Definição

O segmento de mercado e a literatura de software utilizam o termo "componente" para referir-se a muitas coisas diferentes. Geralmente, ele é utilizado no sentido geral para significar "uma peça constituinte". Também é freqüentemente utilizado em um sentido restrito para indicar características específicas que permitem a substituição e a montagem em sistemas maiores.

No RUP, utilizamos o termo "componente" para indicar uma parte encapsulada de um sistema, idealmente uma parte incomum, praticamente independente e substituível de um sistema que cumpre uma função clara no contexto de uma arquitetura bem definida. Isso inclui:

• componente de design - uma parte encapsulada significativa do design e, portanto, inclui Subsistemas de Design e algumas vezes Classes de Design e Pacotes de Design significativos.
• componente de implementação - uma parte encapsulada significativa da implementação, geralmente código que implementa um componente de design.

Idealmente, o design reflete a implementação e, portanto, é possível referir-se apenas a componentes, cada um tendo um design e uma implementação.

A UML ([UML04]) define "componente" como:

Uma parte modular de um sistema que encapsula seu conteúdo e cuja manifestação é substituível em seu ambiente. Um componente define seu comportamento em termos de interfaces fornecida e requerida. Portanto, um componente serve como um tipo, cuja conformidade é definida pelas interfaces fornecida e requerida (incluindo as semânticas estática e dinâmica).

Um componente é definido como um subtipo de classe estruturada, que fornece um componente tendo atributos e operações, sendo capaz de participar de associações e generalizações e tendo estrutura interna e portas. Consulte Conceitos: Classe Estruturada para obter detalhes adicionais.

Existem vários estereótipos padrão da UML que aplicam-se ao componente, por exemplo, <<subsistema>> para modelar componentes em larga escala e <<especificação>> e <<realização>> para modelar componentes com definições distintas de especificação e realização, em que uma especificação pode ter várias realizações.

O uso do termo "componente" no RUP é mais amplo do que a definição da UML. Em vez de definir componentes como tendo características, como modularidade, implementabilidade e capacidade de substituição, recomendamos-as como características desejáveis de componentes. Consulte a seção a seguir sobre Componentes Substituíveis.

Substituição de Componentes

Na terminologia do RUP e da UML, os componentes devem ser substituíveis. No entanto, isso pode querer dizer apenas que o componente apresenta um conjunto de interfaces que ocultam uma implementação subjacente.

Há outros tipos de capacidade de substituição mais fortes. Eles são listados a seguir.

Substituível no Arquivo de Origem

Se duas classes forem implementadas em um único arquivo de código fonte, não será possível criar a versão e controlar cada uma das classes separadamente.

No entanto, se um conjunto de arquivos implementar completamente um único componente, e nenhum outro componente, o componente será substituível pelo arquivo de origem. Essa característica torna mais fácil o controle de versão, a linha de base e a reutilização do código fonte do componente.

Substituível na Implementação

Se duas classes forem implementadas em um único executável, cada classe não será substituível independentemente em um sistema implementado.

Uma característica desejável de componentes de granularidade maior é ser "substituível na implementação", permitindo que novas versões do componente sejam implementadas sem que seja necessário reconstruir os outros componentes. Isso geralmente significa que existe um arquivo ou um conjunto de arquivos que implementam o componente e nenhum outro componente.

Substituível no Tempo de Execução

Se um componente puder ser reimplementado em um sistema em execução, ele será chamado de "substituível no tempo de execução". Isso permite que seja feito upgrade do software sem perda de disponibilidade.

Transparência de Local

Os componentes com interfaces de rede endereçável são referidos como tendo "transparência de local". Isso permite que os componentes sejam relocalizados em outros servidores ou sejam replicados em vários servidores para suportar a tolerância a falhas, o equilíbrio de carga e outros. Esses tipos de componentes são geralmente chamados de componentes "distribuídos" ou "distribuíveis".

Modelagem de Componentes

O componente UML é uma construção de modelagem que fornece os recursos a seguir:

