Uml Na Prática

UML NA PRTICA
DO PROBLEMA AO SISTEMA
Caque Cardoso
f! Utilizo o PRISM Modelo Prtico para

Deienv/o/v/menfo de Software para
desenvolver aplicaes adequadas s
necessidades do cliente
n Acompanhe cada fase de desenvolvimento
do projeto do software
Incluindo o ClassBuilder e
o DMS (Documento de
Modelagem do Sistema)
H Crie de forma prtica a documentao do

projeto utilizando o DMS Documento de
Modelagem de Sistema
EDITORA
CINCIA MODERNA
Caque Cardoso
UML
na prtca
do problema ao sistema
EDITORA
CINCIA MODERNA
UML na prtica: do problema ao sistema

Copyright 2003 Editora Cincia Moderna Ltda.
Todos os direitos para a lnguaportuguesa reservados pela EDITORACINCIA MODERNA LTDA.
Nenhuma parte deste livro poder ser reproduzida, transmitida e gravada, por qualquer meio eletrnico,
mecnico, por fotocpia e outros, sem a prvia autorizao, por escrito, da Editora.
Editor: Paulo Andr P. Marques
Superviso Editorial: Carlos Augusto L. Almeida
Produo Editorial: Tereza Cristina N. Q. Bonadiman
Capa: rika Loroza
Diagramao e digitalizao de imagens: Daniele M. Oliveira
Copidesque: Carmen Mittoso Guerra
Assistente Editorial: Daniele M. Oliveira
,,;:...:.
" '"
-l livro a minha mulher Rita pelo amor e compreenso e aos meus filhos Bruno e Carla por
1 ' MN
i oportunidades
' '1'Oltunidades que
aim tenho
tfinhnnara
anranHariTirvi
r, u r.
ifliw
para aprender
com eles.
Algumas Marcas Registradas aparecem no decorrer deste livro. Mais do que simplesmente listar esses
nomes e informarquem possui seus direitos de explorao, ou ainda imprimir os logotipos das mesmas,
o editor declara estar utilizando tais nomes apenas para fins editoriais, em benefcio exclusivo do dono
da Marca Registrada, sem inteno de infringir as regras de sua utilizao.
FICHA CATALOGRAFICA
Cardoso, Caque
Rio de Janeiro: Editora Cincia Moderna Ltda., 2003.
L inguagem de programao; modelagem de dados
l Ttulo
ISBN: 85-7393-232-5
Editora Cincia Moderna Ltda.

Rua Alice Figueiredo, 46
CEP: 20950-150, Riachuelo -Rio de Janeiro -Brasil
Tel.: (21) 2201 -6662/2201 -6492/2201 -6511/2201 -6998
Fax: (21) 2201 -6896/2281-5778
E-mail: lcm@lcm.com.br
www.lcm.com.br
DEDICATRIA
CDD 001642
SUMRIO
cio
i n 11RODUO
i i (:OMO O DESENVOLVIMENTO DE SOFTWARE HOJE
A ENGENHARIA DE SOFTWARE E O SURGIMENTO DA UML
ORIENTAO A OBJETOS
1,1 O OU E ?
M ; CLASSES, OBJETOS E INSTNCIAS
| i Al RIBUTOS E OPERAES
l Hl l ACIONAMENTOS
8.4.1 Herana
f.4.2 Agregao, composio e dependncia
. 4.3 Multiplicidade
1,5 POLIMORFISMO
8.5.1 Polimorfismo esttico
8.5.2 Polimorfismo dinmico
3 CAPTURANDO REQUISITOS
3,1 REQUISITOS DO CLIENTE X CLASSES DE PROJETO OU DO PROBLEMA AO
HISTEMA
II'.' COMO CAPTURAR OS REQUISITOS ?
;i,() REQUISITOS DE DADO
.'M GERENCIAMENTO DE REQUISITOS
M.!. EXEMPLO DE REQUISITOS
.15.1 ERaF0001.1 - Sacar dinheiro
3.5.2 ERaF0001.2 - Movimentar valores entre contas
3.5.3 ERaF0001.3 - Emitir extraio com saldo da conta
e extraio completo por perodo
3.5.4 ERal0001.4 - Propaganda dos produtos do banco
IX
1
1
2
5
5
6
7
7
8
8
9
10
10
10
13
13
13
14
15
15
15
16
16
16
VI
UM L na prtica: do problema ao sistema
Sumrio
3.5.5 EfaF0001.5 - Instruo fcil para uso de qualquer

opo do caixa eletrnico
3.5.6 ERaF0001.6 - Informao ao usurio do no-funcionamento
do caixa eletrnico
3.6 AVALIAO
^jL
4. COMO TRANSFORMAR REQUISITOS EM USE CASES.

4.1 ATORES
4.2 USE CASE
4.3 DIAGRAMA DE USE CASE
4.3.1 Incluso
4.3.2 Extenso
4.3.3 Derivao
4.4 AVALIAO
5. CLASSES DE ANLISE^.
17
18
19
19
20
25
25
26
27
28
29
5.1 DEFINIO
5.2 CLASSES DE FRONTEIRA
5.3 CLASSES DE ENTIDADE
5.4 CLASSES DE CONTROLE
5.5 AVALIAO
29
30
31
32
32
6. DIAGRAMAS DE INTERAO
35
6.1 AS RELAES ENTRE AS CLASSES DE ANLISE

6.2 DIAGRAMA DE SEQUNCIA
6.3 DIAGRAMA DE COLABORAO
6.4 EXEMPLO DE DIAGRAMAS DE SEQUNCIA
6.5 AVALIAO
7. SUBSISTEMAS
7.1 DESENVOLVIMENTO PARALELO
7.2 SUBSISTEMAS
8. CLASSES DE PROJETO ..!.
8.1 CLASSES DE PROJETO
8.1.1 Estratgias para implementar classes de fronteira
8.1.2 Estratgias para implementar classes de entidade
8.1.3 Estratgias para implementar classes de controle
8.2 OPERAES
8.3 ATRIBUTOS
8.4 OPERAES E ATRIBUTOS DE ESCOPO
8.5 RELACIONAMENTO ENTRE AS CLASSES
8.5.1 Dependncia
5.5.2 Associao
8.5.3 Generalizao
8.6 DIAGRAMA DE CLASSES DE PROJETO...
'HTE8
17
35
35
36
37
37
39
39
39
43
43
44
44
44
45
46
47
48
49
51
54
... 57
lu
59
INTRODUO
l IISTE DE CLASSE
1 1 ' . 1 1 D E STRESS
l USTE DE FUNCIONALIDADE
59
60
60
60
r . I I MAS DETEMPO REAL
61
10,1 INTRODUO
l IML PARA SISTEMAS DE TEMPO REAL
M.', ; Cpsula
\o:>.2Port
10. '..'f Protocolos
IQ.HI XEMPLO: SISTEMA DE RECONHECIMENTO
i - i CHAMADA TELEFNICA
1 1 MODELAGEM DE COMPONENTES
l
i
i
i
i
VII
l l "COMPONENTIZAO", UMA PALAVRA NOVA

l IA UM VELHO PROBLEMA
i .' COMPONENTES
i l PACOTES
l .1 CAMADAS
\'J DO PROBLEMA AO SISTEMA*:

i l O PROCESSO
i ' . ' COMO UTILIZAR OS DIAGRAMAS DA UML
61
61
61
62
63
63
65
65
65
67
68
71
71
75
13. REFERNCIAS BIBLIOGRFICAS
77
II ANEXOS...
81
PREFCIO
A l IML tem se tornado a cada dia um padro para anlise e projeto de software, mas quem
'iilo usa os diagramas da UML? Quem compreende quais as contribuies dos diagramas
o di .envolvimento? Alguns anos atrs, depois de muito tempo desenvolvendo projetos orieni ohjoto, fiz o primeiro contato com a UML e os diagramas e o que mais me impressionou foi o
mui do classes e a possibilidade da modelagem das classes e a gerao de cdigo (ou do
i< 'to" do cdigo) automaticamente e ainda podendo-se atualizar este mesmo cdigo sem perder
ii ilngom. O meu primeiro contato com ferramenta para UML foi justamente o ClassBuilder (includo
1 < |uo acompanha o livro) e que permite trabalhar com modelagem e engenharia reversa de uma
11 mito produtiva.
1
n mndo vi o potencial do diagrama de classes, decidi estudar os outros diagramas imaginando o

> IBSO seria proveitoso no desenvolvimento de um projeto, mas fui me decepcionando a cada novo
>i im, eles no faziam sentido, no havia uma ligao clara entre eles e eu sempre me perguntava
i ilio o diagrama de classes, para que preciso de outros diagramas? Foi na tentativa de responder
Ajunta: que acabei desenvolvendo um modelo que chamei de modelo prtico para desenvolvii do software ou PRISM (Practical Software Development Model) e que a base deste livro. A
.10 do PRISM permitir que se v dos requisitos ao sistema, utilizando os diagramas da UML
inrramenta de trabalho e no somente como documentao de projeto. O PRISM facilita o trabalho
n iltotura e engenharia de software, uma vez que mostra o caminho e permite o acompanhamento
ijulo em cada fase.
n, - .1. livro apresentada em cada captulo uma parte do PRISM (exceto o captulo 2, que apresen onceitos de Orientao a Objetos e que a base da UML e obviamente do PRISM) de forma
nclal, ou seja, se voc seguir captulo a captulo ir poder tomar contato com cada parte do
i Inutu ivolvimento.
A palavra "prtico" tem um significado muito especial, uma vez que a criao do PRISM foi feita
ii ido como referncia o conhecimento terico, porm sempre verificando a utilizao em projetos
< i.s, fazendo com que os conceitos fossem consistentes com o dia a dia de um grupo que trabalhe
i HM i li s:;i 'iivolvimento de software.
U ML na prtica: do problema ao sistema

Para facilitar a documentao foi adicionado ao modelo um template (DMS Documento de
Modelagem de Sistema, que tambm est no CD do livro) que permite documentar todo o desenvolvimento, do software utilizando o resultado do trabalho de modelagem, desta forma, a documentao
passa a ser um aliado durante o processo de desenvolvimento e no um problema, uma vez que
normalmente a documentao feita no final, quando o sistema j est pronto (ou pelo menos o que
se acredita) e no retraa fielmente o que foi desenvolvido, isso quando feita a documentao. E
quando se vai corrigir algum problema ou implementar alguma melhoria no sistema, percebe-se que
esta documentao no tem valor nenhum, uma verdadeira obra de fico sem semelhana com
pessoas ou fatos reais.
Espero que este livro possa ajud-lo no desenvolvimento de software e que sirva de guia, sempre
que for necessrio, na caminho que vai do problema ao sistema. Convido voc a visitar sempre o site
www.umlnapratica.com.br. onde existem artigos, exemplos, ferramentas, informaes e links que
complementam este livro.
l INTRODUO
l l Como o desenvolvimento de software hoje
< > Insonvolvimento de software uma atividade extremamente complexa e subjetiva, pois envol! !< jia muito recente a aparente iluso de que tudo possvel de ser desenvolvido. Alm disso,
i In o rolacionamento entre clientes e desenvolvedores sem um procedimento definido, o que gera
MI lados e no raro leva a discusses que terminam em quebra de contrato e prejuzo para ambas
1
Boa sorte e mos obra!
Caque Cardoso
l Ima tentativa de organizar o desenvolvimento foi a criao de um modelo estruturado e baseado
' i * in ii juagens como Cobol, Fortran, C entre outras. O desenvolvimento estruturado baseado no fluxo
iûo do sistema e nele difcil a mudana aps o incio da implementao. O uso de um
I MI u i i In nunto estruturado no natural, o que dificulta muito a mudana e, via de regra, o cliente muda
i i iiiiio muitas vezes depois do incio do desenvolvimento, principalmente porfalta de conhecimento
IH i n K:I -ssidades reais do sistema que deseja utilizar ou da dificuldade de priorizar o que realmente
H n| i. M lante para o sistema.
lompos mais tarde, e tentando fazer com que o desenvolvimento fosse mais prximo do mundo
H ii. loi desenvolvida a tcnica de desenvolvimento orientado a objetos, onde dados e operaes
sfti i armazenados em classes que possuem um comportamento claro. As principais linguagens so
.lava e C++. As tcnicas de desenvolvimento vm evoluindo muito nos ltimos anos, o que
immiitiu o desenvolvimento de novas tcnicas e, mais recentemente, a criao de uma linguagem
yirtllca chamada UML (Unified Modeling Language), que ser apresentada de uma forma prtica
tmnlo livro.
impossvel desenvolver um sistema que satisfaa a todas as necessidades de uma s vez,
r i n K ipalmente se essas necessidades vo surgindo enquanto se desenvolve.
importante estar preparado para administrar e gerenciar as necessidades do cliente. mais fcil
ti M um modelo que preveja as mudanas e incluso de requisitos do que tentar congelar as necessidai lus em um determinado momento, ou seja, no d para escolher e definir o que o cliente precisa.
Alm do cliente, temos um problema na outra ponta, ou seja, a equipe de desenvolvimento. Uma
nxpresso que ouvi faz algum tempo diz que o desenvolvedor de software discpulo de Ivonsaf.
Imaginei que fosse mais um desses "papas" da engenharia de software, mas no. a sigla para a
"irresistvel vontade de sair fazendo". Isto talvez seja uma caracterstica normal engenharia, principalI1 n mie a novas engenharias, como a engenharia de software, em funo da facilidade de se iniciar um

projeto (e neste campo as ferramentas e novas linguagens 'Visuais" fizeram um desservio tecnologia
de desenvolvimento, principalmente para pequenos grupos). A frase que mais se ouve : "No h tempo
a perder com projeto, precisamos iniciar a implementao." como fazer uma casa sem planta baixa:
a chance de dar errado muito grande.
O desenvolvimento de software nos ltimos anos passou a ser realizado praticamente em qualquer
parte do mundo em funo do barateamento dos computadores, principalmente de computadores
pessoais. A cada dia, o hardware est cada vez mais barato e potente, porm sem acrescentar algo de
novo, mais processamento, mais memria, sem que o desenvolvimento de novos produtos o acompanhe na mesma velocidade. O desenvolvimento de software necessita de uma engenharia, como no caso
de outras reas do conhecimento tcnico humano, de modo a facilitar o desenvolvimento rpido de novos
produtos, com qualidade e atendendo a um maior nmero de clientes com necessidades diferentes.
Tenho a convico de que o desenvolvimento de software uma atividade que demanda um
planejamento extremamente eficiente e que as pessoas no esto acostumadas a fazer.
No muito difcil de se aprender uma nova linguagem de programao, porm cada desenvolvedor
possui um mtodo de trabalho prprio, que foi desenvolvido durante a carreira e que totalmente
particular. Isto um dos maiores problemas no desenvolvimento em equipe. Unem-se vrios artistas
que acham que "meu jeito o melhor" e no se consegue padronizar o desenvolvimento. Algum sai da
equipe e ningum sabe como substitu-lo no trabalho.
1.2 A engenharia de software e o surgimento da UML

At o incio da dcada de noventa, pouco se dizia a respeito de engenharia de software. Alis, nem
este termo era muito utilizado, dando-se preferncia a termos como programao. Alguns, como Roger
S. Pressman, foram pioneiros em encarar o desenvolvimento de sistemas como engenharia, porm
com caractersticas muito particulares. Software considerado uma moeda que tem duas faces: ao
mesmo tempo um produto e um veculo que entrega um produto, como o caso dos programas que
esto em aparelhos celulares, por exemplo.
No incio da dcada de 90, viu-se o que ficou conhecido como a guerra dos mtodos, vrios "papas"
da recm-definida engenharia de software diziam que o seu mtodo era o melhor e que iriam resolver
todos os problemas. Infelizmente, as coisas no so to simples assim e, em meados da dcada,
decidiu-se que era mais prudente reunir o que houvesse de melhor em cada proposta e criar um modelo
nico. Foi assim que Jacobson, Booch e Rumbaugh criaram a UML (UnifiedModel Language), onde se
pretendia apresentar um modelo universal que servisse de sustentao ao desenvolvimento.
A UML inicialmente foi apresentada como um padro. Um dos fatores mais importantes para o uso
da UML foi o fato de existir uma terramenta, chamaTWs, desenvolvida pela Rational, uma empresa
composta pelos trs principais criadores da linguagem que ficaram conhecidos como "los trs amigos".
Em funo da aceitao do modelo por empresas como Digital, HP, l-Logix, Intelicorp, IBM, ICON,
MCI, Microsoft, Oracle, Rational, Texas e Unisys, que aderiram ao modelo, foi criada a verso 1.0 da
UML, padronizada pela OMG (Object Management Group) em janeiro de 1997. Entre janeiro e junho de
97, outras empresas, como Ericsson, Andersen e outras, passaram a fazer parte do grupo e, em
novembro de 97, foram aprovadas as revises na UML, gerando a verso 1.1. Em junho de 98, foi
lanada a verso 1.2 e em dezembro de 98, a verso 1.3, que a verso mais utilizada.
Introduo
A 11M l , apesar de baseada em estudos com mais de 10 anos, bastante recente, o que faz com
iii! iii cursos e profissionais ainda no tenham tido tempo de adquirir o conhecimento e as
i i i IML no dia a dia do desenvolvimento. A UML apresentada como um conjunto de
i
MKIS finalidades, porm sem nenhuma ligao ou sequncia definida pela linguagem, o
nlirita o processo de desenvolvimento.
2. ORIENTAO A OBJETOS
2.1 O que ?
Iciscnvolvimento de software sofreu evolues que marcaram os rumos e geraram correntes
i desenvolvimento estruturado, que ainda hoje utilizado, principalmente para sistemas emH lou, porm o desenvolvimento estruturado artificial, ou seja, o desenvolvimento estruturado
1 1 raciocnio do desenvolvedor. Cada caso um caso especfico, o que torna difcil a formao
.noas com o mesmo conhecimento e tcnica, enfim, que falem a mesma lngua e, conforme o
' 11.1 cresce, fica cada vez mais complicada a manuteno e a continuidade do desenvolvimento.
l ima das correntes mais importantes e que tem evoludo muito o desenvolvimento orientado a
';, que se apresenta de forma mais natural, onde as responsabilidades so divididas entre
< >:; que se relacionam e se comunicam. Para exemplificar, podemos imaginar o desenvolvimento
i software que simulasse uma agncia bancria simples. Em um projeto estruturado, definirailijumas estruturas como, por exemplo, cliente, caixa e conta, que iriam armazenar os dados e,
, i lusenvolveramos mtodos que manipulariam estes dados para executar funes como pai ilo, retirada, depsito etc. O sistema se comporta em um looping, onde os mtodos so chama11 uma determinada sequncia para executar as operaes necessrias.
l nla no a forma como uma agncia bancria funciona. As operaes no so sequenciais. As

1 1 1 iii n as como cliente, caixa ou conta, alm de dados podem e devem executar operaes.
l ni um sistema orientado a objetos, o cliente teria alm dos dados (nome, cpf, endereo etc)
i ' ",> 'i;s como, por exemplo: retirar dinheiro, pagar conta, depositar dinheiro etc, que so tpicas de
os clientes. J o caixa, alm de dados, realizaria operaes como: fazer pagamento, verificar
unido, transferir saldo etc. E o cliente teria um relacionamento com o caixa da agncia para executar s
ii|iumes. desta forma que uma agncia bancria funciona e desta forma que a modelagem
l, ida a objetos encara o sistema a ser desenvolvido. Caso quisssemos criar, por exemplo, um
i In ! ilo especial, deveramos atualizar somente o cliente e no seria necessrio alterar todo o programa,
nu noja, as informaes esto isoladas em cada parte.
Captulo 2 Orientao a objetos
2.3 Atributos e operaes

l In i conceito associado a uma classe ou a um objeto a propriedade ou um conjunto de propriedaii n i uma classe possui. Por exemplo, podemos associar a propriedade 'lazer mooo" classe vaca.
i
l; ido de uma classe em desenvolvimento de software pode ser dividida em duas partes:
Figura 2.1 - Relacionamento entre cliente e caixa.
Atributos: onde so armazenados os dados do objeto. Como no caso da classe vaca, pode -i 11| ilificar o nome, a idade, a produo mdia de leite, entre outras.
Operaes: o comportamento do objeto. Normalmente, o termo operao usado, porm,

is vezes, pode ser chamado de servio ou mtodo ou, ainda, atividade. Na classe vaca temos,
Kotnplo, as seguintes operaes: dar leite, pastar, ruminar, entre outras.
2.2 Classes, objetos e instncias

Objeto um conceito que existe no mundo real (existem objetos no mundo real), ou seja, objeto
tudo aquilo com que podemos nos relacionar ou que se relacionam entre si, de uma agulha a um
vaso, de uma nuvem a uma vaca, o mundo real repleto de objetos diferentes e com diferentes
formas de relacionamentos. Ento, podemos dizer que o mundo real orientado a objeto, e o fato
de utilizar uma metodologia de desenvolvimento que se aproxime do mundo real facilita muito a vida
dos desenvolvedores. O desenvolvimento de software orientado a objetos utiliza o mesmo conceito
do mundo real para simular o que ocorre no dia-a-dia quando um sistema est em execuo.
Outra caracterstica do desenvolvimento orientado a objetos e que tambm pertence ao mundo
real a definio do conceito de classe que representa um conjunto de objetos com caractersticas
similares. Quando se diz que uma vaca um objeto, na verdade estou me referindo classe vaca. J
que no foi identificada nenhuma vaca em particular, podemos ento dizer que a Mimosa, a Fartura e
a Malhada so objetos que pertencem classe vaca. Em modelagem orientada a objetos, dizemos
que um objeto uma instanciao de uma classe, ou seja, um objeto o que existe, de fato, enquanto
a classe um conceito abstrato. E podemos dizer que, apesar das vacas no serem idnticas, elas
possuem uma srie de caractersticas que nos permite associ-las classe vaca.
ily
A UML criou uma notao especfica para representar uma classe e podemos ver o exemplo a
. mn
Nome da classe
Vaca
Atributos
- m_sNome: string
- m_ildade: int
- m jjProducaoMediaDeLeita: double
+ Vaca()
+ produziLeiteQ: double
Operaes
+ pastarQ: void
+ ruminar(): void
Classe
Figura 2.3 - Modelagem da classe vaca.
i
bvio que a classe vaca real bem mais complexa que o nosso modelo, porm o modelo deve ser
ulldente para a representao da classe, do ponto de vista de desenvolvimento de software ou do que
a l irotende que o sistema faa.
Objetos
2.4 Relacionamentos
Mimosa
Fartura
Malhada
Figura 2.2 - Exemplo de classe e objeto (instanciao da classe).
Como foi dito anteriormente, os objetos se relacionam entre si e, como o que fazemos modelar os
i il i|otos, muito importante que os objetos possuam operaes que permitam o relacionamento. Imagino um objeto da classe fazendeiro que possui uma operao chamada retirar leite, que executado
i|iiando o fazendeiro se relaciona com o objeto da classe vaca, ou seja, importante que o modelo
contemple a operao produzir leite para a classe vaca, caso contrrio, este relacionamento no ser
possvel. A seguir so apresentados os principais relacionamentos entre classes.
Captulo 2 - Orientao a objetos
2.4.1 Herana
mjdade : int
Mamlero()
Uma classe pode possuir um relacionamento de herana com outra classe. Nestes casos, dizemos
que a classe "me" menos especializada, ou seja, mais genrica e a classe "filha" mais especializada..ste relacionamento conhecido como " um tipo", ou " do tipo"; por exemplo, "vaca um tipo de
mamfero"; portanto, podemos dizer que a classe vaca possui um relacionamento de herana com a
classe mamfero, ou tambm, que a classe vaca derivada da classe mamfero. A representao de
um relacionamento de herana feito atravs de uma seta que vai da classe filha para a classe me,
como mostrado na figura a seguir.
<Virtual produzleiteO : double
m_sNome : string
m_dProducaoMediaDeLeite : double
l.moO
mliinil .ll() : double
Vacaf)
Virtual produzLeite() : double
pastarf) : void
ruminar() : void
Mamfero
- m ildade: int
Figura 2.5 - Exemplo de composio e agregao entre classes.
+ MamiferoQ
+ Virtual produziLeiteQ: double
Vaca
.Irt uma dependncia quando uma classe depende de outra, porm isto ocorre esporadicamente
h n. u ilo a vida dos objetos. o exemplo da vaca e da vacina que ela recebe do veterinrio, ou o prprio
vnlwlnrio. Existe um relacionamento de dependncia entre a vaca e a vacina.
l -stes conceitos facilitam o desenvolvimento da modelagem, porm na maioria dos casos prticos,
n gorao do cdigo, que o que em ltima anlise estamos buscando, pode mudar pouco e isto ainda
IN n Io linguagem para linguagem, mas a compreenso do modelo fundamental para o desenvolvilo e comunicao entre os desenvolvedores. So os relacionamentos que iro determinar, a
i 'MM' ipio, as operaes que uma classe dever possuir para satisfazer ao relacionamento. Esta uma
ilmi lormas de se determinar quais operaes deveremos ter.
m_sNome: string
- m dProducaoMediaDeLeita: double
+ Vaca()
+ Virtual produziLeiteQ: double
+ pastarQ: void
,+ ruminarO : void
Figura 2.4 - Exemplo de herana entre classes.
2.4.3 Multiplicidade
No relacionamento entre duas classes existe uma determinada multiplicidade. Por exemplo, um
trt/ondeiro pode possuir vrias vacas, portanto o relacionamento chamado ordenhar, que est
uxi nnplificado na figura a seguir, do tipo "1 para muitos". A princpio no se pode definir de antemo
i |i imitas vacas um fazendeiro ter que ordenhar, ento deixamos o relacionamento em relao vaca
com o smbolo "*" (que a notao de UML para muitos) e do lado do fazendeiro "1" que est em
iloslaque na figura a seguir. Existem outros relacionamentos possveis (todo fazendeiro tambm
mnmfero, por exemplo), mas que no so relevantes para o modelo. Devemos nos concentrar no
ci nnportamento que cada objeto deve ter para atender s necessidades do sistema.
2.4.2 Agregao, composio e dependncia

