Exemplo: Campeonato de futebol

Transcrição

1 Exemplo: Campeonato de futebol Um campeonato é constituído por 34 jornadas, é identificado por uma época e possui um campeão e um melhor marcador. Cada jornada é identificada por um número e é constituída por 9 jogos. Cada jogo é efectuado por uma equipa de futebol visitada, outra visitante e é arbitrado por uma equipa de arbitragem. Cada equipa de futebol tem ou mais jogadores e cada equipa de arbitragem possui 4 árbitros. Cada jogador pode marcar golos, a determinado instante do jogo e de uma de diversas formas: de grande penalidade, de livre, de pontapé de fora da área, de cabeça, etc. O árbitro de um jogo pode mostrar um ou mais cartões, amarelos ou vermelhos. José Correia UML Diagramas de Classes 6 Campeonato de futebol: possível solução... (mas que pode ser melhorada) Campeonato epoca Jornada 34 parte do modelo numero a melhorar é constituído por melhorarcador() campeao() é constituída por visitante 9 EquipaFutebol Jogo é arbitrado por EquipaArbitragem nome datarealizacao mostrado em visitada Cartão 4 é constituída marca golo no Golo cor mostrado por Arbitro por hora forma hora Jogador mostrado a 0.. nome numerobi numerotelefone morada numerocartaconducao datanascimento numerocontribuinte José Correia UML Diagramas de Classes 62

2 Relação de Dependência As dependências são desenhadas como linhas dirigidas a tracejado Sensor de Temperatura... inicializa() definealarme(t: Temperatura) valor(): Temperatura Temperatura Uma dependência é uma relação de uso entre dois elementos (não necessariamente classes), em que uma mudança na especificação de um dos elementos pode forçar uma alteração no outro elemento Por motivos de simplicidade, em geral não se explicita este tipo de relações nos diagramas de classes são implícitas! as dependências são muito mais usadas entre outro tipo de elementos do UML, nomeadamente Pacotes José Correia UML Diagramas de Classes 63 Relação de Dependência: Exemplo Exemplo de um modelo de negócio, em que as classes estão agrupadas em pacotes Um pacote depende de outro se uma alteração do pacote de destino afectar o pacote de origem (dependente) José Correia UML Diagramas de Classes 64

3 Restrições (constraints) Uma restrição especifica uma condição que tem de se verificar é indicada por uma expressão ou texto entre chavetas ou por uma nota posicionada junto aos elementos a que diz respeito, ou a eles ligada por linhas a traço interrompido (sem setas, para não confundir com relação de dependência) Alguns exemplos: o salário de um empregado não pode exceder o salário do seu chefe {empregado.salario < chefe.salario} as janelas não podem ter uma relação de aspecto inferior a 0.8 e superior a.5 {0.8 <= largura/altura <=.5} José Correia UML Diagramas de Classes 65 Restrições em Classes nome datanascimento localnascimento datafalecimento { datafalecimento > datanascimento } Factura número data LinhaFactura número artigo quantidade valor Restrições simples, como estas, podem ser colocadas no modelo mas restrições mais complexas devem ser especificadas no modelo funcional { chave candidata: (factura.número, número) } José Correia UML Diagramas de Classes 66

4 Restrições em Associações Factura {ordered} Membro-de {subset} Director-de LinhaFactura Comité uma factura é constituída por um conjunto ordenado de 0 ou mais linhas Conta {xor} Empresa associações mutuamente exclusivas chefe 0.. empregado trabalhador empregador.empregador =.chefe.empregador Empresa José Correia UML Diagramas de Classes 67 Dependências e Restrições: Exemplo Co_op depende de Company se modificarmos Company, podemos também ter de modificar Co_op O diagrama tem duas restrições: uma Section apenas pode ser parte de um CourseSchedule se ele não tiver sido cancelado a restrição {xor} indica que um Student tem de ter um CourseSchedule ou uma posição Co_op, mas não ambos José Correia UML Diagramas de Classes 68

5 Extensão e Restrição na Generalização Conforme já vimos, instâncias de uma classe são também instâncias de todas as classes ascendentes Consequentemente, todas as características das classes ascendentes são aplicadas às instâncias das sub-classes uma classe descendente não pode omitir ou suprimir determinada característica de uma classe ascendente no entanto, as sub-classes podem acrescentar novas características (atributos e operações) à sua super-classe - a sub-classe passa a ser uma extensão da super-classe José Correia UML Diagramas de Classes 69 Extensão e Restrição na Generalização (cont.) Os atributos de uma super-classe podem ter de obedecer a determinadas restrições quando aplicadas às subclasses os valores assumidos pelas subclasses passam a ficar restritos a determinadas gamas de valores - por exemplo, a classe círculo definido com base na classe elipse tem de obedecer à restrição eixos menor e maior são iguais Contudo, alterações arbitrárias dos atributos da super-classe podem violar as restrições relativas à subclasse por exemplo, se os eixos menor e maior de uma elipse forem alterados por uma das operações da classe elipse e o objecto em causa for um circulo, a restrição eixos menor e maior são iguais é certamente violada José Correia UML Diagramas de Classes 70

