Apostila para Curso de UML

UML:
Unified Modeling Language
I
Sumário
1. Introdução...............................................................................1-1
Objetivos.................................................................................................................................1-2
Conectando os estudos.....................................................................................................1-3
Desenvolvimento de software orientado a objetos................................................1-5
UML – A unificação dos métodos e criação de um novo padrão.......................1-6
Uso da UML............................................................................................................................1-8
Fases do Desenvolvimento de um Sistema...............................................................1-9
Análise de Requisitos.......................................................................................................1-10
Análise...................................................................................................................................1-11
Design (Projeto).................................................................................................................1-12
Programação.......................................................................................................................1-13
Testes.....................................................................................................................................1-14
Exercícios..............................................................................................................................1-15
2. Diagrama de Use Case..............................................................2-1

Objetivos.................................................................................................................................2-2
Definição de Use Case.......................................................................................................2-3
O Levantamento de Requisitos......................................................................................2-4
O Use Case.............................................................................................................................2-6
Atores.......................................................................................................................................2-9
Relacionamentos entre casos de uso e atores.......................................................2-14
Associação...........................................................................................................................2-15
Generalização.....................................................................................................................2-16
Extensão (extends)...........................................................................................................2-18
Inclusão (Include)..............................................................................................................2-20
Modelando requisitos com casos de uso..................................................................2-22
Casos de uso e pacotes..................................................................................................2-24
Quando Utilizar Casos de Uso......................................................................................2-26
Exemplos de descrição textual....................................................................................2-27
Exercícios..............................................................................................................................2-29
3. Diagrama de Atividades............................................................3-1
Objetivos.................................................................................................................................3-2
Definição do diagrama......................................................................................................3-3
Elementos do diagrama....................................................................................................3-4
Atividade.................................................................................................................................3-5
Início do diagrama..............................................................................................................3-6
Fim do diagrama..................................................................................................................3-7
Transições...............................................................................................................................3-8
Desvios....................................................................................................................................3-9
Separação e União............................................................................................................3-12
Estado de subatividade...................................................................................................3-15
Concorrência Dinâmica...................................................................................................3-16
Raias (Swimlanes).............................................................................................................3-17
Quando Utilizar Diagramas de Atividades...............................................................3-18
Exercícios..............................................................................................................................3-20
4. Diagrama de Classes................................................................4-1
II
Objetivos.................................................................................................................................4-2
Introdução..............................................................................................................................4-3
Perspectivas..........................................................................................................................4-5
Criando Diagramas de Classe.........................................................................................4-7
Compartimento do Nome da Classe..........................................................................4-10
Atributos................................................................................................................................4-11
Operações............................................................................................................................4-15
Relacionamentos...............................................................................................................4-18
Associação...........................................................................................................................4-19
Nome da associação........................................................................................................4-20
Multiplicidade......................................................................................................................4-21
Papel (role)...........................................................................................................................4-22
Navegabilidade..................................................................................................................4-23
Herança/Generalização...................................................................................................4-24
Dependência.......................................................................................................................4-28
Agregação............................................................................................................................4-29
Composição.........................................................................................................................4-31
Pacotes de classes e colaborações no sistema.....................................................4-32
Pacotes..................................................................................................................................4-33
Colaborações.......................................................................................................................4-36
Quando Utilizar Diagramas de Pacotes e Colaborações.....................................4-37
Multiplicidade......................................................................................................................4-38
Escopo...................................................................................................................................4-40
Classes de Associação.....................................................................................................4-42
Associação Xor (ou exclusiva)......................................................................................4-44
Estereótipo...........................................................................................................................4-45
Interfaces e Classes Abstratas.....................................................................................4-47
Objetos de Referência e Objetos de Valor...............................................................4-50
Objetos de referência......................................................................................................4-51
Objeto de Valor...................................................................................................................4-52
Coleções para Pontas de Associações de Valores Múltiplos.............................4-53
Frozen....................................................................................................................................4-54
Visibilidade...........................................................................................................................4-55
Quando Utilizar Diagramas de Classes.....................................................................4-58
Exercícios..............................................................................................................................4-59
5. Diagrama de Estados................................................................5-1
Objetivos.................................................................................................................................5-2
O que é um Diagrama de Estados?..............................................................................5-3
Estado......................................................................................................................................5-4
Estado Inicial e Estado Final............................................................................................5-7
Transições...............................................................................................................................5-8
Estado composto...............................................................................................................5-11
Quando Utilizar Diagramas de Estados....................................................................5-12
Exercícios..............................................................................................................................5-13
6. Diagrama de Objetos................................................................6-1
Objetivos.................................................................................................................................6-2
O que é um diagrama de objetos?................................................................................6-3
Criando diagramas de objetos.......................................................................................6-4
III
Quando utilizar diagrama de objetos?........................................................................6-8
Exercícios................................................................................................................................6-9
7. Diagrama de Interação.............................................................7-1
Objetivos.................................................................................................................................7-2
O que é um diagrama de Interação?...........................................................................7-3
Diagrama de seqüências..................................................................................................7-5
Diagrama de colaboração..............................................................................................7-11
Modelando diagramas de seqüências.......................................................................7-14
Quando Utilizar Diagramas de Interação.................................................................7-17
Exercícios..............................................................................................................................7-18
8. Diagramas Físicos....................................................................8-1
Objetivos.................................................................................................................................8-2
O que são diagramas físicos?.........................................................................................8-3
Diagrama de Componentes.............................................................................................8-4
Componente..........................................................................................................................8-5
Diagrama de Implantação................................................................................................8-6
Nó..............................................................................................................................................8-7
Combinando Componentes com Diagramas de Utilização.................................8-8
Quando Utilizar Diagramas Físicos.............................................................................8-10
Exercícios..............................................................................................................................8-11
9. Apêndice: Extensibilidade da UML.............................................9-1

Mecanismos de extensibilidade da UML.....................................................................9-2
Estereótipos...........................................................................................................................9-3
Restrições...............................................................................................................................9-7
Glossário.................................................................................................................................9-8
IV
UML
1
2
UML: Unified Modeling Language
1. Introdução
1
Introdução
Objetivos
 Conhecer a UML
 Conhecer os principais métodos que originaram a UML
 Descrever onde pode ser utilizada a UML
 Conhecer as fases de um processo de construção de software
2
Introdução
Conectando os estudos
No curso anterior estudamos os conceitos de orientação a objetos e

vimos como a tecnologia de objetos está organizada. Estudamos vários
conceitos importantes dentre eles o conceito de classe, objeto, herança,
polimorfismo e alguns relacionamentos entre as classes. Foi dado ênfase no
estudo da orientação a objetos e deixado para este curso que você está
iniciando o estudo de como podemos modelar um sistema utilizando uma
linguagem de modelagem de sistemas voltada para a tecnologia de objetos.
Não iremos utilizar diagramas de fluxo de dados (DFDs) para fazer a
modelagem de sistemas orientados a objetos, a pesar de algumas pessoas
tentarem utilizar, uma vez que para a tecnologia de objetos existe outra
técnica específica.
O grande problema do desenvolvimento de novos sistemas utilizando a

orientação a objetos nas fases de análise de requisitos, análise de sistemas e
design é que não existe uma notação padronizada e realmente eficaz que
abranja qualquer tipo de aplicação que se deseje. Cada simbologia existente
possui seus próprios conceitos, gráficos e terminologias, resultando numa
grande confusão, especialmente para aqueles que querem utilizar a orientação
a objetos não só sabendo para que lado aponta a seta de um relacionamento,
mas sabendo criar modelos de qualidade para ajudá-los a construir e manter
sistemas cada vez mais eficazes.
Quando a "Unified Modeling Language" (UML) foi lançada, muitos

desenvolvedores da área da orientação a objetos ficaram entusiasmados já
que essa padronização proposta pela UML era o tipo de força que eles sempre
esperaram.
A UML é muito mais que a padronização de uma notação. É também o

desenvolvimento de novos conceitos não normalmente usados. Por isso e
muitas outras razões, o bom entendimento da UML não é apenas aprender a
simbologia e o seu significado, mas também significa aprender a modelar
orientado a objetos no estado da arte.
UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson
que são conhecidos como "os três amigos". Eles possuem um extenso
conhecimento na área de modelagem orientado a objetos já que as três mais
conceituadas metodologias de modelagem orientada a objetos foram eles que
desenvolveram e a UML é a junção do que havia de melhor nestas três
metodologias adicionado novos conceitos e visões da linguagem. Veremos
características de cada uma destas metodologias no desenvolver deste curso.
Veremos neste curso como a UML aborda o caráter estático e dinâmico

do sistema a ser analisado levando em consideração, já no período de
modelagem, todas as futuras características do sistema em relação a
3
Introdução
utilização de "packages" próprios da linguagem a ser utilizada, utilização do

banco de dados bem como as diversas especificações do sistema a ser
desenvolvido de acordo com as métricas finais do sistema.
Não é intuito deste curso definir e explicar os significados de classes,

objetos, relacionamentos, mensagens e outras entidades comuns da
orientação a objetos, e sim apresentarmos como essas entidades são criadas,
simbolizadas, organizadas e como serão utilizadas dentro de um
desenvolvimento utilizando a UML. Os conceitos como já comentado foram
tratados no curso de Orientação a Objetos o qual recomendamos que seja feito
antes deste.
4
Introdução
Desenvolvimento de software orientado a

objetos
Os conceitos da orientação a objetos têm sido discutidos há muito

tempo, desde o lançamento da primeira linguagem orientada a objetos, a
SIMULA. Vários "papas" da engenharia de software mundial como Peter Coad,
Edward Yourdon e Roger Pressman abordaram extensamente a análise
orientada a objetos como realmente um grande avanço no desenvolvimento de
sistemas. Mas mesmo assim, eles citam que não existe (ou que não existia no
momento de suas publicações) uma linguagem que possibilitasse o
desenvolvimento de qualquer software utilizando a análise orientada a objetos.
Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram,

discutiram e definiram em suas publicações foram que:
A orientação a objetos é uma tecnologia para a produção de modelos

que especifiquem o domínio do problema de um sistema.
Quando construídos corretamente, sistemas orientados a objetos são

flexíveis a mudanças, possuem estruturas bem conhecidas e provêm
a oportunidade de criar e implementar componentes totalmente
reutilizáveis.
Modelos orientados a objetos são implementados convenientemente

utilizando uma linguagem de programação orientada a objetos. A
engenharia de software orientada a objetos é muito mais que utilizar
mecanismos de sua linguagem de programação, é saber utilizar da
melhor forma possível todas as técnicas da modelagem orientada a
objetos.
A orientação a objetos não é só teoria, mas uma tecnologia de

eficiência e qualidade comprovada e usada em inúmeros projetos
para construção de diferentes tipos de sistemas.
A orientação a objetos requer um método que integre o processo de

desenvolvimento e a linguagem de modelagem com a construção de técnicas
e ferramentas adequadas.
5
Introdução
UML – A unificação dos métodos e criação de

um novo padrão
A UML é uma tentativa de padronizar a modelagem orientada a objetos

de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado
corretamente, com consistência, fácil de se comunicar com outras aplicações,
simples de ser atualizado e compreensível.
Existem várias metodologias de modelagem orientada a objetos que até

o surgimento da UML causavam uma guerra entre a comunidade de
desenvolvedores orientado a objetos. A UML acabou com esta guerra trazendo
as melhores idéias de cada uma destas metodologias, e mostrando como
deveria ser a migração de cada uma para a UML.
Falaremos sobre algumas das principais metodologias que se tornaram

populares nos anos 90:
 Booch – O método de Grady Booch para desenvolvimento orientado a

objetos está disponível em muitas versões. Booch definiu a noção de que
um sistema é analisado a partir de um número de visões, onde cada
visão é descrita por um número de modelos e diagramas. O Método de
Booch trazia uma simbologia complexa de ser desenhada a mão,
continha também o processo pelo qual sistemas são analisados por
macro e micro visões.
 OMT – Técnica de Modelagem de Objetos (Object Modelling Technique) é

um método desenvolvido pela GE (General Electric) onde James
Rumbaugh trabalhava. O método é especialmente voltado para o teste
dos modelos, baseado nas especificações da análise de requisitos do
sistema. O modelo total do sistema baseado no método OMT é composto
pela junção dos modelos de objetos, funcional e use-cases.
 OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos

baseados no mesmo ponto de vista formado por Ivar Jacobson. O método
OOSE é a visão de Jacobson de um método orientado a objetos, já o
Objectory é usado para a construção de sistemas tão diversos quanto
eles forem. Ambos os métodos são baseados na utilização de use-cases,
que definem os requisitos iniciais do sistema, vistos por um ator externo.
O método Objectory também foi adaptado para a engenharia de
negócios, onde é usado para modelar e melhorar os processos
envolvidos no funcionamento de empresas.
Cada um destes métodos possui sua própria notação (seus próprios

símbolos para representar modelos orientados a objetos), processos (que
6
Introdução
atividades são desenvolvidas em diferentes partes do desenvolvimento), e

ferramentas (as ferramentas CASE que suportam cada uma destas notações e
processos).
Diante desta diversidade de conceitos, "os três amigos", Grady Booch,

James Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de
Modelagem Unificada. Eles disponibilizaram inúmeras versões preliminares da
UML para a comunidade de desenvolvedores e a resposta incrementou muitas
novas idéias que melhoraram ainda mais a linguagem.
Os objetivos da UML são:
 A modelagem de sistemas (não apenas de software) usando os conceitos

da orientação a objetos
 Estabelecer uma união fazendo com que métodos conceituais sejam

também executáveis
 Criar uma linguagem de modelagem usável tanto pelo homem quanto

pela máquina
A UML está destinada a ser dominante, a linguagem de modelagem

comum a ser usada nas indústrias. Ela está totalmente baseada em conceitos
e padrões extensivamente testados provenientes das metodologias existentes
anteriormente, e também é muito bem documentada com toda a especificação
da semântica da linguagem representada em meta-modelos. Atualmente as
empresas de desenvolvimento de software utilizam muito esta linguagem,
podemos afirmar tranqüilamente que esta é a linguagem de modelagem de
dados e processos mais utilizada por empresas que trabalham com linguagens
orientadas a objeto.
7
Introdução
Uso da UML
A UML é usada no desenvolvimento dos mais diversos tipos de sistemas.

Ela abrange sempre qualquer característica de um sistema em um de seus
diagramas e é também aplicada em diferentes fases do desenvolvimento de
um sistema, desde a especificação da análise de requisitos até a finalização
com a fase de testes.
O objetivo da UML é descrever qualquer tipo de sistema, em termos de

diagramas orientado a objetos. Naturalmente, o uso mais comum é para criar
modelos de sistemas de software, mas a UML também é usada para
representar sistemas mecânicos sem nenhum software. Aqui estão alguns
tipos diferentes de sistemas com suas características mais comuns:
 Sistemas de Informação: Armazenar, pesquisar, editar e mostrar

informações para os usuários. Manter grandes quantidades de dados
com relacionamentos complexos, que são guardados em bancos de
dados relacionais ou orientados a objetos.
 Sistemas Técnicos: Manter e controlar equipamentos técnicos como de

telecomunicações, equipamentos militares ou processos industriais. Eles
devem possuir interfaces especiais do equipamento e menos
programação de software de que os sistemas de informação. Sistemas
Técnicos são geralmente sistemas real-time.
 Sistemas Real-Time Integrados: Executados em simples peças de

hardware integrado a telefones celulares, carros, alarmes etc. Estes
sistemas implementam programação de baixo nível e requerem suporte
real-time.
 Sistemas Distribuídos: Distribuídos em máquinas onde os dados são

transferidos facilmente de uma máquina para outra. Eles requerem
mecanismos de comunicação sincronizados para garantir a integridade
dos dados e geralmente são construídos em mecanismos de objetos
como CORBA, COM/DCOM ou Java Beans/RMI.
 Sistemas de Software: Definem uma infra-estrutura técnica que

outros softwares utilizam. Sistemas Operacionais, bancos de dados, e
ações de usuários que executam ações de baixo nível no hardware, ao
mesmo tempo que disponibilizam interfaces genéricas de uso de outros
softwares.
 Sistemas de Negócios: descreve os objetivos, especificações (pessoas,

computadores etc.), as regras (leis, estratégias de negócios etc.), e o
atual trabalho desempenhado nos processos do negócio.
8
Introdução
É importante perceber que a maioria dos sistemas não possuem apenas

uma destas características acima relacionadas, mas várias delas ao mesmo
tempo. Sistemas de informações de hoje, por exemplo, podem ter tanto
características distribuídas como real-time. E a UML suporta modelagens de
todos estes tipos de sistemas.
9
Introdução
Fases do Desenvolvimento de um Sistema
Atualmente existem muitos processos para desenvolvimento de software

criados por empresas e pesquisadores. Nós iremos aqui mostrar algumas fazes
do desenvolvimento de software, para isto dividimos o ciclo de
desenvolvimento em cinco fases: análise de requisitos, análise, design
(projeto), programação e testes. Estas cinco fases não devem ser executadas
na ordem descrita acima, mas concomitantemente de forma que problemas
detectados numa certa fase modifiquem e melhorem as fases desenvolvidas
anteriormente de forma que o resultado global gere um produto de alta
qualidade e desempenho. A seguir falaremos sobre cada fase do
desenvolvimento de um sistema em UML.
10
Introdução
Análise de Requisitos
Esta fase captura as intenções e necessidades dos usuários do sistema a

ser desenvolvido através do uso de funções chamadas "use-cases". Através do
desenvolvimento de "use-case", as entidades externas ao sistema (em UML
chamados de "atores externos") que interagem e possuem interesse no
sistema são modelados entre as funções que eles requerem, funções estas
chamadas de "use-cases". Os atores externos e os "use-cases" são modelados
com relacionamentos que possuem comunicação associativa entre eles ou são
desmembrados em hierarquia. Cada "use-case" modelado é descrito através
de um texto, e este especifica os requerimentos do ator externo que utilizará
este "use-case". O diagrama de "use-cases" mostrará o que os atores externos,
ou seja, os usuários do futuro sistema deverão esperar do aplicativo,
conhecendo toda sua funcionalidade sem importar como esta será
implementada. A análise de requisitos também pode ser desenvolvida baseada
em processos de negócios, e não apenas para sistemas de software.
11
Introdução
Análise
A fase de análise está preocupada com as primeiras abstrações (classes

e objetos) e mecanismos que estarão presentes no domínio do problema. As
classes são modeladas e ligadas através de relacionamentos com outras
classes, e são descritas no Diagrama de Classe. As colaborações entre classes
também são mostradas neste diagrama para desenvolver os "use-cases"
modelados anteriormente, estas colaborações são criadas através de modelos
dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao
domínio principal do problema do software, ou seja, classes técnicas que
gerenciem banco de dados, interface, comunicação, concorrência e outros não
estarão presentes neste diagrama.
12
Introdução
Design (Projeto)
Na fase de design, o resultado da análise é expandido em soluções

técnicas. Novas classes serão adicionadas para prover uma infra-estrutura
técnica: a interface do usuário e de periféricos, gerenciamento de banco de
dados, comunicação com outros sistemas, dentre outros. As classes do
domínio do problema modeladas na fase de análise são mescladas nessa nova
infra-estrutura técnica tornando possível alterar tanto o domínio do problema
quanto a infra-estrutura. O design resulta no detalhamento das especificações
para a fase de programação do sistema.
13
Introdução
Programação
Na fase de programação, as classes provenientes do design são

convertidas para o código da linguagem orientada a objetos escolhida (a
utilização de linguagens procedurais é extremamente não recomendada).
Dependendo da capacidade da linguagem usada, essa conversão pode ser
uma tarefa fácil ou muito complicada. No momento da criação de modelos de
análise e design em UML, é melhor evitar traduzi-los mentalmente em código.
Nas fases anteriores, os modelos criados são o significado do entendimento e
da estrutura do sistema, então, no momento da geração do código onde o
analista conclua antecipadamente sobre modificações em seu conteúdo, seus
modelos não estarão mais demonstrando o real perfil do sistema. A
programação é uma fase separada e distinta onde os modelos criados são
convertidos em código.
14
Introdução
Testes
Um sistema normalmente é rodado em testes de unidade, integração, e

aceitação. Os testes de unidade são para classes individuais ou grupos de
classes e são geralmente testados pelo programador. Os testes de integração
são aplicados já usando as classes e componentes integrados para se
confirmar se as classes estão cooperando uma com as outras como
especificado nos modelos. Os testes de aceitação observam o sistema como
uma "caixa preta" e verificam se o sistema está funcionando como o
especificado nos primeiros diagramas de "use-cases".
O sistema será testado pelo usuário final o qual verificará se os

resultados mostrados estão realmente de acordo com as necessidades
levantadas durante a fase de requisitos.
15
Introdução
Exercícios
1. Cite e descreva, brevemente, os principais métodos que deram origem a

UML bem como os seus autores.
2. Que tipos de sistemas podem fazer uso da UML?
3. Quais são as fases do desenvolvimento de software? Quais são as

principais atividades de cada uma destas fases?
16
Introdução
Espaço para anotações
17
2. Diagrama de Use Case
1
Diagrama de Use Case
Objetivos
 Entender o diagrama de use case
 Conhecer os elementos que fazem parte deste diagrama
 Aprender a modelar um diagrama de use case para um sistema
 Conhecer os tipos de relacionamentos possíveis entre os elementos
do use case
 Saber quando e como utilizar use case
2
Definição de Use Case
Neste capítulo iremos estudar um dos diagramas centrais da UML, o

diagrama de Use Case (Casos de Uso). Este é um diagrama fundamental para
a modelagem de sistemas orientados a objeto quando utilizamos UML. A maior
dificuldade em modelarmos um sistema não está nos diagramas que temos
que desenhar, no código que devemos criar ou nas bases de dados que
devemos projetar. Na realidade está nos requisitos que devemos gerenciar.
Os requisitos que um sistema possui muitas vezes são complexos, não

estou falando aqui de requisitos simples, como o usuário pedir "Faça um
programa que permita a leitura de uma seqüência de números e informe a
média e o desvio padrão desse conjunto". Temos na verdade que lidar com
dezenas de páginas de "desejos do usuário". Sim, o usuário deseja que o
sistema realize determinadas tarefas, deseja que o sistema realize seus sonhos
e muitas vezes deseja que ele faça milagres. A espectativa dos usuários
quanto aos sistemas é sempre muito grande, eles imaginam que o mesmo
possa realizar todas as coisas que eles precisam e que irá resolver todos os
seus problemas. Acham no sistema a solução para os seus problemas.
Sabemos que isto não é verdade e que algumas tarefas não podemos modelar
e passar par dentro do software.
Pois é com essa expectativa humana que temos que lidar. Temos que
entender o que o usuário quer, e muito mais importante, demonstrar que
realmente entendemos seus desejos. A grande pedra do desenvolvimento de
sistemas começa exatamente neste ponto. Como era difícil validar com o
usuário o que havia sido levantado! Como era difícil transportar para modelos
e códigos aquelas dezenas de linhas em linguagem natural! Precisamos
documentar todos os desejos dos usuários para depois podermos tentar
realizá-los.
A Língua Portuguesa, assim como outras, é ambígua, por natureza.

Portanto, necessitamos de um padrão que permita o uso de linguagem natural,
mas em um formato que reduza as ambiguidades. Além disso, que permita
com facilidade converter essa estrutura para os diagramas e implementações
do sistema. Para isto então temos os diagramas de Caso de Uso na UML.
3
O Levantamento de Requisitos
A UML e a modelagem de casos de usos não interfere nas técnicas

usadas pelos desenvolvedores para o levantamento de requisitos. Pelo
contrário, o caso de uso torna-se o "braço direito" do desenvolvedor,
auxiliando-o a validar os requisitos extraídos junto ao usuário.
O levantamento de requisitos de um sistema não é uma tarefa fácil, mas

também não é impossível. O problema reside no fato de que estamos lidando
com um ser humano que expressa suas idéias, geralmente fora de ordem e
sem muita explicação. É difícil encontrarmos o usuário que nos forneça a
“receita de bolo” pronta para desenvolver seu sistema. Normalmente ele tem
muitos problemas, muitas idéias de como solucioná-los e uma idéia bem
distorcida do que um sistema de computação pode fazer por ele. E a partir daí
nossa tarefa é bem simples: pegar todo esse emaranhado e transformar
primeiramente numa documentação inteligível para ambas as partes e depois
no sistema dos sonhos dele! Claro que estou brincando, não é tão simples
assim todo este processo e muitas vezes nós passamos por inúmeras
discuções onde precisamos mostrar que algumas coisas que o usuário está
querendo fazer de uma determinada forma não será possível e que para poder
atingir o mesmo objetivo devemos seguir outro caminho.
Sabemos que os problemas existem, mas com as técnicas, ferramentas e

paradigma adequados, tudo pode correr tranqüilamente. Temos que ter em
mente que o usuário não é o nosso inimigo, pelo contrário, se conseguirmos
estabelecer com ele uma comunicação sem ruídos, certamente a validação
ocorrerá sem problemas e o nosso software conseguirá então satisfazer os
desejos do usuário.
Durante este processo de levantamento de requisitos através de

conversas com os usuários é preciso mostrar para o usuário que devemos
formar um time para alcançarmos o mesmo objetivo. É importante que durante
este processo haja muita troca de informações entre os usuários e analistas.
Esta troca de informações é que irá garantir o sucesso desta etapa de
levantamento de requisitos.
Vamos pensar: se o usuário despeja sobre nós analistas uma centena de

conceitos e procedimentos a respeito da sua área de negócios e apenas
"engolimos" esses conceitos sem analisá-los, o que ocorrerá? Provavelmente
estaremos implementando a nossa impressão sobre o assunto e não a
realidade do problema. Toda informação, por mais singela, deve ser analisada
quanto a sua inconsistência e/ou ambiguidade. Para que você entenda o que
quero transmitir, vamos fazer um teste.
4
Suponhamos o seguinte dialogo entre usuário e analista:
Desenvolvedor:
O quo o senhor espera desse sistema?
Usuario:
Eu tenho uma loja de peças. Gostaria que o meu PV fosse interligado

