Você está na página 1de 288

Página em branco

© 2004 by Ernani Medeiros

Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou
transmitida de qualquer modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo
fotocópia, gravação ou qualquer outro tipo de sistema de armazenamento e transmissão de
informação, sem prévia autorização, por escrito, da Pearson Education do Brasil.

Diretor Editorial: José Martins Braga


Gerente de Produção: Heber Lisboa
Editora de texto: Renatha Prado
Capa: Marcelo Françozo
Editoração Eletrônica: ERJ Composição Editorial e Artes Gráficas Ltda.
Impressão: São Paulo – SP

Sun, Sun Microsystems, Java, HotJava, Java Development Kit, SunOS, Forte, NetBeans,
Solaris, iPlanet, StartOffice, StarPortal, Jini, Jiro são marcas registradas da Sun
Microsystems, Inc., nos Estados Unidos e outros países.
Jakarta Tomcat, Apache, são marcas da Apache Software Foundation.
PHP © by The PHP Group.
Todos os outros produtos ou serviços mencionados neste livro são marcas registradas ou
marcas comerciais notórias de suas respectivas empresas ou organizações.

Dados Internacionais de Catalogação na Publicação (CIP)


(Câmara Brasileira do Livro, SP, Brasil)

Medeiros, Ernani Sales de


Desenvolvendo software com UML 2.0 : definitivo / Ernani
Sales de Medeiros. -- São Paulo : Pearson Makron Books, 2004.

ISBN 85-346-1529-2

1. Software – Desenvolvimento 2. UML (Ciência da


computação) I. Título

04-1633 CDD-005.369

Índice para catálogo sistemático:


1. UML 2.0 : Desenvolvimento : Ciência da
computação 005.369

2006
Direitos exclusivos para a língua portuguesa cedidos à
Pearson Education do Brasil,
uma empresa do grupo Pearson Education
Av. Ermano Marchetti, 1435
CEP: 05038-001 – Lapa – São Paulo – SP
Fone (11) 3613-1222 Fax (11) 3611-0444
e-mail: vendas@pearsoned.com
Em memória de meu pai, Jose David de Medeiros:
“Ou um homem é muito lido ou muito corrido”.

Para minha mãe, Maria de Lourdes Sales de Medeiros, por seu


exemplo em estar sempre com um livro na mão.

Para Gigi Medeiros e Luís Carlos Gonçalves Junior; ela por


sempre ter um lugar no coração para... MIM!, ele por sua
paciência em brincar com seus ‘hominhos’ sem fazer muito
barulho enquanto eu escrevia! Amo vocês dois.
Página em branco
U m livro nunca é produto de uma pessoa só. Variadas situações e pessoas con-
tribuem para a conclusão de um trabalho como este. No meu caso, agradeço,
em primeiro lugar, aos meus alunos, pois foram eles que deram o pontapé inicial
para que este livro fosse escrito. Especialmente, devo agradecer aos alunos do
INPE – Instituto Nacional de Pesquisas Espaciais, que manifestaram o pedido ex-
plícito para a escrita desta obra: Ana Cláudia de Paula Silva, Anderson Moreira
Carvalho, Antônio Carlos Simões, Flávia Cristina de Andrade, Frederico Ozanam
da Costa Manso, Heliane Benedita Machado, Horácio Hiroiti Sawame, Jeferson
da Silva Cintra, José Ernesto de Araujo Filho, José Júlio Inácio, Luiz Alexandre da
Silva, Vladimir Geraseev Junior. Devo agradecimentos a todos que colaboraram
internamente na Fábrica Web e que ajudaram no projeto UML. Ao designer Rogé-
rio Freitas Vieira que sempre ajudou a melhorar o aspecto visual de tudo. À Pear-
son Education e, em especial, ao diretor editorial José M. Braga, por acreditar
neste trabalho e a editora Renatha Prado e toda a equipe pelo trabalho hercúleo de
edição e revisão!
São fúteis e cheias de erros as ciências que não nasceram da
experimentação, mãe de todo o conhecimento.
LEONARDO DA VINCI

A frase mais deliciosa que se pode ouvir na ciência, aquela que


todos os cientistas adoram, não é ‘Eureka’ mas que
engraçado!...
ISSAC ASSIMOV

Conhecimento escondido em um canto escuro de um cérebro


qualquer não é conhecimento; é orgulho.
ERNANI MEDEIROS
Prefácio XVII

Capítulo 1 Conhecimentos Iniciais 1


Por que a construção de software não apresenta a mesma constância
que outras áreas?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Primeiro estágio – Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Segundo estágio – Aprovação da concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Terceiro estágio – Detalhamento completo das necessidades do software. . . . 3
Quarto estágio – Início da construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Quinto estágio – Construção e testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Sexto estágio – Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Este formato está certo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
O que é UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
UML não é o processo de desenvolvimento? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Como nasceu o Processo Unificado? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Quais as principais características do Processo Unificado? . . . . . . . . . . . . . . . . . . 11
Quais são as fases do Processo Unificado? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Transição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
De quais workflows se compõe o Processo Unificado? . . . . . . . . . . . . . . . . . . . . . . 14
Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Fases com workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Agora temos a planta e os passos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Quais os próximos passos depois do Processo Unificado, da UML e
do PM?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Existe alguma forma de resumir o formato utilizando o processo
unificado e a UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
X Desenvolvendo Software com UML 2.0 – Definitivo

Capítulo 2 Documentos Iniciais de um Software 22


Documento Visão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Modelo de documento Visão – Resumido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Diagrama de Caso de Uso (nível 0) da Visão ou pacote de <<sistema>> . . . . . 26
Documento Nomenclatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Modelo de nomenclatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Variáveis, Objetos e Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Documento Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Modelo de glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Capítulo 3 Caso de Uso 36


O que é um Caso de Uso?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Quanto um Caso de Uso deve ser escrito? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Quem deve fazer a extração de Casos de Uso?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Como extrair um Caso de Uso?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
As mudanças no Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Afinal, quem aprova o Caso de Uso? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
O que existe, ou como será o novo sistema?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Um Caso de Uso tem somente coisas escritas?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Como acompanhamos o progresso das descrições de Casos de Uso?. . . . . . . . 46
O diagrama de Caso de Uso (nível 1) da Visão ou <<subsistemas>> . . . . . . . . . . . . . 46
Arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Iniciando a descrição de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 52


A notação do diagrama de Atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
O primeiro diagrama de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A descrição do Caso de Uso Locar DVD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
O diagrama de Atividades é imprescindível? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Cenário mal-escrito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Pensamos em interface gráfica nesse momento? . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Primeira situação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Segunda situação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Estilo do Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Requisitos x cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
As descrições de Casos de Uso, em versão final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Os diagramas de Casos de Uso revisados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A planilha de acompanhamento de descrições de Casos de Uso . . . . . . . . . . . . 72
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Capítulo 5 Teoria de Classes 74


O que é uma classe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Sumário XI

Instância de uma classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75


Objeto e classe, qual é mesmo a diferença? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Por que objetos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Como é a notação de uma classe?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
O nome da classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Os atributos de uma classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Método, função ou operação? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Responsabilidade de uma classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Generalização e especialização (GenEspec) herança . . . . . . . . . . . . . . . . . . . . . . . . 78
Herança múltipla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Visibilidade de uma classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Classe pública . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Classe privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Classe em pacote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Modificadores de uma classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Classe abstrata (abstract) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Classe final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Classe root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Classe ativa (active) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Visibilidade dos atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Atributo público (public) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Atributo privado (private) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Atributo protegido (protected). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Atributo em pacote (package) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Modificadores de Atributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Atributo estático (static) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Atributo final (final) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Atributo transiente (transient) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Atributo volátil (volatile). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Visibilidade das operações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Operação pública (public) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Operação privada (private) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Operação protegida (protected) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Operação em pacote (package). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Modificadores de Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Operação estática (static). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Operação abstrata (abstract) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Operação final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Operação root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Operação query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Concorrência. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Estruturas todo-parte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Agregação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Composição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Herança, agregação ou composição? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Relacionamento simples entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
XII Desenvolvendo Software com UML 2.0 – Definitivo

Relacionamento ternário ou superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100


Cardinalidade e navegabilidade de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Pacote de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Encapsulamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Coesão e acoplamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Coesão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Acoplamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Assinatura de um método . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Sobrecarga ou overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Redefinição ou overriding (polimorfismo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Estereótipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Classe utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Capítulo 6 O Diagrama de Classes 116


Como fazer o diagrama de classes em ambiente de time de
desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Conceito, especificação e implementação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Métodos repetidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Criando as classes, métodos e atributos para o Caso de Uso Locar DVD . . . . 119
Primeiro cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . 120
Segundo cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . 121
Terceiro cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . 122
Quarto cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . . 123
Quinto cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . . 123
Sexto cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . . . . 124
Sétimo cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . . 126
Oitavo cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . . . 127
Nono cenário principal do Caso de Uso Locar DVD . . . . . . . . . . . . . . . . . . . . . 127
Décimo cenário principal do Caso de Uso Locar DVD. . . . . . . . . . . . . . . . . . . 129
Décimo primeiro cenário principal do Caso de Uso Locar DVD. . . . . . . . . . 129
Décimo segundo cenário principal do Caso de Uso Locar DVD . . . . . . . . . 129
Décimo terceiro cenário principal do Caso de Uso Locar DVD . . . . . . . . . . 130
Cenários alternativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Requisitos especiais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Capítulo 7 Tecnologias 137


HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
JavaScript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
DHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
WML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Sumário XIII

ASP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
DLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
JAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Enterprise JavaBeans (EJB). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Instruções SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Funções ou stored procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Capítulo 8 Diagrama de Seqüência 147


A notação do diagrama de seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Construindo o diagrama de seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
O primeiro cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
O segundo cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
O terceiro cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Quarto e quinto cenários principais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
O sexto cenário principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Sétimo cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Oitavo cenário principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Nono cenário principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Décimo cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Décimo primeiro cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Décimo segundo cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Décimo terceiro cenário principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Cenários alternativos e requisitos especiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Capítulo 9 Diagrama de Estado 171


Quando usar um diagrama de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
A notação do diagrama de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A construção do diagrama de estado para a cesta de locação . . . . . . . . . . . . . . 176
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Capítulo 10 Banco de Dados 179


Quando devemos pensar no banco de dados? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Mas classes não são tabelas do banco de dados? . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Então como descobrimos as entidades no banco de dados? . . . . . . . . . . . . . . . 182
Como é um dicionário de entidades? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Como damos a unicidade aos registros de uma entidade? . . . . . . . . . . . . . . . . . 184
Como é um dicionário de dados? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Código de Locador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Relacionamentos entre entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
XIV Desenvolvendo Software com UML 2.0 – Definitivo

Chave estrangeira FK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187


Normalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Primeira forma normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Segunda forma normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Terceira forma normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Realizando os relacionamentos do MER encontrado. . . . . . . . . . . . . . . . . . . . . . . 192
Observações sobre o modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Atributo de classe e campo de tabela, como resolver? . . . . . . . . . . . . . . . . . . . . . 195
Suporte de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Capítulo 11 Diagrama de Pacotes 197


Quando iniciar a inclusão das classes em pacotes? . . . . . . . . . . . . . . . . . . . . . . . . 198
Como escolho as classes que pertencem a um pacote? . . . . . . . . . . . . . . . . . . . 198
Existe o conceito de pacotes grandes ou pequenos? . . . . . . . . . . . . . . . . . . . . . . 198
Criando o diagrama de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Capítulo 12 Diagrama de Componentes e Implantação 205


A notação do diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
A notação do diagrama de implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Quando usar o diagrama de componentes e o diagrama de implantação? . . . 207
O diagrama de componentes e implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Capítulo 13 Diagrama de Objetos 212


Notação e semântica do diagrama de objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Quando criar um diagrama de objetos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Suporte de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Um exemplo do diagrama de objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Capítulo 14 Diagrama de Comunicação - Colaboração 216


Notação e semântica do diagrama de comunicação . . . . . . . . . . . . . . . . . . . . . . . 217
Quando criar um diagrama de comunicação? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Suporte de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Um exemplo do diagrama de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Sumário XV

Capítulo 15 Timing Diagram 220


Notação e semântica do Timing Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Quando criar um Timing Diagram? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Suporte de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Capítulo 16 Diagrama de Interação – Visão Geral 223


Notação e Semântica do Diagrama de Interação – Visão Geral. . . . . . . . . . . . . 223
Quando criar um diagrama de interação – Visão Geral? . . . . . . . . . . . . . . . . . . . 224
Suporte de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Capítulo 17 Composite Structure Diagram 226


Notação e semântica do Composite Structure Diagram . . . . . . . . . . . . . . . . . . . . . 226
Quando criar um Composite Structure Diagram? . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Suporte de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Capítulo 18 Métrica de Casos de Uso 230


Existe uma sugestão de estimativas?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Por que tanta incerteza nas estimativas de software? . . . . . . . . . . . . . . . . . . . . . . 232
O que pode reduzir a incerteza no método de Karner?. . . . . . . . . . . . . . . . . . . . . 232
Como funciona o método de Pontos de Caso de Uso de Karner? . . . . . . . . . . . 233
Um exemplo de cálculo de esforço baseado em Pontos de
Caso de Uso de Karner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Passo 1 – Relacionar os atores e dar-lhes peso . . . . . . . . . . . . . . . . . . . . . . . . . 236
Passo 2 – Calcular o Total de Pesos Não Ajustados dos Atores
(TPNAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Passo 3 – Relacionar os Casos de Uso e dar-lhes peso . . . . . . . . . . . . . . . . . . 236
Passo 4 – Calcular o Total de Pesos Não Ajustados dos Casos de Uso
(TPNAUC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Passo 5 – Calcular os Pontos Totais Não Ajustados (PTNA) . . . . . . . . . . . . . . 237
Passo 6 – Criar a tabela de Fatores de Complexidade Ambiental (FCA) . . . 237
Passo 7 – Criar a tabela de Fatores de Complexidade Técnica (FCT) . . . . . 238
Passo 8 – Calcular os Pontos Totais de Caso de Uso . . . . . . . . . . . . . . . . . . . . 238
Passo 9 – Efetivar estimativas com os pontos obtidos . . . . . . . . . . . . . . . . . . 238
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Apêndice A 241

Referências 244

Respostas dos Exercícios 248

Índice 259
Página em branco
A motivação para escrever este texto foi a reiterada solicitação de meus alunos,
que pediam a criação de um texto que abordasse a UML sob a perspectiva da
construção de um software.
Alunos reclamavam que os textos sobre UML eram extensos e dispersos demais, ou
resumidos demais, deixando muitas questões por serem esclarecidas. Exemplos
eram dados utilizando-se softwares impossíveis ou vários softwares em diferentes
momentos.
Minha resposta sempre foi: “Meus queridos alunos, não é possível em um único li-
vro abordar tudo a respeito do processo de construção de software e a UML inseri-
da nele. Vocês têm cerca de dez livros a ler! Sinto muito”.
Como dou aulas e consultoria, isso me parecia preguiça da parte dos alunos, po-
rém as solicitações continuaram e percebi que tinham sentido. Isso aconteceu
quando vi dois programadores (já treinados!), cada um com um livro na mão, ten-
tando acompanhar a seqüência de suas atividades.
É claro que o trabalho de mentoring elimina muitas dúvidas aparecidas em encru-
zilhadas do desenvolvimento por exemplo: “Que artefato devo produzir agora?”
Ocorre que muitos são desenvolvedores solitários ou que trabalham em pequenos
grupos que não podem pagar um mentor e, apesar de já serem treinados, as dúvi-
das persistem.
Um ano se passou desde a primeira solicitação até a conclusão final deste trabalho.
Aviso que este texto aborda a UML 2.0 de forma prática, já testada na vida real.
Não apresenta teorias obscuras sobre aspectos que o grosso do público de análise e
de programação jamais verá.
XVIII Desenvolvendo Software com UML 2.0 – Definitivo

Todos os diagramas apresentam exemplos de um único software, um site de alu-


guel de DVDs na Web. O único momento em que não uso esse exemplo é quando
falo da teoria de classes. Isso ocorre porque não é possível que todos os conceitos
da teoria de classes sejam apresentados dentro de uma única aplicação. Esta teria
de ser enorme! Então, somente neste capítulo uso exemplos diferentes do software
adotado. Depois retomo o software de aluguel de DVDs na Web até o banco de
dados.
Outro aspecto a salientar é que este livro não tem glossário; se um conceito é ne-
cessário, forneço-o na hora em que o estamos usando. Faz parte do texto o signifi-
cado, a notação e a semântica. Além disso, procuro mostrar qual a finalidade do
conceito e, finalmente, como usá-lo.
Este trabalho é um norte para você se debruçar e descobrir o caminho a ser adota-
do na sua empresa. Procuro neste texto deixar claro tudo a que me refiro: O que é,
para que serve e como se usa.
Page-Jones1 dizia que, tempos após escrever um livro, mudou de idéia sobre várias
coisas. Isso pode acontecer comigo. Nesse caso, prometo alterar o trabalho. Con-
tudo, além dessa situação, é possível que você encontre alguma forma de colaborar
com este texto brasileiro sobre UML 2.0 e como usá-la. Sinta-se à vontade para en-
trar em contato comigo e expor suas opiniões. Farei o possível para responder a to-
dos os e-mails. Apenas tenha em mente o caráter prático deste texto. Prático, pois é
de uso comum no dia-a-dia de analistas de negócios e programadores.

O que este livro não é?


Este livro não é um tratado minucioso sobre UML 2.0. A documentação Super-
structure da OMG tem cerca de 650 páginas e não é o único documento da OMG
sobre o assunto. Este texto aborda a parte técnica, a notação e a semântica, se es-
sas são necessárias ao exemplo em foco.
Este livro não é um tratado sobre o Processo Unificado; seria, no mínimo, irres-
ponsável dizer isso. Recomendo, para um estudo aprofundado, as literaturas refe-
renciadas.2, 3, 4 Principalmente o autor Kendall Scott, que fez um ótimo resumo do
Processo Unificado.
Quando me perguntam qual processo é o melhor, respondo que uma mescla é mui-
to bem-vinda. É assim que o processo ICONIX propõe um diagrama de seqüência
para cada Caso de Uso. Acho perfeito o approach, você verá isso no capítulo que
trata de diagrama de seqüência. O processo unificado propõe um meio iterativo e
incremental. Iterativo porque passamos por iterações (1, 2, 3, 4,...) em cada fase
da estrutura. Incremental porque a última iteração deve agregar valor à iteração
anterior. Perfeito! É assim que fugimos do antigo processo ‘Queda d’água’. A
Extreme Programming – XP sugere a simplicidade, ou seja, vamos pensar na parte
crítica, mas na coisa mais simples que possa funcionar e resolver os problemas
Prefácio XIX

atuais. Certo! O RUP pensa primeiro em definir a arquitetura e depois substan-


ciá-la com modelos e solução. Ou seja, pensamos nos elementos de desempenho,
escalabilidade, reutilização e restrições econômicas e tecnológicas, iniciando-se
pela ‘Visão’ do software. Perfeito.
Poderíamos continuar com a relação, informando cada processo existente e suas
qualidades. Mas não se engane, por trás das qualidades existem... Defeitos. As re-
clamações são as mais variadas e dependem do caso. Nessas situações, usamos a
criatividade brasileira, que nos coloca entre os melhores desenvolvedores de soft-
ware do mundo. Descubra o que cada processo tem de melhor e separe o que cada
um tem de pior. Fique atento aos momentos de quando usar um e evitar o outro,
mas principalmente use sempre a UML, seja qual for o processo. Por exemplo, a
XP não recomenda o uso da UML, use-a!
Este livro não fala de padrões de desenvolvimento de software. Esse assunto pode-
rá ser abordado em futuras edições.

O que este livro tem?


Sugiro a leitura deste livro de maneira seqüencial, capítulo a capítulo, pois em to-
dos procuro colocar segredos aqui e ali; mas fique à vontade para uma leitura sal-
teada, já que o texto também pode ser usado como referência.
Vamos dar um passeio pelos capítulos dele:

» Capítulo 1 Conhecimentos Iniciais. Informa, de forma abreviada, sobre a his-


tória da UML e suas correlações com o Processo Unificado. A palavra informa
aqui é precisa: a preocupação não é formação mas informação sobre esses temas,
a fim de levar o aluno a esclarecimentos sobre o que esses termos significam.
Também são relacionados todos os diagramas da UML 2.0 e a ordenação em que
serão abordados neste texto.
» Capítulo 2 Documentos Iniciais de um Software. Aborda os documentos ini-
ciais de software e suas correlações com a UML. Principalmente, a criação do
documento Visão e seu uso.
» Capítulo 3 Caso de Uso. Aborda os princípios dos Casos de Uso e dá significa-
ção para o documento Visão nos primeiros diagramas.
» Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso. Aborda o
possível uso do Diagrama de Atividades para a descrição dos Casos de Uso; adicio-
nalmente, as últimas modificações introduzidas nesse diagrama pela UML 2.0.
» Capítulo 5 Teoria de Classes. Preferi chamar de teoria de classes à teoria de
orientação a objetos, pois abordo seu uso, notação, semântica, jargão, visibilidade
e modificadores com exemplos em Java, visando o diagrama de classes.
» Capítulo 6 Diagrama de Classes. Aborda a construção do diagrama de clas-
ses, como criá-lo à luz dos Casos de Uso, armadilhas e soluções.
XX Desenvolvendo Software com UML 2.0 – Definitivo

» Capítulo 7 Tecnologias. Apresenta uma visão geral das tecnologias atuais,


para que os analistas de negócios UML possam conhecer a capacidade das tec-
nologias disponíveis, mesmo que não saibam programar para todas elas. Saber
o uso horizontalmente é mais importante para um analista de negócios do que
saber verticalmente sobre determinado assunto. Ao participar de reuniões e
conversas sobre importantes decisões de software o analista deve estar prepara-
do para esses aspectos.
» Capítulo 8 Diagrama de Seqüência. Aborda o diagrama de seqüência, seu início
e o porquê de usá-lo à luz dos cenários de um Caso de Uso; adicionalmente as últi-
mas modificações introduzidas neste diagrama pela UML 2.0.
» Capítulo 9 Diagrama de Estado. Aborda sua importância, uso e construção.
» Capítulo 10 Banco de Dados. Esse capítulo aborda o Modelo de Entidade e
Relacionamentos, informando sobre entidades, dados, informação, construção
do modelo MER, classes versus tabelas no banco de dados, e situa o MER no
contexto dos diagramas da UML.
» Capítulo 11 Diagrama de Pacotes. Aborda o diagrama de pacotes, que pode
ser usado estereotipado com Casos de Uso, e sem estereótipos, com classes.
» Capítulo 12 Diagrama de Componentes e Implantação. Aborda uso, notação
e semântica, e principalmente o momento de seu uso.
» Capítulo 13 Diagrama de Objetos. Aborda notação, semântica e uso.
» Capítulo 14 Diagrama de Comunicação – Colaboração. Antigo diagrama de
Colaboração. Aborda uso, notação e semântica.
» Capítulo 15 Timing Diagram. Apresenta possíveis usos, semântica e notação.
» Capítulo 16 Diagrama de Interação – Visão Geral. Aborda usos, notação, semân-
tica e quais diagramas podem fazer parte deste novo diagrama da UML 2.0.
» Capítulo 17 Composite Structure Diagram. Novo na UML 2.0, aborda possíveis
usos, notação e semântica.
» Capítulo 18 Métrica de Casos de Uso. Aborda o uso de métrica de estimativa
de esforço na construção de software usando Pontos de Casos de Uso.
» Apêndice A Relata alguns dos estereótipos-padrão, predefinidos na UML 2.0,
e aqueles que deixaram de ser suportados.
Finalmente, existe uma seção onde você encontra as respostas para todos os exercí-
cios dos capítulos. E mais: No site Web
http://wpslive.pearsoncmg.com/br_medeiros_uml_1
os professores encontrarão mais de cem exercícios destinados ao uso em sala de
aula; todos com respostas comentadas pelo autor.
Alguns poderão perguntar por que utilizei Java, quando precisei dar exemplos de
código. A resposta é que este livro não é de programação, porém, pode ser necessá-
rio a alguém, com boa visão de programação, saber como a notação da orientação
a objetos se traduz para código. Havendo essa necessidade você pode observar os
Prefácio XXI

exemplos dados. Os exemplos estão em Java porque é a linguagem que conheço.


Vamos imaginar um site de locação de DVDs pela Internet.
Nosso curso não exige ferramentas, porque existem mais de 300 ferramentas vi-
suais para se modelar UML e precisaríamos ensinar o uso de uma ferramenta junto
com os conceitos de UML, o que inviabilizaria este texto. Você pode estar em uma
empresa que exige skill (habilidade) em uma ferramenta ou outra, como saber? As-
sim, focamos nos conceitos da UML e não na ferramenta.
Ajuda muito saber que as ferramentas têm um aspecto visual muito semelhante,
que um diagrama de classes, ou de Casos de Uso, é muito semelhante ao apresenta-
do em outra.
Para saber o que uma ferramenta de modelagem UML deve ter, antes de escolher,
vá até http://www.objectsbydesign.com/tools/modeling_tools.html.
No link http://www.objectsbydesign.com/tools/umltools_byCompany.html, você vai en-
contrar uma lista com muitas ferramentas de UML, com a descrição dos fabrican-
tes, nome do produto, versão, data do último release, plataforma e preço.
Existem ferramentas gratuitas, pagas com preços razoáveis e com preços altos, as
diferenças também ocorrem de acordo com o que a ferramenta oferece, além de
permitir a geração de gráficos e códigos, porque todas essas características as boas
ferramentas têm.
Ao escolher uma ferramenta, procure uma que atenda a usuários de vários siste-
mas operacionais, garanto que isso evitará uma série de problemas.

Ernani Medeiros
www.fabricaweb.com.br
esales@fabricaweb.com.br
Página em branco
Tentar e falhar é, pelo menos, aprender. Não chegar a tentar é
sofrer a inestimável perda do que poderia ter sido.
GERALDO EUSTÁQUIO

Feliz aquele que transfere o que sabe e aprende o que ensina.


CORA CORALINA

Q uando falamos em processo, no contexto da Engenharia de Software, esta-


mos nos referindo ao processo de desenvolvimento de software. Isso é con-
cernente às etapas necessárias à conclusão ou construção de um software,
desde seu início, passando pelas etapas de homologação e chegando até ao treina-
mento do usuário final na nova ferramenta.
Acredite-me, existem vários processos que se propõem serem adequados à constru-
ção de software. Essa tarefa já foi pensada muitas vezes. Mesmo antes de termos a
ajuda da UML, tínhamos um processo, não formal, de construção de software, que
se resumia ao levantamento de requisitos (necessidades), à definição de um Modelo
de Entidade e Relacionamento (MER) e, finalmente, iniciava-se a codificação.
Todos os modelos de construção de software que apareceram foram ruindo no re-
sultado final e, ainda hoje, mesmo os mais decantados processos, apresentam fa-
lhas, ainda não superadas.
Um amigo, que viu o conceito de Gerenciamento de Projetos sendo utilizado para
a construção de uma usina hidrelétrica, achou que esse conceito poderia se aplicar
de forma integral na construção de software. Teve diversas decepções.
2 Desenvolvendo Software com UML 2.0 – Definitivo

A construção de uma casa pode oferecer melhores resultados que a construção de


software. Você pode me criticar veementemente nessas observações, porém foi mi-
nha experiência quem ditou essa frase. Somos capazes de apontar os motivos, mas
não somos tão felizes em apontar as soluções para esta problemática. A fórmula
secreta da boa construção de software ainda não foi desenvolvida, e isso ocorre em
detrimento de toda a tecnologia existente.

Por que a construção de software não apresenta a mesma


constância que outras áreas?
A Engenharia Civil é apresentada aqui apenas como exemplo. Existem outras áreas
de desenvolvimento e construção que podem servir de bons exemplos. O Grupo
Hyundai, na Coréia, consegue recordes nos prazos de entrega de grandes navios,
não importando onde a encomenda tenha sido feita ou qual o seu tamanho.
Assim, onde estão os problemas? Creio que posso resumir os grandes equívocos
em algumas partes.
O primeiro equívoco ocorre no formato da construção. Quando você pensa em
construir uma casa, um prédio, um navio, enfim qualquer obra de Engenharia Ci-
vil, Naval ou Eletrônica inicia-se com uma planta. Engenheiros, arquitetos e, even-
tualmente, mestres de obras colocam à sua disposição anos de trabalho e
conseqüente experiência. Nada se inicia, em termos de construção, antes que a
concepção do projeto esteja terminada.
No exemplo específico da construção civil, tudo é pensado, antes mesmo de um ti-
jolo ser assentado, partindo-se do pressuposto de que o terreno é conhecido e a
área a ser construída obedecerá às regras de zoneamento da prefeitura local. Mes-
mo o recuo que a construção deve ter, em relação à área construída, é medido,
pensado, checado, corrigido, até que se tenham números extremamente precisos.
Por anos, tentamos construir software tendo como termo de comparação a cons-
trução civil. O problema é que os requisitos de um software sofrem mudanças.
Elas ocorrem porque o interessado no software passa pelas mudanças mostradas a
seguir, não importando o tamanho do software.

Primeiro estágio – Concepção


A idéia inicial existe em um formato nebuloso dentro da mente do interessado na
construção do software. O que ele tem como certo é a sua necessidade, porém a
forma de resolver ou atender a essa necessidade não tem um formato definido em
sua mente. Isso ocorre por diversas razões, mas com freqüência pela falta de co-
nhecimento tecnológico ou mesmo aversão inicial à tecnologia.
Na construção civil, se o engenheiro civil informar que o que pode ser construído
no terreno é um sobrado de dois andares, com a metragem de área útil de x metros
quadrados e x metros de recuo, dificilmente se discutirá sua sentença. O interessa-
Capítulo 1 Conhecimentos Iniciais 3

do passa a formar uma imagem mental daquilo que foi informado pelo engenheiro
civil. Isso facilita muito o trabalho inicial de concepção do projeto.

Segundo estágio – Aprovação da concepção


O estágio seguinte é a aprovação de uma idéia abstrata por parte do interessado. A ele
são entregues calhamaços de papel e diversos diagramas que, para compreensão, re-
querem conhecimento de nível superior seguido de alguns cursos de especialização e
algumas pós-graduações. Mesmo quando o público que deve aprovar tal concepção é
da área de TI, carece de conhecimentos em subáreas que os softwares atuais abarcam.
A visão que o interessado tem é de alto nível, porém nada palpável existe para a to-
mada segura de decisão nesse estágio. Além disso e com as observações do pessoal
de construção do projeto, a idéia inicial do interessado ‘muda’ em relação ao pri-
meiro estágio. Isso é inevitável, pois a idéia nebulosa do primeiro estágio foi, ago-
ra, melhorada, com a ajuda de outras pessoas.
Na construção civil, quando a planta é mostrada ao interessado, este fala mais à
vontade de sua aprovação ou recusa, pelo fato de tratar de assuntos mais concre-
tos. Ele sabe o que é uma parede e um dormitório, então consegue abstrair, com
maior fluidez, o resultado final.
Muitos resultados indesejáveis, no futuro, são resolvidos nesse estágio, porque foi pe-
dida, por exemplo, a conversão de dois dormitórios em apenas um; e tudo isso foi fa-
cilitado pela visão que o interessado teve a partir da planta fornecida pelo engenheiro.

Terceiro estágio – Detalhamento completo das necessidades


do software
Nesse estágio, o detalhamento completo do software desejado é escrito e nova-
mente buscamos a aprovação do interessado. Nada é construído, apenas as fun-
cionalidades desejadas são escritas.
Novamente, a idéia inicial do interessado se altera. Isto ocorre pelo fato de que seu
nível de abstração melhorou. Sua idéia sofreu um amadurecimento. Normalmente,
a própria equipe dedicada à construção descobre inconsistências que são significati-
vas e passam uma segurança que não havia sido encontrada até esse momento.
Na construção civil, como o nível de abstração do segundo estágio foi baseado em
um fundamento bem concreto e plausível, esse estágio quase não sofre alterações
significativas.

Quarto estágio – Início da construção


O início da construção do software se dá com base na aprovação das idéias surgi-
das no segundo e terceiro estágios pelo interessado. Essa construção tem seu início
no modelo de Entidades e Relacionamentos, para se planejar onde os dados reque-
ridos serão guardados. Nós carregamos esse ERRO de estratégia durante anos.
4 Desenvolvendo Software com UML 2.0 – Definitivo

Assim, a interface gráfica é apresentada. Nesse momento, a idéia do interessado,


sobre a forma como a sua necessidade será atendida, sofre mudança. Isso ocorre,
porque seu nível de abstração melhorou. Agora ele vê ‘algo’ mais concreto. Vê
como foi concebida sua intenção inicial.
Na construção civil, a idéia inicial do interessado foi concebida e ‘visualizada’ na
planta em que a construção se baseia; ele somente fará uma observação se a cons-
trução, absurdamente, não obedecer à planta aprovada. Paredes levantadas, dese-
jo alcançado. O máximo de decepção que pode ocorrer é caso um arquiteto tenha
dado aos móveis uma dimensão errada, em uma escala desproporcional que a me-
tragem real não suporta. Por exemplo, o interessado achava que uma cama de ca-
sal caberia em um determinado dormitório, conforme acompanhou no desenho do
arquiteto, porém a metragem real permite apenas uma cama de solteiro.
Mesmo com essa decepção, alterações normalmente não são feitas, porque a me-
tragem da planta (já aprovada na prefeitura municipal) foi obedecida. Além disso,
as dimensões e disposições de móveis em uma planta são normalmente ilustrati-
vas. Já a metragem real original, do início da construção, é a mesma que foi entre-
gue ao final da construção.

Quinto estágio – Construção e testes


O interessado, nesse momento, fica afastado do contato com o software de seu in-
teresse. A premissa é de que tudo o que se necessitava foi conversado e ‘assinado’.
Isso não invalida a visita periódica, do interessado, para avaliar o andamento x
cronograma.
O banco de dados escolhido passa por testes de aderência com as interfaces gráfi-
cas construídas, e muitos códigos de linguagem e funções do banco de dados são
escritos. A idéia aqui é a de que o interessado já informou sobre seu negócio, expôs
suas expectativas e validou as interfaces gráficas, chamadas de protótipos de tela.
No caso da demissão de um programador, Web designer, ou administrador de da-
dos, os problemas começam a aparecer. Isso ocorre devido ao fato de haver muito
personalismo durante a confecção de código. Também perdemos muito tempo,
aguardando o novo profissional a se habituar com os termos específicos do novo
software, entender o ‘negócio’ do cliente e, principalmente, entender o que seu co-
lega precedente estava fazendo, no emaranhado de ‘zilhões’ de linhas de código.
Programadores, com o mesmo nível de experiência, têm visões totalmente diferen-
tes sobre como se deve fazer um código.
Na construção civil, a visita do interessado para avaliar o andamento x do cronogra-
ma é feita com regularidade. No caso da demissão de um empregado busca-se outro
que tenha a mesma experiência. Supondo-se a demissão de um pedreiro, outro é ad-
mitido, passando por um teste rápido de preparo de massa e assentamento de tijolos.
Estando apto, inicia o trabalho deixado pelo outro. Por vezes, não é necessário, por
parte de um trabalhador desse tipo, entender o que seu predecessor estava fazendo.
Capítulo 1 Conhecimentos Iniciais 5

Sexto estágio – Entrega


A entrega de um software ao seu interessado ocorre com raros estouros de cham-
panha. Devido aos problemas de adaptação de pessoal, tecnologia e política, as
datas de entregas foram negociadas com várias protelações ao longo do tempo.
Não raro, quando o software é entregue em uma cerimônia com o principal inves-
tidor presente, ouve-se a homérica frase: “Mas não é nada disso que eu queria!” ou
“Olha, está bom, mas eu gostaria de fazer algumas mudanças na forma como isso
foi pensado”.
Na construção civil, quando uma edificação é terminada, ninguém ouve coisa se-
melhante às frases do parágrafo anterior. Isso indicaria uma completa incompe-
tência por parte do engenheiro responsável.
Se a planta foi obedecida e existe a intenção de se fazer alterações, é necessário que
essa alteração esteja presente na planta, e que esta tenha novas aprovações na pre-
feitura. Novos prazo e preço devem ser negociados para que algumas paredes, se-
não estruturas inteiras, sejam postas a baixo.

Este formato está certo?


Francamente, se uma forma de construção de software for a certa, ela ganhará ra-
pidamente a primeira página de diversos jornais. A forma de construção de soft-
ware depende:
» do conhecimento do negócio a ser modelado;
» do conhecimento da tecnologia que será utilizada, por parte de quem fará a
construção;
» da capacidade de abstração do principal interessado no software;
» da capacidade de abstração de quem construirá o software; e
» do volume de dinheiro dedicado à aquisição de softwares de autoria, banco de
dados, ferramentas de desenvolvimento, hardware e terceiros, como provedores
de acesso e data centers.
Alterando-se apenas uma dessas variáveis, obtém-se um ganho enorme em termos
de produtividade.
Entretanto, nem tudo é desespero. Consideremos os pontos que nos trazem algum
ganho de conhecimento em relação aos itens citados, que comparam a construção
civil à construção de software.
Primeiramente podemos, tranqüilamente, pedir que o mundo pare de comparar a
construção de software com as construções civis, navais, automobilísticas ou aero-
náuticas! Isso não tem cabimento, visto que qualquer ramo de engenharia citado,
que não a construção de software, segue com rigor um plano compreensível de for-
ma universal por quem quer que venha a trabalhar em qualquer desses ramos.
Além disso, durante seus anos de graduação, os alunos vêem e criam esses planos
6 Desenvolvendo Software com UML 2.0 – Definitivo

de forma extensiva. A esses planos damos o nome de planta. Um desenho que con-
tém todas as especificações necessárias e destinadas a quem os entende, seu uso é
um padrão e senso comum.
Da mesma forma, os músicos têm seu padrão nas notações de pentagramas e cifra-
gens. Por exemplo, a nota ‘dó’ estará sempre no terceiro espaço de um pentagrama
que usa a clave de sol e, adicionalmente, qualquer músico sabe quais oitavas a cla-
ve de sol ocupa em relação à clave de fá.
É dessa forma que, quando se escreve uma partitura (a planta da música para uma
orquestra), não se diz ao músico que: “Apesar de usarmos a clave de sol, apenas
nesta partitura a nota (dó) ocupará o quarto espaço do pentagrama, no lugar da
nota (mi)”. Isso não existe! Portanto, até na música temos um padrão, um senso
comum, e isso é assim há séculos!
Em todas essas atividades, temos algo que a Tecnologia da Informação (TI) não
tem. Os trabalhos de engenharias civil, naval, elétrica e mesmo a música existem
há séculos, enquanto a Tecnologia da Informação e, em particular, a engenharia
de software existem há poucas dezenas de anos.
Não existe milagre na padronização de algo.
O primeiro vôo documentado e sem impulsão externa foi realizado por Santos Du-
mont no Campo de Bagatelle, em Paris, no dia 23 de outubro de 1906. Wilbur e
Orville Wright realizaram o feito, mas sem o documentarem e com o auxílio de
uma catapulta, três anos antes. Apesar de terem se passado cem anos, aeronaves
ainda têm seus projetos sendo aprimorados pelas escolas de aviação mais moder-
nas no mundo atual. O padrão e o senso comum em termos de aviação vai-se con-
solidando aos poucos no mundo.
Semelhantemente, a ciência naval tem séculos de tentativas, erros, acertos, e hoje
se constroem verdadeiras cidades flutuantes. Existe um padrão e um senso comum
de como se fazer um barco!
Um padrão de como se construir um software não existe, simplesmente porque os
profissionais da área não querem. Este padrão não existe porque ainda estamos
buscando-o.
Outro ponto interessante é que software versa sobre coisas intangíveis, por vezes,
inimagináveis. O mesmo não ocorre com as outras ciências citadas. Esse fato
alia-se ao desconhecimento, dos requerentes de um software, sobre as tecnologias
à sua disposição. Assim, conforme o software vai se concretizando, a idéia do inte-
ressado se aprimora, ou seja, muda.
Já vi analistas de negócios e programadores (assim como eu), reclamarem de alte-
rações que surgem ao longo da construção de software. Bem, essas mudanças de-
vem ocorrer! Sim, elas são bem-vindas!
Capítulo 1 Conhecimentos Iniciais 7

A partir do momento em que entendemos a novidade que a Tecnologia da Infor-


mação ainda é, devemos ajudar nossos interessados a construir um software ama-
durecendo-o paulatinamente.
Outro ponto a se considerar é o fato de que um software não é algo estanque como
uma construção sólida. Não se retira o andar inferior de uma casa para que seja
construída uma piscina no lugar, mantendo-se o andar de cima, com a mesma planta.
No entanto, em software, isso é possível! É evidente que com uma revisão de preço
e prazo, para uma melhoria ao que existe; mas é perfeitamente possível nos depa-
rarmos com um software que foi concebido para o banco de dados PostgreSQL e
que deva ser portado, também, para o MySQL. Um software que foi pensado para
a via cliente-servidor e que deve ser portado para a Internet ou Intranet. Se já foi
portado para um navegador, pode ser necessário portá-lo para dispositivos sem
fio... As mudanças em software são incessantes, porque a mudança evolucionária
da tecnologia da informação é incessante.
Outro fator de importância a ser notado é que, se o interessado possui o que deseja
automatizar em pleno vigor, incorporado ao seu processo, ele terá grande facilida-
de em expressar seus desejos. Mesmo aí, as alterações ocorrerão. É freqüente, dentro
de um processo, observarmos que uma determinada ação está repetida ou com mal-
funcionamento em uma de suas partes.
Não cabe a automatização de um erro! Olhando aquele processo sob nova pers-
pectiva, nesse caso automatizada, os interessados ou os construtores do software
podem detectar erros não vistos anteriormente e o processo ser alterado. Conse-
qüentemente, o software será alterado também.
Devemos levar em consideração, também, o fato de uma grande porcentagem de
nossos analistas serem oriundos da análise estruturada e pensarem em uma solu-
ção automatizada para um negócio a partir de um DFD (Diagrama de Fluxo de
Dados). Um DFD leva, necessariamente, à criação de um MER (Modelo de Enti-
dade e Relacionamento), o qual veremos no Capítulo 10.
Esse approach não está errado, mas não se mostrou eficiente, na medida em que
entidades de um modelo de dados ‘sobravam’ ou ‘faltavam’ durante e após a entre-
ga do software pedido.
Contudo, precisamos responder a pergunta do tópico: “Este formato de desenvolvi-
mento de software está certo?” Levando-se em consideração tudo o que foi dito, pa-
rece-nos que ‘o quê’ deve ser feito está perfeito; vejamos: Requerimentos, Análise e
Design, Implementação, Testes e Implantação. Então, o que não está certo, diante
da novidade da Tecnologia da Informação? O que não está certo é ‘o como’ está sen-
do feito. Esse formato de desenvolvimento ficou conhecido como Queda d’água.
8 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 1.1 Desenvolvimento em Queda d’água. (Fonte: www.fabricaweb.com.br.)

Esse formato de desenvolvimento oferece os seguintes problemas:


» pressão do risco no tempo;
» custa muito consertar erros, descobertos em tempo, de código e teste;
» aumenta o risco de cancelamento do projeto; e
» este approach tende a mascarar os riscos.
Tom Gilb (Gilb, 1988, p. 73)1 diz: “Se você não atacar os riscos em seu projeto,
eles vão atacar você”.
O risco é uma constante que não é problema nas primeiras iterações pelas quais
passa o software, porém, quando este se aproxima da entrega final, o risco é o fa-
tor de maior perturbação.
Esses riscos foram, também, mencionados por Martin Fowler2, e neles se encaixam
os riscos de requisitos, tecnológicos, de habilidades e políticos. Em qualquer mo-
mento, um desses riscos pode dar início ao risco maior de nosso interessado abortar
o projeto! Percebemos, portanto, que risco não é algo que devamos ignorar!
Não é desnecessário repetir: O que não está certo neste modelo não é o que se deve
fazer, mas a seqüência a ser executada.
Como esse modelo foi muito utilizado em processos da Análise Estruturada, a
orientação a objetos procurou o seu caminho.
Ainda hoje, é possível encontrarmos literatura a respeito de orientação a objetos,
oriunda de trabalho árduo durante anos. Podemos citar os seguintes autores: Alan
Kay, Adele Goldberg, O. J. Dahl e K. Nygaard, Edsger Dijkstra, Ward Cunning-
han, Barbara Liskov, David Parnas, Jean Ichbiach, Bjarne Stroustrup, Richard e
Whitby-Streves, Sally Shlaer/Steve Mellor, Jim Odell e James Martin, Bertrand
Meyer, Peter Coad, Ed Yordon, Meilir Page-Jones.
Capítulo 1 Conhecimentos Iniciais 9

Cada um desses autores deu sua contribuição à orientação a objetos, o que foi
muito positivo para a produção do conhecimento sobre esse assunto nos dias de
hoje. Contudo, os métodos existentes nas décadas de 70 e 80 eram em torno de dez
e, entre 1989 e 1994, chegaram na casa dos 50.
Esse quadro complicou bastante a manutenção da orientação a objetos, porque
ocorria com freqüência, por exemplo, a necessidade de se conhecer variadas for-
mas de construção de um diagrama de classes, o que era impossível.
Estávamos em busca de um padrão de construção de software Orientado a Obje-
tos e sua representação, à semelhança da planta utilizada por outras ciências que
não a Engenharia de Software.
Ivar Jacobson, Grady Booch e Jim Rumbaugh realizaram o feito de unificarem es-
sas idéias em uma única ferramenta, a qual deram o nome inicial de Método Unifi-
cado e o número de 0.8 a essa primeira versão. A partir de 1995 incluíram os
métodos OOSE e Objectory e, em 1996, deram o nome de UML com a versão 0.9.
UML é o acrônimo de Unified Modeling Language. É uma ferramenta que nos au-
xilia na modelagem de sistemas, dos mais simples aos mais complexos. Em 1999,
já na versão 1.3, a UML passou a ser mantida pelo OMG (Object Management
Group). Podemos encontrar maiores informações em www.omg.org e em seu site
www.uml.org. Hoje, qualquer pessoa pode submeter um comentário ou acréscimo ao
que já existe na especificação da UML, bastando ser membro da OMG e escrever o
seu comentário.
Na UML, foram agregados os conhecimentos dos seus três autores. Ivar Jacobson,
entre 1994 e 1995, na empresa Objectory AB pôde dar seqüência à sua metodolo-
gia, que valorizava a fase de descrição de requisitos conhecida como Caso de Uso, e
seu método ficou conhecido como OOSE (Object-Oriented Software Engineering).
Grady Booch, entre 1994 e 1995, dedicava-se à linguagem ADA na Rational Soft-
ware. Tinha um método Booch’93 que se prestava à fase de projeto.
Jim Rumbaugh, entre 1991 e 1996, dedicava-se aos Lab. GE, tinha seu método
que ficou conhecido como OMT (Object Modeling Technique). Destacava-se na
fase de análise.
A especificação da UML pode ser encontrada para download em http://www.omg.org/
tecnology/documents/formal/uml, onde é possível encontrar a última versão desse do-
cumento em PDF, ZIP ou PostScript.
A finalidade da UML é proporcionar um padrão para a preparação de planos de
arquitetura de projetos de sistemas, incluindo aspectos conceituais, como proces-
sos de negócios e funções de sistema, além de itens concretos, como as classes escri-
tas em determinada linguagem de programação, esquemas de bancos de dados e
componentes de software reutilizáveis (Booch, Rumbaugh e Jacobson).
A UML 2.0 é composta de 13 diagramas e, ainda a descrição dos Casos de Uso.
10 Desenvolvendo Software com UML 2.0 – Definitivo

Esses diagramas são:


Diagramas
UML 1.X UML 2.0
Atividades Atividades
Caso de Uso Caso de Uso
Classe Classe
Objetos Objetos
Seqüência Seqüência
Colaboração Comunicação
Estado Estado
-------------------------------------- Pacotes
Componentes Componentes
Implantação Implantação
-------------------------------------- Interação – Visão Geral
-------------------------------------- Timing
-------------------------------------- Composite Structure Diagram

Vamos ver todos neste livro. Faremos exercícios dos seguintes diagramas: Ativida-
de, Caso de Uso, Classe, Seqüência, Estados e Pacotes. Isso porque, como foi dito
(e bem dito) por Ivar Jacobson, 20% da UML resolve cerca de 80% dos problemas
do dia-a-dia.
Veremos também, como pensar um MER (Modelo de Entidade e Relacionamento)
dentro da UML, como podemos construir modelos de software orientados a obje-
tos e pensar bancos de dados relacionais.

O que é UML?
Percebemos, logo à primeira vista, que a UML não nos indica como devemos fazer
um software. Ela indica apenas as formas que podem ser utilizadas para represen-
tar um software em diversos estágios de desenvolvimento.
Utilizando a UML, conseguimos ‘pensar’ um software em um local e codificá-lo
em outro. É evidente que alguma outra comunicação adicional se fará necessária,
porém deve ser minimalista. Se muitas perguntas estão surgindo em função de de-
terminado diagrama, isso é um sério sinal de que esse diagrama deve ser revisado.
Assim, apesar da definição dos ‘três amigos’, podemos dizer que a UML é uma for-
ma de comunicar uma idéia. Como disse anteriormente, estamos em busca de um
padrão para nossa ciência, portanto, o ‘L’ de language refere-se a uma linguagem
de comunicação entre duas partes e não a uma linguagem de computador. Um dia-
grama UML deve dizer – comunicar alguma coisa, senão, não deveria ser feito!
Capítulo 1 Conhecimentos Iniciais 11

Finalmente, temos a tão decantada planta à qual me referi no início do capítulo e


que outras ciências a utilizam de forma extensiva.
Continuamos com o problema de como utilizar esses diagramas. Em que ordem?
Nesse ponto, começamos a nos preocupar com o processo de desenvolvimento de
software.

UML não é o processo de desenvolvimento?


Logo nos primeiros parágrafos indiquei que existem muitos processos de desen-
volvimento, e esta informação procede. Já citamos um formato que é o de Queda
d’água. Indicamos, também, que a UML não é um processo, e sim a forma de co-
municação que um processo pode utilizar.

Como nasceu o Processo Unificado?


Ivar Jacobson, em 1995, informou ao mundo sobre sua forma de ver o processo de
desenvolvimento em seu livro Object-Oriented Software Engineering3; esse pro-
cesso teve seu nome batizado de Objectory.
Ao se juntar à Rational, Jacobson pôde agregar pontos ao seu processo que ainda
deixavam a desejar. Nasceu então o Processo Objectory da Rational (ROP – Ratio-
nal Objectory Process). Com a evolução da Rational e a aquisição de outras em-
presas, surgiu o Rational Unified Process (RUP), que é um subconjunto do Processo
Unificado. Existem diferenças entre ambos os processos.

Quais as principais características do Processo Unificado?


O Processo Unificado é dirigido por Casos de Uso. Casos de Uso são descritos no
Capítulo 3 deste livro, que o detalha de várias formas; ali também escrevemos Ca-
sos de Uso para nosso software de exercício. Descrições de Casos de Uso e seus
diagramas embasam a construção de software pensado, levando-se em conta o Pro-
cesso Unificado.
O Processo Unificado é centrado em arquitetura. Esta é a preocupação de como
vemos um software como um todo. Quando escrevemos questões de orçamento,
tecnologias e ambientes de software sobre o qual o novo software estará pautado,
estamos falando de sua arquitetura. A arquitetura de um sistema pode ser descrita
com os seguintes documentos e diagrama: O documento Visão, o Diagrama de
Caso de Uso referente à Visão e seus módulos são vistos no Capítulo 2; Diagramas
de Componentes e Implantação são abordados no Capítulo 12; o Diagrama de
Interação – Visão Geral pode ser visto no Capítulo 16 e o MER, que pode ser visto
no Capítulo 10, dão nos as perspectivas da arquitetura do software.
As formas de reutilização de software que estão em forma de componentes são va-
lorizadas e encorajadas. Os Casos de Uso que foram criados ao longo do software
12 Desenvolvendo Software com UML 2.0 – Definitivo

indicam quais componentes – devido à sua coesão e acoplamento (Capítulo 5) –


serão criados e sua capacidade.
O Processo Unificado é iterativo e incremental. Uma versão do sistema liberada re-
sulta em uma iteração concluída. Aprende-se com a entrega feita por meio de aná-
lises post-mortem que são realizadas em cada iteração. Se uma entrega promoveu
uma melhora, ela incrementou algo no sistema, daí o chamarmos de iterativo e in-
cremental.
A utilização da abstração, descrita neste livro, juntamente com as aprovações dos
Casos de Uso, permitirá obter um incremento muito próximo do software certo a
ser construído. Este livro passa por uma iteração ao longo do software proposto,
que será uma Locadora de DVDs Virtual.
A princípio, eu prego que devemos pensar na parte mais crítica de qualquer soft-
ware, tentando promover a primeira iteração mostrando valor agregado no novo
software logo de início. As necessidades acessórias (objetos e entidades) vão sur-
gindo ao longo dessa primeira iteração.
Uma iteração percorre cinco workflows descritos mais adiante.
Um incremento pode ser considerado uma versão liberada e pronta para um teste
de uma funcionalidade específica.
Quando digo isto, em curso, os alunos pensam em um software todo pronto, com
tudo o que se tem direito funcionando... Porém, um incremento pode ser apenas
um conjunto de funcionalidades que determinados Casos de Uso prevêem.
Um incremento indica que se iniciou a descrição de determinados Casos de Uso;
conceituamos, especificamos, codificamos seus cenários, pensamos em um MER
que atende àquele conjunto e, também, em uma interface gráfica que os suportam.
Esse conjunto concluiu um incremento, pois houve uma iteração que atravessou as
quatro fases do processo unificado e, em cada fase, utilizamos alguns ou todos cin-
co workflows. Mais adiante, esclareço as fases e os workflows.
Essa característica também nos mostra a necessidade de interação dos interessados
no software sobre o que está ocorrendo e com os elementos responsáveis por levan-
tar os requisitos. Interagindo com os analistas, forçando a aprovação de forma persis-
tente dos requisitos descobertos nos Casos de Uso, os interessados são convidados
ao comprometimento circular durante o ciclo de vida da confecção do software.

Quais são as fases do Processo Unificado?


O Processo Unificado prevê quatro grandes fases: Concepção, Elaboração, Cons-
trução e Transição como mostra a Figura 1.2. As iterações ocorrem dentro de cada
uma dessas fases. Uma fase pode, portanto, ter de uma ou várias iterações. Não
existe um número predeterminado de iterações dentro de uma fase.
Capítulo 1 Conhecimentos Iniciais 13

Concepção
Na fase de concepção, pensamos na Visão do Software, em que o documento de
mesmo nome é construído (veja o Capítulo 3), avaliamos a tecnologia que se apre-
senta, relacionamos os riscos principais ou mais aparentes, e detectamos a(s) área(s)
mais crítica(s) a ser(em) tratada(s).
Nesse momento, os alunos me perguntam se já entregamos uma proposta com
prazo e preço para o interessado. Aqui, sempre informo a necessidade de levarmos
essa fase a um período que varia de uma a duas semanas, dependendo do tamanho
do software.
Em seguida, sempre recebo a pergunta: “Para quê?” Justamente, esse período é
para realizarmos as atividades dessa fase e tentarmos escrever os Casos de Uso da
parte mais crítica descoberta. Ao final desse período, podemos entregar, ao inte-
ressado, uma proposta, o documento Visão, as descrições dos Casos de Uso da
parte mais crítica do software ou, pelo menos, uma boa parte, o diagrama de Caso
de Uso do documento Visão e seus módulos, um diagrama de classes e um MER
conceitual da parte mais crítica do software. Com essa gama de informações pode-
mos, agora, informar prazo e preço com mais certeza do que o que vínhamos fazendo.
Os alunos retratam a dificuldade de se fazer isso em licitações públicas ou priva-
das, porém, não tenho resposta para tudo... Existe até mesmo a possibilidade de se
aceitar fazer um software sem a perspectiva de se receber qualquer valor. Faz-se o
software apenas para cativar o cliente... Embora eu já tenha visto muito choro e
ranger de dentes devido a esse approach.
Essa fase também é responsável pelo início do uso dos documentos Nomenclatura
e Glossário, abordados no Capítulo 2, que avançam por todas as fases do processo.
Quando todos concordam com o escopo descoberto, ou seja, até onde esse soft-
ware vai ou qual será o seu limite; quando sabemos qual é a tecnologia a ser utili-
zada, como Banco de Dados, Linguagem de Desenvolvimento, Ambiente de De-
senvolvimento etc.; que tipo de foco será adotado, se cliente servidor – Internet –
Intranet – dispositivos sem fio; que tipo de software de Controle de Versão (CVS) será
usado; em qual sistema operacional ocorrerá o desenvolvimento e em qual sistema
operacional a fase de implantação se dará; quando temos um estudo sobre a TIR
(Taxa Interna de Retorno) e o ROI (Return on Investment – retorno sobre o investi-
mento) do projeto, para validarmos se este deve seguir à frente, essa fase terminou.
Essa fase tem, tipicamente, uma iteração. Ela incrementa o entendimento do soft-
ware como um todo para todos os participantes do projeto.

Elaboração
É nesta fase que os requisitos (que aparecem no conjunto dos Casos de Uso) das
áreas mais críticas são levantados. Ela consolida a fase de concepção, agregando
14 Desenvolvendo Software com UML 2.0 – Definitivo

valor a cada iteração-incremento que sofre. A fase de elaboração se repete ao lon-


go do desenvolvimento, ou seja, o ciclo de vida do software.
Quando apresentamos uma melhoria com relação a uma iteração anterior, relaci-
onada, por exemplo, ao entendimento de um Caso de Uso, terminamos uma itera-
ção nesta fase. Podem existir várias iterações aqui.

Construção
Quando pensamos em protótipos e nos relacionamos com campos de um banco de
dados, quando funções ou stored procedures conversam com componentes em
Servlets ou EJB, estamos enfrentando a fase de construção do Processo Unificado.
Os interessados avaliam o software ainda em versões beta. O conceito de que sem-
pre deve haver uma versão beta sob avaliação é sinal de que essa fase passa por
uma iteração.
É evidente que, em função dos testes, é aqui que devemos nos livrar dos erros do
software.

Transição
Quando parte do software sai da versão beta e pode ser avaliado como versão de
produção, significa que estamos na fase de transição, em que os erros encontrados
devem ser mínimos. Se chegarmos à homologação da parte sendo avaliada, o ciclo
terminou.

De quais workflows se compõe o Processo Unificado?


O Processo Unificado prevê cinco workflows, que são: Requisitos, Análise, Proje-
to, Implementação e Testes como mostra a Figura 1.2. O termo workflow tem,
aqui, o significado de um conjunto de atividades com um objetivo comum.
Essas são as atividades pelas quais se deve passar quando se está em uma fase. Isto
é o mesmo que dizer que cada fase pode prever essas cinco atividades.

Requisitos
Aqui é necessário se obter todos (todos significam todos mesmo) os requisitos ne-
cessários para a formação de Casos de Uso bem escritos. Se um software necessitar
se amparar em uma documentação, no presente momento ou no futuro, para ser
construído, essa documentação será os Casos de Uso.
Quando qualquer fase passa por esse workflow, sua finalidade é obter Casos de
Uso bem formados.
Esse workflow está contido tipicamente nas fases de Concepção, Elaboração e
Construção.
Capítulo 1 Conhecimentos Iniciais 15

Análise
Quando identificamos quem realizará um Caso de Uso ou um de seus cenários
principais, em termos de classes de forma conceitual, estamos dentro do workflow
de Análise.
Esse workflow está contido tipicamente nas fases de Concepção, Elaboração e
Construção.

Projeto
Quando saímos de uma visão conceitual da construção de classes e diagrama de se-
qüência, na abstração requerida, estamos dentro do workflow de projeto. Esse work-
flow está contido tipicamente nas fases de Concepção, Elaboração e Construção.
Por vezes, mesclo os dois workflows (análise e projeto) em um único. Com freqüên-
cia, acho difícil no dia-a-dia separar de forma documentada e distinta as duas fases.

Implementação
Esse workflow é encontrado quando estamos codificando e compilando algum có-
digo. A própria construção de uma página HTML e sua colocação em funciona-
mento é sinal de que estamos executando esse workflow dentro de alguma fase.
A transformação do diagrama de classes em componentes, bem como o atendi-
mento do diagrama de seqüência, mostra que estamos nesse workflow. Ele está
contido tipicamente nas fases de Elaboração e Construção.

Testes
A criação de um modelo de testes, ou seja, a descrição de por quais testes uma im-
plementação deve passar, relata esse workflow. A compilação dos resultados des-
ses testes (que devem ser anotados e identificados por data e condição de teste)
servirá em análises post-mortem.
Esse workflow está contido tipicamente nas fases de Elaboração e Construção.

Fases com workflows


Como vimos, o processo dito assim, em poucas páginas, parece algo simples, po-
rém, é muito maior que este simples resumo.
Vale a dica de que você deve ler o livro The Unified Software Development Process4.
Aproveito para acrescentar neste quadro, que você não leve o processo em seus mí-
nimos detalhes. Existirão fases que, eventualmente, não se usarão um determinado
workflow. Isso não será nenhum crime!
O que você não pode fazer é pular uma fase – as quatro fases devem existir, embo-
ra as atividades dentro de uma fase possam ser suprimidas.
16 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 1.2 Divisão proposta das quatro fases e os cinco workflows.

Chamamos o que cada fase produz de artefatos. Você encontrará um detalhamen-


to sobre os artefatos que cada fase deve produzir dentro da especificação do pro-
cesso unificado. Estes podem ser diagramas, documentos, conceitos ou modelos.
Quem realiza essas fases, no Processo Unificado, são os trabalhadores. Estes assu-
mem papéis de acordo com seu conhecimento profissional e habilidades pessoais.
É evidente que toda a equipe deve ser treinada em processo unificado e UML.
Também, é desnecessário dizer que o primeiro software que utiliza esse formato
deva ser pequeno e com uma equipe pequena.
Cada passo da equipe deve ser documentado; por exemplo, em um blogger interno
da empresa, que mostra a evolução do projeto semana a semana.
As vantagens desse modelo apresentam-se logo à primeira vista. Nesse approach,
somos forçados a atacar a parte mais crítica do software logo no seu início. So-
mente assim, não iremos mascarar os riscos do software.
Como já disse, quando se iniciava um novo software, primeiro pensávamos nos
cadastramentos básicos, somente então passávamos a tratar ‘o negócio’ propria-
mente dito. Procure pensar: “O que, de fato, aconteceria, se você passasse a pensar
na parte central do software e os cadastros básicos fossem tratados conforme a ne-
cessidade ordenasse?”
Capítulo 1 Conhecimentos Iniciais 17

O que aconteceria se os requerimentos mais críticos fossem focados logo que se


iniciasse o desenvolvimento?
Neste approach o time de desenvolvimento seria forçado a ‘fechar’ um conceito re-
petidamente. Os mal-entendidos seriam resolvidos logo que se iniciasse o proces-
so. O processo não seria em cascata, mas sim contínuo! Testes seriam realizados
de forma muito mais realista, e o time de desenvolvedores aprenderia ao longo das
respostas do usuário.
Nessa visão, espera-se que os requisitos mudem ao longo do desenvolvimento.
Quando falamos em requisitos e que estes podem e devem evoluir ao longo do pro-
cesso de desenvolvimento de software, esperamos algum tipo de gerenciamento
dessas mudanças. Caso não adotemos esse gerenciamento, estaremos caindo nos
erros mais críticos da construção de software: A falta de visão do tamanho do soft-
ware e seu conseqüente atraso.
Gerenciar requisitos é a capacidade de extraí-los de forma eficiente, organizá-los e,
finalmente, documentá-los. Neste livro, teremos uma sugestão de extração e escri-
ta para esses requisitos. No Capítulo 2 falaremos mais a respeito de requisitos,
mudanças e seu contexto.
Devemos partir para a alternativa de envolver o usuário ao longo do processo,
conforme mostrado no modelo de desenvolvimento iterativo de software. É neces-
sário terminarmos com o antigo modelo, em que o usuário visualizava as primei-
ras versões do software pedido e relatava: “Não foi nada disso que pedi”. Esse tipo
de frase tende a sumir, em razão do comprometimento requerido no desenvolvi-
mento iterativo de software.
Os riscos, nesse approach, continuam uma constante, mas a diferença está no fato
de que o usuário contratante acompanha todo o processo. Como em um círculo,
informa requisitos, participa de alterações quando algo é apresentado para testes
e, ainda, acompanha a implantação. Isso é o comprometimento.
Todas essas etapas vão e voltam, exigindo a sua participação constante.

Agora temos a planta e os passos?


Quando alguém me interpela e diz que o processo unificado e a UML são grandes
demais para serem utilizados, fico imaginando que essas pessoas estão sem nada
no momento e que não QUEREM nada que as direcione.
Antes de reclamar do uso de uma metodologia qualquer, como o Processo Unifica-
do, ou de uma ferramenta de desenho e modelagem qualquer, como a UML, verifi-
que se você pode sugerir uma alternativa.
Se a resposta for positiva, adote o seu formato, que pode até ser XP (Extreme Pro-
gramming), RUP (Rational Unified Process), ICONIX, AM (Agile Modeling) etc.
18 Desenvolvendo Software com UML 2.0 – Definitivo

Como se vê, existem outros processos, porque ainda não chegamos a um senso co-
mum sobre o padrão a ser utilizado e o Processo Unificado, ainda tem alguns anos
a percorrer. Tome, como exemplo, um software que necessite alterar seus requisi-
tos de forma quase que imediata. As fases e os workflows do Processo Unificado
podem não ser adequados.
Fica, então, a certeza de que é preciso, pelo menos, modelar os sistemas que nos ar-
voramos construir. Assim, o que é modelar?
Modelar sistemas é a capacidade de simplificar a complexidade. Fazemos isso por-
que não temos a facilidade de enxergar e reter a informação sobre tudo o que um
software precisa. Por essa razão, construímos modelos. Nós nos adaptamos, com
muito mais facilidade, a modelos desenhados do que a textos escritos, que nos ex-
plicam as necessidades de um software. Como foi mostrado, o processo unificado,
em suas fases, tem como produto artefatos que também são modelos, e são repre-
sentados na UML por diagramas.
Os motivos para se modelar software são diversos, porém, Caper Jones nos dá
uma idéia em Patterns of Software Systems Failure and Success:5

» impreciso entendimento das necessidades dos usuários;


» inabilidade de conduzir as alterações nos requerimentos;
» módulos que não se conversam de forma inteligível;
» softwares difíceis de manter e estender;
» descoberta tardia de falhas graves de projeto;
» desempenho inaceitável;
» time de desenvolvedores, cada um tentando descobrir quem alterou o quê,
quando e por que; e
» falta de confiança no processo de construção e implantação.
Não há forma de se fazer um software hoje, sem adotarmos uma forma de modelagem.
Alguns alunos me perguntam: “O que o gerenciamento de projetos, que utiliza téc-
nicas variadas como, as do PMI, tem a ver com o Processo Unificado?”.
As competências, hoje, são relacionadas e interdisciplinares. Não temos como se-
parar esses conhecimentos senão para fins didáticos! Você pode usar o conheci-
mento adquirido com estudos relativos a gerenciamento de projetos aplicá-los ao
Processo Unificado.
O gerenciamento de projetos é uma outra área que engloba os processos descritos
na Engenharia de Software. Para gerenciar um projeto temos de nos preocupar com
nove áreas do conhecimento, conforme a filosofia PMI. É necessário ficar claro que
PMI (Project Management Institute – www.pmi.org) não versa exclusivamente sobre
software – aliás, elas seu escopo é para a construção de qualquer projeto, mesmo um
prédio. As áreas de conhecimento abrangidas pelo PMI podem, também, ser utiliza-
das para gerenciar software.
Capítulo 1 Conhecimentos Iniciais 19

São elas:

Figura 1.3 Áreas do conhecimento abordadas pelo PMI.

Para se saber mais sobre gerenciamento de projetos, consulte o Web site


http://www.pmi.org/info/default.asp. No Brasil, existe o link do PMI (Project Mana-
gement Institute), http://pmisp.org.br/home.asp.
Existem outros capítulos no Brasil, fora do Estado de São Paulo. Você pode asso-
ciar-se e, também, certificar-se em PMP (Project Management Professional).

Quais os próximos passos depois do Processo Unificado, da


UML e do PM?
Quando sua empresa estiver com pelo menos um projeto concluído, utilizando o
Processo Unificado, a UML e as técnicas de gerenciamento de projetos, ela pode se
candidatar a uma certificação em CMM.
CMM (Capability Maturity Model.) é uma certificação internacional que atesta
que sua empresa está madura no desenvolvimento de software. Existe uma estru-
tura para essa certificação que segue níveis de maturidade:
Nível 2 – Planejamento e tarefas de configuração e qualidade, entre outros;
Nível 3 – Organização de processos de desenvolvimento, treinamentos e gerencia-
mento de integração, entre outros;
Nível 4 – Gerenciamento de processo e quantificação de qualidade, entre outros;
Nível 5 – Prevenção de defeitos, gerenciamento de mudanças e seu processo, entre
outros.
Veja maiores detalhes nas referências.6, 7

Existe alguma forma de resumir o formato utilizando o


processo unificado e a UML?
Como sugestão resumida, a fim de reduzirmos as ansiedades, posso citar:
» confecção do documento Visão;
20 Desenvolvendo Software com UML 2.0 – Definitivo

» criação do diagrama de Caso de Uso nível 0 – Pacote de Sistema. Aqui, muitos


profissionais gostam de elaborar um modelo funcional. Mesmo pensando em
orientação a objetos, nada há de errado em criarmos um modelo funcional, po-
rém, podemos assumir que o diagrama de Caso de Uso também cobre essa tarefa;
» formalização do documento Nomenclatura;
» formalização do documento Glossário;
» reunião inicial com todos os analistas e desenvolvedores;
» exploração de cada Caso de Uso em diagramas de nível 1 – Pacotes de subsistemas;
» descrição dos Casos de Uso e sua aprovação, baseada no nível 1;
» aprovação desses Casos de Uso;
» início do diagrama de classes;
» início do diagrama de seqüência;
» definição do Modelo de Entidade e Relacionamento;
» conclusão da interface gráfica;
» aprovação do protótipo com o usuário;
» início da codificação do negócio identificado; e
» construção dos demais diagramas necessários ao software.

Isso tudo ocorre dentro do processo iterativo de software, devidamente dividido


em fases e seguindo os workflows já comentados.

Conclusão
Neste capítulo, fizemos uma comparação do modelo de desenvolvimento de soft-
ware que utiliza a cascata com o modelo que utiliza o processo iterativo. Este pos-
sui as seguintes características: dirigido a Casos de Uso, centrado em arquitetura,
iterativo e incremental.
Dentro do processo iterativo, vimos que existem fases: Concepção, Elaboração,
Construção e Transição. Nessas fases utilizamos workflows, que são atividades
definidas para cada uma. Esses workflows são: Requisitos, Análise, Projeto, Imple-
mentação e Teste. Uma determinada fase pode utilizar um ou todos os workflows.
O que uma fase produz são artefatos, que podem ser: diagramas, documentos,
conceitos ou modelos.
Quem realiza os workflows são os trabalhadores, que recebem um papel para de-
sempenharem nas fases do projeto. Esses papéis podem ser alterados, dependendo
do tamanho do projeto e de sua complexidade.
Os workflows devem ser documentados e expostos na intranet da empresa.
Uma empresa deve começar por um software pequeno, e com uma equipe pequena
anotando seus progressos e fracassos.
Uma análise post-mortem deve ser realizada ao fim de cada iteração, que provo-
cou um incremento de funcionalidade no software proposto.
Capítulo 1 Conhecimentos Iniciais 21

Existem outros modelos propostos de processos de desenvolvimento de software, que


podem ser utilizados dependendo do conhecimento e segurança que se tem deles.
O gerenciamento de projetos pode e deve ser utilizado seguindo uma metodologia.
Existem, atualmente, as sugestões do PMI, que não é um senso comum, porém é
um ponto de onde se partir. O PMI é utilizado para projetos de qualquer natureza
e deve sofrer alterações para se adequar à construção de software.
O último passo que uma empresa pode galgar na construção de software é a obten-
ção de uma certificação CMM, que lhe atesta a capacidade de desenvolver software.
Somente estar no primeiro nível CMM em nada certifica a empresa, pois o fato de
iniciar a certificação coloca a empresa no nível 2. Após a certificação, ela deve cui-
dar para permanecer dentro do nível alcançado.

Exercícios
1. Por que a Tecnologia da Informação é precária no desenvolvimento de software em
contraposição a outras ciências como: engenharia naval, engenharia civil, engenharia
mecânica e outras?
2. Por que é tão difícil, para um interessado no desenvolvimento de um software, expressar
suas necessidades de forma a não deixar dúvidas?
3. As alterações que um interessado no desenvolvimento de um software faz devem ser
estanques, ou seja, estacionadas no tempo?
4. Por que é importante a fase de pré-projeto, que pode ser considerada a fase de concep-
ção do software?
5. Por que, normalmente, a fase de concepção do processo iterativo não possui iterações?
6. Será válido mesclarmos processos de desenvolvimento de software?
7. Quais são as fases do processo iterativo?
8. Quais são os workflows do processo iterativo e onde eles se encaixam no processo?
9. Existe uma forma de se medir a excelência de empresas na confecção de software?
10. As sugestões do PMI são, de forma absoluta, pertinentes a software?
Nada lhe posso dar que já não exista em você mesmo.
Não posso abrir-lhe outro mundo de imagens, além daquele
que há em sua própria alma. Nada lhe posso dar a não ser a
oportunidade, o impulso, a chave. Eu o ajudarei a tornar visível
o seu próprio mundo, e isso é tudo.
HERMANN HESSE

Você aprendeu alguma coisa. Isso sempre parece, à primeira


vista, como se tivesse perdido alguma coisa.
BERNARD SHAW

B ons softwares têm documentação, ou seja, uma história na qual podemos nos
apoiar para entendê-los. É comum vermos que a documentação, freqüentemente,
é deixada de lado, ou por preguiça, ou pela pressão do tempo em se ver algo concreto
para a exibição ao usuário. Contudo, isso pode deixar de ser problema, se nos ocupar-
mos com a documentação como uma das tarefas do desenvolvimento.
Aqui, proponho três documentos iniciais que podem ser agregados, pela sua utili-
dade ou por seu valor histórico, ao modelo de desenvolvimento de sua empresa.

Documento Visão
O documento Visão é um relato resumido com os principais tópicos que o negócio a
ser automatizado deve fornecer. Normalmente, ele faz parte do contrato de desenvol-
vimento de software. Esse documento pode abordar aspectos de tecnologia como,
Capítulo 2 Documentos Iniciais de um Software 23

quais linguagens e bancos de dados serão usados. Apesar disso, ele é uma leitura de
alto nível para aqueles que são os contratantes do software. O diagrama de Caso de
Uso de nível 0 ou Pacote de <<sistema>> baseia-se nesse documento.
Ele é uma espécie de ‘contrato’, entre quem contratou e quem é contratado. Onde
o requisitante diz: “É para isso que o estou contratando, e é isso que quero como
fruto do desenvolvimento que se iniciará”. E quem desenvolve o software diz: “É
para isso que estou sendo contratado, e é baseado nisso que desenvolverei o pro-
duto de software”. O tamanho do documento é relativo à sua vontade de ‘expli-
car’ o software em poucas folhas.
O nascimento desse documento, normalmente se dá na primeira reunião com os
clientes do software. Aqui, é necessário explicitar que clientes não são somente pes-
soas ou organizações externas, mas pessoas, divisões ou departamentos internos.
Vamos iniciar a confecção do nosso documento Visão, relativo à Locação de
DVDs pela Internet.
Neste texto, chamaremos de cliente contratante aquele que nos contratou para fazer
o software. Cliente locador ou cliente usuário aquele que usa o software.
O documento Visão pode ser bastante extenso. Há sugestões de fazê-lo com diver-
sas seções. A seguir, apresento uma sugestão de modelo detalhado e o nosso mode-
lo que será bem resumido e atenderá aos fins deste livro.

Modelo de Documento Visão – Detalhado


1 Introdução
Reserve esta seção para uma descrição geral do trabalho esperado.
2 Escopo
Relacione os principais módulos que serão detalhados em perpectivas do produto. (Veja os
itens 8.1, 8.2 etc.)
3 Definições Acrônimos e Abreviaturas
Faça o possível para não utilizar termos relativos à área de informática, se isso for
imprescindível, então forneça o significado desses termos nessa seção.
4 Referências
Relate a fonte, na qual esse documento se baseou e os participantes desses eventos.
Nomeie as pessoas, seus cargos e localidades.
5 Oportunidades de Negócio
Descreva qual é a oportunidade de negócio que está em apreciação como motivação para
o surgimento desse software.
5.1 Problema a Ser Solucionado
Descreva qual é o problema que está sendo solucionado com esse software.
6 Descrições de Stakeholder e Usuários
Relacione os stakeholders com seus cargos, nomes, telefones, e-mails; e faça o mesmo com os
usuários principais. Isso será uma boa referência para futuros participantes desse software.
6.1 Stakeholder
24 Desenvolvendo Software com UML 2.0 – Definitivo

Modelo de Documento Visão – Detalhado (Continuação)


6.2 Usuários
6.3 Ambiente Atual dos Clientes
Descreva o ambiente atual de informática relativo a esse software que será construído,
como sistema operacional, tecnologias e outros que considerar importante.
7 Observação
Agregue qualquer informação que achar importante.
8 Módulos
8.1 Perspectiva do Produto: Nome do Módulo I
8.2 Perspectiva do Produto: Nome do Módulo II
8.3 Perspectiva do Produto: Nome do Módulo ...
Descreva nesses tópicos os detalhes que cada módulo atenderá. Procure descrever o
que o módulo faz, para que serve e como se relacionará com outros módulos, se isso for
importante. Cada módulo será um componente no diagrama de Caso de Uso que
representará o <<sistema>>.
9 Precedência e Prioridades
Indique qual é a prioridade dos módulos e se ela será a mesma ordem de precendência
para o desenvolvimento. Explique por que adotou essa estratégia e, principalmente, por
que deixou de usar outras. Explicar isso pode ser importante para futuras reuniões, onde
podem perguntar: “Mas, por que não fizemos isso dessa maneira?”
10 Requisitos Não Funcionais
Relate aqui as dependências de softwares externos, particularidades de performance que
são esperadas, grandes necessidades de treinamento e outras que achar necessário.
11 Requisitos de Sistemas e Ambientes
Descreva o sistema operacional elegido, a linguagem de programação e os bancos de dados
que serão utilizados. Nessa seção, informe se será utilizado um servidor de aplicação, qual é
esse servidor, assim como o servidor de Internet e outros softwares dos quais ele dependerá.
11.1 Sistema Operacional
11.2 Linguagens de Desenvolvimento
11.3 Banco de Dados
12 Requisitos de Documentação
Descreva em quais partes a documentação será dividida, quais são essas partes e o quê o
cliente pode esperar de cada uma.
13 Visão Geral UML do Sistema – Modelo Conceitual
Insira uma figura que represente o diagrama de Caso de Uso baseado neste documento.

Modelo de documento Visão – Resumido


Software: Locação de DVDs pela Internet
Data: 28 de junho de 2004
Requisitantes
Empresa Cliente
Capítulo 2 Documentos Iniciais de um Software 25

Principais Contatos
Contato 1 – e-mail – fone
Contato 2 – e-mail – fone
Contato 3 – e-mail – fone
Descrição
Este software tem o objetivo de disponibilizar a locação de DVDs, via Internet, a
clientes já cadastrados ou novos.
O software deve prever o cadastramento de usuários locadores, com seus dados
pessoais, principalmente, os dados de endereço, que são tão importantes para a en-
trega como para a recuperação de produtos alugados.
O software atenderá a todas as cidades onde o cliente contratante tiver depósito de
DVD. Serão disponibilizados somente DVDs da cidade onde o cliente locador resi-
de, visando à entrega.
O cliente locador deve informar o modelo de seu equipamento de DVD, a fim de se
avaliar se ele é ou não adequado a reproduzir o filme.
O cliente locador terá, no máximo, cinco dias para a devolução de um DVD aluga-
do, sendo que esse período dependerá do tipo de DVD, que pode ser: desde lança-
mento até DVDs antigos. O processo de fidelizar o cliente locador leva em
consideração tanto o número de locações quanto as devoluções pontuais.
A não devolução de um DVD no prazo estipulado implica pagamento de multa.
O cliente locador pode designar, desde que apresente a documentação necessária,
beneficiários capazes de efetivar um aluguel de DVD.
As entregas serão feitas somente dentro da cidade em que o locador reside.
Os administradores do site poderão, controlar Programa de Fidelidade, Programa
de Promoções, Preços e Marketing.
Os pagamentos serão feitos antecipadamente, pelo cartão de crédito ou boleto bancário.

Ass. Cliente Contratante Ass. Equipe de Desenvolvimento


---------------------------------------- ----------------------------------------

É necessário fazer um comentário final sobre o documento Visão para sedimentar-


mos o seu perfil. Reveja o seguinte parágrafo: “Os administradores do site poderão
controlar Programa de Fidelidade, Programa de Promoções, Preços e Marketing.”
Esse documento não entra, e não deve entrar, em detalhes de como essas ações se-
rão feitas; elas serão feitas e ponto final. A descrição, aqui, é em alto nível.
26 Desenvolvendo Software com UML 2.0 – Definitivo

A mensagem aqui é alertá-lo para não transformar um documento que delimita o


escopo do sistema proposto em uma especificação detalhada para um grupo de
pessoas que estão habituadas a ler documentos curtos, objetivos e de poucas fo-
lhas. Esse detalhamento tem local próprio para pensarmos nele, nos Casos de Uso,
que somente serão feitos mais tarde.
Com esse documento inicial, os gerentes do cliente contratante e os gerentes que
vão administrar a confecção do software têm uma visão sobre o que será feito.

Diagrama de Caso de Uso (nível 0) da Visão ou pacote de


<<sistema>>
Para iniciarmos a confecção de qualquer diagrama da UML, é necessário conhecer-
mos a sua notação, ou seja, a forma como devemos representá-lo e suas semânticas.
O diagrama de Caso de Uso tem uma notação bem simples. Vamos entendê-la.
Acompanhe a numeração na Figura 2.1 com os nossos comentários.
1. Este é um Stick Man ou Ator. O Ator pode ser uma pessoa, um sistema ou mes-
mo o que chamávamos, na análise estruturada, de Entidade Externa; por
exemplo: um banco – instituição financeira. O ator pode ser até algo como um
roteador. Ele realiza uma atividade. O ator sempre atua sobre um Caso de Uso.
2. Aqui nós temos a representação de um Caso de Uso, ou Use Case, em inglês.
Ambas as denominações são utilizadas por autores nacionais. A Elipse é a no-
tação de um Caso de Uso. O Caso de Uso é uma atividade. É a macroação que
o ator realiza.
3. Isto é uma relação de dependência. Significa que Cadastrar Beneficiário depende di-
retamente da conclusão do Caso de Uso Cadastrar Cliente. A notação é uma seta
tracejada, sem identificação aparente. Nada impede que haja uma identificação. A
seta de dependência sempre parte do Caso de Uso que depende de outro em al-
gum momento, apontando para o Caso de Uso que fornece a necessidade dese-
jada. Esse comportamento vale para Inclusão e Extensão.
4. Aqui, Notação pressupõe uma inclusão de um Caso de Uso ou de parte dele em
outro Caso de Uso. Neste exemplo, o Caso de Uso Calcular Pontos utilizará in-
tegralmente a forma de Cálculo de Pontos de Fidelidade que se encontra docu-
mentada em Calcular Fidelidade. Isso serve para não termos que digitar duas
vezes especificações que se repetem em diferentes Casos de Uso. Evitamos es-
crever demais ou de menos a cada vez que escrevemos. É uma boa forma de
centralizarmos a descrição dos Casos de Uso.
5. O formato anterior prevê que existe um cálculo em Calcular Bonificação, e que
esse cálculo irá se estender, ampliando o significado de uma fórmula já exis-
tente no Caso de Uso Calcular Fidelidade. São válidas aqui, também, as obser-
vações feitas no tópico 4.
Capítulo 2 Documentos Iniciais de um Software 27

Figura 2.1 Notação do diagrama de Caso de Uso na UML.

Agora sabemos o que é um diagrama de Caso de Uso e como utilizá-lo, então va-
mos criar o diagrama de Caso de Uso para o documento Visão (Figura 2.2). No
próximo capítulo, faremos os diagramas de Casos de Uso para os níveis 1.
Fazer esse diagrama é um exercício pessoal; não poderei olhar o seu diagrama e di-
zer que está errado. Um diagrama desse tipo, na verdade, apenas informa visual-
mente os principais tópicos que podem ser explorados ao longo do seu estudo.
Pode acontecer que uma elipse não tenha elementos suficientes para ser explorada
em outro diagrama, o de nível 1. Isso não fere em nada o seu software ou planeja-
mento.
Alguns autores não colocam a figura do quadrado, para designar os limites –
boundary – do software. Não há regra que se sustente aqui. A única regra é você
saber que a notação UML deve ser mantida, os Casos de Uso devem representar ma-
croatividades a serem realizadas; os atores, aqueles que executam essas atividades.
A única notação não comentada é a da seta direcional, a qual apenas liga um Ator
a um Caso de Uso, ou um Caso de Uso a outro Caso de Uso.
28 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 2.2 Caso de Uso relativo ao documento Visão.

Alguns autores sustentam a possibilidade de representar a ligação entre um Ator e


outro Ator. Sustento, porém, que para que um Ator interaja com outro Ator será
necessário um Caso de Uso entre os dois. Outros propõem até ligações de herança
(que veremos nos próximos capítulos).
É necessário frisar aqui que um diagrama de Caso de Uso não tem reflexo direto
em codificação. Ele é um instrumento de visualização da complexidade é a abstra-
ção da complexidade. Falaremos sobre abstração no próximo capítulo.
Vamos agora, supor que o cliente contratante aprovou nosso contrato, nosso do-
cumento Visão, e entendemos nosso diagrama de Caso de Uso para o documento
Visão, o de nível 0. Estamos prontos para o momento do início da análise, propria-
mente dita. Essa fase começa com a confecção do documento Nomenclatura.

Documento Nomenclatura
O documento Nomenclatura serve para criarmos um padrão único de pré e pós-fi-
xação para todos as palavras envolvidas em estrutura de código, escrita de Caso de
Uso ou mesmo criação de tabelas de banco de dados.
Novos colaboradores que se juntarem à equipe deverão se adequar a esse formato
de escrita, que é o único permitido no uso diário. Veja que o benefício dessa deci-
Capítulo 2 Documentos Iniciais de um Software 29

são é, principalmente, o de não termos vários estilos de código para lermos. Nesse
documento, as regras de documentação de código devem estar explícitas, a fim de
não gerar más interpretações.
A notação Hungariana (HN) é uma convenção de nomes que foi originalmente fei-
ta por Charles Simonyi, da Microsoft, e que é usada ao longo de todo o código-fonte
do sistema operacional Windows. A especificação original é um pouco complexa e
específica para a linguagem de programação C, porém ela pode ser convertida
para outras linguagens e, no nosso caso, iremos portá-la para Java. Essa decisão se
dá em razão de que todos os nossos exemplos serão em Java e tínhamos de esco-
lher uma linguagem. Faça as adaptações para o seu caso específico.
Caso queira maiores informações sobre a notação HN, vá até o link da Hungarian
Notation for C Programming1. Esse link, entre outros, contém um briefing do es-
tudo de nomenclaturas.
Passamos a uma sugestão de nomenclatura: Sua empresa deve adotar uma que per-
mita o encontro da identidade do seu formato de nomenclatura.

Modelo de nomenclatura

Variáveis, Objetos e Classes


As variáveis são constituídas de diversas partes, quais sejam:
Escopo da Variável + Tipo da Variável + Nome da Variável + [Qualificador]

Escopo
Em C, escopo representa a visibilidade de uma variável, como global, local etc. Em
Java, o escopo não é tão importante, porque não existem variáveis globais em
Java, e tudo se torna um objeto de outro objeto, por exemplo: Java.lang.System.out
ou a constante Java.lang.Math.PI.
As variáveis locais em C e em Java não têm prefixo de indicação de escopo. Assim,
a prefixação de escopo é raramente usada.
Tipo
Indica o tipo de dado ou classe de uma variável; é a parte mais importante da nota-
ção hungariana. Para isso, usamos um único caractere em minúsculo, indicando o
tipo primitivo do dado em Java. Nos casos em que isso se repetir, usaremos a cria-
tividade nata dos programadores.
30 Desenvolvendo Software com UML 2.0 – Definitivo

Tabela 2.1 Tipos de dados básicos


Tipos de dados básicos em Java Prefixo
boolean b
char, char [] c
byte, byte [] by
Short t
int, int [] i
long, long [] l
Float f
double, double [] d
Void v

Tabela 2.2 Tipos de classes e outros tipos em Java


Tipos de classes e outros tipos Prefixo
ArrayIndexOutOfBoundsException aiob
BigDecimal bd
Boolean b
Byte by
Character c
ClassCastException cce
Collection col
Date dt
Double d
Exception ex
Float f
Hashtable ht
IndexOutOfBoundsException Ioob
Integer I
Iterator It
List lst
Long l
NullPointerException npe
Object obj
RuntimeException rte
Set set
Short t
Capítulo 2 Documentos Iniciais de um Software 31

Tabela 2.2 Tipos de classes e outros tipos em Java (Continuação)

Tipos de classes e outros tipos Prefixo


SortedSet sts
String str
String [] str
StringIndexOutOfBoundsException stroobe
TestInvoker ti
Throwable trb
Time tm
URL url
Vector vt
Button btn
Checkebox chk
Dialog dlg
Label lbl
Record r
Rectangle rect
InputStream ins
OutputStream ous
Classe cls
Pacote pct

As exceções a essas regras são relativas a variáveis que têm um escopo relativa-
mente pequeno, por exemplo: loops. Nesse caso, será adotado o uso das letras ‘i’,
‘j’, ‘k’, ‘l’ etc., em minúsculo. Segue um exemplo no código abaixo:
for( int i = 0; i < inúmero; i++) {
...
}

Nome da variável
O nome de uma variável deve seguir a quantidade de palavras necessárias para ex-
plicar o sentido daquela variável. Cada palavra se iniciará por uma letra em maiús-
cula, seguida de outras em minúsculas. Exemplos de nomes de variáveis válidas
são:
iCodigoCliente.
Ao ser lida essa variável indica que seu tipo é um inteiro em Java e
seu conteúdo é o código do cliente. Seguem outros exemplos válidos: cRua, fSalario,
bEstadoCivil.
32 Desenvolvendo Software com UML 2.0 – Definitivo

Em seguida, veja o exemplo de variáveis não válidas:


iCod_Cli, c_Rua, f_Sal, b_Est_C. Este formato nada indica, ou indica os nomes de for-
ma obscura.
Nome de banco de dados e tabelas
Normalmente, esse tópico não é da alçada de quem está desenvolvendo um soft-
ware mas é responsabilidade do ‘Data Base Administrator’ (DBA). Empresas orga-
nizadas possuem um Dicionário de Dados e um Dicionário de Entidades, formatados
com prefixos e pós-fixos. Além disso, devido à grande variedade de Bancos de Da-
dos, não abordaremos a Nomenclatura para esse tópico.
Nome das janelas
Os arquivos que serão dialog no Java, recebem a prefixação de dlg, arquivos html
recebem, no caso de formulários, frm. Se as páginas forem de processamento – pá-
ginas que não aparecem para o usuário final – receberão a prefixação de proc, sig-
nificando processamento. As páginas de resultados recebem a prefixação de rst.
O nome de uma janela deve seguir a quantidade de palavras necessárias para expli-
car o sentido daquela variável. Cada palavra se iniciará por uma letra em maiúscu-
la, seguida de outras em minúsculas. Não deve existir underscore/underline
(sublinhado) separando as palavras. Exemplos de nomes de variáveis válidas para
interfaces gráficas são: frmCadastroDeCliente, rstListaDeClientes etc.
Nomes de operações ou métodos de classes
As operações ou métodos de classes devem ser prefixadas de seu retorno, e este
deve seguir a Tabela 2.2. Esta prefixação deve seguir palavras que identifiquem o
que a operação ou método faz. Sempre que possível, essa parte deve ser iniciada
com um verbo no infinitivo – Obter, Incluir, Alterar, Excluir etc., seguido de ou-
tras palavras que indiquem o alvo daquela ação. Cada palavra deve iniciar em le-
tra maiúscula para facilitar a leitura.
Dessa forma, são válidos os seguintes nomes para Operações ou Métodos em classes:
» strObterNomeCliente – Este nome indica que o método retorna o Nome de um Clien-
te, e seu retorno é uma string;
» bAlterarNomeCliente – Este nome indica que o método alterará o Nome de um Clien-
te, e seu tipo de retorno é um boolean (True ou False);
» rObterHum – Este nome indica que o método retorna um registro do tipo de regis-
tro que a classe suporta;
» curObterMuitos – Este nome indica que o método retorna muitos registros do tipo
de registro que a classe suporta;
» curObterWhere – Este nome indica que o método retorna muitos registros do tipo
de registro que a classe suporta, porém obedecendo a uma determinada cláusula
Where;
Capítulo 2 Documentos Iniciais de um Software 33

» bIncluirCliente – Este nome indica que o método executa uma inclusão no banco
de dados referente ao tipo de registro suportado por aquela classe, e seu tipo de
retorno é um boolean (True ou False);
» bAlterarCliente – Este nome indica que o método executa uma alteração no ban-
co de dados referente ao tipo de registro suportado por aquela classe, e seu tipo
de retorno é um boolean (True ou False);
» bExcluirCliente – Este nome indica que o método executa uma exclusão no banco
de dados referente ao tipo de registro suportado por aquela classe, e seu tipo de
retorno é um boolean (True ou False).

Semelhantemente, são nomes inválidos para Operações ou Métodos de classe:

» sNomeCli, strNomeCli, strNameCli, sNC.

Documento Glossário
O documento Glossário traduz, para alguém que não conhece o software, todas os
termos utilizados pelo usuário contratante e outros stakeholders. Deve ser dispo-
nibilizado na intranet da empresa, a fim de permitir constantes pesquisas.
Normalmente, as empresas adotam um vocabulário particular como ‘intervenien-
tes’, ‘associados remidos’, e outros dos quais o público externo não capta o signifi-
cado à primeira vista.
A finalidade desse documento é agir como um tradutor entre os participantes da
análise, do desenho, da codificação, dos testes e dos herdeiros do software, e o vo-
cabulário particular da empresa.
Esse documento existe para todos os softwares. Cada software possuirá um docu-
mento Glossário que pode e deve ser acrescido de termos, conforme a necessidade
assim o requerer. Vamos apresentar um modelo para o nosso software que, por
enquanto, tem apenas um documento Visão como ponto de partida.

Modelo de glossário
Software: Locação de DVDs pela Internet.
Locação
Ato de alugar um produto disponível no estoque da empresa.
Usuário Locador ou Cliente Locador
Aquele que aluga um produto. Pode ser o locador principal ou seu beneficiário.
Beneficiário
Aquele que é um agregado, por parentesco ou designação de um cliente locador.
Cliente Contratante
Aquele que fez a requisição do software.
34 Desenvolvendo Software com UML 2.0 – Definitivo

Equipamento de DVD
Aparelho que permite a execução de discos de DVD. Nesse sentido, são agregadas
todas as especificações desse aparelho.
DVD Lançamento
Aquele disco de DVD que apresenta data de lançamento do filme inferior a três
meses.
DVD Antigo
Aquele disco de DVD que apresenta data de lançamento do filme superior a três
meses.
Multa
Valor monetário pago à empresa detentora do produto.
Fidelidade
Programa que visa a estimular o retorno de um cliente locador à empresa.

Conclusão
Esses três documentos – Visão, Nomenclatura e Glossário – devem estar disponí-
veis na Intranet da empresa para consultas de todos os participantes, incluindo-se
aí desenvolvedores de outros softwares que o tomarão como modelo.
Se você ainda não tem uma intranet para esses fins, deve providenciá-la, porque
ela será uma grande aliada na comunicação entre os stakeholders do projeto.
O documento Visão é o único que exige uma assinatura do cliente contratante,
pois ele delimita o boundary do sistema proposto. Ele é uma constante lembrança
de que o cliente contratante sabe para que contratou a equipe de desenvolvimento,
e de que a equipe de desenvolvimento de software sabe para que foi contratada.
O documento Nomenclatura deixa claro a todos que a forma de escrever código
deve ser uníssona. Mesmo novos membros de desenvolvimento deverão seguir
essa forma de escrita. Sugiro que constantes auditorias sejam realizadas, a fim de
se verificar o alvo desse objetivo. A realização semanal é uma boa periodicidade.
O documento Glossário evita que se entre em uma reunião sem o mínimo de infor-
mação sobre o que significam os termos pertinentes aos usuários contratantes.
Além disso, quaisquer novos integrantes do software, lendo o documento Visão
juntamente com o documento Glossário e vendo o diagrama de Caso de Uso de ní-
vel zero, terá uma boa visão inicial do software.
Adote esses princípios na sua empresa. Algumas pessoas gostam de ter um outro
documento que se chama diagrama funcional. Ele não pertence à UML, mas nada
impede que seja usado. Até mesmo, alguns usuários compreendem bem esse diagrama.
Capítulo 2 Documentos Iniciais de um Software 35

Além do documento Visão, pode e deve ser preparado um outro documento que
verse sobre as tecnologias a serem usadas, explicitando fabricante, preços, dispo-
nibilidades e treinamentos necessários, como também seus custos.

Exercícios
1. O que é o Documento Visão e para que serve?
2. O que o pacote <<sistema>> expressa no processo?
3. O documento Nomenclatura é necessário? Por quê?
4. O documento Glossário é necessário? Por quê?
5. Quais outros artefatos podem fazer parte dessa análise inicial de software?
6. A partir desses artefatos iniciais; indique qual é o próximo passo natural na construção
de software.
7. Caso o interessado em construir um software deseje alterar o documento Visão, qual
o significado que isto tem?
8. Todos têm acesso ao documento Visão? Justifique a sua resposta.
9. O que é uma relação de dependência entre Casos de Uso?
10. O que é uma relação de inclusão entre Casos de Uso?
11. O que é uma relação de extensão entre Casos de Uso?
12. Explique: o que é um Ator?
13. Como os modelos de pacotes podem ajudar?
Muitas vezes, as pessoas tentam viver a vida às avessas: Elas
procuram ter mais coisas ou mais dinheiro, para poderem fazer
o que querem, de modo que possam ser felizes. A coisa deve
funcionar ao contrário: Você primeiramente precisa ser quem
você realmente é, para então fazer o que precisa ser feito, a fim
de ter o que você deseja.
SHAKTI GAWAIN

Somos todos prisioneiros, mas alguns de nós estão em celas com


janelas, e outros sem.
KHALIL GIBRAN

O Caso de Uso é a parte mais importante da construção de software orientado


a objetos utilizando a UML. Os Casos de Uso são, talvez, o único instru-
mento que acompanha um software do seu início até a sua conclusão.
Em todas as iterações que vão ocorrendo na confecção do novo software, o Caso
de Uso é a ferramenta de consulta, acerto, discussão, reuniões, alterações em re-
quisitos e alterações em desenho. Ele é a análise intrínseca de um negócio, dentro
do processo de desenvolvimento de software, sugerido pelo processo iterativo e
por outras metodologias que se utilizam da UML.
Começamos aqui a ver a diferenciação entre a UML e o processo. Desde já, deve-
mos saber que, no processo, a UML é apenas a ferramenta.
Capítulo 3 Caso de Uso 37

Fazem parte do processo os documentos iniciais, já vistos no Capítulo 2, exceção


feita à construção do diagrama de Caso de Uso para o documento Visão.
Neste capítulo vou descrever o que é o Caso de Uso e para que serve, apresentando
uma sugestão de como elaborá-lo. Aqui, não teremos exercícios relativos à descri-
ção de Casos de Uso, somente os diagramas serão abordados.

O que é um Caso de Uso?


Para entendermos o conceito de Caso de Uso precisamos conhecer o de Ator. Já
abordamos isso no Capítulo 1, mas vamos reiterar que um Ator pode ser uma pes-
soa, um sistema ou mesmo o que chamávamos, na análise estruturada, de Entida-
de Externa, por exemplo, um banco. Um Ator pode ser até algo como um roteador.
Ele realiza uma atividade e sempre atua sobre um Caso de Uso.
Imaginemos um palco e nele, para a realização de uma peça, precisamos de quem re-
presente um papel. Na UML é este o significado dado, alguém ou alguma coisa atua
ou interage com outras pessoas ou coisas, para que algo seja realizado. Esse é o Ator.
É por esta razão que o nome Ator é bem adequado.
Agora que conhecemos o que é um Ator, podemos nos dedicar ao Caso de Uso.
Um Caso de Uso pode ser explicado como uma macroatividade que encerra diver-
sas tarefas ou atividades. Essas tarefas visam à consecução dessa macroatividade.
Um Caso de Uso pode ser, também, uma representação descrita de variadas ações
para a realização dessa macroatividade. Não uso o termo ‘trabalho’ aqui, pois um
trabalho requer muitas ações e de caráter absolutamente diverso. Enquanto tiver-
mos ‘afinidade’ entre as ações realizadas, teremos um Caso de Uso.
Suponha que iniciamos a descrição de um pagamento de compras. A mostra e vali-
dação de um cartão de débito, a informação do valor que será debitado, a informa-
ção da senha que permite o débito do cartão, a validação da senha, o retorno da
instituição financeira sobre a operação e o resumo dessa operação impressa. To-
das essas tarefas designam um Caso de Uso, são correlatas da macroatividade su-
gerida: Efetuar pagamento de compras.
No entanto, quando iniciamos a descrição do preenchimento e impressão da nota
fiscal, estaremos falando de outra macroatividade; neste caso, a macroatividade de
imprimir nota fiscal será, então, outro Caso de Uso.
O limite de um Caso de Uso é uma decisão pessoal. Com a experiência, você
aprenderá a distinguir um Caso de Uso de outro.

Quanto um Caso de Uso deve ser escrito?


Um Caso de Uso deve ser bastante detalhado. Seu detalhamento será usado por to-
das as outras partes do desenvolvimento de software orientado a objeto utilizando
a UML. Isso não quer dizer que deve ser escrito um tratado maçante e longo demais
38 Desenvolvendo Software com UML 2.0 – Definitivo

para ser lido. Por outro lado, a objetividade não deve sacrificar a compreensão e a
composição do detalhe.
Aprendemos na orientação a objetos que devemos utilizar a abstração. A abstração
é: “Princípio de ignorar os aspectos de um assunto, não relevantes para o propósi-
to em questão, tornando possível uma concentração maior nos assuntos principais.”1
Assim, devemos tratar cada abstração, em relação ao que estamos analisando,
como um negócio intrínseco a outro maior. Avalie que um software pertence a um
negócio a ser automatizado. Ao aplicarmos a abstração a esse negócio, podemos
dividi-lo em várias macroatividades, os Casos de Uso. Ao aplicarmos a abstração a
essas macroatividades teremos a análise de suas tarefas.

Quem deve fazer a extração de Casos de Uso?


Já vi departamentos de recrutamento e seleção aplicando vastos testes de matemá-
tica para candidatos a analistas de negócios. Creio, pessoalmente, que isso é um
grande engano.
O analista de negócios que extrai Casos de Uso faz o que o nome do seu cargo indi-
ca: Analisa negócios, como são criados e realizados. Negócio, aqui, não tem o sen-
tido de estabelecimento comercial, mas refere-se à atividade principal, abstração
do negócio comercial, daquela empresa.
A extração de um Caso de Uso somente é possível por duas vias – a observação e a
entrevista. A observação somente é possível em casos onde a atividade é repetitiva,
realizada por um operador ou uma máquina. A entrevista somente é possível entre
humanos. Esta última é a forma mais comum de extração de Casos de Uso.
Assim, precisamos de analistas de negócios com boa capacidade de comunicação in-
terpessoal. Não confunda capacidade de comunicação interpessoal com uma pessoa
que vive a contar piadas ou entre brincadeiras, no mais das vezes inconvenientes.
HCIs significa habilidades de comunicação interpessoal:
“Com o aprimoramento das HCIs podemos aperfeiçoar a capacidade de ouvir (ato de
entender o que alguém quer nos dizer) em contraposição ao ato de escutar (ato mecâ-
2
nico de perceber os sons)”.
“O desenvolvimento pode abranger qualquer um dos tópicos a seguir: Desenvolver
uma forma mais efetiva de comunicação, construção de empatia com o interlocutor,
aprimorar a capacidade de se envolver mais com a realidade do interlocutor e, dessa
forma, atender melhor, aumentar a objetividade da conversa e, assim, a produtividade,
ouvir em contraposição a escutar, aperfeiçoar a capacidade de ouvir (ato de entender o
que alguém quer nos dizer) em contraposição ao ato de escutar (ato mecânico de per-
3
ceber os sons)”.

O ato de extrair Casos de Uso implica muito mais em ouvir o interlocutor do que o
de escutar. Aqui, apenas o subconsciente registrou o que escutamos e, definitiva-
mente, interessa-nos o que o consciente captou e pode reproduzir.
Capítulo 3 Caso de Uso 39

Além da capacidade de comunicação interpessoal, o analista de negócio deve con-


seguir escrever o que ouviu. Parece boba essa observação, porém já vi diversos
analistas que, colocados à frente de um papel em branco, prefeririam sair em de-
bandada a enfrentar a situação.
Outro ponto importante aqui é a capacidade de relacionamento interpessoal. Uma
pessoa pode transmitir com clareza e objetividade o que quer (comunicação inter-
pessoal), porém não consegue ‘quebrar o gelo’ para iniciar a extração do Caso de
Uso. A essa capacidade dou o nome de relacionamento interpessoal.
Quando vou iniciar uma extração de Caso de Uso, procuro saber detalhes do meu
interlocutor. Se ele gosta muito de futebol, leio todo o caderno de esportes do jor-
nal do dia, a fim de me inteirar dos lances mais importantes dos campeonatos e do
time do meu interlocutor.
Aqui, a cultura geral é, também, fator importante. Se entrar na sala de um interlo-
cutor e ver um pôster com a foto de Tiger Woods, e iniciar minha conversa com:
“Esse jogador de basquete é muito bom, não é?”, muito provavelmente, meu inter-
locutor reduzirá sua disposição de conversar comigo em 30% ou 40%. Para rever-
ter esse quadro, terei o dobro do trabalho.
O que essas habilidades tem a ver com matemática? Creio que nada.

Como extrair um Caso de Uso?


A Figura 3.1 apresenta uma sugestão de estrutura para um Caso de Uso.

Nome Referência: UC03298 – Nome do Caso de Uso


Verbo no infinitivo (informar, comprar, pagar...)
Breve Descritivo
Descrição que informa do que trata este Caso de Uso.
Pré-Condições
Descrição que informa o que é necessário acontecer para que este Caso de Uso se inicie.
Atores Envolvidos
Cenário Principal
A descrição de uma tarefa que represente o mundo perfeito, sem exceções. Verbos no presente
do indicativo ou substantivos, iniciando a frase com (Registra, Compra, Seleciona, Informa...)
Cenário Alternativo
Qualquer situação que represente uma exceção de um cenário principal. Veja o significado de
exceção mais adiante neste capítulo.
Requisitos Especiais
Qualquer situação não contemplada anteriormente. (Adjetivos), veja exemplos mais adiante.
Dados
Tipos de dados que foram encontrados durante a descrição do Caso de Uso. Aqui informamos:
texto, número, data etc., ou mesmo o tipo de dado e seu tamanho, conforme a linguagem a ser
utilizada, caso você os conheça.

Figura 3.1 Sugestão de estrutura de Caso de Uso.


40 Desenvolvendo Software com UML 2.0 – Definitivo

Observação
Analista de Negócio: ________________
Entrevistado: ______________________
Área: _____________________________
Data: ___/___/___
Versão: XPTO
Figura 3.1 Sugestão de estrutura de Caso de Uso. (Continuação)

Autores e ferramentas de modelagem UML sugerem outras seções, porém não


acho produtivo porque, quanto mais se quebra um documento em pedaços, mais
difícil fica a sua leitura.
Lembre-se de que o entrevistado deverá assinar o Caso de Uso descrito, isso faz
parte do comprometimento dele.
Dar um nome ao Caso de Uso usando um verbo no infinitivo facilitará a sua classi-
ficação. Quando você tiver 80 ou 200 Casos de Uso, verá que esse tipo de início o
ajudará muito. Com essa forma de identificação, fugimos à personalização e te-
mos uma forma uníssona de escrita de Casos de Uso. Neste ponto, pode-se infor-
mar o nome interno do Caso de Uso, como: UC03298. Nome interno é a forma
como uma outra aplicação vai se referir a esse Caso de Uso.
Uma breve descrição apenas relata qual o assunto de que aquele Caso de Uso trata.
Isso facilitará a busca de Caso de Uso por uma indexação XML, por exemplo.
Pré-condição é qualquer ação ou reação de um subsistema ou ator que possibilite a
esse Caso de Uso ter início. Relate aqui o que provoca o Caso de Uso. Pode, inclu-
sive, ser um conjunto de ações ou reações. Em algumas situações, essa seção pode
ser uma grande redundância com o nome do próprio Caso de Uso e sua breve des-
crição. Neste caso, simplesmente suprima essa seção.
Os atores envolvidos são separados por vírgula. Caso uma busca seja necessária,
esse formato trará facilidade, além de permitir que enxerguemos, logo no início,
quais atores são responsáveis por aquelas ações. Sempre o entrevistado deve estar
relacionado nessa seção como ator, e seu papel, naquele momento, deve ser claro.
Não posso conceber que você converse com alguém de serviços gerais sobre algo
que acontece no almoxarifado.
Nos cenários principais são descritas as tarefas. Cada cenário principal se refere a uma
tarefa. Você deve ser específico nessa descrição. Informações vagas como: “O cliente sele-
ciona o tipo de cadastramento e informa seus dados”, não indicam absolutamente nada.
Aqui vai uma dica – Responda as perguntas, para você mesmo:
O que é?
Para quê? ou Por quê?
Como?
Capítulo 3 Caso de Uso 41

Então, você terá um cenário principal bem descrito. Esta regra pode ter suas exce-
ções, por exemplo: quando responder para que algo serve, também obterá a res-
posta de como se usa.
A situação que acaba de ser descrita poderia ser reescrita para: “Selecione cadas-
trar-se, informando os dados de: nome, sobrenome, logradouro, complemento,
CEP, cidade, estado, DDD, telefone residencial, telefone comercial, CPF e RG, a
fim de poder efetivar compras no site”.
Informamos aqui o que o usuário do software faz, como e para quê. Pressupõe-se
que existe outra forma de cadastramento, que seria o cadastramento de beneficiá-
rios, por exemplo.
Os cenários principais não prevêem exceções. Exceção é uma coisa que é diferente
de todas as outras. O mundo perfeito é descrito no cenário principal.
Leve em consideração o seguinte exemplo: Um comprador em um site de e-com-
merce pode adicionar variados produtos a seu carrinho de compras. Adicionar e
retirar produtos do carrinho de compras é um cenário principal. Contudo, supo-
nha que exista uma regra dizendo que se o produto estiver no estado de ‘em pro-
moção do dia’, cada compra somente poderá conter cinco unidades desse produto.
Veja, isso não é um erro. É apenas algo que foge do ‘mundo perfeito’. Isso é uma
exceção. Neste caso, a situação de exceção é registrada em cenários alternativos.
Numere os cenários principais, por exemplo: 1, 2, 2.1, 2.1.1, 2.1.2, 3, 3.1 etc.
Numere os cenários alternativos, por exemplo: 2.3. Significa que este é o terceiro
cenário alternativo do cenário principal número 2. Aqui há a dependência do ce-
nário principal.
Isso facilitará a organização do Caso de Uso e o futuro script pode buscar essa nu-
meração e/ou o verbo no presente do indicativo ou substantivo e levar para uma
planilha de gerenciamento. Mostraremos um exemplo dessa planilha de gerencia-
mento de cenários e Casos de Uso mais adiante.
Requisitos especiais são descrições que não cabem em nenhuma das seções ante-
riores. Presto bastante atenção aos adjetivos declarados pelo meu interlocutor,
algo como: “Veja, esta conta tem de ter uma grande precisão! Digamos de quatro
dígitos nas casas decimais”; “Esta consulta tem de ser bem rápida, já tivemos pro-
blemas de ficar esperando minutos para obter algo que estamos pesquisando”.
No primeiro caso, o interlocutor deu-me uma indicação de precisão e, no outro, uma
indicação de desempenho. Essas informações são colocadas nos requisitos especiais.
Na seção de dados, relaciono os dados encontrados enquanto escrevia o Caso de
Uso. É interessante que informemos o tipo de dados e seu tamanho, conforme a
linguagem de programação que será adotada. No diagrama de classes, esses dados
serão atributos ou características que deverão estar destacadas. É interessante nos
preocuparmos, desde já, com esses aspectos, pois economizamos equívocos. Caso
42 Desenvolvendo Software com UML 2.0 – Definitivo

você não tenha esse conhecimento, peça a algum programador que imprima a par-
te de Data Types na ajuda da linguagem escolhida. Ali você terá uma lista bem de-
finida para consulta.
Na seção de observações, coloco informações do tipo lembretes, como – prever
Caso de Uso ‘xpto’ para abordar a situação tal, ou mesmo lembretes para colegas
ou o próprio entrevistado que prometeu fornecer um relatório que não estava dis-
ponível quando de nossa conversa inicial.
Agora, já sabemos como escrever os Casos de Uso, porém, qual é a melhor aborda-
gem? Existem várias formas de extração. Técnicas de extração em grupo, indivi-
duais etc. Já tentei, por exemplo, ouvir o interlocutor e, em seguida, ao término da
sua frase, escrever com o apoio de uma prancheta. Esse approach não funcionou
porque, a todo o momento, eu pedia ‘um instantinho’ ao interlocutor para escrever
o que acabara de ouvir. Isso irrita o interlocutor, que logo perderá a seqüência de pen-
samento e você passará a ouvir frases como: “O que eu estava dizendo mesmo?”
Passei a gravar essas conversas com um pequeno gravador e transformei a extra-
ção de Caso de Uso em uma conversa, próxima de um ‘bate-papo’. É evidente que
pedi ao meu interlocutor, com antecedência, licença para usar esse recurso, infor-
mando os motivos de minha escolha.
Inicialmente, falamos de várias coisas até ele se acostumar com o gravador, e logo
ele esquecerá que a conversa está sendo gravada e a extração do Caso de Uso se
tornará um sucesso.
Jamais use a gravação para promover reuniões de acareação do tipo: “Mas você
disse isso! Olhe aqui!”, ligando o gravador em seguida.
Para conseguirmos o recurso do comprometimento dos entrevistados, pedimos a
sua assinatura no Caso de Uso. Alguns entrevistados até pedem uma cópia. Dê a
cópia.Você perceberá que, quando passar a pedir a assinatura do entrevistado, ele
chamará mais pessoas para validar o que ele disse: “João, venha dar uma olhada
aqui, por favor, nesta descrição”. Isso é muito bom!
Se o entrevistado recusar o formato de gravações, aceite e passe para outro approach.
Fale o ‘idioma’ do entrevistado; se ele é de informática, não se acanhe em quebrar
a regra de não falar termos de informática.

As mudanças no Caso de Uso


Já vi diversos analistas e/ou programadores muito revoltados com o entrevistado
por causa de sua tendência em mudar o que já havia sido dito.
Um cenário principal ou alternativo é um requisito – saiba desde já que cada um deles,
muito provavelmente, terá um método em uma classe que possibilite a sua realização:

O que realiza um cenário é um método em uma classe.


Capítulo 3 Caso de Uso 43

Desse modo, é óbvio que isso sofrerá alterações.


Cada cenário principal, alternativo, requisito especial e, talvez, uma observação
são o que a metodologia do processo unificado chama de requisito. Relembrando:

Requisito é uma condição ou capacidade que um software deve ter.

Quando você mostrar a primeira versão do seu Caso de Uso para o seu interlocu-
tor assinar, haverá mudanças. Quando mostrar o protótipo de uma interface gráfi-
ca que atende àquele Caso de Uso, haverá mudanças. Quando mostrar o protótipo
de uma interface gráfica, com dados reais, que atende àquele Caso de Uso, tam-
bém haverá mudanças.
Dissemos que os requisitos mudam. Sim, devem mudar. Entretanto, deve-se fazer
uma observação com relação a essa frase. Os alunos têm me dito sempre: “Se o en-
trevistado pode mudar os requisitos, então ficamos na mesma, porque terminamos
um módulo e ele pode mudar desde a concepção até o modelo de dados”.
Contudo, não devemos confundir mudança de requisito com mudança de negócio
ou escopo.O que o entrevistado pode mudar é a forma como um requisito é visto,
não o negócio ou escopo. Tome muito cuidado para não permitir a alteração do
negócio ou escopo que está sendo analisado. Alteração de negócio ou escopo im-
plica novo documento Visão, novos prazos e novos preços.
Por vezes, apenas uma caixa de texto em uma interface gráfica atende a um requi-
sito, outras vezes, uma tela inteira.
A percepção do ‘tamanho’ da mudança é pessoal e sutil, ou seja, considerá-la mui-
to grande e, por isso, uma mudança de negócio, ou considerá-la pequena e, por
isso, apenas uma alteração de requisito, vai depender de uma avaliação coletiva,
que deve acontecer sempre que houver a suspeita. Registre a nova versão e qual ce-
nário foi alterado em relação à versão anterior do Caso de Uso.
Por essa razão, deve haver o campo Versão, conforme mostra a Figura 3.1. Guarde
as alterações feitas, isso faz parte da organização de que já falamos. Adiante, mos-
traremos uma planilha de exemplo para essa administração.
Quando alguém lhe pede um gerenciamento de requisitos (uma das melhores prá-
ticas de desenvolvimento, conforme anunciou o RUP), está pedindo que relacione,
numere, date, identifique os autores e as mudanças, e registre o percentual de reali-
zação daquele requisito ao longo do tempo.
Se a empresa possuir uma forma de escrita comum para registrar os requisitos, por
exemplo em um editor de texto, e conseqüente publicação na Intranet da empresa,
já teremos dado o primeiro passo nesse gerenciamento.
O primeiro benefício que aparece neste approach é que a comunicação entre os
stakeholders do projeto fica baseada nesses requisitos. Isso facilita a priorização
dos requisitos e as inconsistências são detectadas muito mais rapidamente.
44 Desenvolvendo Software com UML 2.0 – Definitivo

Afinal, quem aprova o Caso de Uso?


Ao terminar a gravação da entrevista e a descrição do Caso de Uso, passamos ao
processo de aprovação.
Esse processo começa com o colega da baia ao lado. Você pode achar que estou
brincando com esta frase, mas é a pura verdade. Jamais leve um Caso de Uso para
aprovação sem que antes um colega tenha lido o seu conteúdo. Ao término da lei-
tura, seu colega deve lhe ‘contar’ o que leu.
Se, em algum momento da leitura, ele declarou: “Ah, aqui você estava querendo
dizer...”, você já terá uma pista de que o seu Caso de Uso está escrito de forma er-
rada. Um Caso de Uso não é registrado para ser interpretado, e sim para retratar a
realidade das tarefas que compõem uma atividade.
Se o seu colega ‘contou-lhe’ o Caso de Uso descrito sem pestanejar é porque ele
está bem escrito. É evidente que ele tem de ter o documento Glossário para fazer
comparações ao longo da leitura. Informo isso para desestimulá-lo a traduzir ter-
mos no Caso de Uso. Existe um lugar para isso – o documento Glossário.
Se o seu Caso de Uso está bem escrito e passou pelo seu crivo e o de seu colega, en-
tão leve -o ao entrevistado para a sua aprovação deste. Aprovar um Caso de Uso,
significa assiná-lo fisicamente ou de forma digital.
Quando digo: “Leve-o ao entrevistado”, é claro que isso é força de expressão. Use
a Intranet da empresa, use o e-mail e peça a aprovação. Dê um prazo de retorno e
cobre no limite desse prazo.
Quando um entrevistado aprova um Caso de Uso, é interessante que ele aprove os
Casos de Uso de um conjunto de atividades afins. Não entregue Caso de Uso por
Caso de Uso, pois isso quebra a seqüência do raciocínio e faz da aprovação um
processo irritante.
Nesse ponto, você começou os testes de aceitabilidade e não precisou de nenhum
alarde. Se o entrevistado assinou o Caso de Uso, a aceitabilidade começou a ser fei-
ta no papel; depois, esse entrevistado passará a ser um usuário do software e novo
teste de aceitabilidade será feito, juntamente com os testes de usabilidade.*
Na nossa planilha de acompanhamento de Casos de Usos, teremos uma coluna
para a aceitabilidade desses casos.

* A Ergonomia trata de usabilidade e aceitabilidade. Esta matéria é estudada em disciplinas de cursos


superiores de IHC, Interface Homem-Computador. A Ergonomia, em si, é outra ciência estudada
também em cursos superiores. Para nossos fins, vamos definir aceitabilidade e usabilidade. Um
cabeleireiro pode aceitar uma cadeira de uma manicure, porque essa serve pelo menos para sentar!
Porém, o cabeleireiro não terá usabilidade essa cadeira. Aqui, a cadeira passou no teste de aceitabili-
dade, mas não no de usabilidade. Pessoas, crêem nesses testes somente para interfaces gráfica,
quando se fala em mundo computacional. Eu, como percebem, proponho a aceitabilidade desde a
descrição do Caso de Uso. Creio que aqui não cabe a usabilidade.
Capítulo 3 Caso de Uso 45

O que existe, ou como será o novo sistema?


Esta pergunta sempre me faz lembrar aquela menção: “O ovo ou a galinha?”
Vamos tentar respondê-la. Se o negócio que está sendo modelado não existe, é evi-
dente que a sua descrição será sempre a ‘do mundo como ele será’.
Se o negócio existe fisicamente, como uma loja, e o desejo do usuário contratante é o
de levar a loja para o mundo virtual, retrate a loja ‘no mundo como ele é’. Sempre que
ouvir a frase: “Gostaria que fosse diferente na Internet”, registre a forma desejada.
Assim, existirá uma mescla entre ‘o mundo como ele é’ e ‘o mundo como ele será’.
Se o negócio existe física ou virtualmente e o usuário contratante quer uma ‘nova’
forma de realizar esse negócio, afaste-se de conhecer ‘o mundo como ele é’. Não ad-
quira os vícios e preconceitos existentes. Todavia, se for imprescindível conhecer
como está o processo, não se esquive dessa oportunidade. Por vezes, você pode ler
os diagramas de um colega ou mesmo já ter algo documentado sobre o processo,
fruto de um trabalho pregresso. Aproveite o que já existe para não levar o usuário
à sensação de: “Ah, não! De novo isso”. Ademais, rever processos é sempre bom
porque você descobre erros. Creio que automatizar erros não é o desejo de nin-
guém. Portanto, tendo a oportunidade, reveja, teste e proponha modificações no
processo do usuário ao realizar uma tarefa.
O usuário não sabe e você nem precisa lhe contar, porém a UML é utilizada para a
construção de softwares orientados a objetos. Esses conceitos de: ‘o mundo como
ele é’ e ‘o mundo como ele será’, na orientação a objetos, deixam de existir e dão
lugar ao conceito de ‘o mundo em diversas formas’.
Vamos supor que ao chegar pela manhã, coloque uma caneta em uma posição so-
bre uma mesa. Chamo um analista e digo-lhe que gostaria de colocar essa caneta
em uma posição diferente.
Se esse analista tiver uma orientação muito estruturada, tentará me descrever a mesa,
a caneta, e todo o processo que faço hoje com a caneta para propiciar a mudança.
Se o analista tiver uma orientação muito essencial, tentará descrever a nova situa-
ção com todas as suas possibilidades para que a caneta resida no novo local.
Se o analista tiver uma orientação muito voltada a objetos, tentará achar uma for-
ma de colocar a caneta não só naquele local que lhe pedi, mas em qualquer lugar
da mesa.
Nenhum desses approaches está absolutamente certo ou absolutamente errado.
Lance mão do que o ajudará, ou seja, do que for necessário para conseguir colocar
a caneta em qualquer lugar da mesa, ‘o mundo em diversas formas’.

Um Caso de Uso tem somente coisas escritas?


Não! Se você precisar de um gráfico, use-o! Se a inclusão de um organograma fa-
vorecer o entendimento, inclua-o! Isso pode acontecer se o Caso de Uso descrever
46 Desenvolvendo Software com UML 2.0 – Definitivo

coisas do departamento de cargos e salários, por exemplo. Veja, isso é apenas um


exemplo e nada tem a ver com a sugestão estruturada de conhecer o organograma
de uma empresa que vamos modelar.
Se lhe foi mostrado um documento normalizado, muito provavelmente ele será
grande fonte de atributos de classes no futuro; anexe-o. Cite, no cenário principal,
esse anexo. Use vários cenários principais, se precisar. Normalmente esses docu-
mentos também são pistas para as entidades formais em banco de dados.
Se lhe foi mostrado um documento não normalizado, ou seja, o entrevistado o
criou e a ‘empresa’ não sabe da existência daquele documento, anexe-o. Faça as ci-
tações, e esses documentos também serão pistas para as entidades informais em
banco de dados. Veja o capítulo que trata de banco de dados.
Se você está pensando em guardar tudo isso com grampos de grampeadores e em
grandes arquivos, esqueça. Providencie um scanner e guarde os documentos para
uso na Intranet da empresa.
Se a descrição de uma máquina for difícil, dependendo do contexto, você pode
anexar a planta da máquina ou mesmo uma fotografia digital.
Se o que você está descrevendo envolve insumos provenientes de, por exemplo,
módulos SAP, não pense em descrever o que o módulo SAP faz. Pense em descrever os
insumos que você usará provenientes do módulo SAP em questão, como e por que.
Quando, na Intranet, alguém ler um Caso de Uso e ele se referir a um documen-
to, precisará apenas dar um clique para abrir uma nova janela e esse documento
será mostrado.

Como acompanhamos o progresso das descrições de Casos de


Uso?
O líder do projeto deve promover reuniões semanais para esse fim. No começo do
projeto, essas reuniões acontecem duas vezes por semana, para evitarmos tentar
resolver conflitos tardiamente. Conforme o projeto, elas passam a ser semanais.
Se há algum problema com determinado entrevistado ou analista, resolva-o ime-
diatamente. Não permita que o entrevistado fuja do comprometimento já citado
ou que o analista fuja de uma descrição difícil.

O diagrama de Caso de Uso (nível 1) da Visão ou <<subsistemas>>


Vamos construir o diagrama de Caso de Uso de nível 1 para a aplicação de Loca-
ção de DVDs pela Internet. Na verdade, existirão muitos mais diagramas.
Precisamos desse diagrama para podermos distribuí-los entre os analistas de negó-
cio e administrar as descrições com seus prazos e marcações de reuniões com os in-
terlocutores a serem entrevistados. A construção desse diagrama não é definitiva!
Ocorrerão mudanças; e não se espante com isso.
Capítulo 3 Caso de Uso 47

Escolhi, para esse exemplo, o Caso de Uso Locar DVD e, como conseqüência, tam-
bém pensei no Caso de Uso Cadastrar. Esses dois Casos de Uso estão no diagrama
de Caso de Uso de nível 0, veja a Figura 3.2. Observe nas figuras 3.2, 3.3 e 3.4
como esses diagramas, que representam a explosão do primeiro, ficaram.
A Figura 3.2 dá uma idéia dos Casos de Uso envolvidos em locar DVD; a Figura
3.3 mostra a primeira versão do diagrama de Caso de Uso Cadastrar.
Ao iniciar a descrição dos Casos de Uso envolvidos em Cadastrar, senti a necessi-
dade de criar novo Caso de Uso – Administrar Documentos; pois, ao se cadastrar o
cliente, é necessário apresentar alguns documentos que validem a sua admissão ao
site. O beneficiário passa pelo mesmo processo e este não é simples. Então, criei a
segunda versão desse diagrama, demonstrada na Figura 3.4. Fiz isso para mostrar
que você não tem um diagrama de Caso de Uso definitivo. Provavelmente, ao dese-
nhar esse mesmo exemplo, você tenha uma outra visão de como representá-lo.
Isso é assim, não há possibilidades definitivas aqui. Como disse Ivar Jacobson, cer-
ta vez: “Os meus Casos de Uso não são os seus Casos de Uso”. Ele se referia à escri-
ta, porém creio que isso vale para os diagramas.

Figura 3.2 Casos de Uso envolvendo o processo de locar.


48 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 3.3 Casos de Uso envolvendo o processo de cadastrar.

Figura 3.4 Casos de Uso envolvendo o processo de cadastrar, segunda versão.

Há um símbolo do qual não falei quando comentamos notação em diagramas de


Casos de Uso. Esse símbolo é o da herança. Vamos voltar a falar dele quando fa-
larmos de classes. Veja que faz sentido existir herança entre beneficiário e cliente
locador, uma situação em que é permitida a ligação entre atores. Não há beneficiá-
rio sem cliente locador. Assim, utilizei a herança, uma seta vazia apontando para o
‘pai’ da herança.
Capítulo 3 Caso de Uso 49

Alguns autores não recomendam essas simbologias nos Casos de Uso, mas veja...
Não existe conseqüência em código com base em diagrama de Casos de Uso. Ele
serve para podermos iniciar e levarmos avante o processo da abstração do negó-
cio, conforme comentamos anteriormente, nada mais.
Os diagramas de Casos de Uso são uma visão do sistema. Podem existir vários des-
ses diagramas, quantos você sinta a necessidade de criá-los. Nas figuras anteriores
deste capítulo, você vê apenas exemplos de um pedaço do software sob a perspec-
tiva de Casos de Uso.
Outra novidade é que, na segunda versão, o Caso de Uso Administrar Documen-
tos depende diretamente dos Casos de Uso Cadastrar Locador e Cadastrar Benefi-
ciário – faz sentido. Não haverá documentos se não ocorrerem cadastramentos.
Há relação de dependência, também, no diagrama de Caso de Uso referente ao
processo de Locar DVD; observe a Figura 3.2.
Além disso, inseri um ator que, por enquanto, chamo de Site. Deverá existir al-
guém do lado Back Office do site efetivando essas administrações de documentos.
Agora, podemos separar esses Casos de Uso por analista de negócio e marcar as reu-
niões de início de descrição de Caso de Uso.
É interessante que os Casos de Uso referentes ao cadastramento de cliente e de be-
neficiário, como a administração de seus documentos, fiquem com o mesmo ana-
lista. Já os Casos de Uso referentes ao negócio propriamente dito – Locar DVDs –
podem ser designados a outro analista.
Aqui, os analistas recebem as datas em que esses Casos de Uso deverão ser descri-
tos e aprovados.

Arquitetura de software
Quando falamos arquitetura de software, estamos nos referindo a diferentes vi-
sões que possibilitam decisões sobre a construção de um software. Essas visões são
os modelos de sistemas.4
Um sistema automatizado é difícil de ser visualizado, porque ele não existe no
mundo real em três dimensões.5
Os diagramas de Casos de Uso formam o modelo de Caso de Uso que faz parte da
linha base da arquitetura de software. Alguém interessado em conhecer um soft-
ware pode pedir os modelos de:
» Caso de Uso
» Análise
» Projeto
» Implantação
» Implementação
» Teste
50 Desenvolvendo Software com UML 2.0 – Definitivo

Esses modelos, em conjunto, são a Arquitetura de Software. Falaremos deste as-


sunto à medida que formos usando esses conceitos, assim como ocorreu com os
Casos de Uso.

Iniciando a descrição de Casos de Uso


Para escrevermos Casos de Uso vamos passar a outro diagrama da UML, que é um
grande tutor para quem tem dificuldade em escrever Casos de Uso. Também é
um grande tutor para quem está acostumado com a análise estruturada. Vamos
abordá-lo no Capítulo 4.

Conclusão
Vimos, neste capítulo, que Casos de Uso são a parte mais importante da constru-
ção de software, utilizando UML dentro do Processo Iterativo. Observamos que
um Caso de Uso sempre é iniciado por um Ator, e que se ele não conseguir identifi-
car um ator estará errado. Um Caso de Uso pode necessitar da participação de vá-
rios Atores; e é uma forma de abstração da complexidade.
Indicamos o perfil do profissional que pode extrair Casos de Uso e quais os meios
pelos quais um Caso de Uso pode ser extraído, a saber: observação e entrevista.
Uma sugestão de descrição foi apresentada, com as seções mais comuns de um
Caso de Uso. Existem outras seções que podem ser incluídas; cada empresa deve
adotar o seu padrão.
Um Caso de Uso deve descrever o mundo como ele é ou como ele é esperado nos
cenários principais. Os cenários alternativos descrevem alternativas para cada ce-
nário principal do Caso de Uso.
Cada cenário deve responder a três perguntas: ‘O que é?’ ‘Para que’ ou ‘Por quê?’
e, ‘Como é realizado?’
Requisitos especiais são situações que normalmente não aparecem em cenários e
podem ter relação com os adjetivos utilizados pelo entrevistado.
A seção de dados existe apenas para nortear a criação de classes. Nela estamos se-
lecionando os atributos candidatos.
Discutimos o que são requisitos e a sua capacidade de alteração.
Verificamos que um Caso de Uso deve passar por um processo de aprovação.
Demos algumas pistas de Casos de Uso mal escritos.
Imagens podem ser agregadas a um Caso de Uso. Explodimos o diagrama de paco-
tes de sistema visto no Capítulo 2, descobrindo nossos módulos principais.
Capítulo 3 Caso de Uso 51

Exercícios
1. O que é um Caso de Uso?
2. Como os cenários principais são descritos?
3. Um cenário descreve uma atividade ou uma tarefa de uma atividade?
4. Como saber se estamos escrevendo todo um Caso de Uso dentro de outro Caso de
Uso?
5. Por que um Caso de Uso deve ser aprovado?
6. Quem aprova um Caso de Uso?
7. O que pode ser relatado em uma seção de Requisitos Especiais?
8. Por que a seção de dados pode ajudar, e de que forma?
9. Devemos pensar em interface gráfica no momento da descrição de Casos de Uso? Jus-
tifique.
10. Quais são os passos para criarmos os diagramas de Casos de Uso, partindo-se do do-
cumento Visão?
Só me interessam os passos que tive de dar na vida para chegar
a mim mesmo.
HERMAN HESSE

Obras de arte, na minha opinião, são os únicos objetos no


mundo material que possuem ordem interna e isso porque,
apesar de não acreditar que só a arte importa, acredito que a
arte vale a pena pela arte.
E. M. FORSTER

S eguindo a linha do diagrama de Caso de Uso, vamos primeiro mostrar a nota-


ção do diagrama de Atividade.

A notação do diagrama de Atividades


Este símbolo representa uma Atividade. Um retângulo com os cantos
arredondados. Quando o usuário faz alguma coisa ou existe a respos-
ta do sistema, pode ser usado este símbolo.

Este símbolo representa as Passagens de uma atividade para outra. Pode-se


considerar essa passagem como um gatilho trigger, acrescentar efeitos ou resulta-
dos e apontar o efeito na ponta da seta. É possível considerar isso apenas como
um fluxo.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 53

Este é o símbolo de uma Decisão. O fato de termos quatro cantos não signifi-
ca que podemos ter somente quatro saídas. Podemos apontar diversas saídas
para o símbolo de decisão.

Este é o símbolo de Fork. Significa que uma atividade chegou neste ponto
e foi subdividida em mais de uma atividade.

Este é o símbolo de Join. Significa que mais de uma atividade chegou em


um mesmo ponto e criou-se uma nova atividade.

Este é o símbolo de Entrada. O ponto de entrada de um processo. Pode haver


diversos pontos de entrada para um processo.

Este é o símbolo de Saída. O ponto de saída de um processo. Pode haver di-


versos pontos de saída para um processo.

Este é o símbolo de Merge. O mesmo símbolo de decisão, um diamante


vazio, teve sua semântica alterada para também significar o merge a par-
tir da UML 2.0. Aqui a semântica é de que vários fluxos estão convergindo a um pon-
to e existe apenas uma saída, o que é diferente do fork, onde vários fluxos saem
concorrentemente. A diferença é a palavra concorrentemente. Se existir uma etapa do
processo que recebe de atividades diferentes, ora um resultado ora outro e que podem
chegar juntos, achamos uma utilização para o merge.

Condição. Você pode representar uma condição, na UML 2.0, es-


crevendo um texto como [pagamento atrasado], entre colchetes e
em itálico para representar determinada condição. Esse texto estará sob um fluxo, ne-
cessariamente.

Swimlanes. Literalmente, este símbolo reproduz as


raias de uma piscina. Indica a passagem do fluxo de
uma atividade entre um ator e outro. Pode ser re-
presentado na vertical, da forma como está no
exemplo, ou na horizontal, dependendo do uso.

Uma espécie de tridente, chamado de Rake (rodo), voltado para bai-


xo, dentro de uma determinada atividade indica que aquela atividade
tem subatividades ou as está invocando. Essas podem estar descritas
em outro diagrama ou mesmo em outro ponto do mesmo diagrama. No exemplo,
existe um detalhamento de Preencher Pedido. Veja que isso fica muito mais claro com
uma nota.
54 Desenvolvendo Software com UML 2.0 – Definitivo

Uma Nota pode conter qualquer comentário desejável. É interessante


comentarmos o merge, a rake, as swimlanes e, se necessário, as condi-
ções. Você pode ter uma única nota, com itens numerados, visando a
não poluir o diagrama. Os números podem aparecer em pequenos círculos, indicando
que existem comentários a respeito daquele item. É claro que, oficialmente, a UML
2.0 não fala nada de pequenos círculos com números dentro, isso é uma adequação
minha que acho interessante para facilitar a nossa vida.

Fluxo Final. Um círculo com um ‘x’ dentro indica o final de um


fluxo. Aqui é necessária uma distinção. Veja que isto não é um
ponto de saída como o representado por . O símbolo de saí-
da indica que as atividades terminaram para aquela situação, ou Caso de Uso, e vão
seguir em outro ponto, possivelmente. O final de um fluxo indica apenas que determi-
nado fluxo de atividades se encerrou naquele ponto.

A UML 2.0 trouxe Regiões de Atividades Interrompidas. Vamos supor que um pro-
duto, em um carrinho de compras, pode ser cancelado a qualquer tempo, exceto no
momento em que a compra foi finalizada e o processo de pagamento terminado. A Fi-
gura 4.1 mostra as regiões de interrupção em um retângulo com as bordas tracejadas.
Esse diagrama está simplificado apenas para fins didáticos.

Figura 4.1 Regiões de interrupção.


Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 55

A qualquer momento, dentro da região de interrupção, a atividade Cancelar Car-


rinho pode ser invocada. Não tínhamos isso até a UML 1.X, mas fazíamos exata-
mente isso. Adicionalmente, introduzimos um símbolo de uma atividade abstrata,
no nosso caso, representando um evento “Solicitou o Cancelamento da Compra”.
Esse símbolo é chamado, também, de nó de objeto, porém falamos aqui de ativida-
des e não de objetos em si. É chamado de nó de objeto, porque essa atividade será
parte do fluxo da atividade de um objeto. A seta de uma atividade abstrata parte
dela em ziguezague, como mostra a Figura 4.1.
Sinais de aceitação. São eventos que podem ser representados sendo enviados e re-
cebidos e provocam uma transição quando recebidos, assim também como o sím-
bolo de atividades periódicas. Veja o seguinte exemplo:

Figura 4.2 Periodicidade e sinais de aceitação.

1. Este é o símbolo de periodicidade; coloco-a juntamente com uma condição.


Use o símbolo de ampulheta para designar atividades que ocorrem com pe-
riodicidade.
2. Uma atividade comum;
3, 4. Um sinal enviado (3) e um sinal aceito (4) que ocorrem e geram uma transição.
5. Uma atividade comum.
A essa altura, você pode estar se perguntando por que usei regiões de interrupção
na Figura 4.1 e não eventos de aceitação. Francamente, a resposta é: “Porque
quis”. Você poderia ter usado qualquer dessas notações dando a semântica que
achasse necessária.
A UML 2.0 introduziu o significado de atividades parametrizadas, ou seja, uma
atividade pode receber e enviar um parâmetro. Isso é representado por meio de um
pequeno retângulo colado à atividade, chamado de PIN. A finalidade é que ações
recebam e gerem resultados. Provavelmente isso será figurado em métodos de clas-
ses. Apesar de não achar que este é o momento para se tratar disso, segue a propos-
ta da UML 2.0.
Veja a Figura 4.3, para a notação da atividade parametrizada.
Não estará errado se, em vez de PIN representando parâmetros (que serão utiliza-
dos por objetos), você representar a atividade enviando um fluxo diretamente para
um objeto e, deste, sair um outro fluxo para outra atividade. Basta representar o
56 Desenvolvendo Software com UML 2.0 – Definitivo

objeto como um retângulo de cantos retos. Assim, uma atividade envia uma seta
para um objeto e este envia outra seta para outra atividade. Não as utilizo porque,
neste momento, não creio que saibamos com precisão quais serão os nossos obje-
tos. Talvez em um segundo momento você venha a fazer uso dessa notação, po-
rém, na fase de levantamento de requisitos, creio que seria, no mínimo, arrogância
falarmos diretamente em objetos.

Figura 4.3 Atividades parametrizadas – PIN.

O primeiro diagrama de Atividades


Conhecendo a notação desse diagrama, podemos fazer o nosso primeiro diagrama
de atividade relativo à atividade de alugar DVDs. Como dissemos anteriormente,
vamos pensar no ponto crucial de nosso negócio, as necessidades ‘estelares’ surgi-
rão com o passar do tempo.
Nunca é demais lembrar que as notações e semânticas são usadas de acordo com a
sua necessidade. Ter em mente que devemos usar de tudo é improdutivo.
Após nossa conversa com o responsável pela parte de locações, temos bastantes in-
formações para gerar esse diagrama, como mostra a Figura 4.4, na próxima página.
A continuação dessa primeira parte está representada na Figura 4.5, na página 58.
Repeti o diagrama com base na decisão sobre se há ou não resultados na busca de
DVDs para facilitar o entendimento.
Gostaria de comentar que alguém pode argumentar que, do jeito como o diagrama
está desenhado, somente será possível o cadastramento de cliente locador que já
tenha escolhido um DVD para alugar.
Entretanto, não se esqueça de que estamos usando a abstração do processo de alu-
gar filmes em DVD e não de cadastramento. Da forma como esse processo está
modelado, caso o cliente locador escolha um DVD e não esteja cadastrado, será
possível seu cadastramento ou de um beneficiário. Caso não desejar se cadastrar,
somente restará ao cliente a alternativa de sair do processo.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 57

Figura 4.4 Primeira parte do diagrama de atividades referente à locação.


58 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 4.5 Continuação da primeira parte do diagrama de atividades referente à locação.

Outra novidade é que, no momento em que se adiciona o DVD na cesta de loca-


ção, o cliente locador pode retornar à busca e pesquisar novo DVD.
A novidade mostrada na Figura 4.6, na próxima página, é uma linha divisória que
separa o que o ator cliente locador faz das ações que o ator site faz. Essa linha divi-
sória recebe o nome de swimlanes na UML.
Você pode ter várias swimlanes para enriquecer o seu diagrama de atividades; ela
apenas define ou divide as responsabilidades de um ator para outro. Pode-se
usá-las para mostrar uma hierarquia de atividades ou um conjunto de atividades
que se subordina a outro conjunto – apesar de informarmos, anteriormente, que o
símbolo de rake é utilizado justamente para isso é que utilizo uma nota.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 59

Figura 4.6 Continuação da primeira parte do diagrama de atividades referente à locação.

Outra novidade, em termos de notação, nesse diagrama é o uso da nota. O símbo-


lo da nota é um retângulo com uma pequena dobra no canto. Esse símbolo pode
ser usado em qualquer momento e em qualquer diagrama da UML, ou seja, quem
decide quando e como usá-lo é o analista de negócio, no momento em que faz o
diagrama.
Novamente, essa segunda parte – Figura 4.6 – é uma continuação da Figura 4.5,
apenas para o seu entendimento. Na verdade, esse é um único diagrama na ferra-
menta de modelagem.
Nas setas, que já informei que podem ser apenas direcionais ou gatilhos, procurei
usar a informação de forma que agregasse alguma coisa. Dividi a informação na
seta com uma barra ‘/’. Na primeira parte dessa barra, indiquei trigger e na segun-
da parte indiquei effect.
60 Desenvolvendo Software com UML 2.0 – Definitivo

Agora que aprendemos o que é o diagrama de Atividades como nos utilizamos


dele, suas finalidades serão abordadas em seguida.
Vamos escrever o Caso de Uso referente à ação de locar DVD.

A descrição do Caso de Uso Locar DVD


Tabela 4.1 Descrição do Caso de Uso Locar DVD
UC001 Locar DVD
Breve Descritivo: Este Caso de Uso descreve o processo de locar DVD
Pré-Condições: Cliente seleciona grupos de produtos para locar
Atores: Cliente Locador, Site
Cenários Principais:
1 – Visualiza os grupos de produtos existentes, a partir de uma lista criada logo na entrada do
cliente na loja, através da descrição do grupo. Os grupos são: Infantil, Adulto, Ação/Policial,
Antigos, Romance, Comédia, Drama e todos. A opção todos indica que o cliente locador poderá
efetuar uma busca por todos os grupos existentes – Cliente Locador.
2 – Escolhe determinado tipo de grupo selecionando sua descrição – Cliente Locador.
3 – Escolhe o tipo de busca desejada a partir de uma descrição. Essa busca pode ser por: nome de
um ator, nome do diretor ou título do filme – Cliente Locador.
4 – Informa o texto relativo à busca, com mais de três caracteres – Cliente Locador.
5 – Visualiza os resultados da busca por meio de uma relação que é mostrada por aproximação do
texto pedido. A relação deve aparecer por percentual de aproximação. Os títulos com maior
aproximação deverão ser apresentados em primeiro lugar. O Cliente Locador visualiza, também,
sua percentagem de aproximação. Assim, a lista mostrada inicia em 100% e termina em 5%. Ela
deve conter 20 nomes possíveis em cada página. Junto à lista, a capa do DVD é mostrada. O cliente
locador pode ver detalhes da frente, do verso e o resumo do DVD em questão – Cliente Locador.
6 – Seleciona determinado filme e adiciona-o à cesta de locações – Cliente Locador.
7 – Deduz a quantidade do DVD escolhido do estoque de cópias – Site.
8 – Executa a busca novamente a fim de obter outros títulos – Cliente Locador.
9 – Identifica-se pelo seu CPF de cliente – Cliente Locador.
10 – Valida o CPF do cliente, certificando-se de que ele já se encontra cadastrado – Site.
11 – Seleciona o cartão de débito com base em uma lista de cartões de débito cadastrados, a fim
de permitir o débito da locação – Cliente Locador.
12 – Valida o cartão de débito do cliente locador – Site.
13 – Informa o tempo aproximado de entrega, em horas, no endereço listado pelo cliente locador
como endereço de entrega – Site.
Cenários Alternativos:
1.1 – Escolhe um filme que esteja em promoção ou lançamento, logo que entra na loja, sem
recorrer a nenhuma busca – Cliente Locador.
4.1 – Não aceita texto com menos do que três caracteres, não processa a busca. Alerta o cliente
locador – Site.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 61

Tabela 4.1 Descrição do Caso de Uso Locar DVD (Continuação)


UC001 Locar DVD
4.2 – Não aceita texto com mais do que dez caracteres, não processa a busca. Alerta o cliente
locador – Site.
5.1 – Não existindo resultado a ser exibido, permite retorno à seleção de tipo de busca – Site.
5.2 – Não existindo resultado a ser exibido, cliente locador sai da loja sem locar filmes – Site.
9.1, 10.1 – Não cadastrado, cliente locador é levado ao cadastramento. (Veja o Caso de Uso
Cadastrar.) – Site.
11.1 – Informa novo cartão de débito, para ser incluído na relação de cartões existentes – Cliente
Locador.
11.2 – Retira um cartão de débito da relação de cartões existentes – Cliente Locador.
12.1 – Identifica cartão inválido, pede providência do cliente para regularização – Site.
12.2 – Adiciona a quantidade do DVD escolhido ao estoque de cópias, devido a não locação – Site.
13.1 – Altera o endereço de entrega – Cliente Locador.
Requisitos Especiais:
1 - Deve ser adicionado ou deduzido do número disponível de cópias no estoque, imediatamente
após a ação que provocar uma dessas situações.
2 - O cliente locador pode abandonar a loja a qualquer momento.
Observação: Prever Caso de Uso Controlar Estoque, Entregar Locação, Cadastrar Cliente Locador.
Analista de Negócio: XPTO
Entrevistado: José Manoel
Área: Direção de Lojas
Data: 12/04/2004
Versão: 1.0

Vamos fazer algumas observações sobre esse Caso de Uso Locar DVD e o diagra-
ma de Atividades.

O diagrama de Atividades é imprescindível?


Em princípio, veja que nem todos os cenários estão retratados no diagrama de Ati-
vidades. Como exemplo, o cliente locador poderá sair da loja a qualquer momento
que desejar, mesmo que tenha adicionado produtos à sua cesta. Poderíamos ter re-
presentado essa ação no diagrama de Atividades, de outras formas, porém, isso
poderia deixar o diagrama ilegível, devido ao grande número de linhas cruzadas
que apareceriam. Alternativamente, poderia ter introduzido regiões de interrup-
ção, mas sou rebelde e não quis.
62 Desenvolvendo Software com UML 2.0 – Definitivo

O diagrama de Atividades existe para ajudá-lo a criar boas descrições de Caso de


Uso, mostrar uma situação por meio de vários Casos de Uso ou ajustar dúvidas surgi-
das no diagrama de classes ou objetos, que veremos adiante.
Você poderia ter adotado o approach de escrever o Caso de Uso diretamente, sem
a necessidade de criar um diagrama de atividades. No mundo real, dificilmente
você terá tempo de fazer diagramas de Atividades para todos os processos visuali-
zados nos diagramas de Casos de Uso.
O diagrama de Atividades é muito interessante para pessoas que estão acostuma-
das com o diagrama de fluxo de dados (DFD) da análise estruturada e, assim, este
serve como um tutor.
Contudo, procure utilizá-lo, somente em cenários complexos, em que o negócio a
ser modelado é de difícil compreensão. Porém, se sua empresa tiver como norma
gerar este diagrama, obrigatoriamente, como produto da UML, faça-o.

Cenário mal-escrito
Outro exemplo é o de um cenário mal-escrito – veja o exemplo do cenário princi-
pal 5. Muito está dito, mas sem os detalhes necessários. Quando o cliente locador
vê um DVD em detalhes, o que ele vê exatamente? O cenário principal informa
que: “Junto à lista, a capa do DVD é mostrada. O cliente locador pode ver detalhes
da frente, do verso e o resumo do DVD em questão – Cliente Locador”.
As questões aqui são: “O que é mostrado na capa?” “É uma cópia fiel da capa ori-
ginal do DVD?” “Quais são esses detalhes que o cliente locador pode ver?”
Esse cenário principal poderia ser alterado, nessa frase, para: “Junto à lista, resul-
tado da pesquisa, o cliente locador vê uma cópia fiel da frente da capa do DVD,
por meio de uma figura. Ele pode visualizar detalhes como: nome do filme, rese-
nha (texto de até 200 caracteres), atores principais e coadjuvantes, prêmios recebi-
dos, quantas vezes esse DVD foi alugado, críticas de dois jornais, ano de lançamento
e opinião de até dez locadores desse DVD (texto de até 200 caracteres)”.
Outros detalhes poderiam ser acrescidos, isso vai depender da abstração requerida
pelo negócio. Poderíamos ter, por exemplo, gráficos de uma mão fazendo o sinal
de positivo ou negativo, seguidos de percentuais que indicariam a reciprocidade
dos locadores ao filme em questão.
Assim, com essa alteração na descrição do cenário, o programador tem mais insu-
mos para fazer o seu trabalho do que no texto original.
Ao alterar um cenário, foi alterada a versão da descrição do Caso de Uso. Informe
a nova numeração da versão e indique, em um campo adicional, qual cenário foi
alterado em relação à versão anterior.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 63

Lembre-se, todos os cenários terão algo que possibilite àquele cenário transformar-se
em código de programação. Pense que cada cenário equivalerá a uma ação em termos
de programa. Os cenários são ‘orientadores’ e não ‘orientados’ para os programado-
res de linguagens de computador.

Pensamos em interface gráfica nesse momento?


No exemplo do Caso de Uso Locar DVD, não me preocupei com a interface gráfi-
ca que implementará esses cenários. Não sei se será apenas uma janela ou várias.
Preocupei-me apenas com o negócio em si. Veja que não citei botões, combo box,
list box etc.
Quando você está nessa fase, creio que é um erro abordar o assunto de interface
gráfica, pois está aprendendo a escrita do negócio com o entrevistado, não em tes-
tes de aceitabilidade e usabilidade de interfaces gráficas.
Esta antecipação pode gerar alguns problemas. Vou relatar duas situações pelas
quais passei ao descrever Casos de Uso.

Primeira situação
Durante a descrição do Caso de Uso, preocupei-me em esboçar a interface gráfica
para o entrevistado, a fim de queimar etapas. Quando da transformação daquele
Caso de Uso em código, descobri que era impossível atendê-lo com a interface que
havia pensado. Isso gerou um constrangimento, pois tive de retornar ao entrevista-
do e atestar minha incompetência em gerar interfaces gráficas.
O entrevistado já havia criado uma visão mental daquela interface, instigado por
mim! Tive um bom trabalho para convencê-lo a desistir da idéia inicial.
Moral da história: Deixe os Web designers fazerem aquilo que eles sabem fazer de
melhor, não gere expectativas que você não sabe se poderão ser atendidas.

Segunda situação
Falei com um entrevistado que tinha muita facilidade com informática e, enquanto
conversávamos, ele ia esboçando as interfaces gráficas que achava que o atenderiam.
Nesse caso, acolhi suas sugestões, mas não me comprometi diretamente com a
idéia de que a realidade seria uma réplica daquilo. Graças a Deus! Até que enfim,
eu havia aprendido!
Algumas interfaces ele havia melhorado em um editor gráfico, para que eu tivesse
certeza do que ele queria!
Separei o material e pedi ao web designer que atendesse àquelas sugestões, sempre
que possível. Para o que não pudesse ser feito, eu gostaria de ter uma justificativa,
pois iria contra-argumentar com o entrevistado.
64 Desenvolvendo Software com UML 2.0 – Definitivo

Realmente, algumas sugestões eram perfeitas e outras foram melhoradas pelo web
designer. Quando tive uma alternativa palpável de interface gráfica, voltei ao en-
trevistado e foi mais fácil o convencimento.
Moral da história: Não tolha a iniciativa do entrevistado em se expressar. Você
pode estar perdendo uma grande oportunidade de melhorar o seu relacionamento
e a sua habilidade de comunicação interpessoal. No entanto, tenha cuidado ao
criar ou aceitar a criação de interfaces gráficas na fase de levantamento de requisi-
tos. Você pode estar pensando em algo impossível.

Estilo do Caso de Uso


Veja que respeitei a nomenclatura e o estilo propostos no modelo do Capítulo 2,
porém existem situações em que isso pode tornar-se impossível, pois a escrita fica-
ria inútil. Os cenários alternativos 9.1 e 10.1 são exemplos disso.
Procure evitar sair do estilo proposto. Quanto mais nos afastamos do estilo, mais di-
ficultamos a aplicação que deverá buscar os cenários e nos permitir o seu gerencia-
mento. O melhor lugar para você guardar o estilo de Casos de Uso de sua empresa é
no documento Nomenclatura.
Um Caso de Uso não está terminado na primeira escrita. Olhando novamente o
diagrama de Atividades, falando com um colega ou mesmo conversando nova-
mente com o entrevistado, podemos sentir a necessidade de alterar a descrição do
Caso de Uso. Alterada a descrição, verifique a necessidade de rever o diagrama
de Caso de Uso pertinente àquele cenário.
Ao indicar o ator que realiza o cenário, preferi fazê-lo ao final dos cenários, para
ficar dentro do estilo proposto e facilitar a aplicação de gerenciamento de requisi-
tos ou cenários.

Requisitos x cenários
Para que não haja dúvida sobre o que é requisito e o que é cenário, vamos ao exem-
plo. Observe o cenário principal 1 do Caso de Uso Locar DVD:
“Visualiza os grupos de produtos existentes, a partir de uma lista criada logo na
entrada do cliente na loja, através da descrição do grupo. Os grupos são: Infantil,
Adulto, Ação/Policial, Antigos, Romance, Comédia, Drama e todos. A opção to-
dos indica que o cliente locador poderá efetuar uma busca por todos os grupos
existentes – Cliente Locador”.
O próprio cenário é um requisito, ele deve ser atendido no futuro software. Contu-
do, as descrições como “Infantil, Adulto, Ação/Policial, Antigos, Romance, Co-
média, Drama e todos”, para os grupos, são também requisitos.
Inicialmente, havia proposto que fossem respondidas três perguntas ao se escrever
cenários principais:
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 65

O que é?
Para quê? ou Por quê?
Como?
Quase sempre, quando detalhamos o ‘como se usa’, estamos especificando requisi-
tos que deverão existir no software. Nesse exemplo, como os grupos são visualiza-
dos? Pela descrição dos grupos, que podem ser: Infantil, Adulto, Ação/Policial,
Antigos, Romance, Comédia, Drama e todos.
Existem, finalmente, outros estilos de escrita de Caso de Uso. Aqui ficou uma su-
gestão que se aproxima do jeito RUP de escrever Casos de Uso.
Vamos escrever o Caso de Uso relativo ao cadastramento, desta vez, sem a ajuda
do diagrama de Atividades.

As descrições de Casos de Uso, em versão final

UC001 Locar DVD


Breve Descritivo: Este Caso de Uso descreve o processo de locar DVD.
Pré-Condições: Cliente seleciona grupos de produtos para locar.
Atores: Cliente Locador, Cliente Beneficiário, Site.
Cenários Principais:
1 – Visualiza os grupos de produtos existentes, a partir de uma lista criada logo na entrada do
cliente na loja, através da descrição do grupo. Os grupos são: Infantil, Adulto, Ação/Policial,
Antigos, Romance, Comédia, Drama e todos. A opção todos indica que o cliente locador poderá
efetuar uma busca por todos os grupos existentes – Cliente Locador, Cliente Beneficiário.
2 – Escolhe determinado tipo de grupo selecionando sua descrição – Cliente Locador, Cliente
Beneficiário.
3 – Escolhe o tipo de busca desejada, a partir de uma descrição. Esta busca pode ser por: nome de
um ator, nome do diretor ou título do filme – Cliente Locador, Cliente Beneficiário.
4 – Informa o texto relativo à busca, com mais de três caracteres – Cliente Locador, Cliente
Beneficiário.
5 – Visualiza os resultados da busca através de uma relação. A relação é mostrada por aproximação
do texto pedido. A relação deve aparecer por percentual de aproximação. Os títulos com maior
aproximação deverão ser apresentados em primeiro lugar. O cliente locador visualiza, também, o
percentual de aproximação. Assim, a lista mostrada inicia em 100% e termina em 5%. A lista deve
conter 20 nomes possíveis em cada página. Junto à lista, resultado da pesquisa, o cliente locador
vê uma cópia fiel da frente da capa do DVD, por meio de uma figura. Ele pode visualizar detalhes
como: nome do filme, resenha, atores principais e coadjuvantes, prêmios recebidos, quantas vezes
esse DVD foi locado, críticas de dois jornais, ano de lançamento e opinião de até dez locadores
desse DVD – Cliente Locador, Cliente Beneficiário.
6 – Seleciona determinado filme, por meio da descrição, e adiciona-o à cesta de locações – Cliente
Locador, Cliente Beneficiário.
7 – Deduz a quantidade do DVD escolhido do estoque de cópias – Site.
8 – Executa a busca novamente a fim de obter outros títulos – Cliente Locador, Cliente Beneficiário.
66 Desenvolvendo Software com UML 2.0 – Definitivo

(Continuação)

UC001 Locar DVD


9 – Identifica-se, por meio de seu login e senha do cliente locador ou cliente beneficiário – Cliente
Locador, Cliente Beneficiário.
10 – Valida o login do cliente locador ou do cliente beneficiário, certificando-se de que ele já se
encontra cadastrado, e verifica se o cliente locador está em estado de “Aprovado para Locação”.
(Ver Caso de Uso Controlar Estado de Cliente Locador e Cliente Beneficiário.) – Site.
11 – Informa o número do cartão de débito para permitir o débito da locação – Cliente Locador.
12 – Valida o cartão de débito informado – Site.
13 – Informa o tempo aproximado de entrega, em horas, no endereço listado pelo cliente locador
como endereço de entrega – Site.
Cenários Alternativos:
1.1 – Escolhe um filme que esteja em promoção ou lançamento, logo que entra na loja, sem
recorrer a nenhuma busca. (Ver Caso de Uso Administrar Promoções.) – Cliente Locador, Cliente
Beneficiário.
4.1 – Não aceita texto com menos de três caracteres, não processa a busca. Alerta o cliente locador
– Site.
4.2 – Não aceita texto com mais de dez caracteres, não processa a busca. Alerta o cliente locador –
Site.
5.1 – Não existindo resultado a ser exibido, permite retorno à seleção de tipo de busca – Site.
5.2 – Não existindo resultado a ser exibido, cliente locador, ou cliente beneficiário, sai da loja sem
locar filmes – Cliente Locador, Cliente Beneficiário.
9.1, 10.1 – Não cadastrado, cliente locador, ou cliente beneficiário, é levado ao cadastramento. (Ver
Caso de Uso Cadastrar Cliente Locador e Cadastrar Cliente Beneficiário.) Caso o login ou a
senha apresentem problemas, solicita nova digitação – Site.
10.1 – Caso o cliente locador não esteja no estado de “Aprovado para Locação”, pode entrar em
contato com a loja, via fax, e-mail ou telefone para solicitar alteração de estado – Cliente Locador.
12.1 – Identifica cartão inválido, pede providência do cliente para regularização – Site.
12.2 – Adiciona a quantidade do DVD escolhido ao estoque de cópias, devido a não locação – Site.
13.1 – Altera o endereço de entrega. Se desejar alterar o endereço de entrega, o cliente locador deve
enviar novo comprovante de endereço, que deve estar no nome do cliente locador – Cliente Locador.
Requisitos Especiais:
1 - Deve ser adicionado ou deduzido do número disponível de cópias no estoque, imediatamente
após a ação que provocar uma dessas situações.
2 - O cliente locador, ou o cliente beneficiário, pode abandonar a loja a qualquer momento.
Dados:
Descrição de grupos de produtos: Texto 50
Nome do filme: Texto 100
Resenha: Texto 200
Nome do ator principal: Texto 100
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 67

(Continuação)

UC001 Locar DVD


Nome do ator coadjuvante: Texto 100
Nome do prêmio: Texto 50
Quantidade de locações: Número 3
Críticas recebidas: Texto de 200
Ano de lançamento do filme: Texto 4
Opinião de leitores: Texto 200
Login do cliente locador ou beneficiário: Texto 10
Estado do cliente locador ou beneficiário: Numero 1
Nome do cartão de débito: Texto 50
Número de cartão de débito: Texto 37
Banco do cartão de débito: Texto 5
Agência do cartão de débito: Texto 5
Tempo de entrega: Texto 15
Observação: Prever Caso de Uso Controlar Estoque, Entregar Locação, Cadastrar Cliente
Locador, Controlar Estado de Cliente Locador e Cliente Beneficiário, Fidelizar Cliente
Locador e Cliente Beneficiário.
Analista de Negócio: XPTO
Entrevistado: José Manoel
Área: Direção de Lojas
Data: 12/04/2004
Versão: 1.1 – Alterados os cenários principais 5 e 10, com os respectivos cenários alternativos.

UC002 Cadastrar Cliente Locador


Breve Descritivo: Este Caso de Uso descreve o processo de cadastramento do Cliente Locador.
Pré-Condições: Cliente informa a sua intenção de se cadastrar como Cliente Locador.
Atores: Cliente Locador, Site.
Cenários Principais:
1 – Informa login e senha desejada. O login e a senha devem conter letras e números e ter no
mínimo seis caracteres.
2 – Informa os seguintes dados: Nome (100 char.), Data de Nascimento (10 char.), Estado Civil
(1 num.), RG (10 char.) , CPF (11 char.), Logradouro (100 char.), CEP (9 char.), Bairro (50 char.), UF
(Escolhe de uma lista os possíveis) (2 char.), Cidade (Escolhe de uma lista as possíveis) (100 char.),
País (Brasil), Número de Dependentes (2 num.) para efetivar locação, e-mail para contato
(100 char), Telefone comercial (100 char), Telefone residencial (100 char). O país Brasil deve vir
selecionado, estará inicialmente em uma lista de escolha, prevendo-se a expansão da loja de
locações. Somente são permitidos cadastramentos de clientes em UFs e cidades que tenham
franquias da loja de locação, a fim de permitir a entrega – Cliente Locador.
68 Desenvolvendo Software com UML 2.0 – Definitivo

(Continuação)

UC002 Cadastrar Cliente Locador


3 – Informa os dados dos aparelhos de DVD que possui (Marca, Modelo, Ano de Fabricação) –
Cliente Locador.
4 – Informa se permite o envio de material de divulgação e News da loja de locação, através da
seleção de assuntos pertinentes à News da loja. (Ver Caso de Uso Administrar Textos para
Clientes.) – Cliente Locador.
5 – Envia por fax ou e-mail, cópia de um comprovante de residência. (Ver Caso de Uso Administrar
Documentos.) – Cliente Locador.
6 – Escolhe se deseja cadastrar Beneficiários para futuras locações da loja. (Ver Caso de Uso
Cadastrar Beneficiários.) – Cliente Locador.
7 – Altera estado de cliente locador para “cliente em análise”. O cliente em estado de “cliente em
análise” não poderá efetivar locação – Site.
8 – Providencia envio de e-mail para cliente em status de “cliente em análise”, informando o
cadastramento e solicitando que aguarde contato – Site.
Cenários Alternativos:
1.1 – Caso o login já esteja em uso por outro cliente locador, a situação deve ser informada ao
cliente em cadastramento e devem ser sugeridos até cinco logins possíveis a partir da combinação
do nome do cliente com os dois primeiros e dois últimos números de seu CPF – Site.
1.1 – Caso o login ou senha tenha menos do que seis caracteres com a combinação de número e
letras, a situação deve ser informada ao cliente em cadastramento e devem ser sugeridos até cinco
logins possíveis, a partir da combinação do nome do cliente com os dois primeiros e os dois
últimos números de seu CPF – Site.
2.1 – Os dados de CPF são testados quanto a sua validade e também quanto a sua regularização
através da pesquisa disponibilizada pela Receita Federal. Caso apareça invalidade de CPF ou
situação irregular na consulta à Receita Federal, o cliente é informado que existem inconsistências
no número ou na situação do CPF. Deve ser solicitada a regularização. O nome informado pelo
cliente deve ser igual ao que consta na Receita Federal. Caso haja inconsistência aqui, essa
diferença deve ser informada ao cliente e feita conseqüente solicitação de correção.
2.2 – Caso o cliente locador esteja em localidade não coberta pela loja, é informado se existe
previsão de expansão da loja para aquela localidade – Site.
2.4 – Após o cadastramento inicial, o cliente recebe um e-mail informando seu estado de “em análise”
(CP 4 e cenários alternativos respectivos), e um texto solicitando que aguarde contato posterior.
3.1 – Caso seja informado um aparelho de DVD que venha apresentando problemas para reprodução
de DVDs, o cliente locador deve ser informado e concordar (pela leitura de um texto) que a loja de
locação não se responsabiliza por mau funcionamento apresentado por aqueles tipos de aparelhos.
7.1 – Após análise de comprovante de residência, o cliente poderá ir para o estado de “Aprovado
para Locação”, “Pendente” ou “Reprovado para Locação” (Ver Caso de Uso Controlar Estado de
Cliente Locador e Cliente Beneficiário).
Requisitos Especiais:
Observação: Prever Caso de Uso Administrar Textos para Clientes.
Analista de Negócio: XPTO
Entrevistado: José Manoel
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 69

(Continuação)

UC002 Cadastrar Cliente Locador


Área: Direção de Lojas
Data: 12/04/2004
Versão: 1.0

UC003 Cadastrar Cliente Beneficiário de Cliente Locador


Breve Descritivo: Este Caso de Uso descreve o processo de cadastramento de Cliente Beneficiário
de Cliente Locador.
Pré-Condições: Cliente informa a sua intenção de se cadastrar um beneficiário para efetivar
locação na loja.
Atores: Cliente Locador, Site.
Cenários Principais:
1 – Identifica-se por meio de login e senha adquirida – Cliente Locador.
2 – Informa login e senha desejada para o beneficiário. O login e a senha devem conter letras e
números e ter no mínimo seis caracteres.
3 – Informa os seguintes dados do beneficiário: Nome (100 char.), Data de Nascimento (10 char.),
e-mail (100 char) para contato. Os telefones e endereços para entrega de locação serão os do
Cliente Locador. Não é permitido o cadastramento de clientes beneficiários fora do endereço do
cliente locador. Os dados de documentação (CPF – RG – Comprovantes de Endereço), devem ser
os do cliente locador e não os do cliente beneficiário – Cliente Locador.
4 – Informa se permite o envio de material de divulgação e News da loja de locação ao cliente
beneficiário, através da seleção de assuntos pertinentes a News da loja. (Ver Caso de Uso
Administrar Textos para Clientes.) – Cliente Locador.
5 – Informa se concorda em se responsabilizar pelos danos causados pelo cliente beneficiário,
conforme texto. (Ver Caso de Uso Administrar Textos para Clientes.)
Cenários Alternativos:
1.1 – Caso o login já esteja em uso por outro cliente locador, a situação deve ser informada ao
cliente em cadastramento e devem ser sugeridos até cinco logins possíveis a partir da combinação
do nome do cliente com os dois primeiros e dois últimos números de seu CPF.
1.2 – Caso o login ou senha tenha menos que seis caracteres com a combinação de número e
letras , a situação deve ser informada ao cliente locador e devem ser sugeridos até cinco logins
possíveis a partir da combinação do nome do cliente beneficiário com os dois primeiros e dois
últimos números do CPF do cliente locador.
1.3 – Caso o Cliente Locador não esteja no estado de “Aprovado para Locação”, ele não poderá
cadastrar novos beneficiários. Imediatamente após o cadastramento, o cliente beneficiário estará
apto para efetivar locações. A alteração de estado de um cliente locador atinge todos os
beneficiários dependentes daquele cliente locador – Site.
Requisitos Especiais:
Observação:
70 Desenvolvendo Software com UML 2.0 – Definitivo

(Continuação)

UC003 Cadastrar Cliente Beneficiário de Cliente Locador


Analista de Negócio: XPTO
Entrevistado: José Manoel
Área: Direção de Lojas
Data: 12/04/2004
Versão: 1.0

Os diagramas de Casos de Uso revisados


Vejamos, agora, como ficaram nossos diagramas de Casos de Uso referentes ao
processo de locar DVD e cadastrar clientes locadores e beneficiários. São dois dia-
gramas que já havíamos abordado no Capítulo 3, Caso de Uso.

Figura 4.7 Casos de Uso envolvendo o processo de locar DVD, segunda versão.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 71

Figura 4.8 Casos de Uso envolvendo o processo de cadastrar locador e beneficiário, terceira
versão.

De todos esses Casos de Uso estão descritos apenas três: Cadastrar Cliente Loca-
dor, Cadastrar Cliente Beneficiário, Locar DVD.
Veja que enquanto estive descrevendo os três Casos de Uso, referidos no parágrafo
anterior, descobri várias necessidades. Essas novas necessidades foram agregadas
aos diagramas de Casos de Uso respectivos. Compare os diagramas do Capítulo 3
com esses que resultaram das nossas descrições.
Por essa razão, abordei a necessidade de primeiro criarmos um pré-projeto (veja a
Introdução desse texto) para só então entregarmos expectativas de prazos e preços.
Pensei na parte mais delicada do futuro software, que é a essência do negócio em
questão – Locar DVD – e, a partir daí, consegui agregar necessidades como as de
cadastros. Depois, pude ter uma visão muito melhor do processo, seu tamanho e
complexidade. Quando fiquei satisfeito com as minhas principais descrições, sen-
ti-me à vontade para alterar os diagramas, observar suas ‘famílias’ ou ‘módulos’
ou grupos de Casos de Uso, por usuário, e separar as futuras entrevistas.
Surgirem novos Casos de Uso, como deixarem de existir, são coisas absolutamente
normais. O mais comum é que o analista de negócio, ao descrever seus Casos de
Uso, descubra a obsolescência de alguns e proponha novos Casos de Uso.
Com relação à descrição, nunca é demais frisar que seus Casos de Uso não são de
mais ninguém. Por essa razão, quando alguém for escrever o mesmo Caso de Uso a
que você se dedicou, talvez proponha um approach totalmente novo. Isso é muito
normal. Daí a importância de, antes de pedir a aprovação do seu entrevistado, re-
partir a leitura dos seus Casos de Uso com um colega.
Se ele relatar o que você escreveu, sem problemas, seu Caso de Uso estará correto
(veja o tópico: “Afinal, quem aprova o Caso de Uso?”, no Capítulo 3).
72 Desenvolvendo Software com UML 2.0 – Definitivo

Não economize em relatar regras de negócios, como tamanhos de campos e tipos


de dados. São informações importantes para o programadores e uso futuro.

A planilha de acompanhamento de descrições de Casos de Uso


Poderíamos desenvolver uma planilha de administração desses Casos de Uso, a
fim de acompanharmos seu progresso. Você deve incrementar o modelo proposto
para as suas finalidades. O objetivo aqui é o acompanhamento geral, em termos de
agenda, do progresso dos Casos de Uso.

Casos de Usos do Processo: Locar DVD


Caso de Uso Responsável DT Início da Entrevistados DT Finalização – Observação
Análise Descrição
Locar DVD Analista 1 12/04/2004 1 13/04/2004
Fidelizar Cliente Analista 1 12/04/2004 1 13/04/2004
Entregar DVD Analista 1 12/04/2004 1, 2, 3 13/04/2004
Administrar Analista 1 13/04/2004 2, 3, 4 14/04/2004
Promoções
Controlar Estado Analista 2 13/04/2004 1, 2, 3, 4 14/04/2004
de Cliente e
Beneficiários
Fidelizar Cliente Analista 1 13/04/2004 1, 2, 3, 4 14/04/2004
Controlar Estoque Analista 1 13/04/2004 2, 3, 4 14/04/2004

Casos de Usos do Processo: Cadastrar Clientes Locadores e Beneficiários


Caso de Uso Responsável DT Início da Entrevistados DT Finalização Observação
Análise – Descrição
Cadastrar Cliente Analista 2 13/04/2004 1, 2, 3, 4 14/04/2004
Locador
Cadastrar Cliente Analista 2 13/04/2004 1, 2, 3, 4 14/04/2004
Beneficiário
Administrar Analista 2 14/04/2004 1, 2, 3, 4 14/04/2004
Documentos
Administrar Analista 2 14/04/2004 1, 2, 3, 4 14/04/2004
Textos para
Clientes

Creio que os únicos comentários pertinentes aqui são:


» Ajuste as colunas para as necessidades de sua empresa.
» Essa planilha é uma ferramenta gerencial. Podemos administrar tempos, avaliar
empecilhos causados por analistas ou entrevistados.
Capítulo 4 Diagrama de Atividades e Descrição dos Casos de Uso 73

» Temos uma visão rápida sobre o andamento geral dessa fase de levantamentos
de requisitos ou requerimentos.
» Você pode ter planilhas mais detalhadas ainda. São as que tratam cada cenário
dentro de um Caso de Uso. Você pode perseguir um requisito desses desde sua
concepção até a implantação.

Conclusão
Vimos que a importância do diagrama de Atividades é relativa. Isso vai depender
da capacidade de abstração de cada um para isolar áreas de interesse em um negó-
cio. A descrição de Caso de Uso é uma tarefa que deve passar pelo crivo de mais de
um analista, antes de ser submetida à aprovação de um usuário. As mudanças em
diagramas de Caso de Uso são normais na fase de levantamento de requisitos ou
requerimentos. Os ajustes feitos nos Casos de Uso, ou pelo entrevistado ou pelo
analista, devem ser registrados em diferentes versões. Guarde seus documentos de
Casos de Uso em um repositório do tipo CVS (Concurrent Version System), veja a
área de referências1, 2. Você pode e deve administrar o andamento das descrições
de Casos de Uso; sugeri uma planilha para esse fim. Como referência geral para
este capítulo, indico a leitura de outros trabalhos sobre a escrita de Casos de Uso. 3

Exercícios
1. O que é o diagrama de Atividades na UML? Explique o seu uso.
2. Um fork, dentro do diagrama de atividades, pode viver sem um join?
3. Qual a utilidade das swimlanes?
4. Como podemos representar textualmente uma condição no diagrama de Atividades?
5. Se queremos representar subatividades, qual a notação que utilizamos?
6. Se temos uma determinada atividade que pode ocorrer em qualquer momento no dia-
grama de Atividades, como podemos representá-la?
7. Se uma atividade é temporal, qual a notação que utilizamos para representá-la?
8. Qual é a semântica de um PIN, dentro do diagrama de Atividades na UML 2.0?
9. É recomendável que utilizemos a ferramenta de modelagem UML para descrever Ca-
sos de Uso?
10. Podemos escrever Casos de Uso sem o diagrama de Atividades?
11. Como detectar um cenário mal escrito?
12. Por que é perigoso pensarmos em interfaces gráficas ao escrevermos Casos de Uso?
13. Qual o melhor lugar para consultarmos o estilo de Caso de Uso que a empresa adota?
14. Qual a correlação que existe entre requisito e cenário?
15. Durante as descrições de Casos de Uso, os diagramas de Casos de Uso podem ser revistos?
No caráter, na conduta, no estilo, em todas as coisas, a
simplicidade é a suprema virtude.
LONGFELLOW, HENRY WADSWORTH

A vida só pode ser compreendida olhando-se para trás; mas só


pode ser vivida olhando-se para a frente.
SOREN KIERKEGAARD

F azer o diagrama de classes é, sem dúvida, a parte mais esperada e desejada


para quem constrói softwares orientados a objetos. Essa expectativa procede
porque é no diagrama de classes que começamos a sair da parte exclusivamente de
negócios e passamos a tornar realidade a automatização desejada do negócio.
Nos diagramas anteriores, logo no início do capítulo, falei sobre a notação, mos-
trando todos os símbolos, porém, o diagrama de classes é vasto e, por conta disso,
mostrarei a notação juntamente com seus usos. Assim, informo um símbolo e, em
seguida, seu conceito e sua aplicabilidade.
O diagrama de classes é o que tem o maior número de símbolos em uma UML. Isso
se deve ao fato de que ele não é uma invenção da UML. Ele é proposto por diversos
autores e há muitos anos. O problema é justamente esse: Tínhamos várias formas
de fazer o diagrama de classes, pois cada autor trazia a sua visão pessoal.
Creio que todas as melhores formas foram agregadas a UML e, por isso, a babel
de diagramas deixou de existir após a UML. Agora, vamos entender os conceitos
gerais do diagrama de classes e, em seguida, no Capítulo 6, vamos fazê-lo.
Capítulo 5 Teoria de Classes 75

O que é uma classe?


Ainda não encontrei uma melhor forma de explicar o que é uma classe, para meus
alunos, do que a seguinte analogia: “Imagine que eu seja um engenheiro civil. Tive
a incumbência de construir um prédio de apartamentos. Todos os apartamentos
serão rigorosamente iguais, baseados em uma planta que anteriormente já esclare-
cia o número de dormitórios, portas, louças sanitárias, fiação elétrica e disposição
hidráulica”.
A planta dos apartamentos é a classe. Os apartamentos são os objetos baseados
naquela classe.

Instância de uma classe


A criação de um objeto, baseado em uma classe, recebe um nome especial: instância.
Quando instanciamos objetos de uma classe, criamos esses objetos na memória.
As linguagens de programação efetuam essa instância de formas diferentes, porém,
todas as boas linguagens de programação têm uma função especial que cuida da ins-
tância dos objetos – ela é chamada de construtora. Nela, todas as inicializações neces-
sárias ao objeto são realizadas, assim que um objeto é instanciado na memória.
Todas as ações necessárias para se tirar um objeto da memória são executadas na
função destrutora da classe. A função construtora, recebe o nome da classe a que
pertence. No caso da função destrutora esta recebe o mesmo nome só que precedi-
do de til ‘~’ como em C++. Java não tem uma função destrutora, porque isso é feito
de forma automática, por meio de uma tecnologia conhecida como ‘Coleta de Li-
xo’, ou Garbage Collection; mesmo assim, sempre é possível se criar uma função
com o nome de finalize, em Java, que ‘tenta’ ou ‘sugere’ que seja feita a limpeza
para classes mais complexas.1
Suponhamos que temos, então, a classe Apartamento, responsável pela instanciação
de objetos tipo Apartamento na memória. O apartamento 1323 é uma instância
na memória da classe Apartamento.

Objeto e classe, qual é mesmo a diferença?


Vimos que um objeto é uma instância de uma classe, porém, talvez isso seja uma
explicação complicada de se entender. Vamos tentar melhorar.
Um objeto é qualquer coisa que tenha seus limites bem definidos. Uma nuvem, tem
seus limites conhecidos, então, uma nuvem é um objeto, assim como uma mesa,
uma cadeira, um piso, uma porta, um teto, um apartamento, um prédio etc.
Uma classe não tem seus limites bem definidos. Ela não existe, senão em uma folha
de papel, como a planta dos apartamentos citados.
Outra distinção importante é que quando um objeto é criado na memória, ele con-
tém os atributos da classe, pois cada objeto terá seus valores para cada atributo.
76 Desenvolvendo Software com UML 2.0 – Definitivo

Como exemplo, se tivermos a classe clsCliente, o objeto clsCliente1432 terá um va-


lor diferente do objeto clsCliente1433, para nome e saldo de cliente – estes são atri-
butos da classe clsCliente. Entretanto, os métodos ObterNome e ObterSaldoCliente são
comuns aos dois objetos, que residem na classe e não nos objetos. O que reside no
objeto, quando este é instanciado são seus atributos.
Veja, mais adiante, sobre atributo estático.

Por que objetos?


Porque se já pensei na altura, na largura, no formato e na cor de uma porta, não há
razão para eu não me utilizar desse mesmo modelo em um novo projeto de prédios
de apartamentos. Ou seja, a visão orientada a objetos permite a reutilização de ob-
jetos entre as diferentes aplicações que construímos.
Além disso, a organização é muito melhor. Posso ter gavetas separadas que guar-
dam especificações de objetos diferentes: portas, pisos, tetos, batentes, escadas etc.
Creio que, quando pensamos em orientação a objetos, devemos pensar a organiza-
ção como um grande conjunto de legos. Um lego é uma parte da organização. Se ti-
vermos um conjunto de objetos que fornecem determinada funcionalidade à
organização em um desses legos, teremos a possibilidade de reutilizar esses objetos
em outras ocasiões. Em conseqüência disso, a manutenção é muito melhor.
Não vou me delongar mais nesse ponto, é evidente que, se você está lendo esse tex-
to, tem interesse em orientação a objetos e já está convencido disso. Além do que, a
reutilização de código não é o único argumento em favor da orientação a objetos.

Como é a notação de uma classe?


A Figura 5.1 mostra-nos como uma classe é representada. Vemos três comparti-
mentos em um quadrado. O primeiro compartimento é reservado ao nome da clas-
se, o segundo, a suas características ou atributos. O último compartimento é
reservado a suas funções. Esta notação não é uma invenção da UML; há muitos
anos se usa este formato para representar uma classe. Todas as ferramentas que
permitem a construção de um diagrama de classes utilizam essa notação.

Figura 5.1 Uma classe.


Capítulo 5 Teoria de Classes 77

O nome da classe
Assim como todos os símbolos que vamos introduzir, o nome da classe deve seguir
o documento Nomenclatura. Por exemplo, a classe Apartamento se chamaria
clsApartamento. O nome de uma classe deve descrever o que ela representa ou faz,
em português bem claro.

Os atributos de uma classe


Os atributos são as características que uma classe tem. Seguindo nosso exemplo,
clsApartamento possui dez portas. Essa característica é descrita em um atributo que
guardará esse número. Como isso é um número e estamos utilizando Java como
linguagem para construir nosso software, iNumeroPortas é válido como atributo, da
mesma forma como iNumeroDormitorios, strCorParede, dtDataEntrega, dtDataAlvara etc.
Veja que um atributo guarda um valor do tipo existente na linguagem de progra-
mação que será usada. Você deve se informar sobre os tipos de dados usados pela
sua linguagem. Todas fornecem esta lista, que pode ser impressa por um dos pro-
gramadores ao consultarem o menu ajuda da linguagem.

Método, função ou operação?


Em primeiro lugar, vamos esclarecer que esse compartimento (terceiro) é reserva-
do a tudo o que é de responsabilidade da classe obter ou ajustar – você também
pode entender como ‘fazer’.
Uma classe obtém o número de portas pedindo iObterNumeroPortas (icodApto:int):int.
A primeira letra (i) indica que essa função adquire o número de portas por meio de
um Inteiro (i), conforme nosso documento Nomenclatura. O nome da função é
bem claro – ObterNumeroPortas.
Entre parênteses, temos o que chamamos de argumento ou parâmetro; nesse caso,
é a indicação de um parâmetro de entrada. A função precisa saber de qual aparta-
mento estamos falando para retornar o número de suas portas, daí ter pedido o có-
digo do apartamento. Os dois pontos indicam que esse parâmetro é um inteiro.
Finalmente, temos mais dois pontos e, em seguida, um tipo de dado da nossa lin-
guagem. Esse tipo de dado é o indicativo de que tipo de dado será o retorno dessa
função, no nosso caso, um inteiro. Isso faz sentido, visto que o número de portas é
informado em forma de inteiros (1, 2, 3 etc.).
Existem diferenças entre os termos (função, método) e operação. No nosso texto,
vamos procurar utilizar função ou método.
Uma operação é um protótipo, isso é o mais comum para quem desenha diagra-
mas de classes. Não há mais nenhuma indicação de código ou qualquer outra im-
plementação em um protótipo de função. Aqui temos apenas a ‘casca’ da função;
desta forma, iObterNumeroPortas (icodApto:int):int é um protótipo de uma função,
portanto, uma operação.
78 Desenvolvendo Software com UML 2.0 – Definitivo

Um método ou função (ambos os termos têm o mesmo significado) é a implemen-


tação de uma operação. Dessa forma, quando um programador coloca seu código
no corpo de uma operação ele a transformou em método.
A seguir, temos o exemplo dessa situação:
public int iNumPortas(int iCodApto) {
//código do programador
return 0;
}

O exemplo acima é de uma operação pensada por um analista e codificada ou


transformada em método por um programador. Métodos serão encontrados em
arquivos de código de programadores. Eles são conhecidos como a ‘interface’ da
classe pela qual outras classes podem se relacionar com ela.
Na UML, um analista define apenas as operações. Ele informa o nome e os argu-
mentos de entrada e saída das várias interfaces, porém, quem faz o código que im-
plementa essas interfaces é o programador.

Responsabilidade de uma classe


Uma classe sempre deve versar sobre um mesmo assunto. Uma classe encapsula
um dado conhecimento sobre algo. Não faz sentido inserirmos, em uma classe que
trata de apartamento, dados sobre a imobiliária ou atrasos de pagamento da hipo-
teca – são assuntos diferentes, portanto, classes diferentes!
Uma classe tem responsabilidade por tudo o que lhe diz respeito. Sua responsabilida-
de é resumida em seus atributos e operações. Não é responsabilidade de um proprietá-
rio incluir um apartamento, é responsabilidade da própria classe fazer essa inclusão.

Generalização e especialização (GenEspec) herança


Generalização é o nome dado entre dois elementos, um mais geral (Pai) e um mais
específico (Filho). O mais específico é completamente consistente com o mais geral
e adiciona informações ao elemento mais geral. Este conceito pode, segundo a
UML, ser usado para classes, Casos de Uso e pacotes2.
A herança é a possibilidade de uma classe utilizar os atributos e métodos de uma
outra como se fossem seus. A herança pode acontecer entre classes que tenham afi-
nidade (o mais comum), por exemplo: clsPai e clsFilho, ou entre classes entre as
quais, habitualmente, não vemos conexão. Entretanto, não confunda generaliza-
ção – especialização com estruturas todo-parte, da qual falaremos mais adiante.
Uma estrutura de generalização e especialização implica herança: um filho herda
dados do pai como cor dos olhos e cor da pele.
Uma estrutura de todo-parte não possui herança: um braço é parte do pai, assim
como suas pernas, mas não há herança nesses casos.
Capítulo 5 Teoria de Classes 79

Quando temos herança, a classe que fornece a herança é chamada de SuperClasse,


e a que recebe a herança é chamada de SubClasse. Em Java, existe uma SuperClas-
se de todas as classes chamada Object. Todas as classes e arrays herdam os métodos
da classe Object. Somente a classe Object não tem SuperClasses diretas.
Quando uma SubClasse herda os atributos e operações de outra, ela herda todos.
O que faz a diferença é a visibilidade, que veremos no próximo tópico. Todas as
linguagens orientadas a objeto permitem herança. É um equívoco chamar uma lin-
guagem de orientada a objetos se ela não fornecer herança. A utilização da heran-
ça é fator dependente da aplicação e, em aplicações comerciais é muito útil, desde
que estejamos utilizando o conceito de Lego, passado nos tópicos anteriores.
Imaginemos que o pacote pctHabitacao foi terminado e documentado. A sua docu-
mentação orienta-nos sobre o que está dentro do pacote e como usá-lo. Nesse pa-
cote existem operações que uma nova aplicação precisa utilizar a partir de novas
classes. A utilização da herança, aqui, é fundamental para a redução da necessida-
de da codificação e para se obter maior rapidez no desenvolvimento.
Mesmo em uma única aplicação, se uma funcionalidade foi pensada em outra clas-
se, não precisaremos repeti-la, basta utilizarmos a herança.
A Figura 5.2 mostra a notação da herança. Duas classes interligadas por meio de
uma seta vazia. A seta deve, sempre, estar apontando para a SuperClasse. O fato de
termos a seta na parte de baixo da SuperClasse não indica que essa é a única forma
de representarmos a herança. A seta poderia estar em qualquer lado da SuperClasse.

Figura 5.2 A representação da herança.

Essas definições têm reflexo no código que um programador vai executar. No


exemplo anterior, o programador deverá escrever um código semelhante:
public class clsDeposito extends clsApartamento{

}
80 Desenvolvendo Software com UML 2.0 – Definitivo

Cada linguagem resolve a herança a seu modo. Java segue a sintaxe mostrada. A
palavra extends, em Java é a que indica a herança. A classe à esquerda dessa pala-
vra-chave é a SubClasse e à direita da palavra é a SuperClasse.

Herança múltipla
A herança múltipla dá-se quando uma SubClasse herda atributos e operações de
duas ou mais SuperClasses. Esse tipo de situação deve ser evitado. Apesar de a
orientação a objetos prever essa situação, ela introduz possibilidades de difícil re-
solução.
A Figura 5.3 mostra a herança múltipla. Imagine que existisse uma hierarquia de
mais de dez classes nesta árvore de heranças e que clsCobertura tem operações com
o mesmo nome das que aparecem em clsApartamento. Quando, no código, estivésse-
mos tentando descobrir qual o ancestral, ou pai ou SuperClasse de um desses mé-
todos, poderíamos encontrar dificuldade.
Page-Jones diz: “Operações conflitantes têm o mesmo nome, e a SubClasse suces-
sora não consegue diferenciar facilmente qual delas ela deveria herdar”.3

Figura 5.3 Herança múltipla.

Discriminadores de classificação (generalização/especialização)


Os discriminadores são escritos entre chaves e próximos à seta de generalização
mostrada na Figura 5.4. São aplicáveis à generalização/especialização (GenEspec),
ou seja, herança.
O discriminador {completo} ou {complete} indica que qualquer instância da SuperClasse
será uma instância de um dos seus filhos. Se a SuperClasse é Pessoa e suas SubClas-
ses são Homem e Mulher com o discriminador {completo}, então uma instância será
sempre ou de um homem ou de uma mulher. A SuperClasse é abstrata, nesse caso.
A UML diz que se esse discriminador está escrito em um conjunto de generaliza-
Capítulo 5 Teoria de Classes 81

ção/especialização, uma nova SubClasse não deverá ser esperada, ou seja, a análise
do conjunto foi feita por inteiro.
O discriminador {incompleto} ou {incomplete} indica que o conjunto pode esperar
novas SubClasses, a SuperClasse é concreta, e uma instância de seu tipo pode não
ser de uma de suas SubClasses e sim da própria SuperClasse.
O discriminador {disjunção} ou {disjoint} é default (padrão) e indica que qualquer
instância da SuperClasse pode ser uma instância de apenas um dos subtipos, nunca
poderá ser mais do que um.
O discriminador {sobreposição} ou {overlapping} indica o contrário da disjunção, ou
seja, uma instância pode pertencer a mais de um subtipo ou SubClasse. A autora
Ana Cristina Melo dá um bom exemplo quando diz que, em um determinado do-
mínio de problema de Universidade, uma SubClasse Aluno pode ser, ao mesmo
tempo, uma SubClasse Professor dada uma SuperClasse Pessoa; nesse domínio de
problema, um aluno é também um professor.4
Veja que, apesar de essa autora estar certa, isso indica uma herança múltipla, úni-
ca situação em que alguém é aluno e também professor. Esse tipo de solução não é
aconselhado.
O discriminador {dinâmico} ou {dynamic} pressupõe a classificação dinâmica indi-
cando que os objetos podem mudar seus tipos nas suas subtipagens. Martin Fow-
ler dá um exemplo de uma Pessoa (SuperClasse) que tem as SubClasses (Feminino
e Masculino) e em outra estrutura, herdando também de Pessoa as SubClasses
(Gerente, Engenheiro e Vendedor), ou seja, uma pessoa do sexo masculino será
também, em outro objeto, um Engenheiro.5 Isto não é herança múltipla, existem
os dois objetos.
Jim Odell também defende essa classificação dinâmica e múltipla.6 O problema é
implementar isso. O próprio Martin Fowler sugere que, neste caso, seria interes-
sante criarmos uma classe Emprego e ligarmos a Pessoa do sexo masculino ao
Emprego; a classe Engenheiro também teria sua ligação com a classe Emprego.7
O discriminador {estático} ou {static} se opõe ao dinâmico, o mais comum.
A Figura 5.4 nos indica que clsApartamento é uma classe concreta, pois existe o dis-
criminador Incompleto na estrutura de herança e, portanto, existirão objetos do
tipo clsApartamento na solução.
Existe, também, a indicação de que, se existir uma instância herdada de clsAparta-
mento, essa necessariamente será de clsKitchnete ou clsCobertura, mas podem haver
ocorrências de objetos do tipo clsApartamento, pois essa classe é concreta, já que
existe o discriminador Incompleto.
Creio que este é um item do final de desenho, que nos deve levar à preocupação em
casos mais específicos.
82 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 5.4 Discriminadores de generalização.

Interface
A herança múltipla não é permitida em Java. Entretanto, existem situações em que
um quadro semelhante é necessário. Neste caso, temos duas saídas.
A primeira é aumentarmos o número de classes a fim de fugirmos da herança múl-
tipla; normalmente, o acréscimo de classe ocorre na ordem de 50%.
A segunda alternativa é a de criarmos uma interface. Uma interface, em Java, não é
uma classe, é um arquivo que define valores constantes e as operações que uma ou-
tra classe deve implementar. Ou seja, ela não tem métodos, apenas seus protóti-
pos. No tópico em que falamos de métodos, falamos que estes são interfaces com o
mundo externo, não fique confuso. Existem muitos tipos de interface, por exem-
plo, existem as interfaces gráficas. Ou seja, uma interface é uma interligação de
uma coisa com outra.
O que possibilita ao mundo externo colaborar com uma classe é a sua interface. O
que possibilita o usuário fazer uma escolha na tela do computador é uma interface
gráfica.
Uma classe que expõe apenas constantes e operações (sem implementação nenhu-
ma) é, também, chamada de interface.
A interface pode resolver a questão da herança múltipla na análise orientada a ob-
jetos de problemas.
A Figura 5.5 nos mostra a notação do uso de interfaces. A classe clsDeposito herda
valores de clsApartamento e implementa a interface de itCobertura.
O nome Interface que aparece entre os sinais de maior e menor define a notação
para uma Interface. Uma seta pontilhada aponta de quem vai implementar a inter-
face para a interface que será implementada.
Capítulo 5 Teoria de Classes 83

Figura 5.5 O uso de interfaces que podem evitar a herança múltipla.

Poderia surgir a pergunta: “Se uma interface tem 50 operações, como indicamos
para o pessoal de programação qual operação deve ser implementada?” A respos-
ta é que não necessitamos fazer isso, pois quem for implementar uma interface de-
verá fazê-lo por inteiro, mesmo tendo apenas necessidade de usar apenas duas
operações, deverá referir-se a todas as outras. Na documentação da classe você faz
as observações de distinção necessárias.

Visibilidade de uma classe


Uma classe pode ser pública, protegida, privada ou em pacote.
O fato de citar o código em Java não invalida o uso de outras Linguagens Orienta-
das a Objeto. Farei a declaração das linhas de código para mostrar a conseqüência
do trabalho do analista no trabalho do programador.
As diferentes ferramentas de modelagem UML podem mostrar simbologias dife-
rentes para a visibilidade de uma classe, algumas simplesmente não mostram. A
própria documentação da OMG8, deixa aberturas para essa notação.
Entretanto, este é um item que tem repercussão no código desenvolvido pelo pro-
gramador, o que nos exige atenção.

Classe pública
Uma classe pública indica que qualquer outra classe poderá acessar os atributos e
operações da classe.
A sintaxe em Java para este tipo de declaração será:
public class clsCobertura {
}
84 Desenvolvendo Software com UML 2.0 – Definitivo

Classe privada
Uma classe privada pode ser uma classe que foi declarada como parte de outra.
Isso depende do domínio da aplicação. Java permite a declaração de classes como
se fossem atributos de outras; isto é conhecido como inner class.
public class clsCobertura {
private class clsProprietario {
}
}

Classe em pacote
Uma classe declarada como ‘em pacote’ terá a sua visibilidade restrita ao pacote
em que reside. Classes fora daquele pacote não poderão sequer saber de sua exis-
tência. Uma classe sem visibilidade nenhuma tem a visibilidade-padrão, que é a de
pacote. Suponha que tivéssemos o seguinte código:
package pctHabitacao;
public class clsApartamento { Arquivo clsApartamento
}

package pctHabitacao;
Arquivo clsDeposito
class clsDeposito extends clsApartamento {
}

Neste exemplo, a classe cls_Apartamento é pública, ou seja, qualquer classe de fora


do pacote pctHabitacao pode vê-la. Já a classe clsDeposito está com a visibilidade pa-
drão, somente classes pertencentes ao pacote pctHabitacao podem acessá-la.
Portanto, colocar nenhuma visibilidade é colocar a visibilidade padrão ou visibili-
dade de pacote em uma classe.
Existe uma notação especial, na UML, para designar um pacote. Essa notação não
deixa dúvidas ao programador ou a quem quer que leia o diagrama sobre a inten-
ção do analista (veja a Figura 5.6).
O código Java referente a esse tipo de visibilidade em Java, é expresso por:
package pctHabitacao;

Essa declaração, em cada classe do pacote, torna a classe pertencente a determina-


do pacote.
A seguir, veja a Figura 5.6, que nos mostra algumas definições já vistas.

1. clsDeposito herda diretamente de clsApartamento. Estará correto se chamarmos


clsDeposito de derivada ou SubClasse. Também estará correto chamarmos
clsApartamento de classe base ou SuperClasse.
Capítulo 5 Teoria de Classes 85

2. Para evitarmos a herança múltipla, lançamos mão de um artifício que é o uso


da interface. Uma classe pode herdar de uma e implementar uma outra interfa-
ce, conforme o seguinte código em Java, que retrata o que acontece na Figura 5.6.
itCobertura não possui implementação alguma de suas operações; quem realiza
essas implementações é clsDeposito.
class clsDeposito extends clsApartamento implements itCobertura {

}
3. A classe clsProprietario é conhecida como inner class, pois é (além de classe) um
atributo de clsCobertura. Apesar de termos mostrado o formato de uma linha
com uma circunferência e, dentro desta, um sinal de cruz, a ferramenta permite
que se defina uma classe como inner class, mas visualmente não exibe nada.
4. A notação de pacote é feita como mostra a Figura 5.6.

Figura 5.6 A notação do pacote, herança, interface e inner class na UML.

5. A Figura 5.6 é apenas um exemplo. Podemos ter todas essas notações fora de
um pacote. Falaremos mais de pacotes mais adiante neste texto.

Modificadores de uma classe


Uma classe pode sofrer modificações dependendo do uso que lhe seja dado. Esses
modificadores alteram o sentido da classe de diversas maneiras. É possível darmos
um sentido diferente ao que foi apresentado no tópico “O que é uma classe?”.
Uma classe é passível de sofrer os seguintes modificadores: abstract, final, root e active.
86 Desenvolvendo Software com UML 2.0 – Definitivo

Classe abstrata (abstract)


É uma classe que não terá correspondência em objetos na memória, ou seja, não exis-
tiram instâncias de objetos para aquela classe em momento algum. O contraste para a
classe abstrata é a uma classe concreta que, evidentemente, gera objetos na memória.
Essa classe serve de modelos, ou apoio, a outras classes que partilham de seus da-
dos. A classe abstrata está fornecendo uma herança para outras classes e, por isso,
deixa de ter sentido a existência de objetos dela.
Veja que usamos os termos abstração e classe abstrata. Um nada tem a ver com o
outro. No Capítulo 3, falamos sobre o conceito de abstração no tópico “Quanto
um Caso de Uso deve ser escrito?”. O termo abstração refere-se à análise; já o ter-
mo classe abstrata refere-se à classe propriamente dita.
A notação para uma classe abstrata é dependente da ferramenta UML usada. O
exemplo da Figura 5.7 mostra a classe abstrata clsPessoa, a qual fornece herança
para a classe clsCliente. Veja que não faz sentido termos objetos do tipo pessoa,
mas de cliente, sim. clsCliente representará um objeto na memória e terá nome, có-
digo, endereço, histórico etc.
O ganho na criação de classes abstratas está na possibilidade de as usarmos em di-
versos momentos. No nosso exemplo, clsPessoa poderá ser usada por clsFunciona-
rios, clsClienteAdimplentes, clsClientesInadimplentes e todos utilizarão tudo o que já
foi feito na classe abstrata.
O documento OMG9 da UML indica-nos que uma interface (a qual já vimos ante-
riormente) é formalmente uma classe abstrata, sem nenhum atributo ou método,
somente com operações abstratas que serão implementadas por outros.
É necessário dizer que uma classe pode fornecer herança e não ser abstrata.
A classe, então, passa a ter seu nome em itálico.

Figura 5.7 Uma classe abstrata.


Capítulo 5 Teoria de Classes 87

Nas linhas de código, o programador representará essa situação da seguinte forma


em Java:
public abstract class clsPessoa {
}

Classe final
Outro modificador de uma classe é o final. Uma classe é criada como final se sua
definição está completa e nunca existirá uma subclasse dela. Portanto, uma classe
jamais poderá ter ambos os modificadores (FINAL e ABSTRACT), porque sua im-
plementação jamais poderá ser completada, o que ocorre na classe abstrata.10, 11
Esse modificador pode servir para segurança, se quisermos impedir que alguém
realize a herança para nossas classes. Em seguida, mostro como fica a declaração
de uma classe marcada como final para a linguagem Java:
public final class clsCliente extends clsPessoa {

Não existe, visualmente, nenhuma notação específica para a designação de uma


classe como final.

Classe root
Uma classe marcada como root não poderá ter ancestral. Da mesma forma, se uma
interface for marcada como root, ela não poderá ser filha de outras interfaces.
Este modificador é uma preocupação para quando estivermos interessados em ge-
neralização e especialização, e precisamos identificar qual classe é a mais alta na
hierarquia de classes. Pense em uma hierarquia que envolve mais de 20 classes e
esse modificador passa a fazer sentido.
Nada de especial visualmente é feito para a notação, porém a semântica existe e foi
passada nas linhas anteriores. A linguagem Java não prevê nada de especial para
uma classe com o modificador isRoot.12, 13, 14

Classe ativa (active)


Se uma classe tiver objetos com a sua própria thread ou segmento de controle, e es-
ses puderem ser instanciados na memória concorrentemente com outros objetos
de seu tipo, esta classe é marcada como active, ou seja, os métodos desses objetos
poderão ser executados de forma concorrente. O oposto para este tipo de modifi-
cador é uma classe passiva (passive class).
Nada de especial visualmente é feito para a notação, porém a semântica existe e foi
passada nas linhas anteriores. Este modificador é conhecido, também, como isActive.
88 Desenvolvendo Software com UML 2.0 – Definitivo

Visibilidade dos atributos


Os atributos também possuem visibilidade por dois motivos. Primeiro, porque
existe um princípio na orientação a objetos que se chama encapsulamento. Esse
princípio informa que os dados pertencentes a uma classe somente ela pode aces-
sar, ler, distribuir e alterar. Quando uma classe abre os seus atributos para que o
mundo externo possa alcançá-los, fere-se um princípio fundamental da orientação
a objetos.
Em segundo lugar, já informamos que, quando uma classe fornece herança para as
SubClasses, fornece absolutamente tudo. Quando se herda, herda-se tudo. Neste
caso, supondo que não existisse a visibilidade, os atributos e métodos da classe que
fornece a herança estariam à mercê de qualquer alteração sem critério.
Por essas razões, a visibilidade de atributos vem nos resolver uma série de problemas.
A visibilidade de atributo prevê: público (public), privado (private), protegido (pro-
tected) e pacote (package).

Atributo público (public)


A notação para este tipo de visibilidade de atributo é um sinal de adição (+), logo à
frente do nome do atributo.
A semântica desse sinal é que um atributo público é visto pelos membros internos e
por qualquer membro externo à classe em que está declarado. Ou seja, absoluta-
mente qualquer classe fora do pacote em que ela foi definida pode ler e alterar o
valor deste atributo sem obedecer a critério algum. No código de linguagem de pro-
gramação, essa declaração para a classe clsApartamento, no atributo que guarda o
número de portas do apartamento, ficaria assim:
public double iNumPortas;

Quando marcamos um atributo com visibilidade pública, queremos dizer que sua
confiabilidade é fraca. Entretanto, podem existir situações em que um atributo ne-
cessite desse tratamento, porque a implementação do negócio pede assim.

Atributo privado (private)


A notação para este tipo de visibilidade de atributo é um sinal de subtração (–), do
nome do atributo.
Um atributo com visibilidade privada é o mais comum na orientação a objetos. A
semântica para esse símbolo informa que apenas a classe em que ele está declarado
pode acessá-lo. Ou seja, as operações dessa classe podem retornar e alterar o seu
valor.
Quando existir a necessidade de alterar o seu valor, necessariamente, passaríamos
por critérios definidos dentro de um método que tem como responsabilidade res-
guardar a confiabilidade do atributo. No código de linguagem de programação,
Capítulo 5 Teoria de Classes 89

essa declaração para a classe clsApartamento, no atributo que guarda o número de


portas do apartamento, ficaria assim:
private double iNumPortas;

Existem duas formas de acessar e/ou alterar o valor de atributos em linguagens de


programação orientadas a objetos. A primeira é termos uma operação que altere o
valor e uma operação que retorne o valor atual. A segunda forma é termos uma
única operação por classe que acesse e outra, que altere o valor de todos os atribu-
tos em uma classe.
Essa é uma decisão de construção que pode ser até mesclada. Poderíamos utilizar
as duas formas, por que não? É preciso usar o bom senso. Caso tenhamos 20 atri-
butos em uma classe, é muito mais rápido criarmos uma única operação que retor-
ne todos os valores da classe e o cliente use o que precisar, do que criarmos 40
operações, 20 que retornam valores e 20 que alteram valores. Entretanto, podem
existir atributos que devem passar por um crivo especial, então valerá a pena o tra-
tarmos em duas operações separadas, uma que altere e outra que retorne. Adicio-
nalmente, ferramentas UML que geram código em linguagem de programação
podem gerar essas duas operações de forma automática para cada atributo.

Atributo protegido (protected)


A notação para este tipo de visibilidade de atributo é um sinal de cerquilha (#),
logo à frente do nome do atributo.
A semântica nos informa que o atributo, com esse tipo de símbolo precedendo-o,
somente é acessível por meio de classes que estejam participando de sua estrutura
de herança. Classes fora dessa estrutura não poderão acessá-lo, retornando ou al-
terando seu valor.
No código de linguagem de programação, essa declaração para a classe clsCliente,
no atributo que guarda o nome do cliente, ficaria assim:
protected String strNome;

Atributo em pacote (package)


A notação para este tipo de visibilidade de atributo é um sinal de til (~), logo à fren-
te do nome do atributo.
A semântica nos informa que o atributo, com esse tipo de símbolo precedendo-o,
somente é acessível por meio de classes que estejam no mesmo pacote onde a classe
que o declarou está. Classes fora dessa estrutura não poderão acessá-lo, retornan-
do ou alterando seu valor.
No código de linguagem de programação, essa declaração para a classe clsCliente,
no pacote clsCliente, no atributo que guarda o nome do cliente, ficaria assim:
String strNome;
90 Desenvolvendo Software com UML 2.0 – Definitivo

A classe clsApartamento estará marcada como em pacote, usando a declaração:


package pctHabitacao;

Uma determinada visibilidade pode ser dependente de linguagem; por exemplo, em


C++ existe a possibilidade de classificarmos a visibilidade como implementation.15

Modificadores de Atributo
Os modificadores de Atributo podem ser: estático (static), final (final), transiente
(transient), volátil (volatile).
Os modificadores alteram o significado ou comportamento de um atributo.

Atributo estático (static)


Um atributo marcado como static permanecerá na classe, enquanto existem vários
objetos instanciados daquele tipo. Vejamos o exemplo da classe clsApartamento. Os
atributos iNumPortas, iNumDormitorios e dtEntrega são diferentes para cada objeto do
tipo clsApartamento. Dessa forma, esses atributos existem em cada objeto e não na
classe. Entretanto, temos o atributo dMetragem, caso existisse nesta classe, que é úni-
co para todos os objetos.
Não há forma de um proprietário mudar a metragem de um apartamento. Ele
pode alterar a disposição das paredes, reduzir ou aumentar o número de portas,
mas não pode mudar a metragem do apartamento. Por essa razão, o atributo é es-
tático para a classe e seu valor é válido para todos os objetos.
Dessa forma, esse atributo poderia ser marcado como static. É claro, esse prédio
não pode ter cobertura ou apartamento de zelador, que geralmente têm metragens
diferentes dos apartamentos conhecidos como ‘tipo’.
Caso esses outros tipos de unidades existissem, o atributo dMetragem não poderia
mais ser marcado como static, porque passamos a ter uma metragem diferente
para cada objeto do tipo clsApartamento.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento,
no atributo que guarda a metragem do apartamento, ficaria assim:
private static int dMetragem;

A notação para um atributo estático é um sublinhado marcando o atributo na


UML.

Figura 5.8 Atributo estático.


Capítulo 5 Teoria de Classes 91

Atributo final (final)


Um atributo marcado como final não pode ter seu valor de inicialização alterado.
Isso quer dizer que dado um valor a este atributo para um objeto, este não sofrerá
mais mudanças. A diferença para o modificador static é sutil. Naquele temos um
atributo na classe que não se altera, no caso do final, o atributo está no objeto e
não pode ser alterá-lo, desde o momento de sua inicialização.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento, no atributo que guarda a metragem do apartamento, ficaria assim:

private final int dMetragem;

Não há modificação visual para designar um atributo como final, algumas ferra-
mentas sequer permitem a sua designação.

Atributo transiente (transient)


Transiente /zi/. [do latim transiente, por transeunte.] Adj. 2 g. Passageiro, efêmero,
transitório.16
A modificação de um atributo em transiente significará que ele não será salvo e
nem restaurado pelo mecanismo de serialização. Esse mecanismo é utilizado por
objetos que implementam uma classe especial chamada: java.io.Serializable.17, 18, 19
O programador terá de manuseá-lo por conta própria caso necessite recuperá-lo.
O inverso para este modificador é persistente.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento, no atributo que guarda a metragem do apartamento, ficaria assim:

private transient int dMetragem;

Não há modificação visual para designar um atributo como transiente; algumas


ferramentas sequer permitem a sua designação.

Atributo volátil (volatile)


A designação de um atributo como volátil determina ao Java Run Time que o atri-
buto terá seu valor alterado assincronamente por segmentos que estejam sendo
executadas ao mesmo tempo.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento,
no atributo que guarda a metragem do apartamento, ficaria assim:
private volatile int dMetragem;

Não há modificação visual para designar um atributo como volátil; algumas ferra-
mentas sequer permitem a sua designação.
92 Desenvolvendo Software com UML 2.0 – Definitivo

Visibilidade das operações


As operações têm visibilidade e sua assinalação é pertinente, porque uma operação
pode ser chamada para resolver situações específicas de uma classe ou pode existir
para permitir que outras classes acessem seus atributos.
Como dissemos anteriormente, se um atributo é privado de uma classe, precisará
de uma operação que possibilite o seu manuseio.
As operações podem ser: pública (public), privada (private), protegida (protected),
pacote (package).

Operação pública (public)


Uma operação pública é aquela que pode ser acessada por operações na própria
classe onde ela foi declarada e por operações de outras classes.
A notação para este tipo de visibilidade de operação é um sinal de adição (+), logo
à frente do nome da operação.
No código de linguagem de programação essa declaração para a classe clsAparta-
mento,
na operação que retorna a metragem do apartamento, ficaria assim:
public void ObterMetragem() {
}

A maioria das operações de uma classe são públicas, pois, do contrário, não have-
ria forma de o mundo externo se comunicar com a classe em questão.

Operação privada (private)


A notação para este tipo de visibilidade de operação é um sinal de subtração (–),
logo à frente do nome da operação.
A semântica para esse símbolo informa que apenas a classe em que ele está declara-
do pode acessar esta operação.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento,
na operação que retorna a metragem do apartamento, ficaria assim:
private void ObterMetragem() {
}

Somente operações específicas, de tratamentos internos da classe, recebem essa vi-


sibilidade.

Operação protegida (protected)


A notação para este tipo de visibilidade de operação é um sinal de cerquilha (#),
logo à frente do nome da operação.
Capítulo 5 Teoria de Classes 93

A semântica nos informa que a operação, com esse tipo de símbolo a precedendo,
somente é acessível pelas classes que estejam participando de sua estrutura de he-
rança. Classes fora dessa estrutura não poderão acessá-la.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento,
na operação que retorna a metragem do apartamento, ficaria assim:
protected void ObterMetragem() {
}

Operação em pacote (package)


A notação para este tipo de visibilidade de operação é um sinal de til (~), logo à
frente do nome da operação.
A semântica nos informa que a operação, com esse tipo de símbolo a precedendo,
somente é acessível pelas classes que estejam no mesmo pacote onde a classe que a
declarou está. Classes fora dessa estrutura não poderão acessá-la.
No código de linguagem de programação, esta declaração para a classe clsAparta-
mento,
na operação que retorna a metragem do apartamento, ficaria assim:
void ObterMetragem() {
}

A classe clsApartamento estará marcada como em pacote, usando a declaração:


package pctHabitacao;

Modificadores de Operações
Os modificadores de Operações são: estático (static), abstrato (abstract), final,
root e query.

Operação estática (static)


Uma operação marcada como static permanecerá na classe, enquanto existirem
vários objetos instanciados daquele tipo.
Este tipo de operação somente pode ser invocado se, primeiro, referenciarmos a
classe e não o objeto que está instanciado. Informamos anteriormente que uma
operação, por definição, reside na classe e não nos objetos. Entretanto, quando
nos referimos a uma operação de um determinado objeto o fazemos da seguinte
forma: -> objeto.operação. No nosso exemplo, na classe clsApartamento, usaríamos:
clsApartamento1324.ObterMetragem(). Caso esta operação fosse declarada como estáti-
ca, usaríamos clsApartamento.ObterMetragem().
Esse tipo de operação somente poderia utilizar variáveis (atributos) de classe e não
de instâncias dessa classe, ou seja, atributos também estáticos.
94 Desenvolvendo Software com UML 2.0 – Definitivo

Para motivarmos a utilização deste tipo de modificador, vamos levar em conside-


ração um exemplo que apresente a necessidade de contarmos quantos apartamen-
tos estão instanciados na memória.
Caso este contador fosse um atributo de instância e não de classe, jamais sabería-
mos a quantidade de apartamentos instanciados, pois cada instância cuida somen-
te de seus dados.
Precisaríamos ter um atributo de classe (e, portanto, declarado como static) para
contarmos as instâncias de apartamentos. Assim, no método construtor da classe,
teríamos um incremento do atributo estático de classe iCountApartamento a cada ins-
tanciação de um apartamento.
Para recuperamos esse valor precisaríamos de uma operação que lesse o valor,
portanto uma operação também estática. Vamos chamar essa operação de Obter-
NumAptsInstaciados, que retorna um número inteiro representando o número de
apartamentos instanciados na memória.
Quem necessitasse saber o número de apartamentos instanciados na memória, a par-
tir de um apartamento instanciado (objeto instanciado), pediria o nome da classe se-
guido de ponto, seguido do nome do método estático que acessa o atributo estático.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento, na operação que retorna a quantidade de apartamentos instanciados, ficaria
assim:
public static int ObterNumAptsInstanciados() {
}

A notação para uma operação estática é um sublinhado marcando a operação. A


Figura 5.9 mostra essa notação, para atributo e para operação. Isso significa que a
operação estática ObterMetragem() utiliza o atributo dMetragem, também estático.

Figura 5.9 Operação estática.

Operação abstrata (abstract)


Classes abstratas, as quais já vimos sua notação e semântica, não podem ser ins-
tanciadas. São desenhadas para serem estendidas por outras classes, as quais im-
plementam suas operações. Assim, uma operação abstrata não tem implementação,
mas apenas o protótipo de como ela deve ser.
Capítulo 5 Teoria de Classes 95

A notação para uma operação abstrata é ter seu nome em itálico.


Na Figura 5.10, passamos a operação ObterMetragem() para abstrata; veja o resulta-
do final:

Figura 5.10 Operação abstrata.

Visto que uma operação abstrata não tem implementação, vale o formato do
exemplo anterior para designá-la:
public abstract void ObterMetragem() {
}

Operação final
Uma operação marcada como final não poderá ser alterada por outra classe. Mais
adiante, falaremos sobre polimorfismo e overloading, e você entenderá que isso é
perfeitamente possível. Uma operação final está perfeitamente definida e não há
razão para sua alteração. Uma operação final não pode ser abstract, os motivos
são óbvios.
No código de linguagem de programação, essa declaração para a classe clsAparta-
mento,
na operação que retorna a metragem de um apartamento, ficaria assim:
public final void ObterMetragem() {
}

Operação root
Em uma hierarquia de itens, este modificador indica que uma operação está em
seu nível mais alto, não existindo nenhum outro nível acima.
Não há nenhuma alteração visual para esse item, e algumas ferramentas sequer
dão essa possibilidade. Faz mais sentido que uma classe seja marcada como root
do que uma operação dessa classe.

Operação query
Este modificador, propriedade de uma operação, é por default ajustado para FALSE,
os seus valores possíveis são True e False. False indica que a execução da referida
operação poderá alterar o estado da instância, um objeto do tipo daquela classe.
Normalmente não se faz nada, pois o default já é FALSE.
96 Desenvolvendo Software com UML 2.0 – Definitivo

Marcar uma operação como isQuery, e portanto com isQuery=TRUE, indica que
qualquer chamada a esse método não poderá afetar o estado do objeto. O objetivo
aqui é, explicitamente, preservar o estado da instância.20
Estado é um termo que se refere à condição de uma instância em um dado momen-
to do tempo e espaço.21
A especificação UML diz:
“Specifies whether an execution of the Feature leaves the state of the system unchan-
ged. True indicates that the state is unchanged; false indicates that side-effects may
22
occur.”
“Side-Effect = Efeito Colateral, qualquer mudança de estado causada por uma sub-roti-
na. Por exemplo, dizemos que uma rotina que lê um valor em um arquivo e avança o
ponteiro tem um efeito colateral (o avanço do ponteiro).
Rotinas com efeitos colaterais podem se comportar de modo diferente cada vez que
23
são executadas, ainda que sejam chamadas com os mesmos parâmetros.”
Não há nenhuma alteração visual para esse item e algumas ferramentas sequer dão
essa possibilidade.

Concorrência
Determina a semântica de concorrência para chamadas passivas a uma operação.
As opções são seqüencial, restrita ou concorrente (sequential, guarded (synchro-
nized) e concurrent). Na primeira, as chamadas são feitas uma a uma; na segunda,
múltiplas chamadas podem ser feitas, porém apenas uma estará ativa; e na tercei-
ra, múltiplas chamadas podem ser feitas e ativadas.

Estruturas todo-parte
Estruturas todo-parte são representadas por meio da agregação, que pode ser de
dois tipos: agregação e agregação por composição. Chamaremos este último tipo
apenas de composição.
Como indicado no tópico em que falamos de herança, estruturas todo-parte não
são estruturas de generalização e especialização. Não há herança aqui. Somente
existirá uma agregação se o conceito de todo-parte existir. Assim, entre motor e
pistão existe todo-parte, porém não existe herança. Entre aeronave e avião existe
herança, e entre avião e asa existe todo-parte. São conceitos diferentes.
Pode haver herança entre classes e não existir todo-parte, o inverso é, também,
verdadeiro.

Agregação
Uma agregação somente pode ocorrer entre duas classes.
Este tipo de relacionamento ou associação, conforme a UML, é identificável a par-
tir da notação de uma linha sólida entre duas classes, a classe denominada todo-agre-
Capítulo 5 Teoria de Classes 97

gado recebe um diamante vazio, enquanto a outra ponta da linha é ligada à classe
denominada parte-constituinte.
Ambas as classes podem ‘viver’ de forma independente, ou seja, não existe uma li-
gação forte entre as duas. Objetos da parte constituinte ou da parte agregado são
independentes em termos de vida, porém ambas são partes de um único todo. Essa
análise dependerá do domínio do problema em estudo.
Para sabermos se um relacionamento é de agregação, basta perguntarmos se, em
primeiro lugar, cabe a estrutura todo-parte. Em seguida, perguntamos se o objeto
constituinte-parte ‘vive’ sem o objeto agregado. Se a resposta for sim a ambas per-
guntas, teremos uma agregação.
A Figura 5.11 apresenta a notação para essa semântica. Para um determinado do-
mínio de problema que trata de apartamentos e condomínios, vemos que um apar-
tamento tem depósitos. Quando nos referimos a um depósito podemos perguntar
a qual apartamento aquele depósito pertence.
Por outro lado, um determinado proprietário pode ter decidido sobre a venda de
um depósito para alguém que sequer mora no prédio. Assim, teremos os dois obje-
tos, nesse exemplo, vivendo separadamente, sem incômodo algum. Poderíamos ter
a situação em que um apartamento é interditado ou passa por uma grande refor-
ma. Durante algum tempo não teremos movimentação naquele apartamento, po-
rém o depósito que faz parte daquele jogo apartamento-depósito, continua sendo
usado livremente.
Veja que o mesmo exemplo vale para garagens de um apartamento.

Figura 5.11 Uma agregação entre duas classes.


98 Desenvolvendo Software com UML 2.0 – Definitivo

Composição
Uma composição ocorre quando temos uma situação semelhante à da agregação
entre duas classes, porém os objetos da classe parte não podem viver quando o
todo é destruído.
Este tipo de relacionamento ou associação, conforme a UML, é identificável pela
notação de uma linha sólida entre duas classes, a classe denominada todo-compos-
ta recebe um diamante preenchido, enquanto a outra ponta da linha é ligada à
classe denominada parte-componente.
Ambas as classes ‘vivem’ unidas de forma dependente, ou seja, existe uma ligação
forte entre as duas. Os objetos da classe parte são dependentes, em termos de vida,
da classe todo, ambas são partes de um único todo. Essa análise dependerá do do-
mínio do problema em estudo.
Para sabermos se um relacionamento é de composição, basta perguntarmos se, em
primeiro lugar, cabe a estrutura todo-parte; em seguida, perguntamos se o objeto
parte ‘vive’ sem o objeto todo. Se a resposta for sim à primeira pergunta e não à se-
gunda, teremos uma composição.
A Figura 5.12 apresenta uma visão da notação para esse tipo de relacionamento.
Para este domínio de problema, precisei pensar no prédio como um TODO. Isso
parece plausível pois, nesse domínio de problema, necessariamente um prédio de-
veria existir para que haja um apartamento. Caso não pudesse qualificar um pré-
dio, nada poderia ser feito com relação àquele apartamento. Não se pode fazer
nada com um apartamento, vender ou alugar, enquanto ele não possuir um ende-
reço. O endereço é do prédio, o apartamento tem apenas complemento. Assim,
para os fins deste software, não se conseguiria instanciar um objeto clsApartamento,
caso não fosse designado um objeto clsPredio.

Figura 5.12 Composição entre duas classes.


Capítulo 5 Teoria de Classes 99

De outra forma, se você pensasse em termos de proprietário e apartamento, pode-


ria cair em uma armadilha. Veja que não faz sentido pensarmos em todo-parte en-
tre proprietário e apartamento. Além disto, podemos ter um objeto apartamento
que é resultado de um espólio e, durante todo o processo judicial, esse apartamen-
to não pode ser alugado ou vendido, porém alguém deve pagar seu condomínio e
outros impostos governamentais. Assim, se considerássemos uma relação todo-par-
te de composição entre proprietário e apartamento, pecaríamos quanto à existên-
cia do apartamento, independente do seu proprietário.
Fiz todas essas considerações, pois é necessário (sempre) frisar que o que vale é o
domínio do problema em questão. Ficaria mais fácil ficarmos nos exemplos do
tipo avião-asa, motor-pistão etc., porém, o que encontramos na vida real nem
sempre é tão claro assim.

Herança, agregação ou composição?


Quando passo essas definições para meus alunos, uma dúvida atroz passa a perse-
gui-los durante o processo de análise. Será uma agregação, será uma composição
ou uma herança ?
Alguns alunos sentem a necessidade de criar uma classe genérica e nomeá-la de sis-
tema. Pessoalmente, não gosto de classes desse tipo; nomeá-la como utilitária me
parece melhor, conceito que veremos mais adiante. O que gostaria de frisar aqui é
que, ao criar uma classe como sistema, você pode ser levado a pensar que existe
composição dessa classe com todo o software, porque se a classe sistema for des-
truída, não existirão objetos de nenhum tipo no software. Este conceito pode ser
verdade, porém o conceito de todo-parte não existe aqui. Você acabou de entrar
na armadilha.
Para ajudar na análise, pense primeiro se existe herança, existem atributos ou
métodos sendo aproveitados por outras classes, ou seja, existe um ‘dna’ sendo
enviado para outras classes? A SubClasse é do tipo da SuperClasse? Se a resposta
for sim, pare a análise aí. Isso é subtipagem, dentro da orientação a objetos.
Quando dizemos que um objeto é do ‘tipo de’ estamos subtipando esse objeto.
Isso é herança.
Se a resposta for não, considere se existe todo-parte. Se a resposta for sim, pergun-
te se os objetos partes ‘vivem’ sem a parte todo. Se a resposta for sim, você terá
uma agregação, se for não, terá uma composição.

Relacionamento simples entre classes


Agora que falamos de herança, agregação e composição, podemos falar de relacio-
namentos binários. Como o nome indica, eles são relacionamentos entre duas clas-
ses, representados por uma linha sólida entre essas classes.
100 Desenvolvendo Software com UML 2.0 – Definitivo

Esses tipos de relacionamentos são os mais comuns em uma aplicação voltada


para comércio e serviços.
A Figura 5.13 apresenta a perspectiva do entendimento de relacionamentos biná-
rios. Neste domínio de problema, a classe clsProprietario não tem estrutura
todo-parte com clsApartamento, muito menos herança. Então sobrou-nos um rela-
cionamento binário com a classe clsApartamento.

Figura 5.13 Relacionamento binário entre classes.

Com o andamento do projeto poderíamos, à luz da programação, chegarmos à


conclusão de que esses relacionamentos estão errados. Nada nos impedirá de capi-
tularmos e alteramos o relacionamento criado. Isso, aliás, não é incomum.

Relacionamento ternário ou superior


Existem situações em que os relacionamentos são superiores ao comum binário, já
descrito no tópico anterior. Esses relacionamentos ocorrem quando precisamos de
um resultado proveniente de várias classes.
A UML diz: “Ternary and higher-order associations are shown as diamonds con-
nected to class symbols by lines.”24 Como exemplo, temos o preço de um produto.
O preço é função de três coisas: quantidade, fornecedor e produto. A média de no-
ta de um aluno é função de três fatores: nota, disciplina e aluno em um domínio de
problema escola.
Nesses casos, dizemos que o resultado esperado se encontra em um diamante, na
notação da UML. Algumas ferramentas não dão suporte a esta notação, portanto,
não estará errado sentir-se desobrigado do uso do diamante e usar uma classe.
A Figura 5.14 dá-nos uma perspectiva deste tipo de relacionamento, pois o preço de
um apartamento é fruto de algumas coisas: o prédio e sua área comum, o proprietário
e seu desejo de vender, assim como o próprio apartamento e suas condições atuais.
Capítulo 5 Teoria de Classes 101

Poderíamos ter mais classes fazendo parte desse relacionamento; por exemplo, eu
poderia ter uma classe chamada localização; a qual, com certeza, faria parte da
composição do preço de venda do apartamento. Poderíamos ir além e incluir outra
classe: preço de mercado.
A classe clsPrecoApartamento detém a informação do preço final em função das in-
formações das outras.

Figura 5.14 Relacionamento ternário ou superior de classes.

Cardinalidade e navegabilidade de classes


A cardinalidade mostra quantos objetos uma classe pode possuir e por quantos
objetos uma classe é possuída.
A navegabilidade mostra, explicitamente, de quem é a responsabilidade de obter
as informações. A dupla navegabilidade pode ser responsável pelo fato de se obter um
desempenho inaceitável devido ao grande volume de coleções que aparecem em
um software.
Não sou contra as coleções, pelo contrário, eu as uso. No entanto, prefiro apontar
uma coleção dentro de um método, porque posso utilizá-la durante a vida daquele
método e não durante a vida de um objeto. Se tomarmos o cuidado de não preen-
chermos coleções nos métodos construtores de uma classe, quando acionarmos
102 Desenvolvendo Software com UML 2.0 – Definitivo

um determinado método, isso poderá nos dar controle sobre alguns problemas de
desempenho.
Tomemos o exemplo que segue:
A Figura 5.15 mostra a cardinalidade que existe entre as classes clsProprietario e
clsApartamento. O que a semântica indica é que um proprietário pode possuir mui-
tos apartamentos, isso é verdade. Entretanto, a semântica também nos diz que um
apartamento pode ser possuído por muitos proprietários, isso também é verdade.
Mas será que precisa ser representado desta forma?
Até aqui, nenhum código foi adicionado a nenhuma das classes. Agora, para com-
pletarmos esse entendimento, vamos colocar a navegabilidade entre as duas clas-
ses, mostrando essa responsabilidade que tanto desejamos.

Figura 5.15 Cardinalidade entre classes.

Agora estamos mostrando, na Figura 5.16, que é responsabilidade de um aparta-


mento saber quem são seus proprietários e de um proprietário saber quais aparta-
mentos ele tem. Este raciocínio parece ideal, porém, ao olharmos o código gerado
pela ferramenta case, vemos que na classe clsApartamento apareceu uma linha:
public Collection clsProprietario = new TreeSet();

Isso indica que clsApartamento terá um atributo do tipo clsProprietario e que este
tipo é uma coleção.
Capítulo 5 Teoria de Classes 103

Da mesma forma, temos na classe clsProprietario:


public Collection clsApartamento = new TreeSet();

Imagine se tivéssemos uma cadeia do tipo: Item de Nota Fiscal < - > Produto < - > De-
talhes de Produto < - > Preco.
Quando quiséssemos ver apenas o preço de hoje do
produto, teríamos de ver tudo do produto – detalhes e preço – para só então obter-
mos o preço.
Para fugir disto, devemos apenas raciocinar em cima de nossos relacionamentos e
no domínio do nosso problema. Eventualmente, você precisará informar essas na-
vegabilidades de duas mãos, porém, isso será um ato calculado.
Como sugestão:

Figura 5.16 Cardinalidade com navegabilidade.

Na Figura 5.17, vemos que agora um apartamento é responsável por indicar quem
são seus proprietários, um prédio é responsável por apontar quais e como são suas
áreas comuns, um apartamento é responsável por dizer quantos e quais são seus
depósitos.25
A classe clsApartamento ficou com os seguintes novos atributos no seu corpo:
public Collection clsDeposito = new TreeSet();
public Collection clsProprietario = new TreeSet();
104 Desenvolvendo Software com UML 2.0 – Definitivo

Já as classes clsDeposito e clsProprietario não apresentaram nenhuma modificação


digna de nota.

Figura 5.17 Cardinalidade e navegabilidade balanceadas.

A classe clsPredio ficou com o seguinte atributo:


public clsAreasComuns clsAreasComuns;

Isto não é uma coleção, visto que um prédio, neste domínio de problema, possui
áreas comuns em uma única localidade. Já a classe clsAreasComuns não apresentou
nada digno de nota.
Esse desenho deverá ser melhorado, transformando essas coleções públicas em pri-
vadas de cada classe e, adicionalmente, construindo métodos que retornem cole-
ções ou objetos (caso de clsAreasComuns na classe clsPredio) e outros métodos que
esvaziem essas coleções.
Esses métodos nos garantirão que teremos as coleções quando precisarmos e que
as destruiremos tão logo possamos.
Nenhuma cardinalidade entre clsAreasComuns e clsPredio indica que a cardinalidade é de
um objeto, ou seja, o objeto do tipo clsPredio possui um objeto do tipo clsAreasComuns.
Outras soluções seriam possíveis, como criarmos um método que retorne apenas a
informação desejada. Esse método será responsável por instanciar um objeto do
Capítulo 5 Teoria de Classes 105

tipo necessário para obter a informação e, em seguida, destruirá o objeto. Isso dá mais
trabalho, porém pode aumentar o desempenho em alguns casos.
Se quiséssemos saber os nomes dos proprietários de um apartamento, não precisa-
ríamos criar uma coleção, mas apenas um método que instancie um tipo coleção
de proprietários, pesquise seus nomes, destrua a coleção criada e retorne um array.
Notadamente, um array é sempre mais veloz que uma coleção de objetos inteira.
Contudo, isso dependerá de acordos com o pessoal de programação, de agenda e
do domínio do problema em questão, sem contar os radicais de plantão brandan-
do que a orientação a objetos foi maculada de forma irreparável.
Uma determinada cardinalidade pode ter uma observação do tipo condição {orde-
nada ASC}, indicando que o resultado daquele relacionamento é ordenado e o tipo
de ordenação. Também pode receber {Único}, que evita valores repetidos.

Pacote de classes
A possibilidade de juntarmos classes que tenham afinidade entre si é conhecida
como empacotamento. Ao empacotarmos classes estamos criando um único ar-
quivo – no mundo Windows conhecido como .dll ou .jar, no mundo Linux conhe-
cido como .so ou .jar. As classes Java são empacotadas e compiladas posteriormente
em arquivos .jar.
A criação de pacotes permite uma maior organização entre as classes que são utili-
zadas no transcorrer da construção do software em questão.
Poderíamos ter as classes clsApartamento, clsDeposito, clsPredio e, ainda, clsAreasCo-
muns e clsProprietario em um único pacote e chamar esse pacote de pctHabitacao.
Não existe limite de classes que podem estar em um pacote, o limite é a necessidade.
O relacionamento das classes são os mesmos, a notação e a semântica indicam ao
programador que desejamos criar um arquivo do tipo .jar (no Java), referente
àquelas classes.
A próxima figura apresenta a notação utilizada para um pacote na UML.
Para completar este entendimento, veja os tópicos anteriores, neste capítulo, que
tratam de visibilidade: atributo em pacote (package), operação em pacote (packa-
ge) e classe em pacote (package).

Encapsulamento
Modernamente, não há como chegarmos a uma classe sem ela estar em um pacote.
É verdade que um arquivo .class em Java é um arquivo compilado e que podemos
utilizá-lo desta forma, porém, com o crescimento da análise do projeto, você verá
que é mais fácil trabalhar com diagramas que tratam pacotes em assuntos bem es-
pecíficos do que com várias classes soltas.
106 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 5.18 Pacote de classes.

Esse princípio é o da componentização de objetos. Dessa forma, quando outra


aplicação for construída, teremos tudo o que se refere à habitação dentro do paco-
te que trata esse assunto; exporemos para o mundo apenas os métodos que dese-
jarmos, deixando no pacote toda a funcionalidade encapsulada.
Encapsulamento, em orientação a objetos, refere-se à visibilidade de atributos,
métodos e classes, e ao empacotamento das classes.
Quando é executado o método ObterMetragem da classe clsApartamento, que está den-
tro do pacote pctHabitacao, não sabemos o que o método faz exatamente; o que ele
faz com o atributo dMetragem (que é privado da classe) deixa de ser nosso problema,
se é que o método faz alguma coisa com esse atributo!
A posteridade poderá usar o pacote livremente, sem grandes questionamentos.
Tudo o que deveria ser pensado sobre a funcionalidade do pacote pctHabitacao foi
pensado, codificado e testado. O máximo que podemos fazer é usá-lo.
Sempre dou um exemplo para meus alunos, ao chegar nesse ponto: Quando entro
em um carro, instintivamente piso na embreagem e engato a primeira marcha. O
Capítulo 5 Teoria de Classes 107

que acontece com os discos de embreagem (se é que existem) não tenho a menor
idéia. Alguém já pensou naquilo e concluiu acertadamente que eu deveria ser pou-
pado deste conhecimento. Isso é encapsulamento e ocultamento de informações.
Deitel e Deitel dão um ótimo resumo na p. 334 de seu livro:26
“A orientação a objetos encapsula os dados (atributos) e métodos (comportamentos)
em objetos; os dados e métodos de um objeto estão intimamente amarrados entre si.
Os objetos têm a propriedade de ocultar informações. Isso significa que, embora obje-
tos possam saber se comunicar através de interfaces bem definidas, os objetos normal-
mente não têm permissão para conhecer como os outros objetos são implementados –
detalhes da implementação são ocultos dentro dos próprios objetos. Seguramente, é
possível dirigir bem um carro sem conhecer os detalhes sobre como os sistemas de engre-
nagem das transmissões e do escapamento funcionam internamente.”

Coesão e acoplamento
Esta é uma boa hora para falarmos de coesão e acoplamento. É com este conceito da
orientação a objetos que você vai trabalhar quando estiver pensando nas responsa-
bilidades das classes, durante o processo de análise, e preparando os seus pacotes.

Coesão
O conceito de coesão ensina-nos que uma classe deve cuidar ou, pelo menos, ten-
tar cuidar de todas as informações e ações de sua responsabilidade. Isso é o mesmo
que dizer que uma classe não deve pedir para outra classe fazer o seu trabalho.
Pensemos na classe clsApartamento. Imaginemos que existam mais duas outras clas-
ses: clsIncorporador e clsPredio. No domínio de nosso problema, um incorporador
deve vender apartamentos que estão em prédios que acabaram de ser construídos.
Apartamentos em prédios novos.
Diante desse quadro, gostaria de lhe perguntar: a inclusão de um novo prédio a ser
vendido deve ficar na classe clsIncorporador ou clsPredio? Outra pergunta: a inclu-
são de um novo apartamento deve ser feita na classe clsIncorporador, clsPredio ou
clsApartamento?
Se a sua resposta a ambas as perguntas for que depende do domínio do problema,
estará incorreta, isto é um conceito e não depende de domínio de problema.
Se a sua resposta à primeira pergunta for que a inclusão de um novo prédio deve
ser uma operação de clsIncorporador, sua resposta estará incorreta. Assim como se
respondeu que a inclusão de um novo apartamento deve estar ou na classe clsIncor-
porador ou na clsPredio, também respondeu incorretamente.
Como disse: Isso é um conceito e este diz que uma classe deve ser responsável por
seus dados e ações. Uma classe é responsável pela inclusão, alteração, consultas ou
outras operações para seus objetos, ninguém mais deve fazer isso! Guarde este con-
108 Desenvolvendo Software com UML 2.0 – Definitivo

ceito com você e sempre se pergunte de quem é a responsabilidade. Ao responder


isso, avalie se a responsabilidade está sendo transferida para mais de uma classe.
Quanto mais você encapsula suas responsabilidades dentro de uma classe, mais
esta classe está coesa. É muito desejável a alta coesão, o que ocorre quando uma
classe sabe tudo de si mesma e resolve todos os seus assuntos – a classe ideal. O
contrário disto é a baixa coesão.
A responsabilidade de uma classe resume-se a seus atributos e métodos. Por vezes,
isso não é possível, agora, seu risco é calculado.
Os problemas de termos baixa coesão iniciam-se quando outra aplicação for usar
apenas uma classe de nosso exemplo (clsIncorporador, clsPredio, clsApartamento),
mas terá de levar todas. Por quê? Porque em determinado momento, existe um mé-
todo, ou propriedade, que referencia outra classe. Como esta não está presente,
ocorre um erro em tempo de execução. Outro ponto é o uso de memória:os objetos
passam para outros as suas responsabilidades e isso provoca o alto uso desnecessá-
rio da memória.
Respondendo às nossas perguntas: A classe clsPredio deve ter um método que in-
clua seus objetos, e a classe clsApartamento também deve ter seu método de inclusão.

Acoplamento
Enquanto a coesão versa sobre uma única classe, o acoplamento versa sobre o re-
lacionamento entre duas ou mais classes.
Quanto mais relacionamentos ou mensagens uma classe tem com outra, mais alto
é o seu acoplamento. É muito desejável um baixo acoplamento. Isso significa que
os relacionamentos entre classes devem ser pensados com muita reserva. Se exis-
tem relacionamentos, quem implementar uma determinada interface de uma clas-
se, ou utilizar um método, deve levar consigo todas as classes que fazem parte
daquele conjunto acoplado.
Com relação a esse tópico, é evidente que classes com grande acoplamento devem
permanecer no mesmo pacote, nunca em pacotes diferentes. Se você passa pela ex-
periência de ter classes de uma biblioteca conversando com outra biblioteca, e essa
escala começa a se tornar incômoda, comece a pensar em ter estas classes em uma
mesma biblioteca.
Novamente, existem situações em que isso é inevitável, porém seu risco é conhecido.
Resumindo, busque uma alta coesão e um baixo acoplamento.

Assinatura de um método
É importante definirmos o que é assinatura de um método. Você ouvirá falar mui-
to de assinatura, principalmente quando o assunto for overloading ou overriding,
que veremos a seguir.
Capítulo 5 Teoria de Classes 109

A assinatura de um método é algo que identifica um método e consiste em seu


nome, número de parâmetros e tipos de parâmetros. Uma classe, em Java, não
pode declarar dois métodos com a mesma assinatura, senão um erro de compila-
ção ocorrerá (compile-time error).27
Linguagens diferentes podem implementar esses conceitos com pequenas diferen-
ças, é necessária a verificação.
Esse tipo de situação é desejável, a fim de evitarmos a construção de métodos do
tipo: obterComissao1, obterComissao2, obterComissao3 etc.

Sobrecarga ou overloading
Dar o mesmo nome a mais de um método é sobrecarga, o mesmo que overloading.
Isso é possível desde que a assinatura seja diferente, podendo ocorrer entre méto-
dos da mesma classe ou classes diferentes, como um método é herdado e outro é
declarado. Basta que a assinatura seja diferente. Assim:
public int calcularQuadrado (int x) {
return x * x;
}

public double calcularQuadrado (double y) {


return y * y;
}

O tipo de parâmetro mudou de int para double, ou seja, a assinatura foi afetada,
permitindo a sobreposição ou sobrecarga do método. Contudo,
public int calcularQuadrado (double x) {
return x * x;
}

public double calcularQuadrado (double y) {


return y * y;
}

gerará um erro de compilação (compile error – erros que ocorrem quando tenta-
mos compilar um programa).
O tipo dos parâmetros é o mesmo, somente se os tipos desses parâmetros fossem
diferentes é que não obteríamos o erro, conforme o exemplo anterior. Veja que o
tipo de retorno do método pouco importa. Mesmo com tipos de retorno diferentes
a assinatura tem de ser diferente.
Métodos não podem ser distinguidos por tipo de retorno. Métodos sobrecarregados
podem ter tipos de retorno diferentes, mas devem ter tipos de parâmetros diferentes.
110 Desenvolvendo Software com UML 2.0 – Definitivo

Adicionalmente, métodos sobrecarregados não precisam ter o mesmo número de


parâmetros. Não existe limite de sobreposição de métodos, você pode utilizá-los
enquanto for necessário.
A operação específica a ser executada é escolhida pelo compilador em run-time,
que observa a assinatura do método chamado e escolhe algum que satisfaça a assi-
natura. Não encontrando um método que satisfaça a assinatura, um erro de
run-time ocorre, o famoso run-time error.
Essa técnica é chamada de dynamic binding (ligação dinâmica). Veja a diferença
de erro de compilação versus erro em tempo de execução (compile error versus
run-time error).

Redefinição ou overriding (polimorfismo)


A redefinição de um método em classes diferentes, dentro de uma estrutura de he-
rança, é conhecida também como overriding, que é o mesmo que polimorfismo.
A palavra provém de duas palavras gregas: muitas e formas. Page-Jones dá-nos
uma definição que considero muito boa:28
“Polimorfismo é a habilidade pela qual uma única operação pode ser definida em mais
de uma classe e assumir implementações diferentes em cada uma dessas classes.”
Acrescento que com a mesma assinatura.
É evidente que o ganho nesse caso somente tem sentido se escrevermos código dife-
rente em ambos os métodos; por isso dizemos: “Implementar de forma diferente”.
Como já falamos no tópico de herança, quando se herda, herda-se tudo. Veja que
devem ser respeitados aspectos de visibilidade, porém o conceito geral é este.
Se assim é, caso tenhamos uma classe clsKitchnete, que herdasse de clsApartamento, e
esta tivesse o método ObterMetragem(), escrito igualmente está em clsApartamento e
clsKitchnete, teríamos o polimorfismo.
Se esse método não existisse em clsKitchnete, o compilador sem dúvida o buscaria
na classe ancestral – SuperClasse clsApartamento; se o encontrasse, o executaria,
caso contrário, um erro em tempo de execução seria gerado.
Isso significa que, estando um método declarado na SuperClasse e não nas SubClas-
ses, o método da SuperClasse é executado. Caso o método seja definido na SubClasse,
ele é executado em detrimento do método existente na SuperClasse. O método da
SubClasse anula o método da SuperClasse.
No caso do polimorfismo, a assinatura dos métodos precisam ser as mesmas. Um
método estático não pode ser sobrescrito, isso gerará um erro de compilação em
Java; também ocorrerá um erro de sintaxe se um método em uma SuperClasse e
um método em sua SubClasse têm a mesma assinatura, mas um tipo diferente de
retorno. Veja que, aqui, o tipo de retorno importa, ao contrário da sobreposição.
Capítulo 5 Teoria de Classes 111

Bem, dito toda essa teoria, vamos bagunçar... A redefinição de um método de Su-
perClasse em uma SubClasse não precisa ter a mesma assinatura que o método da
SuperClasse. Essa redefinição não é uma anulação de método, mas, simplesmente,
um exemplo de sobrecarga de método em classes diferentes.29
Veja, na Figura 5.19, o exemplo de polimorfismo ocorrendo entre clsKitchnete e
clsApartamento. A forma de se medir uma quitinete, por alguma razão desconheci-
da, é diferente da que se usa em um apartamento. O método da SuperClasse –
clsApartamento (ObterMetragem()) foi sobrescrito por clsKitchnete. Existe herança en-
tre essas duas classes.
A sobreposição é mostrada na classe clsPrecoApartamento, que apresenta duas for-
mas diferentes de calcular o preço do apartamento: uma sem parâmetro algum e
outra com o parâmetro preço de mercado, indicando que seu cálculo leva em con-
sideração o preço de mercado do apartamento.

Figura 5.19 Polimorfismo e sobrecarga.


112 Desenvolvendo Software com UML 2.0 – Definitivo

Estereótipos
Quando você necessitar representar algo que a UML não fornece, basta estereoti-
par algo que ela já tem.
Um estereótipo tem a notação de algo existente, porém, com a semântica diferente.
Quando estávamos no capítulo que trata de Caso de Uso, tratamos de pontos de
extensão e inclusão, mas não custa relembrar. A próxima figura mostra-nos que
existe um Caso de Uso chamado Calcular Fidelização Especial. Veja o Caso de Uso
chamado Fidelizar Cliente Locador e Cliente Beneficiário, que indica uma fórmula
de calcular uma fidelização. O Caso de Uso Calcular Fidelização Especial estende o
cálculo proposto por Fidelizar Cliente Locador e Cliente Beneficiário de alguma for-
ma. Como representar isso? Existe uma seta tracejada na UML cuja semântica repre-
senta uma dependência. Usei a mesma seta com os símbolos de << > >, e dentro desses
escrevi a palavra extend. Extend é um estereótipo de dependência. A semântica da de-
pendência foi alterada para indicar que um Caso de Uso em determinado ponto esten-
de – melhora – o que já existe em outro Caso de Uso.

Figura 5.20 Pontos de extensão e estereótipos na UML.


Capítulo 5 Teoria de Classes 113

Calcular Fidelização Especial estende a forma de cálculo que existe no cenário


principal 5 (Calcula a Fidelização) do Caso de Uso Fidelizar Cliente Locador e
Cliente Beneficiário.
Existem outros tipos de estereótipos, como <<include>>, indicando que um Caso de
Uso inclui um outro Caso de Uso inteiro, ou apenas um ou alguns cenários principais.
Muitos utilizam o estereótipo <<usa>> ou <<uses>> indicando que tal coisa usa outra,
creio que isto é desnecessário.
Estereótipos podem ser usados em absolutamente qualquer diagrama, desde que
você tenha necessidade.
No diagrama de classes, temos a necessidade de representar uma tela de computa-
dor, por exemplo, uma tela HTML ou mesmo um arquivo XML. Como represen-
tar isso na UML?
Uma tela HTML tem nome (o nome do arquivo), propriedades (background,
bgcolor etc.), apenas não podemos dizer que uma tela HTML possui métodos.
Esses existem em scripts JavaScript e podem estar inclusive em arquivos separa-
dos, incluídos por uma tag especial referenciando um arquivo com extensão ‘.js’.
Nada disso, porém, invalida a possibilidade de estereotiparmos uma tela HTML
como uma classe, a fim de a representarmos em um diagrama.
A Figura 5.21 mostra o nosso pacote pctHabitacao, agora sendo acessado por uma
tela HTML (frm_InteresseEmCompra). Esta tela é uma classe estereotipada; isso foi
muito bom, porque agora posso representar elementos que não tinha previsto de
uma forma mais clara. Adicionalmente, estereotipei mais uma classe, agora dan-
do-lhe o estereótipo de JavaScript que, por composição, é parte de um todo
HTML.30
O Apêndice A relata os estereótipos mais comuns encontrados em um modelo e
também os que estavam em vigor até a UML 1.X e foram descontinuados na UML 2.0.
Você pode criar um estereótipo, mas isso deve ter um limite. Um bom lugar para
relacionar esses limites é o documento Nomenclatura, com sua semântica e uso.
Isso, com certeza, vai evitar muitos problemas de interpretação.

Classe utility
A classe utility é um estereótipo. Nela, colocamos todos os métodos que, por algu-
ma razão, não conseguimos identificar a qual classe pertencem. Por exemplo, o
método CalcularCPF: se acharmos que seu proprietário é a classe funcionário, como
ficarão nossos clientes ao necessitarem de uma validação de CPF? Terão de falar
com os funcionários? Isso não parece bom.
Uma classe com o estereótipo <<utility>> ou <<utilitário>> pode resolver. Agora,
tanto funcionários como clientes poderão ter sua validação de CPF sem que isso
represente uma excrescência da orientação a objetos.
114 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 5.21 Estereótipos no diagrama de classes.

Conclusão
Não era minha intenção, neste capítulo, abordar absolutamente todos os aspectos
da orientação a objetos. Seria necessário um outro livro, ou livros, somente para
cobrir este assunto de forma a esgotá-lo.
Neste capítulo, informei as principais considerações que devem ser observadas du-
rante a construção de um diagrama de classes.
Mesmo assim, acredito que o volume de informações dado pode assustar um pou-
co. Todavia, tranqüilize-se, porque raramente você vai utilizar, ou participar, to-
dos os conceitos dados neste capítulo; ademais, alguns aspectos mudarão ao longo
Capítulo 5 Teoria de Classes 115

da análise do domínio do problema; outros mudarão, inclusive na fase de constru-


ção, por exemplo, o aspecto visibilidade sofrerá alterações quando chegar às mãos
de quem programa.
Creio que é fundamental saber que existe um determinado recurso; assim, quando
precisar, você saberá onde buscá-lo.
No próximo capítulo, vamos iniciar a construção de nosso diagrama de classes
para um Caso de Uso do software de Locação de DVDs pela Internet, e você pode-
rá observar que não utilizaremos todos os conceitos dados neste capítulo, apenas
alguns cobrirão nossas necessidades na construção desse diagrama.

Exercícios
1. Uma classe é o mesmo que um objeto? Explique.
2. Qual a diferença entre método e operação?
3. O que designa as responsabilidades de uma classe?
4. O que é a herança?
5. O que é a herança múltipla e quais os seus perigos?
6. O que é uma interface?
7. Quais as visibilidades de uma classe?
8. Qual a diferença entre as visibilidades ‘pacote’ e ‘protegida’ de uma classe?
9. O que são modificadores de uma classe?
10. Uma classe abstrata é o mesmo que uma interface?
11. Como evitamos que códigos externos ao nosso pacote efetivem uma herança de nos-
sas classes?
12. Uma única classe pode controlar vários segmentos de seus objetos? Como?
13. Por que atributos devem ter suas visibilidades marcadas como privadas?
14. Podemos usar modificadores em atributos? Explique.
15. Para que serviria um atributo marcado como estático?
16. Qual a visibilidade que devemos adotar em métodos, perante a orientação a objetos?
17. Um método não estático consegue alcançar um atributo estático?
18. Uma operação, dentro de uma classe abstrata, também será abstrata?
19. Qual é a diferença entre agregação pura e composição de classes?
20. O que a navegabilidade indica, se representada no diagrama de classes?
21. Por que separamos classes em pacotes?
22. Qual a diferença entre coesão e acoplamento? Para que os utilizamos?
23. Como se compõe a assinatura de um método?
24. Qual a diferença entre sobrecarga e polimorfismo?
25. Para que utilizamos os estereótipos na UML?
26. O que o estereótipo de utility designa?
Quem pensa grande também erra grande.
MARTIN HELDEGGER

É impossível para um homem aprender aquilo que ele


acha que já sabe.
EPÍTETO

N este capítulo vamos construir um diagrama de classes que atenda ao Caso de


Uso Locar DVD de nosso software de locação de DVDs pela Internet. Não
custa relembrarmos os passos anteriores. Primeiro, descobrimos as intenções de
nosso cliente potencial e redigimos um documento Visão. Em seguida, após a acei-
tação de nossa proposta de construção de software, criamos um diagrama de Caso
de Uso que atendeu, pelo menos inicialmente, ao documento Visão.
Esse diagrama nos informava as grandes áreas a serem tratadas no software. Cha-
mamos esse diagrama de nível 0 ou <<sistema>>, veja a Figura 2.2. A intenção era
explodir cada Caso de Uso que apareceu nesse diagrama em outros diagramas de
Casos de Uso, mais específicos. Isso foi o que aconteceu conforme as Figuras 3.3 e
3.4. A versão da Figura 4.8, é a última versão do diagrama de Caso de Uso envol-
vendo o processo de cadastrar. Os outros Casos de Uso da Figura 2.2 deverão pas-
sar pelo mesmo processo.
Verificamos que um software pequeno poderá atingir aproximadamente dez dia-
gramas de Casos de Uso e, em cada diagrama, teremos uma média de oito a dez Casos
de Uso para trabalharmos. Isso nos dá cerca de 80 Casos de Uso.
Capítulo 6 Diagrama de Classes 117

É assim que Larry Constantine, no prefácio do livro de Page-Jones, informa que


participou com ele em um projeto de grande porte, que tinha 340 Casos de Uso.1
Para iniciarmos nosso trabalho, atacamos uma das partes mais críticas de nosso
software, qual seja, locar DVD, veja a Figura 3.2 no Capítulo 3. Descrevemos esse
Caso de Uso em detalhes e agora estamos prontos para iniciarmos a construção de
um diagrama de classes que atenda a ele.
Ao iniciar um diagrama de classes novo, não me preocupo em dar um nome a ferra-
menta já coloca ali um nome default ‘Class Diagram xpto’. Não dou um nome ini-
cial, porque isso implica que já sei o assunto do diagrama por inteiro.
Um diagrama de classes pode atender a diversos Casos de Uso, e não a um único.
Se você tem um diagrama de classes inteiro, atendendo apenas a um Caso de Uso,
provavelmente este Caso de Uso está enorme e seus conceitos estão errados.
Quando documento algo, essa documentação está na descrição do Caso de Uso ou
na(s) classe(s) que realiza(m) aquele Caso de Uso.
Usamos o termo ‘realizar’, neste contexto, para designar quem é o responsável pelo
atendimento de determinado cenário principal ou alternativo de um Caso de Uso.
Centralizo essa documentação nesses dois locais, visando a evitar a multiplicidade
de informações que podem deixar um desenvolvedor maluco. Em todos os demais
diagramas, a outra forma de documentação em que gasto algum tempo são as no-
tas da UML, feitas evidentemente dentro dos diagramas.
A Figura 6.1 apresenta uma visão desse recurso da UML – (Nota) – que pode ser utiliza-
do em qualquer diagrama. Na nota você escreve o que achar interessante para aquele
momento da modelagem. Essas notas são muito usadas em diagramas de seqüência ou
estados, que requerem detalhamentos que a modelagem não consegue resolver.
Adicionalmente, podem existir várias notas ligadas à mesma classe. O uso dessa
notação é pessoal.

Figura 6.1 Nota da UML referenciando a classe clsApartamento.


118 Desenvolvendo Software com UML 2.0 – Definitivo

Como fazer o diagrama de classes em ambiente de time de


desenvolvimento
Em um ambiente com time de desenvolvimento, com certeza, você estará respon-
sável por um diagrama de Casos de Uso, que envolverá, digamos, dez Casos de
Uso. As descrições desses Casos de Usos que tratam de uma determinada macroa-
tividade estarão sob sua responsabilidade. É senso comum que a melhor pessoa
para fazer o diagrama de classes desses Casos de Uso é você, enquanto outros cole-
gas estão criando diagramas de classes referentes a outros Casos de Uso. Passa a
ser natural que as classes que eles estão criando sejam, também, as classes de que o
seu diagrama precisa.
Para evitar a duplicidade de classes, métodos e atributos, você necessitará de algo
que controle as versões com as quais você e seus colegas estejam trabalhando. Para
fazer esse trabalho, sugiro o software CVS (http://www.cvshome.org – software de
controle de versões). A última versão do seu projeto, com todos os diagramas e
classes, estará disponível no banco de dados do CVS. Copie essa versão localmente
para a sua máquina. Assim, as classes criadas por outros colegas estarão disponí-
veis para uso; basta você arrastar e soltar a classe ou qualquer outro elemento no
diagrama com o qual estiver trabalhando.
Existem versões visuais:
1. Smart CVS em http://www.smartcvs.com. Neste link, você encontrará uma versão
free do smart CVS, que é a SmartCVS Foundation; a outra versão (Professional)
é paga, porém com preços muito irrisórios no tempo em que escrevo este texto;
2. WinCVS / MacCVS / gCVS em http://cvsgui.sourceforge.net/, versão distribuí-
da sobre GPL e escrita em C++;
3. TortoiseCVS em http://tortoisecvs.org/, que permite trabalhar com o CVS di-
retamente do Windows Explorer.
Para que esse controle de versões seja possível, você necessitará de uma ferramenta
de modelagem que dê suporte a um software de controle de versões. Verifique a
documentação da sua ferramenta de modelagem UML.

Conceito, especificação e implementação


Fowler e Scott, acertadamente, propõem três momentos distintos quando estamos
fazendo diagramas de classes. Esses momentos são: Conceitual, Especificação e
Implementação.2
No panorama conceitual, resolvemos o negócio; na especificação, tratamos as
classes já como software, indicando tipos de retorno, parâmetros de entrada e saí-
da e tudo o que envolva suas interfaces expostas ao mundo; no panorama de im-
plementação, resta-nos colocar as classes em pacotes e código nestas.
Capítulo 6 Diagrama de Classes 119

Ao iniciar o diagrama de classes, misturo as duas primeiras partes, resolvo os cená-


rios dos Casos de Uso e já me preocupo com tipos e interfaces, sei que isso pode
mudar no momento da implementação, porém acredito que ganho tempo sem per-
der a qualidade. Ademais, tenho o sangue do programador nesse momento e rara-
mente consigo fugir disso.

Métodos repetidos
Outro detalhe importante é que Ambler3 sugere que métodos repetitivos ou que
certamente estão nas classes podem e devem ser suprimidos. Neste ponto, pense:
Não é verdade que quase 80% de suas classes precisarão ter os métodos incluir, al-
terar, excluir, obterHum, obterMuitos, obterWhere e outros que sua organização
julgar necessários. Se a resposta for sim, vamos fazer uma multiplicação básica.
Citei seis métodos, supondo uma gama de cem classes e considerando 80% destas
com necessidade para esses métodos – estamos falando de 480 métodos escritos e
documentados. Como resolver? Na décima classe em que você estiver documen-
tando esses métodos, aposto que já terá desistido.
Minha sugestão é que você, na reunião inicial de software, já defina com toda a
equipe que esses métodos estarão bem documentados em três ou cinco classes que
tratam a parte mais crítica do software. Informe quais são essas classes. Se você ne-
cessitar de mais classes do que o número citado, inclua-as. Nessas classes informe:
o tratamento para chaves primárias e estrangeiras do banco de dados; se a exclu-
são é lógica ou física e demais detalhes que acreditar necessários.

Criando as classes, métodos e atributos para o Caso de Uso


Locar DVD
Vamos passar a nos concentrar na realização do diagrama de classes para o Caso
de Uso Locar DVD.
Inicialmente, atentamos a aspectos de negócio, e o Caso de Uso é um bom início
para isso. Resolvo cada cenário principal em um método. Conforme vou avançan-
do na análise, percebo que assuntos afins, ou seja, cenários correlatos, devem resi-
dir na mesma classe. Ao desconfiar que o assunto é correlato, porém de uma
categoria ainda não detectada, crio uma nova classe, e nela, um novo método.
Para realizarmos esse Caso de Uso no diagrama de classes, penso sempre que um
cenário principal é um método em uma classe; com o tempo isto muda, porque,
por exemplo, uma simples composição pode eliminar a necessidade de se escrever
métodos em uma classe. Isso não é a Bíblia; eventualmente você pode encontrar
dois ou mais cenários principais que podem ser resolvidos em um único método.
Adicionalmente, os cenários alternativos podem não ser métodos, e sim ifs, ao lon-
go de um método. Nessa mesma situação incluo os requisitos especiais.
120 Desenvolvendo Software com UML 2.0 – Definitivo

Os dados descritos na seção dados dos Casos de Uso, serão (quase que com 99%
de acerto), atributos de uma ou várias classes. Aqui, o segredo é pensar em – nova-
mente – coisas afins. Você não colocaria número de vagas da garagem na classe
imposto, colocaria?
Outro ponto comum é que a maioria, senão todos, dos atores dos Casos de Uso se-
rão classes no diagrama de classe. Isto não é um item com qual me preocupo logo
no início do diagrama; incluo essas classes à medida que forem necessárias.
Antes de enviar um e-mail para este pobre escritor, não esqueça que este é o meu
diagrama de classes, o seu pode ser diferente e, assim, chegaremos ao mesmo pon-
to comum. O meu diagrama de classes não será o seu. O capítulo que trata do dia-
grama de seqüência fará mudanças significativas nesse diagrama. Se você vê algo
estranho na minha lógica agora, aguarde para saber se isso não foi resolvido no
diagrama de seqüência, nos próximos capítulos.
A finalidade aqui não é resolver o software inteiro, mas sim mostrar-lhe um pas-
so-a-passo de vida real, um norte para que você se baseie.
Desta forma, passarei por 14 fases onde vou alterar classes, retirando ora atribu-
tos, ora métodos. Vou criando as classes paulatinamente, passando por todos os
cenários principais, alternativos e requisitos especiais do Caso de Uso Locar DVD.

Primeiro cenário principal do Caso de Uso Locar DVD


1 Visualiza os grupos de produtos existentes, a partir de uma lista criada logo na entrada
do cliente na loja, através da descrição do grupo. Os grupos são: Infantil, Adulto,
Ação/Policial, Antigos, Romance, Comédia, Drama e todos. A opção todos indica que
o cliente locador poderá efetuar uma busca por todos os grupos existentes – Cliente
Locador, Cliente Beneficiário.
Vamos permitir que esse cliente visualize uma lista de grupos existentes. Como há
vários grupos e, provavelmente, o cliente queira, no futuro, incluir novos grupos,
criei uma classe sem nome que tem um método +curObterListaGrupos(). Este terá de
ser executado em algum lugar, por isso criei uma classe que permite o trabalho
com grupos. É responsabilidade da classe (por enquanto sem nome) saber quais
grupos quer, daí a navegabilidade estar apontando para a classe clsGrupos. Tam-
bém é verdade que, quando forem solicitados os grupos, pode ser solicitado um ou
muitos, daí a cardinalidade 1..*.
A navegabilidade, aqui, permite que seja criada uma coleção na classe sem nome.

Figura 6.2 Diagrama de classes, fase 1.


Capítulo 6 Diagrama de Classes 121

O cenário está mal-escrito na sua parte final, porque ou o cliente fará uma escolha
dentre os grupos conhecidos ou solicitará uma busca. Uma busca será outro cená-
rio principal. Este cenário principal estará melhor assim:
1 Visualiza os grupos de produtos existentes, a partir de uma lista criada logo na entrada do
cliente na loja, através da descrição do grupo. Os grupos são: Infantil, Adulto, Ação/Policial,
Antigos, Romance, Comédia e Drama – Cliente Locador, Cliente Beneficiário.

Pronto, o cenário está atendido. Um outro ponto é que o ator deste cenário é tanto
o cliente locador como cliente beneficiário. O diagrama de Caso de Uso, mostrado
na Figura 4.7, informa-nos que existe generalização entre cliente locador e cliente
beneficiário, o que já nos dá uma pista no nome da classe, inicialmente sem nome.
Poderíamos criar uma classe cliente, SuperClasse abstrata, de onde existiriam he-
ranças de cliente locador e cliente beneficiário. Contudo, respeitarei o diagrama de
Caso de Uso indicando que existem apenas dois tipos de clientes, e um depende de
outro para existir. Coisas de um são aproveitadas no outro. Por essa razão, preferi
criar uma SuperClasse clsClienteLocador com uma SubClasse clsClienteBeneficiario.
Se o andamento da análise requerer, mudo o approach.
Repare que já iniciei a preocupação com visibilidade, atributos e tipos pensando
em Java.

Figura 6.3 Diagrama de classes, fase 2.

Vamos para o próximo cenário principal.

Segundo cenário principal do Caso de Uso Locar DVD


2 Escolhe determinado tipo de grupo selecionando sua descrição – Cliente Locador,
Cliente Beneficiário.
122 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 6.4 Diagrama de classes, fase 3.

O cliente precisará escolher um grupo para iniciar suas buscas de produtos; deve-
mos supor que temos muitos produtos em cada grupo, assim não é possível sim-
plesmente mostrarmos todos os produtos daquele grupo.
Imaginemos que ele obtém um grupo e informa em um formulário algo para bus-
car referente aquele grupo; esse método recebe uma string, a descrição do grupo e
terá a responsabilidade de capturar um número que identifique o grupo, para faci-
litar as buscas, e retorná-lo. Esse valor será iCodGrupo.
Parece que estou repetindo os métodos entre as classes, mas faço isso para não me
perder. Mantendo os mesmos nomes, quando uma classe chegar a 30 ou 40 méto-
dos saberei quem acessa o quê.
Se surgir a pergunta – E quem acessa os métodos das classes clsClienteLocador e
clsClienteBeneficiario? A resposta estará no diagrama de seqüência, onde a interfa-
ce gráfica aparece no formato de tela.
Vamos ao próximo cenário principal. Até aqui, isso parece estar bom. É um ponto
de partida.

Terceiro cenário principal do Caso de Uso Locar DVD


3 Escolhe o tipo de busca desejada, a partir de uma descrição. Essa busca pode ser por nome
de um ator, nome do diretor ou título do filme – Cliente Locador, Cliente Beneficiário.
Aqui ele apenas escolhe um tipo de busca. Precisamos saber qual é este tipo de bus-
ca, para implementar performance na seleção do banco de dados. Então, ele passa
uma descrição do tipo de busca e obtemos um número que a identifique.
Vamos permitir que nosso cliente faça uma busca. Este é o cenário principal 4.
Capítulo 6 Diagrama de Classes 123

Figura 6.5 Diagrama de classes, fase 4.

Quarto cenário principal do Caso de Uso Locar DVD


4 Informa o texto relativo à busca, com mais de três caracteres – Cliente Locador, Clien-
te Beneficiário.
Este cenário não requer qualquer informação em classes, é uma parte do processo
da qual a interface gráfica cuidará. O próximo cenário principal pode ser aglutina-
do a este para darmos significado nas classes.

Quinto cenário principal do Caso de Uso Locar DVD


5 Visualiza os resultados da busca através de uma relação. A relação é mostrada por
aproximação do texto pedido. A relação deve aparecer por percentual de aproxima-
ção. Os títulos com maior aproximação deverão ser apresentados em primeiro lugar.
O cliente locador visualiza, também, o percentual de aproximação. Assim, a lista mos-
trada inicia em 100% e termina em 5%. A lista deve conter 20 nomes possíveis em
cada página. Junto à lista, resultado da pesquisa, o cliente locador vê uma cópia fiel da
frente da capa do DVD, por meio de uma figura. Ele pode visualizar detalhes como:
nome do filme, resenha, atores principais e coadjuvantes, prêmios recebidos, quantas
vezes esse DVD foi locado, críticas de dois jornais, ano de lançamento e opinião de até
dez locadores desse DVD – Cliente Locador, Cliente Beneficiário.
Agora temos uma boa significação para as nossas classes. O cliente informa o tex-
to de busca e, mediante o tipo de busca, obtém uma lista de aproximação descen-
dente. Supondo que ele tenha pedido o tipo de busca por título do filme, e seu texto
foi ‘morango’, então poderia ver uma lista com:
» Morango e Chocolate (1993), direção: Tomás Gutierrez Alea.
» Morangos Silvestres (1957), direção: Ingmar Bergman.

Cada linha será um link permitindo-lhe ver detalhes do filme escolhido, conforme
o cenário principal 5. O cenário principal pede que isso seja mostrado ao lado dos
124 Desenvolvendo Software com UML 2.0 – Definitivo

nomes dos filmes, mas isso não dará usabilidade. Vamos implementar um link
que, ao ser clicado, mostra detalhes daquele filme.
O caminho que penso para este cenário é a execução do método clsCliente.iObterTipo-
DeBusca (strDescricao:String) – clsTiposDeBusca. iObterTipoDeBusca (strDescricao:String).
Em seguida clsCliente.curObterResultadoLista (iTipoDeBusca:int, strTexto:String) –
clsFilmes. curObterResultadoLista (iTipoDeBusca:int, strTexto:String).
Descobre-se, qual é tipo de busca, e o método curObterResultadoLista retorna a lista
desejada que possibilitará a quem chamar montá-la da melhor forma, por exem-
plo, em uma tabela HTML. O método curObterResultadoLista recebe dois parâme-
tros: um é o tipo de lista e o outro a string que será pesquisada.
A composição que aparece entre clsFilmes e clsAtores é devida ao fato de que, para
esse software, não existe sentido em termos atores sem filmes. Também existe uma
relação todo-parte entre ator de um filme e um filme. Adicionalmente, é responsa-
bilidade de um filme saber quem são seus atores, e esses podem ser muitos.
Vamos ao próximo cenário principal.

Figura 6.6 Diagrama de classes, fase 5.

Sexto cenário principal do Caso de Uso Locar DVD


6 Seleciona determinado filme, por meio da descrição, e adiciona à cesta de locações –
Cliente Locador, Cliente Beneficiário.
Capítulo 6 Diagrama de Classes 125

Ao pensar neste cenário, verifiquei novamente os tipos de busca, que são: nome de
um ator, nome do diretor ou título do filme. O nome do ator do filme está resolvi-
do com a classe clsAtores, o nome do filme está resolvido com a classe clsFilmes,
mas o do diretor não.
Um diretor pode ter realizado vários filmes e a busca pelo diretor precisava ser im-
plementada, daí eu ter criado a classe clsDiretores. Esta classe, assim como clsAto-
res, faz parte de clsFilmes, daí a composição entre elas.
Quando iniciei o raciocínio sobre o cenário 6, pensei que o cliente poderia ter uma
classe que representasse sua cesta de compras, a qual seria responsável por saber
que filmes ela possui.
Finalmente, é responsabilidade do cliente saber qual é a sua cesta de locações, mas
não é responsabilidade de uma cesta de locações saber qual é o seu cliente, daí a
navegabilidade de clsCliente para clsCestaLocacao.
Não há método na classe clsCliente para implementar a adição de filmes, porque
bastará a coleção de filmes, existente em clsCestaLocacao, que já implementa a adi-
ção e remoção.
Agora a cesta de locação é um atributo de cliente. Os filmes fazem parte da cesta
do cliente; uma cesta é composta de filmes, daí a composição entre essas duas clas-
ses. Quando quiser saber um filme de uma cesta bastará uma referência clsClien-
te.clsCestaLocacao.colclsFilmes.strObterNomeDoFilme (iCodFilme:int), ou qualquer outro
dado de filme. Estes métodos eu suprimi seguindo a regra da qual falei no tópico
“Métodos repetidos”, anteriormente. Por isso, também, retirei a navegabilidade
de cliente com grupos. Não faz sentido cliente ter o atributo grupos, ele apenas usa
um grupo para incluí-lo em uma busca. Provavelmente uma classe de front-End
implementará essa necessidade em grupos.
Pelas mesmas razões, não faz mais sentido termos métodos em filmes, para obter-
mos atores e diretores. Estes são atributos de filmes, portanto, bastará a referência
a métodos que retornem qualquer atributo, tanto em atores como em diretores, as-
sim como fiz em cesta de locações.
Para atender ao sexto cenário principal, incluí o método iObterFilmeParaCesta (iCod-
Filme:int) na classe clsClienteLocador. Este método vai receber o código do filme,
pois essa informação será dada na interface gráfica, mesmo que o cliente não veja
esse código. É dessa forma que clsClienteLocador acionará a classe clsCestaLocacao:
adicionando o filme selecionado à coleção a que pertence aquele cliente.
A Figura 6.7 apresenta um panorama dessas mudanças. Frisei o desenho, com méto-
dos inadequados, para chamar a atenção de que é muito fácil cometermos um deslize
de raciocínio metodológico. Seus diagramas tendem a mudar durante esta fase, até
que você se sinta seguro de que a solução para o domínio do problema foi alcançada.
126 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 6.7 Diagrama de Classes, fase 6, com acertos de métodos e navegabilidade.

Sétimo cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 7, que nos indica:
7 Deduz a quantidade do DVD escolhido do estoque de cópias – Site.
Para atender a este cenário principal, criei a classe clsEstoqueLocacoes, que possui
dois métodos: um que adiciona e outro que deduz o DVD do estoque disponível
para locações. Esses métodos deverão ocorrer sempre que os métodos de adição e
subtração de um DVD na clsCestaLocacao acontecer. Essa classe, clsEstoqueLocacoes,
será responsável pelas operações de estoque no banco de dados. Por enquanto, ela
aparece sem atributos, porque será função do Caso de Uso Controlar Estoque defi-
nir quais os atributos dessa classe e se existem outros métodos envolvidos aqui.
Como não é responsabilidade deste Caso de Uso efetivar esse controle, não abor-
darei esse assunto aqui.
O fato de o ator ser o site, em nada afeta o processo. A descrição do Caso de Uso
apenas indica, com isso, que a operação é feita de forma transparente e automática.
Capítulo 6 Diagrama de Classes 127

Figura 6.8 Diagrama de Classes, fase 7.

Não criei uma classe site, porque resisto à criação de classes sistema, site, aplica-
ção, programa etc. Tendemos a transformar essas classes em verdadeiros elefantes
brancos, fazendo de tudo um pouco na solução. Vamos ver se isso será necessário
mais para frente.

Oitavo cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 8, que nos indica:
8 Executa a busca novamente a fim de obter outros títulos – Cliente Locador, Cliente Be-
neficiário.
Toda a implementação necessária para atender a este cenário principal já foi feita.
Este cenário apenas indica o loop no qual o usuário pode entrar, caso queira locar
mais de um filme. Nada será feito para este cenário, a menos que tivéssemos uma
regra que nos indicasse que os clientes têm limites de locações; porém nada foi fa-
lado a respeito.

Nono cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 9, que nos indica:
128 Desenvolvendo Software com UML 2.0 – Definitivo

9 Identifica-se, por meio de seu login e senha de cliente locador ou cliente beneficiário –
Cliente Locador, Cliente Beneficiário.
Este cenário principal indica que o cliente que está fazendo uma seleção de DVDs
para locação já é cadastrado e possui um login e uma senha, que são validados
contra algum banco de dados.
Para satisfazer este cenário, acrescentei os atributos privados (strLogin e strSenha)
na classe clsCliente, e fiz o mesmo na classe clsClienteBeneficiario. Deixei-os como
privados, para tratá-los de forma diferente.
Criei um método que faz a checagem desses valores contra um banco de dados:
: Boolean.
#bValidaLogin (strLogin:String, strSenha:String)
Caso este método retorne true, teremos um usuário válido, tanto cliente como
cliente beneficiário. Como o método tem visibilidade protegida, ele pode ser visto
e usado pela classe clsClienteBeneficiario sem grandes problemas.
Quando o cadastro do usuário cliente ou beneficiário ocorre, eles criam as senhas
e seus nomes de login por meio destas mesmas classes, porém, isto não é assunto
deste Caso de Uso. Os colegas que tratam desse assunto vão usar nossas classes
com o mecanismo do CVS.
A próxima figura, dá-nos um panorama de como esse método e atributos ficaram.

Figura 6.9 Diagrama de classes, fase 9.


Capítulo 6 Diagrama de Classes 129

Décimo cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 10, que nos indica:
10 Valida o login do cliente locador ou do cliente beneficiário, certificando-se de que ele
já se encontra cadastrado, e verifica se o cliente locador está em estado de “Aprovado
para Locação”. (Ver Caso de Uso Controlar Estado de Cliente Locador e Cliente Be-
neficiário) – Site.
Não nos resta fazer nada com relação a este cenário principal. As providências que
tomamos, com relação ao cenário principal 9, já atendem este cenário.
Caberá ao método bValidaLogin() verificar se:
» o cliente está cadastrado;
» o estado do cliente é “Aprovado para Locação”.
Outro Caso de Uso cuida de controlar esse estado: Controlar Estado de Cliente
Locador e Cliente Beneficiário.

Décimo primeiro cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 11, que nos indica:
11 Informa o número do cartão de débito para permitir o débito da locação – Cliente Lo-
cador.
Aqui, os dados para débito da locação devem ser informados. Essas informações
somente são possíveis para pagamento pelo cartão de débito.
Para atender a este cenário, criei a operação #bValidaRealizaTef (strCartaoDebi-
to:String) : Boolean na classe clsCliente. Esta operação será responsável por validar
o cartão informado e ainda fazer a transação de TEF (Transferência Eletrônica de
Fundos) entre as entidades financeiras conveniadas e a loja virtual.
Esse método será executado contra um pacote (TEF), que expõe alguma interface
entre a instituição financeira e a loja virtual. Normalmente, operações de TEF são
encapsuladas pela instituição financeira. Você recebe a documentação mostrando
como acessar essas interfaces e, também, como ler seus retornos. Isso não é algo
que terá liberdade de alterar ou criar métodos e atributos, daí eu ter criado o paco-
te TEF e uma classe que represente a interface da instituição financeira que está
conveniada à loja virtual.
A Figura 6.10 apresenta um panorama de como ficaram essas transformações.

Décimo segundo cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 12, que nos indica:
12 Valida o cartão de débito informado – Site.
Novamente, nada há a fazer com relação a este cenário principal. Já resolvemos a
sua necessidade no cenário principal 11. O método bValidaRealizaTef da classe
clsCliente valida e realiza a operação de TEF, já citada.
130 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 6.10 Diagrama de classes, fase 11.

Décimo terceiro cenário principal do Caso de Uso Locar DVD


Vamos ao cenário principal 13, que nos indica:
13 Informa o tempo aproximado de entrega, em horas, no endereço listado pelo cliente
locador como endereço de entrega – Site.
Para atender a este cenário principal, criei um método na classe clsCliente, #ObterEn-
derecoEntrega (strEnderecoEntrega:String) : String, tornando necessária a criação de
um atributo que é o de strEnderecoEntrega.
Ficou evidente que o endereço de entrega pode ser um que não é o endereço resi-
dencial ou comercial do cliente. Assim, ele pode receber seus filmes em outro local
que não o informado no cadastramento inicial. Somente poderá haver um endere-
ço de entrega das locações.
Capítulo 6 Diagrama de Classes 131

Creio que uma boa solução é mostrar o endereço de entrega cadastrado, com esse
método – ObterEnderecoEntrega – e permitir que o endereço seja alterado. Isso deve
ocorrer em outro método bAlterarEnderecoEntrega (strEnderecoEntrega:String), que
dará novo valor à propriedade strEnderecoEntrega.
Vamos olhar a próxima figura, que mostra essa evolução.

Figura 6.11 Diagrama de classes, fase 13.

Cenários alternativos
O primeiro cenário alternativo nos diz:
1.1 Escolhe um filme que esteja em promoção ou lançamento, logo que entra na loja, sem
recorrer a nenhuma busca. (Ver Caso de Uso Administrar Promoções.) – Cliente Lo-
cador, Cliente Beneficiário.
132 Desenvolvendo Software com UML 2.0 – Definitivo

Isso indica que o cliente pode chegar à loja e ver os lançamentos e outras promoções.
Esse é um assunto mais profundo e que requer um outro Caso de Uso, conforme des-
crito. As classes responsáveis por este negócio estarão no Caso de Uso Administrar
Promoções, que incluirá, retirará e definirá regras para os filmes em promoção.
Aqui, parece-me que temos de nos preocupar somente com a escolha de um deter-
minado filme que esteja em promoção, para a sua adição à cesta de locações.
Isso em nada altera nosso desenho, visto que um filme selecionado por uma busca,
ou por uma seleção direta, deverá passar pelo mesmo processo. O método #iObter-
FilmeParaCesta (iCodFilme:int) : int da classe clsCliente já faz isso. Creio que seria ne-
cessário apenas um atributo em clsFilmes, informando se esse filme está em algum
tipo de promoção ou não, porém, isso não é trabalho para este Caso de Uso;
Administrar Promoções fará isso.
O próximo cenário alternativo nos diz:
4.1 Não aceita texto com menos do que três caracteres, não processa a busca. Alerta o
cliente locador – Site.
Isso indica que o cenário principal 4, de busca de filmes, tem um alternativo que é
uma restrição. Para resolver este cenário criei uma classe estereotipada de intera-
ção com o usuário e dei o nome de clsPgInicial. É uma classe com estereótipo de
PHP, pois creio que esse tipo de validação poderá, muito bem, ser de responsabili-
dade do cliente, sem a necessidade de chegarmos até um arquivo de classe propria-
mente dita. O código PHP terá um trecho em JavaScript que possibilitará a
resolução dessa restrição de busca. Este JavaScript estará dentro da parte HTML
do código PHP.
Eu poderia ter criado uma classe estereotipada do tipo HTML, com uma outra
classe, fazendo-lhe composição com o estereótipo de JavaScript. Essas duas classes
alcançariam uma PHP que, finalmente, chega até a classe clsCliente. Mas só de fa-
lar já me cansei! Uma classe estereotipada em PHP pode resolver o problema ade-
quadamente.
Veja que a classe clsPgInicial tem um método chamado de +bValidaBusca(...) : Boo-
lean.Este método é que fará as validações de busca.
Verifique que escondi os parâmetros dos métodos nas classes, para dar maior legi-
bilidade a estes, todas as boas ferramentas de modelagem permitem isso.
O próximo cenário alternativo nos diz:
4.2 Não aceita texto com mais do que dez caracteres, não processa a busca. Alerta o
cliente locador – Site.
Esta situação já foi contemplada na classe clsPgInicial e no método criado ante-
riormente em JavaScript.
O próximo cenário alternativo nos diz:
5.1 Não existindo resultado a ser exibido, permite retorno à seleção de tipo de busca – Site.
Capítulo 6 Diagrama de Classes 133

Figura 6.12 Diagrama de classes, fase 14.

Isso se refere à lista que o cenário principal 5 deve proporcionar. Assim, se não
houver retorno em forma de lista, sugiro apenas um texto do tipo: “Não foram en-
contrados resultados para a sua busca. Por favor, tente novamente”.
Faço esse comentário no método que implementa a busca. Caso o programador re-
ceba uma string vazia do banco de dados, mostrará a página de retorno com esse
texto, permitindo o retorno à busca, por meio de um link.
Essa documentação estará no método clsCliente.curObterResultadoLista(iTipoDeBus-
ca:int, strTexto:String).
134 Desenvolvendo Software com UML 2.0 – Definitivo

O próximo cenário alternativo nos diz:


5.2 Não existindo resultado a ser exibido, cliente locador sai da loja sem locar filmes –
Site.
Não há nada a fazer. O cliente simplesmente fechou o navegador e não quis locar
nada, o que, aliás, é muito comum.
O próximo cenário alternativo nos diz:
9.1, 10.1 Não cadastrado, cliente locador é levado ao cadastramento. (Ver Caso de Uso
Cadastrar Cliente Locador e Cadastrar Cliente Beneficiário). Caso o login ou a
senha apresentem problemas, solicita nova digitação – Site.
Também aqui nada há para se fazer. Caso se detecte que ele não possui um login e
uma senha que lhe permitam efetivar locações, entraremos no Caso de Uso Cadas-
trar Cliente, que não é nosso assunto neste Caso de Uso. Contudo, isso merece
uma documentação no método bValidaLogin da classe clsCliente.
O próximo cenário alternativo nos diz:
10.1 Caso o Cliente Locador não esteja no estado de “Aprovado para Locação”, pode
entrar em contato com a loja, via fax, e-mail ou telefone para solicitar alteração de
estado.
Este cenário alternativo entra no mesmo raciocínio do anterior, creio que isso vale
apenas uma documentação no método bValidaLogin da classe clsCliente. Quem cui-
dará disso é o Caso de Uso Cadastrar Cliente, que deverá prever algo de liberação.
O próximo cenário alternativo nos diz:
12.1 Cartão inválido, pede providência do cliente para regularização – Site.
O método bValidaRealizaTef deverá cuidar dessa situação. Novamente, faremos
apenas uma documentação neste método referente à necessidade de mostrarmos
uma página polida que informa a impossibilidade de utilização do cartão do clien-
te. Pede, também, que ele entre em contato com a instituição financeira.
O próximo cenário alternativo nos diz:
12.2 Adiciona a quantidade do DVD escolhido ao estoque de cópias, devido a não loca-
ção – Site.
Isso se refere ao caso do usuário desistir de locar determinado filme. Devemos re-
tornar esse filme ao estoque. Como ainda não houve entrega física, basta a altera-
ção numérica da disponibilidade no estoque. Quem fará isso é o método
bAdicionaEstoqFilme(...) : Boolean da classe clsEstoqueLocacoes.
O próximo cenário alternativo nos diz:
13.1 Altera o endereço de entrega. Se desejar alterar o endereço de entrega, o cliente loca-
dor deve enviar novo comprovante de endereço, que deve estar no nome do cliente
locador – Cliente Locador.
Esta necessidade foi resolvida pelo método bAlterarEnderecoEntrega (strEnderecoEn-
trega:String)da classe clsCliente.
Capítulo 6 Diagrama de Classes 135

Requisitos especiais
Os requisitos especiais nos dizem:
Requisitos Especiais:
1 – Deve ser adicionado ou deduzido do número disponível de cópias no estoque,
imediatamente após a ação que provocar uma dessas situações.
2 – O cliente locador pode abandonar a loja a qualquer momento.
A primeira necessidade já está atendida pelos métodos +bDiminuiEstoqFilme(...) :
Boolean e +bAdicionaEstoqFilme(...) : Boolean da classe clsEstoqueLocacoes.
A segunda necessidade independe de software e fecha o navegador a qualquer mo-
mento.

Conclusão
Se você observar a Figura 6.12 verá que somente colocamos no diagrama de clas-
ses o Caso de Uso Locar DVD. Muitas classes, métodos e atributos surgiram, por-
que estávamos iniciando o processo de criação das classes.
Quando colegas, ou mesmo você, forem criar novos diagramas de classes, alguns
poderão utilizar as classes dos outros, daí a importância de uma ferramenta de
controle de versão.
Mesclamos o processo de concepção conceitual e especificação.
Quando falo que uma classe, método ou atributo pode receber uma documenta-
ção, isso deve ser feito na área reservada que sua ferramenta de modelagem tem
para isso. Documentar é escrever em bom e claro português o que você deseja.
Um diagrama de classes não é a Bíblia, ele pode sofrer modificações ao longo, prin-
cipalmente, da codificação. Aspectos de visibilidade sofrerão boas alterações, o
que é importante é manter o diagrama atualizado, e talvez seja a parte mais difícil.
Não coloquei as classes em pacotes, porque acho pertinente este passo quando
faço o diagrama de seqüência. O diagrama de seqüência pode promover acrésci-
mos ou decréscimos no diagrama de classes.
Todos os Casos de Uso da Figura 3.2, no Capítulo 3, deverão estar presentes neste
diagrama de classes. O que mudará o conteúdo da nota existente no diagrama
para: “este caso modela o diagrama de Caso de Uso Locar”. Isso ocorre porque as
classes apresentadas neste diagrama serão utilizadas por aqueles Casos de Uso e o
crescimento de classes não será significativo para justificar novos diagramas de
classes.
Não vamos abordar todos os Casos de Uso que descrevemos, porque precisaría-
mos de um grande número de páginas para isso. A intenção era mostrar o processo
de criação do diagrama contra os Casos de Uso. Você pode, para treinar, colocar
essas classes em uma ferramenta e incrementar os outros Casos de Uso.
136 Desenvolvendo Software com UML 2.0 – Definitivo

Exercícios
1. Tendo-se um Caso de Uso na mão, como resolvemos os cenários principais nas classes?
2. Precisamos de alguma ferramenta especial para desenvolvermos o diagrama de classes
em ambiente de time de desenvolvimento?
3. Qual a principal diferença que existe entre os momentos de conceituação e de especifi-
cação?
4. Teremos métodos que se repetiram nas classes? Se sim, devemos representar esses mé-
todos?
5. Qual é o melhor momento para tratarmos os métodos repetidos?
6. Devemos pensar, instintivamente, em implementação? Como esta atende os cenários?
Ou pensamos em resolver primeiramente o negócio? Justifique.
7. Como os cenários alternativos dos Casos de Uso são tratados no diagrama de classes?
8. Devemos representar a visibilidade e modificadores de classes, atributos e métodos
logo ao apontá-los? Por quê?
9. Onde se documenta um cenário, dentro de uma classe?
10. Seguindo a sugestão do texto, onde se deve ter documentação na UML?
Papai, por que o ímã não está pegando este disquete?
ANÔNIMO

A verdade está lá fora, alguém sabe a URL?


ANÔNIMO

Q uando abordo este assunto nos meus cursos, alguns alunos perguntam pri-
meiro do que se trata e, em seguida, o que isso tem a ver com UML.
As respostas para essas perguntas são:
Quando digo tecnologias, refiro-me às variadas tecnologias que existem à disposi-
ção para a criação de Intranet, Extranet e Internet de uma empresa. Isso se deve ao
fato de que hoje temos poucas oportunidades de criar softwares clientes-servidores
puros, como fazíamos aos montes na época em que os navegadores eram muito insipi-
entes. Aqui não abordo como programar nessas linguagens ou utilizar a fundo esses
recursos, apenas informo o que elas permitem e em que momento são pertinentes.
Este assunto tem muito a ver com UML. Primeiro, você pode participar de uma re-
união e ser solicitado a informar uma breve visão da arquitetura sugerida. Peque-
nas coisas que se diz em uma reunião inicial de software é o que fica. Se uma
bobagem foi falada, você permanecerá como autor dela. Outro ponto é que nem
todas as pessoas têm um profundo conhecimento do que faz o quê, e para fazer o
diagrama de seqüência precisa-se conhecer essas tecnologias.
138 Desenvolvendo Software com UML 2.0 – Definitivo

Portanto, creio que é pertinente uma explanação sobre esses tópicos. Caso já co-
nheça o assunto, simplesmente pule este capítulo; porém, vejo em sala de aula que
muitos alunos desconhecem as possibilidades tecnológicas disponíveis. A Figura
7.1 servirá para nortear cada tecnologia que abordarei, neste capítulo.
Quando a Internet começou, tínhamos uma única alternativa para publicar assuntos
para outros verem. Dizemos publicar, porque é o sentido de revista, livro ou jornal,
uma publicação que periodicamente sofre alterações. Essa alternativa era o HTML.

HTML
HTML (HyperText Markup Language) é uma linguagem de marcação que prevê
marcas em um texto; chamamos essas marcas de tags. Esta linguagem de marcação
é considerada não estruturada, porque nem todas as tags de abertura têm a sua tag
de fechamento.
Quem rege a atualização do HTML é o W3C (World Wide Web Consortium).
Você pode ver em que pé estão esses trabalhos pesquisando a página específica
deste assunto no W3C.1
Durante anos, o HTML atendeu à necessidade básica de publicação de textos aca-
dêmicos. Com o tempo, isso deixou de ser suficiente, porque o HTML é incapaz de
fazer a soma de dois números (2+2), ele apenas mostra textos e figuras. Se você cli-
car com o botão direito no seu navegador verá que o que há ali é somente texto. O
HTML não processa nada, ele apenas mostra. Está claro, então, que ele é incapaz
de acessar um único dado em um banco de dados.
O tempo passou e precisávamos utilizar algo que pudesse fazer a conta desejada
(2+2). Para suprir essa necessidade e outras, como referenciar um determinado ele-
mento da tela, surgiram linguagens de scripts, como JavaScript.

JavaScript
Agora, o JavaScript permite que façamos a conta (2+2), criando funções, referen-
ciando e ajustando elementos do texto HTML. Brendan Eich desenvolveu o Java-
Script na Sun Microsystems a partir de dezembro de 1995. A especificação inicial
do JavaScript está na Internet.2 Documentação e referências também podem ser
encontradas na Internet.3 Podemos, até mesmo, utilizar o JavaScript em arquivos
separados do HTML. Esses arquivos têm a extensão .js; neles existem apenas fun-
ções, que são utilizadas somente quando precisamos, diga-se de passagem, a me-
lhor forma de usarmos o JavaScript.
Quem entende o JavaScript e processa as suas funções, quando requisitado, é o navega-
dor que você utiliza. Todo este processamento é feito no seu computador, localmente.
Mostramos o texto e processamos algumas coisas, porém, isso não era suficiente, pre-
cisávamos deixar as páginas mais apresentáveis. Foi aí que se iniciou a criação de ar-
quivos externos que possibilitavam a formatação de páginas HTML, os arquivos .css.
Capítulo 7 Tecnologias 139

CSS
O CSS (Cascading Style Sheets) como diz o W3C é um mecanismo simples para
adicionar estilo (por exemplo fontes, cores, espaçamento etc.) para documentos
Web. O CSS tornou-se uma recomendação do W3C a partir de dezembro de 1996.
O progresso do trabalho feito em CSS pode ser visto na Web.4
Agora, mostro um documento HTML, faço contas e o deixo bonito, porém, isso
não era suficiente. Gostaríamos de fazer um determinado elemento mover-se na
tela, sem a necessidade de o usuário instalar nenhum programa adicional. Para
isso surgiu o DHTML, ou Dynamic HTML.

DHTML
O Dynamic HTML é utilizado em código em JavaScript. Ele permite um maior
controle sobre os elementos da tela. Não existe uma especificação oficial para o
DHTML e cada navegador resolve aceitá-lo ou não. É pura sorte que todos os na-
vegadores aceitem todos os códigos DHTML que prevermos.
Isso não era suficiente, gostaríamos de trocar dados. Essa prática era e é muito usa-
da em ambientes corporativos. Aplicações enviam dados para outras aplicações
pelos arquivos com extensão .txt. Quando a troca de arquivos era feita entre vá-
rias corporações, era um pouco trabalhoso. Por exemplo, caso eu queira submeter
a uma licitação determinado produto, peço aos meus fornecedores que enviem
seus preços, quantidades e especificações dos seus produtos pelo arquivo texto.
Contudo, isso costuma gerar alguns problemas, pois alguns fornecedores usam
‘vírgula’ como separador, outros usam uma tabulação etc. Grande é o trabalho
para ler, traduzir e dar significado à licitação que eu gostaria de fazer. O XML
apareceu para ajudar neste pormenor.

XML
O XML (Extensible Markup Language) é derivado do SGML (Standard Generali-
zed Markup Language). O XML permite a troca de dados de forma padronizada
em meios eletrônicos, e está sob a responsabilidade e trabalho técnico do W3C,
veja detalhes na Internet.5
O XML é uma linguagem estruturada porque, se existe uma tag de abertura, deve
haver uma de fechamento, e também porque é dado um significado para cada tag.
O Parse XML é um verificador da correta sintaxe utilizada no arquivo XML. Ele
sabe o que está certo e o que está errado, porque existe uma seção no arquivo
XML, ou mesmo um arquivo à parte, com extensão .dtd, que informa qual é a for-
matação das tags XML.
O DTD (Document Type Definition) é um mecanismo que informa como o arqui-
vo XML está formatado, ou seja, qual é a estrutura de um arquivo XML ou como
ele deve ser escrito. Para apresentarmos um arquivo XML, podemos usar XSLT
140 Desenvolvendo Software com UML 2.0 – Definitivo

(XSL Transformations), que é uma linguagem de estilos para o XML. Uma alter-
nativa de apresentação é feita por meio de tabelas HTML. Ou seja, você terá de
criar uma aplicação que seja capaz de varrer um arquivo XML e transportar o con-
teúdo de suas tags para uma tabela HTML.
Para que conteúdos fossem criados para dispositivos sem fio, do tipo dispositivos
celulares, pagers e agendas eletrônicas, surgiu o WML.

WML
A WML (Wireless Markup Language) é uma linguagem de marcação baseada no
XML para ser utilizada em um protocolo chamado WAP (Wireless Application Pro-
tocol). O fórum “The WAP Forum”, originalmente fundado pela Ericsson, Motoro-
la, Nokia e Unwired PlanetWML, foi criado para gerar uma especificação global
para protocolo de redes sem fio. Você pode ver mais detalhes a respeito na Internet.6
Todas essas tecnologias são executadas em um computador conectado à Internet,
chamado de computador cliente. Qualquer computador com um sistema opera-
cional do tipo Conectiva Linux, Red Hat Linux ou da família Windows, pode exe-
cutar quaisquer dessas tecnologias, com exceção dos dispositivos sem fio, que têm
seus próprios sistemas operacionais.
A primeira coluna da Figura 7.1 representa essas tecnologias. Entretanto, essas ca-
pacidades não eram suficientes, pois imagine que queiramos mostrar uma página
HTML diferente a cada usuário que acessasse nosso site. Esse HTML deveria ser
criado de forma diferente na sua origem, ou seja, em uma máquina servidora e não
em uma máquina cliente. Para atender a essa necessidade surgiram várias tecnolo-
gias; citarei apenas três: PHP, ASP, JSP.

PHP
PHP (Hypertext Preprocessor) é um projeto da Apache Software Foundation.
Possui código aberto e gratuito, e a comunidade pode contribuir. Saiba mais na
Internet.7, 8

ASP
ASP (Active Server Page) é um projeto proprietário da Microsoft. Saiba mais na
Internet.9

JSP
JSP (JavaServer Pages) é um projeto da Sun Microsystems. Saiba mais na Internet.10
Além dessas tecnologias, existem outras, porém estas cobrem bem mais do que 1
milhão de sites ao redor do mundo. Antes do advento dessas tecnologias e sua po-
pularização, PERL, criação de Larry Wall, era muito popular.11
Capítulo 7 Tecnologias 141

Cada uma dessas tecnologias, para funcionar, precisa de uma aplicação que, no
jargão de informática, chamamos de servidor. Além de estarem em uma máquina
servidor, essas aplicações também são conhecidas como servidor. Assim, para o
PHP funcionar precisará do servidor APACHE,12 para o ASP funcionar precisará
do servidor IIS (Internet Information Server),13 para o JSP funcionar precisará do
APACHE e, adicionado a este, um módulo conhecido como Tomcat.14
Qualquer uma dessas tecnologias é capaz de enviar uma página HTML diferente
para um determinado internauta.
Apesar de essas tecnologias conseguirem gerar código HTML verdadeiramente di-
nâmico, elas precisavam alcançar dados em bancos de dados corporativos. É assim
que qualquer delas consegue chegar até um banco de dados corporativo e executar
uma instrução SQL (Structural Query Language), montar uma tabela HTML com
o resultado e retornar para a máquina cliente.
Isso completou o ciclo de necessidades, porém de forma insegura. Onde quer que
uma página PHP, JSP, ASP ou PERL esteja salva, para abri-la, basta você solicitar
sua abertura em um editor de texto comum. Desta forma, as regras de negócio de
suas aplicações corporativas estarão ao alcance de qualquer pessoa que consiga
abrir esses arquivos. Instruções SQL são também regras de negócios, pois nelas
posso selecionar para determinado negócio todos os clientes, maiores de idade,
com compra acima de determinado volume. Isso é uma regra de negócio. Para re-
solvermos esses problemas, passamos a utilizar o encapsulamento proposto pela
orientação a objetos, criando pacotes DLL ou JAR.

DLL
A DLL (Dynamic Link Library) é baseada no padrão COM (Component Object
Model) de encapsulamento de classes para a família do sistema operacional Win-
dows.

JAR
JAR (Java ARchive) é o padrão de encapsulamento de classes escritas em JAVA e
segue o padrão CORBA (Common Object Request Broker Architecture) de encap-
sulamento de classes para qualquer sistema operacional. Este padrão é aberto e
mantido pela OMG15.
Agora agregamos maior segurança nas aplicações, pois colocamos nossas regras
de negócio junto com as instruções SQL, dentro de nossos arquivos compilados. O
exemplo aqui cita os arquivos com classes empacotadas e compiladas que recebem
a extensão .jar. Porém, normalmente as instruções SQL estão encapsuladas em ar-
quivos Servlets.
Um arquivo com extensão .jar equivale a um arquivo com extensão .exe, que exis-
te em alguns sistemas operacionais. Se dermos um clique duplo em um arquivo
142 Desenvolvendo Software com UML 2.0 – Definitivo

com extensão .exe, um programa será executado, trazendo sua janela principal
para o primeiro plano. Se fizermos o mesmo com um arquivo com extensão .jar,
obteremos o mesmo resultado, se esse arquivo encapsular uma janela principal.
Geralmente, um arquivo .jar é um programa executável conhecido como clien-
te-servidor, isso porque é capaz de buscar informações que residem em outro com-
putador. Isso não significa que esse programa é capaz de buscar informações via
Internet de forma trivial. Mormente, esse tipo de necessidade é resolvido com Serv-
lets – JSP – EJB.

Web Services
Há muitas definições sobre o que é Web Service. A definição que pode resolver esta
pluralidade usada hoje é: Qualquer aplicação (programa de computador em qual-
quer forma possível) que forneça uma forma de comunicação pública para outras
aplicações via Internet.
O principal uso de um Web Service é a intercomunicação entre aplicações de dife-
rentes tipos. Aplicações legadas têm a possibilidade de utilizar essa possibilidade
por meio do protocolo SOAP (Simple Object Access Protocol), que oferece grande
flexibilidade porque utiliza http e XML. O XML recebe um grande sentido se usa-
do através do http, que é o protocolo padrão de uso na Internet, para páginas em
navegadores.

Enterprise JavaBeans (EJB)


Enterprise JavaBeans são componentes que encapsulam regras de negócio e sua ló-
gica. Esses componentes, construídos em Java, possibilitam, por exemplo, que da-
dos sejam gravados em múltiplos bancos de dados mantendo a atomicidade da
transação. Transações distribuídas por diversos servidores fazem uso extensivo de
JavaBeans. Um servidor de aplicações (existem vários no mercado) congrega mui-
tos EJB e atendem às suas necessidades de distribuição. São componentes criados
em Java e com a extensão .java.

Servlets
As JSPs e os EJBs são tipos de Servlets. Como exemplo, um computador cliente faz
uma requisição para um servidor e este aciona, através de um Servlet container,
uma página JSP que faz uma consulta em um EJB. O retorno do Servlet é algo que
o computador cliente pode interpretar, normalmente XHTML.
São componentes criados em Java e com a extensão .java. Um Servlet pode manter
o estado de pedidos feitos entre as chamadas na memória; dessa forma, uma única
instância pode responder a diversas requisições, o que facilita o seu gerenciamento.
Capítulo 7 Tecnologias 143

Instruções SQL
Assim, uma página HTML alcança uma página PHP ou Servlet, que acessa um
JAR que alcança um banco de dados.
Essa solução parece boa, mas quando apenas uma coluna for acrescentada em uma
instrução SQL na parte WHERE para dar maior precisão no retorno, teremos de re-
compilar nossos arquivos DLL, JAR ou Servlet, a fim de podermos fazer a nova so-
lução funcionar. Enquanto isso, o site estará parado aguardando a alteração.
Além disso, esta solução enfrenta dois outros problemas, quais sejam:
1. A cada instrução SQL, qualquer banco corporativo fará a verificação de sinta-
xe, a fim de saber se você escreveu a cláusula SQL corretamente.
2. A cada instrução SQL, qualquer banco corporativo montará um plano de aces-
so. Ou seja, ele tentará descobrir qual a melhor forma de retornar-lhe os regis-
tros pedidos.
Essas duas tarefas serão realizadas a todo o momento que você executar uma ins-
trução SQL, mesmo que você a execute repetidamente. O desempenho caiu consi-
deravelmente, então temos três problemas a resolver: Compilação, Checagem de
Sintaxe e Montagem do Plano de Acesso.

Funções ou stored procedures


Esses três problemas podem ser resolvidos com a criação das instruções SQL em
funções, ou stored procedures, dentro do banco de dados.
Neste momento, surgem gritos horríveis vindos do fundo da sala, onde pessoas jo-
gam pedras e lanças afiadas dizendo que estou maculando a orientação a objetos,
misturando regras de negócios com dados etc.
Considere que:
1. As instruções SQL serão ou deverão ser construídas de qualquer forma; então,
qual a diferença entre fazê-las dentro ou fora de funções no banco de dados?
2. Instruções SQL são regras de negócios, estão logicamente nas camadas de re-
gras de negócios e fisicamente nas camadas de banco de dados.
É evidente que isso é apenas uma sugestão, não quero dizer que é lei, mas pense, ao
menos, na solução. Caso tenha outra solução para os três problemas: Compilação,
Checagem de Sintaxe e Montagem do Plano de Acesso, envie um e-mail que terei
prazer em ler.

Conclusão
A intenção deste capítulo era prepará-lo para a confecção do diagrama de seqüên-
cia. Nesse diagrama, você necessitará dos conceitos mostrados aqui para pensar
na seqüência das requisições, desde a interface gráfica até o banco de dados escolhido.
144 Desenvolvendo Software com UML 2.0 – Definitivo

A Figura 7.1 mostra que o conceito de que existem duas ou três camadas não é
mais verdade. Hoje existem n camadas a suportar uma aplicação Web. Pode ha-
ver, até mesmo, mais computadores representando a distribuição dos arquivos dll,
jar, EJB, Servlets e banco de dados. Eles não precisam estar necessariamente em
um único computador.
Como seria possível a confecção de código fora do perímetro de sua empresa, se
você não informasse onde quer que as coisas sejam executadas?

Figura 7.1 Tecnologias.

Visto que as páginas HTML não processam nada, podemos afirmar que se a pági-
na HTML tem apenas um formulário vazio para preenchimento do internauta,
não há motivos para ela ser considerada como Server, por exemplo: PHP. Essa pá-
gina HTML chama, em seu formulário, uma página PHP que reside no Server. A
página PHP acessa as nossas classes, classes puras – sem estereótipos – feitas no
diagrama de classes que podem ser Servlets no formato EJBs, e estas resolvem o as-
sunto no banco de dados. O banco de dados retorna o desejado, as classes tratam
aquele retorno com outras regras de negócios e devolvem esse retorno para a pági-
Capítulo 7 Tecnologias 145

na PHP. A página PHP, provavelmente, vai remeter o usuário para outra página,
que pode ser tanto HTML como PHP, o que depende da intenção.
Outro cenário possível é aquele em que o usuário navega para uma página inicial
onde os controles estão montados dinamicamente. Isso ocorre quando uma página
deve montar um menu de forma dinâmica, como nossos grupos de DVDs à dispo-
sição. Nesta situação, necessariamente, a primeira página a ser mostrada será PHP
e não HTML, pois HTML não tem condições de processar nada, como já vimos.
Assim, a página PHP solicita informações das classes, que vão até o banco de da-
dos para processar e formatar as informações solicitadas, e o banco de dados re-
torna este resultado para as classes. As classes retornam seus tratamentos para a
página PHP, que formata um código HTML (com o menu montado) e devolve
para o navegador cliente.
À primeira vista, tudo isto parece demorado e desnecessário. Entretanto, com as
tecnologias atuais, as quais citei algumas das principais, essa arquitetura está lon-
ge de ser considerada demorada também não é desnecessária, pois, a intenção é a
reutilização de código.
Nesta proposta, as classes ficaram isoladas tanto do banco de dados como da in-
terface gráfica com o usuário. Isso significa que, se uma aplicação cliente-servidor
precisasse dessas classes, poderia utilizá-las tranqüilamente que nada precisaria
ser reconstruído, pois uma aplicação cliente-servidor consegue acessar uma classe
empacotada normalmente.
A Figura 7.2 exibe um exemplo de como essas tecnologias vieram auxiliar a orien-
tação a objetos, pois as mesmas classes são acessadas por aplicações diferentes.

Exercícios
1. Uma página HTML consegue retornar um valor qualquer de um banco de dados?
2. No diagrama de classes, podemos representar páginas Web como HTML, XML, PHP
etc? Como?
3. Quais os três problemas enfrentados quando não guardamos as instruções SQLs no
banco de dados?
4. Uma aplicação pensada em diversas camadas é mais demorada em termos de desempenho?
Por quê?
5. Uma aplicação deve utilizar apenas e uma tecnologia, de preferência uma que seja for-
necida por um único fabricante. Comente esta afirmação. Discorra sobre as tecnologias
disponíveis apresentadas neste capítulo.
6. Em uma reunião com o interessado em desenvolver um software corporativo, portan-
to, que será utilizado por diversos departamentos, você aconselharia o uso de aplica-
ções do tipo cliente-servidor ou uma solução em ambiente Web? Por quê?
146 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 7.2 Classes sendo reutilizadas por mais de uma aplicação.

7. Com que tipo de tecnologia uma página HTML precisa conversar para acessar dados
encapsulados dentro de um componente Servlet?
8. Qual a função de um servidor de aplicação?
9. Para que serve a tecnologia XML?
10. O que são Web Services?
Ou nós encontramos um caminho, ou abrimos um.
ANÍBAL

Não vemos as coisas como elas são, mas como nós somos.
ANAIS NIN

O diagrama de seqüência é considerado um dos diagramas de interação que


existem. Existem: o diagrama de seqüência (DS), o diagrama de colabora-
ção renomeado para comunicação na UML 2.0, o diagrama de interação – Visão
Geral e o Timing Diagram. Dos quatro creio que o diagrama de seqüência é o mais
estimulante a se usar.
Este diagrama pode ser usado para mostrar a evolução de uma dada situação em
determinado momento do software, mostrar uma dada colaboração entre duas ou
mais classes e pode, também, ser usado para mostrar a tradução de um Caso de
Uso desde a interação com o usuário até a finalização daquele dado processo.
Pessoalmente, é neste sentido que vejo um bom significado ao diagrama de seqüên-
cia. Nós construímos o diagrama de classes, baseando-nos no Caso de Uso. Isso
nos norteou a abstração do negócio a ser modelado. O diagrama de seqüência, se
seguir o mesmo approach, pode mostrar erros não detectados no diagrama de clas-
ses. Ele melhora o diagrama de classes, permitindo que acrescentemos ou retire-
mos métodos e/ou atributos desnecessários de um conjunto de classes.
A intenção, agora, é dar uma demonstração visual da seqüência das ações que
o software tomará frente a uma interação com um ator. Serve como norte para o
148 Desenvolvendo Software com UML 2.0 – Definitivo

programador e dá-nos maior segurança de que o diagrama de classes atende às ne-


cessidades do negócio.

A notação do diagrama de seqüência


Esta é a notação para um objeto. Já que o diagrama de seqüência
vai nos mostrar as seqüências de objetos na memória, esta é a no-
tação que é utilizada, em vez de a notação de classe. O X, no
exemplo, significa o nome do objeto. Algumas ferramentas exi-
gem que se nomeie o objeto, porém isso não é obrigatório na prática; com freqüên-
cia, sabemos que existirá um objeto na memória representando uma classe, porém
não sabemos dizer quem é o objeto. Este nome é seguido de dois pontos e, em segui-
da, o nome da classe. Temos, então, a leitura: X é um objeto instanciado do tipo da
classe ‘NomeClasse’. Todos os diagramas da UML, que exigem a notação de objetos,
usam-na desta forma. Você poderá simplesmente, escrever ‘:NomeClasse’ que será aceito.
Estereótipos, são muito utilizados no diagrama de seqüência. Faz
sentido, já que precisamos representar tanto interações com o
usuário, como gravação e recuperação de informações em banco
de dados ou outro meio físico como arquivos textos ou XML.
Algumas ferramentas exigem que você crie estereótipos para classes e para objetos
separadamente, por isso, se você criar um estereótipo de uma página PHP, ou um ar-
quivo JS no diagrama de classes, talvez tenha de fazê-lo novamente para objetos,
isso se deve ao fato de que, quando se cria um estereótipo, deve-se informar qual é
sua classe base. Uma classe base, de um estereótipo, pode ser tanto Class como
Object, ou outra. Um estereótipo pode ser usado para qualquer item de um diagra-
ma de seqüência, a figura anterior é apenas um exemplo. Conforme já falado ante-
riormente, a letra ‘a’, antes dos dois pontos, será o nome da página PHP em questão.
Como não sei exatamente o nome dessa página, deixo uma letra do alfabeto.

Uma linha tracejada tem o significado da linha de vida da solu-


ção em questão. Essa linha tracejada terá o tamanho necessário
que a solução exigir. Sempre deve ser iniciada no objeto e no
centro deste.

Um retângulo que ocupa qualquer área da linha tracejada é o tem-


po de vida daquele objeto. Este símbolo é uma ocorrência de exe-
cução e, por isso, pode aparecer diversas vezes ao longo da linha de
vida do objeto. As notações a seguir são perfeitamente possíveis.
Um objeto que teve sua instância criada duas vezes. Um objeto
cuja instância usa todo o tempo da solução, conhecido como
objeto ativo, e um objeto que é instanciado várias vezes durante
a solução.
Capítulo 8 Diagrama de Seqüência 149

A representação ao lado é de um ob-


jeto enviando uma mensagem para
outro objeto. Quando um objeto en-
via uma mensagem está executando
um método no outro objeto. É dessa
forma que dizemos que as classes co-
laboram. Classes colaboram envian-
do mensagens umas para as outras.
A teoria diz que você deveria infor-
mar os parâmetros de uma mensagem. Porém, será um trabalho razoável tentar-
mos descobrir ou adivinhar parâmetros possíveis para o envio de uma mensagem.
Gosto de colocar os nomes dos parâmetros em vez de seus valores. Quando são
muito óbvios, nem isso. A seta aponta sempre para onde a mensagem será executa-
da. No exemplo anterior, a página PHP ‘a’ executa um método na classe, agora
uma instância de um objeto clsCliente, cujo objeto chama-se ‘b’. O método em
questão tem dois argumentos de entrada.
A seta tracejada representa o
retorno que a MensagemA pode
dar. Quando mensagens não
têm retorno, típicos métodos
void, simplesmente não repre-
sente a seta tracejada retornan-
do a mensagem. Tome um pa-
drão de retorno e divida esta
sugestão com a equipe. Temos
colegas que, por usarem uma
convenção no documento Nomenclatura, não retornam a seta porque o nome da
função já indica o seu retorno, exemplo: uma função iRetCodCli(strNome), retorna
150 Desenvolvendo Software com UML 2.0 – Definitivo

um inteiro contendo o código do cliente, aqui pode ser redundante a seta de retor-
no. Porém, acerte a semântica devidamente com os colegas antes de adotá-la. Estas
são as mensagens síncronas, as mais comuns. São chamadas de síncronas, pois se
espera seu retorno.
Agora você pode ver a repre-
sentação de mensagens assín-
cronas, aquelas que são envia-
das e, das quais, não se espera
o seu retorno de imediato. Elas
ficam resolvendo seus assun-
tos até seu término. Por exem-
plo, a impressão de um deter-
minado relatório.
A MensagemB(), ao lado, indica
uma mensagem ou método re-
cursivo ou o chamado método
self, aquela mensagem que, é
enviada ao próprio objeto. Ima-
gine uma classe que cuida de
login e senha. A validação de lo-
gin e senha não deve ser passada
adiante antes que a senha seja
criptografada. A criptografia
ocorre na própria classe que
recebeu a mensagem e não cabe o envio para outro lugar. Pronto, surgiu a necessi-
dade de uma recursividade. Uma classe recebe o login e a senha e ela própria cuida
de criptografar essa senha.
Um ‘X’, no final de uma ocorrência de execução, indica que o ob-
jeto foi destruído. Eu creio que isso é desnecessário, uma vez que
o tempo de uma ocorrência de um objeto já é representado pelo
retângulo e o final desse retângulo é o final da vida daquele obje-
to, naquele momento. Além disso, linguagens como Java e ou-
tras já vêm com o Garbage Collection que limpa a memória para
os programadores. Os programadores C++ sabem que devem
destruir um objeto depois de criá-lo.
A UML 2.0 oficializou o que já utilizávamos, cada um a seu modo. A forma de re-
presentar alternativas, else, switch, cases entre outras, é com a utilização de Alt ou
alt, este é dito um Operador de Interação. Um operador de interação deve estar
dentro de um retângulo maior, chamado de Fragmento Combinado, dividido por
uma linha pontilhada. Essas linhas podem ser várias, dependendo da necessidade.
Cada parte do Fragmento Combinado deverá, evidentemente, ter uma condição.
Capítulo 8 Diagrama de Seqüência 151

Neste exemplo, a primeira parte do Fragmento Combinado tem a condição [Login


Válido],enquanto a parte de baixo espera uma outra situação [else].

Trocando-se o Operador de Interação alt por opt, no exemplo anterior, temos uma
opção. Uma opção difere de uma alternativa em que um ou outro é escolhido. Na
opção, pelo menos um é escolhido ou nada deverá acontecer; evidentemente que
não é o caso de [if] e [else].
Quando o Operador de Interação for break, isso indica que o Fragmento Combina-
do mostra um cenário que deve acontecer em vez de simplesmente terminarmos, é
um ponto de parada obrigatória.
Quando o Operador de Interação for Paralelo ou par, designa que o Fragmento
Combinado executa uma intercalação entre os operandos ou cenários desenhados
no Fragmento Combinado.
Quando o Operador de Interação for Região Crítica, designa que um Fragmento
Combinado não pode ser intercalado por outro e seu tratamento é especial.
Quando o Operador de Interação for loop, significa que aquele fragmento passa
por um loop na linguagem. O loop tem uma sintaxe própria, assim como a condi-
ção, loop [(<mínimo>, [<máximo>])], já que o valor máximo é opcional, mínimo não
negativo e máximo maior ou igual ao mínimo.
Quando o Operador de Interação for ignorar significa que existem alguns tipos de
mensagem que não são mostradas naquele fragmento combinado. Por exemplo,
mensagens que são intuitivamente construídas, como a exibição de uma tela que
informa: Por favor, se seu login ou sua senha apresentam problemas, você tem
152 Desenvolvendo Software com UML 2.0 – Definitivo

mais duas chances. Inversamente considerar indica que existem mensagens que de-
vem ser consideradas naquele fragmento.
Quando o Operador de Interação for asserção indica que a seqüência de ações,
dentro do Fragmento Combinado, é somente válida se executada continuamente.
Todas as outras continuações propostas resultarão em uma região inválida.
Existem, ainda, os Gates (Portões), cuja única finalidade é promover uma forma de
interação entre Fragmentos Combinados de um diagrama e outro, uma mensagem
dentro de um Fragmento Combinado alcançando outra mensagem em outro Frag-
mento Combinado. Para representar um gate, basta enviar uma mensagem, uma
seta, para a borda do Fragmento Combinado.
Uma mensagem perdida, lost message, é uma mensagem em que o evento de envio
é conhecido, porém não existe evento que a receba, mensagens que nunca alcan-
çam seu destino. Uma mensagem encontrada, found message, é uma mensagem
em que o evento que a receberá é conhecido, porém o evento que a promoveu não.
Veja a notação para mensagens perdidas e encontradas.

Veja que também você pode ter Continuações, as quais tem o mesmo símbolo de
estados.
Continuações são formas de representar diferentes ramifi-
cações de um Fragmento Combinado alt. Complexas al-
ternativas podem ser representadas, apontando inclusive
para outro diagrama, caso necessário.
Verifique se alt já não atende as suas necessidades antes
de usar opt, break, par ou região crítica. A seguir, mostro um exemplo de Região
Crítica, que, aliás, poderia ser tratada de outra forma, com Fragmentos Combina-
dos e alt em um mesmo diagrama.

Construindo o diagrama de seqüência


Para construirmos o diagrama de seqüência relativo ao Caso de Uso Locar DVD,
vamos adotar o mesmo approach adotado no diagrama de classes. Isso significa
que vamos observar cada cenário principal e alternativo para expressarmos a se-
qüência que desejamos no ato de Locar DVD.
Cada cenário deve ser pensado em termos de que ações de tela, e conseqüentes res-
postas do sistema, são esperadas.
Quando desejarmos que algo seja retirado de um banco de dados, vamos apenas
estereotipar uma entidade do banco, chamando-a de tbs_Banco_Locar.
Capítulo 8 Diagrama de Seqüência 153

A forma de representar o banco de dados vai depender do suporte das ferramentas.


Você pode utilizar um objeto estereotipado, forma apresentada neste texto.

Você pode utilizar o símbolo de banco de dados, conforme está represen-


tado na ilustração ao lado.

Você também pode utilizar este símbolo, que representa um objeto-entidade.

Representar o banco de dados de forma genérica não significa que teremos apenas
uma entidade no banco de dados. Significa apenas que não vamos pensar no banco
de dados agora. Esta entidade estereotipada poderá conter várias tabelas. Quere-
mos apenas representar os retornos do banco de dados.

O primeiro cenário principal


1 Visualiza os grupos de produtos existentes, a partir de uma lista criada logo na entrada
do cliente na loja, através da descrição do grupo. Os grupos são: Infantil, Adulto,
154 Desenvolvendo Software com UML 2.0 – Definitivo

Ação/Policial, Antigos, Romance, Comédia, Drama e todos. A opção todos indica que
o cliente locador poderá efetuar uma busca por todos os grupos existentes – Cliente
Locador, Cliente Beneficiário.
Quando nosso cliente entra na Loja Virtual, ele visualiza grupos de produtos, os
quais lhe permitem pesquisa. Uma lista criada indica que esses grupos deverão es-
tar guardados em algum lugar, por exemplo um banco de dados. Faz sentido a lista
estar em um banco de dados; isso dá flexibilidade ao menu de grupos, pois nosso
cliente, que solicitou o software, poderá acrescentar grupos quando desejar.
Para resolver isso, creio que a simples digitação da URL vai solicitar uma página
PHP (portanto, dinâmica), que solicitará as descrições do banco.
As descrições do banco de dados serão pedidas através da classe clsGrupos, no seu
método curObterListaGrupos(). Então, quando a URL for solicitada, a página PHP
clsPgInicial pede à classe clsGrupos que execute curObterListaGrupos() e esta vai até o
banco de dados e executa uma procedure que retorna os grupos possíveis.
Este método está representado na classe clsClienteLocador. Isso foi colocado, pensan-
do-se em (Página PHP -> Classe de Cliente -> Classe de Grupos -> Entidades do banco de da-
dos), porém vou adotar o approach de não utilizar a classe de cliente agora. Decidi isso
porque: primeiro, o caminho (Página PHP -> Classe de Grupos -> Entidades do banco de da-
dos) é mais rápido; segundo, não acredito que uma instância de cliente deva ser neces-
sária agora; e terceiro, montar a página PHP não me parece uma ação da classe
cliente, e sim algo para o qual a página PHP deva pedir colaboração da classe grupos.
Desse modo, vamos retirar o método da classe de cliente e incluí-lo na página PHP.
Veja que mal começamos o diagrama de seqüência e já iniciamos alterações no
diagrama de classe. É para isso, também, que serve um diagrama de seqüência.
Vamos representar isso no diagrama de seqüência.

Figura 8.1 Diagrama de seqüência, fase 1.

Não estou representando os retornos, pois acho desnecessário. O método curObter-


ListaGrupos()recebe uma página como argumento e retorna uma string, que será
tratada pela página PHP.
Capítulo 8 Diagrama de Seqüência 155

Não há mais comentários sobre este fluxo e, com isso, resolvemos o primeiro cená-
rio principal.

O segundo cenário principal


2 Escolhe determinado tipo de grupo selecionando sua descrição – Cliente Locador,
Cliente Beneficiário.
Quando o cliente escolhe um determinado grupo para satisfazer uma busca, mos-
tramos uma página PHP, específica para consultas. Esta página espera o grupo
para o qual será feita uma busca. Essa escolha envia um inteiro para a página de
busca. A página de busca guarda a informação e espera novas ações. Esta página
pode estar em um frame HTML, caso em que continuamos a necessitá-la.
O cliente pode simplesmente fechá-la, sem efetivar busca alguma. O importante
aqui é que devemos representar a ação de um clique escolhendo um grupo nesta pá-
gina. Documentamos essa intenção na página clsPgInicial, uma classe estereotipada.
O estereótipo da página de busca não está representado no diagrama de classes.
Para usarmos um objeto precisamos informar o seu tipo. Neste caso, o tipo do ob-
jeto é uma classe estereotipada que representa uma página PHP. Vamos até o dia-
grama de classes e criamos a classe estereotipada.
A página PHP de busca, clsPgBusca, deve ficar ativa juntamente com a página PHP
clsPgInicial, como páginas sobrepostas ou o que chamamos de pop-up.
Novamente, mudamos o diagrama de classes, pelos mesmos motivos do cenário
principal anterior. O método iObterGrupo(...) desaparece da classe clsClienteLocador,
veja a Figura 8.13. O código do grupo passa a ser algo controlado pelo JavaScript,
que obteve a descrição e o código do grupo quando do retorno da procedure proc-
MontarGrupos(Pag).
Vamos representar isso no diagrama de seqüência.

Figura 8.2 Diagrama de seqüência, fase 2.


156 Desenvolvendo Software com UML 2.0 – Definitivo

O terceiro cenário principal


3 Escolhe o tipo de busca desejada, a partir de uma descrição. Essa busca pode ser por:
nome de um ator do filme, nome do diretor do filme ou título do filme – Cliente Loca-
dor, Cliente Beneficiário.
Esta ação é algo que a própria página clsPgBusca pode controlar. Apresenta uma
lista das possibilidades de busca e o cliente escolhe uma, através, por exemplo, de
um botão de rádio do HTML. Novamente a classe clsClienteLocador sofre altera-
ção. Retiramos o método iObterTipoDeBusca() da classe clsClienteLocador e documen-
tamos na classe clsPgBusca a nossa necessidade. Também a classe clsTiposDeBusca
deixa de existir, pois não temos mais necessidade de sua ajuda.
Não há necessidade alguma de representarmos esta ação no diagrama de seqüência.

Quarto e quinto cenários principais


4 Informa o texto relativo à busca, com mais de três caracteres – Cliente Locador, Clien-
te Beneficiário.
Nada a fazer. Uma caixa de texto receberá o texto relativo a este cenário e guarda-
rá a informação. Documentamos na classe clsPgBusca.
Vamos ao próximo cenário principal.
5 Visualiza os resultados da busca através de uma relação. A relação é mostrada por apro-
ximação do texto pedido. A relação deve aparecer por percentual de aproximação. Os
títulos com maior aproximação deverão ser apresentados em primeiro lugar. O cliente
locador visualiza, também, o percentual de aproximação. Assim, a lista mostrada ini-
cia em 100% e termina em 5%. A lista deve conter 20 nomes possíveis em cada página.
Junto à lista, resultado da pesquisa, o cliente locador vê uma cópia fiel da frente da capa
do DVD, por meio de uma figura. Ele pode visualizar detalhes como nome do filme, re-
senha, atores principais e coadjuvantes, prêmios recebidos, quantas vezes este DVD foi
locado, críticas de dois jornais, ano de lançamento e opinião de até dez locadores desse
DVD – Cliente Locador, Cliente Beneficiário.
Eu havia pensado no caminho clsCliente.curObterResultadoLista(iTipoDeBusca:int,
strTexto:String) – clsFilmes. curObterResultadoLista(iTipoDeBusca:int, strTexto:String).
Esse caminho ainda me parece desnecessário. Vou alterar o diagrama de classes,
retirando da classe clsClienteLocador o método curObterResultadoLista. Este método
passa a ser da página clsPgBusca, que o executará na classe clsFilmes. O relaciona-
mento clsPgInicial com clsClienteLocador deixa de existir.
A classe clsPgBusca já sabe qual é o tipo de busca e sabe também o texto de procura, a
única alteração passa a ser, então, clsPgBusca.curObterResultadoLista(iTipoDeBusca:int,
strTexto:String) – clsFilmes.curObterResultadoLista(iTipoDeBusca:int, strTexto:String).
A classe clsFilmes vai até o banco de dados e executa a procedure de busca de fil-
mes, à qual vamos dar o nome de procRetListaFilmes().
Vamos representar isso no diagrama de seqüência, fase 3, como mostra a Figura 8.3.
O retorno dessa procedure deve remontar a página clsPgBusca e mostrar a lista de
filmes retornados.
Capítulo 8 Diagrama de Seqüência 157

Figura 8.3 Diagrama de seqüência, fase 3.

O sexto cenário principal


6 Seleciona determinado filme, através da descrição, e adiciona na cesta de locações –
Cliente Locador, Cliente Beneficiário.
Conforme a Figura 8.4, não havíamos pensado em métodos na classe clientes que
adicionasse um filme selecionado na cesta de locações, representada pela classe
clsCestaLocacao. Agora, porém, o cliente clica sobre um filme, ou um ícone ao lado
do filme que indica adicionar, e essa ação deve ir até a classe cliente e adicionar o
filme na coleção de filmes que existe em clsCestaLocacao.
Essa ação é executada pela nova classe clsPgBusca. Esse método precisa ser público,
para ser acessado pela página PHP. O método que atende esses critérios é iObter-
FilmeParaCesta (iCodFilme) e este deve ser público.
Deixa de ter necessidade a relação entre clsClienteLocador e clsFilmes. A única res-
ponsabilidade de clsCestaLocacao é saber quem são seus filmes.
Essa adição deve acontecer, por exemplo, com a criação de arquivo texto no servi-
dor em que o session ID de um determinado cliente dá o nome desse arquivo e o
conteúdo do arquivo é a lista de filmes. Esse detalhe de arquitetura deve ser trata-
do com os colegas para conhecermos outras idéias. Cookies, não são aconselháveis
devido à grande dependência que têm dos navegadores clientes.
Não creio que guardar essas informações, por agora, seja uma boa idéia, nem sa-
bemos se o cliente vai alugar as fitas ou não, isso dependerá de outros fatores que
não discutiremos aqui, como o nível de disponibilidade do servidor de arquivos.
Vamos representar estas conclusões no diagrama de seqüência.
158 Desenvolvendo Software com UML 2.0 – Definitivo
Capítulo 8 Diagrama de Seqüência 159

Sétimo cenário principal


7 Deduz a quantidade do DVD escolhido do estoque de cópias – Site.
Nada do que foi pensado no diagrama de classe foi alterado e esta é uma ação feita
de forma transparente para o cliente. Quando este adiciona algum filme à sua ces-
ta de locações, o estoque deve ser diminuído.
Vamos ao diagrama de seqüência.

Figura 8.5 Diagrama de seqüência, fase 3.

Oitavo cenário principal


8 Executa a busca novamente a fim de obter outros títulos – Cliente Locador, Cliente Be-
neficiário.
Assim como disse no diagrama de classes, vale aqui também a assertiva de que
toda a implementação necessária para se realizar este cenário já foi feita, nada há
para se fazer.

Nono cenário principal


9 Identifica-se, através de seu login e senha de cliente locador ou cliente beneficiário –
Cliente Locador, Cliente Beneficiário.
Este cenário pressupõe uma intenção de fechar a compra. Portanto, nosso cliente deve
identificar-se em uma janela de resumo de compras. Acessa, através da página inicial
ou da página de buscas, a página de resumo de compras e nela informa seu login.
160 Desenvolvendo Software com UML 2.0 – Definitivo

Veja que tentei representar um botão de Solicitação de Resumo de Compras, tanto


na página inicial como na página de buscas.
Quando o cliente vê o seu resumo de compras, informa o seu login e senha a fim de
encerrar sua compra.
Quando ele informa o seu login e sua senha, a classe de clsClienteLocador é aciona-
da para fazer a validação desses dados no banco de dados.
Aqui, seria um bom momento para usarmos o Fragmento Combinado com condi-
ções, caso o usuário entrasse com um login ou senha inadequada, poderíamos re-
direcioná-lo para outra ação. Preferi não iniciar este Fragmento Combinado, pois
o diagrama ficaria um pouco ilegível. Para dar nitidez ao diagrama, teria de iniciar
outro e preferi não fazer isso agora. Preferi, apenas, documentar na classe clsClien-
teLocador essa situação.
Vamos ao diagrama de seqüência da Figura 8.6.

Décimo cenário principal


10 Valida o login do cliente locador ou do cliente beneficiário, certificando-se de que
este já se encontra cadastrado, e verifica se o cliente locador está em estado de “Apro-
vado para Locação”. (Ver Caso de Uso Controlar Estado de Cliente Locador e Clien-
te Beneficiário) – Site.
Conforme já foi dito no tópico anterior, preferi apenas documentar esta situação
na classe clsClienteLocador. Caso o cliente não esteja no estado de “Aprovado para
Locação”, não devemos permitir que ele faça alguma locação. Esta também é uma
regra que poderia ser tratada em um Fragmento Combinado, mas isso deixa o dia-
grama ilegível. Crio, então, um novo diagrama para esta situação ou apenas docu-
mento na classe. Foi o que fiz, documentei em bom português o que queria.

Décimo primeiro cenário principal


11 Informa o número do cartão de débito a fim de permitir o débito da locação – Cliente
Locador.
Após a validação do login e da senha, representei uma mensagem recursiva, onde a
classe clsClienteLocador envia para si própria o pedido de execução do método bVa-
lidaRealizaTef (). Este método terminado, uma mensagem de solicitação de transfe-
rência (TEF) vai para a classe clsTEF, pedindo a transferência.
Nenhuma mudança, foi requerida no diagrama de classes como mostra a Figura 8.7.
Capítulo 8 Diagrama de Seqüência 161
162 Desenvolvendo Software com UML 2.0 – Definitivo
Capítulo 8 Diagrama de Seqüência 163

Décimo segundo cenário principal


12 Valida o cartão de débito informado – Site.
Repito o texto da fase de construção das classes. Novamente, nada há a fazer com
relação a este cenário principal. Já resolvemos sua necessidade no cenário princi-
pal 11. O método bValidaRealizaTef da classe clsCliente valida e realiza a operação
de TEF, já citada.

Décimo terceiro cenário principal


13 Informa o tempo aproximado de entrega, em horas, no endereço listado pelo cliente
locador como endereço de entrega – Site.
Ao obter o endereço de entrega do cliente, o método retorna para a página de resu-
mo com as informações da transação de TEF e de endereço de entrega. Caso o
cliente queira alterar este endereço, faz isso através do método clsClienteLocador.
bAlterarEnderecoEntrega (strEnderecoEntrega:String). Bem, isso é apenas um retorno à
página de resumo com informações adicionais.
Fiz uma nota, apontando para este método, para que na programação seja visto
com claridade a intenção. É claro que na classe estereotipada clsPgResumoCompras foi
devidamente documentada.

Figura 8.8 Diagrama de seqüência, fase 8.


164 Desenvolvendo Software com UML 2.0 – Definitivo

Cenários alternativos e requisitos especiais


Nenhum cenário alternativo merece ser destacado no diagrama de seqüência. To-
dos estes cenários são ‘if’, melhor descritos em português na documentação da
classe. O mesmo ocorre com os Requisitos Especiais.

Conclusão
Veja nas próximas figuras a importância do diagrama de seqüência. Baseado neste
diagrama, nós realizamos importantes alterações no diagrama de classes e este,
agora, reflete mais a realidade daquilo que queremos fazer.
Visibilidades foram alteradas, classes e métodos surgiram ou desapareceram, tudo devi-
do à forma de vermos o mesmo domínio de problema que é o Caso de Uso Locar DVD.
De todos os diagramas da UML, acredito que este ao lado do diagrama de Classes
e o de Casos de Usos são os diagramas mais importantes.
Este diagrama nos dá maior segurança sobre o que passaremos para a próxima
fase que é a de programação.
Verifique que realizei um diagrama de seqüência para um Caso de Uso, o de locar DVD.
O ideal é que todos os casos de uso passem por este diagrama. A regra geral é de que, se
existe uma interação com o usuário, esta deve ser retratada no diagrama de seqüência.
Adicionamos, ao diagrama de seqüência, números nos métodos, o que dá a dimen-
são de “em que ordem nós desejamos que as coisas aconteçam”. Essa numeração
não é da UML, é uma constatação minha de que é importante a ordem da progra-
mação para quando formos programar; de quebra, retiro a necessidade premente
do diagrama de comunicação. Dividi as figuras a fim de melhorar a visualização.
A classe tbs_Banco_Locar, na verdade, não é uma classe, e sim a representação (em
uma única classe) das tabelas do banco de dados que serão necessárias para ajudar
a resolver este domínio de problema.
Sim, é verdade, este é o melhor momento para se pensar no banco de dados. A mi-
nha forma, proposital, de não representar o modelo de dados junto com o modelo
de classes, visa separar você desses dois momentos. Existem autores que propõem
que se faça o modelo de dados usando a própria ferramenta de UML. Veja uma
ferramenta de modelagem UML modela UML, uma ferramenta de modelagem
‘MER’ prevê scripts de criação de functions, prevê atualização automática do
banco de dados atual e prevê uma gama variada de bancos de dados. Pode ser mui-
ta coisa para uma ferramenta de modelagem UML se preocupar. Prefiro, em vez
disso, recomendar que você adote uma ferramenta de modelagem MER para pen-
sar o seu banco de dados à parte.
Então, esta única classe representa várias tabelas no banco de dados? A resposta é
sim, e você pode acrescentar uma nota explicando isso a seu público. Quantas são,
quais as tabelas e quais os seus atributos, ainda não sei. Pode, inclusive, haver
coincidência de nomes de tabelas com classes, mas isso não é necessário, são duas
coisas distintas (Modelo de Classes e Modelo de Dados), apesar de existir uma
corrente que diga o contrário.
Capítulo 8 Diagrama de Seqüência 165
166 Desenvolvendo Software com UML 2.0 – Definitivo
Capítulo 8 Diagrama de Seqüência 167
168 Desenvolvendo Software com UML 2.0 – Definitivo
Capítulo 8 Diagrama de Seqüência 169
170 Desenvolvendo Software com UML 2.0 – Definitivo

Exercícios
1. Por que o diagrama de seqüência é conhecido como um diagrama de interação?
2. Quais são os outros diagramas da UML 2.0 conhecidos com esta designação?
3. Cite os usos do diagrama de seqüência.
4. No diagrama de seqüência relacionamos objetos ou classes? Por quê?
5. Classes que representam interfaces gráficas são representadas no diagrama de seqüência?
6. É possível um mesmo objeto chamar um método que se encontra em uma classe do
mesmo tipo do objeto? Como é conhecido esse tipo de método?
7. Como um ator se relaciona com os objetos de um diagrama de seqüência e como os
objetos se relacionam entre si?
8. Momentos de decisão podem ser representados na UML 2.0? Como isso é feito?
9. Continuações complexas podem ser representadas em diagramas separados? Qual a
notação para indicar isso na UML 2.0?
10. Qual a diferença entre as mensagens síncronas e as assíncronas?
11. Uma entidade no banco de dados pode ser representada em um diagrama de seqüência?
12. Podemos representar objetos, no diagrama de seqüência, que não tenham correspon-
dência no diagrama de classes?
13. Um diagrama de seqüência altera o diagrama de classes ou é o diagrama de classes que
altera o diagrama de seqüência?
14. Como é representado um retorno de uma mensagem em um diagrama de seqüência?
15. Como representamos os cenários alternativos dos Casos de Uso em um diagrama de
seqüência?
Não faça nada contra a sua consciência, ainda que o
Estado lhe peça.
EINSTEIN

O coração do homem de Estado deve estar na cabeça.


NAPOLEÃO BONAPARTE

V amos abordar o diagrama de estado no mesmo formato que abordamos os


diagramas anteriores, informando a notação e a conseqüente semântica. Po-
rém acho importante colocarmos alguns comentários de ordem histórica e de uso.
Em 1987, David Harel escreveu um texto abordando o diagrama de estado e, por-
tanto, anos atrás este homem já tinha a visão da necessidade que este diagrama po-
deria apresentar.1 Em 1991, J. Rumbaugh; M. Blaha; W. Premerlani; F. Eddy; W.
Lorensen reafirmaram a importância do trabalho de Harel, elogiando e copiando
seu estilo.2
A UML não inventou o diagram de estado, como já ouvi alguns abordarem, pois a
UML surgiu na década de 90 e Harel escreveu seu trabalho em 1987. Isso é apenas
uma correção histórica e uma comprovação de que a UML congregou o que havia
de melhor em diversas metodologias para transformar-se no padrão que é hoje.
172 Desenvolvendo Software com UML 2.0 – Definitivo

Quando usar um diagrama de estado


Scott Ambler aconselha a criarmos um modelo quando ele fornece algum valor po-
sitivo para os esforços envolvidos.3 Lembre-se: um modelo apenas nos ajuda a en-
tender determinado domínio do problema.
Meilir Page-Jones ensina que este diagrama é útil para a modelagem de classes cu-
jos objetos têm um atributo de estado com estas duas propriedades: o atributo
pode assumir um pequeno número de valores possíveis e as transições permitidas
entre esses valores são restritas. Uma classe talvez tenha dois ou mais atributos de
estado que podem ser proveitosamente modelados com diagramas de estado.4
Page-Jones também avisa:
“Um diagrama de estado não capta – e não deve captar – todas as facetas e algorit-
mos possíveis da classe. Se você acha que seu diagrama de estado está se tornando
uma ‘miscelânea’ de estados e condições, então muito provavelmente você gosta-
ria de repensar sua noção de classe – ou, no mínimo, posteriormente, abstrair seu
diagrama.”
Então, sabemos que, quando tivermos uma classe com um ou mais atributos, que
reflitam o estado de seus objetos em um determinado tempo, e que esses atributos
merecem ser modelados visando simplificar sua complexidade, podemos criar o
diagrama de estado. Quando digo atributo de uma classe, isso quer dizer um atri-
buto de instância (e, portanto, de um objeto), como também um atributo estático
de uma classe.
Se o relacionamento de classes não está claro o suficiente em função do estado dos
objetos, isso será uma pista de que você deve usar este diagrama. Esta percepção é
pessoal. Isso pode ser feito em qualquer momento da especificação e construção,
porém creio que todo o software terá um momento desses que merece ser modela-
do. Considero as duas regras do Meilir Page-Jones muito atraentes – valores dis-
cretos e restrições entre passagem de estados –, muito úteis para detectarmos a
necessidade de um diagrama de estado.
Essas duas regras informam que, se temos uma gama muito grande de possibilida-
des de estados, como por exemplo o cargo de um funcionário, isso não é passível
de ser modelado, pois existem muitas possibilidades. Outra pista é a de que, se
existem regras, por exemplo: um pedido deve ser separado, para somente depois
ser disponibilizado para entrega, elas são restrições de passagem de estados, possí-
veis de serem modeladas em um diagrama de estado.
Quem for efetivar a programação precisa tanto conhecer esse universo discreto de
possibilidades como essas regras de passagem de estados. No fim de tudo, nova-
mente, o seu diagrama de classes pode sofrer pequenas alterações, porém esse dia-
grama deve ser passado para a fase de programação a fim de clarear o negócio
envolvido.
Capítulo 9 Diagrama de Estado 173

A notação do diagrama de estado


A notação do diagrama de estado segue a notação do diagrama de atividades, po-
rém vou abordar aquilo que podemos usar na maioria das situações de modelagem
de estados.

Um retângulo designa um estado simples. O mais comum usado nos


diagramas de estado que você pode levar avante. Seus cantos são ar-
redondados. Um único valor, de um atributo de uma classe, pode ser
representado por um estado simples.

Um retângulo maior designa um estado composto ou máquina de es-


tado, significando que nele existirão outros estados. Este tipo de es-
tado também é muito utilizado, porque se tivéssemos poucos
estados simples, talvez não valeria a pena sequer termos um diagra-
ma de estado. Assim, quando começamos a trabalhar com a necessi-
dade de estados compostos, passamos a ter a necessidade de um diagrama para
resolver a questão. Quando outros estados (simples) estão participando de deter-
minado estado composto, estes são desenhados em seu interior. Conforme a pró-
xima figura.

Podemos ter a necessidade de um estado composto, porém


com regiões. Essas regiões são separadas por uma linha pon-
tilhada, vertical ou horizontal, dentro do estado. Cada re-
gião pode ter um nome diferente e seus estados separados,
ou seja, cada região pode ter vários estados funcionando in-
dependentemente. Qualquer estado dentro de uma região é
considerado um subestado de um estado composto. Este
tipo de máquina de estado também é conhecido como esta-
do concorrente.
174 Desenvolvendo Software com UML 2.0 – Definitivo

Um círculo preenchido designa um estado inicial chamado, na


verdade, de pseudo-estado inicial. Chamo-o de início. Quando
atribuo um valor para o atributo que representa este estado, dou o valor zero.

O estado final é representado por um círculo vazado e, dentro


deste, um círculo cheio. Você pode chamá-lo de olho de boi. O úl-
timo estado de um objeto será representado por este estado final.

Um círculo simples é um es-


tado de escolha. Ao se che-
gar em um estado de esco-
lha, o software deve tomar
uma decisão e ir para qual-
quer estado possível, dos que
saem do estado de escolha.
Utilizar o tradicional losango
para retratar esta decisão
não estará errado. Aliás, man-
ter a notação do losango é
muito mais intuitivo. É comum representarmos essas escolhas com [atributo x > va-
lor], o que representa uma condição na UML.

Podemos ter a neces-


sidade de representar
que variados estados
podem chegar em um
único ponto. Este pon-
to é conhecido como
ponto de junção: um
círculo preenchido.
Capítulo 9 Diagrama de Estado 175

Assim como mostrado no dia-


grama de atividades, aqui tam-
bém se usa o Fork. A chegada
de um estado a um fork pode
desencadear um ou vários es-
tados concorrentes.

Também, temos no diagrama de estado um


Join, representando vários estados, converten-
do-se em apenas um.

Uma seta, saindo de um estado e


apontando para outro, designa
uma transição de estados. Esta
progressão de um estado para outro é provocada por um evento interno ou externo à
entidade que está sendo modelada. No caso de classes, as transições são resultantes de
chamadas a métodos que provocam uma alteração do estado.

Na figura precedente, temos um ponto de entrada, conhecido como entry action,


no Estado_Simples1, este ponto de entrada significa que a todo o momento que en-
trarmos neste estado esta operação será realizada, no caso, na operação funcXpto().
Veja que isso é diferente de dizer que executaremos uma determinada ação para
entrarmos em um estado.
176 Desenvolvendo Software com UML 2.0 – Definitivo

Aqui, já estamos dentro do estado e esta entry action indica que o método será exe-
cutado na entrada deste estado. Uma barra separa a palavra entry (entrada) da
operação. Poderia surgir a questão: “Como um objeto ao entrar em um estado
executa sozinho a entry action?”. A resposta é que somente existe uma passagem
de estado se um método em uma classe provocou isso. Um método faz uma análi-
se, determinada condição foi alcançada? Se a resposta for sim e outro estado for
provocado, o programador deve saber que o próximo estado tem uma entry action,
então altera o estado do objeto e executa o método da entry action.
A transição está indicada com uma operação (funcXpta()) e também com uma con-
dição opcional [ Se a = 2]. Esta condição é chamada de Guard.
No Estado_Simples2 temos a exit action, que faz a oposição a entry action. Toda
vez que sairmos do estado, esta operação será realizada, no caso, funcXptu(). Uma
barra separa a palavra exit do nome da operação.
Não está representado na figura, porém temos também um tipo de ação que é exe-
cutada durante todo o tempo de permanência naquele estado. Esta ação é repre-
sentada por do action e também é separada por uma barra, assim como as outras.
Isso deve atender a todas as suas necessidades de análise em máquinas de estado.
É facil perceber então que um estado tem dois compartimentos, um com seu nome
e outro com suas ações internas. Essas ações (métodos) terão de existir em uma de-
terminada classe.
As transições de estado também podem ser ações (métodos) e as condições podem
acompanhar essas transições, por exemplo: Há uma transição, mas, somente se
uma condição for atingida, determinado método deverá ser disparado.

A construção do diagrama de estado para a cesta de locação


No diagrama de estado a seguir, procurei representar dois atributos que contro-
lam o estado da Cesta de Locação. Um deles é o iStatusGeral, criado posteriormen-
te na classe. Este estado é igual a 1 quando a cesta de locação está passando por
qualquer tipo de alteração, seja incluindo filmes ou retirando filmes da cesta. Este
estado permanece em 1 enquanto o outro iStatusLocacao entra em 1, caso seja esco-
lhido um filme. Sabemos que foi escolhido um filme porque foi executado o méto-
do iObterFilmeParaCesta. Enquanto a cesta estiver neste estado, deve ser executado o
método que adiciona na coleção de filmes que se encontram na cesta. Terminada
esta adição, o iStatusLocacao passa para 2, informando que o filme foi adicionado.
Há uma decisão a ser tomada: caso o cliente deseje, pode retirar filmes, o que leva
iStatusLocacao para 3, realizando a retirada da coleção assim que é feita a entrada
neste status. Esse evento resulta no estado de filme retirado com valor 4. A possi-
bilidade é de o cliente continuar retirando ou voltar a adicionar um filme. Pode-
ria ter sido representada, inclusive, a ação de pesquisar filmes a adicionar.
Capítulo 9 Diagrama de Estado 177

Figura 9.1 Diagrama de estado para a classe clsCestaLocacao.

Fora de iStatusGeral, duas ações são possíveis: cancelar a cesta de locação, o que
leva o iStatusGeral ao valor 4 – isso irá requerer esvaziar a coleção e seguir para o
estado final. Outra possibilidade é o cliente informar o Fechamento da Locação e
178 Desenvolvendo Software com UML 2.0 – Definitivo

existirem filmes na cesta; desta forma, iStatusGeral vai a 2 e entra em validação de


TEF que detém o valor 3. Se a operação de TEF for bem sucedida, devemos adicio-
nar a cesta propriamente no banco de dados (5) e seguir para o término da loca-
ção, que deve esvaziar qualquer tabela temporária criada durante o processo (6) e
isso leva ao estado final. Caso a operação de TEF, não tenha obtido sucesso, isso
necessita ser informado (7) e chegamos novamente no estado final.

Conclusão
É possível que seu software não requeira um diagrama de estado, apesar de eu crer
que pelo menos um diagrama de estado esteja presente nos softwares, isso vai de-
pender do domínio do problema com o qual estamos trabalhando. Aplicações co-
merciais, com freqüência, necessitam mostrar evolução ou andamento de determi-
nado conjunto de cenários ou apenas um cenário ao longo do tempo para um dado
objeto. O diagrama de estado é ideal para este tipo de modelagem.
Programadores têm uma melhor visão do que é esperado como regra em determi-
nado (s) atributo (s) de determinada (s) classe (s) com seu universo de promoção e
regras de passagem entre estados.
É muito melhor analisarmos o comportamento do estado de um objeto, tendo vá-
rios Casos de Uso. No nosso exemplo, temos o Caso de Uso Locar DVD. Podería-
mos agregar valor se considerássemos os Casos de Uso: Entregar Cesta de
Locação, Devolução de DVDs, Conferência de Integridade de DVD Devolvido etc.
Dessa forma, teríamos a visão da nossa Cesta de Locação (que é o pedido) ao longo
de seus estados possíveis.

Exercícios
1. Quais as regras que Meilir Page-Jones recomenda que sigamos para decidirmos se usa-
mos ou não um diagrama de estados?
2. O que é uma máquina de estados?
3. Um estado de escolha pode ser representado por um losango, formato tradicional, po-
rém qual é a outra forma de grafar em estado de escolha?
4. Como podemos indicar o que é escolhido, textualmente, em um estado de escolha?
5. São possíveis vários pontos de entrada (estados iniciais) e seus conseqüentes pontos de
saída (estados finais)?
6. O que é um entry point ou entry action? Explique o uso.
7. O que é um exit action? Explique o uso.
8. Um estado é provocado por ações. Como esse conjunto é representado em classes?
9. Um objeto que tenha seu estado representado apenas por dois valores não vale a pena
ser modelado? Por quê?
10. Alterações e incrementos de estados provocam mudanças no diagrama de classes?
Explique.
Haaa! Eu sonhei... Dados – jogar com dados: A sorte mudará
em breve. Ganhar nos dados receberá herança. Outras pessoas
jogando: Terá recursos abundantes.
ANÔNIMO

– Por favor senhor, preencha seus dados.


– Mas o que são estes dados?
ANÔNIMO

I nicialmente pensei em não colocar nada a respeito de banco de dados neste livro.
Depois, concluí que algumas palavras seriam interessantes, já que, nos cursos
que ministro, falo a respeito de banco de dados naquilo que é essencial para a con-
clusão do desenvolvimento de software usando a UML 2.0 na prática.
Então pensei em inserir uma parte dedicada a banco de dados em um apêndice.
Isso ficaria meio solto, como uma parte opcional e sabemos que banco de dados
em aplicações corporativas não é opcional. Então, decidi inserir este tópico logo
após o que considero a espinha dorsal da UML (Diagramas de Casos de Uso – Des-
crição de Casos de Uso – Classes – Seqüência – Estados).
A evolução natural após esses passos é pensarmos em um Modelo de Entidade e
Relacionamento – MER.
Eu iria colocar um aviso redundante em cada subtópico informando “Breve Resu-
mo”. Creia, isso é um substrato de um resumo da teoria de banco de dados. Reco-
mendo fortemente que você leia um texto a respeito, por exemplo o texto de Peter
180 Desenvolvendo Software com UML 2.0 – Definitivo

Chen.1 Este é um texto curto que aborda o essencial para um melhor entendimen-
to, porém se precisar de material mais extenso serão necessários outros textos a
respeito.
E, caso você precise de uma definição para banco de dados, aí vai uma: Uma cole-
ção de dados inter-relacionados e armazenados de forma independente das aplica-
ções que os utilizam.
Uma organização pode ter um ou vários bancos de dados. Um banco de dados
pode (e deve) ter várias entidades. Cada entidade guarda informações de um deter-
minado assunto dessa organização. Essas entidades são divididas em linhas ou re-
gistros, e estes divididos em colunas chamadas de campos. Cada campo trata de
um dado diferente, cada registro trata de uma ocorrência para o assunto que aque-
la tabela cuida. Cada tabela ou entidade cuida exclusivamente de um determinado
assunto.
Os valores são guardados em campos divididos por tipos: caracteres, textos, nú-
meros etc. Enquanto um valor é visto isoladamente em um campo, ele á apenas um
dado. Por vezes, podem ocorrer situações em que registros ou linhas inteiras são
apenas dados. Quando relacionamos esses dados é que obtemos a informação.
Ao desenho de diagramas, que mostra o relacionamento entre entidades para ob-
termos uma informação, chamamos de Modelo de Entidade e Relacionamento ou
sua abreviação: MER.
Vamos chamar nossas entidades ora de tabelas ora de entidades, os termos são si-
nônimos.

Quando devemos pensar no banco de dados?


Bem, já dei um briefing deste assunto no parágrafo anterior, mas vamos colocar de
forma diferente...
Creia-me que não existiu, até hoje, um único curso que eu tenha ministrado em
que já, desde o primeiro dia de aula, algum ou alguns alunos não me perguntaram
durante as aulas ou em particular: “Eu gostaria que o senhor abordasse o banco de
dados, onde ele entra na UML?” Outros são mais diretos e perguntam: “E o Banco
de Dados?”
Não é necessário dizer mais nada, eu já sei do que se trata. Durante um bom tempo
eu fui desenvolvedor de software estruturado e a primeira coisa que pensava era o
Modelo de Dados.
Primeiro devemos pensar no MER! Aprendíamos assim nos cursos de graduação e
pós-graduação, colegas mais experientes faziam assim, livros e mais livros davam
o exemplo de pensarmos primeiro no modelo organizacional da empresa, seguido
do modelo conceitual e, em seguida, era fatal um DFD (Diagrama de Fluxo de Da-
dos) para amparar nosso MER. Então, por que não copiar?
Capítulo 10 Banco de Dados 181

A resposta é que isso não funciona quando você usa a UML. Os diagramas da
UML foram conduzindo o contexto do banco de dados. Espero que você tenha
percebido isso durante os capítulos anteriores.
Bem, vamos responder à pergunta – Quando devemos pensar no Modelo Entidade
e Relacionamento (MER)? A resposta é: Quando você terminar o diagrama de se-
qüência e os devidos ajustes no diagrama de classes respectivo.
Pense comigo, o diagrama de classes, no primeiro momento, ajustava o negócio a
ser modelado de acordo com os Casos de Uso descritos. Esse momento era concei-
tual. O segundo momento de confecção do diagrama de classes era modelarmos a
especificação e tinha, também, a função de permitirmos ao usuário, por meio de
uma interface gráfica, incluir, excluir, alterar e consultar dados. Este é o momento
do diagrama de seqüência. Neste momento, refinamos o diagrama de classes, com
visibilidade, coleções, atributos ou propriedades específicas da nossa necessidade.
Então, não há melhor momento para pensarmos no banco de dados. A minha su-
gestão é de que:

1. Houve o entedimento da Visão.


2. Houve a composição dos módulos do software em função da Visão.
3. Ocorreram as descrições de Casos de Uso.
4. A seqüência da interface gráfica até o banco de dados foi definida.
Se é assim, temos exatamente as classes, os métodos e os atributos que precisamos
para atender a determinado conjunto de Casos de Uso, nada sobra ou falta. Diante
deste quadro e com o assunto fresco na mente, não há melhor momento para pen-
sarmos no modelo entidade relacionamento.
Você observou, até mesmo, que, ao criarmos o diagrama de seqüência, descobrimos
as stored procedures que nosso banco deve fornecer. Como exemplo, precisávamos
montar o menu com os textos que apareceriam representando os grupos de escolha
do usuário. Para isso, criamos a necessidade da SP_procMontarGrupos(Pag), que recebe
como parâmetro a página Web com a qual ela deveria se preocupar, veja a Figura 8.3.
Se um analista, ou grupo de analistas de negócios, cuidaram dos casos de uso de
um determinado módulo, eles são os mais indicados a pensarem no modelo de da-
dos. Espera-se, assim, que nada falte ou sobre neste modelo.
Evidentemente, este trabalho não deve ser deixado para ser executado por último
no ciclo de análise. Um monstrengo seria criado no banco, caso agíssemos assim.
Logo que o diagrama de seqüência esteja pronto, comece o diagrama de entidade e
relacionamentos.
É evidente, também, que se você precisou de um diagrama de estados, este deve ser
considerado na construção do modelo entidade e relacionamento.
182 Desenvolvendo Software com UML 2.0 – Definitivo

Mas classes não são tabelas do banco de dados?


Outra pergunta recorrente é o título deste tópico. Vejam, a resposta é simples e sou
categórico nisso: NÃO. Classes representam modelos para objetos que serão ins-
tanciados na memória, conforme você já aprendeu. Tabelas de bancos de dados
são repositórios de dados, ou seja, guardam dados para que sejam geradas infor-
mações; para isso precisamos guardá-los, apenas isso.
Podemos ter vários objetos na memória, realizando determinada operação e seguir
uma tabela no banco de dados para guardar informações sobre estas operações.
Esta resposta é válida para quando falamos de banco de dados relacionais. Banco
de Dados orientados a objetos, não apresentam este misticismo, suas classes serão
objetos no banco, ponto final. Nosso texto é focado em banco de dados relacio-
nais, pois aí residem grandes dúvidas.
Ao terminar a análise do seu MER, é evidente que tabelas com os mesmos nomes de
algumas classes aparecerão, porém isso não significa que elas estão lá porque existem
classes delas. Essas tabelas estão lá porque você precisou delas, esta é o meu approach.

Então como descobrimos as entidades no banco de dados?


Vamos a uma pequena revisão. Antes, porém, é necessário que você entenda que
nada há de novo aqui desde tempos imemoriais.
Suas entidades podem surgir de:
Atores, pois estes podem ter de guardar suas identificações por questões de transa-
ções ou logs.
O produto final do negócio sendo modelado, a análise estruturada chamava isso
de Objetos, mas este termo não nos deixa confortáveis diante de nossa definição
de objeto. Como exemplo, em uma situação que trate a fabricação de bicicletas,
necessitaremos guardar informações sobre este produto.
Ocorrências, que são acontecimentos resultados de um ator ou mesmo de um obje-
to instanciado. Como exemplo, nosso ator Cliente Locador aluga DVDs pela
Web; isso é uma ocorrência que merecerá ser guardada.
Situações Acessórias. Não se encaixam em nenhuma das situações anteriores. Nes-
te quadro temos entidades que guardam características de outras. Na nossa aplica-
ção temos que um Cliente Locador Aluga DVDs. Em algum lugar, precisaremos
guardar os dados de quem alugou o quê. Uma entidade registrará os dados do
cliente, os DVDs que este alugou e quando, para fins de relatórios, por exemplo.
Entidades Formais, são aquelas provenientes de um relatório que necessita ser preen-
chido.
Entidades Informais, são aquelas que o usuário cria sem o conhecimento da orga-
nização, porém funcionam e muito bem. Neste grupo estão planilhas e formulá-
rios diversos.
Capítulo 10 Banco de Dados 183

Falamos a respeito de entidades formais e informais quando abordamos como es-


crever um Caso de Uso, releia o capítulo caso ainda tenha dúvidas.

Como é um dicionário de entidades?


A maioria, senão todos, bancos corporativos lhe permitirão criar um Dicionário
de Entidades.
Um dicionário de entidades concrega todas as informações que uma entidade pode
ter. Normalmente um dicionário de entidades é dividido em partes, quais sejam:
Nome da Entidade, uma Definição em Compreensão, uma Definição em Extensão
e suas Organizações.
Vamos mostrar um dicionário criado para uma entidade, no nosso caso para a en-
tidade cliente locador. Vamos criar a entidade de forma bruta e, em seguida, mos-
trar as conseqüentes normalizações.
A próxima tabela mostra este dicionário. Logo acima temos o nome da entidade
que nos facilita a busca, abaixo temos uma breve descrição que nos informa para
que essa entidade serve e a última seção nos mostra como ela é formada.

Tabela 10.1 Dicionário de entidades


ClienteLocador Nome da Entidade
Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do Cliente Locador que identificam
univocamente este ator que utiliza a aplicação.
Propriedades= Definição em Extensão
- Código de Locador +
- Nome do Locador +
- Login do Locador +
- Senha do Locador +
- [RG/CPF] +
- Endereço =
Logradouro +
Complemento +
Cidade +
CEP +
Sigla do Estado +
- (e-mail) +
- DVDs Alugados =
1{ Nome do DVD +
Ano de Produção +
184 Desenvolvendo Software com UML 2.0 – Definitivo

Tabela 10.1 Dicionário de entidades. (Continuação)


1 {Nome do Ator}n+
1 {Nome do Diretor}n+
Gênero+
Descrição+
Endereço do Gif}n

Sabemos que uma entidade no banco de dados deve ter estas partes e recebe o
nome de entidade devido a uma convenção. Cada entidade é parte de um ou vários
arquivos físicos no disco rígido de um servidor de dados. É comum chamarmos
uma entidade de tabela, este é um jargão comum no mundo relacional.
Vamos nos preocupar apenas com a entidade criada ClienteLocador, pois nosso tex-
to não terá espaço para abordarmos um modelo inteiro. Escolhemos esta endidade
porque nos deparamos com o Caso de Uso Locar DVD, que utilizava informações
de um cliente locador.

Como damos a unicidade aos registros de uma entidade?


No nosso exemplo, caso quiséssemos obter a unicidade de um registro na entidade
ClienteLocador e usássemos o nome, teríamos duplicidade pois, por exemplo, te-
remos vários clientes com o nome José. O login também passa pelo mesmo proble-
ma. O conjunto login e senha poderiam ser boas formas de garantirmos a
unicidade de um cliente locador, já que não permitiríamos um mesmo conjunto lo-
gin e senha para dois clientes. Porém, ambos os campos são de caracteres, pode-
mos correr o risco de os mesmos (login e senha) serem escritos de forma diferente,
porém continuarão a ser os mesmos.
No endereço, nem pensamos, já que clientes com os mesmos nomes podem residir
na mesma cidade, logradouro e complemento.
O RG ou CPF parece bom, porém podemos ter clientes que têm um mas não o outro.
Então descobrimos que:

1. Se um campo de uma entidade é passível de repetição.


2. É opcional.
3. É um texto ou caractere isolado.

Não será adequado para identificar univocamente um registro. Desta forma, no


nosso exemplo, não temos um campo que nos satisfaça.
Vamos criar um campo que guarde um código deste cliente locador; será responsa-
bilidade do banco guardar a numeração dessa propriedade.
Capítulo 10 Banco de Dados 185

O tipo deste campo é comum entre os bancos de dados e este tipo é Sequence*, um
número seqüencial incrementado pelo próprio banco de dados.
Por esta razão temos o campo Código de Locador, veja a tabela anterior. Esta pro-
priedade tem condições de dar unicidade a nosso registro, por esta razão você a vê
sublinhada. Esta é a nomenclatura para designarmos uma propriedade que identi-
fica um registro de forma unívoca, um sublinhado.
Este campo recebe um nome especial, que é o de chave primária, Identificador de
Elemento, primary key ou PK simplesmente.
Uma chave primária não necessariamente é composta de um único campo. Várias
propriedades ou campos podem compor uma chave primária. Porém, o usual é fi-
carmos com poucas propriedades para compor a chave primária, isso por motivos
de desempenho. Uma chave primária é também um índice que o banco utiliza para
efetivar buscas. Quanto mais campos tivermos em uma chave primária, mais lenta
será uma busca baseada nesta chave.
Vamos entender os símbolos que aparecem em um dicionário de entidades.

Tabela 10.2 Notação usada em dicionário de entidades


Símbolos Significado
= É composto de
+ E
() Opção
[] Seleção
{} Iteração
* Comentário

Verifique, novamente, a entidade Cliente Locador e tente ler a entidade usando a


significação dada na Tabela 10.2.
Os únicos comentários ficam por conta da Opção representada por parênteses,
este é o caso do campo e-mail: alguns clientes podem ter, outros não.
Seleção, representada por colchetes [], que é o caso de RG ou CPF: Um cliente
pode escolher qual informar.
Iteração, representada por chaves {}, que é o caso de DVDs alugados: um cliente
pode ter muitos e estes, por sua vez, podem ter vários atores e diretores.

* Vários alunos se queixam que, quando um número do Sequence é excluído, passa a existir uma
‘vaga’, um ‘buraco’ jamais reaproveitado pelos bancos de dados. Eu sempre me pergunto: E daí?
Deixe os brancos acontecerem, por que razão isso tem de ser reaproveitado?
186 Desenvolvendo Software com UML 2.0 – Definitivo

Como é um dicionário de dados?


Um dicionário de dados segue o esquema representado a seguir. Cada entidade,
em um banco de dados, tem uma folha do dicionário de dados para cada campo.

Tabela 10.3 Dicionário de dados


Código de Locador

Este é um número Sequence, que dará ao cliente locador do site a unicidade de registro.
Aplicações:
ClienteLocador
- Regras:
É Obrigatório
ClienteBeneficiário
- Regras:
É Obrigatório
Regras Gerais:
Os domínios permitidos são: 1 até n (onde n é o máximo de um big int do banco de dados)

Este é o exemplo de um único campo (Código de Locador). Há uma breve descri-


ção, seguida das suas aplicações, ou seja, em quais entidades este campo pode ser
usado, seguida das regras que devem ser obedecidas em cada uma delas.
Regras gerais, normalmente, informam o domínio que, em banco de dados, versa
sobre o tipo de dado e sua amplitude.

Relacionamentos entre entidades


Um vínculo existente entre duas entidades é chamado de relacionamento. Se na de-
finição em extensão de uma entidade existe um campo pertinente a outra entidade,
dizemos que as duas entidades se relacionam.
Um relacionamento implica uma cardinalidade, ou seja, quantas vezes um deter-
minado conteúdo de um campo pode aparecer em outra entidade, ou mesmo, quan-
tos registros em outra entidade são ‘possuídos’ pela entidade que os relaciona.
As cardinalidades podem ser: 1:1, 1:N, N:N ou mesmo auto-relacionamento, onde
uma entidade referencia outra linha por meio de uma determinada propriedade.
Capítulo 10 Banco de Dados 187

Seguem alguns exemplos destes relacionamentos com cardinalidades:

Os exemplos anteriores indicam que, respectivamente:


A relaciona-se com muitos resgistros em B e vice-versa;
A pode possuir relacionamentos de 1:1, N:1, N:N na própria entidade A;
Um registro de A pode relacionar-se com vários registros em B;
Um registro em A está relacionado com apenas um registro em B.

Chave estrangeira FK
Quando o identificador unívoco, ou chave primária, de uma entidade é declarado
em outra entidade, este é chamado de chave estrangeira, foreign key ou simples-
mente FK.

Figura 10.1 Exemplo de chave estrangeira.

A figura anterior nos dá uma idéia da notação para uma chave estrangeira. Neste
exemplo, o campo iCodLocador aparece na tabela ClienteBeneficiario como foreign
key e também como primary key.
188 Desenvolvendo Software com UML 2.0 – Definitivo

A linha que forma o relacionamento entre as duas entidades tem uma terminação
que indica a multiplicidade; neste desenho um registro em ClienteLocador relacio-
na-se com vários registros em ClienteBeneficiário, esta notação tem o mesmo signi-
ficado de uma linha com um círculo sólido no lugar do ‘pé-de-galinha’.

Normalização
Normalizar um banco de dados é organizá-lo: retirar as redundâncias de dados e
decompor seu conteúdo para facilitar a compreensão.
Este processo leva tempo e requer o uso de algumas técnicas chamadas de formas
normais. As formas normais são divididas em níveis ou graus, há literatura falan-
do de formas normais até quarto ou quinto graus. No nosso texto, vamos até a ter-
ceira forma normal ou forma normal de terceiro grau.
Este assunto é importante porque aqui reside uma das grandes diferenças entre um
modelo de classes e um Modelo de Entidade e Relacionamentos – MER. Classes
não são normalizadas como tabelas o são. Isso resulta que os modelos de tabelas
poderão conter mais tabelas do que classes.
Vamos normalizar nosso modelo ClienteLocador. Para isso devemos observar as es-
truturas de repetição que aparecerem.

Primeira forma normal


Observe o dicionário de entidades e identifique as estruturas de repetição que apa-
recerem, aquelas que apresentam a possibilidade de estar entre chaves {}. Quando
você retira essas estruturas de repetição está normalizando na primeira forma normal.
No nosso exemplo ClienteLocador, temos uma estrutura de repetição nos campos:
DVDs Alugados e, dentro deste campo, temos outros dois Atores e Diretores, pois
um filme em DVD pode ter vários atores e diretores.
Desta forma retiremos as estruturas de ClienteLocador e criemos outras:

ClienteLocador Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do Cliente Locador que identificam
univocamente este ator que utiliza a aplicação.
Propriedades= Definição em Extensão
- Código de Locador +
- Nome do Locador +
- Login do Locador +
- Senha do Locador +
- [RG/CPF] +
Capítulo 10 Banco de Dados 189

ClienteLocador Nome da Entidade


- Endereço =
Logradouro +
Complemento +
Cidade +
CEP +
Sigla do Estado +
- (e-mail) +

DVD Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do DVD que o identificam univocamente.
Propriedades= Definição em Extensão
- Código de DVD +
- Ano de Produção +
- Gênero+
- Descrição+
- Endereço do Gif +

Ator Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do Ator.
Propriedades= Definição em Extensão
- Código de Ator +
- Nome +
- Endereço do Gif do Ator+

Diretor Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de um Diretor.
Propriedades= Definição em Extensão
- Código de Diretor +
- Nome +
- Endereço do Gif do Diretor+

Agora temos quatro modelos e fizemos isso para retirar as estruturas de repetição.
190 Desenvolvendo Software com UML 2.0 – Definitivo

Segunda forma normal


Quando não existem mais estruturas de repetição, porém existem estruturas de de-
pendência e seus valores podem ser repetidos, você pode normalizar na segunda
forma normal.
No nosso exemplo, temos ClienteLocador com uma estrutura de dependência que é
a de endereço. Cada cliente tem seu endereço e dependemos dele para fazer a entre-
ga e eventuais cobranças, porém vários clientes podem residir em um mesmo ende-
reço. Endereço é, também, uma estrutura: logradouro, complemento, número etc.
Se esta situação existir e você separá-la em outras entidades, estará normalizando
na segunda forma normal.
Veja os próximos exemplos quando normalizamos ClienteLocador, que já se encon-
tra na primeira forma normal, para a segunda forma normal.

ClienteLocador Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do Cliente Locador que identificam
univocamente este ator que utiliza a aplicação.
Propriedades= Definição em Extensão
- Código de Locador +
- Nome do Locador +
- Login do Locador +
- Senha do Locador +
- [RG/CPF] +
- (e-mail) +

Endereço Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de um Endereço.
Propriedades= Definição em Extensão
- Código de Endereço +
- Logradouro +
- Complemento +
- Cidade +
- Sigla do Estado +
Capítulo 10 Banco de Dados 191

Terceira forma normal


Quando, dentro de uma entidade normalizada na segunda forma normal, existi-
rem campos que propiciem a repetição, como cidades e estados da federação e es-
tas forem retiradas, estaremos normalizando na terceira forma normal.
No nosso exemplo, isso acontece em Endereço, pois vários clientes podem residir na
mesma cidade. Imagine uma cidade com o nome de Santa Cruz das Almas de Jabo-
ticabal. Vou economizar muito espaço se referenciar essas cidades por um número
em vez de pelo seu nome. O mesmo acontece com o Estado, Unidade da Federação.
Veja a seguir o exemplo Endereço sendo normalizado na terceira forma normal.

Endereço Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de um Endereço.
Propriedades= Definição em Extensão
- Código de Endereço +
- Logradouro +
- Complemento +

Cidade Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de uma Cidade.
Propriedades= Definição em Extensão
- Código da Cidade +
- Descrição +

UF Nome da Entidade
Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de uma UF.
Propriedades= Definição em Extensão
- Código da UF +
- Descrição +
192 Desenvolvendo Software com UML 2.0 – Definitivo

Realizando os relacionamentos do MER encontrado


Conseguimos normalizar nosso banco de dados. Agora precisamos dizer que, por
exemplo, determinado endereço está em uma determinada cidade. Iniciamos, en-
tão, o processo de relacionamento dessas entidades.
Vamos iniciar pelo fim, Cidade e UF. O nome de uma cidade pode aparecer em diver-
sas UFs, isso faz sentido. Então surgiu a necessidade de criarmos uma entidade relacio-
nada tanto à Cidade como à UF. Além disso, endereço pode, agora referir-se à sua lo-
calização, bastando um número, que será de uma cidade UF, que ficaram assim:

Cidade Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de uma Cidade.
Propriedades= Definição em Extensão
- Código da Cidade +
- Descrição +

CidadeUF Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de uma CidadeUF.
Propriedades= Definição em Extensão
- Código da CidadeUF +
- Código da UF +
- Código da Cidade +

UF Nome da Entidade
Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de uma UF.
Propriedades= Definição em Extensão
- Código da UF +
- Descrição +
Capítulo 10 Banco de Dados 193

Endereço Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações de um Endereço.
Propriedades= Definição em Extensão
- Código de Endereço +
- Código da CidadeUF +
- Logradouro +
- Complemento +

Agora, podemos informar em qual endereço se localiza um cliente locador. Esta


modificação provocou a seguinte alteração em ClienteLocador.

ClienteLocador Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do Cliente Locador que identificam
univocamente este ator que utiliza a aplicação.
Propriedades= Definição em Extensão
- Código de Locador +
- Código de Endereço +
- Nome do Locador +
- Login do Locador +
- Senha do Locador +
- [RG/CPF] +
- (e-mail) +

Agora, precisamos relacionar DVD a atores e diretores. Um único filme de DVD


pode ter vários atores e diretores, vamos resolver isso.

DVD Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do DVD que o identificam univocamente.
Propriedades= Definição em Extensão
- Código de DVD +
- Ano de Produção +
- Gênero+
- Descrição+
- Endereço do Gif +
194 Desenvolvendo Software com UML 2.0 – Definitivo

DVDAtor Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do DVDAtor.
Propriedades= Definição em Extensão
- Código de DVDAtor +
- Código de DVD +
- Código de Ator +

DVDDiretor Nome da Entidade


Conjunto de registros tal que cada registro contém Definição em Compreensão
informações do DVDDiretor.
Propriedades= Definição em Extensão
- Código de DVDDiretor +
- Código de DVD +
- Código de Diretor +

Creio que podemos montar nosso modelo em um diagrama.

Figura 10.2 Modelo entidade relacionamento que modela o cliente locador.


Capítulo 10 Banco de Dados 195

Observações sobre o modelo


Quando iniciei a modelagem da classe clsClienteLocador precisei criar as entidades
ClienteLocador, Endereço, CidadeUF, UF e Cidade. Veja que apenas uma classe ensejou
cinco entidades no banco de dados e o inverso poderia ser verdadeiro.
Coincidências aconteceram quando desejei resolver os títulos que um cliente loca-
dor aluga. Aí precisei das entidades: DVD, DVDDiretor, DVDAtor, Diretor, Ator, para re-
solver as classes clsFilmes, clsAtores e clsDiretores. As coincidências que aconteceram
foram nos nomes. Novamente tivemos cinco entidades para resolver três classes.
Se quiséssemos resolver as classes de clsGrupos e outras, teríamos de pensar em um
modelo que amparesse essa nova abstração do négocio.
Este meu solilóquio foi no interesse de mostrar a não obrigatoriedade de relações
existentes entre um modelo de classes e um modelo de entidades do banco.

Atributo de classe e campo de tabela, como resolver?


Se tivermos um atributo de uma classe que está mapeado para um campo de uma
entidade no banco de dados, devemos marcá-lo com o modificador Persistente.
Esse modificador pode ser usado tanto para uma classe como para um atributo es-
pecífico, ou mesmo vários atributos.
Retire da cabeça a idéia de ter uma única classe que cuide de todas as inclusões, al-
terações e consultas no seu banco de dados. Esta classe será um verdadeiro ‘balaio
de gatos’.
Deixe que métodos de cada classe cuidem do que deve ser guardado e quando. No-
vamente, uma classe deve encerrar todas as suas responsabilidades.

Suporte de ferramentas
Todas as ferramentas de UML permitem que você mostre uma classe com dois
compartimentos, pelo menos as ferramentas mais atuais. Assim é possível você uti-
lizar o estereótipo de <<entidade>> para essas classes. Assim, você pode criar um
modelo de classes (todas estereotipadas) para representar seu modelo de entidades
e relacionamentos.
Apesar disso ser possível, uma ferramenta própria para a modelagem de dados é
muito mais adequada. Uma ferramenta de modelagem de dados lhe permite a utili-
zação de scripts, tediosos de fazer sem o auxílio de uma ferramenta.

Conclusão
Vimos um resumo de teorias que precisariam de outro livro para serem explicadas
a fundo. Isso é um resumo, não se trata de querermos esgotar o assunto. A inten-
ção não era esta.
196 Desenvolvendo Software com UML 2.0 – Definitivo

A intenção era situar o diagrama de entidades e relacionamentos dentro de um


contexto prático no uso da UML. Quando Usar, Como Usar e Por Que Usar? Para
esses fins, creio que as poucas páginas anteriores foram suficientes. Contudo, inci-
to todos à pesquisa de vasto material que já existe a respeito.

Exercícios
1. Defina um banco de dados.
2. O que é uma entidade em um banco de dados?
3. Defina um Modelo Entidade Relacionamento?
4. Em quais fases do processo unificado está situada a confecção do MER – Modelo de
Entidade e Relacionamento?
5. Em que ‘momento’ da UML devemos começar a nos preocupar com o MER?
6. Quais as vantagens do uso de funções internas no banco de dados?
7. Classes são tabelas no banco de dados?
8. Como descobrimos as entidades diante de nossos modelos UML?
9. Defina chave primária e chave estrangeira.
10. Qual o modificador que deve ser utilizado em um atributo, em uma classe, que indi-
que um campo de uma tabela em um banco de dados?
11. Defina normalização.
Anúncio sério em jornal de grande circulação: Troco 286 com
monitor por um pacote de bolacha Maria. Volto diferença.
Alguns homens vêem as coisas como são, e dizem ‘Por quê?’ Eu
sonho com as coisas que nunca foram e digo ‘Por que não?’
GEORGE BERNARD SHAW

A UML define um diagrama de pacotes como um modelo que descreve como


os elementos são organizados dentro de pacotes e suas dependências. Esse
diagrama mostra, inclusive, pacotes importados e extensões de pacotes.
Um pacote pode estar contido em outros pacotes. Em um diagrama de pacotes, es-
tes são ligados por setas pontilhadas que têm seu estereótipo alterado de acordo
com a necessidade. É desta forma que podemos usar <<acessa>>, <<importa>> e isso
indica que a seta é uma dependência estereotipada, como já vimos no caso do dia-
grama de Casos de Uso. Você pode criar seus estereótipos.
Um pacote pode ter qualquer diagrama da UML, porém são mais comuns em dia-
gramas de Casos de Uso, para ajudar a abstração do domínio do problema, e em
classes, para ajudar na organização das classes construídas em sistemas médios e
grandes.
Dou um significado especial ao agrupar classes em pacotes, tendo em mente a ar-
quitetura de distribuição desses pacotes. Ou seja, dou o seguinte significado a um
pacote – ele será realmente um pacote em Java. Além de ser um pacote em Java, ele
será também um arquivo com extensão .jar, um módulo executável em Java.
198 Desenvolvendo Software com UML 2.0 – Definitivo

Se você não estiver usando Java, deve procurar uma forma de encapsular suas clas-
ses para dar um significado a seus pacotes, por exemplo, um arquivo com extensão
.dll é um conjunto de classes.

Quando iniciar a inclusão das classes em pacotes?


Quando termino a análise de um subsistema de Casos de Uso, sei que é um bom
momento para iniciar o empacotamento das classes. Módulo terminado, inicie o
empacotamento das classes. Para sistemas grandes, talvez seja necessário iniciar o
empacotamento por uma outra forma, talvez grandes áreas, ou talvez você tenha
optado por subdividir um grande módulo em outros pequenos. De qualquer for-
ma, o empacotamento deve ser feito sempre.

Como escolho as classes que pertencem a um pacote?


Inicio a separação em pacotes de classes que estejam em uma mesma árvore de he-
rança. Em seguida, penso nas classes que estejam em um mesmo jogo de agregação
ou composição e, por último, classes que estejam aparecendo em um mesmo dia-
grama de seqüência com muitas colaborações (alto acoplamento), faz todo sentido
estarem próximas.
Você terá um pacote utilitário. Este pacote contém classes sem afinidade direta
com o domínio do problema, porém são necessárias.
As classes estereotipadas, como interface gráfica, podem estar em pacotes que es-
pelhem seções de seu site Web. Essas classes não estarão em .dll ou .jar. Se você
tem dúvidas sobre isso, veja o capítulo sobre tecnologia, ele lhe será esclarecedor.

Existe o conceito de pacotes grandes ou pequenos?


A resposta é não. O tamanho dos seus pacotes, ou seja, a quantidade de classes que
estarão dentro deles, depende do domínio do problema com o qual você está tra-
balhando.

Criando o diagrama de pacotes


Iniciei a criação dos meus pacotes pela escolha de classes que encapsulassem o pro-
duto da minha aplicação, no caso os DVDs que servirão às locações.
Capítulo 11 Diagrama de Pacotes 199

Figura 11.1 Pacote das classes relacionadas a filmes.

Em seguida, pensei em um pacote que abrigasse as classes relativas a clientes.


200 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 11.2 Pacote relativo a classes que tratam de assuntos de clientes.

O próximo passo foi pensar em um pacote que abrigasse as classes relativas à in-
terface gráfica e uma classe acabou sendo enviada para um pacote utilitário e TEF.
Veja o resultado nas figuras seguintes.
Capítulo 11 Diagrama de Pacotes 201

Figura 11.3 Pacote referente a classes de interface gráfica.


202 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 11.4 Pacote utilitário.

Figura 11.5 Pacote de TEF.

Agora que as classes estão separadas em pacotes, podemos construir o diagrama


de pacotes, pensando em suas correlações. Inseri, na ferramenta, estereótipos que
representam acessar, ou seja, um relacionamento simples e outro de importação.
A interface gráfica acessa classes inseridas em pacotes. Pacotes usam classes de ou-
tros pacotes através de importação.
Veja o resultado da Figura 11.6.
Capítulo 11 Diagrama de Pacotes 203

Figura 11.6 Diagrama de pacotes para o software Locar DVDs no domínio de problema Locar.

Conclusão
Percebemos, neste capítulo, que um diagrama de pacotes é necessário. Necessário
em Casos de Uso porque ajuda a compreender o domínio do problema a ser traba-
lhado, facilitando a abstração. Também é necessário em classes, porque ajuda na
divisão das classes em assuntos afins (herança, agregação, composição ou alto
acoplamento, descobertos em diagramas de seqüência).
A decisão de como as classes devem ser divididas é importante e não deve ser to-
mada sem a consulta a outros elementos da equipe.
204 Desenvolvendo Software com UML 2.0 – Definitivo

Creio que todas as ferramentas de modelagem UML dão suporte à criação do dia-
grama de pacotes, se não der, você já sabe avaliar a importância deste diagrama
para a criação do seu software de forma adequada.

Exercícios
1. Em que momento você acredita que devemos iniciar a separação de classes em pacotes?
2. Por que devemos levar em consideração o conceito de acoplamento, quando criamos
pacotes?
3. Faz sentido nós termos pacotes físicos de classes estereotipadas, como, por exemplo,
classes que representam HTMLs?
4. Que tipo de visão o diagrama de pacotes de classes nos fornece?
5. As setas tracejadas, que significam dependências, têm sua semântica alterada no dia-
grama de pacotes?
6. Em quais momentos podemos utilizar o diagrama de pacotes na UML?
7. Faz sentido nós iniciarmos separações de pacotes pensando em servidores?
8. A distribuição de classes em pacotes pode afetar o diagrama de classes, alterando-o?
Explique.
9. Por que criar diagrama de pacotes?
10. Pacotes são representações lógicas de quais elementos físicos?
O poeta nunca vive, morre aos pedaços.
JOSÉ FÉLIX

O segredo é quebrar os problemas em pequenos pedaços


administráveis. Se você lidar com eles, termina antes de
saber disso.
ANÔNIMO

V amos apresentar os diagramas de componentes e implantação. Seguindo a


tônica dos diagramas anteriores, apresentaremos a notação e falaremos da
semântica desses diagramas.

A notação do diagrama de componentes


Este símbolo designa um componente. Um componente é qual-
quer arquivo que contenha uma parte necessária à consecução de
um software. Se um software necessita de uma página HTML
para ser executado, este arquivo é um componente. Vale a mesma
concepção para um arquivo com extensão .txt. Este conceito é
importante, porque é necessário evitarmos a crença de que algo é
um componente desde que seja um executável a exemplo de .exe,
.dll, .jar.
Neste panorama, você pode representar qualquer parte de seu sistema em um dia-
grama de componente.
206 Desenvolvendo Software com UML 2.0 – Definitivo

As notações já aprendidas de dependência e seus estereótipos, interface, associa-


ções e associações diretas, agregação, composição (mostrada entre componentes)
e classes podem ser utilizadas. Você pode querer representar seus componentes co-
municando-se, em cada parte de seu sistema, com suas interdependências, por
exemplo: componentes – classes – interfaces. Tudo isso é possível nesses diagramas.
Um componente expõe suas interfaces (métodos públicos) para o
mundo externo. Para representar isso é possível utilizar a notação de
uma interface e estereotipá-la como um componente. Isso facilita a
descrição das ações possíveis de se acessar neste componente.
É possível a representação das interfaces
públicas de um componente, conforme
mostrado na figura ao lado: uma linha sóli-
da ligada a um círculo, chamada de “piruli-
to”. Este tipo de representação é o mais
visto em literatura ligada à orientação a
objetos. Você pode representar quantos
métodos forem necessários para transmitir sua idéia. Para cada método, você de-
verá ter uma linha seguida de um círculo. A figura mostra apenas que o compo-
nente XPTO fornece ou expõe uma interface que tem o nome método A ().
Setas pontilhadas podem mostrar as relações de dependências entre um compo-
nente e outro.

A forma de representar uma interface esperada é


mostrada na figura ao lado: uma linha sólida liga-
da a uma meia-lua, chamada de Assembly Con-
nector. A figura ao lado mostra um componente
fornecendo duas interfaces e esperando duas outras.

A figura representa inter-


faces esperadas se encon-
trando com interfaces for-
necidas. Podemos interpre-
tar a meia-lua como a utili-
zação de uma determinada
interface externa por um
componente.
Um retângulo, apenas com o ícone de um componente no seu canto superior direi-
to, também pode ser usado. Isso é opcional, para representar um componente a
Capítulo 12 Diagrama de Componentes e Implantação 207

partir da UML 2.0. Devido ao fato de ser opcional, representei um com e outro
sem esse ícone.
Essa simbologia, mais simplificada, deu lugar à anterior, mostrada na primeira fi-
gura deste capítulo. Aquela notação ainda existe por razões de compatibilidade
com versões anteriores. Houve, então, o reconhecimento de que esses retângulos
pequenos para nada serviam.
Durante a execução deste livro, alguns aspectos da UML 2.0 ainda não eram su-
portados por ferramentas de modelagem UML.
Componentes complexos podem ser representados com classes, que o realizam, li-
gadas a um componente através de uma dependência.

A notação do diagrama de implantação


Um diagrama de implantação modela o inter-relacionamento entre recursos de in-
fra-estrutura, de rede ou artefatos de sistemas. Normalmente representamos servi-
dores neste diagrama. Estes recursos são chamados de nodes ou nós.
Cada nó é uma máquina física que encerra um ou vários componentes. Outros dispo-
sitivos podem ser representados com o estereótipo de <<dispositivo>> ou <<device>>.
A figura ao lado, mostra a representação de um nó de rede.
Um nó pode, também, representar uma aplicação ou softwa-
re; exemplo desta utilização é demonstrar um conjunto de ar-
quivos com extensão .dll sendo abrigados em um contêiner
de aplicações como o COM+ (um servidor de aplicação) ou
ainda um Enterprise Java Beans Container abrigando beans
feitos em JAVA. Para essa utilização basta um estereótipo que
identifique essa aplicação.
Caso necessite desta representação, mantenha o nó como significando um Server
com um estereótipo de <<dispositivo>> e dentro dele um outro nó com outro este-
reótipo, tipo <<COM+>> ou <<NetscapeApplicationServer>>, ou o que for.
Faz parte deste diagrama a possibilidade de usarmos absolutamente qualquer no-
tação que é usada no diagrama de componentes.

Quando usar o diagrama de componentes e o diagrama de


implantação?
A figura a seguir, fala por si. Restringi estes dois diagramas a este capítulo, porque
acredito ser óbvia a utilização desses dois diagramas de forma conjunta.
Desta forma, minha sugestão é de que você faça um diagrama de implantação para
cada nó.
208 Desenvolvendo Software com UML 2.0 – Definitivo

Dentro deste nó você deve inserir todos os componentes possíveis daquele nó.
Você pode quebrar este diagrama em subdiagramas.
Em seguida, você cria um único diagrama com as conexões desses vários nós, con-
forme mostrado na figura anterior. Mesmo que esses nós estejam em prédios, cida-
des, estados ou mesmo países diferentes.
Este diagrama, que mescla componentes
em seus nós e seus inter-relacionamentos,
deve ser discutido com profissionais de
rede. Essas pessoas são as mais indicadas
para auxiliarem a montagem desses diagra-
mas. Francamente, não creio que isso seja o
skill de desenvolvedores ou analista de sis-
temas. Estes, necessitarão fornecer informa-
ções sobre tamanhos de arquivos e quanti-
dade de RAM utilizada pela aplicação, assim
como sobre os pontos mais críticos ou com
maior volume de acesso. Fornecer essas in-
formações é responsabilidade de desenvol-
vedores e analistas de negócios.
Faz parte desta análise aspectos de segu-
rança ou necessidades de firewall e proto-
colos seguros como https e localização de
certificados para o funcionamento do soft-
ware. Talvez, dependendo do tamanho da
solução, essas informações estejam fora do
escopo do conhecimento de um analista de
negócio ou desenvolvedor.

O diagrama de componentes e implantação


A Figura 12.1 nos dá uma perspectiva das páginas de interface gráfica que se co-
municarão via protocolo http, utilizando um servidor Apache 2.0. É evidente a uti-
lização de PHP como interpretador de páginas, dado o estereótipo das páginas em
questão.
A Figura 12.2 mostra outra possibilidade de notação. Um nó apenas, com a rela-
ção de arquivos .jar que serão utilizados pela aplicação. Estes podem ser represen-
tados em um diagrama mais detalhado. Ferramentas permitem a criação de
subdiagramas a partir de um nó como este, descrito para um Servidor de Aplicação.
Capítulo 12 Diagrama de Componentes e Implantação 209

Figura 12.1 Diagrama de implantação de componentes de IG.

Figura 12.2 Diagrama de implantação de arquivos de aplicação.

A Figura 12.3 mostra a perspectiva de que tipo de servidor de banco de dados


atenderá a aplicação em questão.

Figura 12.3 Diagrama de implantação - Nó de banco de dados.


210 Desenvolvendo Software com UML 2.0 – Definitivo

A Figura 12.4 resume os diagramas de implantação das partes do software propos-


to. Cada um desses nós tem seu próprio diagrama de implantação mostrando seus
componentes internos e como estes se relacionam.

Figura 12.4 Diagrama de implantação.

Conclusão
Esse diagrama encerra o que considero uma necessidade para quem desenvolve
software utilizando UML. Todos os demais diagramas são opcionais [isto é minha
opinião não da UML, ok ?!?]. Veja do que você necessitará:

» Diagrama de Caso de Uso da Visão do negócio. Diagramas relacionados a Caso


de Uso que exploram a Visão de forma mais detalhada <<subsistemas>>, demons-
trando os módulos de um sistema, estes descritos devidamente em pacotes.
» Descrição da Visão e Descrição de Casos de Uso.
» Diagrama de classes, que leva a análise a um ponto mais próximo da codifica-
ção.
» Diagrama de seqüência que corrige erros, no diagrama de classes, e permite a so-
fisticação do diagrama de classes com a inclusão de classes relativas à interface
gráfica.
» Diagrama de estado, que mostra o comportamento de objetos e seus estados es-
pecíficos.
» Diagrama de pacotes das classes, informando a distribuição lógica dos pacotes.
» Modelo de entidades e relacionamentos, informando os detalhes pertinentes a
banco de dados.
» Interface gráfica, que acompanha o diagrama de seqüência.
» Diagrama de implantação que simula o software em funcionamento distribuído
em diversos nós de rede e utilizando todos os recursos e componentes necessári-
os para esse funcionamento.

Adicionalmente, se este conjunto for enviado a uma equipe de programação, esta


terá de ser capaz de codificar o software. Pelo menos é o que se espera! O ranking
dos Casos de Uso mostrarão a seqüência da programação e sua lógica, aliada aos
diagramas de seqüência.
Capítulo 12 Diagrama de Componentes e Implantação 211

Exercícios
1. O que é um componente?
2. Qual é a semântica da representação de um ‘pirulito’ em um componente?
3. Qual é o significado de um traço seguido de uma meia-lua e partindo de um componente?
4. O que é um nó?
5. O que representa um diagrama de componentes e qual sua importância na UML 2.0?
6. O que representa um diagrama de implantação e qual sua importância na UML 2.0?
7. Qual é o público mais indicado para a leitura de um diagrama de componentes e im-
plantação?
Amo a liberdade, por isso... Deixo as coisas que amo livres …
Se elas voltarem, é porque as conquistei, ...Se não voltarem, é
porque nunca as possuí.
JOHN LENNON

O valor das coisas não está no tempo que elas duram, mas na
intensidade com que acontecem.
Por isso, existem momentos inesquecíveis, coisas inexplicáveis e
pessoas incomparáveis.
FERNANDO PESSOA

O diagrama de objetos é uma instância do diagrama de classes. Cada classe


mostra seu objeto em um determinado ponto de tempo. A utilização deste
diagrama é uma opção. Dado a gama de trabalho, já mostrada nos capítulos ante-
riores, despender tempo na confecção deste diagrama é algo que precisa ser seria-
mente ponderado.

Notação e semântica do diagrama de objetos


A notação de um objeto, neste diagrama, segue a notação de um objeto já mostra-
da no diagrama de seqüência: um retângulo, a identificação do objeto seguida de
dois pontos e a identificação da classe a qual este objeto pertence. Também é possí-
vel a representação do objeto com dois compartimentos: um que o identifica e ou-
tro que informa seus atributos.
Capítulo 13 Diagrama de Objetos 213

As notações a seguir são válidas e dependem do uso que se queira dar a um objeto.

A primeira notação informa pouco, apenas a identificação de um objeto e sua clas-


se; a segunda informa menos ainda, apenas a classe. A terceira notação é preferida,
porque mostra os atributos de um objeto produto em um determinado momento.

Um objeto é uma instância de uma classe na memória. Traduza isso para: Um objeto
é a criação de um objeto do tipo da classe à qual ele pertence em um local da memória.

Os relacionamentos entre os objetos podem ser nomeados; se você precisar, use os


nomes dos métodos que alteram os valores dos atributos.
Uma nota, como em qualquer diagrama da UML, é permitida.

Quando criar um diagrama de objetos?


Um diagrama de objetos pode ser um momento de extrema complexidade de um
software. Aquele momento em que o pessoal da programação diz: “Ernani, não
conseguimos entender o resultado que será obtido neste diagrama de classe!” Bem,
nesse momento, podemos avaliar a necessidade de inserirmos dados no nosso ban-
co de dados (valores dos atributos das classes envolvidas naquele relacionamento),
desenharmos o diagrama e entregarmos para o pessoal.
Estes, através de debbugging, verificam se obtiveram os resultados desejados.
Alguns vão apelidar isso de “Teste de Mesa”. Bem, nada posso fazer... Um diagra-
ma de objetos mostra o comportamento de uma classe instanciada na memória (e,
portanto, com valores nos seus atributos). Alguns atributos são fruto de tabelas
em bancos de dados, portanto isso pode ser chamado de “Teste de Mesa”.

Suporte de ferramentas
Algumas ferramentas sequer citam o diagrama de objetos como possibilidade para
ser modelado. Alguns sugerem que, ao criá-lo e descoberta a necessidade, este deve
ser esmigalhado e lançado ao lixo. Deixo a decisão com o leitor.
214 Desenvolvendo Software com UML 2.0 – Definitivo

Caso precise de um diagrama de objetos e a ferramenta não fornecer suporte a ele,


utilize um editor de textos que dê suporte a desenhos e crie seu diagrama lá, ou
mesmo use um quadro branco.

Um exemplo do diagrama de objetos

Figura 13.1 Diagrama de objetos – exemplo.

A figura precedente mostra um diagrama de objetos para um momento de compra


em um site de e-commerce. Observamos o seguinte:
» Um cliente (apenas uma instância de cliente) faz uma seleção de produtos;
» Duas instâncias de produtos vão à memória (produto 1015 e 1016);
» Duas instâncias de preços de produtos vão à memória (1015 – R$ 150,00 e 1016
– R$ 172,00);
» Duas instâncias de item de nota vão à memória;
» Apenas uma instância de Nota Fiscal, com os dois produtos comprados, vai à
memória.
» Uma instância da relação de compras do cliente também vai à memória.
Capítulo 13 Diagrama de Objetos 215

Conclusão
Um diagrama de objetos mostra os objetos, em determinado momento na memó-
ria, com valores em seus atributos. Caso, na programação, obtivermos esses resul-
tados, tenho meu objetivo atingido. Se um relacionamento de classes precisa ser
melhorado, também será uma boa oportunidade de utilizar esse diagrama.
Um diagrama de objetos pode ser construído em qualquer momento da especifica-
ção ou construção de um software.

Exercícios
1. O que retrata um diagrama de objetos?
2. Por que, em objetos, não retratamos os métodos que suas classes possuem?
3. Para que serve um diagrama de objetos?
4. Cite momentos em que seria recomendada a criação de um diagrama de objetos.
Arte é comunicar aos outros nossa identidade íntima com eles.
BERNARDO SOARES

O demônio pode citar as Escrituras para justificar seus fins.


SHAKESPEARE

O diagrama de comunicação – colaboração é um dos diagramas de interação,


pois mostram a interação do usuário com o software em determinado ponto.
Doravante, vamos chamar este diagrama de comunicação para ficarmos de acordo
com a UML 2.0, pois, até a UML 1.5, este diagrama era chamado de colaboração.
Adicionalmente, o diagrama de comunicação mostra a interação entre as classes.
As classes colaboram enviando mensagens umas para as outras. Na verdade, são
objetos, instanciados na memória, que enviam mensagens uns para os outros. Ou
seja, o diagrama de comunicação mostra o fluxo das mensagens entre um objeto e
outro.
Esse diagrama mostra os objetos ligados por uma linha sólida, identificada por
uma mensagem e com números mostrando a seqüência em que essas mensagens
devem ser lidas, pensadas e codificadas.
Capítulo 14 Diagrama de Comunicação - Colaboração 217

Notação e semântica do diagrama de comunicação


A notação do diagrama de comunicação é muito simples. Use a notação de objetos
que você já conhece e, entre eles, coloque uma linha sólida. Esta linha representa
uma mensagem ou muitas mensagens existentes nesse relacionamento.
Não é necessário você representar uma linha sólida para cada mensagem, basta uma.
Relacione as mensagens existentes em uma colaboração, usando a notação de – Número
para a seqüência desta mensagem: Valor de Retorno := Nome do Método(Parâmetros).
Para cada mensagem, informe um número indicando a ordem em que estas mensa-
gens acontecem.

Quando criar um diagrama de comunicação?


Uma colaboração não precisa, necessariamente, ser representada em um diagrama
de comunicação. Você pode fazer isso em um diagrama de classes. Aliás, o diagra-
ma de classes pode ser um bom lugar para se descobrir o que merece um diagrama
de comunicação. Veja a próxima figura que mostra um trecho de classes que cola-
boram. Um círculo pontilhado representa a colaboração e esta é passível de um
diagrama de comunicação mais detalhado.
Veja que a representação inclui até um relacionamento de generalização e especia-
lização entre colaborações. Isso foi um exagero que desenhei apenas para mostrar
até aonde se pode chegar.
Pessoalmente, desde a UML 1.5, optei por utilizar o diagrama de seqüência, pois
este tinha e tem um significado mais esclarecedor para mim. Como já demonstrei,
um diagrama de seqüência me permite descobrir novas classes, classes a serem ex-
cluídas, assim como métodos.
Algumas pessoas têm mais facilidade de abstração nesse diagrama que outras, eu
deixo isso à escolha do freguês.

Figura 14.1 Trecho de colaboração acontecendo no diagrama de classes.


218 Desenvolvendo Software com UML 2.0 – Definitivo

Suporte de ferramentas
Algumas ferramentas não dão suporte ao diagrama de comunicação. Outras pre-
ferem deixar este diagrama e não usar o de seqüências. Algumas permitem a cons-
trução dos dois. Você deve verificar a documentação da ferramenta para o suporte
a este diagrama.

Um exemplo do diagrama de comunicação

Figura 14.2 Exemplo do diagrama de comunicação para o Caso de Uso Locar DVD.

Repare como o diagrama anterior tem uma grande semelhança com o diagrama de
seqüência para o Caso de Uso Locar DVD. Nosso cliente locador digita uma URL
(1) e lhe são retornados os grupos possíveis para pesquisa (2). O cliente, ao solici-
tar uma pesquisa (3), obtém uma lista como resultado (4).
Realmente, para este cenário esse diagrama nada acrescentou. Fiz o diagrama para
familiarizá-lo com a notação e a semântica dele.

Conclusão
Esse diagrama, comunicação, faz parte do jogo de diagramas chamados de intera-
ção. Esse diagrama era conhecido como de colaboração até a UML 1.5. A partir da
UML 2.0, ele passou a ser conhecido como de comunicação. Pode haver trechos
onde, em um diagrama de classes, uma colaboração pode ser representada a fim de
prover melhor esclarecimento.
A utilização desse diagrama é opcional e pode ser feita em qualquer momento da
modelagem. Creio que pode ser útil, em colaborações muito complexas, mas não
supre tão bem as finalidades de modelagem como o diagrama de seqüência. Se co-
locarmos, no diagrama de seqüência, a numeração das mensagens, o diagrama de
comunicação fica prejudicado no seu uso.
Capítulo 14 Diagrama de Comunicação - Colaboração 219

Exercícios
1. O diagrama de comunicação é considerado um diagrama de interação. Por quê?
2. Qual outro diagrama da UML atende as expectativas do diagrama de comunicação?
3. Cite situações em que podemos criar um diagrama de comunicação.
4. Como representamos a seqüência das mensagens no diagrama de comunicação?
5. Como o diagrama de comunicação era conhecido até a UML 1.5?
Existe um tempo certo para cada coisa, momento oportuno
para cada propósito debaixo do Sol: Tempo de nascer, tempo
de morrer; tempo de plantar, tempo de colher.
ECLESIASTES 3:1-2

Nunca penso no futuro, ele chega rápido demais.


ALBERT EINSTEIN

O Timing Diagram é mais um dos diagramas de interação, pois mostra a inte-


ração entre objetos em determinado ponto do tempo. Os diagramas de inte-
ração formam um trio de: seqüência, comunicação e Timing.
Esse tipo de diagrama já é bastante utilizado por engenheiros elétricos no uso de
demonstração do estado de máquinas digitais. Esse diagrama é utilizado por pes-
soas que pensam, por exemplo, em programação de máquinas de controle numéri-
co, na indústria, tipo CNC.
No caso da UML – este diagrama é novo na UML 2.0 – quando, na modelagem, a
proposta primária é mostrar a evolução no tempo ao longo de um eixo com suas
variações (alterações) e de forma linear. O foco da atenção se dá no tempo da
ocorrência dos eventos que causam as mudanças em estados. Resumindo, esse dia-
grama explora o comportamento de um ou mais objetos em dado período de tem-
po, mostrando suas alterações de estado.
Capítulo 15 Timing Diagram 221

Notação e semântica do Timing Diagram

Figura 15.1 Timing Diagram para o Caso de Uso Locar DVD.

As figuras 15.1 e 15.2 mostram as duas possibilidades de se construir um Timing


Diagram, usando a notação da UML 2.0. Existe a forma simples e a mais robusta,
mostrada na Figura 15.2.

Quando criar um Timing Diagram?


A documentação da UML 2.0 aconselha que pode ser mais cômodo (econômico e
compacto) representar a mudança de estado de um objeto em determinado perío-
do de tempo no formato mostrado na Figura 15.1.
Novamente aqui vale a preferência, caso se tenha mais facilidade de entendimento
sobre o que está acontecendo com determinado objeto durante um determinado
tempo, utilizando esse diagrama (em conjunto ou não ao diagrama de estado e/ou
seqüência), esse diagrama pode ser usado.

Suporte de ferramentas
Ao tempo em que escrevo estas linhas não existe ferramenta de UML oferecendo
suporte para esse diagrama e nos sites, referentes às principais ferramentas de
UML existentes, não vi nenhuma referência a planos futuros de implementar esse
diagrama.
Porém, isso não é impedimento para o uso. Você pode usar seu editor de texto ou
mesmo papel e lápis, para representar esse diagrama, caso necessite.
222 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 15.2 Forma mais robusta de Timing Diagram na UML 2.0.

Conclusão
O Timing Diagram é novo na UML 2.0. É considerado um diagrama de interação,
formando o quarteto com os diagramas de seqüência, comunicação e interação – vi-
são geral. É utilizado para mostrar a alteração do estado de determinado objeto, si-
tuação ou condição, chamada de “lifeline”. Existem duas formas de representá-lo,
conforme as figuras 15.1 e 15.2. Esse recurso pode ser utilizado em qualquer momen-
to da modelagem de um software. Seu uso não é comum, exceto em softwares que ne-
cessitam modelar aspectos de Engenharia Eletrônica, onde seu uso já é extensivo.

Exercícios
1. Por que o Timing Diagram é considerado um diagrama de interação?
2. De quantas formas podemos representar um Timing Diagram na UML 2.0?
3. Quando devemos criar um Timing Diagram e quais são suas utilidades?
Ensinar as pessoas sem lhes dar uma visão de um futuro
melhor, uma visão real, é apenas treinamento, não educação.
NIDO QUBEIN

Com visão, qualquer pessoa, organização ou nação florescerá.


A bíblia já nos diz: “Sem visão, perecemos”.
MARK VICTOR HANSEN

O diagrama de interação – Visão Geral é um diagrama que congrega uma de-


terminada visão que pode englobar vários diagramas. Os diagramas que po-
dem estar envolvidos são os diagramas de seqüência, comunicação e Timing. Este
diagrama é novo na UML 2.0. Muito eficaz em reuniões e demonstrações de situa-
ções complexas, devemos utilizá-lo de forma intensiva, pois não existe outro dia-
grama que nos dê uma visão tão completa dos passos que uma situação, classe ou
objeto possa passar. Francamente, eu penso que seria de bom proveito se pudésse-
mos incluir aqui o diagrama de atividades e também o de Casos de Uso, assim po-
deríamos apresentar uma evolução em sua thread do começo ao fim.

Notação e Semântica do Diagrama de Interação – Visão Geral


A notação para este diagrama é absolutamente qualquer notação utilizada no dia-
grama de atividades, mais as possibilidades a seguir.
224 Desenvolvendo Software com UML 2.0 – Definitivo

Esta notação mostra um retângulo e, dentro, uma etique-


ta que identifica o diagrama de interação – Visão Geral.
Este mesmo símbolo pode conter vários semelhantes, re-
presentando outros diagramas.
Dentro deste símbolo, qualquer notação, já mostrada
para o diagrama de atividades, pode ser utilizada.
A Figura 16.1 dá uma idéia da utilização para esse novo diagrama.
Verifique que o fato de estarem representados apenas três diagramas dentro do re-
tângulo do diagrama de interação não significa que existe um limite de diagramas
a serem demonstrados dentro do Frame.
Outra observação é a de que, não necessariamente, este diagrama mostra outros
diagramas inteiros. O diagrama ‘DS XPTO 3’ está apenas citado, fazendo parte de
uma determinada seqüência entre os diagramas.
As decisões ‘forks’, ‘joins’, ‘merge’, subatividades e outros símbolos devem ser docu-
mentados com um texto simples próximo dessas notações. Uma nota da UML
pode acompanhar esse diagrama para explicá-lo de forma melhor.

Quando criar um diagrama de interação – Visão Geral?


Este diagrama é necessário em casos em que as seqüências das interações se mos-
traram tão complexas que requisitam um resumo que possibilite uma visão geral
daquela interação.

Suporte de ferramentas
Ao tempo em que escrevo estas linhas, não existe ferramenta de UML oferecendo su-
porte para esse diagrama e nos sites, referentes às principais ferramentas de UML
existentes, não vi nenhuma referência a planos futuros de implementar esse diagrama.
Porém, isso não é impedimento para o uso. Você pode usar seu editor de texto ou
mesmo papel e lápis, para representar esse diagrama, caso necessite. Infelizmente,
se você escolher (na ferramenta) um diagrama de seqüência, e tentar usar símbolos
do diagrama de atividades, as ferramentas não vão permitir e vice-versa.

Conclusão
O Diagrama de interação – Visão Geral é um diagrama que congrega os outros
diagramas de interação (seqüência, comunicação e Timing). Serve para mostrar se-
qüências entre estes outros diagramas que se mostraram bastante complexas. To-
das as notações do diagrama de atividades são permitidas nesse diagrama. Pode-se
utilizar apenas um label referindo-se a um determinado diagrama de que reside
dentro do Frame principal.
Capítulo 16 Diagrama de Interação – Visão Geral 225

Figura 16.1 Diagrama de interação – Visão Geral.

Exercícios
1. O que é um diagrama de interação – Visão Geral na UML 2.0?
2. Cite situações em que podemos usar o diagrama de interação – Visão Geral dentro da
UML 2.0.
3. Existe algum limite, em números, para representarmos diagramas dentro do diagrama
de interação – Visão Geral?
4. As notações de: forks, joins e decisões entre os diagramas podem ser usadas no diagra-
ma de interação – Visão Geral, por quê?
5. Quando devemos criar um diagrama de interação – Visão Geral?
O que disse Deus depois de criar o homem?
R: Tenho que ser capaz de fazer coisa melhor!
O que disse Deus depois de criar a mulher?
R: A prática traz a perfeição.
FRASE FEMINISTA

Compor é criar um clima de mágica para tocar as pessoas.


MARINA LIMA

O Composite Structure Diagram é um diagrama que mostra uma colaboração


que existe entre instâncias de classes, objetos ou interfaces.
Se traduzíssemos este título de diagrama ao “pé da letra” obteríamos Diagrama de
Estrutura de um Compósito. Um compósito é um todo constituído de partes dis-
tintas que não perdem suas características em combinação com outras, sendo rela-
tivamente fácil sua identificação. Esse diagrama é novo na UML 2.0.

Notação e semântica do Composite Structure Diagram


Faz parte deste diagrama qualquer das notações já mostradas para classe, objeto
ou interface. Apenas para referência segue uma lembrança dessas notações:
Notação para classe. Apesar de ser permitida a participação de uma
classe em um diagrama deste tipo, creio que não é senso comum a uti-
lização de uma, já que colaboração implica em instância e uma ins-
tância de uma classe é um objeto. Poderia ser argumentado que os
Capítulo 17 Composite Structure Diagram 227

métodos (em sua maioria) são da classe e não de suas instâncias (objetos), porém o
diagrama permite o uso de linhas sólidas que podem representar mensagens sendo
enviadas de um objeto para outro.
Notação para um objeto. Apesar de a notação aqui representar apenas
o nome do objeto, creio que a melhor forma de representação para
este diagrama envolveria seus atributos e como eles se comportam na
colaboração.
Notação para interface. A participação de uma interface é compreen-
sível, já que uma interface não instancia objetos na memória; apenas
apresenta os métodos que serão implementados por uma classe. Basta
representarmos a interface que quem sabe ler UML interpretará que
uma classe implementará os métodos dessa interface.
Uma colaboração local onde qualquer retângulo – classe, objeto ou
interface – trocam mensagens. A UML 2.0 prevê que uma ocorrên-
cia de uma colaboração também pode ser usada. Uma ocorrência
de colaboração é o padrão que uma colaboração apresenta para
uma situação envolvendo determinados objetos. Nesse caso, a ocorrência recebe
um nome, seguido de dois pontos e o nome da colaboração – Nome da Ocorrên-
cia:Nome da Colaboração.
Adicionalmente, linhas sólidas interligam as partes interessadas na colaboração.
Estas linhas sólidas podem receber os nomes das mensagens que representam ou os
nomes dos objetos que interagem com a colaboração.
Em um mesmo diagrama desse tipo podem aparecer todos os tipos de retângulos
apresentados, o que for necessário para a clareza do diagrama.

Quando criar um Composite Structure Diagram?


Esta pergunta é feita por alunos que necessitam, na verdade, resolver outra per-
gunta: “Quais diagramas devo usar?” Bem, como outros já citados, esse diagrama
é opcional. Se todas as suas colaborações necessitarem de um diagrama desse tipo,
algo está errado com o conceito de UML que você tem.
De novo, a regra é: Algo está muito complicado? A programação não consegue re-
solver uma determinada situação? Explicar em português claro e alto a situação
apresentada não adiantou? Então, você já respondeu a pergunta – faça o diagrama!

Suporte de ferramentas
Enquanto escrevo este texto, as principais ferramentas ainda não estão implemen-
tando esse diagrama. Mesmo permitindo que colaborações sejam representadas
entre classes e interfaces, é preciso que isso se expanda para objetos.
228 Desenvolvendo Software com UML 2.0 – Definitivo

Figura 17.1 Composite Structure Diagram.

Figura 17.2 Outra possibilidade de representação do Composite Structure Diagram.

Conclusão
O Composite Structure Diagram representa um momento de colaboração entre in-
terfaces, objetos ou classes. Deve ser utilizado em momentos em que suas colabo-
rações mais importantes – a parte crítica de seu software – apresente uma
necessidade de melhor explicitação de suas conexões.
As duas figuras anteriores representando esse diagrama, mostradas neste capítulo,
não encerram suas possibilidades. A UML 2.0 permite a conexão entre colabora-
Capítulo 17 Composite Structure Diagram 229

ções, imagine duas colaborações, do tipo mostrado na Figura 14.1, interconecta-


das para representar uma conseqüência de uma dessas colaborações.

Exercícios
1. O que é o Composite Structure Diagram?
2. Qual a diferença entre o diagrama de comunicação e o Composite Structure Diagram?
3. Qual a notação para uma colaboração dentro do Composite Structure Diagram?
4. Como é a identificação de uma colaboração no Composite Structure Diagram?
5. Qual o significado das linhas sólidas entre os elementos do Composite Structure Dia-
gram?
6. Quando devemos pensar em criar um Composite Structure Diagram?
Não tenho 80 anos, e sim quatro vezes 20.
DANIEL AUBER

A verdade é a melhor camuflagem. Ninguém acredita nela.


MAX FRISCH

A lunos sempre me questionam sobre formas de medir o tempo e o esforço que


um software vai consumir. Quando inicio a minha resposta informando que
não há uma fórmula a se aprender, que possa ser usada imediatamente em produ-
ção, as reclamações saem de lá do fundo da sala em direção do meu peito, como se
eu tivesse enganado alguém.
Olhem, isso É VERDADE!
Eu não poderia mentir a vocês e informar que temos uma capacidade precisa de in-
formar o tempo que um software consumirá para ser feito. Iniciamos o livro, lá no
Capítulo 1, discorrendo que a tecnologia da informação, especialmente a Enge-
nharia de Software, ainda não é uma ciência com padrões tão universais e senso
comum que não deixe dúvidas de como fazer as coisas. Pois bem, nada mudou en-
tre o Capítulo 1 e este, a não ser a numeração dos capítulos!

Existe uma sugestão de estimativas?


Não há melhor forma, em minha opinião, de se medir o consumo de tempo e esfor-
ço, que um software produzirá, do que uma avaliação feita com base nos Casos de
Uso. Apesar da minha opinião, existem várias formas para medir esforço. Uma
Capítulo 18 Métrica de Casos de Uso 231

medida considerada física, por exemplo, é o Número de Linhas de Código. Esta é


uma medida que pode ter valor depois que o software for terminado.
Medir o tamanho provável de um software, baseado em suas funcionalidades, pas-
sou a ser requisitado para se efetivar previsões antes do início do software. Por essa
razão, esse tipo de medida passou a ser classificada como funcional.
Allan Abrecht, em 1979, propôs uma forma de medida funcional que foi muito
utilizada, mas questionada para softwares orientados a objetos, a Ponto Função.
Uma norma ISO, normaliza este método: ISO/IEC 20926. Outras começaram a
surgir.1
Para se utilizar a técnica de Pontos de Função com Casos de Uso, precisamos saber
como é o estilo adotado pela empresa e também precisamos conhecer a técnica de
análise de ponto função.
Gustav Karner, que trabalhava na empresa Objectory AB (de onde provinha Ivar
Jacobson), pensou em um formato de métrica que poderia responder a estas per-
guntas de consumo. Essa medida era uma extensão do método de Abrecht.
A esse método ele deu o nome de Pontos de Caso de Uso; vamos chamá-lo neste
texto de PCU. Karner iniciou esse processo em 19932 e sofreu influências do tradi-
cional método de pontos de função. Karner não foi o único a pensar esta forma de
estimativa, então é provável que você encontre literatura e sites Web dando notícia
de outros autores com similaridade, porém, com significativas diferenças entre
seus métodos e o de Karner.
Veja que é necessário que a empresa tenha um único formato para escrever Casos
de Uso e que todos obedeçam ao documento Nomenclatura, para iniciar a descrição
deles.
Outras formas de métricas, como número de linhas de código, não creio que se
apliquem a um software, pensado em termos de orientação a objetos, pois a rele-
vância aqui são os objetos e não o número de linhas de uma função!
Apesar disso, alguns advogam a pertinência de se mesclar vários métodos a fim de
se obter um resultado mais preciso e de forma mais rápida. Desconfio da necessi-
dade da rapidez quando se fala em estimativas.
Outros, propõem um formato especial, veja como exemplo a indicação que sugere
Martin Fowler e Kendall Scott:3
“Agora, você pode calcular com que rapidez pode prosseguir, o que chamo de veloci-
dade do projeto. Isso é o quanto de desenvolvimento você pode fazer em uma itera-
ção. Você calcula isso tomando o seu número de desenvolvedores, multiplicando pela
duração da iteração e, então, dividindo o resultado pelo coeficiente de carga. Por
exemplo, dados 8 desenvolvedores, uma iteração de 3 semanas de duração, e um coe-
ficiente de carga de 2; você terá um ideal de 12 semanas de desenvolvimento (8*3*1/2)
de trabalho por iteração”.
232 Desenvolvendo Software com UML 2.0 – Definitivo

“Some o tempo para todos os casos de uso, divida-o pelo trabalho por iteração e acres-
cente um para sorte. O resultado é a sua primeira estimativa de quantas iterações você
necessitará para o seu projeto.”
Quando Fowler brinca, pedindo que você acrescente um para sorte, não está fora
da realidade, já que informei o porquê de as estimativas em software serem uma
caixinha de surpresas.

Por que tanta incerteza nas estimativas de software?


Veja que, se algo é uma estimativa, seu nome já indica que existe ali incerteza. O
que faz os responsáveis perguntarem: “Quanto tempo isso vai levar?” e ficarem
possessos, é o tamanho da diferença entre a realidade e o que foi estimado.
Em outras ciências, essas incertezas são menores e mais controladas que na Enge-
nharia de Software e vários fatores colaboram para isso. Estão nesta categoria:

» equipe de desenvolvimento que não consegue trabalhar em conjunto;


» equipe de análise que não consegue se entender;
» falta de liderança eficaz;
» pobreza nas descrições de Casos de Uso;
» irresponsabilidade em procurar atingir metas impossíveis; e
» falta de conhecimento sobre o comportamento dos requisitos e suas alterações.
Geralmente, isso ocorre com quem não se preocupou em gerenciar os requisitos.
Outros fatores podem participar desta fila de forma pertinente, mas creio que, se
você chegou até aqui no livro, deve ter uma boa idéia deles.

O que pode reduzir a incerteza no método de Karner?


Histórico e gerenciamento. Duas palavras resumem o necessário para reduzirmos
as incertezas no método de cálculo de esforço proposto por Karner.
Durante todo o livro, eu aconselhei que você deve documentar seus passos ao lon-
go do Processo Iterativo Unificado usando a UML. Utilizando, de preferência, a
própria intranet da empresa. Também, incentivei a análise post-mortem de cada
iteração do processo. Estudo mais detalhado, falando do processo iterativo unifi-
cado, também foi sugerido.
Todas essas ações somadas ao gerenciamento de requisitos irão reduzir as incerte-
zas provocadas por qualquer método, mas a experiência adquirida ao longo de
seus primeiros softwares é fundamental.
Veremos que Karner propõe que valorize fatores, e estes são absolutamente dife-
rentes em cada empresa. Pode levar algum tempo até você chegar aos valores cor-
retos de sua empresa.
Capítulo 18 Métrica de Casos de Uso 233

Em geral, os passos que recomendo são simples: abra uma planilha de cálculo e ini-
cie sua estimativa. No primeiro software, não leve essa estimativa para seus superio-
res ou reuniões de projeto até o software terminar.
Quando este terminar, construa outra planilha que represente a realidade, observe
fator por fator, ajustando os valores na nova planilha, até que os resultados se
aproximem da realidade obtida e os fatores sejam o mais próximo que você conhe-
ce de sua empresa.
No próximo software, use o mesmo método de Karner e refaça os cálculos no final,
seguindo a sugestão do parágrafo anterior. Verifique que sua primeira estimativa
terá um nível de erro de 80% e, a partir da segunda tentativa, seu nível de acerto
tende a crescer cerca de 30%. Existe um ponto que você não conseguirá ultrapas-
sar: seu nível de acerto chegará próximo de 90%; daí em diante suas estimativas
passarão a crescer pouco. Ou seja, em um você atingirá 92,38% de acerto, no pró-
ximo chegará a 94,78% – um aumento quase insignificante –, porém não alcança-
rá os 100% desejados!
Evidentemente, e de novo, isso é uma estimativa! Por mais que você altere os fato-
res, não será possível chegar à sua promoção usando métrica de esforço baseada
em Casos de Uso.
Diante da margem de erro, promovida pela incerteza, acrescente os pontos percen-
tuais necessários que tornam suas estimativas mais precisas.
Esse processo, pode ser feito durante o pré-projeto que sugeri no Capítulo 1. Lem-
bra-se do tempo que pode levar de uma a duas semanas?
Quando chegar nesse ponto de estimativa de esforço por Casos de Uso, gerando
relatórios mais precisos, relaxe!
Não se estresse com variantes que vão continuar a acontecer. Pessoas vão continu-
ar a deixar o projeto no começo, no meio e no fim; por mais que jurem que jamais
vão lhe deixar sozinho em um momento como esse. A empresa continuará a ter
problemas políticos e financeiros que podem até abortar um projeto inteiro. Ge-
rentes e/ou diretores podem ser trocados, o que pode levar a mudanças significati-
vas no comportamento das necessidades de uma empresa!
Por causa desses fatores, você pode nunca conseguir passar dos 80% de acerto e o
problema não estará em você. Existem empresas cujo turnover alto sempre foi
uma característica, e isso nunca foi considerado algo negativo pela alta direção.

Como funciona o método de Pontos de Caso de Uso de


Karner?
Siga os passos sugeridos a seguir:
1. O primeiro passo é relacionarmos os atores que participam do modelo de Ca-
sos de Uso.
234 Desenvolvendo Software com UML 2.0 – Definitivo

2. Categorize cada ator em níveis de complexidade, estes podem ser um dentre


os seguintes: simples, médio e complexo. Considere como simples um ator
que não esteja envolvido em regras de negócios complexas e com muito pou-
cas entidades de banco de dados envolvidas em seus processos. Semelhante-
mente, considere um ator na categoria complexo se regras complexas estão
envolvidas em suas interações e muitas entidades do MER estão presentes.
Não há regra para isso – tudo é baseado em experiências do passado.
3. Calcule o TPNAA (Total de Pesos Não Ajustados dos Atores), você faz isso
contando o número de atores em cada categoria. Em seguida, multiplique
cada total pelo fator de peso (1, 2, 3) elegido para cada grupo. Adicione os va-
lores que agora são TPNAA.
4. Depois categorize os Casos de Uso em simples, médios e complexos. Você faz
essa categorização pelo número de fluxos e transações (incluindo-se aí os ce-
nários alternativos) pelos quais um Caso de Uso passa. Se existe simples en-
trada de dados, baseada em uma entidade e sem regras de negócio complexas,
este Caso de Uso está na categoria simples; o oposto aplica-se à categoria
complexa. Outras duas formas de categorizar Casos de Uso é por meio de seu
número de classes ou interações que ocorrem entre seus objetos nos diagra-
mas de seqüência. Esta última forma é mais consistente, visto que, quanto
mais complexo é um Caso de Uso, maior número de interações existe no dia-
grama de seqüência relativo a ele.
5. Conte o número de Casos de Uso que existem em cada categoria.
6. Multiplique o número obtido no tópico anterior pelos fatores adotados para
cada categoria. Some os valores encontrados – este número é TPNAUC (To-
tal de Pesos Não Ajustados dos Casos de Uso).
7. Some os pontos dos Casos de Usos não ajustados com os descobertos nos
pontos não ajustados dos Atores, isso resultará em PTNA (Pontos Totais Não
Ajustados):
a. PTNA = TPNAA + TPNAUC
8. Ajuste os pontos encontrados nos Casos de Uso, baseando-se em fatores am-
bientais e técnicos.
9. Existem oito Fatores de Complexidade Ambiental (FCA), quais sejam:
a. Familiaridade com o Processo Iterativo Unificado;
b. Experiência na aplicação;
c. Experiência em orientação a objetos;
d. Capacidade de liderança de análise;
e. Motivação;
f. Estabilidade de requisitos;
g. Consultores Part-Time;
h. Dificuldade de programação na linguagem;
Capítulo 18 Métrica de Casos de Uso 235

10. Existem 13 Fatores de Complexidade Técnicos (FCT), quais sejam:


a. Distribuição do sistema;
b. Resposta aos objetivos de desempenho;
c. Eficiência do usuário final;
d. Complexidade do Processo Interno;
e. Código deve ser reutilizado;
f. Facilidade de instalação;
g. Facilidade de uso;
h. Portabilidade;
i. Facilidade de alterar;
j. Concorrência;
k. Features de segurança;
l. Acesso direto a dispositivos de parceiros;
m. Treinamento especial aos usuários.
11. A cada fator é assinalado um valor entre 0 (zero) e 5 (cinco), dependendo do
seu reflexo no projeto. Você pode considerar estes valores como:
a. 0 = Não está presente ou não é influente;
b. 1 = Insignificante influência;
c. 2 = Influência moderada;
d. 3 = Influência média;
e. 4 = Influência significativa;
f. 5 = Influência significativa através de todo o processo.
12. Esses cálculos resultarão em três diferentes resultados:
a. Fator de Complexidade Técnica (FCT)
FCT = 0.6 + (.01 * Tfator)
b. Fator de Complexidade Ambiental (FCA)
FCA = 1.4 + (-0.03 * Efator)
13. Calcule os Pontos dos Casos de Uso (PTUC) multiplicando os Pontos Totais
Não Ajustados (PTNA) por Fator de Complexidade Técnica (FCT) por Fator
de Complexidade Ambiental (FCA):
a. PTUC = PTNA * FCT * FCA
14. Multiplique o número de pontos encontrados pelo número de homens\hora por
ponto – existe uma sugestão de Karner de usarmos 20 homens\hora por pontos,
mas podemos manipular isso. Esse cálculo nos dará o número de horas que
serão gastas na construção da solução:
a. homens\hora = PTUC * 20.
Vamos a um exemplo que pode aclarar este tópico.

Um exemplo de cálculo de esforço baseado em Pontos de


Caso de Uso de Karner
Segue um exemplo (apenas um exemplo!) para o uso da técnica, com apenas três
atores e três Casos de Uso:
236 Desenvolvendo Software com UML 2.0 – Definitivo

Passo 1 – Relacionar os atores e dar-lhes peso


Vamos relacionar os atores disponíveis nos Casos de Uso: Locar DVD, Cadastrar
Cliente Locador, Cadastrar Cliente Beneficiário de Cliente Locador e atribuir um
peso a estes casos de uso, seguindo a expectativa de 1:(simples), 2:(médio) e
3:(complexo).

Atores Peso
Cliente Locador 3
Cliente Beneficiário 3
Site 2

Considerei os atores cliente locador e cliente beneficiário com pesos máximos por
achar que estes envolvem várias entidades em banco de dados; suas regras de negó-
cios pedem mais cuidado. Além disso, várias interações humanas são pedidas em
seus Casos de Uso. Já o ator site é um sistema interno, trabalha com várias tabelas
de bancos de dados, porém depende de envolvimento puro do sistema em si; suas
ações não acontecem por pedido de alguém e sim por conseqüência da interação
com alguém, então o classifiquei de complexidade média.

Passo 2 – Calcular o Total de Pesos Não Ajustados dos Atores


(TPNAA)
Para fazermos isso, precisamos contar quantos atores existem em cada categoria.
Efetivamos a multiplicação desta soma pelos pesos e somamos os produtos achados.

Complexidade Qtd. de Atores Peso Resultado


1 0 1 0
2 1 2 2
3 2 3 6
Total de Pesos não Ajustados dos Atores (TPNAA) = 8

Passo 3 – Relacionar os Casos de Uso e dar-lhes peso


Precisamos relacionar os Casos de Uso em simples, médios e complexos; veja algu-
mas dicas já citadas anteriormente.

Casos de Uso Peso


Locar DVD 2
Cadastrar Cliente Locador 3
Cadastrar Cliente Beneficiário de Cliente Locador 3
Capítulo 18 Métrica de Casos de Uso 237

Considerei o Caso de Uso Locar DVD como único de média complexidade, pois o
número de transações não é tão grande quanto o dos Casos de Uso que tratam de
cadastramento.

Passo 4 – Calcular o Total de Pesos Não Ajustados dos Casos de


Uso (TPNAUC)
Complexidade Qtd. de Casos de Uso Peso Resultado
1 0 1 0
2 1 2 2
3 2 3 6
Total de Pesos Não Ajustados dos Casos de Uso (TPNAUC) = 8

O fato de termos os mesmos valores, não ajustados, para atores e Casos de Uso é
refletido pelo reduzido número de ambos neste exemplo.

Passo 5 – Calcular os Pontos Totais Não Ajustados (PTNA)


Este cálculo é obtido pela soma PTNA = TPNAA + TPNAUC.
PTNA = 8 + 8;
PTNA = 16.

Passo 6 – Criar a tabela de Fatores de Complexidade Ambiental


(FCA)

Fator Descrição Peso Valor EFator


F1 Familiaridade com o Processo Iterativo 1.5 4 6
Unificado
F2 Experiência na Aplicação 0.5 3 1.5
F3 Experiência em orientação a objetos 1 4 4
F4 Capacidade de Liderança de Análise 0.5 4 2
F5 Motivação 1 3 3
F6 Estabilidade de Requisitos 2 4 8
F7 Consultores Part-Time -1 0 0
F8 Dificuldade de Programação na -1 3 -3
Linguagem
Total (Efator) = 21,5
FCA=> 1.4 + (-0.03 * 21.5) = 0.755
238 Desenvolvendo Software com UML 2.0 – Definitivo

Passo 7 – Criar a tabela de Fatores de Complexidade Técnica (FCT)


Fator Descrição Peso Valor Tfator
T1 Distribuição do sistema 2 5 10
T2 Resposta aos objetivos de desempenho 1 4 4
T3 Eficiência do usuário final 1 2 2
T4 Complexidade do Processo Interno 1 4 4
T5 Código deve ser reutilizado 1 2 2
T6 Facilidade de instalação 0.5 5 2.5
T7 Facilidade de uso 0.5 3 1.5
T8 Portabilidade 2 3 6
T9 Facilidade de alterar 1 3 3
T10 Concorrência 1 2 2
T11 Features de segurança 1 2 2
T12 Acesso direto a dispositivos de parceiros 1 5 5
T13 Treinamento especial aos usuários 1 3 3
Total (Tfator) = 47
FCT => 0.6 + (.01 * 47)= 1.07

Em cada uma dessas tabelas, o que podemos alterar, para refletir o software em
questão, são os valores atribuídos a cada fator. Isso dependerá do histórico de
cada software; uma coisa muito relevante obterá um valor alto, o inverso valendo
para coisas não relevantes, que podem inclusive ter valoração zero. Esses valores
vão de 0 (zero) até 5 (cinco). Vamos relembrar que:
a. 0 = Não está presente ou não é influente;
b. 1 = Insignificante influência;
c. 2 = Influência moderada;
d. 3 = Influência média;
e. 4 = Influência significativa;
f. 5 = Influência significativa através de todo o processo.

Passo 8 – Calcular os Pontos Totais de Caso de Uso


Este passo requer a fórmula: PTUC = PTNA * FCT * FCA, vamos aplicá-la:
PTUC = 16 * 1.07 * 0.755.
PTUC = 12.9256.

Passo 9 – Efetivar estimativas com os pontos obtidos


Sugestão de Karner = 12.9256 * 20 = 258.512
Capítulo 18 Métrica de Casos de Uso 239

1ª Suposição = 7 homens/horas trabalhadas por ponto = 12.9256 * 7 = 90.4792 ou


90 horas.
2ª Suposição = 8 homens/horas trabalhadas por ponto = 12.9256 * 8 = 103.4048 ou
100 horas.
Outras...

Conclusão
Ao utilizar-se o método de Karner, pesquise outros colegas. Pesquise variações que
estão sendo utilizadas com origem no método de Karner.
Lembre-se: por melhor que seja o método, tudo dependerá do histórico. Sem um
histórico, será prematuro você iniciar a distribuição de estimativas de software.
Considerando que nós não temos histórico, nossos valores para os pesos dos fato-
res são meramente estimados. Considerando que estamos com três Casos de Uso,
para os realizarmos, desde a interface gráfica até as entidades do banco de dados,
teremos um esforço humano de cerca de 90 homens/horas (que pode chegar a até 100
homens/horas); estou desconsiderando a sugestão de Karner para 20 homens\hora por
ponto, que, se divididas em dois blocos, ‘interface gráfica’ e programação, nós tere-
mos o trabalho feito entre uma ou duas semanas se considerarmos apenas dois pro-
fissionais.
Quando falo desde a interface gráfica até o banco de dados, quero dizer:
1. Diagrama de Casos de Uso terminados.
2. Casos de Uso bem escritos, normalizados.
3. Casos de Uso aprovados.
4. Diagrama de classes pronto.
5. Diagrama de seqüência pronto.
6. Interface gráfica construída.
7. Interface gráfica aprovada.
8. Diagrama de estado pronto.
9. Diagrama de classes validado.
10. Diagrama de entidade – relacionamento pronto.
11. Diagrama de entidade – relacionamento validado.
12. Codificação e compilação na linguagem esperada.
13. Codificação em HTML, JavaScript e XML terminados.
14. Documentação terminada e publicada na intranet da empresa.
15. Testes de aderência terminados.
16. Testes de validações e dados terminados.
17. Homologação com cliente final terminada e assinada.
18. Fase de transição terminada.
240 Desenvolvendo Software com UML 2.0 – Definitivo

Agora eu creio que pode existir alguém na platéia dizendo: “Nossa, mas duas pes-
soas em 100 horas, ou 1 semana e ½ de trabalho para duas pessoas, é muito pouco
para fazer tudo isso!!!!”
Talvez a estimativa de Karner não esteja tão longe da realidade que nos cerca, não é?
A estimativa de Karner prevê o dobro do que propus. Eu explico porque falo isso
somente agora: é que, com freqüência, alunos me questionam que, para apenas
três Casos de Uso em pequenas telas de cadastramento, a estimativa está exagera-
da e que eles levam no máximo dois dias para fazer o trabalho.
Porém, reparo que, com freqüência, esses alunos estão falando unicamente da par-
te de programação pura, ou seja, apenas os itens: 6, 12, 13, 16 e 17. Em 18 itens,
apenas cinco são costumeiramente apreciados.
Os valores, dos fatores, são fáceis de utilizarmos conforme a sugestão, mas e os pe-
sos, tanto técnicos como ambientais, de onde surgiram?
Os pesos dos fatores surgiram a partir de estudos que Albrecht fez na IBM e este os
justificou como sendo valores relativos de uma determinada função para o usuá-
rio/cliente em questão; debate e teste ajudaram nessa determinação. Isso aconteceu
quando do desenvolvimento da técnica de Pontos de Função.
Alguns poderiam argumentar que se os pesos foram dirigidos à cultura da IBM,
por que não questioná-los?
Minha resposta continua tendo o mesmo formato de como iniciei o capítulo: his-
tórico e gerenciamento. Somente essas duas variáveis podem determinar que os pe-
sos de cada fator estão corretos para sua empresa.
Considere os valores de cada fator em cada software, por menor que seja este
software. Procure ajustar os valores até chegar a níveis próximos da realidade.
Cerca de 90% indicará que você está no caminho certo. Veja que um determinado
valor não deve ser alterado somente porque você deseja chegar a níveis ótimos de
estimativa; aquilo deve fazer sentido!
Se, alterando valores, mesmo assim você não conseguir chegar a números razoáve-
is, comece a pensar na possibilidade de os pesos avaliados para a IBM não serem
bons para a sua empresa. Mexa somente onde o tiro for certo. Avalie, então, os re-
sultados!
Algo positivo é o fato de termos, ao menos, um processo formal que reflete o nosso
desejo de estimar o consumo humano no software. Este método não oferece tanta
complexidade quanto o Ponto de Função e pode ser automatizado em uma plani-
lha de cálculo.
Mais do que nunca, o estilo da escrita para Casos de Uso já abordado nos Capítulos
3 e 4 deve ser o mesmo, não importando o analista de negócios que o tenha escrito.
O documento “Superstructure” da OMG sugere alguns estereótipos padrões.
Na tabela a seguir estão relacionados apenas alguns, os mais utilizados.
Veja no capítulo em que tratamos de Teoria de Classes o tópico “Estereótipos”,
para maiores detalhes.

Estereótipo Aplica-se a Descrição


<<auxiliar>> Classe Uma classe que suporta outra mais fundamental ou
central, geralmente implementando uma lógica
secundária.
<<deriva>> Abstração Especifica um relacionamento de derivação entre
elementos que são usualmente, mas não
necessariamente, do mesmo tipo.
<<framework>> Pacote Especifica que o modelo contém elementos os quais
determinam uma arquitetura reutilizável para parte ou
o todo do sistema.
<<implementa>> Componente Especifica um componente que não tenciona ter uma
especificação dele próprio, em vez disso, ele é uma
implementação para uma <<especificação>> separada
para a qual ele tem uma dependência.
<<instancia>> Uso Geral Indica que existe uma dependência entre dois
elementos e que o cliente cria instâncias de quem
fornece a dependência.
<<responsabilidade>> Uso Geral Indica que um elemento tem responsabilidades ou
obrigações para com outros elementos.
<<script>> Uso Geral Qualquer arquivo de script.
242 Desenvolvendo Software com UML 2.0 – Definitivo

(Continuação)
Estereótipo Aplica-se a Descrição
<<utilitário>> Classe Uma classe que não tem instâncias, mas fornece
diversas operações para serem usadas por outras
classes. Estas funções são de uso genérico.
<<documento>> Artefato Um arquivo genérico que não é um arquivo <fonte> ou
<<executável>>.
<<entidade>> Classe Designa um arquivo que realizará uma persistência de
dados.
<<executável>> Artefato Um arquivo de programa que pode ser executado em
um sistema de computador.
<<arquivo>> Artefato Um arquivo físico que contém o sistema desenvolvido.
<<biblioteca>> Artefato Uma biblioteca estática ou dinâmica.
<<processo>> Componente Um componente baseado em transação.
<<realização>> Classificador Utilizado para designar quando um objeto define a
implementação física de outro objeto.
<<fonte>> Artefato Um arquivo fonte que pode ser compilado em um
<<executável>>.
<<subsistema>> Caso de Uso, Uma unidade hierárquica decomposta de médios e
Classe, grandes sistemas de computador.
Componente
<<estende>> Caso de Uso Indica que um Caso de Uso estende a funcionalidade
de outro em determinado ponto de extensão.
<<include>> Caso de Uso Indica que um Caso de Uso inclui a funcionalidade de
outro em determinado ponto.

Elementos existentes na UML 1.X e que foram retirados na UML 2.0.

Standard Element Name Applies to Base Element


«access» Permission
«appliedProfile» Package
«association» AssociationEnd
«copy» Flow
«create» CallEvent
«create» Usage
«destroy» CallEvent
«facade» Package
«friend» Permission
«invariant» Constraint
«local» AssociationEnd
Apêndice A 243

(Continuação)

Standard Element Name Applies to Base Element


«parameter» AssociationEnd
«postcondition» Constraint
«powertype» Class
«precondition» Constraint
«profile» Package
«realize» Abstraction
«requirement» Comment
Prefácio
1. PAGE-JONES, Meilir. Fundamentos do desenho orientado a objeto com UML. São
Paulo: Makron Books, 2001.
2. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software deve-
lopment process. Indianápolis: Addison Wesley, 1999.
3. SCOTT, Kendal. O processo unificado explicado. Porto Alegre: Bookman, 2003.
4. http://www.sei.cmu.edu/cmm/

Capítulo 1
1. GILB, Tom; SUSANNAH, F. Principles of software engineering management. Wokingham,
England: Addison Wesley, 1988, p. 73.
2. FOWLER, Martin; SCOTT, Kendall. UML essencial. 2. ed. Porto Alegre: Bookman,
2000.
3. JACOBSON, Ivar; CHRISTERSON, Magnus; JONSSON, Patrick; OVERGAARD,
Gunnar. Object-oriented software engineering: a Use Case driven approach. New Jersey:
Addison Wesley, 1992.
4. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software deve-
lopment process. Indianápolis: Addison Wesley, 1999.
5. JONES, Caper. Patterns of software systems failure and success. London: Internatio-
nal Thompson Computer Press, 1996.
6. http://www.sei.cmu.edu/cmm/
7. Software Engineering Institute. The capability maturity model. Carnegie Mellon Uni-
versity, USA.

Capítulo 2
1. http://www.csci.csusb.edu/dick/samples/comp.prog.5_Hungarian.html#Hungarian%20No-
tation%20for%20C%Programming

Capítulo 3
1. Oxford Dictionary. Oxford: Oxford University Press, 1986.
2. http://www.reisner.com.br
3. Idem.
Referências 245

4. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software deve-
lopment process. Indianápolis: Addison Wesley, 1999.
5. SCOTT, Kendall. O processo unificado explicado. Porto Alegre: Bookman, 2003.

Capítulo 4
1. http://www.cvshome.org/
2. http://www.smartcvs.com/
3. COCKBURN, Alistair. Writing effective Use Case. Indianápolis: Addison Wesley,
2000.

Capítulo 5
1. DEITEL, H.M.; DEITEL, P.J. Java – como programar. Porto Alegre: Bookman, 2001.
2. Object Management Group, Inc. OMG Unified Modeling Language Specification.
March, 2003. Versão 1.5 – formal 03-03-01.
3. PAGE-JONES, Meilir. Fundamentos do desenho orientado a objeto com UML. São
Paulo: Makron Books, 2001.
4. MELO, Ana Cristina. Desenvolvendo aplicações com UML. Rio de Janeiro: Brasport,
2002.
5. FOWLER, Martin; SCOTT, Kendall. UML essencial. 2. ed. Porto Alegre: Bookman, 2000.
6. MARTIN, James; ODELL, James J. Object-oriented methods: a foundation (UML
Edition). New Jersey: Prentice Hall, 1998.
7. FOWLER, Martin; SCOTT, Kendall. Op.cit.
8. Object Management Group, Inc. Op. cit.
9. Idem.
10. LINDHOLM, Tim; YELLIN, Frank. The Java virtual machine specification. Indianá-
polis: Addison Wesley.
11. Support Readiness Document Java™ 2. ed. Standard. Versão 1.4 JavaBeans™ Com-
ponent Architecture.
12. Object Management Group, Inc. Op. cit.
13. LINDHOLM, Tim; YELLIN, Frank. Op. cit.
14. Support Readiness Document Java™ 2. ed. Standard, Versão 1.4 JavaBeans™ Com-
ponent Architectute.
15. Object Management Group, Inc. Op. cit.
16. FERREIRA, Aurélio Buarque de Holanda. Novo Dicionário Aurélio da Língua Portu-
guesa. 2. ed. Rio de Janeiro: Nova Fronteira, 1986.
17. http://java.sun.com/docs/books/vmspec/html/Concepts.doc.html#16432
18. LINDHOLM, Tim; YELLIN, Frank. Op. cit.
19. htpp://lists.xcf.berkeley.edu/lists/advanced-java/2002-September/019099.html
20. http://www.uml.crespim.uha.fr/documentation/version1.0/semantics/semantics_ ch7.html
21. http://www.isg.de/people/marc/UmlDocCollection/UMLDictionary/UML.htm#State
22. Object Management Group, Inc. Op. cit.
23. Microsoft Press. Dicionário de Informática. Inglês-Português e Português-Inglês. Rio
de Janeiro: Editora Campus, 1993.
24. Object Management Group, Inc. Op. cit.
25. FOWLER, Martin; SCOTT, Kendall. Op. cit.
246 Desenvolvendo Software com UML 2.0 – Definitivo

26. DEITEL, H.M; DEITEL, P.J. Op. cit.


27. http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#2287
28. PAGE-JONES, Meilir. Op. cit.
29. DEITEL, H.M.; DEITEL, P.J. Op. cit.
30. CONALLEN, Jim. “Modeling Web Application Architectures with UML” [Arquivo
pdf]. Rational Software, June, 1999. Uma versão deste material aparece na edição de
Communications of the ACM. Rational Software White Paper (27662_webapps.pdf),
v. 42, n. 10, Oct. 1999.

Capítulo 6
1. PAGE-JONES, Meilir. Fundamentos do desenho orientado a objeto com UML. São
Paulo: Makron Books, 2001.
2. FOWLER, Martin; SCOTT, Kendall. UML essencial. 2. ed. Porto Alegre: Bookman, 2000.
3. AMBLER, Scott W. The elements of UML style. In: http://www.agilemodeling.com/style/
classDiagram.htm#_Toc792694. New York, 2002-2003.

Capítulo 7
1. http://www.w3.org/MarkUp/
2. http://v2.rl.ac.uk/DELPHI/Adye/jsspec11/jsrefspe.htm
3. http://devedge.netscape.com/central/javascript/
4. http://www.w3.org/Style/CSS/current-work
5. http://www.w3.org/XML/Activity
6. http://www.oasis-open.org/cover/wap-wml.html
7. http://www.php.net
8. http://www.apache.org/
9. http://www.microsoft.com
10. http://java.sun.com/products/jsp/
11. http://perl.org/
12. http://www.apache.org/
13. http://www.microsoft.com
14. http://jakarta.apache.org/tomcat/
15. http://www.omg.org

Capítulo 9
1. HAREL, David. “Statecharts: a visual formalism for complex systems, Science of Com-
puter Programming.” Science of Computer Programming. Amsterdam: Elsevier, 1987.
2. RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W.
Object-oriented modeling design. New Jersey: Prentice Hall, 1991.
3. AMBLER, Scott W. Principle of maximize stakeholder investment agile modeling
(AM)’s. In: http://www.agilemodeling.com/style/stateChartDiagram.htm, 2002.
4. PAGE-JONES, Meilir. Fundamentos do desenho orientado a objeto com UML. São
Paulo: Makron Books, 2001, p. 181-183.
Referências 247

Capítulo 10
1. CHEN, Peter. Modelagem de dados – a abordagem entidade-relacionamento para pro-
jeto lógico. São Paulo: Makron Books, 1990.

Capítulo 18
1. ALBRECHT, A.J; GAFFNEY, J. “Software function, source lines of code, and deve-
lopment effort prediction: a software Science validation.”IEEE Transactions on Soft-
ware Engineering, New York: ACM Press, SE-9, 6, 1983.
2. KARNER, G. Metrics for objectory. Defesa de tese. University of Limköping, Sweden,
1993.
3. FOWLER, Martin; SCOTT, Kendall. UML essencial. 2. ed. Porto Alegre: Bookman,
2000, p. 89.
Capítulo 1
1. Porque a tecnologia da informação é recente, se comparada a outras ciências. Estas
passaram por um processo de amadurecimento pelo qual a tecnologia da informação
apenas começa.
2. Porque ainda não existe um padrão disseminado a ser seguido pelos requisitantes em
termos de solicitações de construção de software.
3. Não, as solicitações feitas por um interessado mudam com o tempo, em função do
amadurecimento pelo qual passa o interessado e quem se dispõe a fazer o software.
4. Porque nesta fase temos a oportunidade de enxergar o software de forma muito apro-
ximada de como ele realmente é, incluindo-se aí estimativas de prazo e preço.
5. Porque nessa fase, que descreve o que o software será, não pode sofrer muitas altera-
ções, principalmente se contratos já foram assinados; ademais essa fase nos indica o es-
copo do projeto.
6. Sim, é valido, visto que ainda se busca um padrão que seja eficiente em diversos mo-
mentos.
7. As fases do processo iterativo Unificado são: Concepção, Elaboração, Construção e
Transição.
8. Os workflows do processo iterativo são: requerimentos, análise, design, implementa-
ção e testes.
9. O que na verdade existe é uma certificação; a CMM (Capability Maturity Model), que
atesta que uma empresa possui condições plenas de desenvolver software.
10. Sim, são pertinentes ao desenvolvimento de software, porém devem passar por algu-
mas adaptações que permitam sua aplicabilidade.

Capítulo 2
1. O documento Visão é um texto que se assemelha a uma carta de intenções. O que é es-
perado pelo interessado em desenvolvimento de software é formalizado nesse docu-
mento. Normalmente, ele faz parte do contrato de desenvolvimento. Esse documento
deve, da melhor forma possível, descrever o escopo do projeto e as tecnologias a serem
utilizadas. Esse documento deve ser o mais detalhado possível, porém sem entrar em
detalhes operacionais de uma determinada função, exceto se essa função for funda-
mental para o software.
2. O pacote com o estereótipo de <<sistema>> descreve os grandes blocos ou módulos nos
quais se divide o sistema.
Respostas dos Exercícios 249

3. O documento Nomenclatura é necessário porque força a utilização de nomes de forma


padronizada, por toda a equipe de desenvolvimento.
4. O documento Glossário é necessário porque ambienta os novos integrantes do softwa-
re no sentido de conhecerem o jargão utilizado pelos interessados em desenvolvimento
de software. Além disso, este documento é fonte de pesquisa para futuros profissionais
que queiram ler a documentação do software. Assim como o documento Nomenclatu-
ra, o documento Glossário faz parte da documentação do software.
5. O documento Visão, o documento Glossário (ainda que insipiente), o documento No-
menclatura, o diagrama de Casos de Uso com o estereótipo de <<sistema>> e as descri-
ções de Casos de Uso da parte mais crítica de um software.
6. Continuar a descrição de Casos de Uso e iniciar o diagrama de classes que realize os
Casos de Uso já escritos.
7. Se o documento Visão sofrer alterações, isso pode significar um novo contrato, conhe-
cido como de melhoria, com novos prazos e novos preços.
8. Sim, todos devem ter acesso ao documento Visão, ele pode evitar muitos equívocos du-
rante a construção do software.
9. Uma relação de dependência entre Casos de Uso indica que um Caso de Uso somente é
realizado se outro (do qual este depende) foi concluído.
10. Uma relação de inclusão, entre Casos de Uso, indica que um determinado Caso de Uso
inclui outro Caso de Uso inteiro ou somente alguns de seus cenários. Isso evita a repeti-
ção textual de determinados processos que tenham caráter mais complexo.
11. Uma relação de extensão em Casos de Uso indica que um determinado Caso de Uso
‘melhora’ o que já está definido em outro Caso de Uso. Desta forma, quem ‘melhora’
o processo faz alguma coisa adicional ou diferente, exemplo: um cálculo.
12. Um ator pode ser um ser humano, uma máquina, um sistema, uma entidade externa ou
qualquer dispositivo que realize uma ação em um Caso de Uso.
13. Modelos de pacotes ajudam na abstração da complexidade de um domínio de problema.
Conseguimos ver a amplitude de um problema analisando seus componentes em pacotes.

Capítulo 3
1. Caso de Uso é a descrição de uma atividade. Esta é dividida em tarefas bem descritas,
chamadas de cenários. O Caso de Uso pode ser considerado um processo, cujas etapas
são colocadas em forma de texto descritivo.
2. Os cenários principais são descritos, pensando-se no mundo ideal, ou seja, não pensa-
mos em eventualidades que possam impedir aquele cenário acontecer.
3. Uma tarefa de uma atividade. A atividade inteira é um Caso de Uso.
4. Quando percebemos a sensação de que estamos descrevendo cenários de uma ativida-
de totalmente distinta daquela a que nos propusemos, temos uma pista de que invadi-
mos a descrição de outro Caso de Uso diverso do que estamos descrevendo.
5. Qualquer entrevistado, mesmo aqueles sem experiência em tecnologia da informação,
deve ser capaz de ler um Caso de Uso e concordar ou fazer alterações naquilo que está
descrito. Erros de interpretações são evitados quando se permite a correção pelo entre-
vistado. Não há melhor momento para isso, do que pedir a aprovação do entrevistado
na versão escrita do que ele manifestou, falando.
6. Todos aqueles que forneceram informações àquela descrição, adicionalmente aquele
que escreveu o Caso de Uso deve, também, assiná-lo.
250 Desenvolvendo Software com UML 2.0 – Definitivo

7. Todos os adjetivos descritos pelo entrevistado podem estar na seção de Requisitos Es-
peciais. São palavras que não relatam fases do processo, mas sim como este deve ser
obtido. Dessa forma, um cálculo preciso em até quatro casas decimais pode ser relata-
do nessa seção. O fato de ser preciso em até quatro casas decimais é adjetivo de fazer o
cálculo que está descrito no cenário principal.
8. Porque quando estamos descrevendo um Caso de Uso, estamos (normalmente) rela-
tando algo que acabamos de ouvir, os fatos estão muito frescos na memória e os dados
necessários para se guardar estes fatos também. É muito mais fácil pensar nestes dados
(atributos de classes) neste momento, do que tratarmos este assunto exclusivamente
quando criarmos as classes.
9. Não, porque a resolução do negócio é que deve ser retratada em um Caso de Uso, sem
levarmos em consideração a tecnologia que será utilizada. Pensar em tecnologia, nesse
momento, limita o negócio àquela tecnologia e, na verdade, a tecnologia será função
do negócio, não o inverso.
10. Criamos o diagrama de Caso de Uso relativo ao sistema. É um diagrama com um este-
reótipo de <<sistema>>, em seguida criamos os subdiagramas dos módulos descobertos
no <<sistema>>. Esses subdiagramas de Casos de Uso recebem o estereótipo de <<sub-
sistema>>. Esses Casos de Uso, descobertos nos subsistemas, serão descritos, um a um.

Capítulo 4
1. O diagrama de atividades descreve o fluxo de determinada atividade. Pode facilitar a
descrição de Casos de Uso, partindo-se desse diagrama.
2. Teoricamente, a resposta é não. Se surgiu um fork deve haver o encontro em um join. A
menos que as atividades surgidas no for sejam muito distintas daquelas que estamos
retratando.
3. As swinlanes dividem as participações dos atores em um diagrama de atividades.
4. Podemos utilizar uma nota ou, formalmente, a notação da UML, que é a condição en-
tre colchetes = [condição = xpto].
5. Utilizamos a notação de atividade, um retângulo com os cantos arredondados, e den-
tro desse um tridente invertido; este é conhecido como Rake ou rodo.
6. Utilizando regiões de atividades interrompidas; é um retângulo com uma linha ponti-
lhada sobre as atividades que podem sofrer a interrupção. A atividade que pode ocor-
rer em qualquer momento, inicia-se neste retângulo.
7. Se uma atividade é temporal, devemos utilizar o símbolo de ampulheta para represen-
tá-la.
8 Um PIN pode ser utilizado representando entrada ou saída de valores, ou ambos; signi-
ficando que a atividade ocorre a partir de determinados estímulos conhecidos que po-
dem gerar outros de saída. Os estímulos de entrada podem ser gerados por outras
atividades, e os de saída podem gerar outras.
9. Não, porque normalmente uma ferramenta de modelagem UML é destinada a dese-
nhos de diagramas. Se escrevermos textos de Casos de Uso com a ferramenta de mode-
lagem UML, corremos o risco de não termos liberdade para gerenciar seus requisitos e
formatá-los conforme nosso gosto.
10. Sim, isso depende da experiência do analista de negócios que se dedica à tarefa de des-
crever Casos de Uso.
Respostas dos Exercícios 251

11. Se um colega leu o que escrevemos e interpretou o que deveria estar escrito, o cenário
ou o Caso de Uso está mal escrito. Outra pista é quando um programador está fazendo
muitas perguntas referentes ao Caso de Uso ou a determinado cenário. Se há muitas
perguntas, algo deixou de ser escrito. Um Caso de Uso deve ser detalhado, tanto quan-
to necessário. Essa quantidade de detalhamento depende da complexidade da ativida-
de que está sendo descrita.
12. Porque podemos gerar uma expectativa que não sabemos se vamos cumprir. O entre-
vistado esperará a interface gráfica que foi comentada durante a extração dos Casos de
Uso. Normalmente, quem descreve um Caso de Uso não é um web designer e pode fa-
lar sobre assuntos que não domina. Desta forma, é melhor não falarmos de janelas ou
qualquer outra forma de interface gráfica durante a descrição de Casos de Uso. O Caso
de Uso é uma representação descritiva de uma atividade que é realizada em um negócio,
com todos os detalhes necessários para aquela atividade ser concretizada, nada mais.
13. No documento Nomenclaturas.
14. Um requisito é um cenário e, ao mesmo tempo, um cenário é composto de vários requi-
sitos. Cenários que não apresentam requisitos não são automatizados.
15. Com certeza, este são revistos porque Atores podem surgir ou deixar de existir, assim
como os Casos de Uso essas mudanças são percebidas durante entrevistas para as des-
crições de Casos de Uso.

Capítulo 5
1. Não é uma classe que desenhamos, é um modelo no qual o compilador se baseará para
criar objetos na memória. Os objetos estão na memória, sendo reproduzidos quantas ve-
zes forem necessárias, mas a classe é uma só, enquanto a aplicação existir na memória.
2. Operação é apenas um protótipo, contendo o nome e os argumentos. Quando alguém
acrescenta código à operação esta se transforma em método.
3. A responsabilidade de uma classe é designada por seus atributos e métodos.
4. A herança é a capacidade que uma classe tem de permitir que outras utilizem seus atri-
butos e métodos como se fossem delas. A classe que fornece a herança é conhecida
como SuperClasse enquanto a que recebe a herança é conhecida como SubClasse.
5. A herança múltipla ocorre quando uma classe – SubClasse – herda atributos e métodos
de mais de uma classe SuperClasse. Nomes de métodos e atributos iguais, em classes
ancestrais diferentes podem deixar dúvidas sobre qual exatamente está sendo herdado.
6. Para criarmos uma interface, nós devemos estereotipar uma classe onde podemos inse-
rir atributos com valores constantes e operações que outras classes devem implemen-
tar, ou seja, outras classes é que transformaram essas operações em métodos.
7. As visibilidades de uma classe são: privada, pública, pacote e protegida.
8. Uma classe marcada com a visibilidade de protegida permite que apenas as classes que
fizerem parte de sua árvore de herança acessem seus atributos e métodos. Uma classe
com a visibilidade de pacote indica que apenas as classes que estejam no mesmo pacote
poderão acessar seus atributos e métodos.
9. Os modificadores de uma classe são estereótipos que alteram o significado de uma classe.
10. Uma interface não pode ter código em nenhum método e seus atributos são valores cons-
tantes, já uma classe abstrata pode ter de um a vários atributos marcados como abstratos e
estes são atribuídos após a instanciação do primeiro objeto daquele tipo. Adicionalmente,
uma classe abstrata pode ter de um a vários métodos marcados como abstratos.
252 Desenvolvendo Software com UML 2.0 – Definitivo

11. Evitamos que códigos externos à nossa classe herdem funcionalidades de nossas clas-
ses marcando-as com o modificador FINAL.
12. Pode, basta essa classe ser marcada com o modificador de ativa. Outra forma é mar-
carmos atributos e métodos com o modificador de estático, o que faz com que esses
atributos e métodos sejam acessíveis apenas a partir da classe e não de seus objetos.
13. Porque a orientação a objetos recomenda que os atributos sejam acessados e alterados
apenas pela classe que os guarda. Isso faz parte do conceito de encapsulamento.
14. Sim, podemos. Isso é permitido para que possamos alterar o significado de um atribu-
to. Por exemplo um atributo é, em regra, gerenciado por objetos. Se desejarmos que
um atributo mude seu significado e seja gerenciado por uma classe, podemos usar o
modificador estático nesse atributo.
15. Um modificador estático indica que somente a classe pode alcançá-lo. Suponha que
seja necessária a contagem de objetos do tipo daquela classe, na memória. Essa situa-
ção somente seria resolvida com a criação de um atributo estático acessado por um mé-
todo; por exemplo, o construtor da classe, e este alteraria o valor desse atributo.
16. A visibilidade de público, pois deve haver uma forma de permitir que outras classes al-
cancem os valores da classe em questão. Sem a visibilidade de público não haveria
como os métodos chegarem à visibilidade das classes.
17. Não. É necessário que um método seja estático (dentro da mesma classe) para que seja
possível alcançar um atributo estático.
18. Sim, sempre será, isso é uma convenção.
19. Na agregação os objetos ‘parte’, devem viver se os objetos ‘todo’ forem destruídos. Já
na composição ocorre o contrário: caso objetos da seção ‘todo’ sejam destruídos, os
objetos ‘parte’ são destruídos também. Quando colocamos como atributo de uma clas-
se, um valor do tipo de outra classe, estamos utilizando a composição. Quando usa-
mos um valor do tipo de outra classe, dentro das linhas de código de um método de
uma classe, estamos usando a agregação.
20. Indica que é responsabilidade da classe de onde parte a navegabilidade saber quantos e
quais são os objetos na classe para onde a navegabilidade aponta.
21. Para fins de administração de grandes aplicações e, também, para permitir a compo-
nentização de objetos. Isso levará outras partes da empresa a utilizarem os pequenos
componentes que gerarmos, promovendo a reutilização de código.
22. O conceito de coesão indica que os métodos de uma classe cuidam, exclusivamente, de
seus atributos, retornando ou ajustando os seus valores. Um Classe não cuida de algo
que não é de sua responsabilidade. O desejável na orientação a objetos é uma classe
com alta coesão. O relacionamento entre duas ou mais classes indica seu acoplamento.
O ideal é termos como objetivo o baixo acoplamento. Isso evitará que quando alguém
necessite usar uma classe tenha de levar várias classes, devido ao alto acoplamento. O
relacionamento entre as classes indica o seu acoplamento.
23. A assinatura de um método se compõe de seu nome, os tipos e as quantidades de seus
atributos. Não faz parte da assinatura de um método o tipo de retorno de um método.
24. A sobrecarga é a redefinição de um método com assinaturas diferentes na mesma clas-
se. O polimorfismo é a redefinição de um método com a mesma assinatura em classes
diferentes.
25. Os estereótipos nos permitem usar símbolos não previstos na UML. Isso nos dá exten-
sibilidade de semântica. Porém, isso deve ser regrado por normas da equipe que está
utilizando o estereótipo. A nova semântica deve fazer sentido para todos.
Respostas dos Exercícios 253

26. O estereótipo de utility indica que a classe que o recebe possui métodos e atributos que
servem a diversas classes. São métodos, por exemplo, pelos quais não conseguimos
identificar qual classe é responsável.

Capítulo 6
1. Devemos tentar resolver os cenários com métodos nas classes.
2. Sim, precisamos de um controlador de versões do tipo CVS, a fim de permitir que vá-
rios analistas trabalhem no mesmo projeto ao mesmo tempo.
3. Na conceituação de um negócio, estamos preocupados em separar classes por área de
atuação. Cada área atinge parte do negócio. Nessa fase, os métodos podem não ter ti-
pos de retorno, como também argumentos. Na fase de especificação, os métodos ga-
nham tipos de retorno e parâmetros. Nesta última fase, nos preocupamos com a
responsabilidade das classes e com coesão e acoplamento.
4. Sim, teremos métodos que se repetiram nas classes, estes podem ser omitidos. Os ana-
listas e programadores devem partir de classes modelos, elegidas a partir da reunião
inicial de software. Normalmente essas classes fazem parte do momento mais crítico
de um software. Nessas classes, os métodos comuns ou repetidos são documentados a
fundo.
5. O melhor momento para tratarmos os métodos repetidos é na reunião inicial de soft-
ware ou quando estes surgirem na necessidade.
6. No primeiro momento da criação das classes, devemos pensar na resolução do negó-
cio. O pensamento na implementação pode levar a equívocos e atrasos; além disso, a
técnica da abstração indica que devemos pensar nas coisas de forma separada.
7. Os cenários alternativos podem ser métodos nas classes; também podem ser condições
de métodos como (‘if’, ‘else’, ‘case’), resolvidos internamente nestes métodos.
8. Sim, porque à medida que desenhamos as classes temos suas necessidades muito claras
em nossas mentes. Não há melhor momento para resolvermos as visibilidades e os mo-
dificadores de classes. Essas visibilidades, porém, podem mudar ao longo do projeto; por
exemplo, na programação.
9. Deve-se documentar um cenário dentro de uma classe.
10. Deve-se documentar na UML, nas descrições de Caso de Uso e nas classes, dentro do
diagrama de classes. Deve-se resistir à tentação de documentar em outros diagramas,
pois estes são muitos e podem deixar futuros colegas confusos.

Capítulo 7
1. Não, isso ocorre porque HTML não é capaz de processar coisa nenhuma.
2. Sim, podemos. Basta utilizarmos os estereótipos nas classes. Qualquer arquivo pode
possuir os compartimentos de uma classe. Qualquer arquivo possui nome, atributos
ou características e alguns podem possuir métodos. Então, podemos estereotipá-los.
3. Compilação. A cada alteração em uma instrução SQL, precisaremos recompilar os ar-
quivos que fazem referência àquele SQL. Checagem de sintaxe. Todas as ocasiões em
que o banco de dados for realizar um SQL externo, este verificará se a sintaxe do SQL
está correta. Montagem de Plano de Acesso. Todas as vezes que um banco de dados for
executar uma instrução SQL, este verificará qual é o melhor caminho, ou seja, quais os
melhores índices para resolver a consulta.
254 Desenvolvendo Software com UML 2.0 – Definitivo

4. Não, é um mito acreditar que, porque uma aplicação tem mais camadas, será mais len-
ta de modo a prejudicar o andamento do trabalho. No entanto, a divisão em camadas
mais auxilia a reutilização dos componentes do que aumenta a preocupação com tem-
po de execução.
5. A afirmação não procede, porque é salutar uma aplicação utilizar variadas tecnologias
de modo a não se depender exclusivamente de apenas uma fonte tecnológica.
6. Deveríamos sugerir a utilização de uma solução WEB, que requer estações mais bara-
tas e permite maior escalabilidade.
7. Com uma tecnologia que sirva de ponte entre o HTML e o Servlet, esta poderia ser
uma JSP ‘Java Server Page’.
8. Um servidor de aplicação congrega vários componentes de várias aplicações e permite
o uso inteligente da memória entre os vários chamadores.
9. XML existe, precipuamente, para a troca de dados entre aplicações e sites de Internet.
10. Web Services são, virtualmente, qualquer aplicação que exista para fornecer uma de-
terminada informação para outras.

Capítulo 8
1. O diagrama de seqüência é conhecido como um diagrama de interação, porque modela
a interação de um usuário, desde sua ação na interface gráfica até que o resultado desta
ação seja processado e exibido de alguma forma. Este diagrama existe, desde que exis-
ta uma interação com o usuário da aplicação.
2. Os diagramas de seqüência, comunicação, Timing Diagram e interação – Visão Geral.
3. O diagrama de seqüência é usado para corrigirmos prováveis erros no diagrama de
classes. Nele podemos descobrir a exata interface gráfica e, também, iniciar a confec-
ção do Modelo de Entidade e Relacionamento necessários.
4. Objetos, pois estamos representando situações na memória.
5. Sim, como exemplo, podemos representar uma página HTML ou PHP, que serão obje-
tos estereotipados.
6. Sim, é possível. Esse tipo de situação é conhecida como chamada self ou recursiva.
7. Um ator executa alguma ação na interface gráfica e os objetos enviam mensagens entre si.
8. Sim, situações de decisão são representadas utilizando-se fragmentos combinados.
9. Podemos usar uma simples nota ou os pontos de continuação. A notação de um ponto
de continuação é igual a de um Caso de Uso.
10. As mensagens síncronas são aquelas que são executadas e espera-se seu resultado; as
assíncronas são executadas e não esperamos seu retorno, outras ações são disparadas
independente de seu resultado.
11. Sim, pode. Basta estereotiparmos uma classe e lhe emprestarmos o significado de <<en-
tidade>>.
12. Não, se existe um objeto no diagrama de seqüência, deve existir a classe corresponden-
te no diagrama de classes.
13. O diagrama de seqüência altera o diagrama de classes, pois, ao confeccionarmos esse
diagrama, via de regra, encontramos os erros cometidos no diagrama de classes.
14. O retorno é representado com uma seta pontilhada entre os objetos.
15. Podemos representá-los em fragmentos combinados ou em mensagens normais.
Respostas dos Exercícios 255

Capítulo 9
1. Meilir Page-Jones aconselha que, se temos um atributo que tenha um universo restrito
de valores e regras de passagens entre estes valores, podemos usar o diagrama de estados
para este atributo.
2. Uma máquina de estados é um estado que contém outros estados representados nele.
3. Um pequeno círculo pode representar escolha.
4. Usando uma nota.
5. Sim, essa situação é perfeitamente possível, pois existem situações iniciadas a partir de
várias outras situações e terminadas por variadas razões.
6 Um entry point ou entry action é uma ação que será executada todo o momento em
que o objeto entrar no estado em que essa ação está inserida.
7. Um exit action é uma ação que será executada em todo momento que sairmos de um
determinado estado.
8. As representações das ações que um estado encerra são feitas por meio de métodos nas
classes.
9. Porque são muito poucos valores para gerarem dúvidas a respeito. Na opinião deste
autor, até 5 (cinco) estados são situações fracas para modelagem com o diagrama de
estados.
10. Sim, podem provocar, pois podemos descobrir novos métodos, atributos e até novas
classes.

Capítulo 10
1. Um banco de dados guarda informações correlatas a determinado assunto. A junção
desses dados, de uma forma inteligível, nos dá informações sobre esse assunto.
2. Uma entidade, em um banco de dados, é uma tabela que contém registros; estes são
formados por linhas e colunas. Cada coluna guarda um dado sobre o assunto do qual
aquela entidade cuida.
3. Quando temos várias entidades se relacionando umas com as outras, temos um mode-
lo de Entidade e Relacionamento.
4. Nas fases de Elaboração e Construção.
5. Quando estamos modelando diagramas de interação. Um exemplo é um modelo gera-
do por um diagrama de seqüências.
6. As vantagens são: realização do plano de acesso apenas uma vez, checagem de sintaxe
apenas no momento da compilação da função, concentração das funções de banco de
dados em um único lugar.
7. Não, classes não são entidades; classes podem ter suas entidades correspondentes no
banco de dados, mas isso não é uma regra.
8. Na presença de um diagrama de seqüências, podemos definir, paulatinamente, quais
dados devem ser guardados e retornados do banco de dados.
9. Chave primária é o conjunto de colunas de um registro que o identifica de forma uní-
voca, já a estrangeira ocorre quando primárias de outras entidades são representadas a
fim de se promover o relacionamento entre as entidades.
10. Podemos utilizar o modificador PERSISTENTE.
11. Normalização é a organização de dados em entidades de modo a promover a abstra-
ção de um assunto e evitar a repetição desnecessária de um determinado dado.
256 Desenvolvendo Software com UML 2.0 – Definitivo

Capítulo 11
1. Devemos separar as classes em pacotes, quando entrarmos na fase de especificação do
diagrama de classes. Isso pode também ser feito quando já temos os diagramas de se-
qüência, estados e MER de determinado conjunto de Casos de Uso.
2. Porque devemos colocar, no mesmo pacote, classes que tenham muitos relacionamen-
tos ou alto acoplamento.
3. Sim, porque, quando na programação, teremos esses arquivos, por exemplo, nos mes-
mos diretórios.
4. Fornece uma visão de quantos e como se relacionam os vários módulos de nosso sistema.
5. A semântica destas setas muda para <<inclui>> ou <<acessa>>, por exemplo.
6. Quando modelando os Casos de Uso do documento Visão ou quando estamos empa-
cotando classes.
7. Sim, porém é aconselhável que utilizemos o conceito de acoplamento ao pensarmos em
pacotes de classes.
8. Pode. Isso pode ocorrer caso queiramos retirar métodos de uma classe e adicioná-los a
outra, a fim de evitarmos o alto acoplamento entre classes, de pacotes diferentes.
9. Para termos uma visão mais clara do que nosso servidor de aplicações irá gerenciar e
de qual o tamanho do processamento será exigido de determinado servidor, bem como
para organizarmos a aplicação em pequenos módulos.
10. Podem ser arquivos .jar ou outros arquivos compilados que congreguem classes.

Capítulo 12
1. Um componente é qualquer parte de um software; neste sentido, até um arquivo com
extensão .txt pode ser um componente.
2. A semântica de um pirulito em um componente é de que este componente tem uma in-
terface com a qual o mundo exterior pode se comunicar.
3. Tem a semântica de que este componente espera que uma interface de um outro com-
ponente se comunique com ele.
4. Nó é um servidor. Uma máquina ou hardware que acomodará certos componentes.
5. O diagrama de componentes nos ajuda a entender como nossos diversos componentes
conversam entre si. A importância desse diagrama é relativa à complexidade do módu-
lo em questão. O diagrama de pacotes pode fazer esse papel.
6. O diagrama de implantação nos dá uma dimensão melhor do tamanho de nosso soft-
ware, a utilização de memória RAM e disco que ele necessitará. Além disso ele fornece
uma visão ampliada da comunicação de rede que haverá entre os diversos componen-
tes em diversos nós.
7. O público mais adequado para a leitura do diagrama de componentes e implantação é
o público de infra-estrutura.

Capítulo 13
1. Um diagrama de objetos retrata a comunicação existente entre objetos na memória.
Deste modo, no diagrama de objetos, um objeto deve ser retratado com valores em
seus atributos. Por esta razão, este diagrama é conhecido, também, como teste de
mesa. É trabalhoso e deve ser usado com parcimônia.
Respostas dos Exercícios 257

2. Porque os métodos residem nas classes e não nos objetos. Os objetos detêm apenas
seus atributos.
3. Veja a resposta 1 deste capítulo.
4. Quando necessitamos esclarecer, ou para a análise ou para a programação, o que espe-
ramos de um determinado relacionamento de classes.

Capítulo 14
1. O diagrama de comunicação é considerado um diagrama de interação porque retrata a
interação com um usuário.
2. O diagrama de seqüência.
3. Quando queremos esclarecer como um usuário obterá determinado resultado, seja
uma informação ou simples dado ou um processamento. Apesar disso, o diagrama de
seqüências atende a todas essas expectativas.
4. Numeramos as mensagens entre os objetos na forma seqüencial em que elas acontecem
e, conseqüentemente, na ordem em que melhor podem ser programadas.
5. Este diagrama é o antigo diagrama de colaboração na UML 1.5.

Capítulo 15
1. Porque esse diagrama mostra a interação entre objetos em determinado ponto do tempo.
2. Existem duas formas de representação do Timing Diagram.
3. Apesar de seu uso não ser comum, o Timing Diagram pode ser usado para demonstrar
a alteração do estado de determinado objeto, porém este recurso é alcançado perfeita-
mente com o diagrama de estados.

Capítulo 16
1. Um diagrama de interação – Visão Geral é um diagrama que contém outros diagramas.
2. Podemos usar este diagrama para mostrar como determinado processo se comporta
em diferentes tipos de visões. Quando uma visão geral for necessária, podemos lançar
mão deste diagrama.
3. Não existem limites de números de diagramas a serem utilizados dentro de um diagra-
ma de interação – Visão Geral.
4. Quando as seqüências das interações se mostraram tão complexas que requisitam um
resumo que possibilite uma visão geral daquela interação.
5. Quando as seqüências das interações se mostrarem tão complexas que requisitem um
resumo que possibilite uma visão geral daquela interação.

Capítulo 17
1. O Composite Structure Diagram mostra a colaboração, ou comunicação, que existem
entre as instâncias de classes distintas (objetos) e interfaces.
2. O diagrama de comunicação mostra a comunicação que existe entre, exclusivamente,
objetos e lá o importante é quando estes enviam mensagens uns para os outros. O Com-
posite Structure Diagram é um diagrama que vê uma colaboração como algo onde vá-
rios objetos participam.
258 Desenvolvendo Software com UML 2.0 – Definitivo

3. A notação para uma colaboração dentro do Composite Structure Diagram é uma elip-
se com a borda tracejada.
4. Uma colaboração dentro do Composite Structure Diagram possui dois compartimen-
tos: um com o nome e outro onde podemos representar os elementos que participam
daquela colaboração. Uma colaboração pode conter outras.
5. O significado das linhas sólidas entre os elementos de uma colaboração é a indicação
de que, de alguma forma, estes elementos se comunicam através de acessos, importa-
ções ou usos.
6. Este diagrama ainda não tem seu uso disseminado entre os usuários da UML, devido ser
uma novidade da UML 2.0. Se algo está muito complicado ou a programação não con-
segue resolver uma determinada situação, se explicar em português claro e alto a situação
apresentada não adiantou, então, você já respondeu a pergunta – faça o diagrama!
A público, 88
static, 90
abstração, 3-5, 12, 15, 28, 38, 49-50, 56, 62,
transiente, 91
73, 86, 147, 195, 197, 203, 217, 249, 251
volátil, 91
Abstração
atributos
o que é, 38
visibilidade, 88
aceitabilidade, 44
acoplamento, 12, 107-108, 115, 248, 252
agregação, 96, 98-99, 198, 206, 248
B
análises
post-mortem, 12 Booch, 9
Arquitetura de Software breve descrição, 40
o que é, 50
artefatos
o que é, 16 C
ASP, 140
assinatura de um método, 108 cardinalidade, 101
atividade, 26, 37-38, 44, 51-53, 55-56, 73, Caso de Uso, XVIII-XX, 9-11, 13-15, 20, 23,
118, 245-247 26-28, 34, 36-47, 49-52, 54, 60-69,
Atividades, XIX, 10, 50, 52, 55-59, 61-62, 71-73, 86, 112-113, 115-117, 119-124,
64-65, 73, 173, 246 126-132, 134-136, 147, 152, 160, 164,
parametrizadas, 55 178, 183-184, 210, 218, 221, 231,
Ator, 26-28, 37, 50, 66-67, 125, 184, 189, 233-235, 237-238, 242, 245-247,
194-195 249-250
atores envolvidos, 40 Casos de Uso
atributo medir esforço, 230
Final, 91 novos, 71
modificador Persistente, 195 obsolescência, 71
pacote, 89 planilha de administração, 72
privado, 88 cenário mal-escrito, 62
protegido, 89 cenário principal
260 Desenvolvendo Software com UML 2.0 – Definitivo

bem descrito, 41 Comunicação, XX, 10, 164, 216-218, 250


cenários complexos, 62 comunicação interpessoal, 38-39
cenários principais, 40 condição
exceção, 41 atividade, 53
chave-estrangeira, 187 Continuações, 152
classe CSS, 139
Active, 87
atributos, 77
concreta, 86 D
Final, 87
instância, 75 David Harel, 171
modificações, 85 decisão, 3, 29, 37, 53, 56, 89, 170, 174, 176,
notação, 76 203, 213, 250
o que é, 75 dependência, 26, 35, 41, 49, 112, 157, 190,
operações e métodos, 77 197, 206-207, 241, 245
pacote, 84 DHTML, 139
privada, 84 diagrama de classes, XIX, XXI, 9, 13, 15,
pública, 83 41, 74, 76, 113-120, 135-136, 144-145,
responsabilidade, 78 147-148, 152, 155-156, 159-160, 164,
root, 87 170, 172, 178, 181, 204, 210, 217-218,
utility, 113 245, 250, 252
visibilidade, 83 diagrama de Comunicação, 216
Classe, 10, 31, 75-78, 83-87, 94, 105, 113, diagrama de Estado, 171
154, 195, 241-242, 248 David Harel, 171
classes notação, 173
Coleta de Lixo, 75 Diagrama de Fluxo de Dados, 7, 62, 180
encapsulamento, 105 DFD, 7
Especificação, 118 diagrama de implantação, 207
Implementação, 118 Diagrama de Interação, 147
pacotes, 105 diagrama de Interação – Visão Geral, 223
relacionamentos binários, 99 diagrama de pacotes, 197
relacionamentos ternários ou superiores, diagrama de seqüência, 147
100 notação, 148
responsabilidade, 102 diagramas de classes
coesão, 12, 107-108, 115, 248-249 Conceitual, 118
Colaboração, XX, 10, 216, 227 diagramas de componentes e implantação,
componente, 205 205
interfaces, 206 dicionário de dados, 186
Componentes, XX, 10-11, 205, 207 Dicionário de Entidades, 183
composição, 38, 98-99, 101, 113, 119, discriminador
124-125, 132, 181, 198, 206, 248 completo, 80
Composite Structure Diagram, XX, 10, dinâmico, 81
226-229 estático, 81
Índice 261

incompleto, 81 do processo unificado, 12-16, 18, 20-21,


sobreposição, 81 120, 196, 244, 246, 251
DLL, 141 final de um fluxo, 54
do action, 176 final de uma ocorrência de execução, 150
documentação, XVIII, 14, 22, 25, 29, 69, 79, FK, 187
83, 117-118, 129, 133-136, 164, 218, foreign key, 187
221, 245 Fork, 53, 175
Funções ou Stored Procedures, 143

E
G
Effect, 59
Enterprise JavaBean, 142 Gates, 152
entidade relacionada, 192 gCVS, 118
Entidades e Relacionamentos, 3, 210 gerenciamento de requisitos
Entidades Informais, 182 o que é, 43
entry action, 175 Gerenciar requisitos
Estado, 10, 67, 96, 171-173, 175-177, 183, o que é, 17
189-191, 220 Glossário, 13, 20, 33-35, 44, 245
estado composto, 173 Gustav Karner, 231
regiões, 173
estado de escolha, 174
estado final, 174 H
estado inicial, 174
estado simples, 173 herança
estereótipo, 112 como representar, 79
estilo discriminadores, 80
Caso de Uso, 64 GenEspec, 78
estimativa, 232 o que é, 78
estruturada, 7, 26, 37, 45-46, 50, 138-139, herança múltipla, 80
182 HTML, 138
Estruturas Todo
o que é, 96
I

Implantação, 7, 10-11, 49, 210


F Incremental, XVIII, 12, 20
incremento, 12, 14, 20, 94
fase
Instruções SQL, 143
concepção, 13
interação, 12, 14, 132, 147, 150, 152, 164,
construção, 14
170, 216, 218-220, 222, 224, 236,
elaboração, 13
250-251, 253
transição, 14
Interação, XX, 10-11, 147, 150, 224-225,
fases
250, 253
262 Desenvolvendo Software com UML 2.0 – Definitivo

interface modificadores de atributos, 90


o que é, 82
interface esperada, 206
interface gráfica, 4, 12, 43, 51, 63-64, 82, N
122-123, 125, 145, 181, 198, 200, 202,
208, 239, 247, 250 navegabilidade, 101
interfaces fornecidas, 206 nó, 207
iteração, XVIII nodes, 207
iterações, XVIII, 8, 12, 14, 21, 36, 232 Nomenclatura, 13, 28-29, 32, 34-35, 245
Iterativo, XVIII, 20-21, 36, 50, 232, 234, Normalizar, 188
237, 244 nós, 207
nota, 6, 37, 53-54, 58-59, 100, 104, 117,
135, 163-164, 213-214, 224, 246,
250-251
J
notação de um objeto, 212
JAR, 141 notação Hungariana, 29
Java
herança, 80
JavaScript, 138 O
Join, 53, 175
JSP, 140 Object Management Group, 9
Objectory, 9
objeto
o que é, 75
L
objeto entidade, 153
líder do projeto, 46 objeto envia uma mensagem, 149
Objetos, XX, 8-10, 29, 76, 79-80, 82, 88-89,
97-99, 107, 113-115, 182, 212, 214,
M 234, 237, 250
Ocorrências, 182
MacCVS, 118 OMT, 9
mensagem OOSE, 9
recursivo, 150 operação
mensagem encontrada, 152 abstrata, 94
mensagem perdida, 152 concorrência, 96
mensagens estática, 93
assíncronas, 150 Final, 95
retorno, 149 pacote, 93
MER, XX, 1, 7, 10-13, 164, 179-182, 188, privada, 92
192, 196, 234 protegida, 92
Merge, 53-54 pública, 92
métodos repetitivos, 119 query, 95
Modelar Root, 95
o que é, 18 Operações
Índice 263

modificadores, 93 S
visibilidade, 92
segunda forma normal, 190
operador de interação, 150
Seqüência, 10, 152, 154-155, 157, 159, 163,
Overloading, 109
179
overriding, 110
Servlets, 142
seta tracejada, 26, 112, 149
Sinais de aceitação, 55
P sinal
Pacotes, 10, 20, 204, 210 aceito, 55
periodicidade, 55 Situações Acessórias, 182
PHP, 140 Smart CVS, 118
PIN, 55 Sobrecarga, 109
PMI stakeholders, 33-34, 43
o que é, 18 SubClasse, 79-81, 84, 99, 110-111, 121, 247
Polimorfismo, 110 Swimlanes, 53
ponto de saída, 53-54
Pré-Condição, 40
pré-projeto, 21, 71, 233 T
Primary Key, 187
terceira forma normal, 191
primeira forma normal, 188
time de desenvolvimento, 17, 118, 136
processo
Timing, XX, 10, 147, 221-224, 250, 253
entrada, 53
Timing Diagram, 220
saída, 53
Todo – Parte
protótipos de tela, 4
o que é, 78
trabalhadores
o que são, 16
Q transição de estados, 175
Queda d’Áágua, 7 tridente, 53, 246
Queda D’Água, 11 Trigger, 59

R U

redefinição de um método, 110 UML


Regiões de Atividade Interrompidas, 54 download, 9
relacionamento, 186 finalidade, 9
relacionamentos com cardinalidades, 187 O que é, 10
requisito UML 2.0
o que é, 43 composição, 9
Requisitos especiais, 41 unicidade de um registro, 184
riscos, 8, 13, 16-17 usabilidade, 44, 63, 124
264 Desenvolvendo Software com UML 2.0 – Definitivo

V workflow
análise, 15
Visão, XIX-XX, 10-11, 13, 19, 22-25, 27-28,
implementação, 15
34-35, 37, 43, 49, 51, 116, 147, 181, 210,
projeto, 15
223-225, 244-245, 250, 252-253
requisitos, 14
teste, 15
workflows, 12, 14-16, 18, 20-21
W

Web Services, 142


WinCVS, 118 X
WML, 140
XML, 139
Página em branco