Desenvolvimento de sistemas - Aula 01

Aula 01
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.
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.
Para entender um pouco mais sobre a modelagem de sistemas, clique no bot�o abaixo:
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 tornaram-se 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.
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.
Mensagem
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.
Metodos
� 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:
Diferen�a entre o conceito de classes e objetos

A seguir, 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.
Para conhecer um pouco mais sobre os pilares da Orienta��o a Objetos, clique no

bot�o ao lado:
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.
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.
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.
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.
Para conhecer um pouco mais sobre as conclus�es do Paradigma Orientado a Objetos,

clique no bot�o ao lado:
Conclus�es do paradigma Orientado a objetos

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�m disso, 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�.
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�ao
A modelagem gr�fica tende a facilitar a compreens�o, permitindo sua interpreta��o
sem ambiguidades.
Especifica�ao
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�ao
Os diagramas UML podem ser diretamente integrados a v�rias linguagens de
programa��o tais como Java e C++.
Documenta�ao
A UML abrange a documenta��o da arquitetura do sistema e de todos os seus detalhes.
Clique no bot�o ao lado para visualizar um breve hist�rico da UML:
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:
Para conhecer cada diagrama detalhadamente, clique no bot�o ao lado:
Diagramas da atual vers�o da UML

Os diagramas da UML s�o divididos em 2 grupos: Diagramas de Estruturas e
Diagramas Comportamentais, e s�o em total de 14, conforme ilustrado pela
imagem:
A seguir, uma especifica��o de cada um dos diagramas:
Diagrama Especifica��o
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�ficas , 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 sequencia Mostra como os objetos interagem para a realiza��o de
um caso de uso, detalhando a troca de mensagem entre
os objetos.
Diagrama de
comunica��o
� o antigo Diagrama de Colaborac�o, que junto com o
diagrama de sequencia forma o diagrama de intera��o.
Tem a mesma finalidade do diagrama de sequencia,
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 sequencia.
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
processo 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 do sistemas para atender �s
necessidades de seus usu�rios. Ambos est�o usando a UML de forma correta e
expressando como visualizam a sequencia 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�ao

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 mini
projetos, curtos, preferencialmente de dura��o fixa (por exemplo, 3 meses),
denominados itera��es.
Para conhecer um pouco mais sobre os processos iterativos, clique no bot�o ao lado:
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.
Mas o que s�o processos iterativos, afinal?
S�o processos onde o ciclo de vida do sistema � dividido em uma s�rie de mini
projetos, curtos, preferencialmente de dura��o fixa (por exemplo, 3 meses),
denominados itera��es.
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
� Diagrama de classes, j� a partir de uma perspectiva de software;
� Diagrama de sequencia, para cen�rios relevantes e comuns;
� Diagrama de estados;
� Diagrama de componentes, com a arquitetura do software;
� Diagrama de implantac�o, para defini��o do ambiente f�sico e distribui��o dos
componentes.
Atividade
Nessa atividade, vamos identificar os requisitos (necessidades dos usu�rios) de um
sistema!
Para isso, primeiramente leia o texto �Necessidade de usu�rio�.
Com base no texto acima, identifique as funcionalidades que o sistema precisa ter
para atender as necessidades do gerente e da Dona S�lvia.
As funcionalidades s�o:
Liberar pagamento, gerir notas fiscais e controlar estoque.
Aula 02
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.
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 as 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?
Nao 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:
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.
Os requisitos nao 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.
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.
Para saber mais, clique no bot�o abaixo:
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:
�Usu�rio� e �Atendente� s�o os atores.
Os casos de uso �Matricular em curso�, �Incluir Disciplina� e �Cancelar

Disciplina�, est�o interagindo com o ator �Usu�rio�. Isto significa que o Usu�rio �
o ator que interage com essas tr�s funcionalidades.
O caso de uso �Cancelar Matr�cula em Curso�, interagindo com o ator �Atendente�, ou

seja, �Atendente� � quem pode �Cancelar Matr�cula de um Curso�, a quarta
funcionalidade dispon�vel no sistema.
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:
Casos 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�.
Matricular em curso
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.
Gabarito atividade
Passo 1: identifica��o dos atores - elementos que interagem com o sistema
(geralmente substantivos)
? �Paciente�, �Atendente� e �M�dico�
Passo 2: para cada ato, identificar os casos de uso com os quais se relacionam
(a��es, geralmente verbos).
? �Atendente�: �Agendar Consulta�, �Agendar Exame�, �Cancelar Consulta� e
�Cancelar Exame�
? �M�dico�: �Consultar Paciente�
Importante: embora o paciente seja extremamente relevante nesse processo, ele
n�o interage diretamente com nenhuma funcionalidade do sistema, embora todos
os dados imputados no sistema sejam fornecidos por ele.
Em princ�pio, n�o � considerado um ator do ponto de vista da intera��o com o
sistema. Todavia muitos autores consideram-no ator, juntamente com os
verdadeiros atores de cada caso de uso.
Assim sendo, podemos ter duas solu��es, representadas nos dois diagramas de
casos de uso a seguir:
o A primeira mais alinhada com o conceito de ator, na qual o paciente
n�o figura entre os atores.
o A segunda mais alinhada com a situa��o real, na qual o �Atendente� e
o �M�dico� inteagem com o sistema, baseado no que lhes diz o
�Paciente�.
Relacionamentos ou associa��es
O diagrama de casos de uso possibilita, ainda, a exist�ncia de relacionamentos

entre:
Atores e casos de uso