com meu estoque e eu pudesse a qualquer momento alterar valores dos FP's.
Posso oferecer descontos a alguns tipos de clientes, mas preciso autorizar essa
operação. No fim do mês quero um relatório dos produtos que mais venderam.
Preciso também saber a estatística de vendas por forma de pagamento. De
tempos em tempos deve aparecer na tela do sistema uma promoção
relâmpago que de um brinde ao cliente. Preciso que o sistema controle os
pedidos também.
O que você identificaria de ambíguo ou não compreensível nessa

descrição do usuário? Várias coisas, não?! Pois bem, cabe ao analista buscar o
esclarecimento desses itens. Podemos então começar perguntando a esse
usuário:
O que 6 PV e FP?
Que tipos de clientes podem receber descontos?
Como seria feita esta autorização de desconto e por quem?
Que quantidade de produtos deve aparecer no relatório dos que mais
venderam?
A estatística leva em conta que período (semanal, quinzenal, mensal,
etc)?
Quanto tempo significa "de tempos em tempos"?
Quais pedidos precisam ser controlados: os dos clientes ou os feitos aos
fornecedores?
Provavelmente, as respostas a essas perguntas levarão a novas dúvidas,

que precisarão ser esclarecidas. Percebemos, então, que uma postura correta
dos participantes associada a boas técnicas de levantamento de requisitos (por
exemplo: entrevistas e brainstorming (Consiste em uma ou várias reuniões nas
quais os participantes sugerem idéias, sem que as mesmas sejam criticadas.
Numa segunda fase, as idéias passam por uma revisão e organização).
Todavia, precisamos expressar esses requisitos de uma forma que não seja
para o desenvolvedor um texto extenso e pouco estruturado e para o usuário
não sejam seqüências de comandos sem o menor sentido. É agora que a
modelagem de casos de uso nos ajuda, unindo usuários e desenvolvedores.
5
O Use Case
Um caso de uso (Use Case) descreve uma seqüência de ações que

representam um cenário principal (perfeito) e cenários alternativos, com o
objetivo de demonstrar o comportamento de um sistema (ou parte dele),
através de interações com atores. Vamos esmiuçar essa definição para
conseguir entende-la.
Uma vez que o desenvolvedor levante os requisitos com o usuário, há a

necessidade de documentá-los, não só para entendimento e validação de
ambas as partes, como para servir de base não ambígua para toda a equipe de
desenvolvimento. A documentação dos requisitos evita que informações
importantes se percam, sendo descobertas apenas ao apresentar o produto
final ao usuário. Em desenvolvimento de sistemas não funciona amarrar uma
fitinha no dedo, para não esquecer de um requisito importante!
Utilizando a modelagem de casos de uso, o primeiro passo do

desenvolvedor é separar as funcionalidades do sistema. Destas
funcionalidades, devemos agrupar um conjunto de ações que tenham um
objetivo bem definido.
Suponhamos, num sistema de vendas de uma loja de roupa, que sejam

tarefas distintas e bem definidas: consultar informações sobre um produto,
efetuar reserva, emitir comprovante de reserva, efetuar venda, emitir nota
fiscal, realizar fechamento diário do caixa, etc. Cada uma destas tarefas possui
um conjunto de ações que precisam ser executadas para que o objetivo da
tarefa seja alcançado. No caso de efetuar venda, é preciso informar a
identificação da vendedora, a identificação do produto, quantidade vendida,
etc. Ao pensarmos nessas ações realizadas numa rotina sem problemas,
estamos lidando com um cenário perfeito, que será o nosso cenário
principal.
O cenário principal descreve uma seqüência de ações que serão

executadas considerando que nada de errado ocorrerá durante a execução da
seqüência.
Vejamos no exemplo abaixo o trecho do caso de uso "Emitir Saldo em um

terminal de caixa eletrônico":
Cenário Principal
1. O sistema realiza a leitura do cartão magnético do correntista;

2. O sistema solicita a digitação da senha. O correntista digita a senha;
3. O sistema valida a senha;
4. O correntista seleciona a opção de saldo;
6
5. O sistema questiona o tipo de saldo: conta corrente, poupança e aplicações;

6. O sistema processa e mostra o saldo solicitado pelo cliente.
No exemplo acima, temos um cenário perfeito, no qual nada ocorre de

errado. Todavia, o mundo não é perfeito, muito menos as transações de um
sistema. Então, como podemos representar as exceções? Podemos represetá-
las com os cenários alternativos. Por exemplo: considerando o cenário principal
da emissão de saldo em um Caixa Eletrônico, poderiamos modelar os cenários
alternativos descritos abaixo.
Alternativa: Problemas na leitura do cartão magnético
1ª) Se o sistema não conseguir ler os dados do cartão magnético, tentar nova
leitura por, no máximo, mais duas vezes. Caso persista o problema, encerrar o
caso de uso (ao dizermos que haverá o encerramento do caso de uso. Estamos
afirmando que a rotina não pode prosseguir pelo motivo relatado. Logicamente
que numa implementação, o fluxo retornará ao seu início (nesse caso, a leitura
de um próximo cartão magnético).
Alternativa: Senha Inválida
3ª) Se a senha digitada pelo correntista não for igual a senha cadastrada no
sistema, informar ao mesmo e solicitar nova digitação. Esse processo pode ser
repetido por no máximo três tentativas (incluindo a primeira). Após a terceira
tentativa, a conta do usuário deverá ser bloqueada e o caso de uso encerrado.
Include Bloquear Conta (o include corresponde a um dos tipos de
relacionamentos entre os diagramas de caso de uso e será explocado mais
adiante nesta apostila).
Alternativa: Conta Inexistente
6ª) Se o correntista não possuir o tipo de conta selecionada, informar ao

mesmo e encerrar o caso de uso.
Nos exemplos acima as alternativas são apresentadas como subitens do

cenário principal (ítens 1, 3 e 6). Esse procedimento facilita a associação da
alternativa com o fluxo principal. O caso de uso deve descrever uma rotina
bem definida do sistema e deve ser totalmente compreensível tanto para a
equipe de desenvolvimento quanto para os clientes que detém o
conhecimento do domínio do sistema.
O caso de uso, por expressar os requisitos do sistema - nada mais do que

a essência deste -, é utilizado durante todo o processo de desenvolvimento. Os
requisitos além de serem a base para a criação dos modelos de análise,
7
projeto e implementação, também são usados como base para a criação de

testes do sistema. Podemos dizer que o modelo de casos de uso será central
para todas as demais etapas do desenvolvimento do sistema. Este diagrama
será sempre utilizado na construção dos demais, sendo muito importante estar
bem definido expressando os desejos do cliente.
Já entendemos porque o caso de uso é uma seqüência de ações, o que é

um cenário principal e o que é um cenário alternativo. Esta faltando apenas
saber o que são interações com atores.
Ao modelarmos um sistema, necessitamos saber até que ponto devemos

nos preocupar. Estes pontos-limites são a fronteira do sistema (system
boundary).
Por exemplo: um sistema de controle de vendas emitirá em algum

momento o faturamento semanal ou mensal de cada vendedor para o
Departamento Pessoal. Todavia, não é responsabilidade do sistema o que o
Departamento Pessoal fará com essa informação.
Os sistemas recebem e enviam informações para o mundo externo

através de suas fronteiras, também conhecidas como interface do sistema.
Logicamente que essas informações não podem cair num "buraco negro", na
saída, nem surgem por mágica, na entrada. Alguém ou algo deve ser
responsável por enviar e/ou receber informações do sistema.
Vejamos a representação gráfica do caso de uso:
Um caso de uso é representado por uma elipse contendo o seu nome. O nome
do caso de uso também pode ser colocado abaixo da elipse, que pode conter
ou não compartimentos referentes a pontos de extensão (estes serão
apresentados mais tarde no curso).
Figura 2-1: Representação básica de um use case
8
9
Atores
Na modelagem de casos de uso, esse papel externo é exercido por um

ator (actor). Na realidade, esse ator, que pode ser tanto uma pessoa, como
um grupo ou ainda um sistema, representa um conjunto de papéis. Um caso
de uso pode se relacionar com mais de um ator.
Um ator representa um conjunto de papéis exercido por um usuário do

sistema ao interagir com um determinado caso de uso.
Um ator é, portanto, um papel que um usuário desempenha em relação

ao sistema. Quando você lidar com atores, é importante pensar nos papeis em
vez de pensar nas pessoas ou em cargos. Os atores desempenham os casos de
uso. Um único ator pode desempenhar muitos casos de uso; um caso de uso
pode ter reciprocamente vários atores desempenhando-o. Na prática,
considero que os atores são mais úteis quando se está propondo os casos de
uso. Em face de um grande sistema, freqüêntemente pode ser difícil propor
uma lista de casos de uso. Nestas situações, é mais fácil chegar primeiro a
lista de atores, e, então, tentar estabelecer os casos de uso para cada ator.
Os atores não precisam ser humanos, embora sejam representados como

bonecos humanos nos diagramas de caso de uso. Um ator também pode ser
um sistema externo que necessita de alguma informação do sistema atual.
Existem diversas variações no que as pessoas mostram como atores. Algumas
pessoas mostram cada sistema externo ou agente humano no diagrama de
caso de uso; outras preferem mostrar o ativador do caso de uso. Prefiro expor
o agente que obtém valor do caso de uso, o qual algumas pessoas chamam de
ator básico. Entretanto, não levo isso muito longe. Contento-me em ver o
sistema de contabilidade obtendo valor, sem tentar identificar o agente
humano que obtém o valor do sistema de contabilidade - isso transmitiria
modelagem ao próprio sistema de contabilidade. Dito isto, você deve sempre
contrapor casos de uso com atores do sistema, descubra quais são os objetivos
reais do usuário e considere maneiras alternativas para atingir estes objetivos.
Vejamos a representação gráfica de um ator:
O ícone estereótipo padrão para um ator é a figura de um "stick man",

contendo seu nome abaixo da figura. Outra representação consiste num
retângulo de classe, com o estereótipo << actor >>. E, ainda, é permitido ao
desenvolvedor utilizar outros ícones que identifiquem mais precisamente o tipo
de ator.
10
Figura 2-2: Representação de atores
Quando estou trabalhando com atores e casos de uso, não me preocupo

muito sobre qual é a associação exata entre eles. Na maioria das vezes, estou
realmente interessado nos casos de uso; os agentes são simplesmente um
meio de chegar lá. A medida que tenho todos os casos de uso, não me
preocupo com os detalhes dos agentes.
Existem algumas situações nas quais vale a pena descobrir os agentes

mais tarde.
O sistema pode precisar configuração para vários tipos de usuários.

Neste caso, cada tipo de usuário é um ator e os casos de uso lhe
mostram o que cada ator precisa fazer.
Identificar quem deseja casos de uso pode ajudá-lo a negociar

prioridades entre vários atores.
Alguns casos de uso não têm ligações claras com atores específicos.
Considere uma empresa de serviço público. Evidentemente, um dos seus casos
de uso é “Enviar Contas”. Entretanto, não é fácil identificar um ator associado.
Nenhum papel de usuário em especial necessita uma conta. A conta é enviada
para o cliente, mas ele não se importaria se isso não acontecesse. O melhor
palpite para ator aqui é o Departamento de Cobrança, no sentido que este
obtém valor deste caso de uso. Mas o Departamento de Cobranca, não está,
geralmente, envolvido neste caso de uso.
11
Esteja ciente de que alguns casos de uso não aparecem como resultado
do processo de considerá-los para cada ator. Se isso acontecer, não se
preocupe muito. O importante é compreender casos de uso e os objetivos dos
usuários que eles atingem.
Uma boa fonte para identificar os casos de uso são os eventos externos.
Considere todos os eventos do mundo externo para os quais você quer reagir.
Um dado evento pode causar uma reação no sistema que não envolve
usuários, ou pode causar principalmente reação dos usuários. A identificação
dos acontecimentos para os quais o sistema necessita reagir vai lhe ajudar a
identificar os casos de uso.
Como exemplo vamos considerar a representação da figura abaixo. Num

determinado sistema acadêmico, a rotina de atualizar a freqüência dos alunos
pode ser executada por quem? Pelos funcionários da Secretaria, pelo próprio
Professor ou pelo Sistema de Avaliação on-line. Esses papéis são representados
por Atores.
Essa comunicação sistema-ator (e vice-versa) consiste da interação

entre sistema e atores.
Figura 2-3: Atores interagindo com o caso de uso
É responsabilidade do caso de uso demonstrar com quais atores o

sistema interage. Essa identificação na fase de análise fornece ao projetista,
no futuro, base para a criação dos perfis de acesso ao sistema.
12
O caso de uso especifica como alcançar a realização de um

procedimento sem relacionar detalhes de implementação. Portanto,
mostramos o que executar sem definir a forma como é feito.
Veja os exemplos.
Considere o seguinte trecho de caso de uso:
"... O cliente seleciona na lista o produto desejado..."
Essa pequena descrição nos diz que existe uma lista contendo os
produtos disponíveis para esta operação. Todavia, a descrição não diz se essa
lista será representada por um grid, uma listbox, uma combobox ou algum
outro tipo de componentes. Não represente nas alternativas validações que
por default já são feitas em qualquer sistema.
Por exemplo: num campo data qualquer, checar se a entrada do

usuário é uma data válida no calendário (por exemplo: 14/01/2004).
Entretanto, deve-se expressar validações que se refiram as regras de

negócio.
Por exemplo: o campo data de rescisão de contrato deve estar dentro

do mês corrente. Esta é uma regra de negócio que deve aparecer no caso de
uso.
Exemplo de um caso de uso com cenários principais e alternativos.
Caso de Uso: Reserva em um Restaurante
Ator: Atendimento ao cliente

Cenário Principal
1. O cliente informa ao atendente a data da reserva, que é repassada ao sis-

tema;
2. O sistema mostra o mapa do salão do restaurante, indicando as mesas já
reservadas e as que estão livres. O sistema calcula e exibe o número de
reservas ainda disponíveis.
3. Um ou vários lugares disponíveis é (são) escolhido(s) para reserva.
4. O sistema solicita o CPF do cliente, para identificação do mesmo no sistema.
O sistema pesquisa o cliente e mostra nome e telefones de contato, para
confirmação.
5. Após confirmação, a reserva é efetuada em nome do cliente.
Cenários Alternativos
Alternativa: Data não disponfvel para reserva
13
1ª) O sistema verifica se para a data informada é possível efetuar reservas.

Caso negativo, uma nova data deve ser solicitada.
Alternativa: Reservas esgotadas
1ª) O sistema verifica se para o dia informado, as reservas estão esgotadas. O

sistema deve possibilitar que seja informada nova data ou que se encerre a
solicitação de reserva.
Alternativa: Cliente não cadastrado
4ª) Se o cliente não for cadastrado: Extend Cadastrar Cliente de Reserva

(Extend é um tipo de relacionamento que explicarei mais adiante).
Não existe um padrão da UML que determine uma forma única de se

escrever casos de uso. As ações podem ser descritas em parágrafos ou através
de enumerações, identificadas (por letras ou números) ou não. Outra forma é
criar um texto com seções de pré e pós-condições. É possível, ainda, escrever
o caso de uso como um pseudocódigo. O importante é que cada caso de uso
deve relacionar o suficiente para seu entendimento e que seja compreensível
para todos os envolvidos no processo de desenvolvimento.
14
Relacionamentos entre casos de uso e atores
Os casos de uso representam conjuntos bem definidos de

funcionalidades do sistema, que não podem trabalhar sozinhas no contexto do
sistema. Portanto, esses casos de uso precisam se relacionar com outros casos
de uso e com atores que enviarão e receberão mensagens destes.
Relacionamentos entre casos de uso: generalização/herança,

extensão e inclusão.
Relacionamentos entre atores: generalização/herança
Relacionamentos entre atores e casos de uso: associação
15
Associação
Representa a interação do ator com o caso de uso, ou seja, a

comunicação entre atores e casos de uso, por meio do envio e recebimento de
mensagens.
As associações entre casos de uso são sempre binárias, ou seja,

envolvem apenas dois elementos. Representam o único relacionamento
possível entre atores e casos de uso.
Por exemplo: O ator Correntista envia e recebe mensagens do Caso de

Uso Calcular Empréstimo Pessoal, por um relacionamento de associação.
Figura 2-4: Relacionamento de associação entre atores e use case

A representação gráfica de uma associação corresponde a uma linha
sólida, ligando o caso de uso ao ator e vice-versa.
16
Generalização
Ocorre entre casos de uso ou entre atores. É considerado quando temos

dois elementos semelhantes, mas com um deles realizando algo a mais.
Costuma ser comparado ao relacionamento de extensão, com uma variação do
comportamento normal sendo descrita sem muito rigor. Segue o mesmo
conceito da orientação a objetos. Podemos dizer também que este
relacionamento é conhecido como herança.
Vejamos a representação deste relacionamento:
Um relacionamento de generalização é representado graficamente pela

seta de generalização, que corresponde a uma linha sólida com uma
única seta fechada, mas não preenchida em uma das pontas. A seta
parte do caso de uso mais específico em direção ao mais genérico.
Por exemplo: num caso de uso no qual C2 herda de C1, significa dizer
que temos C1como um caso de uso mais genérico e C2 mais específico.
Figura 2-5: Generalização entre casos de uso
17
Por exemplo: podemos criar um ator generico Aluno e especializá-lo

nos atores Aluno Matriculado e Aluno Ouvinte.
Figura 2-6: Gerneralização entre atores
18
Extensão (extends)
Um relacionamento de extensão entre casos de uso indica que um deles

terá seu procedimento acrescido, em um ponto de extensão, de outro caso de
uso, identificado como base. Os pontos de extensão são rótulos que aparecem
nos cenários do caso de uso base. É permitido colocar diversos pontos de
extensão num mesmo caso de uso, inclusive repetir um mesmo ponto de
extensão. No corpo do caso de uso representamos a extensão com o termo
Extend seguido do ponto de extensão.
Figura 2-7: Relacionamento de extensão (extend)
Por exemplo:
Cenário Principal
...
5. Escolher forma de pagamento.
6. Se cliente VIP, calcular desconto especial. Extend (desconto ClienteVip).
...
Você deve estar se perguntando: Como e quando usar um

relacionamento de extensão? Um caso de uso de extensão é muito utilizado
para:
• expressar rotinas de exceção ou para expressar o desmembramento de um

caso de uso (quando um cenário alternativo possui um fluxo grande ou que
mereça uma atenção especial);
• separar um comportamento obrigatório de outro opcional;
• separar um trecho do caso de uso que será executado apenas em

determinadas condições;
19
• separar trechos que dependam da interação com um determinado ator. Por

exemplo: no cadastro de uma venda, a rotina de desconto só pode ser
executada pelo gerente. Essa rotina pode ser transferida para um caso de uso
de extensão.
Vejamos a representação gráfica:
Um relacionamento de extensão é representado graficamente por uma

seta tracejada com a ponta aberta, que parte do caso de uso estendido e
contém o estereótipo <<extend>>. Junto deste texto é possível colocar
rótulos correspondentes aos pontos de extensão.
Figura 2-8: Relacionaemnto de extensão e inclusão (visto abaixo)
20
Inclusão (Include)
Indica que um deles terá seu procedimento copiado num local

especificado no outro caso de uso, identificado como base. Você deve estar se
perguntando: Quando uso um relacionamento de inclusão? Quando existem
cenários cujas ações servem a mais de um caso de uso. Por exemplo: validar
matrícula é útil para casos de uso como renovar matrícula de aluno, emitir
histórico escolar, lançar notas de provas, entre outros.
Textualmente, um relacionamento de inclusão, dentro da descrição de

um caso de uso base, é representado com o termo Include seguido de seu
nome.
Por exemplo:
Cenário Principal
1. O aluno digita sua matrícula. O sistema verifica se a matrícula é válida e

ativa. Include (Validar Matrícula). (...)
Mais do que evitar a cópia de trechos idênticos, ganhamos tempo de

modelagem e também de implementação ao trabalhar com casos de uso de
inclusão. Perceba ainda que teremos um ganho significativo quando depois
formos fazer a manutenção do sistema.
Veja a representação gráfica deste tipo de relacionamento:
Um relacionamento de inclusão é representado graficamente por uma

seta tracejada com a ponta aberta (este é o símbolo da dependência
também), que parte do caso de uso base e contém o estereótipo
<<include>>.
21
Figura 2-9: Relacionamento de inclusão
Abaixo você tem outro exemplo de um relacionamento de inclusão, onde

um instrutor pode atualizar material didático porém esta atividade irá incluir
outra onde deverá ser definido e registrado uma data para entrega deste
material.
Figura 2-10: Relacionamento de inclusão entre use cases
22
Modelando requisitos com casos de uso
Não existe uma ordem prédefinida que determine quais diagramas

devem ser modelados primeiramente. A ordem é determinada pela preferência
do desenvolvedor e/ou processo que esteja sendo usado. Sabemos que a UML
é independente de processo. Desta forma, o objetivo deste curso não é
apresentar um processo formal para trabalhar com a UML. Entretanto,
presencio a ansiedade vivida por quem inicia a aprendizagem da UML em
conhecer a "ordem dos fatos". Assim, procurarei, em tópicos como este,
orientar sobre um determinado caminho dos muitos que vocês podem
escolher. Pelo menos é um pontapeé inicial!
Alguns desenvolvedores iniciam a modelagem do sistema pela criação

das classes, outros pelos casos de uso. Se este for o caso, é importante tomar
cuidado com os nomes e os verbos utilizados, pois estes transformar-se-ão em
objetos, atributos e métodos. Outros desenvolvedores começam
desenvolvendo o diagrama de casos de uso para fazer o levantamento dos
requisitos do sistema, depois ustilizam alguns diagramas de atividades para
expressar atividades que já existem e que deverão ser consideradas quando
for elaborado o sistema e somente depois deste diagrama partem para a
definição das classes através do diagrama de classes. Aconselho seguir
sempre esta última abordagem pois é melhor levantarmos todos os requisitos
do sistema e documentá-los assim como descobrir e também documentar as
principais atividades do sistema antes de començar a modelar as classes. O
modelo de classes está bem focado na estrutura interna do software a ser
desenvolvido e quando estamos levantando requisitos bem como as atividades
não estamos ainda preocupados com isto. Neste curso iremos adotar esta
abordagem.
Todos os casos de uso possuem nomes que os identificam e diferenciam

dos demais. Segundo a UML corresponde a uma seqüência de caracteres
(letras, números e a maioria dos sinais de pontuação), exceto os dois-pontos,
que são usados no nome do caminho (com o nome de seu pacote).
Normalmente são breves expressões representando a essência do que

você está modelando. Pode-se iniciar a modelagem a partir da descoberta de
uma lista de casos de uso ou uma lista de atores. Certo é que a partir de um
deles é possível chegar ao outro.
Veja por exemplo:
Dado um caso de uso descobrimos seus atores a partir de vários

questionamentos. Um deles seria: "Quais atores são responsáveis por esse
caso de uso?"
23
Dado um ator, descobrimos casos de uso a partir de vários

questionamentos. Alguns deles seriam: "Quais casos de uso são
responsabilidades desse ator?" "Os atores precisam interagir com quais casos
de uso?"
Antes de identificar o ator é importante identificar seus papéis. Uma vez

identificados os casos de uso, devemos nos concentrar em descrever os
cenários principais. A partir dos cenários principais, identificamos e
descrevemos os cenários alternativos. É comum durante a descrição
percebermos a necessidade de cenários comuns a outros casos de uso.
Estamos comecando a descobrir os casos de inclusão. Da mesma forma, casos
de uso muito extensos, seja quanto ao cenário principal ou quanto aos
cenários alternativos, devem ser divididos em casos de extensão.
Os casos de uso possuem um enfoque conceitual dentro da modelagem

em UML. A implementação de um caso de uso ocorre através dos diagramas
de interação (estes serão estudados mais adiante no curso)
24
Casos de uso e pacotes
Em sistemas de media/alta complexidade é comum termos dezenas de

casos de uso. Nesse caso, a representação de todos eles em um único
diagrama é uma tarefa impossível. A fim de minimizar a visualização e,
principalmente, organizar esses casos de uso considerando uma mesma
abordagem conceitual, podemos trabalhar com pacotes. Um pacote
corresponde a um agrupamento de qualquer elemento de modelo, como casos
de uso, classes, estados, outros pacotes, etc.
Graficamente, o pacote é representado como um grande retângulo com

um pequeno retângulo como uma aba posicionada no topo do seu lado
esquerdo - algo como o ícone que representa uma pasta. O nome do pacote
deve ser exibido na aba caso seu conteúdo seja mostrado. Caso contrário, o
nome do pacote deve vir no seu interior.
Figura 2-11: Representação de pacote exibindo os casos de uso
Quando desejamos fazer referenda a um elemento que pertença a algum

pacote, devemos usar a nomenclatura <nome do pacote> seguido de :: e
<nome do elemento>.
pacote:: elemento
25
Por exemplo:
Controle Acadêmico:: Cadastrar Aluno
Os elementos de um pacote devem ter nomes distintos dentro do mesmo

pacote. Todavia, é possível termos elementos com o mesmo nome desde que
residentes em pacotes diferentes.
Figura 2-12: Representação de um pacote sem os casos de uso
26
Quando Utilizar Casos de Uso
Muitas vezes nos perguntamos quando usar isto tudo, inicialmente pode
parecer um pouco burocrátivo e não necessário este processo todo, mas
veremos ao passar do tempo que ele é fundamental para uma boa análise.
Não consigo imaginar, no momento, uma situação na qual não utilizaria

