Atenção: esse artigo tem uma palestra complementar. Clique e assista!

No oitavo artigo da série Utilizando a UML, apresentaremos mais três dos 13 diagramas descritos na especificação 2.0 da UML, completando assim a série de artigos que descreveu todos os diagramas da UML 2.0.

Em nosso último artigo, tratamos dos Diagramas de Interação Geral, Componentes e Pacotes indicados por muitos autores como método de especificação e documentação das etapas de modelagem de solução e implementação. No presente artigo, vamos tratar de três Diagramas bastante conhecidos na versão 2.0 da UML: os Diagramas de Implantação, Comunicação e Tempo.

Entre as versões 1.5 e 2.0 da UML, diversas alterações/evoluções foram realizadas. Os três diagramas que iremos abordar ao longo deste artigo são resultados nítidos de tal evolução da UML, como veremos a seguir.
O Diagrama de Implantação determina as necessidades de hardware do sistema, as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado. Os Diagramas de Componentes e de Implantação são bastante associados, podendo ser representados em separado ou em conjunto.

O Diagrama de Comunicação era conhecido como Diagrama de Colaboração até a versão 1.5 da UML, tendo seu nome modificado para Diagrama de Comunicação a partir da versão 2.0. Este Diagrama está amplamente associado ao Diagrama de Seqüência. Na verdade, um complementa o outro.

O Diagrama de Tempo é a fusão do Diagrama de Seqüência e Estado apresentando o comportamento dos objetos e sua interação em uma escala de tempo, ou seja, o estado dos objetos em relação ao tempo e às mensagens que modificam esse estado.

Estes três diagramas permitem na etapa análise e projeto modelar com bastante clareza os comportamentos e a implementação do modelo a ser desenvolvido. Neste artigo, vamos falar um pouco da definição, da sua utilização e principalmente dos aspectos de produtividade que fazem desses diagramas, importantes ferramentas na etapa de projeto e desenvolvimento.

O Diagrama de Implantação

O Diagrama de Implantação é o diagrama com a visão mais física da UML (GUEDES, 2007). Este diagrama foca a questão da organização da arquitetura física sobe a qual o software irá ser implantado e executado em termos de hardware, ou seja, as máquinas (computadores pessoais, servidores etc.) que suportam o sistema, além de definir como estas máquinas serão conectadas e por meio de quais protocolos se comunicarão e transmitirão as informações. Os elementos básicos deste diagrama são os Nós, que representam os componentes, Associações entre Nós, que são as ligações entre os Nós do diagrama, e os Artefatos, representações de entidades físicas do mundo real. Veremos cada um dos componentes que compõem o Diagrama de Implantação a seguir.

Nós

Nós são componentes fundamentais do Diagrama de Implantação. Um nó pode ilustrar um item de hardware, como um servidor em que um ou mais módulos do software são executados ou que armazene arquivos consultados pelos módulos do sistema, ou pode representar um ambiente de execução, ou seja, um ambiente que suporta o sistema de alguma forma.

Nós podem conter outros nós, sendo comum encontrar um nó que representa um item de hardware contendo outro nó que representa um ambiente de execução, embora nó que represente um item de hardware possa conter outros nós representando itens de hardware, e um nó que represente um ambiente de execução possa conter outros ambientes de execução.

Quando um nó representa um hardware, deve possuir o estereótipo <>; quando, porém, um nó representa um ambiente de execução, pode utilizar o estereótipo <>. A Figura 1 apresenta exemplo de utilização de nó para representar um item de hardware. Outros exemplos de ambientes de execução são os sistemas operacionais ou sistemas e banco de dados.

Os estereótipos são um dos três mecanismos de extensão da UML. Eles dão mais poder à UML, permitindo classificar elementos "com algo em comum" (Wikipédia).

Associação entre Nós

Os Nós possuem ligações físicas entre si de forma que possam se comunicar e trocar informações. Essas ligações são chamadas associações e são representadas por retas ligando um Nó a outro. Uma associação pode conter estereótipos utilizados para determinar, por exemplo, o tipo de protocolo e comunicação utilizado entre os nós (ver Figura 2).

A Figura 2 demonstra um exemplo de associação entre o Nó que representa o Servidor de Comunicação e o Nó que representa o Servidor de Firewall. O protocolo de comunicação é descrito na Associação como um estereótipo <<TCP/IP>>.

