UML CasoUso

3.
Programa do Módulo 2
Orientação a Objetos
SEL3113 – Engenharia de Software
– Conceitos Básicos
– Análise Orientada a Objetos (UML)
•Diagramas UML
•Diagrama de Caso de Uso
– Processo Unificado (RUP)
 JCFJ
3.2
Métodos Orientados a Objetos - MOO

● O paradigma objeto apareceu nos anos 80 como uma solução revolucionária para o
desenvolvimento de software.
● Os MOO tem sua origem ligada ao trabalho de Grady Booch sobre o projeto de
software com a linguagem Ada.

– Software organizado como um grafo, com os arcos representando as relações de utilização
e os nós representando os objetos Relação de herança adicionada posteriormente.
● Trabalhos sobre as linguagens originaram o aparecimento dos trabalhos sobre análise.

● Desde o início dos anos 90 diversos métodos de análise e projeto orientados a objetos
foram propostos.
– Coad e Yourdon: variedade de conceitos e simplicidade;
– G. Booch/J. Rumbaugh: grande número de conceitos e detalhes
• Booch Projeto / Rumbaugh Análise
– Linguagem UML: Padronização Diversos Métodos RUP
 JCFJ
Métodos Orientados a Objetos 3.3
Unified Modeling Language - UML

● UML é uma linguagem padrão para a visualização,
especificação, construção e documentação dos
elementos de um sistema de software.
● UML pode ser utilizado em todas as etapas do ciclo

de desenvolvimento de um sistema de software.
● UML pode ser utilizado com diferentes tecnologias
de implementação.
● UML combina o melhor de:
http://www.uml.org – Conceitos de Modelagem de Dados (Diagramas
Entidade-Relacionamento)
– Modelagem Comercial (work flow)
– Modelagem Objeto
– Modelagem por Componentes
 JCFJ
Porquê UML ?
● Necessidade de uma Linguagem ● Para Documentar
de Modelagem – As necessidades
– Diagramas com notação clara – A arquitetura
– Modelos variados/pontos de vista – A Concepção

– Flexibilidade – A codificação e os testes....
– Linguagem unificadora
● Em diferentes Ambientes de
● Necessidade de um Processo de Sistemas de Informação:
Modelagem (dirigido pelos casos – SI de empresas
de uso) – Sistemas bancários, financeiros
– Modelos e visões integrando a – Telecomunicações, transportes
arquitetura – Aeroespacial, científico
– Interativo e incremental – Eletrônica, médico
– Pode ser adaptado... – Serviços Web
 JCFJ e JP mP
Gênese de UML UML 2.0 2004

Revisão
UML 1.5 2000
Revisão
UML 1.4 2000
Menor
UML 1.3 1999

UML 1.2 1998
Novembro: Aceitação
1997
UML 1.1
Setembro: submissão final UML 1.0
1997
Janeiro: submissão OMG
UML 0.9 1996
Especificação Método
Unificado 0.8 1995
na Internet
Outros OOAD OMT OOSE

Parceiros
Métodos Booch Rumbaugh...
Rumbaugh... Jacobson...
 JCFJ
UML – Contribuições
Rumbaugh Booch Jacobson
Meyer Fusion
Pré e pós Descrição de operações,

condições numeração de mensagens
Harel Embley
State charts Classes Singleton,
vista de alto nível
Gamma, et.al Wirfs-Brock

Frameworks, padrões, Responsabilidades
notas
Shlaer- Mellor Selic, Gullekson, Ward Odell

Ciclo de vida de objetos ROOM (Real-Time Classificação
Object-Oriented Modeling)
 JCFJ
Métodos Orientados a Objetos - UML 3.7
Conceitos de Base
● Mecanismos Comuns: UML define um pequeno número de
mecanismos comuns que garantem a integridade conceitual da
notação:
– Notas
– Mecanismos de Extensão: Estereótipos, Restrições e Etiquetas
– Relações de Dependência
● Nota: é um símbolo gráfico que contém informações, um comentário, sobre um

elemento, geralmente em forma textual Cada nota é ligada a um elemento de
modelagem por uma linha tracejada.
Nota
 JCFJ
