FACULDADE PITÁGORAS DE DIVINÓPOLIS

MODELAGEM COMPORTAMENTAL

DIVINÓPOLIS
ARIL/2011
FACULDADE PITÁGORAS DE DIVINÓPOLIS

MODELAGEM COMPORTAMENTAL

TRABALHO SOBRE MODELAGEM

COMPORTAMENTAL REFERENTE
À DISCIPLINA DE MODELAGEM E
GERÊNCIA

DIVINÓPOLIS
ABRIL/2011
DEDICATÓRIA

Dedicamos este trabalho ao professor Ernani, que

têm nos ensinado com compromisso e dedicação
assim como também, nossos familiares, que em tudo
tem nos apoiado.
AGRADECIMENTOS

Agradecemos a todos que colaboraram

direta ou indiretamente para a conclusão
deste trabalho.
““Unir-se é um bom começo, manter a união
é um progresso, e trabalhar
em conjunto é a vitória.” Henry Ford.
 LISTAS DE ILUSTRAÇÕES

Sumário

Figura 1- Diagrama de Casos de uso ................................................................................9

Figura 2. Subestados ........................................................................................................17

Figura 3 – Diagrama de estado ........................................................................................19

Figura 4 – Diagrama de sequencia ..................................................................................21

Figura 5 – Diagrama de colaboração ...............................................................................22

Figura 6 – Diagrama de atividade....................................................................................24

 SUMÁRIO

Modelagem Comportamental ........................................................................................ 8

Diagramas de Casos de Uso ........................................................................................... 9

Máquinas de Estado ..................................................................................................... 11

Conceitos: ...................................................................................................................... 11

Estado ............................................................................................................................ 11

Transições ...................................................................................................................... 12

Ações .............................................................................................................................. 14

Ações de Entrada e Saída............................................................................................. 14

Transições Internas ...................................................................................................... 15

Eventos Adiados............................................................................................................ 16

Subestados ..................................................................................................................... 17

Diagramas Estáticos e Dinâmicos ............................................................................... 18

Diagrama de Estado ..................................................................................................... 19

Figura 3 – Diagrama de estado.................................................................................... 19

Diagrama de Sequência ................................................................................................ 20

Figura 4 – Diagrama de sequencia .............................................................................. 21

Diagrama de Colaboração ........................................................................................... 22

Figura 5 – Diagrama de colaboração .......................................................................... 22

Diagrama de Atividade ................................................................................................ 23

Conclusão ...................................................................................................................... 25
Modelagem Comportamental

A modelagem comportamental de um sistema consiste, segundo a abordagem orientada

por objetos, em dois tipos distintos de especificações. Por um lado, na modelagem
comportamental interobjetos, ou seja, na identificação dos seus padrões de trocas de
mensagens (diagramas de interação). Por outro lado, na modelagem comportamental
intraobjeto, ou seja, na identificação dos estados em que um objeto pode se encontrar ao
longo do seu ciclo de vida, dos eventos envolvidos, bem como dos seus algoritmos de
implementação (diagramas de estados e atividades).

Podemos dizer que a modelagem comportamental descreve o comportamento do interior

do sistema, necessário para interagir com o ambiente. O modelo comportamental
representa o que o interior do sistema deve fazer para atender aos eventos apontados
pelo modelo ambiental, sendo o principal produto da análise de requisitos.

A modelagem de um sistema com base em diagramas de classes e de objetos traduz

apenas as suas relações estruturais e estáticas. Nada é revelado sobre o padrão interno e
externo do comportamento dos objetos ou relativamente à definição de determinado
algoritmo. A UML providencia os seguintes elementos que permitem a especificação do
comportamento de um sistema: objetos, interações, mensagens, estados, atividades,
sinais e eventos. Com base nestes elementos podem-se definir os seguintes tipos de
diagramas: diagrama de interações, diagramas de estados, e diagramas de atividades.
Diagramas de Casos de Uso

Um caso de uso é um padrão de comportamento que o sistema exibe. Cada caso de uso
é uma sequencia de transações relacionadas executadas por um ator e o sistema num
diálogo.

O diagrama de casos de uso especifica um conjunto de funcionalidades, atraves do