Figura 1. Exemplo de Nó (GUEDES, pg. 162, 2007)

Figura 2. Exemplo de associação entre Nós (GUEDES, pg. 162, 2007)

Figura 3. Exemplo de Diagrama de Implantação (adaptado Guedes, 2007)

Figura 4. Diagrama de Componentes do Sistema de Controle de Submissões (adaptado de GUEDES, 2007)

Exemplo de Diagrama de Implantação

Os Diagramas de Implantação são conhecidos, principalmente, pela sua simplicidade e facilidade de compreensão. Como facilitador, apresentaremos um exemplo de Diagrama de Implantação referente à arquitetura física necessária para suportar um Sistema de Controle de Submissões (ver Figura 3).

O exemplo apresentado na Figura 3 é o mesmo modelado na edição 67 da SQL Magazine. O sistema que estamos modelando representa um processo de submissão de artigos à edição de um periódico.

A Figura 3 demonstra as associações existentes entre os vários Nós, que representam cada um dos hardwares existentes na arquitetura de implantação do sistema. Através deste diagrama, notamos que a comunicação entre o Nó Hardware do Autor, equipamento utilizado pelo autor para desenvolver o artigo, e o Nó Servidor de Aplicação I, equipamento instalado do lado do servidor onde a aplicação Sistema de Controle de Submissões está instalada, passa pelos Nós Servidor de Comunicação, equipamento que garantirá a boa performance e zelará pela transmissão e recepção dos dados, e Servidor de Firewall, responsável pela proteção da arquitetura do sistema. Podemos notar que após a comunicação com o Nó Servidor de Aplicação I, há a comunicação com os Nós Servidor de Banco de Dados, onde ocorre a persistência e gestão dos dados do sistema, e o Nó Servidor de Aplicação II, que neste contexto representa um modelo de balanceamento ou de administração de sistemas de apoio, como por exemplo, ferramentas de controle administrativo.

Podemos obter também através da leitura deste diagrama (ver Figura 3) o Protocolo de comunicação adotado entre os vários Nós, representado pelo estereótipo <<TCP/IP>>.

A Figura 4 apresenta o Diagrama de Componentes (ler Nota DevMan 1) equivalente aos módulos executáveis do Sistema de Controle de Submissões que estamos modelando.

Alguns módulos não são exatamente executáveis, como é o caso do componente que representa a página de submissão de artigos, ou pertencem exclusivamente ao sistema, como o componente que representa o Sistema Gerenciador de Banco de Dados, mas são indispensáveis para o funcionamento do mesmo.

Figura 5. Exemplo de Artefato implementado em um Nó

Figura 6. Exemplo de Artefato manifestado a partir de um Componente

Podemos observar a utilização dos relacionamentos entre componentes por meio de Interfaces Fornecidas e Requeridas, onde podemos notar, por exemplo, que o componente Sistema de Gerenciamento de Banco de Dados é Interface Fornecida por outros oito componentes: Gerenciador de Login, Gerenciador de Submissões do Autor, Cadastro de Avaliadores, Cadastro de Temas, Gerenciador de Avaliações, Relatório de Avaliações, Notificação de Autor e Gerenciador de Submissões do Coordenador. O componente Página Eletrônica de Submissão de Artigos é o componente inicial deste diagrama. Percebemos isso porque é através dele que o Submissor tem o acesso a executar o componente Controlador de Submissões. O componente Controlador de Submissões é Interface Provida pelo componente Página Eletrônica de Submissão de Artigos, e Interface Requerida para os componentes Gerenciador de Login e Gerenciador de Submissões do Autor.

Artefatos

Um artefato é uma entidade física, um elemento concreto que existe realmente no mundo real, assim como os nós que o suportam. Um artefato pode ser um arquivo fonte, um arquivo executável, um arquivo de ajuda, um documento de texto etc. Um artefato deve estar implementado em um Nó. Na Figura 5 é apresentado um exemplo de Artefato implementado em um Nó.

Na Figura 5 podemos notar que o artefato denominado “Módulo Gerenciador de Login” possui a mesma denominação que um dos componentes apresentados na Figura 4. Na verdade, um artefato é muitas vezes uma “manifestação” no mundo real de um componente. No entanto, não necessariamente existirá um artefato de cada componente, sendo possível existirem diversos artefatos manifestados a partir de um único componente.

