.NET - Implementando Soluções OOP

.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:

É o DRS que define o escopo do sistema;
Utilizamos o diagramas de caso uso, para definir os limites do sistema e identificar as entidades externas que irão utilizar o sistema;
Usamos o diagramas de classe para definir o modelo da estrutura das classes que serão desenvolvidas para implementar o sistema;

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:

O propósito dos cenários e como eles estendem os modelos de casos de uso;
Como os diagramas de sequência modelo a interação dependente do tempo dos objetos em um sistema;
Como o diagrama de atividades mapeia o fluxo de atividades durante o processamento da aplicação;
A importância do desenha da interface do usuário e como ela se encaixa no processo de uma solução OOP;

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:

Pré-Condições : O cliente faz uma solicitação para alugar um filme para o funcionário da locadora. O cliente faz parte dos membros cadastrados para locação de filmes da locadora e entrega ao funcionário seu cartão de registro contendo sua identificação de membro. A identificação do cliente como membro é verificada no sistema. As informações do cliente são exibidas sendo verificada se a conta do cliente não possui pendências de locações a serem quitadas;
Descrição : O funcionário verifica se o filme solicitado para locação esta no estoque. As informações de locação são registradas e o cliente é informado da data de devolução (vencimento da locação);
Pós-Condições : Nenhuma;

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

O filme é verificado no estoque;
O número de cópias existentes é atualizado sendo decrementado da unidade locada;
A data de vencimento da locação (data de devolução) é determinada;
A informação da locação é registrada. Esta informação inclui: o título do filme, o número da cópia, a data atual e a data de devolução;
O cliente é informado da locação;

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 seqüência
Diagramas de colaboraçã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:

O objeto Cliente é uma instância da classe Cliente e é responsável por encapsular e manter as informações referentes a um cliente.
O objeto Funcionario é uma instância da classe Funcionario e é responsável pela gestão do processamento envolvido em alugar um filme.
O objeto Filme é uma instância da classe Filme e é responsável por encapsular e manutenção das informações relativas a um vídeo disponível para aluguel.
O objeto Locação é uma instância da classe Alugar e é responsável por encapsular a manutenção das informações relativas a um vídeo atualmente sendo alugado.

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.

Quando as mensagens são transmitidas de forma síncrona, o objeto de envio suspende o processamento e aguarda uma resposta antes de continuar. A linha traçada com uma ponta de flecha fechada no diagrama de seqüência representa mensagens síncronas.
Quando um objeto envia uma mensagem assíncrona, o objeto continua o processamento e não fica esperando uma resposta imediata do objeto receptor. A linha traçada com uma ponta de seta aberta no diagrama de seqüência representa de mensagens assíncronas.

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

Se o status do item Filme é sim indicando que o filme existe em estoque, uma mensagem é enviada para o objeto Locação para criar uma locação.
Se o status do item Filme for não indicando que ele não existe no estoque, uma mensagem é enviada para o objeto Reservar para criar uma reserva.

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.

Nível Alto - O Foco em nível de sistema representa cada caso de uso como uma atividade e diagramas do fluxo de trabalho entre os diferentes casos de uso.
Diagramas de fluxo de nível médio ocorrem em um caso de uso particular.
Diagrama de fluxo de baixo nível ocorrem no interior de uma operação particular de uma determinada operação de uma das classes do sistema.

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