Prévia do material em texto

MODELAGEM DE SISTEMAS 
As empresas necessitam, hoje em dia, de Sistemas de Informações que agreguem 
muitas funcionalidades, atendam aos 3 níveis da organização (operacional, tático e 
estratégico) tornando-os, consequentemente, grandes, complexos e robustos. 
As empresas privilegiam o emprego de conhecimento em seus processos de negócios e 
a consequente representação deles nos Sistemas de Informação. 
Os usuários têm pressa na implantação dos sistemas, para que possam desempenhar 
suas tarefas com desenvoltura e precisão. 
 O desenvolvimento de sistemas precisa se apoiar em ferramentas eficientes, que 
auxiliem processos de desenvolvimento sustentáveis. A UML (Unified Modelling Language) 
destaca-se como uma ferramenta de modelagem de sistemas, dentro da perspectiva do 
desenvolvimento orientado a objetos, aplicável a processos de desenvolvimento de software. 
Oferecendo um conjunto de diagramas integrados, permite exprimir, em diversas visões, as 
perspectivas do sistema. O interessante é que essa linguagem de modelagem unificada traz 
consigo a possibilidade de ser agregada a empresas de pequeno, médio e grande porte, que 
usem diferentes processos de desenvolvimento de sistemas. 
A capacidade de representação do negócio através de modelos da UML e a visibilidade 
para a construção do sistema são competências que devem ser desenvolvidas no aluno desta 
disciplina. 
Ao final do curso, o aluno será capaz de: 
 Solucionar problemas do mundo real; 
 Conhecer os mais relevantes diagramas da UML; 
 Aplicar os modelos ao desenvolvimento de sistemas. 
Aula 1: Orientação a objetos UML 
Introdução: 
 A modelagem de sistemas consiste no desenvolvimento de modelos (diagramas) que 
representem o mundo real, sob a perspectiva do desenvolvimento de sistemas e está 
intimamente relacionada a dois fatores: ao paradigma de desenvolvimento e ao processo de 
desenvolvimento em uso. 
No paradigma orientado a objetos, o enfoque está na identificação de classes e seus 
respectivos objetos que interagem para a solução do problema. 
Dentro da perspectiva do desenvolvimento orientado a objetos, surge a UML (Unified 
Modelling Language), uma linguagem unificada de modelagem, que permite aos 
desenvolvedores construírem diagramas sob diferentes perspectivas. Nesta aula, vamos 
conhecer esses conceitos. 
Desenvolvimento de sistemas 
 O desenvolvimento de sistemas é um processo intelectual e progressivo, em que os 
profissionais envolvidos adquirem mais conhecimento do sistema à medida que avançam no 
entendimento da realidade em que o sistema está inserido. 
 Tomemos como exemplo a criação de um sistema que gerencie as atividades de um 
estacionamento de veículos: 
 No início do processo, é preciso conversar com os profissionais envolvidos no negócio 
em questão para compreender a realidade e o funcionamento do mesmo. No primeiro dia, 
nada conhecemos do negócio estacionamento, no quinto dia de estudo, por exemplo, o 
conhecimento da realidade é mais apurado. 
Representação da realidade 
 Para representar a realidade e entender o que se passa no contexto do sistema a ser 
construído, precisamos traduzir a realidade em modelos. 
No contexto de desenvolvimento de sistemas, o que são modelos? 
Nada mais são que diagramas gráficos que representam a realidade e ajudam os 
desenvolvedores a compreendê-la. Portanto, modelar um sistema consiste em criar um 
conjunto de modelos sob a forma de diagramas, que representam a estrutura e o 
comportamento de um sistema. 
Podemos citar como exemplo o caso de uma construtora que, quando idealiza um 
empreendimento, constrói uma maquete que representa a realidade, ou seja, ela constrói um 
modelo da realidade. Pela maquete, tanto a equipe de construção como os clientes têm a 
noção do que será o empreendimento (disposição no terreno, área comum etc.), diminuindo, 
consideravelmente, a abstração e aproximando-o da realidade. Da mesma forma, um 
diagrama gráfico representa o sistema, sob determinada visão. 
Mas a maquete não é o único modelo usado para uma construção civil. São 
necessárias, também, diferentes plantas que descrevam as características de cada etapa da 
construção, tais como planta baixa, planta hidráulica, planta elétrica e outras. Analogamente a 
essas plantas, temos, no contexto da modelagem de sistemas, outros diagramas, que ajudarão 
os técnicos a especificar como o sistema deve ser construído. 
Conceitos do Paradigma Orientado a Objetos 
 Podemos dizer que a representação da realidade ocorre por meio de paradigmas. 
 Paradigma é uma forma de abordar um problema. 
 Até o final dos anos 1980, prevaleceu o paradigma imperativo ou estruturado, 
caracterizado pelo uso das técnicas de Análise Estruturada e Análise Essencial, que foram 
eficientes para sistemas de pequeno porte. 
À medida que os sistemas se tornaram mais complexos e robustos, uma nova 
abordagem se fez necessária para estudar, entender e modelar o sistema a ser desenvolvido. 
Surgia o paradigma Orientado a Objetos, também chamado paradigma OO. 
Na modelagem sob o enfoque da orientação a objetos (OO), a tarefa principal passa a 
ser a identificação dos objetos do mundo real envolvidos no contexto do sistema e a relação 
entre eles. Ao identificar os objetos, são identificados também os dados (atributos) e as 
funcionalidades (funções) inerentes àquele objeto, conforme ilustrado na equação abaixo. 
OBJETO = DADOS + FUNÇÕES 
Na medida em que são identificados todos os objetos pertinentes a um sistema, já 
teremos os dados e os procedimentos relacionados. 
EXEMPLO 
 Considerando o contexto de um sistema bancário (ilustrado pela imagem a seguir), 
podemos citar os objetos agência, cliente e conta, e a relação “Cliente possui uma conta em 
uma agência”. 
Ao identificar os objetos, são identificados, também, os dados (atributos) e as 
funcionalidades (funções) inerentes àquele objeto, conforme ilustra a imagem. O objeto 
cliente possui os dados nome, endereço, telefone e CPF e, sobre ele, podem ser realizadas, por 
exemplo, as funções de Incluir Novo Cliente, Excluir Cliente Inativo, Inativar Cliente. 
 
Orientação a Objeto (OO) 
 Um modelo OO tem com entidade fundamental o Objeto, que recebe e envia 
mensagens, executa procedimentos e possui um estado que, por proteção, apenas ele 
próprio pode modificar. Nesse processo, problemas são resolvidos, por meio de objetos, que 
enviam mensagens uns aos outros. 
 O Modelo OO é formado por alguns elementos básicos: 
 OBJETO: É o principal elemento do modelo OO. Representam as “coisas” a 
serem modeladas do mundo real. Um objeto pode ser algo concreto como um 
carro, um aluno ou algo abstrato como uma disciplina, um curso. Cada objeto 
possui os dados inerentes a ele, como por exemplo, Nome (José) e Matrícula 
(201101272201) de um objeto Aluno e possui as operações que ele executa, 
como incluir novo aluno ou alterar dados de um aluno existente. 
 MENSAGENS: Quando um objeto deseja que seja executada uma operação de 
responsabilidade de outro objeto, ele manda uma mensagem a esse objeto 
informando o que ele deseja que seja feito. A operação desejada será 
implementada por meio de um método da classe que recebe a mensagem, 
conforme a imagem abaixo: 
 
 
 ATRIBUTOS: São dados que caracterizam o objeto. 
 MÉTODOS: É um procedimento (implementado por uma rotina ou função) que 
executa uma operação em um objeto, que define parte de seu 
comportamento. 
 CLASSES: É um conjunto de objetos com as mesmas características (atributos 
e métodos). Conforme ilustrado na imagem a seguir, Maria e Pedro são 
objetos da classe PESSOA, cujas características em comum são: 
• Atributos: Nome, Endereço, Telefone, Idade e Altura.• Métodos: Registrar( ), Matricular( ), Pagar( ), Estudar( ) e Cadastrar( ). 
 
Podemos dizer, portanto, que “Objeto é uma instância 
de uma classe”, isto é, a classe é o molde e o objeto, a 
“coisa real”. 
 
 
 
Existe uma diferença entre os conceitos de classes e objetos. Para visualizar um 
exemplo dessa diferença, clique no botão ao lado: 
Um exemplo da diferença entre o conceito de classes e objetos, ou seja, é habitual 
dizermos que “Objeto é uma instância de uma classe”, isto é a classe é o molde e o objeto a 
“coisa real”. 
 
Os pilares do paradigma Orientado a Objetos 
 A orientação a objetos tem como alicerce alguns princípios fundamentais. 
Juntos, eles permitem que classes sejam reaproveitadas, otimizando tempo e custo de 
desenvolvimento, além da segurança no reuso das classes já usadas e testadas. Observe: 
 Encapsulamento: Encapsular significa esconder, ou seja, o objeto esconde 
seus dados (atributos) do acesso indevido de outros objetos. Os dados 
somente devem ser acessados por métodos (funcionalidades que 
implementam o comportamento do objeto) da própria classe, o que pode ser 
visualizado na figura abaixo: 
 
 
 Herança: Mecanismo para derivar novas classes a partir da definição de 
classes existentes através de um processo de refinamento. 
 Polimorfismo: A palavra polimorfismo, deriva do grego, e significa “muitas 
formas”. A partir do momento em que uma classe herda atributos e métodos 
de uma (herança simples) ou mais (herança múltipla) classes base, ela tem o 
poder de alterar o comportamento de cada um desses procedimentos 
(métodos). 
 Visibilidade: Outro conceito fundamental, é a visibilidade entre as classes. A 
visibilidade diz respeito ao que uma classe pode visualizar da outra. Como 
princípio, devemos garantir o encapsulamento, ou seja, os atributos devem 
ser privados (acessíveis apenas por métodos da própria classe) e 
determinados métodos públicos (acessíveis por todas as classes), e acessar 
esses dados. 
Os pilares do paradigma Orientado a Objetos 
Dentre as principais características do paradigma orientado a objeto (OO), 
destacamos: 
Encapsulamento: 
Encapsular significa esconder. O objeto esconde seus dados (atributos) do acesso 
indevido de outros objetos. Os dados somente devem ser acessados por métodos 
(funcionalidades que implementam o comportamento do objeto) da própria classe, o que 
pode ser visualizado na figura abaixo (Encapsulamento). 
O encapsulamento é uma técnica para minimizar a interdependências entre as classes, 
pois apenas os métodos da respectiva classe podem alterar seus dados (atributos), facilitando 
a identificação de erros e a alteração dos programas. 
 
Herança: 
 Mecanismo para derivar novas classes a partir da definição de classes existentes 
através de um processo de refinamento. Uma classe derivada ou descendente herda os dados 
(atributos) e comportamento (métodos) da classe base ou ancestral ou ascendente. 
 Conforme ilustrado na figura abaixo, as classes ContaPoupança e ContaInvestimento 
herdam da classe Conta, os atributos e métodos que são permitidos. A classe Conta é chamada 
Classe base, uma vez que é a base da herança. Veja: 
 
A implementação da herança garante a reutilização de código, que além de 
economizar tempo e dinheiro, propicia mais segurança ao processo de desenvolvimento, posto 
que as funcionalidades da classe base já foram usadas e testadas. 
 
 
Polimorfismo: 
A palavra polimorfismo, deriva do grego, e significa “muitas formas”. A partir do 
momento em que uma classe herda atributos e métodos de uma (herança simples) ou mais 
(herança múltipla) classes base, ela tem o poder de alterar o comportamento de cada um 
desses procedimentos (métodos). Isso amplia o poder do reaproveitamento de código 
promovido pela herança, permitindo que se aproveite alguns métodos e se altere (redefina) 
outros. 
Dessa forma, um método com mesmo nome, em classes distintas, pode ter diferentes 
comportamentos. Acompanhe o exemplo da figura abaixo, onde identificamos uma herança: 
Pagamento em Dinheiro, Pagamento em CC (Cartão de crédito) e Pagamento em Cheque 
herdam da classe Pagamento, o atributo o método Pagar_Conta (Valor: double, troco: double). 
Observe que em cada classe filha (Pagamento em Dinheiro, Pagamento em cartão e 
pagamento em Cheque) escreve novamente o método Pagar, com as respectivas 
particularidades necessárias a cada forma de pagamento. Essa possibilidade ocorre pelo 
princípio do polimorfismo. 
 
Visibilidade: 
Outro conceito fundamental é a visibilidade entre as classes. A visibilidade diz respeito 
ao que uma classe pode visualizar da outra. Como princípio, devemos garantir o 
encapsulamento, ou seja, os atributos devem ser privados (acessiveis apenas por métodos da 
própria classe) e determinados métodos públicos (acessíveis por todas as classes), e acessar 
esses dados. 
Por outro lado, se mantivermos todos os métodos como sendo privados, a classe 
perde o sentido, pois nenhuma outra poderá usar seus métodos. Então, devemos usar a 
visibilidade com equilíbrio e sabedoria. 
Outra visibilidade possível, além de privada e pública, é a protegida, onde os atributos 
e os métodos somente pode ser vistos dentro da estrutura de herança, ou seja, pelas classes 
filhas. 
Na figura que vimos acima, o atributo Valor e o método Pagar_Conta (Valor :int) da 
classe Pagamento, somente podem ser acessados pelas classes Pagamento em Dinheiro, 
Pagamento Cartao e Pagamento Cheque. 
Conclusões do paradigma Orientado a objetos 
 Seguem algumas das conclusões do paradigma OO: 
 O uso de técnicas orientadas a objetos facilita o controle da complexidade 
uma vez que promove uma melhor estruturação de seus componentes e 
também permite que componentes já usados e validados possam ser 
reaproveitados. 
 As hierarquias de classes (herança) são componentes portáveis entre 
aplicações, que, se bem projetados, podem ser reutilizados em vários sistemas 
sem modificação e, além disso, podem ser estendidos (polimorfismo) sem 
corromper o que já existe. 
 Proporciona modularidade trazendo os seguintes benefícios: 
o Reusabilidade: softwares podem ser escritos com base em 
componentes já existentes; 
o Extensibilidade: novos componentes de software podem ser 
desenvolvidos a partir de outros, já existentes, sem afetar o 
comportamento do componente de origem. 
 Um sistema desenvolvido com as características do modelo OO tende a ser 
bem estruturado posto que os objetos são unidades coesas com interfaces 
simples que escondem as suas implementações. 
O paradigma orientado a objetos surgiu (década de 1980) como um modelo promissor 
para o desenvolvimento de software mais confiável devido às características inerentes ao 
modelo de objetos. Vejamos: 
• O conceito de encapsulamento permite a construção de classes independentes 
uma das outras, facilitando o desenvolvimento e a manutenção do software 
(alterações e melhorias na classe). 
• A herança e o polimorfismo permitem e facilitam a reutilização de código, útil nas 
fases de implementação e manutenção. 
O uso de técnicas orientadas a objetos facilita o controle da complexidade uma vez 
que promove uma melhor estruturação de seus componentes e também permite que 
componentes já usados e validados possam ser reaproveitados. 
Cabe ressaltar que uma das principais razões para a baixa produtividade, no 
desenvolvimento de software, é a dificuldade de reutilização de código usando o paradigma 
funcional. 
As hierarquias de classes (herança) são componentes portáveis entre aplicações, que, 
se bem projetados, podem ser reutilizados em vários sistemas sem modificação e, alémdisso, 
podem ser estendidos (polimorfismo) sem corromper o que já existe. 
Assim sendo, podemos dizer que o modelo de objetos proporciona modularidade 
trazendo os seguintes benefícios: 
• Reusabilidade: softwares podem ser escritos com base em componentes já 
existentes; 
• Extensibilidade: novos componentes de software podem ser desenvolvidos a 
partir de outros, já existentes, sem afetar o comportamento do componente de 
origem. 
Sabe-se que software são intrinsicamente complicados devido aos novos requisitos das 
aplicações modernas: alta confiabilidade, alto desempenho, desenvolvimento de software 
rápido e barato, alta complexidade e tamanhos grandes. 
O modelo OO veio para combater os problemas derivados da crise do software, termo 
cunhado em 1968, na Europa, e caracterizado pelos seguintes problemas do software: baixa 
confiabilidade, baixa qualidade, alto custo de manutenção e duplicação de esforços na sua 
construção (tempo e dinheiro). 
Um sistema desenvolvido com as características do modelo OO tende a ser bem 
estruturado posto que os objetos são unidades coesas com interfaces simples que escondem 
as suas implementações. Um sistema desenvolvido sob o paradigma da orientação a objetos 
representa os objetos que encontramos no mundo real, no problema que estamos tratando, 
no negócio para o qual o estamos desenvolvendo o sistema. O foco da equipe de 
desenvolvimento passa a ser a identificação e a modelagem dos objetos do mundo real que 
afetam o sistema. 
A orientação a objetos tem como alicerce três princípios fundamentais: o 
encapsulamento que protege o acesso aos atributos e métodos, a herança e o polimorfismo, 
que juntos, permitem que classes sejam reaproveitadas, otimizando tempo e custo de 
desenvolvimento, além da segurança no reuso de classes testadas e utilizadas. 
Conceitos de Análise e Projeto Orientado a Objeto 
A orientação a objetos enfatiza a identificação, a representação e a organização dos 
objetos necessários a um sistema. 
Antes de adentramos no universo da análise e projeto, sob o enfoque do paradigma 
Orientado a objeto, vamos tecer rápidos comentários acerca do que sejam as atividades de 
Análise e Projeto, dentro do contexto de desenvolvimento de software. 
Análise de sistemas significa uma investigação dos problemas e dos requisitos de um 
contexto, em particular, com vistas ao desenvolvimento de um sistema automatizado. A ideia 
básica é identificar quais seriam as funções que esse sistema precisa ter, de forma a atender 
eficientemente as necessidades de seus usuários. 
Atividade de análise e projeto 
A atividade de análise, por ser muito abrangente, costuma ser dividida em: 
• Análise de requisitos (investigação dos requisitos); 
• Análise do domínio do problema. 
No contexto específico da orientação a objetos, análise implica em identificar e 
descrever os conceitos no domínio do problema. Já na atividade de análise foca-se na 
definição dos objetos de software e como eles colaboram para que os requisitos dos usuários 
sejam plenamente satisfeitos. 
 Por outro lado, a atividade de projeto denota uma solução, voltada a atender aos 
requisitos, considerando aspectos de tecnologia. Em geral, o projeto enfoca a arquitetura do 
sistema, definindo suas partes e a relação entre elas. 
 Portanto, análise pode ser traduzida em “faça a coisa certa”, e projeto em “faça certo 
a coisa”. 
Saiba Mais: Um sistema desenvolvido sob o paradigma da orientação a objetos 
representa os objetos que encontramos no mundo real, no problema que estamos tratando, 
no negócio para o qual o estamos desenvolvendo o sistema. O foco da equipe de 
desenvolvimento passa a ser a identificação e modelagem dos objetos do mundo real que 
afetam o sistema. 
A UML como uma linguagem padrão 
A UML (Unified Modeling Language) é uma linguagem padrão para construção de 
projetos de sistemas, orientados a objeto, voltada para visualização, especificação, construção 
e documentação de artefatos de um sistema. A UML foi projetada para ser independente do 
método de desenvolvimento utilizado. Ela é uma linguagem de modelagem, não é um método 
de desenvolvimento, nem tão pouco um metodologia ou um processo de desenvolvimento de 
sistemas, uma vez que não determina a ordem e nem como os diagramas devem ser usados. 
Simplesmente disponibiliza os diagramas, sob as várias visões necessárias ao desenvolvimento 
de sistemas, e cada empresa utiliza da forma como lhe convém, ou seja, adequando a UML ao 
seu processo de desenvolvimento de sistema. 
A UML é destinada à: 
Visualização: A modelagem gráfica tende a facilitar a compreensão, permitindo sua 
interpretação sem ambiguidades. 
Especificação: Permite a construção de modelos precisos, sem ambiguidades e 
completos. A UML atende a esses quesitos sob o ponto de vista da análise, projeto e 
implementação. 
Construção: Os diagramas UML podem ser diretamente integrados a várias linguagens 
de programação tais como Java e C++. 
Documentação: A UML abrange a documentação da arquitetura do sistema e de todos 
os seus detalhes. 
Um Breve Histórico da UML 
A UML nasceu da integração de três métodos emergentes orientados a objeto, que na 
década de 1990, eram os mais populares entre os profissionais de desenvolvimento de 
sistemas: 
 • O Método OMT (Object Modeling Technique) de Jacobson; 
 • O Método OOSE (Object-Oriented Software Engineering) de Rumbaugh; 
 • O Método de Booch. Finalmente, em 1997, a UML foi adotada pela OMG (Object 
Management Group ou Grupo de Gerenciamento de Objetos), como uma linguagem padrão de 
modelagem. 
Atualmente a UML encontra-se em sua versão 2.0 (2.4.1, já existindo a 2.5 em release 
BETA), e trouxe grandes novidades em relação à estrutura geral da linguagem, principalmente 
a respeito da abordagem de quatro camadas e à possibilidade de se desenvolver “perfis” 
particulares (oficial no site da OMG em www.uml.org). 
Desde a versão inicial, a UML sofreu mudanças substanciais. 
Os diagramas da atual versão da UML 
Os diagramas da UML são divididos em 2 grupos: Diagramas de Estruturas e 
Diagramas Comportamentais. No total, eles formam 14 diagramas, conforme ilustrado pela 
imagem: 
 
A seguir, uma especificação de cada um dos diagramas: 
Diagrama de perfil Diagrama mais recente e bastante abstrato. Permite a criação de 
perfis que adapte a UML a plataformas, tecnologias ou domínios específicos, para os quais a 
linguagem não foi projetada originalmente. 
Diagrama de classes O mais popular dos diagramas. Tem muitas informações, mas a 
principal finalidade é apresentar os tipos de objetos presentes no sistema e os vários tipos de 
relacionamentos existentes entre eles. Descreve para cada classe, suas propriedades (atributos 
e métodos). 
Diagrama de estruturas compostas: Abrange um novo conceito, criado com a UML 
2.0, que é a capacidade de decompor hierarquicamente uma classe. 
 Diagrama de componentes: Apresenta diferentes componentes de um sistema, além 
de possíveis dependências entre eles. O conceito de componente diz respeito a uma parte 
física de um sistema de componente, englobando outras estruturas relacionadas (como 
classes, interfaces etc.). 
 Diagrama de implantação: Determina o ambiente físico sobre o qual o sistema vai 
operar. Determina as necessidades de hardware do sistema, evidenciando características 
físicas dos servidores, estações, protocolos de comunicação, redes etc. 
Diagrama de objetos: É um diagrama de classes, instanciado, ou seja, mostra 
exemplos de objetos de cada classe, exibindo os relacionamentos. 
Diagrama de pacotes: Pacotes são elementos que englobam outros. O mais comum 
são classes, mas têm sido usados para outros elementos,especialmente casos de uso. 
Representam a divisão de um sistema grande em partes menores (modularização). 
Diagrama de atividades: Descreve a lógica de procedimentos, processos de negócios e 
fluxos de trabalho, suportando processamento sequencial e paralelo. 
Diagrama de casos de uso: Mostra as funcionalidades do sistema e os atores que com 
elas interagem. 
Diagrama de estados: Mostra, para cada objeto do sistema, o comportamento do seu 
ciclo de vida. 
Diagrama de sequência: Mostra como os objetos interagem para a realização de um 
caso de uso, detalhando a troca de mensagens entre os objetos. 
Diagrama de comunicação: É o antigo Diagrama de Colaboração, que junto com o 
diagrama de sequência forma o diagrama de interação. Tem a mesma finalidade do diagrama 
de sequência, porém não objetiva a temporalidade (sequencia). 
Diagrama de visão geral de interação: Novidade da versão 2.0. Mistura em um único 
diagrama conceitos e elementos do diagrama de atividades e do diagrama de sequência. 
Diagrama de tempo: Novidade da versão 2.0. Outro tipo de diagrama de interação, 
onde o foco está nas restrições de temporização. Usado para demonstrar a mudança no 
estado de um objeto no tempo em resposta a eventos externos. 
A UML pode ser inserida dentro do contexto de qualquer que seja o processo de 
desenvolvimento em uso, na medida em que é independente de tecnologia e processos de 
desenvolvimento de software. 
Uso da UML 
Como a UML não determina quais diagramas usar nem por onde começar, cada um 
começa por onde desejar. Nem mesmo os idealizadores da UML conseguem usar todos os 
diagramas. Geralmente, as empresas escolhem um subconjunto deles e implementam nas 
fases de seus processos de desenvolvimento de sistemas. O ideal é que você encontre o seu 
conjunto de diagramas que funcione para o tipo de sistema que desenvolve. 
Por exemplo: muitos começam pelo Diagrama de classes, na medida em que o 
consideram o diagrama mais relevante. Porém muitos iniciam pelo Diagrama de Casos de uso, 
cuja finalidade é modelar as principais funcionalidades dos sistemas para atender às 
necessidades de seus usuários. Ambos estão usando a UML de forma correta e expressando 
como visualizam a sequência mais adequada para desenvolver sistemas. 
Martin Fowler e Steve Mellor propuseram três modos pelos quais pode-se usar a UML no 
desenvolvimento de sistemas: 
1. Uml como esboço: O modo mais usado, onde os desenvolvedores usam a UML 
como forma de expressar aspectos relevantes de um sistema, esboçando ideias e 
alternativas do que pretende fazer. É uma possibilidade de discussão com a equipe 
de desenvolvedores. Seu foco é a comunicação seletiva em vez de especificação 
completa. Geralmente, são usados desenhos informais, sem ferramentas e cujo 
objetivo é a discussão de ideias visando à construção de software de forma 
colaborativa. O modo UML, como esboço, está mais compatível com as 
metodologias ágeis, que preconizam mais código e menos documentação. 
2. UML como projeto: Foca a completeza. Aqui a ideia é construir um projeto 
completo para ser codificado por programadores, valendo-se de ferramentas case 
para melhor entendimento dos modelos pela equipe. O modo UML, como projeto, 
está mais alinhado com os processos de desenvolvimento mais complexos, como 
processos iterativos e incrementais, como o PU (processo unificado) 
implementado através da ferramenta RUP (Rational Unifiec Process) prototipação. 
3. UML como linguagem de programação: Onde os desenvolvedores desenham os 
diagramas que são compilados para o código executável e a UML se torna o código 
fonte. Exige ferramentas mais sofisticadas. O modo UML, como linguagem de 
programação, tende a ser mais usado em modelos de desenvolvimento de 
prototipação. 
Processos Iterativos de desenvolvimento e a UML 
Um processo de desenvolvimento de software descreve uma abordagem para 
organizar as atividades relacionadas com a construção, a implantação e a manutenção de 
sistemas. 
Os processos mais populares hoje são os iterativos, como: 
 O PU (Processo Unificado), em particular o RUP (Processo Unificado da 
Rational); 
 As metodologias ágeis, como o XP (eXtreming Programming) e Scrum. 
Mas o que são os processos iterativos? 
São processos onde o ciclo de vida do sistema é dividido em uma série de 
miniprojetos, curtos, preferencialmente de duração fixa (por exemplo, 3 meses), denominados 
iterações. 
Processos Iterativos de desenvolvimento e a UML 
Um processo de desenvolvimento de software descreve uma abordagem para 
organizar as atividades relacionadas com a construção, a implantação e a manutenção de 
sistemas. 
Os processos mais populares hoje são os iterativos, como o PU (Processo Unificado), 
em particular o RUP (Processo Unificado da Rational) e as metodologias ágeis, como o XP 
(eXtreming Programming) e Scrum. 
Cada iteração contém um subconjunto das funcionalidades do sistema. Em cada 
iteração, temos as atividades de levantamento de requisitos, análise de requisitos, projeto, 
implementação, testes e implantação, conforme ilustrado pela imagem a seguir. 
O ciclo de vida iterativo é baseado em incrementos sucessivos do sistema, pelas 
iterações do processo. A cada iteração um pedaço do software é incrementado, daí o nome 
processo iterático e incremental. 
Claro que entre um incremento e outro, teremos feedbacks e ajustes na iteração 
encerrada. 
 
A figura anterior ilustra um processo com uso de 3 iterações, onde em cada uma 
repete-se o conjunto de etapas, que começa com levantamento de requisitos e termina com 
implantação das funcionalidades contidas naquela iteração. 
Como já mencionado, a UML não define um processo padrão. Seus autores 
reconhecem que uma linguagem de modelagem e um processo robusto são ambos 
importantes. Eles ofereceram sua orientação sobre o que constitui um processo adequado em 
publicações separadas daquelas exclusivamente dedicadas a UML, porque a padronização de 
um processo estava fora do escopo da definição de UML. 
A UML e os resultados em cada fase 
Usar a UML, em um processo de desenvolvimento de sistemas, não implica, 
necessariamente, na elaboração de documentos ou uso de uma ferramenta case. 
Muitas equipes, por exemplo, usam UML para desenhos à mão em reuniões e para 
discussão de ideias. 
Uma ferramenta case é um programa que auxilia aos membros da equipe de 
desenvolvimento no estudo, modelagem e construção do sistema, possibilitando que vários 
diagramas possam ser elaborados em conjunto, representando a estrutura e comportamento 
do sistema a ser desenvolvido. 
Para visualizar uma proposta de fluxo de trabalho com os resultados em cada fase, 
usando a UML em um processo iterativo, clique no botão abaixo: 
Proposta de fluxo de trabalho usando a UML 
A seguir, veja uma proposta de fluxo de trabalho com os resultados em cada fase, 
usando a UML em um processo iterativo, conforme ilustração da figura anterior. 
Levantamento de requisitos 
• Diagrama de casos de uso, para identificação, informal, dos requisitos e 
funcionalidades do sistema; 
• Diagrama de classes conceitual, de alto nível, com modelagem apenas das classes, 
com talvez, os atributos mais relevantes. 
Análise de requisitos 
• Casos de uso, que descrevem como as pessoas interagem com o sistema; 
• Diagrama conceitual de classes; 
• Diagrama de estados, caso seja necessário elucidar algum ciclo de vida de um 
objeto relevante para o sistema; 
• Diagrama de atividades, com algum fluxo de trabalho relevante, ou um caso de 
uso mais complexo. 
Nas 2 fases, o aspecto mais relevante é a efetiva comunicação com os usuários e com a 
equipe de desenvolvimento. 
Projeto 
• Diagramade classes, já a partir de uma perspectiva de software; 
• Diagrama de sequência, para cenários relevantes e comuns; 
• Diagrama de estados; 
• Diagrama de componentes, com a arquitetura do software; 
• Diagrama de implantação, para definição do ambiente físico e distribuição dos 
componentes. 
Necessidade de usuário 
Um gerente está em sua mesa, trabalhando, quando se aproxima outra pessoa e se 
apresenta: 
“— Bom dia, sou o analista de sistemas que veio fazer o trabalho encomendado. ” 
“— Que conjunto de atividades são desenvolvidas nesse departamento? ” 
O gerente responde: 
“— Bem, nós aqui fazemos a liberação de pagamento de notas fiscais, o controle das 
notas fiscais, em relação aos pedidos, e o controle de estoque com os itens descritos na nota 
fiscal. ” 
O analista fala: 
“— Quem faz a liberação dos pagamentos de notas fiscais? ” 
O gerente: 
“— A secretária, Dona Sílvia. — E chama a Dona Sílvia para mais esclarecimentos. 
Entrevistando a secretária, o analista completa as informações: 
“— Dona Sílvia, o que faz a Sra. iniciar o seu trabalho? ” 
Ela responde: 
“— Quando chega uma nota fiscal carimbada pelo pessoal do estoque. ” 
“ — Dona Silvia, e quando encerra o seu trabalho? — Pergunta o analista. 
“— Meu trabalho encerra quando gero a guia de liberação de pagamento. ”, responde 
a secretária. 
As funcionalidades são: 
 Liberar pagamento, gerir notas fiscais e controlar estoque. 
Aula 2: Uso e modelagem de requisitos 
Requisitos de um sistema 
O primeiro passo para a modelagem de um sistema é saber quais são os seus 
requisitos. Nesse processo, o levantamento e mapeamento adequado dos requisitos de um 
sistema são passos fundamentais para o sucesso do produto final a ser gerado: o software. 
O software precisa ter as funcionalidades adequadas para satisfazer as necessidades 
de seus usuários. Portanto, durante o processo de desenvolvimento de software é preciso ter 
cuidado e, se possível, garantias de que os requisitos estão sendo corretamente capturados e 
compreendidos pelos analistas de sistemas. 
A UML (linguagem unificada de modelagem) disponibiliza para esse fim o diagrama de 
casos de uso, cuja finalidade é mapear as funcionalidades do sistema, evidenciando os atores 
que com elas interagem. 
Levantamento de requisitos 
De uma forma geral, os requisitos são necessidades dos usuários que os sistemas 
precisam atender. 
As atividades de levantar e identificar os requisitos são fundamentais para todo o 
processo de desenvolvimento de sistemas, pois uma vez conhecidas as reais necessidades de 
seus usuários poderemos desenvolver o sistema adequado. 
Em contrapartida, se as necessidades identificadas não forem os reais, o sistema não 
atenderá ao que seus usuários precisam, e a tendência é que seja descartado. 
Pense um pouco: Apenas identificar os requisitos de um sistema corretamente é o 
suficiente? 
Não: Pois temos de controlar o processo de desenvolvimento do software de forma a 
garantir que os requisitos estão sendo interpretados, entendidos e implementados de forma 
adequada pela equipe de desenvolvimento. 
Ou seja, a garantia de atender aos usuários implementando adequadamente os 
requisitos que reflitam as suas necessidades depende de procedimentos de controle que 
garantam a qualidade do software durante todo o seu processo de desenvolvimento. 
Levantar requisitos implica em sabermos o que o sistema precisa fazer para atender as 
necessidades de seus usuários. A qualidade do levantamento de requisitos influencia todo o 
processo de desenvolvimento, especialmente as validações junto aos usuários, necessárias ao 
longo do processo de desenvolvimento e sobretudo na adequação do software. 
Tipos de requisitos 
O levantamento de requisitos visa identificar dois tipos de requisitos. Veja: 
 
Funcionais 
Os requisitos funcionais representam as funcionalidades necessárias para atender as 
necessidades dos usuários do sistema. 
Veja alguns exemplos de requisitos funcionais para um sistema de Folha de 
Pagamento: 
• Registro dos dados dos funcionários; 
• Registro do salário bruto de cada funcionário; 
• Cálculo da folha de pagamento; 
• Cadastramento da tabela de imposto de renda; 
• Emissão do recibo de pagamento; 
• Dentre outras funções necessárias ao sistema. 
Não funcionais 
Apresentam restrições e qualidades do sistema e suas funcionalidades. 
Eles representam os atributos e propriedades do sistema. Podem ser expressos em 
termos do sistema como um todo, como por exemplo: o sistema deve ser operado por uma 
tela de toque (touch screen), denotando um requisito não funcional de usabilidade. 
Os requisitos não funcionais podem representar também propriedades de uma função 
específica. Por exemplo: o usuário pode ter a necessidade de especificar que a impressão do 
boleto de venda (função) não deve demorar mais que 10 segundos (requisito não funcional), 
representando um requisito não funcional que visa a performance do sistema. 
Diagrama de casos de uso 
Como vimos, o diagrama de casos de uso tem como objetivo apresentar os requisitos 
funcionais do sistema. Ou seja, é um diagrama que começa a ser usado após o levantamento 
de requisitos, de forma a mapear as funcionalidades do sistema, documentando o que o 
sistema faz. 
O diagrama de casos de uso é um dos mais informais e simples, dentre os diagramas 
propostos pela UML (Linguagem Unificada de Modelagem), e sua finalidade é apresentar as 
principais funcionalidades que o sistema precisa ter. 
Curiosidade! 
O diagrama de casos de uso pode, ainda, ser usado durante determinadas técnicas de 
elicitação de requisitos, como o JAD (Joint Application Design), que visa extrair requisitos de 
usuários de forma coletiva e colaborativa. 
Durante uma sessão JAD, componentes da equipe técnica, como engenheiros de 
requisitos e/ou analistas de sistemas, podem desenhar diagramas de casos de uso, para 
identificar as funcionalidades requeridas pelo sistema, de forma a atender as necessidades 
desses usuários. 
Outra finalidade do diagrama de casos de uso é possibilitar que os requisitos possam 
ser validados junto aos usuários, de forma que se tenha certeza de que: 
Todos os requisitos funcionais foram identificados; 
O entendimento da equipe de desenvolvimento, no que tange aos requisitos 
identificados, está correto e corresponde à realidade. 
Nesse diagrama, não mostramos detalhes de como o sistema realizará suas 
funcionalidades. 
Elementos do diagrama de casos de uso 
Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis de 
serem representados, que são: 
Os atores - Os Casos de Uso – Os relacionamentos: A figura a seguir ilustra um 
diagrama de casos de uso, contendo: 
 
