Anlise e Modelagem de Sistemas com a UML

Com Dicas e Exerccios Resolvidos

Luiz Antnio de Moraes Pereira

1 Edio Rio de Janeiro Edio do Autor 2011

Copyright by Luiz Antnio de Moraes Pereira, 2011 lpereira@uninet.com.br

A distribuio deste texto na forma impressa e/ou digital livre, desde que seja feita gratuita e integralmente.

CIP-BRASIL. CATALOGAO-NA-FONTE SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ P492a Pereira, Luiz Antnio de Moraes, 1957Anlise e modelagem de sistemas com a UML : com dicas e exerccios resolvidos / Luiz Antnio de Moraes Pereira. 1.ed. Rio de Janeiro : Luiz Antnio M. Pereira, 2011. il. Inclui bibliograa Apndice ISBN 978-85-911695-0-4 1. Software - Desenvolvimento. 2. UML (Computao). 3. Anlise de sistemas. I. Ttulo. 11-0168. CDD: 005.1 CDU: 004.41 10.01.11 12.01.11 023817

Aos meus lhos Felipe e Henrique.

Sobre o Autor Luiz Antnio graduou-se em Engenharia de Forticao e Construo pelo Instituto Militar de Engenharia IME no Rio de Janeiro em 1980. Obteve o grau de Mestre em Cincias em Informtica pela Pontifcia Universidade Catlica do Rio de Janeiro PUC-Rio em 1987 e de Doutor em Cincias em Informtica em 2004 nesta mesma universidade. Trabalhou de 1981 a 1993 no segmento de Tecnologia da Informao em diversas empresas no Rio de Janeiro e So Paulo. Desde 1993 trabalha no Banco Central do Brasil. Ao longo de sua carreira ministrou treinamento em diversas organizaes do setor pblico e privado e desde 2001 atua como Professor da PUC-Rio na Coordenao Central de Extenso CCE , ministrando disciplinas nos cursos de anlise, projeto e desenvolvimento de sistemas, de banco de dados e de gerncia de projetos de software. Sobre a Obra Este texto foi formatado com o uso do MikTeX 2.7. A documentclass usada foi a memoir, com as opes 12pt, twoside, openright e a4paper. Os pacotes usados foram o graphicx, hyperref, boxit, framed, xcolor, makeidx, acronym, ean13isbn e o wrapfig. O editor de textos usado foi o WinEdt.

S UMRIO
Sumrio Lista de Figuras Lista de Tabelas Lista de Siglas Prefcio 1 Introduo 1.1 A Motivao Para Esta Apostila . . . 1.2 Sobre Ferramentas CASE . . . . . . . 1.3 Bibliograa Adicional Recomendada 1.4 Organizao Deste Texto . . . . . . . 5 10 16 19 21 1 1 3 4 5 7 8 9 11 12 14 17 18 19 20 22 23

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Fundamentos da Modelagem de Sistemas 2.1 O que Software, Anal? . . . . . . . . . . . . . . . . . . . . . 2.2 Qualidade de Software . . . . . . . . . . . . . . . . . . . . . . 2.3 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . 2.4 Processos de Software . . . . . . . . . . . . . . . . . . . . . . . 2.5 Modelos e Modelagem de Software . . . . . . . . . . . . . . . 2.6 Recursos Usados em Modelagem e Construo de Sistemas 2.7 As Anlises Estruturada e Essencial . . . . . . . . . . . . . . . 2.8 Anlise e Modelagem Orientadas a Objetos (OOAD) . . . . . 2.9 UML Breve Histria e Objetivos . . . . . . . . . . . . . . . . 2.10 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Exerccios Propostos . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Diagramas de Casos de Uso: Conceitos e Elementos Bsicos da Notao 25 3.1 Enfoques dos Diagramas de Casos de Uso . . . . . . . . . . . . . . . . . . . 26 3.2 Os Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5

3.3 3.4 3.5 3.6 3.7 3.8 4

Os Casos de Uso . . . . . . . . . . . . . . . . . . . . A Fronteira do Sistema . . . . . . . . . . . . . . . . Relacionamentos em Diagramas de Casos de Uso Os Itens Anotacionais da UML . . . . . . . . . . . . Resumo do Captulo . . . . . . . . . . . . . . . . . . Exerccios Propostos . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

31 32 32 40 41 41 43 44 45 47 53 56 57 59 60 61 64 67 68 68 69

Diagramas de Casos de Uso: Descries, Dicas e Erros Comuns de Modelagem 4.1 Padro de Descries nas Organizaes . . . . . . . . . . . . . . . . . . . . 4.2 Descries Abreviadas e Descries Detalhadas . . . . . . . . . . . . . . . 4.3 Especicando o Curso Tpico e os Cursos Alternativos . . . . . . . . . . . . 4.4 Erros Frequentes e Ms Prticas de Modelagem . . . . . . . . . . . . . . . 4.5 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Exerccios Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramas de Classes: Conceitos e Elementos Bsicos da Notao 5.1 Perspectivas em Diagramas de Classes . . . . . . . . . . . . . . 5.2 Classes Conceituais ou de Entidade . . . . . . . . . . . . . . . . 5.3 Atributos das Classes . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Operaes das Classes . . . . . . . . . . . . . . . . . . . . . . . 5.5 Restries e Responsabilidades . . . . . . . . . . . . . . . . . . 5.6 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Exerccios Propostos . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Diagramas de Classes: Relacionamentos Entre Classes, Classes de Associao, Interfaces e Restries 6.1 Relacionamentos Entre Classes . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Associaes Entre Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Papis nas Associaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Multiplicidades nas Associaes . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Navegabilidade nas Associaes . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Autoassociaes de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Multiplicidades no Projeto e na Implementao . . . . . . . . . . . . . . 6.8 Especializaes-Generalizaes . . . . . . . . . . . . . . . . . . . . . . . . 6.9 Conjuntos de Generalizao e Parties . . . . . . . . . . . . . . . . . . . 6.10 Agregaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11 Agregaes Compostas (ou Composies) . . . . . . . . . . . . . . . . . . 6.12 Classes de Associao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.13 Operaes Abstratas, Interfaces e Dependncia . . . . . . . . . . . . . . 6.14 A Especicao de Restries nos Modelos . . . . . . . . . . . . . . . . . 6.15 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

71 72 72 73 75 75 76 77 78 82 85 86 88 92 93 95

6.16 Exerccios Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 7 Diagramas de Mquina de Estados 7.1 Conceitos Iniciais Importantes . . . . . . . 7.2 Estados . . . . . . . . . . . . . . . . . . . . . 7.3 Pseudoestados Iniciais . . . . . . . . . . . . 7.4 Estados Finais . . . . . . . . . . . . . . . . . 7.5 Eventos, Condies e Aes em Transies 7.6 Estados Compostos . . . . . . . . . . . . . . 7.7 Atividades e aes em DMEs . . . . . . . . . 7.8 DMEs e Diagramas de Casos de Uso . . . . 7.9 Resumo do Captulo . . . . . . . . . . . . . . 7.10 Exerccios Propostos . . . . . . . . . . . . . . 99 . 100 . 102 . 104 . 105 . 106 . 111 . 115 . 115 . 116 . 117 121 . 122 . 123 . 125 . 128 . 129 . 130 . 131 . 132 . 133 . 133 . 137 . 141 . 142 145 . 146 . 149 . 151 . 152 . 155 . 156 . 159 . 160 . 161

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Diagramas de Atividade 8.1 Atividades e Aes em DAs . . . . . . . . . . . . . . . 8.2 Ns de Deciso (Desvios) e Qualicao de Fluxos . 8.3 Separaes e Junes . . . . . . . . . . . . . . . . . . 8.4 Parties . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Fluxos de Objetos . . . . . . . . . . . . . . . . . . . . 8.6 Atividades Aninhadas . . . . . . . . . . . . . . . . . . 8.7 Sinais e Eventos Temporais . . . . . . . . . . . . . . . 8.8 Fim de Fluxo ou Cancelamento . . . . . . . . . . . . 8.9 Conectores . . . . . . . . . . . . . . . . . . . . . . . . 8.10 Pinos, Transformaes e Regies de Expanso . . . 8.11 Especicando Gracamente Casos de Uso com DAs 8.12 Resumo do Captulo . . . . . . . . . . . . . . . . . . . 8.13 Exerccios Propostos . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

Diagramas de Sequncia: Conceitos Bsicos 9.1 Especicando Interaes por Meio de Diagramas . . . 9.2 Cenrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 O Ciclo de Vida dos Objetos . . . . . . . . . . . . . . . . 9.4 Responsabilidades, Atributos e Operaes dos Objetos 9.5 O Trip da Anlise . . . . . . . . . . . . . . . . . . . . . . 9.6 As Dimenses dos Diagramas de Sequncia . . . . . . . 9.7 Nvel de Detalhamento dos Diagramas de Sequncia . 9.8 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . 9.9 Exerccios Propostos . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

10 Diagramas de Sequncia: Mensagens, Quadros de Interao, Controladores e Interfaces 163

10.1 As Mensagens de Chamada . . . . . . . . . . . . . . 10.2 Mensagens de Criao e Destruio de Objetos . . . 10.3 Mensagens de Retorno . . . . . . . . . . . . . . . . . 10.4 Chamadas Assncronas . . . . . . . . . . . . . . . . . 10.5 Parmetros das Chamadas . . . . . . . . . . . . . . . 10.6 Quadros de Interao . . . . . . . . . . . . . . . . . . 10.7 Falando Um Pouco Mais Sobre a Criao de Objetos 10.8 Objetos Controladores . . . . . . . . . . . . . . . . . 10.9 Objetos de Interface . . . . . . . . . . . . . . . . . . . 10.10Resumo do Captulo . . . . . . . . . . . . . . . . . . . 10.11Exerccios Propostos . . . . . . . . . . . . . . . . . . . 11 Diagramas Complementares 11.1 Diagramas de Viso Geral da Interao 11.2 Diagramas de Pacotes . . . . . . . . . . 11.3 Diagramas de Componentes . . . . . . 11.4 Diagramas de Instalao . . . . . . . . 11.5 Palavras-Chave . . . . . . . . . . . . . . 11.6 Resumo do Captulo . . . . . . . . . . . 11.7 Exerccios Propostos . . . . . . . . . . . A Solues dos Exerccios Propostos A.1 Exerccios do Captulo 2, pgina 23: . . A.2 Exerccios do Captulo 3, pgina 41: . . A.3 Exerccios do Captulo 4, pgina 57: . . A.4 Exerccios do Captulo 5, pgina 69: . . A.5 Exerccios do Captulo 6, pgina 96: . . A.6 Exerccios do Captulo 7, pgina 117: . A.7 Exerccios do Captulo 8, pgina 142: . A.8 Exerccios do Captulo 9, pgina 161: . A.9 Exerccios do Captulo 10, pgina 179: A.10 Exerccios do Captulo 11, pgina 196:

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. 164 . 165 . 167 . 169 . 171 . 172 . 175 . 176 . 176 . 178 . 179 183 . 184 . 187 . 189 . 192 . 193 . 194 . 196 199 . 199 . 200 . 203 . 210 . 211 . 216 . 219 . 222 . 226 . 232 241 . 241 . 243 . 246 . 248

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

B Minimundos Completos B.1 Peixaria Q-Sereia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Empresa 5-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 Sistema de Controle de Ordens de Servio Refrigerao ManutAir B.4 Sistema de Acompanhamento de Entregas da Rapido Espacial . .

. . . .

. . . .

. . . .

C Solues dos Minimundos Completos 253 C.1 Peixaria Q-Sereia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 C.2 Empresa 5-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

C.3 Sistema de Controle de Ordens de Servio Refrigerao ManutAir . . . . 263 Referncias Bibliogrcas ndice Remissivo 283 285

L ISTA DE F IGURAS
2.1 2.2 O ciclo de vida do software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 A tecnologia ajuda na aplicao da metodologia e da disciplina para a manuteno do planejamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Casos de uso de negcio e casos de uso de sistema sendo executados no posto do INSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de casos de uso de um Sistema de Registro de Vendas e Devolues de um supermercado hipottico. . . . . . . . . . . . . . . . . . . . . Multiplicidades nas pontas das associaes entre atores e casos de uso. . . Especializao-generalizao de atores. . . . . . . . . . . . . . . . . . . . . . Especializao-generalizao de casos de uso. . . . . . . . . . . . . . . . . . Relacionamento de incluso entre casos de uso. . . . . . . . . . . . . . . . . Relacionamento de extenso entre casos de uso. . . . . . . . . . . . . . . . . Uso de incluso e extenso quando a incluso ocorre obrigatoriamente ou no obrigatoriamente, respectivamente, segundo as regras de negcio. . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

. 27 . . . . . . 29 34 35 36 38 39

. 40

4.1 5.1 5.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8

Leiaute tpico do formulrio de descrio de casos de uso. . . . . . . . . . . . 48 Nveis de abstrao em uma especicao. . . . . . . . . . . . . . . . . . . . . 62 Diagrama de classes conceitual da empresa ctcia ZYX. . . . . . . . . . . . . 63 Nomes de associaes e direes de leitura. . . . . . . . . . . . . . . . . . . . Rtulo de papel ajudando no signicado da associao. . . . . . . . . . . . . Autoassociao chefe-subordinado. . . . . . . . . . . . . . . . . . . . . . . . . A autoassociao do matrimnio. . . . . . . . . . . . . . . . . . . . . . . . . . Modelo de classes conceitual do Sistema de Controle de Galinhas e Ovos SCGO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relacionamento de generalizao-especializao representado pela seta de ponta vazada (trecho da Figura 5.2). . . . . . . . . . . . . . . . . . . . . . . . Generalizao-especializao representada na forma direta ou oblqua. . . Generalizao-especializao representada na forma retilnea. . . . . . . . 10 . . . . 73 74 76 76

. 77 . 79 . 80 . 81

6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 6.19 6.20 6.21 6.22 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 8.1 8.2 8.3 8.4 8.5

Atributos privado (a) e protegido (b) de classes especializadas denindo acessos distintos a objetos das classes que especializam. . . . . . . . . . . . . Conjuntos de generalizao em diagramas de classes. . . . . . . . . . . . . . . Parties em especializaes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relacionamento de agregao funcionrio-dependente. . . . . . . . . . . . . Relacionamento de agregao time-jogador. . . . . . . . . . . . . . . . . . . . Relacionamento departamento-diviso-coordenao. . . . . . . . . . . . . . . Agregao composta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Composies denindo excludncia mtua de instncias de associao. . . . Associao de emprego entre uma pessoa e uma empresa. . . . . . . . . . . . Classe de associao contendo atributos e operaes relativas a uma associao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoo da classe da associao C classe cheia. . . . . . . . . . . . . . . . . Alternativa para armazenar o histrico dos salrios mantendo o uso de classe de associao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de interface e classes de realizao dessa interface. . . . . . . . . . . Forma alternativa de especicao de associaes mutuamente excludentes. Diagrama de mquina de estados para os objetos da classe Pedido. . . . . . A autoassociao do matrimnio. . . . . . . . . . . . . . . . . . . . . . . . . . Duas formas de apresentao da caixa de estado em DMEs da UML. . . . . Rtulos indicando atividades nos estados (um detalhe da Figura 7.1). . . . . Crculo pequeno preenchido: smbolo grco de estado inicial na UML (um detalhe da Figura 7.1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "Olho de boi": smbolo grco de estado nal na UML (um detalhe da Figura 7.1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transies mtuas entre dois estados. . . . . . . . . . . . . . . . . . . . . . . Autotransio em DMEs da UML (um detalhe da Figura 7.1). . . . . . . . . . Nome do evento omitido, signicando o m da atividade do estado de origem (um detalhe da Figura 7.1). . . . . . . . . . . . . . . . . . . . . . . . . Condio omitida, signicando que a transio ocorre incondicionalmente (um detalhe da Figura 7.1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estados e seus subestados: um detalhamento da Figura 7.7. . . . . . . . . . Estados concorrentes dos objetos da classe Pedido da ZYX. . . . . . . . . . Diagrama de classes de conceito do Hotel Cincoestrelas. . . . . . . . . . . . DA da atividade Organizar Pedido. A atividade do diagrama executada pelo estoquista da ZYX, nossa empresa ctcia. . . . . . . . . . . . . . . . . . Ns de deciso em diagramas de atividade (um detalhe da Figura 8.1). . . . O processamento de pedidos na empresa ctcia ZYX. . . . . . . . . . . . . . Parties hierarquizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parties hierarquizadas e em duas dimenses. . . . . . . . . . . . . . . . . .

82 83 84 85 86 86 87 88 89 89 90 91 93 94

. 101 . 102 . 103 . 103 . 105 . 105 . 107 . 108 . 110 . 110 . 112 . 114 . 118

. 124 . 126 . 127 . 129 . 130

8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16

Atividade aninhada em outra (um detalhe da Figura 8.3). . . . . . . . . . . . Envio e recepo de sinais (um detalhe da Figura 8.3). . . . . . . . . . . . . . Representao de eventos temporais na UML. . . . . . . . . . . . . . . . . . Exemplo de m de uxo e recepo de sinal (detalhes da Figura 8.3. . . . . Outro exemplo de m de uxo. . . . . . . . . . . . . . . . . . . . . . . . . . . Modelos com signicados idnticos, sem conectores (a) e usando conectores (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pinos como forma de passagem de parmetros entre aes (a) e a notao equivalente de uxo de objetos (b). . . . . . . . . . . . . . . . . . . . . . . . . Transformao aplicada sobre parmetro de sada de uma ao. . . . . . . . Regio de expanso para execuo de sequncia de aes em paralelo. . . . Especicao de caso de uso apenas com aes correspondendo a aes do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Especicao de caso de uso com aes do sistema e do usurio em parties distintas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramas de sequncia (a) e de comunicao (b) especicando uma colaborao entre trs objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de atividade facilitando a identicao visual de cenrios. Cenrio 1: aes A e C. Cenrio 2: aes A, D e G. Cenrio 3: aes A, B e F. Cenrio 4: aes A, B e E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incorporao de classe de projeto ao diagrama conceitual. . . . . . . . . . . Diagramas de sequncia na formao de modelos completos de sistemas de software. Os nmeros entre parnteses correspondem ordem segundo a qual cada informao tratada no processo de construo do cdigo para o sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O ciclo de vida de um objeto representado em um diagrama de sequncia. Trecho do diagrama da ZYX no nvel de especicao. . . . . . . . . . . . . .

. 130 . 131 . 132 . 132 . 133 . 134 . 135 . 135 . 136 . 139 . 140

9.1 9.2

. 148

9.3 9.4

. 150 . 154

9.5 9.6

. 156 . 159 . 162 . 165 . 165 . 166 . 166 . 168 . 168 . 169 . 170

10.1 Mensagem de chamada entre dois objetos. . . . . . . . . . . . . . . . . . . . 10.2 Autodelegao da operao op2 pelo objeto B. . . . . . . . . . . . . . . . . . 10.3 Mensagens de solicitao de criao de objetos ilustrando as caixas de identicao dos objetos alinhadas com as mensagens. . . . . . . . . . . . . . . 10.4 Mensagens de solicitao de criao de objetos ilustrando as caixas de identicao dos objetos alinhadas com as mensagens. . . . . . . . . . . . . . . 10.5 Omisso das mensagens de retorno e das caixas de ativao, sem prejuzo de expressividade e de preciso. . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6 Diagrama equivalente ao da Figura 10.5, agora com as mensagens de retorno representadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7 Diagrama equivalente aos das Figuras 10.6 e 10.5, agora com as caixas de ativao representadas alm das mensagens de retorno. . . . . . . . . . . . 10.8 Especicao de uma colaborao usando chamadas assncronas. . . . . .

10.9 Quadro loop para especicar repeties. . . . . . . . . . . . . . . . . . . . . 10.10Colaborao opcional especicada por um quadro opt. . . . . . . . . . . . . 10.11Colaboraes alternativas especicadas por um quadro alt. . . . . . . . . . 10.12Diagrama de classes da ZYX contemplando prazo e preo de fornecimento. 11.1 Diagrama de atividade especicando uma atividade hipottica. . . . . . . . 11.2 Diagrama de viso geral da interao, especicando as colaboraes necessrias para a realizao das aes do DA da Figura 11.1. . . . . . . . . 11.3 Uso de pacotes na organizao dos atores de um sistema. . . . . . . . . . . . 11.4 Dependncia entre pacotes em um diagrama de pacotes. . . . . . . . . . . . 11.5 Dependncia entre pacotes realizada atravs de classes de interface. . . . . 11.6 Notao grca de componentes, ilustrando as interfaces fornecida (pelo componente AutenticacaoUsuario) e exigida (pelo componente ControleClientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.7 Transformao de relacionamentos de dependncia em notao de interfaces fornecidas e exigidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8 Sistema cliente-servidor com comunicao por HTTP. . . . . . . . . . . . . 11.9 O diagrama de classes de especicao da ZYX. . . . . . . . . . . . . . . . . . A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12 A.13 A.14 A.15 A.16 A.17 A.18 O atendente, a concluso das OS e o SCR. . . . . . . . . . . . . . . . . . . . . A entrega de documentos impressos. . . . . . . . . . . . . . . . . . . . . . . . Dados do cliente como passos da descrio do caso de uso. . . . . . . . . . Atores distintos participando de casos de uso distintos. . . . . . . . . . . . . Ator associado ao caso de uso base e ao que estende. . . . . . . . . . . . . . Caso de uso executado por um ator ou possivelmente durante a execuo de outro caso de uso por outro ator. . . . . . . . . . . . . . . . . . . . . . . . . Usando o mecanismo de agendamento do Sistema Operacional como ator. Complexidade "escondida"em um caso de uso. . . . . . . . . . . . . . . . . . O registro de compra em um supermercado. . . . . . . . . . . . . . . . . . . Ambiente Acadmico do Municpio de Sertozinho Alegre. . . . . . . . . . . Modelo da soluo para o sistema de controle de uma biblioteca. . . . . . . Modelo da soluo para o editor grco. . . . . . . . . . . . . . . . . . . . . . Modelo da soluo para transformao de classe de associao para classe cheia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelo da soluo para dependncia entre pacotes. . . . . . . . . . . . . . . Modelo da soluo para tornarmos mutuamente excludentes instncias de associaes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de mquina de estados para objetos da classe Apartamento do Hotel Cincoestrelas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estados Reservado, Ocupado e Livre como subestados do estado Operacional na soluo para o exerccio do Hotel Cincoestrelas. . . . . . . Um exemplo de aes executadas em uma manh tpica. . . . . . . . . . . .

. 173 . 173 . 175 . 180 . 185 . 186 . 188 . 189 . 190

. 191 . 192 . 193 . 197 . 201 . 201 . 201 . 202 . 203 . 204 . 204 . 205 . 206 . 212 . 214 . 215 . 216 . 216 . 217 . 218 . 219 . 220

A.19 Exemplo de aes para o tratamento de eventos temporais. . . . . . . . . . A.20 Soluo para a especicao na forma grca do caso de uso Registrar Compra Parte I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.21 Soluo para a especicao na forma grca do caso de uso Registrar Compra Parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.22 Uma soluo para o clculo do Lucro Lquido da ZYX. . . . . . . . . . . . . . A.23 A mesma soluo que a da Figura A.22 para o clculo do Lucro Lquido da ZYX, porm com outra ordem de apresentao dos objetos na dimenso horizontal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.24 Uma soluo de colaborao para obteno do prazo de entrega de um pedido feito ZYX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.25 Uma soluo mais completa de colaborao para obteno do prazo de entrega de um pedido feito ZYX. . . . . . . . . . . . . . . . . . . . . . . . . . . A.26 Uma soluo para a colaborao do caso de uso Efetuar Pedido. . . . . . A.27 Relacionamento de dependncia entre as classes de interface (formulrio), controladora e conceitual resultantes da realizao do caso de uso Efetuar Pedido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.28 Diagrama de atividade parcial especicando os passos do caso de uso Efetuar Pedido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.29 Primeira parte do diagrama de viso geral da interao especicando as aes do DA da Figura A.28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.30 Segunda parte do diagrama de viso geral da interao especicando as aes do DA da Figura A.28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.31 Classes da ZYX agrupadas em pacotes. . . . . . . . . . . . . . . . . . . . . . . A.32 Diagrama de pacotes de classes da ZYX. . . . . . . . . . . . . . . . . . . . . . A.33 Diagrama de distribuio dos sistemas da ZYX. . . . . . . . . . . . . . . . . . C.1 Diagrama de casos de uso da Peixaria Q-Sereia. . . . . . . . . . . . . . . . . . C.2 Diagrama de classes de nvel conceitual da Peixaria Q-Sereia. . . . . . . . . C.3 Diagrama de atividade especicando as aes do sistema da Peixaria QSereia no caso de uso 01-Cadastrar Misso. . . . . . . . . . . . . . . . . . C.4 Diagrama de atividade especicando as aes do sistema da Peixaria QSereia no caso de uso 02-Cadastrar Embarcao. . . . . . . . . . . . . . . C.5 Diagrama de mquina de estados para embarcaes prprias da Peixaria Q-Sereia: primeira soluo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.6 Diagrama de mquina de estados para embarcaes prprias da Peixaria Q-Sereia: segunda soluo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.7 Diagrama de mquina de estados para embarcaes prprias da Peixaria Q-Sereia: terceira soluo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.8 Diagrama de sequncia para o caso de uso Cadastrar Embarcao da Peixaria Q-Sereia curso tpico. . . . . . . . . . . . . . . . . . . . . . . . . . .

. 221 . 223 . 224 . 227

. 227 . 228 . 229 . 230

. 232 . 233 . 234 . 235 . 237 . 238 . 239 . 254 . 259 . 260 . 261 . 262 . 263 . 264 . 265

C.9 Diagrama de sequncia para o caso de uso Cadastrar Misso da Peixaria Q-Sereia curso tpico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.10 Diagrama de classes de especicao da Peixaria Q-Sereia. . . . . . . . . . . C.11 Diagrama de casos de uso da Empresa 5-E. . . . . . . . . . . . . . . . . . . . C.12 Diagrama de classes de conceito da Empresa 5-E. . . . . . . . . . . . . . . . C.13 Diagrama de mquina de estados para os objetos da classe Contrato da Empresa 5-E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.14 Diagrama de casos de uso da ManutAir. . . . . . . . . . . . . . . . . . . . . . C.15 Diagrama de classes de especicao da Empresa ManutAir. . . . . . . . . . C.16 Diagrama de atividade especicando as aes do sistema da ManutAir no caso de uso 01-Cadastrar Contrato. . . . . . . . . . . . . . . . . . . . . . . C.17 Diagrama de atividade especicando as aes do sistema da ManutAir no caso de uso 02-Abrir OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.18 Diagrama de sequncia para o caso de uso 01-Cadastrar Contrato da ManutAir curso tpico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.19 Diagrama de sequncia para o caso de uso 02-Abrir OS da ManutAir curso tpico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. 266 . 267 . 268 . 269 . 275 . 276 . 277 . 278 . 279 . 280 . 281

L ISTA DE TABELAS
3.1 4.1 4.2 4.3 4.4 Exemplos do que usar e do que no usar como nomes de atores. . . . . . . . 30 Exemplo de tabela de regras de negcio. . . . . . . . . . . . . . . . . . . . . . Exemplo de descrio de caso de uso de troca de senha de acesso (cabealho e curso tpico). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de descrio de caso de uso de troca de senha de acesso (cursos alternativos e de exceo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de descrio de casos de uso ilustrando repeties e referncia a outro caso de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 . 50 . 51 . 52

6.1 7.1 9.1

Denindo os nomes de associaes entre classes. . . . . . . . . . . . . . . . . 96 Atividades e aes em DMEs da UML. . . . . . . . . . . . . . . . . . . . . . . . 115 Correlao entre os principais conceitos de processos de negcios e orientao a objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

10.1 Operadores comumente usados em quadros de interao. . . . . . . . . . . . 174 10.2 Tabela de descrio parcial do caso de uso Efetuar Pedido. . . . . . . . . . 181 A.1 A.2 A.3 A.4 Descrio abreviada do caso de uso Registrar Compra. . . . . . . . . . . . Descrio detalhada do caso de uso Registrar Compra (incio). . . . . . . Descrio detalhada do caso de uso Registrar Compra (nal). . . . . . . . Responsabilidades de cada classe na realizao da colaborao do Exerccio 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descrio do caso de uso 01-Cadastrar Misso, 1. parte. . . . . . . . . . Descrio do caso de uso 01-Cadastrar Misso, 2. parte. . . . . . . . . . Descrio do caso de uso 02-Cadastrar Embarcao, 1. parte. . . . . . . Descrio do caso de uso 02-Cadastrar Embarcao, 2. parte. . . . . . . . . Descrio do caso de uso 03-Cadastrar Tripulante Terceiro. . . . . . . . . . . Descrio do caso de uso 01-Cadastrar Contrato da Empresa ManutAir, 1. parte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . 207 . 208 . 209 . 226 . 255 . 256 . 257 . 258 . 258 . 270

C.1 C.2 C.3 C.4 C.5 C.6

C.7 Descrio do caso de uso 01-Cadastrar Contrato da Empresa ManutAir, 2. parte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.8 Descrio do caso de uso 02-Abrir OS da Empresa ManutAir, 1. parte. . . C.9 Descrio do caso de uso 02-Abrir OS da Empresa ManutAir, 2. parte. . . C.10 Descrio do caso de uso 02-Abrir OS da Empresa ManutAir, 3. parte. . .

. 271 . 272 . 273 . 274

L ISTA DE S IGLAS
CA CASE CMMI CT DA DER DFD DME DS ECA MER OCL OMG OO OOAD SGBD
Curso Alternativo Computer-Aided Software Engineering Engenharia de Software Ajudada por Computador Capability Maturity Model Integration Integrao do Modelo de Nvel de Maturidade Curso Tpico Diagrama de Atividades Diagrama de Entidades e Relacionamentos Diagrama de Fluxos de Dados Diagrama de Mquina de Estados Diagrama de Sequncia Evento, Condio e Ao Modelo de Entidades e Relacionamentos ou Modelo Entidades-Relacionamentos Object Constraint Language Linguagem (de Especicao) de Restries de Objetos Object Management Group Grupo de Gerncia de Objetos Orientao a Objetos Object-Oriented Analysis and Design Anlise e Projeto Orientados a Objetos Sistema de Gerenciamento de Banco de Dados 19

UML XMI[DI] XMI XML

Unied Modeling Language Linguagem Unicada de Modelagem XML Metadata Interchange, Diagram Interchange Intercmbio de Diagramas com XML Metadata Interchange Intercmbio de Metadados com XML Extensible Markup Language Linguagem Extensvel de Marcao

20

P REFCIO
A Linguagem Unicada de Modelagem (em ingls Unied Modeling Language UML) foi concebida com o intuito de estabelecer um padro nico a ser usado para a especicao das caractersticas dos sistemas de software projetados para atender s necessidades dos usurios desses sistemas. A linguagem comeou a ser denida em novembro de 1997 e rapidamente se tornou um padro de facto, causando grande impacto na maneira como os sistemas de software vm sendo desenvolvidos, sendo usada para a comunicao entre membros da equipe de desenvolvimento, na discusso e especicao de solues, e entre eles e os usurios, como recurso de especicao do que para ser feito. A UML tambm vem sendo usada como especicao com vistas gerao automtica de cdigo com base no modelo, de forma modular e com altos ndices de reso. A importncia que a UML assumiu no contexto de desenvolvimento de sistemas, fez com que o curso de Anlise, Projeto e Gerncia de Sistemas APGS e o seu sucessor, o de Anlise e Projeto de Sistemas APS , da PUC-Rio, dedicasse uma parte signicativa do programa ao estudo terico e prtico desse assunto, mesclado, como no podia deixar de ser, com as questes relativas s disciplinas de anlise e projeto de sistemas de computao. O que apresento neste texto uma reunio das questes que venho discutindo em sala com os alunos da disciplina de Mtodos de Anlise de Sistemas MAS desses dois cursos. O assunto "anlise de sistemas" tratado na medida em que a necessidade vem surgindo, enquanto explico modelagem. Eu busquei relacionar e organizar os assuntos da maneira que fui percebendo ser a mais conveniente para a apresentao aos alunos (na maioria iniciantes em UML), no s pela ordem tipicamente empregada dos diagramas em um projeto e a relevncia no contexto de desenvolvimento de sistemas, como tambm pelos interesses despertados por eles em sala de aula. Assim sendo, se voc quer iniciar os estudos em UML, sugiro que leia o texto na ordem em que os assuntos so apresentados. Talvez voc considere o texto um tanto extenso, mas ele contm um resumo da UML, cuja especicao longa porque precisa ser detalhada e porque a UML

21

 extensa e objetiva ser abrangente e completa. Com isso, parece bvio que, em pouco mais de duzentas pginas, bastante difcil tratar completamente o que a especicao da UML trata em mais de mil pginas; e isso sem passar as dicas, tcnicas e melhores prticas de anlise e modelagem de sistemas que procuro passar ao longo dos estudos. Eu vejo o texto como uma "partida rpida" para os que querem se familiarizar com a linguagem e aplicar os conhecimentos mais imediatamente em seus projetos. O que tratado no texto tambm pode ser entendido como uma viso de alto nvel, um panorama, para os que querem se aprofundar no estudo da UML. Espero que esse texto seja til de alguma forma em sua atividade de anlise e modelagem de sistemas. Luiz Antnio

22

CAPTULO

I NTRODUO
Failing to plan is planning to fail. Alan Lakein

1.1 A Motivao Para Esta Apostila

Ns desenvolvemos planos a todo instante, pessoal e prossionalmente, para executarmos tarefas simples a mais complexas. Planejamento faz parte de nosso diaa-dia. Os planos que desenvolvemos envolvem a especicao das etapas que os compem, que pode ser feita mentalmente ou de forma mais elaborada e detalhada, dependendo da complexidade e criticidade envolvidas. Especicar o plano a atividade quase sempre consequente atividade de planejamento. Como exemplos, quando nos propomos a realizar uma viagem a passeio, sabemos que importante estabelecer, de antemo, roteiros, metas atingveis, determinar custos, juntar os recursos necessrios, avaliar alternativas e os riscos de atrasos no trajeto. necessrio denirmos um plano de atividades e ouvirmos a experincia de vrias pessoas, dentre outras medidas. Desejamos, com isso, aumentar as chances da viagem ser um sucesso, certo? Boa parte desse esforo pode ser deixada a cargo de um funcionrio de uma agncia de turismo, com quem conversamos 1

CAPTULO 1. INTRODUO

rapidamente por telefone, expondo (especicando) nossas expectativas. O plano pronto pela agncia vem especicado por meio de locais, atividades e demais detalhes que comporo nossa viagem. Quando queremos construir nossa casa, temos que ser bem mais rigorosos quanto especicao do que queremos. Nesse caso, um papo por telefone com um arquiteto j no basta para escalonar as etapas, levantar custos, denir prazos etc. As eventuais perdas, no caso de um insucesso na construo da casa, tendem a ser bem maiores do que no caso da viagem. Por essa razo, para que os detalhes do projeto quem bem entendidos por todos, os prossionais que prestaro os diversos servios durante o projeto e a obra trocaro informaes usando os modelos e o jargo prprios da rea, ou seja, por meio de modelos e especicaes mais estruturadas e precisas do que simples conversas por telefone. Para o projeto e construo de um novo automvel ou navio, de um prdio, de uma ponte ou de uma rodovia (para a execuo de qualquer obra de engenharia de grande porte), fundamental reunir um conjunto bastante extenso de desenhos, especicaes, recomendaes, alm de estabelecer a priori processos de projeto e de construo. Deveremos contar com etapas bem denidas e pontos de controle intermedirios para a vericao do andamento e para a medio da qualidade do que est sendo produzido e do processo de produo propriamente dito. Como curiosidade, para a construo e montagem da usina hidreltrica de Itaipu foram empregadas, desde a elaborao e as revises de seu projeto, cerca de 1.200.000 folhas de desenho e listas de materiais. Essa documentao, superposta, seria suciente para erguer uma pilha com altura equivalente a um prdio de 50 andares1 . Alm dos modelos "em papel", outros modelos tambm foram construdos para estudar e validar inmeros aspectos da engenharia da barragem, dentre eles o modelo reduzido construdo em Curitiba. Modernamente entende-se que o desenvolvimento de software tambm deve ser uma atividade de resultados previsveis quanto aos prazos, preos, qualidade e nveis de atendimento s necessidades da clientela. Muitos programas de computador, no entanto, ainda tm sido construdos sem planejamento, sem especicao de como sero feitos e mesmo sem especicao do que ser feito. Isso vem de encontro aos fatos de que as sociedades modernas esto cada vez mais dependentes da informtica e que a complexidade e a criticidade dos sistemas tm aumentado, no havendo mais espao para improvisaes e para trabalho amador. Como consequncia, o cuidado com o projeto e a documentao e o controle dos custos, prazos e qualidade vm ganhando importncia na construo de sistemas de software, que vem se tornando cada vez mais uma atividade de engenharia, uma obra de engenharia. Neste texto apresentaremos os principais diagramas da Linguagem Unicada de Modelagem Unied Modeling Language - UML para o planejamento e a
1

Fonte: Itaipu Binacional.

1.2. SOBRE FERRAMENTAS CASE

especicao dos aspectos conceituais de sistemas de software, de forma a podermos, em sntese, estruturar o resultado de nosso trabalho e encaix-lo em uma atividade maior, que envolve todas as etapas da engenharia de construo desses sistemas. Este texto foi desenvolvido para dar suporte s minhas aulas na PUC-Rio e segue muito de perto a ordem de apresentao dos assuntos em sala de aula. , em linhas gerais, uma organizao dos assuntos tratados em sala.

1.2 Sobre Ferramentas CASE

Uma dvida que os alunos dos cursos de UML que ministro na PUC-Rio tipicamente tm diz respeito necessidade de uso de uma ferramenta de desenho dos modelos e, havendo, qual eles devem usar. Os modelos podem, claro, ser desenvolvidos utilizando papel e lpis. As ferramentas de software, no entanto, permeiam a quase totalidade dos ambientes de trabalho nas mais diversas reas da atividade humana, dando suporte organizado ao planejamento, metodologia e disciplina, que so componentes essenciais de qualquer ambiente produtivo. Modelagem de sistemas se insere nesse contexto. Para a modelagem de sistemas utilizando a UML, usualmente empregamos ferramentas CASE (Computed-Aided Software Engineering engenharia de software auxiliada por computador), apelidadas simplesmente de CASEs. Nas boas ferramentas, todos os elementos de notao que normalmente precisamos esto disponveis, inclusive nas verses gratuitas, as chamadas verses "comunidade", ou community, em ingls. Simples editores grcos, que permitem manipular "caixinhas e bolinhas" numa tela grca, j possuem vantagens em relao ao uso de papel e lpis, por conta de facilitar a experimentao necessria durante a modelagem. CASEs, no entanto, so mais do que isso. O que faz a diferena real no uso dos CASEs para modelagem de sistemas o suporte organizado ao processo de modelagem que mencionamos, por conta da garantia que eles normalmente do de que o modelo gerado est sintaticamente correto e de que os diversos diagramas que compem o modelo esto consistentes entre si. Por exemplo, se dois determinados atores esto relacionados entre si por generalizao/especializao em um diagrama, esse relacionamento representado automaticamente pelo CASE em todos os demais diagrama do modelo onde eles aparecerem. Caso removamos esse relacionamento em um diagrama, todas as representaes desse relacionamento nos demais diagramas sero automaticamente removidas. Alm disso, CASEs no permitem que atribuamos um identicador j existente a um novo elemento do modelo em um mesmo espao de nomes . CASEs tambm no devem permitir que estabeleamos associaes entre

4 dois atores, o que vedado pela UML.

CAPTULO 1. INTRODUO

H vrios CASEs de qualidade no mercado. Apenas a ttulo de exemplo, podemos citar o Astah (que o sucessor do Jude), o Magic Draw e o Enterprise Architect, alguns deles com verses community (gratuitas) e professional, e outros com verses de preos bem acessveis, variando entre US100eU S 200 por cpia. Eu acho muito importante que voc use uma ferramenta CASE em suas atividades de modelagem. Sugiro que voc baixe e instale o Astah verso community, que gratuito, opera sobre o Windows, Linux e MacOS, pois escrito em Java, e possui recursos sucientes para a maioria das necessidades de modelagem. Eu farei comentrios sobre os recursos e limitaes mais importantes e comuns dos CASEs. Lembre-se, no entanto, de que nossa apostila no sobre CASE, e sim sobre anlise e modelagem com UML.

1.3 Bibliograa Adicional Recomendada

Uma pergunta que quase invariavelmente me fazem no incio dos cursos sobre o que ler para complementar o que eu falo em sala. Uma primeira referncia, claro, esta apostila, cujo contedo pode ser quase totalmente associado em teor e forma aos tpicos que trato em sala. Como o que falo em sala segue, em linhas gerais, os caminhos j trilhados pelos grandes mestres de UML e de orientao a objetos em suas publicaes mais populares sobre esses assuntos, no posso deixar de mencionar essas fontes. Costumo recomendar trs livros, dependendo do tipo de informao em que o aluno est interessado. Se o aluno est interessado em uma viso aplicada da UML, mais informal e "coloquial" da linguagem, eu recomendo o livro UML Essencial ([5]), de Martin Fowler. Nesse livro relativamente no, Fowler coloca em evidncia, de forma bem pedaggica, sua experincia com o uso da UML em ambientes reais. O livro cobre basicamente os mesmos diagramas de que trataremos neste texto. Se o aluno est interessado em um material mais completo e mais alinhado com a especicao formal da UML, eu recomendo o livro UML Guia do Usurio ([1]), de Grady Booch, James Rumbaugh e Ivar Jacobson, autores que so vistos por muitos como as trs personalidades mais importantes da UML. Se o aluno est interessado em uma viso da UML em ambientes de desenvolvimento com o uso do Rational Unied Process (Processo Unicado da empresa Rational) RUP eu recomendo o livro Utilizando UML e Padres ([8]), de Craig Larman, outro grande conhecedor e divulgador de UML e orientao a objetos.

1.4. ORGANIZAO DESTE TEXTO

Esses trs livros so bem interessantes e, de alguma forma, se complementam. No entanto, caso voc queira um nico material impresso alm deste, eu recomendaria o livro do Fowler. No poderia deixar de comentar que a especicao da UML pode ser baixada da Internet gratuitamente. Essa especicao consiste de mais de mil pginas em arquivos .pdf, disponveis no stio do Object Management Group (Grupo de Gerncia de Objeto) OMG2 , grupo que gere o desenvolvimento da linguagem. No espere, no entanto, entender muito facilmente o que est descrito l, pois as informaes so colocadas sem levar em conta o aspecto pedaggico. A consulta especicao normalmente s feita no caso de uma dvida quanto a um detalhe ou outro da linguagem. Os dois principais documentos da especicao so o documento de infraestrutura ([10]) e o de superestrutura ([11]).

1.4 Organizao Deste Texto

Os demais assuntos tratados nesta apostila so organizados da seguinte maneira: No Captulo 2 fazemos uma reviso dos conceitos que, de maneira geral, motivam e esto associados aos propsitos de nosso texto. Tratamos de processos, mecanismos de estruturao e controle de processos de software, orientao a objetos (propriedades, responsabilidades, operaes e colaborao entre objetos), modelos, seus nveis de abstrao e os principais recursos para as suas elaboraes com vistas a prover a fundamentao para o restante do texto. Nos Captulos 3 e 4 tratamos de casos de uso. Inicialmente, no Captulo 3, apresentamos os conceitos e a notao para elaborao dos diagramas de casos de uso e, no Captulo 4, tratamos das especicaes escritas (descries) dos casos de uso. No Captulo 4 tambm chamamos a ateno para erros tpicos de modelagem e damos algumas dicas para a elaborao dos diagramas e das descries. Os diagramas de classes so tratados nos Captulos 5 e 6. Nesses dois captulos discutimos como identicar os conceitos, seus atributos e os relacionamentos que eles mantm entre si, alm de como elaborar diagramas de classes que os especicam. Os diagramas de mquina de estados e os diagramas de atividade so tratados nos Captulos 7 e 8, respectivamente. Embora a UML, a partir da verso 2.0, tenha desvinculado um do outro por conta do aumento de expressividade dos diagramas de atividade, ns mantemos a correlao entre os dois para facilitar a passagem e a assimilao dos conceitos. As especicidades e os detalhes na notao de cada diagrama so tratados dentro de um nvel de detalhamento e abrangncia que
2

Ver http://www.omg.org.

CAPTULO 1. INTRODUO

julgamos suciente para a modelagem conceitual de sistemas e, portanto, para os propsitos do texto. Os conceitos e notao dos diagramas de sequncia so abordados nos Captulos 9 e 10. Os diagramas de viso geral da interao, de pacotes, de componentes e de instalao so discutidos no Captulo 11, onde tambm falamos de palavras-chave (os antigos esteretipos da UML), ltimo tpico tratado neste texto. As solues comentadas dos exerccios propostos nos nais dos captulos se encontram no Apndice A. No Apndice B apresentamos alguns minimundos completos para a elaborao dos modelos UML, conforme haja disposio e disponibilidade de tempo do leitor. Finalmente, no Apndice C apresentamos as solues parciais para os minimundos do Apndice B.

CAPTULO
7

F UNDAMENTOS DA M ODELAGEM DE S ISTEMAS

I do not think much of a man who is not wiser today than he was yesterday. Abraham Lincoln

Os sistemas de software tm desempenhado um papel cada vez mais importante em nossas vidas e, em muitas situaes, o atendimento s necessidades dos usurios, questes de performance e o funcionamento correto ou incorreto desses sistemas pode fazer a diferena entre manter a vida ou causar a morte de algum. Por outro lado, os custos e os prazos de seu desenvolvimento tambm constituem preocupaes para os patrocinadores, os projetistas e os construtores desses sistemas. Inmeras variveis contribuem para o sucesso ou o insucesso de um projeto de desenvolvimento de software: a complexidade tcnica, a disponibilidade de pessoal capacitado e motivado para a gerncia e para as demais atividades necessrias ao desenvolvimento do projeto, o emprego de tcnicas e tecnologias adequadas e o conhecimento do que para ser feito so apenas algumas delas. Neste captulo apresentaremos os conceitos envolvidos e outros aspectos relacionados a essas variveis: trataremos de qualidade, engenharia e processos de software, do uso da UML como linguagem de modelagem de sistemas. Trataremos,

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS

tambm, do uso de ferramentas CASE para dar suporte ao desenvolvimento. Nosso objetivo, em linhas bem gerais, a conscientizao quanto importncia do uso desses ingredientes para o desenvolvimento no preo, no prazo e com a qualidade esperados de um sistema de software. Comearemos pelo conceito de software.

2.1 O que Software, Anal?

H alguns anos ouvi algum dizendo que "software produto projetado e construdo pelos engenheiros de software". Se pararmos para pensar um pouco vemos que, por trs dessa denio, em princpio simplista, esto escondidas duas informaes importantes. A primeira delas diz respeito a processo de produo, por conta da associao entre as palavras software e engenharia, em aparente choque com a forma como a produo de software era entendida antigamente, sendo resultado de uma atividade quase totalmente criativa. A segunda informao trata do que consiste o software, sendo no apenas linhas de cdigo, mas o produto da atividade de desenvolvimento de software, que muito mais do que conjuntos de comandos, como era comumente entendido. Atualmente entendemos que software abrange programas de computador, dados e documentos, tangveis (manuais impressos, por exemplo) e eletrnicos (arquivos em .pdf, por exemplo). Sendo assim, os modelos em UML que desenvolveremos, que so representaes de conceitos por meio de guras, fazem parte do software. Esse material com que lidamos durante o ciclo de vida (Figura 2.1) do software chamamos de conjunto de artefatos1 que compem o software. O ciclo de vida de software compreende o tempo decorrido entre a percepo da necessidade do software e a sua retirada de produo. Muitos autores, no entanto, denem que o incio do ciclo de vida coincide com o incio do ciclo de desenvolvimento, quando iniciado o projeto de construo dele, incluindo anlise de viabilidade. A estrutura de chaves aninhadas a seguir ilustra o ciclo de vida, detalhando as etapas que compem o ciclo de desenvolvimento interno a ele e que, por sua vez, pode ser entendido como sendo composto por quatro fases: concepo, elaborao, construo e transio. A Figura 2.1 ilustra. Uma caracterstica importante do software que ele no desgasta, mas sim deteriora. Software deteriorado o que deixa de atender a todas as necessidades dos
Artefato qualquer documento ou arquivo produzido ou consumido durante o ciclo de vida de um software. Pode ser um mdulo de cdigo, um componente de software, um conjunto de dados de entrada de teste, um arquivo de modelo de uma ferramenta CASE, uma especicao textual em MSWord, um manual etc.
1

2.2. QUALIDADE DE SOFTWARE

Percepo da necessidade Concepo

Elaborao
Desenho Arquitetnico Desenho Detalhado Ciclo de Vida Desenvolvimento Construo Liberao Codificao Testes de Unidade Testes de Aceitao Transio Operao Retirada

Figura 2.1: O ciclo de vida do software.

usurios e, com isso, deixa de ser um produto de qualidade. Isso pode acontecer por vrios motivos. Relacionamos dois: 1. Mudana nas regras de negcio (leis, estatutos internos, boas prticas etc.); 2. Aumento dos dados a serem processados por expanso dos negcios. Como consequncia, isso aumenta o tempo de resposta do sistema, podendo torn-lo inaceitvel. A deteriorao neutralizada por correes feitas no cdigo, quando essas correes so possveis e viveis. Mencionamos a palavra qualidade relacionada a software. Esse um assunto importante, merecendo que o tratemos com maior profundidade.

2.2 Qualidade de Software

Suponha que ns contratamos o desenvolvimento de um sistema para um grupo de prossionais. Durante algum tempo mantivemos contatos com esse grupo no sentido de estabelecer o que o sistema deveria fazer, a quantidade de dados que ele precisaria processar na unidade de tempo, o padro dos usurios (tipicamente tratando da

10

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS

procincia dos usurios em informtica e de possveis limitaes fsicas), o ambiente operacional que deveria ser usado e restries diversas, dentre outros itens. O que esperamos de um servio prestado com qualidade que toda informao que passamos para a equipe de desenvolvimento fosse levada em considerao e que o produto nal estivesse de acordo com nossas necessidades. Pressman ([12]) considera que software de qualidade o que est em conformidade com:

Requisitos funcionais e de desempenho explicitamente estabelecidos; Padres de desenvolvimento explicitamente documentados; Caractersticas implcitas que so esperadas em todo software desenvolvido prossionalmente.

Pressman acredita que possuir as funcionalidades solicitadas (atender aos requisitos funcionais) a base para a medio da qualidade. Os padres de desenvolvimento explicitamente estabelecidos denem de antemo um conjunto de critrios que guiam o processo de desenvolvimento. Esses padres dizem respeito aos nomes de variveis, classes, componentes e pacotes, tratando inclusive da documentao e da forma de endentao e quebra de linhas dos programas. Isso torna o cdigo mais manutenvel (que possui a caracterstica de ser mais facilmente mantido) e elimina esse tipo de decises do processo de sua construo, tornando-o mais rpido. Algumas dessas falhas percebidas em um ou outro ponto colocam todo o software sob suspeio. Outra questo bastante ligada qualidade do produto a qualidade do processo de produo. Dizem que "de uma mesa organizada sai um bom trabalho", no sentido amplo de que, se o nosso ambiente de trabalho organizado (e nesse ambiente inclumos o processo que usamos para fazer algo), maior a chance de produzirmos algo de qualidade2 . Deve-se dar, portanto, mais nfase qualidade do processo de produo do software, na medida em que a qualidade do software vista quase como uma consequncia.
Voc se lembra do primeiro lme da srie O Parque dos Dinossauros? Lembra-se da desorganizao que era a mesa do "prossional" que desenvolveu o software que controlava os portes do parque? O objetivo era passar a sensao de que daquele ambiente desorganizado no sairia um resultado de qualidade como de fato aconteceu.
2

2.3. ENGENHARIA DE SOFTWARE

11

Existem vrios modelos de qualidade de processo, cada um com sua forma de medio da qualidade. Um deles o Capability Maturity Model Integration (integrao do modelo de nvel de maturidade) CMMI, que categoriza empresas em nveis de maturidade segundo os quais elas gerem seus processos de software. O CMMI organiza e auxilia a melhoria do processo de desenvolvimento de software em uma organizao e adotado, por exemplo, pelo departamento de defesa americano o DoD para avaliao de seus fornecedores de software.

2.3 Engenharia de Software

Segundo o IEEE (Institute of Electrical and Electronics Engineers), engenharia de software o estudo e a aplicao de procedimentos sistemticos, disciplinados e quanticveis ao desenvolvimento, operao e manuteno de software, ou seja, a aplicao de prticas de engenharia no desenvolvimento de software. A engenharia de software estabelece, portanto, que o ciclo de vida do software gerido por meio de processos bem comportados, envolvendo a denio, antes do incio do ciclo de desenvolvimento, das etapas do processo de desenvolvimento e produo (incluindo manuteno) e seus pontos de controle (os marcos), dos nveis de qualidade, dos custos e dos prazos. Assim, so trs os ingredientes que do suporte engenharia de software: o planejamento, a metodologia e a disciplina. O planejamento trata da denio das etapas, da sequncia de realizao dessas etapas, do estabelecimento das metas e dos recursos que sero utilizados, da denio da metodologia, das ferramentas e de tudo o mais que trata do que fazer no sistema e como fazer. A metodologia o conjunto de procedimentos e tcnicas que sero usadas, normalmente j estabelecidas por experincia anterior, pela academia ou pela instituio a qual estamos ligados. A disciplina o esforo que precisa ser desenvolvido no desenrolar do processo, no sentido de cumprir rigorosamente o planejamento, de acordo com a metodologia escolhida. Como os graus de complexidade dos projetos tm se tornado cada vez maiores, medida que as atividades que os compem so cada vez em maior nmero e se relacionam, no tempo, de forma cada vez mais intrincada, o ambiente deve contar com ferramentas que ajudam a aplicao da metodologia e da disciplina para a manuteno do planejamento. Com esse objetivo, so usados sistemas de controle de uxo de trabalho (workow), ferramentas de controle da comunicao, ferramentas CASE e ferramentas de gerncia de congurao, entre outras (Figura 2.2).

12

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS

Figura 2.2: A tecnologia ajuda na aplicao da metodologia e da disciplina para a manuteno do planejamento.

A UML compe a metodologia usada no planejamento de projetos de software orientados a objetos (OO). As ferramentas CASE fazem parte da tecnologia para a gesto do modelo UML.

2.4 Processos de Software

Parte da metodologia usada no planejamento de projetos de desenvolvimento de software trata do encadeamento das atividades tcnicas de levantamento e especicao das necessidades dos usurios, especicao da soluo (o sistema) dada pela equipe, construo dessa soluo, testes, treinamento e colocao do sistema em produo. A esse conjunto de atividades e sua ordenao no tempo damos o nome de processo (de construo) de software. Processo de software , em outras palavras, um conjunto de atividades, mtodos, prticas e transformaes que pessoas empregam para denir, desenvolver e manter o software. Lembre que software no apenas linhas de cdigo. Os produtos a ele associados, como plano do projeto, documentos do projeto, casos de teste, manuais do usurio etc., tambm fazem parte do software.

2.4. PROCESSOS DE SOFTWARE Um processo de software envolve: Pessoas com habilidades, treinamento e motivao;

13

Procedimentos e mtodos denindo o relacionamento entre as tarefas que fazem parte do processo; Ambiente adequado para gesto do processo, o que inclui as ferramentas de software (compiladores, programas de gesto da comunicao e da congurao, entre outros) e os equipamentos necessrios para processar as ferramentas e os demais itens de hardware. Qualquer processo de software possui, como vimos, uma srie de tarefas denidas que so organizadas de diferentes formas, de acordo com o modelo de processo adotado. Essas tarefas demandam marcos para vericao, documentao e garantia da qualidade do software. Os modelos de processos de software mais conhecidos so (a ordem no tem um signicado especial): Em cascata (ou clssico), que divide o ciclo de desenvolvimento em cinco fases: levantamento, anlise, projeto, implementao (tambm chamada codicao) e implantao3 . O processo em cascata possui um longo ciclo de desenvolvimento (tipicamente meses), ou seja, os programas so construdos e entregues bom tempo depois do levantamento das necessidades. Por isso, no muito usado atualmente, mas tem sido considerado como base para quase todos os modelos de processo, inclusive os mais usados atualmente, pois as atividades executadas continuam sendo necessrias, apenas mudando de nome e de forma de execuo nos outros processos. RUP (Rational Unied Process), baseado no modelo UP (Unied Process) e especicado pela empresa Rational, que foi adquirida h algum tempo pela IBM. O RUP , na realidade, uma base de conhecimento composta de mais de 3.200 modelos de artefatos (planilhas, arquivos de texto etc.) que podem ser adaptados para a organizao e para o projeto. Possui pontos de controle (ou marcos) muito bem denidos, servindo como um guia bastante completo para a equipe e para os gerentes de projeto.
Levantamento a atividade em que relacionamos todas as necessidades dos usurios. A anlise trata da especicao do que para ser feito no sistema, usando uma linguagem precisa, usualmente grca. Projeto a atividade de especicao da soluo dada pela equipe de desenvolvimento do software. Ele tambm usa uma linguagem precisa, idealmente a mesma usada na anlise. Implementao a atividade de construo (programao) do sistema. A implantao trata da colocao do sistema disposio dos usurios.
3

14

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS XP (Extreme Programming), um dos mtodos ditos geis, sendo bastante usado atualmente, pois "leve" com respeito documentao externa produzida, desonerando a equipe desse trabalho e focando na produo de cdigo que atenda o mais rapidamente aos usurios. No exatamente um modelo de processo, mas sim uma coleo de prticas a serem adotadas pela equipe de desenvolvimento. Por essa razo vem sendo adotado atualmente em conjunto com modelos de gerncia de projetos, notadamente o SCRUM.

A atividade de modelagem no processo em cascata e no RUP produzem artefatos que se tornam partes integrantes da documentao de anlise e projeto e, portanto, do software. No XP, os modelos UML desenvolvidos no tm muito valor como documentao, servindo apenas para discusso das possveis alternativas de soluo. No XP, os modelos, quando necessrios, devem poder ser obtidos a partir do cdigo. Os modelos de processo surgiram como solues para tornar de desenvolvimento de software uma atividade sistemtica, e quanticvel, de engenharia, portanto, em contraposio a desenvolvimento do tipo "codica-remenda", infelizmente ainda em dia. o processo disciplinada praticas de usadas hoje

2.5 Modelos e Modelagem de Software

O conceito de modelo de processo de software discutido at aqui diz respeito a uma das acepes do termo que se refere a padro. No entanto, como o texto de modelagem de sistemas com UML, importante, neste ponto, conceituar modelo, explicando tambm a necessidade de desenvolver modelos para a construo de sistemas. Modelo a representao de algo, uma abstrao da realidade e representa uma seleo de caractersticas do mundo real que so relevantes para o propsito para o qual o modelo foi construdo. Na frase anterior, a palavra representao pretende deixar claro que modelo no a realidade, mas sim algo que permite descrev-la. Por exemplo: quando pensamos em comprar um apartamento "na planta" temos de tomar nossa deciso com base em modelos que correspondem a uma representao do apartamento que no existe ainda. A palavra abstrao refere-se ao "esquecimento" do que no importante em determinado momento. No caso da compra do apartamento na planta, o primeiro modelo que costumamos olhar a planta baixa, que seleciona apenas algumas caractersticas da construo (dimenses e disposio dos cmodos, janelas e portas,

2.5. MODELOS E MODELAGEM DE SOFTWARE

15

dentre outras). Outro modelo que comumente consultamos a maquete, que seleciona caractersticas como posio do prdio dentro do terreno e com respeito s construes vizinhas, caractersticas do acabamento externo etc. Na maquete so abstradas muitas caractersticas representadas na planta baixa e vice-versa. O engenheiro que ir supervisionar a construo necessitar de outros modelos que no so importantes para quem vai comprar o imvel: o modelo (tambm chamado de projeto) de hidrulica, o de eletricidade, o de estrutura... Cada modelo tem, portanto, sua utilidade e seu "pblico alvo". Antes de ser construdo, o prdio s poder ser bem compreendido por meio de modelos quando juntarmos todas as caractersticas representadas em cada modelo. Trazendo esses conceitos para o contexto deste texto, podemos denir, resumidamente, modelos de sistemas como representaes ordenadas, estruturadas e consistentes do conhecimento a respeito do sistema. Um determinado modelo no pode ser considerado "o melhor" em termos absolutos, na medida em que a modelagem um processo iterativo, ou seja, modelos sempre evoluem em preciso, conforme nos debruamos sobre eles e os refazemos. A cada exame de um modelo, a equipe descobre uma forma mais concisa e precisa de especicar o que quer. Costuma-se classicar modelos como "errados" aqueles que no especicam de forma aceitvel a realidade e "corretos" os demais modelos. natural, ento, que alguns modelos corretos sejam mais precisos que outros. As dimenses de um modelo so o conjunto das caractersticas da realidade que so enfatizadas nesse modelo. Modelos dos sistemas de informao possuem trs dimenses:

1. Dimenso de dados, que especica as estruturas de informaes e seus relacionamentos; 2. Dimenso funcional, que especica as transformaes das estruturas de informaes; 3. Dimenso temporal, tambm chamada dimenso de controle, que especica as sequncias de acessos aos dados e de execuo das funes.

O modelo de um sistema que no possui uma dessas dimenses no um modelo completo. A atividade de modelar consiste em criar um modelo da parcela do mundo real que de nosso interesse.

16

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS Modelagem idealmente uma atividade em equipe. Mesmo que um modelo seja criado por um nico membro da equipe, bastante recomendado que ele seja apreciado pelos demais membros da equipe de modelagem, em conjunto com os especialistas do negcio/usurios (as pessoas que conhecem bem as caractersticas do negcio e que entrevistamos durante o levantamento).

A modelagem til por diversas razes, dentre elas:

possibilita o estudo do sistema, j que modelos nos permitem quebrar a complexidade de um sistema com vistas a entender como eles funcionam ou funcionaro, alm de permitir relacionarmos e "experimentarmos" alternativas de como ele poder car melhor; permite que as nossas suposies se tornem visveis e, portanto, disponveis para reviso e correo; possibilita a discusso de correes, modicaes e validao com o cliente e com a equipe a um custo baixo. Isso possvel porque a discusso ocorre usando um ambiente de simulao, utilizando agentes e insumos "virtuais" e tempos menores em relao aos necessrios para a experimentao em ambiente real; facilita a comunicao entre os membros das equipes de anlise e projeto e entre eles e os clientes e usurios.

Os modelos so construdos usando-se linguagens que permitem especicar completamente, sem ambiguidade, regras de negcio, aspectos estruturais (neles se incluem os conceitos do negcio, os relacionamentos que eles mantm entre si, dentre outros), sequncias de operaes e demais aspectos de ordenao temporal necessrios para a realizao dos propsitos do sistema. Dessa forma, o entendimento, por todos da equipe, de todos os aspectos do processo, o mesmo. A modelagem permite, ainda, documentarmos sistemas, registrando todas as suas caractersticas, as decises tomadas ao longo do projeto e os demais aspectos necessrios total compreenso e operao correta do sistema. As linguagens de especicao grca aliam a expressividade conciso e facilidade de emprego. Essas linguagens podem ainda possuir mapeamentos (tradues) para cdigo e outras formas textuais processveis por computadores que nos ajudam a manipular os elementos grcos do modelo, ao mesmo tempo que garantem a sua consistncia.

2.6. RECURSOS USADOS EM MODELAGEM E CONSTRUO DE SISTEMAS

17

2.6 Recursos Usados em Modelagem e Construo de Sistemas

Diante do desao de tornar-se o desenvolvimento de sistemas uma atividade de resultados mais precisamente previsveis, a comunidade de desenvolvedores passou a adotar recursos que, mais adiante no tempo, se tornaram parte das primeiras metodologias para anlise de sistemas. Esses recursos, aplicados desde ento, tiveram como base cinco tcnicas usadas desde a antiguidade para a soluo de problemas em reas diversas da atividade humana, tendo sido orientadas para desenvolvimento de sistemas, como apresentamos a seguir. So cinco os recursos utilizados para a modelagem e construo de sistemas de software: 1. Abstrao, que consiste em "esquecer" o que no interessa em determinado momento. Iniciamos nossa abordagem no chamado nvel conceitual, quando estamos interessados em aspectos de mais alto nvel, mais gerais, ou seja, do domnio do problema. No incio do desenvolvimento de um sistema no devemos pensar nos detalhes, nas questes de tecnologia, nos aspectos ditos fsicos. Devemos nos concentrar no que o usurio realmente precisa em termos de informao, ou seja, devemos nos concentrar na descrio do problema. No extremo oposto, ou seja, imediatamente antes de escrevermos os programas, devemos ter todos os detalhes denidos, incluindo o desenho do banco de dados na tecnologia escolhida (fabricante do sistema de gerenciamento do banco de dados SGBD, verso etc.), os nomes das classes, mtodos e atributos e aspectos da linguagem de programao, entre outros, enm, tudo que necessrio para a programao. Nesse nvel, chamado nvel de implementao, a abstrao (o "esquecimento") zero! No meio do caminho, entre o nvel conceitual e o nvel de implementao, estamos no nvel de especicao, que recebe esse nome por estarmos exatamente especicando a soluo que estamos construindo para o problema. O nvel de especicao comea assim que adicionamos o primeiro aspecto de nossa soluo especicao do problema e termina quanto todos os detalhes dessa soluo esto denidos. 2. Rigor, que consiste em adotar uma abordagem metdica e controles estabelecidos a priori. J falamos sobre isso quando tratamos de engenharia de software (ver Seo 2.3). 3. Formalismo, que se expressa por meio do uso de linguagens de especicao precisas, usualmente grcas, como diagramas de uxos de dados (DFDs), diagramas de entidades e relacionamentos (DERs), diagramas da UML etc.

18

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS O formalismo reduz a ambiguidade da linguagem de descrio, facilitando e tornando precisa a comunicao entre desenvolvedores e usurios e entre os membros da equipe de desenvolvimento. 4. Diviso e conquista, tambm chamada de diviso no domnio, que consiste em dividir o problema em partes pequenas e, idealmente, independentes, de forma a poder tratar cada parte mais facilmente. Nossa expectativa de que, dando soluo para cada uma dessas partes, podemos compor as solues para obter a soluo do problema original, maior. 5. Organizao hierrquica, tambm chamada de diviso no conceito, que consiste, tal qual a diviso no domnio, em dividir o problema em partes pequenas, dessa vez no conceito ou, em outras palavras, em nveis de abstrao cada vez menores. A idia obter partes conceitualmente simples o suciente de forma a descrever o problema e dar soluo a ele mais facilmente. Nossa expectativa tambm poder compor as solues das partes do problema, obtendo a soluo de todo o problema.

2.7 As Anlises Estruturada e Essencial

Como dissemos, os engenheiros de software tm buscado sistematizar a aplicao desses recursos nas metodologias que desenvolvem. Nesse sentido, duas iniciativas precursoras procuraram aplic-los de alguma forma: a anlise estruturada e a anlise essencial. A anlise estruturada empregava bem o recurso da organizao hierrquica dos sistemas por meio dos DFDs e suas "exploses". Os mtodos existentes estabelecem uma notao rigorosa e um processo formal para derivao dos modelos do sistema, ou seja, rigor e formalismo so, com isso, bem aplicados. Embora j houvesse a recomendao para tratar, na fase de anlise, apenas os aspectos lgicos, havia a diculdade de promover a abstrao, provendo um isolamento entre as caractersticas tecnolgicas do problema e o modelo conceitual. Com isso, a separao entre o lgico e o fsico no era clara e a experincia do analista contava muito. Faltava tambm uma tcnica para dividir o modelo em partes to independentes quanto o possvel, de forma a aplicar sistemtica e efetivamente os recursos de diviso e conquista. A anlise essencial veio a seguir, com o intuito de resolver esses problemas. Com o uso dos conceitos da "tecnologia perfeita", as questes fsicas eram sistematicamente postas de lado na fase de anlise, e a aplicao do recurso de abstrao era garantida. Alm disso, por meio dos DFDs particionados por eventos, a diviso do sistema em partes independentes era tambm garantida.

2.8. ANLISE E MODELAGEM ORIENTADAS A OBJETOS (OOAD)

19

Nesse tpico apenas "tocamos" nos conceitos das anlises estruturada e essencial e talvez tenhamos passado a impresso de que as prticas preconizadas por elas sejam ultrapassadas. O fato que, assim como a anlise essencial herdou muita coisa de anlise estruturada, a anlise orientada a objetos (a anlise OO), de que trataremos a seguir, tambm herdou boa parte de seus conceitos e das prticas das duas. Se voc est interessado em mais informao sobre anlise estruturada e anlise essencial, veja, por exemplo, os livros de Gane ([4]) e McMenamim ([3]). H tambm muito material gratuito na Internet.

2.8 Anlise e Modelagem Orientadas a Objetos (OOAD)

Com a anlise essencial, os engenheiros de software poderiam, ento, ter se dado por satisfeitos se no fossem dois outros aspectos que os incomodavam bastante: a separao entre dados e processos nos modelos. Os diagramas de uxo de dados especicavam exclusivamente processos, e os diagramas de entidades e relacionamentos especicavam exclusivamente os dados, no sendo possvel estabelecer na notao a associao existente entre os processos e os dados que processavam; a descontinuidade entre as fases de anlise e projeto. O incio do projeto obrigava que os analistas e projetistas aplicassem regras de derivao para transformao dos modelos de anlise em modelos de projeto, obrigando-os, inclusive, a usar linguagens diferentes em suas especicaes, dependendo do tipo de sistema que estava sendo modelado. Essas questes motivaram a busca por um novo paradigma cujos benefcios se aliassem s conquistas realizadas, at ento, no intuito de transformarem o desenvolvimento de sistemas em uma atividade de engenharia. A anlise e projeto orientados a objetos (OOAD Object Oriented Analysis and Design) vieram ao encontro dessas expectativas. Considerando a forma como atuamos colaborativamente em uma organizao, analistas e projetistas passaram a especicar e conceber sistemas cujas funcionalidades so realizadas por meio de colaboraes entre objetos que encapsulam os dados e que executam operaes. OO permite, portanto, reunir, em um mesmo conceito (e no mesmo modelo, como veremos mais frente em nosso texto), dados e operaes. A busca para um formalismo adequado, permitindo especicar as caractersticas do sistema independentemente do tipo de sistema que est sendo tratado e do estgio

20

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS

dentro do ciclo de desenvolvimento, resultou na criao de inmeras notaes e metodologias ao longo dos anos 1985-1995. Felizmente, em 1997, surgiu a UML, que unicou as notaes, vindo resolver esses ltimos entraves nos projetos de sistemas de software.

2.9 UML Breve Histria e Objetivos

Para que o entendimento de um modelo se faa de forma inequvoca, necessrio adotar para sua especicao uma linguagem cujos smbolos tenham semnticas (signicados) e regras de combinao denidos precisamente. E ainda, para que o modelo seja sucientemente completo, a linguagem deve ser expressiva, de forma a descrever concisamente todos os aspectos necessrios da realidade modelada. Existem vrias linguagens que atendem satisfatoriamente, em graus diferentes, a essas necessidades. A UML uma delas. O mercado de ferramentas e de metodologias para desenvolvimento de sistemas estava bastante dividido e competitivo em meados da dcada de 1990, com inmeros autores importantes liderando grupos independentes de simpatizantes de suas ideias a respeito de anlise e projeto orientados a objetos. Cerca de cento e cinquenta mtodos surgiram at 1995, dando origem principalmente a dvidas com respeito notao a ser usada e falta de uma linha a ser seguida pela indstria de produo de ferramentas CASE. Isso caracterizou o que se chamou de "a guerra dos mtodos". Nessa poca, trs dos grandes nomes em OOAD Grady Booch, Jim Rumbaugh e Ivar Jacobson juntaram foras na Rational Corporation com o intuito de combinar seus mtodos de desenvolvimento de software em uma maneira nica de trabalhar, que eles imaginavam se tornaria um padro da indstria de desenvolvimento de software. Os trs entenderam que um primeiro passo nesse sentido seria a unicao das notaes para especicao dos aspectos de anlise e projeto OO. Esse esforo resultou na submisso de uma verso inicial da UML ao Object Management Group OMG , entidade que representa toda a indstria de desenvolvimento de software OO. Aps muita discusso e alguma contribuio externa, a OMG adotou em 1997 a UML na verso 1.1. A partir da, a UML rapidamente se tornou um padro da indstria para a documentao de software desenvolvido segundo o paradigma OO. Atualmente, a UML est na verso 2.2 e continua sendo atualizada com base no feedback da indstria e da academia. A UML serve para construir modelos concisos, precisos, completos e sem ambiguidades, tendo, de maneira geral, as seguintes caractersticas: Modela os aspectos estruturais (estticos) e comportamentais (dinmicos)

2.9. UML BREVE HISTRIA E OBJETIVOS

21

do sistema, ou seja, pode especicar os conceitos do negcio e seus relacionamentos (invariantes com o tempo) e os estados, sequncias de atividades e de colaboraes (aspectos que contemplam a dimenso temporal, ou seja, que variam conforme o tempo passa). Em outras palavras, a UML prov elementos de notao para modelar dados, funes de transformao dos dados e as restries aplicveis aos dados e s funes, como regras de negcio, por exemplo. Essas caractersticas so necessrias, como j dissemos, produo de bons modelos. Prov uma linguagem que permite o entendimento e a utilizao por humanos e a leitura por mquinas. Alm dos elementos grcos da notao que so compreensveis aos humanos (desde que, obviamente, conheam a linguagem), a UML conta com mecanismo padronizado para mapeamento entre a representao grca do modelo e a sua representao textual em XML (Extensible Markup Language Linguagem Extensvel de Marcao). A representao textual facilita o intercmbio do modelo entre ferramentas de modelagem de fabricantes diferentes e possibilita a exportao desses dados para outras ferramentas, com nalidades diversas. Prov elementos de notao para modelar todos os tipos de sistemas de computao. Permite a modelagem do conceito ao artefato executvel, utilizando tcnicas OO. Usando os mesmos elementos da notao, podemos modelar desde os aspectos do negcio associados a nveis de abstrao maiores at os nveis de implementao, associados a nveis de abstrao "zero" (nenhuma abstrao). Podemos especicar, portanto, negcios e sistemas com o uso de uma nica linguagem, o que permite, quando necessrio, a transio natural entre modelos de negcio e modelos de sistema. Embora a especicao j contenha elementos de notao que permitem o atendimento a um grande nmero de situaes e propsitos, a linguagem extensvel e adaptvel a necessidades especcas; palavras-chave permitem que se modique a semntica de elementos da linguagem. Com o uso de palavraschave possvel manter um conjunto relativamente reduzido de elementos grcos da notao, porm permitindo a adaptao da UML para uso em modelagem em domnios. Contempla as necessidades de produo de modelos pequenos e simples a grandes e complexos. A UML possui diversos conectores e contineres, o que permite dividir os modelos em agrupamentos pequenos no domnio e em nveis de abstrao, de forma a torn-los compreensveis independentemente da

22

CAPTULO 2. FUNDAMENTOS DA MODELAGEM DE SISTEMAS complexidade (se devida ao tamanho do que est sendo estudado ou ao domnio que est sendo tratado). Modela processos manuais ou automatizados, estes independentemente da tecnologia que usam. uma linguagem para visualizao do modelo, facilitando o entendimento pelas equipes de anlise de negcio, desenvolvimento de sistemas e pelos clientes. Serve para construir cdigo de computador, embora no seja uma linguagem de programao de computadores. A UML o padro de facto usado em anlise e projeto de sistemas de informtica orientados a objetos. Est em evoluo, mesmo aps mais de dez anos da publicao da verso inicial. Ainda so publicadas, com certa frequncia, novas verses resultantes das discusses entre membros de diversas reas da indstria e da academia. Embora o intercmbio de modelos entre ferramentas CASE esteja previsto com o uso de um padro, o XMI[DI] XML Metadata Interchange, Diagram Interchange , os produtores de ferramentas CASE at hoje no adotaram plenamente o padro por questes de mercado e, com isso, o intercmbio no possvel entre muitas ferramentas.

A UML, sendo uma linguagem grca, conta ainda com a facilidade de emprego, pois os elementos da notao so smbolos grcos que podem ser compostos com a ajuda de ferramentas grcas interativas que garantem a corretude e a consistncia do modelo. Essas ferramentas esto amplamente disponveis em diversas faixas de preos, muitas delas gratuitas. Como consequncia da extenso de sua especicao e da aplicabilidade em uma gama ampla de domnios, a UML muitas vezes considerada intimidativa. No entanto, com um subconjunto mais reduzido de conceitos e elementos da notao os que tratamos nesta apostila contamos com um ferramental suciente para tratar boa parte (seno a totalidade) das necessidades de modelagem de sistemas encontradas no dia a dia.

2.10 Resumo do Captulo

Software o produto da atividade de engenharia de software, abrangendo programas de computador, dados e documentos. Ele se deteriora quando deixa de atender s

2.11. EXERCCIOS PROPOSTOS

23

necessidades de seus usurios, por mudanas nas regras de negcio ou por no mais responder aos requisitos de performance. A deteriorao neutralizada por alteraes apropriadas no cdigo. Um software de qualidade aquele que atende aos requisitos funcionais e de desempenho explicitamente estabelecidos, foi desenvolvido conforme padres de desenvolvimento previamente e explicitamente documentados e possui caractersticas que so esperadas em todo software desenvolvido prossionalmente, como manutenibilidade e usabilidade. Um processo de software um conjunto de atividades, mtodos, prticas e transformaes que pessoas empregam para denir, desenvolver e manter o software. Envolve pessoas com habilidades, treinamento e motivao, procedimentos e mtodos denindo o relacionamento entre as tarefas que compem o processo, alm de ferramentas e equipamentos adequados. Processos de software buscam manter o ambiente de desenvolvimento organizado, j que a qualidade do produto depende muito da qualidade do processo de produo. Modelos de sistemas so representaes ordenadas, estruturadas e consistentes do conhecimento a respeito do sistema. A modelagem possibilita o estudo do sistema e a discusso de correes, modicaes e validao com o cliente, a um custo baixo. A modelagem facilita a comunicao entre os membros das equipes de anlise e projeto e entre eles e os clientes e usurios. A UML serve para construir modelos concisos, precisos, completos e sem ambiguidades, provendo uma linguagem extensvel que permite modelar todos os tipos de sistemas de computao, o entendimento e utilizao por humanos e a leitura por mquinas, alm de atender os analistas e projetistas em todo o ciclo de vida do software.

2.11 Exerccios Propostos

1. Como os processos e a modelagem de software podem contribuir para a qualidade do software? 2. Os modelos so construdos para que possamos especicar, em uma primeira fase, as necessidades de nossos usurios. Mais adiante, eles permitem discutir com os demais membros da equipe as possveis opes para a construo do sistema. Com base nas caractersticas e nos objetivos da UML que vimos, selecione aspectos da linguagem que ajudam nessas duas fases, explicando, de forma sucinta, o porqu da seleo que voc fez. As solues encontram-se a partir da Pgina 199.

CAPTULO
25

D IAGRAMAS DE C ASOS DE U SO : C ONCEITOS E E LEMENTOS B SICOS DA N OTAO

What we see depends mainly on what we look for. John Lubbock

Joo encontrou sobre a mesa de trabalho dele um bilhete do chefe contendo o seguinte texto: "Joo, temos que resolver os assuntos pendentes o quanto antes. Faremos uma reunio, eu, voc e o diretor. Esteja em sua sala hoje s 15h." Onde, anal, Joo car esperando a reunio acontecer? Na sala onde trabalha ou na sala do diretor? Vimos no Captulo 2 que a qualidade de um sistema est fortemente associada ao atendimento s necessidades da clientela, dos patrocinadores e dos usurios desse sistema, no que diz respeito, em ltima instncia, s funes que o sistema precisa executar. Assim sendo, talvez a atividade mais importante durante a anlise de um sistema seja a conversa com o cliente. Na conversa, precisamos compreender e

26

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO

registrar corretamente as necessidades do cliente com respeito ao sistema que ser desenvolvido, de forma que os demais membros da equipe entendam e no tenham dvida sobre o que foi registrado. A atividade de compreenso e registro das necessidades do cliente conhecida como levantamento (e captura) dos requisitos do sistema. Poderamos, claro, fazer os registros em linguagem coloquial, em formato livre, mas textos escritos dessa forma so susceptveis a ambiguidades, tal qual o bilhete que Joo recebeu de seu chefe... E ns queremos evitar isso. Neste captulo iniciaremos o estudo dos diagramas de casos de uso da UML, que so usados para especicar os requisitos funcionais de um sistema. Esses diagramas so tambm usados para conrmar com o cliente o que ele disse durante o levantamento e para passar essas informaes, de forma precisa, sem ambiguidade, equipe de projeto e construo do sistema.

3.1 Enfoques dos Diagramas de Casos de Uso

Os diagramas de casos de uso da UML tm dois enfoques: o de negcios e o de sistemas. Os dois enfoques so teis, mas precisamos distingui-los porque, durante o trabalho de anlise, eles so usados em tempos diferentes. Eu costumo ilustrar as diferenas entre os dois enfoques usando a Figura 3.1. Imagine um atendente de balco do INSS que atende segurados em suas diversas necessidades. O primeiro segurado da la deseja executar o processo de negcio Averbar Tempo de Servio. Para isso, o atendente consulta um arquivo convencional, pega um ou mais formulrios sobre a mesa e, possivelmente, consulta o tempo de contribuio do segurado no sistema. Durante a realizao desse processo de negcio, o atendente e o segurado trocam informaes e documentos, ambos participando, portanto, do processo. Os dois so ditos atores do negcio, pois cada um deles desempenha seu papel especco no processo de negcio. O atendente tambm consulta o tempo de contribuio do segurado no sistema. Por usar o sistema, o atendente ator do sistema, alm de ator do negcio. O segurado, no entanto, no interage com o sistema e, portanto, no ator do sistema. importante ressaltar que, mesmo que o atendente retire um relatrio do sistema e o entregue ao segurado, este no se torna um ator do sistema por isso. Um indivduo s considerado ator de um sistema se ele usurio desse sistema, ou seja, se ele insere um dado, pressiona um boto ou tecla, passa um carto, toca a tela e seleciona uma opo, rola uma tela ou se identica biometricamente, interagindo diretamente com o sistema.

3.1. ENFOQUES DOS DIAGRAMAS DE CASOS DE USO

27

Estou consultando minhas contribuies

Posto do INSS
Eu quero averbar meu tempo de servio

Balco

Eu quero requerer minha aposentadoria S quero fazer uma perguntinha

Atendente

Porta

Segurados

Figura 3.1: Casos de uso de negcio e casos de uso de sistema sendo executados no posto do INSS.

Situao anloga pode acontecer com os demais processos de negcio dos quais o atendente do INSS participa: Registrar Requerimento de Aposentadoria e Retirar Dvidas. A Figura 3.1 tambm ilustra a situao em que um segurado precisa consultar o seu tempo de contribuio e acessa diretamente outra funcionalidade do sistema do INSS: Consultar Tempo de Contribuio Via Terminal do Cidado. Nesse caso, o processo de negcio do INSS Informar Tempo de Contribuio realizado totalmente pela funcionalidade Consultar Tempo de Contribuio Via Terminal do Cidado. O segurado ator de um processo de negcio e de uma funcionalidade de sistema. De maneira geral, processos de negcio envolvem relaes entre organizaes, entre organizaes e seus clientes e fornecedores, entre colaboradores em uma organizao e entre todas as demais entidades que precisam colaborar de alguma forma para que as organizaes cumpram seus objetivos. Esse o enfoque de negcio e, segundo esse enfoque, os casos de uso de negcio representam os processos realizados e os atores de casos de uso de negcio so todos os que participam

28

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO

deles. Eventualmente, um processo em uma organizao informatizado, parcial ou totalmente. As funcionalidades, demais caractersticas desse sistema e seus usurios dizem respeito ao enfoque de sistema. Segundo esse enfoque, os casos de uso de sistema representam as funcionalidades do sistema; os atores dos casos de uso de sistema so seus usurios. Os processos de negcio podem ser modelados com o uso de diagramas de casos de uso de negcio e as funcionalidades de um sistema podem ser modeladas com o uso de diagramas de casos de uso de sistema. A notao usada nos dois pode ser exatamente a mesma, contanto que mencionemos no diagrama a que enfoque corresponde. Casos de uso de negcio no so o foco deste texto, mas eu pessoalmente estimulo todos os analistas a realizarem o estudo dos processos de negcio e, portanto, a desenvolverem o diagrama e a descreverem os casos de uso de negcio como forma de conhecerem bem os processos que iro automatizar com a criao dos sistemas. Elaboramos o diagrama de casos de uso de sistema para representar os requisitos funcionais, ou seja, as funes que devero estar disponveis no sistema para que as necessidades que motivaram a sua construo sejam satisfeitas. Este o enfoque do texto. Por isso, ao mencionarmos simplesmente "caso de uso" e "ator" estaremos nos referindo neste contexto a "caso de uso de sistema" e "ator de caso de uso de sistema", respectivamente. A seguir apresentaremos a notao grca usada nos diagramas de casos de uso e os conceitos de cada elemento da notao. Na Figura 3.2 so ilustrados seis atores e dois casos de uso de um Sistema de Registro de Compras e Devolues de um supermercado hipottico.

3.2 Os Atores
O termo ator do sistema se refere ao papel que algum ou alguma coisa interpreta enquanto interage com o sistema sendo modelado. No diagrama da Figura 3.2, os "bonequinhos" representam atores do Sistema de Registro de Compras e Devolues. A UML se refere representao grca como sendo de stick men, ou seja, bonecos feitos de linhas, de forma bem simples. Embora, em boa parte das vezes, atores sejam seres humanos, eles tambm podem ser outras coisas, como dispositivos eletrnicos ou outros sistemas que se relacionam com o sistema em estudo. Um nico indivduo pode interpretar o papel de vrios atores (por exemplo, Joel, alm de ser ou interpretar o papel de caixa, pode atuar como o atendente de balco);

3.2. OS ATORES

29

Sistema de Registro de Compras e Devolues

Caixa

Registrar Compra

Administradora do Carto

Cliente Superv isor

Registrar Dev oluo

Sistema de Controle de Estoque Atendente de Balco

Figura 3.2: Diagrama de casos de uso de um Sistema de Registro de Vendas e Devolues de um supermercado hipottico.

vrios indivduos podem interpretar o papel de um nico ator (por exemplo, Joel e Pedro podem ser, ambos, atores caixa). Atores podem participar de um ou mais casos de uso; na Figura 3.2, os supervisores podem participar de registros de compras e de devolues. O nome do ator, idealmente uma expresso breve no singular, deve sugerir claramente o papel que o ator representa, dentro do jargo do negcio, ou seja, no deve ser, por exemplo, uma expresso de uso restrito ao ambiente da equipe de modelagem. A Tabela 3.1 mostra alguns exemplos do que usar e do que no usar como nomes de atores. A verso atual da UML permite representarmos um ator de uma forma grca mais sugestiva quanto ao seu tipo, ou seja, atores sistemas podem ser representados por guras de computadores. Outra representao alternativa com a notao de

30

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO Tabela 3.1: Exemplos do que usar e do que no usar como nomes de atores. Usar Contador Sistema de Controle de Estoque ou simplesmente SCE Sensor de Presena No Usar Contadores Joo Usurio

classes, ou seja, retngulos com a palavra-chave "actor" em seu topo, j que atores tambm podem ser entendidos como categorias ou classes de usurios dos sistemas. Quando desenhamos o retngulo que representa os limites do sistema, os atores so colocados fora dele. Isso signica que, para o propsito do modelo a ser desenvolvido, no interessa saber como eles agem, qual a lgica de funcionamento e como so seus detalhes internos; o que interessa apenas o que eles fazem durante a interao com o sistema que est sendo estudado. Eles podem aparecer repetidos em um mesmo diagrama. Para muitos analistas, isso s tem efeito cosmtico, pois possibilita eliminar cruzamentos entre relacionamentos, o que no se justica pelo aspecto prtico e, na maioria das vezes, de clareza do modelo. Isso, pelo contrrio, s adiciona complexidade visual ao modelo. Resta, agora, identicar os atores do sistema. Essa atividade parece, em princpio, simples, mas devemos ter em mente as diferenas entre participar do processo de negcio e interagir com o sistema. Os atores so descobertos classicando-se os indivduos que efetivamente usaro o sistema ou identicando-se o software tipicamente outros sistemas ou hardware externo que inicia um caso de uso do sistema ou que necessrio durante a execuo desse caso e uso. No se pode ter certeza de que todos os atores foram descobertos antes de especicar1 (descrevermos em detalhes) todos os casos de uso do sistema, pois durante a especicao que entendemos quem faz o que no sistema. Um ator no uma pessoa especca. Quase sempre possvel achar pelo menos duas pessoas cujas responsabilidades e atividades se encaixam no perl de um mesmo ator, isso para cada ator do modelo. Em outras palavras: se voc no achou mais do que uma pessoa que interpreta o papel de determinado ator, bem provvel que voc tenha modelado a pessoa, e no o ator, embora exista a possibilidade de um papel ser interpretado por somente uma pessoa. Um exemplo disso em um Sistema de Controle de Clientes de uma padaria, em que o dono, o Seu Manoel, o nico que executa o caso de uso Manter Lista Negra de Clientes.
1

Especicaes de casos de uso sero vistas na prximo captulo.

3.3. OS CASOS DE USO

31

3.3 Os Casos de Uso

Um caso de uso corresponde a um conjunto de aes executadas durante a realizao de uma funcionalidade do sistema. Casos de uso concentram-se nas relaes entre as funes do sistema e os usurios que delas participam de alguma forma. Um caso de uso de sistema tem as seguintes caractersticas: Captura as aes para a realizao de uma funo do sistema, enfocando as interaes entre os usurios e o sistema; uma unidade coerente de passos, expressa como uma transao entre os atores e o sistema, compondo-se tipicamente de vrias aes dos atores e respostas do sistema; uma sequncia de aes que produzem resultados observveis de valor para os usurios; Expressa o que acontece quando um caso de uso executado, incluindo suas possveis variaes. No h preocupao em como os participantes executam suas aes, embora a ordem delas seja relevante. Nos diagramas, os casos de uso so denotados por ovais ou elipses que representam as funcionalidades do sistema. Casos de uso tm nomes que devem ser ativos, ou seja, um verbo no innitivo concatenado a um substantivo. Exemplos: Aprovar Crdito, Registrar Venda de Automvel e Aprovar Fatura. Os nomes so colocados dentro ou abaixo das ovais. De certa forma, a colocao do nome sob a oval traz mais complexidade visual ao diagrama, j que nome e oval passam a constituir dois elementos visuais distintos. Por exemplo: do caso de uso Registrar Compra da Figura 3.2 participam o Caixa (que registra os itens de compra no sistema), o Cliente (que digita a senha do carto de crdito), a Administradora do Carto (que aprova o dbito do valor no carto), o Sistema de Controle de Estoque (que informado da compra para que possa controlar o estoque), e o Supervisor (que eventualmente retira um item de venda da lista de compras). A forma como eles participam no especicada no diagrama. Usamos, basicamente, duas tcnicas para descobrir as funcionalidades do novo sistema: 1. Iniciando a partir da relao dos atores: funcionalidades de que necessita. para cada ator, identicar as

32

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO 2. Iniciando a partir da relao dos eventos. Isso feito em trs etapas, conforme segue. a) Identicar os eventos externos aos quais o sistema deve responder; b) Associar os eventos aos atores que atuam para trat-los; c) Identicar as funcionalidades que eles necessitam executar em resposta aos eventos.

A primeira tcnica a mais simples e a mais comumente usada. Apenas para ilustrar a segunda tcnica, tomemos como exemplo o evento de recebimento de uma nota scal de entrega pelo setor de controle de estoque de uma organizao. O encarregado do estoque que recebe a nota (o ator) precisa de uma funcionalidade (o caso de uso) para registrar a chegada dessa fatura, que indica a chegada de material para reposio de estoque. Essa funcionalidade poderia, por exemplo, adicionar os novos itens no estoque e indicar ao sistema de contas a pagar da organizao que h um novo compromisso a ser pago.

3.4 A Fronteira do Sistema

A fronteira do sistema, tambm chamada limite ou escopo do sistema, representada pelo retngulo que contm os casos de uso (veja a Figura 3.2). A representao da fronteira opcional, segundo a UML; colocamos a fronteira quando queremos e podemos, j que, s vezes, no conseguimos denir uma fronteira retangular com os casos de uso dentro e os atores fora. A fronteira colocada para salientarmos o que o sistema e, portanto, nosso interesse estudar. Estar fora da fronteira, em contrapartida, signica que no estamos interessados, para efeito de nosso estudo, nos detalhes internos e na lgica de seu funcionamento. Por essa razo, os atores do sistema cam necessariamente fora da fronteira. No topo do retngulo, internamente a ele, centralizado, colocamos o nome do sistema.

3.5 Relacionamentos em Diagramas de Casos de Uso

Com a UML podemos especicar os tipos diferentes de relacionamentos que existem entre atores, entre atores e casos de uso e entre casos de uso. Eles esto detalhados a seguir.

3.5. RELACIONAMENTOS EM DIAGRAMAS DE CASOS DE USO

33

Associao
O nico relacionamento possvel entre um ator e um caso de uso leva o nome particular de associao. As associaes especicam quais atores participam de quais casos de uso, sendo representadas nos diagramas de casos de uso por meio de segmentos de retas, curvas ou poligonais que ligam os atores aos casos de uso de que participam. A UML admite que ambas as pontas das associaes possuam multiplicidades. Quando um ator tem uma associao com um caso de uso com uma multiplicidade que maior que um na ponta da associao do lado do caso de uso (veja a Figura 3.3), isso signica que o dado ator pode estar envolvido com mltiplas execues (instncias) do caso de uso. A natureza especca desse relacionamento mltiplo depende do contexto e no denida na UML. Dessa forma, um ator pode iniciar uma ou mais instncias de um mesmo caso de uso concorrentemente ou elas podem ser mutuamente excludentes no tempo. Por exemplo, um colaborador pode iniciar ao mesmo tempo um determinado tipo de atendimento a vrios clientes no balco ou instituir uma la para atendimento um a um. Quando essa multiplicidade maior do que um do lado do ator, signica que mais de uma instncia daquele ator participa do caso de uso. A maneira como os atores participam depende do contexto (concorrentemente, de forma colaborativa ou numa sequncia) e tambm no denida na UML. Multiplicidades sero vistas adiante com mais detalhes, quando tratarmos de diagramas de classes. Quando no h multiplicidades nas pontas das associaes porque elas ainda no foram determinadas ou essa informao no relevante para o propsito do modelo. Nesse caso, deve-se admitir que um ator participa de um nmero qualquer de instncias do caso de uso e participa do caso de uso qualquer nmero de instncias do ator (usurios daquela classicao). As formas segundo as quais os atores participam dos processos de negcio no so capturadas nos diagramas de casos de uso. Casos de uso precisam ser descritos (especicados) para que os detalhes quem esclarecidos. Especicaes de casos servem ainda para validao junto ao usurio, funcionando com um "contrato" entre o usurio e o desenvolvedor.

Especializao-Generalizao de Atores e Casos de Uso

Os relacionamentos de especializao-generalizao podem ocorrer entre dois atores e entre dois casos de uso. Esses relacionamentos so representados por setas com

34

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO

Abrir OS 0..* 1 Auxiliar Administrativ o

Figura 3.3: Multiplicidades nas pontas das associaes entre atores e casos de uso.

pontas triangulares vazadas (veja as Figuras 3.4 e 3.5), que indicam o sentido da generalizao; o sentido oposto o da especializao. Muitos atores podem interpretar o mesmo papel em um determinado caso de uso. A Figura 3.4 ilustra a situao em que o ator Gerente de Vendas aprova nanciamentos, mas tambm pode atuar como Vendedor, vendendo automveis. De fato, um gerente de vendas vai querer atuar como um vendedor (e ganhar toda a comisso pela venda) quando, por exemplo, um cliente antigo seu chega loja de automveis para trocar os cinco automveis Mercedes-Benz da famlia, como costumeiramente faz todo incio de ano. Essas participaes especcas, por sinal, so as diferenas de comportamento dos atores que justicam suas especializaes. Isso quer dizer que o modelo da Figura 3.4 s se justica se houver pelo menos um caso de uso associado a Gerente de Vendas. Note que a recproca no verdadeira, ou seja, um vendedor no poderia entrar no sistema para registrar a aprovao de um nanciamento.

Especializaes-generalizaes de atores so os nicos relacionamentos possveis entre atores em um diagrama de casos de uso.

3.5. RELACIONAMENTOS EM DIAGRAMAS DE CASOS DE USO

35

Registrar Venda

Vendedor

Aprov ar Financiamento

Gerente de Vendas

Figura 3.4: Especializao-generalizao de atores.

A Figura 3.5 ilustra uma situao em que o vendedor registra a venda de um automvel; esse processo pode ser feito de trs maneiras ligeiramente diferentes: 1. para o caso em que o limite de crdito do comprador se encontra ultrapassado (caso de uso Registrar Venda de Automvel Cliente Com Limite de Crdito Atingido); 2. para o caso em que o cliente um cliente habitual (caso de uso Registrar Venda de Automvel Cliente Habitual); 3. para o caso em que ocorre o processo bsico, normal, que corresponde ao caso de uso base Registrar Venda de Automvel. Esse caso de uso chamado de caso de uso base.

36

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO

Registrar Venda de Automv el

Vendedor Registrar Venda de Automv el Cliente Com Limite de Crdito Atingido

Registrar Venda de Automv el Cliente Habitual

Figura 3.5: Especializao-generalizao de casos de uso.

A especializao de um caso de uso signica, portanto, que o caso de uso que especializa (por exemplo, o caso de uso Registrar Venda de Automvel Cliente Com Limite de Crdito Atingido, da Figura 3.5) um pouco diferente do caso de uso especializado (o caso de uso Registrar Venda de Automvel), podendo acrescentar ou remover passos deste. Na segunda edio do livro UML Essencial ([6]), Fowler e Scott dizem que usam especializaes de casos de uso "quando se tem um caso de uso que semelhante a outro, mas faz um pouco mais". Eles reforam essa ideia quando dizem que usam especializaes quando no querem ser muito precisos, o que equivale a dizer quando querem se manter em um nvel de abstrao mais alto. O processo de venda de automvel para clientes com limite de crdito atingido realizado com base no processo bsico para clientes que compram a crdito, possivelmente demandando outras informaes do cliente, outras garantias e a anuncia do gerente de vendas. O processo de venda para um cliente habitual possivelmente altera o prazo de entrega e agiliza o processo de coleta de informaes do cliente. A generalizao sugere uma leitura do modelo na forma " um tipo de". No exemplo da Figura 3.4 podemos ler: gerente de vendas um tipo de vendedor. No exemplo da Figura 3.5 podemos ler: registrar a venda de automvel para um cliente habitual um tipo de registro de venda de automvel.

3.5. RELACIONAMENTOS EM DIAGRAMAS DE CASOS DE USO

37

O uso de especializao-generalizao, como j dissemos, dota o modelo de um nvel de abstrao mais alto, o que em geral no perdura por muito tempo dentro do ciclo de modelagem; um pouco mais adiante no tempo ser necessrio especicar o quo diferentes (em qu, exatamente) so os casos de uso especializados entre si e em relao ao caso de uso base. Por essa razo, eu particularmente prero usar um tipo de relacionamento que se aproxima mais da forma precisa de especicao dessas diferenas: o relacionamento de extenso, que voc ver mais adiante.

Incluso de um Caso de Uso em Outro

Incluso um relacionamento somente usado entre dois casos de uso. Uma incluso ocorre em um caso de uso quando necessria a invocao do comportamento especicado em outro; em determinado momento da especicao de um processo "se chama" (se faz referncia a) o outro. como se fosse a chamada feita a uma subrotina, em um programa de computador. Uma incluso se faz necessria quando se tem um conjunto relevante de aes que comum a dois ou mais casos de uso. Nesse caso, se fatora esse comportamento em um novo caso de uso, ou seja, se retira dos casos de uso esse conjunto de passos que repetido, colocando-o em um caso de uso parte. A Figura 3.6 ilustra uma situao em que determinado restaurante opera de formas diferentes no almoo e na janta: no almoo ele oferece refeio por quilo e noite a refeio oferecida la carte. Existe um conjunto de aes comum a ambos os casos de uso, que ocorrem obrigatoriamente e de forma idntica segundo as regras do restaurante: o pagamento pela refeio. O pagamento da conta, em geral, no um processo trivial, pois envolve a escolha do meio de pagamento e o cumprimento das formalidades correspondentes. No ser trivial signica demandar um nmero relevante de passos para a sua especicao, o que justica a criao de um caso de uso para represent-lo no diagrama. Outro aspecto importante que o pagamento da conta obrigatrio, no almoo e no jantar... Pelo menos nesse restaurante, pois a incluso est associada obrigatoriedade; se o pagamento fosse facultativo, por alguma razo ou forma (se a despesa pudesse ser "pendurada" ou "deixada pra l", por exemplo), no seria uma incluso, e sim uma extenso.

Extenso de um Caso de Uso por Outro

A extenso tambm um relacionamento que s ocorre entre dois casos de uso.

38

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO

Almoar no Restaurante

include Pagar a Conta Cliente include Jantar no Restaurante

Garon

Figura 3.6: Relacionamento de incluso entre casos de uso.

Extenses so essencialmente generalizaes, s que possuem regras mais explcitas. Quando tratamos de generalizaes/especializaes, mencionamos que elas no perduram por muito tempo no ciclo de modelagem porque, mais cedo ou mais tarde, precisamos especicar as diferenas entre as especializaes e entre elas e o caso de uso base, sob pena do nosso modelo car incompleto. Fowler e Scott recomendam que se use extenso "quando voc estiver descrevendo uma variao do comportamento normal de um caso de uso e deseja utilizar a forma mais controlada". Essa forma mais controlada feita especicando-se pontos de extenso, que no veremos neste texto. Cremos que modelar extenses sem os pontos de extenso, ao invs de generalizaes, seja suciente para cumprir os objetivos da modelagem de casos de uso no nvel conceitual. A extenso tambm signica a invocao de um caso de uso por outro, mas difere da incluso na situao em que, de acordo com as regras do negcio, a invocao feita ao outro caso de uso no ocorre obrigatoriamente. Difere ainda porque a invocao ocorre no sentido inverso da seta. Voltando situao ilustrada pela Figura 3.6, imagine a situao em que o restaurante faz promoes para os almoos, de modo que os clientes habituais no pagam a refeio a cada determinado nmero de idas ao restaurante. Isso signica

3.5. RELACIONAMENTOS EM DIAGRAMAS DE CASOS DE USO

39

Almoar no Restaurante

extend Pagar a Conta Cliente include Jantar no Restaurante

Garon

Figura 3.7: Relacionamento de extenso entre casos de uso.

que, de acordo com as regras do restaurante, o pagamento pelo almoo pode no ocorrer. Nesse caso, o modelo ca conforme ilustra a Figura 3.7 (l-se Pagar Conta estende Almoar no Restaurante). Extenso signica que, em determinada posio da execuo da funcionalidade representada pelo caso de uso, outro caso de uso invocado opcionalmente. O nome extenso signica que o caso de uso invocado estende (aumenta) o caso de uso que invoca, acrescentando novas aes a ele. Fechando a ideia sobre incluses e extenses, os relacionamentos so sempre lidos no sentido da seta (que tracejada, segundo a notao). Incluso signica que o caso de uso apontado pela seta includo no caso de uso que o aponta. Extenso signica que o caso de uso que aponta estende (agrega mais passos a) o caso de uso apontado. Adicionalmente, a extenso ocorre opcionalmente e a incluso ocorre obrigatoriamente, segundo as regras do negcio. importante ressaltar que uma incluso, embora obrigatria pelas regras do negcio, pode no ocorrer. Tomemos como exemplo a situao ilustrada pela Figura 3.6, que especica que o pagamento pela refeio obrigatrio; nada impede, no entanto, que o cliente drible a segurana, pule a janela e saia do restaurante sem pagar. Temos um pequeno "macete" para descobrir se devemos usar incluso ou

40

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO

A
A inclui B obrigatoriamente.

A no obrigatoriamente inclui B (B estende A)

include

extend

Figura 3.8: Uso de incluso e extenso quando a incluso ocorre obrigatoriamente ou no obrigatoriamente, respectivamente, segundo as regras de negcio.

extenso em um modelo: se, por exemplo, o caso de uso A chama em determinado ponto o caso de uso B, indicamos no modelo que A inclui B (o relacionamento de incluso aponta de A para B). Nesse ponto perguntamos: essa incluso ocorre obrigatoriamente, segundo as regras do negcio? Se a resposta for "sim", permanece a incluso; sendo "no", substitumos a incluso por extenso no sentido contrrio (com o relacionamento de extenso apontando de B para A). A Figura 3.8 ilustra. A abordagem feita sobre incluses e extenses, embora no to completa sob o ponto de vista da UML, mostra-se adequada para a maioria das situaes de modelagem de sistemas. Modelos de casos de uso s capturam as caractersticas estruturais dos processos (que elemento do modelo est relacionado a que outro(s)). Os detalhes das sequncias em que as aes ocorrem durante o desenrolar dos casos de uso, dentre outros, s so tratados por meio das descries dos casos de uso, que veremos no prximo captulo.

3.6 Os Itens Anotacionais da UML

Na Figura 3.8 h um novo elemento da notao da UML: o "cartozinho" com a ponta dobrada, que usado para colocar comentrios, qualquer texto que elucide algum aspecto importante do modelo ou um requisito no funcional, como, por exemplo, uma restrio. Esse o chamado item anotacional da UML, que associado ao diagrama ou opcionalmente a um elemento comentado por meio do segmento de reta tracejado.

3.7. RESUMO DO CAPTULO

41

Qualquer elemento do modelo pode ser associado a um comentrio: um ator, um caso de uso, uma associao, uma classe, um objeto, uma atividade, ou seja, itens anotacionais podem aparecer em qualquer diagrama da UML. Embora comentrios no estejam associados exclusivamente a casos de uso, como ns veremos muitos deles nas aulas que viro, decidi mencion-los neste ponto do texto.

3.7 Resumo do Captulo

Os diagramas de casos de uso so vistos como mecanismos bastante ecazes de captura de requisitos funcionais de um sistema, de forma a evitar a ambiguidade. A notao simples o suciente para que possamos validar, com os usurios, as funcionalidades do sistema e quem as utilizar. Utilizando diagramas de casos de uso de negcio, podemos especicar quais so os processos de negcio e quais so os participantes desses processos. Em seguida, elaborando um diagrama de casos de uso de sistema, podemos especicar as funcionalidades que comporo o sistema que automatizar partes dos processos de negcio, bem como quem sero seus usurios, categorizados conforme suas interaes com o sistema. Esses so, respectivamente, os casos de uso do sistema e seus atores. Atores e casos de uso se relacionam. Esses relacionamentos so representados nos diagramas como associaes, especializaes-generalizaes, incluses e extenses. No prximo captulo prosseguiremos com o estudo dos casos de uso, tratando das especicaes (descries textuais) deles, citando erros frequentes de modelagem e dando dicas para a elaborao das especicaes e mais dicas para elaborao dos diagramas.

3.8 Exerccios Propostos

1. Identique os atores de casos de uso de sistema para cada uma das situaes a seguir. Considere que as situaes dizem respeito especicao de trs sistemas totalmente distintos entre si. a) ... o atendente abre uma nova OS (ordem de servio)... b) ... o atendente abre uma nova OS e entrega uma cpia do relatrio de abertura ao cliente que se encontra no balco...

42

CAPTULO 3. DIAGRAMAS DE CASOS DE USO: CONCEITOS E ELEMENTOS BSICOS DA NOTAO c) ...o atendente abre uma nova OS. Ao nal do processo de abertura da OS o supervisor informado por e-mail... 2. Identique os casos de uso de sistema para cada uma das situaes a seguir. Considere que as situaes dizem respeito especicao de trs sistemas totalmente distintos entre si. a) O atendente informa a concluso da OS... b) (em um sistema de segurana computadorizado) ...O sensor de presena do sistema de segurana aciona o alarme que pode ser desligado pelo supervisor de segurana... 3. Desenvolva os diagramas de casos de uso de sistema para as situaes a seguir. Imagine que as situaes so trechos de especicaes de sistemas distintos. a) O atendente informa ao sistema a concluso das OS cujos dados so, ento, passados ao Sistema de Contas a Receber (SCR), que efetuar a cobrana... b) ...o atendente informa ao sistema a concluso das OS. Uma cpia impressa do relatrio de concluso segue junto com o equipamento para o cliente e outra cpia vai para o setor de cobrana... c) ...o atendente abre uma nova OS, informando os dados do cliente e do equipamento... d) ...o atendente abre uma nova OS. Durante esse processo, o sistema solicita a denio dos campos de um formulrio de cadastro de clientes. Esse mesmo formulrio pode ser apresentado ao supervisor, para eventual alterao cadastral... e) ...o atendente abre uma nova OS e, caso o cliente no esteja cadastrado, essa a hora de faz-lo. O atendente ou o supervisor podem, a qualquer momento, cadastrar novos clientes sem que estes solicitem qualquer servio... f) ...clientes do laboratrio podem se cadastrar via Internet. O cadastro tambm pode ser feito na chegada do cliente, pela recepcionista, na abertura de uma lista de exames. g) s sextas-feiras, s 18h, o expediente para o pblico encerrado e s 18h30min o sistema automaticamente imprime a relao de inadimplentes... h) ...o chefe do suporte informado pela rotina de autenticao do sistema, via "torpedo", de qualquer pedido de autenticao feito pelos usurios cadastrados na lista negra de usurios. As solues encontram-se a partir da Pgina 200.

CAPTULO
43

D IAGRAMAS DE C ASOS DE U SO : D ESCRIES , D ICAS E E RROS C OMUNS DE M ODELAGEM

A writer is somebody for whom writing is more difcult than it is for other people. Thomas Mann

Vimos no Captulo 3 que os diagramas de casos de uso so atemporais, ou seja, no capturam as sequncias da interao com os usurios nem as das aes necessrias para a realizao das funes do sistema. A especicao das aes (e em que ordem elas so realizadas) ca por conta de uma descrio textual, em formato padronizado pela organizao ou para o projeto. A essa atividade damos os nomes de especicao ou descrio dos casos de uso. As descries dos casos de uso complementam os diagramas, ajudando a validar a interao sistema-usurio com o cliente e a ordem de execuo das aes dos usurios e do sistema. So tambm usadas como artefatos de entrada para o processo de especicao dos testes funcionais, aqueles que atestam que o sistema faz o que o cliente pediu. Diagramas de casos de uso complementados por suas descries so, portanto,

44

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM

artefatos de grande importncia para as equipes de projeto e construo de sistemas. Neste captulo trataremos das descries dos casos de uso e faremos o "fechamento" do assunto Casos de Uso, relacionando algumas dicas e apresentando os erros mais comumente encontrados na modelagem de casos de uso, incluindo em suas descries.

4.1 Padro de Descries nas Organizaes

Vimos que os diagramas de casos de uso no capturam todas as caractersticas das funes que o sistema precisar executar; por exemplo, por no contemplar a dimenso temporal, no h como especicar sequncias de execuo das aes dos usurios ou do sistema. Pelos diagramas tambm no podemos inferir como atores e sistema interagem para a realizao das funes do sistema; sequer podemos inferir se todos os atores relacionados a um caso de uso no diagrama precisam atuar colaborativamente ou se cada um pode, isolada e independentemente, executar todo o processo. Esses detalhes s so capturados quando descrevemos os casos de uso. As descries dos casos de uso, tambm chamadas de especicaes, no so padronizadas pela UML. Dessa forma, as organizaes denem seus prprios padres usualmente baseados em padres disponveis na Internet ou em livros. Elas criam e instituem templates do MS-Word para as descries, segundo uma estrutura complexa e contendo muitas informaes e referncias cruzadas. Essas informaes so muitas vezes repetidas e/ou no to relevantes para o propsito da modelagem. Minha crtica a esse respeito que informao demais torna a especicao dos casos de uso uma atividade enfadonha e potencialmente geradora de inconsistncias. Essas organizaes esquecem que a completude e a conciso podem andar juntas. Outro aspecto importante a ser observado a dependncia da especicao produzida com respeito ferramenta que a mantm (que a visualiza, altera, elimina e imprime a descrio), seja ela gratuita ou paga. Documentos em formato proprietrio estabelecem um vnculo de longo prazo com a ferramenta e com a empresa que a produziu, alm de estarem sujeitos a corrompimento. O ideal armazenar a documentao em formato textual aberto (por exemplo, DocBook), visualizvel por qualquer editor de textos e intercambivel entre ferramentas de fabricantes e de verses diferentes.

4.2. DESCRIES ABREVIADAS E DESCRIES DETALHADAS

45

4.2 Descries Abreviadas e Descries Detalhadas

As descries podem ser feitas de forma abreviada, em alto nvel de abstrao, ou detalhada. Quando estamos no incio do processo de levantamento, normal optar por fazer uma aproximao "em largura", abordando o quanto antes o maior nmero de casos de uso do sistema, em detrimento dos detalhes de cada caso de uso. Nessa situao, elaboramos as descries abreviadas. Nas demais etapas do levantamento fazemos o renamento dos casos de uso, quando elaboramos as descries detalhadas. Se determinada funo do sistema estiver associada a algum tipo de risco maior, recomendado detalhar o quanto antes a descrio dessa funo. O nvel de detalhamento da especicao de um caso de uso deve depender do risco envolvido na execuo da funo do sistema. Independentemente do padro adotado, a descrio em alto nvel deve conter o nome do caso de uso, a relao dos atores e, em poucas linhas, a descrio do processo adotado. usual que descries em alto nvel contenham, tambm: pr-condies, ou seja, tudo que precisa ser verdade para que o caso de uso inicie. Um exemplo de pr-condio quando, para a execuo de um caso de uso, necessrio que seus usurios estejam autenticados no sistema. O mais conciso, nesse caso, colocar como pr-condio a informao "Usurio autenticado no sistema", ao invs de apontar com o relacionamento de incluso o caso de uso Autenticar Usurio de todos casos de uso no diagrama que demanda autenticao; ps-condies, o seja, o que se torna verdade quando o caso de uso termina. Como isso usualmente depende de como o caso de uso termina, eu evito usar ps-condies ou as restrinjo ao nal que tipicamente acontece. Acho importante deixar isso bem claro ao usar-se ps-condies; garantias. Essas, diferentemente das ps-condies, so o que se torna verdade quando o caso de uso termina, independentemente da forma como ele termina. As descries abreviadas so aproveitadas nas descries detalhadas, pois estas renam aquelas. A descrio detalhada deve conter, alm do que j foi relacionado, as seguintes informaes: os passos que compem o curso tpico;

46

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM Tabela 4.1: Exemplo de tabela de regras de negcio. Tabela de Regras de Negcio Descrio Todo dependente estar associado a um nico funcionrio. Dependentes de funcionrios devem ter idade inferior a 24 anos. ...

Regra de Negcio RN01 RN02 ...

os passos que compem os cursos alternativos; a relao de regras de negcio que devem ser observadas. H situaes em que determinadas informaes fornecidas pelos usurios ou produzidas pelo sistema precisam estar de acordo com uma ou mais regras do negcio. Nesses casos, o que se costuma fazer para que as descries quem concisas referenciar a regra ou regras de negcio onde elas precisam ser observadas.

Regras de negcio (RNs) so usualmente numeradas para que possam ser referenciadas mais facilmente nas descries dos casos de uso. Usualmente, as regras compem uma tabela de regras ou um captulo parte na documentao. Assim sendo, a tabela de RNs precisa ser colocada em um ponto especco da documentao; no captulo (ou item) Regras de Negcio, por exemplo. A Tabela 4.1 ilustra. Para ilustrar como referncias a regras de negcio podem simplicar a descrio de casos de uso, imagine, por exemplo, uma situao em que os dados fornecidos por um usurio do sistema dizem respeito ao dependente de um funcionrio que, por regra do negcio, no pode ter mais do que vinte e quatro anos. Poderamos ter algo do tipo (mostrando apenas um trecho da descrio):

...Sistema exibe formulrio para fornecimento dos dados do dependente do funcionrio; Usurio preenche os campos com os dados do dependente; Sistema verica idade do dependente com respeito RN02...

A RN02, no caso, refere-se regra de negcio de nmero dois (ver Tabela 4.1).

4.3. ESPECIFICANDO O CURSO TPICO E OS CURSOS ALTERNATIVOS

47

4.3 Especicando o Curso Tpico e os Cursos Alternativos

Cada caso de uso tem o seu curso tpico, em que relacionamos os passos da interao usurio(s)-sistema que compem a situao que tpica ou idealmente acontece. comum relacionarmos o curso tpico "situao dos sonhos". Por exemplo, em um sistema de registro de compras de um supermercado, a situao tpica o cdigo de barras poder ser lido pelo leitor tico, ou seja, muito eventualmente o/a caixa precisa entrar com o cdigo pelo teclado. Quando no conhecemos o que tipicamente acontece, por estarmos lidando com uma situao nova, podemos considerar como curso tpico os passos que comporo a situao que dever, idealmente, acontecer. Um caso de uso tambm pode possuir cursos alternativos, em que descrevemos as possveis variaes em geral muitas de execuo do caso de uso. Situaes alternativas so comumente e erradamente associadas a situaes ruins. Na realidade, nem todas as situaes alternativas so situaes ruins, pois tambm podem estar associadas a escolhas feitas pelos usurios. A descrio do curso tpico e dos cursos alternativos feita de forma no procedimental, em linguagem coloquial e usando o jargo do negcio, pois a especicao normalmente usada para validar os casos de uso junto aos especialistas do negcio e demais envolvidos no processo. Na descrio de um caso de uso se deve informar o que feito pelo sistema em cada ao, sem haver a preocupao de relatar como a ao realizada. Por no estarmos interessados, no momento da descrevermos o casos de uso, em como as aes so realizadas, referimo-nos descrio como sendo no procedimental. Considerando a necessidade de se ter, numa especicao de caso de uso, as suas informaes bsicas (nome, pequena descrio, relao de atores, pr e ps-condies, dentre outras), e sendo o conjunto de passos para a realizao de um processo dividido em duas partes (o curso tpico e o conjunto de cursos alternativos), os formulrios usados nas organizaes para descrio dos casos de uso so normalmente organizados conforme a Figura 4.1. O nmero/nome do caso de uso, a relao de atores, a descrio abreviada e, possivelmente, as pr e ps-condies cam no cabealho. As prticas comumente adotadas para a descrio dos casos de uso recomendam: Tratar as alternativas mais frequentes primeiro e as menos frequentes em

48

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM

Figura 4.1: Leiaute tpico do formulrio de descrio de casos de uso.

cursos alternativos subsequentes, ou seja, sempre procurando descrever antes o comportamento mais tpico (da o nome de curso tpico para o primeiro bloco de passos) e depois a(s) variao(es) mais tpica(s) desse comportamento. Essa regra deve ser aplicada recursivamente, ou seja, se existe um comportamento mais frequente dentro de um comportamento alternativo, tratamos o mais frequente primeiro. No exemplo de descrio da Tabela 4.2, informamos no passo 1 do curso tpico que o sistema determina que o usurio cuja senha ser trocada o prprio operador; isso porque essa alternativa a ideal ou a mais frequente. Note que a possibilidade de ele no ser o prprio operador tratada no passo 1 do curso alternativo 1. Evitar o uso de expresses do tipo "Se... ento...", ou seja, devemos informar que

4.3. ESPECIFICANDO O CURSO TPICO E OS CURSOS ALTERNATIVOS

49

ocorre a situao mais tpica e, nos cursos alternativos, tratamos a(s) outra(s) possibilidade(s). Por exemplo, se um participante do processo pode responder "sim" ou "no" a uma pergunta do sistema e se, por exemplo, ele responde "sim" mais frequentemente a tal pergunta, assumir inicialmente que ele responder "sim" e, em um curso alternativo seguinte, assumir que ele responder "no". Usar, na especicao de repeties (loops) em um caso de uso, blocos "Para cada..." ou "Para todos...". Veja os exemplos no passo 3 do curso tpico (CT) e no passo 1 do curso alternativo (CA) 1 da Tabela ??. Numerar os passos do curso tpico e de cada curso alternativo, iniciando de 1 (um) para que possam ser facilmente referenciados em outras partes da especicao. mais usual numerar os passos dos cursos alternativos sempre iniciando de 1 (um), conforme os exemplos das Tabelas 4.3 e ??. Outra maneira prexando a numerao com o nmero do curso alternativo (exemplos: 1.1 e 1.1.1, para passo 1 do curso alternativo 1 e passo 1 do curso alternativo 1.1, respectivamente). Eu prero a primeira maneira, por ser a mais simples. Referenciar um outro caso de uso quando ocorre uma incluso ou uma extenso, explicitando a "chamada" no ponto da descrio do caso de uso que chama. Normalmente se usa a expresso "Executar caso de uso tal" no passo onde essa chamada deve ocorrer. No caso de uma incluso, o caso de uso que chama o de onde parte o relacionamento de incluso; no caso de uma extenso, a chamada feita no caso de uso aonde chega o relacionamento de extenso. Uma regra bsica a de que incluses so especicadas como chamadas nas descries do curso tpico e extenses como chamadas em um dos cursos alternativos. A ttulo de ilustrao do que acabamos de apresentar, veja nas Tabelas 4.2 e 4.3 (a Tabela 4.3 uma continuao da Tabela 4.2) um exemplo de descrio de caso de uso de troca de senha de acesso em um sistema de monitoramento remoto e, nas Tabelas 4.4, um exemplo de descrio de um caso de uso de acionamento de rels em um sistema de automao, dando uma sugesto de como tratamos repeties e chamadas a outros casos de uso. Note que, no exemplo da Tabela 4.3, mencionamos um curso de exceo. Esses cursos so cursos alternativos normalmente associados a possveis falhas no sistema. Entendemos que esses cursos s precisam ser mencionados se suas ocorrncias acarretarem impacto aprecivel, seja no negcio sendo automatizado, seja no restante da execuo do sistema. Por exemplo, se um erro do sistema demandar a execuo de um outro caso de uso ou uma forma diferente de interao com o usurio, esse erro precisar ser tratado como um curso de exceo. Costumo exemplicar esse impacto citando o exemplo do m da ta de impresso de um sistema de caixa de supermercado, quando ela ocorre no meio de uma lista de compras. O que precisa ser

50

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM

Tabela 4.2: Exemplo de descrio de caso de uso de troca de senha de acesso (cabealho e curso tpico).
Caso de Uso: Trocar senha de acesso Propsito: Para o usurio trocar sua senha de acesso ao sistema. Descrio geral: O sistema atualiza os arquivos de senha com a nova senha do usurio. Este caso de uso includo pelo caso de uso Alterar Senha de Acesso Outro Usurio, para a troca de senhas de outro usurio pelo Administrador de Usurios. Atores: Ator do caso de uso chamador (Alterar Senha de Acesso Outro Usurio): o prprio usurio para a troca de sua prpria senha, ou o Administrador de Usurios, na troca da senha de outro usurio do sistema. Iniciador: Pr-condies: Operador autenticado no sistema. Operador habilitado a executar essa funcionalidade. Ps-condies: Caso sucesso: usurio tem sua senha trocada no arquivo de senha para acesso ao sistema e no arquivo de senha de cada diretrio das cmeras s quais tem acesso. Curso tpico (CT) 1. Sistema determina que o usurio cuja senha ser trocada o prprio operador. 2. Sistema obtm o username e o nome completo do usurio cuja senha est sendo trocada. 3. Sistema exibe formulrio com os dados obtidos, um campo para a informao da senha atual, um campo para o fornecimento da nova senha e um campo para uma cpia da nova senha. Exibe as teclas Alterar Senha e Sair. 4. Operador informa senha atual. 5. Operador informa a senha nova. 6. Operador informa novamente a nova senha. 7. Operador pressiona o boto Alterar Senha. 8. Sistema verifica que a senha atual vlida. 9. Sistema verifica que as duas cpias da nova senha so idnticas. 10. Sistema obtm do perfil do usurio as cmeras s quais tem acesso. 11. Sistema criptografa senha. 12. Sistema armazena a nova senha criptografada em todos os diretrios correspondentes s cmeras s quais tem acesso, sobrescrevendo a senha anterior. 13. Sistema armazena a nova senha criptografada no arquivo de senhas para acesso s suas funcionalidades, sobrescrevendo a senha anterior. 14. Sistema informa sucesso na operao de troca de senha e exibe tecla Sair para o operador. ** Fim do Caso de Uso **

4.3. ESPECIFICANDO O CURSO TPICO E OS CURSOS ALTERNATIVOS

51

Tabela 4.3: Exemplo de descrio de caso de uso de troca de senha de acesso (cursos alternativos e de exceo).
Cursos alternativos (CA) CA 1: Passo 1 do CT - Sistema determina que o usurio cuja senha ser trocada no o prprio operador 1. Sistema obtm o username e o nome completo do usurio cuja senha est sendo trocada. 2. Sistema exibe formulrio com os dados obtidos, um campo para o fornecimento da nova senha e um campo para uma cpia da nova senha. Exibe as teclas Alterar Senha e Sair. 3. Operador informa a senha nova. 4. Operador informa novamente a senha nova. 5. Operador pressiona o boto Alterar Senha. 6. Volta ao passo 9 do CT. CA 1.1: Passo 5 do CA 1 - Operador pressiona o boto Sair. ** Fim do Caso de Uso ** CA 2: Passo 4 em diante do CT Usurio pressiona o boto Sair ** Fim do Caso de Uso ** CA 3: Passo 8 do CT Sistema verifica que senha atual no vlida 1. Sistema informa que senha atual no vlida e exibe as teclas Voltar. 2. Usurio pressiona a tecla Voltar. 3. Volta ao passo 1 do curso tpico. CA 4: Passo 9 do CT As duas cpias da nova senha no so idnticas 1. Sistema informa que as duas cpias da nova senha no so idnticas e exibe as teclas Voltar e Sair. 2. Usurio pressiona o boto Voltar. 3. Volta ao passo 1 do curso tpico. CA 4.1: Passo 2 do CA 4 Usurio pressiona a tecla Sair ** Fim do Caso de Uso ** Cursos de exceo (CE) CE 1: Passo 12 ou 13 do CT No foi possvel trocar a senha em um ou mais arquivos de senhas 1. Sistema desfaz as trocas de senhas j feitas. 2. Sistema registra erro no arquivo de log. 3. Sistema gera uma ocorrncia para o Administrador. 4. Sistema informa insucesso na troca de senhas e exibe a tecla Voltar. 5. Usurio pressiona a tecla Voltar. 6. Volta ao passo 1 do CT.

52

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM

Tabela 4.4: Exemplo de descrio de casos de uso ilustrando repeties e referncia a outro caso de uso.
Caso de Uso: Propsito: Rels e seus estados Produzir uma relao dos rels e seus estados (se ligados ou desligados). Descrio O supervisor de segurana visualiza a relao de nmeros, nomes e Geral: estados dos rels, podendo ativ-los ou desativ-los, caso esteja habilitado para tal. Atores: Supervisor de segurana (usurio). Iniciador: Supervisor de segurana. Pr-condies: Usurio autenticado no sistema. Usurio habilitado a executar essa funcionalidade. Ps-condies: Caso sucesso: Relao de rels (nmeros e nomes) e seus estados. Curso tpico (CT) 1. Sistema obtm dos parmetros o nmero de rels e seus nomes. 2. Sistema verifica que usurio est habilitado para alterar os estados dos rels. 3. Para cada rel, o sistema exibe a. o nmero do rel, b. o nome do rel, c. dois radio buttons (ativados), definindo-os com o estado correspondente ao estado corrente do rel. 4. Sistema exibe as teclas Sair e Ligar/Desligar rels. 5. Usurio define novos estados dos rels. 6. Usurio pressiona a tecla Ligar/Desligar rels. 7. Executar caso de uso Acionar rels. 8. Volta ao passo 1 do CT. Cursos alternativos (CA) CA 1: Passo 2 do CT Usurio no est habilitado para alterar os estados dos rels 1. Para cada rel, o sistema exibe a. o nmero do rel, b. o nome do rel, c. dois radio buttons (no ativados), definindo-os com o estado correspondente ao estado corrente do rel. 2. Sistema exibe a tecla Sair. 3. Usurio pressiona Sair. ** Fim do Caso de Uso ** CA 2: Passo 6 do CT Usurio pressiona a tecla Sair ** Fim do Caso de Uso ** Cursos de exceo (CE) No h

4.4. ERROS FREQUENTES E MS PRTICAS DE MODELAGEM

53

feito? Reiniciar a impresso do primeiro item quando a ta for trocada? Imprimir uma observao na nova ta ou simplesmente continuar a imprimir como se nada tivesse acontecido? Quando esse evento ocorrer, o supervisor de vendas precisar executar alguma outra funcionalidade do sistema? Note tambm nas Tabelas 4.2 e 4.4 como restringimos a aplicao das ps-condies s situaes de sucesso de execuo dos casos de uso. Em determinadas situaes no to trivial denir se um curso alternativo ou de exceo. Nesses casos acho que no precisamos perder muito tempo tentando descobrir se um curso alternativo ou de exceo. Existe, no entanto, uma tcnica que pode ser til para voc estabelecer essa diferena, se voc est muito preocupado com ela: cursos alternativos normalmente so trilhados por opes que os atores fazem durante a interao com o sistema; cursos de exceo so as "opes" que o sistema faz. Como j dissemos, a UML no dena um padro de descrio de casos de uso e a forma de especicar casos de uso que foi apresentada acima se alinha com o que se observa na prtica e com o que se encontra na bibliograa que trata desse assunto1 . Nada impede, no entanto, que denamos um novo padro dentro da organizao ou para um sistema em particular. Cabe ainda mencionar que casos de uso so bem especicados usando os diagramas de atividade (DAs) da UML, que veremos no Captulo 8.

4.4 Erros Frequentes e Ms Prticas de Modelagem

Apresentamos a seguir alguns erros e ms prticas de modelagem.

Associao Entre Atores

A comunicao entre dois ou mais atores s de interesse para o negcio quando necessria para a realizao colaborativa de alguma funcionalidade do sistema. um tanto frequente encontrarmos diagramas contendo associaes diretas entre dois atores em um diagrama numa tentativa de se especicar um caminho (que eventualmente existe) de comunicao entre os atores. Se indivduos trocam informao necessria para a realizao colaborativa de algum caso de uso, esse
Sobre padres de descrio de casos de uso, fao uma especial referncia ao livro Writing Effective Use Cases, de Alistair Cockburn ([2]), e recomendo a pesquisa e leitura das inmeras pginas que ele e outros autores mantm na Internet.
1

54

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM

processo deve ser modelado como um caso de uso, e a comunicao entre os atores deve ser feita no diretamente, mas sim por meio desse caso de uso. No h, portanto, sentido em haver associao entre dois atores sem que haja um processo representado por um caso de uso entre eles.

Casos de Uso Muito Pequenos ou Muito Grandes

Outra prtica incorreta identicar-se casos de uso que representam passos individuais, operaes ou aes dentro de um processo. Casos de uso representam funes do sistema e, tipicamente, envolvem um nmero signicativo de passos (costumo dizer que casos de uso so mais para "gordinhos"). Alm dos casos de uso que representam funcionalidades disponveis para os usurios do sistema, novos casos de uso podem ser criados nas seguintes situaes: 1. Quando existe um comportamento comum a dois ou mais casos de uso, contanto que o nmero de passos comuns justique essa fatorao. O novo caso de uso passa a constar do diagrama, sendo includo pelos casos de uso originais; 2. Extraindo comportamentos complexos (com nmeros signicativos de passos na especicao), obrigatrios ou variantes de dentro de casos de uso. Assim, os novos casos de uso aparecero no diagrama, sendo includos pelos casos de uso originais ou os estendendo. A situao 2 est relacionada a casos de uso muito grandes, correspondendo a descries muito longas, o que considero uma prtica "abominvel". Devemos lembrar que as descries servem, em um primeiro momento, para validar com os usurios o nosso entendimento a respeito de suas necessidades. Se a descrio longa demais, o usurio "dorme" ao l-la, ca com preguia de ler, valida de qualquer maneira... E isso no bom! Em decorrncia disso, procure evitar o uso de casos de uso do tipo "manter", que tratam da incluso, excluso, alterao e pesquisa de informaes em um cadastro. Esses casos de uso so conhecidos como casos de uso "CRUD", de Create, Read, Update e Delete. Se tratarmos essas quatro, diramos, subfuncionalidades em um nico caso de uso, provavelmente produziremos uma descrio muito grande, principalmente porque as regras de negcio e de integridade aplicveis so normalmente muito diferentes para cada uma delas. Por exemplo: s se pode incluir um item em um cadastro se ele ainda no consta do cadastro; s se pode excluir um item do cadastro desde que ele exista e no seja referenciado por um item de outro cadastro;

4.4. ERROS FREQUENTES E MS PRTICAS DE MODELAGEM s se pode detalhar um item em uma consulta se ele consta do cadastro;

55

s se pode atualizar um item se ele consta do cadastro e no estiver sendo referenciado por um item de outro cadastro. Sempre considere, portanto, a possibilidade de dividir esses casos de uso em quatro, usando casos de uso "manter" unicamente em situaes de cadastros bem simples. Em caso de dvida, a melhor mtrica o tamanho da descrio: a meu ver, mais do que cinco pginas de descrio j muito.

Atores "Voadores" e Atores "Gordinhos"

Atores no "voam" no modelo. Cada ator est associado a, pelo menos, um caso de uso do modelo. Se isso no ocorre para algum ator, remova-o do modelo. Um determinado ator tipicamente no interage com o sistema de muitas e distintas formas. Se a descrio do papel que interpreta longa e compreende atividades independentes entre si, quase certamente h mais de um papel sendo descrito. Nesse caso, devemos separar os atores, um para cada papel.

Complexidade Visual dos Modelos

Modelos visualmente complexos dicultam seu entendimento. O mesmo acontece com modelos contendo elementos e textos diminutos. Quando o nmero de elementos do modelo tal que somos obrigados a diminuir a escala para que ele caiba em uma pgina da documentao impressa, hora de pensarmos em dividir o modelo em partes. Existe uma regra emprica que estabelece que o nmero ideal de elementos de um modelo em uma mesma pgina deve variar de 5 a 9 ("regra do 7 +/2" sete mais ou menos dois) para uma boa compreenso. Na prtica, observamos que, contrariando a regra, modelos de casos de uso com at quinze casos de uso ainda so bem compreensveis se no h muitos cruzamentos de associaes. No caso de isso no ser possvel em funo da complexidade do negcio, somos obrigados a usar pacotes (agrupamentos) de atores e de casos de uso. Pacotes sero tratados no Captulo 11.

Fim do Caso de Uso

O indicativo de "m de caso de uso" (veja as descries das Tabelas 4.2, 4.3 e 4.4) devem signicar o encerramento do processo e o trmino do que vir a ser o programa que implementar o caso de uso, e no o m da descrio de um curso tpico ou alternativo.

56

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM

Consistncia Diagrama-Descries
Embora diagramas de casos de uso e as descries dos casos de uso sejam partes distintas do modelo, eles possuem uma coerncia mtua que deve ser observada e preservada. Essa coerncia consiste de diversos aspectos. Dentre eles: todos os casos de uso desenhados nos diagramas precisam ter suas descries feitas. Se existe uma descrio sem caso de uso ou vice-versa, sinal de que algo est errado, no diagrama ou nas descries; casos de uso que incluem ou so estendidos no possuem referncia das respectivas incluses nas especicaes (como "Executar caso de uso tal" veja exemplo no passo 7 do CT da Tabela 4.4). Se uma incluso ou extenso no aparece em algum ponto da descrio do caso de uso que inclui, seja no curso tpico, seja em um alternativo, algo est errado no diagrama ou na descrio; atores nos diagramas no podem "desaparecer" ou mudar de nome nas relaes de atores nas especicaes, ou seja, atores associados a casos de uso devem fazer parte da lista de atores dos respectivos casos de uso; atores associados a um caso de uso em um diagrama (e, portanto, tambm na relao de atores da descrio desse diagrama) devem ser mencionados de alguma forma, em algum ponto da descrio. Esses e outros lembretes, dicas e orientaes sobre casos de uso podem ser encontrados do artigo How to avoid use-case pitfalls, de Suzan Lilly ([9]), disponvel gratuitamente na Internet (em http://www.drdobbs.com/184414560, por exemplo). Vale a pena conferir.

4.5 Resumo do Captulo

A especicao ou descrio dos casos de uso dene as aes necessrias realizao das funes do sistema e em que ordem elas so realizadas. As descries dos casos de uso complementam os diagramas, ajudando a validar a interao sistema-usurio com o cliente, alm de serem artefatos importantes para o pessoal de projeto e para a equipe de formulao dos casos de testes funcionais. As descries dos casos de uso no so padronizadas pela UML. As organizaes denem seus prprios padres usualmente baseados em padres disponveis na Internet ou em livros.

4.6. EXERCCIOS PROPOSTOS

57

As descries podem ser feitas na forma abreviada ou na detalhada, dependendo do estgio no ciclo de desenvolvimento e dos riscos associados execuo do sistema. Elas especicam o nome, o propsito, a lista de atores, as pr e pscondies, alm dos uxos tpico (apenas um para um caso de uso), alternativos e de exceo (usualmente vrios) da interao entre os usurios e o sistema, dentre outras informaes. Descries so no procedurais, ou seja, especicam o que o caso de uso faz e no como ele faz.

4.6 Exerccios Propostos

1. Por que mencionamos que o caso de uso que chama outro aquele de onde parte o relacionamento de incluso ou o aonde chega o relacionamento de extenso? 2. Por que estabelecemos a regra bsica de que incluses so especicadas nas descries do curso tpico e extenses em um dos cursos alternativos? 3. Esboce o diagrama e descreva o caso Registrar Compra em um sistema para um supermercado hipottico, do qual participa o Caixa, registrando a compra, eventualmente o Cliente, quando o pagamento feito por dbito ou crdito no carto e ele precisa informar a senha, alm do Supervisor de Vendas, quando necessrio retirar um ou mais itens da lista compras ou reimprimi-la. Use sua vivncia para estabelecer os passos que compem a descrio, mas no se esquea de considerar as situaes em que: tudo d certo; voc no tem o dinheiro suciente para pagar toda a compra, podendo perceber isso durante o registro ou ao nal dele; a ta de papel da mquina registradora acaba no meio da compra e o supervisor precisa intervir com seus "superpoderes" para comandar a reimpresso da lista desde o incio; voc discorda do preo de um item que estava em oferta e pede ao caixa que retire o item da lista. Nesse caso, o supervisor tambm precisa intervir; o cdigo de barras no pde ser lido pela leitora tica e o caixa o informa pelo teclado; o cdigo do item no consta do cadastro; voc paga em carto com chip (no dbito ou no crdito) ou em dinheiro, o que bem menos frequente naquele supermercado.

58

CAPTULO 4. DIAGRAMAS DE CASOS DE USO: DESCRIES, DICAS E ERROS COMUNS DE MODELAGEM As solues encontram-se a partir da Pgina 203.

CAPTULO
59

D IAGRAMAS DE C LASSES : C ONCEITOS E E LEMENTOS B SICOS DA N OTAO

Call it a clan, call it a network, call it a tribe, call it a family: Whatever you call it, whoever you are, you need one. Jane Howard

Durante nossa conversa com os usurios, no processo de levantamento dos requisitos do sistema, alm das funes e informaes que o novo sistema precisa executar e produzir, so passadas informaes que tratam de "coisas" ou conceitos com os quais os colaboradores em uma organizao lidam no dia a dia. Por exemplo, os estoquistas lidam com peas, solicitaes de reposio e pedidos de fornecimento; o pessoal do contas a pagar lida com faturas e notas scais; o pessoal de vendas, com pedidos e clientes; e o pessoal de manuteno de campo com ordem de servio OSs , oramento, visita etc. Se esses aspectos, ou conceitos do negcio, no se relacionassem entre si e se no tivessem outros conceitos embutidos, provavelmente bastaria que registrssemos os termos com seus signicados em um dicionrio ou glossrio para que o projetista pudesse iniciar a concepo da soluo. Quase invariavelmente, no entanto, esses conceitos possuem muitos detalhes e se inter-relacionam de formas intrincadas e obedecendo a determinadas regras ou

CAPTULO 5. DIAGRAMAS DE CLASSES: CONCEITOS E ELEMENTOS BSICOS DA 60 NOTAO restries, o que nos desaconselha elaborarmos uma simples descrio textual, por mais estruturada que seja. Tomemos como exemplo a situao em que o nosso cliente especialista no negcio menciona que um pedido feito a um dos seus fornecedores deve ser associado a possivelmente mais de uma nota scal de entrega e que uma nota scal de entrega s pode conter itens referentes a um nico pedido, e que pedidos devem conter as informaes tais e tais e que devem estar associados aos clientes que os colocaram, e que notas scais devem ter as informaes tais e tais, alm, claro, dos detalhes (descrio, preo unitrio, quantidade e preo total) dos itens que as compem... ufa! Com trs ou quatro conceitos apenas a nossa especicao j cou complicada demais para uma descrio textual. Note que as informaes que so passadas no tratam de requisitos funcionais e de informao, somente, mas tambm de caractersticas diversas que precisamos capturar de alguma forma para que o sistema seja projetado e construdo corretamente. Neste captulo iniciaremos o estudo dos diagramas de classes da UML, que vm em nosso socorro para nos atender em situaes em que necessitamos especicar a estrutura da informao, que a viso esttica do sistema, especicando as relaes atemporais (que no variam com o tempo, da a ideia de viso esttica) entre os conceitos que compem o domnio. Os diagramas de classes proveem as bases de qualquer metodologia de anlise e projeto de sistemas de software orientados a objetos. No h, portanto, um sistema minimamente documentado para o qual no tenhamos desenvolvido um diagrama de classes.

5.1 Perspectivas em Diagramas de Classes

Os diagramas de classes em modelos de sistemas podem especicar as perspectivas conceitual, de especicao e de implementao. Cada perspectiva representa o problema ou a soluo com graus diferentes de abstrao:

um diagrama de classes conceitual contm apenas classes de conceito (da o nome conceitual), dotando o modelo de alto grau de abstrao, ou seja, onde os detalhes so esquecidos. Modelos conceituais especicam parte do problema a ser solucionado pelo sistema. Costumamos dizer que diagramas conceituais de

5.2. CLASSES CONCEITUAIS OU DE ENTIDADE

61

classes compem os modelos de anlise1 . Como todos os elementos colocados no modelo conceitual correspondem a "coisas" do negcio, eles so, portanto, de conhecimento dos especialistas do negcio. Se algum conceito representado no modelo conceitual estranho aos especialistas do negcio, muito provavelmente voc est sendo prematuramente fsico, ou seja, erradamente pensando em detalhes de projeto na fase de anlise. no extremo oposto, na perspectiva de implementao, representamos todos os detalhes necessrios para a implementao do sistema considerando todas as caractersticas das tecnologias escolhidas. Dizemos que, na perspectiva de implementao, estamos no nvel de abstrao zero, em que nada esquecido. Diagramas de classes de implementao so bastante extensos e complexos por detalharem as mincias da soluo que os projetistas conceberam; a perspectiva de especicao se situa entre essas duas, ou seja, comea no instante em que adicionamos ao modelo conceitual completo a primeira classe ou detalhe da soluo que o projetista est dando para o problema e termina quando obtemos o modelo de implementao. O nome especicao est associado fase em que o projetista especica a soluo que est dando para o problema. Neste texto nos manteremos no nvel conceitual, fazendo apenas "incurses" no nvel de especicao quando tratarmos de diagramas de sequncia. Os diagramas de classes que elaboraremos tero o objetivo de representar os conceitos de negcio, seus relacionamentos e restries (regras do negcio). A Figura 5.1 ilustra os sentidos de diminuio do nvel de abstrao e de aumento do detalhamento, tipicamente conforme o tempo passa, enquanto caminhamos em direo perspectiva de implementao. Os diagramas de classes compem-se de classes, dos relacionamentos entre elas e de restries do negcio. Trataremos agora da notao grca da UML para diagramas de classes.

5.2 Classes Conceituais ou de Entidade

A classe o elemento-chave em um diagrama de classes. No nvel conceitual, uma classe representa um conceito do negcio. Assim, conforme ilustra a Figura 5.2,
Modelos de anlise so os modelos conceituais elaborados durante a fase de anlise do sistema, quando nos preocupamos apenas em especicar com preciso o que o sistema far, e no como far. A informao de como o sistema far (os detalhes da soluo, portanto) fazem parte dos modelos que chamamos de modelos de especicao ou de projeto.
1

CAPTULO 5. DIAGRAMAS DE CLASSES: CONCEITOS E ELEMENTOS BSICOS DA 62 NOTAO

Figura 5.1: Nveis de abstrao em uma especicao.

Pedido, Cliente etc. so conceitos que fazem parte de um contexto tpico em uma
empresa ctcia qual demos o nome de ZYX que lida com pedidos feitos por sua clientela. As classes conceituais, tambm chamadas de classes de entidades, so entidades das quais nos interessa ter suas propriedades armazenadas em um arquivo convencional (pastas suspensas e chas), em um sistema manual, ou no banco de dados de sistema informatizado. Por essa razo, quando projetamos um sistema informatizado quase invariavelmente assinalamos no CASE2 as classes conceituais como persistentes, signicando que suas instncias sero armazenadas em banco de dados ou outro tipo qualquer de arquivo em disco para uso futuro. Os conceitos representados pelas classes conceituais so de pleno conhecimento dos participantes do negcio, ou seja, no exemplo da Figura 5.2, nosso cliente conhece bem os conceitos de Pedido, Fornecedor, Pedido de Reposio de Estoque, etc. Classes conceituais tambm so chamadas de classes de entidades e de classes de negcio. Nos diagramas de classes, as classes so representadas por retngulos com um ou mais compartimentos, dependendo do nvel de detalhamento3 . O nome da classe colocado no primeiro compartimento em negrito e
Algumas ferramentas CASE ajudam a elaborar os projetos fsicos dos bancos de dados que usaremos no sistema. Com base nas classes persistentes e seus relacionamentos e na tecnologia a ser adotada (fabricante do SGBD e verso), esses CASEs geram automaticamente os comandos de criao do banco e de suas tabelas. 3 Alguns CASEs permitem que escolhamos o nvel de detalhamento, exibindo ou no compartimentos e as informaes correspondentes em cada classe. Outros, a partir da informao de que se trata de um diagrama de anlise, apresentam classes com dois compartimentos: o do nome e o dos atributos.
2

5.2. CLASSES CONCEITUAIS OU DE ENTIDADE

63

PedidoDeReposicaoDeEstoque dataColocacao -

Pedido numero enderecoEntrega * tipoPagamento prazoEntrega 1 1 -

Cliente endereco telefone

1..* ItemDeReposicaoDeEstoque ordem quantidade * -

1..* ItemDePedido ordem quantidade * ClientePF nome ClientePJ razaoSocial contato *

1 Produto -

1 +Representante de Vendas 0..1 Fornecedor * -

codigp descricao * precoUnitario qtdEstoque

Funcionario nome

Figura 5.2: Diagrama de classes conceitual da empresa ctcia ZYX.

centralizado. Recomenda-se que os nomes sejam substantivos no singular ou expresses breves, preferencialmente com base no jargo usado no negcio. Os nomes so nicos em um espao de nomes (namespace, em ingls), pois identicam univocamente as classes no modelo. Um espao de nomes um local abstrato que fornece contexto para os itens colocados nele. Um espao de nomes um conjunto abstrato de coisas, um continer. Em um dado espao de nomes, cada elemento nele contido precisa ter um identicador um nome que deve ser nico nesse espao. Identicadores podem ser repetidos em espaos de nomes distintos, entretanto, quando compostos com o respectivo espao de nomes, se tornam nicos no domnio. Uma dada classe pode ter mais de uma cpia em um mesmo (ou em outro) diagrama do modelo. A propsito, podemos, sim, ter mais de um diagrama de classes compondo o modelo de classes de um sistema. Isso, por sinal, at bastante usual, especialmente em sistemas grandes. Durante o desenvolvimento do modelo de classes, o analista deve ter preocupao com o nome que dar a cada classe; o nome, embora deva ser um substantivo ou uma expresso breve, deve transmitir bem o conceito que a classe

CAPTULO 5. DIAGRAMAS DE CLASSES: CONCEITOS E ELEMENTOS BSICOS DA 64 NOTAO representa. Em modelos conceituais, o trabalho de dar nomes s classes , de certa forma, facilitado, j que os nomes devem ser preferencialmente retirados do jargo do negcio. Identicar classes o primeiro passo para a elaborao do diagrama de classes. s vezes nos enganamos e esquecemos de identicar uma classe ou identicamos uma ou outra erradamente. Como os modelos conceituais so detalhados ao longo do projeto, passando por modelos de especicao at virarem modelos completos, de implementao, classes necessrias, mas no identicadas, invariavelmente o sero ao longo do projeto. Classes identicadas a mais invariavelmente no sero usadas e sero eliminadas do modelo... cedo ou tarde. Com isso, no h muito como errar na identicao de classes ao longo de um projeto completo. Uma boa tcnica para descobrirmos se determinada classe ou no conceitual perguntar sobre o conceito a ela relacionado ao cliente especialista do negcio que est sendo entrevistado. Se ele no souber responder a respeito, no conhece, nunca usou aquele termo no seu dia a dia, provavelmente a classe no dever fazer parte do modelo conceitual. Objetos so instncias ou ocorrncias das classes. Cada pedido da coleo de pedidos feitos empresa ZYX, por exemplo, uma instncia da classe Pedido. As classes que podemos instanciar, ou seja, das quais podemos solicitar a criao de objetos, so chamadas de classes concretas. A classe Pedido , portanto, um exemplo de classe concreta. Outros exemplos de classes concretas na Figura 5.2 so ItemDePedido, Produto, Funcionario, ClientePF e ClientePJ.

5.3 Atributos das Classes

As informaes a respeito dos conceitos (por exemplo, o endereo e o telefone do cliente na Figura 5.2) que gostaramos de manter em um cadastro so chamadas de atributos das classes. A relao de atributos colocada no segundo compartimento do retngulo da classe, justicada esquerda. A necessidade de mantermos valores de atributos para as ocorrncias de uma determinada classe justica, como j mencionamos, a existncia dessa classe, ou seja, se desejamos armazenar as informaes sobre uma categoria de coisas em um negcio, provavelmente essa categoria se tornar uma classe no modelo de classes do sistema. Os atributos que desejamos relacionar no modelo conceitual so aqueles que os especialistas do negcio mencionam. No certo relacionarmos atributos nessa fase alm daqueles que os especialistas julgam necessrios. Podemos, claro, lembr-los de alguns atributos que so tpicos, mas eles que do a palavra nal sobre a necessidade

5.3. ATRIBUTOS DAS CLASSES

65

ou no. Tambm no certo nos preocuparmos com detalhes, como os tipos dos atributos, se cadeias de caracteres, se numricos e com qual preciso numrica etc. No modelo da Figura 5.2, a classe Fornecedor no possui atributos relacionados, o que sugere que ainda no terminamos o modelo conceitual. Em certas situaes, no entanto, no conseguimos identicar facilmente um atributo para uma classe, mas temos a intuio de que aquele conceito importante, inclusive porque se relaciona com outro(s) conceito(s) importante(s) (veja a observao feita no nal da resposta para Exerccio 1, na Pgina 210). O fato de um conceito ter relacionamento com outro tambm justica sua colocao no modelo. A razo para isso que os relacionamentos que uma classe possui com outras podem ser entendidos como atributos dessa classe. Nomes de atributos devem ser expresses breves, sem espaos em branco. Nomes de atributos, por hbito da comunidade de desenvolvedores, usam o estilo CamelCase4 , comeando com letras minsculas. usual, tambm, mesmo no nvel conceitual, suprimir cedilhas, acentos etc., desde que os nomes no quem muito confusos. Os nomes dos atributos so sucientes nos modelos conceituais. Mais adiante, no ciclo de desenvolvimento do sistema, mais especicamente na fase de projeto, devemos completar os nomes dos atributos com outros detalhes. Alm dos nomes, a notao UML um pouco mais completa para rtulos de atributos (atributos so referenciados pela UML como propriedades) :

[vi si bi l i d ad e][/]nome : t i po[mul t i pl i ci d ad e][= v al or d e f aul t ]

onde os valores entre "[" e "]" nem sempre ocorrem e:

visibilidade o caractere "-" (para privado), "+" (para pblico) ou "#" (para protegido), que indica se o atributo visvel ou no de outros objetos. Atributos privados s podem ser acessados (consultados diretamente e/ou modicados) pelos objetos que os contm. Atributos pblicos podem ser acessados por outros objetos e atributos protegidos so acessados pelos objetos que os contm ou por objetos instanciados de classes especializadas. A visibilidade deve ser omitida no modelo conceitual;
CamelCase a denominao em ingls para a conveno de se escrever palavras compostas ou mesmo frases, onde cada palavra iniciada com maisculas e sem espaos entre elas. Essa denominao associada s corcovas de um camelo. A variao mais comum grafarmos a primeira palavra da expresso em minsculas e as demais palavras da expresso iniciando em maisculas. Exemplos: dataDeNascimento, numeroDeContato etc.
4

CAPTULO 5. DIAGRAMAS DE CLASSES: CONCEITOS E ELEMENTOS BSICOS DA 66 NOTAO a "/" antes do nome indica que o atributo derivado, ou seja, seu valor pode ser determinado por um algoritmo a partir de outro(s). Por exemplo, se tivermos os atributos idade e dataDeNascimento, o atributo idade deve ser precedido da "/", j que a idade de um indivduo pode ser determinada a partir da sua data de nascimento; tipo dene o tipo de dados: inteiro, real, cadeia de caracteres, data etc.; multiplicidade indica as possveis cardinalidades5 para a ocorrncia do atributo. Se a multiplicidade omitida, signica que ela exatamente 1. Veremos multiplicidades em maiores detalhes um pouco mais adiante; o valor default o valor que o atributo assume de incio. Exemplos de rtulos de atributos:

-dataDeNascimento : Date; -/idade : int; +nomeContato : String[0..2];

O primeiro exemplo, o atributo dataDeNascimento privado e do tipo Date (data). O segundo exemplo, idade, privado, derivado (calculado) e do tipo inteiro. O terceiro exemplo, nomeContato pblico, do tipo string (cadeia de caracteres) e pode ter nenhuma, uma ou duas ocorrncias, ou seja, pode no haver nome de contato registrado ou um ou dois nomes de contato registrados. A visibilidade qual nos referimos anteriormente tem a ver com a ideia de encapsulamento, que recomenda deixarmos escondido o que no preciso ser mostrado. Aumentamos a facilidade com que damos manuteno em um sistema (manutenibilidade), denindo como privado o maior nmero possvel de atributos (e operaes, como veremos adiante). Mesmo os atributos que precisam ser "vistos" por outros objetos devem ser denidos como privados e devem ser criadas operaes pblicas de acesso para leitura e escrita a eles. Por meio dessas operaes garantimos acessos mais "policiados" aos atributos. O encapsulamento mximo sugerido pelos CASEs que, por default, atribuem visibilidade privado a cada novo atributo que adicionamos em uma classe. Se voc est interessado em detalhes da especicao para rtulos de atributos de classes, consulte o documento de superestrutura da UML ([11]).
Cardinalidade, na teoria dos conjuntos, o nmero de elementos de um conjunto. Multiplicidade na UML denota as possveis cardinalidades de um conjunto de elementos. Por exemplo, se um atributo tem multiplicidade [0..2] signica que ele pode ter nenhuma, uma ou duas ocorrncias (na UML os ".." indicam intervalos). Se um atributo possui multiplicidade [0..1], signica que ele opcional, pois pode ou no ocorrer.
5

5.4. OPERAES DAS CLASSES

67

5.4 Operaes das Classes

O terceiro compartimento do retngulo da classe contm a lista de operaes que os objetos da classe implementam para realizar suas responsabilidades. praxe, no entanto, que esses compartimentos quem vazios no modelo de anlise, pois as operaes normalmente s comeam a ser descobertas quando iniciamos o nvel de especicao, ao elaborar os diagramas de sequncia. Para o propsito de nosso curso, a notao UML sucientemente completa para os rtulos de operaes : [vi si bi l i d ad e]nome([l i st ad epar met r os])[: t i pod er et or no] onde os valores entre "[" e "]" nem sempre ocorrem e: visibilidade o caractere "-" (privado), "+" (pblico) ou "#" (protegido) que indica que a operao visvel ou no de outros objetos, do mesmo jeito que com os atributos; o nome da operao tambm formado segundo o padro CamelCase; tipo dene o tipo de retorno da operao: inteiro, real, cadeia de caracteres, data etc.; a lista de parmetros formada pelos parmetros de entrada e sada separados por vrgulas, da seguinte forma: [d i r eo]nome : t i po, onde direo (opcional) "in" ou "out" ou "inout", signicando parmetro de entrada, de sada e de entrada e sada, respectivamente. O nome e o tipo so da mesma forma que nos atributos. Os rtulos das operaes so justicados esquerda dentro do compartimento. Exemplos:

+getIdade() : int; +setDataDeNascimento (in dataNascimento :

Date);

No primeiro exemplo, a operao getIdade pblica e retorna o valor da idade, que um valor inteiro. No h parmetros de entrada ou sada. No segundo exemplo, a operao setDataDeNascimento pblica e armazena o valor da data de nascimento fornecida por meio do parmetro de entrada dataNascimento, que do tipo Date. Essa operao no retorna qualquer valor.

CAPTULO 5. DIAGRAMAS DE CLASSES: CONCEITOS E ELEMENTOS BSICOS DA 68 NOTAO Para nossos propsitos, a notao para rtulos de operaes apresentada completa o suciente. A UML especica muitos outros detalhes que podem vistos no documento de superestrutura ([11]).

5.5 Restries e Responsabilidades

As classes podem conter outros compartimentos, conforme estabelece a UML. Um quarto compartimento pode ser usado, por exemplo, para acomodar restries e responsabilidades de classes. As responsabilidades de uma classe denem a utilidade dos objetos dessa classe em um sistema. Um sistema desenvolvido segundo o paradigma de orientao a objetos assume que os objetos colaboram para a realizao dos objetivos desse sistema. O conjunto de coisas que cada objeto faz para colaborar compe as responsabilidades desse objeto. O conjunto de todas as coisas que todos os objetos fazem para colaborar compe as responsabilidades da classe desses objetos. Para realizar essas responsabilidades, os objetos executam as operaes. Costumo fazer a seguinte analogia em sala de aula: quais so as responsabilidades de cada contador (os indivduos, os objetos, instncias da classe Contador, segundo nossa terminologia) em uma organizao? Fechar o balano no nal do ms uma. Ento, para realizar essa responsabilidade, que operaes todo contador precisa fazer? Somar, diminuir, vericar voucher de lanamentos contbeis, vericar lanamentos etc. Embora, como dissemos, a UML faculte a representao de mais do que trs compartimentos, eu no conheo uma ferramenta CASE sequer que oferea suporte grco para mais de trs compartimentos. Entretanto, em todos os CASEs com os quais j trabalhei (Rose, Together, Jude, Magic Draw e Enterprise Architect) h caixas de texto na seo Propriedades de cada classe onde essas e outras informaes podem car registradas.

5.6 Resumo do Captulo

Durante o levantamento de requisitos necessitamos especicar a estrutura da informao, especicando as relaes atemporais entre os conceitos que compem o domnio. Isso feito usando os diagramas de classes da UML. Os diagramas de classes em modelos de sistemas podem especicar as perspectivas conceitual, de especicao e de implementao. Na perspectiva conceitual representamos os conceitos do domnio e os relacionamentos que eles possuem entre si. Na perspectiva de implementao, todos os detalhes precisam

5.7. EXERCCIOS PROPOSTOS

69

estar representados para que possamos implementar o sistema. A perspectiva de especicao o meio do caminho entre a perspectiva conceitual e a perspectiva de implementao, ou seja, indo do ponto em que colocamos a primeira caracterstica do projeto at o ponto imediatamente anterior ao projeto 100% especicado, pronto para ser implementado. No diagrama de classes de nvel conceitual, foco do nosso texto, representamos apenas as classes de entidade (tambm chamadas de classes conceituais) e seus relacionamentos. As classes em um diagrama de classes so representadas por retngulos com compartimentos para seus nomes, seus atributos e para as operaes que executam. Os atributos e as operaes tm formas de notao denidas pela UML. Na prximo captulo prosseguiremos com o estudo dos diagramas de classes da UML, estudando os tipos de relacionamentos e demais conceitos e elementos da notao necessrios interpretao e elaborao de diagramas de classes mais abrangentes.

5.7 Exerccios Propostos

1. Identique e nomeie as classes conceituais no texto a seguir. Lembre-se de que as classes conceituais so entidades sobre as quais nos interessa armazenar alguma informao. Relacione uma ou mais dessas informaes para cada classe identicada, no se preocupando em ser completo. Apenas pense em algumas delas como mecanismos para identicar as classes. As universidades do municpio de Sertozinho Alegre so divididas em um ou mais departamentos (Letras, Matemtica etc.). Um departamento cheado por um de seus professores, mas h casos em que esse cargo est vago. No h acmulo de chea. Os professores podem estar alocados em um ou mais departamentos. Um departamento pode ser criado sem que haja professores alocados a ele. Um aluno pode estar matriculado em mais de uma universidade e pode frequentar mais de uma disciplina na mesma universidade. As universidades podem no ter alunos matriculados. Cada departamento tem seu conjunto especco de disciplinas (pelo menos uma). Cada disciplina pode ser ministrada por um ou mais professores. Cada professor pode ministrar qualquer nmero de disciplinas. 2. Relacione e d nomes adequados a alguns atributos que voc imagina serem importantes para as classes identicadas no Exerccio 1. Adote a notao da UML para formar rtulos completos de atributos. Use visibilidades, tipos, multiplicidades e valores default que julgar mais convenientes. As solues encontram-se a partir da Pgina 210.

CAPTULO
71

D IAGRAMAS DE C LASSES : R ELACIONAMENTOS E NTRE C LASSES , C LASSES DE A SSOCIAO, I NTERFACES E R ESTRIES

Life is relationships; the rest is just details. Gary Smalley

No Captulo 5 vimos que h diversas caractersticas de um sistema que no se enquadram como requisitos, mas que precisamos capturar de alguma forma para que o sistema seja projetado e construdo. H entidades do negcio (classes) que possuem informaes (atributos) e responsabilidades (realizadas por operaes) que se relacionam por meio de associaes, atravs das quais a comunicao entre os objetos possvel. Associaes so um dos tipos possveis de relacionamentos entre classes. Neste captulo continuaremos e encerraremos o estudo de diagramas de classes da UML, apresentando outros tipos de relacionamentos que as classes podem manter entre si, alm de outros conceitos importantes que completaro o ferramental necessrio para a interpretao e elaborao de diagramas de classes de nvel conceitual.

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 72 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

6.1 Relacionamentos Entre Classes

Os conceitos identicados em um dado contexto invariavelmente se ligam de alguma forma. Relacionamentos em diagramas de classes expressam essas ligaes, que, por tambm fazerem parte do conhecimento a respeito do negcio, precisam ser capturadas e especicadas no modelo de classes. Por exemplo, as ligaes entre os pedidos feitos pelos clientes (e, reciprocamente, os clientes que zeram os pedidos) da Figura 5.2 so representadas por um dos tipos de relacionamentos possveis entre classes previstos na UML: associaes. A associao um dos tipos mais comuns de relacionamentos representados em diagramas de classes. Outros relacionamentos comuns so as generalizaesespecializaes, as agregaes, as composies e as dependncias funcionais. Trataremos cada um deles nas sees a seguir.

6.2 Associaes Entre Classes

Associaes so o tipo mais comum de relacionamentos entre classes em um diagrama de classes. No diagrama da Figura 5.2, est especicado, por exemplo, que um determinado cliente pode estar associado a qualquer nmero de pedidos (inclusive zero, ou seja, empresas ou pessoas fsicas so consideradas clientes mesmo no tendo feito qualquer pedido), e um determinado pedido est associado a somente um cliente. Por exemplo, segundo a mesma gura, o cliente Luiz Antnio pode estar associado ao pedido 225 e ao pedido 786. Associaes nos diagramas de classes especicam, portanto, as ligaes existentes entre os objetos instanciados de cada uma das classes associadas no diagrama de classes. Associaes entre objetos so instncias representadas nos modelos de classes. (ocorrncias) das associaes

As associaes so representadas nos diagramas de classes por segmentos de retas, poligonais ou arcos que ligam as classes associadas. Uma associao opcionalmente rotulada com o nome da associao, que deve ser colocado sempre que o signicado da associao no claro no diagrama. A Figura 6.1 ilustra a situao em que um determinado professor pode estar associado de duas formas distintas (se combinadas, so trs) a um determinado departamento de uma universidade: sendo o chefe do departamento, sendo o chefe do departamento e alocado como seu professor ou somente alocado como professor do departamento.

6.3. PAPIS NAS ASSOCIAES

73

Professor

aloca

chefia

Departamento

Figura 6.1: Nomes de associaes e direes de leitura.

No caso da Figura 6.1, se no colocssemos os nomes das associaes, no saberamos o que signica cada associao. Em contrapartida, se o signicado de uma associao claro no contexto do negcio, como, por exemplo, a associao entre Cliente e Pedido da Figura 5.2 (cliente est associado ao(s) pedido(s) que coloca na empresa ZYX), podemos pensar em no colocar seu nome para no aumentar a complexidade visual do diagrama. O nome da associao deve vir acompanhado do smbolo de sentido de leitura (s a ponta cheia de seta) e deve exprimir bem o signicado da associao, sendo preferencialmente um verbo na voz ativa. A vantagem de usarmos verbos na voz ativa em nomes de associaes que tambm podemos ler o nome da associao no sentido contrrio ao da seta, bastando mudar o verbo para a voz passiva (exemplos: "professor alocado a departamento"; "departamento cheado por professor").

6.3 Papis nas Associaes

As pontas das associaes (no pontos onde elas se encontram com as caixas das classes) chamam-se papis, que tambm podem ser usados para dar nomes aos papis

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 74 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Professor

+chefe

aloca

Departamento

Figura 6.2: Rtulo de papel ajudando no signicado da associao.

que as classes representam nas associaes. Quando no especicamos o rtulo do papel (que deve car bem junto do ponto onde a associao encontra a caixa da classe), este leva o nome da classe. De volta Figura 5.2, Representante de Vendas o papel que Funcionrio desempenha quando est associado a ClientePJ. Na Figura 6.2, chefe o papel representado por Professor quando associado a Departamento por meio da associao de chea. Repare que, neste caso, omitimos o nome da associao pelo fato de o rtulo do papel do professor j caracterizar bem que a associao se refere chea do departamento. Como dissemos, se no colocarmos o rtulo do papel, este leva o nome da classe. Sendo assim, na Figura 5.2 lemos: "um ClientePJ est associado a zero ou a um Representante de Vendas", ao invs de dizermos "um ClientePJ est associado a zero ou a um Funcionrio", como faramos se o rtulo do papel no tivesse sido especicado. Da mesma forma, na Figura 6.2 lemos: "Departamento cheado por chefe", ao invs de "Departamento cheado por Professor", caso o rtulo do papel no tivesse sido especicado.

6.4. MULTIPLICIDADES NAS ASSOCIAES

75

6.4 Multiplicidades nas Associaes

As pontas de uma associao entre classes devem especicar tambm as multiplicidades, que indicam quantas instncias das classes podem participar da associao. Essa indicao feita por meio dos valores mximo e mnimo. As multiplicidades podem ser: obrigatrias, quando especicadas por meio de um nmero natural diferente de zero; opcionais, se "0..1"; multivaloradas, se "*" ou "0..*" (as duas notaes tm o mesmo signicado). Intervalos de multiplicidades podem ser especicados com os ".." (exemplo, "1..3", para 1, 2 ou 3, ou de 1 a 3). Se houver mais de um intervalo, eles so especicados entre vrgulas (exemplos: "1..3, 5..7", para 1, 2, 3, 5, 6 ou 7).

6.5 Navegabilidade nas Associaes

As pontas das associaes tambm podem conter o sinal de navegabilidade (ver seta aberta na ponta da associao entre Pedido e Cliente na Figura 5.2), que representa a responsabilidade que um objeto tem de localizar o(s) objeto(s) da outra classe com o(s) qual(quais) se associa. A navegabilidade representada na Figura 5.2 signica que objetos da classe Pedido "tm a responsabilidade" de localizar os clientes a eles relacionados que, em outras palavras, quer dizer que os objetos da classe Pedido devem dispor de recursos para localizar os clientes a eles relacionados. Isso equivale a dizer no negcio que um pedido deve conter informaes para a localizao do cliente que o colocou, possivelmente o nome dele ou seu cdigo para a localizao no cadastro de clientes. Em um sistema, essa responsabilidade seria realizada por ponteiros ou chaves estrangeiras. As navegabilidades podem ser unidirecionais (uma seta), bidirecionais (duas setas ou nenhuma seta, se for assim convencionado) ou indeterminada (nenhuma seta). Navegabilidades so usualmente raras em modelos conceituais, pois normalmente reetem a preocupao dos projetistas com a rapidez de acesso aos objetos na memria e a economia de espao em disco, preocupaes estas associadas fase de projeto dos sistemas. Eu usaria (como usei na Figura 5.2) a navegabilidade de pedido para cliente para salientar a eventual necessidade manifestada pelo usurio em determinar ao cliente dado o pedido que ele fez.

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 76 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Funcionario

+subordinado *

+chefe 0..1

Figura 6.3: Autoassociao chefe-subordinado.

Pessoa +esposa 0..1

+esposo 0..1 casa

Figura 6.4: A autoassociao do matrimnio.

6.6 Autoassociaes de Classes

Autoassociaes so associaes entre objetos da mesma classe. So representadas no diagrama de classes usando-se poligonais ou arcos partindo de uma classe e chegando nela prpria. A Figura 6.3 ilustra a situao em que um determinado subordinado pode estar sem chefe ou ter no mximo um chefe e um determinado chefe pode ter qualquer nmero de subordinados, eventualmente nenhum (a situao, por exemplo, de algum que foi nomeado chefe de um setor que est sendo criado). A Figura 6.3 ilustra, ainda, que chefe e subordinados so funcionrios. Uma questo que frequentemente causa dvidas surge quando, por exemplo, uma pessoa est associada a outra pelo casamento: de um lado da associao, uma pessoa assume o papel de esposo e, do outro, de esposa (ver Figura ??). A dvida normalmente acontece porque lemos "um esposo est casado com zero ou uma esposa"... mas, na possibilidade de no estar casado, a pessoa no cumpre o papel de esposo. A forma correta de entendermos o diagrama que pode no haver a instncia da associao de casamento entre duas pessoas. Havendo a instncia, uma pessoa

6.7. MULTIPLICIDADES NO PROJETO E NA IMPLEMENTAO

77

Galinha bota 1 1..*

Ov o

Figura 6.5: Modelo de classes conceitual do Sistema de Controle de Galinhas e Ovos SCGO.

assume o papel de esposa e outra de esposo.

6.7 Multiplicidades no Projeto e na Implementao

A questo da autoassociao do matrimnio da Figura 6.4 nos leva a discutir outra questo que sempre vem tona em sala de aula, que ilustraremos com a seguinte situao fantasiosa: o SCGO (Sistema de Controle de Galinhas e Ovos) que iremos desenvolver precisa manter um cadastro de galinhas e de ovos, associando cada ovo galinha que o botou e cada galinha aos ovos que botou (os ovos sero identicados um a um). Nosso usurio se interessa por ter cadastradas apenas galinhas que tenham posto pelo menos um ovo, ou seja, toda galinha cadastrada no sistema deve estar associada a pelo menos um ovo. Ns estamos exagerando um pouco, claro, s para poder levantarmos a questo. O modelo conceitual de classes que passamos ao projetista do sistema cou como o da Figura 6.5. Algum tempo mais tarde, o projetista disse que no era possvel projetar o banco de dados porque no era possvel responder clssica e losca pergunta: quem seria instanciado primeiro, o ovo ou a galinha? Segundo o modelo conceitual, no seria possvel armazenar os dados de um novo ovo na tabela OVO antes de ter os dados da galinha que o botou armazenados na tabela GALINHA; e que no poderia armazenar os dados de uma nova galinha sem ter os dados de pelo menos um ovo que ela botou armazenados no banco de dados (veja as multiplicidades das pontas da associao bota na Figura 6.5. A pergunta que normalmente me fazem em sala de aula : "Ns, analistas, devemos exibilizar o modelo conceitual, trocando a multiplicidade 1..* por 0..* para facilitar os trabalhos do projetista e do

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 78 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES programador ou devemos expressar no modelo o que reza o conceito?" Respondo pergunta com outras perguntas: "De que modelo estamos tratando? De quem vocs acham que o problema de projeto e implementao do banco de dados, anal: dos analistas ou dos projetistas/programadores?" As minhas perguntas, feitas da maneira a facilitarem a resposta, conduzem resposta (bvia) que devemos expressar, no modelo conceitual, o que reza o conceito, abstraindo os detalhes de implementao. O problema , portanto, do projetista e do programador. O projetista provavelmente decidir por "relaxar" as restries de integridade do banco de dados, mas determinar que o programador abra uma transao de banco de dados para garantir, por programa, que as multiplicidades do modelo conceitual sejam obedecidas.

6.8 Especializaes-Generalizaes
A nossa empresa ctcia ZYX necessita manter em seu cadastro dois tipos diferentes de clientes: pessoas fsicas (classe ClientePF) e pessoas jurdicas (classe ClientePJ), que possuem semelhanas e diferenas entre si: os endereos e telefones devem ser armazenados nos cadastros para todos os clientes, independentemente se so pessoas fsicas ou jurdicas, os nomes so necessrios apenas para as pessoas fsicas e as razes sociais e nomes de contato so necessrios apenas para as pessoas jurdicas. Utilizando o relacionamento de especializao-generalizao, os atributos, operaes e relacionamentos comuns cam na classe que chamamos de superclasse ou classe-base, enquanto as diferenas vo para as subclasses, tambm chamadas de classes derivadas. Estas herdam da superclasse os atributos, as operaes e os relacionamentos comuns. Sendo assim, os clientes pessoas fsicas do modelo da Figura 6.6 (que um trecho do diagrama da Figura 5.2) tm endereo, telefone e nome como atributos e esto associados a qualquer nmero de pedidos. Os clientes pessoas jurdicas, alm do endereo e telefone, tm como atributos a razo social e o contato e esto associados a qualquer nmero de pedidos. Podem possuir, ainda, um representante de vendas, que um funcionrio da ZYX. Os relacionamentos de generalizao-especializao so representados por setas com pontas triangulares vazadas. Sempre me rero a esse tipo de relacionamento como sendo de generalizaoespecializao porque ele entendido como uma generalizao (quando lemos no

6.8. ESPECIALIZAES-GENERALIZAES

79

DeEstoque -

Pedido numero enderecoEntrega * tipoPagamento prazoEntrega 1 1..* ItemDePedido ordem quantidade * ClientePF nome 1 -

Cliente endereco telefone

eEstoque

ClientePJ razaoSocial contato *

1 Produto -

1 +Representante de Vendas 0..1 Fornecedor * -

codigp descricao * precoUnitario qtdEstoque

Funcionario nome

Figura 6.6: Relacionamento de generalizao-especializao representado pela seta de ponta vazada (trecho da Figura 5.2).

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 80 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Cliente

ClientePJ

ClientePF

Figura 6.7: Generalizao-especializao representada na forma direta ou oblqua.

sentido da seta) e como especializao (quando lemos no sentido oposto ao da seta). Portanto, o sentido da seta indica a generalizao; o sentido oposto indica a especializao. Assim, Cliente uma generalizao de ClientePF e de ClientePJ, enquanto ClientePF e ClientePJ so especializaes de Cliente. As generalizaes so bem lidas como " um tipo de": na Figura 6.6, cliente pessoa fsica um tipo de cliente, e cliente pessoa jurdica um (outro) tipo de cliente. Alis, quando um bom nome para uma associao " um tipo de", devemos vericar se a associao deve dar lugar a um relacionamento de generalizao-especializao. Se a ponta da seta de um relacionamento de generalizao-especializao no for vazada, ele no um relacionamento de generalizao-especializao ou no estamos falando de UML. Alis, a necessidade do uso da forma grca correta vale para todos os demais smbolos usados na notao, que bastante rigorosa a esse respeito. As formas de apresentao de generalizaes-especializaes esto nas Figuras 6.7 e 6.8, indistintas quanto ao signicado, conforme a UML. A forma da Figura 6.7 chamada de direta ou oblqua, e a da Figura 6.8, de retilnea. Cabe aqui explicar um detalhe sobre outro tipo de visibilidade de atributos e mtodos que deixamos de explicar no Captulo 5 porque ainda no tnhamos visto os relacionamentos de especializao-generalizao: os atributos e mtodos protegidos.

6.8. ESPECIALIZAES-GENERALIZAES

81

Cliente

ClientePJ

ClientePF

Figura 6.8: Generalizao-especializao representada na forma retilnea.

Em uma classe, ser protegido signica que o atributo ou mtodo protegido do acesso externo de forma geral, mas pode ser acessado pelos mtodos das classes que a especializam. Um atributo ou mtodo protegido tem sua visibilidade denotada por um #. Como ilustra o diagrama da Figura 6.9a, o atributo nome da classe Funcionario s pode ser acessado diretamente pelo prprio objeto instanciado dessa classe, porque o atributo est marcado como sendo privado. Nesse caso, nem um objeto da classe Engenheiro tem acesso direto a esse atributo. J no diagrama da Figura 6.9b, o atributo nome pode ser acessado diretamente por objetos das classes Funcionario e Arquiteto. H situaes em que no queremos que uma classe possa ser instanciada, ou seja, que no possa haver objetos criados dela (ao contrrio das classes concretas, que foram vistas no Captulo 5). Essas classes so chamadas de classes abstratas. Por exemplo: na Figura 6.6, a classe Cliente foi denida como uma classe abstrata porque no pode haver objetos instanciados dessa classe, ou seja, no h nenhum cliente da ZYX que no seja pessoa fsica nem pessoa jurdica (eles tm de ser, obrigatoriamente, instncias de ClientePF ou ClientePJ quem nos disse isso foi o especialista do negcio na ZYX). Classes abstratas existem no modelo somente para agruparmos em uma s classe os atributos, operaes e associaes comuns a duas ou mais classes. A esse

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 82 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Funcionario nome
#

Funcionario nome

Engenheiro
Engenheiro Arquiteto

(a)

(b)

Figura 6.9: Atributos privado (a) e protegido (b) de classes especializadas denindo acessos distintos a objetos das classes que especializam.

processo de agrupamento, em superclasses, de atributos e operaes comuns a duas ou mais classes damos o nome de fatorao. Classes abstratas so denotadas na UML com seus nomes em itlico ou colocando abstract logo abaixo de seus nomes, dentro do compartimento do nome na caixa da classe. Por m, nada impede que faamos especializaes de especializaes em qualquer quantidade de nveis. A nica recomendao que muitos nveis de especializao (mais do que cinco, conforme cita a literatura) prejudicam o entendimento do modelo.

6.9 Conjuntos de Generalizao e Parties

Conjuntos de generalizao so agrupamentos de relacionamentos de generalizaesespecializaes em categorias. Por exemplo, podemos especializar uma pessoa quanto ao sexo e quanto ao estado civil. Essas categorias so ortogonais (independentes umas das outras), ou seja, uma mulher pode ser casada, solteira ou viva etc., assim como um homem. Cada categoria representa um conjunto de generalizao. A Figura 6.10

6.9. CONJUNTOS DE GENERALIZAO E PARTIES

83

Solteiro

Estado Civil Homem Sexo

Casado

Pessoa

Vivo

Mulher Divorciado

Separadojudicialmente

Figura 6.10: Conjuntos de generalizao em diagramas de classes.

mostra a notao padronizada pela UML. Repare que na Figura 6.10 as linhas tracejadas cortam os relacionamentos relativos ao mesmo conjunto de generalizao. Alm de poderem se agrupar em conjuntos de generalizao, as especializaes tambm podem ser categorizadas em parties. Uma partio pode ser: completa (complete), quando as especializaes geram todas as instncias dos

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 84 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

(a)

(b)

(c)

Figura 6.11: Parties em especializaes.

objetos (tambm chamada de cobertura total); incompleta (incomplete), quando os objetos podem ser instncias das especializaes ou da generalizao (tambm chamada de cobertura parcial); disjunta (disjoint), quando as instncias so de um tipo ou (exclusivo) de outro. Esse o padro quando no h nenhuma marcao de sobreposio no modelo; sobreposta (overlapping), quando as instncias podem ser de um tipo e de outro(s). A Figura 6.11a ilustra as situaes em que a classe Pessoa especializada de forma completa em Mulher e Homem (no h, segundo o modelo, uma instncia de Pessoa que no seja mulher ou homem) e de forma disjunta (no h, segundo o modelo, uma instncia que seja parte mulher e parte homem). A Figura 6.11a ilustra ainda as situaes de as pessoas estarem empregadas ou desempregadas, ou seja, uma pessoa uma instncia da classe Pessoa, simplesmente, ou uma instncia da classe Pessoa Empregada. A Figura 6.11b ilustra a situao em que uma pessoa atua como um vendedor e um gerente de vendas, ou seja, tem caractersticas dos dois. A Figura 6.11c ilustra situao similar, em que uma pessoa pode atuar como mdico e ser paciente concomitantemente, alm de poder no ser nem mdico nem paciente. importante observarmos que especializaes completas sugerem que as superclasses sejam classes abstratas, j que nessas especializaes s podemos instanciar as subclasses.

6.10. AGREGAES

85

Funcionario 1 *

Dependente

Figura 6.12: Relacionamento de agregao funcionrio-dependente.

6.10 Agregaes
H situaes em que precisamos especicar conceitos que representam conjuntos de entidades. Nesse caso, alm das entidades que correspondem s partes, os conjuntos tambm so entidades que devem ser representadas em nosso modelo. O conjuntos e as partes so ligadas entre si por meio de relacionamentos ditos de agregao pois conjuntos agregam suas partes. Exemplos de conjuntos e suas partes so times de futebol e seus jogadores, empregados e seus dependentes, departamentos e suas divises, divises e seus colaboradores, etc. O relacionamento de agregao um relacionamento do tipo todo-parte; representamos o "todo" associado s "partes" que o compem. A UML possui uma notao especial para agregaes: um losango vazado, conforme ilustrado na Figura 6.12. Nessa gura representamos os funcionrios em uma organizao e seus dependentes: cada dependente est associado a um funcionrio especco, enquanto funcionrios tm qualquer nmero de dependentes, eventualmente nenhum. A Figura 6.13 ilustra a situao em que um time composto de 11 a 22 jogadores e que cada jogador ou no est associado a um time ou est associado a, no mximo, um time. A Figura 6.14 ilustra a situao em que os departamentos de uma organizao so subdivididos em no mnimo duas divises e estas so divididas em no mnimo duas coordenaes. Cada coordenao est associada sua respectiva diviso e cada diviso ao seu respectivo departamento. As agregaes so bem lidas com o verbo "tem". Nos exemplos anteriores, funcionrios tm dependentes, times tm jogadores e departamentos tm divises, que tm coordenaes.

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 86 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Time 0..1 11..22

Jogador

Figura 6.13: Relacionamento de agregao time-jogador.

Departamento 1 2..*

Div isao 1 2..*

Coordenacao

Figura 6.14: Relacionamento departamento-diviso-coordenao.

Agregaes so entendidas por muitos autores como "placebos" de modelagem, ou seja, no adicionam semntica ao modelo que justique seu emprego. Dessa forma, as agregaes ilustradas nas Figuras 6.12, 6.13 e 6.14 poderiam ser substitudas por associaes simples, sem nenhuma perda de expressividade. Isso devido colocao das multiplicidades e possibilidade de colocar o rtulo "tem" dando nome associao. Portanto, agregaes s se justicam quando estamos em um nvel de abstrao to alto que no representamos sequer as multiplicidades.

6.11 Agregaes Compostas (ou Composies)

Agregao composta, tambm chamada composio, um tipo mais forte de agregao. tambm um relacionamento todo-parte representado por um losango cheio (veja a Figura 6.15). A principal, e fundamental, diferena entre composies e agregaes que nas composies as partes no podem pertencer, em um mesmo instante, a mais do que um todo. Como consequncia, se o todo deixa de existir, as partes tambm deixam. importante notar que, quando permitido pela

6.11. AGREGAES COMPOSTAS (OU COMPOSIES)

87

Funcionario 1 *

Dependente

Figura 6.15: Agregao composta.

multiplicidade, uma parte pode ser removida da composio antes de ela deixar de existir. A Figura 6.15 traz de volta a questo do "placebo" de modelagem, especicando, na forma de composio, o relacionamento entre um funcionrio de uma organizao e seus dependentes. A pergunta que provavelmente voc se far : qual , anal, a diferena entre os signicados dos modelos das Figuras 6.12 e 6.15? A resposta : neste caso, absolutamente nenhuma. Isso acontece porque, nos dois casos, se um funcionrio deixa de existir, os seus dependentes tambm deixam, pois no pode haver dependentes no ligados a funcionrios (a multiplicidade obrigatria 1 signica isso). Quando uma entidade parte est associada no diagrama a somente uma entidade todo, como na Figura 6.15, a composio pode ser reduzida a uma agregao que, por sua vez, por se tratar de um "placebo", pode ser eliminada do modelo, reduzindo-se a uma simples associao. As composies so indispensveis quando, no modelo, uma entidade parte est associada a mais de uma entidade todo e queremos especicar que uma instncia da parte no pode estar associada, ao mesmo tempo, a mais de uma instncia de entidade todo. Por exemplo, segundo a Figura 6.16, se um determinado funcionrio est associado a uma determinada empresa, no pode estar associado, ao mesmo tempo, a um sindicato. Na Figura 6.16, uma empresa (o todo) tem qualquer nmero de funcionrios (as partes) associados a ela, da mesma forma que sindicatos (o outro todo). Alm disso, um funcionrio pode estar associado a nenhuma ou uma empresa ou a nenhum ou a um sindicato. O que o modelo especica ainda, por se tratar de composies, que, se um funcionrio est associado a uma empresa, no pode estar associado ao mesmo tempo a um sindicato1 , j que uma parte no pode pertencer a mais de um todo nas
1

Nesse exemplo, no estamos considerando a propriedade ou no da relao sindicato-funcionrio-

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 88 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Empresa

Sindicato

0..1

0..1

Funcionario

Figura 6.16: Composies denindo excludncia mtua de instncias de associao.

composies.

6.12 Classes de Associao

Considere a situao do diagrama da Figura 6.17, que especica que uma pessoa est ou no associada a uma empresa por meio de um emprego. Onde seriam armazenados, nesse caso, os atributos matrcula e salrio de um empregado de uma empresa? Na classe Pessoa? Na classe Empresa? Repare que no certo colocar esses atributos na classe Pessoa, porque h pessoas que nunca trabalharam e no trabalharo em nenhuma empresa e, portanto, no devem ter esses atributos. Tambm no certo colocar os atributos na classe Empresa porque, segundo o modelo, empresas podem no ter empregados. Na realidade, esses atributos passam a ser necessrios somente quando uma pessoa se associa a uma empresa como seu empregado; os atributos matricula e salario so, portanto, atributos das associaes entre pessoas e empresas.
empresa, pois sequer conhecemos qualquer Lei que obrigue ou impea o que representamos no modelo da Figura 6.16.

6.12. CLASSES DE ASSOCIAO

89

Empresa 0..1

+empregado *

Pessoa

Figura 6.17: Associao de emprego entre uma pessoa e uma empresa.

Empresa 0..1

+empregado *

Pessoa

Emprego matricula salario

Figura 6.18: Classe de associao contendo atributos e operaes relativas a uma associao.

Atributos e operaes relativos a uma associao devem estar reunidos em uma classe chamada classe de associao. Classes de associao so representadas conforme ilustra a Figura 6.18. No caso da Figura 6.18, demos classe o nome de Emprego, pois ela armazena atributos e operaes dos vnculos empregatcios entre pessoas e empresas. Devemos entender classes de associao da seguinte forma: para cada uma das associaes existentes entre empresas e empregados, ou seja, para uma associao de emprego (o Joo como empregado da ZYX, por exemplo), temos uma instncia da classe Emprego2 , com espao para armazenar o valor de uma matrcula e de um salrio.
Alguns CASEs rotulam automaticamente as associaes, dando a elas os nomes das respectivas classes de associao. Assim, no exemplo da Figura 6.18, teramos um rtulo Emprego dando nome
2

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 90 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Figura 6.19: Promoo da classe da associao C classe cheia.

Esse conceito bastante satisfatrio porque, anal, uma pessoa s tem emprego quando trabalha em uma empresa. Essa ideia ilustra esta importante caracterstica: classes de associao s podem ser instanciadas uma nica vez para uma dada instncia da associao (uma dada empresa associada a um determinado empregado). Costumo at sugerir que os alunos imaginem que existe uma multiplicidade 1 na ponta do segmento de reta tracejado, junto classe Emprego... mas que s imaginem, porque colocar a multiplicidade em uma classe de associao um erro! Como, para o exemplo da Figura 6.18, s podemos armazenar um nico conjunto de atributos do emprego, ou seja, um salrio, uma matrcula, isso signica que no podemos armazenar valores histricos de salrio, por exemplo. Com isso, se uma empresa decide aumentar o salrio de um empregado, esse novo valor sobrescreve o valor anterior do atributo. Se precisamos de histricos dos valores dos atributos, no podemos usar classes de associao; devemos promov-las a classes ditas cheias (classes comuns), o que usualmente feito conforme a tcnica ilustrada na Figura 6.19. Justicamos a tcnica de transformao ilustrada na Figura 6.19 da seguinte forma: cada instncia da classe A est associada a m instncias da classe B e, para cada
associao entre Pessoa e Empresa. No acho isso muito bom porque, alm de ser um rtulo que no precisa ser colocado (o nome da associao uma decorrncia bvia da existncia da classe de associao), ferimos aquele macete de nomear associaes com verbos na voz ativa. Se trocamos o nome da associao, esses CASEs automaticamente trocam o nome da classe, mas verbos na voz ativa no so bons nomes para classes. Dessa forma, nesses casos, eu opto que o CASE no exiba o nome das associaes.

6.12. CLASSES DE ASSOCIAO

91

Empresa 0..1

+empregado *

Pessoa

Emprego matricula

1..* Salario valor dataVigenciaInicio dataVigenciaFim

Figura 6.20: Alternativa para armazenar o histrico dos salrios mantendo o uso de classe de associao.

uma dessas associaes, temos uma instncia da classe de associao C. Raciocnio anlogo vale no sentido da leitura de B para A. Com isso, exibilizando as multiplicidades obrigatrias 1 resultantes da transformao, podemos especicar histricos convenientemente. Temos outras alternativas para os histricos dos salrios da Figura 6.18, caso houvesse essa necessidade. Podemos, por exemplo, denir salrio como um atributo multivalorado (salario [0..*]) ou podemos associar a classe Emprego a uma classe Salario, que poderia at armazenar um perodo de vigncia. Dessa forma, podemos trabalhar convenientemente com as multiplicidades nas pontas da associao. A Figura 6.20 ilustra esta ltima alternativa.

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 92 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

6.13 Operaes Abstratas, Interfaces e Dependncia

Quando tratamos de classes abstratas, no mencionamos que elas podem possuir operaes abstratas. Operaes abstratas no possuem implementao (o cdigo), apenas a declarao da operao e de seus atributos. Chamamos essa declarao de assinatura da operao. As operaes abstratas precisam ser implementadas para que possam ser invocadas. Isso feito nas classes concretas que especializam as abstratas que contm as tais operaes abstratas. As operaes abstratas nos conduzem a mais um conceito e a dois outros tipos de relacionamentos importantes contemplados na UML: o conceito de interfaces e os relacionamentos de dependncia e de realizao das interfaces. Para ilustrar o que acabamos de expor, imagine a seguinte situao. Suponha que precisamos desenvolver um editor grco para vrios ambientes (Windows/Intel, Sun(X), Mac etc.). Queremos isolar, ao mximo, os aspectos conceituais da aplicao dos aspectos de implementao (aspectos do hardware e do ambiente operacional) de cada ambiente, ou seja, a aplicao permitir a manipulao de textos, linhas, retngulos e crculos de acordo com determinadas regras e forma de interao com o usurio, independentemente do ambiente em que a aplicao estar operando. Suponha que meu editor grco precise utilizar as primitivas grcas d r awText (p : Pont o, t ext o : St r i ng ), d r awLi ne(p1, p2 : Pont o), d r awRec t (p1, p2 : Pont o) e d r awC i r cl e(c : Pont o, r : i nt eg er ) para manipulao das formas grcas na tela. Podemos modelar essa aplicao na forma da Figura 6.21. Na Figura 6.21, as classes que compem a aplicao (no nos interessa saber quais so para o efeito da ilustrao) esto dentro do pacote Editor Grfico (pacotes so contineres onde colocamos classes, atores, casos de uso, outros pacotes...; sero vistos em detalhes no Captulo 11). A classe JanelaGrafica foi marcada como interface, signicando que ela uma interface. As operaes dessa classe foram grafadas em itlico, signicando que so operaes abstratas e, como tais, no possuem implementao; apenas apresentam as assinaturas das operaes. Interfaces so necessariamente classes abstratas que s tm mtodos abstratos. O pacote Editor Grfico se associa interface por meio de uma seta tracejada com a ponta aberta, que signica dependncia. A dependncia indica que as classes do editor grco dependem, ou usam, a interface. A interface JanelaGrafica realizada, ou seja, tem suas operaes implementadas, pelas operaes com os mesmos nomes das classes JanelaWin, JanelaMac e JanelaX. A realizao representada por um relacionamento que se assemelha a uma generalizao-especializao, porm com linhas tracejadas.

6.14. A ESPECIFICAO DE RESTRIES NOS MODELOS

93

JanelaMac + + + + drawText(Ponto, String) : void drawLine(Ponto, Ponto) : void drawRect(Ponto, Ponto) : void drawCircle(Ponto, integer) : void

Editor Grfico + + + +

interface JanelaGrafica drawText(Ponto, String) : void drawLine (Ponto, Ponto) : void drawRect(Ponto, Ponto) : void drawCircle(Ponto, integer) : void + + + +

JanelaWin drawText(Ponto, String) : void drawLine(Ponto, Ponto) : void drawRect(Ponto, Ponto) : void drawCircle(Ponto, integer) : void

JanelaX + + + + drawText(Ponto, String) : void drawLine(Ponto, Ponto) : void drawRect(Ponto, Ponto) : void drawCircle(Ponto, integer) : void

Figura 6.21: Exemplo de interface e classes de realizao dessa interface.

O principal uso para classes de interface o isolamento entre partes conceitualmente distintas e coesas de um sistema (entre subsistemas, por exemplo), diminuindo o acoplamento entre elas.

6.14 A Especicao de Restries nos Modelos

Uma restrio uma sentena formulada com o propsito de declarar alguma semntica adicional de um elemento no modelo ([10]). Restries so regras a serem obedecidas durante a execuo do sistema, como por exemplo limites superiores e inferiores que devem ser obedecidos para determinadas variveis, expresses do tipo SE... ENTO... SENO que fazem parte de especicaes de regras de negcio, necessidade de pertinncia a um conjunto de valores possveis (por exemplo, o atributo sexo poder assumir somente os valores "M" ou "F"), expresses matemticas de clculo etc. As restries podem ser especicadas em linguagem natural, portugus estruturado ou usando uma linguagem legvel por mquina (linguagem de programao de computadores, por exemplo), no caso de necessitar ser mais formal

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 94 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES

Empresa {XOR} 0..1

Sindicato

0..1

Funcionario

Figura 6.22: excludentes.

Forma alternativa de especicao de associaes mutuamente

ou de se pretender que o modelo sirva como insumo para gerao automtica de cdigo. O OMG estabeleceu uma linguagem para especicao de restries chamada OCL (Object Constraint Language linguagem de restries de objetos), descrita em um volume parte da especicao da UML. Restries so necessariamente especicadas nos modelos com seus textos entre "" e "". Algumas restries, tais como {XOR} (ou exclusivo), {AND} e {ORDERED} (em que os elementos associados restrio so ordenados de alguma forma), so predenidas e muito usadas na UML. Citamos como exemplo a forma alternativa de especicar a mesma semntica das agregaes compostas, com a expresso que dene excluso mtua aplicada a associaes, como ilustra a Figura 6.22. A Figura 6.22 ilustra a especicao de uma restrio XOR aplicada s associaes Funcionrio-Empresa e Funcionrio-Sindicato. XOR o acrnimo para "exclusive OR" ("ou exclusivo"), que signica, no caso, que existe uma e apenas uma instncia de associao: entre um funcionrio e uma empresa ou entre um funcionrio e um sindicato.

6.15. RESUMO DO CAPTULO

95

As restries podem ser especicadas em qualquer diagrama da UML idealmente considerando seus tipos, ou seja, restries de cunho estrutural so preferencialmente colocadas nos modelos que contemplam a dimenso estrutural (diagramas de classes so espaos muito bons para isso); restries de cunho temporal so colocadas preferencialmente nos modelos em que a dimenso temporal contemplada etc.

6.15 Resumo do Captulo

As classes conceituais se associam entre si. Nas pontas das associaes colocamos as multiplicidades e, opcionalmente, os rtulos dos papis. As multiplicidades especicam o nmero mximo e mnimo de objetos com os quais um determinado objeto se relaciona. Um papel, como o nome diz, especica o papel que um objeto desempenha em sua associao com o outro. Associaes tambm podem possuir rtulos, que servem para ajudar a compreendermos o signicado da associao quando este no claro e no indicado pelos rtulos dos papis. Utilizando especializaes-generalizaes, os atributos, operaes e relacionamentos comuns so colocados na superclasse, enquanto as diferenas vo para as subclasses, que herdam da superclasse os atributos, as operaes e os relacionamentos comuns. Especializaes de uma classe podem ser agrupadas em conjuntos de generalizao e categorizadas segundo parties. Quando queremos representar conjuntos e os elementos que os formam, usamos os relacionamentos todo-parte: agregaes e composies. Agregaes so semanticamente equivalentes a associaes quando representamos as multiplicidades em suas pontas, mas composies acrescentam a restrio de que toda parte no pode pertencer a mais do que um todo. As classes de associao podem ser usadas quando as associaes entre classes possuem atributos e/ou operaes e suas aplicaes nos modelos se restringem a situaes em que no h mais do que uma instncia da classe de associao para a mesma instncia da associao. O emprego de classes de associao em um modelo sempre pode dar lugar ao emprego de classes normais. Usamos interfaces quando queremos diminuir o acoplamento entre partes conceitualmente distintas de um sistema, isolando, por exemplo, o que fazer do como fazer. As restries so limitaes a serem observadas durante o funcionamento de um sistema, impostas por regras de negcio visando manuteno de consistncias, dentre outras razes. Elas devem ser especicadas nos modelos por meio de expresses do tipo SE... ENTO... SENO, expresses matemticas de clculo, em

CAPTULO 6. DIAGRAMAS DE CLASSES: RELACIONAMENTOS ENTRE CLASSES, 96 CLASSES DE ASSOCIAO, INTERFACES E RESTRIES Tabela 6.1: Denindo os nomes de associaes entre classes.
Item
1 2 3 4 5 Pedido Produto ItemDePedido ClientePJ

Classes Associadas
PedidoDeReposicaoDeEstoque ItemDeReposicaoDeEstoque Cliente Fornecedor Produto Funcionario

Nome da Associao

linguagem natural, portugus estruturado ou usando uma linguagem legvel por mquina, como Java. A UML conta com uma linguagem prpria para especicao de restries: a OCL da OMG. Nos modelos, restries so necessariamente colocadas entre "" e "".

6.16 Exerccios Propostos

1. Complete a tabela 6.1 com nomes de associaes entre as classes da Figura 5.2. Ao lado do nome coloque o sentido de leitura (da esquerda para a direita ou da direita para a esquerda). A dica usar verbos em suas vozes ativas que exprimam bem o signicado da associao. 2. Escreva como se leem nos dois sentidos as multiplicidades das associaes entre as classes da Figura 5.2. 3. Elabore o modelo conceitual de classes referente ao texto do Exerccio 1 do Captulo 5 Ambiente Acadmico do Municpio de Sertozinho Alegre. 4. Desenvolva o modelo de classes conceituais com base no texto a seguir, indicando os relacionamentos de associao e de especializao-generalizao, as multiplicidades e os atributos das classes (fatore os atributos e associaes comuns usando especializaes-generalizaes). O sistema de controle de uma biblioteca deve possuir usurios que se classicam em usurios comuns e usurios funcionrios. Para todo e qualquer usurio necessrio que o seu nome esteja no cadastro. Usurios funcionrios possuem um nome de login e uma senha de acesso ao sistema. Usurios comuns tm nmero de registro e se subdividem em alunos e membros da comunidade.

6.16. EXERCCIOS PROPOSTOS

97

Para cada obra armazena-se o ISBN, os autores, o ttulo e os assuntos. Os exemplares possuem data de incluso no acervo e marcao de disponibilidade. A biblioteca s cadastra obras que constem do acervo. A biblioteca empresta livros aos alunos e aos membros da comunidade. Alunos podem retirar at dois ttulos concomitantemente; membros da comunidade podem retirar apenas um ttulo por vez. Usurios funcionrios no tomam livros emprestados. 5. Desenvolva o modelo de classes considerando o texto a seguir: Estamos desenvolvendo um editor grco para permitir o desenho de polgonos (especicados por conjuntos ordenados de trs ou mais pontos ligados por segmentos de retas) e crculos (especicados por seus centros e raios) na tela. As restries a seguir devem ser observadas durante a execuo do editor e, portanto, precisam ser especicadas no modelo: um polgono possui trs ou mais vrtices; um vrtice de um polgono no pode ser ao mesmo tempo vrtice de outro polgono nem centro de um crculo; o centro de um crculo no pode ser centro de outro crculo; ao comandarmos a remoo de um polgono, removemos tambm seus vrtices. Ao comandarmos a remoo de um crculo, removemos tambm seu centro. 6. Transforme a classe de associao da Figura 6.18 em classe cheia usando a tcnica ilustrada na Figura 6.19. 7. Suponha que queiramos isolar as classes do subsistema de controle de vendas da ZYX das do subsistema de cadastro de clientes. Como podemos representar, em alto nvel de abstrao, esse isolamento e, ao mesmo tempo, essa dependncia mtua, se entendermos que cada subsistema compe um pacote distinto? 8. Na soluo dada para o Exerccio 1 mencionamos que a soluo dada parcial. A razo disso que deixamos de apresentar uma restrio importante. Verique se as associaes entre as instncias da classe Exemplar e as das classes UsuarioComumAluno e UsuarioComumMembroComunidade podem ocorrer simultaneamente e, caso no possam, aplique a restrio que completa a soluo dada para aquele exerccio. As solues encontram-se a partir da Pgina 211.

CAPTULO
1

D IAGRAMAS DE M QUINA DE E STADOS

Anybody can make history. Only a great man can write it. Oscar Wilde

Por vezes, uma determinada classe possui instncias que atravessam um nmero signicativo de estados. Por exemplo, no contexto bancrio, uma determinada conta-corrente cinco estrelas, ou seja, uma determinada instncia da classe Conta-Corrente-Especial, pode passar do estado superavitria ao estado credora pela ocorrncia de um saque a descoberto. Ela tambm pode passar de credora ao estado bloqueada pelo atingimento do limite do cheque especial. Pode, tambm, passar de bloqueada ao estado superavitria vip platinum plus plus pela ocorrncia do depsito de um prmio de R$ 50.000.000 da mega-sena. Repare que nem todas as instncias da classe Conta-Corrente-Especial esto, passaram ou passaro pelos mesmos estados durante seus ciclos de vida1 . A passagem de um estado a outro, que chamamos de transio, o caminho entre dois estados a ser trilhado medida que acontecem eventos (no contexto bancrio, por exemplo, os cheques que so sacados, os prmios que so depositados etc.). Podemos tentar descrever os estados, as transies e os eventos usando textos
Ciclo de vida de um objeto o tempo decorrido entre a sua instanciao e a sua destruio.

99

100

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

em linguagem coloquial. Porm, nos casos em que o nmero de estados, eventos e transies grande e as condies para as transies so complexas, o texto possivelmente se tornaria bastante longo, confuso e pleno de ambiguidade. Imagine, por exemplo, uma classe cujas instncias podem passar por sessenta estados, transitando por 90 transies! Por essa razo, a UML trouxe do passado os diagramas de mquina de estados (DMEs). DMEs especicam no s os estados pelos quais os objetos podem passar e as possveis transies entre os estados, mas tambm as reaes dos objetos aos eventos que os atingem. Portanto, diagramas de mquina de estados representam as possveis biograas dos objetos da classe enfocada, cobrindo todos os possveis ciclos de vida desses objetos.

7.1 Conceitos Iniciais Importantes

Considere a entidade Pedido no contexto da nossa empresa ctcia ZYX, conforme o diagrama de classes da Figura 5.2. Queremos especicar as possveis situaes (estados) em que os pedidos (instncias da classe Pedido) podem estar. Como exemplo de algumas possibilidades que precisamos considerar: o pedido de nmero 346, que Joo fez, est na rua, para entrega; o pedido de nmero 349, da Maria, est aguardando a reposio de estoque de determinado produto, para que possa ser embalado e despachado; o pedido de nmero 330, que Pedro colocou, foi devolvido; o de nmero390481, que Bete acabou de colocar, est sendo vericado para determinar se todos os itens que o compem esto disponveis em estoque. Temos, com isso, mais um exemplo de que instncias diferentes de uma mesma classe podem possuir (ou estar em) estados diferentes. Com base nesses exemplos e nas demais informaes que os especialistas no negcio da ZYX deram, desenvolvemos o DME apresentado na Figura 7.1. No se preocupe em entender agora os elementos da notao grca usada. Ela ser explicada em detalhes ao longo do texto adiante.

7.1. CONCEITOS INICIAIS IMPORTANTES

101

Verificando Disponibilidade Estoque + do / organizarPedido

Sendo Embalado [todos os itens disponveis] + + + entry / abaterEstoque do / embalarProdutos exit / notificarTransportadora

Entregando

entrega [algum item no disponvel]

Entregue Aguardando Chegada de Produto

chegada de produto [todos os itens disponveis] entrega recusada

chegada de produto [algum item no disponvel]

devoluo aps (60 dias) /moverArquivoMorto

Dev olv ido + entry / adicionarEstoque

aps (60 dias) /moverArquivoMorto

Figura 7.1: Diagrama de mquina de estados para os objetos da classe Pedido.

Nem todos os pedidos seguem o mesmo caminho2 . Possivelmente h pedidos que, ao serem colocados, tiveram todos os seus itens em estoque, no tendo passado pelo estado Aguardando Chegada de Produto. Haver pedidos que no sero entregues por conta de recusa no recebimento, passando diretamente de Entregando a Devolvido. H pedidos que foram acolhidos na entrega, permanecendo, da entrega em diante, no estado Entregue. Pelo fato de um DME "contar as histrias" dos objetos de uma classe, costumo referir-me a eles como sendo as possveis biograas desses objetos. Sendo assim, desenvolvemos diagramas de mquina de estados para classes de objetos que possuem histrias que valem a pena ser contadas ou, em linguagem mais tcnica, possuem comportamento dinmico relevante, passando por vrios estados e respondendo a diversos eventos. Seria o equivalente a um bigrafo s investir seu tempo na biograa de algum que tem ou teve uma vida que despertar o interesse dos leitores e que, por isso, merece ser contada. Para isso, vericamos se cada classe do modelo de classes "merece" ter um DME desenvolvido para ela.

Os caminhos so indicados no diagrama pelas setas as transies.

102

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

Pessoa +esposa 0..1

+esposo 0..1 casa

Figura 7.2: A autoassociao do matrimnio.

Nas sees a seguir voc ver os conceitos relativos a cada um dos elementos da notao grca da UML para DMEs. Faremos isso com base no diagrama da Figura 7.1.

7.2 Estados
Cada estado em que um objeto se encontra reete a situao dos atributos e dos relacionamentos desse objeto. Veja dois exemplos para ilustrar essa armao. 1. Determinados valores de atributos de uma pessoa evidenciam que essa pessoa est (no estado) saudvel ou no. Os exames de sangue ajudam a conhecer os valores desses diversos atributos. 2. Se um objeto da classe Pessoa se encontra associado a outro objeto dessa mesma classe por meio de uma associao de casamento (como vimos no Captulo 5, essa associao chamada de autoassociao), ou seja, se h uma instncia da autoassociao ilustrada pela Figura 7.2, dizemos que o estado civil de cada uma das duas pessoas desse autorrelacionamento casado. Os estados so representados por "retngulos" com os vrtices arredondados, com um ou dois compartimentos. O nome do estado colocado centralizado no nico compartimento ou no primeiro, quando h dois compartimentos. A Figura 7.3 ilustra. O segundo compartimento opcional e destinado a relacionar, quando for necessrio, as atividades a serem executadas assim que o objeto entra no estado, imediatamente antes de sair do estado e enquanto permanece no estado, dependendo do rtulo. Para isso, a notao usada no segundo compartimento r t ul o + "/" + at i vi d ad e

7.2. ESTADOS

103

Figura 7.3: Duas formas de apresentao da caixa de estado em DMEs da UML.

Verificando Disponibilidade Estoque + do / organizarPedido

Sendo Embalado [todos os itens disponveis] + + + entry / abaterEstoque do / embalarProdutos exit / notificarTransportadora

Entregando

entrega [algum item no disponvel]

Figura 7.4: Rtulos indicando atividades nos estados (um detalhe da Figura 7.1).
Entregue

Aguardando Chegada de Produto O

produto no

rtulo indica quando a atividade ser executada: se imediatamente aps a chegada de produto [todos os itens disponveis] entrada (rtulo = "entry" entrada, em ingls), se durante a permanncia do objeto entrega no estado (rtulo = "do" fazer, em ingls) ou se imediatamente antes da sada (rtulo recusada devoluo = "exit" sada, em ingls). A "/" serve para separar rtulo e atividade.
/moverArquivoMorto Sendo assim, a Figura 7.4 ilustra a situao de um pedido que, ao entrar no estado Dev olv ido Sendo Embalado, executa a atividade abaterEstoque. Durante a permanncia do + entry / adicionarEstoque pedido nesse estado, a atividade embalarProdutos executada. Imediatamente antes de o pedido sair desse estado, a atividade notificarTransportadora executada. aps (60 dias)

Qualquer estado necessariamente de um dos tipos descritos a seguir:

aps (60 dias) /moverArquivoMorto

estado de atividade (por exemplo, Verificando Disponibilidade Estoque, Sendo Embalado e Entregando); estado de espera (ex.: Aguardando Chegada de Produto); estados que reetem que o objeto atingiu determinada condio (por exemplo, Entregue e Devolvido).

104

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

Ser um estado de atividade signica que o objeto executa alguma tarefa enquanto permanece no estado. Estados de atividade devem, portanto, possuir, no segundo compartimento, um rtulo "do" indicando a atividade a ser executada enquanto o objeto permanece no estado. Essas atividades duram indenidamente ou terminam em algum momento. Neste caso, quando as atividades terminam (quando se trata de um clculo, por exemplo), o objeto vai transitar para outro estado pela ocorrncia do evento de nal da atividade sendo executada (trataremos de eventos mais detalhadamente adiante, neste captulo). Ter rtulo(s) "entry" e/ou "exit" no caracteriza que um estado de atividade. Um estado de atividade deve sugerir que algo feito enquanto o objeto se encontra naquele estado. Os nomes de estados de atividade devem ser, portanto, verbos no gerndio (por exemplo, Calculando Tal Coisa, Gerando Tal Coisa, Pesquisando Tal Coisa...). Estados que reetem uma situao do objeto devem ter os nomes com verbos no particpio (por exemplo, Tal Coisa Calculada, Tal Coisa Gerada, Tal coisa Pesquisada...). Os estados de espera devem ter nomes como Aguardando Tal Coisa ou Esperando Tal Coisa (por exemplo, o estado Aguardando Chegada de Produto, da Figura 7.1). Os nomes das atividades executadas seja na entrada, durante a permanncia no estado ou na sada dele devem ter preferencialmente verbos no innitivo (por exemplo, calcular tal coisa, gerar tal coisa, pesquisar tal coisa...). Quem estiver elaborando o modelo deve ter a preocupao de dar "bons nomes" aos estados. Os nomes devem ser de fcil entendimento por parte dos especialistas do negcio e usurios (a dica, mais uma vez, usar o jargo do negcio), alm de reetirem o tipo do estado.

7.3 Pseudoestados Iniciais

Um pseudoestado inicial no exatamente um estado (da o porqu do "pseudo" no nome), mas aponta para o estado em que o objeto se encontrar quando for criado (estado inicial) ou quando entrar em uma regio que contm outros estados (subestados dessa regio, portanto). S poder haver um nico pseudoestado inicial por regio. A notao grca do pseudoestado inicial ilustrada na Figura 7.5, empregada na Figura 7.1 para indicar que o estado Verificando Disponibilidade Estoque o

7.4. ESTADOS FINAIS

105

Figura 7.5: Crculo pequeno preenchido: smbolo grco de estado inicial na UML (um detalhe da Figura 7.1).

Figura 7.6: "Olho de boi": smbolo grco de estado nal na UML (um detalhe da Figura 7.1).

estado que um objeto da classe Pedido assume quando criado.

7.4 Estados Finais

H estados que os objetos atingem dos quais no h sada, ou seja, dos quais no h transies de sada para outros estados. Atingidos esses estados, os objetos permanecero neles para sempre. Esses estados so chamados de estados nais. Imaginemos, para ilustrar, a situao de um equipamento que se danica e para o qual no h reparo e no h a possibilidade de destruio ou venda: ele permanecer para sempre como "Danicado" no inventrio. Uma forma de representarmos um estado nal em um diagrama simplesmente usarmos a notao para estados explicada na Seo 7.2, contanto que dele no haja qualquer transio de sada. H um outro tipo de notao para estados nais: o smbolo do tipo "olho de boi", ilustrado na Figura 7.6 e empregado nas sadas dos estados Devolvido e Entregue da Figura 7.1. H alguma controvrsia quanto ao emprego da notao da Figura 7.6. Por essa razo fazemos referncia UML ([11]), que dene que o estado olho de boi "signica que a mquina de estados correspondente regio3 que o contm terminou".
Uma regio pode ser um superestado (um estado que contm outros j mencionamos isso na Seo sec:PseudoEstadosIniciais), parte de um estado concorrente (de que trataremos no nal deste captulo) ou um diagrama como o da Figura 7.1 (o caso em que no h nenhuma dessas regies caracterizadas).
3

106

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

Os empregos do "olho de boi" em superestados e em estados concorrentes sero vistos mais adiante. Se estamos falando do emprego do "olho de boi" em um diagrama como o da Figura 7.1 (com uma nica regio), devemos entender que ele um estado nal, como seria qualquer outro do diagrama do qual no houvesse qualquer transio de sada. Nesse caso, estaramos usando uma notao diferente, apenas. O que dissemos no pargrafo anterior pode ser dito de outra forma: um estado nal um estado que, se atingido, o objeto no sai dele. O "olho de boi" em um diagrama, ou um estado nal (quando o diagrama tem uma nica regio), ou indica o nal da mquina de estados da regio (quando o diagrama possui mais de uma regio o que veremos mais adiante neste texto). Dois equvocos bem comuns cometidos pelo pessoal de modelagem quando usa essa notao: 1. No incomum que alguns modeladores considerem que o smbolo de "olho de boi" no corresponde ao estado nal, mas apenas indica o estado nal do objeto. 2. O estado "olho de boi" tambm associado por muitos outros modeladores destruio do objeto, o que no est incorreto, porque a destruio um dos possveis estados nais de um objeto, mas no a nica situao nal possvel para um objeto. Um objeto em estado nal pode ter atributos, o que signica que ele no foi necessariamente destrudo ao atingi-lo. Fao a seguir duas recomendaes relacionadas representao de estados nais em diagramas de mquina de estados: 1. evite usar "olhos de boi" em diagramas que no representem trminos de regies em estados compostos. Reserve essa notao para as situaes de m da mquina de estados, em diagramas com estados compostos e para a remoo de objetos nos demais diagramas; 2. se um objeto permanece "para sempre" em um estado importante para o negcio, ou seja, se no h transio de sada desse estado, modele esse estado como um estado normal (caixa retangular com as bordas arredondadas), e no como um "olho de boi". O fato de no haver transio de sada signica, inequivocamente, que aquele um estado nal.

7.5 Eventos, Condies e Aes em Transies

Um objeto, estando num determinado estado, pode passar para outro estado quando certas "coisas" acontecem. Transies denem os possveis caminhos de passagem de

7.5. EVENTOS, CONDIES E AES EM TRANSIES

107

telefone colocado no gancho /desconectar

Desligado

Ligado

telefone retirado do gancho /solicitar tom de discagem

Figura 7.7: Transies mtuas entre dois estados.

um estado a outro, que se do pela ocorrncia de eventos (acontecimentos... as tais "coisas" que mencionamos), atendidas determinadas condies. As transies so representadas na UML por setas poligonais ou curvilneas com as pontas abertas. As setas so obrigatoriamente unidirecionais. Sendo assim, se desejamos representar caminhos de ida e de volta entre dois estados, precisamos represent-los como duas transies; uma de ida e outra (distinta) de volta. A Figura 7.7 ilustra as transies mtuas entre dois estados usando situao aparentemente trivial do DME para objetos da classe Telefone. Note que no representamos o pseudoestado inicial na Figura 7.7 porque julgamos no ser relevante, no caso, saber em qual estado um telefone se encontra quando instanciado (a instanciao de um objeto telefone pode ser associada, por exemplo, ao registro do mesmo no sistema da operadora de telefonia). Caso isso seja necessrio, podemos representar um pseudoestado inicial apontando para o estado Desligado ou para o estado Ligado, conforme queiramos. Transies podem partir de um estado e chegar nele prprio. Transies desse tipo tm o nome especial de autotransies. A Figura 7.8 ilustra o trecho da Figura 7.1 que apresenta uma autotransio. Como dissemos, transies so trilhadas obrigatoriamente pela ocorrncia de eventos. Se no ocorrem eventos, os objetos permanecem nos estados em que se encontravam.

Verificando Disponibilidade Estoque + do / organizarPedido

Sendo Embalado [todos os itens disponveis] + + +

entry / abaterEstoque do / embalarProdutos exit / notificarTransportadora

108

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

[algum item no disponvel]

Aguardando Chegada de Produto

chegada de produto [todos os itens disponveis]

chegada de produto [algum item no disponvel]

aps (60 dia /moverArqui

Figura 7.8: Autotransio em DMEs da UML (um detalhe da Figura 7.1).

Os eventos podem ser externos ou temporais. Eventos externos acontecem no ambiente exterior ao que estudamos e, sendo relevantes para o sistemas, demandam que algum processo do sistema seja executado em resposta ao acontecimento. So exemplos de eventos externos a colocao de um pedido e a chegada de uma fatura em um sistema de controle de estoque. Eventos temporais se do de trs formas: 1. pela chegada de determinada data/hora. Esses eventos so chamados de eventos temporais xos e so normalmente especicados como hora de; 2. pela passagem de uma quantidade de tempo relativa entrada em um estado. Eventos desse tipo so chamados de eventos temporais relativos. Eles so usualmente especicados como aps tanto tempo; 3. trminos de atividades que estavam sendo executadas por um objeto quando em um estado como, por exemplo, o clculo que estava sendo realizado enquanto o objeto estava no estado Calculando Tal Coisa. Pela ocorrncia de um evento, um objeto pode transitar do estado em que se encontra para outro. Em alguns casos, precisa ser atendida alguma condio adicional para que, dada a ocorrncia do evento, o objeto de fato mude de estado. Pode ser necessrio que, adicionalmente, um objeto execute alguma ao durante a transio. Pelo fato de precisarmos especicar o evento, a condio e a ao, as transies so rotuladas com o nome do evento com a condio que precisa ser avaliada para se saber se o objeto transita ou no e com a ao a ser executada durante a transio. Essas trs informaes formam, na ordem, os chamados "rtulos ECA" (Evento, Condio e Ao) das transies. Segundo a UML, a sintaxe dos rtulos das transies event o[cond i o]/ao

7.5. EVENTOS, CONDIES E AES EM TRANSIES

109

Um exemplo de um rtulo completo para uma transio entre os estados, suponhamos, Encaminhado e Entregue de um pedido : ent r eg a[pr azosuper ou24hor as]/apl i car mul t apor at r aso Eventos, sendo acontecimentos, devem ter nomes condizentes: entrega, para signicar que a entrega ocorreu, alocao do tcnico, para indicar que um tcnico foi alocado ordem de servio. Outros exemplos de bons nomes para eventos so entrega recusada, para signicar que ocorreu a recusa do recebimento pelo cliente e pedido devolvido, para signicar que o pedido foi devolvido pelo cliente. Os colchetes devem conter a expresso a ser avaliada (a condio para que, na ocorrncia do evento, a transio seja trilhada). Por exemplo: [prazo superou 24 horas]. As aes, sendo processos executados pelo sistema, devem ser especicadas com verbos no innitivo. Exemplo: /aplicar multa por atraso. A barra ("/") precede necessariamente a ao. Assim, no exemplo completo para um rtulo de evento acima, na ocorrncia da entrega, se o prazo superou 24 horas, o objeto passar de um estado a outro (de Encaminhado para Entregue) executando a ao aplicar multa por atraso. Se o prazo no superou 24 horas, o objeto no transitar de um estado a outro, mesmo que a entrega ocorra (nesse caso, provavelmente outra transio a ser especicada no modelo ser trilhada). Eventos, condies e aes podem ser omitidos dos rtulos das transies, conforme voc pode ver a seguir. Se o evento omitido, signica que o evento4 corresponde ao nal da atividade executada no estado do qual o objeto est saindo. Eventos s podem ser omitidos, portanto, quando o estado do qual o objeto est saindo um estado de atividade e queremos especicar que o evento o m da atividade. Na Figura 7.9, quando termina a vericao da disponibilidade em estoque dos itens do pedido (termina a atividade organizarPedido), o pedido vai transitar para o estado Aguardando Chegada de Produto ou Sendo Embalado, dependendo se h ou no algum item do pedido faltante no estoque. Se a condio omitida (nesse caso, os colchetes tambm devem ser omitidos), a transio ser trilhada incondicionalmente. No caso ilustrado pela Figura 7.10, a entrega ocorre incondicionalmente. Se a ao omitida, a transio ocorrer sem que uma ao seja executada. Ainda no caso ilustrado pela Figura 7.10, a entrega trilhada sem que nenhuma ao do sistema seja executada.
4

Lembre-se de que obrigatrio que um evento ocorra para que a transio possa ser trilhada.

110

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

Verificando Disponibilidade Estoque + do / organizarPedido

Sendo Embalado [todos os itens disponveis] + + + entry / abaterEstoque do / embalarProdutos exit / notificarTransportadora

Entregando

entrega [algum item no disponvel]

Entregue Aguardando Chegada de Produto

chegada de produto [todos os itens disponveis]

entrega recusa chegada de produto [algum item no disponvel] devoluo

Dev olv ido + entry / adicionarEstoque

Figura 7.9: Nome do evento omitido, signicando o m da atividade do estado de origem (um detalhe da Figura 7.1). aps (60 dias)
aps (60 dias) /moverArquivoMorto /moverArquivoMorto

Sendo Embalado + + + entry / abaterEstoque do / embalarProdutos exit / notificarTransportadora

Entregando

entrega

Entregue

s os itens disponveis] entrega recusada

Figura 7.10: Condio omitida, signicando incondicionalmente (um detalhe da Figura 7.1).
Dev olv ido + entry / adicionarEstoque

devoluo

que

transio

ocorre

aps (60 dias) /moverArquivoMorto

aps (60 dias) /moverArquivoMorto

7.6. ESTADOS COMPOSTOS

111

Caso haja mais de uma transio de sada de um estado, no pode haver dvida a respeito de qual transio ser trilhada; ou os eventos so diferentes ou, sendo o mesmo evento, as condies so diferentes. Isso caracteriza o que se chama de excluso mtua; mltiplas transies de sada de um estado so mutuamente excludentes, o que nos leva a concluir que um objeto s pode estar em um s estado em determinado instante. No caso das duas transies de sada do estado Verificando Disponibilidade Estoque, ilustrado na Figura 7.9, ambas ocorrem pelo evento de m da atividade organizarPedido porque, como vimos, no h rotulo de evento. No entanto, apenas uma transio ser trilhada, porque as condies [todos os itens disponveis] e [algum item no disponvel] nunca sero avaliadas como verdadeiras ao mesmo tempo.

7.6 Estados Compostos

Um estado pode conter outros estados, concorrentes ou independentes. Esses estados so chamados estados compostos. Quando vericamos que um estado pode ser subdividido em outros (sub) estados, precisamos desenvolver um diagrama para mostrar seus detalhes. No exemplo da Figura 7.7, o estado Desligado trivial pois, enquanto est desligado, um telefone permanece aguardando uma ligao ou a retirada do gancho. No entanto, enquanto estiver no estado Ligado, um telefone pode estar pronto para fazer uma ligao, emitindo o sinal de discagem; pode estar emitindo o sinal de ocupado; pode estar no meio da entrada do nmero a ser chamado; pode estar falando; pode estar tentando estabelecer a ligao etc. Sendo assim, dizemos que o estado Ligado um superestado e os estados Pronto, Discando, Nmero Invlido, Conectando etc. so subestados daquele estado. A Figura 7.11 ilustra esse conceito, mostrando os subestados representados dentro do superestado Ligado. O diagrama da Figura 7.11 , portanto, um detalhamento do diagrama da Figura 7.7, que era aparentemente trivial; talvez voc at tenha se perguntado por que eu o desenvolvi, j que ele era trivial. Note na Figura 7.11 trs aspectos que merecem destaque: 1. o pseudoestado inicial apontando para o subestado Pronto indica que este estado o subestado em que o objeto se encontrar assim que entrar no (super)estado Ligado; 2. o objeto telefone pode passar imediatamente de qualquer subestado do estado Ligado para o estado Desligado pela simples colocao do telefone no gancho, ou seja, a sada do estado Ligado pela ocorrncia do desligamento provoca a sada do subestado onde o telefone se encontra;

112

Ligado Nmero Inv lido + do / mensagem de erro

digito pressionado [nmero incompleto]

digito pressionado [nmero invlido] Pronto digito pressionado + aps (15s) aps(20s) do / tom de discar digito pressionado [nmero vlido] Discando

Desligado Timeout telefone desligado /desconectar aps(20s) + do / tom de ocupado

telefone retirado do gancho /solicitar tom de discagem

Conectando

conexo estabelecida ocupao detectada

Falando + destinatrio atendeu

Chamando do / sinal de chamada +

Ocupado do / tom de ocupado

Figura 7.11: Estados e seus subestados: um detalhamento da Figura 7.7.

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

7.6. ESTADOS COMPOSTOS

113

3. a situao que acontece quando tiramos o telefone do gancho e nada fazemos por quinze segundos ilustrada na gura pela passagem do estado Pronto ou do estado Discando para o estado Timeout (tempo esgotado): o sinal de ocupado iniciado, sinalizando que o telefone "cansou de esperar" uma ao do operador. O evento de tempo esgotado a passagem de quinze segundos sem que nenhum dgito tenha sido teclado, representado por aps (15s). Caso seja relevante especicar em qual estado um telefone se encontra quando instanciado, devemos representar no diagrama da Figura 7.11 um pseudoestado inicial apontando para o estado Desligado ou para o estado Ligado. Com isso, teremos dois pseudoestados iniciais no mesmo diagrama. Essa situao um exemplo de contextos distintos a que nos referimos anteriormente: o primeiro deles no nvel dos estados Ligado-Desligado e o outro no nvel dos subestados do estado Ligado. De volta nossa empresa ZYX: alm dos estados relacionados ao processo de entrega de um pedido, esperado que os estados relacionados ao processo de pagamento pelo pedido sejam tambm relevantes; usualmente, um pedido s expedido se o pagamento por ele for feito ou, pelo menos, agendado. Atributos relacionados ao pagamento (data de pagamento, valor, descontos, impostos etc.) e atributos relacionados composio e entrega do pedido (o conjunto de itens, as datas de expedio e entrega, o local de entrega etc.) formam subconjuntos distintos e independentes do conjunto de atributos de um pedido, dando origem a dois estados ditos concorrentes. Estados concorrentes so estados independentes entre si, relativos a aspectos distintos, mas que acontecem ao mesmo tempo. importante ressaltar que no estamos contradizendo o que escrevemos antes (que um objeto s pode estar em um nico estado em um dado instante), e sim acrescentando um conceito novo: o de estados concorrentes. A Figura 7.12 apresenta outros aspectos alm dos da Figura 7.1; tambm so considerados os estados relacionados ao pagamento pelo pedido. Com isso, um pedido estar, ao mesmo tempo, em um estado da parte superior e em outro da parte inferior do estado concorrente Preparando Pedido: ele poder estar sendo organizado e com o pagamento autorizado, sendo embalado e com o pagamento sendo efetuado etc. Cada uma das partes separadas pelo segmento de reta tracejado corresponde a uma regio (ver Seo 7.4). Destacamos alguns aspectos importantes da Figura 7.12: a separao das regies feita por meio de segmento de reta tracejado; o emprego do pseudoestado inicial em cada regio, signicando o ponto de partida em cada uma delas;

114

Preparando Pedido

[Entrega] Organizando Pedido [todos os itens disponveis] + do / organizarPedido + + + entry / abaterEstoque do / embalarProdutos exit / notificarTransportadora Embalando Pedido

Aguardando Reposio de Produto No Estoque [algum item no disponvel] chegada de produto [algum item no disponvel] chegada de produto [todos os itens disponveis] Entregando entrega recusada

[Pagamento] solicitao respondida [crdito acolhido] fundos transferidos Solicitando Pagamento do / notificarCliente + do / solicitarCreditoInstituicaoCredito + exit / transferirFundos Entregue Efetuando Pagamento Pagamento Autorizado entrega

aps (60 dias) /moverArquivoMorto devoluo

Pagamento Recusado solicitao respondida [crdito recusado] aps (60 dias) /moverArquivoMorto + aps (60 dias) /moverArquivoMorto

Dev olv ido entry / adicionarEstoque

Figura 7.12: Estados concorrentes dos objetos da classe Pedido da ZYX.

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

7.7. ATIVIDADES E AES EM DMES Tabela 7.1: Atividades e aes em DMEs da UML. Podem durar "para sempre"? Sim No Contexto de execuo Dentro dos estados Durante as transies Pode ser interrompida? Sim No

115

Longa ou curta durao? Longa Curta

Atividade Ao

o emprego do "olho de boi" em cada regio, especicando que a mquina de estados da regio se encerra. S quando ambas as mquinas de estado se encerram o objeto transita do estado concorrente Preparando Pedido para o estado Entregando. Este aspecto, por sinal, ilustra bem nossas explicaes sobre o uso da notao de "olho de boi" (ver Seo 7.4); a sada do estado Preparando Pedido para o estado Pagamento Recusado, por conta da recusa do pedido de crdito.

7.7 Atividades e aes em DMEs

Vimos que um estado de atividade um estado em que um objeto se encontra executando uma atividade que termina em algum momento ou permanece executando para sempre. Vimos tambm que objetos podem executar aes enquanto transitam de estado para estado. Atividades e aes em DMEs so, por denio, coisas que o objeto executa em contextos diferentes; enquanto est em um estado e enquanto transita entre estados, respectivamente. Atividades podem ser interrompidas pela ocorrncia de eventos, enquanto aes no podem ser interrompidas, ou seja, quando um objeto inicia uma transio, esta no pode ser interrompida, nem a ao associada a ela. Atividades so, usualmente, de mais longa durao que as aes. Esses dois conceitos so bastante prximos, e suas diferenas so subjetivas. Resumimos na Tabela 7.1 os conceitos relativos a atividades e aes. As atividades e as aes especicadas nos estados e nas transies dos DMEs so operaes que os objetos enfocados realizam. DMEs, portanto, ajudam a compor o compartimento das operaes dos diagramas de classes.

7.8 DMEs e Diagramas de Casos de Uso

Diagramas de mquina de estado nos ajudam a descobrir casos de uso. Isso ocorre porque as mudanas de estado dos objetos em um sistema esto, em boa parte das

116

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

vezes, associadas a execues de casos de uso. Por exemplo, no detalhe ilustrado na Figura 7.10 o evento de entrega gerado com o registro da entrega no sistema, ou seja, em alguma parte de um caso de uso que especicaremos para registro das entregas no sistema. Analogamente, a transio para o estado Devolvido estar associada execuo de uma alguma funcionalidade (um caso de uso) para registro das devolues de pedidos feitas ZYX. Portanto, uma boa dica para um rpido exame da completude do diagrama de casos de uso vericar os eventos que provocam as transies entre estados nos DMEs. Essa tcnica, embora ajude a elucidar casos de uso esquecidos, no garante que todos os casos de uso foram relacionados, inclusive porque no desenvolvemos DMEs para todas as classes do conceito. Como ilustrao do que acabei de expor, com base em uma experincia que vivi no passado, no incio da fase de anlise de um sistema, da qual participei como arquiteto, um colega de equipe me apresentou um esboo do diagrama de casos de uso que continha cerca de trinta casos de uso. Um pouco mais adiante, tive acesso a um complexo diagrama de mquina de estados de uma entidade do domnio que outro colega havia desenvolvido. Segundo esse diagrama, a entidade modelada possua cerca de vinte estados, havendo cerca de trinta transies entre eles. Achei estranho haver tantas transies (isso em um s DME) e to poucos casos de uso. Em um rpido exame das transies, descobrimos mais cerca de vinte casos de uso que no haviam sido identicados no diagrama de casos de uso. Voc pode imaginar o impacto que isso causou na expectativa do cliente com relao ao custo do projeto. Diagramas de mquina de estados so, portanto, grandes aliados na compreenso e especicao corretas do negcio e do sistema que iremos desenvolver. Muitos analistas de sistemas acham, no entanto, que esses diagramas so para serem desenvolvidos na fase de projeto so sistema, somente.

7.9 Resumo do Captulo

Por vezes, uma determinada classe possui instncias que atravessam um nmero signicativo de estados. Podemos tentar descrever os estados e as transies usando textos em linguagem coloquial; mas, conforme o nmero de estados, eventos e transies aumenta e as condies para as transies se tornam mais complexas, o texto possivelmente se tornaria bastante longo, confuso e pleno de ambiguidades. Por isso desenvolvemos DMEs da UML. DMEs especicam no s os estados pelos quais os objetos podem passar e as possveis transies entre os estados como tambm as reaes dos objetos aos eventos que os atingem. Diagramas de mquina de estados so desenvolvidos somente para classes

7.10. EXERCCIOS PROPOSTOS

117

de objetos que possuem comportamento dinmico relevante, passando por vrios estados e respondendo a diversos eventos. Cada estado em que um objeto se encontra reete a situao dos atributos e dos relacionamentos desse objeto. Qualquer estado um estado de espera ou de atingimento de uma situao ou de atividade. Um objeto em um estado pode executar uma atividade assim que entra no estado, imediatamente antes de sair ou enquanto permanece no estado. Transies (passagem de um estado a outro) se do exclusivamente a partir de eventos e dentro de determinadas condies. Eventualmente objetos executam aes enquanto transitam. O trio evento, condio e ao (ECA) rotula as transies. Estados podem conter outros estados (os subestados), concorrentes ou independentes. Objetos no podem estar em mais de um estado ao mesmo tempo, a menos que sejam estados concorrentes. Um diagrama pode conter mais de um pseudoestado inicial, desde que os pseudoestados estejam em contextos diferentes. Como no deve haver confuso por qual estado uma mquina de estados ir comear, o uso de mltiplos pseudoestados iniciais em um mesmo diagrama deve ser feito com ateno. Estados nais so estados dos quais os objetos no podem sair. "Olhos de boi" tambm representam estados nais, mas devem ser usados com ateno nesse caso, pois representam tambm encerramentos de regies em estados compostos. Atividades e aes tm pequenas diferenas conceituais, muito subjetivas: atividades so executadas nos estados, so normalmente de longa durao e podem ser interrompidas; aes so executadas durante as transies, so normalmente de curta durao e no podem ser interrompidas. Atividades e aes especicadas nos estados e nas transies so operaes que os objetos enfocados realizam e, portanto, devem compor o rol de operaes que eles executam.

7.10 Exerccios Propostos

1. Se, porventura, voc tivesse as classes Interruptor e Ar Condicionado em um modelo, para qual ou quais delas voc investiria seu tempo desenvolvendo um diagrama de mquina de estados? Justique sua resposta. Use sua experincia sobre os estados em que os objetos de cada uma dessas classes podem estar. 2. No contexto de um pequeno hotel, h conceitos como apartamento, reserva, cliente, ocupao e despesa. O diagrama de classes da Figura 7.13 ilustra como esses conceitos se relacionam.

118

CAPTULO 7. DIAGRAMAS DE MQUINA DE ESTADOS

Reserv a * dataChegada dataSaida

1 Cliente * *

1 Apartamento

Ocupacao dataEntrada dataSaida 1

* ItemDespesa

Figura 7.13: Diagrama de classes de conceito do Hotel Cincoestrelas.

Desenvolva o diagrama de mquina de estados para os objetos da classe Apartamento, considerando, em um primeiro momento, que um apartamento pode estar reservado, ocupado ou livre. A gerncia do hotel entende que um apartamento reservado aquele que no est ocupado, mas que no est livre, ou seja, est bloqueado no dia, aguardando a chegada do cliente. importante no confundir com um apartamento que possua reservas para outros dias. Adicione, no local mais apropriado, a ao de impresso da fatura com as despesas do cliente quando ele deixa um apartamento. Use sua experincia pessoal, seu bom senso e o jargo da rea hoteleira. 3. Com base no que foi descrito no Exerccio 2, considere agora que um apartamento tambm pode estar interditado para obras, estado para o qual um apartamento pode passar a qualquer momento pela ocorrncia de um problema

7.10. EXERCCIOS PROPOSTOS

119

srio e duradouro nas instalaes, por exemplo. Sendo assim, a interdio para obras corresponde a uma situao distinta das demais, no se tratando de (pequeno) reparo que pode ser feito rapidamente, durante as ausncias dos clientes dos apartamentos. Verique a convenincia da adoo de superestados e/ou estados concorrentes na sua soluo. Refaa o diagrama sa soluo do Exerccio 2 para reetir essas consideraes. As solues encontram-se a partir da Pgina 216.

CAPTULO
121

D IAGRAMAS DE ATIVIDADE
Great things are done by a series of small things brought together. Vincent van Gogh

Quando estudamos descries de casos de uso, vimos que a especicao da interao entre usurios e sistema segue uma sequncia de passos correspondendo a aes dos usurios preenchendo campos de dados, fazendo opes, pressionando botes etc. e a respostas (aes) do sistema. Vimos que a elaborao de especicaes ecazes no uma atividade trivial porque muitas vezes temos que lidar com situaes complexas (muitas aes e opes oferecidas aos usurios, por exemplo), porm tendo que manter a conciso e garantindo a completude da especicao. Quando estudamos diagramas de mquina de estados, vimos que h estados em que os objetos executam atividades, como, por exemplo, organizarPedido, realizada enquanto um pedido se encontra no estado Verificando Disponibilidade Estoque (ver Figura 5.2). Aproveitando o exemplo, se pensar um pouquinho sobre quais so os passos que compem a atividade organizarPedido, possivelmente voc vai se surpreender com a quantidade deles e a complexidade como eles se estruturam na atividade. Imagine, agora, a quantidade e a complexidade com que se estruturam as aes necessrias para a construo de um avio ou um navio transatlntico... Diagramas de atividade (DAs) enfocam o uxo de controle entre aes que

122

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

compem um processo qualquer. Esses diagramas especicam a ordem (no tempo) de execuo das aes, cobrindo, portanto, parte da dimenso temporal do modelo de um sistema; DMEs e diagramas de interao so os outros diagramas da UML que complementam os DAs na cobertura dessa dimenso. Com os elementos de notao grca que incorporaram nos ltimos anos para tratamento de paralelismo, parties hierarquizadas e em duas dimenses, pinos etc., os diagramas de atividade da UML vm sendo usados em inmeras outras aplicaes, alm das tradicionais especicaes de algoritmos complexos. Da sua grande relevncia em modelagem de sistemas. DAs tambm so muito teis para a descrio de processos compostos por aes executadas em paralelo, como tipicamente ocorre em processos de engenharia e de negcios, os chamados uxos de trabalho workows, em ingls. Nas verses da UML anteriores 2.0, DAs eram associados aos DMEs como variantes destes; DAs poderiam ser entendidos com DMEs onde todos os estados eram estados de atividade. Isso permitia um entendimento rpido dos conceitos e da notao envolvidos em DAs a partir dos conceitos envolvidos em DMEs. Essa pequena variao de um diagrama para outro, no entanto, j era suciente para acarretar grande variao no emprego dos dois diagramas. Na verso 2.0 da UML, DAs sofreram inmeros acrscimos e modicaes na notao usada, estendendo signicativamente suas expressividades. Nessa verso, mesmo no mais mencionando a associao entre DAs e DMEs, a UML adotou a mesma notao grca bsica dos DMEs nos DAs. O fato que o entendimento anterior UML 2.0 continua sendo possvel na maioria dos casos. Nas sees a seguir mostraremos os elementos grcos dos diagramas de atividade que so mais usados em modelagem de sistemas em nvel conceitual. Faremos uma abordagem sob a tica da associao com os DMEs, aproveitando, portanto, boa parte dos conceitos tratados no Captulo 7. Para ilustrar de forma completa a apresentao dos conceitos e da notao, daremos alguns exemplos no contexto de negcios e, no nal do captulo, empregaremos DAs na especicao grca de casos de uso.

8.1 Atividades e Aes em DAs

Segundo a especicao da superestrutura da UML ([11]), "ao a unidade fundamental para a especicao de um comportamento". Entendemos, da, que comportamento um conjunto de aes. Uma ao recebe um conjunto de entradas e as converte em um conjunto de sadas, embora ambos os conjuntos possam ser vazios. O conjunto de entradas para uma ao pode ser resultado das sadas de uma ou mais

8.2. NS DE DECISO (DESVIOS) E QUALIFICAO DE FLUXOS

123

aes executadas anteriormente. Algumas dessas aes alteram o estado do ambiente no qual a ao executada, alterando valores de atributos de objetos desse ambiente. Aes so contidas em atividades. Estas proveem o contexto, o controle e a estrutura de execuo (encadeamento, repeties, decises, paralelismo) das aes. Um DA , portanto, formado pelas aes que compem a atividade que est sendo modelada, estruturadas de alguma forma. A Figura 8.1 ilustra o modelo UML da atividade Organizar Pedido, executada enquanto um objeto da classe Pedido se encontra no estado Verificando Disponibilidade Estoque (ver DME da Figura 7.1). Os elementos do diagrama da gura esto comentados nos itens anotacionais da UML (textos dentro de retngulos com pontas dobradas ligadas aos elementos comentados por meio das linhas tracejadas). Na Figura 8.1, o continer externo ("retngulo com os vrtices arredondados" que contm os demais elementos do modelo) corresponde atividade. Nesse continer esto as aes que compem a atividade, estruturadas conforme a sequncia denida pelos sentidos das setas de transies. A primeira ao a ser executada indicada pelo n inicial (o pseudoestado inicial, segundo a terminologia usada nos DMEs). O smbolo de nal de atividade ("olho de boi") indica o ponto onde a atividade se encerra. Em nossa associao com os DMEs, as aes, como podemos perceber por seus identicadores, so estados de atividade que, quando terminam, provocam as sadas para os estados seguintes, conforme as transies de sada.

8.2 Ns de Deciso (Desvios) e Qualicao de Fluxos

At aqui falamos em transies, mas elas, nos DAs, se chamam uxos. O conceito o mesmo e, por isso, elas possuem a mesma notao grca das transies nos DMEs: segmentos de reta, poligonais ou curvas com seta aberta em uma das pontas. Os uxos podem ser qualicados ou no qualicados, ou seja, podem possuir ou no rtulos; no caso de possuir, eles especicam somente as condies em que so trilhados1 . Nesses casos, as condies, tambm chamadas de guardas, so colocadas obrigatoriamente entre colchetes ("[" e "]"), tal qual nos DMEs. Em outras palavras: um uxo no qualicado de sada de uma ao signica que ele trilhado incondicionalmente pela ocorrncia do evento de m da ao da qual ele parte.
No so mencionados eventos nem aes, at porque os eventos so os de nal de execuo e as aes podem estar especicadas como a ao seguinte, no uxo.
1

124

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

Organizar Pedido

Atividade

N inicial

Aes

Obter primeiro pedido da fila de pedidos a serem atendidos

Obter a localizao fsica do item do pedido

Verificar se a quantidade desej ada para o item est disponv el em estoque

[h mais itens no pedido]

[quantidade desejada para o item NO est disponvel em estoque] [seno]

Colocar o item no carrinho de despacho

Marcar no pedido o item faltante

Ns de deciso

[fim da lista de itens do pedido]

Conferir se todos os itens do pedido esto no carrinho de despacho

[seno] [todos os items do pedido esto no carrinho de despacho]

Encaminhar o carrinho de despacho para o setor de despacho

Encaminhar o carrinho de despacho para a fila de pedidos com pendncias

Final da atividade

Figura 8.1: DA da atividade Organizar Pedido. A atividade do diagrama executada pelo estoquista da ZYX, nossa empresa ctcia.

8.3. SEPARAES E JUNES

125

Fluxos qualicados partem dos chamados ns de deciso (ou desvios), representados gracamente como losangos, como est ilustrado na Figura 8.1. Segundo a UML, um n de deciso um n de controle que escolhe entre uxos de sada, obrigatoriamente guardados com as respectivas condies de sada. Podemos representar quantos uxos de sada necessitarmos, desde que as guardas especiquem condies lgicas mutuamente excludentes, ou seja, s possvel sair por um nico uxo de sada de um n de deciso. Com isso, podemos modelar os cases ou switches das linguagens de programao. Para facilitar a formulao das expresses, usual especicar as condies usando expresses lgicas e complement-las usando "else" ou "seno". A contrapartida de um n de deciso um n de intercalao. A intercalao recebe os vrios uxos de entrada que correspondem aos desvios e tem um nico uxo de sada, ou seja, uma intercalao dene o ponto onde os desvios correspondentes s decises terminam e o uxo retorna a um nico caminho. Uma intercalao tem que ser colocada sempre que colocamos um n de deciso, a menos que o uxo termine ou que outra deciso precise ser tomada. Adotamos o mesmo smbolo de ns de deciso para os ns de intercalao: o losango. Conforme ilustrado na Figura 8.2 (que um detalhe da Figura 8.1), aps a obteno, por parte do estoquista, da localizao fsica do item no estoque, feita a vericao se a quantidade desejada do item est ou no disponvel em estoque. Caso a quantidade desejada do item no esteja disponvel em estoque, o estoquista marca no pedido o item faltante. Caso a quantidade desejada do item esteja disponvel em estoque, o estoquista coloca o item no carrinho de despacho. Logo aps uma ou outra dessas alternativas ter sido trilhada, outra deciso tomada: se h mais itens no pedido (e a prossegue para mais uma iterao) ou se o pedido composto de apenas um item.

8.3 Separaes e Junes

Outros elementos importantes da notao grca usada em DAs so as separaes e as junes (forks e joins, respectivamente, em ingls). Esses elementos dotam os DAs de mecanismos para modelagem de aes que ocorrem concomitantemente, tornando-os sucientemente completos para modelagem de processamento paralelo e processos de negcio. Separaes marcam pontos da atividade em que se iniciam uxos de aes que ocorrem em paralelo, compreendendo um uxo de entrada e dois ou mais uxos de sada. Ao contrrio dos ns de deciso, em que a atividade executa um desvio, tomando um caminho ou (exclusive) outro, dependendo das condies avaliadas, nas separaes todos os uxos de sada so trilhados ao mesmo tempo, caracterizando o

N inicial

Aes

126

Obter primeiro pedido da fila de pedidos a serem atendidos

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

Obter a localizao fsica do item do pedido

Verificar se a quantidade desej ada para o item est disponv el em estoque

[h mais itens no pedido]

[quantidade desejada para o item NO est disponvel em estoque] [seno]

Colocar o item no carrinho de despacho

Marcar no pedido o item faltante

Ns de deciso

[fim da lista de itens do pedido]

Conferir se todos os itens do pedido esto no carrinho de despacho

[seno] [todos os items do pedido esto no carrinho de despacho]

Figura 8.2: Ns de deciso em diagramas de atividade (um detalhe da Figura 8.1).

Encaminhar o carrinho de despacho para o setor de despacho Encaminhar o carrinho de despacho para a fila de pedidos com pendncias

que chamamos de mltiplos os de execuo (multithreading em ingls). A Figura da atividade 8.3 especica o processo de tratamento do pedido na ZYX, imaginando Final que trs setores esto envolvidos no seu processamento: o setor nanceiro, para tratar das questes relativas ao pagamento pelo pedido, o setor de atendimento, que trata da recepo do pedido e da elaborao da fatura, e o setor de processamento, que executa as atividades referentes separao dos itens, embalagem e despacho dos pedidos. Segundo o diagrama da Figura 8.3, a partir do momento em que o setor de atendimento da ZYX recebe o pedido de um cliente, ele notica o setor nanceiro para que tome as providncias para a cobrana do pedido e encaminha uma cpia do pedido para o setor de processamento, para que seus itens sejam separados e

Financeiro

8.3. SEPARAES E JUNES

signal sending Solicitar Pagamento

signal receipt Pagamento Confirmado

Atendimento

Receber pedido

Preparar fatura

cpia do pedido

Organizar pedido [seno]

[pedido completo] Notificar transportadora Embalar pedido ActivityFinal

Processamento

Figura 8.3: O processamento de pedidos na empresa ctcia ZYX.

signal receipt Pedido Completo

127

128

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

embalados para entrega. Concomitantemente, a fatura deve ser preparada pelo atendimento, pois dever ser anexada ao pedido. Os trs setores da ZYX trabalham, a partir do recebimento do pedido, de forma independente, executando as demais aes para o despacho do pedido. Essa "separao" de responsabilidades, independncia ou autonomia denotada pela barra grossa vertical que se assemelha a um garfo (da o nome de fork, que signica garfo, em ingls), com um uxo de entrada (o que vem da ao Receber Pedido), e trs uxos de sada. As contrapartidas das separaes so as junes, que marcam pontos de sincronismo entre os diversos os de execuo criados pelas separaes. O processamento s passa da juno quando todos os os de execuo que nela convergem so terminados, como se a juno fosse um "ponto de encontro". Na Figura 8.3, Embalar Pedido s ocorre aps a fatura ter sido preparada e o pedido ter sido organizado (os itens terem sido separados no carrinho de entrega). Isso pode ser devido, por exemplo, necessidade de a fatura ser embalada junto com os itens que compem o pedido. De forma anloga, a transportadora s pode ser noticada (ao Notificar Transportadora) de que uma entrega deve ser feita se o pedido tiver sido embalado e o pagamento tiver sido informado ZYX. Junes no so obrigatrias aps uma separao. H os de execuo que podem permanecer em execuo "para sempre", sem a necessidade de sincronismo com qualquer outro uxo. Os uxos tambm podem se encerrar antes que a juno ocorra, mas deixamos para tratar disso em detalhes quanto falarmos de ns de uxos, mais adiante, ainda neste captulo. Mltiplos uxos de entrada em uma ao caracterizam o que a UML chama de juno implcita; ou seja, quando vrios uxos convergem diretamente em uma ao, isso signica que a ao s executada quanto terminam todas as aes que originaram esses uxos.

8.4 Parties
Parties so usadas quando h necessidade de indicar quem executa as aes; as aes colocadas em uma determinada partio so executadas pelo ator/setor indicado na partio. A Figura 8.3 ilustra as parties correspondentes aos trs setores da ZYX que participam do processamento de pedidos: Processamento, Atendimento e Financeiro. Parties tambm so chamadas raias de natao. Parties podem ser hierarquizadas (veja a Figura 8.4) e podem representar mais de uma dimenso (veja Figura 8.5).

8.5. FLUXOS DE OBJETOS

129

Processamento

Figura 8.4: Parties hierarquizadas.

A Figura 8.4 especica que os subsetores de Estoque e de Despacho pertencem ao setor de Processamento. A Figura 8.5 especica que os subsetores B1 e B2 pertencem ao setor B e os subsetores A1 e A2 pertencem ao setor A. Alm disso, uma ao colocada na "clula" A1-B1, por exemplo, especica que ela executada de forma colaborativa pelos setores A1 e B1.

8.5 Fluxos de Objetos

Durante a execuo das aes em uma atividade comum que objetos sejam passados entre aes. Por vezes precisamos representar esse trfego de objetos. Por exemplo: na Figura 8.3, queremos especicar que o setor de atendimento passa ao setor de processamento uma cpia do pedido para que o encarregado separe os itens que compem o pedido, colocando-os no carrinho de entrega. Objetos so denotados por retngulos que se situam no uxo entre as aes que os passam e as que os recebem. O nome do objeto deve ser colocado no interior do retngulo na forma objeto:classe, em que a referncia instncia ou classe (uma ou outra) opcional. Por exemplo, as formas a seguir so aceitveis: copiaFatura:Fatura, copiaFatura e :Fatura.

Estoque

Despacho

130

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

B
B1
Financeiro
signal sending Solicitar Pagamento

B2
signal receipt Pagamento Confirmado

A
Atendimento

A2

A1

Receber pedido

Preparar fatura

Figura 8.5: Parties hierarquizadas e em duas dimenses.

cpia do pedido

Processamento

Organizar pedido

[pedido completo] [seno]

Embalar pedido

Figura 8.6: Atividade aninhada em outra (um detalhe da Figura 8.3).

signal receipt Pedido Completo

8.6 Atividades Aninhadas

Alm de aes, as atividades podem conter, recursivamente, outras atividades. possvel representar gracamente uma atividade aninhada (a que est dentro de outra) como uma ao em um diagrama, marcando-a com um pequeno smbolo no canto inferior direito (ver Organizar Pedido, na Figura 8.3, que detalhada na Figura 8.6). As atividades aninhadas so detalhadas em termos de suas aes e/ou atividades em outro diagrama do modelo.

8.7. SINAIS E EVENTOS TEMPORAIS

131

signal sending Solicitar Pagamento

signal receipt Pagamento Confirmado

Figura 8.7: Envio e recepo de sinais (um detalhe da Figura 8.3).

Preparar fatura

Receber pedido

O smbolo ocial da UML para atividade aninhada um pequeno tridente no canto inferior direito, no mais as duas caixas conectadas da Figura 8.6, usadas nas verses anteriores 2.0. Os CASEs, como o caso do que usei para elaborar as ilustraes, demoram algum tempo para se adaptar s mudanas da notao que ocorrem entre verses cpia do pedido da linguagem.

[pedido Organizar pedido 8.7 Sinais e Eventos Temporais completo] Embalar A UML dispe de notao grca para a representao de envio e de recepo de pedido sinais. Segundo a Figura 8.7 (que tambm um detalhe da Figura 8.3), o setor nanceiro solicita o pagamento (enviando um sinal, que pode representar uma ligao telefnica ou um e-mail) ao cliente da ZYX e aguarda a conrmao desse pagamento, possivelmente por parte da operadora do carto de crdito, para que possa dar signal receipt Pedido Completo prosseguimento ao processamento do pedido. O envio e a recepo de sinais so aes especiais rotuladas, respectivamente, com as palavras-chave signal sending e signal receipt. [seno]

O envio de um sinal em um modelo de sistema pode estar associado ao lanamento de uma interrupo, e a recepo pode estar associada execuo da ao de tratamento dessa interrupo. Um evento temporal algo que ocorre em um instante determinado ou aps determinado tempo medido com relao ocorrncia de outro evento (ver Seo 7.5). Um evento temporal pode dar origem a um uxo. Na UML, eventos temporais possuem a notao grca ilustrada na Figura 8.8, que especica a situao em que a ao de fechamento do ms contbil iniciada pela ocorrncia do (evento de) m de ms.

signal sending Solicitar Pagamento

signal receipt Pagamento Confirmado

132

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

Receber pedido

Preparar fatura

Figura 8.8: cpia do pedido

Representao de eventos temporais na UML.

Organizar pedido

[pedido completo] [seno] Notificar transportadora

Embalar pedido

Activ

signal receipt Pedido Completo

Figura 8.9: Exemplo de m de uxo e recepo de sinal (detalhes da Figura 8.3.

8.8 Fim de Fluxo ou Cancelamento

Aps uma separao, quando um uxo de entrada d origem a dois ou mais uxos de sada (os de execuo ou threads, em ingls), pode ser necessrio terminar um ou mais desses uxos de sada antes que ocorra uma juno (que, j vimos, nem sempre necessria), sem que isso provoque o m de toda a atividade. Esse trmino de um uxo (tambm chamado de cancelamento) representado por um crculo com um "X" inscrito nele. A Figura 8.9 ilustra o trecho da Figura 8.3 que representa o m do uxo, caso um pedido seja constatado como incompleto aps a sua organizao. O trecho do DA ilustrado na Figura 8.9 particularmente interessante porque especica que a embalagem do pedido s ocorre aps a preparao da fatura e do pedido estar completa, algo que pode ser vericado aps a organizao ou sinalizado de alguma forma um tempo depois. Outro exemplo de cancelamento ilustrado na Figura 8.10. No caso, as aes B, C e D so executadas em paralelo. Ao nal da ao B, se a condio c1 verdadeira,

8.9. CONECTORES

133

[c2] B [c1]

Figura 8.10: Outro exemplo de m de uxo.

tambm os nais das aes C e D so aguardados na juno para que a ao E seja iniciada. Se a condio c2 verdadeira, o uxo de sada de B cancelado e E iniciada somente aps os nais das aes C e D.

8.9 Conectores
Os conectores so usados para evitar longas setas de uxos e em quebras de pginas. As Figuras 8.11a e 8.11b representam as mesmas situaes, ilustrando sucientemente bem a utilidade de conectores.

8.10 Pinos, Transformaes e Regies de Expanso

Uma ao pode receber parmetros (objetos, valores, listas de objetos ou de valores etc.) da ao anterior e pode passar parmetros para a ao seguinte na sequncia. Caso seja importante especicar esses parmetros, usamos a notao de pinos da UML. Um pino denotado por um pequeno retngulo junto caixa de ao, rotulado com o nome do parmetro que representa. Por exemplo, caso um pedido seja preenchido durante o recebimento de uma fatura e seja necessrio pass-lo para que

134

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

(a)

(b)

Figura 8.11: Modelos com signicados idnticos, sem conectores (a) e usando conectores (b).

a rotina de recebimento do pagamento seja executada, podemos usar a notao de pinos, como ilustra a Figura 8.12a, ou a notao equivalente, na Figura 8.12b, que ilustra o objeto Pedido como parte do uxo entre aes. H situaes em que o parmetro de entrada de uma ao deve ser o resultado de uma operao a ser aplicada no parmetro que sai da ao anterior na sequncia. Nesse caso, aplica-se sobre o uxo que parte de uma ao para a outra o que a UML chama de transformao, representada no diagrama por dois ou mais uxos distintos partindo do pino de sada da ao anterior na sequncia. As transformaes devem ser livres de efeitos colaterais; ou seja, quando aplicadas, no podem alterar o estado do ambiente, mudando valor de qualquer atributo de qualquer objeto. Transformaes so, por exemplo, operaes de consulta aplicadas sobre os parmetros, como selees de ocorrncias em uma lista, escolha de campos especcos de um formulrio etc. A Figura 8.13 ilustra a situao em que um laudo produzido por uma atividade de anlise de crdito, mas apenas o nome, o endereo de e-mail e o parecer, que so campos selecionados do laudo, so os parmetros necessrios para a atividade de informao do resultado da anlise ao solicitante do emprstimo. H ainda situaes em que o parmetro de sada de uma ao composto por

8.10. PINOS, TRANSFORMAES E REGIES DE EXPANSO

135

Receber Fatura Pedido Pedido

Receber Pagamento

(a)

Receber Fatura

Pedido Receber Pagamento

(b)

Figura 8.12: Pinos como forma de passagem de parmetros entre aes (a) e a notao equivalente de uxo de objetos (b).

Elaborar Anlise de Crdito

Laudo

Nome

eMail

Parecer

Informar Resultado de Anlise de Crdito

Figura 8.13: Transformao aplicada sobre parmetro de sada de uma ao.

136

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

Aplicar Prov as

Pilha de Provas parallel

Corrigir Prov a

Lanar Nota

Relao de Notas

Classificar Alunos

Figura 8.14: Regio de expanso para execuo de sequncia de aes em paralelo.

uma lista de itens que iniciam mltiplos os de execuo de um conjunto de aes. Esse conjunto de aes passa a ser executado concorrentemente para cada item na lista, caracterizando o que se chama de regio de expanso. A Figura 8.14 ilustra a seguinte situao: a ao Aplicar Provas produz uma pilha de provas de alunos a serem corrigidas por um pool de professores. Em seguida, cada professor desse pool obtm a prxima prova da pilha, corrigindo e lanando a nota. A sequncia de aes Corrigir Prova e Lanar Nota executada em paralelo pelos professores. S aps as correes e o lanamento de notas de todas as provas que a ao Classificar Alunos executada. A regio tracejada que contm as aes de correo e de atribuio de notas a regio de expanso. Os dois conjuntos de pinos de entrada e de sada dessa regio representam conjuntos ou listas (a pilha de provas e a lista de notas, no caso).

8.11. ESPECIFICANDO GRAFICAMENTE CASOS DE USO COM DAS

137

8.11 Especicando Gracamente Casos de Uso com DAs

Vimos no Captulo 4 que os diversos passos que compreendem a interao usuriosistema em um caso de uso devem ser especicados de forma padronizada. A forma l descrita bem aceita porque no requer, por parte do cliente que homologa a especicao, habilidades especiais alm do conhecimento a respeito do negcio. No entanto, ela sujeita a erros por algumas razes: no concisa. Embora o analista precise manter o foco na conciso, isso muitas vezes no possvel ou facilmente obtenvel. Uma especicao completa quase invariavelmente enfadonha para quem a formula e para quem a l. A busca pela conciso pode provocar falta de completude; dicilmente completa. No s a busca pela conciso que pode ser a causa de incompletude; muitas vezes acontecem esquecimentos de certos "caminhos" dentro dos uxos, pela diculdade de ter uma viso mais em alto nvel quando estamos formulando a especicao textual; pouco manutenvel. As alteraes nos uxos so penosas, seja pela extenso que quase invariavelmente possuem, seja pela no disponibilidade de uma ferramenta adequada, j que frequentemente so usados documentos padronizados do MS-Word com tabelas e links estticos. Assim sendo, alteraes podem facilmente gerar inconsistncias na documentao. As especicaes feitas de forma textual precisam ainda ser interpretadas e convertidas em diagramas de sequncia pelos projetistas (essa tarefa se chama realizao dos casos de uso) na fase de elaborao ou em linguagem de programao pelos programadores na fase de construo do sistema, quando se usa um processo gil. nesse ponto que a incompletude da especicao evidenciada, demandando o retrabalho de especicao dos casos de uso e, quase sempre, novas entrevistas com os usurios. Felizmente, complementarmente s descries textuais ou alternativamente a elas, podemos elaborar a especicao dos casos de uso utilizando os diagramas de atividade da UML. As vantagens de usarmos os DAs para as especicaes de casos de uso anulam parcialmente as desvantagens das especicaes textuais. So elas: a conciso. DAs, como os demais modelos UML, produzem especicaes concisas; a facilitao da busca pela completude. Isso se d pelo fato de identicarmos facilmente, de modo visual, os pontos de desvios (as idas para uxos

138

CAPTULO 8. DIAGRAMAS DE ATIVIDADE alternativos) e de podermos implement-los tambm com facilidade no modelo com os recursos de edio de que a ferramenta CASE dispe; a manutenibilidade. As alteraes nos uxos so facilmente implementadas no modelo grco com a ajuda da ferramenta CASE, conforme j mencionamos.

Quando estamos tratando de modelos de sistemas, outra vantagem decorrente do uso dos DAs na especicao de casos de uso que eles podem facilitar o trabalho dos programadores, pois a transformao do modelo em cdigo representa uma transio bem mais suave e direta do que a transformao de uma especicao em linguagem coloquial, em cdigo. A necessidade do cliente de entender a notao grca para poder homologar a especicao , no entanto, um bice. Por isso, eu particularmente acho razovel que o analista inicie a especicao dos casos de uso com DAs e, com bases nesses DAs, elabore a especicao textual para homologao pelo cliente. Essa a forma que, no meu entender, colabora muito para que se obtenham descries textuais mais completas. Existem basicamente duas maneiras diferentes de descrever casos de uso com o emprego de DAs: especicando unicamente as aes do sistema ou incluindo tambm as aes dos atores na especicao. Nesse caso, usualmente trabalhamos com parties para separar o que cada um faz; uma partio para as aes do sistema e uma para as aes de cada ator. O diagrama de atividade da Figura 8.15 descreve gracamente o caso de uso Rels e Seus Estados, descrito de forma textual na Tabela 4.4. Neste caso, apenas as aes do sistema correspondem a aes no DA. Voc pode notar na Figura 8.15, que a chamada ao caso de uso Acionar Rels do passo 7 do CT na Tabela 4.4 corresponde atividade aninhada Acionar Rels. Pode notar tambm que representamos a deciso do usurio de pressionar o boto Sair, terminando a atividade, como um uxo guardado com a condio "usurio pressiona o boto Sair. Fica tambm como sugesto a forma como representamos gracamente as repeties "para todos", tratando cada elemento da lista em um loop (lao). O diagrama de atividade da Figura 8.16 descreve gracamente o mesmo caso de uso, porm usando parties. Nessa segunda forma, as aes do sistema so colocadas em uma partio, e as aes do supervisor de segurana so colocadas em outra partio. Voc pode notar na Figura 8.16 dois smbolos de nal de atividade. Ao contrrio do smbolo de incio de atividade, que deve ser nico, podemos ter quantos smbolos de nal de atividade quisermos colocar no diagrama para torn-lo visualmente mais simples. Isso evita longos uxos no diagrama.

8.11. ESPECIFICANDO GRAFICAMENTE CASOS DE USO COM DAS

139

Obter dos parmetros o nmero de rels e seus nomes.

Verifica se usurio est habilitado para alterar os estados dos rels.

[usurio no est habilitado] [usurio est habilotado]

Exibir o nmero e o nome do prximo rel na lista de rels e dois radio buttons (ativ ados), definindo-os com o estado correspondente ao estado corrente do rel.

Exibir o nmero e o nome do prximo rel na lista de rels e dois radio buttons (no ativ ados), definindo-os com o estado correspondente ao estado corrente do rel.

[ainda h rel na lista] [ainda h rel na lista] [fim da lista de rels] [fim da lista de rels]

Exibir o boto "Sair" Exibir os botes Sair e Ligar/Desligar Rels.

[usurio pressiona o boto "Sair"]

[usurio pressiona o boto "Sair"] [usurio pressiona o boto "Ligar/Desligar Rels"]

Acionar Rels

Figura 8.15: Especicao de caso de uso apenas com aes correspondendo a aes do sistema.

140

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

Sistema

Superv isor de Segurana

Obter dos parmetros o nmero de rels e seus nomes.

Verifica se usurio est habilitado para alterar os estados dos rels.

[usurio no est habilitado]

[usurio est habilotado]

Exibir o nmero e o nome do prximo rel na lista de rels e dois radio buttons (ativ ados), definindo-os com o estado correspondente ao estado corrente do rel.

Exibir o nmero e o nome do prximo rel na lista de rels e dois radio buttons (no ativ ados), definindo-os com o estado correspondente ao estado corrente do rel.

[ainda h rel na lista]

[ainda h rel na lista] [usurio pressiona o boto "Sair"] [fim da lista de rels] Exibir o boto "Sair"

Exibir os botes Sair e Ligar/Desligar Rels.

Definir nov os estados dos rels.

[usurio pressiona o boto "Ligar/Desligar Rels"]

Acionar Rels

[usurio pressiona o boto "Sair"]

Figura 8.16: Especicao de caso de uso com aes do sistema e do usurio em parties distintas.

8.12. RESUMO DO CAPTULO

141

importante ressaltar que essas duas formas so meramente sugestes. H outras formas, como, por exemplo: pintar as aes do sistema de uma cor e de cores diferentes as aes de cada ator, ao invs de usar parties; representar somente as aes do sistema, porm rotulando os uxos com eventos correspondendo s aes dos atores. Essa forma no correta segundo a UML2 e, por isso, no possvel adotar essa forma usando alguns CASEs. A despeito disso, essa forma uma alternativa bastante interessante. Tendo a capacidade de modelar processos em diversos nveis conceituais, os diagramas de atividade so um poderoso aliado de analistas de negcio, de analistas de sistemas e de projetistas, tornando-se um dos principais diagramas da UML.

8.12 Resumo do Captulo

Diagramas de atividade DAs enfocam o uxo de controle entre aes que compem um processo qualquer, especicando a ordem de execuo das aes. Contando com os elementos de notao grca que incorporaram nos ltimos anos, os DAs vm sendo usados em inmeras aplicaes, dentro e fora da rea de desenvolvimento de sistemas, tais como especicao de algoritmos complexos, modelagem de processos de negcio e workows. DAs tm particular utilidade na especicao de casos de uso, pois as aes podem ser mais facilmente modeladas e os caminhos entre o incio do processamento e os possveis ns (os cenrios) podem ser identicados visualmente e, portanto, com mais facilidade. Alm disso, podemos contar com as ferramentas CASE para rpida e interativamente esboar possveis alternativas de realizao da interao entre usurio e sistema. Um DA modela uma atividade, que contm aes e/ou outras atividades. A ordem de execuo dessas atividades denida pelos uxos, que apontam a passagem de ao em ao. A primeira ao a ser executada na atividade indicada pelo n inicial. Um ou mais ns nais indicam os nais da atividade. Sinais e eventos temporais tambm podem dar origem a aes em uma atividade. Durante a execuo, desvios no uxo geral de execuo podem ser feitos com base em expresses lgicas avaliadas nos ns de deciso em tempo de execuo da atividade. Caso um uxo precise dar origem a mais de um uxo, gerando paralelismo (vrias aes sendo executadas ao mesmo tempo), usado um smbolo de separao.
2

Fluxos s podem ser rotulados com guardas, se eles partem de ns de deciso.

142

CAPTULO 8. DIAGRAMAS DE ATIVIDADE

Caso diferentes uxos precisem ser sincronizados (tornar-se, de novo, um s uxo), um smbolo de juno inserido no diagrama para representar o "ponto de encontro" dos uxos. Um importante elemento da notao grca dos DAs a partio, que pode ser em uma ou em duas dimenses. Parties possibilitam que representemos responsabilidades na execuo de aes, bastando colocar na partio do executor as atividades pelas quais ele responsvel. Objetos podem passar de ao em ao, representando artefatos produzidos ou consumidos por elas. Fluxos originados em uma separao podem ser cancelados (terminados), mantendo os demais uxos ativos ou seja, sem que a atividade seja encerrada. Parmetros passados de ao em ao podem ser representados por pinos. Um pino pode dar origem a mais de um uxo, desde que seja para a mesma ao de destino, caracterizando uma transformao, ou seja, o parmetro que o pino representa pode dar origem a outro, por uma transformao que no pode alterar o contexto (um ltro, por exemplo). Diagramas de atividade so particularmente teis para especicar os passos dos casos de uso, pois eles nos "foram" a considerar todos os possveis desvios ao longo da interao usurio-sistema e nos permitem represent-los facilmente com o uso do CASE.

8.13 Exerccios Propostos

1. Elabore um diagrama de atividade com suas aes e decises tomadas em um dia de semana tpico, do momento em que voc desliga o despertador at sua chegada no trabalho ou escola. Considere a possibilidade de executar aes em paralelo. 2. Refaa o incio do DA do Exerccio 1, considerando a soluo que demos para ele at a hora do banho, por simplicidade. Considere ainda que o despertador funciona como um gerador de eventos (os alarmes) que precisam ser "tratados" por voc. Considere tambm a possibilidade de voc usar a funo "soneca" para dormir mais um pouquinho at no haver mais tempo para isso. 3. Descreva, usando DAs, o caso de uso Registrar Compra em um sistema para um supermercado hipottico, do qual participa o caixa registrando a compra e, eventualmente, o Cliente, quando o pagamento feito por dbito ou crdito no carto e ele precisa informar a senha, alm do supervisor de venda, quando

8.13. EXERCCIOS PROPOSTOS

143

necessrio retirar um ou mais itens da lista ou reimprimi-la. Use sua vivncia para estabelecer os passos que compem a descrio, mas no se esquea de considerar as situaes em que: tudo d certo; voc no tem o dinheiro suciente para pagar por toda a compra, podendo perceber isso durante o registro ou no nal dele; a ta de papel da registradora acaba no meio da compra e o supervisor precisa intervir com seus "superpoderes" para comandar a reimpresso da lista desde o incio; voc discorda do preo de um item que estava em oferta e pede ao caixa que retire o item da lista. Nesse caso, o supervisor tambm precisa intervir; o cdigo de barras no pde ser lido pela leitora tica e o caixa o informa pelo teclado; o cdigo do item no consta do cadastro; voc paga em carto com chip (no dbito ou no crdito) ou em dinheiro, o que bem menos frequente naquele supermercado. A descrio parcial na forma textual do caso de uso se encontra feita como resposta do Exerccio 3 do Captulo 4. Use-a como base. As solues encontram-se a partir da Pgina 219.

CAPTULO
145

D IAGRAMAS DE S EQUNCIA : C ONCEITOS B SICOS

Unity is strength... when there is teamwork and collaboration, wonderful things can be achieved. Mattie Stepanek

Em uma organizao, os processos so tipicamente executados por indivduos especializados, que exercem suas responsabilidades e atuam de forma colaborativa, trocando informaes (conversas telefnicas e na copa, no cafezinho, e-mails, sinais visuais etc.) e objetos tangveis (documentao impressa, informao em CD etc.). Essa comunicao segue uma sequncia estabelecida na cultura da organizao, cultura essa que idealmente resultante de observaes e anlises feitas por seus gestores e por especialistas e analistas do negcio; documentada em manuais de procedimentos da organizao. Para ilustrar, quando hora de fechar o balano da ZYX, alocamos contadores (instncias da classe Contador) na realizao dessa tarefa. Eles tm responsabilidades e, para realiz-las, executam um conjunto de operaes (somar, diminuir, multiplicar, dividir, analisar lanamentos, selecionar contas etc.). Durante a tarefa, trocam mensagens e artefatos entre si e, quase invariavelmente, delegam tarefas a outros

146

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

membros da equipe, contando com a colaborao de auxiliares de contabilidade, de auxiliares administrativos e de mensageiros, dentre outros, todos instncias das respectivas classes. Eles executam as tarefas seguindo uma sequncia predenida, programada, de execuo de operaes e de passagem de mensagens. Analogamente, os programas de computador desenvolvidos segundo o paradigma de orientao a objetos so concebidos imaginando que existam objetos de classes diferentes que so instanciados na memria do computador e que executam cdigo especco, ou seja, cada classe de objetos executa seu conjunto especco de funes. Os objetos invocam funes de outros objetos utilizando mensagens que enviam a eles segundo sequncias predenidas (os programas) criadas pelos programadores de sistemas. As chamadas s funes de outros objetos compem o mecanismo de troca de mensagens entre objetos. Portanto, tal qual em um ambiente de trabalho, os objetos em um sistema interagem e colaboram, na sequncia programada, para a realizao das funes do sistema. Nessa breve introduo tratamos do que chamamos de colaborao entre agentes em um sistema e uma organizao pode ser vista como tal que interagem entre si para a realizao dos propsitos desse sistema. Cabe-nos denir como as colaboraes podem ser especicadas. A UML dispe de diagramas para isso. Um deles o Diagrama de Sequncia, de que trataremos neste e no prximo captulo.

9.1 Especicando Interaes por Meio de Diagramas

Para deixar bem claros os conceitos de interao e colaborao entre objetos em um sistema e para introduzir uma forma de especicao dessa interao, exploramos um pouco mais a comparao entre pessoas em um escritrio e objetos em um sistema. A Tabela 9.1 apresenta as correlaes que estabelecemos entre os principais conceitos mencionados nos dois ltimos pargrafos da seo anterior. Desconsiderado o aspecto pejorativo da associao de pessoas em uma organizao a objetos em um sistema, a Tabela 9.1 indica que a experincia dos administradores de empresas pode ser aplicada por analistas e projetistas de sistemas no desenvolvimento de sistemas elaborados segundo o paradigma da orientao a objetos e vice-versa. Os diagramas de sequncia (DSs) permitem especicar colaboraes, descrevendo a sequncia de mensagens passadas de objeto a objeto necessria para a realizao de um determinado procedimento, seja ele um processo de negcio ou uma funcionalidade em um sistema. Juntamente com os diagramas de comunicao e de viso geral da interao,

9.1. ESPECIFICANDO INTERAES POR MEIO DE DIAGRAMAS

147

Tabela 9.1: Correlao entre os principais conceitos de processos de negcios e orientao a objetos. Processos de Negcio Indivduos especializados Nome de um indivduo Prosses/especialidades dos indivduos Trocas de informaes e sinais Processos de negcio Alocao de um prossional de uma prosso especca em uma tarefa Operaes que um prossional executa para realizar suas responsabilidades Gestores e especialistas no negcio Manual de procedimentos da organizao Programas OO Objetos Identicador de um objeto Classes de objetos Chamadas de funes Rotinas, programas Instanciao (criao) de um objeto de uma classe especca na memria Mtodos (ou operaes) que compem a programao de um objeto Analistas e programadores Diagramas de sequncia

os diagramas de sequncia compem um subconjunto importante dos diagramas da UML genericamente chamados de diagramas de interao, por enfatizarem a interao entre objetos. Os diagramas de sequncia e os diagramas de comunicao (estes no discutiremos em detalhes neste texto) expressam basicamente a mesma informao, mas mostram-na de forma diferente. DSs so melhores que diagramas de comunicao na apresentao das responsabilidades de cada objeto, especialmente quando o aspecto da ordenao temporal relevante (o DS, como voc ver, tem um eixo para representar a dimenso temporal). A Figura 9.1 ilustra uma colaborao simples representada por um diagrama de sequncia e por um diagrama de comunicao, em que o objeto A solicita algo ao objeto B, que por sua vez solicita algo ao objeto C e se autodelega a execuo de algo, nessa sequncia (no se preocupe agora com o que signica cada smbolo nos diagramas; apenas caminhe de objeto a objeto seguindo a ordem numrica crescente das mensagens). Como as duas notaes so facilmente "intercambiveis", algumas ferramentas CASE dispem de funcionalidades para converter automaticamente um diagrama no outro.

148

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

(a)

(b)

Figura 9.1: Diagramas de sequncia (a) e de comunicao (b) especicando uma colaborao entre trs objetos.

No se preocupe, portanto, em desenvolver ambos os diagramas para uma mesma situao em um sistema. Alis, isso no nem um pouco recomendvel, no s por ser intil como tambm porque aumenta a possibilidade de inconsistncia entre os diagramas do modelo, embora bons CASEs ajudem nessa questo. Os diagramas de sequncia tm grande importncia na fase de projeto de sistemas de software, pois eles so usados para atribuir responsabilidades aos objetos do sistema e para a descoberta de operaes das classes, incluindo os detalhes dos parmetros dessas operaes. Em outras palavras, DSs servem para descrever como grupos de objetos colaboram em algum comportamento do sistema, representando o seu "funcionamento", ou seja, a sua programao. Os DSs e os demais diagramas de interao so a principal ponte entre a anlise e a implementao de um sistema, sendo por isso usados principalmente na fase de projeto. Dispondo de uma boa ferramenta CASE e provendo um conjunto de diagramas de sequncia e o diagrama de classes com detalhes sucientes, podemos gerar cdigo automaticamente. A isso chamamos de engenharia direta (a partir do modelo, a ferramenta gera o cdigo). Boas ferramentas CASE tambm dispem de recursos para a execuo de engenharia reversa, ou seja, a partir do cdigo, a ferramenta gera o diagrama de sequncia e o de classes.

9.2. CENRIOS

149

9.2 Cenrios
Mencionamos no Captulo 3 que uma instncia de um caso de uso uma execuo dele. Instncias diferentes de um mesmo caso de uso podem produzir resultados distintos, dependendo do contexto de cada uma e das aes, que podem ser distintas, dos seus atores. Cada instncia executada trilha possivelmente um caminho diferente, desde o incio do caso de uso at um dos possveis nais dele. Cada um desses caminhos diferentes caracteriza um cenrio. Como ilustrao, imagine o caso de uso Sacar Dinheiro no Caixa Eletrnico. H um incio (na maioria dos bancos o processo comea com a passagem do carto do cliente na mquina) e vrios possveis ns, como: o cliente tem o dinheiro e saca o que quer; o cliente no tem o dinheiro, mas pode usar o limite do cheque especial e saca o que quer; o cliente no tem o dinheiro todo e saca o que pode; o cliente no tem nada em conta, no tem cheque especial e nada saca; o cliente tem o dinheiro em conta, mas no saca o que quer porque j passou das 22h... Existe, ainda, a possibilidade de o cliente ter esquecido a senha, o que tambm vai levar o processo de saque a um ou mais outros possveis nais. Instncias diferentes de um mesmo caso de uso compem cenrios diferentes; um otimista, em que tudo d certo; outros pessimistas, em que tudo d errado e ainda outros nem to l, nem to c, em que nem tudo ocorre como o ator gostaria, mas mesmo assim ele ca satisfeito no nal. O principal cenrio corresponde ao que chamamos no Captulo 4 de curso (ou uxo) tpico, que a sequncia de passos que ocorre tipicamente. No caso do saque no caixa eletrnico, o curso tpico deve corresponder ao cenrio otimista, ou seja, ao sucesso no saque sem nenhum contratempo. Os demais cenrios passam por situaes alternativas (os cursos ou uxos alternativos). O nico curso que dene precisamente um cenrio o curso tpico, pois as condies para que ele seja trilhado do incio ao m esto bem denidas (so as condies de guarda que tipicamente ocorrem). Cursos alternativos no denem cenrios, pois um mesmo curso alternativo pode ser trilhado em vrios cenrios.

150

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

[c1] [c2]

[c3]

[c4]

[c5]

Figura 9.2: Diagrama de atividade facilitando a identicao visual de cenrios. Cenrio 1: aes A e C. Cenrio 2: aes A, D e G. Cenrio 3: aes A, B e F. Cenrio 4: aes A, B e E.

Quando tratamos de diagramas de atividade no Captulo 8, vimos que uma das aplicaes desses diagramas a especicao de casos de uso. Quando elaboramos a especicao de um caso de uso usando DAs, podemos visualizar bastante claramente os caminhos entre o incio do caso de uso e todos os possveis ns dele. A Figura 9.2 mostra um diagrama de atividades para ilustrar o mecanismo de identicao visual dos possveis cenrios. Na Figura 9.2 especicamos os cenrios pelas aes executadas em cada um deles. No entanto, muitas vezes mais efetivo especic-los pelas condies correspondentes aos desvios feitos ao longo dos uxos. Assim, o cenrio 1 seria mais efetivamente especicado pela condio c2 verdadeira; o cenrio 2, pela condio

9.3. O CICLO DE VIDA DOS OBJETOS

151

c3 verdadeira; o cenrio 3, pelas condies c1 e c5 verdadeiras; e o cenrio 4, pelas condies c1 e c4 verdadeiras. Poderamos especicar algo como "Cenrio 1: condio c2 verdadeira" etc.
Cenrios so um conceito importante para diagramas de sequncia porque so usados como orientao para as suas elaboraes com vistas diminuio da complexidade visual, conforme trataremos adiante, ainda neste captulo.

9.3 O Ciclo de Vida dos Objetos

O ciclo de vida de um objeto compreende tudo que acontece com ele durante o tempo decorrido entre a sua instanciao e a sua destruio. Essa denio , em princpio, simples, mas causa muita confuso nos alunos porque h dois contextos em que ela se aplica e h dois tipos diferentes de objetos aos quais se aplica. Os dois contextos correspondem aos dois tipos de memria em que o objeto pode se encontrar armazenado: a memria principal e a memria secundria. Os tipos de objeto so: os persistentes e os de vida efmera. Objetos persistentes so aqueles que precisam ser enviados memria secundria (em disco, num banco de dados, por exemplo) para que "sobrevivam" ao desligamento do sistema, se mantendo, portanto, acessveis aps o religamento do sistema. Se eles j existem na memria secundria e precisam participar de uma colaborao, eles so trazidos (na realidade, copiados) da memria secundria para a memria principal para que possam colaborar. Se no so mais necessrios na memria principal, eles so copiados de volta para a memria secundria, caso tenham sido modicados, e removidos da memria principal para que o espao que ocuparam ali possa ser liberado para uso por outros objetos. Objetos persistentes normalmente so instncias de classes de conceito como um determinado pedido ou um determinado cliente da ZYX. Objetos efmeros (ou de vida efmera) so aqueles que so instanciados para colaborar em alguma situao, podendo ser, depois disso, descartados, ou seja, simplesmente removidos da memria, sem necessidade de serem copiados para o disco. Isso libera espao na memria principal para a colocao de outros objetos. Normalmente esses objetos so instncias de classes de projeto ou das chamadas classes utilitrias como, por exemplo, classes de manipulao de datas, de cadeias de caracteres, de colees etc. Independentemente do tipo de objeto, ele precisa estar na memria principal para que possa colaborar para a realizao de uma funcionalidade do sistema, enviar

152

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

mensagens a outros objetos ou receber mensagens de outros objetos, executando uma ou mais operaes para trat-las. Da, a confuso que muitos fazem devida necessidade de instanciar (criar um espao na memria) um objeto da classe Pedido, por exemplo, para poder trazer os dados de um determinado pedido do banco de dados para a memria, achando que esse o incio do ciclo de vida desse pedido. Na realidade, o ciclo de vida do tal pedido j foi iniciado quando ele foi instanciado e, depois, armazenado em disco pelo caso de uso de criao de pedidos. O ciclo de vida s terminar quando o pedido for removido do banco de dados, feito por meio de outra funcionalidade do sistema, e no quando o objeto for eliminado da memria, para liberao de espao, aps sua persistncia em disco. Por essas razes, objetos persistentes tm normalmente ciclo de vida maior do que objetos efmeros.

9.4 Responsabilidades, Atributos e Operaes dos Objetos

Com o exemplo dos contadores e do fechamento do balano da ZYX, falamos h pouco de responsabilidades e das operaes necessrias para realiz-las. Ensinar como programadores escolhem os objetos que vo usar em uma colaborao , presumo eu, igual a ensinar um recrutador de um setor de Recursos Humanos a escolher pessoas para contratao. As responsabilidades que atribumos a um objeto e, portanto, aos demais objetos da mesma classe, devem ser baseadas na capacidade desse objeto de cumpri-las; no vejo, por exemplo, algum sentido em contratar um mdico para fechar os balanos da ZYX. Essa capacidade , em primeira anlise, baseada nos atributos desse objeto. Uma dica que dou aos projetistas , mais uma vez, baseada em uma lgica que me parece bvia para administrao de recursos humanos: Ao designarmos algum para executar algo, se temos de passar muita informao e detalhes a essa pessoa para que ela possa cumprir a tarefa, esse um sinal de que no estamos designando a pessoa certa para a execuo da tarefa. Trazendo essa lgica para nosso contexto, a escolha de um objeto para cumprir uma responsabilidade em uma colaborao deve ser feita com base nos atributos desse objeto, incluindo seus relacionamentos com outros objetos. Por exemplo, se precisamos obter o nome de um cliente da ZYX por meio dos seu cdigo de cliente, nada melhor do que atribuir coleo de clientes da ZYX a responsabilidade de

9.4. RESPONSABILIDADES, ATRIBUTOS E OPERAES DOS OBJETOS

153

responder a consultas desse tipo, na medida em que a instncia dessa classe possui associao com todas as instncias da classe Cliente, que so as que efetivamente tm os valores dos atributos codigoCliente e nomeCliente. H, portanto, situaes em que um objeto no possui os atributos necessrios para o cumprimento de determinada responsabilidade, mas possui uma associao com um ou mais objetos que possuem esses atributos. Nesse caso, vlido atribuir ao primeiro objeto a tal responsabilidade, que a delega parcial ou totalmente aos objetos associados que possuem esses atributos. No sei se voc percebeu, mas quando falamos que a coleo de clientes deveria ter a responsabilidade de obter o nome de um cliente dado o seu cdigo, acabamos de descobrir a necessidade de uma nova classe no diagrama: a classe ColecaoDeClientes (Clientela tambm um bom nome), cuja instncia "aponta" para todos os clientes da ZYX, ou seja, possui associaes com todas as instncias da classe Cliente. Como cada instncia da classe Cliente (tpica e idealmente) no conhece as demais, podemos atribuir mais uma responsabilidade classe ColecaoDeClientes: organizar a lista de (indexar) clientes da ZYX. Provavelmente outras responsabilidades sero atribudas a essa classe conforme o projeto avana. ento, algumas das responsabilidades da classe ColecaoDeClientes que so tipicamente encontradas em classes que representam colees: indexar os clientes da ZYX para um acesso eciente lista; pesquisar clientes na lista de clientes; atualizar no banco de dados qualquer alterao feita em qualquer cliente da ZYX; manter-se atualizada caso alguma alterao na lista seja feita por outro usurio; etc. Para efetuar uma busca de cliente por seu cdigo, por exemplo, solicitamos o cliente ao objeto da classe ColecaoDeClientes passando seu cdigo como parmetro de busca, e esse objeto trata de consultar cada objeto da classe Cliente com o qual ele se relaciona, perguntando seu cdigo e, caso o cdigo seja o da consulta, retornando o cliente. importante, nesse momento, voltarmos ao diagrama de classes e atualiz-lo, adicionando no diagrama a nova classe que acabamos de descobrir associada classe Cliente. O trecho alterado do diagrama de classes (aquele da Figura 5.2) car como na Figura 9.3. Enumeramos,

154

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

singleton ColecaoDeClientes + pesquisaClientePorCodigo(int) : Cliente 1

* Cliente endereco telefone

Figura 9.3: Incorporao de classe de projeto ao diagrama conceitual.

Repare que essa nova classe no uma classe conceitual, porque no faz parte do conceito. Ela foi criada para auxiliar nas situaes que enumeramos. Ela , portanto, uma classe de projeto. Com isso, o diagrama de classes de conceito (ou conceitual) promovido a diagrama de classes de projeto (ou de anlise e projeto, como preferem alguns projetistas) pela adio dessa classe no modelo. Repare tambm que essa classe recm-descoberta deve ter as seguintes caractersticas adicionais: deve possuir uma nica instncia, j que todo ndice deve ser nico. Essa a razo pela qual marcamos a classe como sendo singleton, que um padro de projeto que garante que a classe s ser instanciada uma nica vez, mesmo que invoquemos seu construtor inmeras vezes. Caso queira mais informaes sobre padres de projeto, consulte a referncia clssica sobre o assunto: Design patterns: elements of reusable object-oriented software, de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides ([7]); o objeto no precisa ir para o banco de dados (no uma classe persistente), pois pode ser reconstrudo sempre que o sistema iniciado. Portanto, as operaes necessrias ao cumprimento das responsabilidades de um objeto, se ainda no o foram, so descobertas na hora em que o colocamos para

9.5. O TRIP DA ANLISE

155

colaborar, passando a constar, nesse momento, do compartimento de operaes da classe do objeto no diagrama de classes. Eventualmente durante esse processo descobrimos outros atributos (notadamente os derivados) e associaes que se mostram necessrios para tornar o trabalho de programao mais simples.

9.5 O Trip da Anlise

Os DSs (alis, os diagramas de interao, de maneira geral) completam o que chamamos trip da anlise, cujas outras "pernas" so os casos de uso (a parte preponderantemente funcional), com suas descries, e os diagramas de classes (a parte preponderantemente estrutural). Costumamos dizer que os casos de uso em um sistema especicam o que para ser feito; as classes do diagrama de classes relacionam com quem faremos o que para ser feito; e os DSs so como faremos o que para ser feito, considerando com quem faremos o sistema. Essa conexo entre os trs conjuntos de diagramas em um sistema se d conforme ilustrado na Figura 9.4, que prezo como a ilustrao de uma das etapas de maior importncia em todo o processo de desenvolvimento de um sistema. De forma geral, o processo de construo (codicao) de sistemas com orientao a objetos segue sequncia de passos mostrada na Figura 9.4 para cada cenrio de cada caso de uso. Essa gura ilustra a sequncia de aplicao dos passos (conforme numerao entre parnteses), descritos a seguir: 1. tomamos como base o que temos a fazer (isso no l tanta novidade, convenhamos!). Isso feito por meio do cenrio extrado do caso de uso, ou seja, com base na sequncia de aes que o sistema precisa executar para tratar (processar) corretamente o cenrio enfocado; 2. para cada ao que compe o cenrio e com base no diagrama de classes, procuramos obter uma relao dos objetos que devero colaborar para a realizao da ao. Essa relao feita com base nas responsabilidades que atribumos a cada objeto (reveja o que falamos sobre responsabilidades, atributos e operaes de objetos); 3. estabelecemos a sequncia de mensagens (chamadas de operaes e parmetros das operaes) que um precisa passar a outro para que as aes sejam executadas;

156

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

Diagrama de Classes
1 Univ ersidade efehc oirnoicnuF
1 * odanidrobus * odacola

Caso de Uso

oacolA tem

*..1

rodacola

osiviD

1..*

Departamento

oacolA atad
tem

1 1..* 0..1

Operaes (4)

1..*

matricula

aloca

MeioTransporte
* Aluno frequenta * 1..* * 1..* Disciplina ministra 1..* * 0..1 Professor +chefe

...

Carro

Navio

Diagrama de Sequncia
Janela de Entrada de Pedido criar() * criar() verifica () [verfifica = true] retirar_item() refabricar_item() um Pedido uma linha de Pedido um item em Estoque

Objetos (2)

Interao (3)
[refabricar_item = true] new um Item de Refabricao [verfifica = true] new um Item de Entrega

Cenrio (1)

Figura 9.4: Diagramas de sequncia na formao de modelos completos de sistemas de software. Os nmeros entre parnteses correspondem ordem segundo a qual cada informao tratada no processo de construo do cdigo para o sistema.

4. relacionamos, nos compartimentos de operaes das classes dos objetos envolvidos, as operaes e os parmetros descobertos durante esse processo. Como voc pode constatar, os diagramas de sequncia tendem a "puxar" o projetista para nveis mais baixos de abstrao, conduzindo-o aos detalhes (nomes de operaes, parmetros, atributos de projeto e visibilidades). Dessa forma, elaborar DSs mantendo-se no nvel conceitual no uma tarefa simples (e na maioria das vezes isso no desejado), pois, como j mencionamos, DSs propiciam a representao dos detalhes.

9.6 As Dimenses dos Diagramas de Sequncia

Ao contrrio dos diagramas at ento apresentados, os DSs possuem eixos nas duas dimenses: a horizontal e a vertical. De forma bem geral, na dimenso horizontal relacionamos os objetos que participaro da colaborao que estamos modelando.

9.6. AS DIMENSES DOS DIAGRAMAS DE SEQUNCIA

157

A dimenso vertical representa a passagem do tempo, especicando as mensagens trocadas entre os objetos de forma ordenada com respeito ao tempo. Os detalhes de como apresentamos os elementos da notao grca nessas duas dimenses so apresentados nas duas sees a seguir.

A Dimenso Horizontal dos Diagramas de Sequncia

Objetos e usurios (instncias das classes e dos atores, respectivamente) compem a dimenso horizontal de um diagrama de sequncia. A ordem da colocao dos objetos nessa dimenso no tem signicado; normalmente usada a ordem em que vamos precisando da colaborao dos objetos, ou seja, conforme vamos adicionando os objetos na colaborao durante o processo de modelagem. De tempos em tempos, durante esse processo, damos uma "arrumada" na ordem dos objetos, arrastando-os para a esquerda ou direita, objetivando uma melhor apresentao visual do modelo, sem qualquer alterao em seu signicado. No modelo ilustrado na Figura 9.1a, poderamos, por exemplo, arrastar o objeto B para a esquerda do objeto A (resultando, portanto, na ordem B, A e C dos objetos, da esquerda para a direita na dimenso horizontal), sem qualquer alterao no signicado do modelo. Objetos so representados por retngulos contendo seus identicadores, formulados tipicamente conforme uma das seguintes maneiras: obj:classe (por exemplo, Manuel:Supervisor, signicando o "objeto" Manuel da classe Supervisor); :classe (por exemplo, :Supervisor, signicando um determinado objeto da classe Supervisor, no sendo importante, no entanto, qual esse objeto); ou um(a)Classe (por exemplo, umSupervisor, signicando a mesma coisa que no item acima). Quando, para a realizao de uma atividade, so necessrios, por exemplo, dois objetos da classe Funcionario, uma sugesto que os identiquemos no diagrama como umFuncionario e outroFuncionario ou primeiroFuncionario e segundoFuncionario. Habitualmente sublinhamos os identicadores para denotar que nos referimos a instncias (e no a classes). O sublinhado para denotar objetos em diagramas de sequncia no mais obrigatrio a partir da UML 2.0.

158

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

A Dimenso Vertical dos Diagramas de Sequncia

A dimenso vertical representa o tempo, que evolui de cima para baixo nos DSs, ou seja, o que est abaixo no diagrama acontece depois do que est acima. As linhas de vida dos objetos compem a dimenso vertical, especicando o que acontece com eles, representando como interagem entre si. Representam tambm o foco de controle, ou seja, a ativao e a desativao de objetos quando eles executam algo ou delegam a algum outro objeto a execuo de algo por meio de mensagens que enviam. Representam tudo que acontece com os objetos durante seus ciclos de vida. A linha de vida denotada por um segmento de reta vertical tracejado, iniciando na base do retngulo de identicao do objeto e indo at o nal do diagrama ou, se for o caso, at sua remoo. Por sobre as linhas de vida podemos colocar o que chamamos de caixas de ativao, que denotam que o objeto tem o foco de controle, signicando que ele est executando algo diretamente ou delegando a algum outro objeto a execuo de algo. Caixas de ativao so opcionais pela UML. Sem elas, os diagramas cam mais fceis de desenhar a mo livre, mas a ausncia diculta a leitura do diagrama em situaes em que h mais de um o de execuo (paralelismo). Caixas de ativao podem se empilhar para especicar autodelegaes, que signicam que um objeto solicita a ele mesmo que execute algo. A Figura 9.5 ilustra os conceitos que foram apresentados considerando o ciclo de vida de um objeto. Na Figura 9.5 ilustramos as caixas de ativao, a passagem de mensagens de criao e de destruio de objetos e uma autodelegao (um objeto invoca uma operao de si mesmo). No necessrio, nesse momento, entender todos os aspectos da notao que constam da gura. Os detalhes cam para o prximo captulo. As linhas de vida podem se subdividir em duas ou mais linhas de vida para especicar situaes concorrentes ou alternativas, correspondendo a cenrios diferentes de um mesmo caso de uso. As linhas podem se unir novamente mais adiante no diagrama. Com isso, o diagrama pode car confuso, da a ideia de usar um diagrama para cada cenrio do caso de uso1 ou usar os recursos na notao que foram introduzidos na verso 2.0 da UML e de que tambm trataremos no prximo captulo.
Os diagramas de sequncia muito detalhados, especicando situaes alternativas (desvios e intercalaes) e paralelismo (separaes e junes) so usualmente muito complexos visualmente e, como consequncia, perdem boa parte da utilidade. Por essas razes, recomenda-se usar um diagrama para cada cenrio do caso de uso.
1

9.7. NVEL DE DETALHAMENTO DOS DIAGRAMAS DE SEQUNCIA

159

Tempo

<<create>>

umObjeto

Objeto exibido no topo da sua linha de vida

Linha de vida

Ciclo de vida

(caixa de) ativao

<<destroy>>

autodelegao com caixa de ativao empilhada

X
Destruio do objeto

Figura 9.5: O ciclo de vida de um objeto representado em um diagrama de sequncia.

9.7 Nvel de Detalhamento dos Diagramas de Sequncia

Um aspecto importante a ser considerado na elaborao de DSs a nalidade qual se prestaro: se para documentao, apenas, ou se para a gerao de cdigo. Essas duas nalidades so antagnicas com respeito ao nvel de detalhamento dos diagramas. Para a documentao, ou seja, para que sejam compreensveis por humanos, os DSs no devem ser complexos e, portanto, no devem ser detalhados. Para que se prestem gerao automatizada de cdigo, os DSs precisam ser detalhados e, portanto visualmente muito complexos, at para o pessoal que os elabora e os mantm. Por essa razo, os DSs so pouqussimo desenvolvidos para comporem documentos de anlise e mais frequentemente usados pelos projetistas, que elaboram DSs at certo nvel de detalhes e os entregam aos programadores, que geram o cdigo usando a engenharia direta e, da por diante, trabalham unicamente com o cdigo.

160

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

9.8 Resumo do Captulo

De forma anloga aos processos executados por indivduos em uma organizao, programas de computador desenvolvidos segundo o paradigma de orientao a objetos so concebidos com base na colaborao para a realizao das funes do sistema. Os diagramas de sequncia (DSs) permitem especicar colaboraes entre objetos, descrevendo a sequncia de mensagens passadas de objeto a objeto necessria para a realizao de uma funcionalidade em um sistema. Por enfatizar a interao entre objetos, os diagramas de sequncia compem um subconjunto importante dos diagramas da UML genericamente chamados de diagramas de interao. Os diagramas de sequncia tm grande importncia na fase de projeto de sistemas de software, pois so usados para atribuir responsabilidades aos objetos do sistema e para a descoberta de operaes das classes, incluindo os detalhes dos parmetros dessas operaes. possvel que cada instncia do caso de uso executada trilhe um caminho diferente, desde o incio do caso de uso at um dos possveis nais dele. Cada um desses caminhos diferentes caracteriza um cenrio. O principal cenrio corresponde ao que chamamos de curso tpico. O ciclo de vida de um objeto compreende tudo que acontece com ele durante o tempo decorrido entre sua instanciao e sua destruio. O ciclo de vida de um objeto persistente comea quando ele instanciado e armazenado em disco e s termina quando o pedido removido do banco de dados e no quando o objeto eliminado da memria para liberar espao para outro objeto. Objetos persistentes tm normalmente ciclo de vida maior do que objetos efmeros. As responsabilidades que atribumos a um objeto so realizadas pelas operaes que ele implementa e devem ser baseadas na capacidade desse objeto de cumpri-las. Essa capacidade , em primeira anlise, baseada nos atributos desse objeto, incluindo seus relacionamentos com os demais objetos, pois h situaes em que um objeto no possui os atributos necessrios para o cumprimento de determinada responsabilidade mas possui uma associao com um ou mais objetos que possuem esses atributos. Os DSs completam o trip da anlise, cujas outras "pernas" so os casos de uso com suas descries e os diagramas de classes. O processo de codicao de um sistema com orientao a objetos segue uma sequncia de passos que considera os cenrios dos casos de uso e as classes do diagrama de classes como "entradas" para esse processo. Diagramas de sequncia possuem duas dimenses: horizontal e vertical. Na

9.9. EXERCCIOS PROPOSTOS

161

dimenso horizontal relacionamos os objetos que participaro da colaborao que estamos modelando; na dimenso vertical, que representa o tempo, representamos, de forma ordenada com respeito ao tempo, as mensagens trocadas entre os objetos para que se d a colaborao entre eles. No prximo captulo prosseguiremos com o estudo dos diagramas de sequncia, tratando dos aspectos da notao grca e das tcnicas necessrias para a interpretao e elaborao dos DSs.

9.9 Exerccios Propostos

1. Especique, por meio das condies correspondentes aos desvios feitos ao longo dos uxos, os cenrios identicados no DA da Figura 8.1. 2. Dado o diagrama de classes da ZYX da Figura 9.6, enumere os passos da colaborao necessria para a impresso de um determinado pedido, incluindo os dados do cliente, a quantidade, as descries, os preos unitrios, os preos totais de cada item e o do pedido. Ao nal, relacione as responsabilidades de cada objeto envolvido na colaborao. Leve em considerao o seguinte aspecto: as navegabilidades das associaes que no foram indicadas so bidirecionais. Fique vontade para criar classes cujos objetos voc julgue necessrios para a tarefa. 3. Com base no que discutimos a respeito das dimenses horizontal e vertical dos DSs, esboce o diagrama de sequncia que especica a seguinte colaborao: Joo, presidente da ZYX, solicita a Paulo, diretor nanceiro, o valor do lucro lquido da Empresa. Paulo, por sua vez, desconhecedor dos valores das receitas e das despesas, solicita a Maria, gerente de faturamento, o valor das receitas. Aps receber o valor das receitas, Paulo solicita a Pedro, gerente de operaes, o valor das despesas. De posse desses dois valores, Paulo calcula o lucro lquido (diferena entre receitas e despesas) e o envia a Joo como resposta solicitao inicial. Imagine que Joo, Paulo, Maria e Pedro sejam objetos instanciados de suas respectivas classes e todos se encontram instanciados quando a colaborao se inicia. Use uma das convenes de nomes de objetos que mencionamos, atente para a ordem da passagem das mensagens, mas no se preocupe com a notao rigorosa da UML com relao s mensagens. Se voc usar um CASE para resolver o exerccio, tambm no se preocupe com as caixas de ativao. Seria ideal, no caso, se pudssemos desabilit-las, mas eu no conheo um CASE disponvel hoje em dia em que isso seja possvel.

162

CAPTULO 9. DIAGRAMAS DE SEQUNCIA: CONCEITOS BSICOS

singleton ColecaoDeClientes + pesquisaClientePorCodigo(int) : Cliente 1 * -

Cliente endereco telefone 1

* Produto codigo 1 descricao precoUnitario qtdEstoque * ItemDePedido ordem quantidade 1..* 1 Pedido numero enderecoEntrega tipoPagamento prezoEntrega

Figura 9.6: Trecho do diagrama da ZYX no nvel de especicao.

As solues encontram-se a partir da Pgina 222.

CAPTULO

10

D IAGRAMAS DE S EQUNCIA : M ENSAGENS , Q UADROS DE I NTERAO, C ONTROLADORES E I NTERFACES

Everything requires time. It is the only truly universal condition. All work takes place in time and uses up time. Yet most people take for granted this unique, irreplaceable, and necessary resource. Nothing else, perhaps, distinguishes effective executives as much as their tender loving care of time. Peter Drucker

Vimos no Captulo 9 que objetos colaboram para a realizao das funcionalidades do sistema que estamos construindo. Essa colaborao considera as responsabilidades atribudas a cada objeto e coordenada por uma sequncia programada de mensagens e aes que os objetos trocam entre si. Os diagramas de sequncia da UML ajudam a atribuir responsabilidades a objetos e permitem que especiquemos quais objetos participam das colaboraes e 163

164

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

quais so as sequncias de aes executadas e de mensagens passadas entre os objetos. Neste captulo prosseguiremos o estudo desses diagramas, tratando dos aspectos da notao grca e das tcnicas necessrias para a interpretao e elaborao dos DSs. O primeiro assunto a ser abordado diz respeito aos tipos de mensagens que podem ser passadas entre os objetos.

10.1 As Mensagens de Chamada

As chamadas correspondem invocao de alguma operao de um objeto feita por outro objeto ou, eventualmente, de um objeto por ele mesmo. As chamadas so representadas por setas com pontas fechadas que partem da linha de vida do objeto que envia a mensagem, solicitando a execuo de algo, para a linha de vida do objeto alvo, aquele que executa o que solicitado. As setas so rotuladas com, pelo menos, o nome da funo e os valores ou expresses de seus parmetros, ou seja, os dados necessrios para que o objeto invocado execute o que foi solicitado. Os rtulos podem conter tambm as condies em que as mensagens so enviadas, especicadas entre "[" e "]". As condies de guarda prexando as mensagens, embora tenham sido substitudas por quadros (frames) com rtulos opt ou alt (oriundos do ingls optional e alternative, respectivamente), ainda so amplamente usadas. Os quadros sero tratados mais adiante neste captulo. A Figura 10.1 ilustra a situao em que o objeto A solicita ao objeto B a execuo da operao op1 passando os parmetros p1 e p2. A operao op1 faz parte, portanto, do rol de operaes pblicas de B, pois o objeto A tem de "enxergar" e poder executar essa operao do objeto B, da a necessidade de a operao op1 ser pblica. Como j mencionamos, um objeto pode solicitar a si prprio a execuo de algo, o que caracteriza o que se chama autochamada ou autodelegao (o objeto delega a si prprio a execuo de algo). Suponhamos que, durante a execuo da operao op1 por B, este objeto precise executar a operao op2, que consta de seu rol de operaes, passando os parmetros p3 e p4. A Figura 10.2 ilustra essa situao. Repare que, nesse caso, a operao op2 no precisa ser pblica se nenhum outro objeto, alm de B, precisar execut-la. Na realidade, se esse for mesmo o caso, a operao op2, embora podendo ser pblica, dever ser tornada privada por questes de boa prtica (encapsulamento).

10.2. MENSAGENS DE CRIAO E DESTRUIO DE OBJETOS

165

op1(p1, p2)

Figura 10.1: Mensagem de chamada entre dois objetos.

op1(p1, p2)

op2(p3, p4)

Figura 10.2: Autodelegao da operao op2 pelo objeto B.

10.2 Mensagens de Criao e Destruio de Objetos

possvel representarmos a criao e a destruio de objetos, conforme voc ver a seguir. A criao (instanciao), que corresponde execuo do mtodo construtor do objeto, denotada por uma seta tracejada com a ponta aberta partindo da linha de vida do objeto que solicita a criao para o ponto onde se inicia a linha de vida do objeto que ser criado. Nesse ponto da dimenso vertical, que representa o incio do ciclo de vida do objeto sendo criado, coloca-se a caixa de identicao do objeto (o retngulo com o nome do objeto). A Figura 10.3 ilustra a situao em que um objeto A solicita a criao de um objeto B (em outras palavras, A executa o mtodo construtor do objeto B) que, por sua vez, solicita a criao do objeto C. H situaes em que objetos no so criados, sendo apenas "convocados" para

166

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

A

B create C create

Figura 10.3: Mensagens de solicitao de criao de objetos ilustrando as caixas de identicao dos objetos alinhadas com as mensagens.

destroy

Figura 10.4: Mensagens de solicitao de criao de objetos ilustrando as caixas de identicao dos objetos alinhadas com as mensagens.

colaborarem um caso de uso do sistema. Objetos que j existem quando o caso de uso se inicia tm seus identicadores (retngulos com seus nomes) colocados no topo do diagrama. Os que so criados ao longo do caso de uso tm seus identicadores colocados mais abaixo dos demais, conforme so criados (ver Figura 10.3). A destruio de um objeto pode ser comandada por outro objeto, por meio do envio de mensagem de destruio ( tambm uma seta tracejada de ponta aberta), ou seja, pela execuo do mtodo destrutor do objeto. A "morte" do objeto denotada por um "X" em negrito. Nesse ponto, a linha de vida do objeto se encerra, pois, em se tratando de objetos, no h vida aps a morte! A Figura 10.4 ilustra a situao em que o objeto A solicita a destruio do objeto B. Um objeto pode "sobreviver" execuo de um cenrio de um caso de uso, ou seja, no necessariamente precisa ser destrudo quando o caso de uso se encerra.

10.3. MENSAGENS DE RETORNO

167

Por exemplo, quando executamos com sucesso o caso de uso Cadastrar Cliente, esperado que os dados do novo cliente permaneam no cadastro aps o nal da execuo do caso de uso. Vale a pena comentarmos um erro, de certa forma comum, que os alunos cometem: terminar um diagrama de sequncia colocando sistematicamente um "X" no nal das linhas de vida de todos os objetos relacionados no diagrama, confundindo m de diagrama com m de linha de vida (destruio) de objeto. importante no confundir, no entanto, a destruio de um objeto persistente com a necessidade de o objeto que armazena seus dados na memria ser destrudo aps os dados serem enviados ao banco de dados para liberao do espao ocupado. Nesse ponto, vale a pena rever a Seo 9.3.

10.3 Mensagens de Retorno

Outro tipo de mensagem a de retorno da resposta de uma chamada, com consequente retorno do controle de execuo. Esta mensagem, alm de possivelmente retornar um valor para o objeto que fez a chamada, passa tambm o controle de volta a ele, pois a ao solicitada foi concluda pelo objeto chamado. As caixas de ativao do objeto chamado, quando representadas, se encerram com as mensagens de retorno. Uma mensagem de retorno representada por uma seta tracejada de ponta aberta que vai do objeto chamado para o objeto chamador, ou seja, no sentido oposto chamada. Ela pode ser rotulada com a informao retornada. Assim como as caixas de ativao, segundo a UML, as mensagens de retorno podem ser omitidas. Em chamadas sncronas (sem paralelismo, ou seja, quando o objeto que chama aguarda o m da execuo da operao pelo objeto chamado, conforme vimos tratando at agora em nosso texto), os retornos de controle podem ser facilmente inferidos por simples observao; alm disso, suas omisses tornam os diagramas visualmente mais simples. Veja o exemplo da Figura 10.5. Na Figura 10.5, o objeto A envia a mensagem m1 para o objeto B, que, nesse momento, ca ativado, passando a deter o controle de execuo. O objeto B, ento, envia a mensagem m2 ao objeto C, que a processa e, ao nal, retorna o controle de volta a B, que retorna o controle de volta ao objeto A. Sabemos disso porque A envia a mensagem m3 ao objeto B, s podendo fazer isso se tiver obtido o controle de volta (um objeto s envia uma mensagem se tiver o controle do processamento). B processa a mensagem m3 e retorna o controle de volta a A, que envia a mensagem m4 ao objeto C, que no nal retorna o controle para o objeto A. Releia a explicao que acabamos de dar. Se, mesmo relendo o texto que

168

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

A
m1

m2 m3 m4

Figura 10.5: Omisso das mensagens de retorno e das caixas de ativao, sem prejuzo de expressividade e de preciso.

A
m1

m2

m3

m4

Figura 10.6: Diagrama equivalente ao da Figura 10.5, agora com as mensagens de retorno representadas.

explica a Figura 10.5, ele ainda parecer confuso, tente rel-lo olhando para o diagrama ilustrado na Figura 10.6, que tem o mesmo signicado do diagrama da Figura 10.5 mas mostra as mensagens de retorno. Se agora adicionarmos as caixas de ativao na sequncia da Figura 10.6, a compreenso talvez se torne ainda mais fcil. Faremos isso conforme ilustra a Figura

10.4. CHAMADAS ASSNCRONAS

169

A
m1

m2

m3

m4

Figura 10.7: Diagrama equivalente aos das Figuras 10.6 e 10.5, agora com as caixas de ativao representadas alm das mensagens de retorno.

10.7, quem tem o mesmo signicado das Figuras 10.6 e 10.5. Repare na Figura 10.7: quando um objeto solicita algo a outro objeto, ele permanece ativo pelo tempo em que aguarda a execuo do que foi solicitado. A caixa de ativao termina no objeto chamado porque o controle volta ao objeto chamador. Quando j se tem alguma prtica, retornos e caixas de ativao no ajudam muito na interpretao dos diagramas quando estamos tratando de chamadas sncronas, que podem ser omitidos a bem da simplicidade visual. Caso estejamos lidando com concorrncia, enviando mensagens assncronas (com mltiplos os de execuo multithreading), os retornos e as caixas de ativao podem ser vitais para o entendimento correto de um diagrama. Trataremos de mensagens assncronas a seguir. O retorno de uma chamada sempre acontece para o objeto que fez a chamada, nunca para outro objeto.

10.4 Chamadas Assncronas

At ento tratamos de mensagens sncronas entre objetos em DSs; nessas chamadas, o objeto que chama espera pelo trmino do processamento da mensagem pelo objeto

170

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

Joo:Presidente Paulo:DiretorFinanceiro Maria:GerenteFaturamento Pedro:GerenteOperacoes

lucroLiquido()

receitas()

despesas()

aguardarResposta()

lucroLiquido()

Figura 10.8: Especicao de uma colaborao usando chamadas assncronas.

chamado. O fato que um objeto pode delegar a outro a execuo de algo utilizando tambm outro tipo de chamada: as mensagens assncronas. Nas chamadas assncronas, o objeto que chama no aguarda o trmino do processamento da mensagem pelo objeto chamado para poder fazer outra chamada a outro objeto ou, eventualmente, a si prprio. Em outras palavras: o controle mantido pelo objeto chamador, mas passado tambm ao objeto chamado. Isso d origem a outro o de execuo (thread, em ingls). Enquanto chamadas sncronas so representadas por setas slidas (no tracejadas) de pontas fechadas, as chamadas assncronas so representadas por setas slidas de pontas abertas. Retornando situao descrita no ltimo exerccio do Captulo 9, a soluo dada levou em considerao o enunciado da atividade risca, em que Paulo aguarda Maria informar o valor das receitas para s ento solicitar o valor das despesas a Pedro. Da o uso de chamadas sncronas. Isso, no entanto, no acontece na vida real em uma organizao em que tipicamente os processos ocorrem em paralelo. Paulo, o diretor nanceiro da ZYX, no precisa aguardar o valor das receitas, que solicitou Maria, para que possa pedir ao Pedro o valor das despesas. A Figura 10.8 ilustra a passagem das mensagens de forma assncrona. Nesse caso, Paulo delega a responsabilidade de calcular as receitas Maria e, sem esperar pela resposta, delega a responsabilidade de calcular as despesas a Pedro. Em seguida, podemos imaginar que Paulo ca no estado de "espera ocupada" (busy wait,

10.5. PARMETROS DAS CHAMADAS

171

em ingls), aguardando que Maria e Pedro reportem os valores das receitas e despesas para que ele ento possa calcular o valor do lucro lquido. Para tal, adicionamos a autodelegao de Paulo da ao de espera pelos resultados. Essa autodelegao sncrona porque Paulo precisa aguardar seu nal. A ao de espera pode ser entendida como a especicao do mecanismo de juno (diagramas de atividades) dos dois os de execuo disparados para clculo das receitas e das despesas. A autodelegao de clculo do lucro j estava na soluo dada para o exerccio.

10.5 Parmetros das Chamadas

As mensagens que um objeto passa a outro so, em grande geral1 , chamadas que ele faz s operaes pblicas do outro objeto. A assinatura de uma operao, alm de seu nome, consiste do tipo de retorno e dos parmetros. Estes precisam ser especicados nas chamadas representadas no DS (alm, claro, de nos compartimentos de operaes das classes, no modelo de classes de projeto). Os tipos de retorno e os parmetros das operaes, incluindo seus tipos, so especicados nas assinaturas das operaes e, portanto, nos rtulos das chamadas. Os rtulos das setas de chamadas cam, com isso, muito longos, o que torna os DSs ainda mais complexos visualmente. Com isso, durante a elaborao de um DS camos boa parte do tempo cuidando dos aspectos visuais do diagrama, aumentando ou diminuindo o espaamento entre as linhas de vida dos objetos em funo da extenso do rtulo das chamadas... Mas no h outro jeito. Quando tratamos de responsabilidades, atributos e operaes, mencionamos que, se designarmos algum para executar uma tarefa e tivermos de falar muito, explicando como fazer e dando muitos detalhes do que queremos que seja feito, isso uma possvel evidncia de que escolhemos a pessoa errada para fazer a tarefa. O "falar muito" e os "detalhes" a que nos referimos esto associados, no contexto de projeto de sistemas, ao nmero de chamadas e ao nmero de parmetros presentes em cada chamada. Em outras palavras: se as assinaturas das operaes so muito longas, voc deve pensar na possibilidade de estar escolhendo os objetos errados para colaborar.

Objetos podem se comunicar por meio de outros mecanismos, como lanamento e tratamento de interrupes, que no veremos nesse texto.

172

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

10.6 Quadros de Interao

Com os elementos da notao grca apresentados at aqui, voc tem condies de elaborar diagramas de sequncia prximos da realidade de desenvolvimento de sistemas de software. Mais recentemente, no entanto, a UML incorporou o conceito de quadros, adicionando recursos importantes que facilitam a especicao de colaboraes. Quadros de interao (frames, em ingls) denem uma ou mais regies de um diagrama de sequncia da UML onde representamos iteraes (as repeties, laos ou loops), trechos concorrentes, trechos opcionais ou trechos alternativos de colaboraes, dentre outros. Quadros de interao foram introduzidos na UML na verso 2.0 e simplicaram bastante a especicao de repeties, condies (desvios) e concorrncia, tornando os diagramas mais expressivos. Com isso, DSs podem car mais completos, pois diminui a necessidade de representar um nmero menor de cenrios por diagrama (voc se lembra da recomendao que demos, de representar apenas um cenrio por diagrama?). Os quadros so rotulados com nomes de operadores, colocados no pequeno compartimento acima e esquerda no quadro. As regies que compem os quadros, quando existe mais de uma, chamam-se fragmentos. A Tabela 10.1 relaciona os operadores comumente usados em quadros de interao. Se quisermos, por exemplo, representar que as mensagens em determinado trecho de uma colaborao sejam repetidas um certo nmero de vezes, envolvemos (emolduramos) o conjunto de mensagens por um quadro loop, conforme ilustrado na Figura 10.9. Nesse caso, a chamada m1 e a autodelegao m2 so repetidas n vezes. Caso queiramos especicar uma condio, usamos quadros opt para uma nica condio (um nico fragmento), ou alt para mltiplas condies alternativas (mais de um fragmento), conforme a necessidade. A Figura 10.10 ilustra a situao em que a chamada m1 feita se a condio c1 for verdadeira. A Figura 10.11 ilustra a situao em que, caso a condio c1 seja verdadeira, a chamada m1 enviada; caso contrrio, a chamada m2 enviada. Voc pode notar que a condio que controla o nmero de vezes que a colaborao que est no interior do quadro executada (Figura 10.9) e as condies que especicam a colaborao opcional e as colaboraes alternativas (Figuras 10.10 e 10.11, respectivamente) so colocadas entre "[" e "]". Os quadros so contineres da UML. Sendo assim, a partir do momento em

10.6. QUADROS DE INTERAO

173

loop [tantas vezes/para todos/etc] m1()

m2()

Figura 10.9: Quadro loop para especicar repeties.

opt [c1] m1()

Figura 10.10: Colaborao opcional especicada por um quadro opt.

174

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES Tabela 10.1: Operadores comumente usados em quadros de interao. Operador Signicado Especica mltiplos fragmentos alternativos em um quadro. A condio em que um fragmento executado colocada no topo do fragmento entre colchetes. Os fragmentos do quadro so separados por linhas tracejadas, com as condies em que so executados em seus topos entre colchetes. Especica um quadro executado opcionalmente. O quadro corresponde a um nico fragmento. A condio em que o fragmento executado colocada no topo do quadro, entre colchetes. Especica mltiplos fragmentos executados concorrentemente. Especica um quadro (um nico fragmento) executado iterativamente. Especica um rtulo para um quadro, que pode ser referenciado em outro lugar ou em outro diagrama, como uma chamada. De "sequence diagram", que opcionalmente rotula um quadro que contm totalmente um diagrama de sequncia.

alt

opt

par loop ref

sd

que se coloca um trecho de colaborao dentro dele, todo o trecho est logicamente associado ao quadro. Sendo assim, se eliminamos o quadro do diagrama, toda a colaborao que ele contm eliminada do modelo; se movemos o quadro, toda a colaborao em seu interior se move junto, e assim por diante. Isso o que se espera que acontea no CASE, mas, obviamente, depender de como e se a ferramenta implementa o conceito de quadros conforme especica a UML. A notao usando quadros tem vantagens e desvantagens em relao verso anterior da UML, usando guardas, que relacionamos a seguir: os quadros agregam complexidade visual ao modelo; os quadros proveem maior expressividade ao modelar blocos aninhados correspondendo a iteraes e condicionalidades; o uso de guardas resulta em menor complexidade visual, embora os rtulos das mensagens quem mais extensos; o uso de guardas prov menor expressividade ao modelar blocos aninhados correspondendo a iteraes e condicionalidades.

10.7. FALANDO UM POUCO MAIS SOBRE A CRIAO DE OBJETOS

175

alt [c1] m1()

[else] m2()

Figura 10.11: Colaboraes alternativas especicadas por um quadro alt.

O uso de uma ou de outra notao (desconsiderando-se que as mensagens com guardas no fazem mais parte da notao da UML, apesar de ainda muito usadas) depende da situao, cando a critrio do time de modelagem.

10.7 Falando Um Pouco Mais Sobre a Criao de Objetos

Uma pergunta que frequentemente me fazem diz respeito a quando criar os objetos em uma colaborao. A resposta que costumo dar : "o mais tarde possvel". Vou justicar minha resposta usando novamente como ilustrao a instanciao de um novo cliente (cadastramento) pelo caso de uso Cadastrar Cliente. Nesse caso, a pergunta : quando instanciar o objeto cliente durante a realizao do caso de uso para armazenar os dados coletados do formulrio de cadastramento? A razo para instanciarmos o objeto cliente o mais tarde possvel na colaborao bem simples: diminuir a probabilidade de termos de destruir o objeto, caso encerremos o caso de uso em uma situao de insucesso. Criar e destruir objetos provoca o que se chama fragmentao da memria, que torna a resposta do sistema mais demorada, pode

176

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

provocar falha na criao de novos objetos e pode "despertar" o processo coletor de lixo. Esse processo rearruma o espao livre da memria, reagrupando os fragmentos livres de memria como se fosse uma "arrumao" de casa. Certamente isso leva tempo, demanda CPU e deixa o computador mais lento para o usurio.

10.8 Objetos Controladores

Muitos projetistas optam por atribuir a um conjunto reduzido de objetos as responsabilidades de controlar o uxo de mensagens e/ou de zelar pela obedincia s regras de negcio. Esses objetos so instanciados de classes concebidas exclusivamente para isso, no fazendo parte do conceito; so, portanto, classes de projeto. H inclusive projetistas que retiram quase todas as responsabilidades das classes conceituais, deixando para elas a atribuio exclusiva de armazenar os atributos e prover as operaes get/set (as de obteno e de denio dos atributos das classes, respectivamente). Essas classes recebem o nome de classes controladoras. O objetivo de criarmos classes assim o de concentrarmos a lgica da aplicao em poucas classes, facilitando com isso a manuteno do sistema. Eu, particularmente, acho suciente criar uma classe controladora por caso de uso para a maioria dos casos de uso. Quem opta pelo uso de classes controladoras desenvolve diagramas de sequncia em que as mensagens partem exclusivamente desses objetos para si prprios (autodelegaes) ou, na quase totalidade das demais mensagens, usando mensagens de get/set endereadas aos objetos de classes conceituais. As classes controladoras e seus relacionamentos devem constar do diagrama de classes de projeto.

10.9 Objetos de Interface

Outros objetos muito frequentemente usados so os objetos de interface. As interfaces usualmente proveem meios de comunicao entre ambientes distintos, como, por exemplo, entre dois sistemas, entre dois subsistemas, entre duas tecnologias diferentes e, em muitos casos, entre os usurios e os sistemas. Neste caso se enquadram os formulrios (as telas), sejam eles as telas das aplicaes web (os navegadores ou browsers) ou das aplicaes desktop (formulrios Visual Basic, Delphi etc.). As telas so instanciadas quando o caso de uso se inicia, exibindo os campos

10.9. OBJETOS DE INTERFACE

177

de entrada e sada de dados e os demais controles, como botes, barras de rolagem etc. Elas so instncias de suas respectivas classes (um formulrio VB instanciado da classe Form do VB, por exemplo). Os formulrios proveem, portanto, a nica via de acesso possvel do usurio aos objetos do sistema. Normalmente representamos nos DS os atores de um lado do formulrio e os objetos do sistema do outro. Entre os atores e os formulrios so trocadas mensagens que representam os eventos externos, disparados pelos atores, e as respostas do sistema a esses eventos. Essas mensagens e respostas devem corresponder aos passos contidos nas especicaes dos casos de uso. Usualmente, do outro lado do objeto formulrio colocam-se os objetos instanciados das classes controladoras, em uma posio mais prxima), das classes conceituais e das demais classes de projeto. Objetos formulrios podem instanciar outros objetos formulrios (as telas popups, por exemplo) durante uma colaborao (uma interao) com o usurio. No boa prtica, no entanto, colocar regras de negcio e atribuir responsabilidade de controle de interao aos formulrios. Costumo dizer que os formulrios devem ser "burros", e que a "inteligncia" do sistema deve car a cargo dos objetos controladores e dos objetos das classes conceituais (muitos projetistas diriam "quando muito" nesse ponto, porque at as classes conceituais muitos optam por mant-las "burras"). Por essa razo, assim que um formulrio recebe o controle (o usurio pressiona o boto "Ok", por exemplo), deve pass-lo, o mais rapidamente possvel, para o objeto controlador que est ao seu lado no DS. Objetos de interface so bastante usados para diminuir o acoplamento entre duas partes distintas de um sistema, provendo com isso maior manutenibilidade (capacidade ou facilidade de sofrer manuteno) a ambos os sistemas. Assim com as classes controladoras, as classes de interface e seus relacionamentos devem constar do diagrama de classes de projeto. Desenvolver DSs complexos considerado trabalho jogado fora por muitos projetistas. Por essa razo, o procedimento usado por muitos deles iniciar a realizao dos casos de uso especicando a interao em mais alto nvel usando diagramas de sequncia. Em seguida, geram um "cdigo inicial" utilizando os recursos de engenharia direta disponvel na ferramenta CASE. A partir da, deixam a cargo dos experientes construtores do sistema (se no fazem, eles mesmos, a construo) a codicao " mo" do restante do sistema. Eventualmente, quando o sistema est pronto e testado, eles promovem a engenharia reversa do cdigo para a recomposio/complementao do diagrama de classes.

178

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

10.10 Resumo do Captulo

Os objetos colaboram para a realizao das funcionalidades do sistema que estamos construindo. Essa colaborao coordenada por uma sequncia programada de aes e mensagens que os objetos trocam entre si. Esses so os programas. Os diagramas de sequncia permitem especicar quais objetos participam das colaboraes e quais so as sequncias de aes executadas e de mensagens passadas entre os objetos. As mensagens trocadas entre os objetos so dos tipos chamadas sncronas e assncronas, de criao e de destruio de objetos e mensagens retorno. As chamadas correspondem invocao de alguma operao de um objeto feita por outro objeto ou, eventualmente, de um objeto por ele mesmo e so representadas por setas com pontas fechadas que partem do objeto que solicita a execuo de algo e chegam ao que executa o que solicitado. possvel representar a criao e a destruio de objetos. A instanciao corresponde execuo do mtodo construtor do objeto chamado e denotada por uma seta tracejada com a ponta aberta. A destruio de um objeto pode ser comandada por outro objeto, que chama seu mtodo destrutor. A mensagem de destruio representada igualmente por uma seta tracejada de ponta aberta. Nesse ponto, a linha de vida do objeto destrudo se encerra, pois, em se tratando de objetos, no h vida aps a morte! Outro tipo de mensagem a de retorno da resposta de uma chamada, com consequente retorno do controle de execuo. Mensagens de retorno so representadas por setas tracejadas de ponta aberta, no sentido oposto chamada. O retorno de uma chamada sempre acontece para o objeto que fez a chamada, nunca para outro objeto qualquer. As chamadas podem ser sncronas e assncronas. Nas chamadas sncronas, o objeto que chama espera pelo trmino do processamento da mensagem pelo objeto chamado. Nas assncronas, o objeto que chama no aguarda o trmino do processamento da mensagem para poder fazer outra chamada a outro objeto, dando origem a mltiplas ativaes (mltiplos os de execuo). Chamadas sncronas so representadas por setas slidas (no tracejadas) de pontas fechadas, enquanto chamadas assncronas so representadas por setas slidas de pontas abertas. As chamadas podem passar parmetros aos objetos chamados, que so especicados nas assinaturas das operaes. Os quadros de interao denem uma ou mais regies de um DS onde representamos iteraes (as repeties, laos ou loops), trechos concorrentes, trechos opcionais ou trechos alternativos de colaboraes, dentre outros, simplicando bastante suas representaes em relao s formas adotadas nas verses da UML anteriores verso 2.0. A notao usando quadros tem

10.11. EXERCCIOS PROPOSTOS

179

vantagens e desvantagens em relao verso anterior da UML, usando guardas. O uso de uma ou de outra notao, desconsiderando que as mensagens com guardas no fazem mais parte da notao da UML (apesar de ainda muito usadas), depende da situao, cando a critrio do time de modelagem. Muitos projetistas optam por atribuir a um conjunto reduzido de objetos as responsabilidades de controlar o uxo de mensagens e/ou de zelar pela obedincia s regras de negcio. Esses objetos "de projeto" so instncias de classes que recebem o nome de classes controladoras. O objetivo de criar classes assim concentrar a lgica da aplicao em poucas classes, facilitando com isso a manuteno do sistema. Objetos de interface proveem meios de comunicao entre ambientes distintos, como , por exemplo, entre dois sistemas, entre dois subsistemas, entre duas tecnologias diferentes e, em muitos casos, entre os usurios e os sistemas. Objetos de interface so bastante usados para diminuir o acoplamento entre duas partes distintas de um sistema, provendo, com isso, maior manutenibilidade. Num tipo especial de objetos de interface se enquadram as telas das aplicaes web ou os formulrios das aplicaes desktop que proveem a nica via de acesso possvel do usurio aos objetos do sistema. Os formulrios devem ser "burros", e a "inteligncia" do sistema deve car a cargo dos objetos controladores e dos objetos das classes conceituais.

10.11 Exerccios Propostos

1. Retornando empresa ZYX. Quando um pedido colocado diretamente por um cliente que usa o stio da ZYX na Internet, ele especica os itens que compem o pedido, colocando-os no "carrinho de compras". possvel que o cliente adicione no carrinho itens que no esto disponveis no estoque no momento do pedido, at porque a ZYX pode querer no trabalhar com determinados itens em estoque. Isso certamente atrasar a entrega do pedido pelo prazo demandado para a entrega do produto ZYX pelo fornecedor. Podemos assumir que o prazo e o preo de fornecimento so atributos do relacionamento entre produto e fornecedor do produto. O diagrama de classes a ser considerado o ilustrado na Figura 10.12, que o apresentado na Figura 5.2 com a adio da classe de associao Fornecimento para acomodar os atributos e as operaes relativas ao fornecimento de produtos ZYX. Repare na Figura 10.12 que um mesmo produto pode ter qualquer nmero de fornecedores, mas as condies de fornecimento de um produto por um determinado fornecedor so nicas.

180

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES

PedidoDeReposicaoDeEstoque dataColocacao -

Pedido numero enderecoEntrega * tipoPagamento prazoEntrega 1 1 -

Cliente endereco telefone

1..* ItemDeReposicaoDeEstoque ordem quantidade * -

1..* ItemDePedido ordem quantidade * ClientePF nome ClientePJ razaoSocial contato *

1 Produto -

1 +Representante de Vendas 0..1 Fornecedor * -

codigp descricao * precoUnitario qtdEstoque

Funcionario nome

Fornecimento prazoFornecimento precoFornecimento

Figura 10.12: fornecimento.

Diagrama de classes da ZYX contemplando prazo e preo de

Especique a colaborao necessria para obter o prazo de entrega de um determinado item, supondo que no h quantidade suciente em estoque e que o prazo o do primeiro da lista dos fornecedores para o mesmo produto. Represente as operaes e seus parmetros, assim como as visibilidades das operaes. 2. Estendendo o trecho do descrito no Exerccio 1, vamos especicar, agora, as seguintes situaes: o produto se encontra no estoque. Nesse caso, o prazo de fornecimento zero e comandada a retirada da quantidade demandada do estoque; ou precisamos localizar o fornecimento com o menor preo para a situao em que o produto no se encontra em estoque. O prazo de fornecimento o valor do atributo prazoFornecimento da classe Fornecimento para o referido fornecedor.

10.11. EXERCCIOS PROPOSTOS Tabela 10.2: Tabela de descrio parcial do caso de uso Efetuar Pedido.
Caso de Uso: Propsito: Descrio geral:

181

Efetuar Pedido Registrar pedidos feitos por cliente da ZYX via web. Os clientes da ZYX que se autenticam no sistema podem efetuar seus pedidos diretamente pela internet colocando no carrinho de compras que representa o pedido os itens que deseja comprar e pagando com carto de crdito. Atores: Cliente, operadora de carto de crdito. Pr-condies: Cliente possui login e senha de acesso no sistema. Ps-condies: Caso sucesso: pedido e seus itens registrados no sistema. Curso Tpico (CT) 1. Sistema exibe os campos para autenticao do cliente e o boto Ok; 2. Cliente fornece login e senha e pressiona o boto Ok; 3. Sistema autentica cliente, obtm seu nome e endereo e os exibe no topo do formulrio; 4. Para todos os itens que compem o pedido do cliente: a. Sistema exibe os campos para fornecimento do cdigo do produto, a quantidade desejada e os botes Adicionar ao carrinho de compras e Finalizar pedido; b. Cliente fornece o cdigo do item, quantidade e clica no boto Adicionar ao carrinho de compras; c. Sistema busca a descrio do produto e o preo unitrio; d. Sistema exibe a descrio do produto, o preo unitrio, calcula o preo total do item e o exibe; e. Sistema atualiza o valor total do pedido; 5. ... Cursos Alternativos (CA) CA 1: Passo 3 do CT Sistema no autentica cliente 1. Sistema informa que login/senha no constam do cadastro. ** Fim do Caso de Uso **

3. Desenvolva o DS para os passos do caso de uso Efetuar Pedido especicados na Tabela 10.2. Considere que no diagrama de classes do Exerccio 1 adicionamos a classe ColecaoDeClientes associada classe Cliente para a indexao de clientes, conforme vimos no Captulo 9. Use um objeto controlador para controlar os passos da interao e um ou mais objetos de interface para representar formulrios. Voc poder adicionar outras classes que eventualmente julgar necessrias ao diagrama.

182

CAPTULO 10. DIAGRAMAS DE SEQUNCIA: MENSAGENS, QUADROS DE INTERAO, CONTROLADORES E INTERFACES As solues encontram-se a partir da Pgina 226.

CAPTULO

11
Tom Cruise

D IAGRAMAS C OMPLEMENTARES
Nothing ends nicely, thats why it ends.

Dos treze diagramas ociais da UML, at aqui apresentamos os cinco mais usados em modelagem de sistemas de software. Existem, no entanto, outros quatro diagramas que podem ajudar bastante na especicao de determinados aspectos das dimenses temporal e estrutural do sistema e na organizao dos modelos. Neste captulo apresentaremos os principais conceitos e a notao grca dos diagramas de viso geral da interao, de pacotes, de componentes e de instalao. natural que voc estranhe o fato de apresentarmos quatro diagramas em um nico captulo, quando precisamos de oito captulos para apresentar cinco diagramas. Isso s possvel por duas razes que podem ocorrer concomitantemente, dependendo do diagrama:

1. os conceitos so simples; 2. os conceitos j foram vistos nos outros diagramas e se combinam, de alguma forma, nesses quatros, ou seja, os diagramas a serem apresentados compartilham os conceitos associados aos demais diagramas de que j tratamos. 183

184

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

Trataremos inicialmente dos diagramas de viso geral da interao, que podem ser entendidos como combinaes entre diagramas de atividade e de sequncia, conforme veremos a seguir.

11.1 Diagramas de Viso Geral da Interao

Como j tratamos de diagramas de atividades e de diagramas de sequncia, podemos denir, de forma bastante satisfatria, diagramas de viso geral da interao como sendo uma combinao entre esses dois. Essa combinao se d pela colocao de quadros de interao dos diagramas de sequncia nos lugares das caixas de aes dos diagramas de atividades. Um diagrama de viso geral da interao tambm pode ser visto como sendo uma fragmentao de diagramas de sequncia, com esses fragmentos de mais baixo nvel (as pequenas colaboraes entre objetos contidas em quadros de interao) "costurados" com o uso dos elementos que compem a viso de mais alto nvel da estrutura de controle (uxos, decises, intercalaes, separaes e junes) dos DAs. Os diagramas de viso geral da interao usam interaes (quadros com trechos de diagramas de interao) e/ou ocorrncias de interaes, ou seja, referncias para outros quadros com trechos de diagramas de interao dispostas segundo uma estrutura de controle de mais alto nvel. Eles servem, portanto, para detalhar, em um s diagrama, os passos da colaborao entre objetos necessrios para a realizao de cada ao de uma atividade. Vamos ilustrar o que acabamos de expor imaginando que temos uma determinada atividade especicada pelo DA da Figura 11.1. Caso queiramos especicar como cada ao da atividade da Figura 11.1 realizada por meio de colaboraes entre objetos, desenvolvemos um diagrama de viso geral da interao, que pode ter a forma do diagrama ilustrado na Figura 11.2. Note que, por um lado, podemos entender que o diagrama da Figura 11.2 um renamento do diagrama da Figura 11.1. Por outro, podemos ver o diagrama da Figura 11.2 como sendo uma fragmentao do diagrama de sequncia necessrio para especicar todos os cenrios de uma atividade com vrios quadros de interao colocados da sequncia apropriada com o uso dos elementos de controle de uxo dos DAs. Podemos usar todos os elementos grcos dos DAs, incluindo os de controle do uxo, como decises (j vistas nas Figuras 11.1 e 11.2), separaes, junes etc., nos diagramas de viso geral da interao. Embora estes diagramas sejam bastante recentes (passaram a fazer parte da

11.1. DIAGRAMAS DE VISO GERAL DA INTERAO

185

[c1] [c2]

[c3]

[c4]

[c5]

Figura 11.1: Diagrama de atividade especicando uma atividade hipottica.

especicao da UML apenas em sua verso 2.0), j podemos antever suas aplicaes em projetos de software que usam gerao de cdigo com base nos modelos UML, em que apenas a utilizao de diagramas de sequncia invivel, em funo da complexidade visual resultante ao se modelar mais de um cenrio em um mesmo DS. Tambm por serem recentes, pode no haver suporte grco completo para esses diagramas pelo CASE que voc usa. Mas isso no um problema srio, na medida em que voc pode construir um DS para cada ao do DA sendo detalhada. Alis, essa uma opo quando o diagrama de viso geral da interao adquire uma complexidade visual que o impede de caber em uma pgina. A outra opo, lembre-se, o uso de conectores dos DAs. A recomendao que deixamos procurar tornar as aes to simples quanto

186

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

sd a

a1

a2

[c1]

[c3]

[c2] sd b sd c
b1 b2 b3 d1 d2 d3

sd d

c1

c2

[c5]

[c4] sd e sd f

sd g

e1

e2

e3

f1

g1

g2

loop

Figura 11.2: Diagrama de viso geral da interao, especicando as colaboraes necessrias para a realizao das aes do DA da Figura 11.1.

11.2. DIAGRAMAS DE PACOTES

187

for possvel, atmicas (indivisveis) de preferncia, objetivando obter quadros de interao visualmente simples.

11.2 Diagramas de Pacotes

Pacotes so contineres usados para agrupar certos elementos da notao, provendo um espao de nomes para os elementos agrupados e permitindo que organizemos o modelo, dividindo-o em partes relacionadas entre si para sua melhor visualizao e compreenso. Pacotes tm a forma grca de uma pasta suspensa, ou seja, um retngulo com sua etiqueta em um dos cantos. O nome do pacote usualmente colocado no centro do retngulo, no topo ou dentro da etiqueta. Dentro do espao de nome, os nomes dos elementos grcos (nomes das classes, dos atores etc.) tm de ser distintos, pois precisam identicar univocamente os elementos a que se referem dentro desse espao. Apenas elementos empacotveis de um modelo podem ser agrupados em pacotes nesse modelo. A denio de elemento empacotvel que consta na UML, acreditem, : "elementos empacotveis so elementos que possuem nomes e que podem ser empacotados". Os elementos mais comumente agrupados com o uso de pacotes so classes, atores, casos de uso e outros pacotes. Pacotes contendo outros pacotes permitem formarmos hierarquias de pacotes. Como dissemos, o uso de pacotes facilita a organizao e a compreenso de um modelo, agrupando os elementos dos diagramas conforme suas anidades semnticas e tornando os diagramas menos complexos. Podemos, por exemplo, organizar os atores de um sistema em pacotes. Um pacote poderia ser o de atores administradores do sistema, ou seja, aqueles atores que exercem funes de administrao dos usurios, de fornecimento de parmetros de execuo do sistema em cada uma das suas reas de utilizao dentro da organizao. Outro pacote poderia ser o de gerentes, que tipicamente usam o sistema para a realizao de consultas, extrao de relatrios, para dar prosseguimento a processos que demandam decises importantes etc. A Figura 11.3 ilustra essa situao. Podemos, ainda, organizar os casos de uso por subsistemas, incluindo no pacote Finanas os casos de uso relacionados ao subsistema de nanas, no pacote RH os casos de uso relacionados ao subsistema de gesto de pessoal etc. Agrupar elementos em pacotes feito nos CASEs usualmente de duas formas:

188

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

Atores Administradores

Atores Gerentes

:Administrador de Configurao

:Administrador de Usurios

:Gerente Financeiro

:Gerente de Pessoal

:Gerente de Vendas

:Gerente Geral

Figura 11.3: Uso de pacotes na organizao dos atores de um sistema.

1. instanciar o pacote no formulrio e arrastar o elemento para dentro do pacote instanciado, caso o elemento j exista; ou 2. instanciar o elemento no formulrio j dentro do pacote.

esperado que, ao mover ou deletar um pacote, todos os elementos em seu interior se movam ou sejam deletados, respectivamente. Retirar um elemento de dentro do pacote usualmente feito arrastando-se o elemento para fora do pacote. Aps agrupar os elementos em pacotes e, possivelmente, organizar os pacotes segundo hierarquias, sempre interessante ilustrar essa organizao em um ou mais diagramas de pacotes que, colocados na documentao idealmente antes dos demais diagramas, mostram os pacotes e seus relacionamentos de dependncia (relacionamentos de uso). A Figura 11.4 ilustra um diagrama de pacotes representando, alm dos dois pacotes, um relacionamento de dependncia mtua entre eles. Um relacionamento de dependncia (seta tracejada de ponta aberta) lido na direo da seta como "usa" ou "depende de". O diagrama de pacotes da gura poderia representar, por exemplo, a situao em que classes de conceito contidas no pacote Pagamentos esto associadas com classes de conceito contidas no pacote Finanas e h navegabilidades e chamadas de operaes em ambos os sentidos. Como vimos no nal do Captulo 10, com o intuito de diminuir o acoplamento entre os pacotes, os acessos a recursos de outros pacotes so usualmente feitos atravs de classes de interface. Isso aumenta a manutenibilidade de cada subsistema

11.3. DIAGRAMAS DE COMPONENTES

189

Pagamentos

Finanas

Figura 11.4: Dependncia entre pacotes em um diagrama de pacotes.

e, com isso, do sistema como um todo. Sendo assim, podemos representar os relacionamentos da Figura 11.4 de forma alternativa, como ilustrado na Figura 11.5. comum os projetistas inclurem cada classe de interface em seu respectivo pacote. Com isso, a classe AcessoFinancas faria parte do pacote Finanas e a classe AcessoPagamentos faria parte do pacote Pagamentos. Outra prtica menos frequente, por conta de caractersticas de algumas linguagens, criar-se um pacote (por exemplo Interfaces) para agrupar todas as classes de interface de um sistema.

11.3 Diagramas de Componentes

Ao contrrio de um pacote, que de forma geral corresponde a um agrupamento lgico de elementos do modelo, um componente corresponde a um agrupamento fsico de elementos do modelo que prov um conjunto de funcionalidades. Assim sendo, componentes so tambm contineres. Os componentes em um sistema tm a ver com como projetamos e implementamos o sistema, ou seja, com a arquitetura do sistema. Os diagramas de componentes mostram a estrutura do modelo de implementao, sendo atemporal, portanto. Um diagrama de componentes apresentado como um conjunto de smbolos que representam os componentes, conectados entre si por meio de relacionamentos de dependncia e comumente usando classes de interface para intermediar a comunicao entre os componentes. Um componente pode corresponder a um subsistema ou a qualquer outra poro reutilizvel de um sistema, "mostrando" apenas o que relevante do ponto de vista do restante do sistema e encapsulando o resto. Por sinal, a possibilidade de reutilizao de pores de um sistema em muitos casos orienta a componentizao desse sistema, ou seja, seu desenvolvimento por

190

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

interface AcessoFinancas

Pagamentos

Finanas

interface AcessoPagamentos

Figura 11.5: Dependncia entre pacotes realizada atravs de classes de interface.

blocos internamente coesos e interconectados entre si (a chamada orientao a componentes). As bibliotecas de vnculos dinmicos do Windows DLLs so exemplos de componentes para os quais especicamos as interfaces de uso e os conjuntos de funcionalidades. Para tal, em cada DLL temos um conjunto de classes que colaboram para a realizao das responsabilidades da DLL. Em termos de aplicao, exemplos de componentes comumente construdos nas organizaes so: componentes para autenticao de usurios; componentes para tratamento de datas, de cadeias de caracteres e outras utilidades; componentes para manipulao de dados de clientes;

11.3. DIAGRAMAS DE COMPONENTES

191

ControleClientes

AutenticacaoUsuario

Figura 11.6: Notao grca de componentes, ilustrando as interfaces fornecida (pelo componente AutenticacaoUsuario) e exigida (pelo componente ControleClientes.

componentes para manipulao de ordens de servio; componentes para manipulao de faturas. Componentes so utilizados para, basicamente: dividir o sistema em mdulos; facilitar seus resos em outros sistemas; aumentar a manutenibilidade dos sistemas. Um diagrama de componentes da UML deve especicar a organizao das classes em agrupamentos fsicos, podendo corresponder aos pacotes conforme foram logicamente organizadas. A notao estabelecida pela UML 2.0 para os componentes em um diagrama de componentes ilustrada na Figura 11.6. As classes que compem cada componente, e eventualmente outros componentes, podem ser representadas no interior do componente. A Figura 11.6 ilustra a comunicao entre componentes feita por meio de interfaces fornecida e exigida, ou seja, a interface que o componente prov (pequeno crculo aberto) e a interface que o outro componente usa (pequeno semicrculo externo ao da interface fornecida). Relacionamentos de dependncia nesses casos podem ser substitudos por interfaces fornecidas e exigidas conforme a Figura 11.7. Isso devido ao fato de que o "pirulito" ( esse mesmo o nome que usualmente damos) representa a interface

192

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

se transforma em

Component1

Component2

Figura 11.7: Transformao de relacionamentos de dependncia em notao de interfaces fornecidas e exigidas.

fornecida portanto, a usada; o semicrculo representa a interface exigida portanto, a que usa. A orientao a componentes envolve a adoo de polticas especcas em uma organizao, compreendendo inclusive a possibilidade de compra dos deles no mercado para agilizar o desenvolvimento de sistemas.

11.4 Diagramas de Instalao

Sistemas distribudos so, por denio, aqueles que possuem arquitetura composta de partes de software que so processadas em ns de processamento distintos, eventualmente sicamente distantes entre si. Para esses sistemas tambm necessitamos representar que partes do software processam em que partes do hardware e quais so os mecanismos de comunicao entre essas partes. Essa informao colocada sob a forma de um ou mais diagramas de instalao da UML, usualmente em um documento do sistema chamado de Documento de Arquitetura. Um diagrama de instalao consiste de um conjunto de caixas paralelepipdicas ligadas por associaes de comunicao. As caixas representam os ns de processamento, e as associaes usualmente indicam o protocolo usado para a comunicao. Os ns podem conter as representaes dos componentes contidos neles, conforme o sistema foi/ser implementado. As caixas representando os ns so, portanto, outros contineres da UML. A Figura 11.8 ilustra a representao da arquitetura de um sistema clienteservidor em que o n cliente se comunica com o n servidor usando o protocolo HTTP. A Figura 11.8 pode sugerir que diagramas de instalao so triviais. No entanto, em sistemas concebidos segundo arquiteturas complexas e pouco usuais (por exemplo, sistemas compostos de vrias tecnologias distintas e sistemas integrando outros sistemas legados que demandam componentes de mediao entre eles), o

11.5. PALAVRAS-CHAVE

193

Cliente http

Serv idor

Figura 11.8: Sistema cliente-servidor com comunicao por HTTP.

diagrama pode ser bastante complexo. Nesses casos, diagramas de instalao podem ser bastante teis para a compreenso do conjunto.

11.5 Palavras-Chave
Existe, ainda, um pequeno porm importante detalhe na notao que usamos ao longo de todo o texto, mas do qual no tratamos em nenhuma seo especicamente: as palavras-chave da UML. A UML fornece uma notao grca para elementos estruturais (classes, casos de uso etc.), elementos comportamentais (interaes e mquinas de estados), de agrupamento (pacotes, quadros), itens anotacionais (notas/comentrios) e os blocos relacionais bsicos (relacionamentos diversos), dentre outros. Embora esse conjunto de elementos grcos da notao seja grande, de se esperar que a notao no atenda adequadamente a todas as necessidades de modelagem nos diversos domnios (modelagem de sistemas, modelagem de negcios etc.), sem que isso implique o crescimento sem-m desse conjunto. Isso se d pelo fato de esses elementos terem suas semnticas precisamente denidas, com funes especcas dentro dos grupos relacionados anteriormente. Qualquer necessidade de pequena exibilizao no signicado de um smbolo impediria seu uso e, em consequncia, o uso da linguagem. Com isso em mente, o OMG deniu de antemo algo que pode ser entendido como um mecanismo de extenso da UML: as palavras-chave (keywords, em ingls). Uma palavra-chave usada quando, na construo de um modelo, se necessita de um elemento estrutural, comportamental, de agrupamento, anotacional ou de

194

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

relacionamento que no existe na UML mas que semelhante a algo que j existe. Podemos pensar em palavras-chave como subtipos (especializaes) que criamos ou que algum j criou e estamos reusando para os tipos classe, associao, generalizao etc. da UML. Com isso, podemos estender a semntica de um elemento da notao usando, no modelo, o elemento bsico da UML que melhor se enquadra no que precisamos, rotulando-o com um texto a palavra-chave entre "" e "" que sintetize seu signicado. Em seguida, precisamos denir, de forma no ambgua (preferencialmente usando a prpria UML), o que signica a palavra-chave. Por exemplo, um relacionamento bsico da UML o relacionamento de uso/dependncia, representado gracamente pela seta tracejada com ponta aberta (ver sees 6.13, 11.2 e 11.3). Esse mesmo elemento grco pode ser rotulado, por exemplo, com estende e inclui para modicar o signicado de uso ou dependncia para incluso de um caso de uso em outro de duas formas diferentes, conforme voc viu na Seo 3.5 Relacionamentos em Diagramas de Casos de Uso. A UML j relaciona e especica inmeras palavras-chave que so de uso frequente da comunidade de modelagem1 Outras palavras-chave muito usadas (e que usamos em nossa aulas) so ator, entidade, interface e singleton, para estender a semntica de classes em um modelo de classes, especicando respectivamente que uma dada classe uma categoria de usurios, que uma dada classe um conceito do negcio ( uma classe de entidade), que uma classe de interface e, nalmente, que uma classe s pode ser instanciada uma nica vez. O conceito de palavras-chave foi separado do conceito de esteretipo (do qual no tratamos neste texto) a partir da verso 2.0 da UML. Muitos autores, no entanto, ainda se referem a palavras-chave como sendo esteretipos da UML.

11.6 Resumo do Captulo

Existem outros quatro diagramas da UML que podem ajudar bastante na especicao de determinados aspectos das dimenses temporal e estrutural do sistema e na organizao dos modelos. Os diagramas de viso geral da interao, de pacotes, de componentes e de instalao compartilham os conceitos associados aos cinco diagramas de que j tratamos. Diagramas de viso geral da interao podem ser entendidos como combinaes entre diagramas de atividade e de sequncia. Essas combinaes se do pela colocao de quadros de interao dos diagramas de sequncia nos lugares das caixas de aes
1

Ver Tabela B1 no documento de superestrutura da UML

11.6. RESUMO DO CAPTULO

195

dos diagramas de atividades. Portanto, os quadros de interao que especicam as colaboraes necessrias para as realizaes das aes so "costurados" com o uso dos elementos que compem a estrutura de controle dos DAs. A recomendao que damos para tentar tornar as aes to simples quanto possvel, objetivando obter quadros de interao visualmente simples. Pacotes so contineres usados para agruparmos logicamente certos elementos da notao, provendo um espao de nomes para os elementos agrupados e permitindo que organizemos o modelo, dividindo-o em partes relacionadas entre si para melhor visualizao e compreenso. Os elementos mais comumente agrupados com o uso de pacotes so classes, atores, casos de uso e outros pacotes. Pacotes contendo outros pacotes permitem formar hierarquias de pacotes. O relacionamento de dependncia entre pacotes deve ser representado nos diagramas e a boa prtica recomenda estabelecer interfaces de comunicao entre os pacotes que se relacionam. Um componente corresponde a um agrupamento fsico de elementos do modelo que prov um conjunto de funcionalidades. Dessa forma, componentes so tambm contineres. Um diagrama de componentes apresentado como um conjunto de smbolos que representam os componentes, conectados entre si por meio de relacionamentos de dependncia e comumente usando classes de interface para intermediar a comunicao entre os componentes. Os componentes em um sistema tm a ver com como projetamos e implementamos o sistema, ou seja, com a arquitetura do sistema. Em sistemas distribudos necessitamos representar que partes do software processam em que partes do hardware e quais so os mecanismos de comunicao entre essas partes. Essa informao colocada sob a forma de um ou mais diagramas de instalao da UML, usualmente em um documento do sistema chamado de Documento de Arquitetura. Um diagrama de instalao consiste de um conjunto de caixas que representam os ns de processamento, ligadas por associaes de comunicao que usualmente indicam o protocolo usado para a comunicao. Os ns podem conter as representaes dos componentes contidos neles. A UML fornece uma notao grca bsica para os elementos estruturais, comportamentais, de agrupamento, itens anotacionais e os blocos relacionais bsicos, dentre outros. Como a semntica de cada elemento e suas formas de emprego so precisamente denidas na especicao, a notao bsica no atende adequadamente a todas as necessidades de modelagem nos diversos domnios. O OMG estabeleceu, de antemo, a possibilidade de uso das palavras-chave, que podem ser entendidas como mecanismo de extenso da UML. Uma palavra-chave usada quando se necessita de um elemento estrutural, comportamental, de agrupamento, anotacional ou de relacionamento que no existe na UML, mas que semelhante a algo que j existe. Voc pode criar sua palavra-chave, caso necessite, mas precisa especicar, de maneira

196

CAPTULO 11. DIAGRAMAS COMPLEMENTARES

inequvoca, seu signicado e seu modo de emprego. A UML j relaciona e especica no documento de superestrutura inmeras palavras-chave que so de uso frequente da comunidade de modelagem.

11.7 Exerccios Propostos

1. No exerccio trs da Seo 10.11, apresentamos uma tabela com alguns passos da especicao do caso de uso Efetuar Pedido da nossa empresa ZYX. Desenvolva o diagrama de atividades que especica gracamente o trecho do caso de uso e, com base nele e na colaborao representada no DS proposto como soluo daquela atividade, desenvolva o diagrama de viso geral da interao para esse trecho do caso de uso. Considere, em princpio, que o diagrama de classes o resultante da soluo que demos para aquele exerccio, mas voc pode adicionar outras classes se julgar necessrio. 2. Agrupe as classes do diagrama de classes da ZYX em sete pacotes: Controle de Clientes, Controle de Pedidos, Controle de Fornecedores, Controle de Estoque, RH, Controle e Viso. Elabore, tambm, um diagrama de pacotes em mais alto nvel, mostrando as dependncias entre os quatro pacotes e supondo que as navegabilidades no assinaladas so bidirecionais. O diagrama de classes o da Figura 11.9. 3. Desenvolva um diagrama de distribuio do sistema da ZYX considerando que: o sistema web, ou seja, usa navegadores web como clientes do lado dos usurios e servidor de aplicao (onde os programas so executados) do outro lado; a arquitetura do sistema ainda prev um terceiro n que processa o servidor de banco de dados (SGBD); a comunicao entre os clientes e o servidor de aplicao feita usando o protocolo HTTP; a comunicao entre o servidor de pginas e de aplicao feita usando-se sockets; cada pacote que estabelecemos na Atividade 2 resultar na construo de um componente. Os componentes residiro no servidor de aplicao. Represente os componentes correspondentes aos pacotes (apenas esses pacotes, no considerando ainda as tecnologias de implementao e persistncia) dentro do continer que representa o servidor.

11.7. EXERCCIOS PROPOSTOS

197

Formulario

ControleEntradaPedido + + verificarLoginSenha() criarItemPedido()

PedidoDeReposicaoDeEstoque dataColocacao 1 +

Pedido numero enderecoEntrega tipoPagamento * prazoEntrega calculaPrTotal() criaItemPedido() 1 1 + + +

Cliente endereco telefone verificarLoginSenha() getNome() getendereco() * 1 +

singleton ColecaoClientes verificarLoginSenha()

1..* 1..* ItemDeReposicaoDeEstoque ItemDePedido ordem quantidade * * 1 1 singleton CatalogoDeProdutos + getPuDescricao() localizaProduto() 1 * + Produto codigo descricao precoUnitario qtdEstoque getPuDescricao() Fornecedor * ordem quantidade ClientePF nome ClientePJ razaoSocial contato

+representanteDeVendas

0..1

Funcionario nome

Fornecimento prazoFornecimento precoFornecimento

Figura 11.9: O diagrama de classes de especicao da ZYX.

As solues encontram-se a partir da Pgina 232.

APNDICE

S OLUES DOS E XERCCIOS P ROPOSTOS

A.1 Exerccios do Captulo 2, pgina 23:
1. Processos de software estabelecem antecipadamente as sequncias das atividades, o que ser produzido em cada atividade, os prazos, os custos, os pontos de controle, os nveis de qualidade e as demais variveis associadas ao projeto de desenvolvimento de um sistema. Esses elementos servem de base para a gerncia eciente do projeto, que busca manter cada uma das variveis dentro dos nveis de qualidade preestabelecidos para o software. A modelagem possibilita o estudo do sistema e a discusso de correes, modicaes e validao com o cliente antes de o sistema ser construdo a um custo relativamente baixo, portanto. A modelagem facilita a comunicao entre os membros das equipes de anlise e projeto e entre eles e os clientes e usurios. A modelagem permite estabelecer clara e inequivocamente o que para ser feito e como fazer o sistema. 2. So vrias as razes para usar a UML durante a anlise e o projeto de sistemas OO. Citaremos algumas delas. A notao da UML precisamente denida na especicao, o que signica que modelos construdos com ela no do margem a mltiplos entendimentos, ou seja, ambiguidade. A UML permite construir modelos completos, na medida em que capaz 199

200

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS de capturar as dimenses funcional, estrutural e temporal que compem os sistemas de informao. Com o uso de software de suporte (CASE), disponveis amplamente porque a linguagem padronizada, podemos manipular facilmente os diversos elementos grcos na notao, tornando a tarefa de modelagem uma atividade bastante dinmica e efetiva.

A.2 Exerccios do Captulo 3, pgina 41:

1. No primeiro caso (a), identica-se uma nica funcionalidade do sistema (abrir OS) para a qual existe um nico ator: "atendente". No segundo caso (b), tambm se identica uma nica funcionalidade do sistema (Abrir OS) para qual tambm existe somente um ator (atendente), j que o cliente no balco no interage com o sistema. O terceiro caso (c) conceitualmente idntico ao segundo. A nica coisa que muda a tecnologia: no caso anterior, a informao impressa; nesse caso a informao vai por e-mail. Alm disso, o supervisor no interage com o sistema que gera a OS, que o sistema em estudo. Ele interage com outro sistema: o Outlook ou Gmail/Hotmail via Firefox ou algo no gnero. Para os trs casos, portanto, a resposta a mesma: o Atendente o nico ator. 2. No primeiro caso (a), identica-se uma nica funcionalidade do sistema: Informar Concluso de OS. No segundo caso (b) existem duas funcionalidades. A primeira Acionar Alarme (o ator o Sensor de Presena) e a segunda Resetar Alarme (voc pode achar um nome melhor para essa funo, que signica desligar a sirene e rearmar o sistema). 3. a) O Sistema de Contas a Receber (SCR) informado (por uma mensagem eletrnica) da concluso de uma OS. Colocamos o SCR como ator porque, em geral, sistemas precisam estar online, para que possam se comunicar. Se a comunicao for em batch, o SCR no participar como ator do caso de uso. Outro fator importante que o caso de uso Efetuar Cobrana caso de uso do SCR, e no do sistema que estamos modelando. Por isso ele no aparece no diagrama da Figura A.1. b) J vimos casos semelhantes ao longo do texto: entrega de documentos impressos no caracterizam interao usurio-sistema. O trecho correspondente do diagrama ca como na Figura A.2.

A.2. EXERCCIOS DO CAPTULO ??, PGINA ??:

201

Informar Concluso de OS Atendente SCR

Figura A.1: O atendente, a concluso das OS e o SCR.

Informar Concluso de OS Atendente

Figura A.2: A entrega de documentos impressos.

Abrir OS

Atendente

Figura A.3: Dados do cliente como passos da descrio do caso de uso.

c) A informao dos dados do cliente e do equipamento faz parte do que feito no caso de uso, ou seja, de sua descrio. O trecho correspondente do diagrama ca como na Figura A.3. d) A apresentao do formulrio de cadastramento de um cliente e seu preenchimento pelo atendente so feitos dentro do caso de uso Abrir

202

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Abrir OS

Atendente

Alterar Dados Cadastrais de Cliente Superv isor

Figura A.4: Atores distintos participando de casos de uso distintos.

OS. O supervisor pode acessar o sistema para alterar os dados do cliente

quando isso for necessrio. Essa outra funcionalidade do sistema. O diagrama ca, portanto, como o da Figura A.4. e) A associao de um ator a um caso de uso, importante lembrar, signica que essa funcionalidade est disponvel para esse ator como uma funcionalidade do sistema. Cadastrar Cliente estende Abrir OS porque, durante a abertura de uma OS, pode ser necessrio cadastrar o cliente se seus dados no constarem do cadastro. O diagrama ca conforme a Figura A.5. f) Os dados de um cliente podem ser cadastrados pela recepcionista, como uma atividade a mais, opcional, durante a abertura de uma lista de exames. O diagrama ca conforme a Figura A.6. g) Aqui h uma questo interessante: um sistema no pode ser ator de si mesmo, pois, anal, no estamos interessados nos detalhes dos atores e sim do sistema em estudo (uma coisa no pode ser de interesse e de no interesse ao mesmo tempo). Eu mencionei que o sistema "dispara" a impresso do relatrio de inadimplentes, mas na realidade quem faz isso

A.3. EXERCCIOS DO CAPTULO ??, PGINA ??:

203

Abrir OS Atendente

extend

Cadastrar Cliente

Superv isor

Figura A.5: Ator associado ao caso de uso base e ao que estende.

uma funcionalidade do sistema operacional implementada por um relgio interno que "sabe" a hora e o mecanismo de agendamento de aes a serem executadas nas horas agendadas. No Windows isso feito pelo comando "AT"; no Linux, isso o CRON/Crontab. O diagrama ca conforme a Figura A.7. h) Essa situao bem simples. Basta pensarmos em como precisa ser a sequncia das aes do ator e do sistema nesse caso. Um usurio, ao se autenticar no sistema, faz com que o sistema verique se ele est ou no na lista negra. Caso o usurio esteja, ainda durante a execuo do caso de uso Efetuar Logon o sistema envia um "torpedo" ao chefe do suporte, que no participa do caso de uso como ator porque no interage com ele, mas com a funcionalidade de ler SMSs do seu celular. Esses detalhes esto dentro do caso de uso e no aparecem no diagrama, que ca conforme a Figura A.8.

A.3 Exerccios do Captulo 4, pgina 57:

1. Para responder ao item, suponha um caso de uso A que inclui o caso de uso B. A faz a chamada a B, executando seus passos. Suponha agora que o caso de uso

204

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Cadastrar Dados

Cliente

extend

Abrir Lista de Exames Recepcionista

Figura A.6: Caso de uso executado por um ator ou possivelmente durante a execuo de outro caso de uso por outro ator.

Ocorre s 18:30h, nas sextas-feiras.

Imprimir Relao de Inadimplentes Relgio do Sistema

Figura A.7: Usando o mecanismo de agendamento do Sistema Operacional como ator.

A.3. EXERCCIOS DO CAPTULO ??, PGINA ??:

205

Efetuar Logon Usurio

Figura A.8: Complexidade "escondida" em um caso de uso.

B estenda o caso de uso A. B estende (engorda, aumenta) A com seus passos; portanto, A inclui B, s que opcionalmente, segundo as regras de negcio.
2. O relacionamento de incluso especica que a chamada ao caso de uso feita sempre segundo as regras de negcio. O sempre signica, neste caso, idealmente, tipicamente... Lembre-se do pagamento pelo almoo (Seo 3.5, Figura 3.7), que, embora obrigatrio, pode no ocorrer se o cliente fugir pela janela. J extenses so incluses que no ocorrem sempre, portanto alternativamente, ou atipicamente, segundo as regras de negcio. 3. O diagrama ca como o da Figura A.9 Note que mesmo que o Supervisor, o Cliente e a Operadora do Carto de crdito interajam eventualmente com a funcionalidade Registrar Compra, o relacionamento entre eles e o caso de uso de associao. A descrio abreviada pode ser algo como na Tabela A.1. Note tambm que identicamos o Caixa como iniciador do caso de uso porque ele que, efetivamente, indica o incio de uma nova compra no sistema. O Cliente seria o iniciador do caso de uso de negcio, se o estivssemos descrevendo. E a descrio detalhada pode ser como nas tabelas A.2 e A.3: Repare que usei como cabealho da descrio detalhada o mesmo contedo da descrio abreviada. Alm disso, coloquei sa palavras Supervisor, Operadora, SCE, SF e SCR entre parnteses na relao de atores, como se fossem apelidos para Supervisor de Vendas, Operadora do Carto, Sistema de Controle de Estoque, Sistema de Faturamento e Sistema de Contas a Receber,

206

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Sistema de Faturamento

Sistema de Contas a Receber

Superv isor de Vendas Operadora do Carto Registrar Compra

Cliente Caixa Sistema de Contole do Estoque

Figura A.9: O registro de compra em um supermercado.

respectivamente. Uso muito isso para dar "apelidos" mais abreviados aos atores, facilitando o trabalho de descrio do caso de uso. No houve muita preocupao com a preciso com respeito s tcnicas usadas nesse tipo de aplicao. A completude da descrio tambm foi sacricada a bem da conciso deste texto; nem todos os cursos alternativos e de exceo foram tratados. Situaes como a no aprovao da operadora de carto, seja por senha invlida do cliente ou por insucincia de crdito, assim como falhas de comunicao com o SCE, com o SF, o SCR e com a operadora do carto de crdito, alm possibilidade de informao de senha incorreta de supervisor, deveriam ser tratados se o sistema fosse um sistema "de verdade". Consideramos, no entanto, que o grau de detalhamento da soluo apresentada suciente, do ponto de vista acadmico, para os propsitos de nosso texto. Se voc um especialista nesse tipo de sistema, sinta-se vontade para descrever

A.3. EXERCCIOS DO CAPTULO ??, PGINA ??: Tabela A.1: Descrio abreviada do caso de uso Registrar Compra.

207

Caso de Uso: Propsito:

Registrar Compra Registrar os itens de um carrinho de compras no supermercado e receber o pagamento pela compra. Um cliente chega ao caixa com os itens que deseja comprar. O Caixa registra os itens de compra e recebe o pagamento, que pode ser feito em dinheiro, em dbito ou crdito no carto. Ao final, o Cliente deixa a loja com os produtos adquiridos. Caixa, Cliente, Supervisor de Vendas, Operadora do Carto, Sistema de Controle de Estoque, Sistema de Faturamento, Sistema de Contas a Receber. Caixa.

Descrio geral:

Atores:

Iniciador:

Pr-condies: Venda anterior encerrada, Vendedor autenticado no sistema. Ps-condies: Venda registrada, paga e concluda em caso de sucesso.

completamente o caso de uso e com maior preciso.

Podemos apreender deste exerccio que a tarefa de especicao de casos de uso bastante extenuante pela necessidade de ser completa e precisa, condicionada qualidade de ser concisa.

As especicaes, aps lidas e aprovadas pelos usurios, seguem para o pessoal de projeto, para especicao da soluo, e para e equipe de formulao dos casos de testes funcionais que iro ajudar na aprovao do sistema (homologao) para implantao.

208

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS Tabela A.2: Descrio detalhada do caso de uso Registrar Compra (incio).

Caso de Uso: Propsito:

Registrar Compra Registrar os itens de um carrinho de compras no supermercado e receber o pagamento pela compra. Descrio Um cliente chega ao caixa com os itens que deseja comprar. O geral: Caixa registra os itens de compra e recebe o pagamento, que pode ser feito em dinheiro, em dbito ou crdito no carto. Ao final, o Cliente deixa a loja com os produtos adquiridos. Atores: Caixa, Cliente, Supervisor de Vendas (Supervisor), Operadora do Carto (Operadora), Sistema de Controle de Estoque (SCE), Sistema de Faturamento (SF), Sistema de Contas a Receber (SCR). Iniciador: Caixa. Pr-condies: Venda anterior encerrada, Vendedor autenticado no sistema. Ps-condies: Venda registrada, paga e concluda em caso de sucesso. Curso tpico (CT) 1. Caixa indica no sistema o incio de uma nova compra. 2. Sistema exibe no monitor o texto Prximo Cliente. 3. Sistema zera o total da compra. 4. Sistema imprime na fita o cabealho da lista com os dados do estabelecimento e a data/hora atuais. 5. Para cada item do carrinho de compras a. Caixa apresenta o cdigo de barras ao leitor tico. b. Sistema emite um beep sinalizando que o cdigo foi lido e o produto foi localizado no estoque. c. Sistema busca o preo e a descrio do produto no cadastro. d. Sistema exibe o preo e a descrio do produto no monitor. e. Sistema adiciona o preo do produto ao total da compra. f. Sistema imprime item de compra na fita de papel. g. Sistema exibe o novo total da compra, sobrescrevendo o total exibido anteriormente. 6. Caixa informa ao sistema o fim da lista de compras. 7. Sistema solicita a forma de pagamento. 8. Caixa informa que o pagamento ser feito por meio de carto de crdito com chip. 9. Sistema instrui ao cliente a insero do carto. 10. Sistema aguarda a insero do carto. 11. Sistema l o nmero do carto. 12. Sistema exibe no visor do leitor do carto o valor da compra e solicita a informao da senha. 13. Cliente digita a senha do carto e pressiona tecla verde Enviar. 14. Sistema transmite o nmero do carto, o total da compra e a senha operadora. 15. Operadora valida a compra. 16. Sistema envia o total da compra ao SCR. 17. Sistema informa que a compra foi aprovada e solicita que cliente retire o carto da leitora de cartes.

A.3. EXERCCIOS DO CAPTULO ??, PGINA ??:

209

Tabela A.3: Descrio detalhada do caso de uso Registrar Compra (nal).

18. Sistema abre a gaveta do caixa. 19. Sistema envia a lista de itens adquiridos ao SCE. 20. Sistema envia o total da compra ao SF. 21. Sistema exibe a mensagem Compra encerrada com sucesso no monitor. 22. Sistema conclui a transao de compra. ** Fim do Caso de Uso ** Cursos alternativos (CA) CA 1: Passo 5g do CT Cliente solicita ao Caixa que interrompa a transao de venda por indisponibilidade financeira. ** COMPLETAR, COMO EXERCCIO ** CA 2: Passo 8 do CT Caixa informa que o pagamento em dinheiro. 1. Caixa registra o valor em dinheiro dado pelo Cliente. 2. Sistema calcula o valor a ser devolvido a ttulo de troco. 3. Volta ao passo 18 do CT. CA 3: Passo 15 do CT Operadora no aprova a compra. ** COMPLETAR, COMO EXERCCIO ** Cursos de exceo (CE) CE 1: Passos 5b do CT Sistema no pde ler o cdigo de barras. 1. Caixa digita o cdigo manualmente. 2. Volta ao passo 5c do CT. CE 2: Passos 5f do CT Final da fita de impresso. 1. Supervisor pressiona tecla de interveno de supervisor. 2. Sistema solicita senha de supervisor. 3. Supervisor informa senha. 4. Sistema valida senha de supervisor. 5. Sistema exibe menu de supervisor. 6. Supervisor escolhe opo Reimprimir Itens da Transao de Compra. 7. Sistema imprime dados do estabelecimento, data e hora originais da compra e a lista de itens. 8. Supervisor se desloga do sistema, passando o controle da transao de volta ao Caixa. Sistema retorna ao passo 5g do CT.

210

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

A.4 Exerccios do Captulo 5, pgina 69:

1. As entidades e as informaes so: Universidade: nome e endereo; Departamento: nome; Professor: nome; Disciplina: nome, data de incio e de m, durao da disciplina; Aluno: nome, endereo, data de nascimento etc. Cabe, adicionalmente, uma observao importante: quando voc pensou nas informaes para a identicao das entidades, muito provavelmente voc incluiu alguns relacionamentos. Por exemplo, quando voc identicou a classe Professor, pode ter pensado nas disciplinas que um professor leciona como uma informao que seria interessante armazenar para os professores. Na realidade, voc corretamente identicou a associao de uma classe com outra como sendo uma informao que uma ou ambas as classes devem armazenar. 2. Aproveitando a ideia da resposta comentada da atividade 1 teremos: Universidade: nomeUniversidade, enderecoUniversidade; Departamento: nomeDepartamento; Professor: nomeProfessor, dataNascimentoProfessor, dataAdmissao; Disciplina: nomeDisciplina, dataInicio, dataFim, duracaoDisciplina; Aluno: nomeAluno, enderecoResidenciaAluno, dataNascimentoAluno etc. Os rtulos completos para alguns desses atributos poderiam ser:

+nomeUniversidade:String; +enderecoUniversidade:String; -dataInicio:Date; -dataFim:Date; -/duracaoDisciplina:int;

As visibilidades foram denidas como pblicas e privadas sem nenhum objetivo especco alm de para exercitarmos a notao. O atributo duracaoDisciplina foi denido como derivado porque pode ser calculado pela diferena entre dataFim e dataInicio da disciplina. Cabe, aqui, um breve comentrio: usual a omisso dos elementos formadores de genitivos (do, da, dos, das) nos identicadores dos atributos para reduzir seus tamanhos, sem perda signicativa de expressividade. Assim, o identicador nomeDaDisciplina pode ser substitudo, como foi, por nomeDisciplina.

A.5. EXERCCIOS DO CAPTULO ??, PGINA ??:

211

A.5 Exerccios do Captulo 6, pgina 96:

1. Os nomes das associaes esto em itlicos: a) PedidoDeReposicaoDeEstoque contm ItemDeReposicaoDeEstoque; b) Cliente coloca (ou faz) Pedido; c) Fornecedor fornece Produto; d) Produto especica ItemDePedido; e) Funcionario atende a ClientePJ. Esses nomes so bons porque, se quisermos ler no sentido contrrio, a leitura ca da seguinte forma: a) ItemDeReposicaoDeEstoque contido em PedidoDeReposicaoDeEstoque; b) Pedido colocado por (ou feito por) Cliente; c) Produto fornecido por Fornecedor; d) ItemDePedido especicado por Produto; e) ClientePJ atendido por Funcionario. Para concluir a resposta, importante salientar que quase todos os nomes dessas associaes podem ser omitidos do diagrama por serem associaes com signicados um tanto bvios. Talvez eu deixasse apenas o nome da associao do item 5, se eu no tivesse colocado o rtulo do papel que Funcionrio assume nessa relao com ClientePJ. O funcionrio o representante de vendas para o ClientePJ. 2. Um pedido de reposio de estoque est associado a um ou mais itens de reposio de estoque e um item de reposio de estoque est associado a um pedido de reposio de estoque; Um item de reposio de estoque est associado a um produto e um produto est associado a zero ou mais (tambm se fala "a qualquer nmero de") itens de reposio de estoque; Um pedido est associado a um ou mais itens de pedido e um item de pedido est associado a um pedido; Um item de pedido est associado a um produto e um produto est associado a zero ou mais itens de pedido; Um pedido est associado a um cliente e um cliente est associado a qualquer nmero de pedidos;

212

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Univ ersidade

tem

1..*

Departamento

1 1..* 1..* 0..1

tem matricula aloca

* Aluno frequenta * 1..*

1..* Disciplina ministra * 1..*

0..1 Professor

+chefe

Figura A.10: Ambiente Acadmico do Municpio de Sertozinho Alegre.

Um cliente PJ est associado a zero ou 1 representante de vendas e um representante de vendas est associado a qualquer nmero de clientes PJ. Repare que no li funcionrio no ltimo item, mas sim o papel de representante de vendas que funcionrio assume na associao com cliente PJ. No ltimo item eu tambm poderia ler: cliente PJ tem ou no um representante de vendas, caracterizando a multiplicidade opcional 0..1. 3. O modelo que desenvolvemos o da Figura A.10. Um departamento encontra-se associado a somente uma universidade, porque o objeto (instncia de Departamento) "Departamento de Fsica da PUC", por exemplo, est associado a somente um objeto da classe Universidade, no caso a PUC. J discutimos a questo dos nomes das associaes entre Departamento e Professor. As multiplicidades so opcionais em cada ponta da associao de chea, porque um Departamento pode estar sem chefe e um professor pode no ser chefe mas, se for, ele de no mximo um departamento (no h acmulo de chea, certo?). J vimos que a expresso "qualquer nmero de" resulta em multiplicidade "zero ou mais", representada na UML por um * ou 0..*, indistintamente.

A.5. EXERCCIOS DO CAPTULO ??, PGINA ??:

213

A questo de um aluno poder frequentar uma ou mais disciplinas muitas das vezes interpretada como a no obrigatoriedade de ele estar frequentando pelo menos uma disciplina. Na realidade, os verbos poder e dever causam muita confuso em uma especicao. Embora os signicados desses dois verbos estejam precisamente denidos na NM1 (Norma Mercosul 1), costumo aconselhar os meus alunos a no us-los e, caso os encontrem em uma especicao em prosa, perguntem aos especialistas do negcio antes de elaborar os modelos UML. Imaginemos que eu tenta perguntado ao especialista do negcio "Ambiente Acadmico" e ele me respondeu que um aluno precisa estar matriculado em pelo menos uma disciplina. Por isso usei a multiplicidade "1..*" na ponta direita da associao frequenta. Algumas multiplicidades no foram especicadas no texto. Perguntei aos especialistas e usei o bom senso quando eles no souberam me responder. Os atributos poderiam constar do modelo... eu s no me preocupei com eles neste momento. 4. O modelo que desenvolvemos o da Figura A.11. Tornamos as classes Usuario e UsuarioComum abstratas pelo fato de no existirem usurios desses tipos, ou seja, de s existirem usurios dos tipos UsuarioComumAluno, UsuarioComumMembroComunidade e UsuarioFuncionario. Alm disso, poderamos marcar no modelo essas especializaes como coberturas completas. Criamos o atributo multivalorado autor na classe Obra para podermos armazenar qualquer nmero de autores, inclusive zero, para cada obra. A soluo de termos nenhum autor para uma obra modela corretamente a possibilidade de cadastrarmos obras annimas. Poderamos fazer o mesmo com o atributo assunto, mas decidi criar uma classe Assunto associada classe Obra como uma alternativa multivalorao do atributo. No associamos a classe Exemplar classe UsuarioComum para fatorarmos as duas associaes de emprstimo, porque elas tm multiplicidades diferentes nas pontas UsuarioComumAluno e UsuarioComumMembroComunidade (0..1 e 0..2, respectivamente). Repare que, na soluo apresentada, no coloquei como atributo da classe Exemplar a marcao de que o exemplar se encontra emprestado. Marcaes so as tais ags que o pessoal de implementao "adora" colocar como atributos de classes. Deixei de incluir essa ag porque ela no , de fato, necessria. De maneira geral, ags no so necessrias porque so atributos derivados, ou seja, so obtidas por meio de algoritmos que executamos usando valores de outros

214

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Usuario nome

Assunto descricao -

UsuarioComum numeroRegistro

UsuarioFuncionario login senha

1..*

1..* Obra isbn titulo autor [0..*] 0..2 0..1

UsuarioComumAluno

UsuarioComumMembroComunidade

1 1..* Exemplar 0..1 dataInclusaoAcervo 0..1

Figura A.11: Modelo da soluo para o sistema de controle de uma biblioteca.

atributos. Se uma informao resultado de um algoritmo, essa informao no precisa ser armazenada, pois ela sempre pode ser calculada quando for necessria. Adicionar atributos derivados a classes pode, ainda, ser uma fonte de inconsistncias. Atributos derivados so adicionados a classes apenas quando o algoritmo para obter seus valores muito complexo ou demorado; essas consideraes devem ser feitas somente em tempo de projeto. No nosso caso, a informao de que um exemplar no est disponvel pode ser obtida por meio do exame da existncia de instncias das associaes de emprstimo; estar disponvel signica no estar emprestado a algum, certo? Visto de outra forma, um exemplar estar emprestado signica haver uma (e no mais do que uma) instncia de associao do tal exemplar (que uma instncia da classe Exemplar) com alguma instncia da classe UsuarioComumAluno ou (exclusive) UsuarioComumMembroComunidade.

A.5. EXERCCIOS DO CAPTULO ??, PGINA ??:

215

Poligono 1

+vertice 3..* {ordered} -

Ponto coordX: int coordY: int

+centro 1 1 -

Circulo raio: int

Figura A.12: Modelo da soluo para o editor grco.

5. A soluo que demos a da Figura A.12: Criamos uma classe Ponto para representar o par ordenado P (x, y) do plano. As composies especicam que, se um ponto est associado a um polgono, representando o papel de vrtice, ele no pode estar associado, ao mesmo tempo, a um crculo, representando o papel de centro. As multiplicidades 1 nas pontas das composies especicam que, se um polgono for removido, seus vrtices sero removidos tambm, j que no podem estar associados a 0 (zero) polgonos. O mesmo raciocnio se aplica aos crculos e seus centros. Repare que colocamos junto multiplicidade 3..* o rtulo {ordered} para especicar que a coleo de vrtices ordenada, ou seja, segue uma sequncia determinada, que no importa agora qual . Expresses entre "" e "" colocadas no modelo so outras restries que devem ser observadas durante a execuo do sistema. Veremos mais sobre restries adiante, no nal deste captulo. 6. A resposta direta: basta aplicar a transformao da Figura 6.19; considerando que a classe A da Figura 6.19 corresponde classe Empresa da Figura 6.18, a classe B corresponde classe Pessoa, a classe C corresponde classe Emprego, m corresponde multiplicidade * e n corresponde multiplicidade 0..1. O modelo ca, portanto, como na Figura A.13. 7. A soluo representarmos os dois pacotes com relacionamentos de dependncia entre eles. Note que so duas setas, e no uma seta com duas pontas. A Figura A.14 ilustra. Ao detalharmos mais cada pacote, as classes de interface que proveriam esse isolamento estariam representadas dentro do pacote com o relacionamento de dependncia chegando nelas. 8. A restrio de que um exemplar no pode ser emprestado a dois alunos ou a dois membros da comunidade est garantida pelas multiplicidades 0..1 nas pontas das associaes das classes UsuarioComumAluno e

216

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Empresa 1 * -

Emprego matricula salario 0..1 1

Pessoa

Figura A.13: Modelo da soluo para transformao de classe de associao para classe cheia.

Controle de Vendas

Cadastro de Clientes

Figura A.14: Modelo da soluo para dependncia entre pacotes.

UsuarioComumMembroComunidade com a classe Exemplar, junto a esta.

Entretanto, nada impede, segundo aquele modelo, que um exemplar seja emprestado a um aluno e a um membro da comunidade simultaneamente, o que no pode acontecer. A soluo tornarmos essas duas associaes mutuamente excludentes, aplicando a elas a restrio XOR. A Figura A.15 ilustra.

A.6 Exerccios do Captulo 7, pgina 117:

1. Eu no perderia meu tempo desenvolvendo um DME para os objetos da classe Interruptor, porque qualquer interruptor s possui dois estados: ligado e desligado, passando de um a outro unicamente pelos eventos de ligamento e desligamento. J os objetos da classe Ar Condicionado possuem mais estados: desligado, ligado no ventilador, ligado na posio frio, ligado na posio quente (isso para alguns deles), tudo isso usando exausto ou recirculao e

Assunto descricao -

UsuarioComum numeroRegistro

UsuarioFuncionario login senha

A.6. EXERCCIOS DO CAPTULO ??, PGINA ??:

1..*

217

1..* Obra isbn titulo autor [0..*] 0..2 {XOR} 0..1 dataInclusaoAcervo 0..1 0..1

UsuarioComumAluno

UsuarioComumMembroComunidade

1 1..* Exemplar

Figura A.15: Modelo da soluo para tornarmos mutuamente excludentes instncias de associaes.

com vrios nveis de frio ou calor. Dependendo dos tipos de controles do painel, os eventos que o operador precisa gerar para passar de um estado a outro podem no ser to triviais quanto o switch de um interruptor. 2. A soluo que demos est no DME da Figura A.16. Podemos assumir que, quando um apartamento instanciado, ou seja, quando cadastrado no sistema, ele assumir automaticamente a condio Livre. Por isso colocamos o pseudoestado inicial apontando para esse estado. Estando Livre, um apartamento poder transitar para Ocupado, pela ocorrncia de um check-in, ou para Reservado, pela ocorrncia de uma reserva feita por um cliente para o dia corrente. Estando Ocupado, um apartamento s poder transitar para Livre, pela ocorrncia de uma desocupao (check-out, no jargo da hotelaria). nesse momento que a fatura dever ser impressa, ou seja, imediatamente antes da sada do estado Ocupado. Por isso especicamos a impresso da fatura usando o rtulo exit/imprimir fatura. Note que poderamos ter colocado a impresso da fatura como ao na transio de Ocupado para Livre, certo? Estando Reservado, um apartamento poder transitar para Livre, caso ocorra o cancelamento da reserva, ou para Ocupado, caso o cliente que o tenha reservado efetue o check-in. 3. Existe algo em comum entre os estados Reservado, Ocupado e Livre, que se opem ao estado Interditado para Obras. Esse algo em comum referese situao, nos trs primeiros casos, de um apartamento estar operacional.

218

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

checkin checkout

Liv re reserva

cancelamento de reserva Ocupado + exit / imprimirFatura checkin

Reserv ado

Figura A.16: Diagrama de mquina de estados para objetos da classe Apartamento do Hotel Cincoestrelas.

Interditado para obras e, portanto, no operacional signica que o apartamento no est livre e que no tem possibilidade de ser ocupado ou reservado. Os estados Reservado, Ocupado e Livre podem ser considerados, dessa forma, subestados independentes do estado Operacional. O diagrama da Figura A.17 ilustra esses conceitos usados na soluo do exerccio. De acordo com o diagrama da Figura A.17, o estado Operacional aquele que um apartamento assumir quando for instanciado; o subestado Livre o estado em que o apartamento entrar quando entrar no estado Operacional, seja pela instanciao, seja pelo retorno do estado No Operacional. Estando em qualquer subestado de Operacional, um apartamento poder transitar para No Operacional pela ocorrncia de uma solicitao de reparo. Por essa razo, a atividade imprimirFatura na sada do estado Ocupado, na soluo dada para o Exerccio 2, foi transformada em uma ao da transio entre o estado Ocupado e o estado Livre, porque no teria sentido o cliente receber uma fatura tendo sido obrigado a sair do apartamento em consequncia de sua interdio. Por isso, chamamos sua ateno para o cuidado que voc precisa ter na escolha do lugar para colocao das aes e atividades ao usar

A.7. EXERCCIOS DO CAPTULO ??, PGINA ??:

219

Operacional

checkin

Ocupado

Liv re

checkout /imprimirfatura

No Operacional (Em Reparos) checkin

reserva feita

reserva cancelada Reserv ado

Figura A.17: Estados Reservado, Ocupado e Livre como subestados do estado Operacional na soluo para o exerccio do Hotel Cincoestrelas.

estados compostos nos diagramas.

A.7 Exerccios do Captulo 8, pgina 142:

1. A rotina matinal varia muito de pessoa para pessoa e, para a mesma pessoa, pode variar a cada dia. De maneira geral, uma rotina matinal pode ser modelada conforme o diagrama de atividade do diagrama da Figura A.18. No vejo o que discutir no modelo alm das aes que correspondem preparao da refeio matinal. A preparao do sanduche uma ao que ocorre em paralelo com a preparao do caf (que envolve ferver a gua, derram-la dobre o p no coador e aguardar o caf passar pelo coador, se voc no usa uma mquina para isso). Para a preparao do caf com leite, necessrio que o caf esteja coado e que o leite esteja quente, por isso coloquei uma juno aps essas duas aes para sincroniz-las antes da ao

220

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

So 6:00h e o despertador toca.

Desligar o despertador

Verificar hora

[tempo de sobra] Tomar banho

Ler a primeira pgina do j ornal Traj ar-se

[seno]

Preparar caf

Esquentar leite

Conduzir-se empresa

Preparar sanduche Assinar o ponto

Preparar caf com leite

Tomar o caf da manh

Escov ar os dentes

Figura A.18: Um exemplo de aes executadas em uma manh tpica.

A.7. EXERCCIOS DO CAPTULO ??, PGINA ??:

221

signal receipt Alarme

Av aliar se ainda h tempo para uma soneca

[seno] [h tempo para mais uma soneca]

Desligar o despertador

Pressionar o boto "soneca"

Tomar banho

...

Figura A.19: Exemplo de aes para o tratamento de eventos temporais.

da preparao do caf com leite. 2. O diagrama da Figura A.19 captura bem a iterao que tpica para quem usa a funo "soneca" dos despertadores. Ao pressionar o boto "soneca", terminamos a atividade, preparando-nos (dormindo) para o prximo alarme. Da ao Tomar banho em diante, tudo se passa da mesma forma que na soluo do Exerccio 1.

222

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

3. O diagrama das Figuras A.20 e A.21 modela, apenas, o curso tpico do caso de uso Registrar Compra. Pela complexidade, voc pode perceber que a modelagem completa resultaria em um diagrama bem mais complexo, caso modelssemos completamente o caso de uso. Voc pode elabor-lo a ttulo de exerccio. Os ns de deciso em azul so pontos que originam cursos alternativos. As aes que foram apontadas como possveis geradoras de cursos de exceo ou alternativos devem ser tratadas na soluo nal, sob pena de o sistema resultante no cobrir todos as possibilidades, como, por exemplo, o que deveria ser feito caso qualquer um dos sistemas (SCE, SF, SCR) estivesse fora do ar ou mesmo se a comunicao com a operadora do carto no pudesse ser estabelecida.

A.8 Exerccios do Captulo 9, pgina 161:

1. Acompanhando os desvios no diagrama, desde o incio ao m, possvel identicar os cenrios assim: Cenrio 1 (curso tpico): Quantidade do nico item do pedido est disponvel em estoque na quantidade desejada; Cenrio 2: Quantidade do nico item do pedido no est disponvel em estoque na quantidade desejada; Cenrio 3: O pedido composto por mais de um item e todos os itens esto disponveis em estoque nas quantidades desejadas; Cenrio 4: O pedido composto por mais de um item e nem todos os itens esto disponveis em estoque nas quantidades desejadas. Repare que, com os quatro cenrios identicados acima, todos os uxos so percorridos, alguns deles mais de uma vez. 2. Os passos so os seguintes: a) Como temos o nmero do pedido, devemos pesquisar o conjunto de pedidos para localizar o pedido que corresponde ao nmero que temos. H duas opes para isso: i. pesquisar os pedidos feitos pelos clientes at achar o que queremos. Para isso, iniciamos pela classe ColecaoDeClientes, obtendo os clientes da lista. Para cada cliente, obtemos os pedidos feitos por ele/ela at localizar o pedido. Nesse caso atribuiramos mais essa responsabilidade classe ColecaoDeClientes: localizar um

A.8. EXERCCIOS DO CAPTULO ??, PGINA ??:

223

Sistema

Caixa

Cliente

Operadora do Carto

SCR

SCE

Faturamento

Exibir no monitor o texto Prximo Cliente Zerar o total da compra

Indicar no sistema o incio de uma nov a compra

Imprimir na fita o cabealho da lista com os dados do estabelecimento e a data/hora atuais.

Apresentar o cdigo de barras ao leitor tico.

Emitir um beep sinalizando que o cdigo foi lido e o produto foi localizado no estoque.

[leitura Ok] Buscar o preo e a descrio do produto no cadastro

[produto existe no estoque] Exibir o preo e a descrio do produto no monitor, dicionar o preo do produto ao total da compra, imprimir item de compra na fita de papel e Exibir o nov o total da compra, sobrescrev endo o total exibido anteriormente

[ainda h itens no carrinho]

[No h mais itens no carrinho]

Informar ao sistema o fim da lista de compras

Solicitar a forma de pagamento

Selecionar forma de pagamento [pagamento com carto de crdito]

Solicitar a insero do carto Ler o nmero do carto

Inserir carto

1
[carto lido ok]

Figura A.20: Soluo para a especicao na forma grca do caso de uso Registrar Compra Parte I.
Transmitir o nmero do carto, o total da compra e a senha operadora. Analisar a compra

Exibir no v isor o leitor do carto o v alor da compra e solicita a informao da senha.

Digitar a senha do carto e pressionar tecla v erde Env iar

Env iar o total da compra ao SCR

[compra aprovada] Inserir compromisso a cobrar no futuro

Informar que a compra foi aprov ada e solicitar que cliente retire o carto da leitora de cartes e abrir a gav eta do caixa

Aes geradoras de possveis cursos alternativos ou

produto ao total da compra, imprimir item de compra na fita de papel e Exibir o nov o total da compra, sobrescrev endo o total exibido anteriormente

[ainda h itens no carrinho]

224

[No h mais itens no carrinho]

Informar ao sistema o fim da lista de compras

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Solicitar a forma de pagamento

Selecionar forma de pagamento [pagamento com carto de crdito]

Solicitar a insero do carto Ler o nmero do carto

Inserir carto

[carto lido ok]

Exibir no v isor o leitor do carto o v alor da compra e solicitar a informao da senha.

Digitar a senha do carto e pressionar tecla v erde Env iar

Transmitir o nmero do carto, o total da compra e a senha operadora.

Analisar a compra

Env iar o total da compra ao SCR

[compra aprovada] Inserir compromisso a cobrar no futuro

Informar que a compra foi aprov ada e solicitar que cliente retire o carto da leitora de cartes e abrir a gav eta do caixa

Aes geradoras de possveis cursos alternativos ou excees

Env iar a lista de itens adquiridos ao SCE

Abater itens do estoque

Env iar total para faturamento Registrar faturamento Exibir a mensagem Compra encerrada com sucesso no monitor

Figura A.21: Soluo para a especicao na forma grca do caso de uso Registrar Compra Parte II.

A.8. EXERCCIOS DO CAPTULO ??, PGINA ??:

225

pedido dado seu nmero em toda a coleo de clientes. Como consequncia, a classe ColecaoDeClientes repassaria classe Cliente as responsabilidades de indexar os pedidos de um cliente e de localizar um pedido na coleo de pedidos do cliente. ii. criar uma classe ColecaoDePedidos associada classe Pedido (com multiplicidade 1 para muitos), que indexa os pedidos feitos ZYX, e fazer uma busca nessa coleo, como zemos com os clientes quando queramos localizar um cliente pelo seu cdigo. Nesse caso, a classe ColecaoDePedidos teria as responsabilidades de indexar pedidos e de prover mecanismos de pesquisa na coleo de pedidos. b) Com o pedido localizado, buscamos os dados do cliente que o colocou para compor o cabealho do pedido. A navegabilidade de Pedido para Cliente (seta na ponta da associao) indica essa responsabilidade da classe Pedido, que deve contar com operaes e atributos para realizla. Pedido tambm precisa imprimirCabecalhoPedido, com os dados do cliente. c) Buscamos agora os dados dos itens que compem o pedido. Para isso, a classe Pedido deve ter tambm a responsabilidade de indexar, localizar e obter os itens que compem um pedido. O pedido localizado deve, para cada item de pedido, invocar a operao de obteno dos dados do item, que vm completos, incluindo a descrio e preo unitrio que no fazem parte dos atributos do item e sim do produto correspondente. Essa operao poderia ter a seguinte assinatura: obterDadosItemPedido (ordem, quantidade, descricao, precoUnitario), sendo todos parmetros de sada. Com esses dados de todos os itens, a classe Pedido precisa classicar os itens pela ordem, imprimi-los e calcular o total do pedido. d) Para executar a operao obterDadosItemPedido, o item de pedido precisa obter da classe Produto a descrio e o preo unitrio do item. Solicitar esses dados uma responsabilidade da classe ItemDePedido, que a delega classe Produto. Informar esses dados uma responsabilidade da classe Produto. Resumimos, na Tabela A.4, as responsabilidades de cada classe na realizao dessa colaborao. Consideramos a alternativa a do passo 1. Cabem, ainda, alguns comentrios importantes. A Tabela A.4 no faz parte de qualquer metodologia para elaborao de DSs. Ela serve apenas para consolidar o que discutimos neste exerccio. A resposta que demos acima uma das possveis respostas. Raciocinar e especicar correta e completamente uma colaborao na forma textual no

226

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Tabela A.4: Responsabilidades de cada classe na realizao da colaborao do Exerccio 2. Classe

ColecaoDeClientes Cliente

Pedido

ItemDePedido Produto

Responsabilidade Localizar um pedido por seu nmero Indexar os pedidos Localizar um pedido por seu nmero Prover os dados do cliente Obter os dados do cliente Imprimir o cabealho do pedido Obter os dados dos itens de pedido Imprimir os dados dos itens de pedido e totaliz-los Prover os dados (completos) do item Solicitar descrio e preo unitrio a Produto Prover descrio e preo unitrio do produto

uma tarefa simples nem desejada num projeto. Felizmente, os diagramas de sequncia ajudam na tarefa de atribuir responsabilidades e de descobrir operaes, o que voc ver na Seo 9.5. Deixaremos a elaborao de um diagrama to abrangente para um exerccio do prximo captulo, quando tivermos apresentado mais elementos da notao grca da UML. importante observar que as responsabilidades que relacionamos so apenas parte da soluo completa. S teremos a soluo completa quando considerarmos todos os cenrios de todos os casos de uso do sistema. 3. Como soluo do exerccio elaboramos o diagrama da Figura A.22. Conforme vimos, a ordem dos objetos na dimenso horizontal no relevante, ou seja, posso colocar Maria esquerda de Paulo, conforme o diagrama da Figura A.23 sem alterao da soluo. Repare que mantivemos a ordem e as origens e destinos das chamadas na dimenso vertical, porque a colaborao foi especicada no enunciado dessa forma.

A.9 Exerccios do Captulo 10, pgina 179:

1. A soluo dada consta da Figura A.24. Supor que no existe quantidade disponvel em estoque signica que o prazo de fornecimento no imediato, ou seja, necessria a obteno do valor do atributo prazoFornecimento da classe Fornecimento.

A.9. EXERCCIOS DO CAPTULO ??, PGINA ??:

227

Joo:Presidente

Paulo:DiretorFinanceiro

Maria:GerenteFaturamento

Pedro:GerenteOperacoes

lucroLiquido() receitas()

despesas()

lucroLiquido()

Figura A.22: Uma soluo para o clculo do Lucro Lquido da ZYX.

Joo:Presidente

Maria:GerenteFaturamento

Paulo:DiretorFinanceiro

Pedro:GerenteOperacoes

lucroLiquido() receitas()

despesas()

lucroLiquido()

Figura A.23: A mesma soluo que a da Figura A.22 para o clculo do Lucro Lquido da ZYX, porm com outra ordem de apresentao dos objetos na dimenso horizontal.

228

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

umItem:ItemDePedido

oProduto:Produto

umFornecedor:Fornecedor

oFornecimento:Fornecimento

getPrazoFornecimento() :int getPrazoFornecimento(codigoProduto:int) :int

localizarProduto(codigoProduto:int) :Produto getPrazoFornecimento() :int : prazoFornecimento : prazoFornecimento

Figura A.24: Uma soluo de colaborao para obteno do prazo de entrega de um pedido feito ZYX.

Iniciando, portanto, no item de pedido para o qual se deseja o prazo de fornecimento, solicita-se o prazo de fornecimento ao objeto produto associado (s existe um produto associado a um item de pedido). Como o produto "no sabe" qual esse prazo (isso atributo da classe Fornecimento), o objeto produto repassa a consulta ao primeiro fornecedor da lista de fornecedores, que so em qualquer nmero. O fornecedor, ento, repassa a consulta ao objeto da classe Fornecimento associado. Nessa situao, no entanto, como fornecedores fornecem um nmero possivelmente grande de produtos, uma pesquisa por cdigo de produto precisa ser feita para localizao do produto para o qual precisamos do prazo de entrega. Para isso, foi feita a autodelegao da pesquisa do produto no objeto umFornecedor, que retorna uma referncia ao produto localizado (objeto oFornecimento). Por meio dessa referncia, obtemos o prazo de entrega, invocando a operao getPrazoFornecimento desse objeto. O retorno da informao feito nos sentidos opostos s chamadas. As operaes descobertas e seus parmetros constam do DS. Precisaramos, agora, atualizar o diagrama de classes, colocando essa informao no terceiro compartimento das classes que instanciaram os objetos usados no diagrama. Quanto s visibilidades, todas as chamadas so pblicas, com exceo da autodelegao localizarProduto, que privada, porque no precisa ser pblica.

umItem:ItemDePedido

oProduto:Produto

umFornecedor:Fornecedor

oFornecimento:Fornecimento

qtdEstoque= getQtdEstoque() :int

alt [qtdEstoque < quantidade] getPrazoFornecimento() :int loop [para todos os fornecedores do produto] preco= getPreco(codigoProduto:int) :value

localizarProduto(codigoProduto:int) :Produto getPreco()

Sempre que um preo for menor que o preo mnimo, a referncia ao fornecedor deve ser armazenada para recuperao futura.

A.9. EXERCCIOS DO CAPTULO ??, PGINA ??:

precoMinimo= min(precoMinimo:value, preco:value) :value

getPrazoFornecimento(codigoProduto:int) :int

localizarProduto(codigoProduto:int) :Produto

getPrazoFornecimento() :int : prazoFornecimento : prazoFornecimento

[else] retirarEstoque(quantidade:int)

Figura A.25: Uma soluo mais completa de colaborao para obteno do prazo de entrega de um pedido feito ZYX.

3. Elaboramos o diagrama da Figura A.26 como soluo do exerccio.

2. O DS de nossa resposta para o Exerccio 1 evolui para o diagrama da Figura A.25. Os segmentos do quadro alt especicam as situaes alternativas de haver e de no haver a quantidade necessria do item em estoque. O quadro loop verica o preo mnimo, considerando todos os fornecedores do mesmo produto.

229

230

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Cliente

formulrio de especificao de Pedido

controleEntradaPedido

colecaoClientes

umCliente:Cliente

oCatalogoDeProdutos

oProduto:Produto

exibirTelaAutenticacao() login/senha()

verificarLoginSenha(login:string, senha:string) verificarLoginSenha(login:string, senha:string)

loop [para todos os clientes, at ser validado ] verificarLoginSenha(login:string, senha:string)

clienteValido= :{true, false}

alt [clienteValido = false] "login/senha inexistente"()

[clienteValido = true]

getNome(nomeCliente:string)

getEndereco(enderecoCliente:string) exibeDdosCliente(nomeCliente:string, enderecoCliente:string) oNovoPedido:Pedido create

loop [para todos os itens de pedido do pedido] exibirCamposEntradaItensPedido()

codigo e quantidade()

criaItemPedido(codigo:int, quantidade:int, descr:string, prUnitario:value) criaItemPedido(codigo:int, quantidade:int, descr:string, prUnitario:value) oNovoItem:ItemDePedido create getPuDescricao(codigi:int, descricao:string) localizarProduto(cofigo:int)

getPuDescricao(pU:value, descricao:string)

calculaPrTotal(pU:value, qtd:int) :value

:descrio, preo item, valor pedido

Figura A.26: Uma soluo para a colaborao do caso de uso Efetuar Pedido.

A.9. EXERCCIOS DO CAPTULO ??, PGINA ??: No diagrama de sequncia da Figura A.26 destacamos os seguintes aspectos:

231

todo o diagrama foi colocado em um quadro com rtulo sd, o que permite que o diagrama seja referenciado (chamado) em outro diagrama qualquer por meio de um operador ref; os atores so tambm aqui representados por "bonequinhos"; criamos uma classe de interface atravs da qual o ator interage com o sistema; o objeto de interface delega quase toda a responsabilidade pela lgica do sistema ao objeto controlador; as operaes exibirTelaAutenticacao e exibirCamposEntradaItensPedido so, na realidade, sequncias de operaes de exibio de campos no formulrio, correspondendo invocao de construtores de objetos dos tipos rtulo, caixa de texto e boto com seus correspondentes contedos; optamos por solicitar ao recm-criado objeto oNovoPedido, por meio do objeto controlador, a criao do item do pedido. Este, por sua vez, cou incumbido de obter os dados do produto. Isso facilita a denio da associao entre o pedido e seus itens e os produtos aos quais se referem; adicionamos ao diagrama de classes uma classe CatalogoDeProdutos associada classe Produto (com multiplicidades 1 para muitos) para index-los, facilitando a busca pelo cdigo e a obteno dos seus atributos. Como voc sabe, preciso retornar ao diagrama de classes para adicionar as classes que criamos, as operaes que descobrimos e suas respectivas visibilidades. As classes de interface e controladoras aparecem, no diagrama de classes, relacionadas entre si e s demais classes de conceito e de projeto por meio de relacionamentos de dependncia; o formulrio depende do (ou usa o) controle que depende da coleo de clientes e dos clientes. Sendo assim, as classes e seu relacionamentos a serem adicionados ao diagrama de classes j existente o da Figura A.27: A descrio do caso de uso que elaboramos no est completa nem tivemos a inteno de deix-la da melhor forma possvel. As validaes dos dados de entrada, por exemplo, no foram feitas por questes de simplicao do diagrama. Nosso objetivo foi elaborar uma soluo que permitisse exercitar os conceitos apresentados em um diagrama com complexidade visual dentro dos limites.

232

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Formulario

ControleEntradaPedido + + verificarLoginSenha() criarItemPedido()

Cliente + + + endereco telefone verificarLoginSenha() getNome() getendereco()

singleton ColecaoClientes * 1 + verificarLoginSenha()

Figura A.27: Relacionamento de dependncia entre as classes de interface (formulrio), controladora e conceitual resultantes da realizao do caso de uso Efetuar Pedido.

A.10 Exerccios do Captulo 11, pgina 196:

1. O diagrama de atividade que especica gracamente o caso de uso encontra-se na Figura A.28. No DA esto especicadas apenas as aes do sistema que esto no trecho descrito. Cabe agora especicar, como quadros de interao, cada uma das aes deste DA. O diagrama de viso geral da interao ca, portanto, como nas Figuras A.29 e A.30. Note que, conforme proposto no enunciado do exerccio, usamos os trechos de colaborao do DS da soluo que apresentamos para o exerccio trs da Seo 10.11 (Figura A.26). Alguns aspectos importantes do diagrama de nossa soluo merecem ser

A.10. EXERCCIOS DO CAPTULO ??, PGINA ??:

233

Exibir os campos para autenticao do cliente e o boto Ok

Buscar a descrio do produto e o preo unitrio

Autenticar cliente

[cliente no autenticado] Exibir a descrio do produto, o preo unitrio

[cliente autenticado]

Obter nome do cliente e endereo e os exibir no topo do formulrio; Calcular o preo total do item e o exibir

Informar que login/senha no constam do cadastro

Atualizar o v alor total do pedido

Exibir os campos para fornecimento do cdigo do produto, a quantidade desej ada e os botes Adicionar ao Carrinho de Compras e Finalizar Pedido

[h outro produto no pedido]

[else] continua...

Figura A.28: Diagrama de atividade parcial especicando os passos do caso de uso Efetuar Pedido.

234

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

sd Exibir os campos para autenticao do cliente formulrio de especificao do pedido controleEntradaPedido

exibirTelaAutenticacao()

sd Autenticar Cliente formulrio de especificao do pedido controleEntradaPedido colecaoClientes umCliente

:Cliente

login/senha()

verificarLoginSenha(login:string, senha:string) verificarLoginSenha(login:string, senha:string)

loop [para todos os clientes, at ser validado] verificarLoginSenha(login:string, senha:string)

[cliente autenticado]

[cliente no autenticado]

sd Obter nome do cliente e endereo e os exibir no topo do formulrio formulrio de especificao do pedido controleEntradaPedido umCliente

sd Informar que login/senha no constam do cadastro formulrio de especificao do pedido controleEntradaPedido

"login/senha inexistente"() getNome(nomeCliente:string)

getEndereco(enderecoClienre:string) exibeDados(nomeCliente:string, enderecoCliente:string) oNovoPedido:Pedido create

sd Adicionar Produtos formulrio de especificao do pedido

1
controleEntradaPedido oCatalogoDeProdutos oProduto:Produto

Cliente loop

[para todos os itens de pedido do pedido]

Figura A.29: Primeira parte do diagrama de viso geral da interao especicando as aes do DA da Figura A.28.
codigo e quantidade() criarItemPedido(codigo:int, quantidade:int, descr:string, prUnitario:value) oNovoItem:ItemDePedido create getPuDescricao(codigo:item, descricao:string) localizarProduto(codigo:int)

exibirCamposEntradaItensPedido()

getPuDescricao(pU:value, descricao:string)

calcularPrTotal(pU:value, qtd:int) :value

:descricao, preco item, valor pedido

sd Obter nome do cliente e endereo e os exibir no topo do formulrio formulrio de especificao do pedido controleEntradaPedido umCliente

sd Informar que login/senha no constam do cadastro formulrio de especificao do pedido controleEntradaPedido

"login/senha inexistente"() getNome(nomeCliente:string)

getEndereco(enderecoClienre:string)

A.10. EXERCCIOS DO CAPTULO ??, PGINA ??:

exibeDados(nomeCliente:string, enderecoCliente:string) oNovoPedido:Pedido create

235

sd Adicionar Produtos formulrio de especificao do pedido controleEntradaPedido oCatalogoDeProdutos oProduto:Produto

Cliente loop

[para todos os itens de pedido do pedido] exibirCamposEntradaItensPedido()

codigo e quantidade()

criarItemPedido(codigo:int, quantidade:int, descr:string, prUnitario:value) oNovoItem:ItemDePedido create getPuDescricao(codigo:item, descricao:string) localizarProduto(codigo:int)

getPuDescricao(pU:value, descricao:string)

calcularPrTotal(pU:value, qtd:int) :value

:descricao, preco item, valor pedido

Figura A.30: Segunda parte do diagrama de viso geral da interao especicando as aes do DA da Figura A.28.

destacados: a primeira mensagem em um quadro partiu do objeto que recebeu o controle no quadro anterior no uxo; um diagrama de viso geral da interao ca mais "espalhado" no papel que seu equivalente DS, mas seu entendimento mais fcil porque a estrutura de controle de mais alto nvel ca fora dos quadros de interao; quadros de interao mais simples produzem diagramas mais fceis de ser interpretados. No entanto, decidimos elaborar um nico quadro contendo as aes de fornecimento dos itens do pedido para aproveitar o quadro loop. Isso s foi possvel porque a interao dentro do quadro loop no to complexa, inclusive porque no h condies alternativas nesse trecho de colaborao.

236

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

2. A Figura A.31 mostra o diagrama de pacotes que elaboramos. Poderamos, claro, ter colocado um pacote por diagrama (um pacote em cada folha de papel). S no zemos isso para mostrar que/como podemos fazer e porque, mesmo com todos os pacotes no mesmo diagrama e as classes representadas dentro deles, ainda conseguimos ler os elementos textuais. Isso, no entanto, no possvel na maioria dos casos, porque os diagramas so usualmente bem complexos (alis, uma das razes para usar pacotes para resolver o problema da complexidade visual dos diagramas). Separando os pacotes em diagramas diferentes, bom que tenhamos um diagrama, que tipicamente colocamos no incio, que mostra uma viso de mais alto nvel. A Figura A.32 ilustra o que falamos, completando nossa atividade. 3. O diagrama de distribuio est representado na Figura A.33. No h muito o que discutir a respeito dessa soluo que demos, exceto o fato de que usamos os mesmos relacionamentos de dependncia que apresentamos na soluo do exerccio 2. Como componentes apresentam e usam interfaces para comunicao entre eles, o relacionamento de dependncia poderia ser substitudo pela notao da interface fornecida e exigida da Figura 11.6, considerando que a dependncia corresponde interface exigida e vice-versa, conforme a Figura 11.7.

Controle de Pedidos Controle de Clientes

Controle

Pedido Cliente 1 + + + 1 + verificarLoginSenha() verificarLoginSenha() * getNome() getendereco() singleton ColecaoClientes endereco telefone + +

ControleEntradaPedido verificarLoginSenha() criarItemPedido()

ItemDePedido 1 1..* * ClientePF * Viso nome razaoSocial contato ClientePJ ordem quantidade

numero enderecoEntrega tipoPagamento * prazoEntrega

calculaPrTotal() criaItemPedido()

Formulario Controle de Estoque 1 Produto ItemDeReposicaoDeEstoque 1 * ordem quantidade 1..* + * * 1 singleton CatalogoDeProdutos + getPuDescricao() localizaProduto() getPuDescricao() * 1 Funcionario PedidoDeReposicaoDeEstoque dataColocacao 0..1 nome +representanteDeVendas

A.10. EXERCCIOS DO CAPTULO ??, PGINA ??:

Controle de Fornecedores

codigo descricao precoUnitario qtdEstoque

RH

Figura A.31: Classes da ZYX agrupadas em pacotes.

Fornecimento prazoFornecimento precoFornecimento

Fornecedor

237

238

APNDICE A. SOLUES DOS EXERCCIOS PROPOSTOS

Controle de Pedidos

Controle de Clientes

Controle

Controle de Estoque

RH

Viso

Controle de Fornecedores

Figura A.32: Diagrama de pacotes de classes da ZYX.

A.10. EXERCCIOS DO CAPTULO ??, PGINA ??:

239

Serv idor de Aplicao

Controle de Pedidos

Controle de Clientes

Controle

Cliente Web HTTP Controle de Estoque RH Viso

Controle de Fornecedores

sockets

SGBD

Figura A.33: Diagrama de distribuio dos sistemas da ZYX.

APNDICE

M INIMUNDOS C OMPLETOS
Nesse apndice apresentamos alguns minimundos completos para a elaborao dos modelos UML, conforme haja disposio e disponibilidade de tempo do leitor.

B.1 Peixaria Q-Sereia

A peixaria Q-Sereia teve suas vendas aumentadas substancialmente quando passou a fornecer pescado limpo para grandes restaurantes de frutos do mar no Rio de Janeiro. H algum tempo resolveu entrar no ramo da pesca, adquirindo algumas traineiras e, eventualmente, comprando a produo de embarcaes de terceiros. O Sr. Manoel, proprietrio da peixaria, procurou nossa empresa, a Cooperativa de Competentes Engenheiros de Software CCE-S , com a nalidade de contratar o desenvolvimento de um sistema computadorizado para controle de suas operaes. Inicialmente necessrio desenvolvermos o Sistema de Controle da Produo e Vendas SCPV , conforme descrevemos a seguir. necessrio que o SCPV armazene a matrcula na Capitania dos Portos e a capacidade em toneladas de qualquer embarcao. Para as embarcaes prprias, necessrio que o sistema armazene, tambm, a capacidade em litros do tanque de diesel, alm do status da mesma (situaes possveis so descritas ao nal). Para as embarcaes de 3os., apenas uma referncia empresa proprietria necessria (existe um cadastro de empresas terceiras mantido pelo Sistema de Contas a Pagar que consultado no cadastramento de uma nova embarcao de terceiros). 241

242

APNDICE B. MINIMUNDOS COMPLETOS

Embarcaes (quaisquer) saem em misses de pesca para as quais so necessrios os registros da data de sada, data prevista de chegada, data da efetiva chegada de volta ao porto. Os registros de suas produes so feitos no sistema pelo Auxiliar Administrativo quando as embarcaes voltam de suas misses, sendo compostos de itens de produo (zero ou mais), dos quais constam a espcie de pescado e o peso bruto. As espcies so cadastradas no SCPV atravs de seus nomes populares. Do cadastro de espcies constam, tambm, o percentual estimado de perda, os preos por quilo bruto e limpo de cada espcie. O Capito possui um nmero de registro de habilitao na Capitania. Tambm como parte do cadastramento de uma nova misso, todos os tripulantes (inclusive o Capito) que a realizaro so relacionados. As misses so denidas no sistema na seguinte seqncia: o Auxiliar Administrativo cadastra a data de sada, data prevista de chegada. Em seguida informa a matrcula da embarcao na Capitania dos Portos. Associa os tripulantes (pr-cadastrados, quando funcionrios da Q-Sereia) nova misso. Se a embarcao ainda no se encontra cadastrada, esse o momento de faz-lo. Para embarcaes de terceiros necessrio o cadastramento de todos os tripulantes, fornecendo-se seus nomes e telefones em terra para eventual necessidade de contato. A chegada de uma misso ao porto informada pelo Capito, via rdio, ao Auxiliar Administrativo para que este informe a data/hora do m da misso ao SCPV. A embarcao passa a ser, ento, descarregada, quando o Capito coordena a separao e peso por espcie do produto da pesca, preenchendo um formulrio em duas vias com esses dados (alm da data/hora da chegada ao porto). Os dados da produo so conferidos pelo Encarregado do Estoque que rubrica o formulrio aps a conferncia. O Capito dirige-se, ento, ao escritrio da peixaria no porto e entrega o dirio de bordo (no caso de embarcaes prprias da peixaria), juntamente com as duas vias do formulrio. O Auxiliar Administrativo, aps vericar o preenchimento correto do formulrio, carimba "Recebido" na segunda via, entregando-a ao Capito para seu controle. A primeira via usada pelo Auxiliar para informar os dados da produo ao SCPV e para posterior arquivamento. No incio do cadastramento da produo o sistema dever solicitar a licena da embarcao, que j identicar se a embarcao prpria (o que acontece na maioria das vezes) ou de terceiros. O SCPV passa a solicitar os dados da produo. Ao nal do cadastramento da produo o sistema dever "passar", automaticamente, os dados da mesma aos Sistemas de Controle de Estoque (SCE), ao de Folha de Pagamento (SFP), se a embarcao prpria (parte do pagamento da tripulao dos barcos prprios da Peixaria funo da produo), ou de Contas a Pagar (SCP), se embarcao de terceiros, pois parte do pagamento pelo aluguel do barco/tripulao s terceiras funo da produo.

B.2. EMPRESA 5-E

243

tambm tarefa do Auxiliar o cadastramento no SCPV dos dados das espcies de pescado, usados tambm pelo sistema de contas a pagar para pagamento dos terceiros. A informao da perda mdia pode ser alterada pelo Sistema de Controle de Estoque (SCE), baseado nas quantidades de cada espcie que entram e nas quantidades que so efetivamente estocadas aps a limpeza. Os Vendedores devem dispor de uma rotina de cadastramento de vendas, que verica as quantidades disponveis em estoque, verica se os restaurantes compradores esto na "lista negra" e que processa a venda, solicitando ao SCE a baixa no estoque e criando novo compromisso no Contas a Receber. A lista negra de restaurantes inadimplentes mantida pelo prprio Sr. Manoel, como outra funcionalidade do sistema SCPV. Um aviso enviado ao Contas a Receber quando um restaurante colocado/retirado na/da lista negra. Qualquer embarcao prpria da Q-Sereia pode estar em uma das seguintes situaes: 1. disponvel (quando est pronta, aguardando nova misso), 2. em misso, 3. descarregando (aps chegada ao porto), 4. em avaliao (aps ser descarregada, quando feita uma limpeza e avaliao para vericao da necessidade de reparos antes de uma nova misso), e 5. em reparos (quando, na avaliao, constatada a necessidade de reparo(s)). OBS: Todos os sistemas da Q-Sereia se comunicam/comunicaro diretamente atravs da rede interna e as mensagens so trocadas usando-se um protocolo que garante e informa os seus recebimentos corretos, ou seja, todos os sistemas esto/estaro online.

B.2 Empresa 5-E

Fomos contratados para o desenvolvimento dos sistemas necessrios informatizao das atividades administrativas da Empresa de Engenharia Eletroeletrnica Excelncia (5E) Ltda. Para tal, ser preciso que desenvolvamos os sistemas de Gesto de Pessoal (SRH), de Controle de Fornecedores e Estoque (SCFE), de Controle Financeiro (SCF) que englobar contabilidade, aplicaes nanceiras e os controles do "contas a pagar" e do "contas a receber" alm do Sistema de Gesto de Contratos SGC , que o mais

244

APNDICE B. MINIMUNDOS COMPLETOS

urgente e dever ser o primeiro a ser desenvolvido por completo. Todos esses sistemas operaro de forma integrada, usaro a tecnologia web (servidores e Clientes web) e se comunicaro, exclusivamente, atravs de trocas automticas em tempo real de mensagens eletrnicas em XML (todos os sistemas estaro perfeitamente integrados). O SGC descrito a seguir. Os itens a seguir descrevem as funcionalidades do sistema e os demais itens descrevem os principais aspectos estruturais e dinmicos do mesmo. 1. Os Auxiliares Administrativos (Auxiliares) da 5E podero cadastrar contratos e, durante o cadastramento dos mesmos, podero incluir os dados de novos Clientes. Caso os dados de um Cliente j estejam disponveis no sistema, os Auxiliares simplesmente faro a associao do novo contrato ao Cliente j existente. Como uma funcionalidade isolada do sistema, dever ser possvel o cadastramento de Clientes (Clientes em potencial, sem que eles venham a ser, de imediato, associados a qualquer contrato). No nal do cadastramento de um contrato ser escolhido pelo sistema um Gerente de Contrato (Gerente) num esquema de escalonamento round robin. O Gerente escolhido avisado pelo sistema (dever ser feita a tentativa de exibir-se uma janela popup na estao de trabalho do Gerente, se ele estiver "logado" no SGC, o que demandar a conrmao pelo mesmo) para que se encarregue do "fechamento" (formalizao /celebrao) do contrato. 2. O processo de cadastramento de um contrato ocorre da seguinte forma: o sistema solicita ao Auxiliar o CPF ou CNPJ do Cliente. O sistema busca e exibe, quando j existentes no cadastro, os dados do Cliente para conrmao pelo Auxiliar (o que pode ou no acontecer). Caso os dados no estejam cadastrados, o que mais comum, essa a hora de inform-los. O sistema, ento, solicita o escopo principal do contrato (se de eletricidade ou de eletrnica, se de projeto ou de manuteno) e os demais dados (vide item IX). O Auxiliar passa a informar a durao do contrato, o valor e, caso o contrato seja de manuteno (caso mais comum), o local de prestao dos servios. Antes ainda do nal do cadastramento de um contrato, o mesmo ser associado a um nico Gerente de Contrato (funcionrio da 5E), conforme j mencionamos anteriormente. Como ltima etapa do cadastramento de um contrato, o sistema exibir o identicador nico do contrato (Nmero do Contrato) obtido automaticamente para referncias futuras ao mesmo. 3. Os contratos cadastrados e ainda no fechados sero entendidos como "minutas de contratos" e, nesse estado, podero ser alterados a qualquer momento pelos Auxiliares ou seus Gerentes. 4. Dever existir uma outra funcionalidade do SGC para informar o fechamento de um contrato j cadastrado, quando fornecida a data de incio (a durao j

B.2. EMPRESA 5-E

245

est no corpo do contrato), so impressas duas cpias do mesmo e emitido um carn de pagamento, consistindo de um ou mais boletos de pagamento bancrio. Contratos fechados no podero ser alterados. O fechamento de um contrato feito pelo Gerente de Contrato a ele associado, que poder, a qualquer momento, consultar em tela e imprimir cpias dos contratos pelos quais responsvel. 5. Aps a associao de contrato a um Gerente, este poder adicionar ao contrato notas (comentrios/observaes) em qualquer nmero. Um comentrio poder estar associado a uma data/hora para que o Gerente o receba, como um lembrete pelo sistema, na data e hora especicados. 6. Os diretores da 5E podero executar no sistema as mesmas funcionalidades que os Gerentes de Contrato. Adicionalmente podero informar o cancelamento de um contrato (atividade essa que ser exclusiva dos diretores) juntamente como o motivo do cancelamento. 7. s 8:00h de todo incio de semana, o sistema dever produzir automaticamente uma relao impressa de todos os contratos ainda em aberto (que ainda no foram fechados). 8. importante que, quando um contrato se tornar vencido, uma comunicao do fato seja feita ao respectivo Gerente. 9. Com relao aos dados dos contratos, estes podero ser de projeto ou de manuteno. Qualquer contrato ter sua data de incio e durao em meses, alm do escopo, que pode ser "ELE" (eletricidade) ou "ELO" (eletrnica). Contratos de projeto possuiro uma descrio e contratos de manuteno possuiro a relao dos equipamentos cobertos. Equipamentos cobertos sero especicados atravs da marca, modelo e nmero de srie. Um contrato estar associado a um nico Cliente. Clientes possuiro qualquer nmero de contratos no SGC. Um contrato ser associado a um nico Gerente. Gerentes podero gerir qualquer nmero de contratos. 10. Clientes so pessoas fsicas ou jurdicas. No primeiro caso, ser necessrio o armazenamento do nome, endereo, telefone e o CPF; no segundo caso ser necessrio o armazenamento do endereo, um nome de contato, o telefone, a razo social e o CNPJ. 11. Para o cancelamento de um contrato, ser necessrio que a data/hora e os motivos do cancelamento quem registrados no sistema, alm de uma referncia ao Diretor que cancelou o contrato.

246

APNDICE B. MINIMUNDOS COMPLETOS

12. Um contrato poder estar "Aberto", situao em que se encontrar logo aps o cadastramento. Passar a "Fechado" quando o Cliente e a 5E concordarem com os termos e celebrarem o acordo. Se tornar "Vencido", quando ndo o prazo de durao, e "Cancelado", quando o cancelamento for informado ao SGC por um Diretor. O cancelamento s poder ocorrer enquanto o contrato vigorar. possvel que, atravs de um processo de renovao, um contrato vencido possa voltar a vigorar.

B.3 Sistema de Controle de Ordens de Servio Refrigerao ManutAir

A empresa ManutAir Ltda. tem como atividade a prestao de servios de manuteno preventiva e corretiva de equipamentos de condicionamento de ar. O quadro de funcionrios da empresa composto de tcnicos em ar condicionado e pessoal administrativo. A empresa possui contratos com diversos Clientes, contratos esses que podem ser de dois tipos: contratos com cobertura total (peas e mo-de-obra) ou contratos com cobertura parcial (mo-de-obra somente). Alm disso, a empresa efetua manuteno corretiva em equipamentos no cobertos por nenhum contrato prexistente. Nesse caso criado um contrato, chamado avulso, de cobertura total (no altervel um para cada equipamento a ser reparado), de durao de 90 dias para cobertura das peas trocadas e mo-de-obra envolvidos no reparo, conforme determina o PROCON. Quando um Cliente fecha um novo contrato, ele deve informar ao Atendente a razo social, endereo, CNPJ, nome e telefone do responsvel, para o caso de Cliente PJ, ou nome, endereo, telefone e CPF, para o caso de Cliente PF. O sistema busca e exibe os dados do Cliente (tipicamente os dados j se encontram cadastrados no sistema). Caso os dados do Cliente ainda no se encontrem cadastrados, esse o momento de faz-lo. Em ambos os casos o Cliente informa, tambm, a lista dos equipamentos cobertos pelo contrato (atravs de suas marca+modelo+nmero de srie), a data de incio da vigncia e o prazo de durao em meses. Os contratos, aps cadastrados, recebem do sistema um nmero. No fechamento de um contrato no avulso tambm emitido um carn de pagamento para o Cliente, correspondente s parcelas mensais a serem pagas durante a vigncia do contrato. Tambm no caso de contrato no avulso, a lista de equipamentos cobertos pode ser alterada com a incluso ou excluso de novos equipamentos. feito, se cabvel, o correspondente reajuste do valor das cotas mensais. Os equipamentos includos esto sujeitos carncia, a critrio do Supervisor. No caso de contratos

B.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

247

avulsos, o pagamento feito atravs de um boleto bancrio, que emitido aps a concluso do servio. Em ambos os casos, o banco envia ManutAir a relao impressa dos pagamentos recebidos a cada dia para que seja feita a conciliao bancria pelo Atendente. Os Clientes, quando necessitam de algum atendimento, ligam para o nmero telefnico de solicitao de servio. As chamadas so recebidas pelos Atendentes que fazem a abertura das Ordens de Servio (OS), deixando-as com status "Aberta". Para tal, os Atendentes solicitam ao Cliente o nmero do contrato (que tipicamente j est cadastrado no sistema), o equipamento que necessita reparo (marca+modelo+nmero de srie), o endereo onde este se encontra e uma breve descrio do problema. Caso o equipamento no esteja coberto por nenhum contrato, preparada uma OS especial (correspondente a um contrato avulso) para que se faa um atendimento corretivo. O Supervisor Tcnico dispor de uma funcionalidade para consulta e alocao de novas OS abertas aos tcnicos de campo, o que feito num esquema de rodzio. Ao fazer a alocao de uma OS a um tcnico o Supervisor anota o dia, a hora marcada para a visita do Tcnico, deixando a OS com status "Em Andamento". Nessa oportunidade emitida uma cpia impressa da OS que colocada na caixa de entrada do tcnico. Em casos de urgncia o Supervisor contata os tcnicos via Nextel. Os Tcnicos realizam as visitas aos Clientes, onde prestam o atendimento solicitado que, normalmente, encerrado na visita inicial. Aps um atendimento, o tcnico entra em contato com o Supervisor e informa, via Nextel, a situao da OS. Caso seja necessria a troca de peas, o Supervisor solicita as peas ao estoque atravs de uma funcionalidade do sistema. A OS assume, ento, o status "Aguardando Pea". Quando as peas cam disponveis para a OS, o Estoquista informa o fato no sistema, levando a OS ao estado de "Material Disponvel". Atravs de uma funcionalidade de consulta a OSs pendentes, o Supervisor informado da disponibilidade de pea para que possa marcar uma nova visita ao Cliente. Quando a nova visita marcada, a OS reativada (retornando ao status "Em Andamento") e uma nova comunicao impressa ao Tcnico gerada. Aps a concluso do servio, o Tcnico informa (via Nextel) o fechamento da OS ao Supervisor, informando o total de horas gastas no reparo, bem como o material utilizado. A OS assume, ento, o status "Concluda" quando, se necessrio, iniciada sua cobrana. Aps o recebimento do pagamento, a OS passa para "Encerrada". No caso de OS com cobertura total pelo contrato, ao ser concludo o servio, a OS automaticamente encerrada. A empresa recebe de cinquenta a setenta chamados por dia e trabalha com um Supervisor, dois Atendentes, quinze Tcnicos de campo e um Estoquista.

248

APNDICE B. MINIMUNDOS COMPLETOS

O dono da empresa deseja dispor de um sistema informatizado que permita a gesto dos dados dos contratos e que controle todas as etapas de uma chamada, desde o momento do registro at a nalizao do servio.

B.4 Sistema de Acompanhamento de Entregas da Rapido Espacial

A empresa de vendas pela Internet LatinoamericanasPontoCom (LAPC) possui um sistema de vendas com rastreamento detalhado dos passos dos pedidos feitos por seus clientes enquanto os pedidos se encontram em suas dependncias. Entretanto, como efetua parcerias com empresas de entrega dos pedidos nas diversas praas do Pas, observa uma grande insatisfao de seus clientes quanto falta de informaes precisas das entregas aps os pedidos serem deixados nas transportadoras. A insatisfao consubstancia-as na grande quantidade de reclamaes e at mesmo no retorno das mercadorias LAPC. Em consequncia, a LAPC passou a se interessar por parcerias com empresas de entregas que disponham de sistemas informatizados que possam ser integrados eletronicamente ao sistema de vendas da LAPC, de forma a mant-la minuciosamente informada, para que ela possa repassar as informaes a respeito das entregas a seus clientes. Nossa cliente, a Rapido Espacial Ltda (RE), com liais nas principais cidades do Brasil e com rede de entregas que cobre quase a totalidade de municpios brasileiros uma das principais transportadoras da LAPC. A RE, interessada nessa "fatia" de mercado pois observa que essa tambm uma necessidade de vrias outras empresas de vendas pela Internet , contratou nossos servios para o desenvolvimento de um sistema que permita o acompanhamento detalhado de cada etapa de uma entrega, tanto por parte dos clientes compradores da LAPC quanto por parte da prpria LAPC. Em nossos entendimentos iniciais deniu-se uma relao de requisitos para o novo sistema que apresentamos ao longo do texto a seguir. Quanto comunicao LAPC/RE, toda e qualquer comunicao ligada ao negcio entre a LAPC e a RE ocorrer por via eletrnica (link de dados dedicado, ainda a ser instalado), utilizando um protocolo j denido pela LAPC. As mensagens trocadas entre a RE e LAPC (nos dois sentidos) sero usadas para atualizao em tempo real dos sites tanto da RE quanto da LAPC, permitindo que o cliente comprador acompanhe a entrega acessando, via Internet, qualquer um dos sites. As mensagens geradas durante o processo de entrega de um pacote so centralizadas no sistema da RE para posterior re-envio para a LAPC, caso necessrio. Quanto entrada de informaes no novo "Sistema RE de Acompanhamento de Entregas" SREAE , identicamos que as informaes podero chegar ao SREAE de

B.4. SISTEMA DE ACOMPANHAMENTO DE ENTREGAS DA RAPIDO ESPACIAL 249 trs formas: 1. provir diretamente da LAPC, atravs do mecanismo de mensagens j denido e apresentado acima; 2. provir dos computadores portteis dos funcionrios de campo da RE, que utilizam modernssima tecnologia de computao mvel, com comunicao via rdio com os escritrios da RE e com capacidade de leitura de cdigos de barras, ou 3. da forma convencional, atravs de entrada manual de dados, via teclado. As caractersticas e necessidades do SREAE so descritas a seguir. Quanto ao despacho inicial das mercadorias, diariamente, pela manh, a LAPC embala as compras em pacotes individuais, por destinatrio. Cada pacote recebe um identicador da forma LAPCPCTXXXX, onde XXXX um nmero de sequncia de pacote gerado pelo sistema j existente da LAPC. Os pacotes recebem uma etiqueta contendo as informaes relevantes para o despacho: o identicador (tambm em cdigo de barras), o nome, endereo e CEP do destinatrio, o nmero do lote (ver adiante), o nmero da nota scal e o peso e dimenses do pacote. Tambm axado ao pacote um envelope plstico contendo cpia da nota scal de venda dos produtos que vo no pacote. Um conjunto de pacotes (o lote, formado a critrio da LAPC) recebe um identicador de lote do tipo LAPCLOTXXXX, onde XXXX o nmero de sequncia de lote, gerado pelo sistema da LAPC. Cada lote deixado no balco da RE que ca junto ao setor de despacho de cargas da LAPC. Nesse momento a LAPC manda uma mensagem ao SREAE informando que existe um lote de mercadorias no depsito da RE a ser despachado, passando, tambm, os dados de cada pacote (as mesmas info. contidas em cada etiqueta). A RE confere a relao e, caso "OK", envia uma mensagem LAPC informando da aceitao do lote. Nesse momento tambm manda mensagens (uma para cada pacote) LAPC, informando que a entrega foi iniciada e que o pacote est em triagem no depsito de origem. Em funo do destino nal de cada pacote, o SREAE dever informar todos os despachos intermedirios que sero necessrios (roteamento). Essa funo no 100% automtica, ou seja, considerada como uma funo de auxlio ao Auxiliar Administrativo da RE na denio das rotas e despachos intermedirios. Em seguida inicia-se, efetivamente, a triagem inicial, quando os pacotes so separados manualmente por destinos imediatos (aeroporto tal, rodoviria tal, etc). Os funcionrios da RE responsveis pela entrega de cada novo lote nos respectivos

250

APNDICE B. MINIMUNDOS COMPLETOS

destinos imediatos, scaneiam os pacotes e, ao nal, transferem essas informaes ao SREAE. Passam, ento, ao embarque dos pacotes nas viaturas da RE para serem entregues em cada destino imediato. Ao fazerem a entrega de um lote, disparam uma mensagem de entrega de lote para a RE que, ao mesmo tempo que atualiza seu site, trata de mandar mensagens LAPC com o novo estado de cada pacote. O sistema envia, tambm, mensagens s localidades de destino (intermedirias e/ou nais) para que agendem a busca e, possivelmente, redespacho dos pacotes. Quanto aos despachos intermedirios das mercadorias, um pacote pode ser roteado muitas vezes (recebido de um transportador intermedirio e enviado a outro) at que chegue ao municpio destino, congurando-se, nesse caso, uma entrega local. Sempre que um pacote deixado em um destino (nal ou intermedirio) seu identicador passado RE para que produza uma atualizao no site e para que seja gerada uma mensagem para a LAPC. Ao sair para a coleta dos pacotes que esto chagando, o funcionrio local da RE j dispe da relao desses pacotes carregada em seus computadores portteis. Dessa relao consta, para cada pacote, seu destino imediato (redespacho ou entrega local). Se h pacote esperado que, porventura, no tenha sido recebido, necessrio que o SREAE receba uma mensagem de que o pacote extraviou, para que seja iniciada sua busca. Quanto s entregas locais, ao receber uma mercadoria para entrega no mesmo municpio ou logradouro prximo, o SREAE informa LAPC que uma entrega local foi iniciada. A(s) mercadoria(s) ser(o) armazenada(s) temporariamente para entrega nal no dia seguinte. iniciada a triagem nal, onde o roteiro de entrega dever ser denido com a ajuda de uma funo do sistema. O SREAE produzir uma relao dos bairros ou distritos das entregas, colocados segundo a sequncia denida com ideal, com as respectivas horas de entrega aproximadas. Essa informao tambm enviada LAPC. Entregas nas grandes cidades onde, tipicamente, a quantidade de entregas grande e onde o trnsito complicado, o que pode comprometer o planejamento inicial, as viaturas da RE so ligados via rdio s liais e transmitem, com a periodicidade programada, as suas coordenadas obtidas de um equipamento GPS (Global Positioning System Sistema de Posicionamento Global). Essa informao usada pelo sistema da RE para recalcular as horas previstas de entrega nos diversos bairros. Outras necessidades do SREAE, alm das descritas anteriormente, so: Funo para alterao da rota de um pacote: executada em qualquer ponto intermedirio da rota de um pacote, pelo funcionrio de campo da RE. Essa funo dever manter a consistncia com todos os demais passos para a entrega de um pacote.

B.4. SISTEMA DE ACOMPANHAMENTO DE ENTREGAS DA RAPIDO ESPACIAL 251 Funo para alterao em campo das rotas urbanas: executada em qualquer ponto de um trajeto urbano, basicamente em funo de imprevistos no trnsito (acidentes, obras urbanas, etc.) que possam alterar signicativamente o trajeto. Funo de manuteno dos dados da rede de cobertura RE: para manter a relao de municpios cobertos pela RE, da rotas pr-estabelecidas para eles e os respectivos custos de envio Funes de consulta aos municpios cobertos pela RE: para permitir a consulta, via Internet (para o pblico em geral) e via mensagem (para a LAPC), dos municpios cobertos e dos custos de envio. Funo de faturamento pelos servios de transporte prestados LAPC: mensalmente a RE emite fatura discriminada sos servios prestados LAPC. Funo de consulta ao histrico e situao de um pacote: para a obteno, via Internet, do histrico e da situao atual de um pacote. Isso pode ser feito a partir do nmero de identicao do pacote ou a partir do Nome e CPF do cliente comprador. Funo de suspenso da entrega de um pacote: a LAPC pode solicitar a suspenso de uma entrega a qualquer momento, o que implica que o pacote deve ser roteado de volta LAPC. A cobrana pelos servios da RE recalculada e o novo valor informado LAPC. Funo de alterao do endereo de entrega: a LAPC pode solicitar a alterao do endereo de uma entrega a qualquer momento, o que implica que o pacote deve ser re-roteado para o novo destino. A cobrana pelos servios da RE recalculada e o novo valor informado LAPC.

APNDICE

S OLUES DOS M INIMUNDOS C OMPLETOS

Neste apndice apresento as solues parciais para os minimundos do Apndice B. Os modelos apresentados aqui levam em considerao as discusses realizadas durante as inmeras vezes em que os exerccios foram feitos em sala de aula. Isso no impede, claro, que voc desenvolva uma soluo melhor, mais criativa e/ou concisa. Lembrese, no entanto, que a soluo de cada minimundo atm-se ao que solicitado no respectivo texto. Embora eu incentive os alunos a dar sugestes ao cliente durante o processo de levantamento1 , costumo dizer que quem manda, no nal das contas, quem patrocina. As solues (parciais) foram dadas usando o CASE Astah Community verso 6.3.

C.1 Peixaria Q-Sereia

O diagrama de casos de uso apresentado na Figura C.1. As descries dos casos de uso 01-Cadastrar Misso, 02-Cadastrar Embarcao e 03-Cadastrar Tripulante Terceiro esto apresentadas nas tabelas
O processo gil de desenvolvimento XP (Extreme Programming) recomenda que o projeto seja simples, sem elementos extras (antecipao de necessidades, exibilidades no solicitadas e desnecessrias num dado momento, etc.), ou seja, que se faa a coisa mais simples que possa funcionar e ser til. Recomendo, portanto, que os analistas sejam moderados na hora de dar sugestes.
1

253

254

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.1: Diagrama de casos de uso da Peixaria Q-Sereia.

C.1, C.2, C.3, C.4 e C.5. O diagrama de classes de nvel conceitual apresentado na Figura C.2. Os diagramas de atividade que especicam as aes do sistema nos casos de uso 01-Cadastrar Misso e 02-Cadastrar Embarcao so os das Figuras C.3 e C.4, respectivamente. Demos trs solues para o DME dos objetos da classe Embarcao Prpria. A primeira soluo (Figura C.5) a soluo mais imediata, que atm-se integralmente ao minimundo. A segunda soluo (Figura C.6) equivale primeira, mas cria o superestado Operacional contendo os estados Disponvel, Em Misso, Descarregando e Em Avaliao. Na terceira soluo (Figura C.7) deixamos a criatividade uir, considerando em desacordo com o minimundo que uma embarcao pode ser

C.1. PEIXARIA Q-SEREIA

255

Tabela C.1: Descrio do caso de uso 01-Cadastrar Misso, 1. parte.

Caso de Uso 01 Cadastrar Misso Descrio Geral: As misses de pesca patrocinadas pela Peixaria devem ser prcadastradas no SCPV antes de seu incio. Do cadastro da misso constam a matrcula da embarcao, o nmero da licena do Capito, a relao dos demais tripulantes, bem como as datas de partida e prevista de chegada. Quando a embarcao no prpria da Q-Sereia, todos os tripulantes devem ter seus nomes e telefones de contato cadastrados. Ator(es): Auxiliar Administrativo (Auxiliar) Incio: O Auxiliar Administrativo inicia o cadastramento da misso imediatamente antes da partida da misso. Pr-condies: Auxiliar Administrativo est autenticado no SCPV Datas de sada e prevista de chegada so conhecidas e vlidas Relao de tripulantes conhecida A embarcao que executar a misso tem matrcula na Capitania Portos conhecida e vlida Capito tem habilitao conhecida e vlida. Curso Tpico dos Eventos
Aes

1. 2. 3. 4. 5.

Auxiliar informa data de sada da misso. Auxiliar informa data prevista de chegada ao porto. Auxiliar informa a matrcula da embarcao na Capitania dos Portos. Sistema busca os dados da embarcao. Sistema exibe os dados da embarcao prpria e com status Disponvel da QSereia. 6. Sistema exibe lista de Capites disponveis funcionrios da Q-Sereia. 7. Auxiliar seleciona um Capito da lista. 8. Sistema exibe lista de tripulantes funcionrios da Q-Sereia. 9. Auxiliar seleciona todos os tripulantes disponveis que comporo a lista de tripulantes da misso. 10. Sistema cria um novo nmero de misso. 11. Sistema define status Em misso para a embarcao. 12. Sistema informa o novo nmero da misso. 13. Sistema informa sucesso no cadastramento da nova misso. ** Fim do Caso de Uso **

256

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Tabela C.2: Descrio do caso de uso 01-Cadastrar Misso, 2. parte.

C.A. no. 1 - Passo 4 do C.T.: No foi possvel obter os dados da embarcao

Aes

1. Sistema informa que no foi possvel obter os dados da embarcao. 2. Sistema indaga se o Auxiliar deseja informar novamente a matrcula da embarcao. 3. Auxiliar informa Sim. 4. Volta ao passo 3 do C.T. C.A. no. 1.1 - Passo 3 do C.A. 1: Auxiliar responde No
Aes

1. 2. 3. 4.

Sistema indaga se Auxiliar deseja cadastrar nova embarcao. Auxiliar responde Sim. Executar caso de uso Cadastrar Embarcao. Volta ao passo 5 do C.T.
Aes

C.A. no. 1.1.1 - Passo 2 do C.A. 1.1: Auxiliar responde No 1. Sistema informa que misso no foi cadastrada. ** Fim do Caso de Uso ** C.A. no. 2 - Passo 5 do C.T.: Embarcao no prpria da Q-Sereia
Aes

1. Executar caso de uso Cadastrar Tripulante Terceiro. 2. Sistema indaga se h mais tripulantes. 3. Auxiliar informa Sim. 4. Volta ao passo 1 do C.A. 2 C.A. no. 2.1 - Passo 3 do CA. 2.: Auxiliar informa No
Aes

1. Volta ao passo 10 do C.T. C.A. no. 3 - Passo 10 do C.T.: Sistema no pode criar nmero de misso
Aes

1. Sistema informa que no foi possvel cadastrar nova misso. ** Fim do Caso de Uso **

C.1. PEIXARIA Q-SEREIA

257

Tabela C.3: Descrio do caso de uso 02-Cadastrar Embarcao, 1. parte.

Caso de Uso 02 Cadastrar Embarcao Descrio Geral: As embarcaes que realizam misses de pesca patrocinadas pela Peixaria devem estar cadastradas no SCPV para que possam ser associadas a misses de pesca. Embarcaes podem ser prprias da Q-Sereia ou alugadas de outras empresas. Ator(es): Auxiliar Administrativo (Auxiliar), SCP (consultado quando a embarcao de terceiros) Incio: O Auxiliar Administrativo inicia o cadastramento da embarcao. Quando uma embarcao no se encontra cadastrada antes da misso que realizar, este caso de uso invocado pelo caso de uso Cadastrar Misso Pr-condies: Auxiliar Administrativo est autenticado no SCPV A embarcao tem matrcula na Capitania Portos conhecida e vlida. No caso de embarcaes de terceiros, a empresa proprietria j se encontra cadastrada no SCP. Curso Tpico dos Eventos
Aes

1. Auxiliar informa matrcula da embarcao na Capitania dos Portos. 2. Sistema verifica que embarcao ainda no cadastrada no SCPV. 3. Sistema solicita informar capacidade da embarcao em toneladas. 4. Auxiliar informa capacidade em toneladas da embarcao. 5. Sistema solicita informar se a embarcao prpria. 6. Auxiliar informa que a embarcao prpria da Q-Sereia. 7. Sistema solicita informar capacidade em litros do tanque de combustvel. 8. Auxiliar informa capacidade em litros do tanque de combustvel. 9. Sistema define status da nova embarcao como Disponvel. 10. Sistema informa que nova embarcao foi cadastrada com sucesso. ** Fim do Caso de Uso ** C.A. no. 1 - Passo 2 do C.T.: Embarcao j est cadastrada no sistema
Aes

1. Sistema informa que embarcao j se encontra cadastrada no sistema. ** Fim do Caso de Uso **

258

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Tabela C.4: Descrio do caso de uso 02-Cadastrar Embarcao, 2. parte.

C.A. no. 2 - Passo 4 do C.T.: Auxiliar informa que embarcao de terceiros

Aes

1. Sistema consulta SCP, obtm e exibe lista de empresas terceiras cadastradas naquele sistema. 2. Sistema solicita a seleo da empresa proprietria da embarcao. 3. Auxiliar seleciona a empresa proprietria. 4. Volta ao passo 7 do C.T.

Tabela C.5: Descrio do caso de uso 03-Cadastrar Tripulante Terceiro.

Caso de Uso 03 Cadastrar Tripulante Terceiro Descrio Geral: Esse caso de uso solicita os dados dos tripulantes de embarcaes de empresas terceiras (embarcaes que no so de propriedade da Q-Sereia) Ator(es): Incio: Caso de uso chamado pelo caso de uso Cadastrar Misso, no caso da embarcao que executar a misso de pesca no ser de propriedade da Q-Sereia Pr-condies: Curso Tpico dos Eventos
Aes

1. Auxiliar informa que tripulante no Capito. 2. Auxiliar informa nome e telefone em terra para contato. ** Fim do Caso de Uso ** C.A. no. 1 - Passo 1 do C.T.: Tripulante o Capito
Aes

1. Auxiliar informa nmero da habilitao do Capito. 2. Volta ao passo 2 do C.T.

C.1. PEIXARIA Q-SEREIA

259

Figura C.2: Diagrama de classes de nvel conceitual da Peixaria Q-Sereia.

260

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.3: Diagrama de atividade especicando as aes do sistema da Peixaria QSereia no caso de uso 01-Cadastrar Misso.

C.1. PEIXARIA Q-SEREIA

261

Figura C.4: Diagrama de atividade especicando as aes do sistema da Peixaria QSereia no caso de uso 02-Cadastrar Embarcao.

262

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.5: Diagrama de mquina de estados para embarcaes prprias da Peixaria Q-Sereia: primeira soluo.

vendida, pode naufragar e pode ser danicada sem possibilidade de reparo. Desenvolvemos os diagramas de sequncia para os casos de uso Cadastrar Embarcao e Cadastrar Misso (Figuras C.8 e C.9), considerando os cenrios correspondentes aos seus cursos tpicos. O diagrama de classes de especicao (no caminho entre o conceitual e o de implementao) apresentado na Figura C.10 que apresenta as operaes descobertas na elaborao dos diagramas de sequncia e classes de projeto criadas.

C.2 Empresa 5-E

O diagrama de casos de uso apresentado na Figura C.11. O diagrama de classes de conceito o da Figura C.12 e o diagrama de mquina de estados para os objetos da classe Contrato o da Figura C.13.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

263

Figura C.6: Diagrama de mquina de estados para embarcaes prprias da Peixaria Q-Sereia: segunda soluo.

C.3 Sistema de Controle de Ordens de Servio Refrigerao ManutAir

O diagrama de casos de uso apresentado na Figura C.14. A descrio do caso de uso 01-Cadastrar Contrato da Empresa ManutAir est apresentada nas tabelas C.6 e C.7. A descrio do caso de uso 02-Abrir OS da Empresa ManutAir est apresentada nas tabelas C.8, C.9 e C.10. O diagrama de classes de especicao (no caminho entre o conceitual e o de implementao, aps a descoberta das operaes feita com a ajuda dos diagramas de sequncia) apresentado na Figura C.15 que apresenta as operaes descobertas na elaborao dos diagramas de sequncia e classes de projeto criadas. Os diagramas de atividade que especicam as aes do sistema nos casos de uso 01-Cadastrar Contrato e 02-Abrir OS so os das Figuras C.16 e C.17,

264

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.7: Diagrama de mquina de estados para embarcaes prprias da Peixaria Q-Sereia: terceira soluo.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

265

Figura C.8: Diagrama de sequncia para o caso de uso Cadastrar Embarcao da Peixaria Q-Sereia curso tpico.

266

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.9: Diagrama de sequncia para o caso de uso Cadastrar Misso da Peixaria Q-Sereia curso tpico.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

267

Figura C.10: Diagrama de classes de especicao da Peixaria Q-Sereia.

268

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.11: Diagrama de casos de uso da Empresa 5-E.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

269

Figura C.12: Diagrama de classes de conceito da Empresa 5-E.

270

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Tabela C.6: Descrio do caso de uso 01-Cadastrar Contrato da Empresa ManutAir, 1. parte.

Caso de Uso 01 Cadastrar Contrato Descrio Geral: Objetiva o cadastramento dos dados (cliente, relao de equipamentos cobertos, incio de vigncia e durao) dos novos contratos de manuteno Ator(es): Atendente Incio: O caso de uso se inicia quando um cliente solicita a preparao de um contrato de manuteno preventiva e/ou corretiva de um ou mais equipamentos de condicionamento de ar (estando todos os equipamentos a serem cobertos em perfeitas condies de funcionamento). Pode ser iniciado, tambm, quando o Cliente liga para o 0800 da ManutAir e solicita a abertura de uma O.S. para reparos em um equipamento no coberto por nenhum contrato. Pr-condies: Atendente autenticado no sistema Nmeros de srie, marcas e modelos dos equipamentos a serem cobertos esto disponveis CPF/CNPJ fornecidos so vlidos Curso Tpico dos Eventos
Aes

1. 2. 3. 4. 5. 6.

Atendente informa CPF/CNPJ do cliente Sistema busca os dados do Cliente Sistema exibe os dados do Cliente Sistema solicita informar o tipo de contrato Atendente informa que o tipo de contrato Cobertura Total Executar caso de uso Manter Lista de Equipamentos, sem limites na lista de equipamentos 7. Sistema solicita informar data de incio do contrato 8. Atendente informa data de incio do contrato 9. Sistema solicita informar a durao em meses do contrato 10. Atendente informa a durao do contrato 11. Sistema cria novo nmero de contrato 12. Executar caso de uso imprimir carn de pagamento 13. Sistema informa que contrato foi cadastrado ** Fim do Caso de Uso **

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

271

Tabela C.7: Descrio do caso de uso 01-Cadastrar Contrato da Empresa ManutAir, 2. parte.

C.A. no. 1 - Passo 2 do C.T.: No foi possvel obter dados do Cliente

Aes

1. Sistema informa que no foi possvel obter dados do Cliente 2. Sistema indaga se Atendente deseja fornecer novamente CPF/CNPJ 3. Atendente informa Sim 4. Volta ao passo 1 do C.T. C.A. no. 1.1 - Passo 3 do C.A. 1: Auxiliar responde No
Aes

1. Sistema indaga se Atendente deseja cadastrar um novo cliente 2. Atendente informa que Sim 3. Executar caso de uso Cadastrar Cliente 4. Volta ao passo 4 do C.T. C.A. no. 1.1.1 - Passo 2 do C.A. 1.1: Auxiliar responde No
Aes

1. Sistema informa que contrato no foi cadastrado ** Fim do Caso de Uso ** C.A. no. 2 - Passo 4 do C.T.: Contrato contrato do tipo Avulso
Aes

1. Executar caso de uso Manter Lista de Equipamentos, para a insero de um equipamento 2. Sistema define data de incio = data corrente 3. Sistema define durao do contrato = 3 meses 4. Sistema cria novo nmero de contrato 5. Sistema informa que contrato foi cadastrado

272

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Tabela C.8: Descrio do caso de uso 02-Abrir OS da Empresa ManutAir, 1. parte.

Caso de Uso 02 Abrir OS Descrio Geral: Objetiva a abertura de uma Ordem de Servio (OS) quando um cliente necessitar de algum atendimento Ator(es): Atendente Incio: O caso de uso se inicia quando um cliente solicita algum atendimento de manuteno preventiva e/ou corretiva de um ou mais equipamentos de condicionamento de ar (estando os equipamentos cobertos ou no por um contrato). Pr-condies: Atendente autenticado no sistema Nmeros de srie, marcas e modelos dos equipamentos a serem cobertos esto disponveis nos casos de haver contrato CPF/CNPJ fornecidos so vlidos Curso Tpico dos Eventos
Aes

1. Atendente informa CPF/CNPJ do cliente 2. Sistema busca os dados do Cliente 3. Sistema exibe os dados do Cliente 4. Sistema solicita informar o nmero do contrato 5. Atendente informa o nmero do contrato 6. Sistema busca os dados do contrato 7. Sistema exibe os dados do contrato 8. Atendente solicita abrir nova OS 9. Sistema abre janela de nova OS 10. Sistema solicita informar dados, endereo e descrio do problema do equipamento a ser atendido pela OS 11. Atendente informa os dados solicitados do equipamento a ser atendido pela OS 12. Sistema busca e confirma dados do equipamento 13. Sistema indaga se h mais equipamentos a serem atendidos pela OS 14. Atendente informa No 15. Sistema cria novo nmero de OS 16. Sistema atribui o status Aberta a OS 17. Sistema informa que OS foi cadastrada ** Fim do Caso de Uso **

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

273

Tabela C.9: Descrio do caso de uso 02-Abrir OS da Empresa ManutAir, 2. parte.

C.A. no. 1 - Passo 2 do C.T.: No foi possvel obter dados do Cliente

Aes

1. Sistema informa que no foi possvel obter dados do Cliente 2. Sistema indaga se Atendente deseja fornecer novamente CPF/CNPJ 3. Atendente informa Sim 4. Volta ao passo 1 do C.T. C.A. no. 1.1 - Passo 3 do C.A. 1: Atendente responde No
Aes

1. Sistema indaga se Atendente deseja cadastrar um novo cliente 2. Atendente informa que Sim 3. Executar caso de uso Cadastrar Cliente 4. Volta ao passo 4 do C.T. C.A. no. 1.1.1 - Passo 2 do C.A. 1.1: Atendente responde No
Aes

1. Sistema informa Cliente no cadastrado ** Fim do Caso de Uso ** C.A. no. 2 - Passo 4 do C.T.: No h contrato
Aes

1. 2. 3. 4. 5.

Atendente informa que no h contrato vlido aberto Sistema indaga se Atendente deseja cadastrar um novo contrato Atendente informa que Sim Executar caso de uso Cadastrar Contrato Volta ao passo 7 do C.T.
Aes

C.A. no. 2.1 - Passo 3 do C.A. 2: Atendente responde No 2. Sistema informa que contrato no foi cadastrado ** Fim do Caso de Uso ** C.A. no. 3 - Passo 6 do C.T.: No foi possvel obter dados do contrato
Aes

1. 5. 6. 7.

Sistema informa que no foi possvel obter dados do contrato Sistema indaga se Atendente deseja fornecer novamente o nmero do contrato Atendente informa Sim Volta ao passo 5 do C.T.

274

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Tabela C.10: Descrio do caso de uso 02-Abrir OS da Empresa ManutAir, 3. parte.

C.A. no. 3.1 - Passo 3 do C.A. 3: Atendente responde No

Aes

1. Volta ao passo 2 do C.A. no. 2 C.A. no. 4 - Passo 12 do C.T.: Sistema no confirma dados do equipamento
Aes

1. Sistema informa que no foi possvel confirmar os dados do equipamento 2. Sistema indaga se Atendente deseja fornecer novamente os dados do equipamento 3. Atendente informa Sim 4. Volta ao passo 10 do C.T. C.A. no. 4.1 - Passo 3 do C.A. 4: Atendente responde No
Aes

1. 2. 3. 4.

Sistema indaga se Atendente deseja cadastrar um novo equipamento Atendente informa Sim Executar caso de uso Manter Lista de Equipamentos Volta ao passo 13 do C.T.
Aes

C.A. no. 4.1.1 - Passo 2 do C.A. 4.1: Atendente responde No 1. Sistema informa que equipamento no foi cadastrado ** Fim do Caso de Uso ** C.A. no. 5 - Passo 14 do C.T.: Atendente responde Sim
Aes

1. Volta ao passo 10 do C.T.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

275

Figura C.13: Diagrama de mquina de estados para os objetos da classe Contrato da Empresa 5-E.

respectivamente. Os diagramas de sequncia para os casos de uso 01-Cadastrar Contrato e 02-Abrir OS (Figuras C.18 e C.19), considerando os cenrios correspondentes aos seus cursos tpicos.

276

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.14: Diagrama de casos de uso da ManutAir.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

277

Figura C.15: Diagrama de classes de especicao da Empresa ManutAir.

278

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.16: Diagrama de atividade especicando as aes do sistema da ManutAir no caso de uso 01-Cadastrar Contrato.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

279

Figura C.17: Diagrama de atividade especicando as aes do sistema da ManutAir no caso de uso 02-Abrir OS.

280

APNDICE C. SOLUES DOS MINIMUNDOS COMPLETOS

Figura C.18: Diagrama de sequncia para o caso de uso 01-Cadastrar Contrato da ManutAir curso tpico.

C.3. SISTEMA DE CONTROLE DE ORDENS DE SERVIO REFRIGERAO MANUTAIR

281

Figura C.19: Diagrama de sequncia para o caso de uso 02-Abrir OS da ManutAir curso tpico.

R EFERNCIAS B IBLIOGRFICAS
[1] Grady Booch, James Rumbaugh, and Ivar Jacobson. Editora Campus Ltda, 5a. tiragem edition, 2000. UML: Guia do Usurio.

[2] [3]

Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley, 2001. Sthephen M. McMenamim e/and John F. Palmer. Anlise Essencial de Sistemas. Makron Books Editora Ltda., 1st edition, 1991. Chris Gane e/and Trish Sarson. Anlise Estruturada de Sistemas. Livros Tcnicos e Cientcos, 1983. Martin Fowler and Cris Kobryn. UML Essencial. Bookman, third edition, 2004. Martin Fowler and Kendall Scott. UML Essencial. Bookman, second edition, 2000. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional, 1995. Craig Larman. Utilizando UML e Padres Uma Introdio Anlise e ao Projeto Orientados a Objetos e ao Processo Unicado. Bookman, 3rd edition, 2008. Suzan Lilly. How to avoid use-case pitfalls. http://www.ddj.com/architect/

[4]

[5] [6] [7]

[8]

[9]

184414560, acesso em maio de 2009.

[10] OMG. Unied Modeling Language Infrastructure (OMG UML), 2.2 edition, Fevereiro 2009. [11] OMG. Unied Modeling Language Superstructure (OMG UML), 2.2 edition, Fevereiro 2009. [12] Roger S. Pressman. Engenharia de Software. McGraw-Hill, 5 edition, 2002.

283

 NDICE R EMISSIVO
Abstrao agregaes: uso em altos nveis de, 86 ajudando na modelagem, 17 da realidade em modelos, 14 diculdade de promover a, 18 e modelagem, 16 e nveis de detalhamento, 61 em diagramas de sequncia, 156 em diversos nveis com a UML, 21 em especializaes de casos de uso, 36 nveis de, 17 na anlise essencial, 18 nas descries dos casos de uso, 45 nas perspectivas dos diagramas de classe, 60 seleo dos detalhes, 14 Agregao notao grca, 85 Ambiguidade especicao sem, 16 especicando sem, 18, 20, 26 linguagem coloquial plena de, 100 Anlise essencial, 18 estruturada, 18 Associao autoassociao, 76, 102 classe de, 88 cruzamento entre, 55 em diagrama de instalao, 192 285 entre ator, 53 entre ator e caso de uso, 33 entre atores, 4 entre classes, 71, 72 fatorao de, 81 multiplicidades em, 75, 95 navegabilidade em, 75 nomes de classes de, 90 papis em, 73 rtulo no nome da, 73 representao grca, 72 substituindo agregao simples, 86 Ator associao a caso de uso, 33 associao entre, 4, 53 descrio das aes do, 138 do negcio, 26 do sistema, 26 e a fronteira do sistema, 32 em diagrama de sequncia, 157 em parties de DAs, 128 especializao de, 34 notao grca, 28 organizao em pacote, 187 pacote de, 92, 187 papel, 28 relao de, 45, 47 repetio no diagrama, 30 ator descoberta, 30 CASE

286 adaptao s mudanas da notao, 131 ajuda na aplicao da metodologia, 11 colaboraes em frames, 174 como agrupar elementos em pacotes, 187 como tecnologia de gesto do modelo, 12 consistncia do modelo, 148 converso automtica sequnciacomunicao, 147 engenharia direta, 177 engenharia reversa, 148 eventos nos uxos dos DAs, 141 falta de suporte grco adequado na ferramenta, 185 gerao de cdigo, 148 gerando scripts de criao dos bancos de dados, 62 intercmbio de modelos entre ferramentas, 22 mais de trs compartimentos nas classes, 68 nvel de detalhamento, 62 na identicao de cenrios, 138 na vericao da corretude do modelo, 3 nomeando automaticamente associaes, 90 sugerindo atributos privados, 66 sugesto de ferramenta, 3 Caso de Uso caractersticas, 31 descoberta, 31 m do, 55 notao grca, 31 Caso de uso pacote de, 187 tamanho do, 54 Cenrios

NDICE REMISSIVO forma de especicao, 151 identicao visual, 150 Classe abstrata, 81, 92 atributos das, 64 compartimentos da, 62 conceitual, 61 de associao, 88 de associao, limitao, 90 de entidade, 62 de interface, 93 de projeto, 154 delegao de responsabilidade, 153 identicao de, 64 identicador, 62 nomes de atributos de, 65 notao grca, 62 operaes da, 67 pacote de, 187 padres de projeto, 154 rtulos de atributos de, 66 responsabilidades da, 67, 68, 71, 75, 147, 148, 152155, 160, 163, 171, 176 tcnica de descoberta de, 64 visibilidade de atributos de, 66, 80, 156 visibilidade de operaes de, 67, 80, 156 visibilidade protegida, 81 CMMI modelo de qualidade, 11 Componentes correspondendo a pacotes, 191 diagramas de, 189 Composio notao grca, 86 Conjuntos de Generalizao notao grca, 83 Curso Alternativo do caso de uso, 45, 47, 149

NDICE REMISSIVO Curso de Exceo do caso de uso, 49 Curso Tpico do caso de uso, 45, 47, 149, 160 DA workows, 122 aes, 122 aes como estados de atividade, 122 atividade, 122 cancelamento, 132 comportamento, 122 descrevendo caso de uso, 137 enfocando o uxo de controle, 122 eventos temporais, 131 uxos de objetos, 129 uxos entre aes, 123 uxos no qualicados, 123 uxos qualicados, 123 identicando cenrios, 150 junes, 128 ns de deciso, 125 ns de intercalao, 125 parties, 128 pinos, 134 pseudoestado inicial, 123 raias de natao, 128 separaes, 125 sinais, 131 transformaes, 134 Descries dos UCs, 40, 43, 45, 121, 137, 160 dos UCs, consistncia, 56 dos UCs, padro na organizao, 44 Diagrama de classes perspectivas, 60 Diagramas de Casos de Uso enfoques, 26 DS autochamada, 164

287 caixa de ativao, 158, 168 cenrios, 149 chamadas, 164 chamadas assncronas, 170 chamadas sncronas, 169 criao de objetos, 175 criao e destruio de objetos, 165 dimenso horizontal, 157 dimenso vertical, 158 diminuindo a abstrao, 156 especicando uma colaborao, 146 linha de vida, 158 nivel de detalhamento, 159 objetos controladores, 176 objetos de interface, 176 operadores em quadros de interao, 172 parmetros de chamadas, 171 quadros de interao, 172, 184 retorno, 167 trip da anlise, 155 Engenharia de negcios, 122 de software, o que , 11 direta, 177 reversa, 177 Espao de nomes denio de, 63 denido em um pacote, 187 identicadores nicos em um, 3 Especializao categorizada em partio, 83 como extenso de caso de uso, 38 completa, 84 de ator, 3, 34 de casos de uso, 36 de classe, 78 notao grca, 78, 80 redes de, 82

288 Especicao linguagens grcas, 16 da colaborao com quadros, 172 da colaborao entre objetos, 146 da estrutura da informao, 60 da interao usurio-sistema, 121 da UML, 4 das operaes das classes, 67 de aes em DTEs, 109 de algoritmos complexos com DAs, 122 de casos de uso com DAs, 137, 150 de casos de uso, padro nas organizaes, 44 de conceitos por meio de classes, 60 de estados, transies e eventos com DMEs, 100 de multiplicidades, 75 de papis, 74 de repeties em casos de uso, 49 de repeties em DSs, 172 de restries, 94 do mecanismo de juno, 171 do modelo, 20 do que compe um projeto, 2 dos aspectos conceituais do sistema, 3 dos atributos das classes, 65 dos cursos tpico e alternativos, 47 dos requisitos funcionais, 26 nvel de abstrao de, 17 nvel de formalismo para, 17 para gerao automtica de cdigo, 138 Estado composto, 111 concorrente, 113 de atividade, 104, 121, 122 nal, 105 nal, equvocos, 106 pseudoestado inicial, 104, 107, 123

NDICE REMISSIVO superestado e subestado, 111 tipos de, 103 Estados dos objetos, 102 Evento externo, 108 temporal, 108 Extenso da UML, mecanismo de, 193, 195 de caso de uso, 37, 39, 49, 56 macete de uso, 40 Fatorao agrupamento em superclasses, 82 Generalizao de classe, 78 notao grca, 78, 80 Incluso de caso de uso, 37, 39, 45, 49, 56, 194 macete de uso, 40 Interao diagrama de colaborao, 147 diagrama de sequncia, 147 diagrama de viso geral da, 6, 147, 184 diagramas de, 122, 148, 155 especicando a, 146 Interface entre ator e sistema, 177 Item Anotacional elucidando o modelo, 40, 123 Linhas de vida dos objetos, 158 Modelagem anlise essencial na, 19 anlise estruturada na, 19 bons nomes na, 104 de concorrncia, 125 denio de, 15

NDICE REMISSIVO diagramas mais usados em, 183 diviso e conquista, 18 diviso no conceito, 18 diviso no domnio, 18 e abstrao, 16 em nvel conceitual, 122 estudando os sistemas por meio de, 16 ms prticas, 53 OO, 19 organizao hierrquica, 18 orientada a objetos, 19 placebo de, 86, 87 recursos usados na, 17 vantagens, 16 Modelagens processos de negcio, 28 Modelo de casos de uso, extenso, 37 de casos de uso, incluso, 37 comentando o, 40 completo, dimenses, 15 completude do, 20 complexidade visual, 30, 55, 157, 174 conceitual, 64, 65, 75, 77 consistncia, 16, 56, 148 consistncia e corretude do, 22 construo do, 16 de anlise, 67 de casos de uso, descries em, 44 de processo, 13 de processo de software, 12 de sistemas denio, 15 de software, 14 denio de, 14 dimenses do, 15, 122 e abstrao, 14 entendimento do, 20 evoluo do, 15 gerao automtica de cdigo, 138

289 gerao de cdigo, 16 gerao de cdigo com base no, 185 intercmbio entre ferramentas CASE, 21, 22 linguagem de especicao do, 16 organizao do, 187 renamento do, 15 representao textual com XML do, 21 restries no, 93, 94 separao entre dados e funes, 19 transformaes do, 19 Multiplicidade e cardinalidade, 66 intervalos de, 75 multivalorada, 75 na associao, 75, 95 na associao ator-caso de uso, 33 nas agregaes compostas, 87 nas agregaes simples, 86 no projeto e implementao, 77 obrigatria, 75, 87 opcional, 75 Objetos ativao e desativao nos DSs, 158 caixa de ativao, 158 ciclo de vida, 99, 151, 165 colaborao entre, 19, 146, 163, 184 controladores, 176 correlao entre pessoas e, 146 criao e destruio, 165 de indexao de outros objetos, 153 de interface, 176 de vida efmera, 151 descobrindo as operaes dos, 154 e responsabilidades, 163 escolha para a colaborao, 171 escolha para uma colaborao, 152 estados dos, 99 uxos de, 129

290 formulrios, 177 linhas de vida, 158 mecanismo de troca de mensagens, 146 mensagens entre, 146, 164 nomes nos DSs, 157 ordem de colocao na dimenso horizontal do DS, 157 orientao a, 19, 20, 146, 155 persistentes, 151 responsabilidades dos, 145, 147, 148, 152 Operao abstrata, 92 Pacotes como contineres, 92 correspondendo a componentes, 191 dependncia entre, 215 diagrama de, 6, 55, 187 notao grca, 187 organizando com, 187 Papel ator interpretando, 28 Perspectivas em diagramas de classes, 60 Processo gil, 137 RUP, 13 agrupamento em superclasses, 82 controle, uxo de, 122 de coleta de lixo, 176 de construo do software, 155 de descoberta de operaes, atributos e associaes, 155 de desenvolvimento o trip da anlise, 155 de especicao de testes funcionais, 43

NDICE REMISSIVO de levantamento de requisitos, incio do, 45 de modelagem, 15 de negcio, 26 de negcio, modelo com DA, 125 de negcio, modelo de, 141 de software, 10, 12 de software marcos, 11, 13 de software RUP 13 , de software XP 14 , de software XP com SCRUM, 14 de software em cascata, 13 de software mais conhecidos, 13 de software, denio, 12 de software, qualidade do, 10 em cascata, 13, 14 formal, 18 intermediando a comunicao entre atores, 54 modelo de 14 Unicado da Rational RUP, 4 Qualidade do processo de software, 10 do processo de software, modelos de, 11 do software, 8, 25 do software e do processo, 10 do software e requisitos, 10 do software, deteriorao da, 9 Relacionamento entre classes, 72 Responsabilidade delegao da, 170 Restries nos modelos, 93 notao, 94 RUP como base de conhecimento, 13 na bibliograa, 4

NDICE REMISSIVO Software atores como usurios do, 30 ciclo de vida, 8, 11 disciplina, 11 distribuio, 192 engenharia de, 11 metodologia, 11 modelagem de, 14 o que , 8 OO, 12 padro de desenvolvimento, 10 padres de projeto de, 154 planejamento, 11 qualidade, 10 requisitos, 10 Transies autotransies, 107 e casos de uso, 115 entre estados, 99 eventos, condies e aes, 106 omisso de eventos, condies e aes, 109 Trip da anlise no processo de desenvolvimento, 155 UML caractersticas e vantagens da, 20 histria da, 20 Visibilidade atributos e mtodos protegidos, 80 Workow com DA, 122 sistemas de gerncia de, 11

291

ISBN 978-85-911695-0-4

9 788591 169504