Ap MD3 2012 Faetec

FUNDAO DE APOIO ESCOLA TCNICA
DO
ESTADO DO RIO DE JANEIRO - FAETEC

Nome da Disciplina
Perodo
Carga Horria
MODELAGEM DE DADOS 3 MD3
2 aulas/semana
Notas de Aula v1.0

Fevereiro de 2012
Professor M. Frana
professor@franca.pro.br
http://www.franca.pro.br/prof
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 1
Esta pgina foi deixada propositadamente em branco.
O Autor
Marcelo Frana tcnico em Processamento de Dados, tecnlogo em Processamento de Dados,
analista de sistemas ps-graduado pela PUC-Rio, bacharel em Administrao de Sistemas de Informao,
licenciado em Informtica pelo Instituto Superior de Educao do Rio de Janeiro ISERJ,
mestre em Informtica pela Universidade Federal do Estado do Rio de Janeiro UNIRIO,
aluno do MBA em gerenciamento de projetos da Fundao Getlio Vargas,
certificado MCAD pela Microsoft, certificado SCJA pela Sun,
certificado RAD Associate pela IBM, certificado OCJP 6 (SCJP) pela Oracle,
professor de Informtica da FAETEC e da Faculdade de Informtica Lemos de Castro,
e especialista de sistemas da IBM Brasil.
Estuda Informtica desde 1990 e trabalha com Informtica desde 1994.
Dedicatria
Dedico este trabalho a todos os meus alunos e ex-alunos.
Desejo a todos vocs muito sucesso profissional.
Que seus objetivos sejam alcanados e que vocs sempre perseverem, mantendo o foco!
Agradecimentos
Agradeo a Deus pela iluminao e por ter sido to feliz na escolha desta profisso.
Obrigado, Senhor!
ndice
1.
Introduo ao Paradigma OO ..................................................................................... 7

Motivao.................................................................................................................... 7
Tcnicas de Programao Tradicionais ............................................................................ 9
Histrico da Orientao a Objetos................................................................................. 10
Princpios Bsicos ....................................................................................................... 13
Introduo UML ....................................................................................................... 19
Exerccios .................................................................................................................. 20
2.
Diagrama de Casos de Uso ...................................................................................... 23

Introduo ................................................................................................................ 23
O que so atores, cenrios e casos de uso? ................................................................... 25
Como identificar atores e casos de uso? ........................................................................ 28
Aplicao de UML: diagramas de casos de uso ............................................................... 37
Relacionamentos entre Casos de Uso ............................................................................ 38
Sugestes de ferramentas de Modelagem: .................................................................... 41
Exerccios .................................................................................................................. 42
3.
Diagrama de Classes ............................................................................................... 45

Diagrama de Classes .................................................................................................. 45
Associaes ............................................................................................................... 47
Agregao e Composio ............................................................................................ 49
Generalizaes........................................................................................................... 50
Dependncias e Refinamentos ..................................................................................... 51
Exerccios .................................................................................................................. 52
4.
Diagrama de Atividades e de Sequncia .................................................................... 53

Diagrama de Atividades .............................................................................................. 53
Diagramas de Sequncia ............................................................................................. 60
Exerccios .................................................................................................................. 70
6.
Apndice A Questionrio de Avaliao do Curso ....................................................... 77
1. Introduo ao Paradigma OO
Motivao
Crise do Software
A crise do software foi um termo utilizado nos anos 70, quando a engenharia de software era
praticamente inexistente. O termo expressava as dificuldades do desenvolvimento de software frente
ao rpido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e
da inexistncia de tcnicas estabelecidas para o desenvolvimento de sistemas que funcionassem
adequadamente ou pudessem ser validados.
A noo da crise do software emergiu no final dos anos 60. Uma das primeiras e mais
conhecidas referncias ao termo foi feita por Edsger Dijkstra, na apresentao feita em 1972 na
Association for Computing Machinery Turing Award, intitulada "The Humble Programmer" (EWD340),
publicada no peridico Communications of the ACM.
Logo que o desenvolvimento de software comeou a caminhar com o advento das linguagens
estruturadas e modulares, uma situao tornou-se clara diante de todos: a indstria de software
estava falhando repetidamente na entrega de resultados dentro dos prazos, quase sempre estourando
os oramentos e apresentando um grau de qualidade duvidoso ou insatisfatrio.
Em um relatrio de 1969 [Naur, 1969], esse problema j havia sido reconhecido. Conforme foi
observado, cerca de 50 a 80% dos projetos nunca foram concludos ou estavam to longe de seus
objetivos que foram considerados fracassados. Dos sistemas que foram finalizados, 90% haviam
terminado 150 a 400% acima do oramento e dos prazos predeterminados [Wallnau, 2002].
Os problemas que originaram essa crise tinham relacionamento direto com a forma de trabalho
das equipes. Eram problemas que no se limitavam a "sistemas que no funcionam corretamente",
mas envolviam tambm dvidas sobre como desenvolver e manter um volume crescente de software e
ainda estar preparado para as futuras demandas. Essencialmente, eram sintomas provenientes do
pouco entendimento dos requisitos por parte dos desenvolvedores, somados s tcnicas e medidas
pobres aplicadas sobre o processo e o produto, alm dos poucos critrios de qualidade estabelecidos
at ento [Pressman, 2004].
A palavra crise j tem sido discutida por no descrever exatamente o problema em questo.
Uma definio mais precisa talvez seja aflio crnica, pelas caractersticas de continuidade e
intermitncia dos sintomas [Pressman, 2004].
Todos esses fatores
exigiram
respostas e
mtodos que foram
sendo aprimorados
documentados, dando incio rea de Engenharia de Software. A busca por eficincia e competncia
revelou oportunidades, desafios e perigos que guiaram as tecnologias e apontaram novos rumos para
as pesquisas.
A Crise do Software e a Idade Mdia

Para compreender melhor as origens da Crise de Software, podemos fazer uma comparao
muito interessante com a histria das outras indstrias. Por exemplo, antes da revoluo industrial, os
sapatos eram feitos de forma muito individual. Nesses tempos mais remotos, os sapateiros faziam cada
par de sapatos de forma nica para cada cliente, desde a obteno da matria prima at o produto
final.
As semelhanas com a indstria de software comeam logo a. Primeiro, porque as tcnicas de
desenvolvimento de software ainda no esto totalmente maduras e consolidadas. Afinal, a variedade
de tcnicas que surgiram nas ltimas dcadas enorme.
Em segundo lugar, existe uma tendncia muito forte em desenvolver software sem aproveitar o
material produzido no passado. E para piorar, alm de entreg-lo quase sempre mal documentado, a
maior parte do conhecimento envolvido na sua construo permanece apenas na cabea dos
desenvolvedores, o que deixa a situao muito parecida com a do sapateiro do exemplo.
Causas da Crise do Software

As causas da crise do software esto ligadas a complexidade do processo de software e a
relativa imaturidade da engenharia de software como profisso:
As estimativas de prazo e de custo frequentemente so imprecisas;
No dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software;
Com poucos dados histricos como guia, as estimativas tem sido a olho, com resultados
notadamente ruins;
A produtividade das pessoas da rea de software no tem acompanhado a demanda por
seus servios;
Os projetos de desenvolvimento de software normalmente so efetuados apenas com um
vago indcio das exigncias do cliente;
A qualidade de software s vezes menos que adequada e s recentemente comeam a
surgir conceitos quantitativos slidos de garantia de qualidade de software;
O software existente muito difcil de manter e a tarefa de manuteno devora o oramento
destinado ao software; e a facilidade de manuteno no foi enfatizada como um critrio
importante.
A crise se manifesta de varias formas:
Projetos estourando o oramento;
Projetos estourando o prazo;
Software de baixa qualidade;
Software muitas vezes no atinge os requisitos;
Projetos no gerenciveis (escopo e prazo estourados) e o cdigo difcil de manter.
A maior parte dos projetos, hoje, continua com estes problemas. Assim, pode se dizer que a
crise continua vigente ainda na atualidade.
As possveis solues para a crise de software:
O uso de melhores tcnicas, mtodos e ferramentas;
Mais treinamento e educao: Atualmente no se investe o suficiente;
A mudana de paradigma sobre o que desenvolver software e como deveria ser feito.
Tcnicas de Programao Tradicionais

Introduo
As tcnicas de programao tradicionais, como por exemplo a decomposio funcional, leva o
desenvolvedor a decompor o sistema em partes menores (funes), criando um emaranhado de
inmeras funes que chamam umas s outras.
Geralmente no h separao de conceitos e responsabilidades, causando dependncias
enormes no sistema, dificultando futuras manutenes no cdigo do programa.
No existe muito reaproveitamento de cdigo, ao contrrio, muitas vezes se tem muito cdigo
duplicado (mesmo trabalhando-se com tecnologia OO).
Programao Orientada a Eventos

Uma linguagem pode ser OO e no ser OE (Pascal), bem como pode ser OE (Visual Basic 6,
Javascript) e no suportar totalmente a OO. Outras linguagens (Visual Basic.NET, Java, Delphi) podem
ser tanto orientadas a objetos como orientadas a eventos. Uma boa IDE (Integrated Development
Environment) pode facilitar muito a programao orientada a eventos Microsoft Visual Studio, por
exemplo.
bom salientar que o fato de uma linguagem ser considerada OO, no implica em que a mesma
no seja (tambm) uma linguagem estruturada suportando as instrues bsicas de seqncia,
repetio e seleo.
Em suma, a programao orientada a eventos, somada a componentizao (ferramentas
baseadas
em
componentes
como
text
box,
combo,
button,
form,
etc.,
que
agilizavam
desenvolvimento de interfaces), tornou a programao para Windows uma tarefa relativamente fcil. A
gerao anterior de programadores trabalhava com linguagens como o Clipper, essencialmente
orientadas ao console/texto. Com o advento do Windows, surgiu um novo padro de interface com o
usurio. E a componentizao (Delphi e Visual Basic 5) e o conceito do RAD (Rapid Application
Development) proporcionaram que aplicaes inteiras fossem escritas em um tempo bastante
reduzido, em comparao com a gerao anterior.
Nota: Rapid application development (RAD) is a software development methodology that uses
minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is
interleaved with writing the software itself. The lack of extensive pre-planning generally allows software
to be written much faster, and makes it easier to change requirements.
Histrico da Orientao a Objetos

Origens
A Programao Orientada ao Objeto (Object-Oriented Programming) pode ser considerada como
uma extenso quase natural da Programao Modular; entretanto a sigla OOP tem causado um certo
"frisson" na comunidade de computao, nos ltimos anos.
Na verdade, isto no deveria acontecer, uma vez que a OOP foi concebida h muito tempo atrs
(no inicio da dcada de 70). A sua origem vem da linguagem Simula (Simula Language), concebida na
Noruega no incio da dcada de 60, e como o nome indica, foi criada para fazer simulaes. Entretanto,
seu uso alavancou um conceito que at ento passava "despercebido" pela maioria dos projetistas: a
similaridade com o mundo real.
A primeira linguagem de programao a implementar sistematicamente os conceitos de OOP foi
a linguagem SIMULA-68; em seguida surgiu a linguagem Smalltalk -criada pela Xerox -, que pode ser
considerada a linguagem que popularizou e incentivou o emprego da OOP. Atualmente podemos
encontrar verses de Smalltalk para microcomputadores, o que facilitou enormemente o seu uso,
tirando-a dos ambientes privativos das Universidades. O resultado foi uma linguagem de pura linhagem
OO, poderosssima, que implementa todos os conceitos de OO, o que no acontece com as chamadas
linguagens OO hbridas que implementam apenas alguns conceitos de orientao ao objeto.
Com o aparecimento da famosa "crise do software", o emprego da OOP foi a sada
protagonizada pelos desenvolvedores para minimizar os custos dos sistemas, em particular os custos
relativos s manutenes corretivas, uma vez que cerca de 75% dos custos dos programas referem-se
ao indesejvel expediente de alterar e/ou remendar cdigos dos sistemas j implantados e em
operao. notrio que um dos grandes benefcios da OO a reutilizao (reuso de cdigo/classes),
alm do que, um bom projeto OO resulta em classes com alta coeso e baixo acoplamento o que
facilita a manuteno.
Basicamente, a OOP utiliza os mesmos princpios da engenharia de hardware que projeta novos
equipamentos usando os mesmos componentes bsicos como transistores, resistores, fusveis, diodos,
chips, etc. Os "objetos" j existentes so utilizados para produzir novos "objetos", tornando essa
metodologia mais poderosa que as metodologias tradicionais de desenvolvimento de sistemas.
Se consideramos a Orientao ao Objeto como um novo paradigma de desenho de software,
devemos considerar, tambm, uma nova maneira de pensar, porque apesar de a escrita do cdigo
continuar sendo procedural, alguns conceitos mudam radicalmente: a estruturao e o modelo
computacional. Fundamentalmente o que se deseja com esta metodologia so basicamente duas
caractersticas: reutilizao de cdigo e modularidade de escrita; e nisto a OOP imbatvel quando
comparada com as metodologias antigas.
Em termos de modelo computacional podemos dizer que enquanto as metodologias tradicionais
utilizam o conceito de um processador, uma memria e dispositivos de I/O para processar, armazenar
e exibir as informaes, a OOP emprega um conceito mais real, mais concreto, que o de Objeto.
O que Orientao a Objetos?

um paradigma para o desenvolvimento de software que baseia-se na utilizao de
componentes individuais (objetos) que colaboram para construir sistemas mais complexos. A
colaborao entre os objetos feita atravs do envio de mensagens.
Um paradigma um conjunto de regras que estabelecem fronteiras e descrevem como resolver
problemas dentro desta fronteira. Um paradigma ajuda-nos a organizar a e coordenar a maneira como
olhamos o mundo.
Dentre as vantagens podemos citar:
Facilita a reutilizao de cdigo;
Os modelos refletem o mundo real de maneira mais aproximada: Descrevem de maneira

mais precisa os dados; A decomposio baseada em um particionamento natural; e so
mais fceis de entender e manter;
Pequenas mudanas nos requisitos no implicam em alteraes massivas no sistema em

