ESBC – Engenharia de Software Baseada em componentes

Engenharia de Software Baseada em componentes é um ramo de Engenharia de Software, com ênfase na decomposição dos sistemas, em componentes funcionais e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios componentes. Componentes são considerados como estando num nível de abstração mais alto que do que Objetos e, como tal, não compartilham estado e comunicam-se por troca de mensagens contendo dados.

História

Durante a Conferência de Engenharia de Software da OTAN realizada em 1968, Mcilory expõe a ideia de que o desenvolvimento de software deve empenhar-se em produzir componentes reusáveis com o intuito de proporcionar aos desenvolvedores a possibilidade de escolher quais componentes utilizar, conforme as suas necessidades. Nasce aí o interesse em desenvolver software através da integração de componentes de software.

Em 1976, DeRemer propôs um paradigma de desenvolvimento onde o sistema seria construído como um conjunto de módulos independentes e depois interligados. Já na década de 80, com o surgimento da orientação a objetos e a possibilidade de reutilização, fortaleceu ainda mais a proposta de produzir componentes.

O que é um componente?

Brown e Wallnau descrevem um Componente como “uma não-trivial, quase independente, e substituível parte de um sistema que cumpre uma função clara no contexto de uma arquitetura bem definida”. Em muitos sentidos, esta descrição é similar a de um objeto em POO. Componentes possuem uma interface. Eles empregam regras de herança.

Já para Szyperski, o componente não é necessariamente uma tecnologia implementada especificamente e nem a aplicação, mas sim um dispositivo de software que possua uma interface bem definida.

Mas para Krutchen, o componente é um elemento independente, que pode ser substituído, contudo, ele é significativo, pois tem uma função clara no contexto em que foi definido.

Mas a definição é levada ainda além. Componentes são definidos para oferecer um certo nível de serviço. No caso dos Componentes “Comerciais de Prateleira” (ou Commercial Off-The-Shelf – COTS), o engenheiro de software sabe pouco ou nada sobre o funcionamento interno de um componente. Ao invés disso, ao engenheiro de software é dada apenas uma interface externa bem-definida a partir da qual ele deve trabalhar. O nível de serviço é portanto crucial e precisa ser acurado se quiser que a integração do componente ao sistema de software seja bem sucedida. Brown e Wallnau descrevem um componente de software como “uma unidade de composição contratualmente especificada e somente com dependências contextuais explícitas”. Ao contrário de objetos em POO, os componentes são usualmente construídos a partir de muitos “objetos” de software (embora a construção não seja confinada a POO) e fornecem uma unidade de funcionalidade coerente. Os assim chamados “objetos” trabalham em conjunto para realizar uma tarefa específica em um dado nível de serviço. Componentes podem ser caracterizados com base em seu uso no processo de ESBC: Como mencionado acima temos os COTS. São componentes que podem ser comprados, pré-fabricados, com a desvantagem de que, no geral, não há código fonte disponível, e sendo assim, a definição do uso do componente dada pelo fabricante (desenvolvedor), e os serviços que este oferece, precisam ser confiavelmente testadas, como podem ou não ser acuradas. A desvantagem, entretanto, é que estes tipos de componentes deveriam (em teoria) ser mais robustos e adaptáveis, pois foram usados e testados (e reusados e re-testados) em muitas diferentes aplicações. Adicionalmente aos COTS, a ESBC almeja componentes:

• Qualificados;
• Adaptados;
• Aglutinados;
• Atualizados.

Processo de ESBC

A Engenharia de Software Baseada em Componentes (ESBC) é, em muitos sentidos, similar a engenharia de software convencional ou orientada a objetos. Uma equipe de desenvolvedores define requisitos para o sistema ser construído, usando técnicas de elicitação de requisitos convencionais. Um design da arquitetura é estabelecido. Neste ponto contudo, o processo difere. Ao invés de um detalhando design, a equipe examina os requisitos, para determinar qual subconjunto é diretamente moldável ao esquema decomposição, em detrimento de um esquema de construção. Para cada requisito, a equipe se perguntará:

• Há COTS disponíveis para implementar o requisito?
• Componentes reusáveis desenvolvidos internamente (a software-house) estão disponíveis para implementar o requisito?
• As interfaces para os componentes disponíveis são compatíveis dentro da arquitetura do sistema a ser construído?

A equipe tentará modificar ou remover os requisitos de sistema que não puderem ser implementados com componentes COTS. Isso nem sempre é possível ou prático, mas reduz o custo geral do sistema. Frequentemente pode ser útil priorizar os requisitos, senão desenvolvedores podem se encontrar codificando componentes que já não sejam mais necessários, por já terem sido eliminados dos requisitos.

