Unified Modeling Language (UML) - Modelação da Estrutura -

1. Análise e Concepção de Sistemas de Informação Unified Modeling Language (UML)- Modelação da Estrutura - Alberto Manuel Rodrigues da Silva Prof. DEI/IST/UTL

2. Modelação da Estrutura • Classes • Relações • Interfaces, Tipos, e Papeis • Packages • Instâncias • Diagramas de Classes e de Objectos

3. Classes Uma classeé a descrição de um conjunto de objectos que partilham os mesmos: • atributos • operações • relações • semântica nome Dictionary atributos items size() operações isEmpty() As classes são os mais importantes componentes de construção de sistemas OO

4. Classes - Nome de Classes

5. Classes - Atributos [visibility] [/] name [: type] [ multiplicity ] [= default] [{ property-string }] Tipos de visibilidade: + : público; -: privado; #: protegido

6. Classes - Operações [visibility] name [( parameter-list )] : [return-type] [{ property-string }]

7. Classes - Sugestões • Uma classe deve corresponder a algo tangível ou a uma abstração conceptual existente no domínio do problema ou no dominio da solução • Uma classe bem estruturada ... • Providencia uma abstração definida a partir do vocabulário do domínio do problema ou do domínio da solução. • Agrega um conjunto restrito e bem definido de responsabilidades. • Providencia uma separação clara entre a especificação abstracta e a sua implementação. • É simples, e facilmente entendida.

8. Classes - Exercício Usar classes para definição de dicionário de dados de um sistema “O Jogo de Futebol” “O jogo de futebol é realizado por duas equipas de jogadores. Cada equipa é composta por 11 jogadores, com diferentes funções: o guarda-redes, defesas, médios, atacantes, e pontas de lança. O ponta de lança é um atacante especial por ter especiais características de goleador... O jogo é realizado num campo com medidas regulamentares (em comprimento e largura), tem duas balizas, cada qual em extremos opostos do campo. Ganha o jogo a equipa que marcar mais golos (I.e., colocar a bola) na baliza do adversário. No jogo apenas existe um única bola, que apresenta características (peso, diâmetro, …) regulamentares... O jogo de futebol é mediado por uma equipa de 3 árbitros, em que um é o árbitro principal, e os outros dois árbitros auxiliares… De um jogador conhece-se o nome, morada, telefones (pode ter mais que um), data-nascimento, ... A idade de um jogador tem de ser inferior a 40 anos...”

9. Relações Uma relação é uma ligação entre elementos. Na modelação OO os 3 tipos de relações mais importantes são: • dependências • generalizações • associações elemento B relação elemento A

10. Relações - Dependência Uma dependência indica que a alteração na especificação de um elemento (e.g., pacote “UML 0.9”) pode afectar outro elemento que o usa (e.g., pacote “UML 1.0”) mas não necessariamente o oposto. Em UML as dependências são usadas entre normalmente com packages, componentes e notas.

11. Relações - Dependência Tipos de dependência predefinidos • Abstração: • «refinement»: Usado quando o cliente representa melhorias, junçõe, alterações e outros aspectos relativamente ao conteúdo do(s) fornecedor(es). • «trace»: Usado quando se pretende representar relações históricas e dependência de elementos ao longo do tempo • Ligação: • «bind»: Usado para estabelecer ligações entre parâmetros genéricos e parâmetros efectivos, na criação de elementos não parametrizados • Permissão: • «import»: Usado quando o pacote fornecedor concede ao pacote cliente acesso aos seus elementos públicos, de forma que o nome desses elementos passem a poder ser referenciados directamente no pacote cliente. • Utilização: • «include», «extend», «communicate»: Usados no contexto de diagramas de casos de utilização

12. Relações - Dependência Exemplo de dependência com semântica de «refinement» • «refinement»: Usado quando o cliente representa melhorias, junções, alterações e outros aspectos relativamente ao conteúdo do(s) fornecedor(es).

13. Rectangle Circle Polygn corner: Point radius: Float points: List Relações - Generalização Shape Uma generalização é uma relação entre um elemento geral (superclasse) e um tipo mais específico desse elemento (subclasse). Geralmente conhecida como uma relação “is-a” ou “is-a-kind-of”. origin move() resize() display() Square No contexto de classes usam-se generalizações para ilustrar relações de herança.