casos de uso. Eles são uma ferramenta essencial na captura de requisitos e no
planejamento e controle de um projeto iterativo. A captura de casos de uso é
uma das tarefas básicas na fase de elaboração.
A maioria dos seus casos de uso será gerada durante está fase do
projeto, mas você descobrirá mais a medida que avança. Fique alerta a eles o
tempo todo. Cada caso de uso é um requisito em potencial, e até que você
tenha capturado um requisito, você não pode planejar como lidar com ele.
Algumas pessoas, primeiro, listam e discutem os casos de uso, então

fazem um pouco de modelagem. Também descobri que, fazendo modelagem
conceitual com os usuários, ajuda a revelar casos de uso. Portanto, tendemos a
fazer casos de uso e modelagem conceitual ao mesmo tempo.
E importante lembrar que casos de uso representam uma visão externa

do sistema. Como tal, não espere nenhuma correlação entre eles e classes
dentro do sistema.
Quantos casos de uso você deve ter? Não existe uma resposta exata
para isto. Depende do tamanho do sistema e também dependerá da equipe e
tipo de sistema que está sendo feito. Lembre-se que você terá vários cenários
e que em cada cenário podem existir vários casos de uso e um caso de uso
pode ter casos alternativos. Com isto você já viu que o número de casos de
uso será medido pelo seu bom senso de modelagem e que você deverá fazer
quantos achar necessário para levantar todos os requisitos. Não tem um
número e nem uma fórmula para calcular isto.
27
Exemplos de descrição textual
Abaixo você tem dois exemplos de descrição textual para use-cases.
Use Case: Criar repositório para material
Atores:
- Gerente
Cenário principal de Sucesso ( Perfeito ):
1 - Gerente fornece usuário e senha para login

2 - Sistema valida usuário e senha
3 - Sistema redireciona Gerente para sua página home
4 - Gerente seleciona no menu a opção para criar repositório
5 - Sistema redireciona o Gerente para uma tela de criação do repositório
6 - Gerente seleciona em uma lista o curso para o qual quer criar repositório
7 - Gerente seleciona em uma lista de instrutores habilitados o responsável
pelo material
8 - Gerente informa data prevista de entrega para o material
9 - Gerente confirma a criação do repositório
10 - Sistema valida os dados da interface fornecidos pelo Gerente
11 - Sistema envia email para o Instrutor comunicando que o repositório foi
criado
Cenários alternativos ( Exceções ):
2a: Sistema não consegue validar usuário e senha:

1 - Sistema avisa o Gerente através de uma mensagem na tela e solicita
novamente
o login e senha para novamente validar. Validar no máximo 3
vezes o usuário e
senha. Se não for possível validar então bloquear a conta deste
usuário.
10a: Erro ao validar dados da tela, falta preencher campos ou as informações

estão em formato incorreto.
1 - Sistema sinaliza o campo com problema e solicita correção.
28
Use Case: Entrega do material didático
Atores:
- Instrutor
Cenário principal de Sucesso ( Perfeito ):
1 - Instrutor acessa o sistema com seu usuário e senha

2 - Sistema valida o usuário do Instrutor e redireciona para uma página home
3 - Instrutor seleciona o link para envio do material didático no menú do
sistema
4 - Instrutor fornece os arquivos que fazem parte do material didático em um
formulário para
seleção de arquivos
5 - Sistema recebe os arquivos e os salva no repositório do banco de dados
6 - Sistema confirma para o Instrutor de que o envio foi feito com sucesso
7 - Sistema envia uma confirmação por email para o Instrutor informando da
entrega
8 - Sistema envia um aviso por email para o Gerente de que o material foi
entregue
Cenários alternativos ( Exceções ):
2a: Sistema não consegue validar usuário e senha:

1 - Sistema avisa o Instrutor através de uma mensagem na tela e solicita
novamente
o login e senha para novamente validar. Validar no máximo 3 vezes
o usuário e
senha. Se não for possível validar então bloquear a conta deste
usuário.
4a: Sistema detecta a falta de um ítem do material didatico.

1 - Sistema avisa qual ítem (apostila, slides, setup, instruções) falta e
solicita ao
Instrutor para fornecer este item. Se não houver este ítem o Instrutor
deve sinalizar
selecionando uma opção
29
Exercícios
1 – Brevemente descreba quais são os objetivos bem como em qual

momento devemos utilizar o diagrama de use case.
2 – O texto abaixo é um descritivo para um sistema de controle de

material didático em uma empresa de treinamento. Você deve ler o texto e
montar um diagrama de use case que represente as funcionalidades bem
como os papéis/atores que podem executar cada uma delas. Não se preocupe
ainda com classes, estas serão levantadas e modeladas mais adiante. Dica:
Não se detenha inicialmente nos tipos de relacionamentos entre os elementos,
concentre-se nos use cases e no ator que pode executa-los, deixe para no final
uma segunda passade de olhos para identificar possíveis relacionamentos.
Descrição do sistema:
Objetivo:
Desenvolver um sistema para controle de material didático dos cursos

realizados em uma empresa de treinamento.
Perfis de usuários:
Gerente de Treinamento, Instrutores, Assistente Administrativo e

Responsável pelo Suporte ao Treinamento.
Telas do sistema:
1) Criação do repositório para o material didático;

2) Instrutor fornece a data prevista para entrega do material didático;
3) Instrutor entrega material didático via o sistema;
4) Instrutor solicita alteração do material didático;
5) Manutenção do repositório: alteração do responsável pelo mesmo;
6) Bloquear acesso de um usuário ao sistema.
Descrição da necessidade:
Fazem uso deste sistema instrutor, assistente administrativo,

responsável pelo suporte ao treinamento e o gerente de treinamento da
empresa. Os grupos de usuários devem acessar o mesmo a fim de alimentar e
buscar informações sobre o material didático dos treinamentos. O gerente de
30
treinamento deve acessar o sistema (com usuário e senha) a fim de criar um

repositório para o material didático de um determinado curso, o qual deverá
ser fornecido por um instrutor. Todo curso da empresa terá um material
didático e um instrutor responsável por ele. O material didático é composto
por: arquivo texto compactado da apostila, arquivo compactado com os slides
do curso, arquivo compactado com uma documentação relatando o tipo de
equipamentos necessários para realizar o curso, softwares necessários bem
como o procedimento de instalação dos mesmos nos respectivos
equipamentos, arquivo compactado com o setup do curso (arquivos, scripts,
imagens e informações de como deve ser instalado este setup em cada
estação de trabalho dos alunos). A criação de um repositório para o material
didático de um curso será feita pelo gerente de forma que o instrutor possa
acessar o sistema e enviar os arquivos que compõe este material didático.
Existe uma checagem automática do sistema no momento que o instrutor está
enviando os dados do material didático para que o mesmo forneça ao menos o
arquivo da apostila, os slides do curso e o documento de configuração do
ambiente contendo os equipamentos e procedimentos necessários para
instalação dos softwares. Caso o instrutor não forneça estes três arquivos
mencionados acima, será avisado pelo sistema na hora do envio e o
procedimento será cancelado. Aqueles itens que não fizerem parte do material
didático de um curso devem ser marcados na hora de submeter o material
pelo instrutor como não existente para aquele curso. O instrutor ao acessar o
sistema visualizará uma lista de cursos dos quais ele é o responsável pelo
material didático, bem como um indicativo de quais itens deste material
didático já foram entregues e quais ainda faltam. Uma vez submetido, caso
seja necessário atualizar ou alterar algum dos itens do material, o instrutor
deverá solicitar ao gerente que libere o acesso para alteração do mesmo, uma
vez que logo após os arquivos serem enviados o material didático será
bloqueado para alteração e isto será possível somente através da liberação do
gerente. Quando for feita esta solicitação para alteração do material didático, o
instrutor deverá fornecer uma nova data prevista de entrega do mesmo, bem
como deverá ser informado o motivo da alteração. O motivo será julgado pelo
gerente que irá decidir se libera ou não o acesso ao material. Isto é feito por
questão de segurança e também para controle de versões de apostilas a fim
de evitar que pequenas alterações gerem uma nova versão sem necessidade.
Todo o material que for entregue provocará um arquivamento a título de
histórico da versão anterior do mesmo, bem como irá disparar um aviso ao
assistente administrativo de que o material deve ser substituído na gráfica
para impressão. Neste módulo de interação com o usuário o sistema também
deve permitir que o instrutor possa sugerir nomes de cursos a serem
montados sendo que estes serão recebidos e avaliados pelo gerente de
treinamento. No momento de criação do repositório para o material didático
deverá ser definida uma data prevista para entrega do material. Uma vez
fornecida a data o instrutor não mais poderá alterá-la. O sistema deverá
possuir um mecanismo de alertas para que o instrutor seja lembrado com 15 e
5 dias de antecedência da entrega do material didático do curso. Sempre no
momento de criação de um repositório para material didático de um curso, o
instrutor deve ser alertado pelo sistema de que o mesmo foi criado.
31
O gerente de treinamentos deverá acessar o sistema e terá a sua

disposição as seguintes funções: criar repositório para o material didático de
um determinado curso, adicionar instrutor, assistente administrativo e
responsável pelo suporte ao sistema, liberar acesso ao material didático para
um determinado instrutor, definir o modelo de material didático para os
cursos, transferir a propriedade de um material didático de curso de um
instrutor para o outro, verificar materiais didáticos de cursos que foram
entregues pelos instrutores, emitir relatórios diversos (listados mais abaixo) e
bloquear acesso de um instrutor ao sistema.
Funções disponíveis para o gerente do sistema:
Criar repositório para setup: cada curso possui um material didático e o

sistema deverá permitir ao gerente criar o repositório para o mesmo, remover
ou trocar a propriedade deste material didático. O material didático é
composto por uma série de elementos citados anteriormente e que devem ser
fornecidos pelo instrutor quando o mesmo acessar o sistema para enviar o
material.
Manter instrutores, assistente administrativo e responsável pelo suporte

aos laboratórios no sistema: deverá ser possível criar, deletar e alterar contas
destes perfis. Os usuários podem querer atualizar o seu endereço de e-mail ou
telefone.
Enviar modelo de material didático para o instrutor: o sistema deverá ser

capaz de permitir com que o gerente possa liberar o material didático de
modelo do curso para o instrutor fazer o download do mesmo.
Definir o modelo de material didático para os cursos: o gerente pode

adicionar ao sistema um modelo de material didático para os cursos da
empresa.
Verificar materiais didáticos entregues: ao acessar o sistema o gerente

irá visualizar os últimos materiais didáticos de cursos que foram submetidos
pelos instrutores os quais necessitam ser revisados para uma possível
aprovação. Logo após a ação do gerente o sistema deve mandar um e-mail
para o instrutor informando se o mesmo foi ou não aprovado. Caso não tenha
sido aprovado consta no e-mail o motivo da rejeição.
Emitir relatórios: o gerente pode emitir os seguintes relatórios:

1. listagem de cursos com o material didático aprovado;
2. listagem de cursos com o material didático não aprovado e
que estejam sendo aguardados;
3. listagem de instrutores com os seus respectivos cursos;
4. listagem dos últimos materiais didáticos alterados em lista
cronológica inversa.
32
Bloquear acesso de um usuário: poderá ser bloqueado o acesso de um

usuário (instrutor, assistente administrativo ou responsável pelo suporte ao
treinamento) ao sistema, a fim de garantir segurança do mesmo. Isto deve
acontecer mais freqüentemente para instrutores pois estes tem mais
rotatividade.
No momento de cadastro de um instrutor devem ser fornecido os

seguintes dados do mesmo: nome completo, telefones de contato, e-mail, área
de atuação. Os mesmos dados devem ser fornecidos quando for cadastrado os
demais perfis do sistema.
33
34
3. Diagrama de Atividades
1
Diagrama de Atividades
Objetivos
 Compreender o diagrama de atividades
 Aprender como desenvolver um diagrama de atividades
 Saber quando utilizar o diagrama de atividades
2
Definição do diagrama
Conforme escrevi no capítulo anterior, acredito que este diagrama pode

ser utilizado logo depois de fazermos uso do diagrama de casos de uso. Nem
sempre você fará um diagrama de atividades, isto irá depender da análise que
você está fazendo, se você de fato julgar necessário representar alguma
atividade que esteja envolvida no sistema e que irá lhe ajudar a entender e
documentar alguma parte importante, este diagrama será útil.
Diagramas de atividades são uma das partes mais inesperadas de UML.

Ao contrário da maioria das outras técnicas da UML, diagramas de atividades
não têm origens claras nos trabalhos anteriores dos três amigos. Ao contrário,
o diagrama de atividades combina idéias de várias técnicas: os diagramas de
eventos de Jim Odell, técnicas de modelagem de estado SDL, modelagem de
workflow e redes de Petri. Estes diagramas são particularmente úteis em
conexão com workflow e na descrição de comportamento que tem muito
processamento em paralelo.
Um diagrama de atividades é um caso especial do diagrama de estados

no qual todos (ou pelo menos a maioria) os estados são ações ou
subatividades e no qual todas (ou pelo menos a maioria) as transições são
disparadas pela conclusão de ações ou subatividaes nos estados de origem.
Este diagrama tem por propósito focalizar um fluxo de atividades que ocorrem
internamente em um processamento, dentro de um período de tempo.
3
Elementos do diagrama
Neste item iremos estudar os elementos que compõe o diagrama de

atividades para depois construir um diagrama. Os elementos são simples e
fáceis de representar. Você perceberá que muitos deles são parecidos com
aqueles que você estava acostumado a utilizar nos fluxogramas.
4
Atividade
Na figura abaixo se pode ver o símbolo de uma atividade, este símbolo é

o estado de atividade, ou simplesmente atividade. Uma atividade é um
estado de estar fazendo algo: tanto um processo de mundo real, tal como
datilografar uma carta, ou a execução de uma rotina de software, tal como um
método em uma classe.
Figura 3-1: Representação da atividade
O diagrama de atividades descreve a seqüência de atividades, com

suporte para comportamento condicional e paralelo. Um diagrama de
atividades é uma variante de um diagrama de estados no qual a maioria, se
não todos, dos estados é estado de atividade. Portanto, muito da terminologia
segue a mesma terminologia de diagrama de estados.
5
Início do diagrama
O início do diagrama de atividades é marcado com um sinal de um

círculo preenchido. Este símbolo é o mesmo para o diagrama de estados. Veja
abaixo o símbolo gráfico:
Figura 3-2: Representação gráfica do início do diagrama de atividades
6
Fim do diagrama
Assim como para indicar o início do diagrama de atividades há um

símbolo para indicar o fim deste diagrama e este símbolo é utilizado tanto para
o diagrama de atividades como para o diagrama de estados. A representação é
um cículo preenchido com um circulo contornando o mesmo. Veja abaixo o
símbolo gráfico:
Figura 3-3: Representação gráfica do fim do diagrama de atividades
7
Transições
Para ligar as atividades e indicar a seqüência utilizamos flexas que

representam as transições entre as atividades bem como a transição entre o
início e a primeira atividade, bem como das atividades para o fim do diagrama.
Veja abaixo a representação gráfica juntamente com outros itens do diagrama.
Figura 3-4: Representação gráfica das transições no diagrama de atividades
8
Desvios
Comportamento condicional é delineado por desvios (branches) e

intercalações (merges).
Um desvio (branch) é uma transição de entrada única e várias

transições de saída guardadas. Somente uma transição de saída pode ser
tomada, de modo que os guardas devem ser mutuamente exclusivos. A
utilização de [else] como um guarda indica que a transição "else" deverá ser
usada se todos os outros guardas do desvio forem falsos. Veja na figura abaixo
a representação gráfica de um desvio (branch):
Figura 3-5: Representação gráfica de um desvio (branch)
9
Uma intercalação (merge) tem múltiplas transições de entrada e uma

única saída. Um merge marca o final de um comportamento condicional
iniciado por um branch. Veja abaixo a representação gráfica:
Figura 3-6: Representação gráfica de uma intercalação (merge)
Você não precisa mostrar explicitamente o losango para desvios e

intercalações. Um estado de atividade, como qualquer estado, pode ter
múltiplas transições de saída guardadas e múltiplas transições de entrada. Use
o losango se você quiser deixar claros os desvios e as intercalates em um
diagrama.
Abaixo temos outro exemplo de um diagrama de atividades completo

para representar a atividade de entrega de um material didático.
10
Figura 3-7: Diagrama de atividades para entrega de um material didático
11
Separação e União
Comportamento paralelo é indicado por separação (Forks) e uniões

(Joins). Iremos agora ver este tipo de elemento pertencente ao diagrama de
atividades.
Uma separação (Fork) tem uma transição de entrada e várias

transições de saída. Quando uma transição de entrada é acionada (triggered),
todas as transições de saída são executadas em paralelo. Veja o diagrama
abaixo:
Figura 3-8: Representação de Fork e Join
O diagrama mostra que as atividades de “Carregar texto” e “Exibindo

texto” podem ocorrer em paralelo. Essencialmente, isso significa que a
seqüência entre elas é irrelevante. Essas atividades também podem ser
executadas intercaladamente. Por exemplo, uma parte do texto é carregada e
então é exibida, depois carrega-se outra parte do texto a a exibe. Também
estas atividades podem acontecer em paralelo, de forma que as duas serão
executadas exatamente ao mesmo tempo, mas sabemos que para este
12
exemplo dado acima isto não é possível. Não podemos carregar e ao mesmo
tempo exibir as informações.
O diagrama de atividades permite que você escolha a ordem em que faz

as coisas. Em outras palavras, ele simplesmente determina as regras
essenciais de seqüência que você deve seguir. Esta é a diferença-chave entre
um diagrama de atividades e um fluxograma: os fluxogramas são
normalmente limitados a processos sequenciais, enquanto que os diagramas
de atividades podem lidar com processos paralelos.
Isso é importante para modelagem de negócios. Os negócios tem,

frequentemente, processos não necessariamente seqüenciais. Uma técnica
como esta que encoraja comportamento paralelo é valiosa nestas situações
porque ela encoraja as pessoas a se afastarem de seqüencias desnecessarias
nos seus comportamentos e a identificar oportunidades para fazer coisas em
paralelo. Isso pode melhorar a eficiência e o retorno de processos de negócio.
Os diagramas de atividades também são úteis para programas

concorrentes, uma vez que você pode projetar graficamente quais caminhos
(threads) você tem e quando eles precisam ser sincronizados. Quando você
tem comportamento paralelo, precisa sincronizar. Não podemos liberar a
edição do arquivo até que ele seja completamente carregado. Mostramos isso
com a união (join) antes da atividade “Liberar edição do arquivo”.
Com a união (join), a transição seguinte é efetuada somente quando

todos os estados nas transições de entrada tenham completado suas
atividades.
Separação e união devem se completar. No caso mais simples, isso

significa que toda vez que você tiver uma separação, deve ter uma união que
una os threads iniciadas por aquelas separações. (Esta regra vem do fato de
que um diagrama de atividades é, atualmente, uma forma de diagrama de
estados).
Entretanto, existem várias extenções para esta regra.
Um thread que sai de uma separação pode abrir-se em uma nova

separação, com os novos threads juntando-se antes de alcançar a união
da primeira separação.
Se um thread saindo de uma separação vai direto para outra separação,

você pode remover a segunda separação e somente ter os threads da
segunda separação saindo da primeira separação. De modo semelhante,
se uma união vai direto para uma outra união, você pode eliminar a
primeira união e ter as threads indo direto para a segunda. Isso é uma
forma de simplificar o diagrama; ela tem o mesmo significado semântico
como se as separações e uniões extras estivessem lá.
13
Existe uma exceção para a regra de que todos os estados de entrada em

uma união devem ter terminado suas atividades, antes que a união possa ser
efetuada. Você pode acrescentar uma condição para um thread saindo de uma
separação. O resultado é um thread condicional. Durante a execução, se a
condição de um thread condicional for falsa, este thread e considerado
completado no que diz respeito a união. Veja na figura abaixo um exemplo:
Figura 3-9: Representação de uma thread que pode não ser realizada
14
Estado de subatividade
Um estado de subatividade indica que quando este é iniciado, o gráfico

de atividade aninhado a ele é executado como um gráfico de atividade
independente. O estado de subatividade não é finalizado até que o estado final
do gráfico aninhado seja alcançado, ou quando eventos disparadores ocorrem
em transições vindas de fora do estado de subatividade. Visto que estados em
gráficos de atividade não tem normalmente eventos disparadores, estados de
subatividade são normalmente finalizados quando seus gráficos aninhados são
terminados. Um gráfico de atividade simples pode ser invocado por muitos
estados de subatividades.
Um estado de subatividade é mostrado graficamente da mesmo forma

que um estado de ação, adicionando apenas um ícone no canto direito inferior
representado um diagrama de atividades aninhado. O nome da subatividade é
colocado dentro da figura. A subatividade não necessita ser única dentro do
diagrama.
Figura 3-10: Representação de um estado de subatividade
15
Concorrência Dinâmica
Concorrência dinâmica permite que você mostre interações sem que

tenha que construir um ciclo (loop). Na figura abaixo, a atividade gravar
arquivo é executada uma vez para cada arquivo recebido. O marcador de
multiplicidade (*) indica que a atividade é executada muitas vezes. A transição
para Bloquear material didático é executado somente quando todos os
arquivos tiverem sido gravados.
Figura 3-11: Representação de uma atividade concorrente
16
Raias (Swimlanes)
Os diagramas de atividades dizem o que acontece, mas não dizem quem

faz o que. Em programação, isso significa que o diagrama não representa qual
classe é responsavel para cada atividade.
Em modelagem de domíno, isso significa que o diagrama não representa

que pessoas ou departamentos são responsáveis por cada atividade. Uma
solução, aqui, é rotular cada atividade com a classe ou pessoa responsável.
Isso funciona, mas não oferece a mesma clareza que os diagramas de
interação (estudaremos mais tarde) para mostrar a comunicação entre objetos.
Raias são uma solução para isso. Para usar raias, você deve organizar
seus diagramas de atividades em zonas verticais separadas por linhas. Cada
zona representa as responsabilidades de uma classe especifica ou, um
departamento específico.
As raias são úteis porque elas combinam a descrição de lógica do

diagrama de atividades com a descrição de responsabilidade do diagrama de
interação. Entretanto, elas podem ser difíceis de serem projetadas em um
diagrama complexo. Veja abaixo a representação das rais.
Figura 3-12: Diagrama de atividade com raias
17
Quando Utilizar Diagramas de Atividades
Como a maioria das técnicas de modelagem comportamental, os

diagramas de atividades tem qualidades e fraquezas definidas, por isso a
melhor maneira de usá-los é em combinação com outras técnicas.
A maior qualidade dos diagramas de atividades está no fato de que eles

suportam e encorajam comportamento paralelo. Isso os torna uma grande
ferramenta para modelagem de workflow, e, em princípio, para programação
concorrente. A maior desvantagem destes diagramas é que eles não deixam
muito claras as ligações entre ações e objetos.
Você pode definir uma ligação para um objeto rotulando uma atividade
com um nome de objeto ou usando raias que dividem um diagrama de
atividades em base em responsabilidades, mas isso não tem a clareza simples
de diagramas de interação (estudaremos estes diagramas mais adiante no
curso). Por esta razão, algumas pessoas sentem que diagramas de atividades
não são orientados a objetos e, portanto, são maus.
A técnica pode ser muito útil nas seguintes situações:
Analisando um caso de uso. Neste estágio, não estou interessado em

alocar ações aos objetos; eu preciso simplesmente compreender que
ações precisam acontecer e quais são as dependências
comportamentais.
Compreendendo o workflow. Mesmo antes de iniciar os casos de uso,

acredito que os diagramas de atividades são muito úteis para
compreensão de um processo de negócio. Posso, facilmente, projetar
estes diagramas junto com especialistas do negócio para compreender
como o negócio funciona e como ele pode mudar.
Descrevendo um algoritmo seqüencial complicado. Neste caso, um

diagrama de atividades não é nada mais do que um flowchart em
notação UML. Os prós e contras comuns de flowcharts se aplicam aqui.
Lidando com aplicações de processamento paralelo. Este tipo de

diagrama, como já foi mostrado pode ser utilizado para demonstrar
atividades que devem ou podem acontecer em paralelo.
18
Não use diagramas de atividades nas seguintes situações:
Tentando ver como os objetos colaboram. Um diagrama de interação é

mais simples e lhe dá uma visão mais clara das colaborações.
Tentando ver como um objeto se comporta durante o sen ciclo de vida.

Use um diagrama de estados para isso (Estudaremos mais adiante no
curso).
19
Exercícios
Utilizando a ferramenta para modelagem de diagramas UML

faça:
1 – Para o diagrama de atividades da figura 18 monte um diagrama de

atividades com raias destacando assim quais são os papeis que executam
determinada atividade
2 – Construa um diagrama de atividades para descrever o processo de

solicitação de autorização para uma revisão no material didático.
20
21
22
4. Diagrama de Classes
1
Diagrama de Classes
Objetivos
 Estudar os tipos de associações que fazem parte deste diagrama
 Saber utilizar o escopo e visibilidade para os atributos e operações
 Aprender quando se deve utilizar este diagrama
 Modelar um diagrama de classes
2
Diagrama de Classes
Introdução
Depois de termos estudado dois diagramas pertencentes à UML e que

podem nos auxiliar no levantamento de requisitos bem como na descrição das
principais atividades envolvidas no processo do software, vamos agora estudar
o diagrama de classes. Este é um diagrama muito importante para a
modelagem oriendada a objetos utilizando UML. Posso dizer que é obrigatória
a sua modelagem em função do mesmo demostrar os componentes que fazem
parte do software destacando as suas operações e atributos.
A técnica de diagrama de classes tornou-se realmente central nas

