III Modelagem de Processos Unidade III

Prévia do material em texto

76
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Unidade III
5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO)
5.1 Introdução
Na abordagem de análise da UML, a visão de modelo comportamental representa o sistema do ponto 
de vista dos comportamentos e interações do sistema com o usuário. Os diagramas que modelam o 
comportamento de um sistema da UML são:
• diagrama de caso de uso (use case): é um diagrama de uso geral para as fases de levantamento e 
análise de requisitos do sistema;
• o diagrama de estados ou máquina de estados: que procura acompanhar as mudanças sofridas 
por um objeto dentro de um processo no tempo;
• o diagrama de atividades: que descreve os passos a serem percorridos para a conclusão de uma atividade.
• os diagramas de interação: que são dividios em:
— diagrama de sequência: diagrama que descreve a ordem temporal em que as mensagens são 
trocadas entre os objetos;
— diagrama geral interação: é uma variação dos diagramas de atividades que fornece visão geral 
dentro do sistema ou processo do negócio;
— diagrama de comunicação: associado ao diagrama de sequência, complementando-o e 
concentrando-se em como os objetos estão vinculados.
— diagrama de tempo: diagrama que descreve a mudança de estado ou condição de uma instância 
de uma classe, ou seu papel durante o tempo.
Esta unidade abordará os principais diagramas comportamentais da UML.
 Lembrete
A UML propõe 13 diagramas que cobrem as estruturas estáticas e os 
comportamentos de um aplicativo ou sistema de software. Nesta unidade, 
somente serão abordados os diagramas denominados comportamentais.
77
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
5.2 Modelo de casos de uso
O caso de uso nos modelos da UML é um elemento que descreve como um usuário do sistema 
proposto interage com o sistema para realizar uma determinada tarefa discreta.
Ele descreve e significa uma interação simples, a todo o tempo, que tenha significado para o usuário 
(uma pessoa, uma máquina ou outro sistema).
Um caso de uso, de acordo com a UML:
• tipicamente, tem requisitos e restrições que descrevem as facilidades e regras sobre as quais ele 
opera;
• pode ter um diagrama associado (diagrama de sequência ou de atividades) que ilustre seus 
comportamentos ao longo do tempo: quem faz o quê, para quem e quando.
• tipicamente, tem cenários associados com ele e que descrevem o fluxo de trabalho durante todo 
o tempo que realiza suas tarefas, até produzir os resultados finais.
• a especificação da OMG UML afirma: “um caso de uso é um tipo de classificador de comportamento 
que representa uma declaração de um comportamento oferecido”.1
Cada caso de uso especifica alguns comportamentos, possivelmente incluindo variantes, as quais 
pode executar em colaboração com um ou mais atores.
 Lembrete
Os elementos de casos de uso são utilizados para construir modelos de 
caso de uso. Eles descrevem a funcionalidade do sistema a ser construído, 
os requisitos, as restrições e como o usuário interage com o sistema.
Muitas vezes, os diagramas de sequência são associados com casos de uso para capturar o fluxo de 
trabalho e o comportamento do sistema.
5.2.1 Diagramas de caso de uso
O diagrama ou modelo de casos de uso mostra o que existe fora do sistema (atores) e o que pode ou 
deve ser executado pelo sistema (casos de uso).
Os casos de uso são importantes, pois provêm uma ferramenta para capturar os requisitos do sistema, 
ou seja, o que o sistema necessita disponibilizar para possibilitar a execução das atividades do negócio.
1 UML Superestrutura Especificação, versão 2.1.1, p. 592.
78
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
O conjunto de casos de uso do sistema representa a funcionalidade desse, isto é, a totalidade de 
maneiras de se utilizar o sistema.
Um diagrama de caso de uso é um gráfico de:
• atores;
• conjunto de casos de uso do sistema, encapsulados pela fronteira desse;
• a associação entre os atores e os casos de uso utilizados por eles; e
• os eventuais relacionamentos entre os próprios casos de uso.
A figura 41 mostra um exemplo de um diagrama típico de casos de uso.
uc Use Case Model
Faz login
Registra 
Usuário
<<extend>>Usuário
Figura 41 – Diagrama ou modelo de casos de uso
5.2.1.1 Atores
Os atores representam toda a necessidade de troca de informação com o sistema. Eles constituem, 
portanto, o ambiente do sistema (seres humanos, máquinas, agrupamentos lógicos, outros sistemas).
A diferença entre atores e usuários é que um ator representa certa regra que um usuário pode utilizar 
na interação com o sistema, e o usuário é a pessoa que está usando aquela regra, naquele momento.
Dentro da tecnologia OO, o ator é uma classe, enquanto o usuário é uma instância daquela classe. 
A instância existe apenas enquanto o usuário está fazendo algo no sistema, portanto, o mesmo usuário 
pode ser instância de vários atores no sistema.
79
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
A figura 42 mostra a notação de Ator na UML.
Cliente
Figura 42 – Notação de ator
O ícone padrão do estereótipo do ator é a figura do stick man. O nome do ator deve ser sempre um 
substantivo no singular, por exemplo: cliente, professor, operador etc.
 Observação
A especificação da OMG UML2 afirma:
Um ator modela um tipo de papel desempenhado por uma entidade 
que interage com o sistema (por exemplo, intercâmbio de dados e sinais), 
mas que é externo ao sistema.
Atores podem representar papéis desempenhados por usuários humanos, de hardware externo ou 
de outros sistemas.
Note que um ator não representa, necessariamente, uma entidade física específica, mas apenas uma 
faceta particular (isto é, “papel”) de alguma entidade que é relevante para a especificação de seus casos 
de uso associados.
 Saiba mais
Vale a pena fazer download do manual da OMG Unified Modeling 
Language (OMG UML), o Infrastruture versão 2.3, que se encontra gratuitamente 
disponível em: <http://www.omg.org/spec/UML/2.3/Infrastructure>, e possui 
todas as definições e características dos modelos da UML.
Assim, uma única instância física pode desempenhar o papel de vários atores diferentes e, 
inversamente, um determinado ator pode ser jogador de várias instâncias diferentes.
5.2.2.2 Casos de uso
Uma instância de um ator desencadeia a execução de um caso de uso no sistema. Na UML, um caso 
de uso é representado por uma elipse com seu nome em texto dentro.
2 UML Superestrutura Especificação, versão 2.1.1, p. 584.
80
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A figura 43 mostra um exemplo da notação de caso de uso na UML.
Receber 
Pagamento
Figura 43 – Notação de caso de uso
Um caso de uso é, portanto, um conjunto de transações, executadas em uma determinada sequência, 
em diálogo com o sistema.
Além disso, um caso de uso pode ser visto como uma classe de objetos, devido ao fato de possuir 
propriedades e comportamentos. Quando se inicia um caso de uso, se está instanciando a classe: caso de uso.
Cada instância dessa classe é chamada de cenário. Cada cenário retrata a sequência de interações 
entre atores (estímulos e respostas) e classes do sistema (consultas e atualizações), com todas as 
alternativas de decisão (e respectivas ações) definidas.
Um cenário (instância de caso de uso) pode ser desencadeado:
• por meio de um evento externo (estimuladopor um usuário – instância de um ator); ou
• por um evento temporal (o sistema toma a iniciativa a partir de um algoritmo interno – tempo 
transcorrido, mudança de estado etc.)
Para se representar os cenários de um caso de uso, podem ser utilizados outros diagramas da UML, tais 
como, os diagramas de interação: diagrama de atividades, diagrama de sequência ou de comunicação.
O nome do caso de uso deve ser sempre composto de um verbo e um objeto direto. O verbo pode 
estar no infinitivo ou na terceira pessoa do singular. O importante é manter um padrão que todos sigam 
na empresa, por exemplo: emitir recibo ou emite recibo.
 Observação
O diagrama de casos de uso exerce um papel importante na análise 
de sistemas no momento de se entender e especificar as necessidades do 
cliente ou usuário, já que:
• é o principal diagrama para ser usado no diálogo com o usuário na 
descoberta e validação de requisitos;
• o diagrama pode ser construído a partir do protótipo do sistema, pois 
mostra os usuários (atores) interagindo com o sistema, de acordo 
com as telas, páginas ou relatórios apresentados no protótipo;
81
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
• os casos de uso constituem elementos que estruturam todas as 
etapas do processo de software.
5.2.1.3 Para identificar casos de uso
A partir do levantamento das necessidades do cliente ou de um usuário, a identificação dos casos de 
uso devem seguir um roteiro, conforme o sugerido a seguir:
• O que cada ator necessita ou deve ser capaz de fazer com ou para o sistema. Um ator pode 
armazenar, eliminar, alterar ou ler informações.
• Que tarefas devem ser executadas para suprir deficiências da atual implementação do 
sistema.
• Quais tarefas executar que a implementação atual não supre (novas funcionalidades).
5.2.1.4 Casos de uso empregados por mais de um ator
Quando vários atores do mesmo tipo utilizam o mesmo caso de uso, é possível identificar um ator 
abstrato e tornar os outros atores do mesmo tipo que o utilizam herdeiros dele. Ou ainda, eleger um ator 
como usuário do caso de uso e tornar os demais atores seus herdeiros.
5.2.1.5 Casos de uso utilizados por outros casos de uso
Um relacionamento de extensão (extend) de um caso “B” (caso estendido) para um caso “A” (caso 
básico) indica que instâncias específicas de “A” podem incluir “B”.
Portanto, um caso de uso de extensão é normalmente criado para mostrar comportamentos 
especiais e de exceção, que complementam o caso básico, quando aquelas condições 
excepcionais ocorrerem.
A figura 44 mostra um caso de uso com extensão.
uc Use Case Model
A B
<<extend>>
Figura 44 – O uso da extensão
No exemplo da figura 45, somente nas instâncias do caso de uso receber pagamento em que o prazo 
estiver vencido é que o caso calcular juros de mora será utilizado como extensão.
82
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
uc Use Case Model
Receber 
pagamento
Calcular juros 
de mora<<extend>>
Figura 45 – Uso de extend (extensão)
Um relacionamento de inclusão (include) de um caso A para um caso B indica que uma instância 
do caso A incluirá, também, as instâncias do caso B. Nesse caso, o caso de uso B sempre será acionado 
quando o caso de uso A estiver ativo. A figura 46 mostra esse caso.
uc Use Case Model
A B
<<include>>
Figura 46 – Uso do include
A figura 47 mostra um exemplo de include. Nesse caso, sempre que o caso de uso receber pagamento 
for ativado, o caso de uso emitir recibo também será acionado.
uc Use Case Model
Receber 
pagamento
Emitir 
recibo<<include>>
Figura 47 – Uso do include (inclusão)
Para todas as instâncias do caso de uso receber pagamento, será usado o caso de uso emitir recibo. 
O caso de uso emitir recibo poderá ser usado também por outros casos de uso.
Tanto o relacionamento de extensão (extend) como de inclusão (include) são provenientes de 
fatoração de casos de uso maiores, sendo que:
• extensão normalmente descreve variações de um comportamento normal, e
• inclusão revela comportamentos utilizados por mais que um caso de uso (reuso de caso de uso).
5.2.1.6 Especificação do modelo de caso de uso
A UML não específica um formato rigído para os cabeçalhos e a estrutura de um caso de uso. Eles 
podem ser alterados de acordo com as necessidades de documentação dos sistemas.
83
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
O quadro 4 a seguir mostra um exemplo de especificação de um caso de uso de alto nível.
Quadro 4 – Descrição de um caso de uso de alto nível
Caso de uso Comprar Itens
Atores envolvidos Cliente e operador
Tipo Primário
Descrição
Um cliente chega ao caixa com itens para 
comprar. O operador registra os itens e coleta o 
pagamento. Ao final, o cliente sai com os itens.
O quadro 5 mostra um exemplo de um caso de uso extendido (detalhado).
Quadro 5 – Caso de uso extendido
Caso de uso Comprar itens com dinheiro
Atores envolvidos Cliente e operador
Propósito Capturar uma venda e seu pagamento em dinheiro.
Descrição
Um cliente chega ao caixa com itens para comprar. 
O operador registra os itens e coleta um pagamento 
com dinheiro. Ao final, o cliente sai com os itens.
Tipo Primário e essencial .
Referência Requisitos funcionais: R1, R2, R3 (requisitos).
O quadro 6 mostra a sequência de eventos do exemplo do quadro 5. Ações dos atores e do sistema 
durante a ocorrência de compra.
Quadro 6 – Sequência de eventos em uma compra de cliente
Ação do ator Resposta do sistema
1. Este caso de uso começa quando um cliente chega ao 
caixa com itens para comprar.
2. O operador registra o identificador de cada item.
Se há mais de um do mesmo item, o operador também 
pode informar a quantidade. 
3. Determina o preço do item e adiciona 
informação sobre o item à transação de venda em 
andamento. Mostra a descrição e o preço do item 
corrente.
4. Após processar o último item, o operador indica ao 
sistema. 5. Calcula e mostra o valor total da venda.
6. O operador informa o total ao cliente. 
7. O cliente entrega um pagamento em dinheiro, 
possivelmente maior do que o valor total. 
8. O operador registra o valor recebido em dinheiro. 
9. Mostra o troco devido.
Emite um recibo.
10. O operador deposita o dinheiro e retira o troco devido.
O operador entrega o troco e o recibo ao cliente.
11. Registra a venda no log de vendas completadas.
12. O cliente sai com os itens comprados. 
84
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Essa sequência de eventos ainda pode comportar os eventos de excessão ou sequência de erros. 
Essas sequências devem ser colocadas como caminhos alternativos e podem merecer que novos casos 
de uso possam ser definidos para comportá-las.
 Saiba mais
O autor Martin Fowler escreveu com Kendall Scott um livro denominado 
UML Distilled, que resume a UML e discute todos os modelos ou diagramas 
envolvidos com a linguagem. O livro se encontra na sua 3ª edição. Ele foi 
traduzido para o português pela editora Bookman em 2004, e se chama 
UML Essencial – Um breve guia para a linguagem padrão de modelagem 
de Objetos.
O livro “UML Essencial’ descreve a maioria dos tipos de diagramas 
UML, sua utilização e a notação básica envolvida na criação. Esses 
diagramas incluem classes, sequência, objeto, pacote, instalação, 
casos de uso, máquina de estados, atividades, comunicação, estruturas 
compostas, componentes, visão geral da interação e diagramas de 
temporização.
Os exemplossão claros e as explicações chegam ao fundamento lógico 
de projeto de software orientado a objetos.
5.2.1.7 Estudo de caso com o modelo de caso de uso
Para demonstração da aplicação do modelo de caso de uso da UML, será utilizada a descrição de um 
sistema de vendas simples com algumas funcionalidades fundamentais (mesmo exemplo utilizado na 
unidade 2, como exemplo do uso do diagrama de classes).
Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramenta Case Enterprise 
Architect (EA).
 Saiba mais
O estudo de caso foi adaptado do exemplo apresentado no livro 
Modelagem de objetos, do autor José Davi Furlan, publicado pela Makron 
Books (FURLAN, 1998). Foi um dos autores brasileiros pioneiros na divulgação 
da UML no Brasil.
85
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Ferramentas Case:
O termo Case (Computer-Aided Software Engineering) signfica Engenharia de software auxiliada 
por computador.
Antigamente, os engenheiros de software desenvolviam software para outras áreas, tais como, 
Engenharia, Arquitetura, Medicina etc., mas não se utilizavam de software para fazer seu trabalho, 
confirmando o velho ditado “casa de ferreiro, espeto de pau”.
Com a necessidade de aumentar a produtividade e melhorar a qualidade, foram obrigados a 
desenvolver também software para uso próprio.
Inicialmente, era utilizado o termo Workbench, que significa “bancada de trabalho” e que designava 
as ferramentas, geralmente automatizadas, que auxiliavam no trabalho dos desenvolvedores de software.
Mais tarde, surgiu o termo Case. Uma ferramenta Case é qualquer software que auxilia as pessoas 
que trabalham em um ambiente de desenvolvimento de software.
A presença de ferramentas Case é vital hoje em dia para o bom funcionamento desse ambiente, e elas 
existem apoiando todo o ciclo de desenvolvimento (análise, projeto, implementação, teste e manutenção).
Há também ferramentas Case para apoiar a gerência dos projetos de desenvolvimento, a gerência de 
configuração e a gerência de riscos.
Sem ferramentas, uma metodologia ou método não terá boa aceitação no mercado devido ao 
aumento de trabalho que provoca no ambiente.
Isto ocorreu com diagramas, como o DFD e o E-R, que só foram amplamente utilizados quando 
surgiram as primeiras ferramentas para auxiliar na tarefa de diagramação.
Hoje em dia, há também a difusão do termo I-Case, que é usado para caracterizar um grupo de 
ferramentas Case integradas, isto é, que se relacionam entre si (entradas e saídas) e que permitem 
controlar a consistência dos dados quando uma metodologia é seguida.
Vantagens das ferramentas Case:
• Maior qualidade dos produtos finais: as ferramentas Case diminuem a probabilidade de erros, uma 
vez que podem ajudar no controle de consistência dos dados em um ambiente de desenvolvimento 
de software; também proporcionam maior eficácia dos produtos, ao auxiliarem as fases de análise 
e teste do produto pelo usuário.
• Produtividade: ao ajudar na realização de tarefas e até mesmo ao realizar algumas 
automaticamente, as ferramentas contribuem para uma maior agilidade no desenvolvimento 
de software, isto é, mais produtos em menos tempo.
86
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
• Eliminação de trabalho monótono: as ferramentas Case podem realizar algumas tarefas cansativas 
para os desenvolvedores, tais como, procurar informações e desenhar símbolos de um diagrama, 
as quais são mais suscetíveis ao erro.
• Mais tempo para a tomada de decisão: em consequência das ferramentas realizarem certas 
atividades pelas pessoas, essas ficam liberadas para outras tarefas, geralmente mais nobres, que 
exigem tomada de decisão e criatividade, ao invés de tarefas repetitivas.
• Flexibilidade para mudanças: as ferramentas permitem que sejam mudados dados e diagramas de 
maneira mais rápida e fácil, o que ajuda o desenvolvedor no trabalho de atender às necessidades 
do usuário.
• Menos programação: as ferramentas eliminam muito do trabalho de programação, deixando mais 
tempo para que a equipe técnica se preocupe com a análise do sistema, que é onde se define 
como solucionar o problema do usuário.
• Melhor documentação: por armazenarem dados e diagramas, as ferramentas também contribuem 
para uma melhor documentação do sistema, agilizando relatórios, busca de informações e 
alterações.
• Manutenção mais fácil e ágil: por consequência do item anterior, é possível ter mais informações 
sobre o software na hora de realizar sua manutenção (correção, atualização ou expansão).
5.2.1.8 Descrição do sistema – exemplo de uso do modelo de caso de uso
O sistema de vendas tem o objetivo de fornecer informações unificadas, abrangentes e atualizadas 
aos vendedores, incluindo a situação dos pedidos tirados, posição de crédito dos clientes, a programação 
de apresentação de produtos e a eficiência de vendas.
A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica. 
Os vendedores das filiais atuam em zonas de vendas, e um deles é o responsável pela zona de vendas. 
A estrutura de visitas aos clientes pelos vendedores é definida por zona de vendas e distribuída aos 
vendedores. As visitas ainda são organizadas semanalmente e representam períodos semanais, quinzenais 
e mensais.
A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamente o roteiro 
diário que deve ser seguido pelo vendedor para cumprir sua programação de vendas.
5.2.1.8.1 Requisitos do sistema
A partir da descrição do sistema, existem diversas alternativas de solução. De qualquer maneira, os 
requisitos independem de outra solução específica, mais simples ou mais complexa, já que eles mapeiam 
as necessidades dos clientes em forma de sentenças.
87
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
A figura 48 apresenta o diagrama de requisitos do sistema a ser modelado.
Os requisitos são organizados em dois grupos ou pacotes. O pacote de requisitos funcionais e o 
pacote de requisitos não funcionais:
• O pacote que contém os requisitos funcionais apresenta as características que representam o 
comportamento das funcionalidades ou regras de negócio que o sistema deve apoiar.
• O pacote de requisitos não funcionais contém os requisitos condicionantes e níveis de desempenho 
que o sistema deve atender. Por exemplo: tempo de resposta do sistema, transações de segurança 
etc.
No nosso estudo, somente serão abordados os requisitos funcionais. Ler foneticamente.
Requisitos funcionais
req Modelo de requisitos
RF01 – O sistema deve manter atualizada a posição do cliente
RF03 – Sistema emite informações adicionais sobre os clientes
RF06 – Análise do histórico de vendas
RF02 – O sistema deve elaborar o roteiro de visita do dia
RF05 – Analisa situação financeira do cliente
RF04 – Gera informações sobre filial
RF07 – Registra pedido de venda
Figura 48 – Requisitos do sistema modelado na ferramenta EA
5.2.1.7.2 Modelo de caso de uso do sistema
O primeiro passo para modelar o sistema é a partir dos requisitos apresentados na figura 48, que 
definem os casos de uso que descrevem o que o sistema de suporte a vendas irá oferecer em termos de 
funcionalidades.
Os atores envolvidos são pessoas, o vendedor e o comprador. O vendedor interage com o sistema no 
sentido de obter e registrar o pedido do comprador. O comprador recebe uma série de informações do 
sistema, mas não interage com o sistema diretamente para entrada de dados ou para consultas online.
88
Unidade III
Re
vi
sã
o:
 V
