Unified Modeling Language (UML) - Modelação do Comportamento - Alberto Manuel Rodrigues da Silva Prof. DEI/IST/UTL Análise e Concepção de Sistemas de Informação

Unified Modeling Language (UML)- Modelação do Comportamento -

Alberto Manuel Rodrigues da SilvaProf. DEI/IST/UTL

Análise e Concepção de Sistemas de Análise e Concepção de Sistemas de InformaçãoInformação

2ACSI/UML-Dynamic, Copyright, Alberto Silva

Modelação da Dinâmica do ComportamentoModelação da Dinâmica do Comportamento

Use Cases Diagramas de Use Case Interacções Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

«…qualquer sistema minimamente interessante os objectos não estão estáticos, mas interagem entre si através da troca de mensagens …»


Use Cases (Casos de Utilização)Use Cases (Casos de Utilização)

O modelo de use-case captura os requisitos de um sistema, através do detalhe de todos os cenários que os utilizadores podem realizar.

O modelo do comportamento (ou da dinâmica) de um sistema começa com a análise de use-cases.

Os use-cases, mais que iniciar a modelação do comportamento de um sistema, dirigem/conduzem esse mesmo modelo.


Use CasesUse Cases

... é uma sequência de acções que um ou mais actores realizam num sistema para obter um resultado particular

Deve ser representado por uma frase na voz activa, com um verbo no infinitivo.

E.g., “Gerar relatórios”, “Criar factura”, “Calibrar roda”

Use case


Use CasesUse Cases

... é uma sequência de acções que um ou mais actores realizam num sistema para obter um resultado particular

Note-se que tendo em consideração a definição de caso de utilização “Validar Utilizador” não deverá ser encarado como um “verdadeiro” caso de utilização, já que por si só não produz qualquer “resultado particular” para o sistema.

Contudo, nalgumas circunstâncias estes “pseudo” casos de utilização aparecem no modelo de forma a explictar comportamentos comuns a vários casos de utilização. (Tais comportamentos poderão alternativamente ser especificados através de assunções, ao nível de cada caso ou mesmo ao nível geral do modelo.)

Use case


Use Cases e CenáriosUse Cases e Cenários

Um use-case descreve o que faz um sistema (ou parte deste), mas não como é que tal é realizado.

Foco na visão externa do sistema Um use case é uma colecção de cenários

Um cenário é uma determinada sequência de acções que ilustra um comportamento do sistema. – Numa definição mais abstracta, pode-se entender um cenário

como uma instância de um caso de utilização, – é normal que um caso de utilização possa ser descrito por

dezenas de possíveis cenários


Use Cases – Especificação TextualUse Cases – Especificação Textual

Pode-se especificar o comportamento de um use-case descrevendo textualmente o fluxo de eventos, de modo que um utilizador não técnico o possa entender. Tal especificação deve incluir:– Assunções– Pré-condições– Inicialização: como e quando o caso de utilização começa – Diálogo: quando é que o caso de utilização interactua com os

actores– Conclusão: como e quando o caso de utilização termina– Pós-condições

Outras formas:– Actores que iniciam, que beneficiam...– Diagramas de sequência e/ou de actividades...


Use Cases – Exemplo ATMUse Cases – Exemplo ATM

Fluxo de Eventos PrincipalO caso de utilização inicia-se quando o sistema apresenta um écran a pedir ao cliente o seu cartão electrónico. O cliente introduz o seu cartão MB e, através de um pequeno teclado, o seu PIN. Note-se que o cliente pode limpar a introdução do seu PIN inúmeras vezes e reintroduzir um novo número antes de activar o botão “Entrar”. O cliente activa o botão “Entrar” para confirmar. O sistema lê o PIN e a respectiva identificação do cartão MB, e verifica se é válido. Se o PIN for válido o sistema aceita a entrada e o caso de utilização termina.

Validar UtilizadorDescrição textual de um use case


Use Cases - Exemplo ATM (cont.)Use Cases - Exemplo ATM (cont.)

Cenário Alternativo 1 (Cliente cancela operação)O cliente pode cancelar a transação em qualquer momento activando o botão “Cancelar”, implicando a reinicialização do caso de utilização. Não é realizada qualquer alteração à conta do cliente.

