Diretrizes: Diagrama de Seqüência
|
Diagrama de Seqüência
|
Um diagrama de seqüência descreve um padrão de interação entre objetos, organizado em ordem cronológica; ele mostra os objetos que participam na interação pelas suas "linhas de vida" e as mensagens que um envia ao outro. |
Tópicos
Na maioria dos casos, usamos um diagrama de seqüência para ilustrar as realizações de casos de uso (consulte Artefato: Realizações de Casos de Uso), isto é, para mostrar como os objetos interagem para executar o comportamento total ou parcial 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.
Diferentemente de um diagrama de colaboração, um diagrama de seqüência inclui seqüências, mas não inclui relacionamentos de objetos. Ambos expressam informações semelhantes; o que muda é a forma como elas são mostradas. 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, use um diagrama de colaboração. Consulte Diretrizes: Diagrama de Colaboração para obter mais informações.
Você pode ter objetos e instâncias de ator 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 Colocar Ligação Local em uma Central Telefônica simples.
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.
Geralmente, uma instância de ator é 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.
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.
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.
O controle centralizado de um fluxo de eventos ou de parte do fluxo de eventos significa que poucos objetos guiam o fluxo trocando mensagens com 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 da 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ório decide a ordem em que os totais serão extraídos e escritos.
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 remetente da carta fala em "enviar uma carta a alguém". Ele não precisa nem deseja saber os detalhes de como as cartas são enviadas 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 descentralizada 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.
Copyright © 1987 - 2001 Rational Software Corporation
| 
Artefatos > 
Conjunto de Artefatos de Análise e Design > 
Modelo de Design... > 
Modelo de Design > 
Diretrizes > 
