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çãoNotas

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
sequent
ial
concurr
ent
(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.

:TreeMap topNode

:TreeMapNode

- itsKey = "Martin"

nodes[LESS] nodes[GREATER]

:TreeMapNode :TreeMapNode

- itsKey = "Bob" - itsKey = "Robin"

nodes[LESS] nodes[GREATER] nodes[LESS] nodes[GREATER]

:TreeMapNode :TreeMapNode :TreeMapNode :TreeMapNode

- itsKey = "Alan" - itsKey = "Don" - itsKey = "Paul" - itsKey = "Sam"

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, precisa
Adjetivo, 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
2 nodes

TreeMap TreeMapNode
topNode
+ add(key, value) + add(key, value)
+ get(key) + find(key)

itsKey «interface»
Comparable

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