Diagramas de Interacção

Transcrição

1 24 Diagramas de Interacção Sumário: Tipos de Diagramas de Interacção Interacções Diagramas de Comunicação conceitos base Diagramas de Sequência conceitos base Diagramas de Comunicação conceitos avançados Diagramas de Sequência conceitos avançados

2 25 Tipos de Diagrama de Interacção Os Diagramas de Classe modelam a arquitectura de objectos do sistema Os Diagramas de Interacção modelam o diálogo entre os objectos que compõem o sistema. O UML define dois tipos de diagramas de interacção: Diagramas de Comunicação Diagramas de Sequência Os dois tipos de diagrama têm o mesmo poder expressivo. Contudo, muda a forma de apresentação: Diagramas de Comunicação ênfase na estrutura; Diagramas de Sequência ênfase na sequência temporal dos eventos. Componentes base dos diagramas de interacção: Objectos (ver diagramas de objecto); Interacções entre objectos.

3 26 Interacções Uma Interacção representa comunicação entre objectos (envio de mensagens). Ligação: Instância de uma associação Decorações: Association a instância é conhecida por intermédio de uma associação Self a instância refere-se a si própria global/local/parameter scope da instância num dado contexto Mensagens: call invocação síncrona ( ) send invocação assíncrona ( ) UML versões <= 1.3 send invocação assíncrona ( ) UML versões >= 1.4 Return ( < ) <<create>> criar objecto e <<destroy>> destruir objecto

4 27 Diagramas de Comunicação (Communication) Apresentam uma configuração específica do sistema que suporta um dado Use Case (que objectos deverão existir em tempo de execução runtime). Para essa configuração, mostra como os objectos comunicam entre si (colaboram) para satisfazer um dado pedido. Os use cases concretizam-se por colaborações entre objectos. A ênfase está na organização estrutural dos objectos: Permite analisar se a configuração necessária é suportada pela estrutura de classes idealizada nos diagramas de classe. Ordenação temporal das mensagens não é claramente representada. Notação standard: X.y.zz (ex: 1.2.1)

5 28 Um exemplo...

6 29 Diagramas de Comunicação Lógica Condicional A notação suporta a modelação de estruturas condicionais e repetitivas: Condição: [guarda] mensagem Repetição: *[guarda] mensagem Em alternativa podemos utilizar mais que um diagrama para modelar o comportamento.

7 30 Diagramas de Comunicação Lógica Condicional A mensagem mensagema é enviada 10 vezes antes que as seguintes mensagens possam ser enviadas. A mensagem mensagemb enviada em 2.a só é enviada se a condição for verdadeira. As mensagens enviadas em 2.b e 2.c são enviadas ao mesmo tempo

8 DIAGRAMAS DE SEQUÊNCIA Vamos introduzir agora uma parte da notação UML que é destinada à criação de modelos de comportamento dos sistemas usando Diagramas de Sequência.

9 DIAGRAMAS DE SEQUÊNCIA DIAGRAMAS DE INTERACÇÃO são diagramas que visam em UML a modelação do comportamento de componentes dos sistemas, em especial oferecendo uma representação gráfica e para as interacções entre os objectos. OS DIAGRAMAS DE SEQUÊNCIA, em particular, representam as interacções entre objectos através das mensagens que são trocadas entre eles, especificando ainda qual o respectivo encadeamento temporal correcto (sequência temporal). OS DIAGRAMAS DE SEQUÊNCIA de mais alto nível, são diagramas da fase de análise e não de implementação, representando o sistema como uma black-box, ou seja, sem indicar ainda sub-sistemas, representando os eventos que os actores geram, e as respostas comportamentais do sistema (operações do sistema). Por isso, designam-se, por vezes, DSS (Diagramas de Sequência de Sistema).

10 DIAGRAMAS DE SEQUÊNCIA A partir da especificação textual dos UC, os passos dos Actores são vistos como eventos externos que iniciam operações do sistema.

11 DS: NOTAÇÃO ESSENCIAL Outras formas de representação de objectos

12 35 Diagramas de Sequência Representam o mesmo que os Diagramas de Comunicação, mas a ênfase é colocada na ordenação temporal das mensagens. Permitem analisar a distribuição de responsabilidade pelas diferentes classes (analisar onde está a ser efectuado o processamento)

13 36 Diagramas de Sequência Cálculo do preço de uma encomenda

14 37 Diagramas de Sequência Cálculo do preço de uma encomenda (diagrama alternativo com controlo descentralizado)

15 38 Diagramas de Sequência Diagrama de sequência do método dispatch procedure dispatch! for(linha l:encomenda)! if(product.value > 10)! express.dispatch()! else! normal.dispatch()! if (confirmacao)! messenger.confirm

16 39 Diagramas de Sequência Tipos de frames de interacção alt - alternativa, múltiplas regiões, sendo que apenas uma delas é escolhida opt - opcional, sendo que as interações dentro da região são executadas se a condição for verdadeira break igual a opt, mas o resto do diagrama não é executado. par - as várias regiões ocorrem em paralelo loop - ciclo, sendo que a região executa-se n vezes enquanto a condição for verdadeira region - indica uma região crítica, com apenas uma thread em execução neg - negação, mostra uma interacção inválida ref - referência, indica uma interacção definida noutro diagrama. sd - referencia um diagrama de sequência!

17 DS: FRAME alt

