Modelagem de Classes do Domínio

1. Modelagem de Classes do Domínio

2. Introdução O modelo de casos de uso fornece uma perspectiva do sistema a partir de um ponto de vista externo. De posse da visão de casos de uso, os desenvolvedores precisam prosseguir no desenvolvimento do sistema.

3. Introdução A funcionalidade externa de um sistema orientado a objetos é fornecida através de colaborações entre objetos. Externamente, os atores visualizam resultados de cálculos, relatórios produzidos, confirmações de requisições realizadas, etc. Internamente, os objetos colaboram uns com os outros para produzir os resultados que são visíveis de fora.

4. Uma colaboração pode ser vista sob o aspecto dinâmicoe sob oaspecto estrutural estático. Aspecto dinâmico: Descreve a troca de mensagens entre os objetos e sua reação a eventos que ocorrem no sistema. Aspectos dinâmico e estático

5. Aspecto estrutural estático Permite compreender como o sistema está estruturado internamente. Este é estrutural, pois seu foco encontra-se na representação da estrutura das classes e nas relações entre estas. Este é estático, pois não apresenta informações sobre as interações dos objetos no decorrer do tempo Aspectos dinâmico e estático

6. Aspectos dinâmico e estático Lembre-se: Os aspectos estático e dinâmico deum SW não são independentes ! Na verdade, a construção de um serve para adicionar detalhes ao outro.

7. Modelo de classes O diagrama da UML utilizado para representar o aspecto estático é o diagrama de classes. O modelo de classes é composto desse diagrama e de alguma descrição textual associada. Assim como outros modelos, o modelo de classes evolui durante o desenvolvimento do sistema. À medida que o sistema é desenvolvido, o modelo de classes é incrementado com novos detalhes. Três níveis sucessivos de abstração: Domínio Especificação Implementação.

8. Modelo de classes O modelo de classes de domínio Representa as classes no domínio do negócio em questão. Este modelo é construído na fase de análise. Por definição, este modelo é abstrato e não deve considerar restrições inerentes à tecnologia a ser utilizada na solução de um problema.

9. Modelo de classes O modelo de classes de especificação É obtido através da adição de detalhes (classes da solução tecnológica, tipos, visibilidades, parâmetros,...) ao modelo anterior. Este modelo é construído (por iteração) na fase de projeto O modelo de classes de implementação Corresponde à implementação de classes anteriores em alguma LPOO Este modelo é construído (por iteração) na fase de implementação

10. Modelo de classes Resumindo... As classes de domínio são definições abstratas que descrevem o problema sem considerar a tecnologia usada na solução. O foco está nas classes e não nos seus atributos e operações Quando atributos ou operações são representados, define-se apenas o nome destes (nada de tipo, visibilidade, parâmetros,...)

11. Modelo de classes As classes de especificação e implementação consideram a tecnologia usada na solução, entretanto: As classes de especificação descrevem a solução com um elevado nível de abstração (independente de uma LPOO). As classes de implementação descrevem a solução considerando a implementação da solução em uma LPOO

12. É fortemente recomendado que se padronize a nomenclatura a ser usada para os elementos do modelo de classes. A seguir, é apresentada uma sugestão de padronização Para nomes de Identificadores (regra geral): Remover qualquer espaço em branco, preposição, artigo, acento ou caracter especial. EX: OrdemPedido, obterTotal(), precoUnitario, ... Padronizando a Nomenclatura

13. Para nomes de Classes e de Relacionamentos: Iniciar as palavras com letra maiúscula. EX: Cliente, ItemPedido, Pedido, OrdemPedido,... Para nomes de propriedades (Atributos) e operações (Métodos): A primeira palavra inicia com letra minúscula, as demais iniciam com letras maiúsculas. Acrescentar parênteses às operações e Siglas ficam inalteradas. EX: nome, precoUnitario, obterTotal(), CPF, ... Padronizando a Nomenclatura

14. Classes Uma breve revisão... Uma classe representa um grupo de objetos semelhantes. Uma classe descreve esses objetos através de atributos e operações. Os atributos correspondem às informações que um objeto armazena. As operações correspondem às ações que um objeto sabe realizar.

15. Classes Notação para uma classe Uma classe é representada através de uma “caixa” com, no máximo, três compartimentos exibidos (nome da classe, atributos e métodos). Por convenção, o nome de uma classe é apresentado no singular. A notação utilizada depende do nível de abstração desejado.

16. Classes • Exemplo: classe ContaBancaria

17. Associações Representa relacionamentos que são formados entre objetos. Embora as associações sejam representadas entre classes, tais associações representam ligações entre objetos das classes envolvidas. São representadas através de um segmento de reta.

18. Associações Exemplos:

19. Multiplicidades das Associações Representam os limites inferior e superior da quantidade de objetos aos quais um outro objeto pode estar associado. Cada associação em um diagrama de classes possui duas multiplicidades, uma em cada extremo da linha de associação.

20. Multiplicidades das Associações

21. Multiplicidades das Associações • Exemplo 1: • Pode haver um cliente que esteja associado a vários pedidos. • Pode haver um cliente que não esteja associado a pedido algum. • Um pedido está associado a um, e somente um, cliente.