Cenário Alternativo 2 (PIN inválido)Se o cliente introduz um PIN inválido, o cartão MB é ejectado e o caso de utilização reinicializado. Se tal ocorrer 3 vezes consecutivas, o sistema cativa (i.e., “recolhe”) o cartão MB e cancela a transação; não permitindo qualquer interacção nos 2 minutos seguintes.

Validar Utilizador


Use Cases vs. CenáriosUse Cases vs. Cenários

Um use case descreve uma gama de sequências de acções; não apenas uma única. Cada uma dessas sequências designa-se por cenário.

Um cenário é uma sequência de acções específica que ilustra um determinado comportamento.

Um cenário é uma instância de um use case

Um use case pode ter ser descrito por vários cenários.


Use Cases - OrganizaçãoUse Cases - Organização

Os use cases podem ser organizados nas seguintes formas:

através do seu agrupamento em packages

pela especificação de inter-relações do tipo generalização, inclusão (include) e extensão (extend)


Use Cases - GeneralizaçãoUse Cases - GeneralizaçãoUma relação de generalização entre casos de utilização permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou alternativamente, permite definir casos mais abstractos a partir de casos concretos pelo mecanismo da redução ou generalização

O use case filho herda o comportamento e semântica do seu pai; o filho pode substituir especificações definidas no seu pai.


Use Cases - InclusãoUse Cases - Inclusão

A relação de inclusão entre casos de utilização corresponde a uma relação típica de delegação, significando que o caso base incorpora o comportamento do outro caso relacionado.

Usa-se a relação de inclusão para evitar descreverem-se os mesmos fluxos de eventos inúmeras vezes… (reutilização)


Use Cases - InclusãoUse Cases - Inclusão

Use case “Obter Extracto de Conta”

Nome: Obter Extracto de ContaCenário PrincipalIncluir caso de utilização “Validar Utilizador”. Obter e verificar o número da conta.. Seleccionar todas as linhas de movimentos realizados nos últimos 30 dias. Produzir uma lista resumo com esses movimentos, apresentando a data, o tipo de movimento (débito ou crédito), uma breve descrição e o valor do movimento. Produzir o saldo corrente da conta. Emitir um documento com essa informação, ejectando no terminal de multibanco o referido documento. Apresentar mensagem no visor do terminal para o cliente retirar o extracto. Registar na conta do cliente que esta operação foi realizada com sucesso.

Validar UtilizadorObter Extracto de Conta

«include»


Use Cases - ExtensãoUse Cases - Extensão Uma relação de extensão entre casos de utilização significa que o caso

base incorpora implicitamente o seu comportamento num local especificado indirectamente pelo caso que é usado. Ou seja, o caso destino pode ser estendido com o comportamento de outro(s) caso(s).

Uma relação de extensão permite representar:– A parte de um caso que um utilizador vê como opcional, ou como existindo várias

alternativas.– Um subfluxo de acções que é executado apenas se determinadas condições se

verificarem.– Vários fluxos de acções que podem ser inseridos num determinado ponto de

extensão, de forma controlada, através de uma interacção explícita com um actor.

O use case de base é estendido em 1 ou mais pontos, designados por “pontos de extensão”.


Use Cases - ExtensãoUse Cases - Extensão


Use Cases - ExtensãoUse Cases - Extensão

Nome: Obter Extracto de Conta

Pontos de Extensão: Nº de diasCenário Principal

Incluir caso de utilização “Validar Utilizador”. Obter e verificar o número da conta. Seleccionar o n.º de dias com base no qual se produz o extracto. (N.º de dias). Por omissão são seleccionados os últimos 30 dias. Produzir uma lista resumo com esses movimentos, apresentando a data, o tipo de movimento (débito ou crédito), uma breve descrição e o valor do movimento. Produzir o saldo corrente da conta. Emitir um documento com essa informação produzida ejectando no terminal de multibanco o referido documento. Apresentar mensagem no visor do terminal para o cliente retirar o extracto. Registar na conta do cliente que esta operação foi realizada com sucesso.


Use Cases - ExtensãoUse Cases - ExtensãoNome: Selecciona N.º de DiasTipo: AbstractoCenário Principal

