.NET - Implementando Soluções OOP II


Programar é fácil desenvolver software de qualidade é uma arte.

Na primeira parte do artigo focamos na modelagem dos aspectos estáticos de uma solução OOP (ou POO - Programação Orientada a Objetos) e vimos que:

Vamos continuar a discutir as técnicas de modelagem da UML focando na modelagem dos aspectos dinâmicos da solução. Para isso vamos abordar os seguintes assuntos:

Compreendendo Cenários

Os cenários nos ajudam a compreender as interações dinâmicas que irão ocorrer entre os objetos (objetos são instâncias de classes). Um cenário é uma descrição textual de um processo interno necessário para implementar uma funcionalidade do sistema documentada em um caso de uso.(Lembre-se que um caso de uso descreve a funcionalidade do sistema do ponto de vista dos usuários externos ao sistema). Assim um cenário detalha a execução de um caso de uso descrevendo os passos que precisam ser realizados internamente pelos objetos que compõe o sistema.

Como exemplo vemos na figura 1.0 a representação do caso de uso Alugar Filme para uma aplicação de Video Locadora :

figura 1.0 - Caso de uso - Alugar Filme

O texto a seguir descreve este caso de uso:

Dessa forma o seguinte cenário descreve o processamento interno do caso de uso Alugar Filme:

Este cenário descreve a melhor execução possível para o caso de uso , mas exceções podem ocorrer e um único caso de uso pode gerar vários cenários. Por exemplo, outro cenário criado pelo para o caso de uso Alugar Filme poderia descrever o que acontece quando um filme não esta presente no estoque.

Depois de mapear os vários cenários para um caso de uso você pode criar diagrama de interações para determinar quais classes de objetos estarão envolvidos na realização da funcionalidades dos cenários. Os diagramas de interação também revelam quais operações serão necessárias para essas classes de objetos.

Na UML temos dois diagramas de interação:

Diagramas de Sequência

Um diagrama de seqüência é um diagrama de objetos, ou seja, ele contém como um conjunto de objetos de diferentes classes. O objetivo dos diagramas de seqüência é descrever as comunicações necessárias entre objetos para a realização dos processos de um sistema. Os diagramas de seqüência têm este nome porque descrevem ao longo de uma linha de tempo a seqüência de comunicações entre objetos.

