1 unified modeling language (uml) - modelação da estrutura - alberto silva / josé borbinha...
TRANSCRIPT
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!!!