Uml 2

MODELAGEM
DE
DADOS
Charles Emerson Machado
Charles.emerson.machado@gmail.com
1
2
Um software de alta complexidade não é algo que se produza
simplesmente sentando diante de um ambiente de suporte à
programação e gerando código. Como qualquer desenvolvimento de
alta complexidade, a produção em si precisa de algum planejamento.
Alguém começa a construção de um prédio de vinte andares
assentando tijolos? Antes, há que se desenvolver um projeto. O
mesmo se aplica a máquinas e equipamentos em geral. Com
software complexo não é diferente.
3
Modelagem, no escopo do desenvolvimento de software, constitui um
auxílio ao tratamento da complexidade. Aprender modelagem orientada
a objetos é um requisito básico para quem quer se qualificar ao
desenvolvimento de software de alta complexidade. Modelar software
permite construir um caminho adequado entre o estabelecimento de um
problema e o código que constitui sua solução. Além de auxiliar o
gerenciamento da complexidade evitando que o desenvolvimento perca
o rumo, leva a resultados mais bem estruturados, pois fornece uma
sistemática de identificação e tratamento de problemas.
4
Processo de desenvolvimento de software:
É o conjunto de soluções adotado por uma pessoa ou grupo para

desenvolver software. É composto pelo conjunto de etapas do
desenvolvimento, a sequência de etapas, as atividades associadas a
cada etapa, as metodologias, modelos, padrões e ferramentas
utilizadas em cada atividade.
5
Para capacitar-se como desenvolvedor de software orientado a objetos
com habilidade de desenvolver projeto de software - e não apenas
código – quatro competências são necessárias:
Conhecer os conceitos referentes à modelagem: antes de modelar,

é preciso ter claro por que e para que modelar. Isso envolve desde
noções de Engenharia de Software, do paradigma de orientação a
objetos, até a obtenção de clareza da utilidade da modelagem em um
processo de desenvolvimento, bem como dos requisitos para uma
modelagem bem sucedida;
6
Conhecer uma linguagem de modelagem: atualmente, o padrão
internacionalmente adotado para modelagem orientada a objeto é UML –
especificamente, a segunda versão. É preciso conhecer seus treze
tipos de diagrama, isto é, seus elementos sintáticos e sua aplicabilidade
em um processo de modelagem;
Saber que passos seguir: o desenvolvimento de software – e a

modelagem como parte do processo – consiste em uma sucessão de
esforços que, gradualmente constroem uma solução para um problema
incialmente definido. Modelar demanda seguir um caminho lógico de
construção de especificação. Conhecer esse caminho é um requisito
essencial para o desenvolvimento. É o complemento do conhecimento
de uma linguagem de especificação: saber usá-la;
7
Avaliar o que for produzido: conhecer uma linguagem de
especificação (como UML) e as etapas de um procedimento de
modelagem não garante um desenvolvimento com resultado
satisfatório. É inerente ao desenvolvimento de software que decisões
tenham que ser tomadas com certa frequência, ao longo do processo.
Muitas vezes, sem muita clareza quanto a uma opção ser melhor ou
pior que outra. Pequenas decisões ruins ao longo das etapas podem
resultar em fracasso do desenvolvimento, se o desenvolvedor não se
der conta disso em tempo. Assim é essencial ter a capacidade de
buscar inconsistências na especificação: que tipos de inconsistências
devem ser procurados, onde, como, quando. Além disso, especificações
de projeto podem apresentar imperfeições que não caracterizam
inconsistência. Avaliar o que foi produzido inclui a busca da
maximização da qualidade do processo de desenvolvimento, isto é,
buscar as alternativas que privilegiem a qualidade da especificação.
8
Ciclo de vida do software: Corresponde ao conjunto de etapas por
que um software passar ao longo de sua existência.
Várias alternativas de divisão, com diferentes conjuntos de etapas,

podem ser encontradas na literatura. Aqui será adotada a divisão nas
seguintes etapas:
ANÁLISE DE REQUISITOS->ANÁLISE->DESIGN(PROJETO)->PROGRAMAÇÃO->TESTES
9
Estas cinco fases não devem ser executadas na ordem descrita acima,
mas concomitantemente de forma que problemas detectados numa
certa fase modifiquem e melhorem as fases desenvolvidas
anteriormente de forma que o resultado global gere um produto de alta
qualidade e performance. A seguir falaremos sobre cada fase do
desenvolvimento de um sistema em UML:
10
Análise de Requisitos
Esta fase captura as intenções e necessidades dos usuários do sistema
a ser desenvolvido através do uso de funções chamadas "use-cases".
Através do desenvolvimento de "use-case", as entidades externas ao
sistema (em UML chamados de "atores externos") que interagem e
possuem interesse no sistema são modelados entre as funções que eles
requerem, funções estas chamadas de "use-cases". Os atores externos
e os "use-cases" são modelados com relacionamentos que possuem
comunicação associativa entre eles ou são desmembrados em
hierarquia. Cada "use-case" modelado é descrito através de um texto, e
este especifica os requerimentos do ator externo que utilizará este "use-
case". O diagrama de "use-cases“ mostrará o que os atores externos, ou
seja, os usuários do futuro sistema deverão esperar do aplicativo,
conhecendo toda sua funcionalidade sem importar como esta será
implementada. A análise de requisitos também pode ser desenvolvida
baseada em processos de negócios, e não apenas para sistemas de
software.
11
12
Análise
A fase de análise está preocupada com as primeiras abstrações
(classes e objetos) e mecanismos que estarão presentes no domínio do
problema. As classes são modeladas e ligadas através de
relacionamentos com outras classes, e são descritas no Diagrama de
Classe. As colaborações entre classes também são mostradas neste
diagrama para desenvolver os "use-cases" modelados anteriormente,
estas colaborações são criadas através de modelos dinâmicos em UML.
Na análise, só serão modeladas classes que pertençam ao
domínio principal do problema do software, ou seja, classes técnicas
que gerenciem banco de dados, interface, comunicação, concorrência
e outros não estarão presentes neste diagrama.
13
Conceitos ou Entidades
Representa os conceitos do domínio em estudo.

Perspectiva destinada ao cliente.
14
CLASSES
Tem foco nas principais interfaces da arquitetura, nos principais

métodos, e não como eles irão ser implementados.
Perspectiva destinada as pessoas que não precisam saber
detalhes de desenvolvimento, tais como gerentes de projeto.
15
CLASSES DE SOFTWARE
Aborda vários detalhes de implementação, tais como

navegabilidade, tipo dos atributos, etc.
Perspectiva destinada ao time de desenvolvimento
16
Design (Projeto)
Na fase de design, o resultado da análise é expandido em soluções
técnicas. Novas classes serão adicionadas para prover uma infra-
estrutura técnica: a interface do usuário e de periféricos, gerenciamento
de banco de dados, comunicação com outros sistemas, dentre outros.
As classes do domínio do problema modeladas na fase de análise são
mescladas nessa nova infra-estrutura técnica tornando possível alterar
tanto o domínio do problema quanto a infra-estrutura. O design resulta
no detalhamento das especificações para a fase de programação do
sistema.
17
Programação
Na fase de programação, as classes provenientes do design são
convertidas para o código da linguagem orientada a objetos escolhida
(a utilização de linguagens procedurais é extremamente não
recomendada). Dependendo da capacidade da linguagem usada, essa
conversão pode ser uma tarefa fácil ou muito complicada. No momento
da criação de modelos de análise e design em UML, é melhor evitar
traduzi-los mentalmente em código. Nas fases anteriores, os modelos
criados são o significado do entendimento e da estrutura do sistema,
então, no momento da geração do código onde o analista conclua
antecipadamente sobre modificações em seu conteúdo, seus modelos
não estarão mais demonstrando o real perfil do sistema. A
programação é uma fase separada e distinta onde os modelos criados
são convertidos em código.
18
Testes
Um sistema normalmente é rodado em testes de unidade, integração, e
aceitação. Os testes de unidade são para classes individuais ou grupos
de classes e são geralmente testados pelo programador. Os testes de
integração são aplicados já usando as classes e componentes
integrados para se confirmar se as classes estão cooperando uma com
as outras como especificado nos modelos. Os testes de aceitação
observam o sistema como uma " caixa preta“ e verificam se o sistema
está funcionando como o especificado nos primeiros diagramas de
"use-cases".
19
20
POR QUE É IMPORTANTE USAR POO?
Um dos maiores desafios da programação e análise de sistemas em geral

