UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

PR













ANLISE E PROJETO OO
&
UML 2.0














Cesar Augusto Tacla
Departamento Acadmico de Informtica
ht t p: / / www. dai nf . cef et pr . br / ~t acl a












O uso e reproduo desta apostila
requerem autorizao expressa do
autor.
2
SUMRIO
I INTRODUO ...................................................................................... 5
1 MODELO................................................................................................. 5
2 UML ...................................................................................................... 5
2.1 Breve histrico ...................................................................................... 5
3 ANLISE E PROJETO ORIENTADOS A OBJETOS .................................................. 6
3.1 Anlise e projeto estruturados.................................................................... 6
3.2 Anlise e projeto orientados a objetos .......................................................... 7
4 OBJETO E CLASSE ..................................................................................... 7
4.1 Objeto ................................................................................................ 7
4.2 Classe................................................................................................. 7
5 EXERCCIOS ............................................................................................. 8
II NOO GERAL DE ANLISE E PROJETO OO .................................................. 9
1 VISO GERAL ........................................................................................... 9
2 ANLISE DE REQUISITOS ............................................................................. 9
2.1 Papel dos Casos de Uso na Anlise de Requisitos..............................................10
2.2 Casos de Uso........................................................................................10
3 ANLISE E PROJETO .................................................................................11
3.1 Diagramas de Interao...........................................................................11
3.2 Refinamento do Diagrama de Classes ...........................................................12
3.3 Definir o Comportamento das Classes ..........................................................12
3.4 Implantao ........................................................................................13
3.5 Componentes do Sistema .........................................................................14
4 Modelagem Estrutural e Comportamental ......................................................14
III MODELO DE CASOS DE USO ....................................................................16
1 DEFINIO.............................................................................................16
2 ATORES.................................................................................................16
3 CASOS DE USO ........................................................................................17
3.1 Descrio............................................................................................17
3.2 Fluxo de Eventos ...................................................................................17
3.2.1 Fluxo Bsico...............................................................................18
3.2.2 Subfluxo ...................................................................................19
3.2.3 Pontos de extenso ......................................................................19
3.2.4 Fluxo Alternativo .........................................................................20
3.2.5 Diagrama de atividade...................................................................21
3.2.6 Cenrios ...................................................................................21
3.2.7 Realizaes de Casos de Uso............................................................22
4 RELAES..............................................................................................22
4.1 Associao ..........................................................................................23
4.2 Incluso..............................................................................................24
4.3 Extenso.............................................................................................25
4.4 Generalizao/Especializao ...................................................................26
5 MODELAGEM...........................................................................................29
5.1 Dicas .................................................................................................29
5.2 Passos................................................................................................30
6 EXERCCIOS ............................................................................................31
IV ANLISE DOS CASOS DE USO...................................................................33
1 ANLISE ................................................................................................33
2 PADRO MVC..........................................................................................35
3
3 PADRO OBSERVADOR...............................................................................37
4 CLASSES DE ANLISE.................................................................................37
4.1 Notao UML para Classes ........................................................................37
4.1.1 Atributos...................................................................................37
4.1.2 Mtodos....................................................................................38
4.1.3 Esteretipos ...............................................................................38
4.2 Linhas Mestras......................................................................................40
5 EXEMPLO...............................................................................................40
6 EXERCCIOS ............................................................................................42
V ESTUDO DA INTERAO ENTRE OBJETOS ...................................................43
1 DIAGRAMA DE SEQUNCIA ..........................................................................43
1.1 Tipos de mensagem................................................................................44
1.2 Linha da Vida .......................................................................................45
1.3 Ativao.............................................................................................45
1.4 Alt....................................................................................................45
1.5 Opt ...................................................................................................46
1.6 Loop..................................................................................................46
1.7 Ref ...................................................................................................47
1.8 Criar e destruir .....................................................................................48
1.9 Linhas Mestras......................................................................................48
2 DIAGRAMA DE COMUNICAO......................................................................49
3 EXEMPLO...............................................................................................50
4 PACOTES ...............................................................................................50
5 EXERCCIOS ............................................................................................51
VI RELAES ENTRE CLASSES DE ANLISE......................................................53
1 ASSOCIAO...........................................................................................53
1.1 Associao reflexiva ...............................................................................55
1.2 Classes associativas................................................................................55
1.3 Relaes Ternrias.................................................................................56
1.4 Levantamento das associaes...................................................................57
2 AGREGAO...........................................................................................58
2.1 Notao .............................................................................................58
2.2 Multiplicidade ......................................................................................58
2.3 Tipos de agregaes ...............................................................................59
2.4 Levantamento ......................................................................................60
3 GENERALIZAO......................................................................................60
3.1 Hierarquia de classes..............................................................................61
3.2 Levantamento de generalizaes................................................................62
3.3 Qualidade de uma classificao .................................................................62
3.4 Herana mltipla...................................................................................63
4 EXERCCIOS ............................................................................................63
VII PROJETO DE CASOS DE USO ...................................................................65
1 PROJETO...............................................................................................65
2 CLASSES DE PROJETO ...............................................................................65
3 ESTUDO DA INTERAO ENTRE OBJETOS .......................................................66
3.1 Realizao Converter Celsius-Fahrenheit desktop ............................................66
4 REFINAR O DIAGRAMA DE CLASSES ...............................................................68
4.1 Dependncia........................................................................................68
4.2 Implementao de associaes e agregaes..................................................69
5 SUBSISTEMAS..........................................................................................74
6 COMPORTAMENTOS ASSOCIADOS PERSISTNCIA.............................................75
7 EXERCCIOS ............................................................................................75
VIII DIAGRAMA DE ESTADOS.........................................................................79
4
1 ELEMENTOS BSICOS ................................................................................79
1.1 Notao bsica .....................................................................................79
1.2 Ao nos estados (entry e exit) ..................................................................80
1.3 Atividade nos estados (do) .......................................................................81
1.4 Auto-transio......................................................................................81
1.5 Transio interna ..................................................................................82
1.6 Ordem de execuo de aes e atividades.....................................................82
1.7 Condio de guarda................................................................................83
2 TIPOS DE EVENTOS...................................................................................83
2.1 De chamada.........................................................................................83
2.2 De sinal ..............................................................................................84
2.3 Temporal ............................................................................................85
2.4 De mudana.........................................................................................85
3 ESTADO COMPOSTO..................................................................................86
3.1 Histrico.............................................................................................87
4 EXERCCIOS ............................................................................................88
IX DIAGRAMA DE ATIVIDADES .....................................................................92
1 ELEMENTOS BSICOS ................................................................................92
2 EXERCCIOS ............................................................................................93
X DIAGRAMA DE COMPONENTES E IMPLANTAO ............................................94
1 DIAGRAMA DE COMPONENTES......................................................................94
2 DIAGRAMA DE IMPLANTAO ......................................................................95
XI REFERNCIAS BIBLIOGRFICAS ................................................................97
5
I INTRODUO
Neste captulo so apresentados os conceitos fundamentais do curso: modelo, UML, anlise e projeto
orientado a objetos, objeto e classes de objetos.
1 MODELO
Antes de entrar nos detalhes de UML, preciso ater-se ao conceito de modelo.
Um modelo uma simplificao da realidade que descreve um sistema de um
ponto de vista particular.
Por exemplo, um projeto arquitetnico feito segundo diversas perspectivas: do arquiteto, projeto
arquitetnico em si, do engenheiro eletricista, projeto eltrico, do engenheiro civil, projeto hidrulico e
estrutural. Construmos modelos de sistemas complexos para melhor compreend-los.
Abstrair e refinar incrementalmente so palavras-chaves. Em certos momentos, o projetista deve
focalizar na interao entre componentes do sistema sem se preocupar com seus detalhes internos de
funcionamento, ento ele abstrai estes detalhes. Em outros momentos, preciso detalhar o
comportamento dos componentes. Enfim projetar um sistema significa fazer modelos sob diferentes
perspectivas e graus de abstrao, representando-os por meio de uma notao precisa, refinando-os
sucessivamente at transform-los em algo prximo da implementao lembrando sempre de verificar
se os requisitos so satisfeitos.
A modelagem visual (com auxlio de diagramas) ajuda a manter a consistncia entre os artefatos
(produtos) ligados ao desenvolvimento de um sistema: requisitos, projeto e implementao.
Resumidamente, a modelagem visual pode melhorar a capacidade de uma equipe a gerenciar a
complexidade de software.
2 UML
UML significa Unified Modeling Language ou Linguagem de Modelagem Unificada de projetos
orientados a objetos. Como o prprio nome diz, UML uma linguagem e no um mtodo!
A UML uma linguagem padro de notao de projetos.
Por notao entende-se especificar, visualizar e documentar os elementos de um sistema OO. A UML
importante, pois:
serve como linguagem para expressar decises de projeto que no so bvias ou que no podem
ser deduzidas do cdigo;
prov uma semntica que permite capturar as decises estratgicas e tticas;
prov uma forma concreta o suficiente para a compreenso das pessoas e para ser manipulada
pelas mquinas.
independente das linguagens de programao e dos mtodos de desenvolvimento.
2.1 Breve histrico
Nos anos 90, conhecida como a poca da guerra dos mtodos, vrios mtodos coexistiam com
notaes muitas vezes conflitantes entre si. Dentre estes, os mais conhecidos eram:
OMT (Object Modelling Technique) de Rumbaugh;
Mtodo de Booch;
OOSE (Object Oriented Software Engineering) de Jacobson;
6
Inicialmente, Rumbaugh (OMT) e Booch fundiram seus mtodos (e notaes) resultando no Mtodo
Unificado em 1995 quando trabalhavam juntos na Rational Software (atualmente uma diviso da
IBM). Jacobson juntou-se a eles mais tarde e seu mtodo OOSE foi incorporado nova metodologia
(RUP).
Salienta-se que alm do mtodo, eles unificaram a notao de projeto e a chamaram UML. Ento,
UML representa a unificao das notaes de Booch, OMT e Jacobson. Tambm agrega as idias de
inmeros autores, tais como Harel e seu diagramas de estados, Shlaer-Mellor e o ciclo de vida dos
objetos. Em suma, UML uma tentativa de padronizar os artefatos de anlise e projeto: modelos
semnticos, sintaxe de notao e diagramas.
Na dcada de 90, surge uma organizao importante no mundo dos objetos a OMG (Object
Management Group), uma entidade sem fins lucrativos onde participam empresas e acadmicos para
definirem padres de tecnologias OO.
Outubro de 1995: primeira verso rascunho, verso 0.8 draft.
Julho de 1996: reviso devido ao ingresso de Jacobson, verso 0.9 draft.
Parceiros UML (HP, IBM, Microsoft, Oracle e Rational Software) desenvolveram a verso 1.1 e a
propuseram OMG
A OMG aceita a proposta em novembro de 1997 e assume a responsabilidade de realizar
manuteno reviso da UML
Em maro de 2003, a OMG lanou a verso 1.5
Em outubro de 2004, a OMG lanou verso 2.0 adotada
1

3 ANLISE E PROJETO ORIENTADOS A OBJETOS
H vrios mtodos de desenvolvimento de software. Na dcada de 80 houve preponderncia dos
mtodos estruturados. Atualmente o paradigma OO mais forte e, por isso, importante diferenciar
anlise e projeto estruturado e orientado a objetos.
3.1 Anlise e projeto estruturados
Vrios autores participam da corrente de anlise, projeto e programao estruturados:
1979 - Tom DeMarco: Anlise estruturada (DEMARCO, 1989)
1982 - Gane e Sarson: Anlise estruturada (GANE & SARSON, 1983)
1985 - Ward e Mellor: Anlise estruturada para sistemas tempo real (WARD & MELLOR, 1986)
1989 - Yourdon: Anlise estruturada moderna (YOURDON, 1990)
Na anlise e projeto estruturados, o processo a ser informatizado visto como um conjunto de funes
com dados de entrada, processamento e dados de sada, ou seja, a nfase esta em funes que agem
sobre dados. Estas funes podem ser decompostas em subfunes (decomposio funcional). As
principais caractersticas so:
preocupao com a modularidade e coeso;
desenvolvimento em diferentes nveis de abstrao (top-down).
Os principais diagramas empregados nas diversas metodologias estruturadas so:
dicionrios de dados, modelagem do fluxo de dados (DFD);
modelos de dados: diagrama entidade e relacionamento (DER) e modelo entidade-relacionamento
(MER).

1
http://www.omg.org/technology/documents/formal/uml.htm
7
3.2 Anlise e projeto orientados a objetos
Anlise, projeto e programao orientados a objetos: Coad e Yourdon(1979), Rumbaugh(1991), Grady
Booch(1991), Jacobson(1992). Diferentemente da anlise e projeto estruturados, na orientao a objetos
o processo a ser informatizado visto como um conjunto de objetos que interagem para realizar as
funes. As vantagens do modelo OO so:
maior grau de abstrao;
maior encapsulamento;
modelos apoiados em conceitos do mundo real;
reutilizao (reusabilidade).
Neste curso, no abordado o ciclo de vida de desenvolvimento de software que so inmeros:
cascata, iterativo, incremental, gil, extremo e outros. No entanto, as fases clssicas do ciclo de vida
so utilizadas (engenharia de requisitos, anlise, projeto, implementao, testes, manuteno e
operao).
4 OBJETO E CLASSE
Apresenta-se uma breve reviso de objeto e classes de objeto assim como a notao UML de ambos.
4.1 Objeto
uma abstrao que representa uma entidade do mundo real pode ser algo concreto (computador,
carro) ou abstrato (transao bancria, histrico, taxa de juros). Um objeto num sistema possui trs
propriedades: estado, comportamento e identidade.
Estado: definido pelo conjunto de propriedades do objeto (os atributos) e de suas relaes com os
outros objetos. algo que muda com o tempo, por exemplo, um objeto turma pode estar no estado
aberto ou fechado. Inicia no estado aberto e fecha quando 10 alunos fazem inscrio.
Comportamento: como um objeto responde s solicitaes dos outros e tudo mais o que um objeto
capaz de fazer. implementado por um conjunto de operaes. Ex. objeto turma pode ter
operaes acrescentar aluno ou suprimir aluno.
Identidade: significa que cada objeto nico no sistema. Por exemplo, o objeto turma Tecno-OO
manh diferente do objeto Tecno-OO tarde.
.
Figura 1. Notao de objeto em UML
4.2 Classe
Uma classe uma descrio de um conjunto de objetos com propriedades, comportamento,
relacionamentos e semntica comuns. Uma classe pode ser vista como um esqueleto/modelo para criar
objetos.

Exemplo: classe turma
Atributos: sala, horrio
Operaes: obter local, adicionar estudante, obter horrio
Tecno-OO manh :Turma
Tecno-OO tarde : Turma
objeto : classe
8

Dicas
Classes devem encerrar uma s abstrao do mundo real. Por exemplo, uma classe estudante
contendo tambm o histrico do estudante no uma boa soluo. Melhor dividi-la em duas
classes: estudante e histrico.
Utilizar substantivos para nomear as classes.
Nas fases iniciais de desenvolvimento, pode-se suprimir os atributos e os mtodos deixando
somente os compartimentos.

Figura 2. Notao UML para classe.
5 EXERCCIOS
1. Um usurio deseja uma calculadora que efetue as quatro operaes bsicas. As expresses
permitidas so binrias envolvendo apenas dois nmeros, por exemplo, 2 + 3.5 ou 3 * 3.2.
Identifique os objetos, seus mtodos e atributos.
2. Seguindo a abordagem de orientao a objetos, identificar no enunciado abaixo os objetos e
usurios do sistema. Liste os nomes dos objetos, seus atributos e os usurios do sistema. Faa
o mesmo para a anlise e projeto estruturados identificando as grandes funes e suas
decomposies.
UMA LOCADORA de veculos necessita de um sistema para facilitar o atendimento a seus
clientes. Os carros so classificados por tipo: popular, luxo e utilitrio. As informaes que
interessam locadora sobre cada um dos veculos so: placa do carro, tipo e valor dirio do
aluguel.
Os funcionrios da locadora so responsveis pelo cadastro dos clientes e dos veculos. Eles
tambm fazem as locaes e encerram as mesmas. H clientes especiais e comuns. Os
especiais tm direito a uma taxa de desconto e um valor de quilometragem extra nas suas
locaes. Um cliente identificado pelo nome, nmero do carto de crdito e data de
expirao.
atributos
mtodos

<<esteretipo>>
Classe

9
II NOO GERAL DE ANLISE E PROJETO OO
O objetivo deste captulo apresentar de maneira geral o mtodo de anlise e projeto de sistemas
orientados a objetos utilizado durante o curso. So descritas as fases principais do mtodo e os diagramas
UML mais indicados para cada uma delas. Este mtodo uma simplificao do RUP (Rational Unified
Process).
1 VISO GERAL
No curso, seguiremos o seguinte mtodo:
1. Anlise de requisitos: lista de requisitos funcionais e no-funcionais e diagrama de Casos de
Uso.
2. Levantamento das classes candidatas: montar o diagrama de classes com um levantamento
preliminar das classes, com atributos, mtodos e relaes (quando possvel).
3. Estudo da interao entre objetos: diagramas de interao
4. Refinamento do diagrama de classes
5. Definio do comportamento de classes com estado atravs de mquinas de estados e
diagrama de atividades
6. Modelo de implantao
7. Modelo de implementao
8. Codificao
Os passos de 3 a 5 se repetem at que se chegue prximo da implementao. Eventualmente preciso
revisar os requisitos e verificar as implicaes das mudanas no projeto.
2 ANLISE DE REQUISITOS
Consiste em determinar os servios que o usurio espera do sistema e as condies (restries) sob as
quais o sistema ser desenvolvido e operar. As necessidades do usurio podem ser muito variadas, o
analista deve ser capaz de retirar os requisitos funcionais e no-funcionais destas necessidades:
Funcionais: lista de servios que o sistema deve oferecer ao usurio.
10
No funcionais: propriedades e caractersticas desejadas do sistema relativas capacidade de
armazenamento, tempo de resposta, configurao, uso (ex. uso intuitivo), confiabilidade, etc.