Como podem existir muitos processos em um sistema, sugere-se proceder à construção dos diagramas de seqüência por caso de uso.(Primeiro, se define qual o papel do sistema (Casos de Uso), depois é definido como o software realizará seu papel (Sequência de operações) - fonte: http://pt.wikipedia.org/wiki/Diagrama_de_sequ%C3%AAncia)

A figura 2.0 apresenta uma representação de um diagrama de sequência como um modelo visual em duas dimensões :

  • Um diagrama de sequência representa um cenário de caso de uso
  • Mostra os eventos que partem do ator para o sistema
  • O sistema irá emitir uma resposta para cada evento recebido do ator
  • Descreve ao logo de uma linha de tempo a sequência de comunicação entre os objetos
  • O tempo é visualizado no sentido vertical de cima para baixo
  • As mensagens trocadas entre os objetos são representadas por setas
  • fornecem entrada básica para determinar responsabilidades de classes e interfaces.
figura 2.0 - Representação de um diagrama de sequência

Observe que o fluxo de mensagens de objeto para objeto é representando horizontalmente enquanto que o fluxo de tempo entre as interações é representando por verticalmente iniciando a partir do topo e progressivamente decrescendo até a base. Os objetos são representados juntos no topo e cada um possui uma linha tracejada e um retângulo vertical que representa a ativação do objeto onde a altura do retângulo representa o tempo de ativação do objeto.

Na figura 2.1 abaixo vemos exemplos de ativação, período de ativação e mensagem de objetos representados em um diagrama de sequência:

figura 2.1 - Exemplos de representação de ativação, período de ativação e mensagem
(fonte:
http://www.inf.ufpr.br/silvia/ES/UML/Diagramaseqsisteal.pdf)

Os objetos trocam mensagens entre si e uma seta iniciando do objeto que iniciou a mensagem e terminando no objeto que irá receber a mensagem descreve esta interação. Uma seta tracejada representa a resposta do objeto. As mensagens descritas no diagrama de sequência irão formar a base dos métodos das classes do sistema.

Como exemplo vemos na figura 3.0 o diagrama de sequência para o cenário representando pelo caso de uso Alugar Filme:

figura 3.0 - Diagrama de sequência referente ao cenário do caso de uso Alugar Filme

Conforme você analisa o diagrama de seqüência, você ganha uma compreensão das classes de objetos que irão estar envolvidos na realização do processamento do programa e quais métodos você terá que criar e anexar a essas classes. Você também deve modelar as classes e métodos descritos no diagrama de seqüência no diagrama de classes. Estes documentos de projeto deve ser continuamente cruzados e revistos sempre quando necessário para que correções e aperfeiçoamentos seja feitos.

O diagrama de sequência da figura 3.0 revela que haverá quatro objetos envolvidos na realização do caso de uso Alugar Filme. Além disso temos as seguintes informações:

Tipos de mensagens entre objetos

Ao analisar o diagrama de seqüência, você pode determinar quais mensagens devem ser passadas entre os objetos envolvidos no processamento. Na POO, as mensagens são transmitidas de forma síncrona ou assíncrona.

A seta tracejada mostra geralmente uma mensagem de resposta; Estas linhas são mostrados na Figura 4.

figura 4.0 - Tipos de mensagens

Para o exemplo do diagrama de sequência do cenário Alugar Filme podemos perceber que o objeto Funcionário inicia uma mensagem síncrona com o objeto Filme, requisitando informação sobre se existe uma cópia do filme no estoque; o objeto Filme retorna uma mensagem ao funcionário que existe uma cópia em estoque.

Mensagens recursivas

Não é incomum na POO um objeto ter uma operação que invoca uma outra instância do próprio objeto. Isto é referido como recursão.

A seta de mensagem que circula de volta para o objeto de chamada representa a recursão no diagrama de seqüência.

O fim da seta aponta para um retângulo de menor ativação, representando uma segunda ativação do objeto desenhado na parte superior do retângulo de ativação original (ver Figura 5). Por exemplo, um objeto Conta calcula juros compostos para os pagamentos em atraso; para calcular os juros compostos ao longo de períodos diversos, ele necessita chamar-se várias vezes.

figura 5.0 - Exemplo de mensagem recursiva

Mensagens Iterativas

Algumas vezes uma mensagem é chamada repetidas vezes até que uma condição seja satisfeita. Assim para totalizar o valor de uma locação um método é chamado repetidas vezes até que todas as locações de um cliente sejam calculadas. A isso chamamos iteração.

A representação de tais mensagens é feita por um retângulo que envolve a mensagem no diagrama de sequência. A condição de vinculação da iteração é descrita canto superior esquerdo do retângulo. A figura 7.0 mostra um exemplo de mensagem iterativa:

figura 7.0 - Mensagem iterativa

Mensagens Restritivas

As mensagens trocadas entre os objetos pode ter alguma restrição condicional. Por exemplo: os clientes precisam estar em dia com suas locações para poderem efetuar uma nova locação. Quanto isso precisa ser descrito colocamos a restrição entre colchetes ([]) na sequência. A mensagem será enviada somente se a condição for avaliada como verdadeira (figura 8.0):

figura 8.0 - Mensagem restritiva

Mensagens Ramificadas

Quando as restrições condicionais são vinculadas a uma mensagem, muitas vezes isso ocorre em uma situação de ramificação onde, dependendo da condição, mensagens diferentes podem ser invocados.

A figura 9 representa um uma restrição condicional ao solicitar um aluguel de um filme:

Figura 9.0 - Restrição condicional

Um retângulo desenhado em torno das mensagens mostra os caminhos alternativos que podem ocorrer dependendo da condição.

Diagrama de Atividades

Um diagrama de atividades ilustra o fluxo de atividades que precisam ocorrer durante uma operação ou processo.

Você pode construir o diagrama de atividades para ver o fluxo de trabalho em vários níveis de foco.

Um diagrama de atividade consiste em o ponto de partida do processo representado por um círculo sólido e setas de transição que representam o fluxo ou a transição de uma atividade para outra.

Retângulos arredondados representam as atividades, e um círculo com uma bola representa o ponto final do processo. Por exemplo, a Figura 10 mostra um diagrama de atividades genérico que representa um processo que começa com a atividade A, passa para a atividade B e conclui.

figura 10 - Diagrama de atividades

Freqüentemente uma atividade irá condicionalmente seguir outra atividade , por exemplo, afim de alugar um filme , é feita a verificação da identificação do cliente. Um diagrama de atividades representa a condicionalidade por um ponto de decisão (representado por um losango) com a guarda da decisão (a condição deve ser verdadeira para a atividade continuar) em colchetes([ ]) próxima da linha do fluxo conforme mostra a figura 11 abaixo:

figura 11 - Ponto e Garda de decisão

Em alguns casos duas ou mais atividades podem ser executadas em paralelo. Uma linha sólida desenhada perpendicularmente para setas de transação representam a divisão do fluxo em duas ou mais atividades. A figura 12 representa um diagrama de atividade para o processo de devolução de um filme. A ordem na qual os fluxos para incrementar o estoque e baixar o filme da locação não importa:

figura 12 - Processamento Paralelo

O propósito do diagrama de atividades é modelar o controle de fluxo de cada atividade enquanto o programa esta sendo processado. Ele não nos indicada qual objeto possui a responsabilidade sobre cada atividade. Para atribuir a responsabilidade de cada atividade aos objetos podemos segmentar o diagrama de atividades em painéis verticais particionados para cada atividade definido o objeto responsável pela atividade no topo do painel. A figura 13 abaixo mostra o diagrama de atividades para o processamento do caso de uso Alugar FIlme exibindo os painéis e cada objeto responsável por cada atividade:

figura 13 - Atribuindo responsabilidades aos objetos

Para encerrar vou mostrar como podemos usar os diagramas de atividades para modelar a interface do usuário de uma aplicação.

Embora não seja um papel específico da UML modelar a interface do usuário podemos usar alguns de seus diagramas para nos ajudar nesta tarefa.

O primeiro passo no desenvolvimento da interface do usuário e definir uma análise das tarefas para descobrir como os usuários irão interagir com o sistema.

A análise das tarefas esta baseado nos casos de uso e nos cenários que já foram modelados anteriormente. Podemos dessa forma criar diagramas de atividades para modelar como a interação entre o usuário e o sistema irá ocorrer. Na figura 14 vemos um diagrama de atividades modelando as atividades que o usuário realiza durante o processo de registro de informação de locação:

Figura 14 - Diagrama de Atividades - Registro de informação de locação

E assim neste artigo apresentei os conceitos básicos sobre cenários, diagramas de sequência e diagramas de atividades de forma a dar uma idéia de como usar esses diagramas da UML para modelar a interação entre os objetos.

"Em verdade vos digo que, qualquer que não receber o reino de Deus como menino, não entrará nele." Lucas 18-17

Referências:


José Carlos Macoratti