A Figura 6 demonstra um exemplo de artefato instanciado a partir de um componente. Observe que existe um relacionamento de dependência entre o componente e o artefato, contendo o estereótipo <<manifest>>, significando que o artefato é uma representação do componente do mundo real.

Figura 7. Artefato implementado em um Nó (adaptado de GUEDES, 2007)

Figura 8. Especificação de Implantação

Outra forma de manifestar um artefato contido em um Nó, segundo Guedes em seu livro UML - Guia Prático, é utilizar um relacionamento de dependência, contendo o estereótipo <> entre o nó e os artefatos (ver Figura 7).

Um Nó pode conter componentes da mesma forma que artefatos, como uma maneira de demonstrar em que lugar os componentes poderão ser localizados no hardware que suportará o sistema.

Especificação de Implantação

A Especificação de Implantação especifica um conjunto de propriedades que determinam parâmetros de execução de um artefato implementado em um Nó (ver Figura 8).

A Figura 8 demonstra a Especificação de Implantação do artefato Modulo.jar. O arquivo Módulo.xml é o conjunto de propriedade que descreve os parâmetros que o artefato Modulo.jar implementado na aplicação Sistema de Controle de Submissões.

Diagrama de Comunicação

O Diagrama de Comunicação era conhecido como Diagrama de Colaboração até a versão 1.5 da UML, tendo o seu nome modificado para Diagrama de Comunicação a partir da versão 2.0 da UML. Esse diagrama está amplamente associado ao diagrama de sequência - na verdade, um complementa o outro. As informações mostradas no Diagrama de Comunicação são, com frequência, praticamente as mesmas apresentadas no Diagrama de Sequência (ler Nota DevMan 2), porém com um enfoque diferente, visto que este diagrama não se preocupa com a ordem temporal dos processos, concentrando-se em como os objetos estão vinculados e quais mensagens trocam entre si durante o processo.

Figura 9. Exemplo de Mensagem entre componentes

Por ser muito semelhante ao Diagrama de Sequência, o Diagrama de Comunicação utiliza muitos de seus elementos, como atores e objetos, incluindo seus estereótipos de fronteira e controle. No entanto, os objetos no Diagrama de Comunicação não possuem linhas de vida. Além disso, esse diagrama não suporta ocorrências de interação ou fragmentos combinados como o Diagrama de Sequência, por isso é utilizado para a modelagem de processos mais simples.

Da mesma forma que o Diagrama de Sequência, um Diagrama de Comunicação enfoca um processo, normalmente baseado em um Caso de Uso. As semelhanças entre ambos são tão grandes que existem até mesmo ferramentas CASE capazes de gerar um dos diagramas a partir do outro.

Atores

Os atores são os mesmos descritos no Diagrama de Casos de Uso (ler Nota DevMan 3) e Diagrama de Sequência, ou seja, descreve entidades externas que interagem com o sistema, solicita serviços e gera, dessa forma, eventos que iniciam processos. Normalmente representa usuários que interagem com o sistema e outros softwares, como um sistema integrado ou um hardware específico. Atores são representados por bonecos magros idênticos aos usados no Diagrama de Casos de Uso.

Objetos

Os objetos representam as instâncias das classes que estão envolvidas no processo descrito pelo diagrama de sequência. Os objetos são representados com um retângulo contendo um texto que identifica primeiramente o nome do objeto, em minúsculo, e depois o nome da classe, com letras iniciais maiúsculas, a qual o objeto pertence. As duas informações são separadas por dois pontos (:).

Mensagens

Como comentamos, o Diagrama de Comunicação se preocupa com o relacionamento entre os objetos envolvidos em um processo, e isto é feito principalmente por meio de mensagens. Uma mensagem é causada por um evento e pode conter uma descrição, uma chamada de um método ou ambos. Mensagens podem ainda conter condições de guarda, bastante úteis neste diagrama.

Para que possa ser enviada uma mensagem de um componente é necessário haver uma associação entre os componentes. Após existir a associação, pode-se então acrescentar mensagens a ela. Uma mensagem se caracteriza por conter uma seta apontando ao objeto para o qual está sendo enviada (ver Figura 9).

O Controlador_Congresso, representado por um símbolo em forma de círculo com uma seta incluída, é uma Control Class (Classes de Controle geralmente são as classes que conectam as classes de interface às classes do domínio).

Autochamada

Um objeto pode disparar uma mensagem em si próprio, o que é conhecido como auto-chamada, onde a mensagem parte do objeto e retorna ao próprio objeto. A Figura 10 apresenta um exemplo de auto-chamada em um objeto.