é a reusabilidade, compartilhamento e arquitetura de divisão em módulos.
Essas questões são imprescindíveis para garantir um desenvolvimento
eficiente e a distribuição de tarefas entre os membros de uma equipe.
O dinamismo nas mudanças de regras de negócio dentro de uma
corporação reforça a necessidade de um desenvolvimento modular
coeso, que permita a execução de manutenções pontuais com facilidade,
sem a geração de efeitos colaterais indesejados em outros subsistemas.
Na busca por soluções para as questões levantadas, a POO posiciona-se
como a melhor opção conhecida até o momento, pois a técnica
naturalmente incentiva a reusabilidade e a divisão do software em
módulos.
21
A idéia central da POO é quebrar o software em classes, onde cada
funcionalidade tenha uma classe para sua implementação. Isso facilita o
desenvolvimento, pois coloca o foco do programador apenas naquela
classe que deve ser implementada, além de permitir que outros membros
da equipe implementem também outras partes ao mesmo tempo, já
considerando a existência dessa classe. É claro que para isso tornar-se
possível deve existir uma fase de modelagem do sistema em classes
antes do início da fase de implementação.
Resumidamente, o processo de desenvolvimento de software para ser
qualitativo e produtivo deve:
•Ter uma consistente e eficiente análise de requisitos;

•Ter planejado antes de iniciar a fase de codificação a arquitetura
sistêmica;
•Ter uma codificação padronizada conforme as técnicas definidas na
POO;
22
•Ter um time ou ferramentas de testes que assegurem que os requisitos
estão sendo atendidos;
•E, para isso funcionar como uma engrenagem ou uma linha de
montagem, se faz necessário ter um ciclo de vida de desenvolvimento
estabelecido e praticado pelos membros do time de projetos;
POO quando corretamente aplicada em projetos de desenvolvimento de

software trará resultados qualitativos à programação e manutenção dos
códigos fontes.
23
UM MUNDO ORIENTADO A OBJETOS
Fazendo uma analogia elucidativa, vamos usar o exemplo da torneira.

Uma torneira tem propriedades e métodos. Um exemplo de
propriedade é sua cor ou modelo. Um exemplo de método é a
possibilidade de abrir e fechar a água, onde a ação de abrir e de fechar
seriam os métodos que você pode programaticamente invocar.
CLASSES
As palavras “reservadas” Classe e Objeto são facilmente confundidas
em diversos textos que se propõe a explicar POO. Genericamente
comentando, uma classe é uma abstração que representa alguma coisa,
e o objeto é a usabilidade dessa representação definida pela classe.
Podemos também afirmar que uma classe é um gabarito para a
definição de objetos. Através da definição de uma classe, descreve-se
que propriedades(ou atributos) e métodos (ou procedimentos/funções)
que o objeto terá.
24
Além da especificação de atributos, a especificação de uma classe
descreve também qual o comportamento de objetos da classe, ou seja,
que funcionalidades podem ser aplicadas a objetos da classe. Essas
funcionalidades são descritas através de métodos. Um método nada mais
é que o equivalente a um procedimento ou função, com a restrição que
ele manipula apenas suas variáveis locais e os atributos que foram
definidos para a classe.
Neste caso, uma classe é a “essência” de um objeto. Ele tem a “receita”
para construção do objeto, bem como definição do que o objeto possuirá
(que propriedades e que métodos) quando for criada uma instância real a
partir dela.
25
Se fizermos uma analogia com a construção civil, o arquiteto escreveria a
classe e o engenheiro a invocaria transformando-a em um objeto.
OBJETOS
Objetos são instâncias de classes. É através deles que praticamente todo

o processamento ocorre em sistemas implementados com linguagens de
programação orientadas a objetos. Um objeto é uma combinação de
códigos e dados que podem ser manuseados como uma unidade. Um
objeto pode ser um pedaço de uma aplicação como um formulário, por
exemplo.
Quando se cria um objeto, ele adquire um espaço em memória para
armazenar seu estado (os valores de seu conjunto de atributos, definidos
pela classe) e um conjunto de operações que podem ser aplicadas ao
objeto, ou seja, o conjunto de métodos definidos pela classe.
26
Um programa orientado a objetos é composto por um conjunto de objetos
que interagem através de “trocas de mensagens”. Na prática, essa troca
de mensagem traduz-se na aplicação de métodos a objetos.
INSTÂNCIA
O instanciamento é o ato de trazer a classe para o mundo real. No

processo de instanciamento, é disparado um método construtor da classe.
Neste momento, inicia-se o tempo de vida de um objeto, que é contado
entre o momento em que o objeto é instanciado e o momento em que ele
é destruído.
27
CONTEÚDO DA CLASSE
Generalização é o processo responsável pela identificação e definição de

atributos e operações comuns em um conjunto de objetos. A
generalização existe para nos auxiliar a encontrar as classes mais
elementares do projeto. Sua correta utilização em projetos POO possibilita
a redução de código redundante e funciona como base para a reutilização
de código promovida pelo mecanismo de herança.
Quando usamos generalização, agrupamos uma série de classes
segundo alguma funcionalidade comum. Como exemplo, imagine uma
classe chamada transporte. Ela pode ser considerada superclasse de
diversas classes mais especializadas em um determinado tipo de
transporte, como aéreo, rodoviário e ferroviário.
Especializar é tratar com interesse especial, particular. Utilizando o
exemplo anterior, ao tratarmos sobre transportes, estamos generalizando,
mas ao tratarmos sobre determinado tipo de transporte, descendo em
detalhes específicos, estaremos especializando.
28
CONTEÚDO DA CLASSE
Concluindo:
•Generalização é o processo utilizado no agrupamento de classes que

possuam atributos e realizam operações semelhantes.
•Especialização é herdar, adicionando funcionalidades para a resolução
de problemas específicos.
29
APLICANDO A POO NA RECEITA DE BOLO
O que é uma receita de bolo?

•Mundo real: é a definição de como se fazer um bolo.
•POO: é uma classe.
O que são os ingredientes?

•Mundo real: são os itens que irão compor o bolo.
•POO: são os atributos da classe.
O que é o modo de preparo?

•Mundo real: é como se deve fazer o bolo.
•POO: são os métodos da classe.
30
O que é o bolo pronto?
•Mundo real: é o bolo devidamente assado, já com a cobertura de
chocolate, como determina a receita, pronto para consumo.
•POO: é a instância da classe.
Depois de pronto, como o bolo se “comporta”?

•Mundo real: exala cheiro, possui temperatura, cor, textura, sabor etc.
•POO: são outros atributos da classe, que devem ser previstos após a
instanciação do objeto.
31
O QUE TORNA UMA LINGUAGEM DE PROGRAMAÇÃO OO?
Para uma linguagem de programação ser considerada OO, ela precisa

oferecer suporte aos principais pilares de OO. São eles:
• Encapsulamento;
• Abstração;
• Herança;
• Polimorfismo;
Para compreensão, os termos “objetos” e “cliente” serão usados para

representar o fornecedor de um determinado recurso e o seu
consumidor, respectivamente. Iremos agora ver a definição de cada um
desses importantíssimos pilares:
32
ENCAPSULAMENTO
É a prática de esconder como um objeto executa as suas operações,

quando ele for solicitado por um cliente. Isso traz muitos benefícios, pois
o cliente não precisa ter a mínima idéia de como o objeto funciona
internamente e, para ele, isso realmente não importa.
Um exemplo: Ao pressionar o pedal acelerador de um carro (objeto), nós
(clientes) não precisamos saber que ele irá aumentar a quantidade de
combustível e ar enviada ao motor, que ira gerar uma maior combustão,
movendo os pistões com mais força e rapidez, com isso aumentando a
velocidade do carro. Para o cliente basta saber que, ao pressionar o
pedal acelerador, o carro irá adquirir velocidade.
33
ABSTRAÇÃO
Segundo o dicionário Aurélio:
abstração [Do lat. Tard. Abstracione.] S.f. 1. Ato de abstrair(-se);

