MODELAGEM DE INTERAÇÕES
INTRODUÇÃO
• Suponha que já existam os seguintes modelos de um sistema OO em
desenvolvimento:
–
Modelo de casos de uso (MCU)
–
Modelo de classes de análise (MCA)
• Para continuar a fase de análise, é desejável ter uma noção mais
concreta do
comportamento
dos objetos do SSOO, o que é feito
através da
modelagem de interações
.
• A modelagem de interações pode ser dividida em:
– Modelagem de interações de análise (MIA)
– Modelagem de interações de projeto (MIP)
• O MCU é fonte para construir o MCA, e ambos são fontes para
construir o MIA.
EVENTOS DE SISTEMA
• Um
evento de sistema
(system event) é alguma ocorrência gerada
pelo ambiente do sistema que faz com que este último realize
alguma ação quando o evento é gerado.
– Eventos de sistema representa o conceito fundamental do MIA.
• No contexto do MCU, eventos de sistemas são gerados pelas ações
do(s) ator(es) no cenário de determinado caso de uso.
– No caso particular em que o ator é um ser humano e existe
uma interface gráfica, eventos do sistema são resultantes de
ações desse ator sobre essa interface gráfica.
• De acordo com o Processo Unificado, eventos do sistema são
representados em
diagramas de seqüência de sistema
(DSS).
DIAGRAMAS DE SEQUÊNCIA DO SISTEMA
• Um DSS especifica graficamente o comportamento de
um cenário de um caso de uso.
• Note que DSS não é uma definição encontrada na UML,
mas sim no Processo Unificado (
conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software, combina os ciclos iterativo e incremental para a construção de softwares).
• Esse diagrama mostra:
1. os
atores
que interagem com o sistema,
2. o
sistema
(como uma caixa preta) e
3. os
eventos de sistema
que os atores geram, apresentados na
ordem em que ocorrem no cenário do caso de uso.
• Um DSS pode ser criado para cada fluxo relevante de um
caso de uso.
EXEMPLO DE DSS
Caso de Uso (Realizar Empréstimo
(fluxo principal)
)
1. Atendente inicia a realização de empréstimo, e fornece o
identificador do leitor.
2. Sistema apresenta o nome e situação do leitor.
3. Para cada livro a emprestar:
a. Atendente fornece o identificador do livro a
emprestar.
b.
Sistema
apresenta
a
data
de
devolução
correspondente.
4. Atendente encerra a realização de empréstimo, e o caso
de uso termina.
EXEMPLO DE DSS
OPERAÇÕES DE SISTEMA
• Um evento de sistema inicia uma
operação de
sistema.
• Um evento e sua operação correspondente têm o
mesmo nome (assim como mensagens e
métodos).
• Por
exemplo,
no
DSS
anterior,
temos
apresentadas as seguintes operações de sistema:
1. iniciarEmprestimo(idLeitor)
2. emprestarLivro(idLivro)
OPERAÇÕES DE SISTEMA
• Note que o objeto denominado “Sistema” é apenas
um artifício de modelagem.
– Na verdade, as operações de sistema são alocadas ao
controlador do caso de uso (categorização BCE...).
• Há dois tipos de operação de sistema:
– Operações com parâmetros
, que correspondem a
eventos
informativos
(ex.:
emprestarLivro,
iniciarEmprestimo).
– Operações
sem
parâmetros
,
que
usualmente
correspondem
a
eventos
de
controle
(ex.:
encerrarEmprestimo).
CATÁLOGO DE CONTRATOS DAS
OPERAÇÕES DE SISTEMA
CONTRATOS DAS OPERAÇÕES
• Um
contrato
de
operação
documenta
textualmente o comportamento esperado para
uma operação de sistema.
• O
catálogo de contratos
corresponde a todos
os contratos das operações de sistema.
• Sua construção parte dos seguintes artefatos:
– do modelo de classes conceitual,
– dos DSS (e da identificação das operações de
sistema correspondentes).
SEÇÕES TÍPICAS DE UM CONTRATO
• Nome da operação e parâmetros de
entrada
• Responsabilidade (objetivo)
• Referências cruzadas (para casos de uso,
regras de negócio, etc.)
• Pré-condições
• Pós-condições
EXEMPLO DE CONTRATO
Operação: encerrarEmpréstimo()
Responsabilidade:
– Encerrar o registro de empréstimo a um leitor.
Referências Cruzadas:
– Caso de Uso “Emprestar Livro”
Pré-Condições:
– um leitor apto a emprestar livros já foi identificado;
– pelo menos um livro já foi identificado e está disponível para ser
emprestado.
Pós-Condições:
– um novo empréstimo foi registrado;
– o novo empréstimo foi relacionado ao leitor já identificado na
operação “iniciar o empréstimo”;
EXEMPLO
• Caso
de
Uso:
Fornecer
Grade
de
Disponibilidades
• Ator Primário: Professor
• Sumário: Professor fornece a sua grade de
disponibilidade(ex.:, as disciplinas que deseja
lecionar, juntamente com dias e respectivos
horários em que está disponível para dar aulas)
para o próximo semestre letivo.
EXEMPLO (cont.)
Fluxo principal do caso de uso:
1. Professor fornece sua matrícula para validação.
2. Sistema apresenta o nome do professor e a lista de
disciplinas disponíveis (conforme RN04).
3. Professor informa cada disciplina que deseja lecionar.
4. Sistema apresenta a lista de dias da semana e de
horários.
5. Professor informa cada disponibilidade para o
próximo semestre letivo.
6. Professor confirma o registro de sua grade.
7. Sistema
registra a grade fornecida e o caso de uso
termina.
EXEMPLO (cont.)
EXEMPLO (cont.)
• Nesse caso de uso, há os seguintes eventos de sistema:
1. Solicitação de validação de matrícula de professor;
2. Solicitação de adição de uma disciplina à grade;
3. Solicitação de adição de um item de disponibilidade (dia,
hora inicial e hora final) à grade;
4. Confirmação de registro da grade.
• As operações de sistema correspondentes identificadas são:
1. validarProfessor(matrícula);
2. adicionarDisciplina(nomeDisciplina);
3. adicionarItemDisponibilidade(dia, horaInicial, horaFinal).
4. registrarGrade()
EXEMPLO (cont.)
• Na continuação dessa tarefa de modelagem, cada
operação de sistema identificada deveria ser
documentada em um contrato.
• Esses contratos, uma vez construídos, propiciam o
início da modelagem de interações de projeto.
• O objetivo da modelagem de interações de projeto é
identificar quais mensagens são trocadas pelos
objetos do sistema para produzir o evento de saída
correspondente a cada operação de sistema.
CONCLUSÕES
• A modelagem de interações na fase de análise (MIA)
serve para:
1. confirmar se o MCA está correto, (i.e., detectar erros
ou omissões no modelo de classes conceitual), e
2. determinar as operações de sistema, que são o ponto
de partida para a modelagem de interações de projeto.
A frase a seguir resume o objetivo da MIA:
“[A]s operações [...] de sistema, em conjunto,
correspondem à totalidade das funções possíveis do
sistema, ou seja, à funcionalidade efetiva total do
sistema.”
MODELAGEM DE INTERAÇÃO DE PROJETO (MIP)
• Os artefatos de análise:
– Modelo de casos de uso (MCA)
– Modelo de classes de análise (MCU)
• Versão inicial das classes conceituais e das que participam em cada caso de uso.
– Modelo de interações de análise (MIA)
• Diagramas de seqüência de sistema • Catálogo das operações de sistema.
• Próximo passo: construir o
modelo de interações de
projeto
, para estudar o que acontece dentro de cada caso
de uso quando ele é executado.
MODELAGEM DE INTERAÇÃO DE PROJETO (MIP)
• Esse modelo representa o aspecto dinâmico da
modelagem:
objetos
envolvidos e
mensagens
por eles
trocadas em cada caso de uso.
• Em uma perspectiva
interna
, o MIP apresenta o que o
SSOO realiza para que atores atinjam seus objetivos na
utilização dos casos de uso.
• A correta construção do MIP depende:
– Da experiência do modelador;
– De aspectos micro e macro arquiteturais;
MODELAGEM DE INTERAÇÃO DE PROJETO (MIP)
• No contexto de execução de cada operação de sistema,
são relevantes as seguintes perguntas:
– Quais as responsabilidades de cada objeto?
– Como os objetos estão arquiteturalmente dispostos?
– Que objetos enviam mensagens para que outros?
– Há outros objetos ainda não identificados?
– Quais as consequências da construção do MIP sobre os modelos
já construídos?
• Essas questões são abordadas através da modelagem de
interações da fase de projeto de um SSOO.
MENSAGENS E OPERAÇÕES
• Um objeto A envia uma mensagem a outro B para
solicitar a realização de alguma operação definida na
TIPOS DE DIAGRAMA DE INTERAÇÃO
• Há quatro tipos de diagrama de interação na UML
2.4 usados para construir modelos de interações:
– Diagrama de sequência (sequence diagram)
– Diagrama de comunicação (communication diagram)
– Diagrama de visão geral da interação (interaction
overview diagram)
TIPOS DE DIAGRAMADE INTERAÇÃO
• Diagrama de sequência:
Seu foco é nas mensagens
enviadas no decorrer do tempo.
• Diagrama de comunicação:
Seu foco é nas mensagens
enviadas entre objetos que estão relacionados.
• Diagrama de visão geral de interação:
Utilizado para
apresentar uma visão geral de diversas interações entre
objetos, cada uma delas representada por um diagrama de
seqüência
(comunicação).
Útil
para
modularizar
a
construção
do
diagramas
de
sequência
(ou
de
comunicação).
• Diagrama de temporização:
Útil para modelar sistemas de
tempo real: restrições de tempo entre um conjunto de
objetos.
DIAGRAMA DE SEQUÊNCIA
• O Diagrama de Sequência preocupa-se com a ordem
temporal
em que as mensagens são trocadas entre os objetos envolvidos
em um determinado processo.
• Em geral, baseia-se em um
Caso de Uso
definido pelo diagrama
de mesmo nome e apóia-se no
Diagrama de Classes
para
determinar os objetos das classes envolvidas em um processo,
bem como os métodos disparados entre os mesmos.
• Um Diagrama de Sequência costuma identificar o evento gerador
do processo modelado, bem como, o ator responsável por este
evento e determina como o processo deve se desenrolar e ser
concluído por meio do
envio de mensagens
, que em geral
disparam
métodos, entre os objetos
.
EXEMPLO DE DS
Tempo (top-down) ObjetoA ObjetoB [se novo] <<create>> mensagem valor de retorno <<destroy>> (caixa de)ativação condição de guarda mensagem síncrona objeto símbolo de destruição linha de vida autochamadaELEMENTOS DE UM DS
Elementos de um diagrama de sequência:
– Participantes (atores, objetos, classes, etc.)
– Mensagens
– Linhas de vida e ativações
– Ramificações (desvios condicionais) e
iterações
ELEMENTOS DE UM DS
• Atores: Os atores modelados neste diagrama são
instâncias dos atores declarados no diagrama de casos
de uso, representando entidades externas que
interagem com o sistema, gerando assim eventos que
iniciam processos.
ELEMENTOS DE UM DS
• LifeLine: Um LifeLine é participante individual em cada
interação. Na maioria das vezes um LifeLine irá se
referir a uma instância de uma classe que participa de
uma interação. Em geral um
LifeLine
é um
Objeto
.
Acima temos um LifeLine chamado pesfis1, esse lifeline é uma
instância da classe Pessoa_Fisica.
Um LifeLine pode existir desde o início do processo ou ser criado
durante o decorrer da execução do mesmo.
ELEMENTOS DE UM DS
• Linha da Vida: A linha da vida representa o tempo em que um
objeto existe durante um processo. As linhas da vida são
representadas por linhas finas verticais tracejadas, em algum
momento a linha da vida de um objeto pode ser interrompida
com um “X” representado assim a destruição do objeto.
ELEMENTOS DE UM DS
• Foco de Controle ou Ativação: Indica os períodos em que um
determinado objeto está participando ativamente de um
processo. Os focos de controle são representados dentro da linha
da vida de um objeto, porém enquanto as linhas da vida são
representadas por tracejados finos o foco de controle é
representado por um linha mais grossa.
ELEMENTOS DE UM DS
• Mensagens ou Estímulos: As mensagens são utilizadas para demonstrar a ocorrência de
eventos, que normalmente forçam a chamada de um método em algum dos objetos envolvidos no processo. Pode ocorrer, no entanto, de uma mensagem representar uma comunicação entre dois atores, nesse caso não disparando métodos. Um diagrama de sequência em geral é iniciado por um evento externo, causado por algum ator o que acarreta o disparo de um método em um dos objetos.
– Um ator e outro ator
– Um ator e um Objeto, onde um ator produz um evento que dispara um método.
– Um objeto e outro objeto o que constitui a ocorrência mais comum de mensagens, onde um objeto transmite uma mensagem para outro, em geral solicitando a execução de um método. – Um objeto e um ator, o que normalmente ocorre quando um objeto envia uma mensagem de
ELEMENTOS DE UM DS - Tipos de Mensagens
· Mensagens Síncronas
• Mensagens síncronas são mensagens que implicam um sincronismo rígido entre os estados do objeto que envia a mensagem e os do objeto de destino da mensagem. Um sincronismo entre objetos pode ser entendido, de uma forma geral, como uma dependência na evolução de estado de um objeto sobre o estado de um segundo objeto.
• De uma forma mais direta, pode-se dizer que uma mensagem síncrona implica que o objeto que enviou a mensagem aguarde a conclusão do processamento da mensagem (entendida como um sinal de sincronismo) feito pelo objeto destino, para então prosseguir seu fluxo de execução. Alguns sistemas operacionais oferecem também mecanismos de troca de mensagens síncronas de forma que o objeto que envia a mensagem fique em estado de espera até a conclusão do tratamento da mensagem. • A notação UML para uma mensagem síncrona é a de um segmento de reta com uma
ELEMENTOS DE UM DS - Tipos de Mensagens
Mensagens Assíncronas
• Mensagens assíncronas são mensagens enviadas de um objeto a outro sem que haja uma dependência de estado entre os dois objetos. O objeto de origem envia a mensagem e prossegue seu processamento independentemente do tratamento da mensagem feita no objeto destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais são o exemplo mais comum deste tipo de mensagem. Além disso, de uma forma geral, todas as comunicações entre atores e objetos representam trocas de mensagem assíncronas.
• Considere, por exemplo, uma operação para apresentação de uma mensagem no monitor. Um objeto executa uma instrução print (ou print ou write) e o sistema despacha a mensagem para o ator (o monitor). O objeto prossegue seu processamento independentemente do desfecho na operação. Observe que os softwares não bloqueiam quando o monitor não apresenta alguma informação. A notação UML para uma mensagem assíncrona é a de um segmento de reta com uma meia seta em uma das extremidades.
ELEMENTOS DE UM DS
• Mensagens de Retorno: Esse tipo de mensagem identifica a resposta
a uma mensagem para o objeto ou ator que a chamou. Uma
mensagem de retorno pode retornar informações específicas do
método chamado ou apenas um valor indicando se o método foi
executado com sucesso ou não.
• As mensagens de retorno são representadas por uma linha tracejada
contendo uma seta fina que aponta para o objeto que recebe o
resultado.
Mensagens – Condições de Guarda
• Mensagens podem apresentar condições de guarda
– condições em que a mensagem é enviada
– [condição de guarda]
ELEMENTOS DE UM DS
• Autochamadas ou Autodelegações: Autochamadas são mensagens
que um objeto envia para si mesmo. No caso de autochamadas, uma
mensagem parte da linha da vida do objeto e atinge a linha da vida
do próprio objeto.
Mensagens de Autodelegação podem ser
síncronas ou assíncronas. O caso mais comum de mensagens
assíncronas é o envio de uma mensagem de um objeto para ele
mesmo através de mecanismos de envio de mensagens do
sistema operacional. O caso mais comum de mensagens de
Autodelegação síncronas é a chamada de função de um objeto
pelo próprio objeto.
ELEMENTOS DE UM DS
• Detalhes de Tempo: às vezes é necessário definir detalhes de tempo de uma mensagem, como por exemplo, o tempo máximo de espera até que uma mensagem seja disparada, deve-se usar restrições de tempo que uma mensagem leva em consideração antes de ser disparada. Ela deve ser demonstrada na diagonal.
c v
c v
ELEMENTOS DE UM DS
• Mensagens Perdidas e Encontradas: Uma mensagem perdida representa uma mensagem que foi enviada e sua confirmação de recebimento não foi recebida, podendo significar que a mensagem não chegou ao seu destino, ou pode ainda representar uma mensagem enviada a um destino não representado no diagrama.
• Uma mensagem encontrada representa o recebimento de uma mensagem enviada por um elemento desconhecido ou um elemento não representado no diagrama, ou o recebimento de uma mensagem que fora dada como perdida, pois seu tempo de espera por resposta pode ter sido encerrado.
ELEMENTOS DE UM DS
Quadros(frames)
• Servem para modularizar a construção de diagramas de interação.
• Objetivos específicos:
– Dar um nome ao diagrama que aparece dentro do quadro; – Fazer referência a um diagrama definido separadamente; – Definir o fluxo de controle da interação.
ELEMENTOS DE UM DS
Fragmentos de Interações
• Um Fragmento de Interação é uma noção abstrata de uma unidade de interação geral.
• Um Fragmento de Interação é uma parte de uma interação, no entanto, cada fragmento de interação é considerado como uma interação independente.
• Um Fragmento de Interação é representado como um retângulo que envolve toda a interação, além de conter uma aba no canto superior esquerdo, que contém o operador “sd”, que determina que o Fragmento representa um Diagrama de Interação.
A palavra verdadeiro utilizada como retorno é para indicar o sucesso da operação, o retorno correto seria 1 para indicar que o
cliente foi encontrado e 0 para o caso de não encontrado
ELEMENTOS DE UM DS
Interações
• Uma das principais vantagens do uso de fragmentos de interação caracteriza-se pela possibilidade de poder referenciá-los por meio do operador REF, que é abreviatura de referido e significa que se deve procurar por um diagrama cujo nome é o mesmo do nome apresentado ao operador REF, ou seja, o fragmento faz referência a outro diagrama não detalhado no diagrama em questão e que deve ser inserido neste.
O cliente, solicitou ao funcionário o encerramento da conta, para que ocorra o encerramento pode ser preciso sacar ou depositar algum valor. O processo de emissão de saldo já se encontra modelado em um diagrama a parte.
ELEMENTOS DE UM DS – Exemplo1
• Sistema de vendas online: Neste sistema o cliente pode consultar o carrinho de compras a qualquer momento, no entanto, caso este resolva confirmar o pedido, o sistema obrigatoriamente deverá chamar a rotina de Visualização de Carrinho.• Assim, como o processo de Visualização de Carrinho pode ser chamado de várias partes do sistema, é mais prático modelá-lo em separado e referenciá-lo sempre que for necessário, como é demonstrado neste caso.
• É bastante comum encontrar Ocorrências de Interação simplesmente sobrepostas às linhas de vida dos objetos que fazem parte do processo, sem nem ao menos chamá-las por meio de uma mensagem, como se as instruções contidas nas Ocorrências de Interação fossem adicionadas automaticamente ao diagrama
ELEMENTOS DE UM DS – Exemplo2
• Como o leitor pode observar, na figura abaixo apresenta o mesmo exemplo da figura anterior, no entanto, neste caso o Fragmento de Interação está simplesmente sobre a linha de vida dos objetos envolvidos no processo.
• As Ocorrências de Interação podem se constituir a uma simples chamada a outro Fragmento de Interação ou podem passar parâmetros para o Fragmento, receber o retorno da chamada do Fragmento ou ambos.
ELEMENTOS DE UM DS
Portões (Gates)
• Tem a finalidade de 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.
ELEMENTOS DE UM DS
Fragmentos Combinados e Operadores de
Interação
ELEMENTOS DE UM DS
Operadores de Fragmentos
• Alt – Abreviatura de Alternatives (Alternativas). Este Operador de Interação define que o Fragmento Combinado representa uma escolha de comportamento, onde uma escolha será selecionada em detrimento das outras. Os Fragmentos Combinados cujos Operadores de Interação forem deste tipo costumam utilizar Condições de Guarda, para definir o tipo de teste que deve ser levado em consideração na escolha de um dos possíveis comportamentos, sendo comum encontrar Condições de Guarda do tipo Se (Condição) e Senão, normalmente encontradas em testes do tipo se-então.
ELEMENTOS DE UM DS
Operadores de Fragmentos
• Opt – Abreviatura de Option (Opção). Este Operador de Interação determina que o Fragmento Combinado representa uma escolha de comportamento onde este comportamento será ou não executado, não havendo uma escolha entre mais de um comportamento possível.
• Da continuidade ao processo de encerramento de conta, onde após se realizado o saque ou depósito, pode ser necessário fazer a manutenção da conta do cliente tornando-o inativo.
ELEMENTOS DE UM DS
Operadores de Fragmentos
• Par – Abreviatura de Parallel (Paralelo). Este Operador de Interação determina que o Fragmento Combinado representa uma execução paralela de dois ou mais comportamentos.
• O Ator Motorista deve realizar duas operações simultâneas sobre o objeto car1 da classe Carro, para poder dirigi-lo, soltar a embreagem e pressionar o acelerador. Observe que uma linha tracejada divide os Operandos de Interação representando cada operação paralela
ELEMENTOS DE UM DS
Operadores de Fragmentos
• Loop – Abreviatura de Looping (Laço). Este Operador de Interação determina que o Fragmento Combinado representa um laço que poderá ser repetido diversas vezes
ELEMENTOS DE UM DS
Operadores de Fragmentos
• Break (Quebra) – Este Operador de Interação indica uma “quebra” na execução normal do processo. É usado principalmente para modelar o tratamento de exceções.
• Neste exemplo demos continuidade ao processo representado no exemplo anterior, onde identificamos uma situação em que pode ocorrer uma exceção, devido a algum registro estar corrompido ou algum campo possuir valores inválidos, por exemplo. Dessa maneira criamos um método TratExcecao (Tratamento de Exceção), pertencente à classe Exceção, para tratar possíveis exceções que venham ocorrer durante a atualização dos produtos.
ELEMENTOS DE UM DS
Operadores de Fragmentos
• Critical Region (Região Crítica) – Este Operador de Interação identifica uma Operação Atômica que não pode ser interrompida por outro processo até ser totalmente concluída. • O exemplo abaixo foi utilizado para ilustrar os dois últimos Operadores de Interação, envolvendo o laço de atualização de produtos com um Fragmento Combinado do tipo Critical, indicando que a atualização dos produtos não deverá ser interrompida até que o processo seja totalmente concluído.
ELEMENTOS DE UM DS
Invariante de Estado (StateInvariant)
• Um invariante de estado é uma restrição de tempo de execução aplicada aos participantes da interação. Ela pode ser usada para especificar diferentes tipos de restrições, tais como valores de atributos ou variáveis estados externos ou internos
• A restrição Invariante de estado estabelece uma condição para que o comportamento pretendido de um ou mais elementos de um diagrama possa ser executado.