Unified Modeling Language (UML) - Modelação da Dinâmica -

Slides:



Advertisements
Apresentações semelhantes
Análise e Projeto Orientado a Objetos
Advertisements

DIAGRAMA DE COLABORAÇÃO
Modelagem de Estados.
Análise e Desenvolvimento de Sistemas
UML Visões – Parte 2.
Desenvolvimento de Sistemas Baseado na Transformação de Modelos
(Unified Modeling Language)
Diagrama de Atividades
Unified Modeling Language (UML) - Modelação da Arquitectura -
Diagramas de Seqüência
Linguagens de Modelagem (cont.) (IV)
Linguagens de Modelagem para SMA
Diagrama de Sequência.
Professora: Aline Vasconcelos IF Fluminense
Introdução a diagrama de classes e UML
Diagrama de Atividades
Curso UML Diagramas de Atividade
(Linguagem de Modelagem Unificada)
Análise e Projeto de Sistemas
Aula 10 UML (cont.).
2002/2003 Programação Orientada para Objectos 1 Aula 10 UML (continuação da aula 9) Diagramas de sequência Diagramas de actividade Desenvolvimento de um.
Modelagem de Interações
UML - Unified Modeling Language
Diagrama de Estados.
Diagramas de Sequência e Comunicação
Diagramas de Seqüência
Análise de Sistemas Análise e Projeto Prof. Jeime Nunes Site:
Diagramas de Estados(*)
UML - Unified Modeling Language
Diagrama de Atividades
1 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB 12. Estados Objetivo: compreender a notação do diagrama de estados.
UML – Diagrama de Classes
Diagramas de Interacção
Modelação Conceptual de Sistemas
Análise e Projeto de Sistemas
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Professor Mário Dantas
Diagrama de Atividades
Diagramas de Atividade
UNIDADE 2 UML MODELAGEM TEMPORAL
Especificação, Modelação e Projecto de Sistemas Embutidos / 2009.
Educação Profissional Técnica de Nível Médio Curso Técnico de Informática Disciplina: Interpretação de Projetos de Software Professor: Cheli dos S. Mendes.
Marcio de Carvalho Victorino
UML - Unified Modeling Language
Diagramas de Comunicação
Unified Modeling Language Professor Mário Dantas A NÁLISE O RIENTADA A O BJETOS Nov/2010.
Diagramas de Estado.
Diagrama de Colaboração. Diagramas de Interação Expressam informações bastante similares porém de maneira diferente Diagrama de seqüência: – Interação.
Análise e Projeto de Sistemas
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
Unified Modeling Language (UML) - Modelação do Comportamento -
ATSI 2006/2007 Aulas práticas. Plano da Aulas Práticas de ACSI 7 Março- Apresentação. Exemplos de projectos de anos anteriores Março- Introdução.
Modelação Aula T15 Modelação Conceptual de Sistemas Revisão do Comportamento OCL – Object Constraint Language José Borbinha.
Modelação Aula T13 Modelação Conceptual de Sistemas Comportamento Referências: –Conceptual Modeling of Information Systems (Capítulos 11, 12, 13 e 14)
Análise e Projeto de Sistemas Unified Modeling Language Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores.
UML Statechart CIn-UFPE.
Análise e Projeto de Sistemas
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Modelagem de Sistemas Orientada a Objeto Com UML
Diagrama de Colaboração
Interações entre objetos
Fundamentos de Engenharia de SW Diagramas da UML Usados no Projeto de Software.
UML (Unified Modeling Language) A linguagem unificada de modelagem
Diagrama de Classes Herança Dependências.
Diagrama de atividade.
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
Análise e Design de Software Site:
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
Análise e Conceção de Sistemas
Transcrição da apresentação:

Unified Modeling Language (UML) - Modelação da Dinâmica - Análise e Concepção de Sistemas de Informação Unified Modeling Language (UML) - Modelação da Dinâmica - Alberto Silva / José Borbinha

Modelação da Dinâmica Use Cases e Diagramas de Use Case Interacções Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