irgín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A figura 49 apresenta uma possível visão de solução para o sistema. O diagrama ou modelo de caso 
de uso não mostra as soluções de arquitetura do sistema, mostra apenas os atores interagindo com as 
funcionalidades dele.
uc Modelo de Caso de Uso
Vendedor
Cliente
<<extend>>
<<include>>
Mostra 
detalhes do 
cliente
Manter 
cliente
Elabora o 
roteiro de 
visita
Coloca 
pedido
Manter filial
Gera 
informações 
sobre filial
Analisa 
histórico de 
vendas
Analisa 
situação 
financeira
Informa 
visita
<<include>>
<<include>>
Figura 49 – Modelo de caso de uso do estudo de caso
5.2.1.8.3 Especificações do modelo de caso de uso
Inicialmente, deve-se descrever os atores envolvidos com o sistema e suas interações.
Ator vendedor:
• O vendedor, com base na zona e setor de vendas da filial, solicita a elaboração do roteiro de visita 
a clientes do dia.
• O vendedor, a partir do roteiro de visitas, programa seu deslocamento a clientes.
• O sistema deverá estar preparado para informar o vendedor sobre a localização dos logradouros e 
as principais alternativas viárias de acesso ao cliente.
• O sistema deve estar preparado para fornecer informações adicionais sobre os clientes para apoiar 
o vendedor na venda.
• O vendedor acessa o sistema para obter dados gerais sobre a filial.
89
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
• O vendedor analisa e discute com o cliente a situação da fatura com o cliente, tanto as faturas 
vencidas, como as faturas a vencer nos próximos períodos.
• O sistema permite que o vendedor analise a média de vendas por produto nos últimos meses, por 
meio do histórico de vendas ao cliente.
• Após a formalização do pedido de venda, o vendedor faz as últimas anotações sobre a visita ao 
cliente.
Ator cliente:
• O ator cliente ou comprador recebe, do sistema, dados sobre seu cadastro e um aviso da visita do 
vendedor com data e hora prevista. Ele também recebe uma cópia do pedido depois de dada a 
entrada pelo vendedor.
• Após as descrições dos atores e de suas interações com o sistema, o desenvolvedor deverá descrever 
os casos de uso, usando padrão definido pela organização em que trabalha.
• Será mostrada, como exemplo, a descrição do caso de uso manter filial, que é de responsabilidade 
do vendedor. A ferramenta Case utilizada é o EA.
• Descrição geral:
— A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área 
geográfica. Os vendedores das filiais atuam em zonas de vendas e um deles é o responsável 
pela zona de vendas.
• Pré-condições: vendedor autorizado no sistema.
• Pós-condições: filial liberada para uso.
• Caminho básico:
— Nome: inclui filial.
— Descrição (passos):
1. Vendedor responsável entra com dados da Filial.
2. Sistema valida filial.
3. Vendedor responsável entra com dados da zona de venda.
4. Sistema valida zona de venda.
90
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
5. Sistema associa zona de venda à filial.
6. Vendedor responsável entra com dados do setor de vendas.
7. Sistema valida setor de vendas.
8. Vendedor responsável associa setor de vendas à zona de venda.
9. Vendedor responsável associa outros vendedores à zona de vendas.
• Caminho alternativo:
— Nome: altera filial.
— Descrição (passos):
1. Vendedor responsável entra com filial.
2. Sistema valida filial.
3. Vendedor altera dados da filial.
4. Sistema altera dados da filial.
5. Vendedor responsável entra com dados da zona de venda/ setor de vendas a serem alterados.
6. Sistema valida zona de venda/setor de vendas.
7. Sistema altera dados da zona ou setor de vendas.
8. Vendedor associa/disassocia zona de venda a filial.
9. Sistema altera dados no banco de dados.
• Caminho alternativo:
— Nome: exclui filial.
— Descrição (passos):
1. Vendedor responsável entra com filial/zona de venda ou setor de vendas que quer 
excluir.
2. Sistema valida filial/zona e setor de vendas.
91
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
3. Sistema verifica se existe cliente com pedido pendente.
4. Sistema exclui vendedores da lista da filial.
5. Sistema elimina filial/zona ou setor de vendas.
• Caminho alternativo:
— Nome: erros.
— Descrição (passos):
1. Filial/zona ou setor de vendas inválido.
2. Filial/zona ou setor de vendas já existe.
3. Filial/zona ou setor de vendas não existe.
4. Não é possível eliminar filial/zona ou setor de vendas.
6 OuTROS MODELOS COMPORTAMENTAIS DA uML
6.1 Introdução
A UML apresenta diversos tipos de diagramas que modelam o comportamento de um sistema. Entre 
os diversos diagramas ou modelos comportamentais, o diagrama de caso de uso é considerado o mais 
importante deles e tem como finalidade modelar as necessidades ou requisitos de um cliente ou usuário 
de um sistema.
Todavia, outras necessidades de representar a realidade surgem quando os analistas de sistemas estão 
desenvolvendo ou especificando todas as abordagens necessárias para um entendimento completo do 
sistema que está sendo construído.
Para dar apoio aos desenvolvedores com relação ao comportamento do sistema perante uma 
determinada realidade ou situação, a UML propõe diversas alternativas de modelos que devem 
ser utilizados de acordo com as características do sistema ou do tipo de aplicação necessária para 
automatizar um determinado processo de negócio.
Os modelos comportamentais, além do modelo de caso de uso, são: diagrama de atividades, diagrama 
de estados ou máquina de estados. Outro diagrama importante abordado nesta unidade é o diagrama 
de sequência, sendo que os diagramas de comunicação e de tempo não serão detalhados por não serem 
os mais utilizados na prática da UML.
92
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
6.2 Diagrama de atividades
Um diagrama de atividade é um fluxo que representa as passagens de uma atividade para outra 
durante um fluxo de trabalho. Seu propósito é estudar os fluxos dirigidos por processamento interno, 
descrevendo as atividades em uma operação.
Esse diagrama tem sido usado para desenhar as lógicas dos cenários dos casos de uso, ou a lógica de 
processamento de uma operação de uma classe de objetos mais complexa.
A notação de um diagrama de atividades da UML usa os seguintes símbolos:
Quadro 7 – Símbolos do diagrama de atividade
Símbolos Breve descrição
Atividade
Representa uma atividade realizada por um usuário ou 
pelo sistema. 
Representa a passagem de uma atividade para outra.
Esta passagem também é chamada de gatilho (trigger).
É também chamado de fluxo de controle.
Símbolo de decisão.
Podem-se apontar diversas entradas ou saídas para esse 
símbolo de decisão.
Pode indicar que uma atividade chegou neste ponto e 
foi subdividida em mais de uma atividade (fork).
Caso diversas atividades chegem neste ponto e saiam 
para uma única atividade. O símbolo chama-se Join.
Símbolo de início ou entrada em um fluxo de 
atividades.
Pode haver vários pontos de entrada para um processo.
Símbolo de saída de um processo.
Pode haver diversos pontos de saída para um processo.
Fluxo final.
O X dentro do símbolo indica o final de um fluxo que 
não seja uma saída normal do processo.
act Use Case Model Swimlanes: este símbolo reproduz as raias de uma 
piscina.
Indica o confinamento de um conjuntode atividades 
em uma determinada área da empresa.
É usada para organizar logicamente uma atividade. 
A figura 50 mostra um exemplo da aplicação do diagrama de atividade.
93
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Registrar 
pedido
Avaliar item 
em estoque
Autorizar forma 
de pagamento
Cancelar 
pedido Aceitar pedido
OK?
Figura 50 – Exemplo de diagrama de atividade
6.3 Diagrama de sequência
O diagrama de sequência mostra os objetos e as mensagens sendo trocadas entre eles, necessárias 
para a execução de uma determinada tarefa, evidenciando a ordem em que as coisas acontecem, sem 
mostrar as associações entre os objetos.
Um diagrama de sequência é uma representação estruturada de comportamento com uma série 
de etapas sequenciais ao longo do tempo. Ele é usado para descrever o fluxo de trabalho, passagem de 
mensagens e mostrar como elementos em geral cooperam no tempo para alcançar um resultado.
Esse diagrama pode ser usado para mostrar a evolução de uma dada situação em um determinado 
momento do software, mostrar uma dada colaboração entre duas ou mais classes e pode, também, ser 
usado para mostrar a tradução de um caso de uso, desde a interação com o usuário até a finalização 
daquele dado processo (MEDEIROS, 2004).
Os objetos são mostrados na parte superior do gráfico e, para cada objeto, é desenhada uma linha 
vertical, que representa sua linha de vida.
As mensagens são representadas por setas horizontais que ligam os objetos por meio de suas linhas 
de vida, a ponta da seta aponta para o objeto alvo.
O eixo vertical normalmente aponta para baixo, indicando que as mensagens vão ocorrendo de cima 
para baixo na sequência de eventos.
Cada elemento da sequência é organizado em uma sequência horizontal, com mensagens que 
passam para trás e para frente entre os elementos.
94
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Um elemento de ator pode ser usado para representar o usuário que inicia o fluxo de eventos.
Elementos estereotipados, como interface, controle e entidade, podem ser usados para ilustrar as 
telas, os controladores e os itens de banco de dados, respectivamente.
Cada elemento tem uma linha pontilhada tronco chamada de linha da vida do objeto ou elemento, 
na qual o elemento/objeto existe e, potencialmente, participa das interações.
A figura 51 mostra um diagrama de sequência de um evento em que uma pessoa está telefonando, 
essa pessoa é chamada de chamador.
Os objetos telefone chamador e telefone chamado também interagem para que o telefonema 
aconteça.
sd Use Case Model
Chamador Telefone
chamador
Telefone chamado
chamador levanta receptor( )
sinal de discar começa ( )
telefone toca ( )
atenda telefone ( )
telefones interligados ( )
pessoa chamada desliga ( )
disca ( )
disca ( )
disca ( )
telefone ocupado ( )
som da campainha ( )
telefones interligados ( )
conexão desfeita ( )
conexão desfeita ( )
chamador desliga ( )
Ativação
Linha de 
vida do 
objeto
Figura 51 – Exemplo de diagrama de sequência
95
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
6.3.1 Linha de vida
As linhas pontilhadas na vertical representam a existência do objeto em um determinado tempo.
Se uma determinada mensagem representa a criação da instância do objeto, sua linha de vida inicia-
se naquele ponto.
Se ela representa a destruição do objeto, a linha termina nesse ponto e a sequência termina.
Se o objeto existe durante todo o processo, a linha de vida permeia todo o espaço vertical 
do diagrama.
A linha de vida pode se bifurcar em duas ou mais linhas concorrentes para mostrar 
condicionalidades.
6.3.2 Ativação
 Uma ativação evidencia o período de tempo em que um objeto está executando uma ação, 
