UML e o Processo de Desenvolvimento

:11I

=­

=­

~

=­

:31

=­

=­

::li

=­

:li

=­

:li

=­

:3

:li

:w

:iI

:=I

:11

=s

UML-1550 UNimo ~OOWijG

,OQueéUML?

UII!"!~GE

• A UML é uma linguagem para especificar, visualizar,

construir e documentar os artefatos de software.

• Contribui para as melhores práticas de engenharia de

software, pois é uma linguagem visual.

• A Unified Modeling Language nasceu em 1994 a

partir da junção de vários métodos (Booch, OOSE e

OMT)

• Começou como uma iniciativa particular, mas logo

várias empresas importantes (IBM, Microsoft, etc) se

uniram ao esforço de padronização

• Padrão OMG (UML

1.1 -1997)

63

A Unified Modeling Language é uma notação que normatiza um conjunto de diagramas. É

uma linguagem para especificar, visualizar, construir e documentar os artefatos de software e também para a modelagem de negócios.

A UML é uma indicação das melhores práticas de engenharia que se mostraram bem sucedidas na modelagem de sistemas.

A UML e o Rational Unified Process (RUP) nasceram da junção de vários métodos (Booch, üüSE [Object-Oriented Software Engineering] - Jacobson, e üMT [Object Modeling Technique] - Rumbaugh, entre outros Fusion, Shlaer- Mellor e Coad- Yourdon), por isso se chama 'linguagem unificada' e 'processo unificado'.

<i. <:l I­ --' o .0« o­ o« o ::> o w I­ W Z u, ~ ti: o a, rn o o o« > ti: w fil ti: o· .0« rn

s

l­ m ti: Õ rn o rn o <:l o I­ '~ UML-I:55:

Definição

• Definição em Três Partes

1. A UML funde os conceitos de Grady Booch,

James Rumbaugh e Ivar Jacobson.

2. É genérica e flexível. Pode ser aplicada a uma

diversidade de sistemas.

3. Tem como foco uma linguagem de

modelagem padronizada e não se preocupa

com a metodologia de desenvolvimento.

• Método

=

Linguagem (UML)

+

Processo

(RlTP)

64

Definição em Três Partes

1) A UML funde os conceitos de Grady Booch (Método Booch), James Rumbaugh (OMT - Object Modeling Technique) e Ivar Jacobson (OOSE - Object Oriented Software Engineering).

O resultado é uma única linguagem de modelagem comum e amplamente adotada pelos usuários desses e de

, t=

outros métodos.

'I:

Booch é arquiteto de software e já trabalhou em vários projetos complexos difundindo os conceitos de 00, além de ter escrito vários livros e artigos técnicos.

Jacobson é criador do Objectory (método de desenvolvimento de sistemas) deu importância ao reuso de software e também é autor de vários livros técnicos.

2) Não existe um nicho específico do mercado que pode ser desenvolvido em UML, não há seleção por tamanho do programa, pois a UML se adapta a qualquer tipo de sistema.

Um exemplo dessa capacidade foi a adoção de sistemas distribuídos concorrentes como alvo pelos seus criadores. Outro exemplo é o mapeamento das atividades de um sistema em tempo real.

Exemplo de como a UML pode ser útil a todas as áreas participantes do desenvolvimento do software: o programador que terá um documento com a solução para tradução para a linguagem de programação, facilita o analista no levantamento e entendimento do software, o arquiteto irá desenhar a solução a ser implementada, o gerente do projeto poderá planejar a divisão do trabalho, o cliente irá validar e entender o escopo do projeto - todos tiram proveito do uso da UML.

3) A UML tem como foco uma linguagem de modelagem padronizada e não se preocupa com a metodologia de desenvolvimento (o processo de desenvolvimento em si). Os esforços foram concentrados em um meta­ modelo comum (que unifica a semântica) e em uma notação comum e simples.

==

::i

<i.. >­ ...J

=:i

_o« o <I: o :::l o w

-.

o C> >­ w Z lL ~ o e,

::!

li: til o o <I: li: W til

:::i

> W li: o o« til til o >­

~

jjj li: Õ til til o o

:::::!

o o >­

: !

::3

~

::3

~

:iI

:11

=­

:!I

:11

:iI

:iI

ai

UML-1550

Versões e Certificações

• A versão atual da UML é a

2Y'

• Algumas partes desta especificação ainda

estão em discussão.

• Novidades com relação a versão 1.5:

• Classificadores aninhados

• Melhorias na modelagem de comportamento • Melhorias no relacionamento entre modelos de

comportamento e de estrutura

• Certificações oferecidas pela OMG

65

Versões

A especificação completa da UML pode ser encontrada no site oficial (http://www.uml.org). A versão atual (2.1) ainda possui alguns aspectos sob discussão.

Acrescentou diversas novidades como a possibilidade de criação de novos diagramas sob demanda.

Certificações

A OMG oferece três níveis de certificação: Fundamental

Você pode trabalhar com os elementos UML mais comuns Você pode criar diagramas UML simples

Você está qualificado para ser membro de uma equipe UML Intermediate

Você pode trabalhar com vários elementos UML Você pode criar diagramas complexos

Você está qualificado para ser membro sênior de uma equipe UML Advanced

Você pode trabalhar com todos os elementos UML Você pode criar diagramas extremamente complexos Você está qualificado para ser gerente de uma equipe UML

INSTITUTO INFNET - 65

--ci c ':i o

.

..: o­ ..: o ::> c w I­ W Z LL ~ ao o Q. '" o c ..: > ao W '" W ao o '..: '" '" o I-m ao Õ '" o '"

s

o I­

-

r

_...

UML-I550

o

que

é Engenharia de Software?

• A Engenharia de Software envolve o gerenciamento de

três "forças":

Atividades que

"'"

precisam ser

r

IProces~

executadas e fases

-que precisam ser

cumpridas

r

-Ferramentas

,pesT_

~

-r

Responsáveis pela

-execução das atividades e pelo Infra-estrutura _{gerenciamento do}

--=

incluindo tecnologias _processo

r

-68

o

processo de desenvolvimento de software envolve o gerenciamento de três

r

características: processos, pessoas e ferramentas.

Os processos precisam ser bem definidos e padronizados e devem se adaptar aos

processos de negócio da empresa. Um processo deve ser simples o suficiente para ser entendido e

r

-executado sem falhas, mas não deve eliminar atividades vitais que possam comprometê-lo. Além

disso, a equipe que utiliza o processo precisa ajudar a revisá-lo rotineiramente, depurando-o. Habilidades, capacitação, criatividade, iniciativa são características que precisam ser acentuadas nas pessoas que compõem a equipe. O talento pessoal pode ser melhorado

r

continuamente através de treinamento, incentivos e satisfação em participar de projetos bem

-sucedidos.

i -=

Cada atividade definida no processo tem uma ou mais pessoas que precisam

_!:

desempenhá-la. Muitas dessas atividades precisam do suporte de ferramentas de software que

ajudam e aceleram na sua execução. A homologação de ferramentas é uma atividade cíclica que

r

precisa ser feita rotineiramente a fim de melhorar o processo de desenvolvimento.

Frustração Lentidão Falsos Inícios r - - - - Sucesso iOS 1----+ Confusão r---- Ansiedade L . - _ - - - J Pessoas Processos

Engenharia de Software

• "Equilíbrio de Forças"

--l~~~~~ ~~===;;I//

69

:li

=­

=­

~ -:< :::> ~

:li

:ii: ã z

...

~

=­

!: i: ~

..

=­

>_:: JII. JZ JII. :: :<

:=11I

..

!! :ii: ~ I

:li

! !!

~

=­

_{Para que a construção de um software seja bem-sucedido é necessária a existência de}

==-

fatores para cada um dos elementos do desenvolvimento: processos, ferramentas e pessoas. Na figura acima pode ser visto o que normalmente acontece se uma determinada

:11

características não existe ou não atinge um bom nível de qualidade.

:3

=­

=­

=­

::11I

::11I

:11I

:11

~

INSTITUTO INFNET -69

<i­ a ~ o .« ~ u :::l a w I­ W Z u, ;;l; a: o <>. l/l o a « > a: w l/l W lI: o .« CIl l/l o l­ m a: Õ l/l o l/l o a o I­ UML-1550

Processos de Desenvolvimento

• Os processos de desenvolvimento são

compostos por diversas fases;

• Em cada fase

é necessário executar diversas

atividades.

• Esse esforço tem como alvo principal a

construção de um sistema de qualidade.

70

No processo de desenvolvimento podem ser reconhecidas diversas fases que devem ser cumpridas a fim de que tenhamos o sistema funcionando à disposição do usuário. O processo de desenvolvimento define a regra do jogo.

Em cada fase do projeto, é necessário executar diversas atividades, tais como: • Reuniões com os usuários para definição de escopo e validação do trabalho,

• Gerar documentações (cronograma, documento de visão, diagramas, documentação do projeto, do programa, etc),

• Fazer protótipos de programas para testar tecnologia, arquitetura ou interação com o usuário,

• Testar funcionalidades,

• Fazer instalações de computadores, sistemas operacionais, software de apoio ao desenvolvimento como ferramentas case, compiladores, servidores, etc ..

Todo esse esforço tem como alvo principal a construção de um sistema de qualidade que seja duradouro, suportando modificações com um mínimo de trabalho.

~

-íiiiiiiiiiiii

-.~

-INSTITUTO INFNET - 70 F~..·,.Jg;;gg,

:11

:11

!O --'

:31

_~ <' o < ~ .u Z L.

=-

E ~ ~

~

_~ :< I: .11

..

> .11 I:

=-

;;;:

..

~

:I

E

=-

! ~

~

:3

;li

:a

:iI

:11

:11

:11

:11I

:11

~

:11I

;jI

=­

UML-1550

Processos de

Desenvo!;~e~~oj.o

• Ciclo de Vida

~~íí)<7..eg--o