14. Relações - Generalização Tipos de Generalização...

15. Relações - Generalização Tipos de Generalização... • Generalização disjunta {disjoint}: • tipo por omissão • especifica o facto de uma classe descendente de X poder ser apenas descendente de uma das subclasses de X. • Generalização sobreposta {overlapping}: • especifica o facto de uma classe descendente de X pertence ao produto cartesiano das subclasses de X • No exemplo, a classe CírculoComEtiqueta é uma combinação das subclasses de FiguraGeométrica). • Generalização completa {complete}: vs. incompleta{incomplete}: • especifica o facto de uma generalização ser completamente especificada ou não • No exemplo, o caso da decomposição segundo a dimensão “etiqueta”

16. Relações - Associação Uma associaçãoé uma relação semântica entre dois ou mais elementos de um modelo. Uma pessoa pode trabalhar para várias (0 ou mais) empresas. Numa empresa trabalha 1 ou mais pessoas.

17. Relações - Associação • Multiplicidade • Define quantos objectos participam na relação • O número de instâncias de uma classe relacionadas com uma instância da outra classe • Especificada para cada participante (classe) da associação • Não especificada • Apenas uma • Zero ou mais • Uma ou mais • Zero ou uma • Intervalo especificado • Valores múltiplos 1 0..* ou * 1..* 0..1 2..4 2, 4..6

18. Relações - Associação • Adornos básicos das associações: • - nome • - o papel de cada participante na associação • - a multiplicidade de cada participante na associação • - tipo de agregação

19. Relações - Associação • Adornos básicos das associações: • - restrições As empresas têm um conjunto de empregados, o qual é uma lista ordenada pelo “nome” da pessoa. Adicionalmente, foi definido a restrição de que os empregados são todos do género masculino.

20. Relações - Associação Outros Adornos das Associações • Navegação • Visibilidade • Qualificação • Vários tipos de Agregação

21. Relações - Associação Navegação Por omissão a navegação numa associação é bidireccional. “Dado um pessoa é relevante obter a lista das empresas em que se encontra ligado. Mas não é relevante ou interessante obter-se os empregados de cada empresa.” A navegação é um adorno mais relevante na fase de desenho...

22. Relações - Associação Visibilidade Quando se pretende limitar a visibilidade a objectos externos a determinada associação. Navegação da associação * 1 UserGroup User Password * * +user -key +owner Instâncias de UserGroup podem aceder a instâncias de User(e vice-versa) mas não podem, por sua vez, ver as instâncias de Password dos respectivos User. Tipos de visibilidade: + : público; -: privado; #: protegido

23. Relações - Associação Qualificação Um qualificador é um atributo, ou lista de atributos, cujos valores servem para partir o conjunto de instâncias associadas a uma instância ao longo de uma associação. Os qualificadores são atributos da associação. Banco TabuleiroXadrez NrConta Linha Coluna qualificador * 1 0..1 1 Pessoa Quadrado

24. Relações - Associação Agregação Simples A associação entre classes sem agregação reflecte que ambas as classes se encontram no mesmo nível conceptual. Por vezes, estabelecem-se relações do tipo “is-part-of” ou “has-a”, que devem ser representadas através de agregação.

25. Relações - Associação Composição (Agregação Composta) A composição é uma variante à agregação simples, em que é adicionada a seguinte semântica: (1) forte pertença do “todo” em relação à “parte”, e (2) tempo de vida delimitado (as “partes” não podem existir sem o “todo”). Adicionalmente, o “todo” é responsável pela disposição das suas “partes”, ou seja, “o todo” é responsável pela criação e destruição das suas “partes”. ... Um Departamento não existe sem o contexto de uma Empresa...

26. Relações - Associação

27. Relações - Associação, Exercício Composição (Agregação Composta) Modelize o seguinte discurso: «Uma mesa de café é constituída por um tampo e por quatro pernas…» «Uma mesa de café é constituída por um tampo e por duas a seis pernas, as quais têm de estar ordenadas…»

28. Relações - Associação Classes-Associação Numa associação entre classes, a associação pode também ter as suas próprias propriedades, devendo ser, por conseguinte, modelizada também como uma classe. * 1..* Pessoa Empresa empregador empregado Tarefa descrição dataInício salário classe associação