diretamente ou a partir de um procedimento subordinado.
A ativação é representada por um retângulo de base pequena e cuja altura representa o tempo da 
ação (o topo do retângulo coincide com o início da ação e a base com o seu fim).
A ação a ser executada pode ser colocada em uma etiqueta na proximidade da ativação ou na 
margem esquerda do diagrama, ou estar implícita na mensagem que aciona a ativação.
6.3.3 Autodelegação
Evidencia a mensagem cujo objeto emissor (remetente) coincide com o objeto alvo (destinatário).
Trata-se de uma chamada recursiva. Se a chamada recursiva se der sobre uma ativação, desenha-se 
outro retângulo aninhado com o primeiro, para mostrar a autodelegação.
6.3.4 Mensagem
Uma comunicação entre objetos, que leva informação com a expectativa de que resultará em uma 
atividade.
O recebimento de uma mensagem é normalmente considerado um evento. Mensagem é a unidade 
fundamental da comunicação entre objetos.
A recepção de uma mensagem causa a invocação de uma operação no recebedor (objeto alvo). Esse 
executa o método da classe que corresponde àquela operação.
96
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
As mensagens são representadas por setas nomeadas, colocadas nas proximidades da ligação, que 
ligam os objetos por meio de suas linhas de vida.
A ponta da seta aponta para o objeto alvo. Quando um objeto for acionar uma mensagem nele 
mesmo, a seta inicia-se e termina no mesmo objeto.
A implementação de uma mensagem pode tomar várias formas: a chamada procedure, a passagem 
de sinal entre threads ativas, o específico acionamento de um evento etc. 
6.4 Diagramas de estado (máquina de estado)
O diagrama de estados representa, para uma determinada classe de objetos, seu padrão de eventos, 
estados e transição de estados.
Um diagrama de estados é uma rede de estados e eventos.
Na realidade, somente constrói-se diagrama de estados para as classes que possuem comportamento 
dinâmico importante.
6.4.1 Estado
Um estado é uma abstração dos valores de atributos e ligações de um objeto. Por exemplo: a linha 
telefônica está no estado sinal de discar.
Caso o dígito seja discado, a linha muda de estado, indo para o estado discando. Se o usuário 
recolocar o telefone no gancho, a linha telefônica passa do o estado sinal de discar para o estado 
inativa.
Os conjuntos de valores podem ser agrupados em um estado de acordo com propriedades que 
afetam o comportamento geral do objeto. Por exemplo: o fato do estado de um banco ser de solvência 
ou de insolvência depende do seu ativo exceder o seu passivo.
Com o passar do tempo, os objetos estimulam uns aos outros, resultando em uma série de alterações 
em seus estados.
6.4.2 Notações
Na UML, o estado é representado por um retângulo, como no diagrama de atividades. Um retângulo 
com o nome do estado representa um estado simples.
Um retângulo maior designa um estado composto ou máquina de estados. Quando outros estados 
(simples) estão participando de determinado composto, são desenhados em seu interior.
97
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Pseudo_estado_inicial
Estado_simples
Pseudo_estado_final
Est_simples 1 Est_simples 2
Estado_composto
Figura 52 – Símbolos do diagrama de estado
6.4.3 Evento
Um estímulo individual de um objeto A que o objeto B reconhece e reage é um evento.
A
B
Objeto Objeto
Estímulo
Figura 53 – Evento entre objetos
O objeto B reage ao estímulo dependente de seu estado. Ele pode modificar seu estado, pode enviar 
resposta para o remetente ou acionar outro objeto, a partir de novos eventose estímulos.
Os eventos possuem os seguintes tipos: mensagem, tempo transcorrido e condição de guarda.
Um evento é algo que acontece em um certo momento com os objetos de uma classe. Por exemplo: 
um usuário aperta o botão cancelar, o cliente desconta um cheque.
Um evento pode logicamente preceder ou suceder outro evento. Dois eventos podem não estar 
relacionados, nesse caso, são chamados de concorrentes.
Cada evento é uma ocorrência única, que pode ser agrupada em classes de eventos.
Cada classe de eventos recebe um nome para indicar estrutura e comportamentos comuns.
O exemplo a seguir demonstra uma classe de eventos:
• O voo 100 parte de São Paulo.
• O voo 200 parte de Fortaleza.
• O voo 30 parte de Porto Alegre.
98
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Pode-se criar a classe partida de aviões e tratar esses voos como instâncias da classe. Os atributos 
dessa classe seriam: linha_aérea, número_do_voo, cidade_origem, cidade_destino etc.
A Figura 54 mostra exemplos de classes de eventos:
Botão_do_mouse_ 
levantado
Botão
localização
Partida_aviões
Empresa_aerea
Número_do_voo
Cidade_destino
Altera_destino()
Figura 54 – Exemplo de classes de eventos
6.4.4 Transição
A modificação de estado causada por um evento é chamada de transição. A reação de um 
objeto a um evento pode constituir-se de uma ação que provoca uma modificação de estado no 
objeto.
Um estado corresponde ao intervalo entre dois eventos recebidos por um objeto.
Os eventos correspondem a “pontos no tempo”, e os estados representam “intervalos no tempo”, 
como mostra a Figura 55.
Estados de um objeto
Evento 1 Evento 2
t (objeto)
Figura 55 – eventos e estados
Na definição de estados, ignoram-se os atributos que não afetam o comportamento dos 
objetos.
Englobam-se em um só estado todas as combinações de valores de atributos e ligações que 
apresentam a mesma reação dos eventos.
O diagrama de estados ou diagrama de máquina de estados determina ou específica a sequência de 
estados causada por uma sequência de eventos.
A Figura 56 mostra um exemplo de eventos para uma classe conta de cliente de um banco.
99
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Inativa
Depositando Mensagem rejeitado
Ativa
Depósito_Cliente
Depósito_Rejeitado
Depósito_Aceito
Figura 56 – Exemplo de um diagrama de estado
Um diagrama de estados é uma fonte de descoberta de operações. Ajuda a descobrir também novos 
estados, regras de integridade e definir com mais precisão os domínios dos atributos envolvidos.
A figura 56 mostra um exemplo de um sistema de biblioteca.
Publicação
indisponível
Publicação 
disponível Indisp. 
temporária
(alienada)
Liberação da publicação
Cadastramento
Correção de erros 
 de digitação
