DIAGRAMAS DE INTERAÇÃO

         Diagramas de interação são modelos que descrevem como grupos de objetos colaboram em algum comportamento.

        Tipicamente, um diagrama de interação captura o comportamento de um único caso de uso. O diagrama mostra vários objetos e as mensagens que são passadas entre estes objetos em um caso de uso.

        Ilustarei o enfoque com um simples caso de uso que exibe o seguinte comportamento:

            * Uma janela de Entrada de Pedido envia uma mensagem "preparar" para um pedido.
            * O Pedido, então, envia "preparar" para cada linha de Pedido do Pedido.
            * Cada Linha de Pedido verifica o item de Estoque dado.
                    - Se esta verificação retornar "verdadeira", a Linha de Pedido subtrai a quantidade apropriada do estoque
                       e cria um item de entrega.
                    - Se a quantidade de Estoque caiu abaixo do nível de pedido, este item de Estoque solicita uma ordem de
                       reposição.

        Existem dois tipos de diagramas de interação: diagramas de seqüência e diagramas de colaboração.

        Em um diagrama de seqüência, um objeto é mostrado como uma caixa na parte superior de uma linha tracejada vertical. (veja figura 6)

Figura6.gif (8795 bytes)

Firgura 6 - Diagrama de Seqüência

        A linha vertical é chamada de Linha de Vida do objeto. A linha de vida representa a vida do objeto durante a interação. Esta forma tornou-se popular inicialmente com Jacobson.

        Cada mensagem é representada por uma flecha entre as linhas de vida de dois objetos. A ordem na qual estas mensagens ocorrem é mostrada da parte superior à parte inferior da página. Cada mensagem é rotulada, no mínimo, com o nome da mensagem; você também pode incluir os argumentos e alguma informação de controle. Você pode ainda mostrar uma autochamada, uma mensagem que um objeto manda para si mesmo, enviando a flecha de mensagem de volta para a mesma linha de vida.

        Para mostrar quando um objeto está ativo ( para uma interação procedimental, isso indicaria que o procedimento está na pilha do processador), você inclui uma caixa de ativação. Você pode omitir caixas de ativação; isso facilita o desenho do diagrama, mas o torna mais difícil de ser compreendido.

        Duas informações de controle são valiosas.

        Primeiro, existe a condição, que indica quando a mensagem é enviada ( por exemplo, [precisa de reposição]). A mensagem é enviada somente se a condição for verdadeira. Condições são úteis em casos simples como este, mas para casos mais complicados, prefiro projetar diagramas de seqüência separados para cada caso.

        O segundo marcador de controle útil é o marcador de iteração, que mostra que a mensagem é enviada várias vezes para múltiplos objetos receptores, como aconteceria quando você estivesse fazendo iteração em uma coleção. Você pode mostrar a base da iteração entre colchetes, tal como *[para todas as linhas de pedido].

        A figura 6 inclui um retorno, que indica o retorno de uma mensagem, não uma nova mensagem. O retorno difere das mensagens regulares pois a  linha é tracejada. Algumas pessoas desenham um retorno para cada mensagem, mas acredito que isso torna o diagrama confuso, então os desenho somente quando sinto que eles podem acrescentar clareza ao diagrama. Só utilizei um retorno na figura 6 para demonstrar a notação; se você remover o retorno, acredito que o diagrama continua tão claro como antes. Isto é um bom teste.

        Como você pode ver, a figura 6 é muito simples e tem um apelo visual imediato, o que é sua grande qualidade.

        Uma das coisas mais difíceis de compreender em um programa orientado a objetos é o fluxo global de controle. Um bom projeto tem muitos pequenos métodos em classes diferentes, e, ás vezes, pode ser difícil entender a seqüência global do comportamento pretendido. Você pode terminar examinando o código tentando encontrar o programa. Isto é particulamente verdadeiro para as pessoas sem experiência com objetos. Os diagramas de seqüência ajudam a entender esta seqüência.       


Diagramas de Colaboração

      A segunda forma de diagrama de interação é o diagrama de colaboração.

        Dentro de um diagrama de colaboração, os objetos são mostrados como ícones. Como em um diagrama de seqüência, flechas indicam as mensagens enviadas dentro de um dado caso de uso. Desta vez, entretanto, a seqüência é indicada pela numeração das mensagens.

        A numeração de mensagem torna mais difícil ver a seqüência do que a colocação das linhas de mensagem de cima para baixo na página. Por outro lado, o layout espacial permite que você mostre outras coisas mais facilmente.Você pode mostrar como os objetos são ligados entre si e utilizar o layout de diagramas de classes ou de pacotes para esboçar colaborações entre objetos.

        Você pode usar um dos diversos esquemas de numeração para diagramas de colaboração. O mais simples é ilustrado na figura 7. Outro enfoque envolve um esquema de numeração decimal, visto na figura 8.

Figura8.gif (6130 bytes)

Firgura 7 - Diagrama de Colaboração com Numeração Simples

        Antigamente, a maioria das pessoas utilizava o esquema de numeração simples. UML usa o esquema decimal porque ele torna claro qual operação está chamando outrta operação, embora isso dificulte a visão da seqüência completa.

Figura9.gif (5704 bytes)