abstraimento. 2. Filos. Ato de separar mentalmente um ou mais
elementos de uma totalidade complexa (coisa, representação,
fato), os quais só mentalmente podem subsistir fora dessa
totalidade, etc..
Se formos transpor isso para nosso “Mundo Programático”, ficaremos

com: Abstração é a prática de nos concentrarmos somente nos detalhes
mais importantes de um objeto. Possibilitando o descarte de aspectos
menos importantes para a funcionalidade do mesmo.
Em OO, se uma classe contiver apenas as informações necessárias, é
muito provável que ela seja reutilizada com facilidade e uma das maiores
vantagens de POO é a reutilização de código.
34
HERANÇA
Herança é um mecanismo único da OO que permite que características

comuns a diversas classes sejam generalizadas em uma CLASSE
BASE ou SUPERCLASSE. A partir desse classe base, outras classes
podem ser derivadas. Cada classe derivada ou subclasse apresenta as
características da classe base, possibilitando não só o acréscimo de
particularidades, mas também a alteração (quando possível) da
estrutura que herdou.
35
POLIMORFISMO
Consultando novamente o dicionário, encontramos:
Polimorfismo (poli+morfo+ismo). 1.Propriedade do que é

Polimorfo. 2. Existência de uma espécie sob várias formas,
como as abelhas e as formigas.
Novamente, transpondo para nosso “Mundo Programático” ficaremos

com: Polimorfismo é o comportamento diferenciado de uma operação
dependendo do objeto que a está executando.
36
ATRIBUTOS
São os dados de uma classe. As características que formam as

estruturas da classe. É através dos atributos que os valores que
personalizam uma classe são armazenados e podem ser
modificados/acessados.
Exemplos:
Classe Atributos
Pessoa Nome, Peso, Altura
Carro Cor, Modelo, Ano
37
MÉTODOS
Também conhecidos como procedimentos ou funções, são as

ações/operações que a classe executa. Eles podem receber
parâmetros, retornar valores etc.
Exemplos:
Classe Métodos
Pessoa Andar, Falar, Respirar
Carro Acelerar, Abrirporta, Ligarradio
Os parâmetros dos métodos permitem a passagem de valores a eles

para que sejam trabalhados, em outras palavras, aplique-se a lógica de
negócio que justifique a existência do método.
CAMARA, Fábio. Orientação a Objeto com .NET-2ª Edição

38
MODELAGEM
DE
DADOS
39
40
Por que fazer a modelagem?
“A Modelagem captura as partes essenciais do sistema.”

(Rumbaugh)
Com a modelagem, alcançamos alguns objetivos:
1 -Os modelos ajudam a visualizar o sistema como ele é ou como

desejamos que seja;
2 -Os modelos permitem especificar a estrutura ou o comportamento de
um sistema;
3 -Os modelos proporcionam um guia para a construção do sistema;
4 -Os modelos documenta o sistema;
41
O QUE É MODELAGEM VISUAL?
Modelagem Visual significa modelar com a utilização de notações

padrão. Precisamos adotar uma ferramenta, uma notação e linguagem
para tal empreitada.
UML (Linguagem de Modelagem Unificada) é a linguagem de
modelagem é das mais populares do momento.
42
43
O QUÊ É A UML?
A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão

para elaboração da estrutura de projetos de software. A UML poderá ser
usada para:
•Visualização
•Especificação
•Construção de modelos e diagramas
•Documentação.
A UML é adequada para a modelagem de sistemas, cuja a abrangência
poderá incluir sistemas de informação corporativos a serem distribuídos a
Aplicação baseadas em Web e até sistemas complexos embutidos de
tempo real. A UML é apenas uma linguagem e, portanto, é somente uma
parte de um método para desenvolvimento de software. Ela é
independente do processo, apesar de ser perfeitamente utilizada em
processo orientado a casos de usos, centrado na arquitetura, iterativo e
incremental.
44
Histórico
• Os principais métodos utilizados eram os de Booch, Rumbaugh(OMT)

e Jacobson(Objectory).
• Outros métodos importantes são o de Coad-Yourdon, Shlaer-Mellor e
o método Fusão.
45
Histórico
• Grady Booch
– Um dos pioneiros da OO
– 1980: ênfase em técnicas de projeto
para Ada
– 1992-1994: livros
• Object-Oriented Design with Applications
– projeto de programas em C++ e Ada
1994: Object-Oriented Analysis and Design with Applications
• texto sobre conceitos de OO e modelagem de objetos
• projeto de várias aplicações-exemplo com diferentes linguagens da
época
– 1998: Fundação da Rational
46
Histórico
• Ivar Jacobson
– Modelagem OO baseado em Casos de Uso
– Objectory
47
Histórico
• James Rumbaugh
– Object Modeling Technique (OMT)
– Desenvolvida na GE
– Metodologia baseada em notações pré-existentes (ER, DTE, DFD)
– Clara distinção entre as três visões do problema
48
Histórico
• Em 1994, Rumbaugh e Booch decidiram terminar a “guerra” de

métodos e se uniram visando criar um único método de
desenvolvimento de software;
• A idéia era criar um “Método Unificado” que incorporasse as melhores
características dos métodos existentes e resolvesse os problemas de
cada um dos métodos;
• Em 1996, Jacobson se uniu e decidiu-se criar uma linguagem de
modelagem unificada.
49
50
UML é uma linguagem destinada a:
• Visualizar
• Especificar
• Construir
• Documentar artefatos de software.
Tem sido aplicada de maneira efetiva em:
• Sistemas de informações corporativos

• Serviços bancários e financeiros
• Telecomunicações
• Defesa/Espaço aéreo
51
52
A VISÃO DO CASO DE USO descreve o comportamento do sistema
na visão do usuário final, dos analistas e do pessoal de teste. Ela
abrange um pouco de cada visão, tentando demonstrar as interações
do sistema com os meios externos. Os diagramas utilizados nessa
visão são diagramas de caso de uso e diagramas de atividades,
ambos para a modelagem comportamental.
A VISÃO DE PROJETO é uma visão lógica do sistema e é a visão de
maior interesse para os analistas e projetistas. Ela abrange as classes,
interface e colaborações do sistema, formando o vocabulário do
problema e de sua solução.
Está relacionada na UML com os diagramas de classes para a
modelagem estrutural, diagramas de colaboração para a modelagem
comportamental e diagramas de estados para a modelagem estrutural.
53
A VISÃO DO PROCESSO abrange todos os processos que tornam
funcional o sistema de software, cuida do comportamento, do
desempenho e da escalabilidade do sistema. Utiliza os diagramas de
objetos para a modelagem estrutural e diagramas de sequência para a
modelagem comportamental.
A VISÃO DA IMPLEMENTAÇÃO abrange gerenciamento de versões,
gerenciamento de disco e arquivos para se obter um fornecimento do
sistema físico do software, ou seja, um sistema final executável. Utiliza
diagramas de componentes para a modelagem estrutural.
A VISÃO DA IMPLANTAÇÃO consiste na instalação e distribuição do
sistema de software, tornando um sistema de software acessível ao
usuário final. Utiliza diagramas de execução para a modelagem
estrutural.
54
POR QUE TANTOS DIAGRAMAS?
O objetivo disso é fornecer múltiplas visões do sistema a ser modelado,

analisando-o e modelando-o sob diversos aspectos, procurando-se
assim atingir a completitude da modelagem, permitindo que cada
diagrama complemente os outros. Cada diagrama da UML analisa o
sistema, ou parte dele, sob uma determina ótica; é como se o sistema
fosse modelado em camadas. Alguns diagramas enfocam o sistema de
forma mais geral, apresentando uma visão externa do sistema, como é
o objetivo do Diagrama de Casos de Uso, ao passo que outros
oferecem uma visão de uma camada mais profunda do software,
apresentando um enfoque mais técnico ou ainda visualizando apenas
uma característica específica do sistema ou um determinado processo.
55
Diagramas
A UML modela um sistema e sua interação com o usuário através de

