Apostila UML

Prévia do material em texto

Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
UML 
Ricardo Terra 
rterrabh [at] gmail.com 
UML 1 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
CV 
UML 2 
Nome: Ricardo Terra 
Email: rterrabh [at] gmail.com 
www: ricardoterra.com.br 
Twitter: rterrabh 
Lattes: lattes.cnpq.br/ 0162081093970868 
 
 
Ph.D. (UFMG/UWaterloo), 
Post-Ph.D. (INRIA/Université Lille 1) 
 
Background 
Acadêmico: UFLA (desde 2014), UFSJ (1 ano), FUMEC (3 anos), UNIPAC (1 ano), FAMINAS (3 anos) 
Profissional: DBA Eng. (1 ano), Synos (2 anos), Stefanini (1 ano) 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Introdução 
UML 3 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 4 
O que é UML? 
n  UML (Unified Modeling Language) é uma família de notações 
gráficas, apoiada por um metamodelo único, que ajuda na 
descrição e no projeto de sistemas de software, particularmente 
daqueles construídos utilizando o estilo orientado a objetos (OO) 
n  Esta definição é um tanto simplificada. Na verdade, para 
diferentes pessoas a UML tem significados diferentes 
n  As linguagens gráficas de modelagem existem há muito tempo 
na indústria do software. O propulsor fundamental por trás de 
todas elas é o fato das linguagens de programação não estarem 
em um nível de abstração suficiente alto para facilitar discussões 
sobre projeto 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 5 
O que é UML? 
n  A UML é um padrão relativamente aberto, controlado pelo OMG 
(Object Management Group), um consórcio aberto de empresas. 
O OMG foi formado para estabelecer padrões que suportassem 
interoperabilidade, especificamente de sistemas orientados a 
objetos. Talvez, o OMG seja mais conhecido pelo padrões 
CORBA (Commom Object Request Broker Architecture) 
n  A UML nasceu da unificação das muitas linguagens gráficas de 
modelagem orientadas a objetos 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 6 
Diagramas UML 
n  A UML 2.0 descreve 13 (treze) tipos de diagramas oficiais, 
indicando que 3 novos diagramas foram inseridos desde sua 
última versão 
n  Nosso foco na disciplina não é exatamente ver todos, mas sim, 
aqueles mais comuns, são os diagramas mais utilizados: 
q  Atividades 
q  Classes 
q  Interação 
n  Sequência 
n  Colaboração 
q  Caso de Uso (CDU) 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 7 
Diagramas UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 8 
Significado da UML 
n  Um dos problemas difíceis da UML é que, embora a 
especificação descreva com bastante detalhe o que é UML bem-
formada, ela não tem muito a dizer a respeito do que significa 
UML fora do mundo refinado dos metamodelos UML 
n  Não existe nenhuma definição formal sobre como a UML é 
mapeada para qualquer linguagem de programação específica, 
isto é, você não vê um diagrama UML e dizer exatamente qual 
seria o código equivalente 
 Na prática, isto é suficiente para ser útil 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 9 