O processo ESBC identifica não somente possíveis componentes, mas também qualifica a interface de cada componente, adapta o componente para remover incongruências arquitetônicas, monta os componentes dentro de um estilo de arquitetura selecionado, e atualiza componentes como requisitos para a mudança no sistema. Dois processos ocorrem em paralelo durante o processo de ESBC. São:

1) Engenharia de Domínio: Objetiva identificar, construir, catalogar e disseminar um conjunto de componentes de software que tenham aplicabilidade para software existentes e futuros, dentro de um domínio de aplicação específico. Um domínio de aplicação é como uma família de produtos – aplicações com funcionalidade (ou intenção de funcionalidade) similar. O objetivo é estabelecer um mecanismo em que engenheiros de software possam partilhar estes componentes usando-os em sistemas futuros.

2) Desenvolvimento Baseado em Componentes: O Desenvolvimento Baseado em Componentes (DBC) aborda a criação de sistemas de software que envolva a composição de componentes permitindo a adição, adaptação, remoção e substituição de partes do sistema sem a necessidade de sua completa substituição. Isso auxilia na manutenção dos sistemas uma vez que, permite a integração de novos componentes e/ou a atualização dos já existentes. A abordagem é criar ou adaptar os componentes para que sejam utilizados em diversos sistemas. Essa ideia vem ao encontro da reutilização que busca flexibilizar o desenvolvimento.

DBC

O DBC possui duas perspectivas:

1) Desenvolvimento de componentes consiste na criação de novos componentes, desde a especificação (análise, documentação) até a implementação. A documentação é o fator mais importante, pois é ela que possibilitará a reutilização desse componente em outros sistemas, caso haja a necessidade de alterações.

2) Já o desenvolvimento com componentes consiste na criação de sistemas com um conjunto de componentes interligados. Levando em conta que esse componentes já existam e que estejam disponíveis para uma seleção e reutilização.

Segundo Brown, há cinco estágios neste processo: Seleção, Qualificação, Adaptação, Composição e Atualização.

1. A etapa da Seleção de Componente/Análise de Componente consiste em buscar e selecionar componentes que tem potencial para serem usados na construção do sistema. A busca por componente envolve tanto COTS quanto componentes que foram usados em outros sistemas desenvolvidos anteriormente.
2. A etapa de Qualificação do Componente examina componentes reusáveis, para averiguar se, e em que proporção, se adequam aos requisitos do estilo arquitetural do sistema. Há três importantes aspectos considerados: performance, confiabilidade e usabilidade.
3. A etapa de Adaptação do Componente modificará aspectos do componente. É um passo necessário, pois, raramente um componente se adaptará de pronto ao sistema. Dependendo do tipo de componente (e.g. COTS ou in-house – feito na própria empresa) diferentes estratégias de adaptação (também conhecidas como wrapping – encapsulamento) podem ser empregadas.
4. A etapa de Composição integra os componentes no sistema, por meio de uma infraestrutura feita para aglutinar os componentes em um sistema operacional. A infraestrutura geralmente é em si mesma, uma biblioteca especializada de componentes e serviços que habilita coordenação entre os componentes e realização de tarefas.
5. Já a Atualização, sendo a última atividade, tem-se a atualização dos componentes, onde versões antigas serão substituídas ou novos componentes, com comportamento e interface similares, serão incluídos.

Em suma, se componentes reusáveis existem para um dado caso, precisarão ser qualificados e adaptados. Se novos componentes são necessários, precisarão ser criados. Lembrando que a existência de componentes reusáveis não garante sua integração fácil ou mesmo efetiva.

A Adaptação de um Componente

Conforme pesquisas realizadas, segundo Bosch, têm mostrado que raramente um componente é reutilizado como foi originalmente desenvolvido e que geralmente necessita de alguma forma de alteração para se adequar à arquitetura da aplicação ou aos demais componentes.

As abordagens mais comuns são:

Encapsulamento caixa-branca (White box wrapping) – aqui, a implementação do componente é diretamente modificada para resolver incompatibilidades. Isso é, obviamente, possível apenas se o código-fonte do componente estiver disponível, algo extremamente improvável no caso de COTS.

Encapsulamento caixa-cinza (Grey box wrapping) – Neste caso, a adaptação é feita por uso de uma biblioteca do componente fornecendo uma linguagem de extensão do componente ou API que possibilite a remoção ou mascaramento de conflitos.

Encapsulamento caixa-preta (Black box wrapping) – Caso mais comum, onde não é possível o acesso ao código-fonte, e a única maneira de adaptar o componente é por pré/pós processamento a nível de interface.

É responsabilidade do engenheiro de software determinar se os esforços para encapsular um componente adequadamente são justificados, se seria menos custoso criar um componente que solucione os conflitos. Também, uma vez que um componente foi adaptado é necessário verificar a compatibilidade para integração e realizar-se testes para tentar antecipar quais comportamentos inesperados que surjam devido as modificações realizadas.

Encapsulamento/Empacotamento

O encapsulamento/empacotamento consiste em produzir uma visão externa para um componente, isto é, uma interface, diferente de sua interface original com vista a adaptá-lo a requisitos específicos.

Principais finalidades:

• Incompatibilidade de interfaces (componentes que podem interagir, porém as interfaces não são compatíveis). Ocorre devido a assinaturas de métodos diferentes ou por heterogeneidade dos componentes (diferença na Linguagem de programação, na plataforma de execução e localização física);
• Alterar a funcionalidade original do componente. Isso é, incluir novas funcionalidades como também alterar o tratamento original a determinadas invocações de métodos.

Colagem de Componentes

A colagem de componentes (glueing) trata o mesmo problema do empacotamento, isto é, viabilizar a operação conjunta de componentes originalmente incompatíveis. A diferença neste caso é que o tratamento dado ao problema é a inclusão de um novo elemento, a cola (glue), entre os componentes incompatíveis, possibilitando sua operação conjunta.

O elemento cola nada mais é que um terceiro componente, cuja interface possibilita sua conexão aos componentes Componente um e Componente dois e cuja funcionalidade consiste em compatibilizar a operação conjunta destes componentes. Seja a situação de colagem representada e considere-se que o Componente um seja implementado em Smalltalk e Componente dois, em Java. Com isto, o componente cola deve solucionar a heterogeneidade entre os outros dois componentes (que também pode envolver localização física e plataforma de execução), bem como eventuais incompatibilidades sintáticas e funcionais. Suponha-se que a questão da heterogeneidade seja resolvida com o uso de CORBA. Neste caso o componente cola mascararia o tratamento da heterogeneidade.

A cola é uma prática totalmente transparente para o usuário, uma vez que ele não sabe que três tecnologias diferentes foram utilizadas.

Tecnologia de componentes

Atualmente, os principais modelos de componentes disponíveis são:

• CMM (CORBA Component Model) do OMG (Object Management Group).
• DCOM (Distributed Component Object) e COM/COM+ (Component Object Model) da Microsoft.
• JavaBeans e Entreprise JavaBeans (EJB) da Sun.

Sumário

A ESBC introduz grandes mudanças nas práticas de design e desenvolvimento, o que introduz também custos extras. Engenheiros de Software precisam empregar novos processos e formas de pensamento – isto também introduz custo em treinamento e educação. Contudo, estudos iniciais sobre o impacto da ESBC na qualidade do produto, qualidade do desenvolvimento e custo, demonstram um ganho geral, e tudo indica que a continuação destas práticas melhorarão o desenvolvimento de software no futuro. Ainda não está claro como a ESBC amadurecerá, mas está claro seu potencial de auxílio no atual desenvolvimento de sistemas de larga escala, e também no futuro desenvolvimento de sistemas, além de ser considerada a plataforma perfeita para orientar os requisitos de negócio modernos.

Resolução de Questões de Concursos Anteriores

RESPOSTA: B

Segundo Ian Sommerville: “Engenharia de Software Orientada a Reuso – essa abordagem é baseada na existência de grande número de componentes prontos. O desenvolvimento do sistema é focado na integração destes componentes em um sistema.”

O modelo orientado a reuso visa o desenvolvimento de sistemas tendo como base uma gama de componentes reutilizáveis e sistemas COTS (sistemas comerciais de prateleira ) disponíveis no mercado. Partes do software que não puderem ser comprados são desenvolvidos e integrados a estes componentes.

A abordagem orientada a reuso conta com uma larga base de componentes de software reutilizáveis e um framework de integração para fazer a composição destes componentes. Na maioria dos projetos de software acontece o reuso, mas normalmente de modo informal.

Este modelo se diferencia dos outros já citados por possuir atividades específicas:

Os estágios de requisitos e de validação são semelhantes aos estágios dos outros modelos, mas as outras frases são diferentes.

Análise de Componentes – Com base na especificação dos sistemas, os componentes disponíveis que possam ser utilizados são selecionados e analisados. procura-se componentes que atendam os requisitos especificados. Normalmente, os componentes não atendem a necessidade completamente e são usados parcialmente.

Modificação de Requisitos – Os requisitos são analisados com base nos componentes que foram encontrados e se necessário são adaptados de tal forma que os componentes possam ser utilizados e que o sistema cumpra satisfatoriamente com as necessidades do cliente. Caso não seja possível, a análise de componentes pode ser refeita. Os requisitos são analisados de acordo com os componentes e modificados de acordo com as possibilidades dos componentes encontrados. Se a modificação for impossível deve-se retornar para Análise de Componentes para busca de soluções alternativas.

Projeto (Design) de Sistemas – A infra-estrutura do sistema é projetada (podendo reutilizar de uma já existente) tendo em vista integrar os componentes reutilizáveis e softwares a serem desenvolvidos. O framework é projetado para o sistema ou um framework é reutilizado. Os projetistas levam em consideração os componentes e organizam o framework de forma compatível. Alguns programas pode ser escritos caso não exista componentes disponíveis.

