UML - Diagrama de Componentes

Diagrama de Componentes

• O que é um Diagrama de Componentes?

O diagrama de componentes é um dos diagramas descritos no padrão UML (Unified Modeling Language) que possui ferramentas para ajudar a organizar o projeto de software de forma que fique melhor para visualizar os módulos e suas integrações ao longo do andamento e do seu desenvolvimento.

O diagrama de componentes é um gráfico (desenho) que modela os componentes do projeto, conectando-os por relacionamentos de dependência, ou seja, se um componente depender do outro, serão ligados por uma seta apontada para o que é dependente.

A finalidade do diagrama de componentes é definir os módulos físicos do software e seus relacionamentos uns com os outros. Isso oferece um meio de definir o software como um conjunto de unidades modulares e intercambiáveis, que podem ser montadas para criar unidades sucessivamente maiores, modulares e intercambiáveis.

Componente é o código ou documento do projeto que possui forma independente, podendo ser: um executável (programa), uma biblioteca (de classes ou funções), uma base de dados (tabela) ou outro arquivo do sistema.

O símbolo do componente é um retângulo com dois pequenos retângulos do lado esquerdo, o nome é escrito dentro ou abaixo do retângulo maior, ou ainda dentro de um retângulo com nome e símbolo dentro. Para determinar o tipo de componente, usa-se estereótipos.

Modelos de Icone de Componentes Versão UML 1.4 (esquerda) e versão UML 2.0 (direita

Estereótipo é uma maneira de destacar determinados componentes do diagrama, tornando explícito que tais componentes executam alguma função um pouco diferente dos demais componentes apresentados no diagrama, ou seja, é o tipo do componente.

A UML prevê diversos estereótipos prontos para o Diagrama de Componentes, tais como:

• Executável (executable) – Este estereótipo determina que o componente em questão é um arquivo executável, ou seja, um arquivo já compilado e link-editado em linguagem de máquina que pode executar uma série de instruções
• Biblioteca (library)- Este estereótipo refere-se a bibliotecas contendo funções e sub-rotina que podem ser compartilhadas por diversos componentes executáveis, podendo esta ser fornecidas pela própria linguagem em que o sistema será desenvolvido ou ser criadas pelos próprios desenvolvedores do sistema.
• Tabela (table) – Este estereótipo refere-se a repositórios físicos de dados onde os registros produzidos pelo sistema deverão ser armazenados.
• Documento (document) – Este estereótipo faz referência a arquivo texto utilizado por outros componentes do sistema, como por exemplo, arquivo de ajuda (help).
• Arquivo (file) – Este estereótipo pode ser referir a qualquer outro arquivo que componha o sistema, como arquivos de código-fonte dos módulos do sistema, por exemplo.

O usuário também pode criar seus próprios estereótipos como por exemplo um componente seja a representação de Classes Entidades com atributos em comum, que pode ser definida pelo esterótipos <<Entity>>.

• Representação de Componentes com Esteriótipos

Artefatos

Artefato é qualquer tipo de código que implementa o componente. Os artefatos podem ser qualquer tipo de código fonte que pode residir em qualquer tipo de memória – código – fonte, arquivos primários, scripts, arquivos executáveis, banco de dados ou aplicações.

Os artefatos são agrupados em três categorias:

• Componentes de implementação , que precisam executar o sistema. Alguns exemplos incluem sistemas operacionais, Java Virtual Machines (JVM) e Database Management Systems (DBMS).

• Componentes de produto de trabalho: diagramas da UML, arquivos de classe Java e Jar, bibliotecas de vínculo dinâmico (DDLs) e tabelas de banco de dados.

• Componentes de execução: Enterprise Java Beans, Servlets, documentos HTML e XML, componentes COM+ e .NET, e componentes CORBA.

Os artefatos são representados com um retângulo com o esteriótipo e o nome dentro deste retângulo, como mostra a figura abaixo:

Dependência

Como os componentes dificilmente são isolados no diagrama, eles são interligados uns com os outros, indicando dependencia, ou seja, cada um por si só não existe. E a seta de ligação, vai do dependente ao independente.

Exemplo de dependência entre componentes:

No exemplo acima, temos um programa (componente) que depende de outros arquivos (componentes também).

Porém um componente, pode se transformar em outro, assim, usamos o estereotipo <<Become>> acima da seta tracejada. Exemplo:

Nesse exemplo, tudo que é digitado no programa, é transformado em um arquivo de texto.

Existe um terceiro tipo de Dependência, que é quando o componente contém classes dentro dele.

É representado com o estereotipo <<reside>> acima da seta tracejada ou com essas classes dentro do componente (abaixo do nome).

Exemplo de um projeto com as dependências entre os componentes:

Interface

No padrão UML 1.4 a Interface de Componentes representa uma serviço realizado por uma Classe ou Componente, enão possui qualquer especificação interna, pois são representadas por um pequeno circulo chamado de lollipop (pirulito).

A Interface de Componente pode ser modelada (representada) de duas maneiras:

• A primeira é usando uma classe, com o estereótipo <<interface>>, anexado ao componente com uma seta de realização. A seta de realização se parece com o símbolo de generalização, mas com uma linha tracejada em vez de uma linha sólida. Realizar a interface significa implementa-la como parte do componente.

• • Exemplo – Um componente Programação Produção incorpora a interface para exibir um gráfico de Evolução de Produção. Ou seja mostra a evolução das Ordem de Produção executadas. Para isso ele usa uma Classe (Exibir Gráfico) definica dentro do mesmo. O componente deve conter os dados necessários para dá suporte a interface.

Modelos de Interface com usando uma classe e estereótipo

• Na segunda técnica, mais comum, é usar um "lollipop" anexado ao componente com uma linha sólida.A especificação UML mostra um círculo muito pequeno no final do lollipop. A interface implementada por um componente é, na realidade, definida pelas classes dentro do componente. Assim, a interface já deverá ter sido definida nos seus diagramas de classes. Além disso, um componente pode implementar tantas interfaces quantas forem necessárias

• • Exemplo:O componente Save_Gamer representa o conjunto de arquivos de salvamento da fase do jogador no Game_Legal, que possui uma interface de “Fase do jogador” definida pelo lollipop no diagrama. Esta interface é utilizada pelo componente Game_Legal (arquivo executável) do jogo para iniciar o usuário na ultima fase escolhida do jogo.

Modelos de Interface usando o lollipop

Projetos

Em relação aos projetos apresentados pela turma, qual deles entende que pode ser representado por um Diagrama de Objetos?

• Entre os projetos analisados todos poderiam poderiam serem representados por um Diagrama de Componentes, no entanto, alguns não estãvam com o Diagrams de Classes e Uso definidos. Resolvemos utilizar o projeto Automação Residência da Equipe DOMUS.

Desenhe do Diagrama para este grupo:

Analisando o Diagrama de Classes de o Diagrama de Caso e Usos chegamos a um modelo arquitetônico do software e sua integração com o hardware, onde identificamos superficialmente 10 componentes dos quais um com uma classe residente dentro do mesmo. Identificamos também 05 interfaces entre os componente e várias dependências.

• • Diagrama de Componentes do Projeto "Automação Residencial" do Grupo Domus

Referências

• PENDER, TOM. UML a Bíblia. Rio de Janeiro: Editora Campus, 2004.
• ROGER, S. Presmman. Engenharia de Software. 6ª Ed. São Paulo: McGraw-Hill, 2006.
• GUEDES, Gilleanes T. A., UML Uma Abordagem Prática. 3ª Ed. São Paulo: Novatec Editora, 2008.
• Notação ABNT