Ator 
Vamos conhecer cada elemento do diagrama de casos de uso separadamente, e vamos 
iniciar pelo elemento Ator. 
O ator é algo com comportamento, que interage diretamente com o sistema. Um ator 
participa (realiza) um ou mais casos de uso do sistema. A representação do ator, no diagrama 
de casos de uso, é o boneco, chamado de stickman, conforme a figura ao lado: 
Um ator é o papel que o agente desempenha em relação ao sistema. Ele pode 
representar: 
• Papéis internos (Gerente de Compras) ou externos (Cliente e Fornecedor) 
• Setores e departamentos da empresa (Contabilidade e Contas a Pagar), bem como 
funções desempenhadas na empresa (almoxarifado). 
• Dispositivos eletrônicos, como por exemplo hardware e servidores, ou dispositivos 
lógicos, como sistemas. 
Identificando atores 
O primeiro passo para a construção do modelo de casos de uso é a identificação de 
atores. Algumas perguntas são úteis nesta situação, veja: 
• Quais órgãos,empresas ou pessoas farão uso deste sistema de informação? 
• Que sistemas ou equipamentos irão se comunicar com o sistema que será 
desenvolvido? 
• Quem deve ser informado de alguma ocorrência no sistema? 
• A quem pode interessar os requisitos funcionais do sistema? 
Casos de uso 
Outro elemento do diagrama são os casos de uso. 
Segundo Jacobson, um dos criadores da UML, um caso de uso é uma descrição 
narrativa de uma sequência de eventos que ocorre quando um ator usa um sistema para 
realizar uma tarefa. 
Os casos de uso representam, através de elipses, as funcionalidades do sistema, 
conforme a imagem a seguir: 
Caso de Uso: Sendo uma funcionalidade, o nome do caso de uso deve ser composto 
por um verbo no Infinitivo + complemento verbal, como o exemplo acima: “Matricular em 
Curso”. 
Identificando casos de uso 
Como já fizemos a identificação dos atores, podemos passar à identificação dos casos 
de uso. Esse processo deve seguir duas etapas, veja: 
Em primeiro lugar, podemos pensar nos casos de uso que representam os objetivos 
dos atores. Estes casos de uso representam os processos da empresa, e algumas perguntas são 
úteis neste momento: 
• Quais as necessidades e objetivos de cada ator em relação ao sistema? 
• Que informações serão produzidas pelo sistema? 
• O sistema realizará alguma ação que ocorre de forma regular no tempo? 
• Existe um caso de uso para atender cada requisito funcional? 
Em seguida, podemos pensar nos casos de uso que não representam um benefício 
direto para os atores, mas são necessários para o funcionamento do sistema. Tais casos de uso 
englobam manutenção de cadastros e de informações provenientes de outros sistemas. 
Cenários 
Um caso de uso é um conjunto de cenários. Descreve uma sequência de ações do ator 
e do sistema. Cada sequência de ações é chamada de cenário. 
Portanto, um cenário é uma sequência específica de ações que ilustra o 
comportamento do caso de uso. 
Atividade 
Nessa atividade, você deverá identificar os atores e os casos de uso envolvidos em um 
diagrama de casos de uso. 
Para isso, primeiramente leia o texto “Clínica oftalmológica”. 
Com base no texto acima, identifique os atores e os casos de uso envolvidos e desenhe 
o esboço do diagrama de casos de uso. 
Observação: Realize essa atividade fazendo uso de papel e caneta ou word. Ao 
término da mesma, você pode visualizar o gabarito e compará-lo com a sua resposta. 
Clínica oftalmológica 
Uma clínica oftalmológica precisa de um sistema de agendamento de consultas e 
exames. 
Um paciente contata a clínica, por telefone ou pessoalmente, e solicita a marcação de 
uma consulta com seu médico de preferência, informando a data e hora desejadas. 
A atendente verifica na agenda a disponibilidade mais próxima de data e hora na 
agenda do médico e agenda a consulta. 
Na data e hora agendados, o paciente realiza a sua consulta, na qual o médico pode 
solicitar exames e prescrever medicamentos. 
Após a consulta, o paciente solicita à atendente a marcação de seus exames, 
informando data e hora pretendidos. A atendente verifica disponibilidade próxima ao 
solicitado e agenda o exame para o paciente. 
A qualquer momento, o paciente pode solicitar o cancelamento não apenas da 
consulta, mas também do exame. 
Relacionamentos ou associações 
O diagrama de casos de uso possibilita, ainda, a existência de relacionamentos entre: 
Relacionamentos entre atores e casos de uso 
Esse é o relacionamento mais comum, e é indicado por uma linha sólida, que liga o 
ator ao caso de uso, denotando que o ator interage com o caso de uso. 
Nos termos técnicos, dizemos que o ator realiza o caso de uso. A figura a seguir ilustra 
esse relacionamento: 
 
A comunicação nesse relacionamento é bidirecional, ou seja, o ator informa dados ao 
caso de uso e recebe informações por ele processadas. 
Relacionamentos de atores entre si 
Entre atores, é possível haver o relacionamento de generalização/ especialização, 
representado por uma linha sólida com uma seta na extremidade que aponta para o ator geral, 
conforme ilustrado nesta imagem: 
 
Observe que nesse exemplo, o ator geral é o “Funcionário” e o ator especialista, o 
“Gerente”. Este também exerce as atividades de um funcionário, porém como gerente tem 
tarefas específicas a sua função. 
Vamos analisar mais um exemplo de relacionamento de generalização/ especialização 
entre atores. Observe a leitura desse diagrama: 
 
 O ator geral é “Usuário”. 
 Os atores especializados são “Aluno” e “Atendente”, que se relacionam com todos os 
casos de uso associados ao ator “Usuário”. 
 Apenas o ator “Atendente” se relaciona com “Cancelar Matrícula em Curso”, ou seja, 
apenas o “Atendente” realiza esse caso de uso. 
Esta é uma associação útil para definir a sobreposição de papéis entre atores, na qual: 
• O ator especializado interage com o caso ao qual está associado diretamente e 
com todos os casos de uso com o qual o ator generalizado se associa; 
• Já o inverso não ocorre: o ator generalizado não interage com os casos de uso 
associados ao ator generalizado. 
Relacionamentos de Casos de uso entre si 
Casos de uso podem conectar por três tipos de relacionamentos: 
• Inclusão (include ou uses); 
• Extensão (extend); 
• Generalização. 
Relacionamentos entre Casos de uso por inclusão 
Nesse tipo de relacionamento, um caso de uso (principal) incorpora, explicitamente, o 
comportamento de outro caso de uso (incluído). 
O caso de uso incluído é parte integrante do caso de uso principal. A fatoração 
(separação desse caso de uso) acontece porque outros casos de uso também poderão 
incorporar o caso de uso incluído e, assim, evitar repetições de fluxos. 
O diagrama abaixo demonstra o relacionamento de casos de uso por inclusão: 
 
Vamos analisar um caso de uso por inclusão. Observe o diagrama ilustrado a seguir: 
 
O caso de uso “Validar Disciplina” é usado por dois casos de uso: “Incluir Disciplina” e 
“Eliminar Disciplina”. Isso significa que o caso de uso “Validar Disciplina” está contido em 
ambos, ou seja, se formos descrever as interações do que acontece dentro do caso de uso, 
perceberemos que tanto “Incluir Disciplina” quanto “Eliminar Disciplinas” terão uma parte 
igual. 
Esse caso de uso será obrigatoriamente executado, em algum ponto da execução do 
caso de uso “Incluir Disciplina”, como também em algum ponto na execução do caso de uso 
“Eliminar Disciplina”. 
Normalmente essa percepção da necessidade de fatoração ocorre quando estamos 
descrevendo os casos de uso, assunto de que trataremos na próxima aula. 
O cenário comum a mais de um caso de uso é capturado em outro caso de uso. No 
caso do exemplo anterior, “Validar Disciplina” agrega o que é comum a “Incluir Disciplina” e a 
“Eliminar Disciplina”. 
Relacionamentos entre Casos de uso por extensão 
Esse tipo de relacionamento é usado para descrever cenários opcionais em um caso de 
uso; uma variação do comportamento normal. 
Veja a seguir uma descrição do relacionamento de casos de uso por extensão 
Um caso B (caso de uso estendido) estende A (caso de uso principal) quando alguma 
condição interrompe a execução do caso A (caso de uso principal) para que B (caso de uso 
estendido) execute e retorne, ao final, ao caso de uso A (caso de uso principal). 
A interrupção é feita no chamado ponto de extensão. Esta imagem ilustra o 
relacionamento de extensão: 
 
Para que você entenda melhor como acontece o relacionamento de casos de uso por 
extensão, trouxemos dois exemplos que iremos analisar. Veja: 
 
O caso de uso “Enviar Informe de Dívida” estende o caso de uso “Cancelar Matrícula 
em Curso”. 
Esse caso de uso somente seráexecutado se o cancelamento do curso implica em 
pagamento de dívida do aluno; caso o aluno esteja quite com o curso, o caso de uso não será 
executado. 
 
Observe como os casos de uso “Pagar em Cheque” ou “Pagar em Cartão” estendem o 
caso de uso “Pagar Mensalidade”. 
Neste caso, haverá uma condição a ser avaliada, que é a forma de pagamento e, de 
acordo com o valor desta, será executado um ou outro caso de uso: apenas um deles será 
executado, ou seja, são mutuamente exclusivos. 
Relacionamentos entre Casos de uso por generalização 
Esse tipo de relacionamento é usado quando um caso de uso é semelhante a outro, 
mas executa algumas funções a mais. 
Ele é pouco usado, pois seu uso confunde-se com o extend, na medida em que este 
também pode resolver essa questão da variação de comportamento, neste caso um 
comportamento com adição de funcionalidade. 
O diagrama a seguir ilustra o relacionamento de casos de uso por generalização: 
 
 
 
 
Vamos analisar um exemplo de caso de uso por generalização. Observe: 
 
Neste exemplo existe a especialização do caso de uso “Solicitar Produtos”, que pode 
ser pela internet ou pelo telefone. De acordo com a forma de solicitação, o comportamento do 
caso de uso vai variar, porém existem partes comuns, que estão especificadas em “Solicitar 
Produtos” (caso mais geral). 
Aula 3: Descrição textual dos casos de uso 
A importância da especificação de casos de uso 
O diagrama de caso de uso é útil, na medida em que nos fornece uma visão geral das 
funcionalidades do sistema (conjunto de casos de uso) e dos atores que com elas se 
relacionam. Todavia, é pobre na medida em que não entendemos como a interação ocorre em 
cada caso de uso. 
É nesse contexto que identificamos a importância da especificação dos casos de uso. 
Podemos dizer, então, que o diagrama é um sumário gráfico do conjunto de casos de uso 
(funcionalidades) de um sistema. 
O real valor da técnica de especificação de casos de uso está na adequada descrição 
textual de cada caso de uso, em que veremos com clareza como os atores utilizam o sistema. 
Mas a UML nada define sobre o texto narrativo, que descreve o caso de uso. 
Se o tempo destinado ao modelo de casos de uso for pouco, concentre-se na 
especificação ou descrição dos casos de uso e esqueça o diagrama. Mas se tiver oportunidade, 
modele o diagrama, pois é uma ótima ferramenta de diálogo com usuário, pela sua 
simplicidade. 
Os formatos para especificar casos de uso 
Craig Larman, em seu livro Utilizando UML e Padrões: uma introdução à análise e ao 
projeto orientados a objeto e ao desenvolvimento iterativo, cita três formatos para descrever 
os casos de uso, veja: 
Formato resumido 
Corresponde ao resumo de um parágrafo, geralmente contendo o cenário principal do 
caso de uso e o cenário de sucesso. 
Você deve utilizá-lo na análise inicial de requisitos, para obter uma ideia do assunto e o 
escopo do caso de uso. 
Formato Informal 
Refere-se aos múltiplos parágrafos que cobrem vários cenários de uso. 
Você deve utilizá-lo na mesma condição do formato resumido. 
Formato Completo 
Nesse formato, todos os cenários (principal e alternativos) são descritos em detalhes, 
com seções adicionais, complementando a especificação, com elementos que definem os pré e 
pós-condições. 
Você deve utilizá-lo depois que muitos casos de uso tiverem sido descritos no formato 
resumo ou informal, geralmente durante a fase de análise de requisitos e de sistemas. Para os 
casos de uso relevantes, tende a ser o formato mais adequado. 
Em essência, a especificação ou descrição textual de um caso de uso deve mostrar a 
interação entre o ator e o sistema (caso de uso em questão), ou seja, a “conversa” entre ator e 
sistema na realização (acontecimento) do caso de uso. 
Exemplo de descrição textual de um caso de uso 
Para mostrar a diferença entre os três tipos de especificação, vamos usar como 
exemplo o caso de uso “Registrar Venda”, com o trecho de diagrama de casos de uso, a seguir. 
Observe que neste diagrama foram considerados atores tanto o caixa como o cliente. 
O motivo é que o cliente também interage com o sistema, quando o pagamento é em cartão, 
por exemplo. 
 
FORMATO RESUMIDO 
Caso de uso: “Registrar Venda” 
O cliente chega a um ponto de pagamento da loja com os itens que deseja adquirir. O 
caixa registra cada item desejado. Ao final, o sistema apresenta o total a pagar e a relação de 
itens comprados. 
O cliente informa e o caixa registra os dados do pagamento, que são validados e 
registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras 
e sai com os itens adquiridos. 
 
 
 
FORMATO INFORMAL 
Caso de uso: “Registrar Venda” 
Cenário principal (de sucesso): Cliente chega ao ponto de pagamento da loja com os 
itens a serem adquiridos. Caixa usa o sistema PDV para registrar todos os itens comprados. Ao 
final, sistema apresenta o total a pagar e a relação de itens comprados. 
Cliente informa e caixa registra os dados do pagamento, que são validados e 
registrados pelo sistema. Sistema atualiza o estoque. Cliente recebe o recibo das compras e sai 
com os itens adquiridos. 
Cenários alternativos: Se o identificador do item adquirido não for encontrado no 
sistema, este notifica o caixa e sugere que entre manualmente com a identificação do item 
(que talvez esteja corrompido). 
Se o cliente informou o pagamento em cartão e a operadora não aprova a transação, 
informa o cliente e solicita uma nova forma de pagamento. 
Se o sistema não consegue atualizar o estoque, sugere que o caixa registre no 
formulário de problemas do dia, para o balanço ao final do dia. 
FORMATO COMPLETO 
Vários gabaritos e padrões de formatos estão disponíveis para casos de uso relevantes 
que precisam de especificações detalhadas. 
Para visualizar as principais seções que compõem o formato completo, bem como o 
exemplo de caso de uso “Registrar Venda”, clique no botão. 
Especificação de casos de uso que contenham Include 
Vamos entender como especificar casos de uso que contenham Include por meio de 
um exemplo. Veja: 
Considere o trecho de diagrama a seguir, de um sistema de locadora de DVDs, no qual 
os dependentes podem ser incluídos e eliminados do plano de sociedade com a locadora: 
 
Observe que existe um caso comum a ambos: “Pesquisar Dependente”. A partir da 
especificação de um deles, o “Incluir Dependente”, vamos entender como se dá o uso do 
<include>. 
Para visualizar como realizar a especificação do caso “Incluir Dependente”, clique no 
botão ao lado: 
 
Especificação do caso “Incluir Dependente” 
Cenário principal 
1. Atendente informa identificação do cliente; 
2. Sistema localiza dados do cliente informado; 
3. Atendente informa dados do dependente; 
4. Sistema localiza dados do dependente informado – <>; 
5. Sistema registra dados do dependente do cliente informado. 
Cenários alternativos 
2.a. Cliente não localizado: 
Sistema informa “Cliente não registrado no sistema” e retoma ao passo 1 do cenário 
principal; 
4.a. Dependente já registrado: 
Sistema informa “Dependente já registrado no sistema” e retorna ao passo 3 do 
cenário principal. 
A inclusão do caso “Pesquisar Dependente” ocorre no passo 4 do cenário principal. 
Nesse momento, ocorre a interrupção na execução do caso “Incluir Dependente” e o fluxo 
desvia para a execução do caso “Pesquisar Dependente”. 
Ao final do caso de uso “Pesquisar Dependente”, o fluxo retorna para o cenário 
principal do caso “Incluir Dependente” no passo seguinte ao da inclusão do caso de uso, que é 
o passo 5. 
Especificação de casos de uso que contenham extends 
Para explicarcomo é especificado o uso de casos de extensão (extends), vamos usar 
diagrama a seguir. Observe: 
 
Para visualizar como realizar a especificação do caso “Registrar Devolução de DVD”, 
clique no botão. 
Temos três extends no diagrama, porém dois deles estão relacionados entre si e o 
terceiro não. 
O caso de uso “Calcular Multa por Atraso” será usado se e apenas se (condição) a 
entrega estiver sendo feita com atraso. 
Já os casos de uso “Pagar em Dinheiro” e “Pagar em cartão” são mutuamente 
exclusivos, ou seja, apenas um deles será executado, de acordo com a forma de pagamento 
(condição) escolhida pelo cliente. 
Considerações finais sobre especificações 
Conforme já mencionamos, a UML não descreve nada a respeito de especificações 
textuais de casos de uso, limitando-se a especificar os elementos e uso do diagrama de casos 
de uso. 
Porém, como também já mencionamos, a especificação de casos de uso é 
extremamente relevante para o entendimento dos requisitos para futura implementação de 
outros modelos e dos códigos fontes dos programas que vão compor o sistema. 
Desse modo, existem várias formas e padrões para especificar casos de uso. O que 
descrevemos anteriormente não é o melhor e nem tampouco o mais completo, porém vemos 
muito seu uso na vida profissional. 
Escolha o seu padrão, o seu formato e vá em frente. O importante é que seja algo que 
sua equipe saiba ler e escrever e a comunicação entre vocês possa ser clara e efetiva. 
Dicas para especificações de casos de uso 
Preparamos algumas dicas sobre especificações de casos de uso. Veja: 
1. Não use detalhes de implementação ou de determinada tecnologia em suas 
especificações. 
2. Procure não associar casos de uso a telas de sistemas. 
3. Utilize um formato de especificação que deixa o diálogo mais claro entre ator e 
caso de uso. O modelo tem duas colunas. Na primeira, descrevemos as ações do 
ator, e na segunda as ações do sistema. 
4. Os casos de uso incluídos (chamados de include) ou estendidos (chamados por 
extends) também devem ter descrição textual, podendo estar no formato 
resumido ou informal. 
5. Algumas perguntas podem ajudar no detalhamento dos cenários principal e 
alternativos. Exemplo: Quando tudo ocorre na normalidade (com sucesso), qual o 
comportamento do sistema? 
6. Quando um passo for muito complicado, ele pode vir a ser um novo caso de uso, 
que se relacionará com o caso original pelo estereótipo include. 
7. Faça casos de uso enxutos, pois casos longos podem não ser lidos em sua 
totalidade. 
Para conhecer cada dica de especificações de casos de uso com mais detalhe, clique no 
botão ao lado: 
Dicas para especificações de casos de uso 
Veja um exemplo de caso de uso: 
Caso de uso: “Reserva Quarto” 
Sistema: Gestão de Quartos de Hotel 
 