Atores entre si
Casos de uso entre si
A seguir, vamos conhecer cada tipo de relacionamento com mais detalhe!
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:
Relacionamentos entre 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:
Exemplos de Casos de uso por 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 03
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.
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.
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.
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.
Exemplo de especifica��o 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. A seguir, descrevemos as
principais se��es que comp�em o formato completo:
Se��o da Especifica��o Significado
Nome do caso de uso (*) Verbo no Infinitivo + complemento verbal.
Escopo (*) O nome do sistema/ projeto.
N�vel Objetivo do usu�rio ou subfun��o (include, extend e
especializa��o).
Atores (*) Atores envolvidos: principal e secund�rios.
Interessados e Interesses Quem se importa com esse caso de uso e o que eles
desejam?
Pr�-condi��o (*) O que precisa ser verdade para esse caso de uso
acontecer.
P�s-condi��o ou garantia
de sucesso (*)
O que precisa ser verdade quando da finaliza��o bem
sucedida desse caso de uso.
Cen�rio principal (*) O cen�rio de sucesso, um caminho t�pico, incondicional.
O caso de uso foca no cen�rio principal.
Cen�rios alternativos ou
extens�es (*)
Cen�rios alternativos, quando o cen�rio principal tem
uma varia��o do fluxo bem-sucedido.
- A especifica��o deve indicar o ponto em que se se
estende o cen�rio principal (ou t�pico);
- A especifica��o deve indicar o ponto em que se
retorna ao cen�rio principal (ou t�pico) ou em que se
encerra o caso de uso.
Requisitos especiais Requisitos n�o funcionais relacionados
(*) S�o as se��es mais usadas pela maioria dos autores e analistas de
sistemas.
Exemplo de caso de uso �Registrar Venda�
Nome do caso de uso: �Registrar Venda�
Escopo: Sistema de Vendas � PDV
N�vel: Usu�rio
Atores: Caixa
Interessados e Interesses:
- Caixa: deseja que o sistema seja eficiente, sem erros e que tenha f�cil
utiliza��o;
- Cliente: deseja encontrar os produtos de que precisa, adquiri-los de forma
r�pida, sem muito esfor�o e, ao final, obter um comprovante da compra;
- Org�os fiscais: deseja cobrar os impostos de cada venda realizada;
- Operadora de cart�o: deseja receber solicita��es de autoriza��o de cr�dito no
formato e protocolo corretos.
- Etc.
Pr�-condi��o: todos os produtos registrados no sistema e com respectivos pre�os;
caixa autenticado e PDF registrado.
P�s-condi��es: venda salva, impostos calculados, estoques atualizados,
autoriza��es de pagamento registradas, recibo gerado.
Cen�rio principal (ou fluxo b�sico)
1. Cliente chega ao PDV com os itens que deseja adquirir;
2. Caixa inicia uma nova venda;
3. Para cada item de venda do cliente, fa�a:
a. Caixa insere o identificador do item;
b. Sistema localiza o item;
c. Sistema apresenta a linha do item de venda, com o identificador, nome e
valor unit�rio do produto;
d. Sistema calcula os impostos do item;
4. Sistema apresenta o valor total da venda com impostos calculados;
5. Caixa informa total ao cliente e solicita o pagamento;
6. Caixa informa o pagamento do cliente;
7. Sistema registra e trata o pagamento do cliente;
8. Sistema finaliza a venda e apresenta o recibo;
9. Sistema contabiliza a baixa no estoque de cada item vendido.
Cen�rios alternativos (extens�es)
2.a. Sistema n�o inicializa:
1. Caixa inicia a venda em planilha manual (conting�ncia), registrando cada
item e o pagamento em planilha eletr�nica e encerra o caso de uso.
3.a. Sistema n�o localiza o identificador do item:
1. Sistema avisa o erro e rejeita a entrada;
2. Caixa responde ao erro.
2.a. Existe o ID do item leg�vel:
1. Caixa insere o identificador do item;
2. Sistema mostra descri��o e pre�o.
2.b. Existe pre�o na etiqueta:
1. Caixa solicita ao gerente executar operac�o de correc�o;
2. Gerente realiza a corre��o;
3. Caixa indica a entrada manual de pre�o, insere pre�o e solicita imposto
padr�o para essa quantia.
2.c. Caixa invoca ajuda no sistema para localizar o produto, a fim de obter
identifica��o e pre�os reais do item.
2.d. Caso contr�rio, caixa pergunta a um funcion�rio o pre�o e o
identificador do item e executa a entrada manual do itentificador (ver
acima, 2.a) ou do pre�o do item (ver acima 2.b).
3-4 a. Cliente solicita o cancelamento de um item da venda:
1. Caixa insere o identificador do item a ser removido;
2. Sistema remove o item e exibe o total parcial atualizado.
3-6 a. Cliente solicita o cancelamento da venda:
1. Caixa cancela a venda no sistema.
7.a. Pagamento em dinheiro:
1. Caixa insere a quantia do dinheiro fornececida;
2. Sistema apresenta o valor do troco e libera a gaveta do dinheiro;
3. Caixa deposita o dinheiro fornecido e entrega o troco ao cliente;
4. Sistema registra o pagamento em dinheiro.
7.b. Pagamento com cart�o de cr�dito:
1. Caixa insere dados do cart�o do cliente;
2. Sistema mostra o pagamento para confirma��o;
3. Caixa confirma o pagamento;
4. Sistema envia solicita��o de autorizac�o de pagamento � administradora do
cart�o do cliente.
4.a. Sistema detecta falha ao tentar se comunicar com sistema externo:
1. Sistema avisa do erro ao caixa;
2. Caixa solicita ao cliente forma de pagamento alternativa.
5. Sistema recebe aprova��o de pagamento;
6. Sistema registra ao pagamento com cart�o de cr�dito;
7. Sistema apresenta o mecanismo para entrada do pagamento a Cr�dito;
8. Caixa solicita ao cliente a assinatura para pagamento a cr�dito e cliente
fornece a assinatura;
9. Assinatura em papel, caixa, insere o papel na gaveta e a fecha.
8.a. Impressora n�o tem papel:
1. Se o sistema detecta a falha, avisa sobre o pagamento;
2. Caixa rep�e o papel;
3. Caixa solicita outro recibo.
Requisitos especiais
1. Interface de usu�rio com tela sens�vel a toque em um monitor de tela
plana com pelo menos 23 polegadas;
2. Resposta de autoriza��o de cr�dito, dentro de 30 segundos, em 90% dos
casos;
3. A recupera��o de falhas de servidores deve ser consistente e robusta.
Observe que cada passo do cen�rio principal � numerado e em cada um pode haver
uma ou mais falhas (incucessos).
Nos cen�rios alternativos, temos um n�mero e uma letra. Por exemplo: no passo 2
do cen�rio principal (caixa inicia uma nova venda), pode haver uma exce��o
(sistema n�o inicia), que � tratada no cen�rio alternativo como 2.a.), ou seja, a
primeira (a) alternativa do passo 2.
J� o passo 7 (sistema registra a trata o pagamento do cliente), possui dois
cen�rios
alternativos, representados por 7.a (pagamento em dinheiro) e 7.b (pagamento em
cart�o de cr�dito). Caso t�vessemos uma terceira forma de pagamento, como por
exemplo, cheque, este seria o passo 7.c dos cen�rios alternativos.
Repare na quantidade de detalhes dessa especifica��o. Nesse formato, devem ser
considerados todas as possibidades de exce��o e insucesso de cada passo do
cen�rio principal.
A especificac�o anterior poderia ter muitos mais detalhes, como por exemplo o
tratamento das seguintes exce��es:
? A qualquer momento o sistema falha;
? Ttratamento de outras formas de pagamento (cheque, d�bito);
? Caixa cancela o pagamento, e muitos outros.
O detalhamento vai depender do sistema e da necessidade.
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 � <<Include Pesquisar
Dependente >>;
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 retorma 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 execuc�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 explicar como � 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.
Especifica��o do caso de uso �Registrar Devolu��o de DVD�

Segue a especifica��o do caso de uso �Registrar Devolu��o de DVD�, mostrando
como declarar o uso de casos de extens�o:
Solu��o:
Caso de uso: �Registrar Devolu��o de DVD�
Cen�rio principal
1. Atendente informa identifica��o da m�dia;
2. Sistema localiza loca��o com a m�dia informada;
3. Sistema apresenta registro da loca��o com valor a pagar;
4. Atendente informa forma de pagamento;
5. Caso forma de pagamento seja
DINH: <extends PAGAR EM DINHEIRO>
CART�O: <extends PAGAR no CART�O>
Fim-Caso;
6. Sistema registra devolu��o;
7. Sistema emite recibo de quita��o do pagamento.
Cen�rios alternativos
1.a. M�dia n�o localizada:
- Sistema informa �M�dia n�o registrada no sistema ou n�o alugada� e
retorna ao passo 1 do cen�rio principal.
2.a. Loca��o n�o localizada (inconsist�ncia de dados):
- Sistema informa �Loca��o n�o registrada para a m�dia no sistema� e
encerra o caso de uso.
2.b. Se data corrente > data prevista de devolu��o, ent�o calcular multa
<<Extends CALCULAR MULTA POR ATRASO>>
Destacamos em negrito, para melhor visualiza��o, as chamadas aos casos de
extends. No cen�rio principal, opcionalmente usamos �pagar em dinheiro� ou
�pagar em cart�o�, e nos cen�rios alternativos, condicionalmente, usamos
�calcular multa por atraso�.
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.
� 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
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:
Seguem algumas dicas sobre especifica��es de casos de uso:
1. N�o use detalhes de implementa��o ou de determinada tecnologia em
suas especifica��es.
a. A tecnologia ficar� obsoleta, e seu caso de uso ter� que ser
revisto.
b. Exemplos: imagine um sistema de autoatendimento banc�rio, em
caixas eletr�nicos. Ao descrever a a��o do usu�rio �informar seus
dados de acesso�, evite descrever como, por exemplo: �Usu�rio
insere o seu cart�o�. Em vez disso, use: �Usu�rio informa dados da
ag�ncia, conta e senha de acesso�.
c. Amanh� a tecnologia muda e a identifica��o passa a ser, por
exemplo, pela leitura da digital, e o caso de uso precisar� ser
escrito novamente. Fazendo como o proposto, estar� adequado a
qualquer tecnologia.
2. Procure n�o associar casos de uso a telas de sistemas.
a. Muitos autores sugerem que listemos esbo�os de telas nas
especifica��es de casos de uso. Geralmente os autores s�o
favor�veis e os processos de desenvolvimentos s�o �geis, visando
entregar o c�digo o mais r�pido poss�vel.
b. Procure evitar essa pr�tica, pois no momento em que estamos
especificando os casos de uso, ainda � cedo para pensarmos em
interface, que ser� objeto da fase de projeto do sistema.
c. Resista a essa tenta��o, pois sabemos que os usu�rios adoram
telas.
3. Existe um formato de especifica��o de que muitos gostam, pois fica mais
claro o di�logo que acontece 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. Perguntas que podem ajudar no detalhamento dos cen�rios principal e
alternativos:
a. Quando tudo ocorre na normalidade (com sucesso), qual o
comportamento do sistema? � Esse ser� o passo a passo do cen�rio
principal;
b. Algo pode acontecer de forma diferenciada nesse passo? � Indica
um cen�rio alternativo (relacionado a esse passo);
c. O que pode dar errado nesse passo? � Da mesma forma que a
pergunta anterior, esta conduz � identifica��o de um cen�rio
alternativo.
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.
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:
Gabarito
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:
Formato completo -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 resumido-Resumo de um par�grafo, geralmente contendo o cen�rio principal do

caso de uso e o cen�rio de sucesso.
Formato informal-M�ltiplos par�grafos que cobrem v�rios cen�rios de uso.
Atividade
Considere a seguinte descri��o do que ocorre na realiza��o do caso de uso
�Emprestrar 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 04
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 analise
1-Inicialmente, em sua primeira vers�o, na fase de an�lise, o diagrama apresenta as
classes do neg�cio (tamb�m chamada 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-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:
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 x 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:
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�oes
O conceito de m�todo remete ao conjunto de operac�es (comportamento) que a classe
fornece.
A operac�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.
Exemplos de classes com seus 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.
Para saber mais sobre a associa��o entre classes, clique no bot�o ao lado:
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.
ASSOCIA��O
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, 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.
Autoassocia��o
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}, demotando 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, confome 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:
Multiplicidade Significado
1 Exatamente um
1..* Um ou v�rios (muitos)
0..* Nenhum (zero) ou v�rios (muitos)
* Muitos. A leitura � nenhum (zero) ou v�rios (muitos)
0..1 Nenhum (zero) ou um
m..n Faixa de valores. Exemplo: 1 a 3 , 4 a 7 ou 6 a 11
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 sairmos 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.
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:
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 (-);
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;
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 associac�o;
? Generalizac�o/ especializac�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 asssociac�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 ilusta 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/ especializac�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 especificidaes,
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 principio 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 composic�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 integrande 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�, concluimos 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 agregac�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

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 relacionamento entre 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�.

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.
Observa��o:
Ap�s realizar a atividade proposta, voc� dever� visualizar o gabarito e compar�-lo

com a sua resposta.
Gabarito atividade
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 05
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:
O diagrama 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.
X
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

entre os objetos que est�o relacionados.
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.
X
Diagrama de Comunica��o
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:
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.
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).
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:
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.
Exemplo de diagrama de sequ�ncia