Métodos Orientados a Objetos – UML – Conceitos de Base – Mecanismos Comuns 3.8
● Mecanismos de Extensão:
– Estereótipo: é um mecanismo de extensibilidade de UML, permitindo uma
meta-classificação de um elemento de UML. <<Comprador>>
Cliente
• Possibilita aos usuários adicionar novos tipos de elementos de modelagem,
permitindo uma extensão controlada, pelos usuários, dos elementos de UML.
• Um elemento do modelo associado a um estereótipo herda as definições do
estereótipo
• Pode-se definir estereótipos para classes, associações, operações, estados, pacotes,
etc. Objetivo: classificar estes elementos e reutilizar as descrições
• O nome do estereótipo é colocado entre guillemets antes do nome do elemento ao
qual é aplicado o estereótipo.
– Restrições: é uma relação semântica qualquer entre elementos de modelagem
Informação
definindo proposições que devem ser mantidas verdadeiras para garantir a
validade do sistema modelado.
• Pode-se usar linguagem natural, pseudo-código ou OCL (linguagem formal)
• UML não especifica nenhuma sintaxe particular para as restrições. {ou-exclusivo}
• Uma restrição é definida por uma expressão booleana entre parênteses aplicada E-mail
CEP
a um elemento
 JCFJ
Métodos Orientados a Objetos - UML - Conceitos de Base – Mecanismos Comuns 3.9
– Etiquetas: é um par (nome, valor) que adiciona uma

nova propriedade a um elemento de modelagem, Pessoal
permitindo a extensão dos atributos destes elementos.
{Autor=JCFJ
• A propriedade pode representar uma informação de Versão=2.1
Data=10/04/02}
administração (autor, data, etc.), de geração de código.
• A adição de uma etiqueta é feita da seguinte maneira:

{nome = valor}.
● Relações de Dependência: define uma relação de
utilização unidirecional entre dois elementos de
Elemento Fonte
modelagem, chamados respectivamente fonte e alvo
da relação.
– Indicam uma situação em que uma mudança no
elemento alvo acarreta uma mudança no elemento
Elemento Alvo
fonte.
– Representada por uma flecha pontilhada do elemento
fonte para o elemento alvo.
 JCFJ
Pacotes
● Oferecem um mecanismo geral para a partição de modelos e para
o reagrupamento de elementos de modelagem, assim como para o
encapsulamento destes.
Nome do
● Cada pacote corresponde a um sub-conjunto do modelo e contém, Pacote

segundo o modelo, classes, objetos, relações, componentes ou
nós, assim como os diagramas associados.
● Elementos em pacotes diferentes podem ter o mesmo nome.
● Cada pacote é um reagrupamento de elementos segundo um <<Categoria>>
critério puramente lógico.
● Dois estereótipos podem ser aplicados:
– <<Categoria>>: pacotes ligados a uma visão lógica Aspectos
estáticos dinâmicos do sistema.
<<Sub-Sistema>>
– <<Sub-sistema>>: pacotes ligados a uma visão de implementação
Organização dos módulos no ambiente de desenvolvimento.
 JCFJ
Métodos Orientados a Objetos - UML - Pacotes 3.11
● A forma geral de um sistema (arquitetura) é expressa pela

hierarquia de pacotes e pela rede de relações de
dependência entre pacotes. Fornecedor
● Um pacote pode conter outros pacotes, sem limite de níveis,

e um nível pode conter pacotes e outros elementos de
modelagem (Ex.: classes).
● O relacionamento entre pacotes é representado através de
uma relação de dependência orientada do pacote cliente em
direção do pacote fornecedor Esta relação entre os dois
pacotes significa que ao menos uma classe de um pacote
cliente utiliza serviços oferecidos por ao menos uma classe Cliente
do pacote fornecedor.
 JCFJ
3.12
Conteúdo de Pacotes
● Um Pacote, University Artifacts, contém outro pacote e cinco
classes.
Student Professor
Artifacts
University
Artifacts Course Schedule
Student CourseOffering
 JCFJ
Métodos Orientados a Objetos - UML - Pacotes 3.13
Pacotes - Exemplos
 UML pour l’analyse d’un système d’information

C. Morley, J. Hugues, B. Leblanc - DUNOD
 JCFJ
Diagramas UML 2.0 - I

● Diagramas de Casos de Uso: representam as funções do sistema do ponto de vista do usuário.
● Diagramas de Classes: representam a estrutura estática em termos de classes e relações.
● Diagramas de Objetos: representam os objetos e suas relações Correspondem a diagramas de
colaboração simplificados, sem a representação do envio de mensagens.
● Diagramas de Interação: utilizados para capturar os cenários:

– Diagramas de Seqüência: representação temporal dos objetos e suas interações.
– Diagramas de Colaboração (Comunicação): representação espacial dos objetos, das
relações e das interações.
● Diagramas de Estado: representam o comportamento de uma classe em termos de estados.
● Diagramas de Atividades: representam o comportamento de uma operação em termos de ações.
● Diagramas de Componentes: representam os componentes físicos de uma aplicação.
● Diagramas de Instalação: representam a distribuição dos componentes nos dispositivos de
hardware.
● Diagramas de Pacotes: representam os pacotes do sistema com ou sem seus constituintes.
● Diagramas de Visão Geral de Interação: composição de diagramas de atividades e seqüência,
nos quais as atividades são substituídas por pequenos diagramas de seqüência
● Diagramas de Temporização: representam restrições de temporização, constituem uma outra
forma dos diagramas de interação.
● Diagramas de Estruturas Compostas: representam a decomposição hierárquica de uma classe
em sua estrutura interna.
UML 1.5 UML 2.0
 JCFJ
Diagramas UML 2.0 - II

“20% da UML resolve 80% dos
problemas” – Jacobson.
Diagramas
Estruturas Pacotes Classes Objetos Seqüência Comunicação Atividades

Compostas
Visão Geral
Temporização Caso de Uso Estado Componentes Instalação
da Interação
 JCFJ e JP mP

Diagramas
Estruturas Pacotes Classes Objetos Seqüência Comunicação Atividades

Compostas
Visão Geral
Temporização Caso de Uso Estado Componentes Instalação
da Interação
 JCFJ e JP mP

Diagramas
Classes Objetos Seqüência Comunicação Atividades
Diagramas UML 1.5.
Caso de Uso Estado Componentes Instalação
 JCFJ e JP mP
Métodos Orientados a Objetos – UML – Diagramas UML 3.18
Diagramas
Diagramas UML 1.5.
Aspectos funcionais e dinâmicos:

Diagrama de Caso de Uso: atores, utilização do sistema.
Aspectos estruturais estáticos:
Diagrama de Classes : classes e relações estáticas.
Diagrama de Objetos: objetos e associações.
 JCFJ e JP mP
Diagramas
Aspectos dinâmicos:
Diagrama de Seqüência: visão temporal das interações.
Diagrama de Comunicação (colaboração): visão espacial das interações.
Diagrama de Estados: comportamento dos objetos.
Diagrama de Atividades: fluxo de controle interno das operações, descrição dos
casos de uso.
 JCFJ e JP mP
Diagramas
Aspectos implantação:
Diagrama de Componentes: codificação.
Diagrama de Instalação: implantação, distribuição.
 JCFJ e JP mP
SEL3113 – Engenharia de Software Métodos Orientados a Objetos – UML – Diagramas UML 3.21
Analisar através de Casos de Uso,

Casos de Uso (Diagramas de Atividades),
Cenários: Colaboração e Seqüência 
 JCFJ
Comportamento do Sistema
● Todo sistema interage com pessoas ou outros sistemas Esta interação
resulta em um resultado previsível Seu Comportamento.
● O Comportamento do Sistema é a maneira pela qual este age e reage e

engloba as ações e atividades do sistema.
● Em UML o Comportamento do Sistema é capturado com Casos de Uso.
Uso
– Casos de Uso descrevem a interação entre o sistema e o ambiente ou partes
do ambiente.
 JCFJ
Métodos Orientados a Objetos – UML 3.23
Diagramas de Casos de Uso (Use Cases) – I

● Idéia de Ivar Jacobson sendo um modelo que descreve os Requisitos Funcionais de um
sistema em termos de Casos de Uso.
● Um modelo que apresenta as funcionalidades do sistema (Casos de Uso) e o ambiente
que interage com o sistema (Atores).
View Report Card
Register for Courses
Student
Login
Diagramas de Caso de Uso descrevem através de ações e reações, o comportamento de um

sistema do ponto de vista dos usuários, possibilitando a definição dos limites de um sistema
e das relações entre o sistema e o ambiente.
 JCFJ & JP mP &
Diagramas de Casos de Uso (Use Cases) – II

● Permitem aos usuários estruturar e articular seus desejos:
– Definição da maneira através da qual eles irão interagir com o sistema;
– Determinação das informações que serão manipuladas;
– Descrição do que deve ser feito para se obter o resultado esperado.
● Casos de uso são utilizados em todo o ciclo de vida de um sistema, desde a

análise dos requisitos até a implementação Após a aprovação do modelo pelo
cliente tem-se definido o que o sistema faz e o que o cliente quer O modelo pode
ser usado então ao longo do desenvolvimento para as discussões com o cliente.
● Utilização:
– Participantes: entendimento do sistema.
– Projetistas: base para seu trabalho e como uma visão geral (overview) do sistema.
– Testadores: como uma base para a geração das atividades de teste o mais cedo possível.
– Escritores de Documentação: como uma base para a escrita dos manuais de usuários.
– Arquitetos: modelo a partir do qual se pode identificar funcionalidades arquiteturais
significativas.
– ...
 JCFJ & JP mP &

