Vous êtes sur la page 1sur 386

P r in c p io s d e a n l is e

e PROJETO DE SISTEMAS
COM
Um guia prtico para
modelagem de sistemas
orientados a objetos
atravs da Linguagem
de Modelagem Unificada

CAMPUS 2 a edio totalm ente revista e atualizada


P r in c p io s de a m lise
E PROJETO de SISTEMAS
C@M
ASSOCIAO BKASSmA DE DSHTOS RH^OGRHCOS

Preencha a ficha de cadastro no final deste livro


e receba gratuitamente informaes
sobre os lanamentos e as promoes da
Editora Campus/Elsevier.

Consulte tambm nosso catlogo


completo e ltimos lanamentos em
www.ccampus.c@in.br
Eduardo Bezerra

V________ y
1

____ ____ ^
1
f -------------- \

P r in c p io s d e a n l is e
E PROJETO DE SISTEMAS

- UML
Consultoria Editorial

Lorenzo Ridolfi
Gerente Snior Accenture

Srgio Coicher
Professor do Departamento
de Informtica da PUC-Rio

't' ?o totalmente revista e atualizada


4/ y
X- %
U m
ELSEVIER

D is t r ib u i o
EXCLUSIVA PARA
P R O FESS O R ES
CAMPLS
2007, EIsevier Editora Ltda.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.


Nenhuma parte deste livro, sem autorizao prvia por escrito da editora,
poder ser reproduzida ou transmitida sejam quais forem os meios empregados:
eletrnicos, mecnicos, fotogrficos, gravao ou quaisquer outros.

Copidesque: Maria Luiza Oliveira Brilhante Brito


Editorao Eletrnica: Estdio Castellani
Reviso Grfica-, Marlia Pinto de Oliveira e Marco Antonio Correa

Projeto Grfico
EIsevier Editora Ltda.
A Qualidade da Informao.
Rua Sete de Setembro, 111 - 16 andar
20050-006 Rio de Janeiro RJ Brasil
Telefone: (21) 3970-9300 FAX: (21) 2507-1991
E-mail: info@elsevier.com.br
Escritrio So Paulo:
Rua Quintana, 75318- andar
04569-011 Brookiin So Paulo SP
Tel.: (11) 5105-8555

ISBN 13: 978-85-352-1696-7


ISBN 10: 85-352-1696-0

Nota: Muito zelo e tcnica foram empregados na edio desta obra. No entanto, podem ocorrer erros de
digitao, impresso ou dvida conceituai. Em qualquer das hipteses, solicitamos a comunicao nossa
Central de Atendimento, para que possamos esclarecer ou encaminhar a questo.
Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a
pessoas ou bens, originados do uso desta publicao.
Central de atendimento
Tel.: 0800-265340
Rua Sete de Setembro, 111, 16 andar - Centro - Rio de Janeiro
e-mail: info@elsevier.com.br
site: www.campus.com.br

CIP-Brasil. Catalogao-na-fonte.
Sindicato Nacional dos Editores de Livros, RJ

B469p Bezerra, Eduardo


Princpios de anlise e projeto de sistemas com UML /
Eduardo Bezerra. - Rio de Janeiro : EIsevier, 2007
il. ;
Inclui bibliografia
ISBN 85-352-1696-0

1. Mtodos orientados a objetos (Computao). 2. UML


(Computao). 3. Anlise de sistemas. 4. Projeto de sistemas.
I. Ttulo.

06-2781. CDD 005.117


CDU 004.414.2
Agradecimentos

se passaram quatro anos desde o lanamento da primeira edio deste

J livro. Durante todo esse tempo, diversas pessoas me ajudaram a esclare


cer meu entendimento sobre os assuntos de que trato neste livro. A todas
elas, devo meus sinceros agradecimentos. Comeo por agradecer aos diversos
leitores da primeira edio que contriburam com crticas e sugestes para
melhoramento do mesmo. Agradeo tambm a meus alunos, nas diversas insti
tuies de ensino pelas quais passei. Certamente, a tarefa de professar uma das
melhores maneiras de aprender. Devo agradecimentos tambm a todos os meus
colegas professores com os quais troquei idias e ensinamentos sobre o proble
ma da modelagem de sistemas de software: Ronaldo Goldschmidt, Carmem de
Queiroz, Jorge Soares, Ismael Humberto e Leandro Chernicharo, dentre outros.
Obrigado tambm Rafaela Ventura, supervisora editorial da Elsevier/Campus,
por toda a pacincia e profissionalismo durante o tempo em que trabalhamos na
produo desta segunda edio. Finalmente, e no menos importante, agradeo
a toda a minha famlia, pelo carinho, pelo incentivo e pela pacincia durante os
dias em que estive no computador.
Sumrio

Prefcio XIII

Viso geral 1
1.1 Modelagem de sistemas de software 2
1.2 O paradigma da orientao a objetos 4
1.2.1 Classes e objetos 7
1.2.2 Mensagens 7
1.2.3 O papel da abstrao na orientao a objetos 8
1.3 Evoluo histrica da modelagem de sistemas 12
1.4 A Linguagem de Modelagem Unificada (UML) 15
1.4.1 Vises de um sistema 16
1.4.2 Diagramas da UML 17

0 processo de desenvolvimento de software 21


2.1 Atividades tpicas de um processo de desenvolvimento 22
2.1.1 Levantamento de requisitos 22
2.1.2 Anlise 26
2.1.3 Projeto (desenho) 29
2.1.4 Implementao 30
2.1.5 Testes 30
2.1.6 Implantao 30
2.2 O componente humano (participantes do processo) 30
2.2.1 Gerentes de projeto 3!
2.2.2 Analistas 51
2.2.3 Projetistas
vm \CIPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

2.2.4 Arquitetos de software 33


2.2.5 Programadores 33
2.2.6 Especialistas do domnio 34
2.2.7 Avaliadores de qualidade 35
2.3 Modelos de ciclo de vida 35
2.3.1 O modelo de ciclo de vida em cascata 35
2.3.2 O modelo de ciclo de vida iterativo e incremental 37
2.4 Utilizao da UML no processo iterativo e incremental 41
2.5 Prototipagem 41
2.6 Ferramentas CASE 42

Mecanismos gerais 47
3.1 Esteretipos 47
3.2 Notas explicativas 48
3.3 Etiquetas valoradas (tagged values) 49
3.4 Restries 50
3.5 Pacotes 50
3.6 OCL 52

Modelagem de casos de uso 53


4.1 Modelo de casos de uso 54
4.1.1 Casos de uso 54
4.1.2 Atores 60
4.1.3 Relacionamentos 61
4.2 Diagrama de casos de uso 70
4.3 Identificao dos elementos do MCU 73
4.3.1 Identificao de atores 74
4.3.2 Identificao de casos de uso 74
4.4 Construo do modelo de casos de uso 78
4.4.1 Construo do diagrama de casos de uso 78
4.4.2 Documentao dos atores 80
4.4.3 Documentao dos casos de uso 80
4.5 Documentao suplementar ao MCU 84
4.5.1 Regras do negcio 85
4.5.2 Requisitos de desempenho 86
4.5.3 Requisitos de interface grfica 87
4.6 O MCU em um processo de desenvolvimento iterativo 87
4.6.1 O MCU nas atividades de anlise e projeto 88
4.6.2 O MCU e outras atividades do desenvolvimento 90
4.7 Estudo de caso 91
4.7.1 Descrio da situao 91
4.7.2 Regras do negcio 92
4.7.3 Documentao do MCU 93
Modelagem de classes de anlise 109
5.1 Estgios do modelo de classes iic
5.2 Diagrama de classes 112
5.2.1 Classes 112
5.2.2 Associaes 113
5.2.3 Generalizaes e especializaes 128
5.3 Diagrama de objetos 135
5.4 Tcnicas para identificao de classes 137
5.4.1 Anlise textual de Abbott 138
5.4.2 Anlise dos casos de uso 139
5.4.3 Identificao dirigida a responsabilidades 144
5.4.4 Padres de anlise 151
5.4.5 Outras tcnicas de identificao 154
5.4.6 Discusso 155
5.5 Construo do modelo de classes 158
5.5.1 Definio de propriedades 158
5.5.2 Definio de associaes 160
5.5.3 Organizao da documentao 161
5.6 Modelo de classes no processo de desenvolvimento 162
5.7 Estudo de caso 164
5.7.1 Cartes CRC 169
5.7.2 Glossrio 171

Passando da anlise ao projeto 175


6.1 Detalhamento dos aspectos dinmicos 177
6.2 Refinamento dos aspectos estticos e estruturais 177
6.3 Projeto da arquitetura 178
6.4 Persistncia de objetos 179
6.5 Projeto de interface grfica com o usurio 179
6.6 Projeto de algoritmos 180

Modelagem de interaes 181


7.1 Elementos da modelagem de interaes 182
7.1.1 Mensagens 185
7.1.2 Atores 189
7.1.3 Objetos 189
7.1.4 Classes 190
7.1.5 Colees de objetos 191
7.2 Diagrama de sequncia 193
7.2.1 Linhas de vida 193
7.2.2 Mensagens 194
7.2.3 Ocorrncias de execuo 196
7.2.4 Criao e destruio de objetos 196
princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

7.3 Diagrama de comunicao 198


7.4 Modularizao de interaes 200
7.4.1 Quadros 200
7.4.2 Diagrama de viso geral da interao 205
7.5 Construo do modelo de interaes 206
7.5.1 Mensagens para cumprir responsabilidades 206
7.5.2 Coeso e acoplamento 207
7.5.3 Dicas para a construo do modelo de interaes 208
7.5.4 Procedimento de construo de um diagrama de interao 211
7.6 Modelo de interaes em um processo iterativo 215
7.7 Estudo de caso 218

8 Modelagem de classes de projeto 229


8.1 Transformao de classes de anlise em classes de projeto 229
8.1.1 Especificao de classes de fronteira 230
8.1.2 Especificao de classes de entidade 232
8.1.3 Especificao de classes de controle 233
8.1.4 Especificao de outras classes 235
8.2 Especificao de atributos 238
8.2.1 Notao da UML para atributos 238
8.3 Especificao de operaes 241
8.3.1 Notao da UML para operaes 241
8.3.2 Dicas prticas 242
8.3.3 Projeto por contrato 243
8.3.4 Operaes de criao e destruio de objetos 246
8.3.5 Seletores e modificadores 246
8.3.6 Outras operaes tpicas 247
8.4 Especificao de associaes 248
8.4.1 O conceito de dependncia 248
8.4.2 Transformao de associaes em dependncias 250
8.4.3 Navegabilidade de associaes 250
8.4.4 Definindo a implementao de associaes 252
8.5 Herana 257
8.5.1 Tipos de herana 257
8.5.2 Classes abstratas 258
8.5.3 Operaes polimrficas 260
8.5.4 Interfaces 263
8.5.5 Acoplamentos concreto e abstrato 266
8.5.6 Reuso atravs de delegao 268
8.5.7 Classificao dinmica 269
8.6 Padres de projeto 271
8.6.1 Composite 272
8.6.2 Observer 273
suMi=; XI

8.6.3 Strategy 275


8.6.4 Factory Method 276
8.6.5 Mediator 278
8.6.6 Faade 278
8.7 Modelo de classes de projeto em um processo iterativo 279
8.8 Estudo de caso 280

Modelagem de estados 287


9.1 Diagrama de transio de estado 288
9.1.1 Estados 288
9.1.2 Transies 290
9.1.3 Eventos 290
9.1.4 Condio de guarda 292
9.1.5 Aes 292
9.1.6 Atividades 293
9.1.7 Ponto de juno 293
9.1.8 Clusulas entry, exit e do 294
9.1.9 Transies internas 296
9.1.10 Exemplo 296
9.1.11 Estados aninhados 297
9.1.12 Estados concorrentes 298
9.2 Identificao dos elementos de um diagrama de estados 299
9.3 Construo de diagramas de transies de estados 300
9.4 Modelagem de estados no processo de desenvolvimento 302
9.5 Estudo de caso 303

10 Modelagem de atividades 307


10.1 Diagrama de atividade 307
10.1.1 Fluxo de controle seqencial 308
10.1.2 Fluxo de controle paralelo 309
10.2 Diagrama de atividade no processo de desenvolvimento iterativo 310
10.2.1 Modelagem dos processos do negcio 311
10.2.2 Modelagem da lgica de um caso de uso 311
10.2.3 Modelagem da lgica de uma operao complexa 311
10.3 Estudo de caso 312

11 Arquitetura do sistema 315


11.1 Arquitetura lgica 316
11.1.1 Camadas de software 318
11.2 Implantao fsica 323
11.2.1 Alocao de camadas 32-1
11.2.2 Alocao de componentes 327
11.3 Projeto da arquitetura no processo de desenvolvimento 332
XII princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

12 Mapeamento de objetos para o modelo relacional 335


12.1 Projeto de banco de dados 336
12.1.1 Conceitos do modelo de dados relacional 337
12.1.2 Mapeamento de objetos para o modelo relacional 339
12.1.3 Classes e seus atributos 340
12.1.4 Associaes 341
12.1.5 Agregaes e Composies 344
12.1.6 Associaes reflexivas 345
12.1.7 Associaes ternrias 345
12.1.8 Classes associativas 346
12.1.9 Generalizao 347
12.2 Construo da camada de persistncia 350
12.2.1 Acesso direto ao banco de dados 351
12.2.2 Uso de um SGBDOO ou de um SGBDOR 352
12.2.3 Padro DAO 353
12.2.4 Frameworks ORM 356

Referncias 361

ndice 365
Prefcio

eja bem-vindo segunda edio de Princpios de Anlise e Projeto de Sis

S temas com UML. Este livro uma introduo aos conceitos fundamen
tais necessrios para se realizar a anlise e o projeto de sistemas de soft
ware orientados a objetos atravs da Linguagem de Modelagem Unificada
(UML). J existem bons livros disponveis aqui no Brasil que discutem a mode
lagem de sistemas orientados a objetos com UML. No entanto, uma razo que
me levou a escrever este livro foi o fato de alguns desses livros darem uma nfase
maior descrio da UML em si.
De fato, a UML define uma notao padro que pode ser utilizada por desen
volvedores de software orientado a objetos. Certamente, o domnio dessa nota
o importante para qualquer desenvolvedor que queira aproveitar todas as
capacidades que a UML fornece. Mas, igualmente importante, principalmente
para iniciantes no desenvolvimento de software, o entendimento de como
aplicar a notao da UML na modelagem. esse enfoque que procurei dar neste
livro. Em vista disso, este livro no fornece uma referncia completa sobre a no
tao definida pela UML. Em vez disso, ele descreve uma parte dessa notao e
tambm como realizar a anlise e o projeto de sistemas orientados a objetos
atravs de parte da notao mais utilizada.
Durante todo o livro, exemplos so utilizados para demonstrar a aplicao
da UML em situaes prticas de modelagem. Ao fim de cada captulo, so for
necidos exerccios para testar o contedo apreendido pelo leitor. Alm disso,
um estudo de caso desenvolvido para os principais tpicos abordados com o
objetivo de exemplificar a aplicao dos procedimentos e dicas de modelagem
que so apresentados em cada captulo.
XIV princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Pblico-alvo
Este lTo destinado a estudantes de graduao e ps-graduao em computa
o ou em engenharia de software cursando uma disciplina introdutria de an
lise e projeto orientados a objetos. Ele pode ser tambm utilizado como guia por
estudantes no desenvolvimento de seus projetos finais de curso. Profissionais
que desenvolvem sistemas segundo outros paradigmas (que no o orientado a
objetos) tambm podem encontrar neste livro uma boa iniciao aos conceitos
da orientao a objetos e da sua aplicao modelagem de sistemas de software.
Em todos os casos, o livro pode servir como uma fonte de referncia e de dicas
prticas sobre a aplicao da UML e de outras tcnicas no desenvolvimento de
um sistema de software orientado a objetos.
O conhecimento de alguma linguagem de programao orientada a objetos
(por exemplo, Java, C#, C++ etc.) desejvel (mas no obrigatrio) para o bom
entendimento dos assuntos tratados neste livro. Mas especificamente, este livro
fornece diversos exemplos de trechos de cdigo-fonte em linguagem Java. En
tretanto, esses exemplos devem ser facilmente entendidos por profissionais fa
miliarizados com outras linguagens orientadas a objetos.

Organizao dos captulos


o Captulo 1 apresenta uma breve introduo utilizao do paradigma da
orientao a objetos e da UML. O objetivo deste captulo fornecer uma viso
geral sobre a anlise e o projeto de sistemas de software sob o ponto de vista de
orientao a objetos. Os principais conceitos do paradigma da orientao a ob
jetos so introduzidos neste captulo.
O Captulo 2 descreve as principais atividades constituintes de um processo
de desenvolvimento de software. Tambm descrevemos os principais profissio
nais envolvidos nesse processo, juntamente com suas respectivas atribuies. O
processo de desenvolvimento em cascata apresentado com o objetivo de dar
uma motivao para o surgimento do processo incrementai e evolutivo. Em se
guida, este ltimo tambm descrito e apresentado como a forma atual de se de
senvolver sistemas orientados a objetos. Na maioria dos demais captulos, so
feitas aluses utilizao da UML em um processo de desenvolvimento incre
mentai e evolutivo.
O Captulo 3, 0 menor deste livro, apenas uma apresentao dos mecanis
mos de uso geral da UML. Essa apresentao se faz necessria em virtude de es
ses mecanismos serem utilizveis em diversos diagramas da UML. Nos captu
los posteriores, fazemos uso e estendemos os conceitos introdutrios apresen
tados neste captulo.
No Captulo 4, apresentamos o modelo de casos de uso e os diversos ele
mentos do diagrama de casos de uso da UML. Alm disso, so fornecidas di-
PREFACIO XV

versas dicas prticas que podem ser utilizadas na construo desse modelo.
Este captulo tambm enfatiza o modelo de casos de uso como um ponto cen
tral de um processo de desenvolvimento que utilize a UML como linguagem
de modelagem.
O Captulo 5 descreve a construo do modelo de classes de anlise de um
sistema de software orientado a objetos (SSOO). Os principais elementos de no
tao definidos pela UML para a construo do diagrama de classes so descri
tos. Apresenta tambm o conceito de responsabilidade de um objeto. Descreve
mos tambm diversas tcnicas teis na identificao das classes iniciais de um
SSOO, tais como a anlise textual de Abbot, a anlise de casos de uso, e o uso de
padres de anlise. Alm disso, apresentamos um procedimento de construo
do modelo de classes inicial em um desenvolvimento dirigido a casos de uso.
O Captulo 6 serve como uma apresentao do contedo dos captulos que
o seguem. A partir desse captulo, a descrio das atividades de projeto comea
a tomar o lugar da descrio das atividades de anlise.
A modelagem de interaes entre objetos em um SSOO discutida no Ca
ptulo 7. Nesse captulo, apresento a idia de que as construes do modelo de
classe e do modelo de interaes so interdependentes: a construo de um
modelo fornece informaes para a construo do outro, e vice-versa. Os dia
gramas de interao foram os mais atingidos (em termos de mudanas) com a
nova verso da Linguagem de Modelagem Unificada, a UML 2.0. Nesta segun
da edio, tambm apresentamos alguns novos elementos de notao introdu
zidos pela UML 2.0. Seguindo a filosofia da primeira edio, no me preocupei
em apresentar todos os elementos novos de notao, mas apenas os que, na
minha viso, so os mais importantes e relevantes em situaes prticas de
modelagem.
O Captulo 8 retoma a discusso sobre o modelo de classes, agora com um
enfoque nas caractersticas de modelagem referentes fase de projeto. Nesta se
gunda edio do livro, dei um detalhamento maior aos assuntos tratados neste
captulo. Conceitos fundamentais ao projeto de um SSOO so apresentados ao
leitor: classe abstrata, interface, polimorfismo, tipos de acoplamento, projeto
por contrato etc. Tambm fao uma pequena introduo a um assunto um tanto
avanado, mas cada vez mais sedimentado no desenvolvimento de um SSOO:
padres de projeto.
O Captulo 9 descreve a sintaxe, a semntica e a construo dos diagramas
de transies de estados.
O Captulo 10 finaliza a apresentao dos diagramas da UML relacionados
parte comportamental do sistema. Esse captulo descreve os diagramas de ativi
dades.
O Captulo 11 faz uma introduo aos conceitos relacionados arquitetura
de um sistema de SSOO. Termos como subsistema, componente e camada so
XVI princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

descritos. Outros diagramas da UML so apresentados: o de componentes, o de


pacotes e o de implantao.
Finalmente, o Captulo 12 descreve alternativas de representao de objetos
em um mecanismo de armazenamento persistente como um sistema de gerncia
de bancos de dados relacional. tambm feita uma introduo a questes relacio
nadas implementao de uma camada de persistncia em um SSOO.

Recursos na Internet
Como informao suplementar contida neste livro, fornecido um site na
prpria editora Elsevier/Campus. Acesse a pgina da Editora (www.campus.
com.br). Nesse endereo, o leitor pode obter informaes e material relaciona
do ao livro. Entre os recursos que podem ser encontrados no site, esto os se
guintes:

Solues de alguns dos exerccios propostos no livro. O leitor pode encon


trar diversos exerccios resolvidos no material disponibilizado no site da
editora.
Apresentaes baseadas no contedo dos assuntos abordados no livro. Esse
material til para o professor ou instrutor que deseja adotar o livro em
seus cursos.
Complementos ao estudo de caso apresentado no livro. O estudo de caso que
desenvolvo no livro denominado Sistema de Controle Acadmico (SCA).
No final de alguns dos captulos, forneo diversos exemplos de modela
gem no contexto do SCA. Um problema que surge como continuar e
complementar esses exemplos. Uma soluo que adoto a partir dessa
segunda edio utilizar a Internet como local para fornecer novos ma
teriais acerca deste estudo de caso.
Outras fontes de informao. O material disponvel no site da editora con
tm tambm endereos para outras fontes interessantes sobre modela
gem de sistemas de software orientados a objetos. Seguindo a natureza di
nmica da Internet, o contedo do site ser modificado de tempos em
tempos. O leitor pode tambm utilizar esse site para entrar em contato co
migo, com o objetivo de trocar idias sobre o livro.

Convite ao leitor
Einalmente, convido o leitor a prosseguir pelo restante desta obra. Espero que
as informaes contidas neste livro o ajudem de alguma forma e que a leitura
seja a mais agradvel possvel. Tentei dar o meu melhor para produzir um texto
cuja leitura seja aprazvel e didtica. Entretanto, pelo fato de a produo de um
prefa ; x>

livro ser uma tarefa bastante complexa, tenho conscincia de que erros e incon
sistncias ainda se escondem por entre as linhas que compem este livro. Para
os que quiserem entrar em contato comigo para trocar idias e fornecer crticas
e sugestes, fiquem vontade para enviar uma mensagem atravs do meu ende
reo de correio eletrnico.

Eduardo Bezerra
Rio de Janeiro, RJ
edubezerra@gmail.com
8 de agosto de 2006
Visogeral
Coisas simples devem ser simples, e
coisas complexas devem ser possveis.
- ALAN KAY

O decorrer da histria, diversos tipos de bens serviram de base para o

N desenvolvimento da economia. Propriedade, mo-de-obra, mqui


nas e capital so exemplos desses bens. Atualmente, est surgindo
um novo tipo de bem econmico: a informao. Nos dias de hoje, a empresa que
dispe de mais informaes sobre seu processo de negcio est em vantagem
em relao a suas competidoras.
H um ditado segundo o qual a necessidade a me das invenes. Em
consequncia do crescimento da importncia da informao, surgiu a necessi
dade de gerenciar informaes de uma forma adequada e eficiente e, dessa ne
cessidade, surgiram os denominados sistemas e informaes.
Um sistema de informaes uma combinao de pessoas, dados, proces
sos, interfaces, redes de comunicao e tecnologia que interagem com o objeti
vo de dar suporte e melhorar o processo de negcio de uma organizao empre
sarial com relao s informaes que nela fluem. Considerando o carter estra
tgico da informao nos dias de hoje, pode-se dizer tambm que os sistemas de
informaes tm o objetivo de prover vantagens para uma organizao do p>on-
to de vista competitivo.
O objetivo principal e final da construo de um sistema de informaorsca
adio de valor empresa ou organizao na qual esse sistema ser i
termo adio de valor implica que a produtividade nos process-o- dl
prin cp io s de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

na qual o sistema de informaes ser utilizado deve aumentar de modo signifi


cativo, de tal forma a compensar os recursos utilizados na construo do siste
ma. Para que um sistema de informaes adicione valor a uma organizao, tal
sistema deve ser economicamente justificvel.
O desenvolvimento de um sistema de informaes uma tarefa das mais
complexas. Um dos seus componentes denominado sistema de software. Esse
componente compreende os mdulos funcionais computadorizados que inte
ragem entre si para proporcionar ao(s) usurio (s) do sistema a automatizao
de diversas tarefas.

1.1 Modelagem de sistemas de software


Uma caracterstica intrnseca de sistemas de software a complexidade de seu
desenvolvimento, que aumenta medida que cresce o tamanho do sistema. Para
se ter uma idia da complexidade envolvida na construo de alguns sistemas,
pense no tempo e nos recursos materiais necessrios para se construir uma casa
de cachorro. Para construir essa casa, provavelmente tudo de que se precisa de
algumas ripas de madeira, alguns pregos, uma caixa de ferramentas e certa dose
de amor por seu cachorro. Depois de alguns dias, a casa estaria pronta. O que di
zer da construo de uma casa para sua famlia? Decerto, tal empreitada no se
ria realizada to facilmente. O tempo e os recursos necessrios seriam uma ou
duas ordens de grandeza maiores do que o necessrio para a construo da casa
de cachorro. O que dizer, ento, da construo de um edifcio? Certamente,
para se construir habitaes mais complexas (casas e edifcios), algum planeja
mento adicional necessrio. Engenheiros e arquitetos constroem plantas dos
diversos elementos da habitao antes do incio da construo propriamente
dita. Na terminologia da construo civil, plantas hidrulicas, eltricas, de fun
dao etc. so projetadas e devem manter consistncia entre si. Provavelmente,
uma equipe de profissionais estaria envolvida na construo, e aos membros
dessa equipe seriam delegadas diversas tarefas, no tempo adequado para cada
uma delas.
Na construo de sistemas de software, assim como na construo de siste
mas habitacionais, tambm h uma gradao de complexidade. Para a constru
o de sistemas de software mais complexos, tambm necessrio um planeja
mento inicial. O equivalente ao projeto das plantas da engenharia civil tambm
deve ser realizado. Essa necessidade leva ao conceito de modelo, to importante
no desenvolvimento de sistemas. De uma perspectiva mais ampla, um modelo
pode ser visto como uma representao idealizada de um sistema a ser constru
do. Maquetes de edifcios e de avies e plantas de circuitos eletrnicos so ape
nas alguns exemplos de modelos. So vrias as razes para se utilizar modelos
na construo de sistemas. Segue-se uma lista de algumas dessas razes.
VISAO GER-.

1. Gerenciamento da complexidade; um dos principais motivos de utilizar mo


delos que h limitaes no ser humano em lidar com a complexidade.
Pode haver diversos modelos de um mesmo sistema, cada qual descre
vendo uma perspectiva do sistema a ser construdo. Por exemplo, um
avio pode ter um modelo para representar sua parte eltrica, outro
modelo para representar sua parte aerodinmica etc. Atravs de mode
los de um sistema, os indivduos envolvidos no seu desenvolvimento
podem fazer estudos e prever comportamentos do sistema em desen
volvimento. Como cada modelo representa uma perspectiva do siste
ma, detalhes irrelevantes que podem dificultar o entendimento do sis
tema podem ser ignorados por um momento estudando-se separada
mente cada um dos modelos. Alm disso, modelos se baseiam no deno
minado Princpio da Abstrao (ver Seo 1.2.3), segundo o qual s as
caractersticas relevantes resoluo de um problema devem ser consi
deradas. Modelos revelam as caractersticas essenciais de um sistema;
detalhes no-relevantes e que s aumentariam a complexidade do pro
blema podem ser ignorados.
2. Comunicao entre as pessoas envolvidas: certamente, o desenvolvimento de
um sistema envolve a execuo de uma quantidade significativa de ativi
dades. Essas atividades se traduzem em informaes sobre o sistema em
desenvolvimento. Grande parte dessas informaes corresponde aos
modelos criados para representar o sistema. Nesse sentido, os modelos
de um sistema servem tambm para promover a difuso de informaes
relativas ao sistema entre os indivduos envolvidos em sua construo.
Alm disso, diferentes expectativas em relao ao sistema geralmente
surgem durante a construo dos seus modelos, j que estes servem
como um ponto de referncia comum.
3. Reduo dos custos no desenvolvimento: no desenvolvimento de sistemas, se
res humanos esto invariavelmente sujeitos a cometerem erros, que po
dem ser tanto individuais quanto de comunicao entre os membros da
equipe. Certamente, a correo desses erros menos custosa quando de
tectada e realizada ainda no(s) modelo(s) do sistema (por exemplo,
muito mais fcil corrigir uma maquete do que pr abaixo uma parte de
um edifcio). Lembre-se: modelos de sistemas so mais baratos de cons
truir do que sistemas. Consequentemente, erros identificados sobre mo
delos tm um impacto menos desastroso.
4. Previso do comportamento futuro do sistema; o comportamento do sistema
pode ser discutido mediante uma anlise dos seus modelos. Os mode
los servem como um laboratrio, em que diferentes solues para
um problema relacionado construo do sistema podem ser experi
mentadas.
princpios de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Outra questo importante sobre como so os moJe.c-s de sistemas de soft


ware. Em construes civis, freqentemente h prosf. ^rjiis para analisar as
plantas da construo. A partir dessas, que podem ser -.-.sls ; ; mo modelos, os
profissionais tomam decises sobre o andamento da : r :i *' - -*5 wjC ^15tCm3,S
de software no so muito diferentes dos modelos de s:s:-; Oi . nstruo ci
vil. Nos prximos captulos, apresentaremos diversos rr.:o-:.:s compo
nentes so desenhos grficos que seguem algum padro .: r. -: Es sos desenhos
so normalmente denominados diagramas. Um diagrama arresentao
de uma coleo de elementos grficos que possuem um sigmf:. j o : rredefinido.
Talvez o fato de os modelos serem representados por uiarrarr.as possa ser
explicado pelo ditado: uma figura vale por mil palavras". C-racas a.cs desenhos
grficos que modelam o sistema, os desenvolvedores tir. ama representao
concisa do sistema. No entanto, modelos de sistemas de sor.vare tambm so
compostos de informaes textuais. Embora um diagrama const ea expressar di
versas informaes de forma grfica, em diversos momentos b_a a necessidade
de adicionar informaes na forma de texto, com o objetivo de explicar ou defi
nir certas partes desse diagrama. Dado um modelo de uma das perspiectivas de
um sistema, diz-se que o seu diagrama, juntamente com a informao textual
associada, formam a documentao desse modelo.

A modelagem de sistemas de software consiste na utilizao de notaes gra*icas


e textuais com o objetivo de construir modelos que representam as partes essen
ciais de um sistema, considerando-se vrias perspectivas diferentes e comple
mentares.

1.2 0 paradigma da orientao a objetos


Indispeensvel ao desenvolvimento atual de sistemas de software o paradigma
da orientao a objetos. Esta seo descreve o que esse termo significa e justifica
por que a orientao a objetos importante para a modelagem de sistemas. Po
de-se comear pela definio da palavra paradigma. Essa palavra possui diver
sos significados, mas o que mais se aproxima do sentido aqui utilizado encon
tra-se no dicionrio Aurlio Sculo XXI:

paradigm a . [Do gr. pardeigma, pelo lat. tard. paradigma.] S. m. Termo


com o qual Thomas Kuhn designou as realizaes cientficas (p. ex., a
dinmica de Newton ou a qumica de Lavoisier) que geram modelos
que, por perodo mais ou menos longo e de modo mais ou menos expl
cito, orientam o desenvolvimento posterior das pesquisas exclusiva
mente na busca da soluo para os problemas por elas suscitados.
VISAO GERAL

Para o leitor que ainda no se sentiu satisfeito com essa definio, temos
aqui uma outra, mais consisa e apropriada ao contexto deste livro: um paradig
ma uma form a de abordar um problema. Como exemplo, considere a famosa
histria da ma caindo sobre a cabea de Isaac Newton, citado na definio an-
teriord Em vez de pensar que somente a ma estava caindo sobre a Terra, New
ton tambm considerou a hiptese de o prprio planeta tambm estar caindo
sobre a ma! Essa outra maneira de abordar o problema pode ser vista como
um paradigma.
Pode-se dizer, ento, que o termo paradigma da orientao a objetos
uma forma de abordar um problema. H alguns anos, Alan Kay, um dos pais do
paradigma da orientao a objetos, formulou a chamada analogia biolgica.
Nessa analogia, ele imaginou como seria um sistema de software que funcionas
se como um ser vivo. Nesse sistema, cada clula interagiria com outras clulas
atravs do envio de mensagens para realizar um objetivo comum. Alm disso,
cada clula se comportaria como uma unidade autnoma.
De uma forma mais geral, Kay pensou em como construir um sistema de
software a partir de agentes autnomos que interagem entre si. Ele, ento, esta
beleceu os seguintes princpios da orientao a objetos:

1. Qualquer coisa um objeto.


2. Objetos realizam tarefas por meio da requisio de servios a outros ob
jetos.
3. Cada objeto pertence a uma determinada classe. Uma classe agrupa obje
tos similares.
4. A classe um repositrio para comportamento associado ao objeto.
5. Classes so organizadas em hierarquias.

Vamos ilustrar esses princpios com a seguinte histria: suponha que al


gum queira comprar uma pizza. Chame este algum de Joo. Ele est muito
ocupado em casa e resolve pedir sua pizza por telefone. Joo liga para a pizzaria
e faz 0 pedido. Informa ao atendente (digamos, o Jos) seu nome, as caractersti
cas da pizza desejada e o seu endereo. Jos, que s tem a funo de atendente,
comunica Maria, funcionria da pizzaria e responsvel por preparar as pizzas,
qual pizza deve ser feita. Quando Maria termina de fazer a pizza, Jos chama
Antnio, o entregador. Finalmente, Joo recebe a pizza desejada das mos de
Antnio meia hora depois de t-la pedido.
Pode-se observar que o objetivo dejoo foi atingido graas colaborao de
diversos agentes, os funcionrio da pizzaria. Na terminologia do paradigma da
orientao a objetos, esses objetos so denominados objetos. H diversos obje-

Talvez tal histria no seja verdica, mas ilustra bem o conceito que quero passar.
PRNCPOS Of AMALSf f PROJETO Of SfSFflVAS COM OML, V E ELSEVIER

tos na histria (1^princpio): Joo, Maria, Jos, Antnio. Todos colaboram com
uma parte, e o objetivo alcanado quando todos trabalham juntos ( 2 - princ
pio). Alm disso, o comportamento esperado de Antnio o mesmo esperado
de qualquer entregador. Diz-se que Antnio um objeto da classe Entregador
(3- princpio). Um comportamento comum a todo entregador, no somente a
Antnio, o de entregar a mercadoria no endereo especificado (4- princpio).
Finalmente, Jos, o atendente, tambm um ser humano, tambm mamfero,
tambm um animal etc. (5- princpio).
Mas o que o paradigma da orientao a objetos tem a ver com a modela
gem de sistemas? Antes da orientao a objetos, um outro paradigma era uti
lizado na modelagem de sistemas:^ o paradigma estruturado. Nesse paradig
ma, os elementos so dados e processos. Os processos agem sobre os dados
para que um objetivo seja alcanado. Por outro lado, no paradigma da orien
tao a objetos, h um elemento, o objeto, uma unidade autnoma que con
tm seus prprios dados que so manipulados pelos processos definidos
para o objeto e que interage com outros objetos para alcanar um objetivo.
o paradigma da orientao a objetos que os seres humanos utilizam no coti
diano para a resoluo de problemas. Uma pessoa atende a mensagens (re
quisies) para realizar um servio; essa mesma pessoa envia mensagens a
outras para que estas realizem servios. Por que no aplicar essa mesma for
ma de pensar modelagem de sistemas?

0 paradigma da orientao a objetos visualiza um sistema de software como uma


coleo de agentes interconectados chamados objetos. Cada objeto respons
vel por realizar tarefas especficas. pela interao entre objetos que uma tarefa
computacional realizada.

Pode-se concluir que a orientao a objetos, como tcnica para modelagem


de sistemas, diminui a diferena semntica entre a realidade sendo modelada e
os modelos construdos. Este livro descreve o papel importante da orientao a
objetos na modelagem de sistemas de software atualmente. Explcita ou impli
citamente, as tcnicas de modelagem de sistemas aqui descritas utilizam os
princpios que Alan Kay estabeleceu h mais de 30 anos. As sees a seguir con
tinuam descrevendo os conceitos principais da orientao a objetos.

^ Na verdade, tanto o paradigma estruturado quanto o paradigma orientado a objetos surgiram nas lin
guagens de programao, para depois serem aplicados modelagem de sistemas. De fato, as idias de
Alan Kay foram aplicadas na construo de uma das primeiras linguagens de programao orientadas a
objetos: o SmallTalk.
VISAO GERAL
ELSEVIER

Um sistema de software orientado a objetos consiste em objetos em colaborao


com 0 objetivo de realizar as funcionalidades desse sistema. Cada objeto respon
svel por tarefas especficas. graas cooperao entre objetos que a computa
o do sistema se desenvolve.

1.2.1 Classes e objetos


o mundo real formado de coisas. Como exemplos dessas coisas, pode-se citar
um cliente, uma loja, uma venda, um pedido de compra, um fornecedor, este li
vro etc. Na terminologia de orientao a objetos, essas coisas do mundo real so
denominadas objetos.
Seres humanos costumam agrupar os objetos. Provavelmente, os seres hu
manos realizam esse processo mental de agrupamento para tentar gerenciar a
complexidade de entender as coisas do mundo real. Realmente, bem mais fcil
entender a idia cavalo do que entender todos os cavalos que existem. Na termi
nologia da orientao a objetos, cada idia denominada classe de objetos, ou
simplesmente classe. Uma classe uma descrio dos atributos e servios co
muns a um grupo de objetos. Sendo assim, pode-se entender uma classe como
sendo um molde a partir do qual objetos so construdos. Ainda sobre termino
logia, diz-se que um objeto uma instncia de uma classe.
Por exemplo, quando se pensa em um cavalo, logo vem mente um animal
de quatro patas, cauda, crina etc. Pode ser que algum dia voc veja dois cavalos,
um mais baixo que o outro, um com cauda maior que o outro, ou mesmo, por
um infeliz acaso, um cavalo com menos patas que o outro. No entanto, voc ain
da ter certeza de estar diante de dois cavalos. Isso porque a idia (classe) cavalo
est formada na mente dos seres humanos, independentemente das pequenas
diferenas que possam haver entre os exemplares (objetos) da idia cavalo.
importante notar que uma classe uma abstrao das caractersticas de
um grupo de coisas do mundo real. Na maioria das vezes, as coisas do mundo
real so muito complexas para que todas as suas caractersticas sejam represen
tadas em uma classe. Alm disso, para fins de modelagem de um sistema, so
mente um subconjunto de caractersticas pode ser relevante. Portanto, uma
classe representa uma abstrao das caractersticas relevantes do mundo real.
Finalmente, preciso atentar para o fato de que alguns textos sobre orienta
o a objetos (inclusive este livro !) utilizam os termos classe e objeto de maneira
equivalente para denotar uma classe de objetos.

1.2.2 Mensagens
D-se o nome de operao a alguma ao que um objeto sabe realizar quando so
licitado. De uma forma geral, um objeto possui diversas operaes. Objetos no
princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

executam suas operaes aleatoriamente. Para que uma operao em um objeto


seja executada, deve haver um estmulo enviado a esse objeto. Se um objeto for
visto como uma entidade ativa que representa uma abstrao de algo do mundo
real, ento faz sentido dizer que tal objeto pode responder a estmulos a ele
enviados (assim como faz sentido dizer que seres vivos reagem a estmulos
que recebem). Seja qual for a origem do estmulo, quando ele ocorre, diz-se que
o objeto em questo est recebendo uma mensagem requisitando que ele realize
alguma operao. Quando se diz na terminologia de orientao a objetos que
objetos de um sistema esto trocando mensagens significa que esses objetos esto
enviando mensagens uns aos outros com o objetivo de realizar alguma tarefa
dentro do sistema no qual eles esto inseridos.

Figura 1-1: Objetos interagem atravs do envio de mensagens.

1.2.3 0 papel da abstrao na orientao a objetos


Nesta seo, apresentamos os principais conceitos do paradigma da orientao
a objetos. Discutimos tambm o argumento de que todos esses conceitos so, na
verdade, a aplicao de um nico conceito mais bsico, o princpio da abstrao.
Primeiramente, vamos descrever o conceito de abstrao. A abstrao um
processo mental pelo qual ns seres humanos nos atemos aos aspectos mais im
portantes (relevantes) de alguma coisa, ao mesmo tempo que ignoramos os as
pectos menos importantes. Esse processo mental nos permite gerenciar a com
plexidade de um objeto, ao mesmo tempo que concentramos nossa ateno nas
caractersticas essenciais do mesmo. Note que uma abstrao de algo depen
dente da perspectiva (contexto) sobre a qual uma coisa analisada: o que im
portante em um contexto pode no ser importante em outro. Nas prximas se-
ViSAOGE?-. 9

Figura 1-2: Princpios da orientao a objetos podem ser w to s


como aplicaes de um princpio mais bsico, o da abstrao.

es, descrevemos alguns conceitos fundamentais da orientao a objetos e es


tabelecemos sua correlao com o conceito de abstrao.

1.2.3.1 Encapsulamento
Objetos possuem comportamento. O termo comportamento diz respeito a ope
raes realizadas por um objeto, conforme este objeto receba mensagens. O me
canismo de encapsulamento uma forma de restringir o acesso ao comporta
mento interno de um objeto. Um objeto que precise da colaborao de outro ob
jeto para realizar alguma operao simplesmente envia uma mensagem a este
ltimo. Segundo o mecanismo do encapsulamento, o mtodo que o objeto re
quisitado usa para realizar a operao no conhecido dos objetos requisitan
tes. Em outras palavras, o objeto remetente da mensagem no precisa conhecer
a forma pela qual a operao requisitada realizada; tudo o que importa a esse
objeto remetente obter a operao realizada, no importando como.
Certamente, o remetente da mensagem precisa conhecer quais operaes o
receptor sabe realizar ou que informaes este objeto receptor pode fornecer.
Para tanto, a classe de um objeto descreve o seu comportamento. Na terminolo
gia da orientao a objetos, diz-se que um objeto possui uma interface (ver Figu
ra 1-3). Em termos bastante simples, a interface de um objeto corresponde ao
que ele conhece e ao que ele sabe fazer, sem, no entanto, descrever como ele co
nhece ou faz. Se visualizarmos um objeto como um provedor de servios, a in
terface de um objeto define os servios que ele pode fornecer. Conseqente-
mente, a interface de um objeto tambm define as mensagens que ele est apto a
receber e a responder. Um servio definido na interface de um objeto pode ter
vrias formas de implementao. Mas, pelo encapsulamento, a implementao
de um servio requisitado no importa ou no precisa ser conhecida pelo objeto
requisitante.
10 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Atravs do encapsulamento, a nica coisa que um objeto precisa saber para


pedir a colaborao de outro objeto conhecer a sua interface. Nada mais. Isso
contribui para a autonomia dos objetos, pois cada objeto envia mensagens a ou
tros objetos para realizar certas operaes, sem se preocupar em como se realiza
ram as operaes.
Note tambm que, de acordo com o encapsulamento, a implementao de
uma operao pode ser trocada sem que o objeto requisitante da mesma precise
ser alterado. No posso deixar de enfatizar a importncia desse aspecto no de
senvolvimento de software. Se a implementao de uma operao pode ser
substituda por outra sem alteraes nas regies do sistema que precisam dessa
operao, h menos possibilidades de propagaes de mudanas. No desenvol
vimento de software moderno, no qual os sistemas se tornam cada vez mais
complexos, fundamental manter as partes de um sistema to independentes
quanto possvel. Da a importncia do mecanismo do encapsulamento no de
senvolvimento de software orientado a objetos.
E qual a relao entre os conceitos de encapsulamento e abstrao? Pode
mos dizer que o encapsulamento uma aplicao do conceito de abstrao. A
aplicao da abstrao, neste caso, est em esconder os detalhes de funciona
mento interno de um objeto. Voltando ao contexto de desenvolvimento de
software, note a conseqncia disso sobre a produtividade do desenvolvimen
to. Se pudermos utilizar os servios de um objeto sem precisarmos entender
seus detalhes de funcionamento, claro que a produtividade do desenvolvi
mento aumenta.
VISAO GERAL 11
ELSEVIER

1.2.3.2 Polimorfismo
O polimorfismo indica a capacidade de abstrair vrias implementaes diferen
tes em uma nica interface. H algum tempo, o controle remoto de meu televi
sor quebrou. (Era realmente enfadonho ter de levantar para desligar o aparelho
ou trocar de canal). Um tempo depois, comprei um videocassete do mesmo fa
bricante de meu televisor. Para minha surpresa, o controle remoto do videocas
sete tambm funcionava para o televisor. Esse um exemplo de aplicao do
princpio do polimorfismo na vida real. Nesse caso. dois objetos do mundo real, o
televisor e o aparelho de videocassete, respondem mesma mensagem enviada.
E no contexto da orientao a ohjetos, qual a importncia e quais so as
consequncias do polimorfismo? Nesse contexto, o polimorfismo diz respeito
capacidade de duas ou mais classes de ohjetos responderem mesma mensa
gem, cada qual de seu prprio modo. O exemplo clssico do polimorfismo em
desenvolvimento de software o das formas geomtricas. Pense em uma cole
o de formas geomtricas que contenha crculos, retngulos e outras formas
especficas. Pelo princpio do polimorfismo, quando uma regio de cdigo pre
cisa desenhar os elementos daquela coleo, essa regio no deve precisar
conhecer os tipos especficos de figuras existentes: basta que cada elemento da
coleo receba uma mensagem solicitando que desenhe a si prprio. Note que
isso simplifica a regio de cdigo cliente (ou seja. a regio de cdigo que solici
tou o desenho das figuras). Isso porque essa regio de cdigo no precisa conhe
cer o tipo de cada figura. Ao mesmo tempo, essa regio de cdigo no precisa ser
alterada quando, por exemplo, uma classe correspondente a um novo tipo de
forma geomtrica (uma reta, por exemplo) tiver que ser adicionado. Esse novo
tipo deve responder mesma mensagem (solicitao) para desenhar a si pr
prio, muito embora implemente a operao a seu modo.
Note mais uma vez que, assim como no caso do encapsulamento, a abstra
o tambm aplicada para obter o polimorfismo: um objeto pode enviar a mes
ma mensagem para objetos semelhantes, mas que implementam a sua interface
de formas diferentes. O que est se abstraindo aqui so as diferentes maneiras
pelas quais os objetos receptores respondem mesma mensagem.

1.2.3.3 Generalizao (Herana)


A generalizao outra forma de abstrao utilizada na orientao a objetos. A
Seo 1.2.1 declara que as caractersticas e o comportamento comuns a um con
junto de objetos podem ser abstrados em uma classe. Dessa forma, uma classe
descreve as caractersticas e o comportamento comuns de um grupo de objetos
semelhantes. A generalizao pode ser vista como um nvel de abstrao acima
da encontrada entre classes e objetos. Na generalizao, classes semelhantes so
agrupadas em uma hierarquia (ver Figura 1-4). Cada nvel dessa hierarquia
12 prin cp io s de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

pode ser visto como um nvel de abstrao. Cada classe em um nvel da hierar
quia herda as caractersticas e o comportamento das classes s quais est asso
ciada nos nveis acima dela. Alm disso, essa classe pode definir caractersticas e
comportamento particulares. Dessa forma, uma classe pode ser criada a partir
do reuso da definio de classes preexistentes.
O mecanismo de generalizao facilita o compartilhamento de comporta
mento comum entre um conjunto de classes semelhantes. Alm disso, as dife
renas ou variaes entre classes em relao ao qual comum entre elas podem
ser organizadas de forma mais clara.

Maior
Figura
abstrao
A

Figura Geomtrica Linha

T
Menor
abstrao
Figura 1-4: Principio da generalizao; classes podem ser organizadas em hierarquias.

1.2.3.4 Composio
natural para ns seres humanos pensarmos em coisas do mundo real como
objetos compostos de outros objetos. Por exemplo, um livro composto de
pginas; pginas possuem pargrafos; pargrafos possuem frases, e assim por
diante. Outro exemplo: uma televiso contm um painel de controle, uma tela.
Da mesma forma que o livro e a televiso podem ser vistos como objetos por eles
prprios, seus respectivos componentes tambm podem ser vistos como obje
tos. De uma forma geral objetos podem ser compostos de outros objetos; esse o
princpio da composio. A composio permite que criemos objetos a partir da
reunio de outros objetos.

1.3 Evoluo histrica da modelagem de sistemas


A Lei de Moore bastante conhecida na rea da computao. Embora, seja co
nhecida como lei, foi apenas uma declarao, feita em 1965 pelo engenheiro
Gordon Moore, co-fundador da Intel. A Lei de Moore estabelece que a densi-
sa ; 3

dade de um transistor dobra em um perodo entre 18 e 24 meses. Isso significa


que se um processador pode ser construdo hoje com capacidade de processa
mento P, em 24 meses, pode-se construir um processador com capacidade 2P.
Em 48 meses, pode-se construir um com capacidade 4P, e assim por diante. Ou
seja, a Lei de Moore implica uma taxa de crescimento exponencial na capacidade
de processamento dos computadores.^
O que a Lei de Moore tem a ver com a modelagem de sistemas? Bom, prova
velmente o ditado a necessidade a me das invenes tambm se aplique a
esse caso. O rpido crescimento da capacidade computacional das mquinas re
sultou na demanda por sistemas de software cada vez mais complexos, que tiras
sem proveito de tal capacidade. Por sua vez, o surgimento desses sistemas mais
complexos resultou na necessidade de reavaliao da forma de desenvolver siste
mas. Conseqentemente, desde o aparecimento do primeiro computador at os
dias de hoje, as tcnicas para a construo de sistemas computacionais evoluram
de forma impressionante, notavelmente no que tange modelagem de sistemas.
A seguir, temos um breve resumo histrico da evoluo das tcnicas de
desenvolvimento com o objetivo de esclarecer como se chegou s tcnicas
atualmente utilizadas.

Dcadas de 1950/60: os sistemas de software eram bastante simples. O de


senvolvimento desses sistemas era feito de forma ad hoc.^ Os sistemas
eram significativamente mais simples e, conseqentemente, as tcnicas
de modelagem tambm eram mais simples: era a poca dosfluxogramas e
dos diagramas de mdulos.
Dcada de 1970: nessa poca, computadores mais avanados e acessveis co
mearam a surgir. Houve uma grande expanso do mercado computacional.
Sistemas mais complexos comeavam a surgir. Por conseguinte, modelos
mais robustos foram propostos. Neste perodo, surgem a programao estru
turada , baseada nos trabalhos de David Pamas. No final dessa dcada, surge
tambm a anlise e 0 projeto estruturado, consolidados pelos trabalhos de
Tom DeMarco. Alm de Tom, os autores Larry Constantine e Edward Your-
don foram grandes colaboradores nessas tcnicas de modelagem.

^ Desde que foi declarada, a Lei de Moore vem se verificando com uma preciso impressionante. No en
tanto, alguns especialistas, incluindo o prprio Moore, acreditam que a capacidade de dobrar a capaci
dade de processamento dos processadores a cada 18 meses no seja mais possvel por volta de 2017.
importante notar que a diviso de perodos aqui apresentada meramente didtica. Na realidade,
no h uma diviso clara das diversas propostas de modelagem. Por exemplo, propostas iniciais de mo
delagem orientada a objetos podem ser encontradas j em meados da dcada de 1970.
^ Este termo significa direto ao assunto ou direto ao que interessa. Talvez o uso desse termo deiicti i
abordagem dessa primeira fase do desenvolvimento de sistemas, na qual no ha\ia um pianra
inicial. O cdigo-fonte do programa a ser construdo era o prprio modelo.
14 princpios de a n a l i s e e pro jeto de s i s t e m a s com u m e , 2/E ELSEVIER

Dcada de 1980: nessa fase, os computadores se tornaram ainda mais avan


ados e baratos. Surge a necessidade por interfaces homem-mquina
mais sofisticadas, o que originou a produo de sistemas de softwares
mais complexos. A Anlise Estruturada se consolidou na primeira metada
desta dcada com os trabalhos de Edward Yourdon, Peter Coad, Tom De-
Marco, James Martin e Chris Gane. Em 1989, Edward Yourdon lana o
clssico Anlise Estruturada Moderna, livro que se tornou uma referncia
no assunto.
Incio da dcada de 1990: esse o perodo em que surge um novo paradigma
de modelagem, a Anlise Orientada a Objetos, como resposta a dificulda
des encontradas na aplicao da Anlise Estruturada a certos domnios de
aplicao. Grandes colaboradores no desenvolvimento do paradigma
orientado a objetos so Sally Shlaer, Stephen Mellor, Rebecca Wirfs-
Brock, James Rumbaugh, Grady Booch e Ivar Jacobson.
Fim da dcada de 1990: o paradigma da orientao a objetos atinge sua matu
ridade. Os conceitos de padres de projeto, frameworks, componentes e
qualidade comeam a ganhar espao. Surge a Linguagem de Modelagem
Unificada (UML).

Um estudo mais detalhado da primeira metade da dcada de 1990 pode


mostrar que surgiram vrias propostas de tcnicas para modelagem de sistemas
segundo o paradigma da orientao a objetos. A Tabela 1-1 lista algumas das
tcnicas existentes durante esse perodo; nota-se uma grande proliferao de
propostas para modelagem orientada a objetos. Nesse perodo, era comum o
fato de duas tcnicas possurem diferentes notaes grficas para modelar uma
mesma perspectiva de um sistema. Ao mesmo tempo, cada tcnica tinha seus
pontos fortes e fracos em relao notao que utilizava. A essa altura perce
beu-se a necessidade de uma notao de modelagem que viesse a se tornar um

Tabela 1-1: Principais propostas de tcnicas de modelagem orientada


a objetos durante a dcada de 1990

Ano ' Autor (Tcnica)


1990 Shaler & Mellor
1991 Coad & Yourdon (OOAD - Object-Oriented Analysis and Design)
1993 Grady Booch (Booch Method)
1993 Ivar Jacobson (OOSE - Object-Oriented Software Engineering)
1995 James Rumbaugh et al. (OMT - Object Modeling Technique)
1996 Wirfs-Brock (Responsibility Driven Design)
1996 (Fusion)
VISAO GERAL 15

padro para a modelagem de sistemas orientados a objetos; essa notao deveria


ser aceita e utilizada amplamente pela indstria e pelos ambientes acadmicos.
Surgiram, ento, alguns esforos nesse sentido de padronizao, o que resultou
na definio daUML (Unified Modeling Language) em 1996 como a melhor can
didata para ser a linguagem unificadora de notaes, diagramas e formas de
representao existentes em diferentes tcnicas de modelagem. Descrevemos
mais detalhadamente essa proposta na prxima seo.

1.4 A Linguagem de Modelagem Unificada (UML)


A construo da UML teve muitos contribuintes, mas os principais atores no
processo foram GradyBooch, James Rumbaugh e Ivarjacobson. Esses trs pes
quisadores costumam ser chamados de os trs amigos. No processo de defini
o inicial da UML, esses pesquisadores procuraram aproveitar o melhor das ca
ractersticas das notaes preexistentes, principalmente das tcnicas propostas
anteriormente pelos trs amigos (essas tcnicas eram conhecidas pelos nomes
Booch Method, OMT e OOSE). Conseqentemente, a notao definida para a
UML uma unio de diversas notaes preexistentes, com alguns elementos re
movidos e outros elementos adicionados com o objetivo de torn-la mais ex
pressiva.
Linalmente, em 1997, a UML foi aprovada como padro pelo OMG. Desde
ento, a UML tem tido grande aceitao pela comunidade de desenvolvedores
de sistemas. A sua definio ainda est em desenvolvimento e conta com diver
sos colaboradores da rea comercial.^ Desde o seu surgimento, vrias atualiza
es foram feitas no sentido de torn-la mais clara e til. Atualmente, a especifi
cao do padro UML est na verso 2.0 (OMG, 2003).
A UML uma linguagem visual para modelar sistemas orientados a objetos.
Isso quer dizer que a UML uma linguagem que define elem entos grficos (vi
suais) que podem ser utilizados na modelagem de sistemas. Esses elementos
permitem representar os conceitos do paradigma da orientao a objetos. Atra
vs dos elementos grficos definidos nesta linguagem pode-se construir diagra
mas que representam diversas perspectivas de um sistema.
Cada elemento grfico da UML possui uma sintaxe e uma semntica. A sinta
xe de um elemento corresponde forma predeterminada de desenhar o elemen
to. A semntica define o que significa o elemento e com que objetivo ele deve ser
utilizado. Alm disso, conforme descrito mais adiante, tanto a sintaxe quanto a
semntica dos elementos da UML so extensveis. Essa extensibilidade permite

Sigla para Object Management Group. O OMG um consrcio internacional de empresa que define e
ratifica padres na rea da orientao a objetos.
^ Algumas das empresas que participam da definio da UML so: Digital, HP, IBM, Oracle, Microsoft,
Unisys, IntelliCorp, i-Logix e Rational.
16 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

que a UML seja adaptada s caractersticas especficas de cada projeto de desen


volvimento.
Pode-se fazer uma analogia da UML com uma caixa de ferramentas. Um pe
dreiro usa sua caixa de ferramentas para realizar suas tarefas. Da mesma forma,
a UML pode ser vista como uma caixa de ferramentas utilizada pelos desenvol
vedores de sistemas para realizar a construo de modelos.
A UML independente tanto de linguagens de programao quanto de proces
sos de desenvolvimento. Isso quer dizer que a UML pode ser utilizada para a mo
delagem de sistemas, no importa que linguagem de programao ser utilizada
na implementao do sistema nem a forma (processo) de desenvolvimento ado
tada. Esse um fator importante para a utilizao da UML, pois diferentes siste
mas de software requerem abordagens diversas de desenvolvimento.
A definio completa da UML est contida na Especificao da Linguagem de
Modelagem Unificada da OMG. Essa especificao pode ser obtida gratuitamen
te no site da OMG (www.uml.org). Embora essa documentao seja bastante
completa, ela est longe de fornecer uma leitura fcil, pois direcionada a pes
quisadores ou a desenvolvedores de ferramentas de suporte (ferramentas
CASE; ver Seo 2.6) ao desenvolvimento de sistemas.

1.4.1 Vises de um sistema


o desenvolvimento de um sistema de software complexo demanda que seus de
senvolvedores tenham a possibilidade de examinar e estudar esse sistema a par
tir de diversas perspectivas. Os autores da UML sugerem que um sistema pode
ser descrito por cinco vises interdependentes desse sistema (Booch et al.,
2006). Cada viso enfatiza aspectos diferentes do sistema. As vises propostas
so as seguintes;

Viso de Casos de Uso: descreve o sistema de um ponto de vista externo


como um conjunto de interaes entre o sistema e os agentes externos ao
sistema. Esta viso criada inicialmente e direciona o desenvolvimento
das outras vises do sistema.
Viso de Projeto: enfatiza as caractersticas do sistema que do suporte,
tanto estrutural quanto comportamental, s funcionalidades externa
mente visveis do sistema.
Viso de Implementao: abrange o gerenciamento de verses do sistema,
construdas pelo agrupamento de mdulos (componentes) e subsistemas.
Viso de Implantao: corresponde distribuio fsica do sistema em
seus subsistemas e conexo entre essas partes.
Viso de Processo: esta viso enfatiza as caractersticas de concorrncia
(paralelismo), sincronizao e desempenho do sistema.
VISAG

Dependendo das caractersticas e da complexidade do sistema, nem todas as


vises precisam ser construdas. Por exemplo, se o sistema tiver de ser instalado
em um ambiente computacional de processador nico, no h necessidade da
viso de implantao. Outro exemplo: se o sistema for constitudo de um nico
processo, a viso de processo irrelevante. De forma geral, dependendo do sis
tema, as vises podem ser ordenadas por grau de relevncia.

1.4.2 Diagramas da UML


Um processo de desenvolvimento que utilize a UML como linguagem de supor
te modelagem envolve a criao de diversos documentos. Esses documentos
podem ser textuais ou grficos. Na terminologia da UML, esses documentos so
denominados artefatos de software, ou simplesmente artefatos. So os artefatos
que compem as vises do sistema.
Os artefatos grficos produzidos durante o desenvolvimento de um sistema
de software orientado a objetos (SSOO) podem ser definidos pela utilizao dos
diagramas da UML. Os 13 diagramas da UML 2.0 so listados na Figura 1-6. Na
figura, os retngulos com os cantos retos representam agrupamentos (tipos) de
diagramas da UML. J os retngulos com os cantos boleados representam os dia
gramas propriamente ditos.
O iniciante na modelagem de sistemas pode muito bem perguntar: Parz
que um nmero to grande de diagramas para modelar um sistema? Sera zu
um ou dois tipos de diagramas j no seriam suficientes?" Para justificar a -rs-
PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

tncia de vrios diagramas, vamos utilizar novamente uma analogia. Carrinhos


em miniatura so cpias fiis de carros de verdade. Cada um dos carrinhos um
modelo fsico tridimensional que pode ser analisado de diversas perspectivas
(por cima, por baixo, por dentro etc.). O mesmo no ocorre com os diagramas,
que so desenhos bidimensionais.

Diagramas
da UML

Diagramas Diagramas
Estruturais Comporiamentais

' Diagrama de'


Objetos

Diagrama de
Estrutura Composta.

Diagrama de
Diagrama de U Colaborao ^
Implantao Temporizao ^
InCToduzido pela UML 2.0

Diagrama de Viso
Geral da Interao^
Introduzido pela UML 2.0

Figura 1-6: Diagramas definidos pela UML.

Para compensar essa dimenso a menos, utilizam-se diversos diagramas


para construir modelos de vrias perspectivas do sistema. Cada um dos diagra
mas da UML fornece uma perspectiva parcial do sistema sendo modelado, con
sistente com as demais perspectivas. No decorrer deste livro, descreveremos os
diagramas da UML e sua utilizao na construo de modelos que fornecem as
vrias perspectivas existentes em sistemas de software.

A UML uma linguagem de modelagem visual, ou seja, um conjunto de notaes


e semntica correspondente para representar visualmente uma ou mais perspecti
vas de um sistema.
VISO GE=..;. 15

EXERCCIOS

1-1: Considere o mapa de uma cidade que mostra rodovias e prdios e que esconde a cor dos
prdios. Um mapa pode ser considerado um modelo? Por qu? Discuta as caractersticas desse
mapa com relao ao princpio da abstrao.

1-2: Identifique paralelos entre as seguintes caractersticas de uma clula e os conceitos da


orientao a objetos descritos neste captulo.
a. Mensagens so enviadas de uma clula a outra por meio de receptores qumicos.
b. Clulas tm uma fronteira (a membrana celular). Cada clula tem um comportamento interno
que no visvel de fora.
c. A clulas podem se reagrupar para resolver problemas ou para realizar uma funo.

1-3: Considere os seguintes itens: elevador, ma, a Terra, este livro, voc mesmo, o Cristo
Redentor. Ser que esses itens so objetos, de acordo com os princpios estabelecidos por
Alan Kay?

1-4: 0 termo modelagem bastante amplo e popular. As reas da Matemtica, Filosofia, Psi
quiatria e Qumica, por exemplo, tambm utilizam esse termo. Discuta com um profissional de
algumas dessas reas se h qualquer correlao entre a noo de modelagem por ele utilizada e
a noo utilizada no contexto deste captulo.

1 -5: Explique e relacione os termos objeto, classe, generalizao e mensagem. D exemplos de


cada um desses conceitos.
2
0 processodedesenvolvimento
desoftware
Quanto mais livros voc leu (ou escreveu), mais aulas assistiu (ou lecionou),
mais linguagens de programao aprendeu (ou projetou), mais software 0 0
examinou (ou produziu), mais documentos de requisitos tentou decifrar (ou
tornou decifrvel), mais padres de projeto aprendeu (ou catalogou), mais
reunies assistiu (ou conduziu), mais colegas de trabalho talentosos teve (ou
contratou), mais projetos ajudou (ou gerenciou), tanto mais voc estar
equipado para lidar com um novo desenvolvimento.
-BERTRAND MEYER

desenvolvimento de software uma atividade complexa. Essa com

0 plexidade corresponde sobreposio das complexidades relativas


ao desenvolvimento dos seus diversos componentes; software, hard
ware, procedimentos etc. Isso se reflete no alto nmero de projetos de software
que no chegam ao fim, ou que extrapolam recursos de tempo e de dinheiro alo
cados.
Para dar uma idia da complexidade no desenvolvimento de sistemas de
software, so listados a seguir alguns dados levantados no Chaos Report, um es
tudo clssico feito pelo Stanish Group sohre projetos de desenvolvimento
(Chaos, 1994).

Porcentagem de projetos que terminam dentro do prazo estimado: 10%.


Porcentagem de projetos que so descontinuados antes de chegarem ao
fim: 25%.
Porcentagem de projetos acima do custo esperado; 60%.
Atraso mdio nos projetos: um ano.

Tentativas de lidar com essa complexidade e de minimizar os pn


volvidos no desenvolvimento de software envolvem a definio dr
22 princpios de a n a l i s e e pro jeto oe s i s t e m a s com u m e , 2/E E LS E V IE R

desenvolvimento de software. Um processo de desenvolvimento de software


(simplesmente processo de desenvolvimento ou metodologia de desenvolvimento)
compreende todas as atividades necessrias para definir, desenvolver, testar e
manter um produto de software. Alguns objetivos de um processo de desenvol
vimento so: definir quais as atividades a serem executadas ao longo do projeto;
quando, como e por quem tais atividades sero executadas; prover pontos de con
trole para verificar o andamento do desenvolvimento; padronizar a forma de de
senvolver software em uma organizao. Exemplos de processos de desenvolvi
mento propostos so o ICONIX, o RUP (Rational Unified Process), o EUP
(Enterprise Unified Process), XP (Extreme Programming) e o OPEN (Object-
oriented Process, Environment and Notation).

2.1 Atividades tpicas de um processo de desenvolvimento


Um processo de desenvolvimento classifica em atividades as tarefas realizadas du
rante a construo de um sistema de software. H vrios processos de desenvolvimen
to propostos. Por outro lado, um consenso na comunidade de desenvolvi
mento de software o fato de que no existe o melhor processo de desenvolvimen
to, aquele que melhor se aplica a todas as situaes de desenvolvimento.
Cada processo tem suas particularidades em relao ao modo de arranjar e
encadear as atividades de desenvolvimento. Entretanto, podem-se distinguir ati
vidades que, com uma ou outra modificao, so comuns maioria dos processos
existentes. Nesta seo, descrevemos essas atividades, posto que duas dessas ati
vidades, a anlise e o projeto, fazem parte do assunto principal desse livro.

2.1.1 Levantamento de requisitos


A atividade de levantamento de requisitos (tambm conhecida como elicitao de
requisitos) corresponde etapa de compreenso do problema aplicada ao de
senvolvimento de software. O principal objetivo do levantamento de requisitos
que usurios e desenvolvedores tenham a mesma viso do problema a ser re
solvido. Nessa etapa, os desenvolvedores, juntamente com os clientes, tentam
levantar e definir as necessidades dos futuros usurios do sistema a ser desen
volvido.^ Essas necessidades so geralmente denominadas requisitos.
Eormalmente, um requisito uma condio ou capacidade que deve ser al
canada ou possuda por um sistema ou componente deste para satisfazer um
contrato, padro, especificao ou outros documentos formalmente impostos
(Maciaszek, 2000). Normalmente os requisitos de um sistema so identificados

^Em outras literaturas, o leitor pode encontrar os termos anlise de requisitos ou projeto lgico para de
notar essa fase de definio e compreenso do problema.
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 23
ELSEVIER

a partir de um domnio. Denomina-se domnio a rea de conhecimento ou de ati


vidade especfica caracterizada por um conjunto de conceitos e de terminologia
compreendidos por especialista nessa rea. No contexto do desenvolvimento
de software, um domnio corresponde parte do mundo real que relevante, no
sentido de que algumas informaes e processos desse domnio precisam ser in
cludos no sistema em desenvolvimento. O domnio tambm chamado de do
mnio do problema ou domnio do negcio.^
Durante o levantamento de requisitos, a equipe de desenvolvimento tenta en
tender o domnio que deve ser automatizado pelo sistema de software. O levanta
mento de requisitos compreende tambm um estudo exploratrio das necessidades
dos usurios e da situao do sistema atual (se este existir). H vrias tcnicas utili
zadas para isso, como, por exemplo; leitura de obras de referncia e livros-texto, ob
servao do ambiente do usurio, realizao de entrevistas com os usurios, entrevis
tas com especialistas do domnio^ (ver a Seo 2.2.6), reutilizao de anlises anterio
res, comparao com sistemas preexistentes do mesmo domnio do negcio.
O produto do levantamento de requisitos o documento de requisitos, que
declara os diversos tipos de requisitos do sistema. normal esse documento ser
escrito em uma notao informal (em linguagem natural). As principais sees
de um documento de requisitos so:

1. Requisitos funcionais: definem as funcionalidades do sistema. Alguns


exemplos de requisitos funcionais so os seguintes.
a. O sistema deve permitir que cada professor realize o lanamento de
notas das turmas nas quais lecionou.
b. O sistema deve permitir que um aluno realize a sua matrcula nas
disciplinas oferecidas em um semestre letivo.
c. Os coordenadores de escola devem poder obter o nmero de apro
vaes, reprovaes e trancamentos em cada disciplina oferecida em
um determinado perodo.
2. Requisitos no-funcionais: declaram as caractersticas de qualidade que o
sistema deve possuir e que esto relacionadas s suas funcionalidades.
Alguns tipos de requisitos no-funcionais so os seguintes.
a. Confiabilidade: corresponde a medidas quantitativas da confiabili
dade do sistema, tais como tempo mdio entre falhas, recuperao de
falhas ou quantidade de erros por milhares de linhas de cdigo-fonte.
b. Desempenho: requisitos que definem tempos de resposta esperados
para as funcionalidades do sistema.

^ Neste livro o termo domnio tambm utilizado como sinnimo para domnio do negcio.
^ Um especialista do domnio uma pessoa que tem familiaridade com o domnio do negcio, mas no
necessariamente com o desenvolvimento de sistemas de software. Freqentemente, esses especialistas
so os futuros usurios do sistema de software em desenvolvimento.
24 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

c. Portabilidade; restries sobre as plataformas de hardware e de soft


ware nas quais o sistema ser implantado e sobre o grau de facilidade
para transportar o sistema para outras plataformas.
d. Segurana: limitaes sobre a segurana do sistema em relao a
acessos no-autorizados.
e. Usabilidade; requisitos que se relacionam ou afetam a usabilidade do
sistema. Exemplos incluem requisitos sobre a facilidade de uso e a
necessidade ou no de treinamento dos usurios.
Requisitos normativos: declarao de restries impostas sobre o desen
volvimento do sistema. Restries definem, por exemplo, a adequao a
custos e prazos, a plataforma tecnolgica, aspectos legais (licenciamen
to), limitaes sobre a interface com o usurio, componentes de hardwa
re e software a serem adquiridos, eventuais necessidades de comunica
o do novo sistema com sistemas legados etc. Restries tambm po
dem corresponder a regras do negcio, restries ou polticas de funcio
namento especficas do domnio do problema que influenciaro de um
modo ou de outro no desenvolvimento do software. Regras do negcio
so descritas na Seo 4.5.1.

Uma das formas de se medir a qualidade de um sistema de software pela


sua utilidade. E um sistema ser til para seus usurios se atender aos requisitos
definidos e se esses requisitos refletirem as necessidades dos usurios. Portanto,
os requisitos devem ser expressos de uma maneira tal que eles possam ser verifi
cados e comunicados a leitores tcnicos e no-tcnicos. A equipe tcnica (leito
res tcnicos) deve entender o documento de requisitos de tal forma a poder ob
ter solues tcnicas apropriadas. Clientes (leitores no-tcnicos) devem en
tender esse documento para que possam priorizar o desenvolvimento dos re
quisitos, conforme as necessidades da organizao em que trabalham.
Um ponto importante sobre o documento de requisitos que ele no deve
conter informaes sobre as solues tcnicas que sero adotadas para desenvol
ver o sistema. O enfoque prioritrio do levantamento de requisitos responder
claramente questo o que o usurio necessita do novo sistema?. Lembre-se
sempre: novos sistemas sero avaliados pelo seu grau de conformidade aos re
quisitos, no importa quo complexa a soluo tecnolgica tenha sido. Requisi
tos definem o problema a ser resolvido pelo sistema de software; eles no des
crevem o software que resolve o problema.
O levantamento de requisitos a etapa mais importante em termos de retor
no em investimentos feitos para o projeto de desenvolvimento. Muitos sistemas
foram abandonados ou nem chegaram a uso porque os membros da equipe no
dispensaram tempo suficiente para compreender as necessidades do cliente em
relao ao novo sistema. De fato, um sistema de informaes normalmente
0 PROCESSO DE DESENVOLVIMENTO DE SOF ,'/a =E 25

Utilizado para automatizar processos de negcio de uma organizao. Portanto,


esses processos devem ser compreendidos antes da construo do sistema de in
formaes. Em um estudo baseado em 6.700 sistemas feito em 1997, Carper Jo-
nes mostrou que os custos resultantes da m realizao dessa etapa de entendi
mento podem ser duzentas vezes maiores que o realmente necessrio (Jones,
1997).
O documento de requisitos serve como um termo de consenso entre a equi
pe tcnica (desenvolvedores) e o cliente. Esse documento constitui a base para
as atividades subseqentes do desenvolvimento do sistema e fornece um ponto
de referncia para qualquer validao futura do software construdo. O envolvi
mento do cliente desde o incio do processo de desenvolvimento ajuda a assegu
rar que o produto desenvolvido realmente atenda s necessidades identificadas.
Alm disso, o documento de requisitos estabelece o escopo do sistema (isto , o
que faz parte e o que no faz parte do sistema). O escopo de um sistema muitas
vezes muda durante o seu desenvolvimento. Dessa forma, se o escopo muda,
tanto clientes quanto desenvolvedores tm um parmetro para decidir em que
medida os recursos de tempo e financeiros devem mudar. Contudo, o planeja
mento inicial do projeto deve se basear no escopo inicial.
Outro ponto importante sobre os requisitos sua caracterstica de volatili
dade. Um requisito voltil aquele que pode sofrer modificaes durante o de
senvolvimento do sistema."^ Nos primrdios da modelagem de sistemas, era co
mum a prtica de congelar os requisitos levantados antes de se iniciar a cons
truo do sistema. Isto , os requisitos considerados eram os mesmos do incio
ao fim do projeto de desenvolvimento. Atualmente, a volatilidade dos requisi
tos um fato com o qual a equipe de desenvolvimento de sistemas tem de convi
ver e conseqentemente o congelamento de requisitos impraticvel. Isso por
que, nos dias atuais, as organizaes precisam se adaptar a mudanas cada vez
mais rpidas. Durante o perodo em que o sistema est em desenvolvimento, di
versos aspectos podem mudar: as tecnologias utilizadas, as expectativas dos
usurios, as regras do negcio etc. E isso para mencionar apenas algumas poss
veis mudanas.
Isso parece se contrapor ao fato de que o documento de requisitos deve defi
nir de forma clara quais so os requisitos do sistema. Na realidade, conforme
mencionado anteriormente, o documento de requisitos serve como um consenso
inicial. O ponto principal do levantamento de requisitos compreender o sistema
o mximo possvel antes de comear a constru-lo. A regra definir completa
mente qualquer requisito j conhecido, mesmo os mais simples. medida que

^ A caracterstica de volatilidade tambm pode ser aplicada declarao de requisitos como um todo
para denotar que, durante o desenvolvimento de um produto de software, novos requisitos podem apa
recer ou requisitos preexistentes podem no ser mais necessrios.
26 prin cp io s de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

novos requisitos sejam detectados (ou que requisitos preexistentes mudem), os


desenvolvedores devem verificar cuidadosamente o impacto das mudanas resul
tantes no escopo do sistema. Dessa forma, os clientes podem decidir se tais mu
danas devem ser consideradas no desenvolvimento, uma vez que influenciam o
cronograma de desenvolvimento e os recursos financeiros alocados.
A menos que o sistema a ser desenvolvido seja bastante simples e esttico
(caractersticas raras nos sistemas atuais), praticamente impossvel pensar em
todos os detalhes a princpio. Alm disso, quando o sistema entrar em produo
e os usurios comearem a utiliz-lo, eles prprios descobriro requisitos nos
quais no tinham pensado inicialmente. Em resumo, os requisitos de um siste
ma complexo inevitavelmente mudaro durante o seu desenvolvimento.

No desenvolvimento de sistemas de software, a existncia de requisitos volteis


corresponde mais regra do que exceo.

Uma caracterstica desejvel em um documento de requisitos ter os seus


requisitos ordenados pelos usurios em funo do seu grau de prioridade. O
grau de prioridade de um requisito para os usurios normalmente estabeleci
do em funo da adio de valor que o desenvolvimento desse requisito no siste
ma trouxer aos usurios. Saber o grau de prioridade de um requisito permite
que a equipe de desenvolvimento (mais particularmente o gerente do projeto)
decida em que momento cada requisito deve ser considerado durante o desen
volvimento. As prioridades atribudas aos requisitos permitiro ao gerente de
projeto tomar decises acerca do momento no qual cada requisito deve ser con
siderado durante o desenvolvimento do sistema.

2.1.2 Anlise
De acordo com o professor Wilson de Pdua, as fases de levantamento de requisi
tos e de anlise de requisitos recebem o nome de engenharia de requisitos (Pdua,
2003). Na seo anterior, descrevemos a fase de levantamento de requisitos. Nes
ta seo, damos uma viso geral da fase de anlise de requisitos, tambm conheci
da com o fa se de anlise. Formalmente, o termo anlise corresponde a quebrar"
um sistema em seus componentes e estudar como tais componentes interagem
com o objetivo de entender como esse sistema funciona. No contexto dos siste
mas de software, esta a etapa em que os analistas (ver a Seo 2.2.2) realizam um
estudo detalhado dos requisitos levantados na atividade anterior. A partir desse
estudo, so construdos modelos para representar o sistema a ser construdo.
Assim como no levantamento de requisitos, a anlise de requisitos no leva
em conta o ambiente tecnolgico a ser utilizado. Nesta atividade, o foco de inte-
0 PROCESSO DE DESENVOLVIMENTO DE SOF^/.-^E 27

resse tentar construir uma estratgia de soluo sem se preocupar com a ma


neira como essa estratgia ser realizada. A razo desta prtica tentar obter a
melhor soluo para o problema sem se preocupar com os detalhes da tecnolo
gia a ser utilizada. Em outras palavras, necessrio saber o que o sistema propos
to deve fazer para, ento, definir como esse sistema ir faz-lo.
O termo paralisia da anlise conhecido no desenvolvimento de sistemas
de software. Esse termo denota a situao em que h uma estagnao da fase de
anlise: os analistas passam muito tempo construindo os modelos do sistema.
Embora essa situao certamente exista, na prtica raramente podemos encon
tr-la. O que costuma ocorrer na prtica exatamente o contrrio: equipes de
desenvolvimento que passam para a construo da soluo sem antes terem de
finido completamente o problema. Portanto, os modelos construdos na fase de
anlise devem ser cuidadosamente validados e verificados, atravs da validao e
verificao dos modelos, respectivamente.
O objetivo da validao assegurar que as necessidades do cliente esto sen
do atendidas pelo sistema: ser que o software correto est sendo construdo?
Com a validao, os analistas querem se assegurar de que a especificao que
construram do software correta, consistente, completa, realista e sem ambi-
gidades. Nessa atividade, os analistas apresentam os modelos criados para re
presentar o sistema aos futuros usurios para que esses modelos sejam valida
dos. Quando um usurio valida um modelo, quer dizer que entendeu o modelo
construdo e que, segundo esse entendimento, o modelo reflete suas necessida
des com relao ao sistema a ser desenvolvido. Se um modelo no bem defini
do, possvel que tanto usurios quanto desenvolvedores tenham diferentes in
terpretaes acerca do sistema a ser desenvolvido. Essas diferentes interpreta
es se originam das ambigidades e contradies em relao ao que usurios e
desenvolvedores entendem dos requisitos. Um erro na etapa de levantamento
de requisitos, se identificado tardiamente, implica a construo de um sistema
que no corresponde s expectativas do usurio. Nesses casos, o impacto nos
custos e prazos do projeto de desenvolvimento pode ser devastador. Portanto,
um fator decisivo para o sucesso de um sistema o envolvimento de especialis
tas do domnio (ver a Seo 2.2.6) durante o desenvolvimento. Por isso, a ativi
dade de validao dos requisitos por parte dos usurios to importante.
J a verificao tem o objetivo de analisar se os modelos construdos esto
em conformidade com os requisitos definidos: ser que o software est sendo
construdo corretamente? Na verificao dos modelos, so analisadas a exati
do de cada modelo em separado e a consistncia entre os modelos. Diferente da
validao (que uma atividade de anlise), a verificao uma etapa tpica da
fase de projeto (ver a Seo 2.1.3).
Em um processo de desenvolvimento orientado a objetos, um dos resulta
dos da anlise o modelo de objetos que representa as classes componentes do
28 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

sistema. Alm disso, a anlise tambm resulta em um modelo funcional do siste


ma de software a ser desenvolvido.
De acordo com (Blaha & Humbaugh, 2006), a fase de anlise pode ser sub
dividida em duas subfases: anlise do domnio (ou anlise do negcio) e anlise da
aplicao. Descrevemos essas subfases nos prximos pargrafos.
Na anlise do domnio, um primeiro objetivo identificar e modelar os ob
jetos do mundo real que, de alguma forma, sero processados pela aplicao em
desenvolvimento. Por exemplo, um aluno um objeto do mundo real que um
sistema de controle acadmico deve processar. Assim, aluno um objeto do
domnio. Uma caracterstica da anlise de domnio que os objetos identifica
dos fazem sentido para os especialistas do domnio, por conta de corresponde
rem a conceitos com o quais esses profissionais lidam diariamente em seu traba
lho. Por isso, na anlise de domnio, os analistas devem interagir com os espe
cialistas do domnio. Outros exemplos de objetos do domnio instituio de
ensino so professor, disciplina, turma, sala de aula etc. Outro objetivo da an
lise do domnio identificar as regras do negcio e os processos do negcio reali
zados pela organizao. A anlise do domnio tambm conhecida como mode
lagem do negcio ou modelagem dos processos do negcio.
A anlise do domnio normalmente seguida pela anlise da aplicao. A
anlise da aplicao tem como objetivo identificar objetos de anlise que nor
malmente no fazem sentido para os especialistas do domnio, mas que so ne
cessrios para suprir as funcionalidades do sistema em questo. Esses objetos
tm a ver com os aspectos computacionais de alto nvel da aplicao. Por exem
plo, uma tela de inscrio em disciplinas um objeto componente de uma aplica
o de controle de uma instituio de ensino. De uma forma geral, qualquer ob
jeto necessrio para que o sistema em desenvolvimento possa se comunicar
com seu ambiente um objeto da aplicao. Objetos da aplicao somente tm
sentido no contexto de um sistema de software, diferentemente dos objetos de
domnio. Note que anlise da aplicao envolve apenas a identificao desses
objetos. Essa subfase no envolve o detalhamento desses objetos. Ou seja, no
escopo da anlise da aplicao definir a forma como esses objetos sero imple
mentados; isso escopo da fase de projeto (ver Seo 2.1.3).
Sendo assim, a anlise do domnio identifica objetos do domnio, e a an
lise da aplicao identifica objetos da aplicao. Mas, por que essa separao
da anlise em duas subfases? Uma razo para isso o reuso. Na medida em
que modelamos o domnio separadamente dos aspectos especficos da apli
cao, os componentes resultantes dessa modelagem tm maior potencial de
reusabilidade no desenvolvimento de aplicao dentro do mesmo domnio
de problema.
Nas ltimas dcadas, diversas ferramentas de modelagem foram propostas
para auxiliar a realizao das atividades de anlise. De forma geral, cada ferramen-
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 29

ta til para modelar determinado aspecto de um sistema. comum utiliza-


rem-se diversas ferramentas para capturar aspectos diferentes de um problema
dado. As principais ferramentas da UML para realizar anlise so o diagrama de
casos de uso e o diagrama de classes (para a modelagem de casos de uso e de clas
ses, respectivamente). Outros diagramas da UML tambm utilizados na anlise
so: diagrama de interao, diagrama de estados e diagrama de atividades.

2.1.3 Projeto (desenho)


o foco principal da anlise so os aspectos lgicos e independentes de implemen
tao de um sistema (os requisitos). Na fase de projeto, determina-se como o
sistema funcionar para atender aos requisitos, de acordo com os recursos tecno
lgicos existentes (a fase de projeto considera os aspectos fsicos e dependentes
de implementao). Aos modelos construdos na fase de anlise so adicionadas
as denominadas restries de tecnologia. Exemplos de aspectos a serem consi
derados na fase de projeto: arquitetura do sistema, padro de interface grfica, a
linguagem de programao, o gerenciador de banco de dados etc.
Esta fase produz uma descrio computacional do que o software deve fazer
e deve ser coerente com a descrio feita na anlise. Em alguns casos, algumas
restries da tecnologia a ser utilizada j foram amarradas no levantamento de
requisitos. Em outros casos, essas restries devem ser especificadas. Mas, em
todos os casos, a fase de projeto do sistema direcionada pelos modelos cons
trudos na fase de anlise e pelo planejamento do sistema.
O projeto consiste em duas atividades principais: projeto da arquitetura
(tambm conhecido como projeto de alto nvel) e projeto detalhado (tambm co
nhecido como projeto de baixo nvel).
Durante o processo de desenvolvimento de um sistema de software orienta
do a objetos, o projeto da arquitetura consiste em distribuir as classes de objetos
relacionadas do sistema em subsistemas e seus componentes. Consiste tambm
em distribuir esses componentes fisicamente pelos recursos de hardware dispo
nveis. Os diagramas da UML normalmente utilizados nesta fase do projeto so
os diagramas de implementao. O projeto da arquitetura normalmente reali
zado pelos chamados arquitetos de software (consulte a Seo 2.2.4).
No projeto detalhado, so modeladas as colaboraes entre os objetos de
cada mdulo com o objetivo de realizar as funcionalidades do mdulo. Tam
bm so realizados o projeto da interface com o usurio e o projeto de banco de
dados, bem como so considerados aspectos de concorrncia e distribuio do
sistema. Alm disso, aspectos de mapeamento dos modelos de anlise para arte
fatos de software so tambm considerados na fase de projeto. O projeto dos al
goritmos a serem utilizados no sistema tambm uma atividade do projeto de
talhado. Os diagramas da UML utilizados nesta fase de projeto so: diagrama de
30 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEMER

classes, diagrama de casos de uso, diagrama de interao, diagrama de estados e


diagrama de atividades.
Embora a anlise e o projeto sejam descritos separadamente neste livro,
importante notar que, durante o desenvolvimento, no h uma distino assim
to clara entre essas duas fases. Principalmente no desenvolvimento de sistemas
orientados a objetos, as atividades dessas duas fases freqentemente se mistu
ram (ver Captulo 6).

2.1.4 Implementao
Na fase de implementao, o sistema codificado, ou seja, ocorre a traduo da
descrio computacional obtida na fase de projeto em cdigo executvel me
diante o uso de uma ou mais linguagens de programao.
Em um processo de desenvolvimento orientado a objetos, a implementao
envolve a criao do cdigo-fonte correspondente s classes de objetos do siste
ma utilizando linguagens de programao como C#, C++, Java etc. Alm da co
dificao desde o incio, a implementao pode tambm reutilizar componentes
de software, bibliotecas de classes e frameworks para agilizar a atividade.

2.1.5 Testes
Diversas atividades de teste so realizadas para verificao do sistema constru
do, levando-se em conta a especificao feita na fase de projeto. O principal pro
duto dessa fase o relatrio de testes, com informaes sobre erros detectados
no software. Aps a atividade de testes, os diversos mdulos do sistema so inte
grados, resultando finalmente no produto de software.

2.1.6 Implantao
o sistema empacotado, distribudo e instalado no ambiente do usurio. Os
manuais do sistema so escritos, os arquivos so carregados, os dados so im
portados para o sistema, e os usurios treinados para utilizar o sistema correta
mente. Em alguns casos, aqui tambm ocorre a migrao de sistemas de softwa
re e de dados preexistentes.

2.2 0 componente humano (participantes do processo)


o desenvolvimento de software uma tarefa altamente cooperativa. Tecnolo
gias complexas demandam especialistas em reas especficas. Uma equipe de
desenvolvimento de sistemas de software pode envolver vrios especialistas,
como, por exemplo, profissionais de informtica para fornecer o conhecimento
tcnico necessrio ao desenvolvimento do sistema de software e especialistas do
domnio para o qual o sistema de software deve ser desenvolvido.
0 PROCESSO DE DESENVOLVIMENTO DE SOFTV\'ARE 31

Uma equipe de desenvolvimento de software tpica consiste em um gerente,


analistas, projetistas, programadores, clientes e grupos de avaliao de qualida
de. Esses participantes do processo de desenvolvimento so descritos a seguir.
Contudo, importante notar que a descrio dos participantes do processo tem
mais um fim didtico. Na prtica, a mesma pessoa desempenha diferentes fun
es e, por outro lado, uma mesma funo normalmente desempenhada por
vrias pessoas.

Em virtude de seu tamanho e sua complexidade, o desenvolvimento de sistemas


de software um empreendimento realizado em equipe.

2.2.1 Gerentes de projeto


Como o prprio nome diz, o gerente de projetos o profissional responsvel
pela gerncia ou coordenao das atividades necessrias construo do siste
ma. Esse profissional tambm responsvel por fazer o oramento do projeto
de desenvolvimento, como, por exemplo, estimar o tempo necessrio para o de
senvolvimento do sistema, definir qual o processo de desenvolvimento, o cro-
nograma de execuo das atividades, a mo-de-obra especializada, os recursos
de hardware e software etc.
O acompanhamento das atividades realizadas durante o desenvolvimento
do sistema tambm tarefa do gerente do projeto. sua funo verificar se os
diversos recursos alocados esto sendo gastos na taxa esperada e, caso contr
rio, tomar providncias para adequao dos gastos.
Questes como identificar se o sistema factvel, escalonar a equipe de desen
volvimento e definir qual o processo de desenvolvimento a ser utilizado tam
bm devem ser cuidadosamente estudadas pelo gerente do projeto.

2.2.2 Analistas
o analista de sistemas o profissional que deve ter conhecimento do domnio do
negcio. Esse profissional deve entender os problemas do domnio do negcio
para que possa definir os requisitos do sistema a ser desenvolvido. Analistas de
vem estar aptos a se comunicar com especialistas do domnio para obter conhe
cimento acerca dos problemas e das necessidades envolvidas na organizao
empresarial. O analista no precisa ser um especialista. Contudo, ele deve ter
suficiente domnio do vocabulrio da rea de conhecimento na qual o sistema
ser implantado para que, ao se comunicar com o especialista de domnio, este
no precise ser interrompido a todo o momento para explicar conceitos bsicos
da rea.
32 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Uma caracterstica do analista de sistemas ser o profissional responsvel


por entender as necessidades dos clientes em relao ao sistema a ser desenvol
vido e repassar esse entendimento aos demais desenvolvedores do sistema (ver
as Sees 2.1.1 e 2.1.2). Neste sentido, o analista de sistemas representa uma
ponte de comunicao entre duas faces; a dos profissionais de computao
e a dos profissionais do negcio.
Para realizar suas funes, o analista deve entender no s do domnio do
negcio da organizao, mas tambm ter slido conhecimento dos aspectos re
lativos modelagem de sistemas. Neste sentido, o analista de sistemas funciona
como um tradutor, que mapeia informaes entre duas linguagens diferentes:
a dos especialistas do domnio e a dos profissionais tcnicos da equipe de desen
volvimento. Em alguns casos, h profissionais em uma equipe de desenvolvi
mento para desempenhar dois papis distintos: o de analista de negcios e o de
analista de sistemas. O analista de negcios responsvel por entender o que o
cliente faz, por que ele o faz, e determinar se as prticas atuais da organizao
realmente fazem sentido. O analista do negcio tem que fazer isso a partir da
considerao de diferentes (e muitas vezes conflitantes) perspectivas. J o ana
lista de sistemas especializado em traduzir as necessidades do usurio em ca
ractersticas de um produto de software.
Graas experincia adquirida com a participao no desenvolvimento de
diversos projetos, alguns analistas se tornam gerentes de projetos. Na verdade,
as possibilidades de evoluo na carreira de um analista so bastante grandes.
Isso se deve ao fato de que, durante a fase de levantamento de requisitos de um
sistema, o analista se torna quase um especialista no domnio do negcio da or
ganizao. Para algumas organizaes, bastante interessante ter em seus qua
dros profissionais que entendam ao mesmo tempo de tcnicas de desenvolvi
mento de sistemas e do processo de negcio da empresa. Por essa razo, no
rara a situao em que uma organizao oferece um contrato de trabalho ao ana
lista de sistemas no final do desenvolvimento do sistema.
Uma caracterstica importante que um analista deve ter a capacidade de
comunicao, tanto escrita quanto falada, pois ele um agente facilitador da co
municao entre os clientes e a equipe tcnica. Muitas vezes, as capacidades de
se comunicar agilmente e de ter um bom relacionamento interpessoal so mais
importantes para o analista do que o conhecimento tecnolgico.
Outra caracterstica necessria a um analista a tica profissional. Muitas ve
zes, esse profissional est em contato com informaes sigilosas e estratgicas den
tro da organizao na qual est trabalhando. Os analistas tm acesso a informaes
como preos de custo de produtos, margens de lucro aplicadas, algoritmos proprie
trios etc. Certamente, pode ser desastroso para a organizao se informaes de
carter confidencial como essas carem em mos erradas. Portanto, a tica profis
sional do analista na manipulao dessas informaes fundamental.
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 33

2.2.3 Projetistas
o projetista de sistemas o integrante da equipe de desenvolvimento cujas fun
es so (1) avaliar as alternativas de soluo (da definio) do problema resul
tante da anlise e (2) gerar a especificao de uma soluo computacional deta
lhada. A tarefa do projetista de sistemas muitas vezes chamada de projeto fsico.^
Na prtica, existem diversos tipos de projetistas. Pode-se falar em projetistas
de interface (especializados nos padres de uma interface grfica, como o Win
dows ou o MacOS), de redes (especializados no projeto de redes de comunicao),
de bancos de dados (especializados no projeto de bancos de dados), e assim por
diante. O ponto comum a todos esses tipos que eles trabalham nos modelos re
sultantes da anlise para adicionar os aspectos tecnolgicos a tais modelos.

2.2.4 Arquitetos de software


Um profissional encontrado principalmente em grandes equipes reunidas para
desenvolver sistemas complexos o arquiteto de software. O objetivo desse
profissional elaborar a arquitetura do sistema como um todo. ele quem toma
decises sobre quais so os subsistemas que compem o sistema como um todo
e quais so as interfaces entre esses subsistemas.
Alm de tomar decises globais, o arquiteto tambm deve ser capaz de to
mar decises tcnicas detalhadas (por exemplo, decises que tm influncia no
desempenho do sistema). Esse profissional tambm trabalha em conjunto com
o gerente de projeto para priorizar e organizar o plano de projeto.

2.2.5 Programadores
Esse profissional o responsvel pela implementao do sistema. comum haver
vrios programadores em uma equipe de desenvolvimento. Um programador
pode ser proficiente em uma ou mais linguagens de programao, alm de ter
conhecimento sobre bancos de dados e poder ler os modelos resultantes do tra
balho do projetista.
Na verdade, a maioria das equipes de desenvolvimento possui analistas que
realizam alguma programao, e programadores que realizam alguma anlise.
No entanto, para fins didticos, podemos enumerar algumas diferenas entre as
atividades desempenhadas por esses profissionais. Em primeiro lugar, o analis
ta de sistemas est envolvido em todas as etapas do desenvolvimento, diferente-

^Note que o termo projeto tem diferentes interpretaes no contexto do desenvolvimento de sistemas de
software, podendo significar o conjunto de atividades para o desenvolvimento de um sistema de softwa
re. No entanto, projeto tambm pode significar uma das atividades desse desenvoKmento. No decorrer
deste livro, o termo projeto de desenvolvimento utilizado para denotar o primeiro significado. O terrrx:
projeto utilizado para denotar o segundo significado.
34 prin cp io s de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

mente do programador, que participa unicamente das fases finais (implementa


o e testes). Outra diferena que analistas de sistemas devem entender tanto
de tecnologia de informao quanto do processo de negcio; programadores
tendem a se preocupar somente com os aspectos tecnolgicos do desenvolvi
mento.
Muitas vezes, bons programadores so promovidos a analistas de siste
mas. Essa uma prtica comum nas empresas de desenvolvimento de software e
baseada na falsa lgica de que bons programadores sero bons analistas de sis
temas. A verdade que no se pode ter certeza de que um bom programador ser
um bom analista. Alm disso, um programador no to talentoso pode se tornar
um timo analista. De fato, uma crescente percentagem de analistas sendo for
mados tem uma formao anterior diferente de computao. Por outro lado, um
analista de sistemas deve ter algum conhecimento de programao para que
produza especificaes tcnicas de um processo de negcio para serem passa
das a um programador.

2.2.6 Especialistas do domnio


Um outro componente da equipe de desenvolvimento o especialista do dom
nio, tambm conhecido como especialista do negcio. Esse componente o indi
vduo, ou grupo de indivduos, que possui conhecimento acerca da rea ou do
negcio em que o sistema em desenvolvimento estar inserido. Um termo mais
amplo que especialista de domnio cliente. Podem-se distinguir dois tipos de
clientes: o cliente usurio e o cliente contratante. O cliente usurio o indivduo
que efetivamente utilizar o sistema. O cliente usurio normalmente um espe
cialista do domnio. com esse tipo de cliente que o analista de sistemas intera
ge para levantar os requisitos do sistema. O cliente contratante o indivduo
que solicita o desenvolvimento do sistema. Ou seja, esse usurio quem enco
menda e patrocina os custos de desenvolvimento e manuteno.
Em pequenas organizaes, o cliente usurio e o cliente proprietrio so a
mesma pessoa. J em grandes organizaes, o cliente proprietrio faz parte da
gerncia e responsvel por tomadas de decises estratgicas dentro da empre
sa, enquanto o cliente usurio o responsvel pela realizao de processos ope
racionais.
H casos em que o produto de software no encomendado por um cliente.
Em vez disso, o produto desenvolvido para posteriormente ser comercializa
do. Esses produtos de software so normalmente direcionados para o mercado
de massa. Exemplos de produtos de software nessa categoria so: processado
res de texto, editores grficos, jogos eletrnicos etc. Nesses casos, a equipe de
desenvolvimento trabalha com o pessoal de marketing como se estes fossem os
clientes reais.
0 PROCESSO DE DESENVOLVIMENTO DE SOF ,',- =E 35

Em qualquer caso, a participao do cliente usurio no processo de desen


volvimento de suma importncia. O distanciamento de usurios do desenvol
vimento do sistema se manifesta, sobretudo, em projetos que excedem o seu or
amento, esto atrasados ou que no correspondam s reais necessidades. Mes
mo que o analista entenda exatamente o que o usurio necessitava inicialmente,
se o sistema construdo no contemplar as necessidades atuais desse cliente,
ainda ser um sistema intil. A nica maneira de se ter um usurio satisfeito
com o sistema de informaes torn-lo um legtimo participante fio desenvol
vimento do sistema.

No importa qual seja o processo de desenvolvimento utilizado; o envolvimento do


especialista do domnio no desenvolvimento de um sistema de software de fun
damental importncia.

2.2.7 Avaliadores de qualidade


o desempenho e a confiabilidade so exemplos de caractersticas que devem ser
encontradas em um sistema de software de boa qualidade. Avaliadores de quali
dade asseguram a adequao do processo de desenvolvimento e do produto de
software sendo desenvolvido aos padres de qualidade estabelecidos pela orga
nizao.

2.3 Modelos de ciclo de vida


o desenvolvimento de um sistema envolve diversas fases, descritas na Seo
2.1. A um encadeamento especfico dessas fases para a construo do sistema
d-se o nome de Modelo de Ciclo de Vida. H diversos Modelos de Ciclo de
Vida. A diferena entre um e outro est na maneira como as diversas fases so
encadeadas. Nesta seo, dois modelos de ciclo de vida de sistema so descritos:
o modelo em cascata e o modelo iterativo e incremental.

2.3.1 0 modelo de ciclo de vida em cascata


Este ciclo de vida tambm chamado de clssico ou linear e se caracteriza por pos
suir uma tendncia na progresso seqencial entre uma fase e a seguinte. Even
tualmente, pode haver uma retroalimentao de uma fase para a fase anterior, mas,
de um ponto de vista macro, as fases seguem seqencialmente (ver Figura 2-1).
H diversos problemas associados a esse tipo de ciclo de vida, todos prove
nientes de sua caracterstica principal: a seqencialidade das fases. A seguir, so
descritos alguns desses problemas:
36 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Figura 2-1: A abordagem de desenvolvimento de software em cascata.

1. Projetos de desenvolvimento reais raramente seguem o fluxo sequencial


que esse modelo prope. Tipicamente, algumas atividades de desenvol
vimento podem ser realizadas em paralelo.
2. A abordagem clssica presume que possvel declarar detalhadamen
te todos os requisitos antes do incio das demais fases do desenvolvi
mento (veja a discusso sobre requisitos volteis na Seo 2.1.1). Nes
sa hiptese possvel que recursos sejam desperdiados na constru
o de um requisito incorreto. Tal falha pode se propagar por todas as
fases do processo, s sendo detectada quando o usurio comear a uti
lizar o sistema.
3. Uma verso de produo^ do sistema no estar pronta at que o ciclo do
projeto de desenvolvimento chegue ao final. Como as fases so realiza
das seqencialmente, a implantao do sistema pode ficar muito distan
ciada no tempo da fase inicial em que o sistema foi encomendado. Sis
temas grandes em complexidade podem levar meses ou at anos para se
rem desenvolvidos. Nesses tempos de grande concorrncia entre as em
presas, difcil pensar que o usurio espere pacientemente at que o sis
tema todo esteja pronto para ser utilizado. Mesmo se isso acontecer,
pode haver o risco de que o sistema j no corresponda mais s reais ne
cessidades de seus usurios, em virtude de os requisitos terem mudado
durante o tempo de desenvolvimento.

Apesar de todos os seus problemas, o modelo de ciclo de vida em cascata foi


utilizado durante muitos anos (juntamente com o paradigma de modelagem es
truturada). Atualmente, devido complexidade cada vez maior dos sistemas,
esse modelo de ciclo de vida pouco utilizado. Atualmente, os modelos de ciclo

Uma verso de produo (em contraposio ao termo verso de desenvolvimento) de um software


uma verso que pode ser utilizada pelo usurio.
0 PROCESSO DE DESENVOLVIMENTO DE SOI^' 37

de vida mais utilizados para o desenvolvimento de sistemas complexos so os


que usam a abordagem incremental e iterativa, descrita a seguir.

2.3.2 0 modelo de ciclo de vida iterativo e incremental


o modelo de ciclo de vida incremental e iterativo foi proposto como uma res
posta aos problemas encontrados no modelo em cascata. Um processo de desen
volvimento segundo essa abordagem divide o desenvolvimento de um produto
de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identifica
das as fases de anlise, projeto, implementao e testes. Essa caracterstica con
trasta com a abordagem clssica, na qual as fases de anlise, projeto, implemen
tao e testes so realizadas uma nica vez.
Cada um dos ciclos considera um subconjunto de requisitos. Os requisi
tos so desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvi
mento. No prximo ciclo, um outro subconjunto dos requisitos considera
do para ser desenvolvido, o que produz um novo incremento do sistema que
contm extenses e refinamentos sobre o incremento anterior. Assim, o de
senvolvimento evolui em verses, ao longo da construo incremental e ite
rativa de novas funcionalidades at que o sistema completo esteja constru
do. Note que apenas uma parte dos requisitos considerada em cada ciclo de
desenvolvimento. Na verdade, um modelo de ciclo de vida iterativo e incre
mental pode ser visto como uma generalizao da abordagem em cascata; o
software desenvolvido em incrementos e cada incremento desenvolvido
em cascata (ver Figura 2-2).
A abordagem incremental e iterativa somente possvel se existir um meca
nismo para dividir os requisitos do sistema em partes, para que cada parte seja
alocada a um ciclo de desenvolvimento. Essa alocao realizada em funo do
grau de importncia atribudo a cada requisito. Os fatores considerados no par-

Figura 2-2: No processo incremental e iterativo, cada iterao uma minicascata .


38 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

ticionamento so a prioridade (importncia do requisito para o cliente; ver Se


o 2.1.1) eo risco de cada requisito. funo do gerente de projeto alocar os re
quisitos aos ciclos de desenvolvimento. Na Seo 4.6, descrita uma maneira
indireta de alocar os requisitos aos ciclos de desenvolvimento, atravs dos casos
de uso do sistema.

No modelo de ciclo de vida incrementai e Iterativo, um sistema de software de


senvolvido em vrios passos similares (iterativo). Em cada passo, o sistema es
tendido com mais funcionalidades (incremental).

A abordagem incremental incentiva a participao do usurio nas ativida


des de desenvolvimento do sistema, o que diminui em muito a probabilidade de
interpretaes erradas em relao aos requisitos levantados.
Vrios autores consideram uma desvantagem da abordagem incremental e
iterativa o usurio se entusiasmar excessivamente com a primeira verso do sis
tema e pensar que tal verso j corresponde ao sistema como um todo. De qual
quer forma, o fato de essa abordagem incentivar a participao do usurio no
processo de desenvolvimento de longe compensa qualquer falsa expectativa
que este possa ter sobre o sistema.
Outra vantagem dessa abordagem que os riscos do projeto podem ser mais
bem gerenciados. Um risco de desenvolvimento a possibilidade de ocorrncia
de algum evento que cause prejuzo ao processo de desenvolvimento, junta
mente com as consequncias desse prejuzo. O prejuzo pode incorrer na altera
o de diversos parmetros do desenvolvimento, como custos do projeto, cro-
nograma, qualidade do produto, satisfao do cliente etc. Exemplos de riscos
inerentes ao desenvolvimento de software:

O projeto pode no satisfazer aos requisitos do usurio.


A verba do projeto pode acabar.
O produto de software pode no ser adaptvel, manutenvel ou extensvel.
O produto de software pode ser entregue ao usurio tarde demais.

Um consenso geral em relao ao desenvolvimento de software que os ris


cos de projeto no podem ser eliminados por completo. Portanto, todo processo
de desenvolvimento deve levar em conta a probabilidade de ocorrncia de ris
cos. Na abordagem incrementai, os requisitos mais arriscados so considerados
primeiramente. Visto que cada ciclo de desenvolvimento gera um incremento
do sistema que liberado para o usurio, inconsistncias entre os requisitos
considerados no ciclo e sua implementao se tornam evidentes mais cedo no
desenvolvimento. Se as inconsistncias identificadas no so to graves, tanto
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 3:

melhor: elas so removidas e uma nova verso do sistema entregue ao usurio.


Por outro lado, se as inconsistncias descobertas so graves e tm um impacto
grande no desenvolvimento do sistema, pelo menos a sua identificao torna
possvel reagir a elas mais cedo sem tantas conseqncias graves para o projeto.

Os requisitos a serem considerados primeiramente devem ser selecionados com


base nos riscos que eles fornecem. Os requisitos mais arriscados devem ser consi
derados to logo possvel.

Para entender o motivo de o conjunto de requisitos mais arriscados ser con


siderado o mais cedo possvel, vamos lembrar de uma frase do consultor Tom
Gilb: Se voc no atacar os riscos [do projeto] ativamente, ento estes iro ati
vamente atacar voc (Gilb, 1988). Ou seja, quanto mais cedo a equipe de desen
volvimento considerar os requisitos mais arriscados, menor a probabilidade
de ocorrerem prejuzos devido a esses requisitos.
Uma desvantagem do desenvolvimento incremental e iterativo que a tare
fa do gerente do projeto fica bem mais difcil. Gerenciar um processo de desen
volvimento em que as fases de anlise, projeto e implementao, testes e im
plantao ocorrem em paralelo de fato consideravelmente mais complicado
do que gerenciar o desenvolvimento de um sistema que utilize a abordagem
clssica.

2.3.2.1 Organizao geral de umprocesso incremental e iterativo


O ciclo de vida de processo incremental e iterativo pode ser estudado segundo
duas dimenses: dimenso temporal e dimenso de atividades (ou de fluxos de
trabalho). A Figura 2-3 ilustra essas duas dimenses.
Na dimenso temporal, o processo est estruturado em fases. Em cada uma
dessas fases, h uma ou mais iteraes. Cada iterao tem uma durao preesta
belecida (de duas a seis semanas). Ao final de cada iterao, produzido um in
cremento, ou seja, uma parte do sistema final. Um incremento pode ser liberado
para os usurios, ou pode ser somente um incremento interno.
A dimenso de atividades compreende as realizadas durante a iterao de
uma fase: levantamento de requisitos, anlise de requisitos, projeto, implemen
tao, testes e implantao (as mesmas atividades descritas na Seo 2.1). Essas
atividades so apresentadas verticalmente na Figura 2-3.
Em cada uma das fases, diferentes artefatos de software so produzidos, ou
artefatos comeados em uma fase anterior so estendidos com novos detalhes.
Cada fase concluda com um marco (mostrado na parte superior da Figura
2-3). Um marco um ponto do desenvolvimento no qual decises sobre o pro-
40 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Marcos Incios de iteraes Marcos

Figura 2-3: Estrutura geral de um processo de desenvolvimento incrementai e iterativo.

jeto so tomadas e importantes objetivos so alcanados. Os marcos so teis


para o gerente de projeto estimar os gastos e o andamento do cronograma de
desenvolvimento.
As fases do processo unificado delimitadas pelos marcos so as seguintes: con
cepo, elaborao, construo e transio. Essas fases so descritas a seguir.

Na concepo, a idia geral e o escopo do desenvolvimento so desenvol


vidos. Um planejamento de alto nvel do desenvolvimento realizado.
So determinados os marcos que separam as fases.
Na fase de elaborao, alcanado um entendimento inicial sobre como o
sistema ser construdo. O planejamento do projeto de desenvolvimento
completado. Nessa fase, o domnio do negcio analisado. Os requisi
tos do sistema so ordenados considerando-se prioridade e risco. Nessa
fase, tambm so planejadas as iteraes da prxima fase, a de constru
o. Isso envolve definir a durao de cada iterao e o que ser desenvol
vido em cada iterao.
Na construo, as atividades de anlise e projeto aumentam em compara
o com as demais. Esta a fase na qual ocorrem mais iteraes incremen
tais. No final dessa fase, decide-se se o produto de software pode ser en
tregue aos usurios sem que o projeto seja exposto a altos riscos. Se este
for o caso, tem incio a construo do manual do usurio e a descrio dos
incrementos realizados no sistema.
Na transio, os usurios so treinados para utilizar o sistema. Questes
de instalao e configurao do sistema tambm so tratadas. Ao final
desta fase, a aceitao do usurio e os gastos so avaliados. Uma vez que
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 41

O sistema entregue aos usurios, provavelmente surgem novas ques


tes que demandam a construo de novas verses do mesmo. Se este
for o caso, um novo ciclo de desenvolvimento pode ser iniciado.

Em cada iterao, uma proporo maior ou menor de cada uma dessas ativi
dades realizada, dependendo da fase em que se encontra o desenvolvimento.
Por exemplo, a Figura 2-3 permite perceber que, na fase de transio, a atividade
de implantao a predominante. Por outro lado, na fase de construo, as ativi
dades de anlise, projeto e implementao so as predominantes. Normalmente,
a fase de construo a que possui mais iteraes. No entanto, as demais fases
tambm podem conter iteraes, dependendo da complexidade do sistema.
O principal representante da abordagem de desenvolvimento incremental e
iterativa o denominado Processo Unificado Racional (Rational Unified Process,
RUP). Esse processo de desenvolvimento patenteado pela empresa Rational,
na qual trabalham os trs amigos, Jacobson, Booch e Rumbaugh (em 2002, a
IBM comprou a Rational). A descrio feita nesta seo uma verso simplifica
da do Processo Unificado. Maiores detalhes sobre o Processo Unificado podem
ser obtidos em (RUP, 2002).

2.4 Utilizao da UML no processo iterativo e incrementai


Na Seo 1.4, a UML descrita como uma linguagem de modelagem que inde
pendente do processo de desenvolvimento. Ou seja, vrios processos de desen
volvimento podem utilizar a UML como ferramenta para construo dos mode
los de um sistema de software orientado a objetos.
Em um modelo de ciclo de vida iterativo e incremental, os artefatos de softwa
re construdos atravs da UML evoluem medida que as iteraes do processo
so realizadas. A cada iterao, novos detalhes so adicionados a esses artefatos.
Alm disso, a construo de cada artefato no isolada. Em vez disso, a constru
o de um artefato fornece informaes para adicionar detalhes a outros.
Os prximos captulos deste livro descrevem os diagramas da UML e a cons
truo de modelos, considerando-se a utilizao de um processo iterativo e in
cremental. Para cada modelo descrito, apresentada a sua insero no contexto
do processo de desenvolvimento como um todo.

2.5 Prototipagem
Uma tcnica que serve de complemento anlise de requisitos a construo de
prottipos. No contexto do desenvolvimento de software, um prottipo um
esboo de alguma parte do sistema. A construo de prottipos comumente
chamada de prototipagem.
42 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Prottipos podem ser construdos para telas de entrada, telas de sada,


subsistemas, ou mesmo para o sistema como um todo. A construo de pro
ttipos utiliza as denominadas linguagens de programao visual. Exemplos
so o Delphi, o PowerBuilder, o Visual Basic e o Front Page (para construo
de interface WEB), que, na verdade, so ambientes com facilidades para a
construo da interface grfica (telas, formulrios etc.). Alm disso, muitos
sistemas de gerncia de bancos de dados tambm fornecem ferramentas para
a construo de telas de entrada e sada de dados. Note, entretanto, que pro
ttipos no necessariamente precisam ser construdos para aspectos da in
terface grfica com o usurio. Em vez disso, qualquer aspecto que precise ser
mais bem entendido alvo potencial de prototipagem pela equipe de desen
volvimento.
Na prototipagem, aps o levantamento de requisitos, um prottipo do siste
ma construdo para ser usado na validao, quando o prottipo revisto por
um ou mais usurios, que fazem crticas acerca de uma ou outra caracterstica.
O prottipo ento corrigido ou refinado de acordo com tais crticas. Esse pro
cesso de reviso e refinamento continua at o prottipo ser aceito pelos usu
rios. Portanto, a tcnica de prototipagem tem o objetivo de assegurar que os re
quisitos do sistema foram realmente bem entendidos. O resultado da validao
atravs do prottipo pode ser usado para refinar os modelos do sistema. Aps a
aceitao, o prottipo (ou parte dele) pode ser descartado ou utilizado como
uma verso inicial do sistema.
Embora a tcnica de prototipagem seja opcional, ela costuma ser aplicada
em projetos de desenvolvimento de softTvare, especialmente quando h dificul
dades no entendimento dos requisitos do sistema, ou h requisitos arriscados
que precisam ser mais bem entendidos. A idia que um prottipo mais con
creto para fins de validao do que modelos representados por diagramas bidi
mensionais. Isso incentiva a participao ativa do usurio na validao. Conse-
qentemente, a tarefa de validao se torna menos suscetvel a erros. No entan
to, alguns desenvolvedores usam essa tcnica como um substituto construo
de modelos do sistema. Tenha em mente que a prototipagem uma tcnica com
plementar construo dos modelos do sistema. Os modelos do sistema devem
ser construdos, pois so eles que guiam as demais fases do projeto de desenvol
vimento de software. O ideal os erros detectados na validao do prottipo se
rem utilizados para modificar e refinar os modelos do sistema.

2.6 Ferramentas CASE


Um processo de desenvolvimento de software muito complexo. Vrias pessoas,
com diferentes especialidades, esto envolvidas nesse processo altamente coopera
tivo. Tal atividade cooperativa pode ser facilitada pelo uso de ferramentas que auxi-
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 43

liam na construo de modelos do sistema, na integrao do trabalho de cada mem


bro da equipe, no gerenciamento do andamento do desenvolvimento etc.
Existem sistemas de software que so utilizados para dar suporte ao ciclo de
vida de desenvolvimento de um sistema. Dois tipos de software que tm esse objeti
vo so as ferramentas CASE e os ambientes de desenvobimento. Uma discusso de
talhada sobre esses sistemas de apoio ao desenvohimento est fora do escopo deste
livro. Descrevemos sucintamente cada um desses dois tipos de software a seguir.
O termo CASE uma sigla em ingls para Engenharia de Software Auxiliada
por Computador (Computer Aided Software Engineering). A utilizao dessa sigla j
se consolidou no Brasil. Existem diversas ferramentas CASE disponveis no mer
cado. No est no escopo deste livro detalhar as funcionalidades dessas ferramen
tas. No entanto, a seguir, algumas caractersticas so sucintamente descritas.

Criao de diagramas e manuteno da consistncia entre os mesmos.


comum a quase todas as ferramentas CASE a possibilidade de produzir a
perspectiva grfica dos modelos de software. Com relao manuteno
desses diagramas, um padro que vem ganhando importncia nos lti
mos anos o XMI (XML Metadaia Interchange). O XMI um padro ba
seado em XML para exportar modelos definidos em UML. Esse padro
importante, pois permite a interoperabilidade entre diversas ferramentas
CASE; um diagrama produzido em um ferramenta A pode ser importado
para uma ferramenta B de outro fabncanie. considerando que os fabri
cantes das ferramentas A e B do supene ao padro XML
Manuteno da consistncia entre os modelos gerados: outra funcionali
dade freqentemente encontrada em ferramentas CASE a que permite
verificar a validade de um conjunto de modelos e a consistncia entre os
mesmos.
Engenharia Round-Trip (Round-Tnp Engineering): denomina-se enge
nharia round-trip capacidade de uma ferramenta CASE interagir com o
cdigo-fonte do sistema em desenvolvimento. H dois tipos de engenha
ria round-trip: engenhana direta e engenharia reversa. A engenharia direta
corresponde possibilidade de gerao de cdigo-fonte a partir de diagra
mas produzidos com a ferramenta CASE em questo. A engenharia rever
sa corresponde ao processo inverso, ou seja, gerao de diagramas a partir
de cdigo-fonte preexistente.
Rastreamento de requisitos: uma facilidade importante em um processo
de desenvolvimento a possibilidade de rastreamento de um requisito.
Rastrear um requisito significa poder localizar os artefatos de software ge
rados como conseqncia da existncia daquele requisito. Essa funciona
lidade importante quando um requisito alterado; nesse caso, todos os
artefatos correspondentes devem ser revisados.
44 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Alm das ferramentas CASE, um segundo tipo de software de suporte ao de


senvolvimento so os ambientes de desenvolvimento integrado (Integrated De-
velopment Environment, IDE). Esses ambientes possibilitam a codificao (im
plementao) do sistema, alm de fornecerem diversas facilidades, algumas de
las listadas a seguir;

Depurao de cdigo-fonte: capacidade dos ambientes de desenvolvi


mento que permite ao programador encontrar erros de lgica em partes
de um programa.
Verificao de erros em tempo de execuo: comum nos ambientes de
desenvolvimento modernos a facilidade de compilao do programa em
paralelo escrita do mesmo. Com este recurso, o programador notifica
do de um erro em alguma linha de cdigo logo aps ter passado para a
construo da prxima instruo.
Refatorao; corresponde a alguma tcnica de alterao do cdi
go-fonte de uma aplicao de tal forma que no altere o comportamen
to da mesma, mas, sim, melhore a qualidade de sua implementao e
consequentemente torne mais fcil a manuteno. comum em am
bientes de desenvolvimento integrado modernos a existncia de facili
dades para que o programador realize refatoraes no cdigo-fonte de
sua aplicao.

Alm das ferramentas CASE e dos ambientes de desenvolvimento integra


do, outras ferramentas so importantes em um processo de desenvolvimento. A
seguir, listamos alguns exemplos de facilidades encontradas em ferramentas de
suporte ao desenvolvimento atuais:

Relatrios de cobertura de testes: ferramentas que geram relatrios infor


mando sobre partes de um programa que no foram testadas.
Gerenciamento de verses: ferramentas que permitem gerenciar as diver
sas verses dos artefatos de software gerados durante o ciclo de vida de
um sistema.
Suporte definio de testes automatizados: ferramentas que realizam
testes automticos no sistema.
Monitorao e averiguao do desempenho: averiguar o tempo de execu
o de mdulos de um sistema, assim como o trfego de dados em siste
mas em rede..
Tarefas de gerenciamento: ferramentas que fornecem ao gerente de projetos
(ver Seo 2.2.1) funcionalidades para suporte a algumas de suas atribui
es: desenvolvimento de cronogramas de tarefas, alocaes de recursos de
mo-de-obra, monitorao do progresso das atividades e dos gastos etc.
0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 45
ELSEVIER

EXERCCIOS

2-1: O que os seguintes termos significam. Como eles se relacionam uns com os outros?

Anlise e Projeto
Anlise e Projeto Orientados a Objetos
UML

2-2: Em 1957, um matemtico chamado George Polya descreveu um conjunto de passos gen
ricos para a resoluo de um problema (Polya, 1957). Estes passos so descritos sucintamente
a seguir:
a. Compreenso do problema
b. Construo de uma estratgia para resolver o problema
c. Execuo da estratgia
d. Reviso da soluo encontrada

Reflita sobre a seguinte afirmao: o processo de desenvolvimento de um sistema de software


pode ser visto como um processo de resoluo de um problema.

2-3: Uma teoria da Fsica relativamente nova a chamada Teoria do Caos. Entre outras afirma
es surpreendentes, essa teoria afirma que uma borboleta voando sobre o Oceano Pacfico
pode causar uma tempestade no Oceano Atlntico. Ou seja, eventos aparentemente irrelevan
tes podem levar a conseqncias realmente significativas. Discuta com um analista de siste
mas as conseqncias de pequenas falhas na fase de levantamento em relao a fases poste
riores do desenvolvimento de um sistema de software.

2-4: Baseado em sua experincia, tente escrever um documento de requisitos para um sistema
de controle acadmico. Esse sistema deve controlar as inscries de alunos em disciplinas, a
distribuio das turmas, salas, professores etc. Deve permitir tambm o controle de notas atri
budas aos alunos em diversas disciplinas. Voc pode se basear na forma de funcionamento da
sua prpria faculdade.

2-5: Com base em sua experincia, tente escrever um documento de requisitos para um siste
ma de software do seu cotidiano (por exemplo, um sistema para automatizar algum processo na
empresa em que trabalha, aproveitando o conhecimento do domnio do negcio que voc tiver).
Durante a elaborao desse documento, resista o mximo possvel tentao de considerar de
talhes tcnicos e de implementao.
3
Mecanismos gerais
Podemos apenas ver uma curta distncia frente,
mas podemos ver que h muito l a ser feito.
-ALAN TURING

UML consiste em trs grandes componentes: blocos de construo

A bsicos, regras que restringem como os blocos de construo podem


ser associados e mecanismos de uso geral. Este captulo descreve os
mecanismos de uso geral, pelo fato de eles poderem ser utilizados na maioria
dos diagramas da UML que so apresentados nos captulos seguintes. A descri
o aqui apresentada apenas introdutria. Detalhes e exemplos sobre os meca
nismos de uso geral esto nos demais captulos do livro, quando for necessrio
usar esses mecanismos.

3.1 Esteretipos
Um esteretipo um dos mecanismos de uso geral da UML, que utilizado para
estender o significado de determinado elemento em um diagrama. A UML pre
define diversos esteretipos. Alguns deles aparecem nos captulos seguintes
deste livro. A UML tambm permite que o usurio defina os esteretipos a se
rem utilizados em determinada situao de modelagem. Ou seja, a prpria equi
pe de desenvolvimento pode definir os esteretipos que sero utilizados em si
tuaes especficas. Dessa forma, podemos ter esteretipos de dois tipos: prede-
finidos ou definidos pela equipe de desenvolvimento.
48 p rin c p io s de a n a l i s e e p r o je t o de s i s t e m a s com UML, 2/E ELS E.V 1 E.R

Os esteretipos definidos pela prpria equipe de desenvolvimento devem


ser documentados de tal forma que a sua semntica se^a entendida sem ambi-
gidades por toda a equipe. Alm disso, um esteretipo definido pelo usurio
deve ser utilizado de forma consistente na modelagem de todo o sistema. Ou
seja, no correto utilizar um mesmo esteretipo para denotar diferentes signi
ficados.
Outra classificao que pode ser aplicada aos esteretipos (tanto os predet-
nidos quanto os definidos pela equipe de desenvolvimento) quanto a sua for
ma; esteretipos grficos (ou cones) e esteretipos textuais.
Um esteretipo grfico representado por um cone que lem bre o stgnttea-
do do conceito ao qual ele est associado. Por exemplo; a P tg u ra 3 -l ilustra qua
tro esteretipos grficos. Os dois mais esquerda (Mor e Componente) so prede-
finidos na UML. J os dois elementos grficos mais direita (Servidor HTTP e
Portal de Segurana) so exem plos de esteretipos definidos pela equipe de
desenvolvimento. Note que o cone escolhido para esses esteretipos coerente
com o significado do conceito que eles representam .

Ator
A |~T~^^Componente

Servidor Portal de
HTTP segurana
(firev/a\\)
Figura 3-1; Exemplos de esteretipos grficos.

Um esteretipo de rtulo representado por um nome delimitado pelos


smbolos e (esses smbolos so chamados de aspas jrancesas"), e posiciona
do prximo ao smbolo. Os esteretipos document, i n t e r f a c e , c o n
trol , e n ti t y so exemplos de esteretipos textuais predelinidos dallM L.
Nesse sentido, os esteretipos permitem estender aUMU e adaptar o seu uso em
diversos casos.

3.2 Notas explicativas


Notas explicativas so utilizadas para definir inlormao que comenta ou escla
rece alguma parte de um diagrama. Podem ser descritas em texto livre; tambm
podem corresponder a uma expresso formal utilizando a linguagem de restri
o de objetos da UML, a OCL (ver Seo 3.4).
MECANISMOS GERA.E 49

Graficamente, as notas so representadas por um retngulo com uma ore


lha. O contedo da nota inserido no interior do retngulo e este ligado ao
elemento que se quer esclarecer ou comentar atravs de uma linha tracejada. A
Figura 3-2 ilustra a utilizao de notas explicativas. Como a figura sugere, as
notas devem ser posicionadas prximo aos elementos que elas descrevem.
importante notar que, ao contrrio dos esteretipos, as notas textuais no
modificam nem estendem o significado do elemento ao qual esto associadas.
Elas servem somente para explicar algum elemento do modelo sem modificar
sua estrutura ou semntica.
Notas explicativas devem ser utilizadas com cuidado. Embora elas ajudem a
explicar certos elementos de um diagrama, sua utilizao em excesso torna os
modelos grficos carregados visualmente. Alm disso, com a evoluo dos
modelos durante o desenvolvimento do sistema, algumas notas podem deixar
de fazer sentido, gerando, assim, a sobrecarga de atualizao das mesmas. A
idia utilizar notas explicativas quando for realmente necessrio.

O
Este um exemplo ^
de nota explicativa.

Ator
Figura 3-2: Exemplo de nota explicativa.

3.3 Etiquetas valoradas {tagged values)


Os elementos grficos de um diagrama da UME possuem propriedades predefini-
das. Por exemplo, uma classe tem trs propriedades predefinidas: um nome, uma
lista de atributos e uma lista de operaes. Alm das propriedades predefinidas,
podem-se tambm definir outras propriedades para determinados elementos de
um diagrama atravs do mecanismo de etiquetas valoradas. Na UME 2.0, uma eti
queta valorada somente pode ser utilizada como um atributo definido sobre um
esteretipo. (Este ltimo pode ser predefinido ou definido pelo usurio). Dessa
forma, um determinado elemento de um modelo deve primeiramente ser estendi
do por um esteretipo antes de ser estendido por uma etiqueta valorada.

Tabela 3-1: Alternativas para definio de etiquetas (tags) na UML

{ tag = valor )
{ tagl = valor 1, tag2 = valor2 ... }
{ tag }
50 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Figura 3-3: Utilizao de etiquetas.

Uma etiqueta pode ser definida utilizando-se uma das trs forma alternati
vas apresentadas na Tabela 3-f. As chaves fazem parte da sintaxe. Por exemplo,
uma etiqueta pode ser utilizada para informar o autor e a data de criao de um
determinado diagrama ou elemento de um diagrama. A Figura 3-3 ilustra essa
utilizao.

3.4 Restries
A todo elemento da UML est associada alguma semntica. Isso quer dizer que
cada elemento grfico dessa linguagem possui um significado bem definido
que, uma vez entendido, fica implcito na utilizao do elemento em algum dia
grama. As restries permitem estender ou alterar a semntica natural de um
elemento grfico. Esse mecanismo geral especifica restries sobre um ou mais
valores de um ou mais elementos de um modelo. Restries podem ser especifi
cadas tanto formal quanto informalmente. A especificao formal de restries
se d pela OCL (ver Seo 3.6). Alm de poderem ser especificadas atravs da
OCL, restries tambm podem ser definidas informalmente pelo texto livre
(linguagem natural). Assim como para as etiquetas, uma restrio, seja ela for
mal ou informal, tambm deve ser delimitada por chaves. Essas restries de
vem aparecer dentro de notas explicativas (ver Seo 3.2).

3.5 Pacotes
Um pacote um mecanismo de agrupamento definido pela UML. Esse mecanis
mo pode ser utilizado para agrupar elementos semanticamente relacionados. A
notao para um pacote a de uma pasta com uma aba, conforme mostra a Figu
ra 3-3, um pacote tem um nome.
As ligaes entre pacotes na Figura 3-3 so relacionamentos de dependn
cia entre os pacotes. Um pacote depende de outro P2 se algum elemento con
tido em P^ depende de algum elemento contido em P2. O significado especfico
MECAt.iSyas : s*

dessa dependncia pode ser definido pela prpria equipe de desenvohimemc


com o uso de esteretipos.
Um pacote constitui um mecanismo de agrupamento genrico. Sendo as
sim, ele pode ser utilizado para agrupar quaisquer outros elementos, inclusive
outros pacotes. Na Seo 4.4.1 e na Seo 11.1, apresentamos mais detalhes so
bre pacotes, nos contextos do modelo de casos de uso e da arquitetura lgica do
sistema, respectivamente.
Em relao ao contedo de um pacote, h duas maneiras de represent-lo
graficamente. A primeira exibir o contedo dentro do pacote. A segunda for
ma pendurar os elementos agrupados no cone do pacote. A Figura 3-4 ilus
tra essas duas formas de representao.

Figura 3-4: Formas de representar o contedo de um pacote.

Conforme mostra a Figura 3-5, os pacotes podem ser agrupados dentro de


outros pacotes, formando uma hierarquia de conteno.

----- H

Figura 3-5: Pacotes podem conter outros pacotes.


52 prin cp io s de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

3.6 OCL
A UML define uma linguagem formal que pode ser utilizada para especificar
restries sobre diversos elementos de um modelo. Essa linguagem se chama
OCL, a Linguagem de Restrio de Objetos. A OCL pode ser utilizada para definir
expresses de navegao entre objetos, expresses lgicas, precondies, ps-
condies etc.
A maioria das declaraes em OCL consiste nos seguintes elementos estrutu
rais: contexto, propriedade e operao. Um contexto define o domnio no qual a de
clarao em OCL se aplica. Por exemplo, uma classe ou uma instncia de uma
classe. Em uma expresso OCL, a propriedade corresponde a algum componente
do contexto. Por exemplo, o nome de um atributo em uma classe, ou uma asso
ciao entre dois objetos. Finalmente a operao define o que deve ser aplicado
sobre a propriedade. Uma operao pode envolver operadores aritmticos, ope
radores de conjunto e operadores de tipo. Outros operadores que podem ser utili
zados em uma expresso OCL so: and, or, implies, if, then, else, not, in.
A OCL pode ser utilizada em qualquer diagrama da UML. Para uma descri
o detalhada dessa linguagem recomendamos o livro UML - Guia do Usurio
(Booch et a i , 2006). No entanto, durante as descries dos diagramas da UML
em outros captulos deste livro, fornecemos alguns exemplos de expresses
em OCL.
4
Modelagemdecasos deuso
No diga pouco em muitas palavras,
mas sim muito em poucas.
- PITGORAS

modelo de casos de uso (MCU) uma representao das funcionali

O dades externamente observveis do sistema e dos elementos externos


ao sistema que interagem com ele. O MCU um modelo de anlise
(ver Seo 2.1.2) que representa um refinamento dos requisitos funcionais (ver
Seo 2.1.1) do sistema em desenvolvimento. A ferramenta da UML utilizada na
modelagem de casos de uso o diagrama de casos de uso.
A tcnica de modelagem de casos de uso foi idealizada por um conceituado
engenheiro de software sueco, Ivar Jacobson, na dcada de 1970, enquanto tra
balhava no desenvolvimento de um sistema na empresa de telefonia Ericsson.
Mais tarde, Jacobson incorporou essa tcnica a um processo de desenvolvimen
to de software denominado Objectory (Jacobson et a l , 1992). Posteriormente,
Jacobson se uniu a Grady Booch e a James Rumbaugh, e a notao de casos de
uso foi incorporada Linguagem de Modelagem Unificada (UML). Desde en
to, esse modelo vem se tornando cada vez mais popular para realizar a docu
mentao de requisitos funcionais de uma aplicao, devido sua notao grfi
ca simples e descrio em linguagem natural, o que facilita a comunicao entre
a equipe tcnica e os especialistas do domnio.
O modelo de casos de uso importante, pois direciona diversas tarefas pos
teriores do processo de desenvolvimento de um sistema de software, .\irin dis
54 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

so, esse modelo fora os desenvolvedores a moldarem o sistema de acordo com


as necessidades do usurio.
Neste captulo, estudamos o modelo de casos de uso. Nosso objetivo aqui
apresentar os principais componentes desse modelo, assim como descrever di
cas de modelagem teis na criao e documentao do mesmo. Alm disso,
tambm descrevemos documentao suplementar que normalmente deve ser
criada e associada ao modelo de casos de uso.

4.1 Modeio de casos de uso


o MCU representa os possveis usos de um sistema, conforme percebidos por
um observador externo a este sistema. Cada um desses usos est associado a um
ou mais requisitos funcionais identificados para o sistema. A construo desse
modelo envolve a definio de diversos componentes: casos de uso, atores e rela
cionamentos entre eles. Vamos descrever esses componentes separadamente nas
prximas sees.

4.1.1 Casos de uso


Por definio, um caso de uso (do ingls use case) a especificao de uma se
quncia completa de interaes entre um sistema e um ou mais agentes externos a
esse sistema. Um caso de uso representa um relato de uso de certa funcionalidade
do sistema em questo, sem revelar a estmtura e o comportamento internos desse
sistema. Essa ltima caracterstica de um caso de uso importante, porque sua
existncia implica que o MCU um modelo com uma perspectiva externa do sis
tema. Graas ao estudo do modelo de casos de uso de um sistema, um observador
sabe quais so as funcionalidades fornecidas pelo sistema em questo, e quais so
os resultados externos produzidos pelas mesmas. No entanto, esse observador
no sabe, simplesmente pelo modelo de casos de uso, como esse sistema age in
ternamente para produzir os resultados externamente visveis.
importante enfatizar o uso da palavra completa na definio de caso de
uso que demos no pargrafo anterior. O uso dessa palavra para enfatizar que
um caso de uso no um passo em uma funcionalidade do sistema. Ao contr
rio, um caso de uso um relato fim a fim de um dos usos do sistema por um
agente externo. Outro exemplo para esclarecer esse ponto: entrar no sistem ano
um caso de uso em si, visto que de esperar que o usurio entre no sistema
para alcanar outro objetivo mais til do que s olhar a sua tela inicial. Nessa si
tuao, este outro objetivo que o verdadeiro caso de uso.
Um modelo de casos de uso tpico contm vrios casos de uso. A quantidade
exata de casos de uso obviamente depende da complexidade do sistema em desen
volvimento: quanto mais complexo o sistema, maior a quantidade de casos de uso.
MODELAGEM DE CASOS DE USO 55

Um caso de uso representa uma determinada funcionalidade de um sistema con


forme percebida externamente. Representa tambm os agentes externos que inte
ragem com 0 sistema. Um caso de uso, entretanto no revela a estrutura e o com
portamento internos do sistema.

Cada caso de uso de um sistema se define pela descrio narrativa (textual)


das interaes que ocorrem entre o(s) elemento(s) externo(s) e o sistema. A
UML no define uma estrutura textual a ser utilizada na descrio de um caso de
uso. Conseqentemente, h vrios estilos de descrio propostos para definir
casos de uso. A escolha de um ou de outro estilo fica a cargo da equipe de desen
volvimento, ou, ento, pode ser uma restrio definida pelos clientes que enco
mendaram 0 sistema.
Podemos dizer que h trs dimenses em que o estilo de descrio de um
caso de uso pode variar. Essas dimenses so o formato, o grau de detalhamento
e o grau de abstrao. Como mostra a Figura 4-1, o formato, o grau de detalha
mento e o grau de abstrao so dimenses (escolhas) de descrio indepen
dentes entre si e, por conta disso, podem ser escolhidas de forma independente.
Passamos agora a descrever mais detalhadamente cada uma dessas dimenses.

Figura 4-1: Independncia entre formato, grau de abstrao e detalhamento de um caso de uso.

4.1.1.1 Formato
O formato de uma descrio de caso de uso diz respeito estrutura utilizada
para organizar a sua narrativa textual. Os formatos comumente utilizados so o
contnuo, o numerado e o tabular. Esses trs formatos so apresentados a seguir.
Nesta explicao, utilizado um exemplo correspondente ao caso de uso de sa
que de determinada quantia em um caixa eletrnico de um sistema bancrio.
56 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

O formato contnuo foi introduzido por Ivar Jacobson e seus colaboradores.


Nesse formato, a narrativa se d atravs de texto livre. Como um exemplo desse
tipo de formato, considere o caso de uso Real i zar Saque em um caixa eletrnico.
A descrio contnua deste caso de uso fornecida no Quadro 4-1.

Quadro 4.1: Exemplo de descrio contnua

Este caso de uso inicia quando o Cliente chega ao caixa eletrnico e insere seu carto.
O Sistema requisita a senha do Cliente. Aps o Cliente fornecer sua senha e esta ser
I validada, o Sistema exibe as opes de operaes possiveis. O Cliente opta por realizar
um saque. Ento o Sistema requisita o total a ser sacado. O Cliente fornece o valor da
quantidade que deseja sacar. O Sistema fornece a quantia desejada e imprime o recibo
para o Cliente. O Cliente retira a quantia e o recibo, e o caso de uso termina.

No formato numerado, a narrativa descrita por uma srie de passos nume


rados. Considere como exemplo o mesmo caso de uso Real i zar Saque. Sua des
crio no formato numerado fornecida no Quadro 4-2.

Quadro 4.2: Exemplo de descrio numerada

1) Cliente insere seu carto no caixa eletrnico,


2) Sistema apresenta solicitao de senha.
3) Cliente digita senha.
4) Sistema valida a senha e exibe menu de operaes disponveis.
5) Cliente indica que deseja realizar um saque.
6) Sistema requisita o valor da quantia a ser sacada.
7) Cliente fornece o valor da quantia que deseja sacar.
8) Sistema fornece a quantia desejada e imprime o recibo para o Cliente.
8) Cliente retira a quantia e o recibo, e o caso de uso termina.

O formato tabular tenta prover alguma estrutura descrio de casos de


uso. Esse estilo foi proposto por Rebecca Wirfs-Brock e outros (Wirfs-Brock et
uL, 1991). Nesse estilo, a seqncia de interaes entre o ator e o sistema parti
cionada em duas colunas de uma tabela. Uma das colunas apresenta as aes do
ator e a outra apresenta as reaes do sistema. Essa forma de estruturao da
narrativa tem o objetivo de separar as aes do ator e as reaes do sistema. A
leitura de um caso de uso estruturado segundo esse formato pode ser feita em zi-
guezague. O caso de uso para saque utilizando o formato tabular exibido no
Quadro 4-3. Note que as aes ou reaes podem ser numeradas.
MODELAGEM DE CASOS DE USO 57
ELSEVIER

Quadro 4-3: Exemplo de narrativa particionada

Cliente Sistema
Insere seu carto no caixa eletrnico. Apresenta solicitao de senha.

Digita senha. \"alida senha e exibe menu de operaes


disponveis.
Solicita realizao de saque.
Requisita quantia a ser sacada.
Fornece o valor da quantia que deseja
sacar. Fornece a quantia desejada e imprime o
recibo para o Cliente
Retira a quantia e o recibo.

Alguns autores tambm preconizam a utilizao de uma narrativa seme


lhante ao portugus estruturado, na qual se utilizam construes parecidas com
as das linguagens de programao estruturada. A esse respeito, importante no
tar que a descrio de um caso de uso deve ser legvel para o usurio final. Isso
porque o MCU um dos modelos utilizados na fase de validao do sistema (ver
Seo 2.1.2). Por conta disso, a descrio de um caso de uso deve ser a mais clara
possvel, o que se contrape diretamente idia de descries de casos de uso
semelhantes a cdigos-fonte em linguagens de programao.

4.1.1.2 Grau de detalhamento


O grau de detalhamento a ser utilizado na descrio de um caso de uso pode va
riar desde o mais sucinto at a descrio com vrios detalhes (expandido). Um
caso de uso sucinto descreve as interaes entre ator e sistema sem muitos deta
lhes. Um caso de uso expandido descreve as interaes em detalhes. (Mais in
formaes sobre o detalhamento e.xpandido esto na Seo 4.4.)

4.1.1.3 Grau de abstrao


O grau de abstrao de um caso de uso diz respeito existncia ou no de men
o a aspectos relativos tecnologia durante a descrio desse caso de uso. Em
relao ao grau de abstrao, um caso de uso pode ser real ou essencial. Um caso
de uso essencial abstrato no sentido de no fazer meno a aspectos relativos
tecnologia utilizada nas interaes entre ator e casos de uso. Esse estilo de des
crio de casos de uso foi introduzido por Larry Constantine e Lucy Lockwood
(Constantine e Lockwood. 1999L
Um exemplo de caso de uso essencial apresentado no Quadro 4-4. (Embo
ra esse exemplo utilize o formato numerado, um caso de uso essencial pode ser
descrito em qualquer um dos formatos apresentados na Seo 4.1.1.1.) Note
que o exemplo de caso de uso essencial completamente desprovido de caracte
rsticas tecnolgicas.
58 princpios de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Quadro 4-4: Exemplo de descrio essencial (e numerada)

1) Cliente fornece sua identificao.


2) Sistema identifica o usurio.
3) Sistema fornece opes disponveis para movimentao da conta.
4) Cliente solicita o saque de determinada quantia.
5) Sistema requisita o valor da quantia a ser sacada.
6) Cliente fornece o valor da quantia que deseja sacar.
5) Sistema fornece a quantia desejada.
6) Cliente retira dinheiro e recibo e o caso de uso termina.

Em um caso de uso cujo grau de abstrao real, a descrio das interaes


cita detalhes da tecnologia a ser utilizada na interao entre o ator e o sistema.
Com efeito, a descrio em um grau de abstrao real se compromete com a so
luo de projeto (tecnologia) a ser utilizada para implementar o caso de uso. Os
casos de uso apresentados como exemplos na Seo 4.1.1.1 so todos reais.
uma boa idia utilizar a regra prtica dos 100 anos para identificar se um
caso de uso contm algum detalhe de tecnologia: pergunte-se, ao ler a narrativa
do caso de uso, se a mesma seria vlida tanto h 100 anos, quanto daqui a 100
anos. Se a resposta para sua pergunta for um sim, ento isso um indcio de
que se trata de um caso de uso essencial.^ Caso contrrio, trata-se de um caso
de uso real. Por exemplo, no passo 1 do caso de uso apresentado no Quadro 4.4,
h meno a uma tecnologia de interao especfica, o carto magntico, to co
mum nos dias de hoje, o que caracteriza tal caso de uso como real. (Certamente,
a tecnologia de cartes magnticos no existia h 100 anos, e provavelmente
no mais existir daqui a 100 anos.)

4.1.1.4 Cenrios
Geralmente a funcionalidade de um sistema descrita por um caso de uso tem di
versas maneiras de ser utilizada. Um cenrio a descrio de uma das maneiras
pelas quais um caso de uso pode ser utilizado. Outra maneira de ver um cenrio
como a descrio de um episdio de utilizao de alguma funcionalidade do
sistema. Um cenrio tambm chamado de instncia de um caso de uso. Nor
malmente h diversos cenrios para um mesmo caso de uso. Como exemplo,
considere um caso de uso que representa a funcionalidade para realizar um pe
dido de compra pela Internet. A descrio de um cenrio para esse caso de uso
apresentada no Quadro 4-5.

^Esta dica se justifica pela grande rapidez com a qual uma tecnologia substituda por outra: poucas tec
nologias de 100 anos atrs so usadas hoje, assim como poucas tecnologias atuais sero utilizadas daqui
a 100 anos.
MODELAGE.' DE E-
ELSEVIER

Quadro: 4-5: Exemplo de cenrio para um caso de pedido de compra pela Internet

O cliente seleciona um conjunto de produtos do catlogo da loja.


Aps selecionar os produtos que deseja comprar, o cliente indica o desejo de
realizar o pagamento por carto de crdito.
O sistema informa que o ltimo produto escolhido est fora de estoque.
O cliente pede para que o sistema feche o pedido sem o item que est fora de
estoque.
O sistema solicita os dados do cliente para realizao do pagamento.
O cliente fornece o nmero do carto, a data de expirao, alm de informar o
endereo de entrega do pedido.
O sistema apresenta o valor total, a data de entrega e uma identificao do pedido
para futuro rastreamento.
O sistema tambm envia um correio eletrnico para o cliente como confirmao
do pedido de compra.
O sistema envia os dados do pedido para o sistema de logstica da empresa.

Uma analogia vlida para entender a relao entre caso de uso e cenrio a
de um labirinto. Em um labirinto, temos geralmente diversas maneiras para
chegar a uma determinada sada a partir de uma determinada entrada. De forma
anloga, podemos comparar o labirinto ao caso de uso. Por outro lado, podemos
comparar um cenrio a cada uma das possveis maneiras de atravessar o caso
de uso.
Uma coleo de cenrios para um caso de uso pode ser utilizada posterior
mente na fase de testes (ver Seo 2.1.5) quando o caso de uso estiver sendo tes
tado para verificar a existncia de erros na implementao do sistema. Outro
uso importante dos cenrios est no esclarecimento e no entendimento dos ca
sos de uso dos quais eles so instanciados. Freqentemente durante a constru
o de um cenrio, novos detalhes do caso de uso so identificados, ou mesmo
novos casos de uso so identificados durante esse processo. Por exemplo, no ce
nrio apresentado no Quadro 4-5, o que acontece se o cliente sair do sistema an
tes de completar a realizao de seu pedido? E se o carto de crdito do cliente
no for aceito? O sistema de logstica um ator do sistema?
Um conceito associado ao de cenrio o de realizao de um caso de uso. De
nominamos realizao de um caso de uso ao conjunto de diagramas e artefatos
textuais que especificam como este caso de uso executado internamente ao
sistema em desenvolvimento. Em um sistema de software orientado a objetos, a
realizao de um caso de uso normalmente apresenta colaboraes entre obje
tos de determinadas classes. Essas colaboraes tm o objetivo de produzir o re
sultado externamente visvel do caso de uso. Normalmente, um modelador es
pecifica diversas colaboraes para um caso de uso, um para cada cenrio consi-
60 princpios de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

derado relevante. O detalhamento da realizao de cenrios de um caso de uso


no faz parte da modelagem de casos de uso. Deixamos o tratamento desse as
sunto para o Captulo 7, no qual se faz uma descrio da utilizao de cenrios
para modelar as colaboraes (interaes) entre objetos na realizao de um de
terminado caso de uso.

Um cenrio uma utilizao especfica de um caso de uso pelo ator envolvido;


pode ser visto como uma instncia de um caso de uso.

4.1.2 Atores
Na terminologia da UML, qualquer elemento externo ao sistema que interage
com 0 mesmo , por definio, denominado ator. O termo externo nessa defi
nio indica que atores no fazem parte do sistema. O termo interage significa
que um ator troca informaes com o sistema (envia informaes para o sistema
processar, ou recebe informaes processadas provenientes do sistema). Atores
representam a forma pela qual um sistema percebe o seu ambiente.
Atores de um sistema podem ser agrupados em diversas categorias As cate
gorias de atores, junto com exemplos de cada uma, so listadas a seguir:

1. Cargos (por exemplo. Empregado, Cliente, Gerente, Almoxarife, Vende


dor etc.).
2. Organizaes ou divises de uma organizao (por exemplo. Empresa
Eornecedora, Agncia de Impostos, Administradora de Cartes, Almo-
xarifado etc.).
3. Outros sistemas de software (por exemplo. Sistema de Cobrana, Sistema
de Estoque de Produtos etc.).
4. Equipamentos com os quais o sistema deve se comunicar (por exemplo.
Leitora de Cdigo de Barras, Sensor etc.).

Para todas as categorias de atores listadas anteriormente, os casos de uso re


presentam alguma forma de interao, no sentido de troca de informaes, en
tre o sistema e o ator. Normalmente o ator inicia a seqncia de interaes cor
respondente a um caso de uso. Uma situao menos freqente, mas tambm
possvel, um evento interno acontecer para que a seqncia de interaes do
caso de uso em questo seja acionada (ver Seo 4.3.2.1).
Um aspecto importante a notar que um ator corresponde a um papel re
presentado em relao ao sistema. Por exemplo, a mesma pessoa pode agir (de
sempenhar um papel) como um ator em um momento e como outro ator em ou
tro momento. Para ser mais especfico, em um sistema de vendas de livros via
MODELAGEM DE CASOS DE USO 61

Internet, um indivduo pode desempenhar o papel de Cl i ente que compra mer


cadorias. Esse mesmo indivduo pode tambm desempenhar o papel de Agenda-
dor, 0 funcionrio da loja que agenda a entrega de encomendas. Outro exemplo;
uma pessoa pode representar o papel de Funcionrio de uma instituio ban
cria que faz a manuteno de um caixa eletrnico (para reabastec-lo de nu
merrio, por exemplo). Em outra situao de uso, essa mesma pessoa pode ser o
Cl i ente do banco que realiza o saque de uma quantia no caixa eletrnico.
Levando em conta que um ator um papel representado por algo (ou al
gum) em relao ao sistema, uma boa prtica de modelagem fazer com que o
nome dado a esse ator lembre o seu papel, em vez de lembrar quem o representa.
Exemplos de bons nomes para atores: Cl i ente. Estudante, Fornecedor etc. Exem
plos de maus nomes para atores: Joo, Fornecedora, ACME etc.
Um ator pode participar de muitos casos de uso (de fato, essa situao co
mum na prtica). Do mesmo modo, um caso de uso pode envolver a participa
o de vrios atores, o que resulta na classificao dos atores tm prim rios ou se
cundrios. Um ator primrio aquele que inicia uma sequncia de interaes de
um caso de uso. So eles os agentes externos para os quais o caso de uso traz be
nefcio direto. As funcionalidades principais do sistema so definidas tendo em
mente os objetivos dos atores primrios. J um ator secundrio supervisiona,
opera, mantm ou auxilia na utilizao do sistema pelo atores primrios. Atores
secundrios existem apenas para que os atores primrios possam utilizar o sis
tema. Por exemplo, considere um programa para navegar pela Internet (ou seja,
um navegador ou browser). Para que o Usuri o (ator primrio) requisite uma p
gina ao programa, outro ator (secundrio) est envolvido: o Servidor Web. Note
que 0 ator primrio Usurio de certa forma auxiliado pelo ator secundrio.
Servidor Web, posto que atravs deste ltimo que o primeiro consegue alcan
ar seu objetivo (visualizar uma pgina da Internet). Outro exemplo pode ser
encontrado no cenrio de caso de uso do Quadro 4-5, no qual Cl i ente o ator
primrio e Sistema de Logstica o ator secundrio.

4.1.3 Relacionamentos
Casos de uso e atores no existem sozinhos. Alm desses ltimos, o modelo de
casos de uso possui um terceiro componente, cuja funo relacionar os atores
e casos de uso. Esse componente corresponde aos relacionamentos. Sendo as
sim, um ator deve estar relacionado a um ou mais casos de uso do sistema. Alm
disso, pode haver relacionamentos entre os casos de uso ou entre os atores de
um sistema. A UME define os seguintes relacionamentos para o modelo de casos
de uso: comunicao, incluso, extenso e generalizao. Os significados (semn
tica) desses relacionamentos so discutidos nas prximas sees. Antes de pas
sar s prximas sees, entretanto, bom enfatizar que todos esses relaciona-
62 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

mentos possuem uma notao grfica definida pela UML. Deixamos a apresen
tao dessas notaes para a Seo 4.2.

4.1.3.1 Relacionamento de comunicao


Um relacionamento de comunicao informa a que caso e uso o ator est asso
ciado. O fato de um ator estar associado a um caso de uso atravs de um relacio
namento de comunicao significa que esse ator interage (troca informaes)
com o sistema por meio daquele caso de uso. Um ator pode se relacionar com
mais de um caso de uso do sistema. O relacionamento de comunicao , de lon
ge, o mais comumente utilizado de todos os relacionamentos.

4.1.3.2 Relacionamento de incluso


O relacionamento de incluso existe somente entre casos de uso. Para entender o
princpio deste relacionamento, til uma analogia com um conceito comum em
linguagens de programao: a rotina. Em uma linguagem de programao, uma
seqncia de instrues pode ser agrupada em uma unidade lgica chamada roti
na. Quando a execuo dessa seqncia de instrues for necessria, a rotina
chamada de algum ponto do programa. O mecanismo de empacotar uma seqn
cia de instrues em uma rotina evita a repetio dessa seqncia em todo lugar
do programa em que ela se faz necessria. Na verdade, sempre que a seqncia de
instrues deve ser executada, a rotina correspondente chamada.
O princpio subjacente ao relacionamento de incluso entre casos de uso o
mesmo utilizado no mecanismo de definio de rotinas em linguagens de pro
gramao. Quando dois ou mais casos de uso incluem uma seqncia comum
de interaes, essa seqncia comum pode ser descrita em outro caso de uso. A
partir da, vrios casos de uso do sistema podem incluir o comportamento desse
caso de uso comum. Isso evita a descrio de uma mesma seqncia de intera
es mais de uma vez e, conseqentemente, torna a descrio dos casos de uso
um todo mais simples e de manuteno mais fcil. Como terminologia, o caso de
uso inclusor aquele que inclui o comportamento de outro caso de uso; j o caso
de uso incluso aquele cujo comportamento includo por outros.
Como exemplo de utilizao do relacionamento de incluso, considere
um sistema de controle de transaes bancrias. Alguns casos de uso desse sis
tema so Obter Extrato, Real i zar Saque e Real i zar Transfernci a. Esses casos
de uso tm uma seqncia de interaes em comum, a saber, a seqncia de
interaes para validar a senha do cliente do banco. Essa seqncia de intera
es em comum pode ser descrita em um caso de uso Fornecer Identi f i cao.
Dessa forma, todos os casos de uso que utilizam essa seqncia de interaes
podem fazer referncia ao caso de uso Fornecer Identi fi cao atravs do rela
cionamento de incluso.
MODELAGEM DE CASOS CE uso 63

Um aspecto relevante acerca do relacionamento de incluso relativo for


ma de referenciar o caso de uso incluso no caso de uso inclusor. A UML no es
pecifica uma forma padro de referncia. Conseqentemente, cada modelador
livre para definir sua forma de fazer referncia a um caso de uso incluso. Por ou
tro, um consenso o fato de que na descrio do caso de uso inclusor que deve
ser feita uma referncia para o caso de uso incluso. Recomendamos a utilizao
da seguinte sintaxe para referncia na descrio do caso de uso inclusor: Include
(nome do caso de uso incluso). Essa sintaxe indica que no ponto da descrio em
que for encontrada, a sequncia de interaes do caso de uso incluso inserida
(includa) no caso de uso inclusor.

4.1.3.3 Relacionamento de extenso


Considere dois casos de uso, A e B. Um relacionamento de extenso de A para B
indica que um ou mais dos cenrios de B podem incluir o comportamento espe
cificado por A. Nesse caso, diz-se que B estende A. O caso de uso A chamado de
estendido, e o caso de uso B de extensor.
O relacionamento de extenso utilizado para modelar situaes em que di
ferentes seqncias de interaes podem ser inseridas em um mesmo caso de
uso. Cada uma dessas diferentes seqncias representa um comportamento
eventual, ou seja, um comportamento que s ocorre sob certas condies, ou
cuja realizao depende da escolha do ator. Na realidade, quando o relaciona
mento de extenso utilizado de forma adequada, a descrio do caso de uso es
tendido no deve aparentar falta de completude, ou seja, essa descrio no
deve dar a entender que deve (necessariamente) existir uma extenso em seu
comportamento. Para concluir o raciocnio; a existncia do caso de uso estendi
do deve ser independente da existncia de quaisquer casos de uso que estendam
0 primeiro.
Quando um ator opta por executar a seqncia de interaes definida no ex
tensor (ou quando certa condio se torna verdadeira), este acionado. Aps a
sua execuo, o fluxo de interaes volta ao caso de uso estendido, recomean
do logo aps o ponto em que o extensor foi inserido.
importante notar que o caso de uso estendido uma descrio completa de
uma seqncia de interaes, com significado em si mesma. Isso quer dizer que
no necessariamente o comportamento definido pelo caso de uso extensor
utilizado pelo caso de uso estendido; pode haver cenrios em que apenas o com
portamento do caso de uso estendido executado, sem que o comportamento
de qualquer extensor seja acionado. O que desencadeia a execuo do compor
tamento definido pelo extensor a ocorrncia de alguma condio ou a solicita
o explcita do ator.
Uma questo importante diz respeito ao modo como feita a definio dos
pontos de extenso, ou seja, os locais da descrio do caso de uso estendido em
64 princpios de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

que o comportamento do extensor pode ser inserido. O comum fazer essa defi
nio na descrio textual do caso de uso extensor. A vantagem disso que o
caso de uso estendido no precisa ser modificado quando um caso de uso exten
sor tiver de ser adicionado. No entanto, se o formato de descrio numerada
(ver Seo 4.1.1.1) for utilizado, pode ser que, em uma eventual modificao do
estendido, a referncia descrita no extensor fique desatualizada. Por exemplo,
suponha que a descrio do extensor defina que este pode ser ativado entre os
passos 5 e 6 do estendido. Se um passo anterior do estendido fosse removido ou
um novo passo fosse adicionado, a referncia feita pelo extensor estaria errada.
O modelador deve definir um ponto de extenso como um composto de um
nome e de uma descrio. A descrio de um ponto de extenso deve indicar em
que ponto (ou pontos) do caso de uso estendido pode-se inserir o comporta
mento do extensor. J o seu nome pode ser apenas um mnemnico. Note que
pode haver diversos pontos no estendido em que o extensor pode ser ativado.
Em particular, pode ser que o extensor possa ser ativado entre quaisquer dois
passos do estendido. De qualquer maneira, as descries dos pontos de exten
so realizadas no caso de uso extensor devem declarar claramente e sem ambi-
gidades os locais de extenso.
Como um exemplo de possvel utilizao do relacionamento de extenso,
considere um processador de textos. Considere que um dos casos de uso deste
sistema seja Edi tar Documento, que descreve a seqncia de interaes que ocor
re quando um usurio edita um documento. No cenrio tpico desse caso de
uso, 0 ator abre o documento, modifica-o, salva as modificaes e fecha o docu
mento. Mas, em outro cenrio, o ator pode desejar que o sistema faa uma verifi
cao ortogrfica no documento. Em outro, ele pode querer realizar a substitui
o de um fragmento de texto por outro. Tanto a verificao ortogrfica quanto
a substituio de texto so espordicas, no-usuais, opcionais. Dessa forma, os
casos de uso Corrigi r Ortografia e Substitui r Texto podem ser definidos como
extenses de Editar Documento.
Como exemplo, a seguir apresentada a seqncia de interaes do caso de
uso extensor Substituir Texto, utilizando a primeira alternativa descrita h
pouco (o extensor indica em que ponto(s) pode ser ativado).

1. Em qualquer momento durante Editar Documento, o ator pode optar por


substituir um fragmento de texto por outro.
2. O ator fornece o texto a ser substitudo e o texto substituto.
3. O ator define os parmetros de substituio (substituir somente pala
vras completas ou ocorrncias dentro de palavras; substituir no docu
mento todo ou somente na parte selecionada; ignorar ou considerar le
tras maiusculas e minsculas).
4. O sistema substitui todas as ocorrncias encontradas no texto.
MODELAGEM DE CASOS DE USO 65

4.1.3.4 Relacionamento de generalizao


Os relacionamentos descritos anteriormente (incluso e extenso) implicam o
reuso do comportamento de um caso de uso na definio de outros casos de uso.
Outro relacionamento no qual o reuso de comportamento evidente o de ge
neralizao. O relacionamento de generalizao pode existir entre dois casos de
uso ou entre dois atores. Esse relacionamento permite que um caso de uso (ou
um ator) herde caractersticas de um caso de uso (ator) mais genrico, este lti
mo normalmente chamado de caso de uso (ator) base. O caso de uso (ator) her
deiro pode especializar o comportamento do caso de uso (ator) base. Vamos
examinar cada uma dessas duas alternativas.
Na generalizao entre casos de uso, sejam A e B dois casos de uso. Quando
B herda de A, as seqncias do comportamento de A valem tambm para B.
Quando for necessrio, B pode redefinir as seqncias de comportamento de A.
Alm disso, B (o caso de uso herdeiro) participa em qualquer relacionamento
no qual A (o caso de uso pai) participa. Ou seja, todo ator que puder realizar o
caso de uso pai pode tambm realizar qualquer caso de uso filho.
Uma consequncia da utilizao de generalizao entre casos de uso que
seqncias de comportamento descritas no caso de uso mais genrico so reuti
lizadas pelos casos de uso herdeiros. Somente o comportamento que no faz
sentido ou diferente para o caso de uso herdeiro precisa ser redefinido. Obvia
mente, um complicador se estabelece aqui. pois deve haver alguma maneira de
especificar na descrio do caso de uso herdeiro que passos do caso de uso pai
esto sendo redefinidos pelo primeiro. Isso pode ser feito com o posicionamen
to de marcadores no caso de uso pai. Esses marcadores podem, ento, ser refe
renciados na descrio do caso de uso filho para especificar que passos esto
sendo redefinidos ou onde est sendo definida uma extenso do comportamen
to do pai.
A UME estabelece que o caso de uso mais genrico em uma generalizao
pode ser concreto ou abstrato. Um caso de uso abstrato no apresenta compor
tamento associado. Por outro lado, um caso de uso concreto possui algum com
portamento. (A discusso no pargrafo anterior pressupe que o caso de uso pai
concreto.) Como boa prtica de modelagem, recomendamos que o caso de uso
pai de uma generalizao seja sempre abstrato. Isso evita complicaes com o
uso de marcadores. Alm disso, ainda podemos usar o relacionamento de gene
ralizao para o seu verdadeiro objetivo, que indicar que dois ou mais casos de
uso tm comportamentos semelhantes; o caso de uso abstrato utilizado ape
nas para capturar a natureza semelhante entre os casos de uso filhos, estes lti
mos concretos.
A generalizao entre atores significa que o ator herdeiro possui o mesmo
comportamento (em relao ao sistema) que o ator do qual ele herda. Isso im
plica que, se dois ou mais atores herdam de outro ator A, ento todos os casos de
66 princpios de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

USO associados com A percebem os atores herdeiros como sendo o ator A. Em


outras palavras, impossvel para um caso de uso relacionado com A perceber
diferena entre este e qualquer um de seus atores herdeiros; o ator A e seus her
deiros so percebidos como um s pelo caso de uso.
Outra caracterstica da generalizao entre atores o fato de que o ator her
deiro pode participar em casos de uso em que o ator do qual ele herda no parti
cipa. Note que a propriedade de assimetria da generalizao se aplica aqui: os
casos de uso vlidos para o ator herdeiro no so vlidos para o ator pai.
Assim como na generalizao entre casos de uso, um ator tambm pode ser
concreto ou abstrato. Mas, diferentemente daquele primeiro tipo de generaliza
o, na generalizao entre atores no h complicador envolvido na utilizao
de atores concretos.
Como um exemplo de generalizao entre atores, analise uma biblioteca
na qual pode haver dois tipos de usurios: alunos e professores. Os dois tipos
de usurio podem realizar emprstimos de ttulos de livros e reservas de
exemplares. Suponha que, com relao queles processos do negcio (em
prstimos e reservas), no haja diferena entre um professor e um aluno. Su
ponha ainda que somente o professor pode requisitar a compra de ttulos de
livros biblioteca. Nessa situao, poder-se-ia definir um ator chamado
Usurio e outro ator chamado Professor, que herdaria de Usurio. Assim, o
ator Professor herda todos os casos de uso do ator Usurio, significando que
um professor pode interagir com todos os casos de uso com que um usurio
comum interage. Alm disso, um professor tambm interage com o caso de
uso de requisio de compra de novos ttulos de livros, sendo que este caso
de uso especfico para professores.

4.1.3.5 Quando usar relacionamentos no MCU


Uma vantagem comum aos relacionamentos de incluso, extenso e generaliza
o que eles tornam possvel manter a descrio dos casos de uso o mais sim
ples possvel com a fatorao de seqncias de interaes comuns. Sem a utiliza
o desses relacionamentos, as descries de algumas seqncias poderiam se
repetir em vrios lugares, ou estar aglutinadas em um nico caso de uso gigante
e descompacto.
Uma dvida comum saber que tipo de relacionamento utilizar em dada si
tuao. Na verdade, no h regras para saber quando utilizar um ou outro tipo
de relacionamento; h somente heursticas.^ Sendo assim, para a escolha do re
lacionamento a utilizar, as seguintes heursticas podem ser seguidas:

Uma heurstica uma espcie de dica embasada na experincia prtica.


MODELAGEM DE CASOS DE USO 67

Incluso. Use incluso quando o mesmo comportamento se repetir em


mais de um caso de uso. Por meio do relacionamento de incluso esse
comportamento comum pode ser fatorado em um novo caso de uso, o
chamado caso de uso incluso. Note que esse comportamento comum est
necessariamente contido em todos os cenrios dos casos de uso inclusores,
e que estes ltimos no so completos sem o comportamento do caso de
uso incluso.
Extenso. Use extenso quando um comportamento eventual de um
caso de uso tiver de ser descrito. Note que alguns cenrios do caso de
uso estendido podem no utilizar esse comportamento eventual, pos
to que o mesmo opcional. Podemos tambm pensar em usar o rela
cionamento de extenso na situao em que precisamos estender o
comportamento de um caso de uso preexistente sem modificar sua
descrio original. Essa possibilidade importante, principalmente
em um processo de desenvolvimento iterativo (ver Seo 2.3.2). Isso
porque, quando iteraes subsequentes so realizadas em um projeto
de desenvolvimento (ocasio em que novas verses de casos de uso
preexistentes so desenvohidas), comum a situao de a equipe ter
que adicionar novos comportamentos queles casos de uso. Isso pode
ser feito com o relacionamento de extenso, sem a necessidade de alte
rar a descrio do caso de uso original.
Generalizao entre casos de uso. Use generalizao entre casos de
uso quando voc identificar dois ou mais casos de uso com comporta
mentos semelhantes. Crie. ento, um caso de uso mais genrico (de
preferncia abstrato) e o relacione por generalizao aos casos de uso
semelhantes. Note que a generalizao entre dois casos de uso implica
que 0 caso de uso herdeiro herda todo o comportamento de seu pai.
Portanto, se alguma parte do caso de uso pai no fizer sentido para o
caso de uso herdeiro, no faz sentido utilizar generalizao. Se apenas
algumas partes do caso de uso pai fizerem sentido para os potenciais
herdeiros, considere o uso dos relacionamentos de incluso da exten
so, em vez da generalizao.
Generalizao entre atores. Use generalizao quando precisar definir
um ator que desempenhe um papel que j desempenhado por outro ator
em relao ao sistema, mas que tambm possui comportamento particu
lar adicional.

A Tabela 4-1 resume as possibilidades de existncia de relacionamentos en


tre os elementos do modelo de casos de uso.
68 princpios DE ANALISE E PROJETO DE SISTEMAS COM UME, 2/E ELSEVIER

Tabela 4-1: Possibilidades de relacionamentos entre os elementos do modelo


de casos de uso

Comunicao Extenso Incluso Herana


Caso de uso e caso de uso X X X
Ator e ator ^ X
Caso de uso e ator X

Para finalizar esta seo, importante dizer que os relacionamentos (entre


casos de uso e entre atores) definidos pela UML devem ser utilizados com parci
mnia, Se no fizermos isso, corremos o risco de obter um MCU com vrios re
lacionamentos e difcil de ser entendido. Isso porque, quanto mais relaciona
mentos so utilizados, menor a clareza do modelo. Casos de uso no so espe
cificaes formais; portanto, descries repetidas em mais de um caso de uso
so aceitveis, desde que sejam controladas. O importante a notar que o MCU
uma pea fundamental na validao (ver Seo 2.1.2) de um sistema. Portanto,
a clareza e legibilidade desse modelo devem ser sempre levadas em conta quan
do estivermos pensando em utilizar qualquer um dos trs relacionamentos des
critos aqui. Para deixar claro: o modelo ideal aquele sem redundncias e leg
vel, mas se tivermos que sacrificar uma dessas qualidades, que seja a primeira.
Nesse ponto, a dica prtica que damos a seguinte: se voc tiver absoluta
certeza de que duas ou mais funcionalidades do sistema compartilham compor
tamento comum, ou se um modelador experiente, ento utilize os relaciona
mentos diretamente. Do contrrio, retarde a definio de quaisquer relacio
namentos de incluso, extenso e generalizao at o momento em que voc j
tiver definido uma primeira verso do MCU de seu sistema, contendo os casos
de uso concretos e seus atores. At l, voc ter um melhor entendimento do sis
tema e poder decidir com maior discernimento se a utilizao de um ou outro
relacionamento compensatria.

Se 0 modelador usar relacionamentos (de incluso, extenso e generalizao) em


excesso na construo de um MCU, h o risco da diminuio da clareza desse mode
lo. Lembre-se de que o MCU ferramenta fundamental na validao do sistema, em
que a facilidade de comunicao com o usurio (especialistas do domnio) um fator
determinante.

4.1.3.6 Decomposio funcional e relacionamentos entre casos de uso


Um erro bastante comum na identificao de relacionamentos entre casos de uso,
principalmente para desenvolvedores acostumados com as tcnicas de Anlise
MODELAGEM DE CASOS DE USO 69
ELSEVIER

Estruturada, o de considerar o MCU equivalente ao modelo funcional utilizado


na metodologia estruturada, no qual se utiliza a ferramenta de DFD (Diagrama
de Fluxos de Dados) para representar processos do sistema. Para a construo
do modelo funcional, utiliza-se o procedimento da decomposio funcional.
Nesse procedimento, o sistema interpretado como um grande processo que
pode ser particionado em processos menores e mais simples. Cada um desses,
por sua vez, pode tambm ser particionado em outros mais simples ainda, e as
sim por diante. A aplicao desse procedimento resulta em uma rede hierrqui
ca de processos. Em cada nvel dessa hierarquia, existem processos que so mais
simples que os do nvel acima, e mais complexos que os do nvel abaixo. Alm
disso, as funes de cada nvel esto indiretamente conectadas por depsitos de
dados, repositrios de informaes que tais funes processam. As funes do
sistema se comunicam atravs dos depsitos de dados. No ltimo nvel dessa
hierarquia, existem as primitivas funcionais, processo simples o suficiente para
serem entendidos facilmente e que, por conta disso, no precisam ser particio
nados. Dessa forma, o modelo funcional acaba por estabelecer a estrutura fun
cional interna e o fluxo de informaes entre as funes do sistema. O modelo
funcional, portanto, no prov uma viso externa do sistema (como o faz o mo
delo de casos de uso), mas, sim, uma viso de seu comportamento interno (em
bora em um nvel de abstrao alto).
Outro erro de modelagem resultante da confuso entre modelagem de casos
de uso e modelagem funcional quebrar" (em dois ou mais casos de uso) fun
cionalidades que na verdade pertencem a um mesmo caso de uso. Com relao a
isso, importante ter em mente que um caso de uso uma descrio completa
de uma seqncia de interaes, cuja realizao traz um resultado de valor para
o ator envolvido; ele no normalmente um passo ou atmdade individual em
um processo. Por exemplo, considere um sistema que funciona \ia Internet e
que possibilita a compra de livros por usurio cadastrados. Nessa situao,
muito provvel que a definio de um caso de uso denominado Imprimi r Fatura
no seja correta. mais provvel que aquela seqncia de interaes seja uma
subseqncia contida em uma seqncia maior, esta ltima correspondente a
um caso de uso denominado Comprar Produtos.
Outra m interpretao que pode ser feita pelo modelador iniciante pensar
que casos de uso se comunicam, assim como funes (processos) podem se co
municar em um DFD (atravs de depsitos de dados). Esse erro um sintoma de
que o modelador est tentando definir a estrutura interna do sistema no MCU
com o uso de relacionamentos (ver Seo 4.1.3). Em um MCU, quando definimos
um relacionamento (de incluso, extenso ou generalizao) entre dois casos de
uso, no existe a semntica de troca de dados entre os mesmos. Esse caso de uso
chama o outro, certa vez ouvi um iniciante em modelagem declarar. Em modela
gem de casos de uso, essa interpretao simplesmente no faz sentido.
70 prin cp io s de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Em resumo, o enfoque ao utilizar casos de uso e seus relacionamentos iden


tificar os objetivos do usurio, em vez das funes do sistema. Tenha em mente que
o MCU define uma viso externa do sistema. Embora essa viso externa implique
uma descrio tcnica das aes e das estruturas internas do sistema, esses aspec
tos no so considerados nesse modelo. A modelagem de casos de uso no uma
ferramenta para realizar a decomposio funcional do sistema. Em vez disso, ca
sos de uso fornecem uma perspectiva externa do comportamento do sistema, sem
prover detalhes sobre a lgica interna de funcionamento deste ltimo.

4.2 Diagrama de casos de uso


Na Seo 4.1, descrevemos os principais componentes de um MCU: atores, ca
sos de uso e relacionamentos. Apresentamos tambm diversos estilos de descri
o possveis para um caso de uso. O conjunto de descries dos casos de uso e
atores corresponde perspectiva textual do MCU. Nesta seo, nosso interesse
recai sobre a perspectiva grfica do MCU, representada pelo diagrama de casos
de uso (DCU).
O DCU um dos diagramas da UML e corresponde a uma viso externa de
alto nvel do sistema. Esse diagrama representa graficamente os atores, casos de
uso e relacionamentos entre esses elementos. O DCU tem o objetivo de ilustrar
em um nvel alto de abstrao quais elementos externos interagem com que
funcionalidades do sistema. Nesse sentido, a finalidade de um DCU apresen
tar um tipo de diagrama de contexto que apresenta os elementos externos de
um sistema e as maneiras segundo as quais eles as utilizam.
A notao utilizada para ilustrar atores em um DCU a figura de um bone
co, com o nome do ator definido abaixo da figura. Note que essa notao no
corresponde ao significado de ator em sua completude, porque um ator nem
sempre corresponde a seres humanos, como a notao leva a entender (ver Se
o 4.1.2). Cada caso de uso representado por uma elipse. O nome do caso de
uso posicionado abaixo ou dentro da elipse. Um relacionamento de comuni
cao representado por um segmento de reta ligando ator e caso de uso. Um
ator pode estar associado atravs do relacionamento de comunicao a vrios
casos de uso em um DCU. Pela UML, tambm possvel imprimir um sentido
ao segmento de reta correspondente a um relacionamento de comunicao,
para denotar o sentido das informaes. No entanto, essa situao tem pouco
uso prtico e, normalmente, o segmento de reta do relacionamento de comuni
cao definido sem o sentido. A Eigura 4-2 ilustra a notao da UML para re
presentar atores, casos de uso e relacionamentos de comunicao. Esses trs
elementos so os mais comumente utilizados.
Pode-se tambm representar a fronteira do sistema em um diagrama de ca
sos de uso. Essa fronteira representada por um retngulo no interior do qual
MODELAGEM DE CASOS DE USO 71

Caso de uso

Figura 4-2: Notao para ator, caso de uso


e relacionamento de comunicao.

so inseridos os casos de uso. Os atores so posicionados do lado de fora do re


tngulo, para enfatizar a diviso entre o interior e o exterior do sistema. A Figu
ra 4-3 apresenta um exemplo de diagrama de casos de uso no qual se utiliza uma
fronteira. Por simplicidade, esse diagrama exibe um nico caso de uso.

Figura 4-3: Exemplo de diagrama de casos de uso


utilizando um retngulo de fronteira.

O relacionamento de incluso (ver Seo 4.1.3.2), em que um caso de uso A


inclui um caso de uso B, representado por uma seta direcionada de A para B. O
eixo dessa seta tracejado e rotulado com o esteretipo (ver Seo 3.1) predefi-
nido i ncl ude. A Figura 4-4 ilustra a representao do relacionamento de inclu
so em um DCU. Esse diagrama informa que os casos de uso Obter Extrato, Rea
lizar Saque e Real izar Transferncia tm uma seqncia de interaes em co
mum, a saber, a seqncia para autenticar o cliente do banco que est represen
tada pelo caso de uso Fornecer Identificao.
72 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

O relacionamento de extenso, em que um caso de uso A estende um caso


de uso B, representado por uma seta direcionada de A para B. Essa seta, de eixo
tambm tracejado, rotulada com outro esteretipo predefinido pela UML, o
extend. A Figura 4-5 ilustra a representao desse relacionamento. Essa figura
mostra que os casos de uso C o rrig i r O rto g rafia e S u b stitu i r Texto tm sequn
cias de interaes que so eventualmente utilizadas quando o ator Escri to r esti
ver utilizando a caso de uso E d ita r Documento.

Figura 4-5: Exemplo de relacionamento de extenso

A Figura 4-6 ilustra exemplos do relacionamento de generalizao em suas


duas formas: entre casos de uso e entre atores. A generalizao entre casos de
uso indica que os casos de uso R e a liza r Pagamento com Carto de Crdi to e Real i -
zar Pagamento com Di nhei ro so casos especiais do caso de uso Real i zar Pagamen
to. J a generalizao entre os atores Usuri o e P ro fe sso r indica que este ltimo
pode interagir com qualquer caso de uso que um usurio comum interage.
MODELAGEM DE CASOS DE USO 73

Figura 4-6: Exemplos de utilizao do


relacionamento de generalizao.

extend

include

Figura 4-7: Elementos grficos da UML para o desenho de um DCU.

Alm disso, o Professor pode participar em outros casos de uso especficos a ele,
como, por exemplo. Solicitar Compra de Titulo.

4.3 identificao dos elementos do MCU


Nas Sees 4.1 e 4.2, apresentamos os componentes do MCU e descrevemos deta
lhes acerca de suas perspectivas textual e grfica. O domnio das regras definidas
sobre essas duas perspectivas importante para a construo de modelos de casos
de uso corretos. Entretanto, to importante quanto dominarmos a notao do
MCU termos conhecimento de tcnicas e boas prticas de modelagem que, se
seguidas e utilizadas, nos levam construo de modelos coerentes com as reais
necessidades dos futuros usurio. Nesta seo, estudamos ento algumas tcnicas
que podem ser aplicadas para a correta identificao dos elementos de um MCU.
74 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E E LS E V IE R

Os atores que interagem com um sistema e os casos de uso desse sistema so


identificados a partir de informaes coletadas na fase de levantamento de re
quisitos (ver Seo 2.1.1). Durante essa fase, os analistas de sistemas (ver Seo
2.2.2) devem identificar as atividades dos processos de negcio que devem ser
automatizadas pelo sistema a ser construdo. Os analistas tambm devem iden
tificar quais os elementos que interagem naqueles processos.
Nesta seo, so descritas algumas dicas sobre como identificar atores e ca
sos de uso. Vale dizer que no h uma regra geral que indique quantos casos de
uso so necessrios para descrever completamente um sistema. A quantidade
de casos de uso a ser utilizada depende completamente da complexidade do sis
tema. Sistemas de software de porte mdio possuem de 15 a 20 casos de uso, en
quanto os realmente complexos chegam a possuir at uma ordem de grandeza a
mais que os de porte mdio.

4.3.1 Identificao de atores


Para comear a construir o MCU, todos os atores do sistema devem ser identifi
cados. Para identificar os atores, o analista de sistemas deve tentar identificar
quais as fontes de informaes a serem processadas e quais so os destinos das
informaes geradas pelo sistema. Se o sistema estiver sendo desenvolvido para
uma empresa, o analista deve identificar as reas dessa empresa que sero afeta
das ou utilizaro o sistema. Como, por definio, um ator todo elemento ex
terno que interage com o sistema, as fontes e os destinos das informaes a se
rem processadas so atores em potencial.
Na identificao de atores, h algumas perguntas teis para as quais os ana
listas de sistemas devem procurar respostas:
1. Que rgos, empresas ou pessoas utilizaro o sistema?
2. Que sistemas ou equipamentos iro se comunicar com o sistema a ser
construdo?
3. Algum deve ser informado de alguma ocorrncia no sistema?
4. Quem est interessado em certo requisito funcional do sistema?

Alm de fazer essa identificao inicial, o desenvolvedor deve continuar a


pensar sobre atores quando passar para a identificao dos casos de uso, pois
nessa atividade podem aparecer atores ainda no identificados.

4.3.2 Identificao de casos de uso


A partir da lista de atores, deve-se passar identificao dos casos de uso. Nessa
identificao, pode-se distinguir entre dois tipos de casos de uso: primrio e se
cundrio. Passamos para a descrio desses dois tipos de casos de uso nas prxi
mas sees.
MODELAGEM DE CASOS DE USO 75

4.3.2.1 Casos de uso primrios


Casos de uso primrios so aqueles que representam os objetivos dos atores.
Esses casos de uso representam os processos da empresa que esto sendo auto
matizados pelo sistema de software. A seguir so enumeradas algumas pergun
tas para as quais os analistas de sistemas devem procurar respostas com o intui
to de identificar os casos de uso primrios de um sistema:

1. Quais so as necessidades e os obj etivos de cada ator em relao ao sistema?


2. Que informaes o sistema deve produzir?
3. O sistema deve realizar alguma ao que ocorre regularmente no tempo?
4. Para cada requisito funcional, existe um (ou mais) caso(s) de uso para
atend-lo?

Ao modelador tambm possvel utilizar outras tcnicas de identifica


o. Pode-se considerar as seguintes situaes (na descrio das situaes a
seguir, so dados exemplos considerando um sistema de venda de livros pela
Internet);

Caso de uso oposto: chama-se caso de uso oposto aquele cuja realizao
desfaz o resultado da realizao de outro caso de uso. Por exemplo, pode
ser que um cliente tenha a possibilidade de cancelar um pedido de com
pra realizado anteriormente. Xesse caso, no preciso pensar muito para
identificar um novo caso de uso. Cancelar Pedido. Deve-se perguntar de
forma geral, para cada caso de uso; "As aes realizadas pelo sistema
quando da realizao deste caso de uso podem ser desfeitas?.
Caso de uso que precede outro caso de uso: algumas vezes, certas condi
es devem ser verdadeiras quando da execuo de um caso de uso. Por
exemplo, para que um cliente realize um pedido de compra, necess
rio que ele esteja cadastrado no sistema da IhTaria virtual. Isso leva a um
novo caso de uso para que o cliente se cadastre. Alm disso, para realizar
um pedido de compra, o cliente deve ter a possibilidade de obter deta
lhes de determinados produtos atravs de um mecanismo de busca. De
forma geral, a pergunta a ser feita para identificar casos de uso prece
dentes , para cada caso de uso, o que pode ocorrer antes da realizao
deste caso de uso?.
Caso de uso que sucede a outro caso de uso: uma outra estratgia de identifi
cao pensar nas conseqncias da realizao de um caso de uso. Por
exemplo, considerando o mesmo exemplo da livraria virtual, quando um
cliente realiza uma compra, pode ser que haja a necessidade de agendar a
entrega dessa compra. Nessa situao, um possvel caso de uso decorren
te seria Agendar Entrega de Pedido, no qual um funcionrio da livraria se-
76 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

leciona alguns pedidos para serem entregues em certa data. A pergunta


geral que se deve fazer para cada caso de uso identificado o que pode
ocorrer aps a realizao deste caso de uso?.
Caso de uso temporal: pode haver funcionalidades realizadas pelo sistema
que no so iniciadas por um ator. Isso normalmente acontece quando o
sistema deve realizar alguma tarefa de tempos em tempos, sem interven
o externa.^ Por exemplo: O sistema deve gerar um relatrio de vendas
toda sexta-feira. A pergunta geral nessa situao ; H alguma tarefa
que 0 sistema deva realizar automaticamente?. Em um caso de uso tem
poral, normalmente o ator definido como o agente que recebe a infor
mao resultante (por exemplo, um funcionrio recebe o relatrio de
execuo do sistema). Alternativamente, pode-se definir um ator fictcio.
Tempo, que estar associado ao referido caso de uso (ver Figura 4-8).

Tempo

Figura 4-8: Formas alternativas de representar


um caso de uso temporal.

Caso de uso relacionado a alguma condio interna: assim como nos casos
de uso temporais, esta uma situao em que no h um ator diretamente
envolvido. Nessa situao, o sistema deve realizar alguma funcionalidade
de acordo com a ocorrncia de algum evento interno. Dois exemplos dis
so so os seguintes: o sistema deve notificar o usurio de que h novas
mensagens de correio; o sistema deve avisar o almoxarife de que um de
terminado produto chegou no nvel de estoque mnimo.

^ O leitor familiarizado com a Metodologia de Anlise Essencial ir se recordar de um conceito seme


lhante, 0 dos denominados/luxos e eventos temporais.
MODELAGEM DE CASOS DE uso 77

4.3.2.2 Casos de uso secundrios


Um caso de uso secundrio aquele que no traz benefcio direto para os atores,
mas que necessrio para que o sistema funcione adequadamente. Esses casos
de uso se encaixam nas seguintes categorias:

Manuteno de cadastros: freqentemente h a necessidade de incluso,


excluso, alterao ou consulta sobre dados cadastrais. Por exemplo, em
um sistema de folha de pagamento, deve haver cadastros para funcion
rios e cargos. Normalmente, o mais adequado criar um caso de uso que
corresponda s quatro operaes."^ Isso feito quando todas as operaes
cadastrais so realizadas pelo mesmo ator. Quando as operaes cadas
trais so realizadas por atores diferentes, melhor criar casos de uso sepa
rados para elas. Isso vale de forma geral: sempre mais adequado agrupar
casos de uso de manuteno de cadastros por ator, e no pelo item de in
formao sendo cadastrado. Por fim, importante notar que h certa con
trovrsia na literatura acerca da necessidade de definio de casos de uso
de cadastro. Recomendamos a definio explcita desses casos de uso.
Isso porque, quando um agente externo precisa cadastrar alguma infor
mao, algum comportamento do sistema iniciado por esse agente; ele
usa o sistema para criar (alterar, excluir ou pesquisar) um item de infor
mao. fcil ver que essa situao se encaixa nas definies de caso de
uso e de ator. Alm disso, no considerar certa funcionalidade de cadas
tro no MCU torna esse modelo incompleto e suscetvel a mais de uma in
terpretao: a funcionalidade ser implementada, embora no tenha sido
modelada no MCU, ou o fato de ela no aparecer no MCU significa que
no ser implementada?
Manuteno de usurios e de seus perfis: adio de novos usurios, atribui
o de direitos de acesso, configurao de perfis de usurios etc.
Manuteno de informaes provenientes de outr os sistemas: pode ser o caso
em que o sistema deva se comunicar com outro sistema. Por exemplo, em
um sistema de venda de produtos, pode haver a necessidade de comuni
cao com um sistema de controle de estoque para saber a quantidade de
produtos disponveis. Nesses casos, as informaes em um sistema e no
outro devem ser sincronizadas.

Uma observao importante: embora os casos de uso secundrios devam ser


considerados, o modelador deve priorizar inicialmente a identificao dos casos
de uso primrios, que representam os processos do negcio da empresa. Comear
a identificao pelos casos de uso secundrios uma indicao de que o modela-

Esses so conhecidos como casos de uso CRUD (create-read-update-delete).


78 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

dor est pensando em como o sistema deve ser construdo. O ponto-chave consi
derar que um sistema de software no existe para cadastrar informaes, tampou
co para gerenciar os seus usurios. O objetivo principal de um sistema produzir
algo de valor para o ambiente no qual ele est implantado.

4.4 Construo do modelo de casos de uso


Na Seo 4.3, descrevemos algumas heursticas para identificao dos elemen
tos de um MCU. Entretanto, uma vez que esses elementos esto identificados,
como document-los para construir o modelo de casos de uso propriamente
dito? A construo de um MCU envolve a construo das suas duas perspecti
vas, a grfica e a textual. A primeira corresponde ao diagrama de casos de uso, en
quanto a segunda corresponde documentao dos atores e casos de uso. Nas
prximas sees, descrevemos a construo desses artefatos.

4.4.1 Construo do diagrama de casos de uso


Conforme descrevemos anteriormente, um objetivo importante, talvez o prin
cipal, de um MCU o da comunicao. Ele deve prover um veculo que permita
a especialistas do domnio e desenvolvedores discutirem as funcionalidades do
sistema e o seu comportamento. Por outro lado, o DCU deve servir para dar su
porte parte escrita do modelo, fornecendo uma viso de alto nvel do sistema e
obviamente sendo coerente com aquela parte escrita. Na Seo 4 ..3 , analisa
mos os relacionamentos possveis de serem utilizados em um MCU e a (poten
cial) falta de legibilidade que seu uso em excesso pode trazer. Como o DCU
deve ser coerente com a parte escrita, a falta de legibilidade pode tambm se
propagar para a parte grfica do modelo. Se o diagrama um emaranhado inde
cifrvel de elementos grficos, ele no est cumprindo seu objetivo, que de co
municar. Nesse sentido, quanto mais fcil for a leitura do DCU, melhor. Portan
to, a clareza do DCU (e de qualquer diagrama da UML) deve ser uma preocupa
o constante do modelador.
Para um sistema de software pequeno ou mdio (composto de uma ou duas
dzias de casos de uso), o seu DCU muito provavelmente cabe em uma folha de
papel (ou na tela de uma ferramenta CASE) e pode ser visualizado e entendido
de uma nica vez. Portanto, para esse tipo de sistema, o modelador pode criar
um nico DCU. Nesse diagrama, opcionalmente utiliza-se um retngulo de fron
teira. Os casos de uso so desenhados dentro do retngulo, e os atores so dese
nhados do lado de fora. O objetivo dessa disposio dar uma idia visual clara
da fronteira do sistema. Esse diagrama permite oferecer uma viso global e de
alto nvel do sistema.
Contudo, para sistemas mais complexos, a quantidade de casos de uso cres
ce acima desse limite de fcil visualizao. Representar todos os casos de uso em
MODELAGEM DE CASOS DE USO 79

um nico DCU talvez esse diagrama torne um tanto ilegvel. Nessa situao, o
modelador pode decidir formar grupos de casos de uso logicamente relaciona
dos, em que cada grupo pode ser visualizado de uma s vez. Nessas situaes, o
modelador pode adotar a abordagem de criar vrios diagramas de casos de uso.
A alocao dos casos de uso e os atores por esses diagramas deve ser feita de
acordo com as necessidades de visualizao. A seguir descrevemos alguns crit
rios que podem ser adotados:

Diagrama que exibe um caso de uso e seus relacionamentos.


Diagrama que exibe todos os casos de uso para um ator.
o Diagrama que exibe todos os casos de uso a serem implementados em
uma iterao de desenvolvimento.
9 Diagrama que exibe todos os casos de uso de uma diviso (parte) especfi
ca da organizao.

O uso de pacotes (ver Seo 3.5) permite formar grupos de casos de uso e
atores de tal sorte que o MCU possa ser compreendido e gerenciado por partes.
Em sistemas complexos, os elementos do MCU podem ser divididos em diver-
80 princpios de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

SO Spacotes. No contexto da modelagem d e casos de uso, os pacotes podem ser


utilizados com diversos objetivos. A seguir, so listados alguns desses objetivos:
Para estruturar o modelo de casos de uso de maneira que reflita os tipos
de usurios do sistema.
Para definir a ordem na qual os casos de uso sero desenvolvidos.
Para definir o grau de correlao entre os casos de uso.

A abordagem de representar os casos de uso em diversos diagramas e agru


par cada diagrama em pacote apresenta a desvantagem de se dificultar a manu
teno do MCU. Contudo, uma boa ferramenta CASE (ver Seo 2.6) deve aju
dar nessa tarefa.

0 modelador deve sempre tentar maximizar a legibilidade do DCU. Se necessrio,


deve-se criar mais de um diagrama de casos de uso.

4.4.2 Documentao dos atores


A documentao de atores relativamente simples. Uma breve descrio (uma
frase ou duas) para cada ator deve ser adicionada ao modelo de casos de uso. O
nome escolhido para um ator deve ser escolhido de tal forma que lembre o papel
desempenhado pelo mesmo no sistema.

4.4.3 Documentao dos casos de uso


Conforme mencionamos na Seo 4.1.1, a UML no define uma estruturao
especfica a ser utilizada na descrio de um caso de uso. Por conta disso, h di
versas propostas de descrio. Nesta seo, apresentada uma proposta para a
descrio de um caso de uso expandido.^ No entanto, antes de comear a apre
sentao, o leitor deve atentar para o fato de que essa proposta apenas uma su
gesto. Pode ser que uma equipe de desenvolvimento no precise utilizar todos
os itens aqui mencionados; pode at ser que mais detalhes sejam necessrios.
De qualquer modo, a equipe de desenvolvimento deve utilizar os itens de des
crio que forem realmente teis e mais inteligveis para o usurio.

4.4.3.1 Nome
O primeiro item que deve constar da descrio de um caso de uso o seu nome.
Este deve ser o mesmo nome utilizado no DCU. Cada caso de uso deve ter um
nome nico.

' o formato aqui fornecido uma adaptao do proposto pelo Grupo Guild (Guild, 2002).
MODELAGEM DE CASOS DE USO 81
ELSEVIER

4.4.3.2 Identificador
O identificador um cdigo nico para cada caso de uso que permite fazer refe
rncia cruzada entre diversos documentos relacionados com o MCU (por
exemplo, a descrio de um cenrio do caso de uso pode fazer referncia a esse
identificador). Uma conveno de nomenclatura que recomendamos usar o
prefixo CSU seguido de um nmero seqencial. Por exemplo: CSUOl, CSU02.

4.4.3.3 Importncia
A definio da categoria de importncia atribuda ao caso de uso. A Seo 4.6
detalha as possveis categorias em que um caso de uso pode se encontrar.

4.4.3.4 Sumrio
Uma pequena declarao do objetivo do ator ao utilizar o caso de uso (no mxi
mo duas frases).

4.4.3.5 Ator primrio


O nome do ator que inicia o caso de uso. (Note que pode ser que o ator no inicie
o caso de uso, mas ainda assim seja alvo do resultado produzido pelo caso de
uso.) Um caso de uso possui apenas um ator primrio.

4.4.3.6 Atores secundrios


Os nomes dos demais elementos externos participantes do caso de uso, os ato
res secundrios (ver Seo 4.1.2). Um caso de uso possui zero ou mais atores se
cundrios.

4.4.3.7 Precondies
Pode haver alguns casos de uso cuja realizao no faz sentido em qualquer mo
mento, mas ao contrrio, somente quando o sistema est em um determinado
estado com certas propriedades.
Uma precondio de um caso de uso define que hipteses so assumidas
como verdadeiras para que o caso de uso tenha incio. Este item da descrio
pode conter zero ou mais precondies.

4.4.3.8 Fluxo principal


O fluxo principal de um caso de uso, por vezes chamado de fluxo bsico, corres
ponde sua descrio da seqncia de passos usual. Isso significa que fluxo prin
cipal descreve o que normalmente acontece quando o caso de uso utilizado.
Toda descrio de caso de uso deve ter um fluxo principal. O texto descritivo des-
82 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

se fluxo (assim como dos fluxos alternativos e de exceo, descritos a seguir) deve
ser claro e conciso. Alm disso, nessa descrio, o modelador deve se ater ao do
mnio do problema, e no soluo deste. Portanto, o jargo computacional no
deve ser utilizado na descrio de casos de uso; ao contrrio, casos de uso devem
ser escritos do ponto de vista do usurio e usando a terminologia deste.

4.4.3.9 Fluxos alternativos


Por vezes, um caso de uso pode ser utilizado de diversas maneiras possveis, o
que resulta na existncia de diversos cenrios para o mesmo (ver Seo 4.1.1.4).
Esses fluxos podem ser utilizados para descrever o que acontece quando o ator
opta por utilizar o caso de uso de uma forma alternativa, diferente da descrita no
fluxo principal, para alcanar o seu objetivo. Fluxos alternativos tambm po
dem ser utilizados para descrever situaes de escollta exclusivas eutie si (em
que h diversas alternativas e somente uma deve ser realizada). A Figura 4-10
ilustra de forma esquemtica essas situaes de uso dos fluxos alternativos. As
linhas tracejadas representam fluxos alternativos. A linha slida representa o
fluxo principal. Note que a descrio de um caso de uso pode ter somente o flu
xo principal, sem fluxos alternativos.

Fluxo principal Fluxo principal


Fluxo principal
com alternativas com alternativas
sem alternativas
independentes exclusivas entre si

I
/ \ \
/
/ /,

\
I
\
'
Al A2 A3 A4
I I >
1 \ i '
/ I
/ /


Figura 4-10: Fluxos alternativos em um caso de uso.

Uma dvida que pode existir durante a descrio de um caso de uso se um


determinado comportamento deve ser descrito como um fluxo alternativo ou
como um caso de uso de extenso (ver Seo 4.1.3.3). Podemos resolver esse di
lema recorrendo definio do relacionamento de extenso. Esse relaciona
mento implica que, ao comportamento de um caso de uso, pode ser inserido o
comportamento definido em outro caso de uso. Note a utilizao do termo in-
MODELAGEM DE CASOS DE uso 83

serido, significando que o comportamento do caso de uso extensor no substi


tui parte alguma do caso de uso estendido, mas, sim, o complementa. Podemos
pensar no caso de uso extensor como uma extenso que descreve um comporta
mento que funciona como uma interrupo em relao ao caso de uso de esten
dido. Por outro lado, um fluxo alternativo descreve um comportamento alter
nativo para a execuo do fluxo principal, que substitui uma parte do compor
tamento do fluxo principal. De qualquer maneira, a deciso de utilizar um fluxo
alternativo ou um caso de uso de extenso no ter tanta importncia quanto o
fato de ignorar a existncia do comportamento adicional.

4.4.3.10 Fluxos de exceo


Um fluxo de exceo similar a um fluxo alternativo, posto que tambm repre
senta um comportamento executado como um desvio a partir do fluxo bsico
de um caso de uso. No entanto, os primeiros correspondem descrio de situa
es de exceo. Isso significa que fluxos de exceo descrevem o que acontece
quando algo inesperado ocorre na interao entre ator e caso de uso (por exem
plo, quando um usurio realiza alguma ao invlida).
A importncia de fluxos de exceo est no fato de o modelador poder espe
cificar situaes no usuais, a partir das quais o sistema pode se recuperar (con
tornar a situao) ou pode cancelar a realizao do caso de uso em questo.
Um fluxo de exceo possui algumas caractersticas importantes, listadas a
seguir.

1. Representa um erro de operao durante o fluxo principal do caso de uso.


2. No tem sentido fora do contexto do caso de uso no qual ocorre.
3. Deve indicar em que passo o caso de uso continua ou, conforme for, indi
car explicitamente que o caso de uso termina.

Por exemplo, considere um caso de uso denominado Realizar Pedido, em


que um ator usa o sistema para realizar uma encomenda (pedido) de quaisquer
produtos. A seguir, so listadas algumas situaes no usuais que seriam trata
das em fluxos de exceo na descrio desse caso de uso.

E se o carto de crdito excede o limite?


E se a loja no tem a quantidade requisitada para um dos produtos desejados?
E se o cliente j tem um dbito anterior?

4.4.3.11 Ps-condies
Em alguns casos, em vez de gerar um resultado observvel, o estado do sistema
pode mudar aps um caso de uso ser realizado. Essa situao especificada
84 princpios de a n a l is e e pro jeto de s i s t e m a s com UML, 2/E ELSE\aER

como uma ps-condio. Uma ps-condio um estado que o sistema alcana


aps certo caso de uso ter sido executado.
A ps-condio deve declarar qual esse estado, em vez de declarar como esse
estado foi alcanado. Um exemplo tpico de ps-condio a declarao de que
uma (ou mais de uma) informao foi modificada, removida ou criada no siste
ma. Ps-condies so normalmente descritas utilizando o tempo pretrito.

4.4.3.12 Regras do negcio


A descrio de um caso de uso tambm pode fazer referncia cruzada a uma ou
mais regras do negcio. Por sua importncia, deixamos o detalhamento de regras
do negcio para a Seo 4.5.1.

4.4.3.13 Histrico
Este item da descrio do caso de uso pode declarar informaes como o autor
do caso de uso, a data em que ele foi criado, alm de eventuais modificaes no
seu contedo.

4.4.3.14 Notas de implementao


Na descrio dos fluxos (principal, alternativos e de exceo) de um caso de
uso, o objetivo manter a narrativa em um alto nvel e utilizar a terminologia do
domnio. Entretanto, ao realizar tais descries, podem vir mente do modela
dor algumas consideraes relativas implementao desse caso de uso. A se
o notas de implementao serve para capturar essas idias. Note que essa seo
no a especificao da soluo para implementar um caso de uso. Ela serve
to-somente para capturar idias de implementao relevantes que passam pela
cabea do modelador do caso de uso, enquanto o est descrevendo. Note tam
bm que esta seo (assim como a seo de histrico) no deve ser utilizada na
atividade de validao (consulte a Seo 2.1.2).

4.5JDocumentao suplementar ao MCU


o MCU captura os requisitos funcionais e fora o desenvolvedor a pensar em
como os agentes externos interagem com o sistema. No entanto, esse modelo
corresponde somente aos requisitos funcionais. Outros tipos de requisitos
(desempenho, interface, segurana, regras do negcio etc.) que fazem parte
do documento de requisitos de um sistema no so considerados pelo modelo
de casos de uso. Est fora do escopo deste texto introdutrio dar uma descri
o detalhada sobre como documentar todos os possveis tipos de requisitos
de um sistema.
MODELAGEM DE CASOS DE USO 85

Entretanto, esta seo descreve como alguns dos demais itens da especifica
o de requisitos podem estar relacionados com o modelo de casos de uso. Os
itens aqui considerados so os seguintes:

Regras do negcio
Requisitos de interface
Requisitos de desempenho

4.5.1 Regras do negcio


Regras do negcio so polticas, condies ou restries que devem ser conside
radas na execuo dos processos existentes em uma organizao (Gottesdiener,
1999). As regras do negcio constituem uma parte importante dos processos
organizacionais porque elas descrevem a maneira como a organizao funcio
na. O termo regra de negcio" utilizado mesmo em organizaes que no se
caracterizam como empresariais.
Cada organizao pode ter vrias regras do negcio. As regras do negcio de
uma organizao so normalmente identificadas nas fases de levantamento de
requisitos de anlise. Essas regras so documentadas no chamado modelo de re
gras do negcio. Nesse modelo, as regras so categorizadas. Cada regra normal
mente recebe um identificador (assim como acontece para cada caso de uso).
Esse identificador permite que a regra seja facilmente referenciada nos demais
artefatos do processo de desenvolvimento.
A descrio do modelo de regras do negcio pode ser feita utilizando-se tex
to informal, ou alguma forma de estruturao. Alguns exemplos de regras do
negcio (no pertencentes a uma mesma organizao) so apresentados aqui:

O valor total de um pedido igual soma dos totais dos itens do pedido acres
cido de 10% de taxa de entrega.
Um professor s pode estar lecionando disciplinas para as quais esteja habi
litado.
Um cliente do banco no pode retirar mais deRSl. 000 por dia de sua conta.
Os pedidos para um cliente no-especial de\ em ser pagos antecipadamente.
Para alugar um carro, o proponente de\ e estar com a carteira de motorista
vlida.
O nmero mximo de alunos por tunna igual a 30.
Um aluno deve ter a matrcula cancelada se obtiver dois conceitos D no curso.
Uma vez que um professor confiiina as notas de uma turma, estas no podem
ser modificadas.
Senhas devem ter, no mnimo, seis caracteres, entre nmeros e letras, e devem
ser atualizadas a cada trs meses.
86 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

As regras do negcio normalmente tm influncia sobre a lgica de execu


o de um ou mais casos de uso. Por exemplo, considere a ltima regra ilustrada
anteriormente. Essa regra implica que deve haver uma maneira de informar ao
usurio quando uma atualizao necessria e um modo pelo qual o usurio
possa atualizar a sua senha, o que tem influncia no modelo de casos de uso do
sistema.
Para conectar uma regra a um caso de uso no qual ela relevante deve ser
utilizado o identificador da regra do negcio que influenciar no caso de uso em
questo. Exemplos disso podem ser encontrados nos casos de uso do Sistema de
Controle Acadmico, um estudo de caso de modelagem que desenvolvemos
neste livro (ver Seo 4.7.3).
A Tabela 4-2 fornece um formulrio que pode ser utilizado para construir o
modelo de regras do negcio. Este formulrio apresenta o nome da regra de ne
gcio, o seu identificador, a descrio da regra, a fonte de informao que per
mitiu definir a regra (normalmente um especialista do domnio) e um histrico
de evoluo da regra (por exemplo, data de identificao, data de ltima atuali
zao etc.).

Tabela 4-2: Possvel formato para documentao de uma regra de negcio

Nome Quantidade de inscries possveis (RNOl)


Descrio Um aluno no pode se inscrever em mais de seis disciplinas por
semestre letivo.
Fonte Coordenador da escola de informtica
r .........
I^FIistrico Data de identificao; 12/7/2002

Para finalizar a discusso sobre regras do negcio importante notar que h


outras formas de especificao de uma regra de negcio, alm da forma simples
mente descritiva. Por exemplo, o diagrama de atividades pode ser utilizado para
representar graficamente uma regra do negcio (ver Captulo 10). A OCL (ver
Seo 3.4) outra forma de especificar regras.

4.5.2 Requisitos de desempenho


o MCU tambm no considera requisitos de desempenho. Um requisito de desem
penho define caractersticas relacionadas operao do sistema. Exemplos: n
mero esperado de transaes por unidade de tempo, tempo mximo esperado
para uma operao, volume de dados que deve ser tratado etc.
Alistair Cockburn recomenda em seu livro (Cockburn, 2004) utilizar uma
tabela para ilustrar os requisitos de desempenho e suas associaes com os ca
sos de uso do sistema. A Tabela 4-3 exibe uma adaptao de um exemplo encon-
MODELAGEM DE CASOS DE USO 87

trado neste livro. Nesse exemplo, so apresentados os identificadores de casos


de uso na primeira coluna e requisitos de desempenho nas demais colunas.

Tabela 4-3: Tabela conectando casos de uso a requisitos de desempenho

Identificador Freqncia Tempo mximo


do caso de uso da utilizao esperado
_CSU01 5/ms Interativo
CSU02 15/dia 1 segundo
CSU03 60/dia Interativo
CSU04 180/dia _____________ _ 3 segundos
CSU05 600/ms 10 segundos
CSU07 500/dia durante 10 dias seguidos 10 segundos

4.5.3 Requisitos de interface grfica


A especificao dos requisitos de um sistema pode tambm conter uma seo
que descreva os requisitos de interface do sistema. Por exemplo, o cliente pode
ter definido restries especficas com respeito interface do sistema: cor, esti
lo, interatividade etc. Os requisitos de interface podem estar relacionados a um
ou mais casos de uso do sistema. Esse relacionamento pode ser feito de uma for
ma semelhante da Tabela 4-3.

4.6 0 MCU em um processo de desenvolvimento iterativo


Casos de uso formam uma base natural pela qual possvel planejar e realizar as
iteraes do desenvolvimento. Para isso. os casos de uso devem ser divididos
em grupos. Cada grupo alocado a uma iterao. ' Ento, o desenvolvimento do
sistema segue a alocao realizada: em cada iterao, o grupo de casos de uso
correspondente detalhado e desenvohido. O processo continua at que todos
os grupos de casos de uso tenham sido desenvolvidos e o sistema esteja comple
tamente construdo.
Conforme mencionado h pouco nesta seo, um fator importante para o
sucesso do desenvolvimento do sistema considerar os casos de uso mais im
portantes primeiramente. Murray Cantor (Cantor, 1998) prope uma classifi
cao dos casos de uso identificados para um sistema em funo de dois par-

Note que a interface propriamente dita no deve ser especfica no documento de requisitos, mas sim
restries e demandas do cliente em relao a essa interface.
^Pode ser que um nico caso de uso, em \irtude de sua complexidade, precise ser desenvolvido em mais
de uma iterao. Nesse caso, as sees do caso de uso podem servir de unidade de alocao.
88 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

metros; risco de desenvolvimento e prioridades estabelecidas pelo usurio. Dessa


forma, cada caso de uso se encaixa em uma das categorias a seguir:

1. Risco alto e prioridade alta: casos de uso nesta categoria so os mais cr


ticos. Devem ser considerados o quanto antes.
2. Risco alto e prioridade baixa: embora os casos de uso nesta categoria te
nham risco alto, necessrio, antes de comear a consider-los, negociar
com o cliente em relao a sua verdadeira necessidade.
3. Risco baixo e prioridade alta: embora os casos de uso tenham prioridade
alta, necessrio ter em mente que os casos de uso de mais alto risco de
vem ser considerados primeiro.
4. Risco baixo e prioridade baixa: em situaes em que o desenvolvimento
do sistema est atrasado, estes casos de uso so os primeiros a serem
cortados.

Em a atribuio de importncia segundo a categorizao de Cantor, um


caso de uso no to importante no ser contemplado nas iteraes iniciais. Se o
requisito correspondente a esse caso de uso for modificado ou no mais precisar
ser considerado, os analistas no tero desperdiado tempo com ele.
Note tambm que a descrio expandida de um determinado caso de uso
normalmente feita somente na iterao durante a qual este deve ser implemen
tado. Essa abordagem evita que se perca tempo inicialmente no seu detalha
mento. Alm disso, essa estratgia mais adaptvel aos requisitos volteis. Isso
porque, se todos os casos de uso forem detalhados inicialmente, e se um ou mais
requisitos so modificados durante o desenvolvimento, toda a modelagem cor
respondente a esses casos de uso sofrer modificaes. Por outro lado, se a des
crio detalhada deixada para a iterao qual o caso de uso foi alocado, uma
eventual mudana dos requisitos associados a esse caso de uso no afetar to
profundamente o desenvolvimento.

A construo do MCU deve se adequar ao processo de desenvolvimento sendo uti


lizado. Os casos de uso mais arriscados devem ser considerados primeiramente.

4.6.1 0 MCU nas atividades de anlise e projeto


o modelo de casos de uso tipicamente um artefato da fase de anlise (ver Seo
2.1.2) do desenvolvimento de um sistema. Por outro lado, neste captulo, consi
deramos um tipo especial de modelagem de casos de uso, a modelagem de casos de
uso de sistema (MCUS). Nessa modelagem o objeto sendo modelado um sistema
de software, que tem o objetivo de automatizar um ou mais processo de negcio
de uma organizao. No entanto, casos de uso tambm podem ser utilizados para
MODELAGEM DE CASOS DE uso 89

modelar um objeto em um escopo mais amplo, a saber, a organizao como um


todo. Essa atividade conhecida como modelagem de casos de uso de negcio.
A MCUN uma extenso do conceito de casos de uso para descrever os pro
cessos do negcio de uma organizao. Essa athdade realizada na fase de an
lise do domnio (tambm conhecida como modelagem do negcio ou modelagem
dos processos do negcio; ver Seo 2.1.2). A MCUN interpreta o sistema como
sendo a prpria organizao empresarial; as funcionalidades so os processos
empresariais. Um modelo de casos de uso de negcio serve para estabelecer o
escopo do sistema desejado, ou seja, que processos do negcio devem ser auto
matizados, que processos no o so, e que partes devem ser atacadas com mu
danas no funcionamento da organizao. A modelagem de casos de uso de ne
gcio no escopo deste livro, onde tratamos apenas da MCUS. De qualquer
modo, um modelo de casos de uso de sistema deve dar suporte a um ou mais
modelos de casos de uso de negcio.
Alguns desenvolvedores escrevem as descries iniciais de casos de uso
mencionando detalhes de interface grfica com o usurio (considerando atores
humanos). A justificativa que a narrativa dos casos de uso segundo essa abor
dagem fornece uma idia mais concreta de como se apresentar uma determina
da funcionalidade do sistema. Contudo, as desvantagens dessa abordagem se
sobrepem s vantagens. Considere a situao de uma parte da interface grfica
ser modificada, por alguma razo. Nessa situao, a desvantagem de utilizao
de casos de uso reais (ver Seo 4.1.1.3' se toma ntida, pois o fato de a interface
ser modificada possivelmente resultar na modificao da narrativa do caso de
uso. Alm disso, lembre-se do objetivo principal do modelo de casos de uso, a
saber, modelar os requisitos funcionais do sistema. Portanto, casos de uso de
vem ser independentes do desenho da interface pelo fato de que os requisitos do
sistema no devem estar associados a detalhes de interface. Uma melhor abor
dagem utilizar inicialmente casos de uso essenciais (ver Seo 4.1.1.3) para
no acoplar os detalhes da interface da aplicao na especificao narrativa das
interaes de um caso de uso. Nessa especificao, a ateno do modelador deve
recair sobre a essncia das interaes entre atores e o sistema, em vez de sobre
como cada interao realizada fisicamente. Especificaes de casos de uso fei
tas dessa forma tornam-se mais imunes a futuras mudanas na interface com o
usurio, alm de permitir que o analista de sistemas se concentre no que real-
mente importante em uma narrativa de caso de uso; as interaes entre ator(es)
e sistema. Por exemplo, considere o termo envia uma requisio em contra
posio com o termo duplo clique sobre o boto de envio de requisies. Em
resumo, casos de uso que mencionam detalhes de interface grfica so indesej
veis durante a anlise. O mais adequado utilizar casos de uso essenciais e, pos
teriormente, na etapa de projeto, transform-los em casos de uso reais adicio
nando mais detalhes.
90 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Na fase de anlise, descries de casos de uso devem capturar os requisitos fun


cionais do sistema e ignorar aspectos de projeto, como a interface grfica com o
usurio.

Descrevemos agora um procedimento que pode ser utilizado na construo


do MCU em um processo de desenvolvimento iterativo. (Para descrio das fa
ses aqui mencionadas, ver Seo 2.3.2.1.)
1 Identifique os atores e casos de uso na fase de concepo. Alguns atores e
casos de uso s sero identificados posteriormente, mas a grande maioria
deve ser descoberta nesta fase.
2. Na fase de elaborao:
a. Desenhe o(s) diagrama(s) de casos de uso.
b. Escreva os casos de uso em um formato de alto nvel e essencial.
c. Ordene a lista de casos de uso de acordo com prioridade e risco. Cada
partio corresponde a um grupo de casos de uso que ser imple
mentado em um dos ciclos de desenvolvimento do sistema.
3. Associe cada grupo de casos de uso a uma iterao da fase de construo.
Os grupos mais prioritrios e arriscados devem ser alocados s iteraes
iniciais.
4. Na i-sima iterao da fase de construo:
a. Detalhe os casos de uso do grupo associado a esta iterao (se neces
srio, utilize o nvel de abstrao real).
b. Implemente estes casos de uso.

4.6.2 0 MCU e outras atividades do desenvolvimento


o modelo de casos de uso direciona a realizao de vrias outras atividades do
desenvolvimento.

4.6.2.1 Planejamento e gerenciamento do projeto


O modelo de casos de uso uma ferramenta fundamental para o gerente de um
projeto no planejamento e controle de um processo de desenvolvimento itera
tivo. Ao final de cada iterao, o gerente pode avaliar a produtividade na reali
zao das tarefas. Essa avaliao serve como massa de dados para que esse pro
fissional realize a alocao das tarefas e dos recursos para as prximas iteraes.

4.6.2.2 Testes do sistema


Em um processo de desenvolvimento iterativo, no h uma fase de testes pro
priamente dita. Ao contrrio, os testes do software so realizados continuamen-
MODELAGEM DE CASOS DE USO 91

te durante todo o desenvolvimento. Os profissionais responsveis pelos testes


utilizam o modelo de casos de uso para planejar as atividades de teste. Os casos
de uso e seus cenrios oferecem casos de teste. Quando o sistema est sendo tes
tado, os cenrios sobre o sistema podem ser verificados para identificar a exis
tncia de erros.

4.6.2.3 Documentao do usurio


Os manuais e guias do usurio tambm podem ser construdos com base no mo
delo de casos de uso. Na verdade, se o modelo de casos de uso foi bem construdo,
deve haver uma correspondncia clara entre cada caso de uso do sistema e uma
seo do manual do usurio. Isso porque esse modelo est baseado na noo de
que o sistema construdo para se adequar perspectiva de seus usurios.

4.7 Estudo de caso


A partir desta seo, um estudo de caso comea a ser desenvolvido. Esse estudo
tem o objetivo de consolidar os principais conceitos tericos descritos e ofere
cer uma viso prtica sobre como os modelos apresentados neste livro so de
senvolvidos. Batizamos o sistema de nosso estudo de caso com o nome de Siste
ma de Controle Acadmico (SCA).
O desenvolvimento de nosso estudo de caso feito de forma incrementai: em
cada captulo deste livro em que houver uma seo denominada Estudo de caso,
uma parte do desenvohmento apresentada. importante notar que, para manter
a descrio em um nvel de simplicidade e clareza aceitveis para um livro didtico,
muitos detalhes do desenvoKimento so deliberadamente ignorados.

4.7.1 Descrio da situao


o estudo de caso sobre uma faculdade que precisa de uma aplicao para con
trolar alguns processos acadmicos, como inscries em disciplinas, lanamen
to de notas, alocao de recursos para turmas etc. Aps o levantamento de re
quisitos inicial desse sistema, os analistas chegaram seguinte lista de requisi
tos funcionais:

RI. O Sistema deve permitir que alunos visualizem as notas obtidas por se
mestre letivo.
R2. O sistema deve permitir o lanamento das notas das disciplinas leciona
das em um semestre letivo e controlar os prazos e atrasos neste lana
mento.
R3. O sistema deve manter informaes cadastrais sobre disciplinas no curr
culo escolar.
92 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

R4. O sistema deve permitir a abertura de turmas para uma disciplina, assim
como a definio de salas e laboratrios a serem utilizadas e dos horrios
e dias da semana em que haver aulas de tal turma.
R5. O sistema deve permitir que os alunos realizem a inscrio em discipli
nas de um semestre letivo.
R6. O sistema deve permitir o controle do andamento das inscries em dis
ciplinas feitas por alunos.
R7. O sistema deve se comunicar com o Sistema de Recursos Humanos para
obter dados cadastrais sobre os professores.
R8. O sistema deve se comunicar com o Sistema de Faturamento para infor
mar as inscries realizadas pelos alunos.
R9. O sistema deve manter informaes cadastrais sobre os alunos e sobre
seus histricos escolares.

4.7.2 Regras do negcio


Algumas regras iniciais do negcio tambm foram identificadas para o sistema.
Essas regras so descritas a seguir, utilizando o formato proposto na Seo 4.5.1
(por simplificao, a fonte e o histrico das regras so omitidos).

Quantidade mxima de inscries por semestre letivo (RNOl)


1 ' ..............
Descrio Em um semestre letivo, iim aluno no pode se inscrever em uma
quantidade de disciplinas cuja soma de crditos ultrapasse 20.

Quantidade de alunos possveis (RN02)


Descrio Uma oferta de disciplina em uma turma no pode ter mais de 40
alunos inscritos.

Pr-requisitos para uma disciplina (RN03)


Descrio Um aluno no pode se inscrever em uma disciplina para a qual no
I possua os pr-requisitos necessrios.

Habilitao para lecionar disciplina (RN04)


Descrio Um professor s pode lecionar disciplinas para as quais esteja
habilitado.

iCancelamento de matrcula (RN05)


Descrio Um aluno deve ter a matrcula cancelada se for reprovado mais de
duas vezes na mesma disciplina.
MODELAGEM DE CASOS DE USO 93

Poltica de Avaliao de Alunos (RN06)


I^Descrio A nota de um aluno em uma disciplina (um valor de 0 a 10) obtida
pela mdia de duas avaliaes durante o semestre, A l e A2, ou pela
frequncia nas aulas.
Se o aluno obtiver nota maior ou igual a 7.0 (sete), ser aprovado.
Se o aluno obtiver nota maior ou igual 5.0 (cinco) e menor que 7.0
(sete), dever fazer a avaliao final.
Se o aluno obtiver nota menor que 5.0 (cinco) ser reprovado.
Se o aluno tiver uma freqncia menor que 75% em uma turma,
ser automaticamente reprovado.

4.7.3 Documentao do MCU


Nesse sistema de controle acadmico, o analista identificou e documentou os
seguintes atores:

Aluno: indivduo que est matriculado na faculdade, que tem interesse em


se inscrever em disciplinas do curso.
Professor: indivduo que leciona disciplinas na faculdade.
Coordenador: pessoa interessada em agendar as alocaes de turmas e
professores, e visualizar o andamento de inscries dos alunos.
Departamento de Registro Escolar (DRE): departamento da faculdade inte
ressado em manter informaes sobre os alunos matriculados e sobre seu
histrico escolar.
Sistema de Recursos Humanos: este sistema legado responsvel por for
necer informaes cadastrais sobre os professores.
Sistema de Eaturamento: este sistema legado tem interesse em obter infor
maes sobre inscries dos alunos para realizar o controle de pagamento
de mensalidades.

O analista tambm identificou os casos de uso a seguir, e os organizou em


trs pacotes: Gerenciamento de Inscries. Geraiciamento de Recursos Acadmi
cos e Acompanhamento de Semestre Leth o. Os casos de uso que apresentam co
mentrios (entre parnteses e em itlico) so aqueles para os quais no fornece
mos descries detalhadas.

Gerenciamento de Inscries
o Realizar Inscrio
o Cancelar Inscrio (Aluno cancela inscries em uma ou mais ofertas de
disciplinas em que havia soliticado inscrio.)
94 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E E LS E V IE R

o Visualizar Grade Curricular {Aluno visualiza a grade curricular atual;


ver Seo 5.7.2 para a definio deste termo.)
o Visualizar Andamento de Inscries
o Abrir Turma (Coordenador abre uma turma.)
o Fechar Turma (Coordenador fecha uma turma.)
o Atender Listas de Espera

Gerenciamento de Recursos Acadmicos


o Manter Grade Curricular (Coordenador define informaes sobre uma
grade curricular; ver definio deste termo no glossrio.)
o Manter Disciplina
o Manter Aluno (DRE mantm informaes sobre aluno.)
o Fornecer Grade de Disponibilidade
o Fornecer Habilitaes (Professor infonna as disciplinas da grade curricu
lar que est apto a lecionar).
o Atualizar Informaes sobre Professor

Acompanhamento de Semestre Letivo


o Lanar Avaliaes e Freqncias
o Obter Dirio de Classe (Professor obtm o dirio de classe para determi
nado ms do serrrestr e letivo corrente. Ver Seo 5.7.2 para a definio do
termo dirio de classe.)
o Visualizar Avaliaes e Freqncias
o Solicitar Histrico Escolar (Aluno solicita a produo de seu histrico es
colar.)

A seguir so apresentados o diagrama de casos de uso e as descries de al


guns dos casos de uso no formato essencial e expandido. A descrio dos demais
casos de uso fica como exerccio para o leitor.
MODELAGEM DE CASOS DE uso 95
96 princpios DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Realizar Inscrio (C SU O l)

Sumrio: Aluno usa o sistema para realizar inscrio em disciplinas.


Ator Primrio: Aluno
Atores Secundrios: Sistema de Faturamento

Precondies: O Aluno est identificado pelo sistema.

Fluxo Principal
1. O Aluno solicita a realizao de inscrio.
2. O sistema apresenta as disciplinas para as quais o aluno tem pr-requisitos
(conforme a RN03), excetuando-se as que este j tenha cursado.
3. O Aluno define a lista de disciplinas que deseja cursar no prximo semestre
letivo e as relaciona para inscrio.
4. Para cada disciplina selecionada, o sistema designa o aluno para uma turma que
apresente uma oferta para tal disciplina.
5. O sistema informa as turmas para as quais o Aluno foi designado. Para cada
turma, o sistema informa o professor, os horrios e os respectivos locais das aulas
de cada oferta de disciplina.
6. O Aluno confere as informaes fornecidas. Aqui, possvel que o caso de uso
retorne ao passo 3, conforme o Aluno queira revisar (inserir ou remover itens) a
lista de disciplinas a cursar.
7. O sistema registra a inscrio do Aluno, envia os dados sobre a mesma para o
Sistema de Faturamento e o caso de uso termina.

Fluxo Alternativo (4): Incluso em lista de espera


a. Se no h oferta disponvel para alguma disciplina selecionada pelo aluno
(conforme a RN02), o sistema reporta o fato e fornece a possibilidade de inserir o
Aluno em uma lista de espera.
b. Se 0 Aluno aceitar, o sistema o insere na lista de espera e apresenta a posio na
qual o aluno foi inserido na lista. O caso de uso retorna ao passo 4.
c. Se o Aluno no aceitar, o caso de uso prossegue a partir do passo 4.

Fluxo de Exceo (4): Violao de RNOl


a. Se o Aluno atingiu a quantidade mxima de inscries possveis em um semestre
letivo (conforme a RNOl), o sistema informa ao aluno a quantidade de disciplinas
que ele pode selecionar, e o caso de uso retorna ao passo 2.

Ps-condies: O aluno foi inscrito em uma das turmas de cada uma das
disciplinas desejadas, ou foi adicionado a uma ou mais listas de espera.

Regras de Negcio: RNOl, RN02, RN03


MODELAGEM DE CASOS DE USO 97

Visualizar Avaliaes e Frequncias (C SU 02)

Sumrio: Aluno visualiza avaliao que recebeu (notas e freqncia) nas turmas de
um semestre letivo.

Ator Primrio: Aluno


Precondies: O Aluno est identificado pelo sistema.

Fluxo Principal
1. O Aluno solicita a visualizao das avaliaes para as ofertas de disciplina em
que participou.
2. O sistema exibe os semestres letivos nos quais o Aluno se inscreveu em pelo
menos uma oferta de disciplina.
3. O Aluno seleciona os semestres letivos cujas avaliaes deseja visualizar.
4. O sistema exibe uma lista de avaliaes agrupadas por semestres letivos
selecionados e por turma.
5. O aluno visualiza as avaliaes e o caso de uso termina.

Fluxo de Exceo (2): Aluno sem inscrio


a. No h semestre letivo no qual o Aluno tenha participado de alguma oferta de
disciplina: o sistema reporta o fato e o caso de uso termina.

Ps-condies: O Aluno obteve as avaliaes que desejava visualizar.


98 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Fornecer Grade de Disponibilidades (C SU 03)

Sumrio: Professor fornece a sua grade de disponibilidade (disciplinas que deseja


lecionar, juntamente com dias e horrios em que est disponvel) para o prximo
semestre letivo.

Ator Primrio: Professor


Precondies: O Professor est identificado pelo sistema.

Fluxo Principal
1. O Professor indica o desejo de fornecer sua grade de disponibilidades para o
prximo semestre letivo.
2. O sistema apresenta a lista de disciplinas disponveis (conforme RN04).
3. O Professor preenche a grade com as disciplinas que deseja lecionar no prximo
semestre letivo.
4. O sistema apresenta a lista dias da semana e de horrios do semestre letivo
seguinte.
5. O Professor preenche a grade com sua disponibilidade de dias da semana e
horrios para o prximo semestre letivo.
6. O Professor solicita ao sistema que registre sua grade.
7. O sistema registra a grade fornecida pelo professor e o caso de uso termina.

Fluxo Alternativo (3): Modificao na grade atual


a. O Professor solicita que o sistema apresente a mesma grade do semestre atual.
b. O sistema apresenta a configurao de grade requisitada.
c. O professor realiza as modificaes que deseja na grade e solicita o seu registro.
d. O sistema registra a grade alterada e o caso de uso termina.

Fluxo de Exceo (3): Disciplinas no fornecidas


a. Se o Professor no forneceu disciplina alguma: o sistema reporta o fato e o caso
de uso continua a partir do passo 2.

Fluxo de Exceo (3): Dias e horrios no fornecidos


a. Se o Professor no fornecer dia e horrio algum: o sistema reporta o fato e o caso
de uso continua a partir do passo 4.

Ps-condies: o sistema registrou a disponibilidade do Professor para o prximo


semestre letivo.

Regras de Negcio: RN04


MODELAGEM DE CASOS DE USO 99

Lanar Avaliaes e Frequncias (C SU 04)

Sumrio: Professor realiza o lanamento de avaliaes e frequncias para alunos


das ofertas de disciplinas lecionadas por ele no semestre corrente.

Ator Primrio: Professor

Precondies: O Professor est identificado pelo sistema.

Fluxo Principal
1. O Professor solicita o lanamento de notas.
2. O sistema exibe a lista de turmas e disciplinas correspondentes do semestre
corrente nas quais o Professor lecionou.
3. O Professor seleciona a turma e, dentro desta, a oferta de disciplina para a qual
deseja realizar o lanamento de notas.
4. O sistema exibe a lista de alunos da oferta de disciplina selecionada e requisita a
primeira nota (A l), a segunda nota (A2) e a quantidade de faltas para cada aluno.
5. O Professor fornece as notas de Al e de A2 e a quantidade de faltas (frequncia)
para cada aluno.
6. O sistema exibe o resultado da avaliao de cada aluno, conforme regra de
negcio RN06, para verificao pelo Professor.
7. O Professor confere os dados e confirma o lanamento.
8. O sistema registra as avaliaes e frequncias e o caso de uso termina.

Fluxo Alternativo (7): Erro no lanamento


a. O professor detecta que lanou uma avaliao ou frequncia errada para algum
aluno.
b. O professor corrige a informao que foi lanada erroneamente do aluno.
c. O sistema aceita a correo e o caso de uso continua a partir do passo 7.

Fluxos de Exceo (4): Avaliao em branco ou errada


a. Se o Professor no fornece alguma nota. ou freqncia, ou fornece dados
invlidos; o sistema reporta o fato e o caso de uso retorna ao passo 4.

Ps-condies: as notas de uma ou mais disciplinas ofertadas e lecionadas pelo


professor foram lanadas no sistema.

Regras de Negcio: RN05, RN06


100 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEMER

M anter D isciplina (C SU 05)

S u m rio :DRE realiza o cadastro (incluso, remoo, alterao e consulta) dos


dados sobre disciplinas.
A to r P rim rio : DRE

F lu x o P rin cip a l
1. DRE requisita a manuteno de disciplinas.
2. O sistema apresenta as operaes que podem ser realizadas: a incluso de uma
nova disciplina, a alterao dos dados de uma disciplina, a excluso de uma
disciplina e a consulta de disciplinas.
3. O DRE indica a opo a realizar ou opta por finalizar o caso de uso.
4. O DRE seleciona a operao desejada: Incluso, Excluso, Alterao ou Consulta.
5. Se o DRE deseja continuar com a manuteno, o caso de uso retorna ao passo 2;
caso contrrio, o caso de uso termina.
F lu x o A lte rn a tiv o ( 4 ) ; In clu s o
a. O DRE requisita a incluso de uma disciplina.
b. O sistema apresenta um formulrio em branco para que os detalhes da
disciplina (cdigo, nome e quantidade de crditos) sejam includos.
c. O DRE fornece os detalhes da nova disciplina.
d. O sistema apresenta uma lista de disciplinas para que o DRE selecione as que
so pr-requisitos para a disciplina a ser criada.
e. O DRE define zero ou mais disciplinas como pr-requisitos.
f. O sistema verifica a validade dos dados. Se os dados forem vlidos, inclui a nova
disciplina; caso contrrio, o sistema reporta o fato, solicita novos dados e repete a
verificao.

F lu x o A lte rn a tiv o ( 4 ) : R em o o
a. O DRE seleciona uma disciplina e requisita o sistema que a remova.
b. Se a disciplina pode ser removida, o sistema realiza a remoo; caso contrrio, o
sistema reporta o fato.
F lu x o A lte rn a tiv o ( 4 ) : A lte ra o
a. O DRE altera um ou mais dos detalhes sobre uma disciplina e requisita a sua
atualizao.
b. O sistema verifica a validade dos dados e, se eles forem vlidos, altera os dados
na lista de disciplinas da faculdade.
F lu x o A lte rn a tiv o ( 4 ) : C o n su lta
a. O DRE solicita a realizao de uma consulta sobre a lista de disciplinas.
b. O sistema apresenta uma lista com os cdigos de todas as disciplinas,
permitindo que o usurio selecione a disciplina desejada.
c. O DRE seleciona uma disciplina.
d. O sistema apresenta os detalhes da disciplina e seus pr-requisitos (se existirem)
no formulrio de disciplinas.
P s -co n d i e s: uma disciplina foi inserida ou removida, ou seus detalhes foram
alterados.
MODELAGEM DE CASOS DE uso 101

V isualizar Andamento de Inscries (C SU 06)

Sumrio: O Coordenador usa o sistema para visualizar o andamento de inscries


sendo realizadas pelos alunos em disciplinas ofertadas para o prximo semestre letivo.

Ator Primrio: Coordenador


Precondies: O Coordenador est identificado pelo sistema.

Fluxo Principal
1. O Coordenador solicita a visualizao do andamento de inscries realizadas
pelos alunos.
2. O sistema exibe a lista de disciplinas para as quais existe pelo menos uma oferta
para o prximo semestre.
3. O Coordenador seleciona a disciplina para a qual deseja visualizar o andamento
de inscries.
4. O sistema exibe a lista de turmas nas quais existe oferta para a disciplina
selecionada, juntamente com as distribuies correspondentes: professor, horrios,
locais e situao (aberta ou fechada).
5. O Coordenador seleciona uma das turmas.
6. O sistema apresenta a lista de alunos inscritos na turma para a disciplina
selecionada, ordenados por data de inscrio.
7. O Coordenador visualiza as informaes.
8. Se o Coordenador deseja continuar a visualizao, o caso de uso retorna ao
passo 5; tambm possvel que o caso de uso retorne ao passo 3, de acordo com a
ao do Coordenador; caso contrrio, o caso de uso termina.

Atualizar Inform aes sobre Professor (C SU 07)

Sumrio: Administrador do sistema usa o sistema para atualizar as informaes


cadastrais sobre professores a partir do SRH.
Ator Primrio: Administrador
Ator Secundrio: Sistema de Recursos Humanos (SRH)
Precondies: O Administrador est identificado pelo sistema.

Fluxo Principal
1. O Administrador solicita ao sistema que obtenha os dados atualizados sobre
professores.
2. O sistema se comunica com o SRH e obtm os dados a partir deste.
3. O sistema apresenta os dados obtidos e solicita a confirmao do Administrador
para realizar a atualizao.
4. O Administrador confirma a atualizao.
5. O sistema atualiza os dados cadastrais dos professores e o caso de uso termina.
Fluxo de Exceo (2): Houve uma falha na obteno de dados
a. O sistema no consegue obter os dados a partir do SRH.
b. O sistema reporta o fato e o caso de uso termina.
I Fluxo Alternativo (4): Desistncia de atualizao
j O Administrador declina da atualizao e o caso de uso termina.
102 princpios de a n a lis e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Atender Listas de Espera (C SU 08)

Sumrio: Coordenador atende s demandas representadas pelas listas de espera


por vagas para uma disciplina.

Ator Primrio: Coordenador

Atores Secundrios: Sistema de Faturamento

Precondies: O Coordenador est identificado pelo sistema.

Fluxo Principal
1. O sistema apresenta as listas de espera existentes para as disciplinas.
2. O Coordenador seleciona uma das listas de espera.
3. O sistema apresenta os detalhes da lista de espera selecionada (data de criao e
quantidade de alunos).
4. O Coordenador fornece os dias e respectivos horrios da oferta de disciplina que
deseja criar.
5. O sistema apresenta as salas e os professores disponveis nos dias e horrios
fornecidos pelo Coordenador.
6. O Coordenador seleciona um professor e uma ou mais salas.
7. O Coordenador fornece a quantidade de alunos a serem alocados na nova oferta
de disciplina (conforme RN02).
8. A partir de uma lista fornecida pelo sistema, o Coordenador seleciona a turma
na qual deseja alocar a oferta de disciplina.
9. O sistema cria a oferta de disciplina e transfere a quantidade de alunos fornecida
no passo 7 da lista de espera para a oferta recm-criada, de acordo com a ordem
dos alunos nessa lista.
10. Se o Coordenador deseja continuar o atendimento das listas de espera, o caso
de uso retorna ao passo 1; caso contrrio, o sistema envia os dados de inscries de
alunos para o sistema de faturamento e o caso de uso termina.

Fluxo de Exceo(7): Violao de RN02


a. Se a quantidade de alunos que o Coordenador fornecer for invlida (violar a
regra do negcio RN02), o sistema reporta o fato e solicita um novo valor.
b. O Coordenador corrige o valor e o caso de uso prossegue a partir do passo 8.

Regras de Negcio: RN02


MODELAGEM DE CASOS DE uso 103

exerccios

4-1: Descreva a posio do diagramas de casos de uso no processo de desenvolvimento iterati


vo. Quando eles so utilizados? Para que so utilizados?

4-2: Construa um modelo de casos de uso para a seguinte situao fictcia: Estamos criando um
servio de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volu
mes so considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais vo
lumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar
volumes de valor.

4-3: A seguinte narrativa do caso de uso Real i zar Saque. Identifique os erros existentes nesta
narrativa. Construa uma nova verso deste caso de uso que no contenha os erros encontrados.

A operao de um caixa eletrnico tem incio a partir de uma sesso em que o cliente se
leciona a opo de realizar saque. 0 cliente, ento, escolhe uma quantia a ser retirada, a partir
de um conjunto de opes de quantia disponveis.
Osistema verifica se a conta correspondente tem saldo suficiente para satisfazer a requi
sio. Seno, uma mensagem adequada reportada, o que acarreta na execuo da exten
so. Se h dinheiro suficiente, os nmeros da conta e da agncia do cliente so enviados ao
banco, que aprova ou desaprova a transao. Se a transao aprovada, a mquina libera a
quantia correspondente e emite um recibo. Se a transao reprovada, a extenso Informar
Falha executada.
Obanco notificado, independentemente de uma transao aprovada ter sido completada
ou no pela mquina. Se a transao concluda, o banco realiza o dbito na conta do cliente
{BjorK 1998).

4-4: Qual a notao da UML para um caso de uso? Qual a notao da UML para um ator? Qual
a notao utilizada na UML para o relacionamento de generalizao?

4-5: Defina o que significa um ator. 0 que significa um ator estar associado a um caso de uso por
um relacionamento de comunicao?

4-6: Qual o objetivo dos diagramas de casos de uso?

4-7: Defina o conceito de requisito. Que tipos de requisitos existem? Explique o que realizado
na fase de levantamento de requisitos de um sistema de informaes.

4-8: Que tipo de relacionamento possvel entre um ator e um caso de uso? Que tipo de relacio
namento pode haver entre casos de uso? Que tipo de relacionamento pode haver entre atores?

4-9: Descreva a(s) diferena(s) entre os relacionamentos de incluso, de extenso e de herana.


104 princpios de a n a l i s e e projeto de s i s t e m a s com UML, 2/E ELSEVIER

4-10: Considere um sistema de controle de uma biblioteca. Fornea a descrio narrativa para
os seguintes casos de uso: Reservar Li vro (situao em que um usurio faz a reserva de um
livro), Obter Emprstimo de Livro (situao em que um usurio pega um exemplar de livro
emprestado), Cancel ar Reserva (situao em que um usurio cancela uma reserva) e Devol -
ver Cpia (situao em que um usurio devolve uma cpia anteriormente adquirida).

4-11: Durante a execuo de um caso de uso, podem ocorrer excees. Considere o caso de
uso Real i zar Pedi do, no qual pode ser que o cliente solicite um produto que est fora de esto
que. Como voc modelaria tal situao? Desenhe um diagrama de casos de uso.

4-12: Construa o modelo de casos de uso para a seguinte situao. Tente identificartambm re
gras de negcio que se apliquem situao, de acordo com o texto fornecido.

Uma rede de televiso est requisitando um sistema para gerenciar informaes sobre uma
de suas produes televisivas (por exemplo, uma minissrie ou uma novela).
Uma produo televisiva tem uma verba e composta de cenas. Cenas so escolhidas em
uma determinada seqncia. Cada cena, que tem uma durao em minutos, gravada em uma
ou mais fitas. Cada fita possui um nmero de srie e uma capacidade (medida em minutos que
podem ser gravados na mesma). Deseja-se saber em que fita(s) se encontra uma determinada
cena. Cada cena pode ter sido gravada muitas vezes (futuramente, na edio da obra, oprodutor
selecionar uma dessas tomadas de cena para compor a verso final da produo televisiva).
Deve-se manter o registro de todas as cenas filmadas, de quais atores e dubis participaram de
cada cena. Deseja-se saber, tambm, que dubl substituiu que ator, em cada cena.
Para uma produo televisiva como um todo, deseja-se manter a informao de quais ou
tros funcionrios, os chamados funcionrios de apoio, participaram das filmagens. Esses fun
cionrios podem ser de diversos tipos (cmeras, iluminadores, contra-regras etc). Alm dis
so, possvel haver funcionrios de apoio que exeram mais de uma funo na mesma produ
o televisiva.
Atores e dubis ganham por produo televisiva em que participam. Os demais funcion
rios tm um salrio fixo por obra. necessrio tambm armazenar essas informaes para ter
uma idia do consumo de recursos em relao verba.
Aps 0 trmino de uma obra, o sistema deve produzir um relatrio com o valor a ser pago
para cada funcionrio. 0 sistema tambm deve produzir um relatrio de informaes sobre as
cenas de uma obra televisiva, e sobre que atores, dubis e demais funcionrios participaram
dessa obra televisiva.

4-13:0 seguinte documento de requisitos foi adaptado do livro (Wirfs-Brockea/., 1991). Leia o
texto com ateno. A seguir, elabore um modelo de casos de uso inicial para o sistema.

O DWU Editor um editor qrtico interativo, om ele, usurios podem criar e editar dese
nhos compostos de linhas, retngulos, elipses e texto.
H dois modos de operao do editor. Apenas um modo de operao est ativo em um
dado momento.
MODELAGEM DE CASOS DE uso 105

Os dois modos de operao so: modo de seleo e modo de criao. Quando o modo de
seleo est ativado, os elementos grficos podem ser selecionados com o cursor do mouse.
Um ou mais elementos grficos podem ser selecionados e manipulados; se vrios elementos
grficos forem selecionados, eles podem ser manipulados como se fossem um nico elemento
grfico. Elementos que tenham sido selecionados desse modo so definidos como a seleo
atual". A seleo atual indicada visualmente atravs da exibio dospontos de controle para o
elemento. Um clique seguido de umarrasto de mouse sobre umponto de controle modifica o ele
mento ao qual o ponto de controle est associado.
Quando o modo de criao est ativado, a seleo atual est vazia. 0 usurio pode selecio
nar um objeto grfico a partir de um conjunto de objetos grficos predefinidos.
A criao de um elemento de texto: a posio do primeiro caractere do texto determinada
pela posio na qual o usurio clica oboto do mouse. 0 modo de criao desativado quando o
usurio clica o mouse fora do elemento de texto. Ospontos de controle para um elemento de tex
to soposicionados nos quatro cantos da regio em que o texto inserido. 0 arrasto desses pon
tos de controle muda a regio.
Os outros elementos que podem ser criados pelo usurio so linhas, retngulos e elipses. 0
elemento apropriado comea quando o boto do mouse pressionado e se completa quando o
boto do mouse liberado. Esses dois eventos criam o ponto de partida" e o "ponto de parada".
A "criao de linha" define uma linha do ponto de partida at o ponto de parada. Esses so
os pontos de controle. 0 arrasto de um ponto de controle modifica o ponto extremo correspon
dente.
A "criao de retngulo" define um retngulo tal que dois dos cantos do retngulo diame
tralmente opostos do retngulo correspondem ao ponto de partida e ao ponto de parada. Os
cantos do retngulo formam os pontos de controle. 0 arrasto de umponto de controle modifica o
canto correspondente.
A "criao de elipse"define uma elipse que est contida dentro de um retngulo definido
pelos dois pontos definidos acima. 0 raio maior da elipse metade do comprimento do retn
gulo, e 0 seu raio menor metade da altura do retngulo. Os pontos de controle so os cantos
do retngulo que contm a elipse. 0 arrasto de um ponto de controle modifica o canto corres
pondente.
Ser assumido que oprograma deve fornecer uma tela grfica do diagrama sendo criado, e
que um mouse e um teclado sero utilizados como dispositivos de entrada.

4-14: Considere a seguinte declarao obtida de um gerente de uma empresa que comercializa
livros por correio durante o levantamento de requisitos para construo de um sistema de soft
ware: Aps a ordem de compra do cliente ter sido registrada, o vendedor envia uma requisio
ao depsito com detalhes da ordem de compra. Quais atores em potencial podem ser identifica
dos a partir desse texto?

4-15: Considere o exemplo de relacionamento de extenso entre casos de uso apresentado na


Seo 4.1.3.3, que descreve relacionamentos de extenso entre os casos de uso E ditar Do
cumento e os extensores Corri gi r O rtograf i a e Substi tu i r Texto. Desenhe um diagrama
106 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSE\aER

de casos de uso para essa situao. Como voc faria para estender seu diagrama de casos de
uso com um novo requisito, a saber, permitir que o editor de textos possibilite a criao de um
ndice remissivo sobre um documento sendo editado?

4-16: Em uma empresa, vrios projetos so realizados. Os 50 empregados da empresa trabalham


em pelos menos um projeto. H um sistema implantado na empresa que permite aos participantes
de um determinado projeto marcarem suas horas de trabalho. Esse sistema tambm permite que
outra pessoa, ao fim do ms, gere os relatrios com os totais de horas trabalhadas de cada partici
pante. Quantos atores voc definiria para esse sistema? E quantos papis?

4-17: 0 TurboNote-E um programa Shareware que permite aos seus usurios criar mensa
gens de lembrete que permanecem na rea de trabalho de seus computadores. (Esse programa
funciona como uma verso eletrnica daqueles bloquinhos de papel cujas folhas podem ser afi
xadas na parede.) Ao criar uma nova folhinha no TurboNote-E, o usurio pode preench-la com
texto. As folhinhas podem ser movidas pela rea de trabalho, conforme a vontade do usurio. As
folhinhas permanecem na rea de trabalho. Toda vez que o usurio inicia o seu computador, as
folhinhas esto l, na rea de trabalho. Quando no so mais necessrias, as folhinhas podem
ser removidas. Se o usurio escrever uma expresso aritmtica em uma folhinha, o resultado da
expresso exibido. Desenhe o diagrama de casos de uso para o TurboNote-f.

4-18: Suponha que um sistema de vendas deve gerar de forma automtica um conjunto de esta
tsticas para a diretoria da empresa no ltimo dia til de cada ms. Desenhe o diagrama de ca
sos de uso para essa situao. H mais de uma maneira de represent-la?

4-19: Na utilizao da Internet, normalmente um usurio utiliza um programa navegador


(browser) que, por sua vez, se comunica com um ou mais servidores Web para fornecer as
pginas nas quais o usurio est interessado. 0 que est errado no diagrama a seguir? De
senhe novos diagramas para representar corretamente a situao, considerando duas al
ternativas de escopo. Na primeira, o programa navegador o sistema. Na segunda, a Inter
net 0 sistema.

Usurio da Internet
MODELAGEM DE CASOS DE USO 107

4-20: Assinale V ou F para as seguintes assertivas;


( ) pessoas com o mesmo cargo em uma empresa podem representar papis de diversos atores.
( ) um ator pode representar pessoas de diferentes cargos.

4-21: Altere os seguintes "nomes de casos de uso" de acordo com as nomenclaturas apresen
tadas neste captulo:
a. Cliente realiza transferncia de fundos em um caixa eletrnico.
b. Clientes compram livros na livraria.
c. produzido um relatrio de vendas para o gerente.
d. Hspede se registra em um hotel.

4-22: Desenhe diagramas de casos de uso para os seguintes sistemas:


a. A biblioteca de sua universidade.
b. 0 seu aparelho celular.
c. Um sistema de validao de cartes de crdito.

4-23: Suponha que exista um caso de uso Pagar Pedi do em um sistema, que realizado pelo
ator Cl i ente. Neste caso de uso, o cliente realiza o pagamento de um pedido realizado em al
gum momento do passado. Considerando este caso de uso, voc pode pensar em algum outro
caso de uso do sistema?

4-24: Considere o modelo de casos de uso iniciai para o Sistema de Controle Acadmico (ver
Seo 4.7.3). Modifique esse modelo para contemplaras seguintes novidades:
a. 0 coordenador informa equipe de desenvolvimento que h datas inicial e final preestabeleci
das dentro de um semestre para que um professor possa lanar notas ou fornecer sua disponibi
lidade de carga horria para semestre letivo seguinte. o prprio coordenador que deve estabe
lecer essas datas.
b. Da mesma forma, h um perodo para realizao de inscries e outro para cancelamentos
das mesmas. Fora desses perodos, o sistema no deve aceitar tais operaes. 0 coordenador
tambm deve ter a possibilidade de definir esses perodos,
c. 0 coordenador declara que precisa ser informado pelo sistema (por e-mail, por exemplo)
quando este ltimo cria uma nova lista de espera para uma determinada disciplina.
5
Modelagemdeclasses deanlise
0 engenheiro de software amador est sempre procura da mgica,
de algum mtodo sensacional ou ferramenta cuja aplicao promete
tornar trivial o desenvolvimento de software. uma caracterstica do
engenheiro de software profissional saber que tal panacia no existe.
- GRADY BOOCH

modelo de casos de uso de um sistema construdo para formar a vi

O so de casos de uso do sistema (conforme mencionado na Seo

1.4.1). Esta viso fornece uma perspectiva do sistema a partir de um


ponto de vista externo. De posse da viso de casos de uso, os desenvolvedores
precisam prosseguir no desenvolvimento do sistema.
A funcionalidade externa de um sistema orientado a objetos fornecida por
meio de colaboraes entre objetos. Externamente ao sistema, os atores visuali
zam resultados de clculos, relatrios produzidos, confirmaes de requisies
realizadas etc. Internamente, os objetos do sistema colaboram uns com os ou
tros para produzir os resultados visveis de fora. Essa colaborao pode ser vista
sob o aspecto dinmico e sob o aspecto estnitural esttico.
O aspecto dinmico de uma colaborao entre objetos descreve a troca de
mensagens entre os mesmos e a sua reao a eventos que ocorrem no sistema. O
aspecto dinmico de uma colaborao representado pelo Modelo de Intera
es e estudado nos Captulos 7 e 10.
O aspecto estrutural esttico de uma colaborao permite compreender
como o sistema est estruturado internamente para que as funcionalidades ex
ternamente visveis sejam produzidas. Esse aspecto dito esttico porque no
apresenta informaes sobre como os objetos do sistema interagem no decorrer
do tempo (isso representado no aspecto dinmico da colaborao). Tambm
110 princpios de a n a l i s e e projeto de s i s t e m a s com UML, 2/E ELSEVIER

dito estrutural porque a estrutura das classes de objetos componentes do siste


ma e as relaes entre elas so representadas.
Os aspectos estticos e dinmicos de um sistema orientado a objetos no so
independentes. Na verdade, conforme descrito com mais detalhes neste captu
lo, a construo de um serve para adicionar detalhes no outro. Por exemplo,
quando, durante a construo do aspecto dinmico, o modelador detecta a ne
cessidade de uma mensagem entre dois objetos, isso implica a existncia de al
guma referncia estrutural entre os mesmos. Do mesmo modo, a definio da
estrutura do relacionamento entre dois objetos feita no aspecto estrutural in
fluencia na forma pela qual esses mesmos objetos podem trocar mensagens.
Este captulo inicia a descrio do aspecto estrutural esttico de um sistema
orientado a objetos. Esse aspecto representado pelo Modelo de Classes, da
mesma forma que o aspecto funcional representado pelo Modelo de Casos de
Uso. A ferramenta da UML utilizada para representar o aspecto estrutural estti
co o diagrama de classes. O modelo de classes composto desse diagrama e da
descrio textual associada ao mesmo. Para melhor orientar o leitor, os objeti
vos principais deste captulo so enumerados a seguir.

1. Descrever algumas tcnicas para identificao de classes de anlise.


2. Apresentar alguns dos elementos do diagrama de classes necessrios cons
truo do modelo de classes de anlise (outros elementos so descritos em
captulos posteriores). tambm objetivo deste captulo apresentar o dia
grama de objetos, tambm relacionado ao aspecto estrutural esttico.
3. Descrever como o modelo de classes pode ser documentado.
4. Descrever a insero do modelo de classes de anlise em um processo de
desenvolvimento iterativo.

5.1 Estgios do modelo de classes


importante notar que o modelo de classes utilizado durante a maior parte do
desenvolvimento iterativo de um SSOO. Mais que isso, esse modelo evolui du
rante as iteraes do desenvolvimento do sistema. medida que o sistema de
senvolvido, o modelo de classes incrementado com novos detalhes. El trs es
tgios sucessivos de abstr ao pelos quais o modelo de classes passa: anlise, espe
cificao e implementao.

1. O modelo de classes de anlise representa as classes de anlise, ou seja, as


que se tornam evidentes na medida em que focamos a ateno sobre o
que o sistema deve fazer. Este modelo construdo na fase de anlise
(ver Seo 2.1.2). Por definio, um modelo de classes de anlise no
leva em considerao restries inerentes tecnologia a ser utilizada na
MODELAGEM DE CLASSES DE ANALISE 111

soluo de um problema. Em seu conjunto, o modelo de casos de uso e o


modelo de classes de anlise so os dois principais modelos criados na
fase de anlise (ver Seo 2.1.2).
2. O modelo de classes de especificao um detalhamento do modelo de clas
ses de anlise. tambm conhecido como modelo de classes de projeto.
Quando chegamos nesse estgio, normalmente descobrimos a necessi
dade de criar outras classes, pois comeamos a focar nossa ateno sobre
como o sistema deve funcionar. Alm disso, esse detalhamento do mo
delo de classes tambm envolve a adio de detalhes s classes identifica
das na anlise, em funo da soluo de software escolhida. O modelo de
classes de projeto construdo na atividade de projeto (ver Seo 2.1.3) do
desenvolvimento de uma iterao do desenvolvimento. Para entender a
diferena entre o modelo de classes de anlise e o de projeto, vale aqui uma
analogia com a construo de uma casa. No modelo de anlise de uma
casa, pensamos em objetos como salas, quartos, banheiro, portas etc. No
modelo de especificao desta mesma casa, temos que pensar em outros
detalhes, como encanamento, parte eltrica, caixonetes para as portas, ou
seja, detalhes que no so e%identes para os ocupantes de uma casa, mas
que so necessrios para constru-la propriamente.
3. O modelo de classes de implementao um detalhamento do modelo de
especificao. Esse modelo corresponde implementao das classes em
alguma linguagem de programao, normalmente uma linguagem orien
tada a objetos (C++, Java, C= etc.). O modelo de implementao cons
trudo na atividade de implementao (ver Seo 2.1.4) de um processo
de desenvolvimento iterativo. (Note que aqui estamos considerando o
prprio cdigo-fonte do sistema como um modelo.)

Neste captulo, nosso principal objetivo estudar o modelo de classes em


seu primeiro estgio. O modelo de classes de anlise composto dos objetos
identificados na anlise do domnio e na anlise da aplicao (ver Seo 2.1.2).
Seu objetivo descrever o problema representado pelo sistema a ser desenvolvi
do; ele no considera caractersticas da soluo a ser utilizada. J os modelos de
especificao e de implementao consideram detalhes da soluo de software a
ser utilizada. No entanto, ao contrrio do modelo de implementao, o de espe
cificao descreve a soluo em um nvel alto de abstrao.
Antes de passarmos para as prximas sees, apresentamos a seguir a no
menclatura de identificadores dos elementos do modelo de classes utilizada
neste livro. Entretanto, importante notar que essa nomenclatura apenas uma
possibilidade. A equipe de desenvolvimento pode escolher qualquer estilo de
nomenclatura que desejar. O importante que, uma vez escolhida uma nomen
clatura, esta seja utilizada consistentemente.
112 prin cp io s de a n a l i s e e p ro jeto de s i s t e m a s com UML, 2/E ELSEVIER

1. Para identificadores, quaisquer espaos em branco e preposies do


nome so removidos.
2. Para nomes de classes e nomes de relacionamentos, as palavras compo
nentes do nome so escritas comeando por letra maiuscula. Exemplos:
Cliente, ItemPedido, Pedido, OrdemServi o. Reside, Realiza etc.
3. Para nomes de atributos e nomes de operaes; deve-se escrever a primeira
palavra do nome do atributo em minsculas. Escreva as palavras subsequen
tes em maiusculas. No entanto, siglas so mantidas inalteradas. Exemplos:
quantidade, precoUni trio, CPF, nome, dataNascimento, obterTotal etc.

5.2 Diagrama de classes


o diagrama de classes utilizado na construo do modelo de classes desde o n
vel de anlise at o nvel de especificao. De todos os diagramas da UML, esse
o mais rico em termos de notao. Nesta seo, so apresentados os elementos
do diagrama de classes utilizados para a construo do modelo de classes de n
vel de anlise.

5.2.1 Classes
Uma classe representada por uma caixa com, no mximo, trs comparti
mentos exibidos. No primeiro compartimento (de cima para baixo) exibido o
nome da classe. Por conveno, esse nome apresentado no singular e com as
palavras componentes comeando por maiusculas. No segundo compartimen
to, so declarados os atributos, que correspondem s informaes que um obje
to armazena. Finalmente, no terceiro compartimento, so declaradas as opera
es, que correspondem s aes que um objeto sabe realizar.

Nome da Classe Nome da Classe Nome da Classe Nome da Classe


lista de atributos lista de operaes lista de atributos
lista de operaes
Figura 3-1: Possveis notaes para uma classe na UML.

As possveis notaes da UML para representar classes so apresentadas na


Figura 5-1. O grau de abstrao desejado em um dado momento do desenvolvi
mento do modelo de classes direciona a utilizao de uma ou outra notao.
Estruturalmente, uma classe composta de atributos e de operaes. Os atribu
tos correspondem descrio dos dados armazenados pelos objetos de uma classe.
A cada atributo de uma classe est associado um conjunto de valores que esse atri
buto pode assumir. As operaes correspondem descrio das aes que os obje
tos de uma classe sabem realizar. Ao contrrio dos atributos (para os quais cada ob-
MODELAGEM DE CLASSES DE ANALISE 113

jeto tem o seu prprio valor), objetos de uma classe compartilham as mesmas ope
raes. O nome de uma operao normalmente contm um verbo e um comple
mento, e terminam com um par de parnteses. (Na descrio do modelo de classes
de especificao, apresentada a verdadeira utilidade desse par de parnteses.)
A Figura 5-2 ilustra exemplos de representao de uma mesma classe, Con-
taBancria, em diferentes graus de abstrao.

[ContaBancria| ContaBancria ContaBancria ContaBancria ContaBancria


nmero criarO nmero -nmero : String
saldo bloquearO saldo saldo : Quantia
dataAbertura desbloquearO dataAbertura -dataAbertura: Date
creditarO criar0 rcriarO
debitarO bloquearO -tbloquearO
desbloquearO -tdesbloquearO
creditarO H-creditar(in valor: Quantia)
debitarO rdebitar(in valor : Quantia)

Figura 5-2: Diferentes graus de abstrao na notao de classe.

5.2.2 Associaes
Da Seo 1.2.1, sabe-se que cada ocorrncia de uma classe chamada de objeto ou
instncia. Um ponto importante acerca de objetos de um sistema o fato de que
eles podem se relacionar uns com os outros. A existncia de um relacionamento
entre dois objetos possibilita a troca de mensagens (ver Seo 7.5.1) entre os mes
mos. Portanto, em ltima anlise, relacionamentos entre objetos permitem que
eles colaborem entre si a fim de produzir as funcionalidades do sistema.
No diagrama de classes, podemos representar a existncia de relacionamen
tos entre objetos. Para representar o fato de que objetos podem se relacionar uns
com os outros, existe outro elemento na notao do diagrama de classes, a asso
ciao. Esse elemento representa relacionamentos que so formados entre obje
tos durante a execuo do sistema. Uma associao representada no diagrama
de classes por uma linha (normalmente um segmento de reta) ligando as classes
s quais pertencem os objetos relacionados. Na Figura 5-3, apresentamos
alguns exemplos de associaes entre objetos: (1) no domnio de vendas, um
cliente compra produtos' (2) no domnio bancrio, uma conta-corrente possui
um histrico de transaes', (3) em um hotel, h vrios hspedes, assim como h
vrios quartos. Os hspedes do hotel ocupam quartos.
E importante notar que, embora as associaes sejam representadas entre
classes do diagrama, tais associaes representam ligaes possveis entre obje
tos das classes envolvidas na associao. Por exemplo, quando ligamos no dese
nho acima as classes Hspede e Quarto, isso significa que, durante a execuo do
sistema, haver a possibilidade de troca de mensagens entre objetos dessas clas
ses. Ou seja, objetos dessas classes podero colaborar para realizar alguma (par
te de uma) tarefa do sistema.
114 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML. 2/E ELSEVIER

Figura 3-3: Exemplos de associaes entre objetos.

Associaes possuem diversas caractersticas importantes: multiplicidades,


nome, direo de leitura, papis, tipo de participao e conectividade. Nas pr
ximas sees, descrevemos essas caractersticas.

5.2.2.1 Multiplicidades
As associaes permitem representar a informao dos limites inferior e supe
rior da quantidade de objetos aos quais outro objeto pode estar associado. Esses
limites so chamados de multiplicidades na terminologia da UML.^ Cada asso
ciao em um diagrama de classes possui duas multiplicidades, uma em cada
extremo da linha que a representa. Os smbolos possveis para representar uma
multiplicidade esto descritos na Tabela 5-1. Note que, em dois dos casos apre
sentados nessa Tabela, a UML define mais de um smbolo para representar a
mesma multiplicidade. Primeiramente, o smbolo 1 equivalente utilizao
do smbolo Outra equivalncia ocorre entre os smbolos e 0 ..*.

Tabela 5-1: Simboiogia para representar multiplicidades

I Nome Simboiogia
Apenas Um 1
Zero ou Muitos 0..*
Um ou Muitos 1..*
Zero ou Um 0..1
Intervalo Especfico L .L

^As multiplicidades so bastante semelhantes ao conceito de cardinalidade encontrado em outras nota


es para modelagem de dados (por exemplo: a notao de Peter Chen para o diagrama de entidades e re
lacionamentos bastante conhecido na comunidade de Bancos de Dados).
MODELAGEM DE CLASSES DE ANALISE 115
ELSEVIER

Como exemplo, observe a Figura 5-4, que exibe duas classes. Pedido e Cl ien-
te , e uma associao entre as mesmas. A leitura dessa associao nos informa que
pode haver um objeto da classe Cl i ente que esteja associado a vrios objetos da
classe Pedi do (isso representado pela parte * do smbolo 0..*). Alm disso, essa
mesma leitura nos informa que pode haver um objeto da classe Cl i ente que no
esteja associado a pedido algum (isso representado pela parte 0 do smbolo
0..*). O diagrama da Figura 5-4 tambm representa a informao de que um obje
to da classe Pedi do est associado a um, e somente um, objeto da classe Cliente.

1. 1
Cliente recliclo
1 0. . *
Figura 5-4; Exemplo de utilizao dos smbolos de multiplicidade.

Em todos os smbolos nos quais aparece o este denota que no h um li


mite superior predefinido para a quantidade mxima de objetos com os quais
outro objeto pode se associar. Por exemplo, na Figura 5-4, no h um limite su
perior, pelo menos na teoria, para a quantidade de pedidos que um cliente pode
realizar. Logicamente, a tempo de execuo do sistema que est sendo modela
do, essa quantidade mxima ser sempre limitada pela quantidade de memria
do dispositivo computacional no qual a aplicao est executando. No entanto,
quando utilizamos o smbolo em um diagrama de classes, queremos dizer
que a quantidade mxima de associaes um valor finito maior ou igual a zero,
e que no nos importa qual esse valor.
A Tabela 5-1 tambm exibe a forma geral do smbolo de multiplicidade para
intervalos especficos. As expresses Ij e 1^ devem ser substitudas por valores
correspondentes aos limites inferior e superior, respectivamente, do intervalo
que se quer representar. Por exemplo, vamos representar informaes sobre ve-
locistas e corridas nas quais eles participem. Suponha ainda que, em uma corri
da deve haver, no mximo, 6 velocistas participantes. O fragmento de diagrama
de classes que representa esta situao exibido na Figura 5-5. 0 valor para Ij 2
(uma corrida est associada a, no mnimo, 2 velocistas), e o valor para 1^ 6
(uma corrida est associada a, no mximo, 6 velocistas).
Uma lista de intervalos tambm pode ser especificada na multiplicidade de
uma associao. Por exemplo, a multiplicidade 1, 3, 5..9, 11 perfeitamente
vlida, e significa que um objeto pode se associar a uma quantidade de objetos
que esteja no conjunto { 1 , 3 , 5 , 6 , 7 , 8 , 9 , 1 1 } . Note tambm que, por conveno.

T 1 .
veiocista Corrida
2..6 0..*
Figura 5-5: Exemplo de utilizao de intervalo de valores para multiplicidade.
116 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

OS v a lo r e s e s p e c ific a d o s e m u m a m u lt ip lic id a d e e st o s e m p r e e m o r d e m c r e s
c e n t e , q u a n d o l i d o s d a e s q u e r d a p a r a a d ir e it a .
Existem infinitas possibilidades de associao entre objetos (todas as com
binaes possveis entre os nmeros inteiros). No entanto, essas associaes
podem ser agrupadas em apenas trs tipos: muitos para muitos, um para mui
tos e um para um. Denomina-se conectividade o tipo de associao entre duas
classes. A conectividade da associao entre duas classes depende dos smbolos
de multiplicidade que so utilizados na associao. A Tabela 5-2 exibe as corres
pondncias entre os tipos de conectividade e os smbolos de multiplicidade.

Tabela 5-2: Conectividades versus multiplicidades

M u ltip licid a d e de M u ltip licid ad e do


C o n e ctiv id a d e u m e x tr e m o o u tro e x tre m o

U m para um 0 ..1 ou 1 0.. 1 ou 1

U m para m uitos 0 ..1 ou 1 * ou 1 ..* ou 0 ..*

M uitos para m uitos * ou 1 ..* ou 0 ..* * ou 1 ..* ou 0..*

A Figura 5-6 apresenta trs exemplos, um para cada conectividade possvel.


No primeiro (um para um), indica-se que um empregado pode gerenciar um e
somente um departamento. Um departamento, por sua vez, possui um nico
gerente. No segundo exemplo (um para muitos), um empregado est lotado em
um nico departamento, mas um departamento pode ter diversos empregados.
Finalmente, no terceiro exemplo (muitos para muitos), um projeto pode ter di
versos empregados como trabalhadores. Alm disso, um empregado pode tra
balhar em diversos departamentos.

0..* 1..*
Figura 5-6: Exemplos de cada tipo de conectividade.

5.2.2.2 Participaes
Uma caracterstica importante de uma associao est relacionada necessida
de ou no da existncia dessa associao entre objetos. Essa caracterstica de
nominada participao. A participao pode ser obrigatria ou opcional. Se o va-
MODELAGEM DE CLASSES DE ANALISE 117

lor mnimo da multiplicidade de uma associao igual a 1 (um), significa que a


participao obrigatria. Caso contrrio, a participao opcional.
Por exemplo, considere a associao entre Empregado e Departamento na parte
superior da Figura 5-6. A multiplicidade de valor 1 prxima a Empregado indica
que um objeto da classe Departamento s pode existir se estiver associado a um
objeto Empregado. Ou seja, para objetos da classe Departamento, a participao
obrigatria. No entanto, para objetos de Empregado, essa mesma associao par
cial (pode haver empregados que no estejam associados a um departamento).
Isso indicado pelo smbolo 0..1 no extremo prximo classe Departamento.
Deve-se ter cuidado com a utilizao de participaes obrigatrias, pois es
tas engessam o modelo resultante, o que dificulta futuras extenses do mes
mo. Se h dvidas sobre as multiplicidades de uma associao, pode-se adiar
essa deciso para mais tarde, quando mais informaes sobre o sistema forem
conhecidas. Em partculas, as informaes obtidas com a modelagem dinmica
do sistema servem para definir ou validar as multiplicidades das associaes.

5.2.2.3 Nome de associao, direo de leitura e papis


Para melhor esclarecer o significado de uma associao no diagrama de classes,
a UML define trs recursos de notao: nome de associao, direo de leitura e
papel. O nome da associao posicionado na linha da associao, a meio cami
nho das classes envohhdas.
A direo de leitura indica como a associao deve ser lida. Essa direo re
presentada por um pequeno tringulo posicionado prximo a um dos lados do
nome da associao. O nome de uma associao deve fornecer algum significa
do semntico mesma.
Quando um objeto participa de uma associao, ele tem um papel especfico
nela. Uma caracterstica complementar utilizao de nomes e de direes de
leitura a indicao de papis (roles) para cada uma das classes participantes em
uma associao.
A Eigura 5-7 apresenta uma associao na qual so representados os papis
(contratante e contratado) e o seu nome (Contrata). tambm representada a

Nome da Direo
de leitura

Papel

C ontrata contratado
Organizao Indivduo

Fig u ra 5-7: Exemplo de utilizao de nome de associao, direo de leitura e de papis.


118 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

direo de leitura, que indica que uma organizao contrata indivduos, e no o


contrrio.
Sempre que o significado de uma associao no for fcil de inferir, reco
mendvel representar papis ou pelo menos o nome da associao. Isso evita
que haja interpretaes erradas no significado da associao. Alm disso, essa
prtica aumenta a legibilidade do diagrama. O nome da associao deve ser sim
ples e exprimir o significado da mesma. prefervel no nomear associaes a
usar nomes vagos ou bvios demais. O mesmo vale para os papis: em situaes
em que o significado da associao for intuitivo, a utilizao de papis s serve
para carregar o diagrama. O ponto tentar equilibrar clareza e conciso.
Embora no seja usual, pode haver diversos motivos pelos quais um objeto
precisa saber sobre outro. Consequentemente, pode haver diversas associaes
definidas entre duas classes no diagrama de classes. Por exemplo, considere
duas classes: Empregado e Departamento. Considere, ainda, que um departamento
precisa saber quais so seus empregados e quem o seu gerente. Nesse caso, h
duas associaes diferentes, embora as classes envolvidas sejam as mesmas (ver
Figura 5-8).

* Trabalha 1

1 gerente 0..1
Figura 5-8: Associaes diferentes entres duas classes.

5.2.2.4 Classes associativas


Classes associativas so classes que esto ligadas a associaes, em vez de esta
rem ligadas a outras classes. So tambm chamadas de classes de associao.
Esse tipo de classe normalmente aparece quando duas ou mais classes esto as
sociadas, e necessrio manter informaes sobre a associao existente entre
as mesmas. Embora seja mais comum encontrar classes associativas ligadas a as
sociaes de conectividade muitos para muitos, uma classe associativa pode es
tar ligada a associaes de qualquer conectividade.
Na UML, uma classe associativa representada pela mesma notao utiliza
da para uma classe comum. A diferena que esta classe ligada por uma linha
tracejada a uma associao. Para ilustrar a utilizao de uma classe associativa
em um diagrama de classes, apresentamos a Figura 5-9. Esse diagrama informa
que uma pessoa trabalha como empregado em vrias empresas. Uma empresa,
por sua vez, tem vrios empregados. A classe associativa Emprego permite saber,
para cada par de objetos [empregado, empregador], qual o salrio e a data de
MODELAGEM DE CLASSES DE ANLISE 119

contratao do empregado em relao quele empregador. De forma geral, se


precisarmos representar a existncia de uma informao que somente faz senti
do quando consideramos todos os objetos participantes da associao, pode
mos utilizar o conceito de classe associativa.

Figuj a 5-9: Exemplo de classe associativa.

Como dica de modelagem, no se deve nomear a linha da associao de uma


classe associativa. Nesse caso, somente o nome escolhido para a classe associati
va deve ser suficiente para expressar o significado desejado. Alternativamente,
papis (ver Seo 5.2.2.3) tambm podem ser utilizados para dar significado
associao.
Note que uma classe associativa pode participar de outros relacionamentos.
Por exemplo, observe o diagrama da Figura 5-10, no qual podemos verificar que
h funcionrios com vrias especialidades. Consertos em automveis so reali
zados por funcionrios, mas necessrio saber que especialidade foi utilizada
pelo funcionrio em certo conserto. Para isso, uma classe associativa criada
entre as classes Funci onri o e Automvel. Alm disso, essa mesma classe associa
tiva est associada classe especialidade para permitir conhecer qual a especia
lidade utilizada em um conserto.

Figu ra 5-10: Exemplo de classe associativa.


120 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Pelos exemplos anteriores, pode-se notar que uma classe associativa um


elemento hbrido; tem caractersticas de uma classe, mas tambm caractersti
cas de uma associao.
Por fim, de forma geral, um diagrama de classes que contm uma classe as
sociativa pode ser modificado para retir-la, sem perda de informao no mode
lo em questo. Isso pode ser feito em dois passos: (1) eliminao da associao
correspondente classe associativa e (2) criao de associaes diretas desta l
tima com as classes que antes eram conectadas pela associao eliminada no
passo 1. Como exemplo de aplicao desses passos, a Figura 5-11 apresenta um
diagrama equivalente ao da Figura 5-9, em que a classe associativa foi substitu
da por uma classe ordinria. Note que a classe Emprego tem participao obri
gatria em ambas as associaes.

Figura 5-11: Uma classe associativa pode ser substituda por uma classe ordinria.

5.2.2.5 Associaes ternrias


Define-se o grau de uma associao como a quantidade de classes envolvidas na mes
ma. Na grande maioria dos casos prticos de modelagem, as associaes normalmen
te so binrias, ou seja, representam a ligao entre objetos de duas classes (tem grau
igual a dois). Entretanto, de forma geral, uma associao pode ter grau maior que
dois. Quando o grau de uma associao igual a trs, dizemos que a mesma tern
ria. Associaes ternrias so necessrias quando preciso associar trs objetos dis
tintos. A Eigura 5-12 ilustra a notao da UML para associaes ternrias.
Dada uma associao ternria (ou de mais alto grau) entre as classes A, B e
C, a multiplicidade do extremo C indica quantos objetos da classe C podem es
tar associados com um par particular de objetos (b, c), em que b um objeto da
classe B, e c uma instncia da classe C.

Fig u ra 5-12: Notao para representar associaes ternrias no diagrama de classes.


MODELAGEM DE CLASSES DE ANALISE 121
ELSEVIER

Um exemplo de associao ternria apresentado na Figura 5-13. Esta figu


ra ilustra o fato de que um tcnico utiliza exatamente um computador para cada
projeto em que trabalha. Cada computador pertence a um tcnico para cada pro
jeto. Note que um tcnico pode trabalhar em muitos projetos e utilizar diferen
tes computadores para diferentes projetos.

Figura D-J3; Exemplo de associao temria.

Outro exemplo de associao ternria apresentado na Figura 5-14. Desta


vez, v-se que cada empregado associado a um projeto trabalha em somente
uma localizao, mas pode estar em diferentes localizaes em projetos diferen
tes. Em uma localizao em particular, pode haver muitos empregados associa
dos a um dado projeto.

Figura 5-14: Exemplo de associao ternria.

Finalmente, os conceitos de classe associativa e de associao ternria


podem ser misturados no conceito de classe associativa ternria, no qual
existe uma classe associativa ligada a uma associao ternria. A Figura 5-15
ilustra um exemplo desta situao. H trs classes ligadas por uma associa
o ternria (Estudante, In s t r u t o r e Curso). Alm disso, existe a classe asso
ciativa SeoCurso, que permite armazenar informaes para cada instncia
da associao.
122 prin c pio s DE ANLISE E PROJETO DE SISTEMAS COM UME, 2/E ELSEVIER

Figura 5-15: Exemplo de classe associativa ternria.

5.2.2.6 Associaes reflexivas


Uma associao reflexiva (tambm denominada auto-associao) associa obje
tos da mesma classe. Cada objeto tem um papel distinto nessa associao. Por
exemplo, considere a Figura 5-16, em que existe uma associao reflexiva entre
objetos de Empregado. Nessa figura, apresentamos um exemplo de uso de au
to-associao, em que h objetos que assumem o papel de supervi sor e outros
objetos que assumem o papel de supervi s i onado. Nesse exemplo, o nome da as
sociao poderia ter sido omitido, uma vez que os papis foram definidos (ver
Seo5.2.2.3). Alm disso, conforme mostra a Figura 5-16, em associaes re
flexivas, a utilizao de papis bastante importante para evitar qualquer con
fuso na leitura da associao.

supervisor

Empregado
supervisionado
Figura 5-16: Exemplo de associao reflexiva.

No se deve confundir o significado de uma associao reflexiva. Ela no in


dica que um objeto se associa a ele prprio (um empregado no supervisor
dele prprio; uma disciplina no pr-requisito dela mesma etc.). Em vez disso,
uma auto-associao indica que um objeto de uma classe se associa com outros
objetos da mesma classe.
MODELAGEM DE CLASSES DE ANALISE 123

5.2.2.7 Agregaes e composies


A toda associao podemos atrelar uma semntica. A semntica de uma associa
o corresponde ao seu significado, ou seja, natureza conceituai da relao
que existe entre os objetos que participam daquela associao. Quando damos
um nome a uma associao (ou alternativamente definimos os papis dos obje
tos associados pela mesma), fazemos isso com o objetivo de esclarecer a sua se
mntica.
De todos os significados diferentes que uma associao pode ter, h uma ca
tegoria especial de significados, que representa relaes todo-parte. Uma relao
todo-parte entre dois objetos indica que um dos objetos est contido no outro.
Podemos tambm dizer que um objeto contm o outro.
A UML define dois tipos de relacionammtos todo-parte, a agregao e a composi
o. A agregao e a composio so casos especiais da associao. Conseqente-
mente, todas as caractersticas vlidas para esta ltima (multiplicidades, participa
es, papis etc.) valem para as primeiras. Alm disso, sempre que for possvel utili
zar uma agregao ou composio, uma associao tambm poder ser utilizada.
De qualquer modo, a seguir so relacionadas algumas caractersticas particulares
das agregaes e composies que as diferem das associaes simples.

Agregaes/composies so assimtricas, no sentido de que, se um obje


to A parte de um objeto B, o objeto B no pode ser parte do objeto A.
Agregaes/composies propagam comportamento, no sentido de que
um comportamento que se aplica a um todo automaticamente se aplica s
suas partes.
Nas agregaes/composies, as partes so normalmente criadas e des
trudas pelo todo. Na classe do objeto todo, so definidas operaes para
adicionar e remover as partes.

Em uma situao prtica, podemos aplicar a seguinte regra para verificar se


faz sentido utilizarmos um relacionamento todo-parte (agregao ou composi
o) . Sejam duas classes associadas, X e Y. Se uma das perguntas a seguir for res
pondida com um sim, provavelmente h um relacionamento todo-parte envol
vendo X e Y, no qual X o todo, e Y a parte. (Do contrrio, melhor utilizar
mos a associao simples.)

1) X tem um ou mais Y?
2) Y parte de XI

Graficamente, a UML fornece notaes diferentes para a agregao e a com


posio. Uma agregao representada como uma linha que conecta as classes
relacionadas, com um diamante (losango) branco perto da classe que represen-
124 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E E L S E V IE R

ta o todo. J uma composio representada na UML por meio de um diamante


negro, para contrapor com o diamante branco da agregao.
Como exemplo de agregao, analise a Figura 5-17, que apresenta um frag
mento de diagrama de classes. Esse diagrama indica que uma associao espor
tiva formada por diversas equipes. Cada equipe formada por diversos joga
dores. Por outro lado, um jogador pode fazer parte de diversas equipes.

membro
i Afiliada
AssociaaoEsportiva O Equipe O- Jogador

Figura 5-17: Exemplo de agregaao.

Como exemplo de composio, considere os itens de um pedido de compra.


comum um pedido de compra incluir vrios itens. Cada item diz respeito a um pro
duto faturado. Os itens tm identidade prpria ( possvel distinguir um item de
outro no mesmo pedido). Essa situao representada no diagrama da Eigura 5-18.
Outro exemplo de composio apresentado na Figura 5-19. Esse diagrama infor
ma que um automvel possui vrias partes, a saber, um motor e quatro rodas.

Figura 5-18: Composio entre Pedi do e ItemPedi do.

Figu ra 5-19: Exemplo de utilizao de composio. Todo; Automvel, Partes: Motor e Roda.
MODELAGEM DE CLASSES DE ANALISE 125

Uma agregao pode se estender por diversos nveis. Isso significa que pode
haver um objeto A que seja composto de objetos B, e que este ltimo seja com
posto por objetos C, e assim por diante. Isso gera uma hierarquia de agregaes.
O exemplo da Figura 5-17, em que h dois nveis de agregao, permite notar
essa caracterstica. Assim como as agregaes, composies tambm podem se
estender por diversos nveis. Dessa forma, pode-se falar em uma hierarquia de
composies. Um exemplo de hierarquia de composio a Figura 5-20, que
mostra que captulos so compostos de sees, estas, por sua vez, so compos
tas de pargrafos.

Captulo ---------------------- Seo -------------------- Pargrafo


1 * 1 *

Figura 5-20: Exemplo de hierarquia de composio.

Se um modelador constata que uma associao tem uma semntica to-


do-parte, ele deve decidir que relacionamento utilizar, se uma agregao ou
uma composio. Infelizmente, tanto na prtica, quanto na teoria, as diferenas
entre a agregao e a composio no so bem definidas. Mesmo assim, a seguir
descrevemos as duas diferenas mais marcantes entre os dois tipos de relaciona
mentos todo-parte.

1. Na agregao, a destruio de um objeto todo no implica necessaria


mente a destruio do objeto parte. Por exemplo, considere a Figura
5-17. Se uma das equipes das quais um jogador membro for extinta por
algum motivo, este jogador ainda poder continuar membro de outras
equipes. Por outro lado, considere o exemplo da Figura 5-18. Nessa si
tuao, os itens no tm existncia independente do pedido ao qual esto
conectados. Quando o pedido deixa de existir, o mesmo acontece com os
seus itens.
2. Na composio, os objetos parte pertencem a um nico todo. Por essa ra
zo, a composio tambm denominada agregao no-compartilhada.
Por outro lado, em uma agregao, pode ser que um mesmo objeto parti
cipe como componente de vrios outros objetos. Por essa razo, a agrega
o tambm denominada agregao compartilhada.

5.2.2.8 Restries sobre associaes


Restries podem ser adicionadas sobre uma associao para adicionar a ela
mais semntica. Duas das restries sobre associaes predefinidas pela UML
so subset (subconjunto) e xor (ou exclusivo). Ambas so representadas por
uma linha pontilhada que liga duas ou mais associaes. Embora a descrio a
126 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E E L S E V IE R

seguir faa referncia a associaes, essas restries tambm podem ser utiliza
das em agregaes e composies.
A restrio subset indica que os objetos conectados por uma associao
constituem um subconjunto dos objetos conectados atravs de uma outra as
sociao. A Figura 5-21 ilustra o uso da restrio subset. Neste exemplo, h
duas classes ligadas pela restrio subset, indicando que os objetos associados
atravs de Administra formam um subconjunto dos objetos associados atravs
de Reside. (Portanto, a flecha parte da associao correspondente ao subcon
junto.)

Reside
A
*
1

Pessoa (subset) Edi cio

1 0..1

Administra
Figura 5-21: Exemplo de utilizao da restrio subset.

Na restrio xor, h duas ou mais classes ligadas pela linha pontilhada.


Essas classes devem ter associaes com uma classe em comum. Essa restrio
significa que somente uma das associaes envolvidas pode ocorrer entre os ob
jetos. Como exemplo da restrio xor, considere a Figura 5-22 (por simplifica
o, atributos e operaes so omitidos). Este exemplo indica que um objeto
ContaBancria pode estar associado a objetos Pessoa ou a objetos Instituio,
mas nunca a objetos dos dois tipos simultaneamente.

1..*
Figura 5-22: Exemplo de utilizao da restrio xor.
MODELAGEM DE CLASSES DE ANALISE 127

As restries tambm podem ser definidas formalmente em OCL (ver Seo


3.6). Expresses nessa linguagem podem ser definidas utilizando-se uma expres
so da forma Item.seletor. Essa expresso permite ter acesso s propriedades de
uma classe (atributos, operaes e associaes). Essas expresses podem ser
combinadas recursivamente para formar expresses mais complexas. Alm disso,
os operadores aritmticos (+, -,*,/) e lgicos (>, .=, <, ,=, < >, =) tambm esto dis
ponveis para definir expresses na OCL. A seguir, descreveremos vrios exem
plos de diagramas de classes nos quais so definidas expresses em OCL.
Na Figura 5-23, a expresso em OCL define que, para um objeto Vo, a
quantidade de horas de treinamento do piloto deve ser maior ou igual quanti
dade mnima de horas exigida para o avio a ser pilotado.

Figura 5-23: Exemplo de utilizao da OCL para definir restries.

No exemplo da Figura 5-24. tem-se uma restrio em OCL definida so


bre o elemento de associao entre as classes do diagrama. Essa restrio
indica que um indivduo deve ter mais de 21 anos para participar de uma
sociedade.
Um outro exemplo (adaptado do documento de especificao da UML)
ilustrado na Figura 5-25, em que h duas classes. Empresa e Pessoa. A restri-

Figu ra 5-24: Exemplo de definio de restrio em O CL.


128 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UME, 2/E E L S E V IE R

Figura 5-25: Exemplo de definio de restrio em OCL.

o em OCL deste exemplo significa que uma pessoa que trabalhe para uma
empresa empregadora e o gerente dessa pessoa devem trabalhar para a mes
ma empresa.

5.2.3 Generalizaes e especializaes


Alm de relacionamentos entre objetos, o modelo de classes tambm pode re
presentar relacionamentos entre classes. Esses ltimos denotam relaes de ge
neralidade ou especificidade entre as classes envolvidas. Por exemplo, o concei
to mamfero mais genrico que o conceito ser humano. Outro exemplo: o con
ceito carro mais especfico que o conceito veculo.
O relacionamento de herana tambm chamado de relacionamento de ge-
neralizao/especializao, ou simplesmente genlespec. Isso porque a generali
zao e a especializao so dois pontos de vista do mesmo relacionamento: da
das duas classes A e B, se A uma generalizao de B, ento B uma especializa
o de A.
Os termos para denotar o relacionamento de herana so bastante variados.
O termo subclasse utilizado para denotar a classe que herda as propriedades de
outra classe atravs de uma generalizao. Diz-se, ainda, que a classe que possui
propriedades herdadas por outras classes a superclasse. Utilizam-se ainda os
nomes supertipo e subtipo como sinnimos para superclasse e subclasse, respec
tivamente. Outros termos (mais utilizados em linguagens de programao
orientada a objetos) so classe base (sinnimo para superclasse) e classe herdei
ra (sinnimo para subclasse). Diz-se tambm que uma subclasse uma especia
lizao de sua superclasse (a subclasse especializa a superclasse), e que uma su
perclasse uma generalizao de suas subclasses (a superclasse generaliza as
subclasses). Os termos ancestral e descendente fazem referncia ao uso do rela
cionamento de generalizao em vrios nveis (ver Seo 5.2.3.1).
No diagrama de classes, a herana representada na UML por uma flecha
partindo da subclasse em direo superclasse. Alternativamente, podemos
MODELAGEM DE CLASSES DE ANALISE 129

ISuperclasse I ISiyerel^se |
S

Subclassl] |Subclasse] ... |SubclasseN| |SubcIassel| ISubclassll |SubclasseN|

Figura 5-26: Representaes alternativas para o relacionamento de generalizao na UML.

juntar as flechas de todas as subclasses de uma classe, como mostra a Figura


5-26. A utilizao de um ou de outro estilo questo de gosto.
Para entender a semntica de um relacionamento de herana, preciso lem
brar que uma classe representa um conjunto de objetos que partilham um con
junto comum de propriedades (atributos, operaes, associaes). No entanto,
alguns objetos, embora bastante semelhantes a outros, podem possuir um con
junto de propriedades que outros no possuem. Por exemplo, todos os funcio
nrios de uma empresa partilham os atributos nome, endereo, nmeroMatr cul a e
sal ri oBase. No entanto, um tipo especial de funcionrio - o dos vendedores -
possui atributos especficos, por exemplo, zonaGeogrfica (zona em que traba
lham) e taxaComi sso (porcentagem de comisso que recebem pelas vendas rea
lizadas). Os vendedores pertencem classe dos funcionrios, mas eles por si
prprios formam uma outra classe, a dos vendedores. Portanto, vendedores
possuem todas as caractersticas inerentes a funcionrios, alm de possurem
caractersticas prprias. Diz-se, assim, que a classe de vendedores herda pro
priedades da classe de funcionrios.
importante notar que no somente atributos e operaes so herdados
pelas subclasses, mas tambm as associaes que esto definidas na superclas-
se. A Figura 5-27 um exemplo dessa propriedade: existe uma associao entre
Cl i ente e Pedi do. No h necessidade de se criar uma associao entre Pedi do
e Cl ie n te P e sso a F sica e entre Pedido e Cl ie n te P e sso a J u rd ic a , pois as subclas
ses herdam a associao de sua superclasse. Por outro lado, se existe uma as
sociao que no comum a todas as subclasses, mas, sim, particular a algu-

Realiza

Figu ra 5-27: No h necessidade de se criar uma associao entre Pedido e as subclasses de Cliente.
130 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E E L S E V IE R

mas subclasses, ento essa associaao deve ser representada em separado, en


volvendo somente as subclasses em questo.
Um conceito que pode ser utilizado em situaes de modelagem a classe
abstrata. Uma classe abstrata normalmente utilizada para organizar a hierar
quia de classes. Uma classe abstrata utilizada para fins de modelagem como
um continer de definies de propriedades. Classes abstratas no geram obje
tos diretamente (embora objetos de uma subclasse de uma classe abstrata sejam
tambm considerados objetos dessa ltima). Na notao da UML, uma classe
abstrata representada com seu nome em itlico. Por exemplo, na Figura 5-27, a
classe Cl iente abstrata. As classes Conta e ContaBancri a na Figura 5-28 tam
bm so abstratas. O conceito de classe abstrata tem fundamental importncia
no contexto da modelagem de classes de projeto. Na Seo 8.5.2, descrevemos o
conceito de classe abstrata naquele contexto.
importante notar que o relacionamento de herana difere do relaciona
mento de associao, porque o primeiro se trata de um relacionamento entre
classes. Quando se diz, por exemplo, que gerentes so tipos especiais de funcio
nrios significa que objetos da classe gerente possuem caractersticas comuns a
todos os funcionrios, alm de poderem ter caractersticas prprias de um ge
rente. Por outro lado, os relacionamentos de associao, agregao e composi
o so definidos entre objetos. Isso equivale a dizer que objetos especficos de
uma classe se associam entre si ou com objetos especficos de outras classes.

0 relacionamento de herana acontece entre classes. J o relacionamento de as


sociao acontece entre instncias de classes (objetos).

5.2.3.1 Propriedades do relacionamento de herana


O relacionamento de herana possui duas propriedades importantes, transitivi
dade e assimetria, que descrevemos a seguir.
A propriedade da transitividade indica que uma classe em uma hierarquia
herda tanto propriedades e relacionamentos de sua superclasse imediata quan
to de suas superclasses no imediatas (classes em um nvel mais alto da hierar
quia) . A propriedade de transitividade entre classes tambm pode ser vista sob a
perspectiva de que toda instncia de uma classe tambm uma instncia de suas
superclasses. Ou seja, uma instncia de uma classe C tambm instncia de to
dos os ancestrais de C. Uma classe uma generalizao de outra classe se toda
instncia desta ltima for tambm uma instncia da primeira. Pela propriedade
de transitividade, a herana pode ser aplicada em vrios nveis, ou seja, uma
classe que herda propriedades de uma outra classe pode ela prpria servir como
superclasse. A Figura 5-28 ilustra uma hierarquia de herana de trs nveis. Nes-
MODELAGEM DE CLASSES DE ANALISE 131

sa hierarquia, so apresentadas cinco classes. Note que ContaPoupana possui


um atributo prprio, e mais trs atributos herdados de Conta. Note tambm a
disposio das classes no diagrama, no qual as classes mais genricas esto posi
cionadas acima das classes mais especficas. Essa disposio no obrigatria,
pois o sentido da seta indica qual a classe mais genrica. No entanto, reco
mendado dispor as classes dessa forma para enfatizar a hierarquia existente en
tre superclasses e subclasses.

Figura 5-28: Exemplo de hierarquia de herana.

Outra propriedade importante da herana a assimetria. Essa propriedade


significa que dadas duas classes A e B, se A for uma generalizao de B, ento B
no pode ser uma generalizao de A. Ou seja, no pode haver ciclos em uma
hierarquia de herana.

5.2.3.2 Refinando omodelo de classes comgen/espec


Graas a relacionamentos de herana, podem ser feitos refinamentos no modelo de
classes. A idia bsica identificar abstraes mais genricas ou mais especficas
que outras no diagrama de classes do sistema. Essa identificao de abstraes cor
responde a refinamentos no modelo de classes que podem ser obtidos a partir de
duas estratgias alternativas e complementares: a generalizao e a especializao.
132 prin c pio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E E L S E V IE R

Primeiro pode ser que duas ou mais classes semelhantes tenham sido identi
ficadas. Neste caso, pode ser adequado criar uma generalizao, ou seja, uma
classe mais genrica, e definir as classes anteriores como subclasses desta lti
ma. Pode ser que a superclasse no gere instncias prprias e esteja sendo utili
zada somente para organizar classes semelhantes em uma hierarquia. Neste
caso, a superclasse pode ser definida como abstrata (ver Seo 8.5.2), o que sig
nifica que ela tem o objetivo de organizar o modelo.
Em segundo lugar, pode-se tambm aplicar a especializao, que correspon
de ao processo de criar classes mais especficas a partir de uma classe preexis
tente. Por exemplo, talvez tenha sido identificada uma nova propriedade de
uma classe preexistente que justifique a criao de uma subclasse na qual esta
propriedade seja definida.
Seja qual for o processo de derivao utilizado, generalizao ou especiali
zao, uma dica prtica para confirmarmos se h legitimamente um relaciona
mento de gen/espec entre duas classes aplicar a chamada regra da substituio
que apresentamos a seguir. (Por conta dessa regra, o relacionamento gen/espec
tambm conhecido como relacionamento -um.)

Regra da substituio: sejam duas classes A e B, onde A uma generalizao de


B. No pode haver diferenas entre utilizar instncias de B ou de A, do ponto de vis
ta dos clientes de A.

Uma conseqncia da regra da substituio a seguinte: inadequado o uso


do relacionamento gen/espec onde nem todas as propriedades e comportamen
tos da superclasse fazem sentido para a subclasse.
Outro teste que pode ser realizado para identificar se duas classes se relacio
nam por gen/espec, e que equivalente ao da regra da substituio, perguntar
o seguinte: X um tipo de Y? Se a resposta for sim, provavelmente a classe X
deve ser definida como uma subclasse de Y.
Deve-se tambm considerar a conformidade da subclasse em relao s pro
priedades definidas em sua superclasse. Ou seja, inadequado o uso de gen/es
pec na situao em que nem todas as propriedades da superclasse fazem sentido
para a subclasse. Essa restrio uma interpretao da regra da substituio.
Como um exemplo de uso adequado de gen/espec (e que respeita a regra da
substituio), observe o diagrama de classes da Eigura 5-29. Note que tanto
ContaCorrente quanto ContaPoupana so tipos de ContaBancria. Note tambm
que os relacionamentos e propriedades da superclasse valem para ambas as sub
classes.
Atravs da generalizao e da especializao, classes mais gerais podem ser de
finidas a partir de classes mais especficas, e classes mais especficas tambm podem
MODELAGEM DE CLASSES DE ANAJSE 133

F ig u ra 5 -2 9 : Conformidade das subclasses superclasse.

ser definidas a partir de classes mais gerais. Entretanto, na aplicao de generaliza


o ou especializao, deve-se evitar a construo de hierarquias de herana muito
profundas (com mais de trs nveis), pois elas dificultam a leitura do diagrama.
Outra dica: papis (ver Seo 5 .2.2.3) e subclasses no devem ser confundi
dos. Um papel corresponde ao uso de certa classe em uma associao. Uma clas
se pode assumir vrios papis. O modelador deve evitar a criao de subclasses
em situaes que podem ser resolvidas atravs da utilizao de papis. Veja o
exem plo da Figura 5-30.

m orador

F ig u ra 5 -3 0 : Situao em que mais adequado utilizar um papel do que uma subclasse.

5.2.3.3 Definio de restries sobre gen/espec


Conforme descrito na Seo 3.4, a UML permite que determinadas restries se
jam associadas a elementos de um modelo. Nesta seo, descreveremos algumas
restries predefinidas pela UML que se aplicam ao relacionamento gen/espec.
As restries sobre gen/espec so representadas no diagrama de classes,
prxim as linha do relacionamento. Essas restries so apresentadas entre
chaves. As restries precfehnicias pe/a UML para hierarquias d e herana so
descritas na Tabela 5-3.
134 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E E L S E V IE R

Tabela 5-3: Restries predefinidas para generalizaes

Restrio Significado
sobreposta Posteriormente, podem ser criadas subclasses que herdem de
mais de uma subclasse (herana mltipla).
disjunta Quaisquer subclasses criadas posteriormente podero herdar de
somente uma subclasse.
completa Todas as subclasses possveis foram enumeradas na hierarquia.
incompleta Nem todas as subclasses foram enumeradas na hierarquia.

As duas primeiras restries (sobreposta e disjunta) e as duas ltimas (com-


pleta e incompleta) so exclusivas entre si. Isso quer dizer que no h sentido
em definir subclasses que sejam sobrepostas e disjuntas ao mesmo tempo, e que
no tem sentido definir subclasses simultaneamente com as restries completa
e incompleta. A seguir, veremos diversos exemplos de hierarquias de herana
em que se utilizam restries.
O exemplo da Figura 5-31 informa que h outras subclasses de Ve cul o alm
das que foram enumeradas na hierarquia.
Na Figura 5-32, as restries completa e disjunta significam que (1) no h
objeto dentro desta hierarquia que no seja nem homem nem mulher (comple
ta) e (2) no h objeto nesta hierarquia que seja homem e mulher ao mesmo
tempo (disjuno).

Figura 5-31: Herana incompleta.

Figura 5-32: Herana completa e disjunta.


MODELAGEM DE CLASSES DE ANALISE 135

Na Figura 5-33, o uso da restrio sobreposta significa que um Atleta pode


ser tanto Nadador quanto Corredor. Alm disso, h outras subclasses de Atleta
no enumeradas no diagrama (incompleta).
Na Figura 5-34, El i pse. Quadrado e C rcul o so tipos de FiguraGeomtrica.
Alm disso, existem outras subclasses no especificadas na hierarquia.

Figura 5-33: Herana incompleta e sobreposta.

Figura 5-34: Herana incompleta e disjunta.

5.3 Diagrama de objetos


Alm do diagrama de classes, a UML define um segundo tipo de diagrama estru
tural: o diagrama de objetos. Diagramas de objetos podem ser vistos como ins
tncias de diagramas de classes, da mesma forma que objetos so instncias de
classes.^ Assim como diagramas de classes, diagramas de objetos so estruturas
estticas. Um diagrama de objetos exibe uma fotografia do sistema em certo
momento, exibindo as ligaes formadas entre objetos conforme estes intera
gem e de acordo com os valores dos seus atributos.
Em um diagrama de objetos, cada objeto representado por um retngulo
com dois compartimentos. No compartimento superior, a identificao do ob
jeto exibida. No compartimento inferior (cuja utilizao opcional), apare
cem valores para os atributos definidos na classe do objeto.

2. Diagramas de objetos so tambm chamados diagramas de instncias.


136 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

A identificao do objeto deve ser sempre sublinhada. Por conveno, o


nome da classe comea com letra maiuscula. O nome do objeto pode ser omitido
quando for conveniente. Os dois formatos possveis para a identificao de um
objeto, juntamente com exemplos de cada um, so apresentados na Tabela 5-4.

Tabela 5-4: Possveis formatos para identificao de instncias em um diagrama


de objetos

Formato Exemplo
:NomeClasse :Pedido

notneOb.ieto: NomeClasse umPedido: Pedido

O segundo compartimento do retngulo que representa um objeto, quando


utilizado, exibe uma lista de pares da forma nome do atributo: valor do atributo.
Como um exemplo, a Figura 5-35 exibe um diagrama de objetos instancia
do a partir do diagrama de classes da Figura 5-18. Este diagrama de objetos mos
tra uma instncia de pedido ligada a trs instncias de item de pedido. Cada
item, por sua vez, est ligado a um produto. Note que so apresentados valores
para cada atributo de um objeto.

Figura 5-35: Exemplo de diagrama de objetos.

A Figura 5-36 exibe outro exemplo de diagrama de objetos, em que os com


partimentos dos valores de atributos so omitidos. Esse diagrama uma instn
cia do diagrama de classes da Figura 5-16.
O diagrama de objetos uma contribuio do mtodo de Booch (ver Seo
1.3) UML. Considerados sozinhos, esses diagramas so raramente utilizados
na prtica. A nica utilidade prtica e direta dos diagramas de objetos a de ilus-
MODELAGEM DE CLASSES DE ANALISE 137
ELSEVIER

Figura 5-36: Exemplo de diagrama de objetos em que os valores dos atributos no so exibidos.

trar a formao de relacionamentos complexos de um diagrama de classes,


como associaes reflexivas. Com o objetivo de facilitar a atividade de validao
(ver Seo 2.f .2), podemos construir diagramas de objetos para ilustrar e escla
recer certos aspectos de um diagrama de classes. Entretanto, fora desse contex
to de validao, a descrio do diagrama de objetos ainda relevante, pois o dia
grama de interao (particularmente, o diagrama de comunicao), descrito no
Captulo 7, utiliza a mesma notao que o primeiro.

5.4 Tcnicas para identificao de classes


Na Seo 3.2, descrevemos alguns dos elementos do diagrama de classes. No en
tanto, apenas o conhecimento da notao existente para produo daquele dia
grama no suficiente para a construo do modelo de classes de um sistema de
software orientado a objetos (SSOO). De fato, uma das tarefas mais importantes e
difceis no desenvolvimento de um SSOO a identificao das classes necess
rias e suficientes para compor esse sistema.
Nesta seo, nosso objetivo estudar algumas tcnicas de identificao de
classes. Antes de continuarmos, porm, importante darmos uma explicao
do termo identificao de classes. Por definio, um SSOO composto de
uma coleo de objetos que colaboram para realizar as tarefas desse sistema. Por
outro lado, sabemos que todo objeto de um SSOO pertence a uma classe. Por
tanto, quando se fala em identificao das classes, o objetivo na verdade sa
ber quais objetos iro compor o sistema em questo.
Independentemente da tcnica utilizada, a tarefa de identificao de classes se
divide em duas atividades. Primeiramente, classes candidatas (ou seja, entidades
que podem se tornar classes) so identificadas. Depois disso, so aplicados alguns
princpios para eliminar classes candidatas desnecessrias. A segunda atividade ,
sem dvida, a mais complicada: identificar possveis classes para um sistema no
complicado; o difcil eliminar desse conjunto o que no necessrio. Alm dis
so, importante notar que as atividades para identificao de classes no so se
quenciais (uma no comea quando a outra acaba). Ao contrrio, os desenvolve-
138 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

dores intercalam a realizao dessas atividades, identificando novas candidatas e


removendo candidatas previamente identificadas. Parafraseando Bertrand Me
yer: Como um jardineiro, o [desenvolvedor] deve, a todo o momento, alimentar
as plantas boas e eliminar as ervas daninhas (Meyer, 1997).

5.4.1 Anlise textual de Abbott


Em 1983, Russell Abbott props essa tcnica de identificao que hoje leva seu
nome (Abbott, 1983). Na chamada Andise Textual de Abbott (ATA), utilizam-se
diversas fontes de informao sobre o sistema: documento de requisitos, mode
los do negcio (se existirem; ver Seo 4.6.1), glossrios, conhecimento sobre o
domnio etc. Para cada um desses documentos, os nomes (substantivos e adjeti
vos) que aparecem no mesmo so destacados. (So tambm consideradas locu
es equivalentes a substantivos.) Aps isso, os sinnimos so removidos (per
manecem os nomes mais significativos para o domnio do negcio em questo).
Cada termo remanescente se enquadra em uma das situaes a seguir:
1. O termo se torna uma classe (ou seja, so classes candidatas).
2. O termo se torna um atributo.
3. O termo no tem relevncia alguma com relao aos requisitos do SSOO.

Abbott segue na descrio de sua proposta para aplic-la tambm na identi


ficao de operaes de uma classe e de associaes entre classes. Para isso, ele
sugere que destaquemos os verbos no texto. Verbos com sentido de ao (por
exemplo calcular, confirmar, cancelar, comprar, fechar, estimar, depositar, sa
car etc.) so operaes em potencial. Verbos com sentido de ter so agrega
es ou composies (ver Seo 5.2.2.7) em potencial. Verbos com sentido de
ser so generalizaes (ver Seo 5.2.3) em potencial. Os demais verbos so
associaes em potencial.
Conforme descrito no pargrafo anterior, uma operao identificada me
diante anlise de um verbo que denota ao. A classe na qual essa operao deve
ser definida pode ser encontrada atravs do sujeito da frase em que o verbo uti
lizado. Alm disso, informaes necessrias realizao dessa operao podem
normalmente ser encontradas no complemento da frase.

Parte do Texto Componente Exemplo


Nome prprio Objeto Eduardo Bezerra
Nome simples Classe 1 aluno
Verbos de Ao Operao I registrar
Verbo Ser Herana e um
Verbo Ter Todo-parte tem um
MODELAGEM DE CLASSES DE ANALISE 139

Uma vantagem da anlise de Abbott que essa abordagem bastante sim


ples: para cada documento, destacam-se termos para detectar componentes
do modelo de classes. No entanto, apesar da facilidade de aplicao dessa tc
nica, uma desvantagem que seu resultado (as classes candidatas identifica
das) depende de o documento utilizado como fonte ser completo. Alm disso,
dependendo do estilo que foi utilizado para escrever esse documento, essa tc
nica pode levar identificao de diversas classes candidatas que no geraro
classes. Pior que isso, a anlise do texto de um documento pode no deixar ex
plcita uma classe importante para o sistema. Isso porque, em linguagem natu
ral, as variaes lingsticas e as formas de expressar uma mesma idia so
bastante numerosas.
Para contornar os problemas na identificao de classes atravs da anlise
textual, uma soluo aplicar outra tcnica para validar o que foi descoberto
inicialmente e para identificar novas classes.

5.4.2 Anlise dos casos de uso


Essa tcnica um caso particular da Anlise Textual de Abbott, descrita na Se
o 5.4.1. A anlise de caso de uso preconizada pelo processo de desenvolvi
mento denominado RUP (Ratonal Unified Process). Essa tcnica tambm
chamada de identificao dirigida por casos de uso. Na anlise dos casos de uso,
o MCU (ver Captulo 4) utilizado como ponto de partida. Conforme vimos
no Captulo 4, um caso de uso corresponde a um comportamento especfico
do sistema. Em um SSOO, esse comportamento somente pode ser produzido
por objetos que compem o sistema. Em outras palavras, a realizao de um
caso de uso responsabilidade de um conjunto de objetos que devem colabo
rar para produzir o resultado daquele caso de uso. Com base nisso, o modela
dor que aplica a tcnica de anlise dos casos de uso tenta identificar as classes
necessrias para produzir o comportamento que est documentado na descri
o do caso de uso.
A tcnica de anlise dos casos de uso aplicada como segue. O modelador
estuda a descrio textual de cada caso de uso para identificar classes candida
tas. Para cada caso de uso, seu texto (fluxos principal, alternativos e de exceo,
ps-condies e precondies etc.) analisado. Na anlise de certo caso de
uso, o modelador tenta identificar classes que possam fornecer o comporta
mento do mesmo. Na medida em que os casos de uso so analisados um a um,
as classes do SSOO so identificadas. Quando todos os casos de uso tiverem
sido analisados, todas as classes (ou pelo menos a grande maioria delas) tero
sido identificadas.
A justificativa para essa tcnica que a existncia de uma classe s pode se
justificar se ela participar de alguma forma do comportamento externamente
140 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

visvel do sistema. Dessa forma, o modelo de classes obtido a partir da descri


o dos casos de uso.
De forma resumida, os passos na anlise de casos de uso podem ser descritos
da seguinte forma:

Suplemente as descries dos casos de uso. Esse passo envolve comple


mentar a descrio dos casos de uso com o objetivo de torn-los comple
tos e facilitar a identificao de todas as classes envolvidas no mesmo.
2 . Para cada caso de uso:
a. Identifique classes a partir do comportamento do caso de uso.
b. Distribua o comportamento do caso de uso pelas classes identifi
cadas.
3. Para cada classe de anlise resultante
a. Descreva suas responsabilidades.
b. Descreva atributos e associaes.
4. Unifique as classes de anlise identificadas em um ou mais diagramas de
classes.

Com relao ao passo de identificao das classes a partir do comportamen


to do caso de uso, h uma categorizao de objetos que pode servir como ponto
de partida para tal tarefa. Descrevemos essa categorizao na Seo 5.4.2.1.
Alm disso, a modelagem de interaes na fase de anlise se encaixa no contexto
da realizao dos passos descritos anteriormente. Descrevemos os diagramas de
interao no Captulo 7.

5.4,2.1 Categorizao BCE


Uma tcnica de identificao que pode ser combinada com a anlise de casos de
uso a Anlise de Robustez- Essa tcnica foi proposta por Ivar Jacobson (Jacob
son et a l , 1992) e posteriormente adotada pelo processo de desenvolvimento
denominado ICONIX (Rosenberg & Scott, 2001). De acordo com essa tcnica,
os objetos que compem um SSOO podem ser divididos em trs categorias: ob
jetos de fronteira, objetos de controle e objetos de entidade. Chamamos essa cate
gorizao de BCE (para lembrar os nomes originais das categorias: boundary,
control e entity). Essa categorizao fornece uma espcie de arcabouo que
podemos tomar como ponto de partida para a identificao de classes em cada
caso de uso de um sistema.
No contexto do diagrama de classes, a UML fornece esteretipos (ver Seo
3.1) predefinidos, tanto textuais, quanto grficos, para cada categoria BCE. A
Figura 5-37 apresenta de forma esquemtica os modos de representar objetos
em cada uma dessas trs categorias.
MODELAGEM DE CLASSES DE ANLISE 141

D (!) Q
X Y Z

boundary control entity


X Y X

Figura 5-37: Notao da UML para objetos, segunda a categorizao BCE.

5.4.2.2 Objetos de fronteira


Objetos de fronteira realizam a comunicao do sistema com atores. Em ou
tras palavras, so objetos de fronteira que permitem ao sistema interagir com
seu ambiente. H trs tipos principais de classes de fronteira: as que realizam
a interface com o usurio (atores humanos), as que realizam a interface com
sistemas externos e as que realizam comunicao com dispositivos atrelados
ao sistema.
Para dar um exemplo, considere nosso estudo de caso do SCA (Sistema
de Controle Acadmico). Mais especificamente, analise o caso de uso Real i zar
Inseri o (ver Seo 4.7). Este caso de uso apresenta dois atores. Aluno e Siste
ma de Faturamento. Para que o sistema se comunique com esses atores, ne
cessrio que existam objetos para realizar essa comunicao. Por essa razo,
criamos as classes Formulrioinscrio e Si stemaFaturamento (consulte a Fi
gura 5.47).
Objetos de fronteira tm tipicamente as seguintes responsabilidades: (1)
notificar aos demais objetos os eventos gerados pelo ambiente do sistema e (2)
notificar aos atores o resultado de interaes entre os demais objetos. Em re
sumo, objetos de fronteira so especializados em realizar comunicao com o
ambiente do SSOO. Nomes de classes de fronteira no devem conter verbos
nem devem sugerir aes. Em vez disso, esse nome deve servir para lembrar
qual o canal de comunicao com o mundo externo que a classe representa.
Exemplos: Formulrioinscrio, Lei toraCartes, Si stemaFaturamento etc.
Objetos de fronteira se comunicam com atores e com controladores (ver Se
o 5.4.2.3). Normalmente existem somente durante a realizao do caso de
uso (isso particularmente verdadeiro para objeto de fronteira que correspon
dem a interfaces grficas com o usurio).
Cabe uma observao importante sobre objetos de fronteira: durante a an
lise da aplicao (ver Seo 2.1.2), o modelador deve abstrair os detalhes dessa
142 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

categoria de objetos. Isso significa que, durante a anlise, objetos de fronteira


devem ser considerados somente como o ponto de contato com o ambiente do
sistema. Em particular, os detalhes de como ser feita essa comunicao com o
ambiente (por interface grfica, por algum protocolo de comunicao etc.) de
vem ser ignorados na fase de anlise. O objetivo nesta fase identificar as classes
e suas responsabilidades em um nvel alto de abstrao, sem comprometer
eventuais solues tcnicas.

5.4.2,3 Objetos de controle


Um objeto de controle tambm chamado de controlador. Objetos de controle
servem como uma ponte de comunicao entre objetos de fronteira e objetos de
entidade. So responsveis por coordenar a execuo de alguma funcionalidade
especfica do sistema. Normalmente (embora no necessariamente), essa parte
do sistema corresponde a um caso de uso. Esses objetos decidem o que o siste
ma deve fazer quando ocorre um evento externo relevante. Eles realizam o con
trole do processamento; ou seja, servem como gerentes dos outros objetos
para a realizao de um ou mais cenrios de um caso de uso. Assim como obje
tos de fronteira, essa categoria de objetos tem vida curta: em geral, existem so
mente durante a realizao de um caso de uso.
Nomes normalmente utilizados para uma classe de eontrole devem lembrar
o caso de uso que a mesma responsvel por coordenar. Alguns exemplos de
nomes de classes de controle so: GerenciadorContas, Controladorinscrio,
ControladorReservasCarros, MarcadorTempo etc.
Algumas responsabilidades tpicas de objetos de controle so: (1) realizar
monitoraes, a fim de responder a eventos externos ao sistema (gerados por
objetos de fronteira); (2) coordenar a realizao de um caso de uso por meio do
envio de mensagens a objetos de fronteira e a objetos de entidade; (3) criar asso
ciaes entre alguns objetos de entidade (embora isso possa ser feito pelos pr
prios objetos de entidade; ver mais adiante); (4) manter valores acumulados ou
derivados durante a realizao de um caso de uso; (5) manter o estado da reali
zao do caso de uso.

5.4.2.4 Objetos de entidade


Um objeto de entidade representa um conceito encontrado no domnio do
problema (ver Seo 2.1.1). Normalmente servem como um repositrio
para alguma informao manipulada pelo sistema. Mas no somente isso.
Nessas classes que so alocadas as responsabilidades mais importantes do
sistema, a saber, as que dizem respeito lgica do negcio. Esses objetos so
encontrados durante a an lise de domnio (ver Seo 2.1.2). comum exis
tirem vrias instncias de uma mesma classe de entidade coexistindo no
MODELAGEM DE CLASSES DE ANALISE 143

sistema.^ Por exemplo, em um sistema de venda de produtos, possvel ha


ver milhares de objetos (instncias) da classe Produto.
Objetos de entidade frequentemente participam de vrios casos de uso e
tm um ciclo de vida longo (ou seja, armazenam informaes persistentes do
sistema). Por exemplo, um objeto Aluno pode participar na realizao dos casos
de uso Realizar Inscrio e Lanar Notas (ver o estudo de caso do SCA). Alm
disso, uma vez criado, esse objeto pode existir por diversos anos ou mesmo tan
to quanto o prprio sistema de que componente. (No entanto, alguns objetos
de entidade podem ter ciclo de vida curto e no ser persistentes.)
Algumas responsabilidades tpicas de objetos de entidade so as seguintes:
(1) informar valores de seus atributos a objetos requisitantes; (2) realizar clcu
los ou impor restries relativas s regras do negcio (ver Seo 4.5.1), normal
mente com a colaborao de objetos de entidade associados; (3) criar e destruir
objetos-parte (considerando que o objeto de entidade em questo seja um obje-
to-todo de uma agregao ou composio).

5.4.2.5 Categorizao BCE na identificao de classes


A categorizao proposta por Jacobson implica que cada objeto especialista
em realizar um dos trs tipos de tarefa, a saber: comunicar-se com atores (fron
teira), manter as informaes (entidade) ou coordenar a realizao de um caso
de uso (controle).
Pelo exposto nas Sees 5.4.2.2, 5.4.2.3 e 5.4.2.4, podemos concluir que a
categorizao BCE funciona como uma espcie de receita de bolo para identi
ficar objetos participantes da realizao de um caso de uso. Em particular, essa
tcnica preconiza que, para cada caso de uso, as seguintes regras podem ser apli
cadas na anlise:
1. Adicionar um objeto de fronteira para cada ator participante do caso de
uso. Dessa forma as particularidades de comunicao com cada ator do
caso de uso ficam encapsuladas no objeto de fronteira correspondente.
2. Adicionar um objeto de controle para o caso de uso. Isso porque um caso
de um representa um determinado processo do negcio. O controlador
de um caso de uso tem ento a atribuio de coordenar a realizao desse
processo do negcio.

A Figura 5-38 ilustra de forma esquemtica o que acontece quando os objetos


de um caso de uso de um SSOO so identificados conforme a categorizao BCE. O
ator se comunica com um objeto de fronteira, que repassa (pelo envio de mensa-

^ Esses objetos normalmente so armazenados em algum meio persistente. O Captulo 12 descreve


como esses objetos podem ser mapeados e armazenados em um banco de dados relacional.
144 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

gens) as aes desse ator para o objeto de controle (controlador). O controlador,


por sua vez, coordena a colaborao de um ou mais objetos de entidade para a reali
zao da tarefa desejada pelo ator. Note que, de acordo com o esquema dessa Figu
ra, os objetos de entidade tambm se comunicam entre si com o envio de mensa
gem. Note tambm que a realizao de uma tarefa pode envolver o envio de mensa
gens para outros objetos de fronteira, para que o sistema se comunique com outros
atores (por exemplo, outros sistemas) envolvidos no caso de uso em questo. Aps
a concluso da tarefa, o objeto de controle repassa o resultado para um objeto de
fronteira (que pode ser o mesmo no qual a realizao comeou, ou outro objeto).
Este objeto de fronteira, por sua vez, apresenta o resultado para o ator.

Figura 5-38: A realizao de um caso de uso envolve


objetos de fronteira, de controle e de entidade.

Classes de entidade, assim como seus atributos, so relativamente fceis de iden


tificar. Isso porque tipicamente correspondem a conceitos pertencentes ao domnio
do problema. Essas classes so identificadas na anlise do domnio. J as classes de en
tidade e de controle so normalmente identificadas na anlise da aplicao. (Para de
talhes acerca da anlise de domnio e da anlise da aplicao, ver Seo 2.1.2.)

5.4.3 Identificao dirigida a responsabilidades


Na tcnica de identificao dirigida a responsabilidades, a nfase est na identi
ficao de classes a partir de seus comportamentos relevantes para o sistema. O
esforo do modelador recai sobre a identificao das responsabilidades que cada
MODELAGEM DE CLASSES DE ANALISE 145

classe deve ter dentro do sistema. Esse mtodo foi proposto por Rebecca
Wirfs-Brock e Brian Wilkerson (Wirfs-Brock e Wilkerson, 1989). Nas palavras
desses autores: O mtodo dirigido a responsabilidades enfatiza o encapsula
mento da estrutura e do comportamento dos objetos. Ou seja, essa metodolo
gia utiliza o princpio do encapsulamento, descrito na Seo 1.2.3.1: a nfase
est na identificao das responsabilidades de uma classe que so teis externa
mente mesma. Os detalhes internos classe (como ela faz para cumprir suas
responsabilidades) devem ser abstrados.
Em um SSOO, os objetos encapsulam tanto dados quanto comportamento. O
comportamento de um objeto definido de tal forma que ele possa cumprir com
suas responsabilidades. Uma responsabilidade de um objeto uma obrigao que
este tem para com o sistema no qual ele est inserido. Graas s suas responsabili
dades, um objeto colabora com outros objetos para que os objetivos do sistema se
jam alcanados. Na prtica, uma responsabilidade algo que um objeto conhece ou
fa z (sozinho ou sendo ajudado por outro(s) objeto(s)). Como exemplo do conceito de
responsabilidade, considere um objeto Cliente. Esse objeto provavelmente conhece
seu nome, seu endereo, seu telefone etc. Considere um objeto Pedido; esse objeto
conhece sua data de realizao. Ele tambm deve fazer o clculo do seu valor total.

Um objeto cumpre com suas responsabilidades a partir das informaes que ele pos
sui ou das informaes que ele pode derivar de colaboraes com outros objetos.

Em alguns casos, um objeto tem uma responsabilidade com a qual ele no


pode cumprir sozinho. Nesses casos, o objeto deve requisitar colaboraes de
outros objetos do sistema para cumprir com a sua responsabilidade. Por exem
plo, quando a impresso da fatura de um pedido requisitada em um sistema de
vendas, vrios objetos precisam colaborar. O diagrama de classes da Figura 5-39
ilustra as classes de alguns objetos que esto envohidos nessa colaborao. Um
objeto Pedido pode ter a responsabilidade de fornecer o seu valor total; um obje
to Cl i ente fornece seu nome; cada ItemPedi do informa a quantidade do produto
correspondente e o valor de seu subtotal; os objetos Produto tambm colaboram
fornecendo seu nome e preo unitrio.
De uma forma geral, cada objeto tem um conjunto de responsabilidades den
tro de um SSOO. Esse objeto tem como cumprir sozinho algumas dessas respon
sabilidades. J para outras responsabilidades, o objeto necessita da colaborao
de outros objetos."^ Estes ltimos so seus colaboradores. A Figura 5-40 ilustra a
correspondncia entre classes (de objetos), responsabilidades e colaboraes.

4. atravs da troca de mensagens de um objeto a outro que essas colaboraes so acionadas para que as
funcionalidades do sistema estejam disponveis extemamente. A modelagem de mensagens entre objetos
descrita no Captulo 7.
146 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEN^ER

Figura 5-39: Objetos colaboram entre si para cumprir com suas responsabilidades.

Figura 5-40: Relao entre objetos, responsabilidades e colaboradores.

A identificao de classes dirigida a responsabilidades normalmente utiliza


uma tcnica que permite a participao de especialistas do domnio e analistas.
Essa tcnica, a modelagem CRC, descrita na Seo 5.4.3.1.

5.4.3.1 Modelagem CRC


A modelagem CRC (sigla para Classes, Responsabilidades e Colaboradores) foi
proposta em 1989 por Kent Beck^ e Ward Cunningham (Kent e Cunningham,
1989). A princpio, essa tcnica de modelagem foi proposta como uma forma de

5. Esse autor tambm o principal expoente de um processo de desenvolvimento que est se tornando
bastante famoso, o XP (sigla para Extreme Programming).
MODELAGEM DE CLASSES DE ANALISE 147

ensinar a iniciantes o paradigma da orientao a objetos. Contudo, a sua simpli


cidade de notao a tornou particularmente interessante para ser utilizada na
identificao de classes.
Essa tcnica se baseia fortemente no paradigma da orientao a objetos, em
que objetos colaboram uns com os outros para que uma tarefa seja realizada. Ela
eficaz quando profissionais que no tm tanta experincia com o paradigma
da orientao a objetos (o que normalmente o caso para especialistas do dom
nio) esto envolvidos na identificao de classes. A idia bsica dessa tcnica a
de que as responsabilidades atribudas a um SSOO devem, em ltima anlise,
ser atribudas aos objetos componentes do mesmo. Sendo assim, podemos par
tir das responsabilidades que atribumos ao sistema e, para cada uma delas,
identificar objeto para assumir com as mesmas (ver Figura 5-41).

Responsabilidades
Rj, R ^,..., R j,..., Rj, R,, R R Rn identificadas para o SSOO

Ri Ri Ri

M < + l> Ri+i> >Rm


Figura 5-41: As responsabilidades de um sistema de software orientado a objeto
devem ser alocadas aos objetos componentes do mesmo.

Essa tcnica til na identificao de novas classes e na validao das clas


ses identificadas mediante outras tcnicas (como, por exemplo, a anlise de ca
sos de uso). Na modelagem CRC, especialistas do domnio e desenvolvedores
trabalham em conjunto para identificar objetos, suas responsabilidades e cola
boradores. Para aplicar essa tcnica, esses profissionais se renem em uma sala,
onde tem incio uma sesso CRC.
Uma sesso CRC uma reunio que envolve cerca de seis pessoas. Entre os
participantes esto especialistas de domnio, projetistas, analistas e o modera
dor da sesso.
A cada pessoa entregue um carto de papel como o da Tabela 5-4.^ Esse
carto denominado carto CRC e mede aproximadamente lOcm x 15cm. Cada
carto corresponde a uma das classes do SSOO.

^De preferncia, cada participante deve ficar com nico carto. Isso faz com que o participante se identi
fique com a classe correspondente.
148 prin cpio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E E L S E V IE R

Tabela 5-5: Formato tpico de um carto CRC

Nome da classe

Responsabilidades Colaboradores
12 responsabilidade 12 colaborador
22 responsabilidade 22 colaborador

n-sima responsabilidade m-simo colaborador

A Tabela 5-6 ilustra um exemplo de carto CRC para a classe ContaBanc-


ria. A coluna de colaboradores desse carto foi definida em funo das respon
sabilidades alocadas classe.

Tabela 5-6: Carto CRC para a classe Conta Bancria

ContaBancria

Responsabilidades Colaboradores
1. Conhecer o seu cliente Cliente
2. Conhecer o seu nmero Transao
3. Conhecer o seu saldo
4. Manter um histrico de transaes
5. Aceitar saques e depsitos

Uma vez distribudos os cartes pelos participantes, um conjunto de cen


rios (ver Seo 4.1.1.4) de determinado caso de uso selecionado. Ento, para
cada cenrio desse conjunto, uma sesso CRC iniciada. (Se o caso de uso no
for to complexo, ele pode ser analisado em uma nica sesso.)
Note que um carto CRC dividido em vrias partes, conforme podemos
ver na Tabela 5-5. Na parte superior do carto, aparece o nome de uma classe. A
parte inferior do carto dividida em duas colunas. Na coluna da esquerda, o in
divduo ao qual foi entregue o carto deve listar as responsabilidades da classe.
Finalmente, na coluna da direita, o indivduo deve listar os nomes de outras
classes que colaboram com a classe em questo para que ela cumpra suas res
ponsabilidades.
normal j existirem algumas classes candidatas j identificadas para deter
minado cenrio (obtidas com a aplicao de outras tcnicas de identificao).^

^ classes candidatas iniciais tambm podem ser encontradas em entrevistas com o usurio, no docu
mento de requisitos, no modelo de regras do negcio etc.
MODELAGEM DE CLASSES DE ANALISE 149

A sesso CRC comea com algum dos participantes simulando o ator primrio
que dispara a realizao do caso de uso. medida que esse participante simula a
interao do ator com o sistema, os demais participantes encenam a colabora
o entre objetos que ocorre internamente ao sistema, para que o objetivo do
ator seja alcanado. Graas a essa encenao desempenhada pelos participantes
da sesso CRC, as classes, responsabilidades e colaboraes so identificadas.

Na modelagem CRC, as diversas responsabilidades de um SSOO so atribudas a


classes. Essa tcnica permite antropomorfizar o conceito de classe. Ou seja, obje
tos so verdadeiramente interpretados como entidades ativas que encapsulam
comportamento.

Durante uma sesso CRC, para cada responsabilidade atribuda a uma clas
se, o seu proprietrio (o indi\hduo ao qual foi alocado o carto correspondente)
deve questionar se tal classe capaz de cumprir a responsabilidade sozinha. Se
ela precisar de ajuda, essa ajuda dada por um colaborador. Os participantes da
sesso, ento, decidem que outra classe pode fornecer tal ajuda. Se essa classe
existir, ela recebe uma nova responsabilidade, necessria para que ela fornea
ajuda. Do contrrio, um novo carto (ou seja, uma nova classe) criado para
cumprir com tal responsabilidade de ajuda.
Uma classe pode participar em mais de um caso de uso. medida que os ce
nrios de casos de uso so encenados, as responsabilidades (e os colaboradores)
dessa classe vo se acumulando. Ou seja, as responsabilidades e os colaborado
res necessrios para a realizao dos cenrios aparecem de acordo com o desen
rolar da sesso CRC. Alm disso, durante uma sesso CRC, uma ou mais das se
guintes aes podem ser necessrias:

Adicionar uma responsabilidade identificada a uma classe j existente.


Criar uma classe para realizar uma responsabilidade identificada.
Mover responsabilidades quando uma classe se tornar muito complexa.

5.4.3.2 Dicas para atribuio de responsabilidades


Uma sesso CRC uma reunio bastante dinmica. Em cada encenao, res
ponsabilidades podem passar de um objeto para outro, novos objetos podem
ser criados para assumir outras responsabilidades, objetos preexistentes po
dem no ser mais necessrios etc. A seguir, descrevemos algumas dicas que
podem ser usadas durante uma sesso CRC para atribuir responsabilidades a
classes. Essas mesmas dicas devem ser seguidas durante a modelagem de intera
es (ver Captulo 7).
150 prin c pio s de a n lis e e pro jeto de s is t e m a s com UML, 2/E E L S E V IE R

Associe responsabilidades com base na especialidade da classe. Dependendo da espe


cialidade (fronteira, controle ou entidade) da classe, h um conjunto tpico de
responsabilidades com as quais ela deve cumprir (ver Seo 5.4.2.1). O modela
dor pode tomar esse conjunto comodDase para atriPmr respomthdadeTj
classes do sistema.

Distribua a inteligncia do sistema. A inteligncia do sistema deve ser uniformemen


te distribuda. Isso quer dizer que o conjunto de responsabilidades do sistema
deve ser distribudo o mais uniformemente possvel pelas classes. Com efeito,
uma classe no deve ser sobrecarregada com responsabilidades demais. Se isso
comear a acontecer com uma classe, considere a criao de outras classes para
assumirem algumas responsabilidades que pertencem classe sobrecarregada.
Uma quantidade pequena de classes complexas demais significa que as mesmas
encapsulam mais conhecimento (inteligncia) do que o desejado e so menos
reutilizveis. Por outro lado, uma quantidade maior de classes mais simples sig
nifica que cada classe encapsula uma frao menor da inteligncia do sistema e,
assim, so mais reutilizveis.
Como um exemplo, considere que a um objeto Pedido foi atribuda a res
ponsabilidade de conhecer o seu valor total. Para isso, necessrio que todos os
subtotais dos itens de pedido sejam calculados. Cada item de pedido pode ficar
responsvel por calcular o seu total e informar ao objeto pedido para que ele
faa a totabzao. Por sua vez, o item de pedido pode pedir ajuda ao objeto Pro
duto para que este calcule o seu valor unitrio (necessrio ao clculo do subto
tal). A situao pode ser resumida da seguinte forma:

1. Produto sabe o seu valor total.


2. ItemPedido sabe o seu subtotal.
3. Produto sabe o seu valor.

Nessa situao, cada classe fica com uma parte da responsabilidade relacio
nada tarefa de computar o valor total de um pedido. A inteligncia necessria
para o clculo desse valor distribuda pelo sistema.

Agrupe as responsabilidades conceitualmente relacionadas. Responsabilidades concei-


tualmente relacionadas devem ser mantidas em uma nica classe. Por exemplo,
as informaes (responsabilidades de conhecer) pertinentes a um cliente devem
estar definidas em uma classe Cliente, e no espalhadas por diversas classes. Da
mesma forma, mais adequado criar as classes chamadas Pedido e Fatura em
vez de uma nica classe para manter informaes sobre os dois conceitos. Essa
dica est diretamente relacionada com o conceito de coeso de uma classe, que
detalhamos na Seo 7.5.2.
MODELAGEM DE CLASSES DE ANALiSE 151

Evitar responsabilidades redundantes. Responsabilidades redundantes no devem


ser criadas. Se duas ou mais classes precisam de alguma informao, analise as
seguintes decises alternativas; criar uma nova classe ou escolher uma das clas
ses preexistentes para manter a informao. Em ambos os casos, a informao
fica em um nico lugar, e os outros objetos devem enviar mensagens para o ob
jeto que possui tal informao para obt-la.
A deciso de criar uma nova classe ou utilizar uma classe preexistente para
manter a informao deve ser tomada com cuidado. recomendvel que o mo
delador tente sempre reutilizar uma classe preexistente para atribuir uma res
ponsabilidade. No entanto, deve-se obseix^ar outra dica anterior: no se deve
adicionar uma responsabilidade que no esteja relacionada ao propsito da
classe; nesse caso, melhor criar uma nova classe.

5.4.4 Padres de anlise


Aps produzir diversos modelos para um mesmo domnio de problema, natu
ral que um modelador comece a identificar caractersticas comuns entre esses
modelos. Em particular, um mesmo conjunto de classes ou colaborao entre
objetos costuma recorrer, com algumas pequenas diferenas, em todos os siste
mas desenvolvidos para o domnio do problema em questo. Por exemplo,
quantos modelos de classes j foram construdos que possuem os conceitos
Cliente, Produto, Fornecedor, Departamento etc? Quantos outros j foram
construdos que possuam os conceitos Ordem de Compra, Ordem de Venda,
Oramento, Contrato etc.?
A identificao de caractersticas comuns um processo natural e acontece
em conseqncia do ganho de experincia do modelador em determinado
domnio de problema. Ao reconhecer processos e estruturas comuns em um
domnio de problema, o modelador pode descrever (catalogar) a parte essencial
dos mesmos, dando origem a um padro de software. Quando o problema cor
respondente a um padro de software acontecer, um modelador pode utilizar a
essncia da soluo descrita pelo padro (descrio essa possivelmente catalo
gada por outro modelador). A aplicao desse processo permite que o desenvol
vimento de determinado aspecto de um SSOO seja feito de forma mais rpida e
menos suscetvel a erros. Isso porque a reutilizao de uma mesma soluo j
comprovada anteriormente livra o modelador da tarefa de repensar (ou rein
ventar) tal soluo.
Um padro de software pode, ento, ser definido como uma descrio es
sencial de um problema recorrente no desenvolvimento de software. Padres de
Software vm sendo estudados h anos e so atualmente utilizados em diversas
atividades do desenvolvimento de um sistema, inclusive na anlise. Padres de
software utilizados na anlise so chamados padres de anlise. Um padro de
152 prin c pio s oe a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

anlise normalmente composto, entre outras partes, de um fragmento de dia


grama de classes que pode ser customizado para uma situao de modelagem
em particular.
Pois bem, a tcnica de identificao de classes pela utilizao de padres de
anlise consiste em identificar padres que podem ser aplicados modelagem
do SSOO em questo. Sendo assim, o que ocorre no uma identificao de
classes propriamente, mas, sim, a identificao de problemas cujas solues po
dem ser encontradas em padres de anlise.
Nos ltimos anos, padres de anlise vm sendo extensivamente estudados
e catalogados. Est fora do escopo deste livro um estudo detalhado sobre pa
dres de anlise. No entanto, com o objetivo de dar ao leitor um entendimento
em alto nvel sobre o assunto, nas prximas sees descrevemos alguns padres
de anlise existentes.

5.4.4.1 0 padro Party


O padro Party um dos padres documentados em (Hay, 1996). Tambm foi
descrito em (Fowler, 1997). Esse padro normalmente utilizado para repre
sentar componentes de uma organizao e os relacionamentos entre eles. Esse
padro trabalha com o conceito de parte (traduo para party). Uma parte uma
generalizao de uma pessoa ou de uma organizao de interesse para a aplica
o sendo modelada. A Figura 5-42 apresenta a estrutura de classes correspon
dente ao padro Party.
Na Figura 5-42, a classe Parte possui uma auto-associao que representa
relaes de subordinao: entre pessoas e organizaes, entre pessoas (por

Figura 5-42: O padro Party.


MODELAGEM DE CLASSES DE ANALISE 153

exemplo, quais as pessoas que supervisionam as outras), ou entre organizaes


(por exemplo, que organizaes so subsidirias de outras).
Embora no seja exibido na Figura 5-42, tanto Pessoa quanto Organizao
podem ter quaisquer atributos que sejam necessrios a uma aplicao particular
do padro Party. Note tambm a existncia da classe Emprego, que representa as
sociaes entre empregados (pessoas) e empregadores (organizaes). Essa
mesma classe Emprego est associada classe NomeaoCargo, e essa associao
permite identificar que empregados assumiram determinados cargos em quais
organizaes e em que perodos.

5.4.4.2 0 padro Metamodel


Considere um conjunto de itens quaisquer. Considere, ainda, que cada item
possui vrias propriedades. Um caso particular dessa situao o caso em que
uma classe possui um grupo (fixo) de atributos, mas, no caso geral, as proprie
dades de cada item podem ser diferentes das propriedades dos outros itens do
conjunto.
Por exemplo, analise os seguintes itens (neste caso, equipamentos): Moni
tor, Modem, Teclado e Processador. Obviamente, as propriedades desses produtos
no so as mesmas. desejvel criar no modelo um nico conceito para repre
sentar Produto, sem deixar de modelar as propriedades particulares de cada
tipo de produto. Uma possvel soluo para esse problema criar uma classe de
nominada Produto e criar diversas subclasses, uma para cada tipo de produto
existente. Dessa forma, cada subclasse representaria as propriedades particula
res do tipo de produto correspondente. Uma desvantagem dessa soluo que
novos produtos esto sempre aparecendo e outros desaparecendo, o que levaria
a uma freqente modificao na estrutura de modelagem.
Para complicar mais ainda, podem surgir situaes em que as propriedades
de um mesmo item podem variar com o tempo (ou seja, novas propriedades po
dem ser adicionadas, ou propriedades existentes podem ser removidas). Se a so
luo descrita no pargrafo anterior fosse utilizada, haveria muitas mudanas
no esquema do banco de dados, o que muito provavelmente acarretaria mudan
as nas aplicaes que utilizassem esse esquema.
O padro Metamodel permite a modificao da estrutura de um modelo
de objetos sem que o esquema desses objetos seja realmente modificado. O que
acontece que o esquema de classes representa um metamodelo. Esse padro
apresentado na Figura 5-43.
Vamos agora descrever o funcionamento do padro Metamodel. Para isso,
considere os equipamentos de computador citados no exemplo anterior. Consi
dere ainda que dimenses, velocidade de transferncia, quantidade de teclas e
velocidade so atributos de Monitor, Modem, Teclado e Processador, respectiva
mente. Atravs do padro Metamodel, esses atributos so representados como
154 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E ELS E\aER

Figura 5-43: O padro Metamodel.

instncias da classe Propri edade, cada item representado como uma instncia
da classe Item. Finalmente, a classe valor utilizada para representar o valor de
uma propriedade de determinado item.
Note que propriedades podem ser adicionadas (ou removidas) do metamo-
delo cuja base est no padro Metamodel. Por exemplo, para adicionar o atributo
formato ao item Moni tor (para indicar se o monitor possui tela plana ou no), bas
ta adicionar uma nova linha tabela correspondente ao mapeamento da classe
Propriedade. Note tambm que responsabilidade da aplicao apresentar os da
dos como se eles fossem atributos da instncia de Item. Pode haver inclusive uma
aplicao que permita que seus usurios adicionem (removam) atributos.

5.4.5 Outras tcnicas de identificao


Alm das tcnicas de identificao descritas nas sees anteriores, diversas ou
tras abordagens podem ser aplicadas com o objetivo de identificar as classes de
um SSOO. Um exemplo a utilizao de uma taxonomia de conceitos:

Conceitos concretos, como edifcios, carros, salas de aula etc.


Papis desempenhados por seres humanos, como professores, alunos,
empregados, clientes etc.
Eventos, ou seja, ocorrncias em uma data e em uma hora particulares,
como reunies, pedidos, aterrisagens, aulas etc.
Lugares, ou seja, reas reservadas para pessoas ou coisas, como escrit
rios, filiais, locais de pouso, salas de aula etc.
Organizaes, ou seja, colees de pessoas ou de recursos, como departa
mentos, projetos, campanhas, turmas etc.
Conceitos abstratos, isto , princpios ou idias no tangveis, como reser
vas, vendas, inscries etc.
MODELAGEM DE CLASSES DE ANALISE 155

Alm de estudar taxonomias de conceitos, uma boa abordagem analisar


tambm as funcionalidades e a documentao de sistemas similares no mesmo
domnio do problema. O estudo do vocabulrio dos especialistas do domnio
tambm uma boa fonte para identificao de classes.

5.4.6 Discusso
Nas sees anteriores, descrevemos diversas tcnicas para identificao de
classes. No entanto, uma questo que aflige diversos modeladores (tanto
iniciantes, quanto experientes) a seguinte: possvel aplicar as tcnicas
de modelagem de dados para identificao de classes? Talvez a principal
fonte para esta dvida seja a semelhana de notao que existe entre o dia
grama de entidade e relacionamentos (conhecida ferramenta de modela
gem de dados) e o diagrama de classes. Alistair Cockburn (Cockburn,
1996) descreve uma experincia que envolveu dois grupos de profissionais,
um de modelagem de dados e o outro de modelagem orientada a objetos.
Nessa experincia, foi requisitado aos dois grupos que elaborassem um
modelo de domnio para uma dada situao. Nessa experincia, Cockburn
constatou que os dois grupos produziram modelos similares, sob o aspecto
estrutural. No entanto, quando comparado o aspecto funcional (os profissio
nais de modelagem de dados utilizaram o DFD na experincia), os resulta
dos foram bastante diferentes.
De fato, a questo levantada no pargrafo anterior das mais complexas,
para a qual h respostas conflitantes na literatura. Posto isso, o que exponho nas
prximas linhas minha opinio sobre o assunto. A diferena mais significante
entre um modelo de dados e um modelo de objetos o fato de este ltimo repre
sentar o comportamento dos objetos, alm de seus dados.
Em minha experincia prtica em modelagem orientada a objetos, cons
tato que as entidades que seriam identificadas com a modelagem de dados
frequentemente so identificadas (sob a forma de classes) com a modelagem
orientada a objetos. Isso porque ambas as abordagens tm princpios seme
lhantes em relao ao que consideram um bom modelo do ponto de vista es
trutural. Mas outra constatao minha que objetos do domnio que tm um
vis mais comportamental dificilmente so identificados com a tcnica de
modelagem conceituai de dados. Isso se justifica pelo simples fato de essa
tcnica priorizar o aspecto dos dados relacionados a uma dada entidade do
mundo real. Alm disso, um modelo conceituai de dados representa a estru
tura esttica, enquanto modelos de classes representam uma fotografia (es
ttica) das estruturas (relacionamentos) que so criadas durante o compor
tamento dinmico do sistema. Alm disso, diferentemente do modelo con
ceituai de dados, algumas entidades representadas em um modelo de classes
156 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E E L S E V IE R

so transientes (ou seja, no vivem alm de uma sesso do sistema, arma


zenadas em um SGBD, por exemplo).
No se trata de afirmar que a modelagem conceituai de dados seja uma
tcnica ruim; o fato que ela deixa para outras tcnicas (por exemplo, a de
composio funcional com a ferramenta de Diagrama de Fluxos de Dados) a
responsabilidade de considerar o aspecto funcional do sistema que est sen
do modelado. Em minha opinio, no h nada de errado em aplicar as tcni
cas de modelagem conceituai de dados para construir o aspecto estrutural do
modelo de classes. No entanto, no se pode pensar que chegamos ao final da
tarefa quando tivermos feito isso. importante considerar tambm o aspec
to comportamental desse modelo. E isso deve ser feito com a aplicao de
tcnicas de identificao que levem em conta esse aspecto estrutural, algu
mas das quais foram descritas nesta seo (anlise textual de Abbott, anlise
de casos de uso, modelagem CRC).

Modelos de classes so perigosamente similares a modelos de dados. A maioria


dos princpios que resultam em um bom modelo de dados tambm resultam em um
bom modelo de classes. 0 perigo justamente desenvolver um modelo de classes
orientado a dados, em vez de orientado a responsabilidades.

Outro ponto importante; recomendvel que o modelador aplique duas


ou mais tcnicas de identificao durante a identificao de classes. O objeti
vo disso fazer com que a aplicao de uma tcnica valide a aplicao de ou
tra tcnica. A utilizao de mais de uma tcnica tambm permite descobrir
classes que seriam ignoradas se apenas uma tcnica fossem aplicada. Alm
disso, fundamental a participao de um ou mais especialistas do domnio
durante essa atividade. muito pouco provvel que um analista tenha co
nhecimento equiparvel a uma especialista no domnio de conhecimento
deste ltimo.
Uma primeira questo que podemos analisar como conciliar as tcnicas de
modelagem CRC com a anlise textual de Abbott. Ou seja, ser que essas duas
tcnicas podem ser aplicadas em conjunto para identificar as classes de anlise?
No meu entender, a resposta positiva. Isso pode ser feito em duas etapas. Em
uma primeira etapa, podemos identificar as classes mais bvias atravs da ATA
(podemos utilizar o documento de especificao de requisitos, descries de ca
sos de uso, manuais, enfim, quaisquer fontes de informao textual). Note que
na tcnica ATA, os verbos que indicam ao podem ser interpretados como res
ponsabilidades em potencial. As classes assim identificadas servem de base para
a segunda etapa, quando ocorre a aplicao da modelagem CRC. No incio de
uma sesso CRC, cada indivduo participante deve ser responsvel por ao me-
MODELAGEM DE CLASSES DE ANALISE 157

nos uma classe identificada pela aplicao da ATA. As vantagens dessa aborda
gem so duas. Em primeiro lugar, as classes identificadas atravs da ATA so va
lidadas pela aplicao da tcnica de modelagem CRC. Em segundo lugar, a ses
so CRC comea com um conjunto de classes (e possivelmente responsabilida
des) identificadas. Por fim, note que as tcnicas de anlise de casos de uso e mo
delagem CRC tambm podem ser combinadas, visto que a primeira um caso
especial da tcnica ATA.
O mesmo raciocnio que empregamos no pargrafo anterior para argumen
tar sobre a possibilidade de aplicao da ATA juntamente com a modelagem
CRC pode ser utilizado em relao a esta ltima e anlise de casos de uso. Em
particular, as responsabilidades de um sistema (que a modelagem CRC consi
dera como ponto de partida) podem ser vistas como os casos de uso identifica
dos para o mesmo. Portanto, outra estratgia vlida para identificao de classes
aplicar a anlise de casos de uso e, subseqentemente, validar os resultados
com a aplicao da modelagem CRC.
Ainda sobre a conciliao de tcnicas de identificao, at aqui tenho des
crito formas em que a modelagem CRC aplicada como forma de validao de
outra tcnica. Isso no quer dizer que essa tcnica seja menos importante que as
outras. Na verdade, justo comentar que h domnios em que a modelagem
CRC mais adequada e mais aplicvel que as outras. Por exemplo, na identifica
o de objetos para um jogo, para um sistema de automao, ou para um sistema
de tempo real, essa tcnica consegue de forma bastante mais natural capturar
todas as responsabilidades do sistema na forma de objetos.
importante tambm notar que as tcnicas de identificao de classes des
critas na Seo 5.3 normalmente so aplicadas de um modo iterativo. Iterativo
porque virtualmente impossvel para um modelador construir um modelo
perfeito da primeira vez. Em vez disso, o modelo de classes adequado para um
SSOO construdo por refinamentos sucessivos. Cada refinamento aperfeioa a
verso anterior do modelo.
Por ltimo, relevante fazer um comentrio acerca da diferena conceituai
que h entre as classes que definimos durante a modelagem de classes do dom
nio e durante a modelagem de classes da aplicao. Em um SSOO, razovel ca
tegorizar seus objetos em dois tipos: objetos do domnio e objetos da aplicao.
Com relao identificao de classes, quando estamos realizando a modela
gem de classe de domnio, normalmente ns descobrimos classes, no sentido de
que as classes que definimos so abstraes de entidades reais existentes no do
mnio. Por outro lado, quando estamos na modelagem de classes da aplicao,
normalmente inventamos classes. Isso porque as classes que definimos nessa ati
vidade no tm correspondente no domnio do problema (esse normalmente o
caso das classes de controle e de fronteira).
158 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

5.5 Construo do modeio de classes '


Aps a identificao de classes e atribuio de responsabilidades, o modelador
deve verificar a consistncia entre as classes para eliminar incoerncias e re
dundncias. Como dica, o modelador deve estar apto a declarar as razes de
existncia de cada classe identificada e, para cada classe, argumentar sobre a
existncia de cada uma de suas responsabilidades e de cada um de seus colabo
radores. Do contrrio, o modelador deve reconsiderar se a classe verdadeira
mente necessria.
Em seguida, os analistas devem comear a definir o mapeamento das res
ponsabilidades e dos colaboradores de cada classe para os elementos do diagra
ma de classes. Esse mapeamento gera um diagrama de classes que apresenta
uma estrutura esttica relativa a todas as classes que foram identificadas ante
riormente como participantes da realizao de um ou mais casos de uso. A se
guir, descrevemos o mapeamento de responsabilidades e colaboradores, levan
do em considerao os diversos elementos do diagrama de classes apresentados
na Seo 5.2.

5.5.1 Definio de propriedades


Uma propriedade um nome genrico que se aplica aos membros de uma clas
se, tanto atributos, quanto operaes. Uma questo importante acerca de
como podemos mapear (transformar) responsabilidades atribudas a uma clas
se para propriedades da mesma.
Com relao s operaes, elas correspondem a um modo mais detalhado
de explicitar as responsabilidades e fa z er de uma classe. Uma operao tam
bm pode ser vista como uma pequena contribuio da classe para uma tarefa
mais complexa representada por um caso de uso. Algumas operaes de uma
classe podem ser identificadas facilmente. No entanto, uma definio mais de
talhada e completa das operaes de uma classe s pode ser feita aps a constru
o dos diagramas de interao. Esses diagramas representam detalhes sobre a
ordem das colaboraes entre os objetos que participam da realizao de um
caso de uso. A descrio dos diagramas de interao e sua construo est no
Captulo 7. Portanto, inicialmente, devemos nos preocupar com a descrio
precisa das responsabilidades de cada classe, sem perdermos muito tempo com
detalhes sobre sua transformao em uma ou mais operaes; esses detalhes so
definidos na modelagem de interaes. Dito isso, no restante desta seo, est o
mapeamento de responsabilidades para atributos; enquanto o aspecto do deta
lhamento de operaes est nos captulos seguintes.
Normalmente uma responsabilidade de conhecer mapeada para atributos
ou para associaes. Essa tarefa de mapeamento relativamente fcil, uma vez
que estejam corretamente identificadas as responsabilidades de fazer e os co-
MODELAGEM DE CLASSES DE ANALISE 159
ELSEVIER

laboradores da classe (ver Seo 5.4.3). Aps mapear responsabilidades para


atributos, o modelador deve verificar se cada atributo possui as seguintes pro
priedades:

1. Guarda um valor atmico: normalmente um atributo armazena um va


lor atmico como quantidades, quantias, nomes de coisas etc. Exemplos
de valores atmicos: R$ 100.00, 5, 2.3, Joo da Silva.
2. No contm estrutura interna: esta caracterstica uma conseqncia
da caracterstica anterior. Se uma responsabilidade de conhecer possui
uma estrutura interna relevante para o sistema e se pertence ao domnio
do negcio, considere seriamente model-la como uma classe. Excees
so atributos que correspondem a seqncias de texto (string) ou a da
tas, que so mais adequadamente modelados como atributos (mesmo
que no modelo de classes de especificao esses atributos sejam transfor
mados em classes).
3. Aplica-se a todos os objetos da classe: cada atributo de uma classe deve
fazer sentido para todo e qualquer objeto dessa classe. Por exemplo, in
coerente ter 0 atributo salrio em uma classe Pessoa (pois nem toda pes
soa tem um salrio).

comum ao iniciante em modelagem de classes mapear uma responsabili


dade de conhecer como atributos, quando uma melhor modelagem seria ma
pe-la como uma associao. Por exemplo, considere a responsabilidade co
nhecer o seu cliente atribuda classe Pedi do. Considere tambm o mapeamen
to dessa responsabilidade para o atributo nomeCliente na classe Pedido. Nesse
caso, mais adequado criar uma associao entre Pedido e C liente, sendo que
esta ltima possui o atributo nome. De forma geral, se duas classes esto asso
ciadas, no h necessidade de criar um atributo em uma classe para fazer refe
rncia a informaes da outra. A Figura 5-44 ilustra um exemplo dessa confu
so entre atributos e associaes.
Outro erro comum para iniciantes em modelagem orientada a objetos a
utilizao de atributos de identificao; por exemplo, em uma classe Cl i ente, de
finir i dCl i ente como um atributo. Embora haja a necessidade de identificar uni
camente cada objeto de uma classe, o modelo de classes de domnio no o lu
gar para definir esse tipo de atributo. Nesse modelo, somente informaes que
existem no domnio do negcio devem ser definidas, e as caractersticas de im
plementao devem ser abstradas. Isso no quer dizer que atributos que corres-

Talvez esse erro comum esteja associado correlao que as pessoas fazem com o modelo relacional, no
qual existe o conceito de chave estrangeira (ver Seo 12.2). No entanto, esse um conceito que no deve
ser utilizado no modelo de classes.
160 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEMER

Pedido
data Pedido
Cliente
nomeCliente data
nome
obterTotalO 1 0..^ obterTotalO

Figura 5-44: Confuso entre atributos e associaes.

pondem a identificadores naturais e que existem no domnio do negcio no


devam ser definidos. Exemplos desses atributos so CPF, cdigo (de um produ
to), nmeroMatrcula (de um aluno) etc.
Ainda sobre atributos, deve-se notar tambm que a sua definio para uma
classe dependente do contexto. Uma mesma classe, por exemplo. Pessoa, pode
ter atributos diferentes em sistemas diferentes. Para um sistema que mantm in
formaes sobre pessoas suspeitas de terem cometido crimes, os atributos dessa
classe poderiam ser; fotografia, altura, peso, libi, registro policial etc. J em um
sistema de recursos humanos que mantm informaes sobre os empregados de
uma companhia, os atributos poderiam ser: matrcula, salrio, data de contrata
o etc.

5.5.2 Definio de associaes


Na Seo 5.4.3, vimos que uma responsabilidade de conhecer pode ser mapeada
para uma associao. Por outro lado, o fato de uma classe possuir colaboradores
indica que devem existir relacionamentos entre estes ltimos e a primeira. Isso
porque um objeto precisa conhecer o outro para poder lhe fazer requisies.
Portanto, para criar associaes, verifique os colaboradores de uma classe, con
forme identificados pela tcnica de modelagem CRC. O raciocnio para definir
associaes reflexivas, ternrias e agregaes o mesmo, com a ressalva de que,
em uma agregao, a classe em questo o todo e o seu colaborador correspon
de parte.
Classes de associao (ver Seo 5.2.2.4) surgem a partir de responsabilida
des de saber (e, mais raramente, de responsabilidades defazer) que o modelador
no conseguiu atribuir a alguma classe exclusivamente. Nessas situaes, a so
luo criar uma classe associativa para que ela cumpra tal responsabilidade.
Por exemplo, considere a situao em que pessoas trabalham em projetos, for
mando uma associao de conectividade muitos para muitos. Se houver a ne
cessidade de conhecer quantas horas semanais cada pessoa trabalha em cada
um dos projetos, essa responsabilidade no pode ser atribuda classe Pessoa
exclusivamente, pois isso violaria as propriedades 2 e 3 de um atributo, defini
MODELAGEM DE CLASSES DE ANALISE 161

das na Seo 3.5.1 ( possvel haver pessoas que no estejam alocadas em proje
tos; alm disso, uma pessoa pode ter diversas cargas horrias diferentes, uma
para cada projeto no qual trabalhe). Um raciocnio anlogo se aplica atribui
o da responsabilidade em questo classe Projeto, que tambm no adequa
da para cumprir com a mesma. Portanto, h uma responsabilidade de conhecer
que no se aplica exclusivamente a nenhuma das classes envolvidas. A soluo
criar uma classe associativa para realizar essa responsabilidade de conhecer. A
Figura 5-45 ilustra essa situao.

Adequado
Inadequado

Trabalho
cargaHorria
-------------- 1-------------- '
I
trabalhador
Pessoa
Projeto I Pesso~l~ t j Projeto ]
cargaHorria
trabalhador

Figura 5-45; Definindo classes associativas para cumprir responsabilidades rfs.

5.5.3 Organizao da documentao


Uma vez que classes e suas responsabilidades e colaboradores tenham sido
identificados, esses elementos devem ser organizados em um ou mais diagra
mas de classes e documentados. O conjunto de todos os diagramas de classes
identificadas na anlise de um sistema, juntamente com sua documentao
(e eventuais diagramas de objetos; ver Seo 5.3), corresponde ao modelo de
classes de anlise.
Na diagramao, sempre que possvel, as classes devem ser posicionadas de
tal forma que as associaes sejam lidas da esquerda para a direita ou de baixo
para cima. Isso facilita a leitura, principalmente se o diagrama tiver de ser enten
dido por pessoas de cultura ocidental (onde se costuma ler da esquerda para a
direita e de cima para baixo).
A construo de um nico diagrama de classes para todo o sistema pode re
sultar em um diagrama bastante complexo. Uma alternativa criar uma viso de
classes participantes (VCP) para cada caso de uso. Uma VCP um diagrama de
classes cujas instncias (objetos) participam de um caso de uso. Se essa estrat
gia for adotada, a elaborao de cada caso de uso resulta em uma VCP. A Seo
5.7 ilustra um exemplo de uma VCP construda para um caso de uso.
As vises de classes participantes de cada caso de uso podem ser reunidas
para formar um nico diagrama de classes para o sistema como um todo. Se esse
diagrama ficar muito grande, o modelador pode optar por esconder as classes
de fronteira ou at mesmo as classes de controle. Uma ferramenta CASE que d
suporte a essa operao seria de grande ajuda para a equipe de desenvolvimen
162 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

to. Alm disso, o recurso de modularizao representado pelo mecanismo de


pacotes (ver Seo 3.5) tambm til. Descrevemos a construo de diagramas
de pacotes para classes no Captulo 11.
Alm do diagrama, as classes devem ser documentadas textualmente. Ini
cialmente, pode-se utilizar o prprio formato dos cartes CRC como documen
tao (considerando que esta tcnica de identificao utilizada). Adicional
mente, uma definio (de uma ou duas frases) deve ser fornecida para cada clas
se, assim como para cada um de seus atributos cujo significado no seja fcil de
inferir pelo nome. medida que o desenvolvimento evolui, adequado criar
um glossrio para definir os termos utilizados na construo dos modelos (ver
Seo 5.7.2).
Os nomes escolhidos para as classes devem estar no singular (pois uma
classe j representa vrios objetos), iniciando com letra maiscula. As classes
devem preferencialmente receber nomes provenientes do domnio, ou inspi
rados neste. As responsabilidades atribudas a cada classe (que resultam em
atributos e operaes) tambm devem receber nomes provenientes ou inspi
rados no domnio.
Por fim, tambm til adicionar uma seo de detalhes de implementao
ao modelo de classes, assim como para o modelo de casos de uso (ver Seo
4.4.3.14). Embora os detalhes de implementao no faam parte nem devam
ser considerados no modelo de classes de anlise, esses detalhes inevitavelmen
te surgem na mente dos analistas enquanto esto construindo esse modelo. Esta
seo de implementao serve como repositrio de idias e solues relativas ao
modelo de classes que podem ser utilizadas (ou mesmo descartadas) nas ativi
dades futuras do desenvolvimento.

5.6 Modelo de classes no processo de desenvolvimento


Em um desenvolvimento dirigido a casos de uso (ver Seo 4.6), aps a descrio
dos casos de uso essenciais, possvel realizar a identificao de classes. Nesse
ponto, uma ou mais das tcnicas de identificao de classes (descritas na Seo
5.4) podem ser aplicadas. Durante a aplicao dessas tcnicas, as classes identi
ficadas so refinadas para retirar inconsistncias e redundncias. Finalmente,
as classes so documentadas e o diagrama de classes inicial construdo, resul
tando no modelo de classes de anlise.
Depois que a primeira verso do modelo de classes de anlise est completa,
o modelador deve retornar ao modelo de casos de uso e verificar a consistncia
entre os dois modelos. Uma inconsistncia indica a existncia de algum erro no
modelo de casos de uso ou no modelo de classes. Um caso de uso em que no fo
ram identificados objetos, ou uma classe que no participa da realizao de al
gum caso de uso so exemplos de inconsistncias que devem ser eliminadas.
MODELAGEM DE CLASSES DE ANALISE 163

Pelo exposto anteriormente, pode-se notar que as construes do modelo


de casos de uso e do modelo de classes so retroativas entre si. Por exemplo, na
realizao de uma sesso CRC, novos casos de uso podem ser identificados, ou
pode-se identificar a necessidade de modificao de casos de uso preexistentes.
A Figura 5-46 ilustra a interdependncia entre a construo do modelo de casos
de uso e o modelo de classes. De fato, esta mais uma conseqncia do modo de
pensar orientado a objetos: detalhes so adicionados aos poucos, medida que
o problema entendido.

.^ F o rn e ce detalhes para refinar

Modelo de
Casos de Uso

Analisado para obter Modelo de Classes


Figura 5-46: Interdependncia entre o modelo de casos de uso e o modelo de classes.

Na Seo 2.3.2, descrevemos o ciclo de vida de desenvolvimento iterativo.


Nesse ciclo de vida, os artefatos de software so construdos aos poucos, iterao
aps iterao. Alm dessa caracterstica de construo incremental, os diversos
modelos do SSOO, quando construdos, fornecem informaes teis para refinar
os modelos preexistentes. Em relao ao modelo de classes de anlise, a coisa no
acontece diferente. Na construo deste, a nfase inicial recai em identificar os
objetos do domnio. Aps isso, alguns relacionamentos, atributos e mesmo ope
raes desses objetos podem ser identificados nesta fase. Em seguida, alguns ob
jetos da aplicao (particularmente objetos de fronteira e de controle) so tam
bm identificados na anlise. Entretanto qualquer elemento identificado na mo
delagem de classes de anlise est sujeito a modificaes e refinamentos, em fun
o das informaes obtidas com a modelagem dinmica. Primeiramente, a mode
lagem dinmica fornece detalhes adicionais que podem ser utilizados para refinar
os elementos j identificados do modelo de classes. Em segundo lugar, pode ser
que alguma classe ou responsabilidade importante para o sistema s venha a
ser descoberta quando o aspecto dinmico do sistema for considerado.
O aspecto dinmico de um SSOO representado pelo modelo de interaes e
pelo modelo de estados. A construo desses modelos possvel atravs de infor
164 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

maes obtidas com a construo do modelo de classes. Por outro lado, com a
construo desses modelos, o modelador obtm informaes suficientes para
retornar ao modelo de classes e refin-lo.
Assim como a modelagem esttica (modelagem de classes), a modelagem
dinmica tambm comea na fase de anlise. A modelagem dinmica repre
sentada pelo modelo de interaes e pelo modelo de estados. O modelo de intera
es objeto de estudo do Captulo 7. A descrio do modelo de estados est no
Captulo 10.
Para finalizar esta seo, um comentrio de vis um tanto filosfico. Podemos
perceber que no s um SSOO composto de entidades que colaboram entre si. A
prpria modelagem orientada a objetos tambm constituda de entidades (mo
delos) , cada uma colabora com informaes para a construo da outra. Sendo
assim, o aspecto dinmico depende do aspecto estrutural esttico, e vice-versa.
Nenhum mais importante que o outro; um serve para completar o outro.

5.7 Estudo de caso


Esta seo continua o desenvolvimento da modelagem do estudo de caso inicia
do na Seo 4.7. Aqui, apresentado o modelo de classes de domnio inicial des
se estudo de caso. Conforme descrito neste captulo, o processo de construo
do modelo de classes de domnio realizado por meio da anlise dos casos de
uso. Para cada um deles, os modeladores identificaram quais classes so neces
srias para que os resultados externamente visveis sejam obtidos.
Tome como exemplo o caso de uso denominado Realizar Inscrio. Confor
me mencionado na Seo 5.4.2.5, cada caso de uso tem, a princpio, um objeto
de fronteira para cada ator e um objeto controlador. Com base nessa heurstica,
as primeiras classes identificadas para o cenrio principal desse caso de uso fo
ram C on tro ladorlnscrio, Fo rm u lrioinscrio e Si stemaFaturamento. Essas
duas ltimas so classes de fronteira do sistema que realizam a interface com os
atores Al uno e Si sterna de Faturamento, respectivamente. Note que essas classes
de fronteira tm naturezas completamente diferentes. Uma corresponde pos
sivelmente a uma interface grfica com o usurio. A outra corresponde im
plementao de algum protocolo de comunicao. Entretanto, na anlise, no
devemos nos ater a esses detalhes. O importante identificarmos que tais clas
ses so necessrias para prover as funcionalidades (requisitos funcionais) do
sistema.
A identificao das classes de entidade envolvidas na realizao de certo
caso de uso se d mediante a aplicao de uma ou mais das tcnicas descritas na
Seo 5.4. Por exemplo, quando utilizamos a tcnica de anlise de casos de uso
(ver Seo 5.4.2), estudamos a descrio de cada passo do fluxo principal do
caso de uso em que o sistema realiza alguma ao. Cada um desses passos impli-
MODELAGEM DE CLASSES DE ANALISE 165

ca classes e responsabilidades dentro do sistema. Durante a identificao de


classes a partir do texto de um caso de uso, os fluxos alternativos e de exceo
devem tambm ser analisados. Por exemplo, atravs da anlise do fluxo alterna
tivo Incluso em lista de espera (ver Seo 4.7.3), identificamos a necessidade
da classe Li staEspera, responsvel por manter uma lista de alunos que esto es
perando pela abertura de mais uma oferta para uma determinada disciplina (ver
Figura 5-47). Note que essa classe nem mesmo mencionada no fluxo principal
do caso de uso, o que enfatiza a necessidade de avaliarmos todos os fluxos de um
caso de uso durante a identificao.

Figura 3-47: VCP para o caso de uso Realizar Inscrio.

A viso de classes participantes para o caso de uso Realizar Inscrio


apresentada na Figura 3-47. Alguns diagramas correspondentes s vises de
classes participantes de outros casos de uso do sistema so apresentados logo a
seguir. Como exerccio, o leitor convidado a elaborar as vises de classes
participantes que no so apresentadas aqui, com base nos casos de uso des
critos na Seo 4.7.3.
Note que os diagramas aqui apresentados no exibem atributos nem opera
es das classes. Embora o mapeamento de determinadas propriedades das
classes j possa ser feito neste momento, essa tarefa adiada para os captulos
seguintes, quando descrevemos o modelo de interaes (Captulo 7) e o mode
lo de classes de projeto (Captulo 8). Isso porque graas construo do mo
delo de interaes de um sistema que identificamos as operaes que uma classe
deve possuir.
166 prin cpio s DE ANALISE E PROJETO DE SISTEMAS COM UME, 2/E ELSEVIER

Outra caracterstica geral que podemos notar em cada VCP aqui apresenta
da que o objeto de fronteira associado ao ator primrio do caso de uso normal
mente contm o controlador do caso de uso.

Figura 5-48: VCP para o caso de uso Atender Listas de Espera.

Figu ra 3-49: VC P para o caso de uso Fornecer Disponibilidades.


^ - Ta
MODELAGEM DE CLASSES DE ANALiSE 167
ELSEVIER

boundary
FormulrioLanamentoAvaliaes

control
ControladorLanamentoAvaliaes
* 1
Professor
1 Aluno 1
Leciona
1
Apresenta
Registra Turma [OfertaDisciplina|- -|Disciplb
1
k

|Participao|

1
Recebe
0..1

|Avaliao|
Figura 5-30: Viso de classes participantes para o caso de uso Lanar Avaliaes e Frequncias.

boundary
IFormulrioVizualizaoAvatiaes

control jl
ControladorVizualizaoAvaliaes

1 Turma
Aluno
Composta

Registra OfertaDisciplina Disciplina

Participaao

0..1
IAvalia^
Figura 5-51: Viso de classes participantes para o caso de uso Visualizar Avaliaes e Frequncias.

Note que nos diagramas de classes representando vises de classes partici


pantes apresentados aqui, os nomes das associaes entre controladores e classes
de entidade e entre controladores e classes de fronteira no so apresentados. Isso
168 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

se justifica pelo fato de uma associao entre objetos controladores e demais obje
tos de um sistema no ser duradoura (s existe em tempo de realizao do caso de
uso) e normalmente tem uma mesma semntica bsica: a de que esses demais ob
jetos so coordenados pelo controlador para realizar alguma tarefa. Ainda sobre
essas associaes, note que as apresentamos aqui no incio de nosso estudo de
caso. Entretanto, a identificao dessas associaes realizada mediante a cons
truo do modelo de interaes, que estudamos no Captulo 7.
A Figura 5-52 apresenta um diagrama de classes em que somente so apre
sentadas as classes do domnio do problema, ou seja, as classes de entidade.
Esse diagrama corresponde a uma unificao das vises de classes participan
tes apresentadas anteriormente. Isso porque, conforme podemos perceber pe
las VCPs, diversas classes de entidades aparecem em mais deuma VCP. Entre
tanto, note que esse diagrama somente a verso inicial do modelo de classes
do SCA. Durante a fase de projeto, diversas outras classes surgem. No que ou
tro modelo de classes deva ser construdo; em vez disso, o que acontece que o
modelo de classes de anlise estendido para ser transformado no modelo de
classes de projeto.

Figura 5-52: Diagrama de classes que apresenta as classes de entidade do SCA.


MODELAGEM DE CLASSES DE ANALISE 169
ELSEVIER

5.7.1 Cartes CRC


Conforme vimos na Seo 5.4.3.1, outra tcnica para identificao de classes de
um sistema a modelagem CRC. Vimos tambm que a aplicao de uma tcnica
no exclui a outra. Portanto, nesta seo, apresentamos cartes CRC para os
principais cenrios dos casos de uso do SCA. Com a construo desses cartes,
chegamos a um conjunto de responsabilidades para cada classe do sistema. Os
cartes construdos durante as sesses CRC so apresentados a seguir.

Disciplina

Responsabilidades Colaboradores
1. Conhecer seus pr-requisitos Disciplina
2. Conhecer seu cdigo
3. Conhecer seu nome
4. Conhecer sua quantidade de crditos

ListaEspera

Responsabilidades Colaboradores
1. Conhecer a sua disciplina Disciplina
2. Manter os alunos em espera pela Aluno
abertura de vagas

Aluno

Responsabilidades Colaboradores
1. Conhecer seu nmero de registro Participao
2. Conhecer seu nome
3. Conhecer as disciplinas que j cursou

Participao

Responsabilidades Colaboradores
1. Conhecer sua oferta de disciplina OfertaDisciplina
3. Conhecer sua avaliao Avaliao

Turma

Responsabilidades Colaboradores
1. Conhecer o seu cdigo OfertaDisciplina
2. Conhecer as disciplinas que oferece
170 prin c pio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E E L S E V IE R

O fe rta D iscip lin a

R e sp o n sa b ilid a d e s C o la b o ra d o re s

1. Conhecer a sua situao Disciplina


2. Conhecer sua turma Turma
3. Conhecer a sua disciplina Professor
4. Conhecer o ano e o semestre letivo em que acontece Aula
5. Conhecer dias, horrios e salas de aula em que acontece
6. Conhecer sua quantidade mxima de alunos
7. Conhecer seu professor

C o n tro la d o rln s c ri o

R e sp o n sa b ilid a d e s C o la b o ra d o re s

1. Conhecer as disciplinas de um semestre letivo Aluno


h -

2. Procurar uma turma disponvel para inscrever um aluno Disciplina


em uma disciplina
3. Conhecer as ofertas para uma disciplina OfertaDisciplina
4. Verificar a possibilidade de inscrio de aluno em uma ListaEspera
disciplina
5. Informar ao aluno os detalhes de sua inscrio em uma SistemaFaturamento
disciplina
6. Inserir um aluno na lista de espera de uma disciplina

F o r m u l rio in s c ri o

R e sp o n sa b ilid a d e s C o la b o ra d o re s

1. Receber requisies de inscrio de um aluno Controladorinscrio


2. Exibir uma lista de disciplinas nas quais um aluno pode
se inscrever
3. Exibir os resultados de inscrio de um aluno

Todas as responsabilidades identificadas durante a modelagem CRC de


vem ser alvo de validao durante a modelagem de interaes do sistema. No
Captulo 7, estudamos essa atividade to importante da modelagem de um
SSOO e descrevemos sua correlao com as responsabilidades identificadas
pela modelagem CRC.
MODELAGEM DE CLASSES DE ANALISE 171
ELSEVIER

5.7.2 Glossrio
Os termos relevantes do domnio, a maioria deles correspondentes a classes
identificadas, foram definidos no glossrio do SCA. A definio inicial desse
glossrio apresentada a seguir:

1. Aluno: representa um aluno da faculdade.


2. Aula: representa o acontecimento semanal de uma aula de alguma oferta
de disciplina. Toda aula acontece em uma sala da faculdade.
3. Avaliao: representa uma avaliao atribuda participao de um alu
no em uma turma que oferece alguma disciplina da faculdade.
4. Disciplina: uma disciplina componente da grade curricular da faculdade.
5. Grade de Disponibilidades: representa a grade de dias da semana e os
respectivos horrios no semestre letivo seguinte ao atual nos quais um
professor est disponvel para lecionar na faculdade. Representa tambm
as disciplinas que o professor est apto a lecionar nesse mesmo semestre
letivo.
6. Grade Curricular: uma grade curricular corresponde a um conjunto de
disciplinas, juntamente com os pr-requistos de cada uma delas. De tem
pos em tempos, a instituio de ensino atualiza a sua grade curricular.
Nessa atualizao, novas disciplinas podem ser criadas, assim como dis
ciplinas existentes podem ser removidas da grade.
7. Lista de Espera: representa uma lista dos alunos que esto esperando
que uma certa disciplina seja oferecida em alguma turma.
8. Oferta de disciplina: representa a alocao de uma disciplina em alguma
turma.
9. Participao: representa a participao de um aluno em alguma discipli
na ofertada pela faculdade. A participao de um aluno em uma oferta de
disciplina possui uma avaliao.
10. Professor: representa o indivduo que leciona as disciplinas ofertadas
pela faculdade.
11. Sala: representa um dos locais da faculdade que podem ser utilizados
para as aulas de uma ou mais disciplinas ofertadas pela faculdade.
12. Turma: representa uma turma aberta em algum semestre letivo da facul
dade. Uma turma possui diversas disciplinas ofertadas.
13. Dirio de Classe: corresponde a um formulrio que contm os nomes
dos alunos inscritos em determinada oferta de disciplina. Nesse formu
lrio, o professor lana a quantidade de faltas e as avaliaes de cada
aluno.
172 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

exerccios

5-1 : Descreva a posio do diagrama de classes no processo de desenvolvimento incrementai e


iterativo. Quando eles so utilizados? Para que so utilizados?

5-2: Considere a tcnica CRC. Discuta a relao existente entre as dimenses espaciais usuais
de um carto CRC e a distribuio quase uniforme das responsabilidades.

5-3: Construa o modelo de classes de domnio de um sistema de informaes para controlar o


campeonato da Frmula 1.

5-4: Desenhe um diagrama de classes com relacionamentos, nomes de papis e multiplicida


des para as seguintes situaes:

Uma Pessoa pode ser casada com outra Pessoa.


Uma Disciplina pr-requisito para outra Disciplina.
Uma Pea pode ser composta de diversas outras Peas.

5-5: Considere o diagrama de classes a seguir, que exibe uma classe associativa entre as clas
ses Pessoa e Empresa. Crie um diagrama de classes equivalente ao fornecido a seguir, mas sem
utilizar uma classe associativa.

5-6: Construa um diagrama de classes inicial para a seguinte situao: Pacotes so enviados de
uma localidade a outra. Pacotes tm umpeso especfico. Localidades so caracterizadas pelas fa
cilidades de transporte (por exemplo, rodovirias, aeroportos e auto-estradas). Algumas localida
des so vizinhas, isto , existe uma rota direta de transporte entre tais localidades. A rota de trans
porte entre as localidades tem um certo comprimento (a distncia entre as localidades). Trens,
avies e caminhes so usadospara o transporte depacotes. Cada umdestes meios de transporte
pode suportar uma carga mxima de peso. A cada momento, durante o seu transporte, necess
rio saber a posio (localidade) de cada pacote. Tambm necessrio manter o controle de que
meio de transporte est sendo utilizado em cada parte da rota para um certo pacote.

5-7: Considere o seguinte discurso relativo a um sistema de partidas de tnis: "Num torneio de
tnis, cada partida jogada entre dois jogadores. Pretende-se manter informao sobre o nome
e a idade dos jogadores; data da partida e atribuio dos jogadores s partidas. 0 mximo de
partidas que um jogador poder realizar so seis e o mnimo uma". Desenhe o diagrama de cias
ses correspondente.
MODELAGEM DE CLASSES DE ANALISE 173

5-8: Desenhe um diagrama equivalente ao da Figura 5-10 de duas formas:


a) Utilizando uma classe ordinria para substituir a classe associativa.
b) Utilizando uma associao ternria.
5-9: Identifique classes e/ou relacionamentos a partir das seguintes regras do negcio:
a) Pedidos so compostos de vrios itens de pedido.
b) Um item de pedido diz respeito a um e exatamente um produto.
c) Um pedido pode conter at 20 itens.

5-10: Considere um sistema de software para controlar um hotel. Normalmente, um hspede ocu
pa um quarto por estada. Mas, suponha que uma nova regra foi criada no negcio: agora, um hs
pede pode utilizar at trs quartos. Desenhe o diagrama de classe para essas duas situaes.

5-11 : Reflita sobre a seguinte afirmao: "0 tamanho do carto CRC ajuda a limitar e a restringir
a complexidade das classes identificadas nas sesses CRC."

5-12: Reflita e discuta com algum colega sobre a seguinte afirmao: "Atributos so similares a
associaes. Um atributo de uma classe apenas uma notao para associ-la a um conceito
que tem um valor atmico."

5-13: A seguir, so enumeradas diversas responsabilidades tpicas de serem encontradas em


objetos de um sistema de software. Discuta qual das categorias de objetos (fronteira, controle
ou entidade) mais adequada para cumprir cada uma dessas responsabilidades:
a) Criao ou destruio de um objeto.
b) Formao ou destruio de associaes entre objetos de entidade.
c) Obteno ou modificao de valores de atributos de um objeto de entidade.
d) Exibio de mensagens para o ator.
e) Realizao de clculos complexos.

5-14: Considere as instncias das classes do diagrama exibido abaixo.

Para o diagrama de classes apresentado, qual das seguintes situaes so possveis?


174 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

1. el contm um dl, o qual contm um e2, o qual contm um b2.


2. a1 contm um c1, o qual contm um dl.
3. b1 contm um dl, o qual contm um e2 .
4. c1 contm um a1, o qual contm b1.

5-15: Considere o diagrama de classes a seguir. H como construir um modelo equivalente,


sem 0 uso de gen/spec? Qual seria a vantagem dessa transformao?

Pessoa
nome
dataNascimento

0 atributo status define se o ^ A


cliente comum ou especial.

Cliente Empregado
status matrcula
Empresa J ~ dataContratao
razoSocial
1
Vendedor
taxaComisso

5-16: Analise os dois fragmentos de diagrama de classes a seguir. Eles so equivalentes? Expli
que sua resposta.
6
Passandodaanlise aoprojeto

H duas maneiras de fazer o projeto de um sistema de software.


Uma delas faz-lo to simples que obviamente no h deficincias.
E a outra faz-lo to complexo que no h deficincias bvias.
O primeiro mtodo de longe o mais difcil.
- C.A.R. Hoare

o desenvolvimento de sistemas orientados a objetos, a mesma repre

N sentao utilizada durante a anlise e o projeto: o modelo de classes


utilizado para representar a estrutura das classes do sistema em am
bas as fases.^ A vantagem disso que h uma uniformidade na modelagem do
sistema durante o desenvolvimento, ao contrrio do que acontece no desenvol
vimento de sistemas que utilizam a metodologia de Anlise e Projeto Estmtura-
dos, que utiliza na modelagem vrias notaes diferentes.
No entanto, essa uniformidade de representao tem a desvantagem de tor
nar bem menos ntida a separao entre o que feito na anlise e o que feito no
projeto. Alm disso, a utilizao de um processo de desenvolvimento iterativo
torna ainda mais difcil essa separao. H uma quantidade significativa de tare
fas no desenvolvimento de um sistema orientado a objetos que se situa em uma
rea difusa entre a anlise e o projeto. Pode-se dizer que a anlise vai se transfor
mando em projeto medida que o desenvolvimento evolui. Em um processo de
desenvolvimento iterativo aplicado a um SSOO, a anlise precede o projeto.
Entretanto, anlise e projeto podem estar acontecendo simultaneamente.

* Note que aqui o termo/ase utilizado para denotar anlise e projeto. Mas importante no confundir
com o significado do termo/aseutilizado na descrio do processo de desenvolvimento iterativo e incre
mental.
176 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

De qualquer forma, o modelo de classes de anlise e o modelo de casos de


uso so dois dos artefatos construdos na fase de anlise de uma iterao em um
processo de desenvolvimento incremental. Na modelagem de classes de anlise,
estamos interessados em identificar as classes do SSOO. J no projeto, o interes
se recai sobre refinar essas classes. Sendo assim, mesmo que a anlise e o projeto
trabalhem sobre o mesmo modelo, essas atividades se distinguem pela quanti
dade de detalhes que so includos nesse modelo.
O modelo de interaes tambm deve comear na fase de anlise para repre
sentar os aspectos dinmicos do sistema. Esse modelo comea a ser construdo
j na anlise quando se utiliza alguma tcnica de identificao de classes, como
a modelagem CRC. Esse modelo refinado posteriormente na fase de projeto
com a construo dos diagramas de interao para os cenrios relevantes dos
casos de uso.
Os modelos construdos na anlise esclarecem o problema a ser resolvido.
No entanto, as perspectivas do sistema fornecidas por esses modelos no so su
ficientes para se ter uma viso completa do sistema para que a implementao
comece. Antes disso, diversos aspectos referentes soluo a ser utilizada de
vem ser definidos. na fase de projeto (ver a Seo 2.1.3) de uma iterao que
essas definies so realmente feitas. O projeto uma etapa para definir a solu
o do problema relativo ao desenvolvimento do SSOO. O objetivo encontrar
alternativas para que o sistema atenda aos requisitos funcionais, ao mesmo tem
po que respeite as restries definidas pelos requisitos no-funcionais. Alm dis
so, essa etapa deve aderir a certos princpios para alcanar uma qualidade dese
jvel no produto de software final. As principais atividades realizadas na fase de
projeto so enumeradas a seguir. Aps a realizao dessas atividades, os mode
los estaro em um nvel de detalhamento grande o suficiente para que o sistema
possa ser implementado.

1. Detalhamento dos aspectos dinmicos do sistema.


2. Refinamento dos aspectos estticos e estruturais do sistema.
3. Detalhamento da arquitetura do sistema.
4. Definio das estratgias para armazenamento, gerenciamento e persis
tncia dos dados manipulados pelo sistema.
5. Realizao do projeto da interface grfica com o usurio.
6. Definio dos algoritmos a serem utilizados na implementao.

Por serem muito extensos os tpicos que abordam as atividades enumera


das anteriormente esto divididos em vrios captulos seguintes neste livro.
Este captulo fornece ao leitor uma viso geral desses tpicos. Antes de apresen
tar essa viso geral, importante deixar claro que os prximos captulos no tra
tam exclusivamente de atividades da fase de projeto. Algumas atividades relati-
PASSANDO DA ANALISE AO PROJETO 177
ELSEVIER

vas anlise ainda so descritas. Por exemplo, nos prximos captulos, descre
vemos a modelagem de interaes (atravs do diagrama de interaes, do dia
grama de estados e do diagrama de atividades), que tambm uma atividade
que comea na fase de anlise de um SSOO.

6.1 Detalhamento dos aspectos dinmicos


Na modelagem de classes de anlise, considera-se uma pequena parte dos as
pectos dinmicos do sistema. Isso acontece quando os modeladores utilizam
tcnicas de identificao de classes como a modelagem CRC (ver a Seo
5.4.3.1). Isso porque as sesses CRC simulam a colaborao entre objetos na
realizao de um caso de uso. Embora o estudo dos aspectos dinmicos do
sistema j comece na etapa de anlise, na fase de projeto que esse estudo se
concretiza e onde se realiza o detalhamento das colaboraes nas quais cada
classe participa.
Para fazer o detalhamento desse aspecto dinmico, o modelo de interaes, o
modelo de estados e o modelo de atividades do sistema devem ser construdos.
Esses modelos so descritos nos Captulos 7, 9 e 10, respectivamente. As ativi
dades de construo desses modelos so conhecidas em conjunto como modela
gem dinmica do sistema.

6.2 Refinamento dos aspectos estticos e estruturais


o modelo de classes de anlise descreve as classes do sistema em um nvel alto
de abstrao, atravs da definio de suas responsabilidades. A passagem do
modelo de anlise para o modelo de projeto no to direta. Por exemplo, pode
haver uma classe de anlise que resulte em vrias classes de projeto. Embora
seja uma situao mais rara, pode tambm haver classes de anlise que resultem
em uma nica classe de projeto. Pode tambm ser o caso de uma classe de anli
se ser transformada em diversas classes de projeto. De qualquer forma, tanto
para classes que sobrevivem passagem para o modelo de projeto, quanto para
as classes criadas durante esta transio, vrios detalhes devem ser definidos.
Esses detalhes tm o objetivo de obter um modelo suficientemente completo
para que a implementao de classes possa ser feita a partir dele.
O detalhamento dos aspectos dinmicos do sistema gera material (informa
es) para refinar os aspectos esttico e estrutural definidos no modelo de clas
ses de anlise. Dessa atividade resulta o modelo de classes de projeto. Nessa ati
vidade, so especificados em detalhes os aspectos estrutural e estticos do mo
delo de classes: os atributos, as operaes e as associaes de cada classe do sis
tema. Em particular, as responsabilidades de uma classe devem ser representa
das por atributos e operaes a serem definidos na mesma. O detalhamento de
178 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

atributos e operaes de classes descrito no Captulo 8, no qual tambm se des


creve o detalhamento das associaes existentes entre objetos.
O modelo de classes de anlise tambm pode ser refinado pela identificao
de similaridades entre as classes existentes. Esse refinamento feito pelo uso de
relacionamentos de generalizao e especializao. No Captulo 5, descrevemos
sucintamente o relacionamento de generalizao/especializao. Vimos que
esse relacionamento til quando queremos fatorar caractersticas e comporta
mentos comuns a um grupo de classes. No entanto, quando passamos a consi
derar detalhes da soluo na fase de projeto, diversos aspectos relativos ao rela
cionamento de generalizao/especializao devem ser definidos. Descrevemos
esses aspectos tambm no Captulo 8.
De uma forma geral, o projeto de um sistema a atividade em que diversos
detalhes devem ser adicionados aos modelos. Alguns conceitos que tambm
abordamos no Captulo 8 e que so fundamentais durante o detalhamento dos
modelos provenientes da anlise so: polimorfismo, classificao dinmica,
classes abstratas, interfaces e padres de projeto.

6.3 Projeto da arquitetura


Outro aspecto a considerar na modelagem de um SSOO a forma como esse sis
tema pode ser logicamente decomposto em seus diversos subsistemas. A de
composio lgica de um sistema diz respeito disposio das camadas de soft
ware que compem o mesmo.
Por outro lado, nos dias atuais, comum o desenvolvimento de aplicaes
distribudas, ou seja, sistemas cujos componentes esto fisicamente distribu
dos por diversos ns de processamento (ou processadores). Se existem vrios
ns de processamento disponveis para a execuo de um sistema, a forma
como o sistema deve ser fisicamente distribudo por esses diversos ns tambm
relevante e deve ser considerada em sua modelagem.
Damos o nome de arquitetura forma como um sistema est disposto e sub
dividido, fsica e logicamente. O projeto arquitetural de um sistema a ativida
de do processo de desenvolvimento na qual a arquitetura desse sistema defini
da. Aspectos importantes a serem definidos no projeto de arquitetura so sub
sistemas, interfaces, camadas de software e dependncias entre subsistemas.
Essas questes relativas s arquiteturas fsica e lgica de um sistema so aborda
das no Captulo 11.
A definio da arquitetura de um SSOO tambm envolve a definio de
meios pelos quais os objetos possam se comunicar por mquinas diferentes.
(Essa questo relevante no contexto de sistemas de arquitetura distribuda.)
Envolve tambm a escolha de componentes reutilizveis (como frameworks e
hihliotecas) a serem utilizados durante a implementao.
PASSANDO DA ANALISE AO PROJETO 179

6.4 Persistncia de objetos


Outro aspecto importante no projeto de um SSOO relativo forma pela qual ob
jetos desse sistema so persistidos. Nesse contexto, h dois tipos de objeto em um
SSOO: objetos persistentes e objetos transientes. Esses ltimos so aqueles cujo
tempo de vida o de uma sesso de uso do sistema. Ou seja, objetos transientes
simplesmente desaparecem quando o processo que os criou termina.
A diferena do que acontece com os objetos transientes, os objetos persis
tentes devem existir por vrias sesses do sistema. Para objetos que devem ser
persistentes, a questo que se pe como manter suas informaes do sistema
entre sesses de uso do mesmo. Na prtica, um SSOO precisa controlar vrios
aspectos relativos a objetos persistentes. Alguns desses aspectos so enumera
dos a seguir.

Como as transaes so controladas.


Quando e como objetos persistentes devem ser enviados para o mecanis
mo de armazenamento persistente.
Quando e como os objetos persistentes devem ser lidos do mecanismo de
armazenamento persistente.
Quando e como os objetos persistentes so removidos.

Examinamos mais a fundo as questes sobre a persistncia de objetos no Ca


ptulo 12, no qual apresentamos uma discusso acerca das principais estratgias
de mapeamento de objeto relacional existentes. No entanto, damos especial im
portncia estratgia de persistncia que usa um sistema de gerenciamento de
bancos de dados relacional. So apresentadas questes relativas ao mapeamento
de classes para um sistema de gerncia de banco de dados relacional. Em parti
cular, descrevemos o uso de um framework de mapeamento objeto-relacional
durante o desenvolvimento de um SSOO.

6.5 Projeto de interface grfica com o usurio


Uma caracterstica importante sobre modelos de casos de uso que associa
es entre casos de uso e atores implicam a necessidade de interfaces. Quando
o ator um ser humano, so necessrios, ento, telas (formulrios), relatrios
etc., para dar suporte associao. O projeto da interface grfica do usurio
uma atividade cujo objetivo definir a aparncia do sistema relativamente aos
seus usurios. Nessa atividade, o objetivo principal definir um sistema de
alta usabilidade e facilidade de operao. Outros objetivos importantes nessa
atividade so: padronizao de cores, padronizao de mensagens de erro, pa
dronizao das dimenses dos controles grficos, formatao para entrada de
dados etc.
180 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

No escopo desse livro o detalhamento de aspectos relativos ao projeto da


interface grfica de um sistema. Na verdade, h toda uma teoria desenvolvida na
rea de pesquisa denominada Interface Homem-Mquina (Human-Machine
Interface). No entanto, importante notar que o projeto da interface grfica de
um sistema uma etapa fundamental, visto que a correta realizao dessa ativi
dade resulta na qualidade da parte visvel do sistema. Este ponto crtico para o
projeto e pode determinar o sucesso ou total fracasso do produto de software.

6.6 Projeto de algoritmos


o projeto de algoritmos outra atividade da atividade de projeto. Aspectos que
influenciam na escolha dos algoritmos para implementar um sistema so; (1)
complexidade computacional, (2) facilidade de entendimento, e (3) flexibilida
de. A especificao desses algoritmos pode ser feita tanto formal quanto infor
malmente. O diagrama de atividades da UML pode ser utilizado durante essa es
pecificao (ver Seo 10.2.3). Neste livro, no tratamos de detalhes do projeto
de algoritmos. Para mais detalhes sobre o assunto, recomendamos a referncia
(Szwarcfiter e Markenzon, 1994).
7
Modelagemdeinteraes
Somente aps a construo de diagramas de interao para os cenrios de
um caso de uso, pode-se ter certeza de que todas as responsabilidades que
os objetos devem cumprir foram identificadas.
-IVAR JACOBSON.

m captulos anteriores, dois modelos so descritos: o modelo de casos

E de uso e o modelo de classes de anlise. Vamos resumir o que esses dois


modelos fornecem de informao acerca do sistema.
O modelo de casos de uso descreve quais os requisitos funcionais do sistema
e quais so as entidades do ambiente (atores) que interagem com o sistema. Este
modelo nos informa tambm quais so as aes do sistema conforme percebidas
pelos atores, e quais as aes do ator, conform e percebidas p elo sistema. Com
esse m odelo, podem ser respondidas questes sobre o que o sistema deve fazer e
para quem. No entanto, o modelo de casos de uso nada informa sobre qual deve
ser 0 comportamento interno do sistema para que uma determinada funcionali
dade se realize. Ou seja, para que um caso de uso seja realizado, produzindo um
'esultado de valor para o ator, as questes a seguir so relevantes. (Note que,
Dara essas perguntas, no encontramos respostas no modelo de casos de uso de
am sistema, no importa quo detalhado esse modelo seja.)

1. Quais so as operaes que devem ser executadas internamente ao sis


tema?
2. A que classes essas operaes pertencem?
3. Quais objetos participam da realizao desse caso de uso?
182 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Por outro lado, o modelo de classes de anlise fornece uma viso estrutural e
esttica inicial do sistema. A construo deste modelo resulta em um esboo das
classes e de suas responsabilidades. No entanto, algumas questes tambm no
so respondidas por esse modelo:

1. De que forma os objetos colaboram para que determinado caso de uso


seja realizado?
2. Em que ordem as mensagens so enviadas durante essa realizao?
3. Que informaes precisam ser enviadas em uma mensagem de um objeto
a outro?
cJas.s.ea. opi ainda no foram
identificadas?

A leitura dos pargrafos anteriores d a entender que os modelos de casos de


uso e de classes so representaes incompletas do sistema. E realmente o so.
Para responder s questes levantadas nos pargrafos anteriores, o modelo de in
teraes do sistema precisa ser criado. Esse modelo representa as mensagens (ver
a Seo 1.2.2) trocadas entre os objetos para a execuo de cenrios dos casos de
uso do sistema. A modelagem de interaes uma parte da modelagem dinmica
de um SSOO (a outra parte corresponde modelagem de estados, que descreve
mos no Captulo 9).
A construo do modelo de interaes pode ser vista como uma consolidao
do entendimento dos aspectos dinmicos do sistema. Em particular, se os mode
ladores utilizam a modelagem CRC durante a identificao de classes (ver Seo
5.4.3.1), alguns aspectos iniciais relativos dinmica de interao entre objetosj
conhecida. Entretanto, os aspectos dinmicos identificados com aquela tcnica
ainda so incipientes e incompletos. Graas construo do modelo de intera
es, as classes, as responsabilidades e os colaboradores identificados podem ser
validados. Esse modelo permite ainda refinar o modelo de classes, pois as opera
es (e at alguns atributos) de cada classe so identificadas na construo do
modelo de interaes. Nesse captulo, descrevemos os elementos do modelo de
interaes. So tambm apresentadas dicas sobre a construo desse modelo.

7.1 Elementos da modelagem de interaes


A interao entre objetos para dar suporte funcionalidade de um caso de uso
denomina-se realizao de um caso. A realizao de um caso de uso descreve o
comportamento de um ponto de vista interno ao sistema. A realizao de um
caso de uso representada por diagramas de interao.
Os diagramas da UML que do suporte modelagem de interaes so co
nhecidos genericamente como diagramas de interao. At a verso 1.X da UML,
MODELAGEM DE INTERAES 183
ELSEVIER

havia dois diagramas para dar suporte construo do modelo de interaes: o


diagrama de sequncia (sequence diagram) e o diagrama de comunicao (commu-
nication diagram; na UML l.X , o diagrama de comunicao era chamado de dia
grama de colaborao). De uma forma geral, esses dois tipos de diagramas de in
terao representam mensagens enviadas entre objetos. A diferena entre esses
dois tipos est na nfase dada s interaes entre os objetos. No diagrama de se-
qncia, a nfase est na ordem temporal das mensagens trocadas entre os obje
tos. J o diagrama de comunicao enfatiza os relacionamentos que h entre os
objetos que participam da realizao de um cenrio. O diagrama de sequncia e
o diagrama de comunicao so equivalentes entre si. De fato, um diagrama de
comunicao pode ser transformado em um diagrama de seqncia equivalen
te. Da mesma forma, um diagrama de seqncia pode ser transformado em um
diagrama de comunicao equivalente. No entanto, a popularidade e o uso do
diagrama de seqncia so bem maiores do que o diagrama de comunicao. A
Figura 7-1 e a Figura 7-2 apresentam esboos das estruturas tpicas do diagrama
de seqncia e do diagrama de comunicao, respectivamente.

Ator O b j e t o ( n o t e o s u b li n h a d o ) . C la s s e (n o te q u e n o
h s u b li n h a d o )

: NomeClassel : NomeClassel : NomeCla.sse.3 NomeClasse4

F o c o d e c o n tro le
( u s o o p c io n a l )

M e n s a g e m s n c r o n a

A u t o m e n s a g e m ( in d i c a a e x e c u o
M en sag em d e r eto m o
d e u m a o p e r a o n a c la .ss e d o o b je t o
Vc o r r e s p o n d e a o v a lo r d e
r e t n e t a it c d a m e n s a g e m )
r e to r n o d a m e n s a g e m m l .

Figura 7-1: Estrutura tpica de um diagrama de seqncia.

1.3: m5()

Figura 7-2; Estrutura tpica de um diagrama de comunicao.


184 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEMER

A verso 2.0 da UML apresenta outro tipo de diagrama de interao, o dia


grama de viso geral de interao (traduo para interaction ovei~view diagram).
Esse ltimo pode ser utilizado para apresentar uma viso geral de diversas inte
raes entre objetos, cada uma delas representada por um diagrama de intera
o. Esse diagrama til para modularizar a construo do diagrama de seqn-
cia (ou de comunicao). A Seo 7.4.2 apresenta mais detalhes acerca desse
novo diagrama da UML.
Os diagramas de interao ajudam a documentar e a entender os aspectos
dinmicos do sistema de software. Mais especificamente, eles descrevem a se-
qncia de mensagens enviadas e recebidas pelos objetos que participam em
um caso de uso. Certas caractersticas de um caso de uso (como, por exemplo, o
controle de execuo e a concorrncia no envio de mensagens) tambm so es
clarecidas pela construo de diagramas de interao.

Diagramas de interao mostram como os objetos do sistema agem internamente


para que um ator atinja seu objetivo na realizao de um caso de uso. A modelagem
de um sistema de software orientado a objetos atravs da UML normalmente con
tm diversos diagramas de interao. 0 conjunto de todos os diagramas de intera
o de um sistema constitui o seu modelo de interaes.

Um diagrama de interao utilizado para modelar a lgica de um cen


rio de caso de uso (Seo 4.1.1). Um diagrama de interao tambm pode ser
utilizado para modelar a troca de mensagens entre objetos em uma parte de
um cenrio, se este for muito complexo. Sendo assim, dado um caso de uso,
pode haver vrios diagramas de interao a ele relacionados, um para cada
cenrio (ou parte de um cenrio) considerado relevante. No entanto, se o
caso de uso for simples, o diagrama de interao pode modelar o caso de uso
como um todo.

0 enfoque do diagrama de seqncia est em como as mensagens so enviadas no


decorrer do tempo. 0 enfoque do diagrama de comunicao est em como as men
sagens so enviadas entre objetos que esto relacionados.

O diagrama de seqncia e o diagrama de comunicao possuem bastante


notao em comum. O restante desta seo descreve os diversos componentes
de notao que so comuns a ambos os diagramas de interao. Na Seo 7.2 e
na Seo 7.3, descrevemos as notaes particulares de cada um desses diagra
mas de interao.
MODELAGEM DE INTERAES 185

7.1.1 Mensagens
Conforme vimos no Captulo 4, o conceito fundamental no MCU o caso de
uso. De forma anloga, o elemento mais importante e o princpio bsico da inte
rao entre objetos o conceito de mensagem. Conforme descrito na Seo
1.2.2, uma mensagem uma solicitao de execuo de uma operao em outro
objeto.^ atravs do envio de mensagens que os objetos do sistema colaboram
entre si para prover as funcionalidades esperadas. Em outras palavras, um siste
ma de software orientado a objetos pode ser visto como uma rede de objetos. As
funcionalidades desse sistema so realizadas por seus objetos componentes,
que s podem interagir por meio de mensagens.

Uma mensagem representa a requisio de um objeto remetente a um objeto re


ceptor para que este ltimo execute alguma operao definida para sua classe.
Essa mensagem deve conter informao suficiente para que a operao do objeto
receptor possa ser executada.

Uma mensagem enviada a um objeto invoca a execuo de uma de suas ope


raes. Podemos fazer uma correlao do conceito de envio de mensagem, com o
conceito de chamada de rotinas das linguagens de programao. Uma mensa
gem pode ser vista como uma chamada a uma rotina definida para uma classe de
objetos. Na prtica, uma operao uma rotina implementada em alguma lin
guagem de implementao e definida dentro do escopo de uma classe. Alis, a
diferena entre operao de uma classe e uma rotina est justamente no fato de
que a operao definida dentro de uma classe, em vez de ser um dos compo
nentes de um mdulo de um programa.
Quando uma mensagem representada em um diagrama de interao, h
sempre um objeto remetente, e outro objeto o receptor da mensagem. Alm
disso, o contedo da mensagem enviada pelo remetente especifica informaes
a serem passadas para a operao que deve ser executada no objeto receptor. Na
UML, a sintaxe para representar mensagens comum a ambos os tipos de dia
grama de interao. Por essa razo, os tipos de mensagens e a sintaxe de especi
ficao so descritos separadamente nesta seo, antes do detalhamento desses
diagramas de interao propriamente ditos.

^ Para ser mais exato, um objeto pode enviar uma mensagem para si prprio atravs de uma mensagem
reflexiva.
186 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEMER

7.1.1.1 Natureza de uma mensagem


A verso 2.0 da UML define o conceito de natureza de uma mensagem (message
sort). A natureza da mensagem indica o tipo de comunicao que foi utilizado
para gerar a mensagem. As naturezas possveis para uma mensagem so descri
tas a seguir.

1. Uma mensagem sncrona indica que o objeto remetente espera que o objeto
receptor processe a mensagem antes de recomear o seu processamento. Ou
seja, o remetente fica bloqueado at que o receptor termine de atender re
quisio. Uma mensagem sncrona est tipicamente relacionada chamada
de uma operao definida na classe do objeto receptor da mensagem.
2. Uma mensagem assncrono aquela na qual o objeto remetente no espe
ra a resposta para prosseguir com o seu processamento.
3. Uma mensagem de sinal aquela usada para enviar um sinal. Um sinal
pode representar o envio de uma requisio entre dois mdulos (por
exemplo, cliente e servidor) em um sistema distribudo.
4. Uma mensagem de retomo aquela utilizada para especificar o retorno
(trmino) de uma mensagem enviada anteriormente.

Um objeto pode enviar uma mensagem para ativar uma operao definida
em sua prpria classe. Quando isso ocorre, diz-se que o objeto est enviando
uma mensagem reflexiva. Isso significa que, em vez de requisitar a execuo de
uma operao definida em outra classe, o objeto em questo est requisitando a
execuo de uma operao definida na sua prpria classe.

7.1.1.2 Sintaxe da UML para mensagens


Em ambos os tipos de diagramas de interao, cada mensagem representada
graficamente por uma seta cujo sentido do objeto remetente para o objeto re
ceptor. Alm disso, em ambos os diagramas, as setas possuem rtulos que espe
cificam a mensagem sendo enviada. Esse rtulo pode ser visto como a especifi
cao das informaes que so passadas pelo objeto remetente ao objeto recep
tor no envio de uma mensagem. O rtulo de uma mensagem pode ser definido
simplesmente como o nome de uma operao a ser executada no objeto recep
tor. Essa forma de rtulo a normalmente utilizada nos diagramas de interao
de fase de anlise. Por outro lado, o rtulo de uma mensagem pode correspon
der assinatura completa da operao a ser executada. A sintaxe para essa espe
cificao mais completa, e que normalmente utilizada nos diagramas de inte
rao da fase de projeto, a seguinte:

[[expresso-seqncia] controle:] [v :=] nome [(argumentos)]


MODELAGEM DE INTERAES 187

Nessa especificao anterior, os elementos delimitados por colchetes so


opcionais. Com efeito, somente o nome da mensagem obrigatrio. Por outro
lado, dependendo do grau de detalhe desejado na modelagem, a especificao
de uma mensagem pode conter desde somente o nome da mensagem at a defi
nio de uma expresso que contenha todos os elementos possveis da sintaxe.
A descrio dos elementos da sintaxe anterior dada a seguir.

7.1.1.2.1 Expresso de seqncia


A uma mensagem pode estar associada uma expresso de seqncia que serve
para eliminar ambigidades acerca de quando a mensagem foi enviada em rela
o s demais. Por exemplo, se as mensagens m l, m2 e m3 possuem expresses
de seqncia 1, 2 e 3, respectivamente, pode-se afirmar que a mensagem m l foi
enviada antes da mensagem m2 que, por sua vez, foi enviada antes de m3.
As expresses de seqncia podem tambm ser definidas por um esquema
de numerao em nveis. Por exemplo: 1.2,1.2.1, 1.3, 2.4 etc. Esse esquema de
numerao til quando desejamos modelar que mensagens so enviadas por
conta de uma mensagem anterior ter sido enviada, o que nos permite facilmente
definir a ordem correta de envio das mensagens envolvidas. Por exemplo, supo
nha que uma mensagem cuja expresso de seqncia 1 emitida. As mensagens
1.1, 1.2 etc. so enviadas pela operao que foi invocada pela mensagem 1. As
mensagens 1.1.1, 1.1.2 etc. so enviadas pela operao que foi invocada pela
mensagem 1.1, e assim por diante.
O formato de representao em nveis pode ser sufixado com letras para in
dicar o paralelismo do envio de duas ou mais mensagens. Por exemplo, as ex
presses de seqncia 1.2a e 1.2b indicam mensagens que esto sendo enviadas
em paralelo dentro da ativao 1.2.

7.1.1.2.2 Controle
Algumas vezes necessrio indicar que o envio de uma mensagem est condicio
nado ao valor de uma expresso lgica (ou seja, uma expresso cujo valor de ava
liao verdadeiro ou fa lso). Outras vezes preciso indicar quantas vezes uma
mensagem deve ser enviada consecutivamente. O elemento controle da sintaxe de
uma mensagem pode ser utilizado com esses dois objetivos. Esse elemento de
controle especificado atravs da OCL (ver Seo 3.6). H dois tipos de controle:
a clusula-condio e a clusula-iterao. Descrevemos os dois a seguir.
Se o elemento clusula-condio aparecer na especificao de uma mensa
gem, esta enviada se, e somente se, o valor da expresso lgica for verdadeiro.
Se 0 valor da expresso for falso, a mensagem no enviada. Por exemplo, [a >
b] uma clusula de condio; se, e somente se, a for maior que b, a mensagem
correspondente enviada. A clusula-condio tem outros nomes: condio de
188 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

guarda ou simplesmente guarda. A sintaxe utilizada para esse elemento de con


trole a seguinte: [clusula-condio].
A clusula-iterao representa uma repetio do envio de uma mensagem
representada por um asterisco. Isso indica que a mensagem emitida mltiplas
vezes, geralmente para objetos receptores diferentes. Opcionalmente, a iterao
pode apresentar o elemento clusula-iterao, que define o limite inferior e o li
mite superior de uma seqncia de repeties com uma varivel de iterao. Por
exemplo, a expresso * [ i ; =1.. 10] indica que a mensagem correspondente ser
enviada 10 vezes. A sintaxe utilizada para esse elemento de controle a seguin
te: * [clusula-iterao].
Alternativamente ao uso da OCL, tanto a clusula de condio quanto a
clusula de repetio podem ser especificadas em pseudocdigo. Por exemplo:
*[para cada f em F] desenharf)
*[ enquanto x>0] transformar(x)
[senha vlida] abrirJanelaPrincipalf)

Embora ainda sejam vlidos na UML 2.0, os elementos de controle (clusu


la de condio e clusula de iterao) foram parcialmente substitudos por ou
tros elementos definidos nessa ltima verso da linguagem de modelagem uni
ficada, em particular os fragmentos combinados e os operadores de interaes.
Para mais detalhes sobre esses novos elementos, ver Seo 7.4.

7.1.1.2.3 Varivel
O elemento v na sintaxe de uma mensagem corresponde a um identificador de
varivel que recebe o valor retornado pela operao a ser executada no objeto
receptor. A existncia desse elemento pode ser justificada por uma situao bas
tante comum em programao, a saber, a utilizao de variveis temporrias.
Uma varivel temporria utilizada para armazenar certa informao que deve
ser utilizada em momento futuro. Em particular, podemos usar uma varivel
temporria para armazenar o valor de retorno de uma rotina para uso posterior.
Pois bem, a tempo de modelagem do diagrama de interao, esse artifcio de
programao pode ser representado pelo elemento v que aparece na sintaxe de
uma mensagem.

7.1.1.2.4 Nome e argumentos


O elemento nome na sintaxe corresponde expresso de chamada de uma ope
rao definida na classe do objeto receptor. Esse elemento pode conter uma lista
(possivelmente vazia) de argumentos aps o seu nome. Essa lista delimitada
por parnteses. Se houver mais de um parmetro na lista, eles devem ser delimi
tados por vrgulas. Note que os argumentos definidos em um rtulo de mensa-
MODELAGEM DE INTERAES 189

gem correspondem aos argumentos da operao que deve ser executada. (Os
detalhes da sintaxe completa para operaes esto na Seo 8.3).

7.1.1.2.5 Exemplos
Alguns exemplos correspondentes sintaxe de mensagens so apresentados a
seguir. A Seo 7.2 apresenta mais exemplos de mensagens utilizadas em dia
gramas de interao.
Mensagem simples, sem clusula alguma.
1: adicionarltem(item)

Mensagem com clusula de condio. A mensagem somente enviada se


a condio associada for verdadeira.
3 [a > b ]: trocar(a, b)

Mensagem com clusula de iterao e com limites indefinidos.


2 *: desenhar( )

Mensagem com clusula de iterao e com limites definidos. A mensagem


desenhar enviada 10 vezes, consecutivamente.
2 *[i := 1 ..1 0 ]: figurasfi].desenharf )

Mensagem aninhada com valor de retorno armazenado na varivel x.


Nesse exemplo, a operao recebe um argumento, e.
1.2.1: X := selecionar(e)

7.1.2 Atores
Os atores que participam da realizao de um caso de uso podem ser apresenta
dos no diagrama de interao. Normalmente, o ator primrio (ver Seo 4.1.2)
o responsvel por enviar a mensagem inicial que inicia a interao entre os obje
tos. Os atores so representados nos diagramas de interao pela mesma nota
o grfica utilizada no diagrama de casos de uso (ver Seo 4.2).

7.1.3 Objetos
Objetos em um diagrama de interao so representados da mesma forma que
nos diagramas de objetos. De acordo com a UML 2.0, a expresso definida den
tro do retngulo do objeto deve obedecer sintaxe a seguir;

nomeobjetofseletor] : nomeclasse ref ocorrnciainterao


190 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Na expresso anterior, temos os seguintes componentes:

1. O elemento nome_obj eto especifica o nome de uma instncia (objeto) en


volvida na interao. Esse elemento opcional, o que implica que obje
tos podem ser annimos ou nomeados. Como o prprio nome diz, um ob
jeto nomeado aquele ao qual foi dado um nome. Normalmente, um
objeto nomeado utilizado quando o mesmo precisa ser referenciado em
mais de um lugar no diagrama. Nesse caso, o nome do objeto separado
do nome de sua classe por um sinal de dois pontos. Quando no h essa
necessidade, os objetos annimos so utilizados. A representao para
objetos annimos e nomeados apresentada na Figura 7-3.
2. O elemento nome_cl asse corresponde ao nome da classe dessa instncia.
3. O elemento sei etor opcional; se for especificado, serve para fazer refe
rncia a uma instncia de uma classe que est armazenada em uma cole
o de objetos, tal como uma lista (para mais detalhes sobre colees de
objetos, ver Seo 7.2.4). Veja um exemplo na Figura 7-3; note a utiliza
o de um ndice (a letra i) para indicar o i-simo elemento da coleo.
4. Finalmente, o elemento ocorrnci a_i nterao representa uma ocorrncia
de interao. Este elemento, que tambm opcional, serve para fazer re
ferncia a outro diagrama de seqncia, que mostra detalhes acerca de
como essa instncia manipula as mensagens que recebe. Quando este
elemento for utilizado, a palavra chave ref precisa ser posicionada a sua
esquerda, conforme a sintaxe anterior. Para mais detalhes sobre o uso de
ocorrncias de interao, ver Seo 7.4.

Objeto Objeto Objeto em


nomeado annimo uma coleo

umaDisciulina : Disciulina Discinlina preRequisitosil : Disciplina

Figura 7-3: Representao para objetos e diagramas de seqncia e de comunicao.

7.1.4 Classes
Na maioria das situaes encontradas na prtica, somente objetos so repre
sentados em um diagrama de interao. No entanto, quando a mensagem for
endereada para uma classe (e no para um objeto), a prpria classe deve ser
representada no diagrama. A participao de uma classe em um diagrama de
interao se justifica pelo fato de a prpria classe (em vez de um objeto) poder
atender uma mensagem. Uma mensagem para uma classe dispara a execuo
de uma operao esttica (operaes estticas so descritas na Seo 8.3.1). A
MODELAGEM DE INTERAES 191

representao de uma classe em um diagrama de seqncia a mesma utiliza


da para objetos; porm, o nome da classe no sublinhado (ver extre
ma-direita da Figura 7-1).

7.1.5 Colees de objetos


Alm de permitir a representao de objetos e classes, um diagrama de interao
tambm pode apresentar multiobjetos. Um multiobjeto representa uma coleo
de objetos de uma mesma classe. Um multiobjeto pode ser utilizado para repre
sentar o lado muitos de uma associao de conectividade um para muitos.
Um multiobjeto tambm pode ser utilizado para representar uma lista (tempo
rria ou no) de objetos sendo formada em uma colaborao. Pela representa
o, uma mensagem pode ser enviada para a coleo como um todo, em vez de
ser enviada para um nico objeto da coleo.
Um multiobjeto representado graficamente por dois retngulos superpos
tos. O nome do multiobjeto apresentado no retngulo que fica por cima e se
gue a mesma nomenclatura utilizada para objetos. Normalmente utiliza-se a
conveno de usar o mesmo nome do objeto para nomear o multiobjeto, pois a
superposio dos retngulos evita a confuso. Como exemplo, considere o frag
mento de diagrama de comunicao da Figura 7-4, no qual se utiliza um multi
objeto ItemPedido.
A UML no especifica precisamente que operaes podem ser invocadas em
um multiobjeto. Entretanto, multiobjetos so normalmente implementados
por meio de alguma estrutura de dados que manipule uma coleo de objetos.
Portanto, algumas mensagens tpicas que podemos esperar que um multiobjeto

Produto prod
Integer quant

3.1.1: conectar(prod)

3: adicionarltemCprod, quant) 3.1: criar(prod, quant)


p: Pedido 1 i t e m : I t e m P e d i d o l n e w l 1

(n ew )

3.2: adicionar(item)
4 1 D ro d : P r o d u to |

: ItemPedido
Coleo (multiobjeto) de objetos N
da classe ItemPedido associados ao
objeto p, este ltimo da classe Pedido,

Figu ra 7-4: Exemplo de uso de um multiobjeto.


192 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Posicionar o cursor da coleo no primeiro elemento.


Retornar o i-simo objeto da coleo.
Retornar o prximo objeto da coleo.
Encontrar um objeto de acordo com um identificador nico.
Adicionar um objeto na coleo.
Remover um objeto na coleo.
Obter a quantidade de objetos na coleo.
Retomar um valor lgico que indica se h mais objetos a serem considerados.

Para dar uma viso mais clara das possibilidades de operaes em um multi-
objeto, observe o Quadro 7-1, na qual apresentamos uma interface da lingua
gem Java denominada List (detalhamos o conceito de interface na Seo 8.3.4).
Note que esto declaradas diversas operaes para manipulao de itens de uma
lista (coleo) de objetos.

Quadro 7-1: A interface List da linguagem Java apresenta operaes tpicas


de um multiobjeto

public interface tist<E> extends Collection<E> {


E get(int index);
E set(int index, E element);
boolean add(E element);
void add(int index, E element);
E remove(int index);
abstract boolean addAll(int index, Collection<? extends E> c);
int indexOf(Object o);
int lastIndexOf(Object o);
ListIterator<E> 1istiterator( );
ListIterator<E> 1istIterator(int index);
List<E> subList(int from, int to);

Um multiobjeto representa uma coleo de instncias de certa classe. Em


diagramas de interao, uma mensagem enviada a um multiobjeto emitida
coleo, e no a cada instncia individual. Entretanto, um smbolo de asterisco
(*) pode ser adicionado perto do extremo de uma ligao onde h um multioh-
jeto para indicar que a mensagem est sendo enviada iterativa a cada instncia
da coleo. A Figura 7-5 ilustra os dois casos mencionados aqui.
A verso 2.0 na UML introduziu uma maneira mais conveniente de fazer re
ferncia a um dos elementos de uma coleo de objetos (multiobjeto). Essa ma
neira ilustrada na Figura 7-6. Note que o nome do objeto indexado para enfa
tizar que ele um componente de uma coleo que contm diversos objetos.
MODELAGEM DE INTERAES 193

Figura 7-5: Mensagem enviada para um multiobjeto e para instncias de um multiobjeto.

Figura 7-6: Forma para representar um objeto componente de uma coleo (multiobjeto).

7.2 Diagrama de seqncia


o objetivo do diagrama de seqncia apresentar as interaes entre objetos na
ordem temporal em que elas acontecem. Assim como os outros diagramas da
UML, o diagrama de seqncia possui um conjunto de elementos grficos. Na
construo de um diagrama de sequncia, podemos utilizar as notaes descritas
na Seo 7.1. Podemos tambm utilizar algumas notaes particulares ao diagra
ma de seqncia (ou seja, que no valem para o diagrama de comunicao). Algu
mas situaes para as quais existem notaes particulares no diagrama de se
qncia so as seguintes; linhas de vida, envio de mensagens, ocorrncias de exe
cuo, criao e destruio de objetos. Descrevemos a notao e o significado des
ses elementos de notao particulares nesta seo (descrevemos dicas para a
construo propriamente dita de um diagrama de seqncia na Seo 7.5.3).

7.2.1 Linhas de vida


Uma vez identificados, os objetos que participam da realizao de um determi
nado caso de uso devem ser posicionados no diagrama de seqncia correspon-
194 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSE\'1ER

dente. A notao grfica utilizada para representar esses objetos denominada


linha de vida. Uma linha de vida composta de duas partes, a cabea e a cauda. A
cabea de uma linha de vida representada com a mesma notao que utiliza
mos para objetos no diagrama de objetos (ver Seo 5.3).
A representao grfica de uma linha de vida tambm possui uma cauda,
que corresponde a uma linha vertical tracejada, conforme esquematizado na Fi
gura 7-7. Para o caso de atores representados em um diagrama de seqncia,
tambm comum pendurar uma linha tracejada nesses elementos, da qual par
tem as mensagens para o interior do sistema. Em um diagrama de seqncia,
normalmente o ator posicionado na extrema esquerda do diagrama de seqn
cia (ver tambm a Figura 7-1).

Linha de vida em um ator

Figura 7-7; Representao de linhas de vida em um diagrama de seqncia.

A ordem horizontal utilizada para posicionar os objetos no diagrama de se


qncia no tem nenhum significado predefinido. Entretanto, a ordem normal
mente utilizada a seguinte (da esquerda para a direita): ator primrio, objeto(s) de
fronteira com o(s) qual(is) o ator interage, objeto(s) de controle, objetos de entida
de e atores secundrios. Essa ordem de disposio facilita a leitura do diagrama.

7.2.2 Mensagens
A notao para uma mensagem em um diagrama de seqncia uma flecha (ge
ralmente desenhada na horizontal) ligando uma linha de vida a outra. O objeto
do qual parte a seta aquele que est enviando a mensagem (objeto remetente).
O objeto para o qual a seta aponta aquele que est recebendo a mensagem (ob
jeto receptor). O formato da ponta da seta indica o tipo de mensagem sendo
enviada (ver Seo 7.1.1). Os formatos possveis em um diagrama de seqncia
esto ilustrados na Figura 7-8. O rtulo da mensagem (descrito na Seo 7.1.2)
posicionado acima dessa linha.
MODELAGEM DE INTERAES 195

Mensagem sncrona

Mensagem assncrona

Mensagem de retorno

create Mensagem de criaao de objeto

Figura 7-8: Notaes para os diversos tipos de


mensagem em um diagrama de seqncia.

A passagem do tempo percebida no diagrama de seqncia observando-se


a direo vertical no sentido de cima para baixo. Quanto mais abaixo uma men
sagem aparece no diagrama, mais tarde no tempo esta mensagem foi enviada.
A Seo 7.1.1, apresenta o significado de uma mensagem reflexiva. A Figura
7-9 ilustra o uso desse tipo de mensagem em um diagrama de seqncia. Po
de-se notar que uma mensagem reflexiva representada por uma seta saindo e
retornando para o prprio objeto.
Opcionalmente, o texto do cenrio de caso de uso pode ser adicionado do
lado esquerdo do diagrama de seqncia, para esclarecer as trocas de mensa
gens. Esse texto pode ser definido por notas explicativas (que fazem parte dos
mecanismos de uso geral da UML e so descritas na Seo 3.2). Se isso for feito,
o modelador deve tentar alinhar verticalmente as partes da descrio com as
mensagens correspondentes.

Mensagem reflexiva.
O objeto remetente da
mensagem tambm o receptor.

Note 0 uso do fo co de controle sobreposto.


A parte inferior desse fo co corresponde ao
trmino da execuo da operao
correspondente mensagem reflexiva.

Figu ra 7-9: Mensagem reflexiva em um diagrama de seqncia.


196 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEA^ER

7.2.3 Ocorrncias de execuo


Uma ocorrncia de execuo representa o tempo em que o objeto est ativo,
ou seja, 0 tempo em que ele realiza alguma operao. Graficamente, ocorrn
cias de execuo correspondem a blocos retangulares posicionados sobre a
linha de vida de um objeto. O topo de uma ocorrncia de execuo coincide,
no receptor, com o recebimento de uma mensagem. A parte de baixo dessa
ocorrncia de execuo coincide com o trmino de uma operao realizada
pelo objeto.
O modelador pode optar por no utilizar ocorrncias de execuo nos obje
tos presentes em certo diagrama de seqncia. Por outro lado, o uso de ocorrn
cias de execuo muitas vezes torna desnecessrio o uso de mensagens de retor
no. Isso porque o final de uma ocorrncia de execuo corresponde ao retorno
do fluxo de controle para o emissor da mensagem (no caso de mensagens sn
cronas).

7.2.4 Criao e destruio de objetos


Duas operaes frequentes em um SSOO so a criao e destruio de objetos. A
criao de um objeto o momento em que esse objeto passa a existir no sistema,
e passa a realizar suas responsabilidades. Por exemplo, em nosso estudo de
caso, a realizao do caso de uso Abri r Turma tem o potencial de criar objetos da
classe Li staEspera, conforme vimos na Seo 5.7. J a destruio de um objeto
o momento no qual este objeto deixa de existir no sistema.
Algumas linguagens de programao orientadas a objetos normalmente
definem rotinas ou operadores especializados para a criao e/ou destruio
de objetos. Outras possuem mecanismos para destruio automtica de ob
jeto, liberando o programador de tal tarefa. De qualquer forma, as operaes
de criao e destruio de objetos so importantes o suficiente para terem
notaes especficas no diagrama de seqncia. Descrevemos essas notaes
a seguir.
Se o objeto existe desde o incio da interao (ou seja, se ele no criado du
rante a interao sendo modelada), ele deve ser posicionado no topo do diagra
ma. No entanto, pode ser que a prpria interao crie um ou mais objetos de cer
ta classe. Nesse caso, a posio vertical de um objeto em um diagrama de se
qncia indica o momento no qual ele criado (instanciado) e comea a partici
par da interao. Ou seja, o retngulo que representa o objeto deve ser posicio
nado mais abaixo no diagrama. A instanciao de um objeto sempre requisita
da por outro objeto participante da interao atravs de uma mensagem. A men
sagem de criao pode ser rotulada de duas maneiras alternativas: (1) com o es
teretipo c r e a te ou com o nome do mtodo construtor que ser ativado
(descrevemos mtodos construtores na Seo 8.3.4). Alm disso, a flecha da
MODELAGEM DE INTERAES 197

M ensagem de criao. N ote a form a da seta e ^


o uso do esteretipo create. N ote tam bm
que a m ensagem term ina na cabea da linha
O bjetoC riad or
de vida do ob jeto sendo criado.

o
create
> O bjetoC riad o

; I
Figura 7-10: Criao de objeto em um diagrama de sequncia.

mensagem pontilhada e aponta para o objeto em vez de para a linha de vida.


Na Figura 7-10 apresentamos um exemplo da notao de criao de objetos.
Um diagrama de seqncia pode mostrar tambm a destruio de objetos no
decorrer de uma interao. Um objeto normalmente destrudo quando ele no
mais necessrio na interao. O smbolo X na parte de baixo da linha de vida
de um objeto significa que ele est sendo destrudo. Alm disso, a mensagem de
destruio rotulada com o esteretipo d estro y . A Figura 7-11 fornece um
exemplo da notao para destruio de objetos.

Figu ra 7-11: Destruio de objeto em um diagrama de seqncia.


198 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

7.3 Diagrama de comunicao


o diagrama de comunicao mostra os objetos relevantes para a realizao de
um caso de uso (ou cenrio deste), assim como as ligaes entre os mesmos.
Sendo um tipo de diagrama de interao, o diagrama de comunicao mostra as
mensagens trocadas entre objetos. A Figura 7-2 exibe um esquema genrico
de um diagrama de comunicao, que permite perceber como, estruturalmente,
um diagrama de comunicao bastante semelhante a um diagrama de objetos
(Seo 5.3). A diferena que so adicionados setas e rtulos de mensagens nas
ligaes entre esses objetos.
Objetos e classes podem aparecer em um diagrama de comunicao, assim
como em um diagrama de seqncia, e a notao para esses elementos a mes
ma utilizada neste ltimo. Da mesma forma, pode haver objetos nomeados, ob
jetos annimos, multiobjetos e referncias para elementos de uma coleo.
Um elemento particular do diagrama de comunicao a ligao entre obje
tos. As ligaes so representadas graficamente por linhas entre objetos no dia
grama de comunicao e correspondem a relacionamentos entre os objetos: as
sociaes, agregaes, composies ou dependncias (uma descrio desses re
lacionamentos apresentada na Seo 5.2.2).
Outra diferena dos diagramas de comunicao e de seqncia diz respeito
forma de ler a ordem de envio das mensagens. Um diagrama de comunicao
mostra as interaes entre objetos de maneira semelhante ao diagrama de seqn
cia. No diagrama de comunicao, no h como saber a ordem de envio das men
sagens a no ser pelas expresses de seqncia. Ao contrrio, no diagrama de se
qncia, a posio vertical das mensagens permite deduzir a ordem na qual elas
so enviadas (embora a utilizao de expresses de seqncia para facilitar a lei
tura e eliminar eventuais ambigidades em um diagrama de seqncia tambm
seja possvel). No entanto, o diagrama de comunicao no mostra o tempo como
uma dimenso separada. Para compensar isso, todas as mensagens nesse diagra
ma devem obrigatoriamente conter expresses de seqncia (ver Seo 7.1.1.2.1).
Sendo assim, a ordem de envio de mensagens em um diagrama de comunicao
deduzida a partir das expresses de seqncia. A Figura 7-12 apresenta outro
exemplo de digrama de comunicao com expresses de seqncia.
O rtulo de uma mensagem tambm pode mostrar um elemento de controle
(de condio ou de iterao), conforme descrito na Seo 7.1.2.2. O sentido da
mensagem indicado por uma seta posicionada prxima ao rtulo da mensa
gem. Essa seta aponta para o objeto receptor da mensagem. Veja a Figura 7-13
como exemplo.
comum na modelagem de interaes surgir situaes em que precisamos
representar a criao e destruio de objetos ou de ligaes entre os mesmos.
Com esse objetivo, existem restries predefinidas na UML que podem ser utili
zadas para representar a criao e destruio de objetos, ou de ligaes entre ob-
MODELAGEM DE INTERAES 199
ELSEVIER

Figura 7-12: Expresses de sequncia em um diagrama de comunicao.

Mensagem com expresso de sequncia e guarda, tx


Neste exemplo, a mensagem m enviada somente
se X for maior que zero.

1.2.2: [x>0] m()


OhjetoRemetente ObjetoReceptor

Figura 7-13: Mensagens em um diagrama de comunicao.

jetos em um diagrama de comunicao. Essas restries so {new}, (destroyed)


e {transient}. Veja a descrio a seguir.

1. Objetos ou ligaes criados durante a interao podem ser rotulados


com a restrio {new}.
2. Objetos ou ligaes destrudos durante a interao podem ser rotulados
com a restrio {destroyed}.
3. Objetos ou ligaes destrudos e criados durante uma mesma interao
podem ser rotulados com a restrio {transient}.

Graficamente, a restrio posicionada direita no interior do retngulo do


objeto. Para uma ligao, a restrio posicionada prxima linha correspon
dente ligao. A Figura 7-14 ilustra um exemplo de diagrama de comunicao
que usa a restrio {new}. Nesse diagrama, o uso dessa restrio no objeto i tem
indica que esse objeto est sendo criado durante a interao. O uso dessa mesma
restrio na ligao entre os objetos i tem e prod indica que tal ligao tambm est
sendo criada nessa interao.
200 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E E L S E V IE R

FommlrioDisponibilidade

^4: adicionarHabiliiao(disciplina)

I 3: adicionartem(dia, horainicial, horaFinal)

GerenteDisponibilidade

^4.1; adicionarHabilitao(disciplina)
I 3.1: adicionarItem(dia, horalnicial, horaFinal)

Todas as disciplinas^ 3.1.1: criar(dia, horalnicial, horaFinal)


da grade curricular GradeDisponibilidade ItemPisponibllidade {newl
---------------------------- 7 T ~
4.1.1: add(disciplina)
Uso da restrio {new} aqui 1^
(new) o--- indica que a ligao criada
Uso da restrio Inew} aqui
durante essa interao, indica que o objeto criado
: Disciplina d : Disciplina durante essa interao.______

Figura 7-14: Elementos de um diagrama de comunicao.

7.4 Modularizao de interaes


A verso UML 2.0 introduziu diversos elementos grficos novos para constru
o modular de diagramas de interao; quadros de interao, fragmentos com
binados, referncias, operadores etc. Nesta seo, descrevemos esses elemen
tos. Note que, embora os exemplos que damos nesta seo sejam relativos a dia
gramas de sequncia, quadros tambm podem ser utilizados na construo de
diagramas de comunicao.

7.4.1 Quadros
Um quadro de interao (traduo para interaction fram e) serve para encapsular
um diagrama de seqncia. Um quadro fornece um contexto ou uma fronteira
no interior do qual podemos posicionar os elementos de um diagrama de se
qncia, tais como linhas de vidas e mensagens. Graficamente, um quadro um
retngulo. A notao grfica para um quadro definida pela UML 2.0 apresenta
da na Figura 7-15.

Um diagrama (ou um nome de


um diagrama) posicionado no
interior do quadro._______________

Figu ra 7-15: Notaao para um quadro na UM L.


MODELAGEM DE INTERAES 201
ELSEVIER

Conforme podemos perceber na Figura 7-15, na parte superior esquerda de


um quadro, h uma espcie de orelha, na forma de um pentgono. No interior
desse pentgono devemos definir um rtulo. Esse rtulo pode ser utilizado com
trs diferentes objetivos pelo modelador. Enumeramos esses objetivos abaixo.
Nos prximos pargrafos desta seo, damos detalhes acerca de cada um desses
objetivos.

Para dar um nome ao diagrama que aparece dentro do quadro.


Para fazer referncia a um diagrama definido separadamente.
Para definir o fluxo de controle da interao.

Vamos comear detalhando o primeiro objetivo (dar um nome ao diagraina


dentro do quadro). A partir da EME 2.0, todo diagrama de interao pode ser po
sicionado dentro de um quadro. Se isso acontecer, a orelha do quadro deve con
ter uma expresso da forma TipoDiagrama NomeDiagrama. Nessa expresso, o ele
mento NomeDiagrama o nome dado ao diagrama cuja interao est definida
dentro do quadro. Qualquer diagrama de interao pode ser pocisionado den
tro de um quadro. Para identificar qual o tipo de diagrama que est contido no
quadro, utilizamos o elemento TipoDiagrama da expresso. Os valores poss
veis para este elemento so os seguintes: sd (para diagramas de seqncia),
comm (para diagramas de comunicao) e activity (para diagramas de ativida
de). O objetivo de dar um nome a um diagrama de interao permitir que este
seja referenciado durante a definio de outros diagramas.
O segundo objetivo da orelha de um quadro fazer referncia a um diagrama
definido separadamente. De fato, alm de permitir atribuir um nome a um dia
grama, a orelha de um quadro pode tambm servir para indicar que este corres
ponde a uma ocorrncia de interao. Uma ocorrncia de interao uma intera
o que referenciada por outra. Podemos utilizar ocorrncias de interao
para fatorar interaes comuns a vrios diagramas de seqncia em um nico
quadro e reutilizar esse quadro diversas vezes. Graficamente, uma ocorrncia
de interao um quadro rotulado com a palavra-chave ref. O nome da intera
o posicionado no interior desse quadro rotulado com a palavra-chave r e f a
sua esquerda. Essa palavra-chave indica que uma interao est sendo referen
ciada dentro de outra interao. Na Eigura 7-16, oberva-se que o quadro rotula
do como InteraoA faz referncia a duas outras interaes. Essas, por sua vez,
so representadas como ocorrncias de interao, esto indicadas no diagrama
como InteraoB e InteraoC.
A ocorrncia de interao implica que um quadro pode conter outros qua
dros em seu interior, ou seja, subquadros. Na verdade, a UME 2.0 define dois ti
pos de subquadros. Um deles a ocorrncia de interao, qual nos referimos
h pouco. O outro tipo corresponde ao cham ado fragmento combinado. Este ele-
202 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSE\aER

sd InteraoB J
sd In te ra o ^
Objeiol Objero2
Obietol Obielo2 Objeto3
r m lO I ) m BlO . 1
JL
re InteracoB 1
mB2()
1
InteraoC 1
m 2() mB3()

IrueraoB e IrueraoC so nomes de L


diagramas que apresentam mensagens trocadas
entre os objetos Objetol e Objeto2. Note que
os quadros correspondentes so rotulados com
re r e posicionados sobre as linhas de vida
dos objetos.

Figura 7-16: Ocorrncias de interao.

mento utilizado para alcanar o terceiro objetivo enumerado anteriormente,


definir o fluxo de controle da interao. Este elemento fornece ao modelador a ca
pacidade de definir lgica procedimental (fluxo de controle) nos seus diagra
mas de interao. Graficamente, um fragmento combinado corresponde a uma
ou mais interaes (seqncias de mensagens) encapsuladas em um quadro. O
operador da interao representado dentro do pentgono do quadro corres
pondente ao fragmento combinado. Os operandos do fragmento combinado
(que so as interaes) so posicionados dentro do quadro. Se houver mais de
um operando, estes so separados por uma linha tracejada. Veja a notao defi
nida pela UML 2.0 para um fragmento combinado na Figura 7-17.

Aqui entra o operador do fragmento


combinado (loop, alt, opt etc.)

Fragmento combinado
com dois operandos

Separador de
operandos 5
F ig u ra 7-17: Notao da U M L para um fragmento combinado.
MODELAGEM DE INTERAES 203
ELSEVIER

Internamente, um fragmento combinado composto de um ou mais ope-


randos da interao, de zero ou mais condies de guarda, de um operador de inte
rao. Um operando em um fragmento combinado corresponde a uma seqn-
cia de mensagens. Essa seqncia executada (ou seja, as mensagens correspo-
dentes so enviadas) somente sob circunstncias especficas. A forma de execu
o dessa seqncia definida pelo operador de interao e pelas condies de
guarda que so utilizadas. Uma condio de guarda, tambm chamada de restri
o da interao, uma expresso condicional (de valor verdadeiro ou falso)
que associada a um operando da interao em um fragmento combinado. Uma
condio de guarda impe uma restrio acerca da execuo do operando ao
qual est associada. Essa restrio deve ser suficiente para definir se o operando
(interao) correspondente deve ou no ser executado. Se a condio tiver valor
verdadeiro, o operando executado; do contrrio, o operando no executado.
A definio de uma condio de guarda opcional, de tal forma que um operan
do sem condio de guarda executado sempre. Um operador de interao defi
ne a semntica de um fragmento combinado e determina como usar os operan-
dos da interao contidos nesse fragmento combinado. Em particular, a quanti
dade de operandos que podem ser definidos em um fragmento combinado de
pende do operador associado a esse fragmento. Uma descrio completa de to
dos os operadores de interao definidos pela UML 2.0 est fora do escopo desse
livro e pode ser encontrada em (OMG, 2005). Alguns desses operadores de inte
rao definidos na UML 2.0 so os seguintes: alt, opt, e loop. Descrevemos seus
significados a seguir.
O operador alt modela construes procedimentais do tipo se-ento-
seno. Dos operandos definidos com esse operador, apenas um executado.
Cada operando avaliado com base em uma condio de guarda associada ao
mesmo. Uma condio de guarda uma expresso lgica. Uma condio de
guarda predefinida pode ser utilizada. Esse guarda avalia para VERDADEIRO
quando todas as demais guardas avaliam para EALSO. Os operandos so sepa
rados um do outro dentro do quadro com uma linha tracejada. Veja um exem
plo na Eigura 7-18.
O operador opt modela construo procedimental do tipo se... ento. Esse
operador similar ao operador alt. A diferena que o operador opt est associa
do a apenas um operando. Se a condio de guarda for verdadeira, o operando
correspondente executado. Do contrrio, esse operando pulado. Veja um
exemplo na Eigura 7-19.
O operador loop serve para representar que uma interao (operando) deve
ser realizada zero ou mais vezes. Aps o nome do operador, possvel (opcio
nal) representar os limites mnimo e mximo para definir a quantidade de itera
es. Asintaxe do operador loop a seguinte: loop[(<minint> [,<maxint> ] ) ].
204 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSE\T[ER

Figura 7-18: Utilizao do operador de interao ait.

Figura 7-19: Utilizao do operador de interao opt.

xe utilizada. Mais uma vez, os elementos dessa sintaxe que esto cercados por
colchetes so opcionais, o que significa que podemos utilizar somente o opera
dor. Nessa sintaxe, temos:
MODELAGEM DE INTERAES 205

1. O limite mnimo <minint> um nmero inteiro no negativo.


2. O limite mximo <maxint> pode ser representado de duas maneiras: (1)
com um nmero inteiro maior ou igual a <minint>; (2) pelo smbolo
que significa uma quantidade de iteraes sem limite superior.

Na sintaxe do operador loop, se somente o componente <minint> definido,


isso significa que <minint> igual a <maxint>. Por outro lado, se somente utili
zado o operador (sem os limites mnimo e mximo), isso significa uma quanti
dade de iteraes com limite inferior ou igual a zero e sem limite superior.

sd InteraoA

Obietol Obieto2 Obieto3

l o o p ( l ,3 ^ 1
n mOO ^ 1
* m UJ 1

m3() u1
1

i m4() 1

i U
Figura 7-20: Utilizao do operador de interao loop.

7.4.2 Diagrama de viso geral da interao


Outra abordagem para modularizar a construo de diagramas de interao in
troduzida pela UML 2.0 o diagrama de viso geral da interao (interaction
OverView diagram). Primeiramente, note que os diagramas de interao preexis
tentes (o diagrama de seqncia e o diagrama de comunicao) servem para re
presentar as interaes que ocorrem em um certo cenrio de um caso de uso.
Por outro lado, como seu prprio nome deixa transparecer, esse novo diagrama
introduzido na UML tem o objetivo de dar uma viso geral dos diversos cenrios
de um caso de uso. Este diagrama um tipo especial de diagrama de atividade.
Estudamos o diagrama de atividade em mais detalhes no Captulo 1 0 .0 leitor
convidado a consultar aquele captulo para detalhes acerca da notao do dia
grama de atividade. Em nosso estudo de caso, que continuamos na Seo 7.7,
fornecemos um exemplo de utilizao do diagrama de viso geral da interao.
206 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

7.5 Construo do modelo de interaes


Na Seo 7-2 e 7.3, descrevemos os principais elementos de notao dos diagra
mas de interao. Agora, passamos a discutir o procedimento de construo do
modelo de interaes. Primeiramente, vamos discutir a relao entre os concei
tos de mensagem e responsabilidade (o que fazemos na Seo 7.5.1). Aps isso,
definimos dois princpios fundamentais para a construo do modelo de intera
es, a coeso e o acoplamento (o que fazemos na Seo 7.5.2). Esta seo tam
bm descreve dicas prticas (Seo 7.5.3) e um procedimento (Seo 7.5.4)
para construo do modelo de interaes.

7.5.1 Mensagens para cumprir responsabilidades


Quando um objeto precisa de ajuda para realizar alguma de suas responsabili
dades, ele deve enviar mensagens a outros objetos. Portanto, o fato de um objeto
precisar de ajuda indica a necessidade de esse objeto enviar mensagens para ou
tros. Esse aspecto fundamental na identificao de mensagens.
Por outro lado, uma mensagem implica a existncia de uma operao no ob
jeto receptor, que ser executada quando aquela mensagem for enviada. Portan
to, na construo de diagramas de interao, quando o modelador especifica
mensagens de um objeto a outro, ele est na verdade especificando operaes
que as classes devem ter.

Uma mensagem implica a existncia de uma operao no objeto receptor. A res


posta ao recebimento de uma mensagem a execuo dessa operao.

Por exemplo, considere a Figura 7-21, que ilustra um fragmento de diagra


ma de sequncia com uma mensagem sendo enviada a um objeto da classe Usu-
ri 0. A mensagem indica que essa classe define uma operao denominada vai i dar.
Alm disso, essa operao possui dois argumentos, id e senha, ambos do tipo
Stri ng. Esse exemplo envolve uma mensagem contida em um diagrama de sequn
cia, mas o mesmo raciocnio vale para diagramas de comunicao.

Na modelagem de interaes Na modelagem de classes

ControladorAcesso um usurio: Usurio Usurio


login
senha
validar(in id :String, in senha :Senha) : bool
v:=validar(id, senha)

Operao resultante da identificao da 1^


mensagem homnima durante a
modelagem de inieraes.

Figu ra 7-21: A classe Llsuri o possui uma operao vai i dar, com dois argumentos: i d e senha.
MODELAGEM DE INTERAES 207
ELSEVIER

Pode-se concluir que a existncia de responsabilidades com as quais um ob


jeto no consegue cumprir sozinho indiretamente implica a necessidade de
operaes definidas em seus colaboradores. O modelador deve levar isso em
considerao quando da construo dos diagramas de interao. Sempre que
uma mensagem for enviada a um objeto em um diagrama de interao, o mode
lador deve questionar se tal objeto tem condies de responder mensagem so
zinho ou se precisa enviar mensagens a outros objetos.

7.5.2 Coeso e acoplamento


De acordo com a seo anterior, quando definimos uma mensagem no modelo
de interaes, estamos atribuindo uma responsabilidade a uma classe. Por con
ta disso, podemos entender a modelagem de interaes como um processo cujo
objetivo final decompor as responsabilidades do sistema e aloc-las a classes.
Dado um conjunto de N responsabilidades de um sistema, uma possibilidade
criar uma nica classe no sistema para assumir todas as N responsabilidades.
Outra possibilidade criar N classes no sistema, a cada um delas sendo atribu
da uma das N responsabilidades. Certamente, as duas alternativas anteriores
so absurdas do ponto de vista prtico. Mas, entre esses dois extremos, h mui
tas maneiras possveis de alocar responsabilidades. Como podemos saber quais
delas so melhores que outras?
Conforme j mencionamos no Captulo 5, a tarefa de identificao de
classes e de alocao de responsabilidades bastante complexa, para a qual
no h uma receita de bolo. O bom resultado dessa tarefa depende, entre ou
tros fatores, da experincia do modelador e da correta aplicao de alguns
princpios bsicos de desenvolvimento de software. A coeso e o acoplamento
so dois desses princpios. O acoplamento e a coeso servem como guias
para a correta atribuio de responsabilidades a classes. Descrevemos esses
princpios a seguir.
A coeso uma medida do quo fortemente relacionadas e focalizadas so as
responsabilidades de uma classe. extremamente importante assegurar que as
responsabilidades atribudas a cada classe sejam altamente relacionadas. Em
outras palavras, o projetista deve definir classes de tal forma que cada uma delas
tenha alta coeso. Se uma classe tem alta coeso, ela captura uma nica abstra
o e, por consequncia, mais reutilizvel.
Um sintoma tpico de uma classe com baixa coeso o fato de a mesma apre
sentar dois ou mais grupos de atributos (ou operaes), sendo que h alto grau
de correlao dentro de cada grupo, mas baixo grau de correlao entre os grupos.
Essa caracterstica um indcio de que, em um projeto de melhor qualidade, ha
veria duas ou mais classes, cada uma contendo os grupos de atributos (ou ope
raes) com alta correlao entre si.
208 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Alm de serem menos reutilizveis, classes com baixa coeso normalmente


so mais complexas do que deveriam ser. Por isso, tais classes so menos inteli
gveis e de manuteno (modificao) mais complicada.
O acoplamento uma medida de quo fortemente uma classe est conecta
da a outras classes, tem conhecimento ou depende das mesmas. Uma classe com
acoplamento fraco (baixo) no depende de muitas outras. Por outro lado, uma
classe com acoplamento forte menos inteligvel isoladamente e menos reutili
zvel. Alm disso, uma classe com alto acoplamento mais sensvel a mudan
as, quando necessrio modificar as classes da qual ela depende.
Pelo exposto anteriormente, podemos ver que a criao de modelos com
alta coeso e baixo acoplamento deve ser um objetivo de qualquer projetista.
Mas o que os princpios de coeso e acoplamento tm a ver com a modelagem de
interaes?
Na modelagem de interaes, quando definimos uma mensagem, estamos
criando uma dependncia entre os objetos envolvidos. Isso o mesmo que di
zermos que estamos aumentando o acoplamento entre os objetos em questo.
Portanto, necessrio que o modelador fique atento para apenas definir mensa
gens que so realmente necessrias. Podemos analisar esse aspecto tambm sob
a perspectiva do modelo de classes, da seguinte forma. Sempre que possvel, de
vemos evitar o envio de mensagens que implique a criao de associaes re
dundantes no modelo de classes. Isso porque a adio de uma associao entre
duas classes aumenta o acoplamento entre as mesmas.

Devemos evitar o acoplamento desnecessrio entre mdulos de um SSOO. Alm


disso, devemos tambm evitar a definio de mdulos que tm baixa coeso.

importante notar que as medidas de coeso e de acoplamento aplicam-se


tambm a diferentes nveis de abstrao e artefatos de sofware. Nesta seo, des
crevemos 0 seu uso no contexto das classes. Entretanto, essas medidas podem
tambm ser aplicadas a pacotes (de classes), componentes e camadas de softwa
re, conforme discutimos no Captulo 10, quando descrevemos apectos relativos
arquitetura de um SSOO.

7.5.3 Dicas para a construo do modelo de interaes


1. Identifique as classes conceituais (do domnio) que participam em cada
caso de uso. Essas so as entidades do mundo real que estariam envolvi
das na tarefa do caso do uso se este fosse executado manualmente. Exem
plos so: Aluno, OfertaDisciplina, Venda, Pagamento etc. Note que clas
ses de fronteira tambm podem ser classes provenientes do domnio. Por
MODELAGEM DE INTERAES 209
ELSEVIER

exemplo, Formulriolnscrio um objeto de fronteira (para o caso de


uso Realizar Inscrio; ver Seo 4.7.3) que tambm corresponde a um
conceito existente no domnio.
2. Identifique quaisquer classes de software (ou seja, classes da aplicao,
que no tm correspondente no mundo real) que ajudem a organizar as
tarefas a serem executadas. Essas classes de software normalmente so
necessrias para manter a coeso das demais classes em um nvel alto.
Em seu livro (Larman, 2003), Craig Larman chama essas classes de fa b ri
caes puras (pure fabrications). Aqui, se encaixam algumas classes de
fronteira, classes de controle. Por exemplo, classes de acesso ao mecanis
mo de armazenamento, classes de autenticao etc. Como um exemplo
mais especfico, existe o padro de projeto denominado DAO (Data
Access Object), que define uma estratgia de acesso a informaes em um
banco de dados. Detalhamos esse padro na Seo 12.2.3.
3. Na modelagem de interaes, voc precisar tambm definir que objetos
criam outros objetos. Na realizao de um caso de uso, objetos de entidade
so criados por um objeto de controle, que recebe os dados necessrios
instanciao a partir de objetos de fronteira. Objetos de entidade tambm
podem ser criados por outros objetos de entidade. De uma forma geral, em
uma agregao (ou composio), o objeto todo tem prioridade para criar
suas partes. Portanto, em uma agregao (ou composio) entre objetos de
entidade, mais adequado que o objeto todo crie suas partes quando requi
sitado por outros objetos. Por exemplo, considere a Figura 7-22, na qual um
objeto de controle pode enviar uma mensagem adicionarItemPedido para
Pedido e este, por sua vez, enviar uma mensagem de criao para ItemPedi-
do para que um novo objeto desta classe seja criado.

Figura 7-22; Em uma agregao, o todo normalmente responsvel por criar suas partes.
210 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

4. Verifique tambm a consistncia dos diagramas de interao em relao


ao modelo de casos de uso e ao contexto utilizado do modelo de classes.
Para isso, verifique que cada cenrio relevante para cada caso de uso foi
considerado na modelagem de interaes. Alm disso, se assegure de que
as mensagens que um objeto recebe esto consistentes com as responsa
bilidades a ele atribudas. Alm disso, note que alguns dos objetos neces
srios em uma interao j podem ter sido identificados durante a cons
truo do modelo de classes de anlise (Captulo 5). Entretanto, durante
a construo do diagrama de interao, o modelador pode identificar no
vas classes. Atributos, associaes e operaes tambm surgem como
subproduto da construo dos diagramas de interao.
5. Um aspecto importante na modelagem de interaes tem relao com os
conceitos de coeso e acoplamento (ver Seo 7.5.2) e com os objetos de
controle. Na construo do modelo de classes de anlise, vimos que
possvel definir um objeto de controle para cada caso de uso. Esse objeto
fica ento responsvel por coordenar a realizao desse caso de uso.
Como o controlador tem essa responsabilidade de coordenao, todas as
aes do ator resultam em alguma atividade realizada por esse objeto
controle. Isso pode levar a uma estrutura de classes bastante acoplada;
no pior caso, o controlador tem conhecimento da existncia de todas as
classes participantes do caso de uso. Por conta disso, bastante impor
tante que voc se certifique de que esse controlador realiza apenas coor
denao. Responsabilidades especficas no domnio devem ser atribudas
aos objetos de domnio (entidades). Alm disso, sempre que for adequa
do, segundo os princpios de coeso e de acoplamento, devemos fazer
com que as classes de domnio enviem mensagens entre si. Dessa forma,
o controlador envia uma mensagem para um objeto do domnio e este,
por sua vez, dispara o envio de mensagens para outros objetos do dom
nio, o que evita que o controlador precise ter conhecimento desses lti
mos (isto , fique acoplado aos mesmos). De qualquer forma, se, durante
a construo de um diagrama de interao, o objeto de controle (origin
rio da fase de anlise) comear a ficar muito complexo (e por conseqn-
cia, menos coeso), um ou mais controladores adicionais podem ser cria
dos para distribuir as responsabilidades do controlador original.
6 . Durante a modelagem de interaes, faa o mximo para construir dia
gramas de interao o mais inteligveis possvel. Por exemplo, podemos
utilizar notas explicativas (ver Seo 3.2) para esclarecer algumas partes
do diagrama de interao que esteja construindo. Essas notas podem
conter pseudocdigo ou mesmo texto livre. Outra estratgia que ajuda a
construir um modelo de interaes mais inteligvel utilizar os recursos
de modularizao (quadros, referncias entre diagramas) que a UML 2.0
MODELAGEM DE INTERAES 211
ELSEVIER

acrescentou (isso vale particularmente para os diagramas de seqncia).


Descrevemos esses recursos na Seo 7.4.
7. Outro princpio de projeto que podemos utilizar durante a construo
do modelo de interaes conhecido como Lei de Demeter. Esse princ
pio, tambm chamado de princpio do conhecimento mnimo, est associa
do ao princpio de acoplamento. A Lei de Demeter impe certas restri
es acerca de quais so os objetos para os quais devem ser enviadas
mensagens na implementao de uma operao definida em certa classe.
Mais especificamente, esse princpio indica que, dentro de um mtodo
(implementao de uma operao), mensagens somente devem ser
enviadas aos seguintes objetos: (a) ao prprio objeto da classe (ou self);
(b) a um objeto recebido como parmetro do mtodo; (c) a um atributo
da classe; (d) a um objeto criado dentro do mtodo; (e) a um elemento de
uma coleo que atributo da classe. A inteno desse princpio evitar
acoplar um objeto a outros objetos indiretos e tambm evitar que ele te
nha conhecimento das associaes entre outros objetos. Por exemplo,
considere que existem duas classes associadas, Venda e Pagamento e que
outro objeto necessita saber o valor do pagamento de uma venda. Uma
alternativa fazer com que esse objeto envie uma mensagem para o obje
to Venda para conhecer seu objeto Pagamento associado e, em seguida, en
vie uma mensagem para o objeto Pagamento para saber seu valor. Outra al
ternativa melhor, segundo a Lei de Demeter, fazer com que o objeto
Venda responda diretamente o valor do pagamento. O objeto Venda fica,
ento, responsvel por consultar seu pagamento e retornar o valor cor
respondente. Nessa ltima alternativa, o objeto que precisa desse valor
somente precisa ter conhecimento da classe Venda.

7.5.4 Procedimento de construo de um diagrama de interao


A seguir, descrevemos um procedimento para construir diagramas de intera
o. Esse procedimento genrico serve tanto para diagramas de seqncia
quanto para diagramas de comunicao, resguardando-se as diferenas de
notao entre os dois. Durante a aplicao desse procedimento, recomen
dvel considerar todas as dicas descritas na Seo 7.5.3. As dicas para atri
buio de responsabilidades descritas na Seo 5.4.3.2, quando nos referi
mos modelagem CRC, so igualmente aplicveis na construo do modelo
de interaes. Antes de descrevermos esse procedimento, entretanto, ne
cessrio que definamos o conceito de evento de sistema, o que fazemos no
prximo pargrafo.
O conceito de evento de sistema no novo. Na verdade, j era utilizado na
metodologia de anlise estruturada para a construo do modelo ambiental do
212 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

sistema (Yourdon, 1990). Um evento de sistema alguma ocorrncia no am


biente do sistema e para o qual este sistema deve realizar alguma ao quando
da ocorrncia do evento. No contexto de casos de uso, eventos de sistema cor
respondem s aes do ator no cenrio de determinado caso de uso. Sendo as
sim, relativamente fcil identificar eventos de sistemas em uma descrio de
caso de uso: devemos procurar nessa descrio os eventos que correspondem a
aes do ator. No caso particular em que o ator um ser humano e existe uma
interface grfica para que o mesmo interaja com o sistema, os eventos do siste
ma so resultantes de aes desse ator sobre essa interface grfica, que corres
ponde a objetos de fronteira.

F o rn e cim e n to de G r e ^ M h iUb # Ffniclmno de Grade

1 Dados do pofessoc I dopf


f^atrkula: Mtraiai Nome;
^30919721 1 ValkjarMarfciia | Eduardo Bezerra 1^1972 VaMar Matraa Eduardo Bezerra

Disciplinas Ksponididades R sc f*V 3 S C t e p r d ^ a t e s

1 Disdptna I Dia &mana HorarKiel Hora final

[f4DSr Modelagem de Ssbernas I v j ! 0Qi3O 11:30 1


m
; Cdigo Nome Qtd. crmos Hora Jrtte Hora Priai
' moSI 'Modefa^em de Stsiemas l [a . 7:0O 10:40
,N<S .Engwibaia d sStware 5 ..... 1 Qurta*fdr ;OS:30 11:30
,POO Programao Orientada a Cjstos !04 i Qjari:a-#eira '14:30 18:00
; DBO 'Administraio de Dtnos de Dadiss |04 "1 sexta-feird iCf7:00 10:40
: L..., ...

[ Registrar Crade
1 [ Grade |

Figura 7-23: Relao entre eventos de sistema e objetos de fronteira.

Para esclarecer melhor a origem dos eventos de sistema na interface gr


fica da aplicao, considere a Figura 7-23, em que apresentamos o prottipo
de um dos formulrios de nosso estudo de caso, o SCA. Esse formulrio cor
responde ao caso de uso Fornecer Grade de Disponibilidades (ver a Seo
4.7.3). Neste formulrio, o professor pode configurar sua grade disponibili
dade, que corresponde a um agregado de disciplinas que deseja lecionar e de
dias e horrios em que est disponvel para lecionar no prximo semestre le
tivo. A princpio, o professor deve fornecer sua matrcula e solicitar sua vali
dao pelo sistema (atente para o boto Vai idar Matrcula). Evidentemen
te, essa solicitao, que corresponde a um evento de sistema, desencadeia
uma seqncia de aes executadas pelos objetos componentes do SCA. Ou
seja, essa solicitao do ator um tpico evento de sistema. Se a validao da
matrcula do professor tiver sucesso, este pode montar sua grade (note as
duas abas no formulrio para fornecimento de disponibilidades). Ao final da
montagem de sua grade, o professor pode solicitar ao sistema que este faa o
registro da mesma. Em resumo, temos neste exemplo a seguinte lista de
eventos de sistema:
MODELAGEM DE INTERAES 213

Solicitao de validao de matrcula de professor.


Solicitao de adio de uma disciplina grade.
Solicitao de adio de um item de disponibilidade (dia, hora inicial e
hora final) grade.
Solicitao de registro da grade.

Embora o exemplo anterior tenha sido dado no contexto de um formul


rio, importante notar que nem todo evento de sistema originado em um
objeto de fronteira correspondente a uma interface grfica. Em vez disso, um
evento de sistema corresponde a qualquer ocorrncia na fronteira do sistema
que o leve a reagir de alguma forma; essa ocorrncia pode mesmo ser gerada
por um ator que no seja um ser humano (por exemplo, outro sistema ou um
equipamento).
Mas, por que os eventos de sistema so importantes para a modelagem de
interaes? Esses eventos so importantes para essa atividade porque as intera
es entre objetos de um sistema acontecem por conta do acontecimento da
queles. Ou seja, um evento de sistema alguma ao tomada por um ator que re
sulta em uma seqncia de mensagens trocadas entre os objetos do sistema. Por
tanto, o ponto de partida para a modelagem de interaes a identificao dos
eventos do sistema. Uma vez feita essa identificao, podemos desenhar diagra
mas de interao que modelam como os objetos colaboram entre si para produ
zir a resposta desejada a cada evento do sistema.
Apresentamos agora os passos do procedimento para construo dos dia
gramas de interao.

1. Para cada caso de uso, selecione um conjunto de cenrios relevantes.


Certamente, o cenrio correspondente ao fluxo principal do caso de uso
deve ser includo nessa seleo. Considere tambm fluxos alternativos e
de exceo que tenham potencial em demandar responsabilidades de
uma ou mais classes.
2. Para cada cenrio selecionado no passo anterior, identifique os eventos de
sistema:
a. Posicione o(s) ator(es), objeto de fronteira e objeto de controle no
diagrama.
b. Para cada passo do cenrio selecionado, defina as mensagens a serem
enviadas de um objeto a outro.
c. Defina as clusulas de condio e de iterao, se existirem, para as
mensagens.
d. Adicione multiobjetos e objetos de entidade medida que a sua par
ticipao for necessria no cenrio selecionado.
214 prin c pio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E ELSEVIER

Em relao ao passo 1, a definio dos cenrios depende da complexidade


do caso de uso. Um cenrio relevante pode corresponder ao fluxo principal, a
um fluxo alternativo, a um fluxo de exceo, a uma parte de um fluxo (um ou
mais passos) ou mesmo a todo o caso de uso.
Acerca do passo 2a, note que a ordem de disposio dos objetos no caso par
ticular do diagrama de seqncia aquela: primeiro posicionamos o ator prim
rio (que dispara a realizao do caso de uso); a seguir ( direita), posicionamos o
objeto de fronteira que interage com o ator primrio; direita desse objeto de
fronteira, posicionamos o controlador do caso de uso. Finalmente, direita do
controlador, devemos posicionar os demais objetos que participam do cenrio
em questo; esses objetos correspondem a objetos de entidades e a outros obje
tos identificados na fase de projeto (na maioria das vezes, esses outros objetos
so fabricaes puras; ver Seo 7.5.3).
No passo 2b do procedimento, para definir as mensagens que devem ser en
viadas, o modelador deve se basear nas responsabilidades de cada objeto envol
vido, conforme as dicas descritas na Seo 7.5.3. Alm disso, os princpios de
coeso e acoplamento (que discutimos na Seo 7.5.2) devem ser levados em
conta com o objetivo de realizarmos uma boa modelagem de interaes.
Um ponto importante na produo de diagramas de interao acerca de
como representar as requisies que chegam a um objeto de fronteira. Essas re
quisies normalmente so rotuladas com a informao fornecida pelo ator
(por exemplo, nome da disciplina, matrcula etc.). Essas informaes so poste
riormente repassadas do objeto de fronteira para o objeto de controle atravs de
parmetros de mensagens.
tambm importante notar que, de uma forma geral, as mensagens envia
das pelo objeto de fronteira como conseqncia do acontecimento de algum
evento de sistema resultam na definio das operaes no objeto controlador do
caso de uso em questo. Por exemplo, se continuarmos no exemplo do formul
rio de fornecimento de disponibilidades que comeamos no incio desta Seo,
chegamos constatao de que o controlador do caso de uso em questo deve
possuir as seguintes operaes:
va iid arP rofessor(m atrcula )
adi ci onarDi sei p1i na(nomeDi sei p li na)
adicionarItem Disponibi1idade(dia, h o r a i n ic ia l , horaFinal)
registrarGrade( )

As operaes anteriormente listadas so exemplos de operaes de sistema.


Uma operao de sistema qualquer operao que deve ser executada para re
cepcionar um evento de sistema. Uma operao de sistema normalmente alo
cada a um objeto controlador. Obviamente, diversas outras operaes so invo
cadas como conseqncia da chamada de uma operao que de sistema. Ou
MODELAGEM DE INTERAES 215

seja, uma vez que uma operao de sistema identificada, devemos tambm
identificar as operaes que devem ser invocadas subsequentemente para que a
tarefa correspondente seja executada pelos objetos do sistema. A identificao
correta dessas operaes subseqentes e sua correta alocao aos objetos do sis
tema no so tarefas fceis. Entretanto, pelo menos o modelador tem um ponto
de partida para comear essa identificao: os eventos do sistema identificados
anteriormente. Uma vez identificados esses eventos, a definio das operaes
de sistema correspondentes um processo relativamente fcil e mecnico: dado
um evento de sistema, definimos uma operao de sistema correspondente (ou
seja, uma mensagem enviada ao objeto de controle) e definimos nessa operao
parmetros (ver Seo 8.3.1) que permitam que as informaes necessrias
execuo da operao seja passadas de um objeto a outro. A partir desse ponto, a
identificao das operaes (ou equivalentemente, das mensagens) subseqen-
tes uma tarefa complicada, cuja correta realizao depende muito da experin
cia do modelador. As dicas de atribuio de responsabilidades e os conceitos
que definimos na Seo 7.5.3 devem ajudar na realizao dessa tarefa.

7.6 Modelo de interaes em um processo iterativo


Uma questo relevante acerca de qual o momento adequado para comear a
construir o modelo de interaes. Alguns textos sobre modelagem de sistemas
orientados a objetos indicam o incio da modelagem de interaes j na ativi
dade de anlise. Outros defendem o incio de sua construo somente na ativi
dade de projeto. O fato que a distino entre essas duas fases no to ntida na
modelagem orientada a objetos, e diagramas de interao podem ser utilizados
em ambas as fases. Na anlise, podemos comear a construir os diagramas de in
terao logo depois que uma primeira verso do diagrama de casos de uso esti
ver pronta. Inicialmente, o diagrama de interao pode ser utilizado para repre
sentar apenas os objetos participantes e com mensagens exibindo somente o
nome da operao. Posteriormente (na fase de projeto), esse diagrama pode ser
refinado com mais detalhes, incluindo criao e destruio de objetos, detalhes
sobre o tipo e assinatura completa de cada mensagem.
Os objetivos da construo de diagramas de interao so (1) obter infor
maes adicionais para completar e aprimorar outros modelos (modelo de ca
sos de uso e modelo de classes) e (2) fornecer aos programadores uma viso de
talhada dos objetos e mensagens envolvidos na realizao dos casos de uso do
sistema. De uma forma mais geral, da natureza de um processo incremental e
iterativo que os modelos evoluam em conjunto durante o desenvolvimento do
sistema. Embora esses modelos representem vises distintas do sistema, eles
so interdependentes. Os itens a seguir demonstram como o modelo de intera
es se relaciona com os modelos de casos de uso e de classes.
216 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Modelo de casos de uso modelo de interaes. Utilizamos os cenrios ex


trados do modelo de casos de uso como fonte de identificao de mensa
gens na modelagem de interaes.
Modelo de classes - modelo de interaes. Utilizamos informaes prove
nientes do modelo de classes para construir diagramas de interao (ver
Seo 7.3.3). Em particular, algumas responsabilidades j podem ter sido
definidas durante a modelagem de classes de anlise. Isso particular
mente verdadeiro quando a modelagem CRC (ver Seo 5.4.3.1) foi utili
zada durante a anlise. Note tambm que a notao do diagrama de inte
raes no precisa ser totalmente utilizada inicialmente. Na fase de anli
se, podemos construir diagramas de interao utilizando apenas os ele
mentos de notao essenciais. Em particular, podemos definir diagramas
de interao que apresentam apenas os nomes das mensagens. Essa defi
nio inicial posterior e iterativamente detalhada com a utilizao da
sintaxe mais avanada fornecida pelos diagramas de interao.
Modelo de interaes "modelo de casos de uso. A partir do conhecimento
adquirido com a construo dos diagramas de interao, podemos aper
feioar e validar os cenrios do modelo de casos de uso.
Modelo de interaes -modelo de classes. atravs da construo de
diagramas de interao que surgem informaes necessrias para a
alocao e o detalhamento de operaes para classes. A esse respeito,
existem inclusive/erramentas CASE (ver Seo 2.6) que automatica
mente alteram o diagrama de classes, adicionando uma operao
classe do objeto receptor aps o modelador adicionar uma mensagem
no diagrama de interao. Ou seja, nessas ferramentas, o diagrama de
classes completado de modo automtico pela construo de um dia
grama de seqncia ou de comunicao. Por outro lado durante a
construo de um diagrama de interao, pode ser que algumas infor
maes necessrias em certa classe ainda no existam, em virtude de
no terem sido identificadas anteriormente. Portanto, alm da identi
ficao de operaes, provvel que novos atributos de classes sejam
identificados durante a construo de diagramas de interao. Outro
elemento do modelo de classes que comumente identificado ou vali
dado pela construo do modelo de interaes so as associaes: uma
mensagem implica a existncia de uma associao (ou algum outro
tipo de dependncia; ver Seo 8.4.1) entre os objetos envolvidos. Ei-
nalmente, tambm comum a situao em que identificamos novas
classes durante a modelagem de interaes.
Modelo de interaes vises de classes participantes. Este tpico parece
redundante quando consideramos o tpico anterior. Afinal, as vises de
classes participantes (ver Seo 5.5.3) fazem parte do modelo de classes.
MODELAGEM DE INTERAES 217
ELSEVIER

Entretanto, a interdependncia entre o modelo de interaes e as VCP


importante o suficiente para descrevermos em um tpico em separado.
No Captulo 5, descrevemos o conceito de VCP como um diagrama que
apresenta as classes participantes da realizao de certo caso de uso do
sistema. Pois bem, uma VCP deve ser construda com base em informa
es obtidas a partir dos diversos diagramas de interao associados a um
mesmo caso de uso. Em particular, as corretas associaes do controlador
de um caso de uso com os objetos de entidade que aparecem na VCP s
podem ser validadas pela anlise das mensagens identificadas durante a
construo dos diagramas de interao.

A Figura 7-24 enfatiza a interdependncia entre os artefatos de software


produzidos pelos trs modelos mencionados h pouco. As setas indicam que as
atividades de modelagem alimentam umas as outras com informaes para que
cada modelo evolua.
Como um comentrio final nesta seo, importante notar que a modela
gem dinmica de um sistema uma tarefa complicada. Em um sistema comple
xo, h uma quantidade imensa de possveis caminhos que sua execuo pode
tomar. Nesse cenrio, difcil escolher que classe deve assumir cada comporta
mento. Nessa situao, a melhor alternativa trabalhar iterativamente: desen
volva seus modelo de casos de uso e seu modelo de classes iniciais; aps isso, de-

Projeto da Interface Grfica


F ig u r a 7 -2 4 : Interdependncia entre os artefatos
produzidos durante o desenvolvimento.
218 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

senvolva o modelo de interaes e de estados (para este ltimo, ver o Captulo


9); finalmente, retorne aos modelos iniciais para verificar a consistncia dos
mesmos, internamente, e em relao aos demais modelos.

7.7 Estudo de caso


Continuando o desenvolvimento da modelagem do Sistema de Controle Acad
mico, esta seo apresenta uma parte do modelo de interaes para este sistema.
A Figura 7-25 ilustra um diagrama de comunicao para um dos eventos de sis
tema do fluxo principal do caso de uso Realizar Inscrio (a descrio deste
caso de uso se encontra na Seo 4.7.3). Mais especificamente, esse diagrama re
presenta as trocas de mensagens entre objetos para realizar o passo 2 do referido
caso de uso. Esse passo repetido a seguir para facilitar o acompanhamento da
explicao.

"2. 0 sistema apresenta as disciplinas para as quais o aluno tem pr-requisito

De acordo com a Figura 7-25, podemos perceber que apenas um evento de


sistema de um caso de uso pode ser complexo o suficiente para justificar a cons
truo de um diagrama de interaes. No passo 2 em questo, o sistema deve
apresentar uma lista de disciplinas para que o aluno selecione aquelas nas quais
deseja se inscrever no prximo semestre letivo. No entanto, essa lista de discipli
nas no deve conter as que o aluno j cursou; tambm no deve conter as disci
plinas para as quais o aluno no tem pr-requisitos. Para formar essa lista e repassar
ao objeto de fronteira, o objeto controlador coordena a colaborao de diversos ob
jetos de entidade. A Figura 7-26 apresenta o diagrama de seqncia equivalente.
Ainda no diagrama apresentado na Figura 7-25, podemos perceber o padro
de comunicao entre objetos descritos na Seo 5.4.2.1. O objeto de fronteira
Formul ri oinscri o se comunica com o ator Al uno. Esse mesmo objeto de frontei
ra tambm se comunica com o objeto de controle Controlador Inseri o. Este, por
sua vez, se comunica com os objetos de entidade envolvidos no cenrio.
A Eigura 7-27 ilustra outro diagrama de comunicao para o caso de uso Rea-
1i zar Inseri o. Esse diagrama representa a troca de mensagens resultante da
realizao do passo 4 do caso de uso. Esse passo reproduzido a seguir. Nesse
passo, o controlador coordena o processo de inscrio: para uma disciplina de
sejada pelo aluno (cujo cdigo dado por cDi sei pl i na), o controlador percorre
a coleo de ofertas existentes com o objetivo de encontrar uma oferta em que
haja vagas para inscrever o aluno. Finalmente, quando essa oferta de disciplina
encontrada, o controlador solicita que o objeto Al uno se inscreva na mesma. A
Figura 7-28 apresenta o diagrama de seqncia equivalente.
218 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

senVOIva o modelo de interaes e de estados (para este ltimo, ver o Captulo


9); finalmente, retorne aos modelos iniciais para verificar a consistncia dos
mesmos, internamente, e em relao aos demais modelos.

7.7 Estudo de caso


Continuando o desenvolvimento da modelagem do Sistema de Controle Acad
mico, esta seo apresenta uma parte do modelo de interaes para este sistema.
A Figura 7-25 ilustra um diagrama de comunicao para um dos eventos de sis
tema do fluxo principal do caso de uso Real izar Inscrio (a descrio deste
caso de uso se encontra na Seo 4.7.3). Mais especificamente, esse diagrama re
presenta as trocas de mensagens entre objetos para realizar o passo 2 do referido
caso de uso. Esse passo repetido a seguir para facilitar o acompanhamento da
explicao.

"2. 0 sistema apresenta as disciplinas para as quais o aluno tem pr-requisito


(conforme a RN03), excetuando-se as que h tinha cursado."

De acordo com a Figura 7-25, podemos perceber que apenas um evento de


sistema de um caso de uso pode ser complexo o suficiente para justificar a cons
truo de um diagrama de interaes. No passo 2 em questo, o sistema deve
apresentar uma lista de disciplinas para que o aluno selecione aquelas nas quais
deseja se inscrever no prximo semestre letivo. No entanto, essa lista de discipli
nas no deve conter as que o aluno j cursou; tambm no deve conter as disci
plinas para as quais o aluno no tem pr-requisitos. Para formar essa lista e repassar
ao objeto de fronteira, o objeto controlador coordena a colaborao de diversos ob
jetos de entidade. A Figura 7-26 apresenta o diagrama de seqncia equivalente.
Ainda no diagrama apresentado na Figura 7-25, podemos perceber o padro
de comunicao entre objetos descritos na Seo 5.4.2.1. O objeto de fronteira
Formul rioinscri o se comunica com o ator Al uno. Esse mesmo objeto de frontei
ra tambm se comunica com o objeto de controle Control a dorinscri o. Este, por
sua vez, se comunica com os objetos de entidade envolvidos no cenrio.
A Figura 7-27 ilustra outro diagrama de comunicao para o caso de uso Rea
lizar Inscrio. Esse diagrama representa a troca de mensagens resultante da
realizao do passo 4 do caso de uso. Esse passo reproduzido a seguir. Nesse
passo, o controlador coordena o processo de inscrio: para uma disciplina de
sejada pelo aluno (cujo cdigo dado por cDi sei pl i na), o controlador percorre
a coleo de ofertas existentes com o objetivo de encontrar uma oferta em que
haja vagas para inscrever o aluno. Finalmente, quando essa oferta de disciplina
encontrada, o controlador solicita que o objeto Al uno se inscreva na mesma. A
Figura 7-28 apresenta o diagrama de seqncia equivalente.
Discipimas ainda no cursadas 1\
pelo aluno. Detalhamento para m
obteno desta lista no exibido
neste diagrama.
I Itransient)
A lu n o
dnc: Disciplina
I F o r m u l rio in s r rir
1.3: *[para cada] d := prximoO
obterDisciplinasPossveisO j
d: Disciplina
1.3.1: dpre := obterPrRequisitosO
Disciplinas em que o aluno est
Controladorinscrico
apto a se inscrever, para exibio 1: obterDisciplinasPossveisO-*
pelo objeto de fronteira.

.1 .2 : dnc := obterDisciplinasNoCursadasO
OfertaDiscinlina - | Aluno
d iscip lin a P o ssv e l. Disciplina 1.1: dc := obterDisciplinasCursadasO

l . 1.1.1.1 3 2: [dpre est contido em do] adicionar(d) |

I p- Participao [ Se os pr-requisitos de d ci,


foram cursados, ento, o aluno
1 1 . 1 ,1.1: [participao est apto a se inscrever cm uma Hp- ni.sciplina
oferta de d. o
o
>
CD
finalizada] adictonarfdtscipUnaPossivel)
I 1.1.1.2: [participaao O
m
Z
33
>
O'
m
CO
--0
veis)-
p.' (obter
Realizar Inscri^o
ca so de uso
do
. um evento
comnnlcado pa v
de
7 -2 5 : Diagram a
fig u r a
>
>'

Fig u ra 7-26: Diagrama de sequncia para um cenrio do caso de uso Realizar inscrio (obter disciplinas possveis).
w
CO
o
o
>
CD

Figura 7-27: Diagrama de comunicao para um evento de sistema do caso de uso Realizar Inscrio (inscrever aluno). >>
<D
o>
>

F ig u ra 7-28: Diagrama de sequncia para um cenrio do caso de uso Realizar Inscrio (inscrever aluno).
W'
ct
/:
W
w
MODELAGEM DE INTERAES 223
ELSEVIER

"4. Para cada disciplina selecionada, o sistema designa o aluno para uma turma
que apresente uma oferta para tal disciplina."

Outro exemplo de diagrama de comunicao para o mesmo caso de uso Rea-


1izar Inscrio se encontra na Figura 7-29. Dessavez, o evento de sistema con
siderado corresponde ao fluxo de exceo no qual o sistema insere o aluno em
uma lista de espera, considerando que no existe oferta disponvel para alguma
disciplina em que esse aluno quis se inscrever. A Figura 7-30 apresenta o diagra
ma de seqncia equivalente.
Na Seo 7.4, mencionamos um novo diagrama introduzido pela UML
2.0, o diagrama de viso geral da interao (interaction overview diagram).
Como seu prprio nome diz, esse diagrama permite ter uma viso de alto n
vel de certa interao. Para dar um exemplo desse diagrama em nosso estudo
de caso do SCA, considere a Figura 7-31. Nesta figura, apresentamos o dia
grama de viso geral da interao para o caso de uso Real i zar Inseri o. O
diagrama de viso geral da interao um tipo especial de diagram a de ativi
dade. Para uma explicao mais detalhada da notao utilizada em diagrama
de atividade, veja o Captulo 10.
>
: LislaEspera
Coleo de listas de esper;h >'
existentes no sistema,
Aluno que est

requisitando inscries

Objeto fabricao pura criadol t2 .3 [Ic no existel; adicionar(le)


Cdigo da disciplina em 1\ para desP^^'^r (tornar menos
cuja lista de espera o complexQ) o controlador.
a: Aluno
aluno deve ser inserido i 2.1 : le : : localizarLisla(d)
Aluno O
pos := colocarAlunoEmF-spera(cdigo) -
Verifica se a lista de
Controladorinscrico : GerenteListasEspera I
espera para a disciplina
2; pos := inscrir(a, d) -
j existe.
Posio na qual o aluno foi
inserido na lista de espera. i 1: d := encontrv(cdigo) I 2.4: pos := inscrir(a)

i 2.2 [le no existe]: criar(d)


Lista de disciplinas previamente a
selecionadas pelo aluno. Se a lista de espera
ds: Disciplina
le: LislaEspera para a disciplina no
existe, ela criada.
2.2,1: conectar(d) t

F ig u ra 1-29'. Diagrama de comunicao para um evento do sistema do casd de uso Realizar inscrio (incluso em lista de espera).
M
t-r
C
M O
<
M
sd Adicionar Aluno em Lista de E s p e r ^

Objeto fabricao pura criado Coleo de listas dc espera


Lista de disciplinas previamente*"
para desonerar (tornar menos existentes no sistema.
selecionadas pelo aluno.
complexo) o controlador.____

V I
Aluno [Formula riinscric] Controladorinscrico f ds: Disciplina ll I GerenteListaEspera
^
-------------
] I ListaEspera [J ferListalZspeia |

d ;= encontrar(cdigo) I

inserir(a, d)

O objeto a o aluno quel\^ IcJ := localizarLisla(d)


est rcc[Usitando inscries. ______I
O controlador possui uma
referncia para esse objeto.
alt [lel = null]
7
create (d)
le2: ListaEspera
j------- ------- j
conectar(d)
adicionar(le2)

pos := inserir(a)

TI
(else) >
o
pos := inserir(a)

pos

>
o>
Figura 7-30: Diagrama de sequncia para um evento de sistema do caso de uso Realizar Inscrio (incluso em lista de espera).
226 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Figura 7-31: Diagrama de viso geral da interao para o caso de uso R ealizar In scri o .
MODELAGEM DE INTERAES 227
ELSEVIER

exerccios

7-1: Descreva a posio do diagrama de interao no processo de desenvolvimento incremen


tai e iterativo. Quando eles so utilizados? Para que so utilizados?

7-2: Ivar Jacobson disse uma vez: "Somente aps a construo de diagramas de interao para
os cenrios de um caso de uso pode-se ter certeza de que todas as responsabilidades que os ob
jetos devem cumprir foram identificadas." Reflita sobre essa afirmativa.

7-3: Considere o fragmento de diagrama de seqncia a seguir. Determine a ordem na qual as


mensagens ml e m2 sero passadas.

7-4: Desenhe um diagrama de comunicao equivalente ao diagrama de seqncia do exerccio


anterior.

7-5; Uma mensagem enviada a um objeto invoca a execuo de uma de suas operaes. Por ou
tro lado, em linguagens de programao estruturadas (no orientadas a objetos) existe o con
ceito de chamada de sub-rotinas, em que sub-rotinas fazem chamadas a outras sub-rotinas den
tro de um mdulo de um programa. Discuta as semelhanas e as diferenas entre os conceitos
de passagem de mensagem e de chamada de sub-rotinas.

7-6: De acordo com a diviso de responsabilidades pelos objetos de um sistema, a colaborao


entre eles para a realizao de um cenrio pode ser classificada em um espectro que vai desde a
forma centralizada at a forma descentralizada.'^ Na primeira forma de colaborao (centralizada),
a inteligncia do sistema est concentrada em um nico objeto. Por outro lado, na forma descen
tralizada, a inteligncia do sistema est mais uniformemente espalhada pelas classes. A figura a
seguir apresenta de maneira esquemtica as duas estratgias de colaborao, utilizando a nota
o vista para diagramas de seqncia. Note que, na estratgia centralizada, h um objeto que
controla os demais (Obj 1). J na estratgia descentralizada, h uma cadeia de delegaes entre
os objetos; no h um objeto central que "conhece" todos os demais. Cada objeto realiza uma par
te da tarefa. Discuta as vantagens e desvantagens de cada uma dessas estratgias.

2 Essas estratgias so tambm chamadas de garfo (fork) e escada (stair), respectivamente.


228 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UME, 2/E ELSEVIER
8
Modelagemdeclasses deprojeto

A perfeio (no projeto) alcanada, no quando no h nada mais para


adicionar, mas quando no h nada mais para retirar.
- ERIC RAYMOND, THE CATHEDRAL AND THE BAZAAR

ste captulo descreve algumas das transformaes pelas quais passam


as classes e suas propriedades (atributos, operaes e associaes) com
mmm O objetivo de transformar o modelo de classes de anlise no modelo de
classes de projeto. Neste captulo, tambm estudamos outros elementos do dia
grama de classes que no so considerados no modelo de anlise e que so ne
cessrios construo do modelo de projeto. Esses elementos permitem adicio
nar mais rigor ao diagrama de classes do sistema. Por exemplo, podemos definir
o tipo de cada atributo, a assinatura de cada operao, a navegabilidade de cada
issociao etc. tambm objetivo deste captulo descrever conceitos que sur
uru durante a modelagem de classes de projeto, tais como classes abstratas, in
terfaces, polimorfismo e padres de projeto.

8.1 Transformao de classes de anlise


em classes de projeto
Esta seo descreve as transformaes e os refinamentos que classes de frontei
ra, de controle e de entidade sofrem na passagem para o modelo de classes de
projeto.
230 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

8.1.1 Especificao de classes de fronteira


Classes de fronteira devem apenas servir como um ponto de captao de infor
maes a partir do ambiente, ou de apresentao de informaes que o sistema
(modelo) processou. Portanto, um primeiro ponto importante acerca da especi
ficao de classes de fronteira que no devemos atribuir a essas classes respon
sabilidades relativas lgica do negcio. A nica inteligncia que essas classes
devem ter a que lhes permite realizar a comunicao com o ambiente do siste
ma. H diversas razes para isso. Em primeiro lugar, se o sistema tiver que ser
implantado em outro ambiente, as modificaes resultantes sobre seu funcio
namento propriamente dito (isto , excluindo as interaes com o novo ambien
te) seriam mnimas. Alm disso, o sistema pode dar suporte a diversas formas de
interao com seu ambiente (por exemplo, uma interface grfica e uma interfa
ce de texto). Finalmente, essa separao resulta em uma melhor coeso (ver Se
o 7.5.2) das classes de fronteira.

Registro de Inscries m
D a d o s d o a iuno

M atrcula; Nom e:

Validar M atrcula Maria Eduarda

Disciplina

i M D S I - M o d e la ge m de S iste m a s I

Disciplinas S e le c io n a d a s p a r a In sc ri o

C d ig o N om e Q td. crdito s

M D SI M o d e la ge m d e S iste m a s I 04
EN G E n g e n h a r ia d e So ftw a re 04
POO P ro g ra m a o O rie n ta d a a O b je to s 04
ADBD A d m in istra o d e B a n c o s d e D a d o s 04

R e g ist ra r In sc ri e s

Figura 8-1: Classe de fronteira para interao com o usurio: formulrio de inscrio.

Outro aspecto importante que, durante a anlise, considera-se que h uma


nica classe de fronteira para cada ator que participa de um caso de uso. Na pas
sagem para o modelo de classes de especificao, cada classe de fronteira pode
gerar vrias outras classes. Nessa transformao, devemos considerar os dife
rentes tipos de classes de fronteira; classes de interface com o usurio, classes de
interface com equipamentos e classes de interface com outros sistemas.
A seguir enumeramos as principais formas de interao com o ambiente que
podem existir em um sistema de software. Para todas elas, o projeto de classes
MODELAGEM DE CLASSES DE PROJETO 231

Visualizcio de AmiaSes
D d d o s d o iuno

Mtrcula: Nome:

O 0 I0 9 1 0 3 Vd^dar Matrcula Maria Eduarda

A no: Perodo le tivo :

2006 fekn O S e g u n d o Visualizar AvaBaes

L e ge n d a
RF Reprovado por Falta AP Aprovado RM Reprovado pw Mlda
Avaliaes d o aluno:

Disciplina Pl P2 PF Freqncia S t u ^ &


M D S I - M odelagem d e Sistem a 7,0 9 ,0 ... 76% AP
P O O - P rogram ao Orientada a O bjetos 6,9 4 ,6 5 ,8 88% RM
|BDI - B a n c o s d e D a d o s 5,4 5 ,8 8 ,0 95% AP
j U ^ S O C - Infotm tica e Sociedade 8 ,7 7 ,8 1 56%. RF

Figura 8-2: Classe de fronteira para interao


com 0 usurio: visualizao de avaliao.

de fronteira necessrio. importante tambm notar que as formas necessrias


de interao do sistema com seu ambiente influenciam no projeto arquitetural
desse sistema. Descrevemos o projeto arquitetural no Captulo 11.

1. Clientes WEB clssicos. Essa a forma mais comum de interao em


aplicaes WEB. A classe de fronteira representada por pginas HTML.
Muitas vezes, essas pginas so dinmicas, ou seja, so geradas pelo siste
ma em funo de estmulos que este recebe de seu ambiente. Note que,
neste caso, embora as fronteiras do sistema sejam representadas como
classes na fase de anlise, na fase de projeto essas classes so realizadas
como pginas HTML.
2. Clientes mveis. cada vez mais comum o uso da tecnologia mvel em
todas as reas de negcio. Telefones celulares e computadores manuais
so cada dia mais freqentes e interativos. Para esse tipo de interao
com o ambiente, normalmente so necessrias classes de fronteira que
implementem algum protocolo especfico com o ambiente. Um exemplo
a WML (Wireless Markup Language).
3. Clientes stand-alone. possvel tambm que a aplicao tenha que for
necer uma interface grfica por meio de formulrios, com botes, menus
etc. Nesse caso, recomendvel que os desenvolvedores pesquisem os
recursos fornecidos pelo ambiente de programao sendo utilizado.
Muitos desses ambientes fornecem componentes para construo de in
terfaces grficas. Um exemplo disso o Swing/JFC da linguagem Java.
232 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E E L S E V IE R

4. Servios WEB. Outra tecnologia cujo uso est se tornando bastante co


mum a de servios WEB (WEB services). Um servio WEB uma forma
de permitir que uma aplicao fornea seus servios (funcionalidades)
pela Internet.

Nos casos 1 e 3, as classes de fronteira correspondem interface como seres


humanos. Uma atividade importante de um processo de desenvolvimento que
envolve essas classes o projeto da interface grfica com o usurio. Nessa ativida
de, so especificados aspectos de aparncia e disposio dos componentes grfi
cos, assim como de navegao pelos diversos formulrios da aplicao. Confor
me mencionamos na Seo 6.5, o projeto de interface grfica com o usurio est
fora do escopo deste livro.
Nos casos 2 e 4, o sistema deve se comunicar com outro sistema de software
ou com um dispositivo (equipamento). Como exemplo, em nosso estudo de caso
do Sistema de Controle Acadmico (ver Seo 4.7), temos um ator denominado
Sistema de Faturamento, correspondente a um sistema externo. Nesse estudo de
caso, o SCA deve se comunicar com o Sistema de Faturamento, um sistema exter
no. Nesse caso, podemos criar uma classe denominada SistemaFaturamento para
encapsular o comportamento de interao com o sistema externo. Entretanto,
tambm possvel a situao em que a interao com um sistema externo to
complexa que no seja adequado encapsul-la em uma nica classe. Nesse caso,
necessrio substituir a classe de fronteira identificada na fase de anlise por um
subsistema. Este ltimo serve para representar a comunicao com o sistema ex
terno. Alm disso, esse subsistema agrupa todas as classes necessrias nessa co
municao e prov uma interface (ver Seo 8.5.4) a partir da qual seus servios
podem ser obtidos. (Subsistemas so descritos do ponto de vista arquitetural no
Captulo 11.). A substituio de uma classe de fronteira por um subsistema nor
malmente feita com o uso do padro de projeto Faade (ver Seo 8.7.6).

8.1.2 Especificao de classes de entidade


As classes de entidade so aquelas que representam os conceitos do domnio
que o sistema deve processar. Essas classes representam as informaes e as re
gras de negcio que direcionam a manipulao dessas informaes. Em nosso
estudo de caso, exemplos de classes de entidade so Al uno. Professor, OfertaDi s-
ci pl i na etc. Classes de entidade tambm so chamadas de classes do negcio. A
seguir, algumas dicas que devem ser seguidas durante a especificao das res
ponsabilidades de uma classe de entidade.
A maioria das classes de entidade normalmente permanece na passagem da
anlise ao projeto. Na verdade, classes de entidade so em geral as primeiras
classes a serem identificadas, na anlise de domnio (ver Seo 2.1.2).
MODELAGEM OE CLASSES DE PROJETO 233

Durante a fase de projeto, outro aspecto importante a considerar sobre clas


ses de entidade identificar quais delas geram objetos que devem ser persisten
tes. Para essas classes, o seu mapeamento para algum mecanismo de armazena
mento persistente deve ser definido. No Captulo 12, tratamos da questo da
persistncia de objetos, enfocando o caso no qual o mecanismo de armazena
mento um sistema de gerenciamento de bancos de dados relacional (SGBDR).
Um aspecto importante durante o refinamento do modelo de classes de pro
jeto e relativo s classes de entidade a forma utilizada para representar os rela
cionamentos (associaes, agregaes e composies) entre seus objetos. Essa
representao funo da navegabilidade e da multiplicidade definidas para a as
sociao. Descrevemos a especificao de associaes na Seo 8.4.
Outro aspecto relevante durante a especificao de uma classe de entidade
diz respeito ao modo como podemos identificar cada um de seus objetos unica
mente. Por exemplo, um objeto da classe Aluno unicamente identificado pelo
valor de sua matrcula (um atributo do domnio). A manipulao dos diversos
atributos identificadores possveis em uma classe pode ser bastante trabalhosa.
Para evitar isso, normalmente os projetistas optam por criar um identificador de
implementao, que no tem correspondente com atributo algum do domnio da
aplicao. Uma vantagem dessa abordagem a possibilidade de manipular
identificadores de maneira uniforme e eficiente. Identificadores de implemen
tao so tambm teis quando esses objetos de entidade devem ser mapeados
para um mecanismo de armazenamento persistente, particularmente para um
SGBDR (sobre esse aspecto, ver Seo 12.1.2). Um tipo de dado normalmente
utilizado para representar identificadores de implementao o inteiro. Em
Java, por exem plo, temos os tipos de dados short, int e long, todos p o ssv eis de
serem utilizados para representar identificadores.

8.1.3 Especificao de classes de controle


Assim como as classes de fronteira, classes de controle so normalmente identi
ficadas na modelagem de classes da aplicao. Portanto, controladores normal
mente no so objetos do domnio, mas, sim, da aplicao, cuja responsabilida
de coordenar a interao entre outros objetos. Objetos controladores so, se
gundo Craig Larman,/abricaes puras (ver Seo 7.5.3).
Na atividade de projeto do modelo de classes, devemos refinar cada classe
de controle identificada durante a anlise. Normalmente, essa classe deve ser
particionada em duas ou mais outras classes para controlar diversos aspectos da
soluo. Isso feito com o objetivo de evitar a criao de uma nica classe com
baixa coeso e alto acoplamento (ver Seo 7.5.2). Alguns exemplos dos aspectos
de uma aplicao cuja coordenao (e no a realizao propriamente dita) de
responsabilidade das classes de controle so preenchimento de controles da in-
234 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSE\1ER

terface grfica, autenticao de usurios, controle de acesso a funcionalidades


do sisteraa.
Um tipo comum de objeto controlador o controlador de caso de uso, ao qual
j fizemos meno na Seo 5.4.2.3. Esse objeto responsvel pela coordenao
da realizao de um caso de uso em particular. Mais especificamente, as seguin
tes responsabilidades so esperadas de um tpico controlador de caso de uso:

Deve coordenar a realizao de um caso de uso do sistema.


Deve servir como canal de comunicao entre objetos de fronteira e obje
tos de entidade.
Deve comunicar-se com outros controladores, quando necessrio.
Deve mapear aes do usurio (ou atores de uma forma geral) para atuali
zaes ou mensagens a serem enviadas a objetos de entidade.
Deve estar apto a manipular excees provenientes das classes de entidades.

Em aplicaes WEB, comum a prtica de utilizar outro tipo de objeto con


trolador chamado/ront controller (FC). Um FC um controlador responsvel
por receber todas as requisies de um cliente (por exemplo, de um navegador
WEB ou de um aplicativo mvel). Esse objeto, ento, identifica qual o controla
dor adequado para processar a requisio, possivelmente mediante consulta a
algum servio de mapeamento de URLs para controladores especficos (ou seja,
controladores de caso de uso). Uma vez identificado o controlador de caso de
uso adequado para processar a requisio, o FC a despacha para ele. O controla
dor de caso de uso, por sua vez, coordena a execuo do caso de uso na produ
o da resposta esperada. Essa coordenao envolve o envio de mensagens para
a camada de objetos de negcio (que podem eles prprios enviar mensagens
para outros objetos de entidade), para outros objetos controladores existentes
no caso, ou para objetos mediadores (ver mais adiante). Sendo assim, um FC
um ponto central de entrada para as funcionalidades do sistema. Essa estratgia
torna mais fcil controlar alguns aspectos da aplicao, como, por exemplo, a
autenticao dos usurios. Um objeto FC um caso especial de controlador fa
chada, pelo fato de que sua tarefa recepcionar requisies provenientes dos
objetos de fronteira do sistema.
Embora a definio de um controlador para a aplicao como um todo seja
tpica de aplicaes WEB, nada impede que o mesmo esquema de colaborao
entre objetos seja utilizado em aplicaes convencionais (ou seja, para o desk
top). Por exemplo, em aplicaes do domnio de jogos, comum a criao de
um objeto que representa a aplicao como um todo e que responsvel pela re
cepo dos eventos do sistema.
Um controlador de caso de uso pode aumentar substancialmente o acopla
mento (ver Seo 7.5.2) do sistema, visto que ele serve de intermedirio entre os
MODELAGEM DE CLASSES DE PROJETO 235

objetos de fronteira e de entidade. Alm disso, controladores tm o potencial de


levar duplicao de cdigo. Por exemplo, considere o nosso estudo de caso, o
SCA. Nesse sistema, considere que dois casos de uso precisam apresentar ao
usurio uma lista de disciplinas. Nessa situao, os controladores desses casos
de uso teriam comportamento (cdigo) duplicado para produzir essa lista de
disciplinas. portanto importante que o projetista dispense o tempo que for ne
cessrio para evitar o projeto de controladores que apresentem essas caracters
ticas ruins (o acoplamento excessivo e a duplicao de cdigo). Uma alternativa
para solucionar esses problemas a definio de classes adicionais, cujo objetivo
diminuir o acoplamento do controlador, uma vez que servem de auxiliares do
mesmo durante a execuo do caso de uso. Atravs do uso dessas classes adicio
nais, 0 controlador fica livre de realizar certas tarefas por si prprio. Em vez dis
so, ele delega a realizao da tarefa para outro objeto. Essa estratgia tambm
tem a vantagem de permitir que esses objetos auxiliares sejam reutilizados em ou
tros casos de uso do sistema nos quais a mesma tarefa seja necessria novamente.
Objetos auxiliares normalmente no tm correspondente no domnio do negcio
(ou seja, so fabricaes puras). No entanto, so teis, pois tornam o sistema
mais flexvel, manutenvel e resultam em componentes mais reutilizveis. Na
prxima seo, descrevemos mais detalhadamente diversos aspectos do desen
volvimento que demandam a criao (ou a reutilizao) de classes adicionais.

8.1.4 Especificao de outras classes


Durante a fase de anlise, faz sentido pensarmos somente em objetos pertencen
tes categorizao BCE (ver Seo 5.4.2.1 ). Entretanto, um aspecto importante
acerca da fase de projeto que devemos definir todas as caractersticas do siste
ma que sejam necessrias implementao. Quando chegamos a essa fase, fica
claro que s objetos dessas classes no so suficientes para prover as funcionali
dades que se espera de um sistema de software. Portanto, a identicao de clas
ses no uma tarefa exclusiva da fase de anlise. Na fase de projeto tambm de
vemos nos preocupar em identificar classes para completar as funcionalidades
j fornecidas pelas classes provenientes da anlise. Nesse contexto, diversos as
pectos precisam ser levados em considerao. Alguns exemplos desses aspectos
para os quais precisamos definir classes so: distribuio do sistema por diver
sos ns de processamento e consequente necessidade de comunicao entre
suas partes, segurana, autenticao, autorizao, controle de transaes, regis
tro de operaes realizadas, armazenamento persistente de informaes, leitura
de parmetros de configurao a partir de arquivos no sistema operacional etc.
Cada um desses aspectos implica responsabilidades do sistema, para as quais o
projetista pode definir suas prprias classes, ou pode utilizar classes preexisten
tes definidas em bibliotecas de classes, padres de projeto oufram eworks. No res
tante desta seo, descrevemos alguns desses aspectos.
236 prin cpio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E E L S E V IE R

Quando falamos em uma aplicao no-distribuda, uma requisio de um


objeto a outro no ultrapassa os limites do n de processamento no qual o siste
ma est hospedado. Entretanto, quando falamos em uma aplicao distribuda
de uma, queremos dizer que as partes (subsistemas) componentes desta esto
fisicamente separadas em diferentes ns de processamento. No caso de haver
distribuio, surge o seguinte complicador: como dois objetos residentes em
partes fisicamente separadas da aplicao podem trocar mensagens? Em parti
cular, uma situao comum os objetos de fronteira correspondentes interfa
ce com usurios, e objetos de controle serem alocados em ns de processamen
to diferentes. Uma alternativa para resolver esse problema com o uso de clas
ses procuradoras (traduo para proxy classes). Classes procuradoras so aque
las cuja responsabilidade fazer com que mensagens entre objetos cruzem as
fronteiras entre os ns de processamento atravs de uma rede de comunicao.
O que acontece que um objeto residente em um n de processamento pode en
viar uma mensagem para um procurador. Este, por sua vez, cuida de repassar
essa mensagem para um objeto residente em outro n de processamento, d efor
ma transparente para o remetente. Ou seja, para o objeto remetente, tudo se passa
como se o receptor estivesse residente no n de processamento local. Dois
exemplos de tecnologias que podem ser utilizadas para implementar classes
procuradoras so RMI (sigla para Remote Method Invocation) e CORBA (sigla
para Common Object Request Broker Architecture). Uma estratgia de distribui
o alternativa para o uso de classes procuradoras copiar objetos de um n de
processamento para outro. Dessa forma, cpias do mesmo objeto so distribu
das e, assim, cada cpia pode receber mensagens sem que haja necessidade de
transporte da requisio pela rede de comunicao (como acontece com o uso
de objetos procuradores). Entretanto, a cpia de objetos tem a desvantagem de
possibilitar a inconsistncia entre as cpias criadas. Descrevemos mais detalhes
sohre a distribuio de um sistema na Seo 11.2, quando apresentamos a defi
nio da arquitetura fsica de um sistema.
comum, em aplicaes que envolvem interface grfica, a situao em
que determinado formulrio (objeto de fronteira) apresentado ao usurio
com alguns de seus controles (por exemplo, listas, menus suspensos) j preen
chidos com informaes provenientes dos ohjetos de negcio. Para exemplifi
car esse aspecto, considere a seguinte tarefa comum em uma aplicao: preen
chimento de controles da interface grfica. Considere novamente a Figura 8-1,
na qual apresentamos o prottipo do formulrio para inscrio do SCA. Note
que, quando este formulrio for apresentado ao usurio, o menu suspenso que
apresenta disciplinas disponveis para inscrio j deve estar preenchido.
Nesse caso, o objeto de controle pode delegar a outro objeto a obteno da lis
ta de disciplinas a ser apresentada no objeto de fronteira. Objetos cuja respon
sabilidade obter informaes e agreg-las em um formato especfico so cha
mados View Helpers (VH). Uma classe VH , portanto, qualquer classe que au-
MODELAGEM DE CLASSES DE PROJETO 237

xilie na apresentao de informaes presentes nas classes de negcio de uma


maneira reutilizvel.
Outro aspecto importante durante o projeto diz respeito definio de clas
ses para realizarem o acesso a um mecanismo de armazenamento persistente (por
exemplo, um SGBD). Essas classes so necessrias para a obteno e consolidao
de informaes provenientes dos objetos de negcio (entidades). Uma alternativa
para esse problema de projeto o uso de classes DAO (sigla para Data Access
Object). Uma classe DAO encapsula e implementa operaes CRUD (traduo
para create, read, update, delete) para manipulao de objetos do domnio. Obje
tos DAO normalmente so criados (instanciados) atravs de objetos fbrica (ver
Seo 8.6.4). Entretanto, classes DAO so uma das possveis alternativas para
acesso a um mecanismo de armazenamento persistente. Outras alternativas tc
nicas so o uso de um SGBD orientado a objetos ou de um framework de persis
tncia. Descrevemos essas tcnicas em mais detalhes na Seo 12-2.
Durante o desenvolvimento de um sistema, os projetistas devem usar o m
ximo de sua experincia e criatividade para definir uma soluo de classes a
mais adequada possvel para o problema em questo. Entretanto, tambm co
mum a reutilizao de classes e de solues preexistentes durante o desenvolvi
mento. Essas fontes de reutilizao devem ser pesquisadas pelos projetistas
para evitar o desenvolvimento (codificao) desnecessrio. Trs fontes de reuti
lizao so padres de projeto, bibliotecas de classes efram eworks. Descrevem os
essas ontes no que segue.
Um padro de projeto uma descrio da essncia da soluo para um pro
blema que ocorre de forma recorrente no desenvolvimento de software. Um pa
dro de software descreve um punhado de objetos em colaborao para solucio
nar o problema recorrente. Padres de software so normalmente identificados
e catalogados por desenvolvedores de software experientes. O uso de padres
de software permite que desenvolvedores sejam mais produtivos, pois evita que
estes desenvolvedores reinventem a roda durante o desenvolvimento: se exis
te algum padro de software para um problema com o qual o desenvolvedor se
depara, a soluo apontada por esse padro serve como ponto de partida. Des
crevemos alguns exemplos de padres de software na Seo 5.4.4 e na Seo 8.6.
Alm disso, as classes VEl, DAO e Eront Controller descritas nesta seo fazem
parte dos padres descritos no catlogo J2EE (Alur et a l , 2003).
Um fram ew ork uma coleo de classes em colaborao, assim como um
padro de projeto. Entretanto, h duas diferenas marcantes entre um frame
work e um pacfro cfe projeto. Fm primeiro ugar, um framework muito maior
(possui uma quantidade maior de classes) que o definido em um padro. Alm
disso, um framework apresenta implementao; em um padro, a soluo
apontada pelo mesmo deve ser implementada pelo desenvolvedor. Dois exem
plos de frameworks de cdigo aberto so o Hibernate (http://www.hibemate.org)
238 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

e o JUnit (http://www.junit.org). O primeiro um framework para persistncia


em um SGBD relacional para Java e .NET. O segundo um framework para au
xiliar o desenvolvedor a definir testes para sua aplicao.
Finalmente, uma biblioteca de classes corresponde a uma coleo de classes
que possuem algum objetivo especfico. Exemplos de bibliotecas de classe so a
JDBC e a Swing, existentes na linguagem Java, a primeira para acesso a um
SGBD relacional, e a segunda para a construo de interfaces grficas com o
usurio. Outro exemplo de biblioteca de classes bastante popular, dessa vez para
realizar o registro de operaes da aplicao, a Log4J (http://logging.apache.
orgog4j/docs/). As prprias plataformas de desenvolvimento como Java e .NET
j fornecem diversas bibliotecas de classes reutilizveis; a tecnologia RMI que
mencionamos anteriormente nesta seo um exemplo de biblioteca de classes
existente em Java.

8.2 Especificao de atributos

8.2.1 Notao da UML para atributos


No modelo de classes de anlise, os atributos, quando representados, o so so
mente pelo nome. No entanto, a sintaxe completa da UML para definio de um
atributo bem mais detalhada. Essa sintaxe, cujo uso apropriado para a fase de
especificao do modelo de classes, a seguinte:
[/^ v is ib ilid a d e nome: tipo = v a l o r i n i c i a l

Vamos descrever cada um dos elementos dessa sintaxe. (A Figura 8-3 ilustra
a utilizao desses elementos para atributos da classe Cliente.)
A v i s i b i l idade de um atributo diz respeito ao seu nvel de acesso. Ou seja, a
visibilidade permite definir quais atributos de um objeto so acessveis por ou
tros objetos. A visibilidade de um atributo pode ser pblica, protegida, privativa
ou de pacote. A primeira a visibilidade por omisso (se no for especificada vi
sibilidade alguma, essa assumida). O smbolo e o significado de cada visibili
dade so apresentados na Tabela 8-1.

Cliente
#nome : String
-dataNascimento : Data
-telefone : String
#/idade : int
#limiteCrdito : Moeda = 500.0
-quantidadeClientes : int
-idadeMdia : float

Figura 8-3: Especificao dos atributos da classe Cliente.


MODELAGEM DE CLASSES DE PROJETO 239

A propriedade de visibilidade serve para implementar o encapsulamento da


estrutura interna da classe. Somente as propriedades que so realmente neces
srias ao exterior da classe devem ser definidas com visibilidade pblica. Todo o
resto escondido dentro da classe atravs das visibilidades protegida e priva
tiva. Um atributo definido com a visibilidade protegida diz respeito ao conceito
de herana entre classes. Esse conceito descrito na seo 8.5.

Tabela 8-1: Possveis visibilidades de um elemento (atributo ou operao)

Visibilidade Smbolo Significado


Pblica + ! Qualquer objeto externo pode obter acesso ao
elemento, desde que tenha uma referncia para a
classe em que o atributo est definido.
Protegida # 0 elemento protegido visvel para subclasses da
classe em que este foi definido.
Privativa - 0 elemento privativo invisvel externamente para a
classe em que este est definido.
Pacote ~ 0 elemento visvel a qualquer classe que pertence
ao mesmo pacote no qual est definida a classe.

O elemento nome da sintaxe do atributo corresponde ao nome do atributo.


Na verdade, somente esse elemento obrigatrio na sintaxe de declarao de
um atributo.
O elemento tipo especifica o tipo do atributo. Esse elemento dependente
da linguagem de programao na qual a classe deve ser implementada. O tipo
definido para um atributo pode ser definido pela utilizao de um tipo primitivo
da linguagem de programao a ser utilizada na implementao. Por exemplo,
se estamos utilizando a linguagemjava, temos, dentre outros, os seguintes tipos
primitivos: int, float e boolean. tambm comum a utilizao de tipos abstratos
e dados (traduo para abstract data type, TAD) para declarar atributos. Um
TAD um tipo definido pelo usurio ou um tipo disponvel na linguagem de
programao que contm uma estrutura interna. Por exemplo, na Eigura 8-3, os
atributos Nome e telefone so definidos como do tipo String, que um tipo abs
trato de dados. Alm de String, temos (em Java); List, Set e array. Embora fre-
qentemente corresponda a uma classe, um TAD representado no comparti
mento de atributos em vez de ser representado como uma classe separada no dia
grama de classes. Isso porque o diagrama ficaria muito carregado visualmente
se essas classes TAD fossem representadas por retngulos separados.
A maioria das linguagens de programao j fornece tipos abstratos de da
dos. No entanto, os desenvolvedores podem definir seus prprios tipos. Por
exemplo, a Eigura 8-3 apresenta o atributo 1imi teCrdi to como do tipo Moeda,
240 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

um TAD para manipular valores monetrios. Outros exemplos de TAD so lis


tados a seguir.
Data (para processamento de datas em geral).
Horrio (para processamento de valores de tempo).
Endereo (para armazenamento de endereos em geral).
CdigoPostal, CPF e CNPJ (para armazenamento e validao desses va
lores).

Um valor inicial tambm pode ser declarado para o atributo. Dessa forma,
sempre que um objeto de uma classe instanciado, o valor inicial declarado
automaticamente definido para o atributo. Assim como o tipo, o valor inicial de
um atributo tambm dependente da linguagem de programao.
Pode-se definir um atributo derivado em uma classe. Um atributo derivado
quando o seu valor pode ser obtido a partir do valor de outro (s) atributo(s). Por
exemplo, o valor da idade de uma pessoa pode ser obtido a partir de sua data de
nascimento. Um atributo derivado representado com uma barra inclinada
esquerda. Atributos derivados normalmente so definidos por questes de
desempenho. Por exemplo, considere a classe Cliente da Figura 8-3. Em vez
de calcular a idade mdia de toda a coleo de clientes a cada vez que este valor
necessrio, definimos o atributo derivado idadeMdia e um mtodo seletor cor
respondente.
Outra caracterstica de um atributo o seu escopo. Cada objeto tem um valor
para cada atributo definido em sua classe. Esse o caso mais comum, e diz-se
que o atributo tem escopo de objeto. No entanto, pode haver atributos que te
nham escopo de classe, ou seja, que armazenam valor comum a todos os objetos
da classe. Esse tipo de atributo definido por um sublinhado na sintaxe da
UML. Um atributo que tenha escopo de classe tambm denominado atributo
esttico. Por exemplo, a classe Cl i ente da Figura 8-3 contm o atributo quanti -
dadeCI i entes para armazenar a quantidade de instncias criadas a partir dessa
classe. H apenas um valor desse atributo para todos os objetos da classe Clien
te. O atributo idadeMdia tambm esttico.
Uma possvel aplicao dos atributos estticos na implementao de re
gras de negcio. Por exemplo, considere a Figura 8-4, em que a classe Curso pos
sui um atributo esttico quantidadeMximaAl unos. Este atributo pode ser utiliza
do para implementao da seguinte regra de negcio: Em um curso podem estar
matriculados at 30 alunos.

Aluno Matriculado Curso


-matrcula : String <--------------------------------------------------- -cdigo : String
-nome : String * * -quantidadeMximaAlunos : Integer

Figura 8-4: Atributos estticos podem ser utilizados para implementar regras de negcio.
MODELAGEM DE CLASSES DE PROJETO 241

8.3 Especificao de operaes


Na descrio do modelo de interaes, declaramos que as operaes de uma
classe so identificadas em conseqncia da identificao de mensagens envia
das de um objeto a outro. No detalhamento dessas operaes, devemos conside
rar diversos aspectos; seu nome, lista de parmetros, tipo de cada parmetro,
tipo de retorno. Nesta seo, descrevemos a notao fornecida pela UML para
realizar esse refinamento de operaes. Descrevemos tambm alguns princpios
e dicas recomendados durante essa atividade.

8.3.1 Notao da UML para operaes


As operaes de uma classe correspondem a algum processamento realizado
por essa classe. Em termos de implementao, uma operao uma rotina asso
ciada a uma classe. Conforme visto no Captulo 5, a construo do modelo de
classes de anlise permite a identificao de algumas operaes. Durante a cons
truo do modelo de interaes, essas operaes so validadas e vrias outras o-
peraes so identificadas. Todas essas operaes devem ser adicionadas ao dia
grama de classes e devem ser documentadas com a definio de sua assinatura.
A sintaxe definida na UML para a assinatura de uma operao a seguinte:

v isib ilid ad e nome(parmetros): tipo-retorno {propriedades}

Cliente
+obterNome() : String
+definirNome(in umNome : String)
+obterDataNascimento() : Data
+definirDataNascimento(in umaData : Data)
+obterTelefone() : String
+definirTelefone(in umTelefone : String)
+obterLimiteCredito() : Moeda
+definirLimiteCredito(in umLimiteCredito ; float)
+obterIdade() ; int
+obterOuantidadeClientesO : int
+obterIdadeMedia() : float
Figura 8-5: Especificao das operaoes da classe Cliente.

O elemento nome corresponde ao nome dado operao. A visibilidade usa a


mesma simbologia das visibilidades para atributos. Se uma operao pblica,
ela pode ser ativada com a passagem de uma mensagem para o objeto. Se a ope
rao protegida, ela s visvel para a classe e para seus descendentes (o con
ceito de descendente de uma classe descrito no Captulo 9). Finalmente, se a
242 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

operao privativa, somente objetos da prpria classe podem execut-la. Os


parmetros de uma operao correspondem a informaes que esta recebe
quando executada. Normalmente, essas informaes so fornecidas pelo obje
to remetente da mensagem que requisita a execuo da operao no objeto re
ceptor. Uma operao pode ter zero ou mais parmetros. Estes so separados
por vrgulas. Cada parmetro da lista tem a seguinte sintaxe:
direo nome-parmetro: tipo-parmetro

O elemento direo serve para definir se o parmetro pode ou no ser modi


ficado pela operao. Atravs desse elemento, o modelador pode definir se o pa
rmetro de entrada, sada ou ambos. Se a direo for omitida, o valor assumido
pelo parmetro in. Os significados das direes so fornecidos na Tabela 8-2.
Note que a direo in corresponde passagem de parmetros por valor, enquan
to as direes out e inout correspondem passagem de parmetros por refern
cia. Essas formas de passagem de parmetros so comuns maioria das lingua
gens de programao, resguardadas as diferenas sintticas de cada uma.

Tabela 8-2: Possveis direes na definio de um parmetro

Direo Significado definido pela UML


in Parmetro de entrada: no pode ser modificado pela operao. Serve
somente como informao para o objeto receptor.
out Parmetro de sada: pode ser modificado pela operao para fornecer
alguma informao ao objeto remetente.
inout Parmetro de entrada que pode ser modificado.

O elemento nome-parmetro corresponde ao nome do parmetro. Cada par


metro deve ter um nome nico dentro da assinatura da operao. O elemento ti
po-parmetro corresponde ao tipo do parmetro e dependente da linguagem
de programao. O elemento tipo-retorno representa o tipo de dados do valor re
tornado por uma operao. Esse tipo depende da linguagem de programao.
Assim como atributos, as operaes tambm possuem um escopo. Uma opera
o pode ter escopo de classe ou escopo de instncia. Uma operao que tem esco
po de classe processa atributos estticos. Se essa operao tem escopo de classe,
ela tambm chamada de operao esttica. Uma operao que tenha escopo de
instncia indica que ela processa atributos que tm escopo de instncia.

8.3.2 Dicas prticas


Recomenda-se atribuir um nome a uma operao de forma que este lembre o re
sultado da operao e tenha a forma geral <verbo> + <complemento>. Alm dis-
MODELAGEM DE CLASSES DE PROJETO 243

so, O desenvolvedor deve se lembrar de que uma operao um servio que a


classe presta. Por conseguinte, esse nome deve ser definido a partir da perspec
tiva externa, e no interna. Ele deve tambm deixar claro o que a operao pro
duz como resultado, e no como ela faz isso. Por exemplo, considere a Figura
8-5. Essa figura apresenta uma operao de nome obterIdadeMdia(). Esse
nome mais apropriado do que o nome ca1cularIdadeMdia(), por exemplo.
Note que todas as operaes que correspondem a mensagens de um objeto a
outro em um diagrama de interao (ver Seo 7.5.1) devem ter visibilidade p
blica. Isso porque, para um objeto enviar uma mensagem a outro, a operao no
objeto receptor deve ser conhecida pelo objeto remetente da mensagem.
O desenvolvedor deve definir operaes com o mnimo de parmetros pos
svel. Uma razo para isso que quanto menos parmetros uma operao tiver,
mais fcil a utilizao da mesma. Alm disso, quanto menor a quantidade de
parmetros de uma operao, menor a dependncia entre as classes envolvi
das. tambm adequado que o modelador defina, para cada parmetro, seu va
lor assumido (se existir).
Da mesma forma que a lista de parmetros de uma operao deve ser a mni
ma possvel, assim tambm deve ser a lista de operaes que podem modificar o
estado de um objeto de certa classe. Dessa forma, o projetista deve avaliar cuida
dosamente quais atributos de certa classe podem ser alterados e quais operaes
so realmente necessrias para realizar a alterao.
Assim como para tipos de atributos e de parmetros, o tipo de retorno tam
bm pode ser um TAD. Nem todas as operaes retornam um valor, portanto,
esse elemento nem sempre especificado.

8.3.3 Projeto por contrato


Alm de todas as informaes descritas no diagrama de classes, o modelador
deve tambm especificar o objetivo e o funcionamento de cada operao. A des
crio do funcionamento, uma descrio da lgica da operao, til quando o
algoritmo da operao for complexo. O diagrama de atividades da UME, descri
to no Captulo 10, uma boa ferramenta para realizar essa descrio do funcio
namento.
Outra forma de documentar uma operao com a tcnica de projeto por
contrato (traduo para Design by Contract, DbC), proposta por Bertrand Meyer,
0 criador da linguagem de programao orientada a objetos Eiffel (Meyer,
1997). O objetivo da aplicao dessa tcnica obter uma especificao mais ri
gorosa das operaes de uma classe (ou interface) que seja til para a imple
mentao, 0 teste e o uso das mesmas. Meyer utiliza o termo fornecedor para de
notar o desenvolvedor, e o termo consumidor para denotar o usurio. Se uma
classe A utiliza os servios de uma classe B, ento B fornecedor e A o consu-
244 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

midor. A idia bsica do projeto por contrato criar um contrato entre o desen
volvedor e os consumidores de uma operao. Para cada parte envolvida no con
trato, h obrigaes e benefcios. Para um resumo, veja a Tabela 8-3.
No projeto por contrato, h dois elementos, as invariantes e as asseres. Uma
assero, por sua vez, pode ser de dois tipos: precondio ou ps-condio. Vamos
descrever dois elementos componentes da tcnica DbC nos prximos pargrafos.
Uma precondio uma condio atrelada a uma operao e que deve ser sa
tisfeita pelo consumidor quando este requisitar a execuo da operao ao forne
cedor. A cada operao, adicionado um conjunto de precondies. Como
exemplo de precondio, podemos citar a faixa de valores possveis para certo pa
rmetro de uma operao. Alm das precondies, para cada operao, tambm
so definidas ps-condies. Considere que Cpj.^ e Cp^^ so dois conjuntos de
precondies e de ps-condies, respectivamente, associados a certa operao.
O fornecedor deve garantir que cada ps-condio pertencente a Cp^^ satisfeita
aps a execuo da operao, contanto que as precondies pertencentes a Cp^
tenham sido satisfeitas pelo consumidor quando da chamada da operao. Se
pelo menos uma das precondies em Cp^.^ no forem garantidas pelo consumi
dor, a execuo correta da operao no garantida pelo fornecedor.
Outro elemento da tcnica de DbC a invariante. A cada classe pode ser asso
ciado um conjunto de invariantes (note a diferena em relao s asseres, que
so associadas a cada operao). Uma invariante de uma classe C uma condio
que deve ser obrigatoriamente satisfeita aps quaisquer mudanas realizadas no
estado de algum objeto de C. O objetivo de uma invariante garantir que o objeto
permanece em um estado vlido aps qualquer modificao aplicada sobre ele.

Tabela 8-3: Obrigaes de benefcios associados a consumidores e a fornecedores


no DbC
r" O b rig a e s B en efcio s

C o n s u m id o r Satisfazer precon dies Resultado satisfaz


ps-cond ies e invariantes

F o rn e c e d o r Satisfazer precon dies e Im plem entao pode confiar na


invariantes validade das precondies

A tcnica DbC pode ser aplicada formalmente com o uso da Linguagem de


Restrio de Objetos (ver Seo 3.6), para definir as asseres de cada operao
e invariantes de cada classe. Dois outros exemplos de linguagens de especifica
o formais so a VDM (Vienna Development Method) e a Z.
A definio de asseres e invariantes influencia diretamente na implemen
tao da classe em questo. Mas especificamente, essa influncia diz respeito
forma de validar os valores dos parmetros de suas operaes e de seus atribu-
MODELAGEM DE CLASSES DE PROJETO 245

tos. Com relao a isso, um recurso bastante comum em linguagens de progra


mao OO, e que pode ser utilizado para implementar asseres e invariantes,
a exceo. Uma exceo normalmente corresponde a uma classe predefinida na
linguagem, que pode ser utilizada para notificar alguma situao de erro duran
te o processamento de uma operao. Quando alguma situao de exceo
ocorre em uma operao, um objeto de alguma classe de exceo corresponden
te ao erro acontecido pode ser criado e retorna a regio de cdigo que fez a cha
mada operao. Particularmente no caso dos parmetros de operaes e dos
atributos de uma classe, um exemplo de situao de exceo o fato de ser atri
budo a algum desses elementos um valor invlido. O Quadro 8-1 apresenta,
novamente com a sintaxe da linguagem Java, um exemplo de validao de inva
riantes da classe Al uno com o uso de excees. Note que essa operao (na ver
dade, um dos construtores da classe) utiliza a exceo chamada IllegalArgu-
mentException para notificar o chamador de que houve algum erro na passa
gem dos argumentos para a operao. De qualquer forma, importante que o
projetista defina (1) a faixa de valores vlidos para cada parmetro de operao
e para o atributo em uma classe e (2) que excees devem ser disparadas quando
a verificao desses valores identificar algum valor inadequado.

Quadro 8-1: Exemplo de validao de invariantes com o uso de excees

// Invariante: sexo in ("M", "F"}


// Invariante: nome uma cadeia de caracteres no vazia
// Invariante: matrcula uma cadeia de caracteres no vazia
public c la ss Aluno {
private String nome;
private String matrcula;
private Char sexo;

public Aluno( fin a l String nome, fin a l String matrcula, fin a l Char sexo)
i f ( nome == null || nome.equalsC") ) {
throw new IIlegalArgumentException("Valor invlido para nome.");
}
i f ( matrcula == null || matrcula.equals("")) {
throw new IllegalArgumentException("Valor invlido para matrcula.");

i f ( sexo == null || (!sexo.equals{"M") && !sexo.equals("F"))) {


throw new IllegalArgumentException("Valor invlido para sexo.");
}
this.nome = nome;
this.matricula = matrcula;
this.sexo = sexo;
}
246 prin c pio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E E L S E V IE R

8.3.4 Operaes de criao e destruio de objetos


Duas operaes utilizadas frequentemente nas interaes entre objetos so a cria
o (instanciao) e a destruio de objetos. Essas operaes correspondem s
mensagens de criao e destruio de objetos, que descrevemos na Seo 7.2.4.
Uma operao de criao serve para instanciar um objeto. Operaes de destrui
o normalmente no tm parmetros e servem para liberar alguma quantidade
de memria que tenha sido alocada dinamicamente na instanciao.
Normalmente h diversas operaes de criao definidas em uma classe.
Os parmetros de uma operao de criao so utilizados para iniciar um ou
mais atributos do objeto. Para definir os parmetros de uma operao de cria
o, considere o seguinte: se o valor do atributo essencial para o significado
do objeto, mais adequado iniciar o seu valor logo na criao do objeto. Se
esse for o caso, uma das operaes de criao deve ter um parmetro que sir
va de valor inicial para o atributo essencial. Diz-se tambm que operaes de
criao so utilizadas para definir o estado inicial de um objeto. O estado de
um objeto definido como o conjunto de valores de seus atributos em um
dado momento. A modelagem de estados de um objeto mais bem descrita
no Captulo 9.
A forma de utilizao de mtodos de criao e destruio varia de uma lin
guagem de programao para outra. Por exemplo, na linguagem Delphi os m
todos de criao (Create) e de destruio (Destroy) so invocados explicitamen
te. A linguagem C++ fornece operadores para a criao e destruio de objetos
(new e delete).] as linguagens C# eJava, possibilitam a criao de objeto atra
vs de um operador (new) e possuem um mecanismo automtico de remoo
(destruio) de objetos, quando esses no so mais necessrios aplicao.

8.3.5 Seletores e modificadores


Pelo princpio do encapsulamento (ver Seo 1.2.3.1), qualquer acesso a infor
maes internas a uma classe deve ser realizado atravs de sua interface. A inter
face de uma classe definida como o conjunto de suas operaes de visibilidade
pblica.
Para assegurar o encapsulamento da classe, o projetista deve definir todos
os seus atributos com visibilidade privativa ou protegida. A seguir, ele deve defi
nir operaes para obter acesso e para modificar o valor de cada atributo. Essas
operaes so denominadas seletores e modificadores. (Tambm recebem o
nome comum de mtodos de acesso.) Um seletor retorna o valor de um atributo,
enquanto um modificador altera o valor de um atributo.
Como conveno, o nome de um seletor formado com o prefixo obter
seguido do nome do atributo. Analogamente, o nome de um modificador
construdo com o prefixo definir seguido do nome do atributo. Outra conven-
MODELAGEM DE CLASSES DE PROJETO 247

o comum utilizar o nome do atributo para nomear tanto o seu seletor quanto
o seu modificador. Como exemplo, considere novamente a Figura 8-5, que
apresenta seletores e modificadores para os atributos da classe Cl i ente. Repare
que cada seletor possui um tipo de retorno. J os modificadores no possuem
tipo de retorno, mas cada um possui um parmetro de mesmo tipo do atributo
correspondente.
Nem sempre faz sentido ter um modificador para um atributo. Isso acontece
quando o valor desse atributo somente deve ser consultado, mas no alterado.
Voltando ao exemplo da Figura 8-5, os atributos estticos s possuem seletores,
pois seus valores dependem do nmero de objetos da classe.

8.3.6 Outras operaes tpicas


Durante o projeto de uma classe, diversos mtodos devem ser definidos. Um
exemplo disso so os mtodos de ligao. Como o prprio nome deixa transpare
cer, esse tipo de mtodo serve para definir ligaes (conexes) entre objetos a
tempo de execuo do SSOO. Considere o Quadro 8-2, que apresenta uma clas
se em linguagem Java para representar turmas. Note que essa classe possui um
atributo que corresponde a uma coleo de objetos da classe OfertaDi sei pl i na.
Alm disso, note que os mtodos de ligao adi ci onarOfertaDi sei pl i na e remo-
verOfertaDi sei pl i na esto definidos nessa classe. Esses mtodos serverm para
criar e destruir conexes entre os objetos das classes Turma e OfertaDi sei pl i na
quando da execuo do sistema.

Quadro 8-2: Operaes para manuteno de associaes

public c la s s Turma {
private Set<OfertaDi scipl ina> ofertasDisciplina = new HashSetO;

public TurmaO {

public void adicionarOfertaDisciplina(OfertaDisciplina oferta)


thi s.ofertasDi sciplina.add(oferta);

pu blic boolean removerOfertaDisciplina(OfertaDisciplina oferta)


return this.ofertasDi sei plina.remove(oferta);

public Set getOfertasDisciplinaO {


return Col lections.unmodi fiableSet(this.ofertasDi sciplina);
248 prin cpio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E ELSEVIER

Alm dos mtodos de ligao, outros mtodos comumente encontrados


so para calcular valores derivados de atributos da classe, mtodos de forma
tao, mtodos de converso e cpia de objetos. Alm disso, alguns mtodos
que definimos em uma classe devem ter uma operao inversa bvia. Alguns
exemplos: h a b ilita r versus d e sa b ilita r; tornarVisvel versus to rn a rln v is -
vel; adicionar versus remover; depositar versus sacar etc. De qualquer modo,
devemos sempre validar a necessidade de cada mtodo com relao ao modelo
de interaes (ver o Captulo 7).

8.4 Especificao de associaes


Nesta seo, descrevemos alguns detalhes a serem adicionados para refinar os
relacionamentos de associao identificados do modelo de classes de anlise.
Aqui, definimos o conceito de dependncia, sua notao, e de que forma esse
conceito pode ser utilizado no refinamento de associaes.

8.4.1 0 conceito de dependncia


No modelo de classes de anlise, os relacionamentos entre objetos foram defini
dos apenas com o uso da associao (ou como um de seus casos especiais, a
agregao ou a composio). Entretanto, o fato de existir uma associao entre
duas classes implica a existncia de uma dependncia entre as mesmas. Uma de
pendncia entre classes indica que uma classe depende dos servios fornecidos
pela outra.
No modelo de anlise, suficiente para o modelador identificar a existncia
de associaes entre classes, que uma forma de dependncia. Mas, na fase de
especificao do modelo de classes, essa dependncia precisa ser melhor defini
da pelo projetista, visto que a mesma tem influncia na forma utilizada para im
plementar as classes envolvidas. Sendo assim, vamos ento descrever detalhes
acerca das possveis formas de dependncia. Para isso, considere duas classes, A
e B, onde A depende de B. Vrios tipos de dependncia entre essas duas classes
podem existir. Esses tipos so descritos a seguir.

1. Dependncia por atributo: A possui um atributo cujo tipo B. A depen


dncia por atributo tambm chamada de dependncia estrutural.
2. Dependncia por varivel global: A utiliza uma varivel global cujo tipo
B .

3. Dependncia por varivel local: A possui alguma operao cuja imple


mentao utiliza uma varivel local de tipo B.
4. Dependncia por parmetro: A possui pelo menos uma operao, e esta
possui pelo menos um parmetro, cujo tipo B.
MODELAGEM DE CLASSES DE PROJETO 249

Se analisarmos os tipos de dependncia descritos anteriormente, podemos


constatar que uma dependncia realmente indica que uma classe depende dos
servios fornecidos por uma outra classe. Por exemplo, em uma dependncia
por parmetro, possivelmente a implementao da operao em A invoca uma
ou mais operaes definidas em B.
A notao da UML para representar uma dependncia no diagrama de clas
ses de uma seta tracejada ligando as classes envolvidas. O sentido da seta da
classe dependente para a classe da qual ela depende. A Figura 8-6 ilustra a nota
o da UML para dependncias.

ClasseCliente ^ ClasseFornecedora

Figura 8-6: Notao para o relacionamento de dependncia.

Ainda com respeito notao, as dependncias podem ser estereotipadas para


indicar o tipo de dependncia existente entre duas classes. A tabela a seguir exibe os
esteretipos predefinidos na UML que podem ser utilizados em dependncias.

Tabela 8-4: Exemplo de validao de invariantes com o uso de excees

E s te re tip o T ip o de d e p e n d n cia

global Por varivel global


local Por varivel local
parameter Por parmetro

A Figura 8-7 ilustra exemplos de dependncias entre classes. Os parmetros de


operl e oper2 fazem com que Cl asseA seja dependente de Cl asseB e de Cl asseC.

!
I
parameter
I
I
I
I
I

V
ClasseB

Figura 8-7: Exemplo de uso de dependncias em um diagrama de classes.

Agora que definimos o conceito de dependncia e vimos sua notao, im


portante analisarmos como esse conceito influencia o refinamento de associaes
provenientes do modelo de classes de anlise. Fazemos isso na prxima seo.
250 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSE\^ER

8.4.2 Transformao de associaes em dependncias


No modelo de classes de anlise, quando uma nova classe identificada, o mo
delador especifica uma ou mais associaes entre essa classe e as demais. Na
passagem do modelo de classes de anlise para o de especificao, o modelador
deve estudar cada associao para identificar se ela pode ser transformada em
dependncias dos tipos 2, 3 ou 4 descritos na Seo 8.4.1. A razo para essa
transformao aumentar o encapsulamento das classes: a dependncia por
atributo (tipo 1), que corresponde ao modo de implementar associaes, torna
as classes envolvidas mais dependentes umas das outras. Quanto menos depen
dncias estruturais houver no modelo de classes, maior ser o encapsulamento
das classes constituintes. Alm disso, o acoplamento (ver Seo 7.5.2) do mo
delo de classes tambm diminui proporcionalmente quantidade de dependn
cias estruturais existentes.
Certamente no h um critrio predefinido que o modelador pode utilizar para
decidir as associaes que continuam e as que devem ser transformadas em depen
dncias no-estruturais. Essa deciso depende de vrios fatores e varia de caso para
caso. No entanto, de um modo geral, as associaes que ligam classes de entidade
permanecem como associaes no modelo de especificao. Isso porque associa
es entre classes de entidade normalmente devem ser mantidas de forma persis
tente (ver o Captulo 12). Alm disso, associaes entre controladores e classes de
entidade so bastante suscetveis a serem transformadas em dependncias no-
estruturais (as de tipo 2, 3 ou 4). Entretanto, note que, se um controlador utilizar
um objeto de entidade muito freqentemente, talvez seja mais adequado manter a
associao atravs de uma dependncia estrutural, por motivos de desempenho.
Em relao s associaes entre classes de fronteira e controladores, o mo
delador deve considerar o padro de interao de cada classe de fronteira. Se o
caso de uso em questo possuir um ator humano que inicia a sua realizao,
existir uma classe de fronteira para esse ator. Essa classe pode manter um rela
cionamento estrutural com o controlador do caso de uso. Se existirem outras
classes de fronteira (para equipamentos ou para outros sistemas, por exemplo),
normalmente haver interfaces para essas classes, situao em que mais apro
priado utilizar dependncias no-estruturais (o conceito de interface descrito
em detalhes na Seo 8.5.4).

8.4.3 Navegabilidade de associaes


As associaes (assim como agregaes e composies) podem ser classificadas
em bidirecionais e unidirecionais. Uma associao bidirecional indica que h um
conhecimento mtuo entre os objetos associados. Ou seja, se um diagrama de
classes exibe uma associao entre duas classes e C2, ento as duas assertivas
a seguir so verdadeiras.
MODELAGEM DE CLASSES DE PROJETO 251
ELSEVIER

1. Cada objeto de conhece todos os objetos de C2 aos quais ele est asso
ciado.
2. Cada objeto de C2 conhece todos os objetos de C^ aos quais ele est asso
ciado.

Graficamente, uma associao unidirecional representada adicionando-se


um sentido associao. A classe para a qual o sentido aponta aquela cujos ob-
vAo possuem visibilidade dos objetos da outra classe. O diagrama da Figu-
i f-8 ilustra 0 uso de uma associao unidirecional. Esse diagrama indica que
-letos da classe Pedido possuem, cada qual, uma referncia para um objeto
: - ente. Por outro lado, um objeto de Cl i ente no tem referncias para os obje
tos associados em Pedido.

F ig u r a 8 -8 : Exemplo de associao unidirecional.

Durante a construo do modelo de classes de anlise, associaes so costu


meiramente consideradas navegveis em ambos os sentidos, ou seja, as associa
es so bidirecionais. No modelo de classes de projeto, o modelador deve refinar
a navegabilidade de todas as associaes. Pode ser que algumas associaes de
vam permanecer bidirecionais. No entanto, se no houver essa necessidade, reco-
menda-se transformar a associao em unidirecional. Isso porque uma associa
o bidirecional mais difcil de implementar e de manter do que uma associao
unidirecional correspondente. Para entender isso, basta ver que o acoplamento
(ver Seo 7.5.2) entre as classes envohddas na associao maior quando a nave
gabilidade bidirecional. Portanto, um dos objetivos a alcanar durante o projeto
identificar quais navegabilidades so realmente necessrias.
A definio do sentido da navegabilidade se d em funo dos diagramas de
interao construdos para o sistema (ver Captulo 7). Mais especificamente,
devemos analisar os fluxos das mensagens entre objetos no diagrama de intera
es. Dados dois objetos associados, A e B, se h pelo menos uma mensagem de
A para B em algum diagrama de interao, ento a associao deve ser navegvel
da classe de A para a classe de B. Da mesma forma, se existir pelo menos uma
mensagem de B para A, ento a associao deve ser navegvel de B para A.
252 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

A definio do sentido da navegabilidade feita em funo dos diagramas de inte


rao construdos para o sistema. Devemos analisar os fluxos das mensagens en
tre objetos no diagrama de interaes.

Mesmo em situaes em que a navegabilidade de uma associao deva ser


bidirecional, possvel implementar apenas um sentido da mesma. Por exem
plo, considere a Figura 8-9. Observe, ainda, que necessrio saber de que corri
das certo cavalo participou, e tambm os cavalos que participaram de certa cor
rida. Essas duas necessidades indicam uma associao bidirecional. Entretanto,
se a coleo de cavalos no for to grande, pode-se definir uma associao uni-
direcional no sentido de Corri da para Cavai o. Isso satisfaz a segunda necessida
de. Para satisfazer a primeira necessidade, basta percorrer a coleo de corridas
e, para cada uma, verificar se o cavalo em questo participou da mesma. Note
que essa soluo s se justifica se o tempo necessrio para percorrer a coleo de
corridas no tiver um grande impacto no desempenho. De um modo geral, se o
desempenho for um fator crtico, melhor implementar a associao nos dois
sentidos.

Cavalo Participa ^ Corrida


y
-nome : String -data : Data
^ * *
-dataNascimento : Data -hora : Horrio

F ig u r a 8 -9 : possvel substituir uma associao bidirecional por uma unidirecional.

8.4.4 Definindo a implementao de associaes


Para associaes de conectividade um para um, a implementao trivial. Supo
nha que existam duas classes ligadas por uma associao de conectividade
uma-para-um, e Cp. Considere ainda que a navegabilidade definida no sen
tido de Cg para Cp. Nesse caso, definido um atributo do tipo Cp na classe Cg. Se
a navegabilidade for bidirecional, o procedimento anterior pode ser aplicado
para as duas classes. Portanto, em associaes um para um, no h necessidade
de um refinamento adicional.
Como um exemplo da forma tpica utilizada para implementar associa
es de conectividade um-para-um, considere a Figura 8-10 e o Quadro 8-3.
que apresenta um esboo de implementao (na sintaxe de linguagemjava) da

1..1 0. . 1 -
Professor ^ GradeDisponibilidades
Fig u ra 8-10: Exemplo de associao de conectividade um-para-um.
MODELAGEM DE CLASSES DE PROJETO 253

classe Professor. Note que h um atributo nessa classe cujo tipo GradeDi spo-
ni bi 1 i dades. Dessa forma, cada objeto da classe Professor possui uma refern
cia para um objeto da classe GradeDi sponi bi 1i dades, o que est consistente com
o modelado na Figura 8-10.

Quadro 8-3: Implementao de associao de conectividade um-para-um

public c l a s s Professor {
pri vat e GradeDisponib i l l dades grade;

Para o caso das associaes de conectividade um ipara muitos ou muitos para


muitos, 0 modelador pode decidir representar detalhes adicionais no modelo de
classes de projeto, com o objetivo de esclarecer como tais associaes devem ser
implementadas. Uma razo para a representao desses detalhes adicionais
pode ser o fato de que o sistema esteja sendo desenvolvido com o uso de uma
ferramenta CASE (ver Seo 2.6) que gera cdigo automaticamente a partir do
diagrama de projeto. Nessa situao, o objetivo do modelador no detalhamento
pode ser o de especificar a forma de implementao que a ferramenta deve utili
zar. O detalhamento de associaes de conectividade um para muitos ou muitos
para muitos se baseia em classes que representam colees de elementos. Vamos,
ento, descrever o conceito de classe parametrizada, que permite representar
colees em um diagrama de classes de especificao.
Uma coleo pode ser representada em um diagrama de classes por uma
classe parametrizada. Uma classe parametrizada uma classe utilizada para de
finir outras classes. Ela possui operaes ou atributos cuja definio feita em
funo de um ou mais parmetros. Uma aplicao do conceito de classe para
metrizada na definio de classes que representam colees. Independente-
mente do tipo de elementos que uma coleo possui, tal coleo deve possuir
operaes para adicionar um novo elemento, remover um elemento, encontrar
um elemento etc. Sendo assim, uma coleo pode ser definida a partir de uma
classe parametrizada, em que o parmetro o tipo do elemento da coleo.
H duas notaes possveis na UME para representar uma classe parametri
zada em um diagrama de classes. A Eigura 8-11 um exemplo das duas repre
sentaes possveis para a classe parametrizada denominada Coleo.

Tipo
Coleo
Coleo<Tipo>

Fig u ra 8-11: Notaes possveis na U M L para uma classe parametrizada.


254 prin c pio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E ELSEVTER

Uma questo interessante acerca de qual a correspondncia do conceito


de classe parametrizada em linguagens de programao. Na linguagem Java,
por exemplo, classes parametrizadas so representadas pelo mecanismo de ti
pos genricos (termo original: Java Generics). A linguagem C++ tambm possui
uma forma de implementar classes parametrizadas, com o conceito de templa
tes. A linguagem C# outra que fornece o mecanismo de classes parametriza
das. Como um exemplo, considere o fragmento de classe apresentado no Qua
dro 8-4, no qual utilizamos a sintaxe da linguagem Java. Esse fragmento apre
senta um atributo definido como um tipo genrico, prRequisitos. Nesse caso
particular, esse atributo representa uma coleo de objeto cujos elementos so
da classe Di sei pl i na.

Quadro 8-4: Classe paramentrizada na sintaxe da linguagem Java

public c l a s s Di s c i pl i na {
pri vat e Set<Disci pli na> prRequisi tos;

Conforme declaramos h pouco, o conceito de classe parametrizada pode


ser utilizado para detalhar de que forma pode ser refinada uma associao de co
nectividade um-para-muitos ou muitos-para-muitos. Analisamos esse aspecto a
seguir.
Em uma associao de conectividade um-para-muitos, a forma de refi
n-la (e, conseqentemente, de implement-la) depende da navegabilidade
definida. El dois casos a considerar. No primeiro caso, a navegabilidade aponta
para o lado muitos da associao. No segundo caso, a navegabilidade aponta para
o lado um da associao. Vamos agora analisar cada um desses casos.
Para refinar uma associao de conectividade um-para-muitos em que a na
vegabilidade do lado um para o lado muitos, a idia bsica definir uma
classe parametrizada cujo parmetro a classe correspondente ao lado mui
tos da associao. Como exemplo, a Figura 8-12 ilustra trs verses de um
mesmo fragmento de diagrama de classes para representar o fato de que um ob
jeto da classe Al uno possui associao com diversos (muitos) objetos da classes
Parti ci pao. Aparte (a) ilustra a verso menos detalhada (apenas a navegabili
dade especificada). As partes (b) e (c) da Figura 8-12 ilustram duas represen
taes mais detalhadas. Essas representaes so equivalentes e utilizam o con
ceito de classe parametrizada. Conforme mencionamos na Seo 7.1.5, consi
dera-se que a classe parametrizada correspondente coleo possui operaes
que permitem adicionar, remover e obter acesso aos seus elementos. As lingua
gens de programao orientadas a objetos fornecem diversas classes que podem
MODELAGEM DE CLASSES DE PROJETO 255

{ Panicipaao
Aluno S e t " "
/K } Set<Participa> ^------ >|Participao|

I ColeoPartidpa^
/V
1

1 1

IPart cipao| Aluno Aluno

(a) (b) (c)

F ig u r a 8 -1 2 : Formas alternativas para representar uma associao um para muitos.

ser utilizadas como a classe Coleo Continer. Note-se tambm que a utiliza
o da classe parametrizada resultou na transformao de uma associao um
para muitos em uma associao um para um.
Para dar uma idia de como o diagrama da Figura 8-12 pode ser implemen
tado, considere o Quadro 8-5. Esse quadro apresenta um trecho da implementa
o da classe Al uno em linguagem Java. Note a presena do atributo denominado
participaes, uma lista parametrizada de objetos da classe Participao.
Nesse exemplo, utilizamos a classe Set presente na linguagem Java. Tambm
apresentamos os prottipos dos mtodos adicionarParticipao e removerPar-
ticipao, que servem para manipular a coleo representada pelo atributo
participaes (ver Seo 8.3.6).

Quadro 8-5: Implementao de associao um-para-muitos e de navegabilidade


para o lado "muitos"
I '
public c l as s Aluno {
pri vat e Set<Partici pao> p a r t i c i pa e s ;

public boolean a d i c i on a r Pa r t i c i pa o ( Pa r t i c i pa o p ) {

public boolean removerPartici pao( Partici pao p)

O segundo caso possvel de refinamento de uma associao um-para-


muitos aquele em que a mesma tem navegabilidade apontando para o lado
um. Nesse caso, a utilizao de uma coleo (como no primeiro caso) no
256 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

necessria. Quando a navegabilidade somente aponta para o lado um, tudo o


que deve ser feito criar um atributo de referncia na classe correspondente ao
lado muitos. O tipo desse atributo corresponde classe que est no lado um
da associao. Por exemplo, o Quadro 8-6 apresenta um exemplo de trecho de
cdigo resultante da aplicao dessa regra. Nesse quadro, temos a classe Oferta-
Di sei pl i na, que possui uma associao com a classe Di sei pl i na. A navegabilida
de dessa associao de OfertaDi sei pl i na para Di sei pl i na (ou seja, aponta para
o lado um). Portanto, como mostra essa figura, criamos um atributo na classe
OfertaDi sei pl i na para referenciar o objeto Di sei pl i na ao qual a primeira est as
sociada.

Quadro 8-6: Implementao de associao muitos-para-muitos

public class OfertaDis c ipli na {


private Disciplina disciplina;

A utilizao do conceito de classe parametrizada no detalhamento de uma


associao cuja conectividade muitos para muitos bastante semelhante ao
caso das associaes um para muitos. Considere o exemplo da Figura 8-13a,
que ilustra uma associao entre as classes Di sci pl i na e GradeDi sponi bi 1i dades.
Essa figura tambm informa que a associao navegvel no sentido de Grade
Di sponi bi 1i dades para Di sci pl i na. A Figura 8-13b apresenta o detalhamento do
diagrama apresentado na Figura 8-13a. Note que novamente uma classe para
metrizada utilizada no refinamento da associao.
Alm do refinamento das associaes comuns que descrevemos anterior
mente, h tambm o caso das classes associativas (ver Seo 5.2.2.4). No refina-

Figu ra 8-13: Associao muitos para muitos entre Disciplina e GradeDisponbilidades.


MODELAGEM DE CLASSES DE PROJETO 257
ELSEVIER

mento de classes associativas, a soluo mais usual criar uma classe para subs
tituir a associativa. Uma vez feito isso, o problema se transforma no refinamento
de associaes um para muitos ou muitos para muitos. Como exemplo, a Figura
8-14 ilustra dois diagramas de classes. O diagrama da direita corresponde a um
possvel refinamento do diagrama da esquerda.

Projeto

Aiocaao
cargaHorria : Integer
0..i
-remunerao : Moeda
^ .................................. j
_Al_ocao^__j
S e t" I_______ Alocao
-cargaHorria : Integer
-remunerao : Moeda

Pessoa ^ Projeto
participante

I Pessoa^

(a) (b)

Figura 8-14: Refinamento de uma classe associativa.

8.5 Herana
Na Seo 5.2.3, estudamos o relacionamento de herana no contexto do modelo
de classes de anlise. Na modelagem de classes de projeto, h diversos aspectos
relativos a esse relacionamento, que, nesta fase, normalmente chamado de re
lacionamento de herana. Descrevemos esses aspectos nesta seo.

8.5.1 Tipos de herana


H diversas categorizaes que podem ser feitas a respeito de conceito de heran
a. Uma delas com relao quantidade de superclasses que certa classe pode
ter. De fato, uma classe pode ter mais de uma superclasse. Essa situao corres
ponde ao conceito de herana mltipla. Esse conceito ilustrado na Eigura 8-15.
Este diagrama representa um carro anfbio, que possui tanto caractersticas de
um carro quanto de um barco. Se uma classe tem apenas uma superclasse, ento
estamos diante da herana simples.
O uso de herana mltipla deve ser evitado. Um dos motivos para essa reco
mendao que esse tipo de herana difcil de entender. Alm disso, algumas
linguagens de programao no possuem construes para dar suporte imple
mentao da herana mltipla. Java, C# e Smalltalk, por exemplo, so lingua-
258 PRINCPIOS DE ANLISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEAaER

Figura 8-15: Exemplo de herana mltipla.

gens orientadas a objetos que no do suporte direto ao conceito de herana


mltipla. Por fim, a maioria das linguagens de programao mais modernas
possui uma alternativa para o uso de herana mltipla, as interfaces, que descre
vemos na Seo 8.5.4.
Outro tipo de categorizao do conceito de herana com relao forma de
reutilizao envolvida. H duas formas de reutilizao por herana em LPOO
modernas Qava, C# etc.): herana de implementao e herana de interface. Para
estabelecer a diferena entre esses dois tipos, devemos primeiramente definir o
conceito de servio. Um servio composto de sua especificao e de seu mtodo. A
especificao define o que o servio realiza, alm de documentar as informaes
necessrias para que o servio seja realizado e o resultado da sua realizao. J o
mtodo corresponde ao modo de realizar um servio. Dada uma especificao de
um servio, podem existir diversos mtodos para realiz-lo. Na herana de imple
mentao, uma subclasse herda mtodos de um ancestral. J na herana de in
terface, uma subclasse herda as especificaes definidas na interface de um an
cestral e se compromete a implementar essa interface. A herana de implementa
o bastante intuitiva; fcil entender que uma subclasse herda os mtodos de
qualquer operao definida em seu ancestral. Entretanto, o conceito de herana
de interface no to intuitivo. Para esclarecer esse tipo de herana, nas prximas
sees, introduzimos os conceitos de classe abstrata e de interface.

8.5.2 Classes abstratas


comum, a existncia de uma classe se justificar pelo fato de haver a possibili
dade de gerar instncias da mesma. Classes que geram instncias so chamadas
de concretas. No entanto, podem existir classes que no geram instncias (obje
tos) diretamente. Essas classes so normalmente utilizadas para organizar e
simplificar uma hierarquia de herana. Portanto, classes abstratas s existem
em hierarquias. Propriedades comuns a diversas classes podem ser organizadas
e definidas em uma nica classe abstrata da qual as primeiras herdam.
Na notao da UML, uma classe abstrata representada com o seu nome em
itlico. A Eigura 8-16 apresenta um exemplo de classe abstrata que serve como
MODELAGEM DE CLASSES DE PROJETO 259

Figura 8-16: Exemplo de classe abstrata.

superclasse para duas outras classes. Uma notao alternativa utilizar a etique
ta {abstract} (ver Seo 3.3) dentro do compartimento do nome da classe.
Subclasses de uma classe abstrata tambm podem ser abstratas, mas a hie
rarquia deve terminar em uma ou mais classes concretas. Ou seja, no faz senti
do existir uma hierarquia de herana com uma classe abstrata na base dessa hie
rarquia.
Alm de no poder ser diretamente instanciada, outra caracterstica associa
da ao conceito de classe abstrata o fato de ela possuir ao menos uma operao
abstrata. Na terminologia da Seo 8.5.1, uma operao abstrata corresponde
especificao de um servio que a classe deve fornecer (sem mtodo). Uma classe
qualquer pode possuir tanto operaes abstratas, quanto operaes concretas
(ou seja, operaes que possuem implementao). Entretanto, uma classe que
possui pelo menos uma operao abstrata , por definio, abstrata. Assim
como acontece com qualquer operao pblica, uma operao abstrata definida
em uma classe tambm herdada por suas subclasses. Quando uma subclasse
herda uma operao abstrata e no fornece uma implementao para a mesma,
esta classe tambm ser abstrata (pois, por herana, passar a possuir uma ope
rao abstrata). Por outro lado, se esta classe fornecer uma implementao para
quaisquer operaes abstratas herdadas, e ela prpria no define operaes abs
tratas, esta classe concreta.
Graficamente, uma operao abstrata representada em itlico no diagrama
de classes, segundo a notao definida pela UML. O uso da etiqueta {abstract}
tambm uma alternativa. Como exemplo, considere a Figura 8-17. Nesta figu
ra, a classe FiguraGeomtrica abstrata, pois possui uma operao abstrata, de
senhar (note que a assinatura dessa operao est declarada em itlico). As clas
ses C rcul 0 e Quadrado so concretas, pois fornecem implementao para a ope
rao abstrata herdada.
260 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Figura 8-17: Herana de operao abstrata.

8.5.3 Operaes polimrficas


Uma subclasse herda todas as propriedades de sua superclasse que tenham visi
bilidade pblica ou protegida. Isso quer dizer que possvel a situao em que
um objeto da subclasse recebe uma mensagem para que uma operao pblica
ou protegida definida em sua superclasse seja executada. Entretanto, pode ser
que o comportamento de alguma operao herdada tenha que ser diferente para
a subclasse. Nesse caso, a subclasse deve redefinir o comportamento da opera
o. Note que a assinatura da operao reutilizada pela subclasse; tudo o que a
subclasse faz implementar o novo comportamento desejado para a operao.
O resultado disso que a subclasse e a superclasse agora compartilham a mesma
assinatura de certa operao, mas cada uma delas possui um mtodo (forma de
implementao) particular para essa operao.
Por definio, operaes polimrficas so operaes de mesma assinatura
definidas em diversos nveis de uma hierarquia de herana e que possuem mto
dos diferentes. Essas operaes devem ter a assinatura repetida na(s) subclas-
se(s) para enfatizar que elas esto sendo redefinidas (somente a assinatura
herdada, mas no a implementao).
Como exemplo, considere as classes Funcionrio e Vendedor, esta ltima
subclasse da primeira. Em Funcionrio, existe um mtodo obterPagamento,
que retorna o valor do pagamento do funcionrio. Suponha que o mtodo
para obter o valor do pagamento de um vendedor no seja o mesmo para ob
ter o pagamento de um funcionrio. Nesse caso, no faz sentido Vendedor her
dar a implementao dessa operao. Em vez disso. Vendedor deve redefinir a
operao obterPagamento. Diz-se, ento, que essa operao polimrfica. A
Figura 8-18 ilustra graficamente essse exemplo. A assinatura da operao
obterPagamento repetida em Vendedor. (As notas explicativas ([ver Seo
3.2]) apresentam as expresses de clculo do pagamento utilizadas em uma
classe e na outra.) Note que, como as operaes tm a mesma assinatura, a
MODELAGEM DE CLASSES DE PROJETO 261

Funcionrio
-salrioBase : Moeda
a-obterPagamentoO ; Moeda
return salrioBase; +definirSalrioBase(in umSalrio : Moeda)
-robterSalrioBaseO : Moeda

Vendedor
return comisso * obterSalrioBaseO; comisso : Porcentagem
-tobterPagamentoO : Moeda

Figura 8-18: Definio de operaes polimrficas.

mensagem utilizada para obter o valor do pagamento de um funcionrio ou de


um vendedor a mesma.
Operaes polimrficas tambm podem existir em classes abstratas. A Figu
ra 8-19 ilustra um exemplo dessa situao. Nesse exemplo, b uma classe abs
trata denominada ContaBancria. Essa classe possui duas subclasses, ContaCor-
rente e ContaBancri a. Note tambm que a operao aplicarjuros em ContaBan-
cri a tambm abstrata (pois sua assinatura est declarada em itlico). Isso sig
nifica que as subclasses devem fornecer uma implementao a essa operao
para que tambm no se tornem abstratas. Portanto, tanto ContaCorrente quanto
ContaPoupana implementam a operao herdada.
Operaes polimrficas so importantes porque ajudam na implementa
o do princpio do polimorfismo no qual objetos que pertencem a classes di
ferentes respondem mesma mensagem. (O princpio do polimorfismo
apresentado na Seo 1.2.3.2.) A utilizao de operaes polimrficas tem o

ContaBancria
-saldo : Moeda
+aplicar]uros(in umaTaxa : Porcentagem)
+debitar(in umaQuantia : Moeda)
+creditar(in umaQuantia : Moeda)
A

ContaCorrente ContaPoupana

-taplicarJuros(in umaTaxa : Porcentagem) I -taplicarJuros(in umaTaxa : Porcentagem)

Figura 8-19: Operaes polimrficas tambm podem existir em classes abstratas.


262 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

objetivo de garantir que as subclasses compartilhem uma mesma operao,


mas com mtodos diferentes. Em outras palavras, se duas ou mais subclasses
de uma mesma classe implementam a mesma operao polimrfica, o reme
tente da mensagem no precisa saber qual a verdadeira classe de cada objeto
receptor, pois eles aceitam a mesma mensagem. A diferena que o mtodo
que implementa a operao a ser executada diferente em cada subclasse.
Como exemplo disso, considere o trecho de cdigo apresentado no Quadro
8-7. Nesse exemplo, h uma coleo cuja definio indica que ela armazena
objetos da classe ContaBancri a. A princpio, esse exemplo parece incoerente
com a definio de classe abstrata: como pode existir uma coleo cujos ele
mentos so objetos de uma classe da qual no pode haver instncias? A res
posta para a aparente inconcia que, embora no possa haver instncias di
retas da classe ContaBancri a, pode haver instncias indiretas da mesma. Note
que instncias das classes ContaCorrente e ContaPoupanca so indiretamente
instncias da classe ContaBancri a. Portanto, a coleo denominada contas-
Bancrias pode conter objetos das subclasses de ContaBancri a. Agora note a
regio de cdigo destacada (em negrito) no Quadro 8-7. Essa regio corres
ponde a uma iterao que percorre todos os objetos na coleo contasBanc-
rias e, para cada um deles, invoca a execuo da operao aplicarjuros.
Como essa coleo contm objetos de ambas as subclasses de ContaBancri a,
os mtodos invocados sero diferentes, em funo da verdadeira classe do
objeto receptor da mensagem. De qualquer modo, o fato importante nesse
exemplo que h uma regio de cdigo (a que est destacada no Quadro 8-7)
que envia a mensagem para objetos de classes diferentes, sem saber qual a
verdadeira classe dos objetos receptores (ContaCorrente ou ContaPoupanca). Essa
a essncia do princpio do polimorfismo.

uadro 8-7: Operaes polimrficas ajudam na implementao do polimorfismo

ContaCorrente cc;
ContaPoupanca cp;

List<ContaBancria> contasBancrias ;

contasBancrias.add(cc);
contasBancrias.add(cp);

for (ContaBancria conta: contasBancrIas) {


conta.a p l i carJuros( 0 . 05 );
}
MODELAGEM DE CLASSES DE PROJETO 263

8.5.4 Interfaces
De acordo com a definio de um dicionrio, uma interface um dispositivo ou um
sistema que entidades no relacionadas utilizam para se comunicar. No contexto
do desenvolvimento de sistemas orientados a objetos, quando estamos construin
do uma comunidade de entidades (objetos) que interagem entre si, uma interface
representa a cara que uma dessas entidades mostra outra, ou seja, que servios
ela fornece. Uma entidade pode, naturalmente, ter muitas interfaces, mostrando as
caras diferentes a diferentes membros de comunidade de entidades.
Considere o exemplo a seguir para entender o conceito de interface. Suponha
que exista uma classe Bi ci cl eta, que pertence a uma hierarquia de classes (vecu
los). A classe Bi ci cl eta define o que uma bicicleta pode fazer em termos do com
portamento de um veculo. No entanto, um objeto bicicleta pode interagir com o
mundo de outras formas. Por exemplo, uma bicicleta poderia ser um dos produtos
manipulados por um sistema de vendas. Esse sistema provavelmente no necessita
do comportamento relativo a um veculo da classe Bi ci cl eta, apenas que objetos
dessa classe se comportem como produtos que possam ser vendidos e que forne
am certas informaes (por exemplo, preo de venda, nmero de registro etc.).
Ou seja, para ser manipulado pelo sistema de vendas, um objeto da classe bicicleta
deve estar em concordncia com o protocolo ou contrato de comporamento predefi-
nido. Este protocolo compreende um conjunto no vazio de assinaturas de opera
es. Cada assinatura apresenta o nome da operao, juntamente com a definio
de seus eventuais parmetros e tipo de retomo. O protocolo de interao no con
tm a implementao das operaes nele definidas. Em uma linguagem de progra
mao orientada a objetos, esses protocolos so denominados interfaces.
Voltando ao exemplo do sistema de vendas, este pode interagir com os obje
tos a serem vendidos (produtos) por intermdio de uma interface; no h neces
sidade desse sistema conhecer as verdadeiras classes dos objetos com os quais
interage. Dessa forma, objetos da classe Bi ci cl eta ou da classe Gel adei ra podem
ser tratados de forma indistinta pelo sistema de vendas. De uma forma geral,
qualquer classe que implemente (fornea implementao) para as operaes
definidas na interface que o sistema de vendas espera pode representar o papel
de produto. Alm disso, se por um lado uma interface usada para definir um
contrato de comportamento, por outro lado o mesmo contrato de comportamen
to pode ser implementado por diferentes classes. A conseqncia disso que
no h a necessidade de definirmos relacionamentos diretos entre classes que,
em situaes normais, no estariam relacionadas. Em vez disso, podemos defi
nir uma interface para que essas classes se comuniquem. Podemos ento definir
os seguintes objetivos do conceito de interface:

1. Capturar semelhanas entre classes no relacionadas sem forar relacio


namentos entre elas.
264 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

2. Declarar operaes que uma ou mais classes devem implementar.


3. Revelar as operaes de um objeto, sem revelar a sua classe.
4. Facilitar o desacoplamento entre elementos de um sistema.
Uma interface corresponde a um conjunto de especificaes de servios (ver
Seo 8.5.1) fornecidos por um classificador. Um classificador conceito da
UML usado para denotar uma classe, um subsistema ou um componente. (Estes
dois ltimos elementos so descritos nas Sees 11.1 e 11.2.2, respectivamen
te.) Um classificador possui comportamento, ou seja, implementa um conjunto
de operaes. Atravs dessas operaes, um classificador pode fornecer servi
os para outros classificadores. Ele tambm pode utilizar servios destes lti
mos. Um classificador pode implementar vrias interfaces, assim como uma in
terface pode ser implementada por vrios classificadores. Em uma interface,
no h mtodos associados s especificaes. O classificar que fornece mto
dos para as especificaes das classes que ele implementa.

Figura 8-20: A classe ContaBancria implementa duas interfaces: Manipulvel e Administrvel.

A UML define duas notaes equivalentes para representar graficamente uma


interface. (Os exemplos a seguir so fornecidos em relao a classes, mas a nota
o vale para qualquer classificador.) A primeira notao para uma interface a
mesma definida para classes, em que so exibidas as operaes que a interface de
fine. Entretanto, o compartimento dos atributos fica sempre vazio, pois uma in
terface no possui atributos. Alm disso, no compartimento do nome da interface
deve aparecer o esteretipo i nterf ace. Como exemplo, a Eigura 8-20 utiliza a
primeira notao e indica que ContaBancria realiza as interfaces Manipulvel e
Administrvel. A primeira interface (Mani pul vel ) especifica as operaes credi -
tar( ) e debitar( ). A segunda interface (Administrvel) especifica as operaes
cri ar( ), bl oquear( ) e desbl oquear( ). Para as classes Cl i ente e Gerente, que utili
zam as interfaces que ContaBancria realiza, tudo se passa como se estivessem uti
lizando a prpria classe. A diferena que essas classes somente visualizam as o-
peraes que fazem sentido para elas. Alm disso, qualquer outra classe que im-
MODELAGEM DE CLASSES DE PROJETO 265

plemente as interfaces Mani pul vel e Admi ni strvel pode substituir a classe Con-
taBancria sem modificaes nas demais classes. A segunda notao possvel
para uma interface na UML atravs de um segmento de reta com um pequeno
crculo em um dos extremos e ligado classe que a realiza (implementa) no outro
extremo. O nome da interface posicionado prximo ao extremo do segmento
que contm o pequeno crculo. Nesta notao mais simplificada, as operaes da
interface no so ilustradas. As classes clientes esto conectadas interface atra
vs de um relacionamento de dependncia. A Figura 8-21 exibe essa segunda for
ma de representao de interfaces. Note que, em ambas as formas de representa
o de interfaces, a linha de dependncia parte de um classificador e termina no
smbolo de uma das interfaces de outro classificador.

Figura 8-21: Exemplo da forma simplificada para representar interfaces.

Conforme mencionado h pouco, uma classe pode realizar (implementar)


vrias interfaces. Nesse caso, a classe deve fornecer implementaes (mtodos)
para as operaes cujas assinaturas (especificaes) so declaradas nas interfa
ces. Por exemplo, a classe ContaBancri a fornece implementaes para as opera
es declaradas nas interfaces Manipulvel e Administrvel. Tambm pode ser
que a mesma interface seja realizada por vrias classes. Nesse caso, essas classes
obveni rmpfementar as operaoes a interlace que reazam. For exempfo, se
uma interface I realizada por trs classificadores A, B e C, e declara as opera
es opl( ),op2( ),op3( )eop4( ), ento essas operaes devem estar imple
mentadas em alguns dos classificadores.
Algumas linguagens de programao possuem em sua sintaxe suporte dire
to ao conceito de interface, mas outras no. As linguagens Java e C# apresentam
o conceito de interface em suas sintaxes. A linguagem C++, por outro lado, no
possui explicitamente o conceito de interface. Mesmo assim, nessa linguagem,
interfaces podem ser definidas indiretamente por classes abstratas em que todas
as operaes so abstratas e no h atributos.
266 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Juntamente com o conceito de classes abstratas, interfaces permitem alcan


ar o acoplamento abstrato. Descrevemos esse conceito na prxima Seo.

8.5.5 Acoplamentos concreto e abstrato


Na Seo 7.5.2, descrevemos o conceito de acoplamento. Vimos que esse concei
to corresponde a uma medida da dependncia existente entre classes de um sis
tema. Vimos tambm que devemos manter o acoplamento em um nvel mnimo
possvel, com o objetivo de diminuir as dependncias na estrutura de classes
correspondente. Note a utilizao do termo mnimo possvel na frase ante
rior. O acoplamento necessrio quando um objeto precisa solicitar servios
(interagir) de outro com o envio de mensagens. Nesse caso, o objeto remetente
precisa ter uma referncia para o receptor.
A forma usual de um objeto ter uma referncia para outro fazer com que o
remetente tenha conhecimento direto da classe do receptor. O tipo de dependncia
corresponde ao chamado acoplamento concreto. Esse nome surge do fato de que
h duas classes concretas (ver Seo 8.5.2) envolvidas. Entretanto, h outra for
ma de dependncia que permite que um objeto remetente envie uma mensagem
para um receptor setn ter conhecimento da verdadeira classe desse ltimo; essa for
ma de dependncia corresponde ao acoplamento abstrato. Mas como o acopla
mento abstrato pode ser possvel? Para entendermos isso, vamos analisar nova
mente 0 conceito de interface, que descrevemos na Seo 8.5.4. Acompanhe
essa anlise a seguir, juntamente com a Figura 8-22, que ilustra esquematica
mente os acoplamentos concreto e abstrato.
Uma interface pode ser interpretada como um nvel de indireo, pelo qual
classificadores podem utilizar os servios uns dos outros. Para entender isso, con
sidere dois classificadores, Ca e Cbl. Suponha que Ca utiliza servios de Cbl
atravs de uma interface ICb. Se um novo classificador Cb2 que implementa a
mesma interface ICb foi desenvolvido, este pode substituir Cbl sem que Ca pre
cise sofrer modificaes quando essa substituio ocorrer. Para entender isso,
note que Ca utiliza os servhos implementados em Cbl por intermdio da interfa
ce ICb. Ou seja. Ca no tem uma referncia direta para uma instncia de Cb. Com
efeito, o uso de interfaces entre classificadores torna o sistema mais flexvel a mu
danas. Os classificadores fornecedores de algum servio podem ser substitudos
sem causar modificaes nos classificadores clientes, desde que a interao ocor
ra atravs de uma interface. Essa a essncia do acoplamento abstrato. Interfaces
permitem encapsular comportamento, ocultando qual a classe de um objeto que
est realizando uma tarefa especfica. Isso possvel porque a classe que imple
menta uma interface obrigada a seguir o protocolo definido nesta ltima.
Conforme tambm podemos inferir da Figura 8-22, o acoplamento abstrato
pode ser alcanado no s com o uso de interfaces, mas tambm com classes abs-
MODELAGEM DE CLASSES DE PROJETO 267

No h acoplamento Acoplamento abstrato por classe abstrata


Cliente -----------> Servio
Cliente Fornecedor

Acoplamento concreto fraco



Fornecedor

Cliente -------------------------- > Fornecedor


Acoplamento abstrato por interface
interface
Cliente -----------^
Acoplamento concreto forte Servno

Cliente ^ Fornecedor

Fornecedor

Figura 8-22: Formas de acoplamento entre classificadores.

tratas (ver Seo 8.5.2). A razo disso que o conceito de interface guarda diver
sas semelhanas com o conceito de classe abstrata, conforme descrevemos a se
guir. Em primeiro lugar, da mesma forma que uma classe abstrata, uma interface
no gera instncias. Alm disso, tanto interfaces quantos classes abstratas pos
suem um conjunto de operaes abstratas. Note, entretanto, que h diferenas
entre esses dois conceitos. Ao contrrio de uma classe abstrata, uma interface no
pode conter estrutura interna alguma (ou seja, no pode ter atributos, nem asso
ciaes). Alm disso, todas as operaes de uma interface s possuem especifica
es; a implementao (mtodo) de cada operao no definida na interface.

Uma interface (ou uma classe abstrata) descreve uma parte do comportamento
externamente visvel de um conjunto de objetos, possivelmente de classes dife
rentes. 0 acoplamento abstrato entre elementos (classificadores) que podemos
alcanar com o uso de uma interface ou de uma ciasse abstrata muito importante
na construo de sistemas orientados a objetos de qualidade. Quando bem utili
zado, esse tipo de acoplamento aumenta a flexibilidade e a capacidade de reutiliza
o do sistema, assim como a qualidade do cdigo-fonte. Isso porque o acopla
mento abstrato nos permite isolar um conjunto de servios de certa aplicao que
so instveis, no sentido de terem alto potencial de precisarem de modificaes
em sua implementao no futuro. Se detectamos algum conjunto de servios com
essa caracterstica de instabilidade, podemos isol-lo por trs de uma interface
(ou classe abstrata). Os clientes desse conjunto de servios tm acesso a eles por
intermdio da interface, sem precisarem ter conhecimento direto das classes que
os implementam. Se a implementao de algum servio precisar ser alterada, no
precisaremos modificar os clientes do servio. Nos padres de projeto que descre
vemos na Seo 8.6, o acoplamento abstrato um princpio fundamental.
268 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

8.5.6 Reuso atravs de delegao


Na Seo 8.5.1, descrevemos duas formas de reuso por herana: reuso de interfa
ce e reuso de comportamento. Este ltimo se baseia na noo de que subclasses
herdam comportamento de sua superclasse. Por exemplo, na Figura 8-23, quan
do um objeto da classe ContaCorrente recebe uma mensagem para executar a
operao debitar, ele no tem como atender a essa mensagem s com os recur
sos de sua classe. Ele, ento, utiliza a operao herdada da superclasse. A heran
a de comportamento um mecanismo fcil de implementar; tudo que o desen
volvedor deve fazer na definio de uma subclasse adicionar novas proprieda
des s existentes na superclasse, ou redefinir as propriedades herdadas para se
adequarem ao seu comportamento. No entanto, a herana por comportamento
tem a desvantagem potencial de expor as subclasses aos detalhes de sua super
classe, violando assim o princpio do encapsulamento (ver Seo 1.2.3.1).

Figura 8-23: Redefinio de operaes abstratas herdadas da superclasse.

O reuso de comportamento pode se dar no s pela herana entre classes,


mas tambm pelo mecanismo de delegao. No reuso por delegao, sempre
que um objeto no pode realizar uma tarefa (ou parte dela) por si prprio, ele
delega a realizao da mesma a outro(s) objeto(s). Nesse sentido, podemos afir
mar que o objeto reusa as operaes dos objetos para os quais ele delega respon
sabilidades.
Como um exemplo que serve de comparativo para as duas estratgias de
reuso de comportamento, a Figura 8-24 ilustra a definio de uma classe Pilha
segundo duas alternativas. Na primeira alternativa, a definio feita pelo reuso
por herana; a classe Pi 1ha definida com uma subclasse de Vetor. Note que a
classe Pi 1ha herda tambm operaes que no fazem sentido para objetos dessa
classe (por exemplo, elementos no podem ser inseridos em qualquer posio
de uma pilha, assim como ocorre em um vetor). Na segunda alternativa, a defi-
MODELAGEM DE CLASSES DE PROJETO 269

nio feita pela delegao. Um objeto Pilha agrega (tem como componente)
um objeto Vetor. As operaes na classe Pi 1ha so implementadas pela delega
o de mensagens para o objeto Vetor. Dessa forma, os clientes da classe Pi 1ha
somente tm acesso s operaes definidas nessa classe. Isso porque o objeto
Vetor est encapsulado na implementao da classe Pi 1ha.

Figura 8-24: Duas definies da classe Pilha reutilizando a classe Vetor.

A delegao mais genrica que a herana entre classes, pois um objeto


pode reutilizar o comportamento de outro sem que o primeiro precise ser uma
subclasse do segundo. Outra vantagem da delegao sobre a herana que o
compartilhamento de comportamento e o reuso podem ser realizados em tem
po de execuo. Na herana de classes, o reuso especificado estaticamente. No
entanto, a delegao pode apresentar perda de desempenho quando comparada
a uma soluo que use herana. Isso porque a delegao implica cruzar a fronteira
de um objeto a outro para enviar a mensagem de delegao. Concluindo, h
vantagens e desvantagens tanto no reuso por heranas e por delegao, e a utili
zao de uma ou outra depende da considerao de diversos fatores. De uma
forma geral, no se recomenda utilizar herana nas seguintes situaes:

Para representar papis de uma superclasse.


Quando a subclasse for herdar propriedades que no se aplicam a ela.
Quando um objeto de uma subclasse pode se transformar em um objeto
de outra subclasse. Por exemplo, um objeto da classe Cliente se transfor
ma em um objeto da classe Funcionrio.

8.5.7 Classificao dinmica


Na maioria dos casos prticos em que a herana deve ser utilizada, temos o caso
da classificao esttica. Segundo essa classificao, desde o momento em que
um objeto instanciado at o momento em que ele destrudo, sua classe per-
270 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

manece a mesma. Entretanto, um problema com o qual o modelador pode se de


parar na especificao e implementao de uma relacionamento de herana a
classificao dinmica, tambm chamada de metamor/ose. Para entender esse
conceito, considere uma empresa em que h empregados e clientes. Pode ser
que uma pessoa, em um determinado momento, seja apenas cliente; depois
pode ser que ela passe a ser tambm um empregado da empresa. A seguir, essa
pessoa desligada da empresa, continuando a ser cliente. Ou seja, um mesmo
objeto pode pertencer a diferentes classes durante a sua vida (da o nome meta
morfose). Mais que isso, um mesmo objeto pode pertencer a mltiplas classes si
multaneamente (por exemplo, uma pessoa que , ao mesmo tempo, cliente e
funcionrio da empresa).
As principais linguagens de programao orientadas a objetos (C++,
Java, as linguagens .NET, Smalltalk) no do suporte direto implementa
o da classificao dinmica. Nessas linguagens, se um objeto instanciado
como sendo de uma classe, ele no pode pertencer posteriormente a uma ou
tra classe.
Uma soluo parcial para o problema da classificao dinmica definir
todas as possveis subclasses em uma determinada situao. Utilizando essa
soluo, o problema da empresa descrito h pouco seria modelado como
uma hierarquia de classes em que haveria as subclasses Empregado (objetos
que so s empregados), Cl i ente (objetos que so s clientes) e Empregado-
Cliente (objetos que so tanto clientes quanto empregados). Essa soluo
no resolve o problema todo, pois pode ser que um objeto mude de classe.
Alm disso, considere que o conceito de gerente tenha de ser adicionado
hierarquia de herana. Isso elevaria o nmero de subclasses de trs para cin
co (fica como exerccio para o leitor verificar esse fato), tornando o modelo
ainda mais complexo.
Uma melhor soluo para o problema da classificao dinmica utilizar a
tcnica de delegao descrita na Seo 8.5.6. Por meio dessa tcnica, o relacio
namento de herana existente entre cada subclasse e a superclasse substitudo

Fig u ra 8-25: Exemplo de soluo para o problema da classificao dinmica.


MODELAGEM DE CLASSES DE PROJETO 271
ELSEVIER

por uma composio. Como um exemplo dessa soluo, considere a Figura


8-25. A parte esquerda da figura exibe um fragmento de diagrama de classes de
anlise que apresenta uma hierarquia de classes. A parte direita da figura apre
senta uma possvel reestruturao feita na especificao para solucionar o pro
blema da classificao dinmica. Note que, no diagrama reestruturado, uma
pessoa pode apresentar comportamento somente de um cliente, apenas de um
empregado, ou de ambos.
Como um comentrio final sobre a classificao dinmica, note que durante
a construo do modelo de anlise, o modelador no deve se preocupar com
esse problema. Portanto, nada impede que haja uma hierarquia de classes em
um modelo de anlise na qual um objeto possa pertencer a mais de uma subclas
se, ou possa mudar de subclasse. Entretanto, quando chega a fase de projeto, o
modelador deve considerar a reestruturao da hierarquia de classes para resol
ver o prohlema da classificao dinmica.

8.6 Padres de projeto


da natureza do desenvolvimento de software o fato de que os mesmos proble
mas tendem a acontecer diversas vezes. Na Seo 5.4.4, descrevemos alguns pa
dres de anlise, ou seja, padres de software teis para serem utilizados em
problemas de modelagem recorrentes na fase de anlise do desenvolvimento de
um SSOO. Outra categoria de padres de software extremamente til so os pa
dres de projeto (traduo para design pattem s). O texto clssico sobre esse as
sunto o livro de Eric Gamma e seus colaboradores (Gamma et al., 2000). Esses
autores so popularmente conhecidos como equipe GoE (de Gang o f Four, por
conta de serem quatro autores). Nesse livro, os autores catalogaram 23 padres
de projeto. Os padres de projeto descritos pela equipe GoE foram divididos em
trs categorias, descritas a seguir.

1. Criacionais: procuram separar a operao de uma aplicao de como os


seus objetos so criados.
2. Estruturais: proveem generalidade para que a estrutura da soluo possa
ser estendida no futuro.
3. Comportamentais: utilizam herana para distribuir o comportamento
entre subclasses, ou agregao e composio para construir comporta
mento complexo a partir de componentes mais simples.

Os 23 padres documentados pela equipe GoE so enumerados na Tabela


8-5. Uma descrio detalhada de todos os padres enumerados mais adiante
est fora do escopo deste livro. Para um estudo mais detalhado sobre o assunto,
o leitor pode consultar a referncia (Gamma, 1995). Outra referncia importan-
272 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

te a que descreve os padres de projeto do catlogo J2EE (Alur et a l, 2003).


Por outro lado, consideramos importante, mesmo em um livro introdutrio
como este, dar uma viso geral de um assunto to importante para o desenvolvi
mento de um SSOO. Para isso, descrevemos nas prximas sees trs dos pa
dres de projeto representativos da categoria GoF. So eles: Composite, Obser
ver, Strategy, Factory Method, Mediator e Faade.

Tabela 8-5: Padres de projeto documentados pelo catlogo GoF

Criacionais Estruturais Comportamentais


Abstract Factory Adapter Chain of Responsibility
Builder Bridge Command
Factory Method Composite Interpreter
Prototype Decorator Iterator
Singleton Faade Mediator
Flyweight Memento
Proxy Observer
State
Strategy
Template Method
Visitor

Um padro de projeto corresponde a um esboo de uma soluo reusvel para um


problema comumente encontrado em um contexto particular. Estudar padres
uma maneira eficaz de aprender com a experincia de outros.

8.6.1 Composite
o padro Composite um dos 23 padres catalogados no livro de Eric Camma e
de seus colaboradores. O problema que esse padro considera o seguinte:
como definir uma relao hierrquica entre objetos de tal forma que tanto o ob
jeto todo quanto os objetos parte sejam equivalentes em certos aspectos?
O padro Composite pode ser utilizado para solucionar o problema de re
presentar uma hierarquia de composio recursiva entre entidades. Esse pro
blema conhecido como problema da exploso de partes (parts explosion pro-
blem). O exemplo clssico desse problema o da montagem de peas: uma pea
composta de diversas outras peas, e essas peas componentes so elas pr
prias compostas, e assim por diante.
MODELAGEM DE CLASSES DE PROJETO 273

A Figura 8-26 exibe a estrutura do padro Composite (so apresentadas so


mente as classes, sem atributos nem operaes). O Componente uma super
classe. H dois tipos de componente, Folha e Composto. Uma folha no possui
componentes, enquanto um composto possui. A associao entre Composto e
Componente que representa a hierarquia de composio recursiva: um com
posto possui diversos componentes, que podem ser ou folhas ou outros com
postos.

Componente
+ op eracao() filhos
Cliente + a d ic io n a r (in C o m p o n e n te ) O padro GoF Composite
+ r c m o v e r ( in C o m p o n e n t e ) representa uma hierarquia
+ b t e r F i lh o (in m t) de composio recursiva:
um composto possui
----------- A diversos componentes, que
podem ser ou folhas ou
C outros compostos.

Folha Composto
+operao() +operao()
+adicionar(in Componente)
+remover(in Componente)
Para todos os filhos, faJ^ +obterFilho(in ini)
g.operaoO

Figura 8-26: O Padro Composite.

8.6.2 Observer
o objetivo desse padro definir de forma flexvel uma dependncia um para
muitos entre objetos. Ou seja, o padro Observer til quando h um objeto
central e diversos outros objetos que dependem do primeiro. A dependncia
aqui no sentido de que, se houver alguma modificao no estado do objeto
central, os objetos dependentes devem ser notificados. A preocupao aqui
com respeito ao acoplamento: necessitamos que o objeto central seja capaz de
enviar mensagens de notificao aos seus dependentes sem, no entanto, conhe
c-los diretamente. Em outras palavras, desejamos que haja um acoplamento
fraco entre os objetos dependentes e o objeto central.
A soluo que o padro Observer descreve para o problema fazer com que
os objetos dependentes implementem uma interface (ver Seo 8.5.4) comum
para propiciar o acoplamento abstrato entre cada dependente e o objeto central.
Alm disso, o objeto central deve manter uma lista de referncias para os seus
dependentes. Quando o estado do objeto central modificado, os dependentes
so comunicados por intermdio dessa interface. Tudo o que o objeto central
precisa saber que existem objetos que implementam essa interface. No entan
to, 0 objeto central no precisa ter conhecimento de quais so as classes dos ob
jetos dependentes.
274 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Quadro 8-8: Interface Observer

r interface Observer {
void update(Observable t, Object o);
}

A interface que o objeto central assume que seus dependentes implemen


tam apresentada no Quadro 8.8 (utilizamos a sintaxe da linguagem Java). Essa
interface possui uma nica operao, update. A classe Observable uma su
perclasse do objeto central. Ao ser modificado, esse objeto notifica aos seus de
pendentes chamando a operao update e passando a si prprio como primeiro
argumento. Dessa forma, cada observador (objeto dependente) pode consultar
0 objeto central para saber o que foi modificado neste ltimo.
A razo para a necessidade de a classe do objeto central ser uma subclasse de
Observable que essa ltima fornece duas funcionalidades importantes para
suas subclasses: (1) a de notificao dos dependentes e (2) a de manuteno des
ses dependentes. Em particular, a classe Observable em Java contm as seguin
tes operaes, para manuteno da lista de objetos dependentes:

public void addObserver(Observer obs)


Adiciona um novo objeto na l i s t a de objetos dependentes.

public void deleteObserver(Observer obs)


Remove um objeto da l i s t a de objetos dependentes.

Note que essas operaes so definidas em termos da interface Observer.


Isso significa que, para um objeto ser inserido na lista de dependentes (observa
dores) do objeto central, basta o primeiro implementar a interface Observer. A
Figura 8-27 d uma viso geral da estrutura do padro Observer.
Uma aplicao prtica do padro de projeto Observer na implementao
da comunicao entre camadas de software (ver Seo 11.1.1 ). O padro Obser-

Figu ra 8-27: Estrutura do padro Observer.


MODELAGEM DE CLASSES DE PROJETO 275

ver til nesse caso para permitir que uma camada de software mais genrica
possa enviar sinais para uma camada menos genrica. O elemento pertencente
camada mais genrica, representado pelo objeto central, pode estar associado a
diversos objetos que dele dependem e que esto localizados na camada mais es
pecfica, que so representados como objetos dependentes.

8.6.3 Strategy
o padro Strategy tem o objetivo de encapsular diferentes algoritmos para reali
zao de alguma tarefa computacional por trs de uma interface e permitir que a
regio de cdigo cliente dessa tarefa possa utilizar qualquer desses algoritmos
sem precisar ser modificada. Podemos tambm interpretar o padro Strategy
como uma forma de desacoplar uma regio de cdigo cliente de uma tarefa das
diferentes maneiras de implementar essa tarefa.
Como exemplo do padro Strategy, considere novamente nosso estudo de
caso representado pelo Sistema de Controle Acadmico (ver Seo 4.7). A insti
tuio de ensino na qual o SCA est para ser implantado utiliza uma forma de
calcular o grau final de um aluno em uma disciplina cursada. Esse grau uma le
tra: A, B, C, D ou E. Alm disso, esse grau calculado a partir de notas atribudas
a avaliaes. O projetista do SCA identificou que, atualmente, cada nota varia
na faixa de 0 a 10. No entanto, identificou que comum a coordenao modifi
car a estratgia (algoritmo) de atribuio de graus a partir da notas das avalia
es. Esse projetista definiu o diagrama de classes da Eigura 8-28, correspon
dente a uma estrutura de classes para clculo do grau. Nesse diagrama, nessa so
luo, Participao uma classe que representa participaes de alunos em
uma disciplina e suas correspondentes avaliaes em termos de notas. Alm dis
so, a operao calcular retorna o grau do aluno.
A soluo proposta pelo projetista foi inspirada pelo padro de projeto Stra
tegy. Na Figura 8-28, temos uma hierarquia de classes. A raiz dessa hierarquia
uma classe abstrata. Essa classe possui uma operao abstrata, calcular. As duas

interface
Participao 1 > EstratgiaCdlculoGrau
+obterGrau() 0^ estratgia
+calcular() No padro GoF Strategy, N
C N <3 >\ uma famlia de algoritmos
estratgia. calcularO / fica encapsulada por trs de
/ \
/ \ uma interface, em um tpico
exemplo de acoplamento
abstrato por interface.

EstratgiaClculoGrau 1 EstratgiaClculoGrau2
+calcular() 4-calcularO

Figu ra 8-28: Exemplo do padro de projeto Strategy.


276 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

subclasses fornecem implementao para a operao abstrata que herdam de


sua superclasse. Uma regio de cdigo da aplicao fica responsvel (1) por
identificar qual a estratgia vigente para clculo de grau e (2) por instanciar o
objeto da subclasse correspondente. Uma vez que esse objeto est instanciado, a
regio de cdigo cliente pode, por intermdio da interface, enviar a mensagem
que ativa a execuo do mtodo calcular.
A grande vantagem dessa soluo est na flexibilidade resultante. Para en
tender isso, note que a regio de cdigo cliente no precisa ser alterada quando a
forma de clculo de grau tiver que ser alterada. Tudo o que a regio de cdigo
cliente conhece acerca da regio de cdigo fornecedora do servio (nesse caso, o
clculo do grau do aluno em uma disciplina) que existe uma operao chama
da calcular, que realiza o clculo. A regio de cdigo cliente no sabe nem preci
sa saber qual o objeto especfico que est fornecendo uma implementao dessa
operao.
importante notar tambm que uma soluo alternativa equivalente utili
zao de uma classe abstrata seria utilizar uma interface (ver Seo 8.5.4). Nessa
soluo, as classes EstratgiaClculoGraul e EstratgiaC1culoGrau2 iriam im
plementar a interface. Em ambos os casos, entretanto, o acoplamento abstrato
(ver Seo 8.5.5) mantido entre os elementos envolvidos.

8.6.4 Factory Method


Quando uma determinada parte de um SSOO precisa dos servios de um ob
jeto, essa parte envia mensagem para este ltimo. No entanto para que um
objeto receba mensagens, ele deve existir: no faz o menor sentido falar em
envio de mensagens para um objeto que no existe. Para um objeto existir,
ele deve ser instanciado a partir de uma classe. Instanciar uma classe significa
criar um objeto dessa classe. Fisicamente falando, isso significa (1) alocar es
pao em memria para armazenar o objeto e (2) iniciar o seu estado (ou seja,
os valores de seus atributos). Aps a instanciao, o objeto pode prover servi
os para outros objetos.
A operao de instanciao de um objeto pode ser bastante complexa. Alm
disso, pode ser que no seja adequado fazer com que uma regio de cdigo que
necessite de um servio tenha uma referncia direta para a classe que o fornece.
Uma razo para isso pode ser o fato de que a forma de implementar tal servio
instvel, no sentido de precisar ser alterada no futuro. Se a regio de cdigo ins
tanciar diretamente a classe que lhe fornece determinado servio, essa regio
fica definitivamente acoplada a essa classe fornecedora e a sua forma especfica
de prover o servio requerido.
Uma forma de resolver o problema descrito no pargrafo anterior com
um afbrica de objetos. Uma fbrica de objeto corresponde a uma classe cuja res-
MODELAGEM DE CLASSES DE PROJETO 277

ponsabilidade criar quando requisitada. O fato que essa fbrica retorna o ob


jeto criado na forma de uma referncia para uma superclasse abstrata (ver Seo
8.5.2) ou para uma interface (ver Seo 8.5.4). Dessa maneira, a regio cliente,
que previamente criava o objeto para lhe prover o serLo, agora fica dependen
te desse servio atravs de um acoplamento abstrato (ver Seo 8.5.5). Com efei
to, a classe que realmente fornece o servio requerido pode ser alterada sem que
a regio de cdigo cliente precise de modificao. Em essncia, essa a soluo
que o padro Factory Method descreve. Em outras palavras, o objetivo do pa
dro Factory Method definir uma interface para instanciar objetos. Esse um
dos padres criacionais definidos pelo GoF.
Note que a fbrica de objetos precisa fazer referncia s classes concretas cu
jos objetos fornecem o servio requerido, o que um exemplo de acoplamento
concreto. Entretanto, essa referncia fica localizada em uma regio de cdigo
particular (na fbrica de objeto) e conseqentemente aceitvel. Note que
quaisquer mudanas nas classes que fornecem o servio em questo ficam loca
lizadas na fbrica de objetos e no afetam os clientes.
Outro aspecto importante sobre o padro Factory Method que sua utiliza
o adiciona complexidade ao projeto. Na verdade, essa uma tnica na maio
ria dos padres de projeto: eles adicionam flexibilidade custa de adicionarem
complexidade soluo. No caso particular do padro Factory Method, a deciso
por utilizar o mesmo deve levar em considerao o fato de a classe que fornece o
servio ser realmente suscetvel a mudanas futuras. Do contrrio, a referncia
(instanciao) direta da classe que fornece o servio (em vez de utilizao do
padro Factory Method) uma alternativa mais vivel.

Figura 8-29: Estrutura do padro Factory Method.

Outro padro GoF de criao comumente utilizado o chamado Abstract


Factory. Esse padro uma extenso do Factory Method para criao de uma fa
mlia de objetos relacionados.
278 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

8.6.5 Mediator
o padro de projeto Mediator permite a um grupo de objetos interagir, ao mesmo
tempo que mantm um acoplamento fraco entre os componentes desse grupo. A
soluo proposta pelo padro Mediator para alcanar esse objetivo definir um
objeto, o mediador, para encapsular interaes da seguinte forma: o resultado da
interao de um subgrupo de objeto passado a outro subgrupo pelo mediador.
Dessa forma, os subgrupos no precisam ter conhecimento da existncia um do
outro e podem variar independentemente. Os objetos de controle, cuja especifi
cao descrevemos na Seo 8.1.3, so exemplos de mediadores.

8.6.6 Faade
No Captulo 11, descrevemos aspectos relativos diviso de um SSOO em
subsistemas. Nessa diviso, necessrio definir as interfaces de comunica
o (ou interao) entre os subsistemas resultantes. Nesse contexto, quando
dois subsistemas se comunicam, podemos dizer que h um cliente e um for
necedor. O subsistema cliente requisita algum servio, e o subsistema forne
cedor 0 que prov esse servio. O padro Faade procura resolver o seguin
te problema; como definir uma interface de alto nvel que torna um subsistema
mais fcil de ser utilizado? Em outras palavras, de que maneira podemos de
finir uma interface de comunicao mnima possvel entre os subsistemas clien
te e fornecedor?
A soluo fornecida por este padro a seguinte: criar uma fachada para o
subsistema fornecedor, de tal forma que o subsistema cliente se comunique
com o primeiro por intermdio desta fachada. A vantagem dessa soluo que o

X, Y e Z so classes clienteJ^
do subsistema de classes

Soluo sem o uso de um objeto Faade Soluo com o uso de um objeto Faade

Figura 8-30: Estrutura do padro Faade.


MODELAGEM DE CLASSES DE PROJETO 279

cliente somente conhece o necessrio e suficiente em relao complexidade


do fornecedor. Toda a complexidade adicional desse ltimo fica escondida
por trs da interface de comunicao.
A implementao do padro Faade relativamente simples. Consiste
em definir uma ou mais classes que implementam a interface de comunica
o necessria e suficiente. O subsistema fornecedor fica encapsulado por
essa interface.

8.7 Modelo de ciasses de projeto em um processo iterativo


Em um processo de desenvolvimento iterativo, o modelo de classes de projeto
construdo em diversas iteraes. Normalmente, esse modelo construdo em
paralelo com o modelo de interaes (ver Captulo 7). Isso porque o modelo de
interaes fornece informaes para completar o modelo de classes em seu est
gio de anlise a fim de lev-lo ao estgio de projeto. Em particular, uma mensa
gem que identificamos durante a construo dos diagramas de interaes sem
pre corresponde a uma operao na classe do objeto remetente. Para cada men
sagem identificada, a assinatura da operao correspondente deve ser comple
tamente especificada no modelo de classes de projeto.
Conforme descrevemos na Seo 10.2.3, o diagrama de atividades pode
ser utilizado na construo do modelo de classe de projeto, com o objetivo de
especificar alguma operao um tanto mais complexa. No entanto, impor
tante notar que, em um SSOO, operaes so normalmente simples, o que dis
pensa o detalhamento de sua lgica interna. No mais das vezes, essas opera
es tm 10 instrues ou menos. Algumas vezes, essas operaes tm uma ou
duas instrues. Alm disso, o modelo de interaes fornece informaes sufi
cientes para a implementao correta da lgica de funcionamento de uma ope
rao. Em suma, responsabilidades e operaes que no so nem simples nem
claras sugerem que a classe correspondente est mal projetada. Da mesma for
ma, classes com uma quantidade excessiva de operaes (mais de uma dzia)
tambm so altamente suspeitas. Alis, clareza e simplicidade devem ser per
seguidas desde a fase de anlise, durante a identificao das classes iniciais.
Lembre-se da modelagem CRC, em que cada carto possui um tamanho fixo, o
que fora o modelador a projetar classes simples. Os mesmos princpios de
clareza e simplicidade tambm devem ser perseguidos durante a modelagem
de interaes, pois essa atividade gera informaes para a completa especifica
o das operaes.
O conceito de reuso fundamental durante a construo do modelo de clas
ses de projeto. Os padres de projeto, para os quais demos uma pequena intro
duo na Seo 8.6, so mecanismos de reuso de solues para problemas re
correntes. Outra forma de reuso que deve ser considerada na fase de projeto.
280 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

no somente para a modelagem de classes, o uso de bibliotecas de classes e de


frameworks. Na Seo 12.2.4, descrevemos em mais detalhes o conceito de fra-
mework em um contexto especfico, o da persistncia de objetos.
adequado dizer que as atividades de especificao (projeto) e de imple
mentao so intimamente entrelaadas. Nas palavras de Philippe Krutchen,
um reconhecido arquiteto de software: Eu codifico para melhor entender o
que estou projetando. Essa sinergia entre o projeto e codificao de um SSOO
se justifica pelo fato de que, ao ser forado a moldar certa deciso de projeto
em uma implementao concreta e sem ambigidades, o desenvolvedor valida
a completa utilidade das classes que projetou. Note outra declarao de dois
outros respeitados tecnologistas, Don Roberts e Ralph Johnson: As pessoas
desenvolvem abstraes atravs da generalizao aplicada a exemplos concre
tos. Cada tentativa de determinar abstraes corretas no papel, sem realmente
desenvolver um sistema, est fadada ao insucesso. Ainda outra declarao,
dessa vez do lendrio Fred Brooks: Planeje para jogar um [verso do sistema]
fora; isso acontecer de qualquer maneira. Todas essas declaraes carregam
a mesma mensagem, em essncia: quando uma parte do sistema implemen
tada, isso resulta em informaes para melhorar a qualidade do projeto do
qual partiu a implementao. Nesse contexto, a construo de prottipos (ver
Seo 2.5) para validar as decises de projeto importante.
Uma dvida freqente diz respeito ao nvel de detalhe na especificao dos
diagramas de classes de projeto. H diversos fatores que influenciam a resposta
para essa questo. Em primeiro lugar, devemos perceber que um modelo que
no esteja em conformidade com o sistema no tem valia. Por outro lado, quan
to mais detalhados os modelos que construmos possuem, mais difcil man
t-los em sincronia com o cdigo-fonte, pois este ltimo muito instvel. Se a
equipe de desenvolvimento tiver disposio ferramentas CASE que permitam
realizar engenharias direta e reversa (ver Seo 2.6), a construo de modelos
mais detalhados possvel. Isso porque as prprias ferramentas podem atuali
zar os modelos existentes. Entretanto, se este no for o caso, a equipe corre o ris
co de perder tanto tempo mantendo os modelos atualizados quanto leva para real
mente implementar o sistema. Portanto, o bom senso tambm vale para decidir
o nvel de detalhamento que deve ser adotado na construo, no s dos diagra
mas de classes, mas de qualquer modelo de um SSOO.

8.8 Estudo de caso


Para exemplificar a especificao de classes no estudo de caso do Sistema de
Controle Acadmico, considere o diagrama de classes correspondente viso
de classes participantes do caso de uso Realizar Inscrio. A Figura 8-31 apre
senta uma verso inicial do refinamento desse diagrama, considerando vrios
MODELAGEM DE CLASSES DE PROJETO 281

assuntos tratados neste captulo. Por simplificao, os parmetros das opera


es no so exibidos.
Note que, por simplificao, apenas o refinamento correspondente a uma
das vises de classes participantes apresentado. Em uma situao real, todas as
classes de anlise devem ser consideradas..
ZS2 ,,%ALISE E PROJETO DE SISTEMAS COM UML, 2/E V T ,K

EXERCCIOS
8-1: No Captulo 7, descrevemos os conceitos de coeso e acoplamento. Qual a relao des
ses conceitos com a qualidade resultante da modelagem de classes de projeto?

8-2: Este captulo apresenta o relacionamento de dependncia e descreve diversos tipos de


dependncia que podem existir (por atributo, por varivel local etc.). Seja uma classe A que pos
sui pelo menos uma operao cujo tipo de retorno a classe B. Que tipo(s) de dependncia pode
haver entre A e B?

8-3: Em cada um dos itens a seguir, discuta qual tipo de relacionamento mais adequado (asso
ciao, agregao, composio). Desenhe o diagrama de classes correspondente, indicando as
multiplicidades. Especifique, ainda, atributos e possveis restries.

a) Um Pas possui uma Capital.


b) Uma Empresa subsidiria de diversas outras Empresas.
c) Uma Pessoa mesa de jantar est usando uma Faca.
d) Um Polgono composto por um conjunto ordenado de Segmentos.
e) Um Estudante acompanha uma Disciplina com um Professor.
f) Uma Caixa contm Garrafas.
g) Um Livro contm Captulos.
h) Um Arquivo contm Registros.

8-4: Para cada um dos itens do exerccio anterior, defina refinamentos sobre as associaes
existentes, considerando diversas possibilidades de navegabilidade entre tais associaes.

8-5: Forme uma hierarquia de classes a partir dos seguintes conceitos: Pessoa, Empregado,
Instrutor e Estagirio.

8-6: Em cada um dos itens abaixo, desenhe o diagrama de classes correspondente, indicando
as multiplicidades. Especifique, ainda, possveis restries que se apliquem.

a) Uma Pessoa, como programador, utiliza uma Linguagem de Programao.


b) Um Objeto de Desenho pode ser um Texto, um Grfico ou um Grupo de objetos.
c) Modem, Teclado e Impressora so Dispositivos de Entrada e Sada.
d) Um Banco de Dados contm Tabelas de Sistema e Tabelas de Usurio. Uma Tabela de Sistema
mantm informaes sobre uma ou vrias Tabelas de Usurio. Uma Tabela contm Registros.
e) Um Item pode ser um Item Atmico ou um Item Composto. Um Item Composto possui dois ou
mais Itens.

8-7: 0 que h de errado com o diagrama de classes a seguir? Construa uma nova verso deste
diagrama, consertando os erros identificados.
MODELAGEM DE CLASSES DE PROJETO 283

8-8: Crie um diagrama de classes de projeto para representar os conceitos de crculo e de elipse
como classes. Defina uma operao desenhar em ambas as classes. Dica: crie uma superclas-
se abstrata para organizar a hierarquia.

8-9: Considere as ciasses Rdio e Relgio a seguir. Qual o problema em definir uma classe R-
dioRelgio como subclasse das duas classes (herana mltipla)? Defina uma soluo, utilizan
do 0 mecanismo de delegao, para substituir a soluo por herana mltipla. Defina outra solu
o atravs de interfaces.

Rdio Relgio
-estao -horrio
+ligar r-ligar
+desligar -Hdesligar
+obterEstao() n-obterHorrioO
fdefinirEstaoO +definirEIorrio ( )

8-10; i\!o desenvolvimento de um sistema de software comercial, um modelador precisou re


presentar as classes clientes e funcionrios de uma empresa. Em vez de optar pela soluo do
diagrama esquerda, ele optou pela soluo representada direita na figura a seguir. Discuta as
vantagens e desvantagens de cada uma das duas solues. Reflita sobre a situao em que um
cliente pode tambm ser um funcionrio da empresa. E se uma classe gerente tivesse de ser
modelada?
284 princpios de analise e projeto de sistemas com UML, 2/E ELSEVIER

8-11: Considere os diagramas de classes de anlise fornecidos nos itens (a) e (b) a seguir, am
bos de acordo com a notao da UML. Esses diagramas desejam representar o fato de que uma
conta bancria pode estar associada a uma pessoa, que pode ser ou uma pessoa fsica (repre
sentada pela ciasse Indivduo), ou uma pessoa jurdica (representada pala classe Corporao).
Uma dessas duas solues melhor que a outra? Se sim, qual delas e em que sentido?

8-12: Considere uma aplicao para um bar-caf. Nessa aplicao, considere a existncia de
uma ciasse que representa um comestvel qualquer vendido pelo bar-caf: Comida. Considere
ainda duas outras classes nessa aplicao. Cozinha e CaixaRegistradora. A classe cozinha ma
nipula objeto da classe Comida para montar pratos. J a classe CaixaRegistradora manipula ob
jeto comida para registrar a venda dos mesmos e cobrar por eles. Portanto, essas duas classes
dependem dos servios fornecidos pela classe Comida. Em um primeiro modelo dessa aplica
o, 0 modelador fez com que as classes Cozinha e CaixaRegistradora dependessem direta
mente da ciasse Comida, conforme a Figura (a). No entanto, conforme o desenvolvimento foi se
evoluindo, o modelador identificou um novo requisito na aplicao: agora era preciso registrara
venda de coisas no comestveis. Por exemplo: o caf-bar passou a vender jornais dirios. Para
atender ao novo requisito, o modelador criou duas novas interfaces. Vendvel e Comestvel,
conforme est na Figura (b). Discuta a deciso de projeto do modelador. Voc achou a deciso
adequada? Que princpios de projeto levaram o modelador a tomar tal deciso?

Cozinha
CaixaRegistradora

CaixaRegistradora Cozinha
Interface
Interface Preparvel
Vendvel getNomeO
+getNome() getReceitaO
______i. -i-getPreo() -i-preparar()
Comida -t-venderO -pcozinharO
+getNome()
getReceitaO 71 ^
+gel?re(;oO
-hprepararO
^cozinha^()
+vender()

(a) JornalDirio Comida (b )

8-13: Voc est desenvolvendo uma aplicao para uma empresa que vende componentes de
computador. Atualmente, voc est construindo uma hierarquia de classes para representar os
diferentes tipos de componentes (voc nomeou essas classes como Processador, DiscoRgido
MODELAGEM DE CLASSES DE PROJETO 285

e CDROM). Essa hierarquia contm tambm uma superciasse abstrata denominada Componen
te, da qual so derivadas as demais classes. Por outro lado, um amigo seu j desenvolveu um
sistema semelhante e lhe passou classes para representar discos rgidos e CPUs (as classes
dele so denominadas HardDisk e CPU respectivamente). De que maneira voc pode construir
sua hierarquia de classes aproveitando (reutilizando) as classes fornecidas pelo seu amigo, sem
precisar modific-las? Que padro de software poderia ser empregado para auxiliar na definio
da estrutura de classes a fim de representar a situao discutida anteriormente? Utilizando esse
padro, fornea um fragmento de diagrama de classes que represente essa situao.

8-14: Suponha que voc precise criar em uma aplicao um objeto que, uma vez instanciado,
no deve ter seu estado alterado sob hiptese algum. Descreva uma soluo para esse proble
ma. Pode pensar em possveis aplicaes para essa situao. Dica: procure por Immutable Pat-
tern na Internet

8-15: Suponha que voc precise ter uma classe C em sua aplicao para a qual a forma de aces
so diferenciada, no seguinte sentido: h um conjunto de classes que tm permisso para alte
rar 0 estado dos objetos da classe C; h tambm outro conjunto de classes que, embora faam
uso dos servios fornecidos por objetos da ciasse C, no tm permisso para modificar o estado
desses objetos. Defina uma soluo de projeto para esse problema. Dica: utilize o conceito de
interface.

8-16: Imagine que um projetista est especificando um SSOO para gerenciar conferncias. Uma
conferncia possui diversos recursos cuja alocao precisa ser agendada. Ou seja, para certo
evento em uma conferncia, diversos recursos so alocados. Os recursos so de diversas natu
rezas: funcionrios, equipamentos, salas de apresentao. Suponha que voc esse projetista.
Que soluo de projeto poderia ser definida para esse problema?

Agenda
Interface
^ ------ ------ > Agendvel
-fadicionar(in rec ; Agendvel, in d : DateTime, in L; Durao)
1
+remover(in rec : Agendvel) ^ A ^

____ ____ 1 ___ ^____


Em pregado Equipam ente SalaR eu nio

8-17: Analise as relaes existentes entre o conceito de interface e os princpios de polimorfis


mo e de encapsulamento da orientao a objetos.

8-18: Defina as diferenas e semelhanas existentes entre uma classe abstrata e uma interface.
Qual a diferena entre uma classe concreta que herda de uma classe abstrata e a realizao de
uma interface?
9
Modelagemdeestados
Todos os adultos um dia foram crianas, mas poucos se lembram disso.
-ANTOINE DE SAINT-EXUPRY, O PEQUENO PRNCIPE

bjetos do mundo real se encontram em estados particulares a cada

O momento. Por exemplo, uma jarra est cheia de lquido; uma pessoa
est cansada. Da mesma forma, cada objeto participante de um siste
ma de software orientado a objetos se encontra em um estado particular. Um ob
jeto muda de estado quando acontece algum evento interno ou externo ao siste
ma. Quando um objeto muda de um estado para outro, diz-se que ele realizou
uma transio entre estados. Os estados e as transies de estado de um objeto
constituem o seu ciclo de vida. Quando da sua transio de um estado para ou
tro, um objeto normalmente realiza determinadas aes dentro do sistema.
Cada objeto pode passar por um nmero finito de estados durante a sua vida.
Quando um objeto transita de um estado para outro, significa que o sistema no
qual ele est inserido tambm est mudando de estado.
Pela anlise das transies entre estados dos objetos de um sistema de soft
ware, podem-se prever todas as possveis operaes realizadas, em funo de
eventos que podem ocorrer. O diagrama da UML utilizado para realizar essa an
lise o diagrama de transio de estado (DTE). Esse diagrama permite descrever
o ciclo de vida de objetos de uma classe, os eventos que causam a transio de
um estado para outro e a realizao de operaes resultantes.
A notao e a semntica iniciais do DTE foram propostas por David Harel
(Harel, 1987) em seu trabalho com mquinas de estados finitos (finite State ma-
288 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

chins). A idia bsica de Harel foi definir uma mquina com uma quantidade
fixa de estados (da o nome mquina de estados finitos). A mquina pode rece
ber eventos, e cada evento pode ocasionar a transio de um estado para outro.
Posteriormente, Jim Rumbaugh (um dos trs amigos) e outros (Mealy e Moo-
re) estenderam a proposta inicial de Harel com vrias outras notaes e o dia
grama de transies de estado foi incorporado UML.
Na modelagem de sistemas orientados a objetos, a modelagem dinmica des
creve o comportamento dinmico dos objetos durante a execuo do sistema.
No Captulo 7, descrevemos dois diagramas da UML para realizar modelagem
dinmica. Utiliza-se tambm o DTE para obter uma viso dinmica do sistema.
No entanto, diferentemente dos diagramas de interao (que descrevem o com
portamento de objetos de classes diferentes), um DTE descreve o comporta
mento dos objetos de uma nica classe. Os diagramas de transio de estado no
so definidos para todas as classes de um sistema, mas apenas para aquelas que
possuem um nmero definido de estados conhecidos, e quando o comporta
mento das classes de objetos afetado e modificado pelos diferentes estados.
Nessas classes, um DTE pode ser utilizado para enfatizar os eventos que resul
tam em mudanas de estado.

9.1 Diagrama de transio de estado


A UML tem um conjunto rico de notaes para desenhar um DTE. Alguns ele
mentos bsicos de um diagrama de transio de estados so os estados e as tran
sies. Associados a estas ltimas, esto os conceitos de evento, ao e atividade.
Um DTE pode tambm conter elementos menos utilizados, mas s vezes teis,
como transies internas, estados aninhados e estados concorrentes. A seguir, a
notao e a semntica bsicas dos diagramas de estado so descritas. Para essa
descrio, o DTE da Eigura 9-1 utilizado como exemplo. Esta figura ilustra um
DTE para a classe ContaBancria.

9.1.1 Estados
Um estado uma situao na vida de um objeto durante a qual ele satisfaz algu
ma condio ou realiza alguma atividade. Cada estado de um objeto normal
mente determinado pelos valores dos seus atributos e (ou) pelas suas ligaes
com outros objetos. Por exemplo: o atributo resei'vado deste objeto livro tem
valor verdadeiro. Outro exemplo: uma conta bancria passa para o vermelho
quando o seu saldo fica negativo.
A notao UML para representar um estado um retngulo com as bordas
arredondadas. Na sua forma mais simples, o retngulo de um estado possui um
nico compartimento (conforme ilustrado na Eigura 9-2). O estado inicial re
MODELAGEM DE ESTADOS 289

Realizar depsito (quantia)


/ depositar(quantia)

after(30 dias)/aplicarJuros()
Figura 9-1: Exemplo de DTE para a classe ContaBancria.

presentado como um crculo preenchido e indica o estado de um objeto quando


ele criado. S pode haver um estado inicial em um DTE. Essa restrio serve
para definir a partir de que ponto um DTE deve comear a ser lido. ^O estado fi
nal representado como um crculo eclipsado (ver Eigura 9-2) e indica o fim
do ciclo de vida de um objeto. Este estado opcional e pode haver mais de um
estado final em um DTE.

Estado Estado
Estado final
inicial ordinrio

[ estado ]

Figura 9-2: Elementos grficos bsicos de um DTE

^Na verdade, conforme descrito mais adiante, em um DTE com estados aninhados, pode haver mais de
um estado inicial.
290 prin c pio s DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

9.1.2 Transies
Os estados esto associados a outros pelas transies. Uma transio mostrada
como uma linha conectando estados, com uma seta apontando para um dos es
tados. Quando ocorre uma transio entre estados, diz-se que a transio foi dis
parada. Note que, em uma transio, o estado subsequente pode ser igual ao es
tado original. Uma transio pode ser rotulada com uma expresso. A seguir,
apresentada a forma geral dessa expresso. Seus detalhes so descritos nas se
es a seguir.
evento (lista-parmetros) [guarda] / ao

9.1.3 Eventos
Uma transio possui um evmto associado. Um evento algo que acontece em
algum ponto no tempo e que pode modificar o estado de um objeto. Alguns
exemplos de eventos so listados a seguir:

Tabela 9-1: Exemplos de nomes de eventos em sistemas de software e em processos


de negcio

Em sistemas de software Em processos de negcio


1 Mouse pressionado 1 Pedido realizado
2 Disco inserido 2 Fatura paga
3 Cheque devolvido

Um evento pode conter uma lista de parmetros (veja o elemento lis-


ta-parmetros na sintaxe anterior). Os parmetros so passados para fornecer
informaes teis ao objeto receptor de evento. A lista de parmetros especifi
cada entre os parmetros. Por exemplo, na expresso Mouse P r e s s i o n a d o (lo
ca 1), o parmetro local indica em que posio da tela o mouse foi pressionado.
Os eventos relevantes a uma classe de objetos podem ser classificados em
trs tipos. Estes tipos so descritos a seguir.

1. Evento de chamada: recebimento de uma mmsagem de outro objeto. Pode-se


pensar neste tipo de evento como uma solicitao de servio de um obje
to a outro.
2. Evento de sinal: recebimento de um sinal. Este um tipo especial do evento
anterior. Neste evento, o objeto recebe um sinal de outro objeto que pode
faz-lo mudar de estado. A diferena bsica entre o evento de sinal e o
evento de chamada que neste ltimo o objeto que envia a mensagem
fica esperando a execuo da mesma. No evento de sinal, o objeto reme-
MODELAGEM DE ESTADOS 291

tente continua o seu processamento aps ter enviado o sinal. O evento de


sinal raramente utilizado.
3. Evento temporal: passagem de um intervalo de tempo predefinido. Em vez de
receber uma mensagem especfica, um objeto pode interpretar a passa
gem de um certo intervalo de tempo como sendo um evento.^ Um evento
temporal especificado com a clusula after seguida de um parmetro
que especifica um intervalo de tempo. Por exemplo, a expresso after (30
segundos) indica que a transio correspondente ser disparada 30 se
gundos aps o objeto ter entrado no estado atual.
4. Evento de mudana: uma condio que se tom a verdadeira. O fato de uma de
terminada condio se tornar verdadeira tambm pode ser visto como
um evento. Este evento representado por uma expresso de valor lgi
co (verdadeiro ou falso) e especificado utilizando-se a clusula when. Por
exemplo, a expresso when (sal do > 0) significa que a transio dispara
da quando o valor do atributo saldo for positivo (ver Eigura 9-1). Eventos
temporais (descritos no item anterior) tambm podem ser definidos uti
lizando-se a clusula when. Alguns exemplos: when(data = 13/07/2002),
when(horrio = 00:00h) etc.

Considere a Eigura 9-1. H uma transio reflexiva (ou seja, uma transio
que sai de um estado e entra no mesmo estado) quando a conta bancria est
bloqueada. Essa transio possui um evento temporal, indicando que 30 dias
aps a conta ter entrado nesse estado, a operao apl i carJuros() executada. A
Eigura 9-1 tambm apresenta um exemplo de evento de mudana na transio
de bloqueada para disponvel. Esse evento passa um parmetro (saldo > 0) corres
pondente a uma expresso condicional. Quando essa expresso for verdadeira,
a transio disparada.
A ocorrncia de um evento relevante pode ocasionar outro evento. A Eigura
9-3 ilustra esquematicamente dois diagramas de estados. O primeiro exibe a
forma normal de representao de um evento: quando Evento ocorre, o objeto

Figura 9-3: Ocorrncia de evento ativando outro evento.

^ Para o leitor familiarizado com a terminologia da Anlise Estruturada, esse evento equivalente ao
evento temporal.
zsz PRIWCPWS QE MM.USE E PRQJETQ DE SISTEMAS COM UME, Z ELSEVIER

passa de Estado 1 para Estado 2. A mesma transio acontece no segundo DTE.

jetoAlvo) disparado.

9.1.4 Condio de guarda


Uma transio pode tambm ter uma condio de guarda. Uma condio de guar
da, ou simplesmente guarda, uma expresso de valor lgico, da mesma forma
que a utilizada para diagramas de interao (ver Seo 7.1.1.2.2). A condio de
guarda de uma transio pode ser definida utilizando-se parmetros passados
no evento e tambm atributos e referncias a ligaes da classe em questo.
Alm disso, uma condio tambm pode testar o valor de um estado.
Uma transio na qual foi definida uma condio de guarda disparada so
mente se o evento associado ocorre e a condio de guarda verdadeira. Se uma
transio no tiver uma condio de guarda, ela sempre ser disparada quando
o evento ocorrer. importante no confundir a condio de guarda de uma
transio com um evento de mudana (que tambm definido com uma ex
presso de valor lgico). A expresso condicional de uma condio de guarda
sempre apresentada entre colchetes. Ao contrrio, a expresso condicional nos
eventos de mudana so parmetros da clusula when.
Como exemplo, a Figura 9-1 ilustra uma transio entre os estados disponvel e
bloqueada. Essa expresso possui uma condio de guarda, [quantia = saldo], onde
quantia um parmetro recebido e sal do um atributo da classe ContaBancri a.
Quando o evento Real izar saque ocorre, a transio somente ocorrer se a condi
o de guarda for verdadeira. Se no for o caso, o evento ignorado pelo objeto.

9.1.5 Aes
Ao transitar de um estado para outro, um objeto pode realizar uma ou mais
aes. Uma ao uma expresso que pode ser definida em termo dos atributos,
das operaes ou das associaes da classe. Os parmetros do evento tambm
podem ser utilizados. Uma ao pode tambm corresponder execuo de uma
operao. A ao representada na linha da transio e deve ser precedida por
uma barra inclinada para a direita (smbolo /) Note que a ao associada a
uma transio executada somente se a transio for disparada. Uma ao pode
gerar outros eventos. Esses eventos podem ser relevantes para o prprio objeto
ou para outros objetos.
Pode haver aes especiais que so executadas sempre que um objeto passa
para um determinado estado (no importa por qual transio) ou sempre que o
objeto sai de um estado (tambm no importando por qual transio). Essas
aes especiais so descritas na Seo 9.1.8.
MODELAGEM DE ESTADOS 293

9.1.6 Atividades
Semelhante a uma ao, uma atividade algo que executado pelo objeto. No
entanto, uma atividade pode ser interrompida (considera-se que o tempo de
execuo de uma ao to insignificante que esta no pode ser interrompida).
Por exemplo, enquanto a atividade estiver em execuo, pode acontecer um
evento que a interrompa e cause uma mudana de estado. Uma outra diferena
entre ao e atividade que uma atividade sempre est associada a um estado
(ao contrrio, uma ao est associada a uma transio). A forma de declarar ati
vidades descrita na Seo 9.1.8.

9.1.7 Ponto de juno


Em algumas situaes, o prximo estado de um objeto varia de acordo com o
valor da condio de guarda. Se o valor da condio de guarda for verdadeiro, o
objeto vai para um estado E l; se o valor for falso, o objeto vai para outro estado
E2. como se a transio tivesse bifurcaes, e cada transio de sada da bifur
cao tivesse uma condio de guarda. Essa situao pode ser representada em
um DTE por um ponto de juno.
Um ponto de juno desenhado como um losango^ em que chegam uma
ou mais transies (provenientes de estados diferentes) e de onde partem uma
ou mais transies. A cada transio de sada do ponto de juno est associada
uma condio de guarda. A transio que o objeto segue aquela para a qual a
condio de guarda verdadeira. A Eigura 9-4 apresenta de forma esquemtica
um fragmento de DTE que ilustra a utilizao de um ponto de juno. Desse
ponto, partem quatro transies. Cada uma dessas transies est associada a
uma condio de guarda e a uma ao. As aes so opcionais. importante en
fatizar que, quando uma das condies verdadeira, todas as demais so falsas.
Pontos de juno permitem que duas ou mais transies compartilhem uma
trajetria de transies. Na Figura 9-4, por exemplo, as transies que saem
dos estados EO e El compartilham o mesmo caminho de transies a partir do
ponto de juno. De uma forma geral, pode haver um nmero ilimitado de tran
sies saindo de um ponto de juno. Alm disso, nada impede que o estado no
qual chega uma transio que saiu de um ponto de juno seja o mesmo do qual
saiu uma transio que chegou a tal ponto de juno. Pode haver tambm uma
transio de sada que esteja rotulada com a clusula el se. Isso significa que, se
todas as outras condies de guarda forem falsas, a transio correspondente
clausula ei se ser disparada.

^Uma notao alternativa utilizar um pequeno crculo, semelhante representao de um estado inicial
294 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Figura 9-4: Utilizao de pontos de juno em um DTE.

9.1.8 Clusulas entry, exit e do


No compartimento adicional de um retngulo de estado, podem-se especificar
aes ou atividades a serem executadas.

1. A clusula entry pode ser usada para especificar uma ao a ser realizada
no momento em que o objeto entra em um estado. A ao dessa clusula
sempre executada, independentemente do estado do qual o objeto veio
( como se a ao especificada estivesse associada a todas as transies de
entrada no estado).
2. A clusula exi t serve para declarar aes que so executadas sempre que
o objeto sai de um estado. Da mesma forma que a clusula entry, a ao
da clusula exi t sempre executada, independentemente do estado para
o qual o objeto vai ( como se a ao especificada estivesse associada a to
das as transies de sada do estado).
3. A clusula do serve para definir alguma atividade a ser executada quando
o objeto passa para um determinado estado. (Note a diferena em relao
clusula entry, que serve para especificar uma ao em vez de uma ati
vidade.)

As clusulas predefinidas (entry, exit, do) so especificadas no interior do


retngulo do estado e tm a seguinte sintaxe:
evento / [ao | atividade]

A Figura 9-5 ilustra de forma esquemtica um DTE no qual foi especificada


a clusula do. Note que a inexistncia de um evento na transio de Estado 2 para
Estado 3 indica que, assim que a atividadeE for finalizada, a transio ocorrer
MODELAGEM DE ESTADOS 295

Figura 9-5: Exemplo de utilizao da clusula do.

(a transio automtica). Por outro lado, a transio de Estado 3 para Estado 1


pode ocorrer antes de a atividades terminar, bastando para isso que o Evento B
ocorra antes do trmino da atividade.
A Figura 9-6, adaptada da especificao da UML (OMG, 2001), ilustra um
estado no qual so declaradas as clusulas entry e exi t. A leitura desse estado in
dica que a ao defini rEcofcInvisi vel) executada sempre que o objeto (prova
velmente um objeto de fronteira) entra nesse estado. O mesmo acontece com a
ao definirEco(cVisivei) quando o objeto sai do estado.

Digitando senha

entiy/ definirEco(cInvisvel)

caractere(c)/ tratarCaractere(c)

ajuda/ exibirAjuda(invisvel)

exit/ definirEco(cVisvel)

Figura 9-6: Exemplo de estado no qual foram definidas


as clusulas entry, exit e transies internas.

A Figura 9-7 outro exemplo que ilustra o uso das aes entry e exi t. O dia
grama de estados apresentado representa os estados de uma lmpada (ligada ou
desligada) e os eventos relevantes (ligar e desligar). direita desta figura, apre
sentada a ordem de execuo das operaes quando a lmpada est ligada, e os
seguintes eventos ocorrem sucessivamente; desligar, desligar, ligar.
296 prin c pio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E E L S E V IE R

Figura 9-7: Utilizao das clusulas entry e exit.

9.1,9 Transies internas


Alm das aes predefinidas entry e exit, zero ou mais transies internas po
dem tambm ser especificadas. Uma transio interna uma transio que no
faz o objeto mudar de estado. O objetivo das transies internas fazer com que
uma ao ou atividade seja executada sem que uma mudana de estados ocorra.
A sintaxe de uma transio interna a mesma utilizada para clusulas entry,
exi t e do. Como exemplo, considere novamente a Figura 9-6. No DTE dessa fi
gura, h duas transies internas: caractere e ajuda. Quando algum dos eventos
associados a essas transies ocorre, a ao correspondente executada, mas o
objeto permanece no estado Digitando senha.
De uma forma geral, a declarao das clusulas entry, exi t e do, e das transi
es internas, pode ser em qualquer ordem dentro do retngulo do estado. No
entanto, recomenda-se utilizar a seguinte ordem de declarao: clusula entry,
clusula do, transies internas e clusula exit.
Um ponto importante a ordem na qual as aes predefinidas e as transi
es internas so executadas. Aes de sada (exi t) precedem aes externas as
sociadas a uma transio para fora do estado. Aes de entrada (entry) sucedem
aes externas associadas a uma transio para o estado. Em uma transio
reflexiva, a ordem de execuo a seguinte: ao exit, ao da transio reflexi
va, ao entry e, por fim, as demais aes ou atividades.

9.1.10 Exemplo
Como um exemplo mais completo dos elementos bsicos de um DTE aqui des
critos, considere a Eigura 9-8, um DTE para um relgio despertador, que apre-
MODELAGEM DE ESTADOS 297
ELSEVIER

senta um exemplo de utilizao da clusula do. Esse despertador funciona da se


guinte forma: quando o evento Armar alarme ocorre, o parmetro horrio do
evento informa o horrio no qual o despertador deve tocar o alarme. O desperta
dor fica esperando at que esse horrio chegue. Isso ocorre quando a expresso
de valor lgico definida no evento temporal when (horrio Definido = a g o ra ())s e
torna verdadeira."^ A ocorrncia desse evento acarreta a transio de esperando
para tocando al arme. O estado tocando al arme possui uma clusula entry, na qual
uma operao, tocarAl arme, executada. Essa operao toca o alarme por 10 se
gundos. Agora, note a transio de tocando al arme para esperando. Essa transio
no possui nem evento nem condio de guarda. De fato, essa transio auto
maticamente disparada quando a ao especificada na clusula entry finaliza
da. Isso serve para exemplificar que, de uma forma geral, uma associao que
no possui um evento associado disparada logo aps as aes internas ao esta
do tiverem sido executadas. A ao associada a essa transio executada, fa
zendo com que o novo horrio de alarme seja definido (o alarme toca durante
10 segundos a cada 5 minutos).^
Note que o estado esperando possui uma clusula entry que incrementa um
contador (n um atributo privativo da classe Despertador). Esse contador serve
para definir quantas vezes o alarme ser tocado. Neste exemplo, o alarme ser
tocado 3 vezes, se no for desarmado antes disso. A qualquer momento, pode
ocorrer um evento Desarmar alarme, que faz com que o alarme seja desarmado.

9.1.11 Estados aninhados


Podem existir estados aninhados dentro de um outro estado. Um estado que
contm diversos outros dito composto. Todos os estados dentro de um estado
composto herdam qualquer transio deste ltimo. Isso significa que o uso de
estados compostos geralmente torna um DTE mais legvel.
A Figura 9-9 apresenta um exemplo de DTE com um estado composto, a r
mado. Esse estado possui dois estados aninhados, esperando e tocando alarme.
Compare com o DTE equivalente, porm menos legvel, da Figura 9-8. Quando
ocorre a transio de desarmado para armado, o estado aninhado esperando ativa
do. A qualquer momento em que ocorrer o evento de chamada Desarmar alarme
ou o evento temporal when(n>3), no importa em que estado aninhado o objeto
esteja, o novo estado ser desarmado.

Considere que a funo agora ( ) informe o horrio corrente. Essa funo pode ser uma operao da
classe ou uma funo do sistema operacional.
^Na verdade, uma transio no precisa ter ao ou um evento associado. Nessa situao, a transio
disparada quando as aes internas ao estado terminam. Essas transies so denominadas transies
automticas. Se houver vrias transies automticas partindo de um estado, obrigatoriamente cada
uma deve ter uma condio de guarda, e as condies devem ser mutuamente exclusivas.
298 PRINCPIOS DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Armar alarme(horrio)
/horrioDefindo :=horrio,

Figura 9-8: Diagrama de estados para a classe Despertador.

9.1.12 Estados concorrentes


Um estado concorrente um tipo especial de estado composto. Um objeto em
um estado concorrente pode, na verdade, se encontrar em dois ou mais estados
independentes.
O diagrama de estados da Figura 9-10 ilustra dois conjuntos de estados in
dependentes da classe Refrigerador. Um objeto dessa classe pode estar com a
porta aberta ou fechada. Independentemente, esse objeto pode estar com o
motor ligado ou desligado. O estado composto torna mais simples a represen
tao desses dois conjuntos de estados. Sem um estado composto, haveria um
total de transies igual cardinalidade do produto cartesiano dos dois con
juntos de estados.
MODELAGEM DE ESTADOS 299

Figura 9-10: Estado composto para a classe Refrigerador.

9.2 Identificao dos elementos de um diagrama de estados


Os estados podem ser vistos como uma abstrao dos atributos e associaes de
um objeto. A seguir, temos alguns exemplos (os nomes em itlico so possveis
estados).

Um professor est licenciado quando no est ministrando curso algum


durante o semestre.
Um tanque est na reserva quando o valor do nvel de combustvel est
abaixo de 20%.
Um pedido est atendido quando todos os seus itens esto atendidos.

Um bom ponto de partida para identificar estados de um objeto analisar os


possveis valores de seus atributos e as ligaes que ele pode realizar com outros
objetos. No entanto, a existncia de atributos ou ligaes no suficiente para
justificar a criao de um DTE para uma classe. O comportamento de objetos
dessa classe deve depender de tais atributos ou ligaes.
Em relao a transies, devemos identificar os eventos que podem ge
r-las. Alm disso, deve-se examinar tambm se h algum fator que condicione
o disparo da transio. Se existir, esse fator deve ser modelado como uma condi
o de guarda da transio. J que as transies dependem de eventos para ocor
rer, devem-se identificar esses eventos primeiramente. Um bom ponto de parti
da para identificar esses eventos a descrio dos casos de uso.
Os eventos encontrados na descrio dos casos de uso so externos ao siste
ma. Contudo, uma transio pode tambm ser disparada por um evento interno
ao sistema (ver Seo 9.1.2). Para identificar os eventos internos relevantes a
um objeto, analise os diagramas de interao. Esses diagramas contm mensa
gens sendo trocadas entre objetos, e mensagens nada mais so do que solicita
es de um objeto a outro. Essas solicitaes podem ser vistas como eventos. De
uma forma geral, cada operao com visibilidade pblica de uma classe pode ser
vista como um evento em potencial.
300 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

Outra fonte para identificao de eventos relevantes analisar as regras de ne


gcio definidas para o sistema (ver Seo 4.5.1). Normalmente essas regras pos
suem informaes sobre condies limites que permitem identificar estados e
transies. Por exemplo, vamos analisar alguns exemplos de regras de negcio.

Um cliente do banco no pode retirar mais de R$1.000 por dia de sua


conta. Possivelmente, h dois estados para uma conta bancria: dispon
vel t bloqueada. Alm disso, a transio de um estado para outro depende
do atributo saldo (por exemplo) da conta bancria.
Os pedidos para um cliente no especial devem ser pagos antecipadamente.
O cliente pode estar no estado de cliente especial e cliente comum.
O nmero mximo de alunos por curso igual a 3 0 . Se houver uma classe
Curso e uma classe/li uno no diagrama de classes, essa regra de negcio in
dica que os estados (aberto ou fechado) de um objeto Curso dependem da
quantidade de ligaes desse objeto com objetos de Aluno.

9.3 Construo de diagramas de transies de estados


Para sistemas bastante simples, a definio dos estados de todos os objetos no
to trabalhosa. No entanto, a quantidade de estados possveis de todos os obje
tos de um sistema complexo grande. Isso torna a construo de um DTE para o
sistema todo uma tarefa bastante complexa.
Por exemplo, considere, sem perda de generalidade, que todos os objetos de
um sistema tm o mesmo nmero de estados: trs estados cada um. Para um sis
tema de dois objetos, a quantidade de estados possveis do sistema 9 (3 x 3).
Para um sistema de 4 objetos, a quantidade de estados possveis do sistema pas
sa para 81 (3 x 3 x 3 x 3). Ou seja, o crescimento dos estados de um sistema se d
exponencialmente com o nmero de objetos, o que torna impraticvel a cons
truo de um nico diagrama para todo o sistema.
Para resolver o problema da exploso exponencial de estados, os diagramas
de estados so desenhados por classe. Geralmente, cada classe simples o sufi
ciente para que o diagrama de estados correspondente seja compreensvel.
Note, contudo, que essa soluo de dividir a modelagem de estados por classes
do sistema tem a desvantagem de dificultar a visualizao do estado do sistema
como um todo. Essa desvantagem parcialmente compensada pela construo
de diagramas de interao (Captulo 7).
Nem todas as classes de um sistema precisam de um DTE. Um diagrama
de estados desenhado somente para classes que exibem um comportamen
to dinmico relevante. A relevncia do comportamento de uma classe de
pende muito de cada situao em particular. No entanto, objetos cujo hist
rico precisa ser rastreado pelo sistema so objetos tpicos para se construir
MODELAGEM DE ESTADOS 301

um diagrama de estados. Por exemplo, considere um objeto Pedido. Esse ob


jeto criado quando o cliente realiza um pedido. O crdito deve ser aprova
do para que o pedido seja aceito. Se o crdito negado, o pedido retornado
ao cliente para ser modificado. Se o crdito aceito, o pedido confirmado.
Aps ser atendido (ou seja, todos os itens desse pedido foram providencia
dos), esse pedido enviado ao sistema de distribuio para ser entregue. De
pois disso, por alguma razo, o pedido pode ser devolvido pelo cliente. Esse
histrico de estados de um pedido relevante para o sistema (por exemplo,
s os pedidos atendidos podem ser entregues aos clientes). Esse um caso t
pico de classe cuja definio de um diagrama de estados ajudaria a esclarecer
o seu comportamento.
Um objeto de entidade pode perdurar durante vrias execues do siste
ma. Conseqentemente, esse objeto pode participar da realizao de diversos
casos de uso do sistema. Diagramas de estados so teis para capturar o com
portamento de um objeto de entidade durante vrios casos de uso. Entretanto,
note que no apenas as classes de entidade so candidatas a precisarem de um
DTE. As classes de controle e classes da fronteira (ver Seo 5.4.2) freqente-
mente precisam de diagramas de estados para melhor esclarecer o seu com
portamento.
Uma vez selecionadas as classes para cada uma das quais se deve construir
um diagrama de estados, acompanhe esta seqncia de passos.

Identifique os estados relevantes para a classe.


Identifique os eventos relevantes aos objetos de uma classe. Para cada
evento, identifique qual transio que ele ocasiona.
Para cada estado, identifique as transies possveis quando um evento
relevante ocorre.
Para cada estado, identifique os eventos internos e as aes correspon
dentes relevantes.
5. Para cada transio, verifique se h fatores que influenciam o seu dispa
ro. Se esse for o caso, uma condio de guarda deve ser definida. Verifi
que tambm se alguma ao deve ser executada quando uma transio
disparada (aes).
6 . Para cada condio de guarda e para cada ao, identifique os atributos e
as ligaes que esto envolvidos. Pode ser que esses atributos ou ligaes
ainda no existam. Nesse caso, eles devem ser adicionados ao modelo de
classes.
Defina o estado inicial e os eventuais estados finais.
Desenhe o diagrama de estados. Procure posicionar os estados de tal for
ma que 0 ciclo de vida do obj eto possa ser visualizado de cima para baixo.
e da esquerda para a direita.
302 prin cpio s de a n a lis e e pro jeto de s is t e m a s com u m e , 2/E ELSEVIER

importante notar que a construo de diagramas de estados de um sistema


freqentemente leva descoberta de novos atributos para uma classe, principal
mente atributos que servem de abstraes para estados. Alm disso, esse proces
so de construo permite identificar novas operaes na classe, pois os objetos
precisam reagir aos eventos que eles recebem, e essas reaes so realizadas me
diante operaes.

9.4 Modelagem de estados no processo de desenvolvimento


A modelagem de estados uma atividade que deve comear na fase de anli
se, em paralelo construo nos diagramas de interao e nos diagramas de
classes, e utilizando informaes geradas nessa construo, os diagramas de
estados podem ser construdos para as classes cujos estados so considera
dos relevantes.
O diagrama de classes fornece informaes para a construo do diagrama
de estados (ver Seo 9.2), pois no primeiro que as classes com estados rele
vantes so identificadas. Por outro lado, durante a construo do diagrama de
estados para uma classe, novos atributos e novas operaes podem surgir. Essas
novas propriedades devem ser adicionadas ao modelo de classes. Dessa forma,
assim como vimos para a modelagem de interaes, a modelagem de estados
uma atividade que tem a caracterstica de retroalimentar as atividades de mode
lagem das quais obtm informaes.
Deve-se notar tambm que o comportamento de um objeto varia em funo
do estado no qual ele se encontra. Era vista disso, pode haver a necessidade de
atualizar a descrio de um ou mais mtodos da classe desse objeto para indicar
como as operaes correspondentes se comportam em funo de cada estado.
Por exemplo, o comportamento da operao sacar( ) da classe ContaBancria
(Eigura 9-1) varia em funo do estado no qual essa classe se encontra (saques
no podem ser realizados em uma conta bloqueada).
Outra caracterstica representada em um DTE e que resulta em alteraes
no modelo de classes o estado inicial do objeto. Isso porque o valor do estado
inicial normalmente identificado durante a modelagem dos estados da classe.
O mtodo de instanciao (construtor) da classe em questo deve definir o esta-

public class Lmpada


I
private String estado;
public Lmpada () { estado = desligada;)

Figu ra 9-11: O estado inicial definido na operao de instanciaao.


MODELAGEM DE ESTADOS 303
ELSEVIER

do inicial de um objeto. Normalmente, informaes para definio do estado


inicial de um objeto so passadas como argumentos para o construtor. Por
exemplo, a Figura 9-11 ilustra um fragmento de declarao da classe Lmpada em
linguagem Java. Essa classe apresenta um mtodo de instanciao que define o
valor do atributo estado, responsvel por manter a informao do estado atual
do objeto.

importante tambm notar a diferena de objetivo com o uso do diagrama


de interaes e do diagrama de transies de estados. Enquanto um diagrama de
estados representa o comportamento de um objeto, os diagramas de interao
(estudados no Captulo 7) so utilizados para capturar o comportamento de v
rios objetos em um (cenrio de) caso de uso. No entanto, para capturar o com
portamento de vrios objetos em vrios casos de uso, a melhor alternativa so os
diagramas de atividade, descritos no Captulo 10.

9.5 Estudo de caso


Esta seo continua a modelagem do Sistema de Controle Acadmico. Das clas
ses desse sistema, uma com certeza precisa de um DTE: OfertaDi sei p1 i na. Fo
ram identificados os seguintes estados para essa classe:

Aberta A oferta de disciplina est aberta para receber inscries de


alunos, at a sua quantidade mxima. O professor, as salas e
horrios foram alocados.
Lotada A oferta de disciplina alcanou a sua capacidade mxima em
relao quantidade de alunos inscritos.
Fechada A oferta de disciplina est totalmente definida (os alunos esto
inscritos).
Cancelada A oferta de disciplina cancelada. O evento de cancelamento pode
acontecer a qualquer momento do ciclo de vida de uma oferta de
disciplina.

Em relao ao estado Lotada, o leitor deve se lembrar de que h uma regra de


negcio do sistema que define a quantidade mxima de alunos. Essa regra tem
identificador RN02 e sua declarao se encontra na Seo 4.7.2.
Os eventos que so relevantes para objetos da classe OfertaDi sei pl i na so a
inscrio de um aluno, assim como as operaes que realizam abertura, cance
lamento e fechamento de uma oferta de disciplina. Alm disso, o atributo que
armazena a quantidade atual de alunos inscritos deve ser definido para monito
rar quando essa quantidade atingir o valor mximo.
O DTE para a classe OfertaDi sei pl i na est ilustrado na Eigura 9-2.
304 prin c pio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

cancelamento de inscrio
/qtdAlunos ;=qtclAlunos - 1

O coordenador pode
fechar a oferta sem
que a quantidade
mxima de insero
lenha sido atingida.

F ig u r a 9 -1 2 : DTE para a classe OfertaDisciplina.

Conforme descrito na Seo 9.4, a construo de um DTE para uma classe


pode resultar na definio de novas propriedades nessa classe. De fato, a classe
OfertaDi sei pl i na deve ser atualizada com as informaes obtidas na construo
de seu DTE. A Figura 9-13 ilustra a classe atualizada com base nas informaes
obtidas a partir de seu DTE.

OfertaDisciplina
-ano : Integer
-semestre : Integer
-qtdAlunos ; Integer
-capacidadeMaxima ; Integer
-status
+cancelar()
+fechar()
-rabrirO
-lotarO
F ig u r a 9 -1 3 : Definio atualizada da classe OfertaDi sei pl i na, aps a construo de seu DTE.
MODELAGEM DE ESTADOS 305
ELSEVIER

exerccios

9-1: Descreva a posio do diagrama de estados no processo de desenvolvimento incremental


e iterativo. Quando eles so utilizados? Para que so utilizados?

9-2: Modele atravs de um diagrama de estados a seguinte situao: em uma mquina de


encher garrafas de refrigerante passam diversas garrafas. Uma garrafa entra inicialmente
vazia no equipamento. A partir de um determinado momento, ela comea a ser preenchida
com refrigerante. Ela permanece nesse estado (sendo preenchida) at que, eventualmente,
esteja cheia de refrigerante. Nesse momento, o equipamento sela a garrafa com uma tampi
nha, e assim a garrafa passa para o estado de "lacrada". Uma garrafa vazia no deve ser la
crada pelo equipamento. Alm disso, uma garrafa cheia de refrigerante no deve receber
mais esse lquido.

9-3: Construa um diagrama de estados considerando o seguinte "ciclo de vida" de um paciente


de hospital. 0 paciente entra no hospital, vtima de um acidente de carro. Ele encaminhado
para a emergncia. Aps uma bateria de exames, esse paciente operado. Alguns dias depois,
0 paciente movido da grande emergncia do hospital para a enfermaria, pois no corre mais
perigo de vida. Depois de passar por um perodo de observao na enfermaria, o paciente rece
be alta mdica.

9-4: Construa um DTE para a classe Pedido, mencionada na Seo 9.3.

9-5: Construa um diagrama de estados para uma classe Mensagem, que representa uma men
sagem de correio eletrnico. Como dica, considere os estados apresentados a seguir.

a. Recebida: este o estado inicial. A mensagem acabou de entrar na caixa de correio e perma
nece nesse estado at ser lida.
b. Lida: a mensagem lida pelo usurio.
c. Respondida: o usurio responde mensagem.
d. Na lixeira: usurio remove a mensagem da caixa de correio.

9-6: Construa um diagrama de estados para um aparelho de secretria eletrnica. Como dica,
considere os estados apresentados a seguir. Utilize estados compostos se for necessrio.

a. Registrando recados-, algum faz uma chamada para o aparelho de telefone ao qual a secret
ria est conectada, e a chamada no atendida. A secretria, ento, apresenta a mensagem
gravada pelo usurio do aparelho e registra o recado deixado pela pessoa que fez a chamada te
lefnica.
b. Esperando-, a secretria est ociosa esperando ser ativada.
c. Revendo recados-, algum usurio da secretria requisitou que o aparelho apresentasse os re
cados gravados.
306 prin cpio s de a n a lis e e pro jeto de s is t e m a s com UML, 2/E ELSEVIER

9-7: Considere o DTE para a classe OfertaDi sei pl i na apresentado na Seo 9.5. Suponha
que as ofertas de disciplina tenham tambm um nmero mnimo de alunos para que possam ser
fechadas. Ou seja, se esse nmero mnimo for N, no pode haver ofertas de disciplina com uma
quantidade de alunos inscritos menor que N. Modifique o DTE de OfertaDi sei pl i na para con-
ternpar essa nova restrio.
10
Modelagemdeatividades
Qualquer um pode escrever cdigo que um computador pode entender.
Bons programdores escrevem cdigo que seres humanos podem entender.
- MARTIN FOWLER

diversos diagramas da UML que descrevem os aspectos dinmicos


de um sistema. Um desses diagramas, os diagramas de estados, des
crevem como um sistema responde a eventos de uma maneira que
dependente do seu estado (ver Captulo 10). Outros dois diagramas relativos a
aspectos dinmicos so os de seqncia e de comunicao (ver Captulo 7).
Outro diagrama nessa categoria o diagrama de atividade.

10.1 Diagrama de atividade


Um diagrama de atividade um tipo especial de diagrama de estados, em que
so representados os estados de uma atividade, em vez dos estados de um obje
to. Ao contrrio dos diagramas de estados, que so orientados a eventos, diagra
mas de atividade so orientados a fluxos de controle.
O leitor que trabalhe com computao h mais de uma dcada deve se
lembrar de uma ferramenta bastante utilizada no passado: ofluxogram a. Na
verdade, o diagrama de atividade pode ser visto como uma extenso dos flu-
xogramas. Alm de possuir toda a semntica existente em um fluxograma
(com notao ligeiramente diferente), o diagrama de atividade possui nota
o para representar aes concorrentes (paralelas), juntamente com a sua
sincronizao.
308 princpios oe a n a lis e e pro jeto de s i s t e m a s com u m e , 2/E ELSEVIER

Os elementos de um diagrama de atividade podem ser divididos em dois


grupos: os que so utilizados para representar fluxos de controle seqenciais e
os que so utilizados para representar fluxos de controle paralelos. Esses ele
mentos so ilustrados na Figura 10-1 e descritos nas sees a seguir.

Figura 10-1: Elementos de um diagrama de atividade.

10.1.1 Fluxo de controle sequencial


Os elementos de um diagrama de atividade usados no controle seqencial so
listados e descritos a seguir.

1. Estado ao
2. Estado atividade
3. Estados inicial e final, e condio de guarda
4. Transio de trmino
5. Pontos de ramificao e de unio

Um diagrama de atividade exibe os passos de uma computao. Cada estado


corresponde a um dos passos da computao, em que o sistema est realizando
algo. Um estado em um diagrama de atividade pode ser um estado atividade ou
um estado ao. O primeiro leva um certo tempo para ser finalizado. J o segun
do realizado instantaneamente.
Assim como no diagrama de estados, um diagrama de atividade deve ter um
estado inicial; ele pode ter tambm vrios estados finais e guardas associados a
MODELAGEM DE ATIVIDADES 309

transies. Um diagrama de atividade pode no ter estado final, o que significa


que o processo ou procedimento sendo modelado cclico.
Uma transio de tnnino liga um estado a outro. Essa transio significa o
trmino de um passo e o consequente incio do outro. Observe que, em vez de
ser disparada pela ocorrncia de um evento (como nos diagramas de estados),
essa transio disparada pelo trmino de um estado de ao.
Um ponto de ramificao possui uma nica transio de entrada e vrias
transies de sada. Para cada transio de sada, h uma condio de guarda as
sociada. Quando o fluxo de controle chega a um ponto de ramificao, uma e
somente uma das condies de guarda deve ser verdadeira. Pode haver uma
transio rotulada com a condio de guarda especial fesej, o que significa que,
se todas as demais condies de guarda avaliarem para falso, a transio associa
da a essa guarda especial disparada. Um ponto de unio (rendezvous) rene di
versas transies que, direta ou indiretamente, tm um ponto de ramificao
em comum.

10.1.2 Fluxo de controle paralelo


Um diagrama de atividade pode conter fluxos de controle paralelos. Isso signifi
ca que pode haver dois ou mais fluxos de controle sendo executados simulta
neamente em um diagrama de atividades. Para sincronizar dois ou mais fluxos
paralelos, as barras de sincronizao so utilizadas. H dois tipos de barra de sin
cronizao: barra de bifurcao (fork) e barra de juno (join).
Uma barra de bifurcao recebe uma transio de entrada e cria dois ou mais
fluxos de controle paralelos. A partir desse momento, cada um dos fluxos cria
dos executado independentemente e em paralelo com os demais.
Uma barra de juno recebe duas ou mais transies de entrada e une os flu
xos de controle em um nico fluxo. Essa barra tem o objetivo de sincronizar
fluxos de controle paralelos criados anteriormente no diagrama. As transies
de sada da barra de juno somente so disparadas quando todas as transi
es de entrada tiverem sido disparadas.

10.1.2.1 Raias de natao


Algumas vezes, as atividades de um processo podem ser distribudas por v
rios agentes que o executaro. Isso normalmente ocorre em processos de ne
gcio de uma organizao, onde uma mesma tarefa executada por diversas
pessoas ou departamentos. Nesses casos, o processo pode ser representado
em um diagrama de atividade com o uso de raias de natao (traduo para
swim lanes). As raias de natao dividem o diagrama de atividade em com par
timentos. Cada compartimento contm atividades que so realizadas por
uma agente especfico.
310 princpios de a n a l i s e e pro jeto de s i s t e m a s com u m e , 2/E ELSEVIER

A Figura 10-2 ilustra a utilizao de raias de natao. Nesse diagrama de ati


vidades, h trs compartimentos: Segurado, Seguradora e Oficina. Note que as
atividades podem passar de uma raia para outra. Alm disso, as entidades de
cada compartimento podem estar realizando atividades em paralelo.

Segurado Seguradora Oficina

^ cion ar Seguro^ Recolher Automvel >^Avaliar Danos ^

G Depositar Valor Segurado


>
[perda total]

[else]

Pagar Franquia I Cobrar Franquia j Consertar Automvel

Figura 10-2: Raias de natao.

Tanto o diagrama de interao (ver Captulo 7) quanto o diagrama de ativi


dade so usados para modelar o comportamento do sistema. O diagrama de ati
vidade tambm pode representar interaes entre objetos. Entretanto, enquan
to o diagrama de atividade mostra o fluxo de controle sem fazer referncia s
mensagens trocadas entre os objetos do sistema, o diagrama de interao exibe
esses objetos e a troca de mensagens entre eles.

10.2 Diagrama de atividade no processo


de desenvolvimento iterativo
Diagramas de atividade no so frequentemente utilizados na prtica. Quando
utilizados, os diagramas de atividade tm os usos descritos nesta seo.
Antes de passar a essa descrio, importante notar que desenvolvedores de
sistemas orientados a ohjetos devem avaliar cuidadosamente a utilidade da cons
truo de diagramas de atividade que no seja para um dos objetivos citados
nesta seo. Isso particularmente verdadeiro para a construo de diagramas
de atividade para o fluxo de controle do sistema como um todo. Lembre-se: na
orientao a objetos, o sistema dividido em objetos, e no em mdulos funcio
nais, como na Anlise Estruturada (utilizando-se o Diagrama de Fluxos de Da
dos, DFD). No que haja algo de errado em utilizar as ferramentas da Anlise
MODELAGEM DE ATIVIDADES 311

Estruturada. O fato que devemos sempre tentar utilizar as ferramentas certas


para construir os modelos certos.

10.2.1 Modelagem dos processos do negcio


o processo de modelagem tambm um processo de entendimento. Ou seja, al
gumas vezes o desenvolvedor constri modelos para entender melhor um de
terminado problema. Nesse caso, o enfoque est em entender o comportamento
do sistema no decorrer de diversos casos de uso. Ou seja, comm determinados
casos de uso do sistema se relacionam no decorrer do tempo.

10.2.2 Modelagem da lgica de um caso de uso


A realizao de um caso de uso requer que alguma computao seja realiza
da. Essa computao pode ser dividida em atividades. Alm disso, na descri
o de um caso de uso, no b uma sintaxe clara para indicar decises, itera
es e passos executados em paralelo. comum recorrer a frases do tipo O
passo P ocorre at que a condio C seja verdadeira, ou Se C ocorrer, v
para o passo P.
Nessas situaes, interessante complementar a descrio do caso de uso
com um diagrama de atividade. Os fluxos principal, alternativo e de exceo po
dem ser representados em um nico diagrama de atividade. Entretanto, note
que o diagrama de atividades deve ser utilizado para complementar a descrio
de um caso de uso, e no para substitu-la.
A descrio textual de um caso de uso fornece informaes sobre o fluxo
de eventos gerado quando de sua realizao. Portanto, para identificar ativida
des, pode-se examinar todos os fluxos (principal, alternativo e de exceo) de
cada caso de uso. Note, entretanto, que casos de uso so descritos na perspec
tiva dos atores, enquanto diagramas de atividade descrevem atividades inter
nas ao sistema.

10.2.3 Modelagem da lgica de uma operao complexa


Quando um sistema de software adequadamente decomposto em seus objetos
constituintes e as responsabilidades de cada objeto esto bem definidas, a maio
ria das operaes bastante simples. Essas operaes no necessitam de mode
lagem grfica para serem entendidas. No entanto, em alguns casos, notadamen-
te quando uma operao de uma classe de controle (ver Seo 5.4.2.3) imple
menta uma regra de negcio (ver Seo 4.5.1), pode haver a necessidade de des
crever a lgica dessa operao ou da prpria regra de negcio. Diagramas de ati
vidade tambm podem ser utilizados com esse objetivo.
Q-'SSSm& Q.QM.yMk^.'Ui- ELSEVIEEL

10.3 Estudo de caso


Esta seo ilustra a aplicao do diagrama de atividade no Sistema de Controle
Acadmico. O exemplo apresentado aplica-se descrio da lgica de funcio
namento do caso de uso Real izar Inseri o. A Figura 10-3 ilustra o diagrama
de atividades que define essa lgica de funcionamento. Note que esse diagra
ma reala as atividades do caso de uso que tm potencial para serem realizadas
em paralelo.

Figura 10-3: Diagrama de atividade para o caso de uso Realizar Inscrio.

Tambm podemos utilizar os diagramas de atividade para documentar re


gras de negcio. A Figura 10-4 ilustra esse uso. O diagrama de atividade dessa fi
gura representa a lgica de implementao da regra de negcio Pol i ti ca de Ava-
1i ao de Alunos (RN06), apresentada na Seo 4.7.2.
Outra possibilidade de uso do diagrama de atividades para a modelagem do
SCA apresentada na Figura 10.5. Nessa figura, representamos o fluxo dos pro
cessos de negcios principais do SCA (ver Seo 10.2.1).
MODELAGEM DE ATIVIDADES 313
ELSEVIER
314 princpios DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

exerccios

10-1: Descreva a posio do diagrama de atividade no processo de desenvolvimento incremen


tai e iterativo. Quando eles so utilizados? Para que so utilizados?

10-2: Construa um diagrama de atividades para o seguinte processo de negcio: a autorizao


do pagamento tem incio aps umpedido ter sido feito pelo cliente. Ao mesmo tempo, a disponi
bilidade para cada um dos itens do pedido verificada pelo depsito. Se a quantidade requisita
da de um determinado item existe em estoque, tal quantidade associada ao pedido. Caso con
trrio, somente a quantidade disponvel no momento associada ao pedido. Opedido enviado
pelo depsito ao cliente quando todos os itens estiverem associados e o pagamento estiver au
torizado. O pedido ser cancelado se a ordem de pagamento no tiver sido autorizada.
11
Arquiteturadosistema
'Nada que visto, visto de uma vez e por completo.
-EUCLIDES

m sistema orientado a objetos (SSOO) composto de objetos que in

U teragem entre si por meio do envio de mensagens com o objetivo de


executar as tarefas desse sistema. Cada um desses objetos se compor
ta de acordo com a definio de sua classe. Alm disso, um sistema tambm
pode ser visto como um conjunto de subsistemas que o compem. A definio
dos subsistemas de um SSOO feita no projeto da arquitetura ou projeto arquite
tural. Essa atividade importante porque define de que forma o sistema se divi
de em partes e quais so as interfaces entre essas partes. Alm disso, h diversas
vantagens em dividir um SSOO em subsistemas: produzir unidades menores de
desenvolvimento; maximizar o reuso no nvel de subsistemas componentes;
ajuda a gerenciar a complexidade no desenvolvimento.
Atualmente, no h uma definio universal sobre o que significa arquitetu
ra de software. De acordo com o documento de especificao da UML (OMG,
2001 ), a definio desse termo a seguinte: [] a estrutura organizacional do
software. Uma arquitetura pode ser recursivamente decomposta em partes que inte
ragem atravs de interfaces. Relacionamentos conectam as partes e restries que se
aplicam ao agrupamento das partes. O termo recursivamente nessa definio indi
ca que um sistema composto de partes, sendo que as prprias partes so tam
bm sistemas relativamente independentes que cooperam entre si para realizar
as tarefas do sistema. As decises tomadas para a definio da arquitetura de
316 princpios de a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

software influenciam diretamente na forma como um SSOO ir atender a seus


requisitos no-funcionais (ver Seo 2.1.1).
H dois aspectos relativos arquitetura que devem ser definidos no projeto
arquitetural. Em primeiro lugar, uma questo importante para os desenvolve
dores de um sistema definir como ele decomposto em diversos subsistemas e
como as suas classes so dispostas pelos diversos subsistemas. O segundo as
pecto importante na decomposio de um sistema em seus subsistemas definir
como estes ltimos devem ser dispostos fisicamente quando o sistema tiver de
ser implantado. Ou seja, se houver diversos ns de processamento para o siste
ma ser executado, importante definir em que n cada subsistema estar posi
cionado e com que outros ns ele deve se comunicar. Esse aspecto tem a ver
com a distribuio fsica das partes do sistema. Neste captulo, descrevemos os
aspectos relativos arquitetura de um sistema de software orientado a objetos.
Aqui, descrevemos conceitos como subsistemas, parties, camadas, sistemas
distribudos, concorrncia, ns de processamento e componentes.

11.1 Arquitetura lgica


chamamos de arquitetura lgica organizao das classes de um SSOO em sub
sistemas. Mas o que um subsistema? Um sistema de software orientado a obje
tos, como todo sistema, pode ser subdividido em subsistemas, que corresponde
a um aglomerado de classes. Um subsistema prov servios para outros por
meio de sua interface, que corresponde a um conjunto de servios que ele prov.
Cada subsistema prov ou utiliza servios de outros subsistemas.
Uma viso grfica dos diversos componentes de um SSOO pode ser repre
sentada por um diagrama de subsistemas. Lembremos que descrevemos os paco
tes na Seo 3.5 como um mecanismo de agrupamento geral da UML, que pode
ser utilizado para agrupar vrios artefatos de um modelo. Os pacotes podem ser
utilizados para agrupar um tipo especial de artefato, classes. Pois bem, na nota
o da UML, um subsistema representado por um pacote com o esteretipo
subsystem. Veja o exemplo da Ligura 11-1. Um diagrama de subsistemas
aquele no qual os subsistemas de um SSOO so representados com a notao
grfica de pacotes. O fato de um subsistema utilizar os servios fornecidos por
outro representado por um relacionamento de dependncia (ver Seo 8.4.1).

subsystem
Sistema de Pagamento

F ig u r a 1 1 -1 : Notao da UML para um subsistema.


ARQUITETURA DO SISTEMA 317
ELSEVIER

Durante o desenvolvimento de um SSOO, seus subsistemas devem ser iden


tificados, juntamente com as interfaces entre eles. Cada classe do sistema , en
to, alocada aos subsistemas. Uma vez feito isso, esses subsistemas podem ser
desenvolvidos quase que de forma independente uns dos outros. A seguir, so
descritas algumas dicas que podem ser utilizadas para realizar a alocao de
classes a subsistemas.

O modelo de classes de domnio (ver Captulo 5) fornece o ponto de parti


da para a definio dos subsistemas (pelo menos para os subsistemas relati
vos s classes de domnio). Isso porque podemos agrupar as classes desse
modelo de acordo com o seguinte critrio: primeiramente, identificamos as
classes mais importantes do modelo de domnio. A seguir, para cada uma
dessas classes, criamos um subsistema. Outras classes menos importantes
e relacionadas a uma classe considerada importante so posicionadas no
subsistema correspondente a esta ltima. Por exemplo, um sistema de ven
das pela WEB pode ter sido decomposto nos subsistemas: Cl i entes. Pedi dos
e Entregas pelo fato de existirem classes de mesmo nome que so conside
radas as mais importantes. A classe ItemPedi do (menos importante) prova
velmente ser alocada ao subsistema Pedidos. Por outro lado, um subsiste
ma provvel para a classe Transportadora (que representa uma empresa que
realiza entregas de pedidos) o denominado Entregas.
O princpio do acoplamento (ver Seo 7.5.2) pode ser aplicado para defi
nir os subsistemas em um SSOO. Entre subsistemas, devemos manter o
acoplamento baixo. Isso equivale a dizer que subsistemas devem ser mini
mamente acoplados. Para minimizar a dependncia (e o acoplamento), de
vemos manter em um patamar mnimo possvel a quantidade de associa
es entre classes que esto definidas em diferentes subsistemas.
O princpio de coeso tambm pode ser aplicado: dentro de cada subsiste
ma, devemos manter a coeso alta. Isso equivale a dizer que subsistemas
devem ser maximamente coesos. A dependncia entre os elementos dentro
de um subsistema deve ser mxima; ou seja, deve haver mais associaes
entre elementos dentro de um subsistema do que entre elementos perten
centes a subsistemas diferentes.
Dependncias cclicas entre subsistemas devem ser evitadas. Uma depen
dncia cclica entre subsistemas P^, P2 e P3 existe quando Pj depende de P2,
que depende de P3, que depende de P^. Dessa forma, as dependncias for
mam um ciclo: P^ >P2 P3 - Pj. O raciocnio tambm vale para mais de
trs subsistemas. Uma alternativa para eliminar ciclos quebrar um subsis
tema do ciclo em dois ou mais. Outra soluo combinar dois ou mais sub
sistemas do ciclo em um nico (por exemplo, aglutinar P3 e P^).
318 princpios DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Uma classe deve ser alocada em um nico subsistema. O subsistema que


define a classe deve mostrar todas as propriedades da mesma (nome, atri
butos e operaes etc.). Outros subsistemas que fazem referncia a essa
classe podem utilizar sua notao simplificada. Isso evita que haja defini
es inconsistentes de uma mesma classe em diferentes subsistemas.

11.1.1 Camadas de software


Dizemos que dois subsistemas interagem quando um precisa dos servios do
outro. H basicamente duas formas de interao entre subsistemas: clien
te-servidor e ponto aponto. Essas formas de interao entre subsistemas normal
mente influenciam a forma pela qual esses subsistemas so distribudos fisica
mente pelos ns de processamento (ver Seo 11.2). Examine a Figura 11-2.

Na forma de interao correspondente a uma arquitetura ponto a ponto, a


comunicao pode acontecer em duas vias. Nessa arquitetura, quando h
a necessidade de dois subsistemas A e B se comunicarem, A deve ter o co
nhecimento da interface de B, e vice-versa. Exemplos de sistema clien
te-servidor ponto a ponto so as aplicaes de compartilhamento de ar
quivos existentes no domnio da Internet.
J na arquitetura cliente-servidor, h a comunicao somente em uma via
entre dois subsistemas, do cliente para o servidor. Com efeito, necess
rio que 0 (subsistema) cliente tenha conhecimento da interface do (sub
sistema) servidor. Nesse estilo de arquitetura, chamamos de camadas os
subsistemas envolvidos. Uma camada uma coleo de unidades de soft
ware (tais como classes ou componentes) que podem ser executadas ou
acessadas. As camadas representam diferentes nveis de abstrao. Dessa
forma, um SSOO representado por uma pilha de camadas de software
que se comunicam entre si. As camadas inferiores representam servios
cada vez mais genricos (que podem ser utilizados em divesos sistemas),
enquanto camadas superiores representam servios cada vez mais espec
ficos ao sistema em questo. A diviso de um sistema de software em ca
madas permite que este seja mais portvel e modificvel. Uma mudana
em uma camada mais baixa (ou seja, mais genrica) que no afete a sua in
terface no implicar mudanas nas camadas mais altas. E vice-versa:
uma mudana em uma camada mais alta (ou seja, mais especfica) que no
implica a criao de um novo servio em uma camada mais baixa no afe
tar esta ltima. Nesta seo, enfocamos a arquitetura cliente-servidor
em camadas (em detrimento da arquitetura ponto a ponto), por conta de
ser mais utilizada.
ARQUITETURA DO SISTEMA 319

subsystem subsystem
A C

1 \/
subsystem subsystem
B D

Na arquitetura cliente-servidor, N Na arquitetura ponto a ponto, os


temos um subsistema assumindo o subsistemas assumem os papis
papel de servidor em relao ao de cliente e de servidor
outro subsistema, o cliente. simultaneamente.
Figura 11-2: Arquiteturas cliente-servidor e ponto a ponto.

Um SSOO projetado em camadas pode ter uma arquitetura aberta ou uma


arquitetura fechada. Em uma arquitetura fechada, um componente de uma ca
mada de certo nvel somente pode utilizar os servios de componentes da sua
prpria camada ou da imediatamente inferior. J na arquitetura aberta, uma ca
mada em certo nvel pode utilizar os servios de qualquer camada inferior.
Observe a Figura 11-3. Na maioria dos casos prticos, encontramos sistemas
construdos pelo uso de uma arquitetura aberta. A arquitetura aberta tambm
conhecida como relaxada ou transparente.
Bm]>DJn9}i}e}}}iaw}}zap}}kdZ3iur23iqa}ongeum33m-
nizao, uma diviso tipicamente encontrada para as camadas lgicas de um
SSOO a que separa o sistema nas seguintes camadas; apresentao, aplicao,
domnio e servios tcnicos. Da esquerda para a direita, temos camadas cada vez
mais genricas. Tambm da esquerda para a direita, tem os a ord em d e depen
dncia entre as camadas; por exemplo, a camada da apresentao depende (re
quisita servios) da camada de aplicao, mas no o contrrio.
Descrevemos essas camadas no que segue. Acompanhe pelo esquema da F i
gura 11-4. (Note que, embora a notao para pacotes e para camadas [subsiste
mas] seja a mesma, os significados desses conceitos so diferentes.)

Camada de apresentao composta de classes que constituem a funcio


nalidade para visualizao dos dados pelos usurios e interface com ou
tros sistemas. As classes de fronteira se encontram nessa camada. Exem
plos de camadas de apresentao; um sistema de menus baseados em tex-
320 princpios DE ANALISE E PROJETO DE SISTEMAS COM UML, 2/E ELSEVIER

Subsistema N Subsistema N
1 1 1

Subsistema N-1 y
1 1
I I
I I
Subsistema N-1
Ji
1
1
I I 1
I I 1
I I 1
I I 1
I I 1
I I 1
I I 1
I I 1
I I 1
1 1
Subsistema 2 1 Subsistema 2 1
1 1 1
I
] 1
V Subsistema 1 V Subsistema 1

F ig u r a 1 1 -3 : Arquiteturas abertas e fechadas.

to; uma interface grfica construda em algum ambiente de programao.


Os objetos de fronteira que interagem com usurios so alocados nesta
camada.
Camada da aplicao, a que serve de intermediria entre os vrios com
ponentes da camada de apresentao (por exemplo, telas da interface gr
fica e interfaces de voz) e os objetos do negcio (ou seja, da camada de do
mnio). Esta camada traduz as mensagens que recebem da camada da
aplicao em mensagens compreendidas pelos objetos do domnio.
tambm responsvel pelo fluxo da aplicao e controla a navegao do
usurio de uma janela a outra. A camada da aplicao nem sempre en
contrada na implementao de sistemas multicamadas. A utilizao dessa
camada normalmente necessria quando o sistema complexo, com
muitos casos de uso (dezenas ou at centenas deles). Os objetos de con
trole so alocados a essa camada. Na camada da aplicao, so realizadas
tarefas especficas da aplicao em questo. As classes dessa camada dire
cionam as classes do negcio na realizao das funcionalidades do siste
ma. As classes de controle se encontram nessa camada. A camada da apli
cao no contm regras do negcio, apenas delega tarefa para os objetos
da camada do domnio. Essa camada tambm chamada de camada de
servio.
Camada do domnio aquela onde se encontram a maioria dos objetos
na anlise de domnio (ver Seo 2.1.2). Esta camada manipula requisi
es da camada da aplicao. Os objetos nesta camada normalmente so
independentes da aplicao. Essa camada responsvel por validaes
das regras de negcio (ver Seo 4.5.1), assim como de validao de da-
ARQUITETURA DO SISTEMA 321

Figura 11-4: Camadas lgicas em uma aplicao.

dos provenientes da camada de apresentao (por intermdio da cama


da de aplicao). Exemplos de objetos encontrados nesta camada so
alunos, disciplinas, turmas, professores ou o que quer que seja apro
priado ao domnio do problema. Essa camada tambm chamada de ca
mada da lgica do negcio.
Camada de servios tcnicos o lugar onde so encontrados servios ge
nricos e teis para uma gama bastante grande de aplicaes. Exemplos
desses servios fornecidos por esta camada so segurana, registro de ope
raes do sistema, manipulao de arquivos, estruturas de dados (vetores
de caracteres, mapas, listas etc.), classes utilitrias etc. Essa camada tam
bm contm classes cujo objetivo permitir que o sistema se comunique
com outros sistemas para realizar tarefas ou adquirir informaes (por
exemplo, acesso a um SGBD ou a servios W EB). Em particular, a camada
de persistncia, da qual falamos na Seo 12.2, um servio (subcamada)
da camada de infra-estrutura. Todas as camadas superiores so depen
dentes (requisitam servios) da camada de servios tcnicos.
322 princpios oe a n a l i s e e pro jeto de s i s t e m a s com UML, 2/E ELSEVIER

Um princpio bsico que deve ser seguido na diviso descrita anteriormente


que as camadas mais altas (superiores) devem depender das camadas mais bai
xas (inferiores) e no o contrrio. Essa disposio ajuda a gerenciar a complexi
dade atravs da diviso do sistema em partes menos complexas que o todo. Tam
bm incentiva o reuso, porque as camadas inferiores so projetadas para serem
independentes das camadas superiores. Finalmente, temos ainda outra vanta
gem: o acoplamento entre camadas mantido no nvel mnimo possvel. Note,
entretanto, que h casos em que uma camada inferior precisa enviar algum sinal
para algum elemento de alguma camada superior. Isso pode ser feito pelo padro
de projeto Observer (ver Seo 8.6.2), que permite a realizao dessa tarefa sem a
necessidade de o elemento da camada inferior precisar de uma referncia direta
para o elemento da camada superior. Conforme vimos, o padro Observer
alcana esse objetivo porque faz uso do acoplamento abstrato (ver Seo 8.5.5).
Uma caracterstica importante da diviso em camadas descrita anterior
mente que cada uma delas possui um conjunto especfico de responsabilida
des. De particular importncia a separao entre a apresentao das informa
es (que feita pela camada de apresentao) e o processamento das mesmas
(que feito dentro da camada de domnio). Para esclarecer a importncia des
sa separao, considere o caso dos chamados sistemas de informaes organiza
cionais (enterprise inform^ation systems, ES), sistemas que manipulam grandes
quantidades de dados e fornecem servios de alta qualidade para integrar di
versos processos de negcio em uma grande organizao. Um EIS normal
mente possui muitos grupos de usurios, cada um deles com sua necessidade
em relao forma de interagir com o sistema. Nesses sistemas, a mesma in
formao deve ser apresentada em formatos e em diferentes perspectivas.
Alm disso, as mudanas realizadas em uma perspectiva devem ser refletidas
imediatamente em outras vistas perspectivas. Alm disso, h o requisito de
que a funcionalidade do ncleo do sistema deve ser independente das diferen
tes perspectivas fornecidas. Sendo assim, fundamental estruturar os compo
nentes dessa aplicao de tal forma que ela seja facilmente adaptvel a diferen
tes alternativas de apresentao de suas informaes e interao com seu am
biente. Nesses sistemas, fundamental que a construo de uma nova forma
de apresentao no resulte em mudanas nas camadas inferiores (na camada
de domnio por exemplo).
importante notar que uma aplicao tpica normalmente possui diversos
subsistemas (ou pacotes) internamente a cada uma das camadas descritas aci
ma. Por exemplo, em uma aplicao que fornea certo servio que acessvel
tanto por um usurio final (ser humano), quanto por outra aplicao (por meio
de um servio WEB, por exemplo), h duas camadas de aplicao, possivelmen
te tendo acesso mesma camada da aplicao. Alm disso, uma certa camada
pode ser dividida verticalmente no que costumamos chamar de parties. Com
ARQUITETURA DC S 323

exemplo de parties, considere novamente o exemplo dado anteriormente


neste captulo de um sistema de vendas pela WEB , cuja camada de domnio foi
decomposta nos subsistemas (parties): C lien tes, Pedidos e Entregas.
Outra caracterstica digna de nota acerca das camadas de apresentao e de
servios tcnicos que ambas fornecem servios de interao com o ambiente
do sistema. Por um lado, a camada da aplicao est tipicamente associada in
terao com usurios. J a camada de servios tcnicos prov servios para que a
aplicao interaja com sistemas externos (mecanismos de armazenamento, por
exemplo).
No incio deste captulo, declaramos que o projeto da arquitetura de um sis
tema influencia diretamente na qualidade do mesmo com relao ao atendi
mento de seus requisitos no funcionais (ver Seo 2.1.1). De fato, a separao de
um SSOO nas camadas descritas acima permite que o mesmo fornea de forma
satisfatria diversos de seus requisitos no funcionais. Em particular a manute-
nibilidade e a flexibilidade do sistema aumentam com a diviso em camadas.
Durante a definio da arquitetura lgica de um SSOO, o uso de padres de
projeto (consulte a Seo 6 .6) bastante comum. Por exemplo, para comunicao
entre subsistemas, normalmente o padro Faade utilizado. Para diminuir o
acoplamento entre camadas (ou entre parties dentro de uma camada), o padro
Factory Method pode ser utilizado. Alm disso, o padro Observer tambm pode
ser utilizado quando uma camada em certo nvel precisa se comunicar com uma
camada de um nvel superior. Nesse caso, o uso do padro Observer se justifica,
com o componente da camada inferior representa o sujeito (observvel), enquan
to o componente da camada superior representa o obervador. O observvel en
xerga a camada superior por uma interface genrica, e assim no precisa ter co
nhecimento da classe especfica do observador que reside na camada superior.
Finalmente, outra questo importante diz respeito distino entre as ca
madas da aplicao e do domnio. No raro, essa distino no to ntida e v
rias vezes pode surgir a dvida acerca de onde alocar certa responsabilidade.
Neste ponto, a dica prtica a seguinte: se a responsabilidade diz respeito ao do
mnio do problema, sempre mais adequado aloc-la a alguma classe da cama
da do domnio. Por outro lado, se a responsabilidade for especfica de algum
caso de uso, mais adequado aloc-la na camada da aplicao. importante no
tar tambm que nem sempre a camada de aplicao utilizada; quando o siste
ma em questo no for to complexo a camada de apresentao pode enviar re
quisies diretamente camada de domnio.

11.2 Implantao fsica


K arquitetura de implantao diz respeito disposio dos subsistemas de um
''Opelos ns de processamentos disponveis. Para sistemas simples, a arqui
324 princpios de a n a l i s e e projeto de s i s t e m a s com u m e , 2/E E LS E V IE R

tetura de implantao no tem tanta importncia. No entanto, na modelagem de


sistemas complexos, fundamental conhecer quais so os componentes fsicos
do sistema, quais so as interdependncias entre eles e de que forma as camadas
lgicas do sistema so dispostas por esses componentes. Nessa seo, discuti
mos aspectos relativos implantao fsica de um SSOO.
Outro aspecto que descrevemos nesta seo o suporte da UML para o pro
jeto da implantao fsica de um SSOO. O diagrama de implementao da UML
utilizado para representar a arquitetura fsica de um sistema. O modelo constru
do a partir desse diagrama denominado modelo de implementao. Esse modelo
tambm denominado modelo da arquitetura fsica. H dois tipos de diagramas
de implementao que so estudados aqui: o diagrama de implantao e o dia
grama de componentes.

11.2.1 Alocao de camadas


Na implantao fsica de um sistema construdo segundo a arquitetura a clien
te-servidor, comum utilizar as definies das camadas lgicas como um guia
para a alocao fsica dos subsistemas pelos ns de processamento existentes.
Sendo assim, a cada n de processamento so alocadas uma ou mais camadas
lgicas. Note que, nesta seo, o termo camada utilizado com dois sentidos
diferentes: para significar uma camada lgica (conforme a Seo 11.1.1) e para
significar uma camada fsica, esta ltima normalmente associada a um n de
processamento. Em ingls, esses significados normalmente correspondem
aos termos chamados de layers e de tiers, respectivamente (embora tambm
haja confuso de uso dos mesmos). Nesta seo, o contexto da utilizao do
termo camada deve ajudar a eliminar qualquer eventual ambigidade com re
lao ao significado.
A alocao das camadas lgicas a diferentes ns de processamento possui
diversas vantagens. Em primeiro lugar, a diviso dos objetos permite um maior
grau de manuteno e reutilizao desses objetos, porque sistemas de software
construdos em camadas podem ser mais facilmente estendidos. Por exemplo,
se surgir a necessidade de construir uma verso de sistema preexistente para
funcionar no ambiente da Internet, necessrio apenas adicionar uma nova ca
mada de apresentao. Em tese, as demais camadas no precisariam de modifi
cao, e a nova verso do sistema poderia utilizar as mesma camadas mais inter
nas que as utilizadas pela verso anterior. Os sistemas em camadas tambm so
mais adaptveis a uma quantidade maior de usurios (comparativamente ar
quitetura cliente-servidor em duas camadas). De fato, na arquitetura em cama
das, servidores novos ou mais potentes podem ser acrescentados para compen
sar um eventual crescimento no nmero de usurios do sistema. No entanto, a
diviso do sistema em camadas apresenta a desvantagem de potencialmente di-
ARQUITETURA DO SISTEMA 325

minuir o desempenho do mesmo: a cada camada, as representaes dos objetos


sofrem modificaes, e essas modificaes levam tempo para serem realizadas.
Na implantao fsica de um sistema construdo segundo a arquitetura clien
te-servidor, a camada de apresentao alocada na mquina do usurio e nor
malmente responsvel pela interface grfica com o usurio. O servidor (que
corresponde s camadas lgicas inferiores) normalmente executado em outra
mquina, que possui uma capacidade de processamento maior e pode servir a
diversos clientes. No entanto, nada impede que possa haver outras configura
es de alocao entre cliente e servidor. Com efeito, dependendo da carga de
processamento destinada a ele, um cliente pode ser magro ou gordo. Em um
cliente magro (traduo para thin client), temos apenas a camada de apresenta
o, que representa o papel de cliente na comunicao com os demais subsiste
mas. O processamento da lgica da aplicao (clculos, regras de negcio, vali
daes de campos etc.) est no servidor (demais camadas). O cliente fica com a
responsabilidade de prover a interface grfica com o usurio. O cliente gordo
tambm conhecido como cliente rico (traduo para rich client). Um cliente
gordo (traduo para/a client), por outro lado, se caracteriza por conter a inter
face grfica com o usurio e a maior parte da (ou toda) lgica da aplicao; nesse
caso, 0 servidor funciona como um repositrio de dados.
Independentemente de o cliente ser gordo ou magro, um SSOO que divide a
interao com o usurio e o acesso aos dados em dois subsistemas denomina
do sistema cliente-servidor em duas camadas. Sistemas cliente-servidor em duas
camadas foram dominantes durante aproximadamente toda a dcada de 1990.
A construo de sistemas em duas camadas vantajosa quando o nmero de
clientes no to grande (por exemplo, uma centena de clientes interagindo
com o servidor por uma rede local). No entanto, um acontecimento importante
fez com que sistemas cliente-servidor em duas camadas se tornassem obsoletos:
o surgimento da Internet. Esse acontecimento gerou uma demanda pela cons
truo de sistemas de software que pudessem ser utilizados pela Internet. Isso
causou problemas em relao estratgia cliente-servidor em duas camadas,
principalmente em relao construo de clientes gordos. Isso porque a idia
bsica da Internet permitir o acesso a variados recursos por meio de um pro
grama navegador (browser), que no fornece grande suporte construo da
quele tipo de cliente.
A soluo encontrada para o problema da arquitetura em duas camadas foi
simplesmente dividir o sistema em mais camadas de software. Sistemas cons
trudos segundo essa estratgia foram denominados sistemas cliente-servidor em
:rs camadas ou sistemas cliente-servidor em quatro camadas. Entretanto, a idia
osica original permanece: dividir o processamento do sistema em diversos ns.
Em particular, uma disposio bastante popular, principalmente em aplicaes
nara a WEB, a arquitetura cliente-servidor em trs camadas (