Onde começar com UML? 
n  “Ninguém, nem mesmo seus criadores, entende ou utiliza tudo 
que há na UML. A maioria das pessoas utiliza um pequeno 
subconjunto da UML e trabalha com isto.” (FOWLER, 2005) 
n  Podemos pensar em UML como o processo de engenharia de 
software RUP. Ambos são muito grandes, todavia ninguém o 
usa como um todo. As pessoas/empresas separam o que 
realmente acreditam que seja útil e o utilizam 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diagrama de Atividade 
UML 10 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 11 
Diagrama de Atividades 
n  Os diagramas de atividades são uma técnica para descrever 
lógica de procedimento, processo de negócio e fluxo de trabalho 
n  Se assemelha aos fluxogramas, mas a principal diferença é o 
fato dos diagramas de atividades suportarem comportamento 
paralelo 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 12 
Diagrama de Atividades 
n  Um diagrama de atividades é normalmente composto pelos 
seguintes elementos: 
q  Atividade 
q  Transição 
q  Condição de guarda 
q  Decisão 
q  Ponto de merge 
q  Ponto de Início 
q  Ponto de Fim 
q  Concorrência 
n  Bifurcação 
n  Sincronização 
n  Veremos um pouco de cada um desses 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 13 
Atividades e transições 
n  Uma atividade é uma etapa em um processo, onde algum 
trabalho está sendo realizado 
n  A atividade é representada por um retângulo arredondado, 
contendo texto em forma livre 
n  Um diagrama de atividades é uma série de atividades ligadas 
por transições, que são setas conectando cada atividade 
n  Normalmente uma transição ocorre quando uma atividade é 
concluída 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 14 
Atividades e transições 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 15 
Condição de Guarda 
n  Em algumas situações, a transição só deve ocorrer se 
determinada condição ocorra 
n  Uma condição de guarda pode ser atribuída com a intenção de 
restringir o uso daquela transição 
n  A condição de guarda é uma condição dentro de conchetes em 
proximidade a seta de transição 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 16 
Decisões 
n  Assim como no fluxograma, o losango do diagrama de 
atividades também representa um ícone de decisão. Uma seta 
sai do losango para cada valor possível da condição testada 
n  A condição pode ser simples (como um booleano) ou mais 
abrangente 
n  Cada opção é identificada por meio de uma condição de guarda. 
Cada condição de guarda precisa ser mutuamente exclusiva, de 
modo que somente uma opção possa ser selecionada a partir da 
decisão 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 17 
Decisões 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 18 
Ponto de merge 
n  O ícone de losando também é usado para modelar um ponto de 
merge 
n  O ponto de merge é um local onde dois caminhos alternativos se 
juntam e continuam como apenas 1 caminho 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 19 
Ponto de Início e de Fim 
n  A UML também oferece ícone para iniciar e terminar um 
diagrama de atividade 
q  Um ponto sólido indica o início do fluxo de atividades 
q  Um “olho de boi” indica o ponto final 
n  Somente deve existir um ponto de início por diagrama de 
atividade 
n  Podem existir vários pontos de fim. Se quiser pode apontar 
todas suas transições apontando para o mesmo ponto de fim, 
mas todos estes pontos de fim significam a mesma coisa: “Parar 
todas as atividades do diagrama” 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 20 
Ponto de Início e de Fim 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 21 
Concorrência 
n  A notação admite concorrência, que permite modelar os 
recursos das linguagens que foram criados após a invenção do 
fluxograma. Estes recursos são conhecidos como threads ou 
processos concorrentes 
n  Para demostrar que um processo simples inicia vários outros 
processos concorrentemente, o diagrama de atividades utiliza 
uma barra simples, chamada bifurcação 
q  Cada transição de saída desta bifurcação é uma nova thread 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 22 
Concorrência 
n  Para a sincronização de diversos processos paralelos é utilizada 
a mesma barra, todavia agora conhecida como barra de 
sincronização 
n  Nesta barra de sincronização, chega diversos processos e saí 
apenas uma transição, que indica que o processamento 
concorrente acabou e o diagrama de atividades continua como 
uma única thread ou processo 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 23 
Concorrência 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 24 
Exemplo Completo 
n  Ver página 119 do livro UML Essencial - 3ª edição. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 25 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diagramade Casos de Uso 
UML 26 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 27 
Casos de Uso 
n  Os casos de uso são uma técnica para captar os requisitos 
funcionais de um sistema. Eles servem para descrever as 
interações típicas entre os usuários de um sistema e o próprio 
sistema, fornecendo uma narrativa de como o sistema é utilizado 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 28 
Abordagem 
n  Nossa abordagem neste estudo será: 
q  Diagramas de casos de uso 
q  Narrativas de caso de uso 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 29 
Narrativa de um caso de uso 
n  Não existe nenhuma maneira padronizada para escrever o 
conteúdo de um caso de uso e diferentes formatos funcionam 
bem em diferentes casos 
n  O slide a seguir mostra um estilo comum de uso. Você começa 
escolhendo um dos cenários como sendo o cenário principal de 
sucesso (CPS). Da início ao corpo do caso de uso escrevendo o 
CPS como uma seqüência de passos numerados. Então, pega 
os outros cenários e os escreve como extensões, descrevendo-
os em termos de variações em relação ao cenário principal de 
sucesso. As extensões podem ser bem-sucedidas – o usuário 
atinge o objetivo, como em 3a – ou falhas como em 6a 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 30 
Narrativa de um caso de uso 
Nome: Comprar produto. 
 