6 Extensão e Restrição na Generalização (cont.) Para casos deste tipo: as propriedades herdadas podem ser renomeadas - por exemplo, eixos diâmetro a subclasse pode não herdar todas as operações da super-classe - por exemplo, operações de alteração de escala desigual segundo os eixos X e Y devem ser suprimidas de forma adequada na classe círculo A restrição implica que nem todas as operações da super-classe possam ser herdadas pela subclasse José Correia UML Diagramas de Classes 7 Classes e Operações abstractas ( concretas) Classe abstracta: classe que não pode ter instâncias directas pode ter instâncias indirectas pelas subclasses concretas Icon origin: Point display() getid(): Integer Operação abstracta: operação com implementação a definir nas subclasses uma classe com operações abstractas é obrigatoriamente uma classe abstracta Notação: nome em itálico ou propriedade {abstract} RectangularIcon height: Integer width: Integer Button display() ArbitraryIcon edge:linecollection display() isinside(p:point):bool Fonte: The UML User Guide, Booch José Correia UML Diagramas de Classes 72

7 Classes abstractas (cont.) Empregado Rendimento CalcularPagamento() Empregado pago à hora CustoHora CalcularPagamento() Empregado fixo VencimentoMensal CalcularPagamento() Uma classe é abstracta quando só os seus descendentes é que podem ser instanciados de forma directa a classe Empregado não pode ser directamente instanciada Uma classe é concreta quando pode ser directamente instanciada as subclasses de Empregado podem ser instanciadas José Correia UML Diagramas de Classes 73 Exemplo: Encomendas Modelização das encomendas (Orders) de um cliente (Customer), cujo pagamento (Payment) é feito em dinheiro (Cash), cheque (Check) ou através de cartão de crédito (Credit Card). As encomendas contêm linhas (OrderDetail), cada uma das quais com o respectivo item (Item) associado. José Correia UML Diagramas de Classes 74

8 Multiplicidade de classes e atributos Multiplicidade de classe: número de instâncias que podem existir por omissão é 0.. NetworkController consoleport [2..]: Port Multiplicidade de atributo: número de valores que o atributo pode tomar do tipo especificado por omissão é José Correia UML Diagramas de Classes 75 Visibilidade de atributos e operações Visibilidade - (private): visível só por operações da própria classe # (protected): visível por operações da própria classe e descendentes (subclasses) + (public): visível por todos Recordando o encapsulamento... devem-se esconder todos os detalhes de implementação que não interessam aos clientes (utilizadores) da classe Toolbar # currentselection: Tool # toolcount: Integer + gettool(i: Integer): Tool + addtool(t: Tool) + removetool(i: Integer) - compact() usada internamente por outras operações José Correia UML Diagramas de Classes 76

9 Atributos e operações do âmbito da classe ( instância) Atributo do âmbito da classe: tem um único valor para todas as instâncias (objectos) da classe, o qual está definido mesmo que não exista nenhuma instância Operação do âmbito da classe: não tem como argumento implícito um objecto da classe Notação: nome sublinhado Correspondem a membros estáticos (static) em C++ e Java Factura número: Long data: Date valor: Real últimonumero: Long = 0 criar(data:date,valor:real) destruir() valortotal(): Real retorna a soma dos valores de todas as facturas cria uma nova factura com a data e valor especificados, e um número sequencial atribuído automaticamente com base em ultimonumero José Correia UML Diagramas de Classes 77 Subclasses incompletas ( completas) Caso em que um objecto da super-classe pode não pertencer a nenhuma das subclasses Indicado por restrição {incomplete} O contrário é {complete} (situação por omissão) Funcionário {incomplete} Técnico Comercial outras possibilidades: Administrativo, Director, etc. José Correia UML Diagramas de Classes 78

10 Subclasses sobrepostas ( disjuntas) Caso em que um objecto da super-classe pode pertencer, simultaneamente, a mais do que uma subclasse Indicado por restrição {overlapping} O contrário é {disjoint} (situação por omissão) Académico ou Académico {overlapping} {overlapping} Estudante Professor Estudante Professor José Correia UML Diagramas de Classes 79 Herança múltipla ( simples) Estudante curso Académico nome {overlapping} Professor categoria Pelo menos conceptualmente, existe uma super-classe comum Só faz sentido assim! Porquê? Professor-Estudante redução de horário Herda propriedades de Estudante e Professor e, indirectamente, de Académico (uma única vez!) Uma subclasse com duas ou mais super-classes é denominada classe de junção José Correia UML Diagramas de Classes 80

