Análise e Projeto de Sistemas 2 (Uml) Unidade01

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01
UNIDADE 1 CONCEITOS INICIAIS SOBRE UML

MDULO 1 UML E O DESENVOLVIMENTO DE SISTEMAS
01
1 - DIAGRAMAS E REQUISITOS DA DISCIPLINA UML

Nesta disciplina iremos tratar sobre a UML - Unified Modelling Language.
A UML, em portugus, Linguagem de Modelagem Unificada uma linguagem ou notao de diagramas
para especificar, visualizar e documentar modelos de software orientados por objetos.
A UML no um mtodo de desenvolvimento, o que significa que no lhe diz como ser a interface
(telas) do sistema, ou mesmo como program-lo, mas ajuda a visualizar as principais caractersticas,
grupos de funcionalidades e como os componentes do sistema se comunicam.
A UML oficialmente composta por quatorze diagramas que representam as diferentes vises, partes e
caractersticas de um sistema de software. Assim como podemos ter um mapa geogrfico, um mapa
geopoltico, um mapa hidrogrfico, um mapa agropecurio e um mapa de altitudes que representam
cada um uma viso diferente sobre o mesmo assunto, cada diagrama da UML tambm permite
compreender o sistema sobre aspectos diferentes.
Os diagramas definidos na UML 2.0 so:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Diagrama de Caso de Uso;

Diagrama de Classe;
Diagrama de Objetos;
Diagrama de Sequncia;
Diagrama de Mquina de Estados;
Diagrama de Atividade;
Diagrama de Componente;
Diagrama de Implantao;
Diagrama de Pacotes;
Diagrama de Estruturas Compostas;
Diagrama de Viso Geral de Interao;
Diagrama de Comunicao;
Diagrama de Tempo;
Diagrama de Perfil.
Diagrama de Caso de Uso

Representa as pessoas e/ou usurios do sistema (chamados de atores), as situaes de
uso/funcionalidades do sistema (chamados de casos de uso), e seus relacionamentos. Basicamente,
representa quais servios (funcionalidades) o sistema deve oferecer aos usurios.
2015 - AIEC - Associao Internacional de Educao Continuada

1
Diagrama de Classe
Representa as classes e os relacionamentos entre elas. Cada classe representa um conjunto de
informao e/ou funcionalidades de um objeto (um item do sistema). Em outras palavras, representam
o contedo de dados e funcionalidades que so utilizados e manipulados dentro do sistema.
Diagrama de Objetos
Representa uma condio especfica ou um exemplo. So normalmente utilizados para representar
uma configurao especfica do sistema, o que muito usado na realizao de testes ou chamadas
operacionais.
Diagrama de Sequncia
Representa os objetos e uma sequncia lgica de evoluo das informaes e funcionalidades em um
determinado contexto. Foca na troca de mensagens entre um grupo de objetos e a sequncia das
mensagens.
Diagrama de Mquina de Estados

Representa os estgios (ciclo de vida) de um objeto medida que ele evolui em um sistema.
Diagrama de Atividade
Representa os acontecimentos (atividades e mudanas) de acordo com os eventos ocorridos em
alguma parte do sistema. Utilizado para representam o fluxo de dados e o fluxo de controle. Captura o
fluxo entre objetos interligados.
Diagrama de Componente
Representa os componentes de programao de alto nvel. Mostram a organizao e o relacionamento
entre os entregveis (pacotes) do sistema.
Diagrama de Implantao
Representa a arquitetura de execuo do sistema, composta por todos os componentes do sistema e
seus relacionamentos. Contempla, por exemplo, a plataforma de hardware, os artefatos de software, o
ambiente de software (como mquinas virtuais ou sistemas operacionais).
Diagrama de Pacotes
Representam os componentes do sistema que esto associados em partes maiores para futura
distribuio.
Diagrama de Estruturas Compostas

Representa como determinado pedao do projeto foi feito. especialmente til em projetos muito
complexos de estruturas compostas (baseadas em vrios componentes integrados).
2
Diagrama de Viso Geral de Interao

Representa vrios cenrios possveis e suas aes (um grupo de elementos trabalhando juntos para
alcanar um objetivo).
Diagrama de Comunicao
Representa as mensagens entre um grupo de objetos e o relacionamento entre eles.
Diagrama de Tempo
Representa as mudanas e o relacionamento delas com o tempo sob a tica do funcionamento real da
aplicao. Este diagrama raramente utilizado.
Diagrama de Perfil
Representa as diferentes verses das funcionalidades disponibilizadas pela aplicao de acordo com
perfis distintos de usurios. Este diagrama raramente utilizado.
02
1.1. Pr-requisito para a disciplina

3
Para realizarmos os exerccios desta disciplina, iremos precisar de um software de modelagem. H vrias
opes gratuitas, como o softwarelivre Visual Paradigm.
Outro software similar o Violet UML Editor, tambm gratuito.
Observaes:
1: caso voc j tenha feito a disciplina de Java, provavelmente voc j deve ter o software Eclipse.
Nesse caso, no ser necessrio instalar o Visual Paradigm, visto que o Eclipse tambm permite criar os
diagramas da UML.
Tela com os principais diagramas da UML no Visual Paradigm

2: no escopo desta disciplina realizar um treinamento de Visual Paradigm, Violet UML, Eclipse ou
qualquer outra ferramenta de UML. Para tanto, caso voc tenha dificuldade no uso dessas ferramentas,
pesquise no Youtube ou Google vdeos ou manuais de como utiliz-las.
Visual Paradigm
Para baixar o Visual Paradigm, acesse o link: http://www.visualparadigm.com/download/community.jsp. Nesta pgina h um link para outras verses do programa
(como para Windows 32 bits ou Linux). Faa o download e instale o programa. Informe seu nome e email na tela de instalao e receba no seu e-mail o cdigo de ativao. Informe esse cdigo no sistema
e pronto, voc j pode utilizar o software.
Violet UML Editor

O Violet UML Editor tambm gratuito e est disponvel aqui:
http://sourceforge.net/projects/violet/files/latest/download?source=files
4
03
Para que voc possa aproveitar ao mximo essa disciplina, necessrio o conhecimento prvio dos
seguintes assuntos:
Orientao a objeto: conceitos como classe, mtodo, evento, objeto, chamada, herana e
outros so fundamentais para a diagramao UML.
Metodologia de Desenvolvimento de Sistemas baseado em Mtodo Unificado (como o RUP ou
o Open UP): conceitos como iniciao, elaborao, construo e transio, que representam o
ciclo de criao de um projeto de software. Tratamos na UML principalmente das fases de
Iniciao e Elaborao, a documentao elaborada nestas fases servir de embasamento para a
programao de software realizada na fase de construo.
Esses contedos fazem parte do seu curso, ento aproveite para compreend-los bem!
04
1.2. Tipos de diagramas
Na UML h basicamente trs tipos de diagramas:
Diagramas estruturais;
Diagramas de comportamento;
Diagramas de interao.
Outra forma de se organizar os diagramas de acordo com suas caractersticas essenciais:
Diagramas estticos
Representam as
funcionalidades do
sistema que no
mudam com o tempo.
Esta categoria similar
aos diagramas
estruturais.
Diagramas dinmicos
Diagramas funcionais
Representam como o
sistema evolui (se
comporta) com o
tempo. Essa categoria
envolve os diagramas
de estado e de tempo.
Representam os detalhes
dos comportamentos e
os algoritmos, ou seja,
como o sistema realiza o
comportamento
esperado. Essa categoria
inclui os diagramas de
caso de uso, de interao
e de atividades.

5
Diagramas estruturais
So aqueles que representam a estrutura do software, independente das funcionalidades do sistema.
Por essa razo, eles normalmente no mudam com a evoluo do sistema (manuteno evolutiva).
Esto intimamente ligados tecnologia empregada no projeto.
Diagramas de comportamento
So aqueles que representam como o sistema reponde a uma chamada ou como ele se comporta ao
longo do tempo.
Diagramas de interao
Esses diagramas so um tipo especial de diagramas de comportamento. Esses diagramas representam a
colaborao (troca de mensagens) entre os componentes do projeto, ou mesmo com o projeto e outros
sistemas adjacentes (integrados e/ou relacionados).
05
Voc tambm pode utilizar os diagramas para responder informaes distintas em momentos
especficos do projeto de software. Um exemplo seria:
Quem usa o sistema?
Os atores (usurios do sistema) nos respectivos casos de uso (representando o propsito do sistema).
Do que o sistema feito?
Representado nos diagramas de classe que apresenta a estrutura lgica e o diagrama de componentes
que define a estrutura fsica.
Onde os componentes do sistema esto localizados?
Os diagramas de implantao indicam o plano de onde os componentes do sistema devero ser

instalados.
Quando eventos importantes do sistema acontecem?
Os diagramas de estado e de interao apresentam quais causas (eventos) fazem com que o sistema
reaja e que tarefas so ento executadas.
Como o sistema ir funcionar?
Os diagramas de comunicao e de estrutura representam as interaes em um nvel suficientemente

detalhado para o desenho (modelagem) e implementao (codificao).

6
06
2 - IDEIA GERAL SOBRE A UML

Voc j ouviu falar que uma imagem vale mais do que mil palavras? Pois , esse ditado popular to
antigo e amplamente utilizado traduz pura verdade quando falamos de projetos de sistemas de
informao. Diagramar uma tcnica de representar uma ideia em um desenho. Para a grande maioria
das pessoas mais fcil compreender e relembrar uma ideia desenhada do que uma ideia escrita. Alm
disso, um desenho pode inserir detalhes que dificilmente seria possvel caso s utilizssemos palavras.
por isso que desde h muitos anos so utilizadas tcnicas para expressar ideias em desenhos: uma
planta de uma casa, um desenho arquitetnico de uma ponte, uma simulao em 3D de um automvel
so exemplos de tcnicas de desenho e projeto.
Para o desenvolvimento de software, a melhor tcnica de se desenhar um sistema, por meio da qual se
apresenta uma ideia do que o sistema ser no futuro, a prototipao.
Por meio da prototipao criamos uma simulao do que o sistema ser quando concludo, incluindo
como acessar e navegar no sistema, como acessar as funcionalidades, como se parecero os cadastros,
pesquisas e relatrios.
Entretanto, j iniciar o projeto de informao por meio do prottipo no uma boa ideia, pois quando
criamos um prottipo, necessrio e prudente possuir uma viso completa do que o sistema faz e como
ele funciona. Para isso, utilizaremos outras tcnicas de diagramao que nos permitiro entender o que
o nosso cliente quer com o sistema e como ele deve interagir internamente para funcionar conforme o
esperado.
A UML surgiu como uma ideia de promover a comunicao e a produtividade entre os desenvolvedores
de sistemas orientados a objeto, mas o verdadeiro poder da UML a facilidade com que novos
desenvolvedores compreendem o que o sistema deve fazer. Por isso, no s no desenvolvimento de
novos sistemas, mas tambm durante a manuteno dos sistemas j existentes a diagramao UML
tem muito a contribuir.
07
Os principais objetivos da UML realizar as seguintes tarefas:
Especificao
Visualizao
Desenho da arquitetura do sistema
7
Construo
Simulao e teste
Documentao
Especificao
Entender o que o sistema deve fazer sob a viso do usurio.
Visualizao
Permitir uma viso do todo e como as partes do sistema se integram e interagem entre si.
Desenho da arquitetura do sistema

Definir entre os milhares de possibilidades qual ser a estrutura interna (arquitetura) do sistema, quais
tecnologias sero utilizadas e como elas sero utilizadas.
Construo
Definir um projeto de construo segundo uma ordem lgica que permita, futuramente, a integrao
das diversas partes de software que compe o sistema por completo.
Simulao e teste
Definir regras para as quais o sistema ser testado antes de ser entregue aos usurios finais (colocado
em produo), assim, podero ser identificados problemas de performance, segurana ou mesmo erros
de cdigo.
Documentao
De modo amplo, documentar o sistema de forma a que qualquer desenvolvedor tenha a capacidade de
desenvolv-lo de forma padronizada e, futuramente, alter-lo, consert-lo ou criar novas
funcionalidades para o sistema.
08
2.1. Processo de modelagem de software

8
A forma pela qual o sistema ser modelado e documentado (que o que a UML pretende) depende do
modelo de desenvolvimento de software proposto no projeto.
Atualmente h, basicamente, dois modelos largamente difundidos, cada um tem suas vantagens e
desvantagens:
Modelo de
Desenvolvimento
Vantagens
Modelo Unificado
(Unified Process)
Modelo gil
Desvantagens
Indicado principalmente para

projetos grandes;
Permite a documentao
completa de todo o projeto do
sistema;
Baseia-se nos modelos de
fbrica de software mais
comuns do mercado.
Indicado para projetos
pequenos ou mdios;
Produz resultados mais
rpidos;
O projeto geralmente fica
economicamente mais barato.
mais complexo;
Demora mais;
O projeto tende a custar mais
caro.
Documenta apenas o essencial

ao projeto;
Pode deixar falhas,
principalmente nas integraes
dos componentes.
Os conceitos que aprenderemos nesta disciplina permitem a aplicao de qualquer um dos modelos
citados.
09
Ainda em se tratando do modelo unificado, importante relembrar que a modelagem evolui em dois
sentidos com o tempo. Na medida em que o tempo do projeto passa:
Passamos de uma viso mais geral e macro do projeto, para uma viso mais detalhada do que o
sistema deve fazer;
Aps a definio da viso geral, o projeto do sistema dividido em pedaos chamados de iteraes e,
em cada iterao, os detalhes pertencentes quele conjunto so detalhados mais e mais at o nvel de
entendimento e documentao desejado.

9
Uma boa metodologia de desenvolvimento de

