Este é um diagrama comportamental que procura determinar a sequência de eventos que ocorrem em um determinado processo, identificando quais mensagens devem ser disparadas entre os elementos envolvidos e em que ordem. Assim, determinar a ordem em que os eventos ocorrem, as mensagens que são enviadas, os métodos que são chamados e como os objetos interagem dentro de um determinado processo é o objetivo principal desse diagrama.
O diagrama de sequência baseia-se no diagrama de casos de uso, havendo normalmente um diagrama de sequência para cada caso de uso declarado, uma vez que um caso de uso, em geral, refere-se a um processo disparado por um ator. Assim, um diagrama de sequência também permite documentar um caso de uso específico, sendo que muitas ferramentas CASE permitem gerar um diagrama de sequência diretamente a partir de um caso de uso.
Obviamente, o diagrama de sequência depende também do diagrama de classes, já que as classes dos objetos utilizados no diagrama de sequência estão descritas nele. No entanto, o diagrama de sequência é uma excelente forma de validar e complementar o diagrama de classes, pois é ao modelar um diagrama de sequência que se percebe quais métodos são necessários declarar em que classe.
Isto é. inclusive, o que é recomendado fazer em alguns processos de desenvolvimento de software, como o Processo Unificado, no qual, como já foi dito anteriormente, primeiramente produz-se o modelo conceitual, durante a fase de análise, e só mais tarde, durante a fase de projeto, produz-se o modelo de domínio, onde serão detalhados os métodos das classes.
A descoberta desses métodos é feita por meio do detalhamento dos processos enunciados no diagrama de casos de uso, por meio de diagramas de interação, como os de sequência, embora estes possam também ser utilizados na fase de análise, como será demonstrado ao longo deste capítulo.
7.1 Atores Prática interdisciplinar em Os atores modelados neste diagrama são instâncias dos atores declarados no diagrama de casos de uso, representando entidades externas que interagem com o sistema e que solicitam serviços, gerando, assim, eventos que iniciam processos. Esses atores costumam ser apresentados como bonecos magros idênticos aos usados no diagrama de casos de uso, porém, contendo uma linha de vida. O conceito de linha de vida será explicado nas seções seguintes. A figura 7.1 ilustra um exemplo de como é representado um ator no diagrama de sequência.
A figura 7.1 representa um cliente que interage com o sistema ou com outro ator envolvido no processo. Os atores não são realmente obrigatórios nesse diagrama, mas são utilizados com muita frequência. Além disso, como a maioria dos diagramas de sequência, senão todos, refletem o aspecto dinâmico de um caso de uso, a utilização dos mesmos atores que interagem com o caso de uso em questão, facilita a compreensão do processo.
7.2 lifelines Prática interdisciplinar em Um lifeline é um participante individual em uma interação. Na maioria das vezes um lifeline irá se referir a uma instância de uma classe que participa de uma interação. Para não confundir com a linha que determina o tempo em que um participante existe no diagrama, iremos manter essa terminologia em inglês.
Lifelines no diagrama de sequência têm a mesma notação utilizada no diagrama de objetos, diferenciando-se por uma linha de vida, representada por uma linha vertical tracejada abaixo do participante. Como na prática, em geral um lifeline é um objeto, iremos utilizar o termo objeto com frequência ao longo do capítulo. A figura 7.2 apresenta um exemplo de lifeline no diagrama de sequência.
Como é possível perceber ao observarmos a figura 7.2, existe um lifeline chamado pesfis1, e esse lifeline é uma instância da classe Pessoa_Fisica. A linha tracejada vertical que surge a partir do objeto representa a linha de vida do mesmo.
Um lifeline pode existir desde o início do processo ou ser criado durante o decorrer da execução do mesmo. No primeiro caso, o retângulo que representa o lifeline aparecerá na parte superior do diagrama. Já no segundo caso, o retângulo surgirá na mesma altura em que a mensagem que o criar for chamada. A figura 7.3 apresenta um exemplo de lifelines ativos desde o inicio do processo e lifelines criados no decorrer do mesmo.
Na figura 7.3 utilizamos o componente notas para destacar a existência de dois lifelines no diagrama, pesfis1 e comum1, esse último pertencente à classe Conta_Comum. Ao estudarmos a figura verificamos que o objeto (lifeline) pesfis1 esteve ativo desde o início do processo. Já o objeto (lifeline) comum1 foi instanciado ao longo do processo.
Observe que há mais duas instâncias de objetos no diagrama, cujos nomes não foram definidos, que se referem respectivamente à classe Interface_Banco, uma classe de fronteira e à classe Controlador_Banco, uma classe de controle. Além disso, existem dois atores interagindo nesse processo, os atores Cliente e Funcionário. Outros detalhes deste diagrama serão explanados ao longo deste capítulo.
7.3 linha de Vida A linha de vida representa o tempo em que um objeto (Iifeline) existe durante um processo. As linhas de vida são representadas por linhas finas verticais tracejadas, partindo do retângulo que representa o objeto. A linha de vida é interrompida com um "X" quando o objeto é destruído.
Um objeto não precisa necessariamente existir quando o processo é iniciado, podendo ser criado ao longo do mesmo. Assim, os objetos criados não são representados no topo do diagrama, mas só a partir do momento em que forem criados, como no exemplo da figura 7.3, e obviamente só terão uma linha de vida a partir desse mesmo momento.
7.4 Foco de Controle ou Ativação Indica os períodos em que um determinado objeto está participando ativamente do processo, ou seja, identifica os momentos em que um objeto está executando um ou mais métodos utilizados em um processo específico. Os focos de controle são representados dentro da linha de vida de um objeto, porém, enquanto as linhas de vida são representadas por tracejados finos, o foco de controle é representado por uma linha mais grossa. A figura 7.4 apresenta um exemplo de linha de vida e foco de controle.
Nessa figura novamente utilizamos o componente notas, dessa vez para identificar a linha de vida e o foco de controle de um objeto do diagrama. Ao observarmos a figura 7.4, podemos perceber, por intermédio da linha de vida (linha vertical tracejada fina que parte do objeto), que o objeto pesfis1 esteve presente durante todo o processo de abertura de conta, mas ele só participou ativamente do processo quando do disparo do método concpf, quando a linha de vida tornou-se mais grossa, indicando que o foco de controle do processo estava sobre o objeto pesfis1.
7.5 Mensagens ou Estímulos As mensagens são utilizadas para demonstrar a ocorrência de eventos, que normalmente forçam a chamada de um método em algum dos objetos envolvidos no processo. Pode ocorrer, no entanto, de uma mensagem representar a comunicação entre: dois atores, nesse caso, não disparando métodos. Um diagrama de sequencia em geral é iniciado por um evento externo, causado por algum ator, o que acarreta o disparo de um método em um dos objetos.
As mensagens podem ser disparadas entre: um ator e outro ator; um ator e um objeto, onde um ator produz um evento que dispara um método em um objeto;
um objeto e outro objeto, o que constitui a ocorrência mais comum de mensagens, onde um objeto transmite uma mensagem para outro, em geral solicitando a execução de um método. Um objeto pode inclusive enviar uma mensagem para si mesmo, disparando um método em si próprio, o que é conhecido como autochamada;
um objeto e um ator, o que normalmente ocorre quando um objeto envia uma mensagem de retorno em resposta à chamada de um método solicitado, contendo seus resultados.
As mensagens são representadas por linhas entre dois componentes, contendo setas indicando qual componente enviou a mensagem e qual a recebeu. As mensagens são apresentadas na posição horizontal entre as linhas de vida dos componentes e sua ordem sequencial é demonstrada de cima para baixo.
Os textos contidos nas mensagens primeiramente identificam qual evento ocorreu e forçou o envio da mensagem e qual método foi chamado. As duas informações são separadas por um símbolo de dois pontos (:). Podem ocorrer eventos que não disparam métodos. Nesse caso, a mensagem descreve apenas o evento que ocorreu, sem o símbolo de dois pontos e nenhum texto após os mesmos. Também pode acontecer de somente o método chamado ser descrito, sem detalhar qual evento o causou.
A figura 7.5 apresenta um exemplo de mensagem disparada entre atores, representando uma conversação entre os mesmos e que, portanto, não gera o disparo de nenhum método. Já a figura 7.6 mostra um exemplo de uma mensagem enviada por um objeto que dispara um método em outro.
Ao compararmos as duas figuras, percebemos que a mensagem da figura 7.5 descreve simplesmente o evento em si, enquanto a da figura 7.6 descreve o evento e, após os dois pontos, o método que foi disparado por ele. Logicamente, tais métodos podem conter parâmetros e retomar valores. No entanto, deve-se evitar colocar muitos detalhes nas chamadas dos métodos para impedir que o diagrama de sequência torne-se muito extenso.
Quando a mensagem é dirigida a um objeto já existente, a seta da mensagem atinge a linha de vida do objeto, engrossando-a, identificando que o foco de controle está sobre o objeto em questão. No entanto, quando a mensagem cria um novo objeto, a seta atinge o retângulo que representa o objeto, indicando que a mensagem representa um método construtor e que o objeto passa a existir somente a partir daquele momento. A figura 7.7 apresenta um exemplo de mensagem que provoca a criação de um novo objeto.
Nesse exemplo, o objeto da classe Contralador_Banco dispara o método abrir_conta no objeto comum1 da classe Conta_Comum, instanciando esse objeto a partir desse momento. Uma mensagem pode também representar um método destrutor, ou seja, um mérodo que elimina um objeto não mais necessário. Nesse caso a mensagrm atinge a linha de vida de um objeto e a interrompe com um X. A figura 7.8 apresenta um exemplo de chamada de método destrutor.
Nesse exemplo, existe um objeto car1 pertencente a uma classe Carrinho, que representa um carrinho de compras, como os encontrados nas livrarias digitais da internet e que pode ter muitos itens, representados pelos objetos da classe Item_Carrinho. Se em algum momento o cliente resolver cancelar a compra de algum dos itens do carrinho, o objeto da classe Carrinho deverá disparar um método destrutor no objeto da classe Item_Carrinho, aqui representado pelo método Excluir.