Unified Modeling Language (UML)
Universidade Federal do Maranhão – UFMAPós Graduação de Engenharia de Eletricidade Grupo de Computação
Assunto: Diagrama de Caso de Uso (Use Case)
Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
2 Diagrama de Caso de Uso
A modelagem de um diagrama de caso de uso é uma técnica
usada para descrever e definir os requisitos funcionais de um
sistema, focando principalmente em processos do negócio.
2.1 Objetivos
Descrever os requerimentos funcionais do sistema de maneira
consensual entre usuários e desenvolvedores de sistemas.
Fornecer uma descrição consistente e clara sobre as
responsabilidades que devem ser cumpridas pelo sistema,
além de formar a base para a fase de desenho.
Oferecer as possíveis situações do mundo real para o teste do
2.2 Definição
Um diagrama de caso de uso é um gráfico de atores, um
conjunto de casos incluído por um limite de domínio,
comunicação, participação e associações entre atores, assim
como generalizações entre casos de uso.
Os diagramas são escritos em termos de atores externos que
interagem entre si, casos de uso e o sistema modelado.
Assim são quatro os elementos básicos:
Ator
Caso de uso
Interação
2.3 Exemplos
Ator
Caso de uso
2.4 Atores
Os atores representam o papel de uma entidade externa ao
sistema como um usuário, um hardware, ou outro sistema que
interage com o sistema modelado.
Os atores iniciam a comunicação com o sistema através dos
casos de usos, onde o caso de uso representa uma seqüência de
ações executadas pelo sistema e recebe do ator que lhe utiliza
dados tangíveis de um tipo ou formato já conhecido, e o valor de
resposta da execução de um caso de uso (conteúdo) também já é
de um tipo conhecido, tudo isso é definido juntamente com o
Atores e casos de usos geralmente se tornam classes.
Um ator é conectado a um ou mais casos de uso através de
associações, e tanto atores quanto casos de usos podem possuir
relacionamentos de generalização que definem um
comportamento comum de herança em superclasses
especializadas em subclasses.
2.5 Casos de uso
Características principais de um caso de uso
Um caso de uso é sempre iniciado por um ator
Um caso de uso é sempre realizado em nome de um ator
que, por sua vez, deve pedir direta ou indiretamente ao
sistema tal realização.
Um caso de uso é completo
Um caso de uso deve ser uma descrição completa, portanto,
não estará completo até que o valor final seja produzido
mesmo se várias comunicações ocorrerem durante a
interação.
Um caso de uso deve prover um valor tangível a um ator em
resposta à sua solicitação.
2.6 Casos de uso e colaborações entre classes
A utilização de casos de usos em colaborações é muito
importante, onde estas são as descrições de um contexto,
mostrando classes/objetos, seus relacionamentos e sua interação
exemplificando como as classes/objetos interagem para executar
uma atividade específica no sistema.
Quando um caso de uso é realizado, a responsabilidade de cada
passo da execução deve ser associada às classes que participam
da colaboração, tipicamente especificando as operações
necessárias dentro destas classes juntamente com a definição de
como elas irão interagir.
Um cenário é uma instância de um caso de uso, ou de uma
colaboração, mostrando o caminho específico de cada ação.
Quando visto em nível de um caso de uso, apenas a interação
entre o ator externo e o caso de uso é vista, mas já observando
em nível de uma colaboração, toda as interações e passos da
execução que implementam o sistema serão descritos e
2.7 Identificação de atores
Quem utilizará a principal funcionalidade do sistema (atores
principais)?
Quem irá manter, administrar e fazer com que o sistema
permaneça operando (atores coadjuvantes)?
Quem proverá suporte ao sistema em seu processamento
diário?
Quem ou quê tem interesse nos resultados produzidos pelo
sistema?
Quais dispositivos de hardware são necessários ao sistema?
Com quais outros sistemas o sistema em foco irá interagir?
2.8 Identificação de casos de uso
O ator precisa ler, criar, destruir, modificar ou armazenar
algum tipo de informação no sistema?
O trabalho diário do ator pode ser simplificado ou tornado
mais eficiente através de novas funções do sistema?
O ator tem de ser notificado sobre eventos no sistema ou ainda
Quais as funções que o ator necessita do sistema?
O que o ator necessita fazer?
Quais são os principais problemas com a implementação atual
do sistema?
Quais são as entradas e as saídas, juntamente com sua origem
e destino, que o sistema requer?
2.9 Como extrair um caso de uso em uma entrevista
Nome do caso de uso
Verbo no infinitivo (informar, comprar, pagar, ....)
Breve descritivo
Descrição que informa do que se trata este caso de uso
Atores envolvidos
Cenário principal
A descrição de uma tarefa que represente o mundo perfeito,
sem exceções. Verbos no presente do indicativo ou
substantivos, iniciando a frase (registra, compra, seleciona,
informa, etc.). Ex.: “Um comprador em um site de
e-commerce pode adicionar e remover produtos a seu carrinho
Cenário alternativo
Qualquer situação que represente uma exceção de um
cenário principal. Ex.: “Para os itens em promoção o cliente
só deve comprar 5 itens”
Requisitos especiais
Qualquer situação não contemplada anteriormente. observar
adjetivos do entrevistado. Ex.: “esta consulta tem que ser
bem rápida, já tivemos problemas de ficar esperando horas”
Dados
Tipos de dados que foram encontrados durante a descrição
do caso de uso. Informamos: texto, número, data, etc., ou
mesmo o tipo de dado e seu tamanho, conforme a linguagem
a ser utilizada (se conhecer).
Como extrair um caso de uso (cont)
Observações
Usuário prometeu fornecer algum formulário
Analista
Quem fez a análise
Assinatura do entrevistado
Data
Data da assinatura
2.10 Exemplo
Nome: Locar DVD
Atores: cliente locador, site
Cenários principais:
Escolhe determinado tipo de grupo selecionando sua
descrição – cliente locador
Escolhe tipo de busca desejada a partir de uma descrição.
Essa busca pode ser por ator, diretor ou título – cliente
locador
Deduz a quantidade do DVD escolhido no estoque – site
(1) Valida o cartão de débito do cliente locador – site
(2) Informa tempo aproximado de entrega, em horas, no
Cenários alternativos:
(1.1) Identifica cartão inválido, pede providência do cliente
para regularização – site
(1.2) Adiciona a quantidade do DVD escolhido ao estoque
de cópias devido a não locação – site
(2.1) Altera o endereço de entrega – cliente locador
Requisitos especiais
Deve ser adicionado ou deduzido do número cópias no
estoque, imediatamente após a ação que provocar uma
dessas situações.
O cliente locador pode abandonar a loja a qualquer
momento.
Observações:
Prever Caso de Uso Controlar Estoque, Entregar Locação,
Cadastrar Cliente Locador
2.11 Dicas
Um cenário principal ou alternativo é um requisito,
possivelmente uma classe no futuro
Lembrete: requisito é uma condição ou capacidade que um
software deve ter
2.12 Interações em caso de uso
Comunicação
Um ator comunica-se com o caso de uso, assim, cada
participação sua é mostrada conectando-se o símbolo de
caso de uso por um caminho sólido
Extensão
São freqüentemente usadas para mostrar comportamento de
exceção e casos especiais que aumentam a quantidade de
casos de uso no modelo.
Trata-se de um relacionamento de um caso de uso para
outro, especificando como o comportamento definido para o
primeiro caso pode ser inserido no comportamento definido
para o segundo.
É desenhada através de um seta de generalização etiquetada
com o estereótipo <<estende>>, do caso de uso que fornece
extensão para o caso de uso básico.
Quando um número de casos de uso tem um comportamento
comum, esse comportamento pode ser modelado em um
simples caso de uso que é utilizado por outros casos.
Ocorre quando há uma parcela de comportamento similar
entres eles sugerindo uma reutilização em vez de nova cópia
da descrição do comportamento.
É desenhado como uma seta de generalização do caso de
uso que fez o uso ao caso de uso que é usado, etiquetada
com o estereótipo <<inclui>>.
Como regra geral, empregue relacionamento de extensão
quando estiver descrevendo uma variação em um
comportamento normal, e relacionamento de uso quando
estiver repetindo comportamento em dois ou mais casos de
2.13 Exemplos
“requisitar catálogo de pedido” estende “colocar pedido” e
“colocar pedido” inclui “pedir produto”.
indica-se que “Gerente de Vendas” e “Gerente de Compras”
têm alguns aspectos em comum, que são abstraídos através
Relacionamento entre atores e caso de uso
Os relacionamentos indicam a existência de comunicação
entre atores e casos de uso. Um caso de uso pode estar
associado a mais de um ator, quando a sua execução requer
a participação de diferentes atores.
Relacionamento caso de uso com mais de ator
Quando a iniciativa parte do caso de uso (alarmes,
mensagens, dados enviados para outros sistemas etc.), a
comunicação deve ser direcionada para o ator. Nesse
exemplo, o caso de uso “Gestão Manual de Estoque”,
acionado pelo ator “Gestor de Estoque”, envia dados para o
2.14 Considerações Finais
Cada Diagrama de Casos de Uso representa graficamente uma
visão parcial do Sistema
O conjunto de Diagramas de Casos de Uso forma a visão de
Casos de Uso completa do Sistema
Representam uma visão externa ao sistema, ajudando a
identificar e especificar o conjunto de classes e suas interações
Unified Modeling Language (UML)
Universidade Federal do Maranhão – UFMAPós Graduação de Engenharia de Eletricidade Grupo de Computação
Assunto: Diagrama de Classes
Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
3 Diagrama de Classes
3.1 Definições
Uma classe é a descrição de um tipo de objeto.
Todos os objetos são instâncias de classes, onde a classe descreve
as propriedades e comportamentos daquele objeto.
Identificar as classes de um sistema pode ser complicado, e deve
ser feito por experts no domínio do problema a que o software
modelado se baseia.
O diagrama de classes é considerado estático já que a estrutura
descrita é sempre válida durante o ciclo de vida do sistema.
Um sistema normalmente possui alguns diagramas de classes, já
que não são todas as classes que estão inseridas em um único
diagrama e uma certa classe pode participar de vários diagramas de
classes.
As classes devem ser extraídas do domínio do problema e serem
3.2 Relacionamentos
Classes podem se relacionar com outras através de diversas
maneiras: associação (conectadas entre si), dependência (uma
classe depende ou usa outra classe), especialização (uma classe é
uma especialização de outra classe), ou em pacotes (classes
agrupadas por características similares).
Os relacionamentos são mostrados no diagrama de classes
juntamente com as suas estruturas internas, que são os atributos e
operações.
3.3 Propósitos Básicos e Distintos
Fazer modelagem do vocabulário do sistema
Indica quais abstrações fazem parte do sistema e quais estão
fora do limite do mesmo
Fazer a modelagem e colaboração simples
Mostra como as classes trabalham em conjunto permitindo a
compreensão de uma semântica maior do que se estas mesmas
classes fossem analisadas individualmente.
Fazer a modelagem do esquema lógico de um banco de dados
Descreve, de forma orientada a objetos, o esquema lógico de
um banco de dados que fisicamente pode ser orientado a
objetos, relacional ou híbrido.
3.4 Identificação de classes
Questões que podem ajudar a identificá-las:
Existem informações que devem ser armazenadas ou analisadas?
Se existir alguma informação que tenha que ser guardada,
transformada ou analisada de alguma forma, então é uma
Existem sistemas externos ao modelado? Se existir, eles deverão
ser vistos como classes pelo sistema para que possa interagir
com outros externos.
Existem classes de bibliotecas, componentes ou modelos
externos a serem utilizados pelo sistema modelado? Se sim,
normalmente essas classes, componentes e modelos conterão
classes candidatas ao nosso sistema.
Qual o papel dos atores dentro do sistema? Talvez o papel deles
possa ser visto como classes, por exemplo, usuário, operador,
cliente e daí por diante.
3.5 Representação
Em UML, as classes são representadas por um retângulo dividido
em três compartimentos: o compartimento de nome, que conterá
apenas o nome da classe modelada, o de atributos, que possuirá a
relação de atributos que a classe possui em sua estrutura interna, e
o compartimento de operações, que serão os métodos de
manipulação de dados e de comunicação de uma classe com outras
do sistema.
A sintaxe usada em cada um destes compartimentos é
independente de qualquer linguagem de programação, embora
Representação Gráfica
3.6 Tipos de relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando
relações lógicas entre estas entidades. Os relacionamentos
podem ser dos seguintes tipos:
Associação: É uma conexão entre classes que também significa uma conexão entre objetos daquelas classes. Em
UML, uma associação é definida com um relacionamento que
descreve uma série de ligações, onde a ligação é definida como
a semântica entre as duplas de objetos ligados.
Generalização: É um relacionamento de um elemento mais geral e outro mais específico. O elemento mais específico
pode conter apenas informações adicionais. Uma instância (ou
objeto) do elemento mais específico pode ser usada onde o
elemento mais geral seja permitido.
Dependência e Refinamentos: Dependência é um
relacionamento entre elementos, um independente e outro
dependente. Uma modificação de um elemento independente
afetará diretamente elementos dependentes dele. Refinamento
é um relacionamento entre duas descrições de uma mesma
3.7 Associações
Uma associação representa que duas classes possuem uma
ligação (link) entre elas, significando, por exemplo, que elas
“conhecem uma a outra”, “estão conectadas com”, “para cada X
existe um Y” e assim por diante.
Podem ser:
Normal, Recursiva, Qualificada, Exclusiva, Ordenada, Classe,
Ternária e Agregação.
Associação Normal
O tipo mais comum de associação é apenas uma conexão entre
classes.
É representada por uma linha sólida entre duas classes. A
associação possui um nome (junto à linha que representa a
associação), normalmente um verbo, mas substantivos também
são permitidos.
Pode-se também colocar uma seta no final da associação
indicando que esta só pode ser usada para o lado onde a seta
aponta. Mas associações também podem possuir dois nomes,
Para expressar a multiplicidade entre os relacionamentos, um
intervalo indica quantos objetos estão relacionados no link. O
intervalo pode ser de zero para um (0..1), zero para vários (0..*
ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11)
e assim por diante. É também possível expressar uma série de
números como (1, 4, 6..12). Se não for descrita nenhuma
multiplicidade, então é considerado o padrão de um para um
(1..1 ou apenas 1).
Exemplo: um relacionamento entre as classes Cliente e Conta
Corrente que se relacionam por associação.
Associação Recursiva
Quando for necessário conectar uma classe a ela mesma através
de uma associação e que ainda representa semanticamente a
Associação Qualificada
Associações qualificadas são usadas com associações de um para
vários (1..*) ou vários para vários (*). O “qualificador”
(identificador da associação qualificada) especifica como um
determinado objeto no final da associação “n” é identificado, e
pode ser visto como um tipo de chave para separar todos os
objetos na associação.
O identificador é desenhado como uma pequena caixa no final
da associação junto à classe de onde a navegação deve ser feita.
Associação Exclusiva
Em alguns modelos nem todas as combinações são válidas, e
isto pode causar problemas que devem ser tratados.
Uma associação exclusiva é uma restrição em duas ou mais
associações.
Ela especifica que objetos de uma classe podem participar de no
Uma associação exclusiva é representada por uma linha tracejada
entre as associações que são partes da associação exclusiva, com
a especificação “{ou}” sobre a linha tracejada.
Exemplo: No diagrama abaixo um contrato não pode se referir a
uma pessoa e a uma empresa ao mesmo tempo, significando que
o relacionamento é exclusivo a somente uma das duas classes.
Associação Ordenada
As associações entre objetos podem ter uma ordem implícita.
O padrão para uma associação é desordenado (ou sem nenhuma
ordem específica). Mas uma ordem pode ser especificada através
Este tipo de associação pode ser muito útil em casos como este:
janelas de um sistema têm que ser ordenadas na tela (uma está
no topo, uma está no fundo e assim por diante).
A associação ordenada pode ser escrita apenas colocando
“{ordenada}” junto à linha de associação entre as duas classes.
Associação de Classe
Uma classe pode ser associada a uma outra associação, não
sendo conectada nenhuma das extremidades da associação já
existente, mas na própria linha da associação.
Esta associação serve para se adicionar informação extra a
associação já existente.
Exemplo: A associação da classe Fila com a associação das
classes Cliente e Processo pode ser estendida com operações de
adicionar processos na fila, para ler e remover da fila e de ler o
seu tamanho. Se operações ou atributos são adicionados a
Associação de Ternária
Mais de duas classes podem ser associadas entre si, a associação
ternária associa três classes.
Ela é mostrada como uma grade losango (diamante) e ainda
suporta uma associação de classe ligada a ela, traçar-se-ia, então,
uma linha tracejada a partir do losango para a classe onde seria
feita a associação ternária.
Exemplo: A associação ternária especifica que um cliente poderá
possuir 1 ou mais contratos e cada contrato será composto de 1
Associação de Agregação
A agregação é um caso particular da associação.
A agregação indica que uma das classes do relacionamento é
uma parte, ou está contida em outra classe. As palavras chaves
usadas para identificar uma agregação são: “consiste em”,
“contém”, “é parte de”.
Existem tipos especiais de agregação que são as agregações
compartilhadas e as compostas.
Agregação Compartilhada:
É dita compartilhada quando uma das classes é uma parte, ou
está contida na outra, mas esta parte pode estar contida na
outras várias vezes em um mesmo momento.
Exemplo: uma pessoa pode ser membro de um time ou vários
3.8 Generalização
A generalização é um relacionamento entre um elemento geral e
um outro mais específico.
O elemento mais específico possui todas as características do
elemento geral e contém ainda mais particularidades.
Um objeto mais específico pode ser usado como uma instância
do elemento mais geral.
A generalização, também chamada de herança, permite a criação
de elementos especializados em outros.
Existem alguns tipos de generalizações que variam em sua
utilização a partir da situação. São elas:
Normal
Restrita
Sobreposição
Disjuntiva
Completa
Generalização Normal
Na generalização normal a classe mais específica, chamada de
subclasse, herda tudo da classe mais geral, chamada de
superclasse. Os atributos, operações e todas as associações são
herdados.
Uma classe pode ser tanto uma subclasse quanto uma
superclasse, se ela estiver numa hierarquia de classes que é um
gráfico onde as classes estão ligadas através de generalizações.
A generalização normal é representada por uma linha entre as
duas classes que fazem o relacionamento, sendo que se coloca
uma seta no lado da linha onde se encontra a superclasse
Generalização Restrita
Uma restrição aplicada a uma generalização especifica
informações mais precisas sobre como a generalização deve ser
usada e estendida no futuro.
Generalizações restritas com mais de uma subclasse:
Sobreposição e Disjuntiva:
Generalização de sobreposição ocorre quando subclasses
herdam de uma superclasse por sobreposição e novas
subclasses destas podem herdar de mais de uma subclasse.
A generalização disjuntiva é exatamente o contrário da
Completa e Incompleta
Uma restrição simbolizando que uma generalização é completa
significa que todas as subclasses já foram especificadas, e não
existe mais possibilidade de outra generalização a partir
daquele ponto.
A generalização incompleta é exatamente o contrário da
3.9 Dependência e Refinamento
Dependência é uma conexão semântica entre dois modelos de
elementos, um independente e outro dependente.
Uma mudança no elemento independente irá afetar o modelo
dependente. Como no caso anterior com generalizações, os
modelos de elementos podem ser uma classe, um pacote, um
use-case e assim por diante.
Quando uma classe recebe um objeto de outra classe como
parâmetro, uma classe acessa o objeto global da outra. Nesse
caso existe uma dependência entre estas duas classes, apesar
de não ser explícita.
Uma relação de dependência é simbolizada por uma linha
tracejada com uma seta no final de um dos lados do
relacionamento. E sobre essa linha o tipo de dependência que
existe entre as duas classes.
As classes “Amigas” provenientes do C++ são um exemplo
Refinamentos são um tipo de relacionamento entre duas
descrições de uma mesma coisa, mas em níveis de abstração
diferentes, e podem ser usados para modelar diferentes
implementações de uma mesma coisa (uma implementação
simples e outra mais complexa, mas também mais eficiente).
Os refinamentos são simbolizados por uma linha tracejada
com um triângulo no final de um dos lados do relacionamento
e são usados em modelos de coordenação.
Em grandes projetos, todos os modelos que são feitos devem
ser coordenados. Coordenação de modelos pode ser usada
para mostrar modelos em diferentes níveis de abstração que se
relacionam e mostram também como modelos em diferentes
3.10 Mecanismos gerais
A UML utiliza alguns mecanismos em seus diagramas para tratar
informações adicionais.
Ornamentos:
São gráficos são anexados aos modelos de elementos em
diagramas e adicionam semânticas ao elemento.
Um exemplo de um ornamento é o da técnica de separar um
tipo de uma instância. Quando um elemento representa um
tipo, seu nome é mostrado em negrito. Quando o mesmo
elemento representa a instância de um tipo, seu nome é escrito
sublinhado e pode significar tanto o nome da instância quanto
o nome do tipo.
Outros ornamentos são os de especificação de multiplicidade
de relacionamentos, onde a multiplicidade é um número ou
um intervalo que indica quantas instâncias de um tipo
conectado pode estar envolvido na relação.
Notas:
Nem tudo pode ser definido em uma linguagem de
Para permitir adicionar informações a um modelo não poderia
ser representado de outra forma, UML provê a capacidade de
adicionar Notas.
Uma Nota pode ser colocada em qualquer lugar em um
Unified Modeling Language (UML)
Universidade Federal do Maranhão – UFMAPós Graduação de Engenharia de Eletricidade Grupo de Computação
Assunto: Diagrama de Seqüência
Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
7 Diagrama de Seqüência
7.1 Tipos de diagramas de interação
Termo genérico que se aplica a vários tipos de diagramas que
enfatizam interações de objetos.
Uma interação é uma especificação comportamental que inclui
uma seqüência de trocas de mensagem entre um conjunto de objetos dentro de um contexto para realizar um propósito específico.
Deve ser utilizado quando se deseja visualizar o comportamento
de vários objetos dentro de um único caso de uso, a partir das mensagens que são passadas entre eles.
& Diagrama de Seqüência
& Diagrama de Colaboração (Comunicação em UML 2.0)
7.2 Diagrama de Seqüência
Um diagrama de seqüência mostra a colaboração dinâmica entre
os vários objetos de um sistema e que dá ênfase à ordenação temporal das mensagens trocadas entre objetos do sistema.
Mostra a interação entre os objetos, alguma coisa que acontecerá
em um ponto específico da execução do sistema.
Pode ser usado para mostrar a evolução de uma dada situação
em 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 sua interação com o usuário até a finalização daquele dado processo.
Pode mostrar erros não detectados no diagrama de classes. Ele
melhora o diagrama de classes, permitindo que acrescentemos ou retiremos métodos e/ou atributos desnecessários de um conjunto de classes.
O mais importante aspecto deste diagrama é que a partir dele
percebe-se a seqüência de mensagens enviadas entre os objetos.
A intenção é dar uma demonstração visual da seqüência das
7.3 Notação
Objeto
Estereótipos
bastante utilizados, pois precisamos representar interações
com usuário, gravação e recuperação de informações em banco de dados, textos ou XML
A letra “a” antes do dois pontos será o nome da página PHP
em questão.
Uma linha tracejada significa a linha de vida da solução em
Um retângulo que ocupa qualquer área da linha tracejada é o
tempo de vida do objeto.
Um objeto enviando uma mensagem para outro objeto. Quando
A seta tracejada representa o retorno que a MensagemA pode
dar. Quando métodos não tem retorno simplesmente não represente esta seta
A representação de mensagem assícronas, aquelas que são
Método recursivo é aquele mensagem que é enviada ao próprio
objeto. Ex.: uma classe de senha e ela própria cuida de criptografar essa senha.
Um “X”, no final de uma ocorrência de execução, indica que o
Operador de interação.
O operador deve estar dentro de um retângulo maior,
chamado de Fragmento Combinado, dividido por uma ou mais linhas pontilhada.
Formas de representar alternativas (Alt ou alt), else, switch,
cases entre outras. Uma ou outra opção é escolhida
Utilizando opt temos uma opção. Pelo menos um é escolhido
ou nada deverá acontecer.
Quando o operador de interação for o break, isso indica que o
em vez de simplesmente terminarmos, é um ponto de parada obrigatória.
Quando o operador de interação for Paralelo ou par, designa
que o fragmento combinado executa um intercalação entre os operandos ou cenários desenhados no fragmento combinado
Quando o operador de interação for Região Crítica, designa
que o fragmento combinado não pode ser intercalado por outro e seu tratamento é especial
Quando o operador de interação for loop, segnifica que
aquele fragmento passa por um loop na linguagem. O loop tem uma sintaxe própria, assim como a condição,
loop [(<minimo>, [<maximo>])]
Quando o operador de interação for ignorar, significa que
existem alguns tipos de mensagem que não são mostrados naquele fragmento combinado. Por exemplo, mensagens que são intuitivamente construídas, como a exibição de uma tela que informa: por favor, se seu login ou sua senha apresentam problemas, você tem mais duas chances. Inversamente
considerar indica que existem mensagens que devem ser consideradas naquele fragmento.
Quando o operador de interação for asserção, indica que a
Existe, ainda, os gates (portões), cuja única finalidade é
promover uma forma de interação entre fragmentos combinados alcançando outra mensagem em outro fragmento combinado. Para representar um gate, basta enviar uma mensagem, uma seta, para a borda do fragmento combinado.
Unified Modeling Language (UML)
Universidade Federal do Maranhão – UFMAPós Graduação de Engenharia de Eletricidade Grupo de Computação
Assunto: Diagrama de Atividade
Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
6 Diagrama de Atividade
6.1 Definição
Capturam ações e seus resultados, focando o trabalho executado
na implementação de uma operação (método), e suas atividades
numa instância de um objeto.
Trata-se de uma variação do diagrama de estado com um
propósito um pouco diferente do diagrama de estado:
Capturar ações (trabalho e atividades que serão
executados) e seus resultados em termos das mudanças
de estados dos objetos.
Os estados no diagrama de atividade mudam para um
próximo estágio quando uma ação é executada (sem
necessidade de especificação de evento).
Outra diferença é que podem ser colocadas como
“swimlanes” (agrupamento de atividades com respeito a
quem é responsável e onde estas atividades residem na
organização), representada por retângulos que
Forma alternativa de se mostrar interações, com a possibilidade
de expressar como as ações são executadas, o que elas fazem
(mudanças dos estados dos objetos), quando elas são executadas
(seqüência das ações), e onde elas acontecem (swimlanes).
Mostra o fluxo seqüencial das atividades: atividades executadas
por uma operação específica do sistema.
Consistem em estados de ação, contendo a especificação de uma
atividade a ser desempenhada por uma operação do sistema.
Decisões e condições, como execução paralela, também podem
ser mostradas na diagrama de atividade.
O diagrama também pode conter especificações de mensagens
enviadas e recebidas como partes de ações executadas.
6.2 Objetivos
Capturar as ações que serão executadas quando uma operação
é disparada (uso comum) e o trabalho interno em um objeto.
Mostrar como um grupo de ações relacionadas pode ser
executado, e como elas vão afetar os objetos em torno delas.
Mostrar como uma instância pode ser executada em termos de
ações e objetos.
Mostrar como um negócio funciona em termos de trabalhadores
(atores), fluxos de trabalho, organização, e objetos (fatores
6.3 Notação
Atividade: usado quando o usuário faz
alguma coisa ou existe a resposta do
sistema, pode ser usado este símbolo.
Passagens entre atividades: (fluxo ou
gatilho) Podem ser acrescentados efeitos
e resultados.
Decisão: Diversas saídas para o símbolo
de decisão
Fork: Significa que uma atividade chegou
neste ponto e foi subdividida em mais de
uma atividade
Join: Significa que uma atividade chegou
num mesmo ponto e criou-se uma nova
atividade
Entrada/Saída: Pode haver diversos
Merge: Fluxos convergentes para um único ponto e existe
apenas um saída, o que é diferente do join, onde vários fluxos
chegam concorrentemente.
Condição.
Swinmlanes. Reproduz as
raias de uma piscina
Rake (rodo - tridente)
dentro de uma determinada
atividade indica que aquela
atividade tem subatividades
ou as está invocando
Fluxo final. Indica que as
atividades terminaram para
aquela situação, ou caso de uso, e vão seguir em outro ponto,
possivelmente. O final de um fluxo indica apenas que
6.4 Comportamento Condicional
Feito através de desvios e intercalações (merges)
Um desvio é uma transição de entrada única e várias transições
de saídas guardadas. Somente uma transição de saída pode
ser tomada, de modo que os guardas (guards) devem ser
mutuamente exclusivos.
A utilização de
[else] como um
guarda indica que a
transição “else”
deverá ser usada
se todos os outros
guardas de desvios
forem falsas.
Uma intercalação
tem múltiplas
transições de
entrada e uma
única saída. Uma
intercalação marca
o final de um
6.5 Comportamento Paralelo
O comportamento condicional é feito através de Forks e Joins
Uma separação tem uma transição de entrada e várias
transações de saída. Quando uma transição de entrada é
acionada (triggered), todas as transições de saída são
executadas em paralelo.
Depois de uma separação e realização dos processo é
necessário se efetuar a junção
Separação e junção devem se completar. No caso mais
simples, isso significa que todas vez que você tiver uma
separação, deve ter
uma junção que uma
os threads iniciadas
por aquelas
separações
Thread condicional:
existe uma exceção
para regra de que
todos os estados de
entrada em uma junção devem ter terminado suas atividades,
antes que a junção possa ser efetuada. Você pode acrescentar
uma condição para um thread saindo de uma separação.
No exemplo, mesmo que você não esteja a fim de vinho, ainda
6.6 Decomposição
6.7 Raias
Permite que se documente o que acontece e quem faz
acontecer.
Permite que, em modelagem de domínio, o diagrama de
atividade represente pessoas ou departamentos responsáveis
por cada atividade.
Para usar raias, você deve organizar seus diagramas de
atividades em zonas verticais separadas por linhas. Cada zona
representa as responsabilidades de uma classe específica ou
um depto específico.
Combinam a descrição de lógica do diagrama de atividades com
a descrição de responsabilidade do diagrama de interação.
Podem ser
difíceis de
serem
projetadas em
um diagrama
Unified Modeling Language (UML)
Universidade Federal do Maranhão – UFMA Pós Graduação de Engenharia de Eletricidade
Grupo de Computação Assunto: Diagrama de Estado
Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
5 Diagrama de Estado
5.1 Definição
Trata-se de um complemento para a descrição das
classes, documentando os estados possíveis que objetos
de uma certa classe podem assumir, além de mostrar
ainda os eventos do sistema que geram tais mudanças.
Os diagramas de estado não são escritos para todas as
classes de um sistema, mas apenas para aquelas que
possuem um número definido de estados conhecidos e
onde o comportamento das classes é afetado e
modificado pelos diferentes estados.
Através da análise da mudança de estados dos tipos de
objetos de um sistema, podemos prever todos os
possíveis comportamentos de um objeto de acordo com
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, timer, erros, e
condições sendo satisfeitas) afetam estes estados ao
passar do tempo.
Todos os objetos possuem um estado que significa o
resultado de atividades executadas pelo objeto, e é
normalmente determinada pelos valores de seus atributos
e ligações com outros objetos.
Um objeto muda de estado quando acontece algo, o fato
de acontecer alguma coisa com o objeto é chamado de
evento.
Os objetos de uma classe habitualmente possuem um
ciclo de vida: são gerados, assumem posições durante a
sua vida, dão origem a outros objetos em classes
relacionadas e deixam de existir no momento de sua
destruição
Um diagrama de estado não capta – e não deve captar –
Se o diagrama de estado está se tornando uma
“miscelânea” de estados e condições, então muito
provavelmente é necessário repensar sua classe.
Devemos usar esse diagrama quando tivermos uma
classe com mais de um atributo, que reflitam o estado de
seus objetos em um determinado tempo, e que esses
atributos mereçam ser modelados visando simplificar sua
complexidade.
Se o relacionamento de classes não está claro o
suficiente em função do estado dos objetos, isso será
uma pista de que deve usar este diagrama. Essa
5.2 Notações do diagrama
Um retângulo designa um estado simples. O mais
comum usado nos diagramas de estado. Seus cantos
são arredondas. Um único valor,de um atributo de uma
classe, pode ser representado por um estado simples.
O estado tem 2 compartimentos, um com seu nome e o
outro com suas ações internas.
Um retângulo maior designa um estado composto ou
máquina de estado, significando que nele existirão
Estado composto por regiões. Essas regiões são
separadas por uma linha pontilhada, vertical ou
horizontal, dentro do estado. Cada região pode ter um
nome diferente e seus estados separados. Este estado
é conhecido como estado concorrente.
Um círculo preenchido
designa um estado inicial
chamado de
pseudo-estado inicial.
O estado final é representado por um círculo vazado e,
dentro deste, um círculo cheio. O último estado de um
Um círculo simples é um estado de escolha. Ao se
chegar a um estado de escolha, o software deve tomar
um decisão e ir para qualquer estado possível, dos que
saem do estado de escolha.
Podemos ter a necessidade de representar que vários
estados podem chegar em um único ponto. Este ponto
A chegada de um estado a um fork pode desencadear
um ou vários estados concorrentes.
O estado join representa vários estados convertendo-se
Entry action significa que a todo o momento que
entrarmos neste estado esta operação será realizada,
no caso, na operação funcXpto()
A transição está indicada com a operação (funXpta()) e
também com uma condição [se a = 2]. Esta condição é
chamada de Guard
No estado_simples2 temos exit action significando que
toda vez que sairmos do estado, esta operação será
realizada, no caso funcXptu().
Temos também um tipo de ação que é executado
durante todo o tempo de permanência naquele estado.
Esta ação é representada por do action.
Transição tem 3 partes opcionais: evento[guarda]/ação
Guarda é uma condição lógica que devolve SIM ou
NÃO
5.3 Dicas
Ações são associadas com transição e são
considerados como processos de curta duração, não
podendo ser interrompidos
Atividades são associados a estados e podem levar
mais tempo. Uma atividade pode ser interrompida por
algum evento.