Figura 3: Taxonomia de requisitos no-funcionais (extrada de
http://www.csc.liv.ac.uk/~igor/COMP201/files/SE_L4.ppt#289,15,Non-functional requirement types)
2.1 Papel dos Casos de Uso na Anlise de Requisitos
Casos de uso representam funcionalidades completas para o usurio e no, funcionalidades internas
do sistema. Outro ponto importante que o diagrama de casos de uso um artefato de comunicao
entre cliente, usurios e desenvolvedores. Por ser extremamente simples e, consequentemente, de fcil
compreenso, incentiva a participao do cliente e usurios no processo de desenvolvimento. Tambm
serve como um contrato entre a equipe/empresa desenvolvedora e o cliente.
2.2 Casos de Uso
A coleo de casos de uso representa todos os modos pelos quais o sistema pode ser utilizado pelos
atores envolvidos. Um caso de uso uma seqncia de aes realizadas colaborativamente pelos
atores envolvidos e pelo sistema que produz um resultado significativo (com valor) para os atores.
Um ator pode ser um usurio ou outro sistema.
Para uma calculadora de linha de comando cujo objetivo executar expresses aritmticas (ex. -2 +
3*5), o diagrama de casos da figura 4 pode ser considerado adequado.

Figura 4. Diagrama de casos de uso para a calculadora.
O diagrama de casos de uso apenas um panorama visual das funcionalidades do sistema,
necessria uma descrio textual para detalhar os casos de uso. A tabela 1 ilustra esta documentao
para o caso de uso resolver expresses aritmticas.
TABELA 1: DOCUMENTAO PARA O CASO DE USO RESOLVER EXPRESSES ARITMTICAS BSICAS.
Nome do caso de uso Efetuar expresses aritmticas bsicas
Desempenho
Espao
Privacidade
Segurana
Usabilidade
Eficincia
Portabilidade
Confiabilidade
Produto
Padres
Implementao
Entrega
Organizacionais
Legais
ticos
Interoperabilidade
Externos
Requisitos
no-funcionais
11
Descrio
Permite resolver expresses envolvendo nmeros inteiros e
reais e as operaes bsicas de soma, subtrao,
multiplicao e diviso sem parnteses.
Ator Envolvido Usurio
Pr-condies
Sistema deve estar em execuo aguardando por uma
expresso
Ps-condies
Expresso aritmtica resolvida ou abandono da expresso
pelo usurio.
Fluxo bsico
Usurio Sistema
{Solicita expresso}
Solicita a expresso. (A2)
Fornece a expresso
{Valida expresso}
Avalia se a expresso sintaticamente correta (A1)
{Calcula valor}
Calcula o valor da expresso.
{Mostra o resultado}
Informa o resultado da expresso.
{Fim} Fim do caso de uso.
Fluxos alternativos
A1: em {Valida expresso}
Se o usurio fornecer uma expresso sintaticamente
incorreta, inform-lo sobre o erro e retomar o fluxo
bsico em {Solicita expresso}
A2: em {Solicita expresso}
O usurio pode decidir encerrar o caso de uso sem
fornecer uma expresso. Nesse caso retomar o fluxo
bsico em {Fim}
Portanto, a sada da fase de anlise de requisitos composta por:
lista de requisitos funcionais e no-funcionais;
diagrama de casos de uso e definies textuais dos casos.
3 ANLISE E PROJETO
Anlise a soluo conceitual dada ao problema. Marca o incio da definio informtica, mas sem
levar em conta detalhes da implementao tais como a linguagem a ser utilizada e o sistema
gerenciador de banco de dados. Preocupa-se principalmente com as classes do domnio do problema e
suas relaes e tambm com os casos de uso.
Projeto a soluo informtica dada ao problema. A separao entre anlise e projeto tnue, pois o
projeto acaba sendo o resultado de sucessivos refinamentos do modelo conceitual de anlise.
3.1 Diagramas de Interao
H vrios tipos de diagramas de interao na UML. Exemplifica-se o uso do diagrama de seqncia
cuja utilidade estudar as interaes entre os objetos com o objetivo de refinar o diagrama de classes,
identificando relaes entre classes, seus mtodos e atributos. A figura 5 mostra um cenrio onde o
usurio fornece uma expresso aritmtica sintaticamente correta.
12













Figura 5. Diagrama de seqncia para a calculadora.
3.2 Refinamento do Diagrama de Classes
A partir das informaes do diagrama de seqncia, possvel:
identificar mtodos associados s classes. Por exemplo, a classe IUCalculadora deve ter um
mtodo mostrarResultado(<resultado>).
identificar as relaes entre classes. Pelo diagrama de seqncia, fica clara a existncia de uma
relao de dependncia entre a classe de controle e as duas outras como ilustra a figura 6.












Figura 6. Diagrama de classes.
3.3 Definir o Comportamento das Classes
Nem todas as classes de um sistema possuem mais de um estado. Para as classes mais complexas,
podemos especificar seus comportamentos utilizando mquinas de estado. A figura 7 mostra uma
possvel mquina de estados para a calculadora.
13











Figura 7. Mquina de estados para calculadora.
Os mtodos de uma classe podem ainda ser detalhados por meio de um diagrama de atividades como
ilustra figura 8.














Figura 8: diagrama de atividades - detalhe de um mtodo para verificar a sintaxe de expresso aritmtica.
3.4 Implantao
O diagrama de implantao representa as necessidades de hardware e sofware bsico (ex. servidores).
Para tornar o diagrama mais realista, a figura 9 supe que a calculadora um servio ofertado por um
servidor de aplicaes Web.
14









Figura 9: diagrama de implantao (deployement).
3.5 Componentes do Sistema
O objetivo documentar os componentes do sistema (fontes, bibliotecas) e suas relaes. A figura 10
ilustra o diagrama de componentes para a calculadora e mostra a dependncia entre seus
componentes.










Figura 10: diagrama de componentes para a calculadora.
4 MODELAGEM ESTRUTURAL E COMPORTAMENTAL
Com esta rpida introduo UML, possvel observar que alguns diagramas so mais indicados
para modelar a estrutura do sistema e outros, o comportamento. A figura 11 mostra esta diviso.
15

Figura 11. Diagramas estruturais e comportamentais da UML.
Segue uma breve descrio dos diagramas UML ainda no descritos neste documento:
Pacotes: representa uma coleo de classes que juntas formam uma unidade. Tambm pode servir
para agrupar um conjunto de casos de uso com similaridades funcionais. Os pacotes podem
apresentar relaes, por exemplo, um pacote de classes pode depender de outro para executar suas
funes.
Objetos: um instantneo da execuo do sistema, retrata os objetos instanciados e suas relaes em
um dado momento.
Componentes: segundo a definio de (OMG, 2007, pg. 146), um componente um mdulo ou parte
de um sistema que encapsula seu contedo (comportamento e dados). Um componente exibe seu
comportamento atravs de interfaces bem definidas e pode depender de outros componentes.
Deployement (Implantao ou Distribuio): para representar a arquitetura fsica do sistema, ou seja,
para representar as relaes entre os componentes (artefatos) e os locais de execuo (nodos:
mquinas ou sistemas servidores).
Estrutura Composta: descreve a estrutura interna de uma classe ou componente, detalhando as
partes internas que o compe como estas se comunicam e colaboram entre si (Guedes, 2004).
Atividades: pode ser utilizado para diversos fins, um deles a especificao mais detalhada de
mtodos complexos ou do encadeamento dos casos de uso.
Interao.Comunicao: mostra as interaes entre uma coleo de objetos sem a linha do tempo
(pode ser obtido do diagrama de seqncia e vice-versa).
Interao.Tempo: mostra o estado de um objeto ao longo do tempo.
Interao.Geral: a fuso do diagrama de atividades com o de seqncia. Permite fazer referncia a
diagramas de seqncia e combin-los com controle de fluxo (ex. pontos de deciso, forks e joins).
Objetos
Componentes

Pacotes
Classes
Estrutural
Diagramas
UML
Implantao
Estrutura
Composta
Mquina de
Estados
Interao
Atividades
Casos de Uso
Comportamental
Seqncia
Comunicao
Tempo
Geral de
Interao
16
III MODELO DE CASOS DE USO
O modelo de casos de uso (que mais do que o diagrama) o principal resultado da fase de anlise de
requisitos. Diagramas de casos de uso so utilizados para representar de forma panormica os requisitos
funcionais de um sistema do ponto de vista do usurio. Cabe salientar que h outras utilizaes possveis
para o diagrama de casos de uso, tal como modelagem do negcio, porm, o foco nesta seo est na
representao de requisitos funcionais do usurio.
1 DEFINIO
um diagrama utilizado na anlise de requisitos com objetivos claros:
1. Compreender o problema.
2. Delimitar o sistema (quem est no entorno).
3. Definir as funcionalidades oferecidas ao usurio (no h preocupao com a
implementao).
Diagrama de casos de uso uma ferramenta de comunicao entre clientes,
usurios e desenvolvedores para discutirem e definirem as funcionalidades que
devem ser realizadas pelo sistema.
Os elementos bsicos de um diagrama de casos de uso so:
atores,
casos de uso e
relaes entre os mesmos.
2 ATORES
Representam papis desempenhados por usurios ou qualquer outra entidade externa ao sistema
(ex. hardware, outros sistemas)
Podem iniciar casos de uso
Podem prover e/ou receber informaes dos casos de uso






Figura 12: Notao UML para ator.
Como encontrar atores de um sistema
Examinar o problema procurando por pessoas ou sistemas do entorno.
Quais as pessoas ou departamentos interessados num determinado requisito funcional?
Quem ir suprir o sistema com informaes e quem ir receber informaes do sistema?
Quais os recursos externos utilizados pelo sistema?
Uma pessoa desempenha diferentes papis?
O sistema interage com outros sistemas j existentes?
17
Como saber se um ator foi bem escolhido?
um processo iterativo, a primeira tentativa dificilmente ser a definitiva. Por exemplo, um aluno
calouro diferente de um veterano so atores diferentes? SIM, se eles utilizam o sistema de maneiras
diferentes e NO, caso contrrio.
3 CASOS DE USO
A coleo de casos de uso representa todos os modos de execuo do sistema do ponto de vista do
usurio. Um caso de uso uma seqncia de aes que produz um resultado significativo (com valor)
para um ator.
Quais so as tarefas de cada ator?
Que informaes o ator obtm do sistema?
Quem as fornece?
Quem as captura?
Algum ator precisa ser informado sobre eventos produzidos pelo sistema?
Sim => casos de uso de registro e notificao
H eventos externos que devem ser notificados ao sistema?
Sim => devem haver casos para que os atores possam notificar o sistema
3.1 Descrio
No h descrio padro definida pela UML. Em geral o diagrama bastante informal e sua
estruturao (relao entre casos) no deve ser levada ao extremo. importante ressaltar que o
diagrama de casos de uso uma forma de visualizar os casos e no de descrev-los detalhadamente.
Portanto, o diagrama por si s no suficiente. Os casos de uso so descritos normalmente pelos
seguintes elementos:
nome
descrio
requisitos (requirements): so os requisitos funcionais providos pelo caso de uso
restries (constraints), tais como pr e ps-condies e condies invariantes:
Pr-condies: define o que deve ser verdadeiro para que o caso de uso seja iniciado. Por
exemplo, num sistema bancrio, para o caso de uso Abrir conta-corrente, uma pr-condio
apresentar CPF sem restries (aprovao do pedido)
Ps-condies: o que se torna verdadeiro pela execuo do caso de uso. No mesmo caso de
uso acima, o sistema pode se encontrar em um dos seguintes estados: conta aberta e com um
depsito inicial ou conta no-aberta por reprovao do CPF.
Invariantes: condies que so verdadeiras durante a execuo do caso de uso.
fluxos de eventos: descrio de interaes entre atores e sistema que ocorrem durante a execuo
do caso de uso.
outras informaes: data, autor, etc.
3.2 Fluxo de Eventos
Um fluxo de evento descreve i) como o sistema e os atores colaboram para produzir algo de valor aos
atores e ii) o que pode impedir sua obteno. Um fluxo descreve um caminho entre muitos possveis
visto que um caso de uso pode ser executado de vrios modos.
18
H fluxos primrios ou bsicos (fluxo normal de eventos) e alternativos (o que fazer se). Para
descrev-los, possvel se inspirar na situao em que uma pessoa explica um caminho outra.
Primeiro, o fluxo bsico explicado, depois, as alternativas.
Para ir ao churrasco, pegue a BR116 na direo So Paulo. Logo aps o clube Santa Mnica,
tem um retorno por baixo da pista. Faa o retorno e continue reto (no retorne BR). Continue
nesta estradinha asfaltada por 1 km, no entroncamento pegue a estrada de terra direita, ande
cerca de 500m, voc ver um grande eucalipto e uma araucria. A entrada da chcara entre
os dois. No se esquea de trazer o pinho. // primrio
Se estiver chovendo muito, os 500m na terra podem ser bem difceis porque o barro mole.
Neste caso, siga reto no entroncamento (ao invs de virar direita) e na prxima a direita
pegue a rua de paraleleppedos. Ande cerca de 1 km e depois vire na segunda a direita que vai
desembocar na frente da chcara. // alternativo 1
Se voc for comprar o pinho no caminho, logo depois de fazer o retorno da BR tem uma
venda. Se estiver fechada, um pouco mais a frente, tem um senhor da chcara Pinhais que
tambm vende. Se no encontrar pinho, no tem problema. // alternativo 2
Fluxos documentam as responsabilidades, ou seja, como as responsabilidades especificadas nos casos
de uso so divididas entre sistema e atores. No desenrolar do projeto, as responsabilidades atribudas
ao sistema devem ser distribudas entre os objetos que compem o sistema.
Nas fases iniciais de anlise bom concentrar-se nos fluxos bsicos (cerca de 80% do tempo de
execuo de um sistema ocupado pelos casos primrios) e somente identificar os casos secundrios.
3.2.1 Fluxo Bsico
Um fluxo bsico representa o que ocorre normalmente quando o caso de uso executado. A descrio
do fluxo bsico deve conter (Bittner e Spencer, 2003):
ator e o evento que o mesmo dispara para iniciar o caso;
a interao normal (sem tratamento de excees) entre ator e sistema;
descrio de como o caso termina.
Exemplo: considere um sistema onde o cliente realiza compras on-line num site utilizando um carrinho
de compras virtual. O projetista do sistema previu um caso chamado buscar produtos e fazer pedido
especificado pelo fluxo bsico seguinte - extrado de (Bittner e Spencer, 2003):
NOME: Buscar produtos e fazer pedido
DESCRIO: Este caso descreve como um cliente usa o sistema para visualizar e comprar
produtos disponveis. Para encontrar um produto, o cliente pode pesquisar o catlogo por
tipo de produto, fabricante ou por palavras-chaves.
PR-CONDIES: o cliente est logado no sistema.
PS-CONDIES: o cliente realiza uma compra ou no.
FLUXO BSICO DE EVENTOS
1. O caso de uso inicia quando o ator cliente escolhe a opo de consultar o catlogo de
produtos.
2. {Mostrar catlogo de produtos}
3. O sistema mostra os produtos oferecidos, ressaltando os produtos cujas categorias constam
no perfil do cliente.
4. {Escolher produto}
19
5. O cliente escolhe um produto a ser comprado e define a quantidade desejada.
6. Para cada produto selecionado disponvel em estoque, o sistema registra o cdigo do
produto e a quantidade solicitada reservando-a no estoque e adiciona-o ao carrinho de
compras.
7. {Produto esgotado}
8. Os passos 3 e 4 se repetem at que o cliente decida efetuar a compra dos produtos.
9. {Processar pedido}
10. O sistema pergunta ao cliente se deseja fornecer informaes sobre o pagamento.
11. O sistema utiliza um protocolo seguro para obter as informaes de pagamento do cliente.
12. Executar subfluxo validar informaes de pagamento
13. {Informaes de pagamento no vlidas}
14. O sistema pergunta ao cliente se deseja fornecer informaes sobre o envio das mercadorias.
15. O sistema utiliza um protocolo seguro para obter as informaes de envio.
16. Executar subfluxo validar informaes de envio.
17. {Informaes de envio no vlidas}
18. Executar subfluxo efetuar transao financeira.
19. O sistema pergunta ao cliente se deseja comprar mais produtos.
20. Se o cliente desejar comprar mais produtos, retomar o caso no ponto {Mostrar catlogo de
produtos}, se no o caso termina.
No fluxo bsico acima, pode-se notar a existncia de vrios elementos que sero descritos a seguir:
subfluxo, pontos de extenso e fluxos alternativos.
3.2.2 Subfluxo
Um fluxo de eventos pode ser decomposto em subfluxos para melhorar a legibilidade. No entanto,
interessante evitar muitas decomposies, pois o fluxo ficar muito fragmentado e seu entendimento
dificultado. Um subfluxo deve ser atmico, isto , ou executado na sua totalidade ou no
executado. Para referenciar um subfluxo a partir de outro fluxo usar a notao: executar <nome
subfluxo>. No exemplo Buscar produtos e fazer pedido, os subfluxos seguintes so encontrados:
S1 Validar informaes de pagamento;
S2 Validar informaes de envio;
S3 Efetuar transao financeira.
Estes subfluxos podem ser detalhados da mesma maneira que um fluxo bsico, porm deve-se evitar
muitas decomposies sob o risco de perder a viso geral do caso de uso.
3.2.3 Pontos de extenso
So pontos precisos num fluxo de eventos que servem para inserir comportamentos adicionais. Pontos
de extenso podem ser privados ou pblicos. So privados se visveis somente dentro do caso onde
foram definidos ou pblicos se visveis nos casos que estendem o caso onde foram definidos.
No exemplo Buscar produtos e fazer pedido, os pontos de extenso seguintes so encontrados:
{Mostrar catlogo de produtos}
{Escolher produto}
20
{Produto esgotado}
{Processar pedido}
{Informaes de pagamento no vlidas}
{Informaes de envio no vlidas}
Um ponto de extenso pode definir
uma localizao nico dentro do fluxo, por exemplo, {Mostrar catlogo de produtos}, {Escolher
produtos} e {Processar pedido};
um conjunto de localizaes que representam um certo estado do caso de uso, por exemplo,
{Produto esgotado} que poderia aparecer em vrios pontos do fluxo de eventos;
uma regio entre dois pontos de extenso, por exemplo, {Escolher produtos} e {Processar pedido}.

3.2.4 Fluxo Alternativo
Um fluxo alternativo apresenta um comportamento opcional, de outra forma, que no parte do
comportamento normal de um caso de uso. Fluxos alternativos so utilizados para representar
tratamento de excees ou um comportamento alternativo complexo que tornaria o fluxo bsico muito
longo ou de difcil compreenso.
Fluxos alternativos sempre so dependentes da existncia de uma condio que ocorre em um ponto
de extenso de outro fluxo de eventos. H trs tipos de fluxos alternativos:
1. Especfico: iniciam num ponto de extenso.
2. Regional: podem ocorrer entre dois pontos de extenso.
3. Geral: podem ocorrer em qualquer ponto do caso de uso.
No exemplo Buscar produtos e fazer pedido, os fluxos alternativos seguintes so encontrados: Tratar
produto esgotado (especfico) e pesquisar por palavras-chaves (regional).
A2 Tratar produto esgotado
Em {Produto esgotado} quando no h a quantidade requisitada do produto em estoque.
1. O sistema informa que o pedido no pode ser completamente satisfeito.
2. // a descrio deste fluxo continua com oferta de quantidades e produtos alternativos ao cliente
3. O fluxo de eventos bsico retomado no ponto onde foi interrompido.

A1 Pesquisar por palavras-chaves
Entre {Mostrar catlogo de produtos} e {Escolher produto} quando o cliente escolhe realizar
uma pesquisa por palavras-chaves.
1. O sistema pergunta ao cliente pelos critrios de busca do produto.
2. O cliente fornece os critrios de busca de produto.
3. // a descrio deste fluxo continua
4. O fluxo de eventos bsico retomado em {Escolher produto}.
No h fluxo geral para o exemplo, mas poderia ser definido da seguinte maneira: em qualquer ponto do
caso de uso Buscar produtos e fazer pedido...
21
Por que representar um fluxo alternativo separadamente do fluxo bsico se possvel represent-lo com um se (if)
no fluxo bsico?
Fluxos alternativos so opcionais e descrevem comportamentos que esto fora do comportamento
normal esperado.
Nem todos os fluxos alternativos representam funcionalidades essenciais, muitos deles podem no
ser necessrios, podem ser muito caros ou no prover funcionalidades importantes o suficiente
para dispndio de esforos de desenvolvimento.
Fluxos alternativos permitem adicionar funcionalidade ao fluxo bsico de maneira incremental ou
remover funcionalidade medida que tempo e dinheiro se esgotam.
Por exemplo, qual a importncia de realizar pesquisas por palavras-chaves no exemplo em uso? Se for
apenas uma das alternativas de busca no inviabiliza a funcionalidade do fluxo bsico como um todo.
Agora se algum perguntar qual a importncia do fluxo bsico buscar produtos e realizar pedido, fcil
ver que no pode ser deixado de fora.
3.2.5 Diagrama de atividade
Um diagrama de atividade pode ser empregado para representar os fluxos de eventos de um caso de
uso. Sua utilizao no suprime a descrio textual, pelo contrrio, ele deve ser visto como uma
ilustrao simplificada da descrio textual. Se todos os detalhes da descrio textual forem colocados
no diagrama, este ficar extremamente poludo e perder sua utilidade: tornar o caso de uso mais
compreensvel aos leitores.