Outras formas de relacionamento so agregao, composio ou dependncia. Estes relacionamentos so semelhantes, diferenciando em relao intensidade. Um relacionamento de composio
existe quando uma classe composta por outra, de tal forma que a parte que compe no existe, se no
existir o todo, ou seja, "a parte no vive sem o todo"; o caso, por exemplo, de uma vaca ser composta
por chifres, cascos, rabo, bere, entre outras coisas e se retirarmos algumas destas partes, elas no
fazem sentido sem o todo.
A agregao semelhante, porm a parte vive sem o todo, ou seja, se no existir o todo, a parte
continuar existindo. o caso da vaca e o fazendeiro. Existe um relacionamento de agregao entre o
fazendeiro e a vaca.
Fazendeiro
- rrLsNome strinq
f FazendeiroQ
- retirarLeiteQ: double
Ordenhar
Vaca
- m_sNome: string
- m_dProducaoMediaDeLeite: double
O + Vaca()
+Virtual produzLeite(): double

+ pastarQ: void
ruminarQ: void
Captulo 2 - Orientao a objetos
10
2.5 Polimorfismo
Polimorfismo uma das caractersticas mais potentes da orientao a objetos. Polimorfismo a

propriedade que indica que uma operao pode^ apesar de ter o mesmo nome,'executar aes diferentes. Existem dois tipos de polimorfismo: o esttico e o dinmico.
- iX:int
2.5.1 Polimorfismo esttico
- iA:int
Este conceito no de simples compreenso e vou mais uma vez vamos lanar mo de um
exemplo para explicar. Imaginemos uma classe chamada Data que armazena os dados de dia, ms e
ano, alm de hora, minuto e segundo, como mostrado a seguir.
+ Desenhar():void
11
FormaGeomtrica
- iY:int
-iLint
Figura 2.8 - Exemplo de classe abstraia.

Data
iDia:int
iMes:int
iAno:int
Esta classe possui uma operao chamada Desenhar, porm, como desenhar uma forma geom.') no sabemos exatamente como ela ? Esta operao chamada de operao abstraia (o que
>m que a classe FormaGeomtrica seja chamada de classe abstraa), ou seja, serve como
i icia, porm no implementada; a implementao fica a cargo da classe filha (classe derivada),
... P u i representado na figura a seguir.
iMinuto:int
iSegundo:int
AjustaData(Data:string):void
AjustaData(iDia:int, iMes:int, iAno:int):void
FormaGeomtrica
- iX:mt
- iY:int
Figura 2.7 - Exemplo de polimorfismo esttico.
-iLint
- iA:int
Ao chamar a operao AjustaData, a operao exata que ir ser executada depender dos
parmetros que so passados, ou seja:
Se utilizarmos AjustaData ("15/09/2001"), ser executada a primeira operao.
Se utilizarmos AjustaData (15,9,2001), ser executada a segunda operao.
E a classe que se relaciona com a classe Data no necessita saber os detalhes da operao
AjustaData, deve simplesmente usar a que melhor lhe convier.
A vantagem disso que a classe pode atender a vrios usurios da classe e cada um pode
"enxerg-la" de maneira diferente. Os objetos do mundo real tambm executam as mesmas atividades,
porm com formas de atender diferentes usurios, dependendo da forma como e quais "parmetros"
so passados.
2.5.2 Polimorfismo dinmico