É apresentado um écran em que o utilizador pode especificar o n.º de dias desejado, através da marcação em vários botões numéricos (de ‘0’ a ‘9’). Há uma caixa de texto construída dinamicamente que vai apresentando o valor corrente. Por fim, o utilizador marca o botão “Confirmar” e o valor construído é retornado ao caso destino no seu respectivo ponto de extensão.

Cenário Alternativo 1Idêntico ao cenário principal. Em qualquer momento o utilizador pode marcar sobre o botão “Apagar” de modo a apagar o algarismo introduzido mais recentemente.

Cenário Alternativo 2Idêntico ao cenário principal. Quando o utilizador marca “Confirmar” e o valor introduzido fôr superior a 59 dias é apresentada uma mensagem de aviso que o número máximo é 59, e o caso é reiniciado.

Cenário Alternativo 3Idêntico ao cenário principal. Em qualquer momento o utilizador pode seleccionar o botão “Cancelar”- O caso termina e é retornado o valor 1 (dia) por omissão..


Diagramas de Use CasesDiagramas de Use Cases Um diagrama de Casos de Utilização é um diagrama que ilustra um

conjunto de Casos de Utilização, de Actores, e suas relações. Estes diagramas têm duas aplicações comuns:

- Modelação do contexto de um sistema; ênfase na identificação da fronteira do sistema, dos seus actores e no significado das suas funções.

- Modelação dos requisitos de um sistema; consiste na identificação do que o sistema deve fazer, independentemente de como o sistema o deve realizar.


Diagramas de Use CasesDiagramas de Use Cases Um diagrama de Casos de Utilização é utilizado para ilustrar que

os actores e os casos de utilização interagem pelo envio reciproco de “estímulos”.

Uma associação de comunicação entre um actor e um caso de utilização implica uma interacção entre ambos.

Cada função nesta associação tem uma propriedade de navegação, que indica a direcção da comunicação.

Se for bidireccional omite-se a representação da direcção.

Actor

Use Case A


Diagramas de Use Cases - ActoresDiagramas de Use Cases - Actores

… representa uma função (ou papel) que um utilizador pode desempenhar relativamente ao sistema a modelizar.

… o conjunto total de actores de todos os use cases reflecte todos os elementos que interactuam com o sistema.

… um determinado utilizador pode desempenhar diferentes papéis, podendo, por conseguinte, representar diferentes actores.

Actor (~ perfil de utilizador)

Cliente

Cliente VIP

generalização de actores


Diagramas de Use Cases - ExemploDiagramas de Use Cases - Exemplo

A Máquina de Bebidas

Cliente

Agente do Fornecedor

Comprar Bebida

Repôr Bebidas

Retirar dinheiro

Colector

Dono




Cliente


Comprar Bebida

Repôr bebidas

Retirar dinheiroColector

Dono

Inclusão...

Abrir a Máquina

Fechar a Máquina

«include»

«include»

«include»

«include»




Repôr Bebidas Dono

Extensão...

Abrir a Máquina

Fechar a Máquina

«include»

«include»


Extension Pointencher prateleiras

Repôr latas de acordo

com as vendas

«extend»(encher prateleiras)

A possibilidade da reposição de bebidas na máquina depender agora de um algoritmo dependente das marcas e do número de latas vendidas...


Diagramas de Use Cases - ExercícioDiagramas de Use Cases - Exercício

Indique 2 vantagens da visualização de um use case.

Quais as semelhanças e diferenças entre classes e use cases?

(1) permitir melhor dialogar com o utilizador/cliente(2) combiná-lo com outros tipos de diagramas

Semelhanças:São ambos elementos estruturais, e.g., ambos suportam relações de herança.

Diferenças:As classes consistem em atributos e operações; os uses cases consistem em cenários, e cada cenário numa sequência de passos.A classe dá uma visão estática de uma parte do sistema; o use case dá uma visão do seu comportamento.A classe pode ilustrar os detalhes internos do sistema; o use case providencia a visão externa do sistema


Diagramas de Use Cases – Exercício-1Diagramas de Use Cases – Exercício-1

Esboçe um diagrama de use cases para um controlo remoto de TV. Garanta que incluie todas as funções do controlo remoto como use cases do seu modelo…

Descreva textualmente os use case

“Ligar TV” e

“Seleccionar Canal”

Variante: considere que a TV pode ter um mecanismo de controlo de acesso (com password) de forma a evitar que as crianças estejam “agarradas” à TV...