sistema deve prever quais documentos sero
feitos e o nvel de detalhamento de cada um de
acordo com as caractersticas do projeto, dessa
forma voc poder otimizar o tempo e o custo
do projeto que melhor seja adequado
situao. Lembre-se: nem sempre possvel (e
mesmo desejvel) criar todos os documentos da
UML para todas as situaes do projeto.
A viso dos usurios sobre um determinado sistema nem sempre completa e logicamente organizada.
Por isso, durante a modelagem de um sistema, muito comum que o profissional que est realizando
esse servio sugira mudanas estruturais e organizacionais no projeto do sistema de forma a produzir
um software melhor. Por isso, para uma boa modelagem de sistema, o projeto de software precisa de
algum que conhea muito bem sobre a matria que trata o software, de forma a colaborar com os
usurios e analistas na melhor organizao e desenho do sistema em si.
Tambm prudente que analistas de UML procurem por outros projetos similares ao que ele est
trabalhando, pois muito mais fcil conhecer e melhorar algo que j existe parecido do que reinventar
a roda a partir do zero.
10
Fazendo uma analogia com a construo civil, ao modelarmos um sistema como realizar as seguintes
atividades da construo civil para a criao de um prdio:
Fazer um desenho arquitetnico para ter uma viso geral externa do prdio. Da mesma forma,
criaremos uma viso geral do sistema sob o ponto de vista do usurio.
Fazer a planta de diviso dos ambientes internos. Tambm identificaremos as funcionalidades
do sistema.
Produzir as plantas eltricas e hidrulicas de forma a estruturar e promover funcionalidades e
recursos para cada rea e diviso do prdio. Da mesma forma, iremos criar diversos
documentos, com objetivos diferentes, que sero integrados entre si, juntando-os dentro de um
projeto nico (foco e objetivo nico).
11
10
2.2. Abstrao
Abstrao refere-se capacidade humana de traduzir o que est escrito e diagramado e imaginar como
aquilo ser no futuro.
Ao ler a planta de uma casa conseguimos entender a disposio e tamanho dos cmodos. Ao ver um
mapa de uma estrada, conseguir interpretar quais sero as cidades pelas quais passaremos ao longo do
nosso trajeto. Sob essa mesma ideia, ao criarmos a documentao UML, precisaremos ter a capacidade
de interpretar os diagramas e textos criados naquilo que futuramente chamaremos de sistema!
Quando modelamos um sistema, o material que produzimos no completa exatamente TODAS as
caractersticas do sistema, mas sim aquelasessenciais para formar a estrutura do sistema.
As demais caractersticas do sistema so informadas equipe de projeto por meio de documentos
auxiliares como prottipos, desenhos de tela, exemplos de grficos e relatrios, escolha de fontes,
tamanhos e cores, e outros.
12
2.3. Da generalizao para a especializao
Uma das formas mais tradicionais de se especificar e modelar um sistema de informao partir de um
conceito mais genrico, central, geral, amplo, grosso modo (generalizao) para um conceito mais
detalhado, especfico, determinado, definido, claro, restrito (especializao).
Utilizaremos essa tcnica no fluxo de trabalho de modelagem de um projeto de sistema de informao:
partiremos de diagramas que representam conceitos genricos, passando por diagramas que
representam conceitos intermedirios, at chegarmos a diagramas que representam conceitos
especficos e detalhados.
medida que o projeto de sistema de informao vai evoluindo, novas ideias so clarificadas, definidas
e detalhadas. Muitas vezes necessrio voltar aos documentos j elaborados para refin-los, corrigi-los
ou adequ-los aos projetos.
13
3 - Automao por meio da arquitetura dirigida ao modelo
A arquitetura dirigida ao modelo (do ingls Model-Driven Architecture MDA) uma metodologia de
desenvolvimento de software que permite a estreita relao entre os diagramas UML e o cdigo fonte.
Ferramentas de desenvolvimento de software que suportam essa tecnologia fazem com que qualquer
mudana feita nos diagramas UML automaticamente reflita no cdigo fonte do programa. O contrrio
tambm verdadeiro, qualquer mudana no cdigo fonte atualiza a documentao UML. Desta forma,
conseguem-se os seguintes benefcios:
A documentao do projeto nunca fica desatualizada em relao ao cdigo fonte.
11
Facilita o desenvolvimento.
Modelos de alto nvel independente de plataformas (tecnologias).
A documentao do projeto nunca fica desatualizada em relao ao cdigo fonte.
Sempre que o desenvolvedor altera, corrige, cria ou retira parte do sistema, a documentao
automaticamente reflete essas mudanas.
Facilita o desenvolvimento.
Por criar toda a estrutura do projeto, fica mais fcil programas o sistema. Tambm diminui erros de
programao por falta ou excesso de cdigo em divergncia com o que foi estipulado.
Modelos de alto nvel independente de plataformas (tecnologias).

Com isso, os modelos de alto nvel ficam abstratos, o que permite que seja possvel realizar mudanas
de tecnologia sem alterar a especificao do projeto (portabilidade). Exemplo: poderia,
hipoteticamente, trocar o banco de dados de uma aplicao de Oracle para Ms SQL e o software de
desenvolvimento automaticamente adequaria o cdigo fonte de acordo com os parmetros e
caractersticas da outra linguagem. Ao programados cabe apenas autorizar a converso do sistema,
sem necessidade de programao complementar.
14
4 - Perfis profissionais de TI que utilizam UML

Basicamente, so trs os perfis profissionais que utilizam a UML:

12
Analistas de Sistema, Designers, Engenheiros de Software,

Administradores de dados
So os profissionais que exploram as possibilidades de solues e tecnologias a fim de
resolver as necessidades dos usurios. Na ideia de uma analogia com a medicina, eles
entendem a doena e prescrevem o remdio e/ou a terapia adequada.
Analistas de Sistema, Designers, Engenheiros de Software,
Administradores de dados
So os profissionais que exploram as possibilidades de solues e tecnologias a fim de
resolver as necessidades dos usurios. Na ideia de uma analogia com a medicina, eles
entendem a doena e prescrevem o remdio e/ou a terapia adequada.
Implementadores, Desenvolvedores, Programadores

So os profissionais que criam o software a partir da soluo definida e escolhida.
Atualmente, as modernas linguagens de programao atuam em conjunto com os
modelos da UML criando no s o sistema de informao do projeto
de software proposto, mas tambm programas auxiliares de testes e at mesmo o
modelo de dados da aplicao. Na analogia com a medicina, eles so os enfermeiros e
terapeutas que aplicam o remdio ao paciente e controlam realizao da terapia
proposta.
15
5 - Conceitos Gerais
Para trabalharmos com UML essencial que alguns conceitos de orientao a objetos estejam bem
claros para voc:

13

Item
Descrio
Exemplo
Objeto
Refere-se a algo til que

tem uma identidade,
uma estrutura e um
comportamento.
O aparelho de ar-condicionado que est na minha sala

nico em relao a todos os demais aparelhos do prdio.
Ele est situado no teto, prximo janela e mede
aproximadamente 1m de largura por 20 cm de altura. Ele
se comporta bem, resfriando o ar quente da sala,
deixando-a confortvel para o trabalho.
Classe
Um conjunto de objetos
similares quanto
estrutura e
comportamento.
Todos os aparelhos e ar-condicionado resfriam o ar. Eles

tm um controle que permite ligar, desligar e regular a
temperatura para um determinado nvel.
Abstrao
Descreve a essncia de
um objeto para um
propsito.
Um diagrama eltrico de um aparelho de ar-condicionado

descreve como a energia eltrica percorre seus circuitos,
dessa forma, voc sabe manipular internamente o arcondicionado sem tomar um choque eltrico.
Descreve apenas o que

eu preciso saber para
usar um objeto
Para operar o ar-condicionado, eu no preciso saber

como funciona o compressor, as tubulaes e o
conversor trmico. Basta saber lig-lo energia eltrica,
pressionar o boto de ligar e regular a temperatura ao
nvel que eu desejar.
Mantm as coisas
simples suprimindo
detalhes.
A maioria das pessoas no precisa saber que o aparelho

de ar condicionado precisa de um disjuntor eltrico de 15
amperes de energia. Tambm no relevante nesse
contexto falar como o aparelho fixado janela ou onde
est conectado o duto de sada de gua.
Informa tudo o
desejvel sobre o
objeto.
O ar-condicionado resfria o ar da sala puxando o ar

quente por um duto, resfriando-o e expelindo-o de volta
por outro duto. H ainda a possibilidade de puxar o ar
externo ao ambiente ao invs do ar da sala. Ele
composto por uma unidade interna com ventilador e um
filtro, um condensador externo, tubulao ligando essas
duas unidades, conexes eltricas e um controle remoto.
Encapsulamento
Informao
oculta
Agregao

14
Generalizao
Informa o que comum

entre os objetos.
Todo aparelho de ar-condicionado possui um filtro de ar

e um ventilador interno para movimentar o ar.
Especializao
Informa o que
diferente em um objeto
em particular. o
oposto da generalizao.
O meu aparelho de ar-condicionado possui um mostrador

digital na cor verde que representa a temperatura atual
do ambiente. No controle remoto h outro mostrador,
desta vez azul, que representa a temperatura que o
aparelho est configurado para funcionar.
Herana
Objetos especficos
herdam caractersticas
comuns de objetos
genricos.
Assim como o meu aparelho de ar-condicionado, todos

os aparelhos de ar-condicionado so capazes de resfriar
um ambiente.
Polimorfismo
Nomes idnticos para

operaes semelhantes
em objetos diferentes.
Todo aparelho, de qualquer natureza, tem a tecla on,

essa tecla a que liga o aparelho. Assim como toda tecla
off desliga qualquer tipo de aparelho.
16
No dia a dia, ns reproduzimos e utilizamos vrios dos conceitos da orientao ao objeto sem perceber.
Entender esses conceitos importante, pois facilita o estudo da matria.
Quando olhamos um mapa de uma estrada que liga duas cidades quaisquer, por exemplo, ns no
vemos a estrada real, mas sim uma representao daquilo que encontraremos ao dirigir pelo caminho.
Ao ler o mapa, interpretamos as linhas e curvas que vemos como a estrada que iremos percorrer. Essa
interpretao do desenho na estrada de fato o que chamamos de abstrao. Quando modelamos
um softwareno vemos nos diagramas que criamos o software em si, mas sim uma representao
daquilo que queremos construir.
O mapa tambm no contm as rvores, as placas e sinalizaes, pontes e viadutos que encontramos
pelo caminho. Apenas as informaes relevantes esto l presentes, as demais so omitidas. Assim na
modelagem, apenas o que realmente importante deve estar presente, os demais detalhes surgiro em
outro momento com documentos de apoio, prottipos, exemplos etc. A modelagem deve focar naquilo
que essencial para o sistema funcionar de maneira completa.

15
Quando traamos um plano de viagem, inclumos

informaes de previso do tempo, condio das estradas,
tempo previsto para a viagem, lugares para abastecer o
veculo e se alimentar, postos de pedgio previstos, horrio
de sada e chegada.
Todas essas informaes reunidas em um plano de viagem
nico e completo o que chamamos de agregao. Agregar
juntar em um pacote tudo aquilo que diz respeito a um
terminado assunto. Ao modelar sistemas, precisamos
compreender as informaes afins e agreg-las para obter a
melhor coeso possvel.
17
J o termo encapsular refere-se a esconder os detalhes internos daquela funcionalidade de quem a
acessa, o que importante no s para dar mais segurana aplicao, mas tambm para no poluir o
prprio ambiente de desenvolvimento. Por exemplo, voc sabe que ao ligar o aparelho de arcondicionado ele funcionar, voc no precisa saber como os fios, motor, tubulaes e demais peas
esto conectadas internamente. Pois bem, essas peas todas esto encapsuladas em um objeto
chamado ar-condicionado.
Dica: quando voc precisar esconder as partes internas de um objeto, use a notao da UML de
agregao. Dessa forma, voc estar escondendo a complexidade de todo um objeto do mundo
exterior que o acessa (os demais objetos que interagem com ele).
A composio um tipo especial de agregao, para entender a composio mais fcil quando
comparamos as duas:
Composio
Agregao
Representa um nico objeto, indivisvel, cujo

ciclo de vida integrado, se evento encerra a
vida de parte do objeto, todo o objeto
extinto.
Representa um objeto constitudo pelo

relacionamento de vrios outros objetos. Cada
subparte tem seu ciclo de vida prprio, o
encerramento de uma parte no interfere no
ciclo de vida das demais subpartes.

16
Ex. Se um aparelho de ar-condicionado

queima o condensador, correto pensarmos
que todo o aparelho estragou, pois a parte
condensador indispensvel para o
funcionamento do ar-condicionado.
Ex. Se um caminho carrega uma carreta, e

essa carreta removida do caminho, ele
continua funcionando normalmente, sem
nenhuma interferncia. A remoo da carreta
no faz com que o caminho torne-se
imprestvel, o ciclo de vida dele continua
independentemente da carreta.
Observe que a diferena bsica a fora com a qual os objetos esto ligados entre si. Na composio, a
fora extrema e vital, j na agregao uma espcie de parceria suave.
18
5.1. Algumas outras palavras tcnicas no mundo orientado ao objeto
Diferentemente do mundo estruturado antigo, onde tnhamos apenas os conceitos de variveis,
constantes, frmulas, funes e procedimentos, o mundo orientado ao objeto trouxe consigo uma srie
de novos elementos. Vejamos os principais:
Elemento
Componente
Desenvolvimento
baseado em
componentes
Interface
Padro (Pattern)
Significado
Exemplo
Um objeto do mundo real feito em

cdigo de software que completo e
pode ser melhorado ou substitudo por
outro objeto, sem que o usurio saiba a
diferena.
Voc pode substituir seu aparelho

de DVD por um outro aparelho de
DVD mais moderno com
funcionalidades iguais ou
superiores. Da mesma forma, voc
pode substituir um mdulo do
cdigo do seu sistema por outro
mdulo que funcione melhor.
Uma forma de construir sistemas

modularmente, onde voc pode
facilmente substituir unidades de cdigo
sem afetar o restante do sistema.
Desenvolver um sistema utilizando

componentes Enterprise Java Beans,
Microsoft .Net ou CORBA.
Uma especificao que diz o que o

objeto deve fazer (mas no como fazer).
Um aparelho de DVD deve possuir

sadas de udio padro (exemplo,
tipo RCA).
Descrio de como os programadores

resolvem um problema/necessidade que
ocorre frequentemente.
Usar um adaptador padro para

fazer com que uma classe de
interface existente realize uma
tarefa determinada.

17
Framework (sem
uma boa traduo
para o portugus)
Framework um conjunto de classes

que colaboram para realizar uma
responsabilidade para um domnio de
um subsistema da aplicao. Ditam a
arquitetura da aplicao.
Voc pode implementar um

programa de reserva de hotel
usando o framework orientado a
eventos utilizando telas GUI.
Ferramenta de
modelagem UML
Um software utilizado para desenhar

diagramas de UML de maneira integrada
e inter-relacionada e documentar
sistemas de informao. Alguns ainda
criam parte do cdigo fonte da
aplicao.
H vrios softwares de modelagem

UML, aqui voc encontra uma lista
de vrios softwares de modelagem
UML: http://goo.gl/Yo0CQ4.
Ciclo de vida
Uma sequncia genrica de passos

desde o incio at o fim que qualquer um
do time de desenvolvimento precisa
seguir para considerar o projeto de
software corretamente desenvolvido
(bem feito).
Para a maioria dos projetos de

software aplicvel um ciclo de vida
que comea com uma etapa de
anlise, seguida por uma de
desenvolvimento.
Metodologia (de
desenvolvimento de
software)
Uma definio detalhada de todas as

tarefas necessrias para desenvolver um
sistema de informao para uma
determinada equipe de
desenvolvimento.
H vrios modelos proprietrios e

pblicos que tratam deste assunto.
RUP, OpenUp, OMT, Scrum,
eXtreme Programming, so alguns
exemplos.
19
6 - Criando aplicaes com programao orientada a componentes
Antigamente, quando falvamos de programao estruturada, os programadores normalmente criavam
os programas baseando-se numa sequncia lgica: primeiro se criava a tela principal do sistema, com o
login de acesso e o menu de funcionalidades, depois criava-se os cadastros bsicos, depois os cadastros
mais complexos, depois as operaes do sistema e por fim, os relatrios. Quase todas as equipes
utilizavam essa ideia de processo de criao de software.
Entretanto, para o mundo orientado a objetos essa tcnica mostrou-se ineficiente.
Construir software orientado a objetos tem outra lgica, outra ideia: agora, os programadores criam os
diversos pedaos (componentes) de software, cada um especializado em um tipo de tarefa. Exemplo:
cria-se um componente de interface de usurio, outro de gerenciamento de login e segurana, outro
para cadastros, outro para relatrios, tudo de forma bem genrica. Depois, hora de montar o sistema,
juntando os diversos componentes em outros componentes mais especficos, que realizam as tarefas
18
pontuais. Para isso, reutilizam-se os componentes genricos integrando-os por meio de componentes
mais especializados.
A maioria das linguagens de programao moderna, como Java, Ms .Net, PHP e outras, j possuem
prontos todos os componentes genricos utilizveis por qualquer tipo de software. Desta forma, o
trabalho do programador fica simplificado na arte de juntar esses componentes naquilo que o
propsito do projeto de software.
20
Ainda, por meio desses componentes (que j foram testados exaustivamente), o risco de incorrer em
erros de software cada vez menor. Assim como a segurana, a qualidade e a performance devem ser
cada vez maiores.
Dessa forma, a criao de programas orientados ao objeto deve seguir as regras:
1. Criar componentes;
2. Separar o que o componente pode fazer do como o componente faz;
3. Promover um mtodo padro para comunicao entre os componentes;

19
4. Permitir que seus

componentes
Use diagramas da UML para descrever como as partes da sua aplicao

foram montadas:
existam em um
ambiente padro.
Use os diagramas de classes, de composio de estruturas, de