diagramas padronizados. São treze diagramas, entre eles, diagrama de
caso de uso (Use Case), diagrama de classes, diagrama de sequência
e diagrama de atividades.
Estes são os mais utilizados e os utilizaremos em nosso projeto,
considerando a complexidade média do domínio do problema em
estudo.
Os diagramas UML esboçam todas as visões de um projeto de sistema
de software, possuindo diagramas estruturais, comportamentais e de
modelos de gerenciamento especificados a seguir.
56
A utilização de diversos diagramas permite que falhas possam ser
descobertas nos diagramas anteriores, diminuindo a possibilidade da
ocorrência de erros durante a fase de desenvolvimento do software.
É importante destacar que, embora cada diagrama tenha sua utilidade,
nem sempre é necessário modelar um sistema utilizando-se de todos
os diagramas, pois alguns deles possuem funções muito específicas,
como é o caso do Diagrama de Tempo, por exemplo.
57
DIAGRAMA DE CASOS DE USO
Este é o diagrama mais geral e informal da UML, sendo utilizado

principalmente para auxiliar no levantamento e análise dos requisitos,
em que são determinadas as necessidades do usuário, e na
compreensão do sistema como um todo, embora venha a ser
consultado durante todo o processo de modelagem e sirva de base
para todos os outros diagramas.
O Diagrama de Casos de Uso apresenta uma linguagem simples e de
fácil compreensão para que os usuários possam ter uma idéia geral de
como o sistema irá se comportar. Ele procura identificar os atores
(usuários, outros softwares que interajam com o sistema ou até
mesmo algum hardware especial), que utilizarão de alguma forma o
software, bem como os serviços, ou seja, as opções que o sistema
disponibilizará aos atores, conhecidas neste diagrama como Casos de
Uso.
58
COSTA, Carlos Alberto. Gestão & Produção – Aplicação da Linguagem de Modelagem Unificada (UML) para o
suporte ao projeto de sistemas computacionais dentro de um modelo de referência. Departamento de Engenharia
Mecânica Universidade de Caxias do Sul (UCS)
59
DIAGRAMA DE CLASSES
Este é o diagrama mais utilizado e o mais importante da UML, servindo

de apoio para a maioria dos outros diagramas. Como o próprio nome
diz, esse diagrama define a estrutura das classes utilizadas pelo
sistema, determinando os atributos e métodos possuídos por cada
classe, além de estabelecer como as classes se relacionam e trocam
informações entre si.
60
61
62
DIAGRAMA DE SEQÜÊNCIA
O Diagrama de Seqüência preocupa-se com a ordem temporal em que

as mensagens são trocadas entre os objetos envolvidos em um
determinado processo. Em geral, baseia-se em um Caso de Uso
definido pelo diagrama de mesmo nome e apóia-se no Diagrama de
Classes para determinar os objetos das classes envolvidas em um
processo, bem como os métodos disparados entre os mesmos. Um
Diagrama de Seqüência costuma identificar o evento gerador do
processo modelado, bem como o ator responsável por este evento, e
determina como o processo deve se desenrolar e ser concluído por
meio do envio de mensagens, que em geral disparam métodos entre os
objetos.
63
64
DIAGRAMA DE COMUNICAÇÃO
O Diagrama de Comunicação era conhecido como Diagrama de

Colaboração até a versão 1.5 da UML, tendo seu nome modificado para
Diagrama de Comunicação a partir da versão 2.0. Esse diagrama está
amplamente associado ao Diagrama de Seqüência; na verdade, um
complementa o outro. As informações mostradas no Diagrama de
Comunicação são, com freqüência, praticamente as mesmas
apresentadas no Diagrama de Seqüência, porém com um enfoque
diferente, visto que este diagrama não se preocupa com a temporalidade
do processo, concentrando-se em como os objetos estão vinculados e
quais mensagens trocam entre si durante o processo.
65
66
DIAGRAMA DE MÁQUINA DE ESTADOS
O Diagrama de Máquina de Estados era conhecido nas versões

anteriores da linguagem como Diagrama de Gráfico de Estados ou
simplesmente como Diagrama de Estados, tendo assumido nova
nomenclatura a partir da versão 2. Esse diagrama procura acompanhar
as mudanças sofridas nos estados de uma instância de uma classe, de
um Caso de Uso ou mesmo de um subsistema ou sistema completo.
Como o Diagrama de Seqüência, o Diagrama de Máquina de Estados
muitas vezes se baseia em um Caso de Uso e se apóia no Diagrama
de Classes.
67
68
DIAGRAMA DE ATIVIDADE
O Diagrama de Atividade era considerado um caso especial do antigo

Diagrama de Gráfico de Estados, mas, a partir da UML 2.0, esse
diagrama se tornou independente, deixando inclusive de se basear em
máquinas de estados e passando a se basear em Redes de Petri. O
Diagrama de Atividade se preocupa em descrever os passos a serem
percorridos para a conclusão de uma atividade específica, muitas
vezes representada por um método com um certo grau de
complexidade, podendo, no entanto, modelar um processo completo.
Concentra-se na representação do fluxo de controle e no fluxo de
objeto de uma atividade.
69
70
71
USE CASE
Objetivo: Descrever um modelo funcional do sistema. Procura

identificar os usuários e representar o sistema segundo a sua visão.
[Deboni 2003].
Deve estabelecer um modelo de requisitos do sistema através da

identificação de como o mesmo será utilizado pelos elementos
externos e quais serviços deve prover.
72
73
Cenário: Encomendas de Placas
João confecciona placas por encomenda. Como o volume dos pedidos
tem aumentado, ele pediu ao filho que lhe fizesse uma pequena
aplicação que controle:
− O cadastro de seus clientes
− As encomendas
Quando ele recebe uma encomenda, João anota num caderninho o nome
do cliente e seu telefone.
Para a encomenda, ele registra: o tamanho da placa (altura e largura), a
frase a ser escrita, a cor da placa (branca ou cinza), cor da frase (azul,
vermelho, amarelo, preto ou verde), data da entrega, valor do serviço e
valor do sinal.
74
A aplicação deve obrigar que o valor do sinal seja de no mínimo 50%.
Para calcular o valor da placa as seguintes fórmulas são usadas:
Área = altura X largura
Custo_material = área X R$ 147,30
Custo_desenho=número_letras x R$ 0,32
Valor_placa = custo_material + custo_desenho
Para calcular o prazo de entrega, considera-se que ele só consegue produzir seis
placas por dia.
João deseja que o sistema controle os pedidos, calcule o preço final das peças e
o prazo de entrega. Para cada encomenda cadastrada deve ser emitido um recibo
em duas vias (cliente e empresa), contendo todos os dados da encomenda e do
pagamento.
75
76
77
78
79
80
81
ELEMENTOS DE UM DIAGRAMA UC
Este diagrama utiliza três elementos básicos para a sua construção:
ATOR
• Um ator é alguém ou alguma coisa que interage com o sistema; é
quem ou o que usa o sistema.
• O ator representa um papel, não um usuário individual do sistema.
• Atores podem ser humanos ou sistemas automatizados.
• O ator comunica-se com o sistema enviando e recebendo
mensagens.
• Atores recebem nomes que refletem o papel que desempenham no
sistema.
• Representação gráfica do ator:
nome do ator
82
Atores - Exemplos
•Em um Consultório Médico Médico Atendente
•Em uma Biblioteca
Bibliotecário Usuário
83
CASO DE USO
• Um caso de uso representa uma funcionalidade completa do

sistema, conforme percebida por um ator.
• É um conjunto de seqüências de ações que um sistema executa,
gerando um resultado observável que interessa a determinado ator.
• A idéia é que os casos de uso representem, por meio de pequenas
histórias descritivas, as funcionalidades de um sistema.
• Modela o diálogo entre o ator e o sistema.
• São as funções que o sistema vai desempenhar.
84
CASO DE USO
• Os Casos de Uso representam as funções do sistema, ou seja, os