Diagramas de Use Cases – Exercício-2Diagramas de Use Cases – Exercício-2Considere, relativamente ao sistema GTTI, os seguintes diagramas de casos de utilização relativamente ao utilizador membro. Discuta justificadamente a versão do diagrama que considera mais adequada.

Temporizador

Configura Opções Pessoais

Consulta Termos Propostos

Submete Opinião sobre Proposta

<<extend>>

Propõe Termo

<<extend>>

UMembro

Recebe Automaticamente Novos Termos Oficiais Temporizador

Configura Opções Pessoais

Consulta Termos Propostos

Submete Opinião sobre Proposta

<<extend>>

Propõe Termo

<<extend>>

UMembro

Recebe Automaticamente Novos Termos Oficiais

Valida Acesso

<<include>>

<<include>>

<<include>>

<<include>>

Com o Caso “Valida Acesso” Sem o Caso “Valida Acesso”


Diagramas de Use CasesDiagramas de Use CasesUma Proposta de Metodologia…

Identificar os actores do sistema

Identificar, para cada actor, os seus casos de utilização principais– Note-se que podem existir casos que envolvam a participação de mais

que um actor.

Factorizar: identificar relações de inclusão– Com base nos casos de utilização originais, identificar, factorizar e colocar

em evidência casos de utilização que sejam recorrentes em mais que um dos casos originais.

– Nessa situação, cria-se o novo caso de utilização (em geral é um caso abstracto) e os casos originais envolvidos estabelecem uma relação de inclusão com o dito caso.

– Repetir o processo até não se conseguir identificar qualquer outro caso a reutilizar

1

2

3


Diagramas de Use CasesDiagramas de Use CasesUma Proposta de Metodologia…

Flexibilizar: identificar relações de extensão– Para tratar casos de utilização que pretendam ser flexíveis e

versáteis, definir pontos de extensão (ou de variabilidade) e conjuntamente definir um ou mais casos de utilização (abstractos) que os permitam estender nesses pontos.

– Nesta situação, cria-se uma relação de extensão do caso abstracto para o caso estendido.

Especificar textualmente cada caso de utilização – segundo um determinado formato previamente definido.

– não esquecer nesta especificação textual a explicitação dos pontos de extensão e de inclusão anteriormente identificados

4

5


Modelação do ComportamentoModelação do Comportamento

Especificar o comportamento inter-objectos Diagrama de Sequência Diagrama de Comunicação Diagrama da visão geral da interacção (interaction overview

diagram) Diagrama temporal (timming diagram),

Especificar o comportamento intra-objecto Diagrama de Estados (statemachine diagram)

Objectivos

Diagramas de interacção


InteracçõesInteracções

Uma interacção é a especificação do comportamento de um conjunto de

objectos, representado pela sua troca de mensagens, num determinado

contexto, e com vista à concretização de um dado objectivo.

Uma mensagem é a especificação de comunicação entre objectos.

Sempre que existe uma ligação (link) entre objectos, pode ocorrer uma ou

mais interacções.


Interacções - Relação entre DiagramasInteracções - Relação entre Diagramas

:Pessoa :Empresa

classe

PessoaEmpresa

associação

1..* *

objecto

Diagrama de Classes

Diagrama de Objectos

:Pessoa :Empresa

afecta(desenvolvimento)objecto

link

mensagem

Diagrama de Interacção


Interacções - Objectos e LinksInteracções - Objectos e Links

Pode-se encarar um diagrama de objectos como a representação dos aspectos estáticos de uma interação. Contudo, uma interacção vai mais longe, ao introduzir uma sequência dinâmica de mensagens que podem fluir entre os links que ligam esses objectos.

Assim, os diagramas de interacções devem ser considerados como uma extensão aos diagramas de objectos.

Um link traduz uma relação semântica/estrutural entre objectos. Sempre que existe uma associação entre 2 classes também deve existir

um link entre instâncias dessas classes

:Pessoa :Empresa

afecta(desenvolvimento)objecto

link

mensagem


Interacções - MensagensInteracções - Mensagens Uma mensagem é o

estabelecimento de uma comunicação entre objectos que veicula informação com a expectativa de determinada actividade ser realizada.

:Pessoa :Empresa

afecta(desenvolvimento)

mensagem

