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 Silva / José Borbinha

2. Modelação da Estrutura • Classes • Relações • Diagramas de Classes • Interfaces • Instâncias • Diagramas de Objectos • Pacotes (Packages)

3. Classes Uma classerepresenta uma categoria de objectos que partilham os mesmos: • atributos • operações • relações • semântica

4. Classes – Atributos e Operações • Tipos de visibilidade: • + público (pode ser visto e usado por qualquer classe que conheça esta classe) • privado (só pode ser visto dentro da classe) • # protegido (só pode ser visto dentro da classe, ou pelos seus descendentes Atributos: [visibility] [/] name [: type] [ multiplicity ] [= default] [{ property-string }] Operações: [visibility] name [( parameter-list )] : [return-type] [{ property-string }]

5. Classes - Sugestões • Uma classe deve corresponder a algo tangível ou a uma abstracção conceptual existente no domínio do problema ou no domínio da solução • Uma classe bem estruturada ... • Providencia uma abstracçã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.

6. Modelação da Estrutura • Classes • Relações • Diagramas de Classes • Interfaces • Instâncias • Diagramas de Objectos • Pacotes (Packages)

7. Relações Uma relação é uma ligação entre elementos. Numa modelação orientada a objectos os três tipos de relações mais importantes são: • Dependências • Generalizações • Associações elemento B relação elemento A

8. 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.

9. Relações – Dependência (tipos de predefinidos) • Abstracçã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

10. 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).

11. Rectangle Circle Polygn corner: Point radius: Float points: List Relações - Generalização Shape origin move() resize() display() 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”. Square No contexto de classes usam-se generalizações para ilustrar relações de herança.

12. 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 trabalham 1 ou mais pessoas.

13. Relações - Associação • Multiplicidade de uma associação • 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 e intervalos múltiplos 1 0..* ou apenas * 1..* 0..1 2..4 2, 4..6

14. Relações – Associação (Adornos Básicos) • - nome • - o papel de cada participante na associação • - a multiplicidade de cada participante na associação • - tipo de agregação

15. Relações – Associação (Adornos de 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.

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

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

18. * 1 UserGroup User Password * * +user -key +owner Relações – Associação (Adornos de Visibilidade) Quando se pretende limitar a visibilidade a objectos externos a determinada associação. Navegação da associação “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

19. Relações – Associação (Adornos de Qualificação) • Um qualificador é um atributo de uma associação que limita a relação entre as duas entidades relacionadas por essa associação. Banco TabuleiroXadrez NrConta Linha Coluna qualificador * 1 0..1 1 Pessoa Quadrado

20. Relações – Associação (Adornos de Agregação) Relações entre classes do tipo “is-part-of” ou “has-a” são representadas através de agregação. ... uma Pessoa pode existir sem uma Empresa... Uma composição é uma agregação forte ( “todo” em relação à “parte”) e com tempo de vida delimitado (as “partes” não podem existir sem o “todo”). O “todo” é responsável pela criação e destruição das suas “partes”. ... um Departamento não existe sem o contexto de uma Empresa...

21. Relações - Associação

22. 1 1 1 1 Tampo Tampo Relações – Associação... • «Uma mesa é constituída por um tampo e por quatro pernas…» • «Uma mesa é constituída por um tampo e por duas a seis pernas, as quais têm de estar ordenadas…» Mesa Mesa Ordem 1 1 4 2..6 Perna Perna

23. 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, modelada também como uma classe. * 1..* Pessoa Empresa empregador empregado Tarefa descrição dataInício salário classe associação

24. 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.

25. “Tarefa” é uma classe resultante da associação entre as classes “Pessoa”, “TipoTarefa” e “Empresa” TipoTarefa Tarefa 1 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

26. * professor Departamento 1 sub-departamento Docente * 1 assistente Relações - Associações Reflexivas Quando uma classe tem uma associação consigo própria... “um departamento universitário pode conter outros departamentos” • “um docente, enquanto professor, pode ser responsável por outros docentes, designados por assistentes” • “um docente, enquanto assistente, está dependente de um outro docente, designado por professor”

27. 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.

28. Modelação da Estrutura • Classes • Relações • Diagramas de Classes • Interfaces • Instâncias • Diagramas de Objectos • Pacotes (Packages)

29. 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 • ....

30. Diagramas de classes Perspectivas: • Modelo de Análise – diagrama de classes representa os conceitos do domínio em análise; normalmente existirá uma relação com as classes que os implementarão (modelos de domínio) • Modelo de Desenho - diagrama de classes representa o desenho da implementação do software • São muito ricos; podem-se tornar muito complicados... • Não se devem 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)

33. Diagrama de Classes dos diagramas da UML2.0

34. Modelação da Estrutura • Classes • Relações • Diagramas de Classes • Interfaces • Instâncias • Diagramas de Objectos • Pacotes (Packages)

