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

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

Modelaçã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)
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 Cases Use case ... é 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 Cases Use case ... é 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 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 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...

Descrição textual de um use case
Use Cases – Exemplo ATM Descrição textual de um use case Validar Utilizador Fluxo de Eventos Principal O 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.

Use Cases - Exemplo ATM (cont.)
Validar Utilizador 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.

Use 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çã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ção
Uma 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ã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ão Use case “Obter Extracto de Conta”
«include» Validar Utilizador Use case “Obter Extracto de Conta” Nome: Obter Extracto de Conta Cenário Principal Incluir 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.

Use 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ão

Use Cases - Extensão Nome: Obter Extracto de Conta Pontos de Extensão:
Nº de dias Cená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ão Nome: Selecciona N.º de Dias Tipo: Abstracto
Cená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 1 Idê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 2 Idê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 3 Idê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 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 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 - Actores
Actor (~ perfil de utilizador) … 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. Cliente generalização de actores Cliente VIP

Diagramas de Use Cases - Exemplo
A Máquina de Bebidas Cliente Comprar Bebida Agente do Fornecedor Dono Repôr Bebidas Colector Retirar dinheiro

Inclusão... A Máquina de Bebidas Cliente Comprar Bebida Agente do Fornecedor Repôr bebidas Dono «include» «include» Abrir a Máquina «include» Colector Retirar dinheiro Fechar a Máquina «include»

Extensão... 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... A Máquina de Bebidas Abrir a Máquina «include» Agente do Fornecedor Dono Repôr Bebidas Extension Point encher prateleiras «include» «extend» (encher prateleiras) Fechar a Máquina Repôr latas de acordo com as vendas

Diagramas 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-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-2
Considere, 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. Sem o Caso “Valida Acesso” Com o Caso “Valida Acesso”

Uma Proposta de Metodologia…
Diagramas de Use Cases Uma Proposta de Metodologia… 1 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 2 3

Uma Proposta de Metodologia…
Diagramas de Use Cases Uma Proposta de Metodologia… 4 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 5

Modelação do Comportamento
Objectivos 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) Diagramas de interacção

Interacçõ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 Diagramas
Diagrama de Classes associação classe Pessoa 1..* * Empresa Diagrama de Objectos objecto link :Pessoa :Empresa mensagem Diagrama de Interacção objecto afecta(desenvolvimento) :Pessoa :Empresa

Interacções - Objectos e Links
mensagem objecto afecta(desenvolvimento) :Pessoa :Empresa link 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

Interacções - Mensagens
mensagem Uma mensagem é o estabelecimento de uma comunicação entre objectos que veicula informação com a expectativa de determinada actividade ser realizada. afecta(desenvolvimento) :Pessoa :Empresa Sintaxe de uma mensagem [attribute =] signal-or-operation-name [ (arguments)] [: return-value] | ´*´ arguments ::= argument [, arguments] argument ::= [parameter-name= ] argument-value | - attribute::= out-parameter-name [:argument-value] | - 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”.

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

Em 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 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. 1: add() :X :Y número da mensagem 2: modify() 3: update() :Z mensagem

Interacções - Sugestões
Uma Interacção bem estruturado é: 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

Diagramas 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ências
Os diagramas de sequência descrevem um padrão de interacção entre objectos, apresentado de uma forma cronológica. 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. Definir o “melhor” percurso para as férias em Malta...

Diag. 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ção
Os 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â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 Comunicaçã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)
Criação de “Conta” – diag. Seq. nível desenho em ASP.NET...

Diag. 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)
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. 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

Um diagrama de estado também é designado por “máquina de estados”
Diagramas de Estado O que são? 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 Um diagrama de estado também é designado por “máquina de estados”

Diagramas de Estado O que descrevem? representam:
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

Como são representados?
Diagramas de Estado Como são representados? X Estado inicial Estado final Estado X transição Nome Operações Visão de um Estado com detalhes

Diagramas de Estado Exemplo: “lâmpada” Acesa Danificada Apagada
Desligar (off) Ligar (on) Danificada Apagada

Diagramas de Estado - Acçõ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.

Diagramas de Estado Eventos e Acções

Diagramas de Estado Condições com Guarda
Uma transição de estado realiza-se se: o evento ocorre; e a guarda é verdadeira. Sintaxe completa de uma transição: evento [condição com guarda] / acção

potencia o mecanismo de abstracção/decomposição...
Diagramas de Estado Sub-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-Estados Concorrentes
Diagramas de Estado Sub-Estados Sub-Estados Concorrentes

Diagramas 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 Actividade
Um 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.

Utilizações Comuns 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

O que são? estado inicial 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 ... transição Actividade 1 Actividade 2 estado final

Contém genericamente: Calcular Factura 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). index:= a+b+f(c); Emitir Factura Reunião com o Cliente entry / apresentar credenciais

A actividade “Submeter Opinião” , WebGTTI

Decisões (“… ou …”) Duas formas equivalentes de se representar uma decisão

Caminhos Concorrentes... Conjunto de actividades realizadas concorrentemente, independentemente da sua ordem de execução Todas as actividades são realizadas concorrentemente

Diagramas 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 - algoritmos
Especificação de uma operação Exemplo: Série de Fibonacci

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)
middle.jsp 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" /> ... }

Diagramas de Actividade - workflows
Especificação de um processo de negócio Preparar Proposta (Empresa de Serviços) partições Partições - permitem separar o diagrama em segmentos paralelos, em que cada um apresenta as actividades de cada interveniente no processo global

A partição de actividades pode representar uma ou mais dimensões do problema Mas, solução não é escalável…

Alternativa escalável…

Actividades e Objectos

Diagramas de Actividade - Exercício
Especifique o seguinte processo de negócio: “gestão de encontros com clientes” (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

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

Apresentações semelhantes

Apresentação em tema: "Unified Modeling Language (UML) - Modelação do Comportamento -"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

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

Apresentações semelhantes

Apresentação em tema: "Unified Modeling Language (UML) - Modelação do Comportamento -"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback