Introdução à UML: Elementos, Relacionamentos e Diagramas

Prévia do material em texto

UML, Introdução
O propósito da UML (Unified Modeling Language) é o de:
Visualizar		Apresenta graficamente os elementos da aplicação 
Especificar		Define a estrutura o comportamento dos elementos da aplicação 
Construir		Fornece uma guia para análise e codificação das aplicações 
Documentar		Documenta requerimentos, arquitetura, código, testes, protótipos, versões etc. 
Para sistemas orientados a objeto, sendo empregada principalmente em sistemas intensivos em software [1].
Building Block, “Lego”
A UML é uma linguagem constituída de elementos básicos que podem, por sua vez, serem combinados de modo a formar novos elementos. Esses building blocks podem ser de 3 tipos: Elementos, Relacionamentos e Diagramas.
Elementos
Estruturais		 Classes, interfaces, colaborações, casos de uso, componentes, nós
Comportamentais		Mensagens, estados de objetos
Elementos de agrupamento	Pacotes
Elementos de anotação	Notas
Relacionamentos
Dependência			(<<include>>, <<extend>>~, <<import>> são alguns estereótipos de dependência) 
Associação			(composição, agregação e associações com navegabilidade são casos especiais) 
Generalização			(o termo empregado para herança e especializações na UML)
Realização			(empregado especialmente na realização de interfaces)
Diagramas
Diagrama de classes
Diagrama de Objetos
(Diagramas de Interação)
	Diagramas de Seqüência
	Diagramas de Colaboração
Diagramas de Estado
Diagramas de Atividades
Diagramas de Componentes
Diagramas de Distribuição
Níveis e diferentes visões dos diagramas
Dependendo do nível de detalhe os diagramas da UML podem ser: Conceituais, de Especificação (Desenho) ou de Implementação (Codificação). Por oferecer diferentes visões de um mesmo sistema a UML apresenta uma visão Ortogonal das aplicações. 
Ciclo de vida de desenvolvimento de software
A UML é independente do ciclo de vida de desenvolvimento de software empregado. Entretanto a UML se beneficia de métodos de desenvolvimento:
Direcionados pelos Casos de Uso
Centrados na arquitetura
Interativos e Incrementais
Não sendo de forma alguma um processo seqüencial e linear de desenvolvimento (ver figura abaixo).
Exercícios
1. Identifique os diagramas Estruturais, Comportamentais e de Arquitetura da UML. 
2. Quais as 5 visões oferecidas pela UML em um projeto de software? 
R. Visão do caso de uso; visão de desenho (design ou projeto); de processo; de implementação; e de distribuição (deployment). 
UML, Casos de Uso
Geral
Casos de Uso					Diagramas estruturais
Atores						Agentes externos ao sistema
Caso de uso					Representam um funcionalidade autocontida
Relacionamentos				Associações Atores-Casos de Uso; dependência; generalização;
Dependência					Estereótipos: <<include>>; <<extend>>
Fluxo de Eventos
Para cada caso de uso do diagrama deve haver uma descrição textual com os seguintes elementos: 
Nome do caso de uso
Atores participantes
Condições de entrada			(Condições que precisam ser satisfeitas antes do caso de uso ser iniciado) 
Fluxo de eventos principais
	Fluxo de eventos secundários
Condições de saída				(Condições que precisam ser satisfeitas depois do caso de uso estar completado)
Requerimentos especiais
Cenários
Os cenários são instâncias de casos de uso e devem ser empregados quantos cenários forem necessários para que se complemente a descrição dos casos de uso. Alguns tipos de cenários úteis:
Cenários “As-is”
Cenários futuros
Cenários para avaliação
Cenários para treinamento
Requerimentos não funcionais 
Os requerimentos não funcionais, como considerações de performance e de segurança do sistema, não são exatamente parte dos diagramas UML mas devem fazer parte do levantamento e da descrição de qualquer sistema (ver exercício abaixo).
Boas práticas
Identificando Atores:
	Identifique grupos de usuários: a) suportados pelo sistema em seu trabalho; b) grupos que executam as principais funções do sistema e funções secundárias; c) interações do sistema com agentes externos de hardware ou software.
Identificando Cenários:
	Identifique grupos de usuários que criam, modificam, acessam e removem os dados.
	Identifique as tarefas que cada grupo de usuários deseja executar.
	Identifique a frequencia e a validade das informações dadas e fornecidas pelo sistema. 
Identificando Casos de Uso:
	Lembre-se os casos de uso são estruturais e, portanto, descrevem grandes estruturas ou partes do sistema.
	Na descrição, seja dos diagramas, fluxo de eventos ou cenários, deve-se empregar sempre a linguagem do usuário. 
 
Exercícios
1. Diferencie e dê exemplo das dependências do tipo <<include>> e <<extend>> em casos de uso.
2. Casos de uso devem fazer uso da linguagem do usuário. Justifique. 
3. Os cenários são sempre construídos antes da criação dos diagramas de casos de uso. Justifique.
4. Não existe nenhum sentido de fluxo ou sequencia nos diagramas de casos de uso. Justifique. 
UML, Diagramas de classe
Uma classe simples
Uma classe simples em Java com um a único atributo e uma única operação. 
public class Employee { 
private int empID; 
public double calcSalary(){ 
... } 
}
Atributos
[visibilidade] nome [multiplicidade] [:tipo] [=valor inicial] [{outras propriedades}]
+ public [0..5] *item frozen
# protected int changeable	
- private String addOnly
O atributo ainda pode ser sublinhado para indicar escopo de classe no lugar de escopo de instância.
Operações
[visibilidade] nome [ (lista de parâmetros) ] [: tipo de retorno ] [{outras propriedades}]
 isQuery
 sequential
 concurrent		
(lista de parâmetros) := [direção] nome : tipo [=valor inicial]
 in
 out
 inout		
Principais relacionamentos
Dependência 
public class Employee { 
public void calcSalary(Calculator c) { 
... 
} 
}
Associação simples e navegabilidade 
public class Employee { 
private TimeCard _tc[]; 
public void maintainTimeCard() { 
... 
} 
}
Agregação
public class Employee { 
private EmpType et[]; 
public EmpType getEmpType() { 
...
	}
}
�
Composição
public class Employee { 
private TimeCard tc[]; 
public void maintainTimeCard() { 
... 
} 
}
Generalização
public abstract class Employee { } 
public class Professor extends Employee { }
Realização
public interface CollegePerson { } 
public class Professor implements CollegePerson { }
Um exemplo completo
�
Diagrama de Objetos
Diagrama de Objetos correspondente ao Diagrama de Classes do exercício 1.
Abbott`s Rules
As regras abaixo são heurísticas bastante simples que podem ser empregadas para modelagem de aplicações OO à partir dos discursos que a descrevem. 
Parte do discurso		Componente do modelo			Exemplos
Substantivos próprios		Objeto						Anna, Shell
Substantivos comuns		Classe						Aluno, Empresa, Funcionário
Verbos com sentido de
	Fazer			Operação					Cria, submete, seleciona
	Ser			Generalização					É um tipo de, é outro, é um
	Ter			Agregação					Tem, consiste de, inclui
	Obrigação		“Constraints”					Deve, precisaAdjetivo, adjetivados		Atributo					Descrição do incidente, nota do aluno, custo da ação			 		
Boas práticas
Tenha foco na estrutura do sistema.
Foque em um aspecto estrutural do sistema, empregando mais de um diagrama se for necessário descrever mais que um aspecto.
Empregue somente elementos que são essenciais para descrever um aspecto.
	Isto é especifique somente os aspectos que você deseja que sejam garantidos na aplicação.
Empregue nomes que comuniquem seu propósito.
Tente não mostrar muitos relacionamentos. Em geral existem relacionamentos predominantes. 
Exercícios
1. Considere o diagrama de classes acima. Codifique as respectivas classes Java.
 public class TreeMap {
 TreeMapNode topNode = null;
 public void add(Comparable key, Object value) {…}
 public Object get(Comparable key) {…}
}
class TreeMapNode {
 private Comparable itsKey;
 private Object itsValue;
 private TreeMapNode nodes[] = new TreeMapNode[2];
 public TreeMapNode(Comparable key, Object value) {…}
 public Object find(Comparable key) {…}
 public void add(Comparable key, Object value) {…}
}
2. Além dos compartimentos para nome, atributos e operações, existe ainda um quarto compartimento para a representação de classes. Justifique.
O quarto compartimento é empregado para descrevermos a responsabilidade da classe. 
UML, Diagramas de Interação
São diagramas que descrevem o comportamento de um sistema, seu comportamento ” inter-classes”. São de dois tipos: os diagramas de sequência que privilegiam a ordem cronológica em que ocorrem as mensagens e eventos do sistema; e os diagramas de colaboração, que privilegiam a representação da estrutura de classes que colaboram na execução de um dada tarefa (responsabilidade).
Diagramas de Seqüência
�
Diagramas de Colaboração
�
Exercícios
1. Converta o diagrama Sequência dado acima para um diagrama de Colaboração.
2. Converta o diagrama Colaboração dado acima para um diagrama de Sequência. 
UML, Diagramas de Estado
São diagramas que descrevem o comportamento de um sistema do ponto de vista ” intra-classes”. Os diagramas de estado também podem ser empregados para representar estados mais genéricos e mais abstratos do sistema como “em produção” ou “em análise”.
�
Exercícios
1. Elabore um diagrama de estados que represente um controlador de temperatura. Acima (abaixo) de uma determinada temperatura o sistema passa a esfriar (esquentar). O sistema também possui uma temperatura limite (mais alto e mais baixo) à partir do qual o sistema alarma e deixa de operar. 
2. Cite aspectos que diferenciam um DFD de um diagrama de estados. 
UML, Diagramas de Atividades, Pacotes e Componentes
package BusinessObjects; 
public class Employee { 
Dependência de pacotes
package A; 
import B.*; 
public class SomeAClass { 
private ClassInB b; 
}
Booch, G., Rumbaugh, J., Jacobson, I. The Unified Modeling Language User Guide, Addison-Wesley, 1999.
Knoernschild, K. Java™ Design: Objects, UML, and Process, Addison-Wesley, 2001.
Bruegge, B., Dutoit, A.H. Object-Oriented Software Engineering: Conquering Complex and Changing Systems, Prentice-Hall, 2000.
 
� EMBED Unknown ���
� EMBED PBrush ���
� EMBED Unknown ���
� EMBED PBrush ���
_1237234842/r&�
_1237234927/Þù�
_1237234999/ÒÀ�
_1237234239.vsd
_1237234369.vsd