Apostila Orientacao Objetos 2009 PDF

Introdu c ao ` a An alise Orientada a Objetos e Projeto Arquitetural
Cec lia Mary Fischer Rubira cmrubira@ic.unicamp.br http://www.ic.unicamp.br/cmrubira
Patrick Henrique da Silva Brito pbrito@ic.unicamp.br http://www.ic.unicamp.br/pbrito
Instituto de Computa c ao - UNICAMP
2009
Sum ario
Sum ario Lista de Tabelas Lista de Figuras 1 Introdu c ao 1.1 Estrutura c ao de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Gerenciamento da Complexidade do Software . . . . . . . . . . . 1.1.2 T ecnicas de Estrutura c ao de Software . . . . . . . . . . . . . . . 1.1.3 Crise de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Evolu c ao da Abstra c ao em Linguagens de Programa ca o . . . . . . . . . 1.2.1 Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . 1.2.2 M odulos, Pacotes e Subsistemas . . . . . . . . . . . . . . . . . . 1.2.3 Tipos Abstratos de Dados . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Programa c ao Orientada a Objetos . . . . . . . . . . . . . . . . . 1.2.5 Programa c ao Orientada a Objetos vs. Programa c ao Estruturada 1.2.6 Linguagens Orientadas a Objetos . . . . . . . . . . . . . . . . . . 1.3 Fundamentos do Paradigma de Objetos . . . . . . . . . . . . . . . . . . 1.3.1 O Conceito de Objeto . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Classica c ao/Instancia c ao . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Abstra c ao de Dados e Hierarquias de Abstra c oes . . . . . . . . . 1.3.5 Generaliza c ao/Especializa c ao . . . . . . . . . . . . . . . . . . . . 1.3.6 Agrega c ao/Decomposi c ao . . . . . . . . . . . . . . . . . . . . . . 1.3.7 Associa c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.8 Depend encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 An alise e Projeto Orientado a Objetos . . . . . . . . . . . . . . . . . . . 1.4.1 Processos Tradicionais vs. Processos Orientados a Objetos . . . . 1.4.2 Limita c oes do Modelo de Objetos . . . . . . . . . . . . . . . . . . 1.5 Engenharia de Software Baseada em Componentes . . . . . . . . . . . . 1.5.1 Componentes de Software . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Reusabilidade, Modularidade e Extensibilidade . . . . . . . . . . 1.5.3 Desenvolvimento Baseado em Componentes . . . . . . . . . . . . 1.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i i v vii 1 1 2 2 3 4 4 6 8 8 10 11 12 12 13 14 15 16 16 18 19 19 20 23 23 23 24 25 26
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii 1.7 Exerc cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 29 29 31 32 33 35 36 37 38 38 39 40 41 43 45 45 46 47 49 49 50 51 51 54 56 57 58 63 63 64 65 66 67 69 70 72 72 75 76 77 78 78
2 Modelagem de Casos de Uso 2.1 Introdu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Casos de Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Atores e Pap eis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Cen arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Formato e Conven c oes para Casos de Uso . . . . . . . . . . . . . . . . 2.7 Diagramas de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Relacionamentos entre Casos de Uso . . . . . . . . . . . . . . . . . . . 2.8.1 Generaliza c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.2 Inclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.3 Extens ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 M etodo para a Modelagem de Casos de Uso . . . . . . . . . . . . . . . 2.9.1 Identica c ao de Casos de Uso Baseada em Atores . . . . . . . . 2.9.2 Identica c ao de Casos de Uso Baseada em Atributos . . . . . . 2.9.3 Identica c ao de Casos de Uso Baseada em An alise de Dom nio 2.9.4 Constru c ao de um Gloss ario e Termos . . . . . . . . . . . . . . 2.9.5 Levantamento Inicial dos Casos de Uso . . . . . . . . . . . . . 2.9.6 Descri c ao de Casos de Usos . . . . . . . . . . . . . . . . . . . . 2.9.7 Gerenciamento de Casos de Uso Complexos . . . . . . . . . . . 2.9.8 Descri c oes Formais de Casos de Usos . . . . . . . . . . . . . . . 2.9.9 Diagrama de Casos de Uso do Sistema da Biblioteca . . . . . . 2.9.10 Diagrama de Atividades para Fluxo de Eventos . . . . . . . . . 2.9.11 Diagramas de Intera c ao de Sistema . . . . . . . . . . . . . . . . 2.9.12 In cio da An alise . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Exerc cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 An alise Orientada a Objetos: Modelagem Est atica 3.1 An alise OO x Projeto OO . . . . . . . . . . . . . . . . . . . . 3.2 Modelagem Est atica x Modelagem Din amica . . . . . . . . . 3.3 Metodologias para An alise Orientada a Objetos . . . . . . . . 3.3.1 OMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Um M etodo para An alise Orientada a Objetos Usando UML 3.4.1 T ecnicas para Extra c ao de Informa c oes . . . . . . . . 3.5 Atividade 1: Identicar Classes de An alise . . . . . . . . . . . 3.5.1 Atividade 1.1: Extrair Classes Candidatas . . . . . . . 3.5.2 Atividade 1.2: Eliminar Classes Inapropriadas . . . . . 3.5.3 Atividade 1.3: Renar a Lista de Classes Candidatas . 3.6 Atividade 2: Atualizar Dicion ario de Dados . . . . . . . . . . 3.7 Atividade 3: Identicar os relacionamentos entre as classes . . 3.7.1 Atividade 3.1: Identicar Associa c oes . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
iii 3.7.2 Atividade 3.2: Identicar Agrega c oes . . . . . . . . . . . 3.7.3 Atividade 3.3: Identicar Heran ca . . . . . . . . . . . . Atividade 4: Identicar/Atributos das Classes de An alise . . . Atributos das Classes de An alise no Estudo de Caso . . . . . . Atividade 5: Iterar e Renar . . . . . . . . . . . . . . . . . . . 3.10.1 Atividade 1 (itera c ao 2): Identicar Classes de An alise . 3.10.2 Atividade 3 (Itera c ao 2): Identicar os Relacionamentos Padr oes de Modelagem . . . . . . . . . . . . . . . . . . . . . . . Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exerc cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . entre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . as Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 79 80 81 82 82 85 85 87 88 91 91 91 92 94 95 95 95 96 99 101 101 103 105 106 110 111 113 115 115 118 119 119 120 122 123 124 125 126 128 130 131 133 134
3.8 3.9 3.10
3.11 3.12 3.13
4 Modelagem Estrutural em UML 4.1 Objetos e Classes . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Classes Concretas . . . . . . . . . . . . . . . . . 4.1.2 Instancia c ao de Objetos em UML . . . . . . . . . 4.1.3 Opera c oes Construtoras . . . . . . . . . . . . . . 4.1.4 Visilibilidade de Atributo e Opera c ao . . . . . . 4.2 Tipo Abstrato de Dados . . . . . . . . . . . . . . . . . . 4.2.1 Tipos e Classes . . . . . . . . . . . . . . . . . . . 4.2.2 Tipos Abstratos de Dados . . . . . . . . . . . . . 4.3 Relacionamento de Agrega c ao e Associa c ao . . . . . . . 4.4 Relacionamento de Generaliza c ao . . . . . . . . . . . . . 4.4.1 Heran ca Simples de Classes . . . . . . . . . . . . 4.4.2 Visibilidade Protegida de Atributos e Opera c oes 4.4.3 Clientes por Heran ca e por Instancia c ao . . . . . 4.4.4 Heran ca de Implementa c ao . . . . . . . . . . . . 4.4.5 Heran ca de Comportamento . . . . . . . . . . . . 4.4.6 Heran ca M ultipla . . . . . . . . . . . . . . . . . . 4.4.7 Exemplo de Heran ca M ultipla em UML . . . . . 4.5 Polimorsmo . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 O que e polimorsmo? . . . . . . . . . . . . . . . 4.5.2 Coer c ao . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Sobrecarga . . . . . . . . . . . . . . . . . . . . . 4.5.4 Polimorsmo Param etrico . . . . . . . . . . . . . 4.5.5 Polimorsmo de Inclus ao . . . . . . . . . . . . . 4.5.6 Exemplo: Pilha de Publica c oes . . . . . . . . . . 4.6 Classes Abstratas . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Opera c ao Abstrata vs. Opera c ao Concreta . . . 4.6.2 Classe Raiz, Classe Folha e Opera c ao Folha . . . 4.6.3 Exemplo 1: Hierarquia de Ra cas de C aes . . . . 4.6.4 Exemplo 2: Hierarquia de Figuras Gr acas . . . 4.7 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Relacionamento de Realiza c ao em UML . . . . . 4.7.2 Heran ca Simples e M ultipla entre Interfaces . . . 4.7.3 Exemplo 1 - Integra c ao Objeto-Relacional . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv 4.7.4 Exemplo 2 - Alternativa ` a Heran ca M ultipla de Classes 4.7.5 Exemplo 3 - Classes, Interfaces e Tipos . . . . . . . . . 4.8 Pacotes em UML . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Visibilidade de Classes, Atributos e Opera c oes . . . . . 4.9 Relacionamento de Delega c ao . . . . . . . . . . . . . . . . . . . 4.9.1 Sistemas baseados em Delega c ao . . . . . . . . . . . . . 4.9.2 Delega c ao versus Heran ca . . . . . . . . . . . . . . . . . 4.9.3 Delega c ao em Sistemas Basedos em Classes . . . . . . . 4.9.4 O Padr ao Delega c ao para Sistemas baseados em Classes 4.9.5 Uma Aplica c ao do Padr ao Delega c ao . . . . . . . . . . . 4.10 Metaclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.1 Exemplo de utiliza c ao de metaclasses . . . . . . . . . . 4.11 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Exerc cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 138 139 142 143 143 144 145 147 148 154 156 159 160
5 An alise Orientada a objetos: Modelagem Din amica 5.1 Atividades da Modelagem Din amica . . . . . . . . . . . . . . . . . . . . . 5.2 Atividade 1: Identicar Eventos do Sistema . . . . . . . . . . . . . . . . . 5.2.1 An alise Textual do Caso de Uso Emprestar Exemplar . . . . . . . . 5.2.2 Eventos Identicados . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Atividade 2: Construir Diagrama de seq u encia para o Caso de Uso . . . . 5.3.1 Diagrama de Seq u encia de Sistema . . . . . . . . . . . . . . . . . . 5.3.2 Diagrama de Seq u encia Renado . . . . . . . . . . . . . . . . . . . 5.4 Atividade 3: Constru c ao de um Diagrama de Colabora ca o para o Sistema 5.5 Atividade 4: Atualizar interfaces p ublicas das classes de an alise. . . . . . . 5.6 Atividade 5: Construir Diagramas de Estados . . . . . . . . . . . . . . . . 6 Estudo de Caso: Sistema de Caixa Autom atico 6.1 Enunciado do Problema . . . . . . . . . . . . . . . . . . . . . . . 6.2 Descri c ao dos Casos de Uso . . . . . . . . . . . . . . . . . . . . . 6.2.1 Caso de Uso Efetuar Login . . . . . . . . . . . . . . . . . . 6.2.2 Diagrama de Atividades do Caso de Uso Efetuar Login . . 6.2.3 Diagrama de Seq uencia do Caso de Uso Efetuar Login . . 6.2.4 Caso de Uso Consultar Saldo . . . . . . . . . . . . . . . . . 6.2.5 Diagrama de atividades do caso de uso Consultar Saldo . . 6.2.6 Diagrama de Seq uencia do Caso de Uso Consultar Saldo . 6.2.7 Caso de Uso Efetuar Saque . . . . . . . . . . . . . . . . . . 6.2.8 Diagrama de Atividades do Caso de Uso Efetuar Saque . . 6.2.9 Diagrama de Seq u encia do Caso de Uso Efetuar Saque . . 6.2.10 Caso de Uso Efetuar Dep osito . . . . . . . . . . . . . . . . 6.2.11 Diagrama de Atividades do Caso de Uso Efetuar Dep osito 6.2.12 Diagrama de Seq uencia do Caso de Uso Efetuar Dep osito . 6.3 Modelagem Est atica . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Atividade 1: Identicar as Classes de An alise . . . . . . . 6.3.2 Atividade 1.1: Extrair as Classes Candidatas . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
167 . 168 . 169 . 169 . 171 . 172 . 172 . 173 . 175 . 176 . 179 181 181 183 183 184 184 184 185 186 187 188 188 189 191 191 192 192 197
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
v 6.3.3 Atividade 1.2: Renar Classes Candidatas . . . . . . . . . . 6.3.4 Atividade 1.3: Revisar Lista de Classes Candidatas . . . . . 6.3.5 Atividade 2: Construir o Dicion ario de Dados . . . . . . . . 6.3.6 Atividade 3: Identicar os Relacionamentos entre as Classes 6.3.7 Atividade 4: Identica c ao de Atributos . . . . . . . . . . . 6.3.8 Atividade 5 (Itera c ao 2): Iterar e Renar . . . . . . . . . . Modelagem Din amica . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Passo 1: Identicar Eventos . . . . . . . . . . . . . . . . . . 6.4.2 Diagramas de Seq u encia . . . . . . . . . . . . . . . . . . . . Diagrama de Colabora c ao . . . . . . . . . . . . . . . . . . . . . . . Diagrama Final de Classes da An alise . . . . . . . . . . . . . . . . Diagrama de Estados da Classe Conta . . . . . . . . . . . . . . . . Renamentos do Diagrama de Classes de An alise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 199 199 200 201 202 206 206 213 215 215 216 217 221 223 223 224 225 226 227 229 232 233 233 234 234 238 238 238 239
6.4
6.5 6.6 6.7 6.8
7 Transi c ao da An alise OO para o Projeto OO 7.1 Fases do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 OMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Propriedades N ao-Funcionais do Sistema Realizadas na Arquiteturas de Software 7.3 Vis oes da Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 O Padr ao Arquitetural de Camadas . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Arquitetura do Sistema de Caixa Autom atico . . . . . . . . . . . . . . . . . . . . 7.6 O Padr ao de Projeto State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.2 Solu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.3 Conseq u encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 Aplica c ao do Padr ao State ao Sistema de Caixa Autom atico . . . . . . . . 7.7 O Padr ao de Projeto Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.2 Solu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.3 Conseq u encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
Lista de Tabelas
1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1 6.1 7.1 Compara c ao entre a Programa c ao Estruturada e a Orientada a Objetos . . . . . . . 11 Modelo Sugerido para a deni c ao do Gloss ario . . . . . . . . . . . . . . . . . . . . . 47 Gloss ario dos Termos da Biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Categorias e Entidades identicadas para o sistema da biblioteca . . . . . . . . . . . 73 Atributos identicados para o sistema de bibliotecas . . . . . . . . . . . . . . . . . . 82 Especica c ao Informal do TAD Pilha. . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Especica c ao do TAD Pilha Utilizando Pr e e P os-condi c oes . . . . . . . . . . . . . . 99 Eventos relevantes para as Classes identicadas. . . . . . . . . . . . . . . . . . . . . . 177 Atributos Identicados das Classes de Entidade . . . . . . . . . . . . . . . . . . . . . 202 Resumo das Vis oes do Modelo 4+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
vii
viii
Lista de Figuras
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 3.1 3.2 Passos Intermedi arios da Modelagem da Realidade . . . . . . . . Programa c ao Estruturada vs. Programa c ao Orientada a Objetos Classica c ao de Wegner . . . . . . . . . . . . . . . . . . . . . . . O Conceito de Objeto . . . . . . . . . . . . . . . . . . . . . . . . Opera c oes, M etodos e Atributos . . . . . . . . . . . . . . . . . . Classes e Objetos em UML . . . . . . . . . . . . . . . . . . . . . Exemplo de Classica c ao/Instancia c ao . . . . . . . . . . . . . . . Exemplo de Generaliza c ao/Especializa c ao . . . . . . . . . . . . . Exemplo de Agrega c ao/Decomposi c ao . . . . . . . . . . . . . . . Associa c oes em UML . . . . . . . . . . . . . . . . . . . . . . . . . Relacionamento de Depend encia em UML . . . . . . . . . . . . . Modelo Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . Representa c ao de um componente UML . . . . . . . . . . . . . . Diagramas de classes com Poss veis Erros de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 10 11 13 13 14 15 17 17 19 19 21 22 24 28 30 32 33 33 38 39 40 40 42 49 50 52 53 54 55 56 57
Casos de Uso na Especica c ao dos Requisitos . . . . . . . . . . . . . . . . . . Caso de Uso Emprestar Exemplar em UML . . . . . . . . . . . . . . . . . . . . Representa c ao de Atores em UML . . . . . . . . . . . . . . . . . . . . . . . . Caso de Uso Emprestar Exemplar com seus atores . . . . . . . . . . . . . . . . Diagrama de Casos de Uso para o Sistema de Biblioteca . . . . . . . . . . . . Exemplo de Generaliza c ao no Diagrama de Casos de Uso . . . . . . . . . . . Exemplo de Inclus ao entre Casos de Uso . . . . . . . . . . . . . . . . . . . . . Exemplo de Extens ao entre Casos de Uso . . . . . . . . . . . . . . . . . . . . Realiza c oes dos Casos de Uso em Modelos Diferentes . . . . . . . . . . . . . . Modelagem Alternativa do Caso de Uso Manter Dados Publica c ao . . . . . . . Pacotes de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Casos de Uso do Sistema da Biblioteca . . . . . . . . . . . . . . Um Exemplo Simples de Diagrama de Atividades . . . . . . . . . . . . . . . . Diagrama de Atividades para o Caso de Uso Emprestar Exemplar . . . . . . . Diagrama de Seq u encia de Sistema para um Cen ario de Emprestar Exemplar . Diagrama de Colabora c ao de Sistema para um Cen ario de Emprestar Exemplar Modelo de Classes Preliminar para o Sistema da Biblioteca . . . . . . . . . .
Est agio da An alise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Atividades da Modelagem Est atica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 ix
x 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34 4.35 4.36 4.37 Extra c ao de Informa c oes a partir do Enunciado do Problema . . . . . . . Diagrama de Classes Inicial de An alise . . . . . . . . . . . . . . . . . . . . Diagrama de Classes Inicial de An alise (com Pacotes) . . . . . . . . . . . Diagrama de Classes Inicial de An alise com Relacionamentos e Atributos Representa c oes Gr acas para Estere otipos de Classes de An alise . . . . . Liga c oes Poss veis entre as Classes do Padr ao MVC. . . . . . . . . . . . . Diagrama de Classes de An alise Renado . . . . . . . . . . . . . . . . . . Classe que representa as publica c oes de uma biblioteca . . . . . . . . . . . Instancia c ao de dois objetos da classe Publicacao . . . . . . . . . . . . . . Cria c ao de um Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe Publicacao com duas Opera c oes Construtoras . . . . . . . . . . . . Estrutura de um Tipo Abstrato de Dados . . . . . . . . . . . . . . . . . . Classe Pilha, que dene um TAD . . . . . . . . . . . . . . . . . . . . . . . Hierarquia de Agrega c ao de uma Biblioteca . . . . . . . . . . . . . . . . . Diagrama de Colabora c ao com Propaga c ao de Mensagem . . . . . . . . . Exemplo de Heran ca de Classes . . . . . . . . . . . . . . . . . . . . . . . . Hierarquia de Classes de Usu arios . . . . . . . . . . . . . . . . . . . . . . . Hierarquia de Lista e Pilha com Heran ca . . . . . . . . . . . . . . . . . . . Hierarquia de Lista e Pilha com Heran ca de Implementa c ao . . . . . . . . Solu c ao Alternativa com Agrega c ao . . . . . . . . . . . . . . . . . . . . . . Analogia entre Supertipo/Subtipo e Conjunto/Subconjunto . . . . . . . . Hierarquia de Figuras Geom etricas . . . . . . . . . . . . . . . . . . . . . . Problema do Diamante em Heran ca M ultipla . . . . . . . . . . . . . . . . Hierarquia de um Rel ogio-Calend ario . . . . . . . . . . . . . . . . . . . . . Alternativa ` a Heran ca M ultipla com Agrega c ao . . . . . . . . . . . . . . . M etodo Polim orco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uma Hierarquia de Tipos e Subtipos Polim orcos . . . . . . . . . . . . . . Taxonomia de Cardelli e Wegner . . . . . . . . . . . . . . . . . . . . . . . Polimorsmo de Sobrecarga na Classe Publicacao . . . . . . . . . . . . . . Polimorsmo Param etrico . . . . . . . . . . . . . . . . . . . . . . . . . . . Uma Pilha de Publica c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . Um Exemplo de Polimorsmo de Inclus ao com Redeni c ao de Opera c oes Exemplo de Classe Abstrata e Concreta . . . . . . . . . . . . . . . . . . . Uma Hierarquia de Classes de Reserva de Publica c oes . . . . . . . . . . . Exemplo de Hierarquia de Classes . . . . . . . . . . . . . . . . . . . . . . Hierarquia de Classe para C aes . . . . . . . . . . . . . . . . . . . . . . . . Hierarquia de Classes para Figuras Gr acas . . . . . . . . . . . . . . . . Exemplo de Interface em Sistemas Computacionais . . . . . . . . . . . . . Uma Hierarquia de Classes e Interfaces . . . . . . . . . . . . . . . . . . . . Uma Interface Implementada por Duas Classes . . . . . . . . . . . . . . . Uma Classe que Implementa Duas Interfaces e Estende Outra Classe . . . Heran ca Simples e M ultipla entre Interfaces . . . . . . . . . . . . . . . . . Separa c ao Expl cita Entre Camadas de Neg ocios e Dados . . . . . . . . . Heran ca M ultipla Entre Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 80 80 83 84 85 86 92 92 93 94 96 97 100 101 102 103 106 108 109 110 111 112 113 115 116 117 117 119 120 122 123 124 125 126 127 129 130 131 132 132 133 134 136
xi 4.38 4.39 4.40 4.41 4.42 4.43 4.44 4.45 4.46 4.47 4.48 4.49 4.50 4.51 4.52 4.53 4.54 4.55 4.56 4.57 4.58 4.59 4.60 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 Solu c ao em Java Usando Interfaces . . . . . . . . . . . . . . . . . . Uma Hierarquia de Figuras Geom etricas . . . . . . . . . . . . . . . Uma Hierarquia Mais Complexa . . . . . . . . . . . . . . . . . . . Exemplo de Organiza c ao em Pacotes . . . . . . . . . . . . . . . . . Visibilidade de atributos e opera c oes em UML . . . . . . . . . . . Exemplo de Visibilidade de Pacote em UML . . . . . . . . . . . . . Exemplo de Prot otipos Geom etricos . . . . . . . . . . . . . . . . . Delega c ao de mensagens entre prot otipos . . . . . . . . . . . . . . Figuras Geom etricas baseadas em Classes . . . . . . . . . . . . . . Implementa c ao de Delega c ao em Linguagens Baseadas em Classes Representa c ao Expl cita dos Estados da Publica ca o . . . . . . . . . Estrutura do Padr ao de Projeto State . . . . . . . . . . . . . . . . Padr ao state Aplicado na Hierarquia de Publica c oes . . . . . . . . O Conceito de Metaclasse . . . . . . . . . . . . . . . . . . . . . . . Fus ao de Metaclasse com Classe . . . . . . . . . . . . . . . . . . Metaclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Atributos e m etodos de classe. . . . . . . . . . . . . . . . . . . . . Solu c ao com Atributos e M etodos Est aticos . . . . . . . . . . . . . O Padr ao de Projeto Factory Method . . . . . . . . . . . . . . . . . Especializa c ao da Classe Pessoa em Duas Dimens oes . . . . . . . . Hierarquia de Classes de um Buer . . . . . . . . . . . . . . . . . . Sistema de Controle de Consultas . . . . . . . . . . . . . . . . . . . Hierarquia de C omodos de um Hotel . . . . . . . . . . . . . . . . . Extra c ao de Informa c oes a partir do Enunciado Diagrama de seq u encia de Sistema . . . . . . . Diagrama de seq u encia Renado . . . . . . . . Diagrama de Colabora c ao . . . . . . . . . . . . Diagrama de Classes de An alise com Opera c oes Um Diagrama de Estados UML . . . . . . . . . Diagrama de Estados para a Classe Usu ario . . do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 137 139 140 142 143 144 145 146 147 150 151 152 154 155 155 156 156 159 161 164 164 165 169 173 174 176 178 179 180 182 184 185 186 187 189 190 191 192 193 200 200 201
Sistema de Caixa Autom atico . . . . . . . . . . . . . . . . . Diagrama de atividades para o caso de uso Efetuar Login . . Diagrama de seq u encia do caso de uso Efetuar Login . . . . Diagrama de atividades para o caso de uso Consultar Saldo . Diagrama de seq u encia do caso de uso Consultar Saldo . . . Diagrama de atividades para o caso de uso Efetuar Saque . . Diagrama de seq u encia do caso de uso Efetuar Saque . . . . Diagrama de atividades para o caso de uso Efetuar Dep osito Diagrama de seq u encia do caso de uso Efetuar Dep osito . . . Atividades simplicadas da an alise textual . . . . . . . . . . Diagrama inicial de classes com agrega c oes. . . . . . . . . . Diagrama inicial de classes com pacote. . . . . . . . . . . . Identica c ao dos relacionamentos entre as classes. . . . . . .
xii 6.14 6.15 6.16 6.17 6.18 6.19 6.20 6.21 6.22 6.23 6.24 6.25 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 Diagrama inicial de classes de an alise com atributos. Diagrama de classes nal de an alise (sem opera c oes) Atividades da Modelagem Din amica . . . . . . . . . Diagrama de seq u encia Efetuar Login . . . . . . . . . Diagrama de seq u encia Consultar Saldo . . . . . . . . Diagrama de seq u encia Efetuar Saque . . . . . . . . . Diagrama de seq u encia Efetuar Dep osito . . . . . . . Diagrama de colabora c ao . . . . . . . . . . . . . . . Diagrama de Classes de An alise com Opera c oes . . . Diagrama de Estados da Classe Conta . . . . . . . . Nova hierarquia para contas. . . . . . . . . . . . . . Hierarquia de contas revisada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 205 206 214 214 215 216 216 217 218 218 218 222 228 230 232 232 233 234 235 239
Realiza c ao do caso de uso Efetuar Saque durante a an alise. . . . . . . . O modelo 4+1 para a representa c ao de arquiteturas de software. . . . Subsistemas do Sistema de Caixa Autom atico Vis ao L ogica. . . . . . Mapeamento inicial entre as classes de an alise e as classes de projeto. . Divis ao das classes de projeto entre as camadas da arquitetura. . . . . Estrutura do Padr ao State. . . . . . . . . . . . . . . . . . . . . . . . . Modelagem simplicada . . . . . . . . . . . . . . . . . . . . . . . . . . Modelagem usando o padr ao State . . . . . . . . . . . . . . . . . . . . Estrutura do Padr ao Singleton . . . . . . . . . . . . . . . . . . . . . .
Cap tulo 1
Introdu c ao
Este cap tulo dene e discute v arios conceitos fundamentais do modelo de objetos. A evolu c ao das t ecnicas de programa c ao e das abstra c oes nas linguagens de programa c ao s ao apresentados de como uma mudan ca crescente na forma de desenvolver software. O paradigma de programa c ao procedural (ou imperativo) e o paradigma orientado a objetos s ao comparados e as novas estruturas abstratas do modelo de objetos s ao apresentadas. Finalmente, o cap tulo apresenta algumas das principais limita c oes do modelo de objetos e como a engenharia de software baseada em componentes tenta super a-las.
1.1
Estrutura c ao de Software
Sistemas de software modernos requerem um alto grau de conabilidade, disponibilidade e seguran ca. Alguns exemplos s ao sistemas de controle para centrais telef onicas, sistemas banc arios, sistemas nanceiros sistemas de e-banking, etc. Entretanto, a constru c ao de sistemas de software complexos e uma tarefa dif cil que exige o emprego de t ecnicas especializadas durante todo o ciclo de vida do sistema. O modelo de objetos apresenta-se como um modelo promissor para o desenvolvimento de software con avel e robusto devido a caracter sticas inerentes ao pr oprio modelo de objetos, tais como, abstra c ao de dados, encapsulamento, heran ca e reutiliza c ao de objetos (classes e componentes). O uso de t ecnicas orientadas a objetos facilita o controle da complexidade do sistema, uma vez que promove uma melhor estrutura c ao de suas partes. Al em disso, o seu uso permite que elementos de software j a validados sejam reutilizados, promovendo a reutiliza c ao dos casos de teste. 1
Cap tulo 1: Introdu c ao
1.1.1
Gerenciamento da Complexidade do Software
Sistemas de software s ao intrinsicamente complicados e t em se tornado mais complicados ainda com os novos requisitos impostos pelas aplica c oes modernas: alta conabilidade, alto desempenho, desenvolvimento r apido e barato, tudo isso associado a uma complexidade de funcionalidade cres poss cente. E vel, e muitas vezes at e desej avel, ignorar a complexidade dos sistemas de software, mas isso n ao resolve totalmente o problema; pois ela certamente aparecer a em algum outro lugar. Aplica c oes de software que tratam de problemas complicados devem lidar com tal complexidade em alguma hora. Como seres humanos, n os empregamos v arios mecanismos para gerenciar essa complexidade, tais como abstra c ao, generaliza c ao e agrega c ao. Abstra c ao e um meio pelo qual evitamos a complexidade n ao desejada e e uma das ferramentas mais ecientes para lidarmos com o nosso mundo complexo. Cientistas de computa c ao j a reconheceram h a algum tempo que a chave para o sucesso no desenvolvimento de software est a no controle da sua complexidade. O conceito de linguagens de programa c ao de alto n vel e seus compiladores foi um grande passo em dire c ao a este objetivo, pois proporcionou uma abstra c ao do funcionamento interno do computador, permitindo que o desenvolvedor de software programasse sem precisar ser um especialista no funcionamento do hardware utilizado. Depois disso, os pesquisadores e prossionais come caram a reconhecer a necessidade de melhores processos e ferramentas para gerenciar a complexidade; como conseq u encia, surgiram os conceitos de programa c ao estruturada e bibliotecas de programas. Embora essas contribui c oes tenham sido valiosas, elas ainda deixam muito a desejar em termos de reutiliza c ao de software. Em outras palavras, existe uma complexidade ainda maior do que simplesmente tentar minimizar a complexidade local de cada parte de um programa. Um tipo de complexidade mais importante est a relacionada com a complexidade da sua organiza c ao global: a macro complexidade da estrutura de um programa ou sistema (i.e., o grau de associa c ao ou interdepend encia entre as principais partes de um programa). A estrutura dos m odulos do sistema e a comunica c ao entre eles e representada pela arquitetura de software. Esse conceito ser a visto no Cap tulo 7 (Se c ao 7.2). Podemos dizer que a complexidade de um componente ou subsistema de software e alguma medida do esfor co mental requerido para entend e-lo. De uma forma mais pragm atica, ela e fun c ao dos relacionamentos entre os diversos elementos do sistema. Complexidade e um dos principais fatores que contribui para que a produ c ao de software seja de baixa qualidade.
1.1.2
T ecnicas de Estrutura c ao de Software
Uma diferen ca vis vel entre uma organiza c ao de programa bem estruturada e uma organiza c ao mal estruturada est a na complexidade. Alguns conceitos da teoria geral de sistemas podem ser aplicados para reduzir a complexidade de sistemas de software, a saber [37]: (i) particionamento de sistemas em partes que sejam muito bem delimitadas, procedimento conhecido por modulariza c ao do sistema; (ii) representa c ao do sistema como uma hierarquia com separa c ao de n veis de abstra c ao, que proporcionam uma vis ao hier arquica do sistema; (iii) maximiza c ao da independ encia entre
as partes do sistema, que proporciona o baixo acoplamento entre os elementos do sistema; e o (iv) agrupamento das partes inter-relacionadas do sistema, o que reduz a necessidade de troca de mensagens entre as partes do sistema, nesse caso, dizemos que o sistema possui alta coes ao . O particionamento de um programa em componentes menores e individuais pode reduzir a sua complexidade at e certo ponto. Uma justicativa plaus vel para essa redu c ao e o fato do particionamento criar um n umero de interfaces bem denidas dentro do modelo, isto e, as intera c oes entre os m odulos seguem listas pr e-denidas, com as opera c oes de cada m odulo. Essas interfaces s ao muito u teis para o entendimento do programa, uma vez que mostram quais elementos s ao relevantes e quais n ao s ao em determinados contextos, estreitando o foco de aten c ao. Em outras palavras, a interface esconde informa c ao irrelevante atr as dela, sendo considerada um importante mecanismo de abstra c ao. O conceito de hierarquia e de vital import ancia tanto para o entendimento quanto para a constru c ao de sistemas. Pelo fato da mente humana ter um limite pequeno para o n umero de fatos com os quais pode lidar simultaneamente, n os podemos entender melhor os sistemas que est ao denidos de forma hier arquica [43]. Hierarquias permitem a estratica c ao de um sistema em v arios n veis de detalhes. Cada camada (ou n vel) abstrai os detalhes representados nas camadas inferiores. O conceito de camada facilita o entendimento do sistema, uma vez que possibilita o ocultamento de n veis de detalhes desnecess arios. Embora o particionamento e a estrutura hier arquica sejam conceitos muito importantes na estrutura c ao de sistemas, existe um terceiro conceito relacionado que e igualmente importante: independ encia. Este conceito implica na maximiza c ao da independ encia de cada componente do sistema para que a sua complexidade seja reduzida. Portanto, o problema n ao e meramente particionar um programa numa hierarquia, mas determinar como particionar um programa numa estrutura hier arquica de tal forma que cada subsistema seja t ao independente dos outros quanto poss vel. Portanto, modularidade pode ser denida como a propriedade de um sistema que foi decomposto num conjunto de m odulos fracamente acoplados e altamente coesos. Outra no c ao muito importante relacionada com as tr es discutidas anteriormente e o da representa c ao expl cita das inter-conex oes entre os componentes do sistema [36]. Esse foco na intera c ao entre os componentes, al em de facilitar o entendimento, possibilita uma deni c ao clara de protocolos de comunica c ao entre eles. Essas vantagens s ao percebidas mais claramente em sistemas de grande porte, onde e comum a ocorr encia de efeitos colaterais decorrentes da falta de clareza desses inter-relacionamentos.
1.1.3
Crise de Software
O termo Crise de Software1 foi cunhado na Confer encia de Engenharia de Software da OTAN em 1968, na Europa. Naquela epoca concluiu-se que os m etodos de produ c ao de software n ao eram adequados para as necessidades crescentes das ind ustrias de defesa e de processamento de dados. V arios problemas foram identicados nos sistemas de software produzidos na epoca, por exemplo,
1
do ingl es software crisis
eles eram pouco prediz veis, apresentavam uma baixa qualidade, tinham alto custo de manuten c ao e havia muita duplica c ao de esfor cos em sua constru c ao. Os processos subseq uentes foram tentativas de superar essa crise de software. Entretanto, apesar da prolifera c ao dos processos de an alise e de projeto, existem v arias evid encias de que muitos projetos de software ainda s ao entregues atrasados, com o or camento estourado e com a especica c ao incompleta. Nesse contexto, surge o modelo de objetos que, embora nos ofere ca novas ferramentas e uma abordagem mais moderna para desenvolvimento de software, e considerado mais uma abordagem evolucion aria do que revolucion aria, no sentido de que o modelo engloba conceitos bem conhecidos, inovando principalmente na maneira como s ao estruturados e utilizados. Os benef cios advindos do emprego do modelo de objetos s ao v arios, por exemplo, abstra c ao de dados/encapsulamento, modularidade, reutiliza c ao, maior facilidade de extens ao e manuten c ao.
1.2
1.2.1
Evolu c ao da Abstra c ao em Linguagens de Programa c ao

Desenvolvimento de Software
Muitos pesquisadores reconhecem que existe um relacionamento muito pr oximo entre os pensamentos e a linguagem humana usada para express a-los. De fato, a natureza da linguagem modela e d a forma aos nossos pensamentos e vice-versa: linguagem e pensamento modelam mutuamente um ao outro e n ao h a uma preced encia entre eles. A rela c ao entre programas de software e a linguagem de programa c ao usada para desenvolv e-los e semelhante [20]. Por esse motivo, as linguagens de programa c ao s ao as representa c oes abstratas mais comuns em computa c ao. Entretanto, e dif cil transformar as abstra c oes do mundo diretamente nas abstra c oes de uma linguagem de programa c ao sem ser necess ario passar por passos intermedi arios, como apresentado na Figura 1.1. Neste caso, nota c oes gr acas intermedi arias s ao u teis para ajudar o programador na representa c ao das suas abstra c oes para a linguagem. Podemos, ent ao, denir desenvolvimento de software como um processo atrav es do qual n os renamos transforma c oes sucessivas de uma representa c ao de alto n vel para uma representa c ao de mais baixo n vel execut avel num computador. Conseq uentemente, o processo inteiro e dependente das facilidades para a representa c ao de abstra c oes dispon veis na linguagem de programa c ao alvo. Se a linguagem restringe de alguma forma o modo como as abstra c oes podem ser denidas, ela certamente limitar a a modelagem das aplica c oes. A constru c ao descendente2 e uma t ecnica u til que requer que uma aplica c ao seja projetada considerando inicialmente sua macro-estrutura como um todo. Nos passos seguintes do desenvolvimento, esta estrutura e detalhada at e que uma implementa c ao seja produzida. O renamento passo-a-passo( do ingl es stepwise renement) proporciona uma estrat egia para a realiza c ao desse detalhamento [7, 39]. De fato, o processo de renamento passo-a-passo acontece at e que a solu c ao do problema se torne um programa. Este processo considera cada subproblema como um prob2
do ingl es top-down
Figura 1.1: Passos Intermedi arios da Modelagem da Realidade
lema separado, cria uma descri c ao de alto n vel para ele e ent ao rena-o em termos de outros subproblemas. A abordagem descendente e uma disciplina de Engenharia de Software madura na qual foram baseados diversos processos de projeto estruturado durante os u ltimos 30 anos. Como ser a visto na Se c ao 1.2, processos de an alise e projeto Orientado a Objetos apresentam uma alternativa para esta abordagem convencional, especialmente quando tratamos de sistemas grandes e complexos. No in cio do desenvolvimento de linguagens de programa ca o, linguagens de montagem permitiam aos projetistas escrever programas baseados em instru c oes de m aquina (operadores) que manipulavam os conte udos das loca c oes de mem oria (operandos). Portanto, as abstra c oes de dados e controle eram de muito baixo n vel. Um grande passo de evolu c ao ocorreu quando surgiram as primeiras grandes linguagens de programa c ao imperativas (Fortran e Cobol). Fortran foi importante porque introduziu a no c ao de subprogramas (fun c oes e procedimentos), enquanto Cobol introduziu a no c ao de descri c ao de dados. Subseq uentemente, Algol-60 introduziu o conceito de estrutura de bloco, procedimento, etc. Ela inuenciou fortemente numerosas linguagens de programa c ao que foram chamadas linguagens baseadas em Algol. A losoa de Algol-68 consistia da escolha de um conjunto adequado de mecanismos que deveriam ser combinados sistematicamente. Apesar da import ancia de Algol-60 para a evolu c ao das linguagens de programa c ao, foi Pascal que tornou-se a linguagem de programa c ao mais popular, principalmente por causa da sua simplicidade, sistem atica e eci encia de implementa c ao. As duas linguagens possuem estruturas de controle ricas e deni c oes de tipos e estruturas de dados, seguindo as id eias da programa c ao estruturada criadas por Wirth, Dijkstra and Hoare [16].
1.2.2
M odulos, Pacotes e Subsistemas
Desde os anos 70, as linguagens t em se preocupado em dar mais suporte para programa c ao em larga escala. Este tipo de programa c ao (complementar ` a programa c ao em pequena e m edia escala) preocupa-se com a constru c ao de programas grandes a partir de m odulos. Um m odulo e uma unidade de programa que pode ser implementado de uma maneira mais ou menos independente dos outros m odulos. Um m odulo bem projetado tem um prop osito bem denido, assim como suas interfaces de comunica c ao com outros m odulos. Tal m odulo e considerado reutiliz avel, quando tem grande chance de ser reutilizado, podendo ser incorporado a v arios programas; e modic avel, quando pode ser alterado sem causar grandes mudan cas em outros m odulos relacionados. A disciplina do ocultamento da informa c ao, tamb em conhecida como encapsulamento, foi proposta por Parnas [38], por volta de 1972 e sua id eia era encapsular vari aveis globais em um m odulo juntamente com o grupo de opera c oes que tinham acesso direto a elas. Outros m odulos podiam acessar essas vari aveis somente indiretamente, atrav es das opera c oes oferecidas pelos m odulos. odulo faz e passado para o seu cliente; o como e implementado somente Somente o que o m diz respeito ao implementador do m odulo. Se um m odulo e implementado desta forma, e dito que esse m odulo encapsula seus componentes. Para a obten c ao de uma interface bem denida, um m odulo tipicamente faz com que apenas um n umero pequeno de componentes sejam vis veis para os clientes externos. Tais componentes s ao exportados pelo m odulo, enquanto muitos outros componentes permanecem ocultos dentro dele. Portanto, encapsulamento sugere que ` a medida que uma estrutura de dados deve residir dentro de um m odulo, uma interface oferece o acesso necess ario a tais estruturas para m odulos externos. Em resumo, o encapsulamento minimiza as inter-depend encias entre m odulos escritos separadamente atrav es da deni c ao de interfaces estritas. Um conceito semelhante aos m odulos e o que conhecemos como subsistemas. Um subsistema pode ser visto como um tipo particular de m odulo que, por ser auto-contido, pode oferecer seus servi cos sem necessitar interagir com o meio externo. Seguindo esse racioc nio, um sistema pode ser visto como um subsistema de um outro sistema maior. Existem pelo menos tr es mecanismos de linguagens de programa c ao que d ao apoio ` a modulariza c ao: (i) m odulos, como implementados em Modula-2; (ii) pacotes, como implementado em Ada, Java [3] e C# [24]; e (iii) tipo abstrato de dados, tipos denidos indiretamente atrav es de suas opera c oes. Um m odulo consiste de duas partes relacionadas: (i) especica c ao do m odulo, chamada de spec e (ii) implementa c ao do m odulo, chamada de body. Enquanto a parte spec cont em um conjunto de declara c oes de estruturas de dados e assinaturas de procedimentos, a parte body cont em as implementa c oes declaradas na spec. Cada entidade declarada na spec deve estar implementada no body. Entretanto, o body pode conter estruturas de dados e procedimentos adicionais usados para implementar as entidades vis veis. Essas entidades adicionais declaradas apenas no body devem ser privadas, sendo invis veis aos clientes da spec, a m de n ao interferir na interface oferecida pelo m odulo. O trecho de c odigo a seguir apresenta um exemplo de implementado do m odulo stack na linguagem ADA. Esse m odulo representa a estrutura de uma pilha. As linhas de 1 a 6 apresentam
a especica c ao da pilha, que atrav es das opera c oes p ublicas Push(...) e Pop(...) (Linhas 4 e 5), se comunicam com os m odulos externos. Al em disso, a especica c ao dene uma vari avel que representa a capacidade m axima da pilha (Linha 2). A implementa c ao da pilha (body, linhas de 9 a 29) dene o comportamento das opera c oes da pilha (Linhas 14 a 28) e al em disso, dene um tipo Table (Linha 10) e duas vari aveis internas (Linhas 11 e 12), invis veis externamente.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
e s p e c i f i c a c ao Size : Positive ; package S t a c k i s procedure Push (E : in Integer ) ;
procedure Pop (E : out I n t e g e r ) ; end S t a c k ;
implementa c ao package body S t a c k i s type Table i s array ( P o s i t i v e range <>) of I n t e g e r ; Space : Table ( 1 . . S i z e ) ; Index : N a t u r a l := 0 ;
procedure Push (E : in I n t e g e r ) i s begin i f Index < S i z e then Index := Index + 1 ; Space ( Index ) := E ; end i f ; end Push ;
procedure Pop (E : out I n t e g e r ) i s begin i f Index > 0 then E := Space ( Index ) ; Index := Index 1 ; end i f ; end Pop ; end S t a c k ;
A maioria das linguagens de programa c ao atuais utilizam o conceito de pacotes, discutido em maiores detalhes na Se c ao 4.8 do Cap tulo 4, de uma maneira mais gen erica que em ADA. A principal diferen ca entre esses dois conceitos de pacotes e que enquanto em ADA h a uma separa c ao
expl cita entre especica c ao e implementa c ao, em linguagens como Java e C# os pacotes determinam apenas espa co de nomes, deixando a crit erio dos desenvolvedores separar ou n ao a especica c ao da implementa c ao. Os espa cos de nomes s ao utilizados como um mecanismo para organizar elementos em grupos hier arquicos, podendo controlar inclusive quais elementos s ao vis veis externamente. A quest ao da visibilidade em orienta c ao a objetos ser a abordada em detalhes na Se c ao 4.8.1 do Cap tulo 4.
1.2.3
Tipos Abstratos de Dados
A no c ao de tipos abstratos de dados (TAD) se refere ao encapsulamento de uma estrutura de dados juntamente com as opera c oes que manipulam essas estruturas dentro de uma regi ao protegida. Uma linguagem d a apoio a tipos abstratos de dados quando ela possui mecanismos que permitem a sua representa c ao diretamente. Linguagens de programa c ao como Ada e Modula-2 d ao apoio a tipos abstratos de dados, mas ainda t em certas limita c oes. As principais s ao: (i) o sistema de tipos e unidimensional, ou seja, um programa e desenvolvido como um conjunto de tipos abstratos de dados cuja estrutura e denida no n vel horizontal: as hierarquias de generaliza c ao/especializa c ao n ao podem ser representadas explicitamente. (ii) tipos abstratos de dados n ao s ao representados explicitamente em tempo de execu c ao, isto e, embora tipos abstratos de dados sejam u teis durante as fases de an alise, projeto e implementa c ao, eles desaparecem durante o tempo de execu c ao e o software se torna de novo um monte de linhas de c odigo agrupadas em m odulos completamente desestruturados. No exemplo do m odulo de pilha apresentado anteriormente, o TAD Stack seria denido pelas opera c oes p ublicas Push(...) e Pop(...), al em da vari avel p ublica Size, declarada na especica c ao do m odulo.
1.2.4
Programa c ao Orientada a Objetos
O pr oximo passo da evolu c ao das linguagens de programa c ao foi introduzido com o conceito de objetos, criado por Dahl e Nygaard com a linguagem Simula-67 [17], e consolidado com a linguagem Smalltalk-76. Simula-67 introduziu os conceitos de classe, objeto e heran ca. O modelo cl assico de objetos emprega classes para a descri c ao de objetos. Essas classes cont em a deni c ao da estrutura dos objetos (i.e. dados e fun c oes). Al em disso, atrav es dos mecanismos de heran ca e agrega c ao, classes j a existentes podem compartilhar seu comportamento com novas classes. Essencialmente, o modelo de objetos trata dados e fun c oes como aspectos indivis veis no dom nio do problema. O forte relacionamento entre o modelo de objetos e a no c ao de tipo abstrato de dados se torna evidente, uma vez que os objetos podem ser vistos como inst ancias de tipos abstrato de dados. Na verdade, na maioria das linguagens orientadas a objetos, a deni c ao de uma classe descreve um tipo de dados associado com as opera c oes que podem ser executadas nas inst ancias desse tipo.
Fazendo um panorama hist orico, destacamos seis acontecimentos principais que marcaram a cria c ao do modelo de objetos. O primeiro deles, que j a foi relatado anteriormente a introdu c ao do conceito de objetos no ano de 1967, lan camento da linguagem Simula-67. Em seguida, em 1972 Dahl escreveu um artigo sobre ocultamento de informa c oes. Apesar de nesta etapa da hist oria o conceito de objetos j a estar bem denido, apenas em 1976, com o lan camento da primeira vers ao do Smalltalk a orienta c ao a objetos foi consolidada. A partir da , o modelo de objetos evoluiu no sentido de oferecer novas linguagens de programa c ao. Em 1983 foi disponibilizada a primeira vers ao do C++, vers ao orientada a objetos da disseminada linguagem C. Em 1988, foi lan cada a linguagem Eiel, a primeira linguagem considerada orientada a objetos pura. Finalmente, j a no nal do s eculo XX, mais precisamente no ano de 1995, foi lan cada a primeira vers ao da linguagem Java, uma linguagem orientada a objetos pura, baseada na sua antecessora C++. Programa c ao orientada a objetos e um modelo de programa c ao baseado em conceitos, tais como objetos, classes, tipos, ocultamento da informa c ao, heran ca, polimorsmo e parametriza c ao. An alise e projeto orientados a objetos oferecem uma maneira de usar todos esses conceitos para a estrutura c ao e constru c ao de sistemas. Esses conceitos s ao intrinsicamente independentes de linguagens e cada uma tem sua pr opria maneira de implement a-los. A ess encia da programa c ao orientada a objetos e a resolu c ao de problemas baseada na identica c ao de objetos do mundo real pertencentes ao dom nio da aplica c ao e no processamento requerido por esses objetos, atrav es de intera c oes entre eles. Esta id eia de programas simulando o mundo real cresceu com o lan camento do Simula-67, que inicialmente foi projetada para o desenvolvimento de aplica c oes de simula c ao. Devido ao fato do mundo estar povoado de objetos, uma simula c ao de tal mundo deveria conter objetos simulados capazes de enviar e receber mensagens e reagir ` as mensagens recebidas. Conseq uentemente, na programa c ao orientada a objetos, a execu c ao de um programa consiste de um conjunto de objetos relacionados que trocam mensagens entre si, isto e, que se comunicam atrav es da execu c ao das opera c oes uns dos outros. Cada objeto tem um estado interno composto por atributos que s ao modicados mediante a recep c ao e o envio de mensagens. Programas s ao constru dos atrav es da deni c ao de classes, que se relacionam e formam hierarquias de abstra c ao (Se c ao 1.3.4). Este estilo de programa c ao tem algumas caracter sticas positivas, por exemplo: (i) modularidade, (ii) suporte expl cito para refatorar os grupos comuns, (iii) vis ao unicada de dados e opera c oes, e (iv) desenvolvimento incremental e evolucion ario. Muito do interesse no modelo de objetos e uma conseq u encia da melhor estrutura c ao do sistema e do encapsulamento entre dados e fun c oes, o que auxilia principalmente na constru c ao de programas complexos. Embora as especula c oes sobre o aumento da reutiliza c ao n ao tenham se mostrado reais, a estrutura c ao do racioc nio e o menor acoplamento proporcionado pelo conceito de objetos melhoram a qualidade do produto nal e reduzem os custos de manuten c ao do sistema. Ao longo deste livro, diversos diagramas representando aspectos diferentes de sistemas de software orientados a objetos s ao apresentados. Todos estes diagramas seguem uma nota c ao gr aca chamada UML (sigla do ingl es Unied Modeling Language) [9], na sua vers ao 2.0. A linguagem UML e uma linguagem para especicar sistemas orientados a objetos que se tornou um padr ao tanto na ind ustria quanto na academia. A linguagem UML unica as nota c oes propostas pelos
10
processos de Rumbaugh (OMT) [40], Booch [49] e Jacobson [25] e e independente do processo ou linguagem de programa c ao adotados. Ela foi padronizada por um comit e internacional que lida com tecnologias orientadas a objetos chamado Object Management Group (OMG). A linguagem UML e uma linguagem de modelagem, n ao um processo.
1.2.5
Programa c ao Orientada a Objetos vs. Programa c ao Estruturada
Para a resolu c ao de problemas, a abordagem estruturada utiliza uma t ecnica conhecida como decomposi c ao funcional. Dessa forma, uma opera c ao complexa e dividida em opera c oes menores e assim sucessivamente, at e atingir um n vel de detalhes que possa ser implementado facilmente. Dessa forma, as fun c oes assumem um papel central no desenvolvimento, que recebem dados de entrada e produzem dados de sa da. Apesar da estreita rela c ao entre dados e fun c oes, nas linguagens estruturadas esses dois conceitos s ao completamente disjuntos, tratando cada um deles de uma maneira particular. Por essa raz ao, os processos estruturados de desenvolvimento de software exigem mudan cas de contexto constantes, o que diculta o mapeamento dos artefatos de diferentes fases do desenvolvimento. O encapsulamento de dados e fun c oes, decorrente do conceito de objetos e classes foi um grande passo para a homogeniza c ao do racioc nio e a redu c ao da complexidade dos sistemas. Com essa vis ao unicada, a id eia central passa a ser a decomposi ca o de dados, ao inv es da decomposi c ao funcional. As fun c oes se tornam ligadas a um modelo de dados, que juntos formam o conceito de classe. Em OO, as classes desempenham um papel semelhante aos m odulos da programa c ao estruturada, com a vantagem de garantir a coes ao entre elementos agrupados (dados e fun c oes). A Figura 1.2 explicita a diferen ca estrutural existente entre a programa c ao estruturada e a programa c ao orientada a objetos.
Paradigma Estruturado
procedimentos A( ) B( ) C( ) D( ) E( )
Variveis Objeto 3 locais
Paradigma OO
interface pblica A() dados i j
Variveis locais Variveis Objeto 1 (tipo T1) locais
D()
Objeto 4 (tipo T4)
B() C()
Variveis locais
(tipo T3)
Objeto 2 (tipo T2)
Figura 1.2: Programa c ao Estruturada vs. Programa c ao Orientada a Objetos Apesar das particularidades de cada uma delas, existem algumas similaridades entre a programa c ao estruturada e a programa c ao orientada a objetos. A Tabela 1.1 tra ca um paralelo entre
Cap tulo 1: Introdu c ao essas duas abordagens. Tabela 1.1: Compara c ao entre a Programa c ao Estruturada e a Orientada a Objetos o Estruturada Programac a tipos de dados vari avel fun c ao/procedimento chamada de fun c ao o Orientada a Objetos Programac a classes/tipos abstratos de dados objeto/inst ancia opera c ao/servi co envio de mensagem
11
1.2.6
Linguagens Orientadas a Objetos
Na literatura existe uma distin c ao clara entre linguagens baseadas em objetos, baseadas em classes e linguagens orientadas a objetos. De acordo com a taxonomia proposta por Wegner [48] (Figura 1.3), uma linguagem e baseada em objetos3 quando ela d a apoio expl cito somente ao conceito de 4 objetos. Uma linguagem e baseda em classes quando ela d a apoio tanto para a cria c ao de objetos, quanto para o agrupamento de objetos atrav es da cria c ao de novas classes, mas n ao d a suporte a nenhum mecanismo de heran ca. Uma linguagem e dita orientada a objetos5 se ela proporciona suporte ling u stico para objetos, requer que esses objetos sejam inst ancias de classes e al em disso, oferece suporte para um mecanismo de heran ca. Portanto:
Linguagem Orientada a Objetos = Objetos + Classes + Heran ca
Baseado em Objetos
+ Classes
Baseado em Classes
+ Herana
Orientado a Objetos
Figura 1.3: Classica c ao de Wegner De acordo com essa taxonomia, linguagens como Ada85 e CLU s ao baseadas em objetos, enquanto C++ [45], Java, C#, Modula-3 [12] e Smalltalk-80 [21] s ao orientadas a objetos. Uma classica c ao mais abrangente e proposta por Blair et al. [6] que tamb em inclui as linguagens baseadas em delega c ao. Delega c ao e um mecanismo parecido com o de heran ca, que promove o compartilhamento de comportamento entre objetos, ao inv es de ser entre classes (veja a Se c ao 4.9). Blair classica uma linguagem como sendo orientada a objetos se ela d a apoio ` a cria c ao de objetos e a um
do ingl es object-based language do ingl es class-based language 5 do ingl es object-oriented language.
4 3
12
mecanismo de compartilhamento de comportamento (heran ca ou delega c ao). Para prop ositos deste livro, adotaremos a taxonomia proposta por Wegner, ou seja, para n os uma linguagem orientada a objetos d a suporte direto para objetos, classes e heran ca. O modelo de objetos compreende um conjunto de princ pios que formam a funda c ao do modelo de objetos. Um ponto muito importante na programa c ao orientada a objetos e a obten c ao de componentes reutiliz aveis e ex veis atrav es de conceitos como, por exemplo, objetos, classes, tipos, heran ca, polimorsmo, e acoplamento din amico. O conceito de heran ca e exclusivo do modelo de objetos.
1.3
1.3.1
Fundamentos do Paradigma de Objetos

O Conceito de Objeto
O modelo de objetos representa elementos que encontramos no mundo real. Esses elementos podem ser de v arios tipos, como entidades f sicas (avi oes, rob os, etc.) e abstratas (listas, pilhas, las, etc.). A caracter stica mais importante (e diferente) da abordagem orientada a objetos para desenvolvimento de software e a unica c ao dos dados e fun c oes, que tradicionalmente s ao considerados separadamente. Essa uni ao e materializada atrav es do conceito de objetos. A representa c ao unicada desses dois elementos de programa c ao resulta no que n os chamamos de encapsulamento. Al em de estruturar a representa c ao de dados e fun c oes relacionados, o encapsulamento possibilita omitir detalhes desnecess arios externamente aos objetos. A principal pol tica para garantir esse encapsulamento e a atribui c ao de n veis de visibilidade: os dados devem ser denidos como privados do objeto e s o podem ser consultados ou modicados atrav es dos seus procedimentos, que s ao p ublicos. Portanto, Objeto = dados(privados) + procedimentos(p ublicos) A comunica c ao entre dois objetos de um sistema acontece atrav es do envio de mensagens. Como um objeto n ao deve possuir atributos p ublicos, o envio de uma mensagem por um objeto deve implicar na execu c ao de uma opera c ao da interface p ublica do objeto recipiente. Como apresentado na Figura 1.4, essa restri c ao de comunica c ao visa evitar o acesso direto ao estado do objeto por parte das entidades externas a ele. Portanto, um objeto encapsula tanto o seu estado, isto e, seus dados, quanto o seu comportamento, isto e, suas opera c oes, que s ao implementadas atrav es de m etodos. No contexto de orienta c ao a objetos, comportamento dene como um objeto age e reage em termos das suas mudan cas de estado e troca de mensagens [8] e e completamente denido pelas suas opera c oes. Entretanto, na teoria de tipos abstratos de dados, o termo comportamento e usado para denotar a interface p ublica de um objeto, que e denida pelo conjunto de opera c oes aplic aveis a ele.
13
I n t e r f a c e
Mtodos
Dados
Figura 1.4: O Conceito de Objeto Em orienta c ao a objetos, o comportamento que um cliente pode realizar sobre um objeto e declarado atrav es de opera co es. Essas opera c oes s ao implementadas atrav es de m etodos e o conjunto de opera c oes e atributos p ublicos constituem a interface p ublica de um objeto (Figura 1.5). importante que que clara a diferen E ca entre uma opera c ao e seu respectivo m etodo: a primeira e abstrata (especica c ao), enquanto o segundo e concreto (implementa c ao). C++ usa o termo fun c ao membro6 para se referir a um m etodo.
Operao Operao
Mtodo Valores dos Atributos Mtodo
Mtodo
Mtodo
Operao
Operao
Figura 1.5: Opera c oes, M etodos e Atributos Em resumo, um objeto possui: (i) um estado, (ii) um comportamento bem denido, formado pelo conjunto de opera c oes da sua interface p ublica, e (iii) uma identidade u nica.
1.3.2
Classes
Uma classe e a descri c ao de um molde que especica as propriedades e o comportamento relativo a um conjunto de objetos similares. Todo objeto e inst ancia de apenas uma classe. Toda classe tem um nome e um corpo que dene o conjunto de atributos e opera co es possu das pelas suas inst ancias. E importante distinguirmos objetos de suas classes; o termo classe e usado para identicar um grupo de objetos e o termo objeto se refere a uma inst ancia de uma classe. No modelo de objetos, atributos e opera c oes s ao usualmente parte da deni c ao de uma classe.
6
do ingl es member function
14
A Figura 1.6 mostra a representa c ao em UML para classes e objetos. Uma classe pode ser representada de uma das duas formas apresentadas na Figura 1.6 (a). Um objeto, por sua vez, e representado de forma similar a uma classe, exceto pelo fato do seu nome ser sublinhado (Figura 1.6 (b)). O nome ap os os dois pontos representa a classe da qual o objeto foi instanciado (joao:Usuario).
classe Usuario nome :. codigo :. + utilizar ():. classe Usuario objeto joao:Usuario nome = Joao :. codigo ="J10" :. + utilizar ():. objeto joao:Usuario
Verso Expandida
Verso Simplificada
Verso Expandida
Verso Simplificada
(a)
(b)
Figura 1.6: Classes e Objetos em UML O fato dos atributos da Figura 1.6 possu rem visibilidade privada (-) indica que eles s o podem ser acessados internamente; em outras palavras, apenas as opera c oes da pr opria classe poder ao acessar esses atributos diretamente. Em contrapartida, os atributos e opera c oes p ublicos (+) podem ser acessados normalmente por quaisquer outros objetos do sistema. Na Se c ao 4.4.3 desde livro, ser ao apresentadas outros tipos de visibilidade. De um modo geral, uma classe e considerada bem estruturada quando: (i) proporciona uma abstra c ao bem denida de um elemento oriundo do vocabul ario do dom nio do problema ou da solu c ao; (ii) e formada por um conjunto pequeno e bem denido de responsabilidades que devem ser cumpridas pela classe; (iii) proporciona uma separa ca o clara entre a especica c ao da abstra c ao e a sua implementa c ao; e (iv) e simples e f acil de entender, e ao mesmo tempo tem capacidade de extens ao e adapta c ao.
1.3.3
Classica c ao/Instancia c ao
A abstra c ao de classica c ao/instancia c ao permite agrupar objetos similares em uma mesma categoria. Por exemplo, duas pessoas: Jo ao e Maria, podem ser classicadas como inst ancias da categoria Usuario. Classica c ao pode ser descrita como uma associa c ao e-uma, por exemplo, podemos dizer que Jo ao e-um usu ario. A Figura 1.7 apresenta a representa c ao em UML para classica c ao/instancia c ao. Como pode ser percebido, um objeto e inst ancia de apenas uma classe, enquanto uma classe pode ter v arias inst ancias associadas a ela. Neste exemplo, os objetos joao e maria s ao inst ancias da classe Usuario. O fato dos objetos dependerem da sua classe e representada atrav es de depend encias UML (setas pontilhadas). Esse relacionamento ser a explicado em detalhes na Se c ao 1.3.8. A linguagem UML foi elaborada de modo que extens oes possam ser incorporadas a ela de maneira natural. Para tanto, ela emprega o conceito de estere otipos. Atrav es de um estere otipo,
15
classe Usuario nome :String codigo :String + verificarCodigo (cod :String ):boolean
Classificao
Instanciao
<< instance_of >>
(os objetos depen dem da classe)
<<. instance_of >> maria:Usuario objeto
joao:Usuario objeto
OBS.: No contexto de um sistema de controle de bibliotecas
Figura 1.7: Exemplo de Classica c ao/Instancia c ao
e poss vel estender a UML atrav es da deni c ao de uma sem antica diferente para um elemento j a existente na linguagem (normalmente uma depend encia ou uma classe). Para denir um estere otipo, basta colocar o nome do estere otipo entre os sinais << e >> acima do nome do elemento cuja sem antica se deseja modicar. Por exemplo, gra cas ao estere otipo << instance of >>, o relacionamento de depend encia apresentado na Figura 1.7 possui uma sem antica de classica c ao/instancia c ao.
1.3.4
Abstra c ao de Dados e Hierarquias de Abstra c oes
Uma das tarefas mais importantes em desenvolvimento de software e a an alise do dom nio do problema e a modelagem das entidades e fen omenos relevantes para a aplica c ao (modelagem conceitual). A modelagem conceitual envolve dois aspectos fundamentais: (i) abstra c ao, relacionada com os nossos pensamentos na observa c ao do dom nio do problema e na deni c ao dos objetos, propriedades e a c oes relevantes para a solu c ao; e (ii) representa c ao, que est a relacionada com a nota c ao adotada para expressar o modelo concreto (ou realidade f sica). Portanto, o sucesso na cria c ao de um sistema depende da deni c ao de uma representa c ao e de um conjunto de opera c oes que sejam ambas corretas e efetivas [50]. Abstra c ao e denida como um mecanismo atrav es do qual n os observamos o dom nio de um problema e focamos nos elementos que s ao relevantes para uma aplica c ao espec ca em um determinado contexto de uso, ignorando todos os pontos irrelevantes. Ela remove certas distin c oes de tal forma que seja poss vel ver as coisas comuns entre diversas entidades. Em outras palavras, uma abstra c ao descreve as caracter sticas essenciais de um grupo de objetos que o distingue de todos os outros tipos existentes. Dessa forma, uma abstra c ao proporciona limites conceituais bem denidos, com rela c ao ` a perspectiva de um observador em particular.
16
Na area de Engenharia de Software, abstra c ao de dados (ou tipos abstratos de dados - TAD) proporciona uma abstra c ao sobre uma estrutura de dados em termos de uma interface bem denida. O princ pio da abstra c ao de dados surgiu na d ecada de 70 como uma t ecnica muito importante e efetiva para o controle da complexidade de sistemas de software. A m de alcan car esse controle da complexidade, tr es no c oes diferentes podem ser abstra das de uma observa c ao: (i) categorias, grupos ou classes; (ii) a c oes; e (iii) propriedades. Podemos, ent ao, denir tr es atividades envolvendo abstra c ao, cada qual com sua opera c ao inversa: classica c ao/instancia c ao, generaliza c ao/especializa c ao e agrega c ao/decomposi c ao. O agrupamento de objetos em categorias ou classes permite a simplica c ao do modelo, uma vez que torna poss vel o tratamento generalizado dos grupos. Dessa forma, esse tratamento se at em as caracter ` sticas comuns, abstraindo as particularidades de cada objeto. Quando um sistema tem muitos detalhes relevantes para serem representados atrav es de apenas uma abstra c ao, essa abstra c ao pode ser decomposta hierarquicamente. Dessa forma, e poss vel denir abstra c oes relacionadas, de modo que os detalhes relevantes sejam introduzidos de maneira controlada, com v arios n veis de detalhamento dispon veis. As hierarquias de classica c ao/instancia c ao foram apresentadas na Se c ao 1.3.3. As Se c oes 1.3.5 e 1.3.6 detalham as hierarquias de generaliza c ao/especializa c ao e aagrega c ao/decomposi c ao, respectivamente.
1.3.5
Generaliza c ao/Especializa c ao
As hierarquias de generaliza c ao, tamb em conhecidas como hierarquias e-um-tipo-de ou hierarquias de heran ca, denem grupos de categorias. Nessas hierarquias, as caracter sticas de uma categoria podem ser herdadas por outras, possibilitando a exist encia de categorias gen ericas (comuns) ou espec cas. Dessa forma, a generaliza c ao permite que todas as inst ancias de uma categoria espec ca sejam tamb em consideradas inst ancias de uma categoria mais abrangente; mas o inverso n ao e necessariamente v alido. Por ser um conceito intuitivo, a generaliza c ao e um mecanismo importante para representar abstra c oes do mundo real. Em UML, um relacionamento de generaliza c ao e representado por uma linha que se inicia na classe mais espec ca e termina em um tri angulo branco que aponta para a mais abrangente, como apresentado no exemplo da Figura 1.8. Nessa gura, as classes Aluno e Professor s ao representadas como tipos de Usuarios e por isso podem ser utilizadas em qualquer lugar que a classe Usuario pode ser empregada, uma vez que a opera c ao utilizar() foi herdada por ambas.
1.3.6
Agrega c ao/Decomposi c ao
As hierarquias de agrega c ao, tamb em conhecidas como hierarquias de parte-todo, possibilitam representar uma abstra c ao a partir das partes que a comp oem. Al em disso, o fato de cada parte poder possuir seus pr oprios componentes, possibilita uma refatora c ao recursiva.
17
Classe base Usuario
nome :String codigo :String + verificarCodigo (cod :String ):boolean
Generalizao Especializao
Aluno anoEscolar :int + suspender ():void Classe derivada Professor tempoServico :int + aposentar ():void Classe derivada
Figura 1.8: Exemplo de Generaliza c ao/Especializa c ao Al em da representa c ao parte-todo, o relacionamento de agrega c ao/decomposi c ao adiciona um valor sem antico ao modelo. No exemplo da Figura 1.9, o fato das partes estarem agregadas a Biblioteca tamb em representam que e poss vel existir inst ancias isoladas de Usuario e Publicacao. Para indicar a impossibilidade de exist encia das partes sem que necessariamente haja o todo, o analista pode utilizar uma varia c ao da agrega c ao, denominada composi c ao .
Biblioteca identificador :String endereco :String + listarPublicacoes ():void + listarUsuarios ():void
Usuario nome :String codigo :String + verificarCodigo (cod :String ):boolean
Publicacao numeroTombo :String nome :String + reservar ():void
Agregao
Decomposio
Figura 1.9: Exemplo de Agrega c ao/Decomposi c ao Agrega c ao e generaliza c ao s ao no c oes completamente diferentes e complementares. Eles s ao 7 conceitos ortogonais e quando empregados em conjunto formam uma ferramenta efetiva para a modelagem de sistemas. A principal diferen ca entre eles e que enquanto nas hierarquias de generaliza c ao/especializa c ao, a no c ao de heran ca de tipos est a implicitamente representada, nas hierarquias de agrega c ao/decomposi c ao isso nem sempre e verdade. Por exemplo, na hierarquia da Figura 1.8, as propriedades gerais de um Usuario, tais como nome e codigo, s ao implicitamente herdadas por um Aluno ou um Professor. Em contraste, na hierarquia da Figura 1.9, uma propriedade de Biblioteca, por exemplo o endereco, n ao e automaticamente herdada pelas suas partes.
7
Duas propriedades s ao ortogonais quando a retirada, inclus ao ou modica c ao de qualquer uma delas n ao afeta a
outra.
18
Em UML, um relacionamento de agrega c ao, apresentado na Figura 1.9, e representado por uma linha que se inicia nas partes e termina no todo, em um diamante branco. Para indicar a sem antica de composi c ao utiliza-se uma representa c ao semelhante, com a diferen ca de que o todo e indicado por um diamante negro, ao inv es de branco.
1.3.7
Associa c oes
Assim como o relacionamento de agrega c ao/decomposi c ao (Se c ao 1.3.6), uma associa c ao e um relacionamento estrutural entre classes. Por em, ao contr ario do primeiro, ela e uma rela c ao conceitual na qual a id eia de parte-todo n ao est a presente. Uma associa c ao representa uma visibilidade permanente entre dois tipos de objetos. Isto e, o relacionamento existe durante toda a vida dos objetos, embora as inst ancias que estejam conectadas possam mudar ao longo do tempo. Sendo assim, uma refer encia a um par ametro ou ` a cria c ao de objetos internos aos m etodos n ao devem ser modelados como associa c oes, e sim como uma depend encia (Se c ao 1.3.8). Em UML, agrega c ao e composi c ao s ao tipos especiais de associa c ao com uma sem antica adicional de parte/todo. O relacionamento de associa c ao entre duas classes e mostrado na Figura 1.10. Em UML, uma associa c ao e representada por uma linha que liga as duas classes associadas. Essa linha pode ter uma seta no nal, indicando que o uxo de controle da associa c ao ui apenas na dire c ao para onde a seta aponta. Na Figura 1.10 s ao apresentados exemplos de associa c oes que envolvem multiplicidades. A multiplicidade de uma associa c ao indica quantas inst ancias de cada uma das classes envolvidas poder a estar associada com a outra. No primeiro exemplo, o n umero 1 e o s mbolo * nas pontas da associa c ao entre as classes Publicacao e Exemplar indica que nesse modelo, cada inst ancia de Pubicacao pode estar associada a v arias inst ancias de Exemplar, enquanto que um Exemplar est a associado a exatamente uma Publicacao. No segundo exemplo, cada inst ancia de Usuario poder a estar associada a zero ou uma inst ancia de Emprestimo, enquanto o Emprestimo n ao possui refer encias sobre os Usuarios (associa c ao unidirecional). A quantidade zero ou um e indicada pelo s mbolo 0..1. Outros exemplos de conven c oes de UML para a especica c ao de multiplicidades de associa c oes s ao apresentados do lado direito da gura. Na aus encia de uma especica c ao de multiplicidade, assume-se por padr ao que se trata de uma multiplicidade 1. Para aumentar a expressividade de um diagrama de classes, associa c oes entre duas classes podem ser nomeadas, indicando a maneira como inst ancias dessas classes se relacionam. Por exemplo, analisando a Figura 1.10 (b) e poss vel perceber que Usuario e Emprestimo se associam devido a uma rela c ao de realiza c ao. Na fase de codica c ao do sistema, cada associa c ao, seja ela simples, agrega c ao ou composi c ao, e materializada no c odigo-fonte das classes de maneira uniforme: atrav es de um atributo do tipo da classe agregada. Dessa forma, apesar de n ao herdar o comportamento das classes associadas, as suas opera c oes p ublicas podem ser acessadas normalmente. No caso de relacionamentos unidirecionais, o atributo e adicionado ` a classe de onde a seta se origina, uma vez que apenas esta classe conhece a outra.
19
Publicacao
possuir/referenciar 1 *
Exemplar
LEGENDA (cardinalidade) : 1 * 0..1 n..m 1..* Um e somente um Qualquer nmero a partir de zero at o infinito Zero ou um Qualquer nmero no internalo entre n e m, inclusive Qualquer nmero positivo
(a) Bidirecional
Usuario realizar 0..1 Emprestimo
(b) Unidirecional
Figura 1.10: Associa c oes em UML
1.3.8
Depend encias
O relacionamento de depend encia e usado quando se quer mostrar que um elemento usa outro. Usar, neste contexto, pode signicar envia uma mensagem, cria uma inst ancia, retornar um objeto do tipo, etc. Refer encias a par ametros de um determinado tipo e cria c ao de objetos normalmente s ao modeladas como depend encias. Apesar de ser o tipo de relacionamento mais fraco que pode existir entre dois elementos, esse relacionamento de uso estabelece que uma mudan ca na especica c ao do elemento referenciado pode afetar os elementos que o utilizam. Como pode ser visto na Figura 1.11, em UML uma depend encia e representada gracamente por uma linha pontilhada cuja seta aponta para o elemento do qual se depende. No modelo apresentado na Figura 1.11, temos que a classe Usuario depende da Exemplar, isto e, se a classe Exemplar sofrer mudan cas isso poder a afetar a classe Usuario. Essa depend encia se baseou na seguinte regra de neg ocio hipot etica: se o exemplar for devolvido, o cliente deve ser informado. O estere oripo << use >> indica que um Usuario pode utilizar uma refer encia de Exemplar. O relacionamento de depend encia pode ser utilizado entre classes, objetos, pacotes, e at e mesmo casos de uso, que ser ao vistos no Cap tulo 2.
Usuario << use >> Exemplar
Figura 1.11: Relacionamento de Depend encia em UML
1.4
An alise e Projeto Orientado a Objetos
Processos de desenvolvimento de software, independentemente dos m etodos empregados, possui basicamente as quatro etapas seguintes: (i) especica c ao do problema; (ii) entendimento dos requisitos; (iii) planejamento da solu c ao; e (iv) implementa c ao de um programa numa dada linguagem de programa c ao. Um processo de an alise e projeto auxilia na constru c ao de um modelo do dom nio de um problema e na adi c ao de detalhes de implementa c ao a esse modelo. A abordagem orientada a
20
objetos para constru c ao de sistemas permite que um mesmo conjunto de conceitos e uma mesma nota c ao sejam usados atrav es de todas as fases do desenvolvimento do software: an alise, projeto e implementa c ao. Neste cap tulo, eu til denirmos alguns conceitos. No contexto deste livro, um m etodo e um conjunto de atividades sistem aticas para realizar uma tarefa. Uma t ecnica e um modo de executar as atividades recomendadas por um m etodo e um processo e um conjunto de m etodos e t ecnicas com os quais um objetivo pode ser realizado. Um bom processo de an alise e projeto deve proporcionar mais do que uma simples nota c ao: ele deve fornecer orienta c oes sobre os passos que ser ao executados nos diversos est agios de desenvolvimento e deve cobrir todo o ciclo de desenvolvimento de software.
1.4.1
Processos Tradicionais vs. Processos Orientados a Objetos
Em 1970 surgiu um dos primeiros modelos propostos para processos de desenvolvimento de software: o modelo cascata, tamb em conhecido como modelo cl assico ou abordagem descendente [44]. Com o objetivo principal de estabelecer uma ordem no desenvolvimento de grandes produtos de software, o modelo cascata dene etapas seq uenciais de desenvolvimento, especicadas com base nas atividades de desenvolvimento de software praticadas na epoca. Como pode ser visto na Figura 1.12, o modelo cascata classica o desenvolvimento de software em oito etapas (ou fases) estruturadas como uma cascata. Nesse modelo, uma fase s o pode ser iniciada ap os a conclus ao da sua antecessora. Os pap eis envolvidos em cada fase s ao denidos de acordo com a natureza das atividades desempenhadas: (i) representa c ao das expectativas dos usu arios (especica c ao de requisitos); (ii) modelagem do sistema (an alise e projeto); (iii) implementa c ao em uma linguagem de programa c ao espec ca (codica c ao); (iv) execu c ao de testes no ambiente de desenvolvimento (testes de unidade e integra c ao e teste de sistema); (v) execu c ao de testes no ambiente do usu ario (teste de aceita c ao); e (vi) utiliza c ao, corre c ao e evolu c ao do sistema (opera c ao e manuten c ao). Al em da divis ao de fases bem denidas, outro motivo para o modelo cascata ter se tornado uma refer encia para muitos modelos posteriores, e o fato dele ser centrado em documenta c ao. Como pode ser visto na Figura 1.12, a documenta c ao do sistema e atualizada em todas as etapas do desenvolvimento, facilitando inclusive a comunica c ao entre as fases do modelo. Apesar do seu impacto para a engenharia de software, o modelo cascata ainda e considerado muito r gido, com pouca intera c ao com o usu ario e com pouca enfase na ger encia do desenvolvimento. A rigidez do modelo e uma conseq u encia da impossibilidade de voltar para uma fase anterior do desenvolvimento. Dessa forma, o modelo cascata s o e adequada quando o sistema n ao e muito grande, e pertence a um dom nio est avel e bem conhecido da equipe de desenvolvimento. Por esse motivo, surgiram algumas evolu c oes do modelo cascata que tentam solucionar algumas das suas deci encias. Alguns exemplos das varia c oes do modelo cascata s ao: (i) modelo cascata relaxado, que possibilita que o uxo de desenvolvimento volte para atividades anteriores, tornando o modelo mais pr oximo da realidade atual; (ii) modelo cascata com prototipa c ao, que prop oe o desenvolvimento de
21
prot otipos a serem validados pelos usu arios, antes do in cio do desenvolvimento, e (iii) modelo em V, que ressalta a rela c ao entre as atividades de teste e as de desenvolvimento.
Especificao de Requisitos Anlise Projeto Codificao Testes de Unidade e Integrao Teste de Sistema Teste de Aceitao Operao e Manuteno
Documentao
Figura 1.12: Modelo Cascata Uma evolu c ao mais estrutural do modelo cascata e o modelo espiral, originalmente proposto por Boehm em 1988. Al em das fases tradicionais do modelo cascata, este modelo adiciona o conceito de an alise de risco, realizada constantemente durante o desenvolvimento evolutivo incremental. Como pode ser visto na Figura 1.13, o modelo espiral e ex vel, possibilitando ajustes em qualquer fase do desenvolvimento, inclusive na especica c ao de requisitos. Essa caracter stica o torna mais adequado ao desenvolvimento de software atual, reduzindo as chances de insucesso no desenvolvimento. A dimens ao radial no espiral da Figura 1.13 representa o custo acumulado do projeto, enquanto a dimens ao angular representa o progresso atrav es da espiral. O modelo espiral e composto de quatro grandes fases de desenvolviment, representadas pelos quatro quadrantes da espiral da Figura 1.13. Cada quadrante possui atividades, que s ao executadas durante o percurso da espiral. Um ciclo (ou itera c ao) de desenvolvimento se inicia no primeiro quadrante (determina c ao de objetivos, alternativas e restri c oes), onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estrat egia para alcan car os objetivos. Em seguida, no segundo quadrante (avalia c ao de alternativas, identica c ao e solu c ao de riscos) e feita a an alise e avalia c ao dos risco previstos e dos respectivos planos de conten c ao. O modelo recomenda a utiliza c ao de prot otipos para auxiliar a an alise dos riscos. O projeto s o continua se os riscos forem considerados aceit aveis. No terceiro quadrante do desenvolvimento, ocorre o desenvolvimento propriamente dito. Neste momento do desenvolvimento, o modelo espiral sugere a execu c ao do modelo cascata, visto anteriormente. Finalmente, no u ltimo quadrante de cada itera c ao, o produto constru do e avaliado e al em disso, a pr oxima itera c ao do desenvolvimento e planejada, para iniciar o ciclo seguinte a partir do primeiro
22 quadrante.
Por ser uma abordagem evolucion aria incremental, o desenvolvimento orientado a objetos segue o modelo espiral de desenvolvimento. No decorrer do desenvolvimento orientado a objetos, as fases de an alise e projeto n ao s ao fases distintas e monol ticas; ao contr ario, elas s ao apenas passos ao longo do caminho do desenvolvimento incremental e iterativo do software.
Figura 1.13: Modelo Espiral
Metodologias de projeto orientadas a objetos promovem uma melhoria substancial sobre os modelos tradicionais. A id eia chave da an alise e projeto orientados a objetos e o foco em objetos e classes, ao inv es de fun c oes (ou procedimentos). O projetista n ao come ca pela identica c ao das diferentes funcionalidades do sistemas, mas pela identica c ao dos objetos que o modelam. Uma motiva c ao para essa abordagem e que mudan cas na especica c ao dos requisitos tendem a afetar menos os objetos do que as fun c oes. Conseq uentemente, o emprego de objetos produz sistemas que s ao menos vulner aveis a mudan cas. Al em disso, componentes de um software orientado a objetos t em uma probabilidade maior de serem reutilizados, pois encapsulam representa c ao de dados e implementa c ao. Outra vantagem importante do modelo de objetos e o fato dele oferecer uma melhor integra c ao das diferentes fases do desenvolvimento, j a que todas elas manipulam as mesmas abstra c oes: objetos e classes.
23
1.4.2
Limita c oes do Modelo de Objetos
Apesar do amadurecimento relativamente alto das linguagens, processos e ferramentas de apoio ao desenvolvimento orientado a objetos, existe muito trabalho ainda a ser feito para o oferecimento de suporte para projetos de grande porte usando processos orientados a objetos. A diculdade se deve ` a diculdade de se gerenciar a complexidade crescente dos sistemas utilizando unidades de abstra c ao pequenas,como as classes. Um grande passo para superar essa limita c ao e a ado c ao de representa c oes abstratas do sistema, como por exemplo o conceito de arquitetura de software, que ser a apresentado do Cap tulo 7. Outra limita c ao do modelo de objetos e a baixa granularidade de reutiliza c ao de software. No desenvolvimento orientado a objetos n ao e t ao simples obter elementos reutiliz aveis entre diversas aplica c oes, especialmente usando-se heran ca. Existe a necessidade de t ecnicas mais efetivas para a obten c ao de reutiliza c ao de software. Com o uso de heran ca, os objetos tornarem-se muito dependentes da aplica c ao para a qual foram projetados. Para promover um maior desacoplamento e uma reutiliza c ao de c odigo em alta granularidade, cada vez mais est a se utilizando o conceito de engenharia de software baseada em componentes, que ser a apresentado na Se c ao 1.5 e e complementar ao desenvolvimento orientado a objetos.
1.5
1.5.1
Engenharia de Software Baseada em Componentes

Componentes de Software
Apesar de todas as vantagens atribu das ` a programa c ao modular do modelo de objetos (classes e pacotes), os desenvolvedores de software identicaram novas necessidades de aperfei coamento da modulariza c ao. A partir do conceito de m odulo, apresentado na Se c ao 1.2, foram denidas novas restri c oes com o intuito de reduzir o acoplamento entre os m odulos relacionados e conseq uentemente reduzir as depend encias do sistema. Dessa forma surgiu o conceito de componente de software. A id eia de utilizar o conceito de componentes na produ c ao de software data de 1976 [32]. Apesar desse tempo relativamente longo, o interesse pela engenharia de software baseada em componentes s o foi intensicado vinte anos depois, ap os a realiza c ao do Primeiro Workshop Internacional em Programa c ao Orientada a Componentes, o WCOP96. Apesar de ser um conceito muito utilizado no universo do hardware, n ao existe um consenso geral sobre a deni c ao do que seja um componente de software. Por em, um aspecto muito importante e sempre ressaltado na literatura: componente de software e um m odulo que encapsula dentro de si seu projeto e implementa c ao, al em de todo acesso ao meio externo (outros componentes) ser sempre mediado atrav es de interfaces pr e-denidas. O baixo acoplamento decorrente dessa pol tica proporciona muitas exibilidades, tais como: (i) facilidade de montagem de um sistema a partir de componentes j a existentes (reutiliza c ao em larga escala); e (ii) facilidade de substitui c ao de componentes que implementam interfaces equivalentes.
24
Uma deni c ao complementar de componentes, adotada na maioria dos trabalhos publicados atualmente, foi proposta em 1998 [46]. Segundo Szyperski, um componente de software e uma unidade de composi c ao com interfaces especicadas atrav es de contratos e depend encias de contexto expl citas. Sendo assim, al em de explicitar as interfaces com os servi cos oferecidos (interfaces providas), um componente de software deve declarar explicitamente as depend encias necess arias para o seu funcionamento, atrav es das interfaces requeridas. A Figura 1.14 mostra a representa c ao UML de dois componentes de software conectados. O componente SistemaDeEmprestimos oferece os servi cos da interface IEmprestimo e necessita dos servi cos da interface ICadastro. J a o componente SistemaDeCadastro oferece os servi cos da interface ICadastro e n ao necessita de nenhum servi co externo. Perceba que os componentes se conectam e o u nico conhecimento que um tem sobre o outro s ao os servi cos das suas interfaces.
Componente << component >> Interface Provida SistemaDeEmprestimos IEmprestimo Interface Requerida Componente << component >> SistemaDeCadastro
ICadastro
Figura 1.14: Representa c ao de um componente UML Al em dessa distin c ao clara entre interfaces providas e requeridas, os componentes seguem tr es princ pios fundamentais, que apesar de serem comuns ao modelo de objetos, representam um aumento de granularidade da abstra c ao. S ao eles [14]: 1. Unica c ao de dados e fun co es: Um componente deve encapsular o seu estado (dados relevantes) e a implementa c ao das suas opera c oes oferecidas, que acessam esses dados. Assim como acontece em OO, essa liga c ao estreita entre os dados e as opera c oes ajudam a aumentar a coes ao do sistema; 2. Encapsulamento: Os clientes que utilizam um componente devem depender somente da sua especica c ao, nunca da sua implementa c ao. Essa separa c ao de interesse8 reduz o acoplamento entre os m odulos do sistema e melhora a manuten c ao do mesmo. 3. Identidade: Assim como os objetos, cada inst ancia de componente possui um identicador u nico que o difere das demais.
1.5.2
Reusabilidade, Modularidade e Extensibilidade
Como discutido na Se c ao 1.1.3, a produtividade e uma preocupa c ao constante da ind ustria de software. Durante a evolu c ao das tecnologias e processos de desenvolvimento, constatou-se que uma das raz oes principais para o problema da baixa produ c ao de software e a diculdade para reutilizar o c odigo gerado pelos modelos tradicionais. O modelo de objetos representa uma evolu c ao nesse sentido, j a que promove a modularidade e o encapsulamento; hierarquias de classes e objetos s ao,
8
do ingl es separation of concerns
25
em geral, componentes port aveis entre aplica c oes. Se bem projetados, esses componentes podem ser reutilizados em v arias aplica c oes. Por em, como visto na Se c ao 1.4.2, apesar das suas qualidades, o modelo de objetos sozinho n ao e suciente para maximizar a reutiliza c ao de software em larga escala. Para isso, ele necessita de evolu c oes relativas principalmente ` a granularidade de reutiliza c ao e` a redu c ao do acoplamento entre os m odulos do sistema. Essas limita c oes podem ser compensadas utilizando-se o conceito de componente de software. Meyer, o criador da linguagem orientada a objetos Eiel [33], aponta cinco crit erios para a obten c ao de modularidade. Esses crit erios s ao gerais e podem ser aplicados a qualquer tipo de modelo, embora seja mais dif cil segui-los usando-se modelos tradicionais. Os crit erios s ao os seguintes: (i) decomponibilidade: facilidade para particionar o sistema em unidades manej aveis; (ii) componibilidade: m odulos podem ser livremente combinados em outros sistemas; (iii) entendimento: a compreens ao de uma parte contribui para o entendimento do todo; (iv) continuidade: pequenas mudan cas no sistema implicam em pequenas mudan cas no comportamento; e (v) prote c ao de condi co es excepcionais: condi c oes excepcionais ou err oneas s ao connadas aos subsistemas nas quais elas ocorrem ou afetam apenas as partes diretamente a elas relacionadas. Todos esses crit erios s ao mais facilmente alcan cados quanto utilizamos paradigmas de desenvolvimento que visam o baixo acoplamento do desenvolvimento, abstraindo-se as particularidades da implementa c ao. Al em disso, o aumento de granularidade das unidades de desenvolvimento favorece ainda mais a modularidade e reutiliza c ao. Al em do baixo acoplamento que deve haver entre os componentes, existe um outro fator que inuencia diretamente o grau de reuso dos elementos de um sistema: o contexto de uso. Em outras palavras, estudos atuais mostram que um componente de software tem muito mais chance de ser reutilizado quando conhecemos os dom nios espec cos onde ele pode ser utilizado.
1.5.3
Desenvolvimento Baseado em Componentes
O Desenvolvimento Baseado em Componentes (DBC) pode ser visto como um paradigma de desenvolvimento de software onde a unidade b asica e o componente. A alta granularidade de desenvolvimento do DBC facilita a constru c ao de sistemas complexos, al em de viabilizar a reutiliza c ao sistem atica em larga escala. Sempre pensando em componentes, o DBC possui duas vertentes complementares [44]: (i) desenvolvimento para reuso, que consiste no desenvolvimento de componentes elementares que podem ser utilizados em sistemas maiores; e (ii) desenvolvimento com reuso, que consiste na composi c ao de sistemas, a partir de componentes j a existentes. Apesar de ser um novo paradigma de programa c ao, o DBC e na verdade complementar ao desenvolvimento orientado a objetos. Pela inexist encia de linguagens orientadas a componentes e pela orienta c ao a objetos proporcionar uma representa c ao compat vel com a realidade, a maioria dos autores recomenda o desenvolvimento para reuso seja realizado com linguagens orientadas a objetos. A u nica restri c ao recomendada e que essas linguagens possuam o conceito de m odulo (por exemplo, pacotes) e interface, como por exemplo Java e C#. A populariza c ao do DBC est a sendo motivada principalmente pelas press oes sofridas na
26
ind ustria de software por prazos mais curtos e produtos de maior qualidade. O aumento de produtividade e decorrente da reutiliza c ao de componentes existentes na constru c ao de novos sistemas. J a o aumento da qualidade e uma conseq u encia do fato dos componentes utilizados j a terem sido empregados e testados em outros contextos. Por em, vale a pena ressaltar que apesar desses testes pr evios serem ben ecos, a reutiliza c ao de componentes n ao dispensa a execu c ao dos testes no novo contexto onde o componente est a sendo reutilizado.
1.6
Resumo
As diculdades enfrentadas na epoca da crise do software evidenciaram a necessidade de se utilizar t ecnicas sistem aticas de estrutura c ao dos sistemas. Com o objetivo de facilitar a constru c ao de sistemas complexos, as linguagens de programa c ao foram incorporando novos conceitos, tais como instru c oes de alto n vel, m odulos, objetos e classes. A adi c ao desses conceitos proporcionou tanto um aumento da granularidade do desenvolvimento, quanto o encapsulamento crescente dos dados e fun c oes relacionados entre si. Com o advento da Programa c ao Orientada a Objetos, conceitos como objetos, classes e hierarquias de abstra c ao ganharam evid encia. Al em de encapsular seus dados e suas fun c oes, um objeto se comunica com outro atrav es da troca de mensagens, que consiste na execu c ao de opera c oes do objeto alvo. Todo objeto e inst ancia de exatamente uma classe. Sendo assim, uma classe e a descri c ao de um molde que especica as propriedades e o comportamento relativo a um conjunto de objetos similares. Classes podem ser estruturadas de forma hier arquica, atrav es do conceito de hierarquias de abstra c ao. As duas principais hierarquias de abstra c ao existentes no paradigma de objetos s ao: generaliza c ao/especializa c ao e agrega c ao/decomposi c ao. As hierarquias de generaliza c ao/especializa c ao representam a id eia de heran ca de tipo, isto e, a subclasse e-um-tipo-da superclasse. J a as hierarquias de agrega c ao/decomposi c ao s ao utilizadas para decompor a classe atrav es das partes que a comp oe. Essas hierarquias s ao complementares e juntas, oferecem o arcabolso b asico para modelar sistemas orientados a objetos. Assim como as linguagens de programa c ao, os processos de desenvolvimento de software tamb em evoluiram. O modelo de desenvolvimento tradicional, conhecido como modelo cascata, representa um marco no desenvolvimento de software, estruturando-o em fases bem delimitadas, que deveriam ser executadas sequencialmente. O car ater interativo do desenvolvimento de software motivou v arias evolu c oes do modelo cascata e uma delas e o modelo espiral. Al em de representar o processo de desenvolvimento de maneira iterativa, esse modelo adicionou uma fase importante para a constru c ao de software: a an alise de risco. Nesta abordagem o software entregue aos poucos, o que aumenta a modularidade do sistema constru do. O desenvolvimento de software orientado a objetos adota o modelo espiral. Apesar de todas as vantagens da orienta c ao a objetos, ele apresenta algumas limita c oes que incentivam a pesquisa por novos paradigmas e tecnologias complementares. O aumento do tamanho e complexidade do software, por exemplo, desperta a necessidade de se ter unidades de desen-
27
volvimento com granularidade superior ` as classes. Al em disso, a exig encia po tempo e costo de desenvolvimento cada vez menores evidencia a necessidade de t ecnicas de reutiliza c ao em grande escala. Seguindo essa dire c ao, o conceito de desenvolvimento baseado em componentes vem se apresentando como uma tend encia para suprir as deci encias do paradigma de objetos. Vale a pena refor car o car ater complementar das duas tecnologias, uma vez que cada componente de software pode ser incarado como um sistema orientado a objetos.
1.7
Exerc cios
1. Explique e contraste cada um dos seguintes pares de termos: (i) inst ancia e classe; (ii) comportamento e estado; (iii) agrega c ao e heran ca; (iv) heran ca e delega c ao. 2. D e um exemplo de duas hierarquias: uma de generaliza c ao/especializa c ao e outra de agrega c ao/decomposi c ao. Descreva as diferen cas e similaridades entre as duas hierarquias. 3. Construa uma hierarquia que represente os diversos tipos de contas dispon veis para os clientes do seu banco. Lembre-se de representar a classe mais gen erica, denominada ContaBancaria. 4. Dena atributos e opera c oes para o tipo abstrato de dados CarteiraDeDinheiro. Pense a respeito do comportamento de uma carteira e sobre os atributos relacionados com esse comportamento. 5. Dena uma classe representando uma pessoa com os seguintes atributos: nome, ano de nascimento e altura (em metros). Dena opera c oes para a inicia c ao desses atributos. Adicione uma opera c ao que retorna a idade aproximada de uma pessoa de acordo com um determinado ano de entrada. Adicione outra opera c ao que retorna sua altura em cent metros. 6. Dena uma classe para um tipo abstrato de dados ItemDeEstoque. Ela deve conter os atributos do n vel de estoque e pre co unit ario. Dena m etodos para consultar os valores desses atributos e tamb em para inici a-los usando par ametros. Adicione mais dois m etodos para permitir a atualiza c ao do n vel de estoque de forma apropriada (isto e, para baixa e reposi c ao de estoque). 7. Suponha que voc e esteja desenvolvendo uma classe que represente um baralho de cartas. Quais opera c oes voc e deveria oferecer na interface p ublica da classe? Faria sentido voc e modelar essa abstra c ao usando duas classes separadas: uma para modelar o baralho e outra para representar as cartas? Por qu e? 8. Para os diagramas de classe da Figura 1.15, discuta os erros de modelagem cometidos (caso eles existam) e proponha solu c oes corretivas. 9. Crie uma hierarquia de generaliza c ao/especializa c ao que modele os alimentos encontrados nas prateleiras de um supermercado. Identique atributos associados a cada uma das classes. 10. Crie um modelo de objetos que represente um carro que possa ser colocado e retirado de uma garagem. Quantas abstra c oes voc e acha que s ao necess arias para que o modelo represente
28
VeculoTerrestre Veculo Carro tipoDeVeculo:TipoVeiculo
CarroAzul
CarroVerde
CarroAmarelo
onde TipoVeiculo um enumerado = {Carro, Caminho, nibus}
(a)
Pneus Lataria Motor
(b)
Carro
(c)
Figura 1.15: Diagramas de classes com Poss veis Erros de Modelagem o mais elmente poss vel a realidade? Quais opera c oes voc e poderia oferecer na interface p ublica das classes usadas? 11. Dena uma hierarquia de classes que represente uma cole c ao de n umeros. Uma cole c ao e um grupo de objetos. Um conjunto e um tipo de cole c ao onde n ao existem duplicatas e uma lista e uma cole c ao onde seus elementos est ao ordenados. Identique o comportamento de cada tipo abstrato de dados envolvido na sua modelagem. 12. Modele uma hierarquia de classes parcial para um sistema de controle de reservas e ocupa c oes de um hotel. O hotel e constitu do por um conjunto de quartos (simples e duplos), audit orios para confer encias e sal oes de festas. O sistema controla a ocupa c ao e desocupa c ao dos seus c omodos, bem como, permite que o usu ario verique o estado atual de cada c omodo, isto e, se ele est a ocupado ou desocupado. 13. Classique e crie uma hierarquia de generaliza c ao/especializa c ao contendo os diferentes tipos de itens encontrados na biblioteca de uma universidade. Sugest ao: livros, peri odicos, teses, tas de v deo, DVD etc. Identique os atributos e as opera c oes de cada tipo abstrato de dados criado.
Cap tulo 2
Modelagem de Casos de Uso

2.1 Introdu c ao
No contexto do software, a fase de especica c ao de requisitos tem o objetivo de representar a id eia do usu ario a respeito do sistema que ser a desenvolvido. Essa representa c ao e feita atrav es do documento de requisitos, que deve compreender a necessidade real dos usu arios e suas expectativas, dimensionar a abrang encia do sistema e delimitar o seu escopo. Em geral, os requisitos podem ser vistos como condi c oes ou capacidades necess arias para resolver um problema ou alcan car um objetivo. Para a elicita c ao dessas capacidades, os processos normalmente estruturam a fase de especica c ao de requisitos nas quatro etapas seguintes: (i) identica c ao do dom nio do problema; (ii) identica c ao das funcionalidades esperadas pelo sistema (objetivos); (iii) deni c ao de restri c oes existentes para o desenvolvimento; (iv) identica c ao dos atributos de qualidade desejados. As funcionalidades especicadas para o sistema e os seus atributos de qualidade recebem um tratamento diferenciado no documento de especica c ao de requisitos. Por essa raz ao, os requisitos s ao classicados em dois tipos [44]: (i) requisitos funcionais, composto pelas funcionalidades especicadas; e (ii) requisitos n ao funcionais, que materializam os atributos de qualidade do sistema. Apesar de n ao representarem funcionalidades diretamente, os requisitos n ao-funcionais podem interferir na maneira como o sistema deve execut a-las. De acordo com a norma ABNT/ISO 9126, os requisitos n ao-funcionais de um software podem ser classicados em seis grupos, de acordo com a sua caracter stica principal: (i) completude (do ingl es functionality), que quantica a grau de satisfa c ao das necessidades do cliente; (ii) conabilidade, que identica a capacidade do software em manter a sua integridade ap os a ocorr encia de falhas n ao controladas; (iii) usabilidade, que identica a facilidade de se compreender o funcionamento e opera c ao do software; (iv) eci encia, que identica a capacidade do software em 29
30
Cap tulo 2: Casos de Uso
desempenhar as suas atividades de forma adequada em rela c ao ao tempo e aos recursos alocados; (v) manutenibilidade, que identica a capacidade do software em sofrer modica c oes; e (vi) portabilidade, que identica a capacidade de adapta c ao do software quando transferido para outros ambientes e/ou plataformas. Em UML, a nota c ao utilizada para a representa c ao dos requisitos do sistema o diagrama de casos de uso. Pelo fato da UML ser uma linguagem unicada, os processos que a utilizam evidenciam a import ancia dos casos de uso. Esses artefatos, que representam o objetivo do sistema, e a base para todo o processo de desenvolvimento, sendo o ponto de liga c ao entre o cliente e toda a equipe de desenvolvimento. A modelagem de casos de uso e uma t ecnica que auxilia o entendimento dos requisitos de um sistema computacional atrav es da cria c ao de descri c oes narrativas dos processos de neg ocio, al em de delimitar o contexto do sistema computacional [29]. Um caso de uso e uma narrativa que descreve uma seq u encia de eventos de um agente externo (ator) usando o sistema para realizar uma tarefa. Casos de uso s ao utilizados para descrever os requisitos funcionais, que indicam o que o sistema dever a ser capaz de fazer, sem entrar em detalhes sobre como essas funcionalidades ser ao materializadas. Como pode ser visto na Figura 2.1, o modelo de casos de uso e um dos principais artefatos oriundos da fase de especica c ao de requisitos e serve de entrada para a fase de an alise. Casos de uso bem estruturados denotam somente o comportamento essencial do sistema ou subsistema e n ao podem ser nem muito gerais, a ponto de prejudicar o seu entendimento, nem muito espec cos, a ponto de detalhar como as tarefas ser ao implementadas.
Especificao de Requisitos Especificao dos Requisitos ou Modelo Contextual do Sistema Ponte (artefato comum)
Anlise Modelo de Classes de Anlise ou Modelo Conceitual
Modelo de Casos de Uso
Figura 2.1: Casos de Uso na Especica c ao dos Requisitos Al em de capturar o conhecimento de clientes e futuros usu arios do sistema sobre seus requisitos, casos de uso tamb em s ao u teis para denir cronogramas e auxiliam na elabora c ao dos casos de teste do sistema. A m de xar os conceitos apresentados neste cap tulo, ser a utilizado o exemplo de um sistema de controle de bibliotecas, descrito a seguir.
Enunciado: Sistema de Controle de Bibliotecas Um sistema de controle de bibliotecas e um sistema computacional usado para controlar o empr estimo e a devolu c ao de exemplares de uma biblioteca. O usu ario pode fazer um empr estimo de um exemplar durante um certo per odo e, ao nal desse tempo, o exemplar deve ser devolvido, ou o empr estimo deve ser renovado.
Cap tulo 2: Casos de Uso O atendente e um funcion ario que interage com os usu arios e com o sistema de controle da biblioteca atrav es de um terminal. As principais caracter sticas do sistema s ao listadas a seguir: 1. Um usu ario do sistema, que pode ser um aluno, um professor ou um outro funcion ario da universidade, pode reservar publica c oes e tamb em cancelar reservas previamente agendadas. 2. Um usu ario deve estar devidamente cadastrado no sistema para usar os seus servi cos. O sistema e operado pelo atendente da biblioteca, que tamb em e um funcion ario da universidade. 3. Um usu ario pode emprestar exemplares previamente reservados ou n ao. Se foi feita uma reserva, ela deve ser cancelada no momento do seu empr estimo. 4. No caso da devolu c ao de um exemplar em atraso, existe uma multa que deve ser paga. Essa multa e calculada com base no n umero de dias em atraso. Al em disso, se o exemplar estiver atrasado por mais de 30 dias e se o usu ario n ao for um professor, al em de pagar a multa, o usu ario e suspenso por um per odo de 2 meses. 5. Um exemplar da biblioteca pode ser bloqueado/desbloqueado por um professor por um per odo de tempo. Nesse caso, o exemplar ca dispon vel numa estante, podendo ser consultado por usu arios da biblioteca, mas n ao pode ser emprestado. 6. O per odo de empr estimo e vari avel, dependendo do tipo de usu ario (aluno, funcion ario ou professor). 7. A manuten c ao dos dados do acervo da biblioteca e feita pela bibliotec aria, que tamb em e funcion aria da universidade. Essa funcion aria e respons avel pela inclus ao de novos exemplares, exclus ao de exemplares antigos e pela atualiza c ao dos dados dos exemplares cadastrados. Os exemplares podem ser livros, peri odicos, manuais e teses. As publica c oes s ao identicadas pelo seu n umero do tombo, al em de outras caracter sticas como o t tulo, a editora e o n umero da edi c ao correspondente. A biblioteca s o empresta suas obras para usu arios cadastrados. Um usu ario e identicado atrav es de seu n umero de registro. Outras informa co es relevantes s ao seu nome, instituto/faculdade a que pertence e seu tipo (aluno/funcion ario/professor).
31
2.2
Casos de Usos
Um caso de uso e uma descri c ao de um processo de neg ocio relativamente longo com um come co, meio e m. Ele representa as principais funcionalidades que o sistema deve oferecer de maneira observ avel por seus interessados externos, isto e, os seus atores. Os casos de uso, na verdade, representam fun c oes no n vel do sistema e podem ser utilizados para visualizar, especicar, construir e documentar o comportamento esperado do sistema durante o levantamento e an alise de seus requisitos. A deni c ao formal de caso de uso, segundo Larman [29], e: um conjunto de seq u encias
32
de a c oes que um sistema desempenha para produzir um resultado observ avel, de valor para um ator espec co. Por se preocupar unicamente com o problema e utilizar conceitos do dom nio, a utiliza c ao de casos de uso tamb em facilita a comunica c ao entre os usu arios nais, os especialistas no dom nio e os desenvolvedores do sistema. Um exemplo de caso de uso do sistema de bibliotecas seria o Emprestar Exemplar. A Figura 2.2 apresenta a representa c ao gr aca desse caso de uso, de acordo com a linguagem UML. O caso de uso Emprestar Exemplar pode ser descrito da seguinte forma: Caso de Uso: Emprestar Exemplar Atores: Usu ario, Atendente, Sistema de Cadastro. Descri c ao: Este caso de uso representa o processo de empr estimo de um ou v arios exemplares da biblioteca. O empr estimo se inicia com a solicita c ao feita pelo usuario ao atendente. Em seguida, atrav es de um terminal, o atendente solicita ao sistema o empr estimo dos respectivos exemplares.
Emprestar Exemplar
Figura 2.2: Caso de Uso Emprestar Exemplar em UML
2.3
Atores e Pap eis
Um ator e uma entidade externa ao sistema computacional que participa de um ou mais casos de uso. Essa participa c ao normalmente e baseada na gera c ao de eventos de entrada ou no recebimento de alguma resposta do sistema. De uma maneira geral, atores representam entidades interessadas, que podem interagir diretamente com o sistema. A representa c ao dos atores se d a a partir do papel que eles representam, como por exemplo, usuario, atendente, aluno, etc. Em geral, atores podem ser: (i) pap eis que pessoas representam nos casos de uso, (ii) dispositivos de hardware mec anicos ou el etricos, ou at e mesmo (iii) outros sistemas computacionais. A intera c ao entre um ator e o sistema acontece atrav es de troca de mensagens e em UML, e representada por um relacionamento de associa c ao (uma linha cont nua, como visto na Se c ao 1.3.7). Em rela c ao aos atores, A Figura 2.3 apresenta as duas maneiras de represent a-los: (i) na forma de um boneco; ou (ii) como uma classe com o estere otipo << actor >>. No exemplo do sistema de bibliotecas, podemos identicar inicialmente dois atores: o atendente
33
<< actor >> Atendente
Atendente
Figura 2.3: Representa c ao de Atores em UML e o usu ario. Na Figura 2.4 podem ser vistas as associa c oes que indicam a participa c ao desses atores no caso de uso Emprestar Exemplar.
caso de uso
Emprestar Exemplar
associao
ator
Atendente
Usurio
Figura 2.4: Caso de Uso Emprestar Exemplar com seus atores Como visto anteriormente, os atores s ao usados para representar qualquer entidade externa com a qual o sistema interage. Dessa forma, a interfer encia do tempo em um sistema, por exemplo, pode ser representada atrav es de um ator chamado tempo, associado aos seus respectivos casos de uso. De modo particular no sistema de bilbiotecas, o cancento de uma reserva ap os um per odo caracteriza casos de uso associados ao ator tempo. Outra solu c ao e n ao representar o tempo explicitamente, o considerando como um componente interno do sistema. Nesse caso, o caso de uso inicia a si pr oprio numa determinada hora e por isso e associado apenas aos demais atores interessados no seu funcionamento. Por exemplo, os sistemas e interessados que recebem a sa da gerada por ele.
2.4
Fluxo de Eventos
O uxo de eventos de um caso de uso e uma seq u encia de comandos declarativos que descreve as etapas de sua execu c ao, podendo conter desvios de caminhos e itera c oes. Esse uxo deve especicar o comportamento de um caso de uso de uma maneira sucientemente clara para que algu em de fora possa compreend e-lo facilmente. Em outras palavras, ele deve permanecer focado no dom nio do problema e n ao em sua solu c ao. Al em disso, esse uxo dever a incluir como e quando o caso de uso inicia e termina, quais s ao os atores interessados no sistema e quando e como o caso de uso interage com eles. O uxo de eventos de um caso de uso e composto por: um (i) uxo b asico e (ii) zero ou mais uxos alternativos. Enquanto o uxo b asico descreve a seq u encia de passos mais esperada para a execu c ao da funcionalidade do caso de uso, os uxos alternativos descrevem desvios do uxo b asico. Esses uxos podem ser especicados de diversas maneiras, incluindo descri c ao textual
34
informal, texto semi-formal (atrav es de assertivas l ogicas), pseudoc odigo, ou ainda uma combina c ao dessas maneiras. A seguir, e mostrado o uxo de eventos do caso de uso Emprestar Exemplar. O uxo b asico e descrito atrav es de pseudoc odigo, enquanto os uxos alternativos s ao descritos informalmente, por meio de descri c ao textual. Para facilitar a leitura do caso de uso, ser a adotada a seguinte conven c ao: cada frase que descreve uma a c ao deve iniciar com o nome sistema, ou o nome do ator que a executa. Em seguida, deve-se indicar o verbo da a c ao e nalmente o complemento da frase. Quando apropriado, o complemento da frase deve referenciar o paciente da a c ao. Sendo assim, o formato sugerido para cada frase e o seguinte: < sistema/ator agente > + < verbo > + < complemento f rase > + < sistema/ator paciente >. Fluxo B asico de Eventos: 1. O usu ario solicita empr estimo de um ou mais exemplares de publica c oes (livro, peri odico, tese ou manual), fornecendo o seu c odigo e os exemplares desejados; 2. O atendente solicita o empr estimo ao sistema, fornecendo o c odigo do usu ario; 3. Para cada exemplar a emprestar: 3.1 O atendente fornece o n umero de registro do exemplar. 3.2 O sistema valida o usu ario e verica o seu status (Normal ou Suspenso) atrav es de seu n umero de registro. 3.3 O sistema verica se o exemplar pode ser emprestado pelo usu ario em quest ao; 3.4 Se o status do usu ario for Normal e o exemplar estiver dispon vel: 3.4.1. O sistema verica se a publica c ao do exemplar est a reservada. Se estiver reservada: A. O sistema cancela a reserva, passando o n umero de tombo da publica c ao 3.4.2. O sistema calcula o per odo do empr estimo, que depende do tipo de usu ario - 7 dias para alunos e 15 para professores 3.4.3. O sistema registra o empr estimo do exemplar; 3.4.4. O sistema atualiza seu banco de dados com a informa ca o de que o exemplar n ao ir a se encontrar na biblioteca at e completar o per odo. Fluxos Alternativos Fluxo Alternativo 1: No Passo 3.4, se o usu ario estiver suspenso, este e informado de sua proibi c ao de retirar exemplares e o empr estimo n ao e realizado. Fluxo Alternativo 2: No Passo 3.4, se todas as c opias da publica c ao estiverem emprestadas ou reservadas, o sistema informa ao atendente que n ao ser a poss vel realizar o empr estimo daquele exemplar. Se tiver outros exemplares para emprestar, v a para o Passo 3.1 do uxo b asico.
35
Como p ode ser visto neste exemplo, os uxos alternativos s ao executados quando condi c oes especiais pr e-denidas s ao detectadas durante a execu c ao do uxo b asico. Neste caso, a execu c ao do uxo b asico e interrompida e o uxo alternativo correspondente ` a condi c ao e executado. No exemplo acima, se o usu ario n ao estiver suspenso e o exemplar n ao estiver dispon vel, (Passo 3.4 do uxo b asico), o segundo uxo alternativo e executado. Se for bem sucedido, ao nal deste, a execu c ao e retomada a partir do Passo 3.1 do uxo b asico (pr oximo exemplar). Tamb em e poss vel que um uxo alternativo leve ao encerramento precoce do uxo de eventos, como e o caso do primeiro uxo alternativo do exemplo acima.
2.5
Cen arios
Um cen ario e uma seq u encia de comandos/a c oes simples, que representa uma execu c ao espec ca do uxo de eventos, com todas as decis oes e itera c oes j a conhecidas de antem ao. Um cen ario representa uma intera c ao ou execu c ao de uma inst ancia de um caso de uso. O uxo de eventos de um caso de uso produz um cen ario prim ario, que representa a funcionalidade b asica do caso de uso, e zero ou mais cen arios secund arios, que descrevem desvios do cen ario prim ario. O cen ario prim ario de um caso de uso e escrito supondo que tudo d a certo e ilustra uma situa c ao t pica de sucesso. Normalmente o cen ario prim ario de um caso de uso corresponde ` a execu c ao dos passos de seu uxo b asico quando nenhum desvio e tomado. Cen arios secund arios representam situa c oes menos comuns, incluindo aquelas em que um erro ocorre. Cen arios secund arios que representam situa c oes de erro tamb em s ao conhecidos como cen arios excepcionais. Tipicamente, para cada cen ario derivado de um uxo de eventos, deve ser poss vel responder as quatro quest oes seguintes: (i) como o cen ario come ca? (ii) o que causa o t ermino do cen ario? (iii) quais respostas s ao produzidas pelo cen ario? (iv) existem desvios condicionais no uxo de eventos? Seguindo o nosso exemplo, o cen ario prim ario do caso de uso Emprestar Exemplar pode ser descrito da seguinte forma: 1. O usu ario Jos e chega ` a biblioteca para tomar emprestado um exemplar do livro S ao Bernardo. Jos e apresenta o exemplar e informa o seu c odigo pessoal, que e A55; 2. O atendente solicita o empr estimo, fornecendo o c odigo A55 para Jos e; 3. O atendente olha o exemplar entregue e fornece o n umero do registro ao sistema; 4. O sistema verica que Jos e est a com status Normal; 5. O sistema verica que o exemplar est a dispon vel para loca c ao; 6. O sistema calcula que o exemplar pode car emprestado a Jos e por 7 dias; 7. O sistema registra o empr estimo; 8. O sistema atualiza o registro, nalizando o empr estimo;
36 9. O atendente entrega o exemplar a Jos e; 10. Jos e vai embora.
Cen arios secund arios s ao descritos de maneira similar, mas levando em considera c ao desvios do cen ario prim ario. Por exemplo, no Passo 3 do cen ario prim ario, o c odigo do produto pode ser inv alido e, nesse caso, o sistema deve indicar um erro. De forma an aloga, no Passo 5 o exemplar pode n ao estar dispon vel e ent ao a transa c ao de empr estimo do exemplar em quest ao deve ser cancelada. O primeiro cen ario alternativo poderia ser descrito da seguinte forma: 1. O usu ario Jos e chega ` a biblioteca para tomar emprestado um exemplar do livro S ao Bernardo. Jos e apresenta o exemplar e informa o seu c odigo pessoal, que e A55; 2. O atendente solicita o empr estimo, fornecendo o c odigo A55 para Jos e; 3. O atendente olha o exemplar entregue e fornece o n umero do registro ao sistema; 4. O sistema verica que Jos e est a com status Suspenso; 5. O sistema avisa ao atendente que Jos e n ao pode realizar o empr estimo e cancela a opera c ao; 6. O atendente informa a Jos e; 7. Jos e vai embora.
2.6
Formato e Conven c oes para Casos de Uso
Formato de Caso de Uso Al em do uxo de eventos, a descri c ao de um caso de uso pode incluir informa c oes que aumentem a rastreabilidade dos requisitos e facilitem a comunica c ao entre clientes e a equipe de desenvolvimento do sistema [15]. N ao existem padr oes na ind ustria ou na literatura sobre quais informa c oes devem ser inclu das na descri c ao de um caso de uso; autores normalmente preferem indicar uma lista de tens que podem ser relevantes e sugerem que sejam escolhidos de acordo com a utilidade de cada um para um determinado projeto de desenvolvimento [18]. O livro de Cockburn [15] apresenta diversos formatos com diferentes informa c oes e estilos de descri c ao. Neste livro adotaremos o seguinte formato para a descri c ao de casos de uso, baseado no RUP [26]: 1. Nome do Caso de Uso (a) Breve Descri c ao ...texto... (b) Atores ...texto...
Cap tulo 2: Casos de Uso (c) Pr e-condi co es: ...texto... (d) P os-condi co es: ...texto... (e) Requisitos Especiais (requisitos n ao-funcionais): ...texto... (f) Refer encia Cruzada (requisitos mapeados): ...lista de requisitos... 2. Fluxo de Eventos (a) Fluxo B asico ...passos do cen ario... (b) Fluxo Alternativo 1 ...passos do cen ario... (c) Fluxo Alternativo 2 ...passos do cen ario... ... (d) Fluxo Alternativo N ...passos do cen ario...
37
No modelo acima, um caso de uso e identicado por seu nome. Este e seguido por (i) uma descri c ao sucinta, similar ` as que foram apresentadas na Se c ao 2.2; (ii) a lista dos atores que participam desse caso de uso; (iii) um conjunto de pr e-condi c oes, predicados que devem ser verdadeiros para que o cen ario seja executado; (iv) um conjunto de p os-condi c oes, predicados que devem ser verdadeiros ao nal da execu c ao do cen ario; (v) uma lista de requisitos especiais, requisitos n aofuncionais que o sistema deve apresentar durante a execu ca o do caso de uso, como desempenho e conabilidade (Se c ao 2.1); e (vi) uma refer encia ao requisito (ou conjunto de requisitos) satisfeito(s) pelo caso de uso. A especica c ao dos uxos de eventos segue o formato apresentado na Se c ao 2.4.
2.7
Diagramas de Casos de Uso
Um diagrama de casos de uso e uma representa c ao gr aca que mostra um conjunto de casos de uso, atores e seus relacionamentos para um determinado sistema. Ele e um diagrama que contextualiza o sistema no ambiente no qual ele se insere e possui quatro elementos b asicos: (i) atores; (ii) casos de uso; (iii) intera c oes; e (iv) fronteira do sistema. A Figura 2.5 apresenta o diagrama de casos de uso para o sistema da biblioteca. Esse diagrama inclui o caso de uso Emprestar Exemplar apresentado na Figura 2.4, al em de tr es casos de uso novos: Devolver Exemplar, Reservar Publica c ao e Cancelar Reserva. Al em do seu papel central para a modelagem dos requisitos funcionais de um sistema, os diagramas de casos de uso tamb em s ao muito utilizados para facilitar a compreens ao de sistemas legados, por meio de engenharia reversa [9].
38
Como pode ser visto na Figura 2.5, a fronteira do sistema e representada gracamente atrav es de uma linha ao redor dos casos de uso. Essa delimita c ao expl cita do contexto representa a forma como o sistema interage com as entidades externas associadas a ele, que s ao representadas pelos atores.
Limite do sistema Sistema de Biblioteca
caso de uso
Emprestar Exempalar
associao
Devolver Exemplar
ator
Reservar Publicao Atendente Usurio
Cancelar Reserva
Figura 2.5: Diagrama de Casos de Uso para o Sistema de Biblioteca
2.8
Relacionamentos entre Casos de Uso
Al em das associa c oes entre os casos de uso e seus atores, em um diagrama de casos de uso e poss vel denir outros relacionamentos, tanto entre os casos de uso, quanto entre os atores. A linguagem UML dene tr es tipos de relacionamentos, que aumentam o valor sem antico do diagrama. S ao eles: (i) generaliza c ao (heran ca); (ii) inclus ao (<< include >>); e (iii) extens ao (<< extend >>). Esses relacionamentos s ao utilizados com a nalidade principal de fatorar tanto o comportamento comum entre os casos de uso, quanto as varia c oes desses comportamentos. A seguir, as Se c oes 2.8.1, 2.8.2 e 2.8.3 apresentam cada um desses relacionamentos em maiores detalhes.
2.8.1
Generaliza c ao
O relacionamento de generaliza c ao entre casos de uso e similar ` a generaliza c ao entre classes, vista na Se c ao 1.3.5, isto e, o caso de uso derivado herda tanto o signicado do caso de uso base, quanto o seu comportamento, que normalmente e estendido e especializado. Por exemplo, na Figura 2.6 (a), o caso de uso Emprestar Exemplar e respons avel por efetuar o empr estimo de um exemplar. Podemos
39
denir dois casos de uso derivados, Emprestar sem Renova c ao e Renovar Empr estimo, de tal forma que ambos se comportem igual ao caso de uso Emprestar Exemplar, exceto pelo fato de explicitarem o tipo espec co de empr estimo que e feito. Os dois casos de uso derivados podem ent ao ser usados em qualquer lugar onde o caso de uso Emprestar Exemplar e esperado.
Emprestar sem Renovao

Funcionrio
Emprestar Exemplar
Renovar Emprstimo
Bibliotecrio Atendente
(a)
(b)
Figura 2.6: Exemplo de Generaliza c ao no Diagrama de Casos de Uso Num diagrama de casos de uso, o relacionamento de generaliza c ao tamb em pode ser usado entre atores, signicando que um ator desempenha os mesmos pap eis de um outro ator, podendo ainda desempenhar pap eis extras. A Figura 2.6 (b) mostra um exemplo de generaliza c ao entre atores, onde os atores Bibliotec ario e Atendente s ao derivados de um ator base chamado Funcion ario. Isso signica que todos os pap eis desempenhados pelo ator Funcion ario podem ser desempenhados por qualquer ator derivado, seja ele um Bibliotec ario ou um Atendente.
2.8.2
Inclus ao
Um relacionamento de inclus ao (<< include >>) entre casos de uso signica que o caso de uso base sempre incorpora explicitamente o comportamento de outro caso de uso em um ponto espec co. Sendo assim, mesmo que o caso de uso inclu do n ao esteja associado a nenhum ator, ele e executado como parte do caso de uso que o inclui. Costuma-se usar um relacionamento de inclus ao para evitar a descri c ao de um mesmo conjunto de uxo de eventos, atrav es da fatora c ao do comportamento comum. Um relacionamento de inclus ao e representado em UML como uma depend encia (ver Se c ao 1.3.8) cuja seta aponta para o caso de uso inclu do, isto e, o caso de uso base depende do caso de uso inclu do, signicando que se o caso de uso inclu do for modicado, o caso de uso base tamb em deve ser revisto. Essa depend encia recebe o estere otipo << include >>, como mostrado na Figura 2.7. No exemplo da Figura 2.7, o caso de uso Emprestar Exemplar explicita o fato da valida c ao do usu ario fazer parte da sua l ogica de neg ocio. Dessa forma, sempre que o caso de uso Emprestar Exemplar e executado, o caso de uso Validar Usu ario e executado.
40
caso de uso base Emprestar Exemplar << include >> relacionamento de incluso

caso de uso includo Validar Usurio
Figura 2.7: Exemplo de Inclus ao entre Casos de Uso
2.8.3
Extens ao
Um relacionamento de extens ao (<< extend >>) entre casos de uso signica que o caso de uso base incorpora implicitamente o comportamento de outro caso de uso num ponto espec co. No relacionamento de extens ao, diferentemente do que ocorre no relacionamento de inclus ao, o caso de uso extensor s o tem seu comportamento incorporado pelo caso de uso base em algumas circunst ancias espec cas. As condi c oes necess arias para que o caso de uso base possa ser estendido devem ser especicadas explicitamente atrav es de pontos pr e-estabelecidos na especica c ao. Esses pontos s ao chamados de pontos de extens ao. Um relacionamento de extens ao e representado em UML como uma depend encia cuja seta aponta para o caso de uso base (n ao para o caso de uso extensor), isto e, o caso de uso extensor depende do caso de uso base. Essa depend encia possui o estere otipo << extend >>, como mostrado no exemplo da Figura 2.8. O relacionamento de extens ao e utilizado para modelar a parte do caso de uso que o usu ario considera como sendo um comportamento condicional do sistema. Desta forma, e poss vel, por exemplo, separar o comportamento opcional do comportamento obrigat orio, ou at e mesmo expressar um subuxo separado que e executado apenas em circunst ancias espec cas. A Figura 2.8 apresenta o caso de uso Emprestar Exemplar, que e estendido pelo caso de uso Cancelar Reserva.
caso de uso base Emprestar Exemplar Extension Points (publicao reservada) : ponto de extenso << extend >> (publicao reservada) relacionamento de extenso caso de uso extensor Cancelar Reserva
Figura 2.8: Exemplo de Extens ao entre Casos de Uso Agora que j a conhecemos como casos de uso podem se relacionar entre si, o uxo de eventos do caso de uso Emprestar Exemplar, que j a foi denido na Se c ao 2.4, poderia explicitar o local onde outros casos de uso s ao executados. Para isso, ser ao utilizados os relacionamentos de << include >> e << extend >> A vers ao renada desse uxo b asico e apresentada a seguir: Fluxo B asico de Eventos: 1. O usu ario solicita empr estimo de um ou mais exemplares de publica c oes (livro, peri odico, tese ou manual), fornecendo o seu c odigo e os exemplares desejados;
Cap tulo 2: Casos de Uso 2. O atendente solicita o empr estimo ao sistema, fornecendo o c odigo do usu ario; 3. Para cada exemplar a emprestar: 3.1 O atendente fornece o n umero de registro do exemplar. 3.2 O sistema valida o usu ario e verica o seu status (Normal ou Suspenso) atrav es de seu n umero de registro. (<< include >> Validar Usu ario); 3.3 O sistema verica se o exemplar pode ser emprestado pelo usu ario em quest ao; 3.4 Se o status do usu ario for Normal e o exemplar estiver dispon vel: 3.4.1. O sistema verica se a publica c ao do exemplar est a reservada. Se estiver reservada (publica c ao reservada): A. O sistema cancela a reserva, passando o n umero de tombo da publica c ao (<< extend >> Cancelar Reserva) 3.4.2. O sistema calcula o per odo do empr estimo, que depende do tipo de usu ario - 7 dias para alunos e 15 para professores (<< include >> Calcular Tempo de Empr estimo) 3.4.3. O sistema registra o empr estimo do exemplar; 3.4.4. O sistema atualiza seu banco de dados com a informa ca o de que o exemplar n ao ir a se encontrar na biblioteca at e completar o per odo.
41
Neste exemplo, (publica ca ~o reservada) e um ponto de extens ao. Um caso de uso pode ter v arios pontos de extens ao, que podem inclusive aparecer mais do que uma vez. Em condi c oes normais, o caso de uso Emprestar Exemplar e executado independentemente da satisfa c ao dessas condi c oes. Ppor em, se o usu ario solicitar o empr estimo de um exemplar que est a reservado por ele, ent ao o ponto de extens ao (publica ca ~o reservada) e ativado e o comportamento do caso de uso Cancelar Reserva e ent ao executado. Em seguida, o uxo de controle continua do lugar de onde foi interrompido (Passo 3.4.2).
2.9
M etodo para a Modelagem de Casos de Uso
Quando a modelagem de casos de uso e utilizada para melhorar o entendimento dos requisitos funcionais do sistema computacional, e importante que haja a participa c ao ativa dos clientes/usu arios do sistema. O usu ario entende como o sistema ser a usado e esse conhecimento e capturado na forma de casos de uso. Esses casos de uso s ao carregados atrav es das fases de an alise, projeto, implementa c ao, testes e manuten c ao do sistema, servindo como guia e base para o seu entendimento. A Figura 2.9 mostra como os casos de uso s ao realizados atrav es das fases de an alise e projeto. O modelo conceitual da an alise rena os casos de uso e as classes do modelo de projeto, por sua vez, renam o modelo conceitual da an alise. Em geral, durante essas transforma c oes o n umero de classes aumenta. O estere otipo << trace >> entre a fase de an alise e a fase de especica c ao de requisitos, mostrado na Figura 2.9, indica qual conjunto de elementos da an alise corresponde ` a especica c ao do caso de uso Emprestar Exemplar. Similarmente para o estere otipo << trace >> entre as fases
42
de an alise e projeto. Al em de possibilitar o rastreamento entre os artefatos das fases do desenvolvimento do software, o relacionamento de depend encia traz informa c oes importantes que auxiliam o gerenciamento da evolu c ao do sistema. Como visto na Se c ao 1.3.8, o fato do modelo de an alise depender do modelo de casos de uso, implica que se o caso de uso Emprestar Exemplar for alterado, o modelo de an alise correspondente deve ser revisto. A mesma sem antica tamb em e v alida entre os modelos de projeto e de an alise.
Fase de Especificao de Requisitos Modelo de Casos de Uso
Fase de Anlise Modelo de Anlise Classes Envolvidas em Emprestar Exemplar . << trace >>
Fase de Projeto Modelo de Projeto Classes Refinadas para Exemplar Exemplar
Emprestar Exemplar
<< trace >> .
Figura 2.9: Realiza c oes dos Casos de Uso em Modelos Diferentes Nesta se c ao s ao apresentados tr es m etodos para a constru c ao do modelo de casos de uso, partindo de uma especica c ao inicial informal dos requisitos do sistema, chegando at e a descri c ao gr aca de seus uxos de eventos. Apesar de suas caracter sticas particulares, os m etodos expostos aqui s ao complementares e podem ser utilizados em conjunto, a m de maximizar a ec acia da elicita c ao e representa c ao dos requisitos. As abordagens mostradas s ao: 1. Identica c ao de Casos de Uso Baseada em Atores. Essa t ecnica se baseia na identica c ao das funcionalidades requeridas por cada um dos interessados no sistema. O ponto forte dessa abordagem e o seu car ater intuitivo, que motiva a sua populariza c ao na literatura. 2. Identica c ao de Casos de Uso Baseada em Atributos. Essa abordagem enfatiza a necessidade de analisar as informa c oes relevantes para cada entidade conceitual do sistema, isto e, os atributos identicados nas descri c oes textuais. A partir da , s ao identicadas as funcionalidades relativas ao gerenciamento e atualiza c ao dessas informa c oes, tais como cadastro e manuten c ao de dados. 3. Identica c ao de Casos de Uso Baseada em An alise de Dom nio. O objetivo principal dessa abordagem e a identica c ao dos requisitos inerentes ao dom nio do sistema. Por serem normalmente comuns a outros sistemas do mesmo dom nio, esses requisitos representam as funcionalidades mais prop cias ` a reutiliza c ao. Cada um desses m etodos e composto por uma seq u encia de passos que estruturam a modelagem dos requisitos de um sistema atrav es de casos de uso. Al em da utiliza c ao desses m etodos, e bom ter sempre em mente as seguintes dicas que orientam a especica c ao de casos de uso: 1. Um caso de uso n ao diz nada sobre o funcionamento interno do sistema, isto e, o sistema e visto como uma caixa preta; 2. Casos de uso s ao parte do dom nio do problema e n ao da solu c ao;
Cap tulo 2: Casos de Uso 3. Um caso de uso diz como atores interagem com o sistema e como o sistema responde; 4. Um caso de uso e sempre iniciado ou por um ator, ou por outro caso de uso do qual fa ca parte; 5. Um caso de uso oferece um resultado observ avel, sob o ponto de vista do ator; 6. Um caso de uso e completo, isto e, ele possui um come co, um meio e um m; 7. O m de um caso de uso e indicado quando o seu resultado observ avel e obtido pelo ator; 8. Podem ocorrer v arias intera c oes entre os atores e os casos de uso, durante a execu c ao dos uxos de eventos.
43
O sistema de controle de bibliotecas, descrito no in cio do cap tulo, ter a seus casos de uso identicados e especicados em maiores detalhes. Para isso, ser ao utilizadas as tr es abordagens de modelagem de casos de uso apresentados anteriormente.
2.9.1
Identica c ao de Casos de Uso Baseada em Atores
Nesse m etodo, o primeiro passo para a identica c ao dos casos de uso e identicar os atores que ir ao interagir com o sistema. Como visto na Se c ao 2.3, esses atores podem ser pessoas ou outros sistemas externos com os quais o sistema especicado interage. Para ajudar na tarefa de descoberta desses atores, existem algumas perguntas a serem respondidas [42]. A seguir, s ao apresentadas as sete principais quest oes, respondidas de acordo com o sistema da biblioteca. 1. Quem opera o sistema? Resp.: O sistema pode ser operado pelo atendente ou pelo bibliotec ario. 2. Quem e respons avel pela sua administra c ao? Resp.: A administra c ao do sistema ca por conta do bibliotec ario. 3. Quem e respons avel pela manuten c ao dos seus dados? Resp.: A manuten c ao dos dados e feita pelo atendente (dados de usu arios) e pelo bibliotec ario (dados de usu arios e do acervo). 4. Quem necessita das suas informa c oes? Resp.: As informa c oes s ao u teis para o usu ario (alunos, professores e funcion arios), para o atendente e para o bibliotec ario. 5. Quem oferece informa c oes para o sistema? Resp.: As informa c oes podem ser oferecidas pelo usu ario (informa c oes pessoais), pelo atendente (informa c oes pessoais) e pelo bibliotec ario (informa c oes sobre o acervo). 6. Os outros sistemas utilizam algum dado/processamento do sistema especicado?
44
Cap tulo 2: Casos de Uso Resp.: O sistema cont abil necessita de informa c oes sobre o valor de todas as multas pagas pelos usu arios. 7. Acontece algo automaticamente/periodicamente no sistema? Resp.: Sim. Uma reserva pode ser cancelada automaticamente, caso o empr estimo n ao tenha sido efetuado no per odo estipulado.
Os atores identicados com as respostas dadas foram os seguintes: (i) atendente; (ii) usu ario; (iii) aluno; (iv) professor; (v) funcion ario; (vi) bibliotec ario; (vii) sistema cont abil; e (viii) tempo. Numa biblioteca pequena, e poss vel que v arios desses pap eis sejam desempenhados pela mesma pessoa. Em cada papel, esta pessoa age de forma diferente e tamb em espera respostas diferentes do sistema. Dado que os atores j a foram descobertos, e poss vel iniciar a especica c ao dos casos de uso, a partir do que cada um dos atores espera do sistema. Para isso, para cada um dos atores identicados, devemos considerar seis pontos importantes, que ser ao apresentados a seguir. As respostas elaboradas se referem ao ator usu ario do exemplo da biblioteca. 1. Quais tarefas o ator deseja que o sistema realize? Resp.: O usu ario deseja emprestar um exemplar, devolver um exemplar, reservar um exemplar, e cancelar reserva. 2. Quais informa c oes o ator deve fornecer para o sistema? Resp.: O usu ario pode fornecer as seguintes informa c oes: nome, endere co, t tulo da publica c ao, n umero de tombo da publica c ao, n umero de registro do exemplar. 3. Existem eventos que o ator deve comunicar ao sistema? Resp.: O usu ario pode comunicar uma poss vel mudan ca de endere co. 4. O ator precisa ser informado de alguma coisa importante pelo sistema? Resp.: O usu ario deve ser informado quando uma publica c ao reservada por ele possuir algum exemplar dispon vel para ser emprestado. 5. O ator e respons avel por iniciar ou terminar a execu c ao do sistema? Resp.: Sim, nas funcionalidades: consultar uma publica c ao, reservar um exemplar, e cancelar reserva. 6. O sistema armazena informa c oes? O ator necessita manipul a-las, isto e, ler, atualizar ou apagar? Resp.: Sim. O usu ario pode desejar saber os u ltimos exemplares alugados por ele, ou ainda atualizar seus dados pessoais. Com base nessas respostas, podemos identicar os seguintes casos de usos: (i) Manter Dados Usu ario. O usu ario deve ser cadastrado na biblioteca, fornecendo informa c oes sobre seu nome, endere co, e tipo de v nculo com a universidade; (ii) Emprestar Exemplar. O usu ario pode emprestar exemplares da biblioteca; (iii) Devolver Exemplar. O usu ario pode devolver exemplares emprestados a ele; (iv) Reservar Publica c ao. O usu ario pode reservar um n umero de exemplares de uma
45
determinada publica c ao; (v) Cancelar Reserva. O usu ario pode cancelar uma reserva feita por ele; (vi) Contactar Usu ario. O usu ario pode ser contactado quando uma publica c ao reservada por ele estiver dispon vel; e (vii) Consultar Hist orico Usu ario. O usu ario pode consultar os u ltimos exemplares emprestados a ele. Considerando o atendente, o bibliotec ario e o professor, podemos identicar outros casos de uso: (i) Manter Dados Publica c ao. O bibliotec ario pode gerenciar os dados das publica c oes do sistema; (ii) Manter Dados Exemplar. O bibliotec ario pode gerenciar os dados dos exemplares de cada pubica c ao; (iii) Consultar Hist orico Biblioteca. Antes de comprar novos exemplares, uma informa c ao u til ao bibliotec ario e saber quais publica c oes s ao mais populares; (iv) Bloquear Exemplar. Um professor pode bloquear o empr estimo de exemplares espec cos; e (v) Desbloquear Exemplar. Os exemplares bloqueados para empr estimo podem voltar a ser emprestados (desbloqueados);
2.9.2
Identica c ao de Casos de Uso Baseada em Atributos
Uma outra forma de identicar os casos de uso e considerar os poss veis atributos das entidades do sistema alvo. Por exemplo, uma publica c ao pode ter associados a ela: um t tulo, o g enero da publica c ao (t ecnica, n ao-t ecnica), a data de lan camento, etc. Pensando nesses atributos, e poss vel identicar casos de uso relacionados com funcionalidades de consulta e manuten c ao. Por exemplo: (i) Consultar Publica c ao., que representa a consulta da disponibilidade dos exemplares de uma determinada publica c ao. De forma an aloga, analisando a entidade usu ario seria poss vel identicar o caso de uso Consultar Usu ario, uma vez que o atendente pode encontrar o registro de um determinado usu ario, informando um dos seus dados pessoais.
2.9.3
Identica c ao de Casos de Uso Baseada em An alise de Dom nio
Analisando o dom nio do problema, e poss vel identicar entidades e funcionalidades mais prop cias a serem reutilizadas posteriormente. A seguir, para cada uma das quatro etapas da an alise de dom nio, relatamos o produto nal obtido para o sistema da biblioteca. 1. Estudo da viabilidade do dom nio. Esta etapa consistiu na identica c ao e sele c ao dos dom nio relacionados para o sistema em quest ao. Foi identicada uma grande semelhan ca entre sistemas de bibliotecas e sistemas de loca c ao. Al em disso, tamb em julgou-se que o dom nio do sistema analisado possui caracter sticas de sistemas de livraria. Baseado nesses dom nios, constituiu-se o dom nio dos sistemas de empr estimo de publica c oes, que agrega as caracter sticas dos dom nios de: (i) sistemas de loca c ao; e de (ii) sistemas de livraria. 2. Planejamento do dom nio. Em rela c ao ` a an alise de risco relativa ao nosso exemplo, n ao
46
Cap tulo 2: Casos de Uso foram identicados riscos s erios de projeto. Essa decis ao se baseou no fato de se tratar de um dom nio amplamente conhecido e sem a necessidade de se utilizar tecnologias imaturas. 3. Contextualiza c ao do dom nio. Nesta etapa foi avaliada a contextualiza c ao do dom nio do ponto de vista do sistema em particular. Com o intuito de acompanhar a tend encia especicada no dom nio do sistema, e desej avel existir um m odulo de consulta e reserva pela Internet. 4. Aquisi c ao do conhecimento do dom nio. Esta fase e respons avel pela elicita c ao nal e representa c ao das informa c oes e requisitos relacionados ao dom nio. Os artefatos produzidos nesta etapa s ao descri c oes textuais semelhantes aos uxos de eventos dos casos de uso, apresentados na Se c ao 2.4. Por esse motivo, essa atividade deve ser desempenhada normalmente em conjunto, tanto pelo especialista no dom nio, quanto pelo engenheiro de requisitos e os artefatos produzidos aqui servir ao de base para a especica c ao dos casos de uso do sistema. No contexto do nosso exemplo, foram identicadas algumas caracter sticas inerentes aos sistemas de bibliotecas. O conhecimento dessas caracter sticas foi decorrente da an alise dos dom nios identicados anteriormente. As principais caracter sticas encontradas s ao enumeradas a seguir: (a) Uma biblioteca normalmente disponibiliza v arios tens distintos para serem emprestados, n ao apenas material impresso; (b) No caso da devolu c ao ser atrasada, normalmente e cobrada uma multa proporcional ao tempo de atraso (Cobrar Multa) e o usu ario pode ser suspenso tempor aria ou permanentemente ou (Suspender Usu ario e Cancelar Suspens ao); (c) Durante o cadastro de usu arios, pode ser conveniente consultar institui c oes de prote c ao ao cr edito (ator Sistema de Cr edito);
Ap os identicar os casos de uso do sistema utilizando os m etodos apresentados anteriormente, o pr oximo passo e detalhar as suas especica c oes. Sendo assim, as atividades e conceitos mostrados a partir da Se c ao 2.9.4 se baseiam apenas nas particularidades do neg ocio e nos casos de uso identicados, independentemente da abordagem (ou combina c ao de abordagens) utilizada para tal.
2.9.4
Constru c ao de um Gloss ario e Termos
Um gloss ario cont em a deni c ao de todos os conceitos utilizados na especica c ao e modelagem do sistema, que possam comprometer o seu entendimento [29]. Sendo assim, a deni c ao de um gloss ario busca tanto denir termos desconhecidos, quanto esclarecer conceitos aparentemente similares. O principal benef cio desse esclarecimento da terminologia adotada e a melhoria da comunica c ao, reduzindo os riscos de desentendimento entre os interessados do sistema. Um entendimento consistente dos termos utilizados no dom nio do desenvolvimento e extremamente importante durante as fases de desenvolvimento [29]. Apesar de ser criado originalmente na
47
fase de elicita c ao de requisitos e planejamento do projeto, esse gloss ario deve ser renado continuamente em cada ciclo iterativo. Dessa forma, no decorrer do desenvolvimento, novos termos podem ser adicionados e as deni c oes anteriores podem ser atualizadas. Uma simplica c ao do modelo de deni c ao de gloss arios proposto por Larman [29] e mostrado na Tabela 2.1. O campo termo representa o conceito cujo signicado e denido no campo coment ario. Al em dessas informa c oes, esse modelo possibilita a especica c ao de informa co ~es adicionais referentes ao campo. Essas informa c oes adicionais podem ser utilizadas, por exemplo, para contextualizar o termo descrito em rela c ao ` a fase do desenvolvimento que ele foi identicado. Tabela 2.1: Modelo Sugerido para a deni c ao do Gloss ario Termo Entidade a ser denida rio Comenta Explica c ao descritiva Inf. Adicionais Informa c oes adicionais
No contexto do exemplo da biblioteca, e interessante que seja estabelecida uma distin c ao entre alguns termos, a m de evitar ambig uidade nas descri c oes dos casos de uso. Esse gloss ario e mostrado na Tabela 2.2, que dene os termos (Publica c ao e Exemplar). Tabela 2.2: Gloss ario dos Termos da Biblioteca Termo Publica c ao rio Comenta nome coletivo para todos os exemplares de uma determinada publica c ao. Essa abstra c ao de tipo e utilizada para realizar as opera c oes de consulta e reserva. Exemplar c opia individual de uma publica c ao que pode ser emprestada pelo usu ario. Essa e a abstra c ao de tipo que representa o objeto f sico. (i) fase de requisitos; (ii) exig encia do cliente. Inf. Adicionais (i) fase de requisitos; (ii) exig encia do cliente.
2.9.5
Levantamento Inicial dos Casos de Uso
Uma vez que os casos de uso fundamentais foram identicados, podemos ren a-los descrevendo-os com maiores detalhes. Por exemplo, o caso de uso Devolver Exemplar envolve as seguintes quest oes que devem ser considerados: (i) a devolu c ao est a atrasada? (ii) o exemplar est a danicado? Todas essas quest oes sugerem uma revis ao dos casos de uso identicados at e agora, gerando a seguinte lista parcial de casos de uso:
48
Cap tulo 2: Casos de Uso [Caso #1] Reservar Publica c ao. O usu ario pode reservar um n umero de exemplares de uma determinada publica c ao. [Caso #2] Cancelar Reserva. O usu ario pode cancelar uma reserva feita por ele. [Caso #3] Contactar Usu ario. O usu ario pode ser contactado quando uma publica c ao reservada por ele estiver dispon vel. [Caso #4] Emprestar Exemplar. O usu ario pode emprestar exemplares da biblioteca. [Caso #5] Devolver Exemplar. O usu ario pode devolver exemplares emprestados a ele. [Caso #6] Cobrar Multa. Multa cobrada nos casos onde h a devolu c oes em atraso. [Caso #7] Bloquear Exemplar. Um professor pode bloquear o empr estimo de exemplares espec cos. [Caso #8] Desbloquear Exemplar. Os exemplares bloqueados para empr estimo podem voltar a ser emprestados (desbloqueados). [Caso #9] Suspender Usu ario. Usu arios podem ser suspensos para loca c ao. [Caso #10] Cancelar Suspens ao. Usu arios suspensos provisoriamente podem voltar a realizar empr estimos. [Caso #11] Manter Dados Usu ario. O usu ario deve ser cadastrado na biblioteca, fornecendo informa c oes sobre seu nome, endere co, e tipo de v nculo com a universidade. [Caso #12] Manter Dados Publica c ao. O bibliotec ario pode gerenciar os dados das publica c oes do sistema. [Caso #13] Manter Dados Exemplar. O bibliotec ario pode gerenciar os dados dos exemplares de cada pubica c ao. [Caso #14] Consultar Usu ario. O atendente pode encontrar o registro de um determinado usu ario informando um dos seus dados pessoais. [Caso #15] Consultar Publica c ao. O usu ario pode consultar a disponibilidade dos exemplares de uma determinada publica c ao. [Caso #16] Consultar Hist orico Usu ario. O usu ario pode consultar os u ltimos exemplares emprestados a ele. [Caso #17] Consultar Hist orico Biblioteca. Antes de comprar novos exemplares, uma informa c ao util ao bibliotec ario e saber quais publica c oes s ao mais populares.
Renamento de Casos de Usos Relacionados Uma vez que uma lista de casos de uso tenha sido obtida, voc e pode unir e renar aqueles que s ao similares e denir v arias vers oes, cen arios e variantes para cada um deles. Por exemplo, os casos de uso #14 e #15 s ao parte dos casos de uso #11 e #12, respectivamente. As diversas atividades de manuten c ao: consulta, cadastro, altera c ao e exclus ao podem ser descritas como uxos do mesmo caso de uso. Outra possibilidade e den -los como extens oes do caso de uso mais geral, utilizando
49
o relacionamento de << extend >>, como mostrado na Figura 2.10 para o caso de uso Manter Dados Publica c ao. Apesar das v arias possibilidades de especica c ao de um diagrama de casos de uso, existe uma rela c ao de compromisso (do ingl es tradeo) entre a complexidade dos casos de uso e o n umero excessivo de casos de uso em um sistema.
<< extend >>
Consultar Publicao
<< extend >>
Manter Dados Publicao
<< extend >>
Excluir Publicao
<< extend >>
Cadastrar Publicao
Alterar Publicao
Figura 2.10: Modelagem Alternativa do Caso de Uso Manter Dados Publica c ao
2.9.6
Descri c ao de Casos de Usos
Cada caso de uso da lista preliminar deve receber um nome u nico e, em seguida, deve ser atribu do a ele um coment ario expandido que proporcione um entendimento mais detalhado. Por exemplo, o caso de uso #5 (Devolver Exemplar) pode expandir a sua descri c ao inicial, de modo a envolver os atores interessados na sua execu c ao (usu ario e atendente). Uma descri c ao mais completa do caso de uso Devolver Exemplar e apresentada a seguir: Caso de Uso: Devolver Exemplar. Atores: Usu ario e Atendente. Descri c ao: Este caso de uso representa o processo de devolu c ao de empr estimo de um ou v arios exemplares da biblioteca. A devolu c ao se inicia com a solicita c ao feita pelo usuario ao atendente. Em seguida, atrav es de um terminal, o atendente solicita ao sistema a devolu c ao dos respectivos exemplares. Se a devolu c ao estiver em atraso e o usu ario n ao for um professor, e cobrada uma multa e o usu ario pode ser suspenso.
2.9.7
Gerenciamento de Casos de Uso Complexos
Para promover o reuso e tornar mais claras as especica c oes dos casos de uso do sistema, eu til usar os relacionamentos entre casos de uso descritos na Se c ao 2.7. Por exemplo, o caso de uso Cancelar Reserva, identicado na Se c ao 2.9.5, descreve em detalhes como um usu ario cancela uma reserva feita para uma determinada publica c ao. Por outro lado, o caso de uso Emprestar Exemplar pode envolver o cancelamento de uma reserva como parte do processo de empr estimo. Neste caso, ao inv es de copiarmos o caso de uso Cancelar Reserva para o caso de uso Emprestar Exemplar, podemos dizer que Cancelar Reserva estende Emprestar Exemplar atrav es do relacionamento << extend >>. poss E vel usar tamb em o relacionamento de inclus ao, visto na Se c ao 2.8.3. Por exemplo, sempre
50
que o empr estimo e realizado ou quando um exemplar e devolvido ou bloqueado, o usu ario deve ser validado para vericar a sua possibilidade de executar o servi co solicitado (caso de uso Validar Usu ario). Com o intuito de explicitar a reutiliza c ao desde o modelo de casos de uso, pode-se dizer que o caso de uso Validar Usu ario e inclu do pelos casos de uso Emprestar Exemplar, Devolver Exemplar e Bloquear Exemplar.
Pacotes Para controlar a complexidade do modelo, ` a medida que o n umero de casos de usos cresce, se faz necess ario utilizar o conceito de m odulos. Conforme descrito na Se c ao 1.2.2, a modulariza c ao e implementada em UML atrav es do conceito de pacotes. Um pacote agrupa um conjunto de entidades UML relacionadas. V arios crit erios diferentes podem ser utilizados na hora de denir como os casos de uso ser ao empacotados. Por exemplo, voc e pode agrupar casos de uso que interagem com o mesmo ator, ou aqueles que estabelecem relacionamentos de inclus ao, extens ao ou generaliza c ao (casos de uso mais acoplados). Como exemplo de uma abordagem mista, a Figura 2.11 apresenta a vis ao modularizada dos casos de uso do sistema de bibliotecas. Enquanto os Pacotes 1 e 2 agrupam os casos de uso baseado nos atores, os Pacotes 3 e 4 agrupam pela semelhan ca das suas funcionalidades. A Figura 2.11 tamb em representam uma hierarquia de casos de uso, agrupando os casos de uso principais juntos e colocando os menos importantes em pacotes secund arios (subpacotes). Dessa forma, o pacote de n vel mais alto, chamado de top-level, representa o modelo completo do sistema.
topLevel
pacote_1 pacote_2
Usurio
Bibliotecrio
pacote_3
pacote_4
Reserva
Emprstimo
Figura 2.11: Pacotes de Casos de Uso
2.9.8
Descri c oes Formais de Casos de Usos
A deni c ao de assertivas e uma maneira muito utilizada para a formaliza c ao das especica c oes dos casos de uso. Esse princ pio se baseia na t ecnica de projeto por contrato(do ingl es design by contract), denido por Bertrand Meyer [34]. Sua losoa principal e a deni c ao de restri c oes que devem ser satisfeitas antes (pr e-condi c oes) ou ap os (p os-condi c oes) a execu c ao da funcionalidade especicada. As pr e- e p os-condi c oes s ao adicionadas ` a especica c ao dos casos de uso, conforme o
Cap tulo 2: Casos de Uso modelo mostrado na Se c ao 2.6.
51
Uma pr e-condi c ao de um caso de uso descreve restri c oes no sistema antes de um caso de uso iniciar. Por exemplo, antes do caso de uso Devolver Exemplar come car, o usu ario deve estar cadastrado na biblioteca e deve ter emprestado o exemplar que est a sendo devolvido. Al em disso, a biblioteca deve estar aberta. Um caso de uso s o tem o compromisso de executar corretamente nos cen arios onde as suas pr e-condi c oes s ao satisfeitas. Cada um desses cen arios podem ter uma vers ao mais detalhada das suas pr e-condi c oes. As p os-condi co es de um caso de uso descrevem o estado do sistema e possivelmente dos atores, depois que o caso de uso foi completado. Elas s ao verdadeiras para todos os cen arios do caso de uso, embora cada cen ario possa descrever suas pr oprias p os-condi c oes mais detalhadamente. Por exemplo, ao nal do caso de uso Devolver Exemplar, a situa c ao do usu ario deve estar regularizada. Al em disso, uma multa pode ou n ao ter sido cobrada, dependendo do tipo de usu ario e das condi c oes da devolu c ao.
2.9.9
Diagrama de Casos de Uso do Sistema da Biblioteca
Utilizando os conceitos apresentados na Se c ao 2.7, a Figura 2.12 mostra o diagrama de casos de uso do sistema de gerenciamento de bibliotecas. Lembrando que dependendo da decis ao do analista, poderiam ser produzidas outras vers oes corretas do diagrama.
2.9.10
Diagrama de Atividades para Fluxo de Eventos
Diagramas de atividades possuem elementos adicionais que tornam poss vel a representa c ao de desvios condicionais e execu c ao concorrente de atividades. Dessa forma, todos os uxos de eventos de um caso de uso (b asico e alternativos) podem ser representados gracamente atrav es de um u nico diagrama. Um diagrama de atividades e bastante similar a uma m aquina de estados na qual os estados correspondem a atividades e as transi c oes s ao, em sua maioria, vazias. A Figura 2.13 apresenta um diagrama de atividades contendo os principais elementos que podem ser encontrados em um diagrama de atividades. O uxo de eventos descrito pelo diagrama come ca no estado inicial, indicado pelo c rculo preto na parte superior da gura, e termina no estado nal, indicado pelos dois c rculos conc entricos, o menor preto e o maior branco, na parte inferior da gura 2.13. Um desvio ou ramica c ao (do ingl es decision) e uma estrutura utilizada para especicar caminhos alternativos de execu c ao. Como pode ser visto na Figura 2.13, ele e representado por um losango que possui uma transi c ao de entrada e v arias sa das distintas. A sele c ao da sa da correta se d a a partir da resolu c ao de express oes booleanas, denidas em cada uma das sa das. Um desvio e similar a um comando condicional de uma linguagem de programa c ao. Na Figura 2.13, o u nico desvio existente escolhe a Atividade B se a condi c ao [cond1] for verdadeira e a Atividade C se a condi c ao [cond2] for verdadeira (relembrando: as condi c oes devem ser disjuntas). Uma
52
Reservar Publicao Cancelar Reserva << extend >> Usurio Calcular Tempo de Emprstimo << include >> Renovar Emprstimo Emprestar Exemplar Emprestar sem Renovao << include >> Cobrar Multa Devolver Exemplar Aluno Validar Usurio << include >> << extend >> << include >> Suspender Usurio Bloquear Exemplar Funcionrio << include >> Manter Dados Usurio << extend >> Manter Cadastros << extend >> Consultar Crdito Contactar Usurio << extend >> << extend >> Cancelar Suspenso
De acordo com o tipo do cliente
Sistema Contbil
Tempo Se o usu rio for des vinculado da universidade
Desbloquear Exemplar Professor
Manter Dados Publicao
Manter Dados Exemplar
Sistema de Crdito Bibliotecrio
Figura 2.12: Diagrama de Casos de Uso do Sistema da Biblioteca intercala c ao (do ingl es merge), que e opcional, indica o nal da execu c ao de um bloco condicional iniciado por um desvio. Apesar de tamb em ser representado por um losango, a intercala c ao e complementar ao desvio, possuindo m ultiplas transi c oes de entrada e apenas uma de sa da. Ao t ermino do bloco condicional, independentemente de qual atividade tenha sido executada (B ou C), a Atividade D e executada. Uma das caracter sticas mais importantes de um diagrama de atividades e a facilidade de se representar atividades que s ao executadas de forma concorrente. Para indicar que dois subuxos do uxo de eventos devem executar concorrentemente, usa-se o s mbolo de separa c ao (do ingl es fork), que e representado por uma barra s olida (horizontal ou vertical) com exatamente um uxo de entrada e v arios uxos de sa da. Essas sa das indicam subuxos que s ao executados em paralelo quando a transi c ao e acionada. Sempre que iniciamos uma execu c ao concorrente, e necess ario indicar o ponto da execu c ao onde a concorr encia termina. Nesse local acontece o que chamamos de sincroniza c ao, permanecendo assim at e que todos os caminhos de execu c ao nalizem. Para representar o m da concorr encia

Estado Inicial
53
Atividade A
separao [cond. 1] desvio [cond. 2]
Atifidade E
Atividade B
Atividade C
intercalao
Atividade D
juno
Estado Final
Figura 2.13: Um Exemplo Simples de Diagrama de Atividades
em um diagrama de atividades, utiliza-se o s mbolo de jun c ao (do ingl es join), tamb em conhecido como uni ao. Sua representa c ao tamb em se d a a partir de uma barra s olida, por em, com duas ou mais entradas e uma u nica sa da. Um detalhe importante e o balanceamento entre separa c oes e jun c oes. Isso signica que o n umero de uxos que saem de uma separa c ao deve ser necessariamente o mesmo n umero de uxos que entram na jun c ao correspondente. Na Figura 2.13, logo depois que a Atividade A termina, dois subuxos concorrentes s ao executados; um contendo apenas a Atividade E e o outro contendo as atividades B, C e D. Esses subuxos se juntam imediatamente antes do estado nal ser alcan cado. A Figura 2.14 apresenta um diagrama de atividades correspondente ao uxo de eventos do caso de uso Emprestar Exemplar. Neste diagrama s ao representados dois uxos alternativos. O primeiro e iniciado quando o usu ario est a suspenso para empr estimo. O segundo por sua vez, e ativado quando apesar do cliente estar apto a realizar empr estimos, o exemplar desejado encontra-se indispon vel para empr estimo. Essa indisponibilidade pode ser conseq u encia de um bloqueio por parte de um professor. Al em de oferecer uma maneira gr aca de representar o uxo de eventos de um caso de uso, diagramas de atividade tamb em s ao u teis para descrever algoritmos seq uenciais complicados e especicar o comportamento de aplica c oes paralelas e concorrentes.
54
Incio
O usurio solicita emprstimo de um ou mais exemplares de publicaes
O atendente solicita o emprstimo ao sistema
[fim do loop] Fim [para cada exemplar] O atendente fornece o nmero de registro do exemplar
O sistema valida o usurio e verifica o seu status
O sistema verifica se o exemplar pode ser emprestado pelo usurio [status = "Normal" & exemplar indisponvel] [status = "Normal" & exemplar disponvel] [status = "Suspenso"] O sistema encerra a operao Fim
O sistema verifica se o exemplar est reservado
[exemplar reservado]
O sistema cancela a reserva
O sistema calcula o perodo do emprstimo
O sistema concretiza o emprstimo do exemplar
[caso contrrio]
Figura 2.14: Diagrama de Atividades para o Caso de Uso Emprestar Exemplar
2.9.11
Diagramas de Intera c ao de Sistema
As intera c oes entre os atores e o sistema podem ser representadas atrav es de diagramas de intera c ao de sistema. A principal caracter stica desses diagramas e a representa c ao do sistema como uma caixa-preta. Assim, a sem antica proporcionada pelos diagramas de intera c ao de sistema e feito [29]. A representa c ao da intera c ao descreve o que o sistema faz sem se preocupar com o como do sistema pode ser feita tanto atrav es de um diagrama de seq u encia, quanto atrav es de um diagrama de colabora c ao, que s ao diagramas din amicos da UML. Esses diagramas, descritos a seguir, ser ao detalhados no Cap tulo 5. De uma maneira geral, os diagramas de intera c ao de sistema s ao modelos que ilustram eventos entre atores e o sistema. Ele mostra, para um cen ario particular de um caso de uso, os eventos que os atores geram e a ordem com que esses eventos s ao executados. Dessa forma, a enfase desses
Cap tulo 2: Casos de Uso diagramas est a nos eventos que cruzam a fronteira do sistema [29].
55
A principal diferen ca entre os diagramas de seq u encia e os diagramas de colabora c ao est a na enfase dada por cada um deles. Enquanto os diagramas de seq u encia enfatizam a ordem em que os participantes da intera c ao se comunicam, os diagramas de colabora c ao enfatizam as conex oes entre os participantes. A Figura 2.15 mostra um diagrama de seq u encia de sistema com as intera c oes em um cen ario do caso de uso Emprestar Exemplar, onde o usu ario realiza o empr estimo de um exemplar com sucesso. O diagrama apresenta os atores do sistema da Biblioteca e o objeto (:SistemaBiblioteca) que representa o pr oprio sistema computacional.
<< actor >> :Usurio 1 : Solicitar Emprestimo 2 : Emprestar Exemplar 3 : Validar Usuario 4 : Verificar Exemplar Disponivel 5 : Calcular Tempo Emprestimo 6 : Registrar Emprestimo 2.1 : Emprestimo OK << actor >> :Atendente :SistemaBiblioteca
1.1 : Emprestimo OK
Figura 2.15: Diagrama de Seq u encia de Sistema para um Cen ario de Emprestar Exemplar Em um diagrama de seq u encia, os participantes da intera c ao aparecem no topo do diagrama, como ret angulos. Os nomes associados aos participantes indicam seus tipos e s ao sublinhados para ressaltar que eles s ao inst ancias de classes, isto e, objetos e n ao classes.Como visto no Cap tulo 1 deste livro (Se c ao 1.3.2), classe e a descri c ao de um molde que especica as propriedades e o comportamento relativo a um conjunto de objetos similares As mensagens entre os participantes s ao representadas pelas setas entre as linhas verticais abaixo dos mesmos. Al em de representar as mensagens em si com sua origem e destino, os diagramas de seq u encia enfatizam a ordem cronol ogica entre todas as mensagens da intera c ao. Essa ordem e denida atrav es da posi c ao que a mensagem ocupa na linha de tempo do objeto (linha vertical tracejada). Por exemplo, na Figura 2.15, Emprestar Exemplar ocorre antes de Registrar empr estimo, j a que se encontra em uma posi c ao mais alta no diagrama. Al em de enviar mensagens para outros participantes, um participante pode enviar uma men-
56
sagem para si mesmo (auto-referencia c ao) para indicar que est a realizando algum trabalho interno. Na gura, um exemplo disso e a mensagem Validar usu ario, que o objeto :SistemaBiblioteca envia para si mesmo quando recebe uma mensagem Emprestar exemplar, advinda do objeto :Atendente. Voc e pode tamb em construir um diagrama de colabora c oes de sistema (Figura 2.16) para uma melhor visualiza c ao das associa c oes entre os diversos objetos (no caso, atores e o sistema).
<< actor >> :Usuario
1 : Solicitar Emprestimo
<< actor >> :Atendente
2 : Emprestar Exemplar :SistemaBiblioteca
3 : Validar Usuario 4 : Verificar Exemplar Disponivel 5 : Calcular Tempo Emprestimo 6 : Registrar Emprestimo
Figura 2.16: Diagrama de Colabora c ao de Sistema para um Cen ario de Emprestar Exemplar Em um diagrama de colabora c ao, os participantes da intera c ao s ao representados da mesma maneira como aparecem em um diagrama de seq u encia, por em, n ao e necess ario dispor os objetos de uma maneira pr e-denida. Associa c oes entre os objetos s ao indicadas explicitamente no diagrama atrav es de linhas que ligam dois participantes. As mensagens, por sua vez, s ao representadas por setas. Diferentemente do que ocorre em diagramas de seq u encia, nos quais a ordem entre as mensagens e expl cita, num diagrama de colabora c ao ela s o pode ser representada atrav es do artif cio de enumera c ao das mensagens.
2.9.12
In cio da An alise
Nos diagramas anteriores, o sistema foi tratado de forma monol tica (como uma caixa preta); a fase de an alise e respons avel por particionar/identicar os objetos que comp oem o sistema internamente. Nessa fase, os componentes do sistema s ao identicados gradativamente a partir dos casos de uso e representados num diagrama de classes UML. Como apresentado na Figura 2.17, esse diagrama e constru do a partir da identica c ao das principais entidades conceituais do sistema e da especica c ao da maneira como elas se relacionam. Como visto na Se c ao 1.3.4, cada entidade, conhecida como classe, encapsula os seus dados atrav es de atributos e o seu comportamento atrav es de opera co es. A identica c ao das classes do sistema baseia-se principalmente na an alise do dom nio do neg ocio,
57
denido na especica c ao dos casos de uso. No contexto do sistema para controle de bibliotecas, n os sabemos que a entidade publica c ao faz parte do seu dom nio. Al em disso, sabemos que publica c oes s ao tipos de item emprest avel. A decis ao de modelar o conceito de publica c ao separado do conceito de item emprest avel se baseia na possibilidade da biblioteca disponibilizar outros itens para empr estimo, como por exemplo, DVDs, CDs de m usica , etc., como mostrado na Se c ao 2.9.3. As opera c oes emprestar() e devolver(), comuns a todos os itens emprest aveis, s ao identicadas na classe ItemEmprest avel. O diagrama de classes do sistema da biblioteca mostrado na Figura 2.17 e parcial. No Cap tulo 3 veremos uma forma sistem atica de construir um diagrama de classes mais elaborado, a partir das especica c oes dos casos de uso.
SistemaBiblioteca
:Usuario Publicacao titulo :String
:Atendente ItemEmprestavel status :int numRegistro :String + emprestar (): + devolver ():
Livro
CD
DVD
Figura 2.17: Modelo de Classes Preliminar para o Sistema da Biblioteca
2.10
Resumo
Os requisitos de um software representam a id eia do usu ario a respeito do sistema que ser a desenvolvido. Em geral, os requisitos podem ser vistos como condi c oes ou capacidades necess arias para resolver um problema ou alcan car os objetivos pretendidos. Durante a fase de especica c ao dos requisitos e feita uma distin c ao clara entre as funcionalidades especicadas para o sistema (requisitos funcionais) e os atributos de qualidade desejados, que s ao materializados pelos requisitos n aofuncionais. Apesar de n ao representarem funcionalidades diretamente, os requisitos n ao-funcionais podem interferir na maneira como o sistema deve execut a-las. Os requisitos de um sistema s ao representados atrav es de um documento, conhecido como documento de requisitos. Esse documento deve registrar a necessidade real dos usu arios e suas
58
expectativas, dimensionar a abrang encia do sistema e delimitar o seu escopo. Em UML, essa representa c ao e feita atrav es do conceito de casos de uso. A modelagem de casos de uso e uma t ecnica que auxilia o entendimento dos requisitos de um sistema computacional atrav es da cria c ao de descri c oes narrativas dos processos de neg ocio (casos de uso), al em de delimitar claramente o contexto do sistema computacional (atores). Existem tr es maneiras de representar a forma como dois casos de uso se relacionam entre si: (i) relacionamento de inclus ao (<< include >>), que indica a inclus ao do comportamento de um caso de uso em outro; (ii) relacionamento de extans ao (<< extend >>), que indica uma inclus ao condicional; e (iii) relacionamento de generaliza c ao/especializa c ao (Se c ao 1.3.5), que representa o conceito de subtipo. O comportamento de um caso de uso e detalhado atrav es da descri c ao de uxos de eventos. Esses uxos denem uma seq u encia de comandos declarativos, incluindo desvios condicionais e itera c oes. Inst ancias desses uxos, onde as decis oes e itera c oes s ao pr e-denidas s ao conhecidas como cen arios de uso. Em UML, a forma indicada para representar gracamente os uxos e atrav es de diagramas de atividades. J a os cen arios de uso s ao normalmente representados atrav es de diagramas de seq u encia ou diagramas de colabora c ao. Por ocultar os detalhes internos do sistema e se preocupar unicamente com a representa c ao da intera c ao do sistema com o meio externo, os diagramas de seq u encia e colabora c ao feitos durante a especica c ao dos casos de uso s ao classicados como diagramas de sistema, isto e, diagramas de seq u encia de sistema e diagramas de de colabora c ao de sistema, respectivamente. Com os casos de uso especicados, o pr oximo passo e detalhar o sistema internamente. Do ponto de vista da an alise orientada a obetos, esse detalhamento consiste na identica c ao das classes internas que comp oem o sistema e do relacionamento e regras de intera c ao entre elas.
2.11
Exerc cios
1. Dado o seguinte enunciado de um sistema de Ponto de Venda (PDV): Um sistema de ponto de vendas e um sistema computacional usado para registrar vendas e efetuar pagamentos. Ele inclui componentes de hardware, como um computador e um scanner de c odigo de barras, al em dos componentes de software para o controle do sistema. Nesse exemplo, estamos interessados na compra e pagamento de produtos. Os requisitos b asicos de funcionamento do sistema s ao nove: (i) registrar os itens vendidos em cada venda; (ii) calcular automaticamente o total de uma venda, incluindo taxas; (iii) obter e apresentar as informa c oes sobre cada produto mediante a leitura de seu c odigo de barras; (iv) reportar ao estoque a quantidade de cada produto vendido quando a venda e completada com sucesso; (v) registrar cada venda completada com sucesso; (vi) exigir que o atendente forne ca sua senha pessoal para que possa operar o sistema; (vii) o sistema deve ter um mecanismo de armazenamento de mem oria est avel; (viii) receber pagamentos em dinheiro ou
Cap tulo 2: Casos de Uso cart ao de cr edito; e (ix) emitir mensalmente o balan co do estoque.
59
(a) Classique os nove requisitos do sistema de pontos de venda entre funcionais e n aofuncionais. Os requisitos n ao-funcionais devem ser categorizados de acordo com a nomenclatura ABNT/ISO 9126, apresentada na Se c ao 2.1. (b) Especique o diagrama de casos de uso do sistema; (c) Identique os relacionamentos entre os diversos casos de uso do sistema usando << include >> e << extend >>. (d) Descreva um dos casos de uso do sistema usando o formato da Se c ao 2.6. 2. Dado o seguinte enunciado de um sistema de Controle de Videolocadora: Um sistema de controle para uma videolocadora tem por objetivo automatizar o processo de loca c ao e devolu c ao de tas de v deo. Deve-se manter um controle dos cadastros de clientes e seus respectivos dependentes e tamb em um controle sobre o acervo de tas e sua movimenta c ao. Os clientes podem executar opera c oes que envolvem loca c ao, devolu c ao e compra de tas. Caso a ta n ao seja devolvida no prazo previsto, uma multa ser a cobrada. Caso o cliente perca ou danique uma ta alugada, ele deve ou pagar uma multa equivalente ao pre co de uma ta nova, ou comprar uma nova ta para substituir a que foi danicada. (a) Especique o diagrama de casos de uso do sistema; (b) Identique os relacionamentos entre os diversos casos de uso do sistema usando << include >> e << extend >>. (c) Atualize o diagrama de casos de uso especicado para contemplar as seguintes restri c oes, adicionadas ao sistema: O cliente VIP pode alugar um n umero ilimitado de tas; caso contr ario, o n umero m aximo de tas e limitado a tr es. O pagamento pode ser efetuado no ato da loca c ao ou da devolu c ao e pode ser feito em dinheiro, com cart ao de cr edito, ou atrav es de cheque-v deo, que e comprado antecipadamente. Se pagar com cheque-v deo, o cliente recebe um desconto especial. 3. Considere os seguintes requisitos de um sistema para gest ao de um estacionamento: O controle e efetuado com base na placa do ve culo, que deve estar cadastrado no sistema. Na entrada do estacionamento deve existir um funcion ario inserindo os n umeros das placas no sistema, que registra automaticamente a data e a hora de in cio. Se o ve culo n ao estiver cadastrado, o funcion ario deve cadastr a-lo. O cadastro e feito em duas etapas: (i) cadastro do respons avel; e (ii) associa c ao do ve culo ao respons avel. O funcion ario tamb em pode editar os dados do respons avel ou alterar os ve culos associados a ele.
60
Cap tulo 2: Casos de Uso Na sa da do estacionamento, o funcion ario registra novamente o n umero da placa do ve culo. Nesse momento, o sistema calcula o valor a pagar pelo servi co. O estacionamento tem clientes avulso e clientes mensalistas. Para os clientes mensalistas, o sistema deve oferecer a possibilidade de adicionar o valor na conta do usu ario, que e paga mensalmente. O gerente do estacionamento consulta diariamente um relat orio do sistema. Em algumas situa c oes, o gerente poder a desempenhar as fun c oes de atendimento, no entanto, apenas o gerente pode solicitar o relat orio. Construa um diagrama de casos de uso para esse sistema. Tente aplicar os relacionamentos de << include >> e << extend >> no seu modelo. 4. Modele o diagrama de casos de uso de um sistema de gerenciamento de hotel descrito a seguir, seguindo as diretrizes propostas na Se c ao 2.9: Um grupo de empres arios deseja que sua equipe desenvolva um sistema para gerenciar reservas e ocupa c oes de apartamentos em uma rede de hot eis. O sistema ser a utilizado para controlar servi cos internos de cada hotel e para a comunica c ao entre hot eis da rede de forma que seja poss vel que uma unidade da rede fa ca consultas sobre a disponibilidade de vagas em outras unidades da mesma cidade ou regi ao. Os servi cos b asicos a ser considerados s ao: Entrada para cadastro de cliente (nome, endere co, e-mail, data de chegada, data de sa da, classica c ao do cliente, documento); Consultas, reservas e cancelamento de reserva atrav es da Web; Caso uma reserva n ao seja cancelada e nem ocupada no prazo especicado, e cobrada uma tarifa de no show, correspondente a 30% do valor da di aria; Cadastro de apartamento: tipo de apartamento (su te, standard, duplo, arcondicionado), cidade ou local; Cadastro de salas e audit orio; Cadastro de despesas; Servi cos adicionais s ao tamb em inclu dos no sistema: telefone, TV paga, acesso ` a internet, frigobar, lavanderia, servi co de lanche e caf e da manh a; Conex ao para consultas e reservas de vagas em outros hot eis do grupo; Controle de ocupa c ao de apartamentos (reservado ou entrada do h ospede); Controle de ocupa c ao de salas e audit orio; Controle de limpeza dos apartamentos; Descontos para clientes VIP e grupos; Recebimento de pagamento (tipo de pagamento cheque, dinheiro, cart ao, parcelado, moeda estrangeira); Emiss ao de nota scal (podendo ser separado por itens: hospedagem, restaurante, lavanderia, etc); Emiss ao da fatura parcial (somente para consulta);
Cap tulo 2: Casos de Uso Emiss ao de relat orios cont abeis; Emiss ao de relat orios de ocupa c ao; Emiss ao de relat orios de h ospedes em d ebito; Relat orios parciais de consulta;
61
Gerar relat orios estat sticos (m edia de dias que o cliente hospeda, gastos m edios, itens mais consumidos nos restaurantes); Esse sistema deve ser interligado a um sistema cont abil, que e respons avel pelo pagamento dos servi cos consumidos no hotel.
62
Cap tulo 3
An alise Orientada a Objetos: Modelagem Est atica

Este cap tulo apresenta uma s erie de passos e t ecnicas para a elabora c ao de modelos conceituais, utilizando a nota c ao UML. Essa seq u encia de passos bem denidos auxilia a especica c ao do modelo de an alise de sistemas de software a partir dos requisitos estabelecidos. Assumimos que esses requisitos s ao especicados atrav es de casos de uso (Cap tulo 2), embora as id eias apresentadas sejam gen ericas o suciente para possibilitar a sua utiliza c ao conjunta com outros artefatos de descri c ao de requisitos.
3.1
An alise OO x Projeto OO
Um processo de desenvolvimento de software tem por objetivo enfatizar princ pios de boas pr aticas de desenvolvimento e proporcionar diretrizes que o desenvolvedor possa adotar. Entretanto, as atividades envolvidas nessa tarefa requerem habilidades criativas e individuais, experi encias passadas e bom senso. Uma das partes mais importantes de um processo de desenvolvimento de software e o conjunto de diretrizes que sugere como decompor sistemas grandes e complexos em componentes menores que possam ser manipulados mais facilmente. A aplica c ao de conceitos de orienta c ao a objetos para o desenvolvimento de software traz novas solu c oes para velhos problemas, mas tamb em demanda a confec c ao de novos m etodos e processos que adotem uma abordagem completamente nova. Sendo assim, um processo de desenvolvimento de software orientado a objetos difere dos processos tradicionais na maneira particular como decomp oe o sistema em partes menores e na natureza dos relacionamentos entre essas partes. Al em disso, numa abordagem cl assica, as fases de an alise, projeto, implementa c ao e testes s ao geralmente 63
64
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica
vistas como fases globais e separados a serem executados seq uencialmente no ciclo de vida do sistema inteiro (veja a discuss ao da Se c ao 1.4.1). Na abordagem orientada a objetos, essa id eia n ao se aplica. A seq u encia de fases de an alise, projeto, implementa c ao e testes pode ser adotada para o ciclo de vida de classes individuais, e n ao necessariamente para o sistema inteiro como na abordagem cl assica. Embora n ao haja uma padroniza c ao de termos na area de an alise e processos de desenvolvimento orientado a objetos, existe uma distin c ao comum feita entre an alise orientada a objetos e projeto orientado a objetos. Em geral, a fase de an alise lida com o dom nio do problema, enquanto que a fase de projeto lida com o dom nio da solu c ao. A seguir, e mostrada uma descri c ao mais precisa desses termos: An alise OO. Modela o mundo real de tal modo que ele possa ser compreendido. Durante a an alise, a enfase est a em encontrar e descrever as entidades do dom nio do problema que sejam relevantes para o sistema que se pretende construir. Projeto OO. Dene as entidades de software que fazem parte do dom nio da solu c ao e que ser ao implementadas em uma linguagem de programa c ao orientada a objetos. O modelo de an alise e uma abstra c ao do modelo de projeto. Gra cas ` a sua abstra c ao, o modelo de an alise omite v arios detalhes de como o sistema funciona e proporciona um panorama geral da funcionalidade do sistema. Por ser um renamento do modelo de an alise, o modelo de projeto consiste de um conjunto de colabora c oes que representam a estrutura e o comportamento do sistema, de forma mape avel a pelo menos uma linguagem de programa ca o orientada a objetos. A maneira como o sistema se comporta e derivada do modelo de casos de uso e dos requisitos n ao-funcionais especicados para ele.
3.2
Modelagem Est atica x Modelagem Din amica
A an alise orientada a objetos cria uma especica c ao que utiliza termos e entidades do dom nio do problema para a representar principalmente os requisitos funcionais do sistema (Se c ao 2.1). Durante a an alise, s ao modelados aspectos est aticos e din amicos do dom nio do problema. Na modelagem est atica, conceitos do mundo real relevantes para o sistema a ser constru do s ao inclu dos em um diagrama de classes de an alise, tamb em conhecido como modelo de objetos ou modelo conceitual [29]. Basicamente, esse modelo e composto das principais entidades do sistema (classes), os atributos dessas classes e os relacionamentos entre elas. A modelagem est atica e o foco deste cap tulo. A modelagem din amica descreve os aspectos do sistema de software que podem mudar com o tempo devido ` a ocorr encia de eventos e que dizem respeito ao seu uxo de controle. A modelagem din amica usa diagramas din amicos de UML, como diagramas de seq u encia, de atividades e de colabora c ao, para modelar as intera c oes entre objetos no sistema. Esses objetos s ao inst ancias das
65
classes de an alise e est ao contidos no dom nio do problema. A modelagem din amica tamb em afeta o modelo de classes de an alise, enriquecendo-o com elementos ligados ao comportamento do sistema, como as opera c oes. A modelagem din amica e apresentada em detalhes no Cap tulo 5.
3.3
Metodologias para An alise Orientada a Objetos
Em geral, programas bem estruturados fazem mais do que simplesmente satisfazer seus requisitos funcionais. Um software que segue pr aticas apropriadas para a sua constru c ao tem maiores chances de estar correto e ser reutiliz avel, extens vel e f acil de depurar. Vale enfatizar que as diretrizes de projeto advindas da abordagem convencional, tais como particionamento, hierarquia, modularidade, etc., que foram vistas na Se c ao 1.1.1, tamb em s ao aplic aveis ao desenvolvimento orientado a objetos. Como discutido na Se c ao 1.2, os principais benef cios do desenvolvimento orientado a objetos s ao: (i) aumentar a produtividade no desenvolvimento e (ii) facilitar a manuten c ao (adi c ao de melhorias e modica c oes) de sistemas de software. Esse aumento da produtividade e uma conseq u encia tanto do melhor entendimento do sistema, quanto do maior grau de reutiliza c ao de suas partes. Por ser um tema atual de pesquisa, existem muitos trabalhos na literatura que enfatizam a reutiliza c ao de software de maneira sistem atica. A maioria desses trabalhos destacam a import ancia dos processos de desenvolvimento e do paradigma de objetos para reduzir o acoplamento entre as diversas partes que comp oem o sistema. Al em de maximizar a reutiliza c ao, a redu c ao do acoplamento entre os m odulos do sistema melhora consideravelmente o seu requisito de manutenibilidade. V arios processos orientados a objetos diferentes podem ser encontrados na literatura. Cada um desses processos introduziu um m etodo para a an alise de sistemas de software, um conjunto de diagramas que evoluiu a partir do m etodo, e uma nota c ao para representar os diagramas e modelos de uma maneira consistente. Apesar dessa diversidade, desde o nal dos anos 90, um processo vem se tornando padr ao para o desenvolvimento de software orientado a objetos: o Rational Unied Process (RUP), da IBM. Esse processo surgiu da uni ao de tr es outras bastante populares: Booch [8] de Grady Booch, Object Modelling Technique (OMT) de James Rumbaugh [41] e OOSE [27] de Ivar Jacobson. Pode-se dizer que os processos existentes para desenvolvimento orientado a objetos s ao, na sua macro-estrutura, muito parecidos. Esta se c ao, descreve sucintamente como os processos OMT e RUP conduzem a fase de an alise orientada a objetos. Em seguida, e apresentado um processo composto dos passos principais, comuns a v arios processos de desenvolvimento orientado a objetos. Esse processo, que pode ser considerado uma inst ancia do RUP, ser a utilizado nos exemplos deste livro.
66
3.3.1
OMT
O processo OMT foi desenvolvido por Rumbaugh et.al. [40] para a an alise e projeto de sistemas de software no in cio dos anos 90. Como pode ser visto na Figura 3.1, a atividade de an alise nesta metodologia cria tr es modelos: (i) modelo de objetos; (ii) modelo din amico; (iii) modelo funcional. O modelo de objetos descreve os aspectos de um software em termos de um diagrama de classes. Esse modelo e uma abstra c ao da implementa c ao de um sistema e e representado por grafos cujos n os s ao classes, e arcos que denotam os relacionamentos de generaliza c ao/especializa c ao, agrega c ao/decomposi c ao ou associa c oes entre as classes. O modelo de objetos da OMT corresponde ao diagrama de classes UML. O modelo din amico descreve os aspectos do sistema que podem mudar com o tempo devido a ocorr ` encia de eventos e e usado para entender o uxo de controle do software. Ele pode ser ou um diagramas de uxo de eventos, equivalente aos diagramas de seq u encia e de colabora c ao UML, ou por diagramas de transi c oes de estados, cujos n os s ao estados e arcos s ao transi c oes causadas por eventos entre os estados. O modelo funcional e um reexo da vis ao centrada em dados dos processos contempor aneos ao OMT, que seguem o paradigma de programa c ao estruturada. O modelo funcional, que n ao tem um equivalente em UML, descreve as transforma c oes de dados dentro do sistema e emprega Diagramas de Fluxo de Dados (DFD) para representar computa c oes dos valores de sa da a partir de valores de entrada.
Entrevistar Usurios
Modelos Construdos: Construir Modelo de Objetos
Preparar o enunciado do problema
Obter Informaes do Domnio Construir Modelo Dinmico Avaliar Experincias Anteriores Construir Modelo Funcional
Figura 3.1: Est agio da An alise Os modelos de objetos, din amico e funcional s ao vis oes ortogonais da descri c ao de um sistema. Entretanto, o modelo de objetos e o mais importante porque ele descreve os elementos principais do sistema, independentemente de quando e como eles mudam. O produto da an alise e um documento que consiste do (i) enunciado do problema, (ii) modelo de objetos, (iii) modelo din amico e (iv) modelo funcional. A partir desses artefatos, e poss vel identicar: objetos e seus atributos, opera c oes, a visibilidade de cada objeto em rela c ao aos outros e a interface de cada objeto. Para sistematizar a constru c ao desses artefatos de an alise, o processo OMT apresenta oito atividades a serem executadas: (i) identicar objetos e classes; (ii) preparar dicion ario de dados;
67
(iii) identicar associa c oes (agrega c oes); (iv) identicar atributos; (v) renar com heran ca; (vi) testar os caminhos de acesso aos atributos usando cen arios; (vii) iterar e renar; e (viii) agrupar classes em m odulos. Primeiro, um conjunto de classes candidatas e encontrado e renado, a partir de uma descri c ao textual dos requisitos do sistema. Entre as classes encontradas, s ao eliminadas aquelas que n ao s ao importantes para o dom nio do problema e as que n ao s ao relevantes para o sistema que se pretende construir. As remanescentes s ao ent ao descritas em um gloss ario de termos espec cos do problema, que e usado pelos desenvolvedores. Depois que as classes de an alise s ao identicadas, associa c oes e atributos s ao encontrados a partir da especica c ao de requisitos e as classes s ao organizadas em hierarquias de heran ca. Cen arios s ao usados para vericar se os atributos e associa c oes encontrados s ao realmente relevantes e para denir o comportamento dos objetos. Esse processo e repetido at e que o modelo de objetos esteja est avel. Neste momento, as classes do modelo s ao agrupadas em m odulos.
3.3.2
RUP
Na segunda metade da d ecada de 90, Grady Booch [8], James Rumbaugh [40] e Ivar Jacobson [27] colaboraram para combinar as melhores caracter sticas de suas metodologias de an alise e projeto orientados a objetos. O resultado nal foi a elabora c ao da UML, uma linguagem concebida desde o princ pio para se tornar um padr ao em modelagem orientada a objetos. Embora a UML independa do processo de desenvolvimento utilizado, seus criadores tamb em se preocuparam em elaborar um processo para desenvolvimento de software baseado nela. Este processo foi batizado, inicialmente, de Unied Software Development Process [26]. Posteriormente, foi rebatizado para Rational Unied Process (RUP), pois a Rational Software Corporation contratou seus tr es criadores. Mais que um processo, o RUP e um imenso conjunto de m etodos, t ecnicas, documentos e procedimentos que visam ser o mais gen erico poss vel. Isso o torna muito complexo para ser usado diretamente, sendo necess ario adapt a-lo ` as necessidades de cada organiza c ao, eliminando-se partes que n ao sejam relevantes em um determinado contexto. Segundo o RUP, a an alise visa (i) identicar as classes que executam o uxo de eventos de um caso de uso e os relacionamentos entre essas classes (modelagem est atica) e (ii) distribuir o comportamento do caso de uso entre essas classes, atrav es de realiza c oes de casos de uso (modelagem din amica). A realiza c ao de um caso de uso consiste de um conjunto de diagramas din amicos da UML, tais como diagramas de seq u encia e de colabora c ao, que modelam o uxo de eventos e alguns cen arios do caso de uso. O RUP recomenda que durante a fase de an alise deve-se seguir as sete atividades seguintes: 1. Denir a estrutura do sistema. Esta etapa consiste na deni c ao dos m odulos principais do sistema e nas restri c oes de comunica c ao entre eles. Essa deni c ao estrutural inuenciar a todas as atividades seguintes, isto e, as restri c oes especicadas aqui dever ao ser satisfeitas adiante. 2. Complementar as descri co es dos casos de uso. No decorrer do desenvolvimento, e
68
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica comum sentir a necessidade de ajustar a especica c ao dos casos de uso. Essas mudan cas s ao fruto de uma maior contextualiza c ao com o problema e uma maior intera c ao com o cliente/usu ario. 3. Identicar classes de an alise. Essas classes devem ser identicadas a partir das especica c oes dos casos de uso. 4. Distribuir comportamento entre as classes de an alise. Isso acontece atrav es de simula c oes dos cen arios dos casos de uso, atrav es dos diagramas din amicos da UML. 5. Descrever responsabilidades das classes. Ap os a distribui c ao do comportamento entre as classes, as responsabilidades das classes j a est ao identicadas. A descri c ao dessas responsabilidades consiste na atualiza c ao do gloss ario, apresentado na Se c ao 2.9.4. 6. Identicar os atributos. Assim como a descoberta das classes, a identica c ao dos atributos se baseia na an alise da especica c ao dos casos de uso do sistema. 7. Estabelecer associa co es entre classes de an alise. As associa c oes entre as classes de an alise podem ser identicadas a partir dos diagramas din amicos j a especicados. Nesse sentido, a necessidade de intera c ao entre duas classes durante a execu c ao de opera c oes pode indicar a exist encia de associa c oes entre elas. O conceito de associa c ao foi apresentado na Se c ao 1.3.7.
Como apresentado ap os a deni c ao da estrutura do sistema, as descri c oes de casos de uso s ao complementadas. O objetivo desse detalhamento e capturar informa c oes adicionais necess arias para entender o comportamento interno que o sistema deve apresentar. Depois, um conjunto de classes de an alise candidatas e encontrado a partir das descri co es estendidas dos casos de uso. A m de determinar as responsabilidades das classes de an alise, cen arios (diagramas de seq u encia e colabora c ao) s ao constru dos com base nas classes de an alise encontradas e nas especica c oes dos casos de uso. Responsabilidades s ao extra das a partir das mensagens trocadas entre os objetos nos diagramas de intera c ao. Descri c oes curtas podem ser associadas a cada responsabilidade identicada, caso as descri c oes existentes nos casos de uso n ao sejam satisfat orias. Durante a etapa de projeto, as responsabilidades das classes de an alise s ao renadas para opera c oes. Finalmente, as informa c oes que devem ser mantidas pelas classes de an alise e as associa c oes entre essas classes s ao extra das das descri c oes dos casos de uso e dos diagramas de intera c ao especicados. Uma caracter stica importante do processo RUP e a preocupa c ao constante com a arquitetura de software, que dene o sistema em termos dos seus componentes conceituais e das restri c oes de comunica c oes entre eles. A arquitetura inicial, proposta pelo RUP, dene uma vis ao modular do sistema, sem detalhar os componentes envolvidos. Mais detalhes sobre arquitetura de software est a dispon vel na Se c ao 7.2.
69
1: Identificar Classes de Anlise
3: Identificar os Relacionamentos entre as Classes
2: Construir Dicionrio de Dados
4: Identificar os Atributos das Classes de Anlise
[iterar e refinar]
[no refinar] refinamento
Figura 3.2: Atividades da Modelagem Est atica
3.4
Um M etodo para An alise Orientada a Objetos Usando UML
As duas metodologias apresentadas nas Se c oes 3.3.1 e 3.3.2 fornecem um panorama u til, ainda que limitado, das metodologias para an alise orientadas a objetos. A OMT, apesar de j a ter sido bastante popular e de englobar diversas boas id eias, hoje em dia e considerada ultrapassada (por exemplo, ela n ao explora a no c ao de casos de uso). O RUP, por outro lado, e moderno e centraliza as qualidades existentes em v arias outras metodologias. Por outro lado, e complexo demais para ser usado sem modica c oes, o que limita um pouco sua aplicabilidade. Apesar das diferen cas entre as diversas metodologias existentes, os passos necess arios para realizar a an alise orientada a objetos s ao bastante parecidos em todas elas [39]. Isso pode ser percebido facilmente analisando-se as listas de atividades da OMT e do RUP, apresentadas nas se c oes anteriores. Essas atividades gen ericas s ao apresentadas na Figura 3.2: As atividades apresentadas na Figura 3.2 compreendem o que e normalmente chamado de modelagem est atica. Na literatura, a atividade de encontrar as opera c oes das classes de an alise pode ser considerada parte da modelagem est atica [26][39], ou parte da modelagem din amica [29][40]. Neste livro adotamos a segunda abordagem e deixamos esse passo para ser tratado no Cap tulo 5, que descreve a modelagem din amica. Conforme mencionado na Se c ao 3.3.2, a UML foi concebida para se tornar um padr ao em linguagem de modelagem. Conseq uentemente, ela n ao depende de uma metodologia espec ca. Apesar disso, seus criadores tinham em mente quatro caracter sticas que qualquer processo de desenvolvimento baseado na UML deveria seguir: (i) direcionamento por casos de uso; (ii) centrado na arquitetura; (iii) iterativo; e (iv) incremental. Essas caracter sticas s ao detalhadas a seguir:
Direcionado por casos de uso. Na UML, casos de uso capturam os requisitos funcionais do sistema. Como os casos de uso cont em descri c oes das funcionalidades que o sistema deve implementar, eles afetam todas as etapas do desenvolvimento.
70
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica Centrado na arquitetura. A arquitetura de um sistema computacional e formada pelo conjunto das suas estruturas. Essas estruturas englobam elementos de software e hardware, focando nas propriedades vis veis externamente desses elementos e nos relacionamentos entre eles [5]. Em um processo centrado na arquitetura, a deni ca o da arquitetura do sistema ea primeira atividade realizada durante a etapa de projeto. Iterativo. Em um processo interativo, sistemas s ao constru dos atrav es de diversas itera c oes, onde cada uma passa por todas as etapas do desenvolvimento e acrescenta algum elemento ao produto nal. Um exemplo desse renamento e o fato de no nal da an alise as classes serem renadas com modelos mais pr oximos do projeto, como por exemplo o MVC, que ser a apresentado na Se c ao 3.10.1. Incremental. Em um processo iterativo-incremental, cada itera c ao pode ser usada para construir uma parte do sistema, isto e, um resultado que pode ser testado e avaliado. Casos de uso oferecem uma maneira simples e natural de denir incrementos, j a que podem ser priorizados de modo que os mais importantes sejam desenvolvidos primeiro e os menos importantes depois.
A seguir, s ao apresentadas algumas t ecnicas para auxiliar na identica c ao das classes de an alise e os respectivos atributos. Em seguida, cada uma das atividades apresentadas na Figura 3.2 ser a detalhada e exemplicada no contexto do estudo de caso do sistema de bibliotecas, apresentado no Cap tulo 2.
3.4.1
T ecnicas para Extra c ao de Informa c oes
Durante a identica c ao de conceitos relevantes para o dom nio do problema, e importante tentar extrair o m aximo de informa c ao a partir das descri c oes dos casos de uso. De um modo geral, uma boa pr atica neste est agio inicial da modelagem e identicar mais classes de an alise do que realmente necess ario. A raz ao para isso e o fato de ser mais f acil descartar as classes desnecess arias do que depois precisar analisar os mesmos casos de uso novamente para identicar as classes ausentes. As situa c oes em que e necess ario voltar atr as acarretam desperd cio de tempo no ciclo de desenvolvimento do software. Para agilizar a constru c ao do software, os processos de desenvolvimento buscam antecipar o m aximo poss vel as informa c oes necess arias de maneira a evitar ciclos muito curtos. Uma outra maneira de agilizar o processo de desenvolvimento e identicar claramente os limites do sistema. Dessa forma, e poss vel excluir do modelo qualquer aspecto que n ao esteja diretamente relacionado com o problema que o sistema deve resolver. Um usu ario ou cliente e tipicamente um objeto que est a fora do escopo sistema que estamos tentando construir, a n ao ser que o sistema precise manter um registro dos seus dados, por exemplo, para controle de acesso. Embora devamos estar atentos ` as mensagens enviadas pelos usu arios, n ao existe nenhuma raz ao para model a-los como fundamental entender que, durante a an objeto. E alise, existem objetos externos ao sistema que fazem parte do dom nio do problema, mas que n ao estar ao representados no dom nio da solu c ao.
71
Diversas estrat egias podem ser empregadas para se obter as informa c oes relevantes para a constru c ao do diagrama de classes de an alise a partir de especica c oes de casos de uso. Neste livro, descrevemos tr es t ecnicas que auxiliam a identica c ao de classes candidatas para o modelo. S ao elas: (i) lista de categorias conceituais [29]; (ii) an alise textual; e (iii) an alise de dom nio, apresentada na Se c ao 2.9.3, no contexto de casos de uso. Essas t ecnicas s ao complementares e, sempre que poss vel, devem ser usadas em conjunto.
Lista de Categorias Conceituais Nessa estrat egia, classes candidatas podem ser identicadas com o aux lio de uma lista de categorias. Essa lista cont em diversas categorias que normalmente devem ser levadas em considera c ao para a constru c ao de sistemas de software. A seguir, s ao apresentadas as oito principais categorias apresentadas por Larman [29]: (i) objetos f sicos ou tang veis; (ii) especica c oes ou descri c oes de coisas; (iii) locais; (iv) transa c oes; (v) itens de transa c oes; (vi) pap eis de pessoas; (vii) outros sistemas ou dispositivos externos ao sistema; e (viii) eventos. As categorias n ao est ao organizadas de acordo com qualquer ordem de import ancia.
An alise Textual Por se basear unicamente em descri c oes textuais a respeito do problema, a abordagem de an alise textual pode ser utilizada desde os primeiros est agios da an alise. V arios processos de desenvolvimento se utilizam dessa caracter stica e prop oem formas sistem aticas de analisar artefatos como por exemplo o documento de uma entrevista, uma especica c ao dada por um especialista do dom nio, ou at e mesmo as especica c oes dos casos de uso. Na an alise textual, os substantivos identicados correspondem a objetos ou atributos e os verbos correspondem normalmente a associa c oes ou opera c oes (Figura 3.3). Al em disso, adjetivos e indica c oes de estado (palavras ap os verbo de liga c ao) podem indicar a necessidade de um atributo. Por exemplo, pela frase O profuto possui um c odigo r deve estar liberato para consumo, poderia ser identicada a classe candidata Produto, com os atributos c odigo e status da libera c ao. Como pode ser percebido, a ec acia da an alise textual e relativa, uma vez que sua precis ao depende da clareza do texto analisado. Mesmo assim, ela e um passo inicial u til para a identica c ao de classes candidatas e seus comportamentos.
Objetos/Classes Atributos Associaes Operaes
Enunciado do Problema OU Especificao dos Casos de Uso
Substantivos e Inf. de estado Verbos
Figura 3.3: Extra c ao de Informa c oes a partir do Enunciado do Problema A partir da pr oxima se c ao, cada uma das atividades da an alise orientada a objetos e apresentada
72
em detalhes. Para exemplicar o papel de cada uma delas, ser a utilizado o sistema de controle de bibliotecas, apresentado no Cap tulo 2.
3.5
Atividade 1: Identicar Classes de An alise
O primeiro passo para analisar os requisitos da aplica c ao e identicar os conceitos relevantes para o sistema que se pretende construir, no contexto do dom nio do problema. A atividade de extra c ao dessas entidades consiste basicamente na an alise dos casos de uso e dos outros documentos de requisitos do sistema, a m de identicar as entidades conceituais relevantes para o dom nio do problema. Uma vez obtidos, esses conceitos s ao transformados em classes, constituindo assim a primeira vers ao do diagrama de classes de an alise. Esse diagrama deve ser revisado at e que todos os elementos redundantes ou irrelevantes sejam removidos. Al em de decompor o dom nio do problema em unidades compreens veis para n ao-especialistas, a cria c ao do diagrama de classes de an alise contribui para o entendimento da terminologia ou vocabul ario desse dom nio. O diagrama de classes de an alise oferece meios para que desenvolvedores e especialistas no dom nio (usu arios, por exemplo) se comuniquem usando uma terminologia uniforme. Al em disso, esse diagrama, juntamente com as especica c oes dos casos de uso, s ao as principais fontes de informa c ao usadas por desenvolvedores durante a etapa de projeto do sistema. Durante a an alise, assim como em todas as outras etapas de um processo de desenvolvimento perfeitamente orientado a objetos, n ao h a a obriga c ao de acertar tudo na primeira tentativa. E aceit avel e at e esperado que o analista deixe escapar alguns conceitos relevantes durante a an alise importante ter em mente que o e s o perceba isso na fase de projeto, ou at e mesmo depois. E desenvolvimento deve ser iterativo (Se c ao 3.4) e que na pr oxima itera c ao haver a uma nova etapa de an alise. N ao vale a pena atrasar todo o cronograma do projeto tentando encontrar todo e qualquer conceito que tem alguma probabilidade, ainda que m nima, de ser relevante para o problema em quest ao. Um outra caracter stica da an alise orientada a objetos e o fato do seu principal produto, o diagrama de classes de an alise, ser uma descri c ao de elementos do dom nio do problema do mundo real, n ao do dom nio da solu c ao, que e o foco do projeto de software. Conseq uentemente, artefatos de software, tais como janelas e bancos de dados, n ao devem ser levados em considera c ao na an alise, a n ao ser que essas entidades fa cam parte do dom nio em quest ao, por exemplo, na modelagem de conceitos de software [29].
3.5.1
Atividade 1.1: Extrair Classes Candidatas
Para identicar classes candidatas em nosso estudo de caso, foram utilizadas as t ecnicas apresentadas na Se c ao 3.4.1: (i) lista de categorias conceituais; e (ii) an alise textual. A seguir, s ao mostradas as classes candidatas identicadas com cada uma dessas t ecnicas.
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica Lista de Categorias Conceituais
73
A Tabela 3.1 mostra as entidades descobertas no contexto do sistema de bibliotecas, para cada uma das categorias sugeridas. Tabela 3.1: Categorias e Entidades identicadas para o sistema da biblioteca Categoria Objetos tang veis Locais Transa co es f sicos ou Exemplo livro, peri odico, tese, manual, cart ao da biblioteca biblioteca empr estimo, reserva, cadastro de usu ario, inclus ao de nova obra no acervo Itens de transa co es Pap eis de pessoas Outros sistemas ou dispositivos sistema Eventos devolu c ao com atraso, reserva, empr estimo, perda, bloqueio, desbloqueio externos ao exemplar, publica c ao atendente, usu ario, bibliotec aria sistema de cadastro de publica c oes e usu arios
Como resultado, as seguintes classes candidatas foram identicadas: Livro, Peri odico, Tese, Manual, Cart ao da biblioteca, Biblioteca, Empr estimo, Reserva, Cadastro de Usu ario, Inclus ao de nova obra no acervo, Publica c ao, Atendente, Usu ario, Reserva, Empr estimo e Perda.
An alise Textual A identica c ao de classes candidatas a partir de an alise textual consistiu basicamente na procura de substantivos e refer encias a mudan cas de estado nas especica c oes dos casos de uso do sistema, que foram identiicados no Cap tulo 2. Posteriormente, para denir as associa c oes e opera c oes, ser a enfatizada a identica c ao de verbos. A seguir, apresentamos novamente a descri c ao do caso de uso Emprestar Exemplar, destacando
74
os substantivos e refer encias a estado encontrados. Caso de Uso: Emprestar Exemplar Atores: Usu ario, Atendente, Sistema de Cadastro. Descri c ao: Este caso de uso representa o processo de empr estimo de um ou v arios estimo se inicia com a solicita c ao feita pelo usuario exemplares da biblioteca. O empr ao atendente. Em seguida, atrav es de um terminal, o atendente solicita ao sistema o empr estimo dos respectivos exemplares. Pr e-condi c ao: O exemplar da publica c ao est a dispon vel, o usu ario est a cadastrado no sistema e o cliente n ao est a suspenso. P os-condi c ao: O exemplar est a emprestado. Restri co es Especiais: nenhuma. Fluxo B asico de Eventos: 1. O usu ario solicita empr estimo de um ou mais exemplares de publica c oes (livro, peri odico, tese ou manual), fornecendo o seu c odigo e os exemplares desejados; 2. O atendente solicita o empr estimo ao sistema, fornecendo o c odigo do usu ario; 3. Para cada exemplar a emprestar: 3.1 O atendente fornece o n umero de registro do exemplar. 3.2 O sistema valida o usu ario e verica o seu status (Normal ou Suspenso) atrav es de seu n umero de registro. (<< include >> Validar Usu ario); 3.3 O sistema verica se o exemplar pode ser emprestado pelo usu ario em quest ao; 3.4 Se o status do usu ario for Normal e o exemplar estiver dispon vel: 3.4.1. O sistema verica se a publica c ao est a reservada. Se estiver reservada: A. O sistema cancela a reserva, passando o n umero de tombo da publica c ao (<< extend >> Cancelar Reserva) 3.4.2. O sistema calcula o per odo do empr estimo, que depende do tipo de usu ario - 7 dias para alunos e 15 para professores (<< include >> Calcular Tempo de Empr estimo) 3.4.3. O sistema registra o empr estimo do exemplar; 3.4.4. O sistema atualiza seu banco de dados com a informa c ao de que o exemplar n ao ir a se encontrar na biblioteca at e completar o per odo. Fluxos Alternativos Fluxo Alternativo 1: No Passo 3.4, se o usu ario estiver suspenso, este e informado de sua proibi c ao de retirar exemplares e o empr estimo n ao e realizado. Fluxo Alternativo 2: No Passo 3.4, se todas as c opias da publica c ao estiverem emprestadas ou reservadas, o sistema informa ao atendente que n ao ser a poss vel realizar o empr estimo daquele exemplar. Se tiver outros exemplares para emprestar, v a para o Passo 3.1 do uxo b asico.
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica Entidades identicadas: exemplar empr estimo terminal est a dispon vel est a emprestado tese n umero de registro reserva tipo de usu ario professores per odo processo de empr estimo usu ario sistema est a cadastrado livro manual status n umero de tombo dias banco de dados proibi c ao biblioteca atendente publica c ao est a suspenso peri odico c odigo do usu ario est a reservada per odo de empr estimo alunos informa c ao c opias
75
3.5.2
Atividade 1.2: Eliminar Classes Inapropriadas
Depois que a lista inicial de classes candidatas e obtida, e necess ario ren a-la para eliminar o que n ao e classe, conceitos redundantes ou irrelevantes para o escopo do sistema. As principais justicativas para a elimina c ao de classes candidatas s ao: (i) itens sin onimos; (ii) itens irrelevantes para o contexto do sistema; (iii) itens que representam atributos de outra classe; e (iv) itens que representam conceitos vagos. Entre as classes candidatas listadas anteriormente, podemos eliminar as seguintes: processo de empr estimo: sin onimo de empr estimo. est a dispon vel: estado de exemplar (atributo). est a cadastrado: estado de usu ario (n ao e atributo). est a suspenso: estado de usu ario (atributo). est a emprestado: estado de exemplar (atributo). c odigo do usu ario: atributo de usu ario. n umero de registro: atributo de usu ario. status: atributo de usu ario. est a reservada: estado de publica c ao (n ao e atributo).
76
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica n umero de tombo: atributo de publica c ao. per odo de empr estimo: sin onimo de per odo. tipo de usu ario: essa informa c ao e capturada pela hierarquia formada entre usuario, aluno e professor. dias: termo vago. banco de dados: faz parte do dom nio da solu c ao. informa c ao: termo vago. per odo: atributo de empr estimo. proibi c ao: representa um papel (processo din amico). c opias: sin onimo de exemplar.
Note que poder amos ter eliminado tamb em as classes candidatas professor e aluno, j a que ambas poderiam ser representadas pela classe usu ario. Resolvemos deix a-las, por em, porque s ao conceitos relevantes e a decis ao de uni-las faz parte do dom nio da solu c ao, mais precisamente na fase de projeto do sistema. O mesmo vale para livro, peri odico, tese e manual com rela c ao a publica c ao.
3.5.3
Atividade 1.3: Renar a Lista de Classes Candidatas
Ap os eliminar algumas classes inapropriadas, a nova lista de classes identicadas e apresentada a seguir. As classes em destaque s ao as que n ao foram eliminadas: exemplar empr estimo terminal
est a dispon vel est a emprestado processo de empr estimo
usu ario sistema

est a cadastrado
biblioteca atendente publica c ao

est a suspenso
tese
n umero de registro
livro manual
status n umero de tombo dias banco de dados proibi c ao
peri odico
c odigo do usu ario est a reservada per odo de empr estimo
reserva
tipo de usu ario
alunos
informa c ao c opias
professores
per odo
77
A classe sistema e uma representa c ao sem antica do sistema e em fases posteriores do desenvolvimento poder a ser eliminada.
3.6
Atividade 2: Atualizar Dicion ario de Dados
Depois que as classes de an alise foram identicadas, e conveniente descrev e-las sucintamente em um dicion ario de dados. Este serve para aumentar o entendimento dos desenvolvedores sobre o dom nio do problema. O dicion ario de dados para o nosso estudo de caso e apresentado a seguir. Classe Publica ca ~o: representa as publica c oes pertencentes ao acervo da biblioteca. A classe publica c ao na realidade representa um conjunto de outras classes que s ao livros, peri odicos, manuais e teses. Classe Exemplar: representa as c opias de uma publica c ao; representa o objeto f sico que e emprestado. Classe Biblioteca: representa a biblioteca em si e por isso guarda os dados relativos a ela, tais como, nome, cnpj e endere co. Classe Empr estimo: representa o empr estimo de uma ou mais publica c oes a um usu ario. Essa classe guarda informa c oes como quais foram as obras emprestadas, quem as pegou emprestadas, quando o empr estimo foi realizado e qual o prazo para devolu c ao. Classe Usu ario: representa indiv duos que podem pegar livros emprestados na biblioteca. Dois tipos de usu arios s ao denidos pelo sistema: alunos e professores. Classe Atendente: representa o atendente, um tipo de usu ario que opera o sistema no estabelecimento da biblioteca. Classe Terminal: representa o ponto de acesso entre o usu ario e o sistema. Classe Sistema: representa o sistema como um todo e engloba todas as classes identicadas. Classes Livro, Peri odico, Tese e Manual: representam tipos de publica c oes existentes na biblioteca. Classe Reserva: representa uma reserva que um usu ario pode fazer a uma lista de publica c oes.
78
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica Classes Aluno e Professor: representam tipos de usu ario que podem pegar exemplares emprestados na biblioteca. Classe Item Emprest avel: representa as caracter sticas comuns de qualquer item que pode ser emprestado na biblioteca. Como discutido na Se c ao 2.9.12 do Cap tulo 2, a decis ao de modelar o conceito de publica c ao separado do conceito de item emprest avel se baseia na possibilidade da biblioteca disponibilizar outros itens para empr estimo, como por exemplo, DVDs, CDs de m usica , etc.
Vale a pena salientar que ap os a descri c ao do dicion ario de dados, pode ser conveniente atualizar o gloss ario, criado inicialmente durante a especica c ao dos casos de uso (Se c ao 2.9.4).
3.7
Atividade 3: Identicar os relacionamentos entre as classes
Neste est agio, realiza-se a identica c ao de associa c oes, agrega c oes e relacionamentos de heran ca entre as classes. A identica c ao das associa c oes e agrega c oes torna clara a responsabilidade de cada objeto e e o primeiro passo em dire c ao ` a especica c ao das opera c oes das classes do sistema. A identica c ao de relacionamentos de heran ca, por sua vez, promove um melhor particionamento dessas responsabilidades, atrav es do agrupamento das caracter sticas comuns a alguns subconjuntos de entidades.
3.7.1
Atividade 3.1: Identicar Associa c oes
Como apresentado na Se c ao 1.3.7, uma associa c ao em UML e um relacionamento estrutural entre objetos. Assim como as classes, associa c oes podem ser identicadas tanto atrav es das caracter sticas do dom nio, quanto analisando-se os documentos de requisitos e as descri c oes dos elementos do dicion ario de dados. Express oes do tipo conhece freq uentemente indicam a exist encia de associa c oes. A seguir, e apresentada uma lista com alguns crit erios que podem ser utilizados para auxiliar na descoberta de associa c oes entre as classes de an alise A e B [29]:(i) A e uma parte f sica ou l ogica de B; (ii) A est a contida em B; (iii) A e uma descri c ao de B; (iv) A e um tem de uma transa c ao ou relat orio B; (v) A e um membro de B; (vi) A e uma sub-unidade organizacional de B; (vii) A usa ou gerencia B; (viii) A se comunica com B; (ix) A est a relacionada com uma transa c ao B; e (x) A e possu do por B. Apesar de auxiliar na descoberta de associa c oes, a satisfa c ao de um dos crit erios anteriores pode n ao implicar necessariamente numa associa c ao entre entidades. Mas de uma maneira geral, relacionamentos entre duas classes cujo conhecimento precisa ser preservado durante algum tempo normalmente produzem associa c oes. Antes de identicar as associa c oes, vale a pena observar que associa c oes demais tendem a tornar o modelo confuso, ao inv es de deix a-lo mais claro. Descobr -las pode ser muito trabalhoso e trazer
79
poucos benef cios concretos. Por essa raz ao, evite colocar no modelo associa c oes que podem ser derivadas a partir de outras. Em resumo, na etapa de modelagem est atica, e mais importante identicar classes do que associa c oes. A forma como as classes se relacionam entre si e identicada naturalmente durante a modelagem din amica (Cap tulo 5), uma vez que a troca de mensagens entre objetos podem signicar a exist encia de uma associa c ao entre as classes.
3.7.2
Atividade 3.2: Identicar Agrega c oes
Os relacionamentos de agrega c ao e composi c ao, apresentados na Se c ao 1.3.6, s ao associa c oes que indicam rela c oes parte-todo entre duas ou mais classes distintas. Por exemplo, lendo a descri c ao da classe Sistema (Se c ao 3.6), e poss vel perceber que h a uma agrega c ao entre esta e todas as outras classes de an alise, j a que ela engloba todas as classes identicadas. De uma maneira geral, dadas duas classes (A e B), podemos dizer que B agrega A quando: (i) A e uma parte f sica ou l ogica de B; (ii) A est a contida em B; (iii) A e um tem de uma transa c ao ou relat orio B; (iv) A e um membro de B; (v) A e uma sub-unidade organizacional de B; e (vi) A e possu do por B.
3.7.3
Atividade 3.3: Identicar Heran ca
A identica c ao de relacionamentos de heran ca e mais simples do que a de associa c oes. Para encontrar relacionamentos de heran ca entre as classes de an alise identicadas, basta estud a-las e procurar por rela c oes do tipo e-um-tipo-de entre elas. Um exemplo claro no sistema de biblioteca e o relacionamento entre a classe Usu ario e as classes Atendente, Aluno e Professor. Al em disso, as classes Peri odico, Livro, Tese e Manual podem ser consideradas como sub-tipos de Publica ca ~o. A rela c ao das classes identicadas para o sistema pode ser identicada a partir do dom nio do problema ou do dicion ario de dados, apresentado na Se c ao 3.6. Ap os a identica c ao dos relacionamentos de heran ca, pode ser necess ario refatorar as associa c oes entre as classes. Essa refatora c ao tem o objetivo principal de mover as associa c oes comuns a todas as classes derivadas (lhas) para a classe base (superclasse). Al em disso, a exist encia de hirarquias de generaliza c ao/especializa c ao bem estruturadas possibilitar ao outros benef cios ao modelo. Um exemplo e a utiliza c ao do conceito de polimorsmo de inclus ao, que ser a visto na Se c ao 4.5.5 do Cap tulo 4. A Figura 3.4 apresenta o diagrama de classes de an alise depois da adi c ao de associa c oes, agrega c oes e relacionamentos de heran ca. Devido ao excesso de agrega c oes entre a classe Sistema e as demais classes modeladas, essa informa c ao conceitual de composi c ao das partes do sistema pode ser expressada atrav es do conceito de m odulo, que pode ser representado por pacotes UML (ver Se c ao 1.2.2). A Figura 3.5 apresenta o mesmo diagrama de classes de an alise da Figura 3.4 utilizando um pacote para expressar a composi c ao de todo o sistema.
80

Sistema
Terminal
Biblioteca Exemplar ItemEmprestavel
Reserva Publicacao
Emprstimo
Livro
Periodivo
Tese
Manual
Usuario
Aluno
Professor
Atendente
Figura 3.4: Diagrama de Classes Inicial de An alise

sistema Terminal << entity >> Biblioteca << entity >> Exemplar
<< entity >> Reserva
<< entity >> Publicacao
<< entity >> Emprstimo << entity >> Manual
<< entity >> Livro
<< entity >> Periodivo
<< entity >> Tese
<< entity >> Usuario
<< entity >> Aluno
<< entity >> Professor
<< entity >> Atendente
Figura 3.5: Diagrama de Classes Inicial de An alise (com Pacotes)
3.8
Atividade 4: Identicar/Atributos das Classes de An alise
No u ltimo est agio da modelagem est atica, s ao identicados os atributos das classes de an alise. Por em, nem todos os atributos precisam ser encontrados durante a an alise; e esperado que uma parte deles perten ca ` a solu c ao e por isso devem ser identicadas durante a fase de projeto. Os atributos que s ao identicados durante a fase de an alise, ou s ao inerentes ao dom nio da aplica c ao,
81
ou s ao aqueles que representam informa c oes relevantes para a realiza c ao dos casos de uso, isto e, aqueles que representam informa c oes explicitadas na especica c ao dos casos de uso. Sendo assim, esses atributos quase sempre est ao associados a classes de entidade. Como ser a visto a seguir (Se c ao 3.11), podem existir classes respons aveis unicamente pela coordena c ao da execu c ao dos servi cos. Essas classes normalmente s o precisam ter estado se for necess ario guardar informa c oes relativas ` a intera c ao com um certo usu ario, por exemplo informa c oes de se c oes, utilizadas no caso de v arios usu arios acessarem o sistema ao mesmo tempo. Mas normalmente esse tipo de informa c ao s o e levado em considera c ao e identicado a partir da fase de projeto. A identica c ao dos atributos e feita de maneira an aloga ` a identica c ao das classes, isto e, os atributos normalmente s ao identicados atrav es da an alise do dom nio e do estudo das especica c oes dos casos de uso do sistema, do enunciado do problema e do dicion ario de dados. De uma maneira geral, eles podem ser identicados a partir das classes candidatas descobertas atrav es da an alise textual desses artefatos, mais especicamente, a partir das classes descartadas no renamento do diagrama de classes de an alise, realizado pela Atividade 1.2 (Se c ao 3.5.2). Esses atributos normalmente representam conceitos simples que podem ser expressados usando-se tipos primitivos, como inteiros e caracteres. Quando n ao e o caso, e comum criar novas classes que representam registros de dados, onde cada atributo representa um campo do registro. Para enfatizar a sua import ancia, alguns autores d ao a essas classes o estere otipo << datatype >>. Exemplos de classes que normalmente denem tipos de dados s ao Endere co, Cor, Telefone, Ponto cartesiano, etc. [29]. De um modo geral, se um atributo de uma classe e muito complexo, provavelmente ele deveria ser denido como uma classe ` a parte. Depois, se for necess ario, as classes de atributos podem ser facilmente transformadas em atributos na fase de projeto do sistema.
3.9
Atributos das Classes de An alise no Estudo de Caso
Olhando rapidamente a lista de classes eliminadas na Se c ao 3.5.1, percebemos que v arias delas n ao se tornaram classes de an alise por representarem, na verdade, atributos de outras classes. Al em dessas informa c oes, e poss vel extrair algumas outras examinando a especica c ao do dicion ario de dados e os atributos inerentes ao dom nio da aplica c ao. A Tabela 3.2 associa os atributos identicados ` as classes correspondentes. Algumas informa c oes foram modicadas para se tornarem mais simples e de acordo com as orienta c oes descritas na se c ao anterior. Por exemplo, o per odo de um empr estimo foi denido atrav es de dois atributos: a data em que o empr estimo foi realizado (data de empr estimo) e a data esperada para devolu c ao data de devolu ca ~o. Tamb em podem ser adicionados ao modelo de an alise atributos obvios, relativos ao dom nio e que n ao apareceram na descri c ao dos casos de uso analisados. Deve-se ter cuidado, por em, com a deni c ao do que e ou n ao inerente ao dom nio. Por exemplo, no nosso estudo de caso, e perfeitamente coerente adicionar o atributo T tulo ` a classe Publica ca ~o, j a que qualquer publica c ao tem um t tulo. Por outro lado, apesar de tentador, n ao e adequado adicionar um atributo Au-
82
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica Tabela 3.2: Atributos identicados para o sistema de bibliotecas lise Classes de Ana Empr estimo Atributos data de empr estimo data de devolu ca ~o Usu ario status n umero de registro Publica ca ~o Item Emprest avel n umero de tombo identificador status Reserva data inicial data final
tor a essa classe, j a que, entre as publica c oes com as quais o sistema deve lidar, est ao peri odicos, publica c oes para as quais o conceito de autor normalmente n ao faz sentido. A Figura 3.6 apresenta o diagrama de classes de an alise depois de adicionados os atributos identicados nesta se c ao.
3.10
Atividade 5: Iterar e Renar
Por se tratar de um processo de desenvolvimento iterativo, o sistema e constru do gradativamente, a partir de renamentos sucessivos dos modelos produzidos. Essa constru c ao gradual do sistema proporciona uma distribui c ao da sua complexidade, o que al em de permitir mudan cas tardias dos requisitos, aumenta a qualidade nal do produto nal. Nesta se c ao, ser ao mostradas as atividades onde houve algum renamento do diagrama inicial de classes produzido na primeira itera c ao (Figura 3.6).
3.10.1
Atividade 1 (itera c ao 2): Identicar Classes de An alise
O processo RUP sugere que classes de an alise sejam dividas em tr es grupos, a m de classicar os elementos de acordo com o seu papel no modelo. O principal objetivo dessa classica c ao e simplicar a transi c ao da an alise para o projeto. Os tr es grupos denidos s ao: classes de entidade, classes de controle e classes de fronteira. Essa classica c ao das classes de an alise pode ser adotada desde
83
sistema Terminal Biblioteca
Reserva dataInicial :Date dataFinal :Date
Publicacao status :int numTombo :String
Exemplar Emprestimo dataEmprestimo :Date dataDevolucao :Date
Livro
Peridico
Tese
Manual
Usuario status :int numRegistro :String
Aluno
Professor
Atendente
Figura 3.6: Diagrama de Classes Inicial de An alise com Relacionamentos e Atributos o in cio da modelagem est atica, embora seja especialmente u til durante a modelagem din amica, quando diagramas de intera c ao envolvendo as classes de an alise s ao constru dos. Em um contexto mais geral, a divis ao entre entidade, controle e fronteira independe do processo utilizado e no contexto da orienta c ao ao objetos e considerado um padr ao de an alise chamado MVC (do ingl es Model-View-Controller). Um padr ao e uma solu c ao para um problema bem conhecido que j a foi empregada e validada em diversas ocasi oes distintas. O padr ao MVC pode ser usado em diversos n veis de abstra c ao diferentes, como projeto arquitetural, projeto detalhado e implementa c ao. O objetivo principal desse padr ao e separar explicitamente os dados (entidades), os controladores (controle) e as interfaces (fronteiras). No contexto do MVC, as interfaces representam os pontos de acesso entre o sistema e os seus elementos externos (usu arios, dispositivos de hardware e outros sistemas). Classes de entidade modelam informa c oes que devem ser armazenadas e o comportamento associado a elas. Objetos de entidade (inst ancias de classes de entidade) s ao usados para guardar e atualizar informa c oes sobre os elementos de dados relevantes para o sistema, como por exemplo um evento, uma pessoa, ou algum objeto da vida real. Os dados dessas entidades normalmente s ao persistentes, isto e, s ao armazenados em reposit orios permanentes, por exemplo, um banco de dados. Por em, os detalhes relacionados a ` persist encia dos dados em disco s ao espec cos de tecnologia e por isso s o devem ser considerados durante a fase de projeto. As classes de controle s ao os locais onde e implementada a l ogica do neg ocio, uma vez que elas modelam o comportamento de controle para um ou mais casos de uso. Essas classes podem contribuir para o entendimento do sistema porque representam seus aspectos din amicos, coordenando
84
as principais tarefas e uxos de controle entre as classes do sistema. Uma classe de fronteira, como o pr oprio nome indica, representa um ponto de acesso para o sistema a partir do meio externo. Por possibilitar esse ponto de acesso, as classe de fronteira modelam a intera c ao entre os elementos internos do sistema e os atores que se comunicam com ele. Essa intera c ao envolve entre outras coisas, a transforma c ao e a tradu c ao de eventos. Sendo assim, s ao as u nicas partes do sistema que conhecem e dependem dos elementos externos. Conseq uentemente, uma mudan ca na interface com o usu ario ou no protocolo de comunica c ao deve implicar em mudan cas apenas nas classes de fronteira e n ao nas de controle ou entidade. Posteriormente, na fase de projeto, o papel das classes de fronteira e normalmente atribu do ` a pr opria interface com o usu ario. Mas devido ` a sua relev ancia do ponto de vista conceitual, essas classes s ao representadas desde o diagrama de classes de an alise. Para cada tipo de classe de an alise, o RUP dene um estere otipo. Classes de entidade s ao identicadas pelo estere otipo << entity >>, classes de controle pelo estere otipo << control >> e classes de fronteira pelo estere otipo << boundary >>. Cada um desses estere otipos tem uma representa c ao gr aca, conforme mostrado na Figura 3.7.
Classes de Fronteira <<boundary>>
Classes de Controle <<control>>
Classes de Entidade <<entity>>
Figura 3.7: Representa c oes Gr acas para Estere otipos de Classes de An alise Al em de denir as tr es categorias de classes j a apresentadas, o padr ao MVC dene algumas restri c oes de relacionamento entre elas. A Figura 3.8 mostra as liga c oes poss veis entre classes estruturadas de acordo com o padr ao MVC. As classes de fronteira s o podem se associar ` as classes de controle. Essa restri c ao visa impedir, por exemplo, que uma classe de fronteira coordene a execu c ao de v arias classes de entidade, de modo a implementar as regras de neg ocio da aplica c ao, o que e papel exclusivo das classes de controle. Classes de entidade, de modo geral, tamb em s o se associam ` as classes de controle. H a casos especiais, por em, em que vale a pena criar uma associa c ao direta entre duas classes de entidade. Normalmente, essa associa c ao entre entidades pode ser justicada quando representa um relacionamento de agrega c ao. Um exemplo bastante comum e a liga c ao entre um cliente e suas contas em um sistema banc ario. Nessa situa c ao, o fato de um Cliente poder possuir Contas pode ser interpretado como uma agrega c ao, o que justica a perman encia da associa c ao. Esse tipo de decis ao deve ser tomado com cuidado, por em, j a que (i) a classe Cliente ca respons avel por manter a consist encia da associa c ao, o que pode torn a-la muito complexa, e (ii) essa liga c ao pode exigir uma associa c ao bidirecional entre as classes Cliente e Conta. Se a complexidade de uma associa c ao entre duas classes de entidade for muito grande, vale a pena pensar na possibilidade de criar uma nova classe controladora s o para gerenciar essa intera c ao. Revisando a lista de classes de an alise da itera c ao anterior, percebe-se a necessidade de se

Relacionamento entre classes no MVC
85
sistema Fronteira Controle Entidade
Ator
Figura 3.8: Liga c oes Poss veis entre as Classes do Padr ao MVC. adicionar uma nova classe ao modelo: a classe Controlador, que encapsular a as regras de neg ocio que o sistema deve implementar. Na especica c ao de requisitos vista no Cap tulo 2, essas regras s ao representadas pelos uxos dos casos de uso do sistema.
3.10.2
Atividade 3 (Itera c ao 2): Identicar os Relacionamentos entre as Classes
Ap os renar o modelo de an alise com o padr ao MVC, e necess ario vericar a necessidade de renar as associa c oes entre as classes, de acordo com as diretrizes apresentadas na Se c ao 3.7.1. Para isso, e necess ario analisar o modelo de duas formas complementares: (i) vericar a necessidade de liga c ao entre as novas classes (no nosso exemplo, a classe Controlador) e as classes j a existentes; e (ii) vericar a necessidade das associa c oes anteriores, ap os a adi c ao das classes novas. A liga c ao entre Terminal e Controlador pode ser compreendida, uma vez que o terminal, que faz a interface com os usu arios, precisa estar ligado ` a parte do sistema respons avel por suas regras de neg ocios, para que opera c oes, tais como empr estimo e consulta de fato sejam efetuadas. Al em disso, tanto o enunciado do problema quanto as descri c oes dos casos de uso deixam claro a necessidade de se ter os dados relativos ` a Publicacao, Exemplar, Emprestimo, Reserva e Usuario para efetivar opera c oes de reserva e empr estimo. Por esse motivo, a classe Controlador necessita estar associada as classes de entidade citadas. ` A Figura 3.9 apresenta o diagrama de classes da itera c ao anterior (Figura 3.6), com algumas modica c oes. A classe Controlador foi adicionada ao modelo, assim como as novas associa c oes e os s mbolos correspondentes aos estere otipos do padr ao MVC.
3.11
Padr oes de Modelagem
Desenvolvedores experientes de sistemas orientados a objetos constru ram ao longo dos anos um repert orio de solu c oes para problemas comuns encontrados durante o desenvolvimento. Para serem consideradas como padr oes, essas solu c oes, devem ser validadas atrav es do uso em diversas circunst ancias distintas, especicadas de uma maneira estruturada que descreve tanto a solu c ao quanto o problema que ela se prop oe a resolver.
86
sistema << boundary >> Terminal
<< control >> Controlador
<< entity >> Biblioteca << entity >> Exemplar << entity >> Publicacao << entity >> Reserva dataInicial :Date dataFinal :Date id :String status :String numTombo :String << entity >> Emprstimo dataEmprestimo :Date dataDevolucao :Date
<< entity >> Livro
<< entity >> Periodivo
<< entity >> Tese
<< entity >> Manual
<< entity >> Usuario status :int numRegistro :String
<< entity >> Aluno
<< entity >> Professor
<< entity >> Atendente
Figura 3.9: Diagrama de Classes de An alise Renado Inicialmente, os padr oes surgiram no contexto do projeto arquitet onico, na constru c ao civil [1]. Segundo Christopher Alexander, cada padr ao descreve um problema que ocorre recorrentemente em nosso ambiente e uma solu c ao para ele, de tal maneira que se pode usar essa solu c ao v arias vezes e de diversas maneiras [1]. No desenvolvimento de software, padr oes podem ser encontrados em diversas circunst ancias diferentes. Padr oes de projeto foram os primeiros a aparecer [19] e n ao demorou muito para que uma mir ade de outros, como padr oes arquiteturais [10], an alise [18] e de implementa c ao [29] surgissem. Atualmente, padr oes de variados tipos s ao empregados em projetos de desenvolvimento para tornar os sistemas constru dos mais f aceis de entender e manter, al em de facilitar a reutiliza c ao de suas partes. Em geral, um padr ao tem quatro elementos fundamentais: 1. Nome do padr ao: um identicador que podem ser utilizados para descrever um problema, sua solu c ao e suas conseq u encias em uma ou duas palavras. 2. Problema: uma descri c ao de quando aplicar o padr ao. Ele explica o problema que o padr ao
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica resolve, bem como seu contexto.
87
3. Solu c ao: uma descri c ao dos relacionamentos, responsabilidades e colabora c oes que comp oem o padr ao e explica como esses elementos s ao combinados, a m de resolver o problema. 4. Conseq u encias: os resultados de se utilizar o padr ao. Essas conseq u encias normalmente envolvem escolhas que inuenciam na decis ao de utilizar ou n ao o padr ao. Um exemplo de padr ao de an alise que discutimos neste cap tulo foi o padr ao Controlador [29], apresentado como parte do padr ao de an alise MVC (Se c ao 3.10.1). Este padr ao consiste em atribuir a uma classe a responsabilidade de tratar os eventos do sistema, sendo respons avel por implementar a l ogica do neg ocio. Esse padr ao de an alise e descrito resumidamente a seguir: Nome: Controlador Problema: denir qual classe implementa as regras do neg ocio e e respons avel por lidar com os eventos do sistema. Solu c ao: atribuir essa responsabilidade a uma classe cujo prop osito e justamente lidar com esses eventos e implementar as regras de neg ocios. Essa classe representa a intelig encia do sistema. Conseq u encias: (i) aumenta o potencial para reutiliza c ao, j a que separa o controle de outras caracter sticas do sistema, como a interface com o usu ario e a representa c ao dos dados; e (ii) melhorar a manutenibilidade do sistema, uma vez que a r apida localiza c ao do controle facilita evolu c ao das regras de neg ocio.
3.12
Resumo
O diagrama de classes de an alise e o principal artefato da fase de an alise orientada a objetos. O primeiro passo para a especica c ao desse diagrama e modelar a sua estrutura, atrav es da identica c ao das classes que comp oe o sistema, os atributos dessas classes e os relacionamentos entre elas. Este cap tulo apresentou uma maneira sistem atica de partir dos documentos de requisitos apresentados no Cap tulo 2, como por exemplo o modelo de casos de uso, e atrav es de diretrizes e renamentos sucessivos, construir o diagrama de classes de an alise. Por se preocupar prioritariamente com os aspectos estruturais do problema a ser resolvido, essa etapa da an alise orientada a objetos e conhecida como modelagem est atica do sistema. A partir do enunciado do problema e das descri c oes dos casos de uso, o processo apresentado neste cap tulo prop oe tr es maneiras complementares de identicar as entidades relevantes para representar o problema: (i) lista de categorias conceituais, que consiste na utiliza c ao de uma lista de categorias comuns a v arios sistemas, como checklist para ajudar na identica c ao de algumas entidades b asicas; (ii) an alise textual, atrav es da an alise dos documentos de requisitos, com o objetivo de identicar substantivos (poss veis classes ou atributos) e informa c oes de estado (poss veis atributos); e (iii) an alise de dom nio, que possibilita a identica c ao de entidades e atributos inerentes a um conjunto de sistemas de um mesmo dom nio.
88
Com as entidades identicadas, o pr oximo passo e identicar os relacionamentos entre elas. Conforme apresentado na Se c ao 1.3 do Cap tulo 1, os poss veis relacionamentos entre classes s ao: generaliza c ao/especializa c ao, agrega c ao/decomposi c ao, associa c oes e depend encias. Apesar de todos os relacionamentos serem importantes, do ponto de vista da an alise est atica, existem dois principais: generaliza c ao/especializa c ao e agrega c ao/decomposi c ao. A import ancia desses dois relacionamentos e relativa ao seu car ater conceitual, que um enfoque fortemente sem antico. Os demais relacionamentos podem ser identicados naturalmente na fase de modelagem din amica do diagrama de classes, que ser a apresentada no Cap tulo 5. Com a identica c ao do relacionamento entre as classes, est a constru do o diagrama inicial de classes de an alise, tamb em conhecido como modelo conceitual. Para nalizar a etapa de modelagem est atica do sistema, o modelo conceitual deve ser renado com padr oes de an alise. O processo apresentado neste cap tulo recomenda a utiliza c ao dos padr oes MVC (do ingl es Model-View-Controller) e Controlador. Juntos, esses padr oes possibilitam uma melhor separa c ao de interesse no modelo de an alise. Essa separa c ao e realizada atrav es de duas restri c oes importantes: (i) classica c ao das classes do modelo em tr es categorias (entidade, controle e fronteira); e (ii) deni c ao de regras de relacionamento entre as categorias. As classes de entidade, que recebem o estere otipo << entity >>, s ao os elementos do modelo conceitual que representam entidades da solu c ao, diferentemente de processos ou da l ogica do neg ocio. As classes com esse perl de controle das a c oes e l ogica do neg ocio s ao classicadas com o estere otipo << control >>. Finalmente, para explicitar os pontos de intera c ao entre o sistema e os seus atores relacionados (humanos ou outros sistemas), as classes que desempenham esse papel recebem o estere otipo << boundary >>. Segundo o padr ao de an alise MVC, um diagrama de classes deve possuir pelo menos uma classe de cada uma dessas categoria. Ap os essa classica c ao e feito um renamento dos relacionamentos entre as classes, de forma a atender as tr es restri c oes seguintes: (i) as classes de entidade s o possuem associa c ao simples com classes de controle e s o podem se relacionar com agrega c ao com outras classes de entidade; (ii) as classes de fronteira s o se comunicam com classes de controle, o que acontece atrav es de associa c oes simples; e (iii); as classes de controle podem possuir associa c oes simples para qualquer outra classe, inclusive outros controladores. Com o modelo est atido de an alise pronto, o analista est a pronto para iniciar a modelagem din amica, que ser a o foco de estudo do Cap tulo 5. Mas antes e importante compreender alguns conceitos mais avan cados do paradigma de objetos. Esses conceitos, apresentados nos Cap tulos 4 e 4, podem ser utilizados para renar o diagrama de classes no seu estado atual.
3.13
Exerc cios
1. Complemente o modelo do sistema da biblioteca exibido na Figura 3.9, de modo a contemplar todos os requisitos do sistema de gerenciamento de bibliotecas, descrito no Cap tulo 2. 2. A seguir, e apresentada a descri c ao de um sistema de controle de reservas e ocupa c oes, que
89
ser a utilizado pelo hotel Ast oria. Construa um modelo de objetos que melhor represente esse sistema. Identique as classes, as hierarquias, e poss veis atributos e opera c oes das suas classes. Descri c ao: O Hotel Ast oria tem 5 salas de palestras (numeradas de 1-5) e 40 quartos (numerados de 6-45). Os quartos de 6-15 s ao single e os quartos de 16-45 s ao double. Quando o cliente entra no hotel, eles s ao alocados para o primeiro quarto dispon vel do tipo requerido por ele. Al em disso, o cliente preenche uma cha com seus dados pessoais juntamente com o nome do pagador (isto e, quem efetivamente est a pagando pelo quarto). Se e o pr oprio cliente quem vai pagar pelo seu quarto, este campo e preenchido como privado; caso contr ario, o nome da companhia ou organiza c ao e anotado. As tarifas para um quarto single e de R$100,00, para um quarto double e de R$200,00 e para uma sala de palestras e de R$300,00. Existe apenas 1 conjunto de equipamentos de apresenta c ao, que inclui 1 canh ao, 1 laptop, e 1 microfone, no hotel que pode ser movido entre as salas de palestras. O sistema de controle de reservas dos c omodos do hotel permite que um cliente seja alocado para um quarto dispon vel e garante que o c omodo esteja dispon vel para futuras reservas assim que o cliente sai do hotel. Suponha que o sistema n ao lide com datas, de forma que as entradas/sa das dos clientes e as mudan cas do equipamento entre as salas sejam puramente eventos que ocorrem em tempo de execu c ao. O sistema e capaz de fornecer as seguintes informa c oes na tela: (i) quantos c omodos est ao sendo correntemente ocupados; (ii) os n umeros dos quartos correntemente ocupados e detalhes dos seus h ospedes; (iii) os n umeros das salas de palestras correntemente ocupadas; e (iv) qual a sala de palestra que cont em o equipamento. 3. O enunciado abaixo descreve um sistema de controle de tr afego a ereo simplicado. N os assumimos que o enunciado do problema foi obtido atrav es de uma an alise de dom nio envolvendo entrevistas com especialistas e usu arios nais. Leia cuidadosamente o enunciado e especique o caso de uso Pousar Avi ao. A partir dessa especica c ao, realize a an alise do caso de uso. O resultado dessa atividade deve ser um diagrama de classes de an alise contendo as classes, relacionamentos entre elas e atributos de cada uma. Enunciado do Problema: Aeronaves fazem v oos entre aeroportos, e um v oo e sempre entre 2 aeroportos, um origem e um destino. Cada v oo tem um n umero de v oo. Aeroportos variam o seu n umero de pistas, heliportos, terminais e hangares, mas devem ter pelo menos uma pista e tamb em uma torre de controle. Cada aeronave, aeroporto, pista e terminal devem ter um identicador u nico para permitir que o controle de tr afego a ereo gerencie. Alguns hangares s ao puramente para armazenamento de aeronaves, enquanto que outros s ao hangares de manuten c ao e tem facilidades adicionais, como por exemplo, a habilidade de servir as aeronaves. Um aeronave pode ser um helic optero ou um avi ao, e pode ter comportamentos diferentes, como por exemplo, a habilidade do helic optero decolar e aterissar em um
90
Cap tulo 3: An alise Orientada a objetos: Modelagem Est atica heliporto, sem precisar de uma pista. Entretanto, eles tamb em t em caracter sticas em comum, como por exemplo, necessidade de um piloto antes do v oo come car. V oos carregam pessoas e suas bagagens, e uma aeronave que carrega passageiros deve ter uma lista de passageiros detalhando todos os passageiros e os respectivos n umeros da passagem num arquivo indexado. Todos os v oos s ao registrados numa base central onde eles podem ser acessados pelos controladores (ou operadores) do tr afego a ereo nas torres de controle dos aeroportos. Aeronaves s ao rastreadas por radar e s ao dadas instru c oes de decolagem e aterissagem quando est ao dentro das areas controladas por aeroportos espec cos. Uma aeronave chegando pode ser colocado numa la caso uma pista ou um heliporto n ao esteja dispon vel. Aeroportos podem ser fechados devido ao mau tempo; nesse caso as aeronaves que chegam s ao desviados para outros aeroportos. 4. Um propriet ario de restaurante acredita que a automa ca o poder a fazer com que seu neg ocio se torne mais eciente, atraindo mais clientes. Ele deseja automatizar a maior quantidade poss vel de opera c oes. Devem ser mantidos manuais dos processos de preparar os pratos e todos os pedidos devem ser anotados. Construa o diagrama de classes de an alise, sabendo que atrav es de entrevista e question arios, foram identicadas as seguintes informa c oes: Entidades envolvidas: Propriet ario do restaurante; Cliente (gar cons/ operador de caixa); Fornecedor. Objetivos do sistema: Processar os pedidos e emitir notas; Automatizar contabilidade (pagamento de fornecedores, relat orios cont abeis); Fazer pedido de compras aos fornecedores da maneira mais eciente, de forma que os produtos n ao faltem e que tamb em n ao encalhem no estoque. O propriet ario deseja que o sistema controle o estoque, para facilitar a verica c ao do balan co entre os valores real e esperado. O cliente tamb em deseja ter algumas estat sticas sobre vendas de diferentes itens. Id eias preliminares: Manter informa c oes sobre fornecedores, contabilidade, pedidos e menu; O controle de estoque deve usar as informa c oes sobre o total da compra e sobre as vendas realizadas, baseado na quantidade estimada dos produtos em cada prato, que e obtida a partir de informa c oes do menu.
Cap tulo 4
Modelagem Estrutural em UML

4.1 Objetos e Classes
Conforme apresentado no primeiro cap tulo deste livro (Se c ao 1.3.1), um objeto e uma entidade utilizada para representar elementos relevantes para modelar um problema. Cada objeto possui um estado, denido atrav es de um conjunto de atributos, e um comportamento, denido atrav es de um conjunto de opera c oes. Essas opera c oes s ao implementadas atrav es de m etodos e o conjunto de opera c oes e atributos p ublicos constituem a interface p ublica de um objeto. A comunica c ao entre dois objetos de um sistema acontece atrav es do envio de mensagens. Como um objeto n ao deve possuir atributos p ublicos, o envio de uma mensagem por um objeto deve implicar na execu c ao de uma opera c ao da interface p ublica do objeto recipiente. Esse envio de mensagem consiste na u nica maneira de comunica c ao ente os objetos do sistema. Como visto na Se c ao 1.3.2 do Cap tulo 1, uma classe e a descri c ao de um molde que especica as propriedades e o comportamento relativo a um conjunto de objetos similares. No modelo de objetos, atributos e opera c oes s ao usualmente parte da deni c ao de uma classe.
4.1.1
Classes Concretas
Como visto no Cap tulo 1 deste livro (Se c ao 1.3.4), as unidades b asicas de desenvolvimento do modelo de objetos s ao classes e objetos. A Figura 4.1 mostra a representa c ao em UML para a classe Publicacao, que representa uma publica c ao de uma biblioteca. Como pode ser visto, o estado de uma publica c ao e denido atrav es de dois atributos: numeroTombo e nome. O comportamento, por sua vez, e denido atrav es de quatro opera c oes: Publicacao(), respons avel por criar objetos da classe, o que e conhecido por 91
92
Publicacao numeroTombo :String nome :String
Cap tulo 4: Fundamentos de An alise OO
<< create >> + Publicacao ():Publicacao + criarPublicacao (numTomb :String ,nome :String ):void + reservar ():void + imprimir ():void
Figura 4.1: Classe que representa as publica c oes de uma biblioteca instancia c ao da classe, al em das opera c oes criarPublicacao(numTomb:String, nome:String), que inicializa os valores do estado do objeto criado, reservar() e imprimir().
4.1.2
Instancia c ao de Objetos em UML
Como apresentado na Se c ao 1.3.3 do Cap tulo 1, e poss vel criar um n umero qualquer de objetos relacionados a uma classe. Para isso, o modelo de objetos dene o relacionamento de classica c ao/instancia c ao. A Figura 4.2 mostra a representa c ao em UML para classica c ao/instancia c ao. Como pode ser percebido, um objeto e inst ancia de apenas uma classe, enquanto uma classe pode ter v arias inst ancias associadas a ela. Neste exemplo, os objetos p1 e p2 s ao inst ancias da classe Publicacao. O fato dos objetos dependerem da sua classe e representada atrav es de depend encias UML (setas pontilhadas). O relacionamento de depend encia foi apresentado na Se c ao 1.3.8 do Cap tulo 1.
Publicacao numeroTombo :String nome :String << create >> + Publicacao ():Publicacao + criarPublicacao (numTomb :String ,nome :String ):void + reservar ():void + imprimir ():void << instance_of >> . p1:Publicacao numeroTombo = "G145C" :String nome = "UML User Guide" :String + criarPublicacao (numTomb :String ,nome :String ):void + reservar ():void + imprimir ():void << instance_of >> . p2:Publicacao numeroTombo = "R145Z" :String nome = "Applying Use Cases" :String + criarPublicacao (numTomb :String ,nome :String ):void + reservar ():void + imprimir ():void
Figura 4.2: Instancia c ao de dois objetos da classe Publicacao Nas linguagens de programa c ao modernas, os objetos podem ser alocados dinamicamente, isto e, os endere cos de mem oria s ao referenciados em tempo de execu c ao. Em Java, por exemplo, a cria c ao de um objeto e sinalizada atrav es da palavra reservada new. Apesar do ganho de exibilidade e expressividade oferecido pela aloca c ao din amica, ela obriga que o programador se preocupe explicitamente com a aloca c ao e desaloca c ao dos recursos da
93
mem oria. Exce c oes ` a obrigatoriedade de desaloca c ao expl cita s ao as linguagens que implementam mecanismos de coleta autom atica de lixo (do ingl es garbage collection), como por exemplo a linguagem Java. O exemplo a seguir mostra a aloca c ao din amica de um objeto em Java:
1 2 3 4 5 6
... Publicacao p1 ;
p1 = new P u b l i c a c a o ( ) ; p1 . c r i a r P u b l i c a c a o ( G145C , UML User Guide ) ; p1 . i m p r i m i r ( ) ; ...
No trecho de c odigo anterior, p1 e um apontador para um objeto do tipo Publicacao (Linha 2). Inicialmente, ele aponta para null (endere co nulo). Na Linha 3 e criado um novo objeto do tipo Publicacao e p1 passa a apontar para ele atrav es da opera c ao de atribui c ao (=). A mensagem criarPublicacao() e enviada para p1 (Linha 4) a m de atribuir valores iniciais aos atributos numeroTombo e nome. Como p ode ser percebido no exemplo em Java, a sintaxe para a invoca c ao de uma opera c ao e uma combina c ao de acesso a uma estrutura de dados (o objeto) e a invoca c ao de um procedimento. A raz ao disso e que uma opera c ao est a associada a uma inst ancia de classe espec ca e tem que existir uma maneira de dizer para a opera c ao em qual inst ancia ela deve operar. Isto e feito como segue: < nomeObjeto > . < nomeOperacao > (argumentos) Para xar melhor o conceito, a Figura 4.3 apresenta a rela ca o entre a cria c ao da vari avel (o apontador p1 do exemplo de Java) e a instancia c ao do objeto.
Varivel Tipo de Varivel referncia para um objeto do tipo Documento Tipo de Objeto
d1
objeto do tipo Documento
Figura 4.3: Cria c ao de um Objeto Cada objeto criado cont em seus pr oprios valores dos atributos numeroTombo e nome, declarados na classe Publicacao. Objetos s ao manipulados atrav es do envio de mensagens que acionam opera c oes realizadas sobre o objeto alvo. Na Linha 5 do trecho de c odigo Java, a mensagem imprimir() e enviada para o objeto referenciado por p1. Na maioria das linguagens orientadas a objetos, existe uma distin c ao clara entre as vari aveis e os objetos referenciados por elas. Essas linguagens adotam a aloca c ao din amica, onde vari aveis s ao
94
apenas nomes que cont em refer encias (endere cos) para objetos.
4.1.3
Opera c oes Construtoras
Um construtor e uma opera c ao especial, ativada automaticamente no momento da cria c ao de um objeto da classe. Como apresentado na Figura 4.4, uma opera c ao construtora possui nome id entico ao da sua classe e n ao pode retornar nenhum resultado (nem mesmo void), embora possa receber valores atrav es de um ou mais par ametros. Quando n ao recebe nenhum par ametro, dizemos que a opera c ao representa um construtor padr ao (primeira opera c ao da Figura 4.4). Caso contr ario, trata-se de um construtor n ao-padr ao (segunda opera c ao da Figura 4.4).
Publicacao numeroTombo :String nome :String Construtor padro << create >> + Publicacao ():Publicacao << create >> + Publicacao (numTomb :String ,nome :String ):Publicacao + criarPublicacao (numTomb :String ,nome :String ):void + reservar ():void + imprimir ():void
Construtor nopadro
Figura 4.4: Classe Publicacao com duas Opera c oes Construtoras Na Linha 4 da listagem mostrada a seguir, e apresentado o m etodo construtor padr ao (implementa c ao da opera c ao) da classe Publicacao. A implementa c ao do construtor n ao padr ao e apresentada nas Linhas 5 a 8. Ao implementar as opera c oes de uma classe, pode ser necess ario enviar mensagens ao objeto que est a sendo executado. Para isso, as linguagens de programa c ao possuem vari aveis especiais, denidas implicitamente e vis veis em todos os m etodos da classe. Em Java, essa vari avel e denominada this (Linha 7). Os m etodos construtores s ao utilizados normalmente para atribuir valores iniciais aos atributos. Na maioria das linguagens orientadas a objetos, inclusive em Java, se o programador n ao especicar nenhum m etodo construtor, a linguagem fornece um construtor padr ao para a classe. Esse m etodo padr ao n ao possui nenhum par ametro e atribui valores iniciais padr oes aos atributos, de acordo com as suas deni c oes de tipos.
1 2 3 4 5 6 7 8 9
public c l a s s P u b l i c a c a o { private S t r i n g numeroTombo ; private S t r i n g nome ; public P u b l i c a c a o ( ) { } public Documento ( S t r i n g numTomb, S t r i n g nome ) { numeroTombo= numTomb ; t h i s . nome = nome ; } public void r e s e r v a r ( ) {

10 11 12 13 14 15
95
System . p r i n t l n ( Reserva a P u b l i c a c a o ) ; } public void i m p r i m i r ( ) { System . out . p r i n t l n ( Imprime o conte u do da P u b l i c a c a o ) ; } }
Agora que Publicacao tem um construtor que recebe par ametros, o m etodo criarPublicacao() tornou-se desnecess ario. Assim, a cria c ao de uma publicacao passa a exigir apenas os dois passos a seguir:
1 2
P u b l i c a c a o p1 ; p1 = new P u b l i c a c a o ( G145C , UML User Guide ) ;
4.1.4
Visilibilidade de Atributo e Opera c ao
O modelo de objetos apresenta estrat egias variadas para acesso e visibilidade de atributos e opera c oes. Atributos e opera c oes denidas como p ublicas (+) possuem acesso e irrestrito, isto e, podem ser acessadas por qualquer objeto do sistema. No caso dos atributos e opera c oes com visibilidade privada (-), eles s o s ao vis veis pelo pr oprio objeto. Em outras palavras, esses atributos e opera c oes s o s ao vis veis na constru c ao dos m etodos da classe. Apesar do modelo permitir a deni c ao de atributos p ublicos, uma recomenda c ao para garantir o encapsulamento dos dados do objeto e a atribui c ao da visibilidade privada para todos os atributos da classe. Dessa forma, a interface p ublica do objeto deve ser constitu da apenas de opera c oes.
4.2
4.2.1
Tipo Abstrato de Dados

Tipos e Classes
Como apresentado na Se c ao 1.2.3 do Cap tulo 1, o conceito de tipo pode ser visto como uma especica c ao de um conjunto de valores que podem ser atribu dos a uma vari avel, juntamente com as opera c oes que podem ser usadas legalmente para criar, acessar e modicar tais valores. Por exemplo, o tipo boolean e associado aos valores true e false e ` as opera c oes AND, OR e NOT. No contexto de orienta c ao a objetos, a deni c ao de tipo deve ser apresentada em termos de objetos. Sendo assim, um tipo pode ser denido como as caracter sticas comuns de uma cole c ao de objetos do sistema que respondem ao mesmo conjunto de mensagens. Ou seja, o tipo e o conceito
96
que agrupa uma cole c ao de objetos com a mesma interface p ublica [4]. Portanto, essa deni c ao se alinha com o conceito de classes no modelo de objetos. Entretanto, os conceitos de tipo e classe s ao distintos [7]. Um tipo e essencialmente a descri c ao de uma interface, que especica o comportamento comum a um grupo de objetos. Enquanto isso, uma classe especica uma implementa c ao particular de um tipo. A deni c ao de uma classe, al em de conter a implementa c ao das opera c oes dos objetos, inclui uma descri c ao dos estados internos desses m etodos. Portanto, apesar de uma classe apresentar implicitamente o conceito de tipo atrav es dos seus m etodos p ublicos, o papel da classe e implementar o(s) tipo(s) associado(s) a ela. Embora tipo e classe n ao sejam a mesma coisa, muitos autores usam esses termos como sin onimos; outros acham que a diferen ca entre os dois e primordial. Algumas linguagens orientadas a objetos, como por exemplo Arche, POOL, Guide e Java, separam a deni c ao de tipo e sua implementa c ao. C++, Eiel, e Modula-3 [22] n ao oferecem essa separa c ao. A linguagem de modelagem UML tamb em separa explicitamente tipos e classes, atrav es do conceito de interface (interface em Java), que ser a discutido em detalhes na Se c ao 4.7.
4.2.2
As Se c oes 1.3.1 e 1.3.2 do Cap tulo 1 e a Se c ao 4.1 deste cap tulo enfatizaram a importante distin c ao entre tipos e classes, que e uma conseq u encia da separa c ao de interesse (do ingl es separation of concerns) entre a especica c ao do comportamento e a sua implementa c ao. O conceito de tipo abstrato de dados (TAD) utilizado neste livro (Se c ao 1.3.4 do Cap tulo 1) considera que todos os atributos possuem visibilidade privada e por n ao serem vis veis externamente, n ao fazem parte da deni c ao do tipo. Dessa forma, um tipo abstrato de dados consiste de um conjunto de opera c oes, que devem ser implementadas por todos os elementos que perten cam a esse tipo. Estruturalmente, um tipo abstrato de dados e constitu do de duas partes (Figura 4.5): (i) especica c ao, isto e, a interface; e (ii) implementa c ao. Cada parte, por sua vez, e subdividida. A especica c ao e denotada pela sua sintaxe (ou assinatura) juntamente com a sua sem antica, enquanto que a implementa c ao e denotada pela representa c ao (ou estruturas de dados) e os seus algoritmos associados. Em UML, a especica c ao de um TAD e materializada atrav es de interfaces, enquanto que a implementa c ao e materializada atrav es de classes.
Especificao
Implementao
Sintaxe (assinatura)
Semntica
Representao (estrutura de dados)
Algoritmos
Figura 4.5: Estrutura de um Tipo Abstrato de Dados
97
O principal benef cio decorrente da separa c ao expl cita entre a especica c ao de um tipo e a sua implementa c ao e a garantia de abstra c ao por parte do cliente. Sendo assim, o cliente pode fazer uso do TAD, mesmo desconhecendo os aspectos t ecnicos envolvidos na sua implementa c ao. Outra conseq u encia dessa separa c ao e o baixo acoplamento existente entre esses conceitos, o que possibilita que um TAD tenha mais de uma implementa c ao associada a ele. Considere a classe Pilha, apresentada na Figura 4.6 e a especica c ao informal das suas opera c oes, apresentada na Tabela 4.1.
Pilha elementos :int[] << create >> + Pilha():Pilha + empilhar (e:int ):void + desempilhar ():int + estaVazia ():boolean + estaCheia ():boolean + devolverTopo ():int
Figura 4.6: Classe Pilha, que dene um TAD Tabela 4.1: Especica c ao Informal do TAD Pilha. Linguagem Pilha() o Descric a O construtor n ao recebe par ametros de entrada, n ao devolve nenhum resultado e cria uma pilha vazia. empilhar(int e) Recebe um elemento inteiro para ser empilhado e n ao retorna nenhum resultado. int desempilhar() N ao recebe par ametros de entrada; desempilha o elemento do topo da pilha, do tipo int e o retorna. estaVazia() N ao recebe par ametros de entrada e devolve true se a pilha estiver vazia e false, caso contr ario. estaCheia() N ao recebe par ametros de entrada e devolve true se a pilha estiver cheia e false, caso contr ario. int devolverTopo() N ao recebe par ametros de entrada; inspeciona o topo da pilha e devolve uma c opia do elemento como resultado de retorno, que e do tipo int.
Um tipo abstrato de dados e normalmente denido atrav es de uma interface, que no contexto
98
do modelo de objetos, representa as opera c oes p ublicas de uma classe. Entretanto, apenas a especica c ao sint atica n ao e suciente para descrever o comportamento de um tipo abstrato de dados. Tamb em e necess ario algum suporte para especicar a sua sem antica. Uma das t ecnicas mais bem sucedidas para se especicar a sem antica de um tipo abstrato de dados e a especica c ao alg ebrica. Esta t ecnica requer que o projetista dena um conjunto de equa c oes l ogicas que expressem a sem antica desempenhada pelas opera c oes do tipo abstrato de dados. A especica c ao sint atica do TAD Pilha e apresentada a seguir, em forma de classe Java:
1 2 3 4 5 6 7 8 9
class Pilha { // . . . a t r i b u t o s public P i l h a ( ) { . . . } public void e m p i l h a r ( i n t e ) { . . . } public i n t d e s e m p i l h a r ( ) { . . . } public boolean e s t a V a z i a ( ) { . . . } public boolean e s t a C h e i a ( ) { . . . } public i n t devolverTopo ( ) { . . . } } // fim da c l a s s e P i l h a
Uma poss vel especica c ao sem antica para o TAD Pilha usando a t ecnica de especica c ao alg ebrica e apresentada a seguir. Nessa especica c ao, assumimos que p e uma inst ancia de Pilha e e e um elemento que pode ser empilhado. Al em disso, e utilizada uma sintaxe semelhante ao OCL (do ingl es Object Constraint Language), a linguagem formal da UML. Por exemplo, p@pre indica o estado inicial da pilha p, antes de executar qualquer opera c ao representada: (1) - [Pilha()].estaVazia() e verdadeiro. (2) - [p.empilhar(e)].estaVazia() e falso. (3) - [p.empilhar(e)].desempilhar() == e AND [[p.empilhar(e)].desempilhar()] [p == p@pre]] (4) - [p.empilhar(p.desempilhar())] [p == p@pre] (5) - [p.devolverTopo()] [p == p@pre] Outra t ecnica que auxilia o programador a especicar o comportamento de tipos abstratos de dados e baseada na deni c ao de express oes que constituem as pr e e p os-condi c oes das opera c oes, da mesma forma como apresentado no Cap tulo 2 em rela c ao aos casos de uso. Predicados (ou express oes booleanas) podem ser associadas a opera c oes para descrever o estado desej avel do objeto. etodo ser Uma pr e-condi c ao para uma opera c ao descreve o estado do objeto desejado antes do m executado. Se a pr e-condi c ao e verdadeira, o m etodo pode ser executado. Se for falsa, o m etodo n ao pode ser executado. Uma p os-condi c ao, por sua vez, descreve o estado do objeto ap os a execu c ao do m etodo. Por exemplo, um programador pode associar pr e e p os-condi c oes ` as opera c oes empilhar() e desempilhar() para garantir a consist encia da pilha, de acordo com a sem antica esperada para
99
cada opera c ao. Uma pr e-condi c ao para empilhar() e que a pilha n ao pode estar cheia, enquanto que uma pr e-condi c ao para desempilhar() e que a pilha n ao pode estar vazia. Similarmente, uma p os-condi c ao para empilhar() e que a pilha n ao seja mais vazia e, para desempilhar(), que o n umero total de elementos seja decrescido de 1. A especica c ao das opera c oes do TAD Pilha, usando pr e e p os-condi c oes, e apresentada na Tabela 4.2. Tabela 4.2: Especica c ao do TAD Pilha Utilizando Pr e e P os-condi c oes o Operac a empilhar() desempilhar() estaVazia() -condic o Pre a !estaCheia() !estaVazia() TRUE* s-condic o Po a !estaVazia() !estaCheia() Nenhuma mudan ca no estado da pilha estaCheia() TRUE Nenhuma mudan ca no estado da pilha devolverTopo() !estaVazia() Nenhuma mudan ca no estado da pilha construtorPilha() TRUE estaVazia()
*TRUE signica que a opera c ao pode ser chamada incondicionalmente.
Apesar de ser um conceito u til do ponto de vista da modelagem, poucas linguagens de programa c ao d ao apoio ` a especica c ao sem antica do comportamento. O exemplo mais conhecido de uma linguagem de programa c ao que ap oia essa especica c ao e a linguagem Eiel, que permite a especica c ao de pr e e p os-condi c oes associadas aos m etodos das classes. Bar-David[4] descreve o comportamento de tipos abstratos de dados atrav es de um conjunto de equa c oes que relacionam a interface p ublica do tipo no contexto de C++. A m de oferecer suporte ` a especica c ao dessas assertivas, a partir da sua vers ao 1.4, a linguagem Java incorporou a palavra reservada assertion. Uma assertion e utilizada para associar express oes l ogicas que devem ser satisfeitas. Sendo assim, de acordo com o local da sua inser c ao, a assertiva pode signicar tanto uma pr e-condi c ao (in cio do m etodo), quanto uma p os-condi c ao (nal do m etodo).
4.3
Relacionamento de Agrega c ao e Associa c ao
Agrega c ao e um relacionamento estrutural entre o todo e suas partes [9]. Como visto na Se c ao 1.3.6, as hierarquias de agrega c ao/decomposi c ao devem ser empregadas para modelar relacionamentos do tipo parte/todo. Sendo assim, agrega c oes s ao utilizadas para modelar entidades a partir das suas partes, o que permite a reutiliza c ao de comportamento entre elas. A Figura 4.7 apresenta uma hierarquia de agrega c ao na qual inst ancias da classe Biblioteca
100
s ao compostas por inst ancias das classes Usuario e Publicacao.

Biblioteca identificador :String endereco :String << create >> + Biblioteca ():Biblioteca + listarPublicacoes ():void + listarUsuarios ():void * Usuario nome :String codigo :String + verificarCodigo (cod :String ):boolean + imprimir ():void numeroTombo :String nome :String << create >> + Publicacao ():Publicacao << create >> + Publicacao (numTomb :String ,nome :String ):Publicacao + reservar ():void + imprimir ():void * Publicacao
Figura 4.7: Hierarquia de Agrega c ao de uma Biblioteca Para implementar numa linguagem de programa c ao orientada a objetos a hierarquia da Figura 4.7, uma classe estruturalmente descrevendo uma biblioteca e denida com atributos referenciando seus v arios componentes. Esses atributos s ao iniciados com as inst ancias correspondentes das classes Usuario e Publicacao. Esta abordagem tamb em permite liga c oes com v arias inst ancias de uma classe para descrever um objeto agregado. Por exemplo, pode ser necess ario referenciar mais de uma inst ancia de Publicacao para denir o acervo da Biblioteca. O princ pio de heran ca geralmente n ao permite que uma informa c ao seja herdada mais do que uma vez a partir de uma mesma classe, ao contr ario da agrega c ao. O seguinte trecho de c odigo apresenta uma implementa c ao parcial para a classe Biblioteca.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
public c l a s s B i b l i o t e c a { // A t r i b u t o s private S t r i n g i d e n t i f i c a d o r ; private S t r i n g e n d e r e c o ;
// A g r e g a c oes public P u b l i c a c a o [ ] p u b l i c a c a o ; public U s u a r i o [ ] u s u a r i o ;
// Metodos public B i b l i o t e c a ( ) { . . . } // C o n s t r u t o r padr ao public void l i s t a r P u b l i c a c o e s ( ) { f o r ( i n t i = 0 ; i < p u b l i c a c a o . l e n g t h ; i ++) publicacao [ i ] . imprimir ( ) ; } public void l i s t a r U s u a r i o s ( ) {

17 18 19 20
101
f o r ( i n t i = 0 ; i < u s u a r i o . l e n g t h ; i ++) usuario [ i ] . imprimir ( ) ; } }
Como pode ser percebido na implementa c ao das opera c oes listarPublicacoes() e listarUsuarios() da classe Biblioteca, o objeto agregador pode propagar mensagens para os seus agregados (Linhas 14 e 18). Para apresentar uma vis ao mais clara da estrutura dos objetos instanciados, a Figura 4.8 apresenta um diagrama de colabora c ao (Se c oes 2.9.11 do Cap tulo 2) entre objetos dos tipos Biblioteca e Publicacao. Ap os o recebimento da mensagem listarPublicacoes() pelo objeto bc, ele imediatamente propaga a mensagem imprimir() para os objetos dp e cj.
(1) listarPublicacoes() (2) imprimir()
dp:Publicacao numeroTombo = "M14T" :String nome = "Design Patterns" :String + reservar ():void + imprimir ():void (3) imprimir() cj:Publicacao numeroTombo = "S14G" :String nome = "Core Java" :String + reservar ():void + imprimir ():void
bc:Biblioteca identificador = "BC" :String endereco = "Rua Jacarand" :String << create >> + Biblioteca ():bc:Biblioteca + listarPublicacoes ():void + listarUsuarios ():void
Figura 4.8: Diagrama de Colabora c ao com Propaga c ao de Mensagem
4.4
4.4.1
Relacionamento de Generaliza c ao
Heran ca Simples de Classes
Heran ca (do ingl es inheritance ou subclassing) e um mecanismo para derivar novas classes a partir de classes existentes atrav es de um processo de renamento. Uma classe derivada herda a representa c ao de dados e opera c oes de sua classe base, mas pode seletivamente adicionar novas opera c oes, estender a representa c ao de dados ou redenir a implementa c ao de opera c oes j a existentes. Uma classe base proporciona a funcionalidade que e comum a todas as suas classes derivadas, enquanto uma classe derivada proporciona a funcionalidade adicional que especializa o seu comportamento. Para uma classe derivada acessar as opera c oes e atributos vis veis da classe base, ela pode se utilizar da
102
vari avel impl cita super. De forma an aloga ao this apresentado na Se c ao 4.1.3, o super e uma vari avel impl cita que ca vis vel na implementa c ao de todos os m etodos da classe. c oes A hierarquia da Figura 4.9 especica tr es tipos diferentes: (i) Publicacao, com as opera reservar() e imprimir(); (ii) Livro, com as opera c oes reservar(), imprimir() e bloquear(); e (iii) Periodico, com as opera c oes reservar(), imprimir() e indexar(). Al em das classes que denem os tipos, foram instanciados dois objetos: l1, do tipo Livro e p1, do tipo Peri odico.
Publicacao numeroTombo :String nome :String editora :String << create >> + Publicacao ():Publicacao << create >> + Publicacao (numTomb :String ,nome :String ,editora :String ):Publicacao + reservar ():void + imprimir ():void
Livro edicao :int << create >> + Livro (numTomb :String ,nome :String ,editora :String ,edicao :int ):Livro + bloquear ():void Interface pblica da classe "Livro" << instance_of >> . l1:Livro numeroTombo = "M16P" :String nome = "Dominando Java" :String editora = "Impresso" :String edicao = 1 :int + reservar ():void + imprimir ():void + bloquear ():void Interface pblica do objeto "l1" (do tipo Livro) periodicidade :int
Periodico
<< create >> + Periodico (numTomb :String ,nome :String ,editora :String ,per :int ):Periodico + indexar ():void << instance_of >> . p1:Periodico numeroTombo = "M16P" :String nome = "Dominando Java" :String editora = "Impresso" :String periodicidade = 30 :int + reservar ():void + imprimir ():void + indexar ():void Interface pblica do objeto "p1" (do tipo Periodico)
Figura 4.9: Exemplo de Heran ca de Classes O estado do objeto l1 cont em quatro atributos: numeroTombo, nome, editora e edicao. Os atributos numeroTombo, nome e editora devem ser alterados apenas por opera c oes da classe Publicacao, uma vez que s ao denidos nessa classe e possuem visibilidade privada. Por uma raz ao an aloga, o atributo edicao s o pode ser alterado por opera c oes da classe Livro. As opera c oes da classe Livro n ao enxergam os atributos e opera c oes privadas da classe base e, portanto, ela n ao pode alter a-los. Para isso, e necess ario utilizar as opera c oes vis veis da classe Publica c ao, atrav es da vari avel super. A interface p ublica do tipo Livro e estabelecida pelas opera c oes v alidas para objetos desse tipo, isto e, tanto a opera c ao bloquear(), denida pela classe Livro, quanto as opera c oes reservar() e imprimir(), denidas na classe Publicacao. As opera c oes construtoras s ao uma exce c ao ` a regra de heran ca, pois n ao s ao herdadas pelas classes derivadas. O construtor de uma classe tem que obrigatoriamente chamar um construtor de sua classe base. Em Java, a palavra reservada super signica minha super classe e o m etodo super(x) signica o m etodo construtor da minha superclasse, onde x s ao os par ametros passados para o construtor. Esses par ametros s ao usados normalmente para inicializar os atributos da superclasse. A terminologia usada para heran ca engloba v arios termos que s ao usados como sin onimos: Classe derivada ou subclasse ou classe lha: e uma classe que herda parte dos
Cap tulo 4: Fundamentos de An alise OO seus atributos e m etodos de outra classe. Classe base ou superclasse ou classe pai: e uma classe a partir da qual classes novas podem ser derivadas. Classes ancestrais s ao todas as classes das quais se herdam atributos e m etodos, independentemente da posi c ao que elas ocupam na hierarquia de classes. As superclasses s ao exemplos de classes ancestrais. Classes descendentes s ao todas as classes que herdam o comportamento de uma classe espec ca, independentemente da posi c ao que elas ocupam na hierarquia de classes. As subclasses s ao exemplos de classes descendentes.
103
4.4.2
Visibilidade Protegida de Atributos e Opera c oes
A Figura 4.10 mostra uma hierarquia de classes de usu arios de uma biblioteca. Na raiz dessa hierarquia est a uma classe base gen erica chamada Usuario, a partir da qual as classes Aluno e Professor herdam os atributos nome, codigo e status, al em das opera c oes verificarCodigo(), imprimir() e mudarStatus().
Usuario nome :String codigo :String #status :int << create >> + Usuario (nome :String ,codigo :String ,status :String ):Usuario + verificarCodigo (cod :String ):boolean + imprimir ():void #mudarStatus (status :int ):void
Aluno anoEscolar :int << create >> + Aluno (nome :String ,codigo :String ,status :String ,anoEsc:int ):Aluno + aplicarMulta ():void tempoServico :int
Professor
<< create >> + Professor (nome :String ,codigo :String ,status :String ,tempo :int ):Professor + aposentar ():void
Figura 4.10: Hierarquia de Classes de Usu arios O c odigo parcial da implementa c ao dessa hierarquia em Java pode ser o seguinte:
1 2 3 4 5 6 7 8 9 10
public c l a s s U s u a r i o { // A t r i b u t o s private S t r i n g nome ; private S t r i n g c o d i g o ; protected i n t s t a t u s ; // 1 : i n a t i v o ; 2 : s u s p e n s o ; 3 : normal .
// Opera c o es public U s u a r i o ( S t r i n g nome , S t r i n g c o d i g o , S t r i n g s t a t u s ) { . . . }
public boolean v e r i f i c a r C o d i g o ( S t r i n g cod ) { . . . } public void i m p r i m i r ( ) { . . . }
104
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

public mudarStatus ( i n t s t a t u s ) { this . s t a t u s = s t a t u s ; }
c l a s s Aluno extends U s u a r i o { private i n t a n o E s c o l a r ; public Aluno ( S t r i n g nome , S t r i n g c o d i g o , S t r i n g s t a t u s , i n t anoEsc ) { super ( nome , c o d i g o , s t a t u s ) ; a n o E s c o l a r = anoEsc ; } public double a p l i c a r M u l t a ( ) { // s e e s t i v e r em a t r a s o , s u s p e n d e
double multa = v a l o r M u l t a d i a s A t r a s o ; i f ( multa > 0 ) s t a t u s = 2 ; // a l t e r a n d o um a t r i b u t o da s u p e r c l a s s e return multa ; } }
c l a s s Aluno extends P r o f e s s o r { private i n t t e m p o S e r v i c o ; public Aluno ( S t r i n g nome , S t r i n g c o d i g o , S t r i n g s t a t u s , i n t tempo ) { super ( nome , c o d i g o , s t a t u s ) ; t e m p o S e r v i c o = tempo ; } public void a p o s e n t a r ( ) { // s e e s t i v e r em a t r a s o , s u s p e n d e
i f ( t e m p o S e r v i c o >= 3 0 ) s t a t u s = 1 ; // a l t e r a n d o um a t r i b u t o da s u p e r c l a s s e } }
As classes Aluno e Professor est ao alterando um atributo denido pela classe base. Isso somente e poss vel porque a visibilidade do atributo saldo e estabelecida como protegida (# em UML, ou protected em Java) na classe Usuario. Se a visibilidade do atributo status fosse alterada para privada (private), ao inv es de protegida, a implementa c ao da opera c ao aplicarMulta() da classe Aluno deveria ser modicada, de modo a evitar o acesso direto ao atributo. Uma possibilidade dessa nova vers ao da opera c ao aplicarMulta() e apresentada a seguir:
1
public double a p l i c a r M u l t a ( )
{ // s e e s t i v e r em a t r a s o , s u s p e n d e

2 3 4 5 6
105
double multa = v a l o r M u l t a d i a s A t r a s o ; i f ( multa > 0 ) t h i s . mudarStatus ( 2 ) ; // e x e c u t a n d o um m e todo da s u p e r c l a s s e return multa ; }
A altera c ao se faz necess aria porque com a visibilidade privada, a classe Aluno passa a n ao enxergar o atributo status diretamente. Seu acesso deve ent ao ser realizado por meio da interface p ublica da classe Usuario, neste caso, atrav es da opera c ao mudarStatus().
4.4.3
Clientes por Heran ca e por Instancia c ao
Como visto na Se c ao 1.2.2 do Cap tulo 1, o encapsulamento e uma t ecnica utilizada para minimizar as interdepend encias entre os m odulos do sistemas. Uma das formas mais utilizadas para melhorar o encapsulamento dos m odulos e restringir a comunica c ao entre eles atrav es de interfaces externas bem denidas Essa interface pode ser vista como uma esp ecie de contrato entre o m odulo e os seus clientes; dessa forma, o encapsulamento garante aos projetistas que mudan cas podem ser feitas de modo seguro, facilitando a manuten c ao e a evolu c ao do software. Esses benef cios s ao especialmente importantes para sistemas de software complexos, grandes e de vida longa. Do ponto de vista da orienta c ao a objetos, a interface externa de um m odulo nada mais e do que o conjunto de opera c oes p ublicas de todas as classes p ublicas do m odulo; por essa raz ao, at e mesmo uma classe OO isolada pode ser vista como um m odulo de granularidade pequena. Em Orienta c ao a Objetos, a deni c ao de uma classe pode ser vista como esp ecie de m odulo cuja interface externa consiste de um conjunto de opera c oes; mudan cas na implementa c ao da classe que preservam sua interface externa n ao afetam o c odigo do resto do sistema. O comportamento de uma classe pode ser acessado de duas maneiras: atrav es do relacionamento de generaliza c ao/especializa c ao, onde a subclasse herda o comportamento da superclasse, ou atrav es da instancia c ao da classe e execu c ao dos seus m etodos. Em rela c ao ` a instancia c ao, uma classe pode oferecer interfaces distintas, dependendo do cliente que a instanciou. A diferen ca das interfaces p ublicas apresentadas a cada uma dessas duas categorias de clientes e denida atrav es do controle de visibilidade. Para recapitular, as duas categorias b asicas de clientes que podem acessar uma classe s ao: etodos e a estrutura da Clientes por heran ca s ao as subclasses que herdam os m classe. Clientes por instancia c ao s ao as classes que criam inst ancias da classe e acessam o seu comportamento atrav es do envio de mensagens para essas inst ancias.
106
4.4.4
Heran ca de Implementa c ao
Apesar do relacionamento de generaliza c ao/especializa c ao possuir uma sem antica de subtipo, algumas linguagens de programa c ao orientadas a objetos utilizam artif cios para diversicar as formas de heran ca. Por essa raz ao, dependendo da maneira como o mecanismo de heran ca e usado, ele pode ser classicados de duas maneiras diferentes(ii) heran ca de implementa c ao. A seguir, cada uma dessas formas de utiliza c ao do mecanismo de hera ca e discutida em maiores detalhes. Mas h a casos em que o programador deseja reutilizar comportamento, mas as classes envolvidas n ao possuem uma rela c ao de subtipos entre elas. Nesses casos a heran ca de comportamento n ao pode ser utilizada. Um exemplo dessa situa c ao e apresentado na Figura 4.11, onde a classe Pilha, que est a sendo desenvolvida, herda o comportamento da classe Lista, j a existente. O problema dessa hierarquia e o fato de uma pilha possuir restri c oes quanto ` a ordem de inser c ao e remo c ao de elementos, o que n ao existe em uma lista. Como pode ser visto no objeto p1 do tipo Pilha, al em das opera c oes empilhar() e desempilhar(), denidas na classe Pilha, ele herda opera c oes que podem comprometer a consist encia da ordem da pilha, que nesse caso s ao adicionarInicio() e removerInicio.
l1:Lista Lista +adicionarInicio(e:Elemento):void +removerInicio():Elemento +adicionarFim(e:Elemento):void +removerFim():Elemento +estaCheia():boolean +estaVazia():boolean p1:Pilha
+adicionarInicio(e:Elemento):void +removerInicio():Elemento +adicionarFim(e:Elemento):void +removerFim():Elemento +estaCheia():boolean +estaVazia():boolean
. << instance_of >>
Pilha * empilhar() usa adicionarFim() * desempilhar() usa removerFim() . << instance_of >> +empilhar(e:Elemento):void +desempilhar():Elemento +devolverTopo():Elemento
+adicionarInicio(e:Elemento):void +removerInicio():Elemento +adicionarFim(e:Elemento):void +removerFim():Elemento +estaCheia():boolean +estaVazia():boolean +empilhar(e:Elemento):void +desempilhar():Elemento +devolverTopo():Elemento
Figura 4.11: Hierarquia de Lista e Pilha com Heran ca A seguir, e apresentada a implementa c ao da hierarquia apresentada na Figura 4.11 em Java:
1 2 3 4
public c l a s s L i s t a { // A t r i b u t o s // . . . // Opera c o es

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
107
public void a d i c i o n a r I n i c i o ( Elemento e ) { . . . } public Elemento r e m o v e r I n i c i o ( ) { . . . } public void a d i c i o n a r F i m ( Elemento e ) { . . . } public Elemento removerFim ( ) { . . . } public b o o l e a n e s t a V a z i a ( ) { . . . } // r e t o r n a TRUE s e a l i s t a e s t i v e r v a z i a . // Sen a o , r e t o r n a FALSE public b o o l e a n e s t a C h e i a ( ) { . . . } // r e t o r n a TRUE s e a l i s t a e s t i v e r c h e i a . // Sen a o , r e t o r n a FALSE }
public c l a s s P i l h a e x t e n d s L i s t a { // A t r i b u t o s // . . . // Opera c o es public void e m p i l h a r ( Elemento e ) { a d i c i o n a r F i m ( e ) ; } public Elemento d e s e m p i l h a r ( ) public Elemento devolverTopo ( ) { Elemento e = d e s e m p i l h a r ( ) ; empilhar ( e ) ; return e ; } } ... public s t a t i c void main ( S t r i n g [ ] a r g s ) { P i l h a p l h = new P i l h a ( ) ; p l h . a d i c i o n a r I n i c i o ( e l e m e n t o ) ; // corrompe o e s t a d o da p i l h a } { return removerFim ( ) ; }
Para contornar esse problema, e poss vel utilizar uma varia c ao de heran ca, existente em UML: heran ca de implementa c ao. Diferentemente da heran ca que materializa o relacionamento de generaliza c ao/especializa c ao, apresentada na Se c ao 1.3.5 do Cap tuilo 1, a heran ca de implementa c ao n ao representa o conceito de tipo/subtipo. Isso acontece pelo fato dela especicar que a subclasse herda apenas a implementa c ao das opera c oes, mas n ao essas opera c oes n ao fazem parte da sua interface p ublica [9]. A Figura 4.12 apresenta a hierarquia de Lista e Pilha, utilizando heran ca de implementa c ao. Perceba que o relacionamento de heran ca recebe o estere otipo implementation . Nessa hierarquia, Pilha n ao e um tipo de Lista.
108
l1:Lista Lista + adicionarInicio (e:Elemento ):void + adicionarInicio (e:Elemento ):void + removerInicio ():Elemento . << instance_of >> + adicionarFim (e:Elemento ):void + removerInicio ():Elemento + adicionarFim (e:Elemento ):void + removerFim ():Elemento + removerFim ():Elemento + estaCheia ():boolean + estaCheia ():boolean + estaVazia ():boolean + estaVazia ():boolean p1:Pilha << implementation >> Pilha * empilhar() usa adicionarFim() * desempilhar() usa removerFim() * estaCheia() usa estaCheia() * estaVazia() usa estaVazia() . << instance_of >> + empilhar (e:Elemento ):void + desempilhar ():Elemento + devolverTopo ():Elemento + estaCheia ():boolean + estaVazia ():boolean adicionarInicio (e:Elemento ):void removerInicio ():Elemento adicionarFim (e:Elemento ):void removerFim ():Elemento + empilhar (e:Elemento ):void + desempilhar ():Elemento + devolverTopo ():Elemento + estaCheia ():boolean + estaVazia ():boolean
Figura 4.12: Hierarquia de Lista e Pilha com Heran ca de Implementa c ao A seguir, e apresentada a implementa c ao da hierarquia apresentada na Figura 4.12 em C++, utilizando heran ca de implementa c ao, que em C++ e implementada atrav es de deriva c ao privada:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
c l a s s P i l h a : private L i s t a { // A t r i b u t o s // . . . // Opera c o es public : L i s t a : : e s t a C h e i a ( ) ; // v i s i b i l i d a d e p u blica explicita Lista : : estaVazia () ; // o p e r a c o e s de P i l h a void e m p i l h a r ( Elemento e ) { a d i c i o n a r F i m ( e ) ; } Elemento d e s e m p i l h a r ( ) Elemento devolverTopo ( ) { Elemento e = d e s e m p i l h a r ( ) ; empilhar ( e ) ; return e ; } }; ... i n t main ( ) { Pilha plh ; { return removerFim ( ) ; } // v i s i b i l i d a d e p u blia explicita

20 21
109
p l h . a d i c i o n a r I n i c i o ( e l e m e n t o ) ; // e r r o de c o m p i l a c ao }
Solu c ao Recomendada Usando Agrega c ao Apesar da heran ca de implementa c ao ser uma poss vel solu c ao para o problema da heran ca de opera c oes indesejadas, a sua utiliza c ao pode tornar o modelo mais complexo e propenso a erros, uma vez que n ao representa um relacionamento de generaliza c ao/especializa c ao entre as classes. Uma solu c ao alternativa para a hierarquia de Lista apresentada na Figura 4.11 consiste em criar uma hierarquia de agrega c ao envolvendo Lista e Pilha. Neste caso, podemos tratar Lista como uma parte de Pilha, conforme ilustrado na Figura 4.13.
Lista
Lista
Pilha
Pilha
+empilhar(e:Elemento):void +desempilhar():Elemento +devolverTopo():Elemento +estaCheia():boolean +estaVazia():boolean
+adicionarInicio(e:Elemento):void +removerInicio():Elemento +adicionarFim(e:Elemento):void +removerFim():Elemento +estaCheia():boolean +estaVazia():boolean
NO RECOMENDADO
RECOMENDADO
Figura 4.13: Solu c ao Alternativa com Agrega c ao O trecho de programa a seguir mostra a implementa c ao parcial dessa solu c ao alternativa em Java:
1 2 3 4 5 6 7 8 9 10 11 12 13
class Pilha { private L i s t a l ; // a p o n t a d o r para um o b j e t o L i s t a
public void e m p i l h a r ( Elemento e ) { l . a d i c i o n a r F i m ( e ) ; } public Elemento d e s e m p i l h a r ( ) { return l . removerFim ( ) ; } public Elemento devolverTopo ( ) { Elemento e = d e s e m p i l h a r ( ) ; empilhar ( e ) ; return e ; } public boolean e s t a C h e i a ( ) { return l . e s t a C h e i a ( ) ; } public boolean e s t a V a z i a ( ) { return l . e s t a V a z i a ( ) ; } };
110
4.4.5
Heran ca de Comportamento
A heran ca de comportamento e a maneira utilizada pelas linguagens de programa c ao para implementar o relacionamento de generaliza c ao/especializa c ao, onde h a a id eia de uma hierarquias de tipos. Essa forma de uso do mecanismo de heran ca e a recomendada, uma vez que a no c ao de subtipo tem um papel fundamental no modelo de objetos. Para xar melhor o conceito, a seguir e apresentada uma deni c ao mais clara de subtipo. Dados dois tipos S e T. S e considerado um subtipo de T se e somente se S possui pelo menos o comportamento de T. Por essa raz ao, um objeto do tipo T pode ser substitu do por um objeto do tipo S, uma vez que ele possui todas as opera c oes denidas em T. Mas apesar de herdar o comportamento do(s) seu(s) supertipo(s), um subtipo pode ter propriedades e opera c oes adicionais. Muitos desenvolvedores costumam utilizar o mecanismo de heran ca como forma de reutiliza c ao de c odigo atrav es do compartilhamento de comportamento. Mas em orienta c ao a objetos, o compartilhamento de comportamento atrav es de heran ca s o e justic avel quando existe um relacionamento verdadeiro de generaliza c ao/especializa c ao entre as duas classes, isto e, quando a subclasse e um tipo da superclasse. A Figura 4.10 apresentou um exemplo da utiliza c ao do mecanismo de heran ca para indicar um relacionamento de generaliza c ao/especializa c ao. Como um Aluno e um Professor s ao considerados um tipo de Usuario, a heran ca de comportamento faz todo o sentido. Nessa hierarquia, as classes Aluno e Professor herdam todo o comportamento de um usu ario da biblioteca: verificarCodigo(), imprimir() e mudarStatus() e por isso podem ser utilizadas onde a classe Usuario e esperada. O fato de haver um supertipo de usu arios facilita a evolu ca o do modelo, no intuito de adicionar novos tipos de usu arios, como por exemplo: Funcion arios e PesquisadoresVisitantes. Sabendo que os elementos de um subconjunto est ao contidos em um conjunto maior e mais abrangente, podemos concluir intuitivamente, que a no c ao de supertipo/subtipo assemelha-se ` a no c ao de conjunto/subconjunto. Por exemplo, todos os objetos do tipo Aluno formam um subconjunto dos objetos do tipo Usu arios (Figura 4.14).
Figura 4.14: Analogia entre Supertipo/Subtipo e Conjunto/Subconjunto
111
4.4.6
Heran ca M ultipla
Em uma hierarquia de classes que utiliza apenas heran ca simples, qualquer classe deriva de no m aximo uma classe base. Por em, em muitas situa c oes e desej avel que uma classe herde de mais de uma classe, o que e poss vel com a utiliza c ao de heran ca m ultipla. Por exemplo, a Figura 4.15 apresenta uma hierarquia de guras geom etricas. A classe Figura dene um tipo abstrato de dados de uma gura de duas dimens oes. A classe Retangulo herda diretamente de Figura e redene a opera c ao calcularArea(). A hierarquia tamb em cont em uma classe denominada Centrado, que dene o tipo abstrato de dados relativo a elementos que possuem um centro denido, e que por isso podem girar em torno dele. Finalmente, a classe RetanguloCentrado representa uma entidade que ao mesmo tempo e um tipo de ret angulo que possui um centro determinado, sendo tamb em um tipo de elemento centrado.
Figura Centrado coordXCentro :int coordYCentro :int raio :float + girar (graus :int ):void Retangulo dimensao1 :float dimensao2 :float + calcularArea ():float
+ calcularArea ():float
RetanguloCentrado
Figura 4.15: Hierarquia de Figuras Geom etricas
Estrat egias para Resolu c ao de Conitos Quando uma classe herda de mais de um pai, existe a possibilidade de conitos: opera c oes e atributos com mesmo nome, mas com sem anticas diferentes, que s ao herdadas das diferentes superclasses. Ao utilizar heran ca m ultipla de classes, um tipo particular de ambig uidade e conhecido como problema do diamante. A Figura 4.16 ilustra esse problema. Quando duas classes (Aluno e Professor) herdam de um mesmo pai (Usuario), e uma outra classe (ProfessorAluno) herda ao mesmo tempo
112
das classes intermedi arias, se um objeto do tipo ProfessorAluno receber uma chamada referente a uma opera c ao denida em Usuario (verificarCodigo, por exemplo), qual a implementa c ao a ser executada? de Usuario, de Aluno, ou de Professor?
Usuario nome :String codigo :String #status :int << create >> + Usuario (nome :String ,codigo :String ,status :String ):Usuario + verificarCodigo (cod :String ):boolean + imprimir ():void #mudarStatus (status :int ):void
Aluno anoEscolar :int << create >> + Aluno (nome :String ,codigo :String ,status :String ,anoEsc:int ):Aluno + aplicarMulta ():void tempoServico :int
Professor
<< create >> + Professor (nome :String ,codigo :String ,status :String ,tempo :int ):Professor + aposentar ():void
ProfessorAluno
Figura 4.16: Problema do Diamante em Heran ca M ultipla O nome problema do diamante e devido ao formato de losango, estabelecido entre as classes (ver Figura 4.16), que lembra um diamante. Muitas solu c oes t em sido propostas para resolver esse problema. A seguir, s ao apresentadas as tr es principais estrat egias existentes: 1. Lineariza c ao. Esta estrat egia especica uma ordem linear e total das classes, e determina que a busca do atributo ou m etodo seja efetuada na ordem estabelecida. Essa abordagem e implementada pelas linguagens Flavors e CommonLoops. 2. Renomea c ao. Ela requer a altera c ao dos nomes de atributos e opera c oes que sejam conitantes. Essa abordagem e implementada por Eiel. 3. Qualica c ao. Sempre que ocorrer ambig uidade, deve-se redenir a opera c ao e utilisar um operador de escopo, como por exemplo a identica c ao da classe seguida de quatro pontos (::), presente em C++. Dessa forma, esse operador permite a identica c ao u nica do atributo ou m etodo conitante. Essa abordagem e implementada pela linguagem C++. A estrat egia de lineariza c ao torna o problema da resolu c ao de conitos transparente ao programador, mas introduz uma ordem obrigat oria na heran ca das classes, o que inviabiliza por exemplo a sele c ao de uma opera c ao conitante de cada classe. A renomea c ao e a qualica c ao s ao estrat egias que promovem uma maior exibilidade para o programador decidir a aplicabilidade dos m etodos e/ou atributos herdados. V arias discuss oes a respeito da viabilidade da heran ca m ultipla t em sido discutidas na literatura. Heran ca m ultipla e um assunto controverso. Apesar disso, esse tipo de heran ca e uma ferramenta poderosa para a especica c ao de classes e para o aumento da oportunidade de reutiliza c ao de
113
comportamento. As suas principais desvantagens s ao o aumento do acoplamento entre as classes do sistema e o aumento da complexidade do modelo e da implementa c ao.
4.4.7
Exemplo de Heran ca M ultipla em UML
A Figura 4.17 mostra um exemplo de uso de heran ca m ultipla.

Relogio hr :int min :int seg:int is_pm :int << create >> + Relogio (h:int ,s:int ,m :int ,pm :int ):Relogio + ajustarRelogio (h:int ,s:int ,m :int ,pm :int ):void + lerRelogio ():int[] + avancar ():void mes :int dia :int ano :int << create >> + Calendario (d:int ,m :int ,a:int ):Calendario + ajustarCalendario (d:int ,m :int ,a:int ):void + lerCalendario ():int[] + avancar ():void Calendario
RelogioCalendario
<< create >> + RelogioCalendario (d:int ,m :int ,a:ano ,h:int ,s:int ,m :int ,pm :int ):RelogioCalendario + avancar ():void
Figura 4.17: Hierarquia de um Rel ogio-Calend ario Neste exemplo, tanto a classe Relogio quanto a classe Calendario apresentam o m etodo avancar() nas suas interfaces. Embora essas opera c oes tenham o mesmo nome, as suas sem anticas s ao diferentes pois a opera c ao avancar() da classe Relogio avan ca o ponteiro de um rel ogio, enquanto a opera c ao avancar() da classe Calendario avan ca um dia do calend ario e eventualmente tamb em avan ca o m es e o ano, caso seja necess ario. A classe RelogioCalendario implementa a sua pr opria opera c ao avancar() cuja sem antica e uma fus ao das outra duas opera c oes avancar() herdadas. O conito de nomes repetidos das opera c oes e resolvido com a estrat egia de qualica c ao, usando-se o operador de escopo de C++ nomeDaClasse::nomeDaOpera c ao. Dessa forma a classe RelogioCalendario pode fazer uso das duas implementa c oes herdadas como lhe for conveniente. O trecho do c odigo a seguir, apresenta uma implementa c ao parcial em C++ para a hierarquia apresentada na Figura 4.17.
1 2 3 4 5 6 7 8
class Relogio { protected : i n t hr ; i n t min ;
i n t s e g ; i n t is pm ; public : R e l o g i o ( i n t h , i n t s , i n t m, i n t pm) { . . . } void a j u s t a r R e l o g i o ( i n t h , i n t s , i n t m, i n t pm) { . . . } int [ ] l e r R e l o g i o ( ) { . . . }
114
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

void a va n c a r ( ) { . . . } // > c o n f l i t o de nome };
class Calendario { protected : i n t mes ; i n t d i a ; i n t ano ; public : C a l e n d a r i o ( i n t d , i n t m, i n t a ) { . . . } void a j u s t a r C a l e n d a r i o ( i n t d , i n t m, i n t a ) { . . . } int [ ] l e r C a l e n d a r i o ( ) { . . . } void a va n c a r ( ) { . . . } // > c o n f l i t o de nome };
c l a s s R e l o g i o C a l e n d a r i o : public R e l o g i o , public C a l e n d a r i o { public : R e l o g i o C a l e n d a r i o ( i n t d , i n t m, i n t a , i n t h , i n t mn, i n t s , i n t pm) { . . . } void a va n c a r ( ) { R e l o g i o : : a va n c a r ( ) ; C a l e n d a r i o : : a va n c a r ( ) ; //> M e todos Q u a l i f i c a d o s } };
Heran ca M ultipla vs. Agrega c ao Apesar da expressividade do relacionamento de heran ca m ultipla, a sua utiliza c ao aumenta o acoplamento entre as classes, uma vez que a classe derivada passa a ser afetada diretamente por altera c oes em qualquer uma de suas classes base. Al em disso, como j a discutido anteriormente, o uso de heran ca m ultipla aumenta consideravelmente a complexidade dos sistemas e por isso deve ser empregado de forma disciplinada. Devido ` a diculdade em se utilizar corretamente o conceito de heran ca m ultipla e principalmente ao aumento da complexidade do sistema decorrente dessa utiliza c ao, algumas linguagens de programa c ao orientada a objetos, como por exemplo Java e C#, n ao oferecem meios de se implementar heran ca m ultipla entre classes. Em contrapartida, a literatura de engenharia de software apresenta t ecnicas de modelagem que podem ser empregadas como formas alternativas a esse conceito. Essas t ecnicas visam tanto suprir as necessidades de reutiliza c ao de c odigo, quanto a id eia
Cap tulo 4: Fundamentos de An alise OO de possuir mais de um supertipo, separando explicitamente esses dois conceitos.
115
Como mostrado na Figura 4.4.7, o relacionamento de agrega c ao pode ser utilizado como forma alternativa de se alcan car a reutiliza c ao de c odigo, existente na implementa c ao da classe RelogioCalendario, mostrada na Figura 4.17. Essa reutiliza c ao acontece atrav es da comunica c ao com as classes Relogio e Calendario, que e poss vel gra cas ao relacionamento de agrega c ao, tornando a classe RelogioCalendario um cliente por instancia c ao das classes Relogio e Calendario.
Relogio hr :int min :int seg:int is_pm :int << create >> + Relogio (h:int ,s:int ,m :int ,pm :int ):Relogio + ajustarRelogio (h:int ,s:int ,m :int ,pm :int ):void + lerRelogio ():int[] + avancar ():void mes :int dia :int ano :int << create >> + Calendario (d:int ,m :int ,a:int ):Calendario + ajustarCalendario (d:int ,m :int ,a:int ):void + lerCalendario ():int[] + avancar ():void Calendario
RelogioCalendario
<< create >> + RelogioCalendario (d:int ,m :int ,a:ano ,h:int ,s:int ,m :int ,pm :int ):RelogioCalendario + ajustarRelogio (h:int ,s:int ,m :int ,pm :int ):void + ajustarCalendario (d:int ,m :int ,a:int ):void + lerRelogio ():int[] + lerCalendario ():int[] + avancar ():void
Figura 4.18: Alternativa ` a Heran ca M ultipla com Agrega c ao Apesar da agrega c ao n ao expressar o conceito de supertipos/subtipo envolvido no relacionamento de heran ca, isso pode ser resolvido de uma maneira elegante utilizando interfaces. A Se c ao 4.7 abordar a essa quest ao em detalhes. Por representar unicamente o conceito de tipo, as interfaces podem ser utilizadas de forma ortogonal e complementar ao conceito de composi c ao de classes, presente na agrega c ao.
4.5
Polimorsmo
Esta se c ao examina os conceitos de polimorsmo, concentrando-se nas v arias formas de polimorsmo existentes. Polimorsmo e um conceito chave no contexto de orienta c ao a objetos.
4.5.1
O que e polimorsmo?
A palavra polimorsmo e derivada do grego e signica muitas formas ou tendo muitas formas. Quando usada no contexto de orienta c ao a objetos, polimorsmo signica que vari aveis podem
116
referenciar mais do que um tipo. Como conseq u encia, essas vari aveis podem fazer refer encias a diferentes tipos em diferentes contextos. O conceito de polimorsmo n ao e novo; por volta de 1976, a linguagem ML apresentou uma disciplina de tipo polim orca uniformizada para todos os tipos da linguagem. Atualmente, existem fun c oes e tipos polim orcos aplicados a diversas linguagens de programa c ao. Uma fun c ao e considerada polim orca quando seus par ametros podem ter mais do que um tipo. Em tipo, por sua vez, e dito polim orco se o seu conjunto de opera c oes pode ser aplicada a operandos de mais de um tipo; caso contr ario s ao ditos monom orcos. Por exemplo, numa linguagem polim orca, pode-se denir uma u nica fun c ao obterComprimento() do tipo: obterComprimento::[A] -> NUM, para todos os tipos A, signicando que (i) obterComprimento() e uma fun c ao cujo par ametro de entrada e uma lista de elementos (simbolizada pelos colchetes); (ii) o tipo de cada elemento da lista pode ser qualquer um, simbolizado por (A); e (iii) a fun c ao devolve um valor num erico como sa da. Em contraste, uma linguagem com tipos monom orcos for ca o programador a denir diferentes fun c oes para retornar o comprimento de uma lista de inteiros, de uma lista de reais, e assim por diante. Exemplos de linguagens com tipos monom orcos s ao C, Pascal e Algol-68. Em particular, no contexto do modelo de objetos, polimorsmo signica que diferentes tipos de objetos podem responder a uma mesma mensagem de maneiras diferentes (Figura 4.19). Por exemplo, num programa, podemos denir uma opera c ao chamada imprimir() em diversas classes diferentes, mas cada vers ao de imprimir() e adaptada para o tipo espec co de objeto que ser a impresso. Um objeto do tipo Publicacao responder a` a mensagem imprimir() de uma maneira, um objeto Livro responder a de outra forma e um objeto do tipo Periodico responder a de uma outra forma ainda. Isto signica que n ao temos que denir opera c oes com nomes completamente diferentes para cada um dos tipos, como por exemplo, imprimirPublicacao(), imprimirLivro() e imprimirPeriodico(), o que tornaria o programa muito menos ex vel. Dizemos que imprimir() e uma opera c ao polim orca pois ela e implementada diferentemente por diferentes tipos de objetos.
Figura 4.19: M etodo Polim orco
117
A Figura 4.20 mostra uma hierarquia de classes em UML correspondente ao exemplo da Figura 4.19. A classe Publicacao est a no topo da hierarquia e dene uma implementa c ao padr ao para a implementa c ao imprimir(). Suas subclasses: Livro e Periodico, denem implementa c oes espec cas.
* imprimir() implementao padro (#1)
Livro edicao :int << create >> + Livro (numTomb :String ,nome :String ,editora :String ,edicao :int ):Livro + bloquear ():void + imprimir ():void periodicidade :int
Periodico
<< create >> + Periodico (numTomb :String ,nome :String ,editora :String ,per :int ):Periodico + indexar ():void + imprimir ():void
* imprimir() implementao especfica (#2)
* imprimir() implementao especfica (#3)
Figura 4.20: Uma Hierarquia de Tipos e Subtipos Polim orcos Em sistemas de software, mais especicamente nas linguagens de programa c ao, a multiplicidade de formas pode ser obtida de diversas maneiras. Cardelli e Wegner [13] criaram uma taxonomia que classica o polimorsmo em categorias e subcategorias. Como pode ser visto na Figura 4.21, existem duas categorias principais: (i) ad hoc; e (ii) universal. O polimorsmo ad hoc e caracterizado pela aus encia de um modo uniforme no comportamento de uma fun c ao, que pode variar radicalmente, de acordo com os tipos dos seus argumentos de entrada. No polimorsmo universal, tamb em conhecido como polimorsmo verdadeiro, uma fun c ao ou tipo trabalha uniformemente para qualquer um dos tipos que ele seja compat vel. Sendo assim, enquanto o polimorsmo ad hoc trabalha com um n umero limitado de tipos de um modo n ao sistem atico, o polimorsmo universal trabalha potencialmente com um conjunto innito de tipos de modo disci plinado. As duas principais formas de polimorsmo ad hoc s ao: coer c ao e sobrecarga. Em rela c ao ao polimorsmo universal, as duas formas b asicas s ao: polimorsmo param etrico e polimorsmo de inclus ao . A seguir, as Se c oes 4.5.2 a 4.5.5 detalham cada uma dessas quatro formas de polimorsmo.
Polimorfismo Universal Paramtrico Incluso Sobrecarga Ad Hoc Coero
Figura 4.21: Taxonomia de Cardelli e Wegner
118
4.5.2
Coer c ao
A coer c ao proporciona um meio de contornar a rigidez de tipos monom orcos. Linguagens que d ao suporte a coer c ao realizam um mapeamento interno entre tipos, de acordo com rela c oes de equival encia existentes entre eles. Imagine que uma determinada chamada de fun c ao passa um tipo diferente do esperado; nesse caso, a pr opria linguagem verica se existe uma coer c ao adequada, baseada na convers ao impl cita entre tipos de dados equivalentes. O trecho de c odigo seguinte apresenta um exemplo desse cen ario, implementado em Java.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
public c l a s s P r o f e s s o r { // A t r i b u t o s private f l o a t s a l a r i o ; ...
// Operacoes public void a u m e n t a r S a l a r i o ( f l o a t abono ) { s a l a r i o = s a l a r i o + abono ; } ...
// . . . u t i l i z a c a o do m e todo public s t a t i c void main ( S t r i n g [ ] a r g s ) { P r o f e s s o r p1 = new P r o f e s s o r ( ) ; int i 1 = 400; float f1 = 712.5; p1 . a u m e n t a r S a l a r i o ( i 1 ) ; p1 . a u m e n t a r S a l a r i o ( f 1 ) ; } }
No exemplo anterior, o m etodo aumentarSalario() e denido como tendo um par ametro do tipo float. Devido ao uso de coer c ao, e poss vel chamar esse procedimento passando como argumento um par ametro do tipo int (Linha 17) ou qualquer outro tipo compat vel com o tipo (que caiba em) float. Se n ao houvesse coer c ao, seria necess ario denir dois m etodos:
1 2
public void a u m e n t a r S a l a r i o 1 ( f l o a t abono ) { . . . } ; public void a u m e n t a r S a l a r i o 2 ( i n t abono ) { . . . } ;
Note que, no trecho de c odigo acima, todos os m etodos t em nomes diferentes, mas suas implementa c oes seriam a mesma. Dessa forma, al em de melhorar a legibilidade do programa, a coer c ao tamb em proporciona reutiliza c ao de c odigo.
119
4.5.3
Sobrecarga
O polimorsmo de sobrecarga (do ingl es overloading) permite que um nome de fun c ao seja usado mais do que uma vez, com diferentes tipos de par ametros. A Figura 4.22 apresenta a especica c ao da classe Publicacao, que possui duas opera c oes construtoras recebendo argumentos diferentes. Nesse caso, dizemos que o construtor da classe Publicacao foi sobrecarregado.
Figura 4.22: Polimorsmo de Sobrecarga na Classe Publicacao
4.5.4
Polimorsmo Param etrico
O uso do polimorsmo param etrico possibilita que uma u nica fun c ao possa ser codicada, de modo a funcionar uniformemente com v arios tipos distintos. Por esse motivo, fun c oes param etricas s ao tamb em chamadas de fun c oes gen ericas. Como exemplo de uma fun c ao param etrica, considere a fun c ao obterComprimento() discutida na Se c ao 4.5.1. Como exemplo de tipo param etrico ou classe param etrica, considere uma classe Pilha< T ipo >, onde Tipo e o tipo do elemento que ser a manipulado. Desse modo, uma classe gen erica que implementa uma pilha pode ser escrita independentemente do tipo dos itens que s ao armazenados nela. A Figura 4.23 mostra a representa c a da pilha gen erica em UML. Nessa gura, o tipo param etrico Pilha< T ipo >, exemplicando a sua instancia c ao atrav es da deni c ao de tr es objetos que representam pilhas de tipos espec cos e distintos: uma pilha de livros (PilhaLivro ou Pilha<Livro>), uma pilha de publica c oes (PilhaPublicacao ou Pilha<Publicacao>) e uma pilha de strings (PilhaString ou Pilha<String>). Note que o estere otipo << bind >> se aplica a um relacionamento de depend encia, especicando que o tipo gen erico fonte (no caso, a classe Pilha) instancia o tipo alvo usando os par ametros dados. O trecho de c odigo a seguir apresenta parte da implementa c ao em Java da pilha polim orca apresentada na Figura 4.23. A partir da vers ao 1.5.0 [11] lan cada em 2005, a linguagem Java incorporou o conceito de tipos gen ericos, uma forma de implementar polimorsmo param etrico. As Linhas 12 a 16 apresentam como a classe Pilha pode ser instanciada para tipos distintos.
1 2 3 4
public c l a s s P i l h a <Tipo >{ private Tipo i t e m A t u a l ; private Tipo proximoItem ; private i n t maxLen ;
120
Figura 4.23: Polimorsmo Param etrico

private i n t top ;
5 6 7 8 9 10 11 12 13 14
public void e m p i l h a r ( Tipo i ) { . . . } public Tipo d e s e m p i l h a r ( ) { . . . } public boolean e s t a C h e i a ( ) { . . . } public boolean e s t a V a z i a ( ) { . . . }
public s t a t i c void main ( S t r i n g [ ] a r g s ) { P i l h a <Livro > p i l h a L i v r o = new P i l h a <Livro > () ; // p i l h a de L i v r o s P i l h a < P e r i o d i c o > p i l h a P e r i o d i c o = new P i l h a < P e r i o d i c o > () ; // p i l h a de Periodicos
15 16 17
P i l h a <S t r i n g > p i l h a S t r i n g = new P i l h a <S t r i n g > () ; // p i l h a de S t r i n g s } }
Um detalhe importante da implementa c ao de polimorsmo param etrico em Java e que o conceito de classes gen ericas s o pode ser instanciada com tipos relativos a classes, (subtipos de Object). Dessa forma, no exemplo da pilha gen erica, n ao e poss vel denir uma pilha de nenhum tipo nativo da linguagem: boolean, byte, char, double, float, int, long e short.
4.5.5
Polimorsmo de Inclus ao
Por estar relacionado com a no c ao de supertipo/subtipo decorrente do relacionamento de generaliza c ao/especializa c ao, o polimorsmo de inclus ao s o e encontrado em linguagens orientadas a objetos. O princ pio b asico do polimorsmo de inclus ao e uma conseq u encia do fato das subclasses (ou subtipos) herdarem automaticamente todas as opera c oes das suas respectivas superclasses (ou
121
supertipos). Por exemplo, na hierarquia da Figura 4.20 da Se c ao 4.5.1, a classe Publicacao tem duas subclasses: Livro e Periodico. Al em dos seus construtores, que n ao s ao herdados, a classe Publicacao dene duas outras opera c oes: reservar() e imprimir(). Livro dene uma opera c ao adicional: bloquear(), enquanto Periodico adiciona a opera c ao: indexar(). O trecho de c odigo seguinte apresenta alguns exemplos de uso dessas classes, levando-se em considera c ao a exist encia de polimorsmo de inclus ao. Perceba que as Linhas 8 e 12 apresentam um erro de inconsist encia de tipos.
1 2 3 4 5 6 7 8 9 10 11 12
... P u b l i c a c a o p = new P u b l i c a c a o ( ) ; p . imprimir ( ) ; p . reservar () ; p = new L i v r o ( ) ; p . imprimir ( ) ; p . reservar () ; p . bloquear () ; // ERRO
p = new P e r i o d i c o ( ) ; p . imprimir ( ) ; p . reservar () ; p . i n d e x a r ( ) ; // ERRO
No c odigo anterior, a vari avel p e do tipo Publicacao (Linha 2) e, portanto, independentemente do subtipo do objeto para o qual apontar, essa vari avel aceita apenas as opera c oes denidas em Publicacao. A vari avel p pode referenciar qualquer objetos do tipo Publicacao, incluindo as inst ancias de seus subtipos. No exemplo, s ao atribu dos a p um objeto do tipo Livro (Linha 5) e outro do tipo Periodico (Linha 9). Quando as opera c oes imprimir() e reservar() s ao acionadas a partir de p, tanto os objetos do tipo Publicacao quanto os dos tipos Livro e Periodico s ao capazes de respond e-las, uma vez que esses dois u ltimos herdaram essas opera c oes de Publicacao. Por outro lado, se chamarmos as opera c oes bloquear() (Linha 8) ou indexar() (Linha 12), ocorre um erro, j a que essas opera c oes n ao est ao declaradas no tipo da vari avel p, que e Publicacao. O polimorsmo de inclus ao foi batizado com esse nome porque as opera c oes polim orcas de um tipo est ao inclu das nos seus subtipos. Em Java, a classe Object e a raiz de todas as classes. Os m etodos da classe Object s ao exemplos de polimorsmo de inclus ao, pois eles s ao capazes de operar uniformemente sobre objetos de qualquer tipo em Java. Um caso especial de polimorsmo de inclus ao ocorre quando uma subclasse dene uma forma de implementa c ao especializada para um m etodo herdado da classe base. Nesse caso, diz-se que o m etodo da classe derivada redene o m etodo da classe base. Para que a redeni c ao ocorra, o novo m etodo deve ter a mesma assinatura do m etodo herdado, isto e, eles devem ser id enticos quanto ao nome da opera c ao e ` a lista de par ametros (mesmo n umero de par ametros, com os mesmos tipos e declarados na mesma ordem). O tipo do resultado de retorno n ao faz parte da assinatura do m etodo e n ao pode ser modicado. A no c ao de redeni c ao de m etodos s o faz sentido em linguagens
122
que d ao suporte a acoplamento din amico, como Java, C++ e C#. Na hierarquia de publica c oes apresentada na Figura 4.20 da Se c ao 4.5.1, a opera c ao imprimir(), denida inicialmente na classe Publicacao, e redenido pelas suas subclasses Livro e Periodico. Note que a redeni c ao de m etodos e diferente da sobrecarga. Na primeira, o m etodo que redene e o m etodo redenido precisam ter assinaturas absolutamente id enticas e esses m etodos precisam ser declarados em classes distintas ligadas por um relacionamento de heran ca. No caso da sobrecarga, as assinaturas precisam ser diferentes (contanto que o nome continue o mesmo) e as diversas implementa c oes do m etodo podem estar todas localizadas na mesma classe.
4.5.6
Exemplo: Pilha de Publica c oes
Considere uma pilha de publica c oes formada por v arios tipos diferentes de publica c oes, como livros e peri odicos, como ilustrado pela Figura 4.24.
Figura 4.24: Uma Pilha de Publica c oes A pilha de publica c oes da Figura 4.24 poderia ser modelada conforme apresentado na Figura 4.25. Suponha agora que gostar amos de imprimir o conte udo de cada um dos objetos armazenados na pilha. Numa linguagem orientada a objetos que d a suporte a polimorsmo de inclus ao, podemos modelar os tipos de documentos existentes e a pr opria pilha seguindo a hierarquia de classes apresentada na Figura 4.25. O trecho de c odigo seguinte apresenta a implementa c ao em Java do m etodo imprimir() da classe Pilha.
1 2 3 4 5 6 7
public c l a s s P i l h a { private P u b l i c a c a o e l e m e n t o s P i l h a [ ] ; // a r r a y de a p o n t a d o r e s para // o b j e t o s do t i p o P u b l i c a c a o ... public void i m p r i m i r ( ) { f o r ( i n t i =0; i < e l e m e n t o s P i l h a . l e n g t h ; i ++) { elementosPilha [ i ] . imprimir ( ) ;

123
Pilha numElementos :int << create >> + Pilha():Pilha + empilhar (e:int ):void + desempilhar ():int + estaVazia ():boolean + estaCheia ():boolean + devolverTopo ():int + imprimir ():void *
Livro edicao :int << create >> + Livro (numTomb :String ,nome :String ,editora :String ,edicao :int ):Livro + bloquear ():void + imprimir ():void periodicidade :int
Periodico
<< create >> + Periodico (numTomb :String ,nome :String ,editora :String ,per :int ):Periodico + indexar ():void + imprimir ():void
* imprimir() para cada elemento da pilha elemento.imprimir()
* imprimir() imprime os atributos especficos de um livro
* imprimir() imprime os atributos especficos de um peridico
Figura 4.25: Um Exemplo de Polimorsmo de Inclus ao com Redeni c ao de Opera c oes
8 9 10
} } }
No trecho de c odigo acima, a implementa c ao do m etodo imprimir(), que e executado a cada itera c ao do la co for, depende do tipo do objeto apontado por elementosPilha[i]. Por exemplo, se for um objeto do tipo Livro, o m etodo imprimir() chamado e o denido pela classe Livro. Por outro lado, se elementosPilha[i] aponta para um objeto do tipo Periodico, a implementa c ao utilizada ea
4.6
Classes Abstratas
Uma classe abstrata e uma classe que n ao pode ter inst ancias diretas, enquanto que uma classe concreta pode ser instanciada. Classes abstratas podem denir o protocolo para uma opera c ao, fornecendo ou n ao a implementa c ao correspondente. No caso de n ao oferecer o c odigo referente ` a sua implementa c ao, a opera c ao e denominada abstrata. Uma opera c ao abstrata dene a assinatura de uma opera c ao para a qual cada subclasse concreta deve providenciar sua pr opria implementa c ao. Por exemplo, a Figura 4.26 mostra uma opera c ao abstrata reservar() da classe Publicacao (apresentada em it alico); sua assinatura est a denida mas n ao sua implementa c ao. Dessa forma, cada subclasse concreta deve redenir o m etodo da opera c ao abstrata. Livro e Periodico s ao exemplos de classes concretas. Perceba que por possuir um m etodo abstrato, a classe Publicacao obrigatoriamente deve ser abstrata (nome em it alico).
124
Publicacao numeroTombo :String nome :String editora :String
<< create >> + Publicacao (numTomb :String ,nome :String ,editora :String ): Publicacao + reservar ():void + imprimir ():void
Livro edicao :int << create >> + Livro (numTomb :String ,nome :String ,editora :String ,edicao :int ):Livro + bloquear ():void + imprimir ():void + reservar ():void periodicidade :int
Periodico
<< create >> + Periodico (numTomb :String ,nome :String ,editora :String ,per :int ):Periodico + indexar ():void + imprimir ():void + reservar ():void
Figura 4.26: Exemplo de Classe Abstrata e Concreta
4.6.1
Opera c ao Abstrata vs. Opera c ao Concreta
Sintaticamente, uma classe abstrata e expressada em UML pela representa c ao do seu nome em it alico (veja a classe Publicacao da Figura 4.26). Em Java, tanto uma opera c ao quanto uma classe podem ser declaradas como abstratas. Em ambos os casos, e necess ario usar o modicador abstract. Por exemplo:
1 2 3 4 5 6
public abstract c l a s s P u b l i c a c a o { public P u b l i c a c a o ( S t r i n g numTomb, S t r i n g nome , S t r i n g e d i t o r a ) { . . . } public abstract void r e s e r v a r ( ) ; public void i m p r i m i r ( ) { . . . }
Existem duas id eias principais envolvidas com a no c ao de classe abstrata, a saber: (i) presen ca de opera c oes abstratas; e (ii) inviabilidade de se criar inst ancias a partir delas. Em Java, uma classe pode ser declarada como abstrata sem que nenhuma das suas opera c oes seja abstrata. O modicador abstract atribu do a ` classe indica apenas que ela n ao pode ser instanciada. Por em em C++, para que uma classe seja considerada abstrata e necess ario que ela tenha pelo menos uma opera c ao abstrata. Mas uma caracter stica essas duas linguagens t em em comum: toda classe que cont em opera c oes abstratas precisa, necessariamente, ser declarada como abstrata. Se uma classe cont em opera c oes abstratas, n ao faz sentido permitir que seja instanciada, uma vez que objetos criados a partir dessa classe n ao ser ao capazes de responder a todas as mensagens denidas na sua interface p ublica. Na Figura 4.27, um outro exemplo, baseado na mesma hierarquia de publica c oes da Figura 4.26 e apresentado. Nessa gura, a classe Publica c ao e abstrata. Isso signica que, apesar de Usuario estar associado a Publicacao, os objetos que as pessoas reservam s ao inst ancias das classes concretas Livro ou Periodico. Quando a opera c ao reservar() e chamada para uma vari avel do tipo Publicacao, o efeito

Publicacao numeroTombo :String nome :String editora :String << create >> + Publicacao (numTomb :String ,nome :String ,editora :String ): Publicacao + reservar ():void + imprimir ():void
125
Usuario
Livro edicao :int << create >> + Livro (numTomb :String ,nome :String ,editora :String ,edicao :int ):Livro + bloquear ():void + imprimir ():void + reservar ():void periodicidade :int
Periodico
<< create >> + Periodico (numTomb :String ,nome :String ,editora :String ,per :int ):Periodico + indexar ():void + imprimir ():void + reservar ():void
Figura 4.27: Uma Hierarquia de Classes de Reserva de Publica c oes obtido depende do tipo do objeto sendo referenciado na ocasi ao. Se for um objeto da classe Livro, a opera c ao reservar() agenda a reserva de um livro por quinze dias, utilizando a implementa c ao especicada na classe Livro. Se for um objeto da classe Periodico, a opera c ao reservar() agenda a reserva de um peri odico por um per odo de sete dias, utilizando a implementa c ao especicada na classe Periodico.
4.6.2
Classe Raiz, Classe Folha e Opera c ao Folha
Classes abstratas e concretas bem como os seus elementos polim orcos s ao exemplicados na Figura 4.28. Em UML, uma classe e abstrata se o seu nome est a escrito em it alico. Por exemplo, como a Figura 4.28 mostra, as classes A, B e C s ao todas abstratas, isto e, nenhuma delas pode ter inst ancias diretas. Em contraste, as classes D, E e F s ao concretas, isto e, elas podem ter inst ancias diretas criadas a partir delas. Normalmente em UML, quando uma classe e criada, considera-se que ela possa herdar de outras classes mais gerais e que tenha classes derivadas que herdem seu comportamento. Entretanto, voc e pode especicar em UML uma classe que n ao possui classes lhas, escrevendo a propriedade leaf (folha) embaixo do nome da classe. Uma classe folha n ao tem classes derivadas. De forma an aloga, podemos especicar uma classe raiz, isto e, que n ao tem nenhum pai, escrevendo a propriedade root embaixo do nome da classe. Uma classe raiz n ao e derivada de nenhuma outra classe do sistema, e indica o in cio de uma hierarquia de classes. Em UML, uma opera c ao e, por deni c ao, polim orca. Isso signica que voc e pode especicar opera c oes com a mesma assinatura em diversos pontos da hierarquia de classes (isto e, polimorsmo de inclus ao). Nesse caso, quando uma mensagem e enviada em tempo de execu c ao, a opera c ao que e invocada na hierarquia e escolhida polimorcamente isto e, a opera c ao escolhida depende do tipo do objeto que recebeu a mensagem. Por exemplo, na Figura 4.28, a opera c ao1() e a opera c ao2() s ao opera c oes polim orcas. Al em disso, a opera c ao A::opera ca o1() e abstrata. Em UML, voc e especica que uma opera c ao e abstrata escrevendo o seu nome em it alico, similarmente ao que e feito com uma classe. Em contraste, A::opera c ao3() e uma opera c ao folha, signicando que a opera c ao n ao e polim orca e n ao pode ser redenida em nenhum lugar da hierarquia.
A Figura 4.29 mostra uma hierarquia de classes para c aes. A classe C ao e a raiz da hierarquia e implementa o m etodo mostraRa ca como sendo virtual. As suas subclasses redenem o m etodo mostraRa ca para que imprima o tipo de classe de c ao que seja adequada.
126
4.6.3 Exemplo 1: Hierarquia de Ra cas de C aes

A{root} classe base (no tem classes pais)
Figura 4.28: Exemplo de Hierarquia de Classes
classes abstratas (em itlico)
+ operacao1 ():void + operacao3{leaf} ():void
operao abstrata (em itlico) e polimrfica operao folha (no pode ser redefinida)
classe abstrata B C
+ operacao4 (p:Tipo ):void
+ operacao2 ():void
operao polimrfica
operaes sobrecarregadas D F
+ operacao4 (p:Tipo ,q:Tipo ):void + operacao1 ():void
+ operacao1 ():void + operacao2 ():void classes concretas
operao redefinida e concreta operao redefinida e concreta
operaes redefinidas e concretas
E{leaf} classe folha (no pode ter classes filhas) + operacao1 ():void
127
Cachorro
classe concreta
+mostraRaca():void
operao polimrfica e concreta
Boxer
Cocker
Schnauzer operao redefinida e concreta
+mostraRaca():void
+mostraRaca():void
+mostraRaca():void
Miniatura
Padrao operao redefinida e concreta
+mostraRaca():void
+mostraRaca():void
Figura 4.29: Hierarquia de Classe para C aes Um trecho parcial de c odigo Java que implementa essa hierarquia, e mostrado a seguir:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
c l a s s Cachorro { public void mostraRaca ( ) { System . out . p r i n t l n ( Raca n ao d e f i n i d a ) ; } }
c l a s s Schnauzer extends Cachorro { public void mostraRaca ( ) { System . out . p r i n t l n ( Raca Schnauzer ) ; } }
c l a s s M i n i a t u r a extends Schnauzer { public void mostraRaca ( ) { System . out . p r i n t l n ( Raca Schnauzer M i n i a t u r a ) ; } }
public s t a t i c void main ( S t r i n g a r g s [ ] ) {
128
20 21 22 23 24 25 26 27 28
Cachorro apCao = new Cachorro ( ) ; // a p o n t a d o r para o b j e t o s do t i p o Cachorro Schnauzer s = new Schnauzer ( ) ; M i n i a t u r a m = new M i n i a t u r a ( ) ; apCao . mostraRaca ( ) ; // imprime Ra c a n ao d e f i n i d a apCao = s ; // r e c e b e e n d e r e c o do o b j e t o s apCao . mostraRaca ( ) ; // imprime Ra c a Schnauzer apCao = m; // r e c e b e e n d e r e c o do o b j e t o m apCao . mostraRaca ( ) ; // imprime Ra c a Schnauzer M i n i a t u r a }
Observe que no exemplo mostrado anteriormente, a classe Cachorro n ao deveria poder ser instanciada, j a que n ao faz sentido criar objetos que representam c aes que n ao possuem uma ra ca. O fato do m etodo mostraRaca() denido nessa classe retornar uma mensagem de erro e um forte indicador desse fato. Pode-se modelar a hierarquia apresentada na Figura 4.29 de uma maneira mais natural usando o conceito de classe abstrata. Nessa abordagem, Cachorro e transformada em uma classe abstrata. Por em isso n ao e suciente, uma vez que essa deni c ao n ao garante a redeni c ao do m etodo mostraRaca() nas classes derivadas. Da conclui-se que tanto a classe Cachorro quanto a opera c ao mostraRaca() precisam ser declaradas como abstratas. Tendo em vista as modica c oes sugeridas no par agrafo anterior, cada classe derivada de C ao tem duas escolhas: (i) implementar o m etodo mostraRaca() tornando-se uma classe concreta, ou (ii) n ao implementar o m etodo mostraRaca(), tornando-se uma classe abstrata. Para as classes Boxer e Cocker faz sentido implementar mostraRa ca. Para a classe Schnauzer, entretanto, temos duas op c oes v alidas: (i) deni-la como uma classe concreta como anteriormente, ou (ii) n ao redenir o m etodo mostraRaca() e deixar que suas subclasses Miniatura e Padrao o fa cam. O trecho de c odigo seguinte mostra alguns exemplos de uso correto e incorreto da hierarquia modicada:
1 2 3 4 5 6
public s t a t i c void main ( S t r i n g a r g s [ ] ) { Cachorro apCao = new Cachorro ( ) ; // ERRO. C l a s s e a b s t r a t a . Schnauzer s = new Schnauzer ( ) ; // ERRO. C l a s s e a b s t r a t a . M i n i a t u r a m = new M i n i a t u r a ( ) ; // Ok . C l a s s e c o n c r e t a . m. mostraRaca ( ) ; // imprime Ra c a Schnauzer M i n i a t u r a }
4.6.4
Exemplo 2: Hierarquia de Figuras Gr acas
A Figura 4.30 mostra uma hierarquia para guras gr acas. A classe Figura e uma classe abstrata e estabelece uma sem antica para as classes derivadas a partir dela. Os m etodos mostra() e esconde()
129
s ao declarados como abstratos na classe Figura. As classes concretas Linha, Arco e Tri angulo implementam esses m etodos. O trecho de c odigo em Java a seguir mostra uma implementa c ao parcial da classe Figura:
Figura linha:. coluna:. +mostra():void +esconde():void +move(dr:int,dc:int):void {leaf} Classe abstrata
chama esconde() e mostra()
Linha extremos:. +mostra():void +esconde():void
Arco angulo:. +mostra():void +esconde():void
Triangulo altura:. +mostra():void +esconde():void
Figura 4.30: Hierarquia de Classes para Figuras Gr acas

1 2 3 4 5 6 7 8 9 10 11 12 13
abstract c l a s s F i g u r a { protected i n t l i n h a ; protected i n t c o l u n a ; public F i g u r a ( i n t r , i n t c ) { l i n h a = r ; c o l u n a = c ; } public a b s t a c t void mostra ( ) ; // a b s t r a t a
public void e s c o n d e ( ) ; // a b s t r a t a public f i n a l void moveAoRedor ( i n t dr , i n t dc ) { esconde ( ) ; l i n h a += dr ; c o l u n a += dc ; mostra ( ) ; } }
Note que o m etodo moveAoRedor() n ao e declarado como abstract na classe Figura. O motivo e que esse m etodo usa outros m etodos para executar as a c oes que dependem de implementa c oes espec cas de guras (como Linha, Arco e Triangulo). No exemplo, essas a c oes s ao materializadas pelos m etodos esconde() e mostra(). Al em disso, o m etodo moveAoRedor() e declarado como nal, indicando que e acoplado estaticamente. Por n ao poder ser redenido, esse m etodo representa um ponto de congelamento1 da hierarquia de classes. Por outro lado, os m etodos mostra() e esconde()
1
Do Ingl es frozen spot.
130
s ao chamados de pontos de adapta c ao2 da hierarquia de classes, pois s ao polim orcos e podem ser redenidos em diversos pontos da hierarquia.
4.7
Interfaces
Em geral, o conceito de interface dene uma fronteira que separa duas fases de um mesmo sistema. Uma fase, por sua vez, e denida como sendo uma parte homog enea pertencente a um sistema heterog eneo. Em sistemas computacionais, interfaces podem ser encontradas em diversos dom nios (Figura 4.31) , por exemplo: (i) interface humano-computador, que e a camada de um sistema respons avel pela fronteira entre o usu ario e os processos da aplica c ao; e (ii) interface de programa c ao ou API3 , que e uma camada composta por um conjunto de fun c oes que podem ser chamadas pelos programas aplicativos para usar os servi cos fornecidos pelo sistema operacional.
usurios interfaces homemcomputador programa aplicativo interfaces de programao sistema operacional sistema computacional
Figura 4.31: Exemplo de Interface em Sistemas Computacionais Em orienta c ao a objetos, uma interface e usada para denir um tipo que descreve o comportamento externamente vis vel de uma classe, objeto ou uma outra entidade. Sendo assim, uma interface especica um TAD atrav es da deni c ao de um conjunto de opera c oes e suas respectivas assinaturas de m etodos. No restante desta se c ao, focaremos nossa aten c ao no conceito de interface conforme denido por UML. As id eias apresentadas aqui s ao v alidas para qualquer linguagem que possibilite a representa c ao expl cita das interfaces, como por exemplo, C# ou Modula 3 e Java, que e uma das linguagens de programa c ao mais populares na qual o conceito de interface est a explicitamente materializado. A implementa c ao de um TAD especicado por uma interface e feita atrav es de uma classe. Uma classe pode implementar v arias interfaces e uma interface pode ser implementada por diversas classes. A tarefa de uma interface e separar de forma expl cita diferentes grupos de classes de uma aplica c ao, isto e, estabelecer fronteiras expl citas entre partes homog eneas de um sistema computacional heterog eneo. A Figura 4.32 mostra gracamente como isso pode ser feito. No caso (a), a classe Carro cont em uma refer encia direta para um objeto de tipo Motor1.0.
2 3
Do Ingl es hot spots. Do Ingl es Application Programming Interface

(a)
Carro motor :Motor1.0
131
(b)
Carro motor : Motor2.0
Cenrio de Evoluo
Motor1.0
Motor2.0
MotorGasolina1.0
MotorAlcool1.0
MotorGasolina2.0
MotorAlcool2.0
OBS.: A Classe Carro foi alterada.
Carro motor :IMotor
(c)
Carro motor :IMotor
<< interface >> IMotor
Cenrio de Evoluo
<< interface >> IMotor
Motor1.0
Motor1.0
Motor1.8
Motor2.0
...
MotorGasolina1.0 MotorAlcool1.0
...
...
OBS.: A Classe Carro no foi alterada
Figura 4.32: Uma Hierarquia de Classes e Interfaces Uma depend encia entre Carro e Motor1.0 e estabelecida. No caso (b), as classes Carro e Motor1.0 se acoplam atrav es de uma interface IMotor. Carro cont em uma refer encia para um objeto de tipo IMotor e as classes Motor1.0 e Motor2.0 implementam essa mesma interface IMotor. A depend encia entre Carro e Motor1.0 e reduzida, uma vez que Carro e capaz de operar com qualquer objeto do tipo IMotor, que pode ser instanciado a partir das classes Motor1.0 ou Motor2.0.
4.7.1
Relacionamento de Realiza c ao em UML
Uma interface UML cont em apenas assinaturas de m etodos e deni c oes de constantes. Uma caracter stica essencial e a aus encia de implementa c ao, tanto de m etodos quanto de estrutura de dados, isto e, atributos. Portanto, uma interface e, por deni c ao, abstrata e possui todas as suas opera c oes igualmente abstratas e com visibilidade p ublica. Uma classe, em contraste com uma interface, pode conter deni c oes de atributos, m etodos concretos e m etodos abstratos. Sendo assim, enquanto uma interface especica de forma expl cita um TAD, uma classe fornece a implementa c ao dessa especica c ao. Interfaces representam um n vel superior de abstra c ao em rela c ao ao das classes, isto e, pode-se projetar todas as interfaces de uma aplica c ao explicitamente antes de se decidir sobre a forma mais adequada de implementa c ao. Essa separa c ao entre o projeto de interface e o projeto de classes e an aloga ` a separa c ao entre o projeto arquitet onico e o projeto de engenharia de uma constru c ao civil.
132
A Figura 4.33 apresenta uma interface ICadastro implementada por duas classes diferentes, ListaCad1 e ArrayCad. Note que, em UML, uma interface e representada como uma classe com o estere otipo <<interface>>.
<<interface>> Cadastro
inserir() procurar() remover() <<realizes>> <<realizes>> ArrayCad
ListaCad1
Figura 4.33: Uma Interface Implementada por Duas Classes O trecho de c odigo abaixo exemplica a implementa c ao de uma mesma interface por duas classes diferentes, para as interfaces e classes da Figura 4.33. Caso uma classe implemente uma interface mas n ao forne ca uma implementa c ao para algum dos m etodos denidos por ela, o m etodo torna-se implicitamente abstrato nessa classe, e conseq uentemente, a classe se torna abstrata.
1 2 3
public i n t e r f a c e I C a d a s t r o { . . . } c l a s s ListaCad1 implements I C a d a s t r o { . . . } c l a s s ArrayCad implements I C a d a s t r o { . . . }
A Figura 4.34 apresenta uma classe ListaCad2, que implementa duas interfaces, I e ICadastro, e estende uma classe ListaEspecial.
<<interface>> Cadastro <<interface>> I ListaEspecial
<<realizes>>
<<realizes>> classe base ListaCad2
classe derivada
Figura 4.34: Uma Classe que Implementa Duas Interfaces e Estende Outra Classe O trecho de c odigo seguinte exemplica a implementa c ao de diversas interfaces por uma mesma classe.

1 2 3
133
public i n t e r f a c e Cadastro { . . . } public i n t e r f a c e I { . . . } public c l a s s ListaCad2 extends L i s t a E s p e c i a l implements I C a d a s t r o , I { . . . }
Em Java, uma classe pode herdar apenas de uma classe base (heran ca simples), mas pode implementar v arias interfaces. Essa pol tica impede que ambig uidades como as descritas na Se c ao 4.4.6 ocorram, j a que elas s ao causadas por implementa c oes conitantes de m etodos com as mesmas assinaturas.
4.7.2
Heran ca Simples e M ultipla entre Interfaces
Interfaces podem estender outras interfaces. Uma interface pode estender v arias interfaces e uma mesma interface pode ser estendida por v arias outras. A Figura 4.35 apresenta exemplos de heran ca simples e m ultipla entre interfaces.
Herana Simples <<interface>> I Herana Mltipla <<interface>> Relogio <<interface>> Calendario
<<interface>> J
<<interface>> RelogioCalendario
Figura 4.35: Heran ca Simples e M ultipla entre Interfaces Em Java, heran ca entre interfaces e indicada atrav es da palavra chave extends. O trecho de c odigo seguinte apresenta alguns exemplos de heran ca entre interfaces, baseado nos relacionamentos mostrados na Figura 4.35.
1 2
public i n t e r f a c e IMotor { . . . } public i n t e r f a c e I M o t o r E l e t r i c o extends IMotor { . . . } // heran c a s i m p l e s de interfaces
public i n t e r f a c e IMotorCombustao extends IMotor { . . . } // heran c a s i m p l e s de interfaces
4 5 6 7 8
public i n t e r f a c e R e l o g i o { . . . } public i n t e r f a c e C a l e n d a r i o { . . . } public i n t e r f a c e R e l o g i o C a l e n d a r i o extends R e l o g i o , C a l e n d a r i o { . . . } // heran ca m u l t i p l a de i n t e r f a c e s
Se uma interface IMotorCombustao estende uma interface IMotor, IMotorCombustao herda todas
134
as opera c oes denidas por IMotor. Conseq uentemente, uma classe concreta MotorGasolina que implemente IMotorCombustao deve fornecer implementa c oes para todas as opera c oes de ambas, IMotor e IMotorCombustao.
4.7.3
Exemplo 1 - Integra c ao Objeto-Relacional
Uma aplica c ao comum de interfaces em sistemas reais nos quais informa c oes s ao armazenadas em um banco de dados consiste em separar as camadas de dados e neg ocios, de modo que essas duas possam evoluir de maneira independente. Classes da camada de neg ocios s ao clientes da camada de dados e a usam para abstrair a maneira como os dados s ao armazenados. A Figura 4.36 apresenta essa organiza c ao.
GerenciadorDePublicacoes << interface >> RepositorioDePublicacoes + inserir (c:Publicacao ):void + procurar (tombo :String ):Publicacao + remover (c:Publicacao ):void + atualizar (c:Publicacao ):void
+ reservar (tombo :String ,quant :int ):void
Programa Principal RepDePublicacoesBDOO RepDePublicacoesBDRelacional
Publicacao
+ reservar (quant :int ):void
Figura 4.36: Separa c ao Expl cita Entre Camadas de Neg ocios e Dados O seguinte trecho de c odigo mostra a implementa c ao da classe CadastroDePublicacoes, levando em conta a estrutura denida pela Figura 4.36.
1 2 3 4 5 6 7 8 9 10 11
// a r q u i v o G e r e n c i a d o r D e P u b l i c a c o e s . j a v a public c l a s s G e r e n c i a d o r D e P u b l i c a c o e s { private R e p o s i t o r i o D e P u b l i c a c o e s r c ; // d e f i n i c a o de a t r i b u t o // do t i p o R e p o s i t o r i o D e P u b l i c a c o e s \\ public G e r e n c i a d o r D e P u b l i c a c o e s ( R e p o s i t o r i o D e P u b l i c a c o e s r ) { r c= r ; // r e c e b e r e f e r e n c i a de um o b j e t o c u j a c l a s s e // implementa a i n t e r f a c e R e p o s i t o r i o D e C o n t a s } void r e s e r v a r ( S t r i n g tombo , i n t quant ) { P u b l i c a c a o p = r c . p r o c u r a r ( tombo ) ; p . r e s e r v a r ( quant ) ;

12 13 14
135
rc . atualizar (p) ; } } // fim da c l a s s e G e r e n c i a d o r D e P u b l i c a c o e s
No c odigo acima, a classe GerenciadorDePublicacoes n ao faz refer encia a nenhuma classe que implemente a interface RepositorioDePublicacoes. Ao inv es disso, ela referencia apenas RepositorioDePublicacoes. Seu construtor recebe como par ametro um objeto que implementa a interface RepositorioDePublicacoes e esse objeto e usado pelo m etodo reservar(), independentemente de sua classe de implementa c ao. O trecho de c odigo seguinte mostra como a classe GerenciadorDePublicacoes pode ser usada, em conjunto com alguma implementa c ao de RepositorioDePublicacoes (no exemplo, RepDePublicacoesBDRelacional).
1 2 3 4
// a r q u i v o P r i n c i p a l . j a v a public c l a s s P r i n c i p a l { public s t a t i c void main ( S t r i n g a r g s [ ] ) { G e r e n c i a d o r D e P u b l i c a c o e s g e r P u b l i c a c o e s = new G e r e n c i a d o r D e P u b l i c a c o e s ( new
5 6 7 8 9 10
RepDePublicacoesBDRelacional ( ) ) ; g e r P u b l i c a c o e s . r e s e r v a r ( G157T , 1 ) ; ... } ... } // fim da c l a s s e P r i n c i p a l
Note que a implementa c ao de RepositorioDePublicacoes s o e conhecida no momento em que GerenciamentoDePublicacoes e instanciada (Linhas 4 e 5).
4.7.4
Exemplo 2 - Alternativa ` a Heran ca M ultipla de Classes
Interfaces podem ser usadas no lugar de heran ca m ultipla, em linguagens como Java, que n ao d ao suporte a esse recurso. O uso de interfaces nesses casos tem a vantagem de sempre produzir heran ca por comportamento, j a que todas as classes concretas que implementam uma interface devem oferecer implementa c oes para todos os m etodos denidos por essa interface. A Figura 4.37 apresenta uma hierarquia de classes que usa heran ca m ultipla. Nessa gura, a classe RetanguloCentrado herda de duas classes distintas: Retangulo e Centrado. A Figura 4.38 apresenta uma solu c ao alternativa, na qual a classe RetanguloCentrado estende Retangulo e implementa Centrado, que passa a ser uma interface. O trecho de c odigo seguinte apresenta as implementa c oes da interface Centrado e da classe RetanguloCentrado.
136

Figura area(){abstract} Centrado Retangulo setCentro() getCentroX() getCentroY() area()
RetanguloCentrado Classe Abstrata
Figura 4.37: Heran ca M ultipla Entre Classes

<<interface>> Centrado Retangulo setCentro() getCentroX() getCentroY()
area()
RetanguloCentrado setCentro() getCentroX() getCentroY()
Figura 4.38: Solu c ao em Java Usando Interfaces
1 2 3 4 5 6 7 8
public i n t e r f a c e Centrado { public void s e t C e n t e r ( double x , double y ) ; public double getCentroX ( ) ; public double getCentroY ( ) ; }
public c l a s s RetanguloCentrado extends Retangulo implements Centrado {

9 10 11 12 13 14 15 16 17 18 19 20 21
137
private double cx , cy ; // novos a t r i b u t o s public RetanguloCentrado ( double cx , double cy , double l a r g , double a l t ) { super ( l a r g , a l t ) ; // l a r g u r a e a l t u r a do r e t a n g u l o t h i s . cx = cx ; t h i s . cy = cy ; } public void s e t C e n t r o ( double x , double y ) { cx = x ; cy = y ; } public getCentroX ( ) { return cx ; } public getCentroY ( ) { return cy ; } }
Suponha que implementemos outras duas classes, CirculoCentrado e QuadradoCentrado, do mesmo modo que RetanguloCentrado. A classe Figura (Figura 4.37) e superclasse de Circulo, Quadrado e Retangulo. Cada classe derivada redene a opera c ao area() herdada do pai. A Figura 4.39 apresenta essa hierarquia.
Figura
area(){abstract}
Centrado <<interface>>
Retangulo area()
Circulo area()
Quadrado area()
<<realizes>> CirculoCentrado QuadradoCentrado
RetanguloCentrado
Figura 4.39: Uma Hierarquia de Figuras Geom etricas O seguinte trecho de c odigo utiliza a hierarquia mostrada na gura 4.39 para realizar algumas opera c oes com guras, abstraindo o tipo espec co da gura que e manipulada.
138
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

F i g u r a [ ] s h a p e s = new F i g u r a [ 3 ] ; // c r i a um a r r a y de r e f e r e n c i a s // para o b j e t o s do t i p o F i g u r a s h a p e s [ 0 ] = new RetanguloCentrado ( 1 . 0 , 1 . 0 , 1 . 0 , 1 . 0 ) ; s h a p e s [ 1 ] = new QuadradoCentrado ( 2 . 5 , 2 . 0 , 3 . 0 ) ; s h a p e s [ 2 ] = new C i r c u l o C e n t r a d o ( 2 . 3 , 4 . 5 , 3 . 4 ) ; double t o t a l A r e a = 0 ; double t o t a l D i s t a n c i a= 0 ; f o r ( i n t i =0; i < s h a p e s . l e n g t h ; i ++) { t o t a l A r e a += s h a p e s [ i ] . a r e a ( ) ; i f ( s h a p e s [ i ] instanceof Centrado ) { // e necess a r i o c a s t i n g do t i p o F i g u r a // para uma s u b c l a s s e do t i p o Centrado Centrado c = ( Centrado ) s h a p e s [ i ] ; double cx = c . getCentroX ( ) ; double cy = c . getCentroY ( ) ;
double t o t a l D i s t a n c e+= Math . s q r t ( cx cx + cy cy ) ; // f o r m u l a para c a l c u l a r a d i s t a n c i a da origem ( 0 , 0 ) // ao c e n t r o da f i g u r a ( cx , cy ) } // f e c h a o i f } // f e c h a o f o r System . out . p r i n t l n ( Area M e dia : + t o t a l A r e a / s h a p e s . l e n g t h ) ; System . out . p r i n t l n ( D i s t a n c i a M e dia : + t o t a l D i s t a n c e / s h a p e s . l e n g t h ) ;
Interfaces s ao tipos, tal como as classes. Quando uma classe implementa uma interface, inst ancias daquela classe podem ser atribu das ` as vari aveis do tipo da interface. Conseq uentemente, n ao e necess ario fazer casting de irm aos de RetanguloCentrado para Centrado, antes de chamarmos os m etodos setCentro(), getCentroX() ou getCentroY(). RetanguloCentrado implementa setCentro(), getCentroX() e getCentroY() e herda o m etodo area() da superclasse Retangulo. No exemplo, o casting foi necess ario porque o array shapes e do tipo Figura e essa classe n ao implementa Centrado.
4.7.5
Exemplo 3 - Classes, Interfaces e Tipos
Considere a hierarquia de classes da Figura 4.40. O trecho de c odigo seguinte cria objetos dos tipos C1, C2, C3 e C4 e realiza diversas atribui c oes v alidas.
1 2
C1 c1 = new C1 ( ) ; C2 c2 = new C2 ( ) ;

I1 I2 I4
139
I3 C1 <<realizes>> <<realizes>> C2 C4 <<realizes>>
C3
Figura 4.40: Uma Hierarquia Mais Complexa

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
C3 c3 = new C3 ( ) ; C4 c4 = new C4 ( ) ;
I 1 i 1 = c1 ; // c l a s s e C1 implementa a i n t e r f a c e I 1 I 1 i 1 = c2 ; // c l a s s e C2 implementa a i n t e r f a c e I 1 I 1 i 1 = c3 ; // c l a s s e C3 implementa a i n t e r f a c e I 1 I 2 i 2 = c1 ; // c l a s s e C1 implementa a i n t e r f a c e I 2 I 2 i 2 = c2 ; // c l a s s e C2 implementa a i n t e r f a c e I 2 I 2 i 2 = c3 ; // c l a s s e C3 implementa a i n t e r f a c e I 2 I 3 i 3 = c1 ; // c l a s s e C1 implementa a i n t e r f a c e I 3 I 3 i 3 = c2 ; // c l a s s e C2 implementa a i n t e r f a c e I 3 I 3 i 3 = c3 ; // c l a s s e C3 implementa a i n t e r f a c e I 3 I 4 i 4 = c4 ; // c l a s s e C4 implementa a i n t e r f a c e I 4 I 4 i 4 = c2 ; // c l a s s e C2 implementa a i n t e r f a c e I 4 I 4 i 4 = c3 ; // c l a s s e C3 implementa a i n t e r f a c e I 4
4.8
Pacotes em UML
As unidades b asicas de abstra c ao e encapsulamento, em orienta c ao a objetos, s ao os tipos abstratos de dados, representados por deni c oes de classes. A quantidade de classes numa aplica c ao real pode atingir facilmente a casa das centenas, ou mesmo milhares. Qualquer sistema dessa magnitude exige alguma forma de modulariza c ao que abstraia a maior parte da complexidade do sistema, agrupando
140
os seus elementos internos que podem ser vistos como unidades indivis veis, em n veis de abstra c ao mais elevados. Dois princ pios fundamentais regem a constru c ao de sistemas computacionais complexos: abstra c ao e modulariza c ao. Como visto nas Se c oes 1.2.2 e 1.1.1 do Cap tulo 1, abstra c oes nos permitem entender e analisar o problema concentrando-se nos aspectos relevantes e ignorando detalhes irrelevantes. Uma das formas mais ecazes de abstrair os detalhes indesejados de sistemas de software e atrav es da do desenvolvimento modular. A modulariza ca o nos permite projetar e construir um sistema computacional a partir de partes menores, chamados m odulos ou pacotes. No desenvolvimento modular, durante o projeto de constru c ao de um sistema, e criada uma estrutura de m odulos para o programa; se esses m odulos corresponderem ` as abstra c oes descobertas durante a an alise do problema, ent ao o sistema ser a mais facilmente compreendido e gerenciado. Dada a sua import ancia, a fase de projeto de software tem como um de seus objetivos encontrar uma decomposi c ao modular que seja adequada para a implementa c ao do sistema. Uma decomposi c ao modular e considerada boa quando ela e composta por m odulos que sejam independentes o m aximo poss vel uns dos outros, isto e, que haja um fraco acoplamento entre os m odulos. Para isso, cada m odulo deve esconder uma decis ao particular de projeto; de forma que, se essa decis ao for mudada, apenas o m odulo que conhece a decis ao tomada ser a modicado. Os outros m odulos permanecem inalterados. Para que isso seja poss vel, uma decomposi c ao modular (ou fatora c ao) de boa qualidade deve proporcionar um fraco acoplamento entre os diferentes pacotes e alta coes ao entre os elementos de um mesmo pacote. Quando um projeto e composto por m odulos altamente independentes entre si, esses m odulos podem ser utilizados como unidade para atribui c ao de trabalho entre os membros do time de programa c ao. Al em disso, como discutido na Se c ao 1.5.3 do Cap tulo 1, a exist encia de elementos independentes entre si facilita as atividades de manuten c ao do sistema, uma vez que os efeitos das modica c oes s ao restritos a m odulos individuais. Um exemplo dessa estrutura pode ser visto na Figura 4.41, que apresenta duas aplica c oes (sistemaBibliotecas e controleDados). Nela, as pastas representam pacotes, enquanto os ret angulos correspondem a classes na sua vis ao simplicada (ver Se c ao 1.3.2 do Cap tulo 1). A aplica c ao sistemaBibliotecas e composta pelas classes Publicacao, Controlador, Livro e Periodico e pelo pacote reservas, que e utilizado pela classe Publicacao; o pacote reservas e composto pelas classes Rerserva e Controlador. Sobre a aplica c ao controleDados, sabe-se apenas que ela e utilizada pelos dois controladores da aplica c ao sistemaBibliotecas, a sua complexidade interna foi totalmente abstra da.
sistemaBibliotecas controleDados Controlador
Publicacao
reservas Reserva Controlador
Livro
Periodico
Figura 4.41: Exemplo de Organiza c ao em Pacotes
141
Em Java, um pacote e representado por um diret orio do sistema de arquivos, que e utilizado para armazenar o c odigo da aplica c ao, inclusive outros pacotes subordinados hierarquicamente (subdiret orios). Todas as deni c oes de tipo contidas num pacote precisam identicar a hierarquia completa de pacotes que o cont em, que em Java e indicado atrav es da palavra reservada package. O trecho de c odigo seguinte mostra as declara c oes dos pacotes feitas em cada uma das classes apresentadas na Figura 4.41.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
// a r q u i v o s i s t e m a B i b l i o t e c a s / P u b l i c a c a o . j a v a package s i s t e m a B i b l i o t e c a s ; // P e r t e n c e ao p a c o t e s i s t e m a B i b l i o t e c a s . ...
// a r q u i v o s i s t e m a B i b l i o t e c a s / C o n t r o l a d o r . j a v a package s i s t e m a B i b l i o t e c a s ; // P e r t e n c e ao p a c o t e s i s t e m a B i b l i o t e c a s . ...
// a r q u i v o s i s t e m a B i b l i o t e c a s / L i v r o . j a v a package s i s t e m a B i b l i o t e c a s ; // P e r t e n c e ao p a c o t e s i s t e m a B i b l i o t e c a s . ...
// a r q u i v o s i s t e m a B i b l i o t e c a s / P e r i o d i c o . j a v a package s i s t e m a B i b l i o t e c a s ; // P e r t e n c e ao p a c o t e s i s t e m a B i b l i o t e c a s . ...
// a r q u i v o s i s t e m a B i b l i o t e c a s / r e s e r v a s / Reserva . j a v a package s i s t e m a B i b l i o t e c a s . r e s e r v a s ; // P e r t e n c e ao p a c o t e r e s e r v a s , que ... // p e r t e n c e ao p a c o t e s i s t e m a B i b l i o t e c a s .
// a r q u i v o s i s t e m a B i b l i o t e c a s / r e s e r v a s / C o n t r o l a d o r . j a v a package s i s t e m a B i b l i o t e c a s . r e s e r v a s ; // P e r t e n c e ao p a c o t e r e s e r v a s , que ... // p e r t e n c e ao p a c o t e s i s t e m a B i b l i o t e c a s .
Em algumas linguagens, como C# [24], pacotes s ao conhecidos como espa cos de nomes (do ingl es namespaces). Essa nomenclatura e coerente, j a que classes com o mesmo nome podem ser empregadas em um mesmo sistema, atrav es do uso de pacotes. No exemplo acima h a duas classes com nome Controlador, mas n ao h a perigo das duas serem confundidas, j a que pertencem a pacotes (espa cos de nomes) distintos.
142
4.8.1
Visibilidade de Classes, Atributos e Opera c oes
As Se c oes 4.1.4 e 4.4.2 apresentaram os conceitos de visibilidade p ublica (+), privada (-) e protegida (#), que podem ser utilizadas em atributos e opera c oes das classes. Com o conceito de pacotes, surge a necessidade de se ter mais um n vel de visibilidade: a visibilidade de pacote (). As classes, atributos e m etodos declarados com visibilidade de pacote s ao acess veis por todas as classes dentro de um mesmo m odulo. Em Java, a visibilidade de pacote e indicada pela aus encia de todos os outros indicador de visibilidade: public, private ou protected. Em UML e poss vel representar gracamente as quatro visibilidades apresentadas. A Figura 4.42 mostra um exemplo dessa representa c ao em uma classe. Como pode ser visto, cada m etodo ou atributo pode ser precedido por um s mbolo que indica a sua visibilidade: + visibilidade p ublica; - visibilidade privada; # visibilidade protegida; e visibilidade de pacote.
Classe atributo1:TipoAtrib1 #atributo2:TipoAtrib2 ~atributo3:TipoAtrib3 operao pblica operao protegida operao privada operao com visibilidade de pacote +operacao1():TipoResposta #operacao2():TipoResposta operacao3():TipoResposta ~operacao4():TipoResposta atributo privado atributo protegido atributo com visibilidade de pacote
Figura 4.42: Visibilidade de atributos e opera c oes em UML
Em UML, para que uma classe contida num pacote possa ser utilizado por classes de outros pacotes, deve ser denida com visibilidade p ublica. Se isso n ao for feito, a classe s o ser a vis vel para as classes dentro do mesmo pacote, cando invis veis at e mesmo para as classes de seus subpacotes. Por exemplo, se a classe Publicacao da Figura 4.41 n ao for declarada como p ublica, ela s o ser a vis vel para as classes Livro, Periodico e Controlador do pacote sistemaBibliotecas (ou simplesmente sistemaBibliotecas.Controlador). A Figura 4.43 mostra a hierarquia de pacotes apresentada na Figura 4.41 do ponto de vista de um observador externo, assumindo que as u nicas classes p ublicas s ao sistemaBibliotecas.Controlador e sistemaBibliotecas.reservas.Controlador.

sistemaBibliotecas reservas Controlador Controlador
143
Observador Externo
+ listarPublicacoes ():void + reservarPublicacao (tombo :String ):void + cancelarReservaPublicacao (tombo :String ):void
+ criarReserva (pub :Publicacao ):Reserva + cancelarReserva (codReserva :String ):void
Figura 4.43: Exemplo de Visibilidade de Pacote em UML
4.9
Relacionamento de Delega c ao
4.9.1
Sistemas baseados em Delega c ao
No modelo de objetos, o mecanismo de heran ca permite compartilhamento de comportamento (do ingl es: behaviour sharing), isto e, reutiliza c ao de opera c oes, entre classes derivadas e classes bases. O mecanismo de heran ca n ao e aplicado a objetos individualmente; entretanto, existe um mecanismo chamado de delega c ao, parecido com o de heran ca, que tamb em permite compartilhamento de comportamento, mas que opera diretamente entre objetos, n ao entre classes. Nas linguagens de programa c ao baseadas no mecanismo de delega c ao, tais como Self [47] e Actor [30], objetos s ao vistos como prot otipos ou exemplares. Os prot otipos t em o papel de delegadores ao delegarem seu comportamento para prot otipos relacionados chamados de delegados. Sistemas baseados em delega c ao, em geral, n ao t em como foco principal a estrutura c ao baseada em classes. O relacionamento de delega-para entre um delegador e um delegado pode ser estabelecido dinamicamente enquanto que o relacionamento de heran ca de linguagens baseadas em classes, tais como C++ e Java, e estabelecido e estaticamente xado quando a classe e criada. Todos os objetos de uma classe t em uma mesma estrutura e compartilham um comportamento comum. Como conseq u encia, altera c oes efetuadas nos m etodos e estrutura de uma classe, podem ser automaticamente passadas para todas as suas inst ancias. Este mecanismo impl cito de propaga c ao de altera c oes permite que sistemas computacionais possam ser modicados com base em grupos/classes. Portanto, linguagens baseadas em classes usam um compartilhamento de comportamento est atico e baseado em grupos, constratando com as linguagens baseadas em delega c ao que proporcionam um compartilhamento de comportamento din amico e basedo em prot otipos (objetos).
144
4.9.2
Delega c ao versus Heran ca
Em sistemas baseados em delega c ao, as distin c oes entre classes e objetos s ao removidas. Na verdade, a no c ao de classes e eliminada, cando apenas a no c ao de objetos, no caso, chamado de prot otipos. O desenvolvedor inicialmente identica um conjunto de prot otipos, e depois descobre similaridades e/ou diferen cas com outros objetos. Dentro dessa nova concep c ao, um objeto antigo pode tornar-se um prot otipo para um objeto rec em-descoberto. A id eia e come car com casos particulares, e depois generaliz a-los ou especializ a-los. Por exemplo, suponha que um desenvolvedor inicialmente identique um objeto retangular, e, em seguida, ele identique um objeto quadrado. Nesse caso, podemos dizer que o quadrado se parece com um ret angulo. Suponha ainda que posteriormente o desenvolvedor identique um outro quadrado cujo tamanho seja maior do que o primeiro quadrado. Num sistema baseado em prot otipos, podemos denir o ret angulo como sendo o prot otipo para a cria c ao do primeiro quadrado. Similarmente, o primeiro quadrado pode ser denido como o prot otipo de cria c ao para o segundo quadrado. Vale ressaltar, que nessa nova concep c ao, a no c ao de classe, a partir da qual um objeto e criado, n ao existe. Seja ret1 o prot otipo ret angulo, qua1 o prot otipo primeiro quadrado e qua2 o prot otipo segundo quadrado (Figura 4.44). O prot otipo ret1 tem opera c oes, tais como, mover(), rotacionar(), e reajustarTamanho(), e tamb em opera c oes de inspe c ao de atributos, como por exemplo, getCentro(), getPerimetro() e getRazao(), que retornam valores relativos aos atributos centro, lado e altura.
ret1:Ret1 lado = 5 :int altura = 3 :int centro = 10,25 :int[2] + mover (x :int ,y:int ):void + rotacionar (graus :int ):void + reajustarTamanho (larg :int ,alt :int ):void + getCentro ():int[2] + getPerimetro ():int + getRazao ():float qua1:Quad1 delega para << use . >> lado = 4 :int altura = 4 :int centro = 15,30 :int[2] + reajustarTamanho (larg :int ,alt :int ):void delega para << use >> . qua2:Quad2 lado = 3 :int altura = 3 :int centro = 0,0 :int[2]
Figura 4.44: Exemplo de Prot otipos Geom etricos O prot otipo qua1 e similar ao prot otipo ret1; a u nica diferen ca s ao os valores dos atributos centro, lado e altura. O objeto qua1 tem uma associa c ao de delega-para com o objeto ret1. Isto signica que os atributos e opera c oes que n ao s ao redenidos em qua1 ser ao herdados de ret1. No nosso exemplo, a opera c ao reajustarTamanho() foi redenida no prot otipo qua1, signicando que sua execu c ao n ao ser a delegada para ret1. Portanto, qua1 delega a execu c ao de mensagens, como por exemplo rotacionar(), para o seu objeto delegado ret1. No entanto, vale ressaltar que quando a opera c ao rotacionar() e executada no prot otipo ret1, essa opera c ao utiliza o estado do objeto qua1, isto e, o receptor inicial da mensagem. De forma similar, qua2 delega todas as suas mensagens recebidas para qua1. Por exemplo, se qua2 recebe a mensagem mover(), ela ser a inicialmente delegada para qua1. Desde que a mensagem n ao pode ser executada por qua1, ela ser a delegada para o objeto ret1. Entretanto, quando a
145
qua2:Quad2
qua1:Quad1
ret1:Ret1
1: mover(18,33)
2 : mover(18,33) 3 : mover(18,33) Altera o estado do objeto "qua2" 4 : ok 5 : ok
6: ok
Figura 4.45: Delega c ao de mensagens entre prot otipos opera c ao mover() for executada no prot otipo ret1, ela acessar a o estado do objeto qua2, o receptor inicial da mensagem. A Figura 4.45 mostra a sequ encia de delega c ao da mensagem mover(). O exemplo dos prot otipos geom etricos pode ser remodelado usando a no c ao de classes atrav es da cria c ao de uma superclasse Ret1, que possui a subclasse Quad1, que por sua vez e superclasse de Quad2. Al em disso, os objetos ret1, qua1 e qua2 devem ser instanciados (Figura 4.46). Nesse modelo, quando o objeto qua1 recebe a mensagem rotacionar(), a busca pela opera c ao se inicia pela classe Quad2. Como ela n ao e encontrada, a busca continua na superclasse Quad1, e persistindo a aus encia, continua na superclasse Ret1, exatamente como no caso dos prot otipos baseados em delega c ao. Quando a opera c ao e encontrada na classe Ret1, ela e executada no estado do objeto qua2, o receptor inicial da mensagem. As linguagens baseadas em delega c ao implementam implicitamente o mecanismo de delega c ao entre prot otipos, da mesma forma que o mecanismo de heran ca entre classes e implicitamente implementado em linguagens basedas em classes atrav es do relacionamento de generaliza c ao/especializa c ao entre classes. Entretando, o mecanismo de delega c ao e mais gen erico do que o mecanismo de heran ca, no sentido que o mecanismo de delega c ao pode simular o mecanismo de heran ca, mas n ao vice-versa. Em sistemas baseados em delega c ao, a lista de delegados de um prot otipo pode conter zero ou muitos delegados, que podem ser alterados dinamicamente.
4.9.3
Delega c ao em Sistemas Basedos em Classes
Compartilhamento de comportamento pode ser obtido pelo menos de duas formas diferentes: (i) compartilhamento baseado em classes (mecanismo de heran ca) e (ii) compartilhamento baseado em prot otipos/objetos (mecanismo de delega c ao), como discutido nas se c oes 4.9.1 e 4.9.2. Embora heran ca e delega c ao sejam geralmente denidas como solu c oes alternativas no projeto de sistemas orientados a objetos, delega c ao pode ser simulada em linguagens baseadas em classes de forma sf ad hoc. Essa implementa c ao de delega c ao em sistemas baseados em heran ca e uma forma de implementar
146
Ret1 lado :int altura :int centro :int[2] << instance_of . >> + mover (x :int ,y:int ):void + rotacionar (graus :int ):void + reajustarTamanho (larg :int ,alt :int ):void + getCentro ():int[2] + getPerimetro ():int + getRazao ():float

ret1:Ret1 lado = 5 :int altura = 3 :int centro = 10,25 :int[2] + mover (x :int ,y:int ):void + rotacionar (graus :int ):void + reajustarTamanho (larg :int ,alt :int ):void + getCentro ():int[2] + getPerimetro ():int + getRazao ():float qua1:Quad1 Quad1 lado :int altura :int centro :int[2] + reajustarTamanho (larg :int ,alt :int ):void . << instance_of >> lado = 4 :int altura = 4 :int centro = 15,30 :int[2] + mover (x :int ,y:int ):void + rotacionar (graus :int ):void + reajustarTamanho (larg :int ,alt :int ):void + getCentro ():int[2] + getPerimetro ():int + getRazao ():float qua2:Quad2 << instance_of >> lado = 3 :int . altura = 3 :int centro = 0,0 :int[2] + mover (x :int ,y:int ):void + rotacionar (graus :int ):void + reajustarTamanho (larg :int ,alt :int ):void + getCentro ():int[2] + getPerimetro ():int + getRazao ():float
Quad2 lado :int altura :int centro :int[2]
Figura 4.46: Figuras Geom etricas baseadas em Classes
compartilhamento de comportamento quando um objeto precisa, por exemplo, ser capaz de alterar suas respostas para pedidos de servi cos em tempo de execu c ao. A natureza do mecanismo de heran ca e est atica e relacionada com classes enquanto que a natureza do mecanismo de delega c ao e din amica e concentrada em objetos, o que traz certa exibilidade para o sistema. A principal vantagem de delega c ao sobre heran ca e que delega c ao facilita a mudan ca de implementa c ao de opera c oes em tempo de execu c ao. A maioria das linguagens baseadas em classes n ao permitem que objetos mudem de classes pois eles estariam alterando os seus tipos em tempo de execu c ao; entretanto, e f acil mudar o delegado de um objeto sem necessariamente isso implicar numa mudan ca de grupo. Al em disso, uma linguagem baseada em classes com verica c ao est atica de tipos pode garantir que um delegado entender a todas as mensagens delegadas pelo delegador. Portanto, delega c ao e compat vel com verica c ao est atica de tipos presumindo-se que todos os delegados sejam conhecidos em tempo de compila c ao. Em tempo de execu c ao, existe a escolha de qual delegado ser a ativado. Portanto, delega c ao pode ser vista como uma t ecnica de projeto alternativa que pode ser usada em qualquer linguagem orientada a objetos baseada em classes, incluindo aquelas que s ao estaticamente tipadas.
147
4.9.4
O Padr ao Delega c ao para Sistemas baseados em Classes
Motiva c ao Em sistemas orientados a objetos convencionais baseados em classes, que usam o mecanismo de heran ca, todas as inst ancias de uma determinada classe devem seguir o mesmo padr ao de comportamento. Uma vez que um objeto e criado, ele est a permanentemente ligado ao comportamento estabelcido para o grupo ao qual ele pertence. Muitas entidades do mundo real exibem diferentes tipos de comportamentos em diferentes est agios de vida, em particular, depedendo se a entidade est a operando corretamente ou n ao. E desej avel encontrar meios atrav es dos quais objetos que representam tais entidades possam realizar tais mudan cas de comportamento de forma expl cita documentada no projeto do sistema. Outra restri c ao de modelar um sistema apenas baseado no conceito de classe, e que muitas vezes n ao e claro ou mesmo n ao e conhecido no in cio da concep c ao do sistema, todos os diferentes grupos existentes no dom nio do problema para que todas as classes sejam criadas inicialmente. O desenvolvedor gostaria de reutilizar comportamentos j a implementados por outros prot otipos sem ter a obriga c ao de garantir que o relacionamento de generaliza c ao/especializa c ao e verdadeiro. Solu c ao Como ilustrado na Figura 4.47, delega c ao pode ser implementada numa linguagem baseada em classes atrav es da inclus ao do receptor original (isto e, o objeto delegador) como um par ametro extra para cada mensagem delegada para o objeto delegado.
Delegador * operacao: delegado.operacao(this); delega para . >> << use + operacao ():void + operacao (ref :Delegador ):void Delegado
Figura 4.47: Implementa c ao de Delega c ao em Linguagens Baseadas em Classes Consequ encias A implementa c ao do padr ao de delega c ao numa linguagem baseda em classe requer, portanto, um esfor co extra por parte do desenvolvedor pois: (i) o objeto delegador e os seus objetos delegados devem ser estaticamente denidos (isto e, n ao existiria cria c ao din amica de delegados a princ pio), e (ii) um objeto delegado ao receber uma mensagem delegada, utiliza o par ametro extra com a refer encia do receptor inicial da mensagem para realizar opera c oes no estado do delegador. O padr ao acima pode ser recursivamente aplicado, no sentido de que um objeto delegado pode assumir o papel de delegador e ter sua pr opria lista de delegados, e assim por diante. Em linguagens baseadas em delega c ao, essa no c ao mais geral de v arios n vies de delegadores e explorada, conforme explicado na se c ao 4.9.1. O leitor deve se lembrar, entretanto, que a refer encia a ser repassada para a cadeia de delegados armazena a refer encia para o receptor original da mensagem, isto e, o delegador inicial. De forma geral, existe um delegador inicial que recebe a mensagem inicialmente e
148
um conjunto de delegadores intermedi arios que repassam a execu c ao da mensagem at e que o c odigo da opera c ao seja encontrado. Linguagens basedas em delega c ao implementam este n vel extra de indire c ao de forma transparente. Portanto, o programador pode facilmente implementar mudan cas de comportamento de entidades do mundo real atrav es da delega c ao de opera co es para os diferentes delegados representando os diferentes comportamentos que a entidade externa pode ter. Entretanto, n ao existe garantia de que os diversos delegados representando os diferentes estados l ogicos de uma entidade externa sejam aderentes a uma mesma especica c ao (geralmente n ao existe verica c ao est atica de tipos). Em outras palavras, linguagens baseadas em delega c ao enfatizam exibilidade, isto e, d ao suporte para mudan cas em tempo de execu c ao baseando-se em verica c ao din amica de tipos.
4.9.5
Uma Aplica c ao do Padr ao Delega c ao
Problema O estudo dos aspectos din amicos de entidades no dom nio do problema nos leva a avaliar o comportamento de um objeto atrav es do tempo. Quando n os consideramos o comportamento de entidades no mundo real, n os observamos que elas geralmente tem um ciclo de vida. Desde que todas as inst ancias de uma classe devem seguir as mesmas regras de comportamento, quando n os abstraimos um grupo de entidades similares no dom nio do problema em objetos correspondentes no dom nio da solu c ao, n os tamb em abstraimos o seu comportamento comum. Muitas vezes entidades no mundo real exibem diferentes fases de comportamento durante o seu ciclo de vida. Por exemplo, uma borboleta come ca a vida como uma caterpilar, depois muda para uma cris alida e nalmente se transforam numa borboleta adulta. O termo estado l ogico e aplicado para cada fase de comportamento observ avel da borboleta, isto e, caterpilar, cris alida e borboleta adulta. Num dado momento, diferentes inst ancias de uma classe podem estar em estados l ogicos diferentes. O estado l ogico de uma inst ancia em particular e chamado de bf estado l ogico corrente. Entretanto, a implementa c ao do comportamento e diferente nesses tr es estados l ogicos. Por exemplo, uma oper c ao como mover() precisa ser implementada de pelo menos duas formas distintas quando a borboleta e ainda caterpilar e depois quando ela se transforma em adulta. Em geral, os estados l ogicos s ao informa c oes obtidas na fase de an alise, e linguagens de programa c ao baseadas em classes na maioria das vezes for cam que a informa c ao sobre estados desej l ogicos que escondida na implementa c ao dos m etodos de um objeto. E avel encontrar uma forma expl cita de representar estados l ogicos ao inv es de adotar uma abordagem de representa c ao impl cita atrav es do uso de comandos condicionais. Em algumas situa c oes, o comportamento de um objeto depende do seu estado e esse comportamente precisa ser modicado em tempo de execu c ao, quando esse estado interno muda. Normalmente, esse problema e resolvido atrav es de m etodos que usam comandos condicionais para decidir qual comportamento deve ser adotado, dependendo do estado do objeto. Essa abordagem n ao e recomendada, por em, porque c odigo pode ser repetido em v arios m etodos (tanto c odigo relativo
149
`s condi a c oes quanto ao comportamento). Al em disso, um n umero grande de condi c oes complexas torna o c odigo dos m etodos muito dif cil de entender e manter. Exemplo Motivador Para ilustrar nossas id eias considere o problema t pico de um sistema de controle de bibliotecas bem simples: Uma biblioteca tem um conjunto de usu arios. Suponha que existe esses usu arios possam reservar publica c oes, de tal modo que uma publica c ao reservada n ao possa ser reservada por outro usu ario. Al em disso, o usu ario pode a qualquer cancelar a sua reserva a qualquer momento. Por em, se a publica c ao estiver bloqueada por algum professor, isso implica que a sua utiliza c ao e exclusivamente para consulta dentro da biblioteca, n ao sendo poss vel efetuar reservas. Primeira Solu c ao Uma solu c ao poss vel e representar os estados l ogicos de um objeto Publicacao dentro dos atributos da pr opria classe. Mudan cas nos valor desses atributos s ao detectados por comandos condicionais.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
class Publicacao { double s t a t u s ; // 0 : d i s p o n i v e l ; 1 : r e s e r v a d a , 2 : b l o q u e a d a
public r e s e r v a r ( ) { ... i f ( s t a t u s = 0) { // r e a l i z a r a r e s e r v a } else { // i m p r i m i r uma mensagem de a v i s o : o p e r a c a o i n d i s p o n vel }
public c a n c e l a r R e s e r v a ( ) { i f ( s t a t u s == 1 ) status = 0; } } }
Segunda Solu c ao
150
Uma solu c ao alternativa e elimar os comandos condicionais inseridos na implementa c ao das opera c oes da classe Publicacao (Figura 4.48). A cria c ao de tipos PublicacaoDisponivel, PublicacaoReservada e PublicacaoBloqueada substitui o atributo agNormal que guarda uma informa c ao de tipo na proposta da primeira implementa c ao.
Publicacao
+ reservar ():void + cancelarReserva ():void
PublicacaoDisponivel
PublicacaoReservada
PublicacaoBloqueada
Figura 4.48: Representa c ao Expl cita dos Estados da Publica c ao Nessa solu c ao, as opera c oes reservar() e cancelarReserva() est ao redenidas nas classes PublicacaoDisponivel, PublicacaoReservada e PublicacaoBloqueada. Essa solu c ao captura o relacionamento entre as diferentes informa c oes sobre uma publica c ao, mas apresenta pelo menos duas limita c oes: 1. Linguagens orientadas a objetos da escola escandinava, como Java e C++, n ao permitem que objetos mudem de classes. Isto implica que quando um objeto publicacao muda de estado, por exemplo, de PublicacaoDisponivel para PublicacaoReservada, um novo objeto deve ser criado e o antigo objeto PublicacaoDisponivel deve ser destru do. Entretanto, essa opera c ao de destrui c ao e cria c ao para sistemas complexos pode ser bem custosa pois as identidades desses objetos n ao s ao mantidas ao longo dos seus ciclos de vida. Este problema e crucial se outros objetos do sistema mant em refer encias para objetos antigos. Uma poss vel solu c ao e criar uma tabela contendo refer encias para todos os objetos mutav eis. Outra solu c ao e manter uma lista de depend encias dos objetos que referenciam objetos mut aveis. Portanto, quando a identidade do objeto muda, e poss vel avisar todos os objetos que devem ser atualizados. Essa solu c ao est a documentada no padr ao Observer [19]. 2. As classes PublicacaoDisponivel, PublicacaoReservada e PublicacaoBloqueada n ao s ao realmente subtipos de publica c ao, mas sim estados conceituais separados pertencentes a uma mesma abstra c ao. Na verdade, os estados l ogicoa de uma publica c ao podem ser classicados como dispon vel, reservada, e bloqueada, e n ao a publica c ao propriamente dita. Terceira Solu c ao: o padr ao de projeto state O padr ao de projeto state permite que um objeto altere seu comportamento quando seu estado interno muda. Ele usa o mecanismo de delega c ao e o relacionamento de agrega c ao para
151
Contexto
EstadoAbstrato
+operacao():.
+operacao(c:Contexto):.
EstadoConcreto1 ... +operacao(c:Contexto):.
EstadoConcreto2
+operacao(c:Contexto):.
Figura 4.49: Estrutura do Padr ao de Projeto State lidar com situa c oes em que um objeto precisa se comportar de maneiras diferentes em diferentes circunst ancias. Sendo assim, a terceira solu c ao consiste em criar classes que encapsulam os diferentes estados l ogicos do objeto conta e os comportamentos associados a esses estados. Dessa forma, a complexidade do objeto e quebrada em um conjunto de objetos menores e mais coesos. A Figura 4.49 mostra a estrutura geral do padr ao State. Na Figura 4.49, a classe Contexto dene objetos cujos estados s ao decompostos em diversos objetos diferentes denidos por subtipos da classe abstrata Estado. A classe Estado dene uma interface unicada para encapsular o comportamento associado a um estado particular de de um objeto do tipo Contexto. Um objeto do tipo Contexto mant em uma refer encia para uma inst ancia de uma subclasse concreta de Estado e, para cada estado de Contexto, e denida uma subclasse EstadoConcreto de Estado que implementa o comportamento associado a esse estado. Um objeto Contexto delega requisi c oes dependentes de estado para o objeto EstadoConcreto atual, de acordo com o padr ao delega c ao da se c ao4.9.4. A classe Contexto passa uma refer encia de si pr opio como argumento para o objeto do tipo Estado respons avel por tratar a requisi c ao. Clientes podem congurar um contexto com objetos do tipo Estado. Uma vez que isso seja feito, por em, esses clientes passam a se comunicar apenas com o objeto do tipo Contexto e n ao interferem mais com seu estado. Consequ encias O padr ao state tem as seguintes consequ encias: Localiza o comportamento dependente de estado e particiona o comportamento relativo a diferentes estados. O padr ao substitui uma classe Contexto complexa por uma classe Contexto muito mais simples e um conjunto de subclasses de Estado altamente coesas.
152
Torna transi c oes de estado expl citas, ao inv es de espalh a-las em comandos condicionais. Torna o estado de um objeto compartilh avel, caracterizando uma quebra de encapsulamento entre a classe Contexto e a classe Estado. O padr ao state aplicado na hierarquia de publica co es A Figura 4.50 apresenta a aplica c ao do padr ao state no contexto da hierarquia de publica c oes. Perceba que do ponto de vista de quem est a fora do pacote, a u nica classe vis vel e a classe Publicacao. Mesmo assim, as opera c oes defineEstadoDisponivel(), defineEstadoReservada() e defineEstadoBloqueada() n ao s ao vis veis externamente ao pacote publicacao.
Publicacao a nica classe pblica do pacote "publicacao" publicacao Publicacao numeroTombo :String nome :String << create >> + Publicacao (numTomb :String ,nome :String ):Publicacao + imprimir ():void + reservar ():void + cancelarReserva ():void ~defineEstadoDisponivel ():void ~defineEstadoReservada ():void ~defineEstadoBloqueada ():void ~reservar (ref :Publicacao ):void ~cancelarReserva (ref :Publicacao ):void EstPublicacao
EstPublicacaoReservada
~reservar (ref :Publicacao ):void ~cancelarReserva (ref :Publicacao ):void EstPublicacaoDisponivel EstPublicacaoBloqueada
~reservar (ref :Publicacao ):void ~cancelarReserva (ref :Publicacao ):void
~reservar (ref :Publicacao ):void ~cancelarReserva (ref :Publicacao ):void
Figura 4.50: Padr ao state Aplicado na Hierarquia de Publica c oes A seguir, e apresentada a implementa c ao em Java do modelo apresentado na Figura 4.50.
1 2 3 4 5
// P u b l i c a c a o . j a v a package p u b l i c a c a o ; public c l a s s P u b l i c a c a o { // C o n s t a n t e s private s t a t i c E s t P u b l i c a c a o D i s p o n i v e l e s t D i s p o n i v e l = new EstPublicacaoDisponivel () ;
private s t a t i c E s t P u b l i c a c a o R e s e r v a d a e s t R e s e r v a d a = new E s t P u b l i c a c a o R e s e r v a d a ( ) ;
private s t a t i c E s t P u b l i c a c a o B l o q u e a d a e s t B l o q u e a d a = new E s t P u b l i c a c a o B l o q u e a d a ( ) ;
8 9
// A t r i b u t o s ...

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
153
// A s s o c i a c o e s private E s t P u b l i c a c a o e s t a d o ;
// Opera c o es ... public r e s e r v a r ( ) { e s t a d o . r e s e r v a r ( t h i s ) } public c a n c e l a r R e s e r v a ( ) { e s t a d o . c a n c e l a r R e s e r v a ( ) }
c l a s s abstract E s t P u b l i c a c a o extends Conta { public d e b i t a r ( f l o a t qtde ) { // r e a l i z a r o saque
i f ( saldo = 0) { // t r a n s i c a o de ContaNormal para ContaAnormal , // elimando o o b j e t o do t i p o // ContaNormal e c r i a n d o um o b j e t o ContaAnormal } } }
// E s t P u b l i c a c a o . j a v a package p u b l i c a c a o ; import p u b l i c a c a o . P u b l i c a c a o ; public abstract c l a s s E s t P u b l i c a c a o { // Opera c o es public P u b l i c a c a o p u b l i c a c a o ; abstract void r e s e r v a r ( P u b l i c a c a o r e f ) ; abstract void c a n c e l a r R e s e r v a ( P u b l i c a c a o r e f ) ; }
// E s t P u b l i c a c a o D i s p o n i v e l . j a v a package p u b l i c a c a o ; public c l a s s E s t P u b l i c a c a o D i s p o n i v e l extends p u b l i c a c a o . E s t P u b l i c a c a o { // Opera c o es void r e s e r v a r ( P u b l i c a c a o r e f ) { r e f . d e f i n e E s t a d o R e s e r v a d a ( ) ; } void c a n c e l a r R e s e r v a ( P u b l i c a c a o r e f ) { System . out . p r i n t l n ( A p u b l i c a c ao j a est a d i s p o n vel ) ;}
154
46 47 48 49 50 51 52
// E s t P u b l i c a c a o R e s e r v a d a . j a v a package p u b l i c a c a o ; public c l a s s E s t P u b l i c a c a o R e s e r v a d a extends p u b l i c a c a o . E s t P u b l i c a c a o { // Opera c o es void r e s e r v a r ( P u b l i c a c a o r e f ) { System . out . p r i n t l n ( A p u b l i c a c ao j a est a d i s p o n vel ) ;}
53 54 55 56 57 58 59 60
void c a n c e l a r R e s e r v a ( P u b l i c a c a o r e f ) { r e f . d e f i n e E s t a d o D i s p o n i v e l ( ) ; } }
// E s t P u b l i c a c a o B l o q u e a d a . j a v a package p u b l i c a c a o ; public c l a s s E s t P u b l i c a c a o B l o q u e a d a extends p u b l i c a c a o . E s t P u b l i c a c a o { // Opera c o es void r e s e r v a r ( P u b l i c a c a o r e f ) { System . out . p r i n t l n ( A p u b l i c a c a o n a o pode s e r reservada ) ;}
61 62
void c a n c e l a r R e s e r v a ( P u b l i c a c a o r e f ) { A p u b l i c a c a o n a o pode s e r r e s e r v a d a } }
4.10
Metaclasses
Metainforma c ao e um termo gen erico aplicado a qualquer dado que descreve outro dado. Em particular, na maioria das linguagens de programa c ao orientadas a objetos, classes s ao vistas como f abricas que criam e inicializam inst ancias (i.e. objetos). As classes n ao s ao objetos porque elas pr oprias n ao s ao inst ancias de classes. Entretanto, em algumas linguagens orientadas a objetos, tal como Smalltalk-76 [31], existem dois tipos de elementos geradores no modelo de objetos: (i) metaclasses que geram classes e (ii) classes que geram inst ancias terminais (Figura 4.51). Portanto, todas as entidades do modelo de objetos s ao objetos, inclusive as classes. Com isto uma uniformiza c ao do modelo de objetos e obtida.
<< metaclass >> Metaclasse atributos de classe :. + mtodos de classe ():. Classe . atributos de objetos << instance_of >> :.
objeto:Classe
<< instance_of >> + mtodos de objetos ():.
instncia terminal
Figura 4.51: O Conceito de Metaclasse
155
Mais especicamente, metaclasse e uma classe que descreve outra classe, isto e, ela e uma classe cujas inst ancias s ao classes. Em outras palavras, uma metaclasse guarda a metainforma c ao de uma classe. Existem pelo menos dois benef cios da representa c ao de classes como objetos. O primeiro e que as informa c oes globais relativas a todos os objetos de uma classe podem ser armazenadas nos atributos de classe (seguindo a terminologia de Smalltalk). Os m etodos associados com a metaclasse (chamados de m etodos de classe) podem ser usados para recuperar e atualizar os valores dos atributos de classe. A segunda vantagem e o seu uso para cria c ao/inicia c ao de novas inst ancias da classe. Em Smalltalk-80, por exemplo, existe uma metaclasse distinta para cada classe do sistema e a hierarquia de metaclasses e constru da de forma paralela ` a hierarquia de classes. Algumas linguagens orientadas a objetos, como C++ e Java, n ao d ao apoio direto para a abordagem classes como inst ancias de metaclasses, como Smalltalk. No entanto, C++ e Java d ao apoio para as no c oes de atributos de classes e m etodos de classes atrav es de uma fus ao do conceito de metaclasse com o de classe (Figura 4.52).
Classe atributos de classe :int atributos de objetos :int + mtodos de classe ():void + mtodos de objetos ():void . << instance_of >> objeto:Classe valores dos atributos de objetos :.
Figura 4.52: Fus ao de Metaclasse com Classe
De forma mais gen erica, podemos dizer que o paradigma de objetos d a suporte a pelo menos tr es n veis de abstra c oes: (i) abstra c ao de dados para comunica c ao de objetos; (ii) super-abstra c ao (heran ca) para o compartilhamento de comportamento e ger encia de objetos; e (iii) meta-abstra c ao (metaclasse) como base para a auto-representa c ao do sistema. Em UML, metaclasses s ao representadas atrav es do estere otipo metaclass (Figura 4.53), especicando uma classe (no caso do exemplo, MetaLivro) cujos objetos s ao classes (classe Quarto). UML tamb em permite a especica c ao de m etodos e atributos de classe. Estes aparecem sublinhados em um diagrama de classes comum, conforme apresentado na Figura 4.54.
dp:Livro << metaclass >> MetaLivro contadorLivros :int tempoDeEmprestimo :int + devolverContadorLivros ():int + devolverTempoDeEmprestimo ():int + ajustarTempoDeEmprestimo (numDias :int ):void . << instance_of >> Livro nome :String editora :String edicao :int contadorLivros :int tempoDeEmprestimo :int nome = "Design Patterns" :String editora = "Addison Wesley" :String . << instance_of >> edicao = 1 :int + devolverContadorLivros ():int + devolverTempoDeEmprestimo ():int + ajustarTempoDeEmprestimo (numDias :int ):void + bloquear ():void + desbloquear ():void
+ bloquear ():void + desbloquear ():void
contadorLivros = 251 tempoDeEmprestimo = 15
Figura 4.53: Metaclasses
156
Livro contadorLivros :int tempoDeEmprestimo :int nome :String editora :String edicao :int + devolverContadorLivros ():int + devolverTempoDeEmprestimo ():int + ajustarTempoDeEmprestimo (numDias :int ):void + bloquear ():void + desbloquear ():void
. << instance_of >>
dp:Livro
Figura 4.54: Atributos e m etodos de classe.

Publicacao contadorPublicacoes :int numeroTombo :String nome :String editora :String + devolverContadorPublicacoes ():int + reservar ():void + imprimir ():void
Livro contadorLivros :int edicao :int + devolverContadorLivros ():int + bloquear ():void + desbloquear ():void + imprimir ():void
Periodico contadorPeriodicos :int periodicidade :int + devolverContadorPeriodicos + indexar ():void + imprimir ():void ():int
Figura 4.55: Solu c ao com Atributos e M etodos Est aticos
4.10.1
Exemplo de utiliza c ao de metaclasses
Vamos imaginar uma situa c ao onde se deseja controlar o n umero de publica c oes de uma biblioteca. Al em disso, deseja-se saber o n umero espec co dos tipos instanciados: n umero de livros e n umero de peri odicos. Primeira Solu c ao: atributos e opera co es est aticas na classe Livro A Figura 4.55 apresenta a primeira solu c ao poss vel para esse problema. Perceba que os atributos contadorDePublicacoes, contadorDeLivros e contadorDePeriodicos pertencem ` as classes Publicacao, Livro e Periodico, enquanto numeroTombo, nome, editora, edicao e periodicidade pertencem aos objetos dessas classes. O c odigo a seguir apresenta uma implementa c ao em Java para a hierarquia de publica c oes
157
apresentada na Figura 4.55. Perceba que os atributos e m etodos de classe podem ser acessados diretamente a partir da classe (Linhas 11,25,28,29,44,47 e 48), sem necessitar instanciar qualquer objeto. O acesso desses atributos e opera c oes atrav es do nome da classe (e n ao de um objeto) e considerada uma boa pr atica de programa c ao, pois auxilia o desenvolvedor a diferenciar facilmente os elementos da classe e os elementos do objeto.
1 2 3 4 5 6 7 8 9 10 11
// Arquivo P u b l i c a c a o . j a v a public abstract c l a s s P u b l i c a c a o { // c l a s s e a b s t r a t a // A t r i b u t o s da c l a s s e private s t a t i c i n t c o n t a d o r P u b l i c a c o e s ; // A t r i b u t o s do o b j e t o private S t r i n g numeroTombo ; private S t r i n g nome ; private S t r i n g e d i t o r a ;
// Opera c o es da c l a s s e public s t a t i c i n t d e v o l v e r C o n t a d o r P u b l i c a c o e s ( ) { return P u b l i c a c a o . contadorPublicacoes ;}
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
// Opera c o es do o b j e t o public void r e s e r v a r ( ) { . . . } public void i m p r i m i r ( ) { . . . } }
// Arquivo L i v r o . j a v a public c l a s s L i v r o { // A t r i b u t o s da c l a s s e private s t a t i c i n t c o n t a d o r L i v r o s ; // A t r i b u t o s do o b j e t o private i n t e d i c a o ;
// Opera c o es da c l a s s e public s t a t i c i n t d e v o l v e r C o n t a d o r L i v r o s ( ) { return L i v r o . c o n t a d o r L i v r o s ; } // Opera c o es do o b j e t o public L i v r o ( ) { L i v r o . c o n t a d o r L i v r o s ++; // ou s i m p l e s m e n t e c o n t a d o r L i v r o s ++ P u b l i c a c a o . c o n t a d o r P u b l i c a c o e s ++; // ou s i m p l e s m e n t e c o n t a d o r P u b l i c a c o e s ++ } public void b l o q u e a r ( ) { . . . } public void d e s b l o q u e a r ( ) { . . . }
158
33 34 35 36 37 38 39 40 41 42 43 44

public void i m p r i m i r ( ) { . . . }
// Arquivo P e r i o d i c o . j a v a public c l a s s L i v r o { // A t r i b u t o s da c l a s s e private s t a t i c i n t c o n t a d o r P e r i o d i c o s ; // A t r i b u t o s do o b j e t o private i n t p e r i o d i c i d a d e ;
// Opera c o es da c l a s s e public s t a t i c i n t d e v o l v e r C o n t a d o r P e r i o d i c o s ( ) { return P e r i o d i c o . contadorPeriodicos ;}
45 46 47 48 49 50 51 52
// Opera c o es do o b j e t o public P e r i o d i c o ( ) { P e r i o d i c o . c o n t a d o r P e r i o d i c o ++; // ou s i m p l e s m e n t e c o n t a d o r P e r i o d i c o s ++ P u b l i c a c a o . c o n t a d o r P u b l i c a c o e s ++; // ou s i m p l e s m e n t e c o n t a d o r P u b l i c a c o e s ++ } public void i n d e x a r ( ) { . . . } public void i m p r i m i r ( ) { . . . } }
Segunda Solu c ao: O padr ao de projeto factory method O padr ao de projeto factory method lida com o problema da instancia c ao de objetos de maneira controlada. Utilizando atributos e m etodos est aticos, o padr ao dene uma opera c ao u nica para instancia c ao de onjetos, que n ao e o construtor da classe. Dessa forma, o padr ao reduz inclusive o acoplamento entre as classes do sistema, uma vez que quem requisita a instancia c ao do objeto n ao conhece qual a classe exata da hierarquia que foi instanciada; facilitando a evolu c ao do sistema. A Figura 4.56 apresenta o padr ao factory method aplicado para instanciar publica c oes da biblioteca. Perceba que as classes Publicacao, Livro e Periodico n ao s ao instanci aveis diretamente por classes externas ao pacote publicacao. Enquanto a classe Publicacao e uma classe abstrata, os construtores padr oes das classes Livro e Periodico possuem visibilidade de pacote. Sendo assim, o padr ao factory method dene um u nico ponto de acesso para se instanciar objetos de Livro e Periodico, que s ao as opera c oes createLivro() e createPeriodico(), respectivamente.
159
classe "final", no pode ser raiz de herana publicacao FabricaPublicacao contadorPublicacoes :int contadorLivros :int contadorPeriodicos :int << create >> MinhaFabrica ():FabricaPublicacao + createLivro ():Livro + createPeriodico ():Periodico + devolverContadorPublicacoes ():int + devolverContadorLivros ():int + devolverContadorPeriodicos ():int << instance_of >> . edicao :int objetoFab1 << create >> ~Livro ():Livro + bloquear ():void + desbloquear ():void + imprimir ():void << instance_of >> . << instance_of >> . << use . >> Publicacao numeroTombo :String nome :String editora :String + reservar ():void + imprimir ():void
Livro
Periodico periodicidade :int << create >> ~Periodico ():Periodico + indexar ():void + imprimir ():void
<< instance_of >> .
livro1:Livro
livro2:Livro
per1:Periodico
Figura 4.56: O Padr ao de Projeto Factory Method
4.11
Resumo
Este cap tulo apresentou alguns conceitos adicionais sobre o paradigma de objetos. Vimos que um objeto pode ser alocado em mem oria de duas formas diferentes: (i) aloca c ao est atica, realizada no momento em que o programa ou m odulo e carregado na mem oria; e (ii) aloca c ao din amica, realizada em tempo de execu c ao. Cada uma dessas estrat egias de aloca c ao possui vantagens e desvantagens. Por ser feita no momento em que o software e carregado, os objetos alocados estaticamente s ao acessados de forma mais eciente, uma vez que cam armazenados na pilha. Por em, a aloca c ao est atica aumenta o acoplamento entre tipo e implementa c ao, o que restringe fortemente a utiliza c ao de t ecnicas avan cadas de programa c ao OO, tais como o polimorsmo de inclus ao, que ser a visto na Se c ao 4.5.5. Al em disso, a aloca c ao est atica s o pode ser utilizada quando o programador j a sabe de antem ao as classes e a quantidade exata dos objetos do sistema. Enquanto isso, a aloca c ao din amica prioriza a exibilidade e a expressividade da programa c ao, perdendo as vantagens de desempenho alcan cadas com a aloca c ao est atica. Os objetos alocados dinamicamente s ao armazenados no heap, como conseq u encia, o processo de aloca c ao e desaloca c ao de objetos se torna mais caro. Al em disso, o programador deve se preocupar explicitamente com o tempo de vida do objeto, isto e, enquanto na aloca c ao est atica o objeto e desalocado automaticamente no nal da execu c ao do bloco de instru c oes, na aloca c ao din amica o programador deve indicar explicitamente o momento da desaloca c ao. Uma exce c ao a essa regra s ao as linguagens que implementam algum mecanismo de coleta autom atica de lixo (do ingl es garbage collection).
160
Tamb em foram apresentadas duas manieras de se implementar o conceito de tipos em uma linguagem de programa c ao: (i) tipagem est atica, denida explicitamente pelo programador, durante a codica c ao do sistema; e (ii) tipagem din amica, denida dinamicamente, podendo ser alterado no decorrer da execu c ao. Dependendo do mecanismo de tipagem utilizado pela linguagem de programa c ao, deve ser utilizado um processo diferente para vericar a consist encia entre os tipos das vari aveis declaradas. Nas linguagens que implementam a tipagem est atica, como por exemplo C, C++, Java e C#, o tipo de cada objeto e denido no momento da declara c ao da vari avel que o representa. Essa deni c ao antecipada de tipos possibilita uma melhor verica c ao de compatibilidade em tempo de compila c ao, uma vez que os tipos n ao s ao alterados implicitamente, de acordo com o conte udo das vari aveis. Nas linguagens que implementam a tipagem din amica, como por exemplo Smalltalk-80, Objective-C, Perl e Python, as vari aveis declaradas n ao est ao associadas a um tipo particular. Nessas linguagens, o tipo das vari aveis e associado no momento da atribui c ao de valores. Dessa forma, o tipo pode ser alterado implicitamente no decorrer da execu c ao e a verica c ao da compatibilidade de tipo s o pode ser feita em tempo de execu c ao. Em rela c ao ao relacionamento de generaliza c ao/especializa c ao, foram apresentados dois tipos de heran ca, que s ao implementados por linguagens de programa c ao populares: (i) heran ca de comportamento, que apresenta a sem antica padr ao de generaliza c ao/especializa c ao, inclusive com a rela c ao de equival encia de tipos entre as superclasses e subclasses; e (ii) heran ca de implementa c ao, um artif cio para reutilizar c odigo da superclasse, quando a subclasse n ao e um tipo da superclasse. Na heran ca de implementa c ao, os atributos e opera c oes p ublicos da superclasse s ao herdados pela subclasse com visibilidade privada. Apesar de n ao recomendado, algumas linguagens de programa c ao possibilitam a sua utiliza c ao. Uma alternativa para esse tipo de reutiliza c ao de c odigo e atrav es da utiliza c ao de agrega c ao/decomposi c ao. Al em dos tipos de heran ca, este cap tulo discutiu em detalhes alguns problemas relacionados ` a hera ca m ultipla, assim como as principais abordagens de resolu c ao, que s ao implementadas pelas linguagens de programa c ao. Tamb em foi discutida uma alternativa ` a heran ca m ultipla de classes. Utilizando o relacionamento de agrega c ao/decomposi c ao, e poss vel usufruir das vantagens de reutiliza c ao de c odigo alcan cada com a heran ca m ultipla, sem comprometer a legibilidade do modelo e do c odigo. Finalmente, foi discutido um pouco mais sobre a implementa c ao de pacotes UML, apresentando alguns exemplos em Java.
4.12
Exerc cios
1. Um editor de desenhos geom etricos possui uma tela para desenhar. Essa tela pode ser constitu da de muitas guras. Figuras podem ser c rculos, linhas, pol gonos e grupos. Um grupo consiste de muitas guras e um pol gono e composto por um conjunto de linhas. Quando um cliente pede para que uma tela se desenhe, a tela, por sua vez, pede para cada uma das guras associadas que se desenhe. Da mesma forma, um grupo pede que todos os seus com-
161
ponentes se desenhem. Crie uma hierarquia de generaliza c ao/especializa c ao que classique essas diferentes guras geom etricas e identique o comportamento de cada tipo abstrato de dados que voc e criar, bem como os seus respectivos atributos. 2. Dena uma classe Rob o com as seguintes propriedades. A localiza c ao do rob o e dada por 2 coordenadas inteiras: x para sua posi c ao lest-oeste e y para a sua posi c ao norte-sul (x aumenta quando o rob o move para o leste e y aumenta quando o rob o move para o norte). O rob o pode se virar para qualquer posi c ao denida pelo tipo enumerado: Dire c ao = {norte, sul, leste, oeste}. A interface p ublica do rob o deve conter uma opera c ao para a sua movimenta c ao, e para o ajuste da sua orienta c ao (dobrar ` a esquerda ou ` a direita num angulo de 90 graus). 3. Classique e crie uma hierarquia de generaliza c ao/especializa c ao para os diferentes tipos de itens encontrados na biblioteca de uma universidade. Sugest ao: livros, peri odicos, teses, etc. Dena atributos (o m aximo que voc e souber) para cada uma das classes identicadas. 4. Explique a diferen ca entre o acesso p ublico, privado, protegido e a visibilidade de pacote de atributos e m etodos de uma classe. 5. Uma abstra c ao pode ser vista atrav es de m ultiplas perspectivas. Por exemplo, uma pessoa pode ser classicada de acordo com o seu sexo como masculino ou feminino e pode tamb em ser classicada de acordo com a sua idade como crian ca, jovem e adulto. Baseado na Figura 4.57
Pessoa
PessoaSexoMasculino
PessoaSexoFeminino
Criana
Jovem
Adulto
Figura 4.57: Especializa c ao da Classe Pessoa em Duas Dimens oes (a) Apresente uma solu c ao de modelagem que combine essas duas perspectivas usando heran ca m ultipla. Note que um objeto pode ser instanciado a partir de apenas uma u nica classe (um objeto n ao pode ser inst ancia de 2 classes). Por exemplo, o objeto Jos e e do sexo masculino e adulto, mas ele n ao pode ser instanciado a partir de ambas as classes SexoMasculino e Adulto ao mesmo tempo. (b) Discuta duas desvantagens da sua solu c ao proposta no tem anterior. (c) Proponha uma solu c ao alternativa mais ex vel que supere as desvantagens identicadas no tem anterior. (Dica: pense na hierarquia de agrega c ao/decomposi c ao.) 6. Fa ca uma compara c ao entre tipos abstratos de dados, classes e interfaces de Java. 7. C++ e Java usam mecanismos diferentes para desalocar objetos que n ao s ao mais necess arios. C++ usa desaloca c ao autom atica de objetos declarados estaticamente, mas os objetos criados dinamicamente devem ser desalocados explicitamente pelo programador. Java usa coleta de lixo autom atica. Pesquise o que isso signica e compare as duas abordagens.
162
8. Java, Eiel e Smalltalk-80 t em diferentes regras associadas ao acesso de atributos internos de uma classe por clientes fora da classe. Em Smalltalk-80, os atributos s ao invis veis fora da classe e, portanto, n ao podem ser acessados fora dela. Em Eiel, um atributo pode tornar-se vis vel fora da sua classe, mas ele pode ser somente lido e nunca modicado. Finalmente, Java e C++ permitem que atributos sejam lidos e escritos desde que eles sejam declarados como public. Compare essas tr es abordagens. Qual delas na sua opini ao e a mais razo avel? 9. Discuta heran ca de comportamento versus heran ca de implementa c ao (como apresentado na Se c ao 4.4), dando exemplos de cada uma delas. Em sua opini ao, qual das duas abordagens deveria ser incentivada? Justique sua resposta. 10. Considerando o trecho de c odigo em C++ apresentado a seguir, o que aconteceria se voc e tentasse compilar esse programa? Haveria erro de compila c ao? Caso exista, quais seriam os erros? E se o atributo codigo de Publicacao fosse privado?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
class Publicacao { protected : int codigo ; private : S t r i n g nome ; int s t a t u s ; public : void r e s e r v a r ( ) { . . . } i n t obterNome ( ) { . . . } }
c l a s s L i v r o : public P u b l i c a c a o { private : String isbn ; P u b l i c a c a o pub = new P u b l i c a c a o ; public : void o p e r a c a o 1 ( ) { i f ( c o d i g o == 0 ) //AQUI ( i ) c o u t << i s b n ; // AQUI ( i i ) i f ( ( pub . c o d i g o ) == 0 ) // AQUI ( i i i ) c o u t << ( pub . nome ) ; // AQUI ( i v ) c o u t << ( pub . obterNome ( ) ) ; // AQUI ( v ) } }
11. Dadas as seguintes declara c oes de classes em Java:
163
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
public c l a s s T { public void op ( ) { // implementa c a o1 } }
public c l a s s S extends T { public void op ( ) { // implementa c a o2 } }
public c l a s s P r o g r a m a P r i n c i p a l { public s t a t i c void main ( S t r i n g [ ] a r g s ) { T x = new T( ) ; S y = new S ( ) ; T p = new T( ) ; } }
Considere as invoca c oes de opera c oes apresentadas a seguir. Para cada uma das invoca c oes indicadas de (i) a (v), determine qual implementa c ao (1 ou 2) ser a executada. Justique as suas respostas.
1 2 3 4 5 6 7
p . op ( ) ; p = y; p . op ( ) ; x . op ( ) ; y . op ( ) ; x = y; x . op ( ) ;
// ( i ) // o a p o n t a d o r p r e c e b e o e n d e r e c o da v a r i avel // ( i i ) // ( i i i ) // ( i v ) // o a p o n t a d o r x r e c e b e o e n d e r e c o da v a r i avel // ( v ) y y
12. Em Ada, pode-se escrever uma fun c ao gen erica que aceita par ametros de diversos tipos. Compare esta forma de polimorsmo com o polimorsmo de inclus ao encontrado em linguagens orientadas a objetos. 13. Modele uma la polim orca de ve culos ( onibus, caminh oes, carros e motos). Essa la pode ser usada, por exemplo, em um sistema de ped agio. Utilize os conceitos de hierarquia de generaliza c ao/especializa c ao, agrega c ao/decomposi c ao, classe abstrata e classe concreta. 14. Em C++, um programador pode denir fun c oes param etricas que aceitam par ametros de tipos diferentes. Compare essa abordagem com a redeni c ao de opera c oes no polimorsmo de inclus ao encontrada em todas as linguagens orientadas a objetos.
164
15. O diagrama de classes apresentado na Figura 4.58 n ao representa elmente um buer que e inicialmente vazio, depois passa por estados sucessivos de transforma c ao. O mesmo buer pode car parcialmente cheio e possivelmente, pode car cheio. Modique o diagrama de tal forma que ele reita melhor os diferentes estados de transforma c ao pelos quais o objeto passa.
Buffer
Vazio
ParcialmenteCheio
Cheio
Figura 4.58: Hierarquia de Classes de um Buer 16. Dada a Figura 4.59, que apresenta o diagrama de classes de um sistema de controle de consultas m edicas:
Sistema de Controle de Consultas Mdicas
<< boundary >> Terminal
+ marcarConsulta (cpf :String ,crm :String ,data :Date ):void + confirmarConsulta (cpf :String ,crm :String ,data :Date ,hora :Time ):void Clinica
<< control >> CtlConsulta
+ marcarConsulta (cpf :String ,crm :String ,data :Date ):void obterMedico (crm :String ):Medico + confirmarConsulta (cpf :String ,crm :String ,data :Date ,hora :Time ):void obterCliente (cpf :String ):Cliente
Especialidade HorarioAtendimento diaDaSemana :String horaInicio :Time horaFim :Time nome :String crm :String endereco :String telefone :String + obterHorariosDisponiveis (data :Date ):HorarioAtendimento[] + obterHorarioConsultas (data :Date ):Consulta[] Medico nome :String codigoCRM :String << boundary >> FrtSUS
PlanoDeSaude cnpj :String razaoSocial :String endereco :String telefone :String Consulta data :Date hora :Time duracao :int id :String
Paciente nome :String telefone :String dataNascimento :Date endereco :String profissao :String cpf :String
ConsultaConveniada Observacao
ConsultaParticular
<< create >> + ConsultaParticular (cli :Paciente ,med :Medico ):ConsultaParticular
Queixa
PrescricaiEExame
ResultadoExameEResposta
Figura 4.59: Sistema de Controle de Consultas
165
(a) Como esse diagrama de classes poderia ser evolu do usando o conceito de interface UML? Suponha o caso onde o sistema deve ser integrado a v arios planos de sa ude diferentes. Justique sua resposta. (b) Dena o conceito de classe abstrata e mostre como diagrama de classes do sistema de controle de consultas pode explorar esse conceito. 17. Rene a hierarquia de c omodos apresentada na Figura 4.60 usando o conceito de metaclasses visto na Se c ao 4.10, onde os atributos e m etodos de classe s ao separados dos atributos e m etodos de objetos.
Comodo contadorComodos :int numComodo :int status :int << create >> + Comodo (numComodo :int ,status :int ): Comodo + getContadorComodos ():int + mostrar ():void + ocupar ():void status: 1 = ocupado 2 = reservado 3 = livre
Quarto contadorQuartos :int numCamas :int << create >> + Quarto (numCamas :int ,numComodo :int ,status :int ):Quarto + getContadorQuartos ():int + mostrar ():void Auditorio contadorAuditorios numLugares :int :int
<< create >> + Auditorio (numLugares :int ,numComodo :int ,status :int ):Auditorio + getContadorAuditorio ():int + mostrar ():void
Figura 4.60: Hierarquia de C omodos de um Hotel
166
Cap tulo 5
An alise Orientada a objetos: Modelagem Din amica

No Cap tulo 3 foi apresentada a modelagem est atica, na qual as especica c oes dos casos de uso do sistema s ao analisadas e as informa c oes extra das s ao representadas atrav es de um diagrama de classes de an alise. Essa primeira vers ao do diagrama de classes inclui elementos est aticos do dom nio do problema, isto e, conceitos relevantes (classes), informa c oes associadas a esses conceitos (atributos) e as liga c oes entre esses conceitos (associa c oes, agrega c oes e relacionamentos de heran ca). Neste cap tulo, apresentamos a modelagem din amica, que identica e modela os aspectos do sistema de software que podem mudar durante a sua execu c ao, devido ` a ocorr encia de eventos. Na modelagem din amica, o comportamento esperado do sistema e representado atrav es de diagramas din amicos da UML, mais especicamente, os diagramas de atividades, de seq u encia, e de colabora c ao, introduzidos no Cap tulo 2, al em dos diagramas de estados, que ser ao vistos na Se c ao 5.6. Os diagramas de atividades representam a l ogica do neg ocio a partir das suas principais atividades e as respectivas condi c oes de ativa c ao. Por esse motivo, como visto na Se c ao 2.9.10, esses diagramas s ao utilizados normamente para representar os uxos de eventos dos casos de uso. J a os diagramas de seq u encia e colabora c ao representam as intera c oes entre objetos dentro do sistema. Um diagrama de estados, por sua vez, fornece uma vis ao complementar aos diagramas din amicos anteriores, atrav es de uma representa c ao do estado do sistema ou de suas partes. Isso e feito atrav es de um conjunto de estados previstos e das respectivas transi c oes entre esses estados. As transi c oes s ao disparadas pela ocorr encia de eventos, que tanto podem ser est mulos externos fornecidos pelos atores do sistema, quanto condi c oes internas que devem ser detectadas antes das a c oes serem executadas. Al em de produzir um conjunto de diagramas que representam o comportamento e o estado esperados do sistema de software, a modelagem din amica tamb em acrescenta novas informa c oes 167
168
Cap tulo 5: An alise Orientada a objetos: Modelagem Din amica
ao diagrama de classes de an alise, que continua sendo o principal artefato produzido pela an alise orientada a objetos. Atrav es do estudo do modelo de casos de uso do sistema e das mensagens trocadas entre objetos nos diagramas de seq u encia e colabora c ao, as opera c oes p ublicas das classes de an alise s ao identicadas e conseq uentemente, as interfaces dessas classes s ao atualizadas. Apesar de j a serem identicadas nesse momento da an alise, essas opera c oes ser ao renadas, posteriormente, durante a fase de projeto do sistema. importante ressaltar que, assim como na modelagem est E atica, nenhuma solu c ao t ecnica e identicada ou descrita durante a modelagem din amica. Essa u ltima e apenas uma etapa da an alise e, conseq uentemente, trata estritamente do dom nio do problema.
5.1
Atividades da Modelagem Din amica
Durante a modelagem din amica, estamos interessados em denir o comportamento do sistema. Esse comportamento normalmente e descrito em termos dos eventos que ocorrem ao longo da execu c ao do sistema. Chamamos de evento qualquer ocorr encia que envolva o sistema com algum tipo de troca de informa c ao. e importante ressaltar que um evento n ao e a informa c ao trocada, mas o fato de alguma informa c ao ter sido trocada. Durante a an alise, o tipo de evento mais comum que encontramos e a intera c ao entre um ator e o sistema, embora outros tipos tamb em sejam poss veis. Neste livro, a modelagem din amica consiste das atividades mostradas a seguir, que s ao baseadas em outras metodologias descritas na literatura[41][29][26]:
Atividade 1 Identicar eventos do sistema. Atividade 2 Construir diagramas de seq u encia para os cen arios prim arios dos casos de uso. Atividade 3 Construir um u nico diagrama de colabora c ao para o sistema, combinando os diagramas de seq u encia obtidos na Atividade 2. Atividade 4 Atualizar interfaces p ublicas das classes de an alise. Atividade 5 Construir diagramas de estados. Atividade 6 Iterar e renar.
Nas se c oes seguintes, descrevemos cada uma dessas atividades em detalhes. Para tornar a explica c ao mais ilustrativa, lan camos m ao do mesmo estudo de caso que foi apresentado no Cap tulo 3, o Sistema de Controle para Bibliotecas.
169
5.2
Atividade 1: Identicar Eventos do Sistema
Como visto no Cap tulo 2, casos de uso representam seq u encias de atividades que envolvem atores e suas intera c oes com o sistema. Como dissemos antes, os eventos decorrentes da intera c ao entre esses atores e o sistema s ao bastante relevantes para a an alise OO, lembrando que atores podem ser pessoas, dispositivos ou at e mesmo outros sistemas computacionais. Tendo isso em vista, assim como na modelagem est atica, o modelo de casos de uso e a principal fonte de informa c oes para a modelagem din amica. Para identicar os eventos relevantes, realizamos uma nova an alise textual das especica c oes dos casos de uso, destacando os pontos nos quais ocorrem trocas de informa c ao. Esses pontos s ao facilmente identic aveis pela presen ca de a c oes, que normalmente s ao identicadas a partir de verbos ou verbos substantivados (Figura 5.1). A informa c ao que deve ser capturada consiste tanto dos verbos empregados quanto dos contextos nos quais eles aparecem.
Objetos/Classes Atributos Associaes Operaes
Enunciado do Problema OU Especificao dos Casos de Uso
Substantivos e Inf. de estado Verbos
Figura 5.1: Extra c ao de Informa c oes a partir do Enunciado do Problema
5.2.1
An alise Textual do Caso de Uso Emprestar Exemplar
A seguir, apresentamos novamente a especica c ao do uxo de eventos do caso de uso Emprestar Exemplar, destacando com sublinhado os eventos encontrados. Fluxo B asico : (livro, 1. O cliente solicita empr estimo de um exemplar de alguma publica c ao peri odico, tese ou manual), fornecendo o seu n umero de registro e o n umero de tombo da publica c ao desejada. 2. A atendente solicita o empr estimo ao sistema, fornecendo o c odigo do cliente e o tombo da publica c ao 3. O sistema valida o cliente e verica o seu status no sistema de cadastro (Normal ou Suspenso) atrav es de seu n umero de registro. (<< include >> Validar Usu ario) 4. O sistema verica se existe algum exemplar dispon vel da publica c ao desejada. 5. Se o status do cliente for Normal e algum exemplar da publica c ao estiver dispon vel 5.1. O sistema registra um novo empr estimo;
170
Cap tulo 5: An alise Orientada a objetos: Modelagem Din amica ario - 7 dias 5.2. O sistema verica o per odo do empr estimo, que depende do tipo de usu para alunos e 15 para professores c ao de que o exemplar n ao ir a 5.3. O sistema atualiza seu banco de dados com a informa se encontrar na biblioteca at e completar o per odo.
Fluxo Alternativo 1 : No passo 5, se o usu ario estiver suspenso, o sistema o informa de sua proibi c ao de retirar exemplares e o empr estimo n ao e realizado. Fluxo Alternativo 2 : No passo 5, se todas as c opias da publica c ao estiverem emprestadas ou reservadas, o sistema informa ` a atendente que n ao ser a poss vel realizar o empr estimo.
Entre os trechos destacados acima, alguns n ao d ao uma id eia imediata de troca de informa c ao, mas isso e fruto da maneira como o caso de uso foi especicado. Conseq uentemente, e preciso aten c ao ao realizar a an alise textual da especica c ao ` a procura de eventos, j a que nem sempre eventos s ao t ao f aceis de identicar quanto conceitos. Por exemplo, a frase O empr estimo e realizado n ao parece com um evento, j a que n ao indica a ocorr encia de troca de informa c oes entre o sistema e algum ator. Entretanto, uma an alise mais cuidadosa mostra que isso n ao procede, j a que o atendente (ou quem quer que seja respons avel pela opera c ao do sistema) precisa ser informada sobre o fato de o empr estimo ter sido realizado com sucesso ou n ao. Conseq uentemente, essa frase precisaria ser reescrita para que passasse a descrever um evento: O sistema informa ao atendente que o empr estimo foi realizado. Pelo exemplo acima, e f acil perceber que nem toda ocorr encia de verbo corresponde a um evento, embora eventos sempre estejam associados a verbos, ou verbos substantivados. Por exemplo, a frase A publica c ao n ao se encontrar a na biblioteca n ao pode ser vista como um evento. Ao inv es disso, diz respeito ` a necessidade do sistema manter algum registro da situa c ao de uma publica c ao emprestada. Por outro lado, dependendo da forma como o caso de uso foi especicado, a express ao gerenciamento de usu ario, por exemplo, apesar de n ao conter um verbo, pode signicar funcionalidades relativas ` a inclus ao, exclus ao e manuten c ao dos dados do usu ario. Nesse contexto, a palavra gerenciamento desempenha o papel do verbo gerenciare deve ser analisado como tal. Al em disso, e importante entender a rela c ao dos atores com o sistema. Por exemplo, no uxo de eventos apresentado, clientes nunca interagem diretamente com o sistema, j a que quem opera este u ltimo e o atendente. Conseq uentemente, eventos n ao precisam ser especicados com clientes no papel de atores. Deve-se prestar aten c ao, por em, para diferenciar as situa c oes em que clientes s ao atores, como na ora c ao: O cliente solicita empr estimo de publica ca o, daquelas em que o cliente e, na verdade, uma informa c ao que o sistema manipula, como por exemplo, a frase: O atendente verica o status do cliente. Neste u ltimo caso, cliente e, na verdade, uma inst ancia da classe Usu ario ou alguma de suas subclasses (Cap tulo 3) e e respons avel por conter os dados do cliente que s ao relevantes para o sistema.
171
5.2.2
Eventos Identicados
Selecionando e reescrevendo os trechos destacados no uxo de eventos e levando em considera c ao as observa c oes feitas acima, identicamos os seguintes eventos: 1. O cliente solicita empr estimo de um exemplar de alguma publica c ao; 2. O cliente fornece o seu n umero de registro e o n umero de tombo da publica c ao; 3. A atendente solicita o empr estimo ao sistema; 4. A atendente fornece o n umero de registro do cliente e o n umero de tombo da publica c ao; 5. O sistema valida o cliente e verica o seu status; 6. O sistema verica se existe algum exemplar dispon vel da publica c ao desejada; 7. O sistema registra um novo empr estimo; 8. O sistema verica o per odo do empr estimo; 9. O sistema atualiza seu banco de dados; 10. O sistema o informa de sua proibi c ao de retirar exemplares; 11. O sistema informa ` a atendente que n ao ser a poss vel realizar o empr estimo. Note que cada um dos eventos acima indica explicitamente se algum ator ou o pr oprio sistema eo respons avel por disparar o evento. Por exemplo, no evento 3: A atendente solicita o empr estimo ao sistema, ca claro que o atendente inicia a intera c ao e, conseq uentemente, dispara o evento. Essa informa c ao torna mais f acil determinar, em etapas seguintes da an alise, quais eventos d ao origem a opera c oes e quais s ao simplesmente respostas produzidas pelas chamadas dessas opera c oes. Al em disso, cada evento tamb em explicita o tipo de informa c ao que e trocada quando ele ocorre, embora sem entrar nos detalhes de sua representa c ao. Por exemplo, no evento 6: O sistema verica se existe algum exemplar dispon vel da publica ca o desejada, a informa c ao que o sistema obt em tem que ser suciente para que ela seja capaz de conhecer se h a ou n ao exemplares dispon veis. Essa informa c ao pode ser um valor booleano ou a quantidade de exemplares dispon veis. A decis ao nal quanto a isso s o ser a tomada na fase de projeto. Na lista de eventos apresentada acima, nem todos os eventos indicam intera c oes diretas entre o atendente e o sistema, embora todos sejam conseq u encia dessas intera c oes. Por exemplo, o evento 7: O sistema registra um novo empr estimo n ao envolve qualquer ator. Al em disso, e f acil perceber que h a uma certa redund ancia de informa c ao. Por exemplo, quando o atendente solicita o empr estimo de uma publica c ao para um usu ario cadastrado, pressup oe-se que informa c oes relativas ao usu ario e ` a publica c ao ser ao fornecidas. Apesar disso, foi usado um evento diferente para fornecer esses dados. Isso e de se esperar da especica c ao de um sistema real e n ao caracteriza um erro.
172
Nas atividades seguintes da modelagem din amica essa informa c ao ser a organizada de modo que as redund ancias sejam eliminadas. Uma vez que todos os eventos tenham sido identicados, eles s ao associados aos objetos envolvidos. Um objeto pode ser respons avel por gerar eventos ou reconhecer eventos gerados por outros. f E acil perceber que, no caso de uso Emprestar Publica c ao, h a apenas dois objetos interagindo: o atendente e o sistema. Podemos usar, por em, as diretrizes descritas na Se c ao 3.10.1, e dividir o sistema de acordo com os tr es tipos de classes de an alise apresentados: fronteira, controle e entidade. Deste modo, podemos descobrir mais informa c oes sobre o funcionamento esperado do sistema. A se c ao seguinte descreve como isso pode ser feito.
5.3
Atividade 2: Construir Diagrama de seq u encia para o Caso de Uso
No Cap tulo 2, Se c ao 2.9.11, introduzimos o conceito de diagrama de seq u encia de sistema. Um diagrama de seq u encia de sistema representa gracamente as intera c oes entre o sistema e os atores relacionados com a realiza c ao de um certo caso de uso. Intera c oes s ao explicitamente representadas atrav es de mensagens entre atores distintos e entre atores e o sistema. A ordena c ao temporal das mensagens e representada pela posi c ao em que elas aparecem no diagrama.
5.3.1
Diagrama de Seq u encia de Sistema
Para construir um diagrama de seq u encia de sistema, e necess ario identicar, a partir da descri c ao de um caso de uso, todas as intera c oes relevantes para a sua realiza c ao. E poss vel perceber, a partir desse fato, que existe uma rela c ao direta entre diagramas de seq u encia de sistema e os eventos identicados na Se c ao 5.2.2. Por exemplo, a Figura 5.2 mostra o diagrama de seq u encia de sistema para o caso de uso Emprestar Publica c ao, onde as mensagens que uem entre o ator Atendente e o sistema s ao os eventos identicados naquela se c ao. No exemplo acima, o atendente s o conrma a realiza c ao do empr estimo se o usu ario estiver em dia com a biblioteca ([status = Normal]) ou ([status = Suspenso]) e se houver algum exemplar da publica c ao solicitada dispon vel para empr estimo (# exemplaresDisponiveis > 0). Normalmente, recomenda-se que condi c oes em diagramas de seq u encia sejam usadas raramente, j a que podem introduzir uma complexidade desnecess aria e dicultar o entendimento desses diagramas. O diagrama de seq u encia de sistema e um artefato u til para a an alise. A partir dele, percebe-se claramente quais eventos correspondem a servi cos que o sistema deve oferecer e quais se referem a respostas que ele deve fornecer, mediante requisi c oes disparadas por atores. Al em disso, a ordena c ao dos eventos e explicitada e tanto mensagens redundantes quanto novos eventos tornam-se imediatamente identic aveis. No diagrama da Figura 5.2, assumimos que, uma vez que o registro do usu ario e o n umero de tombo da publica c ao desejada sejam fornecidos, o sistema j a informa o

Diagrama de Seqncia de Sistema
173
a:Atendente a / 1) .solicitarEmprestimo() .Registro do Usuario .Nmero do Tombo
s:Sistema
Operao Cancelada
.verificarStatusUsuario
.emprestarExemplarDisponivel
a / 2)
.registrarEmprestimo
Figura 5.2: Diagrama de seq u encia de Sistema status do usu ario e o n umero de exemplares dispon veis da publica c ao, ao inv es de esperar que essas informa c oes sejam pedidas explicitamente. Al em disso, um novo evento: Conrma empr estimo, foi inclu do no diagrama, correspondente ao momento em que a bibliotec aria informa ao sistema que o empr estimo deve ser registrado.
Nota c ao UML para Condi co es e Itera co es em Diagramas de Seq u encia Um diagrama de seq u encia pode incluir condi c oes a m de modelar intera c oes mais complexas. Nesse tipo de diagrama, uma condi c ao indica quando uma mensagem e ou n ao enviada. Condi c oes s ao indicadas entre colchetes, junto com o r otulo de uma mensagem. Na Figura 5.2, duas condi c oes s ao utilizadas [status = Suspenso ou # exemplaresDisponiveis = 0] e [status = Normal e # exemplaresDisponiveis > 0]. Estas est ao associadas aos poss veis retornos da mensagem 3: fornece n umero de tombo da publica ca o, enviada pelo atendente. Tamb em e poss vel representar itera c oes em diagramas de seq u encia. A nota c ao e a mesma que e empregada para condi c oes, exceto pelo fato de itera c oes serem precedidas pelo s mbolo *. Uma itera c ao em um diagrama de seq u encia indica que uma mensagem e enviada v arias vezes para m ultiplos receptores. Normalmente, esses receptores correspondem aos elementos de uma cole c ao, por exemplo: (i) todas as publica c oes de um empr estimo; ou (ii) todos os usu arios cadastrados.
5.3.2
Diagrama de Seq u encia Renado
Apesar dos benef cios trazidos pelo emprego de diagramas de seq u encia de sistema, sua aplicabilidade e limitada, j a que o sistema e tratado como uma caixa preta. Conseq uentemente, n ao e feita rela c ao entre os eventos representados e as classes de an alise descobertas na modelagem est atica. No Cap tulo 3, mais precisamente na Se c ao 3.10.1, foi apresentada uma categoriza c ao para
174
classes de an alise sugerida pelo processo RUP. Essa categoriza c ao visa, principalmente, aumentar o entendimento do analista sobre o sistema que est a sendo modelado. De acordo com ela, as classes de an alise do sistema s ao divididas entre tr es categorias: fronteira, controle e entidade. Essas categorias denem uma estrutura c ao em camadas para o sistema, o que limita a maneira como inst ancias das classes de an alise interagem. Classes de fronteira interagem apenas com atores e classes de controle. J a as classes de entidade interagem com outras classes de entidade agregadas a ela e tamb em com as classes de controle, que implementam a l ogica do neg ocio. Essas classes de controle podem interagir com qualquer classe do sistema, seja ela de fronteira, de entidade, ou at e mesmo outra classe de controle. Utilizando essa distin c ao e obedecendo as restri c oes de comunica c ao entre as categorias das classes de an alise, pode-se enriquecer o diagrama de seq u encia da Figura 5.2 com informa c oes adicionais. Para tanto, devemos substituir o objeto do tipo Sistema por inst ancias das classes de an alise que o comp oem. Revisando a Figura 3.9 do Cap tulo 3, percebemos que o sistema tem apenas uma classe de fronteira e apenas uma classe de controle. Conseq uentemente, as duas classes foram selecionadas para serem inclu das no diagrama de seq u encia renado. Al em disso, e necess ario averiguar quais classes de entidade ser ao usadas no diagrama. Essa atividade pode ser executada a partir da an alise da lista de eventos identicada na atividade anterior. Revendo a lista de eventos identicados para o caso de uso Emprestar Publica c oes, percebe-se que, inicialmente, apenas as classes Publica c ao, Usu ario e Empr estimo s ao relevantes. O diagrama de seq u encia obtido ap os realizar as altera c oes descritas e apresentado na Figura 5.3.
Diagrama de Seqncia Refinado
a:Atendente
t:Terminal
c:Controlador
u:Usuario
ex :Exemplar
e:Emprestimo
1) .solicitarEmprestimo [regUsuario, nTombo]
2) .solicitarEmprestimo [regUsuario, nTombo] .u = pesquisarUsuario [regUsuario] 3) .obterStatus
4) .ex = obterExemplar Disponivel[nTombo] .emprestar 5) .e = new Emprestimo[ex,u]
6) 7) 8)
Figura 5.3: Diagrama de seq u encia Renado Fica claro no diagrama de seq u encia da Figura 5.3 que o n umero de eventos aumentou consideravelmente, em rela c ao ao diagrama da Figura 5.2. Al em de todos os eventos presentes na vers ao
175
simplicada, o novo diagrama adicionou novos eventos internos ao sistema. Esses eventos surgem naturalmente, ` a medida que o diagrama e constru do. Por exemplo, para poder informar o status do usu ario, o sistema precisa primeiro procurar pelo objeto do tipo Usu ario correspondente para, em seguida, obter o status desse usu ario e apresent a-lo na tela do terminal. Similarmente, para registrar um novo empr estimo, um objeto do tipo Empr estimo precisa ser criado e armazenado. Os novos eventos identicados nesta atividade ser ao usadas na atividade 4, quando s ao adicionadas opera c oes ` as interfaces p ublicas das classes de an alise. Vale ressaltar, por em, que o analista n ao deve perder muito tempo tentando identicar todos os eventos poss veis, j a que estes poder ao ser identicados em itera c oes subseq uentes, ` a medida que seu entendimento sobre o sistema crescer. O diagrama de seq u encia da Figura 5.3 apresenta elementos que, at e ent ao, n ao haviam aparecido. Por exemplo, quando o terminal envia para o controlador a mensagem 4: solicitaEmprestimo, ele tamb em passa dois par ametros (regUsuario e nTombo) correspondentes ao n umero de registro do usu ario e ao n umero de tombo, respectivamente. Dessa forma, o diagrama torna expl cito o tipo de informa c ao transferida em decorr encia desse evento. Al em disso, quando o controlador envia para si mesmo a mensagem 5: pesquisaUsu ario, al em de passar como par ametro o n umero de registro regUsuario, tamb em atribui o retorno a uma vari avel u do tipo Usu ario, correspondente ao usu ario encontrado. A nomea c ao dos objetos e um artif cio para tornar expl citas as rela c oes entre os objetos no diagrama. Note que o mesmo objeto do tipo Usu ario que e referenciado por u (u:Usu ario) e o que recebe a mensagem 6: obtemStatus, enviada do controlador. Dessa forma, ca expl cito quando o destino das mensagens n ao e qualquer objeto, mas aquele que foi obtido como resultado da pesquisa.
5.4
Atividade 3: Constru c ao de um Diagrama de Colabora ca o para o Sistema
Uma vez que os eventos tenham sido identicados para todos os casos de uso de um sistema, cria-se uma representa c ao de como esses eventos uem de um objeto para outro. Para tanto, utiliza-se um diagrama de colabora c ao em que os eventos n ao s ao numerados. Esses diagramas tamb em s ao conhecidos como diagramas de uxo de eventos. A Figura 5.4 mostra o diagrama de uxo de eventos relativo ao caso de uso Emprestar Publica c ao. Na Figura 5.4 a ordem em que os eventos s ao trocados pelos objetos n ao e explicitada. Conseq uentemente, em um diagrama de uxo de eventos, podem ser inclu dos os eventos identicados para todos os casos de uso do sistema, o que n ao seria poss vel, por exemplo, em um diagrama de seq u encia. Desse modo, consegue-se desfrutar de uma vis ao geral das trocas de informa c oes entre importante ressaltar, por objetos no sistema. E em, que esses diagramas tendem a tornar-se muito complexos, ` a medida que o n umero de casos de uso analisados aumenta.
176
Diagrama de Colaborao
:Atendente
e:Emprestimo
ex:Exemplar
solicitarEmprestimo(regUsuario, nTombo)
: emprestar() :
e = new Emprestimo(p,u)
:Terminal
solicitarEmprestimo(regUsuario, nTombo)
:.
:Controlador : :
obterStatus() :
u:Usuario
u = pesquisarUsuario(regUsuario) ex = obterExemplarDisponivel(nTombo)
Figura 5.4: Diagrama de Colabora c ao
5.5
Atividade 4: an alise.
Atualizar interfaces p ublicas das classes de
Nas atividades 1 e 2 da modelagem din amica, foram identicados diversos eventos relacionados ` a execu c ao do caso de uso Emprestar Publica c ao. Esses eventos representam tanto o comportamento externamente observ avel do sistema, isto e, aquele que e conseq u encia de intera c oes entre atores e o sistema; quanto o comportamento decorrente das intera c oes entre seus elementos internos. Os diagramas de seq u encia apresentados na Se c ao 5.3 determinam, ainda que implicitamente, a maneira como os eventos identicados anteriormente se relacionam com as classes de an alise encontradas durante a modelagem est atica. Na atividade atual, deve-se estudar esses diagramas de seq u encia, em especial o diagrama renado, mostrado na Figura 5.3, a m de atualizar as interfaces p ublicas das classes de an alise com as opera co es, que ofere cam os servi cos que essas classes devem oferecer e que, durante o projeto do sistema, ser ao materializados em m etodos. Pode-se come car separando os eventos identicados at e o momento, associando-os ` as classes dos objetos presentes no diagrama de seq u encia da Figura 5.3 e, para cada classe, indicando se o objeto foi respons avel pela ocorr encia do evento ou se apenas o recebeu. A Tabela 5.1 apresenta essa informa c ao. Uma vez que os eventos produzidos e recebidos pelas classes de an alise tenham sido identicados, pode-se precisar atualizar o diagrama de classes de an alise com essa informa c ao. Os eventos recebidos por uma classe se transformam em opera c oes de sua interface p ublica. J a os eventos produzidos por um objeto podem indicar duas coisas: (i) uma resposta a um evento recebido, como por exemplo, o evento 6(b): devolve status da classe Usu ario; ou (ii) o fato de que uma classe usa algum servi co oferecido por outra, como por exemplo, o evento 6: obtem status, que e produzido pela classe Controlador). No primeiro caso, os eventos servem para indicar o tipo de informa c ao que e devolvida por uma opera c ao. No segundo, eles oferecem informa c oes u teis para a implementa c ao dos m etodos, que acontecer a na fase de projeto. Opera c oes s ao especicadas como m etodos das classes de an alise. O tipo de cada par ametro
177
Tabela 5.1: Eventos relevantes para as Classes identicadas. Classe Usu ario Emprestimo Controlador pesquisarUsuario(regUsuario) Eventos Produzidos devolve status Eventos Recebidos obterStatus() new Emprestimo(ex, u) solicitarEmprestimo (regUsuario, nTombo) u=pesquisarUsuario(regUsuario) obterStatus() obterExemplarDisponivel (nTombo) e=new Empr estimo(p,u) registrarEmprestimo(e) N ao e poss vel realizar o empr estimo Informa status do usu ario e # de exemplares dispon veis Terminal solicitaEmprestimo() Registro do Usu ario N umero do Tombo solicitarEmprestimo (regUsuario, nTombo) N ao e poss vel realizar o empr estimo Informa status do usu ario e # de exemplares dispon veis registrarEmprestimo(e) devolve status obterExemplarDisponivel (nTombo)
178
corresponde ao tipo de informa c ao que e transferida quando o evento ocorre, como por exemplo, o par ametro regUsuario, passado no evento 4 da Figura 5.3. J a o tipo de retorno de cada opera c ao depende do evento que e produzido como resposta para a mensagem que inicia a sua execu c ao. A Figura 5.5 apresenta uma vers ao modicada do diagrama de classes de an alise do sistema de controle para bibliotecas, no qual opera c oes foram adicionadas ` as classes. Na gura, o evento new Emprestimo(p, u), que representa uma chamada ao construtor da classe Emprestimo, n ao foi inclu do. Esse tipo de evento normalmente n ao precisa ser documentado durante a an alise.
Diagrama de Classes de Anlise
+ solicitarEmprestimo (regUsuario :String ,nTombo :String ):void
<< control >> Controlador
+ solicitarEmprestimo (regUsuario :String ,nTombo :String ):void pesquisarUsuario (regUsuario :String ):Usuario obterExemplarDisponivel (nTombo :String ):Exemplar
<< entity >> Emprestimo dataEmprestimo :Date dataDevolucao :Date + << create >> + Emprestimo 1 << entity >> Publicacao titulo :String numeroTombo :String + obterExemplarDisponivel ():Exemplar 1 (ex :Exemplar ,u:Usuario ):Emprestimo * 1 << entity >> Usuario status :String numeroRegistro :String + obterStatus ():String
1 Exemplar status :String * codFisico :String + emprestar ():void
Figura 5.5: Diagrama de Classes de An alise com Opera c oes Note que, na Figura 5.5, alguns tipos de par ametros e tipos de retorno n ao correspondem a tipos normalmente encontrados em linguagens de programa c ao. Por exemplo, o tipo de retorno da opera c ao obterNumeroExemplaresDisponiveis() e quantidade. N ao usamos tipos existentes em linguagens de programa c ao, como inteiro ou real, porque a escolha dos tipos de dados que ser ao usados para modelar os conceitos do dom nio do problema e feita apenas durante o est agio de projeto. A classe de an alise Terminal corresponde ` a interface entre a bibliotec aria e o sistema. Embora a tenhamos representado de forma an aloga ` as outras classes de an alise, durante o projeto essa classe sofrer a um tratamento diferente. Suas opera c oes provavelmente n ao ser ao mapeadas para m etodos em classes de projeto. Ao inv es disso, ser ao transformadas em comandos e informa c oes exibidas atrav es de uma interface gr aca. Durante a an alise, por em, n ao h a mal nenhum em representar a classe Terminal da mesma forma que as outras classes.
179
Vale ressaltar que e poss vel complementar o diagrama de classes de an alise especicando as sem anticas das opera c oes. Podemos utilizar as t ecnicas descritas no Cap tulo 4, como (i) pr e- e p os-condi c oes e (ii) especica c oes alg ebricas. A u ltima atividade da modelagem din amica, que e mostrada na se c ao seguinte, abordar a a cria c ao de diagramas de estados de UML. Esses diagramas podem ser utilizados como forma complementar ` as t ecnicas de especica c ao sem antica de m etodos citadas anteriormente.
5.6
Atividade 5: Construir Diagramas de Estados
Esta se c ao, mostra como m aquinas de estados podem ser usadas para especicar o comportamento de sistemas e classes. Utilizamos a abordagem de UML, que e baseada no conceito de statecharts, criado por David Harel [23]. De um modo geral, diagramas de estados ilustram os poss veis estados que um objeto pode assumir e as respectivas condi c oes de altern ancia entre esses estados. Al em disso, esses diagramas mostram a maneira como o objeto reage aos eventos, sejam eles externos ou internos. A Figura 5.6 apresenta um diagrama de estados muito simples.
Estado inicial
Estado 1 Evento [Guarda] / Ao Estado 2
Estado final
Figura 5.6: Um Diagrama de Estados UML Os elementos b asicos de um diagrama de estados s ao estados e transi c oes. Em UML, estados s ao representados por ret angulos com os cantos arredondados, enquanto transi c oes s ao as setas que ligam os estados. Os estados inicial e nal s ao representados atrav es de s mbolos especiais (Figura 5.6). Transi c oes t em r otulos que consistem de tr es partes, todas opcionais: Evento [Condi ca o] / A ca o. Uma transi c ao exige que um certo evento ocorra e que a sua condi c ao seja verdadeira. A aus encia de condi c oes e equivalente a uma condi c ao que e sempre verdadeira. Quando uma transi c ao ocorre, uma a c ao pode ser executada, por exemplo, a invoca c ao de um m etodo. Diagramas de estados normalmente s ao usados para modelar: (i) a seq u encia legal de eventos externos que s ao reconhecidos e tratados por um sistema, no contexto da execu c ao de um caso de uso, (ii) o conjunto de todos os estados e transi c oes do sistema, ao longo da execu c ao de todos os casos de uso que o especicam, e (iii) o comportamento de classes complexas que dependem de algum tipo de estado. Em todos os casos, e recomend avel que a modelagem tenha foco nos eventos externamente observ aveis produzidos pela entidade especicada. No passo 5 da modelagem
180
din amica, damos enfase ao terceiro uso de diagramas estados, ou seja, estamos interessados em modelar o comportamento das inst ancias das classes de an alise. O estado de um objeto tem tanto caracter sticas ativas quanto passivas. O estado passivo de um objeto consiste dos valores de todos os seus atributos. J a o estado ativo indica o estado atual do objeto em um contexto espec co, relacionado ` a l ogica do neg ocio. Um objeto passa de um estado ativo para outro apenas se um evento relevante e pr e-denido tiver ocorrido. Para denir o comportamento de uma classe de an alise, come camos procurando, na especica c ao do sistema, todos os estados ativos relevantes. Por exemplo, observando a descri c ao do nosso estudo de caso, apresentada no Cap tulo 3, percebemos que um usu ario (classe Usu ario) pode (1) estar apto a pegar livros emprestados sem estar de posse de nenhum livro; (2) ter pego alguns livros e ainda ter tempo para devolv e-los; (3) estar de posse de livros que j a deveriam ter sido devolvidos; e (4) estar suspenso. Poderia-se tamb em levar em considera c ao dois estados adicionais identic aveis a partir da descri c ao do problema: (i) cadastrado; e (ii) n ao-cadastrado. Esses estados ativos n ao s ao relevantes, por em, j a que todos os outros estados assumem que o usu ario j a foi cadastrado. Al em disso, o sistema n ao sabe da exist encia um usu ario n ao-cadastrado. Depois disso e necess ario identicar as transi c oes entre estados. Transi c oes s ao facilmente identic aveis a partir dos eventos que ocorrem durante a opera c ao do sistema. Por exemplo, quando o evento 10 da Figura 5.3: registraEmprestimo(e) ocorre, sabe-se que ou (i) o usu ario passa do estado 1 do par agrafo anterior para o estado 2, ou (ii) se mant em no estado 2. O segundo caso pode ou n ao corresponder a uma transi c ao, dependendo de como o comportamento da classe e modelado. Neste exemplo, note que o evento respons avel pela transi c ao deve atualizar explicitamente o estado do objeto do tipo Usu ario, uma vez que a inst ancia dessa classe n ao percebe a ocorr encia do evento inicial. Isso e um indicativo de que cuidado adicional deve ser tomado quando se especica o comportamento de uma classe atrav es de diagramas de estados. A Figura 5.7 apresenta o diagrama de estados que modela o comportamento da classe Usu ario. Os eventos que aparecem no diagrama foram retirados das especica c oes de diversos casos de uso, n ao apenas de Emprestar Publica c ao.
Sem Livros
fim do perodo de suspenso registra devoluo [hoje < dataDevoluo] registra emprstimo
registra devoluo
Suspenso p/ Novos Emprstimos
registra Com devoluo [hoje < dataDevoluo]
Livros
registra emprstimo
registra devoluo [hoje > dataDevoluo]
Figura 5.7: Diagrama de Estados para a Classe Usu ario e importante ter cuidado para que diagramas de estados n ao sejam super-utilizados. Especicar comportamentos muito simples envolve esfor co e n ao tr as benef cios signicativos, j a que esses comportamentos normalmente s ao f aceis de entender mesmo sem a ajuda dos diagramas. Al em disso, identicar as transi c oes de um diagrama de estados pode ser um trabalho muito dispendioso.
Cap tulo 6
Estudo de Caso: Sistema de Caixa Autom atico

Este cap tulo apresenta um estudo de caso completo compreendendo a modelagem est atica e a modelagem din amica da an alise orientada a objetos.
6.1
Enunciado do Problema
O sistema de caixa autom atico permite que clientes realizem saques e veriquem seus saldos, de acordo com as seguintes regras de neg ocios: 1. Quando uma conta e criada no banco, o seu saldo e maior que zero. 2. Um cliente pode possuir v arias contas no banco. 3. O cliente acessa uma conta atrav es do terminal de um caixa eletr onico do seu banco. 4. Antes de executar qualquer opera c ao da conta, o cliente deve fornecer o n umero da sua conta e a senha referente ` a mesma. 5. Para a realiza c ao do saque, o cliente utiliza um terminal para solicitar um valor num erico de dinheiro. 6. O cliente pode sacar qualquer quantia do caixa, desde que a mesma seja igual ou inferior ao saldo dispon vel. Vale a pol tica do banco de que uma conta n ao aceita uma opera c ao de saque quando a conta est a com o saldo zerado. O dinheiro e liberado no dispensador de notas do caixa e debitado do saldo da conta. 181
182
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico
7. Al em de possuir o dinheiro dispon vel na conta, em uma opera c ao de saque, a quantidade de dinheiro dispon vel no caixa deve ser maior ou igual ` a quantia solicitada. 8. Se o saldo de uma conta e zerado durante uma opera c ao de saque, a conta deve se tornar inativa. 9. Os clientes que v ao operar o caixa eletr onico devem estar devidamente cadastrados no banco e suas contas est ao ativas. 10. Cada conta tem associado um n umero e uma senha. Al em disso, cada conta e associada a um cliente do banco, que possui informa c oes como nome, RG, CPF, etc. 11. As informa c oes adicionais sobre as contas e seus clientes est ao armazenadas em um Cadastro de Contas do Banco que interage com o Sistema de Caixa Autom atico. 12. Qualquer cliente cadastrado no banco pode efetuar dep ositos em uma conta, quer a conta esteja ativa, quer ela esteja inativa. 13. Caso a conta esteja inativa e ap os o dep osito seu saldo que maior que zero, a conte deve ser reativada.
Sistema de Caixa Automtico
Efetuar Login
Consultar Saldo Cadastro de Contas do Banco
Cliente Efetuar Saque
Dispensador de Notas Efetuar Depsito
Figura 6.1: Sistema de Caixa Autom atico
183
6.2
Descri c ao dos Casos de Uso
Nesta se c ao s ao apresentados os casos de uso correspondentes ao enunciado de problema apresentado na Se c ao 6.1. A Figura 6.1 mostra o diagrama de casos de uso do sistema de caixa autom atico. Nesse diagrama s ao apresentados quatro casos de uso: (i) Efetuar Login; (ii) Consultar Saldo; (iii) Efetuar Saque; e (iv) Efetuar Dep osito. Esses casos de uso ser ao estudados em detalhes no restante deste cap tulo.
6.2.1
Caso de Uso Efetuar Login
Breve Descri c ao : Em um caixa eletr onico, o cliente fornece o n umero de sua conta e senha e, caso estes estejam corretos, o acesso ao sistema e liberado. Atores : Cliente, Cadastro de Contas do Banco. Pr e-condi c ao : O cliente deve ter uma conta no banco e a senha informada deve ser igual ` a senha da conta. P os-condi c ao : Estado da conta inalterado e cliente autorizado a usar o sistema. Requisitos Especiais : Criptograa dos dados de acesso. Fluxo B asico : 1. O cliente solicita a op c ao de Efetuar Login no sistema. 2. O sistema pede que o cliente informe o n umero da conta. 3. O cliente fornece o n umero da conta. 4. O sistema pede que o cliente informe a sua senha. 5. O cliente fornece a senha. 6. O sistema verica se a conta e v alida e se a senha est a correta, atrav es do Cadastro de Contas do Banco. Em caso positivo, o sistema atualiza o estado do caixa eletr onico com as informa c oes de login. 7. O sistema exibe no terminal o menu de op c oes que o cliente pode acessar. Fluxo Alternativo 1 : No passo 6 do Fluxo B asico, se a conta fornecida n ao existir ou se a senha estiver errada, o sistema informa que alguma das informa c oes fornecidas est a incorreta e que n ao e poss vel autenticar o cliente. Em seguida, volta ao passo 2 do Fluxo B asico. Fluxo Alternativo 2 : Nos passos 3 e 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
184
6.2.2
Diagrama de Atividades do Caso de Uso Efetuar Login
A Figura 6.2 mostra o diagrama de atividades referente aos uxos do caso de uso Efetuar Login.
Estado Inicial
Selecionar opo "Efetuar Login"
Obter nmero da conta e senha
[operao cancelada] [seno] Verificar nmero da conta e senha
[Conta e/ou senha invlidos] [conta e senha Ok] Exibir "menu principal" Exibir "mensagem de erro"
Estado Final
Figura 6.2: Diagrama de atividades para o caso de uso Efetuar Login
6.2.3
Diagrama de Seq uencia do Caso de Uso Efetuar Login
A Figura 6.3 mostra o diagrama de seq u encia referente aos uxos do caso de uso Efetuar Login.
6.2.4
Caso de Uso Consultar Saldo
Breve Descri c ao : O cliente, j a autenticado, escolhe a op c ao Consultar Saldo e o sistema apresenta o seu saldo. Atores : Cliente, Cadastro de Contas do Banco. Pr e-condi c ao : A conta deve estar ativa e o cliente j a deve ter sido autenticado junto ao sistema, atrav es do caso de uso Efetuar Login. P os-condi c ao : Estado da conta inalterado.
185
<< actor >> :Cliente 1 : efetuarLogin() 2 : informar nro. da conta 3 : informar senha
:Sistema
4 : obterConta()
5 : verificarSenha()
[conta vlida E senha est correta] :. 6:atualizarStatusCaixa() [conta vlida E senha correta] :. 1.1: tela principal do sistema
[conta invlida OU senha incorreta] :. 1.2: mensagem de erro
Figura 6.3: Diagrama de seq u encia do caso de uso Efetuar Login Requisitos Especiais : nenhum. Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Consultar Saldo. 2. O sistema verica se o login foi efetuado 3. O sistema verica se a conta est a ativa, atrav es do Cadastro de Contas do Banco. 4. O sistema obt em o saldo da conta do cliente e o imprime. Fluxo Alternativo 1 : No passo 2 do Fluxo B asico, se o login n ao foi efetuado, o sistema informa isso ao cliente. Fluxo Alternativo 2 : No passo 3 do Fluxo B asico, se a conta n ao estiver ativa, o sistema informa isso ao cliente e avisa que a consulta n ao p ode ser realizada.
6.2.5
Diagrama de atividades do caso de uso Consultar Saldo
A Figura 6.4 mostra o diagrama de atividades referente aos uxos do caso de uso Consultar Saldo.
186

Estado Inicial
Selecionar opo "Consultar Saldo"
Verificar Login do usurio
[login no efetuado] [seno] Exibir "mensagem de erro de login" Verificar status da conta
[seno] [status == ativo] Exibir "mensagem de conta inativa"
Emitir Saldo
Estado Final
Figura 6.4: Diagrama de atividades para o caso de uso Consultar Saldo
6.2.6
Diagrama de Seq uencia do Caso de Uso Consultar Saldo
A Figura 6.5 mostra o diagrama de seq u encia referente aos uxos do caso de uso Consultar Saldo.

187
:Cliente
:Sistema
:CadastroContasDoBanco
1) .consultarSaldo
.obterNumConta .obterConta[numConta]
.verificarContaAtiva
.obterSaldo 2) .
Mensagem sncrona com representao de retorno
Mensagem assncrona sem representao de retorno
Figura 6.5: Diagrama de seq u encia do caso de uso Consultar Saldo
6.2.7
Caso de Uso Efetuar Saque
Breve Descri c ao : O cliente, j a autenticado, escolhe a op c ao Efetuar Saque, informa a quantia desejada e, caso o saldo da conta seja suciente e o caixa tenha o dinheiro necess ario, a quantia e liberada. Atores : Cliente, Cadastro de Contas do Banco, Dispensador de Notas. Pr e-condi c ao : O cliente deve estar logado no sistema, atrav es do caso de uso Efetuar Login. Al em disso, a conta deve estar ativa e o valor a debitar deve ser maior que zero e n ao pode ser superior ao saldo da conta nem ` a quantidade de dinheiro dispon vel no caixa. P os-condi c ao : O valor a ser sacado e subtra do do saldo da conta e do total dispon vel no caixa eletr onico e a quantia solicitada e fornecida ao cliente. Requisitos Especiais : nenhum. Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Efetuar Saque. 2. O sistema verica se o login foi efetuado. 3. O sistema verica se a conta est a ativa, atrav es do Cadastro de Contas do Banco. 4. O sistema solicita que o cliente informe a quantia desejada.
188
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico 5. O cliente informa a quantia desejada. 6. O sistema verica se o saldo da conta e suciente para realizar a transa c ao e, em caso armativo, se h a dinheiro em quantidade suciente no caixa. 7. O sistema subtrai o valor solicitado do saldo da conta do cliente e do valor dispon vel no caixa e libera a quantia solicitada, atrav es do dispensador de notas.
Fluxo Alternativo 1 : No passo 2 do Fluxo B asico, se o login n ao tiver sido efetuado, o sistema informa isso ao cliente. Fluxo Alternativo 2 : No passo 3 do Fluxo B asico, se a conta n ao estiver ativa, o sistema avisa isso ao cliente e informa que o saque n ao p ode ser realizado. Fluxo Alternativo 3 : No passo 6 do Fluxo B asico, se o valor solicitado for menor que zero ou superior ao saldo da conta ou ` a quantidade de dinheiro dispon vel no caixa, o sistema informa que n ao e poss vel realizar o saque e o porqu e. Em seguida, volta ao passo 4 do Fluxo B asico. Fluxo Alternativo 4 : Ap os o passo 7 do Fluxo B asico, se o saldo da conta for menor ou igual a zero, a conta deve ser desativada. Fluxo Alternativo 5 : No passo 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
6.2.8
Diagrama de Atividades do Caso de Uso Efetuar Saque
A Figura 6.6 mostra o diagrama de atividades referente aos uxos do caso de uso Efetuar Saque.
6.2.9
Diagrama de Seq u encia do Caso de Uso Efetuar Saque
A Figura 6.7 mostra o diagrama de seq u encia referente aos uxos do caso de uso Efetuar Saque.

Estado Inicial
189
Selecionar a opo "Efetuar Saque"
[login no efetuado] [seno] Exibir "mensagem de erro de login" Verificar status da conta
[seno] [status == ativo] Exibir "mensagem de conta inativa" Obter a quantia a sacar
[seno]
Verificar o saldo da conta e a quantia do caixa
[cancelar operao]
[quantia > 0 E quantia >= saldo E caixa tem dinheiro]
[seno]
Debitar valor na conta
Exibir "mensagem do porqu do saque estar indisponvel"
Liberar saque
Estado Final
Figura 6.6: Diagrama de atividades para o caso de uso Efetuar Saque
6.2.10
Caso de Uso Efetuar Dep osito
Breve Descri c ao : O cliente, escolhe a op c ao Efetuar Dep osito, informa a conta destino e a quantia desejada e, caso a quantia seja maior que zero, o sistema adiciona esse valor ao saldo da conta indicada. Atores : Cliente, Cadastro de Contas do Banco, Dispensador de Notas. Pr e-condi c ao : A conta destino do dep osito deve ser v alida e o valor a depositar deve ser maior que zero. P os-condi c ao : O valor a ser depositado e adicionado ao saldo da conta. Requisitos Especiais : nenhum. Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Efetuar Dep osito. 2. O sistema solicita que o cliente informe a conta destino do dep osito.
190
:Cliente 1) .efetuarSaque[valor]
:Sistema
:CadastroContasDoBanco
.obterNumConta .obterConta[numConta]
.verificarContaAtiva
.obterSaldo
.obterValorEmCaixa
2)
.debitarValor
Figura 6.7: Diagrama de seq u encia do caso de uso Efetuar Saque 3. O cliente informa a conta destino do dep osito. 4. O sistema solicita que o cliente informe a quantia desejada. 5. O cliente informa a quantia desejada. 6. O sistema adiciona o valor depositado ao saldo da conta. 7. O sistema verica se a conta deve ser reativada (saldo 0 E conta inativa). Em caso positivo, o sistema altera o estado da conta para ativo Fluxo Alternativo 1 : No passo 3 do Fluxo B asico, se a conta for inv alida, o sistema informa isso ao cliente. Em seguida, volta ao passo 2 do Fluxo B asico. Fluxo Alternativo 2 : No passo 5 do Fluxo B asico, se a quantia informada pelo cliente for menor que zero, o sistema deve informar isso ao cliente, explicando o porqu e. Em seguida, volta ao passo 4. Fluxo Alternativo 3 :
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico Nos passos 3 e 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
191
6.2.11
Diagrama de Atividades do Caso de Uso Efetuar Dep osito
A Figura 6.8 mostra o diagrama de atividades referente aos uxos do caso de uso Efetuar Dep osito.
Estado Inicial
Selecionar opo "Efetuar Depsito"
[login no efetuado] [seno] Exibir "mensagem de erro de login"
Obter conta a depositar
[operao cancelada]
[seno] Verificar existncia da conta
[conta inexistente] [conta existente]
Exibir "mensagem de conta inexistente"
Obter a quantia a depositar
[quantia <= 0]
Exibir "mensagem de quantia invlida"
[quantia > 0] Adicionar quantia ao saldo da conta [conta bloqueada E saldo da conta > 0] [conta desbloqueada OU saldo da conta <= 0]
Ativar conta
Estado Final
Figura 6.8: Diagrama de atividades para o caso de uso Efetuar Dep osito
6.2.12
Diagrama de Seq uencia do Caso de Uso Efetuar Dep osito
A Figura 6.9 mostra o diagrama de seq u encia referente aos uxos do caso de uso Efetuar Dep osito.
192
<< actor >> :Cliente 1 : solicitarDeposito() 2 : informar quantia a depositar
:Sistema
<< actor >> :CadastroContasDoBanco
3 : obterContaLogin()
. [login no efetuado] : 1.1: mensagem de erro login
[quantia <= 0] :. 1.2: mensagem de erro quantidade 4 : obterConta() 5 : adicionarValorConta() [conta inativa E saldo > 0] :. 6: ativarConta()
[seno] :. 1.3: operao concluda
Figura 6.9: Diagrama de seq u encia do caso de uso Efetuar Dep osito
6.3
Modelagem Est atica
Nesta se c ao, focamos na modelagem est atica do sistema do caixa autom atico para a identica c ao das classes de an alise, seus atributos e os relacionamentos entre elas. Para identicar os conceitos relevantes para o dom nio do problema, ser a utilizada a t ecnica de an alise textual, descrita no Cap tulo 3. Sendo assim, ser ao destacados inicialmente os substantivos das especica c oes dos quatro casos de uso descritos na Se c ao 6.2: Efetuar Login, Consultar Saldo, Efetuar Saque e Efetuar Dep osito. O artefato nal desta fase ser a a vers ao inicial do diagrama de classes de an alise. A Figura 6.10 mostra uma vers ao simplicada da seq u encia de atividades a serem seguidas para a modelagem desse diagrama. Neste cap tulo e sugerida a seq u encia de atividades apresentada no Cap tulo 3 (Se c ao 3.4). A Figura 6.10 sintetiza os principais passos a serem seguidos.
6.3.1
Atividade 1: Identicar as Classes de An alise
A seguir e iniciada a identica c ao dos substantivos a partir da especica c ao dos casos de uso do sistema. Inicialmente ser a analisado o caso de uso Efetuar Login. Em seguida ser a feito o mesmo com os casos de uso Consultar Saldo, Efetuar Saque e Efetuar Dep osito, destacando basicamente as diferen cas entre eles.
193
Estado Inicial
A partir do enunciado do paoblema E da especificaao dos casos de uso
1: Identificar substantivos
4: Identificar relacionamentos entre as classes de anlise
2: Identificar as classes de anlise
5: Identificar atributos das classes de anlise
[seno] 3: Construir o dicionrio de dados das classes selecionadas [6: Iterar e refinar] Estado Final
Figura 6.10: Atividades simplicadas da an alise textual Caso de Uso Efetuar Login
Breve Descri c ao : Em um caixa eletr onico, o cliente fornece o n umero de sua conta e senha e, caso estes e liberado. estejam corretos, o acesso ao sistema Atores : Cliente, Cadastro de Contas do Banco. Pr e-condi c ao : O cliente deve ter uma conta no banco e a senha informada deve ser igual ` a senha da conta. P os-condi c ao : Estado da conta inalterado e cliente autorizado a usar o sistema. Requisitos Especiais : Criptograa dos dados de acesso. Fluxo B asico : c ao de Efetuar Login no sistema. 1. O cliente solicita a op 2. O sistema pede que o cliente informe o n umero da conta. 3. O cliente fornece o n umero da conta. 4. O sistema pede que o cliente informe a sua senha. 5. O cliente fornece a senha. e v alida e se a senha est a correta, 6. O sistema verica se a conta atrav es do
onico Cadastro de Contas do Banco. Em caso positivo, o sistema atualiza o estado do caixa eletr com as informa c oes de login.
194

c oes que o cliente pode acessar. 7. O sistema exibe no terminal o menu de op
Fluxo Alternativo 1 : ao existir ou se a senha estiver errada, o sistema No passo 6 do Fluxo B asico, se a conta fornecida n informa que alguma das informa c oes fornecidas est a incorreta e que n ao e poss vel autenticar o asico. cliente. Em seguida, volta ao passo 2 do Fluxo B Fluxo Alternativo 2 : Nos passos 3 e 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
Caso de Uso Consultar Saldo

Breve Descri c ao : O cliente, j a autenticado, escolhe a op c ao Consultar Saldo e o sistema apresenta o seu saldo. Atores : Cliente, Cadastro de Contas do Banco. Pr e-condi c ao : A conta deve estar ativa e o cliente j a deve ter sido autenticado junto ao sistema, atrav es do caso de uso Efetuar Login. P os-condi c ao : Estado da conta inalterado. Requisitos Especiais : nenhum. Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Consultar Saldo. 2. O sistema verica se o login foi efetuado 3. O sistema verica se a conta est a ativa, atrav es do Cadastro de Contas do Banco. 4. O sistema obt em o saldo da conta do cliente e o imprime. Fluxo Alternativo 1 : No passo 2 do Fluxo B asico, se o login n ao foi efetuado, o sistema informa isso ao cliente. Fluxo Alternativo 2 : No passo 3 do Fluxo B asico, se a conta n ao estiver ativa, o sistema informa isso ao cliente e avisa que a consulta n ao p ode ser realizada.
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico Caso de Uso Efetuar Saque
195
Breve Descri c ao : O cliente, j a autenticado, escolhe a op c ao Efetuar Saque, informa a quantia desejada e, caso o saldo da conta seja suciente e o caixa tenha o dinheiro necess ario, a quantia e liberada. Atores : Cliente, Cadastro de Contas do Banco, Dispensador de Notas. Pr e-condi c ao : O cliente deve estar logado no sistema, atrav es do caso de uso Efetuar Login. Al em disso, a conta deve estar ativa e o valor a debitar deve ser maior que zero e n ao pode ser superior ao saldo da conta nem ` a quantidade de dinheiro dispon vel no caixa. P os-condi c ao : O valor a ser sacado e subtra do do saldo da conta e do total dispon vel no caixa eletr onico e fornecida ao cliente. e a quantia solicitada Requisitos Especiais : nenhum. Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Efetuar Saque. 2. O sistema verica se o login foi efetuado. 3. O sistema verica se a conta est a ativa, atrav es do Cadastro de Contas do Banco. 4. O sistema solicita que o cliente informe a quantia desejada. 5. O cliente informa a quantia desejada. 6. O sistema verica se o saldo da conta e suciente para realizar a transa c ao e, em caso armativo, se h a dinheiro em quantidade suciente no caixa. 7. O sistema subtrai o valor solicitado do saldo da conta do cliente e do valor dispon vel no caixa e es do dispensador de notas. libera a quantia solicitada, atrav Fluxo Alternativo 1 : No passo 2 do Fluxo B asico, se o login n ao tiver sido efetuado, o sistema informa isso ao cliente. Fluxo Alternativo 2 : No passo 3 do Fluxo B asico, se a conta n ao estiver ativa, o sistema avisa isso ao cliente e informa que o saque n ao p ode ser realizado. Fluxo Alternativo 3 : No passo 6 do Fluxo B asico, se o valor solicitado for menor que zero ou superior ao saldo da conta ao e poss vel realizar o ou ` a quantidade de dinheiro dispon vel no caixa, o sistema informa que n saque e o porqu e. Em seguida, volta ao passo 4 do Fluxo B asico.
196
Fluxo Alternativo 4 :
Ap os o passo 7 do Fluxo B asico, se o saldo da conta for menor ou igual a zero, a conta deve ser desativada. Fluxo Alternativo 5 : No passo 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
Caso de Uso Efetuar Dep osito

Breve Descri c ao : O cliente, escolhe a op c ao Efetuar Dep osito, informa a conta destino e a quantia desejada e, caso a quantia seja maior que zero, o sistema adiciona esse valor ao saldo da conta indicada. Atores : Cliente, Cadastro de Contas do Banco, Dispensador de Notas. Pr e-condi c ao : A conta destino do dep osito deve ser v alida e o valor a depositar deve ser maior que zero. e adicionado ao saldo da conta. P os-condi c ao : O valor a ser depositado Requisitos Especiais : nenhum. Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Efetuar Dep osito. 2. O sistema solicita que o cliente informe a conta destino do dep osito. 3. O cliente informa a conta destino do dep osito. 4. O sistema solicita que o cliente informe a quantia desejada. 5. O cliente informa a quantia desejada. 6. O sistema adiciona o valor depositado ao saldo da conta. 7. O sistema verica se a conta deve ser reativada (saldo 0 E conta inativa). Em caso positivo, o sistema altera o estado da conta para ativo Fluxo Alternativo 1 : No passo 3 do Fluxo B asico, se a conta for inv alida, o sistema informa isso ao cliente. Em seguida, volta ao passo 2 do Fluxo B asico. Fluxo Alternativo 2 :
197
No passo 5 do Fluxo B asico, se a quantia informada pelo cliente for menor que zero, o sistema deve informar isso ao cliente, explicando o porqu e. Em seguida, volta ao passo 4. Fluxo Alternativo 3 : Nos passos 3 e 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
6.3.2
Atividade 1.1: Extrair as Classes Candidatas

Consulta Saldo Saldo Terminal Saldo da conta Login Consulta Efetua Saque Caixa Dinheiro Quantia Dispensador de Notas Valor a debitar Quantia de dinheiro dispon vel em caixa Valor a ser sacado Quantia solicitada Quantia desejada Transa c ao sito Efetuar Depo Valor a depositar Valor a ser depositado Valor depositado Estado da conta Quantia informada pelo cliente Conta destino do dep osito
Efetuar Login Caixa eletr onico Cliente N umero da conta Senha Acesso Sistema Cadastro de Contas do Banco Op c ao Menu Principal Conta Banco Estado da conta Criptograa Opera c ao Estado do Caixa eletr onico
6.3.3
Atividade 1.2: Renar Classes Candidatas
Ap os fazer uma lista inicial de poss veis classes candidatas, procura-se identicar as classes redundantes, classes irrelevantes, classes vagas, atributos, opera c oes e pap eis.
Classes Redundantes Valor a ser depositado, Valor depositado e Quantia informada pelo cliente: equivalentes a Valor a depositar.
198
Caixa: id entica ` a classe Caixa eletr onico. Valor a ser sacado, Quantia desejada, Quantia solicitada, Quantia: equivalentes a Valor a debitar. Saldo da conta, Saldo da conta do cliente: equivalentes a Saldo. Opera c ao e Op c ao: equivalente a Transa c ao. Conta destino do dep osito: equivalente a N umero da conta.
Classes Irrelevantes Transa c ao: o enunciado do problema n ao exige que informa c oes sobre as transa c oes realizadas sejam armazenadas. N umero da conta: atributo da classe Conta. Senha: atributo da classe Conta. Estado do caixa: termo gen erico para os atributos da classe Caixa eletr onico. Quantidade de dinheiro dispon vel no caixa: atributo da classe Caixa eletr onico. Estado da conta: termo gen erico para os atributos da classe Conta. Saldo: atributo da classe Conta.
Classes Vagas Acesso Menu Principal Criptograa Login Consulta Valor a debitar Valor a depositar
199
6.3.4
Atividade 1.3: Revisar Lista de Classes Candidatas
CaixaEletr onico Cliente Sistema Cadastro de Contas do Banco Conta Banco Terminal Dispensador de Notas Na lista de classes acima, observa-se que Cliente, Dispensador de Notas e Cadastro de Contas do Banco s ao tr es elementos que n ao comp oem o sistema pois s ao atores que interagem com o sistema. Apesar disso, o enunciado do problema deixa claro a necessidade de se ter uma classe que represente os dados do cliente. Esse fato ca mais claro na seguinte arma c ao: Cada conta tem associado um n umero e uma senha. Al em disso, cada conta e associada a um cliente do banco, que possui informa co es como: nome, RG, CPF, etc. Por motivos did aticos, a classe que representa os dados de um cliente do banco ser a chamada DadosCliente, a m de n ao confundir com o ator Cliente.
6.3.5
Atividade 2: Construir o Dicion ario de Dados
Classe Terminal: classe atrav es da qual s ao transmitidos os valores de entrada e sa da a serem utilizados pelo caixa eletr onico. Esta classe encapsula toda a interface com o usu ario, assim, o tipo de terminal a ser implementado por um Sistema de Caixa Autom atico pode ser facilmente modicado atrav es da substitui c ao desta classe. Classe DadosCliente: classe cujos objetos encapsulam os dados pessoais dos clientes do banco. Classe Conta: classe cujos objetos s ao as contas mantidas pelos clientes do banco. Classe CaixaEletronico: classe que representa o estado do caixa autom atico. Classe Banco: classe que representa o estado do banco ao qual est a vinculada a conta e os clientes. Classe Sistema: o Sistema de Caixa Autom atico pode ser visto como uma classe que representa o sistema e engloba todas as classes pertencentes a este. Esta e uma classe conceitual e n ao pertence ao sistema propriamente dito.
200
6.3.6
Atividade 3: Identicar os Relacionamentos entre as Classes
Al em das trocas de mensagens j a descritas, deve-se denir a associa c ao existente entre as classes Terminal, CaixaEletr onico, Conta, Banco e DadosCliente com a classe Sistema. A classe Sistema representa o sistema como um todo e, desta forma, todas as outras classes podem ser consideradas partes dela. A Figura 6.11 mostra o diagrama de classes inicial do Sistema de Caixa Autom atico. Para simplicar a representa c ao do modelo, a classe Sistema pode ser substitu da por um pacote que contenha todas as classes que comp oem o sistema. Essa simplica c ao pode ser vista na Figura 6.12.
Sistema
Terminal
Caixa
DadosCliente
Conta
Banco
Figura 6.11: Diagrama inicial de classes com agrega c oes.

sistema
Terminal
Caixa
DadosCliente
Conta
Banco
Figura 6.12: Diagrama inicial de classes com pacote. As classes identicadas at e o momento devem ser analisadas com o intuito de identicar os relacionamentos de agrega c ao/decomposi c ao e de generaliza c ao/especializa c ao entre elas. Inicialmente, para identicar as agrega c oes , deve-se analisar a descri c ao do sistema e as especica c oes dos casos de uso, identicando o modo como as entidades se relacionam. Por exemplo, a frase Quando uma conta e criada no banco, o seu saldo deve ser maior que zero, evidencia o fato de um Banco possuir uma ou mais Contas. De forma an aloga, analisando a frase: O cliente acessa uma conta atrav es do terminal de um caixa eletr onico do banco, identica-se dois relacionamentos de agrega c ao: (i) a classe Caixa eletr onico agrega o Terminal; e (ii) a classe Banco agrega a classe CaixaEletronico. Por m, a frase: cada conta tem associado um n umero e uma senha. co es como: nome, Al em disso, cada conta e associada a um cliente do banco, que possui informa RG, CPF, etc. evidencia mais duas agrega c oes, uma vez que a classe DadosCliente pode possuir
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico v arias Contas e deve pertencer a um Banco.
201
Ap os a identica c ao das agrega c oes, o pr oximo passo e identicar os poss veis relacionamentos de generaliza c ao/especializa c ao entre as classes. Para isso, e necess ario analisar a exist encia (ou possibilidade de cria c ao) de tipos comuns entre as classes, de modo a generalizar nas classes base, as caracter sticas compartilhadas pelas classes derivadas. O enunciado do problema e as especica c oes dos casos de uso tamb em podem auxiliar essa atividade. No contexto espec co do sistema do caixa autom atico, n ao foram identicados relacionamentos de generaliza c ao/especializa c ao. A Figura 6.13 mostra as classes do sistema com os relacionamentos identicados.
sistema Terminal CaixaEletronico Banco
DadosCliente
Conta
Figura 6.13: Identica c ao dos relacionamentos entre as classes.
6.3.7
Atividade 4: Identica c ao de Atributos
Para descobrir os atributos das classes de an alise, retornamos ` a lista de classes irrelevantes apresentada na Se c ao 6.3.1. Diversas dessas classes candidatas foram eliminadas por representarem atributos de classes de an alise e n ao classes de an alise propriamente ditas. A Tabela 6.3.7 apresenta esses atributos, juntamente com as classes ` as quais eles pertencem. Al em dessa an alise das especica c oes dos casos de uso, pode-se utilizar o enunciado do problema para descobrir outros atributos das classes de an alise. O par agrafo seguinte levanta novas informa c oes que devem ser guardadas por objetos do tipo DadosCliente:
Cada conta tem associados um n umero e uma senha. Al em disso, cada conta e associada a um cliente do banco, que possui informa c oes como: nome, RG, CPF, etc..
A Figura 6.14 apresenta a vers ao revisada do diagrama de classes de an alise, j a levando em considera c ao os atributos identicados neste passo. Inclu mos tamb em neste diagrama a informa c ao referente ao n umero de inst ancias de cada uma das classes em tempo de execu c ao (Se c ao 1.3.3).
202
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico Tabela 6.1: Atributos Identicados das Classes de Entidade Classes de Entidade CaixaEletronico Atributos Quantidade de dinheiro dispon vel Status do Login N umero da Conta logada Conta Senha N umero Saldo Status Banco C odigo Nome
Diagrama de Classes de Anlise com Atributos
sistema Terminal CaixaEletronico quantiaDisponivel :. statusLogin :. contaLogin :. Banco cod :. nome :.
FichaCliente nome :. rg :. cpf :.
Conta senha :. numero :. saldo :. status :.
Figura 6.14: Diagrama inicial de classes de an alise com atributos.
6.3.8
Atividade 5 (Itera c ao 2): Iterar e Renar
Por se tratar de um processo de desenvolvimento iterativo, o sistema e constru do gradativamente, a partir de renamentos sucessivos dos modelos produzidos. Essa constru c ao gradual do sistema proporciona uma distribui c ao da sua complexidade, o que al em de permitir mudan cas tardias dos requisitos, aumenta a qualidade nal do software produzido. Nesta se c ao, ser ao mostradas as atividades onde houve algum renamento do diagrama inicial de classes produzido na primeira itera c ao. Esse diagrama e mostrado na Figura 6.14.
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico Atividade 1 (Itera c ao 2): Renamento das Classes de An alise
203
Como toda a intera c ao entre o sistema e os atores precisa ser intermediada por classes de fronteira, percebe-se que, al em do Terminal j a identicado, duas novas classe de fronteira devem ser introduzidas entre as candidatas. Essas novas classes, FronteiraCadastroContas e FronteiraDispensadorNotas, s ao respons aveis por mediar a intera c ao entre o sistema e os atores Cadastro de Contas do Banco e Dispensador de Notas, respectivamente. A lista seguinte apresenta as classes de an alise do sistema do caixa autom atico e seus respectivos estere otipos. Al em das novas classes de fronteira, uma nova classe foi inclu da na lista inicial de classes: a classe ControladorCaixa. Esta e uma classe de controle que representa as regras de neg ocio da aplica c ao e segue o padr ao de an alise Controlador (Se c ao 3.11). CaixaEletronico << entity >> Sistema Conta << entity >> Banco << entity >> Terminal << boundary >> DadosCliente << entity >> FronteiraCadastroContas << boundary >> FronteiraDispensadorNotas << boundary >> ControladorCaixa << control >> Atores: Cliente, Cadastro de Contas do Banco e Dispensador de Notas.
Atividade 2 (Itera c ao 2): Renamento do Dicion ario de Dados O novo dicion ario de dados e mostrado a seguir: Classe Terminal: classe de fronteira atrav es da qual s ao transmitidos os valores de entrada e sa da a serem utilizados pelo caixa eletr onico. Esta classe encapsula toda a interface com o usu ario, assim, o tipo de terminal a ser implementado por um Sistema de Caixa Autom atico pode ser facilmente modicado atrav es da substitui c ao desta classe. ticas denidas pela especi Classe ControladorCaixa: classe de controle que encapsula as pol ca c ao do sistema e gerencia as intera c oes entre as classes de fronteira e entidade. Os objetos da classe ControladorCaixa possuem opera c oes para efetuar login no sistema, consultar o saldo de uma conta, efetuar um saque e efetuar um dep osito.
204
Classe DadosCliente: classe de entidade cujos objetos encapsulam os dados pessoais dos clientes do banco. ao as contas mantidas pelos clientes do banco. Classe Conta: classe de entidade cujos objetos s Classe CaixaEletronico: classe de entidade que representa o estado do caixa autom atico. Classe Banco: classe de entidade que representa o estado do banco ao qual est a vinculada a conta e os clientes. Classe Sistema: o Sistema de Caixa Autom atico pode ser visto como uma classe que representa o sistema e engloba todas as classes pertencentes a este. Esta e uma classe conceitual e n ao pertence ao sistema propriamente dito. c oes entre o sistema Classe FronteiraCadastroContas: classe de fronteira que media as intera e o ator Cadastro de Contas do Banco. Classe FronteiraDispensadorNotas: classe de fronteira que media as intera c oes entre o sistema e o ator Dispensador de Notas.
Atividade 3 (Itera c ao 2): Renamento dos Relacionamentos entre as Classes Ap os a estrutura c ao das classes seguindo o modelo MVC, apresentado na Se c ao 3.10.1 do Cap tulo 3, pode-se utilizar as diretrizes fornecidas no Cap tulo 3 (Se c ao 3.7.1) para a identica c ao de associa c oes. Assim, deve-se averiguar quais as associa c oes existentes entre as classes do diagrama inicial de classes da itera c ao anterior, mostrado na Figura 6.14, e as novas classes identicadas nesta itera c ao. A liga c ao entre Terminal e ControladorCaixa pode ser compreendida, uma vez que o terminal que faz a interface com o cliente precisa estar ligado ` a parte do caixa respons avel por suas regras de neg ocios, para que opera c oes como saque e consulta de saldo de fato sejam efetuadas. Voltando ao enunciado do problema, as frases: Um cliente pode possuir v arias contas no banco. O cliente acessa uma conta atrav es do caixa eletr onico, bastando usar um terminal fornecendo o n umero de conta e a senha referente ` a mesma. justicam esta associa c ao. A associa c ao entre ControladorCaixa e Conta pode ser explicada, uma vez que na l ogica de neg ocio do caixa eletr onico, ele deve acessar informa c oes sobre a conta, necessitando assim interagir com ela. Al em disso, ControladorCaixa e a classe de entidade CaixaEletronico tamb em devem permanecer associadas, j a que a segunda representa o estado do caixa autom atico e esse estado n ao pode ser acessado sem levar em considera c ao as regras de neg ocio do sistema. Outra maneira pr atica de identicar as associa c oes relevantes entre as classes e simular a execu c ao dos passos dos uxos dos casos de uso. Essa simula c ao deve ser abstrata o suciente para se ater apenas ` a l ogica do
205
neg ocio, sem entrar em detalhes de implementa c ao. Por exemplo, numa opera c ao de saque, atrav es da interface do terminal, o cliente simplesmente solicita a quantia desejada. A classe de controle ControladorCaixa deve conhecer a classe de fronteira do sistema do sistema de cadastro de contas do banco: FronteiraCadastroContas. Essa associa c ao e necess aria, uma vez que os dados da conta devem ser obtidos antes de serem manipulados. Mas para visualizar essa manipula c ao, o controlador tamb em deve conhecer a classe de entidade Conta, a m de conseguir vericar se a conta obtida do cliente est a ativa, bem como conrmar se de fato o saldo dispon vel permite a efetiva c ao do saque e se o caixa tem a quantia solicitada. Desta forma, e a classe de controle que intermedia a comunica c ao entre o terminal e as contas e gerencia o estado do caixa autom atico (associa c ao com a classe CaixaEletronico). A classe Terminal simplesmente entra com o valor do saque desejado e, caso a classe ControladorCaixa verique que e poss vel realizar o saque e aciona o dispensador de notas, atrav es da associa c ao entre as classes ControladorCaixa e FronteiraDispensadorNotas. Caso contr ario, o terminal repassa para o usu ario uma mensagem vinda da classe controladora avisando que o saque n ao p ode ser conclu do. Seguindo as restri c oes do modelo MVC, todas as liga c oes entre classes de fronteira e classes de entidade devem ser removidas do diagrama, j a que essas classes devem ser sempre ligadas atrav es de uma classe de controle (Se c ao 3.10.1). Sendo assim, a agrega c ao entre as classes CarxaEletronico e Terminal deve ser removida. Dessa forma, a comunica c ao necess aria entre essas classes ser a intermediada pela classe ControladorCaixa O diagrama da Figura 6.15 apresenta o diagrama de classes nal da fase de an alise, sem a deni c ao das opera c oes das classes.
sistema Terminal ControladorCaixa FronteiraDispensadorNotas
FronteiraCadastroContas CaixaEletronico quantiaDisponivel :. statusLogin :. contaLogin :. Banco cod :. nome :.
FichaCliente nome :. rg :. cpf :.
Conta senha :. numero :. saldo :. status :.
Figura 6.15: Diagrama de classes nal de an alise (sem opera c oes)
206
6.4
Modelagem Din amica
Depois de modelar os aspectos est aticos do sistema, pode-se iniciar a modelagem din amica, relativa ao comportamento das classes de an alise em tempo de execu c ao. Realizamos uma nova an alise das especica c oes dos quatro casos de uso especicados: Efetuar Login, Consultar Saldo, Efetuar Saque e Efetuar Dep osito. Deve-se procurar por eventos que descrevam o comportamento do sistema. Seguindo as diretrizes apresentadas no Cap tulo 5 (Se c ao 5.1), deve-se dar uma aten c ao especial ` a ocorr encia de verbos e aos contextos nos quais esses verbos s ao empregados. A informa c ao extra da e ent ao utilizada para denir as opera c oes das classes de an alise pertencentes ` a sua interface p ublica. A Figura 6.16 sistematiza os passos a serem seguidos atrav es de um diagrama de atividades UML.
Estado Inicial A partir do enunciado do paoblema E da especificaao dos casos de uso Identificar verbos / verbos substantivados Construir diagramas dinamicos
anonymous Identificar eventos candidatos Atualizar interfaces das classes
Selecionar os eventos
Construir diagrama de estados Estado Final
Figura 6.16: Atividades da Modelagem Din amica
6.4.1
Passo 1: Identicar Eventos
A seguir, s ao apresentados os uxos de eventos dos casos de uso do sistema de caixa autom atico, destacando com sublinhado os trechos que possam corresponder a eventos.
Caso de Uso Efetuar Login Fluxo B asico : 1. O cliente solicita a op c ao de Efetuar Login no sistema. 2. O sistema pede que o cliente informe o n umero da conta. 3. O cliente fornece o n umero da conta.
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico 4. O sistema pede que o cliente informe a sua senha. 5. O cliente fornece a senha.
207
6. O sistema verica se a conta e v alida e se a senha est a correta, atrav es do Cadastro de Contas do Banco. Em caso positivo, o sistema atualiza o estado do caixa eletr onico com as informa c oes de login. 7. O sistema exibe no terminal o menu de op c oes que o cliente pode acessar. Fluxo Alternativo 1 : No passo 6 do Fluxo B asico, se a conta fornecida n ao existir ou se a senha estiver errada, o sistema informa que alguma das informa c oes fornecidas est a incorreta e que n ao e poss vel autenticar o cliente. Em seguida, volta ao passo 2 do Fluxo B asico. Fluxo Alternativo 2 : Nos passos 3 e 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
Caso de Uso Consultar Saldo Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Consultar Saldo. 2. O sistema verica se o login foi efetuado. 3. O sistema verica se a conta est a ativa, atrav es do Cadastro de Contas do Banco. 4. O sistema obt em o saldo da conta do cliente e o imprime. Fluxo Alternativo 1 : No passo 2 do Fluxo B asico, se o login n ao foi efetuado, o sistema informa isso ao cliente. Fluxo Alternativo 2 : No passo 3 do Fluxo B asico, se a conta n ao estiver ativa, o sistema informa isso ao cliente e avisa que a consulta n ao p ode ser realizada.
Caso de Uso Efetuar Saque Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Efetuar Saque. 2. O sistema verica se o login foi efetuado. 3. O sistema verica se a conta est a ativa, atrav es do Cadastro de Contas do Banco. 4. O sistema solicita que o cliente informe a quantia desejada.
208
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico 5. O cliente informa a quantia desejada. 6. O sistema verica se o saldo da conta e suciente para realizar a transa c ao e, em caso armativo, se h a dinheiro em quantidade suciente no caixa. 7. O sistema subtrai o valor solicitado do saldo da conta do cliente e do valor dispon vel no caixa e libera a quantia solicitada, atrav es do dispensador de notas.
Fluxo Alternativo 1 : No passo 2 do Fluxo B asico, se o login n ao tiver sido efetuado, o sistema informa isso ao cliente. Fluxo Alternativo 2 : No passo 3 do Fluxo B asico, se a conta n ao estiver ativa, o sistema avisa isso ao cliente e informa que o saque n ao p ode ser realizado. Fluxo Alternativo 3 : No passo 6 do Fluxo B asico, se o valor solicitado for menor que zero ou superior ao saldo da conta ou ` a quantidade de dinheiro dispon vel no caixa, o sistema informa que n ao e poss vel realizar o saque e o porqu e. Em seguida, volta ao passo 4 do Fluxo B asico. Fluxo Alternativo 4 : Ap os o passo 7 do Fluxo B asico, se o saldo da conta for menor ou igual a zero, a conta deve ser desativada. Fluxo Alternativo 5 : No passo 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
Caso de Uso Efetuar Dep osito Fluxo B asico : 1. O cliente escolhe no menu principal do terminal a op c ao Efetuar Dep osito. 2. O sistema solicita que o cliente informe a conta destino do dep osito. 3. O cliente informa a conta destino do dep osito. 4. O sistema solicita que o cliente informe a quantia desejada. 5. O cliente informa a quantia desejada. 6. O sistema adiciona o valor depositado ao saldo da conta. 7. O sistema verica se a conta deve ser reativada (saldo > 0 E conta inativa). Em caso positivo, o sistema altera o estado da conta para ativo. Fluxo Alternativo 1 :
209
No passo 3 do Fluxo B asico, se a conta for inv alida, o sistema informa isso ao cliente. Em seguida, volta ao passo 2 do Fluxo B asico. Fluxo Alternativo 2 : No passo 5 do Fluxo B asico, se a quantia informada pelo cliente for menor que zero, o sistema deve informar isso ao cliente, explicando o porqu e. Em seguida, volta ao passo 4. Fluxo Alternativo 3 : Nos passos 3 e 5 do Fluxo B asico, o cliente pode cancelar a opera c ao.
Atividade 1.1: Identicar Eventos Candidatos A seguir, e apresentada a lista de eventos candidatos identicados a partir das especica c oes dos casos de uso. Ao lado de cada evento candidato, e indicado o ator que o inicia. Escolher op c ao Efetuar Login (cliente) Solicitar o n umero da conta (sistema) Fornecer o n umero da conta (cliente) Solicitar a senha (sistema) Fornecer a senha (cliente) Vericar se a conta e v alida (sistema) Vericar se a senha est a correta (sistema) Atualizar o estado do caixa eletr onico com as informa c oes de login (sistema) Exibir no terminal o menu de op c oes (sistema) Informar que o login ou a senha est a inv alido (sistema) cancelar a opera c ao de efetuar login (cliente) Escolher a op c ao Consultar Saldo. (cliente) Vericar se o login foi efetuado (sistema) Vericar se a conta est a ativa. (sistema) Obter o saldo da conta. (sistema) Imprimir o saldo da conta. (sistema) Informar ao cliente que a conta n ao est a ativa. (sistema)
210
Informar ao cliente que o login n ao foi efetuado (sistema) Informar ao cliente que a consulta n ao p ode ser realizada. (sistema) Informar ao cliente que alguma das informa c oes fornecidas e incorreta. (sistema) Informar ao cliente que a consulta n ao p ode ser realizada. (sistema) Cancelar a opera c ao de consultar saldo (cliente) Escolher a op c ao Efetuar Saque. (cliente) Solicita que o cliente informe a quantia desejada. (sistema) Informar a quantia desejada. (cliente) Vericar se o cliente tem saldo suciente para realizar a transa c ao. (sistema) Vericar se h a dinheiro em quantidade suciente no caixa. (sistema) Subtrair o valor solicitado do saldo da conta do cliente. (sistema) Liberar a quantia solicitada. (sistema) Informar que n ao e poss vel realizar o saque porque o saldo da conta do cliente n ao e suciente. (sistema) Informar que n ao e poss vel realizar o saque porque n ao h a dinheiro suciente no caixa. (sistema) Desativar a conta (sistema) Cancelar a opera c ao de efetuar saque (cliente) Escolher a op c ao Efetuar Dep osito (cliente) Solicitar que o cliente informe o n umero da conta do dep osito (sistema) Informar o n umero da conta do dep osito (cliente) Solicitar a quantia desejada para dep osito (sistema) Informar a quantia desejada para dep osito (cliente) Adicionar o valor depositado ao saldo da conta (sistema) Vericar se a conta deve ser reativada (sistema) Reativar a conta (sistema) Informar que a quantia desejada e inv alida e que deve ser maior que zero (sistema) Cancelar a opera c ao de efetuar dep osito (cliente) Note que praticamente cada passo dos uxos de eventos produziu um evento. Isso e esperado, tendo em vista que um caso de uso modela intera c oes entre atores e o sistema.
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico Passo 1.2: Selecionar os Eventos Candidatos
211
Depois de identicar os eventos, precisamos associ a-los ` as classes de an alise. Como os eventos encontrados at e o momento enxergam o sistema como uma caixa preta, precisamos descobrir os eventos internos ao sistema que cada um desses eventos externos produz. Para tanto, usamos a divis ao das classes de an alise entre fronteira, controle e entidade, e do padr ao de intera c ao que essas classes seguem (Se c ao 3.10.1). Primeiramente, e necess ario identicar os eventos relevantes para o sistema. Pode-se iniciar analisando os eventos encontrados at e o momento, ` a procura de eventos que n ao possam ser realizados apenas por classes de fronteira. Os seguintes eventos dizem respeito exclusivamente ` a classe Terminal: Escolher op c ao Efetuar Login (cliente) Solicitar o n umero da conta (sistema) Fornecer o n umero da conta (cliente) Solicitar a senha (sistema) Fornecer a senha (cliente) Exibir no terminal o menu de op c oes (sistema) Informar que o login ou a senha est a inv alido (sistema) cancelar a opera c ao de efetuar login (cliente) Escolher a op c ao Consultar Saldo. Imprimir o saldo da conta. Informar o cliente que a conta n ao est a ativa. Informar ao cliente que o login n ao foi efetuado. Informar ao cliente que a consulta n ao p ode ser realizada. Informar ao cliente que alguma das informa c oes fornecidas e incorreta. Informar ao cliente que a consulta n ao p ode ser realizada. Cancelar a opera c ao de consultar saldo. Escolher a op c ao Efetuar Saque. Solicitar que o cliente informe a quantia desejada. Informar a quantia desejada.
212
Informar que n ao e poss vel realizar o saque porque o saldo n ao e suciente. Informar que n ao e poss vel realizar o saque porque n ao h a dinheiro suciente no caixa. Cancelar a opera c ao de efetuar saque. Escolher a op c ao Efetuar Dep osito (cliente) Solicitar que o cliente informe o n umero da conta do dep osito (sistema) Informar o n umero da conta do dep osito (cliente) Solicitar a quantia desejada para dep osito (sistema) Informar a quantia desejada para dep osito (cliente) Informar que a quantia desejada e inv alida e que deve ser maior que zero (sistema) Cancelar a opera c ao de efetuar dep osito (cliente) O seguinte evento diz respeito exclusivamente ` a classe FronteiraDispensadorNotas: Liberar a quantia solicitada. O elemento comum a todos esses eventos e o fato de se referirem exclusivamente ` a intera c ao entre o cliente e o sistema. Ou seja, s ao eventos relativos ` a capta c ao de informa c oes fornecidas pelo cliente (informar a quantia desejada, escolher a op c ao Consulta Saldo) e ` a produ c ao de resultados externamente observ aveis resultantes de computa c oes internas previamente realizadas ( liberar a quantia desejada, informar ao cliente que a consulta n ao p ode ser realizada.). Ap os separar os eventos de entrada e sa da, sobraram os seguintes: Vericar se a conta e v alida. Vericar se a senha est a correta. Atualizar o estado do caixa eletr onico com as informa c oes de login. Vericar se o login foi efetuado. Vericar se a conta est a ativa. Obter o saldo da conta. Vericar se o cliente tem saldo suciente para realizar a transa c ao. Vericar se h a dinheiro em quantidade suciente no caixa. Subtrair o valor solicitado do saldo da conta do cliente.
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico Desativar a conta. Adicionar o valor depositado ao saldo da conta. Vericar se a conta deve ser reativada. Reativar a conta.
213
Agora que j a foram identicados os eventos que devem ser renados, e necess ario determinar quais eventos internos produzem o comportamento desejado. Deve-se levar em considera c ao o fato do sistema estar modelado de acordo com as classes de an alise identicadas durante a modelagem est atica. Tendo isso em vista, deve-se renar os eventos identicados e, a partir destes, criar novos eventos relevantes ou eliminar eventos irrelevantes. Por exemplo, pode-se decompor o evento obter o saldo da conta nos seguintes passos: 1. obter o objeto do tipo Conta correspondente ` a conta desejada a partir do FronteiraCadastroContas. 2. obter o saldo a partir da Conta. 3. mostrar o saldo obtido no Terminal. Note que, nos passos acima, s ao utilizados os nomes das classes de an alise para referenciar os conceitos do dom nio do problema. Isso e aceit avel neste caso, j a que est a-se falando do funcionamento interno do sistema e n ao do seu comportamento externamente observ avel. Depois de renar todos os eventos relevantes, pode-se construir os diagramas de seq u encia que representam gracamente o funcionamento interno do sistema.
6.4.2
Diagramas de Seq u encia
Ap os identicar os eventos que s ao relevantes para o sistema, se faz necess ario renar os diagramas de seq u encia de sistema (Figuras 6.3, 6.5, 6.7 e 6.9) para que quem consistentes com esses eventos. Eventos externos, produzidos ou recebidos por atores, e eventos internos, aqueles que uem entre as inst ancias das classes de an alise, s ao inclu dos nos diagramas. Al em disso, o objeto Sistema deve ser substitu do por inst ancias das classes de an alise. Os diagramas de seq u encia resultantes para os casos de uso Efetuar Login, Consultar Saldo, Efetuar Saque e Efetuar Dep osito s ao apresentados respectivamente, nas Figuras 6.17, 6.18, 6.19 e 6.20. Em rela c ao ao caso de uso Efetuar Saques, os atores Cadastro de Contas do Banco e Dispensador de Notas foram omitidos, a m de manter a legibilidade da Figura 6.19.
214
<< actor >> :Cliente efetuar Login (numConta, senha)
:Terminal
:ControladorCaixa
:FronteiraCadastroContas
c:Conta
:CaixaEletronico
1:
2 : efetuarLogin(numConta, senha)
3 : c = obterConta(numConta) 3.1 : c:Conta
4 : verificarSenha(senha) [conta vlida E senha correta] :. 5: atualizarStatusLoginCaixa(numConta) [conta vlida E senha correta] :. 2.1: sucesso na operao
[conta invlida OU senha incorreta] :. 2.2: erro na operao [conta vlida E senha correta] :. 1.1: tela principal do sistema [conta invlida OU senha incorreta] :. 1.2: mensagem de erro
Figura 6.17: Diagrama de seq u encia Efetuar Login

Diagrama de Seqncia "Consultar Saldo"
:Cliente
:Terminal
:ControladorCaixa
:CaixaEletronico
c:Conta
1) .consultarSaldo 2) .consultarSaldo .numConta = obterNumConta .c = obterConta[numConta] .obterStatus .obterSaldo 3)
4)
Figura 6.18: Diagrama de seq u encia Consultar Saldo
215
Diagrama de Seqncia "Efetuar Saque"
:Cliente
:Terminal
:CtlCaixa
:CaixaEletronico
:FrtCadastroContas
c:Conta
:FrtDispe
1) .efetuarSaque[quant] 2) .efetuarSaque[quant] .numConta = obterNumConta .c = obterConta[numConta] .obterStatus .obterSaldo .obterValorCaixa
.debitarValor[quant] .debitarValor[quant] .liberaDinheiro[quant] 3) 4)
Figura 6.19: Diagrama de seq u encia Efetuar Saque
6.5
Diagrama de Colabora c ao
A Figura 6.21 apresenta o diagrama de colabora c ao decorrente da uni ao dos diagramas de seq u encia das Figuras 6.17, 6.18, 6.19 e 6.20. A m de reduzir a complexidade do diagrama, os eventos de retorno das mensagens n ao foram representados.
6.6
Diagrama Final de Classes da An alise
A Figura 6.22 apresenta o diagrama de classes de an alise revisado e levando em considera c ao as opera c oes identicadas a partir dos diagramas de seq u encia das Figuras 6.17, 6.18, 6.19 e 6.20. As opera c oes foram selecionadas usando-se as diretrizes apresentadas na Se c ao 5.5. Eventos recebidos por inst ancias de uma classe se tornam opera c oes de sua interface p ublica. As informa c oes associadas a esses eventos correspondem aos seus par ametros e os tipos de retorno s ao determinados pelos eventos produzidos em resposta ` a recep c ao de um evento, quando aplic avel.
216
<< actor >> :Cliente
:Terminal
:ControladorCaixa
:CaixaEletronico
c:Conta
1:
efetuarDeposito (quant) 2 : efetuarSaque(quant) 3 : numConta = obterContaLogin() 4 : c = obterConta() 5 : depositar(quant) [conta inativa E saldo > 0] :. 6: ativar() 7 : atualizarConta(c) 2.3 : operao concluda
2.1 : operaao concluda
Figura 6.20: Diagrama de seq u encia Efetuar Dep osito
Diagrama de Colaborao
:FrtDispensadorNotas
:Terminal
:FrtCadastroContas obterConta(numConta) :
liberarDinheiro(quant)
consiltarSaldo() : efetuarSaque(quant) :
:CaixaEletronico obterNumConta() : obterValorCaixa() : debitarValor(quant) :
:CtlCaixa obterStatus() : obterSaldo() : debitarValor(quant)
c:Conta
Figura 6.21: Diagrama de colabora c ao
6.7
Diagrama de Estados da Classe Conta
Tendo em vista a varia c ao dos comportamentos dispon veis de acordo com o estado da conta, julgou-se interessante modelar os estados da classe Conta com as respectivas opera c oes que podem
217
<< boundary >> FronteiraCadastroContas
<< entity >> Conta senha :. numero :. saldo :. status :. + verificarSenha (senha :.):. + obterStatus ():. + obterSaldo ():. + debitar (quant :.):. + desativar ():. + depositar (quant :.):. + ativar ():.
+ efetuarLogin ():. + consultarSaldo ():. + efetuarSaque ():. + solicitarDeposito ():.
+ obterConta (numConta :.):. + atualizarConta (numConta :.):.
<< control >> ControladorCaixa << entity >> Banco + efetuarLogin (numConta :.,senha :.):. + consultarSaldo ():. + efetuarSaque (quant :.):. + efetuarDeposito (quant :.):. cod :. nome :.
<< boundary >> FronteiraDispensadorNotas
<< entity >> CaixaEletronico quantiaDisponivel :. statusLogin :. numContaLogin :. + atualizarStatusLoginCaixa (numConta :.):. + obterNumConta ():. + obterQuantDisponivel ():. + debitarValor (quant :.):.
<< entity >> FichaCliente nome :. rg :. cpf :.
+ liberarQuantia (quant :.):.
Figura 6.22: Diagrama de Classes de An alise com Opera c oes ser executadas em cada um desses estados. A Figura 6.23 mostra essa modelagem atrav es de um diagrama de estados UML.
6.8
Renamentos do Diagrama de Classes de An alise
Uma extens ao realista para o sistema e o fato de um cliente poder possuir dois (ou mais) tipos distintos de contas: uma conta corrente e uma conta poupan ca. Neste caso, ao inv es de uma u nica classe, Conta, correspondente a uma conta no banco, ter amos mais duas, ContaCorrente e ContaPoupanca. A Figura 6.24 apresenta um diagrama de classes com essa hierarquia expandida. No diagrama de classes da Figura 6.22, o status de cada conta e representado por um atributo da poss classe Conta. E vel, por em, usar abordagens alternativas nas quais o status da conta e modelado como uma ou mais classes. Neste caso, uma classe abstrata Status encapsularia o comportamento que e comum a qualquer status, enquanto classes concretas como Ativa e Inativa encapsulariam o comportamento mais especializado. O diagrama de classes da Figura 6.25 apresenta a hierarquia
218
Estado Inicial
Ativa
[debitar(quant) E saldo <= 0] Inativa
[depositar(quant) E saldo > 0]
Figura 6.23: Diagrama de Estados da Classe Conta

Conta
ContaCorr
ContaPoup
Figura 6.24: Nova hierarquia para contas. estendida de contas, incluindo as classes que representam explicitamente o status de cada conta.
Conta
Status
ContaCorr
ContaPoup
Ativa
Inativa
Figura 6.25: Hierarquia de contas revisada. Estudaremos a modelagem do status de uma conta como um conjunto de classes no Cap tulo 7
Cap tulo 6: Estudo de Caso: Sistema de Caixa Autom atico (Se c ao 7.6), que fala sobre a transi c ao da an alise para o projeto.
219
220
Cap tulo 7
Transi c ao da An alise OO para o Projeto OO

Nos Cap tulos 3 e 5 foram descritos os passos da an alise orientada a objetos. A an alise OO foca no entendimento dos requisitos, conceitos e opera c oes relacionados com o sistema. Ela enfatiza o que deve ser feito quais s ao os processos dentro do sistema, conceitos relevantes, etc. A Figura 7.1 mostra a rela c ao entre as classes de an alise e a realiza c ao do caso de uso Efetuar Saque, apresentado no cap tulo anterior. Durante a an alise, um caso de uso se desdobra em diversas classes de an alise distintas que correspondem a diferentes aspectos do sistema. Os resultados concretos da etapa de an alise s ao: (i) um diagrama de classes de an alise, que descreve os conceitos relevantes do sistema; e (ii) um conjunto de diagramas de intera c ao, que representam os cen arios aos quais o sistema deve dar suporte. Neste cap tulo, e descrita a etapa de transi c ao da an alise OO para o projeto OO. Mais especicamente, s ao descritos os est agios iniciais do projeto orientado a objetos e a maneira como estes se relacionam com os artefatos produzidos pela an alise. Na etapa de projeto, o foco do desenvolvimento muda do dom nio do problema para o dom nio da solu c ao. O projeto OO enfatiza a maneira como os requisitos ser ao satisfeitos pelo sistema. O projeto orientado a objetos transforma o modelo conceitual criado durante a an alise em um modelo de projeto que oferece um conjunto de diretrizes para a constru c ao do sistema de software. Os resultados concretos produzidos pelo projeto OO s ao: (i) um diagrama de classes de projeto, similar ao diagrama de classes de an alise, s o que mais detalhado e focado no dom nio da solu c ao; e 221
222
Realizaes dos Casos de Uso e Classes de Anlise
Cap tulo 7: Transi c ao da An alise para o Projeto
Modelo de Casos de Uso

. . . . << boundary >> Terminal . . . << boundary >> FrtCadastroContas << boundary >> FrtDispensadorNotas << control >> CtlCaixa
<< entity >> Banco Efetuar Saque . << entity >> Conta << entity >> CaixaEletronico << entity >> FichaCliente
Efetuar Saque
Figura 7.1: Realiza c ao do caso de uso Efetuar Saque durante a an alise. (ii) um conjunto de realiza c oes de casos de uso, que denem a maneira como as classes de projeto colaboram a m de oferecer o comportamento especicado pelos casos de uso. Durante a etapa de projeto, as classes de an alise, junto com o comportamento agregado a elas denido pelos diagramas de seq u encia, s ao transformadas nas realiza c oes dos casos de uso. Embora as diversas metodologias existentes para projeto OO preescrevam diferentes seq u encias de passos, pode-se dizer que todas dividem a fase de projeto em duas grandes etapas: (i) o projeto arquitetural; e (ii) o projeto detalhado. O projeto arquitetural, ou projeto de sistema[39], tem o objetivo de denir a estrutura geral do sistema, sua quebra em componentes, os relacionamentos entre esses componentes e a maneira como eles interagem. O principal artefato produzido pelo projeto arquitetural e a deni c ao da arquitetura do sistema. A arquitetura de um sistema de software reete o primeiro conjunto de decis oes que devem ser tomadas no projeto desse sistema; aquelas que s ao mais dif ceis de mudar em etapas posteriores do desenvolvimento. Em decorr encia disso, e atribu da uma import ancia cada vez maior ` a etapa de projeto arquitetural do desenvolvimento de um sistema pois ela pode ser o fator que determina a falha ou sucesso de um projeto. Uma arquitetura de software orientada a objetos compreende um conjunto de regras, diretrizes, interfaces e conven c oes usadas para denir como aplica c oes se comunicam e interoperam umas com as outras atrav es de t ecnicas orientadas a objetos [35]. A arquitetura de software est a relacionada com a complexidade global do sistema e com a integra c ao dos seus subsistemas. No desenvolvimento de uma arquitetura de software orientada a objetos, o foco est a na deni c ao da infraestrutura e da interface entre os componentes de software. O objetivo principal e o oferecimento de um ambiente con avel e de f acil manuten c ao onde aplica co es possam cooperar e evoluir de acordo com as necessidades dos usu arios. Para que esse objetivo seja alcan cado, o arquiteto de software precisa denir um conjunto de abstra c oes que sejam efetivas no controle da complexidade do sistema, das suas mudan cas, e outras necesidades. Al em disso, o projetista deve preocupar-se com outras
223
quest oes, como por exemplo, particionamento do sistema em subsistemas menores, determina c ao do uxo de controle interno da arquitetura, deni c ao de camadas e protocolos de intera c ao entre as mesmas, aloca c ao de software/hardware, etc. A etapa de projeto detalhado, ou projeto de classes[26], descreve as classes do sistema, seus relacionamentos e as intera c oes entre suas inst ancias em tempo de execu c ao. No projeto detalhado, as classes de projeto (identicadas renando-se as classes de an alise) s ao especicadas de maneira minunciosa; atributos e estruturas de dados que devem ser mantidos em tempo de execu c ao s ao denidos e opera c oes s ao descritas de maneira precisa. O objetivo do projeto detalhado e produzir um modelo do sistema que possa ser implementado de maneira n ao-amb gua pelos programadores. Assim como foi dito para o est agio de an alise, n ao se deve esperar acertar em todas as decis oes de projeto em uma primeira tentativa. A principal vantagem de usar um processo iterativo de desenvolvimento e exatamente o fato de ser poss vel voltar atr as e corrigir eventuais equ vocos. Neste livro nos concentramos no projeto arquitetural. Al em disso, apresentamos sucintamente um exemplo da aplica c ao de alguns padr oes de projeto [19]. Padr oes de projeto encontram-se num n vel de abstra c ao intermedi ario entre o projeto arquitetural e o projeto detalhado. Normalmente padr oes de projeto s ao usados para renar os componentes de uma arquitetura. Esse renamento e usado como ponto de partida para as atividades do projeto detalhado. Na Se c ao 7.6 ser a utilizado o padr ao State[19] para aplicar uma das extens oes sugeridas na Se c ao 6.8 do Cap tulo 6 no Sistema de Caixa Autom atico. Os exemplos utilizados neste Cap tulo se baseiam no Sistema de Caixa Autom atico descrito no Cap tulo 6. O diagrama de classes de an alise apresentado na Figura 6.22 e tomado como ponto de partida.
7.1
Fases do Projeto
As metodologias para projeto OO preescrevem tarefas de alto n vel, semelhantes ` as vistas no Cap tulo 3, ao falar de metodologias para an alise OO. Nesta se c ao, ser a examinada de forma sucinta a organiza c ao da fase de projeto das metodologias OMT e RUP.
7.1.1
OMT
O projeto na metodologia OMT se divide em duas grandes fases: (i) o Projeto do Sistema e (ii) o Projeto de Objetos. Essas fases correspondem, respectivamente, ao projeto arquitetural e ao projeto detalhado. O projeto do sistema preocupa-se com decis oes a respeito da arquitetura geral do sistema. Neste est agio, o sistema e dividido em subsistemas. Tomando o diagrama de classes de an alise como guia, s ao realizadas as atividades mostradas na sequ encia de atividades a seguir: 1. Organizar o sistema em subsistemas;
224
2. Identicar a concorr encia inerente no problema; 3. Alocar os subsistemas a processos e tarefas; 4. Escolher as estrat egias para implementar banco de dados; 5. Identicar os recursos compartilhados e determinar os mecanismos de acessos a eles. A sa da desse est agio e o Documento de Projeto do Sistema que dene a estrutura b asica da arquitetura do sistema, bem como as decis oes de estrat egias de alto-n vel. O projeto de objetos preocupa-se com estruturas de dados e algoritmos necess arios para implementar cada classe do modelo de objetos. Durante este est agio, os aspectos din amicos e funcionais s ao combinados e renados. Al em disso, os uxos de controle entre os objetos s ao detalhados. Os passos para a realiza c ao desta fase podem ser vistos na seq u encia de atividades a seguir: 1. Obter as opera c oes para o modelo de objetos a partir dos outros modelos; 2. Projetar os algoritmos para implementar as opera c oes; 3. Otimizar os caminhos de acesso a dados; 4. Ajustar a estrutura de classes para aumentar heran ca; 5. Implementar as associa c oes; 6. Determinar arepresenta c ao exata dos atributos; 7. Empacotar as classes e associa c oes em m odulos. O documento resultante do est agio de projeto de objetos e chamado de Documento de Projeto, que cont em um modelo de objetos, um modelo din amico, e um modelo funcional, todos eles com um alto n vel de detalhes relacionados ` a implementa c ao.
7.1.2
RUP
A etapa de projeto do RUP e composta por diversos uxos de atividades que incluem atividades t ao diversas como Projeto de Componentes de Tempo Real e Projeto de Banco de Dados. Os principais uxos de atividades dessa etapa, por em, s ao a Deni c ao da Arquitetura e o Projeto de interessante notar que, no RUP, a etapa de deni Componentes. E c ao da arquitetura e iniciada antes da an alise. Esse fato ressalta a import ancia crescente do projeto arquitetural nas metodologias de desenvolvimento modernas. Depois que a arquitetura e denida, a an alise e iniciada e, concorrentemente, a arquitetura inicial e renada para se adaptar ` a modelagem do problema. A deni c ao da arquitetura t ao cedo no processo de desenvolvimento visa identicar, a partir das descri c oes dos casos de uso, um conjunto de elementos arquiteturalmente importantes que
225
ser ao usados como base para a an alise. O renamento da arquitetura realizado concorrentemente ` a an alise OO visa tornar natural a passagem desta u ltima para o projeto OO. As principais atividades do projeto arquitetural no RUP s ao apresentadas a seguir: 1. Analisar a arquitetura inicial; 2. Identicar os mecanismos de projeto; 3. Identicar os elementos de projeto; 4. Incorporar os elementos de projeto existentes; 5. Descrever a arquitetura de tempo de execu c ao; 6. Descrever aspectos relativos a distribui c ao. O principal artefato produzido pelo projeto arquitetural e um Documento de Arquitetura de Software. O n vel de detalhe deste documento depende da itera c ao na qual o desenvolvimento se encontra. Nas itera c oes iniciais, ele inclue apenas diretrizes de projeto e conceitos relevantes em um alto n vel de abstra c ao. Em itera c oes subseq uentes, diversos elementos adicionais como divis ao em camadas e tecnologias empregadas s ao inclu dos. No projeto de componentes, os elementos de projeto de alto n vel identicados durante o projeto arquitetural s ao renados at e um n vel de abstra ca o que permita que programadores possam implement a-los de forma direta. O projeto de componentes compreende as seguintes atividades: 1. Projeto de classes; 2. Projeto de subsistemas; 3. Projeto de banco de dados (opcional). Este uxo de atividades produz como sa das (i) um diagrama de classes de projeto, (ii) um documento de projeto de subsistemas, especicando as interfaces dos subsistemas e as intera c oes entre eles, e (iii) um modelo de dados.
7.2
Propriedades N ao-Funcionais do Sistema Realizadas na Arquiteturas de Software
Nas discu c oes sobre arquiteturas de software, freq uentemente se faz refer encia ` as propriedades/requisitos n ao-funcionais do sistema que s ao satisfeitos pela arquitetura; em contraste, as propriedades funcionais da arquitetura s ao assumidas implicitamente. Uma propriedade funcional lida com algum aspecto particular da funcionalidade do sistema e est a usualmente relacionada a um requisito
226
funcional especicado. No passado, os desenvolvedores de software concentravam-se principalmente nas propriedades funcionais dos sistemas. Entretanto, nos sistemas de software modernos, as propriedades n ao-funcionais est ao se tornando cada vez mais importantes. Como mostrado no Cap tulo 2 (Se c ao 2.1), uma propriedade n ao-funcional (ou administrativa) denota uma caracter stica de um sistema que n ao e coberta pela sua descri c ao funcional. Uma propriedade n ao-funcional tipicamente est a relacionada a aspectos como, por exemplo, conabilidade, adaptabilidade, interoperabilidade, usabilidade, persist encia, manutenabilidade, distribui c ao e seguran ca. As propriedades n ao-funcionais de uma arquitetura de software t em um grande impacto no seu desenvolvimento, manuten c ao e extens ao. Quanto maior e mais complexo um sistema de software for e quanto maior for seu tempo de vida, maior ser a a import ancia das suas propriedades n ao-funcionais. Como conseq u encia, as decis oes de projeto que devem ser tomadas no desenvolvimento de uma arquitetura de software geralmente s ao complexas e envolvem v arios aspectos relacionados com as suas propriedades n ao-funcionais do sistema. Com o objetivo de se tomar boas decis oes de projeto, e essencial que o contexto do problema seja bem denido, a m de que seja poss vel identicar as melhores escolhas dentre as diversas op c oes de projeto poss veis. Um modo de claricar esse contexto e aplicar a t ecnica de separa c ao de interesse1 [38]. Para que os diversos aspectos envolvidos no projeto de uma arquitetura de software possam ser separados, e necess ario inicialmente o estabelecimento dos limites conceituais entre eles. Cada parti c ao obtida ser a respons avel por resolver um subconjunto dos requisitos propostos. O arquiteto de software tem a responsabilidade de compor as diferentes parti c oes de modo que todos os requisitos sejam conjuntamente satisfeitos.
7.3
Vis oes da Arquitetura de Software
At e o meio dos anos 90, devido ` a juventude da area de pesquisa de arquitetura de software, diversos trabalhos foram publicados nos quais representa c oes arquiteturais falhavam em expressar as id eias de seus autores. Em 1995, Philippe Kruchten [28] publicou um artigo bastante inuente em que argumentava que a causa para esse problema era a insist encia dos autores em representar toda a arquitetura do sistema atrav es de uma u nica abstra c ao. Kruchten defendia a id eia de que a arquitetura de um sistema de software precisa ser representada atrav es de quatro vis oes diferentes e ortogonais entre si: (i) l ogica, (ii) de desenvolvimento, (iii) de processos e (iv) f sica. A conex ao entre essas quatro vis oes e feita atrav es de uma quinta vis ao que inclui elementos de todas elas, a vis ao de casos de uso. Essas cinco vis oes s ao descritas a seguir:
Vis ao l ogica: est a relacionada aos requisitos funcionais do sistema. Na vis ao l ogica, o sistema e decomposto em um conjunto de abstra c oes extra das principalmente do dom nio do problema, na forma de objetos ou classes que se relacionam. A vis ao l ogica descreve tanto estrutura est atica quanto estrutura din amica do sistema e e representada, na UML, atrav es de diagramas de classes e de diagramas din amicos (seq u encia, colabora c ao, atividades, etc.). Uma vers ao inicial da vis ao l ogica da arquitetura do sistema e fornecida pelo diagrama
1
Do Ingl es separation of concerns.
227
de classes de an alise e pelos diagramas de seq u encia e colabora c ao produzidos durante a modelagem din amica. Vis ao de desenvolvimento: foca na organiza c ao do sistema em m odulos de c odigo. A vis ao de desenvolvimento e representada, na UML, atrav es de diagramas de componentes poss contendo m odulos, bibliotecas e as depend encias entre esses elementos. E vel tamb em represent a-la, de forma mais simplicada, usando-se diagramas de pacotes (Se c oes 1.2.2, 2.9.7 e 4.8). Vis ao de processos: a vis ao de processos lida com a divis ao do sistema em processos e processadores. Ela trata de aspectos relacionados ` a execu c ao concorrente e distribu da do sistema e, atrav es dela, requisitos n ao-funcionais como performance, toler ancia a falhas e disponibilidade s ao realizados. A vis ao de processos e representada, na UML, atrav es de diagramas din amicos, assim como diagramas de componentes e implanta c ao. Esta vis ao tamb em e conhecida como vis ao de concorr encia. A vis ao de processos costuma ser de especial import ancia para a constru c ao de sistemas com requisitos ligados a temporiza c ao e sincroniza c ao, como sistemas de controle e de tempo real. Vis ao f sica: esta vis ao leva em considera c ao principalmente os requisitos n ao-funcionais do sistema, em especial os que est ao relacionados com sua organiza c ao f sica, como toler ancia a falhas, escalabilidade e performance. Na vis ao f sica, tamb em conhecida como vis ao de implanta c ao, o sistema e representado como um conjunto de elementos que se comunicam e que s ao capazes de realizar processamento (como computadores e outros dispositios). A UML d a suporte ` a vis ao f sica atrav es de diagramas de implanta c ao. Vis ao de casos de uso: esta vis ao, tamb em conhecida como vis ao de cen arios, e respons avel por integrar as outras quatro e descreve a funcionalidade oferecida pelo sistema aos seus atores. Esta vis ao apresenta informa c ao redundante com rela c ao ` as outras vis oes e e usada desde o in cio do desenvolvimento, para expressar os requisitos, at e o nal, quando testes de aceita c ao s ao realizados. A vis ao de casos de uso e representada, na UML, atrav es de diagramas e especica c oes de casos de uso. Esse modelo para a representa c ao de arquiteturas de software foi batizado de Modelo 4+1 e se tornou praticamente um padr ao na ind ustria[26] e na academia[5]. A Figura 7.2 aparece em quase todos os textos nos quais o modelo 4+1 e mencionado e mostra como as cinco vis oes se relacionam. A Tabela 7.3 mostra um resumo das vis oes do modelo 4+1, com os respectivos requisitos e participantes de cada uma das vis oes.
7.4
O Padr ao Arquitetural de Camadas
No projeto OO, e necess ario particionar o modelo de an alise em conjuntos coesos e fracamente acoplados de classes [29]. Esses conjuntos, chamados subsistemas, incluem tanto as classes propriamente ditas quanto seus comportamentos e os relacionamentos entre elas. Eles podem estar envolvidos na realiza c ao de um mesmo conjunto de requisitos funcionais, residir dentro de um mesmo
228
Viso Lgica Viso de Casos de Uso Viso de Desenvolvimento
Viso de Processos
Viso de Implantao
Figura 7.2: O modelo 4+1 para a representa c ao de arquiteturas de software. Tabela 7.1: Resumo das Vis oes do Modelo 4+1 o Visa Vis ao L ogica Vis ao de Processo Requisito Principal Funcionalidade Desempenho Escalabilidade Transfer encia de dados (taxa) Vis ao de Desenvolvimento Topologia do sistema Distribui c ao e instala c ao Comunica c ao Vis ao F sica Vis ao de Casos de Uso Gerenciamento do Software Comportamento Programador Analista de sistemas Analista de testes Engenheiro de Sistema Participante Principal Usu ario Final Integrador do Sistema
produto de hardware ou gerenciar um mesmo tipo de recurso[39]. Subsistemas normalmente s ao identicados pelos servi cos que oferecem, denidos atrav es das opera c oes de suas interfaces. Consequentemente, uma das atividades mais importantes do projeto arquitetural e a especica c ao das interfaces dos subsistemas. Al em disso, um subsistema pode depender de outros subsistemas, assumindo o papel de cliente, e oferecer servi cos que s ao utilizados por outros subsistemas, assumindo o papel de servidor. Pressman[39] apresenta uma lista de crit erios de projeto com os quais subsistemas em qualquer projeto de desenvolvimento OO devem estar em conformidade: O subsistema deve ter uma interface bem denida atrav es da qual ocorre toda a comunica c ao com o resto do sistema. Com exce c ao de um pequeno n umero de classes de comunica c ao, as classes em um subsis-
Cap tulo 7: Transi c ao da An alise para o Projeto tema devem colaborar apenas com outras classes dentro do pr oprio subsistema.
229
O n umero de subsistemas deve ser pequeno, onde o signicado de pequeno depende do projeto e deve ser julgado pelo arquiteto de software, normalmente um membro experiente do time de desenvolvimento. Um subsistema pode (e deve) ser particionado internamente, a m de reduzir sua complexidade. Quando um sistema e particionado em subsistemas, uma outra atividade ocorre concorrentemente: a divis ao em camadas. Cada camada de um sistema OO cont em um ou mais subsistemas e e respons avel por um conjunto de funcionalidades relacionadas. Normalmente, em sistemas estruturados em camadas, subsistemas localizados em uma determinada camada n usam os servi cos oferecidos pelos subsistemas da camada n + 1 (abaixo) e oferecem servi cos para os subsistemas da camada n 1 (acima). As camadas n 1 e n + 1 n ao enxergam uma ` a outra diretamente[5]. Sendo assim, uma camada esconde de suas camadas superiores, os detalhes das implementa c oes das camadas inferiores, tornando poss vel que a implementa c ao de uma camada seja trocada sem que o sistema inteiro seja afetado. Uma estrutura c ao em camadas muito utilizada para a constru c ao de sistemas de informa c ao, especialmente os baseados na web, consiste em utilizar tr es camadas: (i) uma respons avel pela intera c ao entre o sistema e o usu ario, (ii) uma outra respons avel por implementar as regras de neg ocio da aplica c ao e (iii) uma terceira que lida com o armazenamento dos dados. A divis ao das classes de an alise entre os tr es tipos descritos na Se c ao 3.10.1 (fronteira, controle e entidade) tem suas ra zes na estrutura c ao em tr es camadas. Arquiteturas de software organizadas de acordo com essa divis ao s ao conhecidas como Arquiteturas Three-Tier (ou arquiteturas em tr es camadas). Um exemplo de arquitetura em tr es camadas e apresentado na pr oxima se c ao.
7.5
Arquitetura do Sistema de Caixa Autom atico
Particionar o sistema do estudo de caso apresentado no Cap tulo 6 em subsistemas e uma tarefa simples, tendo em vista que as classes de an alise s ao poucas e com responsabilidades bem denidas. As classes Terminal e FronteiraDispensadorNotas representam as classes do sistema nal respons aveis pela intera c ao entre o usu ario e o sistema. Da pode-se deduzir que, durante o projeto detalhado, essas classes se transformar ao em um conjunto de classes, todas envolvidas na realiza c ao de um mesmo conjunto de requisitos. Conforme recomendado pela Se c ao 7.4, todas essas classes ser ao agrupadas em um mesmo subsistema (Interface com o Usu ario). As classes CaixaEletronico, Conta, ControladorCaixa e DadosCliente dizem respeito ` as regras de neg ocios da aplica c ao. ControladorCaixa representa as regras de neg ocios relativas ` as realiza c oes dos casos de uso, como por exemplo, transfer encias feitas entre contas do mesmo cliente n ao requerem cobran ca de CPMF. Conta, por sua vez, dene as regras de neg ocio que dizem respeito a todas as contas, por exemplo, uma senha n ao pode ter menos que 5 d gitos. O mesmo para as classes
230
DadosCliente e CaixaEletronico. Tendo essas informa c oes em vista, ca claro que essas classes n ao podem fazer parte do subsistema Interface com o Usu ario, j a que n ao lidam com a intera c ao entre o usu ario e o sistema. Conseq uentemente, um novo subsistema necessita ser denido: Regras de Neg ocio, do qual todas as classes relacionadas ` as regras de neg ocio da aplica c ao fazem parte. A classe FronteiraCadastroContas dene servi cos atrav es dos quais o sistema pode se comunicar com o Cadastro de Contas do Banco. Conforme visto no Cap tulo 6, e no Cadastro de Contas do Banco que os dados sobre as contas s ao armazenados. Conseq uentemente, a classe FronteiraCadastroContas e o meio atrav es do qual esses dados podem ser lidos e escritos. Tendo isso em vista e sabendo que FronteiraCadastroContas n ao implementa regras de neg ocios, pode-se denir um novo subsistema para localizar as classes respons aveis pelo acesso aos dados do sistema. Esse novo subsistema pode ser chamado de Dados. A Figura 7.3 representa gracamente o particionamento descrito. Essa gura evidencia ainda decis oes tomadas em rela c ao ` a distribui c ao f sica de cada um dos tr es m odulos do sistema. Dessa forma, enquanto a Interface com o Usu ario e considerado parte do m odulo cliente, os demais subsistemas constituem o m odulo servidor.
Mdulo Cliente
Interface com o Usurio
Regras de Negcio
Dados
Mdulo Servidor
Figura 7.3: Subsistemas do Sistema de Caixa Autom atico Vis ao L ogica. O Sistema de Caixa Autom atico usa uma arquitetura em tr es camadas, conforme descrito na se c ao anterior, sendo uma delas localizada do lado cliente (Interface com o Usu ario) e as demais do lado servidor (Regras de Neg ocio e Dados). Essa e a escolha mais natural para esse sistema, tendo em vista a sua divis ao em tr es subsistemas representando aspectos diferentes (interface com o usu ario, neg ocios e dados). As camadas seguem essa mesma divis ao e, daqui por diante, os termos cliente, neg ocios e dados ser ao utilizados para designar tanto as camadas correspondentes aos subsistemas de Interface com o Usu ario, Regras de Neg ocios e Dados, respectivamente, quanto os subsistemas propriamente ditos. Ap os particionar as classes de an alise entre subsistemas e denir as camadas, o arquiteto deve denir as interfaces entre elas. Apesar da semelhan ca da nomenclatura, essas interfaces n ao s ao o
231
mesmo que o conceito de interface denido por Java (Se c ao 4.7), embora possam ser materializadas atrav es delas, durante a implementa c ao do sistema. Interfaces entre camadas na arquitetura est ao em um n vel de abstra c ao muito mais alto do que aquelas no n vel da implementa c ao. Neste est agio, o foco est a na maneira como a comunica c ao entre as camadas e entre os subsistemas ocorrer a, em quest oes como, por exemplo: (i) quais classes representar ao os pontos de acesso ` as camadas; e (ii) quais tecnologias ser ao usadas para mediar a comunica c ao entre elas. Em alguns casos, decis oes relacionadas ` as tecnologias utilizadas na constru c ao de um sistema s ao restri c oes de projeto especicadas desde a etapa de requisitos e o trabalho do arquiteto de software e simplesmente projetar sua arquitetura tendo esse fator em vista. Em outros, o arquiteto tem a liberdade para escolher e deve levar em considera c ao os diversos aspectos positivos e negativos de cada estilo arquitetural, tendo sempre em mente as caracter sticas desejadas do sistema. No caso do Sistema de Caixa Autom atico, algumas restri c oes foram impostas desde a sua concep c ao. Por exemplo, a tecnologia de banco de dados empregada e aquela utilizada pelo Cadastro de Contas do Banco. O sistema deve ser capaz de se comunicar com este u ltimo e o arquiteto n ao tem, a priori, nenhuma autoridade sobre a maneira como os dados s ao armazenados. Por outro lado, diversos aspectos foram deixados em aberto. Por exemplo, a camada de neg ocios est a localizada sicamente no mesmo local que a de cliente, ou em algum outro lugar? Em outras palavras, e necess ario que alguma tecnologia de distribui c ao seja utilizada na comunica c ao entre as camadas de cliente e neg ocios? Ser ao tomadas apenas duas decis oes no que concerne ` a intera c ao entre as camadas. Em primeiro lugar, ser a considerado que a comunica c ao entre as camadas de cliente e neg ocios e distribu da. N ao ser a feita nenhuma restri c ao, por em, sobre qual tecnologia dever a ser empregada. O objetivo neste ponto e apenas construir o sistema de tal maneira que seja f acil torn a-lo distribu do, se isso for necess ario. Para tanto, ser ao introduzidas duas classes adicionais, adaptadores distribu dos [2], no diagrama de classes de projeto (antigo diagrama de classes de an alise). Uma delas faz parte da camada cliente (AdaptadorCliente) e a segunda e parte da camada de neg ocios (AdaptadorServidor). Durante o projeto detalhado, essas classes ser ao renadas de acordo com a(s) tecnologia(s) de distribui c ao empregada(s). desej A outra decis ao diz respeito ao acesso aos dados. E avel que, se os dados do Sistema de Caixa Autom atico forem movidos para uma nova base que utilize um sistema de gerenciamento de banco de dados diferente, o sistema possa ser adaptado a esta mudan ca com um m nimo de altera c oes. Para alcan car esse objetivo, deve-se utilizar a abordagem sugerida na Se c ao 4.7.3 para integra c ao objeto-relacional. Essa abordagem e gen erica o suciente para desacoplar as camadas de neg ocios e dados, independentemente do tipo de banco de dados utilizado (relacional, orientado a objetos, hier arquico, etc.). Na Figura 7.4 e apresentado o mapeamento entre as classes de an alise e as de projeto, tendo em vista as decis oes arquiteturais tomadas. Note que essas classes de projeto ser ao renadas em etapas subseq uentes dessa fase. Detalhes ser ao adicionados a essas classes e diversas novas classes surgir ao. Vale ressaltar que a pr opria organiza c ao em camadas pode mudar, devido a decis oes arquiteturais tomadas a posteriori. Por exemplo, devido ao uso de adaptadores distribu dos, poderia ser adequado denir uma nova camada, de distribui c ao, respons avel por encapsular toda a comunica c ao remota entre as camadas de cliente e de neg ocios. A decis ao quanto a criar uma nova camada ou
232
Modelo de Anlise
<< boundary >> FronteiraDispensadorNotas << control >>
<< entity >> Banco
<< entity >> DadosCliente
ConrtoladorCaixa
<< boundary >> Terminal
<< entity >> CaixaEletronico
<< entity >> Conta
<< boundary >> FronteiraCadastroContas
Modelo de Projeto
Terminal AdaptadorServidor CaixaEletronico Conta << interface >> IRepositorioDeContas FronteiraDispensadornotas AdaptadorCliente ControladorCaixa Banco DadosCliente RepositorioDeContasBDR
Figura 7.4: Mapeamento inicial entre as classes de an alise e as classes de projeto.
n ao deve ser tomada levando em considera c ao a necessidade de modicar a implementa c ao de um conjunto de classes respons aveis por uma mesma fun c ao. Por exemplo, e justic avel criar uma camada de dados, uma vez que pode ser necess ario mudar a maneira como os dados do sistema s ao armazenados e, idealmente, essa mudan ca n ao deve afetar as outras camadas do sistema. Por enquanto, foi resolvido deixar a arquitetura do sistema como est a. A Figura 7.5 apresenta a divis ao de camadas da arquitetura do sistema, levando em considera c ao as classes de projeto pertencentes a cada uma.
FronteiraDispensadornotas
CaixaEletronico
Conta
Terminal
AdaptadorServidor
ControladorCaixa
<< interface >> IRepositorioDeContas
RepositorioDeContasBDR
AdaptadorCliente
Banco
DadosCliente
Figura 7.5: Divis ao das classes de projeto entre as camadas da arquitetura.
7.6
O Padr ao de Projeto State
O padr ao de projeto State permite que um objeto altere seu comportamento quando seu estado interno muda. Ele usa delega c ao e agrega c ao para lidar com situa c oes em que uma classe precisa se comportar de maneiras diferentes em diferentes circunst ancias.
233
7.6.1
Problema
Em algumas situa c oes, o comportamento de um objeto depende do seu estado e precisa ser modicado em tempo de execu c ao, quando esse estado muda. Normalmente, esse problema e resolvido atrav es de m etodos que usam comandos condicionais para decidir qual comportamento deve ser adotado, dependendo do estado do objeto. Essa abordagem n ao e recomendada, por em, porque o c odigo pode ser repetido em v arios m etodos (tanto c odigo relativo ` as condi c oes quanto ao comportamento). Al em disso, um n umero grande de condi c oes complexas torna o c odigo dos m etodos muito dif cil de entender e manter.
7.6.2
Solu c ao
Criar classes que encapsulam os diferentes estados do objeto e os comportamentos associados a esses estados. Dessa forma, a complexidade do objeto e quebrada em um conjunto de objetos menores e mais coesos. A Figura 7.6 mostra a estrutura geral do padr ao State.
Estado operacao() operacao()
Contexto
estado
estado.operacao() EstadoConcreto1 operacao() EstadoConcreto2 operacao()
(...)
Figura 7.6: Estrutura do Padr ao State. Na Figura 7.6, a classe Contexto dene objetos cujos estados s ao decompostos em diversos objetos diferentes, denidos por subtipos da classe abstrata Estado. A classe Estado dene uma interface unicada para encapsular o comportamento associado a um estado particular de Contexto, que mant em uma refer encia para uma inst ancia de uma subclasse concreta de Estado. Cada subclasse concreta de Estado implementa o seu respectivo comportamento associado. Contexto delega requisi c oes dependentes de estado para o objeto EstadoConcreto atual. Contexto pode passar a si mesmo como argumento para o objeto do tipo Estado respons avel por tratar a requisi c ao. Clientes podem congurar um contexto com objetos do tipo Estado. Uma vez que isso seja feito, por em, esses clientes passam a se comunicar apenas com o objeto do tipo Contexto e n ao interferem mais no seu estado diretamente.
234
7.6.3
Conseq u encias
O padr ao State tem as seguintes conseq u encias: Localiza o comportamento dependente de estado e particiona o comportamento relativo a diferentes estados. O padr ao substitui uma classe Contexto complexa por uma classe Contexto muito mais simples e um conjunto de subclasses de Estado altamente coesas. Torna transi c oes de estado expl citas, ao inv es de espalh a-las em comandos condicionais. Torna o estado de um objeto compartilh avel, embora essa caracter stica deva ser explorada somente quando esse estado consistir apenas de comportamento, sem dados (como no padr ao de projeto Flyweight [19]).
7.6.4
Aplica c ao do Padr ao State ao Sistema de Caixa Autom atico
Como exemplo, ser a utilizada a extens ao do Sistema de Caixa Autom atico sugerida na Se c ao 6.8. Cada conta tem um status associado que indica se ela est a ativa ou inativa. No segundo caso, saques e quaisquer outras opera c oes que modiquem o saldo atual da conta n ao podem ser realizadas. Uma abordagem alternativa de modelagem para essa situa c ao seria criar uma vari avel do tipo boolean chamada ativa que teria valor false se a conta estivesse inativa e true se estivesse ativa (Figura 7.7). O problema dessa solu c ao e que m etodos da classe Conta, como efetuarSaque(), teriam que vericar o estado atual do objeto antes de executar. Esse tipo de verica c ao e f acil de implementar quando apenas dois estados s ao poss veis. Se um terceiro estado for adicionado, por em, todos os m etodos dependentes do estado precisar ao ser modicados para acomodar o novo comportamento. Isso nos leva a perceber que uma solu c ao alternativa seria bastante u til. Essa solu c ao alternativa e o padr ao State.
Conta estaAtiva:boolean +debitar(quant:float):void
public void debitar(float quant){ (...) if (estaAtiva){ //realizar o saque } else //imprimir mensagem de erro }
Figura 7.7: Modelagem simplicada Para utilizar o padr ao State, deve-se modelar o status de uma conta como um conjunto de classes separadas, cada uma implementando um estado e o comportamento associado. Desse modo
235
tem-se uma classe Conta que referencia objetos do tipo Estado, e duas classes correspondentes aos valores poss veis para o atributo status, Ativa e Inativa, ambas subclasses de Estado. Esta segunda op c ao de modelagem e apresentada na Figura 7.8.
Soluo Indicada
Conta saldo :float + creditar (quant :float ):void + debitar (quant :float ):void ~obterSaldo ():float ~ajustarSaldo (valor :float ):void ~proximoEstado ():void //creditar() status.debitar(this, quant); ... //debitar() status.creditar(this, quant);
Status
~creditar (ct :Conta ,quant :float ):void ~debitar (ct :Conta ,quant :float ):void
Ativa
Inativa
Figura 7.8: Modelagem usando o padr ao State O trecho de c odigo seguinte apresenta uma implementa c ao parcial para a segunda op c ao de modelagem.
// arquivo Conta.java package conta; public class Conta { double saldo = 0; private Status status = null; int numero = 0;
public Conta(int argNum, Status argInicial, double argSld) { this.status = argInicial; this.saldo = argSld; this.numero = argNum; } public void debitar(double qtd) { this.status.debitar(this, qtd); }
236
Cap tulo 7: Transi c ao da An alise para o Projeto void proximoEstado(Status proximo) { this.status = proximo; } }
A implementa c ao do m etodo debitar() da classe Conta chama o m etodo debitar() do objeto correspondente ao seu status (Linha 14). Isso e feito por todas as opera c oes que dependem do status atual da conta. Al em disso, no trecho de c odigo acima, note que o m etodo proximoStatus() (Linhas 16 a 18) e declarado com visibilidade de pacote. Desse modo, apenas classes declaradas no mesmo pacote (conta) t em acesso a esse m etodo. O m etodo proximoStatus() da classe Status, apresentado a seguir, e respons avel por chamar o m etodo proximoStatus() da classe Conta. A decis ao sobre qual ser a o pr oximo status, por em, depende da implementa c ao do padr ao State. Em nossa implementa c ao, as subclasses concretas de Status denem qual ser a o pr oximo status da execu c ao. Como proximoStatus() e declarado com visibilidade protegida na classe Status, as subclasses de Status podem chamar esse m etodo com o m de denir o pr oximo estado de um objeto do tipo Conta. O trecho de c odigo seguinte apresenta implementa c oes para as classes Status, Inativa e Ativa.
// arquivo Status.java package conta; public abstract class Status { public abstract void debitar(Conta ct, double qtd); protected void proximoEstado(Conta ct, Status proximo) { ct.proximoEstado(proximo); } }
// arquivo Inativa.java package conta.status; public class Inativa extends Status { public void debitar(Conta ct, double qtd) { System.out.println("Conta inativa. Nao e possivel realizar" + "o saque."); }
Cap tulo 7: Transi c ao da An alise para o Projeto public void creditar(Conta ct, double qtd) { if(qtd > 0) { ct.saldo = ct.saldo + qtd; this.proximoEstado(ct, new Ativa()); // ativa a conta ct. } } }
237
// arquivo Ativa.java package conta.status; public class Ativa extends Status {
public void debitar(Conta ct, double qtd) { if(qtd <= ct.saldo && qtd > 0) { ct.saldo = ct.saldo - qtd; if(ct.saldo == 0) { // deve desativar a conta this.proximoEstado(ct, new Inativa()); } } } public void creditar(Conta ct, double qtd) { if(qtd > 0) { ct.saldo = ct.saldo + qtd; } } }
O m etodo debitar() e denido como abstrato na classe Status e implementado na classe Inativa (Linha 13). Essa implementa c ao apenas emite uma mensagem de erro, informando que n ao se pode realizar saques em contas inativas. Uma conta torna-se inativa automaticamente quando seu saldo chega a zero, como pode ser percebido pela implementa c ao do m etodo debitar() da classe Ativa
238
(Linhas 32 e 33). Quando uma conta bloqueada recebe um dep osito e seu saldo se torna maior que zero novamente, o m etodo proximoEstado() da classe Status e invocado (Linha 20), indicando que a conta deve ser reativada.
7.7
O Padr ao de Projeto Singleton
O padr ao singleton busca principalmente garantir que uma classe tenha sempre uma u nica inst ancia que possa ser acessada por v arios clientes distintos. Al em disso, o uso desse padr ao faz com que a classe ofere ca um ponto global de acesso a ela. Exemplos de classes implementadas por esse padr ao s ao as classes com multiplicidade pr e-denida, como por exemplo, as classes de fronteira e de controle do padr ao MVC, que possuem multiplicidade 1. O conceito de multiplicidade foi apresentado no Cap tulo 1 (Se c ao 1.3.3) e o padr ao MVC foi apresentado no Cap tulo 3 (Se c ao 3.10.1). A implementa c ao do padr ao singleton se baseia no ocultamento de informa c oes, atrav es do conceito de visibilidade visto no Cap tulo 4.
7.7.1
Problema
Em algumas situa c oes, e importante que as classes garantam a exist encia de apenas uma inst ancia sua. Por exemplo, apesar de um sistema poder ter v arias impressoras, deve existir apenas um spool de impress ao para controlar a la. Normalmente esse problema e resolvido utilizando vari aveis globais (uma para cada inst ancia desejada), mas al em de aumentar a complexidade do sistema, essa solu c ao e limitada no sentido de n ao permitir aumentar facilmente o n umero de inst ancias poss veis. Uma solu c ao mais adequada e tornar a classe respons avel por si mesma, garantingo que haja somente uma inst ancia. Por se tratar de um acesso centralizado, a classe pode garantir que nenhuma outra inst ancia possa ser criada, atrav es da intersepta c ao de todas as requisi c oes de cria c ao de novas inst ancias.
7.7.2
Solu c ao
Dene uma opera c ao de instancia c ao que permite o acesso por parte dos clientes. Essa opera c ao deve pertencer ` a classe, isto e, ser est atica e e respons avel por criar sua u nica inst ancia da classe e passar essa refer encia u nica em cada requisi c ao recebida. Na Figura 7.9, a classe Singleton, que implementa o padr ao singleton, possui um atributo de classe privado que aponta para a u nica inst ancia da pr opria classe. Al em disso, essa classe disponibiliza uma opera c ao de classe com visibilidade p ublica que e respons avel por controlar as requisi c oes de inst ancias da classe. Para concluir, a classe deve redenir o construtor padr ao da linguagem, mudando a visibilidade do mesmo para privada, a m de evitar instancia c oes diretas da classe. Como dito anteriormente, uma maneira utilizada para garantir a exist encia de uma inst ancia
239
Singleton uniqueInstance:Singleton Redefinio do construtor << create >> Singleton():Singleton +uniqueInstance():Singleton nica instncia
Mtodo de "fbrica" que retorna a nica instncia da classe.
Figura 7.9: Estrutura do Padr ao Singleton u nica e ocultar as opera c oes que instanciam a classe normalmente (os construtores), oferecendo uma opera c ao espec ca com esse objetivo. Esta opera c ao deve passar a refer encia de uma vari avel que aponte para a u nica inst ancia da classe. Sendo assim, o objeto singleton deve ser instanciado apenas uma vez, antes da sua primeira utiliza c ao. Em java, por exemplo, e poss vel denir um atributo est atico na classe Singleton que referencie um objeto do pr oprio tipo. De forma an aloga, essa classe deve oferecer um m etodo est atico que retorne a refer encia da inst ancia. Uma poss vel implementa c ao em Java para a classe Singleton e mostrada a seguir: public class Singleton { private static Singleton instancia; // vari avel que referencia a unica inst^ ancia da classe
private Singleton(); // redefini ca ~o do construtor para impedir que a classe seja instanciada public static Singleton obterInstancia(){ if (instancia == null) { instancia = new Singleton(); } return instancia; } } Os clientes da classe Singleton a acessam exclusivamente atrav es do m etodo est atico obterInstancia(). A vari avel instancia e inicializada automaticamente como null e o m etodo est atico obterInstancia() retorna o valor de instancia, inicializando essa vari avel uma u nica vez, antes da primeira requisi c ao.
7.7.3
Conseq u encias
Os principais benef cios do padr ao singleton s ao [19]:
240
Acesso controlado a uma inst ancia u nica. Devido ` as classes Singleton encapsularem suas inst ancias u nicas, e poss vel ter controle estrito sobre como e quando essas refer encias s ao acessadas pelos clientes. Redu c ao do espa co de nomes: O padr ao Singleton apresenta vantagens em rela c ao ` a utiliza c ao de vari aveis globais, uma vez que evita a explos ao do n umero dessas vari aveis. Permite o renamento de opera c oes e de representa c ao. Uma classe Singleton pode possuir poss subclasses. E vel congurar a aplica c ao com uma inst ancia da classe que voc e necessita em tempo de execu c ao, atrav es do conceito de polimorsmo de inclus ao, visto na Se c ao 4.5.5. Permite um n umero vari avel de inst ancias. O padr ao facilita a mudan ca do n umero de inst ancias permitido pela classe. Al em disso, e poss vel utilizar a mesma abordagem para controlar o n umero de inst ancias que a aplica c ao utiliza. Em qualquer um desses casos, apenas a opera c ao que retorna as inst ancias deve ser modicada.
Refer encias Bibliogr acas

[1] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977. [2] Vander Alves and Paulo Borba. Distributed adapters pattern: A design pattern for objectoriented distributed applications. In First Latin American Conference on Pattern Languages Programming, SugarLoafPLoP 2001, October 2001. Published in UERJ Magazine: Special Issue on Software Patterns, June 2002, pages 132-142. [3] Ken Arnold, James Gosling, and David Holmes. The Java Programming Language. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [4] Tsvi Bar-David. Object-oriented design for C++. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1993. [5] Len Bass, Paul Clements, and Rick Kazman. Software architecture in practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. [6] Gordon Blair, John Gallagher, and Javad Malik. Genericity vs. inheritance vs. delegation vs. conformance vs. . . .. Journal of Object-Oriented Programming, pages 1117, September/October 1989. [7] Gordon S. Blair. Basic concepts iii (types, abstract data types and polymorphism). pages 75107, 1991. [8] Grady Booch. Object oriented design with applications. Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, USA, 1991. [9] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unied Modeling Language user guide. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1999. [10] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture - A System of Patterns. John-Wiley and Sons, 1996. [11] Terry Camerlengo and Andrew Monkhouse. SCJD Exam with J2SE 5, Second Edition. Apress, Berkely, CA, USA, 2005. [12] Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan, Bill Kalsow, and Greg Nelson. Modula-3 language denition. SIGPLAN Not., 27(8):1542, 1992. 241
242
[13] Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism. ACM Comput. Surv., 17(4):471523, 1985. [14] John Cheesman and John Daniels. UML components: a simple process for specifying component-based software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [15] Alistair Cockburn. Writing Eective Use Cases. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [16] O. J. Dahl, E. W. Dijkstra, and C. A. R. Hoare. Structured Programming. Number 8 in A.P.I.C. Studies in Data Processing. Academic-Press, 1972. DAH o 72:1 1.Ex. [17] Ole-Johan Dahl. SIMULA 67 common base language, (Norwegian Computing Center. Publication). 1968. [18] Martin Fowler and Kendall Scott. UML distilled: applying the standard object modeling language. Addison-Wesley Longman Ltd., Essex, UK, UK, 1997. [19] Erich Gamma, Richard Helm, and Ralph Johnson. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley, 1995. GAM e 95:1 1.Ex. [20] Carlo Ghezzi and Mehdi Jazayeri. Programming Language Concepts. John Wiley & Sons, Inc., New York, NY, USA, 1997. [21] Adele Goldberg and David Robson. Smalltalk-80: The Language. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1989. [22] Samuel P. Harbison. Modula-3. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1992. [23] David Harel and Michal Politi. Modeling Reactive Systems with Statecharts: The Statemate Approach. McGraw-Hill, Inc., New York, NY, USA, 1998. [24] Anders Hejlsberg, Scott Wiltamuth, and Peter Golde. Addison-Wesley, Reading, MA, USA, 2003. The C# Programming Language.
[25] Ivar Jacobson. Object-Oriented Software Engineering: a Use Case driven Approach. Addison Wesley, Wokingham, England, 1995. [26] Ivar Jacobson, Grady Booch, and James Rumbaugh. The unied software development process. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999. [27] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering. Addison-Weseley, 1994. [28] Philippe Kruchten. The 4+1 view model of architecture. IEEE Software, 12(6):4250, 1995. [29] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall, 1997.
243
[30] Henry Lieberman. Using prototypical objects to implement shared behavior in object-oriented systems. In OOPLSA 86: Conference proceedings on Object-oriented programming systems, languages and applications, pages 214223, New York, NY, USA, 1986. ACM Press. [31] G. Masini, A. Napoli, D. Colnet, D. Leonard, and K. Tombre. Object Oriented Languages. Academic Press, San Diego, CA, 1991. [32] M. D. Mcllroy. Mass-produced software components. Petrocelli/Charter, 1st edition, 1976. [33] Bertrand Meyer. Object-Oriented Software Construction. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1988. [34] Bertrand Meyer. Design by contract. In Advances in Object-Oriented Software Engineering. Prentice Hall, Englewood Clis, N.J., 1991. [35] Thomas J. Mowbray and Raphael C. Malveau. CORBA design patterns. John Wiley & Sons, Inc., New York, NY, USA, 1997. [36] Glenford J. Myers. Softwear Reliability. John Wiley & Sons, Inc., New York, NY, USA, 1976. [37] Glenford J. Myers. Composite/Structured Design. van Nostrand Reinhold Company, 1st edition, 1978. [38] David L. Parnas. On the criteria to be used in decomposing systems into modules. pages 411427, 2002. [39] Roger S. Pressman. Software Engineering: A Practitioners Approach. McGraw-Hill Higher Education, 2001. [40] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Object-oriented modeling and design. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1991. [41] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Object-Oriented Modeling and Design. PrenticeHall, Englewood Clis, NJ, 1991. [42] Geri Schneider and Jason P. Winters. Applying use cases (2nd ed.): a practical guide. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 2001. [43] H.A. Simon. The architecture of complexity. In The Sciences of the Articial, pages 192229. MIT Press, Cambridge, Massachusetts, 1981. [44] Ian Sommerville. Software Engineering. Addison-Wesley, 5th edition, 1995. [45] Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [46] Clemens Szyperski. Component Software: Beyond Object-Oriented Programming. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 2002. [47] David Ungar and Randall B. Smith. Self: The power of simplicity. In OOPSLA 87: Conference proceedings on Object-oriented programming systems, languages and applications, pages 227 242, New York, NY, USA, 1987. ACM Press.
244
[48] Peter Wegner. Concepts and paradigms of object-oriented programming. SIGPLAN OOPS Mess., 1(1):787, 1990. [49] Iseult White. Using the Booch Method: A Rational Approach. Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, USA, 1994. [50] Terry Winograd and Fernando Flores. Understanding Computers and Cognition: A New Foundation for Design. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1987.

Apostila Orientacao Objetos 2009 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostila Orientacao Objetos 2009 PDF

Uploaded by

Copyright:

Available Formats

Introdu c ao ` a An alise Orientada a Objetos e Projeto Arquitetural

Cec lia Mary Fischer Rubira cmrubira@ic.unicamp.br http://www.ic.unicamp.br/cmrubira

Patrick Henrique da Silva Brito pbrito@ic.unicamp.br http://www.ic.unicamp.br/pbrito

Instituto de Computa c ao - UNICAMP

ii 1.7 Exerc cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 29 29 31 32 33 35 36 37 38 38 39 40 41 43 45 45 46 47 49 49 50 51 51 54 56 57 58 63 63 64 65 66 67 69 70 72 72 75 76 77 78 78

3.8 3.9 3.10

3.11 3.12 3.13

6.5 6.6 6.7 6.8

Est agio da An alise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Atividades da Modelagem Est atica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 ix

Cap tulo 1: Introdu c ao

Gerenciamento da Complexidade do Software

T ecnicas de Estrutura c ao de Software

Cap tulo 1: Introdu c ao

do ingl es software crisis

Cap tulo 1: Introdu c ao

Evolu c ao da Abstra c ao em Linguagens de Programa c ao

Cap tulo 1: Introdu c ao

Figura 1.1: Passos Intermedi arios da Modelagem da Realidade

Cap tulo 1: Introdu c ao

M odulos, Pacotes e Subsistemas

Cap tulo 1: Introdu c ao

e s p e c i f i c a c ao Size : Positive ; package S t a c k i s procedure Push (E : in Integer ) ;

procedure Pop (E : out I n t e g e r ) ; end S t a c k ;

Cap tulo 1: Introdu c ao

Tipos Abstratos de Dados

Programa c ao Orientada a Objetos

Cap tulo 1: Introdu c ao

Cap tulo 1: Introdu c ao

Programa c ao Orientada a Objetos vs. Programa c ao Estruturada

Objeto 4 (tipo T4)

Objeto 2 (tipo T2)

Linguagens Orientadas a Objetos

Cap tulo 1: Introdu c ao

Fundamentos do Paradigma de Objetos

Cap tulo 1: Introdu c ao

Mtodo Valores dos Atributos Mtodo

do ingl es member function

Cap tulo 1: Introdu c ao

Cap tulo 1: Introdu c ao

<< instance_of >>

(os objetos depen dem da classe)

<<. instance_of >> maria:Usuario objeto

OBS.: No contexto de um sistema de controle de bibliotecas

Figura 1.7: Exemplo de Classica c ao/Instancia c ao

Abstra c ao de Dados e Hierarquias de Abstra c oes

Cap tulo 1: Introdu c ao

Cap tulo 1: Introdu c ao

nome :String codigo :String + verificarCodigo (cod :String ):boolean

Usuario nome :String codigo :String + verificarCodigo (cod :String ):boolean

Publicacao numeroTombo :String nome :String + reservar ():void

Cap tulo 1: Introdu c ao

Cap tulo 1: Introdu c ao

Figura 1.10: Associa c oes em UML

Figura 1.11: Relacionamento de Depend encia em UML

An alise e Projeto Orientado a Objetos

Cap tulo 1: Introdu c ao

Processos Tradicionais vs. Processos Orientados a Objetos

Cap tulo 1: Introdu c ao

Cap tulo 1: Introdu c ao

Figura 1.13: Modelo Espiral

Cap tulo 1: Introdu c ao

Limita c oes do Modelo de Objetos

Engenharia de Software Baseada em Componentes