[attribute =] signal-or-operation-name [ (arguments)] [: return-value] | ´*´arguments ::= argument [, arguments]argument ::= [parameter-name= ] argument-value | - attribute::= out-parameter-name [:argument-value] | -

Sintaxe de uma mensagem

Exemplos cancela(), envio de uma operação sem valores em argumentos e sem retorno. cancelaProposta(data=31/12/2006, -):void, envio de uma operação com o primeiro argumento

com valor “31/12/2006”, o segundo argumento sem valor; e com retorno do tipo “void”.


Interacções - MensagensInteracções - Mensagens

Tipos de Mensagens:

(Notar no entanto que diferentes ferramentas CASE podem suportar diferentes representações gráficas deste tipo de setas.)


Interacções - MensagensInteracções - MensagensEm UML estão predefinidos diferentes tipos de mensagens:

Call: invoca uma operação de um objecto (é o tipo de msg mais usual) Return: devolve um valor para o “chamador” Send: envia um sinal para o objecto Create: cria um objecto Destroy: destroi um objecto (um objecto pode auto-destruir-se)


Interacções - Sequência de MensagensInteracções - Sequência de Mensagens

Quando um objecto envia uma mensagem a outro objecto, este por sua vez pode enviar uma outra mensagem a outro objecto, e assim sucessivamente.

Cria-se, deste modo, sequências de mensagens, em geral, executadas sobre o mesmo processo ou actividade de execução.

:X

:Z

:Y

1: add()

2: modify()3: update()

número da mensagem

mensagem


Interacções - SugestõesInteracções - Sugestões

Simples: deve incluir apenas os objectos necessários que conjuntamente

realizam um determinado comportamento Contexto bem definido:

pode representar uma interacção de objectos no contexto de uma operação, uma classe, ou o sistema como um todo

Eficiente deve executar o seu comportamento com um compromisso

óptimo entre tempo e recursos Comprensível

não deve ter efeitos co-laterais escondidos, ou semântica obscura

Uma Interacção bem estruturado é:


Diagramas de InteracçãoDiagramas de Interacção Um diagrama de interacção ilustra uma interacção, apresentando as

mensagens trocadas entre objectos na realização de um caso de utilização.

Tipos de Diagramas– Diagrama de sequência: é um diagrama de interacção com ênfase na ilustração

temporal das mensagens trocadas entre os objectos – Diagrama de comunicação: é um diagrama de interacção com ênfase na

ilustração da organização estrutural dos objectos que trocam mensagens entre si.

– Diagrama da visão geral da interacção (interaction overview diagram): é um diagrama de interacção com ênfase na ilustração de alto nível do fluxo de controlo lógico das interacções relevantes. Pode ser encarado como um diagrama de actividade, em que os seus nós são interacções definidas com detalhe através dos diagramas de sequência e ou de comunicação.

– Diagrama temporal (timming diagram): é um diagrama opcional que permite especificar restrições de tempo associadas a mensagens trocadas no decurso de uma interacção.


Diag. de Interacção - Diag. de SequênciasDiag. de Interacção - Diag. de Sequências

Conceitos– objectos e sua

linha de vida– mensagens– âmbito de

execução– numeração de

mensagens hierárquica

– scripts

Não mostra as associações entre objectos.

Os diagramas de sequência descrevem um padrão de interacção entre objectos, apresentado de uma forma cronológica.

Definir o “melhor” percurso para as férias em Malta...


Diag. de Interacção - Diag. de SequênciasDiag. de Interacção - Diag. de Sequências Diagrama de sequência correspondente à “Subscrição de Membro” do

sistema GTTI. Especificação de alto nível ...


Diag. de Interacção - Diag. de ComunicaçãoDiag. de Interacção - Diag. de ComunicaçãoOs diagramas de comunicação descrevem um padrão de interacção entre objectos, apresentando os objectos que participam na interacção com ligações entre si, e as mensagens que enviam.

Conceitos representados– objectos– ligações– mensagens


Diag. de Interação - Equival. SemânticaDiag. de Interação - Equival. Semântica

Diagrama de Sequências Diagrama de Comunicação

O que não significa que ambos os diagramas apresentem explicitamente a mesma informação


Diags Sequência vs Diags Diags Sequência vs Diags ComunicaçãoComunicação