Pré-condições: Cliente com acesso a internet na página inicial do comércio eletrônico. 
 
Cenário Principal de Sucesso: 
1. O cliente navega pelo catálogo e seleciona itens para comprar. 
2. O cliente vai para o caixa, isto é, fecha o carrinho de compra. 
3. O cliente preenche formulário de remessa (forma de pagamento; endereço da entrega; opção de entrega imediata ou em três 
dias). 
4. O sistema apresenta a informação completa do faturamento, incluindo a remessa. 
5. O cliente autoriza a compra. 
6. O sistema confirma imediatamente a venda. 
7. O sistema envia uma confirmação para o cliente por e-mail. 
 
Extensões: 
3a. Cliente regular: 
.1: O sistema mostra a informação atual da remessa, a informação do preço e a informação de cobrança. 
.2: O cliente pode aceitar ou escrever por cima desses padrões, retornando ao CPS no passo 6. 
 
6a. O sistema falha na autorização de compra a crédito 
.1: O cliente pode inserir novamente a informação do cartão de crédito ou cancelar. 
 
Pós-condições: Cliente finaliza sua compra. 
Ver figura 9.1 da página 105 do livro UML Essencial – 3ª edição 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 31 
Diagrama de Caso de Uso 
n  Um diagrama de caso de uso é normalmente 
composto pelos seguintes elementos: 
q  Ator: 
n  Um papel desempenhado por uma pessoa, sistema, dispositivo 
ou mesmo uma empresa, que possui interesse na operação 
bem-sucedida do sistema 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 32 
Diagrama de Caso de Uso 
q  Caso de Uso 
n  Identifica um comportamento-chave do sistema. Sem esse 
comportamento, o sistema não preencherá os requisitos do ator. 
Cada caso de uso expressa um objetivo que o sistema precisa 
alcançar e/ou um resultado que ele precisa produzir 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 33 
Diagrama de Caso de Uso 
q  Associação 
n  Identifica uma relação entre atores e casos de usos. Cada 
associação torna-se um diálogo que deve ser explicado em uma 
narrativa de caso de uso. Cada narrativa oferece um conjunto de 
cenários como já foi visto anteriormente 
Ver figura 12.12 e 12.13 das páginas 320-321 do livro UML, a Bíblia. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 34 
Diagrama de Caso de Uso 
q  Relacionamento include (inclusão) 
n  Identifica um caso de uso reutilizável, que é incorporado 
incondicionalmente na execução de outro caso de uso. A 
responsabilidade pela decisão sobre quando e por que usar o 
caso de uso incluído encontra-se no caso de uso que o chama 
Ver figura 12.14 da página 322 do livro UML, a Bíblia. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 35 
Diagrama de Caso de Uso 
q  Relacionamento extend (extensão) 
n  Identifica um caso de uso reutilizável, que interrompe 
condicionalmente a execução de outro caso de uso para 
aumentar sua funcionalidade. A responsabilidade por decidir 
quando o caso de uso estendendo deve ser usado encontra-se 
com o caso de uso estendendo 
Ver figura 12.15 da página 323 do livro UML, a Bíblia. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 36 
Diagrama de Caso de Uso 
«extend» X «include» 
 Include Extend 
Aumentam o comportamento do caso de uso básico. 
O caso de uso incluído sempre é 
utilizado. 
O caso de uso de extensão pode ser 
usado. 
A seta do relacionamento é desenhado do 
caso de uso em execução para o caso de 
uso incluído. 
A seta do relacionamento indica que o 
caso de uso básico direciona o caso de 
uso incluído para a execução. 
A seta do relacionamento é desenhada do 
caso de uso de extensão para o caso de 
uso em execução. 
A seta indica que o caso de uso de 
extensão está tomando a decisão se 
deverá interromper o caso de uso em 
execução. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 37 
Diagrama de Caso de Uso 
q  Generalização 
n  Identifica um relacionamento de herança entre atores. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 38 
Diagrama de Caso de Uso – Exemplo 
Ver figura 12.4 da página 314 do livro UML, a Bíblia. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 39 
Diagrama de Caso de Uso 
n  Como construir um diagrama de Caso de Uso (PENDER): 
1.  Definir o contexto do sistema: 
1.  Identificar atores e suas responsabilidades. 
2.  Identificar os casos de uso, os comportamentos do sistema, 
em termos de objetivos específicos e/ou resultados que 
precisam ser produzidos. 
2.  Avaliar os atores e casos de uso para encontrar oportunidades 
de refinamento, como divisão ou merge de definições. 
3.  Avaliar os casos de uso para encontrar relacionamentos do tipo 
«include». 
4.  Avaliar os casos de uso para encontrar relacionamentos do tipo 
«extend». 
5.  Avaliar os atores para oportunidades de generalização 
(propriedades compartilhadas) 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 40 
Diagrama de Caso de Uso 
n  Como construir um diagrama de Caso de Uso (FOWLER): 
q  Embora o diagrama de Caso de Uso às vezes seja útil, ele não 
é obrigatório. Em seu trabalho com casos de uso, não se 
esmere muito no diagrama. Em vez disto, concentre-se na 
narrativa (conteúdo textual) do caso de uso. 
q  A melhor maneira de pensar em um diagrama de caso de uso é 
como um sumário gráfico do conjunto de casos de uso. O 
diagrama de casos de uso mostra os atores, os casos de uso e 
os relacionamentos entre eles. 
n  Quais atores realizam quais casos de uso? 
n  Quais casos de uso incluem outros casos de uso? 
q  A UML inclui outros relacionamentos entre os casos de uso, 
além da inclusão e da extensão, mas não é necessário nos 
aprofundarmos a este ponto. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diagrama de Classe 
Existe uma versão mais atualizada deste material como uma seção da 
Apostila Java (também publicamente disponível) 
UML 41 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diferenciação entre classe e objeto 
n  As classes formam o alicerce do diagrama de classes. Assim, para 
trabalhar com diagrama de classes, você precisa ter uma noção 
clara da diferença entre classes e objetos. Portanto: 
q  Classe é a definição para um recurso. Ela inclui informações que 
descrevem os recursos de uma entidade e como ela pode ser utilizada 
 