Empréstimo de 
todos exemplares
Devolução do empréstimo
Retirada por empréstimo
Depósito_Aceito
Figura 56 – Diagrama de estados
 Saiba mais
Vale a pena ler o material disponível no endereço: <http://www.
fabriciosousa.com/APS_Diagrama_Estados.pdf>.
Este material está baseado no livro Princípios de análise e projeto de 
sistemas com UML, de Eduardo Bezerra, 2ª ed., Editora Campus/Elsevier.
100
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
 Resumo
Esta unidade apresentou conceitos da modelagem comportamental 
dos sistemas de informação.
Diversos diagramas e modelos da UML são utilizados para se modelar 
os comportamentos dos sistemas, mas esta unidade deu ênfase ao modelo 
de caso de uso que, para alguns autores, é o principal modelo de UML, 
juntamente com o modelo de classes de objetos.
Como os modelos estruturais são fundamentais para se definir a 
estrutura de um sistema, sua composição e dependências, os modelos 
comportamentais mostram as ações que durante o tempo acontecem com 
o sistema e com os atores que com ele interagem.
A UML apóia o processo de desenvolvimento UP (Unified Process). Ele 
é considerado um processo use case driven, o que significa um processo 
dirigido por casos de uso.
O modelo de caso de uso mostra o sistema realizando uma sequência 
de ações, para receber entradas dos usuários e gerar saídas para responder 
as necessidades do negócio. Daí a sua importância no desenvolvimento 
moderno e a ênfase dada a ele nesta unidade.
De todos os diagramas da UML, juntamente com o diagrama 
de casos de uso e o diagrama de classes, o diagrama de sequência é 
considerado um dos mais importantes, principalmente no momento da 
programação.
Com ele, pode-se passar a ordem e a sequência de chamadas dos 
objetos para resolver determinada lógica ou cenário de um caso de uso. Por 
sua vez, o diagrama de estado descreve o comportamento de um objeto de 
uma determinada classe de objetos.
Já com o diagrama de estados, são modelados os eventos que podem 
ser representados como operações nos modelos de objetos. O modelo 
dinâmico de uma classe é herdado por suas subclasses. As subclasses 
herdam os estados e as transições de seus ancestrais. As subclasses podem 
ter seus próprios diagramas de estado.
101
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
 Exercícios