Diagramas de sequência mostram a sequência explicita

das mensagens melhores para visualizar o fluxo

global de aplicação melhores para especificações

de tempo real e para cenários complexos

Diagramas de comunicação mostram relações,

adicionalmente às interacções melhores para visualizar

padrões de colaboração entre objectos

melhores para visualizar todos os efeitos num dado objecto

mais fáceis de utilizar em reuniões

Devem-se utilizar diagramas de interacção sempre que se pretende representar o comportamento de vários objectos num único caso de utilização.São adequados para representar a colaboração entre objectos, mas não para a representação exacta do comportamento.


Diag. de Interação - Exemplo (1)Diag. de Interação - Exemplo (1)Criação de “Conta” – diag. Seq. nível desenho em ASP.NET...


Diag. de Interação - Utilizações ComunsDiag. de Interação - Utilizações Comuns

Para modelizar o fluxo de controlo segundo uma perspectiva temporal– Usar diagramas de sequências

particularmente útil para detalhar um cenário de um use case melhores para especificar situações complexas, bem como múltiplos e

concorrentes fluxos de controlo (sistemas de tempo real), ...

Para modelizar o fluxo de controlo segundo uma perspectiva organizacional– Usar diagramas de comunicação

ênfase nas relações estruturais entre as instâncias de uma interacção mais adequados para especificar situações simples, desenho procedimental


Diag. de Interação - Exercício (1)Diag. de Interação - Exercício (1)

Operador

Enviar Fax

Considere-se o melhor cenário para o use case “Enviar Fax” (o cenário em que tudo corre bem”)Considere que um sistema composto, entre outros, pelos seguintes objectos:

máquina que envia; máquina que recebe; uma central que encaminha faxes e chamadas telefónicas

Desenhe o diagrama de sequências respectivo.


Cliente

Comprar Bebida

Considere-se o cenário mais usual para o use case “Comprar Bebida”: o cenário em que “tudo corre bem”, i.e., há a bebida seleccionada, o dinheiro introduzido está correcto, …

Considere apenas os “objectos”: “cliente” e “máquina” Variante: considere que a máquina é constituída pelos objectos: “painel-interface”,

“caixa-registradora”, “despensa-frigorifico”…

Desenhe o diagrama de sequências/comunicação respectivo.




Considerem-se outros cenários para o use case “Comprar Bebida”

O utilizador introduziu mais dinheiro que o valor da bebida, e a máquina tem dinheiro para troco

O utilizador introduziu mais dinheiro que o valor da bebida, e a máquina não tem dinheiro para troco

Desenhe os respectivos diagramas de sequências, e de comunicação.



Considere a seguinte interacção entre objectos Java de acesso a BD usando o package java.sql.*

Connection con;Statement stmt;...Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con = DriverManager.getConnection("jdbc:odbc:BD1");stmt = con.createStatement();...stmt.executeUpdate(“INSERT …”);...stmt.executeUpdate(“UPDATE …”);

Desenhe o respectivo diagrama de sequências e de colaboração.


Diag. de Interação – Diag. TemporalDiag. de Interação – Diag. Temporal Um diagrama temporal (timing diagram) é um diagrama de interacção

com objectivos específicos de ilustrar os eventos que ocorrem num determinado objecto ao longo de um período de tempo.

Pode ser considerado como uma combinação entre um diagrama de interacção e um diagrama de estados, com a capacidade de explicitação de restrições de tempo e de duração.

Diagrama temporal para a classe “Termo” no contexto do sistema GTTI


Diagramas de EstadoDiagramas de Estado

Um modo de representar as alterações de um sistema. I.e., os seus objectos mudam de estado como resposta a eventos e à passagem de tempo.

Exemplos: Quando se liga/desliga um interruptor Depois da passagem de um determinado período de tempo, a máquina

de lavar termina o seu programa de lavagem, e inicia o de secagem

O que são?

Um diagrama de estado também é designado por “máquina de estados”



– O ciclo de vida de instâncias de uma classe

– a execução de uma operação de uma instância de uma classe

representam:

– os estados possíveis das instâncias de uma classe

– as possíveis transições entre estados

– os eventos que fazem desencadear as transições

– as operações (acções e actividades) que são executadas dentro de um estado ou durante uma transição

O que descrevem?



Como são representados?

X