sequncia e de comunicao para descrever como a parte interna
dos seus componentes atuam.
Os diagramas de classe mostram os atributos e as operaes de
cada objeto pertencente aos seus componentes.
Os diagramas de composio de estrutura apresentam as partes
internas que formam cada componente.
Os diagramas de sequncia mostram a interao entre os
componentes ao longo do tempo.
Os diagramas de comunicao representam a complexidade das
interaes internas das partes dos seus componentes.
Criar componentes
Escrever (ou utilizar) unidades de software como grupo de objetos que cooperam entre si, os quais voc
pode reutiliz-los em vrias partes da sua aplicao ou mesmo em vrias aplicaes. Nesta etapa muito
comum utilizar bibliotecas de software feitas por outras pessoas. Exemplos: bibliotecas para editar texto,
bibliotecas para tratar de assinatura digital, bibliotecas para tratar de arquivos multimdia, bibliotecas para
tratar criptografia, etc.
Separar o que o componente pode fazer do como o componente faz

Voc precisa declarar interfaces nos seus componentes. Cada interface especifica o nome da operao
e os parmetros necessrios para ela funcionar. Quando um componente invoca a interface de outro
componente, ele no precisa saber absolutamente nada de como aquela tarefa ser realizada.
Exemplo: quando seu programa faz uma chamada em um componente que reproduz um arquivo MP3,
voc no precisa saber como o componente far para tocar a msica, ela simplesmente soar por conta
da codificao interna que o componente de udio possui para tocar msicas MP3. Para voc, basta
utilizar as operaes preestabelecidas para tocar, parar, adiantar e/ou voltar a msica para o incio.
Promover um mtodo padro para comunicao entre os componentes

Para permitir que os componentes possam ser substitudos (quando necessrio), voc precisa
padronizar a modo exato com o qual os componentes conversam entre si. Os padres CORBA e
Microsoft COM so dois exemplos de padres de comunicao.
Permitir que seus componentes existam em um ambiente padro

Os seus componentes devem ser capazes de a) criar instncias de outros componentes; b) descobrir
20
quais interfaces outros componentes disponibilizam; c) registrar a si prprios, de modo que outros
componentes possam encontra-los e invoc-los. O Enterprise Java Beans (EJB) um bom exemplo de
ambiente de componentes. O EJB prov meios padro para criar, registrar, encontrar, executar e
deletar componentes.
21
6.1. Usando ferramentas de UML
Diagramas UML so fceis de desenhar, entretanto, requerem certa dose de dom artstico para
ficarem legveis e bem organizados. Voc poderia desenhar diagramas UML usando um papel e uma
caneta, mas certamente seria impossvel manter as atualizaes no diagrama bem como ler e
interpretar dezenas e dezenas de diagramas.
O que precisamos de uma ferramenta de modelagem UML, formalmente conhecida
como ferramentas CASE (Computer-Aided SoftwareEngineering Engenharia de Software Assistida por
Computao). Uma ferramenta de modelagem faz muito mais do que desenhar diagramas.
Com essa ferramenta possvel:
Criar diagramas inter-relacionados, onde possvel ver o detalhamento de um diagrama em

outro, ou a sequncia de um em outro.
Desenhar notaes UML corretamente. importante que voc mantenha o padro exato de
cada item, pois no faria sentido precisarmos de uma legenda toda vez que analisssemos um
diagrama novo.
Organizar as anotaes e diagramas em pacotes. Em projetos grandes, a quantidade de itens
que compe o seu projeto pode ser de centenas ou milhares. Ter uma ferramenta que permita
no s organizar, mas tambm realizar pesquisas (localizar) fundamental.
Engenharia reversa. Essa uma funcionalidade extremamente til: a partir de um cdigo fonte
a ferramenta de UML capaz de gerar a documentao dela. Essa mesma funcionalidade
utilizada para manter a sincronia entre os diagramas e o cdigo fonte.
Relatrios. Toda ferramenta de UML deve ser capaz de imprimir no s os diagramas, mas
tambm listagem de classes, objetos e dados estatsticos sobre a modelagem.
Gerao de cdigo. Essa funcionalidade trabalha em sincronia com a engenharia reserva, ela
que gera parte da estrutura do software a partir dos diagramas criados.
22
Existem mais de 200 ferramentas de UML atualmente, a escolha daquela mais adequada ao seu projeto
deve levar em conta:
o custo da ferramenta (e disponibilidade de recurso financeiro),
a tecnologia utilizada,

21
o framework de desenvolvimento,
o tamanho do projeto, e
a expertise da equipe.
Considere ainda as seguintes caractersticas de projetos de software:

Sistema de informao.
Sistemas com comportamento baseados em tempo real.
Sistemas de banco de dados.
Sistemas WEB.
Sistema de informao
Se o seu projeto pretende processar informao, voc precisa de uma ferramenta que trabalhe bem
todos os diagramas da UML (deve ser bem completa).
Sistemas com comportamento baseados em tempo real

Neste caso, voc precisa de uma ferramenta que trabalhe bem com questes temporais e eventos.
Procure uma ferramenta que implemente bem diagramas de estado.
Sistemas de banco de dados

Neste caso, voc provavelmente precisar mapear transaes ou data warehouse (armazm de dados).
Dessa forma, considere ferramentas que incluam representao de diagramas lgico e fsico de dados,
e que gerem cdigo SQL para criao de bancos compatvel com a tecnologia de banco de dados da sua
aplicao.
Sistemas WEB
Aqui voc provavelmente precisar de ferramentas que sejam capazes de criar scripts de cdigo e
servios WEB. Estruturas de dados em formato XML, cdigo em cliente (cliente-side code), e operaes
nos servios (server-side code) so alguns dos exemplos de tecnologia que sua ferramenta dever
suprir.
23
Resumo
Neste mdulo, aprendemos que:
a. UML uma linguagem ou notao de diagramas para especificar, visualizar e documentar
modelos de software orientados por objetos.
22
b. Atualmente so 13 os tipos de diagramas, cada qual com seu uso particular.

c. Nem todos os diagramas so aplicveis a todos os tipos de sistemas. Cada projeto de sistema
requer um conjunto especfico de diagramas, cabe equipe de projeto decidir quais diagramas
fazem sentido em cada contexto do projeto.
d. A diagramao UML aplicvel a qualquer metodologia de desenvolvimento, desde que
orientada a objetos.
e. Os diagramas UML podem ser classificados quanto aos tipos: estruturais, de comportamento e
de interao. Tambm podem ser classificados quanto s suas caractersticas essenciais:
estticos, dinmicos e funcionais.
f.
Ferramentas modernas de modelagem incluem a tecnologia MDA que permite a sincronizao

entre o cdigo fonte e a modelagem do sistema.
g. H vrios profissionais de TI que utilizam os diagramas UML para suas tarefas do dia a dia. Cada
profissional tem um uso particular para os diagramas.
h. Os conceitos de UML esto estritamente ligados aos conceitos de programao orientada a
componentes.
i.
H centenas de opes de escolha de ferramentas de diagramao UML, cada uma pode ser
mais bem adequada a uma ou outra equipe. H de se fazer uma boa anlise antes de adquirir ou
utilizar uma ferramenta de modelagem UML em um projeto.

MDULO 2 DIAGRAMAS DE CASO DE USO
01
1 - CASOS DE USO
Neste mdulo voc aprender os conceitos mais comuns e utilizados no dia a dia no desenvolvimento
de aplicaes orientadas a objetos. Tanto atuando como um modelador de sistemas quanto como um
programador, ns iremos familiariz-los com os conceitos de casos de uso. Voc ver detalhes
importantes sobre a notao de modelagem de objetos por meio da UML e ver dicas importantes e
boas prticas. Tambm voc aprender a identificar os problemas mais comuns que voc deve evitar.
O incio de um projeto de software tambm o momento mais importante do projeto. Saber utilizar
bem o tempo gasto nessa fase primordial para obter uma boa concepo do projeto. Nesse momento
voc dever ser capaz de identificar os principais objetivos do projeto e quais so as pessoas e
mecanismos que interagem com o sistema.

23
Tela de diagramas UML do Visual Paradigm, em destaque, o diagrama de caso de uso.
02
O diagrama de casos de uso o diagrama que apresenta o teor menos tcnico de todos os diagramas.
Isso se deve ao fato de este diagrama demonstrar como as pessoas esperam que o sistema funcione.
Portanto, por ter a viso das pessoas comuns (usurios) de se esperar que os termos que apaream
nele sejam relativamente fceis das pessoas comuns entenderem.
Layout bsico de um diagrama de caso de uso.

O diagrama de casos de uso incorpora os seguintes objetivos:
Identificao dos usurios relevantes para o sistema (lembrando que um usurio pode ser
tambm uma mquina ou outro sistema).
Os servios que os usurios executaro no sistema (algo como as funcionalidades que eles
esperam que o sistema produza).
Os servios que os usurios precisam prover para o sistema (informaes e procedimentos que
devem ser inseridos e executados no sistema).

24
03
O diagrama de caso de uso pode representar uma atividade manual do dia a dia de uma organizao a
qual se quer ser transformada em uma atividade gerenciada por um sistema de informao. Muitas
vezes, os insumos para se criar casos de uso so as teorias da administrao, de gesto de pessoas, do
direito civil, do direito comercial, pois so essas teorias (e tambm leis, regulamentos, regras etc.) que
definem a forma de se trabalhar. Dessa maneira, evita-se um erro muito comum na criao de sistemas:
ao invs de se criar sistemas que devem fazer a atividade do jeito certo, criam-se sistemas que
executam as atividades informadas de maneira errada ou incompleta pelas pessoas que as realizam no
dia a dia nas empresas.
por isso que o trabalho do profissional de informtica que faz a modelagem de sistemas no deve ser
apenas o de documentar a rotina de trabalho atual, mas tambm procurar certificar-se que as
instrues que lhe so passadas pelos usurios a forma correta (e completa) de se trabalhar.
Dessa maneira, podemos concluir que as atividades de elaborao de casos de uso podem incluir:
Entrevistas com os futuros usurios do sistema ou com pessoas especialistas no assunto

(exemplo: entrevistar uma pessoa formada em Contabilidade para tratar de um sistema de
contabilidade);
Pesquisas em documentos, legislao, regras, manuais, livros e padres de mercado;
Comparativos com outros sistemas semelhantes que j existam.
Geralmente, ao modelar um sistema de informao temos dois cenrios: o atual, onde h um problema
para ser resolvido, e um futuro, que representa a situao que se quer alcanar.
Modelar sistemas saber traar o melhor caminho entre a situao atual e o
cenrio futuro. Essa reta que liga esses dois pontos o escopo do projeto, e o
profissional que sabe construir essa reta da maneira mais inteligente, simples e
eficaz, certamente criar o melhor projeto de software possvel.
04
Para se definir os requisitos de um projeto de sistema de informao necessrio considerar duas
dimenses:
O escopo, ou seja, todas as funcionalidades que o sistema deve realizar; e

O nvel de detalhes (ou requisitos) que o sistema deve cumprir.
Por exemplo, no basta apenas dizer que um sistema qualquer deve permitir que o usurio faa o
pagamento de um boleto bancrio por meio do sistema, mas deve incluir todos os detalhes tcnicos,
tais como: que o boleto ter seu cdigo de barras digitado no sistema (e no escaneado por um scanner
de cdigo de barras), que o sistema dever funcionar 24h por dia (e no somente no horrio de

25
expediente bancrio), que o sistema dever guardar em registro interno quem foi a pessoa que realizou
o pagamento, entre outras informaes.
O escopo do projeto deve definir claramente quais so as fronteiras da aplicao. O que ela deve fazer
e o que ela no faz, mas que necessrio para o projeto funcionar. Muitas vezes, como podemos estar
tratando de sistemas que conversam com outros sistemas, ento importante deixar bem claro qual
a fronteira que limita essas duas aplicaes e como elas trocaro informaes entre si.
05
Um diagrama de caso de usos pode representar tanto a viso geral e total de todo um sistema, como
pode ser detalhado em diagramas mais especficos at o ponto de representar apenas uma pequena
funcionalidade do sistema. comum termos relacionamentos do tipo um diagrama pai, mais genrico,
que aponta para vrios diagramas filhos (ou at mesmo netos, bisnetos etc.), mais detalhados e
especficos.
Para permitir a documentao de todo o sistema, em seus diversos nveis, a UML prov o conceito de
pacotes. A ideia dos pacotes similar de diretrios que podem conter subdiretrios e/ou arquivos.
Cada subdiretrio representa subconjuntos do sistema e cada arquivo um subdiagrama. Para o analista
que ir modelar o sistema, o ideal que se parta de uma viso mais macro e com o tempo ele vai
detalhando at o ponto em que julgar aquele nvel de detalhe ideal para a compreenso do projeto
de software.
06
Como um sistema de informao criado para desempenhar um conjunto de funcionalidades, de se
esperar que o levantamento de informaes para a modelagem desse sistema comece pela identificao
das funcionalidades que fazem parte do escopo do projeto.
26
A lista de funcionalidades deve:
Definir todas as funcionalidades e seus desdobramentos em funcionalidades menores, mais

especficas.
Definir como as funcionalidades interagem entre si, por onde comeam e onde terminam, quais
so aquelas que podem funcionar de maneira isolada e quais dependem de outras.
Definir os comportamentos especficos que o sistema deve realizar, o que sucesso (e est ok),
e o que pode ser considerado errado (e deve ser desfeito ou cancelado).
Definir todas as interfaces com os usurios, sistemas, componentes etc.
Prover um cenrio de plano de testes desde o incio do projeto (e no no final).

Os diagramas de caso de uso no devem focar no processo de trabalho ao
longo do tempo, mas sim nos objetivos daquela funcionalidade. Dessa forma,
focamos em como satisfazer o usurio, e no em como conduzi-lo resposta
esperada. Trabalhando dessa forma, a soluo aparecer como o menor
caminho para se alcanar o resultado, evitando-se assim atividades que
podem no agregar valor para o sistema.
07
Sob essa ideia, nossos futuros sistemas podem no ser uma representao sistematizada do que
ocorre no presente, mas sim uma reinveno da forma de se trabalhar, buscando alternativas mais
vantajosas e eficientes. Em outras palavras, o sistema no deve focar em como as pessoas trabalham
atualmente, mas procurar meios de alcanar os resultados do trabalho de modo mais simples, prtico,
barato, seguro, eficiente e rpido. E tudo isso responsabilidade do modelador de sistemas! Exemplo
prtico.
Exemplo prtico
Pense em um cinema que sempre vendeu ingressos na sua bilheteria de forma manual e agora
solicitado a voc um sistema para modernizar a venda de bilhetes. Neste cenrio voc analisa a
situao e percebe que empresa (cinema) possui os seguintes objetivos com o futuro sistema:
a) facilitar a venda de ingressos,
b) gastar menos tempo com a venda de ingressos,
c) reduzir custos de mo-de-obra na venda de ingressos,
d) aumentar as vendas de ingresso.
Dessa forma, ao invs de propor que se crie apenas um sistema para gerenciar a venda de bilhetes,
voc possa sugerir a criao de uma soluo completa de tecnologia que permita a venda de bilhetes
pela internet, por smartphones e em mquinas automticas nas proximidades do sistema. Isso tudo
facilitaria a vida do cliente e certamente potencializaria as vendas de ingressos. Percebe como a
soluo pode ser muito melhor do que o problema original?
27
08
2 - IDENTIFICANDO INFORMAES PARA OS DIAGRAMAS DE CASO DE USO

Conforme j dissemos, uma das primeiras atividades em um projeto de sistema de informao definir
o contexto e o escopo proposto para a aplicao. Para isso, voc precisar responder s seguintes
questes:
Quais funcionalidades devemos incluir e excluir?

