UML 2.0 – Uma visão geral… Engenharia de Software MIEIC 2007/2008
UML 2.0 – Uma visão geral…
Engenharia de Software
MIEIC 2007/2008
Authors
Ademar Aguiar [email protected]
João Pascoal Faria - [email protected]
Nuno Honório Flores [email protected]
Pedro Mendes - [email protected]
http://paginas.fe.up.pt/~softeng/2
3
Sumário Introdução
Visão Histórica
Tipos de Elementos Básicos
Tipos de Relações
Tipos de Diagramas Principais
Mecanismos Comuns do UML
Objectivos do UML 2.0
4
Introdução (I)
UML : Unified Modeling Language•Linguagem para especificação, construção,
visualização e documentação de artefactos de um sistema informático.
•Standard da OMG (Object Management Group)
•Adoptado por empresas e instituições de todo o mundo
•Existem mais de 50 ferramentas comerciais e académicas para modelação com o UML.
5
Introdução (II)
UML – Características principais• Semântica e notação para tratar um grande número
de tópicos actuais de modelação
• Semântica para tratar tópicos de modelação futura- tecnologia de componentes, computação distribuída,
frameworks e Internet.
• Mecanismos de extensão que permitem que futuras aproximações e notações possam usar o UML.
• Semântica e sintaxe para facilitar a troca de modelos entre ferramentas distintas.
6
Introdução (III)
UML – Objectivos na sua concepção• Definição de uma linguagem de modelação
standard- Independente da linguagem de programação,
ferramentas CASE e processo de desenvolvimento.- Para diferentes projectos, diferentes metodologias,
mas a mesma linguagem de modelação• Independente das ferramentas de modelação
- Apesar de sugerir algumas ideias na apresentação, não aborda todos os requisitos necessários, por não ser esse o seu objectivo.
• Simplicidade• Coerência na unificação de elementos de outras
notações (Booch, OMT, OOSE, …)
7
Visão Histórica
OOSE Booch’91 OMT-1Outros
Métodos
Booch’93 OMT-2
Unified Method 0.8
UML 0.9 UML Partners
UML 1.0
UML 1.4
UML 2.0
Fragmentação
Unificação
Industrialização
Normalização
Out 1995
Jun 1996
Jan 1997
2001
2001-2004
8
Tipos de Elementos Básicos (I)
Estrutura de Conceitos•Conjunto variado de notações, as quais
podem ser aplicados em diferentes domínios de problemas e a diferentes níveis de abstracção.
•(1) “coisas” ou elementos básicos através dos quais se definem os modelos.
•(2) relações, que relacionam elementos•(3) diagramas, que definem regras de
agrupamento de elementos
9
Tipos de Elementos Básicos (II)
Principais elementos da estrutura• Classes, Objectos, Interfaces, Casos de Utilização,
Actores, Colaborações, Componentes, Artefactos e Nós.
• Elementos de especificação de comportamento (estados e actividades)
• Elementos de agrupamento (pacotes e fragmentos)
• Anotações e restrições
Classe
Actor
ObjectoPacote
ComponenteNó
Caso de Utilização
Estado Estado Composto
Actividade Anotação
10
Tipos de Relações
Relações• Sintaxe e semântica bem definidas
• Permitem o estabelecimento de interdependências entre os elementos básicos vistos anteriormente.
Tipos• Associação
• Dependência
• Realização
• Generalização
• Agregação
11
Tipos de Diagramas Principais (I)
Diagramas•Possibilidade de agrupar elementos básicos
e as suas relações de uma forma lógica ou que estruturalmente faça sentido.
• “Nenhum modelo é suficiente por si só. Qualquer sistema não-trivial é melhor representado através de um pequeno número de modelos razoavelmente independentes”
• Três categorias de diagramas : Comportamento, Interacção e Estrutura.
12
Tipos de Diagramas Principais (II)
Diagramas de Comportamento• Demonstram os aspectos comportamentais e de reacção
do sistema ou da lógica de negócio do projecto.- Actividade, Estados, Casos de Uso e todos os de interacção.
Diagramas de Interacção• Sub-conjunto de diagramas de comportamento que
enfatizam a interacção entre os objectos.- Comunicação, Interacção entre objectos, Sequência, Visão
geral da interacção e Temporal.
Diagramas de Estrutura• Especificação estrutural do elementos independente do
tempo.- Classes, Estrutura Composta, Componentes, Instalação,
Objectos e Pacotes.
13
Tipos de Diagramas Principais (III)
Diagramas de Casos de Utilização• Descreve a relação entre actores e casos de
utilização de um dados sistema.• Permite dar uma visão global e de alto nível do
sistema.• Fundamental na definição correcta da fronteira do
sistema.• Utilizados preferencialmente nas tarefas de
especificação de requisitos e/ou modelação dos processos de negócio.
• Equivalentes aos homólogos no método OOSE.
14
Tipos de Diagramas Principais (IV)
Diagramas de Casos de Utilização: Exemplo (I)
15
Tipos de Diagramas Principais (V)
Diagramas de Casos de Utilização: Exemplo (II)
16
Tipos de Diagramas Principais (VI)
Diagrama de Classes• Descrevem a estrutura de um sistema, em
particular as entidades existentes, as suas estruturas internas, e relações entre si.
Diagrama de Objectos• Descreve um conjunto de instâncias compatíveis
com determinado diagrama de classes.
• Permitem ilustrar os detalhes de um sistema em determinado momento, ao providenciarem cenários de possíveis concretizações.
17
Tipos de Diagramas Principais (VII)
Diagrama de Classes (exemplo)
18
Tipos de Diagramas Principais (VIII)
Diagrama de Objectos (exemplo)
19
Tipos de Diagramas Principais (IX)
Diagrama de interacção entre objectos• Composto por dois sub-diagramas:
- Diagrama de Sequência- Diagrama de Comunicação
Diagrama de Sequência• Ilustram interacções entre objectos num determinado
período de tempo• Objectos representados pelas suas “linhas de vida” e
interagem por troca de mensagens aos longo de um determinado período de tempo.
Diagramas de Comunicação• Ilustram interacções entre objectos com ênfase para a
representação das ligações entre objectos.• Sequência de mensagens e actividades concorrentes
determinada usando números sequenciais, com diferentes níveis hierarquicos.
20
Tipos de Diagramas Principais (X)
Diagrama de Sequência - Exemplo
21
Tipos de Diagramas Principais (XI)
Diagrama de Comunicação - Exemplo
22
Tipos de Diagramas Principais (XIII)
Diagrama de Estados - Exemplo
23
Tipos de Diagramas Principais (XVI)
Diagrama de Actividades - Exemplo
24
Tipos de Diagramas Principais (XII)
Diagramas de Estados• Descrevem as sequências de estados que um objecto ou
uma interacção pode passar ao longo da sua existência em resposta a estímulos recebidos, conjuntamente com as suas respostas e acções
Diagramas de Actividades• Representam uma série de acções e/ou actividades, e em
que as transições são desencadeadas regra geral devido à simples conclusão de acções/actividades.
• Adequado para representar o comportamento de algoritmos, processos de negócio e casos de utilização.
• Caso particular dos diagramas de estados• Inspirados nos fluxogramas.
25
Tipos de Diagramas Principais (XV)
Diagramas de Componentes• Descrevem as dependências entre componentes de
software, incluindo componentes de código fonte, código binário e executáveis.
• Representados na forma de tipos e não na forma de instâncias. Para instâncias de componentes, usam-se os diagramas de instalação.
Diagramas de Instalação• Descrevem a configuração de elementos de suporte
ao processamento, componentes de software, processos e objectos existentes nesses elementos.
26
Tipos de Diagramas Principais (XVI)
Diagrama de Componentes - Exemplo
27
Tipos de Diagramas Principais (XVII)
Diagrama de Instalação - Exemplo
28
Hierarquia de Diagramas UMLDiagrama UML
Diagrama Estrutura
Diagrama Comportamento
Diagrama de Classes
Diagrama de Pacotes
Diagrama de Objectos
Diagrama Estrutura Composta
Diagrama Componentes
Diagrama Instalação
Diagrama Casos de Utilização
Diagrama Interacção
Diagrama Actividades
Diagrama Estados
Diagrama Sequencia
Diagrama Comunicação
Diagrama Temporal
Diagrama Visão Geral Interacção
29
Mecanismos Comuns do UML
Existe um conjunto de mecanismos comuns que pode ser utilizado, independentemente do diagrama.•Anotações, mecanismos de extensão e
tipos de dados
30
Mecanismos Comuns do UML (I)
Notas (ou Anotações)• Ilustra um comentário e não tem impacto
semântico.
• Utilização para descrever informalmente.- Requisitos, restrições, observações, revisões ou
explicações.
• Podem existir autonomamente, i.e., sem estar directamente associados a uma elemento específico.ClasseMuito
Complexa
Esta classe é muito complexa. Deve ser implementada segundo o padrão “Facade”.
31
Mecanismos Comuns do UML (II)
Notas (ou Anotações) – Recomendações na sua Utilização:
•Localização: Devem ser colocadas graficamente perto dos elementos que descrevem.
•Visibilidade: Podem-se esconder ou tornar visíveis (dependendo da ferramenta)
•Extensão: Devem-se usar referências (e.g., nomes de documentos ou URLs) caso se pretenda um comentário mais extenso.
•Evolução: À medida que o modelo evolui, as notas mais antigas (que se tornem não relevantes) devem ser eliminadas do modelo.
32
Mecanismos Comuns do UML (III)
Mecanismos de Extensão• Estender a notação de forma consistente
- Estereótipos, marcas e restrições.
• Considerações a ter:- Introduzir um número reduzido destes elementos- Escolher nomes curtos e com significado para
estereótipos e marcas.- Sempre que a precisão for relaxada, usar texto livre
para a especificação de restrições, senão usar OCL.- Realizado por número restrito de especialistas e
devidamente documentado.
33
Mecanismos Comuns do UML (IV)
Mecanismos de Extensão : Estereótipos• Meta-tipo: tipo que descreve tipos.
• Permite definir novos tipos de elementos sem se alterar o metamodelo do UML.
• O nome de um estereótipo é representado entre « », podendo-se referir os seguintes exemplos:
- Na modelação de processo de negócio- «trabalhador», «documento», «política», …
- Na modelação de aplicações específicas- «interface», «controlo», «entidade»,…
- etc…
34
Mecanismos Comuns do UML (V)
Mecanismos de Extensão : Estereótipos•A definição de um estereótipo tem de ter
em conta os seguintes aspectos:- Propriedades (seu próprio conj. de marcas)- Semântica (suas próprias restrições)- Notação (seu próprio ícone)- A classe base do metamodelo que vai ser
estendida.
Sensor Temperatura
«exception»Overflow
«metaclass»ModelElement
35
Mecanismos Comuns do UML (VI)
Mecanismos de Extensão : Marcas com Valor• Permitem adicionar novas propriedades aos
elementos, sejam elementos já existentes ou “estereotipados”.
• Deve ser entendido como metadata, pois o seu valor aplica-se ao próprio elemento e não à sua instância.
• Um par “marca” e “valor” é delimitado pelos caractéres { }. Exemplos usuais:
- Geração de código.- Produção automática de documentação.- Gestão de configurações
-nome {cor=amarelo}
Aluno{autor=”JB”, data=”1/1/2005"}
36
Mecanismos Comuns do UML (VII)
Mecanismos de Extensão : Restrições• Permitem adicionar ou alterar a semântica assumida por
omissão de qualquer elemento UML.
• Especificação de uma condição delimitada pelos caractéres { }. Pode ser formal (OCL) ou informal (texto em português).
• Permite especificar condições que têm de ser validadas para que o modelos esteja “bem definido”.
-género: {m,f}
Pessoa -mulher
0..1
-marido0..1
{self.mulher.genero="f" and self.marido.genero="m"}
37
Mecanismos Comuns do UML (VIII)
Tipos de Dados• Abstracção utilizada de forma implícita no UML.• Não são elementos do modelo e por conseguinte, não é
possível associar-lhes estereótipos, marcas com valor ou restrições.
• Um tipo primitivo é um tipo de dados que não tem uma subestrutura.
• Exemplos de tipos de dados:- Primitivos: Integer, String, Time- Enumerados: Boolean, AggregationKind, VisibilityKind- Outros: Expression, Mapping, Coordinate, Name, Multiplicity
• Note-se que os conceitos de nomes, expressões ou multiplicidade são tipos de dados UML definidos à custa de outros primitivos.
38
Objectivos do UML 2
Melhorar a arquitectura geral do modelo.
Melhorar os mecanismos de extensibilidade
Separar a semântica dos diagramas de estados relativamente aos diagramas de actividade
Melhorar a gestão de modelos
Melhorar os suporte para o desenvolvimento baseado em componentes
Melhorar a modelação de relações
Suportar um modelo de versões.
39
Referências
Algumas ferramentas de modelação visual • Rational Architect(www.rational.com)• Enterprise Architect (www.sparxsystems.com)• Together (www.togethersoft.com) • Platinum Paradigm Plus (www.platinum.com)• Microsoft Visio
Livros• UML 2 and the Unified Process: Practical Object-
Oriented Analysis and Design by Jim Arlow and Ila Neustadt, Addison Wesley (14 Jul 2005)
• The Object Primer: Agile Model-driven Development with UML 2.0, Scott W. Ambler, Cambridge University Press (22 Mar 2004)
Notações• www.omg.org
40
Dúvidas, Questões, Comentários, Opiniões?