O componente é um módulo independente que provê informações sobre o que ele faz e como usá-lo através de suas interfaces públicas, enquanto encapsula as suas tarefas internas (MCCLURE, 2001, p. 4; BARROCA et al, 2005, p. 4). Conforme esses autores, algumas características básicas são requisitadas para que um componente atenda os seus princípios básicos:
41
• interface bem definida: como elas definem os serviços que o componente atende, elas devem ser claras, explicitas e fornecer uma documentação;
• facilidade de ser substituído: a interação entre os componentes deve ser única e exclusivamente através de suas interfaces. A sua especificação precisa ser clara sobre suas funcionalidades e relações com outros componentes; e
• interoperabilidade com outros componentes: aqui entram os serviços de infra-estrutura do ciclo de vida e comunicação dos componentes, que é referenciada como middleware (BARROCA et al, 2005, p. 21). Existem padrões abertos (como o CORBA da OMG) e proprietários (COM/DCOM da Microsoft e RMI do Java da SUN).
O conceito de componentes é muitas vezes confundido, ao de objetos. A diferença marcante entre ambos está em sua granularidade. Um objeto atende a uma responsabilidade bem limitada, abstrai um conceito menor, deve prover alta coesão e baixo acoplamento (LARMAN, 2004). Em contrapartida, um componente encapsula um número maior de responsabilidades e funcionalidades sendo, portanto, maiores (MCCLURE, 2001, p. 5). Eles podem requerer interação de muitos outros componentes para atingir seus objetivos.
Para esclarecer essa diferença, será exemplificado o módulo de Diário de Classe de um ambiente de aprendizagem. Quando se fala em objetos (e classes), as necessidades envolvidas nesse módulo são divididas em vários conceitos: aluno, dia, disciplina, avaliação, regras de distribuição de pesos para a nota final, entrada de dados, persistência dos dados, etc; e cada um desses conceitos é atendido por uma ou mais classes. A equipe de desenvolvimento vai se preocupar no projeto, implementação e utilização dessas classes. Os projetos futuros podem (e deveriam) reutilizá-las. O usuário das classes tem acesso a cada uma delas, podendo estendê-las, ou rearranjá-las da forma que melhor convir. Ele monta a aplicação com essas pequenas partes.
Numa visão de componente, existe o módulo “Diário de Classe” como uma única entidade. Ela possui uma interface que o montador da aplicação vai usufruir para acoplá-la no sistema. Nessa interface constam configurações de cálculo de aprovação, as regras de distribuição dos pesos, como conectar-se a um banco de dados para armazenar os dados do módulo, etc. O usuário do componente tem acesso ao módulo somente através dessas interfaces. Ele não consegue estender o componente, ou modificar alguma lógica, se esta não está fornecida através das interfaces.
42
Enquanto a montagem de uma aplicação com objetos é um trabalho enfadonho, pois requer a disposição e ligação de pequenos blocos para realizar uma funcionalidade, a montagem com componentes é mais produtiva, porque se juntam blocos completos para a mesma tarefa, inclusive, o próprio bloco já pode ter toda a funcionalidade inerente.
Portanto, um componente é um conjunto de artefatos de software (p.e., classes, bancos de dados, arquivos de mídia) encapsulados, e que fornece uma interface para publicar os serviços que ele oferece, assim como que serviços que ele também requer para executar as suas funcionalidades.
A ESBC é muitas vezes confundida com o próprio desenvolvimento baseado em componentes (DBC). Esse trabalho utilizará a definição de Pressman (2002), onde a ESBC é dividida pela modelagem de domínio (ou engenharia de domínio (ED)) e modelagem de especificação (ou DBC).
Na ED existem duas perspectivas (WERNER e BRAGA, 2005, p. 60): na primeira se pretende entender o problema de negócio, definindo modelos conceituais, se situando sobre as características do negócio. Na segunda, o objetivo é conhecer sistemas e aplicações já existentes sobre o domínio dessa aplicação, além de “identificar, construir, catalogar e disseminar um conjunto de componentes de software” (PRESSMAN, 2002, p. 707) sobre esse domínio.
Essa engenharia é composta de duas atividades: análise, que define os requisitos, delimita o domínio, define características naquele domínio; e projeto, onde se generaliza uma arquitetura de software para atender as especificações do domínio, delimitando o quão reutilizável será o componente, o que implica na definição das interfaces.
A implementação é responsabilidade do DBC. Nesse processo buscam-se por componentes para utilizá-los, ou se desenvolvem novos. Então o DBC é composto pelas tarefas de (PRESSMAN, 2002, p. 714): (i) qualificação de componentes (analisá-lo comparando com os requisitos funcionais e não-funcionais, se integrável com as ferramentas de desenvolvimento legadas, etc), (ii) adaptação de componentes (com três possibilidades: alterar o código interno, utilizar alguma API ou mecanismo de extensão do componente, e introdução de pré ou pós processamentos das interfaces. Se não houver a adaptabilidade, recorre-se a implementação de um novo componente), (iii) composição de componentes (juntar os componentes para atender a arquitetura estabelecida na ED), e (iv) interoperação (adequação dos componentes dentro de um middleware).
43
Em relação à modelagem de componentes, a UML 2.0 apresentou mudanças significativas na modelagem do diagrama de componentes em relação à versão 1.4 (PENDER, 2004, p. 425; FOWLER, 2005, p. 135). Conforme Fowler (2005), nas versões anteriores os componentes eram tratados como DLLs, e nessa nova versão eles são considerados artefatos.
Pender (2004) comenta que essas modificações facilitam a especificação das interfaces e de como um componente é composto, e são as seguintes:
• um componente é modelado com a mesma notação de uma classe, adicionando o estereótipo <<component>> ou uma ícone de componente que era utilizado na versão 1.4 (Figura 12);
• é possível representar a dependência entre os componentes, sem necessariamente explicitar as interfaces que eles dependem, através de linhas tracejadas (Figura 12.a);
• as interfaces fornecidas são representadas por um círculo. E as requeridas (ou exigidas) por um meio círculo (Figura 12.b). Essas interfaces também podem ser representadas por classes (Figura 12.c);
• a conexão entre as interfaces de dois componentes é representada por um ícone onde o círculo está dentro do meio círculo (Figura 12.d).
44
Figura 12. Diagrama de componentes Fonte: Adaptado de Pender (2004).