11 Herança múltipla (cont.) As propriedades de uma classe ascendente, que são obtidas por caminhos diferentes, só são herdadas uma vez um veículo anfíbio herda todas as características de um veículo terrestre e de um veículo aquático Veículo no entanto, as características de veículo só são herdadas uma vez pelo veículo anfíbio Veículo Terrestre {overlapping} Veículo Aquático Automóvel Anfíbio Barco Definições paralelas em classes ascendentes produzem conflitos a definição de características idênticas para os veículos terrestres e aquáticos torna a definição de um veículo anfíbio ambígua e inconsistente José Correia UML Diagramas de Classes 8 Herança múltipla (cont.) As subclasses de uma dada generalização podem-se sobrepor ou podem ser disjuntas por exemplo, um determinado veículo pode ser terrestre e aquático ao mesmo tempo, ou seja, assumir ambas as formas em simultâneo a generalização é sobreposta na generalização relativa aos empregados (pagos à hora, assalariados ou fixos), um determinado empregado ou pertence a uma das subclasses ou a outra, mas nunca às duas em simultâneo generalização disjunta A herança múltipla permite misturar informação de duas ou mais fontes Cada generalização deve ser feita sobre uma das propriedades da classe A generalização múltipla deve ser usada quando uma classe necessitar de refinamentos em dimensões distintas e independentes José Correia UML Diagramas de Classes 82

12 Classificação múltipla ( simples) Caso em que um objecto pode pertencer num dado momento a várias classes, sem que exista uma subclasse que represente a intersecção dessas classes (com herança múltipla) Homem Mulher sexo função {incomplete} Médico Enfermeira Fisioterapeuta combinações legais: {Mulher, Enfermeira}, {Homem, Fisioterapeuta},... A classificação múltipla pode ser simulada por agregação de papéis José Correia UML Diagramas de Classes 83 Classificação dinâmica ( estática) Caso em que a(s) classe(s) a que um objecto pertence pode(m) variar ao longo da vida do objecto Indicado por estereótipo «dynamic» atributo discriminante (atributo de pessoa que indica a subclasse a que pertence) tarefa «dynamic» Gestor Engenheiro Vendedor uma pessoa que num dado momento tem a tarefa de gestor, pode noutro momento ter a tarefa de vendedor, etc. José Correia UML Diagramas de Classes 84

13 Elementos derivados Elemento derivado (atributo, associação ou classe) - elemento calculado em função doutros elementos do modelo Notação: barra / antes do nome do elemento derivado Um elemento derivado tem normalmente associada uma restrição que o relaciona com os outros elementos José Correia UML Diagramas de Classes 85 Elementos derivados: Exemplos Empresa empregador TrabalhaEmDepartamento Departamento datanascimento /idade { idade = dataactual() datanascimento } Movimento data valor / TotalMensal mês valor { valor = (select sum(valor) from Movimento where month(data) = mês) } José Correia UML Diagramas de Classes 86

14 Perspectivas a usar (num diagrama de classes) Um diagrama de classes é construído de acordo com determinada perspectiva (situada num dado nível de abstracção) Tipos comuns de perspectivas: Conceptual: descrição dos conceitos do domínio do problema - as classes e respectivas associações representam conceitos - em alguns casos, descrição das principais responsabilidades do objecto Especificação: descrição das interfaces das classes - as classes já representam elementos de software - as associações representam as responsabilidades dos objectos Implementação: a descrição das interfaces é complementada com a descrição das respectivas implementações José Correia UML Diagramas de Classes 87 Resumo José Correia UML Diagramas de Classes 88

15 Resumo Um diagrama de classes é construído e refinado ao longo das várias fases do desenvolvimento do software, por analistas, projectistas (designers) e implementadores Elementos da UML presentes nos diagramas de classes: Classes, com as respectivas estruturas internas e comportamento Associações, agregações, dependências e relações de herança Multiplicidade e indicadores de navegação Nomes de papéis (o que uma classe representa para outra) José Correia UML Diagramas de Classes 89 Referências Estes apontamentos foram baseados em: UML Unified Modeling Language, Curso em Tecnologia de Objectos, FEUP, Novembro 2000 Ademar Aguiar, Gabriel David, João Pascoal Faria Desenvolvimento OO Construção do modelo de objectos através da linguagem UML, ISPGaya, Novembro 998 César Toscano UML, Capítulo 2, Objectos e Classes, ISPGaya José Maria Bonnet Practical UML: A Hands-On Introduction for Developers, TogetherSoft Corporation UML Metodologias e Ferramentas CASE, Centro Atlântico, 200 Alberto Silva, Carlos Videira José Correia UML Diagramas de Classes 90