elemento sintatico “casos de uso”, e os elementos extrernos que interagem com o
sistema, atraves do elemento sintatico “ator” (SILVA, 2007). Alem de casos uso e
atores, este diagrama contem relacionamentos de dependência, generalização e
associação e são basicamente usados para fazer a modelagem de visão estática do caso
de uso do sistema. Essa visão proporciona suporte principalmente para o
comportamento de um sistema, ou seja, os serviços externamente visíveis que o sistema
fornece no contexto de seu ambiente. Neste caso os diagramas de caso de uso são
usados para fazer a modelagem do contexto de um sistema e fazer a modelagem dos
requisitos de um sistema.

Figura 1- Diagrama de Casos de uso

Como os casos de uso representam um objetivo do ator é comum dar como nome aos
casos de uso frases verbais curtas no infinitivo (EmprestarMaterial) ou no gerúndio
(EmprestandoMaterial) onde o sujeito é normalmente o ator.

Ex.

 O usuário empresta material

 O usuário pesquisa assunto

Cada caso de uso deve receber uma descrição textual que permita o entendimento do
objetivo. Esta descrição pode ser detalhada em cenários. Um cenário é uma instância de
um caso de uso, isto é, é uma situação onde o ator utilizou o sistema para conseguir
atingir o objetivo do caso de uso. Um cenário pode ser considerado otimista de o ator
obteve sucesso no seu objetivo, pode ser pessimista se o ator não conseguiu e ocorreu
uma situação de exceção, ou o cenário pode ser alternativo, quanto frente a uma
situação de exceção o ator optou por caminhos alternativos. Os diagramas de caso de
uso são importantes principalmente para a organização e modelagem dos componentes
de um sistema.
Máquinas de Estado

A Máquina de Estados pode ser entendida como uma representação matemática de um

sistema qualquer (não, necessariamente, apenas de software) que possui um número
limitado e contável de estados, sendo cada estado uma representação específica e
instantânea da condição atual de tal sistema.

Conceitos:

 É um sistema cuja saída é determinada por entradas passadas e corrente

 O efeito de entradas anteriores é representado por um estado

 É uma abstração composta por eventos (entradas), estados e ações

(saídas)

 Modela sistemas sequenciais

 Foram aplicadas para design de software a partir da década de 60

 Foram incorporadas pela UML

Elementos presentes em um diagrama de máquina de estados são:

Estado

Um estado é uma condição de um objeto em que ele realiza alguma atividade ou espera
um evento. Um objeto pode permanecer em um estado durante um tempo limitado. Um
estado tem várias propriedades:

Nome Uma seqüência de caracteres textuais que distingue o

estado de outros estados; um estado também pode ser
anônimo, ou seja, não ter nenhum nome.

Ações de entrada/saída As ações executadas ao entrar no estado ou sair dele.

Transições internas As transições que são manipuladas sem causar

mudança de estado.

Subestados A estrutura aninhada de um estado, envolvendo

subestados separados (ativos seqüencialmente) ou
simultâneos (ativos concomitantemente).

Eventos adiados Uma lista de eventos que não são manipulados no

estado, mas são adiados e enfileirados para serem
manipulados pelo objeto em outro estado.
Transições

Uma transição é um relacionamento entre dois estados indicando que um objeto no

primeiro estado executará certas ações, e entrará em um segundo estado quando ocorrer
um evento especificado e determinadas condições forem satisfeitas. Nessa mudança de
estado, diz-se que a transição foi 'acionada'. Até que a transição seja acionada, diz-se
que o objeto está no estado 'de origem'; após o seu acionamento, diz-se que o objeto está
no estado 'de destino'. Uma transição tem várias propriedades:

Estado de origem O estado afetado pela transição. Se um objeto estiver

no estado de origem, uma transição de saída poderá
ser acionada quando o objeto receber um evento
trigger da transição e quando a condição de guarda, se
houver, for satisfeita.

Trigger de evento O evento que torna a transição passível de ser

acionada (contanto que sua condição de guarda seja
cumprida) quando recebido pelo objeto no estado de
origem.

Condição de guarda Uma boolean expression que é avaliada quando a

transição é disparada pela recepção do disparador de
evento. Se o valor da expressão for Verdadeiro, a
transição poderá ser acionada; se a expressão for
Falso, a transição não será acionada. Se não houver
outra transição que possa ser disparada pelo mesmo
evento, o evento será perdido.

Ação Um cálculo indivisível executável que pode agir

diretamente sobre o objeto que possui a máquina de
estado e indiretamente em outros objetos visíveis ao
objeto.

Estado de destino O estado que é ativado após a conclusão da transição.

Uma transição pode ter várias origens (nesse caso, ela representa uma junção de vários
estados simultâneos) e vários alvos (nesse caso, ela representa uma forquilha para vários
estados simultâneos).
Condições de Guarda