desenvolvimento;
Implementao de tipos abstratos de dados (tipos que no sero implementados, mas

que servem ao projeto, pensando-se em herana).
Classes e Objetos
A OO um mecanismo moderno que ajuda a definir a estrutura de programas baseada nos
conceitos
do
mundo
real,
sejam
eles
reais
ou
abstratos.
OO
permite
criar
programas
componentizados, separando as partes do sistema por responsabilidades e fazendo com que essas
partes se comuniquem entre si, por meio de mensagens. Essas partes do sistemas so chamadas
OBJETOS criados a partir de CLASSES.
Uma classe a descrio de um grupo de objetos com propriedades similares (atributos),
comportamento comum (operaes), relacionamentos com outros objetos e semnticas idnticas. Todo
objeto instncia de uma classe.
Enquanto um objeto individual uma entidade concreta que executa algum papel no sistema,
uma classe captura a estrutura e comportamento comum a todos os objetos que esto relacionados.
Uma classe define a estrutura e o comportamento de qualquer objeto da classe, atuando como um
padro para a construo de objetos. Objetos podem ser agrupados em classes.
A definio da classe consiste na definio dos atributos e operaes dos objetos desta classe;
Um atributo uma caracterstica de uma classe. Atributos no apresentam comportamento, eles
definem a estrutura da classe; Operaes caracterizam o comportamento de um objeto, e so o nico
meio de acessar, manipular e modificar os atributos de um objeto.
Figura 1: relao entre classe e objeto
Exemplo: Programao Estruturada vs. OO

Vamos considerar o mesmo problema sendo resolvido, usando-se pseudo-cdigo, primeiro na
programao estruturada, e depois na programao orientada a objetos.
Ler 2 nmeros e exibir sua soma (Como?):
PROGRAMA SOMA
VARIVEIS
N1, N2: REAL
INCIO
LOC = 8
ESCREVA ENTRE COM DOIS NMEROS:

LEIA N1, N2
ESCREVA A SOMA :, N1+N2
FIM
Note que a nfase neste caso est nas operaes que devem ser desempenhadas para a soluo
do problema. Neste caso a soluo fica muito presa ao problema, sendo mais difcil podermos
aproveitar este cdigo num outro cenrio. Alguns poderiam afirmar que este cdigo poderia ser
utilizado atravs do famoso Copy & Paste. Porm, esta tcnica no deve ser considerada quando
falamos de reuso, pois pode levar situaes de redundncia (o que dificulta e encarece a manuteno
do cdigo), bem como a situaes de inconsistncia (no caso de uma alterao ser necessria mas nem
todas as ocorrncias do cdigo foram atualizadas, logo, o cdigo ter cpias atualizadas e outras no
Find & Replace). Por fim, note que foram necessrias apenas 8 linhas de cdigo para a soluo no
paradigma estruturado (seqncia, seleo e repetio).
Ler 2 nmeros e exibir sua soma (Com o qu?):

CLASSE CALCULADORA
ATRIBUTOS
N1, N2: REAL
MTODOS
INFORMAR_N1(N: REAL)
N1 N
FIM-INFORMAR_N1
INFORMAR_N2(N: REAL)
N2 N
FIM-INFORMAR_N2
RETORNAR_SOMA(): REAL
RETORNO (N1+N2)
FIM-RETORNAR_SOMA
FIM-CLASSE
LOC = 27
PROGRAMA SOMA
VARIVEIS
C: CALCULADORA
N: REAL
INCIO
C NOVO CALCULADORA
ESCREVA ENTRE COM DOIS NMEROS:
LEIA N
C.INFORMAR_N1(N)
LEIA N
C.INFORMAR_N2(N)
ESCREVA A SOMA :, C.RETORNAR_SOMA()
FIM
Princpios Bsicos
Abstrao
Informalmente um objeto representa uma entidade, tanto fsica quanto conceitual ou de
software. Exemplos:
Entidade Fsica: caminho, carro, bicicleta, etc.
Entidade Conceitual: processo qumico, matrcula, etc
Entidade de Software: lista encadeada, arquivo, etc.
Podemos afirmar que um objeto um conceito, abstrao, ou entidade com limites bem
definidos e um significado para a aplicao. Quando modelamos um objeto (classe), s consideramos o
que for relevante. O time de futebol do corao pode no ser um atributo relevante para um sistema
de informao escolar, por exemplo.
Abstrao considerada como a habilidade de modelar caractersticas do mundo real do
problema que o programador esteja tentando resolver. Por exemplo, se o programador estiver
interessado em controlar dados dos clientes de uma empresa, muito mais fcil lidar com uma
linguagem que oferea recursos em que ele possa criar algo chamado "Cliente" ao invs de recorrer
estruturas de dados tipo array ou record.
Nesse contexto a abstrao refere-se capacidade de modelar o mundo real, e por outro lado,
podemos consider-la como um mecanismo pelo qual restringimos o nosso universo de anlise e as
variveis e constantes que compem esse universo, desprezando os dados que no nos interessa na
anlise.
Podemos demonstrar o uso de abstrao facilmente, quando fechamos os olhos e pensamos em
uma mesa; esta mesa imaginria provavelmente no vai ser igual uma outra imaginada por outras
pessoas, mas o que importa que todos as pessoas que imaginaram uma mesa, colocaram nessa as
informaes que para elas so necessrias para a sua funo (de ser uma mesa). No importa se a
mesa de trs ps ou quatro, ou se o tampo de vidro, madeira ou mrmore; o que importa que a
imagem que idealizamos em nossa cabea de uma mesa e tenha as informaes necessrias para
cumprir sua funo.
Encapsulamento
Information Hiding: segurana, simplicidade, coeso.
Esconder os detalhes da implementao de um objeto chamado encapsulamento. A
capacidade de um objeto possuir uma parte privada, acessvel somente atravs dos mtodos definidos
na sua interface pblica; No se deve permitir acesso direto aos atributos de uma classe;
Benefcios: O cdigo cliente pode usar apenas a interface para a operao; A implementao do
objeto pode mudar, para corrigir erros, aumentar performance, etc. sem que seja necessrio modificar
o cdigo do cliente; A manuteno mais fcil e menos custosa; e cria um programa legvel e bem
estruturado. Na prtica, tendemos a diminuir o acoplamento, a dependncia externa (de outras
classes).
Normalmente, para respeitarmos o princpio do encapsulamento, todos os atributos de uma
classe devem ser private ou, no mximo, protected.
Observao: A linguagem Java no respeita totalmente o conceito do encapsulamento posto
que o escopo protected em Java permite que outras classes, que no filhas, consigam acessar o item
(atributo ou mtodo), apenas por fazer parte do mesmo pacote.
Encapsulamento a base de toda a abordagem da Programao Orientada ao Objeto; isto
porque contribui fundamentalmente para diminuir os malefcios causados pela interferncia externa
sobre os dados. Partindo desse princpio, toda e qualquer transao feita com esses dados s pode ser
feita atravs de procedimentos colocados "dentro" desse objeto, pelo envio de mensagens. Desta
maneira, dizemos que um dado est encapsulado quando envolvido por cdigo de forma que s
visvel na rotina onde foi criado; o mesmo acontece com uma rotina, que sendo encapsulada, suas
operaes internas so invisveis s outras rotinas. E at mesmo em linguagens consideradas no OO,
como no caso do Clipper 5.xx, segundo FERREIRA & JARABECK, pode-se observar um certo
encapsulamento nas rotinas em que as variveis so declaradas como LOCAL. Nesses casos tais
variveis so visveis somente dentro dessas rotinas aonde foram declaradas, o que permite ao
programador certa segurana quanto aos acessos indevidos por parte de outras rotinas, o que no
acontece com variveis PRIVATE ou PUBLIC, no contexto dessa linguagem.
Podemos visualizar a utilidade do encapsulamento pensando em um dvd, onde temos os botes
de liga-desliga, para frente, para traz, etc. Estes botes executam uma srie de operaes existentes
no aparelho, onde so executadas pelos componentes existentes dentro do aparelho (transistores,
cabos, motores, etc.) No interessa ao operador saber como o funcionamento interno do
equipamento; esta informao s relevante para os projetistas do aparelho (Encapsulamento =
Simplicidade). As informaes pertinentes ao usurio do equipamento so as existentes no meio
externo (botes, controle remoto) que ativam as operaes internas do equipamento. Desta maneira o
aparelho de dvd pode evoluir com os avanos tecnolgicos, e as pessoas que o utilizam continuam
sabendo utilizar o equipamento, sem a necessidade de um novo treinamento.
Na rea de software acontece o mesmo: as classes podem continuar evoluindo, com aumento
de tecnologia, e os programas que utilizam essas classe continuam compatveis. Isto ocorre porque a
esses programas no interessa saber como o funcionamento interno da classe e sim sua funo, para
que ele possa executar, conforme ela evolui, novas funes colocadas sua disposio. A nica coisa
que interessa aos consumidores a API da classe (operaes pblicas).
Herana
Herana um mecanismo que, se for bem empregado, permite altos graus de reutilizao de
cdigo. Do ponto de vista prtico, pode ser entendido como sendo um conjunto de instncias criadas a
partir de um outro conjunto de instncias com caractersticas semelhantes, e os elementos desse
subconjunto herdam todas as caractersticas (se aplica a atributos e mtodos.) do conjunto original.
A ideia fornecer um mecanismo simples (mas muito poderoso) para que se defina novas
classes a partir de uma j existente. Assim sendo, dizemos que essas novas classes herdam todos os
membros (propriedades + mtodos) da classe-me (ou super classe); isto torna o mecanismo de
herana uma tcnica muito eficiente para construir, organizar e reutilizar cdigo. Por isso, nas
linguagens que no suportam esse mecanismo, as classes so criadas como unidades independentes:
cada uma com seus membros concebidos do zero (sem vnculo direto com outras classes), o que torna
o processo mais demorado e com cdigos, s vezes, redundantes.
Um exemplo de linguagem que no implementa herana na sua forma clssica o Visual Basic
(at a atual verso desktop 6.0); neste caso o desenvolvedor tem que simular esse mecanismo,
usando a criatividade. A herana possibilita a criao de uma nova classe de modo que essa classe
(denominada subclasse, classe-filha ou classe derivada) herda TODAS as caractersticas da classe-me
(denominada superclasse, classe base ou classe primitiva); podendo ainda, a classe-filha, possuir
propriedades e mtodos prprios.
No processo de herana podemos imaginar um ser humano, que nasce com todas as
caractersticas de um ser humano sadio; agora, coloquemos nele uma roupa e um relgio. A roupa e o
relgio no faz parte do ser humano, mas quando "pegamos" este ser, vestido e com um relgio, e
realizamos o processo de herana gerada uma copia idntica da matriz. Se colocarmos um sapato
preto no ser humano original a sua copia tambm ficar calada, e se trocarmos a camisa do ser
humano original a sua cpia tambm vai receber a nova camisa; isto demonstra que a copia continua
vinculada matriz de origem. Podemos tirar quantas cpias que desejarmos da matriz original e todas
estas cpias mantero o seu vnculo. Podemos, at, tirar cpias das cpias, mas o processo de
modificarmos a matriz original implicar numa mudana em todas as outras que esto abaixo dela.
Nunca uma modificao feita nas copias altera a matriz de origem, e nunca podemos remover um item
que tenha sido recebido por intermdio da herana, isto que dizer que nenhuma das cpias (humanas)
poder se dar ao luxo de no ter o relgio.
Polimorfismo
O termo polimorfismo, etimologicamente, quer dizer "vrias formas"; todavia, na Informtica, e
em particular no universo da OOP, definido como sendo um cdigo que possui "vrios
comportamentos" ou que produz "vrios comportamentos"; em outras palavras, um cdigo que pode
ser aplicado vrias classes de objetos (se aplica a mtodos). De maneira prtica isto quer dizer que a
operao em questo mantm seu comportamento transparente para quaisquer tipos de argumentos;
isto , a mesma mensagem enviada a objetos de classes distintas e eles podero reagir de maneiras
diferentes.
Um mtodo polimrfico aquele que pode ser aplicado vrias classes de objetos sem que haja
qualquer inconveniente. o caso por exemplo, do mtodo Clear em Delphi, que pode ser aplicado
tanto classe TEdit como classe TListBox; nas duas situaes o contedo desse objetos so limpos,
mesmo pertencendo, ambos, classes distintas, LEITE.
Segundo FERREIRA & JARABECK, um exemplo bem didtico para o polimorfismo dado por um
simples moedor de carne. Esse equipamento tem a funo de moer carne, produzindo carne moda
para fazer bolinhos. Desse modo, no importa o tipo (classe) de carne alimentada; o resultado ser
sempre carne moda, no importa se de boi, de frango ou de qualquer outro tipo. As restries
impostas pelo processo esto no prprio objeto, definidas pelo seu fabricante e no pelo usurio do
produto.
comum a definio de que, para haver polimorfismo, preciso primeiro haver herana.
Polimorfismo se refere a mtodos, e nunca a atributos. Um mtodo herdado pode ser sobrescrito na
classe-filha, ou seja, apresentar um comportamento diferente do comportamento original da classeme. importante salientar que existe o chamado Polimorfismo de Interface, onde classes diferentes
(de hierarquias diferentes) implementam um mesmo conjunto de mtodos, cada qual sua maneira.
Classicamente isto no deve ser considerado polimorfismo posto que no existe herana, nem ligao
hierrquica neste caso.
Binding Dinmico
O acoplamento (binding) uma associao feita pelo compilador (interpretador) entre um
atributo e uma entidade. Exemplo: acoplamento entre tipos e variveis. O acoplamento pode ser:
Esttico: se ocorre antes do tempo de execuo e permanece inalterado durante a

execuo do programa. Exemplo: quando voc declara em Pascal que uma varivel do
tipo integer;
Dinmico ou Atrasado: se ocorre durante o tempo de execuo ou muda durante a

