Introdução a

Orientação a Objetos
e UML
 Introdução a
Orientação a Objetos
Introdução a Orientação a Objetos

A construção de uma solução computadorizada consiste no
mapeamento do problema a ser resolvido no mundo real
(Espaço do Problema) em um modelo de solução no Espaço de
Soluções.

Gap Semântico – distância entre o problema do mundo real e o
modelo abstrato construído.

A Orientação a Objetos é um dos paradigmas existentes para
apoiar o desenvolvimento de sistemas, que busca fornecer
meios para se diminuir o gap semântico.
Introdução a Orientação a Objetos
Introdução a Orientação a Objetos

Vantagens / Benefícios

Gap Semântico Reduzido – o mundo real é composto por objetos, e o mesmo ocorre
com o mundo computacional, facilitando assim a compreensão;

Centralização de dados e funções em uma única unidade, o objeto;

Reutilização – o que permite um ganho significativo de tempo e custo. Aqui há destaque
para o conceito de herança. No desenvolvimento de softwares o uso de tal conceito
reduz custo e tempo;

Modularização - não só no que se refere aos pacotes, mas principalmente ao tratamento

de classes;

Compatibilidade - os modelos desenvolvidos (análise, projeto e programação) são

claramente relacionados e complementares. Fica destacada aqui a importância
crescente

da documentação de um software;

Manutenibilidade - a modularização natural em classes facilita a realização de alterações
no software.

Ocultamento de Informação – uma classe enxerga apenas a interface de outra classe, o
que evita vários erros acidentais.
Introdução a Orientação a Objetos

A Orientação a Objeto é um paradigma de análise, projeto e

programação de sistemas de informação automatizados
baseado na composição e interação entre diversas unidades de
software chamadas objetos.
Conceitos da Orientação a Objetos
Objetos

Mas o que é Objeto?
De acordo com o dicionário: - Objeto: “1. Tudo que se oferece aos nossos sentidos ou
à nossa alma. 2. Coisa material: Havia na estante vários objetos. 3. Tudo que
constitui a matéria de ciências ou artes. 4. Assunto, matéria. 5. Fim a que se mira ou
que se tem em vista”

Objetos podem ser não só coisas concretas como também coisas inanimadas, como
por exemplo uma matrícula, as disciplinas de um curso, os horários de aula
Objetos

Mas o que é Objeto?
De acordo com o dicionário: - Objeto: “1. Tudo que se oferece aos nossos sentidos ou
à nossa alma. 2. Coisa material: Havia na estante vários objetos. 3. Tudo que
constitui a matéria de ciências ou artes. 4. Assunto, matéria. 5. Fim a que se mira ou
que se tem em vista”

Objetos podem ser não só coisas concretas como também coisas inanimadas, como
por exemplo uma matrícula, as disciplinas de um curso, os horários de aula
Classes

O que é uma Classe?

Uma classe descreve um conjunto de objetos com propriedades e
comportamentos semelhantes e com relacionamentos comuns com outros
objetos.

Classes podem incluir abstrações que são parte do domínio do problema, assim como as
classes que fazem uma implementação. Podemos usar ainda as classes para
representar itens de software, de hardware e até itens que sejam somente conceituais.

Exemplo:

A classe Pessoa deverá ter atributos e métodos comuns
Tipos de Classes


Classe Concreta – Uma classe que tem assinatura e a
implementação de métodos.

Classe Abstrata – Provê organização, não possui “instances” e
possui uma ou mais operações (métodos) abstratas.
Interfaces

As interfaces são estruturas muito parecidas com as classes,

porém com um propósito diferente.
Uma interface não possui atributos e sim somente operações.
O fato aqui é que as operações não são como nas classes, ou
seja, em uma interface estas operações não possuem
implementação.
Uma interface será utilizada para definir comportamentos que
outros elementos, as classes, podem desejar implementar.
Imagine então que queremos definir um tipo de comportamento
que poderá ser implementado por mais de uma classe em nosso
sistema, então este comportamento colocaremos em uma
interface.
A classe obrigatoriamente deverá possuir estas operações da
interface implementadas nela, sendo que a implementação
ficará na classe e não na interface.
Abstração

Princípio de ignorar aspectos não relevantes de um assunto,

segundo a perspectiva de um observador, tornando possível
uma a concentração maior nos aspectos principais do assunto.
Só devem ser mapeados os objetos que são relevantes ao
problema, bem como as características desses objetos que
forem necessários.
Encapsulamento

O encapsulamento consiste na separação dos aspectos externos

de um objeto, acessíveis por outros objetos, de seus detalhes
internos de implementação, que ficam ocultos dos demais
objetos [Rumbaugh94].
A interface de comunicação de um objeto deve ser definida de
forma a revelar o menos possível sobre o seu funcionamento
interno.
Os usuários tem conhecimento apenas das operações que podem
ser realizadas e precisam estar cientes apenas do QUE as
operações fazem, e não COMO elas estão implementadas.
[Booch94]
Herança

O conceito de Herança na Orientação a Objetos lembra o conceito

de herança genética, na qual um elemento descendente herda
as características de um elemento ancestral.
Polimorfismo

É a operação que pode assumir múltiplas formas, a propriedade

segundo o qual uma operação pode comportar-se
diferentemente em classes diferentes.
Overloading

Possibilidade de reúso do nome do método para diferentes

implementações, em tempo de execução, a aplicação escolherá
o método adequado para cada chamada.
Para cada tipo de dados existe um método, o reúso do nome do
método é permitido, entretanto a lista de argumentos deve ser
diferente.
Overrinding

Uma subclasse pode mudar o comportamento herdado da

Superclasse, ou seja, um método herdado poderá ser alterado.
Definindo o Escopo
do Sistema com
Casos de Uso
Definindo o Escopo
do Sistema com
Casos de Uso
Definindo o Escopo do Sistema com
Casos de Uso

A modelagem de casos de uso pode ajudar a delimitar o escopo
do sistema, identificando o que está dentro e o que está fora da
fronteira do sistema.


O diagrama de casos de uso é a ferramenta gráfica utilizada
para este propósito. Nele demonstramos visualmente o
comportamento esperado ( as funcionalidades ) pelo sistema e
todos os envolvidos com o sistema ( atores ) e com isso temos a
fronteira do sistema definida de forma clara e objetiva.


Elaboramos o diagrama de casos de uso de sistema para
representar os requisitos funcionais, ou seja, as funções que
deverão estar disponíveis no sistema para que as necessidades
que motivaram a sua construção sejam satisfeitas.
Descrevendo o Sistema sob o ponto de vista do
usuário.
 A modelagem de casos de uso deve ser feita considerando-se a
visão do usuário, seus problemas, suas necessidades de
informação, as atividades que fazem parte do seu dia a dia, as
informações com as quais trabalha, etc.

 A descrição do sistema não deve levar em considerações

aspectos técnicos relacionados com a tecnologia de software ou
hardware utilizados para construção da solução.

 É muito importante que o analista de sistemas busque a