Diagramas de Casos de Uso (Use Cases) – III

● O formalismo dos casos de uso, baseado na utilização da linguagem natural, é
naturalmente acessível aos usuários, facilitando a comunicação Cliente
Desenvolvedor.
● Um caso de uso é utilizado na representação dos requisitos do sistema

– Representa uma maneira específica de utilizar um sistema;
– Constitui a imagem de uma funcionalidade do sistema, ativada em resposta a um estímulo
de um agente externo.
● Diferentes níveis de atores (principal, secundário, hardware, sistema)
● Relações (comunicação, uso, extensão)
● Componentes:
– Ator: representa um papel interpretado por uma pessoa ou algo que interage com o
sistema.
– Casos de Uso: modelam um diálogo entre os atores e o sistema, representando as
funcionalidades que serão oferecidas aos atores pelo sistema A coleção dos casos de uso
de um sistema representa todas as maneiras através das quais o sistema pode ser
utilizado.
 JCFJ e JP mP
Métodos Orientados a Objetos - UML – Diagramas de Casos de Uso 3.26
Benefícios do Diagrama de Casos de Uso
● Comunicação
● Identificação
Caso de Uso
● Verificação
Identificação
Comunicação Verificação
Usuário Especialista do
Final Domínio Usuários
 JCFJ
O que é um Ator?
● Atores representam papéis que os usuários do sistema podem
desempenhar Podem representar uma pessoa, uma
máquina, ou outro sistema.
● Eles podem realizar um intercâmbio de informações com o

sistema.
● Eles podem fornecer informações ao sistema.
● Eles podem ser um recipiente passivo de informações.
● Eles são determinados através da observação dos usuários
diretos do sistema, daqueles responsáveis por sua utilização e
por sua manutenção, assim como dos sistemas que interagem
com o sistema sendo desenvolvido Atores são descritos Ator
por pequenos textos em linguagem natural.
● Atores não fazem parte do sistema, eles são Externos ao
sistema.
 JCFJ
O que é um Caso de Uso?

● É uma seqüência de ações que o sistema realiza e que conduzem a um resultado
observável para um ator em particular.
● Um caso de uso modela O QUÊ o sistema deve fazer e não Como.
● Um caso de uso modela um diálogo entre um ou mais atores e o sistema.

● Um caso de uso descreve as ações que o sistema toma para entregar algo de valor
para o ator.
● Casos de uso servem para modelar o comportamento de um elemento, sistema, sub-
sistemas, classe.
● Casos de uso podem ser apresentados com diferentes estereótipos: normal, lógica de
negócio, realização, etc.
● Um caso de uso tem uma série de propriedades que inclui: breve descrição, fluxo de
eventos, requisitos especiais, diagramas de atividades, etc.
Caso de Uso
 JCFJ
Casos de Uso e Atores

● Um caso de uso modela um diálogo entre atores e o sistema.
● Um caso de uso é iniciado por um ator para invocar uma funcionalidade do sistema
Um caso de uso pode iniciar uma comunicação com um ator, normalmente neste caso
um ator “não humano”.

● Atores podem se conectar a casos de uso UNICAMENTE por associações
Associações indicam que atores e casos de uso se comunicam, cada um deles podendo
enviar e receber mensagens.
● A seta na ponta da associação é opcional e indica simplesmente QUEM inicia a
comunicação.
Caso de Uso
Associação
Ator
 JCFJ
Como você leria este Diagrama?

View Report Card
Maintain Professor
Information
Register for Course Catalog

Courses
Maintain Student
Student Information
Login
Registrar
Close Registration
Select Courses to
Teach
Professor Submit Grades Billing System
● De que casos de uso um Student participa? E um ● Descreva os relacionamentos dos casos

Professor? E o Course Catalog? de uso Close Registration e Select
● Se Charlie for um estudante e professor, que Courses to Teach.
casos de uso ele executa? ● Qual caso de uso precisa ser executado
● Descreva a funcionalidade deste sistema. primeiramente, Register for Courses ou
View Report Card?
 JCFJ