Como o sistema se relaciona a outros sistemas no ambiente de trabalho?
Quem usar o sistema?
De quem ou do que o sistema depende para realizar suas atividades?
Quais produtos ou resultados o sistema deve prover?
Por que os usurios precisam dessas funcionalidades no sistema?
Dessa forma, pensando na teoria do encapsulamento, os diagramas de caso de uso representao o que
o sistema faz e suas interfaces, e no como o sistema age internamente para realizar suas tarefas.
Geralmente os propsitos e interfaces dos sistemas se mantm com o tempo, o que muda a forma
como internamente as coisas acontecem. Assim, os componentes do sistema podem evoluir e serem
substitudos sem afetar a interao deles para com os usurios.
09
A prioridade na modelagem de sistemas definir o seu propsito e suas interfaces.
O propsito representa a
justificativa pela qual o sistema
deve existir.
As interfaces representam os canais de

comunicao entre os usurios do
sistema (que chamaremos a partir de
agora de atores) e as funcionalidades
(que chamaremos de casos de uso).
O diagrama de casos de uso composto por seis tipos de elementos grficos que representam os atores,
os casos de uso e os diferentes tipos de relacionamento entre eles, alm da nomenclatura utilizada. O
objetivo dos diagramas de caso de uso prover uma viso externa entre o relacionamento do sistema e
do mundo exterior.

28
Exemplo prtico, um sistema hipottico de compra de ingressos de cinema (seja ela pela
internet, smartphone ou equipamentos localizados na sala de cinemas) deveria oferecer aos usurios as
seguintes possibilidades:
Ver quais filmes esto passando e horrios das prximas sees;
Mostrar quais sees esto disponveis para compra (e talvez quais j estejam esgotadas);
Reservar assentos e comprar ingressos, pagando com carto de crdito.
10
3 - DESCRIO DO CASO DE USO

O diagrama de caso de uso por si s geralmente no traduz o entendimento e os requisitos suficientes
para a modelagem da situao, necessitando, portanto, de um texto narrativo complementar, chamado
de descrio do caso de uso (ou narrativa do caso de uso). No h uma forma padro estabelecida para
essa descrio, muito embora a maioria das organizaes utilizem documentos de texto que contenha,
ao menos, as seguintes informaes:
Nome: identificao do caso de uso.

Suposies: condies que se julgam serem verdadeiras para a execuo do caso de uso.
Exemplo
Pr-condies: situao prvia do sistema antes do processamento. Exemplo
Dilogo: sequncia de passos que o usurio deve fazer para utilizar o sistema corretamente.
Exemplo
Ps-condies: o que o sistema realiza para confirmar a operao. Exemplo
Excees: define como o sistema reage quando a operao no executada a
contento.Exemplos
Melhorias futuras: ideias que so pensadas no momento da anlise, mas no previstas no
escopo atual. Essas ideias podero ser parte futura de melhorias no sistema.
Questes abertas: questes que ainda no esto claras de como o sistema deve reagir, essas
questes sero discutidas com usurios e equipe de desenvolvedores a fim de se definir o
comportamento ideal. Exemplos
Suposies - Exemplo
O usurio deve estar logado no sistema para que ele possa executar o caso de uso em questo.
Pr-condies - Exemplo
O sistema deve apresentar a tela de cadastro para o usurio.
Dilogo exemplo
O usurio deve preencher os campos de nome e endereo, selecionar na lista a UF referente cidade
29
onde ele mora e executar o comando de salvar.
Ps-condies exemplo
O sistema confere se o CPF do usurio vlido e, em caso positivo, armazena os dados no banco de
dados, apresentando uma janela de dilogo que confirma a operao.
Excees exemplos
Algumas excees podem ser:
a) caso o CPF do usurio no seja vlido, o sistema deve cancelar a operao, apresentando janela
de dilogo na tela informando que o CPF no vlido;
b) caso o sistema no consiga salvar os dados no banco de dados, o sistema deve informar em
janela de dilogo que no foi possvel salvar as informaes, solicitando do usurio uma das
opes a seguir:
1) se o usurio deseja tentar salvar novamente ou
2) se o usurio deseja cancelar a operao).
Questes abertas exemplos

Podem ser questes do tipo:
O que o sistema deve fazer ao cancelar a operao? Deve apagar todos os dados da tela? Deve deixar
os dados preenchidos para que o usurio possa tentar salvar posteriormente?
11
Vejamos a seguir um exemplo hipottico de um caso de uso de abertura de conta bancria.
Nome: Abertura de conta bancria.
Suposies
O cliente est de posse de toda a documentao necessria, o gerente do banco possui acesso s
funcionalidades de cadastro de novo cliente e abertura de conta bancria no sistema do banco.
Pr-condies
O gerente deve logar no sistema com sua conta pessoal e acessar a tela de funcionalidades do sistema.
Dilogo
1.
2.
3.
4.
5.
6.
O gerente clica em cadastrar novo cliente

O gerente preenche os dados pessoais consultando os documentos apresentados.
O gerente clica em incluir endereo residencial.
O gerente preenche os dados de endereo e clica em salvar.
O gerente clica em criar conta bancria.
O gerente seleciona uma ou mais opes: criar conta corrente, criar conta de
poupana, criar conta especial com limite, criar conta associada a carto de
30
crdito.
7. O gerente confirma a operao, imprime os documentos e solicita assinatura do cliente
em todos.
8. O gerente digitaliza os documentos enviando-os para o sistema e arquivando os
documentos fsicos na agncia.
9. Fim.
Ps-condies
O sistema informa que a conta foi aberta e apresenta instrues para gerao de senha pessoal de
acesso.
Excees
1. O sistema impede o cadastro de dados de CPF invlido.
2. O sistema impede a concluso da abertura enquanto os documentos digitalizados no
forem enviados para o sistema.
Melhorias futuras
1. O sistema poderia permitir associar mais de um endereo para o cliente.
2. A gerao da senha poderia ser feita no mesmo ato de criao da conta corrente.
Questes abertas
1. Qual ser o padro para digitalizao? PDF?
2. O sistema poderia permitir cadastro prvio de informaes at que o cliente traga os
documentos pessoais?
3. O sistema deve sugerir como padro a abertura de todas as opes de conta e crdito?
12
4 -CENRIO DE CASO DE USO
Layout bsico de um diagrama de cenrio de caso de uso.

31
Uma das maiores foras do diagrama de casos de uso que ele define o que o sistema (ou o
componente) deve fazer. Para assegurar o sucesso do desenvolvimento, necessrio um plano de teste.
Examinando as narrativas de caso de uso podemos identificar os cenrios de caso de uso. Os cenrios
so as formas que o sistema pode operar. Normalmente, em cada caso de uso possvel definir os
seguintes cenrios:
O cenrio que representa a sequncia de atividades mais comum e curto do sistema (muitos
autores chamam esse cenrio de caminho feliz). Exemplo 1
Outros cenrios que representam alternativas, incorporando outras funcionalidades. Exemplo 2
Cenrios de exceo, onde o sistema dever bloquear a operao, desfazer aes j feitas e/ou
apresentar erros na tela. Exemplos
Os cenrios de caso de uso podem tanto ser representados por um diagrama, utilizando um diagrama
de atividades (veremos mais frente), tcnicas de fluxograma ou BPMN, ou utilizando narrao
descritiva.
Juntos, o diagrama de casos de uso, a descrio/narrativa do caso de uso, e os cenrios compem o
conjunto de artefatos de caso de uso necessrios para modelar um sistema.
Exemplo 1
O usurio seleciona o filme, o horrio, a quantidade de bilhetes, define as poltronas onde quer sentar e
efetiva a compra, realizando o pagamento.
Exemplo 2
O usurio pode pagar por meio de carto de crdito ou por meio de transferncia bancria.
Exemplos
A sesso escolhida est esgotada; o usurio no est satisfeito com as poltronas disponveis e quer
cancelar a operao (ou mudar de horrio da sesso); o pagamento no pode ser validado e a operao
deve ser cancelada.
13
5 - DIAGRAMANDO UM CASO DE USO

Elementos que formam um diagrama de caso de uso:
atores,
casos de uso,

32
associaes,
relacionamentos (<<include>> e <<extend>>) e
generalizaes.
Exemplo bsico de um diagrama de caso de uso (utilizando a ferramenta Visual Paradigm).
14
Ator
Representa um papel desempenhado por uma pessoa, um sistema, um equipamento, uma organizao
etc., que tem um interesse no sucesso da operao do sistema.
Exemplos: usurio, cliente, vendedor, operador do caixa, sistema bancrio, empresa de correios,
transportadora, departamento financeiro, setor de usinagem etc.
Um ator nunca ser uma pessoa nomeada, mas sim um papel. Uma mesma pessoa pode executar, na
prtica, diversos papeis diferentes. Exemplo hipottico: o Joo, que o gerente do banco XPTO,
tambm um cliente do banco, portanto, ora ele pode ser considerado no papel gerente, ora no
papel de cliente. O ator normalmente representado pelo desenho de um boneco, mas tambm pode
ser substitudo por uma imagem, logotipo ou outro desenho.
Exemplo de simbologia de um ator.

33
15
Caso de uso
Identifica um comportamento chave do sistema (e no uma simples atividade). Sem esse
comportamento, o sistema no resolveria a necessidade do ator. Lembre-se: um caso de uso deve ser
sempre focado em um objeto.
Bons exemplos: sacar dinheiro, efetivar compra do bilhete, reservar diria em hotel, cadastrar
pessoa.
Maus exemplos: logar no sistema, selecionar o item no menu do sistema, preencher a tela com
informaes cadastrais, salvar dados.
Muitas equipes de desenvolvimento preferem de usar verbos no infinitivo para os casos de uso, mas h
tambm a possibilidade de utilizar verbos no presente (exemplo: saca dinheiro, reserva hotel).
Mantenha sempre o padro da sua equipe, evite misturar padres. O caso de uso representado por
uma elipse com o nome do caso de uso escrito internamente.
Exemplo de simbologia de um caso de uso.
16
Associao
Identifica uma interao entre os atores e os casos de uso. Cada associao inicia com um dilogo que
deve ser explicado em um documento de narrativa do caso de uso. Cada narrativa em questo prov um
conjunto de cenrios que podem ajudar no desenvolvimento dos planos de testes para futura validao
da anlise, desenho e implementao do sistema.
Exemplo: se um ator do tipo cliente executa uma operao de sacar dinheiro em um caixa eletrnico
de banco, ento, h uma associao entre o ator cliente e o caso de uso sacar dinheiro.
A associao diagramada por meio de uma linha comum (sem ser pontilhada).
Exemplo de simbologia de uma associao de um ator a um caso de uso

34
17
Relacionamento do tipo <<include>>
Identifica um caso de uso reutilizvel (e compartilhado com outros casos de uso) que
obrigatoriamente incorporado na execuo de outro caso de uso.
Exemplo: para que o caso de uso sacar dinheiro funcione, obrigatoriamente ele deve executar o caso
de uso efetuar dbito da conta corrente. O relacionamento do tipo <<include>> representado por
meio de uma seta pontilhada (com o texto <<include>>) que aponta para o item que incorporado ao
caso de uso principal.
Exemplo de simbologia de um relacionamento do tipo include, ligando dois casos de uso
18
Relacionamento do tipo <<extend>>
Identifica um caso de uso reutilizvel que pode ser opcionalmente incorporado na execuo de outro
caso de uso. E, para ser incorporado, deve obedecer uma certa condio.
Exemplo: para que o caso de uso efetuar dbito da conta corrente funcione, pode ser necessrio
executar ou caso de uso usar o limite do cheque especial, que somente ser executado caso o valor do
saque seja maior que o valor disponvel na conta corrente do cliente.
O relacionamento do tipo <<include>> representado por meio de uma seta pontilhada (com o texto
<<extend>>) que aponta para o item que invoca o caso de uso opcional (direo oposta do include). No
exemplo abaixo vemos tambm a representao de uma nota explicativa (por meio de um cone que
representa uma nota).
Exemplo de simbologia de um relacionamento do tipo extend, ligando dois casos de uso
19
35
Generalizao/Herana
Identifica o relacionamento de herana entre atores ou entre casos de uso.
Exemplo: o ator pessoa pode ser a generalizao dos atores cliente e vendedor, pois ambos
compartilham (e herdam) propriedades similares ao ator pessoa. J o caso de uso abrir conta
corrente representa uma especializao do caso de uso abrir conta bancria, o mesmo vale para o
caso de uso abrir conta de poupana que herda os comportamentos comuns de abrir conta
bancria.
A generalizao representada por uma seta fechada lisa que sai do item mais especfico e aponta para
o item mais genrico.
Exemplo de simbologia de generalizao relacionando trs atores ( esquerda) e trs casos de uso (
direita)
20
5.1. Passo a passo para construo de diagramas de caso de uso
Para construir diagramas de caso de uso, voc precisa:

36
Definir o contexto do
sistema (ou da
anlise, caso seja de
parte do sistema)
Avaliar os atores e
casos de uso a fim de
identificar
oportunidades de
refinamento, por
meio da separao
ou da juno de
definies.
Avaliar os casos de
uso para encontrar
relacionamentos do
tipo <<extend>>".
Diagramar o caso de
uso.
Avaliar os atores e
casos de uso para
identificar
oportunidades de
generalizao (para
compartilhamento de
propriedades).
Contexto do sistema
Na definio do contexto do sistema, deve-se:
1. Identificar os atores e suas responsabilidades;
2. Identificar os casos de uso e os comportamentos do sistema em termos de objetivos
e/ou resultados que devem ser produzidos;
Documentar essas informaes um documento a parte ou junto narrativa de caso de uso.
21
6 - EXERCCIO PRTICO
A melhor forma de aprender a diagramar UML executar exerccios prticos. Para esses exerccios que
faremos agora, voc no precisa nem de um software de UML, basta lpis e papel.
6.1. Mquina automtica de venda de ingresso de cinema
Suponha que numa entrevista com um funcionrio do cinema, ele tenha de explicado como funcionar a
mquina de venda de ingressos: As pessoas vo maquininha e apertam na tela. L ele vai ver que
filme est passando, a ele escolhe o filme e o horrio. Depois ele escolhe quantos ingressos quer
comprar, depois ele escolhe onde vai sentar. Depois ele confirma, bota o carto de crdito na mquina e
compra o ingresso.
Veja que a forma com a qual a pessoa narrou o fato precisa de uma srie de ajustes de vocabulrio para
que a diagramao e documentao fiquem mais formal:
A pessoa se tornar o cliente;

37
A maquininha chamaremos de mquina de venda de ingresso;
Ver que filme est passando escreveremos como pesquisar filmes disponveis;
Ele escolhe o filme transformaremos em selecionar filme;
E o horrio ser selecionar sesso do filme;
Ele escolhe quantos ingressos quer comprar ser selecionar quantidade

de ingressos;
Ele escolhe onde vai sentar ser selecionar poltronas disponveis;
Ele confirma ser confirmar operao de compra;
Bota o carto de crdito e compra ser ajustado para realiza o pagamento com carto de
crdito.
Sempre ser necessrio ajustar o dilogo entre o usurio/cliente e o texto que ser documentado.
Feito isso, j conseguimos identificar os atores deste cenrio; no caso, o nico ator o cliente.
22
Pensando em objetivos, percebemos que h dois objetivos no cenrio:
1 - pesquisar e ver os filmes em cartaz e
2 - comprar bilhetes.
Para que esses dois objetivos sejam concretizados, outros menores devem existir para auxili-los,
como por exemplo: selecionar assentos e efetivar pagamento. Uma informao nova acrescentada ao
contexto: a multiplicidade. Um cliente pode pesquisar um ou mais filmes, pode comprar um ou vrios
bilhetes, selecionar um ou vrios assentos e, finalmente, realizar um nico pagamento.
Para indicar a multiplicidade so usados os mesmos smbolos da orientao a objetos (1, 1..*, 0..*, etc.,
se voc no se lembra desses smbolos, no se preocupe, eles sero revistos mais adiante). Com essas
informaes, j podemos desenhar nosso diagrama. Veja uma sugesto abaixo:

38
Diagrama de Caso de uso de Compra de Bilhete de Cinema
23
Com o diagrama em mos, podemos realizar nova entrevista com o demandante do sistema a fim de se
obter novas regras de negcio e assim poder descrever a narrativa de caso de uso. Uma sugesto
hipottica do resultado dessa reunio de levantamento de informaes poderia ser descrita nesta
narrativa de caso de uso:
Nome: Comprar bilhete de Cinema.
Suposies
Pr-condies
Dilogo
Ps-condies
Excees
Melhorias futuras
Questes abertas.
Suposies
1. At 30 minutos aps o incio da sesso de cinema j iniciada, mas ainda com
pelo menos um assento livre, a sesso deve ser considerada disponvel para
compra de bilhetes.
2. Aps 30 minutos de incio, a sesso de cinema deve ser considerada encerrada.
3. Aps o esgotamento de assentos disponveis, a sesso deve ser considerada
esgotada.
4. No deve ser possvel a compra de bilhetes para sesses encerradas ou
esgotadas.
39
5. Somente estar disponvel a compra de bilhetes para sesses que acontecem

no mesmo dia da compra.
6. O equipamento possui tela sensvel ao toque para operao do sistema, todas
as operaes devero ser realizadas por meio desta tela. No h teclado,
mouse ou outros botes fsicos.
7. O equipamento possui dispositivo para leitura de carto de crdito acoplado.
8. Caso o sistema permanea por mais de 3 minutos sem que o cliente interaja
com o sistema, toda a operao deve ser cancelada e voltada tela de incio.
O sistema deve possibilitar o cancelamento da operao em qualquer estgio da compra.
Pr-condies
1. Deve haver ao menos um filme em cartaz;
2. Deve haver conectividade com sistema bancrio (para pagamento com carto de
crdito);
Deve haver conectividade com o sistema central de gerenciamento do cinema (para pesquisa de
informao sobre filmes disponveis, sesses e assentos disponveis).
Dilogo
1.
Ao chegar mquina de vendas, o usurio pode consultar algumas das informaes j
presentes da tela de inicial do sistema. Essa tela deve mostrar um resumo com todos
os filmes em cartaz, apresentando uma imagem do filme, o nome do filme, o horrio
da prxima sesso de cada um e a quantidade de assentos disponveis para compra da
sesso. Caso esta sesso j esteja esgotada, o sistema dever apresentar as
informaes para a sesso seguinte. Caso no exista sesso seguinte, o sistema deve
apresentar a informao que a venda de ingressos est esgotada para aquele filme.
2.
O usurio clica em qualquer parte da tela para iniciar o uso do sistema.
3.
Ao clicar na tela, o sistema deve apresentar uma listagem de todos os filmes em
cartaz. Ao lado do nome de cada filme, o sistema deve apresentar todos os horrios
de incio das sesses disponveis para o dia. Para ser considerada disponvel,
necessrio ter ao menos um assento livre.
4.
O usurio clica em uma sesso de cinema.
5.
A tela apresenta uma imagem grande do filme, informando o horrio de incio e
trmino da sesso e a quantidade de assentos disponveis. A tela tambm apresenta
opes para selecionar cada uma das outras sesses disponveis e outro comando
para cancelar a operao.
6.
Se o cliente selecionar outra sesso disponvel, a tela atualizada com as informaes
respectivas da sesso selecionada.
7.
Se o cliente clicar em cancelar, o sistema volta para a tela de incio.
8.
O cliente clica em selecionar poltronas.
9.
O sistema apresenta uma tela com imagem representando todas as poltronas do
cinema, marcando de vermelho escuro as poltronas indisponveis e de azul claro as
poltronas disponveis. O sistema dever incluir comandos para cancelar a operao
(voltando para a tela de incio), selecionar outra sesso (voltando para a tela
anterior) e finalizar compra. A opo de finalizar compra s deve aparecer se ao
menos uma poltrona (correspondente a um bilhete) estiver sido selecionada.
40
10.
11.
12.
13.
14.
15.
16.
17.
O cliente clica nas poltronas que deseja comprar. Ao clicar em uma poltrona, esta
deve ser destacada em amarelo na tela do sistema. Para desmarcar uma poltrona
selecionada, basta que o cliente clique novamente na mesma poltrona, assim, ela ser
desmarcada, retornando cor azul. As poltronas que estiverem selecionadas, nesse
momento devero ficar em estado de reserva por 3 minutos. Dessa maneira, outros
clientes utilizando outras mquinas de compra ou mesmo a bilheteria ficam
impossibilitados de comprar a mesma poltrona. O sistema deve ser capaz ainda de
atualizar as poltronas disponveis em tempo real, a cada segundo, sincronizando
informaes de compra dos diversos pontos de venda, evitando assim a compra
duplicada da mesma poltrona.
Aps a seleo das poltronas desejadas, o cliente clica em finalizar a compra.
O sistema apresenta uma tela resumo com a quantidade de bilhetes, o valor total da
compra, o filme e sesso selecionados, e as poltronas selecionadas. A categoria do
bilhete a ser computada neste momento a de bilhete comum.
O sistema de permitir a troca individual da categoria dos bilhetes, possibilitando ao
cliente substituir pelas categorias estudante e terceira idade (que fornecem 50% de
desconto no valor da compra).
Ao mudar de categoria de bilhete, o sistema deve recalcular o valor total da compra.
O sistema deve solicitar ao cliente inserir o carto de crdito na mquina para efetivar
a compra.
O sistema deve solicitar a senha do carto de crdito e a confirmao do pagamento.
O sistema deve processar o pagamento e concluindo-o, imprimir os bilhetes do
cinema, a nota fiscal e o comprovante de pagamento do carto de crdito.
Ps-condies
Aps a confirmao do pagamento a venda concluda, emitindo os bilhetes e transformando os
assentos daquela sesso em assentos permanentemente indisponveis.
Excees
1. Caso o cliente clique em cancelar, a qualquer momento, o sistema deve voltar tela de
incio.
2. Caso ocorra problema no pagamento, o sistema deve permitir a substituio ou outro
carto ou a possibilidade de se cancelar a compra de bilhetes.
Caso o sistema fique mais de 3 minutos sem uma ao do cliente, a operao deve ser cancelada e o
sistema deve voltar tela inicial.
Melhorias futuras
1. Na tela de listagem de todos os filmes e sesses, ao lado de cada sesso poderia ser
informada a quantidade de assentos disponveis.
2. O sistema de pagamento poderia possibilitar tambm a operao de dbito em conta
(carto de dbito) ou at mesmo de transferncia bancria.
3. Criar uma aplicao para smartphones que tambm permita a venda de bilhetes.

41
Questes abertas
1. Ao cancelar a operao, a operao deve ser imediatamente cancelada ou o sistema
deve apresentar uma janela de dilogo solicitando confirmao ao cliente se ele deseja
realmente cancelar a operao?
2. Ao abandonar a operao, as poltronas pr-selecionadas devem realmente ficar at 3
minutos em estado de reserva?
24
Quanta informao no mesmo?! Parece complicado a princpio, mas com a prtica do dia a dia, esse
trabalho no ser to difcil quanto parece, apenas um pouco grande ou um pouco demorado, mas
no ser complexo nem difcil demais para voc.
Note ainda que para esse exemplo todos os fluxos opcionais j esto descritos no texto. No seria
realmente necessrio criar um diagrama de cenrio de caso de uso. Entretanto, se mesmo assim voc
desejar inserir um no seu projeto, abaixo voc v uma sugesto.
Diagrama de Sequncia auxiliando o entendimento do caso de uso

Veremos o diagrama de sequncia em detalhes em outro mdulo.
25
7 - Casos de uso do tipo manter alguma coisa
A maioria dos sistemas de informao possui cadastros bsicos, como os cadastros de cliente, de
funcionrios, de produtos, de cidade, de UF, de fornecedores, de usurios etc. Todos os cadastros
bsicos possuem quatro funcionalidades em comum em relao aos seus cadastros em bancos de
dados.
Essas funcionalidades so chamadas pelos engenheiros de software de CRUD:
C create (criar)
R report
a funcionalidade que cadastrar um novo item na base de dados.

a funcionalidade de poder pesquisar, encontrar e mostrar as informaes
42
(reportar)
U update
(atualizar)
D Delete
(excluir)
cadastradas.
Refere-se capacidade de poder atualizar uma informao previamente cadastrada
com um dado mais atualizado.
Funcionalidade de apagar informaes do banco de dados.
Para realizar todas essas quatro operaes (e uma quinta que a de pesquisar/localizar), os engenheiros
de software, por prtica de mercado, definiram que todo sistema de informao precisa possuir ao
menos um caso de uso para cada cadastro (tabela) no banco de dados denominado de caso de uso
manter. Dessa forma, os primeiros casos de uso que voc pode comear a identificar no seu sistema
so os casos de uso do tipo manter.
Exemplos comuns desse tipo de caso de uso: manter cliente, manter funcionrio, manter vendedor,
manter produto, manter fornecedor, manter contas a pagar, manter contas a receber, manter cidades,
manter UF etc.
26
Resumo
a. Os projetos de software devem comear por meio da definio dos objetivos do software. Esta
anlise tambm nos ajudar a identificar os atores do sistema, que so pessoas e mecanismos
que interagem com o sistema.
b. H diversas fontes de informao para a elaborao de casos de uso. Documentos da empresa,
regras de mercado, leis e entrevistas com os usurios so as opes mais comuns.
c. O desdobramento dos casos de uso trar as funcionalidades (e futuramente as classes) do
sistema, e como elas interagem entre si e com outros sistemas.
d. Os casos de uso devem representar uma forma mais moderna e racional do trabalho atual, e
no apenas a fiel repetio das atividades atuais.
e. Ao modelar sistemas, voc pode trazer qualquer sugesto que oferea algum tipo de melhoria
ou benefcio ao sistema e aos seus usurios.
f.
A descrio de um caso de uso uma narrativa complementar que fornece uma srie de
requisitos e informaes sobre o funcionamento do caso de uso.
g. O diagrama de cenrios de caso de uso representa o fluxo principal do caso de uso e outros
fluxos opcionais e de exceo.
43
h. Relacionamentos do tipo include so obrigatrios e apontam para o caso de uso que chama
o outro caso de uso.
i.
Relacionamentos do tipo extend so opcionais e apontam para o caso de uso que

chamado. Ainda, esse tipo de relacionamento precisa de uma condio do uso do sistema
para o caso de uso ser executado.
j.
Atores so papis representados no sistema por pessoas, subsistemas, equipamentos etc.
k. Os casos de uso representam objetivos do software a serem cumpridos.

l.
A generalizao expressa por uma seta contnua que parte do item mais especfico a aponta
para o item mais genrico.

MDULO 3 DIAGRAMAS DE ATIVIDADES
01
1 - CARACTERSTICAS DO DIAGRAMA DE ATIVIDADES

Ol, seja bem-vindo a mais uma etapa do nosso estudo. Aqui voc aprender os conceitos que esto por
trs do comportamento do sistema, modelado por meio dos diagramas de atividades.
Tela de diagramas UML do Visual Paradigm, em destaque, o diagrama de

atividades.
O diagrama de atividades frequentemente visto como parte da viso funcional de um sistema, pois
descreve os processos lgicos ou funes. Cada processo descreve uma sequncia de tarefas e as
decises que regem quando e como eles so realizados.

44
preciso compreender um processo a fim de escrever ou gerar o cdigo correto para um

comportamento.
02
Alguns autores juntam os aspectos funcionais e dinmicos da modelagem. Isso se deve ao fato de que
ambos expressam o comportamento do sistema. No entanto, para fins de aprendizado, importante
voc saber distinguir a lgica da interao:
Interaes
Modelos funcionais
ou lgicos
Abordam os
resultados conjuntos
dos processos, ou
seja, entradas e
sadas.
Abordam os
mecanismos de
transformao de
entrada em sadas.
Alm disso, a modelagem funcional adquiriu uma m reputao com o incio da modelagem orientada a
objetos (OO). Afinal, a orientao a objetos aborda as deficincias do modelo anterior, como a
modelagem funcional e de dados. Mas tanto a modelagem funcional quanto a modelagem de dados
ainda fornecem informaes valiosas sobre o desenvolvimento de software. Mtodos de
desenvolvimento OO no eliminam a necessidade dessas perspectivas valiosas; eles simplesmente
trazem os dois conceitos juntos para fornecer um modelo mais abrangente e preciso de como as coisas
funcionam. Modelagem funcional ainda uma parte muito bsica de qualquer design do aplicativo.
Assim, a UML preservou modelagem funcional sob a forma de diagramas de atividade, que concebida
para apoiar a descrio de comportamentos que dependem dos resultados dos processos internos, ao
contrrio de eventos externos, como nos diagramas de interao. O fluxo em um diagrama de atividades
impulsionado pela realizao de uma ao. Em uma mquina de estado, o fluxo conduzido por
eventos ou condies externas associadas. Consequentemente, diagramas de atividades so teis para
operaes que definem casos de uso e fluxos de trabalho que unem uma srie de casos de uso.
03
2 - MODELANDO UM DIAGRAMA DE ATIVIDADES

Desde o passado at hoje em dia, muitos ambientes de negcios usam fluxogramas para representar
processos de trabalho.
Processos so sequncias lgicas de tarefas regidas por pontos bem definidos de controle, tais como as
45
decises, junes e separaes.
A criao de um fluxograma uma tcnica simples e prtica, com muitas aplicaes. A UML oferece uma
verso melhorada dos fluxogramas, sob a forma do diagrama de atividades, tambm chamado
de grfico de atividades.
H pelo menos trs lugares em um modelo onde um diagrama de atividades fornece informaes
valiosas:
modelando fluxos de trabalho (workflow),
descrevendo os casos de uso,
especificando operaes.
04
2.1 - Modelando fluxos de trabalho e casos de uso
J aprendemos que um caso de uso modela um objetivo que o sistema deve atingir, a fim de ser bem
sucedido. O diagrama de atividades mapeia o comportamento do usurio atravs de um procedimento,
observando as decises tomadas e as tarefas executadas. O procedimento pode explicar um nico caso
de uso, ou apenas parte de um caso de uso, ou mesmo muitos casos de uso unidos para criar um fluxo
de trabalho. Modelar um caso de uso parte do processo de descoberta e validao para a modelagem
de um sistema. Cada diagrama d uma nova perspectiva sobre os recursos do sistema.
Um diagrama de atividades relacionado a um caso de uso explica como o ator interage com o sistema
para cumprir a meta do caso de uso, incluindo as regras, informaes trocadas, as decises tomadas e
produtos de trabalho criados.
Um diagrama de fluxo de trabalho (workflow) detalhado ao nvel de atividades representa a ordem e as
condies em que os casos de uso so executados em uma srie (sequncia).
Modelar o trabalho do usurio desta maneira no define essa verso particular do processo como a
nica forma correta do sistema trabalhar. Cada objetivo (caso de uso) pode ser satisfeito por qualquer
nmero de processos vlidos. Mas a criao de um modelo deste tipo provavelmente ir revelar os
elementos essenciais do processo de uma forma que seja familiar para os utilizadores.
Elementos essenciais incluem:

46
05
O diagrama de atividades pode facilitar a entrevista para esclarecer as tarefas e as decises a fim de
encontrar as razes por trs delas. Ou seja, esta a sua oportunidade de identificar como alcanar o
objetivo do processo, e definir cada tarefa necessria para tornar o processo bem sucedido (passo a
passo).
Uma vez que as regras essenciais para o processo foram identificadas, ento mais fcil de avaliar
processos alternativos para satisfazer essas regras. Num sistema hipottico de compra de bilhetes de
cinema, por exemplo, os clientes querem descobrir quais so os filmes, as sesses e os lugares
disponveis.
O objetivo bsico simples: mostrar a eles o que est disponvel e capacit-los para selecionar o que
eles gostariam de comprar. As regras essenciais incluem:
A identificao das
informaes
necessrias
Exibir a informaes de
forma que os clientes
possam facilmente
compreender
Deve possibilitar que