Atividade 
O diagrama de caso de uso é útil, na medida em que nos fornece uma visão geral das 
funcionalidades do sistema (conjunto de casos de uso) e dos atores que com elas se 
relacionam. No entanto, ele não informa como ocorre a interação em cada caso de uso. 
Nesse cenário, entra em cena a especificação de casos de uso. Explique qual a importância 
dessa técnica: 
O real valor da técnica de especificação de casos de uso está na adequada descrição 
textual de cada caso de uso, em que veremos com clareza como os atores utilizam o 
sistema. 
Atividade 
Craig Larman cita três formatos para descrever os casos de uso: o resumido, o informal 
e o completo. 
Analise as informações abaixo e relacione cada formato à sua devida definição: 
Todos os cenários (principal e alternativos) são descritos em detalhes, com seções 
adicionais, complementando a especificação, com elementos que definem os pré e pós-
condições. Formato completo 
Resumo de um parágrafo, geralmente contendo o cenário principal do caso de uso e o 
cenário de sucesso. Formato resumido 
Múltiplos parágrafos que cobrem vários cenários de uso. Formato informal 
Atividade 
Considere a seguinte descrição do que ocorre na realização do caso de uso “Emprestar 
DVD”, referente a um sistema de uma locadora de DVD: 
• O cliente escolhe os DVDs que pretende alugar e os entrega ao caixa; 
• O caixa solicita ao cliente sua identificação (CPF ou telefone); 
• O cliente informa sua identificação e o sistema verifica se o cliente está 
devidamente cadastrado; 
• Estando cadastrado, o caixa informa o ID de cada DVD a ser alugado, quando o 
sistema verifica se o ID está devidamente cadastrado e mostra o nome do DVD, 
com o respectivo preço de locação; 
• Ao final do registro de todos os DVDs, o caixa confirma a locação. O sistema, nesse 
momento, registra a locação dos DVDs informados, imprime o recibo de locação, 
com o valor que deve ser pago no ato da devolução; 
• Caso cada DVD informado para locação não esteja cadastrado, deve ser tratado 
pelo sistema, emitindo uma mensagem de erro, da mesma forma que a 
identificação do cliente não cadastrado. 
Descreva a solução para o caso de uso: 
Caso de Uso: Emprestar DVD 
Pré-condição: cliente e DVDs devidamente registrados 
Pós-condição: empréstimo devidamente registrado 
Cenário principal: 
1. Caixa informa ID do cliente; 
2. Sistema localiza cliente com ID do cliente; 
3. Para cada DVD a ser emprestado, FAÇA: 
 a. Caixa informa ID do DVD; 
 b. Sistema localiza DVD com ID DVD; 
 c. Sistema exibe nome do DVD e valor de locação; 
 d. Sistema acumula total da locação; 
Fim_Para: 
4. Sistema apresenta total da locação; 
5. Caixa confirma a locação; 
6. Sistema registra locação de cada DVD, calculando a data de devolução; 
7. Sistema imprime recibo com dados da locação. 
Cenários alternativos: 
2.a. Cliente não cadastrado 
1. Sistema informa “Cliente não cadastrado"; 
2. Sistema retorna ao passo 1. 
 3.b.a. DVD não cadastrado 
1. Sistema informa “DVD não cadastrado"; 
2. Sistema retorna ao passo 3.a. 
Aula 4: Digrama de classes 
Conceitos de diagrama de classes 
O diagrama de classes é considerado por muitos o principal diagrama da UML, sendo 
também o mais amplamente usado por aqueles que usam a UML na modelagem de seus 
sistemas orientados a objetos. 
Existem vários níveis de diagramas de classes, que são usados no nível de domínio — 
conceitual — e de projeto. 
Nesta aula, vamos inicialmente abordar o diagrama de classes a partir da observação 
do mundo real para um determinado contexto. Vamos construir o diagrama em nível de 
domínio, ou ainda, o chamado modelo conceitual de classes. 
Para começarmos, atente-se para a seguinte informação, referente ao diagrama 
conceitual de classes: 
Não se devem representar estruturas de projeto (interfaces, chaves, arquivos, campos 
etc.). O foco da análise é o negócio. 
Modelo conceitual de classes 
Com base no que vimos, podemos conhecer o modelo conceitual de classes. 
Esse modelo usa os elementos mais básicos do diagrama de classes, pois a finalidade é 
representar os objetos tal qual existem no mundo real, sem inserir aspectos de projeto ou de 
implementação no modelo. 
Assim, o diagrama de classes descreve, de forma gráfica, os tipos de objetos que 
interagem para realizar as funcionalidades previstas em um sistema, bem como os vários tipos 
de relacionamentos estáticos entre eles. O diagrama de classes mostra, ainda, as propriedades 
e operações de uma classe e as restrições relacionadas à forma como os objetos se 
relacionam. 
A evolução do diagrama de classes 
O diagrama de classes evolui à medida que o projeto avança. Observe esse processo 
através do esquema a seguir: 
Fase de Análise 
1º Momento -> Inicialmente, em sua primeira versão, na fase de análise, o diagrama 
apresenta as classes do negócio (tambémchamada de entidades) e chama-se diagrama de 
classes conceitual. 
Esse é um diagrama compatível com as funcionalidades dos casos de uso, ou seja, 
mostra a modelagem em classes dos requisitos essenciais do sistema. 
2º Momento -> Num segundo momento, ainda na fase de análise, novas classes 
podem ser inseridas no diagrama de classes, como as de controle e as de interface (ou 
fronteira). 
Classe de fronteira (boundary) ou interface: responsável pela interação com os atores. 
Exemplo: para representar um formulário, para representar a interface com outro 
equipamento (um acionador de cancelas de entrada e saída de veículos, por exemplo); 
Classes de controle: responsável pela coordenação da interação entre os objetos, na 
realização de um caso de uso. A princípio, cada caso de uso teria uma classe de controle. 
Fase de projeto ->. Nessa fase, o mesmo diagrama de classes pode ser refinado com a 
inserção de: 
• Multiplicidades e papéis; 
• Relacionamento entre as classes; 
• Novos métodos (como, por exemplo, get, set e formatações); 
• Novos atributos; 
• Parâmetros nas chamadas dos métodos; 
• Visibilidade dos atributos e métodos; 
• Novas classes, chamadas de classes de projeto (como representação de 
persistência). 
Fase de implementação 
Durante a implementação (codificação na linguagem), novas classes podem surgir, 
como classes que implementem determinada característica da linguagem de programação ou 
determinada forma de programar. É o diagrama de classes de implementação. 
Na verdade, embora com diferentes nomenclaturas, o diagrama de classes é um só, 
que vai crescendo e sendo alterado a cada fase do ciclo de desenvolvimento. Algumas equipes 
de projeto podem optar por guardar as versões finais de cada diagrama, mas a última versão 
guarda todas as alterações feitas. 
A classe 
Vamos conhecer o conceito de classe com mais detalhe: 
Uma classe é uma abstração da realidade, na qual representamos algo do mundo real. 
Se, por exemplo, em um contexto de sistema, identificarmos que desejamos armazenar os 
dados de um determinado elemento, estamos diante de uma candidata à classe do sistema. 
Na UML, uma classe é representada por um compartimento contendo três partes, 
conforme ilustra a figura a seguir: 
 
Exemplo 
A figura, abaixo, ilustra um exemplo de classe de nome “cliente”, contendo os 
atributos Nome e Matrícula e os métodos (operações) Criar(), Destruir() e Incluir Cliente(): 
 
Classe->. Corresponde ao nome da classe. 
Atributos ->São os dados que se retêm da classe. 
Operações -> São os procedimentos que a classe executa, para prestar seu serviço ao sistema, 
como um todo, chamados de métodos. 
Classe x Objeto 
Qual a relação existente entre classe e objeto? 
CLASSE ->. É o molde de um conjunto de objetos afins, ou seja, com as mesmas características 
(atributos e métodos). 
OBJETO ->. É uma instância de uma classe. 
Na imagem, a seguir, você pode visualizar o exemplo de um objeto específico 
pertencente à classe cliente. O objeto é como se fosse um elemento específico do conjunto 
(classe) cliente: 
 
Atenção: Ao modelarmos um sistema, estamos em busca de classes, e não de objetos. 
Poderíamos pensar que o nome da técnica deveria chamar-se “orientação a classes”, e não 
“orientação a objetos”. 
Visão geral do diagrama de classes e seus elementos 
A figura abaixo ilustra um diagrama conceitual de classes, contendo apenas classes de 
negócio (entidades) que são modeladas, bem como apresenta comentários dos principais 
elementos do diagrama de classes. 
 
 
Figura extraída do livro UML Essencial: um breve guia para a linguagem-padrão de 
modelagem de objetos, de Martin Fowler, 3a edição. 
Por meio do exemplo de diagrama, podemos observar que um diagrama de classes 
possui os seguintes elementos básicos: 
1. Classes, com atributos e operações (métodos) de cada uma; 
2. Relacionamentos entre as classes; 
3. Multiplicidade dos relacionamentos; 
4. Visibilidade de atributos e métodos; 
5. Nome dos relacionamentos e papel nos relacionamentos; 
6. Navegabilidade nos relacionamentos; 
7. Notas e comentários. 
Vamos conhecer cada elemento com mais detalhe, a seguir. 
Classes com seus atributos e operações 
Cada classe possui os seus atributos e operações específicos. Veja como esses 
elementos se relacionam: 
Atributo 
O conceito de atributo remete ao conjunto de características (estado) dos objetos da 
classe. 
Ele descreve uma propriedade estrutural da classe, um dado relevante que desejamos 
armazenar daquela classe. Segundo a UML, forma mínima de representar um atributo é: 
visibilidade Nome: tipo. 
Operações 
O conceito de método remete ao conjunto de operações (comportamento) que a 
classe fornece. 
A operação de uma classe é representada por um método, que é um procedimento ou 
função da classe. Segundo a UML, a forma mínima de representar um método é: visibilidade 
Nome (Lista de parâmetros): tipo. 
Exemplo de atributos e operações 
Atributo 
Conforme a figura a seguir, temos a classe disciplina e quatro atributos. Vejamos o 
atributo código: 
 O sinal menos (-) antes do nome é a visibilidade, que explicaremos adiante; 
 Código é o nome do atributo; 
 String é o tipo do atributo. 
 
Operações 
Conforme a figura a seguir, temos a classe disciplina e quatro métodos. Vejamos o 
método RECUPERARCREDITOS(Cod:int):int: 
 O sinal mais (+) antes do nome é a visibilidade, que explicaremos adiante; 
 RecuperarCreditos é o nome do método; 
 (Cod:int) é a lista de parâmetros, que no caso é composta de apenas um parâmetro; 
em que Cod é o nome do parâmetro e int o tipo de dado do parâmetro; 
 Int é o tipo de dado que RECUPERACREDITOS retorna. 
 
 
Observe que em três métodos o tipo de dados é VOID. Isto significa que esses métodos 
não retornam um tipo de dados, não sendo, portanto, uma função, e sim um procedimento. 
Associação entre classes 
O relacionamento de associação é o mais simples e comum relacionamento entre 
classes. Ocorre entre uma, duas ou mais classes distintas, não correlatas e independentes. Ao 
final do relacionamento, as classes permanecem com suas vidas próprias. 
A associação entre classes pode acontecer das seguintes maneiras, veja: 
Associação Binária -> É a associação mais comum, também chamada de associação 
entre duas classes. 
Autoassociação -> Também chamada de associação unária, corresponde à associação 
que ocorre com a mesma classe, na qual uma classe se relaciona com ela própria. 
Associação Exclusiva-> É uma restrição em duas ou mais associações. Ela indica que 
objetos de uma determinada classe podem participar de no máximo uma das associações, em 
determinado momento. 
Ela é representada por uma linha tracejada, entre as associações, com a especificação 
{ou}, denotando que o relacionamento é exclusivo a somente uma das duas classes. 
Associação entre classes 
O relacionamento de associação é o mais simples e comum relacionamento entre classes. 
Ocorre entre uma, duas ou mais classes distintas, não correlatas e independentes. Ao final do 
relacionamento, as classes permanecem com suas vidas próprias. 
A associação entre classes pode acontecer das seguintes maneiras, veja: 
Associação binária 
É a associação mais comum é entre duas classes, ilustrada na figura a seguir. Observe 
que o relacionamento de associação e denotado por uma linha sólida, que conecta as duas 
classes. 
Nesse exemplo, as classes cliente e pedido se relacionam no momento em que o 
cliente faz um pedido à empresa. 
 
 
Autoassociação 
Também chamada de associação unária, corresponde à associação que ocorre com a 
mesma classe, na qual uma classese relaciona com ela própria, conforme ilustra a figura a 
seguir, em que o relacionamento é de pré-requisito. Uma disciplina tem como pré-requisito 
outra disciplina da mesma classe. É possível haver relacionamentos com três ou mais classes, 
todavia é difícil encontrá-los no mundo real para modelagem. A figura a seguir mostra um 
exemplo de relacionamento de associação entre três classes. Um cliente contrata um projeto e 
um arquiteto. 
 
É possível haver relacionamentos com três ou mais classes, todavia é difícil encontrá-
los no mundo real para modelagem. A figura a seguir mostra um exemplo de relacionamento 
de associação entre três classes. Um cliente contrata um projeto e um arquiteto. 
 
Associação exclusiva 
Uma associação exclusiva é uma restrição em duas ou mais associações. Ela indica que 
objetos de uma determinada classe podem participar de no máximo uma das associações, em 
determinado momento. 
É representada uma linha tracejada, entre as associações, com a especificação {ou}, 
denotando que o relacionamento é exclusivo a somente uma das duas classes. 
A figura a seguir mostra que um contrato somente pode ser entre pessoas ou entre 
empresas, mas não pode haver contrato no qual figure empresa e pessoa simultaneamente: 
 
Multiplicidade nos relacionamentos 
A multiplicidade é um conceito extremamente relevante nos relacionamentos. De uma 
forma bem simples, ela indica quantos objetos de cada classe podem estar envolvidos no 
relacionamento. 
Para visualizar um exemplo sobre a multiplicidade nos relacionamentos, clique no 
botão a seguir: 
Exemplo de multiplicidade nos relacionamentos 
Imagine um relacionamento entre cliente e pedido, no qual um cliente faz um pedido. 
Vamos analisar a multiplicidade de cada um dos dois lados do relacionamento: do lado da 
classe cliente e do lado da classe pedido. 
Do lado da classe cliente, temos: o cliente pode realizar nenhum ou vários pedidos. 
Observe que escrevemos essa multiplicidade do lado de pedido, conforme ilustra esta figura: 
 
Do lado da classe pedido, temos: o pedido pertence a um e somente um pedido. 
Escrevemos essa multiplicidade do lado de cliente, conforme ilustra esta figura: 
 
Aqui, a imagem completa do relacionamento, com as multiplicidades em ambos os 
lados do relacionamento: 
 
A análise das multiplicidades entre os relacionamentos de classes sempre deve 
acontecer dessa forma. Analisando um lado e depois o outro, as possíveis multiplicidades são: 
 
Observe a cardinalidade do diagrama de classes representado na figura a seguir: 
 A classe EQUIPEFUTEBOL tem de 11 a 22 ESTUDANTES  11..22 do lado da classe 
ESTUDANTE; 
 A classe ESTUDANTE pode participar de NENHUMA e até 8 DISCIPLINAS  0..8 do lado 
da classe DISCIPLINA. 
 
 
Visibilidade de atributos e métodos 
Diz respeito a quais classes podem ver (visualizar) o quê de outra classe. A ideia é que 
cada classe tenha elementos privados e públicos. Observe: 
 O que for público pode ser visualizado e usado por qualquer outra classe. 
 O que for privado só pode ser usado pela classe proprietária. 
No entanto, ao saímos da modelagem e passarmos para a implementação, temos que 
observar as particularidades de cada um no tocante à visibilidade. 
A UML aborda o tema sem entrar nessa confusão e deixa a cargo da equipe de 
desenvolvimento esses aspectos de compatibilidade. Basicamente, a UML permite que se 
rotule todo atributo e método de uma classe com um indicador de visibilidade. 
Atenção 
Em todos os exemplos vistos até aqui, usamos as visibilidades públicas (sinal de mais +) 
para os métodos e visibilidade privada (sinal de menos -) para os atributos. A UML fornece 
quatro possibilidades de visibilidade, a saber: 
 
Preparamos algumas diretrizes relevantes sobre visibilidade que você deve estar atento. 
Veja: 
1. O encapsulamento, um dos princípios básicos da orientação a objetos, diz que os 
atributos de uma classe não devem ser usados por outras classes, e sim apenas por 
métodos da própria classe. A conclusão é que os atributos devem ser classificados com 
visibilidade privada (-); 
2. Uma classe deve prestar serviço às demais, através de seus métodos. Assim sendo, 
pelo menos um dos métodos da classe deve ter visibilidade pública, para que as 
demais classes possam usá-lo; 
3. Num relacionamento de generalização/ especialização, todos os atributos e métodos 
que desejar que sejam herdados pela classe especializada (subclasse) devem ter 
visibilidade protegida na classe geral (superclasse). 
Outros relacionamentos entre classes 
Os relacionamentos representam os mais relevantes elementos de um diagrama de 
classes. Por isso, agora estudaremos os relacionamentos mais usados na modelagem de 
classes. 
Além das associações, são possíveis os seguintes relacionamentos: 
CLASSE DE ASSOCIACÃO: É uma classe que surge do relacionamento de associação entre 
outras duas classes. 
GENERALIZACÃO/ ESPECIALIZACÃO (HERANÇA): É o relacionamento entre classes que 
implementa o conceito de herança, com reaproveitamento de código, preconizado pela 
orientação a objetos. 
AGREGAÇÃO E COMPOSIÇÃO: Esses dois relacionamentos são do tipo “todo-parte”, ou 
seja, existe uma classe que denota um todo e outras que denotam as partes. 
DEPENDÊNCIA: A dependência entre duas classes existe se: mudanças na definição de uma 
classe puder demandar mudanças na definição da outra classe. 
Outros relacionamentos entre classes 
Os relacionamentos representam os mais relevantes elementos de um diagrama de 
classes. Estudaremos os relacionamentos mais usados na modelagem de classes. Além das 
associações, são possíveis os seguintes relacionamentos: 
 Classe de associação; 
 Generalização/ especialização (herança); 
 Agregação; 
 Composição; 
 Dependência. 
Classes de associação 
A figura a seguir ilustra o relacionamento entre classes chamado de classe de associação. É 
uma classe que surge do relacionamento de associação entre outras duas classes. 
Imagine que um leitor (classe) de uma biblioteca solicita o empréstimo de um exemplar de 
livro (classe). 
Nesse momento, surge a necessidade de armazenar alguns atributos como: data de 
empréstimo e data de data de devolução, além de métodos para registrar o empréstimo, 
registrar a devolução e tratar a multa em caso de atraso na devolução. 
Tais atributos e métodos não podem ser associados à classe leitor nem tampouco à classe 
exemplar de livro. Não seria adequado incluir tais atributos e métodos em nenhuma dessas 
classes, pois não dizem respeito a elas. 
Surge então uma nova classe, denominada de empréstimo, como consequência da 
associação entre leitor e exemplar de livro, que deverá armazenar todos os atributos e 
métodos derivados dessa associação. 
O relacionamento classe de associação é representado por reta pontilhada, a partir de 
uma associação entre duas classes, conforme podemos ver nesta figura: 
 