q  Objetos, ao contrário, são instâncias de uma classe. Pode-se dizer que 
um objeto é uma entidade identificável de forma exclusiva de acordo 
com as regras definidas pela classe 
42 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diagrama de Classes 
n  “Se alguém chegar perto de você em um beco escuro e disser: 
“Psiu,quer ver um diagrama UML:”, esse provavelmente seria um 
diagrama de classes. A maioria dos diagramas UML que vejo é 
composta por diagrama de classes.” (FOWLER, 2005) 
n  “O diagrama de classes provavelmente é o diagrama mais utilizado 
da UML. Na verdade, o diagrama de classes é a ferramenta de 
modelagem principal para descrever a própria UML.” (PENDER, 
2004) 
43 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diagrama de Classes 
n  Um diagrama de classes descreve os tipos de objetos presentes no 
sistema e os vários tipos de relacionamento estáticos existentes 
entre eles 
n  Os diagramas de classe também mostram as propriedades e 
operações de uma classe e as restrições que se aplicam à maneira 
como os objetos estão conectados 
44 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Classe 
n  Uma classe é uma descrição de um conjunto de objetos que 
partilham os mesmos atributos, operações, relações e semântica 
n  Por exemplo, na classe Cliente, "João da Silva" pode ser 
considerado um dos objetos em um sistema que pretende 
manipular informação referente aos clientes de uma empresa 
45 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Classe 
n  Uma classe é descrita por seus aspectos estruturais através de 
seus atributos e através de seus aspectos comportamentais através 
de suas operações 
n  Uma classe (seus atributos e operações) pode ser detalhada 
através de sua visibilidade e sua multiplicidade. Uma classe é 
representada como mostrado no desenho abaixo: 
46 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Operações e Atributos de uma Classe 
n  Uma classe é definida nos seus aspectos estruturais através de 
seus atributos e nos seus aspectos comportamentais através de 
suas operações 
n  Uma classe não tem necessariamente que corresponder a uma 
entidade humana ou, mais genericamente, a uma entidade com 
representação física (por exemplo, uma fatura) 
n  Pode-se representar entidades mais abstratas (por exemplo, venda) 
47 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Atributos de uma Classe 
n  Atributo da classe 
q  São propriedades semelhantes que os objetos de uma classe possuem. 
O "João da Silva" além do nome, também é caracterizado por outros 
atributos, como endereço, número do contribuinte, cpf, rg, etc 
q  Cada atributo permite definir um intervalo de valores que as instâncias 
dessa propriedade podem apresentar 
q  Meu carro é branco, o seu é preto 
n  Essas propriedades de carro são descritas pelo atributo cor 
48 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Atributos de uma Classe 
n  Tanto nos atributos quanto nas operações de uma classe podem 
ser especificados detalhes de sua visibilidade e de sua 
multiplicidade 
n  A sintaxe básica de um atributo é: 
 
 [visibilidade] nome-do-atributo : [tipo] { =valor-inicial } 
 
n  Exemplos: 
 
 + nome : String 
 
 - salario : double = 1000.00 
 
 # nota : int 
49 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Operações de uma Classe 
n  Operações da Classe 
q  O João da Silva possui uma identidade própria, isto é, para a empresa, 
ele é distinto de todos os outros clientes 
q  Essa identidade não é só descrita pelos atributos. Todos os objetos de 
uma classe podem fazer alguma coisa (um serviço) ou pode-se fazer 
com ele alguma coisa 
q  As operações são responsáveis pela efetivação dos serviços prestados 
pelas classes 
q  Sobre o cliente "João da Silva" pode-se efetuar várias operações como 
emitir-lhe faturas, alterar seu endereço, apagá-lo da base de dados, etc 
50 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Operações de uma Classe 
n  A sintaxe básica de uma operação é: 
 
 [visibilidade] nome-da-operação ( [lista-de-parâmetros] ) : [tipo-retorno] 
 
n  Exemplos: 
 
 - mostrar() : void 
 
 + calcularTaxa( valorDolar : double ) : double 
 
 # somar (a : int , b: int ) : int 