Modelação da Dinâmica (ou Comportamento) Dinâmica geral do sistema Diagrama de Casos de Utilização Diagrama de Actividade Diagramas de Interacção Dinâmica entre objectos Diagrama de Sequência Diagrama de Comunicação Diagrama Temporal Diagrama da Visão Geral da Interacção Comportamento dos objectos... Diagrama de Máquina de Estados

Modelação da Dinâmica Use Cases e Diagramas de Use Case Interacções Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

Use Cases (Casos de Utilização) Um use-case descreve o que faz um sistema (ou parte deste), não como é que tal é realizado (foco na visão externa do sistema) O modelo do comportamento (ou da dinâmica) de um sistema começa com a análise de use-cases. Os use-cases capturam os requisitos de um sistema, através do detalhe de todos os cenários que os actores podem realizar. 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. É normal um use-case ser descrito por vários cenários possíveis.

Reutilização na Modelação de Casos de Utilização (inclusão versus extensão) Alerta para uma confusão frequente... Inclusão Uma relação de inclusão entre dois casos representa uma situação em que um caso, em determinado momento da sua execução, incorpora sempre a execução de outro. É relevante considerar o uso de inclusão quando há comportamentos que são executados da mesma forma em vários casos. Identificando-os em casos específicos permite reutilizá-los. Extensão Uma relação de extensão entre dois casos significa que, sob certas condições, o caso base pode incorporar a execução do outro. Uma relação de extensão permite representar uma parte de um caso que é opcional, ou que existe em várias alternativas. Um use case de base pode ser estendido num ou mais pontos, designados por “pontos de extensão”.

Reutilização na Modelação de Casos de Utilização (inclusão versus extensão) A Máquina de Bebidas Os casos de “Abrir a Máquina” e “Fechar a Máquina” são executados em vários outros casos, logo, se forem relevantes (por exemplo, para se abrir a máquina tem de se ter acesso a uma chave) faz sentido identificá-los explicitamente e reutilizá-los quando necessário. Esta reutilização faz-se por inclusão (como no caso dos ficheiros “include”em C e noutras linguagens ou ambientes de programação) 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»

Reutilização na Modelação de Casos de Utilização (inclusão versus extensão) O caso “Obter Extracto de Conta” pode ter um comportamento por omissão que nos dá, por exemplos, o extracto dos últimos 30 dias. No entanto, ainda dentro do mesmo caso, podemos desejar a opção de alterar esses número de dias. Temos assim uma condição variável! A forma de declarar isso é definindo um Ponto de Extensão para o Número de Dias, e definir casos de utilização que podem estender o caso principal segundo essa variável.

Reutilização na Modelação de Casos de Utilização (inclusão versus extensão) O caso “Perform Security Check” é executado apenas se o actor for um “International Student”

Modelação da Dinâmica Interacções Use Cases e Diagramas de Use Case Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

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. Exemplos de Mensagens 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”. 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] | -

Interacções - Relação entre Diagramas associação classe Diagrama de Classes Pessoa 1..* * Empresa :Pessoa :Empresa objecto Diagrama de Objectos afecta(desenvolvimento) link mensagem Interacção

Interacções - Objectos e Links :Pessoa :Empresa objecto Diagrama de Objectos afecta(desenvolvimento) link mensagem Interacção Os diagramas de interacções devem ser considerados como uma extensão (dinâmica) aos diagramas de objectos (que são estáticos). Um link traduz uma relação semântica/estrutural entre objectos. Sempre que existe uma associação entre duas classes também deve existir um link entre instâncias dessas classes. Uma mensagem é o estabelecimento de uma comunicação por um link entre objectos que veicula informação com a expectativa de determinada actividade ser realizada.

Interacções - Mensagens Tipos de Mensagens ( de notar no entanto que diferentes ferramentas CASE podem suportar diferentes representações gráficas): Em UML estão já predefinidos alguns 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 outra mensagem a outro objecto, e assim sucessivamente. Criam-se, deste modo, sequências de mensagens, em geral executadas sobre o mesmo processo ou actividade de execução. É importante descrever claramente essas sequências!!! 1: add() :X :Y número da mensagem 2: modify() 3: update() :Z mensagem