Figura 13: Exemplo de diagrama de atividades.
3.2.6 Cenrios
Cenrios so instncias de execuo dos casos de uso. Os fluxos alternativos representam as
possibilidades de execuo de um caso de uso. No exemplo buscar produtos e realizar pedido, o fluxo
alternativo pesquisar produtos por palavras-chaves uma alternativa simples visualizao do catlogo
22
Fluxo bsico
Fluxo
alternativo
cenrio
de produtos, logo h pelo menos dois caminhos possveis de execuo. Um cenrio representa um
desses caminhos (figura 14).





Figura 14: Representao esquemtica de um cenrio.
Cenrios so importantes para definir casos de teste e para desenvolvedores pensarem sobre como o
sistema ser utilizado. Podem ser documentada adicionando-se informao s descries dos casos de
uso ou como parte da descrio dos testes. No h necessidade de descrev-los detalhadamente, basta
nome-los e descrever o caminho a ser percorrido (por exemplo, fluxo bsico, fluxo alternativo a1,
fluxo bsico).
3.2.7 Realizaes de Casos de Uso
Um caso de uso pode ser realizado (projetado e implementado) de diferentes modos. Em UML h uma
representao para realizao de caso de uso como ilustra a figura 15. O intuito dessa representao
fazer uma ponte entre as descries do sistema utilizadas pelas pessoas envolvidas na sua construo,
mas que no participam do desenvolvimento em si, e as descries do sistema utilizadas pela equipe
de desenvolvimento.








Figura 15: Realizao de um caso de uso.
Diagramas de interao podem ser associados s realizaes de casos de uso para especificar o fluxo
de informaes entre objetos que concretizam o caso. Porm, a representao de realizao de caso no
muito utilizada.
4 RELAES
H vrios tipos de relaes possveis num diagrama de casos de uso, porm importante salientar que
as relaes:
1. no representam a ordem de execuo dos casos;
2. devem melhorar a compreenso do que o sistema deve fazer (e no como projet-lo).
Em seguida, apresentam-se as relaes mais comuns.
Modelo de casos de uso
Modelo de anlise e projeto
23
4.1 Associao
Associao o tipo mais comum de relao. Pode ser utilizada entre dois atores ou entre um ator e um
caso de uso. So representadas por uma linha cheia, com ou sem direo.
Ator x Ator
Relaes associativas podem conectar atores para representar comunicao entre atores. A relao
pode receber um nome que identifica o contedo da mensagem, documento ou objeto que trafega
entre os atores. A figura 16 mostra uma associao entre o ator usurio de biblioteca que passa o livro ao
atendente que realiza o emprstimo ou a devoluo. Como no h flechas, assume-se que o atendente
devolve algo ao usurio da biblioteca, provavelmente um comprovante no representado no
diagrama. No recomendvel colocar este tipo de relao no diagrama de casos de uso.








Figura 16: Exemplo de associao entre atores.
Ator x Caso
H vrios usos para associaes entre atores e casos de uso:
1. indica quem inicia a comunicao, o ator ou o caso de uso (sistema);
2. indica o fluxo de informaes, ou seja, quem fornece informaes a quem.
Para documentar a escolha, pode-se atribuir um nome associao. Na figura 16, h uma associao
entre o atendente e o caso de uso realizar emprstimo. Observar que bidirecional, portanto o atendente
inicia a execuo do caso, fornece e recebe informaes do mesmo.
Associaes unidirecionais deixam os diagramas mais claros, embora no sejam obrigatrias. Por
exemplo, a figura 17 ilustra um mesmo diagrama que representa os requisitos de um sistema de
telefonia com relaes bidirecionais e unidirecionais. No diagrama superior, pode-se deduzir que o
emissor inicia a chamada telefnica e, no inferior, esta informao est explcita.
24











Figura 17: Associaes bidirecionais e unidirecionais.
4.2 Incluso
A relao de incluso utilizada entre dois casos, quando um deles inclui o outro na sua execuo
(subcaso). Um subcaso representa parte de um fluxo de eventos bsico, isto , um subfluxo que foi
separado e representa um conjunto de aes atmico.
Ressalta-se que a existncia de um subfluxo na descrio textual de um caso no implica sua
representao no diagrama de casos de uso. A relao de incluso (<<include>>) deve ser utilizada
somente quando dois ou mais casos de uso apresentam partes idnticas nos seus fluxos de evento,
caso contrrio (se somente um caso de uso utilizar o subfluxo) no deve ser representado. Isto requer
que os fluxos de evento sejam escritos antes de se colocar relaes de incluso no diagrama.
A figura 18 mostra um caso efetuar matrcula que possui subfluxos escolher disciplinas, alocar alunos s
turmas e emitir boleto. Este ltimo compartilhado com o caso Efetuar inscrio curso opcional e,
portanto, deve ser representado no diagrama. Um erro comum que adiciona complexidade ao
diagrama incluir os subfluxos escolher disciplinas e alocar alunos s turmas no diagrama.












Figura 18: exemplo de incluso de casos.
25
importante ressaltar que:
um caso de uso nunca deve ser includo apenas por um caso, ou seja, no utilizar <<include>> para
decompor o diagrama em partes;
um caso de uso que includo por vrios outros no tem conhecimento sobre quem o inclui,
portanto, podem ser includos por qualquer caso sem sofrer modificaes;
no utilizar a relao de incluso para representar opes de menu, pois o caso que faz a incluso
seria um simples despachante, todo o comportamento estaria fragmentado nos casos includos.
Enfim, incluso deve ser utilizada para administrar comportamentos comuns e no para estruturar
funcionalmente o diagrama.
4.3 Extenso
Um caso pode estender outro quando se deseja inserir um comportamento opcional ou excepcional
disparado por alguma condio (ex. um alarme ou condio especial de algum objeto). Situaes que
podem levar ao uso da relao de extenso (Bittner e Spencer, 2003):
Descries opcionais ao comportamento normal do sistema: por exemplo, mdulos que podem
ser comprados do desenvolvedor ou de terceiros.
Descries de tratamento de erros e excees complexos: estes tratamentos podem ser
extremamente longos e ofuscar o fluxo bsico.
Customizao: fluxos alternativos que especificam como diferentes clientes tratam certas situaes
no dentro do mesmo caso de uso base.
Administrao de escopo e de release: comportamentos que sero includos futuramente.
importante ressaltar que:
Um caso de uso de extenso no requer modificaes no caso base (aquele que estendido). O
comportamento bsico do caso base permanece intacto.
Um caso de uso que estende um caso base conhece este ltimo (no muito comum um caso de
uso estender mais de um caso base).
Uma extenso nasce como um fluxo alternativo, mas nem todo fluxo alternativo vira uma
extenso.
Casos de uso que estendem assumem o controle no ponto de extenso e quando terminam
devolvem o controle no mesmo ponto.
Aqui cabe uma distino entre fluxos alternativos e casos de uso que estendem outros. Fluxos
alternativos so parte do caso de uso base e tm acesso ao seu estado, pr-condies, outros fluxos
existentes e pontos de extenso alm daquele onde se inserem. Casos de uso que estendem conhecem
apenas o ponto de extenso onde se inserem no caso estendido. Para saber se um fluxo alternativo
candidato a ser uma extenso, deve responder positivamente questo: o sistema pode ser entregue
sem a extenso?
Na figura 19, a emisso de histrico escolar estendida pelo caso imprimir comprovante de trmino
quando o aluno solicitante for formado. Observa-se que um comportamento opcional que pode no
ser oferecido sem prejuzo ao comportamento bsico emitir histrico escolar.
26









Figura 19: exemplo de relao de extenso entre casos de uso.
Nota-se na o ponto de extenso pblico denominado {aluno formado} onde o comportamento
opcional imprimir comprovante trmino inserido. provvel que existam outros pontos de extenso
privados definidos nos fluxos de emitir histrico escolar, porm, no diagrama s os usados pelas
extenses so listados. A figura 20 ilustra o diagrama de casos de uso para o exemplo buscar produto e
fazer pedido.










Figura 20: pontos de extenso para o caso buscar produtos e fazer pedido.
4.4 Generalizao/Especializao
A relao de generalizao/especializao pode ocorrer entre casos de uso ou entre atores.
Caso x Caso
Generalizao permite especificar comportamentos genricos que podem ser especializados para
atenderem necessidades especficas. Normalmente utilizado quando se quer descrever famlias de
sistemas.
Por exemplo, uma empresa que desenvolve software pare terminais bancrios de auto-atendimento
quer expandir seus negcios para outras reas, tais como pagamento direto em bombas de gasolina.
NOME: Realizar transao (caso abstrato)
DESCRIO: Permite ao usurio comprar mercadorias de um terminal automtico
sendo que o valor das mercadorias descontado de uma conta bancria.
27
PR-CONDIES: (e) o cliente possui um carto bancrio; a conexo com o banco
est ativa; o terminal deve ter mercadoria.
PS-CONDIES: (ou) O terminal retornou o carto bancrio ao cliente, entregou a
mercadoria ao cliente e debitou o valor de sua conta. O terminal retornou o carto
bancrio ao cliente, no entregou nenhuma mercadoria e nenhum valor foi
debitado da sua conta.
FLUXO BSICO DE EVENTOS
1. O ator cliente insere o carto bancrio no terminal.
2. O sistema l as informaes da conta do cliente no carto bancrio
3. O sistema solicita ao cliente a senha
4. O cliente fornece a senha
5. O sistema verifica se a senha fornecida pelo cliente idntica lida do carto
bancrio
6. O sistema contata com o Sistema Bancrio para verificar se as informaes da
conta do cliente so vlidas
7. O sistema solicita o valor da transao
8. O sistema contata o Sistema Bancrio para verificar se o cliente tem saldo para
cobrir a solicitao.
{Cliente realiza a transao}
9. O sistema registra o valor da transao.
10. O sistema comunica ao Sistema Bancrio que a transao foi efetuada.
11. O sistema grava no log os dados da transao: data, hora, valor e conta.
12. Trmino do caso de uso.

NOME: Sacar (caso concreto)
DESCRIO: Especializa o caso de uso realizar transao para permitir ao cliente
retirar dinheiro de um terminal de auto-atendimento bancrio.
PR-CONDIES: (e) o cliente possui um carto bancrio; a conexo com o banco
est ativa; o terminal deve ter dinheiro.
PS-CONDIES: (ou) O terminal retornou o carto bancrio ao cliente, entregou o
dinheiro ao cliente e debitou o valor de sua conta. O terminal retornou o carto
bancrio ao cliente, no entregou dinheiro e nenhum valor foi debitado da sua
conta.
FLUXO BSICO DE EVENTOS
Em {Cliente realiza transao}
1. O sistema verifica se tem dinheiro suficiente em relao ao montante solicitado
pelo cliente.
2. O sistema entrega o montante solicitado.
3. O sistema solicita que retire o dinheiro do terminal.
4. O cliente pega o dinheiro.
28
5. Retoma-se o caso de uso abstrato em {Cliente realiza transao}

NOME: Abastecer veculo (caso concreto)
DESCRIO: Especializa o caso de uso realizar transao para permitir ao cliente obter
combustvel de uma bomba debitando o valor de sua conta.
PR-CONDIES: (e) o cliente possui um carto bancrio; a conexo com o banco est ativa;
a bomba tem combustvel.
PS-CONDIES: (ou) O terminal retornou o carto bancrio ao cliente, liberou o
combustvel ao cliente e debitou o valor de sua conta. O terminal retornou o carto
bancrio ao cliente, no liberou combustvel e nenhum valor foi debitado da sua conta.
FLUXO BSICO DE EVENTOS
Em {Cliente realiza transao}
1. O sistema solicita ao cliente para tirar o bico de abastecimento e libera o fornecimento
de combustvel.
2. O cliente enche o tanque at atingir o valor informado ou at que o tanque esteja cheio.
3. O cliente recoloca o bico na bomba.
4. Retoma-se o caso de uso abstrato em {Cliente realiza transao}

O diagrama de casos de uso correspondente aos casos acima ilustrado na figura 21.









Figura 21: generalizao/especializao de casos de uso.
Ressalta-se que nesta situao, so executados os casos de usos especializados. Eles apenas reusam
partes do caso geral. A tabela 3 mostra as diferenas entre especializao e extenso de casos de uso.
TABELA 3: COMPARATIVO ENTRE ESPECIALIZAO E EXTENSO DE CASOS DE USO.
Especializao Extenso
O caso de uso especializado executado O caso de uso base executado
O caso de uso base no precisa ser
completo e com sentido. H vrias
lacunas preenchidas somente nas
especializaes.
O caso de uso base deve ser completo e com
sentido.
O comportamento de uma execuo
depende unicamente do caso especfico.
O comportamento de uma execuo
depende do caso de uso base e de todas as
29
extenses que so executadas.

Ator x Ator
Especializao de atores representa que um conjunto deles possui responsabilidades ou caractersticas
em comum. Algumas dicas para evitar modelagens desnecessrias:
No utilizar atores para representar permisses de acesso.
No utilizar atores para representar organogramas (hierarquias) de cargos de uma empresa.
Utilizar atores somente para definir papis em relao ao sistema.
Por exemplo, se num sistema de matrculas de uma universidade h casos de uso especiais para
alunos de cincias exatas e para alunos de humanas, ento sinal que estes alunos so especializaes
de um ator genrico aluno. A figura 22 ilustra a notao UML para este caso. Observar que alunos de
cincias exatas e de humanas herdam todas as associaes do ator aluno.












Figura 22: Especializao de atores.
5 MODELAGEM
5.1 Dicas
Casos de uso auxiliares
Casos de uso auxiliares so frequentemente esquecidos, pois no so essenciais funcionalidade
do sistema. Porm, esquec-los completamente pode conduzir a um sistema difcil de ser
utilizado.
Lembrar de colocar casos de uso para executar, manter e configurar o sistema, tais como: lanar e
parar o sistema, incluir novos usurios, fazer backup das informaes, incluir novos relatrios e
realizar configuraes.
Decomposio funcional
No necessrio detalhar em excesso os casos de uso. Muitos detalhes levam a decomposio dos
casos em funes. O objetivo compreender o sistema atravs de cenrios de utilizao.
Casos de uso no so feitos para analisar (no sentido de decompor) os requisitos em requisitos
menores. um processo de sntese ou elaborao (e no de anlise) no qual o problema no
30
totalmente conhecido. Quebr-lo em partes menores (anlise) dificulta a obteno de uma viso
geral.
Em equipes com forte competncia em anlise estruturada, h tendncia em encontrar funes ao
invs de casos de uso. Por exemplo, fazer pedido, revisar pedido, cancelar pedido e atender pedido
podem parecer bons casos de uso. No fundo, todas estas funes esto relacionadas ao caso de uso
realizar pedido.
Decomposio funcional pode levar a um nmero intratvel de casos, mesmo para pequenos
sistemas, e perda de foco no que realmente importante no sistema (o que traz valor aos atores).
Casos de uso no chamam outros casos de uso ou se comunicam com outros casos.
Estrutura e detalhamento
No estruturar demais o diagrama de casos de uso, isto , no inclua relaes entre casos de uso a
no ser que sejam extremamente necessrias. O uso em excesso destas relaes podem fragmentar
o diagrama, diminuindo a compreenso global.
O modelo deve ser o mais simples e direto possvel.
No descrever o que ocorre fora do sistema. Por exemplo, interao entre atores pode ser
importante para o negcio, mas se o sistema no facilita esta interao, deixe-a fora. Se for
necessrio esclarecer estes pontos faa um modelo do negcio e no um modelo de casos de uso.
No fazer casos tais como incluir, consultar, alterar e excluir (ICAE). Casos de uso que descreve
comportamentos ICAE no adicionam muito valor descrio da funcionalidade do sistema. Para
estes tipos de comportamentos, os requisitos so bastante claros e no se deve perder tempo
especificando-os. A maior parte destes comportamentos tem um padro mostrar campos, usurio
entra com os dados, sistema valida, usurio corrige erros,... A validao, a parte mais importante dos
comportamentos ICAE, pode ser capturada no domnio do modelo (por meio de relaes,
cardinalidade e restries) ou textualmente no glossrio de dados.
Modelo de casos de uso mais que um diagrama
O diagrama de casos de uso uma viso panormica dos casos de uso e, portanto, apenas um dos
componentes do modelo de casos de uso. A descrio textual dos mesmos a parte mais
importante do modelo. So elementos do modelo de casos de uso: glossrio, modelo do domnio e
diagramas de atividades.
Um glossrio e um modelo do domnio podem evitar o excesso de detalhes nas descries dos
casos de uso. Por exemplo, ao invs de descrever a validao da entrada de dados, os campos
podem ser definidos no glossrio com os respectivos valores possveis.
Um modelo do domnio ajuda a entender as relaes existentes entre as entidades do domnio e as
restries sobre as relaes.
5.2 Passos
Para elaborar um modelo de casos de uso, os seguintes passos podem ser seguidos:
Recapitular a viso do sistema (estudo de viabilidade) aos envolvidos.
Elaborar se necessrio um diagrama de contexto para definir os limites do sistema (o que est
dentro e o que est fora).
Identificar os atores do sistema.
Identificar os casos de uso: descrev-los e rascunhar o fluxo de eventos. No se preocupe com
fluxos alternativos. No gaste mais do que 10 minutos para descrever cada caso de uso.
Esboar o diagrama de casos de uso mostrando associaes entre atores e casos de uso.
31
Verificar os casos de uso:
H casos de uso sem conexo com requisitos funcionais? Caso haja, pode haver casos em
excesso ou requisitos que no foram identificados!
H requisitos funcionais sem casos? Alguns casos podem ter sido esquecidos.
Todos os requisitos no-funcionais foram tratados (associados aos casos de uso quando so
especficos)?
Todos os tipos de usurios foram mapeados para um ator ao menos?
Descrever os casos detalhadamente
Representar os subfluxos (<<include>>) e fluxos alternativos (<<extend>>) considerados importantes
no diagrama
Verific-los:
possvel eliminar os casos includos ou as extenses e ainda ser capaz de entender o que o
sistema faz para as partes interessadas?
6 EXERCCIOS
1. Um aluno de uma universidade particular deve escolher disciplinas do semestre. Em seguida
ele alocado s turmas para ento receber uma fatura emitida pelo sistema de faturamento
com o valor a ser pago em funo do nmero de turmas em que conseguiu vaga. Quais so os
atores e casos de uso?
2. A secretaria de uma universidade deve cadastrar turmas, apag-las e modific-las e envi-las
aos departamentos acadmicos? Quais so os atores e casos de uso?
3. Construir o diagrama de casos de uso e especificar os fluxos de eventos bsico.
Um cliente deseja um sistema que permite jogar jogo da velha e forca. O sistema destinado a
um usurio e deve armazenar as estatsticas de uma sesso (do lanamento ao trmino do
sistema).
Em uma sesso o usurio pode jogar diversas vezes cada um dos jogos. Ao trmino de cada
jogo, atualizam-se as estatsticas da sesso: nmero de vezes que jogou velha, nmero de
vitrias absoluto e percentual e o mesmo para forca. O usurio deseja que o painel de
estatsticas esteja sempre visvel.
4. Qual a diferena entre as relaes de incluso e extenso entre casos de uso?
5. Como voc modelaria a situao abaixo utilizando casos de usos? Faa a descrio completa
para um dos casos incluindo descrio, pr-condies, ps-condies, fluxo de eventos
bsico e alternativos e o diagrama de casos.