compreensão do negócio através de técnicas de levantamento
de requisitos como o uso de entrevistas, questionários,
observação do ambiente de trabalho do usuário, sessões JAD
ou brainstorm.
Descrevendo o Sistema sob o ponto de vista do
usuário.
Quantos casos de uso temos no cenário abaixo?
Descrevendo o Sistema sob o ponto de vista do
usuário.
Imagine um atendente de balcão do INSS que atende segurados em suas diversas
necessidades. O primeiro segurado da fila deseja executar o processo de negócio
Averbar Tempo de Serviço. Para isso, o atendente consulta um arquivo
convencional, pega um ou mais formulários sobre a mesa e, possivelmente,
consulta o tempo de contribuição do segurado no sistema.

Durante a realização desse processo de negócio, o atendente e o segurado trocam

informações e documentos, ambos participando, portanto, do processo. Os dois
são ditos atores do negócio, pois cada um deles desempenha seu papel específico
no processo de negócio.

O atendente também consulta o tempo de contribuição do segurado no sistema.

Por usar o sistema, o atendente é ator do sistema, além de ator do negócio. O

segurado, no entanto, não interage com o sistema e, portanto, não é ator do
sistema. É importante ressaltar que, mesmo que o atendente retire um relatório do
sistema e o entregue ao segurado, este não se torna um ator do sistema por isso.
O que são Atores?

Um único indivíduo pode interpretar o papel de vários atores (por exemplo, José,
além de ser – ou interpretar o papel de – caixa, pode atuar como o atendente de
balcão); vários indivíduos podem interpretar o papel de um único ator (por
exemplo, José e Pedro podem ser, ambos, atores caixa).
O que são Atores?

O nome do ator, idealmente uma expressão breve no singular, deve sugerir

claramente o papel que o ator representa, dentro do jargão do negócio, ou seja,
não deve ser, por exemplo, uma expressão de uso restrito ao ambiente da equipe
de modelagem ou o nome de um usuário que vai interagir com o sistema.
Certo Errado
Pensionista Dispositivo
Segurado Sistema
Sistema de Benefícios Usuário
Leitor de Código de Barras Zé
O que são Atores?
Um ator não é uma pessoa específica. Quase sempre é possível achar
pelo menos duas pessoas cujas responsabilidades e atividades se encaixam
no perfil de um mesmo ator e nem por isso serão modelados dois atores no
sistema.
Falhas comuns em Casos de Uso

1. Escrever casos de uso para os requisitos funcionais.

Às vezes os casos de uso são expressos em termos de requisitos
funcionais, em termos do que o sistema deve fazer. Na
realidade deveriam ser expressos descrevendo as ações que os
usuários fazem e as respostas que o sistema gera, ou seja, as
interações entre o usuário e o sistema para realização de uma
tarefa, uma atividade do processo de negócio que será atendido
por um requisito.

Lembre-se que o caso de uso deve levar em consideração a forma

como o ator interage com o sistema. Os requisitos funcionais
não descrevem a forma como o ator interage com o sistema. Os
requisitos descrevem apenas o que o sistema deve fazer.
Falhas comuns em Casos de Uso

2. Incluir detalhes da interface com o usuário no caso de uso

O caso de uso não deve incluir detalhes da camada de interface com

o usuário, mas deve ser livre de detalhes sobre os campos e outros
elementos de suas telas. O caso de uso deve ser independente da
interface com o usuário que pode ser uma página em uma intranet,
uma janela no Windows ou Linux ou uma tela de um terminal que
acessa o mainframe.
Falhas comuns em Casos de Uso

3. Casos de Uso pouco detalhados

Não escrever os casos de uso muito sucintamente. Quando se

trata de escrever um texto para os casos de uso, não economize
nos detalhes. Você precisa lidar com todos os detalhes de ações
do usuário e as respostas do sistema na modelagem de interação,
de modo que você precisa colocar todos esses desses detalhes
em seus casos de uso.

Lembre-se também de que seus casos de uso servirá como base

para o seu manual do usuário. É melhor errar do lado de muitos
detalhes quando se trata de documentação do usuário.
Falhas comuns em Casos de Uso

4. Não considerar o ponto de vista do usuário

Outra falha comum ocorre quando equipe de desenvolvimento não

considera o ponto de vista dos usuários na especificação do caso
de uso. Você precisa descrever a interação do usuário com o
sistema levando em conta o ponto de vista do usuário, a forma que
ele trabalha, as ações que realiza em sua atividade que será
capturada pelo caso de uso.

Como mencionado anteriormente, você não precisa descrever os

campos das telas, e nem discutir a aparência estética de suas
telas, no entanto, deve buscar compreender o ponto de vista do
usuário na realização da tarefa e documentar isso na especificação
do caso de uso.
Falhas comuns em Casos de Uso

5. Omitir Fluxos Alternativos ou de Fluxos de Exceção

O Fluxo Básico de ação é geralmente mais fácil de identificar e escrever.

Fluxos Alternativos principais são identificados e especificados, alguns
Fluxos de Exceção são também especificados. Isso não significa, porém,
que você deve adiar lidar com cursos alternativos até, digamos, ter o
projeto detalhado.

Na verdade, todas as alternativas e possíveis exceções devem ser

tratadas pelo caso de uso e muito bem detalhadas. Não se pode
escrever um caso de uso considerando o apenas os fluxos principais e
deixar o programador com a responsabilidade de decidir por ele mesmo
como devem ser tratadas as exceções de negócio ou alternativas de
interação do ator com o sistema.

Quando isso ocorre, geralmente o programador tende a tratar estes

detalhes da forma que seja mais conveniente para ele.
Falhas comuns em Casos de Uso

6. Escrever Casos de Uso Longos

Casos de uso longos com especificação de várias páginas é uma

falha grave na especificação. Quase sempre, temos detalhes
desnecessários ou estamos modelando mais de um comportamento
no mesmo caso de uso.

Da mesma forma que é importante detalhar bem o caso de uso

também é importante evitar longas especificações de casos de uso
pois é difícil de entender o passo a passo dos fluxos em casos de
uso com especificações longas.

Um caso de uso deveria ser especificado em até 3 páginas para que

seja de fácil entendimento e compreensão do fluxo das ações do
usuário e respostas geradas pelo sistema.
Falhas comuns em Casos de Uso

Repetição de passos em Casos de Uso

Evite repetir passos em casos de uso. Ao invés disso, prefira usar

associações do tipo Inclusão ou Extensão nos casos de Uso.
Promover o reuso é muito importante para evitar redundância nas
especificações.

Quase sempre é possível identificar um comportamento comum em

vários casos de uso e promovê-lo a um caso de uso que pode ser
incluído em outro caso de uso ou que possa estender outro caso de
acordo com uma condição ou regra de negócio.

Com isso se ganha em reuso e qualidade na especificação dos

casos de uso.
Escrevendo Casos de Uso Eficazes

Identificação do Caso de Uso

UC_<XX>_<Nome do Caso de Uso>

Exemplo: UC_01_IncluirRepresentanteLegal

- O Número do caso de uso é gerado pela ferramenta de gestão de

requisitos (Caliber)
- O nome do caso de uso deve iniciar com um verbo no infinitivo ( Incluir,
Aprovar, Conceder, Cancelar, etc. )

Descrição do Caso de Uso

- Uma descrição do propósito do caso de uso, do seu objetivo

- Use até duas frases para descrever o objetivo do ator ao usar o caso de
uso
Escrevendo Casos de Uso Eficazes

Atores Envolvidos
- Preencher com os atores que interagem com o caso de uso no
diagrama de casos de uso.
- Todos os atores envolvidos devem ser mencionados neste item.

Pré-Condição
- Descrever as condições que devem ser verdadeiras para que o
caso de uso seja executado.
- Estas condições devem especificar o estado do sistema antes da
execução do caso de uso.

Exemplo: O Segurado deve estar cadastrado no CNIS para requerer

o Beneficio.
Escrevendo Casos de Uso Eficazes

Pré-Condição ( Continuação )
- Descrever as condições que devem ser verdadeiras para que o
caso de uso seja executado.
- Estas condições devem especificar o estado do sistema antes da
execução do caso de uso.

Exemplo: O Segurado deve estar cadastrado no CNIS para requerer

o Beneficio.

Fluxo de Eventos
- São sequências de passos que representam os cenários possíveis
para um caso de uso. Um caso de uso pode ter vários cenários.
- Os passos devem descrever o que deve ser feito e não como fazer.
- Um cenário é uma sequência específica de ações que ilustra um
comportamento.
Escrevendo Casos de Uso Eficazes

Fluxo de Eventos (Continuação)

- Os possíveis cenários para um caso de uso são:
- Fluxo Básico
- Fluxo Alternativo
- Fluxo de Exceção

 O Fluxo Básico descreve o que normalmente ocorre quando o caso de

uso é executado

 O Fluxo Alternativo descreve um comportamento alternativo ou variações

do comportamento normal que podem ocorrer no caso de uso.

 O Fluxo de Exceção descreve um comportamento excepcional em

relação ao comportamento normal ou a um comportamento alternativo e que
pode ocorrer no caso de uso.
Fluxo Básico

O Fluxo Básico normalmente deve ser iniciado por uma ação do Ator ou por um
Evento como por exemplo Passagem do Tempo, nesse caso o Ator é o
Temporizador ou simplesmente Tempo.

Exemplos:
O Caso de Uso inicia quando o Ator seleciona a opção Consultar Beneficio por NIT

O Caso de Uso é iniciado pelo Temporizador Diariamente ( Semanalmente,

Quinzenalmente, Mensalmente )

O Fluxo Básico descreve os passos realizados pela funcionalidade básica ou

central do Caso de Uso. Ele descreve a situação mais comum na qual o objetivo
é atingido.

O detalhamento do Fluxo Básico deve descrever os eventos de maior normalidade

no processo descrito ( conceito de mundo ideal ).
Fluxo Básico

O Fluxo Básico, e os Fluxos Alternativos e de Exceção, apresenta uma sequência

de passos que defletem a interação do ator com o sistema. Assim cada passo
descrevendo uma ação do Ator deve ter um passo descrevendo uma resposta
do sistema. Nunca devemos suprimir uma ação do ator ou uma resposta do
sistema.

O Fluxo Básico não deve conter condições para a realização dos passos. As
condições são especificadas nos Fluxos Alternativos e nos Fluxos de Exceção.

Sempre que houver erros ou exceções para um determinado passo do Fluxo Básico
mencionar entre parênteses(), os Fluxos Alternativos (alternativas) e os Fluxos
de Exceção (erros ou exceções) que irá tratar as alternativas ou exceções. Esta
prática é importante para facilitar compreensão do Caso de Uso.
Fluxo Alternativo
Fluxo Alternativo
Às vezes, o Fluxo Básico possui várias alternativas prováveis de ocorrer. Nestes casos,
pode-se usar o conceito de Fluxo Alternativo. Os Fluxos Alternativos representam um
dos possíveis caminhos do Fluxo Básico.

Um Caso de Uso pode ter vários Fluxos Alternativos e pode ser necessário vários níveis
de Fluxos Alternativos, porém recomenda-se cautela pois isso torna o Caso de Uso
mais complexo e difícil de entender.

Caso existem Fluxos Alternativos comuns e que são repetidos em diferentes Casos de
Uso, pode-se analisar a possibilidade de se modelar um novo Caso de Uso que
possa ser usado por outros Casos de Uso.

Os Fluxos Alternativos devem ser referenciados entre parênteses () no passo onde o

sistema verifica as alternativas ou o ator seleciona uma alternativa ao Fluxo Básico.
Exemplo:
Fluxo Básico:
1 – O sistema apresenta uma lista de motivos de suspensão do Benefício
2 – O Servidor da APS seleciona o motivo de suspensão igual a suspeita de óbito (FA 01 – Motivo
Suspensão Judicial )
Fluxo Alternativo

O Fluxo Alternativo deve iniciar descrevendo o passo e o Fluxo de Evento ( Fluxo

Básico ou outro Fluxo Alternativo ) pelo qual foi referenciado.

O Fluxo Alternativo deve encerrar descrevendo o passo e Fluxo de Evento ao qual

deve retornar ou deve encerrar o Caso de Uso da seguinte forma: O Caso de
Uso é encerrado:
– Encerramento de Fluxo Alternativo
– Exemplo:
– Retorna para o passo X.XX do Fluxo Básico ou Fluxo Alternativo de
Origem

– O Caso de Uso é encerrado

Fluxo de Exceção

O Fluxo de Exceção trata de situações de exceção ou erros ocorridos no Fluxo

Básico e/ou nos Fluxos Alternativos

O Fluxo de Exceção deve iniciar descrevendo o passo e o Fluxo de Evento que

originou o Fluxo de Exceção.

O Fluxo de Exceção deve encerrar da seguinte forma:

– Exemplo:
– O Caso de Uso é encerrado
– Retorna para o passo X.X do Fluxo Básico ou Fluxo Alternativo de Origem
Relacionamentos entre Casos de Uso

A UML define diversos tipos de relacionamentos:


Comunicação

Inclusão

Extensão

Generalização

Relacionamento de Comunicação

Representa o relacionamento entre os Atores e os Casos de Uso

Um Ator pode se relacionar com mais de um Caso de Uso

O fato de um Ator estar associado a um Caso de uso significa que esse ator
interage (troca informações) com o sistema

É o mais comum dos relacionamentos
Relacionamentos entre Casos de Uso

Relacionamento de Inclusão (Include)


Permitido somente entre Casos de Uso

O Caso de Uso incluído sempre será executado pelo Caso de Uso que o
inclui.


Evita repetição de fluxos alternativos e passos entre os Casos de Uso,
promovendo reuso com a criação de novos Casos de Uso que podem ser
incluídos em outros Casos de uso


Um Caso de Uso pode ser incluído por mais de um Caso de Uso


A Inclusão é um relacionamento que elimina a repetição de informações e
simplifica a especificação de um Caso de Uso


O Relacionamento de Inclusão não deve refletir jamais a sequência de
navegação do Protótipo de Projeto.
Relacionamentos entre Casos de Uso

A figura abaixo mostra uma situação em que determinado restaurante opera de formas
diferentes no almoço e na janta: no almoço ele oferece refeição por quilo e à noite a refeição é
oferecida à la carte. Existe um conjunto de ações comum a ambos os casos de uso, que
ocorrem obrigatoriamente e de forma idêntica segundo as regras do restaurante: o pagamento
pela refeição.
Relacionamentos entre Casos de Uso

Relacionamento de Extensão (Extends)


Permitido somente entre Casos de Uso

Estender um Caso de Uso significa afirmar que ele será executado de
acordo com uma alternativa/condição que deverá ocorrer, ser atendida.

Evita repetição de fluxos alternativos e passos entre os Casos de Uso,
promovendo reuso com a criação de novos Casos de Uso que podem ser
incluídos em outros Casos de uso

Um Caso de Uso pode ser estendido por mais de um Caso de Uso

Um Caso de Uso pode estender mais de um Caso de Uso.

A Extensão é um relacionamento que elimina a repetição de informações e
simplifica a especificação de um Caso de Uso

O Relacionamento de Extensão não deve refletir jamais a sequência de
navegação do Protótipo de Projeto.

Quando a extensão de um Caso de Uso depende da escolha ou alternativa
definida por um Ator, a representação no Diagrama deverá refletir a
comunicação entre este Ator e o Caso de Uso.
Relacionamentos entre Casos de Uso

A figura abaixo mostra a situação em que o restaurante faz promoções para os almoços,
de modo que os clientes habituais não pagam a refeição a cada determinado número de
idas ao restaurante. Isso significa que, de acordo com as regras do restaurante, o
pagamento pelo almoço pode não ocorrer ou seja não é obrigatório pois está condicionado
a uma regra de negócio.
Relacionamentos entre Casos de Uso

Relacionamento de Generalização

Relacionamento permitido somente entre Casos de Uso

Permite que um Caso de Uso herde comportamento de um Caso de Uso
mais genérico

Somente o comportamento diferente precisa ser redefinido em um Caso de
Uso que herda o comportamento do Caso de Uso ancestral.

Então o Caso de Uso herdeiro pode especializar o comportamento do
Caso de Uso Base, adicionando novo comportamento nos passos dos
Fluxos de Evento ( Fluxo Básico, Fluxo Alternativo e Fluxo de Exceção )

Este Relacionamento pode existir entre Casos de Uso e entre Atores.

Não é um tipo muito comum de Relacionamento e deve ser evitado.
Relacionamentos entre Casos de Uso

O processo de venda de automóvel para clientes com limite de crédito atingido é

realizado com base no processo básico para clientes que compram a crédito,
possivelmente demandando outras informações do cliente, outras garantias e a
anuência do gerente de vendas. O processo de venda para um cliente habitual
possivelmente altera o prazo de entrega e agiliza o processo de coleta de
informações do cliente.
Regras de Negócio

Referencia à Regras de Negócio

As Regras de Negócio tratadas por um Caso de Uso deve ser referenciadas entre
parênteses () no passo do Fluxo de Evento em que são aplicadas. Esta boa
prática de especificação ajuda a manter a rastreabilidade entre os Casos de Uso
e as Regras de Negócio.

A Regra de Negócio deve ser aplicada no passo em que o Ator interage com o
sistema e nunca no passo em que o sistema envia resposta ao Ator.

Para cada Regra de Negócio deverá ser especificado um Fluxo de Exceção para
tratar a exceção para quando a Regra de Negócio não for atendida.

O Fluxo de Exceção que tratar uma Regra de Negócio deve conter a referência à
Regra de Negócio e, adicionalmente, à Mensagem que deve ser apresentada ao
Ator, se for o caso.
Regras de Validação

Quando existir um passo em que foi aplicada uma Regra de Validação a

referência a esta regra deve constar no passo e deve vir entre parênteses ().

Devem ser aplicadas Regras de Validação no passo onde o Ator interage com o
sistema e nunca no passo que o sistema envia resposta ao Ator.

Toda Regra de Validação deve ter um Fluxo de Exceção para tratar a situação em
que a Regra de Validação não for atendida.

O Fluxo de Exceção que tratar uma Regra de Validação deve conter a referência
à Regra de Validação e, adicionalmente, à Mensagem que deve ser
apresentada ao Ator, se for o caso.
Mensagens do Sistema

Nos passos dos Fluxos Básico, Alternativos e de Exceção devemos referenciar as

Mensagens que serão exibidas como resposta do Sistema ao Ator.

As Mensagens podem ser dos seguintes tipos:


Atenção

Erro

Sucesso

Pergunta

Dia

Lembrete

Quando existir um passo em que foi exibida uma Mensagem a referência a esta
Mensagem deve constar no passo e deve vir entre parênteses (). Deve ser
referenciado no passo o código da mensagem e mencionado o tipo de erro.
Exemplo:
O sistema apresenta mensagem de confirmação do cadastramento (MSG_XXX)
Exercícios
Exercícios – Diagrama de Casos de Uso

Exercício 1

Vídeo Locadora

Desenvolva um Diagrama de Casos de Uso para um Sistema de vídeo locadora que trabalha da
seguinte forma:

Ao realizar uma locação, o sócio deve primeiro informar seu código para que o atendente possa
verificar se este se encontra cadastrado. Se o sócio não estiver cadastrado, então a locação deverá
ser recusada e o sócio será informado de como proceder para se cadastrar. Caso esteja cadastrado,
o atendente deve verificar se o sócio em questão, já devolveu todas as locações feitas
anteriormente, se não o tiver feito, a locação deve ser recusada.

Caso o sócio tenha quitado todas as locações anteriores, então este deverá informar os títulos dos
filmes ou os números das cópias dos filmes que deseja alugar. Em seguida o atendente registrará a
locação e fornecerá as cópias em questão para o sócio.

É responsabilidade do atendente realizar a manutenção dos filmes e de suas respectivas cópias.

Registrando os novos filmes adquiridos pela locadora, por exemplo.
Exercícios – Diagrama de Casos de Uso

Exercício 2

Venda de Passagens Aéreas

Desenvolva o Diagrama de Casos de Uso para um sistema de venda de passagens aéreas pela
Internet, equivalente ao módulo de compra de passagens por um cliente, levando em consideração
os seguintes fatos:

O cliente deve selecionar o local de origem ( cidade e aeroporto de onde partirá ) voo e o local de
destino, informando ainda se deseja uma passagem só de ida ou passagens de ida e volta. Em
seguida o cliente deve selecionar a data de partida e, se tiver optado por ida e volta, a data de
retorno.

Após isso, o cliente deve consultar os horários e classes (econômica, executivo, etc ) disponíveis do
vôo desejado.

Caso o cliente esteja de acordo com o horário e preço de algum dos voos apresentados, então ele
deve selecionar os assentos disponíveis e informar o número de parcelas com que deseja pagar a
passagem.
Exercícios – Diagrama de Casos de Uso

Exercício 3

Clínica Veterinária

Crie um Diagrama de Casos de uso para um sistema de veterinária, levando em consideração as

seguintes características:

Um cliente chega à clínica onde marca uma consulta com a secretária, informando seus dados
pessoais e do(s) animal(s) que deseja tratar. Se o cliente ou o animal ainda não foram cadastrados
ou precisam atualizar algum dado, a secretária deverá atualizar seus cadastros.

Em cada sessão de tratamento, o cliente deve informar os sintomas do animal e estes devem ser
registrados. Um tratamento pode ser encerrado a qualquer momento ou pode ter várias sessões
dependendo do diagnóstico feito pelo médico-veterinário.
Modelando o fluxo de
processos com
Diagrama de
Atividades
Tipos de Diagramas

Diagramas Comportamentais
Diagrama de Caso de Uso
Diagrama de Sequência
Diagrama de Colaboração
Diagrama de Estados
Diagrama de Atividades
Diagramas Estruturais
Diagrama de Classes
Diagrama de Pacotes
Diagrama de Objetos
Diagrama de Componentes
Diagrama de Implantação
Diagrama de Atividades

É um tipo específico de Diagrama de Estados, hoje conhecido

como Diagrama de máquina de Estados.

Útil para modelar fluxo de trabalho (workflow).

Representa as atividades que afetam o estado do sistema e os

fluxos que levam de uma atividade a outra.

É usado para modelar processo de negócio e workflows.

Diagrama de Atividades – Elementos Básicos

Estados Iniciais e Finais

Ação: realizada de forma instantânea.

Atividade: demora certo tempo para ser realizada.

Transição

Decisão

Paralelismo ou Bifurcação (fork)

Sincronização ou União (join)

Elementos Básicos - Representação
Estados Iniciais e Finais

Todos os Diagramas de Atividades possuem um estado inicial e

no mínimo um estado final.

Estado inicial indica o início do processo

Estado final o fim do processo

Atividade

Retângulos com bordas arredondadas representam as atividades

Ação que deve ser feita
Quando finalizada transfere a execução para a próxima atividade
(transição)
Transições

Setas contínuas que representam fluxo de trabalho de uma

atividade para outra

Caminho a ser seguido para conclusão do processo.

Decisões

Losango utilizado para controlar os desvios do fluxo de controle

Ramificação: uma entrada e duas saídas
Mesclar : duas entradas e uma saída

Utiliza-se uma expressão lógica.

Bifurcação e União

Barra sólida usada para atividades paralelas (concorrentes)

Bifurcação: Divisão do fluxo de controle

União: sincronização das atividades

Raias

Raias são uma forma de organização lógica das atividades

Podem estar associadas a objetos, componentes do sistema ou a

atores.
O Diagrama
Modelagem da Lógica do Caso de Uso

A realização de um caso de uso requer que alguma computação seja

realizada.

Esta computação pode ser dividida em atividades.

“Passo P ocorre até que a C seja verdadeira”
“Se ocorre C, vai para o passo P”.

Nessas situações, é interessante complementar a descrição do caso de

uso com um diagrama de atividade.
Modelagem da Lógica do Caso de Uso

Os fluxos principal, alternativos e de exceção podem ser representados

em um único diagrama de atividade.

Identificação de atividades através do exame dos fluxos do caso de uso.

Modelagem da Lógica do Caso de Uso
Exercícios
 Exercícios – Diagrama de Atividades

Locação de Fitas

Desenvolva o Diagrama de Atividades para um sistema de vídeo locadora equivalente ao módulo

de locação de fitas de filmes, enfocando as ações necessárias para realizar este processo, de
acordo com que foi explicado até aqui e com os fatos complementares abaixo:

O sócio deve se dirigir ao atendente e apresentar seu código de registro de sócio ou, se não se
lembrar, seu nome.

O atendente então pesquisa o sócio no cadastro de sócios para verificar se ele realmente é sócio.
Se não estiver cadastrado a locação deve ser recusada.

Caso o sócio esteja cadastrado, o sistema deve verificar se este possui alguma pendencia, ou
seja, alguma locação que não foi devolvida. Se houver alguma pendencia a locação deve ser
recusada.

Se o sócio não possuir pendencias, então o atendente irá registrar a locação, bem como cada uma
das cópias locadas.
 Exercícios – Diagrama de Atividades

Venda de Passagens Aéreas

Desenvolva o Diagrama de Atividades para um sistema de venda de passagens aéreas pela

Internet para o módulo de compra de passagens por um cliente. Considere as informações dos
exercícios anteriores e os seguintes fatos adicionais:

Primeiramente o cliente deve selecionar o local de origem, ou seja, um dos aeroportos da cidade
onde o passageiro tomará o voo.

Em seguida, o cliente deve selecionar o local de destino, ou seja, o aeroporto da cidade para onde
o passageiro deseja viajar.

Após isso, o cliente irá consultar todos os voos que possuam escala nos aeroportos de origem e
destino selecionados.

Caso o valor e o horário de algum voo satisfaçam o cliente, este comprará uma passagem para o
vôo em questão, caso contrário, o processo será encerrado.

Se o cliente optar por comprar uma passagem, este deverá se identificar caso já seja registrado ou
gerar um novo registro caso não esteja cadastrado.

Em seguida, deverá selecionar a forma de pagamento da passagem após o que a passagem será
finalmente gerada.
 Exercícios – Diagrama de Atividades

Clínica Veterinária

Crie um Diagrama de Atividades referente ao processo de geração de uma nova consulta de um determinado
animal de um sistema de clínica veterinária, determinando os passos percorridos durante este processo, levando
em consideração as seguintes características.

Ao chegar a veterinária, o dono do animal deve se identificar. Caso este não esteja registrado, a secretária deverá
cadastrar os dados pessoais do cliente, bem como de seu animal.

Ao consultar um cliente, uma lista de todos os animais do cliente é apresentada junto com os dados pessoais do
cliente. Caso o animal para o qual o cliente deseja atendimento não esteja presente na lista, a secretária deve
cadastrá-lo.
Ao selecionar um animal, a secretária pode visualizar todos os tratamentos do animal, já realizados ou ainda em
andamento.

A partir da listagem dos tratamentos, a secretária pode selecionar um tratamento, o que fará surgir juntamente com
as informações gerais do tratamento, todas as consultas já realizadas durante o mesmo, permitindo também que
outra consulta possa ser marcada, caso o tratamento não tenha sido concluído.

Se for a primeira consulta do animal, primeiramente um novo tratamento deve ser gerado, contendo a data de inicio
do tratamento e identificando o animal e os sintomas gerais do animal. Caso não seja a primeira consulta deve-se
selecionar o tratamento referente à consulta para depois marcá-la.

Após selecionar o cliente, o animal para o qual será marcada a consulta e o seu tratamento, a secretária poderá
marcar a consulta. Sempre que for registrar uma nova consulta, a secretária deve informar a data e a hora
desejadas pelo cliente.
 Mais Detalhes do
Diagrama de Classes
O que é Diagrama de Classes?

É um diagrama que demonstra a estrutura estática das classes de

um sistema e seus relacionamentos.
Classes podem se relacionar com outras através de diversas
maneiras:
• Associações (conectadas entre si)
• Dependência (uma classe depende ou usa outra classe)
• Especialização (uma classe é uma especialização de outra
classe)
• Pacotes(classes agrupadas por características similares)
Associações entre Classes

A associação é o tipo mais comum e mais importante em um sistema orientada a

objetos
Uma associação é um relacionamento ou ligação entre duas classes permitindo
que objetos de uma classe possam comunicar-se com objetos de outra classe.
O objetivo da associação é possibilitar a comunicação entre objetos de duas
classes.
A associação aplica-se a classes independentes que precisam comunicar-se de
forma uni ou bidirecional de maneira a colaborarem para a execução de algum
caso de uso.
Uma classe pode associar-se a uma ou mais classes para fins de comunicação.
Não existe um limite máximo de associações que uma classe pode possuir com
outras classes.
Notação UML para Associações

Nome e Sentido

Uma associação é um segmento de reta ligando as duas classes.

Se a associação for unidirecional, inclui-se uma seta na extremidade de destino

da associação.
Notação UML para Associações

Cardinalidade
.É uma indicação que especifica o número de objetos de cada classe envolvidos
com a associação.
Quando não há uma especificação de cardinalidade, entende-se que a
cardinalidade é 1.

”Um objeto da classe Cturma se associa com 40 objetos da classe CAluno, e um

objeto da classe CAluno se associa com um número indefinido (inclusive zero)
de objetos da classe Cturma”.
Levantamento de Associações

Associações são definidas conforme seja necessário estabelecer

um canal para comunicação entre objetos de duas classes.

As associações são estabelecidas observando-se as necessidades

de comunicação definidas nos diagramas de sequência.

Sempre que houverem mensagens trocadas, estabelece-se uma

associação uni ou bidirecional conforme o sentido das
mensagens.
Agregação entre Classes

A agregação é um relacionamento pertinência entre classes que permite

estabelecer a inclusão de objetos de uma classe no interior de objetos de outra
classe.
A agregação também é dita uma relação ”parte-de” já que o objeto agregado
passa a constituir ou fazer parte do objeto que agrega.
Deve-se observar que não se trata de incluir (ou agregar) uma classe dentro de
outra mas de objetos dentro de outros objetos.
A relação de agregação permite criar composições de objetos, o que é bastante
útil quando se deseja definir hierarquias de dados ou procedimentos.
A comunicação é unidirecional do objeto que agrega para o objeto
agregado.
O objeto agregado não conhece, a princıpio, o objeto que agrega. Desta forma,
ele não pode comunicar-se com o objeto que agrega.
Tipo de Agregação

Agregação por Composição

Agregação por Associação

Agregação por Composição

Uma agregação por composição é uma agregação de fato.

Realmente é feita a criação ou alocação de um objeto dentro de um outro objeto.

A alocação do objeto interno é feita estaticamente pela instanciação do objeto

Deve-se observar que na agregação por composição é necessário que o número

de objetos agregados seja fixo uma vez que eles são alocados estaticamente.

A notação UML para agregações por composição é um retângulo preenchido

Exemplo de Agregação por Composição

O objeto ender da classe CEndereco esta sendo instanciado

dentro da classe CAluno.
Agregação por Associação

A agregação por associação tem a mesma interpretação do que a agregação por

composição, ou seja, entende-se que o objeto agregado é um componente do
objeto que agrega.
A grande diferença está na forma de alocação do objeto agregado.
Na agregação por associação a alocação do objeto agregado não ocorre de forma
estática no interior da classe do objeto que agrega. A alocação do objeto
ocorre de forma estática fora do objeto que agrega ou de forma dinâmica em
seu interior. O objeto que agrega guarda apenas o identificador ou endereço
do objeto agregado.
Note que em termos de implementação não existe diferença entre a associações
e a agregação por associação.
A agregação por associação é necessária quando deseja-se estabelecer uma
agregação envolvendo um número variável de objetos.
Exemplo de Agregação por Associação
Generalização/Especialização de Classes

A generalização ou especialização é um relacionamento que ocorre efetivamente

em termos estruturais entre duas classes.
Das duas classes envolvidas, uma será considerada uma classe base (ou
superclasse) e a outra será considerada uma classe derivada (ou subclasse).
Lendo-se a relação no sentido da classe base para a classe derivada entende-se
a relação como uma especialização, ou seja, a classe derivada seria uma
classe especial definida a partir da classe base.
Lendo-se a relação no sentido da classe derivada para a classe base, entende-se
a relação como uma generalização, ou seja, a classe base representa um
caso geral da classe derivada.
Independentemente do significado da relação, a implementação da generalização
ou especialização ocorre sempre na forma de uma herança da classe base
para a classe derivada.
Não se especifica cardinalidade para relacionamentos de herança pois
ela é sempre uma relação de uma única classe para outra classe.
Exemplo Generalização/Especialização de
Classes
Herança Múltipla

A herança múltipla ocorre quando uma classe deriva de mais de uma classe base.
Mantém-se exatamente os mesmos princípios da herança porém a classe
derivada passa a incorporar em seu interior os atributos e métodos de mais de
uma classe base.

O conceito de generalização se perde, em parte, no caso da herança múltipla pois

cada classe base não representa mais um caso geral de toda a classe
derivada, mas sim um caso geral de uma parte da classe derivada.
Exemplo Herança Múltipla

No exemplo não se pode mais afirmar que a classe CAutomovel seja uma
generalização completa de CCarro. CAutomovel é , na verdade,
uma generalização parcial pois só considera aspectos específicos de CCarro.
O conceito de especialização se mantém na herança múltipla. No exemplo,
CCarro é um caso especial de CAutomovel e é também um caso especial de
CBemMovel.
Diagrama de Objetos

O que é um Diagrama de Objetos?

É um diagrama que exibe uma variação do diagrama de classes e utiliza quase a

mesma notação. A diferença é que o digrama de objetos mostra os objetos
que foram “instanciados” das classes.
Diagrama de Pacotes

Como podemos definir um Diagrama de Pacotes?

A definição de Pacotes é uma generalização, ou seja, um agrupamento, com o
propósito de organizar as Classes de Objetos em grupos.

Esta abordagem facilita a análise a medida que o número de Classes de Objetos

cresce num cenário. O tipo de relacionamento é linha pontilhada com uma seta
que indica dependência.
Diagrama de Pacotes

Podemos usar a estrutura de pacotes para criar coesão entre as classes que tem
objetivos comum, por exemplo podemos colocar em único pacote todas as
classes que se referem a regras de negócios.

Fisicamente os pacotes tem a estrutura de diretórios e subdiretórios, isto quer

dizer a Aplicação terá o seguinte formato:
Exercícios
 Exercícios – Diagrama de Classes

Locação de Fitas

Elabore um Diagrama de Classes para um sistema de vídeo locadora equivalente ao módulo de

locação de fitas de filmes de acordo com as informações abaixo:

Um filme tem obrigatoriamente ao menos uma cópia, mas pode possuir diversas cópias. Cada
cópia refere-se exclusivamente a um determinado filme.

Um sócio pode realizar muitas locações enquanto permanecer sócio da locadora, mas uma
locação refere-se unicamente a um sócio.

Cada locação deve obrigatoriamente referenciar ao menos uma cópia de filme, podendo
referenciar muitas cópias, no entanto uma mesma cópia pode ser alocada diversas vezes, ao
longo do tempo.
 Exercícios – Diagrama de Classes

Venda de Passagens Aéreas

Elabore um Diagrama de Classes para um sistema de venda de passagens aéreas pela Internet,
equivalente ao módulo de compra de passagens por um cliente. Considere as seguintes
informações:

Um cliente pode ser um passageiro de muitos voos, cada voo requer a compra de uma passagem.
No entanto, cada passagem se refere a um cliente específico. A empresa mantém um cadastro de
todos os clientes que já foram passageiros algum dia.

Um voo pode ter muitos passageiros, no entanto cada passageiro se refere exclusivamente a um
voo específico. Cada voo possui origem, destino, data e hora.

Um voo pode fazer escalas em diversos aeroportos, ou seja, pode ter diversos destinos e um
aeroporto pode ser o destino de muitos voos. A empresa mantêm um cadastro de todos os
aeroportos para onde oferece voos.

Um aeroporto pode ser a origem ou o destino de muitas escalas, no entanto, um determinado

aeroporto só pode ser origem ou o destino de uma determinada escala, nunca os dois ao mesmo
tempo.

Um aeroporto está localizado em uma cidade especifica, mas uma cidade pode possuir muitos
aeroportos.
 Exercícios – Diagrama de Classes

Clínica Veterinária

Crie o Diagrama de Classes para um sistema de clínica veterinária, levanto em consideração as seguintes
características:

Um cliente pode possuir muitos animais, mas um animal pertence a apenas um único cliente. A clínica
precisa de informações a respeito de cada cliente, como nome, endereço, telefone e e-mail, além de um
resumo dos animais que lhe pertencem.

Um animal pertence a uma única espécie, porém podem haver vários animais de uma espécie. É preciso
manter informações sobre cada animal, como nome, sexo, idade e espécie a qual pertence.

Um animal pode realizar vários tratamentos, mas um tratamento é realizado exclusivamente por um
animal.

Cada tratamento possui ao menos uma consulta, mas pode possuir muitas consultas. Uma determinada
consulta refere-se exclusivamente a um determinado tratamento. Cada consulta deve armazenar
informações como a data em que foi realizada por somente um veterinário.

Um veterinário pode realizar muitas consultas, porém uma consulta deve ser realizada por somente um
veterinário.

Em uma consulta podem ser marcados exames para o animal, o número de exames possíveis em uma
consulta é indeterminado, mas precisam ser registrados.
 Modelando
Interações entre
Objetos
O que é Diagrama de Sequência?

É um diagrama que exibe a colaboração dinâmica entre os vários objetos

de um sistema. O principal aspecto deste diagrama é que a partir dele
percebe-se a sequência de mensagens enviadas entre os objetos.

Ele mostra a interação entre os objetos, algum evento que acontecerá em

um ponto específico da execução do sistema.
Explicando o Diagrama

O diagrama de sequência consiste em um número de objetos

mostrado em linhas verticais. O decorrer do tempo é visualizado
observando-se o diagrama no sentido vertical de cima para
baixo. As mensagens enviadas para cada objeto são
simbolizadas por setas entre os objetos que se relacionam.

Diagramas de sequência possuem dois eixos: o eixo vertical, que

mostra o tempo e o eixo horizontal, que mostra os objetos
envolvidos na sequência de uma certa atividade. Eles também
mostram as interações para um cenário específico de uma certa
atividade do sistema.
Explicando o Diagrama

No eixo horizontal estão os objetos envolvidos na sequência. Cada

um é representado por um retângulo de objeto e uma linha
vertical pontilhada chamada de linha de vida do objeto,
indicando a execução do objeto durante a sequência, como
exemplo citamos: mensagens recebidas ou enviadas e ativação
de objetos.
A comunicação entre os objetos é representada como linha com
setas horizontais simbolizando as mensagens entre as linhas de
vida dos objetos. A seta especifica se a mensagem é síncrona,
assíncrona ou simples. As mensagens podem possuir também
números sequenciais, eles são utilizados para tornar mais
explícito as sequencias no diagrama.
Explicando o Diagrama

Em alguns sistemas, objetos executam de forma concorrente, cada

um com sua linha de execução (thread). Se o sistema usa linhas
concorrentes de controle, isto é mostrado como ativação,
mensagens assíncronas, ou objetos assíncronos.

Os diagramas de sequência podem mostrar objetos que são

criados ou destruídos como parte do cenário documentado pelo
diagrama. Um objeto pode criar outros objetos através de
mensagens. A mensagem que cria ou destrói um objeto é
geralmente síncrona, representada por uma seta sólida.
Exemplo: Entregar Veículo
Exemplo em Detalhes
Diagrama de Comunicação

Antes da versão 2.0 era chamado de Colaboração.

É outra forma de representar um cenário: contém as mesmas

informações que o diagrama de sequência, mas não considera
a dimensão temporal.
Alguns autores recomendam utilizá-lo para analisar a colaboração
das classes de realização de um caso de uso, pois facilita a
identificação das classes que colaboram de forma mais próxima
e, por consequência, a identificação de pacotes de análise.
No diagrama de comunicação, a ordem de envio das mensagens é
dada por números sequenciais.
Diagrama de Comunicação
Mesmo Exemplo usando Diagrama de Sequência
Exercícios
 Exercícios – Diagrama de Sequência

Locação de Fitas

Desenvolva o Diagrama de Sequência para um sistema de vídeo locadora equivalente ao módulo

de locação de fitas de filmes, de acordo com os fatos já descritos nas questões relativas a este
sistema nos exercícios anteriores e nos fatos complementares abaixo:

O atendente deve verificar se o sócio está cadastrado. Senão estiver cadastrado a locação deve
ser recusada.

Em seguida, o atendente deve verificar se o sócio possui alguma locação pendente, caso em que
também recusará o empréstimo.

Se o sócio existir e não tiver locações pendentes, então a locação deverá ser registrada e as
cópias emprestadas ao sócio.

Durante o registro da locação deverão ser registrado todas as fitas alocadas.

 Exercícios – Diagrama de Classes

Passagens Aéreas

Desenvolva o Diagrama de Sequencia para um sistema de venda de passagens aéreas pela

internet, equivalente ao módulo de compra de passagens por um cliente, levando em consideração
os fatos já enunciados nos exercícios anteriores, juntamente com os seguintes fatos
complementares:

O cliente irá selecionar uma origem ( seu ponto de partida ) e um destino ( seu ponto de chegada )
e consultar todos os voos relacionados ao destino escolhido que partam da origem selecionada.

Caso o horário e o valor de algum dos voos retornados satisfaça o cliente, ele comprará as
passagens.

Ao comprar uma passagem, o cliente precisa se identificar, caso já esteja cadastrado na empresa
ou se registrar, caso ainda não esteja cadastrado. Mesmo que já esteja registrado, um cliente pode
ter que atualizar seus dados.

Após a identificação do cliente, a passagem será gerada.

 Exercícios – Diagrama de Classes

Clínica Veterinária

Desenvolva um Diagrama de Sequência para o módulo de consulta de um animal para um sistema

de clínica veterinária, levando em consideração as seguintes características do negócio:

Se a consulta não for a primeira consulta do tratamento, o veterinário antes de examinar o animal
pode querer verificar o histórico das últimas consultas do tratamento. Para isso será necessário
consultar o dono do animal que está sendo tratado, esta consulta trará juntamente com as
informações do cliente uma listagem de todos os animais pertencentes ao cliente. Com esta
listagem, o veterinário seleciona o animal a ser tratado, o que forçara exibir as informações
específicas do animal. A partir do cadastro do animal podemos consultar uma lista de todos os
tratamentos feitos pelo mesmo e após selecionar o tratamento atual do animal pode-se visualizar
uma nova listagem contendo todas as consultas já realizadas, bastando ao veterinário selecionar a
consulta desejada.