execuo do programa. Normalmente associado linguagens orientadas a objetos;
Exemplo (Java):
1 Elipse e;
2 Circulo c;
3 e := c;
4 e.calcularArea( );
A atribuio da linha 3 dinamicamente acoplada, pois acopla o objeto e a um tipo diferente de
seu tipo originalmente declarado. Em princpio, seria uma violao atribuir um objeto de um tipo
diferente do tipo da varivel e, no entanto, como c (Circulo) subclasse de e (Elipse) essa atribuio
vlida.
Qual o mtodo executado? O de Crculo ou de Elipse? Note que executamos o mtodo da
instncia e no da referncia. A operao executada a de Circulo, porque o compilador em tempo de
execuo verifica que a varivel aponta para um objeto desta classe.
Em algumas linguagens o programador deve pedir explicitamente o acoplamento dinmico para
uma mensagem em particular. Por exemplo, em C++ a operao deve ser declarada virtual na
superclasse e redefinida na subclasse.
Importante:
Todas
as
operaes
sobrescritas
na
classe
derivada
devem
proporcionar
semanticamente os mesmos servios oferecidos pela superclasse.
Classes Abstratas
Uma classe abstrata uma classe que no tem instncias diretas. Uma classe concreta uma
classe que pode ter instncias. Em outras palavras se X uma classe abstrata o cdigo a seguir no
pode ser executado:
X objeto = new X();
Apesar disso, voc pode criar construtores de uma classe abstrata para que eles sejam
chamados pelos construtores das subclasses (Reutilizao).
Em Java utiliza-se a palavra abstract para indicar uma classe abstrata:
public abstract class Figure { ....
O objetivo de criarmos classes abstratas encapsular outras classes com comportamento
comum. Elas podem surgir naturalmente na modelagem ou serem criadas para promover o reuso.
Alm disso, uma classe abstrata pode definir um protocolo para uma operao sem definir a
implementao do mtodo.
public abstract class Figure { // inicio da class Figure
public abstract double area();

public abstract double perimetro();
}// fim da class Figure
Assim, voc pode declarar mtodos abstratos em uma classe abstrata apenas para especificar
um protocolo comum de operaes. Toda subclasse concreta da classe abstrata deve fornecer uma
implementao para TODOS os mtodos abstratos:
class Circle extends Figure {
protected double raio;
public Circle(double r) { raio = r;}
public double area() { return PI*raio*raio;}
public double perimetro() { return 2*PI*raio;}
}
Se uma subclasse de uma classe abstrata no implementa todos os mtodos abstratos ento ela
tambm abstrata; e Uma classe abstrata tambm pode ter mtodos concretos. Frequentemente, faz
sentido mover o mximo de funcionalidade possvel para uma superclasse, seja ela abstrata ou no.
Interfaces
Interface um contrato entre a classe e o mundo externo. Quando uma classe implementa uma
interface, ela est comprometida a fornecer o comportamento publicado pela interface.
What Is an Interface?
As you've already learned, objects define their interaction with the outside world through the
methods that they expose. Methods form the object's interface with the outside world; the buttons on
the front of your television set, for example, are the interface between you and the electrical wiring on
the other side of its plastic casing. You press the "power" button to turn the television on and off.
In its most common form, an interface is a group of related methods with empty bodies. A
bicycle's behavior, if specified as an interface, might appear as follows:
interface Bicycle {
void changeCadence(int newValue);
// wheel revolutions per minute
void changeGear(int newValue);

void speedUp(int increment);
void applyBrakes(int decrement);
}
To implement this interface, the name of your class would change (to a particular brand of
bicycle, for example, such as ACMEBicycle), and you'd use the implements keyword in the class
declaration:
class ACMEBicycle implements Bicycle {
// remainder of this class implemented as before
}
Implementing an interface allows a class to become more formal about the behavior it promises
to provide. Interfaces form a contract between the class and the outside world, and this contract is
enforced at build time by the compiler. If your class claims to implement an interface, all methods
defined by that interface must appear in its source code before the class will successfully compile.
Note: To actually compile the ACMEBicycle class, you'll need to add the public keyword to the
beginning of the implemented interface methods.
A API (Application Program Interface) pblica de uma classe, ou a interface de uma classe o
conjunto de todos os mtodos pblicos da classe.
Introduo UML
Motivao
O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objetos nas
fases de anlise de requisitos, anlise de sistemas e design que no existe (ou existia) uma notao
padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada simbologia
existente possui seus prprios conceitos, grficos e terminologias, resultando numa grande confuso,
especialmente para aqueles que querem utilizar a orientao a objetos no s sabendo para que lado
aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajud-los a
construir e manter sistemas cada vez mais eficazes.
Quando a "Unified Modeling Language" (UML) foi lanada, muitos desenvolvedores da rea da
orientao a objetos ficaram entusiasmados j que essa padronizao proposta pela UML era o tipo de
fora que eles sempre esperaram.
A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de
novos conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da
UML no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar
orientado a objetos no estado da arte.
UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos
como "os trs amigos". Eles possuem um extenso conhecimento na rea de modelagem orientado a
objetos j que as trs mais conceituadas metodologias de modelagem orientada a objetos foram
desenvolvidas por eles, e a UML a juno do que havia de melhor nestas trs metodologias
adicionado novos conceitos e vises da linguagem.
Veremos como a UML aborda o carter esttico e dinmico do sistema a ser analisado levando
em considerao, j no perodo de modelagem, todas as futuras caractersticas do sistema em relao
utilizao de "packages" prprios da linguagem a ser utilizada, utilizao do banco de dados bem
como as diversas especificaes do sistema a ser desenvolvido de acordo com as mtricas finais do
sistema.
A
verso
atual
da
(especificao)
UML
pode
ser
conferida
no
site
http://www.omg.org/spec/UML/. No momento da preparao desta apostila, a verso corrente era a

2.4.1 de agosto de 2011.
The Unified Modeling Language - UML - is OMG's most-used specification, and the way the
world models not only application structure, behavior, and architecture, but also business process and
data structure.
UML, along with the Meta Object Facility (MOF), also provides a key foundation for OMG's
Model-Driven Architecture, which unifies every step of development and integration from business
modeling, through architectural and application modeling, to development, deployment, maintenance,

and evolution.
OMG is a not-for-profit computer industry specifications consortium; our members define and
maintain the UML specification which we publish in the series of documents linked on this page for your
free download. Software providers of every kind build tools that conform to these specifications. To
model in UML, you'll have to obtain a compliant modeling tool from one of these providers and learn
how to use it.
Exerccios
Responda
Baseado no texto o que seria necessrio aplicar para evitar a Crise do Software?
Em sua opinio, estamos ainda em uma Crise de Software? Comente sua resposta.
Em sua opinio, a comparao entre a fabricao de sapatos e de software procede?
Comente sua resposta.
Qual o objetivo da Engenharia de Software?
Segundo a Engenharia de Software, o que um software de baixa qualidade?
O fato de o Software ser feito sob encomenda um complicador? Torna a construo, de
certa forma, artesanal? Comente sua resposta.
Em sua opinio, existem outras possveis solues para a crise de software alm das
descritas neste artigo?
Exerccio de Modelagem
O exerccio (modelo de funcionrios) a seguir tem por objetivo criar um sistema para gerenciar
os funcionrios do Banco.
1) Modele um funcionrio. Ele deve ter o nome do funcionrio, o departamento onde trabalha,
seu salrio (double), a data de entrada no banco (String), seu RG (String) e um valor booleano que
indique se o funcionrio ainda est ativo na empresa ou se j foi mandado embora.
Voc deve criar alguns mtodos de acordo com sua necessidade. Alm deles, crie um mtodo
bonifica que aumenta o salrio do funcionrio de acordo com o parmetro passado como argumento.
Crie, tambm, um mtodo demite, que no recebe parmetro algum, s modifica o valor booleano
indicando que o funcionrio no trabalha mais aqui.
A ideia aqui apenas modelar, isto , s identifique que informaes so importantes e o que
um funcionrio faz. Desenhe no papel tudo o que um Funcionario tem e tudo que ele faz.
2) Transforme o modelo acima em uma classe Java. Teste-a, usando uma outra classe que
tenha o main. Voc deve criar a classe do funcionrio chamada Funcionario, e a classe de teste voc
pode nomear como quiser. A de teste deve possuir o mtodo main.
Um esboo da classe:
class Funcionario {
double salario;
// seus outros atributos e mtodos
void bonifica(double aumento) {
// o que fazer aqui dentro?
}
void demite() {
// o que fazer aqui dentro?
}
Figura
2:
classe
Funcionario
Voc pode (e deve) compilar seu arquivo java sem que voc ainda tenha terminado sua classe
Funcionario. Isso evitar que voc receba dezenas de erros de compilao de uma vez s. Crie a classe
Funcionario, coloque seus atributos e, antes de colocar qualquer mtodo, compile o arquivo java.
Funcionario.class ser gerado, no podemos execut-la pois no h um main, mas assim verificamos
que nossa classe Funcionario j est tomando forma.
Esse um processo incremental. Procure desenvolver assim seus exerccios, para no descobrir
s no fim do caminho que algo estava muito errado. Um esboo da classe que possui o main:
1 class TestaFuncionario {
2
3 public static void main(String[] args) {
4 Funcionario f1 = new Funcionario();
5
6 f1.nome = "Fiodor";
7 f1.salario = 100;
8 f1.bonifica(50);
9
10 System.out.println("salario atual:" + f1.salario);
11
12 }
13 }
Incremente essa classe. Faa outros testes, imprima outros atributos e invoque os mtodos que
voc criou a mais.
Lembre-se de seguir a conveno java, isso importantssimo. Isto , nomeDeAtributo,
nomeDeMetodo, nomeDeVariavel, NomeDeClasse, etc... (Camel case).
Exerccios Tericos
1) Relacione os termos classe, objeto e instncia.
2) Defina os princpios/conceitos do paradigma OO.
3) Defina a estrutura de uma classe.
4) Qual a diferena entre programao orientada a eventos e programao orientada a
objetos?
5) Defina a classe Java Pessoa com os atributos nome e idade, e seus respectivos mtodos
getters e setters.
6) Faa um programa que instancie duas Pessoas: Joo e Maria. O programa deve exibir os
dados de ambos os objetos.
2. Diagrama de Casos de Uso

Introduo
Um caso de uso uma tcnica de modelagem usada para descrever o que um novo sistema
deve fazer. Ele construdo atravs de um processo interativo no qual as discusses entre o cliente e
os desenvolvedores do sistema conduzem a uma especificao do sistema da qual todos esto de
acordo.
Um caso de uso descreve as operaes que o sistema deve cumprir para cada usurio. Ele vai
ajudar a formalizar as funes que o sistema precisa fazer. Um caso de uso se apresenta como uma
lista completa das interaes entre um usurio e o sistema para cumprir uma tarefa. Lista completa
significa que o caso de uso descreve as interaes desde o incio da tarefa, at o fim.
Casos de uso tm que ser compreensveis por usurios porque s eles sabem o que o sistema
precisa fazer. Os casos de uso permitem verificar se o analista e o usurio concordam sobre o que o
sistema deve fazer. Isso um problema importante no desenvolvimento de software. No mesmo
tempo, casos de uso podem servir de contratos entre os usurios e a equipe de desenvolvimento.
Casos de uso so narrativas em texto, amplamente utilizadas para descobrir e registrar
requisitos. Eles influenciam muitos aspectos de um projeto, inclusive a A/POO, e servem de entrada
para vrios artefatos subseqentes.
Objetivo
Decidir e descrever os requisitos funcionais do sistema;
Fornecer uma descrio clara e consistente do que o sistema deve fazer;
Permitir descobrir os requisitos funcionais das classes e operaes do sistema (Casos de

uso NO so requisitos, mas ajudam a identific-los).
Componentes
Podemos dizer que os componentes de um modelo de casos de uso so:
Ator - um papel (role) que tipicamente estimula/solicita aes/eventos do sistema e

recebe reaes. Cada ator pode participar de vrios casos de uso;
Casos de uso - documento narrativo que descreve a seqncia de aes feitas por um
ator no uso do sistema;
Sistema - o sistema a ser modelado.
Na UML o modelo de casos de uso consiste de diagramas de casos de uso que mostram os
atores , os casos de uso e seus relacionamentos. Os elementos grficos que representam atores, casos
de uso e sistema so mostrados abaixo:
Figura 3: casos de uso (UML)
Elementos
Os elementos principais do diagrama so uma elipse para representar um caso de uso e um
pequeno boneco para representar um ator.
O nome de um caso de uso pode ser qualquer sentena, mas a UML recomenda usar uma frase
ativa curta (verbo + substantivo), por exemplo: comprar itens, efetuar venda, etc..
Exemplo
Informalmente, casos de uso so narrativas em texto de algum ator usando um sistema para
atingir objetivos. Segue um exemplo de caso de uso no formato resumido:
Processar Venda: um cliente chega em um ponto de pagamento com itens que deseja
adquirir. O caixa usa o sistema PDV para registrar cada item comprado. O sistema
apresenta um total parcial e detalhes de linha de item. O cliente entra com os dados
sobre o pagamento, que so validados e, em seguida, registrados pelo sistema. O
sistema atualiza o estoque. O cliente recebe um recibo do sistema e sai com os itens
comprados.
Note que casos de uso no so diagramas, so textos. Enfocar os diagramas de caso de uso
UML, de valor secundrio, em vez do importante texto do caso de uso, um erro comum para novatos.
Casos de uso frequentemente necessitam ser mais detalhados ou estruturados do que no
exemplo, mas o essencial descobrir e registrar os requisitos funcionais, escrevendo narrativas de uso
de um sistema para satisfazer as metas do usurio, ou seja, casos de uso (caso de utilizao). No se
trata de uma idia difcil, embora possa ser difcil descobrir o que necessrio e escrev-lo de forma
coerente.
O que so atores, cenrios e casos de uso?

Introduo
Primeiro, daremos algumas definies informais: um ator algo com comportamento, tal como
uma pessoa (identificada por seu papel), um sistema de computador ou uma organizao; por
exemplo, um caixa.
Um cenrio uma seqncia especfica de aes e interaes entre atores e o sistema;
tambm chamado de instncia de caso de uso. uma histria particular de uso de um sistema ou um
caminho atravs do caso de uso; por exemplo, o cenrio de efetuar com sucesso a compra de itens em
dinheiro, ou o cenrio de no consumar a compra de itens por causa da recusa de uma autorizao de
crdito.
Em termos informais, ento, um caso de uso uma coleo de cenrios relacionados de sucesso
e fracasso, que descrevem um ator usando um sistema como meio para atingir um objetivo. Por
exemplo, temos a seguir um caso de uso em um formato informal que inclui alguns cenrios
alternativos:
Tratar Devolues
Cenrio de sucesso principal: um cliente chega a um posto de pagamento com itens a
serem devolvidos. O caixa usa o sistema PDV para registrar cada item devolvido...
Cenrios alternativos:
Se o cliente pagou a crdito e a transao de reembolso para estorno em sua conta de
crdito rejeitada, informe o cliente e o reembolse com dinheiro.
Se o identificador do item no for encontrado no sistema, este notifica o caixa e sugere
que entre manualmente o cdigo do produto (talvez ele esteja corrompido).
Se o sistema detecta uma falha para se comunicar com o sistema externo de