A atividade da biblioteca centra-se principalmente no emprstimo de publicaes pelos
alunos. O emprstimo registrado pelos funcionrios da biblioteca que tambm
consultam diariamente os emprstimos cujos prazos foram ultrapassados. Os alunos
necessitam pesquisar os livros existentes na biblioteca. Caso um livro esteja emprestado
mostrado a data esperada de entrega.
6. Construir o diagrama de casos de uso:
Um cliente (pessoa fsica ou jurdica que paga o advogado pra defend-la ou para processar
outra pessoa) procura o advogado. Se o cliente ainda no estiver cadastrado, o advogado
dever registrar seus dados pessoais.
Em seguida, o cliente deve fornecer informaes a respeito do processo que deseja que o
advogado mova contra algum ou que o defenda de outra pessoa. Obviamente o processo
precisa ser registrado e receber diversas adies enquanto estiver em andamento. O cliente
32
deve fornecer tambm informaes sobre a parte contrria (pessoa fsica ou jurdica que est
processando ou sendo processada pelo cliente), que dever ser registrada, caso ainda no
esteja. Observe que uma mesma pessoa fsica ou jurdica pode ser tanto um cliente como uma
parte contrria em processos diferentes obviamente.
Um processo deve tramitar em um determinado tribunal e em uma determinada vara, no
entanto um tribunal pode julgar muitos processos e uma vara pode possuir diversos processos
tramitando nela. Um tribunal pode possuir diversas varas, porm um processo julgado por
um tribunal s pode tramitar em varas pertencentes ao mesmo. O advogado pode achar
necessrio emitir relatrios de todos os processos em andamento em um tribunal e tramitando
em uma vara.
Cada processo possui no mnimo uma audincia, cada audincia relativa a um determinado
processo deve conter sua data e a recomendao do tribunal. Para fins de histrico do
processo, cada audincia deve ser registrada.
Um processo pode gerar custas (cpias, viagens, etc.). Cada custa deve ser armazenada de
forma a ser cobrada da forma contrria caso o processo seja ganho.
Este sistema deve estar integrado a um sistema de contas a pagar receber, cada custa gera uma
conta a pagar. Caso o processo seja ganho, ele gerar uma ou mais contas a receber,
dependendo da negociao com a parte contrria.
33
IV ANLISE DOS CASOS DE USO
Este captulo inicia com uma breve apresentao do padro de projeto MVC e do padro observador que
servem de ponto de partida na escolha das classes que fazem parte de um sistema (classes de anlise). Em
seguida, apresenta-se o levantamento das classes de anlise a partir dos casos de uso.
1 ANLISE
O levantamento das classes de anlise marca o incio da construo do modelo da anlise (RUP).
Ocorre uma mudana na linguagem, enquanto no modelo de casos de uso a descrio do sistema era
feita na linguagem do cliente/usurio, na anlise emprega-se a linguagem dos desenvolvedores. A
tabela 4 ilustra as diferenas entre o modelo de casos de uso e o modelo de anlise segundo (Jacobson
e co-autores, 1999).
TABELA 4: COMPARAO ENTRE MODELO DE CASOS DE USO E DE ANLISE (JACOBSON E CO-AUTORES, 1999).
Modelo de casos de uso Modelo de anlise
Linguagem do cliente/usurio Linguagem dos desenvolvedores
Viso externa do sistema Viso interna do sistema
Estruturado pelos casos de uso Estruturado por classes estereotipadas e pacotes
Contrato entre cliente e desenvolvedores sobre
o que o sistema deve e no deve fazer
Utilizado pelos desenvolvedores para entender
qual a forma do sistema, i.e., como deve ser
projetado e implementado
Pode haver redundncias e inconsistncias nos
requisitos
No deve haver redundncias e inconsistncias
nos requisitos
Captura a funcionalidade do sistema Rascunha como realizar a funcionalidade
Define casos de uso que so analisados no
modelo de anlise
Define realizaes de casos de uso, cada uma
representando a anlise de um caso de uso
Por que fazer anlise?
Uma pergunta recorrente por que fazer anlise ao invs de partir diretamente ao projeto e
implementao? H vrias respostas que se complementam:
Antes de projetar e implementar preciso especificar os casos de uso num grau de detalhamento
e de formalismo que no interessa aos usurios, s aos desenvolvedores.
Anlise permite obter uma viso geral do sistema de difcil obteno se todos os detalhes de
projeto e implementao fossem nela inseridos. Anlise pode envolver grandes pores do sistema
sem muitos custos se comparado ao projeto e implementao. Resultados da anlise permitem
planejar melhor o projeto/implementao dividindo-se o sistema em partes menores que podem
ser desenvolvidos incrementalmente de maneira seqencial ou concorrente (projetado e
implementado por equipes diferentes).
Se o sistema em desenvolvimento utiliza um sistema legado este ltimo pode sofrer reengenharia
para se obter o modelo de anlise para que os desenvolvedores o entendam sem entrar nos
detalhes tecnolgicos. A reengenharia completa um processo caro, custoso e demorado que pode
no ser necessrio se o sistema legado no necessita ser modificado e utiliza tecnologias obsoletas.
Um modelo de anlise pode fornecer uma viso conceitual do sistema independente das
tecnologias empregadas. Por exemplo, um cliente pode querer que duas fornecedoras de software
faam uma proposta baseando-se em uma especificao. Outro caso seria a necessidade de
implementar parte de um sistema em plataformas ou linguagens diferentes devido infra-
estrutura existente em filiais distintas (por exemplo, plataformas diferentes). Ainda, sistemas
34
crticos (controle de aeronaves, linhas de trem) podem necessitar de programas que realizam
clculos empregando diferentes mtodos para que decises crticas s sejam tomadas quando os
dois mtodos produzem resultados equivalentes.
Anlise ou no
Em relao aos modelos de anlise, pode-se dizer que h trs abordagens possveis:
Mant-lo atualizado durante todo o ciclo de vida do sistema.
Consider-lo como um resultado intermedirio e, uma vez que o projeto esteja feito, atualizar o
modelo de projeto.
Fazer anlise e projeto integrados (recomendvel apenas para sistemas extremamente simples), h
duas possibilidades:
requisitos so analisados durante o levantamento ou captura: exige mais formalismo no
modelo de casos de uso;
requisitos so analisados durante o projeto: se os requisitos forem simples e/ou bem
conhecidos.
Realizao dos casos de uso
Segundo (Jacobson e co-autores, 1999, pg. 221), se o modelo de anlise no atualizado durante o ciclo
de vida do software, ou seja, foi criado apenas para possibilitar a elaborao de um bom projeto, no
h realizao de casos de uso na anlise. Neste caso, a realizao do caso de uso ocorrer somente no
projeto. As realizaes de casos de uso de projeto podem ser diretamente conectadas ao modelo de
caso de uso por uma relao de dependncia <<trace>> (ao invs de estarem ligadas realizao do
caso de uso de anlise), conforme ilustra a Figura 24.

Figura 24: realizao dos casos de uso - anlise e projeto ou somente no projeto.
Mtodo de Anlise
De acordo com o RUP, a anlise de casos de uso composta por:
Para cada caso de uso considerado em uma iterao
Criar uma realizao de caso de uso
Complementar a descrio do caso de uso
Levantar as classes de anlise examinando o comportamento do caso de uso
Distribuir o comportamento do caso de uso entre as classes de anlise
Para cada classe de anlise
Descrever as responsabilidades da classe
<<trace>>
<<trace>>
Modelo de
casos de uso
Realizao do
caso de uso
(anlise)
Realizao do
caso de uso
(projeto)
<<trace>>
<<trace>>
Modelo de
casos de uso
Realizao do
caso de uso
(projeto)
35
Definir atributos
Definir relaes entre classes
2 PADRO MVC
MVC (Model, View, and Controller) um padro de arquitetura de software. No contexto da engenharia
de software, um padro uma soluo comprovada a um problema recorrente. Segundo (Gamma e
co-autores, 1995), padres especificam abstraes que esto acima do nvel de classes, objetos isolados
ou de componentes. As vantagens ao se utilizar padres de projeto so:
ter um vocabulrio comum para a discusso de problemas e solues de projeto (Gamma et al.
1995);
facilitar documentao e manuteno da arquitetura do software (Buschmann et al., 1996);
auxiliar o projeto de uma arquitetura com determinadas propriedades (Buschmann et al., 1996).
A idia do padro MVC desacoplar ao mximo a apresentao da aplicao (view) da lgica do
negcio (business model). Muitos sistemas tornam-se complexos, pois misturam cdigo da apresentao
com o cdigo da lgica do negcio. Qualquer mudana requerida pelo usurio na forma de
apresentao das informaes exige tambm mudana na lgica do negcio. A camada de
apresentao envolve interfaces e tambm relatrios.
Atualmente, freqente a utilizao de diversas interfaces para um mesmo negcio em funo do tipo
de usurio ou do tipo de dispositivo de sada. Se para cada tipo de usurio/tipo de dispositivo de
sada fizermos uma lgica de negcio diferente, estaremos replicando cdigo desnecessariamente. Por
exemplo, uma aplicao que mostra o extrato bancrio de uma conta corrente em diversos tipos de
dispositivo tais como PC, caixa automtico, Palm e celular. A lgica do negcio sempre a mesma,
juntar as transaes executadas em uma conta em um perodo, mudando apenas a forma de mostrar
os dados.
O padro MVC prope a diviso da aplicao em trs partes (ou camadas):
Modelo do negcio (model): contm os dados do negcio e as regras do negcio que ditam o
acesso e a modificao dos dados. De forma mais prtica, encapsula os dados e os
comportamentos do negcio e salva os mesmos sem se preocupar em como sero mostrados.
Viso (view): responsvel pela interao com o usurio e por apresentar as diversas vises que
dos dados do negcio. No se preocupa em como os dados foram obtidos, apenas em apresent-
los.
Controle (controller): comanda o fluxo de obteno, encaminhamento e apresentao das
informaes fazendo a intermediao entre as camadas de viso e de modelo.
A Figura 25 ilustra o modelo MVC. H duas formas bsicas, na primeira (a) os eventos/respostas da
interface so tratados diretamente pela camada de viso e na segunda, pelo controle que ento
seleciona a viso apropriada. O controle interpreta os eventos e informaes fornecidas pelo usurio e
chama as aes que podero mudar o estado do modelo do negcio. Em seguida, as alteraes do
modelo so retratadas pela camada da viso podendo ter o controle como intermedirio ou no.
Normalmente, h um controlador para cada caso de uso do modelo do negcio.
36

Figura 25. Modelo MVC nas duas formas possveis.
O modelo MVC bastante utilizado em aplicaes WEB. Um servio pode ser chamado a partir de
diferentes clientes tais como celulares, PCs e Palms. A lgica do negcio, no entanto, permanece a
mesma independente do cliente. Normalmente, nas aplicaes WEB o servidor escolhe a viso mais
apropriada como mostra a Figura 26. Observar que os servidores no so necessariamente mquinas
distintas. Existe um framework chamado Struts que diminui o esforo de desenvolver uma aplicao
Web segundo o padro MVC. Framework uma coleo de interfaces e classes para auxiliar o
desenvolvimento e manuteno de aplicaes.

Figura 26. Padro MVC numa aplicao WEB.
Viso
Controle Modelo do
negcio
Eventos de interface,
entrada de informaes
Estado
modelo
Eventos e respostas
gerados pelo modelo
aes
Viso
Controle Modelo do
negcio
Estado
modelo
Eventos e respostas
gerados pelo modelo

aes
Eventos de interface,
entrada de informaes
Viso selecionada
(a)
(b)
Cliente HTML
Cliente Celular
Cliente Palm
Controlador
Modelo do
negcio
Servidor web Servidor de aplicao
37
3 PADRO OBSERVADOR
O objetivo do padro observador (Gamma e co-autores, 1995, pg. 294) reduzir o acoplamento entre
classes. Podemos utilizar este padro em conjunto com o MVC para desacoplar as classes da camada
de viso das do modelo. Este o desacoplamento mais importante, pois separar as classes de controle
das de viso nem sempre uma tarefa evidente.
Suponha que os dados do modelo devem ser vistos de vrias maneiras (por meio de diferentes
interfaces), mas de maneira sincronizada, ou seja, cada mudana nos dados do modelo deve ser
refletida igualmente em todas as interfaces. Neste caso o padro observador til, pois as classes do
modelo no necessitam saber quantas e quais classes da camada de viso dependem delas.
Segundo (Gamma et al., 1995), o padro observador til nas situaes seguintes:
Quando uma modificao em um objeto implica modificaes em outros e no se sabe quantos
objetos precisam ser modificados.
Quando um objeto deve ser capaz de notificar outros objetos, mas sem pressupostos sobre os
objetos a serem notificados.
4 CLASSES DE ANLISE
Em um diagrama de classes so definidas as classes de objetos, suas operaes e atributos e as relaes
entre classes. A dificuldade que no h mtodo ou receita para escolher as classes de um sistema.
uma tarefa que depende em grande parte da experincia do desenvolvedor.
Nas fases iniciais do projeto, as classes so chamadas de classes candidatas ou de anlise, pois h
grande probabilidade que mudem ao longo do projeto. Com base no padro de projeto MVC, uma
primeira aproximao das classes necessrias ao sistema pode ser feita. Antes de explicar como faz-
la, apresenta-se a notao de classes e alguns esteretipos de classes.
4.1 Notao UML para Classes
Uma classe representada por um retngulo dividido em trs compartimentos como ilustra a figura
27. Os compartimentos de atributos e mtodos so opcionais (figura 28). Um esteretipo define um
tipo para a classe.

Figura 27: notao para classe.




Figura 28: notao de classe sem atributos e mtodos.
4.1.1 Atributos
A sintaxe para declarao de um atributo em UML segue o formato:
atributos
mtodos

<<esteretipo>>
NomeClasse

38

[<visibilidade>]<nome>[<multiplicidade>]:[<tipo>][=<valor inicial>]

<visibilidade>:
+ pblico, todas as classes tm acesso;
- privada, somente mtodos definidos na classe podem v-lo;
# protegido, mtodos definidos na classe e nas classes derivadas podem v-lo;
~ pacote, visvel dentro das classes de um pacote.
<nome>: nome do atributo
<multiplicidade>: por exemplo, valores[5] ou matriz[4, 6]
<tipo>: pode-se utilizar os tipos da linguagem de implementao. Por exemplo, char, float ou int.
<valor inicial>: valor inicial para o atributo que respeite o tipo de dado.

Exemplos
- nome: String
- sexo: char=f
+ cdigo: int=20
4.1.2 Mtodos
Sintaxe para declarao de um mtodo em UML:

[<visibilidade>]<nome>(<lista argumentos>):[<retorno>]

<visibilidade>:
+ pblico, todas as classes tm acesso;
- privada, somente mtodos definidos na classe podem v-lo;
# protegido, mtodos definidos na classe e nas classes derivadas podem v-lo;
~ pacote, visvel dentro das classes de um pacote.
<nome>: nome do mtodo
<lista de argumentos>: (<nome_argumento>:<tipo>, ..., <nome_argumento>:<tipo>). Por exemplo,
(nome:String, idade: int)
<retorno>: tipo do dado retornado. Pode-se utilizar os tipos da linguagem de implementao. Por
exemplo, char, float ou int.

Exemplos
- calcularIdadeEmMeses(Data dataNasc): int
+moverPara(x:int, y:int):void
4.1.3 Categorias de responsabilidades: esteretipos
De maneira geral, um esteretipo deixa clara a funo de um componente em um diagrama.
possvel definir seus prprios esteretipos o que permite estender a UML. No diagrama de classes h
trs esteretipos bastante utilizados que designam a responsabilidade das classes:
<<entidade>> ou <<entity>>
<<controle>> ou <<control>>
<<fronteira>> ou <<boundary>>
Estes esteretipos so oriundo do trabalho de Ivar Jacobson (1992) sobre Anlise de Robustez.
Basicamente, a anlise de robustez permite determinar preliminarmente as classes de anlise
baseando-se nas descries dos casos de uso.
39
Classes entidade
utilizado em classes que armazenam informaes do domnio a longo-prazo. Objetos destas classes
so normalmente persistentes, mas no uma regra geral. Frequentemente estas classes se encontram
na camada do modelo, por isso no dependem (ou ao menos no deveriam depender) do contexto
onde o sistema est inserido. Pode tanto refletir uma entidade do mundo real ou uma entidade
necessria ao funcionamento interno do sistema. Classes com este esteretipo podem ser
representadas pelo cone alternativo
2
da figura 29.




Figura 29: cone alternativo para classes <<entidade>>.
Classes de fronteira
utilizado em classes que realizam a interao entre sistema e ator (humano ou no). So classes que
dependem do contexto onde o sistema est inserido, dado que o contexto dado justamente pelas
interaes com o mundo externo. Classes de fronteira representam, por exemplo, protocolos de
interao com outros sistemas, interfaces com usurios, interao entre sistema e dispositivos. Classes
com este esteretipo podem ser representadas pelo cone da figura 30.
Segundo (Jacobson e co-autores, 2002), se uma classe <<fronteira>> j foi designada para um ator
humano, o desenvolvedor deve tentar reutiliz-la para minimizar o nmero de janelas que o ator
utiliza.




Figura 30: cone alternativo para classes <<fronteira>>.
Esteretipo de controle
utilizado em classes que encapsulam o controle/lgica de um caso de uso, ou seja, aquelas que
comandam a execuo de um caso de uso fazendo a ligao das classes de fronteira com as de
entidade. Normalmente so dependentes da aplicao. Classes com este esteretipo podem ser
representadas pelo cone da figura 31.
Em alguns casos, a lgica do caso de uso pode ser muito complexa e exigir mais de uma classe de
controle. Em outros, a lgica comanda pelo ator e neste caso, a classe de controle e de fronteira
podem ser unificadas como fronteira.




Figura 31: cone alternativo para classes <<controle>>.

2
Robustness Analysis Icon
40
4.2 Linhas Mestras
Para identificar as classes candidatas seguindo o padro de projeto MVC, executar os passos
seguintes:
Definir uma classe de fronteira para cada par ator-caso de uso
Definir uma classe de controle para cada caso de uso
Definir classes de entidade: procurar substantivos nos casos de uso e pontos onde h um conjunto
de dados que possuem unidade (objeto).
Estas linhas so extremamente gerais e, portanto, sujeitas a adaptaes em funo do problema em
mos. Por exemplo, se a fronteira com um ator for extremamente simples pode-se conjugar controle e
fronteira. Se o controle para todos os casos de uso for extremamente simples, pode-se coloc-los numa
s classe de controle.
5 EXEMPLO
O levantamento de classes de anlise mostrado por meio de um exemplo didtico cujo enunciado o
seguinte:
Um meteorologista necessita de um programa simples que faa converses de temperaturas
em graus Celsius para Fahrenheit. Ele deseja armazenar as 10 ltimas converses realizadas,
denominadas no seu todo histrico, e visualiz-las constantemente numa janela
independente daquela destinada a fazer a converso. Se por acaso o usurio fechar a janela do
histrico, ele deve ter algum modo de reabri-la. Uma converso formada pela data, hora,
valor em Celsius e em Fahrenheit.
A partir do enunciado, elaborou-se o diagrama de casos de uso da figura 53. Notar que no
preocupao com a ordem de execuo dos casos de uso e com o fluxo de dados (o fato de consultar
histrico utilizar os mesmos dados manipulados por atualizar histrico).

Figura 32: Diagrama de casos de uso para conversor de graus Celsius para Fahrenheit.
TABELA 5: DESCRIO DO CASO DE USO CONVERTER.
Nome do caso de uso Converter Celsius Fahrenheit
Descrio
Permite ao meteorologista realizar vrias converses de
Celsius para Fahrenheit e as armazena em um histrico.
Ator Envolvido Meteorologista
Pr-condies Sesso iniciada
Ps-condies Converso realizada
Fluxo Bsico
Ator Sistema
Solicitar converso de uma
temperatura em graus Celsius

{Obter valor}
41
Solicita o valor a ser convertido
Fornece valor a ser convertido

Obtm o valor
{Validade valor entrada}
Realizar a converso
Executar subfluxo Atualizar Histrico
Mostrar temperatura em Fahrenheit