Iterativo (RUP) Extreme Programming

Tradicional

MU:l"

~~$P1

71

A forma usual de divisão do processo de desenvolvimento em fases é considerar que o problema deve ser entendido (análise), projetado (projeto), implementado (construção) e testado (testes).

A figura acima mostra como três processos diferentes tratam essa questão:

• As formas tradicionais consideram que o usuário deve saber todas as suas necessidades no começo do processo e que mudanças não irão ocorrer durante o desenvolvimento.

• Os processos iterativos, como o Rational Unified Process (RUP), consideram que mudanças ocorrem e devem ser incorporadas ao software durante o seu desenvolvimento. Utilizam o processo iterativo (repetições das fases) e incremental (melhorias no projeto em cada iteração).

• O processo extreme programming (XP) leva a dinâmica do desenvolvimento ao extremo: os requisitos mudam muito rápido e devem ser implementados o mais cedo possível para que o produto seja útil ao usuário final.

--<i c !:i o '00: o­ 00: U ::l C w ti z u, ~ o:: o _Do rn O C 00: > o:: w rn w o:: o '00: rn rn O t:: w o:: C rn O rn O C ~ UML-1550

Rational

Unified Process

.,..

• Origens

-- O RUP foi desenvolvido originalmente na

Suécia por Ivar Jacobson, sendo batizado, na

ocasião da sua concepção, de Objectory.

- Trata-se de um processo iterativo e incrementaI

e indica o uso da UNIL.

- O RUP é um framework, ou seja, você pode

--.::

adaptá-lo para as suas necessidades.

'~

­

'-­

-

-'~

­

o

RUP foi desenvolvido originalmente na Suécia por Ivar Jacobson, sendo batizado, na ocasião da sua concepção, de Objectory.

Trata-se de um processo iterativo e incremental baseado na UML, cujo foco central são os modelos de caso de uso e métodos de projeto orientados a objetos.

--. '~

---= '~

-E

-INSTITUTO INFNET - 72 ~

­

UML-1550

Rational Unified Process

Disciplinas Modelagem de Negócios Requisitos Análise e Design Implementação Teste Implantação Geren. de C.Qnf\9ura~o e Mudança Gerenciamentó de Projero Ambiente _ _....!--_..."'"'-!-- IIIIIIIIiIl~ . . . 73

Descrição em Duas Dimensões

Esta figura representa duas dimensões:

• A horizontal que representa o aspecto dinâmico do processo, como é ordenado e expresso em termos de ciclos e marcos de projeto - é o eixo do tempo.

• A segunda dimensão, vertical, representa o aspecto estático dQS processo, como é descrito em termos de atividades, fluxos de trabalho, artefatos e pessoas -é o eixo de conteúdo. O final de cada iteração é marcado pela entrega de um artefato de software (uma versão, um módulo, um conjunto de diagramas), esta entrega pode ser para validação com o usuário ou para teste da equipe.

Podemos observar que o compromisso de desenvolver um sistema, envolve diversas atividades que são executadas continuamente durante todo o projeto.

No RUP as atividades têm uma alocação maior em função da fase em que se encontra o projeto. As fases ajudam o gerente do projeto a fazer a apropriação de profissionais e custos, resultando em uma maior eficiência.

Por exemplo, na fase de Concepção (Inception) existe uma alocação maior de analistas envolvidos na atividade de "Levantamento de Dados", representada no diagrama por "Business Modeling" e "Requirements". INSTITUTO INFNET - 73

::I

=­

::s

::w

~

=­

::I.

=t

::I

:t

: I

=­

::I

::I

: t

::I

::I

:ti

::I

::J

<i

e

-

_c -=: 't>_« E i5 ,L; !.LJ Z LL. ~ 11: ~ :c o ~ > ::

'"

'" x:

'"

~ '" :: o n :>:: Õ Q o Q ·0 C

e

~

