Introdução

Na maioria dos casos, utilizamos um diagrama de seqüência para ilustrar realizações de casos de uso (consulte Produto de Trabalho: Realizações do Caso de Uso), isto é, para mostrar como os objetos interagem para executar o comportamento de todo ou parte de um caso de uso. Um ou mais diagramas de seqüência podem ilustrar as interações de objetos que constituem um caso de uso. Uma organização típica deve ter um diagrama de seqüência para o fluxo principal de eventos e um diagrama de seqüência para cada subfluxo independente do caso de uso.

Os diagramas de seqüência são muito importantes para designers porque eles esclarecem os papéis dos objetos em um fluxo e, portanto, fornecem entrada básica para determinar responsabilidades de classe e interfaces.

Diferente de um diagrama de comunicação, um diagrama de seqüência inclui seqüências cronológicas, mas não inclui relacionamentos de objetos. Os diagramas de seqüência e os diagramas de comunicação expressam informações semelhantes, mas as mostram de maneiras diferentes. Os diagramas de seqüência mostram a seqüência explícita de mensagens e são melhores quando é importante visualizar a ordenação temporal das mensagens. Quando você estiver interessado nos relacionamentos estruturais entre as instâncias de uma interação, utilize um diagrama de comunicação. Consulte Técnica: Diagrama de Comunicação para obter mais informações.

Conteúdo dos Diagramas de Seqüência

Você pode ter objetos e instâncias de agente em diagramas de seqüência, juntamente com mensagens que descrevem como eles interagem. O diagrama descreve o que ocorre nos objetos participantes, em termos de ativações, e como os objetos se comunicam enviando mensagens uns aos outros. É possível fazer um diagrama de seqüência para cada variante do fluxo de eventos de um caso de uso.

Um diagrama de seqüência que descreve parte do fluxo de eventos do caso de uso Fazer Chamada Local em um Comutador de Telefone Simples.

Objetos

Um objeto é mostrado como uma linha tracejada vertical denominada "linha de vida". A linha de vida representa a existência do objeto em um momento específico. Um símbolo de objeto foi desenhado no alto da linha de vida e mostra o nome do objeto e sua classe sublinhada e separada por dois-pontos:

objectname : classname

Você pode usar objetos em diagramas de seqüência das seguintes formas:

• Uma linha de vida pode representar um objeto ou sua classe. Portanto, a linha de vida pode ser usada para modelar tanto o comportamento da classe quanto do objeto. Contudo, em geral, uma linha de vida representa todos os objetos de uma determinada classe.
• Uma classe de objeto pode não estar especificada. Geralmente, você cria primeiro um diagrama de seqüência com objetos e mais tarde especifica as suas classes.
• Os objetos podem não ter nome, mas é recomendável nomeá-los se você quiser diferenciar os diversos objetos da mesma classe.
• Várias linhas de vida no mesmo diagrama podem representar objetos diferentes da mesma classe; mas, como foi dito anteriormente, os objetos devem ser nomeados para que você possa estabelecer a diferença entre os dois objetos.
• Uma linha de vida que representa uma classe pode existir paralelamente a linhas de vida que representam objetos daquela classe. O nome do objeto da linha de vida que representa a classe pode ser definido com o nome da classe.

Agentes

Geralmente, uma instância de agente é representada pela primeira (mais à esquerda) linha de vida no diagrama de seqüência, como o disparador da interação. Se houver várias instâncias de atores no mesmo diagrama, tente mantê-las na linha de vida mais à esquerda ou na linha mais à direita.

Mensagens

Uma mensagem é uma comunicação entre objetos que leva informações na expectativa de que resulte uma atividade; nos diagramas de seqüência, uma mensagem é mostrada como uma seta sólida horizontal partindo da linha de vida de um objeto para a linha de vida de outro objeto. No caso de uma mensagem de um objeto para si mesmo, a seta pode iniciar e terminar na mesma linha de vida. A seta é rotulada com o nome da mensagem e seus parâmetros. Ela também pode ser rotulada com um número que indique a seqüência da mensagem no processo geral de interação. Os números seqüenciais em geral são omitidos em diagramas de seqüência, nos quais a localização física da seta mostra a seqüência relativa.

Uma mensagem pode ser não-atribuída, o que significa que seu nome é uma seqüência de caracteres temporária que descreve o sentido geral da mensagem e não é o nome de uma operação do objeto recebedor. Mais tarde, você poderá atribuir a mensagem especificando a operação do objeto de destino da mensagem. A operação especificada substituirá então o nome da mensagem.

Scripts