Se o usurio deseja continuar, voltar ao ponto {Obter
valor}; se no, o caso de uso termina.
Fluxos alternativos e subfluxos
A1: em {Validade valor entrada}
Se temperatura no for numrica voltar ao ponto
{Obter valor}
S1: Atualizar Histrico
Armazena uma converso de Celsius para Fahrenheit
incluindo o valor em Celsius, o equivalente em Fahrenheit,
data e hora da converso.
TABELA 6: DESCRIO DO CASO DE USO CONSULTAR HISTRICO
Nome do caso de uso Consultar Histrico
Descrio
Permite ao usurio visualizar as dez ltimas converses
realizadas.
Ator Envolvido Meteorologista
Pr-condies Sesso iniciada
Ps-condies Histrico mostrado ao meteorologista.
Fluxo bsico
Ator Sistema
Solicitar visualizao

{nenhuma converso realizada}
Sistema busca as ltimas dez converses realizadas
ou as existentes
Mostra o histrico de converso

{fim}
O caso de uso termina.
Fluxos alternativos
A1: em {nenhuma converso
realizada}
Se no houver converses no histrico mostrar
mensagem nenhuma converso realizada at o
momento e ir para o ponto {fim}

Aps a elaborao do diagrama de casos de uso, fez-se uma primeira tentativa de identificar classes de
anlise seguindo as linhas mestras. Na figura 33, as linhas mestras foram seguidas risca.
42
class Classes de anlise (levantamento)
IUConversao
Ctrl Conversao
Hi stori co
ConversaoCF
IUHistori co
Ctrl Hi stori co

Figura 33: Levantamento das classes de anlise.
6 EXERCCIOS
1. Considere um caso de uso chamado efetuar operaes aritmticas para uma calculadora. Analise
as responsabilidades e o comportamento de uma classe de controle para este caso de uso frente a
duas implementaes para a classe <<entidade>> calculadora cujo comportamento descrito
abaixo:
a. capaz de efetuar operaes binrias, por exemplo, somar(2, 3), subtrair (5, 4), etc.
b. capaz de avaliar sintaticamente e executar expresses aritmticas, por exemplo, 2 + 3/5.
2. Qual o auxlio trazido pelo padro observador ao modelo MVC?
3. Fazer o levantamento das classes candidatas para os exerccios do captulo anterior (pg. 31):
a. Biblioteca
b. Jogo da forca e da velha
c. Escritrio de advocacia
43
V ESTUDO DA INTERAO ENTRE OBJETOS
O projeto de um sistema pode ser visto como sucessivos refinamentos de diviso de responsabilidades.
Nos casos de uso, so identificadas as funcionalidades do sistema separando-as do que externo ao
mesmo. Em seguida, so levantadas as classes de anlise, o que representa uma primeira tentativa de
identificar quem dentro do sistema far o qu para que os casos de uso se concretizem. Os diagramas de
interao constituem um passo importante nesta diviso, pois detalham como os objetos das classes de
anlise e, por consequncia, quais operaes cada um deve realizar. Se um caso de uso possui vrios
fluxos, pode ser til criar um diagrama de interao para cada cenrio. Os diagramas de interao mais
utilizados so o de sequncia e o de comunicao (ex-colaborao).
Diagramas de interao so usados tanto na anlise quanto no projeto. Na anlise as comunicaes entre
objetos so mais abstratas, no importando muito os argumentos e valores retornados. No projeto, o
detalhamento maior
1 DIAGRAMA DE SEQUNCIA
Relembra-se que cada caso de uso representa uma funcionalidade do sistema vista da perspectiva de
um ator. Um caso de uso pode apresentar diversas possibilidades de execuo visto que h fluxos
primrios (fluxo normal de eventos) e alternativos (o que fazer se). Estes fluxos so documentados
textualmente ou na forma de uma tabela ator x sistema.
Cenrios so utilizados para identificar como uma sociedade de objetos interage para realizar um caso
de uso. Cenrios documentam as responsabilidades, ou seja, como as responsabilidades especificadas
nos casos de uso so divididas entre os objetos do sistema. Portanto, um cenrio uma instncia de
um caso de uso: um caminho entre os muitos possveis. Cenrios podem ser representados por
diagramas de seqncia e pelos diagramas de colaborao.
Um diagrama de seqncia representa os atores e objetos envolvidos num cenrio
e a seqncia de troca de mensagens ao longo do tempo para realizar o cenrio.
Um diagrama de seqncia permite identificar os mtodos e atributos de cada classe assim como as
responsabilidades de cada classe na realizao de um caso de uso. Os elementos bsicos de um
diagrama se seqncia so
Atores
Objetos
Linha do tempo (uma para cada objeto e ator)
Comunicao entre ator e objeto ou entre objetos
Interpretao das mensagens: por exemplo, evento do sistema operacional ou de uma interface,
envio de mensagem ou chamada de mtodo
44
sd Interao
usuri o
:A :B
sncrona
resposta
assncrona

Figura 34: exemplo de diagrama de seqncia.
1.1 Tipos de mensagem
H vrios tipos de mensagem que podem ser utilizados num diagrama se seqncia, sendo os mais
comuns os seguintes (figura 34):
Simples: quando o tipo de mensagem irrelevante ou ainda no foi definido.
Sncrona: quando enviada, o emissor fica bloqueado aguardando a resposta.
Assncrona: o emissor no bloqueia at que o receptor enviar resposta para continuar seu
processamento.
Retorno ou resposta: resposta mensagem sncrona; pode ser omitida
Uma mensagem definida sintaticamente por:
expresso-seqncia recorrncia: v := mensagem
Expresso-seqncia: um nmero seqencial de envio das mensagens. Por exemplo,
1: msg1
2: msg2
representando que a mensagem msg1 precede a msg2.
Pode-se utilizar nveis:
1.1: msg1
1.2: msg2
representando que msg1 e msg2 foram enviadas aps recebimento de uma mensagem 1.
Para representar mensagens concorrentes, pode-se utilizar letras:
1.1a: msg1
1.1b: msg2
significando que msg1 e msg2 so enviadas concorrentemente.
Recorrncia: indica um envio condicional ou uma repetio. Zero ou mais mensagens so enviadas
dependendo da condio envolvida. As opes so:
*[clusula-iterao] ou
[guarda]
No h sintaxe rgida definida pela UML, a clusula de interao e a condio de guarda podem ser
especificadas em pseudocdigo ou na linguagem alvo. Exemplos:
objeto
Linha da
vida
ativao
45
[x > y] msg: mensagem msg enviada somente se x > y
*[i:=1..10] msg: mensagem msg enviada 10 vezes.
*[x > 0] msg: enquanto x for maior que zero enviar mensagem msg.
Receber valor de retorno: possvel receber um valor de retorno e atribu-lo a uma varivel.
x:=obter()
1.2 Linha da Vida
So linhas verticais que representam o tempo de vida de um objeto. Um X na linha denota o fim da
existncia do objeto. Objetos no topo do diagrama so considerados criados desde o incio.
1.3 Ativao
Uma ativao (um retngulo sobre a linha da vida) representa o perodo durante o qual um objeto est
em execuo diretamente ou indiretamente. Direta, se estiver executando um mtodo ou indireta, se
chamou um mtodo e est bloqueado aguardando o retorno. A ativao mostra a durao das
operaes nos objetos e o fluxo de controle entre o objeto invocador e o invocado.
1.4 Alt
Equivale ao if-else.
sd Interao
usuri o
:A :B
alt verifica x
[x>0]
[x<=0]
x
msg1
msg2

Figura 35: exemplo de alt no diagrama de seqncia.
O mesmo comportamento pode ser representado atravs de uma condio de guarda in-line como
ilustra a figura 36.
46
sd Loop
usuri o
:A :B
loop notificaes
[x >= 0]
x
msg1
msg2
x
sd Interao
usurio
:A :B
x
[x>0]: msg1
[x<=0]: msg2

Figura 36: exemplo de condio de guarda no diagrama de seqncia.
1.5 Opt
Opcional: equivale ao if (sem else).










Figura 37: exemplo de opt.
1.6 Loop
Permite representar laos.









Figura 38: exemplo de loop em diagrama de seqncia.
sd Opt
usuri o
:A :B
opt testa x
[x > 0]
x
msg1
msg2
msg3
47
sd Loop in-line
usuri o
:B :A
x
[x>=0]: * x= msg1 :i nt
Repeties tambm podem ser representados inline. Na Figura 39 est representado que a mensagem
msg1 enviada vrias vezes (*) enquanto x for maior ou igual a zero. Ao fazer a chamada msg1, o objeto
da classe A recebe como resposta um inteiro e o armazena na varivel x.









Figura 39: exemplo de loop inline.
A sintaxe especificada no UML Superstructure (7/2/2005) para loop definida como:
loop[( <minint> [, <maxint> ] )]
<minint> ::= natural no negativo
<maxint> ::= natural no-negativo maior ou igual <minint> | * significa infinito.
Se somente <minint> for definido, significa que <minint> = <maxint> = <inteiro>.
Se somente loop for definido, ento representa um lao com limite superior infinito e limite inferior
igual a zero.
Exemplo:
loop[(0, 10)] define um lao com 11 repeties
1.7 Ref
Permite fazer referncias a outros diagramas. Observar no diagrama referenciado que o resultado
retornado foi representado como um objeto. Para fazer referncia ao diagrama em questo, basta
colocar um fragmento ref inline. O fragmento ref substitudo por uma rplica do diagrama
referenciado onde os argumentos substituem os parmetros.









Figura 40: exemplo de referncia a outro diagrama (ver figura 41)
48










Figura 41: exemplo de diagrama referenciado.
1.8 Criar e destruir
possvel mostrar a criao e a destruio de objetos num diagrama de seqncia. Objetos que so
criados e destrudos so chamados de transientes.












Figura 42: exemplo de objeto transiente (CartItem).
1.9 Linhas Mestras
Um diagrama de seqncia deve ter certa distncia do cdigo fonte, no preciso representar todos os
detalhes do cenrio. Algumas dicas:
mant-lo simples;
condies de guarda: se forem poucas devem ser colocadas em um s diagrama, caso contrrio
fazer um novo diagrama s para mostr-las;
os diagramas podem ser ligados entre si (ref).
Em algumas ferramentas possvel gerar automaticamente a primeira verso do diagrama de seqncia. Por exemplo, no
Rational Rose, se o fluxo de evento foi definido, basta clicar com o boto da direita em cima do caso de uso e escolher generate
sequence diagram.
sd Verificar x(int x):Resultado
:A Resul tado :B
alt trata x
[x < 0]
[x > 0]
[x = 0]
msg1
setTo(NEGATIVO)
msg2
setTo(POSITIVO)
msg3
setTo(ZERO)
49
2 DIAGRAMA DE COMUNICAO
Diagrama de comunicao (antes da verso 2.0 era chamado colaborao) outra forma de
representar um cenrio: contm as mesmas informaes que o diagrama de seqncia, mas no
considera a dimenso temporal. Alguns autores recomendam utiliz-lo para analisar a colaborao
das classes de realizao de um caso de uso (Jacobson e co-autores, 1999), pois facilita a identificao
das classes que colaboram de forma mais prxima e, por conseqncia, a identificao de pacotes de
anlise.
Visual Paradigm: Para gerar automaticamente este diagrama a partir do de seqncia clicar com o boto da direita no pano
de fundo do diagrama de seqncia e escolher to collaboration diagram.
No diagrama de comunicao, a ordem de envio das mensagens dada por nmeros seqenciais (
possvel utiliz-los no diagrama de seqncia tambm). A figura 43 mostra um exemplo de diagrama
de colaborao. Observar a restrio {transient} junto ao objeto Transaction indicando que ele criado
e destrudo na interao.











Figura 43: diagrama de comunicao.
A figura 44 mostra o diagrama de seqncia equivalente ao de comunicao da figura 43.












Figura 44: diagrama de seqncia equivalente.
50
sd anlise casos de uso
:meteorologi sta
:IUConversao :CtrlConversao :Historico :ConversaoCF
sol i ci tar val or Cel si us
val or Cel si us?
c
c
converter val or c
guardar conversao
val or Fahrenhei t
mostrar val or converti do
val or Fahrenhei t
3 EXEMPLO
Retoma-se o exemplo do conversor de graus Celsius para Fahrenheit. O cenrio fluxo bsico +
subfluxo atualizar histrico mostrado na figura 45. Observar que o diagrama bastante informal,
sem preocupao com argumentos de mtodos, criao e destruio de objetos, armazenamento em
banco de dados ou sistema de arquivos e se h lugar ou no no histrico para guardar uma nova
converso.


















Figura 45: diagrama de seqncia para o caso realizar converso C > F.
4 PACOTES
A estrutura de uma aplicao dada pelas classes e suas relaes. Classes podem ser agrupadas em
pacotes de anlise para facilitar o manuseio do modelo de anlise (lidar com partes menores) ou
medida que o modelo de anlise aumenta e precisa ser decomposto. Alm de identificar os pacotes de
anlise, preciso definir os servios que cada um deles fornece.
51
sd Exerccio
:C :A :B
3.1 *[i:=1..2] m()
3.1.1 *[i :=1..3] m2( )
5 EXERCCIOS
1. No diagrama de seqncia abaixo qual a ordem das mensagens enviadas (m1 e m2):












2. Desenhe o diagrama de comunicao equivalente ao diagrama de seqncia anterior.
3. Faa um diagrama de seqncia para representar um cliente que efetua uma retirada R$50,00 em
um caixa automtico. A retirada deve ser debitada da conta corrente do cliente.
4. Complete o exerccio anterior para permitir saques somente quando h saldo na conta corrente e
se o valor do saque for inferior a R$1.000,00.
5. Um casal tem trs filhos. Cada filho tem seu quarto. Para facilitar as tarefas matinais, o casal
dispe de um relgio no quarto capaz de enviar sinais de rdio aos relgios dos filhos, mas no de
receber. Ao anoitecer, o casal seta no relgio deles o horrio para despertar, idntico para todos os
filhos. Ao amanhecer, na hora marcada, o relgio do casal envia o sinal de despertar para cada um
dos relgios dos filhos. Desenhe o diagrama de seqncia.
6. Suponha o caso de uso apresentado em seguida resultante da fase de anlise de requisitos. Na fase
de anlise (realizao dos casos de uso) sua descrio pode ser detalhada sem se preocupar
profundamente com a implementao. Descreva a realizao do mesmo fazendo os itens abaixo:
a. Detalhe a descrio do caso de uso considerando que ele ser voltado a funcionar na web. Os
clientes devem ter meios de realizar reservas on-line:
i) Podem escolher a categoria de veculo ao invs de visualizar todos (passo 5).
ii) Podem participar de um programa de fidelidade e, neste caso, informaes de cadastro
(ou perfil) so utilizadas para pr-popular os formulrios.
iii) Ao confirmar a reserva, o sistema deve mostrar os dados da mesma.
iv) Se o usurio informou um endereo de e-mail vlido, o sistema envia-lhe a confirmao
por email.
b. Identifique as classes de anlise candidatas.
c. Filtre as classes de anlise reduzindo (possivelmente) o nmero de classes candidatas
d. Identifique e descreva as responsabilidades de cada classe e possveis relacionamentos entre
elas
e. Estude a interao entre os objetos das classes
f. Identifique possveis atributos para as classes

52
Sistema para locao de carros on-line (web)
NOME: Reservar veculo
DESCRIO: Este caso descreve como um cliente usa o sistema para reservar um veculo.
PR-CONDIES: o cliente est conectado ao sistema.
PS-CONDIES: o cliente realiza uma reserva ou no.
REQUISITOS NO-FUNCIONAIS: servio acessvel pela WEB.
FLUXO BSICO DE EVENTOS
1. O caso de uso inicia quando o ator cliente escolhe a opo de reservar veculo.
2. O sistema solicita ao usurio os locais, datas e horrios de retirada e de devoluo do
veculo.
3. O cliente informa os locais, datas e horrios de retirada e de devoluo do veculo.
4. O sistema pergunta ao usurio qual o tipo de veculo desejado.
5. O sistema apresenta todas as opes de tipos de veculo disponveis no local de retirada para
a data e horrios escolhidos.
6. O cliente escolhe um veculo para locar.
7. O sistema solicita informaes de identificao ao cliente (nome completo, telefone, e-mail,
bandeira do carto de crdito, data de expirao, etc.).
8. O cliente fornece as informaes de identificao solicitadas.
9. O sistema apresenta informaes sobre seguros e protees e pergunta ao cliente para aceitar
ou rejeitar cada oferta.
10. O cliente informa suas escolhas.
11. O sistema solicita confirmao da reserva.
12. O cliente aceita a reserva.


53
VI RELAES ENTRE CLASSES DE ANLISE
O diagrama de classes um dos principais diagramas da UML, representa a estrutura do sistema
(elementos que foram selecionados para fazer parte do sistema). A partir dele, por exemplo, o
esqueleto do cdigo fonte pode ser gerado automaticamente. Neste captulo so apresentadas as
relaes mais usuais para a fase de anlise. Posteriormente, apresentam-se relaes mais prximas da
implementao e, portanto, mais adequadas fase de projeto.
O comportamento requerido do sistema alcanado pela colaborao entre objetos. O diagrama de
classes fornece uma representao esttica da colaborao por meio de relacionamentos. Os
relacionamentos so utilizados no diagrama de classes que refinado incrementalmente (modelo do
domnio, anlise e, posteriormente, no projeto).
So apresentadas as seguintes relaes:
associao (mais comum),
agregao (um tipo de associao),
generalizao/especializao
1 ASSOCIAO
uma relao entre duas classes significando que os objetos destas classes possuem uma ligao. Por
exemplo, a figura 46 representa um professor leciona uma disciplina.





Figura 46: Exemplo de associao.
possvel designar que uma quantidade objetos de uma classe se relacionam com uma quantidade de
objetos de outra classe por meio da notao de multiplicidade (tabela 7). As multiplicidades so
colocadas nos extremos das linhas que representam as relaes.
TABELA 7: MULTIPLICIDADE DE RELAES
Repr Significado
1 Exatamente uma
0.. * Zero ou mais
* Zero ou mais
1.. * Uma ou mais
0..1 Zero ou uma
5..8 Intervalo especfico (5, 6, 7, or 8)
4..7,9 Combinao (4, 5, 6, 7, or 9)
Por exemplo, a figura 53 interpretada como um professor leciona uma ou mais disciplinas, sendo
ilimitado o nmero mximo de disciplinas. Observar que no lado do Professor a multiplicidade
igual a 1, ento a participao de objetos Professor no relacionamento leciona obrigatria, ou seja, um
professor s pode existir se estiver associado a uma disciplina.
Professor


Disciplina


leciona
54





Figura 47: Exemplo de multiplicidade em associao.
Navegabilidade
As associaes podem opcionalmente direcionadas. No exemplo abaixo, a partir de um professor
pode-se chegar a uma disciplina, mas o caminho inverso no possvel o que indicado pelo X sobre
a associao.




Figura 48: associao unidirecional.
Para representar uma associao bidirecional, navegvel nos dois sentidos, utiliza-se uma flecha
bidirecional. Para facilitar a leitura, pode-se indicar a direo da mesma (tringulo ao lado do nome da
associao).




Figura 49: associao bidirecional.
Se no h definio sobre a navegabilidade pode-se deix-la no-especificada. Neste caso, no se deve
utilizar flechas. Por exemplo, a figura 50 representa uma associao 1:1 de navegabilidade no-
especificada.