Após a realização da consulta pelo veterinário deve-se registrar o histórico da consulta que contém
a data em que a consulta foi realizada, o resumo do diagnóstico que foi feito e o médico veterinário
que realizou a consulta. Se for a primeira consulta, o sistema deve gerar uma nova instância de
tratamento, já que um tratamento pode possuir muitas consultas, mas uma consulta é sempre
relacionada a um tratamento.
Modelando o Ciclo de
Vida do Objeto
(Máquina de Estado)
O que é Diagrama de Estado?

É um diagrama que tipicamente complementa a descrição das

classes.
Este diagrama exibe todos os estados possíveis que objetos de
uma certa classe podem se encontrar e mostra também quais
são os eventos do sistemas que provocam tais mudanças.
Diagramas de estado capturam o ciclo de vida dos objetos,
subsistemas e sistemas. Eles mostram os estados que um
objeto pode possuir e como os eventos (mensagens recebidas,
tempo, erros e condições sendo satisfeitas) afetam estes
estados ao passar do tempo.
O Diagrama
O funcionamento

O diagrama de máquina de estados possuem um ponto de início e

vários pontos de finalização.
Quando o evento acontece, a transição de um estado para outro é
executada ou disparada.
Uma transição de estado normalmente possui um evento ligado a
ela.
Se um evento é anexado a uma transição, esta será executada quando o
evento ocorrer.
Se uma transição não possuir um evento ligado a ela, a mesma ocorrerá
quando a ação interna do código do estado for executada (se existir ações
internas como entrar, sair, fazer ou outras ações definidas pelo
desenvolvedor).
Quando todas as ações forem executadas pelo estado, a
transição será disparada e serão iniciadas as atividades do
próximo estado no diagrama de máquina de estados.
Elementos
Transições e Estados

Os diagramas de máquina de estados são compostos de

transições e estados.
As transições são associadas com ações e são consideradas
como processo de curta duração e não podem ser
interrompidos.
Os estados são associados com as atividades e podem levar mais
tempo. Uma atividade pode ser interrompida por algum evento.
Exemplo
Diagrama de Implantação

O diagrama de implantação determina as necessidades de

hardware do sistema, as características físicas como servidores,
estações, topologias e protocolos de comunicação, ou seja, todo
o aparato físico sobre o qual o sistema deverá ser executado.

Esse diagrama permite demonstrar também como se dará a

distribuição dos módulos do sistema, em situações em que
estes forem ser executados em mais de um servidor.
Diagrama de Implantação
Exercícios
 Exercícios – Diagrama de Máquina de Estados

Locação de Fitas

Desenvolva o Diagrama de Máquina de Estados para o sistema de locadora de fitas para o módulo
de locação de fitas de filmes, enfocando os estados de uma locação, de acordo com os fatos já
apresentados e nas informações descritas abaixo:

Durante o processo de locação de fitas, deve-se verificar se o sócio está cadastrados

Em seguida, deve-se verificar se não há locações pendentes

Caso não haja pendências, deve-se iniciar o registro da nova alocação, bem como de cada item
locado.

Após selecionar todas as cópias desejadas para a locação, esta deve ser finalizada.
 Exercícios – Diagrama de Máquina de Estados

Venda de Passagens Aéreas

Desenvolva o Diagrama de Máquina de Estados para um sistema de venda de passagens aéreas

pela Internet, equivalente ao módulo de compra de passagens por um cliente, enfocando os
estados de um objeto da classe Passagem, levando em consideração os fatos já enunciados dos
execícios e os seguintes fatos adicionais:

Após requisitar os possíveis voos que façam escala nos locais de origem e destino desejados pelo
cliente e caso o horário e o valor de algum dos voos retornados satisfaçam o cliente, então o
cliente selecionará um dos voos na listagem apresentada.

Em seguida o cliente deverá se identifica a após isso selecionar a forma de pagamento através da
qual desejar pagar as passagens.

Finalmente, o cliente poderá confirmar a compra o que fará com que a passagem seja gerada.
 Exercícios – Diagrama de Máquina de Estados

Clínica Veterinária

Desenvolva o Diagrama de Máquina de Estados referente ao processo de marcação de uma nova

consulta de um determinado animal de um cliente, enfocando os estados de um objeto da classe
Consulta, levando em consideração as seguintes características:

Primeiro é necessário identificar o dono do animal que deseja marcar a consulta e em seguida o
animal propriamente dito.

Se for a primeira consulta, um novo tratamento deve ser gerado, antes que a consulta seja
marcada, já que um tratamento pode possuir muitas consultas, mas uma consulta pertence
unicamente a um tratamento.

No caso de se tratar de uma consulta para dar continuidade a um tratamento em andamento é

necessário primeiro selecionar o tratamento em questão.
 Exercícios – Diagrama de Implantação

Locação de Fitas

Desenvolva o Diagrama de Implantação para o sistema de vídeo locadora de acordo com as

seguintes informações:

É necessário existir um módulo principal, cuja função será chamar os outros módulos do sistema.

É necessária também a existência de um módulo para gerenciar os diversos filmes oferecidos pela
locadora. As cópias dos filmes são gerenciadas neste mesmo módulo.

Deve existir ainda um módulo para gerenciar os sócios da locadora

Finalmente é preciso haver um módulo para gerenciar os empréstimos de fitas realizados pela
locadora.
 Exercícios – Diagrama de Implantação

Venda de Passagens Aéreas

Desenvolva o Diagrama de Implantação para o sistema de venda de passagens aéreas pela

Internet levando em consideração as informações abaixo:

A interface de venda de passagens roda na própria máquina do cliente, quando este a acessa
através da Internet.

As solicitações do cliente são retransmitidas pela interface de venda de passagens para o servidor
de comunicação da empresa. As solicitações serão então interpretadas pelo módulo controlador da
página, que as repassará para o módulo de venda de passagens.

O módulo de venda de passagens, juntamente com o módulo responsável por manter os clientes
da empresa, rodam em um servidor de aplicação e se comunicação com um servidor de banco de
dados, que mantêm as informações do sistema, localizado em um servidor de arquivos.

Finalmente há um segundo servidor de aplicação, onde devem rodar os módulos responsáveis por
gerenciar os voos oferecidos pela empresa, bem como as escalas mantidas pela empresa e os
aeroportos onde os voos pousam. Da mesma forma que no primeiro servidor de aplicação, os
módulos deste servidor buscam os dados em um SGBD localizado em um servidor de arquivos.
 Exercícios – Diagrama de Implantação

Clínica Veterinária

Crie o diagrama de Implantação referente ao sistema de clínica veterinária, de acordo com as

seguintes características:

Deve existir um módulo principal, responsável por chamar os outros módulos.

É preciso haver um módulo responsável pela manutenção dos médicos-veterinários que trabalham
na clínica.

Deve haver também um módulo para manter o cadastro de clientes e seus respectivos animais,
bem como os tratamentos e consultas por eles realizados.
Fim