A seguir, veja um exemplo de diagrama de sequ�ncia, a partir do qual
explicaremos os elementos b�sicos e a correla��o com casos de uso e classes.
1. O ator � o mesmo do caso de uso: Correntista, com a mesma
representa��o do boneco (stickman);
2. Interface � o formul�rio com o qual o ator interage com o sistema;
3. Conta Corrente e Movimento Conta s�o classes do modelo
conceitual de classes, envolvidas no cen�rio de uso em quest�o;
4. Ag�ncia e Conta e Senha s�o dados informados pelo ator
correntista, sobre sua conta corrente;
5. Validar AgConta (Ag�ncia e Conta) e Validar Senha () s�o m�todos
da classe Conta Corrente, que s�o acionados por uma mensagem
(s�ncrona) enviada � classe;
6. ObterSaldoConta (Ag�ncia, Conta, Data) � um m�todo da classe
Movimento Conta, que � chamado por uma mensagem s�ncrona
enviada � classe;
7. ObterSaldoConta, por sua vez, chama o m�todo Calcular Saldo
(Data), atrav�s de uma autochamada, ou seja, o m�todo que est�
sendo chamado pertence � pr�pria classe. Isto tamb�m � chamado
de autodelega��o;
8. A linha pontilhada vertical que aparece em cada elemento � Ator,
Interface e Classes, chama-se Linha da Vida;
9. As caixas que aparecem ao longo da linha da vida, abaixo de cada
elemento (ator, interface e classes), chama-se caixa de ativa��o e
mostra quando cada elemento est� ativo na intera��o;
10. Observe que antes da chamada os m�todos Validar Senha tem
[Ag�ncia e Contas Validas]. Esta � uma condi��o de guarda. Entre
colchetes, as condi��es s�o apresentadas. O m�todo ValidarSenha
somente ser� executado se a condi��o for satisfeita;
11. Da mesma forma, antes da chamada ao m�todo ObterSaldoConta
(Ag�ncia, Conta e Data), temos a condi��o de guarda [Ag�ncia,
Conta e Senha v�lidos], indicando que o referido m�todo apenas
ser� executado se a condi��o for verdadeira.
Para chegamos a esse diagrama de sequ�ncia, t�nhamos o seguinte em m�os:
- Cabe destacar que o diagrama de sequ�ncia apresentado refere-se
ao Cen�rio Principal do caso de uso Emitir Saldo Conta, abaixo
descrito e cujo trecho de diagrama segue.
1) Especifica��o de casos de uso
Caso de uso: Emitir Saldo Conta
1. Correntista informa ag�ncia e conta corrente;
2. Sistema valida ag�ncia e conta;
3. Correntista informa senha de acesso;
4. Sistema valida senha de acesso;
5. Sistema calcula saldo do dia corrente, com base nas movimenta��es da
conta e saldo anterior;
6. Sistema apresenta saldo ao correntista.
2) Trecho de diagrama de caso de uso relacionado � intera��o
3) Diagrama de classes � Esta figura exibe o trecho de diagrama de classe
relacionado a esse diagrama de sequ�ncia:
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.
Exemplo dos principais elementos do diagrama de sequ�ncia

A figura a seguir, extra�da do livro UML essencial: um breve guia para a
linguagem-padr�o de modelagem de objetos, 3a
edi��o, de Martin Fowler, mostra
os elementos principais de um diagrama de sequ�ncia. Todos os elementos que
citamos no exemplo dado acima est�o bem elucidados na imagem.
1) Participantes - Ator e classes que participam da intera��o;
2) Linha da vida de cada participante (classes: Um Pedido, Uma Linha de
Pedido, Um Produto e Um Cliente);
3) Caixa de ativa��o, indicando o quanto o participante est� ativo na
intera��o;
4) Mensagem � Chamado de um m�todo da classe, aonde chega a mensagem;
5) Retorno � Mensagem de retorno da mensagem (chamada ao m�todo da
classe);
6) Autochamada � Chamada de um m�todo da pr�pria classe. No exemplo
anterior, corresponde ao m�todo calcular Pre�oBase, da classe um
Pedido.
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].
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.
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.
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.
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.
EXEMPLO
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.
Responsabilidade das Classes

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 o 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:
Atividade
Para realizar esta atividade, considere o diagrama de casos de uso, a especifica��o

(descri��o textual) do caso de Uso Registrar Loca��o e o diagrama de classes.
Com base nessa documenta��o apresentada, elabore o diagrama de sequ�ncia para o
cen�rio principal do caso de uso Registrar Loca��o.
Diagrama de casos de uso, a especifica��o (descri��o textual) do

caso de Uso Registrar Loca��o e o diagrama de classes
Registrar Loca��o
1. Atendente informa identifica��o do cliente;
2. Sistema localiza dados do cliente informado ;
3. Atendente informa dados da m�dia a ser locada;
4. Sistema localiza dados da m�dia informada;
5. Sistema informa data de devolu��o da loca��o;
6. Atendente confirma loca��o;
7. Sistema registra loca��o;
8. Sistema emite boleto de loca��o para o cliente.
2.a. Cliente n�o localizado.
- Sistema informa �Cliente n�o registrado no sistema� e retorna ao
4.a. M�dia n�o localizada.
- Sistema informa �M�dia N�O registrada no sistema� e retorna ao
Gabarito atividade
Segue uma das poss�veis respostas, incluindo as altera��es propostas para o
diagrama de classes.
5.2. Caso de Uso: Registrar Loca��o
Observe a especifica��o do caso de uso e veja que a a��o 8 chama-se �Sistema
Emite Boleto de Loca��o� (destacado em amarelo). Isto significa que � preciso que
exista um m�todo na classe LOCA��O para formatar os dados j� transacionados no
caso de uso e emitir o boleto desejado.
Segue uma das solu��es do diagrama de sequ�ncia solicitado no enunciado:
Segue a solu��o usando classes de interface, controle e entidade:
As mensagens que chegam �s classes s�o m�todos das mesmas e devem ser
inseridos no diagrama de classes.
1) M�todo Pesquisar (id Cliente) na classe Cliente.
2) M�todo Pesquisar (Id Midia) na classe M�dias.
3) M�todo Registrar loca��o (Id Cliente, Id Midia e Data Devolu��o) na classe
Loca��o.
4) M�todo Emitir Boleto Loca��o da classe Loca��o.
Segue o diagrama de classes, refinado, com esses m�todos:
Segue o diagrama de classes, contendo as classes de interface (boundary) e
controle (control).
Aula 06
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�o deve 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.
Sistema
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).
Unidade 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.
Consultar pedido do per�odo - Permitir que sejam consultados todos os pedidos de um

per�odo informado pelo usu�rio.
Cadastrar cliente - Registrar os dados cadastrais dos clientes que realizam seus
pedidos.
Registrar pedido - Registrar os pedidos de faixa feitos pelos clientes.
Registrar entrega do pedido - Sinaliza que o pedido foi entregue ao cliente,
devendo haver mudan�a do estado do pedido, nesse momento.
Registrar inicio da produ��o - A f�brica deve sinalizar a data em que a produ��o
foi iniciada e confirmada a data de entrega, devendo haver mudan�a de estado do
pedido, nesse momento.
Registrar fim da produ��o do pedido - Sinaliza que a produ��o da faixa chegou ao
fim, devendo haver mudan�a do estado do pedido, nesse momento.
Consultar cliente sem pedido - Relaciona todo cliente que n�o faz pedido h� mais de
seis meses (com base na data corrente).
Confirmar recebimento do sinal - Confirmar que o cliente pagou o sinal, sendo a
base para c�lculo da data de entrega do produto. Deve haver mudan�a de estado do
pedido nesse momento.
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.
1. Usu�rio informa ID do pedido;
2. Sistema localiza pedido com ID do pedido;
3. Sistema exibe dados do pedido.
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.
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.
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

1. Usu�rio informa ID do pedido;
2. Sistema localiza pedido com ID

do pedido;
3. 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.
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:
As classes envolvidas s�o:
Cliente e Pedido.
O relacionamento entre as classes � associa��o.
O papel do relacionamento � �Cliente Faz Pedido�.
A cardinalidade do relacionamento:
1 Cliente faz * Pedidos

1 Pedido � de 1 Cliente
Dessa forma, teremos:

1 do lado Cliente e 0..* do lado Pedido.
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
Caso de uso: Consultar Clientes em Pedido - Cen�rio: Principal

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.
Atividades
Agora, vamos praticar com duas atividades.
1 - Desenvolva o diagrama de sequ�ncia do cen�rio principal do caso de uso

CADASTRAR CLIENTE, cuja especifica��o foi desenvolvida durante esta aula. Caso haja
altera��o no diagrama de classes, apresente o novo diagrama.
1
Gabarito:
Veja abaixo uma das solu��es do diagrama. Observe que os m�todos usados j� existiam
no
diagrama de classes e n�o foi preciso modific�-lo, com a inclus�o de novos m�todos.
2 - Desenvolva o diagrama de sequ�ncia do cen�rio principal do caso de uso

REGISTRAR ENTREGA DO PRODUTO, cuja especifica��o foi desenvolvida durante esta
aula. Caso haja altera��o no diagrama de classes, apresente o novo diagrama.
1
Gabarito:
Veja abaixo uma das solu��es do diagrama. Observe que aqui dois m�todos (setas que
chegam na classe PEDIDO) s�o novos, ou seja, ainda n�o est�o no diagrama de classes
e
devem figurar. S�o eles:
1. ProcPedido (Id Pedido): localiza um pedido pelo seu ID;
2. Alterar Data entrega (Data Real de entrega): alterar a data real de entrega do
pedido.
O m�todo (autochamada) Alterar Status Pedido (�E�) j� existia, sendo �E�, a
sinaliza��o do
status ENTREGUE.
O diagrama de classes, ap�s o diagrama de sequ�ncia acima, ficaria, assim, com a
inclus�o
dos dois novos m�todos.
2
Aula 07
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 estado de 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.
N�o e preciso desenvolver um DTE para cada classe do sistema, e sim para aquelas
que possuem um n�mero conhecido e finito de estados (maior que um estado).
A UML possui um conjunto rico de elementos para descrever o DTE, veja:
- B�sicos: estado e transi��es;
. Conceitos relacionados: evento, a��o e atividade;
- Menos utilizados, mas �teis em momentos especificos: transi��es internas,
estados aninhados e estados concorrentes.
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 que
nada � 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 leitura � a seguinte:
Ao realizar um �saque de R$" e o saldo ficar menor que zero, a conta transita para
o estado Bloqueada,
em que fica �aguardando um dep�sito�, que torne o saldo zerado ou positivo (maior
ou igual a zero). Um
evento pode denotar mais de uma transi��o e, neste caso, as sentinelas devem
expressar condi��es que
sejam mutuamente exclusivas, por motivos �bvios. O estado final indica que o ciclo
do objeto est�
encerrado e a sua m�quina de estados est� completa.
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.
Exemplo de a��es de Entrada e Sa�da, Transi��es internas e Atividades
Veja, agora, um exemplo de como declarar no estado a��es de entrada (Entry), de

sa�da (Exit) e atividaes (do):
Acrescentando uma transi��o interna, temos:

Descri��o:
. O evento, que demanda a a��o;
. A condi��o de guarda para a execu��o da atividade;
- A atividade interna que ser� realizada.
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.
Observe a seguinte regra para a defini��o dos superestados:

Todos os estados dentro de um estado composto herdam suas transi��es.
Um estado composto pode ser sequencial ou concorrente. Segue um exemplo de

superestado sequencial, ilustrado em duas imagens:
Passo a Passo para a Constru��o do DTE
O DTE (diagrama de transi��o de estado) deve ser elaborado para classes cujos
objetos tenham dois ou mais estados. Veja o passo a passo para a constru��o do DTE:
Identifique todos os estados

relevantes para a classe.
Analise os possiveis eventos que

ocasionam mudan�a de estado.
Para cada evento, identifique
qual transi��o ele ocasiona.
Para cada esta?�o':
. Identifique as transi��es
possiveis quando um
evento ocorre;
. Identifique os eventos
internos e a��es
correspondentes.
Para cada vari��o verifique se

h� fatores que influenciam no
seu disparo (de�ni��o de
condi��es de guarda e a��es).
Para cada cond��o de guarda e

para cada a��o identi�que os
atributos e liga��es que est�o
envolvidos.
Defina o estado inicial e os

eventuais estados finais.
Desenhe o diagrama.
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.
Atividade
1 - O diagrama de estados:
Mostra cada estado e as respectivas transi��es de estado de um objeto.
2 - Quando devemos modelar o diagrama de estado de uma classe?

Para toda classe cujo objeto tenha pelo menos dois estados.
3 - (Eletrobr�s) Observe o diagrama de transi��o de estados. Suponha que, num dado

momento, o sistema se encontre no Estado0 e que ocorra a seguinte sequ�ncia de
eventos: a b c b b b c a. O estado do sistema, ap�s a ocorr�ncia desses
eventos, ser�:
Estado4
4 - No que se refere �s caracter�sticas avan�adas do diagrama de transi��o de

estados, assinale a �nica op��o ERRADA:
Uma a��o de saida de um estado � executada durante todo o tempo em que o objeto
encontra-se naquele objeto.
5 - Como se chama a seta que indica no diagrama de transi��o de estados a mudan�a

de um estado X para um estado Y?
Transi��o
6 � Observe a �ltima vers�o do DTE do objeto Quarto do sistema Hotel e, a partir

dela, fa�a as altera��es necess�rias para que ele represente:
A exclus�o do quarto, que antes s� era poss�vel quando no estado Dispon�vel, agora
pode acontecer em todos os estados.
Gabarito quest�o 6
Como pode haver transi��o de todo estado para o Final, cria-se um superestado,
de novo Ativo, representado pelo diagrama de nome Estados.
A transi��o ap�s a ocorr�ncia do evento �Excluir Quarto� acontece do superestado
para o estado final.
Abaixo a solu��o acima descrita, representada pelo diagrama de estados:
Aula 08
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�.
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:
Atividade
Ret�ngulo com bordas arredondadas. Veja um exemplo:
Transi��o
Setas cont�nuas que representam o fluxo de trabalho entre atividades. Veja um
Decis�es
Losango, usado para controlar os desvios (caminhos) do fluxo de controle.
Condi��es de guarda
S�o condi��es associadas a transi��es entre uma atividade e outra, indicando que a
atividade que sucede somente ser� executada se a condi��o de guarda for verdadeira.
Ponto de Merge
Desvios: a decis�o, que divide em dois ou mais caminhos (fluxos de atividades). Tem
um fluxo de entrada e N fluxos de sa�da;
Intercala��es: local onde dois ou mais caminhos (fluxos de atividades) se juntam e
continuam como apenas um fluxo. � usado o mesmo losango da decis�o.
Os caminhos que se juntam foram separados anteriormente pelo elemento desvio. Tem N
fluxos de entrada e um fluxo de sa�da.
Para visualizar um exemplo de ponto de merge, clique no bot�o abaixo:
Exemplo de ponto de merge