requisitos do sistema sob o ponto de vista do usuário
• Eles mostram as funcionalidades que serão utilizadas pelos usuários
• O foco do Caso de Uso está em O QUE o sistema faz e não COMO
o sistema faz
85
Representação gráfica do Caso de Uso
Nome do Caso
de Uso
Nome do Caso de
Uso
86
Exemplo: Sistema Telefônico
Realizar
Chamada
Usuário
Manter
Agenda
87
Para identificar os Casos de Uso respondemos algumas perguntas como:
 “Qual é a expectativa do usuário ao usar o sistema, ou seja, o que
ele precisa fazer com o sistema?”

 “ Quais resultados de valor o usuário espera receber do sistema?”
Exemplos:
 Efetuar Depósito
Está é uma lógica oculta
 Solicitar Extrato com a qual o usuário final
 Efetuar Transferência não se preocupa, portanto
não é qualificada com um
 Efetuar Saque Caso de Uso
 Validar Saldo
88
Casos de Uso do tipo CRUD (Create, Read, Update, Delete) por terem
comportamentos muito semelhantes geralmente são combinados em em caso
de uso que ofereça todos os recursos de manutenção.
UC Incluir Usuário
UC Manter Usuário = UC Alterar Usuário

UC Excluir Usuário
UC Pesquisar Usuário
Fazendo uma analogia:

UC Abrir conta corrente
UC Manter
Conta Corrente
= UC Encerrar conta corrente
UC Alterar conta corrente
UC Consultar conta corrente
89
ESPECIFICAÇÃO DE UM CASO DE USO
Informações Básicas
• Número do Caso de Uso
• Nome do Caso de Uso
• Descrição
• Pré-condições
• Pós-condições
• Ator Principal
• Fluxo de Eventos
• Fluxos Alternativos
• Fluxos de Exceção
• Cenários
• Views (Telas, Relatórios, etc)
• Regras de Negócio
90
Descrição:
– Descrever a função e o resultado observável do Caso de
Uso.
Orientações:
– Escreva pouco
– Especifique com exatidão o resultado observável
Sugestão: “Este Caso de Uso serve para ...”
Exemplos: Este caso de uso serve para realizar um saque em
Conta Corrente com cartão de débito.
91
Pré-condições:
– Condições que precisam ser verdadeiras para que o Caso de
Uso possa iniciar
Orientações:
– Uma pré-condição não satisfeita impede o início do Caso de
Uso .
– Uma pré-condição pode ser um outro Caso de Uso
executado.
– Nem todos os Casos de Uso têm pré-condições.
Sugestão: “Este Caso de Uso pode iniciar somente se ...”
Exemplos: Este use case pode iniciar somente se:
– O Cliente tiver perfil disponível para transação Saque em
Conta Corrente.
– Tela do Caixa Automático estiver disponível.
92
Pós-condições:
– Situação após a execução do Caso de Uso
Orientações:
– As pós-condições são condições que devem sempre ser
verdadeiras após o término da execução do Caso de Uso.
– Uma pós-condição não satisfeita impede o fim normal do
Caso de Uso.
– Assim como as pré-condições, as pós-condições podem ser
usadas para adicionar informações sobre a ordem em que os
Casos de Uso são executados.
Sugestão: “Após o fim normal deste Caso de Uso ... deve ...”
Exemplos: Após o fim normal deste Caso de Uso, o sistema deve:
• ter feito o débito na Conta Corrente do Cliente.
• ter acionado o UC Contabilidade de Caixa.
• ter impresso o Comprovante do Saque em C/C.
• ter disponibilizado informações para Extrato C/C.
93
Ator:
– O Ator não faz parte do sistema, ele é quem solicita uma ação
ao sistema (ou recebe uma resposta do sistema), ou seja, é
quem interage com o sistema.
Tipos de ator:
– Humano: um cliente de um banco sacando dinheiro.
– Sistema: o Sistema de Ações é o Ator quando aciona o Sistema
de Contas Correntes para depositar os dividendos da carteira de
ações do cliente.
– Tempo: no início do mês o Sistema de Contas Correntes
imprime os extratos do mês anterior para enviar ao cliente
através do Correio.
94
Fluxo de Eventos Principal :
– Descrever a seqüência de ações que devem ser executadas
para que o Caso de Uso execute sua função.
Orientações:
– Descrição passo a passo do fluxo normal, ou “caminho feliz”,
sob o ponto de vista do Ator
– Especifica como o Sistema será usado e não como será
implementado
– Deve ser caracterizado por frases simples, em que o
sujeito é o Ator ou o Sistema
– Não deve ter desvios para outros passos do Fluxo de
Eventos
95
Fluxos de Eventos Alternativos
– No Fluxo de Eventos Principal, caso ocorra alguma
condição em algum dos passos, deve-se executar um Fluxo
Alternativo para aquele passo.
Orientações:
– Um Fluxo Alternativo pode conter outros Fluxos Alternativos
e pode retornar para o fluxo principal
96
Fluxos de Exceção
 Descrevem os procedimentos que devem ser adotados no caso
de erros durante os fluxos principal e alternativos.
97
Cenários:
 São exemplos específicos de fluxos de um Caso de Uso.
São úteis para validar os fluxos.
Exemplos:
 Cenário 1: Saldo da conta igual a R$ 1000,00 e
cliente tenta sacar R$ 2.000,00
 Cenário 2: Saldo da conta igual a R$ 1000,00 e
cliente saca um valor menor que o saldo, com
sucesso
98
MODELAGEM
DE
DADOS
99
EXEMPLO: LOJA DE CDS
Identificando os atores
– Uma loja de CDs possui discos para venda. Um cliente pode

comprar uma quantidade ilimitada de discos para isto ele deve se
dirigir à loja. A loja possui um atendente cuja função é atender os
clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao atendente, ou seja, ele
também atende os clientes durante a venda dos discos.
100
IDENTIFICANDO OS ATORES
E o cliente ?
– Não é ator pois ele não interage com o sistema!
101
ELEMENTOS DO DIAGRAMA
Atores
– Casos de uso
– Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
– Fronteira do sistema
Caso de Uso
– Representa uma funcionalidade do sistema (um requisito funcional)

– É iniciado por um ator ou por outro caso de uso
Dicas:
Nomeie os casos de uso iniciando por um verbo
102
Identificando os casos de uso
– Uma loja de CDs possui discos para venda. Um cliente pode comprar
uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A
loja possui um atendente cuja função é atender os clientes durante a
venda dos discos. A loja também possui um gerente cuja função é
administrar o estoque para que não faltem discos. Além disso é ele
quem dá folga ao atendente, ou seja, ele também atende os clientes
durante a venda dos discos.
103
Relacionamentos
• Associação
• Generalização
Dicas:
NÃO use setas nas associações;
Associações NÃO representam fluxo de informação;
104
Identificando os relacionamentos de associação
– Uma loja de CDs possui discos para venda. Um cliente pode

comprar uma quantidade ilimitada de discos para isto ele deve se
dirigir à loja. A loja possui um atendente cuja função é atender os
clientes durante a venda dos discos. A loja também possui um
gerente cuja função é administrar o estoque para que não faltem
discos. Além disso é ele quem dá folga ao atendente, ou seja, ele
também atende os clientes durante a venda dos discos.
105
Identificando os relacionamentos de associação
106
Relacionamentos
• Associação
• Generalização
Relacionamento de generalização
Generalização de atores
– Quando dois ou mais atores podem se comunicar com o mesmo
conjunto de casos de uso;
– Um filho (herdeiro) pode se comunicar com todos os casos de uso
que seu pai se comunica.
Dica: coloque os herdeiros embaixo
107
IDENTIFICANDO GENERALIZAÇÃO DE ATORES
108
Relacionamento de generalização
Generalização de casos de uso
– O caso de uso filho herda o comportamento e o significado do caso

de uso pai;
– O caso de uso filho pode incluir ou sobrescrever o comportamento do
caso de uso pai;
– O caso de uso filho pode substituir o caso de uso pai em qualquer
lugar que ele apareça;
Dica: deve ser aplicada quando uma condição resulta na definição de