contabilidade...
Agora que cenrios (instncias de casos de uso) esto definidos, uma definio alternativa,
porm similar, de caso de uso fornecida pelo RUP (Rational Unified Process) vai fazer mais sentido:
Um conjunto de instncias de casos de uso, no qual cada instncia uma sequencia de aes
que um sistema executa e que fornece um resultado observvel com valor para um determinado ator
[RUP].
Casos de uso e o modelo de casos de uso

O PU (Processo Unificado) define o Modelo de Casos de Uso dentro da disciplina Requisitos.
Essencialmente, trata-se do conjunto de todos os casos de uso escritos; um modelo da
funcionalidade e ambiente do sistema.
Casos de uso so documentos de texto e no diagramas. Portanto, a modelagem de caso de uso
essencialmente uma ao de redigir texto e no de desenhar diagramas.
O Modelo de Casos de Uso no o nico artefato de requisitos no PU. Existem tambm:
Especificao Suplementar, Glossrio, Viso e Regras de Negcio. So todos teis para anlise de
requisitos, mas secundrios neste ponto.
O Modelo de Casos de Uso pode opcionalmente incluir um diagrama de caso de uso UML para
mostrar os nomes de casos de uso, atores e seus relacionamentos. Isso d um belo diagrama de
contexto de um sistema e do seu ambiente. Fornece tambm um modo rpido de listar os casos de
uso por nome.
No h nada orientado a objetos em casos de uso; no estamos fazendo anlise OO quando os
escrevemos. Isso no problema casos de uso so amplamente aplicveis, o que aumenta sua
utilidade. Dito isso, casos de uso so considerados uma entrada de requisitos chave para a A/POO
clssica.
Motivao: por que casos de uso?

Ns temos objetivos e desejamos que os computadores nos ajudem a atingi-los. Os objetivos
vo desde o registro de vendas at o uso de jogos e programas para estimar o fluxo de petrleo de
futuros poos. Analistas experientes inventaram muitos modos de descobrir objetivos, mas os melhores
so simples e familiares. Por qu? Isso torna mais fcil especialmente para clientes contribuir para
sua definio e reviso. Isso diminui o risco de perder a referncia. Este pode parecer um comentrio
inoportuno, mas importante. Pesquisadores apresentaram mtodos complexos de anlise que eles
entendem, mas que levam uma pessoa de negcios a entrar em coma! Falta de envolvimento do
usurio em projetos de software est perto do topo da lista de razes para fracassos de projetos
[Larman 03], assim, qualquer coisa que ajude a mant-los envolvidos realmente desejvel.
Casos de uso so uma boa maneira de manter a coisa simples e de tornar possvel a
especialistas no domnio ou fornecedores de requisitos escrever eles mesmos (ou participar da escrita
de) casos de uso.
Outro valor dos casos de uso que eles enfatizam os objetivos e perspectivas do usurio;
formulamos a questo quem est usando o sistema, quais so seus tpicos cenrios de uso e quais so
os seus objetivos? Essa uma nfase mais centrada no usurio, comparada a simplesmente solicitar
uma lista de caractersticas do sistema.
Muito tem sido escrito sobre casos de uso e, apesar de valer a pena, pessoas criativas
frequentemente obscurecem uma ideia simples com camadas de sofisticao ou supercomplicao.
Geralmente, possvel encontrar um modelador de casos de uso novato (ou um analista srio tipo A)
que se preocupa em excesso com problemas secundrios, como diagramas de casos de uso,
relacionamento entre casos de uso, pacotes de casos de uso e etc., em vez de se concentrar no
trabalho rduo de simplesmente escrever as narrativas em texto.
Dito isso, um dos pontos fortes do mecanismo de casos de uso a sua capacidade de
escalabilidade para cima ou para baixo em termos de sofisticao e formalidade.
Guia Sugerido para Preparar Casos de Uso

Nome do Caso de Uso (Comear com um verbo.)
Descrio do caso de uso (um pargrafo). Escopo (O sistema em projeto.).
Atores
Ator principal chama o sistema para fornecer os servios.
Lista dos nomes dos atores com descrio curta.
Prioridade
Este caso de uso muito importante no projeto ou acessrio?
Pr-Condies
Lista de condies que tm que ser verificadas antes que o caso de uso comea.
Fluxo de Eventos / Fluxo Principal
1. Primeiro passo no caso de uso resposta do sistema.
2. Segundo passo no caso de uso resposta do sistema.
3. ...
Fluxos Alternativos
Descrever os fluxos alternativos ou extenses.
Ps-Condies (garantias de sucesso)
Lista de condies que tm que ser verificadas depois do fim do caso de uso.
Pontos de extenso
Lista dos pontos de extenso no caso de uso.
Casos de uso includos
Lista dos nomes dos casos de usos includos.
Como identificar atores e casos de uso?

Introduo
Nos primeiros contatos com os modelos de casos de uso surgem com frequncia perguntas para
as quais no existe uma resposta absoluta. So elas: Como identificar atores? Como identificar casos
de uso?
Para identificar os atores que vo participar do modelo devemos perguntar:
Quem usa o sistema?
Quem inicia o sistema?
Quem fornece os dados?
Quem usa as informaes?
Descrio de Atores
Geralmente descreve atores usando:
Nome do caso de uso;
Tipo de uso (frequente, ocasional , etc.);
Descrio de seu papel no sistema.
Tipos de Atores
Um ator qualquer coisa com um comportamento, inclusive o prprio sistema em discusso
quando invoca os servios de outros sistemas. Atores principais e de suporte aparecero nos passos de
ao do texto do caso de uso. Atores no so somente papis desempenhados por pessoas, mas
tambm por organizaes, software e mquinas. H trs tipos de atores externos em relao ao
sistema:
Ator Principal (Primary) tem objetivos de usurio satisfeitos por meio do uso dos servios
do sistema. Por exemplo, o caixa.
o Por que identificar? Para encontrar objetivos de usurio, que guiam os casos de uso.
Ator de Suporte (Supporting) fornece um servio (por exemplo, informaes) para o

sistema. O servio automatizado de autorizao de pagamento um exemplo. Frequentemente
um sistema de computador, mas pode ser uma organizao ou pessoa.
o Por que identificar? Para esclarecer interfaces externas e protocolos.
Ator de Bastidor (Offstage) tem interesse no comportamento do caso de uso, mas no um

ator principal ou de suporte; por exemplo, um rgo governamental responsvel por impostos.
o Por que identificar? Para garantir que todos os interesses necessrios estejam
identificados e satisfeitos. Os interesses de atores de bastidor so, s vezes, sutis ou de
fcil esquecimento, a menos que esses atores sejam explicitamente nomeados.
Formatos Comuns de Casos de Uso

Casos de uso podem ser escritos em diferentes formatos e nveis de formalidade:
Resumido (brief) resumo sucinto de um pargrafo, geralmente o cenrio de sucesso

principal. O exemplo precedente Processar Venda foi resumido.
o Quando? Durante a anlise de requisitos inicial, para obter uma rpida ideia do
assunto e escopo. Pode levar apenas alguns minutos para criar.
Informal (casual) formato informal de pargrafos. Mltiplos pargrafos que cobrem vrios
cenrios. O exemplo precedente Tratar Devolues foi informal.
o Quando? Como acima.
Completo (fully dressed) Todos os passos e variantes so escritos em detalhe, e h sees

de suporte, como pr-condies e garantias de sucesso.
o Quando? Depois que muitos casos de uso tiverem sido identificados e escritos em
formato resumido, ento durante o primeiro workshop de requisitos, alguns (como por
exemplo, 10%) dos casos de uso arquiteturalmente significativos e de alto valor, so
escritos em detalhe.
Exemplo Caso de Uso Completo