18 DS: FRAME loop Para cada uma das figuras do conjunto de figuras que seja visível, determinar os seus limites (cf. r) e adicionar tal rectângulo ao rectângulo que está a ser calculado (limites totais do desenho).

19 DS: MODULARIDADE A estruturação de diagramas pode ser feita identificando diagramas de sequência usando sd nome e referenciando-os usando o frame ref.

20 DS: MODULARIDADE

21 DS: EXEMPLOS Objectos necessitam por vezes de enviar mensagens para si próprios: cf. this.mensagem()

22 DS: EXEMPLOS Mensagem para this!!

23 46 Diagramas de Sequência Exemplo Seja um sistema de gestão de contéudos. A especificação do use case Criar Conta de Blog vai ser detalhada, no que concerne à descrição da colaboração, num diagrama de sequência. Diagrama de Use Case:

24 47 Diagramas de Sequência Exemplo CMS A narrativa do use case apresentado é:

25 48 Diagramas de Sequência Exemplo CMS A primeira versão do diagrama de sequência mostra os participantes e as mensagens que são trocadas durante o use case. Mostram-se as interacções entre os actores externos e o sistema - é um diagrama de alto nível

26 49 Diagramas de Sequência Exemplo CMS O sistema não vai ser implementado como uma peça monolítica (uma única classe), o que significa que se deve acrescentar mais detalhe.

27 50 Diagramas de Sequência Exemplo CMS O diagrama anterior não mostra a criação do blog! Esse aspecto deve ser acrescentado ao detalhe do diagrama.

28 51 Diagramas de Sequência Exemplo CMS O objecto com a informação dos detalhes de um autor (authordetails) já não é necessário após a criação de newaccount, logo pode ser destruído.

29 52 Diagramas de Sequência Exemplo CMS A descrição do diagrama pode ser enriquecida com informação sobre a lógica condicional do controlo de fluxo.

30 53 Diagramas de Sequência Exemplo CMS Por forma a lidar com a complexidade do diagrama é possível estruturar uma interacção em vários diagramas.

31 54 Diagramas de Sequência Exemplo CMS Em que o sub-diagrama de sequência é:

32 DS: EXEMPLOS A possibilidade de termos diagramas de sequência com modularidade permitenos agora gerir tal modularidade, ou seja, pensar em regras que nos digam por onde devemos partir estas sequências, isto é, com que critério ou método. Necessitamos de ter um método sistemático de passar dos UC para os DS!

33 MÉTODO: UCs DS Use Cases não são operações do sistema mas incluem operações do sistema; Jacobson diz que: cada use case constitui uma série completa de eventos iniciados por um actor e especifica a interacção que tem lugar entre o actor e o sistema. Um use case é, portanto, uma sequência especial de transacções relacionadas, executadas por um actor e pelo sistema em diálogo. (para o actor é atómica!) Cada transacção destas pode muito bem ser analisada, individualizada e transposta de forma sistemática para o Diagrama de Sequência

34 MÉTODO: UCs DS Aceites todas estas definições standard do que se deve entender ser um UC, o que se deve entender por <<include>> e por <<extend>>, como se devem escrever UC textuais, etc., torna-se agora importante passar dos diagramas de UC e das descrições textuais de Ucs, para especificações mais detalhadas do ponto de vista comportamental. Problema: Como passar sistematicamente, ou seja com método, dos UC para os Diagramas de Sequência que especificam, com mais detalhe, como o Sistema em desenvolvimento responde às mais diversas solicitações dos actores, tal como anteriormente identificado no Diagrama de Use Cases? Resposta: Não há qualquer metodologia, quer no RUP, quer noutro processo qualquer OO para o fazer. Vamos assim introduzir um método inovador, não documentado ainda em livros nem artigos, desenvolvido visando uma coerente e correcta resolução desta fase de transição do RUP, de forma a que, seguindo certas regras, se atinjam certos objectivos de forma coerente e, portanto, sendo os passos reversivelmente identificáveis.

35 MÉTODO: UCs DS PASSO 1 : Identificar as transacções no UC (por exemplo com cores) T1 T2 T3 T4 Algumas são do tipo Acção -> Reacção (ie. possuem apenas 2 passos)

36 MÉTODO: UCs DS O sistema foi já dividido em 2 subsistemas!

37 MÉTODO: UCs DS Transacções T1 T2 T3 T4

38 MÉTODO: UCs DS LEVANTAMENTO DE UMA ATM: Alternativas e Excepções. Como fazer?

39 MÉTODO: UCs DS Para o Main Flow (Cenário de Sucesso) sabemos já identificar as transacções definidas no UC textual e passar cada uma delas para o Diagrama de Sequência. Precisamos agora de ter uma forma sistemática de representar no Diagrama de Sequência os outros dois tipos de fluxo que podemos ter num UC: Alternativas e Excepções. Precisamos ainda de saber tratar sistematicamente as situações em que o UC <<include>> outros Ucs ou é estendido por outros Ucs. Se criarmos um template geral do que pode ser um UC textual, talvez tal nos ajude a identificar todos os casos possíveis de transformação de um UC num DS.

40 TEMPLATE GERAL UCs

41 PASSAGEM PARA DS (1) Main Flow Tratamento dos Fluxos Alternativos

42 PASSAGEM PARA DS (2) break break Tratamento dos Fluxos de Excepção Tratamento dos <<include>> Tratamento dos <<extend>>, mesmo que tenham Extension Points alternativos

43 ONDE ESTAMOS RUP/DSS?