Observe o diagrama a seguir:
Conforme trecho de diagrama 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.
Processamento em paralelo
Bifurca��o e uni�o (ou jun��o): barras horizontais que sincronizam atividades que
v�o ocorrer em paralelo. No caso, as atividades que ocorrem em paralelo s�o
processar pedido e faturar pedido. Observe:
Para visualizar um exemplo de processamento em paralelo, clique no bot�o a seguir:
Exemplo de processamento em paralelo

A imagem a seguir ilustra o diagrama de atividades, representando a l�gica do
procedimento de realiza��o de pedido de produtos a um fornecedor.
A leitura deste diagrama pode ser descrita como:
In�cio
1. Atividade para controlar a entrada de dados do pedido
2. Atividade para validar o pedido, segundo as regras
3. Decis�o: pedido v�lido?
4. Se pedido OK ? Atividade processar pedido
Sen�o ? Atividade informar dados pedido
5. Atividade enviar pedido ao fornecedor
Fim
Por esse exemplo, j� podemos observar os principais elementos do diagrama de
atividades, que s�o apresentados a seguir:
Elemento Descri��o
Marca o in�cio do diagrama
Apenas um in�cio por diagrama
Representa a atividade, que � um conjunto de a��es
Marca o fim do diagrama
Pode ter mais de um estado final
Pode n�o ter estado final, para procedimentos c�clicos
Decis�o
Losango que controla os desvios do fluxo de controle
[Pedido OK]
[Pedido incompleto]
S�o sentinelas, associadas � decis�o. S�o condi��es
booleanas colocadas entre colchetes.
Elas mostram o fluxo que deve ser seguido conforme a
decis�o.
Transi��es: setas cont�nuas, representando o fluxo de
trabalho, de uma atividade para outra.
Repare, pelo exemplo apresentado, que o diagrama de atividades determina as
regras de sequ�ncia que se deve seguir.
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 em paralelo, 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:
Exemplos de paralelismo no diagrama de atividades

A seguir, um trecho gen�rico de diagrama de atividades, exemplificando as barras
de sincroniza��o e as atividades paralelas:
A primeira barra horizontal, logo ap�s o in�cio, chama-se de bifurca��o, a partir
da
qual os fluxos de atividades que v�o ocorrer em paralelo, que no caso do exemplo,
s�o tr�s:
? O fluxo que inicia com a atividade 1;
? O fluxo que inicia com a atividade 2;
? O fluxo que inicia com a atividade 3.
Os tr�s fluxos ocorrem em paralelo, e cada um tem um tempo diferente e
independente de execu��o. Por isso h� a necessidade de sincronizar os tr�s fluxos
ao final de cada um, da� a exist�ncia do elemento jun��o (joint), atrav�s da
segunda barra horizontal.
Ou seja, fluxos de atividades que precisam ocorrer em paralelo ser�o sincronizados
duas vezes: no in�cio pela barra de sincroniza��o chamada de bifurca��o, e ao final
pela barra de jun��o.
? A barra de bifurca��o recebe uma transi��o de entrada e gera N
fluxos de controle paralelo, em que todos os N fluxos iniciam no
mesmo momento;
? A barra de jun��o recebe N fluxos de controle e gera uma transi��o de
sa�da, que somente ser� executado quando todos os fluxos de entrada
chegarem na jun��o.
Os fluxos de controle ocorrem em paralelo entre uma bifurca��o e uma jun��o.
Desta forma, podemos afirmar, seguindo o exemplo do trecho de diagrama de
atividade anterior:
1. Os tr�s fluxos iniciam a execu��o ao mesmo tempo, assim que
sincronizados, pela barra de bifurca��o;
2. Os tr�s fluxos t�m tempos de execu��o diferentes e independentes;
assim sendo, n�o duram o mesmo tempo e chegam � barra de jun��o
em momentos diferentes.
A barra de jun��o tamb�m pode ser chamada de barra de uni�o.
No exemplo representado pela imagem a seguir, podemos observar o seguinte fluxo
de atividades:
In�cio
1. A atividade 1 � executada
3. H� uma decis�o (n�o explicitada, o que n�o � bom)
4. Se a decis�o implicar em n�o, retorna o fluxo para a atividade 2
5. Se a decis�o implicar em sim, segue o fluxo conforme segue
6. As atividades 3 e 4 s�o iniciadas e acontecer�o em paralelo, atrav�s da
barra de bifurca��o
7. As atividades 3 e 4, ap�s encerrarem (cada uma a seu tempo), s�o
sincronizadas, atrav�s da barra de jun��o
Fim
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.).
Raias de nata��o
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:
Documentar sistemas n�o � uma pr�tica usual no Brasil, em fun��o de v�rios motivos
que n�o cabem discutir aqui.
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.
As aplica��es mais usuais para diagramas de atividades s�o:
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
Exemplos de subatividade do diagrama de atividades

Segue um exemplo de diagrama de atividade cuja atividade de nome �entregar
pedido� ser� descrita em outro diagrama complementar:
A seguir, o detalhamento da atividade �entregar pedido�. Com a modelagem da
atividade com ancinho, h� um desvio para executar o que est� especificado no
diagrama a seguir, desde o in�cio at� o fim.
Ao final da execu��o do diagrama �entregar pedido�, o fluxo volta ao diagrama
anterior para o ponto imediatamente seguinte � atividade �entregar pedido�, que �
a barra de jun��o.
Observe que o nome do diagrama (canto superior esquerdo, ap�s a palavra ACT) � o
mesmo que o nome da atividade que tem o ancinho.
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
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 (*)
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
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.
Atividade
Considere o diagrama de atividades, referente ao processo de acionamento do seguro

em caso de sinistro e, em seguida, responda �s seguintes quest�es:
Gabarito atividade
1 - Em que situa��es o processo chega a seu final?
a) Quando a perda � total e o cliente recebe o pr�mio do seguro;
b) ap�s o conserto do autom�vel ficar pronto e o cliente pagar a franquia para o
uso dos servi�os do seguro.
2 - O autom�vel sempre ser� consertado?
N�o, somente ser� consertado se n�o for perda total.
3 - Quais atividades s�o executadas em paralelo? Essas atividades t�m a mesma
dura��o?
Cobrar franquia/ pagar franquia e consertar autom�vel. N�o, elas n�o t�m a
mesma dura��o e por isso mesmo precisam ser sincronizadas ao final de todas.
4 - Em que situa��o o cliente precisa pagar franquia?
Quando for perda parcial e o carro for consertado.
5 - Fa�a o diagrama de atividades que retrate o seguinte fato: o carro somente
ser� consertado se a franquia for paga.
Segue uma poss�vel solu��o para essa modifica��o:
Aula 09
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:
Um componente representa uma parte modular de um sistema que encapsula seu conte�do
e cuja
manifesta��o � substitu�ve/ dentro de um ambiente.
Um componente detine seu comportamento em termos de interfaces fornecidas e