metodologias orientadas a objetos. Praticamente, cada metodologia incluiu
algumas variações nesta técnica. O diagrama de classes não é somente
amplamente usado, mas também o receptáculo para o maior escopo de
conceitos de modelagem. Embora os elementos básicos sejam necessários
para todos, os conceitos avançados são utilizados com menos freqüência.
Um diagrama de classes descreve os tipos de objetos no sistema e os

vários tipos de relacionamento estático que existem entre eles. Há dois tipos
principais de relacionamento estático:
associações (por exemplo, um cliente pode alugar vários vídeos)

subtipos (uma enfermeira é um tipo de pessoa)
Diagramas de classes também mostram atributos e operações de uma

classe e as restrições à maneira com que os objetos são conectados. Veja
abaixo um exemplo de diagrama de classes que iremos estudar
detalhadamente neste curso.
3
Diagrama de Classes
4
Diagrama de Classes
Figura 4-1: Representação típica de um diagrama de classes
5
Diagrama de Classes
Perspectivas
Antes de começar a descrever diagrama de classes, temos que

mencionar uma sutileza importante no modo com que as pessoas os utilizam.
Esta sutileza não é comumente documentada, mas tem um impacto na
maneira que você deve interpretar um diagrama, pois se refere muito ao que
você está descrevendo com o modelo.
Existem três perspectivas que você pode usar quando projetar

diagramas de classes ou, de fato, qualquer modelo, mas esta classificação é
mais perceptível em conexão com diagramas de classes.
Conceitual: Se tomar a perspectiva conceitual, você projeta um

diagrama que representa os conceitos no domínio que está sendo
estudado. Estes conceitos serão naturalmente relacionados às
classes que vão executá-los, mas freqüentemente não existe um
mapeamento direto. Na verdade, um modelo conceitual deve ser
projetado com pouca ou nenhuma preocupação com o software
que poderá implementá-lo, portanto ele pode ser considerado
independente de linguagem.
Especificação: Agora estamos examinando o software, mas

estamos analisando as suas interfaces, não a sua implementação.
O desenvolvimento orientado a objeto põe muita ênfase na
diferença entre interface e implementação, mas isto é
freqüentemente negligenciado na prática porque a noção de classe
em uma linguagem OO combina interface com implementação. É
uma pena, porque a chave para uma programação OO eficaz é
programar para uma interface de classe em vez de fazê-lo para
sua implementação. Você ouve com freqüência a palavra "tipo"
para falar sobre uma interface de uma classe; um tipo pode ter
muitas classes que o implementam e uma classe pode
implementar muitos tipos.
Implementação: Nesta visão, realmente, temos classes e

estamos pondo a implementação às claras. Esta é, provavelmente,
a perspectiva usada com mais freqüência, mas, de várias formas, a
perspectiva de especificação é freqüentemente a melhor para ser
usada.
A compreensão das diversas perspectivas é crucial tanto para desenhar

como para ler diagramas de classes. Infelizmente, as linhas entre as
perspectivas não são rígidas, e a maioria dos modeladores não se preocupa
em ter suas perspectivas classificadas quando eles estão modelando. Embora
6
Diagrama de Classes
acredite que isso freqüentemente não afeta muito a perspectiva conceitual e a

perspectiva de especificação, é muito importante separar a perspectiva de
especificação e a perspectiva de implementação.
A perspectiva não é parte da UML formal, mas é considerada

extremamente valiosa na modelagem e na revisão de modelos. UML pode ser
usada com todas as três perspectivas. Ligando classes com um estereótipo
(Iremos estudar mais adiante), você pode dar uma indicação da perspectiva.
Você marca classes como <<classe de implementação>> para mostrar a
perspectiva de implementação, e com <<tipo>> para as perspectivas de
especificação e conceitual.
7
Diagrama de Classes
Criando Diagramas de Classe
O diagrama de classes é a estrela principal de um sistema orientado a

objetos. Nesse diagrama é possível modelar detalhes das classes e seus
relacionamentos. Também são visíveis outros elementos como interfaces e
pacotes.
Diagramas de classes podem ser organizados dentro de pacotes, assim

como um pacote (iremos estudar pacotes mais tarde) pode ser representado
por um ou mais diagramas de classes.
As classes são declaradas no diagrama de classes mas são usadas em

muitos outros diagramas. Uma classe é representada como um retângulo
subdividido em três compartimentos, separados por linhas horizontais que
nessa ordem armazenam:
o nome da classe e outras propriedades gerais da mesma, incluindo

estereótipos;
lista de atributos;
Lista de operações.
Essa divisão corresponde à notação básica dos diagramas de classes.

Entretanto, compartimentos adicionais (não definidos pela UML) podem ser
incluídos e usados como extensões das ferramentas de modelagem, com o
intuito de exibir outras informações do modelo, como por exemplo: regras de
negócio, responsabilidades, exceções, etc. A maior parte desses
compartimentos exibem apenas uma lista de strings, entretanto são possíveis
outros formatos definidos pelas ferramentas.
Figura 4-2: Representação de classe
8
Diagrama de Classes
As normas de estilo da UML determinam que:
o nome da classe seja centralizado e negritado

para todas as linguagens que distinguem entre caracteres minúsculos e
maiúsculos, escrever as iniciais dos nomes das classes em maiúsculas,
inclusive as primeiras letras de nomes compostos
Exemplo: AlunoUniversitario, PessoaFisica, Funcionário, Gerente, Carro,

Curso, Instrutor
os atributos e operações devem ser escritos com formatação normal e

alinhados à esquerda
os nomes de atributos e operações devem iniciar com letra minúscula,
entretanto as iniciais das palavras compostas seguintes devem iniciar
com letra maiúscula
Exemplo: reajustarSalario, matricular, dataNascimento
Como extensão de ferramentas, o negrito pode ser usado para marcar

listas especiais de elementos.
As normas de estilo da UML são importantes para a padronização da

notação da linguagem. Entretanto, às vezes, é comum compatibilizarmos as
normas de estilo da UML com as normas da linguagem com a qual estamos
trabalhando.
A linguagem java, por exemplo, segue o padrão de nomes de classes e

atributos especificado na UML. Os nomes de métodos são somente
modificados de forma a termos a palavra get e set na frente de alguns deles.
Isto é dependente da linguagem de programação e por isto não será estudado
neste curso.
Se necessário, compartimentos podem ser nomeados, cujos nomes

devem ser representados com uma fonte diferente, centralizados no topo do
compartimento.
Figura 4-3: Classe com seus compartimentos nomeados

9
Diagrama de Classes
A UML permite que em algumas visualizações os detalhes sejam

omitidos, isto é, é possível mostrar:
apenas o nome da classe ou

o nome da classe e seus atributos ou
o nome da classe e suas operações
O nome da classe é obrigatório não podemos representar uma classe

sem nome, mas perceba que podemos representar sem atributos e operações.
A grande maioria dos processos de modelagem recomendará que, no

primeiro diagrama de classes desenhado, não façamos o registro de todos os
detalhes das classes. Na realidade, a identificação das classes e seu
detalhamento ocorre gradativamente. No processo de desenvolvimento, deve-
se levar em conta que a versão do diagrama usada na fase de projeto estará
mais completa.
10
Diagrama de Classes
Compartimento do Nome da Classe
O compartimento de nome mostra o nome da classe e outras

propriedades divididas em três seções, contendo as informações conforme
descritas a seguir:
Estereótipos podem ser escritos em estilo normal dentro de guillemets

(<< >>) acima do nome da classe, e/ou um ícone estereótipo pode ser
colocando no canto superior direito do compartimento. Exemplo:
<<type>>;
O nome da classe aparece em seguida, centralizado e em negrito (única
informação obrigatória);
Uma lista de strings indicando propriedades como atributos a nível de
classe e valores de etiqueta são mostrados abaixo do nome da classe,
entre chaves.
Exemplo: { versão = 1.2 }
Figura 4-4: Classe com informações no compartimento de nome
11
Diagrama de Classes
Atributos
Ao definirmos atributos não informamos apenas seu nome ou tipo de

dados. Podemos determinar, também, seu valor inicial, visibilidade e outras
características. A única informação obrigatória é o próprio nome do atributo,
mas conforme a modelagem é refinada, outras características do atributo
tornam-se importantes para o projeto.
A sintaxe default para a definição de atributos é:
visibilidade nome: tipo [ multiplicidade ordering] = valor-inicial {string-

propriedade}
A visibilidade pode ser representada pelas palavras-chaves public,

protected, private ou package (ou por seus ícones +, #, -, ~).
Por exemplo:
private senha: String

+ tamanho: int
O tipo do atributo pode corresponder ao nome de uma classe ou ser um

tipo dependente da linguagem de programação a ser adotada (String acima é
uma classe pois está com a primeira letra maiúscula, já int é um tipo
pertencente a linguagem java). Na maior parte das vezes os atributos
corresponderão a tipos básicos (int, float, boolean). Mas, também podemos
associar tipos definidos pela linguagem de implementação, como por exemplo
Date, Vector, String em Java.
Outra forma de definir o tipo de um atributo é associá-lo a tipos não-

básicos, como uma classe. Por exemplo: um livro pertence a uma editora. Este
relacionamento pode aparecer de duas formas: a primeira consiste numa
associação entre as classes Livro e Editora; a segunda seria colocar um
atributo editora do tipo classe Editora, na classe Livro. Esta última forma
permite um mapeamento direto para as bases de dados, ou seja, é mais usada
na fase de projeto.
Por exemplo:
editora: Editora
12
Diagrama de Classes
A multiplicidade pode ser omitida se corresponder a exatamente 1 (1..1).

Em outros casos pode ser representada dentro de colchetes.
Por exemplo:
telefones: String [0..5]

filhos: Filhos [0..*]
O primeiro exemplo nos diz que uma determinada classe não tem valor
para o atributo telefone ou tem até cinco valores. No segundo exemplo, temos
que uma determinada classe tem de um a três filhos.
A propriedade ordering é relevante se o limite superior da multiplicidade

for superior a 1. Nesse caso, o atributo pode assumir os valores: unordered
(valor também assumido quando a propriedade está ausente) ou ordered,
respectivamente significando que não possuem ou que possuem ordenação.
Por exemplo: vamos supor uma classe CorredorFormula1 que possua um
atributo campeonatos que contenha a lista de temporadas (anos) nos quais ele
foi campeão da Fórmula1. Esse atributo poderia ser modelado da seguinte
forma:
campeonatos: integer [0..* ordering]
que indicaria que um piloto pode nunca ter sido campeão ou já ter sido
campeão de vários (*) campeonatos, sendo que essa lista de anos deve
aparecer ordenada cronologicamente.
O valor-inicial determina o valor inicial do atributo no momento em que o

objeto é instanciado.
Por exemplo:
salario: float = 1350.40

nota1: float = 0
A string-propriedade indica valores de propriedades que se aplicam ao

atributo, como:
changeable: o valor do atributo pode ser modificado, sem restrições.

Corresponde ao default, se nenhuma propriedade for informada.
addOnly: no caso de multiplicidades superiores a 1, indica que podem
ser incluídas novas instâncias, porém estas não podem ser alteradas ou
excluídas.
frozen: após o instanciamento do objeto, o valor do atributo não poderá
ser modificado.
13
Diagrama de Classes
Por exemplo:
identificacaoCliente: int {frozen }

feriasGozadas: String [0..*] {addOnly}
No último caso, o atributo feriasGozadas armazena a lista de períodos de

férias já gozadas pelo funcionário. Mas uma vez cadastrada essa informação,
não deve ser possível alterá-la.
O escopo (visto anteriormente) default corresponde a um atributo de

instância. Para representar um atributo de classe deve-se sublinhar o nome e o
tipo do atributo.
Por exemplo:
Figura 4-5: Classe com um atributo de classe
Temos, ainda, a representação de atributo derivado. Um atributo

derivado é aquele cujo valor é computado a partir de outro(s) atributo(s). Por
ser um valor sempre gerado não teria necessidade de aparecer em forma de
atributo. Todavia sua exibição no diagrama é feita com o intuito de melhorar o
entendimento do modelo ou por propósitos de projeto.
Indica-se graficamente que um atributo é derivado inserindo-se uma

barra (/) à frente do nome do atributo.
Veja por exemplo: a classe BoletimEscolar possui, entre outros, os

atributos: nota1 e nota2. Sabemos que a média é calculada pela divisão por
dois do resultado da soma das notas 1 e 2. Então, para obter a média, basta
que tenhamos as notas 1 e 2. Todavia, deixar essa informação implícita pode
levar a falhas no entendimento do modelo. Assim, modela-se o atributo média,
mas determinando que sua atualização é feita por uma operação de cálculo e
não por uma atribuição, como ocorre com os outros atributos. Veja o exemplo
na figura abaixo:
14
Diagrama de Classes
Figura 4-6: Classe com atributo derivado
Podemos especificar a forma de cálculo de um atributo derivado, fazendo

uso de uma nota ligada ao nome do atributo. Veja o exemplo abaixo:
Figura 4-7: Descrição para atributo derivado
15
Diagrama de Classes
Operações
Da mesma forma que ocorre com os atributos, a modelagem das

operações não se limita a seu nome e parâmetros. A única informação
obrigatória é o próprio nome da operação, mas conforme a modelagem é
refinada, outras características da operação tornam-se importantes para o
projeto.
A sintaxe default para a definição de operações é:
visibilidade nome (lista-de-parâmetros): tipo-de-retorno {string-propriedade}
A visibilidade pode ser representada pelas palavras-chaves public,

protected private ou package (ou por seus ícones +, #, -, ~).
Por exemplo:
private obterSenha: String

+ modificarTamanho (t: int)
A lista-de-parâmetros corresponde a uma lista de parâmetros separada

por vírgula, no qual cada parâmetro deve obedecer a seguinte sintaxe:
escopo-parâmetro nome: tipo = valor-default
O escopo-parâmetro pode assumir os valores:
in: o parâmetro é apenas de entrada, não aceitando modificação.

out: parâmetro apenas de saída, não aceitando leitura.
inout: parâmetro de entrada e saída. Aceita leitura e modificação (default
no caso do escopo ser omitido).
O tipo do parâmetro também é dependente da linguagem de

programação. No caso da linguagem Java todo os parâmetros que forem do
tipo primitivo (exemplo: int, float, boolean, etc.) terão escopo in e todos
aqueles que forem do tipo composto (exemplo: String, Date, Vector, etc.) serão
do tipo inout. Não há, no java, mapeamento para o escopo out.
O valor-default indica um valor que será considerado, caso nenhum valor

seja passado para o parâmetro.
Por exemplo:
calcularMedia(tipo: TipoMedia = Aritmética)
16
Diagrama de Classes
O tipo-de-retorno da operação é dependente da linguagem de

programação a ser adotada. Se nenhum retorno for especificado, estamos
declarando uma operação que não possui retorno (estes conceitos são
análogos a funções e procedimentos). Existem linguagens com o Java que
mesmo quando uma operação não possui retorno nos precisamos indicar o
retorno como sendo void.
O escopo default corresponde a uma operação de instância. Para

representar uma operação de classe deve-se sublinhar o nome e o tipo de
retomo da operação. Por exemplo, a operação emitirListaFrequencia() possui
escopo de classe:
Figura 4-8: Operações com escopo de classe
A string-propriedade indica valores de propriedades que se aplicam à

operação. As semânticas de concorrência (usadas em processos e threads) de
uma operação são especificadas por uma propriedade no formato:
{concorrência = nome}
O nome da concorrência pode assumir os seguintes valores: sequential,

guarded, concurrent. Vejamos, então, as propriedades usadas:
query: indica que a execução da operação não modifica o estado do

objeto. Por exemplo: ao chamarmos a operação emitirListaFrequencia(),
não realizamos qualquer alteração nos dados armazenados. Isto já não
ocorre com a operação reajustarMensalidade que poderíamos ter na
classe.
sequential: a chamada para um objeto precisa ocorrer imediatamente,
de forma completa e perfeita. Se ocorrerem chamadas simultâneas, a
semântica e integridade do sistema não podem ser garantidas.
guarded: múltiplas chamadas de threads concorrentes podem ocorrer
simultaneamente para um objeto, mas somente é permitida a uma delas
iniciar. As outras são bloqueadas até que a execução da primeira
operação esteja completa. Essa responsabilidade pertence ao projetista
do sistema, que deve assegurar que deadlocks não ocorram devido a
blocos simultâneos.
17
Diagrama de Classes
concurrent: múltiplas chamadas de threads concorrentes podem ocorrer

simultaneamente para um objeto. Todas precisam ser executadas
concorrentemente, mantendo correta sua semântica.
Existe uma diferença entre operação e método que necessita ser

relembrada. Uma operação corresponde à definição conceitual do serviço de
uma classe, enquanto que o método corresponde à implementação da
operação.
Por default, uma operação é considerada como não-abstrata, o que

significa que obrigatoriamente deve ter um método que a implemente. Para
indicar que a classe não implementa a operação, esta deve ser marcada como
{abstract} (iremos estudar mais adiante as classes abstratas) ou a assinatura
da operação ser escrita em itálico.
O corpo de um método pode ser mostrado no diagrama de classes por

meio de uma nota ligada à operação. Especificações formais, expressas em
qualquer linguagem, devem ser colocadas entre chaves. Desta forma na nota
iremos colocar o código entre chaves. Perceba que este tipo de situação não é
comum, e na maioria dos diagramas você não irá encontrar isto.
Outro conceito importante é quanto à assinatura da operação, que é

composta do nome da operação, seus parâmetros e o tipo de retorno (se
existir).
Quando não temos o interesse de demonstrar todas as operações iremos

colocar no final da região das operações na representação da classe três
pontinhos, mostrando que há mais operações porém estas não estão sendo
mostradas.
18
Diagrama de Classes
Relacionamentos
As classes dentro do contexto da modelagem de um sistema, na sua

maioria, não trabalham sozinhas. Pelo contrário, elas colaboram umas com as
outras por meio de relacionamentos. No diagrama de classes temos os
relacionamentos de associação, generalização e dependência. Como
variação do relacionamento de associação, ainda é possível modelar
relacionamentos de agregação e composição.
19
Diagrama de Classes
Associação
A associação é um relacionamento que conecta duas (associação binária)

ou mais classes (associação ternária ou de ordem-n), demonstrando a
colaboração entre as instâncias de classe.
A associação binária conecta exatamente duas classes, sendo possível a

associação de uma classe com ela própria. Por exemplo: uma empresa possui
diversos funcionários. Essa é uma associação entre as classes Empresa e
Funcionário. De outra forma, um funcionário tem um chefe que também é um
funcionário, portanto temos uma associação da classe Funcionário com ela
própria. Veja a figura abaixo:
Figura 4-9: Associação entre classes
A associação binaria é representada grafícamente por uma linha sólida

que liga uma classe a outra ou uma classe a ela própria.
Em UML, a associação pode ser de três tipos diferentes: associação

simples; agregação por composição; agregação compartilhada. Visto que a
construção de agregação pode ter diferentes significados dependendo da área
de aplicação, a UML fornece um significado mais preciso para duas dessas
construções (associação e agregação por composição) e deixa a agregação
compartilhada mais livremente definida no meio das outras. Mais adiante
veremos os conceitos de agregação e composição.
Uma associação pode conter adornos que melhoram, em alguns casos, a

compreensão do modelo. Adornos são um tipo de esteriótipos (Veja sobre os
tipos de adorno no apêndice). Todos esses adornos são opcionais e só devem
ser usados quando sua função for plenamente atendida, para não poluir
visualmente o diagrama de classes. Eles devem ajudar a modelagem, não
complicá-la!
20
Diagrama de Classes
Nome da associação
É mostrado próximo à linha do relacionamento, todavia não se deve

colocá-lo próximo às extremidades, pois estas posições pertencem aos nomes
de papéis.
O nome da associação pode ser acompanhado de um pequeno triângulo

preenchido indicando a direção na qual o nome deve ser lido. No exemplo
abaixo o triângulo expressa a leitura da associação como "aluno cursa curso".
.
Figura 4-10: Associação com nome
Para associações binárias, na sua maioria, não é preciso nomear as

associações, pois elas já são auto-explicativas. O nome de associação é mais
usado quando possa haver dúvidas sobre o tipo de associação ou nas
associações que envolvem uma única classe. Já nas associações n-árias seu
uso é mais freqüente. Veja na figura abaixo que usamos o nome pré-requisito
para esclarecer o relacionamento: "Um curso é pré-requisito de outro curso".
Figura4-11: Nome para associação
21
Diagrama de Classes
Multiplicidade
Colocada nas extremidades do caminho da associação, identifica o

número de instâncias de uma classe que pode se relacionar com outra. A
mulplicidade especificada em uma extremidade determina que essa é a
quantidade de instâncias da classe oposta que se relacionará na associação.
Apesar de ser opcional, só deve ser omitida nas primeiras visões do diagrama.
Uma vez que a modelagem avance, determinadas informações são relevantes
para o projeto. Uma delas é a multiplicidade.
Por exemplo: Vamos considerar um curso que possa ter no máximo 10

alunos. Para representar este relacionamento iremos colocar as seguintes
multiplicidades na associação:
Figura 4-12: Multiplicidade na associação
Se fossemos ler o relacionamento acima diríamos que um aluno pode

estar matriculado em pelo menos um curso ou mais, não havendo limite de
cursos. E ainda podemos dizer que um curso contém no máximo 10 alunos.
Se a multiplicidade da associação for superior a um, então os elementos

relacionados podem ser ordenados ou não. Se não incluirmos nenhum adorno
na associação, estaremos determinando que os elementos não são ordenados.
Para determinar a ordenação deve-se incluir a string {ordered}. Essa
declaração não especifica como a ordenação é realizada ou mantida. Essa é
uma responsabilidade das operações que agem sobre as instâncias, demonstra
somente que é ordenado os objetos dentro da coleção que irá conter os
mesmos. Geralmente essa especificação é feita no projeto.
22
Diagrama de Classes
Papel (role)
Colocada nas extremidades do caminho da associação, indica o papel

representado pela classe na associação (veja figura abaixo). Esse nome é
colocado na extremidade do caminho da associação, próximo à classe a que se
refere. De uma forma geral, o nome da classe já identifica o papel dela na
associação, como por exemplo: Curso e Aluno. Todavia, quando temos classes
que podem exercer vários papéis, a transparência diminui. Assim, o nome do
papel passa a ser importante.
Figura 4-13: Papel execido pela classe no relacionamento
23
Diagrama de Classes
Navegabilidade
Uma seta pode ser colocada na extremidade de uma associação

indicando que a navegação é determinada na direção para onde partiu a seta.
As setas podem ser omitidas, colocadas em apenas uma das extremidades ou
em ambas. A navegabilidade quando é omitida indica que a mesma é
desconhecida ou bidirecional.
Se temos a classe Aluno e Curso sem navegabilidade, podemos dizer que

a partir de aluno podemos saber o curso dele, e por outro lado, a partir de um
determinado curso podemos saber quais são os alunos matriculados. Se
indicássemos uma navegabilidade direcionada ao aluno, estaríamos dizendo
que a partir de um aluno não deve ser implementada uma forma de saber seu
curso. Claro que essa não é uma situação perfeita, pois é claro que precisamos
saber o curso de um aluno. A "via de mão dupla" é mais comum na grande
maioria dos relacionamentos de associação. Veja a figura abaixo uma situação
onde o curso sabe quais são os alunos que tem nele mas os alunos não sabem
a quais cursos eles pertencem.
Figura4-14: Associação com navegabilidade
Sabemos que um aluno precisa saber em quais cursos ele está

matriculado, então não iremos em uamsituação real modelar com
navegabilidade somente de Curso para Aluno, mas sim com navegabilidade
para os dois lados. Quando a navegabilidade for para os dois lados, não
precisamos colocar flexas nas extremidades da associação.
24
Diagrama de Classes
Herança/Generalização
Vamos recordar dos conceitos de orientação a objetos que você

aprendeu no curso anterior: a generalização entre classes envolve elementos
mais genéricos e outros mais específicos.
O relacionamento de generalização entre classes é mostrado

graficamente como uma seta fechada e vazada, com seu corpo sólido, que
parte da classe específica em direção à classe mais genérica. Veja abaixo a
representação:
Figura 4-15: Primeira forma de relacionamento de Herança/Generalização entre as classes
25
Diagrama de Classes
Outra forma de representar a Herança/Gerneralização é mostrada

abaixo:
Figura 4-16: Segunda forma de relacionamento de Herança/Generalização entre as classes
Restrições predefinidas podem ser usadas para indicar restrições

semânticas entre as classes filhas. Essas restrições são colocadas entre
chaves, separadas por vírgula e posicionadas próximas à seta do
relacionamento. Uma forma alternativa consiste em colocar uma linha
tracejada atravessando as linhas de relacionamento as quais se referem à
restrição. A restrição, então, é colocada próxima à linha tracejada.
Duas restrições predefinidas para generalização são:
Completo (complete) - todas as subclasses de uma superclasse já

foram especificadas (dentro do contexto do sistema), mesmo que
algumas tenham sido omitidas no diagrama. Não é permitida
nenhuma especialização adicional. Por exemplo:
Superclasse: Pessoa
Subclasses: Física e Jurídica
No caso da superclasse Pessoa, todas as subclasses já foram definidas e se

outras subclasses fossem possíveis, não seriam permitidas suas inclusões.
Superclasse: Funcionário
Subclasses: Vendedor / Auxiliar Administrativo / Gerente
No foco do sistema, estes são os únicos funcionários existentes na

empresa.
26
Diagrama de Classes
Figura 4-17: Representação de uma associação “completo”
Incompleto (incomplete) - determina que nem todas as subclasses

possíveis foram especificadas no modelo, mas que essas inclusões ainda
são permitidas. Por exemplo:
Modelando os animais de um zoológico. Mamífero e Ave não são os únicos

animais, mas no momento a modelagem se restringiu a eles.
Superclasse: Animal
Subclasses: Mamífero / Ave
Supondo o contexto de um sistema acadêmico, percebemos que outras

subclasses da Classe Pessoa podem surgir no futuro, como: Funcionário
Administrativo, Monitor, etc.
Superclasse: Pessoa
Subclasses: Aluno e Professor
27
Diagrama de Classes
Figura 4-18: Incompleto
Para representar o polimorfismo, reescrevemos a operação na

subclasse, ou seja, estamos redefinindo a operação. No exemplo da figura
abaixo demonstramos o relacionamento entre as classes Funcionário, Professor
e Vendedor. A classe Funcionário possui a operação calcularSalario() que
realiza seu cálculo a partir de um salário base. No caso de Professor, a
operação também existe, porém com um método (implementação) diferente -
o cálculo é feito sobre hora-aula. O mesmo ocorre com o vendedor que possui
um salário base mais uma comissão sobre as vendas. Desta forma, redefinimos
as operações, permitindo que os métodos sejam implementados de maneiras
diferentes.
Figura 4-19: Polimorfismo redefinindo uma operação
28
Diagrama de Classes
Dependência
O relacionamento de dependência entre duas classes indica que uma

mudança na interface de uma delas pode causar mudanças na outra.
Existem vários fatores que levam à dependência entre classes. Vejamos

alguns deles:
troca de mensagens entre classes (uma classe chama operações de

outra)
Por exemplo: a classe ProdutoDB é uma classe que possui as operações

para manutenção de produtos em uma tabela de produtos no banco de dados.
Ela necessita da classe Conexao para para fazer este acesso ao banco de
forma que a mesma irá chamar os métodos de abrir conexão, inserir, alterar,
etc. que estão escritos em Conexao. Mudanças na interface dessa classe pode
afetar a classe ProdutoDB. Assim, dizemos que a classe ProdutoDB é
dependente da classe Conexao.
Figura 4-20: Relacionamento de dependência
uma classe tem como atributo outra classe
Por exemplo: uma classe Imóvel possui o atributo Proprietário que é

uma instância da classe Proprietário.
Na assinatura de uma operação, uma classe aparece como parâmetro.
Por exemplo: Na classe Gôndola de um supermercado, vamos supor a

existência da operação ReporProduto (produto_reposicao: Produto). Essa
operação recebe por parâmetro uma instância da classe Produto.
Não representamos sempre todas as dependências, pois essas

características citadas anteriormente já expressam o relacionamento.
29
Diagrama de Classes
Representamos o relacionamento de dependência apenas em casos que a

mesma é implícita.
30
Diagrama de Classes
Agregação
A agregação corresponde a um caso particular da associação (apenas

associações binárias), utilizada para expressar um relacionamento "todo-
parte". A agregação representa uma propriedade fraca, pois uma classe
"parte" pode estar contida em outras agregações.
Vamos primeiro discutir a agregação: quando definimos um

relacionamento de associação, estabelecemos uma ligação entre as classes,
mantendo a independência de vida das mesmas. No contexto de um Sistema
Acadêmico, ao acabar com uma associação entre as classes Curso e Professor,
as classes envolvidas continuam a ter vida própria, com pleno significado. Eu
pergunto "o que é um curso dentro de um Sistema Acadêmico?" ou pergunto
"O que é um professor dentro de um Sistema Acadêmico?". As respostas
provavelmente serão objetivas e explicativas. Mais do que isso, curso pode ser
definido sem depender da existência do professor e da mesma forma professor
pode ser conceituado sem depender da existência do curso.
Agora, vamos pensar em uma página da Web. Uma página é composta

(ou não) de imagens. Uma imagem também é parte de um diretório do Site. E
se eu perguntasse "O que é uma imagem dentro de um Site?". Você poderia
começar respondendo "é uma figura que ilustra uma página" ou "é uma figura
que serve de link em uma página", etc.
Veja que a figura tem um significado que para ser completo está
dependente de outro elemento. É como um verbo transitivo direto ou indireto.
Se eu digo "você acorda", estou me referindo a um verbo intransitivo (que não
pede complemento). Quem acorda, acorda e ponto final. Já se digo: "eu
chamo", fica faltando alguma coisa. Quem chama, chama alguém.
Paralelamente, uma imagem é uma imagem de alguém (ou algo). A página
Web representa o todo enquanto que a imagem representa a parte. Portanto,
nesse caso, podemos modelar o relacionamento entre Página Web e Imagem
como uma agregação. Lembrem-se sempre de que o contexto interfere
diretamente no tipo de relacionamento. Uma imagem não fará sempre parte
de uma agregação - depende do contexto no qual ela está envolvida.
A representação gráfica da agregação consiste em se colocar um

diamante aberto junto à classe agregadora.
31
Diagrama de Classes
Figura 4-21: Relacionamento de agregação
O relacionamento de agregação mostra que um objeto pode estar sendo

referenciado por dois ou mais outros objetos. Na figura acima imagine que um
objeto da classe PaginaWeb “morra” (não seja mais utilizado e pode ser
coletado da memória pelos gerenciadores de memória das linguagens), desta
forma o objeto imagem deve continuar lá e não será removido junto com a
PaginaWeb.
32
Diagrama de Classes
Composição
A composição (ou agregação por composição) é uma variação mais

poderosa da agregação. Passamos a interpretar o relacionamento como um
objeto composto de partes. A diferença consiste no fato de que a classe parte
pertence só e somente só à classe todo, em um determinado momento, não
podendo fazer parte de outro relacionamento de composição. A classe
composta é responsável pela criação e destruição de suas partes. Entende-se,
assim, que uma vez que a classe composta deixe de existir, todas as suas
partes morrem juntas. Observe que é justamento o contrário do
relacionamenro de agregação mostrado acima onde as “partes” continuam a
existir.
Ao definirmos uma classe como parte de uma composição, indicamos

que no relacionamento essa classe perdeu sua identidade, pois é parte
incorporada da outra classe.
Seguindo o exemplo do relacionamento de agregação, vamos pensar em

um frame que representa uma tela de uma aplicação. Imagine que dentro
desta tela temos um botão de pesquisar, perceba que este botão só estará
dentro desta janela não irá estar presente em outras janelas (pelo menos o
mesmo botão). Quando a janela for fechada (morrer) o botão será também
morto, ou seja irá junto com a janela por fazer parte da estrutura da mesma.
Temos, portanto, uma agregação mais forte: uma composição.
Graficamente, é representada por um diamante preenchido junto à classe
composta.
Figura 4-22: Relacionamento de composição
33
Diagrama de Classes
Pacotes de classes e colaborações no sistema
Uma das questões mais antigas nas metodologias de software é: como

você quebra um sistema grande em sistemas pequenos? Fazemos esta
pergunta porque à medida que os sistemas crescem, se torna difícil
compreendê-los, bem como as mudanças que neles fazemos.
Métodos estruturados usam decomposição funcional, no qual todo o

sistema foi mapeado como uma função e quebrado em sub-subfunções, que
foram posteriormente quebradas em sub-subfunções e assim por diante. As
funções eram como os casos de uso em um sistema orientado a objeto no qual
as funções representavam algo que o sistema fazia como um todo.
Aquela era uma época em que o processo e os dados eram separados.

Então, além da decomposição funcional, havia também a estrutura de dados.
Isso assumiria um segundo plano, embora algumas técnicas de Engenharia de
Informação agrupassem registros de dados em áreas de interesse e
produzissem matrizes para mostrar como as funções e os registros de dados
interagiam.
E deste ponto de vista que vemos a maior mudança que a orientação a

objetos tem trazido. A separação entre processo e dados já era, a
decomposição funcional já era, mas a velha questão ainda continua.
Uma idéia é agrupar as classes em unidades de nível mais alto. Esta

idéia, aplicada de forma bastante livre, aparece em muitas metodologias
orientadas a objetos. Em UML, este mecanismo de agrupamento é chamado
pacote (package).
34
Diagrama de Classes
Pacotes
A idéia de um pacote pode ser aplicada a qualquer elemento do modelo,

não somente a classes. Sem alguma heurística para agrupar as classes, o
agrupamento se torna arbitrário. A dependência é a heurística que considero
mais útil e mais enfatizada em UML.
Usamos o termo diagrama de pacotes para um diagrama que mostra

pacotes de classes e as dependências entre eles. De modo restrito, um
diagrama de pacotes é simplesmente um diagrama de classes que mostra
apenas pacotes e dependências. Utilizamos muito estes diagramas, por isso
chamamos de diagramas de pacotes, mas você deve lembrar que este é um
termo não oficia, não um nome oficial de diagramas da UML
.
Existe dependência entre dois elementos se mudanças na definição de
um elemento possam causar mudanças ao outro. Nas classes, as dependências
existem por várias razões: uma classe manda uma mensagem para outra; uma
classe tem outra como parte de seus dados; uma classe menciona uma outra
como um parâmetro para uma operação. Se uma classe muda a sua interface,
qualquer mensagem que ela mande pode não ser mais válida.
De forma ideal, apenas mudanças na interface de uma classe devem

afetar qualquer outra. A arte de projetar em grande escala envolve
minimização de dependências; desta forma, os efeitos da mudança são
reduzidos, e o sistema requer menos esforço para mudar.
UML tem muitas variedades de dependência, cada uma com estereótipos

e semântica particulares. É mais fácil começar com a dependência não-
estereotipada e usar as dependências mais particulares somente se
necessário.
35
Diagrama de Classes
Na figura abaixo você pode ver alguns pacotes e suas dependências.
Figura 4-23: Diagrama de pacotes
Há dependência entre dois pacotes se houver qualquer dependência

entre quaisquer duas classes nos pacotes. Por exemplo, veja que o pacote
“Gerenciador de Conexões com Banco de Dados” é um pacote muito utilizado
pelos demais, todos ous outrs pacotes dependem dele. Desta forma uma
alteração em classes deste pacote deve ser feito com muito cuidado pois pode
projudicar as classes nos demais pacotes.
36
Diagrama de Classes
É possível também representar um relacionamento de

generalização/herança entre os pacotes. Este tipo de relacionamento
normalmente é utilizado quando temos um conjunto de classes em um pacote
que são abstratas e devem ser utilizadas para que possamos criar outras
classes a fim de as mesmas executarem algo. Imagine o exemplo dado
anteriormente onde tínhamos um pacote com classes para conectar com o
banco de dados, todas as classes que estavam naque pacote eram abrastratas
e nós precisamos espcializar as mesmas e criar classes para fazer aquilo que
nós de fato queremos fazer: conectar com oracle, postgreSQl, etc. Veja abaixo
então como ficaria esta representação:
Figura 4-24: Diagrama de pacotes com generalização
37
Diagrama de Classes
Colaborações
Além de conter classes, um pacote pode conter colaborações. Uma

colaboração é um nome dado à interação entre duas ou mais classes.
Tipicamente, isso é uma interação, como descrito no diagrama de interação
(este diagrama será vistomais adiante no curso). Vejamos uma pequena
colaboração abaixo:
Figura 4-25: Colaboração entre classe para agendar um curso
Esta colaboração pode mostrar a implementação de uma operação ou a

realização de um caso de uso. Você pode modelar a colaboração antes de
decidir que operação a chama. Uma colaboração pode ser descrita com mais
de um diagrama de interação, com cada um mostrando um caminho diferente.
Você também pode mostrar um diagrama de classes para mostrar as classes
que participam na colaboração conforme a figura acima.
38
Diagrama de Classes
Quando Utilizar Diagramas de Pacotes e

Colaborações
Os pacotes são ferramentas vitais para projetos grandes. Utilize pacotes

sempre que um diagrama de classes que compreenda todo o sistema não for
mais legível numa única folha de papel tamanho A4.
Os pacotes são particularmente úteis para testes. Embora normalmente

se escreve alguns testes em um fundamento de classe-por-classe, prefira fazer
teste de unidade em um fundamento de pacote-por-pacote. Cada pacote deve
ter uma ou mais classes de teste que testem o comportamento do pacote.
Considere colaborações úteis sempre que você quer se referir a uma

interação particular ou mostrar uma pequena parte do diagrama de classes
focando um objetivo final para uma relação entre classes.
39
Diagrama de Classes
Multiplicidade
Indica uma faixa de cardinalidade permitida a um elemento, isto é, a

quantidade de instâncias possíveis em um relacionamento.
Por exemplo:
Numa classe Pessoa com o atributo cônjuge podemos afirmar (na nossa
atual legislação) que sua multiplicidade é de no mínimo zero e no
máximo um cônjuge (levando em conta o cônjuge atual).
Considerando uma classe Curso que se relacione com uma classe Aluno,
podemos afirmar que para cada instância de Curso há um
relacionamento com no mínimo zero e no máximo vários alunos; e para
cada instância de Aluno há um relacionamento com no mínimo zero (a-
luno está com a matrícula trancada) e no máximo vários cursos.
A multiplicidade consiste num subconjunto de um conjunto infinito de

números inteiros não-negativos. A especificação da multiplicidade é mostrada
como uma string compreendida numa seqüência de intervalos inteiros
separados por vírgula, no qual um intervalo representa uma faixa de inteiros
no formato:
limite-inferior.. limite-superior
Se a multiplicidade contiver um asterisco (*), significa que temos uma

faixa infinita de números inteiros não-negativos. É equivalente a 0..* (zero ou
mais). As multiplicidades mais comuns são:
• 0..1 (valor opcional)

• 1 ou 1..1 (exatamente um)
• * ou 0..* (qualquer valor inteiro não-negativo)
• 1..* (qualquer valor inteiro positivo)
Exemplos de multiplicidades:
"1", "*", "0..1", "1..*", "1..5", "3, 5..7, 10..12"
Algumas normas de estilo devem ser usadas para multiplicidade, como:
os intervalos devem ser mostrados em ordem crescente.
Exemplo: Adequado: 2..5, 8, 10..15

Inadequado: 10..15, 2..5, 8
40
Diagrama de Classes
dois intervalos contíguos devem ser combinados num intervalo simples.
Exemplo: Adequado: 3..8

Inadequado: 3..5, 6..8
Figura4-26: Multiplicidade entre classes
41
Diagrama de Classes
Escopo
Vamos supor o objeto Funcionário com o atributo salário. Agora vejamos

a seguinte situação: na empresa fictícia XYZ Ltda, instanciamos dois objetos a
partir de uma classe Funcionário identificando-os como objetoP e objetoA, os
quais representarão os funcionários Pedro e Augusto, respectivamente. Pedro
recebe R$ 500,00 de salário enquanto que Augusto recebe R$ 2000,00. Se
quisermos saber os salários desses funcionários, podemos nos referenciar da
seguinte forma:
objetoP.salario e objetoA.salario
Veja que dependemos da individualidade do objeto para obtermos os

salários corretos. Estamos diante do conceito de escopo de instância, que
também pode ocorrer com as operações. Vamos levar em conta a operação
gerarContraCheque. O resultado dessa operação será diferente para as
seguintes chamadas:
objetoP. gerarContraCheque() e objetoA.gerarContraCheque()
A diferença será dada em função dos objetos terem salários diferentes,

um possui R$ 500,00 e o outro R$ 2000,00. O contra-cheque gerado na
primeira chamada apresentará os dados funcionais do funcionário Pedro,
incluindo a demonstração de seus proventos e descontos. Já na segunda
chamada, o contra-cheque apresentará os dados funcionais e demonstração
de proventos e descontos do funcionário Augusto.
Isso significa que, ao definirmos o escopo de um atributo ou operação

como sendo de instância, estamos dizendo que eles estão ligados à identidade
do objeto, ou seja, pertencerão ao objeto.
Agora vamos pensar numa outra situação: vamos supor que os

funcionários dessa empresa não possam ganhar menos que um determinado
piso salarial, independente de seu cargo. Nesse caso, eu pergunto: piso salarial
é um atributo que modifica seu valor se o funcionário for o Pedro, Augusto ou
qualquer outro da empresa? Não. Isso significa dizer que esse atributo não está
ligado à identidade do objeto e sim à coleção (conjunto) de funcionários da
empresa. Está ligado à classe Funcionário. Dessa forma, supondo que a classe
Funcionario seja identificada como Funcionario, a referência a esse atributo
seria feita da seguinte forma:
42
Diagrama de Classes
Funcionario.pisoSalarial
Obteríamos o mesmo resultado, acessando objetoP.pisoSalarial ou

objetoA.pisoSalarial. A diferença é que no primeiro caso, não é preciso
instanciar um objeto. Imaginem criar um objeto só para saber o valor de um
atributo público!
O mesmo ocorreria com uma operação chamada emitirFolhaPagamento.

O resultado dessa operação é a folha de pagamento mensal contendo todos os
funcionários. Desta forma não importa chamá-la a partir de um único
funcionário, pois seu processamento será sempre sobre o conjunto de
funcionários, independente de quem ou quantos sejam.
Funcionario.emitirFolhaPagamento()
Estes dois últimos casos ilustram o conceito de escopo de classe.

Assim é comum dizermos que estamos definindo um atributo de classe ou
uma operação de classe.
A UML determina que o escopo de classe seja representado sublinhando-

se o elemento. Você pode encontrar representações diferentes em algumas
ferramentas, como por exemplo colocar à frente do elemento, um sinal de
dólar ($) - notação usada em versões mais antigas.
Figura 4-27: Operações com escopo de classe
43
Diagrama de Classes
Classes de Associação
Classes de associação permitem que você acrescente atributos,

operações e outras características às associações, como mostrado na figura
abaixo.
Figura 4-28: Representação de uma classe de associação
Você pode ver pelo diagrama que uma Pessoa pode trabalhar para uma
única Companhia. Suponhamos que necessitamos manter informação sobre o
período de tempo que cada funcionário trabalha para cada Companhia.
Podemos fazer isso adicionando o atributo dataInicio à associação.

Poderíamos acrescentar este atributo à classe Pessoa. Mas é realmente um
fato sobre a relação da Pessoa com a companhia, que mudará caso a pessoa
mude de empregador.
A figura abaixo mostra uma outra maneira para representar esta

informação: faça de Emprego uma classe plena (observe como as
multiplicidades foram movidas correspondentemente). Neste caso, cada uma
das classes na associação original tem uma ponta de associação de valor único
em relação à classe Emprego. A ponta "Empregador" agora é derivada, embora
eu não tenha que mostrá-lo.
44
Diagrama de Classes
Figura 4-29: Representação de uma classe de associação com emprego sendo classe plena
No diagrama acima podemos ver que uma pessoa pode trabalhar em

uma ou nenhuma empresa, sendo que esta empresa possui várias pessoas
trabalhando nela. A ponta empregador mostra que na pessoa teremos um
atributo empregador quando houver uma associação de pessoa também com
Empredo. Pereba que a empresa esta ligada a um emprego e este emprego
(que é único) pode ser exercido por uma pessoa, que por sua vez pode
também não estar liagada a emprego nenhum sendo que não estará então
ligada também a empresa.
45
Diagrama de Classes
Associação Xor (ou exclusiva)
Uma restrição Xor (ou exclusiva) indica que, dentre as várias associações
envolvidas nessa restrição, somente uma delas pode ocorrer por vez.
Por exemplo: suponha a classe Contrato que se relacione com a Classe

Contratante. Podemos ter um contratante do tipo Pessoa Física, assim como
um contratante do tipo Pessoa Jurídica, gerando duas associações:
Classe Contrato com a classe Pessoa Física

Classe Contrato com a classe Pessoa Jurídica
Entretanto, não podemos permitir que ambas as associações ocorram ao

mesmo tempo. Não seria possível num mesmo contrato termos um contratante
que fosse ao mesmo tempo Pessoas Física e Jurídica.
Representamos graficamente esta restrição por meio de uma linha

tracejada ligando as associações envolvidas. Essa linha é identificada com a
string {xor}. Veja a figura abaixo que ilustra esta associação:
Figura 4-30: Representação de {xor}
46
Diagrama de Classes
Estereótipo
Um estereótipo é um mecanismo de extensibilidade da UML que

representa uma subclasse de um elemento já existente com o mesmo formato
porém com objetivos diferentes e bem definidos. Geralmente, quando
necessitamos distinguir um uso específico para um elemento, utilizamos
estereótipos.
O estereótipo possui a mesma representação gráfica do elemento, sendo

colocado seu nome entre guillemets (<<>>) acima ou em frente do nome do
elemento que está sendo descrito pelo estereótipo. Se múltiplos estereótipos
são definidos para o mesmo elemento de modelo, então, eles são colocados
verticalmente um abaixo do outro. Por exemplo: <<utility>>
Um outro exemplo disso é a interface. A interface de UML é uma classe

que tem somente operações públicas sem métodos nem atributos. Isso
corresponde a interfaces em Java, COM e CORBA. Uma vez que este é um tipo
especial de classe, ele é definido como um estereótipo de classe. Utilizamos
também estereótipos para classes abstratas. Veja abaixo as figuras:
Figura 4-31: Utilização de estereótipos em classes
Notas
É um símbolo gráfico contendo informação textual. É utilizado para

especificar vários tipos de informações sobre os modelos, como: restrições,
comentários, corpos de métodos e valores de etiquetas. Veja abaixo a
presentação de uma nota:
47
Diagrama de Classes
Figura 4-32: Representação de uma nota
As notas são os elementos mais utilizados para melhorar e enriquecer os

seus diagramas com informações. Elas podem ser utilizadas em qualquer
diagrama e irão nos ajudar a explicar partes dos diagramas que os elementos
do mesmo utilizados pela UML não conseguem deixar claro.
48
Diagrama de Classes
Interfaces e Classes Abstratas
Uma das grandes qualidades do desenvolvimento orientado a objetos é

que você pode variar as interfaces de classes, independentemente da
implantação. Muito da força do desenvolvimento orientado a objetos vem
desta propriedade. Entretanto, poucas pessoas fazem bom uso disso.
As linguagens de programação usam uma construção única, a classe,

que contém tanto a interface quanto a implementação. Quando você faz
subclassificação, você herda as duas. Raramente, faz-se uso de interface como
uma construção separada, o que é uma pena.
Uma interface pura, como em Java, é uma classe sem implementação e,

portanto, tem declarações de operações mas não corpos de métodos e não
tem campos. As interfaces são, freqüentemente, declaradas através de classes
abstratas. Tais classes podem oferecer alguma implementação, mas, com
freqüência, elas são usadas basicamente para declarar uma interface. O ponto
é que a subclassificação - ou outro mecanismo- proverá a implementação, mas
os clientes nunca verão a implementação, somente a interface.
O editor de texto representado na figura abaixo é um exemplo típico

disso. Para permitir que o editor seja independente da plataforma, definimos
uma classe Janela abstrata independente de plataforma. Esta classe não tem
corpos de métodos; ela apenas define uma interface para utilização pelo editor
de texto. Subclasses específicas de plataforma podem ser usadas conforme o
desejado.
49
Diagrama de Classes
Figura 4-33: Representação de uma classe abstrata
Se você tem uma classe ou um método abstrato, a convenção de UML é

de colocar em itálico o nome do item abstrato. Você também pode usar a
restrição {abstract}. Uso {abstract} em quadros brancos porque não posso
escrever um texto em itálico. Os editores permitem usar itálico, mas acredito
que o uso do estereótipo deixa mais claro.
Classes abstratas podem possuir operações com implementação, a pesar

de se diferenciarem por terem operações sem implementação. Muitas vezes
consideramos a classe abstrata como uma classe inacabada e que que não
pode ser acabada porque a implementação do que falta é dependente de
alguém, como por exemplo na figura acima, dependente de uma plataforma.
Normalmente as classes abstratas representam estruturas das quais não
iremos criar objetos mas sim servirão de moldes para a padronização de outras
classes, as classes filhas.
Uma interface é muito parecida com uma classe abstrata, porém ela se
difere por ser uma estrutura voltada para a representação de
comportamentos, onde os comportamentos serão as operações. Uma interface
não possui operações com implementação, elas tem somente a assinatura das
mesmas declaradas. A interface será implementada por classes e a relação
entre elas será conhecida como realização. Veja abaixo a representação de
uma interface com algumas operações:
50
Diagrama de Classes
Figura 4-34: Representação de uma interface
Abaixo temos uma JanelaWindows que está implementando o

comportamento de uma interface WindowListener. Este interface define todos
os comportamentos que uma janela pode ter. Se a JanelaWindows implementar
estes comportamentos então será obrigado termos na mesma todas as
operações descritas na interface. A classe que implementar esta interface
poderá tratar ações que acontecem em uma janela, ou seja os
comportamentos da interface WindowListener.
Figura 4-35: Relacionamento de realização entre uma classe e uma interface
51
Diagrama de Classes
Objetos de Referência e Objetos de Valor
Uma das coisas comuns dita sobre objetos é que eles têm identidade.
Isso é verdade, mas não é tão simples assim. Na prática, você percebe que a
identidade é importante para objetos de referência, mas não tão importante
para objetos de valor.
52
Diagrama de Classes
Objetos de referência
São coisas como Clientes, geralmente as classes das linguagens. Aqui, a

identidade é muito importante, porque você geralmente quer que somente um
objeto de software designe um cliente no mundo real. Um objeto que faz
referência a um objeto-Cliente fará isso através de uma referência ou ponteiro;
todos os objetos que se referem a este Cliente vão se referir ao mesmo objeto
de software. Desta forma, modificações em um Cliente ficam disponíveis para
todos os usuários do Cliente.
Se você tem duas referências para um Cliente e quer ver se são as

mesmas, você, normalmente, compara suas identidades. Cópias podem ser
proibidas; se são permitidas, elas tendem a ser feitas raramente, talvez para
propósitos de arquivamento ou para replicação na rede. Se cópias forem feitas,
você necessita decidir como sincronizar as atualizações do objeto.
53
Diagrama de Classes
Objeto de Valor
São coisas como datas, ou tipos primitivos das linguagens. Você tem,
geralmente, múltiplos objetos de valor representando o mesmo objeto do
mundo real. Por exemplo, é normal ter centenas de objetos que designam 29-
Jul-2004. Estas são todas cópias intercambiáveis. Novas datas são
freqüentemente criadas e destruídas.
Se você tem duas datas e quer ver se elas são a mesma, você não
examina as suas identidades, mas sim os valores que elas armazenam. Isso
significa, geralmente, que você tem que escrever um operador de teste de
igualdade, que para datas fará testes no ano, mês e dia (ou qualquer outra
forma de representação interna). Normalmente, cada objeto que faz referência
a 29-Jul-2004 tem o seu próprio objeto data dedicado a isso, mas você também
pode compartilhar datas.
Objetos de valor devem ser imutáveis (congelados; veja "Frozen" mais

adiante). Em outras palavras, você não deve ser capaz de pegar um objeto
data de 29-Jul-2004 e mudá-lo para ser 31-Jul-2004. Em vez disso, você deve
criar um novo objeto 31-Jul-2004 e ligá-lo ao primeiro objeto. A razão é que se
a data fosse compartilhada, você atualizaria a data de outro objeto de um
modo imprevisível.
Antigamente, a diferença entre objetos de referência e objetos de valor

era mais clara. Objetos de valor eram os valores básicos (built-in) de um
sistema de tipos. Agora, você pode estender o sistema de tipos com suas
próprias classes, por isso esta questão requer mais reflexão. Em UML, atributos
são geralmente usados para objetos de valor e associações são usadas para
objetos de referência. Você também pode usar composição para objetos de
valor.
A distinção entre objetos de valor e de referência seja útil para modelos

conceituais. Isso pode causar confusão com multiplicidades. Se representar
uma ligação para um objeto de valor com uma associação, normalmente
marcamos a multiplicidade da ponta do usuário de um dado valor como "*", a
não ser que exista uma regra de unicidade, tal como um número de seqüência.
54
Diagrama de Classes
Coleções para Pontas de Associações de

Valores Múltiplos
Uma ponta de valor múltiplo é uma cujo limite superior de

multiplicidade é maior que 1 (por exemplo, "*"). Uma convenção usual é que
pontas de valores múltiplos sejam consideradas como conjuntos. Não há
ordem para os objetos-alvo, e nenhum objeto aparece no conjunto mais de
uma vez. Entretanto, você pode mudar estas suposições anexando uma
restrição.
A restrição {ordered} implica que há uma seqüência de ordem para os

objetos-alvo - isto é, objetos-alvo formam uma lista. Eles podem aparecer
somente uma vez na lista.
Uso a restrição {bag} para indicar que objetos-alvo podem aparecer

mais de uma vez, mas sem ordem. Também a restrição {hierarchy} para
indicar que eles formam uma hierarquia.
55
Diagrama de Classes
Frozen
Frozen (Congelado) é uma restrição que UML define como aplicável a um

atributo ou a uma ponta de associação, mas considero-o útil também para
classes.
Em uma ponta de associação ou atributo, Frozen indica que o valor

daquela ponta de associação ou atributo não pode mudar durante o tempo de
vida do objeto-fonte. O valor deve ser estabelecido na criação do objeto e não
pode mudar jamais. O valor inicial pode ser nulo. Certamente, se isso é
verdade quando o objeto for construído, isso será verdade durante toda a vida
do objeto. Isso indica que existe um argumento para este valor em um
construtor e não existe operação que atualize este valor.
Quando aplicado a uma classe, congelado indica que todas as pontas de

associação e todos os atributos associados com aquela classe são congelados.
Congelado não é o mesmo que Read-Only (somente-de-leitura). Read-

Only indica que um valor não pode ser mudado diretamente, mas pode mudar
devido a uma mudança em algum outro valor. Por exemplo, se uma pessoa
tem uma data de nascimento e uma idade, a idade pode ser somente-de-
leitura, mas não pode ser congelada.
Frozen quando colocado na assinatura de uma classe indica que esta

classe não pode ter filhos, ou seja não poderá ser classe pai em uma relação
de generalização/herança. Já quando colocamos frozen em uma assinatura de
uma operação estamos dizendo que esta operação não poderá ser
sobreescrita, ou seja ela não poderá ser redefinida na classe filha da classe
que a contém.
56
Diagrama de Classes
Visibilidade
A visibilidade é um daqueles assuntos que é simples em princípio, mas

tem complexas sutilezas. A idéia básica é que qualquer classe tem elementos
públicos e elementos particulares. Os elementos públicos podem ser usados
por qualquer outra classe; os elementos particulares podem ser usados
somente pela classe proprietária. Entretanto, cada linguagem tem suas
próprias regras. Embora muitas linguagens usem termos como public
("público"), private ("particular") e protected ("protegido"), eles têm
significados diferentes em linguagens diferentes. Estas diferenças são
pequenas, mas causam confusão, principalmente para alguns de nós que
utilizamos mais de uma linguagem.
UML tenta abordar o tema sem entrar em terrível confusão.

Essencialmente, dentro de UML, você pode rotular qualquer atributo ou
operação com um indicador de visibilidade. Você pode usar qualquer marcador
que quiser, e seu significado é dependente da linguagem. Entretanto, UML
fornece quatro (bastante difíceis de lembrar) abreviações para visibilidade; +
(público), - (privado), # (protegido) e ~ (pacote)
Para compreender realmente algumas diferenças comuns que existem

entre modelos, você necessita compreender os enfoques que linguagens
diferentes usam em relação à visibilidade. Com C++, que é a base para o uso-
padrão de UML, temos os três primeiros mostrados abaixo, porém a maioria
das linguagens possui o pacote também.
PUBLIC é visível em qualquer lugar no programa e pode ser acessado

por qualquer objeto no sistema.
PRIVADO pode ser usado somente pela classe que o define.
PROTEGIDO pode ser usado somente por (a) uma classe que o define
ou (b) uma subclasse daquela classe.
PACOTE pode ser utilizado pela classe que o define e por outras classes
que estivrem no mesmo pacote.
Considere uma classe Cliente que tem uma subclasse Cliente Pessoa-
Física. Considere também o objeto Martin, que é uma instância de Cliente
Pessoa-Física. Martin pode usar qualquer membro público de qualquer objeto
no sistema. Martin também pode usar qualquer membro particular da classe
Cliente Pessoa-Física. Martin não pode usar membros particulares definidos
dentro de Clientes; pode, entretanto, usar membros protegidos de Cliente e
membros protegidos de Cliente Pessoa-Física.
Agora, examinemos Smalltalk. Dentro desta linguagem, todas as

variáveis de instância são particulares, e todas as operações são públicas.
57
Diagrama de Classes
Entretanto, particular não significa a mesma coisa em Smalltalk que em C++.

Em um sistema Smalltalk, Martin pode acessar qualquer variável de instância
dentro do seu próprio objeto se aquela variável de instância estiver definida
dentro de Cliente ou Cliente Pessoa-Física. Então, de certa forma, particular em
Smalltalk é semelhante a protegido em C++.
Ah, mas isso seria simples demais...
Vamos voltar para C++. Digamos que eu tenha uma outra instância de
Cliente Pessoa-Física chamada Kendall. Kendall pode acessar qualquer membro
de Martin que tenha sido definido como parte cia classe Cliente Pessoa-Física,
seja público, particular ou protegido. Kendall também pode acessar qualquer
membro público ou protegido de Martin que tenha sido definido em Cliente.
Entretanto, em Smalltalk, Kendall não pode acessar as variáveis de instância
particulares de Martin - somente as operações públicas de Martin.
Em C++, você pode acessar membros de outros objetos de sua própria

classe da mesma forma que acessa os seus próprios membros. Em Smalltalk,
não faz diferença se um outro objeto é da mesma classe ou não; você pode
somente acessar as partes públicas de um outro objeto.
Java é semelhante a C++; ela oferece acesso livre a membros de outros

objetos de uma mesma classe. Ela também acrescenta um novo nível de
visibilidade, chamado pacote. Um membro com visibilidade de package
(pacote) pode ser acessado somente por instâncias de outras classes dentro
do mesmo pacote.
Permanecendo em nosso tema, para garantir que as coisas não são tão
simples, Java redefine levemente visibilidade protegida. Em Java, um membro
protegido pode ser acessado por subclasses, mas também por qualquer outra
classe do mesmo pacote da classe proprietária. Isso significa que, em Java,
protegido é mais público que pacote. Java também permite que classes sejam
marcadas: como públicas ou de pacote. Os membros públicos de uma classe
pública podem ser usados por qualquer classe que importa o pacote em que a
classe pertence. Uma classe de pacote pode ser usada somente por outras
classes do mesmo pacote.
C++ acrescenta um penduricalho adicional. Um método ou classe de C+

+ pode se tornar um amigo ("friend") de uma classe. Um amigo tem acesso
completo a todos os membros de uma classe - portanto, a frase (de mau-
gosto) "em C++, amigos tocam as partes particulares dos outros".
Quando você estiver usando visibilidade, use as regras da linguagem na

qual está trabalhando. Quando você está examinando um modelo UML de
qualquer outra origem, seja cuidadoso com o significado dos marcadores de
visibilidade, e esteja ciente de como estes significados podem mudar de
linguagem para linguagem.
As visibilidades geralmente mudam quando você começa a trabalhar

com código. Então, não fique amarrado a elas no início do projeto. Veja abaixo
uma classe com a visibilidade para seus atributos:
58
Diagrama de Classes
Figura4-36: Representação da visibilidade para atributos de uma classe
Na Orientação a Objetos lembre-se que o recomendado é ter os atributos

de uma classe sempre privados, desta forma teríamos sempre o sinal de “-” na
frente de cada um doa atributos.
59
Diagrama de Classes
Quando Utilizar Diagramas de Classes
Diagramas de classes são a base de quase todas as metodologias OO,

portanto você irá utilizá-los o tempo todo. Este capítulo cobre os conceitos
básicos; neste capítulo do curso discutimos muitos conceitos avançados.
O problema com diagramas de classes é que eles são muito ricos e

podem ser complexos de se usar. Você tem aqui algumas dicas.
Não tente utilizar todas as notações que você dispõe. Comece com os
recursos mais simples: classes, associações, atributos, generalização e
restrições. Introduza outras notações mais avançadas vistas neste
capítulo somente se necessitar.
Ajuste a perspectiva na qual você está desenhando os modelos para o

estágio do projeto.
1- Se você estiver fazendo análise, desenhe modelos conceituais.

2- Quando você estiver trabalhando com software, concentre-se nos
modelos de especificação.
3- Desenhe modelos de implementação somente quando você estiver
ilustrando uma particular técnica de implementação.
Não desenhe modelos para tudo; em vez disso, concentre-se nas áreas
principais. É melhor ter poucos diagramas que você usa e mantém
atualizados do que ter muitos modelos esquecidos e obsoletos.
O maior perigo com diagrama de classes é que você pode ficar detido
em detalhes de implementação muito facilmente. Para combater isso,
concentre-se nas perspectivas conceituais e de especificação.
60
Diagrama de Classes
Exercícios
Utilizando a ferramenta de modelagem de diagramas UML faça:
1 – Para o texto descritivo do sistema apresentado no exercício do

capítulo 1 (capítulo sobre use cases) elabore um diagrama de classes que
possa representar as classes envolvidas no sistema mostrando as suas
assiciações. Tente utilizar ao máximo a notação para representação dos
elementos do diagrama de classes estudada no capítulo.
2 – Reflita e discuta com o instrutor e colegas quais são os benefícios

da construção de um diagrama de classes para a modelagem de sistemas
orientados a objeto.
61
Diagrama de Classes
62
5. Diagrama de Estados
1
Diagrama de Estados
Objetivos
 Aprender o que é e como pode ser utilizado diagramas de estados
 Conhecer os elementos que fazem parte deste tipo de diagrama
 Saber quando devemos utilizar diagramas de classes
2
Diagrama de Estados
O que é um Diagrama de Estados?
O diagrama de gráfico de estados descreve o comportamento de objetos

como reação a eventos discretos (como por exemplo sinais e invocação de
operações), por meio de seqüências de estados e ações que ocorrem durante a
sua vida.
Um diagrama de gráfico de estados tem por objetivo mostrar uma

máquina de estado. Uma máquina de estado consiste num comportamento
que especifica a seqüência de estados que um objeto atravessa durante sua
vida, em resposta a eventos, junto com suas responsabilidades e ações.
3
Diagrama de Estados
Estado
Um estado é uma condição ou situação existente na vida de um objeto

durante a qual o estado satisfaz alguma condição, executa alguma atividade
ou espera por algum evento.
Um estado é representado graficamente como um retângulo com cantos

arredondados. O nome do estado é colocado no centro do mesmo, caso ele
não esteja subdividido em compartimentos. Veja na figura abaixo a
representação de um estado:
Figura 5-1: Representação de estados
Um estado pode ser opcionalmente subdividido em compartimentos

separados cada qual por uma linha horizontal. São eles:
Compartimento de nome: armazena o nome do estado, como uma string.

É possível desenharmos estados sem nomes. Estes são estados
anônimos, distintos em si.
Compartimento de transições internas: este compartimento armazena

uma lista de ações ou atividades internas que são executadas enquanto
o objeto se apresenta no estado em foco.
Essas transições internas são representadas por expressões que identificam

as circunstâncias sobre as quais a ação associada será invocada. A ação
associada ao tipo de transição externa pode fazer uso de quaisquer atributos e
links, que estão no escopo do objeto proprietário. Uma transição interna não
modifica o estado do objeto.
Por exemplo: quando um objeto OperacaoBancaria entra no estado de

"Liberando dinheiro de saque", ele pode chamar uma ação que bloqueie na
conta do correntista o valor designado para saque. Na saída desse estado, ele
pode chamar a ação de debitar o valor da conta. Durante o estado, estará
sendo executada a operação de contagemCedulas().
4
Diagrama de Estados
Existem algumas palavras reservadas que representam as transições

internas. Veja quais são e seus significados:
entry: identifica uma ação que é executada na entrada do estado.

exit: identifica uma ação que é executada na saída do estado.
do: identifica uma atividade em andamento, ou seja, que é executada
continuamente durante o tempo em que o objeto permanece nesse
estado.
include: usado para identificar a invocação de uma submáquina, cujo
nome está ligado à expressão.
As expressões citadas identificam, cada qual, o evento que dispara a

expressão correspondente associada.
O formato geral para qualquer item da lista é:
nome-do-evento (lista de parâmetros separada por vírgula ) [ condição-de-guarda ] /

expressão-ação
Cada nome de evento pode aparecer mais de uma vez por estado se as
condições de guarda forem diferentes. Os parâmetros do evento e as
condições de guarda são opcionais.
Figura 5-2: Compartimento de transições internas
Vou utilizar em seguida um exemplo do nosso mundo real para que vocês
possam abstrair mais facilmente o conceito de estados.
Vamos pensar na vida de uma pessoa do nascimento até a terceira

idade. Veja, de forma sucinta, como seria parte do nosso diagrama de estados.
Para assumirmos o primeiro estado de nossa existência, precisamos do

evento nascer. Já nascemos como bebé e a primeira ação que temos é
reconhecer nossa mãe, pelo toque, voz e/ou cheiro. Durante esse período
inicial, o bebé, além de dormir e mamar, também desenvolve suas habilidades
- principalmente motoras: aprende a sentar, engatinhar, falar e andar. Só que
ao final dessa fase, quando ele já tem uma personalidade bem formada, já
5
Diagrama de Estados
podemos considerar nosso bebé como uma pequenina criança. Nesse período
no "estado de criança", recebemos muitos estímulos e executamos muitas
ações. Mas pelo foco que quero dar nesse primeiro exemplo, coloquei como
atividade principal: brincar. Até que chega a dita puberdade, que transforma
nossas crianças em adolescentes. Na saída do estado de criança, algumas
atitudes são tomadas: se criança do sexo feminino, abandonar as bonecas; se
do sexo masculino, abandonar os carrinhos (ou as “bolinhas de gude”).
Já ao entrar na fase de adolescência, a primeira ação de nossa "pós-

criança" é estabelecer seu território: o quarto deles, as coisas deles, os direitos
deles, etc. No estado de adolescente há várias coisas que podem ser feitas,
mas decidi colocar a operação namorar. Em determinado momento da vida
(que não sei precisar qual e não sei se alguém consegue determinar), o
adolescente passa para o estado adulto. Ou, então, por uma precipitação da
sua ação principal (namorar), casa-se sem se tornar adulto.
Figura 5-3: Exemplo de um diagrama de estados descrevendo nossa evolução
Durante sua permanência no estado adulto, essa pessoa exerce a ação

Trabalhar . Finalizarei o exemplo com uma separação do estado Adulto (como
solteiro) para um estado de Casado.
6
Diagrama de Estados
Estado Inicial e Estado Final
Um estado inicial é um tipo de estado que indica o local de início na

máquina de estados ou em um subestado. É representado graficamente como
um círculo preenchido.
Figura 5-4: Exemplo de estado inicial
Um estado final é um tipo de estado que indica que a máquina de

estados ou um estado composto concluiu sua execução. É representado
graficamente como ura círculo envolvendo um pequeno círculo preenchido.
Figura 5-5: Exemplo de estado final
7
Diagrama de Estados
Transições
Uma transição é um relacionamento entre dois estados indicando que

houve uma mudança de estado e determinadas ações serão executadas,
quando um evento específico ocorrer, garantindo que condições foram
satisfeitas. A transição é disparada quando ocorre a mudança de estado.
É representada graficamente como uma linha sólida na qual o estado de

partida é identificado como estado de origem e o estado-alvo é o estado de
destino. A linha da transição finaliza com uma seta. Pode ser identificada por
uma string que possui o seguinte formato:
assinatura-do-evento [ condição-de-guarda ] / expressão-ação
A assinatura-do-evento descreve um evento com seus argumentos, no

seguinte formato:
nome-do-evento (lista de parâmetros separada por vírgula )
Exemplo: ChecarEstoque(produto)
Figura 5-6 – Diagrama de estados para uma fila de impressão
A condição de guarda é uma expressão booleana que determina, quando

verdadeira, o início da transição. Pode ser escrita com parâmetros do evento
disparador ou ainda atributos e links do objeto proprietário da máquina de
estados. Só é avaliada depois que o evento de ativação ocorre. É possível
termos várias transições a partir do mesmo estado de origem, identificadas
com o mesmo evento, diferenciando apenas na sua condição de guarda.
Exemplo: [estoqueAtual <= estoqueMinimo]
A expressão-ação somente é executada no início da transição, se esta

ocorrer. Pode ser escrita com operações, atributos e links do objeto proprietário
8
Diagrama de Estados
da máquina de estados, parâmetros do evento disparador ou qualquer outro

elemento visível no mesmo escopo.
Exemplo: DataPagamento:= DataPagamento + 3
Veja por exemplo a figura abaixo. O objeto está no estado Aguardando

Nota, até que o evento Nota lançada ocorra. Nesse momento, temos duas
possibilidades para o mesmo evento. A primeira é representada na transição
para o estado Atualizando Média, que só será iniciada se a sua condição de
guarda for satisfeita, ou seja, que nota >= 0. Outra possibilidade ocorre na
transição para o estado Habilitando Segunda Chamada, que só terá início se a
condição de guarda nota = "FT" for verdadeira, ou seja, se não tiver havido
nota pois o aluno faltou.
Figura 5-7: Diagrama de Estados com condição nas transições
Um evento é a especificação de um tipo de ocorrência observável. Para

propósitos práticos em diagramas de estado, ele é uma ocorrência que pode
disparar uma transição de estado. Eventos podem ser processados um de cada
vez. Se um evento não disparar uma transição, esta é descartada. Eventos
podem ser de vários tipos (não necessariamente mutuamente exclusivos):
Quando uma condição (descrita por uma expressão booleana) tem seu
valor modificado de falso para verdadeiro;
Quando há recepção de um sinal explícito de um objeto para outro;
Quando há recepção da chamada de uma operação implementada como
uma transição por um objeto;
Quando a passagem de um período de tempo específico depois da ocor-
rência de outro evento representa um evento de tempo. Pode ser repre-
sentado pela palavra chave after seguida pela expressão a ser avaliada
(ex: after 10 minutos). Outra palavra-chave que pode ser usada é when
(ex: when (dataAdmissao >= 01/01/1987)).
9
Diagrama de Estados
Figura 5-8: Diagrama para fila de impressão com eventos internos
10
Diagrama de Estados
Estado composto
Um estado composto é um estado que possui uma decomposição gráfica

em dois ou mais subestados concorrentes (sobrepostos) ou sequenciais
(disjuntos).Cada região de um estado pode possuir estados inicial e final.
Uma transição para um estado composto representa uma transição para

o estado inicial do referido estado composto. Uma transição para um estado
final representa a conclusão da atividade na região do estado composto.
Vamos supor um sistema de avaliação no qual o aluno responda as questões
de sua prova on-line. Vamos pensar para esse sistema em um objeto Prova
(veja figura abaixo). Durante a vida deste objeto, no momento que o aluno
responde às questões, o objeto estará passando do estado Aguardando
Escolha de Questão para Aguardando Resposta de Questão e assim por diante.
Todavia, em paralelo com essas respostas, temos o estado Checando Término
da Prova, que ocorre quando o tempo decorrido de prova se iguala ao valor do
atributo tempoProva. Neste caso, estamos diante de subestados concorrentes,
nos quais os estados ocorrem simultaneamente.
Figura 5-9: Diagrama de Estados concorrentes
11
Diagrama de Estados
Quando Utilizar Diagramas de Estados
Diagramas de estados são bons para descrever o comportamento de um

objeto, através de vários casos de uso. Esses diagramas não são muito bons
para descrever um comportamento que envolve vários objetos em
colaboração. Para tal, é útil combinar diagramas de estados com outras
técnicas.
Por exemplo, diagramas de interação (vistos mais adiante neste curso)

são bons para descrever o comportamento de vários objetos em um único caso
de uso, e diagramas de atividades (visto anteriormente) são bons para mostrar
a seqüência geral de ações para vários objetos e casos de uso.
Nem todo mundo considera que os diagramas de estados sejam naturais.

Fique atento ao modo que as pessoas trabalham com eles. Pode ser que sua
equipe não considere diagramas de estados úteis para seu tipo de trabalho.
Isso não é um grande problema; como sempre, você deve lembrar de usar
uma combinação das técnicas que funcionam para você.
Se você utilizar diagramas de estados, não tente projetá-los para cada

classe no sistema. Embora este método seja frequentemente usado por
perfeccionistas de muita formalidade, ele é quase sempre um desperdício de
trabalho. Use diagramas de estados somente para aquelas classes que exibem
comportamento interessante, para as quais a construção do diagrama de
estados ajude a compreender o que está acontecendo. Muitas pessoas
acreditam que Interface de Usuários e objetos de controle têm o tipo de
comportamento que é útil descrever com diagramas de estados.
12
Diagrama de Estados
Exercícios
1 – Em quais situações você julga importante a criação de diagramas de

estados?
2 – Utilize a ferramenta de modelagem UML para criar um ou mais

diagramas de Estados para as classes que você julgar que necessitam no seu
diagrama de classes. Concentre-se nos esdados das classes e deixe para
pensar depois as operações (entry/do/exit).
13
Diagrama de Estados
14
6. Diagrama de Objetos
1
Diagrama de Objetos
Objetivos
 Conhecer o diagrama de objetos
 Reconhecer os elementos do diagrama de objetos
 Montar um diagrama de objetos
 Saber quando utilizar este tipo de diagrama
2
Diagrama de Objetos
O que é um diagrama de objetos?
Este diagrama poderia tranquilamente ser abordado como um item do

capítulo de diagrama de classes, já que representa a instância desse diagrama
num determinado ponto do tempo. Por suas características, ele merece um
pouco mais de atenção. Se pensarmos naqueles sistemas cujos requisitos são
fonte de dúvidas, certamente você achará que esse diagrama lhe fornece
muito mais produtividade do que aparenta. Para instâncias de uma classe
Aluno, talvez esse diagrama seja desnecessário, mas será que teríamos o
mesmo pensamento no caso de classes envolvendo um ambiente industrial?
Vejamos agora este diagrama em detalhes, o mesmo é um diagrama simples e
não frequentemente utilizado.
3
Diagrama de Objetos
Criando diagramas de objetos
Um diagrama de objetos consiste numa instância do diagrama de

classes, no qual para cada classe ternos um objeto (sua instância) em um
determinado ponto do tempo. Você deve estar perguntando: e para que isso
me serviria? Primeiramente, muitas vezes estamos naqueles dias em que a
criatividade custa para vir ou simplesmente o relacionamento entre classes
não está claro suficiente para que possamos realizar a modelagem do
diagrama. Uma vez que criamos um diagrama de objetos, passamos a
trabalhar com dados reais, que numa visão direta lhe dizem muito mais do que
a simples estrutura de uma classe. Essa visão não só esclarece o
relacionamento entre as classes, como pode levar ao esclarecimento de
dúvidas de domínio.
Os diagramas de objetos são muito úteis para facilitar a modelagem de

estruturas complexas de dados. O diagrama de objetos pode também auxiliar
o desenvolvedor no momento de identificar problemas na execução de uma
aplicação. Durante o debugging, pode-se parar a execução e paralelamente
mapear, num diagrama de objetos, os objetos que estão sendo manipulados,
expandindo seus relacionamentos e alguns objetos vizinhos.
Se levarmos em conta todos os objetos e relacionamentos possíveis

dentro de um diagrama, teremos milhares de objetos. Logicamente é
impossível exibirmos tudo. Desta forma, deve-se mostrar no diagrama de
objetos somente um conjunto de objetos que tenham relevância dentro da
modelagem. Esse conjunto procura se basear em colaborações. A partir de um
determinado objeto, percorrem-se os relacionamentos existentes, congelando-
se um determinado estado do objeto. Fowler, no seu livro UML Distilled - A
BriefGuide to the Standard Object, afirma que podemos considerar um
diagrama de objetos como um diagrama de colaboração (visto anteriormente)
sem mensagens, uma vez que estamos representando os objetos ligados uns
aos outros para realizar determinada tarefa.
As ferramentas não necessitam possuir uma implementação separada

para diagramas de objetos. É possível apenas adotar um diagrama de classes
que mostre objetos no lugar das classes. Para chamar a atenção para
características importantes, pode-se trabalhar com anotações e cores
diferenciadas no diagrama.
A representação gráfica de um objeto é similar à de uma classe. Consiste

num retângulo com dois compartimentos. O primeiro mostra o nome do objeto
e o segundo mostra os atributos, um em cada linha, com seus valores. Veja a
figura abaixo:
4
Diagrama de Objetos
Figura 6-1: Representação de um objeto

O nome do objeto deve ser sublinhado, na seguinte notação: nome do
objeto: nome da classe
Por exemplo: uml: Curso
É possível ainda omitir o nome do objeto (preservando os dois pontos),

representando um objeto anônimo ou omitir o nome da classe (juntamente
com os dois pontos). Em qualquer um desses casos, mantém-se o sublinhado.
É mais comum representarmos somente o tipo do objeto não se preocupando
com o nome do mesmo. Veja a figura abaixo:
Figura 6-2: Representações possíveis para um objeto
Quanto aos atributos, estes são exibidos na notação:
nome do atributo: tipo = valor
O tipo, se for citado, deve ser o mesmo definido na classe. Desta forma,
ele pode ser omitido sem prejuízo da compreensão do diagrama.
Figura 6-3: Representações de um objeto com atributos e valores

5
Diagrama de Objetos
Atributos cujos valores não sejam relevantes para a modelagem podem

ser omitidos. É possível também representar atributos cujos valores mudam
durante um processamento. Nesse caso, representa-se essa mudança por meio
de uma lista de valores.
O relacionamento entre os objetos é feito através de links. Um link é a

instância de uma associação. Um nome de papel pode ser mostrado ao final de
cada link. Da mesma ferma, um nome de associação pode ser mostrado
próximo à linha. Multiplicidades não podem ser mostradas para links, pois
estes já são instâncias de associações. Os adornos de associação como
agregação, composição e navegação, assim como qualifícadores, podem ser
mostrados na terminação dos links. Os diagramas de objetos podem também
conter: notas, restrições e pacotes.
Vamos considerar o diagrama de classes da figura abaixo. A partir deste

diagrama vamos montar um diagrama de objetos, mostrando mais
explicitamente as multiplicidades que podem ser representadas por objetos.
6
Diagrama de Objetos
Figura 6-4: Diagrama de classes base para o diagrama de objetos
Abaixo podemos ver um diagrama de objetos para este diagrama de

classes. Note que o diagrama de objetos mostra claramente a multiplicidade
que pode acontecer entre um Instrutor e MaterialDidatico, bem como a
possibilidade de haver mais de uma versão para o material didático que é
mostrado na associação entre Curso e MaterialDidatico. Note ainda que cada
associação entre o MaterialDidatico e o Arquivo resultou na criação de um
objeto ligado a MaterialDidatico.
7
Diagrama de Objetos
Figura 6-5: Diagrama de objetos para o diagrama de classes
8
Diagrama de Objetos
Quando utilizar diagrama de objetos?
Como já falamos na parte introdutória deste capítulo, o diagrama de

objetos será utilizado nas seguintes situações:
1 – Durante o debugging, pode-se parar a execução e paralelamente

mapear, num diagrama de objetos, os objetos que estão sendo manipulados,
expandindo seus relacionamentos e alguns objetos vizinhos
2 – Mostrar as multiplicidades do diagrama de classes de forma mais

clara ligando os objetos
3 – Muitas vezes estamos naqueles dias em que a criatividade custa

para vir ou simplesmente o relacionamento entre classes não está claro
suficiente para que possamos realizar a modelagem do diagrama. Um
diagrama de objetos irá nos ajudar nestes relacionamentos
4 – Montar uma diagrama de objetos com valores e enviar para o

programador fazer testes no sistema com objetos com aqueles dados
9
Diagrama de Objetos
Exercícios
1 – Qual a finalidade dos diagramas de objetos?
2 – Para o diagrama de classes que você construiu nos exercícios do

capítulo de classes faça agora um diagrama de objeto para algumas regiões
que você julgar importantes do mesmo.
10
Diagrama de Objetos
11
7. Diagrama de Interação
1
Diagrama de Interação
Objetivos
 Conhecer o diagrama de interação
 Reconhecer os elementos do diagrama de interação
 Estudar diagramas de colaboração
 Estudar diagramas de seqüência
 Saber quando utilizar estes diagramas
2
O que é um diagrama de Interação?
Antes de iniciarmos o estudo sobre os diagramas de interação, seria

importante definirmos o que é uma interação. Mais do que isso, acho
pertinente esclarecermos quaisquer dúvidas sobre interação e iteração.
Definição, segundo o Dicionário Aurélio:
interação. [De inter- + nção.] S. f. L Ação que se exerce mutuamente

entre duas ou mais coisas, ou duas ou mais pessoas; ação recíproca: "Nesse
fenômeno de interação de linguagem popular e linguagem poética o fato que
nos parece mais curioso é o do aproveitamento, no curso da vida de cada
um, .... de expressões usadas por poetas" (Valdemar Cavalcanti, Jornal
Literário, p. 199); "É evidente que a obra de arte resulta da interação de
fatores subjetivos e objetivos, veiculados através do meio social. " (Euríalo
Canabrava, Estética da Crítica, p. 29)
iteração. [Do lat. iteratione.] S. f. L Ato de iterar; repetição. 2. Álg.