29. TipoTarefa * * * Pessoa Empresa Tarefa Tarefa descrição dataInício salário classe associação Relações - Associação Associação N-Ária (N  3) Associações com aridade 3 ou superior. São pouco comuns, mas há casos que a sua aplicação é vantajosa... A multiplicidade em associações n-árias pode ser especificada mas é menos óbvia que a multiplicidade em associações binárias. A multiplicidade num papel representa o número de tuplos (de instâncias) numa associação quando os outro N-1 valores são fixos.

30. “Tarefa” é uma classe resultante da associação entre as classes “Pessoa”, “TipoTarefa” e “Empresa” TipoTarefa 1 * Tarefa descrição dataInício salário 1 Pessoa Empresa 1 * * Relações - Associação Associação N-Ária (N  3) As associações N-árias podem ser transformadas em várias relações binárias entre a classe-associação e as restantes classes participantes. Se for esta a estratégia adoptada deve ser assinalado esse facto (por exemplo, através de um estereótipo ou de uma anotação) junto à classe-associação

31. Relações - Associações Reflexivas Quando uma classe tem uma associação consigo própria... 1 professor Docente * assistente “um docente, enquanto professor, é responsável por outros docentes, designados por assistentes”

32. Relações - Sugestões • Usar dependência apenas quando a relação não é estrutural. • Usar generalização apenas quando se tem uma relação do tipo is-a ou is-a-kind. • Herança múltipla pode ser geralmente substituida pela agregação. • Evitar relações de generalização ciclicas • Manter as generalizações balenceadas (nem muito largas, nem muito fundas) • Usar associações sempre que existirem relações semânticas entre objectos.

33. Diagramas de classes Perspectivas: • Modelo de Análise – diagrama representa os conceitos do dominio em análise; normalmente existirá uma relação com as classes que os implementarão (tb. modelos de domínio) • Modelo de Desenho - o diagrama representa o desenho da implementação do software • São muito ricos, podem-se tornar complicados • Não se deve utilizar todas as notações disponíveis • Começar com: classes, atributos, associações, generalizações e restrições • Utilizar correctamente as diferentes perspectivas (análise vs desenho)

34. Diagramas de classes • Representam a visão lógica do sistema, expressa pelo conjunto de todas as suas classes e respectivas relações. • Elementos UML que são representados num diagrama de classes: • Classes e toda a sua estrutura interna • Relações • Tipos (Associações, Agregações, Dependências, Generalização) • Multiplicidade • Navegabilidade • Nome da relação e papel de cada interveniente • ....

35. Exercícios • Modelizar o diagrama de classes de um jogo de futebol • Usar as classes anteriormente definidas • Introduzir as relações entre as classes • Como representaria a seguinte informação: “Um aluno pode-se inscrever em algumas disciplinas de um curso, que têm precedência entre si.”?

36. Exercício: Facturas&Clientes Enunciado: • Um sistema de facturação mantém informação sobre clientes, sobre tipos de produtos e de serviços vendidos/prestados. • Um cliente é identificado univocamente pelo NIF, e tem ainda nome, morada, telefones, e tipo de cliente. Um cliente pode ter mais que uma morada… • Uma factura é identificada univocamente pelo IDFactura, que é um número sequencial. Tem ainda a informação sobre data de facturação, cliente, valor total. Uma factura tem várias linhas, cada qual especificando a venda de um bem ou serviço… • Uma factura pode ser paga por uma ou mais prestações. Cada pagamento parcial/total corresponde à emissão de respectivo recibo...

37. Interfaces Uma interface é um ... contrato na forma de uma colecção de assinaturas de métodos que providencia um mecanismo para separação clara entre a vista externa e a vista interna de um determinado elemento • permite compreender melhor uma abstração sem se ter de conhecer os detalhes da sua implementação • Promove a abstração; desenvolvimento baseado em componentes; separação de aspectos • Suportada pela generalidade das modernas linguagens de programação (Java, VB, VisualC++, Delphi, Corba IDL, COM IDL, …) • A adequada definição de interfaces é essencial para um bom desenho/desenvolvimento de sistemas OO Visão externa interface elemento Visão interna

38. Interfaces Uma interface é uma coleção de operações que são usadas para especificar um serviço de uma classe ou de uma componente

39. Interfaces exemplo de interfaces de uma componente em Active-X...