requeridas. Como tal,
serve como um tipo, cuja conformidade � definida por essas interfaces fornecidas e
requeridas.
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.
A ideia � construir sistemas, como um conjunto de componentes, que s�o

partes substitu�veis, e que esses componentes possam ser reutilizados em
muitos sistemas.
Os componentes devem ter interfaces que propiciem grande flexibilidade e

adapta��o em muitos sistemas. Portanto, os componentes podem ser criados
de outros componentes.
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
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:
Exemplo de diagrama de componentes

Segue um exemplo de diagrama de componentes necess�rio ao servi�o de uso de
um caixa eletr�nico (ag�ncias banc�rias e banco 24h):
1. Gerenciador de Caixa Eletr�nico: gerencia o uso e aguarda pelos
eventos dos correntistas, ao interagir com o caixa eletr�nico.
2. Criptografia: criptografa os dados, de forma que trafeguem em
seguran�a at� os servidores da empresa.
3. Controlador Caixa Eletr�nico: age como interface entre o caixa
eletr�nico e as camadas da aplica��o, residentes nos servidores, que
dar�o a reposta a cada solicita��o do cliente.
4. Firewall: filtra os acessos, verificando se a chamada ao gerenciador
de contas � confi�vel e de acordo com os par�metros de comunica��o
da empresa.
5. Gerenciador de Contas: gerencia os acessos aos dados da conta e sua
movimenta��o, solicitando a desencripta��o dos dados e identificando
o que o cliente solicitou no caixa eletr�nico.
6. Descriptografia: respons�vel por desencriptar os dados, encriptados
na origem, deixando-os no estado original.
7. SGBD: faz o acesso � base de dados, conforme a solicita��o do
cliente.
Repare que a solu��o dessa imagem permite flexibilidade em futuras mudan�as.
? Se alterarmos a t�cnica de criptografia ou mesmo desejarmos ampliar
as possiblidades com novas t�cnicas, basta substituir ou adicionar
novos componentes de criptografia e descriptografia.
? Se quisermos trocar o software de firewall, basta substituir o
respectivo componente.
? Se mudarmos de banco de dados, basta substituir o componente
respons�vel pelo acesso aos dados.
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

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).
Atividade
Um diagrama de implanta��o define os aspectos f�sicos do sistema, em que cada n�
representa um dispositivo f�sico com mem�ria e/ou capacidade de processamento.
J� o diagrama de componentes exibe quais m�dulos de software

(arquivos .dll, .exe, .com, .bat, .htm e outros execut�veis) s�o necess�rios para
executar a aplica��o.
Com base no contexto apresentado, responda:
� poss�vel integrar esses dois diagramas, mostrando, para cada n�, quais seriam os
componentes que nele executariam? Caso a resposta seja sim, explique qual a
vantagem em integrarmos os dois diagramas dessa forma.
Sim, � poss�vel.
Seria �til para conhecermos as demandas de processamento do software que rodaria em

cada n� e assim poder definir a capacidade de processamento, mem�ria e disco de
cada um.
Aula 10
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.
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.
Sistema de controle de atividades

O sistema de controle de atividades encomendado pelo seu Pereira compreende,
basicamente:
? Controle e acompanhamento dos pedidos;
? Cadastramento de seus clientes.
O cliente, geralmente indicado por um amigo satisfeito com os servi�os da gr�fica,
faz seu pedido; Seu Pereira (diretor) ou a atendente fazem o atendimento e
registram 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 na faixa, cor da faixa (amarela, preta ou branca), cor do
texto (branco, preto, azul ou vermelho), previs�o de entrega, valor do
servi�o e valor do sinal (50% do valor total do servi�o).
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)
O prazo de entrega deve ser calculado levando-se em considera��o a produ��o
di�ria de faixas, que n�o deve 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.
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).
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 saldo deve ser pago
em contraentrega, 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.
O sistema deve prover uma consulta (dispon�vel apenas � diretoria), de cada pedido
feito no per�odo, informando: data do pedido, data de entrega, valor do servi�o e
do sinal, sinal pago (sim/n�o), servi�o finalizado (sim/n�o), servi�o pago
(sim/n�o)
e status do pedido.
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.
O sistema deve emitir um informe a todo cliente que n�o faz pedido h� mais de 6
meses (com base na data corrente).
Recentemente foi feita uma modifica��o no sistema de pedidos, e agora num
mesmo pedido pode ser encomendada mais de uma faixa, at� cinco no m�ximo
(mas essa regra pode alterar a qualquer momento).
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:
1-Diagrama de estados, identificando as classes que t�m necessidade desse diagrama;

2-Deriva��o do diagrama conceitual de classes, com base no diagrama conceitual de
classes;
3-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;
4-Constru��o do diagrama de componentes;
5-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 estados ao 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.
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.
O uso oportuno do diagrama de atividades � para casos de uso cuja especifica��o �

complexa e/ou extensa. Tais propriedades n�o se aplicam em nossos casos de uso,
devido � simplicidade do estudo de caso. Nossa inten��o n�o � explorar as
propriedades superlativas da UML e seus diagramas, e sim mostrar como aplic�-los.
Diagrama de Atividades do Caso de Uso Registrar Pedido

Segue a especifica��o do caso de uso para compara��o com o diagrama de
atividade:
Caso de Uso: Registrar Pedido
Pr�-condi��o: --
P�s-condi��o: pedido registrado e cliente registrado, caso seja um novo cliente
Cen�rio Principal
3. Sistema exibe nome, e-mail e telefones do cliente
4. Para cada faixa do pedido, fa�a:
a. Usu�rio informa dados da faixa (1)
b. Sistema calcula valor da faixa (2)
c. Sistema acumula valor do pedido
5. Sistema apresenta valor total do pedido
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
Coment�rios do diagrama de atividade x especifica��o de caso de uso:
? Se voc� ler o diagrama de atividade, partindo do in�cio, vai perceber a
rela��o entre as atividades do diagrama e cada passo do caso de uso.
? Perceba que, ap�s a atividade LOCALIZAR CLIENTE, existe uma decis�o:
? Se o cliente estiver cadastrado, segue o fluxo estabelecido no cen�rio
principal do caso de uso.
? Se o cliente n�o estiver cadastrado, apresentamos o que � tratado no
cen�rio alternativo (um sen�o ao cen�rio principal) � Extends
Cadastrar Cliente, que est� representado pela atividade INCLUIR
CLIENTE, destacado na cor azul, para diferenci�-la das demais, uma
vez que o desenho do �ancinho� demonstra que � uma subatividade,
ou seja, composta de outras atividades, que mostraremos na
sequ�ncia.
? Perceba ainda que, ap�s a atividade TOTALIZAR PEDIDO, temos uma decis�o,
que na verdade simboliza a repeti��o representada na especifica��o do caso
de uso.
? Se existirem mais faixas para o pedido, ent�o, voltamos para a
atividade USU�RIO INFORMA DADOS FAIXA, para processar nova faixa
do pedido.
? Caso contr�rio, a repeti��o � encerrada e vamos � atividade EXIBIR
TOTAL DO PEDIDO.
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:
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.
Transcri��o da especifica��o do caso de uso Cadastrar Cliente