22. Multiplicidades das Associações • Exemplo 2: • Uma corrida está associada a, no mínimo, dois velocistas • Uma corrida está associada a, no máximo, seis velocistas. • Um velocista pode estar associado a várias corridas. • Uma lista de intervalos pode ser especificada na multiplicidade de uma associação • EX: “1,3,5..9,11” equivale a um intervalo {1,3,5,6,7,8,9,11}

23. Conectividade das Associações Aconectividade corresponde ao tipo de associação entre duas classes: um para um um para muitos muitos para muitos. A conectividade da associação entre duas classes depende da multiplicidade da associação.

24. Conectividade das Associações • Exemplo: um para um um para muitos muitos para muitos

25. Participação das Associações Indica a necessidade da existência da associação. A participação pode ser Obrigatória. Se o valor mínimo da multiplicidade de uma associação é igual a 1 Opcional Se o valor mínimo da multiplicidade de uma associação é igual a 0. Por exemplo: obrigatório opcional

26. Detalhando uma associação Para melhor esclarecer o significado de uma associação no diagrama de classes, a UML define três recursos de notação: Nome da associação: fornece algum significado semântico a mesma. Direção de leitura: indica como a associação deve ser lida Papel: para representar um papel específico em uma associação.

27. Detalhando uma associação Direção Nome Papel Papel

28. Detalhando uma associação Atenção: É preferível não nomear associações a usar nomes vagos ou óbvios demais. O mesmo vale para papéis! O objetivo é ter diagramas claros e não “poluídos”. Isto é, equilibrar o entendimento e a concisão !

29. Detalhando uma associação Embora ocorra com pouca freqüência, pode-se definir mais de uma associação entre duas classes. Nestes casos, já que as duas classes envolvidas são as mesmas, o detalhamento das associações (uso de papéis, nomes de associações e/ou direção de leitura) é apropriado para aumentar a legibilidade.

30. Detalhando uma associação

31. Associação de Agregação É um caso especial da associação conseqüentemente, multiplicidades, participações, papéis, etc. podem ser usados igualmente É utilizada para representar conexões que guardam uma relação todo-parte entre si.

32. Associação de Agregação A diferença entre associação simples e uma associação de agregação é puramente semântica Em uma associação de agregação, um objeto está contido no outro, ao contrário de uma associação simples que apenas relaciona objetos. Onde se puder utilizar uma associação de agregação, uma associação simples também poderá ser utilizada.

33. Associação de Agregação Atenção: Sejam duas classes associadas, X e Y. Se uma das perguntas a seguir for respondida com um sim, então, provavelmente há uma agregação onde X é todo e Y é parte. X tem um ou mais Y? Y é parte de X?

34. Associação de Agregação • Notação : • Um segmento de reta que conecta as classes relacionadas e possui um losango branco perto da classe que representa o todo. • Exemplo: • Obs: • Na associação de agregação não há dependência existencial entre as partes e o todo. • Se uma Equipe for extinta, o Jogador ainda pode ser membro de outras

35. Composição Um livro é composto de capítulos Capítulo é parte essencial de livro Se não existir capítulo, não existe livro Capítulo não existe fora de livro Linha com losângulo preenchido na classe “dominante” Livro é composto de 1 ou mais capítulos

36. Classe Associativa É uma classe que está ligada a uma associação, ao invés de estar ligada a outras classes. É normalmente necessária, quando duas ou mais classes estão associadas, e é necessário manter informações sobre esta associação. Uma classe associativa pode estar ligada a associações de qualquer tipo de conectividade. Todavia, é mais comum com conectividade muitos para muitos

37. Classe Associativa • Notação: • Mesma da classe, entretanto a classe é ligada a uma associação. • Exemplo: • OBS: • Não se descreve a linha de associação de uma classe associativa

38. Classe Associativa • De forma geral, pode-se substituir, sem perda de informação, uma classe associativa por uma classe ordinária • Note que a classe emprego tem participação obrigatória em ambas as associações

39. Generalizações e Especializações O modelador também pode representar relacionamentos entre classes. Esses denotam relações de generalidade ou especificidade entre as classes envolvidas. Exemplo:o conceito mamífero é mais genérico que o conceito ser humano. Exemplo: o conceito carro é mais específico que o conceito veículo. Esse é o chamado relacionamento de herança. relacionamento de generalização/especialização relacionamento de gen/espec

40. Generalizações e Especializações Terminologia subclasse X superclasse. supertipo X subtipo. classe base X classe herdeira. classe de especialização X classe de generalização. ancestral e descendente (herança em vários níveis) Notação definida pela UML

41. Semântica da Herança Subclasses herdam as características de sua superclasse É como se as características da superclasse estivessem definidas também nas suas subclasses Note a diferença semântica entre a herança e a associação. A primeira trata de um relacionamento entre classes, enquanto que a segunda representa relacionamentosentre instâncias de classes.

42. Semântica da Herança Na associação, objetos específicos de uma classe se associam entre si ou com objetos específicos de outras classes. Exemplo: Herança: “Gerentes são tipos especiais de funcionários”. Associação: “Gerentes chefiam departamentos”.

43. Herança de Associações Não somente atributos e operações, mas também associações são herdadas pelas subclasses. No exemplo abaixo, cada subclasse está associada a Pedido, por herança.

44. Propriedades da Herança