Use Case UC1: Process Sale
Scope: NextGen POS application
Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:
Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are
deducted from his/her salary.
Salesperson: Wants sales commissions updated.
Customer: Wants purchase and fast service with minimal effort. Wants easily visible display
of entered items and prices. Wants proof of purchase to support returns.
Company: Wants to accurately record transactions and satisfy customer interests. Wants to
ensure that Payment Authorization Service payment receivables are recorded. Wants some
fault tolerance to allow sales capture even if server components (e.g., remote credit
validation) are unavailable. Wants automatic and fast update of accounting and inventory.
Manager: Wants to be able to quickly perform override operations, and easily debug Cashier
problems.
Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies,
such as national, state, and county.
Payment Authorization Service: Wants to receive digital authorization requests in the correct
format and protocol. Wants to accurately account for their payables to the store.
Preconditions: Cashier is identified and authenticated.

Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated.
Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment
authorization approvals are recorded.
Main Success Scenario (or Basic Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.

2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price
calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the external
Accounting system (for accounting and commissions) and Inventory system (to update
inventory).
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
1. System enters Manager-authorized mode.

2. Manager or Cashier performs one Manager-mode operation. e.g., cash balance change,
resume a suspended sale on another register, void a sale, etc.
3. System reverts to Cashier-authorized mode.
*b. At any time, System fails:
To support recovery and correct accounting, ensure all transaction sensitive state and events
can be recovered from any step of the scenario.
1. Cashier restarts System, logs in, and requests recovery of prior state.
2. System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1. System signals error to the Cashier, records the error, and enters a clean state.
2. Cashier starts a new sale.
1a. Customer or Manager indicate to resume a suspended sale.

1. Cashier performs resume operation, and enters the ID to retrieve the sale.
2. System displays the state of the resumed sale, with subtotal.
2a. Sale not found.
1. System signals error to the Cashier.
2. Cashier probably starts new sale and re-enters all items.
3. Cashier continues with sale (probably entering more items or handling payment).
2-4a. Customer tells Cashier they have a tax-exempt status (e.g., seniors, native peoples)
1. Cashier verifies, and then enters tax-exempt status code.
2. System records status (which it will use during tax calculations)
3a. Invalid item ID (not found in system):
1. System signals error and rejects entry.
2. Cashier responds to the error:
2a. There is a human-readable item ID (e.g., a numeric UPC):
1. Cashier manually enters the item ID.
2. System displays description and price.
2a. Invalid item ID: System signals error. Cashier tries alternate
method.
2b. There is no item ID, but there is a price on the tag:
1. Cashier asks Manager to perform an override operation.
2. Managers performs override.
3. Cashier indicates manual price entry, enters price, and requests
standard taxation for this amount (because there is no product information, the
tax engine cant otherwise deduce how to tax it)
2c. Cashier performs Find Product Help to obtain true item ID and price.
2d. Otherwise, Cashier asks an employee for the true item ID or price, and does
either manual ID or manual price entry (see above).
3b. There are multiple of same item category and tracking unique item identity not important
(e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity.
3c. Item requires manual category and price entry (such as flowers or cards with a price on
them):
1. Cashier enters special manual category code, plus the price.
3-6a: Customer asks Cashier to remove (i.e., void) an item from the purchase: This is only legal
if the item value is less than the void limit for Cashiers, otherwise a Manager override is needed.
1. Cashier enters item identifier for removal from sale.
2. System removes item and displays updated running total.
2a. Item price exceeds void limit for Cashiers:
1. System signals error, and suggests Manager override.
2. Cashier requests Manager override, gets it, and repeats operation.
3-6b. Customer tells Cashier to cancel sale:

1. Cashier cancels sale on System.
3-6c. Cashier suspends the sale:
1. System records sale so that it is available for retrieval on any POS register.
2. System presents a suspend receipt that includes the line items, and a sale ID used
to retrieve and resume the sale.
4a. The system supplied item price is not wanted (e.g., Customer complained about something
and is offered a lower price):
1. Cashier requests approval from Manager.
2. Manager performs override operation.
3. Cashier enters manual override price.
4. System presents new price.
5a. System detects failure to communicate with external tax calculation system service:
1. System restarts the service on the POS node, and continues.
1a. System detects that the service does not restart.
1. System signals error.
2. Cashier may manually calculate and enter the tax, or cancel the sale.
5b. Customer says they are eligible for a discount (e.g., employee, preferred customer):
1. Cashier signals discount request.
2. Cashier enters Customer identification.
3. System presents discount total, based on discount rules.
5c. Customer says they have credit in their account, to apply to the sale:
1. Cashier signals credit request.
2. Cashier enters Customer identification.
3. Systems applies credit up to price=0, and reduces remaining credit.
6a. Customer says they intended to pay by cash but dont have enough cash:
1. Cashier asks for alternate payment method.
1a. Customer tells Cashier to cancel sale. Cashier cancels sale on System.
7a. Paying by cash:
1. Cashier enters the cash amount tendered.
2. System presents the balance due, and releases the cash drawer.
3. Cashier deposits cash tendered and returns balance in cash to Customer.
4. System records the cash payment.
7b. Paying by credit:
1. Customer enters their credit account information.
2. System displays their payment for verification.
3. Cashier confirms.
3a. Cashier cancels payment step:
1. System reverts to item entry mode.
4. System sends payment authorization request to an external Payment Authorization
Service System, and requests payment approval.
4a. System detects failure to collaborate with external system:

1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
5. System receives payment approval, signals approval to Cashier, and releases cash
drawer (to insert signed credit payment receipt).
5a. System receives payment denial:
1. System signals denial to Cashier.
2. Cashier asks Customer for alternate payment.
5b. Timeout waiting for response.
1. System signals timeout to Cashier.
2. Cashier may try again, or ask Customer for alternate payment.
6. System records the credit payment, which includes the payment approval.
7. System presents credit payment signature input mechanism.
8. Cashier asks Customer for a credit payment signature. Customer enters signature.
9. If signature on paper receipt, Cashier places receipt in cash drawer and closes it.
7c. Paying by check
7d. Paying by debit
7e. Cashier cancels payment step:
1. System reverts to item entry mode.
7f. Customer presents coupons:
1. Before handling payment, Cashier records each coupon and System reduces price as
appropriate. System records the used coupons for accounting reasons.
1a. Coupon entered is not for any purchased item:
1. System signals error to Cashier.
9a. There are product rebates:
1. System presents the rebate forms and rebate receipts for each item with a rebate.
9b. Customer requests gift receipt (no prices visible):
1. Cashier requests gift receipt and System presents it.
9c. Printer out of paper.
1. If System can detect the fault, will signal the problem.
2. Cashier replaces paper.
3. Cashier requests another receipt.
Special Requirements:
Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
Credit authorization response within 30 seconds 90% of the time.
Somehow, we want robust recovery when access to remote services such the inventory system
is failing.
Language internationalization on the text displayed.
Pluggable business rules to be insertable at steps 3 and 7.
...
Technology and Data Variations List:

*a. Manager override entered by swiping an override card through a card reader, or entering an
authorization code via the keyboard.
3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. But within two years, we predict many
customers will want digital signature capture.
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
What are the tax law variations?
Explore the remote service recovery issue.
What customization is needed for different businesses?
Must a cashier take their cash drawer when they log out?
Can the customer directly use the card reader, or does the cashier have to do it?
Este caso de uso ilustrativo e no pretende ser exaustivo (embora seja baseado nos requisitos
de um sistema PDV real desenvolvido com projeto OO em Java). No entanto, suficientemente
detalhado e complexo para oferecer um senso de realismo, de modo que um caso de uso completo
possa registrar muitos detalhes de requisitos. Este exemplo servir de modelo para muitos problemas
de casos de uso.
Como encontrar Casos de Uso

Os casos de uso so interaes entre os atores e o sistema. Temos ento aes do ator e aes
do sistema, sendo que os atores sempre iniciam a ao.
Casos de uso so definidos para satisfazer aos objetivos dos atores principais. Assim, o
procedimento bsico :
1. Escolher a fronteira do sistema. Ele somente uma aplicao de software, o hardware e a

aplicao como uma unidade, isso e mais uma pessoa usando o sistema, ou toda uma
organizao?
2. Identificar os atores principais aqueles que tm objetivos satisfeitos por meio do uso dos
servios do sistema.
3. Identificar os objetivos para cada ator principal.
4. Definir casos de uso que satisfaam os objetivos dos usurios; nomeie-os de acordo com o
objetivo. Geralmente, os casos de uso no nvel de objetivo do usurio estaro em uma relao
de um-para-um com os objetivos dos usurios, mas existe pelo menos uma exceo que ser
examinada.
Certamente, em um desenvolvimento iterativo e evolutivo, nem todos os objetivos ou casos de
uso vo estar total ou corretamente identificados logo no incio. Trata-se de uma descoberta evolutiva.
Recomendaes
Nomeie um caso de uso comeando com um verbo, para enfatizar que ele um processo. Ex:
Cadastrar Cliente , Comprar Item, etc..
Para identificar claramente um ator iniciador e um evento, comece a descrio da sequncia de
um caso de uso usando o seguinte esquema: Este caso de uso comea quando o <Ator> <Evento que
inicia o caso de uso>...
Exemplo: Este caso de uso comea quando um cliente chega com vrios itens para efetuar uma
compra.
Vamos a outro exemplo: Suponha que voc tenha um almoxarifado de peas onde clientes
faam pedidos e onde um operador receba tarefas do sistema para buscar peas para os pedidos dos
clientes e distribuir peas do setor de compras para o almoxarifado.
Como poderamos identificar os atores e os casos de uso para este exemplo?
Vamos identificar os atores. Eles so: Cliente, Operador, Sistema e Setor de Compras. Certo?
No, errado! No exemplo acima Sistema no pode ser um ator pois ele no se ajusta ao conceito
dado a um ator: Um agente externo ao sistema.
Lembre-se que um ator um papel que interage com o sistema mas no faz parte do sistema.
Ento, no lugar de Sistema, poderamos sugerir um administrador ou gerente. Ento os atores seriam:
Cliente, Operador, Administrador e Compras. Note ainda que podem existir subsistemas que interajam
com o sistema. Neste caso eles seriam considerados atores.
E os casos de usos, quais seriam?
solicita peas (ator Cliente)
entrega peas (ator Compras)
buscar pedidos (ator operador)
distribuir pedidos (ator operador)
cadastrar Tarefas (administrador)
Certo? Errado! No caso do ator operador, ele no atua sobre o sistema nos casos de uso buscar
pedidos e distribuir pedidos. Ele atua sobre o sistema realizando Tarefa. Ento o correto seria:
solicita peas (ator Cliente)
entrega peas (ator Compras)
realiza Tarefa (ator operador)
Figura 4: atores e fronteira do sistema
cadastrar Tarefas (administrador)
O caixa ou o cliente o ator principal?

Por que o caixa, e no o cliente, o ator principal no caso de uso Processar Venda?
A resposta depende da fronteira do sistema em projeto e para quem o sistema est sendo
principalmente projetado, conforme ilustrado na figura 4. Se enxergarmos a empresa ou o
servio de concluso da venda (checkout) como um sistema agregado, o cliente um ator
principal, com o objetivo de obter bens ou servios e ir embora.
Aplicao de UML: diagramas de casos de uso

Introduo
A UML fornece a notao de diagramas de casos de uso para ilustrar os nomes dos casos de uso
e dos atores, bem como os relacionamentos entre eles (ver figura 5).
Figura 5: diagrama parcial de contexto dos casos de uso.

Um sinal tpico de modeladores de casos de uso iniciantes (ou acadmicos) a preocupao
com diagramas de casos de uso e seus relacionamentos, em vez de escrever texto. Especialistas em
casos de uso mundialmente reconhecidos, como Fowler e Cockburn, entre outros, no se preocupam
com os diagramas de casos de uso e seus relacionamentos, concentrando-se, em vez disso, em sua
redao. Tendo isso como um alerta, um simples diagrama de caso de uso oferece um diagrama de
contexto visual sucinto para o sistema, que ilustra os atores externos e como eles usam o sistema.
Um diagrama de caso de uso uma excelente imagem do contexto do sistema; ele um bom
diagrama de contexto, ou seja, mostra a fronteira de um sistema, o que est fora dele e como o
sistema usado. Serve como uma ferramenta de comunicao que resume o comportamento do
sistema e seus atores. A figura 5 uma amostra de um diagrama de caso de uso de contexto parcial
para o sistema ProxGer.
Diretriz: diagramao
A figura 6 oferece algumas sugestes sobre o diagrama. Note a caixa de ator com o smbolo
ator. Este smbolo usado para as palavras-chave e esteretipos UML e incluem aspas horizontais
guillemets colchetes especiais de um nico caractere (ator e no <<ator>>), mais comumente
usados na tipografia francesa para indicar uma citao.
Figura 6: Sugesto de notao.

Para maior clareza, alguns preferem destacar os atores externos ao sistema de computador com
uma notao alternativa, como mostrado na figura 7.
Figura 7: Notao alternativa para ator.
Relacionamentos entre Casos de Uso

Introduo
A partir do diagrama de casos de uso preliminar, muitas vezes temos que definir casos de usos
adicionais, separadamente, pois as operaes se encontram duplicadas em outros casos de uso ou so
complexas e longas e a separao nos ajuda a compreend-las.
Os relacionamentos possveis so: Incluso, Extenso e Generalizao.
Incluso
Se um caso de uso inicia ou inclui o comportamento de outro, dizemos que ele usa o outro.
Exemplo: No caso de uso Comprar Item, se o pagamento for feito com dinheiro, podemos ter a
incluso PagarComDinheiro.
O relacionamento de incluso em UML ilustrado com uma linha de generalizao com o rtulo
include.
Figura 8: Inclui
Ento, para o exemplo do cliente, com o use case Solicitar Pedidos de peas, teramos como
propriedades bsicas da incluso:
Realizar uma decomposio funcional;
Reduzir a complexidade de um caso de uso;
O caso de uso bsico no pode executar sem a incluso.
Comportamento comum.
Extenso
Define pontos de extenso (opcionais) que adicionam comportamento a um caso de uso base,
descrevendo uma variao do comportamento normal. O caso de uso base pode ser executado mesmo
sem a extenso.
Exemplo: O caso de uso Comprar Produto pode apresentar a extenso Compra por um Cliente
Regular. Os pontos de extenso so indicados na linha entre os casos de uso do sistema. Abaixo temos
diagramas UML exemplificando estes conceitos.
Figura 9: Estende
Dica: note que a seta sempre aponta para o ido (estendido, ou includo).
Figura 10: Relacionamento de incluso e extenso.
Generalizao
Indica um caso de base que possui diferentes especializaes, e inclui comportamento ou
sobrescreve o caso de uso base.
O caso de uso Pagar fatura apresenta as especializaes: Pagamento com carto e Pagamento
com Cheque, conforme o diagrama a seguir:
Figura 11: generalizao do caso de uso.

Alm disto temos tambm os relacionamentos entre atores onde um ator especializado pode
acessar os casos de uso de um Ator base.
A seguir temos um exemplo onde o Ator gerente acessa os casos de uso do ator funcionrio:
Figura 12: generalizao de atores.
Sugestes de ferramentas de Modelagem:

Introduo
Recomendamos as seguintes ferramentas:
Rational Rose (IBM RSA Rational Software Architect).
Free: Jude/Community
Poseidon/Community
Visual Paradigm Community Edition
Note que algumas empresas adotam o Microsoft Visio. Porm, ele no considerado uma
ferramenta especfica para UML ao contrrio do Visual Paradigm, por exemplo.
Exerccios
Faa os diagramas de caso de uso
Fazer Pedido - verso 1
Cenrio informal
O caso de uso comea quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e
endereo. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente a cidade e o estado. O
cliente fornece os cdigos do produto. O sistema devolve as descries e o preo de cada produto. O
sistema calcular os valores totais para cada produto fornecido. O cliente fornece as informaes sobre
carto de crdito. Em seguida, ele submete os dados ao sistema. O sistema verifica as informaes
fornecidas, marca o pedido como "pendente" e envia as informaes de pagamento para o sistema de
contabilidade e pagamento. Quando o pagamento confirmado, o pedido marcado como
"confirmado" e o nmero de pedido (NP) dado ao cliente.
Desenhe o caso de uso

Cenrio: Jos resolveu desenvolver uma aplicao para controlar as ligaes telefnicas de sua
casa, a fim de checar se o valor que paga mensalmente est correto. Assim, sempre que desejar
poder listar as ligaes efetuadas num determinado perodo, contabilizando o valor a pagar.
Para que isso seja possvel, toda ligao ser feita pelo computador. A cada solicitao de
ligao, a aplicao dever registrar: a data da ligao, a hora da ligao, quantidade de minutos
gastos (que deve ser registrado no momento que a ligao for encerrada), o nmero de pulsos (que
deve ser calculado pela aplicao) e o telefone para onde se discou.
A aplicao permitir o controle de uma agenda de telefones, com nmero do telefone e nome
da pessoa de contato. O usurio poder escolher no momento da ligao, se deseja um dos registros
da agenda ou se digitar diretamente o nmero do telefone.
A forma de clculo dos pulsos considera os seguintes critrios:
- A ligao ao ser completada j conta um pulso. A partir da, a cada quatro minutos de
conversao concluda, cobra-se mais um pulso.
- Cada pulso custa R$ 0,08 para ligaes locais.
Exemplo:
Ligao de 2 minutos - 1 pulso
Ligao de 4m30s - 2 pulsos
Ligao de 8 minutos - 3 pulsos
- Os finais de semana possuem uma promoo. Cada ligao contabiliza somente um pulso,
independente do nmero de minutos de conversao.
Desenhe o diagrama de casos de uso

Carlos aposta toda semana na Loteria, em jogos como quina, megasena, fotomania, etc. So
vrios cartes por semana. Na hora de conferir uma loucura. Certa vez, quase que ele confere o
carto errado.
Para resolver isso, ele quer desenvolver uma aplicao que cadastre os cartes apostados e o
resultado de um concurso, apresentando o relatrio final com os nmeros acertados por carto e o
valor do prmio, se houver.
Exerccio (Biblioteca)
Identifique os atores e elabore o diagrama de casos de uso para o sistema de controle de uma
biblioteca descrito a seguir:
um sistema de suporte para uma biblioteca
A biblioteca empresta livros e revistas para clientes, que so registrados no sistema, no qual
tambm esto registrados os livros e as revistas.
A biblioteca controla a compra de novos ttulos. De ttulos populares compra-se vrias cpias.
Livros antigos e revistas so removidos quando esto ultrapassados ou deteriorados.
Bibliotecrio um funcionrio da biblioteca que interage com os clientes e seu trabalho
auxiliado pelo sistema.
Um cliente pode reservar um livro ou revista que no est disponvel no momento na biblioteca,
de forma que quando ele for devolvido ou comprado pela biblioteca, o cliente avisado. A reserva
cancelada quando o cliente retira o livro ou revista, ou atravs de um processo exclusivo de
cancelamento.
A biblioteca pode facilmente criar, atualizar, e apagar informaes sobre seus ttulos, clientes,
emprstimos, e reservas no sistema.
O sistema pode rodar em todos os ambientes populares (UNIX, Linux, windows, etc) e tem uma
interface grfica (GUI) moderna.
O sistema deve ser facilmente estendido com novas funcionalidades
O sistema deve lidar com a mensagem que enviada ao cliente quando um ttulo reservado
torna-se disponvel, e precisa checar se um determinado ttulo est ultrapassado ou deteriorado.
Exerccio (Coca-Cola)
Identifique os atores e elabore o diagrama de casos de uso para um sistema de controle de uma
mquina que vende Coca-Cola, descrito a seguir:
um sistema de venda de Coca-cola em mquina automatizada.
O sistema deve estar preparado para receber e conferir o dinheiro colocado pelo Cliente,
inclusive para dar o troco.
Deve controlar a recarga de refrigerantes pelo Tcnico, bem como o recolhimento do dinheiro da
mquina.
3. Diagrama de Classes
Diagrama de Classes
Introduo
O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas
representam as "coisas" que so gerenciadas pela aplicao modelada. Classes podem se relacionar
com outras atravs de diversas maneiras: associao (conectadas entre si), dependncia (uma classe
depende ou usa outra classe), especializao (uma classe uma especializao de outra classe), ou em
pacotes (classes agrupadas por caractersticas similares).
Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas
estruturas internas, que so os atributos e operaes. O diagrama de classes considerado esttico j
que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema.
Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes
que esto inseridas em um nico diagrama e uma certa classes pode participar de vrios diagramas de
classes.
Escopo ou Visibilidade
+, -, # (protected), ~ (friend/pacote). Visibilidade do elemento.
Figura 3.1: diagrama de classes.
Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o

compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que possuir
a relao de atributos que a classe possui em sua estrutura interna, e o compartimento de operaes,
que sero o mtodos de manipulao de dados e de comunicao de uma classe com outras do
sistema. A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem
de programao, embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
Pacotes
Pacote um mecanismo de agrupamento, onde
todos os modelos de elementos podem ser agrupados.
Em UML, um pacote definido como: "Um mecanismo
de
propsito
geral
para
organizar
elementos
semanticamente relacionados em grupos." Todos os

modelos
de
referenciados
elementos
por
um
que
pacote
so
so
ligados
chamados
ou
de
"Contedo do pacote". Um pacote possui vrios

modelos de elementos, e isto significa que estes no
podem ser includos em outros pacotes.
Pacotes podem importar modelos de elementos
Figura 3.2: pacotes.
de outros pacotes. Quando um modelo de elemento

importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os
pacotes possuem relacionamentos com outros pacotes. Embora estes no possuam semnticas
definidas para suas instncias. Os relacionamentos permitidos entre pacotes so de dependncia,
refinamento e generalizao (herana).
O pacote tem uma grande similaridade com a agregao (relacionamento que ser tratado em
seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregao de
composio. Se este for destrudo, todo o seu contedo tambm ser.
Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas
entidades. Os relacionamentos podem ser dos seguintes tipos:
Associao: uma conexo entre classes, e tambm significa que uma conexo entre
objetos daquelas classes. Em UML, uma associao definida com um relacionamento
que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as
duplas de objetos ligados.
Generalizao: um relacionamento de um elemento mais geral e outro mais especfico.

O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia
(um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada
onde o elemento mais geral seja permitido.
Dependncia e Refinamentos: Dependncia um relacionamento entre elementos, um

independente e outro dependente. Uma modificao um elemento independente
afetar
diretamente
elementos
dependentes
do
anterior.
Refinamento
um
relacionamento entre duas descries de uma mesma entidade, mas em nveis diferentes
de abstrao.
Abordaremos agora cada tipo de relacionamento e suas respectivas sub-divises:
Associaes
Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando
por exemplo que elas "conhecem uma a outra", "esto conectadas com", "para cada X existe um Y" e
assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas
complexos.
Associaes Normais
O tipo mais comum de associao apenas uma conexo entre classes. representada por uma
linha slida entre duas classes. A associao possui um nome (junto linha que representa a
associao), normalmente um verbo, mas substantivos tambm so permitidos.
Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada
para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um
nome para cada sentido da associao.
Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos
esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou
apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm
possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrito nenhuma
multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).
Figura 3.3: associao.
No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente se

relacionam por associao.
Associao Recursiva
possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa
semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe. Uma
associao deste tipo chamada de associao recursiva.
Figura 3.4: associao recursiva.
Associao Qualificada
Associaes qualificadas so usadas com associaes de um para vrios (1..*) ou vrios para
vrios (*).
Figura 3.5: associao qualificada.
O "qualificador" (identificador da associao qualificada) especifica como um determinado objeto

no final da associao "n" identificado, e pode ser visto como um tipo de chave para separar todos os
objetos na associao. O identificador desenhado como uma pequena caixa no final da associao
junto classe de onde a navegao deve ser feita.
Associao Exclusiva
Em alguns modelos nem todas as combinaes so vlidas, e isto pode causar problemas que
devem ser tratados. Uma associao exclusiva uma restrio em duas ou mais associaes. Ela
especifica que objetos de uma classe podem participar de no mximo uma das associaes em um
dado momento. Uma associao exclusiva representada por uma linha tracejada entre as associaes
que so parte da associao exclusiva, com a especificao "{ou}" sobre a linha tracejada.
Figura 3.6: associao exclusiva.
No diagrama acima um contrato no pode se referir a uma pessoa e a uma empresa ao mesmo
tempo, significando que o relacionamento exclusivo a somente uma das duas classes.
Associao de Classe
Uma classe pode ser associada a uma outra
associao. Este tipo de associao no conectado
a nenhuma das extremidades da associao j
existente, mas na prpria linha da associao. Esta
associao serve para se adicionar informaes
extras a associao j existente.
A associao da classe Fila com a associao
Figura 3.7: associao de classe.
das classes Cliente e Processo pode ser estendida com operaes de adicionar processos na fila, para
ler e remover da fila e de ler o seu tamanho. Se operaes ou atributos so adicionados a associao,
ela deve ser mostrada como uma classe.
Agregao e Composio
Agregao
A agregao um caso particular da associao. A agregao indica que uma das classes do
relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para
identificar uma agregao so: "consiste em", "contm", " parte de".
Figura 3.8: agregao.
Existem tipos especiais de agregao que so as agregaes compartilhadas e as compostas.

Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou est
contida na outra, mas esta parte pode fazer estar contida na outra vrias vezes em um mesmo
momento.
Figura 3.9: agregao compartilhada.
No exemplo acima uma pessoa pode ser membro de um time ou vrios times e em determinado
momento.
Composio
Agregao de Composio: uma agregao onde uma classe que est contida na outra "vive"
e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de
composio sero destrudas juntamente j que as mesmas fazem parte da outra.
Figura 3.10: agregao de composio.
Generalizaes
Definio
A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O
elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais
particularidades. Um objeto mais especfico pode ser usado como uma instncia do elemento mais
geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados
em outros.
Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So
elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de
sobreposio, disjuntiva, completa e incompleta.
Generalizao Normal
Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe
mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdadas.
Figura 3.11: generalizao normal.
Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa
hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes.
A generalizao normal representada por uma linha entre as duas classes que fazem o
relacionamento, sendo que coloca-se um seta no lado da linha onde encontra-se a superclasse
indicando a generalizao.
Observao: a herana deve ser natural. Ao criar uma girafa, nenhum programador deveria
estender elefante s porque precisa de algo com quatro patas. Seno, no futuro, podemos acabar
tendo uma girafa com tromba...
Dependncias e Refinamentos
Definio
Alm das associaes e generalizaes, existem ainda dois tipos de relacionamentos em UML. O
relacionamento de dependncia uma conexo semntica entre dois modelos de elementos, um
independente e outro dependente. Uma mudana no elemento independente ir afetar o modelo
dependente. Como no caso anterior com generalizaes, os modelos de elementos podem ser uma
classe, um pacote, um use-case e assim por diante. Quando uma classe recebe um objeto de outra
classe como parmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma
dependncia entre estas duas classes, apesar de no ser explcita.
Uma relao de dependncia simbolizada por uma linha tracejada com uma seta no final de
um dos lados do relacionamento. E sobre essa linha o tipo de dependncia que existe entre as duas
classes. As classes "Amigas" provenientes do C++ so um exemplo de um relacionamento de
dependncia.
Figura 3.12: dependncia.
Os refinamentos so um tipo de relacionamento entre duas descries de uma mesma coisa,

mas em nveis de abstrao diferentes e podem ser usados para modelar diferentes implementaes de
uma mesma coisa (uma implementao simples e outra mais complexa, mas tambm mais eficiente).
Os refinamentos so simbolizados por uma linha tracejada com um tringulo no final de um dos
lados do relacionamento e so usados em modelos de coordenao. Em grandes projetos, todos os
modelos que so feitos devem ser coordenados. Coordenao de modelos pode ser usada para mostrar
modelos em diferentes nveis de abstrao que se relacionam e mostram tambm como modelos em
diferentes fases de desenvolvimento se relacionam.
Figura 3.13: refinamento.
Exerccios
Um estudo de caso em UML
Diante do apresentado no decorrer do trabalho, aplicaremos aqui grande parte dos conceitos
abordados diante de uma aplicao da UML num problema fictcio que poder ser de grande ajuda no
melhor entendimento das potencialidades da linguagem de modelagem unificada.
O estudo de caso dar mais nfase na fases de anlise de requisitos, anlise e design, j que as
principais abstraes dos modelos do sistema se encontram nestas fases do desenvolvimento.
Desenvolveremos uma modelagem em UML para criarmos um sistema de manuteno e
controle de contas correntes e aplicaes financeiras de um banco fictcio.
Antes de dar incio primeira fase da modelagem, faremos algumas consideraes sobre o que
o sistema se prope a fazer e outras observaes que consideramos de suma importncia para o bom
entendimento do problema.
O sistema suportar um cadastro de clientes, onde cada cliente cadastrado poder ter
vrias contas correntes, vrios dependentes ligados a ele, e vrias contas de poupana.
Cada dependente poder possuir vrias contas de poupana, mas no podero ter uma
conta corrente prpria.
Entendemos poupana como uma conta que possui um valor, um prazo de aplicao a
uma taxa de juros (definida no vencimento da poupana).
Entendemos Aplicaes Pr-fixadas como uma aplicao de um valor, em um prazo

predeterminado a uma taxa de juros previamente definida.
Tanto a conta corrente quanto a poupana devero manter um histrico de todas as

movimentaes de crdito, dbito, transferncias e aplicaes de pr-fixados (prfixados apenas para conta corrente).
Uma conta corrente poder ter vrias aplicaes pr-fixadas ligadas a ela.
4. Diagrama de Atividades e de Sequncia

Diagrama de Atividades
Introduo
Um diagrama de atividades UML mostra atividades sequenciais e paralelas em um processo. Eles
so teis para modelagem de processos de negcios, fluxos de trabalho (workflows), fluxos de dados e
algoritmos complexos.
Uma atividade o estado de estar fazendo uma ao: tanto um processo de mundo real, como
realizar um exerccio, ou a execuo de uma rotina de software, tal como um mtodo em uma classe.
O diagrama de atividades descreve a sequncia de atividades, com suporte para comportamento
condicional e paralelo. Um diagrama de atividades uma variante de um diagrama de estados no qual
a maioria, se no todos, dos estados estado de atividade. Portanto, muito da terminologia segue a
mesma terminologia de estados.
Na figura 1 o smbolo central o estado de atividade, ou simplesmente atividade.

Incio
Receber
o Pedido
Separao
Atividade
Preencher
o Pedido
Guarda
Envia a
Fatura
Desvio
[Seno]
[Pedido Urgente]
Entrega Durante
a Noite
Entrega
Regular
Recebe o
Pagamento
Intercalao
Juno
Fechar
o Pedido
Fim
Fig. 1: Diagrama de Atividades
Como aplicar os diagramas de atividade?

Um diagrama de atividades da UML oferece uma notao rica para mostrar uma sequncia de
atividades, inclusive atividades paralelas. Ele pode ser aplicado em qualquer perspectiva ou propsito,
mas mais popular para visualizar fluxos de trabalho e processos de negcios, alm de casos de uso.
Modelagem de processo de negcios: Um de meus clientes est no negcio de entrega expressa
de mercadorias. O processo de despachar um pacote bastante no trivial; existem muitas partes
envolvidas (cliente, motorista, ...) e muitos passos. Embora este processo possa ser capturado por um
texto (no texto do caso de uso), neste caso os diagramas de atividades representam um excelente
exemplo de que figuras valem por mil palavras. Meu cliente usa diagramas de atividades para entender
seus atuais e complexos processos de negcio por meio de sua visualizao. As parties so teis
para ver as vrias partes envolvidas e as aes paralelas envolvidas no processo de despacho. Os ns
de objetos ilustram o que est sendo movimentado de um lado para outro. Depois de modelar seus
processos atuais, eles exploram visualmente mudanas e otimizaes.
Modelagem de fluxo de dados: A partir dos anos 70, diagramas de fluxos de dados (DFD)
tornaram-se uma forma popular de visualizar os principais passos e dados envolvidos em processos de
sistemas de software. Isso no equivale modelagem de processos de negcios; em vez disso, DFDs
eram geralmente usados para mostrar fluxos de dados em um sistema computacional, embora
teoricamente pudessem ser aplicados modelagem de processos de negcios. DFDs eram teis para
documentar os principais fluxos de dados ou para explorar um novo projeto de alto nvel em termos de
fluxo de dados. Veja a figura 13 para um exemplo de um DFD na notao clssica de Gane-Sarson.
Observe que os passos do processo so numerados, para indicar a ordem.
Figura 13: DFD Clssico, na notao Gane-Sarson.
A informao modelada em um DFD til, tanto para documentao quanto para descoberta,
mas a UML no inclui a notao para DFD. Felizmente, os diagramas de atividade da UML podem
satisfazer os mesmos propsitos eles podem ser usados para modelagem de fluxo de dados,
substituindo a notao tradicional dos DFDs. A Figura 14 ilustra a mesma informao do DFD da Figura
13, mas usando um diagrama de atividades da UML. Note que alm de podermos usar os ns de objeto
para mostrar os fluxos de dados, os ns dos armazns de dados (datastore nodes) da UML podem
ser usados.
Figura 14: Aplicao da notao de

diagramas de atividades para mostrar um
modelo de fluxo de dados.
Programao concorrente e modelagem de algoritmos paralelos: Embora os detalhes estejam
fora do escopo desta introduo, algoritmos paralelos em problemas de programao concorrente
envolvem parties mltiplas e comportamento de fork e juno. Por exemplo, tais algoritmos so
usados em simulaes 3D com elementos finitos ou modelagem por diferenas finitas, sendo aplicados
para modelagem de reservas de petrleo, anlise de resistncia de materiais e modelagem do tempo.
O espao fsico global dividido em blocos grandes e muitas linhas de execuo (ou processos)
paralelas executam, uma para cada sub-bloco. Nesses casos, as parties dos diagramas de atividade
UML podem ser usadas para representar diferentes linhas ou processos do sistema em operao. Os
ns de objeto podem ser usados para modelar os dados e objetos compartilhados. E, claro, forking
pode ser usado para modelar a criao e execuo paralela de mltiplas linhas ou processos, um por
partio.
Comportamento Condicional
Comportamento condicional delineado por desvios (branches) e intercalaes (merges). Um
desvio (branch) uma transio de entrada nica e vrias transies de sada guardadas. Somente
uma transio de sada pode ser tomada, de modo que os guardas devem ser mutuamente exclusivos.
A utilizao de [else] como um guarda indica que a transio else dever ser usada se todos os
outros guardas do desvio forem falsos. Uma intercalao (merge) tem mltiplas transies de
entrada e uma nica sada. Um merge marca o final de um comportamento condicional iniciado por um
branch.
Comportamento paralelo indicado por separaes (forks) e junes (joins). Uma separao
(fork) tem uma transio de entrada e vrias transies de sada. Quando uma transio de entrada
acionada (triggered) todas as transies de sada so executadas em paralelo. Quando temos
comportamento paralelo, precisamos sincronizar. Com a juno (join) a transio seguinte efetuada
somente quando todos os estados nas transies de entrada tenham completado suas atividades.
O diagrama de atividades permite escolher a ordem em que as coisas vo ser feitas. Ele
simplesmente determina as regras essenciais de sequncias que devem ser seguidas. Esta a
diferena-chave entre um diagrama de atividades e um fluxograma: os fluxogramas so normalmente
limitados a processos sequenciais, enquanto que os diagramas de atividades podem lidar com
processos paralelos.
Os diagramas de atividades tambm so teis para programas concorrentes, uma vez que
possvel projetar graficamente quais caminhos (threads) temos e quando eles precisam ser
sincronizados.
Separao e juno devem se completar. Isso significa que toda vez que tiver uma separao deve
haver uma juno que una as threads iniciadas por aquelas separaes.
Entretanto, existem vrias extenses para esta regra:
Um thread que sai de uma separao pode abrir-se em uma nova separao, com os novos
threads juntando-se antes de alcanar a juno da primeira separao.
Se um thread saindo de uma separao vai direto para outra separao, podemos remover a
segunda separao e somente ter os threads da segunda separao saindo da primeira
separao. De modo semelhante, se uma juno vai direto para outra juno, podemos
eliminar a primeira juno e ter as threads indo direto para a segunda.
Uma construo avanada chamada de estado de sincronia permite que faamos sincronia
em lugares onde a regra de encaixe de separao e juno impediria que fizssemos isso.
Existe uma exceo para regra de que todos os estados de entrada em uma juno devem ter
terminado suas atividades, antes que a juno possa ser efetuada. Podemos acrescentar uma condio
para um thread saindo de uma separao. O resultado um thread condicional. Durante a execuo,
se a condio de um thread condicional for falsa, este thread considerado completado no que diz
respeito juno.
Separao removida
do diagrama
[a fim de vinho]
Cozinhar
Espaguete
Misturar Molho
Carbonara
Thread
Condicional
Abrir Vinho
Tinto
Combinar
Fig 2:
Separaes, Junes e Thread Condicionais
Decompondo uma Atividade

Uma atividade pode ser dividida em subatividades. Isso funciona mais ou menos como
superestados e subestados em um diagrama de estados. Voc pode somente mostrar o superestado no
diagrama-pai, ou pode mostrar o superestado no seu comportamento externo dentro dele.
As vantagens dos estados de fim e incio explcitos so que uma atividade de entrega pode ser
usada em outros contextos, e o diagrama-pai desacoplado dos contedos do diagrama subsidirio.
Como podemos mostrar que uma atividade expandida em outro diagrama de atividades? As
figuras 15 e 16 ilustram isso, usando o smbolo de um ancinho.
Como podemos mostrar ramos condicionais? Veja o smbolo de deciso usado na Figura 16. O
smbolo correspondente para juno mostra como os fluxos podem voltar a ficar juntos.
Figura
15:
Uma
atividade
ser expandida em outro diagrama.

Sinais so mostrados na Figura 17. Eles so teis, por exemplo, quando voc precisa modelar
eventos como o disparo de uma ao, ou uma solicitao de cancelamento.
Figura 16: A expanso de uma atividade.

Existe muito mais notao UML disponvel para diagramas de atividades. Esta pequena
introduo destaca meramente alguns dos elementos mais comuns.
Figura 17: Sinais.
Concorrncia Dinmica
Concorrncia dinmica permite que voc mostre iteraes sem que tenha que construir um
ciclo. Ou seja, permite representar a repetio de uma atividade.
Concorrncia Dinmica
Receber o
Pedido
*
Preencher Linha
de Item
Entregar
Pedido
Fig 4: Concorrncia Dinmica
Raias (Swimlanes)
Para usar raias, voc deve organizar seus diagramas de atividade em zonas verticais separadas
por linhas. Cada zona representa as responsabilidades de uma classe especfica ou, um departamento
especfico.
As raias so teis porque combinam a descrio de lgica do diagrama de atividades com a

descrio de responsabilidade do diagrama de interao.
Figura 18: Modelagem do caso de uso Processar

Venda com um diagrama de atividades.
Quando utilizar Diagramas de Atividades?

Os diagramas de atividades tm qualidades e fraquezas definidas, por isso a melhor maneira de
us-los em combinao com outras tcnicas. A maior qualidade dos diagramas de atividades est no
fato de que eles suportam e encorajam comportamento paralelo. A maior desvantagem destes
diagramas que eles no deixam muito claras as ligaes entre aes e objetos.
Voc pode definir uma ligao para um objeto rotulando uma atividade com um nome de objeto
ou usando raias que dividem um diagrama de atividades em base em responsabilidades, mas isso no
tem a clareza simples de diagramas de interao. Por esta razo, algumas pessoas sentem que
diagramas de atividades no so orientados a objetos e, portanto, so maus.
Devemos utilizar diagramas de atividades nas seguintes situaes:
Analisando um caso de uso.
Compreendendo workflow
Descrevendo um algoritmo sequencial complicado
Lidando com aplicaes de processamento paralelo.
No devemos usar diagramas de atividades nas seguintes situaes:
Tentando ver como os objetos colaboram.
Tentando ver como um objeto se comporta durante o seu ciclo de vida.
Representando lgica condicional existente.
O diagrama de estados e diagramas de atividades faz com que exista uma base mais estvel
para os desenvolvedores de ferramentas construrem as que executaro estes diagramas.
Diagramas de Sequncia
Introduo
A UML inclui diagramas de interao para ilustrar como os objetos interagem por meio de
mensagens. Eles so usados para modelagem de objetos dinmica. H dois tipos comuns de diagramas
de interao: diagramas de sequncia e de comunicao.
O termo diagrama de interao uma generalizao de dois tipos de diagramas
especializados da UML: diagramas de sequncia e diagramas de comunicao. Ambos podem expressar
interaes semelhantes.
Diagramas de sequncia so os mais ricos dos dois tipos em termos de notao, mas diagramas
de comunicao tambm tm sua utilidade, especialmente para rascunho na parede.
Os diagramas de sequncia ilustram as interaes em um formato semelhante a cercas, nas
quais cada objeto novo acrescentado direita, conforme mostrado na Figura 19.
Figura 19: Diagrama de sequncia.

O que isso poderia representar em cdigo? Provavelmente, que a classe A tem um mtodo
denominado fazerUm e um atributo do tipo B. Tambm que a classe B tem mtodos chamados
fazerDois e fazerTres. Talvez a definio parcial da classe A seja:
public class A
{
private B meuB = new B();
public void fazerUm()
{
meuB.fazerDois();
meuB.fazerTres();
}
...
}
Um diagrama de sequncia do sistema um artefato criado rpida e facilmente que ilustra os

eventos de entrada e sada relacionados com o sistema em discusso. Eles so entradas para contratos
de operao e mais importante projeto de objetos.
A UML contm notao na forma de diagramas de sequncia para ilustrar eventos provenientes
de atores externos ao sistema.
A influncia dos artefatos do PU enfatizando diagramas de sequncia de sistema mostrada na
Figura 20. O texto do caso de uso e seus eventos implcitos no sistema so entradas para a criao do
DSS. As operaes do DSS (tais como entrarItem) podem, por sua vez, ser analisadas nos contratos de
operao, detalhadas no Glossrio, e mais importante servir como ponto de partida para projetar
objetos de colaborao.
Figura 20: Amostra da influncia dos artefatos no PU.
Na maioria dos casos, usamos um diagrama de sequncia para ilustrar as realizaes de casos
de uso, isto , para mostrar como os objetos interagem para executar o comportamento total ou
parcial de um caso de uso. Um ou mais diagramas de sequncia podem ilustrar as interaes de
objetos que constituem um caso de uso. Uma organizao tpica deve ter um diagrama de sequncia
para o fluxo principal de eventos e um diagrama de sequncia para cada subfluxo independente do
caso de uso.
Os diagramas de sequncia
ncia so muito importantes para designers porque eles esclarecem os
papis
dos
objetos
em
um
fluxo
e,
portanto,
fornecem
entrada
bsica
para
determinar
responsabilidades
bilidades de classe e interfaces.
Diferentemente de um diagrama de colaborao, um diagrama de sequ
sequncia inclui sequncias,
mas no inclui relacionamentos de objetos. Ambos expressam informaes semelhantes; o que muda
a forma como elas so mostradas. Os diagramas de sequncia
ncia mostram a sequncia
seq
explcita de
mensagens e so melhores quando importante visualizar a ordenao temporal das mensagens.
Quando voc estiver interessado nos relacionamentos estruturais entre as instncias de uma interao,
use um diagrama de colaborao.
Contedo de Diagrama de Sequncia

Voc pode ter objetos e instncias de ator em diagramas de sequ
seq ncia, juntamente com
mensagens que descrevem como eles interagem. O diagrama descreve o que ocorre nos objetos
participantes, em termos de ativaes, e como os objetos se comunicam enviando mensagens uns aos
outros. possvel fazer um diagrama de sequncia para cada variante do fluxo de eventos de um caso
de uso.
Figura 21: Um diagrama de seqncia que descreve parte

do fluxo de eventos do caso de uso Colocar Ligao Local em uma
Central Telefnica simples.
Objetos
Um objeto mostrado como uma linha tracejada vertical denominada
denominada "linha de vida". A linha de
vida representa a existncia do objeto em um momento especfico. Um smbolo de objeto foi
desenhado no alto da linha de vida e mostra o nome do objeto e sua classe sublinhada e separada por
dois-pontos:
objectname : classname
FAETEC 2012
12 - Notas de Aula de MD3 Prof. M. Frana Pgina: 62
Voc pode usar objetos em diagramas de sequncia das seguintes formas:
a) Uma linha de vida pode representar um objeto ou sua classe. Portanto, a linha de vida pode
ser usada para modelar tanto o comportamento da classe quanto do objeto. Contudo, em geral,
uma linha de vida representa todos os objetos de uma determinada classe.
b) Uma classe de objeto pode no estar especificada. Geralmente, voc cria primeiro um
diagrama de sequncia com objetos e mais tarde especifica as suas classes.
c) Os objetos podem no ter nome, mas recomendvel nome-los se voc quiser diferenciar os
diversos objetos da mesma classe.
d) Vrias linhas de vida no mesmo diagrama podem representar objetos diferentes da mesma
classe; mas, como foi dito anteriormente, os objetos devem ser nomeados para que voc possa
estabelecer a diferena entre os dois objetos.
e) Uma linha de vida que representa uma classe pode existir paralelamente a linhas de vida que
representam objetos daquela classe. O nome do objeto da linha de vida que representa a classe
pode ser definido com o nome da classe.
Atores
Geralmente, uma instncia de ator representada pela primeira (mais esquerda) linha de vida
no diagrama de sequncia, como o disparador da interao. Se houver vrias instncias de atores no
mesmo diagrama, tente mant-las na linha de vida mais esquerda ou na linha mais direita.
Mensagens
Uma mensagem uma comunicao entre objetos que leva informaes na expectativa de que
resulte uma atividade; nos diagramas de sequncia, uma mensagem mostrada como uma seta slida
horizontal partindo da linha de vida de um objeto para a linha de vida de outro objeto. No caso de uma
mensagem de um objeto para si mesmo, a seta pode iniciar e terminar na mesma linha de vida. A seta
rotulada com o nome da mensagem e seus parmetros. Ela tambm pode ser rotulada com um
nmero que indique a sequncia da mensagem no processo geral de interao. Os nmeros
sequenciais em geral so omitidos em diagramas de sequncia, nos quais a localizao fsica da seta
mostra a sequncia relativa.
Uma mensagem pode ser no-atribuda, o que significa que seu nome uma sequncia de
caracteres temporria que descreve o sentido geral da mensagem e no o nome de uma operao do
objeto recebedor. Mais tarde, voc poder atribuir mensagem especificando a operao do objeto de
destino da mensagem. A operao especificada substituir ento o nome da mensagem.
Tipos de Mensagem
Mensagem de Criao
Aponta diretamente para o objeto e marcada com create
Mensagem de Retorno
Opcional, e normalmente omitida
Usa seta tracejada
Marca de Destruio
Indica o trmino da vida de um objeto com um X
Figura 22: Mensagens.
Mensagem Sncrona x Assncrona

