Baixe o app para aproveitar ainda mais
Prévia do material em texto
Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 5 Modelagem de Classes de Análise “O engenheiro de software amador está sempre à procura da mágica, de algum método sensacional ou ferramenta cuja aplicação promete tornar trivial o desenvolvimento de software. Ë uma característica do engenheiro de software profissional saber que tal panacéia não existe” -Grady Booch Tópicos • Diagrama de Classes • Responsabilidade e Colaboração • Identificação das Classes Iniciais • Construção do Modelo de Classes de Domínio Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 3 Tópicos • Diagrama de Classes • Responsabilidade e Colaboração • Identificação das Classes Iniciais • Construção do Modelo de Classes de Domínio Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 4 Introdução • O modelo de casos de uso fornece uma perspectiva do sistema do ponto de vista externo. • Externamente os atores visualizam resultados de cálculos, relatórios, confirmações de requisições; • Internamente os objetos colaboram entre si para formar os resultados que são visíveis ao usuário externo; • Essa colaboração pode ser vista do aspecto dinâmico e estrutural estático. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 5 Introdução • O aspecto dinâmico descreve as trocas de mensagens entre os objetos e sua reação com eventos que ocorrem no sistema. • O aspecto estrutural estático mostra como o sistema está organizado internamente; – Estático refere-se ao fato de não possuir relação com o tempo – Estrutural refere-se ao fato das estruturas das classes e das relações entre elas serem representadas. • O diagrama que representa o aspecto estrutural estático de um sistema OO é o diagrama de classes. O modelo de classes consiste no diagrama e na descrição textual associada. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 6 Modelo de Classes • O modelo de classes evolui durante o desenvolvimento do sistema; • Há três níveis: – Modelo de classes de domínio – Representa as classes no domínio do negócio, é construído ainda na análise e não leva em consideração as restrições da tecnologia utilizada. – Modelo de classes de especificação – Consiste na adição de detalhes específico no modelo de domínio. É feita no projeto. – Modelo de classes de implementação – É uma extensão do modelo de especificação, corresponde a implementação das classes em uma linguagem de programação. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 7 Nomenclatura Utilizada • Padrão adotado no livro texto. Os termos não apresentam espaços em branco e preposições. • Para nome de classes e relacionamentos, palavras iniciam em maiúsculo: Cliente, ItemPedido, Pedido... • Para nome de atributos e nomes de operações (Exceto siglas), a primeira letra em minúsculo e as demais iniciais em maiúsculo: quantidade, precoUnitario, CPF, nome, dataNascimento... Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 8 Diagrama de Classes Classes • São representadas através de uma caixa com no máximo três compartimentos. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 9 Nome Atributos Operações Nome Nome Atributos Nome Operações Nome Atributos Operações Possíveis notações Diagrama de Classes • Exemplos de representação de uma mesma classe. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 10 ContaBancaria ContaBancaria numero saldo dataAbertura ContaBancaria numero saldo dataAbertura criar(); bloquear(); desbloquear(); creditar(); debitar(); Diagrama de Classes Relacionamento entre objetos (associação) • Representa o relacionamento entre objetos de duas classes; • Uma associação é representada através de um segmento de reta ligando as classes. • Exemplo: um cliente compra produtos. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 11 Cliente Produto Diagrama de Classes Relacionamento entre objetos (associação) – Multiplicidade • As associações permitem representar limites inferior e superior da quantidade de objetos o outro pode estar associado; • Esses limites são chamados de multiplicidade. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 12 Nome Simbologia Apenas um 1..1 ou 1 Zero ou muitos 0..* ou * Um ou muitos 1..* Zero ou um 0..1 Intervalo específico i..j Diagrama de Classes Relacionamento entre objetos (associação) – Multiplicidade • Um cliente pode estar associado a vários pedidos • Uma corrida pode ter de 2 a 6 velocistas. • Pode haver outras multiplicidades, exemplo: 1,3,5..9,11 significa que as a multiplicidade é: {1,3,5,6,7,8,9,11} Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 13 Cliente Pedido 1 0..* Velocista Corrida 2..6 1 Diagrama de Classes Relacionamento entre objetos (associação) – Multiplicidade • As associações podem ser agrupadas em três grandes tipos: “muitos para muitos”, “um para muitos”, “um para um”. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 14 Conectividade Multiplicidade de um extremo Multiplicidade do outro extremo Um para um 0..1 ou 1 0..1 ou 1 Um para muitos 0..1 ou 1 * ou 1..* ou 0..* Muitos para muitos * ou 1..* ou 0..* * ou 1..* ou 0..* Diagrama de Classes Relacionamento entre objetos (associação) – Multiplicidade Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 15 Empregado Departamento 1 0..1 Empregado Departamento 0..* 1 Empregado Projeto 0..* 1..* Um para um Um para muitos Muitos para muitos Diagrama de Classes Nome de associação, direção de leitura e papeis. • O nome da associação é posicionado na linha da associação; • A direção de leitura informa como a associação deve ser lida. • Os papéis de cada objeto em um relacionamento pode ser representado. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 16 Diagrama de Classes Nome de associação, direção de leitura e papeis. • São muito úteis quando o significado de uma associação é difícil de compreender. • Auxilia em situações em que há múltiplas associações entre as mesmas classes. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 17 Diagrama de Classes Agregação e Composição • São tipos especiais de associação, que representam relacionamentos todo-parte. • Agregação: Relação de dependência fraca: A existência do objeto-parte faz sentido sem o objeto-todo; É representado por um losango branco. • Composição: Relação de dependência forte: O objeto-parte não existe sem o objeto-todo. É representado por um losango preto. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 18 Diagrama de Classes Agregação e Composição Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 19 Agregação Composição Diagrama de Classes Classes associativas • São classes que estão ligadas a associações, em vez de outras classes; • Mais comum em associações muitos para muitos Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 20 Diagrama de Classes Classes associativas • Mais um exemplo: Consertos em automóveis são realizados por funcionários,mas é necessário saber que especialidade foi utilizada; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 21 Diagrama de Classes Classes Associativas • Uma classe associativa é um elemento híbrido: classe e associação; • Normalmente opta-se por remover essa classe e inserir uma classe ordinária com multiplicidade 1 para muitos. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 22 Diagrama de Classes Associação ternária • São necessárias para associar elementos de três classes distintas; • São representadas como na figura abaixo. • Não são muito utilizadas. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 23 Diagrama de Classes Associação ternária • Pode ainda haver uma utilização mútua de classes associativas e associação ternária. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 24 Diagrama de Classes Associações reflexivas • Também chamadas de auto associação; • Associa objetos de uma mesma classe. • Os papéis são importantes para facilitar a leitura; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 25 Tópicos • Diagrama de Classes • Responsabilidade e Colaboração • Identificação das Classes Iniciais • Construção do Modelo de Classes de Domínio Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 26 Identificando Classes Iniciais • Quando buscamos identificar as classes, estamos procurando os objetos que irão compor o sistema. • A identificação das classes se divide em duas etapas que são intercaladas: – Identificação das classes candidatas – Eliminação das classes desnecessárias • Existem dois métodos principais para identificar as classes de domínio: – Método dirigido a dados – Método dirigido a responsabilidades (será estudado) Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 27 Responsabilidades e Colaboradores Responsabilidades • Em OO, os objetos encapsulam dados e comportamentos; • As responsabilidades são as obrigações que um objeto tem para com o sistema. • Através das responsabilidades, um objeto colabora com outros para alcançar os objetivos do sistema. • Na prática, é algo que o objeto faz. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 28 Responsabilidade e Colaboradores Responsabilidade • Considerando um objeto cliente: – Ele conhece seu nome, endereço, telefone... • Considerando um pedido: – Ele conhece sua data de realização, ele também sabe calcular seu valor total. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 29 Responsabilidade e Colaboração Colaboração • Algumas vezes um objeto tem responsabilidades que ele não consegue cumprir sozinho; • Deve haver colaboração com outros objetos; • Por exemplo na impressão da fatura de um pedido: – O objeto Pedido informa o seu valor total – O objeto Cliente o seu nome – Cada objeto ItemPedido a quantidade e o subtotal – Cada objeto Produto informa seu nome e preço unitário Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 30 Responsabilidade e Colaboração • Resumindo... Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 31 Objetos Responsabilidades O que o objeto conhece + O que o objeto faz Colaboradores O padrão de comunicação entre os objetos Possuem Precisam de Realizadas por Categorias de Responsabilidade • Os objetos podem ser categorizados de acordo com o tipo de responsabilidade; • Os objetos podem ser divididos em (Proposto por Ivan Jacobson): – Objetos de entidade – Objetos de controle – Objetos de fronteira Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 32 Categorias de Responsabilidade Objetos de Entidade • É um repositório para alguma informação manipulada pelo sistema; • Normalmente armazenam informações persistentes no sistema; • Os atores não possuem acesso direto a esses objetos; • Normalmente participam de vários casos de uso Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 33 Categorias de Responsabilidade Objetos de Entidade • Algumas responsabilidades típicas: – Informar valores de seus atributos a objetos de controle – Realizar cálculos simples, normalmente com a colaboração de objetos de entidade; – Criar e destruir objetos todo-parte • Eles devem conhecer os elementos da sua criação. Por exemplo, um cliente deve conhecer nome, telefone, endereço... Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 34 Categorias de Responsabilidade Objetos de Fronteira • Traduzem eventos gerados por um ator em eventos relevantes ao sistema; • São responsáveis por apresentar os resultados de uma iteração em algo que possa ser entendido pelo ator; • Permitem a comunicação com o mundo exterior; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 35 Categorias de Responsabilidade Objetos de Fronteira • As classes de fronteira normalmente fazem: – Notificam aos objetos de controle os eventos gerados externamente ao sistema; – Notificam aos atores o resultado de interações entre objetos internos. • Já as responsabilidades de conhecer, normalmente estão voltadas a propriedades da interface de comunicação. • No início os objetos de fronteira esses objetos são abstraídos. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 36 Categorias de Responsabilidade Objetos de Controle • Servem como uma ponte entre os objetos de fronteira e os de entidade; • Decidem o que o sistema faz quando ocorre um evento externo relevante; • São bastante acoplados à lógica da aplicação. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 37 Categorias de Responsabilidade Objetos de Controle • Responsabilidades de fazer típicas: – Realizar monitorações, a fim de responder a eventos externos ao sistema; – Coordenar a realização de um caso de uso através do envio de mensagens a objetos de fronteira e de entidade; – Assegurar que as regras de negócio estão sendo seguidas; – Coordenar a criação de associação entre objetos de entidade; • As responsabilidades de conhecer são usados para manter valores acumulados ou derivados durante a realização de um caso de uso, ou manter informações de estado dele. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 38 Divisão de Responsabilidades • As categorias propostas por Jacobson implica que cada objeto é especialista em um de três tipos de tarefas: – Se comunicar com atores : Fronteira – Manter informações do sistema: Entidade – Coordenar a realização de um caso de uso: Controle • Auxilia na resposta a mudanças: Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 39 Tipo de mudança Onde mudar Mudanças na interface do sistema (interface gráfica ou comunicação com outros sistema) Objetos de fronteira Mudanças nas informações manipuladas pelo sistema Objetos de entidade Mudanças em funcionalidades complexas (vários objetos) Objetos de controle Divisão de Responsabilidades • Como exemplo, consideremos uma loja de aluguel de carros; • O sistema necessita ser atualizado para que os clientes possam utilizar o sistema via internet; • Os objetos que precisam ser modificados nesse caso são os de fronteira; • A mudança é complexa, mas somente um subconjunto dasclasses seria modificado. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 40 Divisão de Responsabilidades • Continuando o exemplo, esse sistema deve ter como classes de entidade: Carro, Aluguel, etc. • Deve também na classe de controle, uma lógica para calcular o valor total das locações feitas por um cliente; • Caso haja uma mudança na lógica, somente as classes de controle serão alteradas. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 41 Divisão de Responsabilidades Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 42 <<Fronteira>> <<Controle>> <<Entidade>> <<Entidade>> <<Entidade>> Tópicos • Diagrama de Classes • Responsabilidade e Colaboração • Identificação das Classes Iniciais • Construção do Modelo de Classes de Domínio Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 43 Identificação das Classes Iniciais • Os casos de uso podem ser usados como base para o desenvolvimento de um sistema; • É lógico, pois a existência de uma classe só faz sentido se ela participar de alguma forma de um comportamento visível do sistema; • O modelador analisa cada caso de uso e identifica as classes candidatas a desempenhar responsabilidades nas categorias: fronteira, controle e entidade. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 44 Identificação das Classes iniciais • A descrição dos casos de uso são estudados para identificar as classes candidatas. • Todos os fluxos são analisados (principal, alternativos e exceção); • Na análise, os substantivos e locuções equivalentes são destacados e são removidos os sinônimos. Os nomes restante são classes candidatas. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 45 Identificação das Classes Iniciais • Para identificar as responsabilidades de fazer, deve-se identificar os verbos que representam ações. • O substantivo da frase representa a classe que possui essa responsabilidade; • Vantagem: Abordagem simples; • Desvantagem: Depende da descrição dos casos de uso, e a linguagem natural omite alguns aspectos; • Solução: Após a análise, modelar CRC. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 46 Modelagem CRC • Classe Responsabilidades e Colaboradores: Proposta em 1989; • Não faz parte da UML; • Na modelagem CRC os usuários, modeladores, projetistas, programadores trabalham juntos; • Utilizam cartões simples. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 47 • Utiliza pequenos cartões onde constam o nome da classe e sua especialidade (fronteira, entidade ou controle), na esquerda são listadas suas responsabilidades e na direita os colaboradores. Modelagem CRC Nome da Classe (especialidade) Responsabilidades Colaboradores 1ª responsabilidade 1º colaborador 2ª responsabilidade 2º colaborador ... ... nª responsabilidade mº colaborador Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 48 • Exemplo Modelagem CRC ContaBancaria (entidade) Responsabilidades Colaboradores 1 – Conhecer o seu cliente Cliente 2 – Conhecer o seu número Historico 3 – Conhecer o seu saldo HistoricoTransacoes 4 – Manter um histórico de transações 5 – Aceitar saques e depósitos Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 49 Modelagem CRC Dicas para atribuição de responsabilidades: • Associar responsabilidades com base na especialidade da classe: – Fronteira – Entidade – Controle Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 50 Modelagem CRC Dicas para atribuição de responsabilidades: • Distribuir a inteligência do sistema; • Não sobrecarregar uma ou um conjunto de classes; – Exemplo: Um objeto Pedido tem a responsabilidade de saber o seu valor total implica que ele deve saber os subtotais de cada item; – Solução: Cada objeto ItemPedido é responsável por calcular seu subtotal, com a ajuda de um objeto Produto Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 51 Modelagem CRC Dicas para atribuição de responsabilidades: • Agrupar responsabilidades conceitualmente relacionadas – Responsabilidades relacionadas devem ser mantidas em uma classe; – Não “espalhar” as responsabilidades; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 52 Modelagem CRC Dicas para atribuição de responsabilidades: • Evitar responsabilidades redundantes: – Não repetir responsabilidades, criar uma nova classe ou escolher uma das classes para persistir a informação; – Lembrando-se da dica anterior... Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 53 Tópicos • Diagrama de Classes • Responsabilidade e Colaboração • Identificação das Classes Iniciais • Construção do Modelo de Classes de Domínio Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 54 Criação do Modelo de Classes de Domínio • Após identificar classes e responsabilidades, deve-se verificar incoerências e inconsistências; • Depois devem ser definidas responsabilidades e colaborações entre as classes; • Esse modelo resumido comporá as classes de domínio. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 55 Criação do Modelo de Classes de Domínio Definição das Prioridades de uma Classe • Após identificar as responsabilidades para atributos, deve-se verificar se os atributos: – Guardam valores atômicos – Não contém estrutura interna (complementa a anterior) – Aplica-se a todos os objetos da classe. Exemplo: É incoerente um atributo salário na classe Pessoa. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 56 Criação do Modelo de Classes de Domínio • É comum mapear responsabilidades de conhecer como atributos, mas as vezes uma associação é mais indicada. Ex.: – Atributo nomeCliente na classe Pedido, poderia ser trocada por uma associação entre Cliente e Pedido; – Se há a relação, não necessita de um atributo na classe fazendo referência. Confusão com o modelo relacional. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 57 Criação do Modelo de Classes de Domínio • É comum também no início definir um identificador para as classes. • No modelo de classes de domínio, não é necessário. • Isso não quer dizer que atributos que são identificadores naturais não possam ser definidos: – CPF – Código de um produto ou pedido – Número de matrícula Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 58 Criação do Modelo de Classes de Domínio • Os atributos dependem do contexto: – Para um sistema de recursos humanos, uma Pessoa possui matrícula, nome, salário, data de contratação. – Para um sistema que guarda informações criminais: fotografia, peso, altura... Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 59 Criação do Modelo de Classes de Domínio • As responsabilidades de fazer são as operações: • No início é difícil de identificar todas as operações; • Os diagramas de interação ajudam a identificar; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 60 Criação do Modelo de Classes de Domínio Associações e agregações • Se uma classe colabora com outra, deve haver relacionamentosentre elas; • As agregações são identificadas quando percebe-se uma relação todo-parte entre elementos das classes; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 61 Criação do Modelo de Classes de Domínio Classes associativas • Surgem quando há uma responsabilidade de saber que não pode ser atribuída a uma das classes; • Muitas pessoas trabalham em muitos projetos: – Quantas horas uma pessoa trabalha em cada projeto? Não pode ser atribuído a pessoa, nem a projeto; Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 62 Criação do Modelo de Classes de Domínio Documentando o modelo de classes • Após identificar classes, responsabilidades e colaboradores, os mesmos devem ser organizados em um documento; • Na diagramação, as associações devem poder ser lidas da esquerda para direita ou de baixo para cima; • Podem ser definidos estereótipos para as classes: <<fronteira>>, <<entidade>> e <<controle>> Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 63 Criação do Modelo de Classes de Domínio Documentando o modelo de classes • A construção de um único diagrama para todas as classes pode ser complexo; • Uma alternativa é criar uma VCP (Visão de Classes Participantes) para cada caso de uso; • As VCPs podem ser juntadas para formar um único diagrama, se ficar muito grande pode-se esconder as classes de fronteira ou até as de controle. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 64 Criação do Modelo de Classes de Domínio Documentando o modelo de classes • Além do diagrama, deve haver uma documentação textual; • Pode-se utilizar os cartões CRC, com a adição de um pequeno texto para descrever a classe; • A medida que o desenvolvimento evolui, novos detalhes são adicionados. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 65 Criação do Modelo de Classes de Domínio • Após construir o modelo de classes de domínio, deve-se retornar aos casos de uso para verificar inconsistências; • Há uma estrita relação entre os casos de uso e as classes de domínio: Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 66 Criação do Modelo de Classes de Domínio • A construção do diagrama de classes é um processo incremental; • É necessário um pouco de experiência dos modeladores; • As classes de domínio sofrerão mudanças, principalmente quando adiciona-se aspectos dinâmicos: Diagrama de Interações e Diagrama de Estados Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 67 Estudo de Caso • Páginas 130 a 137 do livro texto. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 68 Exercício • Construir o modelo de casos de uso, e o modelo de classes de domínio para um caixa eletrônico. Considere inicialmente os casos de uso: Realizar Saque e Realizar Depósito. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 69 Referências • BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Editora Campus, 2006. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 70
Compartilhar