Modelação Aula T14 Modelação Conceptual de Sistemas Comportamento (2) Referências: –Conceptual Modeling of Information Systems (Capítulos 11, 12, 13 e

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


-

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


• 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


• 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


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…






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…






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


Decisões (“… ou …”)

Duas formas equivalentes de se representar uma decisão

37Modelação


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

Documents

Modelação Aula T14 Modelação Conceptual de Sistemas Comportamento (2) Referências: –Conceptual Modeling of Information Systems (Capítulos 11, 12, 13 e