Cadastre-se Revistas DevMedia Cursos
 

Space de Paulo César Barreto da Silva
Busca Autor


Últimas 20 atualizações de Paulo César Barreto da Silva

Artigo - Artigo SQL Magazine 68 - Utilizando UML: Diagramas de Implantação, Comunicação e TempoArtigo SQL Magazine 68 - Utilizando UML: Diagramas de Implantação, Comunicação e Tempo

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
25/03/2010 13:24:00





 

Graduado em Análise de Sistemas pelo Centro Universitário Salesiano de São Paulo e Pós graduado pela Universidade Estadual de Campinas na área de Orientação a Objetos.
Arquivo de atualizações
 2010

Estatísticas do Autor:
Número de posts: 9
Características dos posts deste autor:
Conteúdo:
Utilidade:
3 0
 
DevMedia Group - Tel: (21) 3382-5038 - www.devmedia.com.br
Todos os Direitos Reservados a DevMedia Group