~ ~ o .« ~ o ::::l C W I­ W Z lL ~ D: o o. Ul o c « ~ w [fi p: o .« Ul Ul o !::: w D: Õ Ul o Ul o c g UML-I55:

RUP: Requisitos

[Now SstemaJ [Si si:ema Existentej

[No'J3 Ertra:la]

Anaisa- o Problema

t

[Problema

Incorreto]

[Não posso fazer

tO~,Q o traJalho)

--~"i~ijil--<ll

Ge-enciar Requisitas tvt.Jl:á...as

Definir o Gerendaro Escopo [TnDalhã

Sistema do aatema no sscopo]

Refina-~

Definição do Sstema

74

A figura acima mostra os fluxos de trabalho envolvidos na etapa onde acontece a identificação de requisitos. Segue abaixo a lista dos fluxos, seus objetivos e responsáveis pelo trabalho:

Analisar o Problema (Analista de Sistemas): definir as fronteiras do sistema, restrições e

envolvidos.

Compreender as Necessidades dos Envolvidos (Analista de Sistemas): levantar

informações dos envolvidos no sistema para compreender as suas reais necessidades.

Definir o Sistema (Analista de Sistemas) : realizar uma análise das necessidades dos

envolvidos, refinar a visão do sistema e seus casos de uso.

Gerenciar o Escopo do Sistema (Arquiteto de Software e Analista de Sistemas): priorizar

e refinar os requisitos, definir o conjunto de casos de uso mais relevantes, definir o que será mantido.

Refinar a Definição do Sistema (Especificador de Requisitos, Designer da Interface):

descrever com detalhes os casos de uso, detalhar especificações suplementares, modelar e criar o protótipo da interface do usuário.

Gerenciar Requisitos Mutáveis (Analista de Sistemas, Revisor de Requisitos): avaliar

solicitações de mudança, estruturar os casos de uso, verificar se o trabalho está de acordo com a visão do usuário. INSTITUTO INFNET • 74

r

-if

-~ I~

-~

-~

-~

-r

-1f

-f

-r

-'ir

-~

-1f

-~

-~

-~

::I

c .... ...

::I

q; o o« o­ -c o ::::l C W

::I

.... W Z lL

: I

:?: EC O O­ O

'"

c -c > EC

~

w W

'"

EC O O

::li

o«

'"

....

'"

U; EC E O O

: I

'"

'"

c O

=t

....

:.t

: I

:=I

=­

~

:I

=­

:!I

:li

:11

:iI

:ti

UML-1550

RUP: Análise e

Projeto

Projetar Projetar o

Co mpcnernes Banco de Dados

Refinar a

Arquitetura

75

Fluxos da Análise e Projeto:

Definir uma Sugestão de Arquitetura (Arquiteto de Software, Designer): criar o esboço inicial da arquitetura do sistema (identificar elementos mais relevantes, definir as camadas), identificar classes de análise, atualizar casos de uso.

Analisar Comportamento (Arquiteto de Software, Designer, Revisor de Design):

transformar as definições dos casos de uso em um conjunto de elementos viável para o trabalho de designo

Projetar Componentes (Designer, Revisor de Design): detalhar elementos de design, atualizar casos de uso, revisar o design, implementar componentes, testar componentes.

Projetar Banco de Dados (Designer, Designer do Banco de Dados, Revisor): identificar classes persistentes, projetar estrutura do banco de dados, definir estratégias de armazenamento e recuperação de dados.

Refinar Arquitetura (Arquiteto de Software, Revisor): identificar mecanismos e elementos de design, descrever arquitetura e distribuição.

Realizar Síntese Arquitetural (Arquiteto de Software): demonstrar que há solução arquitetural viável para satisfazer os requisitos do sistema.

<i c ~ o '<l: o­ <l: o => c UJ lü z u, ~ a: ~ til o c <l: > a: UJ til UJ ~ o '<l:_til til o !:: UJ a: Õ til o til o C ~ UML-I550

Esirut urar o tIobdelo de Implementação t

mJ,

Pl:an~ara Integração ,j, [Componentes Testados em Unidadesdisponíve:is] [Mais Componentes para Implementar nessa Iteração] [Mas '~:t~~~~a~~ _""I'""'...a;.,._ _~ essalteraç:ào] [Feita) 76 Fluxos de Implementação:

Estruturar o Modelo de Implementação (Arquiteto de Software): organizar o modelo de

implementação com o objetivo de minimizar conflitos.

Planejar a Integração: planejar a construção e ordem de integração dos subsistemas. Implementar os Componentes (Implementador, Revisor, Integrador): programar os

componentes definidos.

Integrar cada Subsistema e Sistema (Integrador): integração dos novos componentes e

geração de versões do software. .

j

f[. / 1', /

~ (svl~r:~ ~ Af~f&rP!'

él9U<.

<=>d'--o

<fQ

,4c::y\.{;J~N'")

o~(~Wt}~

INSTITUTO INFNET - 76 ~

-E

-E

-~

-E

-E

_....

E

-~

-E

-~

-=­

:11I

<:

=

-D

=-

~ ~ n z z ... E §:

::-

~

_g

> ll. ll. E

:-

<

'"

E :< == c

:11I

i: == e-E ::5

..

O c

:3

s

=-c

=­

:::.

:11

=­

::31

=­

~

:s

=­

::J

::I

:21

UML-1550

RUP: Testes

lEI

Definir Missão deATiação

t

~ r--~

VerifiGarAbordag em Validar Estabilidade do Teste do Build t ~ I (Outra Técnica] Realizar Testar e Missão Avaliar Aceitável t >Ir ~' AprimorarVantagEns do Teste } ~ outro Ciclo ... de Teste) Fluxos de Teste:

Definir Missão de Avaliação (Gerente de Testes, Analista de Testes): identificar estratégias de testes, descrever métodos de teste e definir formas de avaliação.

Verificar Abordagem do Teste (Gerente de Testes, Analista de Testes, Testadores): verificar se a abordagem definida funcionará e estabelecer a infra-estrutura.

Validar Estabilidade do Build (Gerente de Testes, Analista deTestes, Testadores): fazer a avaliação da estabilidade do build, identificando o build como aprovado ou não.

Testar e Avaliar (Gerente de Testes, Analista de Testes, Testadores): fornecer avaliação contínua dos itens de teste.

Realizar Missão Aceitável (Gerente de Testes, Analista de Testes, Testadores): defender a qualidade adequada e identificar regressões de qualidade.

Aprimorar as Vantagens de Teste (Gerente de Testes, Analista de Testes, Testadores): montar scripts de teste, manter configurações do ambiente de teste, explorar oportunidades para melhoria da produtividade, documentar lições aprendidas.

....I <i. a I­ O -o« o _o« U ::> a w I­ W Z u. i!E a: O e, O

'"

a o« > a: w w

'"

a: Ó .0«

'"

_O

'"

!:: w a: Õ O

'"

O

'"

a O I­ UML-155W

RUP: Implantação.

~: p-i-~-~;J~r Implantação Gerendâ~T~·ste de "' Aoeitação<N,? Local do üesenvower Material nesewotvi mento>

de Suporte ~ Produz.ir Unidade de Implantação . . [""e••ê ·""1

""1eI1

[R etease do Client:l::r::< -:-:::::::::::::::::::::::-:-:-:::_-;:: 'f Produto de Teste Beta [Softv..<are Descarregával] 78 Fluxos de Implantação:

Planejar Implantação (Gerente): planejar a implantação do software.

Desenvolver Material de Suporte (Autores do Material de Treinamento): escrever o material que auxiliará no trabalho de implantação do software.

Gerenciar Teste de Implantação (Gerente): garantir a aceitação do software antes do lançamento geral.

Produzir Unidade de Implantação (Gerente, Implementador): criar uma unidade de implantação (software e recursos de instalação necessários).

Produto de Teste Beta (Gerente): criar um produto de teste para a obtenção de feedback sobre o software.

Gerenciar Teste de Aceitação (Gerente): garantir a aceitação do software antes do lançamento geral.

Empacotar Produto (Gerente, Artista): reunir as unidades de implantação, scripts de instalação e manuais para produção do software.

Fornecer Acesso ao Site de Download (Gerente): disponibilizar o produto para download.

INSTITUTO INFNET - 78 - , - ' - - - ' - -- - ­ ~

_­

r

-r

-~

­

ir

-•

-.;;( J < =: iI :ui li: :5 ::: o ::: o := o UML-1550

Rational Unified Process

• o

RlTP é uma implementação do modelo de

espiral, no qual as fases se repetem e se

sobrepõem

• Ciclo de Vida:

- Concepção

- Elaboração

- Construção

- Transição

79

o

RUP é baseado nos princípios de desenvolvimento de software: Desenvolvimento iterativo

Controle de requisitos Arquitetura de componentes Modelagem visual de software Controle da qualidade do software Controle das mudanças no software

O RUP foi construído a partir de um ponto de vista de gerenciamento, tendo sido dividido em quatro fases: concepção (iniciação), elaboração, construção e transição. Estas fases não são independentes, ou seja, uma não termina necessariamente antes da próxima começar.

Podem ser realizadas várias iterações sendo que em cada uma delas é feito o trabalho das quatro fases. Cada passagem completa é denominada de ciclo de desenvolvimento.

<i _c S o .C( ~ o => c w I­ w Z u, ~ a:: o n. (f) o c c( > a:: w (f) w r;<: o .C( (f) (f) o ~ _w a:: Õ (f) o (f) o c o I­ UML-I550

Fase de Concepção

• Na fase de concepção é estabelecido o contexto de

negócio para o sistema e delimitado o escopo do

projeto.

• O contexto de negócio inclui também um critério de

sucesso, ponderado em função de recursos e tempo.

• Devemos elaborar um cronograma básico de

execução com as principais fases e datas

• Nessa fase o sistema é descrito através de um texto

sumário, resumindo o que é o sistema, e de um

diagrama de Caso de Uso geral, contendo os atores e

as suas principais funcionalidades.

80

Na fase de concepção é estabelecido o contexto de negócio para o sistema e delimitado o escopo do projeto. Para tal, identificamos os atores que estarão interagindo com o sistema, bem como os casos de uso associados às essas interações.

O contexto de negócio inclui também um critério de sucesso, ponderado em função de recursos e tempo. Essa ponderação nos dá o grau de "risco" que é possível assumir.

Além disso, devemos nessa fase elaborar um estudo que tem como produto final um cronograma básico de execução com as principais fases e datas de entrega.

Essa fase envolve a elaboração de um ante-projeto do sistema (uma proposta) composto pelo memorial do projeto, escopo pretendido, principais atores envolvidos, principais casos de uso e o uma estimativa de cronograma (com os principais marcos do projeto).

'I:

i!

-INSTITUTO INFNET -ao

I=============~~~==---•

11

11

11

li

11

11

11

iI

iI

11

!

-, 1

-<i. o -' o -o: t> -c o 5 lU .... OJ Z

...

~ ::I: o "­ o '" c -c > I:C l!J l!J

'"

::I: o -o: et:I CIl o .... iü c:: Õ et:I o cn o o o .... UML-1550

Fase de Elaboração

• Consiste de uma análise mais refinada do sistema a

ser construído, juntamente com um plano detalhado

de trabalho a ser feito.

• Elaboração de um projeto completo, com o

detalhamento de interações e estrutura do sistema.

• Construir um protótipo que teste a arquitetura

escolhida.

• Nessa fase os Casos de Uso são completamente

detalhados, são elaborados todos os diagramas de

classes identificadas, são feitos protótipos das telas e

o projeto lógico do banco de dados é elaborado.

81

Consiste de uma análise mais refinada do sistema a ser construído, juntamente com um plano detalhado de trabalho a ser feito. As metas da fase de elaboração são: analisar o domínio do problema, estabelecer uma arquitetura funcional, desenvolver um plano do projeto e minimizar elementos de riscos potenciais ao projeto.

Essa fase envolve a elaboração de um projeto completo, com o detalhamento de interações e estrutura do sistema. Nessa fase também podemos construir um protótipo que teste a arquitetura escolhida.

Por exemplo, podemos ter a incumbência de criar uma aplicação para Web usando Java Server Pages - JSP. Nós vamos detalhar as interações dos atores com cada caso de uso, vamos modelar as classes do sistema e vamos construir algumas páginas JSP para testar a sua funcionalidade. Podemos ainda envolver a participação do cliente nesse processo.

-I

~ I­ ...J o '-o:_C> i3 ::> w

"

I­ W Z u, ~ a: o Q. CJl o -o:

"

> a: w CJl w .a: o '-o:_CJl CJl o l ­ m a: C CJl o CJl o

"

~ UML-I65:

:1

Fase de Construção

• Trabalhamos sobre o protótipo da fase anterior

I

adicionando novas funcionalidades e refinando as

funcionalidades pré-existentes.

_I

• O gerente do projeto define várias versões que

devem ser liberadas a cada ciclo.

• A cada ciclo é necessário rever os requisitos de

cada parte da aplicação.

• Nessa fase os módulos do sistema são

implementados e refinados em ciclos (iterações).

O projeto físico do banco de dados é

implementado.

82

I

Durante a fase de construção trabalhamos sobre o protótipo da fase anterior adicionando novas funcionalidades e refinando as funcionalidades pré-existentes. Chamamos essa abordagem de iterativa (por ciclos) e incremental (adicionando valor).

O gerente do projeto define várias versões que devem ser liberadas a cada ciclo, incluindo alterações, refinamentos e novas funcionalidades.

A cada ciclo é necessário rever os requisitos de cada parte da aplicação, pois essa é a essência do desenvolvimento incremental.

INSTITUTO INFNET - 82

UML-1550

Fase

de

Transição­

• Nessa fase o software pode ser instalado em

ambiente de produção para que os clientes possam

trabalhar com ele - versão beta.

• A medida em que testes são executados e

melhorias são implementadas é produzida a versão

final do produto.

• Nessa fase, além da versão beta e do produto final,

são produzidos os manuais e componentes de

distribuição do software.

83

Nessa fase o software pode ser instalado em ambiente de produção para que os clientes possam trabalhar com ele. Como esta transição será feita ? Em paralelo com o sistema atual ou simplesmente o substituído deixará de funcionar para início do novo sistema ?

Assim que o programa entra em operação, é previsto que alguns pequenos ajustes sejam necessários para que a versão final esteja disponível.

Um marco dessa fase é a "versão beta" do produto para testes.

Se tiver programado é nesta fase que ocorre o treinamento e outro produto (ou artefato) é o conjunto de manuais com instruções de uso do sistema.

Ao [mal dessa fase público-alvo.

teremos o produto em sua versão final para uso irrestrito por todo o

:11

:11

=­

:I

=­

=­

:I

:3

:3

:3

:3

:I

:3

=­

:I

:I

:I

:i

:t

:i

<i. ::l :J c « o­ « :.J ::::I ::l :.ll. iu z L ~ OI: ~ CO O ::l « > c: Lt.!I. Q :.tJ. c: O « _Q Q 2 ii OI: Õ "" o "" o ::>

e

INSTITUTO INFNET - 83

~

:=I

::li

~

:11

.<

= -:> ~ < :ii ; z ~ ~ t­

:a

~ u ~ > :z:: u ;a,

: I

< "" ~

..

:z::

..

o

:11

Ü

..

:z:: :i

..

o c

~

::l

:::

~

=­

=­

~

~

::11

:li

: I

~

:11

:11

:11

=iI

UML-1550

Extreme Programming (XP)

~"<"",-,,,~",,,,,,,,,,~"'=--'--''''~''.~~---'--'''~"-'- ,~-" -.,. - ­

• Processo ágil de desenvolvimento

• Criado por Kent Beck, Ward Cunningham,

and Ron

J

effries em 2000

• Objetivo principal: entregar o software que o

cliente quer no momento em que ele precisa

• Menos formalização e mais disciplina

• Sugere práticas para alcançar valores

85

Processo ágil de desenvolvimento criado por Kent Beck, Ward Cunningham, and Ron Jeffries.

Um manifesto (http://agilemanifesto.orgl) foi escrito para descrever o que é o desenvolvimento ágil e porque ele está sendo usado:

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas;

Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano.

Ou seja, mesmo dando valor aos itens àdireita, valorizamos mais os itens à esquerda."

INSTITUTO INFNET - 85

---_._---_._----_._,,---~---_._----_.~----_._--II

"

I I I ! I <i c ~ o .« o­ « o :::l C w lu _z LL ~ D: o O­ '"o c « > D: W w

'"

D: o .« '" o

'"

!:: w D: Õ o '" '"o c ~ UML-I55:

Valores do XP

1.

2.

Comunicação

Maior comunicação entre membros da equipe

Não é limitada por processos formais

Simplicidade

Redução da complexidade do sistema

Não projetar de maneira genérica

86

o

XP tem o objetivo principal de entregar o software que o cliente precisa no momento em que ele precisa. Para atingir este objetivo quatro valores devem ser incorporados no processo:

Comunicação. Quanto mais eficiente for a comunicação e mais cedo ela ocorrer, mais problemas virão a tona e poderão ser gerenciados antes que causem maiores estragos. A melhoria da comunicação entre os membros da equipe pode ser alcançada com práticas simples: A

comunicação não pode ser limitada pela burocracia. Deve-se utilizar o melhor meio possível no momento: conversa, email, telefonema. A comunicação deve conter o que for necessário para a explicação: código fonte, diagramas, descrição de casos de uso, etc.

Algumas constatações sobre comunicação: presença física é melhor que telefonema que é melhor que email. Código simples de entender é melhor do que documentação escrita.

Simplicidade. Manter tudo o mais simples possível toma o sistema mais fácil de alterar, mais rápido de desenvolver e menos propenso a erros. As práticas XP que reduzem a

complexidade são: a solução (projeto, algoritmos, tecnologia, ténicas) sempre deve ser a mais simples possível e que atenda as necessidades do cliente. Não há momento fixo para simplificar o projeto, código ou processo. Qualquer tipo de trabalho que seja feito genericamente

(contemplando possíveis questões futuras) deve ser eliminado.

INSTITUTO INFNET - 86

11:

:~

r

-r

-L.~.-============-===~~~

:li

:I

e

_....J

:11

""

o < _o­ s ~ .1C

:I

< .L! %

=-

.L :: 15 ;?; ~

'"

< J: ., ""

3

_""> _J:

..

..

c

:li

< ~ :I!:

..

:5

..

o

=-

§

31

-•

11

iiII

11

11

11

11

•

₁₁

•

₁₁

lIML -1550

Valores do XP

3. Feedback

Tanto sobre a qualidade do código quanto sobre

o seu funcionamento

4. Coragem

Jogar fora práticas que causam problemas

Feedback. Quanto mais cedo os problemas aparecerem, mais cedo serão resolvidos ou pelo menos contornados. Estes problemas podem ser de qualquer tipo: no código, processo, interface, requisitos, etc.

Nesta área o XP oferece as práticas que mais fizeram sucesso: feedback sobre o código: programação em par, testes de unidade (test-first) e posse coletiva; feedback sobre o

desenvolvimento: histórias do cliente, integração contínua, jogo do planejamento. Ambas as práticas permitem que:

Erros sejam detectados e corrigidos imediatamente

Requisitos e prazos sejam revistos mais cedo, minimizando o custo de alterações As decisões sejam tomadas de forma mais fácil, mais segura e com menos riscos Estimativas sejam mais precisas

Coragem. Todas as práticas vistas até agora, além de terem benefícios próprios, possuem uma consequência benéfica: o desenvolvedor fica mais confiante e seguro para tomar atitudes que provavelmente não faria sem o XP:

Mexer no código que está funcionando para tomá-lo mais simples. Jogar trabalho (código) fora quando for necessário

Mexer no proj eto a qualquer momento Pedir ajuda

INSTITUTO INFNET - 87

2

:I.

=­

::J

:< ::'

- c-ir

::I

< ~ :Li: z ~ ~

::J

~ ~ < >: z.!

::I

> '"'" >: :<

.,

2

::I

., E >: Õ

.,

c

.,

~

~ E

: I

:3

::I

::I

=­

~

: I

=­

:iI

:ti

:11

:iI

UML-1550

Práticas do XP

5. Padrão de Codificação (Coding Standard/)

J

• Parece que uma pessoa fez todo o sistema

6. Posse Coletiva (Collective Ownership)

• Todos são responsáveis

7. Integração Contínua (Continuous Integration)

• Várias vezes ao dia

8. Metáfora (Metaphor)

• Analogia para facilitar o desenvolvimento

9. Ritmo Sustentável (Sustainable Pace)

• Prazos adequados

89

5. Padrão de Codificação (Coding Standard)

Definição de padrões para nomes de classes, variáveis, métodos, tabelas, campos, constantes, estruturas, posição de chaves, identação.

6. Posse Coletiva (Collective Ownership)

O dono do código é a equipe. Qualquer um pode melhorar o projeto a qualquer momento e todos são responsáveis por ele.

7. Integração Contínua (Continuous Integration)

A integração entre as várias partes do código devem ser feitas com muita frequência para eliminar o mais rápido possível os erros de integração.

8. Metáfora (Metaphor)

A comunicação da equipe é importante, portanto todos devem ter uma visão unificada sobre o sistema. A metáfora é uma analogia com alguma coisa que todos conheçam, por exemplo: "este software parece um jogo de xadrez" se referindo a um sistema de simulação financeira.

9. Ritmo Sustentável (Sustainable Pace)

Projetos XP devem ter prazo adequado pois horas extras demais afetam a produtividade, a comunicação e a disciplina.

<i. a :; O .« o­ « O => a w f­ w Z lL ~ a: O o.. rJl O a « > a: w ffi .a: O .« rJl rJl O !::. w a: Õ rJl O rJl O a O f­ UML-J550

Práticas do XP

10. Programação em Par (Pair Programming)

~

•

Troca e alternância

11. Projeto Simples (Simple Design)

•

Apenas o que

é

necessário

12. Orientação a Testes

(Test-Driven~

•

Teste primeiro, programe depois

13. Refatoramento (Refactoring)

•

Melhoria contínua do software

90

10. Programação em Par (Pair Programming)

A atividade do programador exige conhecimento, concentração, raciocíno apurado, entre outras características. A programação em par procura maximizar estas

habilidades colocando dois programadores no mesmo computador. Enquanto um fica com o controle do teclado o outro observa, opina e revisa o código. Estas posições são alternadas constantemente e quando possível os pares são trocados. Pesquisas indicam que o tempo que se leva para fazer um programa em par é aproximadamente igual ao de um programador sozinho mas a qualidade do código melhora significativamente. 11. Projeto Simples (Simple Design)

O projeto deve se manter simples durante todo o processo de desenvolvimento. Características que não sejam necessárias para a iteração corrente (versão) não são implementadas ou projetadas.

12. Orientação a Testes (Test-Driven)

Os testes são desenvolvidos antes da programação iniciar. Os testes são automáticos e executados constantemente.

13. Refatoramento (Refactoring)

O projeto e o código são refinados continuamente. Antes de uma mudança o código é melhorado sem que se altere sua funcionalidade. Para que esta prática funcione, a existência de testes automáticos é imprescindível.

INSTITUTO INFNET - 90

-,~

'I

I

, I

I

I

I

I

I

I

I

~

~

<é Cl !:;

~

-.:o o­ q: :::l Cl ffi-.•.. :

:;iI

w o -I­ w Z LL :i!: ti: o 11. cn o Cl -c > ti: W cn W ti: o ,q: cn cn o to w ti: Õ cn o sn o Cl ~

t=I

~

t:3

~.".' ~ ~.' ~

t=i

~.

~ d:,

~

UML-1550

Vantagens

• Foco na codificação (programas pequenos)

• Envolvimento do usuário

• Trabalho em equipe e comunicação

• Responsabilidade pela qualidade

• Simplicidade

• Testes frequentes

• Melhoria contínua

91

As vantagens do XP já foram enumeradas nas páginas anteriores: basicamente as práticas resolvem vários problemas no desenvolvimento de software (apesar de criarem outros como será visto a seguir).

O foco na codificação diminui a quantidade e necessidade de projetos e documentação. Deve-se salientar que esta vantagem existe apenas para projetos pequenos.

O envolvimento do usuário na equipe permite que problemas sejam descobertos mais cedo facilitando o acompanhamento dos trabalhos e aumentando a confiança de todos no sucesso do empreendimento.

Equipes unidas que se comuniquem facilmente, a existência de padrões de documentação e da possibilidade de se alterar o software a qualquer momento faz com que todos sejam

responsáveis pelo sistema.

Simplicidade, testes frequentes e melhoria contínua facilitam a manutenção e a qualidade do software.

UML-155D

Desvantagens

• Foco na codificação (programas grandes)

• Baixa taxa de reutilização

• Ausência de processo e documentação formais

• Não funciona bem quando:

- A comunicação é difícil: equipes grandes ou

espalhadas

- O código não puder ser modificado

- A compilação/testes demorarem demais

- Os programadores do par forem experts

92

A principal desvantagem do XP aparece quando o software aumenta de complexidade pois aumenta também o número de pessoas envolvidas, quantidade de código que deve ser programado e gerenciado e até mesmo a quantidade de diferentes tipos de trabalho (o projeto passa a ser muito mais do que apenas um projeto de software).

A reutilização no XP é muito baixa pois não existe documentação e o código não é feito de maneira genérica.

A taxa de defeitos encontrados quando um programador faz uma revisão na tela é de 10 a 25%. Esta taxa sobe para 20 a 40% quando a programação em par é utilizada. Entretanto, processos estruturados de revisão de software encontram de 60 a 80% dos erros, reduzindo bastante o tempo gasto com testes.

A falta de planejamento de qualidade (métricas e gerenciamento de qualidade) exige muito tempo de teste. O desenvolvimento pode chegar a um ponto bem semelhante a um processo de tentativa e erro.

Nem todos os requisitos podem ser tratados com a abordagem do XP. Requisitos não funcionais restritivos que limitam a funcionalidade do sistema (desempenho, disponibilidade, segurança, etc) não são suportados pelo XP.

INSTITUTO INFNET - 92

e-­

-=

F:-~ u : .

e:=

~

ce=

==

~

-....

­

-tT:9

ai

1,"1 ~il a

:I

:s­

:B

ei o f­ ...l o <I: o­ u a ~ w..JI

::3

« f­ 'U Z o:: o o­

: I

~ ::o o a > o:: co " ,

::I

""' -c o:: o <I: co o f­

:=í

W co Ir Õ ::o co o

: I

o o o I­

: I

:3

:11

:3

:3

::3

:B

::3

::3

: i

:ii

:iI

=8

UML-1550

Processo Sinaples

• Processo usado no curso para a solução dos

exercícios, laboratórios e estudos de caso.

• Passos:

1. Elaborar documento de visão

2. Identificar funcionalidades (requisitos

funcionais)

3. Detalhar funcionalidades

93

Os processos de desenvolvimento são apenas diretrizes e sugestões sobre como projetar sistemas. O próprio RUP é um framework que deve ser adaptado de acordo com a realidade de cada empresa.

Será apresentado agora um processo simples que utiliza algumas técnicas conhecidas e partes de outras metodologias. O objetivo deste processo é servir de base para que o aluno consiga elaborar seus primeiros sistemas e até mesmo definir seu próprio processo.

A primeira parte é a análise e projeto inicial do sistema:

Elaborar documento de visão: Documento que conta a história do sistema.Ele deve descrever o sistema de forma natural, conforme o cliente o relata. Se necessário pode-se aplicar um questionário a fim de colher as informações, visando o "O QUE" o sistema deve fazer, suas características principais e funcionalidades pretendidas. Deve-se evitar entrar no detalhe do "COMO" o sistema será desenvolvido.

Identificar Funcionalidades (Requisitos Funcionais): As funcionalidades estão relacionadas com entrada de dados, inclusão, exclusão, atualização, consulta, cálculo, processamento etc. A lista de funcionalidades serve como um lembrete para facilitar o detalhamento dos casos de uso. Dicas para criação da lista: 1) Usar verbos no infinitivo para descrever as funcionalidades. 2) Agrupar os requisitos conforme as funcionalidades sempre que possível. 3) Colocar em destaque (vermelho) as alterações que possam ocorrer no documento de visão em função da lista de requisitos.

Detalhar funcionalidades: Escrever de maneira bem resumida os passos que devem ser seguidos (sistema e usuários) para executar a funcionalidade. Neste ponto normalmente são encontradas subtarefas comuns a várias funcionalidades.

INSTITUTO INFNET - 93

<i. c ~ o '<C _o­ <C U => c w

...

w Z LL õ!: o: o "­ li) o c <C > o: w 13 .0: o '<C _li) li) o !:: w o: E li) O li) O c O

...

UML-I550

Processo Simples.

•

Passos:

4. Identificar casos de uso

5. Associar telas a casos de uso

6. Detalhar casos de uso

7. Desenhar o(s) diagrama(s) de casos de uso

8. Identificar classes de negócio

.~

-94

'Ê

Identificar casos de uso: elaborar uma lista com os casos de uso que farão parte do escopo

do sistema. Dicas:

Imaginar como o usuário final perceberá as funcionalidades do sistema, listadas na "Lista de Funcionalidades".

Lembrar que casos de uso são macro-funções do sistema perceptíveis pelo usuário - têm início, meio e fim (o início e o fim são percebidos pelo usuário).

Usar verbos no infinitivo para representar os nomes dos casos de uso.

Lembrar da existência do ator Tempo para processos batch, aqueles que são iniciados pelo sistema, em horários definidos.

Associar telas a casos de uso: Para facilitar a identificação dos casos de uso é possível

criar a estrutura de navegação de telas (protótipos ou diagramas) e associar telas aos objetivos de uso dos usuários.

Detalhar casos de uso. Cada caso de uso identificado dever ser descrito de maneira

completa. Todas as interações e exceções devem constar da descrição. Para casos mais complexos são utilizados diagramas específicos.

Desenhar o(s) diagrama(s) de casos de uso: Desenhar o diagrama de casos de uso,

identificando casos de uso primários e secundários.

Identificar classes de negócio: Identificar as classes (entidades, tipos complexos) que

aparecem nas descrições de casos de uso.

:11

::11

=­

=­

=­

; I

:I

:3

; I

~

:3

: I

:I

:I

:I

:I

:I

:t

:I

:J

::J

~

...

c o­

'"

« c ~ :.Li< .c Z ... ~ l:: ~ :I: C ~ > z: :til. 'L!.

'"

:>: C -o: '" '" c Ü :>: 3" '" c 'o '" o o !~ UML-1550

Processo Sinaples

•

Passos:

9. Identificar relacionamentos

10. Detalhar as classes de negócio

11. Desenhar diagramas de sequência

12. Identificar estados

95

Identificar os relacionamentos das classes: Desenhar o diagrama de classes e identificar os relacionamentos que existem entre elas.

Detalhar as classes de negócio: Identificar os atributos e métodos das classes. Esta tarefa é feita simultaneamente com a seguinte.

Desenhar diagramas de sequência: Desenhar os diagramas de sequência para descrever os casos de uso e identificar novos métodos, atributos e classes.

Identificar estados: Identificar os possíveis estados de objetos do sistema. Normalmente um objeto tem estado se sua classe possui algum atributo que indique tal fato. As descrições de casos de uso e diagramas de sequência também são lugares onde os estados podem ser

identificados.

Este processo é feito de maneira iterativa e incremental, assim como o RUP. A cada passo, os diagramas anteriores são revisados para refletirem a nova condição do sistema.

A partir deste estágio, o projeto pode ser iniciado. Nesta etapa as tarefas do desenvolvedor são:

• Projetar Banco de Dados

• Identificar requisitos não funcionais

• Relacionar requisitos não funcionais a casos de uso • Definir arquitetura

• Identificar classes de projeto

INSTITUTO INFNET - 95

:11I

:11I

::11

=­

=­

:11

:11

=­

3

=­

=­

3

=­

:iI

:­

:­

!:li

:­

êI

,.

s

~ -o < _:;; o( Q s ""

...

_Z L. o

..

~

'"

e, o :l <t :>

..

li: .cJ .IJij :li: o < SI

'"

O,

...

E '" :5 O

'"

'" o ::l o ... UML-1550

Diagramas: Visões do Sistema

A UML integra várias visões do sistema com o usuário no centro do processo

99

Cada diagrama da UML apresenta uma visão diferente do sistema mas sempre tendo o usuário no centro do processo.

São definidos dois tipos de diagramas:

Estrutura

Mostram as partes do sistema de forma estática, sem informações sobre o funcionamento. São os diagramas: classes, objetos, componentes, distribuição, pacotes e estrutura

composta.

Comportamento

Mostram o comportamento do sistema, suas funcionalidades gerais, específicas, como interage com o usuário, como se comporta com relação ao tempo. São os diagramas: casos de uso, estados e atividades e os diagramas de interação: sequência, comunicação, temporal e visão geral de interação

J

« '" _~ o ,« ~ o ::> w '" I­ w Z lL ~ o:: o O­ CIl o « '" > o:: w CIl w .0:: o .« CIl CIl o !:: w o:: ;:, CIl o CIl o '" o I­ UML-I550

Diagramas Básicos da UML

++ + Oiagrama Objetos ++ + Diagrama de Componentes 100

A figura acima mostra os diagramas mais utilizados nos projetos UML. Os cinco diagramas em destaque serão estudados neste curso e são os mais importantes para a análise de um sistema.

UML-1550

Fases X Diagramas _

Captura de Requisitos

-

Atividades (fluxo de trabalho, casos de uso) 101 Análise e Projeto

-

Atividades (comportamento objeto, AlgOrItmo,operação)

-Construção

Não existe regra fixa para a utilização de um diagrama em urna ou outra etapa do

desenvolvimento, entretanto a experiência e o bom senso indicam quando estes diagramas devem ser criados.

Os casos de uso são desenvolvidos durante a fase de captura de requisitos. Casos de uso complexos e fluxos de trabalho podem ser descritos por diagramas de atividades.

No momento da elaboração da solução os diagramas de classes definem a estrutura do sistema e os diagramas de atividades descrevem métodos ou trechos de métodos. O diagrama de estados modela as possíveis situações vivenciadas por um objeto, e os diagramas de sequência e comunicação mostram corno os atores interagem com o sistema e corno os objetos trocam mensagens entre si.

Na construção, é necessário definir os componentes de software, ou seja, corno as classes serão reunidas em unidades de software. Além disso, deve-se definir em quais estas partes serão instaladas.

::I

:2

~

::I

:li

::w

::a

: I

=­

=­

~

=­

:­

:­

: I

: I

: I

:I

:I

:i

:s

ci c ,... ...J o -:o: o­ <l: U :::> t:J: '" ,... "" z u, :!:: o:: o a, o

'"

c <:( > li: er '" li: '" o «

'"

'" o ,... Ui a: Õ '" o

'"

o Cl o

...

INSTITUTO INFNET -101

UML -155oD oi a :; O '<l: o­ <l: U '" a LU tü _z u, ~ te O C. cn O a <l: 6: LU cn LU te . O '<l: cn cn O !:: LU te Õ cn O cn O a O ...

Exemplo de uso da UML

• Cenário de uma Aplicação

- Este cenário apresenta oito diagramas UML

utilizados na modelagem de um sistema de

software para uma locadora de veículos.

- Tem como objetivo apresentar uma visão geral do

uso da UML na modelagem de sistemas.

102

INSTITUTO INFNET -102

==­

=­

:=li

-~ <::;:lo

~

ã

:li

_:;;: ;;JL.

=-

!: Z L !!: < li: JlI. 'a JlI.

:a

<! li:

=-

> llIt :li: ~ llIt

~

9 ~

=­

: I

:11

~

::I

:11

:11

:li

:li

=­

=­

:ti

=­

UML-1550 cliente

~tirar car~

.>:

103

Especifica uma interação entre um usuário e o sistema, no qual o usuário tem um objetivo muito claro a atingir.

Os usuários são conhecidos como atores e podem ser pessoas, equipamentos, outros

sistemas e até mesmo o tempo (quando a tarefa é executada periodicamente de forma automática). O diagrama de casos de uso fornece uma visão geral do escopo do sistema. Cada caso de uso deve ser descrito com detalhes. As descrições de casos de uso são a base do restante do sistema, a partir dele se criam classes, diagramas de sequência, estados, etc.

No sistema da locadora, existem dois atores: cliente e atendente pois ambos usam o sistema para realizar tarefas diferentes:

O cliente faz a reserva de um carro; O atendente registra a retirada do carro; O atendente registra a devolução do carro.

oi c ~ o -..: o <[ u :> c !.LI >­ !.LI Z u, ~ li: O e, O

"'

o <[ > li: w !.LI "' li: O ê1i "' O !::: !.LI li: ã O "' o

"'

c O >­ lia UML-1550

Diagrama de Classes.

Carro Aluguel -placa -dataAluQuel -mode Lo f---~o-,,·---1-daLaElltrada »chas s í 1,,* -e e c edc -preco .... -t-reae rve r () +retirar () Aqência

+devo 1ver () Cliente

-endereco -fone <nome -endereco -fone -habilitacao -gerente »emet.j. 104 Funcionario

A próxima tarefa é a classificação das entidades envolvidas neste processo e o seu relacionamento.

Diagramas de classe mostram a estrutura geral do sistema e também as suas propriedades rel acionais e de comportamento.

A locadora pode ser implementada com as classes: Carro, Aluguel, Cliente, Agência, Funcionário, Vendedor e Mecânico.

O diagrama da figura acima mostra as classes de negócio, aquelas que implementam os requisitos funcionais da aplicação.

Podem ser feitos outros diagramas de classes com objetivos diferentes, por exemplo, um diagrama de projeto que mostre as classes ligadas ao controle e à apresentação dos dados para o usuário.

INSTITUTO INFNET -104

3

K---:---­ [ 11 ; ccnbrmeçêo 1 : Soliclação do Carro() 4 : carro e perfodoO 6 ; dados pessoasf) / A

equencia

. 2 : buscarCarrosO :

T~---.--~lJ

~ 3 : Iist., de carros ~ ~O, 5; calcularAluguel() ~

O

<xcreece> , 7

i

li

10 : efetuarReserva() 9 : verificarl-tlstoríco() : UML-ISSO

Mostra uma interação de um ator com o sistema, organizada em forma de uma seqüência, dentro de um determinado período de tempo. É um dos diagramas de interação.

Os participantes são os objetos (classes), atores métodos.

A figura acima apresenta um diagrama de sequência que descreve o caso de uso "Reservar Carro". Nele podem ser encontradas as classes do diagrama de classes e um elemento novo: a Fronteira. Este objeto representa a interação com o usuário e serve para abstrair os detalhes de implementação e focar apenas na parte do negócio, a mais importante da fase de entendimento do sistema. INSTITUTO INFNET -10S

:11

=­

:JI

:11

~

:3

=­

:3

:I

=­

=­

:­

:3

:3

:3

:J

:3

:i

:i

:ii

~ ~ c <: IJ g <: i: i: z

...

~ :li: ~ o "" o « > :: e, LI

'"

'"

O <: '" '" O f-i:] II: Õ ee O O

'"

O O i­

<i o !:J o

.

..: o­ ..: o ::::l o w tu z IL :i!: li: o Q. sn o o ..: > li: w <Jl W li: o

.

..: <Jl <Jl ~ m li: C in o in o o ~

:1:

E:

Diagrama

de

Comunicação

~

r=

1: Solicitação de Carro

3: Informa Reserva (data,carro) 2: BuscaCarro( )

5: Identificação Pessoal 4: Calcula Aluguel( )

I:

IFronteira I

-~

---1

~~~~

_I

~

-~

I I

11:

: Cliente

8: Cadastra eserva()

~v~~,~t'I";OOI

J

; /

_~

I: Aluguel I _{I :} Client~=1 I I <E-­ 7: VerificaHistorico( ) 106

É um diagrama que possui a mesma semântica (conteúdo) do diagrama de sequência, ou seja, um pode ser convertido no outro sem perda de significado. O diagrama de comunicação também é um diagrama de interação.

Ele mostra como um grupo de objetos num caso de uso interage com os demais. Cada mensagem é numerada para documentar a ordem na qual ela ocorre. Em versões anteriores da UML, era conhecido como Diagrama de Colaboração.

O diagrama acima descreve o caso de uso "Reservar Carro" do ponto de vista da troca de mensagens entre os objetos. Compare este diagrama com o anterior e perceba que ambos tem o mesmo conteúdo. Entretanto, é mais fácil entender a ordem de funcionamento no diagrama de sequência e mais fácil de visualizar as trocas de mensagens entre os objetos no diagrama de

~ comunicação.

-'~

-UML-I550 INSTITUTO INFNET -106

oi. c ~ o '<C to> <C o ::> c w I­ W Z u, ~ a: o a. CIl o c <C > a: W CIl w a: o '<C CIl CIl o in a: 15 CIl o CIl o c ~ UML-I550

Diagrama de

Comunicação

1: Solicitação de Carro

3: Informa Reserva (data.carro) 2: BuscaCarro( )

5: Identificação Pessoal 4: Calcula Aluguel( )

~ rFr~

_{~ ~~car~~1}

I

r

: Cliente 8:

cad/~:erva(

)

6~aHistoriCO(

)

/ /

~-p~

II _ _: _ _

CI~ie_nt_e

\ -E-­ 7: VerificaHistorico( ) 106

É um diagrama que possui a mesma semântica (conteúdo) do diagrama de sequência, ou seja, um pode ser convertido no outro sem perda de significado. O diagrama de comunicação também é um diagrama de interação.

Ele mostra como um grupo de objetos num caso de uso interage com os demais. Cada mensagem é numerada para documentar a ordem na qual ela ocorre. Em versões anteriores da UML, era conhecido como Diagrama de Colaboração.

O diagrama acima descreve o caso de uso "Reservar Carro" do ponto de vista da troca de mensagens entre os objetos. Compare este diagrama com o anterior e perceba que ambos tem o mesmo conteúdo. Entretanto, é mais fácil entender a ordem de funcionamento no diagrama de sequência e mais fácil de visualizar as trocas de mensagens entre os objetos no diagrama de comunicação.

11:

~

:3

::::t :::i

: l

_...: <­o '-" <l:

:J

::; ::> ::::t L; ~ ~ ~ O "­ '" O

::!

ii: c > I!!!J

: !

'"

'"

« ~ !!: O

:!

'<l: '" ,O >­ '" i:i !i: ã

:!

'"

,O '" '" O

-

•

g

•

-: i

:3

:3

~

: I

::11

:iI

:i

:iI

:Jj,

:iI

UML-1550

Diagrama de Máquina de

Estados

~--__ Cancelar Reserva.---L----.

Reservado

Retira Carro

Retir arro _{[ carro ok]}

[ > 1 ano ou >15000 krn ]

~Em Manutenção Disponível

~_ _

107

Este diagrama é bem conhecido e utilizado há bastante tempo. Ele mapeia diferentes estados em que se encontram os objetos. Desencadeia eventos que levam os objetos a se encontrarem em determinado estado em um dado momento.

A figura acima mostra uma visão dos possíveis estados de um objeto da classe Carro durante sua existência.

Quando um carro é criado ele está disponível para aluguel.

Se um cliente reservá-lo ele ficará reservado até que a reserva seja cancelada ou até que o cliente retire o carro. Neste caso ele estará alugado. Ele também pode ser alugado se alguém chegar diretamente na loja (sem reserva) e retirá-lo.

Quando o carro for devolvido ele irá para a manutenção onde será avaliado e caso esteja tudo certo, voltará a ficar disponível para um novo aluguel. Se determinados valores forem atingidos (carro com mais de um ano ou com mais de 15 mil quilômetros) o carro será posto à venda e sairá do escopo do sistema da locadora. Este fato é identificado pelo estado final.

J

<i. c !:; o '-o:₀₀ -o: O ::> C UJ l;j Z u, ~ a: O o.. <Jl O C -o: > a: UJ fn a: O '-o:rJ) <Jl O !::: UJ a: Õ rJ) O <Jl O C g UML-I~'

Diagrama de Atividades

Veriflcar Histórico do Cliente

Obter I~ormações Pes50ai~ ~ ~ :>- ~~ Rejeitar Cliente [ há problema,]

Confirmar ~e3erva ~ ~ . ,

108

[ ok]

É semelhante ao antigo fluxograma mas possui símbolos para representar outras situações como paralelismo e objetos.

Apresenta a lógica de algum processo, caso de uso, método ou até mesmo a navegação de telas de um sistema.

A figura acima mostra a verificação do histórico do cliente. Ele é mais usado para indicar este tipo de lógica do que o diagrama de sequência pois este normaimente indica apenas o fluxo normal de execução.

É um dos diagramas mais versáteis podendo ser usado em qualquer situação onde seja necessário descrever o fluxo de execução de uma atividade.

INSTITUTO INFNET - 108 1I

•

li

r

-r

-~

-f

-E

-r

•

::I

=­

<i. >­ ....I o

:3

o« c _o­ « o ::> c

...

: I

...

>­ z "­ ti: o "­

::I

~ co o '" « :x: ur co 1!l

: I

> ti: o >« o

'"

:JI

'"

>­ W ti: C o

'"

'" o

~

o o >­

: I

:!

::I

: I

: i

: !

~

::I

::!

: i

es

::2

:a

UML-1550

Diagrama de Componentes

r - - - - I

g

I I I SistemaWEB.DLL - - - 1 I I 1 I I I I

~'''ml

I I I I

~

109

Mostra como os diferentes subsistemas de software formam a estrutura total de um sistema. As dependências entre os diversos componentes também são mostradas neste diagrama.

---r

! I I i <i. Cl ~ o .C( o­ c( o => Cl w

...

w Z LL ~ tE: o D­ CIJ o Cl c( ~ _w CIJ w tE: ' 0 .C( CIJ CIJ o

...

_m tE: 15 CIJ o CIJ o Cl o

...

UML-I55:

Diagrama

de

Implantação

Servidorde Aplicação ---~

6

P' , 'OO A5 P _,,

g

, , ,, , r---­ _, , Servidorde Negpcios O 5"'''''".DLL I

O

SíslemaWEB.DLL ~----I ,,

g

,,

r---I , Bencceenerícc.Du, I ,, ,

Servidorde Banco de Dados

êf:j

110

Mostra como estão configurados o hardware e o software dentro de um determinado sistema.

O nome original deste diagrama é "Deployment Diagram". Como não existe tradução exata, ele tem vários nomes em português: implantação, distribuição e instalação.

I

I

i

•

i

'.

i

'.

i

•

i

_•

i

_•

i

•

i

•

i

..

i

•

INSTITUTO INFNET ·110

i