Modelação Aula T14 Modelação Conceptual de Sistemas Comportamento (2) Referências:...
Transcript of Modelação Aula T14 Modelação Conceptual de Sistemas Comportamento (2) Referências:...
Modelação
Aula T14Modelação Conceptual de Sistemas
Comportamento (2)
Referências:– Conceptual Modeling of Information Systems (Capítulos 11, 12, 13 e 14)– UML, Metodologias e Ferramentas CASE (Capítulo 8)
José Borbinha
ProgramaT01-T03 – Módulo 1
– Introdução à Modelação de SistemasT04-T07 – Módulo 2
– Modelação Conceptual de SistemasT08-T11 – Módulo 3
– OntologiasT12 – Correcção do Teste 1
T13-T15 – Módulo 4
–Modelação de Sistemas: Comportamento
T16-T18 – Módulo 5– Modelação de Sistemas: Arquitectura
T19-T25 – Módulo 6– Temas avançados
2Modelação
Modelação do Comportamento
-
Revisão de Conceitos -
(Conceptual Modeling of Information Systems -capítulos 12 e 11 – ler por esta ordem!!)
3Modelação
Revisões…
• Conceito: Algo que concebemos no nosso entendimento através da generalização de certas instâncias.
• Esquema: A especificação de um modelo usando uma determinada linguagem.
• Modelo: uma interpretação segundo um determinado ponto de vista, o qual define os níveis de abstracção e de detalhe requeridos.
• Linguagem: Estrutura de conceitos e conjunto de regras para interpretar o significado dessa estrutura de conceitos. Uma linguagem pode ser formal ou informal; textual ou gráfica; etc.
• Diagrama: Um esquema representado por uma linguagem gráfica
• Notação: Os elementos visuais dos diferentes elementos da estrutura de conceitos de uma linguagens de modelação gráfica.
• Esquema Conceptual de um sistema é composto por:– Esquema estrutural: A descrição do modelo de domínio do sistema– Esquema de comportamento: A especificação das acções válidas e das
mudanças possíveis no estado do domínio do sistema
4Modelação
Acções:• Esquema de comportamento: A especificação das acções válidas e das
mudanças possíveis no estado do domínio do sistema
– Um sistema executa acções! Acções válidas são as acções permitidas ou possíveis de serem executadas pelo sistema.
– As acções podem provocar ou não alterações no estado do domínio.
• Uma acção que não altera o estado do domínio pode ser por exemplo uma acção que apenas comunica para o exterior
• Um acção que provoca mudanças no estado do domínio é uma acção que altera as entidades do sistema ou as suas relações. Uma mudança no estado do domínio pode ser:
– Simples: quando consiste apenas num evento estrutural
– Composta: quando consiste em dois ou mais eventos estruturais
5Modelação
Acções e Eventos:• As acções ocorrem na sequência de eventos!
• Um evento estrutural é um evento que evoca uma acção que muda o estado do domínio, podendo esta ser de inserção ou de eliminação de entidade; ou de inserção ou de eliminação de relação
• Um evento do domínio é um conjunto de um ou mais eventos estruturais que provocam uma mudança no estado do domínio, mudança essa que pode ser percebida ou considerada como única.
• Um evento do domínio corresponde assim a uma mudança no estado do domínio em que o estado antes da mudança e o estado depois da mudança satisfazem todos os constrangimentos estáticos de integridade do sistema expressos no seu esquema de comportamento.
• Dois ou mais eventos de domínio podem ocorrer em paralelo.
6Modelação
Acções de Pedidos de Eventos:• Tal como as acções ocorrem na sequência de eventos, os eventos são
também consequência de acções…
• Uma acção de pedido de evento (ou apenas pedido), é um pedido ao sistema para executar uma acção.
• Dependendo de como pode ser iniciado, um pedido pode ser:– Explícito externo: se gerado por um actor do sistema– Explícito induzido: se gerado por uma acção, como parte do seu efeito– Gerado: se resulta da verificação de uma condição lógica prevista no
sistema
– Temporal: quando é resultante de uma passagem de tempo (relevante para sistemas de informação, embora na realidade um pedido destes possa ser sempre considerado um dos casos anteriores, dependendo da natureza e arquitectura do sistema em causa…)
7Modelação
Modelação do Comportamento
-
Estados -
(Conceptual Modeling of Information Systems - capítulos 13 e 14)
8Modelação
Máquinas de Estado
• Uma máquina de estados é um autómato finito.
• Um autómato finito consiste numa sequência finita de estados e de transições de estados que ocorrem segundo os valores de entradas. Quando uma entrada varia, a máquina executa uma transição do seu estado actual (fonte) para um estado de destino.
– Máquina de Moore: Autómato finito em que os eventos determinam as mudanças de estado e as saídas sistema num dado momento dependem apenas do estado do sistema nesse momento.
– Máquina de Mealy: Autómato finito em que os eventos determinam não só as mudanças de estado mas também as saídas do sistema, que neste caso dependem do estado do sistema nesse momento e dos eventos que conduziram o sistema a esse estado.
9Modelação
Diagramas de Transição de Estado• Em termos genéricos, máquinas de estado podem ser representadas como
grafos em diagramas de transição de estado (ou apenas “diagramas de transição”),
10Modelação
Entidades de Sistema como Máquinas de Estado
• Máquinas de estado são modelos abstractos de sistemas do mundo real. Os significados em concreto de “estado”, “entrada” e “saída” dependem do sistema real a ser modelado…
• Num sistema, as entidades podem ser modeladas como máquinas de estado.
• Cada entidade de um sistema (objecto) tem num dado instante a sua própria máquina de estados, mas conceptualmente o mesmo diagrama de transição de estados pode ser usado para todas as instâncias do mesmo tipo de entidades (classes).
11Modelação
Entidades de Sistema como Máquinas de Estado
• Conceptualmente o estado de uma entidade pode ser modelado por um atributo. Neste caso as instâncias do tipo desse atributo definem todos os estados possíveis.
– Exemplo: se num dado sistema para um dado tipo de entidade definirmos o atributo “Estação do ano”, então segundo esse atributo as instâncias dessa entidade podem ter tipicamente quatro estados: “Primavera”, “Verão”, “Outono” e “Inverno”.
• Nalguns casos o número possível de estados pode ser indeterminado, ou mesmo infinito.
– Exemplo: se num dado sistema para um dado tipo de entidade definirmos o atributo “Peso”, as instâncias dessa entidade podem ter um grau infinito de estados, se os valores a atribuir a peso forem reais (os estados já poderão no entanto ser determinados se para esse atributo for definido um universo de valores através dos limites máximo e mínimo de peso, e da definição de uma escala discreta para os mesmos – ex: [0kg, 1kg, 2kg, 3kg, 4kg, 5kg]
12Modelação
Entidades de Sistema como Máquinas de Estado
• Conceptualmente, quando uma transição dispara e a máquina de estados muda para o estado de destino, podem-se executar ainda acções.
• Em geral podemos classificar essas acções como:
– Transição: A acção é executada quando a transição é disparada.
– Entrada no Estado: A acção é executada quando a máquina entra no estado.
– Saída do Estado: A acção é executada quando a máquina sai do estado.
– No Estado: A acção é executada enquanto a máquina está no estado.
• Uma linguagem de modelação conceptual pode permitir definir todos ou apenas um subconjunto destes tipos de acções
13Modelação
Ciclo de vida de uma entidade• O ciclo de vida de uma entidade num dado instante é a sequência de estados em que
essa entidade tenha estado desde que foi criada até ter chegado ao estado actual.
• Quando uma entidade é criada assume-se sempre que o seu ciclo de vida se inicia num dado estado, designado de “estado inicial”.
• Um ciclo de vida diz-se completo se o seu último estado é um “estado final”.– Exemplo: Se considerarmos um tipo de entidade “Viagem”, cujos estados são definidos pelo
atributo “Fase”, de valores possíveis “Planeamento”, “Partida”, “Execução”, “Chegada”e “Balanço”, podemos considerar que cada vez que uma instância deste tipo atingi o estado “Balanço” se completa o seu ciclo de vida.
• Nos diagrama de transição podemos definir dois tipos de constrangimentos aos ciclos de vida das entidades:
– O conjunto de estado permitidos (constrangimento estático)– O conjunto de sequências válidas para esses estados (constrangimento específico de
cada transição, pois envolve dois ou mais estados)
– Exemplo: Ainda para o caso do tipo de entidade “Viagem”, com os mesmos estados permitidos, podemos considerar a sequência de estados “Planeamento”, “Chegada”e “Balanço” como inválida, mas já a sequência “Planeamento” e “Balanço” pode ser válida (correspondendo a uma viagem anulada, por exemplo)
14Modelação
Mapas de Diagramas de Estado (“Statecharts”)• Podemos ter casos em que os ciclos de vida das entidades podem ser tão complexos,
que pode ser conveniente representá-los com vários níveis de granularidade.– Podemos assim numa dada perspectiva representar apenas como um estado algo
que na realidade corresponde em detalhe a uma máquina de estados, a qual se pode definir em detalhe num diagrama próprio, e assim sucessivamente.
– Neste caso dizemos que temos hierarquia de estados!
• Podemos ter ainda entidades em que os estados podem ser determinados por mais que um atributo cujos valores podem ser modificados com algum grau de independência.
– Neste caso temos partes do ciclo de vida da entidade a evoluir em paralelo.
• Quando queremos representar diagramas de estados recorrendo à representação hierárquica de estados e a representações paralelas dos ciclos de vida, podemos recorrer a mapas de diagramas de estado, que são simplesmente diagramas de estado em que estas complexidades tanto se escondem como se detalham.
15Modelação
Modelação do Comportamento
em UML
(Conceptual Modeling of Information Systems - capítulos 13 e 14)(UML, Metodologias e Ferramentas CASE - Capítulo 8)
16Modelação
Modelação da Dinâmica (ou Comportamento) em UML
• 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
17Modelação
Modelação da Dinâmica (ou Comportamento) em UML
18Modelação
Estados, Eventos e Interacções
Modelação 19
Interacções• Uma interacção é a especificação do comportamento de um conjunto de objectos,
representado por uma troca de mensagens, num determinado contexto, e com vista à concretização de um dado objectivo. Num diagrama de interacção representam-se portanto objectos e troca de mensagens entre esses objectos!
• Uma mensagem é a especificação de uma comunicação entre dois objectos.• Sempre que existe uma ligação entre dois objectos, pode ocorrer uma ou mais
interacções.
20Modelação
:Réu :Juiz
objecto
Diagrama de Objectos
:Réu :Juiz
1.pergunta()
objecto
ligação
mensagem
Diagrama de Interacção
2.responde()
Tipos de Mensagens de Interacção em UML
• Call: invoca uma operação de um objecto (o tipo mais comum…)• Return: devolve um valor para o objecto que a envia• Send: envia um sinal para o objecto de destino• Create: cria um objecto• Destroy: destrói um objecto (um objecto pode auto-destruir-se)
21Modelação
Diagramas de Sequência e de 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 comunicação...)
22Modelação
UML…
• 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
23Modelação
Diagramas de Estado - Representação
X
Estado inicial Estado finalEstado X
Nome
Operações
Um estado com detalhes
Transição
24Modelação
Diagramas de Estados - Exemplo
Exemplo de uma lâmpada
Acesa
Danificada
Apagada
Desligar(off) Ligar(on)
25Modelação
Diagramas de Estados - Exemplo
Modelação 26
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ções executadas quando se entra no estado– exit/actions - acções executadas quando se sai do estado– do/activities - actividades executadas 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
27Modelação
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.
28Modelação
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ção29Modelação
Mapas de Diagramas de Estado em UML
Modelação 30
Mapas de 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...
31Modelação
Diagramas de Estado – Sub-Estados Concorrentes
32Modelação
Para as próximas aulas…
• 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
33Modelação
Diagramas de ActividadeUm 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 estados ilustra o fluxo de controlo dos estados dos objectos. – Um diagrama de interacção ilustra o fluxo de controlo entre objectos.– Um diagrama de actividades ilustra o fluxo de controlo (e de objectos) entre
actividades dos processos
34Modelação
Diagramas de Actividade
• Diagramas que fornecem uma visão simplificada do fluxo de controlo de um caso de uso, operação ou de um processo
• Mostram o fluxo entre actividades (e possivelmente também o fluxo de informação)
Actividade 1
Actividade 2
estado inicial
estado final
transição
35Modelação
Diagramas de Actividade - Conceitos
• Acções: execuções atómicas.• Actividades: execuções que podem ser decompostas (noutras actividades ou em
acções) e interrompidas.• 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).
36Modelação
Diagramas de Actividade
Decisões (“… ou …”)
Duas formas equivalentes de se representar uma decisão
37Modelação
Diagramas de Actividade
Todas as actividades são realizadas concorrentemente
Conjunto de actividades realizadas concorrentemente, independentemente da sua ordem de execução
Caminhos Concorrentes...
38Modelação
Diagramas de ActividadeExemplo para um algoritmo - Série de Fibonacci
39Modelação
Diagramas de ActividadeExemplo para um processo de negócio / workflow
Partições - permitem separar o diagrama em segmentos paralelos, em que cada um apresenta as actividades de cada entidade interveniente no processo global.
As entidades das partições são tipicamente actores do sistema
A partição de actividades pode representar uma ou mais dimensões do problema… Mas esta solução não é escalável!!!
40Modelação
Diagramas de ActividadeExemplo para um processo de negócio / workflow
Uma alternativa escalável é ignorar as partições e especificar, nas actividades, a entidade responsável
41Modelação
Diagramas de Actividade – Exemplo para um processo de negócio / workflow
Representação de objectos afectados nas entradas e saídas das actividades
42Modelação