os clientes faam suas
escolhas de modo a
concretizar a compra
Cliente emite bilhetes
Cliente efetua
pagamento
Cliente reserva lugares
06
No exemplo do sistema de bilhetagem de ingressos, tanto o objetivo quanto as regras associadas podem
ser apoiados por muitos processos. Por exemplo, eles podem ser satisfeitos:
47
por um ponto de venda (bilheteria) falando com um cliente ou por meio de uma mquina
automtica;
por meio da impresso dos bilhetes em papel ou apenas a imagem deles em um smartphone,
com o acesso ao sistema em uma pgina Web ou em aplicaes para smartphones Apple e
Android, por exemplo.
Observe que h muitas alternativas de como exibir o contedo e comunicar as escolhas.

O importante que sem um requisito base impossvel criticar e avaliar com preciso o valor relativo de
cada alternativa.
O diagrama de atividades projetado para fornecer uma definio precisa dos requisitos bsicos de uma
perspectiva lgica, sequencial.
07
2.2 - Definindo mtodos
O diagrama Atividade tambm pode ser usado para modelar a implementao de mtodos complexos.
Ao definir a implementao de uma operao, voc precisa modelar a sequncia de manipulao de
dados e transformaes, lgica de programao e decises. A modelagem dessas funes complexas
pode evitar problemas futuros, quando voc escrever o cdigo, revelando todos os requisitos
explicitamente no diagrama. A modelagem apresenta e permite o teste mental de todas as
possibilidades possveis, tornando-as mais fceis de rever e corrigir.
muito tentador resumir ou dispensar a modelagem as atividades, mas o

verdadeiro valor da modelagem est em revelar o que sabe, para que ele
possa ser contestado e verificado. Fazendo suposies visveis (explcitas) a
reviso e a correo tornam-se mais fcil (alm de extremamente valioso).
As modernas ferramentas de UML implementam o diagrama de atividades com todas as construes
lgicas que voc encontra na maioria das linguagens de programao. Na verdade, ele se traduz muito
bem em uma narrativa de cdigo ou mesmo rascunho do cdigo fonte.
As modernas ferramentas de UML implementam o diagrama de atividades com todas as construes
lgicas que voc encontra na maioria das linguagens de programao. Na verdade, ele se traduz muito
bem em uma narrativa de cdigo ou mesmo rascunho do cdigo fonte.
08
3 - NOTAO DE UM DIAGRAMA DE ATIVIDADES

3.1. Atividades e transies
48
Uma atividade uma etapa de um processo em que algum trabalho que est sendo feito. Poderia ser
um clculo matemtico, encontrar alguns dados, manipulao de informaes, ou a verificao dos
dados.
A atividade representada por um retngulo com os cantos arredondados e dentro dele um texto para
descrever a ao. Por boa prtica, as atividades sempre so escritas no idioma portugus utilizando
verbos no infinitivo e um substantivo que d a noo exata da ao que est sendo feita. Exemplos:
calcular salrio, pesquisar cliente, gravar dados do cliente, atualizar conta corrente, importar dados de
venda, imprimir relatrio fiscal etc.
Um diagrama de atividades contm sempre mais de uma atividade, ligadas por transies,
representadas por setas que ligam cada atividade. Normalmente a transio ocorre porque a atividade
concluda. Por exemplo, voc est atualmente na atividade de "ler a pgina." Quando voc terminar a
atividade, voc alterna para a atividade "virar a pgina". Quando voc terminar de virar a pgina, voc
volta para a atividade ler a pgina. Veja como representar graficamente essas duas atividades:
Diagrama de atividades representando o relacionamento entre duas atividades
09
3.1.1. Condio de guarda
Em um determinado cenrio, uma transio de uma atividade para outra s pode ocorrer quando uma
certa condio tornar-se verdadeira. Isso especialmente til quanto queremos representar um
processamento contnuo at que todas as entradas tenham sido processadas.
Exemplos prticos para isso seriam:
Incluir produto na nota fiscal, enquanto houver itens no pedido de compra a serem
processados;
Digitalizar documento, enquanto houver pginas a serem digitalizadas;
Copiar arquivos, enquanto houver arquivos a serem copiados.
A representao de uma condio de guarda feita por meio de um texto entre os sinais de [ e ].
Exemplo: [Enquanto houver arquivos a serem copiados].
Para o exemplo do diagrama anterior, a pgina s pode ser virada quando todo o contedo da pgina
atual tiver sido lido. Dessa forma, a representao do diagrama anterior poderia ser evoluda para:

49
Diagrama de atividades representando o relacionamento entre duas atividades.
10
3.2. Incio e fim de um diagrama de atividade
Para diagramar o incio (que sempre nico) e o(s) encerramento(s) (que podem ser um ou vrios) de
um diagrama de atividades, utilizamos o smbolo de uma bola preta para simbolizar o incio e uma bola
preta com um aro externo para simbolizar o encerramento. O diagrama anterior poderia incluir a
indicao de incio e encerramento sendo assustado para:
Diagrama de atividades incluindo a representao do incio e do fim do processo.
11
3.3. Deciso
Uma deciso refere-se possibilidade de o fluxo seguir um ou outro caminho dependendo de uma
determinada condio.
Tanto na tcnica de fluxograma quando na UML, a deciso representada por um losango. A diferena
que no fluxograma geralmente h uma pergunta dentro do losango (exemplo: Qual foi a cor
escolhida). J na UML, no h a pergunta dentro do losango, mas, em cada linha de sada da deciso, h
a representao da deciso escolhida entre os sinais de [ e ] (exemplos: [amarelo], [azul], [branco ou
verde] perceba que uma condio pode comportar mais de uma hiptese). Um exemplo de um
diagrama com uma deciso est expresso a seguir:

50
Diagrama de atividades representando uma condio.

As decises podem ser descritas como expresses lgicas simples ou complexas, como por exemplo:
[estoque >0]
[existe vendedor disponvel]
[sexo = masculino]
[sexo = masculino E estado civil = solteiro]
[idade entre (18, 70)]
[(sexo = masculino E estado civil = solteiro) OU (idade entre (18, 70)]
12
3.4. Juno
Junes representam a unio de dois caminhos distintos.
A representao da juno tambm feita por um losango que recebe todos os caminhos unidos. A
condio para que o processo continue a sensibilizao de todos os caminhos juntados. No exemplo
abaixo, perceba que a atividade concluir a venda s acontecer quando as atividades escolher itens
e confirmar estoque disponvel forem concludas. Enquanto qualquer uma delas no tenha sido
concluda, a atividade concluir a venda no ser executada.
Diagrama de atividades representando uma juno.

51
A juno representa a necessidade de unio de dois ou mais fluxos a fim de sensibilizar a entrada de
outra atividade. possvel que uma atividade tenha mais de um fluxo de sada, portanto, a juno une
fluxos e no atividades.
13
3.5. Atividades e aes
Dependendo da complexidade de uma atividade, ela pode ser detalhada em outro diagrama que
represente atividades menores, mais facilmente compreensveis. Entretanto, devemos ter cuidado ao
detalhar demais, pois podemos ter um desenho altamente complexo e desnecessrio. Voc deve
sempre utilizar o bom senso em saber at onde deve detalhar a atividade.
Todo item de alto nvel chamado de atividade pela UML, j o ltimo nvel de detalhamento, aquele
que no pode ser mais detalhado em subpartes menores, chamado de ao pela UML. Desta forma,
dizemos que um processo um conjunto de atividades, e uma atividade pode ser decomposta em
aes.
Um exemplo prtico o ajudar a entender melhor a ideia. No diagrama anterior, a atividade confirmar
estoque disponvel pode ser detalhada da seguinte maneira:
Diagrama de atividades representando uma diviso de uma atividade complexa em aes.

Quanto maior o detalhamento, maior o controle sobre aquilo que
ser feito, entretanto, sua documentao fica mais complexa e mais
inflexvel quando as regras e alternativas de solues adotadas.
14
3.6. Raias e Piscinas
a) Raias
Raias representam a separao de papis.

52
Esse termo vem das raias das piscinas de natao, pois uma pessoa numa raia no invade outra raia.
Aqui a ideia a mesma: aquilo que acontece em uma raia restringe-se quele escopo /sistema
/dimenso /papel do usurio.
Dessa forma, as raias separam as atividades respectivas de cada papel de usurio em uma operao.
Veja por exemplo um sistema de venda de um produto.
Poderamos pensar, de forma bem simples, em dois papis de pessoas que participam desse processo:
o cliente e o vendedor. As atividades de cada papel ficariam em uma raia isolada. Resumidamente,
teramos um diagrama assim:
Diagrama de atividades resumido de um processo de venda.

Voc seria capaz de evoluir esse diagrama incluindo os papeis do caixa e do estoquista? Refaa o
diagrama, use lpis e papel se no tiver um software de UML disponvel.
15
b) Piscinas
Para representar ambientes distintos (como sistemas distintos, ou operaes no sistema e operaes
manuais), normalmente criamos piscinas separadas, ou seja, raias que no se tocam.
Enquanto raias separam papis, piscinas separam ambientes. Graficamente, a diferena que raias so
desenhadas tocando-se lateralmente (retngulos lado-a-lado), enquanto piscinas so isoladas por um
pequeno espao em branco (retngulos que no se tocam).
Um diagrama de atividades pode conter quantas piscinas e raias forem necessrias. Inclusive um mesmo
diagrama pode conter representaes de raias e piscinas ao mesmo tempo.
Por exemplo, dentro de um sistema qualquer poderamos usar raias para representar:
a. o que acontece dentro do universo do banco de dados;
b. outra raia para representar o que acontece no servidor da aplicao; e
c. uma ltima para o que acontece no computador do usurio (cdigo em Java Script, por
exemplo).
53
A seguir vamos ver um exemplo utilizando piscinas.
16
Exemplo do uso de piscinas
Suponha que voc tenha uma atividade no seu sistema que se chama efetuar pagamento do boleto
bancrio no site homebanking do banco e que voc queira detalhar todas as aes pertinentes a esta
atividade. Em primeiro lugar, vamos determinar quantas piscinas existiro:
a. uma para a aplicao da empresa,
b. outra para o sistema bancrio e
c. outra para as atividades manuais do operador do sistema.
Como essas informaes tratam de ambientes distintos (dois sistemas distintos e um conjunto de
operaes manuais), o correto utilizar piscinas (e no raias).
Feito isso, precisamos detalhar todas as operaes necessrias (as aes):
Acessar o site homebanking do banco;
Localizar no menu de opes a funcionalidade efetuar pagamento de boleto;
Clicar na funcionalidade;
Preencher os dados de pagamento: data de vencimento, cdigo de barras, valor, desconto (se
houver);
Digitar a senha de pagamento;
Confirmar a operao;
Digitar o cdigo da operao bancria no sistema da empresa.
Imprimir o comprovante de pagamento;
Grampear o comprovante ao boleto fsico;
Guardar o comprovante e o boleto na pasta de contas pagas da empresa.
Veja como seria a representao do cenrio acima com trs piscinas (uma, para o sistema da empresa,
outra, para o homebanking e outro, para as operaes manuais).

54
Exemplo de diagrama de atividades representando vrias piscinas.

Nesse caso, observe que a documentao extrapola o sistema de informao e detalha o prprio
trabalho manual que feito na empresa para efetuar o pagamento da conta. Observe que a
documentao UML pode ter sua fronteira definida no s no sistema que estamos programando, mas
percorrendo todas as aes que as pessoas tm de fazer para tudo funcionar a contento.
17
3.7. Concorrncia
Concorrncia (ou paralelismo) refere-se possibilidade de realizar vrias aes ao mesmo tempo.
Essa questo especialmente til quando um determinado processo precisa realizar vrias aes
logicamente independentes entre si, em outras palavras, elas podem ser executadas to logo exista
disponibilidade para o sistema execut-las, elas no precisam ocorrer em sequncia.
Suponha, por exemplo, que um sistema que voc crie ir efetuar pesquisas por passagens areas em
diversas companhias areas. Voc no precisa pesquisar a companhia A primeiro para depois pesquisar
a companhia B, depois a C, depois a D e assim sucessivamente. Voc pode disparar quatro consultas ao
mesmo tempo aos sistemas das quatro companhias, e, medida que os resultados vo sendo
processados e comunicados ao seu sistema, voc poder apresent-los ao seu usurio.
A representao de uma concorrncia a de um garfo. Para posterior juno, utiliza-se a funo de
sincronizao. Veja para o cenrio descrito no exemplo acima, poderamos ter uma representao
simplificada assim:

55
Diagrama de atividades representando uma concorrncia.

Identificar uma oportunidade de concorrncia no significa a definio de
um requisito de concorrncia, mas to somente uma melhor forma de se
fazer um determinado trabalho. A definio do requisito deve ser feita por
meio de documento especfico ou caso de uso, ambos provindos de
entrevistas com os usurios da aplicao (ou demandantes da aplicao).
18
4 - EXERCCIO PRTICO
A melhor forma de aprender a diagramar UML executar exerccios prticos. Para esses exerccios que
faremos agora, voc no precisa nem de um software de UML, basta lpis e papel.
4.1. Mquina automtica de venda de ingresso de cinema
No mdulo passado j apresentamos um diagrama de venda de ingressos de cinema. Voc se lembra
daquele diagrama que utilizamos para exemplificar os cenrios do caso de uso? Para relembr-lo,
representamos novamente o diagrama simplificado abaixo:
Diagrama simplificado de atividades representando o processo de venda de ingresso de cinema.
19
Entretanto, pensando em uma representao completa do diagrama, pode ser necessrio que
especifiquemos todos os smbolos UML. Dessa forma, veja como ficaria uma reviso das primeiras trs
atividades apenas:
56
Diagrama revisado de atividades representando apenas as trs primeiras atividades de venda de

ingresso de cinema
(observao: devido ao fato de o diagrama completo ficar muito grande, optamos
por representar apenas o detalhamento das trs primeiras atividades).
A representao completa s precisa ser assim detalhada em dois casos:
a. quando a ferramenta UML responsvel por gerar cdigo fonte do sequenciamento das
atividades;
b. quando as atividades so to crticas e/ou complexas que merecem esse detalhamento.
Caso o objetivo da documentao seja restrito comunicao e informao do funcionamento do
projeto para o desenvolvedor de sistemas (e futuramente ao testador do sistema), provavelmente, um
diagrama resumido (como o primeiro) ser suficiente.

57
20
RESUMO
a. O diagrama de atividades da UML 1.4 muito semelhante a um fluxograma clssico. Ele pode
ser aplicado a qualquer processo, grande ou pequeno. Trs aplicaes comuns de diagramas de
atividades so para explicar o fluxo de trabalho (uma srie de casos de uso), para explicar um
nico caso de uso, e para explicar um mtodo (a sequncia de aes realizadas pelo mtodo).
b. O diagrama de atividades representa uma tarefa como um retngulo com os cantos
arredondados, contendo uma descrio de texto de forma livre da tarefa. A transio de uma
atividade para a prxima mostrada como uma seta. A notao prev pontos de incio e fim,
usando um pequeno crculo pintado e um crculo pintado com um anel externo,
respectivamente.
c. As decises so representadas como um pequeno losango. Cada transio de sada deve ser
marcada com uma condio de guarda (com texto entre colchetes), e as condies devem ser
mutuamente exclusivas. O losango tambm pode ser usado para representar um ponto de
fuso, unindo dois ou mais percursos alternativos na sequncia.
d. As condies de guarda tambm podem ser usadas em transies deixando uma atividade, em
que o resultado da atividade fornece todas as informaes necessrias para cumprir uma das
condies.
e. A concorrncia refere-se s mltiplas atividades ocorrendo simultaneamente. Uma barra do tipo
garfo representa uma transio de entrada para iniciar vrias transies. A barra de
sincronizao mostra vrias transies chegando ao fim e uma nova transio combinando-as.
f.
Muitas vezes, uma explicao textual pode ser um pouco ambgua para a definio de um
processo complexo. O diagrama de atividades normalmente utilizado como uma ferramenta
para facilitar a comunicao das explicaes textuais.
g. Para traduzir a descrio do usurio em um diagrama de atividades, isole cada tarefa como uma
atividade. Indique a sequncia das tarefas desenhando uma seta de transio de uma atividade
para a prxima atividade na sequncia.
h. Para modelar as decises no processo, voc tem duas opes. Uma deciso que resulta da
concluso de uma atividade desenhada com condies de guarda (cada transio para fora da
atividade marcada com uma nica e mutuamente exclusiva expresso condicional entre
colchetes). Para representar uma deciso que no o resultado de uma atividade especfica,
utilize o cone de losango. Cada transio para fora do ponto de deciso do losango tambm
marcada com uma expresso condicional nica entre colchetes (exemplo: [sim] e [no]).
58
i.
Quando o fluxo lgico do processo precisa retornar a um ponto anterior no fluxo, use o cone de
losango para representar um ponto de fuso. Pode haver duas ou mais setas que entram no
ponto de fuso, mas apenas uma pode sair.