possvel utilizar dois tipos de mensagem de mtodos no diagrama de sequncia:
Mensagem sncrona (seta cheia): a execuo fica bloqueada at o retorno do
mtodo.
Mensagem assncrona (seta vazia): a execuo continua em paralelo ao mtodo que
foi chamado (fork implcito).
Figura 23: Mensagens Sncronas e

Assncronas.
Scripts
Os scripts descrevem o fluxo de eventos textualmente em um diagrama de sequncia. Voc
deve posicionar os scripts esquerda das linhas de vida para poder ler o fluxo completo de cima para
baixo (consulte a Figura 21). Voc pode anexar scripts a uma determinada mensagem assegurando,
assim, que o script se mova com a mensagem.
Distribuio de Fluxo de Controle

O controle centralizado de um fluxo de eventos ou de parte do fluxo de eventos significa que
poucos objetos guiam o fluxo trocando mensagens com outros objetos. Esses objetos controladores
decidem a ordem em que outros objetos sero ativados no caso de uso. A interao entre os objetos
restantes mnima ou inexistente.
Exemplo:
No Sistema da Mquina de Reciclagem, o caso de uso Imprimir Relatrio Dirio controla,
entre outros, o nmero e o tipo de objetos retornados, e escreve a contagem em um recibo. O objeto
de controle Gerador de Relatrio decide a ordem em que os totais sero extrados e escritos.
Figura
24:
estrutura
de
comportamento do caso de uso Imprimir