Uma condição de guarda é avaliada após o evento trigger acionar a transição. É possível
que haja várias transições do mesmo estado de origem e com o mesmo trigger de
evento, contanto que as condições de guarda não se sobreponham. Uma condição de
guarda é avaliada apenas uma vez para a transição no momento em que o evento ocorre.
A expressão booleana pode fazer referência ao estado do objeto.
Ações

Uma ação é um cálculo indivisível executável, ou seja, ela não pode ser interrompida
por um evento e, portanto, é executada até a sua conclusão. Isso contrasta com uma
atividade, que pode ser interrompida por outros eventos. As ações podem incluir
chamadas de operação (para o proprietário da máquina de estado, bem como para outros
objetos visíveis), a criação ou a destruição de outro objeto, ou o envio de um sinal para
outro objeto. No caso de envio de um sinal, o nome do sinal recebe como prefixo a
palavra-chave 'send'.

Ações de Entrada e Saída

As ações de entrada e de saída permitem que uma mesma ação seja enviada sempre que
um estado entra ou sai, respectivamente. As ações de entrada e de saída permitem que
isso seja feito adequadamente, sem precisar colocar ações explícitas em todas as
transições de entrada e de saída. As ações de entrada e de saída não devem ter
argumentos ou condições de guarda. As ações de entrada no nível mais alto da máquina
de estado para um elemento de modelo podem ter parâmetros que representam os
argumentos que a máquina receberá quando o elemento for criado.
Transições Internas

As transições internas permitem que eventos sejam manipulados dentro do estado,

evitando, com isso, disparar ações de entrada ou de saída. As transições internas podem
ter eventos com parâmetros e condições de guarda e representam, essencialmente,
manipuladores de interrupção.
Eventos Adiados

Os eventos adiados são aqueles cuja manipulação é adiada até que um estado em que o
evento não seja adiado se torne ativo. Quando esse estado se torna ativo, a ocorrência do
evento é disparada e pode causar transições como se ele tivesse acabado de ocorrer. A
implementação de eventos adiados requer a presença de uma fila interna de eventos.
Quando um evento ocorre mas está listado como adiado, ele é enfileirado. Os eventos
sairão da fila tão logo o objeto entre em um estado que não adie esses eventos.
Subestados

Um estado simples é aquele que não possui subestrutura. Um estado que possui
subestados (estados aninhados) é denominado estado composto. Os subestados podem
ser aninhados em qualquer nível. Uma máquina de estados aninhados deve ter no
máximo um estado inicial e um estado final. Os subestados são usados para simplificar
máquinas complexas de estados simples mostrando que alguns estados são possíveis
apenas dentro de um determinado contexto (o estado confinado).Ver Figura1.

Figura 2. Subestados.

A partir de uma origem externa ao estado composto confinado, uma transição pode ter
como objetivo um estado composto ou um subestado. Se o seu alvo for o estado
composto, a máquina de estados aninhados deverá conter um estado inicial, para o qual
o controle passará após entrar no estado composto e após enviar sua ação de entrada (se
houver alguma). Se o seu alvo for o estado aninhado, o controle passará para o estado
aninhado após enviar a ação de entrada do estado composto (se houver alguma) e, em
seguida, a ação de entrada do estado aninhado (se houver alguma).

Uma transição orientada para fora de um estado composto pode ter como sua origem o
estado composto ou um subestado. Nos dois casos, o controle sai primeiro do estado
aninhado (e sua ação de saída, se houver, é enviada) e, em seguida, sai do estado
composto (e sua ação de saída, se houver, é enviada). Uma transição, cuja origem é o
estado composto intrinsecamente, interrompe a atividade da máquina de estados
aninhados.
Diagramas Estáticos e Dinâmicos

Todos os sistemas possuem uma estrutura estática e um comportamento dinâmico. A

UML suporta modelos estáticos (estrutura estática), dinâmicos (comportamento
dinâmico) e funcional. A Modelagem estática é suportada pelo diagrama de classes e de
objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos podem ser
de associações, herança (generalização), dependência ou refinamentos. Os
modelamentos dinâmicos são suportados pelos diagramas de estado, sequência,
colaboração e atividade. E o modelamento funcional é suportado pelos diagramas de
componente e execução.
Diagrama de Estado

O diagrama de estado é tipicamente um complemento para a descrição das classes.

Este diagrama mostra todos os estados possíveis que objetos de uma certa classe podem
se encontrar e mostra também quais são os eventos do sistemas que provocam tais
mudanças.

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.

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.