A Figura 10 demonstra o envio de uma mensagem do objeto autor1 para si próprio, solicitando o disparo do método ValCpf() responsável pela validação do CPF. Esta instância da classe Autor está contida no processo de submissão de artigos como um método de validação da informação de CPF do autor do artigo.

Condições de Guarda e Iterações

Condições de Guarda são textos entre colchetes que estabelecem condições ou validações para que uma mensagem possa ser enviada. Já Iterações representam uma situação em que uma mensagem pode ser enviada várias vezes, correspondendo muitas vezes a um laço de repetição.

As iterações são representadas por um asterisco (*) na frente da mensagem e em geral vêm apoiadas por Condições de Guarda. Uma vez que o Diagrama de Comunicação não suporta fragmentos combinados, muitas vezes é necessário lançar mão desse artifício para representar situações opcionais ou laços. Um exemplo é apresentado na Figura 11.

Na Figura 11 observamos a utilização da Condição de Guarda e Iteração no processo de ordenação das submissões em relação à instância da classe Edicao. O processo se inicia com a validação das informações de acesso do Ator Editor_Chefe e em seguida pela execução do processo de ordenação. Esta Condição de Guarda e Iteração representa que para cada submissão uma ordem será definida e isso ocorre enquanto houver submissões a serem ordenadas.

Figura 10.Exemplo de Autochamada (adaptado de GUEDES, pg. 242, 2009)

Figura 11. Exemplo de Condição de Guarda e Iteração (adaptado de GUEDES, 2009)

O responsável por esta atividade é o método DefOrd(ord), recebe como parâmetro à ordem desta submissão dentro da edição, da classe Edicao estimulado/executado pela instancia da classe Editor.

Modelando Diagrama de Comunicação para o Sistema de Controle de Submissões

A partir de agora, iremos demonstrar a continuação da modelagem do Sistema de Controle de Submissões, citado anteriormente e descrito no artigo anterior desta série. Os diagramas seguintes correspondem aos mesmos processos apresentados na Figura 4, que demonstra o Diagrama de Componentes.

A Figura 12 demonstra o processo de Login do Submissor através do Diagrama de Comunicação. O processo de Login do Submissor é executado com o objetivo de validar suas informações de acesso, e em seguida executar a atividade de ordenação das submissões realizadas pelos autores dentro de uma edição.

Este processo inicia-se com a mensagem Informar login e senha na interface Pagina_Congresso que é validada pelo componente Controlador_Congresso que executa o método Login() da instância da classe Autor (objeto autor1).

A seguir, a Figura 13 demonstra o processo de Submissão de artigos, através do Diagrama de Comunicação. O processo apresentado no exemplo demonstra a validação das informações de acesso do responsável pela submissão no sistema.

Figura 12. Realizar Login (adaptado de GUEDES, pg. 113, 2007)

Figura 13. Realizar Submissão (adaptado de GUEDES, pg. 113, 2007)

O processo é iniciado pelo Ator Submissor que começa selecionando a opção de submissão na interface Pagina_Congresso. Em seguida, ele seleciona o tema e informa os dados de submissão. Através das informações transmitidas pelo Ator à Interface, o componente Controlador_Congresso recebe de Pagina_Congresso a solicitação de submissão (mensagem Submissão solicitada), a informação de tema (mensagem Tema) e a confirmação de submissão (mensagem Submissão confirmada). Após receber as mensagens enviadas ao componente Controlador_Congresso, este realiza um processo executado sobre a Condição de Guarda Para cada tema, que para cada tema executará o método SelTema() do objeto da classe Tema. Em seguida o componente Controlador_Congresso executa o método SelTema() do objeto da classe Tema e o método RegSub() do objeto sub1 da classe Submissao, responsável pelo registro da submissão.

Continuando, a Figura 14 demonstra o processo de verificação de submissões de artigos também. Para cada submissão é realizada uma verificação através do componente Controlador­_Congresso.

A Figura 15 demonstra o processo de verificação de comentários de um artigo. Para cada submissão é realizada uma avaliação através do componente Controlador­_Congresso que executa o método SelAval()do objeto da classe Avaliacao. Neste exemplo há duas Condições de Guarda. A primeira Condição de Guarda restringe que para cada avaliação será executado uma vez o método SelAval() da classe Avaliacao. A segunda Condição de Guarda possui comportamento semelhante, porém a restrição se refere a um comentário sobre uma avaliação realizada.