Uma outra forma de polimorfismo o dinmico. Vamos mais uma vez utilizar um exemplo, imaginemos a classe FormaGeomtrica, que esta apresentada a seguir.
+ Desenhar():void
Retngulo
+ Desenhar():void
Crculo
+ Desenhar():void
Figura 2.9 - Exemplo de polimorfismo dinmico.
12
Imagine que temos dois objetos (ou instanciao da classe) Retngulo e Crculo e o ponteiro para
FormaGeomtrica:
Retngulo R;
Crculo C;
FormaGeomtrica "pFG;
U. CAPTURANDO REQUISITOS
Tem-se o seguinte cdigo:
void DesenharQ
{
pFG = &R;//Oponteiro aponta para o objeto retngulo.
pFG->Desenhar();// desenhado um retngulo.
pFG = &C;//Oponteiro aponta para o objeto crculo.
pFG->Desenhar();// desenhado um crculo.
Podemos observar que simplesmente chamada a operao Desenhar de um objeto abstraio

FormaGeomtrica e o objeto aponta para a operao Desenhar correia.
3.1 Requisitos do cliente X classes de projeto ou do

problema ao sistema
A mula da modelagem desenvolver o diagrama de classes de projeto, ou seja, desenvolver toda
> i i i u li 'l; M jom onde ser desenvolvido o cdigo que executar as funes do sistema. O diagrama de
.de projeto composto pelas classes com seus atributos e operaes e pelo relacionamento
i ilas. O processo de desenvolvimento deve ser feito por incrementos. O que veremos deste
um diante como adquirires requisitos (ou necessidades do cliente, "g problema") e caminhar
classes de projeto implementadas e testadas ("o sistema"). Como o processo incremental, ao
lo primeiro incremento gera-se parte do cdigo e inicia-se novamente o processo para os
iiny que no foram trabalhados, caminhando-se novamente pela sequncia de atividades e
unas que sero apresentados, e assim repetindo para cada incremento. A essa forma de
.i ilho chamamos de Modelo Prtico para Desenvolvimento de Software, ou Practical Software
llfVt /< >i>ment Modeling, PRISM.
3.2 Como capturar os requisitos?

l li iquisito o nome dado a todo tipo de necessidade que se identifica para um sistema e normal"" i IN i obtido atravs de entrevistas com os clientes ou algum que conhea a necessidade dos
II HiOS.
A (ibteno dos requisitos no uma atividade trivial, uma vez que quem os fornecer muitas vezes
Min i :;;ibe exatamente como o sistema dever funcionar, ou seja, sabe qual o problema, mas no tem
li li i M lo como a soluo e por essas e outras razes que se deve dedicar uma ateno muito grande
>l>ter os requisitos. , normalmente, durante a obteno dos requisitos que os responsveis pelo
nvolvimento interagem com os problemas e necessidades do cliente e acabam conhecendo e
'i !' ! idcndo sobre o negcio no qual o sistema estar envolvido, o que fundamental.
O responsvel pelo desenvolvimento deve ser capaz e estar disposto.a mergulhar o mais profundo
pimtifvel nos problemas do cliente, j que muito mais difcil o cliente analisar do ponto de vista de
i Imionvolvimento de software. No se deve deixar nenhum tipo de requisito de fora do levantamento, por
mui que parea impossvel de realiz-lo no momento. Esta avaliao deve ser feita em um outro
11 n n i icnto e nestes casos deve ser negociado para que estes requisitos se transformem em requisitos
14
futuros, bvio que isto s possvel, caso estes requisitos no sejam prioritrios. Nesses casos,
deve-se deixar claro que este requisito ter urTimpacto muito grande no desenvolvimento do projeto,
devendo ter grande influncia no prazo de entregado sistema. .
Uma forma de facilitar a especificao dos requisitos dividi-los nos seguintes tipos:
Requisito funcional (F)

Um requisito que especifica uma ao que o sistemajtever ser capaz de realizar, sem levar em
considerao restries fsicas como, por exemplo, um requisito que especifica o comportamento das
" entradas e sadas do sistema.
Requisito de dado (D)

Requisitos que se referem estrutura esttica do software. Esses requisitos podem ser atributos
simples ou aqueles quejraffirjilarjjrniase.de dados lgjca Para este ltimo tipo, na fase de
elaborao, devero possuir especificaes do tipo: tigo.de informaes usadas por vrias funes,
frequncia de uso, capacidade de acesso, entidades e relacionamentos, restries de integridade e
requisitos de reteno de dados.
Requisito de interface (l)

Requisito que se refere a interfaces de cliente e tambm a outros sistemas de software ou de
Hardware e de comunicao. Na fase de elaborao, esses atributos devero ser especificados mais
detalhadamente, incluindo: interface do cliente (formato de tela, formato de relatrios, estruturas de
menus, funes de teclas, etc.), interfaces do software (outros produtos de software requeridos, tais
como DBMS, Browser Web, sistemas operacionais e interfaces com outros sistemas de aplicao,
indicando nome, verso e fabricante, .incluindo definies do comportamento de cada uma delas e
interfaces de comunicao com protocolo e formatos).
Requisito no-funcional (N)

Requisito no-funcional ou requisito especial pode incluir requisitos legais ou referentes a algum
regulamento, a aplicao de padres e tambm os atributos de qualidade do sistema a ser construdo.
Adicionalmente, outros requisitos, tais como: o sistema operacional a ser utilizado, requisitos de compatibilidade e restries de projeto, tambm devero ser capturados nesse item.
Uma forma interessante para identificar os requisitos utilizar a seguinte definio:
ER[f i a][Fi D111 N] [XXXX]. N onde ER significa Especificao de Requisitos
[fia] significa requisito futuro ou atual
FiDiliN apresenta em qual tipo de requisito esta associado
XXXX o nmero ou sigla do projeto que o requisito esta associado
N o nmero sequencial de requisitos do projeto
Captulo 3 - Capturando requisitos
15
3.3 Os riscos e prioridades associados a requisitos

l IIMII ntividade muito importante na Especificao de Requisitos determinar qual prioridade o
' i ir.socia a cada um dos requisitos levantados. Em geral o cliente tem a tendncia de dizer que
> i. . i m requisitos so de altssima prioridade, porm isto nem sempre verdade. Esta negociao
importante e uma atividade muito subjetiva e difcil de ser conduzida por pessoas extremamente
ir., ni.. r., c nesse momento que o papel de gerncia de desenvolvimento de software entra em cena,
i iode dizer sim a tudo que o cliente pede, deve-se ser bastante claro ao mostrar as dificuldades
ilmui desenvolver um sistema. As prioridades iro facilitar na conduo do projeto e em que atividades
11 "ulizadas e a que tempo. Os nveis de prioridade podem ser divididos da seguinte forma:
Altssima
Alta
Mdia
Baixa
Baixssima
A i loterminao do conjunto Prioridade/Risco (P/R) ir orientar o desenvolvimento, ou seja, assim

ijiio possvel deve-se baixar o nvel dos riscos associados aos requisitos de maior prioridade.
llniti das maneiras de se fazer isto o desenvolvimento de prottipos que possam permitir que o
M reduzido ou negociar com o cliente uma nova forma de atender ao requisito. importante
lo ocorra/durante o incio do projeto,p modo que todos os riscos estejam no nvel baixo ou
.uno antes da fase de construo.
l )ove-se ter em mente que o sucesso do projeto se baseia em levantar e especificar, da forma mais
(iincisa possvel, os requisitos e, em seguida, determinar uma estratgia que permita no prazo mais
. .n 1.1 possvel reduzir o nvel dos riscos associados aos requisitos.
3.4 Gerenciamento de requisitos

O gerenciamento de requisitos uma atividade que permite monitorar as necessidades apresenpelo cliente e o andamento da soluo destas necessidades do ponto de vista de projeto.
n i >i" pssvel congelar os requisitos do cliente, uma vez que a cada passo e conforme o sistema vai
11.1< i construdo vai tambm se tornando mais claro como o sistema deve funcionar e que caracteis tecnolgicas o sistema deve ter. Assim, o cliente vai sentindo a necessidade de novos
ss a serem implementados. Este livro no trata de um processo de desenvolvimento do ponto
11.1 vi%ta gerencial, porm importante salientar a necessidade de se controlar todos os requisitos
nnuociados ao sistema, sejam eles oriundos do cliente ou determinados pelo arquiteto do sistema.
!' iimdamental importncia que se possa rastrear os requisitos, de modo a medir o quanto um
i minado requisito (que pode surgir a qualquer momento) ir criar um impacto no prazo final do
i M . ,|( >io. A documentao, identificao e anlise de risco associado ao requisito servem de base para
B yorncia de requisitos, a fim de minorar os problemas quanto mudana de requisitos. Este trabalho
fundamental, pois um erro neste ponto ir se propagar durante o projeto e gerar um srie de
pioblemas que, na maioria das vezes, leva ao cancelamento do projeto e ao reprojeto em novas
IMBOS, o que sempre desastroso, caro e desgastante tanto para o cliente quanto para a equipe.
Captulo 3 Capturando requisitos
16
Descrio do risco
3.5 Exemplo de requisitos

Para facilitar a compreenso de como devem ser especificados os requisitos de um sistema,
vamos exemplificar utilizando alguns dos requisitos necessrios para desenvolvimento de um caixa
eletrnico de banco. A seguir so apresentados alguns requisitos para demonstrar como so avaliados
Risco
A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer
as informaes a respeito das contas do usurio.
e descritos.
17
Prioridade
Baixo.
Mdia.
Tabela 3 - Risco do requisito Emitir extrato com

saldo da contra e extrato completo por perodo.
3.5.1 ERaF0001.1 - Sacar dinheiro

O sistema dever permitir que usurio saque dinheiro do caixa eletrnico. Esta atividade responsvel pelo ciclo que se inicia quando o usurio solicita o saque de dinheiro e se encerra, no fluxo timo,
quando o usurio recebe em dinheiro o valor solicitado e o documento de comprovao de saque.
Risco
Descrio do risco
Prioridade
Altssima.
Altssimo.
Tabela 1 - Risco do requisito Sacar dinheiro.
A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio.
Descrio do risco
Risco
A implementao conhecida. Existe pessoal disponvel

para o desenvolvimento e o prazo para desenvolvimento
razovel.
Prioridade
Mdio.
Alta.
3.5.5 ERaF0001.5 - Instruo fcil para uso de qualquer opo

do caixa eletrnico
O sistema dever permitir movimentar valores entre contas do mesmo usurio.
Risco
O sistema dever permitir apresentar propaganda dos produtos do banco quando o sistema de
caixa eletrnico no estiver em uso.
Tabela 4 - Risco do requisito Propaganda dos produtos do banco.
3.5.2 ERaF0001.2 - Movimentar valores entre contas
Descrio do risco
Prioridade
Altssimo.
O sistema~dever permitir que a qualquer momento do uso de uma opo (servio) do caixa
eletrnico, o usurio possa ser auxiliado no uso e nas informaes que esto sendo solicitadas.
Altssima.
Tabela 2 - Risco do requisito Movimentar valores entre contas.
3.5.3 ERaF0001.3 - Emitir extrato com saldo da conta e extrato

completo por perodo
O sistema dever permitir emitir extrato com o saldo da conta selecionada pela usurio ou emitir
extrato com dados completos de crdito e dbito por perodo no maior que 3 meses anteriores data
atual configurada pelo usurio.
Descrio do risco
Risco
A implementao no totalmente conhecida. Existe pessoal disponvel para o desenvolvimento e o prazo para
desenvolvimento razovel.
Prioridade
Baixo.
Alta.
Tabela 5 - Risco do requisito Instruo fcil para

o uso de qualquer opo do caixa eletrnico.
3.5.6 ERaF0001.6 - Informao ao usurio do no-funcionamento

do caixa eletrnico
O sistema dever permitir que em caso de falta de dinheiro, falta de comunicao com o sistema
contrai ou qualquer outra falha o usurio seja informado.
Captulo 3 Capturando requisitos
16
Descrio do risco
3.5 Exemplo de requisitos

Para facilitar a compreenso de como devem ser especificados os requisitos de um sistema,
vamos exemplificar utilizando alguns dos requisitos necessrios para desenvolvimento de um caixa
eletrnico de banco. A seguir so apresentados alguns requisitos para demonstrar como so avaliados
Risco
e descritos.
17
Prioridade
Baixo.
Mdia.
Tabela 3 - Risco do requisito Emitir extrato com

saldo da contra e extrato completo por perodo.
3.5.1 ERaF0001.1 - Sacar dinheiro

O sistema dever permitir que usurio saque dinheiro do caixa eletrnico. Esta atividade responsvel pelo ciclo que se inicia quando o usurio solicita o saque de dinheiro e se encerra, no fluxo timo,
quando o usurio recebe em dinheiro o valor solicitado e o documento de comprovao de saque.
Risco
Descrio do risco
Prioridade
Altssima.
Altssimo.
Tabela 1 - Risco do requisito Sacar dinheiro.
A implementao depende da definio da forma de comunicao entre o caixa e o sistema servidor que fornecer as informaes a respeito das contas do usurio.
Descrio do risco
Risco
A implementao conhecida. Existe pessoal disponvel

para o desenvolvimento e o prazo para desenvolvimento
razovel.
Prioridade
Mdio.
Alta.
3.5.5 ERaFOOOl .5 - Instruo fcil para uso de qualquer opo

do caixa eletrnico
O sistema dever permitir movimentar valores entre contas do mesmo usurio.
Risco
O sistema dever permitir apresentar propaganda dos produtos do banco quando o sistema de
caixa eletrnico no estiver em uso.
Tabela 4 - Risco do requisito Propaganda dos produtos do banco.
3.5.2 ERaFOOOl .2 - Movimentar valores entre contas
Descrio do risco
Prioridade
Altssimo.
O sistema~dever permitir que a qualquer momento do uso de uma opo (servio) do caixa
oletrnico, o usurio possa ser auxiliado no uso e nas informaes que esto sendo solicitadas.
Altssima.
Tabela 2 - Risco do requisito Movimentar valores entre contas.
3.5.3 ERaFOOOl .3 - Emitir extrato com saldo da conta e extrato

completo por perodo
O sistema dever permitir emitir extrato com o saldo da conta selecionada pela usurio ou emitir
extrato com dados completos de crdito e dbito por perodo no maior que 3 meses anteriores data
atual configurada pelo usurio.
Descrio do risco
Risco
A implementao no totalmente conhecida. Existe pessoal disponvel para o desenvolvimento e o prazo para
desenvolvimento razovel.
Prioridade
Baixo.
Alta.
Tabela 5 - Risco do requisito Instruo fcil para

o uso de qualquer opo do caixa eletrnico.
3.5.6 ERaFOOOl .6 - Informao ao usurio do no-funcionamento

do caixa eletrnico
O sistema dever permitir que em caso de falta de dinheiro, falta de comunicao com o sistema
contrai ou qualquer outra falha o usurio seja informado.
18
Descrio do risco
Risco
A implementao totalmente conhecida. Existe pessoal

disponvel para o desenvolvimento e o prazo para desenvolvimento razovel.
Prioridade
Baixo.
Alta.
Tabela 6 - Risco do requisito Informao ao usurio

do no-funcionamento do caixa eletrnico.
3.6 Avaliao
Os requisitos apresentados so alguns exemplos de requisitos para o desenvolvimento de um
sistema de caixa eletrnico e, neste caso, esto colocados somente os requisitos funcionais. Os
requisitos apresentados tm nveis diferentes de risco. O modelo apresentado neste livro (PRISM)
indica que devemos avaliar os requisitos de mais alto risco e eliminar o risco o mais rpido possvel. Por
exemplo, para o requisito ERaFOOO! .1 - Sacar dinheiro, deve-se desenvolver prottipos ainda na fase
de levantamento e especificao de requisitos e negociar com o cliente qual a melhor soluo encontrada para atender ao requisito antes de iniciar a fase de implementao do sistema (note que o risco deste
requisito est associado a outros requisitos). Alm dos requisitos de alto risco, deve-se desenvolver
prottipos de interface, ou seja, janelas de interface com o usurio para que possa ser avaliada pelo
cliente como uma prvia do produto final.
4. COMO TRANSFORMAR REQUISITOS EM

USE CASES
Uma vez especificados os requisitos (vale salientar que no necessrio obter e especificar todos
os requisitos do sistema, pode-se iniciar a determinao de use case em funo da estratgia de
desenvolvimento) inicia-se o processo de especificao de use case que foi introduzido por Ivar
Jacobson e que veremos com mais detalhes neste captulo.
4.1 Afores
Um ator qualquer pessoa ou sistema externo (SE) que tenha interao com o sistema que est em
desenvolvimento; o nome ideal seria papel e no ator, pois isto tem confundido alguns projetistas que
acabam identificando somente as pessoas que acessam o sistema e no levam em considerao que
outros SEs podem e devem ser representados como ator. Alm do nome, foi definido para a UML um
smbolo que ajuda nesta associao com pessoas interagindo com o sistema, como mostrado na figura
u seguir.
Figura 4.1 - Smbolo associado ao ator na UML.
A identificao dos atores o primeiro passo para a criao de use cases, pois um ator representa
uma classe fora do sistema que se envolve de alguma forma com o mesmo. O uso do conceito classe
t'i Importante porque o ator no um objeto, ou seja, no uma pessoa (ou SE) em particular que ir
ulllizar o sistema, sim o papel que essa pessoa (ou SE) especfica ou conjunto de pessoas represenli ti n para o sistema.
Um ator pode ser representado atravs de um diagrama de especializao (ou generalizao)
mino utilizamos com classes. A figura a seguir representa um diagrama de atores com relacionamento do especializao. Neste exemplo, estamos identificando alguns dos possveis atores do caixa
Captulo 4 Como transformar requisitos em use cases
20
MM identificarmos os atores do sistema, devemos iniciar a identificao das use case, de modo
.lorrnar os requisitos do sistema passado pelo cliente em algo que possa ser entendido pelo
< ilvodor. Esta passagem representa o elo de ligao entre o processo de desenvolvimento e
T.sidades do cliente. A identificao das use cases baseada nos requisitos no uma atividai.il, uma vez que cada sistema necessariamente diferente do outro, porm representa um
i do ponto de vista do processo de desenvolvimento, pois qualquer identificao, por mais
1.1 que seja, melhor do que nenhuma e, como o processo de desenvolvimento incremental,
M, o analista ter oportunidade de passar outras vezes por este trabalho, existe sempre a
i! iilidnde de se corrigir e aprofundar o detalhamento das use cases.
eletrnico de banco. Um ator o cliente do banco, porm temos neste caso trs tipos diferentes de
atores que derivam do ator genrico cliente de banco. So eles:
Cliente VIP
Cliente Especial
Cliente Padro
Estes clientes possuem papis comuns, porm em funo da forma de atendimento, existem
caractersticas que so especficas para cada tipo de cliente do banco e, por consequncia, do
caixa eletrnico.
21
i ii a idi Mitificarmos uma use case, devemos seguir estes passos:

l
Analisar e agrupar todos os requisitos do ponto de vista das funcionalidades (requisitos funcionais) do sistema a ser desenvolvido. Ou seja, imagine um ciclo completo de uso do sistema e
i lotermine quais requisitos esto associados a este ciclo.
l, Uma vez agrupados, determine quais atores interagem com este ciclo de uso.
I. Descreva o fluxo timo para este ciclo, ou seja, o fluxo onde nada de errado acontece e a
ontrada do ator levar ao resultado final sem erros ou problema.
Cliente do banco
4. Descreva os fluxos alternativos ou de exceo para este ciclo, ou seja, quando e onde algo
pode dar errado.
I.
Cliente VIP
/\e padro
Cliente especial
Figura 4.2 - Diagrama de especializao (generalizao) de atores.
O primeiro passo para identificar os atores realizado entre o analista e o cliente, que identificam os
usurios e os organizam em categorias (classes) de atores. Dois critrios so importantes para identificar um ator:
Deve ser possvel identificar pelo menos um usurio que represente o ator candidakvpois
isto ajuda a encontrar somente os atores relevantes e ignorar os atores imaginrios.
Deve existir um mnimo de sobreposio de papis entre os diferentes atores que se relacionam com o sistema. No devem existir dois atores com papis semelhantes em relao ao ,
sistema. Se isto ocorrer, devemos combin-los em um ator ou tentar utilizar a generalizao.
O analista, aps identificar os atores, deve dar um nome e fazer uma breve descrio dos papis
de cada ator no sistema., muito importante definir nomes que representem o maior nmero de papis
'de um determinado ator. Isto ir facilitar a identificao.
Use case
f
Uma use case pode ser definida como:
|
_JJm conjunto de funcionalidades de um sistema, representado por fluxos de eventos
l iniciados por um ator e apresentando um resultado de valor a um ator.
Caso o fluxo seja complexo, por exemplo, existe mais de um fluxo timo, necessrio
desenvolver um diagrama de atividades para este ciclo. Sempre que possvel interessante gerar um diagrama de atividades para demonstrar o fluxo de eventos graficamente.
, Partes de uma use case podem aparecer em outras use cases. Por exemplo, a use case para
Identificar o login do usurio analisando nome e senha. Desta forma, interessante dividir a use
case em partes para no repetir a descrio. Existem trs tipos de relacionamento entre use
cases, que so:
1. Herana: equivalente herana entre classes ou atores. As use cases podem
herdar o comportamento da use case da qual deriva.
2. Incluso: a use case que includa sempre executada, ou seja, o fluxo de eventos
desta use case sempre acessado.
3. Extenso: a use case estende o comportamento da use case, sendo que o fluxo de
eventos da use case pode ou no ser acessado.
() desenvolvimento dos seis itens apresentados representa os passos para a criao de uma use
i importante ao final da criao de cada use case reunir-se com o cliente no sentido de discutir se
i' M analisado est de acordo com as necessidades. As use cases e os prottipos, como as janelas
i iniorface com o usurio, fazem parte da primeira viso do cliente sobre o produto final e tm
IMI| i. MiAncia fundamental no desenvolvimento do projeto. No se deve tentar detalhar todas as use
.. M > n lusmo tempo. Da mesma forma que foi feito para os requisitos, deve-se determinar qual use
DAM fundamental para o incio do desenvolvimento do sistema e detalh-la ao mximo na primeira
(n A determinao de quais use cases sero trabalhadas deve ser feita pelo arquiteto do sistema,
p M M li >vo possuir uma viso completa do sistema que ser desenvolvido e que ir basear a avaliao
uiridades e riscos que iro compor a use case.
22
Considerando os atores do caixa eletrnicos, sabemos que uma use case Sacar dinheiro, portanto podemos descrev-la da seguinte forma:
'"" i-(:obidas
Aes realizadas
6. Volta ao ponto 3 do fluxo timo.
Breve descrio: esta use case responsvel pelo ciclo que se inicia quando o usurio solicita ao
caixa eletrnico o saque de dinheiro e se encerra, no fluxo timo, quando o usurio recebe o dinheiro e
o documento de saque.
Senha incorreta
Pre-condio: o usurio solicitar o saque de dinheiro.
AÔim recebidas
Aes realizadas
Incio da use case: esta use case inicia quando o usurio solicita o saque de dinheiro do caixa
1, A lonha digitada pelo usurio.
2. Avalia a senha.
3. Verifica que a senha no vlida e solicita
que o usurio digite novamente a senha.
eletrnico.
Fluxo timo
6. Solicita a senha.
10. A quantia digitada pelo usurio.
4. Volta ao ponto 7 do fluxo timo e aps a terceira tentativa, o sistema informa que no poder mais executar qualquer operao com
este carto por um prazo de 24 horas.
Aes realizadas
2. 0 terminal pede que ele passe o carto.

1 . 0 usurio solicita o saque de dinheiro.
4.
0 terminal l os dados do carto.
3. 0 usurio passa o carto solicitado pelo terminal.
5. Verifica se o carto vlido.
7. A senha digitada pelo usurio.
(continuao)
5. Pede ao usurio que passe o carto novamente e mostra isto graficamente.
Use case Sacar dinheiro
Aes recebidas
23
Saldo insuficiente
AyOo recebidas
A quantia digitada pelo usurio.
Aes realizadas
8. Avalia a senha.
2. verificada a quantia de recursos na conta]

do usurio.
9. Solicita que o usurio entre com a quantia

a ser sacada.
3. No h recursos suficientes para a finalizao)

do saque.
1 1 . E verificada a quantia de recursos na

conta do usurio.
4. solicitado um novo valor de acordo com o

saldo do usurio.
12. feita a impresso do recibo de saque.
5. Volta ao ponto 10 do fluxo timo.
1 3. liberado o valor solicitado.

14. 0 sistema volta ao estado inicial para a
execuo de outros servios para o mesmo ou para outros usurios.
Fluxos alternativos
Carto invlido ou passado de forma incorreta pelo leitor
Aes recebidas
Aes realizadas
1 . 0 usurio passa o carto solicitado pelo terminal.2. 0 terminal l os dados do carto.

3. Verifica se o carto vlido.
4.Determna que o carto invalido.
A ligura a seguir apresenta o mesmo fluxo de eventos, porm na forma de um diagrama de

ii ls, onde todos os fluxos so mostrados de uma forma nica.
24
25
4.3 Diagrama de use case

A llm de complementar a use case, a UML definiu um diagrama que apresenta uma elipse com o
i MH o o relacionamento com os atores do sistema. O diagrama de use case no substitui a descrio
n fluxos de eventos e da prpria use case, porm permite apresentar o relacionamento entre atores
wn case e ainda permite dividi-la.
Incio do fluxo Sacar Dinheiro
O usurio solicita o
\e de dinheiro
O terminal pede que

ele passe o carto
/'
O usurio passa o carto
V.
solicitado pelo terminal
O terminal l os
Cliente do banco
\s do carto
Sistema central
Figura 4.4 - Exemplo de diagrama de use case.
Observaes:
Pura a use case "Sacar dinheiro" existem mais trs atores:
Pede ao usurio que passe o carto

novamente e mostra isso graficamente
Informa que a senha
A senha digitada
incorreta
pelo usurio
Impressora, que responsvel por imprimir o recibo de retirada de dinheiro.
Equipamento de liberao de dinheiro, que responsvel, como o prprio nome diz, pela
liberao das notas correspondentes ao valor solicitado pelo usurio.
Equipamento leitor de carto magntico.
l iilos atores no sero modelados para facilitar didaticamente a compreenso do modelo.
Informa que o carto no ser

mais aceito por 24 horas
Solicita que o usurio que entre

com a quantia a ser sacada
Sada por Erro na digitao da

senha
A criao de use case de derivao ou incluso permite fragmentar uma use case e deve ser feito
luas situaes:
A quantia digitada
O fluxo de eventos utilizado por outras use case ou

O fluxo de eventos muito complexo e ir dificultar o detalhamento em uma nica use case.
pelo usurio
Como j foi dito anteriormente, alm da derivao, as use cases podem ser divididas por incluso
i iso que sero detalhados a seguir.
/ solicitado ao usurio um valor inferior ao

solicitado acordo com o saldo
feita a impresso
do recibo de saque
\4t\m do fluxo
Figura 4.3 - Exemplo do uso de diagrama de atividades para use case.
4.3.1 Incluso
A Incluso representa um fluxo de eventos que se repete em outras use cases. Desta forma,
|iimnlvol criar a use case uma nica vez e inclu-la nas outras que tenham o mesmo fluxo de eventos.
M 1 1 - ii iola de fluxo de eventos, quando for necessrio citar o fluxo, deve-se colocar o texto: incluir a
u i i .i:;o [Nome da use case]. Um exemplo o fluxo de eventos que avalia a senha do usurio do
nnlxn oletrnico. Esta use case ser utilizada por outras use cases do sistema e sempre ser
iiocirnsrio execut-la.
26
Captulo 4 - Como transformar requisitos em use cases
Sacar dinheiro
Sacar dinheiro
Cliente do banco
-fi
/
Cliente do banco
Sistema central
Sistema central
extend
include
\o insuficiente
Validar usurio
Figura 4.5 - Use case includa.
Figura 4.6 - Use case estendida.
Desta forma, o fluxo de eventos de "Verificar senha" ser independente da use case "Saca
dinheiro", porm includo nesta e se chama "Validar usurio".
Use case Saldo insuficiente
AyOo recebidas
Use case Validar usurio
Aes realizadas
i i K \\ recursos suficientes para a finalizao

llll ..l.|IIO.
Aes recebidas
Aes realizadas
1.0 usurio inicia um servio do sistema.
2. A senha solicitada.
3. A senha digitada pelo usurio.
4. Avalia a senha. Se vlida, encerra com resposta afirmativa.
ii >va quantia digitada pelo usurio.
4. verificada a quantia de recursos na conta

do usurio.
5. Se valor correio, retorna com resposta posi tiva, seno...
6. Volta ao passo 2 do fluxo.
5. Verifica que a senha no vlida e solicita qu>

o usurio digite novamente a senha.
6. Volta ao ponto 2 deste fluxo e aps a terceiro
tentativa, o sistema informa que no poderc
mais executar qualquer operao com est
carto por um prazo de 24 horas.
4.3.2 Extenso
2. solicitado ao usurio um valor inferior ao

digitado de acordo com o seu saldo.
4,3.3 Derivao
A dnrivao entre use case semelhante derivao em classes, ou seja, a use case filha
.IB propriedades da use case me. Para exemplificar, imagine que tenhamos dois tipos de
u i do usurio. Uma seria atravs da senha e outra atravs de identificao das impresses
- i l < > usurio. Neste caso, temos a use case "Validar usurio" dividida em duas, como mostrain|uraaseguir.
Quando um fluxo de eventos faz parte de uma use case, mas nem sempre este fluxo executado,!
pode-se retir-lo da use case e coloc-lo como uma extenso da use case. Como ocorre para incluso,!
deve-se quebrar a use case, caso o fluxo de eventos se repita em outra(s) use case(s). Um exemplo!
seria a use case Saldo insuficiente, que no executada quando existe saldo na conta do usurio, j
Validar usurio
Verificar senha
Verificar impresso digital
Figura 4.7 - Derivao entre use cases.
28
4.4 Avaliao
A anlise dos requisitos e transformao em use case um passo muito importante, porque i
o ltimo contato do cliente com o sistema at que se inicie o desenvolvimento, por isso deve sei
discutido com o cliente e revisitado sempre que alguma dvida a respeito do sistema surgir!
Lembre-se que o fluxo de eventos que representa, na forma de tabela, um conjunto de requisitoaf
do cliente; portanto, pea que seja avaliado com o mximo critrio possvel. A subdiviso da usd
case depende do nvel de complexidade e deve ser avaliada quanto e se deve ser feita. A figura i
seguir mostra o diagrama completo da use case "Sacar dinheiro".
6. CLASSES DE ANLISE
r 1 Definio
Sacar dinheiro
Cliente do banco
fl
^ Sistema central
/ . , . \
/mclude\
Validar usurio
Verificar impresso digital
Saldo insuficiente
Verificar senha
Figura 4.8 - Exemplo de fragmentao de use case.
'i a definio das use caseque atendem aos requisitos funcionais do cliente, o passo seguinte
i nu iiar a use case em classes de anlise. Classes de anlise representam uma abstrao de uma
"i classes de projeto e/ou subsistemas. As classes de anlise possuem as seguintes caracters M "liminares:
As classes de anlise representam o comportamento relacionado aos requisitos funcionais no
Inicio da anlise e vo adquirindo novas funcionalidades com a sequncia do projeto.
l
As classes de anlise raramente possuem operaes ou argumentos (que so caractersticos

das classes de projeto). O comportamento da classe definido sem se preocupar com os detalhes, ou seja, a responsabilidade e o comportamento da classe deve ser descrita na forma de
texto.
Um comportamento muito importante das classes de anlise o relacionamento com as outras

classes. Estes relacionamentos iro gerar no futuro as operaes que definem o comportamento da classe.
As classes de anlise podem definir atributos, porm estes atributos so sempre conceituais,
ou seja, no feito o detalhamento.
Observao: os outros requisitos no foram modelados neste exemplo.

uactersticas das classes de anlise so mutantes, ou seja, conforme se evolui na anlise
mho do projeto sero agregadas mais informaes at que em um determinado ponto a
IM io anlise se torne uma ou mais classes de projeto.
i < nu as classes de anlise, inicia-se o processo de distribuio do comportamento da use case
's. Na primeira avaliao da use case, provavelmente ir se chegar a um nmero de
'! de anlise pequeno, que representa de forma macro o comportamento da use case, porm
. iprofundamento da anlise, novas classes surgiro e outras sero fundidas, de modo que
il do processo, as classes de anlise estaro muito prximas das classes de projeto.
i - i .ii'iri Ires tipos de classes de anlise: classes de fronteira, classes de controle e classes de
ii In
30
Captulo 5 - Classes de anlise
31
Observaes:
5.2 Classes de fronteira

As classes de fronteira so responsveis pela comunicao entre a use case e o ator. Senctl
assim, existe uma regra bsica que determina que cada relao entre ator e use case gera umi
classe de fronteira e este relacionamento envolve receber ou apresentar informaes do sistemal
para o ator.
Os comportamentos dessas classes estojjntjmamejite Hgad^s_cornatpque mantm relaciol
namento com a use case, uma vez que atravs d aliasse de fronteira que o ator ter os seud
requisitos atendidos. Uma interface com o usurio ou a interface de comunicao deve ser isoladaerj
Classes de fronteira, na maioria das vezes, esto associadas a janelas^rmsînterfaces Jo
comunicao, interface de impressora, sensores, terminais eAPJs (Aplication Prgfam Interact-.).
A figura a seguir mostra como o smbolo para classes de fronteira.
l xltlom mais trs classes de fronteira: uma que interage com a impressora que imprime o
mt;ll)o de liberao de dinheiro, outra responsvel por enviar as informaes para o equipainnnlo que libera o dinheiro e uma para a leitura do carto magntico, mas para facilitar a
nnpreenso e simplicidade do modelo, estas trs classes no sero modeladas.
0,3 Classes de entidade

AM clnsses de entidade so utilizadas para modelar informaes que so duradouras e persistem
.i" a execuo do sistemaJSo informaes e comportamentos associados a conceitos como
l.|i'i" i i eventos da vida real. Um objeto de entidade (instncia de uma classe de entidade) no
'.'..mamente passivo; pode e deve possuir um comportamento mais complexo relacionado s
.ices, que representam e isolam as mudanas no sistema relativo a estas informaes. No
Illlo urna regra bsica para determinar as classes de entidade, deve-se analisar as informaes
. i use case. Normalmente, em uma primeira anlise, so determinadas de 1 aSclassesde
i, i 1.1.-por use case.
AB classes de entidade so representadas como mostrado na figura a seguir.
Fronteira
Figura 5.1 - Smbolo para classe de fronteira.
Para o exemplo de use case "Sacar dinheiro", identificamos na primeira anlise que existem du
classes de fronteira que so:
.
Janela de interface com o usurio, que ir ser responsvel por obter e enviar informaes pari
o usurio.
Interface de comunicao com o sistema central, que ser responsvel por buscar informa
coes do cliente no sistema central, onde se encontram os dados dosicorrnTtstas:
Entidade
Figura 5.3 - Smbolo para classe de entidade.
Avnliando a use case "Sacar dinheiro" identificamos as seguintes classes de entidade:
Usurio, que responsvel por armazenar as informaes do usurio durante o processo de
tique de dinheiro no caixa eletrnico.
Carto, que responsvel por armazenar as informaes da conta e do carto do usurio
Uianto o processo de saque de dinheiro no caixa eletrnico.
Interface de comunicao com o sistema central
Usurio
Conta
Figura 5.4 - Exemplos de classes de entidade.

Janela de interface com o usurio
Figura 5.2 - Exemplos classes de fronteira.
32
Captulo 5 - Classes de anlise
5.4 Classes de controle
As classes de controle representam a coordenao, seqenciamento, transaes e controle entra

os objetos da use case, isto , todo o controle da use case ser encapsulado nas classes de controle
As classes de controle so tambm utilizadas para representar aes complexas como lgica dd
negcio que representa o comportamento da use case e que no representa uma informao duradou]
r, como no caso das informaes das classes de entidade.
A parte dinmica do sistema ser modelada em classes de controle, uma vez que elas manipular
e coordenam as principais aes e controle de fluxos e distribuem o trabalho a ser executado pelas
classes de entidade ou de fronteira.
A regra para a primeira anlise uma classe de controle para cada use case. Normalmente,
classe de controle recebe mensagens das classes de fronteira e distribuem as tarefas e informaes
para outras classes de entidade ou de fronteira e normalmente retornam informaes para a classe dfl
fronteira que mandou a primeira mensagem. Com a evoluo da anlise, outras classes de controla
podero surgir.
As classes de controle so representadas como mostrado a seguir.
Controle
Figura 5.5 - Smbolo para classe de controle.

