Projeto
Utilizando UML: Diagramas de Implantação, Comunicação e
Tempo
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 Implantançã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
<<device>>; quando, porém, um nó representa um ambiente de
execução, pode utilizar o estereótipo
<<ExecutionEnvironment>>. 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).
Figura 1. Exemplo de Nó (GUEDES, pg. 162, 2007).
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).
Figura 2. Exemplo de associação entre Nós (GUEDES, pg. 162, 2007).
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>>.
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.
Figura 3. Exemplo de Diagrama de Implantação (adaptado Guedes, 2007).
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.
Nota DevMan 1. Diagrama de Componentes
Na edição 67 da SQL Magazine, apresentamos o Diagrama de Componentes. O
Diagrama de Componentes, como o próprio nome sugere, apresenta a
identificação dos componentes que compõem um sistema, subsistema ou
mesmo componentes ou classes internas de um componente individual. Para
maiores detalhes, leia os artigos anteriores da série Utilizando UML.
Figura 4. Diagrama de Componentes do Sistema de Controle de Submissões
(adaptado de GUEDES, 2007).
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ó.
Figura 5. 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 6. Exemplo de Artefato manifestado a partir de um Componente.
Outra forma de m
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|