Exemplo 1: Reservar um vôo em uma data precisa
● O cliente interroga o sistema, seja passando em uma agência, seja via internet, para
garantir que ele pode fazer a reserva desejada.
● A reserva pode ser feita para um transporte de passageiros (um ou diversos) ou para o
transporte de carga.
● Uma solução sendo encontrada, o sistema registra a reserva (nome do(s) passageiro(s)
e/ou característica da(s) carga(s)) e realiza o pagamento através do meio que convier
ao cliente (dinheiro, cheque, cartão de crédito).
● O ou os bilhetes correspondentes são entregues, diretamente na agência, pelo correio,
ou disponibilizados na aeroporto.
Informação é atachada
a todo UC, para definir
Seu papel e conteúdo
Reservar
Cliente
 JCFJ e JP mP
Exemplo 1 – Requisitos
(Sistema) RESERVAR
Interrogar no guichê
Interrogar possibilidade-vôo
Interrogar via internet
Generalização/Especialização segundo o “modo de acesso”
Cliente
Componentes são somente

os elementos presentes na
análise de requisitos Visão Análise de Requisitos:
Um ator, o cliente
O UC RESERVAR decomposto como pacote-diagrama de UC RESERVAR
 JCFJ e JP mP
(Sistema) RESERVAR
Registrar reserva
Cliente
Visão Análise de Requisitos
 JCFJ e JP mP
(Sistema) RESERVAR
Registrar reserva Especialização segundo

Registrar carga o objeto do transporte
Cliente
Registrar passageiros
 JCFJ e JP mP
(Sistema) RESERVAR
Registrar reserva
Registrar carga
Cliente
Pagar Registrar passageiros
 JCFJ e JP mP
(Sistema) RESERVAR
Registrar reserva
Registrar carga
Cliente
Caso de Uso em
diversos níveis
Pagar Registrar passageiros O Caso de Uso é
representado como
um Pacote
Obter bilhetes
Ativação do sistema
 JCFJ e JP mP
Exemplo 1 – Análise
(Sistema) RESERVAR
Gestor dos vôos
Gestor interface
Sub-sistemas externos
Cliente Adiciona-se os Visão Análise

componentes descobertos (refinamento)
no processo de análise
especificação
 JCFJ e JP mP
(Sistema) RESERVAR
Gestor dos vôos
Registrar carga
Registrar reserva
Gestor interface
Pagar
Gestor financeiro
Cliente Visão Análise
 JCFJ e JP mP
(Sistema) RESERVAR
atores Gestor dos vôos
secundário
Registrar carga Atores

secundários
Registrar reserva
Gestor interface
principal Pagar
Obter bilhetes Gestor financeiro

Cliente Visão Análise
 JCFJ e JP mP
Relações nos Diagrama de Caso de Uso – I

● Inexistência de relação de Composição-Decomposição: (para o refinamento) mas um UC se descreve
em detalhes através de um pacote associado ao UC a detalhar Este pacote é descrito por Diagramas de
UC que definem o conteúdo do pacote (T3.36).
<<include>>
● Inclusão « include »: (para a reutilização) A inclui B

e lhe utiliza Relação de dependência entre UC de
Caso de Uso A Caso de Uso B
um mesmo diagrama O UC, incluso, pode ser utilizado
em outros diagramas; (exemplo tipo: Validar e Registrar pedido)
● Extensão « extend »: (para a extensibilidade) B estende A, <<extend>>
em ... Relação de dependência entre UC de um mesmo

diagrama O UC, que “estende”, deve ter um ponto Caso de Uso A Caso de Uso B
de inserção no UC “estendido”; (exemplo:
“Consultar as promoções”)
● Generalização : (para os mecanismos de herança e versões) relação hierárquica (uma especialização

garante a função do UC pai) que possibilita que se tenha diversos ambientes com o mesmo objetivo.
(exemplo : Interrogar no guichê e Interrogar via Internet)
 JCFJ e JP mP
Relações nos Diagrama de Caso de Uso – II [FK02]
● Deve-se utilizar Inclusão quando um comportamento estiver sendo

utilizado em dois ou mais casos de uso diferentes.
● Deve-se utilizar Generalização quando se deseja descrever, sem muito

rigor, uma variação do comportamento normal de um caso de uso.
● Deve-se utilizar Extensão quando se deseja descrever com rigor,

declarando o que pode ser estendido, uma variação do comportamento
normal de um caso de uso.
 JCFJ
include e extend – Definição UML 2.0

● include:
– Uma relação de um caso de uso de base para um caso de uso de inclusão,
especificando como o comportamento do caso de uso de base contém o
comportamento do caso de uso de inclusão. O comportamento é inserido no local