Para a use case "Sacar dinheiro" e seguindo a regra identificamos a classe Sacar, cuja irnagen
mostrada a seguir.
Sacar
Figura 5.6 - Exemplo de classes de controle.
5.5 Avaliao
chamada de realizao de use case a determinao das classes de anlise relacionadas a estl
use case e ao relacionamento entre estas classes. Este passo permite passar fase seguinte, deterf
minando os comportamentos do relacionamento entre as classes.
A figura a seguir mostra a realizao de use case "Sacar dinheiro".
Conta
Usurio
h
.Inniila de interface com o usurio
Interface de comunicao com

Sacar
o sistema central
Figura 5.7 - Exemplo de realizao de use case.
33
6. DIAGRAMAS DE INTERAO
i.1 As relaes entre as classes de anlise
l h na vez determinadas as classes de anlise devemos, tendo em mos os fluxos de evento das
i".os (e/ou um diagrama de atividades), trabalhar no relacionamento entre estas classes, ou
i, ontre os objetos de anlise, uma vez que o relacionamento existe entre objetos. Ou seja, na
iliiln iii,, 10 de classes e objetos, vimos que a classe vaca tem a propriedade de "produzir leite", porm
HUWIM produz mesmo a Mimosa ou a Malhada, por exemplo. Vaca uma classe e, portanto, abstraia,
IIHululo do raciocnio humano. No existe no mundo real e, portanto, no pode produzir leite. Neste
i ilo, estamos interessados nas mensagens que so enviadas de um objeto para outro e nos
>; realizados. Estas mensagens e servios esto, de alguma forma, descritas no fluxo de
, da use case. Esta fase , inclusive, importante para validar o fluxo de eventos e verificar se
ii n dos requisitos deixou de ser atendido pela use case. A UML define dois diagramas de interao:
Diagrama de sequncia
Diagrama de colaborao
dois diagramas so duas formas diferentes de apresentar os relacionamentos entre os

>; de anlise, porm a indicao do PRISM para a utilizao do Diagrama de sequncia, uma
u ai este diagrama est mais ligado ao fluxo de eventos que foi desenvolvido para a use case.
i lorma, diminui-se o risco de haver perda de consistncia na evoluo do desenvolvimento.
0,2 Diagrama de sequncia