diversos fluxos alternativos.
109
Identificando generalização de casos de uso
Novos requisitos:
– As vendas podem ser à vista ou a prazo. Em ambos os casos o
estoque é atualizado e uma nota fiscal, entregue ao consumidor.
• No caso de uma venda à vista, clientes cadastrados na loja e que
compram mais de 5 CDs de uma só vez ganham um desconto de 1%
para cada ano de cadastro.
• No caso de uma venda a prazo, ela pode ser parcelada em 2
pagamentos com um acréscimo de 20%. As vendas a prazo podem ser
pagas no cartão ou no boleto. Para pagamento com boleto, são gerados
boletos bancários que são entregues ao cliente e armazenados no
sistema para lançamento posterior no caixa. Para pagamento com
cartão, os clientes com mais de 10 anos de cadastro na loja ganham o
mesmo desconto das compras a vista.
110
IDENTIFICANDO GENERALIZAÇÃO DE CASOS DE USO
111
Identificando mais generalização de casos de uso
Novos requisitos:
– As vendas podem ser à vista ou a prazo. Em ambos os casos o
estoque é atualizado e uma nota fiscal, entregue ao consumidor.
• No caso de uma venda à vista, clientes cadastrados na loja e que
• No caso de uma venda a prazo, ela pode ser parcelada em 2
pagamentos com um acréscimo de 20%. As vendas a prazo podem ser
pagas no cartão ou no boleto . Para pagamento com boleto, são
gerados boletos bancários que são entregues ao cliente e
armazenados no sistema para lançamento posterior no caixa. Para
pagamento com cartão, os clientes com mais de 10 anos de cadastro
na loja ganham o mesmo desconto das compras a vista.
112
IDENTIFICANDO GENERALIZAÇÃO DE CASOS DE USO
113
Relacionamentos
• Associação
• Generalização
Relacionamento de dependência:
Extensão:
– Representa uma variação/extensão do comportamento do caso de
uso base;
– O caso de uso estendido só é executado sob certas circunstâncias
– Separa partes obrigatórias de partes opcionais
• Partes obrigatórias: caso de uso base
• Partes opcionais: caso de uso estendido
– Fatorar comportamentos variantes do sistema (podendo reusar este
comportamento em outros casos de uso)
Notação: <<extends>>
114
Identificando dependência: extensão
Novos requisitos:
– No caso de uma venda à vista, clientes cadastrados na loja e que

– No caso de uma venda a prazo...
...Para pagamento com cartão, os clientes com mais de 10 anos de
cadastro na loja ganham o mesmo desconto das compras à vista.
115
IDENTIFICANDO DEPENDÊNCIA: EXTENSÃO
116
Relacionamento de dependência:
Inclusão:
– Evita repetição ao fatorar uma atividade comum a dois ou mais casos

de uso;
– Um caso de uso pode incluir vários casos de uso;
Notação: <<includes>>
Identificando dependência: inclusão
Novos requisitos:
– Para efetuar vendas ou administrar estoque, atendentes e gerentes

terão que validar suas respectivas senhas de acesso ao sistema.
117
IDENTIFICANDO DEPENDÊNCIA: INCLUSÃO
118
FRONTEIRA DO SISTEMA
Fronteira do Sistema
– Elemento opcional (mas essencial para um bom entendimento)
– Serve para definir a área de atuação do sistema
IDENTIFICANDO A FRONTEIRA DO SISTEMA
119
MODELAGEM
DE
DADOS
120
SISTEMA ATUAL
1.1. Um grupo de pesquisa em culinária vegetariana discute, troca

informações e desenvolve receitas de forma colaborativa.
1.2. Os trabalhos do grupo são desenvolvidos a partir da distribuição,
troca e aplicação sistemática de receitas, bem como a disseminação de
ajustes e experiências com variações aplicadas.
1.3. O grupo é fechado, ou seja, o acesso é restrito e as informações
trocadas entre os membros permanecem entre estes.
1.4. Membros estão dispersos geograficamente em diferentes países.
1.5. Toda a comunicação (troca de receitas e experiências) é feita
através de mensagens.
1.6. Existe um web site que contém receitas prontas. Porém, não existe
nenhum mecanismo que garante que receitas prontas estão ou serão
publicadas neste site.
1.7. A forma atual de formatação das receitas consiste em um texto
acrescido de uma imagem.
1.8. O idioma padrão adotado é o Inglês.
121
122
MODELAGEM
DE
DADOS
123
CLASSES
Uma classe descreve as propriedades e os comportamentos de certo

tipo de objetos. A partir da classe, o sistema criará objetos concretos
(ditos instâncias da classe), com tais propriedades e tais
comportamentos.
O grafismo exato (como cantos arredondados ou em ângulo reto…) e
a quantidade de detalhes são variáveis. Por exemplo, poderiam não
estar indicados os tipos de dados dos atributos.
Nesta representação exemplificativa os atributos e as operações
também têm indicação do seu nível de acesso, sendo todos prefixados
por «+», por serem todos «públicos», o que significa que estão todos
permanentemente acessíveis a qualquer classe.
O nível de acesso «privado» tem o prefixo «-» e corresponde às
situações em que o acesso só é permitido dentro da própria classe.
O prefixo «#» usa-se quando os membros são «protegidos»; isto é,
acessíveis apenas na sua própria classe e nas classes herdeiras.
124
DIAGRAMA DE CLASSES
Reúne os elementos mais importantes de um sistema orientado a objetos

Exibe um conjunto de classes, interfaces e seus relacionamentos
As classes especificam tanto as propriedades quanto o comportamento
dos objetos
ATRIBUTOS
Um atributo representa alguma propriedade que é compartilhada por