Estado inicial Estado finalEstado X

Nome

Operações

Visão de um Estado com detalhes

transição



Exemplo: “lâmpada”

Acesa

Danificada

Apagada

Desligar(off) Ligar

(on)


Diagramas de Estado - Diagramas de Estado - Acções e ActividadesAcções e Actividades

Acção: – atómica e não interrompível

Actividade:

– complexa (eventualmente descrita por um outro diagrama de estado aninhado) e interrompível

Clausulas:– entry/actions acção(ões) é executada quando se entra no estado

– exit/actions acção (ões) é executada quando se sai do estado

– do/activities actividade(s) é executada, são permitidos parâmetros

– Internal event/actions evento é tratado dentro de um estado, não provoca mudanca de estado

– Event /defer evento é diferido para ser tratado fora do estado



Exemplo: O ciclo de vida de um “termo”... No WebGTTI





Ordem de realização das operações quando ocorre um evento que provoca uma transição

1. Caso exista uma actividade em execução no estado corrente, esta deverá ser interrompida (de preferência de forma graciosa, i.e., sem provocar incoerência no estado do objecto).

2. Caso existam, executar as acções de saida, definidas na cláusula “exit”.

3. Caso existam, executar as acções definidas na transição de estado.

4. Caso existam, executar as acções de entrada, definida na cláusula “entry”, do novo estado.

5. Caso existam, começar a executar as actividades do novo estado.



Auto-transições– Situações em que um objecto recebe um evento que não provoca

a sua mudança de estado, mas que corresponde a uma interrupção de facto do seu estado.

– Este tipo de evento é suficientemente significativo pois força o objecto a interromper a sua actividade corrente, forçando-o a sair do seu estado corrente e a retornar ao mesmo estado, provocando de facto uma re-entrado no estado corrente.



Eventos e Acções



Condições com Guarda

Sintaxe completa de uma transição:evento [condição com guarda] / acção

Uma transição de estado realiza-se se: o evento ocorre; e a guarda é verdadeira.


Diagramas de EstadoDiagramas de EstadoSub-Estados

Um estado pode ser melhor descrito por um conjunto (sequencial e/ou concorrente) de outros estados, designados por “sub-estados”. Ou seja, um conjunto de estados podem ser agregados num único estado...

potencia o mecanismo de abstracção/decomposição...



Sub-EstadosSub-Estados Concorrentes


Diagramas de Estado - ExercíciosDiagramas de Estado - Exercícios

(1) Desenhe o diagrama de estados de uma tostadeira. Defina os diferentes estados do pão na tostadeira, sem esquecer de especificar os necessários eventos, acções, e condições com guarda.

(2) Desenhe o diagrama de estados de um relógio digital. Considere que o relógio tem um visor, dois botões (E e D) e dois modos básicos de funcionamento: mostrar horas (e minutos) e acertar as hora (e minutos). O acerto de horas tem dois sub-modos: acertar horas e acertar minutos. O botão E serve para seleccionar os modos de funcionamento segundo a sequência cíclica: mostrar; acertar horas, acertar minutos, mostrar, ... Dentro dos modos de acertar, o botão D serve para adiantar os valores correspondentes (a horas ou a minutos).


Diagramas de ActividadeDiagramas de ActividadeUm diagrama de actividades pode ser visto como um caso particular de um diagrama de estados

– no qual todos ou a maioria dos estados são “estados de actividades”

e – todas ou a maioria das transições são desencadeadas pela

conclusão das actividades dos estado anteriores.

Diagrama de actividades vs. de estados vs. de interação:– Um diagrama de actividades ilustra o fluxo de controlo (e de

objectos) entre actividades, – Um diagrama de estados ilustra o fluxo de controlo entre

estados. – Um diagrama de interacção ilustra o fluxo de controlo entre

objectos.


Diagramas de ActividadeDiagramas de Actividade

Para modelizar os aspectos de comportamento funcional (e.g., o algoritmo) de um sistema como um todo, de um subsistema, de uma operação ou de uma classe.

Pode-se também associar um diagrama de actividade a um caso de utilização (para modelizar um cenário) ou a uma colaboração (para modelizar o comportamento de um conjunto de objectos genéricos).

Para modelizar processos (workflows) com diferentes participantes

Utilizações Comuns