onde é definido no caso de uso de base. O caso de uso de base depende da
execução do comportamento do caso de uso de inclusão, mas não de sua
estrutura (i.e., atributos ou operações).
● extend
– Um relacionamento de um caso de uso de extensão para uma caso de uso de base,
especificando como o comportamento definido para o caso de uso de extensão
aumenta (sujeito a condições especificadas na extensão) o comportamento
definido para o caso de uso de base. O comportamento é inserido no local
definido pelo ponto de extensão no caso de uso base. O caso de uso base não
depende da execução do comportamento do caso de uso de extensão.
 JCFJ
Exemplo 1 – Projeto
Sistema de Reserva
Sub-sistema Gestão de reservas

Tele-sistema
Agência
<<include>>
Validar pedido
<<include>>
Reservar Adiciona-se os
componentes
Agente de reserva descobertos no
Registrar
<<include>> processo de projeto
<<include>> pedido
Cliente
Editar bilhetes Gerir Registrar Registrar

pagamentos passageiros carga
 JCFJ e JP mP
Exemplo 1 – Extensão: Sistemas Evolutivos
1. O caso de uso Consultar as promoções estende o caso de

uso Interrogar via internet.
2. A extensão é permitida unicamente para algumas
funcionalidades.
3. O pontos de inserção, que definem o que pode ser
estendido, são declarados no caso de uso base e na
associação entre os casos de uso.
4. Um caso de uso pode ter vários pontos de extensão e um
Pontos de extensão caso de uso de extensão pode aumentar um ou mais
. Pacotes destes pontos de extensão.
. Viagens Nacionais Fonte: [FK02]
<<extend>>
(Pacotes, Viagens Nacionais)
Consultar as promoções
 JCFJ e JP mP
Descrição dos Casos de Uso

MODELO
X: Fluxo de eventos para o caso de uso <nome do caso de uso>;
X.1 Breve Descritivo
X.2: Pré-condições: condições que devem ser verificadas para que o caso de uso possa ser iniciado;
X.3 Atores Envolvidos
X.4: Fluxo principal;

X.5: Sub-fluxos (quando se puder aplicar);
X.6: Fluxos alternativos.
APLICAÇÃO AO CASO DE USO GERIR PAGAMENTOS

Fluxo de eventos para o caso de uso Gerir Pagamentos
1.1 Descrição: este caso de uso aborda a gestão de pagamentos.
1.2: Pré-condições: para que este caso de uso seja executado o caso de uso Reservar já deve ter
sido executado.
1.3 Atores Envolvidos: Cliente, Agente de Reserva.
1.4: Fluxo principal:
Este caso de uso se inicia quando um pagamento tiver que ser realizado. Caso o meio de pagamento
não apresente fundos (E1) o caso finaliza. Pode-se escolher entre pagar com cartão (CARTAO) ou
cheque (CHEQUE). Se for escolhido CARTAO o sub-fluxo S1-Pagar com Cartao será executado .......
1.5: Sub-fluxos
S1-Pagar com cartao: o sistema apresenta uma janela para entrada dos dados e o .......
1.6: Fluxos alternativos
E1: o meio de pagamento do cliente apresenta problemas e portanto......
 JCFJ
Diagrama de Atividades
● Um Diagrama de Atividades pode ser utilizado para capturar as atividades e ações
realizadas em um caso de uso Descrição gráfica do fluxo de eventos.
● É essencialmente um diagrama de fluxo que mostra o fluxo de controle de uma
atividade ou ação para outra.
● Ele será introduzido aqui e detalhado futuramente para outras utilizações.

APLICAÇÃO AO CASO DE USO GERIR PAGAMENTOS
Fluxo de eventos para o caso de uso Gerir Pagamentos

1.1 Descrição: este caso de uso aborda a gestão de pagamentos.
1.2: Pré-condições: para que este caso de uso seja executado o caso de
uso Reservar já deve ter sido executado.
1.3 Atores Envolvidos: Cliente, Agente de Reserva. S1
Este caso de uso se inicia quando um pagamento tiver que ser realizado.
Caso o meio de pagamento não apresente fundos (E1) o caso finaliza.
Pode-se escolher entre pagar com cartão (CARTAO) ou cheque (CHEQUE).
Inicialização S2
Se for escolhido CARTAO o sub-fluxo S1-Pagar com Cartao será
executado .......
1.5: Sub-fluxos
S1-Pagar com cartao: o sistema apresenta uma janela para entrada dos
dados e o .......
E1: o meio de pagamento do cliente apresenta problemas e portanto......
 JCFJ &