Figura 3 – Diagrama de estado

Diagramas de estado possuem um ponto de início e vários pontos de finalização. Um

ponto de início (estado inicial) é mostrado como um círculo todo preenchido, e um
ponto de finalização (estado final) é mostrado como um círculo em volta de um outro
círculo menor preenchido. Um estado é mostrado como um retângulo com cantos
arredondados. Entre os estados estão as transições, mostrados como uma linha com uma
seta no final de um dos estados. A transição pode ser nomeada com o seu evento
causador. Quando o evento acontece, a transição de um estado para outro é executada
ou disparada.

Uma transição de estado normalmente possui um evento ligado a ela. Se um evento é

anexado a uma transição, esta será executada quando o evento ocorrer. Se uma transição
não possuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do código
do estado for executada (se existir ações internas como entrar, sair, fazer ou outras ações
definidas pelo desenvolvedor). Então quando todas as ações forem executadas pelo
estado, a transição será disparada e serão iniciadas as atividades do próximo estado no
diagrama de estados.

Diagrama de Sequência

Um diagrama de sequência mostra a colaboração dinâmica entre os vários objetos de

um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a
sequência de mensagens enviadas entre os objetos. Ele mostra a interação entre os
objetos, alguma coisa que acontecerá em um ponto específico da execução do sistema.

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

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

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

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

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

Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de

execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado
como ativação, mensagens assíncronas, ou objetos assíncronos.
 Figura 4 – Diagrama de sequencia

Os diagramas de sequência podem mostrar objetos que são criados ou destruídos como
parte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos
através de mensagens. A mensagem que cria ou destroi um objeto é geralmente
síncrona, representada por uma seta sólida.
Diagrama de Colaboração

Um diagrama de colaboração mostra de maneira semelhante ao diagrama de sequência,

a colaboração dinâmica entre os objetos. Normalmente pode-se escolher entre utilizar o
diagrama de colaboração ou o diagrama de sequência.

No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos,

percebe-se também os objetos com os seus relacionamentos. A interação de mensagens
é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é
melhor escolher o diagrama de sequência, mas se a ênfase for o contexto do sistema, é
melhor dar prioridade ao diagrama de colaboração.

O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos

objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens
são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As
mensagens são nomeadas, que entre outras coisas mostram a ordem em que as
mensagens são enviadas.

Também podem mostrar condições, interações, valores de resposta, e etc. O diagrama

de colaboração também pode conter objetos ativos, que executam paralelamente com
outros.

Figura 5 – Diagrama de colaboração

Diagrama de Atividade
Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho
executado na implementação de uma operação (método), e suas atividades numa
instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado
e possui um propósito um pouco diferente do diagrama de estado, que é o de 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 ser necessário especificar nenhum evento como no diagrama de
estado).

Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas
como "swimlanes". Uma swimlane agrupa atividades, com respeito a quem é
responsável e onde estas atividades residem na organização, e é representada por
retângulos que englobam todos os objetos que estão ligados a ela (swimlane).

Um diagrama de atividade é uma maneira 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 (sequência das ações), e onde elas
acontecem (swimlanes).

Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:

 Para capturar os trabalhos que serão executados quando uma operação é

disparada (ações). Este é o uso mais comum para o diagrama de atividade.

 Para capturar o trabalho interno em um objeto.

 Para mostrar como um grupo de ações relacionadas podem ser executadas, e

como elas vão afetar os objetos em torno delas.

 Para mostrar como uma instância pode ser executada em termos de ações e
objetos.

 Para mostrar como um negócio funciona em termos de trabalhadores (atores),

fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no
negócio).

O diagrama de atividade mostra o fluxo sequencial das atividades, é normalmente

utilizado para demonstrar as atividades executadas por uma operação específica do
sistema. Consistem em estados de ação, que contém 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 mostrados no diagrama de atividade. O diagrama também
pode conter especificações de mensagens enviadas e recebidas como partes de ações
executadas.
Figura 6 – Diagrama de atividade
Conclusão

Concluímos que a modelagem comportamental Descreve os aspectos da dinâmica

interna de um SI, qual é a lógica interna dos processos sem especificar como serão
implementados. Ela é de extrema importância para a especificação do funcionamento do
sistema, orientando os programadores que irão implementares as classes, assim como
também clientes que poderão opinar no processo de construção no sistema, já que
conhecem muito bem como funcionam os processos para os quais o sistema irá
trabalhar.