1

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

Alberto Silva / José Borbinha

Análise e Concepção de Sistemas de Informação

2

Modelação da Estrutura

• Classes• Relações• Diagramas de Classes• Interfaces• Instâncias• Diagramas de Objectos• Pacotes (Packages)

3

ClassesUma classe representa uma categoria de objectos que partilham os mesmos:– atributos– operações– relações– semântica

4

Classes – Atributos e Operações

Atributos: [visibility] [/] name [: type] [ multiplicity ] [= default] [{ property-string }]Operações: [visibility] name [( parameter-list )] : [return-type] [{ property-string }]

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

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çõesUma 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 A

elementoB

relação

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ênciaExemplo 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

originmove()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”.

Rectanglecorner: Point

Circleradius: Float

Polygnpoints: 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

1

0..* ou apenas *

1..*

0..1

2..4

2, 4..6

Não especificada

Apenas uma

Zero ou mais

Uma ou mais

Zero ou uma

Intervalo especificado

Valores e intervalos múltiplos

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

Por omissão a navegação numa associação é bidireccional.

A navegação é um adorno mais relevante na fase de desenho...

“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 .”

Relações – Associação (Adornos de Navegação)

18

Relações – Associação (Adornos de Visibilidade)

Quando se pretende limitar a visibilidade a objectos externos a determinada associação.

Tipos de visibilidade:+ público- privado# protegido

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

User Password1 *

+ownerUserGroup

-key+user* *

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.

Pessoa

qualificador*

Banco

NrConta

0..1

Quadrado

1

TabuleiroXadrez

LinhaColuna

1

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

... uma Pessoa pode existir sem 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…»

Perna

1

Mesa

Ordem

2..6Perna

1

Mesa

4

Tampo

1

1Tampo

1

1

23

Relações - 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.

Classes-Associação

Pessoa Empresa1..* *

empregado empregador

Tarefa

descriçãodataIníciosalário

classe associação

24

Relações - Associação

Associações com aridade 3 ou superior.São pouco comuns, mas há casos que a sua aplicação é vantajosa...

Associação N-Ária (N 3)

Pessoa Empresa* *

TarefadescriçãodataIníciosalário

classe associação

TipoTarefa*

Tarefa

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

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 Pessoa Empresa1 1

TarefadescriçãodataIníciosalário

TipoTarefa1

*

“Tarefa” é uma classe resultante da associação entre as classes “Pessoa”, “TipoTarefa” e “Empresa”

* *

26

Relações - Associações Reflexivas

Quando uma classe tem uma associação consigo própria...

• “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”

*1professor

assistenteDocente

“um departamento universitário pode conter outros departamentos”

*

1sub-departamento

Departamento

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 classesPerspectivas:

• 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

• 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

Visão interna

interface

elemento

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.

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

ISpell<<Interface>>

ISpell

WP.exe wordsmith.dll

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:

Jantar-DebateEmpresaActividade

obterResponsável()obterPatrocionadores()obterCusto()

<<Interface>>

patrociona >

Jantar-DebateEmpresa

Actividade

patrociona >

??!

OK

40

Interfaces - Sugestões

• 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

Uma interface bem estruturada é:

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 concretoEx: actores, processos, threads, agentes, aplicações,...

:AgentNews

t:HandlerNetworkThread

:Produtor:ProdutorLinhas 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

d-fin:Departamento

d-pro:Departamento

d-ven:Departamento

d-fin:Departamento

d-pro:Departamento

d-ven:Departamento

my:Empresa

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 ObjectosUm 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

Pessoa Veículomodelomatriculacor

Motornúmerocilindradacombustível

*0..1 10..1

ZéMaria:Pessoa

nome=“Zé Maria”

AudiA3:Veiculo

modelo=A3 TDimatricula=99-99-MMcor=vermelho

:Motor

número=9999cilindrada=1900cccombustível=gasóleo

tem tem

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

51

Modelação da Estrutura

• Classes• Relações• Diagramas de Classes• Interfaces• Instâncias• Diagramas de Objectos• Pacotes (Packages)

52

Packages

Torna-se difícil, impraticável, modelar de uma “só vez” sistemas de média/grande dimensão ou complexidade

Motivação

É um mecanismo genérico para organizar elementos em grupos

O que é?Package A

package

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

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

5 estereótipos standard para packages…

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!!!