Conceitos: Componente
Tópicos
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 de
"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 substituível, incomum e praticamente independente
de um sistema que cumpre a 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 generalizaçã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.
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, o baseline 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".
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 Artefato: Subsistema de Design, Atividade:
Design de Subsistema e Diretrizes: Subsistema de
Design para obter detalhes. Consulte também as definições em Conceitos:
Classe Estruturada.
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.
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 Diretrizes: Elemento de Implementação
para discussão adicional sobre a representação de arquivos na 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 Artefato:
Subsistema de Design e Diretrizes: Subsistema de
Design para obter detalhes.
Consulte Diferenças entre a UML
1.x e a UML 2.0 para obter informações adicionais.
|