Inform. Processo de resolução (de uma equação, de um problema) mediante
uma seqüência finita de operações em que o objeto de cada uma é o resultado
da que a precede.
Isto posto, interação corresponde a um conjunto de mensagens

trocadas entre objetos, com o objetivo de alcançar um determinado
propósito, respeitando-se o contexto do sistema.
Já iteração corresponde, em uma abordagem mais complexa, às fases

que se repetem, nas quais a entrada de uma fase corresponde à saída da sua
antecessora. Em uma abordagem mais simples, corresponde a um processo de
repetição.
Um diagrama de interação mostra as interações por meio de uma visão

dinâmica do sistema. Pode representar um sistema, subsistema, operação,
classe ou cenário de um caso de uso, sendo essa última representação a mais
frequente. Um diagrama de interação é formado, basicamente, por objetos,
relacionamentos e mensagens. Os diagramas de interação se apresentam de
duas formas:
diagramas de seqüências
diagramas de colaboração
Esses diagramas possuem cada qual alguns aspectos que os

diferenciam. O diagrama de seqüências enfatiza a seqüência de mensagens
dentro de uma linha de tempo, enquanto que o de colaboração enfatiza o
relacionamento estrutural entre os objetos, sem se preocupar com o tempo
determinado para cada interação.
3
Traçando um paralelo: suponha que no Restaurante A sei que o garçom