Firgura 8 - Diagrama de Colaboração com Numeração Decimal

        Independente do esquema de numeração a ser usado, você pode acrescentar o mesmo tipo de informação de controle mostrado em um diagrama de seqüência.

        Na figura 9 e na figura 10, você pode ver as várias formas de esquema de nomeação de objetos de UML, NomeObjeto: NomeClasse, na qual tanto o nome do objeto quanto o nome da classe podem ser omitidos. Observe que se omitir o nome do objeto, você deve manter os dois pontos de modo que fique claro que o que aparece é nome da classe e não o nome do objeto. Por exemplo, o nome "linha Macallan: Linha de Pedido" indica uma ocorrência de Linha de Pedido chamada linha Macallan (Macallan é um uísque). Tenho a tendência de nomear objetos no estilo SmalTalk a ser usado nos diagramas de seqüência. (Este esquema é também UML porque "umObjeto" é um bom nome para um objeto).


Comparando Diagramas de Seqüência com Diagramas de Colaboração

        Diferentes desenvolvedores têm preferências diferentes no que diz respeito à escolha da forma de diagrama de interação a ser usado. Geralmente, prefiro o diagrama de seqüência porque gosto da ênfase que ele dá à seqüência; é facil ver a ordem que as coisas acontecem. Outros preferem diagrama de colaboração porque podem usar o layout para indicar como objetos são estaticamente conectados.

        Uma das características principais de qualquer forma de um diagrama de interação é sua simplicidade. Você pode ver facilmente as mensagens observando o diagrama. Entretanto, se você tentar representar algo além de um processo seqüencial úncio sem muito comportamento condicional ou iterativo, a técnica deixa de funcionar tão bem.

        Um dos problemas com diagramas de interação é que seu uso pode ser inadequado na exploração de alternativas. Ao experimentar alternativas, você tem muito trabalho apagando e refazendo diagramas. Como resultado, acredito que cartões CRC (veja no box abaixo) são muito úteis para exploração de comportamento.

Cartões CRC

          No final da década de oitenta, um dos maiores centros de tecnologia de objetos estava nos laboratórios de pesquisa da Tektronix, Portland, Oregon. Estes laboratórios tinham alguns dos mais importantes usuários de Smaltalk, e muitas idéias-chave sobre tecnologia de objetos foram desenvolvidas lá. Dois renomados programadores de Smaltalk que trabalhavam lá eram Ward Cunningham e Kent Beck.

          Cunningham e Beck estavam e estão preocupados em como ensinar o profundo conhecimento de Smaltalk que eles adquiriram. Da questão de como ensinar objetos surgiu a simples técnica de cartões Class-Responsibility - Collaboration (CRC).

          Em vez de utilizar diagramas para desenvolver modelos, como a maioria dos metodologistas fazia, Ward representava classes em cartões de índice 4" x6". Em vez de indicar atributos e métodos nos cartões, ele escrevia  responsabilidades.

          Então, o que é uma responsabilidade? É uma descrição de alto nível do propósito de uma classe. A idéia é tentar fugir de uma descrição de dados e processo e , em vez disso, capturar o propósito da classe em poucas sentenças. A escolha de um cartão é deliberada. Você não pode escrever mais do que cabe em seu exíguo espaço. (veja figura 11).

          O segundo C refere-se aos colaboradores. Estes representam as outras classes com as quais esta classe precisa trabalhar. Isto dá alguma idéia das ligações entre classes- ainda de alto nível.

          Um dos maiores benefícios dos cartões CRC é que eles encorajam animadas discurssões entre os desenvolvedores. Quando você está trabalhando com um caso de uso para ver como as classes o implementarão. os diagramas de interação deste capítulo podem ser lentos de se projetar. Freqüentemente, você precisa considerar alternativas, e com diagramas perde-se muito tempo apagando e refazendo as alternativas. Com cartões CRC, você modela a interação pegando cartões e movendo-os. Isso permite que se considere rapidamente diversas alternativas.

Figura11.gif (7985 bytes)

Firgura 9 - Cartão Classe-Responsabilidade-Colaboração (CRC)

          À medida que faz isso, você forma idéias sobre responsabilidades e as escreve nos cartões. È importante pensar sobre responsabilidades porque você deixa de considerar classes como simples portadores de dados e ajuda os membros da equipe compreenderem o comportamento de cada classe em um nível mais elevado. Uma responsabilidade pode corresponder a uma operação, a um atributo, ou (mais provavelmente) a um aglomerado indeterminado de atributos e operações.

          Um erro comum que vejo as pessoas cometerem e gerar longas listas de responsabilidades de baixo nível. Isto é realmente um erro. As responsabilidades devem caber facilmente em um cartão. Eu questionaria qualquer cartão com mais de três responsabilidades. Você deve questionar se a classe deve ser dividida ou se as responsabilidades seriam mais bem formuladas se englobadas em declarações de nível mais alto.

Quando Utilizar Cartões CRC

          Utilize cartões CRC para explorar uma interação entre classes, tipicamente para mostrar como um cenário é implementado. Uma vez que você elaborou como a interação funciona, você pode documentá-la com diagramas de interação.

          Use responsabilidades para ajudá-lo a sumarizar as responsabilidades-chave de uma classe. Elas são úteis para enfatizar classes sobrecarregadas.

          Muitas pessoas salientam a importância de desenhar papéis; cada pessoa de uma equipe desempenha o papel de uma ou mais classes. Nunca vi Ward ou Kent fazerem isso, e acho que isso atrapalha.


Comparando Diagramas de Seqüência com Diagramas de Colaboração

        Você deve utilizar diagramas de interação quando quiser observar o comportamento de vários objetos dentro de um único caso de uso. Esses diagramas de interação são bons para mostrar as colaboraçãoes entre objetos; eles não são tão bons para uma definição precisa de comportamento.

        Se você quiser observar o comportamento de um simples objeto através de muitos casos de uso, use um diagrama de estados. Se você quer observar o comportamento através de muitos casos de uso ou de muitas trilhas de execução (treads), considere um diagrama de atividades.