Métodos Orientados a Objetos – UML – Diagramas de Atividades 3.47
O que é uma Atividade?

● O comportamento é expresso como um fluxo de execução via seqüenciamento de
unidades subordinadas Unidades subordinadas incluem atividades aninhadas e em
último nível ações individuais.
● Ações constituem atividades primitivas que podem ser compreendidas como a menor
unidade computacional que pode ser apresentada.
● Atividades e Ações podem conter expressões com restrições booleanas que restringem
seu início e término Atividades: <<Precondition>> e <<Postcondition>> e Ações:
<<localPrecondition>> e <<localPostcondition>>.
Atividade p
<<Precondition>> Atividade n
Restrição Booleana
<<Postconditon>>
Atividade m Restrição Booleana
 JCFJ
Métodos Orientados a Objetos – UML – Diagramas de Atividades 3.48
Diagrama de Atividades: Exemplo

Decisão
Select Course Atividade/Ação
Processamento
Concorrente
[ delete course ]
Delete Course
[ add course ]
Barra de
Sincronização (Fork)
Check Check
Schedule Pre-requisites
Sentinela
Barra de
[ checks completed ] [ checks failed ] Sincronização (Join)
Assign to Resolve
Course Conflicts
Transição
Update
Schedule
 JCFJ
Revisão
● O que é Comportamento do Sistema?
● O que é um Diagrama de Caso de Uso? Quais são seus
benefícios?
● O que é um Ator? Um Caso de Uso?

● O que é um Diagrama de Atividades?
 JCFJ
Exercício: Sistema de Controle de Pedidos

Uma empresa pretende desenvolver um Sistema de Informação para a gerência
dos pedidos recebidos pela empresa. Este sistema de informação deve ser capaz de
controlar o cadastro dos clientes, dos pedidos e dos produtos com todas as
funcionalidades características (inclusão, alteração, supressão). Para realizar qualquer operação

com o sistema o funcionário deve ter realizado o login no sistema. No sistema um login é
caracterizado por um username e uma password. Os Clientes que serão gerenciados pelo SI
podem ser do tipo Cliente Corporativo ou Cliente Pessoal. Cada Cliente pode estar associado a
diversos Pedidos, mas um Pedido está associado unicamente a um Cliente. Um Pedido é
composto por diversas Linhas de Pedido e cada Linha de Pedido logicamente só pode fazer parte
de um único Pedido. As linhas de Pedido nascem e morrem com os Pedidos. Cada Linha de
Pedido está associada a unicamente um Produto, mas um Produto pode estar associado a diversas
Linhas de Pedido. Clientes Corporativos são definidos por um código, um nome, um endereço,
um nome de contato, uma classe de crédito e um limite de crédito. Clientes Pessoais são definidos
por um código, um nome, um endereço, e um número de cartão de crédito. Um Pedido é definido
por uma data, um preço e um número. Cada Linha do Pedido é definida por uma quantidade e um
preço e cada Produto é definido por um código, uma descrição e um preço.
 JCFJ
Métodos Orientados a Objetos – UML - Exercício: Sistema de Controle de Pedidos 3.51
Diagramas de Casos de Uso – I

 JCFJ
Diagramas de Casos de Uso – II

Fluxo de eventos para o caso de uso Inserir Cliente
1.1 Descrição: este caso de uso aborda o procedimento adotado para o cadastro de clientes no sistema.
1.2: Pré-condições: para que este caso de uso seja executado o caso de uso Logar deve ter sido
executado; o funcionário já deve ter feito o login no sistema.
1.3 Atores Envolvidos: Funcionário.

Este caso de uso se inicia quando o funcionário se loga no Sistema de Registro e entre seu/sua senha. O
sistema verifica se a senha é válida (E-1) e solicita ao funcionário que defina o tipo de cliente a ser
cadastrado, Corporativo ou Pessoal. O funcionário entra o tipo desejado: Corporativo (CC) ou Pessoal
(CP). Se o tipo de cliente for Corporativo (CC), o sub-fluxo S-1: Adicionar Cliente Corporativo será
executado. Se o tipo de cliente for Pessoal (CP), o sub-fluxo S-2: Adicionar Cliente Pessoal será
executado.
1.5: Sub-fluxos
S1-Inserir Cliente Corporativo: o sistema apresenta uma janela para entrada dos seguintes dados, código
(E2), nome, endereço, nome de contato, classe de crédito e limite de crédito. O funcionário salva os dados
e o caso de uso reinicia.
S2-Inserir Cliente Pessoal: o sistema apresenta uma janela para entrada dos seguintes dados, código (E2),
um nome, um endereço, e um número de cartão de crédito. O funcionário salva os dados e o caso de uso
reinicia.
E1: um usuário ou senha inválido foi fornecido. O funcionário pode fornecer novamente o username e
senha ou terminar o caso de uso
E2: houve uma tentativa de cadastro de um cliente já cadastrado. A situação é informada e o caso de uso
se reinicia.
 JCFJ