51 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Operações e Atributos Estáticos 
n  Uma operação ou um atributo que não pertence a uma instância da 
classe, mas à classe como um todo é chamado de operação e 
atributo estático, respectivamente 
n  Operações e atributos estáticos são compartilhados por todas as 
instâncias da classe, mas não pertence a nenhuma instância 
52 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Visibilidade 
n  Os atributos e operações de uma classe podem ser especificados 
para mostrar como a mesma pode ser vista e utilizada pelos outros 
elementos do sistema 
n  Os níveis de visibilidade para o atributo ou a operação: 
q  (+) PÚBLICO: 
n  Todas as classes visualizam 
q  (-) PRIVADO: 
n  Somente a própria classe visualiza 
q  (#) PROTEGIDO: 
n  Todas as classes do mesmo pacote e sub-classes visualizam 
q  (~) PACOTE: 
n  Todas as classes do mesmo pacote visualizam 
53 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Visibilidade 
n  Exemplo: 
q  Somente a própria classe tem acesso direto aos atributos do veículo 
q  Qualquer classe pode ligar ou desligar o veículo 
q  Somente classes do mesmo pacote ou sub-classes podem acelerar ou 
frear o veículo 
q  Somente a própria classe pode ativar o ABS 
q  Somente classes do mesmo pacote podem ver o consumo do veículo 
54 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Associação 
n  Outra maneira de se criar um atributo é através de uma 
associação 
n  Associação é uma linha cheia entre duas classes, direcionadas 
da classe de origem para a classe de destino. A direção pode 
ser nos dois sentidos, o que gera uma Associação Bidirecional 
q  Exemplo: 
q  Este exemplo indica que um objeto NotaFiscal possui pelo menos 
um objeto ItemNotaFiscal. 
55 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Associação 
n  Ainda no exemplo: 
q  Como pode ser visto não deve-se colocar uma associação como 
atributo, pois a própria associação já nos diz isto 
q  O código Java ficaria assim: 
public class NotaFiscal { ! ! ! !!
 private List<ItemNotaFiscal> itensNotaFiscal; ! !!
 ... ! ! ! ! ! ! !
}!
!
public class ItemNotaFiscal{!
 private NotaFiscal notaFiscal;!
 ... !!
} 
56 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Classes Associativas 
n  Algumas associações de muitos para muitos exige a necessidade 
da criação de uma classe associativa entre as duas classes 
associadas 
n  No exemplo abaixo existe a classe Paciente com seus atributos e a 
classe Exame com seus atributos. Do relacionamento entre 
Paciente e Exame, tem-se a data da realização e o diagnóstico 
Observe: 
57 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Multiplicidade 
n  A multiplicidade de uma classe é o número de instâncias possíveis 
que uma classe pode ter considerando uma única instância da outra 
classe a qual ela é associada. Ou seja, é o número de objetos de 
uma classe que pode relacionar com um único objeto de uma outra 
classe 
n  Multiplicidades são números simples ou intervalos de números. A 
tabela abaixo exemplifica os tipos comuns de multiplicidades 
0..1 Uma instância opcional. 
1 Exatamente uma instância. 
0..* Zero ou mais instâncias. 
1..* Pelo menos uma instância. 
58 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Multiplicidade 
n  No exemplo abaixo, um pedido pode estar vinculado a um único 
cliente, porém um cliente poderá possuir qualquer quantidade de 
pedidos 
n  E esses? 
59 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Generalização 
n  Trata-se da ação de uma classe herdar toda a estrutura de uma 
outra classe 
q  Uma sub-classe sempre herda de sua super-classe: 
n  Atributos 
n  Operações 
n  Relacionamentos 
q  Uma sub-classe pode: 
n  Adicionar atributos e operações 
n  Adicionar relacionamentos 
n  Sobrepôr (override) operações herdadas 
n  Sobrecarregar (overload) operações herdadas 
n  Umasub-classe sempre herda tudo de sua super-classe, isto é, não 
tem como herdar somente alguns atributos ou operações 
60 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Generalização 
n  Exemplo: 
q  ContaCorrente é um tipo de Conta 
q  ContaPoupanca é um tipo de Conta 
61 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Pacotes 
n  Um pacote é um mecanismo de agrupamento 
n  Pode ser utilizado para agrupar qualquer elemento UML (como 
casos de uso, atores, classes, componentes e outros pacotes) 
n  Geralmente utizada para especificar uma distribuição lógica 
62 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Pacotes 
n  Os pacotes em um diagrama de classes são altamente utilizados, 
pois, na implementação do sistema, a organização das classes são 
sempre feitas utilizando pacotes 
63 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Notas e Comentários 
n  Assim como todo diagrama UML pode ser inseridos notas ou 
comentários 
64 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Cuidado 
n  Diagrama de Classes não é um modelo ER 
n  O maior perigo com os diagramas de classes é que você pode 
focalizar exclusivamente na estrutura e ignorar o comportamento 
65 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Exercício de Fixação 01 
n  A gráfica ABC trabalha com diversos autores que escrevem 
os livros que ela publica. Alguns autores escreveram apenas 
um livro, enquanto outros já escreveram vários. Além disso, 
alguns livros foram escritos por vários autores, porém um livro 
deve possuir pelo menos um autor. A gráfica ABC trabalha 
também com diversas impressoras, porém um livro só pode 
ser impresso em uma única impressora. 
 Deve ser possível buscar os livros de um autor, saber qual foi 
a impressora em que o livro foi impresso, saber a quantidade 
de páginas que uma impressora já imprimiu e a quantidade 
de páginas que ela imprimiu de um determinado livro, entre 
outros. 
66 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Exercício de Fixação 01 - Solução 
67 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Exercício de Fixação 02 
n  Um veículo tem chassi, modelo, peso, ano de 
fabricação. Um veículo não existe por si só, ele deve ser 
um avião ou um carro. Todo veículo liga e desliga. Um 
carro acelera e freia e um avião decola, voa e pousa. 
68 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Exercício de Fixação 03 
n  Um imóvel possui um endereço, área (em m2) e um proprietário. O 
imóvel pode ser uma casa ou um apartamento. Caso seja casa 
possuirá também o número do registro do lote e, caso seja 
apartamento, possuirá o número do andar e um flag indicando se 
possui ou não elevador. Um proprietário possui cpf, nome e 
telefone. 
Pelo menos as seguintes operações devem existir: 
n  Alterar a área de um imóvel 
n  Alterar o proprietário de um imóvel 
n  Alterar o flag se possui ou não elevador do apartamento 
n  Recuperar a quantidade de imóveis de um proprietário 
n  Alterar o telefone de um proprietário 
 
n  PS: Atenção com os parâmetros e com o tipo de retorno das operações 
69 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Exercício de Fixação 04 
n  Uma pessoa possui cpf e nome. Um professor é uma pessoa que também possui uma titulação e 
a IES (Instituição de Ensino Superior) vinculada. Um aluno também é uma pessoa e possui a 
informação de qual período se encontra e qual o seu curso (um curso possui um registro do 
MEC, um nome e sua área de concentração). 
 Uma palestra possui um nome e um assunto e pode ser ministrada por diversos professores. 
Para cada professor ministrando cada palestra, deve constar a data e a localização (rua, número, 
bairro, cidade, estado e telefone) deste evento e, um aluno, pode assistir vários destes eventos. 
 Pelo menos as seguintes operações devem existir: 
q  Alterar o nome de uma pessoa; 
q  Alterar a titulação de um professor; 
q  Alterar a IES de um professor; 
q  Alterar o período em curso de um aluno; 
q  Alterar o curso de um aluno; 
q  Alterar o registro do MEC de um curso; 
q  Alterar o nome de uma palestra; 
q  Alterar a data de um evento; 
q  Alterar a localização de um evento; 
q  Alterar o telefone de uma localização. 
70 UML 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
Diagrama de Interação 
UML 71 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 72 
Diagramas de Interação 
n  Os diagramas de interação mostram como os objetos interagem uns 
com os outros. Permitem assim modelar os aspectos dinâmicos de 
um sistema. Existem dois tipos de diagramas de interação: 
q  Diagrama de Seqüência 
q  Diagrama de Colaboração 
n  O diagrama de colaboração pode ser usado para mostrar como os 
objetos em um sistema interagem sobre múltiplos casos de uso . 
n  Por outro lado, um diagrama de seqüência é tipicamente usado 
para mostrar a interação de objetos em um único caso de uso. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 73 
Objeto da Classe 
n  Objeto de Classe é uma instância de uma classe, isto é, uma 
manifestação concreta de algo abstrato. 
n  No exemplo acima, existe a definição da classe Carro e dois 
objetos desta classe. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 74 
Mensagens 
n  Uma mensagem é a remessa de um sinal ou a chamada de uma 
operação de um objeto (o emissor) para um ou mais objetos (receptor). 
n  A mensagem é o elemento principal do diagrama de interação. 
n  Uma mensagem é representada graficamente como uma seta (do 
emissor ao receptor), acima do qual pode-se colocar um nome 
(geralmente o nome da operação) e um número de sequência. 
n  No exemplo acima, o objeto emissor (:Motorista) invoca o método ligar 
do objeto receptor (:Carro). 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 75 
Mensagens 
n  Existem diversos tipos de 
mensagens, tais como 
mensagem síncronas 
( m a i s u s a d a s ) , 
assícronas, de retorno, 
a u t o - r e f e r ê n c i a e 
temporizada, observe a 
diferença entre elas. 
Seta Tipo Descrição 
Síncrona Envio de mensagens síncronas. 
Assíncrona É uma mensagem que não 
bloqueia o emissor. Isto é, o 
emissor e o receptor executam 
concorrentemente. 
Retorno Indica o retorno do controle 
após uma nova mensagem ter 
sido enviada 
Auto-
referência 
Usada quando um objeto 
n e c e s s i t a e n v i a r u m a 
mensagem para ele mesmo. 
Temporizada Indica que a mensagem enviada 
possui tempo de vida. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 76 
Diagrama de Seqüência 
n  O diagrama de seqüência, como um dos dois tipos de diagrama de 
interação, mostra a interação existente num conjunto de objetos e 
seus relacionamentos, dando ênfase à ordenação temporal de 
mensagens. 
n  Nesse diagrama, colocam-se os objetos de classes que participam de 
interação no topo (eixo X), o objeto que inicia a interação é colocado 
mais à esquerda e os demais vão sendo colocados à direita. As 
mensagens trocadas são dispostas ao longo do eixo dos Y, de acordo 
com os vínculos entre os objetos da classe, e em ordem crescente do 
tempo. 
n  Os diagramas de sequência diferenciam dos diagramas de 
colaboração por apresentar linhas de vida e barras de ativação. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 77 
Linhas de Vida 
n  Linhas de vida são linhas verticais tracejadas que indicam a existência 
do objeto no tempo. 
q  Recomenda-se que todos os objetos a serem utilizados sejam inseridos já 
no início do diagrama com sua respectiva linha de vida, observe: 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 
n  Barras de ativação representam o tempo que um objeto necessita 
para completar uma tarefa. As barras mostram o tempo em que objeto 
está ativo. 
q  As barras de ativação são representadas graficamente por um retângulo alto 
e estreito, colocado no eixo Y, sobre as linhas de vida dosobjetos. 
n  Observe exemplo no próximo slide. 
UML 78 
Barras de Ativação 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 79 
Diagrama de Sequência 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 80 
Diagrama de Colaboração 
n  O diagrama de colaboração, como um dos dois tipos de diagrama de 
interação, mostra a interação existente num conjunto de objetos e seus 
relacionamentos, dando ênfase à organização estrutural dos objetos. 
n  O diagrama mostra os objetos das classes que participam da 
interação, mostrando os vínculos entre os mesmos, descrevendo as 
mensagens que os objetos recebem e enviam. 
n  Os diagramas de colaboração diferenciam-se dos diagramas de 
seqüências nestes aspectos: 
q  Existe um caminho que indica como o objeto está vinculado a outro. 
q  Existe um número de seqüência para indicar a ordem temporal de uma 
mensagem. 
n  No diagrama de seqüência é altamente recomendado, mas é opcional. 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 81 
Diagrama de Colaboração 
Ricardo Terra (rterrabh [at] gmail.com) Julho, 2009 UML 82 
Referência Bibliográfica 
n  FOWLER, Martin. UML Essencial. 3 ed. Porto Alegre: Bookman, 
2005. 
n  PENDER, Tom. UML, a Bíblia. 2 reimp. Rio de Janeiro: 
Campus, 2004.