Desenvolvimento e integração – Partes do sistema são desenvolvidas e integradas com os componentes e sistemas COTS. A integração pode ser parte do desenvolvimento. Softwares que não podem ser obtidos são desenvolvidos e os componentes ou softwares de prateleira (COTS) são integrados para criar um novo sistema. Nesse caso, a integração faz parte do desenvolvimento.

Este modelo tem a vantagem de reduzir a quantidade de software a ser desenvolvida e assim reduzir custos e riscos, e geralmente propicia a entrega mais rápida do software. Porém as adequações nos requisitos são inevitáveis, podendo resultar em um sistema que não atenda às reais necessidades dos usuários. Além disso, quando os componentes reutilizáveis não estão sob o controle da organização que os utiliza, perde-se o controle sobre a evolução do sistema.

Existem 3 tipos de componentes que podem ser reutilizados:

1. Web services
2. Coleção de objetos desenvolvidos como pacotes para ser integrados a um framework de componentes (.NET or JEE são exemplos de frameworks deste tipo)
3. Sistemas de softwares stand-alone

Esse modelo de processo reduz a quantidade de software a ser desenvolvido, reduzindo assim custos e riscos, levando a um desenvolvimento teóricamente mais rápido. Por outro lado, os requisitos sempre ficam prejudicados de alguma forma, o que pode levar a um sistema que não supre as necessidades reais do cliente. Também não se tem pleno controle a respeito da evolução do sistema, já que novas versões dos componentes não estão sob controle.

RESPOSTA: D

O middleware serve justamente para realizar a abstração e manter a independência entre as linguagens dos componentes.

O custo com reuso é muito inferior ao desenvolvimento tradicional, uma vez que se economiza com partes previamente desenvolvidas. Além disso, o custo de integração é menor que o custo do desenvolvimento do componente.

Um componente que esteja no estágio de reuso deve necessariamente manter um nível de confiabilidade alto, mantendo-se genérico o suficiente, encapsulado e padronizado o suficiente, documentado e testado o suficiente. Caso contrário, o componente “instável” oferece risco a todos os projetos que o utilizarem.

Apesar da resposta ser D, a letra B também poderá ser um problema, tanto que existe faze de adaptação para realizar a integração entre os componentes utilizados.

RESPOSTA: Certo

Fiocruz – Tecnologista em Saúde – 2010 – NCE-UFRJ

Na maioria dos projetos de software, existe algum reuso de software. Isto ocorre geralmente quando as pessoas da equipe conhecem outros projetos com códigos semelhantes aos necessários. Na modelagem evolucionária de processos, o reuso é frequentemente essencial para o desenvolvimento rápido do sistema. Nesse sentido, observe a figura abaixo que representa um modelo de processo, que emprega o reuso. Esse modelo é conhecido como Engenharia de Software baseada em: a) dados b) eventos c) classes d) requisitos e) componentes

RESPOSTA: E

Pressman, 7ª Edição:

O modelo de desenvolvimento baseado em componentes incorpora muitas das características do modelo espiral.

É evolucionário em sua natureza, demandando uma abordagem iterativa para a criação de software.

O modelo baseado em componentes desenvolve aplicações a partir de componentes de software pré-empacotados.

Independentemente da tecnologia usada para criar os componentes, o modelo baseado em componente incorpora as seguintes etapas (implementadas usando-se uma abordagem evolucionária):

1. Produtos baseados em componentes disponíveis são pesquisados e avaliados para o campo de aplicação em questão;
2. Itens de integração de componentes são considerados;
3. Uma arquitetura de software é projetada para acomodar os componentes;
4. Os componentes são integrados na arquitetura;
5. Testes completos são realizados para assegurar funcionalidade adequada.

O modelo conduz ao reúso do software e a reusabilidade proporciona uma série de benefícios mensuráveis aos engenheiros de software. A equipe de engenharia de software pode conseguir uma redução do ciclo de desenvolvimento, bem como uma redução no custo do projeto, caso a reutilização de componentes se torne parte de sua cultura.

RESPOSTA: Errado

No livro de sommerville tem que:

“Componentes podem ser acessados com alguma infra-estrutura de integração e às vezes esses componentes são sistemas propriamente ditos.”

Ou seja, às vezes, não é sempre que componentes são sistemas completos que possivelmente tratam suas exceções.

Ainda segundo Sommerville pag. 297 parágrafo 5: “Os componentes não devem tratar as exceções por si mesmos, pois cada aplicação terá seus próprios requisitos para tratamento de exceções. Antes, o componente deve definir quais exceções podem surgir e publicá-las como parte da interface”.

RESPOSTA: E