< > l liagrama de sequncia, como o nome diz, apresenta uma sequncia de eventos que determinam o comportamento da use case e so apresentados no fluxo de eventos. Neste diagrama so
i Tilados os atores e as classes de anlise na parte superior do diagrama e as linhas que se
Buuorn abaixo de cada um deles representam a linha de vida do objeto ou da ao do ator ou objeto
lnlno outro objeto. A figura a seguir mostra um exemplo onde um ator 1 inicia o processo enviando a
igem para uma classe de fronteira e esta passa a mensagem para a classe de controle. Estas
igens e servios devem ser retirados do fluxo de eventos. Um exemplo de instanciao (cons0 do objeto mostrado no relacionamento entre o objeto controlar e o objeto entidade, que
"iimmlri" e "destri" o objeto (onde colocado um sinal "X"). A figura a seguir mostra o diagrama
36
Captulo 6 Diagramas de interao
de sequncia com este exemplo de instanciao. Quando o objeto envia uma mensagem a si
prprio isto representado por uma linha de ida e volta como no caso do exemplo da mensagem
chamada "automensagem" no objeto controlar. O diagrama de sequncia deve ser depurado ate
o momento onde todos os comportamentos necessrios e conhecidos foram representados nc
diagrama. E neste momento que iniciamos o processo de desenvolvimento das classes de
projeto. Porm no existe uma linha divisria, trabalha-se em um e em outro diagrama, deper
do das necessidades do desenvolvimento.
: Ator
Fronteira
Mensagem!
10: Automensagem
2: Mensagem 2
:Controlar 5:Mensagem!
: Ator 1
: Fronteira
: Fronteira
: Controlar
37
: Ator 2
:Entidade
8:Resposta2
Figura 6.2 - Diagrama de colaborao.
6.4 Exemplo de diagramas de sequncia

Considerando os atores, as classes de anlise e o fluxo de eventos determinados para a use
i-rthii Sacar dinheiro vistos anteriormente foi desenvolvido o diagrama de sequncia apresentado na
i a seguir para o fluxo timo. Neste diagrama, os objetos foram representados pelo nome das
|MHGS que os compem sem utilizar os smbolos das classes de anlise e j esto preparados para
Inlulnr o processo de criao das primeiras operaes das classes de projeto. As mensagens do
tllBgrnma sero as primeiras mensagens que cada objeto (e, por consequncia, a classe) ter para
III i M h ;r s necessidades do sistema.
-^
^
:Ent
Mensagem 3
mens
Mensagem 5
Respostas
Resf
Al
T
l
Figura 6.1 - Diagrama de sequncia.
6.3 Diagrama de colaborao

O diagrama de colaborao muito semelhante ao diagrama de sequncia, porm mostra o
relacionamento das classes no que diz respeito ao sentido das mensagens e ao nmero de mensagem dando nfase organizao dos objetos que participam de uma interao. A figura a seguir
mostra um exemplo de diagrama de colaborao baseado no mesmo exemplo do diagrama d<
sequncia da figura anterior.
6.5 Avaliao
Como o diagrama de sequncia representa a "ponte" entre a anlise e o projeto, o seu uso
unental. Nas primeiras verses, o diagrama conter somente mensagens em texto, porm com
(lontinuao do trabalho, as mensagens vo se transformando em operaes da classe que est
imulo representada pelo objeto no diagrama.
A modelagem dinmica completa do sistema com todos os cenrios relevantes em conjunto com
i IN i lingramas de classe representam a documentao mais poderosa para se compreender e realiM - 1 implementao do sistema e, conseqentemente, para melhorias ou correes futuras.
lr
38
LJ
Sacar
V,
Carto
getMoneyO
passCardt)
. Validar carto
7. SUBSISTEMAS
Mensagem da Ern
Dados do Usurio
; Contai,^
siore
" ClienteO
l store()
checkPasswordO
7.1
.1 Desenvolvimento
Des(
paralelo
Com a criao do Diagrama de sequncia, possvel iniciar a implementao do sistema, porm
ompre possvel implementar todo o projeto simultaneamente. necessrio avaliares diagrama no sentido de dividi-los em partes que podem ser implementadas por grupos ou pessoas e para
:;istema deve ser dividido em pacotes ou subsistemas. Esta diviso no possui uma regra
' i iva. importante avaliar os recursos humanos e tcnicos (como subsistemas j existentes)
nveis para dar incio implementao do projeto.
Senha correia? ,
Redigitar senha
[Se>3bloqueiacartoj
Red igitar senha

' l
: j lSesenha incorrela]
Solicita valor
[Se senha correia]
. verityBalancel)
Existe saldo?
M
Informa (alia de saldo
A administrao do desenvolvimento paralelo permite realizar um conjunto de tarefas simultne iii que se perca no trabalho. A definio de subsistemas permite definir a fronteira entre os
liai Milhos, de modo a garantir a no interferncia entre os subprojetos, ou seja, define-se um contrato
I|H i omunicao entre pacotes ou subsistemas que garanta um desenvolvimento adequado. Caso
n|n necessrio mudar o contrato, negocia-se novamente, porm mantendo sincronismo entre as
'iites partes do sistema.
l * [Pede novo valorj

Informa liberao
{Se h saldo]
s ; -Contaf)
:
; - Cliente()
Figura 6.3 - Exemplo do uso do Diagrama de sequncia.
7.2 Subsistemas
1 ' '.ubsistema um tipo especial de pacote. A grande diferena que um subsistema possui um
"rortamento definido, ou seja, tem responsabilidades claras e uma forma conhecida de ser
.u ia. A esta forma, d-se o nome de interface. Do ponto de vista de conceito, um subsistema
HS|I'I n meio caminho entre um pacote e uma classe. A figura a seguir mostra a representao para
(lllmliitemas na UML.
40
Captulo 7 - Subsistemas
41
subsytem
Subsistema
Interface
Sistema central
Interface
Figura 7.1 - Smbolo de subsistema para UML.
Figura 7.2 - Exemplo de subsistema.
A identificao de subsistemas um dos passos mais importantes no projeto de software, pois

permite a criao de uma biblioteca de classes e subsistemas que ir formar um framework de
desenvolvimento que, uma vez bem modelado e documentado, pode ser utilizado em outros projetos.j
alm de ser fundamental para o desenvolvimento paralelo.
IHIO isolaria o acesso ao sistema central do banco, o que provavelmente ser utilizado por outnas
l" " em outras use cases.
Quando se decide desenvolver um subsistema, est se buscando diminuir os acoplamentos

entre as partes do projeto e, conseqentemente, aumentar a independncia das partes do sistema. (
isolamento de funcionalidades em subsistemas (que tambm ocorre na definio dos pacotes, mas
de uma forma menos especfica) facilita as mudanas no sistema, principalmente nas mudanas de
requisitos durante o desenvolvimento (e queiramos ou no, estas mudanas acontecem) e permite j
uma evoluo independente entre os componentes.
A identificao de subsistemas feita a partir da anlise dos diagramas de sequncia. No incio,
no se deve ter preocupao com detalhes internos do subsistema, concentrando as atenes na
interface (o contrato entre os componentes),focando no encapsulamento do comportamento e na
abstrao em relao a operaes e atributos.
A seguir so apresentados os passos para desenvolver um subsistema:
Distribuir o comportamento nos elementos (classes) pertencentes ao subsistema.
Documentar os elementos.
Descrever os relacionamentos (contratos de interface) entre os elementos.
importante definir uma lista de avaliao para verificar se todos os comportamentos necessric
foram atendidos.
As responsabilidades de um subsistema so representadas pelas operaes de interface quel
devem ser claras e bem definidas para facilitar a reutilizao e interessante que esta documen-l
taco seja focada nas responsabilidades e na interface, detalhando e exemplificando. desejvel}
desenvolver programas-exemplo que facilitem a compreenso do uso prtico do subsistema.
Os subsistemas devero ter ao final do desenvolvimento (assim como um sistema) os diagrama
de sequncia e classes de projeto com relacionamento entre as classes.
Um exemplo de subsistema para o projeto de caixa eletrnico e para a use case Sacar dinheiro
o que faz a interface com o sistema central do banco para buscar informaes do cliente do banco.l
8. CLASSES DE PROJETO
8.1 Classes de projeto
Uma vez trabalhado o diagrama de sequncia no sentido de levantar todas as possveis classes e
subsistemas que iro compor a use case, inicia-se a montagem das classes de projeto que represenInm o ltimo passo antes da gerao de cdigo. Vale lembrar que o aprofundamento do trabalho no
illnsjrama de sequncia vai depender da complexidade e do conhecimento tcnico. As classes foram
iniioduzidas no captulo Orientao a Objetos, porm neste captulo iremos analisar as classes do
ponto de vista de projeto, ou seja, como desenvolv-las a partir das use case, classes de anlise e do
i llnsjrama de sequncia.
Para identificarmos as classes de projeto devemos:
Desenvolver as classes de projetos iniciais que so retiradas diretamente do diagrama de

sequncia.
Definir as operaes de relacionamento.
Definir atributos e outras operaes.
Definir dependncias, associaes e generalizaes.
Verificar a consistncia da classe quanto aos requisitos no funcionais.
Criar, se necessrio, novas classes de projeto.
A quantidade de classes que deve existir em um projeto depende da complexidade do projeto e, em

especial, da use case que se est desenvolvendo. Podemos dizer que:
Muitas classes simples significam que:
Encapsulam um pouco de toda a inteligncia do sistema.
So fortes candidatas a serem reutilizadas.
So mais fceis de serem implementadas.
Poucas classes complexas significam que:
Encapsulam boa parte da inteligncia do sistema.
So mais difceis de serem reutilizadas.
So mais difceis de serem implementadas.
Captulo 8 Classes de projeto

44
45
UML na prtica:
prtica: do problema,
problema ao sistema
UML
Uma classe deve possuir um propsito bem definido e deve ser responsvel por fazer uma coisa e
.lahom
faz-labem.
Sabemos que o aprofundamento do estudo do diagrama de sequncia ir gerar em ltima anlise
um conjunto de classes dos tipos: fronteira, controle ou entidade. Desta forma, importante estabelecer
critrios que facilitem a implementao destas classes. As estratgias para esta implementao esto
i :imos, a distribuio do controle pode ser muito complexa e seria necessrio dividi-la em duas ou mais.
Como foi colocado no tpico anterior, talvez as responsabilidades de algumas (ou todas) classes de entidade
l H iiisam ser transferidas s classes de controle.
A deciso do que fazer est relacionado com a complexidade, probabilidade de mudanas, performance,
i lltilribuio do comportamento ou gerenciamento da transao. As classes de controle podem tambm
i Ininparecer e se transformar em operaes em uma outra classe, normalmente de entidade.
apresentadas a seguir.
8.1.1 Critrios para implementar ciasses de fronteira

Quando iniciamos a implementao de classes de fronteira, devemos primeiro identific-las nos
dois tipos principais, que so:
Classes de fronteira que executam interface com o usurio. Neste caso, devemos analisar se
existe alguma ferramenta que ir gerar automaticamente esta interface e o quanto desta
interface ser gerada pela ferramenta. A escolha certa ir implicar na facilidade ou no do
desenvolvimento destas classes, o que pode, em alguns casos, implicar em atrasos na entrega
do sistema. O fato de estas classes estarem diretamente ligadas ao usurio faz com que, aos l
olhos do cliente, represente o prprio sistema, por isso importante o desenvolvimento de ]
prottipos com estas classes (janelas), de modo a deixar a interface o mais prximo possvel ]
da necessidade do cliente.
Classes de fronteira que fazem interface com sistemas externos. Neste caso, normalmente
existe um protocolo, aberto ou proprietrio, de comunicao entre os sistemas. muito impor- l
tante isolar este comportamento do resto do sistema, de modo a no influenciar o desenvolvi- I
mento do restante do sistema em caso de mudana por qualquer razo do protocolo. Estas l
classes so muito importantes e, na maioria das vezes, implicam em um risco alto (s vezes, j
altssimo) em funo do no conhecimento do protocolo ou uma documentao insuficiente do l
sistema legado com o qual se deve trocar informaes. Por isso, na maioria dos casos, deve-se j
ter muita ateno com este tipo de classe de fronteira.
8.1.2 Critrios para implementar classes de entidade

As classes de entidade representam o conhecimento e/ou dados do sistema e, portanto, devem l
conter os mtodos e atributos que representem este comportamento. Estas classes executam a
maioria dos comportamentos da use case. importante ressaltar que as classes de entidade so l
responsveis pelos dados e por qualquer outra informao relativa a estes dados; e que no necessariamente estes dados esto relacionados ao banco de dados que representa, na verdade, uma forma l
de dar persistncia aos dados. Em alguns casos, os requisitos de performance podem influenciar na
reavaliao destas classes. Em particular, os mtodos que esto diretamente ligados a estes requisi- l
tos. Em algumas use cases, talvez seja mais prudente que os comportamentos das classes de entidade
sejam incorporados s classes de controle.
8.1.3 Critrios para implementar classes de controle

Antes da implementao de uma ciasse de controle, deve-se primeiro avaliar se a(s) classe(s) de
controle (so) realmente necessria(s), uma vez que a distribuio do controle pode no ser
complexo o suficiente para determinar a existncia de uma classe de controle especfica. Em outros
8.2 Operaes
Muitas operaes viro diretamente do diagrama de sequncia, que quanto mais trabalhado for,
tunls ir fornecer informaes que determinaro as operaes. No necessrio obter todas as
i iporaes diretamente do diagrama de sequncia, uma vez que outras operaes necessariamente
imo surgir da modelagem do diagrama de classes de projeto. E esta modelagem das classes de projeto
importante porque outras operaes sero descobertas atravs do estudo do comportamento da
lilusse, como:
Operaes de gerenciamento.
Clculos necessrios com os atributos da classe.
Operaes de teste.
Operaes internas que facilitem a compreenso e a distribuio das funcionalidades.
Uma caracterstica muito importante de uma operao o nome que deve ser apropriado, indicando
finalidade e levar em conta a perspectiva do cliente da classe, ser consistente e relativo responsahllldade da operao.
Deve-se tambm definir claramente a assinatura da operao. Por assinatura da operao, entenil-se os tipos dos parmetros (inteiro, string etc) e os prprios parmetros que so passados
uporao, alm do nome e tipo de retorno da operao. Deve-se definirse os parmetros so opcionais
> u no. Se forem, devero possuir um valor default (caso no se envie nenhum valor, este ser
> iiiii/,- ido). Por exemplo, int iValue=10, onde 10 o valor default. Deve-se definirse os parmetros devem
sm passados por valor, por referncia ou por ponteiro:
Por valor: o valor do parmetro o prprio parmetro. Deve ser utilizado quando se deseja
simplesmente utilizar o valor.
Por referncia: o valor passado o prprio parmetro, que poder ser alterado dentro da
operao. Este uso tem vantagens para parmetros (ou objetos) pequenos. Caso contrrio,
interessante a passagem de ponteiro.
Por ponteiro: o valor passado o endereo de onde est armazenado o parmetro. Deve ser
utilizado quando se necessita alterar o valor do parmetro dentro da operao.
No caso de muitos parmetros a serem passados para a operao, deve-se utilizar um objeto com
Indi >.' os dados que os representem e que permitam uma assinatura mais clara e limpa.
As operaes possuem visibilidade que permitem reforar o encapsulamento na classe e podem
BUI i Io trs tipos:
+ pblica: so operaes que podom ser acossadas por operaes de outras classes e que
representam a intorfnco d.i cl.iv.m um .r.. l. r.ss cliente (+ o smbolo da UML para operaes pblicas).
46
Captulo 8 - Classes de projeto

# protegida: so operaes que podem ser acessadas pelas operaes da prpria classe e pelas
classes
derivadas (especializao) ^(# o smbolo da UML para operaes protegidas).
CI&&&&& 4JK91 ivavtcra y^w^v^.^....
privada:sso operaes que podem ser acessadas somente pelas operaes
--=--. da
-i~ prpria
~,^r\*Haoce
-- privada:
classe,
sendo
totalmente
encapsuladas
(
o
smbolo
da
UML,
para
operaes
privadas).
sendo totali
T
Classe
Classe
ÔpPblicaO
PrivadaQ
A figura a seguir mostra uma classe com um exemplo de cada tipo de atributo. Neste exemplo, ao
Invs do caractere determinado pela UML, utilizado um cone que tambm previsto.
A figura a seguir mostra uma classe com um exemplo de cada tipo de operao. Nesi
invs do caractere determinado pela UML, utilizado um cone que tambm possvel
Ôp ProtegidaQ
47
PblicaQ: void
ProtegidaQ: void
Privada(): void
Classe
Classe
j>Pblico
^Privado
"^Protegido
+ m_Pblico: int
>OpPblica()
<^5>OpProtegida()
p PrivadaQ
# m_Protegido: int
- m_Privado: int
+ PblicaQ: void
# ProtegidaQ: void
- PrivadaQ: void
Figura 8.2 - Exemplo de atributos de classe.
8.4 Operaes e atributos de escopo

Figura 8.1 - Exemplo de classe com 3 tipos de operaes.
Uma vez determinadas as operaes, deve-se definir os mtodos, ou seja, deve-se descrever e
implementar o corpo de uma operao. A palavra mtodo muitas vezes utilizada no mesmo sentido de
operao (o que a princpio no faz muita diferena), mas mtodo a construo da operao. Nesta
construo, devem ser avaliados algoritmos especiais, que outros objetos ou operaes sero utilizadas, como os atributos sero utilizados, como ser implementado o relacionamento entre as classes e
como isto reflete no mtodo.
8.3 Atributos
Normalmente, os atributos e as operaes de uma classe s iro existir quando a classe for
Instanciada, ou seja, se transforme em um objeto, porm existe a possibilidade de se ter um atributo ou
operao que seja relacionado com a classe. Um exemplo de atributo de escopo o mximo de um
i liilorminado valor; no sistema para Sacar dinheiro poderia ser o valor mximo retirado do caixa por vez
i iu o tempo mnimo entre um saque e outro. Nestes exemplos, estes valores no esto relacionados ao
olijoto e sim ao sistema. O mtodo que permitisse ler ou alterar um valor de escopo teria que ser
(Balizado por um mtodo de escopo.
A figura a seguir mostra um exemplo de varivel de escopo que na UML representado por um
tributo sublinhado. Como a varivel de escopo est associada com todo o sistema, ela pode ser
publica. Independente da criao ou no do objeto, este parmetro de escopo pode ser utilizado.
Inicialmente, determinamos os atributos da classe que se originou de classes de entidade. Estas

classes possuem atributos que fazem parte da prpria modelagem. Para identificar outros atributos,
devemos estudar as descries dos mtodos e determinar quais informaes devem ser mantidas.
Classe
Classe
Os atributos possuem uma representao determinada por um nome, um tipo e um valor padro
(default) que opcional. importante na representao dos atributos seguir normas que facilitem a
<> Pblico
G<> Privado
^Protegido
+ m_Pblico: int
identificao.
Os atributos, assim como as operaes, possuem visibilidade que so:
+ pblicos: so atributos que podem ser acessados por operaes de outras classes. No
recomendado o uso de atributos pblicos, porque isto ir degradar consideravelmente o
encapsulamento da classe. Se houver necessidade de uma informao ou de alterar o valor de um '
atributo, deve-se desenvolver uma operao pblica que permita acessar o atributo (+ o smbolo
da UML para atributos pblicos).
# protegidos: so atributos que podem ser acessados pelas operaes da prpria classe e pelas
classes derivadas (especializao) (# o smbolo da UML para atributos protegidos).
- privados: so atributos que podem ser acessados somente pelas operaes da prpria classe,
sendo totalmente encapsulados (- o smbolo da UML para atributos privados).
^>OpPblica()
^>OpProtegida()
# m_Protegido: int
- m_Privado: int
+ m ESCOPO : int
Pblica(): void
# ProtegidaQ: void
- PrivadaQ: void
+
Figura 8.3 - Exemplo d* clnsio com atributo de escopo.
49
48
8.5.1 Dependncia
8.5 Relacionamento entre as classes

Toda classe possui um relacionamento. No faz sentido desenvolver uma classe que no possua
um cliente. Seria desenvolver uma classe sem finalidade. Os relacionamentos sempre so feitos atravs da parte pblica da classe, para ser mais exato, pelas operaes (mtodos) pblicas, uma vez que
Vs Ud [jai ic HU
A dependncia se caracteriza por uma relao leve entre dois objetos, ou seja, a relao no
iiutrutural. Nos relacionamentos por instncia, existe sempre afigura do objeto fornecedor e do objeto
cliente, ou seja, um objeto ir fornecer um determinado servio que ser consumido pelo cliente. Para
determinar o tipo de relacionamento, importante avaliar como cliente e fornecedor se relacionam e
como o cliente visvel ao fornecedor.
l - _. ~l*n jf
no devem existir atributos pblicos.
Considerando o relacionamento de herana (especializao/generalizao), podemos demonstrar
Fornecedor 1
o relacionamento como na figura a seguir.
Figura 8.5 - Relacionamento entre cliente e fornecedor.

No tpico seguinte, iremos detalhar a associao, porm importante fazer uma comparao no
nontido de avaliar se um relacionamento uma dependncia ou uma associao. Associaes so
mlacionamentos estruturais, ou seja, so relacionamentos mais duradouros e normalmente o cliente
nula o tempo todo necessitando de servios do fornecedor.
Um relacionamento de dependncia pode ser implementado como:
Uma varivel local a uma operao.
Um parmetro por referncia.
Uma classe utilitria.
Um relacionamento de associao pode ser implementado como:
Um atributo da classe.
Na figura a seguir, Cliente tem um relacionamento de dependncia com o Fornecedorl, uma assouiao com o Fornecedor2 e esta a forma de representao na UML.
Figura 8.4 - rvore de herana de relacionamentos.
Fornecedor 2
O relacionamento dividido em dois tipos:

Por instncia: neste tipo, existe um objeto ou mais objetos da outra classe que realizam o rela
cionamento.
Por classe: neste tipo, existe um relacionamento de herana (generalizao/ especializao)
entre as classes e, neste caso, o relacionamento no por objeto.
Fornecedor 1
Figura 8.6 - Roprosontao na UML de dependncia e associao.
50
8.5.1.1 Dependncia com varivel local

i
A implementao
de uma varivel local e uma operao exemplificada na figura a seguir. A
51
8.5.1.3 Dependncia com classe utilitria

Uma instncia de uma classe utilitria (Utility Class) visvel para todas as classes. considerada
uma classe global.
operao op1 () contm um objeto instanciado do objeto fornecedor 1.

Cliente
Fornecedor 1
oP1 (pFornecedor: Fornecedorl*;
Voidop1()
{
double dValue;
Fornecedor 1 Fornecedor;
Fornecedor.lerDadosQ;
Void op 1 (pFornecedor* pFornecedor)
dValue = Math.cos(SO);
Math
<fe cos (dAngle : double): double
Cliente
Figura 8.9 - Exemplo de uma dependncia por classe utilitria.
Figura 8.7 - Exemplo de implementao de dependncia com varivel local.
Uma classe utilitria uma classe de auxlio e normalmente no modelada, ou seja, no aparece
no modelo. Este relacionamento poder aparecer em vrias classes que ir poluir o diagrama. As
classes utilitrias so representadas na UML com o lado direito e inferior com uma faixa cinza.
A dependncia nem sempre deve ser modelada e isto deve ser avaliado para no poluir o diagrama
8.5.2 Associao
de classes de projeto.
8.5.1.2 Dependncia com parmetro por referncia

A implementao de dependncia exemplificada na figura a seguir, onde a instncia (um objeto) da
classe Forncedorl passada para a classe cliente que ir utilizar os servios.
Void op 1 (Fornecedor 1 * pFornecedor)
Como j foi dito anteriormente, uma associao um relacionamento duradouro e pode ser dividido
nm composio e agregao. Em alguns casos, implementado como um atributo da classe e no
modelado. Em outros casos, modelado no diagrama (apesar de que na gerao de cdigo a mesma
coisa). importante determinar qual a navegabilidade, ou seja, que classe conhece a outra ou se as
duas classes se conhecem, ou seja, podem acessaros servios uma da outra e a multiplicidade que
ilotermina quantos objetos de uma classe est associada outra classe. Outra caracterstica importanlo determinar se necessrio o desenvolvimento de uma classe de associao que ser responsvel
polo relacionamento.
pFornecedor->lerDados();
8.5.2.1 Composio
Composio uma associao muito forte e representa que o tempo de vida entre os objetos
coincide. Uma f rase representa este relacionamento:
Cliente
Op 1 (pFornecedor: Fornecedor"!'
Figura 8.8 - Exemplo de implementao de dependncia por passagem de parmetro.

Esta modelagem deve ser feita dependendo da necessidade de compreenso do relacionamento J
"A parte no vive sem o todo".
Um exemplo a classe rvore, que composta de galhos. Ento valeria dizer que um galho no vive
Miirn a rvore e isto verdade.
52
53
8.5.2.3 Classes de associao
Figura 8.10 - Exemplo de composio.

A representao de agregao na UML um losango colorido (normalmente preto) no lado da
classe que possui a parte (o todo). A seta representa a navegabilidade, ou seja, quem utiliza os servios
Uma classe de associao contm as propriedades do relacionamento, existindo uma instncia por
n ilacionamento. A classe de associao sugerida quando se tem uma associao mltipla (um para
muitos 1 -> *) para composio ou agregao. As classes de associao para este tipo de relacionainonto normalmente so listas de objetos e so responsveis pela passagem de parmetros entre os
i ibjetos e pela manuteno dos objetos nesta lista. Uma forma de implementar uma lista utilizar classes
parametrizadas (template) que so classes que definem outras classes e que so implementas em
li impo de compilao. Representam classes conhecidas como container, por exemplo: listas, pilhas,
lllus etc. Uma classe de template apresentada na UML como a seguir:
de quem.
Uma pergunta que se deve fazer se devemos utilizar atributos ou composio e devemos seguir
f argumento
as seguintes regras:
Usamos composio quando:
As classes necessitam de modelagem independente.
Classe parametrizada
O relacionamento implica no comportamento do sistema.

Existe necessidade de mostrar a visibilidade entre as classes relacionadas.
Figura 8.12 - Representao de templates na UML.
Caso contrrio, utilizamos atributos e o relacionamento no aparece na modelagem.

Existem basicamente trs tipos de multiplicidade em agregao ou composio:
8.5.2.2 Agregao
Uma agregao uma associao de fora mdia em que o tempo de vida no coincide e os objetos l
podem existir independentes um do outro. Como exemplo, podemos dizer que os pssaros esto agregados floresta, assim como s rvores (em tese, rvores e pssaros podem existir sem florestas).
1 para 1 (1 -> 1) - Um objeto de uma classe possui relacionamento com um objeto da outra
classe.
1 para muitos (1 -> *) ou (1 -> n) - Um objeto de uma classe possui relacionamento com vrios
objetos da outra classe.
Muitos para muitos (* -> *) ou (n -> n) - Muitos objetos de uma classe possuem relacionamento
com vrios objetos da outra classe. Esta opo deve ser evitada, optando-se por uma classe de
associao entre as classes de tal forma que temos:
Classe 1
Classe 2
^
n
Figura 8.13 - Relacionamento muitos para muitos.
Figura 8.11 - Exemplos de agregao.
Classe 1
n
A agregao representada na UML como um losango branco como mostrado na figura anterior. 9
importante ter em mente que o modelo representa um mundo real, mas sem expressar todos oa
detalhes do mundo real. Seria impossvel, portanto, modelar o que realmente importante para qud
possamos entender completamente o que se deseja do sistema. Use o bom senso sempre que estiver
modelando. No exagere nos relacionamentos, porm no deixe de fora relacionamentos importantes
para a compreenso, evoluo ou manuteno do sistema.
Classe associao
Hj.
Figura 8.14 - Implementao com uma classe de associao.
As outras formas de multiplicidade so derivadas destas trs.
Classe 2
55
54
8.5.2.4 Navegabilidade
IIIUCIUV.
A
que a
a ciaooc
classe w
de origem
tem visibilidade da classe destino e se no houver
A navegabilidade
navegabilidade indica
indica que
~, ,a *
-' -"'
a o. itra Um exemplo de composio bidirecional
direo identificada, as classes podem visualizar uma a outra. Um exemplo de com
de 1 para 1 pode ser implementado em C++ da seguinte forma:
c/ass Fornecedor
Floresta
.***--.
'-^
-v
prvate:
Arvore
*-'
Cliente *m_pCliente;
public:
){m_pC,iente=PC,iente};//Construtorcom,i9aocomo
clientel
Fornecedor (Cliente *pCliente,

-FomecedorQ;
c/ass Cliente
{
prvate:
Fornecedor *m_pFornecedor;
public:
Cliente(){
m_pFomecedor= new Fomecedorfthis);
//Construtor inicializando objeto do fornecedor
Cedro
Anjico
Jalob
Peroba
Figura 8.15 - Exemplo de generalizao (herana) e outros relacionamentos.
Uma classe muito ulilizada em generalizao a classe abslrala. Classes abslralas represenlam
otimportamentos genricos, mas se instanciarmos estas classes, elas no lm como implemenlaro
iiomporlamenlo. Para isso, ser necessrio que uma classe concreta faa o trabalho. Por exemplo,
abemos que uma rvore tem o comportamento de gerar frutos, porm, se formos instanciar a classe
Aivore, no saberemos como implementar este comportamento, s podemos criar a operao. Caso a
nliifise seja Jalob, esle comportamento conhecido.
Em C++ no existe o conceito de interface, por isso podemos utilizar classes abstraias para
Implementar uma interface.
};
Forma
-CHenteQ;
* abslracl draw()
O que indica que uma composio que o fornecedor no existe sem o cliente e bidirecional,]
porque ambos os objetos podem chamar mtodos de um para o outro. O relacionamento um para um, j
ou seja, um objeto de uma classe ter um objeto da outra classe.
8.5.3 Generalizao
Uma classe pode compartilhar a estrutura e/ou o comportamento de outra classe e este
compartilhamento chamado de generalizao que tambm conhecido como " um tipo de" ou " um",
ou seja, quando ao descrever a classe se utilizar esta expresso, provavelmente existir um relacionamento de generalizao entre as classes. Se utilizarmos o exemplo de florestas e rvores, sabemoj
que florestas so compostas por Jatobs, Cedros, Anjico, Peroba e por a vai. Estes exemplos so
todos tipos de rvore e Jatob uma rvore.
Quadrado
Crculo
Tringulo
^ drawQ
S>draw()
^draw()
Figura 8.16 - Exemplo de relacionamento de generalizao com classe abstraia.

Em desenvolvimento, no se deve utilizar mltipla herana, ou seja, uma classe que herda o
comportamento de outras duas. Isto pode causar problemas de execuo. A seguir mostrado um
exemplo de mltipla herana, onde no possvel determinar qual operao da classe ser executada
quando for solicitado o servio Draw.
57
8.6 Diagrama de classes de projeto

O diagrama de classes de projeto representa o ponto onde o PRISM completa o ciclo, ou seja, onde
11 desenvolvimento do modelo toma a forma do projeto e onde as classes desenvolvidas sero apresenludas com os relacionamentos, operaes e atributos. Ento possvel iniciar o trabalho de transformaViflo de operaes em mtodos, que o preenchimento das operaes com a sequncia de cdigo que
Irrt prover o servio. No diagrama de classes de projeto, possvel avaliar a modelagem da ou das use
ouses que foram trabalhadas e analisar, do ponto de vista da arquitetura escolhida para o sistema, se
unta tudo de acordo ou se necessrio que se altere alguma coisa na modelagem.
Neste momento, as ferramentas de gerao de cdigo automtico so capazes de gerar o esqueInlo do projeto que ser implementado, gerando ento um cdigo executvel. A montagem do modelo de
i lnsses de projeto depende da experincia do projetista com a linguagem e com orientao a objetos e
um projeto ser tanto melhor quanto mais simples e fcil de manter ele for, alm, claro, de corresponder
os requisitos de funcionalidade, robustez e performance.
Figura 8.17 - Exemplos de mltipla herana.

Mas como resolver o problema quando se necessita de um relacionamento mais duradouro? Muitas J
. -v.i..:_Jn. ,mQ Ha,, neneralizaces por composio, porm uma outra
forma vermcar se, i u. cc.,,^v.~, _ n
Peroba realmente uma rvore e um vegetal, porm todos as i
podemos mudar o modelo como mostrado a seguir.
V
Floresta
rvore
f
Anjico
*>
^>
Jatob
Figura 8.18 - Como so-uc.onar o prob.ema de mltipla herana.
Galho
9. TESTES
9.1 Introduo
Desde o primeiro cdigo gerado, deve-se realizar e documentar os testes. Existem vrios estudos
e ferramentas para facilitar a execuo de testes que detectem o quanto antes os famosos "bugs"de
toftware, que podem comprometer todo o desenvolvimento e, conseqentemente, todo o produto,
l xiste um consenso que diz que todo software tem algum bug que pode nunca ser descoberto, porm
n funo do teste permitir que um sistema seja consistente e confivel o bastante para ser utilizado. O
Inste representa o final do ciclo (ou final do incremento) quando o executvel gerado. Os testes de
ilstema dependem fundamentalmente do tipo de sistema que est em desenvolvimento, por isso so
ugeridos trs tipos de teste que devem ser utilizados, dependendo do tipo de sistema. Para todos os
li As tipos de teste, deve-se preencher a seguinte tabela:
Responsvel:
Data:
Inclua o nome da pessoa responsvel pela execuco do teste.
Inclua a data de execuo do teste no formato

dd/mm/a 3.
Recursos necessrios:
Inclua a especificao de hardware e software da(s) mquina(s) envolvida(s) no teste.
Hardware
Configurao
Procedimentos:
Descreva os procedimentos para a execuo do teste.
Resultados:
Doscreva os resultados obtidos ao final do teste.
Software
60
todos os mtodos das classes executem oe auui

exceo que devem ser tratados pelas classes.
Sendo assim, o foco testar a classe, ou seja, confirmar se a classe atende s responsabilidades
10. SISTEMAS DE TEMPO REAL
atribudas.
Para este fim so desenvolvidos mtodos especficos para teste, que devem ser diferenciados dos
demais com, por exemplo, a incluso da palavra test antes do nome do mtodo. A criao de mtodos
especficos para teste facilita que aps cada incremento os testes sejam repetidos para verificar se o
10.1 Introduo
comportamento da classe no foi alterado de forma incorreta.
9.3 Teste de stress

O teste de sfress utilizado a fim aplicar ao sistema um conjunto muito grande de dados e analisar
o comportamento do sistema. Ao final do incremento, o executvel gerado submetido a um programa
especificamente desenvolvido para se comunicar com o sistema em desenvolvimento e intensificar Q
uso. Normalmente este teste aplicado a sistemas que manipulem dados, ou sistemas de tempo real:
9.4
^.4 Teste de funcionalidade
funcionalidade
O teste de funcionalidade L "---*-)<-
baseado r\oc
nas llfif*
use Cf
cases desenvolvidas para o sistema. Os fluxos d<
evento timos e alternativos so aplicados ao sistema, a fim de garantir o funcionamento de acordo cort
as use cases (ou requisitos funcionais) trabalhadas no incremento, que se est finalizando e repetindc
para as use cases, ou test case, dos incrementos anteriores, se for o caso. A utilizao de use cs
para testes normalmente chamada de test case, ou caso de teste, o que, na prtica, representa utiliz;
os fluxos de eventos das use cases e verificar se o sistema os atende.
Um sistema de tempo real leva em considerao o tempo de resposta a um estmulo externo. Em

nlguns casos, est associado a um equipamento do sistema externo e ao sistema em desenvolvimento.
Alguns sistemas operacionais como QNX, por exemplo, permitem a execuo de processos, de modo a
londera estas necessidades. Os processos so executados obedecendo a uma determinada poltica e
l n loridade e, nestes casos, os processos compartilham um mesmo processador, no sentido de atender
mposta ao evento to rpida quanto possvel. Porm no necessrio que o sistema operacional seja
iltisenvolvido especificamente para tempo real, pois esta avaliao feita, como foi dito, em termos do
Blmulo e da resposta a este estmulo. Ou seja, o sistema operacional deve permitir responder no tempo
adequado, o que conseguido, se for possvel executar tarefas mltiplas fmu/f/fas/Tpseudosimultneas".
l Isto a maioria dos sistemas operacionais atuais permite.
Uma vez identificado que o sistema de tempo real, deve-se utilizar o diagrama de estado da UML
pura demostrar o comportamento dinmico do objeto (ou classe) responsvel pelos estados, que no
possvel de ser analisado no diagrama de sequncia. A implementao do diagrama de estado no
i omplexa e muitas vezes um mtodo de controle analisa o estado atual, alm do evento recebido e
promove a mudana de estado para o estado seguinte em funo do estmulo. Os mtodos da classe
iMtponsveis por cada estado iro atualizar os valores de estado da classe.
10.2 UML para sistemas de tempo real

10.2.1 Cpsula
Uma das definies explicitamente determinada para sistema de tempo real a de cpsula, que
i n 11 padro especfico que representa o encapsulamento de um processo, ou thread, de controle do
ililema.
A figura a seguir mostra o exemplo de uma cpsula, que composta de:
Subcpsulas que representam novos processos.
Classes passivas que so executadas sequencialmente (no mesmo processo da cpsula) e

que so responsveis pelas operaes das cpsulas.
Captulo 10 Sistemas de tempo real
63
62
Mquina de estado, ou diagrama de estado, que representam o comportamento dinmico da

cpsula.
O port, que responsvel pela comunicao entre a cpsula (ou processo) e outras cpsulas
(ou processos).
:
r
?i ;
Mquina de estado \-z-l !<x|
Protocolo
1
Entrada
| Diagrama de sequncia ]
Mquina de estado
1 ..*
1 ..*
| Tipos de protocolo |
<->
Cpsula
11
Sinal
1..*
|'Oi
Sada
l 0 ..*
Cpsula
Figura 10.3 - Protocolos.
0..*
0..*
Class< passiva
Port
Figura 10.1 - Cpsula.
10.2.2 Port
10.3 Exemplo: sistema de reconhecimento de chamada

telefnica
Um sistema de reconhecimento de chamada est ligado linha telefnica. Ao receber as chamadas
locebe tambm o nmero do telefone que esta chamando. Estes nmeros so lidos, armazenados na
memria para uma futura consulta e apresentados em um display. A figura a seguir mostra o diagrama
do estado que representa estes estados.
Os ports se comportam como a fronteira da cpsula, ou seja, so os objetos responsveis pela

troca de informao entre as cpsulas. Normalmente, estas informaes so definidas por protocolos
de comunicao e podem ser realizadas atravs de memria compartilhada, rede de computadores
sockets etc. figura a seguir mostra um diagrama de classes, onde aparece o relacionamento entrt
cpsula, port e protocolo.
Prximo nmero (O a i
| Considera-se:
| Caractere OxOA -> Ring
Caractere 0x06 > Fim de nmero
Caracteres 0x00 a 0x09 -> Nmeros de telefone
Figura
10.2 - Cpsu.a uti.izando ports de comunicao

baseado em um protocolo.
Figura 10.4 - Exemplo de diagrama de estado
10.2.3 Protocolos
O protocolo uma lista de tipos de mensagem de entrada e de sada que pode seguir um padr
definido, padro aberto ou pode ser proprietrio, ou seja, desenvolvido pelo dono do sistema. C
protocolos proprietrios devem ser cuidadosamente documentados, uma vez que no existe outro loc
onde esta informao possa ser encontrada.
A interpretao dos caracteres OxOA, OxOB e os nmeros de O a 9 representam o protocolo de

Comunicao entre os sistemas.
11. COMPONENTES, PACOTES, CAMADAS E

DIAGRAMA DE ENTREGA
11.1 "Componentizao", uma palavra nova para um
velho problema
A complexidade dos sistemas pode variar de um simples programa de consulta de dados at sistemas complexos que utilizam a Internet como meio de comunicao e com dados e usurios espalhados
por todo o mundo. Como desenvolver um sistema to complexo? A complexidade e a responsabilidade
podem e devem ser divididas em pequenas partes especializadas em determinadas atividades. Esta
lcnica conhecida como Objeto distribudo e est relacionada com as decises de arquitetura do
projeto, que dependem muito de fatores como experincia da equipe nas tecnologias, tempo hbil para a
nquisio de novos conhecimentos, necessidades do sistema etc. Nesta altura do desenvolvimento,
dove-se iniciar o projeto do sistema do ponto de vista de pacotes, que representam os agrupamentos de
partes do sistema que facilitem o desenvolvimento e a manuteno do sistema de camadas, que reprenontam os nveis de negcio representados na construo do sistema, que sero vistos mais frente, e
do componentes, que representam os cdigos gerados e como se comunicam.
11.2 Componentes
Os componentes so as partes reais que compem o produto como, por exemplo, arquivos
nxocutveis, bibliotecas como DLL, ActiveX, componentes COM, COM+ ou DCOM ou, ainda, componentes Java como, por exemplo, JavaBeans ou Java Enterprise Beans. Estes componentes so
losponsveis pelo funcionamento do sistema, principalmente quando se trata de um sistema que
funciona em camadas, em especial sistemas para Internet e como o desenvolvimento de sistemas
illiitribudos para este ambiente est crescendo a cada dia (principalmente com o surgimento de
Incnologias como .NET e J2EE). fundamental a modelagem dos componentes para facilitar a distribuiVto do comportamento das use cases, o que ser apresentado em detalhes mais adiante. O momento
11 lazer esta modelagem vai depender do conhecimento das necessidades do sistema, o quanto antes
imilhor, porm talvez seja necessrio aprofundar o desenvolvimento para definir o modelo de compoiitmtes. s vezes, necessrio realizar o primeiro incremento para definir corretamente este modelo.
68
layer
Cliente
Captulo 11 Componentes, pacotes, camadas e diagrama de entrega
69
layer
Cliente
layer
Middleware
layer
Server
Figura 11.3 - Sistema de trs camadas.
Em f u
(que originalmente estavam na camada servidor) que podem estar em qualquer lugar
Lso da camada server (como mostra a figura a seguir) em duas partes.
. camada de negcio, que responsve, pelo tratamento dos dados que so env,ados ou rece-
bidos do cliente e
camada de dados, que responsvel pela interface com o repos,tor,o de dados.
Figura 11.4 - Exemplo de sistema com quatro camadas.
A deciso da diviso do sistema em camadas vai depender da complexidade e das necessidades

do sistema. Esta deciso ir influenciar diretamente na tecnologia a ser adotada e no conhecimento
lcnico necessrio equipe para o desenvolvimento do projeto. O uso de padres de componentes ir
lucilitar a escolha da melhor forma de dimensionar o projeto em funo da tecnologia existente.
As camadas normalmente so consideradas pacotes e vo naturalmente influenciar na distribuio da
atividade de desenvolvimento em paralelo. Uma camada ou pacote pode ser composto de componentes
ou classes.
11.5 Diagrama de entrega

Em determinados projetos, principalmente em sistemas multicamadas ou com componentes,
li i iportante apresentar um diagrama que mostre o relacionamento dos componentes e/ou camadas em
i olao ao local onde estes componentes estaro fisicamente, ou seja, onde devero ser instalados.
l"ste diagrama ir facilitar a visualizao da distribuio dos componentes e a forma de instalao.
A figura a seguir mostra um exemplo de diagrama de entrega simples para uma loja virtual (uma loja
virtual necessita de mais componentes). No navegador estar sendo executado um componente responsvel pelas informaes da compra do cliente. No servidor de Internet esto os componentes
i impensveis pelo negcio, pela inteligncia do slstoma como controle de clientes, produtos e compras.
No banco de dados est o componente rosponnrivol por todo e qualquer acesso ao banco de dados,
l ate um exemplo tpico de quatro camadas: a quarta cnirmda a camada de comunicao que no
tiBl apresentada no diagrama.
70
12. DO PROBLEMA AO SISTEMA

12.1 O processo
Figura 11.5 - Exemplo de diagrama de entrega.
O desenvolvimento de software uma atividade de raciocnio humano nica e sem precedentes na

histria. uma mistura de criatividade com tecnologia, o que faz com que se necessite de um processo
que atenda s expectativas tecnolgicas sem restringir a criatividade no desenvolvimento do projeto. A
criatividade uma caracterstica humana difcil de ser aprendida e quase impossvel de ser ensinada e
muito menos determinada por um processo, j o conhecimento e a aplicao do conhecimento tecnolgico
pode e deve ser modelado, uniformizado e transmitido, a fim de aumentar a produtividade e a qualidade
do produto gerado.
A proposta deste livro baseada em um modelo j conhecido e abrangente, a UML. O PRISM
prope uma forma de desenvolvimento criada principalmente do prisma do desenvolvedor, apresentando, de forma clara, a sequncia do trabalho a ser desenvolvido, ou seja, onde comea e onde termina
o trabalho e quais so as etapas a serem seguidas.
Este livro apresenta um modelo de engenharia de software que est focado no desenvolvimento
(anlise, projeto e arquitetura) em si e no na(,gerncia e que foi considerado uma viso prtica que
permitisse a real implementao do modelo.
O livro segue uma linha de trabalho chamada do "Problema ao sistemalque permite identificar o(s)
problema(s) que suscitou(ram) a necessidade de uma soluo e desenvolver um sistema com prazo,
custo e qualidade adequados.
Os passos deste modelo so:
Problema: o problema na realidade composto pelo conjunto de necessjdad.e,s que o cliente

tem em relao automao de qualquer processo ou trabalho que um sistema (ou software)
possa resolver. Existem inmeras formas de resolver o mesmo problema, ou seja, existiro
vrios tipos de sistemas que podem ser desenvolvidos a partir destas necessidades. O que se
quer garantir utllizando-se um modelo de engenharia de software como o PRISM que.o
resultado atenda s necessidades com qualidade e que melhorias possam ser feitas j que os
problemas tambm evoluem.
Captulo 12 - Do problema ao sistema
73
72
Levantamento>e anlise de requisitos: uma vez sendo apresentadp_aQpJoblma_|rec]al

joimat-lo e analis-lo, de forma a levantar os possveis riscos da no implementao do
sistema nas condies apresentadas pelo cliente. Esta fase fundamental poro,uerepresenta
urn compromisso do que se est contratando e o qTjsfa~eTrtregre nofjnrd^rojet.
Modelagem de use case: com os requisitos em mo, definem-se os atores e as use cases que
-ra-aiSael atestes; requisitos, Deve-se colher nos requisitos funcionais do sistema (requisitos
com os quais o cliente ir interagir) as use cases que permitiro atend-los:
Escolha da(s) use case(s) a ser(em) trabalhada(s): a escolha da ou das use cases a serem
trabalhadas deve_uti|jzar asavaliaes4e risco j levantadas a partir dos requisitos, de modo a
atacar os prob^
terr^domnip da soluo para
depois. Esta escolha tambm deve levar em conta quais use cases so bsicas e/ou prioritrias
para o funcionamento do sistema para que as outras a serem desenvolvidas possam ser
Sistema: o sistema a concluso da montagem de cada cdigo gerado e testado em cada ciclo
de desenvolvimento. Cada ciclo ser responsvel por uma parte de cdigo (testado o mximo
possvel), que adicionado ao cdigo j existente, testado e, ao final, quando todas as use
cases forem realizadas ou todos os requisitos forem atendidos, representa o sistema.
Modelagem de sistemas de tempo real: normalmente, os sistemas que dependem de informaes de um outro sistema, principalmente se esse outro sistema representar um hardware
dedicado com um firmware, ser necessrio desenvolver um diagrama de estado que fornecer a viso de comportamento dinmico do objeto relacionado com estas informaes.
Modelagem de pacotes/componentes: o desenvolvimento de sistemas complexos ou de

sistemas para Internet ir necessitar da diviso em pacotes e componentes que iro determinar
a forma de desenvolvimento e da montagem final do sistema. Os componentes so normalmente utilizados em sistemas corporativos de trs ou mais camadas desenvolvidas com COM+
(Microsoft) JavaBeans, J2EE (Sun).
incorporadas nos incrementos seguintes.
Modelagem de classes de anlise

as classes de anlise que as compem. Este trabalho representa^) primeiro passo de fragmentao da use case no sentido do sistema^
~~~
Modelagem dinmica utilizando o diagrama de sequncia: as classes de anlise sero_

fundidas ou quebradas durante o processo de anlise dinmica dos objetos que instanciam_
estas classes. Este trabalho representa a ponte entre a anlise e o projeto. difcil definir neste
pontoi ondj termina a..anlisei efindQ^camjgfiaa..piojgto_, mas isso o que menos importa.
trabalho na modelagem dinmica, principalmente no diagrama de sequncia, gerar a maioria
das classes de projeto e facilitar a busca das operaes (e, por consequncia, os mtodos) e
atributos que as classes de projeto tero alm de permitir identificar os subsistemas que faro
parte do sistema, facilitando inclusive a reutilizao de cdigo j desenvolvido. U ma. oujrajpjsj^
importante neste momento a definio (se ainda no foi feita) dos subsistemas qu,eja,zem
parte do projeto para permitir o desenvolvimento paralelo.
"~
Modelagem de classes de projeto: aps a modelagem dinmica, passa-se modelagem
.
SBTKSST; mm relacionamentos detalhados, atributos e mtodos, comportamento definido, subsistemas, pacotes etc. MS uia&ooo w= K.w,^,., -^ -._
antes da gerao de cdigo e est intimamente ligada implementao do projeto
Gerao de cdigo: a gerao de cdigos executveis representam o incio do final doJncre-_
mento no PR1SM que comeou com a anlise do problema. Um novo cdigo ser gerado ao final
de cada ciclo de processo, construindo assim as partes do sistema.
Testes: os testes dos cdigos gerados a cada incremento facilitam a integrao e o funcionamento do sistema. Todos os testes devem ser documentados para que possam ser repetidos a
qualquer momento durante o desenvolvimento do projeto.
A figura a seguir mostra um diagrama de atividades com todas as atividades de cada fase do PRISM
e quais diagramas sero gerados em cada fase e ainda como feita a ligao entre os diagramas, ou
seja, qual diagrama serve de entrada na construo de um outro.
74
Captulo 12 Do problema ao sistema
75
12.2 Como utilizar os diagramas da UML

Para a utilizar os diagramas, necessrio saber qual a finalidade de cada um deles e de treinamento
e prtica na forma de utilizao. interessante tambm que se disponha de uma ferramenta de apoio ao
desenvolvimento que facilite a gerao dos diagramas, em especial o diagrama de classes de projeto
que est intimamente relacionado com a implementao do sistema.
As fases que so abrangidas neste livro esto ligadas a analistas, projetistas e arquitetos de
sistemas, que normalmente so as pessoas com mais experincia da equipe, o que facilitar a utilizao. Porm, como o livro est baseado em uma linguagem conhecida e aberta, a UML, os estudantes de
computao podem utilizar as tcnicas apresentadas aqui no desenvolvimento de projetos.
O livro no prioriza tamanho de projeto ou de equipe, apesar de a preocupao maior ser com
equipes pequenas, que tm dificuldade em modelar os sistemas que esto em desenvolvimento.Tanto
grandes projetos como pequenos podem utiliz-lo, o que ir diferenciar, neste caso, ser o nmero de
diagramas gerados, o nmero de use cases encontradas e o nmero de interaes necessrias para
o desenvolvimento completo do sistema. Normalmente, projetos mais complexos necessitam de um
nmero maior de pessoas/equipes e isso ir comprometer o gerenciamento do projeto. Porm, do ponto
de vista do PRISM, pouca coisa (a no ser em volume de documentos) ser necessria mudar.
Para obter mais informaes, visite o site www.umlnapratica.com.br e estude projetos completos
usando o PRISM.
Figura 12.1 - PRISM diagrama de atividades e diagramas da UML gerados.
13. REFERNCIAS BIBLIOGRFICAS

[1 ] Ambler, S. "Architectural Modeling", Software Development Magazine, 1999, On-line de http://
www.sdmagazine.com
[2] Ambler, S., "Distributed Object Transactions", Software Development Magazine, 2000, On-line de
http://www.sdmagazine.com
[3] Ambler, S. "Extreme Modeling", Software Development Magazine, 2000, On-line de http://
www.sdmagazine.com
[4] Ambler, S. "Object-Oriented Business Ruies", Software Development Magazine, 2000, On-line
de http://www.sdmagazine.com
[5] Ambler, S. "Object Testing Patterns", Software Development Magazine, 1999, On-line de http://
www.sdmagazine.com
[6] Ambler, S., "Process Patterns", Cambridge University Press, 1998
[7] Berard, E. "Be Careful With Use Cases", The Object Agency, Inc, 2000, On-line de http://
www.toa.com/pub/use cases.htm
[8] Booch, G., Rumbaugh J., Jacobson, L, 'The Unified Modeling Language User Guide", AddisonWesley, 1999.
[9] Booch, G., Rumbaugh J., Jacobson, l., 'The Unified Software Development Process", AddisonWesley, 1999.
[10] Cockburn, A. "Writing Effective Use Case",, Addison-Wesley, 2001.
[11] Dimaggio, L. ,"A Roadmap for Software Test Engineering", Software Development Magazine,
2001, On-line de http://www.sdmagazine.com
[12] Douglass, B., "Real-Time UML", Addison-Wesley Longman, 1998
[13] Evans, G., "Object Think: It Really is Different", 1999, Evanetics, Inc., On-line de http://
www.evanetics.com
[14] Eriksson, H., Penker, M., "UML Toolkit", Wiley Computer Publishing, 1998.
[15] Firesmith, D., "Use Case Modeling Guidelines", Lante Corporation, lEEETransaction Software
Engineer, 1999, pp. 184-193
Captulo 13 Referncias bibliogrficas

78
79

[16] Fowler, M. ,"A UMLTesting Framework", Software Development Magazine, 1999, On-line de
[39] Rosemberg, D., Scott, K., "Driving Design with Use Cases", Software Development Magazine,
http://www.sdmagazine.com
[17] Fowler, M. "The New Methodology", Martin Fowler web site, 2001, On-line de http://
[40] Rosemberg, D., Scott, K. "GiveThem WhatThey Want", Software Development Magazine,
www.martinfowler.com
[18] Fowler, M., Scott, K.,"UMLDistilled", Addison-Wesley, 1998
[19] Fleisch, W., "Applying Use Cases for the Requirements Validation of Component-Based RealTime Software", lEEETransaction Software Engineer, 1999, pp. 75-84
[41] Rosemberg, D., Scott, K., "Sequence Diagram: One Step at aTime", Software Development
Magazine, 2001, On-line de http://www.sdmagazine.com
[20] Gamma, E., Helm, R., Johnson, R.Vlissides, J., "Design Patterns",, Addison-Wesley, 1997
[43] Rosemberg, D., Scott, K. ,'TopTen Use Case Mistakes", Software Development Magazine,
[21] Hantos, R, "A Systems Engineering View of Requirements Management for Software-intensive
Systems", lEEETransaction Software Engineer, 1999, pp.620-621
[22] Henderson-Sellers, B., Collins, G., Graham, l."UML-Compatible Process", lEEETransaction
Software Engineer, 34th Hawaii International Conference on System Sciences, 2001.
[42] Rosemberg, D., Scott, K.,"Successful Robustness Analysis", Software Development Magazine, 2001, On-line de http://www.sdmagazine.com
[44] Rumbaugh, J., Blaha, M. Premerlani, W., Eddy, F, Lorensen, W., "Object-Oriented Modeling and
Design", Prentice Hall International Editions, 1991.
[23] Heverhagen.T.Tracht, R., "Implementing Function Block Adapters", Rational Corporation, 2001,
[45] Saeki, M, "Reusing Use Case Descriptions for Requirements Specification:Towards Use Case
Patterns", lEEETransaction Software Engineer, 1999, pp.309-316
On-line de http://www.rational.com
[24] Jeffries, R., "RecordMap, Test First", X Programming, XP Magazine, 2002, On-line de http://
[46] Sawyer, R, Sommerville, l., Viller, S., "CapturingThe Benefits of Requirements Engineering",
lEEETransaction Software Engineer, 1999, pp.78-85
www.xprogramming.com
[25] Jeffries, R., "XP and Reliability", X Programming, XP Magazine, 2001, On-line de http://
[47] Schneider, G., Winters, J., "Applying Use Cases", Addison-Wesley, 2001.
www.xprogramming.com
[26] Kiedaisch, F., Pohl, M., Bauer, S. Ortmann, S., "Requirements Archaeology: From Unstructured
Information to High Quality Specifications", lEEETransaction Software Engineer, 2001, pp. 304-305
[27] Keuffel, W. ,"Best Practices Actually Applied", Software Development Magazine, 2000, On-line
de http://www.sdmagazine.com
[28] Korson, M. "Constructing Useful Use Case", McGregor Korson web site, 2000, On-line de http:/
/www.korson-mcgregor.com
[29] Kruchten, P., 'The Rational Unified Process, an Introduction", Addison-Wesley, 2000.
[30] Larman, C., "Utilizando UML e Padres", Bookman, 2000
[31] McConnelI, S., "Rapid Development", Microsoft Press, 1996
[48] Selonen, R, "Generating Structured Implementation Schemesfrom UML Sequence Diagrams",

lEEETransaction Software Engineer, 2001, pp. 317-328
[49] Selonen, R, Koskimies, K, Sakkinem, M."How to Make Apples from Oranges in UML', IEEE
Transaction Software Engineer, 34th Hawaii International Conference on System Sciences, 2001.
[50] Smith, R. "Defining the UML Kernel", Software Development Magazine, 2000, On-line de http:/
/www.sdmagazine.com
[51] Spionla, M., "Diretrizes para desenvolvimento de software de sistemas embutidos", Tese de
Doutorado, Universidade de So Paulo - USP, 1999
[52] Stroustrup, B., 'The C++ Programming Language", Addison-Wesley, 1997.
[53] Susan, L., "Use Case Pitfalls:Top 10 Problems from Real Projects Using Use Cases", IEEE
Transaction Software Engineer, 1999, pp. 174-183
[32] McGregor, J., Major, M., "SelectingTest Case Based on User Priorities", Software Developme
Magazine, 2000, On-line de http://www.sdmagazine.com
[54] Unified Modeling Language Specification Version 1.3, Object Management Group (OMG), 1999
[33] Oestereich, B. "Developing Software with UML',, Addison-Wesley, 1999

[34] Paulk, M. ."Extreme Programming from a CMM Perspective", Software Engineering Institute,
[56] Wiegers, K., "Karl Wiegers Describes 10 Requirements Traps to Avoid", Process Impact,
Software Testing & Quality Engineering, 2000, On-line de http://www.processimpact.com
2001
[35] Paulk, M., Weber, C. Curtis, B., Chrissis, M., 'The Capability Maturity Model", Addison-Wesley,
[57] Wiegers, K., "Writing Quality Requirements", Process Impact, 1999, On-line de http://
www.processimpact.com
1997.
[36] Phillips, C., Kemp, E., Sai, K., "Extending UML Use Case Modeling to Support Graphical User
Interface Design", lEEETransaction Software Engineer, 2001, pp.48-52
[37] Pressman, R., "Software Engineering", McGraw-Hill, 2001
[38] Rosemberg, D., Scott, K., "Driving Design:The Problem Domain", Software Development Magazine, 2001, On-line de http://www.sdmagazine.com
[55] What Is OMG-UML And Why Is It Important, OMG, 2001, On-line de http://www.omg.org
14. ANEXOS
Neste anexo, est a base do documento a ser utilizado durante o desenvolvimento do sistema.
chamado Documento de Modelagem de Sistema - DMS, que acompanha todo o projeto do sistema e
serve de referncia para futuras melhorias. O DMS totalmente baseado no texto apresentado neste
livro. O documento para Word est no CD do livro.
DMS DOCUMENTO DE MODELAGEM DE

SISTEMA
Este documento foi criado seguindo as recomendaes e orientaes do livro UML na prtica: do
problema ao sistema e do modelo PRISM.
Todos os tpicos que no forem utilizados devem ser retirados do documento final, assim como os
comentrios, tais como este.
Verso:
[NOME DO SISTEMA]
[AUTORES]
TABELA DE REVISES
Esta tabela contm um histrico das revises do documento. As entradas na tabela abaixo servem
apenas como carater ilustrativo. As demais entradas devero ser apagadas at que a reviso a que ela
se referir tenha sido criada.
Verso
principais autores
descrio da verso
data de trmino
V[x.x]
[nome]
[descrio da verso]
[dd/mm/aa]
V[x.x]
[nome]
[descrio da verso]
[dd/mm/aa]
PREFACIO
O prefcio contm uma introduo ao documento e principalmente ao sistema que est em
desenvolvimento.
NDICE
Este ndice foi criado de forma automtica. Caso voc tenha alterado, criado ou retirado algum item
do corpo deste documento, atualize-o posicionando o cursor em qualquer lugar do ndice e pressione a
tecla F9. Se voc deseja que este documento seja fcil de ser mantido, nunca altere o contedo deste
ndice de forma manual.
1. LISTA DE FIGURAS
91
2. LISTA DE TABELAS
93
3. INTRODUO
95
3.1 FINALIDADE
3.2 ESCOPO
3.3 DEFINIES, ACRNIMOS E ABREVIATURAS
3.4 REFERNCIAS
3.5 DETALHES DO SISTEMA
4. ESPECIFICAO DE REQUISITOS
4.1 ESPECIFICAO DOS REQUISITOS
4.1.1 ER[fla][FIDIIIN].N
5. DESCRIO DAS USE CASES E ATORES
5.1 USE CASES

5.2 DESCRIO DOS ATORES
5.2.1 [Nome do Aator N]
5.3 DIAGRAMA GERAL DE USE CASES
5.4 DETALHAMENTO DAS USE CASES
5.4.1 Use Case [Nome da Use Case N]
6. INTERFACES
6.1 INTERFACE N ..
95
95
95
96
96
97
97
97
99
99
99
99
99
100
100
103
..103
90
7. PERSISTNCIA DE DADOS
7.1 DADOS DA TABELA N
8. CLASSES DE ANLISE
8.1.1 Classes de anlise da [Nome da Use Case N].
9. CAMADAS E PACOTES
9.1.1 Diagrama de camadas (ou pacotes)
9.1.2 Camada (ou pacote) [Nome da camada (ou do pacote)]
10. COMPORTAMENTO DINMICO
10.1 DIAGRAMAS DE SEQUNCIA DA USE C4SE[NOME DA USE CASE]
10.1.1 [Nome do Diagrama de Sequncia N]
105
,105
.107
.107
.109
111
111
111
11. SUBSISTEMAS E COMPONENTES
113
12. COMPORTAMENTO ESTTICO
115
12.1 DIAGRAMAS DE CLASSE PROJETO [NOME DO DIAGRAMA]

13. TESTES.
13.1 TESTE DE CLASSE
13.1.1 Classe - [nome da classe]
13.2 TESTE DE STRESS

13.3 TESTE DE FUNCIONALIDADE
13.3.1 Teste de funcionalidade do Fluxo de evento principal
13.3.2 Teste de funcionalidade do Fluxo de evento alternativo [N]
13.3.3 Teste de funcionalidade do Fluxo de evento de exceo [N]
1. LISTA DE FIGURAS
109
109
115
...117
117
117
118
119
119
119
120
Sempre que for inserida uma nova figura ao documento, ela dever possuir uma legenda do tipo
figura, para que este ndice possa ser atualizado corretamente. Para atualizar este ndice de figuras,
coloque o cursor em qualquer lugar da mesma e pressione a tecla F9. Se voc deseja que este ndice
seja fcil de ser mantido, nunca o altere manualmente.
Figura 1 - Diagrama geral de use cases

Figura 2 - Interface para a(s) use case(s)
101
105
2. LISTA DE TABELAS
Sempre que for inserida uma nova tabela ao documento, ela dever possuir uma legenda do tipo
tabela, para que este ndice possa ser atualizado corretamente. Para atualizareste ndice de tabelas,
coloque o cursor em qualquer lugar da mesma e pressione a tecla F9. Se voc deseja que este ndice
seja fcil de ser mantido, nunca o altere manualmente.
Esta seopode ser excluda se o documento no contiver tabelas.
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
1 - Tabela de especificao do requisito ER[fla][FIDIIIN].N

2 - Fluxo de eventos da use case [nome da UC]
3 - Requisitos relacionadas com a interface
4 - Requisitos relacionadas com a tabela
3 - Teste de classe [nome da classe]
4 - Teste de funcionalidade do Fluxo de evento principal
5 - Teste de funcionalidade do Fluxo de evento alternativo [N]
6 -Teste de funcionalidade do Fluxo de evento exceo [N]
99
102
105
107
119
121
121
122
3. INTRODUO
Este tpico descreve uma viso geral de todo o documento. Nenhum texto necessrio entre este
item e o prximo, a menos que necessrio.
3.1 Finalidade
Descreva a finalidade a que se prope este documento e seu pblico alvo.
O texto abaixo serve de base, podendo ser alterado, se necessrio.
Este documento apresenta a modelagem do sistema <nome>, utilizando como referncia o
livro UML na prtica: do problema ao sistema. O pblico alvo deste documento inclui pessoas
envolvidas com o desenvolvimento (analistas de sistemas e programadores), testes do sistema e avaliadores do projeto.
3.2 Escopo
Inclua uma breve descrio sobre a aplicao deste documento; o que ser afetado ou influenciado
por este documento.
O texto abaixo serve de base, podendo ser alterado, se necessrio.
O Documento de Modelagem de Sistema prov uma viso completa dos modelos do sistema <nome>. Ele produzido e utilizado pelos desenvolvedores da equipe para documentar os
requisitos, modelos e arquitetura do sistema.
3.3 Definies, acrnimos e abreviaturas

Defina todos os termos, acrnimos e abreviaes a serem utilizadas neste documento. Caso no
tenha nenhum termo, escreva a palavra "inexistente"neste item.
U ML na prtica: do problema ao sistema
96
3.4 Referncias
Liste todos os documentos e outros materiais referenciados neste documento. Esta seo similat
a uma bibliografia.
3.5 Detalhes do sistema

Neste tpico, voc deve colocar detalhes do sistema como o nome comercial, o cone que ser,
usado etc. Ou qualquer outra informao relevante do ao sistema que no foi includo em nenhum outro
4. ESPECIFICAO DE REQUISITOS
II!
il
tpico.
4.1 Especificao dos requisitos

Este tpico dever especificar todos os requisitos do software em um nvel de detalhe suficiente
para que os especialistas possam desenvolver o sistema satisfazendo os requisitos do cliente; os
responsveis pelo teste possam verificar se o sistema satisfaz a estes requisitos e os clientes possam
avaliar se suas necessidades esto representadas nestes requisitos.
Todos os requisitos devero ser identificveis de forma nica, seguindo o modelo apresentado
neste documento.
Nenhum texto necessrio entre este item e o prximo, a menos que desejado. Consulte o captulo
3 do livro para saber mais detalhes sobre levantamento e especificao de requisitos.
4.1.1 ER[fla][FIDIIIN].N
Preencha a tabela de especificao para cada requisito levantado junto ao cliente do sistema.
Consulte o livro para tirar dvidas de como preencher as tabelas.
ER[fla][FIDIIIN].N
Nome da especificao de requisito
Descrio
Descreva detalhadamente o requisito do sistema, exemplificando sem

pr que possvel.
Descrio do risco
Risco
Descreva o risco associado ao requisito colocando o mximo de informao possvel para

n mitigao.
D um
qualificador
para o risco.
Ex:.altssimo.
Prioridade
D um
qualificador
para a
prioridade.
Ex:altssima.
98

O porqu da no implementao do requisito
(continuao)
Descreva neste campo o porqu da no implementao do requisito e quando e em que verso se

deseja implement-lo. Caso o requisito seja atual, estas duas ltimas linhas da tabela devem se>
excludas.
Tabela 1 - Tabela de especificao do requisito ER[fla][FIDIIIN].N.
5. DESCRIO DAS USE CASES E ATORES
e use cases.
5.1 Use cases

Faa uma breve descrio de cada use case que foi identificada para o sistema.
5.2 Descrio dos atores

5.2.1 [Nome do ator N]
vn o sistema. O texto abaixo, pode set
Este ator uma [pessoa ou um sistema ou um dispositivo] que atua no sistema para...
5.3 Diagrama geral de use cases
Descrio das use cases e atores
100
Fluxo alternativo N
Aes recebidas
(continuao)
Aes realizadas
1. O ator X inicia a fluxo alternativo N

(ou fluxo de erro, ou fluxo opcional etc).
2. O processo recebe a entrada, avalia e

envia ao controle.
3. O controle trata a informao.
4. Aps tratara informao, os dados so
apresentados ao ator.
Tabela 2 - Fluxo de eventos da use case [nome da UC].
Figura 11 - Diagrama geral de use cases.
5.4 Detalhamento das use cases

No inclua nenhum texto neste item.
5.4.1 Use case [nome da use case N]

Inclua um diagrama de use cases estruturado, caso ele tenha sido criado. Um diagrama estruturado
de use cases inclui os possveis relacionamentos entre use cases (incluso, extenso ou generalizao). Consulte o captulo 4 do livro para saber mais sobre o Fluxo de eventos e de use cases.
Nome da use case
Coloque um nome adequado para a use case.
Descrio
Descreva detalhadamente o propsito da use case.
Requisitos associados
Liste os requisitos que esto sendo atendidos por esta use case.
Se existir uma ou mais pr-condies, descreva-as aqui.
Ps condies
Se existir uma ou mais ps condies, descreva-as aqui.
Atores
Liste os atores que se relacionam com esta use case.

Fluxo principal
Aes realizadas
f. O ator X inicia a fluxo principal (ou fluxo timo).
2. O processo recebe a entrada, avalia e envi

ao controle.
3. O controle trata a informao.
4. Aps tratar a informao os dados so aprej
sentados ao ator.
101
6. INTERFACES
Uma interface uma descrio lgica e conceituai de como uma ou mais use cases so providas
pela interface do usurio, se foro caso, incluindo a interao requerida entre o(s) ator(es) e o sistema.
Em geral, janelas representam as interfaces necessrias para entender, do ponto de vista macro, os
requisitos da interface do usurio.
1.1 Interface N
Requisitos relacionadas com a interface
Tabela 3 - Requisitos relacionadas com a interface.
Faa o desenho das interfaces grficas referenciando os campos com etiquetas como no exemplo
abaixo.
|x
Cadastro do usurio
Nome do usurio:
e-mai):
rQ]
H]
'[H]
TEJ
Senha:
Confirmar senha:
Cadastrar
"*[LiJ
Cancelar
'f 12.
Figura 2 - Interface para a(s) use case(s).
104
Descreva os campos da interface grfica:

1. Campo para a entrada e visualizao do nome do usurio.
2. Campo para a entrada e visualizao do e-mail do usurio.
3. Etc.
7. PERSISTNCIA DE DADOS
Esta seo descreve o armazenamento dos dados do sistema que devem ser persistidos e, de
uma maneira geral, a organizao destes dados em tabelas, vises, ndices e procedimentos usados
para manter a persistncia do sistema.
Esta seo opcional para aqueles sistemas onde h pouco ou nenhum dado persistente.
7.1 Dados da tabela N

Requisitos relacionadas com os dados
Tabela 4 - Requisitos relacionadas com a tabela.
8. CLASSES DE ANALISE
Este tpico dever apresentaras classes de anlise para cada use case.
Consulte o captulo 5 do livro para saber mais detalhes sobre classes de anlise
8.1.1 Classes de anlise da [nome da use case N]

Voc dever detalhar todas as classes de anlise encontradas para o sistema, caso uma use case
utilize uma classe de outra descrita antes, deve-se relacion-la da seguinte forma:
"Classe de [tipo da classe] [nome da classe] descrita na use case [nome da use case]"
8.1.1.1 Classe de fronteira N [nome da classe]

Descreva a responsabilidade da classe e, se foro caso, a qual interface est relacionada. Se esta
classe se relaciona com outros sistemas atravs de um protocolo, descreva o mais detalhado possvel
este protocolo. Faa uma descrio para cada classe de fronteira. N significa o nmero da classe, caso
exista mais de uma. Caso contrrio, no necessrio.
8.1.1.2 Classe de entidade N [nome da classe]

Descreva a responsabilidade da classe e quais as informaes que so pertinentes a ela. Faa uma
descrio para cada classe de entidade. N significa o nmero da classe, caso exista mais de uma. Caso
contrrio, no necessrio.
8.1.1.3 Classe de controle N [nome da ciasse]

Descreva a responsabilidade da classe, a sequncia de controle (se necessrio, faa um diagrama
de atividades) e os comportamentos relacionados ao negcio. Faa uma descrio para cada classe de
controle. N significa o nmero da classe, caso exista mais de uma. Caso contrrio, no necessrio.
8.1.1.4 Diagrama de classes de anlise

Coloque o diagrama de relacionamento entre as classes de anlise para esta use case.
9. CAMADAS E PACOTES
Este tpico dever apresentar as camadas e pacotes determinados para o sistema. Caso no
exista, o tpico deve ser suprimido.
9.1.1 Diagrama de camadas (ou pacotes)

Faa um diagrama das camadas (ou dos pacotes) determinados para o sistema, mostrando o
relacionamento entre eles e explicando o funcionamento.
9.1.2 Camada (ou pacote ) [nome da camada

(ou do pacote)]
Descreva a responsabilidade da camada (ou pacote) e como realizada a interface entre esta
camada (ou pacote) e as camadas (ou pacotes) relacionadas. Faa um para cada camada (ou pacote)
definido para o sistema.
10. COMPORTAMENTO DINMICO

Este tpico dever apresentar os diagramas de sequncia que representem o comportamento
dinmico das classes de anlise, sendo este comportamento desenvolvido analisando-se o fluxo de
eventos da use case. Consulte o captulo 6 do livro para saber mais detalhes sobre modelagem
dinmica, em especial, o uso dos diagramas de sequncia.
10.1 Diagramas de sequncia da use case [nome da

use case]
Ao apresentares diagramas de sequncia que atendam a todos os fluxos de eventos existentes na use
case, os diagramas podem sercomentados, caso haja necessidade. O prprio diagrama, porm, deve contei
o mximo de informaes para que possa ser compreendido. Deve-se desenvolver diagramas de sequncia
com bom senso, ou seja, no necessrio um para cada fluxo, porm no se deve exagerar na quantidade de
fluxos para cada diagrama.
10.1.1 [Nome do diagrama de sequncia N]
11. SUBSISTEMAS E COMPONENTES

Esfe tpico dever apresentares subsistemas e ou componentes determinados para o sistema e
referenciara documentao relativa ao subsistema ou componente para que possa ser consultada em
caso de dvida. Caso no existam componentes ou subsistemas, o tpico deve ser suprimido.
Faa um diagrama dos componentes utilizados relacionando-os com as camadas, pacotes ou
partes do sistema que utilizam os servios. Para sistemas no muito complexos, pode-se utilizar o
diagrama completo de classes de anlise para representar os relacionamentos. Para sistemas mais
complexos pode-se utilizar o diagrama de camadas ou pacotes. importante deixar claro onde se
encontram as informaes relativas ao contrato de utilizao dos subsistemas e componentes. Em
alguns casos, pode-se se anexar esta documentao a este documento.
Consulte o captulo 7 e 7 do livro para saber mais detalhes sobre subsistemas, componentes e,
principalmente, sobre os contratos de interface.
12. COMPORTAMENTO ESTTICO
Este tpico dever apresentares diagramas de classe que representem o comportamento esttico
das classes de anlise.
12.1 Diagramas de classe de projeto [nome do diagrama]

Apresentares diagramas de classe de projeto que foram desenvolvidos a partir, principalmente, dos
diagramas de classes de anlise e dos diagramas de sequncia mostrando todos os relacionamentos
entre as classes e as operaes mais importantes (no necessrio que todas as operaes ou
mtodos e atributos sejam mostrados, j que no se deve poluir o diagrama). Consulte o captulo 8 do
livro para saber mais detalhes sobre diagramas de classes de projeto.
13. TESTES
Este tpico dever apresentar os tipos de testes a serem aplicados, os recursos e os procedimentos necessrios para a execuo do teste do componente em questo. Consulte o captulo 9 do livro
para saber mais detalhes sobre tipos de teste e como execut-los.
13.1 Teste de classe

Seu foco testara classe, ou seja, confirmar se a classe atende s responsabilidades atribudas.
Inclua, se necessrio, uma breve descrio sobre a aplicao do teste; o que ser afetado ou
influenciado por este documento.
Verifique se o componente composto de classes que precisam ter um tratamento especial de
teste. Deve-se levarem considerao o grau de complexidade da mesma. Quanto mais complexa fora
classe, maior a necessidade de mtodos de teste. Estas classes devem ter mtodos que permitam
realizar o autoteste.
Inclua uma seo para cada classe que ser testada.
13.1.1 Classe - [nome da classe]

Inclua uma tabela para cada classe a ser testada.
Responsvel:
Data:
Inclua o nome da pessoa responsvel pela

execuo do teste.
Inclua a data de execuo do teste no formate

dd/mm/aa.
Nome do mtodo:
Inclua o nome do mtodo que ir testara classe. Este nome deve comear com a palavra "tesferr
letra minscula, seguido do nome da classe. Suponhamos, por exemplo, que a classe a ser testado
se chame "Line". Ento o mtodo para o teste ter o nome "testLine".
118
Testes
Procedimentos:
119
13.3 Teste de funcionalidade
(continuao)
Seu foco verificar se o componente funciona como pretendido.
Inclua, se necessrio, uma breve descrio sobre a aplicao do teste; o que ser afetado ou
Influenciado por este documento.
Resultados:
Descreva os resultados obtidos ao final do teste.
13.3.1 Teste de funcionalidade do Fluxo de evento principal
Tabela 5 - Teste de classe [nome da classe].
Para executar o teste, utiliza-se o Fluxo de evento principal, completando a tabela abaixo:
13.2 Teste de stress

Um tipo de teste da confiabilidade. Seu foco assegurar que o sistema funciona como pretendido
quando circunstncias anormais so encontradas. O teste de stress pode incluir memria insuficiente,
servios no disponveis ou recursos compartilhados escassos. Tipicamente, estes testes so executados para determinar quando h falhas em um grande volume e/ou dados.
Inclua, se necessrio, uma breve descrio sobre a aplicao do teste, o que ser afetado ou
influenciado por este documento.
Responsvel:
Data:

execuo do teste.
Inclua a data de execuo do teste no formate

dd/mm/aa.
O programa de teste deve ser includo na coluna relacionada ao Software.
Inclua uma tabela para cada teste a ser realizado.
Hardware
Configurao
Software
Final:
Responsvel:
execuo do teste.
Incio:
Inclua a data e a hora Inclua a data e a hor
de incio do teste n final do teste no formata,
formato dd/mm/aa - dd/mm/aa - hh:mm.
hh:mm.
Procedimentos:
Resultados:
Inclua a especificao de hardware e software da(s) mquina(s) envolvida(s) no teste. interessante
desenvolver um programa de teste especialmente para este fim. O nome do programa poder ser c
mesmo do componente a ser testado, acrescido da palavra Tester".
Hardware
Configurao
Software

Tabela 6 - Teste de funcionalidade do Fluxo de evento principal.
13.3.2 Teste de funcionalidade do Fluxo de evento alternativo [N]

Para executar o teste, utiliza-se o Fluxo de evento alternativo [1 a n], onde para cada fluxo alternativo cria-se uma nova tabela:
Procedimentos:
Responsvel:
Data:
Resultados:

execuo do teste.
\nclua a data de execuo do teste no formato

dd/mm/aa.
O programa de teste deve ser includo na coluna relacionada ao software.
120
Hardware
Configurao
Software (continuao)
Procedimentos:
Resultados:
Tabela 7 - Teste de funcionalidade do Fluxo de evento alternativo [N].
13.3.3 Teste de funcionalidade do Fluxo de evento de exceo [N]

Para executar o teste, utiliza-se o Fluxo de evento exceo [1 a n], onde para cada fluxo exceo
cria-se uma nova tabela:
Responsvel:
Data

execuo do teste.
Inclua a data de execuo do teste no formato

dd/mm/aa.
O programa de teste deve ser includo na coluna relacionada ao Software.
Configurao
Hardware
Software
Procedimentos:
Resultados:
Tabela 8 - Teste de funcionalidade do Fluxo de evento exceo [N].

Uml Na Prática

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Uml Na Prática

Загружено:

Авторское право:

Доступные форматы

UML NA PRTICA

f! Utilizo o PRISM Modelo Prtico para

H Crie de forma prtica a documentao do

UML na prtica: do problema ao sistema

Editora Cincia Moderna Ltda.

UM L na prtica: do problema ao sistema

3.5.5 EfaF0001.5 - Instruo fcil para uso de qualquer

4. COMO TRANSFORMAR REQUISITOS EM USE CASES.

6.1 AS RELAES ENTRE AS CLASSES DE ANLISE

r . I I MAS DETEMPO REAL

l l "COMPONENTIZAO", UMA PALAVRA NOVA

\'J DO PROBLEMA AO SISTEMA*:

13. REFERNCIAS BIBLIOGRFICAS

n mndo vi o potencial do diagrama de classes, decidi estudar os outros diagramas imaginando o

U ML na prtica: do problema ao sistema

Boa sorte e mos obra!

UML na prtica: do problema ao sistema

1.2 A engenharia de software e o surgimento da UML

l nla no a forma como uma agncia bancria funciona. As operaes no so sequenciais. As

Captulo 2 Orientao a objetos

UML na prtica: do problema ao sistema

2.3 Atributos e operaes

Figura 2.1 - Relacionamento entre cliente e caixa.

Operaes: o comportamento do objeto. Normalmente, o termo operao usado, porm,

2.2 Classes, objetos e instncias

Figura 2.3 - Modelagem da classe vaca.

Figura 2.2 - Exemplo de classe e objeto (instanciao da classe).

Captulo 2 - Orientao a objetos

UML na prtica: do problema ao sistema

<Virtual produzleiteO : double

Figura 2.5 - Exemplo de composio e agregao entre classes.

Figura 2.4 - Exemplo de herana entre classes.

2.4.2 Agregao, composio e dependncia

+Virtual produzLeite(): double

Captulo 2 - Orientao a objetos

UML na prtica: do problema ao sistema

Polimorfismo uma das caractersticas mais potentes da orientao a objetos. Polimorfismo a

2.5.1 Polimorfismo esttico

Figura 2.8 - Exemplo de classe abstraia.

Figura 2.7 - Exemplo de polimorfismo esttico.

Se utilizarmos AjustaData ("15/09/2001"), ser executada a primeira operao.

Se utilizarmos AjustaData (15,9,2001), ser executada a segunda operao.

2.5.2 Polimorfismo dinmico

Figura 2.9 - Exemplo de polimorfismo dinmico.

UML na prtica: do problema ao sistema

Tem-se o seguinte cdigo:

Podemos observar que simplesmente chamada a operao Desenhar de um objeto abstraio

3.1 Requisitos do cliente X classes de projeto ou do

3.2 Como capturar os requisitos?

UML na prtica: do problema ao sistema

Requisito funcional (F)

Requisito de dado (D)

Requisito de interface (l)

Requisito no-funcional (N)

Captulo 3 - Capturando requisitos

3.3 Os riscos e prioridades associados a requisitos

A i loterminao do conjunto Prioridade/Risco (P/R) ir orientar o desenvolvimento, ou seja, assim

3.4 Gerenciamento de requisitos

Captulo 3 Capturando requisitos

UML na prtica: do problema ao sistema

3.5 Exemplo de requisitos

Tabela 3 - Risco do requisito Emitir extrato com

3.5.1 ERaF0001.1 - Sacar dinheiro