Questão 1. Os processos de desenvolvimento de software que se baseiam na UML como linguagem 
de modelos denominam o modelo de caso de uso como o orientador do processo (use case driven). Nesse 
modelo, temos três elementos considerados básicos: o Ator, o Caso de Uso e a Associação entre o ator e o 
caso de uso. O ator é usado para definir o papel que um utilizador ou usuário representa relativamente ao 
sistema de informação modelado. Ele representa um conjunto coerente de papéis que os usuários de casos 
de uso desempenham quando interagem com esses casos de uso. Pode-se afirmar que um ator representa 
um papel que um ser humano, um dispositivo de hardware ou até outro sistema desempenha com o 
sistema. A UML define que um usuário do sistema representado pelo ator pode ser: uma pessoa; outro 
sistema de informação; um equipamento hardware especializado; a passagem de tempo. Considerando-se 
os conceitos apresentados sobre a UML, analise as afirmações a seguir e assinale a alternativa incorreta:
A) Na UML, o modelo de caso de uso é importante, já que auxilia na captura de requisitos do sistema 
que será construído.
B) Os casos de uso de um diagrama de Caso de Uso representam as funcionalidades que serão 
implementadas em um sistema de informação.
C) Os atores representam o ambiente externo do sistema (seres humanos, máquinas, agrupamentos 
lógicos, outros sistemas).
D) Como a UML apresenta modelos e elementos na tecnologia OO, pode-se afirmar que um Ator é 
uma classe de objetos.
E) O ícone que representa um ator no diagrama de casos de uso é um retângulo com diversos 
segmentos.
Resposta: Alternativa E.
Na UML, o modelo de caso de uso descreve como os usuários do sistema (entidades externas ao 
sistema), interagem com o sistema enviando ou recebendo informações.
Análise das alternativas
A) Correta. Quando o analista de sistemas precisa representar as necessidades do cliente ou usuário, 
utiliza o modelo de caso de uso da UML; este permite ao usuário mapear os requisitos em torno 
dos usuários e das funcionalidades do sistema.
B) Correta. No modelo de caso de uso, o elemento que representa as funcionalidades do sistema e 
que executará os requisitos do sistema é o próprio caso de uso.
102
Unidade III
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: Már
ci
o 
- 
14
-0
8-
20
12
C) Correta. Como os atores estão fora do sistema e interagem com o mesmo modelo de Caso de Uso, 
representam o ambiente externo do sistema.
D) Correta. Todos os elementos de todos os modelos da UML representam objetos que podem ser 
instanciados na execução do sistema. O ator que representa os usuários do sistema também será 
instanciado na execução do sistema.
E) Incorreta. O ícone que representa um ator no diagrama de caso de uso é a figura do stick man ou 
o homem palito.
Questão 2. Os casos de uso em um modelo de caso de uso podem ser expandidos por meio de outros 
para mostrar comportamentos especiais e de extensão que complementam os cenários do caso de uso 
básico modelo. Considerando-se os conceitos apresentados sobre o modelo de caso de uso, analise as 
afirmações a seguir e assinale a alternativa incorreta:
A) Um modelo de casos de uso é um modelo das funções pretendidas do sistema e suas vizinhanças, 
que serve como contrato entre o cliente e os desenvolvedores.
B) Há muitas maneiras de modelar um sistema, cada uma pode atender a uma finalidade diferente, 
e o modelo de caso de uso, por ser facilmente compreendido, torna-se uma ferramenta poderosa 
de comunicação entre as pessoas envolvidas com o sistema.
C) Os usuários e qualquer outro sistema que pode interagir com o sistema sendo modelado com o 
diagrama de caso de uso são os atores.
D) O modelo de casos de uso não é uma ferramenta útil na negociação entre os desenvolvedores e 
os clientes/usuários devido à sua complexidade técnica.
E) Os casos de uso são desenvolvidos com base nas necessidades dos atores. Isso garante que o 
sistema será o que os usuários esperam.
Resolução desta questão na plataforma.