MDULO 3 DIAGRAMA DE CLASSES CONCEITOS
01
1 - RECONHECENDO CLASSES E OBJETOS

Nesta etapa voc aprender os conceitos mais comuns e utilizados no dia a dia no desenvolvimento de
aplicaes orientadas a objetos. Tanto atuando como um modelador de sistemas quanto como um
programador, ns iremos familiariz-los com os conceitos de objetos, classes, associao, generalizao,
agregao e pacotes. Voc ver detalhes importantes sobre a notao de modelagem de objetos por
meio da UML e ver dicas importantes e boas prticas. Voc tambm poder identificar os problemas
mais comuns que dever evitar.
O incio de um projeto de software tambm o momento mais importante do projeto. Saber utilizar
bem o tempo gasto nessa fase primordial para obter uma boa concepo do projeto. Nesse momento
voc dever ser capaz de identificar os atributos das classes, as operaes que elas podero realizar e
quais partes devem permanecer privadas ou expostas (compartilhadas).
Tela de diagramas UML do Visual Paradigm, em destaque, o diagrama de classes.

59
02
O diagrama de classes sem dvida o diagrama mais utilizado na UML. A ideia aqui no qualificar o
diagrama de classes como o diagrama mais importante da UML, todos os diagramas so importantes,
mas o diagrama de classes aquele que, em modelagens mais simples, o escolhido como o mais
desejvel pelas equipes. Portanto, d uma ateno especial para este diagrama (ele contempla boa
parte do nosso estudo), pois certamente ser o que voc mais ir modelar e analisar no seu dia a dia.
As classes formam a base do diagrama de classes. Para modelar esse tipo de diagrama, voc precisa
estar bem seguro sobre a diferena entre classes e objetos. Uma classe uma definio de um recurso.
A classe descreve as caractersticas de uma entidade e como ela pode ser usada. Em contraste,
um objeto uma entidade identificvel de forma especfica, que est de acordo com as regras definidas
pela classe.
Em termos de software, o cdigo escrito como um conjunto de classes e referncias a
comportamentos definidos pelas classes. A informao criada e manipulada pelos usurios pertence a
objetos que estejam em conformidade com as descries de classe. Os objetos so representados por
linhas em um banco de dados, registros em arquivos, ou reas de memria em um computador.
Um exemplo prtico de um software que faa o gerenciamento de vendas de uma padaria:
Nas classes voc informar quais atributos um produto pode ter, como nome, valor, descrio,
marca, modelo, quantidade em estoque. Sobre a classe venda, voc dir que ela possui
produtos associados, que possui data, valor total, cliente etc.
Nos objetos estar o contedo de uma venda real. Um objeto de venda pode incluir os
produtos po, leite e queijo, no valor total de R$ 12,00. O objeto leite conter a informao de
quantos litros de leite o cliente est comprando e o valor unitrio de cada litro.
03
1.1. Classe
Uma classe representa as caractersticas, estruturas e comportamentos de uma espcie comum.
Quando pensamos em um ser humano como uma pessoa, identificamos que pessoa uma classe
que possui vrios atributos como nome, idade, sexo, altura, peso, nacionalidade, estado civil, e outros. A
classe pessoa tambm possui comportamentos comuns, toda pessoa pode andar, dormir, comer,
sentar-se. Essas caractersticas e comportamentos comuns o que tipifica uma pessoa. Em se tratando
de sistemas de informao, essencial que sejam identificados todos os tipos de item que o sistema
ir tratar. Pense por exemplo em uma livraria, tipos de itens comuns para um sistema de gerenciamento
de uma livraria seriam: livros, autores, editoras, clientes, fornecedores, vendas, compras, e outros.
1.2. Objeto
Um objeto uma classe materializada, uma classe que existe e que tem identidade prpria.
60
Quando pensamos em pessoa, no pensamos em algum especfico, mas quando falamos em Pedro
lvares Cabral, a sim sabemos exatamente quem ele . No conceito de um sistema para
gerenciamento de uma livraria, seriam exemplos de objetos: o livro de culinria cozinhe feliz, o autor
Joo Cruz Neto, a editora Brasil e-books, o cliente Joo Feliciano, o fornecedor grfica
bandeirante, e outros.
Objetos so criados a partir de classes predefinidas. Quando pensamos em um sistema de informao,
precisamos identificar qual a realidade daquela empresa que utilizar o sistema, e assim conseguir
identificar as classes que o sistema dever possuir. Tudo aquilo que existir como objeto no mundo real
da empresa, poder existir como um objeto no software que voc ir construir.
04
Uma das formas mais comuns de voc identificar os objetos e classes de um futuro sistema de
informao escrever todos os procedimentos que o sistema deve fazer. Feito isso, identifique todos os
substantivos descritos e avalie se:
a. Ele representa uma coisa em particular (um objeto) ou um conjunto de coisas semelhantes (uma
classe);
b. Ele parte do problema a ser resolvido ( escopo do projeto);
c. Ele no parte de um detalhe de implementao (uma caracterstica de um objeto);
d. Ele no um evento ou uma ocorrncia;
e. Ele no uma propriedade (uma caracterstica) de uma coisa.
Aps essa anlise, bem provvel que voc consiga identificar as classes e objetos do sistema. Veja, no
pequeno exemplo da realidade de uma livraria, como poderamos hipoteticamente identificar alguns
objetos e classes:
O cliente vem loja e procurar por um ou mais livros de seu interesse. Ele pesquisa o preo dos livros
por meio da etiqueta afixada em cada livro. Se houver interesse, ele pode comprar um ou mais livros,
pagando em dinheiro, carto ou cheque.
Neste pequeno exemplo conseguimos identificar os seguintes objetos e classes:
Cliente
Classe que define (generaliza) as caractersticas das pessoas que vo livraria comprar livros.
Livros
61
Classe que define (generaliza) as caractersticas dos produtos que a livraria vende.
Etiqueta
Classe que possui algumas das informaes dos livros (como cdigo de barras e preo). Possui uma
associao com a classe livro.
Dinheiro, carto e cheque
Podem ser entendidos como classes isoladas ou generalizados como uma classe de nome forma de
pagamento.
05
Outras informaes que tambm conseguimos identificar:
Procurar uma atividade que futuramente ser um mtodo de alguma classe.
Preo um atributo de um livro.
Venda classe subentendida que existe na operao de comprar, possui associao com as
classes cliente e livros.
Cliente e vendedor atores dos casos de uso pertinentes ao cenrio.
Pesquisar livros, comprar livros, efetuar pagamento, pagar com dinheiro, pagar com carto,
pagar com cheque casos de uso do cenrio.
Dessa forma, as informaes que encontramos ao analisar um cenrio so caracterizadas por:

Tipo de informao
Exemplo
Parece ser...
Um conjunto de coisas
Livro, Cliente
Uma Classe
Um nome prprio
Livro Cozinhe Feliz, Cliente

Pedro Afonso Neto
Um objeto
Uma propriedade de alguma

coisa
Preo, Quantidade em estoque
Um atributo
Um valor ou um dado
R$ 47,00; 44 unidades; Cozinhe

Feliz; Pedro Afonso Neto
O valor de um atributo

62
Uma condio de uma coisa
Em falta, Em estoque
Um estado
Uma ocorrncia, evento ou

tempo
Cliente chega loja; o telefone

toca; o cliente pesquisa o preo
Uma operao
Parte da implementao
Banco de dados, tabela
Deixe para o posterior momento

do designer da aplicao
Um papel
Cliente
Deixe para o diagrama de casos

de uso
Comprar
Ser utilizando como um

mtodo em uma classe e
tambm no diagrama de
atividades.
Pagar com carto
Ser utilizado como um mtodo

em uma classe, um item em um
diagrama de atividades e um
caso de uso.
Uma atividade
Um caso de uso
06
Veja que ao analisar um cenrio, identificamos ao mesmo tempo informaes de classes, casos de
uso e atividades. Nossos modelos sero criados e evoludos na medida em que as informaes vo
ficando cada vez mais detalhadas e precisas.
Crie uma lista dos nomes que fazem sentido para o contexto. Seja generoso, se algo parece ser
duvidoso, adicione lista da mesma forma (depois voc eliminar redundncias e itens que no sero
escopo, em outros casos, essas informaes podero vir a tornarem-se atributos, eventos e outros).
Aps identificar os objetos, procure inferir quais classes criam e definem esses objetos.
A chave para identificar essas informaes analisar
completamente a descrio do negcio a ser resolvido pelo
sistema (ou que j existe na organizao). Se o processo de
trabalho ainda no existe, crie um (ou pea para algum especialista
no assunto criar um).
Na maioria das vezes, a
descrio do comportamento do sistema a melhor forma de organizar o conjunto de entidades
(chamada de atores), validando seus objetivos individuais (chamados casos de uso) que sero invocados
pelo sistema.
63
Trataremos de atores e casos de uso mais frente, ainda nesta disciplina.
07
2 - NOMEANDO CLASSES E OBJETOS

Aps identificar as classes e objetos que voc quer no seu sistema, hora de definir como voc ir
cham-los. Todo projeto pode conter suas prprias regras de como nomear classes, mas os nomes que
voc ir definir tambm devem seguir alguns padres e boas prticas do mercado. Veja algumas regras
bsicas que a maioria dos projetos de software utilizam para nomear classes:
Use sempre substantivos (verbos no infinitivo s aparecem em mtodos);
Use sempre o singular (use o plural apenas em objetos, nunca em classes);
Evite pronomes, adjetivos, advrbios, artigos e preposies;
Use as iniciais em maisculo;
No use espaos, caracteres acentuados ou cedilha;
Seguindo essas regras, podemos imaginar alguns exemplos hipotticos de classes para um sistema de
biblioteca: PedidoCompra, Venda, Livro, Cliente, Vendedor.
Levando em considerao que o objetivo de um bom nome prover uma informao rpida e precisa,
evite qualquer coisa que possa confundir ou deixar a interpretao lenta. Uma boa poltica evitar
qualquer tipo de abreviao e palavras com duplo sentido (homnimos).
08
2.1 Encapsulamento (ou encapsulao)
O encapsulamento uma forma de organizar os vrios tipos de informao e comportamento descrito
anteriormente para que os objetos possam ser utilizados da forma mais eficiente e eficaz possvel. A
encapsulao afirma que ao projetar um objeto que deve separar o que sabemos sobre o objeto de
acordo com dois conceitos:
As informaes mnimas necessrias para usar o objeto.
As informaes necessrias para fazer funcionar o objeto corretamente.
Estes dois conceitos nos orientam a olhar para o objeto a partir de duas perspectivas: uma viso
externa: "O que eu posso fazer com este objeto?" e uma viso interna: "Como que esta coisa
funciona?"
Encapsular est ligado ideia de proteger e esconder dentro da classe aquilo que quem a chama no
precisa saber (por exemplo, como ela funciona) e divulgar, mostrar, deixar expostas as informaes
64
(atributos) e aes (mtodos) necessrias para poder utilizar a classe.
09
Encapsular possui os seguintes objetivos:
Juntar as partes afins e semelhantes de forma a criar um contexto completo e funcional ao

objeto;
Proteger a funcionalidade interna.
Veja por exemplo essa situao hipottica: suponha que voc esteja construindo um carro e voc
compra um motor pronto de um fabricante. Voc no precisa saber como funciona os cilindros, como o
cabeote est fixado, como os pistes rodaro o virabrequim, pois todos esses itens esto
encapsulados dentro do motor. O que voc precisa saber para usar o motor : por onde colocar o
combustvel, como controlar a potncia do motor, por onde ser fixado ao carro, por onde ser
conectado ao sistema de cmbio e embreagem. Esses sos os mtodos e propriedades do motor que
ficam expostos a voc.
Na prtica, voc poderia ter hipoteticamente o seguinte cenrio: suponha que voc esteja criando uma
aplicao que toque msicas MP3. Voc pode criar uma classe que exponha um local para ser informado
o local do arquivo MP3 e funes para tocar, parar, adiantar, voltar e pausar. Quem chama essa classe
no precisa saber qual o cdigo fonte que voc utilizou para fazer a msica tocar, essa parte est
protegida (encapsulada); quem chama essa classe, s precisa saber como enviar o arquivo MP3
(atributo) e como realizar as operaes citadas (mtodos), essa a parte pblica da classe.
10
2.2 Diagramando uma classe
Falamos anteriormente que a UML uma tcnica de diagramao. Neste sentido, cada componente
deve ser representado como um desenho geomtrico. Em se tratando de classes e objetos, o desenho
geomtrico que representa esses componentes o retngulo, onde, dentro dele, colocamos o nome da
classe ou do objeto. O layout padro :
Para diferenciar objetos de classes, a regra estabelece que objetos devam ser escritos com o nome do
objeto, seguindo por dois pontos, e depois o nome da classe. Nesta ideia, para representar o objeto
cliente da classe Pessoa, teramos algo como:

65
Se o texto do retngulo fosse apenas cliente, no saberamos dizer, a princpio, a qual classe ele
pertence.
11
2.3 Utilizando setas para indicar a classe do objeto
A UML permite mais de uma maneira de representar a mesma informao. Isso significa que voc deve
utilizar aquela mais adequada para sua necessidade. A redundncia muitas vezes aprimora a qualidade
da comunicao, entretanto, traz consigo um diagrama mais complexo.
A UML possui uma outra forma de representar a relao de classe-objeto, ela pode ser vista pela
representao de dois retngulos interligados por uma seta pontilhada que liga o objeto classe. Para o
exemplo anterior, a relao cliente-Pessoa poderia ser representada assim:
Tenha em mente que ao utilizar essa notao, o seu diagrama conter o dobro de retngulos (e as setas)
do que a forma anterior.
12
3 - DEFININDO ASSOCIAES E LINKS (LIGAES)

Identificar os objetos e classes individuais apenas o comeo de modelagem. Para que os objetos e
classes de um software realizem o respectivo trabalho a ser feito, eles precisam trabalhar juntos de
forma a representar o contexto do trabalho a ser feito.
Por exemplo, quando um cliente solicita ingressos de um filme (cinema), o sistema cria uma venda e
adiciona ingressos para essa venda. Ainda, associa um filme, uma sesso, reserva poltronas e pode
definir outras caractersticas do ingresso (como por exemplo valor promocional para estudante ou
idosos). Os objetos de software que representam os clientes, a venda, a sesso do filme, as poltronas, e
os ingressos precisam replicar exatamente as relaes entre os objetos do mundo real.
Ateno quanto nomenclatura da UML:
um link (ligao) uma relao entre dois objetos;

uma associao um relacionamento entre duas classes.