Generalização/ especialização 
A generalização/ especialização é o relacionamento entre classes que implementa o 
conceito de herança, com reaproveitamento de código, preconizado pela orientação a objetos. 
Uma classe mais geral se relaciona com outra mais específica (herdada). A classe mais 
específica herda todas as características (atributos e métodos) permitidos da classe mais geral. 
A classe mais geral também é chamada de superclasse, e a classe mais específica chama-se 
subclasse. 
A imagem a seguir ilustra o relacionamento de generalização/ especialização, em um 
exemplo típico, envolvendo clientes pessoas físicas e jurídicas, que tem diferenças, mas 
também semelhanças. 
As semelhanças podem ser agrupadas na classe mais geral, cliente(a superclasse), e as 
diferenças ficam nas subclasses, pessoa física e pessoa jurídica. 
O relacionamento de generalização/ especialização é representado por uma reta com uma 
seta sem preenchimento na ponta, apontando para a classe mais geral. A leitura é: “A pessoa 
física é um cliente; A pessoa jurídica é um cliente” 
 
O relacionamento de generalização/ especialização contém algumas especificidades, 
chamadas de restrições, que acrescentam informações mais precisas sobre como a 
generalização deve ser usada e estendida no futuro. 
Generalização completa e incompleta 
Uma restrição indicando que a generalização é completa significa que todas as subclasses 
(especializações) já foram especificadas e não existe mais a possibilidade de outra 
generalização no futuro. A incompleta é o contrário, e é o padrão da UML. 
O exemplo a seguir ilustra o uso dessa restrição completa, na qual uma pessoa é homem 
ou mulher, não havendo novas subclasses possíveis para a superclasse pessoa. 
 
 
A figura a seguir mostra o princípio da herança chamado transitividade: 
 A classe Cl2 herda o atributo Cl1 (visibilidade protegida); 
 A classe Cl3 herda o atributo M2 de Cl2; 
 A classe Cl3 herda o atributo M1 de Cl1, pelo princípio da transitividade. 
 
Agregação e composição 
Uma das maiores fontes de confusão e dúvidas na modelagem de classes é o uso dos 
relacionamentos de agregação e composição. 
Esses dois relacionamentos são do tipo “todo-parte”, ou seja, existe uma classe que 
denota um todo e outras que denotam as partes. A grande dificuldade está em diferenciar 
agregação de composição. 
A composição é um relacionamento mais forte, no qual podemos prever as seguintes 
características: 
 Embora uma classe possa ser um componente de muitas outras classes, toda instância 
deve ser componente de apenas um proprietário, o que significa dizer que teremos a 
cardinalidade 1 do lado do objeto “todo” (proprietário). Em outras palavras, os objetos 
“parte” somente podem pertencer a um único objeto “todo”; 
 Se o todo for excluído, todas as partes devem ser também, ou seja, quando o todo 
“morre”, todas as partes também “morrem”. A vida do todo e das partes são 
coincidentes. 
Quando num relacionamento “todo-parte” as duas propriedades citadas não forem 
identificadas, estamos diante de uma agregação. Ou seja, a constatação de que o 
relacionamento é uma agregação deriva da análise das duas características citadas e da 
conclusão de que não é uma composição. 
A representação da agregação é por um losango (que muitos chamam de diamante) sem 
preenchimento, do lado do objeto “todo”. 
A representação da composição é pelo mesmo elemento, porém colorido de preto, 
também do lado do objeto “todo”. 
As figuras a seguir ilustram cada um dos relacionamentos. A primeira mostra um 
relacionamento de agregação entre as classes prova e questões. A segunda mostra um 
relacionamento de composição entre as classes pedido e itens de pedido. 
Vamos analisar cada um dos dois relacionamentos a seguir, à luz das duas características 
descritas e explicar o porquê de serem agregação e composição, respectivamente. 
Por que o relacionamento entre prova e questões é uma agregação? 
Analisando o relacionamento ilustrado na figura a seguir, sob a luz das duas características 
descritas, temos: 
 O objeto “parte” questões pode pertencer a mais de um todo, uma vez que uma 
questão pode ser parte integrante de mais de uma (várias) provas; 
 Quando uma prova deixa de existir, as questões nela contidas podem (e devem) 
continuar existindo, para que possam ser usadas em outras provas; logo, a vida das 
partes não é coincidente com a vida do todo. 
Concluindo: como nenhuma das propriedades foi analisada como verdadeira, podemos 
concluir que o relacionamento entre prova e questões não se trata de composição. Como é um 
relacionamento “todo-parte”, concluímos tratar-se de uma agregação. 
 
Por que o relacionamento entre pedido e itens pedido é uma composição? 
Analisando o relacionamento ilustrado na figura a seguir, sob a luz das duas características 
descritas, temos: 
 O objeto “parte” itens pedido não pode pertencer a mais de um todo, pois aquele item 
é daquele pedido e não poderá estar em outro; 
 Quando um pedido deixa de existir, não faz sentido os seus itens permanecerem 
ativos, “vivos”; logo, quando o pedido (todo) “morre”, os itens pedido (parte) também 
“morrem”. 
Concluindo: como as duas características foram analisadas como verdadeiras, podemos 
concluir que o relacionamento entre pedido e itens pedido é uma composição. 
 
Embora as duas características ajudem muito a elucidar a dúvida sobre qual dos dois 
relacionamentos é mais apropriado, devemos sempre analisar o contexto, para entender como 
se relacionam todo e parte. 
Por fim, afirmamos que a composição é um relacionamento que diz muita coisa a quem vai 
implementar as classes, na linguagem de programação, pois orienta que a criação e destruição 
das partes está condicionada à vida do todo. 
Já a agregação não tem essa particularidade. Uma agregação poderá, se desejado, ser 
substituída por uma associação simples, já que não tem grandes valores semânticos, a não 
explicitar que se trata de uma relação “todo-parte”. 
Dependência 
A dependência entre duas classes existe se: mudanças na definição de uma classe puder 
demandar mudanças na definição da outra classe. As dependências podem ser evidenciadas 
de várias formas, como por exemplo: 
 Uma classe tem outra como parte de seus dados; 
 Uma classe menciona outra como parâmetro de uma chamada de método. 
Se a interface da classe dominante muda, as mensagens enviadas podem não ser mais 
válidas, demandando alterações na classe dependente. 
Sabemos o quanto esse tipo de alteração provoca problemas endêmicos em sistemas, 
acarretando o chamado “efeito em cascata”, ou seja, uma alteração em parte do código 
resulta como consequência (erros, problemas) em outras partes. 
Na modelagem UML, veremos muitas dependências, mas você deve ser seletivo e modelar 
dependências apenas quando ela for relevante para o contexto específico de sua aplicação. 
Um dos usos mais comuns da dependência é na modelagem de um relacionamento 
transitório, como quando um objeto é passado para outro como parâmetro. 
A imagem a seguir ilustra um relacionamento de dependência entre as classes estudante e 
disciplina. A dependência é representada por uma seta pontilhada, que sai da classe 
dependente. Ou seja, no relacionamento a seguir, disciplina depende (é dependente) de 
estudante. 
Observe o método incluir da classe disciplina. Ela usa como parâmetro o objeto aluno, que 
é da classe estudante. Isto significa que qualquer mudança na interface (assinatura) de 
estudante poderá afetar a classe disciplina. 
 
Nome do relacionamento e papel nos relacionamentos 
Podemos definir, para um relacionamento, um nome e um papel. A imagem a seguir 
mostra um exemplo de como definir esses elementos: 
 
 
 
Atenção 
Cada classe pode ter o nome de seu papel descrito no relacionamento, conforme ilustra a 
figura anterior. Seu uso é opcional e, caso seja necessário, pode-se especificar o papel de 
apenas uma das classes no relacionamento. Veja: 
Faz é o nome do relacionamento, com a seta apontado para pedido, indicando que a 
leitura é na direção cliente faz pedido; 
Possui é o nome do relacionamento entre pedido e itens pedido, com a seta apontada 
para itens pedido, indicando que a leitura é na direção pedido possui itens pedidos; 
Faz pedido é o papel que o cliente tem no relacionamento entre cliente e pedido; 
Cada item do pedido é o papel que itens pedido tem no relacionamentoentre pedido e 
itens pedido. 
Navegabilidade nos relacionamentos de associação 
A navegabilidade mostra a direção da navegação. 
Podemos citar como exemplo, uma associação que é dita navegável da classe C1 para a 
classe C2 se, a partir de um objeto de C1, consegue-se obter diretamente os objetos 
relacionados da classe C2. Assim, denota-se, no diagrama de classes, a capacidade de um 
objeto mandar mensagens a objetos de outra classe. 
Veja mais um exemplo: 
No diagrama de classes representado pela figura a seguir, está sendo representada a 
navegabilidade da associação entre as classes cliente e endereços. O símbolo é a seta colada 
na classe endereços. 
 
A interpretação para o diagrama que vimos anteriormente é a seguinte: 
 O cliente sabe quais são seus endereços; 
 Mas o endereço não sabe a quais clientes pertence; 
 A classe cliente poderá enviar mensagens à classe endereços, mas o contrário 
não poderá ocorrer; 
 Esta é uma notação semântica que ajuda muito na implementação. 
 
Notas e comentários no diagrama de classes e UML 
Notas são comentários nos diagramas. Elas podem ser isoladas ou vinculadas, por linha 
tracejada, a um dos elementos do diagrama. Podem ainda ser usadas em qualquer diagrama. 
A figura a seguir, ilustra as duas possibilidades: notas associadas a um elemento, no caso à 
classe endereços e nota associada ao diagrama, de uma forma geral. 
 
Atividade 
Com base no enunciado e na solução de caso de uso, elabore um diagrama conceitual de 
classes. 
Para isso, primeiramente leia o texto “Clínica oftalmológica”. 
Uma clínica oftalmológica precisa de um sistema de agendamento de consultas e exames. 
 Um paciente contata a clínica, por telefone ou pessoalmente, e solicita a marcação de 
uma consulta com seu médico de preferência, informando data e hora desejadas. 
 A atendente verifica na agenda a disponibilidade mais próxima de data e hora, na 
agenda do médico, e agenda a consulta. 
 Na data e hora agendada, o paciente realiza sua consulta, na qual o médico pode 
solicitar exames e prescrever medicamentos. 
 Após a consulta, o paciente solicita à atendente a marcação de seus exames, 
informando data e hora pretendida. A atendente verifica a disponibilidade próxima ao 
solicitado e agenda o exame. 
 A qualquer momento o paciente pode solicitar o cancelamento não apenas da 
consulta, mas também do exame. 
Segue um dos possíveis diagramas de classes, com base na solução dada no diagrama de 
casos de uso da aula 2. 
 
Segue o passo a passo para a obtenção do diagrama de classes com base no enunciado e 
diagrama de casos de uso. 
1) Precisamos reter, no sistema, dados de algum ator? Ou seja, algum ator é candidato à 
classe? 
a. Sim, paciente e médico. 
2) Que casos de uso dão origem a classes? 
a. Consultar paciente  Classe consulta. 
b. Agendar exame  Classe exame. 
c. Consultar paciente  Classe prescrição, já que na consulta o médico prescreve 
medicamentos. 
3) Que casos de uso dão origem a métodos de uma classe? 
a. Classe consulta: 
agendarConsulta, 
CancelarConsulta, 
ConsultarPaciente. 
b. Classe exame: 
Agendar Exame, 
cancelar exame. 
4) Como relacionar as classes envolvidas? 
Segue o diagrama de classes derivado do diagrama de casos de uso. 
 
Aula 5: Diagramas de Interação, com ênfase em Sequência 
Diagramas de interação 
Os sistemas orientado a objetos implementam as funcionalidades que oferecem, pela 
troca de mensagens entre os objetos, ou seja, um objeto envia uma mensagem a outro 
quando deseja que este realize uma tarefa. 
Baseado nesse contexto, podemos entender de que forma os diagramas de interação 
atuam. Vamos entender isso partindo do conceito de diagrama de casos de uso e diagrama de 
classes. Veja: 
Os diagramas de casos de uso apresentam as funcionalidades. 
O diagrama de classes mostra a estrutura (nome, atributos e métodos) e relacionamentos 
entre as classes necessárias ao sistema. 
Os diagramas de interação mostram como as classes (na verdade, os objetos) trocam 
mensagens, ou seja, interagem para oferecer uma funcionalidade (ou realizar um caso de uso). 
Uma mensagem representa a solicitação que um objeto requisitante faz a um objeto 
receptor para que este execute uma das operações definidas em sua classe. 
Tipos de diagramas de interação 
Os diagramas de interação, de uma forma geral, mostram como as classes colaboram em 
determinados comportamentos. Visam ilustrar como os objetos interagem, por meio de 
mensagens. 
São dois tipos de diagramas de interação: o diagrama de sequência e o diagrama de 
comunicação. 
Veja algumas características desses dois tipos de diagramas de interação: 
 De uma forma genérica, o diagrama de sequência é o mais rico dos dois, mas o 
diagrama de comunicação também tem sua finalidade, na medida em que é mais 
flexível quanto ao desenho. Cada um dos diagramas de interação tem suas 
vantagens e desvantagens que os tornam úteis em diferentes situações. 
 De uma forma geral, ambos visam estabelecer a integração entre o diagrama de 
classes e o diagrama de especificações textuais dos casos de uso, mostrando como 
as classes colaboram na realização de um cenário de uso (um caso de uso é um 
conjunto de cenários de uso). 
 Uma das grandes contribuições dos diagramas de interação é a identificação de 
novos métodos para as classes e ainda a ajuda na identificação de qual classe deve 
conter um determinado método. 
A UML, em sua versão 2.0, oferece algumas formas de modelar interações, e o diagrama 
de sequência é o mais usado deles. O outro é o diagrama de comunicação, que nas versões 
anteriores à 2.0 da UML era chamado de diagrama de colaboração. 
A seguir, veja algumas diretrizes sobre os diagramas de interação: 
• Num mesmo projeto, podemos até usar os dois diagramas de interação, mas para 
representar interações ou comportamentos diferentes. 
• Não faz sentido usar ambos, por exemplo, para representar um mesmo cenário de 
uso, pois eles têm o mesmo objetivo, porém focos diferentes. 
• Para cenários, casos de uso ou comportamentos diferenciados, podemos optar 
por um dos dois. Mas em geral, usa-se apenas um deles por todo o projeto. 
Comparativo entre os diagramas de interação 
Como vimos, os diagramas de interação podem ser de dois tipos: diagrama de sequência e 
diagrama de comunicação. Cada um tem sua vantagem, que por sua vez atua como 
desvantagem para o outro. Veja, a seguir, um comparativo das vantagens, quando usar, 
pontos fortes e fracos de cada tipo de diagrama: 
Diagrama de Sequência 
Vantagens: 
• Há como saber a ordem de envio das mensagens, com bastante clareza. Já no 
diagrama de colaboração, o conhecimento da sequência das mensagens ocorre 
pela inserção da numeração das mensagens; 
• O diagrama de sequência é oportuno, pelo fato de focar a temporalidade (daí o 
nome sequência) da interação, que é relevante. 
Quando usar: 
• Devemos usar o diagrama de sequência quando o foco for a sequência das 
mensagens no decorrer do tempo. 
Pontos fortes: 
• Mostra com clareza a sequência temporal das mensagens; 
• Amplo conjunto de opções de notação. 
Pontos fracos: 
• A cada novo objeto, o diagrama cresce para a direita, consumindo espaço na 
horizontal, e se muitos objetos participam, dificulta o desenho e leitura. 
 
 
Diagrama de Comunicação 
Vantagens: 
• Normalmente permite construir modelos mais legíveis, comparativamente aos 
diagramas de sequência; 
• O diagrama de comunicação foca nas mensagens enviadas entre objetos que 
estão relacionados. 
Quando usar: 
• Devemos usar o diagrama de comunicação quando o foco forem as mensagens 
enviadas entreos objetos que estão relacionados. 
Pontos fortes: 
• Economia de espaço ao modelar — flexibilidade ao adicionar novos objetos, em 
qualquer direção do desenho. 
Pontos fracos: 
• Difícil perceber a sequência das mensagens, sendo necessária sua numeração 
sequencial; 
• Menos opções de notação. 
O tripé da análise 
 Do ponto de vista da fase de análise de sistemas, existem três modelos que se integram e 
formam uma base mínima para a modelagem e documentação de sistemas. São eles: 
• Diagrama de casos de uso e especificações de casos de uso; 
• Diagrama de classes; 
• Diagrama de sequência ou diagrama de colaboração. 
Esses três diagramas formam o chamado tripé da análise. Veja essa relação na figura ao 
lado: 
 
Casos de uso (em suas especificações) — Especificam o comportamento do sistema (ou 
parte dele), descrevendo as funcionalidades deste. O caso de uso é um conjunto de cenários, 
no qual: 
• O cenário é uma sequência de passos que descreve uma interação entre o 
sistema e um usuário; 
• Todo caso de uso tem o cenário principal, que é o “caminho sem erros”, ou 
seja, tudo acontece sem nenhum problema ou exceção; 
• A cada problema ou exceção, pode-se derivar um novo cenário, mostrando 
como o sistema vai se comportar. 
O diagrama conceitual de classes mostra as classes do domínio do problema. 
O diagrama de sequência ou comunicação mostra a interação (como trocam mensagens) 
entre os objetos (classes) de um determinado cenário (caso de uso). 
Pontos importantes sobre o diagrama de interação 
• Para cada cenário de um caso de uso, teremos um diagrama de interação. 
• Em contrapartida, os diagramas de interação contribuem com a descoberta de 
novas operações, que serão acrescidas nos métodos das classes envolvidas. 
• É sob essa ótica que desenvolveremos o diagrama de sequência, tendo em mãos: 
Diagrama de casos de uso; Especificação de cada caso de uso; Diagrama conceitual 
de classes. 
• Vale observar que, ao elaborarmos o diagrama de sequência, podemos realizar 
melhorias e acréscimos tanto nas especificações de casos de uso, no diagrama de 
casos de uso quanto, principalmente, no diagrama de classes. Neste, além de 
novos métodos para as classes já existentes, poderemos também modelar novas 
classes e até mesmo atributos. 
• Essas alterações são normais, sadias e realmente acontecem, pois à medida que 
vamos evoluindo e nos aprofundando no sistema, aumentamos nossa 
compreensão e capacidade de modelar o sistema mais adequadamente. 
O Diagrama de Sequência 
A partir de agora vamos conhecer as especificidades do diagrama de sequência. 
 Você já sabe que o diagrama de sequência visa mostrar como as classes envolvidas 
interagem (trocam mensagens) para a realização de um caso de uso, mais especificamente de 
um cenário de uso (parte de um caso de uso), ao longo da linha do tempo. O foco aqui é a 
sequência da troca de mensagens. 
Assim, o diagrama de sequência mostra o passo a passo da especificação do cenário de 
uso, evidenciando as classes relacionadas e como elas trocam mensagens entre si, conforme 
ilustra a imagem (trecho de diagrama de sequência) a seguir: 
ATENÇÃO 
A mensagem em um diagrama de sequência representa um método que pertence à classe 
do objeto que recebe a mensagem. Vide a classe Cliente, a seguir, com o método Procurar 
Cliente(). 
 