Figura 14. Verificar Submissões (adaptado de GUEDES, pg. 114, 2007)

Figura 15. Verificar Comentários (adaptado de GUEDES, pg. 114, 2007)

A Figura 16 apresenta o processo que permite a manutenção, modificação, das informações relacionadas às avaliações e comentários em relação a uma submissão. Este processo complementa aspectos apresentados no processo descrito na Figura 15.

A Figura 17 demonstra o processo de manutenção de comentários que podem ser feitos durante o processo de avaliação de um artigo. O processo é iniciado pelo Avaliador que poderá ao longo do processo criar um novo comentário, alterar, selecionar e excluir a qualquer momento um comentário. As Condições de Guarda do início do Diagrama de Comunicação irão determinar o fluxo de mensagens.

O exemplo apresentado na Figura 18 demonstra o processo de emissão de relatórios no Sistema de Controle de Submissões. Neste diagrama, o estímulo inicial que parte do Ator Coordenador que seleciona a opção Relatório de Avaliações e o Tema e Tipo de Submissão desejada. Para cada Submissão, seleciona-se o Tema, o conteúdo submetido e a avaliação desta submissão.

Diagrama de Tempo ou de Temporização

Esse diagrama apresenta algumas semelhanças com o Diagrama de Máquinas de Estados. No entanto, ele enfoca as mudanças de estado de um objeto ao longo do tempo. Esse diagrama terá pouca utilidade, segundo Guedes, em seu livro UML - Uma Abordagem Prática, para modelar aplicações comerciais, contudo, poderá ser utilizado na modelagem de sistemas de tempo real ou sistemas que utilizem recursos de multimídia/hipermídia, onde o tempo em que o objeto é executado algo é muitas vezes importante.

Figura 16. Manter Avaliações (adaptado de GUEDES, pg. 114, 2007)

Figura 17. Manter Comentários (adaptado de GUEDES, pg. 114, 2007)

Figura 18. Relatório de Avaliações (adaptado de GUEDES, pg. 114, 2007)

Em um sistema, por exemplo, de concurso público, há uma sequência lógica de etapas que necessita ser executada. Não se pode “Aplicar prova de seleção” sem antes “Elaborar Edital de Concurso”. O exemplo do processo de concurso (ver Figura 19) descreve a mudança no estado ou condição da instância de “Concurso” durante o tempo de existência da instância. Tipicamente os Diagramas de Tempo demonstram mudanças no estado de um objeto no tempo em repostas a eventos externos. Cada etapa ou estado do objeto da classe “Concurso” é apresentada por meio de um hexágono, sendo que o primeiro e o último estado se encontram abertos. Abaixo de cada etapa, entre barras verticais, se encontram as restrições de duração que determinam o tempo em que transcorrem as etapas. No caso do estado “Abrindo Inscrições”, o período vai de 05 de janeiro a 31 de janeiro.

É muito importante destacar que o Diagrama de Tempo tem duas notações ou formas de representação: uma notação conhecida como concisa, mais simples (conforme foi usado na Figura 19), chamada de linha de vida de valor, e uma notação considerada mais robusta, onde as etapas são apresentadas em uma forma semelhante a um gráfico (ver Figura 20), chamada linha de vida de estado. No Diagrama de Tempo, o termo linha de vida (lifeline) refere-se ao caminho percorrido por um objeto durante um determinado tempo.

A Figura 20 demonstra o mesmo diagrama da Figura 19, dessa vez utilizando a forma robusta e linha de vida de estado, onde as transições de estado são determinadas por mudanças em um gráfico, podendo estas conter descrições que determinam o evento que causou a mudança, se isso for considerado necessário. Um Diagrama de Tempo pode ter linhas de vida de múltiplos objetos, utilizando a mesma notação ou notações diferentes.

Figura 19. Diagrama de Tempo - Forma concisa

Figura 20. Diagrama de Tempo - Forma considerada mais robusta

Conclusão

Este foi o último artigo da série Utilizando UML. No decorrer destes 8 artigos pudemos com bastante detalhe conhecer cada um dos 13 diagramas da UML 2.0. A Modelagem através da UML adotada em processos de desenvolvimento representa uma das boas práticas da programação e manutenção de softwares. Até a próxima, sucesso e bons estudos!