Interacções - Sugestões Uma Interacção bem estruturada é: Simples: deve incluir apenas os objectos necessários que entre si realizam um determinado comportamento. De contexto bem definido: pode-se representar uma interacção de objectos no contexto de uma operação, de uma classe, ou o do 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.

Modelação do Comportamento Use Cases e Diagramas de Use Case Interacções Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

Diagramas de Interacção Um diagrama de interacção ilustra as mensagens trocadas entre objectos na realização de um caso de utilização. Devem-se utilizar diagramas de interacção sempre que se pretende representar o comportamento de vários objectos num único caso de utilização. Tipos de Diagramas de Interacção 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.

Interacção: Diagramas 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

Interacção: Diagramas de Sequências (exemplo) Criação de “Conta” – diagrama de sequência ao nível de desenho em ASP.NET...

Interacção: Diagramas de Comunicação Mostram relações entre os objectos, adicionalmente às interacções Adequados para visualizar padrões de colaboração entre objectos Adequados para visualizar todos os efeitos num dado objecto

Diag. Sequência versus Diag. 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 Estes diagramas são semanticamente equivalentes, mas não apresentem explicitamente a mesma informação (ex: a linha de tempo não existe no diagrama de sequências...)

Interação - Utilizações Comuns Para modelar o fluxo de controlo numa 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 fluxos de controlo múltiplos e concorrentes (sistemas de tempo real), ... Para modelar o fluxo de controlo numa 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 – Diag. Temporal Um diagrama temporal (timing diagram) é um diagrama de interacção com objectivos específicos de ilustrar para o exterior as mudanças de estado 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.

Modelação do Comportamento Use Cases e Diagramas de Use Case Interacções Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

Um diagrama de estado também é designado por “máquina de estados” Diagramas de Estado Modo de representar as alterações de estado dos objectos do sistema (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 - Representação X Estado X Estado inicial Estado final transição Nome Operações Visão de um Estado com detalhes Exemplo: “lâmpada” Acesa Danificada Apagada Desligar (off) Ligar (on)

Diagramas de Estado - Acções e Actividades Acção: atómica; não se pode interromper Actividade: complexa (eventualmente descrita por um outro diagrama de estado aninhado); pode-se interromper. Cláusulas: 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 no estado (são permitidos parâmetros) Internal event/actions - evento que não provoca mudança de estado Event /defer - evento é diferido para ser tratado fora do estado

Diagramas de Estado - Acções e Actividades 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 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

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

Sub-Estados Concorrentes Diagramas de Estado Sub-Estados Sub-Estados Concorrentes

Modelação do Comportamento Use Cases e Diagramas de Use Case Interacções Diagramas de Interacção Diagramas de Estado Diagramas de Actividade

Diagramas de Actividade Um diagrama de actividades descreve os processos de negócio de um sistema (modelação da lógica do sistema e fluxos de dados) Modelação dos 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. Modelação de um cenário de um caso de utilização ou do comportamento de um conjunto de objectos genéricos numa colaboração. Modelação de processos (workflows) com diferentes participantes ... Notas: Um diagrama de actividades ilustra o fluxo de controlo (e de objectos) entre actividades dos processos. Um diagrama de estados ilustra o fluxo de controlo entre estados dos objectos. Um diagrama de interacção ilustra o fluxo de controlo entre objectos.

Diagramas de Actividade Diagramas que fornecem uma visão simplificada do fluxo de controlo de um caso de utilização, operação ou de um processo Mostram o fluxo entre actividades (e adicionalmente também o fluxo de informação) Equivalente a fluxogramas, na sua forma de aplicação simples ... estado inicial transição Actividade 1 Actividade 2 estado final

Diagramas de Actividade 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

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

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

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

Diagramas de Actividade – Ex. para um algoritmo Exemplo: Série de Fibonacci

Diagramas de Actividade – Exemplo para um processo de negócio / workflow Preparar Proposta (Empresa de Serviços) 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 – Exemplo para um processo de negócio / workflow A partição de actividades pode representar uma ou mais dimensões do problema Mas esta solução não é escalável…

Diagramas de Actividade – Exemplo para um processo de negócio / workflow Alternativa escalável…

Diagramas de Actividade – Exemplo para um processo de negócio / workflow Actividades e Objectos