O objeto Controlador envia uma mensagem de nome Procurar Cliente () ao objeto Cliente. 
O Diagrama de Sequência e seus Elementos 
Dentre os elementos principais de um diagrama de sequência, podemos destacar: 
• Os objetos participantes da interação são organizados na horizontal; 
• Abaixo de cada objeto, existe uma linha pontilhada (linha de vida); 
• Cada linha de vida possui o seu foco de controle (caixa de ativação); 
• O foco de controle indica que o objeto está fazendo algo; 
• As mensagens entre objetos são representadas com linhas horizontais rotuladas, 
partindo da linha de vida do objeto remetente e chegando à linha de vida do 
objeto receptor. 
Representando decisões no diagrama de sequência 
 Muitas vezes, precisamos representar que determinadas mensagens serão enviadas ou 
não de acordo com a chamada condição de guarda; ou ainda representar um conjunto de 
mensagens mutuamente exclusivas (no qual, dentre várias mensagens possíveis, apenas uma 
delas é enviada). Na imagem a seguir, vemos um trecho de diagrama de sequência, no qual 
representamos a decisão. 
 Observe que temos o retângulo, com uma linha tracejada dentro, com o rótulo de 
nome “alt”, indicando um fragmento alternativo para a lógica condicional de exclusão mútua, 
expresso em guardas. Na parte de cima, inicial do retângulo, temos a condição de guarda [Tipo 
Cliente =F] e na parte de baixo, após a linha tracejada, temos outra condição de guarda [Tipo 
Cliente = J]. 
 
Descrição: 
1. O ator informa o tipo de cliente, que pode ser F (física) ou J (jurídica); 
2. Se o Tipo Cliente = F (primeira condição de guarda) = VERDADE, executa-se as 
mensagens que estão associadas a essa condição, ou seja, as mensagens que estão 
antes da linha tracejada; 
a. Ator informa os dados da pessoa física (dados cliente físico); 
b. Ocorre a inserção desses dados, através da chamada ao método Inserir CliFis(), 
que está na classe Pessoa Física; 
3. Se o Tipo Cliente = F = FALSO, desvia-se para a execução das mensagens que estão 
após a linha tracejada, na qual temos outra condição de guarda a ser avaliada; 
4. Se Tipo Cliente = J (segunda condição de guarda) = VERDADE, executa-se as 
mensagens que estão associadas a essa condição, ou seja, as mensagens que estão 
após a linha tracejada; 
a. Ator informa os dados da pessoa jurídica (Dados Jur); 
b. Ocorre a inserção desses dados, através da chamada ao método Inserir CliJur(), 
que está na classe Pessoa Jurídica. 
Exemplo de representação de decisões no diagrama de sequência 
A seguir, veja um exemplo que mostra que pode haver tantas condições de guarda 
quantas forem necessárias. Nele, temos Opcão = A, Opção = B e Else (a mensagem 3 será 
executada se opção diferente de A e opção diferente de B). 
 
Como funciona esse diagrama? 
1) Se [Opção = A] é verdade, chama o método Msg1 do Objeto 1. 
Senão: 
Se [Opção = B] é verdade, chama o método Mgs2 do Objeto 2. 
Senão: 
Chama o método Msg3 do Objeto 3. 
 
Representando repetições no diagrama de sequência 
Além dos elementos já discutidos, o diagrama de sequência possibilita que especifiquemos 
repetições, ou seja, uma ou mais mensagens que são enviadas repetidas vezes. Veja um 
exemplo: 
Esse trecho de diagrama de sequência representa a repetição, na caixa LOOP, chamada de 
quadro de interação, com a condição de guarda [Para cada item de venda], ou seja, enquanto 
houver item na venda e o caixa (ator) digitar um cod produto, as mensagens e interações 
contidas na caixa LOOP serão executadas (ProcurarProd(), Inserir Novo Item() e Incluir Item() ). 
O retângulo que representa a repetição tem o rótulo “Loop”, indicando fragmento de 
repetição enquanto a condição de guarda for verdadeira. 
Observe que os métodos Inserir Novo Item() e Incluir Item() serão executadas se a 
condição [Se produto Exists) for verdadeira. E tal condição varia em função do resultado do 
método ProcurarProd(), contido na classe Produto. 
 
Criação e destruição de objetos 
O diagrama de sequência dispõe de duas notações extras para representar, 
respectivamente, a criação (<<Create>>) e a destruição (<<Destroy>>) de objetos participantes 
da interação. A seguir, veja exemplos das duas notações: 
Uso da criação 
Na figura a seguir, vemos o uso da criação do participante (Objeto Criado). Depois de 
criado, quando recebe a mensagem<<CREATE>>, representado pelo método (CriaObjeto()), o 
Objeto Criado pode receber e enviar mensagens normalmente. 
 
Criação e destruição de objetos 
O diagrama de sequência dispõe de duas notações extras para representar, 
respectivamente, a criação (<<Create>>) e a destruição (<<Destroy>>) de objetos participantes 
da interação. A seguir, veja exemplos das duas notações: 
Uso da destruição 
Na figura a seguir, temos o exemplo da destruição de objetos, quando o objeto destruidor 
envia a mensagem <<destroy>>, representado pela execução do método DestroyMessage(). O 
elemento, representado pelo X, no objeto destruído representa o seu fim. 
Um objeto pode se autodestruir, o que é representado por um X ao final da linha de vida 
de um objeto (neste caso, é como se o objeto enviasse uma destruição a si próprio). 
 
Como hoje as linguagens possuem um sistema de coleta de lixo, não se excluem objetos 
diretamente, mas pode ser relevante indicar que o objeto não é mais necessário e não pode 
ser utilizado. 
Tipos de Mensagens: Síncronas e Assíncronas 
Os exemplos aplicados sobre o diagrama de sequência, até aqui, usaram apenas a 
mensagem síncrona, ou seja, aquela que uma vez enviada, aguarda o retorno (seta pontilhada 
na direção contrária) com a sua conclusão (tal qual uma chama de rotina em um programa). 
O outro tipo é a mensagem assíncrona, ou seja, a que uma vez enviada não necessita 
esperar por uma resposta e pode continuar o fluxo do processamento. 
Um bom exemplo de uso de mensagens assíncronas são os sistemas que necessitam de 
processamento concorrente e por isso devem permitir representar mensagens concorrentes 
assíncronas (mensagens que são processadas em paralelo sem um tempo definido para a sua 
realização e sem esperar o retorno da mensagem para prosseguir). 
A figura a seguir mostra um exemplo de mensagem assíncrona (seta vazia), representada 
pela chamada ao método Message1(), que sai do Objeto 1 para o Objeto 2. Mostramos logo a 
seguir a Message2(), síncrona (seta cheia), para que você perceba a diferença. 
 
Responsabilidade das Classes 
Quando definimos uma mensagem no modelo de interações, estamos atribuindo uma 
responsabilidade a uma classe. 
A modelagem de interações é um procedimento cuja finalidade é decompor as 
responsabilidades do sistema e alocá-las a classes. 
Se partimos do princípio que um sistema terá N responsabilidades, podemos pensar em 
algumas soluções de divisões de responsabilidades entre as classes desse sistema. As soluções 
extremas seriam: uma classe contendo as N responsabilidades ou N classes contendo uma 
responsabilidade cada. Claro que essas duas soluções são inviáveis na prática, mas entre elas 
existem outras possibilidades. 
A tarefa de identificação de classes e atribuição de responsabilidades é complexa e 
existem várias formas para realizá-la. A melhor solução dependerá, obviamente, da expertise 
do modelador e da correta aplicação de alguns princípios básicos de desenvolvimento de 
software. A coesão e o acoplamento são dois desses princípios. Ela é uma medida que indica as 
quão relacionadas (afins) são as responsabilidades de uma classe. Um bom projeto indica uma 
alta coesão, ou seja, as responsabilidades de uma classe devem ser fortemente relacionadas 
entre si. 
Ao modelarmos classes, uma questão de relevância surge. Veja: 
• Qual classe deve ser responsável por um determinado método? 
• Ou seja, em qual classe devemos alocar esse método? 
Para tal decisão, devemos levar em consideração volume, desempenho, segurança e 
outros aspectos físicos, inerentes à implementação. Existe um conjunto de critérios que devem 
ser avaliados, e nosso foco aqui não é nos estendermos nesse assunto, mas alertar da 
preocupação. Apenas para citar, devemos alocar os métodos de forma que tenhamos um 
baixo acoplamento e alta coesão entre as classes. 
Existe um padrão chamado de “padrão especialista” (solução já dada, estudada e 
adaptada) que diz que o método deve ser colocado na classe que conhece a informação 
(tratada pelo método). 
Padrão é uma solução, já usada em projetos anteriores, que deve ser usada e ajuda a dar 
soluções eficientes em nossos projetos. Existem outros padrões, classificados em diferentes 
tipos a serem considerados, que podem ser objeto de uma pesquisa, para a expansão dos 
conhecimentos nesse sentido. 
Os diagramas de interação, em que o diagrama de sequência é um deles, ajudam a clarear 
essa questão, e muitas vezes perceberemos que fizemos uma escolha equivocada de classe, na 
qual inicialmente alocamos determinados métodos. 
Classes de Interface e Controle 
No conceito do desenvolvimento em camadas, devemos separar as classes em: 
<interface> 
É a classe de interface, cujo estereótipo é <<boundary>>, que identifica uma classe que 
serve de comunicação entre os atores e o sistema. 
<controle> 
É a classe de controle, com o estereótipo de <<Control>>, que serve de intermediação 
entre a classe de interface e as demais classes. Fica responsável por interpretar eventos 
ocorridos sobre os objetos <<boundary>> (eventos de mouse e teclado) e encaminhar a classe 
correta que precisa receber aquele evento. 
<entidade> 
São as classes de entidade, com o estereótipo <<entity>>, que representam as classes do 
domínio do problema, que contém o conhecimento do negócio. 
Em geral, temos uma classe de interface por cenário de uso e uma classe de controle por 
caso de uso. 
Tipicamente a sequência entre as classes ocorre conforme o procedimento descrito na 
imagem a seguir: 
1) O ator solicita a ação desejada, pela interface do cenário de uso; 
2) A classe de interface encaminha o pedido a classe de controle; 
3) A classe de controle traduz o pedido e solicita à respectiva entidade que execute 
determinada operação; 
4) A sequência de retornos acontece, até que pela interface com o usuário tem a sua 
resposta. 
 
A seguir, você pode visualizar o diagrama equivalente, alterando apenas a forma de 
apresentar a classe de entidade: 
Quando tratamos do relacionamento entre as classes no diagrama de classes genérico, em 
que a classe de controle intermedia a comunicação entre as classes de interface e as classes de 
entidade, seguimos o seguinte modelo: 
 
AULA 6: Modelos BÁSICOS DE ANÁLISE 
MINIMUNDO DO ESTUDO DE CASO 
Iniciaremos nossa aula com um Estudo de Caso. Observe o minimundo descrito, a seguir. 
A empresa fictícia Faixa Amarela Ltda. confecciona faixas de anúncios por encomenda. 
Como os pedidos vêm crescendo, Seu Pereira, proprietário da gráfica de faixas, encomendou 
um sistema que controle suas atividades, que basicamente compreendem: 
• Controle e acompanhamento dos pedidos; 
• Cadastramento de clientes. 
• O cliente, geralmente indicado por um amigo satisfeito com os serviços da gráfica, 
faz seu pedido; Seu Pereira (o diretor) ou a atendente faz o atendimento e registra 
no caderno de pedidos: 
• Cliente: nome, cpf, endereço completo, tel_fixo, Tel_cel; 
• Pedido: data do pedido, tamanho da faixa (altura e largura), texto a ser escrito, cor 
(amarela, preta ou branca), cor do texto (branco, preto, azul ou vermelho), 
previsão de entrega, valor do serviço e do sinal (50% do valor total do serviço). 
No levantamento de requisitos foi decidido que o sistema deve possuir as seguintes 
funcionalidades: 
Valor 
O valor do serviço é calculado com base na seguinte fórmula: 
• Valor da faixa = Custo_Material + Custo_desenho + % Lucro 
• Custo_Material = área x 20,00 
• Custo_Desenho = número de letras * 0,70 
• % de Lucro = 20 % (Custo_Material + Custo_desenho) 
Prazo 
O prazo de entrega deve ser calculado levando-se em consideração a produção diária de 
faixas, que nãodeve ultrapassar oito. Considere cinco dias úteis por semana, para fins do 
cálculo da data de entrega. 
O prazo deve começar a ser contabilizado após a confirmação do pagamento do sinal. O 
sistema deve calcular o prazo de entrega e o valor do serviço. 
Recibo 
Para cada encomenda, deve ser emitido um recibo, em duas vias, contendo os dados do 
pedido e pagamento (valor do sinal e valor a pagar na entrega). 
Controle de pagamento 
O sistema deve controlar o pagamento do sinal, quando o serviço é iniciado e a data de 
entrega calculada. Apenas a diretoria deve ter acesso a essa funcionalidade. 
O sistema deve controlar o pagamento da parcela a ser paga na entrega. O pagamento do 
sinal deve ser feito por depósito bancário, e o pagamento do saldo deve ser pago contra 
entrega, em dinheiro, cheque ou cartão de débito. 
O produto somente é entregue mediante o pagamento do saldo. A entrega deve ser 
controlada pelo sistema. 
Consulta 
O sistema deve prover uma consulta (disponível apenas a diretoria), de cada pedido 
feito no período, informando: data do pedido, data de entrega, valor do serviço, valor do sinal, 
sinal pago (S/N), serviço finalizado (S/N), serviço pago (S/N) e status do pedido (S/N). 
Mudança de estados 
O pedido, ao longo do seu ciclo de vida, pode ter vários estados e o sistema deve controlar 
os eventos que geram mudança de estado. Vejamos: 
• Ao ser inserido, o status é “Em espera”; 
• Assim que o sinal for pago, o status passa a ser “Pronto para produção”; 
• Quando o responsável técnico da fábrica inicia a produção da faixa, o status passa 
a ser “Em produção”; 
• Ao ser finalizado, o status passa a ser “Pronto”; 
• Ao ser entregue, o status passa a ser “Entregue”. Para ser considerado entregue, o 
pedido tem que ter o saldo de pagamento confirmado. 
Informe ao cliente 
O sistema deve emitir um informe a todo cliente que não faz pedidos há mais de seis 
meses (com base na data corrente). 
Unidades por pedido 
Recentemente, foi feita uma modificação no sistema de pedidos, e agora em um mesmo 
pedido pode ser encomendada mais de uma faixa, até cinco no máximo (mas esta regra pode 
alterar a qualquer momento). 
Solução do Estudo de Caso 
Seguiremos o seguinte procedimento para a modelagem desse sistema com base em UML: 
I. Diagramação da 1ª versão do diagrama de casos de uso; 
Identificação das principais funcionalidades do sistema; 
II. Especificação textual de casos de uso de relevância; 
III. Refinamento do diagrama de casos de uso; 
Identificação de includes ou extends que otimizem a solução; 
IV. Identificação das classes do negócio; 
V. Diagrama conceitual de classes; 
VI. Diagrama de sequência dos casos de uso de relevância. 
Veremos cada passo, a seguir. 
1ª Versão do diagrama de casos de uso 
Observe, ao lado, uma primeira versão do diagrama de casos de uso, no qual figuram as 
grandes funcionalidades do sistema: 
 
Especificações de casos de uso 
A seguir, temos uma breve descrição da finalidade de cada caso de uso modelado na 1ª 
versão do diagrama de sequência. 
 
 
 
 
 
 
 
 
 
 
 
 
Versão refinada do diagrama de casos de uso 
Uma das formas de identificarmos otimizações de casos de uso, com base em includes, é 
através da observação de repetições de trechos nas descrições de casos de uso. 
Observe que, nos casos de uso Confirmar Recebimento do Sinal, Registrar Início da 
Produção, Registrar Fim da Produção e Registrar Entrega do Pedido, temos os dois trechos a 
seguir repetidos: o primeiro no cenário principal e todo o cenário alternativo. 
Cenário principal: 
1. Usuário informa ID do pedido; 
2. Sistema localiza pedido com ID do pedido; 
3. Sistema exibe dados do pedido. 
Cenários alternativos: 
2. a. Pedido não localizado; 
 1. Sistema emite mensagem “Inconsistência de dados; pedido não localizado”; 
 2. Sistema retorna ao passo 1 do cenário principal. 
A otimização que pode ser feita seria a inclusão do caso de uso «Pesquisar Pedido» é 
relacioná-lo, através do relacionamento «include», aos casos de uso anteriormente citados. 
A seguir, uma versão refinada, com as considerações anteriores: 
As especificações dos casos de uso também precisam ser modificadas para refletir as 
alterações representadas no diagrama. 
Observe que, no local das três linhas que havia anteriormente na especificação do caso de 
uso “Confirmar Recebimento do Sinal”, passamos a ter uma única linha com a inclusão do novo 
caso de uso («Include» Pesquisar Pedido), que também precisa ser especificado. 
E o cenário alternativo de “Confirmar Recebimento de Sinal” passa a ser o cenário 
alternativo do «include» Pesquisar Pedido. 
 
Caso de uso: Confirmar Recebimento do Sinal 
Pré-condição: pedido registrado, cliente registrado e pedido pago. 
Pós-condição: data de entrega do pedido definida. 
Cenário principal: 
1. «Include» Pesquisar Pedido; 
2. Usuário informa data e valor de pagamento do sinal; 
3. Sistema aponta “Pronto para produção” para status do pedido; 
4. Sistema calcula data de entrega do pedido; 
5. Sistema altera dados do pedido. 
Caso de uso Include: Pesquisar Pedido 
Cenário principal: 
1. Usuário informa ID do pedido; 
2. Sistema localiza pedido com ID do pedido; 
4. Sistema exibe dados do pedido. 
Cenário alternativo: 
2. a. Pedido não localizado; 
 1. Sistema emite mensagem: “Inconsistência de dados; pedido não localizado”; 
 2. Sistema retorna ao passo 1 do cenário principal. 
Cabe ressaltar que as mesmas alterações realizadas nas especificações do caso de uso 
“Confirmar Recebimento do Sinal” devem ser realizadas nos casos de uso “Registrar Início da 
Produção”, “Registrar Fim da Produção” e “Registrar Entrega do Pedido”. 
Diagrama Conceitual de Classes 
O diagrama conceitual de classes pode ser extraído dos casos de uso. De uma forma 
simplificada, a extração ocorre: 
• Casos de uso podem ser classes; 
• Casos de uso podem ser métodos. 
Analisando os casos de uso, temos: 
 
Assim temos: 
 
 
Diagrama de Sequência 
Agora passemos aos diagramas de interação, especificamente o diagrama de 
sequência, que nos dará maior clareza dos métodos das classes. 
Vamos elaborar o diagrama de sequência dos casos de uso: Registrar Pedido, Consultar 
pedidos do período e Consultar Clientes sem Pedido, posto que os demais são muito diretos e 
não modificarão nem a alocação de atributos nem a de métodos já alocados, conforme a 
imagem do diagrama anterior. 
Caso de uso: Registrar Pedido - Cenário: Principal 
Este diagrama de sequência cria um conjunto de métodos, nas diversas classes 
envolvidas na interação. Conforme regra já explicada, toda seta que chega em uma classe é um 
método dessa classe. 
 