Figura 50: associao no-especificada.
Papis
Podemos associar papis s associaes para clarificar as responsabilidades dos objetos participantes.
A figura 51 ilustra uma associao entre Empresa e pessoa. Para evitar um nome ambguo de
associao pela utilizao de papis. Por exemplo, o nome trabalha pode ser interpretado como:
pessoa trabalha para Empresa
empresa trabalha (presta um servio) para Pessoa;
O nome emprega pode ser interpretado como:
empresa emprega Pessoa;
pessoa emprega (contrata) Empresa
Assim, para representar os dois primeiros itens pode-se utilizar papis, a Empresa desempenha o
papel de empregador de Pessoa e Pessoa, empregado.
Professor


Disciplina


leciona
Professor


Disciplina


leciona
Professor


Disciplina


leciona
Professor


Disciplina


leciona
1..* 1
55

Figura 51: Papis nas relaes.
1.1 Associao reflexiva
Os objetos de uma classe podem se relacionar com objetos da mesma classe. Por exemplo, uma relao
do tipo pai-filho ou chefe-empregado cada objeto desempenha um papel diferente. Neste tipo de
associao freqente a utilizao de papis ao invs de nome de associao para evitar
ambigidades na leitura.
Na associao reflexiva da classe Pessoa (figura 52), a interpretao a seguinte: uma pessoa tem zero
ou um pai e uma pessoa pode ser pai de vrios filhos. A multiplicidade zero no papel filho permite
que mulheres e homens sem filhos no participem desta associao. A multiplicidade zero no papel
pai pode parecer estranha, pois todo filho tem um pai, porm, se colocarmos 1 na multiplicidade,
todos os pais do mundo teriam que ser representados no sistema.


Figura 52: Exemplos de associaes reflexivas.
Na associao reflexiva da classe Empregado (figura 52), a interpretao a seguinte: um empregado
que desempenha o papel de gerente tem zero ou mais subordinados. Pode parecer estranho um
gerente sem subordinados, mas se colocssemos 1 ao invs de zero na multiplicidade no lado do papel
subordinado, todo empregado teria que ter ao menos um subordinado. Portanto, este zero significa
que empregados que no desempenham o papel de gerente no precisam estar associados a
subordinados. No sentido contrrio, todo empregado est associado a exatamente um gerente. Neste
caso, define-se que um gerente subordinado a ele mesmo no nvel mais alto da hierarquia, por isso
podemos deixar multiplicidade igual a 1 no lado gerente.
1.2 Classes associativas
Quando uma relao associativa possui atributos prprios pode-se criar uma classe associativa. Estas
classes so teis quando queremos armazenar o histrico de uma associao (relacionamentos que
ocorrem e interessam serem salvos). No exemplo abaixo (figura 53) quando existir uma associao
entre uma instncia de aluno e uma de turma haver tambm uma instncia de inscrio para
armazenar o resultado escolar.

Pessoa


Empregado


0..*
0..*
filho
pai
gerente
subordinado
1
0..1
Empresa


Pessoa


empregador empregado
Empresa


Pessoa


Trabalha ou emprega ?
56

Figura 53: Exemplo de classe associativa.
Algumas caractersticas das classes associativas:
Classes associativas so comuns em relaes de multiplicidade *:*, embora no seja uma regra
definitiva.
A linha que representa a associao no nomeada, o nome da classe associativa deve ser
suficiente para identificar a relao.
Classes associativas podem estar relacionadas a outras classes.
1.3 Relaes Ternrias
possvel representar em UML relaes entre objetos de trs ou mais classes. No exemplo abaixo, est
representado o fato de um professor lecionar numa sala para vrios alunos (o professor sempre utiliza
a mesma sala).

Figura 54: exemplo de relao ternria.
Podemos ter classes associativas tambm nas associaes mltiplas. No exemplo abaixo, o jogador
participa de vrios times ao longo de uma temporada, para cada participao num time armazena-se
os dados de gols marcados, gols levados, vitrias e derrotas do time.
57











Figura 55: exemplo de relao ternria com classe associativa.
1.4 Levantamento das associaes
Normalmente as associaes vem as regras do negcio, dos requisitos funcionais e dos diagramas de
interao. Por exemplo, em uma universidade prtica comum que cada professor tenha entre zero e
quatro turmas. Em uma biblioteca, alunos no podem emprestar mais de quatro livros ao mesmo
tempo.

Figura 56: associao capturada a partir de uma regra do negcio.
Ao observar o diagrama de seqncia da converso de graus Celsius para Fahrenheit (figura 45, pg.
50), possvel identificar as seguintes classes esto de alguma forma associadas:
IUConverso e CtrlConverso
CtrlConverso e ConversoCF
ConversoCF e Histrico
O diagrama de classes de anlise pode ser enriquecido com estas relaes e com outras provenientes
do diagrama de seqncia do caso de uso Visualizar histrico produzindo o diagrama de classes de
anlise da figura 57. Observar que as associaes que envolvem classes de controle e de fronteira no
so nomeados, pois apresentam uma mesma semntica: comunicao.
Aluno


Livro

Empresta 0..4
0..1
58
class Classe
Janela
Boto
ComboBox
ScrollBar
3
1
1
1
0..1
1
class Classes de anlise (associaes)
ConversaoCF Ctrl Conversao
Hi stori co
IUConversao
:IUHi stori co Ctrl Hi stori co
0..10
pertence
1
1 1
1 1
1 1
1 1










Figura 57: classes de anlise do conversor Celsius-Fahrenheit com associaes.
2 AGREGAO
um caso especial de associao utilizada para representar relacionamentos de pertinncia (parte
de). Permite representar o fato que um objeto ou mais objetos de uma classe fazem parte de um
objeto de outra classe. Um exemplo tpico uma janela de interface com o usurio composta por
diversos botes, campos texto, scrolls bars, etc. A agregao representa uma ligao entre o objeto o
todo (a janela) e as partes (Boto, ComboBox, ScrollBar). Um comportamento que se aplica ao todo se
propaga as partes, por exemplo, ao movimentar a janela, todos seus elementos de deslocam tambm.















Figura 58: exemplo de agregao.
2.1 Notao
Podem-se incluir nomes, papis, multiplicidades e navegabilidades, enfim aceita todos os adornos de
uma relao de associao.
2.2 Multiplicidade
Frequentemente ser 1 do lado da classe todo visto que um objeto normalmente parte de um s
objeto. Porm, h diversas excees como o exemplo da figura 59. Nela representa-se que um time
composto por vrios jogadores (inclusive por nenhum) e que um jogador pode participar de vrios
59
class Classe
Time Jogador
* *
times. Observar tambm a representao da navegabilidade: do todo possvel alcanar todas as
partes e de cada uma das partes possvel alcanar o todo.








Figura 59: Exemplo de agregao com multiplicidade.
2.3 Tipos de agregaes
Nos exemplos anteriores, foram utilizados dois tipos de agregaes, de composio e de associao,
representadas respectivamente por losangos preenchidos e vazios.
Composio (composite aggregation)
uma agregao de fato, o todo composto pelas partes. Existe uma relao forte entre o todo e as
partes, pois quando o todo destrudo as partes tambm o sero, ou seja, a eliminao do todo se
propaga para as partes. De outra forma, o todo e as partes tm tempos de vida semelhantes.
Associao
uma forma mais branda de agregao, embora exista uma relao de composio os todos os
comportamentos so propagados para as partes. Por exemplo, uma equipe de futebol composta por
vrios jogadores pode deixar de existir, mas os jogadores continuam. A figura 60 mostra um exemplo
similar, onde uma turma composta por alunos (de 0 a 45). A turma pode ser destruda sem afetar a
existncia dos objetos alunos dentro do sistema.





Figura 60: Exemplo de agregao por associao.
No exemplo da figura 61, se destruirmos o cinema a bilheteria ser destruda. A coleo de filmes no
ter o mesmo fim.

Figura 61: Exemplo de agregaes por composio e por associao.
60
2.4 Levantamento
A identificao de agregaes pode ser feita a partir de:
decomposio: quando uma classe torna-se muita complexa ou extensa podemos dividi-la em
vrias classes que comunicam entre si. O risco perder a viso do todo.
composio: identifica-se um conjunto de objetos que reunidos formam um objeto maior. Por
exemplo, barra de rolagem, menu e text area compem uma janela.
partes comuns: se duas ou mais classes apresentam um conjunto de atributos semelhantes
podemos agrup-los num objeto desde que tenham uma identidade.

Figura 62: Exemplo de agregao a partir de partes comuns.
No exemplo do conversor Celsius-Fahrenheit, a associao entre a classe ConversoCF e Histrico
pode ser substituda por uma agregao por composio. Se o objeto histrico destrudo todas as
converses tambm o sero.










Figura 63: substituio da associao entre ConversoCF e Histrico por uma agregao.
3 GENERALIZAO
A relao de especializao utilizada quando um conjunto de classes compartilha comportamentos e
atributos, pode-se ento generaliz-las agrupando seus comportamentos e atributos comuns.
class Classes de anlise (associaes)
ConversaoCF Ctrl Conversao
Hi stori co
IUConversao
:IUHi stori co Ctrl Hi stori co
0..10
1
1 1
1 1
1 1
1 1
61
A relao de generalizao recebe muitos nomes, tais como herana e especializao. A leitura pode
ser feita, partindo-se da classe base em direo a derivada, como um tipo de, uma ou um.
Na figura 64, aluno (classe derivada) um tipo de pessoa (classe base).







Figura 64: exemplo de relao de generalizao/especializao.
A implementao da relao de generalizao ocorre pelo mecanismo de herana. Por herana, a
classe derivada incorpora os mtodos e atributos da classe base. A classe derivada pode incluir novos
mtodos e atributos e redefinir os mtodos herdados (polimorfismo de reescrita). Em UML quando
repetimos a assinatura de uma operao numa classe derivada significa que temos uma nova
implementao. No exemplo da Figura 65 o clculo do IPVA na classe derivada leva em conta a
quantidade de cavalos do carro.







Figura 65: Relao de generalizao/especializao com reescrita de mtodo.
3.1 Hierarquia de classes
Nas classes base colocamos os atributos e operaes que so comuns a todas as classes derivadas,
evita-se redundncia e facilita-se reutilizao. A figura 66 ilustra uma situao onde atributos e
operaes comuns s classes Aluno e Professor foram colocados na classe base Pessoa, desta forma
no preciso redeclar-las em cada uma das especializaes.
62

Figura 66: Exemplo de hierarquia de classes.
3.2 Levantamento de generalizaes
Basicamente, h duas maneiras de se identificar generalizaes:
Identificao de partes comuns: a partir de classes especficas tenta-se estabelecer classes
genricas.
Sntese de classes base: pode-se iniciar a concepo a partir de classes abstratas tentando
especializ-las.
3.3 Qualidade de uma classificao
Uma boa classificao estvel e extensvel.
Estvel: os critrios de classificao no mudam ao longo do tempo.
Extensvel: fcil de incluir novas classes derivadas na hierarquia.
No classificar os objetos em funo de critrios que caracterizam seus estados ou critrios muito
vagos como ilustra a figura 67. Ao tentar estender a hierarquia desta figura com uma janela do
tipo Dialog, torna-se evidente que o critrio de classificao no foi bem escolhido.


Figura 67: exemplo de taxonomia em funo de estados.
63
class Casa
Casa
Pessoa
Casa Pessoa
0..*
propri edade
1
+propri edade
1..*
+propri etri o
0..*
Dica
Uma boa relao de herana deve respeitar o princpio da substituio: qualquer instncia da classe
base pode ser substituda por uma instncia de uma classe derivada sem alterar a semntica de um
programa escrito para (em funo da) a classe base.
3.4 Herana mltipla
Uma classe derivada de mais de uma classe base. Ocorre perda conceitua,l pois uma classe base no
representa um caso geral completo da classe derivada, ela representa uma parte do conceito
representado na classe derivada. No exemplo abaixo, Cautomovel no uma generalizao completa
de Ccarro pois no leva em conta aspectos do carro ligados ao patrimnio.

Figura 68: Exemplo de herana mltipla (extrada da apostila do Paulo)
4 EXERCCIOS
1. Em relao aos relacionamentos abaixo responda:
a. Qual a representao mais correta a primeira ou a segunda relao? Por qu?
b. O que preciso mudar na segunda relao para representar que uma casa possui diversos
proprietrios ao longo do tempo?













64
2. Qual a diferena de interpretao entre as duas representaes? Qual seria mais indicada para um
tribunal regional eleitoral?











3. Represente um e-mail na forma de um diagrama de classes. Identifique os componentes
(destinatrio, assunto, etc.) e suas relaes (fazer o diagrama no editor).
4. Qual a diferena de interpretao entre os relacionamentos livro-sobrecapa e livro-pginas?

5. Todo aluno matriculado em trabalho de diplomao ser orientado por um professor. Alguns
professores orientam vrios alunos e outros, nenhum. Qual dos diagramas melhor representa esta
relao?

6. Construa uma hierarquia de classes para os seguintes tipos de obra: romance, livro de fico, livro
de auto-ajuda, gibi, rock, MPB, filme fico e comdia.
7. Um cliente pode fazer diversos contratos de locao de carros numa locadora de veculos. A
locadora aluga caminhes, carros de passeio categoria A, B e C e motos. Os contratos diferem em
valor e imposto segundo o tipo de veculo locado. Construa um diagrama de classes para
representar as classes e seus relacionamentos.
8. Retoma as classes de anlise e o diagrama de seqncia do exerccio 6 (pg. 51) e defina as relaes
entre as classes de anlise (arquivo disponvel na pgina do curso verso Enterprise Architect).




class eleies
Pessoa
Pessoa
el ei tor 0..*
vota >
candi datoPresi dente
0..1
el ei tor
0..*
vota >
candi datoPresi dente
0..1
65
VII PROJETO DE CASOS DE USO
De forma geral, a atividade de projeto de casos de uso a transformao das classes de anlise em
uma ou mais classes de projeto. A representao das classes na atividade de projeto muito mais
prxima da implementao, ou seja, leva em conta as tecnologias que so utilizadas na implementao
do sistema.
1 PROJETO
Resultados
Os resultados da atividade de projeto de casos de uso so:
Classes de projeto
Operaes e atributos de cada classe
Diagramas de interao para mostrar como as classes de projeto colaboram para realizar os
processos do negcio capturados nos casos de uso.
Arquitetura de software (SAD Software Architecture Document)
Interfaces com subsistemas especficos ou software de terceiros
Subsistemas
Mtodo
Criar realizaes de casos de uso: na anlise, as realizaes contm classes de anlise e objetos que
aparecem em diagramas de classes e de interao. No projeto, so utilizados praticamente os
mesmos diagramas, a diferena que as informaes so mais prximas da implementao.
Descrever interaes entre objetos e refinar diagrama de classes
Simplificar diagramas de seqncia utilizando subsistemas (opcional)
Descrever comportamentos associados persistncia
2 CLASSES DE PROJETO
Na atividade de anlise, ao construir os diagramas de interao (seqncia e comunicao),
considerou-se que os objetos estavam disponveis e persistidos, no havia preocupao com a criao
e destruio dos mesmos e nem em acess-los e associ-los a outros objetos. Na atividade de projeto,
estas questes devem ser levadas em conta. Alm disso, classes de anlise podem ser transformadas
em vrias classes de projeto, reduzidas a um mtodo de uma classe de projeto, suprimidas, etc.
Classes de Anlise x Projeto
Qual a diferena entre uma classe de anlise e uma de projeto?
Uma classe de projeto especificada na linguagem de programao alvo (tipos de dados,
operaes, atributos so definidos utilizando-se a sintaxe da linguagem de programao).
As visibilidades dos atributos e operaes de uma classe de projeto so especificadas na maior
parte das vezes.
66
As relaes entre classes num diagrama de classes de projeto influenciam diretamente na
implementao destas classes. Por exemplo, associaes e agregaes so mapeadas para atributos
das classes para que os objetos envolvidos possam se referenciar.
Operaes das classes de projeto so traduzidas de forma direta em cdigo.
3 ESTUDO DA INTERAO ENTRE OBJETOS
Esta seo exemplifica o estudo da interao entre objetos para realizar o caso de uso converso de
Celsius para Fahrenheit em uma aplicao desktop com interface textual. O intuito mostrar como
refinar um diagrama de classes a partir do detalhamento do diagrama de seqncia.
3.1 Realizao Converter Celsius-Fahrenheit desktop
O diagrama de seqncia representa o cenrio onde o meteorologista realiza vrias converses de
Celsius para Fahrenheit que so guardadas numa coleo denominada histrico. Ao decidir encerrar a
sesso, o histrico persistido em disco por meio de um objeto serializvel.
67
sd converter c-f
:meteorologi sta
:Historico
conv
:ConversaoCF
:IUConversao
:CtrlConversao
loop
[!FIM]
sol ici tarCel sius() :fl oat
Celsi us?
c
c
ConversaoCF(c)
adi ci onar(this)
mostrar(conv.getFahr())
conv.Fahr
sal var()
writeObject


























Figura 69: Diagrama de seqncia (converter Celsius-Fahrenheit textual).
Das colaboraes expressas na Figura 69, pode-se derivar o seguinte diagrama de classes de projeto.
68
class classes converter
boundary
IUConversao
~ mostrar(fl oat) : voi d
~ sol i ci tarCel si us() : fl oat
control
CtrlConversao
enti ty
ConversaoCF
- cel si us: fl oat
- Horari o: Date
+ getFahr() : fl oat
enti ty
Historico
+ adi ci onar(ConversaoCF) : voi d
- wri teObj ect() : voi d
i nterface
Serializable
1
i nstanti ate
1 1
i nstanti ate
1
1
i nstanti ate
1
0..10 {ordered}
1













Figura 70: Diagrama de classes de projeto (converter Celsius-Fahrenheit textual).
Observar que as associaes entre CtrlConversao e as demais classes foram transformadas em
dependncias. Deixou-se claro que Histrico implementa (realiza) uma classe de interface serializvel.
Histrico uma coleo ordenada de objetos ConversaoCF. Os atributos e operaes tambm
possuem tipos de dados compatveis com Java (a suposta linguagem de implementao) e
visibilidades. importante notar que as mensagens que chegam num objeto so transformadas em
operaes (ex. solicitarCelsius() transformada numa operao em IUConversao).
Neste exemplo didtico, as classes de anlise no sofreram grandes modificaes. Tambm no houve
necessidade de dividir o sistema em subsistemas ou pacotes.
4 REFINAR O DIAGRAMA DE CLASSES
A partir dos diagramas de seqncia de projeto, detalham-se as relaes do diagrama de classes.
Alguns refinamentos no diagrama de classes podem ser feitos em funo da implementao desejada.
4.1 Dependncia
Uma relao de dependncia indica que uma classe depende do auxlio de outra classe para
implementar seus comportamentos. um relacionamento utilizado prioritariamente na fase de
projeto. Dadas duas classes A e B, as dependncias possveis entre elas podem ser assim resumidas:
Varivel local: Classe A utiliza em alguma operao uma varivel de tipo B
Parmetro de operao: Classe A utiliza como parmetro de alguma operao cujo tipo B.
Instanciao: a Classe A instancia um objeto de B.
Para representar os tipos de dependncia ilustrados, esteretipos podem ser utilizados (figura 71).
69
class Dependncia
ClasseA
+ operacao(Cl asseC) : voi d
ClasseB
ClasseC
ClasseD
l ocal
parameter
i nstanti ate
class Classe
ClasseA ClasseB
1 1









Figura 71: Alguns tipos de dependncia.
4.2 Implementao de associaes e agregaes
No h diferena entre a implementao de uma associao e uma agregao. Portanto, o texto que
segue serve indistintamente para os dois tipos de relaes. Tambm no h diferenas significativas
entre uma agregao por associao e uma agregao por composio. Nesta ltima, a lgica da classe
todo deve garantir que os comportamentos se propagam em direo s partes sempre que necessrio.
Em uma composio, uma parte exclusiva do todo e, portanto, no deve participar de outras
agregaes.
Multiplicidade 1:1 e variaes
Associaes unidirecionais de multiplicidade 1:1 so de simples implementao: basta colocar um
atributo na classe origem da relao. Se a relao for bidirecional, coloca-se um atributo em cada uma
das classes que participam da associao.