Os scripts descrevem o fluxo de eventos textualmente em um diagrama de seqüência.

Você deve posicionar os scripts à esquerda das linhas de vida para poder ler o fluxo completo de cima para baixo (consulte a figura acima). Você pode anexar scripts a uma determinada mensagem assegurando, assim, que o script se mova com a mensagem.

Distribuindo Fluxo de Controle no Diagrama de Seqüência

O controle centralizado de um fluxo de eventos, ou parte dele, significa que poucos objetos guiam o fluxo enviando mensagens para, e recebendo mensagens de, outros objetos. Esses objetos controladores decidem a ordem em que outros objetos serão ativados no caso de uso. A interação entre os objetos restantes é mínima ou inexistente.

Exemplo

No Sistema de Máquina de Reciclagem, o caso de uso Imprimir Relatório Diário controla, entre outros, o número e o tipo de objetos retornados e escreve a contagem em um recibo. O objeto de controle Gerador de Relatórios decide a ordem em que as somas serão extraídas e gravadas.

A estrutura de comportamento do caso de uso Imprimir Relatório Diário é centralizada no objeto de controle Gerador de Relatório.

Esse é um exemplo de comportamento centralizado. A estrutura de controle é centralizada principalmente porque as diferentes fases de subeventos do fluxo de eventos não dependem umas das outras. A principal vantagem desse método é que cada objeto não precisa controlar a contagem do objeto seguinte. Para mudar a ordem das fases de subeventos, basta fazer a mudança no objeto de controle. Ainda será possível adicionar facilmente outra fase de subevento se, por exemplo, for incluído um novo tipo de item retornável. Outra vantagem dessa estrutura é que você pode facilmente reutilizar as várias fases de subeventos em outros casos de uso, porque a ordem de comportamento não está embutida nos objetos.

O Controle Descentralizado surge quando os objetos participantes se comunicam diretamente entre si, e não através de um ou mais objetos controladores.

Exemplo

No caso de uso Enviar Carta, alguém remete uma carta para outro país através de uma agência de correio. Primeiro, a carta é enviada para o país do destinatário. No país, a carta é enviada para uma cidade específica. A cidade, por sua vez, envia a carta para a residência do destinatário.

A estrutura de comportamento do caso de uso Enviar Carta é descentralizada.

O comportamento do caso de uso é um fluxo de eventos descentralizado. As fases de subeventos integram o conjunto. O emissor da carta fala de "enviar uma carta a alguém". Ele não precisa nem deseja saber os detalhes de como as cartas são redirecionadas em países ou cidades. (Provavelmente, se alguém remetesse uma carta dentro do mesmo país, nem todas as ações ocorreriam.)

O tipo de controle usado depende do aplicativo. Geralmente, você deve tentar conseguir objetos independentes, isto é, delegar várias tarefas aos objetos naturalmente mais apropriados a executá-las.

Um fluxo de eventos com controle centralizado terá um diagrama de seqüência em forma de "forquilha". Por outro lado, um diagrama de seqüência em "forma de escada" ilustra que a estrutura de controle foi descentralizada para os objetos participantes.

Uma estrutura de controle centralizada em um fluxo de eventos produz um diagrama de seqüência em forma de "forquilha". Uma estrutura de controle descentralizado produz um diagrama de seqüência em "forma de escada".

A estrutura de comportamento da realização de um caso de uso freqüentemente consistem em uma mistura de comportamento centralizado e descentralizado.

Uma estrutura descentralizada será adequada:

• Se as fases de subevento estiverem intrinsecamente acopladas. Esse será o caso se os objetos participantes:
  • Formarem uma hierarquia de partes ou constituintes, como País - Estado - Cidade;
  • Formarem uma hierarquia de informações, como CEO - Gerente de Divisão - Gerente de Seção;
  • Representarem uma progressão cronológica fixa (a seqüência de fases de subeventos será sempre realizada na mesma ordem), como Anúncio - Pedido - Fatura -Remessa - Pagamento; ou
  • Formarem uma hierarquia de herança conceitual, como Animal - Mamífero - Gato.
• Se você desejar encapsular a funcionalidade e, portanto, fazer abstrações dela. Isso é bom para alguém que deseje utilizar sempre a funcionalidade inteira, porque a funcionalidade pode se tornar desnecessariamente de difícil compreensão caso a estrutura de comportamento seja centralizada.

Uma estrutura centralizada será adequada:

• Se a ordem em que as fases de subeventos serão executadas puder ser mudada.
• Se você espera inserir novas fases de subeventos.
• Se você deseja manter partes da funcionalidade reutilizáveis como peças separadas.