Os novos métodos descobertos são: 
 
 
 
 
Caso de uso: Consultar Pedidos no Período - Cenário: Principal 
 
Os novos métodos descobertos são: 
Caso de uso: Consultar Clientes em Pedido - Cenário: Principal 
 
Os novos métodos descobertos são: 
 
O Modelo Conceitual 
Após toda a análise das interações, o modelo conceitual de classes ficará conforme o 
exemplo. 
Observe que tal modelo ainda não dispõe de visibilidade de atributos e métodos, bem 
como parâmetros e tipos de dados de retorno dos métodos, propositalmente, pois em geral 
esses dados são inseridos no modelo de classes de projeto, que discutiremos na continuidade, 
que se dará na aula 10. 
Aula 7: Diagrama de Estados 
Estado de um objeto 
O estado de um objeto compreende todas as suas propriedades associadas aos valores 
correntes de cada uma delas. Tais propriedades compreendem os atributos de uma classe. Ou 
seja, o estadode um objeto é determinado pelos valores de seus atributos, em um 
determinado momento. 
Para garantir a propriedade do encapsulamento, é salutar que apenas os métodos que 
denotam o comportamento da classe à qual o objeto pertence alterem os seus respectivos 
atributos. 
Dessa forma, apenas os métodos da própria classe a que o objeto pertença devem 
alterar o seu estado. 
Estado de um objeto 
O período de tempo em que o objeto permanece vivo e ativo, chamamos de ciclo de 
vida, ou seja, o tempo que decorre desde a sua criação até sua destruição. Durante o ciclo de 
vida, o objeto pode ter finitos estados, caracterizados por determinados valores de alguns de 
seus atributos. 
Um objeto muda de um estado para outro na medida em que eventos (internos ou 
externos) acontecem. Quando ocorre uma mudança de estados, dizemos que houve uma 
transição entre estados. 
Assim sendo, temos que: eventos acarretam a transição entre estados de um objeto. 
No momento da transição, o objeto realiza determinadas ações dentro do sistema. 
Pela análise das transições de estados, é possível identificar as operações que precisam 
ser realizadas para responder aos eventos. Tais operações estarão mapeadas em métodos da 
classe a que o objeto pertence. 
O diagrama da UML que ajuda na análise das transições entre os estados de um objeto 
é o diagrama de transição de estados, ou simplificadamente, diagrama de estados. 
O Diagrama de Transição de Estados – DTE 
O diagrama de transição de estados - DTE apresenta os possíveis estados de um objeto 
e demonstra, por meio das transições, os eventos que geram as mudanças de um estado para 
outro (s), durante todo o ciclo de vida do objeto. 
Em outras palavras, o DTE descreve o ciclo de vida de objetos de uma classe, os 
eventos que causam as transições entre estados e as operações resultantes. 
Diferentemente dos diagramas de interação (que descrevem o comportamento de 
objetos de diferentes classes, mostrando a interação entre elas), o DTE mostra o 
comportamento de objetos de uma única classe. 
 
Conceitos Básicos: Estado, Evento e Transição 
Veja, agora, alguns conceitos básicos do diagrama de transição de estados: 
Estado 
O estado de um objeto é a sua condição específica, em algum momento em que ele 
está sendo usado no sistema. 
Segundo a definição de Booch, Rumbauch e Jaconson (2006), estado é uma condição 
ou situação na vida de um objeto durante o qual o objeto satisfaz alguma condição, realiza 
alguma atividade ou aguarda um evento. 
Um objeto permanece em um estado por um tempo finito. Cada estado de um objeto 
é, em geral, determinado pelos valores de seus atributos. 
Esta imagem mostra a representação de um estado, segundo a UML — um retângulo 
com bordas arredondadas 
 
Evento 
Um evento é a ocorrência (interna ou externa) de um estímulo gerado para o objeto, 
capaz de mudar o seu estado atual. 
Transição 
Uma transição indica um movimento de um estado para o outro, pela ocorrência de 
um evento. 
A imagem a seguir mostra o evento e a consequente transição de estado, onde a 
ocorrência do evento faz com que haja a transição (representada pela seta) entre o “estado 
UML 1” para o “estado UML 2”. A seta indica a direção da transição. Observe: 
 
Exemplo de Diagrama de Transição de Estados 
Os estados podem ser classificados em dois tipos, que são chamados de 
pseudoestados. São eles: 
Estado inicial 
O estado inicial é representado pelo círculo preenchido e denota o pseudoestado de 
um objeto no momento de sua criação, quando ele é instanciado na memória. Só há um 
estado inicial em um DTE, mostrando o início de sua leitura. Veja o exemplo: 
Estado final 
O estado final é representado pelo círculo preenchido com outro círculo em volta e 
denota o pseudoestado do fim do ciclo de vida de um objeto. É um estado opcional, no DTE, e 
também pode haver mais um. Veja o exemplo: 
A figura a seguir mostra um exemplo simples de diagrama de estados que contempla 
os elementos básicos, que foram explicados anteriormente. Veja: 
 
Neste exemplo, o estado inicial indica o estado quando o objeto é criado, por isso 
citamos como pseudoestado, pois na verdade ainda não é propriamente um estado. 
Analisando um Diagrama de Estados e seus Elementos 
Vamos identificar os elementos do diagrama de estados, analisando a figura a seguir, 
que apresenta o diagrama de estado (DTE) de uma classe Quarto de um sistema de gestão 
hoteleira: 
 
O início ocorre no pseudoestado inicial que é a bola preta, cuja seta aponta para o 
estado Disponível, efetivamente o estado em que fica o quarto inicialmente. 
Ou seja, assim que o objeto é criado (estado inicial), ele já entra no estado Disponível. 
Imagine um quarto sendo criado (novo quarto) que, ao ser inserido no sistema (estado inicial), 
entra no estado Disponível. 
Estando no estado Disponível, o estado pode transitar para o estado Reservado 
quando ocorre o evento “Cliente faz Reserva”. 
Ou seja, assim que um cliente confirma uma reserva, o estado do objeto quarto 
transita (muda) para Reservado. 
Estando no estado de Reservado, pode haver duas transições distintas: 
• Transição (de volta) para o estado Disponível se ocorrer o evento “Reserva é 
cancelada”; 
• Transição para o estado Ocupado, se ocorrer o evento “Cliente faz check-in” 
(chega ao hotel para hospedar-se). 
Do estado Ocupado, só pode haver transição para o estado Em Limpeza, na medida em 
que ocorre o evento “Cliente faz check-out” (deixa o hotel). 
Estando no estado Em Limpeza, o quarto voltará ao estado Disponível na ocorrência do 
evento “Atendente libera Quarto”. 
Estando no estado Disponível, o Quarto pode mudar também para o estado Final, 
quando for excluído do sistema (quarto deixa de existir para hospedagem). 
Exemplo de diagrama de estados 
Os estados determinam e delimitam as operações que podem ser realizadas com 
aquele objeto. Veja um exemplo: 
Pela análise do DTE, um hóspede não pode chegar ao hotel e hospedar-se sem que 
tenha feito uma reserva: isto é interpretado pela ausência de transição entre os estados 
Disponível e Ocupado. Somente existe transição para o estado Ocupado, estando no estado 
Reservado. 
Para que seja possível a ocupação de quarto sem a devida reserva, o DTE deveria ser 
como o representado na imagem a seguir, em que, pela transição de Disponível para Ocupado, 
acabamos com a obrigação de reservar um quarto para poder ocupá-lo. 
A representação das transições entre os estados Disponível e Reservado foi feita por 
uma seta dupla (nas duas direções). 
Na seta que representa a transição do estado Disponível para Reservado, temos a 
ocorrência do evento “Cliente Faz Reserva”; 
Na seta que representa a transição de Reservado para Disponível, temos a ocorrência 
do evento “Reserva é cancelada”. 
Detalhando a Transição 
A transição, em um diagrama de estados, indica um movimento de um estado para 
outro. Cada transição possui um rótulo que possui três partes. Veja: 
Assinatura do gatilho 
Via de regra, é um único evento que demanda a mudança de estado. No exemplo 
inicial, sobre os estados do Quarto do hotel, usamos apenas a assinatura do gatilho (Cliente 
Faz Reserva, Cliente Faz Check-in etc.), ou seja, o evento que ocasiona a transição de estado. 
É raro que esteja ausente, mas pode ocorrer e denota que a transição é feita 
imediatamente. 
Sentinela 
Quando estiver presente, corresponde a uma condição que deve ser verdadeira para 
que a transição ocorra. Se ausente, indica que a transição sempre acontece. É representada 
entre colchetes [..], com a condição dentro. 
Atividade 
É um comportamento executado durante a transição. A ausência de atividade diz quenada é feito durante a transição. 
Exemplo de transição completa 
O trecho de DTE a seguir mostra uma transição completa. Veja a descrição: 
• Assinatura do gatilho: Saque de R$ 
• Sentinela: [Saldo ˂ 0] 
• Atividade: Aguardar depósito 
Ações de Entrada e Saída, Transições internas e Atividades 
Seguem algumas características avançadas do DTE, que ajudam a otimizá-lo, a reduzir 
a quantidade de estados e a sua complexidade: 
Ações de entrada e saída 
São ações realizadas dentro do estado, assim que entra no estado (entrada) e antes de 
sair dele (saída), independentemente da transição. Veja a descrição: 
A cláusula Entry denomina uma ação de entrada no estado, assim como a cláusula Exit 
é usada para ações de saída; 
A cláusula Entry pode ser usada para especificar uma ação a ser efetivada no momento 
em que o objeto entra no respectivo estado; 
A cláusula Exit especifica ações a serem realizadas sempre que o objeto sai de 
determinado estado. 
Transição interna 
Os estados podem reagir a eventos, que não ocasionam transição, usando atividades 
internas. Ou seja, são eventos que precisam ser tratados, mas que não ocasionam transição de 
estado. 
As atividades internas não disparam ações de entrada e saída, na medida em que não 
saem e entram do objeto, em decorrência do evento. 
Atividades 
Em geral, o objeto fica ocioso em um estado até que um evento ocorra. Porém, talvez 
você deseje que um objeto permaneça realizando uma tarefa, até que determinado evento 
ocorra. Ou seja, executa uma atividade enquanto está nesse estado. 
A cláusula do indica que há uma atividade naquele estado. 
Veja, agora, um exemplo de como declarar no estado ações de entrada (Entry), de 
saída (Exit) e atividades (do): 
 
 
Retornando ao exemplo do DTE referente à classe Quarto do sistema Hotel, 
poderíamos eliminar o estado Em limpeza, fazendo com que a Limpeza seja uma ação de saída 
(Exit) do estado Ocupado, e assim, reduziremos o número de estados. Ou seja, quando o 
cliente fizer o check-in, evento que ocasiona a transição de Ocupado, em vez de ir para o 
estado Em limpeza, iria direto para Disponível e acrescentaríamos uma ação de saída (Exit), de 
nome Limpeza, ao estado Ocupado. 
O diagrama de estado alterado para atender ao especificado, é representado na 
imagem a seguir: 
 
Observe que: 
Desaparece o estado Em limpeza; 
A limpeza passa a ser uma atividade que será realizada antes do estado transitar para 
Disponível; 
Entre Disponível e Ocupado, a transição pode acontecer nos dois sentidos: de 
Disponível para Ocupado, quando ocorrer o evento “Cliente Faz Check-in”; e de Ocupado para 
Disponível, quando ocorrer o evento “Cliente faz Check-out”. 
Superestados 
Um superestado, também chamado de estado composto, ajuda a simplificar a 
modelagem de comportamentos complexos, sendo composto de vários estados ou 
subestados. 
 
 
 
 
O primeiro diagrama é o principal e tem um superestado, de nome Ativo. Observe que 
ele tem um símbolo dentro, que mostra que contém em si outros estados. 
O estado Cancelado tem uma transição do estado Ativo, denotando que pode haver 
uma transição de qualquer estado do superestado Ativo para o estado Cancelado. Se não fosse 
assim, haveria uma transição de cada estado para Cancelado, o que não estaria errado, mas 
tornaria o desenho mais complexo. 
 
A segunda imagem mostra o desdobramento do estado Ativo, composto dos 
subestados Solicitado, Em produção, Embalando e Entregue. 
 
Contribuições do DTE ao Diagrama de Classes 
Para finalizarmos esta aula, veja algumas contribuições do DTE ao Diagrama de 
Classes: 
O DTE pode ser construído com base nas especificações de casos de uso, nos 
diagramas de interação e nos diagramas de classes; 
Novas propriedades (atributos e métodos) podem ser descobertos ao elaboramos o 
DTE e devem ser incorporados ao diagrama de classes; 
Pode ser necessária a atualização de um ou mais métodos de uma classe, para refletir 
o comportamento do objetos nos respectivos estados. Por exemplo: o comportamento do 
método sacar() da classe ContaBancária varia em função do estado no qual esta classe se 
encontra. Saques, por exemplo, não podem ser realizados em uma conta que esteja no estado 
Bloqueada. 
Aula 8 Diagrama de atividades 
Fluxograma, o precursor do diagrama de atividades 
Quem programava lá pelo final dos anos 1970 e início dos 1980 vai se lembrar de uma 
ferramenta muito usada para especificação da lógica de programas: o fluxograma. 
Antes de escrever o código na linguagem de programação, os programadores 
pensavam na lógica do programa e, através do fluxograma, modelavam graficamente (através 
de formas geométricas) os fluxos de controle desse programa. Foi uma das primeiras 
ferramentas de modelagem gráfica usadas. 
A figura ao lado ilustra um fluxograma, que mostra a lógica de um programa para “ler 
dois números, diferentes de zero, e achar a média aritmética desses números”. 
 
 
Fluxograma, o precursor do diagrama de atividades 
Em tese, o fluxograma pode ser usado para representar o fluxo de procedimentos ou 
processos das empresas, conforme ilustra a imagem a seguir. 
Cada forma geométrica tem um significado específico nos diagramas, como por 
exemplo, o losango, que representa uma decisão (pergunta), que tem como resposta uma, 
duas ou mais opções, dependendo do tipo de decisão. 
Fluxogramas, conforme podemos ver nos exemplos apresentados, apenas possibilitam 
representar atividades sequenciais, cujo fluxo pode ser alterado por decisões (representadas 
pelos losangos). 
O diagrama de atividades, inspirado nos fluxogramas, apresenta uma formatação 
diferenciada, com novos elementos (conforme definido na UML) e novas possibilidades. 
A principal diferença, que faz o diagrama de atividade mais versátil que os 
fluxogramas, é a possibilidade de representar atividades que ocorrem em paralelo. 
 
Os primeiros elementos do diagrama de atividades 
Os elementos do diagrama de atividades diferem daqueles usados nos fluxogramas, 
mas sua essência é bem próxima. Os principais elementos do diagrama de atividades são: 
 
 
 
 
 
 
 
 
 
 
 
 
Exemplo de ponto de merge 
Observe o diagrama a seguir: 
 
Conforme trecho de digrama de atividade apresentado nessa imagem, temos: 
 O primeiro losango é o desvio e o segundo a intercalação; 
 Após processar o pedido, será feita a entrega, que pode ser de duas formas (aí 
entra a decisão): 
Se o pedido for urgente, será executada a atividade entrega urgente; 
Caso contrário, se o pedido for normal, será executada a atividade entrega normal. 
Como temos dois caminhos e a próxima atividade será a mesma para ambos os 
caminhos, surge a necessidade de unificar esses caminhos, daí o uso da intercalação, a partir 
da qual será executada a atividade encerrar pedido. 
 
 
Representando o fluxo de controle paralelo 
A UML dotou o diagrama de atividades de dois elementos que operam em conjunto, 
que permitem expressar o comportamento paralelo, ou seja, uma ou mais atividades que 
podem acontecer ao mesmo tempo. Muitos afirmam ser esse o grande diferencial do 
diagrama de atividades da UML para outras ferramentas gráficas, como o fluxograma, que se 
atem apenas a representar o processamento sequencial. 
A programação em paralelo em algoritmos concorrentes não é muito comum no 
mundo comercial, sendo mais usada em software básico (como por exemplo, em sistemas 
operacionais). 
O poder do paralelismo do diagrama de atividade é mais comumente usado para 
representar processos de negócio ou fluxos de trabalho. 
Para iniciar ou sincronizar dois ou mais fluxos de trabalho emparalelo, são usados dois 
tipos de barras de sincronização: bifurcação (fork) e junção (joint). 
Para visualizar alguns exemplos de paralelismo no diagrama de atividades, clique no 
botão a seguir: 
Raias de natação 
Para entender melhor o particionamento do diagrama de atividades, vamos pensar nas 
raias de natação, que exibem os agentes que realizam cada atividade no diagrama. 
O diagrama de atividades também é dividido em compartimentos, nos quais cada um 
será executado por um agente, que poderá ser: departamentos ou setores da empresa 
(financeiro, contabilidade, criação, propaganda etc.), funções ou cargos de pessoas nas 
empresas (gerente, operação, atendente etc.), papéis nas empresas (fornecedor, cliente, 
segurado, seguradora etc.). 
O diagrama de atividades representa, ainda, a lógica de casos de uso ou de métodos 
complexos de uma classe. Já as raias podem representar: objetos, componentes e atores. 
Observe o diagrama de atividades a seguir, com o uso de raias de natação, com as 4 
entidades envolvidas no pedido: o cliente faz o pedido, o departamento de vendas processa o 
pedido, o estoquista separa os produtos do pedido e o setor de distribuição despacha os 
produtos ao cliente. 
 
Para que usar o diagrama de atividades? 
Muitos autores (Eduardo Bezerra, Martin Fowler, dentre outros) já destacaram o 
pouco uso dos diagramas de atividades em projetos de desenvolvimento de software. Mesmo 
que voltados para as utilidades descritas a seguir, o uso de diagrama de atividades não ocorre 
em larga escala, e os principais motivos são: 
1) Documentar sistemas não é uma prática usual no Brasil, em função de vários motivos 
que não cabem discutir aqui. 
2) Em sistemas desenvolvidos sob o paradigma da orientação a objetos, o 
particionamento do sistema é por classes, e não por funcionalidades (como seria nos 
paradigmas estruturado e essencial); como o diagrama de atividades descreve um 
comportamento, estaria, pela lógica, mais relacionado a funcionalidades. 
Modelagem de processos de negócios e fluxos de trabalho 
Essa utilização é que mais tira proveito do fato de o diagrama de atividades permitir 
representar fluxos de controle paralelos, já que em muitos processos de negócio e em fluxos 
de trabalho, as sequências de atividades costumam acontecer em paralelo. 
Modelagem da lógica de um caso de uso complexo 
Muitas vezes, a especificação textual de casos de uso complexos demanda muito esforço 
e, por vezes, por sua extensão, é difícil de ser visualizada como um todo (ocupando mais de 
uma folha de papel ou de editor de texto). 
A especificação do passo a passo de um cenário de uso complexo pode se valer do 
diagrama de atividades. 
A restrição aqui, muito bem descrita por Martin Fowler, é que o usuário final (especialista 
do domínio do problema), geralmente leitor das especificações de casos de uso, poderia não 
acompanhar o diagrama com facilidade. 
Em contrapartida, a grande vantagem é que os cenários principal e alternativos podem ser 
representados no mesmo diagrama, facilitando a visão do caso de uso como um todo. 
Outra limitação é que os casos de uso são descritos na visão dos atores e o diagrama de 
atividades especifica as atividades do sistema (ações do sistema); neste caso, as interações do 
ator para informar dados devem ser representadas em atividades. 
Modelagem da lógica de uma operação complexa 
Embora não seja muito usual, os métodos de classes podem ter uma lógica complexa, 
especialmente em classes de controle; neste caso, o diagrama de atividades pode ser útil para 
representar a lógica desse método. 
Modelar a lógica de algoritmos paralelos para programas concorrentes 
Pode-se valer dos elementos (separações e junções) usados pelo diagrama de atividades 
para representar o processamento paralelo em programas concorrentes. 
Subatividades no diagrama de atividades 
As atividades, quando complexas, podem ser decompostas em subatividades. Neste caso, 
tal atividade decomposta terá um diagrama especificando suas subatividades e o diagrama 
principal terá uma representação diferenciada — com símbolo do ancinho, conforme esta 
imagem: 
 