Figura 72: Implementao de uma associao unidirecional de multiplicidade 1:1
O cdigo abaixo ilustra uma implementao possvel para a associao da figura 72.
1 class ClasseA {
2 Private ClasseB objB = new ClasseB(); // pode ser instanciado em outro local
3 // outros atributos
4 // mtodos
5 }

O cdigo abaixo ilustra uma implementao para uma associao bidirecional de multiplicidade 1:1.
1 class ClasseA {
2 Private ClasseB objB = new ClasseB(); // pode ser instanciado em outro local
3 // outros atributos
4 // mtodos
5 }
6 class ClasseB {
7 Private Classe objA = new ClasseA(); // pode ser instanciado em outro local
8 // outros atributos
9 // mtodos
70
class Professor
Professor Disciplina
0..1
l eci ona
0..5
class classes
Professor
Disciplina
1 *
10 }
Multiplicidade 1:* e variaes
Quando a multiplicidade mxima menor que infinito (e no muito grande) pode-se alocar espao na
instanciao do objeto do lado 1 e povoar o vetor neste instante ou posteriormente.





Figura 73: associao de multiplicidade 0..1:0..5
Por exemplo, para a associao representada na figura 73 as seguintes implementaes so possveis.
1 class Professor {
2 private Disciplina[] disciplinas = new Disciplina[5]; // aloca espao para 5 objs
3
4 public void adicionarDisciplinas(Disciplina[] disc){
5 // inicializar vetor disciplinas com parmetro disc
6 }
7 }

1 class Professor {
2 private Disciplina[] disciplinas = {
3 // instancia os objetos disciplina
4 new Disciplina(),
5 new Disciplina(),
6 new Disciplina(),
7 new Disciplina(),
8 New Disciplina(),
9 };
10 }
Quando multiplicidade mxima for igual a * (figura 74) recomenda-se utilizar uma coleo
parametrizada como ilustra o cdigo seguinte.








Figura 74: associao de multiplicidade 1:*
1 class Professor {
2 private Vector<Disciplina> disciplinas = new Vector<Disciplina>(4, 2);
3 public void adicionarDisciplinas(Disciplina[] disc){
4 disciplinas.add(disc[0]);
5 ...
6 }
7 }
Dica Enterprise Architect: para gerar cdigo nesta situao, em tools>options>Java>[Collection classes], definir Vector
como default collection class. Nas propriedades da associao, no lado target (*), colocar Member Type = Vector<Disciplina>.
71
class muitos para muitos
Proj eto Pessoa
+emprega
0..*
+parti ci pa
0..*
class associao reflexiva
Professor
Disciplina
1 *
+preRequisi to
0..*
+temPrerequi si to
0..*
Multiplicidade *:*
A implementao de associaes com multiplicidade *:* envolve a utilizao de colees. Para o
exemplo da figura 75, utilizou-se a coleo Vector. Em seguida, mostra-se o cdigo Java
correspondente.







Figura 75: Associao muitos para muitos.
1 public class Projeto {
2
3 public Vector<Pessoa> participa;
4 ...
5 }


1 public class Pessoa {
2 public Vector<Projeto> emprega;
3 ...
4 }
Associaes reflexivas
O mapeamento para Java de uma associao reflexiva no difere dos mapeamentos entre duas classes
distintas.










Figura 76: Associao reflexiva muito para muitos.
A implementao da classe Disciplina ilustrada no cdigo seguinte:
1 public class Disciplina {
2
3 public Vector<Disciplina> temPrerequisito;
4 public Vector<Disciplina> preRequisito;
5
6 ...
7 }
Classes associativas
Classes associativas podem ser transformadas em classes comuns e, a partir da, as associaes caem
nos casos anteriores. Por exemplo, a figura 77 ilustra um caso onde um projeto pode ter vrias pessoas
e uma pessoa pode participar de vrios projetos. Cada participao possui uma carga horria, data de
entrada no projeto e de sada.
72
class classe associativa
Proj eto
Pessoa
Participacao
- cargaHorari a: i nt
- dataEntrada: Date
- dataSai da: Date
+emprega
0..*
+parti ci pa
0..*
class classe associativa (proj )
Proj eto Pessoa Participacao
- cargaHorari a: i nt
- dataEntrada: Date
- dataSai da: Date
1
possui
0..* 1
parti ci pa
0..*












Figura 77: Classe associativa.
O diagrama anterior poderia ser representado da seguinte forma








Figura 78: Classe associativa transformada em classe normal.
A implementao correspondente ao diagrama da figura 78 ficaria:
1 public class Projeto {
2 public Vector<Participacao> m_Participacao;
3 ...
4 }

1 public class Pessoa {
2 public Vector<Participacao> m_Participacao;
3 ...
4 }

1 public class Participacao {
2 private int cargaHoraria;
3 private Date dataEntrada;
4 private Date dataSaida;
5 public Projeto projeto; // se relao for bidirecional
6 Public Pessoa pessoa; // se relao for bidirecional
7 ...
8 }
Agregao por composio
uma agregao de fato, a criao/alocao de um objeto feita dentro de outro. Existe uma relao
forte, pois quando todo destrudo as partes tambm o sero, ou seja, a eliminao do todo se propaga
para as partes. O todo e as partes agregado tm tempos de vida semelhantes.
73








Figura 79: Agregao por composio.
A seguir duas implementaes possveis para a composio da figura 79. Um histrico uma
agregao de URLS visitadas, portanto, uma vez que o histrico destrudo as instncias de URLs
visitadas tambm o sero. Em Java no h necessidade de destruir os objetos devido ao Garbage
Collection. Todos os objetos criados so eliminados da memria quando no so mais referenciados
por nenhuma varivel, portanto na implementao da agregao por composio no precisamos nos
preocupar com a igualdade dos tempos de vida do todo e das partes.
1 class URLVisitada {
2 private String url;
3
4 URLVisitada (String url) {
5 this.url = url;
6 }
7 }
8
9 class Historico {
10 // cria trs objetos da classe URLVisitada
11 private URLVisitada[] historico = { // poderia ser com alguma coleo
12 new URLVisitada("http://www.uol.com.br"),
13 new URLVisitada("http://www.terra.com.br"),
14 new URLVisitada("http://www.lemonde.fr"),
15 };
16
17 }
possvel implementar uma agregao com classes aninhadas, como ilustra o cdigo abaixo.
1 class Historico {
2 // como private, a URLVisitada s pode ser instanciada dentro do escopo do todo
3
4 private class URLVisitada {
5 private String url;
6 URLVisitada (String umaURL) {
7 url = umaURL;
8 }
9 ...
10 }
11 private Vector<URLVisitada> historico = new Vector<URLVisitada>(4, 2);
12 ...
13
14 }
Agregao por associao
A implementao idntica a da associao.
Realizao
uma relao que indica que uma classe realiza ou segue o contrato definido por uma classe de
interface (no sentido Java). No diagrama de classes do conversor de Celsius-Fahrenheit, a classe
Histrico realiza a interface Serializable (implements).
class agregao por composio
HistoricoPagsWeb
URLVisitada
- URL: Stri ng 0..* 1
74













Figura 80: Relao de realizao.
A implementao em Java de uma realizao mostrada em seguida.
1 public interface Serializable {
2 ...
3 }

1 public class Histrico implements Serializable {
2 ...
3 }
5 SUBSISTEMAS
Aps estudar em detalhes a interao entre objetos e refinar o diagrama de classes, possvel
identificar subsistemas. Uma forma de identificar subsistemas observar comportamentos repetidos
nos diagramas de seqncia.
Subsistemas podem conter outros elementos de modelagem (ex. classes, pacotes) e apresentam
comportamento definido pelas interfaces que realiza. Em UML, subsistemas so representados como
pacotes, porm com um esteretipo <<subsistema>>.
Considere o exemplo onde durante a anlise foi identificada uma classe de anlise <<fronteira>> com
um sistema de faturamento. No projeto, esta classe se mostrou muito complexa e foi transformada
num subsistema onde vrias classes colaboram para realizar as responsabilidades previstas.
enti ty
Historico
+ adi ci onar(ConversaoCF) : voi d
- wri teObj ect() : voi d
i nterface
Serializable
i nstanti ate
1
75
















Figura 81: Exemplo de subsistema.
6 COMPORTAMENTOS ASSOCIADOS PERSISTNCIA
No interessante que objetos da camada de modelo conheam detalhes do banco de dados (ex.
conexo, tabelas, formato de registros). O problema que qualquer mudana no esquema do banco de
dados se reflete nos objetos do modelo. Para desacoplar os objetos da camada do modelo do banco de
dados possvel utilizar padres, tais como factory, que cria objetos do modelo j preenchidos com
informaes do banco de dados e da, um intermedirio que faz a ligao entre o(s) objeto(s) do modelo
e o banco de dados. Pode haver aumento da complexidade se o acesso ao banco de dados for simples.
Por outro lado diminui-se a dependncia do modelo em relao ao banco de dados. Dao pode ser feito
num nvel de granularidade maior, por exemplo, para manipular um conjunto de registros (viso) ou
uma tabela.
7 EXERCCIOS
1. Supor que no projeto do conversor de graus Celsius para Fahrenheit, a persistncia do Histrico
agora somente pelo tempo de uma sesso Web. A partir destas decises de projeto, uma nova
realizao de projeto do caso de uso Converter Celsius-Fahrenheit deve ser realizada. Supor o
cenrio onde o cliente faz o primeiro acesso ao sistema, logo uma sesso deve ser criada para
armazenar as converses realizadas daquele momento em diante. O diagrama de seqncia
parcial mostrado em seguida. Complete o diagrama de seqncia e refine o diagrama de classes.
class subsistema
i nterface
Faturamento
+ emi ti rFatura(Pessoa, fl oat) : voi d
Faturamento
Class3
Class4
cone para
esteretipo
<<Subsistema>>
76
sd proj eto casos de uso (web)
:meteorol ogi sta
j sp page
:IUConversao
servl et
:Ctrl Conversao
:ConversaoCF
pg. converso
cel si us
POST cel si us
ConversaoCF(cel si us)
deployment proj eto casos de uso
Servidor WEB
Navegador 1
Navegador 2
Navegador N-1
Navegador N
http
http http
http











2. Para o sistema de locao de veculos, caso de uso Reservar Veculo, supor que na fase de projeto
o arquiteto de software decidiu por uma arquitetura Web como mostra o diagrama de
implantao. Alm disso, o arquiteto de software optou por utilizar o conhecimento da equipe
desenvolvedora em Java, Java ServerPages, servlets e Java Script.












Com estas decises, o diagrama de seqncia reservar veculo foi parcialmente refinado, ou seja,
somente a parte de seleo de veculo por parte do cliente em um cenrio onde tudo funciona como
mostra a figura seguinte. No est includo o tratamento do perfil do cliente.


77
sd Reservar Veculo (prj )
:Cl i ente
:Fi l i al
:DataAccess
enti ty
:Veicul o
servl et
:Ctrl Reserva
j sp page
:MostraInventario
j sp page
:IUReserva
entity
:Inventari o
verifi ca se a fi l i al estar
aberta nos di as e horri os
sol ici tados
pg. de reserva
vec, IDFi l i al e datas
POST vei c, IDFi l ial e datas
popul ar(IDFi l i al)
buscarFi l i al (IDFil i al )
preencher(regDB)
val i dar(datas)
ok
popul ar(IDFi l i al , datas, catVei c)
buscarVei cul os(this)
preencher(regDB)
adici onar(vei cul o)
armazena col eo vei cs. na sesso
forward pg. i nventari o
mostrar i nventri o
mostra todos vecs. di sponvei s


A partir do diagrama de seqncia, refinou-se o diagrama de classes. A figura seguinte mostra apenas
as modificaes em relao ao diagrama de classes de anlise. Note que operaes foram adicionadas
e outras classes dependentes da arquitetura escolhida, tais como as pginas JSP.
78

class Classes proj eto (delta 1)
j sp page
IUReserva
jsp page
MostraInventario
servl et
CtrlReserva
entity
Filial
+ endereco
+ estadoFederecao
+ IDFil ial
+ popul ar(int) : voi d
+ preencher(regDB) : void
+ val idar(Date[2]) : bool ean
entity
Inventario
+ adi cionar(Vei cul o) : void
+ popul ar(int, Date[2], i nt) : void
enti ty
Veiculo
+ acessori o
+ categoriaVei c
+ estado
+ preencher(regDB) : void
DataAccess
+ buscarFil ial (i nt) : regDB
+ buscarVeicul os(Inventario) : regDB
*
1
1
1
i nstanti ate
instantiate


Pede-se:
Faa o diagrama de seqncia que mostre a efetivao da reserva por parte do usurio
Faa as mudanas necessrias no diagrama de classes.
(arquivo disponvel na pgina do curso formato Enterprise Architect)
79
VIII DIAGRAMA DE ESTADOS
1 ELEMENTOS BSICOS
Casos de uso e cenrios (diagramas de interao seqncia e comunicao) so utilizados para
descrever o comportamento do sistema. Frequentemente necessrio descrever o comportamento
interno de uma classe de objetos. No necessrio fazer diagramas de estado para todas as classes do
sistema, somente para as mais complexas onde o comportamento dos objetos modificado pelos
diferentes estados.
Um diagrama de estados mostra os eventos que causam as transies de estados e as aes/atividades
tomadas em conseqncia da transio. Condies de guarda podem ser associadas aos eventos, neste
caso, a ocorrncia do evento no garante a ocorrncia da transio, preciso que a condio de guarda
seja satisfeita para que ela ocorra.
Estado a situao na qual se encontra o objeto. Ao longo da sua vida, um objeto criado no
estado inicial, passa por estados intermedirios e morre no estado final. Estados recebem nomes
no particpio ou gerndio. Por exemplo, um objeto pode estar emprestado ou disponvel.
Evento (trigger event): algo que ocorre de forma instantnea no tempo e pode ocasionar uma
transio de estado em um objeto.
Ao: uma ao algo executado de forma imediata e atmica, ou seja, o tempo de execuo
muito pequeno e a ao no pode ser interrompida. Est frequentemente associada a uma
transio embora possa aparecer dentro de um estado relacionada s palavras-chave entry e exit ou
a transies internas a um estado.
Atividade: similar a uma ao, porm pode ser interrompida. associada a um estado por meio
da palavra-chave do.
Condio de guarda: expresso lgica que deve ser verdadeira na ocorrncia do evento para que a
transio ocorra.
1.1 Notao bsica
Diagrama de estados um grafo dirigido onde os nodos so os estados e os arcos, transies entre
estados como ilustra a figura seguinte.








Figura 82: elementos bsicos de um diagrama de estados.
A Figura 83 mostra o comportamento de uma janela que inicia no tamanho original e pode ser
minimizada, podendo trocar de estados vrias vezes, at ser fechada.
stm Abstrato
estado i ni ci al
Estado Estado 2
Fi nal
transi o evento [guarda] /ao
Transio externa
80
class Estaes do ano
Ini ti al
JanelaOriginal
JanelaMinimizada
Fi nal
boto mi n.
pressi onado
/mi ni mi zar
boto rest. pressi onado
/restaurar
boto fechar
pressi onado /destrui r
stm Livro aes nas transies
Initi al
Disponvel
Emprestado
Em reparo
Final
comprado
/Noti fi carInteressados
Emprestado
Col ocado em reparo
devol vido
/Notifi carInteressados
reparado
/Notifi carInteressados
reti rado do acervo













Figura 83: Diagrama de estados para uma janela (original, minimizada)
1.2 Ao nos estados (entry e exit)
Aes podem ser representadas nos eventos ou nos estados. Normalmente, a representao nos
estados permite simplificar o diagrama. Observar na figura 84 que toda vez que o Livro passa ao
estado Disponvel a ao de NotificarInteressados executada. Ao invs de repetir a ao em cada
transio, pode-se coloc-la no interior do estado associada palavra-chave entry (figura 85). Cada vez
que o estado Disponvel alcanado, executa-se a ao NotificarInteressados.















Figura 84. Aes nas transies que levam ao estado Disponvel.
81
stm Livro aes no estado
Ini ti al
Disponvel
+ entry / Noti fi carInteressados
Emprestado
Em reparo
Fi nal
comprado
emprestado devol vi do
reti rado do acervo
col ocado em reparo
reparado
stm Atividade no estado
Ini tial
Impressora ociosa
Sem papel
+ do / beep(tempo)
Imprimindo
i mpresso i ni ci ada
fi m i mpresso
falta de
papel
papel col ocado
i mpresso cancel ada
impresso cancel ada















Figura 85. Ao no estado Disponvel.
De forma similar, pode-se utilizar a declarao exit <ao> nos estados para representar que a <ao>
ser executada toda vez que se deixar o estado.
1.3 Atividade nos estados (do)
Uma atividade pode ser interrompida ou terminar por si s. Um atividade est sempre associada a um
estado por meio da palavra-chave do (faa). Por exemplo, na a atividade beep(tempo) ser executada
toda vez que a impressora estiver sem papel. Esta atividade pode ser interropida a qualquer momento
pela ocorrncia do evento impresso cancelada ou papel colocado.













Figura 86. Atividade na transio Sem Papel.
1.4 Auto-transio
possvel que um evento provoque a transio de um estado para ele mesmo. Neste caso, todas as
aes associadas ao estado por meio das palavras-chaves entry e exit e as aes associadas palavra-
chave do sero executadas. Na figura 87, toda vez que uma letra for teclada, dispara-se a transio do
estado Contado letras para ele mesmo o que provoca a execuo da ao num++. Notar que possvel
definir atributos das classes nos estados onde so manipulados (num: int).
82
stm Conta letras
Ini ti al
Contando letras
- num: i nt
+ entry / num++ Fi nal
/num:=-1 enter
l etra tecl ada










Figura 87: Auto-transio em mquina de estado.
1.5 Transio interna
possvel representar a ocorrncia de um evento que no provoca uma mudana de estado, somente
a execuo de uma ao. Estes eventos so chamados de eventos internos e so representados no
interior dos estados. A resposta a um evento interno difere daquela da auto-transio, pois no se
deixa o estado para reentrar em seguida. Portanto, as aes associadas s palavras-chaves entry e, exit
no so executadas e a atividade porventura em execuo no interrompida. No exemplo seguinda
(Figura 88), h uma transio interna disparada pela tecla F1. Neste caso, a ao mostrar help ser
executada, porm a ao num++ no ser executada.











Figura 88: Exemplo de transio interna.
1.6 Ordem de execuo de aes e atividades
A ordem de execuo das aes e atividades a seguinte, supondo-se que a mquina j se encontra
num estado A e passa ao estado B pela ocorrncia de um evento AB:
1. se existe uma atividade em execuo em A, ela interrompida;
2. executa-se a ao exit do estado A;
3. executa-se a ao associada ao evento AB;
4. executa-se a ao entry do estado B;
5. executa-se a atividade do em B, se existir.
No exemplo da figura 89, supe-se a seguinte seqncia de eventos: incio, ev AB, ev interno, ev B e ev
FIM. Para esta seqncia, as aes so executadas na seguinte ordem: incio - A0 A1, A2, A3 ev AB -
AB, A5, A6 ev interno - A7 (sem matar A6) ev B (interrompe A6) A8, A4, A5, A6 ev FIM A8,
A9.
stm Conta letras
Ini ti al
Contando letras
- num: i nt
+ F1 / mostrar hel p
+ entry / num++
Fi nal
/num:=-1
enter
l etra teclada
83
stm Ordem exec
Ini ti al
Estado A
+ entry / A1
+ do / A2
+ exi t / A3
Estado B
+ entry / A5
+ do / A6
+ ev i nterno / A7
+ exi t / A8
Fi nal
/A0
ev AB /AB
ev FIM /A9
ev B /A4














