1. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UMLUML - Linguagem de
Modelagem Unificada
Autor: Rildo F. Santos (rildosan@uol.com.br)

2. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
2
Conteúdo
Parte 1:
- Introdução a Orientação a Objeto
Parte 2:
- Introdução a UML
Parte 3:
- Diagramas da UML
Parte 4:
- Estudo de Caso
- Exercício
Apêndices:
- Notação UML
- UML 2.0

3. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
3
Palavra inicial
A UML é padrão de mercado (www.omg.org/uml) que representa as
melhores práticas da engenharia de software em modelagem de
software;
A UML permite que desenvolvedores visualizem o software através
modelos e de um conjunto de diagramas;
A modelagem visual facilita o entendimento e a comunicação do 'quê'
precisa ser feito e 'como' deve ser feito o software;
Os diagramas oferecem a padronização, que é necessária quando
trabalhamos com grandes equipes de desenvolvedores ou com
fornecedores;
Neste treinamento apresentaremos todos os diagramas, elementos e
a semântica da Linguagem de Modelagem Unificada;
O treinamento:
Começa sendo demonstrado uma introdução a orientação a objetos
com objetivo de fazer um alinhamento de conhecimento da Orientação
a Objetos.
Depois é apresentado a UML, semântica e todos os diagramas (da
versão 1.5)
Também será exibido em estudo de caso com propósito de mostrar
como é feito a modelagem visual de software com UML.
Será utilizada uma ferramenta de modelagem visual para ajudar o
aprendizado da UML.

4. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
4
Introdução a Orientação
a Objetos
Objetivo desta parte:
É apresentar e discutir uma
introdução a Linguagem de
Modelagem Unificada versão 1.5.

5. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
5
Orientado a Objetos
Introdução a Orientação a Objetos
Os sistemas projetados atualmente são maiores, mais complexos e sujeitos a constantes
alterações e adaptações aos diversos ambientes computacionais. Através do
encapsulamento de informações, a reutilização de esforços empregados em projetos
anteriores e a modificação do sistema se tornaram mais fáceis.
Orientação a Objetos:
Um problema sempre define ou está contido em um domínio (sujeito a leis da física, da
matemática, do direito, do mercado financeiro e por ai a fora).
Assim a primeira resposta a buscar no desenvolvimento de um sistema em computação é
a construção de um modelo que coloque em termos de algoritmos o domínio da
aplicação. Pensando num modelo de objetos, numa abordagem de alto nível de abstração
há três fases:
Projeto e Modelagem UML
Implementação Linguagem Java
Metodologia
Análise
Orientação a Objetos
Análise: Discute
o porque, o que
(com quais informações
e para quais serviços) se
deve fazer
Projeto: O Como fazer, de
forma a ficar manutenível;
O mapeamento em
linguagem processável
pelo computador

6. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
6
O Método Orientação a Objetos
A metodologia Orientação a Objetos é baseada em noções, consideradas intuitivas ao
ser humano, tais como: objetos e atributos, classes e membros, estruturas e
componentes, ação e reação.
Os métodos de desenvolvimento de software anteriores ao surgimento desse paradigma
organizam a especificação de um sistema de acordo com suas funções ou com os
dados manipulados. Geralmente, esses métodos apresentam dificuldades na transição
da representação do sistema em uma fase para outra do processo de desenvolvimento
(da Análise para o Projeto e, do Projeto para a Implementação).
Em um sistema orientado a objetos, os dados e todas as operações (funções), que
manipulam esses dados, são agrupados em uma única estrutura: os objetos. Desde o
início do desenvolvimento desses sistemas e, em todas as suas fases, o analista
trabalha com o mesmo elemento de abstração, os objetos.
Introdução a Orientação a Objetos
Orientado a Objetos

7. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
7
As classes são as partes mais importantes de qualquer sistema orientada a objetos.
Usamos as classes para capturar o vocabulário do sistema que está em
desenvolvimento. Essas classes podem incluir abstrações que são parte do domínio do
problema, assim como as classes que fazem uma implementação. Podemos usar ainda
as classes para representar itens de software, de hardware e até itens que sejam
somente conceituais.
Exemplo:
A classe Pessoa deverá ter atributos e métodos comuns
Pessoa
Nome
Idade
GetNome
GetIdade
Nome da Classe
Atributos
Métodos
Os nome deverão ser identificadores únicos em conjunto de classes, este devem ser
substantivos. Exemplo: Produto.
Tipos de Classes:
• Classe Concreta
• Classe Abstrata
O que é uma Classes?
“Uma classe descreve um conjunto de objetos com propriedades e comportamentos
semelhantes e com relacionamentos comuns com outros objetos”
Classe
Orientado a Objetos

8. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
8
Exemplo:
A classe Pessoa. Classe concreta.
public class Pessoa {
//Atributos
private String nome;
private int idade;
//métodos
public String getNome(){
return nome; }
public void setNome(String
nome){
this.nome = nome; }
public int getIdade(){
return idade; }
public void setIdade(int
idade){
this.idade = idade; }
}
Classe Concreta:
Uma classe que tem assinatura e a implementação de métodos.
Exemplo de diagrama de classe
usando Rational Rose (notação Unified)
Classe
Orientado a Objetos

9. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
9
Exemplos de Objetos:
O que são Objetos ?
São qualquer coisa na natureza que possua propriedades (características) e
comportamentos (operações).
Exemplo: uma pessoa, uma cão e etc
Orientação a Objetos:
O termo orientação a objetos significa organizar o mundo real como uma coleção de
objetos que incorporam estrutura de dados e um conjunto de operações que
manipulam estes dados.
Estrutura de um objeto
Objetos combinam propriedades (atributos) e comportamentos (operações ou
métodos).
Propriedades Comportamentos
Bonita
Jovem
Inteligente
Andar
Correr
Falar
Chorar
Dançar
Objeto: Pessoa
Objetos
Orientado a Objetos

10. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
10
public class CalculaData {
private int day, month, year;
public float calcDays(int age )
{
return 365.25F * age;
}
}
Métodos
método
Métodos são os comportamentos ou as funções do objeto. A declaração é feita da
seguinte forma:
< modificador > < tipo de retorno > < nome > ( < lista de argumentos > )
< bloco >
< modificador > -> segmento que possui os diferentes tipos de modificações
incluíndo public, protected, private e default (neste caso não precisamos declarar o
modificador).
< tipo de retorno > -> indica o tipo de retorno do método.
< nome > -> nome que identifica o método.
< lista de argumentos > -> todos os valores que serão passados como
argumentos.
Exemplos: public void somaDias (int dias) { }
private int somaMes(int mês) { }
protected String getNome() { }
int getAge(double id) { }
Orientado a Objetos

11. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
11
public class Disciplina {
private int cargaHoraria;
private String nome;
public Disciplina(String nome, int
cargaHoraria){
this.nome = nome;
this.cargaHoraria =
calcCargaHoraria(cargaHoraria);
}
public String getNome(){
return nome;
}
public int getCargaHoraria(){
return cargaHoraria;
}
public int calcCargaHoraria(int
qdeHoras) {
int horasPlanejamento = (int)
( qdeHoras * 0.1);
return cargaHoraria =
horasPlanejamento + qdeHoras;
}
}
Atributos
Variáveis
temporárias
Atributos e variáveis (Linguagem Java)
Os atributos são pertencentes a classe, eles podem ser do tipo primitivo ou
referência (objetos), os seus modificadores podem ser: public, private, protected
ou default.
O ciclo de vida destes atributos estão vinculados ao ciclo de vida da classe.
Variáveis Locais:
São definidas dentro dos métodos. Elas têm o ciclo de vida vinculado ao ciclo do
método, também são chamadas de variáveis temporárias
Modificador
Orientado a Objetos

12. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
12
O que é abstração?
Podemos dizer abstração é generalização.
Qual é a função da abstração ?
A função da abstração é capturar as propriedades e os comportamentos essenciais,
como se fosse uma fatoração, desta forma determina-se o que é importante e o que
não é.
Aeronave
Caça Helicóptero Passageiros
Mamífero
Vaca Urso Cavalo
Para discutirmos sobre classes abstratas é necessário falarmos sobre a abstração de
dados.
As classes Aeronave e Mamífero neste caso são abstratas e ambas representam um
domínio.
Abstração de Dados:
Orientado a Objetos

13. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
13
Uma operação abstrata só determina a existência de um comportamento não definindo
uma implementação. Classes Abstratas - Exemplo:
Classes Abstratas
Uma classe abstrata é uma classe que:
• Provê organização
• Não possui “instances”
• Possui uma ou mais operações (métodos) abstratas
Pessoa
Pessoa
Física
Pessoa
Jurídica
getNome()
getNome() getNome()
Classe Abstrata
Funcionário
Analista Programador
Classe concreta
Classe concreta
Classe Abstrata
Abstração de Dados:
Orientado a Objetos

14. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
14
Um relacionamento é a conexão entre itens. É representado graficamente como um
caminho, que tem tipos diferentes de linhas para distinguir os tipos de
relacionamentos.
Ao construir as abstrações, descobrimos que são poucas as classes que trabalham
sozinhas. Em vez disso, a maioria das classes colaboram com outras classes de várias
maneiras.
Portanto, quando estamos modelando, devemos identificar as classes, atributos, métodos e
relacionamentos.
Existem alguns tipos principais de relacionamentos entre classes e objetos:
• Herança
• Agregação
Veja a definição de relacionamento:
Exemplo: Hierarquia de Classes
Pessoa
Aluno Funcionário
Professor
Pessoal
Administrativo
Terceiro
Professor
Autônomo
Pessoal
Operacional
SubClasses
SuperClasse
Relacionamento:
1 - Pessoa é a SuperClasse de Terceiro, Aluno e de Funcionário,
estas são subclasse de Pessoa.
2 - Terceiro e Funcionário são SuperClasse de Professor e Pessoal Administrativo e de
Professor Autônomo e Pessoal Operacional respectivamente.
E estas são subclasse de Terceiro e Funcionário.
Relacionamento
Orientado a Objetos

15. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
15
Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e
comportamento de elementos mais gerais,
Uma classe derivada herda a estrutura de dados e métodos de sua
classe “base”, mas pode seletivamente:
• adicionar novos métodos
• estender a estrutura de dados
• redefinir a implementação de métodos já existentes
Uma classe “pai” proporciona a funcionalidade que é comum a todas as suas classes
derivadas, filhas, enquanto que uma classe derivada proporciona a funcionalidade
adicional que especializa seu comportamento.
Exemplo:
Graduação Pós-Graduação
Curso
Universitário
Especialização Extensão
Hierarquia de Classes
Podemos dizer que Graduação é tipo de Curso Universitário, assim como Curso de
Especialização ou de Extensão.
extends
extends
Herança
Orientado a Objetos

16. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
16
Exemplo: Implementação- Pessoa, Aluno, Terceiro, Funcionário
public abstract class Pessoa {
protected String idPessoa;
protected int idade;
protected String nome;
public Pessoa(String nome)
{
this.nome = nome;
}
public abstract String getNome();
public void setidPessoa()
{ }
public abstract int getIdade();
public void setIdade(int idade)
{ }
}
public class Terceiro extends Pessoa{
private int codigoTerceiro;
public Terceiro(String nome)
{
super(nome);
}
public int getIdade()
{
return 0;
}
public String getNome()
{
return "";
};
}
public class Funcionario extends Pessoa{
private int codigofuncionario;
public Funcionario(String nome)
{
super(nome);
}
public int getIdade()
{
return 0;
}
public String getNome()
{
return "";
};
}
Professor
Autônomo
Pessoal
Operacional
Professor
Pessoal
Administrativo
Herança
public class Aluno extends Pessoa{
public Aluno(String nome)
{
super(nome);
}
public int getIdade()
{
return 0;
}
public String getNome()
{
return "";
};
}
Orientado a Objetos

17. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
17
Pessoa
AlunoTerceiro
public class ProfessorAutonomo
extends Terceiro{
public ProfessorAutonomo(
String nome)
{
super(nome);
}
}
public class PessoalOperacional
extends Terceiro{
public PessoalOperacional(
String nome)
{
super(nome);
}
}
public class Professor
extends Funcionario{
public Professor(
String nome)
{
super(nome);
}
}
public class PessoalAdministrativo
extends Funcionario{
public PessoalAdministrativo(
String nome)
{
super(nome);
}
}
Funcionário
Exemplo de Herança: Implementação: ProfessorAutonomo, PessoalOperacional,
Professor e Pessoal Administrativo
Herança
Orientado a Objetos

18. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
18
A herança múltipla é quando uma classe tem mais que uma Superclasse associada e
que herde as características de todas elas. Veja a figura abaixo:
Pessoa
Pessoa JurídicaPessoa Física
<<interface>>
Mamífero
Relacionamento:
Pessoa Física é tipo de pessoa, mas também é mamífero.
Na linguagem Java:
A Herança múltipla é somente permitida por contrato, neste caso a Mamífero é uma
Interface, podemos dizer que é tipo especial de classe, que não pode
ter métodos implementados, apenas as assinaturas.
Herança Múltipla
<<interface>>
Mamífero
Interface:
O que é interface ?
Interface é um contrato entre o cliente, que pode ser classe concreta ou abstrata, e a
interface. Este contrato é garantia que o métodos assinados na interface serão
implementados na classe cliente.
Nota: Na interface também podemos declarar constantes (public static final).
interface Product
{
String getName ();
double getCost ();
}
Superclasse
Superclasse
Exemplo de Interface
Orientado a Objetos

19. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
19
Exemplo: Implementação da classe Pessoa, PessoaFisica e PessoaJuridica e a
interface Mamifero
public abstract class Pessoa {
protected String idPessoa;
protected int idade;
protected String nome;
public Pessoa(String nome)
{
this.nome = nome;
}
public abstract String getNome();
public abstract int getIdade();
public void setIdade(int idade){ }
}
public class PessoaJuridica1 extends Pessoa
{
public PessoaJuridica1(String nome)
{
super(nome);
}
public int getIdade()
{
return 0;
}
public String getNome()
{
return "";
};
}
public interface Mamifero {
final int qdeOlhos=2;
public int getQdePernas();
}
public class PessoaFisica1 extends Pessoa
implements Mamifero {
public PessoaFisica (String nome)
{
super(nome);
}
public int getQdePernas(){
return 2; }
public String getNome(){
return “”; }
public int getIdade(){
return 0; }
}
Exercício:
1 - Podemos implementar a herança múltipla na Classe Pessoa? Por que ?
2 - Por que somos obrigado a assinar ou implementar os métodos da Interface Mamifero
na classe PessoaFisica
Herança Múltipla
implements
extends
extends
Orientado a Objetos

20. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
20
É uma proteção adicional dos dados do objeto de possíveis modificações impróprias,
forçando o acesso a um nível mais baixo para tratamento do dados.
Operações/métodos/interface
pública
Dados/Atributos/propriedades
privada
Encapsulamento (“data hiding”)
Encapsulamento é definido como uma técnica para minimizar dependências entre
“módulos” através da definição de interfaces externas. Também conhecido como:
O fenômeno da “caixa preta”
Encapsulamento
public class Empregado {
private double salario;
public Empregado(){
salario=0.00;
}
public double getSalario(){
return this.salario;
}
}
O atributo salario somente poderá ter
um valor atribuído ou alterado,
através de método público.
Através do método getSalario, que
tem modificador public, podemos
manipular ou recuperar o valor do
atributo salario.
Classe Empregado e método
getSalario
O atributo salario
private double salario;
Orientado a Objetos

21. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
21
A interface (pública) de um objeto declara todas as operações permitidas (métodos)
Todo o acesso aos dados do objeto é feito através da chamada a uma operação (método)
da sua interface.
Encapsulamento - Benefícios
- Segurança:
Protege os atributos dos objetos de terem seus valores corrompidos por outros
objetos.
- Independência:
“Escondendo” seus atributos, um objeto protege outros objetos de complicações de
dependência de sua estrutura interna
Encapsulamento
public class Gerente1 extends Empregado {
private double bonus = .15;
public double getSalario(){
//referência ao método getSalario
return super.getSalario() +
(super.getSalario()*this.bonus);
}
}
public class Empregado {
private double salario;
public Empregado(){
salario=0.00;
}
public double getSalario(){
return this.salario;
}
}
private double salario;
Orientado a Objetos

22. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
22
Definição:
“Polimorfismo” é uma operação que pode assumir múltiplas formas, a propriedade
segundo o qual uma operação pode comportar-se diferentemente em classes diferentes”
(Rumbaugh)
O polimorfismo é o responsável pela extensibilidade em programação orientada a objetos.
Polimorfismo
overloading
overriding
Overloading:
Possibilidade de reúso do nome do método para diferentes implementações, em tempo de
execução, a aplicação, escolherá o método adequado para cada chamada, veja o
exemplo.
TesteSoma Soma
somar(int a, int b)
somar(float a, float b)
somar(char a, char b)
somar(long a, long b))
Para cada tipo de dados existe um método, o reúso do nome do método é permitido,
entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o método
somar é definido várias vezes, entretanto com a lista de argumentos diferente, desta
forma evitaremos problemas como ambigüidade.
Polimorfismo
Orientado a Objetos

23. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
23
public class EmpregadoExemplo {
private double salario;
public void setSalario(int diastrabalhados,
double valorhora ){
this.salario = diastrabalhados *
valorhora * 8;
}
public double getSalario(){
return this.salario;
}
}
public class Engenheiro extends
EmpregadoExemplo {
public static void main(String args[])
{
Engenheiro eng = new Engenheiro();
eng.setSalario(22, 35.00);
System.out.println(eng.getSalario());
}
}
O método setSalario é herdado da Superclasse (Empregado), entretanto para cada cargo
(tipo de empregado) ele tem uma implementação diferente. Por exemplo:
- Para Engenheiro e Secretária salário = (Dias Trabalhados x Valor hora)
- Para Gerente salário = (Dias Trabalhados x Valor hora) + Bônus
- Para Diretor salário = (Dias Trabalhados x Valor hora) + Bônus + Participação nos
lucros.
Overrinding - Exemplo:
Empregado
setSalario()
getSalario()
Engenheiro
getSalario()
Gerente
getSalario()
Diretor
getSalario()
Secretária
getSalario()
Polimorfismo
Orientado a Objetos

24. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
24
Overrinding
Uma subclasse pode mudar o comportamento herdado da Superclasse, ou seja, um método
herdado poderá ser alterado. Veja o exemplo abaixo:
O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada
tipo de Conta ele tem uma implementação diferente. Por exemplo:
- Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo
anterior) - saques
Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros)
- saques
Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior
+ juros) - resgates - ir
Conta Bancária
getSaldo()
Conta Corrente
getSaldo()
Conta Poupança
getSaldo()
Investimentos
getSaldo()
Exercício:
Faça a implementação das classes acima.
Polimorfismo
Orientado a Objetos

25. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
25
Introdução a UML

26. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
26
Visão
de
Projeto
Funcionalidade
Vocabulário
Visão da
Implementação
Codificação
Montagem
Visão do
Processo
Desempenho
Escalabilidade
Throughput
Visão da
Implantação
Topologia do Sistema
Distribuição
Instalação
Conceitual Físico
Visão de
Caso de
Uso
Visão 4 + 1
Introdução a UML

27. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
27
• A visão do caso de uso abrange os casos de usos que descrevem o
comportamento do sistema conforme é visto pelos seus usuários
finais, analista e pessoal de teste. Essa visão não especifica realmente
a organização do sistema de softwasre. Porém , ela existe para
especificar as forças que determinam a forma da arquitetura do
Sistema. Com a UML, os aspectos estáticos dessa visão são
representados em diagramas de caso de uso, enquanto os aspectos
dinâmicos são representados em diagrama de interação., diagrama de
gráfico de estados e diagrama de atividades
• A visão de projeto de um sistema abrange as classes e colaborações
que formam o vocabulário do problema e de sua solução. Essa
perpectiva proporciona principalmente um suporte para os requisitos
funcionais do sistema, ou seja, os serviços que o sistema deverá
fornecer a seus usuários finais.
Com a UML, os aspectos estáticos dessa visão são captados em
diagramas de classes e de objetos; os aspectos dinâmicos são
captados em diagramas de interações, de estados e de atividades.
Visão de Caso
de Uso
Visão de Processo
Introdução a UML
Visão 4 + 1

28. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
28
• A visão do processo abrange os threads e os processos que formam
os mecanismos de concorrência e de sincronização do sistema. Essa
visão tem com objetivo principal tratar questões de desempenho, à
escalabilidade e ao throughput do sistema. Com a UML, os aspectos
estáticos e dinâmicos dessa visão são capturados nos mesmos tipos
de diagrama da visão do projeto, mas o foco voltado para as classes
ativas que repesentam esses threads e processos.
Threads = Linhas de execução em paralelos, estas linhs podem ser programas ou parte.
• A visão de implementação de um sistema abrange os componentes e
os arquivos utilizados para a montagem e fornecimento do sistema
físico. Essa visão envolve principalmente o gerenciamento da
configuração das versões do sistema, compostas por componentes e
arquivos de alguma maneira independentes, que podem ser reunidos
de diferentes formas para a produção de um sistema executável.
Visão de Implementação
Visão de Processo
Introdução a UML
Visão 4 + 1

29. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
29
• A visão do implantação de um sistema abrange os nós que formam a
topologia de hardware em que o sistema é executado. Essa visão
direciona principalmente a distribuição, o fornecimento e a instalação
das partes que constituem o sistema físico. Com a UML, os aspectos
estáticos dessa visão são representados em diagrmas de implantação;
os aspectos dinâmicos são capturados em diagramas de interações,
de gráfico de estados e diagramas de atividades.
Visão de Implantação
Cada uma dessas visões pode ser considerada isoladamente, permitindo
que diferentes participantes orientem seu foco para os aspectos da
arquitetura do sistema que mais lhes interessem. Essas cincos visões
também interagem entre sí, por exemplo:
Os nós na visão de implantação contêm componentes da visão de
implementação que, por sua vez, representa a realização física de classes,
interfaces, colaborações e classes ativas provenientes das visões de projeto
e de processo.
Introdução a UML
Visão 4 + 1

30. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
30
Desenvolvimento de Software
Estrutura:
Casos de Uso
Seqüência
(eventos)
Colaboração
Classes
Distribuição
Implementação
Estrutura
Comportamento
interno
Comportamento
externo
Análise de
Requisitos
Introdução a UML

31. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
31
Produtos dos Workflows de Requisitos e de Análise:
Documento de Visão
Especificação de Requisitos (Casos de Uso)
Vocabulário do Sistema
Modelo Conceitual ou Modelo de Domínio
Análise
Requisitos
Arquitetura Modelo de Arquitetura Inicial
Introdução a UML

32. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
32
Produtos dos Workflows de Projeto
Projeto
Diagrama de Seqüência / Colaboração
Diagrama de Classes (Refinado)
Diagrama de Atividades*
Diagrama de Estados*
* se necessário
Introdução a UML

33. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
33
Produtos dos Workflows de Arquitetura
Arquitetura
* se necessário
Diagrama de Componentes
Diagrama de Distribuição(Deployment)
Modelo de Arquitetura
Introdução a UML

34. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
34
Por que fazer a modelagem?
“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)
Com a modelagem, alcançamos alguns objetivos:
1 - Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja
2 - Os modelos permitem especificar a estrutura ou o comportamento de um sistema
3 - Os modelos proporcionam um guia para a construção do sistema
4 - Os modelos documenta o sistema
O Que é Modelagem Visual?
Modelagem Visual significa modelar com a utilização de notações padrão.
Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada.
UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das
mais populares do momento. Mas podemos optar por usar OMT, por exemplo.
Construímos modelos para compreender melhor que estamos desenvolvendo
Introdução a UML

35. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
35
Modelagem visual significa modelar com a utilização de notações
padrão. Precisamos adotar uma ferramenta, uma notação e
linguagem para tal empreitada. UML (Linguagem de Modelagem
Unificada) é a linguagem de modelagem é das mais populares do
momento.
A UML (Linguagem de Modelagem
Unificado) é padrão mantido pelo
OMG (www.omg.org/uml).
O Que é Modelagem Visual?
Introdução a UML

36. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
36
O Quê é a UML?
A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão
para elaboração da estrutura de projetos de software. A UML poderá ser
usada para:
• Visualização
• Especificação
• Construção de modelos e diagramas
• Documentação.
A UML é adequada para a modelagem de sistemas, cuja a abrangência
poderá incluir sistemas de informação corporativos a serem distribuídos a
Aplicação baseadas em Web e até sistemas complexos embutidos de
tempo real.
A UML é apenas uma linguagem e, portanto, é somente uma parte de um
método para desenvolvimento de software. Ela é independente do
processo, apesar de ser perfeitamente utilizada em processo orientado a
casos de usos, centrado na arquitetura, iterativo e incremental.
Introdução a UML

37. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
37
ESTÁTICOS
. Diagrama de Classes
. Diagrama de Objetos
. Diagrama de Componentes
. Diagrama de Distribuição
DINÂMICOS
. Diagrama de Casos de Uso
. Diagramas de Interação
- Diagrama de Seqüência
- Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados
Modela o comportamento
do sistema
Modela a estrutura
do sistema
Diagramas*
Introdução a UML
Nota: diagramas da versão 1.5

38. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
38
O Quê é a UML?
A UML é linguagem para documentação
A construção de software produz todos os tipos de artefatos além do código executável.
Estes artefatos incluem o seguinte:
- Requisitos
- Arquitetura
- Projeto
- Código-Fonte
- Planos de Projeto
- Teste
- Protótipos
- Versões
A UML abrange a documentação da arquitetura do sistema e de todos os seus detalhes.
A UML também proporciona uma linguagem para expressão de requisitos e para
realização de testes. Por fim, a UML oferece uma linguagem para modelagem das
atividades de planejamento do projeto e de gerenciamento de versões.
Onde a UML pode ser utilizada ?
A UML se destina principalmente a construção de software complexos. Atualmente
sendo empregada largamente na construção de Sites de E-commerce e E-business
Introdução a UML

39. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
39
O Quê é a UML?
Blocos de construção da UML
O Vocabulário da UML abrange três tipos de blocos de construção:
- Itens
- Relacionamentos
- Diagramas
- Itens,
Existem quatro tipos de itens na UML
Itens estruturais: São os substantivos utilizados em modelos da UML. São as partes
mais estáticas do modelo, representando elementos conceituais ou físicos.
Primeiro, as classes são descrições como conjuntos de objetos que compartilham os
mesmos atributos, operações, relacionamento e semântica.
Nome
Atributos
Métodos
Introdução a UML

40. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
40
O Quê é a UML?
Blocos de construção da UML
- Itens (continuação),
Segundo, uma interface é uma coleção de operações que especificam serviços de uma
classe ou componente. Portanto, uma interface descreve o comportamento
externamente visível desse elemento. Uma interface poderá representar todo o
comportamento de uma classe ou componente, como também apenas parte do
comportamento. A interface define um conjunto de especificações de operações
(assinaturas), mas nunca um conjunto de implementações de operações.
Calculo
Terceiro, as colaborações definem interação e são sociedades de papéis e outros
elementos que funcionam em conjunto para proporcionar um comportamento
cooperativo superior à soma de todos os elementos. Portanto, as colaborações contêm
dimensões estruturais, assim como comportamentais. As colaborações representam a
implementação de padrões que formam um sistema .
Cadeia de
Responsabilidade
Introdução a UML

41. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
41
O Quê é a UML?
Blocos de construção da UML
- Itens (continuação),
Quarto, um caso de uso é a descrição de conjunto de sequência de ações realizadas
pelo sistema que proporciona resultados observáveis de valor para um determinado
ator. Um caso de uso é utilizado para estruturar o comportamento de itens em um
modelo. Um caso de uso é realizado por uma colaboração.
Quinto, as classes ativas são classes cujos os objetos têm um mais processos ou
threads e, portanto, podem iniciar a atividade de controle. Uma classe ativa é
semelhante a um classe, exceto pelo fato de que seus objetos representam elementos
cujo o comportamento é concorrente com o outros elementos.
FazerPedido
start()
sleep()
ControlEvent
Introdução a UML

42. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
42
O Quê é a UML?
Blocos de construção da UML
- Itens (continuação),
Sexto, os componentes são partes físicas e substituíveis de um sistema, que
proporcionam a realização de um conjunto de interfaces.Tipicamente os componentes
representam, o pacote físico de elementos lógicos diferentes, como classes,
interfaces e colaborações.
Sétimo, um nó é elemento físico existente em tempo de execução que representa um
recurso computacional, geralmente com pelo menos alguma memória e,
frequentemente, capacidade de processamento. Exemplo de nós:
- Computadores (estações clientes e servidores)
- Redes
- Roteadores
Component.java
Servidor
Introdução a UML

43. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
43
O Quê é a UML?
Blocos de construção da UML
- Itens Comportamentais
São parte dinâmicas dos modelos de UML. São os verbos de um modelo, representado
comportamento no tempo e espaço. Ao todo, existem dois tipos de itens
comportamentais:
Primeiro, um interação é um comportamento que abrange um conjunto de mensagens
trocadas entre um conjunto de objetos em determinado contexto para realização de
propósitos específicos. As interações envolvem outros elementos, inclusive
mensagens, sequência de ações (os comportamentos chamados pelas mensagens) e
ligações (as conexões entre os objetos)
Mostrar
Segundo, uma máquina de estado é um comportamento que especifica as sequências
de estados pelas quais objetos ou interações passam durante sua existência em
resposta a eventos, bem como suas respostas a esses eventos. O comportamento de
classe ou de uma colaboração pode ser especificado por meio de uma máquina de
estados. Uma máquina de estados abrange mais elementos, tais como, transições (o
fluxo de um estado a outro evento), evento (itens que disparam uma transição) e
atividades (as respostas às transições).
Aguardando
Introdução a UML

44. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
44
O Quê é a UML?
Blocos de construção da UML
- Itens de Agrupamentos
Os itens de agrupamento são partes organizacionais dos modelos de UML. São os
blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo
principal de itens de agrupamento chamado de pacotes.
Um pacote é mecanismo de propósito geral para a organização de elementos em
grupos. Os itens estruturais, os itens comportamentais e até outros itens de grupos
podem ser colocados em pacotes. Ao contrário dos componentes (que existem em
tempo de execução), um pacote é puramente conceitual (o que significa que existe
apenas em tempo de desenvolvimento.
Aplicação
Interface de
Usuário
Controle
Regras de
Negócios
- Itens Anotacionais
Itens anotacionais são as partes explicativas dos modelos UML. São comentários,
incluídos para descrever, esclarecer e fazer alguma observação sobre qualquer
elemento do modelo. Existe apenas um item anotacional chamado nota
Imprimir
Recibo
Introdução a UML

45. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
45
O Quê é a UML?
Blocos de construção da UML
- Relacionamentos
Existem quatro tipos de relacionamentos na UML:
1 - Dependência
2 - Associação
3 - Generalização
4 - Realização
Esses relacionamentos são blocos relacionais básicos de construção da UML.
O primeiro dependência é um relacionamento semântico entre dois itens, nos quais a
alteração de um (o item independente) pode afetar a semântica do outro (o
dependente). Sua representa é linha tracejada, possivelmente com setas e
ocasionalmente incluindo um rótulo.
O segundo associação é um relacionamento estrutural que descreve um conjunto de
ligações, em que as ligações são conexões entre objetos. A agregação é um tipo
especial de associação, representando um relacionamento estrutural entre o todo e
suas partes. É representada por uma linha sólida, possivelmente direcionadas,
ocasionalmente incluído rótulos e freqüentemente, contendo outros adornos, como
nomes de papéis e multiplicidade.
Pessoa Empregador
empregador
0..1
*
funcionário
Introdução a UML

46. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
46
O Quê é a UML?
Blocos de construção da UML
O terceiro é a generalização é um relacionamento de especialização e generalização,
nos quais os objetos dos elementos especializados (os filhos) são substituíveis por
objetos do elemento generalizados (os pais). Dessa forma, os compartilham a estrutura
e comportamento dos pais.
Médico
Clinico Geral Pediatra
generalização
especialização
O quarto é a realização é um relacionamento semântico entre classificadores, em que
um classificador especifica um contrato que outro classificador garante executar.
Os relacionamentos de realização são encontrados em dois locais: entre interface
e as classes ou componentes que as realizam; entre casos de uso e as colaborações
que os realizam.
Place
order
Order
management
colaboração
Introdução a UML

47. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
47
O Quê é a UML?
Revisão
Blocos de construção da UML
O Vocabulário da UML abrange três tipos de blocos de construção:
- Itens
- Relacionamentos
- Diagramas
- Itens,
Existem quatro tipos de itens na UML
Itens estruturais: São os substantivos utilizados em modelos da UML. São as partes
mais estáticas do modelo, representando elementos conceituais ou físicos.
Primeiro, as classes são descrições como conjuntos de objetos que compartilham os
mesmos atributos, operações, relacionamento e semântica.
Segundo, uma interface é uma coleção de operações que especificam serviços de
uma classe ou componente.
Terceiro, as colaborações definem interação e são sociedades de papéis e outros
elementos que funcionam em conjunto para proporcionar um comportamento
cooperativo superior à soma de todos os elementos.
Quarto, um caso de uso é a descrição de conjunto de sequência de ações realizadas
pelo sistema que proporciona resultados observáveis de valor para um determinado
ator.
Quinto, as classes ativas são classes cujos os objetos têm um mais processos ou
threads e, portanto, podem iniciar a atividade de controle
Introdução a UML

48. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
48
O Quê é a UML?
Revisão
Sexto, os componentes são partes físicas e substituíveis de um sistema, que
proporcionam a realização de um conjunto de interfaces.
Sétimo, um nó é elemento físico existente em tempo de execução que representa um
recurso computacional
- Itens Comportamentais
São parte dinâmicas dos modelos de UML. São os verbos de um modelo, representado
comportamento no tempo e espaço. Ao todo, existem dois tipos de itens
comportamentais:
Primeiro, interação é um comportamento que abrange um conjunto de mensagens
trocadas entre um conjunto de objetos em determinado contexto para realização de
propósitos específicos.
Segundo, uma máquina de estado é um comportamento que especifica as sequências
de estados pelas quais objetos ou interações passam durante sua existência em
resposta a eventos, bem como suas respostas a esses eventos.
Introdução a UML

49. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
49
Diagramas da UML

50. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
50
Casos de Uso
O que são Caso de Uso?
São diagramas de que permitem visualizar, especificar e documentar o comportamento
de um elemento. Esses diagramas fazem com que sistema, subsistemas e classes
fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como
esses elementos podem ser utilizados no contexto.
Definição:
Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive
variantes, que um sistema pode produzir um resultado de valor observável por um ator.
A representação gráfica é uma elipse.
Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papéis que os usuários de casos de uso
desempenham quanto interagem com esses casos de uso. Geralmente um ator
representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo.
Cenários:
Podemos definir os cenários como uma instância de um Caso de uso. O caso de uso
deve ser descrito através de cenários. Devem ser construídos tantos cenários quantos
forem necessários para se entender completamente todo o sistema. Podem ser
considerados como teste informais para validação dos requisitos do sistema.
Introdução a UML

51. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
51
Diagramas de Caso de Uso e Extensões
Professor
Selecionar curso
para ensinar
Pedir lista dos
matriculados
Gerente
Manter informação de
aluno
Manter informação de
professor
Gerar catalogo
Manter informações dos
cursos
Sistema de
cobrança
Matrícula nos
Cursos
Aluno
Casos de Uso
Generalização:
Entre casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou
sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer
local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal,
entretanto, querendo fazer uma descrição mais controlada, explicando os pontos
de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso
Use (obsoleto): Especifica que a semântica do elemento de origem depende da
semântica da parte pública do destino
Introdução a UML

52. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
52
Descrição dos Cenários:
Nome AutenticarSenha
Descrição Autenticar Senha
Objetivo Identificar o usuário, autenticar senhas e autorizar acesso.
Atores Usuário
Papéis: Funcionário Administrativos, Alunos e Professores
Pré Condição Usuário cadastro no sistema senhas, Usuário não estar “logado”
Dados Entrada
e Saída
Entrada: Código do usuário e senha de acesso
Saída: Autorização para uso (Pasta de Acesso) ou uma mensagem de alerta
Sequência de troca mensagens
Ator Sistemas
1. Usuário chama uma interface Registro
2. Usuário informa seu código e sua senha.
3. Usuário requisita autenticação dos dados
informados.
8 Usuário recebe a mensagem, ou seja, a autorização
Pasta de Acesso, formatada de acordo sua interface.
4. Aplicativo processa a autenticação da senha, faz a
identificação do usuário. Verificar se usuário tem o
status de Liberado.
5. Conferir se senha não está expirada.
6. Conferir se senha informada coincide com a senha
gravada.
7. Retornar uma mensagem e uma assinatura.
Curso Alternativo (Exceção):
Ator Sistemas
4. Usuário com status de bloqueado. Retornar
mensagem de alerta/erro
5. Senha expirada. Retornar mensagem de alerta/erro
(O usuário deverá trocar a senha – ver case de uso
AlterarSenha)
6. Senha não confere. Retornar mensagem de
alerta/erro de senha inválida. Registrar a quantidade
de tentativas sem sucesso, caso seja igual a 5 (limite
de tentativas) o sistema bloqueará o usuário, mudando
o status de liberado para bloqueado automaticamente.
Pós Condição Autorização (Pasta de acesso)
Interfaces Registro
Casos de Uso
Introdução a UML

53. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
53
Descrição dos Cenários: Regras de Negócios
Casos de Uso
Regras de Negócios:
Autenticação: A senha será validada, seguindo as regras de negócios de Autenticação de
Senha:
1 - O usuário deve estar cadastrado no Aplicativo;
2 - A senha não pode estar expirada;
3 - O usuário deve ter um “status” de Liberado;
4 - A senha informada (criptografada) deve coincidir com senha gravada na tabela de
senhas. Autorização
5 - Somente o usuário detentor da senha poderá altera-lá
Introdução a UML

54. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
54
Ator
Casos de Uso - Identicação de Atores
Os atores não são parte do sistema - eles representam qualquer um e qualquer
coisa que faça interação com sistema. Podendo ser uma pessoa, software,
hardware e etc.
Uma ator pode:
- Apenas fornecer informações ao sistema
- Apenas receber informações ao sistema
- Fornecer e receber informações ao sistema
Tipicamente os atores são identificados nas declarações de problemas ou através de
entrevistas com os usuários e outros analistas envolvidos no processo, como, Analista de
Sistema e Analista de Negócio, por exemplo.
As seguintes questões podem ser usadas para identificar o atores:
- Onde o sistema será usado ?
- Quais áreas serão usuárias do sistema ?
- O sistema usará recurso externo ?
- Quem será o responsável pelo sistema ?
- Quem serão os usuários do sistema ?
Introdução a UML

55. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
55
Casos de Uso
Generalização:
Entre casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou
sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer
local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados,
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal,
entretanto, querendo fazer uma descrição mais controlada, explicando os pontos
de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso
Use (obsoleto): Especifica que a semântica do elemento de origem depende da
semântica da parte pública do destino
Diagramas da UML

56. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
56
Explicando o estereotipo <<extend>>
Extend: Podemos usa-los em dois momentos
1 Variação
Cada uma das extensões descreve as diferentes maneiras com que um
passo do caso de uso pode ser executado. Exemplo:
Casos de Uso
Dinheiro
ReceberConta
CartaoCredito Cheque
<<extend>><<extend>> <<extend>>
2 Casos excepcionais
Condições de falha que podem ocorrer e serem recuperada em único
passo e requerem um caso de uso para sua descrição.
AlterarDisponibilidadeCarro ConsultarCliente
<<include>>
DevolvendoCarro
CalcularMulta
<<extend>>
<<include>>
Diagramas da UML

57. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
57
Casos de Uso
PlaceOrder
<<include>>
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base
incorpora explicitamente o comportamento de outro caso de uso em uma localização
especificada na base. O caso de uso incluído nunca permanece isolado, mas é apenas
uma “instance” como parte de alguma base maior que o inclui. Você pode pensar na
inclusão como o caso de uso base que o obtém o comportamento a partir do fornecedor
do caso de uso.
Você utiliza um relacionamento de inclusão para evitar descrever o mesmo fluxo de
eventos várias vezes, incluindo o comportamento comum em um caso de uso próprio. O
relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta um
conjunto de responsabilidades do sistema e o captura um único local (o caso de uso
incluído); depois, permite que outras partes do sistema (outros casos de uso) incluam a
nova agregação de responsabilidade sempre que precisamos utilizar essa
funcionalidade.
Explicando o estereotipo <<include>>
TrackOrder
ValidateUser<<include>>
Diagramas da UML

58. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
58
Locadora de carros
Uma locadora aluga carros aos clientes previamente cadastrados. Caso o cliente
não esteja cadastrado, esta atividade custodial é realizada, separadamente em
outra atividade do sistema. Caso um carro, disponível, seja escolhido pelo cliente
este é alugado, sendo registrada a data inicial junto ao aluguel. Para que o
cliente possa alugar um carro, este não pode estar com dívida pendente.
Os carros são descritos pela placa, ano, modelo, descrição, km, preço por km,
situação(disponível, etc), taxa diária, observações(informações gerais) e sua
imagem. Os clientes são cadastrados pelo seu cpf, nome, endereço, telefone e
dívida(reservado para registrar pagamentos pendentes).
Quando o cliente devolve o carro, a situação do carro é mudada para
“disponível”, o km é atualizado com o km atual do carro e um recibo é emitido,
baseado nos kms rodados e nos dias em que ficou com o carro. Ainda na
atividade de devolução é removido o registro do aluguel e, caso o cliente não
possa pagar, a dívida do aluguel é registrada junto ao cliente.
Exemplo: Casos de Uso
Diagramas da UML

59. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
59
Objetivo:
Fazer locação de carros
Restrição:
Cliente não pode ter dividas pendentes
Atores:
Atendente
Entidade Custodial
Candidatos a Casos de Usos:
Cadastrar Cliente
Cadastrar Carro
VerificarDadosCliente
VerificarDividadoCliente
VerificarDisponibilidadeVeiculo
(Locar) EntregarVeiculo
(Devolução) ReceberVeículo
EmitirRecibo
RegistrarDivida
Candidatos a Classe:
Veículos
Clientes
Divida do Cliente
Locação
Empregado
Exemplo: Casos de Uso
Diagramas da UML

60. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
60
Continuação:
Atores:
Atendente: Faz o atendimento ao cliente da Locadora
Entidade Custodial: Faz o cadastro da custódia do cliente
Candidatos a Casos de Usos:
Cadastrar (Cliente e Carro)
VerificarDadosCliente (Se é cliente e se tem divida)
VerificarDisponibilidadeVeiculo
EntregarVeiculo
ReceberVeículo
EmitirRecibo
RegistrarDivida
Candidatos a Classe:
Veículo
DadosdoCliente
DividadoCliente
Locação
Empregado
Exemplo: Casos de Uso
Diagramas da UML

61. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
61
Diagrama de Caso de Uso
EntregarVeiculo
Verif icarDisponibilidadeVeiculo
<<include>>
Verif icarDadosCliente
<<include>>
SocilicarCadastro
EntidadeCustodia
<<extend>>
AlterarDisponibidadeVeiculo
ReceberVeiculo
<<include>>
ImprimirReciboRegistrarDiv ida
ReceberPagtoCliente
<<include>>
<<extend>>
<<extend>>
Atendente
Cadastrar CadastrarCliente
CadastrarCarro
Exemplo: Casos de Uso
Diagramas da UML

62. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
62
Cenário do Caso de Uso: VerificarDadosCliente
Casos de Uso
Nome: VerificarDadosCliente
Objetivo: Verificar se Cliente está cadastro no Sistema e e divida pendente
Pré-condição: Cliente solicitar uma locação
Ator: Atendente
Fluxo Normal:
1-O atendente solicita o número do CPF
2-Digita o CPF no sistema
3-O sistema verifica se cliente está cadastrado e se tem
divida pendente
4-O sistema envia mensagem cliente cadastrado e não
há divida
Fluxo Alternativo 1 (Cliente não cadastrado):
4-O sistema envia mensagem cliente não cadastrado
5-Solicita o cadastro da custódia do cliente
Fluxo Alternativo 2 (Cliente com divida):
4-O sistema envia mensagem cliente cadastrado e com
divida pendente
Diagramas da UML

63. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
63
Diagrama de Seqüência
O que é Diagramas de Seqüência?
É um diagrama que exibe a colaboração dinâmica entre os vários objetos de um sistema.
O principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de
mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, alguma
evento que acontecerá em um ponto específico da execução do sistema.
formulários
de registro
formulário
de matrícula
cursos
disponíveis
Ator (José) entrar com chave de
acesso
validar acesso
entrar com o
semestre
criar nova matrícula
apresentar em tela
obter cursos
Diagrama de Seqüência
Introdução a UML
Explicando o diagrama:
O diagrama de seqüência consiste em um número de objetos mostrado em
linhas verticais. O decorrer do tempo é visualizado observando-se o
diagrama no sentido vertical de cima para baixo. As mensagens enviadas
por cada objeto são simbolizadas por setas entre os objetos que se
relacionam.
Diagramas de seqüência possuem dois eixos: o eixo vertical, que mostra o
tempo e o eixo horizontal, que mostra os objetos envolvidos na seqüência de
uma certa atividade. Eles também mostram as interações para um cenário
específico de uma certa atividade do sistema.

64. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
64
Diagrama de Seqüência
Diagramas da UML
Diagrama de Seqüência
Explicando o diagrama (continuação)
No eixo horizontal estão os objetos envolvidos na seqüência. Cada um é
representado por um retângulo de objeto (similar ao diagrama de objetos)
e uma linha vertical pontilhada chamada de linha de vida do objeto,
indicando a execução do objeto durante a seqüência, como exemplo
citamos: mensagens recebidas ou enviadas e ativação de objetos. A
comunicação entre os objetos é representada como linha com setas
horizontais simbolizando as mensagens entre as linhas de vida dos
objetos. A seta especifica se a mensagem é síncrona, assíncrona ou
simples. As mensagens podem possuir também números seqüenciais,
eles são utilizados para tornar mais explícito as seqüência no diagrama.
Em alguns sistemas, objetos executam de forma concorrente, cada um
com sua linha de execução (thread). Se o sistema usa linhas concorrentes
de controle, isto é mostrado como ativação, mensagens assíncronas, ou
objetos assíncronos.
Os diagramas de seqüência podem mostrar objetos que são criados ou
destruídos como parte do cenário documentado pelo diagrama. Um objeto
pode criar outros objetos através de mensagens. A mensagem que cria ou
destrói um objeto é geralmente síncrona, representada por uma seta sólida

65. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
65
Diagrama de Seqüência
Exemplo: EntregarVeiculo
: Atendente
: Cliente : Veiculo : Locacao
getDadosCliente( )
[* se cliente cadastrado
verificar divida ]
getDivida( )
getDisponibilidade( )
[* se veículo
disponível ]
setSaida( )
Este diagrama descreve em ordem cronológica as mensagens entre os
objetos.
Neste momento estamos dizendo o como o Caso de Uso deve ser
implementado
Diagramas da UML

66. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
66
Diagrama de Seqüência
Explicando os detalhes:
: Atendente
: Cliente : Veiculo : Locacao
getDadosCliente( )
[* se cliente cadastrado
verificar divida ]
getDivida( )
getDisponibilidade( )
[* se veículo
disponível ]
setSaida( )
ator
Instance das classes
Linha do tempo
As interações entre os
objetos
Restrição ou
condição
Autodelegação
Diagramas da UML

67. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
67
Diagrama de Colaboração
O que é Diagramas de Colaboração?
É um diagramas que mostra a colaboração dinâmica entre os objetos,
semelhante ao diagrama de seqüência. No diagrama de colaboração, além
de mostrar a troca de mensagens entre os objetos, percebe-se também os
objetos com os seus relacionamentos. A interação de mensagens é mostrada
em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é
melhor escolher o diagrama de seqüência, mas se a ênfase for o contexto do
sistema, é melhor dar prioridade ao diagrama de colaboração. Podemos
também escolher ambos. O diagrama
de colaboração é desenhado como um diagrama de objeto, onde os diversos
objetos são mostrados juntamente com seus relacionamentos. As setas de
mensagens são desenhadas entre os objetos para mostrar o fluxo de
mensagens entre eles. As mensagens são nomeadas, que entre outras
coisas mostram a ordem em que as mensagens são enviadas. Também
podem mostrar condições, interações, valores de resposta, e etc. O diagrama
de colaboração também pode conter objetos ativos, que executam
paralelamente com outros.
6:obter cursos
Ator (José)
formulários de registro
2: validar acesso
1:entrar com chave
de acesso
3:entrar com o
semestre
4:criar nova matrícula
formulário de matrículacursos disponíveis
5:apresentar
em tela
Diagrama de Colaboração
Diagramas da UML
NOTA: O diagrama de colaboração em alguns caso pode ser considerado opcional. Pode-se escolher entre utilizar o diagrama de colaboração
ou o diagrama de seqüência.

68. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
68
Diagrama de Colaboração
: Atendente
: Cliente
: Veiculo :
Locacao
1: getDadosCliente( )
2: getDivida( )
3: getDisponibilidade( )
4: setSaida( )
Diagramas da UML

69. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
69
Diagrama de Estado
O que é Diagrama de Estado?
É um diagrama que tipicamente complementa a descrição das classes.
Pois este diagrama exibe todos os estados possíveis que objetos de uma
certa classe podem se encontrar e mostra também quais são os eventos do
sistemas que provocam tais mudanças.
Não necessário escrever o diagrama de estado para todas as classes de
um sistema, mas apenas para aquelas que possuem um número definido
de estados conhecidos e onde o comportamento das classes é afetado e
modificado pelos diferentes estados.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e
sistemas. Eles mostram os estados que um objeto pode possuir e como os
eventos (mensagens recebidas, tempo, erros, e condições sendo
satisfeitas) afetam estes estados ao passar do tempo.
Registro fechado
[númeroDeAlunos<3]
cancelarCurso
cancelarCurso
cancelarCurso
Registro fechado
[númeroDeAlunos>=3
]
Registro fechado [número
de alunos =10]^Curso
.Criar relatório
Matrícula aberta/inicialize
númeroDeAlunos = 0
Curso Completado
faça: Gerar lista de
alunos
Criação
faça: Crie o
objeto curso
Atribuição Curso
faça: Atribuir um
professor ao curso
Curso Aberto
Entrada: Registre
um aluno
Adicionar Aluno
Curso Encerrado
faça: relate curso
esta cheio
Curso Cancelado
faça: envie notificação
de cancelamento
cancelarCurso
Projeto e Modelagem Visual com UML

70. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
70
Diagrama de Estado
Projeto e Modelagem Visual com UML
Diagramas de estado possuem um ponto de início e vários pontos de
finalização. Um ponto de início (estado inicial) é mostrado como um círculo
todo preenchido, e um ponto de finalização (estado final) é mostrado como
um círculo em volta de um outro círculo menor preenchido. Um estado é
mostrado como um retângulo com cantos arredondados. Entre os estados
estão as transições, mostrados como uma linha com uma seta no final de
um dos estados. A transição pode ser nomeada com o seu evento
causador. Quando o evento acontece, a transição de um estado para outro
é executada ou disparada.
Uma transição de estado normalmente possui um evento ligado a ela. Se
um evento é anexado a uma transição, esta será executada quando o
evento ocorrer. Se uma transição não possuir um evento ligado a ela, a
mesma ocorrerá quando a ação interna do código do estado for executada
(se existir ações internas como entrar, sair, fazer ou outras ações definidas
pelo desenvolvedor). Então quando todas as ações forem executadas pelo
estado, a transição será disparada e serão iniciadas as atividades do
próximo estado no diagrama de estados.
Verificando
Estado Transição Fim Inicio
Elementos

71. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
71
Diagrama de Estado
Projeto e Modelagem Visual com UML
Exemplo: Diagrama de Estado Telefone
ocioso
início
Ativo
fora do gancho
no gancho
transição
Estado
Os diagramas de estados são compostos de transições e estados. As
transições são associadas com ações e são consideradas como processo
de curta duração e não podem ser interrompidos. Os estados são
associados com as atividades e podem levar mais tempo. Uma atividade
pode ser interrompida por algum evento.
Final

72. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
72
Diagrama de Estado
Projeto e Modelagem Visual com UML
Aplicação
Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:
- Classes
- Tipos (conceitos)
- Casos de Uso
Exemplo:
início
Verificando Expedindo
Aguardando
Cancelamento
cancelamento
Entregue
cancelado
[Todos os itens
verificados e
alguns itens não
estão disponíveis]
[Todos os itens verificados e
os todos itens disponíveis]
Item recebido
[os todos itens
disponíveis]
final
[Nem todos os itens verificados]/pegar
próximo item
[itens ecebidos
[alguns itens não
estão disponíveis]

73. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
73
Diagrama de Atividade
O que é Diagrama de Atividade?
É um diagramas que exibe o fluxo seqüencial das atividades, é geralmente utilizado para
demonstrar as atividades executadas por uma operação específica do sistema, como por
exemplo seleção de um item do menu principal. Consistem em estados de ação, que
contém a especificação de uma atividade a ser desempenhada por uma operação do
sistema. Decisões e condições, como execução paralela, também podem ser mostrados
na diagrama de atividade. O diagrama também pode conter especificações de
mensagens enviadas e recebidas como partes de ações executadas.
Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho
executado na implementação de uma operação (método), e suas atividades numa
instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado e
possui um propósito um pouco diferente do diagrama de estado, que é o de capturar
ações (trabalho e atividades que serão executados) e seus resultados em termos das
mudanças de estados dos objetos.
Projeto e Modelagem Visual com UML
Fazer Pedido
Cliente
Processar Pedido
Separar Produtos
Enviar Pedido
Cobrar Cliente
Fechar Pedido
Receber Pedido
Pagar Fatura
Vendas Estoque

74. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
74
Os estados no diagrama de atividade mudam para um próximo estágio quando uma
ação é executada (sem ser necessário especificar nenhum evento como no diagrama de
estado). Outra diferença entre o diagrama de atividade e o de estado é que podem ser
colocadas como swimlanes (raias). Uma swimlane agrupa atividades, com respeito a
quem é responsável e onde estas atividades residem na organização, e é representada
por retângulos que englobam todos os objetos que estão ligados a ela (swimlane).
Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a
possibilidade de expressar como as ações são executadas, o que elas fazem
(mudanças dos estados dos objetos), quando elas são executadas (seqüência das
ações), e onde elas acontecem (swimlanes).
Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:
 Para capturar os trabalhos que serão executados quando uma operação é
disparada (ações). Este é o uso mais comum para o diagrama de atividade.
 Para capturar o trabalho interno em um objeto.
 Para mostrar como um grupo de ações relacionadas podem ser executadas, e
como elas vão afetar os objetos em torno delas.
 Para mostrar como uma “instance” pode ser executada em termos de ações e
objetos.
 Para mostrar como um negócio funciona em termos de trabalhadores (atores),
fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no
negócio).
Enfim o diagrama de atividade mostra o fluxo seqüencial das atividades, é normalmente
utilizado para demonstrar as atividades executadas por uma operação específica do
sistema. Consistem em estados de ação, que contém a especificação de uma atividade
a ser desempenhada por uma operação do sistema. Decisões e condições, como
execução paralela, também podem ser mostrados na diagrama de atividade. O
diagrama também pode conter especificações de mensagens enviadas e recebidas
como partes de ações executadas.
Projeto e Modelagem Visual com UML
Diagrama de Atividade

75. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
75
Exemplo:
Diagrama de Atividades
Projeto e Modelagem Visual com UML
Diagrama de Atividade

76. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
76
Diagrama de Atividade
Componentes:
Projeto e Modelagem Visual com UML
Fazer Pedido
Cliente
Processar Pedido
Separar Produtos
Enviar Pedido
Cobrar Cliente
Fechar Pedido
Receber Pedido
Pagar Fatura
Vendas
Estoque
raias
junção
separação
atividade
Atividade
atividade transição decisão
Barras de
sincronização
Exemplo com comentários:

77. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
77
Diagrama de Atividade
Projeto e Modelagem Visual com UML
Exemplo com comentários:
Receber Pedido
Preencher Pedido
Receber Pagamento
Enviar Fatura
Entrega durante
a noite
Entrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega

78. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
78
Diagrama de Pacotes
Como podemos definir o diagrama de pacotes?
A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de
organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida
que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é
linha pontilhada com uma seta que indica dependência.
A notação usada pela UML para representar pacotes é:
Nome do Pacote
Exemplo: As classes pertencentes ao Sistema de Matrícula podem ser agrupadas em três
pacotes:
• UI (Interface Usuário)
• Regras de Negócio
• Interfaces de Banco de Dados
Interfaces de
Banco de Dados
{abstrata}
Interfaces com
Usuário
Regras de
Negócios
Interface
MySQL
Introdução a UML

79. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
79
Podemos usar a estrutura de pacotes para criar coesão entre as classes que tem objetivo
comum, por exemplo podemos colocar em único pacote todas as classes que se referem a
regras de negócios.
Exemplo:
Fisicamente os pacotes tem a estrutura de diretório e subdiretório, isto que dizer que
a Aplicação terá a seguinte formato:
Aplicação
Regras de Negócios
Interface de Usuário
Controle
Aplicação
Interface de Usuário
Controle
Regras de Negócios
Diagrama de Pacotes
Projeto e Modelagem Visual com UML

80. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
80
Diagrama de Classes
O que é um Diagrama de Classes?
É um diagrama que demonstra a estrutura estática das classes de um sistema e seus
relacionamentos. Classes podem se relacionar com outras através de diversas maneiras:
associação (conectadas entre si), dependência (uma classe depende ou usa outra classe),
especialização (uma classe é uma especialização de outra classe), ou em pacotes
(classes agrupadas por características similares). Todos estes relacionamentos são
mostrados no diagrama de classes juntamente com as suas estruturas internas, que são
os atributos e operações. O diagrama de classes é considerado estático já que a estrutura
descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. Um sistema
normalmente possui alguns diagramas de classes, já que não são todas as classes que
estão inseridas em um único diagrama e uma certa classes pode participar de vários
diagramas de classes.
1..*
1
1
tem
Professores
Pessoa
Alunos
Funcionários
Administrativo
Curso
Disciplinas
Matricula
11
1
Uma classe num diagrama pode ser diretamente implementada utilizando-se uma
linguagem de programação orientada a objetos que tenha suporte direto para
construção de classes. Para criar um diagrama de classes, as classes têm que estar
identificadas, descritas e relacionadas entre si.
Introdução a UML

81. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
81
Diagrama de Objetos
O que é um Diagrama de Objetos?
É um diagrama que exibe uma variação do diagrama de classes e utiliza quase a mesma
notação. A diferença é que o diagrama de objetos mostra os objetos que foram
“instanciados” das classes. O diagrama de objetos é como se fosse o perfil do sistema em
um determinado momento de sua execução. A mesma notação do diagrama de classes é
utilizada, entretanto há duas diferenças: os objetos são escritos com seus nomes
sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de
objetos não tem a mesma importância do diagramas de classes, mas eles são muito úteis
para exemplificar diagramas complexos de classes ajudando muito em sua compreensão.
Diagramas de objetos também são usados como parte dos diagramas de colaboração,
onde a colaboração dinâmica entre os objetos do sistema são mostrados.
Nome: “Fulano de Tal”
Data: 23-02-2001
:Aluno
Matricula: 201-23-02-01
Curso: Adm Empresas
201-23-02-01:Matricula
Introdução a UML

82. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
82
Diagrama de Classes
Diagramas da UML

83. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
83
Mapeamento do Diagrama de Classes e Modelo de Entidades e
Relacionamento
MER
Entidades
Relacionamentos
Atributos
Roles
Constraints
Generalização e
Especialização
UML
Classes Persistentes
Associação
Atributos
Roles
Multiplicidade
Generalização e
Especialização
Veja a tabela abaixo que relaciona as característica da UML e MER:
Pessoa
-idpessoa
-nome
Pessoa
Idpessoa <pk>
nome
Classe persistente Entidade
Os atributo de uma classe persistente são mapeado para colunas de entidade
Diagramas da UML

84. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
84
Mapeamento Diagrama de Classes e Modelo de Entidades e
Relacionamento
Um exemplo de mapeamento Diagrama de classe (UML) e entidade (MER)
Pessoa
-nome
-idade
Funcionário
funcao
{abstract}
Cliente
Idcliente
telefone
Classes
Veja agora o mapeamento para entidade MER, para cada classe criaremos uma
entidade correspondente:
Pessoa
idpessoa <pk>
nome
idade
Funcionário Cliente
é um
idpessoa <fk>
funcao
idpessoa <fk>
idcliente <pk>
telefone
é um
Diagramas da UML

85. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
85
Mapeamento Diagrama de Classes e Modelo de Entidades e
Relacionamento
Neste exemplo o mapeamento é feito para duas entidades:
Funcionário
idfunc <pk>
nome
idade
funcao
Cliente
idcliente <pk>
nome
idade
telefone
Diagramas da UML

86. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
86
Diagrama de Componente
O que é um Diagrama de Componente?
É um diagrama que exibe o sistema por um lado funcional, expondo as
relações entre seus componentes e a organização de seus módulos durante
sua execução.
O diagrama de componente descreve os componentes de software e suas
dependências entre si, representando a estrutura do código gerado. Os
componentes são a implementação na arquitetura física dos conceitos e da
funcionalidade definidos na arquitetura lógica (classes, objetos e seus
relacionamentos). Eles são tipicamente os arquivos implementados no
ambiente de desenvolvimento.
Curso.jar Pessoa.jar
Aluno.class Professores.classDisciplina.classr
Introdução a UML
Um componente é mostrado em UML como um retângulo com uma elipse e
dois retângulos menores do seu lado esquerdo. O nome do componente é
escrito abaixo ou dentro de seu símbolo.
Componentes são tipos, mas apenas componentes executáveis podem ter
instâncias. Um diagrama de componente mostra apenas componentes como
tipos. Para mostrar instâncias de componentes, deve ser usado um diagrama
de execução, onde as instâncias executáveis são alocadas em nodes.

87. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
87
Diagrama de Componente
Introdução a UML
A dependência entre componentes pode ser mostrada como uma linha
tracejada com uma seta, simbolizando que um componente precisa do outro
para possuir uma definição completa. Com o diagrama de componentes é
facilmente visível detectar que arquivos .jar são necessários para executar a
aplicação.
Componentes podem definir interfaces que são visíveis para outros
componentes. As interfaces podem ser tanto definidas ao nível de codificação
(como em Java) quanto em interfaces binárias usadas em run-time (COM).
Uma interface é mostrada como uma linha partindo do componente e com um
círculo na outra extremidade. O nome é colocado junto do círculo no final da
linha. Dependências entre componentes podem então apontar para a
interface do componente que está sendo usada.
Reserva.jar Pessoa.jar
PessoaFisica.
PessoaJuridicaCheckIN
Exemplo:

88. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
88
Diagrama de Distribuição
O que é Diagrama de Distribuição?
É um diagrama que exibe a arquitetura física do hardware e do software no sistema.
Pode apresentar os atuais computadores e periféricos, juntamente com as conexões que
eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses
computadores.
Especifica-se também os componentes executáveis e objetos que são alocados para
mostrar quais unidades de software são executados e em que destes computadores são
executados.
O diagrama de distribuição demonstra a arquitetura runtime de processadores,
dispositivos físicos e de software que executam no ambiente onde o sistema
desenvolvido será utilizado. É o último diagrama da topologia do sistema, descrevendo
a estrutura de hardware e software que executam em cada unidade.
O diagrama de distribuição é composto por componentes, que possuem a mesma
simbologia dos componentes do diagrama de componentes, nodes, que significam
objetos físicos que fazem parte do sistema, podendo ser uma computador cliente em
uma Rede, um computador Servidor, uma impressora, um roteador, etc., e conexões
entre estes nodes e componentes que juntos compõem toda a arquitetura física do
sistema.
Cliente A
Servidor
de Aplicação
Servidor
de Banco de
Dados
<<TCP/IP>>
<<TCP/IP>>
0..* 1 1 1
Projeto e Modelagem Visual com UML

89. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
89
Diagrama de Distribuição
Exemplo:
Projeto e Modelagem Visual com UML
Cliente
Servidor
Firewall
Banco de Dados
Web
Oracle Server
Apache sob Linux
HTPP
HTPP
*
1
Banco de Dados
Corporativo
MySQL

90. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
90
Projeto de Desenvolvimento:
Um exemplo

91. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
91
Exemplo de Projeto de Desenvolvimento com UML
Projeto de Desenvolvimento
Fases do Desenvolvimento
O desenvolvimento de um sistema de informação, de acordo com metodologia rápida, é
divido em duas etapas: enquanto a primeira fase, Definição de Requisitos, tem por objetivo
determinar os requisitos, a segunda Análise, tem a finalidade de definir os módulos
componentes do sistema.
Definição dos Requisitos
O objetivo desta fase é determinar a funcionalidade esperada pelo usuário do sistema.
Num projeto de construção civil, esta fase corresponderia ao projeto de arquitetura, onde
se descrevem as características da casa que são visíveis ao seu morador. O produto
desta fase é chamado de Modelo de Requisitos.
A estrutura do Modelo de Requisitos é exibida na figura abaixo. Cada uma das caixas
representa um ou mais documentos que devem ser apresentados no final da fase. O
diagrama indica que o modelo de Requisitos é composto de: Modelo de Casos de Uso,
uma protótipo e um Glossário.
Por sua vez, o Modelo de Casos de uso é composto de diagramas de caso de uso, cada
destes contém uma descrição para o caso de uso.
Modelos de Requisitos
Diagrama de Casos de
Uso
Protótipo Glossário
Casos de Uso
Descrição do Caso
de Uso
1..*
1..*

92. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
92
Segunda fase: Análise e Projeto
O objetivo desta fase é produzir um plano que permita a construção do sistema. Por
exemplo, comparando mais uma vez a engenharia civil, esta fase corresponderia às
plantas detalhadas da construção de uma casa.
Em termos de software, a planta do sistema é a especificação de suas classes
componentes, que chamamos de Modelo de Análise e Projeto.
O Modelo de Análise e Projeto é composto pelo Modelo Estático e pelo Modelo Dinâmico.
O modelo estático é composto por um conjunto de diagramas de classes.
O Modelo Dinâmico é composto por conjuntos de Diagramas de Seqüência e Diagrama
de Estados.
Modelos de Análise e
Projeto
Modelo Estático Modelo Dinâmico
Diagrama de Classes
Classes
Diagrama de Sequência Diagrama de Estado
1..*
1..*
1..* 1..*
Projeto de Desenvolvimento
Exemplo de Projeto de Desenvolvimento com UML

93. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
93
Roteiro para o Desenvolvimento de Sistema usando a Metodologia Rápida
1 - Definir o escopo do Sistema;
2 - Produzir o Modelo de Requisitos
2.1 - Identificar os casos de usos
2.2 - Identificar os atores
2.3 - Identificar e definir as entidades do domínio do problema
2.4 - Definir os casos de uso que podem ser abstraídos
2.5 - Fazer agrupamento dos casos de uso com semântica semelhante
2.6 - Verificar o Modelo de Requisitos
3 - Produzir o Modelo de Análise e Projeto, executando as seguintes etapas:
3.1 - Criar um diagrama com modelo de classes do domínio do problema;
3.2 - Criar um diagrama com o modelo de classes de cada agrupamento de casos
de uso. Este modelo deve conter as classes de domínio, interface e controle
envolvidas no agrupamento de casos de uso.
3.3 - Fazer um diagrama de seqüência para cada agrupamento de caso de uso.
3.4 - Criar um diagrama de transição e estados para as classes de domínio,
interface e controle que tenham ciclos de vida não-triviais.
3.5 - Revisar o diagrama de classes (reveja os relacionamentos)
3.6 - Verificar o modelo de Análise e Projeto.
Projeto de Desenvolvimento
Exemplo de Projeto de Desenvolvimento com UML

94. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
94
Estudo de Caso
e Exercício

95. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
95
Estudo de Caso
Caso Prático
• A Universidade ESU quer informatizar seu sistema de matrícula
– A Secretaria produz o currículo para o semestre
– Os Alunos selecionam 4 matérias principais e 2 matérias
alternativas
– Após a matrícula, o sistema de cobranças será notificado para
que receba o pagamento do estudante por um semestre
– Os Alunos podem usar o sistema para adicionar ou remover
matérias por um determinado período após a matrícula
– Os Professores usam o sistema para receber a lista de ofertas
de cursos
– Os usuários do sistema de matrícula tem senhas que são
utilizadas para validação de logon

96. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
96
Atores
• Um Ator é alguém ou alguma coisa que deve interagir com o sistema
a ser desenvolvido
Aluno
Secretaria
Professor
Sistema Cobrança
Estudo de Caso

97. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
97
Casos de Uso:
• Um caso de uso é um padrão de comportamento que o sistema exibe
– Cada caso de uso é uma seqüência de transações relacionadas
executadas por um ator e o sistema num diálogo
• Atores são examinados para determinar suas necessidades
– Secretaria -- manter o curriculum
– Professor -- solicitar lista de cursos
– Aluno -- manter o horário de aulas
– Sistema Cobrança -- recebe informações sobre cobranças
Manter Horário
Manter Curriculum
Solicitar Lista de Cursos
Estudo de Caso

98. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
98
Documentando Caso de Uso
• Um documento de fluxo de eventos é criado para cada caso de uso
– Escrito do ponto de vista do ator
• Detalha o que o sistema deve fornecer quando o caso de uso é
executado
• Conteúdos típicos
– Como o caso de uso inicia e termina
– Fluxo normal de eventos
– Fluxos alternativos de eventos
– Fluxos excepcionais de eventos (respostas a erros)
Fluxo de Eventos de Manter Curriculum
• Este caso de uso inicia quando a Secretaria entra no sistema e entra
sua senha. O sistema verifica se a senha é válida (E-1) e solicita a
escolha do semestre atual ou futuro (E-2). A Secretaria entra o
semestre desejado. O sistema pergunta qual a atividade desejada:
INCLUIR, APAGAR, MODIFICAR, ou SAIR.
• Caso a atividade selecionada seja INCLUIR, o S-1: O sub-fluxo
Inclui uma Matéria é executado.
• Caso a atividade selecionada seja APAGAR, o S-2: O sub-fluxo
Apaga uma Matéria é executado.
• Caso a atividade selecionada seja MODIFICAR, o S-3: O sub-fluxo
Modificar uma Matéria é executado.
• Caso a atividade selecionada seja SAIR, o caso de uso termina.
• ...
Estudo de Caso

99. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
99
Diagrama de Caso de Uso
• Diagramas de caso de uso são criados para se visualizar a relação
entre atores e casos de uso
Aluno
Secretaria
Professor
Mantém Horário
Mantém Curriculum
Solicita Lista de Cursos
Sistema Cobrança
Estudo de Caso

100. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
100
Usos e Extensões das Relações de Casos de Uso
• À medida em que casos de uso são documentados, outras relações
entre casos de uso poderão ser descobertas
– Uma relação de uso (usa) mostra comportamento que é comum a
um ou mais casos de uso
– Uma relação de extensão mostra comportamento opcional
Matricular para cursos
<<extends>>
Validar Senha
<<extends>>
Manter Curriculum
Estudo de Caso

101. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
101
Realizações de Casos de Uso:
• O Diagrama de Caso de Uso apresenta uma visão externa do sistema
• Diagramas de Interação descrevem como casos de uso são
realizados como interações entre associações de objetos
• Há dois tipos de Diagramas de Interação
– Diagramas de Seqüência
– Diagramas de Colaboração
Diagrama de Seqüência:
• Um Diagrama de Seqüência mostra interações de objetos ordenados
numa seqüência de tempo
: Aluno
1: preenche
2: envia
3: curso(Maria,matemática)
4: está aberto?
5: está aberto?
6: incui(Maria l)
7: incui (Maria)
Formulário de
Matrúcula
Gerente de
Matrículas
Matemática
Básica
Matemática
Álgebra
Tempo
Estudo de Caso

102. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
102
• Um Diagrama de Colaboração mostra interações organizadas à volta de
objetos e as ligações de um para o outro
Diagrama de Colaboração
: Secretaria
curso form :
cursoForm
Diretor :
Diretor_do_Curso
acurso :
curso
1: pega informação curso
2: processa
3: incui curso
4: novo curso
Estudo de Caso

103. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
103
Diagrama de Classes
• Um Diagrama de Classes mostra a existência de classes e suas
relações com a visão lógica do sistema
• Elementos de UML presentes nos Diagramas de Classes:
– Classes, suas estruturas internas e comportamento
– Associações, agregações, dependências, e relações de
herança
– Multiplicidade e indicadores de navegação
– Nomes de papéis (O que uma classe representa para outra)
Classes
• Uma classe é uma coleção de objetos com um estrutura,
comportamento, relações e semântica comuns
• Classes são descobertas pelo exame dos objetos nos diagramas
de Seqüência e Colaboração
• Uma classe é desenhada como um retângulo com três
compartimentos:
– Primeiro: Nome da classe
– Segundo: Atributos (opcional)
– Terceiro: Métodos (opcional)
• Classes devem ser nomeadas usando o vocabulário do domínio
– Padrões de nomenclatura devem ser estabelecidos
– Regra: Todos os nomes de classes são substantivos no
singular, iniciando com letra maiúscula
Exemplo: Cliente, Fornecedor, Pessoa, Aluno e etc.
Estudo de Caso

104. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
104
Diretor Matrícula
Formulário Matrícula
Professor
Aluno
Oferta Curso
Curso
Algorítmo de Horário
Classes:
Estudo de Caso

105. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
105
• O comportamento de uma classe é representado pelas suas operações
• Operações podem ser encontradas examinando-se os Diagramas de
Interação
Matrícula
form
Matrícula
Gerente
3: matricula curso(Maria, matemática)
Diretor Matrícula
Matricula (aluno,curso)
Classes:
Atributos:
Cada Curso oferecido
possui um número,
local e horário
Oferta Curso
número
local
horário
Estudo de Caso

106. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
106
Classes
curso
nome
NúmeroCréditos
abrir()
incluirAluno(AlunoInfo)
Aluno
nome
nível
Professor
nome
StatusCadeira
Algorítmo de Horário
Formulário Matrícula
Diretor Matrícula
incluiAluno(curso, AlunoInfo)
Oferta Curso
local
abrir()
incluirAluno(AlunoInfo)
Estudo de Caso

107. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
107
Relacionamento:
• Relações fornecem um caminho para a comunicação entre os objetos
• Diagramas de seqüência e/ou colaboração são examinados para
determinar quais ligações entre objetos precisam existir para se chegar
ao comportamento desejado. -- Caso dois objetos precisem
“conversar” deverá haver uma ligação entre elas
• Há três tipos de relações:
– Associação e Agregação
– Dependência
– Herança
• Uma associação é uma conexão bidirecional entre classes
– Uma associação é mostrada como uma linha conectando as
classes relacionadas.
• Uma agregação é um tipo mais forte de conexão, aonde a relação é
entre o todo e suas partes.
– Uma agregação é mostrada como uma linha conectando as
classes relacionadas com um losango perto da classes que
representa o todo
• Uma relação de dependência é uma forma mais fraca de relação,
mostrando uma relação entre um cliente e um fornecedor, aonde o
cliente não tem conhecimento semântico do fornecedor
– Uma dependência é mostrada como uma linha pontilhada entre
o cliente e o fornecedor
Associação:
Estudo de Caso

108. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
108
Descobrindo os Relacionamentos:
• Relações são descobertas examinando-se os Diagramas de Sequência
– Caso dois objetos devam “conversar”, deverá haver um caminho
para a comunicação
Diretor
Matrícula
Álgebra
curso
3: insere aluno(Maria)
Diretor Matrúcula
curso
Estudo de Caso

109. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
109
Diretor Matrícula
incluiAluno(curso, AlunoInfo)
Aluno
nome
nível
Oferta Curso
local
abrir()
incluirAluno(AlunoInfo)
Professor
nome
StatusCadeira
Algorítmo de Horário
Formulário Matrícula
curso
nome
NúmeroCréditos
abrir()
incluirAluno(AlunoInfo)
Relacionamento:
Estudo de Caso

110. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
110
Multiplicidade e Navegação:
• Multiplicidade define como muitos objetos participam numa relação
– Multiplicidade é o número de instâncias de uma classe que se
relacionam a UMA instância de uma outra classe
– Para cada associação e agregação, haverá duas decisões
relativas a multiplicidade a se tomar: Uma para cada lado da
relação
• Apesar de associações e agregações serem bidirecionais por
definição, freqüentemente é desejável restringir a navegação em uma
única direção
– Caso a navegação seja restringida, uma seta é adicionada para
se indicar a direção da navegação
Estudo de Caso

111. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
111
Multiplicidade e Navegação:
Diretor Matrícula
incluiAluno(curso, AlunoInfo) curso
nome
NúmeroCréditos
abrir()
incluirAluno(AlunoInfo)
Aluno
nome
nível
Oferta Curso
local
abrir()
incluirAluno(AlunoInfo)
Professor
nome
StatusCadeira
Algorítmo de Horário
Formulário Matrícula
0..*
1 1
0..*
1
1..*
3..10
1
4
0..4
Estudo de Caso

112. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
112
Herança
• Herança é uma relação entre uma super-classe e suas subclasses
• Há duas formas de se descobrir heranças:
– Generalização
– Especialização
• Atributos comuns, operações, relações e/ou, são mostradas no nível
aplicável mais alto da hierarquia
nome
Usuário
Formulário Matrícula Algorítmo de Horário
Diretor Matrícula
incluiAluno(curso, AlunoInfo)
Oferta Curso
local
abrir()
incluirAluno(AlunoInfo)
Aluno
nome
nível
curso
nome
NúmeroCréditos
abrir()
incluirAluno(AlunoInfo)
Professor
nome
StatusCadeira
Estudo de Caso

113. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
113
O Estado de um Objeto
• Um diagrama de transição de estados mostra
– O ciclo de vida de uma classe
– Os eventos que causam a transição de um estado para outro
– As ações que resultam de uma mudança de estado
• Diagramas de Transição de Estados são criados para objetos que
tenham um comportamento dinâmico significante
Iniciar Ação
Abrir
entrar: Registrar Aluno
Sair: incrementa contador
Fechado
Cancelado
fazer: Iiniciar curso
fazer: Finalize curso
fazer: Notificar Aluno Matriculado
Incluir Aluno /
Contador = 0
Inclui aluno[ contador < 10 ]
[ contador = 10 ]
Cancelar
Cancelar
Cancelar
Diagrama de Transições de Estados
Estudo de Caso

114. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
114
O Mundo Físico
• Diagramas de Componentes ilustram a organização e
dependências entre componentes de software
• Um componente pode ser:
– Um componente de código fonte
– Um componente de runtime, ou
– Um componente executável
Estudo de Caso

115. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
115
Curso.class Oferta
curso.class
Aluno.class Professor.class
Diagrama de Componentes
curso.jar pessoa.jar
curso
Usuário
Registro
Cobrança
Sistema
Cobrança
Estudo de Caso

116. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
116
Distribuindo o Sistema
• O Diagrama de Distribuição mostra a configuração dos elementos de
processamento runtime e dos processos que rodam dentro deles
• O Diagrama de Distribuição visualiza a distribuição dos componentes
através de toda a empresa
Matrícula Database
Biblioteca
Salas
Sede
Principal
Diagrama de Distribuição
Estudo de Caso

117. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
117
Exercício
O Hotel “Só quero Sossego” está precisando de sistema para
automatizar suas principais atividades e facilitar o gerenciamento de
suas operações.
O hotel contém um número de apartamentos disponíveis para
serem alugados aos hospedes. Cada apartamento tem as seguintes
características:
- Número, preços base, capacidade de pessoas
- Tipo (Single, double, triplo ou suíte)
O preço de cada apartamento está relacionado com seu tipo e
sazonalidades (períodos especiais, tais como: férias, natal,
carnaval...)
Um hospede pode fazer reserva de mais de um apartamentos
através do telefone, Internet ou pessoalmente no balcão de reserva
do Hotel . As reversas devem ser registras no livro de reservas, que
deve conter as seguintes informações:
- Tipo de apartamento, período, duração da estadia e data da
reserva. A reserva somente é confirmada após a verificação da
disponibilidade do apartamento na data informada. O cliente deve
receber as seguintes informações se confirmada a reserva:
- Preço e detalhes sobre hotel. Caso contrário deve receber a
informação que não foi possível fazer a reserva para data
informada.
Declaração do Problema:

118. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
118
- As reservas também podem ser feitas diretamente na
Recepção do Hotel.
No Check-in o hospede é identificado juntamente com sua
reserva.
No Check-out verifica-se todos os serviços prestados ao
hospede e as despesas advindas desses serviços tais como:
lavandeira, restaurante, telefonia, assim como a consumação do
“frigobar”.
O cliente poderá pagar a conta com cartão de crédito, dinheiro,
cheque ou cheque de viagens.
A disponibilidade deseja para o sistema é de 24x7 para
Internet, as interfaces com usuários devem ser simples e
sistema deve seguir o padrão de Identidade Visual (Manual de
Identidade Visual).
O sistema deve implementar um nível de segurança que garanta
que somente o usuário que possuir uma senha (esta deve ser
criptografa) poderá fazer alterações nos dados da reserva ou
alterar seus cadastrais.
Exercício:
- Fazer o Diagrama de Caso de Reserva
- Fazer o Diagrama de Seqüência
- Fazer o Diagrama de Classes (Classes de Negócio)
- Fazer o Diagrama de Projeto (Refinamento de Casses)
- Fazer o Diagrama de Competentes
Declaração do Problema (continuação):
Exercício

119. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
119
Apêndice

120. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
120
SÍMBOLO GRÁFICO NOME
DIAGRAMAS EM QUE
APARECE USUALMENTE
MODELO A QUE
PERTENCEM
ASSOCIAÇÂO DE
AGREGAÇÃO
Diagrama de Classes,
Diagrama de Componentes.
Classes de Objetos
Componentes
ASSOCIAÇÂO DE
COMPOSIÇÃO
Diagrama de Classes,
Diagrama de Componentes.
Classes de Objetos
Componentes
ASSOCIAÇÂO DE
DEPENDÊNCIA
Diagrama de Casos de Uso,
Diagrama de Classes,
Diagrama de Componentes,
Diagrama de Implantação.
Caso de Uso
Classes de Objetos
Componentes
Componentes
ASSOCIAÇÂO DE
GENERALIZAÇÃO
Diagrama de Casos de Uso,
Diagrama de Classes.
Caso de Uso
Classes de Objetos
ASSOCIAÇÂO
REGULAR
Diagrama de Casos de Uso,
Diagrama de Classes,
Diagrama de Componentes,
Diagrama de Implantação.
Caso de Uso
Classes de Objetos
Componentes
Componentes
ATOR
Diagrama de Casos de Uso,
Diagrama de Seqüência.
Caso de Uso
Caso de Uso
CASO DE USO Diagrama de Casos de Uso. Caso de Uso
CLASSE Diagrama de Classes. Classes de Objetos
COMPONENTE Diagrama de Componentes Componentes
Nome do Estado
ESTADO
Diagrama de Estados,
Diagrama de Atividades.
Classes de Objetos
Caso de Uso
ESTADO FINAL
Diagrama de Estados,
Diagrama de Atividades
Classes de Objetos
Caso de Uso
Nome da Classe
Atributos
Operações
Nome do Componente
Apêndice A
Notação UML

121. Linguagem de Modelagem Unificada
© Copyright Rildo Ferreira, e-tecnologia.com, 2009
UML
121
ESTADO INICIAL
Diagrama de Estados,
Diagrama de Atividades.
Classes de Objetos
Caso de Uso
Nome da “Interface” ou
“INTERFACE” Diagrama de Componentes Componentes
INTERVALO DE
EXECUÇÃO DE
OPERAÇÂO
Diagrama de Seqüência Caso de Uso
MENSAGEM DE
RETORNO
Diagrama de Seqüência Caso de Uso
MENSAGEM E
CHAMADA DE
OPERAÇÂO
“Síncrona”
Diagrama de Seqüência Caso de Uso
MENSAGEM E
CHAMADA DE
OPERAÇÃO
“Assíncrona”
Diagrama de Seqüência Caso de Uso
NÓ Diagrama de Implantação Componentes
texto NOTA Em qualquer diagrama
identificador:Classe ou :Classe
OBJETO
Diagrama de Seqüência,
Diagrama de Atividades
Caso de Uso
Caso de Uso
Nome do Pacote PACOTE
Em qualquer diagrama em que é
necessário representar um
conjunto de coisas que devem
estar agrupadas para efeito de
uma organização apropriada
TRANSIÇÃO DE
ESTADO
Diagrama de Estados,
Diagrama de Atividades
Classes de Objetos
Caso de Uso
AUTODELEGAÇÃO Diagrama de Seqüência Caso de Uso
<<interface>>
Nome da “Interface”
Operação1 ()
Operação2 ()
Operação3 ()
Apêndice A
Notação UML