• é possível agrupar classes para definir uma parte maior de granularidade de um sistema
• é possível separar as interfaces visíveis da implementação interna
• é possível ter instâncias que são executadas no tempo de execução

Um componente tem uma série de Interfaces fornecidas e requeridas, que formam a base para conectar os componentes. Uma Interface fornecida é aquela implementada diretamente pelo componente ou uma de suas classes ou subcomponentes de realização ou é o tipo de uma Porta fornecida do Componente. Uma interface requerida é designada por uma Dependência de Uso do Componente ou uma de suas classes ou subcomponentes de realização ou é o tipo de uma Porta requerida.

Um componente tem uma visualização externa (ou visualização de "caixa preta") por meio de suas propriedades e operações publicamente visíveis. Opcionalmente, um comportamento como uma máquina de estado de protocolo pode ser conectado a uma interface, a uma porta e ao próprio componente, para definir a visualização externa com mais exatidão, tornando explícitas as restrições dinâmicas na seqüência de chamadas da operação. A conexão entre os componentes em um sistema ou outro contexto pode ser estruturalmente definida utilizando dependências entre as interfaces de componente (geralmente em diagramas de componentes).

Opcionalmente, uma especificação mais detalhada da colaboração estrutural pode ser feita utilizando partes e conectores nas estruturas compostas, para especificar a colaboração no nível de função ou de instância entre os componentes. Ou seja, a visualização interna do componente (ou a visualização de "caixa branca") por meio de suas propriedades privadas e classes ou subcomponentes de realização. Esta visualização mostra como o comportamento externo é realizado internamente. O mapeamento entre as visualizações interna e externa é feito por meio de dependências (em diagramas de componentes) ou conectores de delegação para partes internas (em diagramas de estrutura composta).

O RUP recomenda a utilização de componentes como a representação para Subsistemas de Design. Consulte Produto de Trabalho: Subsistema de Design, Tarefa: Design de Subsistema, e Orientações: Subsistema de Design para obter informações mais detalhada. Além disso, consulte as definições em Conceito: Classe Estruturada.

Instanciação de Componentes

Um componente pode ou não ser diretamente instanciado no tempo de execução.

Um componente indiretamente instanciado é implementado, ou realizado, por um conjunto de classes, subcomponentes ou partes. O componente em si não aparece na implementação; ele serve como um design que uma implementação deve seguir. O conjunto de classes, subcomponentes ou partes de realização deve abranger o conjunto inteiro de operações especificado na interface fornecida do componente. O modo de implementar o componente é responsabilidade do implementador.

Um componente diretamente instanciado especifica sua própria implementação encapsulada; ele é instanciado como um objeto endereçável. Isso significa que um componente de design possui uma construção correspondente na linguagem de implementação, portanto pode ser explicitamente referenciado.

Representação da UML 1.x

"Componente" definido pela UML 1.5 como:

Uma parte modular, implementável e substituível de um sistema que encapsula a implementação e apresenta um conjunto de interfaces. Um componente é geralmente especificado por uma ou mais classes ou subcomponentes que residem nele e pode ser implementado por um ou mais artefatos (por exemplo, arquivos binários, executáveis ou de script).

Observe que na UML 1.3 e em versões anteriores da UML, a notação "componente" era utilizada para representar arquivos na implementação. Os arquivos não são mais considerados "componentes" pelas definições mais recentes da UML. No entanto, muitas ferramentas e perfis UML ainda utilizam a notação de componente para representar os arquivos. Consulte Orientações: Elemento de Implementação para obter mais discussão sobre arquivos de representação no UML.

Da perspectiva de modelagem, os componentes eram comparados com Subsistemas da UML na UML 1.5, uma vez que forneciam modularidade, encapsulamento e instâncias aptas a executarem no tempo de execução. O RUP considera a construção de modelagem de componentes da UML 1.5 uma notação alternativa para representar os Subsistemas de Design. Consulte Produto de Trabalho: Subsistema de Design e Orientações: Subsistema de Design para obter mais detalhes.

Consulte Diferenças entre a UML 1.x e a UML 2.0para obter informações adicionais.