35. 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 abstracção sem se ter de conhecer os detalhes da sua implementação • Promove a abstracçã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

36. Interfaces Uma interface é uma especificação de um comportamento, uma colecção de operações que especificam um serviço de uma classe ou de um componente

37. Interfaces exemplo de interfaces de uma componente em Active-X... WP.exe wordsmith.dll <<Interface>> ISpell WP.exe wordsmith.dll ISpell

38. Interfaces - Relações • Uma interface pode participar em relações do tipo generalização, associação, dependência ou “realização” 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.

39. Interfaces – Quando detalhar? Caso: A universidade promove várias actividades de cariz socioprofissional (e.g., jantares-debates, cursos de curta duração, visitas a empresas), as quais podem ser patrocinadas por empresas. Considerando que “Actividade” é uma interface: OK ??!

40. 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

41. Modelação da Estrutura • Classes • Relações • Diagramas de Classes • Interfaces • Instâncias • Diagramas de Objectos • Pacotes (Packages)

42. 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 • Exemplos: • uma instância de uma classe é um objecto • uma instância de uma associação é uma ligação (link) • uma instância de um nó é um computador em concreto • uma instância de um caso de utilização (use case) é um cenário

43. Instâncias - Objectos • Um objecto é uma instância de uma classe • O objecto herda assim todos os atributos e métodos definidos na classe, possuindo uma representação de execução própria (a qual se pode designar genericamente por estado), bem como uma identificação única no contexto da sua execução Sintaxe do nome de um objecto: Nome-do-objecto : Nome-da-classe

44. Instâncias - Objectos Estado de um objecto... • é dado pelos valores assumidos pelo conjunto de atributos de um objecto. • é naturalmente um facto dinâmico, variando ao longo do tempo e do espaço na medida em que o objecto interactua com outros objectos

45. Instâncias - Objectos Activos Objectos activos: objectos que podem executar o seu próprio comportamento sem necessidade de evocação de um método/operação em concreto Ex: actores, processos, threads, agentes, aplicações,... t:HandlerNetworkThread :AgentNews :Produtor :Produtor Linhas com maior espessura

46. Instâncias - Objectos Compostos • Um objecto composto é constituído por outros (sub)objectos. • Podem ocorrer inúmeras situações de objectos compostos, mas em geral tal reflecte relações de agregação entre as respectivas classes. my:Empresa my:Empresa d-fin:Departamento d-fin:Departamento d-ven:Departamento d-ven:Departamento  d-pro:Departamento d-pro:Departamento Objecto composto A vantagem de se representar um conjunto relacionado (por agregação) de objectos através de um objecto composto é essencialmente por motivos de clareza e simplicidade dos diagramas produzidos, para além de se explicitar desta forma o nível de coesão entre os objectos.

47. Modelação da Estrutura • Classes • Relações • Diagramas de Classes • Interfaces • Instâncias • Diagramas de Objectos • Pacotes (Packages)

48. Diagramas de Objectos Um diagrama de objectos... • ilustra um conjunto de objectos e respectivas relações num determinado momento • permite captar uma imagem ou fotografia momentânea sobre determinado sistema • é um grafo composto por objectos e ligações (links) entre eles • Um diagrama de objectos não pode especificar completamente a estrutura de objectos de um dado sistema, pois para cada classe há quase sempre um grande número de combinações potenciais entre instâncias… • Assim, o objectivo dos diagramas de objectos é apenas expor conjuntos relevantes de objectos de modo a melhor se entender as suas funcionalidades e relações.

49. tem tem ZéMaria:Pessoa nome=“Zé Maria” AudiA3:Veiculo modelo=A3 TDi matricula=99-99-MM cor=vermelho :Motor número=9999 cilindrada=1900cc combustível=gasóleo Diagramas de Objectos Exemplo “Sistema de Gestão de Automóveis” Uma pessoa pode ser proprietário de vários veículos e estes são possuídos apenas por uma única pessoa. Por outro lado, um veículo tem de possuir necessariamente um motor. Um veículo é identificado univocamente pela matrícula e possuí ainda outras informações, tais como a cor, data de fabrico, marca e modelo. Um motor é identificado por um número de motor, tipo de combustível e cilindrada Veículo modelo matricula cor Motor número cilindrada combustível 1 0..1 * 0..1 Pessoa O Zé Maria é dono de um Audi A3 TDi vermelho, com matricula ‘99-99-MM’, que tem um motor 1900cc, com número ‘9999’

50. Diagramas de Objectos - Sugestões... Um diagrama de objectos bem estruturado: • Tem um foco: focaliza um determinado aspecto da visão do desenho/processo estático do sistema • Representa uma “Fotografia”: representa uma fotografia no storyboard dinâmico representado por um diagrama de interacções • É simples: contém apenas os elementos que são essenciais à compreensão de determinado aspecto • É consistente: providencia detalhes de forma consistente com o seu nível de abstracção