Relatrio Dirio centralizada no objeto
de controle Gerador de Relatrio.
Esse um exemplo de comportamento centralizado. A estrutura de controle centralizada
principalmente porque as diferentes fases de subeventos do fluxo de eventos no dependem umas das
outras. A principal vantagem desse mtodo que cada objeto no precisa controlar a contagem do
objeto seguinte. Para mudar a ordem das fases de subeventos, basta fazer a mudana no objeto de
controle. Ainda ser possvel adicionar facilmente outra fase de subevento se, por exemplo, for includo
um novo tipo de item retornvel. Outra vantagem dessa estrutura que voc pode facilmente reutilizar
as vrias fases de subeventos em outros casos de uso, porque a ordem de comportamento no est
embutida nos objetos.
O controle descentralizado surge quando os objetos participantes se comunicam diretamente
entre si, e no atravs de um ou mais objetos controladores.
Exemplo: No caso de uso Enviar Carta algum remete uma carta para outro pas atravs de
uma agncia de correio. Primeiro, a carta enviada para o pas do destinatrio. No pas, a carta
enviada para uma cidade especfica. A cidade, por sua vez, envia a carta para a residncia do
destinatrio.
Figura 25: A estrutura de comportamento do

caso de uso Enviar Carta descentralizada.
O comportamento do caso de uso um fluxo de eventos descentralizado. As fases de
subeventos integram o conjunto. O remetente da carta fala em "enviar uma carta a algum". Ele no
precisa nem deseja saber os detalhes de como as cartas so enviadas em pases ou cidades.
(Provavelmente, se algum remetesse uma carta dentro do mesmo pas, nem todas as aes
ocorreriam.)
O tipo de controle usado depende do aplicativo. Geralmente, voc deve tentar conseguir objetos
independentes, isto , delegar vrias tarefas aos objetos naturalmente mais apropriados a execut-las.
Figura 26: Uma estrutura de controle centralizada "em forma de