leva dez minutos até trazer meu pedido e levo vinte minutos comendo. Espero
mais cinco minutos pela conta e outros cinco minutos pelo troco. Devo lembrar
que a conta só é trazida depois que termino minha refeição. Quando vou ao
Restaurante B, não preciso me preocupar com o tempo. Assim, não olho toda a
hora para o relógio. Sei que faço um pedido ao garçom, ele atende meu
pedido, recebo a conta, pago, pego o troco e vou embora. Só não dá para
afirmar se a conta chega antes de terminar a minha refeição ou não.
Assim, o Restaurante A seria similar ao diagrama de seqüências, no qual as
mensagens são trocadas entre os objetos (nesse caso: cliente e garçom), com
demonstração do tempo de processamento (não necessariamente com valor
definido (10 minutos). O Restaurante B seria similar ao Diagrama de
Colaboração, no qual as mensagens são passadas de um objeto a outro sem
indicar o tempo de processamento de cada uma.
É interessante ressaltar que esses diagramas apresentam formas

diferentes de modelar os mesmos elementos. É como se ordenássemos uma
mesma lista de duas maneiras distintas. Apesar da visão ser diferente,
estamos lidando com os mesmos dados.
4
Diagrama de seqüências
Para melhor ilustrar a interação de um Diagrama de Seqüências, vamos

imaginar um processo X qualquer de uma empresa, na qual trabalham os
funcionários Antônio, João e Carlos. Num dado instante, o Gerente da empresa
solicita ao Antônio que prepare um relatório de comissões para um
determinado mês. Entretanto, para que o Antônio consiga preparar esse
relatório, ele precisa do total de cada vendedor, obtido no mês em foco, e essa
informação quem tem é o João. Então, Antônio passa um e-mail para o João
pedindo essa informação.
João quando recebe essa mensagem (eletrônica) inicia os procedimentos

necessários para relacionar as vendas de cada vendedor. Todavia, ele só possui
em mãos a matrícula de cada vendedor e seu total vendido. Mas ele pode
conseguir o nome de cada vendedor com o Carlos. Assim, João passa um e-
mail para o Carlos, enviando no corpo da mensagem a lista de matrículas que
ele possui, solicitando que seu colega diga a quem pertence.
Carlos, ao receber a mensagem, procura em suas fichas os nomes dos

vendedores. De posse desses nomes, ele responde ao e-mail de João,
acrescentando os nomes dos vendedores. João, ao receber a resposta de
Carlos, responde a mensagem original de Antônio, acrescentando no corpo da
mensagem a lista de vendedores (com matrícula e nome) acompanhada dos
totais de vendas de cada um.
Antônio, feliz da vida pois a equipe é bem entrosada, abre a mensagem

de resposta, pega as informações recebidas e coloca em seu relatório. Nada
como uma empresa que funciona! Guardadas as devidas proporções, se
trocarmos os funcionários Antônio, João e Carlos pelas responsabilidades que
eles possuem, temos a encenação da troca de mensagens entre objetos em
um diagrama de seqüências.
Antônio é um captador e transmissor de informações; será nossa tela de

Relatório. João é responsável por controlar as vendas do mês; será nosso
objeto Vendas. Carlos é responsável por controlar o cadastro dos vendedores;
será nosso objeto vendedor.
A representação gráfica de um diagrama de seqüências é baseada em

duas dimensões. A primeira dimensão é vertical e representa as mensagens
trocadas no decorrer de um tempo de vida (eixo Y). A segunda dimensão é
horizontal e representa os objetos participantes das interações (eixo X). As
mensagens correspondem a chamadas de serviços dos objetos, ou seja, a
chamadas de suas operações.
Assim, estabelecemos uma interação que corresponde à representação

de um elemento do modelo (por exemplo: Diagrama de Seqüências para o
5
caso de uso Cadastro de Funcionário) e para tal relacionamos os objetos

envolvidos e desenhamos cada chamada de operação como o disparo de uma
mensagem, partindo do objeto chamador para o objeto executor da operação.
Figura 6-6: Exemplo simplificado de troca de mensagens
A representação dos objetos em um diagrama de seqüências é feita

com um retângulo alinhado no topo do diagrama, partindo dele uma linha
vertical tracejada denominada linha de vida, que é desenhada até o fim do
diagrama. A linha de vida representará a vida deste objeto dentro de um
determinado período de tempo.
6
Figura 6-7: Diagrama de seqüência para cálculo de preço do produto
Um objeto, que já existe quando a transação do diagrama tem início, é

mostrado alinhado ao topo do diagrama, de forma a ficar acima da primeira
seta de mensagem. Por outro lado, um objeto que continuará a existir, mesmo
após a finalização da transação do diagrama, tem sua linha de vida estendida
para além da última seta de mensagem.
A criação ou destruição de um objeto dentro do período de tempo total

representado pelo diagrama são mostradas desenhando-se o início ou fim da
linha de vida do objeto no ponto determinado pela criação ou destruição. No
caso da criação, a seta que representa essa mensagem é desenhada de forma
a apontar sua cabeça para o símbolo do objeto. No caso da destruição, a seta
que carrega essa mensagem é direcionada a um grande "X" colocado no fim
da linha de vida. As mensagens de criação e destruição podem ser
estereotipadas com <<create>> e <<destroy>>, respectivamente.
Abaixo você tem um exemplo de um diagrama de seqüência para

mostrar de forma simplificada o agendamento de um curso. Observe as
criações de objetos, bem como as chamadas e retornos de métodos. Note que
as expressões entre “[ ..]” representam condições que serão explicadas mais
adiante.
7
Figura 6-8: Diagrama de seqüência com mensagens de retorno
8
Figura 6-9: Diagrama de Seqüência com a criação e retorno dos objetos
9
As mensagens são enviadas de um objeto a outro, por meio de setas

que partem de uma linha de vida para outra. Essas setas são identificadas com
o nome da operação que está sendo chamada. As mensagens podem carregar
a solicitação de um processamento, a comunicação de um evento ou outras
informações relevantes para o cumprimento de responsabilidades. A seqüência
de mensagens pode ser numerada, mas seu uso é desnecessário nesse tipo de
diagrama. Na figura acima você pode ver as mensagens numeradas sendo que
os números ajudam no entendimento da ordem das mensagens.
Ao alcançar o outro lado, a seta dá início à ativação, que corresponde

ao período de tempo durante o qual um determinado procedimento de um
objeto está sendo executado. Essa ativação é mostrada graficamente como um
retângulo fino e comprido, que tem sua parte superior alinhada ao final da seta
ativadora e se estende até o fim do processamento, que pode ter uma
representação extra com uma mensagem de retorno. A mensagem de retorno
não é obrigatória. Os retornos são dados por uma linha pontilhada com uma
sea na ponte partindo do receptor da mensagem para quem a chamou.
A seta de mensagem, além do nome da operação, também pode conter

uma condição e/ou uma expressão de iteração (seqüência repetida de
mensagens). Textos de identificação como restrições de tempo, descrições de
ações durante uma ativação, entre outros, também podem ser mostrados na
margem esquerda do diagrama ou perto dos elementos que eles identificam.
Condições são colocadas dentro de colchetes e determinam que a

mensagem só será disparada se a condição for verdadeira. Por exemplo:
[instrutorOk] agendarCurso()
A iteração representa o envio da mesma mensagem diversas vezes para

o mesmo objeto, sendo comum no tratamento de coleções de objetos. Vamos
supor que tenho que chamar a operação calculaMedia() dos alunos da turma.
Marcando a iteração para a mensagem calculaMedia(), indicamos que ela deve
ser chamada várias vezes. A representação da iteração é feita dentro de
colchetes, incluindo antes do colchete inicial o símbolo (*) – A notação de
condição e iteração é a mesma para o diagrama de iteração. O texto dentro
dos colchetes indica a condição que determinará quantas vezes a mensagem
será passada. Por exemplo:
*[para cada aluno da turma] calcularMedia()

*[para cada instrutor] instrutorOk := disponivel(data)
10
No caso de chamada recursiva (um objeto passa mensagem para si

próprio), o segundo símbolo de ativação é desenhado levemente à direita do
primeiro, dando a impressão de que estão empilhados. Essa chamada
recursiva é denominada auto-chamada.
Num fluxo de controle procedural, a mensagem de retorno pode ser

omitida, pois fica implícito que, ao final da ativação, o retomo ocorrerá, ou
seja, assume-se que toda mensagem de chamada faz par com uma mensagem
de retorno. Para fluxos de controle não-procedurais (como mensagens de
processamento paralelo), mensagens de retorno devem ser mostradas
explicitamente.
Na arrumação dos objetos, deve-se colocar como o primeiro objeto

exatamente aquele que dá início à interação.
No diagrama de seqüências também representamos uma ramificação

para condições ou concorrências, que é mostrada por múltiplas setas partindo
de um ponto simples, sendo cada ramo identificado por uma condição.
Dependendo de como as condições são mutuamente exclusivas, essa
construção pode representar condicionalidade ou concorrência. Veja a figura
abaixo:
Figura 6-10: Exemplo de ramificação de mensagens
11
Diagrama de colaboração
Os objetos são distribuídos no diagrama de colaboração na ordem similar

à do diagrama de seqüências, obedecendo à seqüência de mensagens. A
colaboração entre objetos é representada por uma ligação simples
acompanhada de uma numeração sequencial e de outras informações como
condições e iterações.
Em virtude da forma como um diagrama de colaboração é apresentado,

identificamos a seqüência temporal das mensagens por meio de seqüências
numéricas. A autochamada do diagrama de seqüências é identificado como
autodelegação no diagrama de colaboração e representado como um arco
ligado ao objeto.
Na figura abaixo, a primeira mensagem é a chamada do método

obterGrade() para o objeto cursoX. O código deste método para ser concluído
necessita de informações das disciplinas do referido curso e das turmas ativas.
Então, para cada disciplina é chamado o método obterInfDisciplina() do
objeto disc1. O objeto disc1, por sua vez, necessita de informações dos pré-
requisitos das disciplinas. Então, passa uma mensagem para si mesmo,
chamando o método obterPreRequisito(). O objeto cursoX, depois que
recebe a resposta de sua mensagem n° 2, chama o método
obterTurmasAtivas() que pertence ao objeto turma 1. Repare que uma
grande diferença entre o Diagrama de Colaboração e o de Seqüências é
exatamente o que ocorre com o objeto cursoX. Não fica explícito no diagrama
as mensagens de retorno e o momento em que isso ocorre.
Figura 6-11: Diagrama de colaboração
12
Figura 6-12: Diagrama de colaboracão para o diagrama de classes
Figura 6-13: Diagrama de colaboracão com mensagens sequenciais
13
Figura 6-14: Diagrama de colaboracão com mensagens sequenciais aninhadas
14
Modelando diagramas de seqüências
O Diagrama de Seqüências é totalmente adequado para a identificação

de operações de classes. Normalmente, durante o desenho dos diagramas,
vamos percebendo as mensagens necessárias, e se elas não existirem como
operações de classe, poderão ser incluídas neste momento.
O diagrama pode ser desenhado de forma gradativa, no qual a cada

mensagem surgida, verifica-se a existência de um objeto instanciado ou não,
procedendo sua criação, se necessário.
Condições são recursos interessantes no diagrama de seqüências, mas

seu uso para separar cenários totalmente distintos pode dificultar a
compreensão do diagrama.
O uso mais frequente para o diagrama de seqüências é o de representar

cenários de um caso de uso. Vamos considerar o diagrama de classes da figura
abaixo:
Figura 6-15 - Diagrama de Classes para exemplificação do Diagrama de Seqüências
Esse diagrama de classes refere-se a um Controle das vendas efetuadas

por um conjunto de vendedores de uma loja de R$ 1,99. Nesse caso, não
controlamos os produtos vendidos. Para tanto, vamos pensar no Caso de Uso
Registrar vendas.
15
Registrar vendas
Objetivo: permite cadastrar as vendas efetuadas pêlos vendedores

Ator: Assistente de gerência
Cenário Principal
1. O sistema prepara uma lista dos vendedores cadastrados na loja.
2. O usuário informa o número da venda.
3. O usuário informa, ainda:
3.1. a data da venda;
3.2. o valor da venda;
4. O usuário seleciona o vendedor que efetuou a venda, a partir da lista já
montada pelo sistema.
5. O sistema efetua a gravação da venda.
Cenário Alternativo
Venda já cadastrada
2a. Se o número da venda já estiver cadastrado, informar ao usuário, mostrar
as informações da venda na tela e entrar em modo de alteração dos dados.
A partir desses elementos, montamos o diagrama de seqüência com os

objetos envolvidos no caso de uso mais o ator. Analisando o caso de uso
percebemos a presença da Classe Venda com seus atributos e da Classe
Vendedor, pois ninguém melhor do que ela para nos dizer quem são os
vendedores ativos.
Vejamos a figura abaixo que apresenta o diagrama de seqüências que

representa este caso de uso. Começamos o diagrama de seqüências com o
ator Assistente de Gerência. Em seguida poderíamos colocar a instância da
classe principal (Venda) ou fazer uso de uma instância de tela. Como o usuário,
ao usar a classe, o faz via uma tela. Desta forma, desenhamos os objetos que
representam instâncias da tela de cadastramento, da classe venda e da classe
vendedor.
16
Figura 6-16: Exemplo de um diagrama de seqüências a partir de uma descrição de caso de uso
Conforme dito no caso de uso, a primeira ação é do sistema, obter uma

lista de vendedores ativos. Assim, a instância de tela passa uma mensagem
para o objeto da classe Vendedor, solicitando esta lista de vendedores. Depois
de receber a resposta, o controle passa para o ator, que informa: o número da
venda. O sistema, antes de permitir que o ator prossiga seu cadastro, verifica
se a venda já foi cadastrada anteriormente, por meio do envio de uma
mensagem de busca à classe Venda. Sendo positivo, o sistema mostrará os
dados na tela, mas essa operação não precisa ser representada no diagrama
de seqüências, já que foi devidamente detalhada no caso de uso. O ator
informa a data e o valor. Em seguida, seleciona na lista montada o vendedor
que efetuou a venda. Nada mais tendo para informar, cabe ao sistema
(Logicamente que o sistema aguarda a confirmação do usuário para efetuar a
gravação. Mas essa mensagem não precisa ser mostrada) efetuar a gravação
da mesma, passando uma mensagem para a classe Venda.
17
Quando Utilizar Diagramas de Interação
Você deve utilizar diagramas de interação quando quiser observar o

comportamento de vários objetos dentro de um único caso de uso. Esses
diagramas de interação são bons para mostrar as colaborações entre objetos;
eles não são tão bons para uma definição precisa de comportamento.
Se você quer observar o comportamento de um simples objeto através

de muitos casos de uso, use um diagrama de estados. Se você quer observar o
comportamento através de muitos casos de uso ou de muitas trilhas de
execução (threads), considere um diagrama de atividades.
18
Exercícios
1 – Quais as principais diferenças entre diagrama de seqüência e

diagrama de colaboração?
2 – Construa um diagrama de seqüência para representar o processo de

entrega de um material didático
3 – Para o diagrama de seqüência da figura 69 faça um diagrama de

colaboração
19
20
21
8. Diagramas Físicos
1
Diagramas Físicos
Objetivos
 Conhecer os diagramas físicos de componentes e implantação
 Reconhecer os elementos destes diagramas
 Saber quando utilizar estes diagramas
2
Diagramas Físicos
O que são diagramas físicos?
Diagramas de Físicos mostram aspectos de implementação física,

incluindo a estrutura de componentes e a estrutura do sistema em tempo de
execução (run-time)
Eles são expressos de duas formas:
Diagrama de Componentes
Diagrama de Implantação
O Diagrama de Componentes mostra a estrutura de componentes,

incluindo os classificadores que eles especificam e os artefatos que eles
implementam.
O Diagrama de Implantação mostra a estrutura de nós nos quais os

componentes são implantados.
Esses diagramas também podem ser aplicados na modelagem de

negócios, no qual os componentes representam artefatos e procedimentos de
negócios e os nós de implantação representam a organização de unidades e
recursos (humanos e outros) do negócio.
Vamos ver agora com mais detalhes estes diagramas, começaremos pelo
diagrama de componentes.
3
Diagramas Físicos
Diagrama de Componentes
Um diagrama de componentes mostra as dependências entre

componentes de software, incluindo os classificadores que eles especificam
(isto é, classes de implementação) e os artefatos que eles implementam (isto
é, arquivos de códigos-fonte, arquivos de código binário, arquivos executáveis,
scripts).
Um diagrama de componentes representa o tipo e não a instância. Para

mostrar instâncias de componentes, utilize um diagrama de implantação.
Um diagrama de componentes é um gráfico de componentes conectados

por relacionamentos de dependência. Componentes podem ser conectados a
outros componentes por compartimentos físicos representando
relacionamentos de composição.
Classificadores que especificam componentes podem ser conectados a

eles por compartimentos físicos ou por um relacionamento estereotipado
<<reside>>. Outros-sim, artefatos que especificam componentes podem ser
conectados a eles por compartimentos físicos ou por um relacionamento
estereotipado <<implement>>.
Um diagrama contendo tipos de componente pode ser usado para

mostrar dependências estáticas, como as dependências de compilação entre
programas, que são mostradas como setas tracejadas (de dependência) de um
componente cliente para um componente fornecedor que depende dele de
alguma maneira.
Embora um componente não tenha suas próprias propriedades (isto é,

atributos, operações), ele age como um container para outros classificadores
que são definidos com propriedades. Componentes, tipicamente, expõem um
conjunto de interfaces que representam os serviços providos pêlos elementos
que neles residem. O diagrama pode mostrar essas interfaces e a chamada de
dependências entre componentes, usando setas tracejadas dos componentes
para as interfaces em outros componentes.
4
Diagramas Físicos
Componente
Um componente representa um módulo físico, implementável e

substituível, que corresponde à parte de um sistema. Um componente
encapsula a implementação e exibe um conjunto de interfaces.
Um componente corresponde às interfaces que ele expõe, interfaces

essas que representam serviços providos pêlos elementos que residem no
componente. Um componente pode ser implementado por um ou mais
artefatos, tais como: arquivos binários, arquivos executáveis ou arquivos de
script.
São tipos de componentes: os necessários para a execução de um

sistema (.exe, .dll, etc), arquivos de código fonte, arquivos de dados, tabelas,
etc.
É mostrado graficamente como um retângulo grande contendo dois

pequenos retângulos sobrepostos, partindo de seu interior para o lado de fora
do retângulo principal.
Figura 8-1 Representação gráfica de um componente
5
Diagramas Físicos
Diagrama de Implantação
Diagramas de implantação mostram a configuração de elementos de

processamento em tempo de execução e os componentes de software,
processos e objetos que são executados sobre eles. Instâncias de componentes
de software representam manifestações em tempo de execução de unidades
de código de software.
Para modelagem de negócios, os elementos de processamento em

tempo de execução incluem trabalhadores e unidades organizacionais, e os
componentes de software incluem procedimentos e documentos usados pêlos
trabalhadores e unidades organizacionais.
Um diagrama de implantação é um gráfico de nós conectados por

associações de comunicação. Os nós podem conter instâncias de
componentes. Isto indica que o componente é executado dentro do nó.
Componentes podem conter instâncias de classificadores, que indicam

que a instância reside no componente. Componentes são conectados a outros
componentes por setas tracejadas de dependência (possivelmente por meio de
interfaces). Isto indica que um componente usa os serviços de outros
componentes. Um estereótipo pode ser usado para indicar uma dependência
precisa, se necessário.
6
Diagramas Físicos
Nó
Um nó é um objeto físico que representa um recurso de processamento,

frequentemente possuindo capacidade de processamento. Os nós incluem
dispositivos de computação mas também recursos humanos ou recursos de
processamento mecânico. Os nós podem ser representados como tipos e como
instâncias.
Um nó é mostrado graficamente como uma figura que parece uma visão

tridimensional de um cubo. Um nó possui um tipo-nó.
Uma instância de nó tem um nome e um nome de tipo. O nó pode ter um

nome sublinhado, mostrado dentro ou abaixo dele. O nome do nó tem a
sintaxe:
Nome : tipo-do-nó
As normas de apresentação do nó com seu tipo são similares à

apresentação de objetos. Setas tracejadas com a palavra-chave <<deploy>>
mostram a capacidade de um tipo-nó suportar um tipo-componente.
Alternativamente, isto pode ser mostrado por símbolos de componentes
aninhados dentro de símbolos de nó.
Instâncias de componentes e objetos podem estar contidos dentro de

símbolos de instâncias de nós. Isto indica que os itens residem nas instâncias
dos nós.
Nós podem ser conectados por associações para outros nós, por meio de
um caminho de comunicação. A associação pode ter um estereótipo para
indicar a natureza do caminho de comunicação (por exemplo: o tipo de canal
ou rede). Veja abaixo a representação gráfica:
Figura 8-2: Rerpesentação gráfica de um Nó
7
Diagramas Físicos
Combinando Componentes com Diagramas de

Utilização
Embora possa projetar em separado o diagrama de utilização e o

diagrama de componentes, você também pode colocar o diagrama de
componentes no diagrama de utilização, como na figura abaixo. Você pode
fazer isso para mostrar quais componentes funcionam em que nós.
Figura 8-3: Componentes e nós juntos em um diagrama físico
8
Diagramas Físicos
As pessoas, projetam, frequentemente, estes tipos de diagramas com

símbolos que se parecem com os vários elementos. Por exemplo, elas usam
ícones especiais para servidores, PC e bancos de dados. Isso é válido em UML:
você pode tratar cada ícone como um estereótipo de um elemento de
diagrama apropriado. Geralmente, tais ícones facilitam a compreensão do
diagrama, embora eles se tornem confusos se você mostrar nós e
componentes juntos.
A arquitetura mostrada acima é de uma aplicação que estará

armazenada em um J2EE Server central o qual será acessado via web pelos
seus usuários. Nele terá uma página HTML com o link para rodar a aplicação. O
usuário deverá pela primeira vez acessar esta página e clicar no link para que
a aplicação seja baixada e instalada automaticamente pelo Java Web Start na
máquina. Durante a instalação o Java Web Start irá perguntar se o usuário
deseja criar um atalho no desktop do seu micro para futuramente rodar a
aplicação. Desta forma as próximas execuções do software podem ser feitas
clicando no ícone localizado no desktop, da mesma forma como as demais
aplicações são executadas. Após ter sido baixado e instalado o programa
passará a estar acessível para o usuário localmente na máquina. Não mais o
usuário precisará esperar o download da aplicação para poder utilizá-la. O
programa será armazenado localmente em uma espécie de cache do Java Web
Start fazendo com que nas próximas execuções ele já esteja disponível e não
precise ser baixado novamente. Caso seja atualizado algum módulo do
sistema esta atualização deverá ser colocada no servidor J2EE central, onde
antes de cada execução, se houver rede, o Java Web Start irá procurar por
atualizações do software a fim de manter sempre o mesmo atualizado para o
cliente. Caso haja alguma atualização esta será feita de forma transparente
para o usuário.
Problema: Demanda máquinas mais robustas no lado do cliente; Requer a

instalação do JRE no cliente.
Benefícios: Pode funcionar mesmo que não haja rede; Emissão de relatórios
mais fácil.
9
Diagramas Físicos
Quando Utilizar Diagramas Físicos
A maioria das pessoas projeta este tipo de informação informalmente,

mas as pessoas estão gradualmente formalizando os diagramas para se
adaptarem a UML. Projeta-se estes diagramas sempre que preciso mostrar
informação física que é diferente da informação lógica associada.
10
Diagramas Físicos
Exercícios
1 – Qual a finalidade do diagrama de componentes e do diagrama de

implantação?
2 – Para o sistema acima monte um diagrama de componentes em

conjunto com um diagrama de implantação consideranco que o sistema
deverá ser em n-camadas. Para isto escolha uma tecnologia que você gostaria
de implantar o mesmo e coloque os componentes de software necessários
para rodar o mesmo.
11
Diagramas Físicos
12
9. Apêndice 1: Extensibilidade
da UML
1
Apêndice: Extensibilidade da UML
Mecanismos de extensibilidade da UML
A UML é uma linguagem-padrão para a modelagem de sistemas

orientados a objetos. Apesar de sua padronização predefinida, a UML oferece
notações de extensão que permitem a ampliação de como podemos expressar
nossos modelos. Basicamente, podemos encontrar duas formas de extensão
da UML:
Estereótipos
Restrições
2
Estereótipos
Os estereótipos são utilizados para a classificação de novos elementos

na UML. O estereótipo é utilizado para a criação de classificações de elementos
que não foram definidos como padrão, e deve ser utilizado para o tratamento
de problemas específicos de modelagem. Os estereótipos são formados por
palavras entre ângulos duplos “<<estereótipo>>". Segue uma lista de
estereótipos predefinidos, que foram extraídos a partir do uso comum destes.
Essa lista segue a seguinte classificação:
• Estereótipos para relacionamentos de dependências.

• Estereótipos para classes.
• Estereótipos para eventos e mensagens.
• Estereótipos para componentes.
• Estereótipos para relacionamentos de generalização.
• Estereótipos para restrições.
• Estereótipos para comentários.
Estereótipos para relacionamentos de dependências
<<access>>
Especifica que o conteúdo público do pacote de destino está acessível ao
espaço do nome do pacote de origem.
<<bind>>
Especifica que a origem instância o template de destino, utilizando os
parâmetros reais dados.
<<call>>
Especifica que a operação de origem invoca a operação de destino.
<<derived>>
Especifica que o elemento-origem é derivado do elemento-destino. Isso
significa que o elemento-origem não é uma instância do elemento-destino,
mas é uma instância de um outro elemento que é um subtipo ou uma
subclasse do elemento-destino.
<<extend>>
Especifica que um caso de uso tem um comportamento estendido a partir de
um caso de uso-base.
<<friend>>
Especifica que o elemento-origem tem visibilidade especial no elemento
destino.
3
<<import>>
Especifica que o conteúdo público do pacote-destino pode ser recebido e
acessado por um pacote-origem.
<<include>>
Especifica que comportamentos comuns a mais de um caso de uso devem ser
captura em outro caso de uso que será utilizado pêlos casos de uso que lhe
deram origem.
<<instanceof>>
Especifica que o objeto de origem é uma instância do classificador de destino.
<<instantiate>>
Especifica que as operações na classe de origem criam instâncias da classe de
destino.
<<refine>>
Especifica que a origem é um grau mais alto de abstração que o destino.
<<send>>
Especifica que a operação de origem envia o evento destino.
<<trace>>
Especifica que o destino é um antecessor histórico da origem.
Estereótipos para classes
<<actor>>
Especifica um elemento que interage externamente com o sistema.
<<exception>>
Especifica um evento que pode ser ativado ou capturado por uma operação de
classe.
<<implementationClass>>
Especifica a implementação de uma classe em uma linguagem de
programação.
<<interface>>
Coleção de operações que pode ser utilizado para definir os serviços que uma
classe pode oferecer a outras.
<<powertype>>
Especifica um classificador cujas instâncias de suas classes estão envolvidas
em um relacionamento de generalização.
4
<<process>>
Especifica um classificador cujas instâncias representam um fluxo pesado.
<<signal>>
Especifica um estímulo assíncrono comunicado entre instâncias.
<<stereotype>>
Especifica que o classificador é um estereótipo que pode ser aplicado a outros
elementos.
<<thread>>
Especifica um classificador cujas instâncias representam um fluxo leve.
<<type>>
Especifica uma classe abstraia que é utilizada somente para determinar a
estrutura e o comportamento de um conjunto de objetos.
<<utility>>
Especifica classes cujos atributos e operações são todos escopo de classes.
Estereótipos para eventos e mensagens
<<becomes>>
Especifica que o objeto-destino é o mesmo objeto que o de origem, mas em
um ponto adiante no tempo e com possíveis valores, estados ou papéis
diferentes.
<<copy>>
Especifica que o objeto de destino é uma cópia exata do objeto-origem, mas é
independente.
<<create>>
Especifica que o objeto-destino é criado pelo evento ou pela mensagem
enviada pelo objeto-origem.
<<destroy>>
Especifica que o objeto-destino é destruído pelo evento ou pela mensagem
enviada pelo objeto-origem.
Estereótipos para componentes
<<table>>
Especifica um componente que representa uma tabela de banco de dados no
sistema.
5
<<documents>>
Especifica um componente que representa um documento do sistema.
<<executable>>
Especifica um componente que representa um componente que poderá ser
executado no sistema.
<<file>>
Especifica um componente que representa códigos-fonte ou dados.
<<library>>
Especifica um componente que representa uma biblioteca de objetos.
Estereótipos para relacionamentos de generalização
<<implementation>>
Especifica que o filho herda a implementação do pai, mas não a torna pública,
nem oferece suporte para suas interfaces, violando dessa forma a
característica de permitir substituições.
Estereótipos para restrições
<<invariant>>
Especifica uma restrição que sempre precisa ser mantida para o elemento que
está associado.
<<precondition>>
Especifica uma condição que deve ser verdadeira antes da invocação de uma
operação.
<<poscondition>>
Especifica uma condição que deve ser verdadeira após o término da execução
de uma operação.
Estereótipos para comentários
<<requirement>>
Especifica uma característica ou comportamento desejado para um sistema.
<<responsability>>
Responsabilidade ou obrigações que um elemento é encarregado de cumprir.
6
Restrições
As restrições ampliam o vocabulário dos elementos na UML, permitindo

modificar ou acrescentar novas regras aos elementos do modelo. Por exemplo,
por uma questão de regra de negócio, todos os clientes do tipo pessoa física
devem ter obrigatoriamente o salário informado. Podemos expressar essa
restrição como no exemplo a seguir. As regras devem ser expressa entre
chaves {}.
{ PessoaFisica.salário > O } Exemplo de uma restrição simples
Alguns padrões para restrição
A UML também define como padrão algumas restrições. Aqui segue uma
lista com esses padrões com o elemento a qual se aplica.
Restrições para generalização
{complete}
Especifica que todos os subtipos de um supertipo já foram especificados, não
permitindo filhos adicionais.
{incomplete}
Especifica que nem todos os subtipos de um supertipo foram totalmente
especificados, permitindo filhos adicionais.
{overllaping}
Especifica que subtipos de um supertipo podem ter mais de um filho como
tipo.
Restrições para instâncias
{destroyed}
Especifica que a instância deve ser destruída antes da conclusão da interação
da qual ela faz parte.
{new}
Especifica que a instância deve ser criada durante a execução da interação da
qual ela faz parte.
{transient}
Especifica que a instância deve ser criada durante a execução da interação da
qual ela faz parte, mas é destruída antes da conclusão da execução.
7
Glossário
abstração
Característica essencial de uma entidade que a diferencia de todos os outros
tipos.
agregação
Tipo de associação na qual um todo é relacionado com suas partes
(relacionamento todo/parte).
agregada
Classe que representa o "todo" no relacionamento de agregação.
arquitetura
Arquitetura de sistemas é um conjunto de decisões sobre artefatos e
elementos que formaram o sistema. A arquitetura deve abranger como será
construído o sistema, seus elementos estruturais e comportamentais, suas
colaborações, etc.
artefato
Conjunto de informações utilizado ou realizado por um processo de
desenvolvimento de sistemas de software.
assinatura
Nome, parâmetros e valores de retomo de uma operação.
associação
Associação descrê vê relacionamentos entre objetos. Cada associação tem
duas pontas, onde em cada ponta está ligado um objeto.
atividade
Estado de execução de alguma coisa. Pode ser, por exemplo, a execução de
um método em uma classe, uma rotina de trabalho, etc.
ator
Papel desempenhado por qualquer usuário de um caso de uso, ou seja, o ator
é quem solicita os serviços disponíveis em casos de uso.
atributo
Atributo é uma propriedade de classe. Representa as características próprias
de uma abstração.
autochamada
Mensagem que um objeto envia para si mesmo.
característica comportamental
Característica dinâmica de um elemento, como uma operação ou um método.
8
característica estrutural
Característica estrutural (estática) de um elemento.
cardinalidade
Número de elementos existentes em um conjunto.
caso de uso
Documento que descreve os cenários pretendidos para um sistema, com o
objetivo de atender as necessidades do usuário.
classe
Abstração de um conjunto de objetos que compartilham os mesmos atributos,
operações e relacionamentos.
colaboração
Nome dado à interação entre duas ou mais classes, com o objetivo de fornecer
algum comportamento cooperativo.
componente
Parte física de um sistema, que representa elementos lógicos para a realização
de uma ou mais interfaces.
comportamento
Resultados produzidos por eventos e métodos.
composição
Forma de agregação, em que o objeto-parte pode pertencer somente ao
objeto-todo. Além disso, geralmente o objeto-todo vive e morre com suas
partes, isto é, acontece uma remoção em cascata
container
Objeto que existe para conter outros objetos e que proporciona operações para
acessar ou interagir com seu conteúdo.
delegação
Habilidade de um objeto enviar uma mensagem a um outro objeto como
resposta a uma mensagem recebida.
dependência
Relacionamento entre dois itens, em que a alteração do item independente
pode alterar a semântica do item dependente.
destinatário
Objeto que manipula a instância de uma mensagem passada pelo objeto
emissor.
diagrama
Representação gráfica de um conjunto de elementos do sistema, que permite a
visualização do sistema sob diferentes perspectivas.
9
diagrama de atividades
Representa um fluxo de controle de atividades, que ocorrem no processo de
um sistema, oferecendo suporte para comportamentos condicionais e
paralelos
diagrama de casos de uso

Representa um conjunto de cenários identificados, que seja útil aos usuários
de um sistema.
diagrama de classes
Representa o modelo da estrutura de um sistema orientado a objetos,
demonstrando as classes, os tipos e os relacionamentos.
diagrama de colaboração
Um dos diagramas de interação que dá ênfase à organização estrutural dos
objetos que colaboram entre si.
diagrama de componentes
Representa os componentes que farão parte dos sistemas em construção,
demonstrando as dependências entre esses componentes.
diagrama de gráficos de estados

Representa os estados possíveis de um objeto em particular. São
demonstrados os estados de um objeto, eventos, transições e atividades.
diagrama de implantação
Representa a configuração e a arquitetura de um sistema a que estarão
ligados seus respectivos componentes, podendo ser representada também a
arquitetura física de hardwares, processadores, etc.
diagrama de objetos
Representa a modelagem de instâncias das classes de um sistema em
determinado ponto e momento de execução.
diagrama de seqüência
Um dos diagramas de interação que dá ênfase à ordenação sequencial em que
os comportamentos acontecem.
encapsulamento
Mecanismo usado para ocultar os dados, a estrutura interna e os detalhes de
implementação de um objeto. Toda a interação com um conjunto de objetos é
feita de uma interface pública constituída de operações.
estado
Situação vivida por um objeto, pela qual esse objeto deve responder algo aos
eventos gerados.
estereótipo
Extensão do vocabulário da UML que permite a criação de novos tipos de
blocos de construção, para atender necessidades específicas de um modelo.
10
estímulo
Evento gerado no sistema que necessita de resultados.
evento
Ocorrência de um estímulo gerado para o objeto, capaz de fazer a mudança de
seu estado atual.
exportar
Tornar visível um elemento fora do espaço do nome que o contém.
expressão
Seqüência de caracteres que tem como resultado um valor.
expressão booleana
Tem como resultado um valor booleano.
filha
Subclasse.
foco de controle
Indicador do período de duração pelo qual os objetos estão cooperando para
realizar um comportamento.
generalização
É a capacidade de se criar superclasses que encapsulam a estrutura e o
comportamento comum a várias subclasses.
herança
Mecanismo pelo qual elementos mais específicos incorporam a estrutura e o
comportamento de elementos mais gerais.
herança múltipla
Uma variação da generalização, em que uma subclasse pode herdar a
estrutura e o comportamento de mais de uma superclasse.
hierarquia de classes
Representa descrições das relações de herança entre classes.
implementação
Realização concreta do contrato declarado por uma interface ou a definição de
como algo é construído ou computado.
incompleto
Modelagem de um elemento em que faltam certas partes.
instância
Manisfestação concreta de alguma abstração, uma entidade à qual um
conjunto de operações pode ser aplicado e que tem um estado para armazenar
o efeito das operações.
11
integridade
Relacionamento consistente e apropriado entre dois ou mais elementos.
interação
Conjunto de objetos que interagem por meio da troca de mensagens, para a
realização de um comportamento.
linha de vida do objeto

Representa a existência de um objeto em uma interação.
mãe
Superclasse.
máquina de estados
Seqüência de estados pela qual um objeto passa durante seu tempo de vida.
mecanismos de extensabilidade
Um dos mecanismos que permite a extensão da UML de maneira organizada.
mensagem
Meio de comunicação entre objetos que contêm informações à espera de
atividades que acontecerão.
método
Implementação de uma operação para uma classe.
modelo
Simplificação da realidade, criado com a finalidade de proporcionar uma
melhor compreensão do sistema que será gerado.
multiplicidade
Indicação de quantos objetos podem participar de um dado relacionamento.
nó
Elemento físico existente em tempo de execução que representa um recurso
computacional.
nota
Representa comentários, observações e esclarecimentos que se podem utilizar
para qualquer elemento da UML.
objeto
Sinónimo de instância de classe, sendo uma manifestação concreta de uma
abstração com uma identidade que encapsula estados e comportamentos.
objeto persistente
Objeto que sobrevive após o término de execução de um processo ou um
thread.
12
objeto transiente
Objeto que sobrevive somente até o término de execução de um processo ou
um thread.
operação
Procedimento de chamada em um objeto.
operação polimórfica
Uma mesma operação que é implementada de maneira diferente por dois ou
mais tipos.
orientado a casos de uso

Processo pelo qual os casos de uso são utilizados como artefatos primários
para o estabelecimento do comportamento desejado do sistema, para verificar
e validar a arquitetura de um sistema.
pacotes
Organizam os modelos criados na UML.
pai
Superclasse.
papel
Comportamento de uma entidade que participa de determinado contexto no
sistema.
parâmetro
Especificação de uma variável que pode ser alterada, passada ou retornada.
polimorfismo
Conceito segundo o qual dois ou mais tipos de objetos podem responder à
mesma mensagem de maneiras diferentes, usando operações polimórficas.
pós-condição
Algo que necessita ser verdadeiro após a chamada de uma operação.
pré-condição
Algo que necessita ser verdadeiro antes da chamada de uma operação.
privado
Mecanismo de escopo usado para restringir o acesso a atributos e operações
de uma classe, de maneira que outros objetos não possa utilizá-los.
produto
Artefatos de desenvolvimento, como códigos, modelos, documentação gerada,
etc.
propriedade
Característica de um elemento da UML.
público
13
Mecanismo de escopo usado para tornar atributos e operações de classes

acessíveis a outros objetos.
raia de natação
Organiza as atividades representadas em diagramas de atividades. Essa
organização consiste em criar grupos que são responsáveis pelas atividades
ocorridas.
realização
Relacionamento entre itens, no qual um item implementa comportamentos
especificados por outros.
receptor
Objeto ao qual é enviada uma mensagem.
refinamento
Relacionamento que representa a especificação completa de algo já
especificado em determinado nível de detalhe.
relacionamentos
Conexão semântica entre elementos.
responsabilidade
Contrato ou obrigação em um tipo ou de uma classe.
restrição
Extensão da semântica de um elemento da UML, permitindo criar ou modificar
regras já existentes.
solicitação
Especificação de um estímulo enviado a um objeto.
subclasse
Elemento que recebe por herança a estrutura e os comportamentos de uma
superclasse.
superclasse
Elemento que contém a estrutura e o comportamento generalizado de outras
classes (as subclasses).
thread
Fluxo leve de controle que pode ser executado concorrentemente com outros
threads no mesmo processo.
tipo
Estereótipo de uma classe, utilizado para especificar um domínio de objetos,
com as operações que podem ser aplicadas aos objetos.
transição
14
Relacionamento entre dois estados, em que o objeto no seu estado atual deve
realizar atividades para passar para um outro estado, desde que as atividades
tenham sido cumpridas.
UML (Unified Modeling Language)

Linguagem de modelagem unificada para visualização, especificação,
construção e documentação de artefatos de sistemas de software.
valor atribuído
Extensão das propriedades de um elemento da UML, que permite a criação de
novas informações na especificação desse elemento.
versão
Um conjunto de artefatos de software, relativamente completos e consistentes
que serão entregues.
visão
Projeção em um modelo, vista a partir de determinada perspectiva ou ponto de
vista, que omite as entidades que não são relevantes para essa visão.
visão dinâmica
Aspectos de um sistemaque dão ênfase a comportamentos.
visão estática
Aspectos de um sistema que dão ênfase à estrutura.
visibilidade
Especificação de como uma característica ou um comportamento especificado
para uma classe podem ser vistos por outros objetos de classe.
15
10. Apendice 2: Diagramas

UML dos exercicícios
1
2
3
4
5
6
7
8
9
10

Apostila para Curso de UML

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apostila para Curso de UML

Hochgeladen von

Copyright:

Verfügbare Formate

UML:

Unified Modeling Language

2. Diagrama de Use Case..............................................................2-1

9. Apêndice: Extensibilidade da UML.............................................9-1

No curso anterior estudamos os conceitos de orientação a objetos e

O grande problema do desenvolvimento de novos sistemas utilizando a

Quando a "Unified Modeling Language" (UML) foi lançada, muitos

A UML é muito mais que a padronização de uma notação. É também o

Veremos neste curso como a UML aborda o caráter estático e dinâmico

utilização de "packages" próprios da linguagem a ser utilizada, utilização do

Não é intuito deste curso definir e explicar os significados de classes,

Desenvolvimento de software orientado a

Os conceitos da orientação a objetos têm sido discutidos há muito

Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram,

A orientação a objetos é uma tecnologia para a produção de modelos

Quando construídos corretamente, sistemas orientados a objetos são

Modelos orientados a objetos são implementados convenientemente

A orientação a objetos não é só teoria, mas uma tecnologia de

A orientação a objetos requer um método que integre o processo de

UML – A unificação dos métodos e criação de

A UML é uma tentativa de padronizar a modelagem orientada a objetos

Existem várias metodologias de modelagem orientada a objetos que até

Falaremos sobre algumas das principais metodologias que se tornaram

 Booch – O método de Grady Booch para desenvolvimento orientado a

 OMT – Técnica de Modelagem de Objetos (Object Modelling Technique) é

 OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos

Cada um destes métodos possui sua própria notação (seus próprios

atividades são desenvolvidas em diferentes partes do desenvolvimento), e

Diante desta diversidade de conceitos, "os três amigos", Grady Booch,

Os objetivos da UML são:

 A modelagem de sistemas (não apenas de software) usando os conceitos

 Estabelecer uma união fazendo com que métodos conceituais sejam

 Criar uma linguagem de modelagem usável tanto pelo homem quanto

A UML está destinada a ser dominante, a linguagem de modelagem

A UML é usada no desenvolvimento dos mais diversos tipos de sistemas.

O objetivo da UML é descrever qualquer tipo de sistema, em termos de

 Sistemas de Informação: Armazenar, pesquisar, editar e mostrar

 Sistemas Técnicos: Manter e controlar equipamentos técnicos como de

 Sistemas Real-Time Integrados: Executados em simples peças de

 Sistemas Distribuídos: Distribuídos em máquinas onde os dados são

 Sistemas de Software: Definem uma infra-estrutura técnica que

 Sistemas de Negócios: descreve os objetivos, especificações (pessoas,

É importante perceber que a maioria dos sistemas não possuem apenas

Fases do Desenvolvimento de um Sistema

Atualmente existem muitos processos para desenvolvimento de software

Esta fase captura as intenções e necessidades dos usuários do sistema a

A fase de análise está preocupada com as primeiras abstrações (classes

Na fase de design, o resultado da análise é expandido em soluções

Na fase de programação, as classes provenientes do design são

Um sistema normalmente é rodado em testes de unidade, integração, e

O sistema será testado pelo usuário final o qual verificará se os

1. Cite e descreva, brevemente, os principais métodos que deram origem a

2. Que tipos de sistemas podem fazer uso da UML?

3. Quais são as fases do desenvolvimento de software? Quais são as

Espaço para anotações

2. Diagrama de Use Case

Definição de Use Case

Neste capítulo iremos estudar um dos diagramas centrais da UML, o

Os requisitos que um sistema possui muitas vezes são complexos, não

A Língua Portuguesa, assim como outras, é ambígua, por natureza.

A UML e a modelagem de casos de usos não interfere nas técnicas

O levantamento de requisitos de um sistema não é uma tarefa fácil, mas

Sabemos que os problemas existem, mas com as técnicas, ferramentas e