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

Apresentação em tema: "Unified Modeling Language (UML) - Modelação da Estrutura -"— Transcrição da apresentação:

1 Unified Modeling Language (UML) - Modelação da Estrutura -
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 classe representa 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 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”. Rectangle corner: Point Circle radius: Float Polygn points: List 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 Relações – Associação (Adornos de Visibilidade)
Quando se pretende limitar a visibilidade a objectos externos a determinada associação. User Password 1 * +owner UserGroup -key +user 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 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 Tampo 1 Ordem 1 Tampo 1 1 4 Perna 2..6 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. Pessoa 1..* * Empresa empregado empregador Tarefa descrição dataInício salário classe associação

24 Associação N-Ária (N  3)
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... Pessoa Empresa * Tarefa descrição dataInício salário classe associação TipoTarefa 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 Associação N-Ária (N  3)
Relações - Associação Associação N-Ária (N  3) Pessoa Empresa 1 Tarefa descrição dataInício salário TipoTarefa * “Tarefa” é uma classe resultante da associação entre as classes “Pessoa”, “TipoTarefa” e “Empresa” 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 Relações - Associações Reflexivas
Quando uma classe tem uma associação consigo própria... * 1 sub-departamento Departamento * 1 professor assistente Docente “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)

31

32

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 Sintaxe do nome de um objecto: Nome-do-objecto : Nome-da-classe
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 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 Pessoa 0..1 * 0..1 1 O Zé Maria é dono de um Audi A3 TDi vermelho, com matricula ‘99-99-MM’, que tem um motor 1900cc, com número ‘9999’ 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 tem

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

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

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

53 Packages - Exemplos

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

55 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”!!! Um caso de testes por package!!! Úteis ainda em termos de unidades de programação...

56 Modelação da Estrutura
Classes Relações Diagramas de Classes Interfaces Instâncias Diagramas de Objectos Pacotes (Packages) FIM!!!