Diagramas que fornecem uma visão simplificada do fluxo de controlo de um caso de utilização, operação ou de um processo

Mostra o fluxo entre actividades (e adicionalmente tb o fluxo de informação)

~ Fluxogramas, na sua forma de aplicação simples ...

O que são?

Actividade 1

Actividade 2

estado inicial

estado final

transição



Acções: execuções atómicas, não interrompíveis, com tempo de execução irrelevante.

Actividades: execuções não atómicas (decompostas), interrompíveis, em que o tempo de execução é normalmente relevante.

Transições. Objectos. Nós (ou pontos) de decisão e de junção. Nós de difusão (fork) e de junção ou

sincronização (join).

Contém genericamente:Calcular Factura

Emitir Factura

index:= a+b+f(c);

Reunião com o Cliente

entry / apresentar credenciais


Diagramas de ActividadeDiagramas de Actividade A actividade “Submeter Opinião” , WebGTTI



Decisões (“… ou …”)

Duas formas equivalentes de se representar uma decisão



Todas as actividades são realizadas concorrentemente

Conjunto de actividades realizadas concorrentemente, independentemente da sua ordem de execução

Caminhos Concorrentes...


Diagramas de Actividade - algoritmosDiagramas de Actividade - algoritmos

Utilizações Típicas dos Diagramas de Actividade:

Para especificar uma operação– permite especificar detalhadamente um algoritmo

Para especificar um processo de negócio– permite especificar detalhadamente uma sequência de

actividades existentes num processo de negócio


Diagramas de Actividade - algoritmosDiagramas de Actividade - algoritmos

Especificação de uma operação Exemplo: Série de Fibonacci


Diagramas de Actividade – Exercício (1)Diagramas de Actividade – Exercício (1)

Desenhe o diagrama de actividades correspondente ao algoritmo do factorial de “n”.

n! = 1, se n <= 1; = n*(n-1)!, se n > 1


Diagramas de Actividade – Exercício (2)Diagramas de Actividade – Exercício (2)

<%@ page import="puc.util.Flow" %> <% String flow = (String)session.getAttribute(Flow.FLOW_KEY); if (flow.equals(Flow.CONNECTION_ERROR)) { %> <jsp:include page="/genericJSP/connectionError.jsp"

flush="true" /><% } else if (flow.equals(Flow.NEW_SUBSCRIBE)) {%> <jsp:include page="/subscribeJSP/newSubscribe.jsp"

flush="true" /><% } else if (flow.equals(Flow.NEW_SUBSCRIBE_RESULT)) {%> <jsp:include page="/subscribeJSP/newSubscribeResult.jsp"

flush="true" />... }%>

middle.jsp


Diagramas de Actividade - workflowsDiagramas de Actividade - workflows

Preparar Proposta (Empresa de Serviços)

Especificação de um processo de negócio

partições

Partições - permitem separar o diagrama em segmentos paralelos, em que cada um apresenta as actividades de cada interveniente no processo global


Diagramas de Actividade - workflowsDiagramas de Actividade - workflowsA partição de actividades pode representar uma ou mais dimensões do problema

Mas, solução não é escalável…


Diagramas de Actividade - workflowsDiagramas de Actividade - workflowsAlternativa escalável…


Diagramas de Actividade - workflowsDiagramas de Actividade - workflowsActividades e Objectos


Diagramas de Actividade - ExercícioDiagramas de Actividade - Exercício

(1) Um vendedor telefona ao cliente e marca uma reunião.(2) Se a reunião é na empresa, os técnicos da empresa preparam a sala de

conferências para a apresentação.(3) Se a reunião é for a da empresa (no escritório do cliente) um consultor prepara

a apresentação num laptop.(4) O consultor e o vendedor reunem-se com o cliente no local e hora combinada.(5) O vendedor envia ao cliente uma carta a resumir o “sucesso” da reunião.(6) Se a reunião resultou na identificação de um problema, o consultor escreve

uma proposta e envia-a para o cliente.

Variante: Captar o local onde se realiza a actividade

Especifique o seguinte processo de negócio: “gestão de encontros com clientes”

Documents

Unified Modeling Language (UML) - Modelação do Comportamento - Alberto Manuel Rodrigues da Silva Prof. DEI/IST/UTL Análise e Concepção de Sistemas de Informação