todos os objetos de uma classe.
Descrevem os dados contidos nas instâncias de uma classe n Sintaxe
[visibilidade] nome [:tipo][= valor inicial]
125
SINTAXE DE ATRIBUTOS
Visibilidade
público (+)
O atributo é acessível a qualquer outro objeto ou classe
protegido (#)
O atributo é acessível apenas nas subclasses
privado (-)
O atributo só é acessível dentro da classe onde foi definido
ATRIBUTOS
126
OPERAÇÕES (MÉTODOS)
Uma operação é um serviço que pode ser requisitado a qualquer

objeto ou classe, possivelmente afetando o seu estado n A execução
de uma operação de um objeto.
altera valor de seus atributos
retorna informações sobre o objeto
SINTAXE PARA OPERAÇÕES
Sintaxe
¨ [visibilidade] nome [(lista-deparâmetros)][:tipo-de-retorno]
127
OPERAÇÕES
128
RELACIONAMENTOS
Poucas classes têm sentido sozinhas!

Relacionamentos ligam classes entre si criando relações lógicas
Os relacionamentos podem ser dos seguintes tipos:
Associação
Generalização
Agregação
Composição
ASSOCIAÇÃO
É um relacionamento estrutural que especifica que objetos de um
elemento estão conectados a objetos de outro elemento.
129
MULTIPLICIDADE
É a cardinalidade de uma
associação;
É colocada em cada lado da
associação;
130
NAVEGABILIDADE
A navegação entre as classes de uma associação é bi-direcional.

Porém, podemos limitá-la a apenas uma direção
Significa uma forma de mostrar acesso direto a objetos
131
GENERALIZAÇÃO
Uma classe pode ser uma especialização da outra, ou seja, possui

todas as propriedades e comportamento da outra e alguma coisa mais;
Classe mais geral - “superclasse”
Classes específicas - “subclasses”
Quando os fatos acima acontecem há uma relação de generalização
ou herança
Generalização: relacionamento do tipo “é-um” ou “herda”
132
EXEMPLO DE GENERALIZAÇÃO
133
RELACIONAMENTO ENTRE CLASSES
Agregação
tipo de associação (é parte de) onde o objeto parte é um atributo do
todo
Uma calculadora agrega multiplicadores e somadores
A agregação é um relacionamento entre duas classes e que estabelece

que uma instância de uma classe agrupa uma ou mais instâncias da
outra. Dá a idéia de que um objeto, para estar completo, isto é, para
estar apto a desempenhar seu papel no programa, deve estar
associado a um ou mais objetos. Também é chamada de
relacionamento todo/parte.
A agregação é uma relação unidirecional onde cada uma das duas
classes envolvidas assume um papel específico. A classe que “possui”
instâncias de outra classe é chamada de agregado e a classe que tem
instâncias “possuídas”, parte.
134
RELACIONAMENTO ENTRE CLASSES
Composição
•Agregação mais forte. Implica que o “todo” é responsável pela criação

da “parte” e que esta não vive sem o “todo”
•A composição é mais física, uma parte não pode pertencer a dois
objetos compostos ao mesmo tempo
•um motor não pode pertencer a dois carros ao mesmo tempo
•uma casa e suas paredes
•Implica uma forma de propagação de algumas propriedades
•Quando o objeto composto morrer, as partes morrem também.
Quando um carro se mover, as partes se movem também.
•Essa propagação não é a herança, não é automática, tem-se que
especificá-la e implementá-la.
135
OBSERVAÇÕES
A diferença entre agregação e composição não é sempre clara!

Em caso de dúvidas, é melhor usar a agregação que é menos restrita,
ou até uma associação simples.
136
EXEMPLO DE CASO EM UML
Desenvolvimento de Modelagem em UML para Sistema de

Manutenção e Controle de Contas Correntes e Aplicações
Financeiras.
Abaixo algumas considerações sobre o que o sistema se propõe a
fazer e outras observações que consideramos de suma importância
para o bom entendimento do problema:
•O sistema suportará um cadastro de clientes, onde cada cliente

cadastrado poderá ter várias contas correntes, vários dependentes
ligados a ele, e várias contas de poupança.
•Cada dependente poderá possuir várias contas de poupança, mas
não poderão ter uma conta corrente própria.
•Poupança seria uma conta que possui um valor, um prazo de
aplicação a uma taxa de juros (definida no vencimento da poupança).
137
•Aplicações Pré-fixadas seria uma aplicação de um valor, em um prazo pré-
determinado a uma taxa de juros previamente definida.
•Tanto a conta corrente quanto a poupança deverão manter um histórico de
todas as movimentações de crédito, débito, transferências e aplicações de
pré-fixados (pré-fixados apenas para conta corrente).
•A conta corrente poderá ter várias aplicações pré-fixadas ligadas a ela.
138
•Análise de Requisitos
O sistema implementará funções básicas que serão desempenhadas
pela Administração do banco e pelos seus clientes. As principais
funções do sistema são:
•Cadastrar novo cliente
•Excluir ou editar cliente
•Cadastrar dependente
•Excluir ou editar dependente
•Abrir e Fechar conta corrente
•Abrir e Fechar poupança
•Movimentar conta corrente
•Aplicar em pré-fixados
•Consultar histórico de conta corrente ou poupança
•Cadastrar Agência
•Excluir ou Editar Agência
139
140
Análise
Nesta fase, com o diagrama de use-case, podemos definir o diagrama

de classes do sistema. Neste primeiro diagrama da fase de análise,
métodos e atributos de acesso a banco de dados, estrutura de
mensagens entre objetos e etc. não deverão aparecer, apenas os tipos
de objetos básicos do sistema. Existirão 8 classes no sistema e que se
relacionarão segundo o diagrama de classes a seguir.
141
142
A seguir, iremos traçar como estas classes irão interagir para realizar
as funções do sistema. Para modelarmos como os objetos do sistema
irão interagir entre si, utilizamos o diagrama de seqüência ou o de
colaboração. E modelaremos um diagrama para cada função (use-
case) definida no diagrama de use-cases. Escolhemos o diagrama de
seqüência para dar mais ênfase a ordem cronológica das interações
entre os objetos. Já se faz necessário utilizar idéias básicas da
modelagem da interface do sistema como as janelas.
143
144
CENÁRIO: RÁDIO TÁXI MAR & SOL
A empresa de Rádio Táxi Mar & Sol precisa de uma aplicação que
controle:
- o cadastro de seus clientes
- o cadastro dos cooperados
- o cadastro das corridas programadas
Para cada cliente são cadastrados os seguintes dados: código (que
deve ser gerado pelo sistema), nome, endereço completo (logradouro,
número, complemento, bairro, município, estado) e dois telefones de
contato. O cliente pode se cadastrar apenas com o nome para
agilizar o processo. Quando fizer sua primeira chamada por
telefone, seus dados serão atualizados. Para o cooperado (taxista)
cadastram-se: nome, CPF, número da carteira de motorista, categoria,
data de validade da carteira, número do táxi na cooperativa (conhecido
como número de VR), número da placa, modelo do veiculo, fabricante,
cor do veículo, endereço residencial completo, telefone residencial e
celular e data de entrada na Cooperativa. Quando o cooperado se
desliga, deve ser cadastrada a data de desligamento.
145
Quando o cliente solicitar uma corrida programada (pedidos com

antecedência maior do que meia hora), cadastra-se no controle de
corridas: o endereço de saída do carro, o bairro de destino, a data e
hora de saída, telefone de contato (se local de saída diferente do
cadastro). Se o cliente não for cadastrado, seu cadastro deve ser feito
no momento da solicitação do carro. O status dessa corrida deve ser
definido como: "aguardando VR".
Uma hora antes da corrida programada, a operadora questiona, pelo
rádio, aos cooperados que estejam em trânsito, qual deseja pegar a
corrida programada.
146
Deve ser cadastrado na aplicação o número da VR do taxista

que se candidatou à corrida. Meia hora antes do horário, o cliente deve
ser avisado a respeito do número da VR. Antes de avisar ao cliente, o
status deve ser assinalado como: "aguardando aviso". Após o aviso, o
status muda para "aviso efetuado". Após ser atendido, o status deve
ser alterado para: "tripulado". Em qualquer momento a corrida pode ser
cancelada pelo passageiro.
Se for uma solicitação de carro imediato, a operadora deve retomar ã
tela, informando o status dentre as opções: "aguardando aviso", "aviso
efetuado", "cancelado pelo passageiro" ou "cancelado pela cooperativa
por falta de carro". Se um logradouro não estiver na lista, a solicitação
não será atendida.
Quando o cliente for atendido, o status deve ser alterado para:
"tripulado“.
147
EXERCÍCIO:
A partir do cenário descrito, desenhe o diagrama de casos de uso.

Considere que: o cadastramento das corridas e dos clientes é feito pela
Operadora da Central; o cadastramento dos cooperados é feito por
qualquer funcionário da Área Administrativa; e o controle mensal de
pagamentos de diárias é feito pela Área Financeira.
EXERCÍCIO A:
A partir do cenário descrito identifique as classes, com seus

atributos e métodos.
EXERCÍCIO B:
Utilizando apenas o nome das classes, desenhe o relacionamento

entre as classes.
148
149
150
CENÁRIO: CONTROLE DE OBRA
Álvaro está fazendo uma ampliação de sua residência. Todo dia existe
demanda de compra de material. Sendo assim, ele desenvolveu uma
pequena aplicação que controla essa demanda de solicitações e as
compras efetuadas, de forma a montar uma base de cotações para as
compras futuras.
A aplicação possui um cadastro de produtos, contendo: nome,
descrição, medida de venda do produto (kg, ml ou m; indicando peso,
volume ou comprimento) e valor da medida de venda (ex: 1,5).
A cada solicitação de compra cadastram-se os itens dessa solicitação.
Cada item possui: o produto e a quantidade. Quando cada item é
adquirido, atualiza-se a solicitação com o preço unitário de, compra, a
forma de pagamento (dinheiro, cheque, cheque pré ou cartão), a data
de compra e o local da compra.
151
São controles oferecidos pela aplicação:

Quando há uma nova solicitação, é possível obter de cada item a lista
dos três menores preços que já foram pagos para o referido produto,
incluindo na listagem o local onde foi comprado.
A lista de compras é impressa a partir dos itens que não foram
fechados, de todas as solicitações de compra que estejam com status
em aberto.
Uma solicitação pode ser cancelada {status = "cancelado").
Quando todos os itens de uma solicitação tiverem sido comprados, o
sistema atualiza automaticamente o status dessa solicitação para
"fechado".
Deve ser emitida uma listagem de todos os produtos já comprados,
com seu somatório de quantidade e de valor.
152
EXERCÍCIO:
A partir do cenário descrito, desenhe o diagrama de casos de uso

desse sistema.
Considere que todas as operações são feitas pelo Álvaro, que pode
ser Identificado como Responsável pela Obra.
153
154
CENÁRIO: ESTACIONAMENTO
Bruno e seu pai compraram um terreno e inaugurarão um

estacionamento.
Para ajudar, a irmã de Bruno está desenvolvendo uma aplicação de
controle de estacionamento.
Quando o veículo entra no estacionamento, o atendeníe observa sua
placa e a mesma é cadastrada, juntamente com o modelo do veículo e
sua cor.
A hora de entrada é gerada automaticamente, correspondendo ao
momento do cadastramento da placa. Após estacionar o veículo, o
cliente pega o ticket onde está impresso: o número da placa, o modelo
do veículo, a cor, a data e a hora da entrada.
155
Ao retomar ao estacionamento, o cliente entrega o ticket. O tempo de

permanência é calculado. Considerando esse tempo de permanência,
é aplicada a tabela de preços, sabendo-se que a tabela de sábado não
é a mesma dos dias úteis e, às vezes, dependendo da época do ano,
os donos lançam promoções durante os dias úteis. Veja exemplo das
tabelas de preço:
Segunda á sexta
1a hora = R$2,00
a partir da 2a hora (inteiro ou
fração) = + R$ 1,00
Sábado
Preço único = RS 3,00
Os donos precisam de relatórios de faturamento diário e semanal.
156
157
CENÁRIO: CONTROLE BOLÃO
Jairo trabalha no Departamento de Informática de uma grande empresa.

Ele e seus amigos estão sempre fazendo bolão da Mega Sena, Quina e outros
tipos de jogos. Jairo sempre controla numa planilha Excel os números
apostados, além das pessoas que entraram no bolão, seus e-mails (para
receberem os números apostados) e se pagaram suas cotas. Entretanto, isso
tem lhe tomado um tempo considerável. Sendo assim, ele pensou em
desenvolver uma aplicação que atenda às seguintes funcionalidades:
- permita cadastrar os participantes de cada bolão, com seus ramais e e-mails;
- para cada bolão feito, cadastrar o valor da cota, número de cotas, os cartões
apostados (com sua relação de números), o tipo de jogo (Mega Sena, Quina
etc.), o número do concurso e a data em que será realizado o sorteio;
- controlar quem pagou cada cota;
- gerar automaticamente uma página Web com os dados do sorteio,
participantes do bolão com suas cotas e os números apostados. O arquivo
HTML dessa página será enviada por e-mail;
158
- cada participante poderá adquirir mais de uma cota;

- gerar a lista de participantes que ainda não pagaram;
- a aplicação deve verificar se o total das cotas é igual ao total apostado;
- uma determinada aposta pode ser aproveitada em outros bolões.
Avaliação Formal 1:
A partir do cenário descrito, desenhe o diagrama de casos de uso desse
sistema, escreva, também, os cenários. Considere que todas as operações são
feitas pelo Jaíro, que pode ser identificado como Gestor do Bolão.
A partir do cenário e dos casos de uso descritos, desenhe um modelo de classes
completo, incluindo os atributos, métodos e relacionamentos.
159
160
CENÁRIO: SENHA DE ATENDIMENTO
A empresa Compre Bem implantou uma senha de atendimento para o SAC

de suas lojas. O objetivo é reduzir o tempo de espera na fila.
O atendimento é dividido por assuntos e cada caixa pode cuidar de um ou mais
assuntos, ou um assunto pode ser tratado por um ou mais caixas.
Para cada caixa deve-se saber o número e a posição (direita ou esquerda da
máquina de senhas).
Para cada caixa, deve-se ter um histórico de atendimentos, para se obter
estatística. A estatística deve ser detalhada quanto ao tempo mínimo, médio e
máximo de atendimento por caixa e por dia, além do número de atendimentos
por assunto,
A qualquer momento é preciso saber que caixa está com um determinado
número de atendimento.
161
EXERCÍCIO:
A partir do cenário descrito, desenhe o diagrama de casos de uso desse

sistema. Escreva, também, os cenários. Considere que as tarefas de controlar
os assuntos e os caixas, obter estatística e relatórios são do Setor
Administrativo. O Caixa se responsabiliza por controlar a próxima senha e o
Balcão de Informações é que gera novas senhas.
162
163
164
165
166

Uml 2

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uml 2

Enviado por

Direitos autorais:

Formatos disponíveis

MODELAGEM

É o conjunto de soluções adotado por uma pessoa ou grupo para

Conhecer os conceitos referentes à modelagem: antes de modelar,

Saber que passos seguir: o desenvolvimento de software – e a

Várias alternativas de divisão, com diferentes conjuntos de etapas,

Representa os conceitos do domínio em estudo.

Tem foco nas principais interfaces da arquitetura, nos principais

Aborda vários detalhes de implementação, tais como

Um dos maiores desafios da programação e análise de sistemas em geral

•Ter uma consistente e eficiente análise de requisitos;

POO quando corretamente aplicada em projetos de desenvolvimento de

Fazendo uma analogia elucidativa, vamos usar o exemplo da torneira.

Objetos são instâncias de classes. É através deles que praticamente todo

O instanciamento é o ato de trazer a classe para o mundo real. No

Generalização é o processo responsável pela identificação e definição de

•Generalização é o processo utilizado no agrupamento de classes que

O que é uma receita de bolo?

O que são os ingredientes?

O que é o modo de preparo?

Depois de pronto, como o bolo se “comporta”?

Para uma linguagem de programação ser considerada OO, ela precisa

Para compreensão, os termos “objetos” e “cliente” serão usados para

É a prática de esconder como um objeto executa as suas operações,

Segundo o dicionário Aurélio:

abstração [Do lat. Tard. Abstracione.] S.f. 1. Ato de abstrair(-se);

Se formos transpor isso para nosso “Mundo Programático”, ficaremos

Herança é um mecanismo único da OO que permite que características

Consultando novamente o dicionário, encontramos:

Polimorfismo (poli+morfo+ismo). 1.Propriedade do que é

Novamente, transpondo para nosso “Mundo Programático” ficaremos

São os dados de uma classe. As características que formam as

Também conhecidos como procedimentos ou funções, são as

Os parâmetros dos métodos permitem a passagem de valores a eles

CAMARA, Fábio. Orientação a Objeto com .NET-2ª Edição

“A Modelagem captura as partes essenciais do sistema.”

Com a modelagem, alcançamos alguns objetivos:

1 -Os modelos ajudam a visualizar o sistema como ele é ou como

Modelagem Visual significa modelar com a utilização de notações

A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão

• Os principais métodos utilizados eram os de Booch, Rumbaugh(OMT)

• Em 1994, Rumbaugh e Booch decidiram terminar a “guerra” de

• Sistemas de informações corporativos

O objetivo disso é fornecer múltiplas visões do sistema a ser modelado,

A UML modela um sistema e sua interação com o usuário através de

Este é o diagrama mais geral e informal da UML, sendo utilizado

Este é o diagrama mais utilizado e o mais importante da UML, servindo

O Diagrama de Seqüência preocupa-se com a ordem temporal em que

O Diagrama de Comunicação era conhecido como Diagrama de

O Diagrama de Máquina de Estados era conhecido nas versões

O Diagrama de Atividade era considerado um caso especial do antigo

Objetivo: Descrever um modelo funcional do sistema. Procura

Deve estabelecer um modelo de requisitos do sistema através da

Este diagrama utiliza três elementos básicos para a sua construção:

•Em um Consultório Médico Médico Atendente

•Em uma Biblioteca

• Um caso de uso representa uma funcionalidade completa do

• Os Casos de Uso representam as funções do sistema, ou seja, os

ele precisa fazer com o sistema?”

UC Manter Usuário = UC Alterar Usuário

Fazendo uma analogia:

UC Alterar conta corrente

UC Consultar conta corrente