Figura 89: Ordem de execuo das aes e atividades.
1.7 Condio de guarda
Condio de guarda uma expresso lgica que deve ser satisfeita na ocorrncia de um evento para
que a transio correspondente ocorra. Por exemplo, na Figura 90, quando ocorrer o evento userInput
h trs opes mutuamente exclusivas dadas pelas condies de guarda:
1. opo = OK: a auto-transio sem ao associada ser executada;
2. opo = NOK: a auto-transio com a ao mostrarMsg ser executada;
3. opo = fim: o objeto ser destrudo.








Figura 90: Condio de guarda.
A condio de guarda importante para evitar conflitos entre transies. Se pela ocorrncia de um
evento, mais de uma transio pode ser disparada, ento a mquina de estados no determinstica.
2 TIPOS DE EVENTOS
2.1 De chamada
um evento sncrono, tipicamente uma chamada de mtodo. Pode-se chamar um mtodo da prpria
classe ou de outra classe. Por exemplo, a partir do diagrama de seqncia (figura 69, pg. 67) da
realizao do caso de uso Converter Celsius-Fahreneheit pode-se identificar que a classe CtrlConverso
possui um estado inicial (onde instancia a interface e histrico) e passa automaticamente ao estado
Aguarda entrada onde executa a ao associada entry. Esta ao produz um evento de chamada na
classe IUConversao que faz com que a mquina correspondente passe do estado Aguarda cmdo controle
84
stm CtrlConversao ME
Inici al
Aguarda entrada
+ entry / ^IUConversao.soli ci tarCel si us
fi m
Final
[falso]
/ConversaoCF(v),
^IUConversao.mostrar(f)
[verdadei ro]
/wri teObj ect()
v:=val or
forneci do
/i nstanci a
Hi stori co e
IUConversao
para Aguarda entrada do usurio. Observar que do ponto de vista do CtrlConversao solicitarCelsius
uma ao e de IUConversao, um evento de chamada. Embora no esteja representado (e no preciso
representar todos os detalhes) fica subentendido que quando o usurio fornece um valor de entrada
ao objeto da classe IUConversao, gera-se o evento valor fornecido no CtrlConversao (equivale resposta
ao evento de chamada solicitarCelsius).






















Figura 91: diagrama de estados para a classe CtrlConversao e IUConversao.
Quando um objeto envia um evento de chamada a outro objeto ele passa o controle da execuo ao
receptor. Uma vez que o objeto receptor processa o evento, disparando uma transio (se houver), o
controle retorna ao invocador. Porm, contrariamente a chamada de um mtodo, uma mquina de
estados que recebe um evento de chamada pode continuar sua execuo em paralelo (aps retorno do
controle) com o objeto invocador.
2.2 De sinal
So eventos assncronos que, portanto, no bloqueiam o emissor, tal como um sinal enviado pela rede
de comunicao de um processo a outro ou vindo da prpria interface do usurio. Para ilustrar este
tipo de sinal, considerar um servidor de pginas WEB. O funcionamento tpico o seguinte: o servidor
aguarda mensagens que podem chegar a qualquer momento. Quando chega uma mensagem, o
servidor a trata e envia uma resposta de forma assncrona (sem se preocupar se a mensagem chegou
ou no).

stm IUConversao ME
Ini ti al
Aguarda cmdo
controle
Aguarda entrada
usurio
fi nal
sol i ci tarCel si us val or forneci do [numri co
ou "fi m"]
val or forneci do
[~fi m & ~numri co]
destroy
mostrar(f)
/mostrar(f)
85

2.3 Temporal
Tipicamente so utilizados eventos nomeados por After(30seg) ou when(data= 1/ 2/2004) para indicar,
respectivamente, um intervalo de tempo relativo ou um momento preciso no tempo. Por exemplo, um
semforo passa pelos estados vermelho, verde e amarelo, sendo 45s no vermelho, 45s no verde e 5s no
amarelo.








Figura 92: Exemplo de evento temporal em mquina de estados.
2.4 De mudana
uma condio avaliada continuamente disparando um evento toda vez que se torna verdadeira.
representada frequentemente por meio do evento When. Difere de uma condio de guarda que
avaliada somente uma vez quando o evento ao qual est associada ocorre. A figura 93 ilustra a
diferena entre um evento de mudana e uma condio de guarda:
Parte superior da figura: encher o tanque e parar quando volume = 25 litros
Parte inferior da figura: uma vez o tanque cheio, se o volume for maior ou igual a 25 ganha ducha, caso
contrrio, no ganha.













Figura 93: diferena entre condio de guarda e evento de mudana.
86
Exerccio. Refaa o exemplo do semforo para acomodar a seguinte situao: da meia-noite s 5h00 o
sinal fica no estado alerta (piscando amarelo).

3 ESTADO COMPOSTO
Um estado composto pode ser decomposto em um conjunto de regies, cada uma delas com vrios
subestados. H diversas razes e, por conseqncia, formas ligeiramente diferentes de se representar
estados compostos.
Para representar decomposio de um estado, pode-se fazer um estado composto com uma nica
regio com subestados diretos onde somente um deles est ativo por vez.
Para representar concorrncia entre estados, isto , o fato de dois estados estarem ativos ao mesmo
tempo, preciso representar dividir o estado composto em duas ou mais regies cada qual ter
um estado ativo.
Para representar uma submquina, ou seja, um estado que referencia outra mquina de estados
que conceitualmente substitui o estado em questo.
Para exemplificar a situao, imaginar um aparelho de fax capaz de enviar e transmitir
simultaneamente. A representao, idntica utilizada no caso de multithreading, ilustrada na figura
94. O estado composto Processando dividido em duas regies concorrentes, a superior, responsvel
pela recepo de fax, e a inferior, pelo envio. Em um dado momento, o aparelho de fax pode estar com
os subestados transmitindo e recebendo ativos.
87















Figura 94: Estado composto Processando com duas regies concorrentes.
Na figura 94, possvel observar um pequeno smbolo na parte inferior do subestado Recebendo que
indica ser um estado composto. Sua decomposio est detalhada na figura 95.






Figura 95: Detalhamento do estado Recebendo.
3.1 Histrico
O pseudo-estado histrico denotado por H utilizado para memorizar o ltimo estado ativo quando
se deixou um estado composto. A flecha do H aponta para o estado default, ou seja, o subestado que
ativado na primeira vez em que o estado composto alcanado. Por exemplo, a Figura 96 mostra um
lava-car que inicia no estado composto, subestado lavagem. Caso ocorra o evento parada de urgncia
durante o estado enxaguar, retorna-se ao estado enxaguar aps a ocorrncia do evento retomada graas
ao smbolo histrico.
88



















Figura 96: Memorizao do ltimo estado visitado (histrico).
4 EXERCCIOS
1. Fazer um diagrama de estados para as estaes do ano. Fazer o diagrama de estados no editor
UML e codificar a classe em JAVA.
2. Anlise o cdigo abaixo (CD Player) e construa a mquina de estados equivalente ao
comportamento apresentado. Utilize condies de guarda e aes nas transies.

1 import java.io.*;
2 class CDPlayer {
3 static private int estado=0;
4
5 // AES
6 static private void desligar() {
7 System.out.println("*cortar fonte de energia*");
8 }
9 static private void ligar() {
10 System.out.println("*alimentao acionada*");
11 }
12 static private void pararCDabrirCompartimento() {
13 pararCD();
14 abrirCompartimento();
15 }
16 static private void fecharCompartimentoTocarCD() {
17 fecharCompartimento();
18 tocarCD();
19 }
20 static private void fecharCompartimento() {
21 System.out.println("*acionar motor fechamento*");
22 }
23 static private void abrirCompartimento() {
24 System.out.println("*acionar motor abertura*");
25 }
26 static private void tocarCD() {
27 System.out.println("*acionar leitor otico e giro CD*");
28 }
29 static private void pararCD() {
30 System.out.println("*parar leitor otico e giro CD*");
31 }
32
33
34 static private void mudarEstado(String evento) {
35 switch(estado) {
89
36 case 0: // estado desligado
37 if (evento.compareToIgnoreCase("l")==0) {
38 estado=1;
39 ligar();
40 System.out.println("[CD LIGADO]");
41 }
42 break;
43 case 1: // estado ligado
44 if (evento.compareToIgnoreCase("l")==0) {
45 estado=0;
46 desligar();
47 System.out.println("[CD DESLIGADO]");
48 }
49 else
50 if (evento.compareToIgnoreCase("p")==0) {
51 estado=2;
52 tocarCD();
53 System.out.println("[TOCANDO]");
54 }
55 else
56 if (evento.compareToIgnoreCase("o")==0) {
57 estado=3;
58 abrirCompartimento();
59 System.out.println("[ABERTO]");
60 }
61 break;
62
63 case 2: // tocando
64 if (evento.compareToIgnoreCase("l")==0) {
65 estado=0;
66 pararCD();
67 desligar();
68 System.out.println("[CD DESLIGADO]");
69 }
70 else
71 if (evento.compareToIgnoreCase("o")==0) {
72 estado=3;
73 pararCDabrirCompartimento();
74 System.out.println("[ABERTO]");
75 }
76 if (evento.compareToIgnoreCase("s")==0) {
77 estado=1;
78 pararCD();
79 System.out.println("[CD LIGADO]");
80 }
81 break;
82
83 case 3: // aberto
84 if (evento.compareToIgnoreCase("l")==0) {
85 estado=0;
86 fecharCompartimento();
87 System.out.println("[CD DESLIGADO]");
88 }
89 else
90 if (evento.compareToIgnoreCase("p")==0) {
91 estado=2;
92 fecharCompartimentoTocarCD();
93 System.out.println("[TOCANDO]");
94 }
95 else
96 if (evento.compareToIgnoreCase("c")==0) {
97 estado=1;
98 fecharCompartimento();
99 System.out.println("[LIGADO]");
100 }
101 break;
102
103 }
104 }
105
106 static public void main(String args[]) {
107 BufferedReader rdr = new BufferedReader(new InputStreamReader(System.in));
108 String evento="";
109 System.out.println("[CD DESLIGADO]");
110 do {
111 System.out.println("(L)iga/desliga (P)lay (S)top (O)pen (C)lose (F)im");
112 try {
90
Ociosa
Manuteno
Validao
do carto
Seleo
operao
Processa-
mento
Impresso
Fazer manut.
Fim manut.
Cancelar/
ejetar carto
Cancelar/
ejetar carto
Cancelar/
ejetar carto
Cancelar/
ejetar carto
Fim impresso/
ejetar carto
Inserir carto
/Ler carto
113 evento = rdr.readLine();
114 mudarEstado(evento);
115 } catch (IOException e) {
116 System.out.println("!!! Erro leitura !!!");
117 }
118 } while (evento.compareToIgnoreCase("f")!=0);
119 }
120 }

3. Refazer o exerccio acima mostrando como colocar aes nos estados (entry e exit).
4. Refazer o diagrama de estados abaixo utilizando um estado composto.













5. Faa um diagrama de estados para uma classe que implemente um jogo de xadrez. Voc pode
usar, por exemplo, os eventos seguintes: branca move, preta move, branca desiste, preta desiste,
xeque mate. Represente nos estados o jogador da vez (brancas ou pretas).
6. Faa o diagrama de estados para um despertador. O despertador pode estar em um dos estados
seguintes: desarmado, esperando e despertando. O despertador inicia no estado desarmado. Para
passar ao estado esperando, ele deve ser armado para disparar num determinado horrio. No
estado despertando ele soa por 30 segundos. Se o usurio deslig-lo ele volta ao estado
desarmado. Caso o usurio no desligue, o despertador volta a soar em 2 minutos at 3 vezes. Se
ao cabo destas 3 vezes o usurio no desligou-o ento o despertador volta ao estado desarmado.
7. Desenhe o diagrama de estados correspondente ao algoritmo do fatorial de n:
0! = 1
1! = 1
n! se n > 1 = n*(n-1)!
8. Represente em 3 diagramas de estado, uma televiso que pode estar ligada ou desligada, um
DVD player, que tambm pode estar ligado ou desligado e um controle remoto que tem dois
modos de funcionamento ora liga/desliga a televiso e ora liga/desliga o DVD player. Os botes
dos trs aparelhos so do tipo liga/desliga (o mesmo boto realiza as duas funes).
9. Suponha um editor de textos capaz de manipular trs tipos diferentes de objetos: textos, imagens e
desenhos. Este programa manipula somente um tipo de objeto por vez de acordo com a seleo
corrente do usurio. Quando o usurio seleciona um texto, o editor mostra um menu pop-up com
as opes de edio textuais, o mesmo ocorre quando da seleo de uma imagem ou de um
91
desenho. Faa o diagrama de estados representado este comportamento e o pseudocdigo que
implementa o diagrama de estados
92
IX DIAGRAMA DE ATIVIDADES
O diagrama de atividades utilizado para representar a dinmica do negcio, dos casos de uso ou
para detalhar uma operao de uma classe. Em relao aos casos de uso, pode tanto representar o
fluxo bsico como um cenrio particular de execuo. importante ressaltar que diagramas de
atividade no devem tomar o lugar dos diagramas de estado nem dos diagramas de interao, pois ele
no detalha como os objetos se comportam nem como interagem.
Normalmente utilizado na fase de inicializao para descrever os fluxos dos casos de uso,
amadurecendo na fase de elaborao. Posteriormente pode ser utilizado para representar o
fluxograma para uma operao.
1 ELEMENTOS BSICOS
Ao: realizada de forma instantnea.
Atividade: demora certo tempo para ser realizada.
Transio:
Deciso
Paralelismo ou bifurcao (fork)
Sincronizao ou unio (join)
Raias







Figura 97: Elementos bsicos do diagrama de atividades.
A figura 98, ilustra um caso de uso de oferta de disciplinas em uma universidade. Professores
escolhem as disciplinas e horrios (que formam as turmas), os alunos recebem uma notificao e
tambm uma cpia do catlogo impressa. As seguintes atividades esto representadas:
Criar turmas (entrar com as informaes das turmas para o semestre)
Escolher turmas (professor escolhe turmas)
Associar professor s turmas
Criar catlogo de disciplinas (na verdade das turmas)
As transies entre as atividades representam o fluxo de controle do caso de uso. H atividades
seqenciais, pontos de deciso, barras de paralelismo e de sincronizao, raias que identificam os
responsveis pelas atividades e atividades inicial e final.
93
























Figura 98: Exemplo de diagrama de atividades.
2 EXERCCIOS
Representar por meio de um diagrama de atividades a regra de negcio de um sistema de controle de
notas escolares que determina se um aluno foi aprovado ou reprovado em funo de:
O aluno de v ter freqncia igual ou maior a 75%, caso contrrio estar reprovado por faltas.
Em relao mdia das notas parciais n1 e n2:
se superior ou igual a 7,0, aprovado por mdia
se superior ou igual 5, 0 e inferior a 7,0, em final
se inferior a 5,0, reprovado por nota.
Se aluno em final, realiza uma terceira prova:
Se mdia + final / 2 for maior ou igual a 5,0, aprovado, caso contrrio reprovado por nota.
Barra de sincronizao
Incio de paralelismo
94
X DIAGRAMA DE COMPONENTES E IMPLANTAO
1 DIAGRAMA DE COMPONENTES
Quando um classificador (classe, pacote, subsistema, componente) realiza uma interface, significa que
ele implementa uma ou mais operaes especificadas pela mesma. Uma interface define, portanto,
uma coleo de servios que devem ser implementados em algum ponto do sistema.
Um componente uma parte fsica do sistema, como um arquivo executvel, que realiza uma
interface e , portanto, substituvel por outro componente que realize a mesma interface. A figura 99
ilustra um componente.java que realiza a interface ImageObserver e um outro, image.java, que depende
da interface (e no da implementao da mesma).
















Figura 99: Exemplo de componentes e de suas relaes
3
.
A UML define trs tipos de componentes (Bezerra, 2004):
De execuo: existem em tempo de execuo, por exemplo, processos, threads, etc.
De instalao: por exemplo, arquivos executveis, controles Active-X, DLLs, etc.
De trabalho: so aqueles a partir dos quais os componentes de instalao so criados, tais como
documentos, fontes, bibliotecas estticas, etc.
H vrios esteretipos para componentes:
Executvel
Biblioteca: bibliotecas de classes ou funes;
Tabela: repositrio de dados;
Documento: arquivos texto (help), manual do usurio;
Arquivo: cdigo fonte ou outro arquivo qualquer.

3
Extrado de http://paginas.fe.up.pt/~jpf/teach/POO/componentes.pdf
95
deployment Proj eto
devi ce
Impressora
executi on envi ron...
cliente: Navegador
executi on envi ron...
App Server
executi on envi ron...
BD Coorp.
LAN
HTTP
ODBC
cmp Proj eto
executabl e
Lanamento de
Notas
executabl e
Alunos
executabl e
Professores
executabl e
Turmas
IAlunos
IProf
ITurmas
BD
executabl e
SGBD
Persistncia
iPersist
2 DIAGRAMA DE IMPLANTAO
O diagrama de implantao (deployement) representa a arquitetura fsica do sistema e, opcionalmente,
os componentes que existem em tempo de execuo. Os elementos bsicos so:
Ns: representa um recurso computacional (processadores, dispositivos, sensores, roteadores);
Conexes: ligam os ns, normalmente so meios fsicos de comunicao (fibra tica, cabo coaxial)
ou protocolos de comunicao (TCP/IP, HTTP, UDP).
A figura 100 mostra um exemplo de diagrama de implantao.










Figura 100: Exemplo de diagrama de implantao.
O diagrama de implantao pode ser associado ao de componentes para representar a distribuio dos
componentes. Pode ser importante para analisar o sistema quanto distribuio de carga de trabalho.
O diagrama de componentes da figura 101 pode ser associado ao diagrama de implantao da figura
100 resultando naquele ilustrado pela figura 101.









Figura 101 Exemplo de diagrama de componentes.
96
deployment Proj eto
devi ce
Impressora
executi on envi ronm...
cliente: Navegador
executi on envi ronment
App Server
executi on envi ronment
BD Coorp.
:Persistncia
executabl e
:Alunos
executabl e
:Professores
executabl e
:Turmas
executabl e
:SGBD
executabl e
:Lanamento de
Notas
LAN
HTTP
ODBC











Figura 102 Exemplo de diagrama de componentes.

97
XI REFERNCIAS BIBLIOGRFICAS
BOOCH G; RUMBAUGH J; JACOBSON I. UML: guia do usurio. Rio de Janeiro: Campus, c2000.
472p. ISBN 85-352-0562-4
BEZERRA E. Princpios de Anlise e Projeto de Sistemas com UML, Rio de Janeiro, Elsevier, 2002,
286p, ISBN 85-352-1032-6.
FOWLER M; SCOTT K. UML essencial: um breve guia para a linguagem-padro de modelagem de
objetos. 2.ed. Porto Alegre: Bookman, 2000 169 p. ISBN 8573077298
FOWLER M. Padres de Arquitetura de Aplicaes Corporativas, Bookman (ed.), 494p.
GUEDES G. T. A.; UML Uma Abordagem Prtica, Inovatec, 319p., 2004.
OMG, Unified Modeling Language 2.1.1, 732p., Fevereiro/2007. Disponvel em
http://www.omg.org/cgi-bin/apps/doc?formal/07-02-05.pdf, acesso em 16/04/2007.
PRESSMAN R. S. Engenharia de software. So Paulo: Makron, 1995. 1056 p. ISBN 85-346-0237-9
RUMBAUGH J., JACOBSON I., BOOCH G. The Unified Modeling Language Reference Manual,
2ed., Pearson Education, 2005, ISBN 0-321-24562-8.
QUATRANI T. Visual Modelling with Rational Rose 2000, Addison-Wesley, 2
a
edio, 1999, 288p.