forquilha". Uma estrutura de controle descentralizada "em forma de
escada".
Um fluxo de eventos com controle centralizado ter um diagrama de sequncia "em forma de
forquilha". Por outro lado, um diagrama de sequncia "em forma de escada" ilustra que a estrutura de
controle foi descentralizada para os objetos participantes.
A estrutura de comportamento da realizao de um caso de uso frequentemente consiste em
uma mistura de comportamento centralizado e descentralizado.
Uma estrutura descentralizada ser adequada:
Se as fases de subevento estiverem intrinsecamente acopladas. Esse ser o caso se os objetos

participantes:
o Formarem uma hierarquia de partes ou constituintes, como Pas - Estado - Cidade;
o Formarem uma hierarquia de informaes, como CEO - Gerente de Diviso - Gerente de
Seo;
Representarem uma progresso cronolgica fixa (a sequncia de fases de subeventos ser sempre
realizada na mesma ordem), como Anncio - Pedido - Fatura -Remessa - Pagamento; ou
Formarem uma hierarquia de herana conceitual, como Animal - Mamfero - Gato.

Se voc desejar encapsular a funcionalidade e, portanto, fazer abstraes dela. Isso bom para
algum que deseje utilizar sempre a funcionalidade inteira, porque a funcionalidade pode se tornar
desnecessariamente de difcil compreenso caso a estrutura de comportamento seja centralizada.
Uma estrutura centralizada ser adequada:
Se a ordem em que as fases de subeventos sero executadas puder ser mudada.
Se voc espera inserir novas fases de subeventos.
Se voc deseja manter partes da funcionalidade reutilizveis como peas separadas.
Repeties
O diagrama de sequncia permite que repeties sejam feitas durante o fluxo. Para isso so
utilizados quadros (frames) do tipo loop.
Decises
O diagrama de sequncia permite que decises sejam tomadas durante o fluxo
Para isso so utilizados quadros (frames) do tipo alt ou opt com condies de guarda
Exemplo:
Motivao: por que desenhar um DSS?

Uma questo interessante til no projeto de software a seguinte: que eventos esto
entrando no nosso sistema? Por qu? Porque temos que projetar o software para tratar esses eventos
(desde o mouse, teclado, outro sistema, ...) e executar uma resposta. Basicamente, um sistema de
software reage a trs coisas: (1) eventos externos de atores (seres humanos ou computadores), (2)
eventos de tempo e (3) falhas ou excees (que frequentemente so de fontes externas).
Portanto, til saber quais, precisamente, so os eventos externos de entrada os eventos do
sistema. Eles so uma parte importante da anlise do comportamento do sistema.
Voc pode estar familiarizado com a ideia de identificar as mensagens que entram em um
objeto de software. Mas esse conceito til em um nvel mais alto de componentes, inclusive todo o
sistema visto (abstratamente) como uma coisa ou objeto.
Antes de prosseguir para um projeto detalhado de como uma aplicao de software vai
funcionar, til investigar e definir seu comportamento como uma caixa-preta. Comportamento do
sistema uma descrio do que um sistema faz, sem explicar como o faz. Uma parte dessa descrio
um diagrama de sequncia do sistema. Outras partes incluem os casos de uso e os contratos de
operao do sistema.
Exemplo:
Figura
27:
Escolher
os
nomes
de
eventos e de operaes no nvel abstrato.
Exerccios
Diagramas de Atividades
1. Qual a finalidade do Diagrama de Atividades?
2. Quando recomendado utilizar raias na descrio do diagrama de atividades?
3. Compare barra de Juno x Barra de Bifurcao
4. Construa o diagrama de atividades que descreva o processo de compras on-line
(Ex.Submarino, Americanas)
5. Construa o diagrama de atividades que modele as regras de negcio das avaliaes do
semestre, considerando o seguinte mini-mundo:
Faltas (25%)
Avaliaes das unidades (Trs)
Prova final (mdia 5,0)
Media final=Media unidade (Peso 7) e prova final (Peso 3)
1 - Construa os Diagramas de Sequncia para o Caso de Uso Reservar Carro:
Nota: somente clientes j cadastrados podero fazer a reserva do veculo on-line.
2 - Sistema de Vendas de Livros On-Line

Criar o Diagrama de Sequncia para o Caso de Uso Cadastrar Livro, tendo como referncia
a tela de cadastramento apresentada abaixo. Observe que esta mesma tela dever ser preenchida por
dois atores diferentes. Primeiro o Funcionrio, depois o Gerente registrando os preos de compra e
venda.
3. Construa um Diagrama de Seqncia para abrir uma conta, conforme a descrio

abaixo:
O cliente que deseja abrir uma conta no banco, encaminha um pedido de abertura de conta,
com a documentao necessria. O funcionrio do banco, ento ir consultar o cadastro do cliente por
meio do seu CPF, para determinar se o solicitante j se encontra cadastrado. Se o cliente j estiver
cadastrado, a consulta retornar as informaes do cliente, caso contrrio retornar um valor
significando que o cliente ainda no possui cadastro na instituio. Em seguida, o cadastro do cliente
poder ser atualizado, caso necessrio, podendo gerar uma nova instncia da classe Cliente, se o
solicitante ainda no estiver registrado, ou simplesmente atualizar os dados do mesmo, se houver
necessidade de alguma atualizao.
Antes de finalizar a atualizao do cliente, algumas inconsistncias devem ser levadas a efeito,
uma delas o disparo do mtodo para validao do CPF pelo prprio objeto da classe Cliente. Aps o
trmino da atualizao, o objeto da classe cliente retornar algum sinal para o funcionrio do banco,
para indicar que o cliente foi atualizado com sucesso ou se ocorreu algum erro.
O banco ento ir informar ao cliente se o seu pedido foi ou no aprovado. Em caso de
aprovao, o cliente ir fornecer o valor inicial necessrio para a abertura da conta e escolher a
senha. O funcionrio ir disparar o mtodo de abertura na classe ContaComum, ou seja, criar um
novo objeto ContaComum.
Aps ter sido criado pela chamada do mtodo abertura, o objeto de ContaComum ir disparar o
mtodo gravar para gerar uma nova instncia da classe Historico, registrando o movimento gerado
pela abertura da conta, pois, para abrir uma conta, a instituio exige que o cliente deposite algum
valor na mesma. O mtodo gravar retornar um sinal indicando que o movimento foi registrado com
sucesso e o mtodo abertura disparado na classe ContaComum, por sua vez, retornar o nmero da
conta gerado, indicando que a conta foi criada com sucesso e finalizando o processo de abertura de
conta.
4. Construa um Diagrama de Seqncia encerrar uma conta, conforme a descrio
abaixo:
Primeiramente um cliente se encaminha ao caixa do banco, representado pelo ator Funcionario
e solicita o encerramento de uma determinada conta comum. O caixa ento ir verificar se a conta
informada realmente existe e se a senha informada verdadeira, por meio do disparo do mtodo
consulta. Caso a conta realmente exista, o prprio mtodo ir chamar o mtodo de validao de senha
para verificar se a senha informada pelo usurio est correta. Em caso positivo, ser verificado o saldo
da conta.
Se o saldo retornado for positivo, ento o caixa ir retirar o dinheiro da conta, o saque efetuado
dever ser registrado no histrico das movimentaes. Em seguida o objeto de ContaComum retornar
o valor do saldo para o atendente que dever ser igual a zero se o mtodo for executado com sucesso.
Finalmente o atendente ir chamar o mtodo encerramento para fechar a conta do cliente no
objeto de ContaComum. Antes de concluir a execuo, esse mtodo pode, caso a conta a ser encerrada
seja a nica possuda pelo cliente, atualizar o cadastro do mesmo, definindo o seu status como inativo,
por meio do mtodo gravar no objeto de Fisica.
Caso tenha sido possvel atualizar a instncia da classe Fsica, ento o mtodo gravar retornar
um valor indicando que o cliente foi atualizado. A conta retornar um valor que instruir o software
mostrar ao atendente a mensagem: Conta Encerrada com Sucesso, finalizando o processo de
encerramento de conta.
Referncias
Crise do Software - Alanderson (FNM, Engenharia da Computao)
Programao Orientada ao Objeto: uma abordagem didtica - UNICAMP
Conceitos de OO Prof. Cleidson Souza - Universidade Federal do Par
Apostila de Java e OO da CAELUM
Java Help da Oracle (em ingls)
Linguagem de Modelagem Unificada
Utilizando UML e Padres 3 edio Craig Larman
Object Management Group website at www.omg.org
6. Apndice A Questionrio de Avaliao do Curso

FAETEC Rio de Janeiro
Professor M. Frana
Disciplina:
Aluno:
__________
_______________________________________________
Data:
________
Perodo/Turma: ________
Observao: Solicite ao professor o endereo para preenchimento eletrnico.

Ateno: Procure dar respostas completas, evitando monosslabos: sim, no, , fui etc..
E no se esquea de perguntar ao professor sobre o 0,5 ponto relativo ao preenchimento deste.
1) O curso: O curso Tcnico em Informtica da Escola Tcnica Estadual Repblica possui um bom nvel? As
matrias so atuais e relevantes? Ele proporciona um ambiente para que alunos interessados possam adquirir
conhecimentos aplicveis profissionalmente?
2) A disciplina: A disciplina em questo (MD3) possui um contedo atual? O programa foi totalmente coberto? A
carga horria semanal foi suficiente para explanao e resoluo de exerccios? As aulas prticas (se for o
caso) foram suficientes e em condies adequadas (mquinas)?
3) O professor: O professor possua domnio da disciplina (conhecimento)? Ele explica bem (didtico)? Ele
cordial e atencioso para com os alunos? Ele estava sempre disposto a explicar novamente algum conceito mal
compreendido? Existe algum ponto positivo e/ou negativo no professor?
4) O aluno: Voc freqenta as aulas assiduamente? Voc faz os exerccios/estuda em casa? Voc presta ateno
na explicao do professor? Voc se considera um aluno agitado/disperso? Voc conseguiu aprender os
principais conceitos da disciplina? Voc tentou tirar suas dvidas com o professor?
5) Livre: Que sugestes, ou crticas, voc gostaria de fornecer para a melhoria do processo?
6) Nota: D uma nota para a disciplina (MD3), de 0 (muito insatisfeito) a 10 (muito satisfeito): ______
Muito obrigado. Desejo a todos muito sucesso profissional e boas frias; Sem radicalismos!
Teu corao livre.
Tenha coragem para segui-lo!
Brave Heart

Ap MD3 2012 Faetec

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ap MD3 2012 Faetec

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAO DE APOIO ESCOLA TCNICA

ESTADO DO RIO DE JANEIRO - FAETEC

MODELAGEM DE DADOS 3 MD3

Notas de Aula v1.0

Esta pgina foi deixada propositadamente em branco.

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 2

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 3

Esta pgina foi deixada propositadamente em branco.

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 4

Introduo ao Paradigma OO ..................................................................................... 7

Diagrama de Casos de Uso ...................................................................................... 23

Diagrama de Classes ............................................................................................... 45

Diagrama de Atividades e de Sequncia .................................................................... 53

Apndice A Questionrio de Avaliao do Curso ....................................................... 77

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 5

Esta pgina foi deixada propositadamente em branco.

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 6

mtodos que foram

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 7

A Crise do Software e a Idade Mdia

Causas da Crise do Software

Projetos estourando o oramento;

Projetos estourando o prazo;

Software de baixa qualidade;

Software muitas vezes no atinge os requisitos;

Projetos no gerenciveis (escopo e prazo estourados) e o cdigo difcil de manter.

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 8

O uso de melhores tcnicas, mtodos e ferramentas;

Mais treinamento e educao: Atualmente no se investe o suficiente;

Tcnicas de Programao Tradicionais

Programao Orientada a Eventos

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 9

Histrico da Orientao a Objetos

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 10

O que Orientao a Objetos?

Facilita a reutilizao de cdigo;

Os modelos refletem o mundo real de maneira mais aproximada: Descrevem de maneira

Pequenas mudanas nos requisitos no implicam em alteraes massivas no sistema em

Implementao de tipos abstratos de dados (tipos que no sero implementados, mas

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 11

Figura 1: relao entre classe e objeto

Exemplo: Programao Estruturada vs. OO

ESCREVA ENTRE COM DOIS NMEROS:

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 12

Ler 2 nmeros e exibir sua soma (Com o qu?):

Entidade Fsica: caminho, carro, bicicleta, etc.

Entidade Conceitual: processo qumico, matrcula, etc

Entidade de Software: lista encadeada, arquivo, etc.

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 16

Esttico: se ocorre antes do tempo de execuo e permanece inalterado durante a

Dinmico ou Atrasado: se ocorre durante o tempo de execuo ou muda durante a

semanticamente os mesmos servios oferecidos pela superclasse.

public abstract double area();

// wheel revolutions per minute

void changeGear(int newValue);

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 18

http://www.omg.org/spec/UML/. No momento da preparao desta apostila, a verso corrente era a

modeling, through architectural and application modeling, to development, deployment, maintenance,

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 20

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 21

FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 22

2. Diagrama de Casos de Uso

Decidir e descrever os requisitos funcionais do sistema;