Diagrama de Atividades
Caso de Uso
Inserir Cliente
 JCFJ
Bibliografia
● [FK02] Martin Fowler e Kendall Scott, UML Essencial – 2 ª Edição, Bookman, 2002.
● [FOO04] Martin Fowler, UML Essencial – 3 ª Edição, Bookman, 2004.
● [MED04] Ernani Medeiros, Desenvolvendo Software com UML2.0, Pearson – Makron

Books, 2004
● [IBM04] IBM Corporation, Essentials of Visual Modeling with UML 2.0, Material
disponibilizado através do programa University da IBM.
● [UML04] Object Management Group – OMG, UML 2.0: Infrastructure Specification,
http://www.uml.org/#UML2.0, Acessado em 04/2004.
 JCFJ

UML CasoUso

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 CasoUso

Enviado por

Direitos autorais:

Formatos disponíveis

3.

– Processo Unificado (RUP)

Métodos Orientados a Objetos - MOO

software com a linguagem Ada.

● Trabalhos sobre as linguagens originaram o aparecimento dos trabalhos sobre análise.

Unified Modeling Language - UML

● UML pode ser utilizado em todas as etapas do ciclo

Métodos Orientados a Objetos 3.4

– Modelos variados/pontos de vista – A Concepção

Gênese de UML UML 2.0 2004

UML 1.3 1999

UML 0.9 1996

Outros OOAD OMT OOSE

Métodos Orientados a Objetos 3.6

Pré e pós Descrição de operações,

Gamma, et.al Wirfs-Brock

Shlaer- Mellor Selic, Gullekson, Ward Odell

● Nota: é um símbolo gráfico que contém informações, um comentário, sobre um

Métodos Orientados a Objetos – UML – Conceitos de Base – Mecanismos Comuns 3.8

– Etiquetas: é um par (nome, valor) que adiciona uma

• A adição de uma etiqueta é feita da seguinte maneira:

Métodos Orientados a Objetos - UML 3.10

● Cada pacote corresponde a um sub-conjunto do modelo e contém, Pacote

● A forma geral de um sistema (arquitetura) é expressa pela

● Um pacote pode conter outros pacotes, sem limite de níveis,

 UML pour l’analyse d’un système d’information

Métodos Orientados a Objetos - UML 3.14

Diagramas UML 2.0 - I

● Diagramas de Interação: utilizados para capturar os cenários:

Diagramas UML 2.0 - II

Estruturas Pacotes Classes Objetos Seqüência Comunicação Atividades

Métodos Orientados a Objetos - UML 3.16

Diagramas UML 2.0 - II

Estruturas Pacotes Classes Objetos Seqüência Comunicação Atividades

Diagramas UML 2.0 - II

Classes Objetos Seqüência Comunicação Atividades

Diagramas UML 1.5.

Caso de Uso Estado Componentes Instalação

Métodos Orientados a Objetos – UML – Diagramas UML 3.18

Classes Objetos Seqüência Comunicação Atividades

Caso de Uso Estado Componentes Instalação

Aspectos funcionais e dinâmicos:

Classes Objetos Seqüência Comunicação Atividades

Caso de Uso Estado Componentes Instalação

Métodos Orientados a Objetos – UML – Diagramas UML 3.20

Classes Objetos Seqüência Comunicação Atividades

Caso de Uso Estado Componentes Instalação

Analisar através de Casos de Uso,

Métodos Orientados a Objetos – UML – Diagramas UML 3.22

● O Comportamento do Sistema é a maneira pela qual este age e reage e

Diagramas de Casos de Uso (Use Cases) – I

que interage com o sistema (Atores).

View Report Card

Register for Courses

Diagramas de Caso de Uso descrevem através de ações e reações, o comportamento de um

 JCFJ & JP mP &

Métodos Orientados a Objetos – UML 3.24

Diagramas de Casos de Uso (Use Cases) – II

● Casos de uso são utilizados em todo o ciclo de vida de um sistema, desde a

 JCFJ & JP mP &

Diagramas de Casos de Uso (Use Cases) – III

● Um caso de uso é utilizado na representação dos requisitos do sistema