66
Uma associao a definio de um tipo de link (ligao) da mesma forma que uma classe a definio
de um tipo de objeto. Assim como um objeto uma instncia de uma classe, um link um exemplo de
uma associao.
Associaes (e links) podem assumir trs formas diferentes: associao, agregao e composio. A
forma mais simples, a associao, uma relao ponto a ponto. Um objeto simplesmente sabe sobre
outro objeto da mesma forma que uma pessoa pode saber sobre outra pessoa. Esse conhecimento
normalmente armazenado no objeto como uma referncia, como uma pessoa que mantm um nmero
de telefone ou endereo de outra pessoa que ele quer entrar em contato.
13
Uma associao geralmente modelada como uma linha de chamada entre duas classes, conforme
mostrado abaixo.
Exemplo de associao entre objetos.

No mundo real, podemos identificar as mesmas relaes representadas no diagrama:
Um cliente solicita uma venda de ingressos;
A venda inclui, obviamente, um ou vrios ingressos;
A venda de ingressos refere-se a uma sesso de cinema;
A sesso de cinema possui poltronas (disponveis e ocupadas);
A sesso de cinema representa o horrio de um filme especfico.
Essas associaes representam que, no contexto apresentado, h uma relao entre elas para que a
funcionalidade do sistema seja vlida.
14
A associao usada para juntar dois objetos distintos em um contexto: quando voc junta pessoa
venda apenas naquele contexto que existe essa associao.
A associao corresponde a relaes temporrias e rpidas para um
objetivo em comum de objetos distintos.

67
Uma associao pode ser nomeada para deixar o relacionamento ainda mais claro. importante levar
em considerao que devemos sempre usar a voz ativa (evitando a voz passiva). Dessa forma, como
exemplo, as classes Venda e Produtos podem ser relacionadas pelo texto inclui (uma venda inclui
produtos). O nome so includos (produtos so includos em uma venda) no uma boa escolha.
Exemplo de nomenclatura de uma relao entre classes

Assim como no mundo real, as associaes podem requerer regras especficas para controlar o
relacionamento entre elas. Quem participa do relacionamento? Quantos objetos podem participar?
Como os participantes controlam o comportamento do objeto? Em qual direo a associao deve ser
ligada? Quando o relacionamento comea e termina? As regras so definidas e representadas por meio
de multiplicidade, restries, indicadores de direo, classes de associao papis e comentrios. Cada
um deles ser apresentado no devido tempo com a evoluo dessa matria.
15
3.1 Tipos de Associao
As associaes podem ser refinadas em um modelo mais restritivo de relacionamento, chamado
agregao. Uma agregao pode ainda ser refinada em um relacionamento ainda mais restritivo,
denominado composio.
Associao
Agregao
Os objetos sabem da
existncia do
relacionamento que h
entre si, dessa forma eles
podem trabalhar juntos.
A integridade da
configurao protegida.
Funcionam como um nico
objeto.
Um objeto controla todos
os outros.
Toda agregao um tipo
de associao.
Toda agregao possui as
caractersticas de uma
associao e outras novas
especficas da agregao.
Composio
Cada parte s pode ser

membro de um objeto
agregado
Toda composio um
tipo de agregao.
Toda composio
possui as
caractersticas de uma
agregao e outras
novas especficas da
composio.
16
3.2 Definindo agregaes
A agregao um tipo especial de associao usada para indicar que os objetos participantes no so
apenas objetos independentes que sabem sobre o outro. Em vez disso, eles so montados ou
68
configurados em conjunto para criar um novo objeto, mais complexo.
Por exemplo, um automvel composto por vrias partes: motor, carroceria, rodas etc. A associao
que essas peas tm com o automvel do tipo agregao: um automvel agrega vrias partes juntas,
como uma carroceria, um motor, quatro rodas etc..
Para modelar a agregao em um diagrama de classes:
Desenhe uma associao (linha) entre a classe que representa o membro ou parte do conjunto e
da classe que representa a agregao, ou seja, o conjunto (o todo).
Desenhe um losango na extremidade da associao que est ligado classe agregadora.

Exemplo: no relacionamento entre automvel e motor, a classe automvel possuiria um losango
para representar que um automvel inclui um motor.
Voltando ao nosso exemplo anterior, da venda de ingressos de cinema, podemos perceber que h uma
relao intensa entre a sesso de cinema e o filme. No faz sentido o objeto sesso sem ele estar
associado a um filme, da mesma forma, um filme precisa possuir sesses (disponveis) para permitir uma
venda de ingressos. A sesso inclui um filme como parte do seu conjunto. Da mesma forma, tambm h
uma relao entre as poltronas e a sesso de cinema. No faz sentido o objeto poltrona sem que esteja
associado a uma sesso, assim, uma sesso precisa possuir poltronas (disponveis) para permitir uma
venda. Observe que a sesso o centro da questo, ela possui caractersticas prprias (como os
horrios) e incorpora outras informaes (outros objetos), no caso, poltronas e filme. Sob essa tica,
poderamos refinar a associao existente entre sesso, poltronas e filme, criando agregaes e
evoluindo o diagrama para a representao abaixo:
Evoluo do diagrama anterior utilizando agregaes
17
Observe novamente o diagrama:

69
Evoluo do diagrama utilizando agregaes

Note que, com a agregao, o contexto torna-se um pouco mais significativo. Agora, o objeto sesso o
chefe que tem o poder de comandar poltronas e o filme. Dessa forma, o controle, alm de
simplificado (pois, ao invs de comandar esses trs objetos para fazer a venda de ingressos, a classe
venda s precisar comandar um), o contexto tambm fica protegido (a classe venda no precisa nem
pode acionar poltronas e filmes individualmente, tudo poder e dever ser feito por meio da classe
sesso).
Na prtica, teramos esses resultados:
Se voc quer saber quais poltronas esto disponveis, pergunte classe sesso e ela responder.
Se voc quer reservar poltronas, solicite classe sesso e ela responder.
Se voc quer ver uma imagem ou informaes sobre o filme, pergunte classe sesso e ela
responder.
Quer comprar ingresso e marcar a poltrona como reservada? Solicite classe sesso e ela o far.
18
3.3 Definindo a composio
A composio utilizada para agregaes em que o perodo de vida da parte depende do tempo de
vida do objeto agregador. O objeto agregador tem controle sobre a criao e destruio dos objetos
agregados. Em suma, o objeto membro no pode existir para alm da montagem.
Desenhe esta forma mais forte de agregao simplesmente fazendo o losango da agregao se tornar
slido (preto).
No nosso exemplo anterior, percebemos que o objeto ingresso no faz sentido se ele no estiver
associado a uma venda. No existe um ticket em branco. No existe um ingresso que no tenha uma
sesso, poltrona, filme e venda associado. Dessa forma, o relacionamento do ingresso com a venda
mais forte que uma simples agregao, uma associao.
E quanto aos relacionamentos anteriores? Ser que eles poderiam ser uma composio tambm?
70
Vamos ver os dois casos anteriores:
Um filme pode existir por si s, sem uma sesso associada? Sim, o filme pode ser um prlanamento, uma previso, uma propaganda, ento ele pode existir sim sem estar associado a
uma sesso. Ento, a relao entre sesso e filme no chega a ser uma composio.
E poltronas, podem existir poltronas disponveis e reservadas sem estarem associadas a uma
sesso? De forma alguma, o conceito e uso da disponibilidade de poltronas s faz sentido
quando associadas a uma sesso de filme. Se a sesso de filme fosse cancelada, todas as
reservas e disponibilidades de poltronas deixariam de existir. Dessa forma, o relacionamento
to intenso que deve ser evoludo para uma composio.
Percebemos ento que nosso diagrama deve ser atualizado para:
Evoluo do diagrama anterior utilizando composies
19
4 - DEFININDO HERANA E GENERALIZAO

Criar uma generalizao o processo de organizar as caractersticas dos diferentes tipos de objetos que
compartilham a mesma finalidade. Uma generalizao uma descrio das caractersticas comuns de
um conjunto de objetos.
Usamos o processo de generalizao para organizar grandes quantidades de informao. Caminhe por
um supermercado e voc encontra alimentos localizados em reas de armazenamento de acordo com
suas propriedades - produtos enlatados esto localizados em uma rea, frutas e legumes em outro,
gros em outros. Todos esses itens so alimentos, mas so tipos diferentes de alimentos. Frases como
"uma espcie de" ou "tipo de" so muitas vezes utilizados para descrever um relacionamento de
generalizao entre classes (por exemplo, uma ma um tipo de fruta que por sua vez um tipo de
alimento e assim por diante).
Voc tambm pode ouvir esse tipo de relacionamento referido como herana. Muitas vezes os termos
de generalizao e herana so usados como sinnimos. Isso porque se uma ma, por exemplo, um
tipo de fruta, em seguida, ela herda todas as propriedades de fruta. Da mesma forma, uma ma uma
especializao da fruta porque ela herda todas as propriedades generalizadas de frutas e adiciona
71
algumas propriedades nicas que fazem mas especiais ou exclusivas dentro do maior grupo de frutas.
No sentido inverso, eu poderia dizer que o conceito de "fruta" uma generalizao dos fatos que so
verdadeiros para as melancias, mas, pssegos, e todos os tipos de objetos do grupo.
20
A diferena entre os termos generalizao e herana apenas na leitura da relao. Veja o exemplo:
uma banana herda as propriedades das frutas, uma fruta a representao genrica de uma banana.
A generalizao no uma associao. Associaes definem as
regras de como os objetos podem se relacionar entre si. A
generalizao diz que certas classes contm um subconjunto das
propriedades de uma classe superior. Nesse sentido, uma
generalizao no possui atributos e regras comuns das
associaes, como multiplicidade, papel, restries.
Um exemplo bem simples e ilustrativo de herana e generalizao seria o seguinte:
Diagrama de classes mostrando herana e generalizao
21
5 - REPRESENTANDO ATRIBUTOS E OPERAES

Voc j sabe que uma classe possui um nome que a define. Tambm sabe que uma classe contm
propriedades (atributos) e mtodos (operaes).
As propriedades so as informaes da classe que so expostas a quem a chama, por sua vez, os
mtodos so as aes que ela possui para permitir que operaes aconteam dentro dela.

72
Temos ento trs informaes bsicas e precisamos poder represent-las em um diagrama de classes: o
nome, os atributos e os mtodos.
Lembrando que uma classe representada por um retngulo, vamos dividir esse retngulo com duas
linhas horizontais. Em cada compartimento criado, iremos escrever, respectivamente, o nome da classe,
os atributos e as operaes:
Diagrama representando a sintaxe dos itens que compe uma classe

O espao reservado para atributos e operaes pode conter quantos itens forem necessrios. Veja o
exemplo abaixo:
Exemplo de classe com atributos e mtodos.

Na prxima oportunidade iremos ver em detalhes as caractersticas dos atributos e dos mtodos.
RESUMO
a. Classes e objetos: Uma classe uma definio de um tipo de entidade, da mesma forma que um
livro define como deve ser um livro de informtica. Um objeto uma abstrao para uma
nica entidade, como o meu livro de UML. A classe define regras. Um objeto define fatos. Um
objeto instanciado (criado) de acordo com as regras definidas pela sua classe.
b. Abstrao: Uma abstrao uma representao de algo real, como o seu rosto em uma foto:
aquilo que vemos na foto uma representao de voc, e no voc (a pessoa real). Mesmo que
haja uma quantidade quase infinita de informaes sobre qualquer entidade real, uma
abstrao de software til contm apenas a informao suficiente para apoiar a finalidade da
aplicao de software.
c. Encapsulao: Descreve um modo para organizar a informao de uma abstrao de modo que
ele pode ser usado eficientemente em uma aplicao de software. A encapsulao as
73
informaes que precisamos saber da lgica de funcionamento do objeto que no precisamos

conhecer. Para usar um objeto, ele precisa expor a sua finalidade e interfaces. O objeto precisa
conter os dados e comportamentos que satisfaam os servios oferecidos pelas interfaces.
d. Associaes e links: Uma associao define um tipo de relacionamento, da mesma forma que
uma classe define um tipo de entidade. Um link uma abstrao de uma relao especfica que
est em conformidade com as regras estabelecidas por uma associao, da mesma forma que
um objeto uma abstrao de uma entidade que est em conformidade com as regras
estabelecidas por uma classe.
e. Agregao: Agregao um tipo de associao que afirma que um dos objetos participantes
deve desempenhar o papel de controlador do outro objeto. Todas as interaes com o par so
dirigidas para o objeto de controle, o objeto agregador. O objeto agregador define como um
objeto agregado deve se comportar. O objeto agregador propaga as instrues necessrias para
o objeto agregado. As duas caractersticas que definem a agregao so: a) um objeto
desempenha o papel de controlador e outro o papel subordinado; e b) dois (ou mais) objetos se
comportam como um s.
f.
Composio: Composio um tipo de agregao, que afirma que um objeto membro pode
existir se dentro do contexto da agregao. O tempo de vida do membro dependente do
tempo de vida do objeto que o compe.
g. Generalizao, especializao e herana: Generalizar reunir todas as caractersticas comuns a

partir de um conjunto de classes e defini-las em uma nica classe. A generalizao a classe que
contm os recursos compartilhados. Especializar isolar as caractersticas de uma classe que s
se aplica a um subconjunto do objeto dessa classe. A especializao uma classe que contm os
recursos exclusivos para o subconjunto de objetos. A herana o princpio que permite uma
especializao para ter acesso aos recursos em uma generalizao. Um objeto instanciado por
uma classe especializada construdo a partir dos recursos da classe especializada e de todas as
suas caractersticas generalizadas.

74

Análise e Projeto de Sistemas 2 (Uml) Unidade01

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Análise e Projeto de Sistemas 2 (Uml) Unidade01

Hochgeladen von

Copyright:

Verfügbare Formate

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

UNIDADE 1 CONCEITOS INICIAIS SOBRE UML

1 - DIAGRAMAS E REQUISITOS DA DISCIPLINA UML

Diagrama de Caso de Uso;

Diagrama de Caso de Uso

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Diagrama de Mquina de Estados

Diagrama de Estruturas Compostas

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Diagrama de Viso Geral de Interao

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Tela com os principais diagramas da UML no Visual Paradigm

Violet UML Editor

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Outra forma de se organizar os diagramas de acordo com suas caractersticas essenciais:

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Quem usa o sistema?

Do que o sistema feito?

Onde os componentes do sistema esto localizados?

Os diagramas de implantao indicam o plano de onde os componentes do sistema devero ser

Quando eventos importantes do sistema acontecem?

Como o sistema ir funcionar?

Os diagramas de comunicao e de estrutura representam as interaes em um nvel suficientemente

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

2 - IDEIA GERAL SOBRE A UML

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Desenho da arquitetura do sistema

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Indicado principalmente para

Documenta apenas o essencial

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Uma boa metodologia de desenvolvimento de

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Modelos de alto nvel independente de plataformas (tecnologias).

4 - Perfis profissionais de TI que utilizam UML

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Analistas de Sistema, Designers, Engenheiros de Software,

Implementadores, Desenvolvedores, Programadores

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Refere-se a algo til que

O aparelho de ar-condicionado que est na minha sala

Todos os aparelhos e ar-condicionado resfriam o ar. Eles

Um diagrama eltrico de um aparelho de ar-condicionado

Descreve apenas o que

Para operar o ar-condicionado, eu no preciso saber

A maioria das pessoas no precisa saber que o aparelho

O ar-condicionado resfria o ar da sala puxando o ar

2015 - AIEC - Associao Internacional de Educao Continuada

115 Anlise e projeto de sistemas 2 (UML) | Unidade 01

Informa o que comum

Todo aparelho de ar-condicionado possui um filtro de ar

O meu aparelho de ar-condicionado possui um mostrador

Assim como o meu aparelho de ar-condicionado, todos

Nomes idnticos para

Todo aparelho, de qualquer natureza, tem a tecla on,