Caso de Uso: Cadastrar Cliente
Pr�-condi��o: cliente n�o cadastrado
P�s-condi��o: cliente com dados devidamente cadastrados
Cen�rio Principal
3. Usu�rio informa dados do cliente (1)
4. Sistema registra dados do cliente
2.a. Cliente j� cadastrado
1. Sistema emite mensagem �Cliente j� est� cadastrado�
2. Sistema retorna ao passo 1 do cen�rio principal
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).
Transcri��o da especifica��o do caso de uso Confirmar Recebimento

de Sinal
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. Usu�rio informa Id do pedido
2. Sistema localiza pedido com Id do pedido
3. Sistema exibe dados do pedido
4. Usu�rio informa data e valor de pagamento do sinal
5. Sistema aponta PRONTO PARA PRODUC�O para status do pedido
6. Sistema calcula data de entrega do pedido
7. Sistema altera dados do pedido
2.a. Pedido n�o localizado
1. Sistema emite mensagem �Inconsist�ncia de dados, pedido n�o localizado�
4.a. Valor do sinal inferior a 50% do pedido
1. Sistema emite mensagem �O valor do sinal deve ser equivalente a 50% do
valor do
pedido�
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:
1-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.
2-O banco de dados usado ser� o SQL Server, que a empresa j� possui.
3-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).
4-O sistema deve ter um design responsivo (operar em qualquer plataforma de

equipamentos), de forma que funcione em computadores, notebooks, tablets e
smartphones.
5-O sistema ser� desenvolvido para a plataforma Windows, usando o gerenciador de

internet IIS do Windows.
6-A linguagem ser� JAVA.
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.
Atividade
Sabemos que determinadas solicita��es de altera��o dos requisitos do sistema afetam

sobremaneira o desenvolvimento e acarretam altera��es nas solu��es j� apresentadas,
atrav�s dos diversos diagramas da UML usados.
Imagine a seguinte mudan�a: o usu�rio, antes de usar o sistema, deve se logar e

registrar cada acesso ao sistema (login).
Com base nessas informa��es, modele o diagrama de casos de uso e o diagrama

conceitual de classes para conter essas modifica��es.
Gabarito
? Agora o usu�rio deve registrar seu login no sistema (novo caso de uso),
autenticando-se com login e senha.
? Caso o cliente n�o seja cadastrado, a partir do login, o usu�rio poder�
cadastrar-se.
? O cliente pode agora registrar seu pedido, da� a rela��o do cliente ao caso
de uso Registrar Pedido.
? No diagrama de classes, surge a classe login, como as datas de login e
m�todos que ser�o descobertos ao desenhar os diagramas de sequ�ncia
relacionados aos casos de uso que sofreram altera��o.
? Na classe Cliente, adicionamos os atributos necess�rios ao login e um novo
m�todo que servir� para os usu�rios se autenticarem e o m�todo Autenticar
o Usu�rio.
Essas s�o as altera��es m�nimas para a mudan�a necess�ria. Outras solu��es podem
existir desde que levem a solu��es satisfat�rias.

Desenvolvimento de sistemas - Aula 01

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de sistemas - Aula 01

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 01

Tomemos como exemplo a cria��o de um sistema que gerencie as atividades de um

No in�cio do processo, � preciso conversar com os profissionais envolvidos no

Para representar a realidade e entender o que se passa no contexto do sistema a ser

No contexto de desenvolvimento de sistemas, o que s�o modelos?

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,

Na modelagem sob o enfoque da orienta��o a objetos (OO), a tarefa principal passa a

OBJETO = DADOS + FUN��ES

Na medida em que s�o identificados todos os objetos pertinentes a um sistema, j�

Considerando o contexto de um sistema banc�rio (ilustrado pela imagem a seguir),

Ao identificar os objetos, s�o identificados, tamb�m, os dados (atributos) e as

Orienta��o a Objeto (OO)

O Modelo OO � formado por alguns elementos b�sicos:

� Atributos: Nome, Endere�o, Telefone, Idade e Altura.

Diferen�a entre o conceito de classes e objetos

Os pilares do paradigma Orientado a Objetos

A orienta��o a objetos tem como alicerce alguns princ�pios fundamentais. Juntos,

Para conhecer um pouco mais sobre os pilares da Orienta��o a Objetos, clique no

Os pilares do paradigma Orientado a Objetos

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

Proporciona modularidade trazendo os seguintes benef�cios:

As hierarquias de classes (heran�a) s�o componentes port�veis entre aplica��es,

Para conhecer um pouco mais sobre as conclus�es do Paradigma Orientado a Objetos,

Conclus�es do paradigma Orientado a objetos

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

Antes de adentramos no universo da an�lise e projeto, sob o enfoque do paradigma

An�lise de sistemas significa uma investiga��o dos problemas e dos requisitos de um

Atividade de an�lise e projeto

An�lise de requisitos (investiga��o dos requisitos);

No contexto espec�fico da orienta��o a objetos, an�lise implica em identificar e

Um sistema desenvolvido sob o paradigma da orienta��o a objetos representa os

A UML como uma linguagem padr�o

A UML (Unified Modeling Language) � uma linguagem padr�o para constru��o de

Clique no bot�o ao lado para visualizar um breve hist�rico da UML:

Um Breve Hist�rico da UML

Os diagramas da atual vers�o da UML

Para conhecer cada diagrama detalhadamente, clique no bot�o ao lado:

Diagramas da atual vers�o da UML

1-Uml como esbo�o

2-Uml como projeto

3-Uml como linguagem de programa�ao

Processos Iterativos de desenvolvimento e a UML

Um processo de desenvolvimento de software descreve uma abordagem para organizar as

Os processos mais populares hoje s�o os iterativos, como:

O PU (Processo Unificado), em particular o RUP (Processo Unificado da Rational);

Mas o que s�o os processos iterativos?

Processos Iterativos de desenvolvimento e a UML

A UML e os resultados em cada fase

Usar a UML, em um processo de desenvolvimento de sistemas, n�o implica,

Uma ferramenta case � um programa que auxilia aos membros da equipe de

Proposta de fluxo de trabalho usando a UML

Para isso, primeiramente leia o texto �Necessidade de usu�rio�.

Liberar pagamento, gerir notas fiscais e controlar estoque.

O software precisa ter as funcionalidades adequadas para satisfazer as necessidades

A UML (linguagem unificada de modelagem) disponibiliza para esse fim o diagrama de

As atividades de levantar e identificar os requisitos s�o fundamentais para todo o

Em contrapartida, se as necessidades identificadas n�o forem as reais, o sistema