40. Interfaces - Relações • Uma interface pode participar em relações do tipo generalização, associação, e dependência • Adicionalmente pode participar em relações do tipo “realização” A realização é uma relação semântica entre duas entidades, em que uma específica um contrato, e a outra garante a sua execução. Quais?

41. Interfaces – em UML 2.0 Considere a situação: A universidade promove várias actividades de cariz socio-profisssional (e.g., jantares-debates, cursos de curta duração, visitas a empresas), as quais podem ser patrocionadas por empresas Considere que “Actividade” é uma interface... OK! ??!

42. Interfaces – em UML 2.0 Considere a situação: A universidade promove várias actividades de cariz socio-profisssional (e.g., jantares-debates, cursos de curta duração, visitas a empresas), as quais podem ser patrocionadas por empresas Considere que “Actividade” é uma interface...

43. Interfaces - Sugestões Uma interface bem estruturada é: • Simples, ainda que completa: • providencia todas as operações necessárias para especificar um determinado serviço ou papel • E.g., serialização, gestão de nomes, estabelecimento de conexões HTTP, acesso a objecto remoto, … • Compreensível: • providencia informação suficiente para ser, quer usada, quer realizada sem ser necessário examinar-se a sua realização • Fácil de aprender/utilizar • providencia informação para ser fácil utilizar as suas operações principais, sem se ter que dominar, em detalhe, todas as operações

44. Package A Packages Motivação Torna-se difícil, impraticável, modelizar de uma “só vez” sistemas de média/grande dimensão ou complexidade package O que é? É um mecanismo genérico para organizar elementos em grupos • Um package pode conter outros elementos, incluindo: classes, interfaces, … e mesmo outros packages • Qq elemento é definido em apenas um único package • Um package providencia suporte para um espaço de nomes adequado • e.g., X::A é diferente de X::Y:A, diferente de Z::A, ...

45. Packages - Exemplos

46. Packages - Importação/Exportação O package origem tem acesso ao conteúdo (público) do package destino. A tem acesso a B, mas o recíproco não é verdade.

47. Packages - Tipos Standard 5 estereótipos standard para packages… • facade: • pacote com elementos (tipicamente classes e interfaces) que constituem a fachada (ou a interface de programação) providenciada conjunta e coerentemente por outros pacotes • framework: • um framework é uma arquitectura de classes e interfaces com inúmeros pontos de variabilidade ou de extensão e com estruturas de objectos padronizadas, conhecidas por padrões de desenho • stub: • um adaptador (stub) é usado quando se pretende partir um sistema em diferentes pacotes por motivos, e.g., de divisão de trabalho • subsystem: • uma parte independentemente do sistema inteiro • system: • pacote que representa o sistema inteiro; tipicamente este pacote agrega pacotes dos restantes tipos (subsistema, fachada, etc.)

48. Packages - Conselhos ... Um package bem estruturado é: • Coerente: • providencia uma fronteira bem definida que agrega um conjunto de elementos relacionados • Minimiza as dependências: • exporta apenas os elementos que outras packages necessitarão; e importa de outras packages os elementos estritamente necessários • Tem hierarquias balanceadas • evitar largas/profundas hierarquias de packages aninhadas • Tem conteúdo balanceado • dentro do conjunto de packages de um sistema, não deverão existir packages nem demasiado grandes (partir), nem demasiado pequenos (juntar) Quando utilizar Packages? • Sempre que um determinado diagrama que representa o sistema (ou subsistema) não seja legível numa “folha A4” • Particularmente úteis para os testes unitários => um caso de testes por package • Úteis ainda em termos de unidades de programação

49. Packages - Exercício • Considere o sistema de jogos de futebol. Defina 4 packages respectivamente para agrupar classes relativas a (1) equipas de jogadores; (2) equipas de arbitragem; (3) clubes de futebol; e (4) os jogos propriamente ditos. • Defina o diagrama de packages respectivo, evidenciando as classes exportadas e as dependências de importação correspondentes.

50. Instâncias • Uma instância é uma manifestação concreta de uma abstracção, à qual um conjunto de operações pode ser aplicado, e que tem um estado que regista os efeitos das operações • Em geral designa-se “instância” a “objecto” e vice-versa; mas rigorosamente são conceitos distintos. E.g., • instância de uma classe é um objecto • instância de uma associação é um link • instância de um nó é um computador que se encontra fisicamente num local • instância de um use case é um cenário