Para visualizar alguns exemplos de subatividade do diagrama de atividades, clique no 
botão a seguir: 
Aplicando diagrama de atividades 
Vamos observar uma aplicação do diagrama de atividades. Para isso, observe as 
informações abaixo: 
Modelagem da lógica de um caso de uso complexo 
Considere a seguinte especificação do caso de uso registrar pedido: 
 Caso de Uso: Registrar Pedido 
 Pré-condição: -- 
 Pós-condição: pedido registrado e cliente registrado, caso seja novo cliente 
Cenário principal: 
1. Usuário informa Id do cliente 
2. Sistema localiza cliente com Id do cliente 
3. Sistema exibe nome, e-mail e telefones do cliente 
4. Usuário informa dados do pedido (1) 
5. Sistema calcula valor do serviço (2) 
6. Sistema aponta EM ESPERA para status do pedido 
7. Sistema registra pedido 
8. Sistema emite boleto do pedido (*) 
Cenários alternativos: 
2.a. Cliente não localizado 
 1. Extends cadastrar cliente 
(1) Dados do pedido: altura e largura da faixa, texto da faixa, cor da faixa, cor do texto 
(2) Valor do serviço = Custo_Material + Custo_desenho + % Lucro 
 Custo_Material = área x R$ 20,00 
 Custo_Desenho = número de letras x R$ 0,70 
 % de Lucro = 20 % x (Custo_Material + Custo_desenho) 
 Valor do sinal = 50% x Valor Serviço 
Aplicando diagrama de atividades 
Vamos observar uma aplicação do diagrama de atividades. Para isso, observe as 
informações abaixo: 
 Modelagem da lógica de um caso de uso complexo 
 Segue uma das possíveis soluções do diagrama de atividades: 
Observe que os passos do caso de uso, como exibir dados (passo 3) e alteração de status 
(passo3), por serem ações simples, podem ser omitidos do diagrama de atividades. 
Representá-los não seria um erro, mas detalhes que podem ser omitidos. 
Observe que o extends do caso de uso (cadastrar cliente) é considerado uma atividade e 
representado no diagrama de atividades, dando a visão do cenário principal e do alternativo. 
 
Aula 9: diagramas de componentes e implantação 
Diagrama de Componentes 
O diagrama de componentes mostra os componentes de um sistema e suas 
dependências. São úteis para a modelagem da arquitetura física de um software, 
apresentando os componentes físicos, suas interfaces e dependências. Esse diagrama permite 
o desenvolvimento baseado em componentes, em que um software é dividido em 
componentes e interfaces reutilizáveis e substituíveis. Veja um exemplo: 
Imagine um sistema de home theater, composto por componentes que podem ser 
facilmente conectados uns aos outros e substituídos a qualquer momento: projetor, receiver, 
caixas de som (frontal, lateral, subwoofer). Se qualquer elemento queimar, poderemos 
substituí-lo por um igual ou equivalente (com as mesmas interfaces). 
A ideia do uso de componentes em software é a mesma: conjunto de componentes, 
com interfaces bem definidas, que podem ser integrados a qualquer sistema e substituídos 
sempre que necessário. 
Componentes 
A UML define componente da seguinte forma: 
 
Assim, um componente pode ser definido como uma caixa preta, em que são 
especificadas suas interfaces para que outros componentes possam usar seus serviços, sem 
conhecer detalhes de como esses serviços estão sendo implementados. Ou seja, o 
componente encapsula (protege) o seu conteúdo, e seu comportamento é definido em função 
de prover e requerer serviços, através de suas interfaces. 
O desejo é que o componente possa ser independente e intercambiável. Em um 
sistema baseado em componentes, cada componente tem uma finalidade,ou seja, presta um 
serviço, e para tal, demanda o uso de outros componentes. 
Esta imagem mostra a representação do componente na UML por nome 
“Componente”. Veja: 
 
Interfaces 
Interfaces são elementos que definem um conjunto de operações que outros 
elementos, como classes ou componentes, devem implementar. Um mesmo componente 
pode tanto fornecer como requerer interfaces. O relacionamento entre os componentes e as 
interfaces é a essência dos sistemas. 
Em diagramas de componentes, existem dois tipos de interfaces. Veja: 
Interfaces fornecidas 
Descrevem os serviços oferecidos a outros componentes. Um componente pode 
declarar quantas interfaces fornecidas forem necessárias. 
O símbolo de uma interface fornecida é o círculo apresentado à esquerda do 
componente, conforme a imagem abaixo: 
 
Interfaces requeridas 
São as interfaces usadas pelo componente, quando solicita serviços de outros 
componentes. Um componente pode ter várias interfaces requeridas. 
O símbolo da interface requerida é um semicírculo apresentado à direita do 
componente, conforme a imagem abaixo: 
 
Componentes e Interfaces 
O usuário do serviço de um componente deve conhecer bem a sintaxe das interfaces 
do componente. Analogamente ao exemplo dado de início, as interfaces são as conexões 
possíveis entre o receiver do home theather e os dispositivos (projetor, caixas, DVD, TV etc.). 
Para usarmos um DVD, precisamos saber as possíveis conexões: HDMI, DVI etc. Para 
usar um componente, precisamos saber as possíveis interfaces. 
Existem duas maneiras de representar o relacionamento entre componentes e 
interface, conforme mostram as duas imagens a seguir. 
Nesta representação, o componente que usa a interface se conecta ao outro 
componente por meio do relacionamento de dependência. 
 
O componente que fornece a interface é conectado a ela pelo relacionamento de 
realização (entre o componente fornecedor e a interface). 
Componentes e Interfaces 
O usuário do serviço de um componente deve conhecer bem a sintaxe das interfaces 
do componente. Analogamente ao exemplo dado de início, as interfaces são as conexões 
possíveis entre o receiver do home theather e os dispositivos (projetor, caixas, DVD, TV etc.). 
Para usarmos um DVD, precisamos saber as possíveis conexões: HDMI, DVI etc. Para 
usar um componente, precisamos saber as possíveis interfaces. 
Existem duas maneiras de representar o relacionamento entre componentes e 
interface, conforme mostram as duas imagens a seguir. 
O componente que usa a interface (componente usuário) é a ela conectado pelo 
relacionamento de dependência (entre o componente usuário e a interface). O 
relacionamento de dependência determina que um componente pode usar os serviços ou 
depender de outro elemento do sistema. 
 
Componentes e Interfaces 
Na imagem a seguir, temos o exemplo do componente Login Usuário, onde «build 
component» é um estereótipo. Esse componente tem: 
Duas interfaces providas, ou seja, serviços prestados ao usuário: Validar Usuário e 
Validar Senha; 
Uma interface requerida, ou seja, serviço que precisa usar: Conexão. 
 
Para visualizar um exemplo de diagrama de componentes, clique no botão a seguir: 
Diagrama de Implantação 
O diagrama de implantação mostra o layout físico de um sistema, revelando quais 
partes do software são executadas em quais partes do hardware (fowler). Enfoca a estrutura 
física sobre a qual o software vai executar. Define como as máquinas estarão conectadas e 
através de quais protocolos se comunicarão. 
Seus elementos são os nós e as conexões entre eles. Essas conexões representam um 
caminho de comunicação entre os nós. Assim como as associações, possuem nome e 
multiplicidade. 
Portanto, um diagrama de implantação mostra o local onde os componentes e 
artefatos são utilizados no sistema em funcionamento. 
Nó 
Um nó, em um diagrama de implantação, representa um recurso computacional de um 
sistema, como servidores, impressoras, terminais remotos, computadores pessoais, dentre 
outros. Em geral, o nó é identificado por um nome, que o descreve, conforme esta imagem: 
 
Podemos representar, em diagramas de implantação, a existência de componentes 
dentro de um nó, conforme estes exemplos: 
 
Nesse caso, representamos a relação de dependência entre os componentes. 
 
A possibilidade de representar os componentes que vão executar em um nó é positivo 
no sentido de possibilitar a definição da configuração do nó, tanto em termos de capacidade 
de processamento como de memória principal e secundária (discos). 
Caminhos de Comunicação (Conexões) 
Os nós em um diagrama de implantação são conectados por caminhos de 
comunicação, que é um relacionamento de associação, em que podem constar: multiplicidade, 
papel e nome do relacionamento (em geral, pelo tipo de protocolo de comunicação). Neste 
caso, a associação representa uma conexão física entre os nós. 
Segue um exemplo de dois nós representando um sistema cliente-servidor, onde o 
caminho de comunicação é o protocolo TCP/IP, através da internet: 
 
Exemplos de Diagrama de Implantação 
Veja alguns exemplos de diagrama de implantação: 
A imagem a seguir apresenta um diagrama de implantação com seus elementos 
básicos: 
Nós: tablet do vendedor, CPU do vendedor, CPU do gerente, servidor de aplicações, 
servidor de BD e impressora. 
Caminhos de comunicação: TCP/IP e porta USB (conectando CPU do vendedor e 
impressora). 
 
Segue o exemplo do diagrama de implantação para o sistema de caixa eletrônico, o 
mesmo para o qual elaboramos o diagrama de componentes (aqui nesta mesma aula). 
 
 
 
Segue o refinamento do diagrama anterior, mostrando os componentes que vão 
executar em cada um dos nós. 
Repare que conhecer os componentes que cada nó precisará executar nos permite 
reconhecer a capacidade de cada um, em termos de processamento (processador), capacidade 
de memória (RAM), capacidade de disco e outras configurações. 
Por fim, cabe ressaltar que “o diagrama de implantação deve fazer parte dos manuais 
para instalação e operacionalização dos sistemas” (Bezerra 2015). 
 
Aula 10: Práticas dos modelos (UML) e abordagens em camadas 
Minimundo do Estudo de Caso 
Vamos iniciar esta aula realizando um estudo de caso. Observe: 
Esta é a gráfica Faixa Amarela Ltda. que confecciona faixas de anúncios ou outras 
finalidades por encomenda. 
Vamos iniciar esta aula realizando um estudo de caso. Observe: 
Este é o proprietário da gráfica de faixas, seu Pereira. 
Como os pedidos vêm crescendo, ele encomendou um sistema que controle suas 
atividades. 
Entenda melhor sobre as características desse sistema clicando aqui. 
Solução ao projeto 
Para desenvolver o sistema solicitado pelo seu Pereira, proprietário da gráfica Faixa 
Amarela, seguiremos o seguinte procedimento para modelagem da continuidade dos 
diagramas da UML: 
 Diagrama de estados, identificando as classes que têm necessidade desse diagrama; 
 Derivação do diagrama conceitual de classes, com base no diagrama conceitual de 
classes; 
 Construção do diagrama de atividades para casos de uso complexos e/ou identificar a 
necessidade de diagrama de atividades para métodos de classes com algoritmos 
complexos; 
 Construção do diagrama de componentes; 
 Construção do diagrama de implantação. 
Diagrama de Estados 
O primeiro passo é analisar o diagrama conceitual de classes e identificar as que terão mais 
de um estado durante o ciclo de vida do sistema: 
Cliente 
Os objetos da classe cliente tem apenas um estado em todo o ciclo de vida do sistema. 
Nesse caso, não há necessidade de diagrama de estado. 
Pedido 
Possuem vários estadosao longo do ciclo de vida, em função da fase em que o pedido se 
encontra. Nesse caso, é necessário o diagrama de estados. 
Itens Pedido 
É a classe que compõe a classe Pedido e depende do estado de pedido. Nesse caso, não há 
necessidade de diagrama de estados. 
 
Conclusão do diagrama de Estados 
Com base no diagrama que vimos anteriormente, podemos concluir que apenas 
teremos diagramas de estados para a classe PEDIDOS, que através do atributo STATUS 
armazenará os diferentes estados que poderão assumir os objetos da classe PEDIDO, durante 
o ciclo de vida do sistema. Observe que o próprio enunciado já nos informa os estados de 
PEDIDO, neste trecho extraído do enunciado: 
O pedido, ao longo do seu ciclo de vida, pode ter vários estados, e o sistema deve 
controlar os eventos que geram mudança de estado. 
Ao ser inserido, o status é EM ESPERA; 
Assim que o sinal for pago, o status passa a ser PRONTO PARA PRODUÇÃO; 
Quando o responsável técnico da fábrica inicia a produção da faixa, o status passa a ser 
EM PRODUÇÃO; 
Ao ser finalizado, o status passa a ser PRONTO; 
Ao ser entregue, o status passa a ser ENTREGUE. Para ser considerado ENTREGUE, o 
pedido tem que ter o saldo de pagamento confirmado. 
Conclusão do diagrama de Estados 
Os possíveis estados da classe Pedido podem ser vistos na tabela a seguir: 
 
Diagrama de Atividades 
Para compreender como usar o diagrama de atividade, vamos modelar três casos de 
uso. Mas antes, saiba que esse diagrama amplia a visão das especificações de casos de uso, na 
medida em que permite que modelemos também (em conjunto) os cenários alternativos. 
Os casos de uso que terão as suas especificações complementadas pelos respectivos 
diagramas de atividades são: Registrar Pedido, Incluir Cliente, Cadastrar Cliente e Confirmar 
Recebimento de Sinal. 
Caso de Uso Registrar Pedido 
 
 
Para compreender como usar o diagrama de atividade, vamos modelar três casos de 
uso. Mas antes, saiba que esse diagrama amplia a visão das especificações de casos de uso, na 
medida em que permite que modelemos também (em conjunto) os cenários alternativos. 
Os casos de uso que terão as suas especificações complementadas pelos respectivos 
diagramas de atividades são: Registrar Pedido, Incluir Cliente, Cadastrar Cliente e Confirmar 
Recebimento de Sinal. 
Subatividade INCLUIR CLIENTE 
O mais interessante desta modelagem de subatividade para INCLUIR CLIENTE é que ela 
será aproveitada também no diagrama de atividade do caso de uso CADASTRAR CLIENTE. 
Observe: 
 
Para compreender como usar o diagrama de atividade, vamos modelar três casos de 
uso. Mas antes, saiba que esse diagrama amplia a visão das especificações de casos de uso, na 
medida em que permite que modelemos também (em conjunto) os cenários alternativos. 
Os casos de uso que terão as suas especificações complementadas pelos respectivos 
diagramas de atividades são: Registrar Pedido, Incluir Cliente, Cadastrar Cliente e Confirmar 
Recebimento de Sinal. 
Subatividade CADASTAR CLIENTE 
Comentários do diagrama de atividade x especificações de casos de uso: 
Observe, novamente, que as atividades correspondem ao passo a passo da 
especificação do respectivo caso de uso, que apresentaremos na sequência. 
Há uma decisão, cuja pergunta é “LOCALIZOU O CLIENTE?”. 
 Em caso negativo, acionaremos a subatividade INCLUIR CLIENTE, já desenvolvida 
no diagrama de atividade do caso de uso REGISTRAR PEDIDO. 
Usaremos novamente aqui. Veja o que ela contém no diagrama apresentado; 
 Em caso positivo, ou seja, o cliente foi localizado, é emitida uma mensagem de 
erro e retornamos à atividade INFORMAR ID CLIENTE. 
Para visualizar a transcrição da especificação do caso de uso Cadastrar Cliente, clique no botão 
ao lado: 
 
Caso de Uso Confirmar Recebimento de Sinal 
Comentários do diagrama de atividade x especificações de casos de uso: 
Nesse diagrama, podemos ver com mais propriedade a grande vantagem do diagrama 
de atividade sobre a especificação de casos de uso, além, claro, de ser gráfico, enquanto a 
descrição é textual: podemos ver todos os cenários alternativos conjugados com a 
diagramação do cenário principal. 
 Temos dois cenários alternativos, representados por caminhos do SENÃO nas 
duas decisões do diagrama. A primeira decisão após a atividade LOCALIZAR 
PEDIDO e a segunda após a atividade INFORMAR DADOS SINAL, com as 
respectivas atividades de emissão de mensagens (cenários alternativos). 
Para visualizar a transcrição da especificação do caso de uso 
 Confirmar Recebimento de Sinal, clique no botão ao lado: 
Diagramas de componentes e de implantação 
Esses dois diagramas estão intimamente relacionados e caracterizam a solução 
arquitetônica definida para o software. O diagrama de atividade é o limiar entre o projeto 
lógico (solução sistêmica) e o projeto físico (solução tecnológica). Assim sendo, antes de 
modelarmos esses diagramas, vamos conhecer as definições tecnológicas da solução, veja: 
O sistema vai rodar na intranet, já deixando toda a plataforma pronta para operar pela 
internet a qualquer momento. Espera-se que, com o crescimento da empresa, em um ano esse 
sistema comece a ser usado pela internet. 
O banco de dados usado será o SQL Server, que a empresa já possui. 
Será usado o sistema de autenticação e firewall já existentes na empresa, bem como a 
estrutura de servidores existentes (aplicações web, servidor BD e servidor impressão). 
O sistema deve ter um design responsivo (operar em qualquer plataforma de 
equipamentos), de forma que funcione em computadores, notebooks, tablets e smartphones. 
O sistema será desenvolvido para a plataforma Windows, usando o gerenciador de 
internet IIS do Windows. 
A linguagem será JAVA. 
As definições tecnológicas da solução não têm compromisso com as melhores 
soluções. Nossa finalidade é acadêmica, e assim estimulá-los a pensar e refletir sobre a 
existência de soluções mais adequadas. 
Diagramas de componentes e de implantação 
Veja, agora, a modelagem dos diagramas de componentes e de implantação: 
Diagrama de Componentes 
 
Através da página da aplicação, tem-se acesso aos componentes PEDIDO e CLIENTES, 
que por sua vez usam as rotinas padronizadas (contidas em Biblioteca Padrão) e as rotinas do 
SGBD SQL SERVER. 
 
 
 
Diagrama de Implantação