A engenharia de software baseada em componentes consiste em ...

Gabarito: Letra D - confiabilidade e certificação dos componentes reusados.

A Engenharia de Software Baseada em Componentes (ESBC) é um paradigma de desenvolvimento de software que enfatiza a importância de reutilizar componentes de software previamente construídos e testados, com a intenção de aumentar a eficiência e a qualidade no processo de desenvolvimento de sistemas. Este modelo depende fortemente da integração de componentes que possam se comunicar entre si por meio de interfaces bem definidas, geralmente facilitadas por um middleware.

Com relação à questão da confiabilidade e certificação dos componentes reusados, esta é uma preocupação primordial no reuso de componentes. Cada componente de software deve ser confiável, o que significa que deve funcionar conforme o esperado e ser robusto em relação a falhas. A certificação de um componente implica em uma garantia formal de que ele atende a determinados padrões de qualidade ou normas técnicas. Na prática, a confiabilidade e a certificação são cruciais, pois as falhas em um componente podem se propagar por todo o sistema, levando a um comportamento inesperado ou até mesmo a falhas críticas.

Portanto, a alternativa D está correta porque destaca uma das principais preocupações ao decidir pelo reuso de componentes de software. A confiabilidade e certificação são aspectos que têm um impacto direto na qualidade e segurança do sistema final. Os desenvolvedores e analistas de sistemas devem garantir que os componentes reutilizados sejam não apenas funcionais, mas também seguros e confiáveis, para manter a integridade e a reputação dos sistemas de software corporativos e comerciais.

Embora as demais alternativas possam representar desafios no contexto de ESBC, a questão coloca a confiabilidade e a certificação como o problema que o analista deve enfrentar, reforçando que este é um aspecto crítico ao se optar pelo reuso de componentes de software.

 a) dependência de linguagem de programação dos componentes reusados. (errado) O middleware serve justamente para realizar a abstração e manter a independência entre as linguagens dos componentes.

 b) falta de padronização dos componentes reusados. (dúvida) Também me parece um problema... afinal, é um pressuposto na engenharia de componentes que exista um padrão na criação dos componentes. Eu consideraria como um problema.

 c) alto custo de desenvolvimento dos componentes reusados em comparação ao custo de integração e de teste dos mesmos. (errado) O custo de um componetne para reúso será diluído nos projetos seguintes que necessitarem do seu uso, gerando economia de recursos e tempo. O custo de integração é menor que o custo do desenvolvimento do componente.

 d) confiabilidade e certificação dos componentes reusados (certo) 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.

1. Confiabilidade de componentes. Os componentes são unidades caixa-preta de programa, e o código-fonte do componente pode não estar disponível aos usuários. Nesses casos, como o usuário pode saber que um componente é confiável? O componente pode ter modos de falha não documentada que comprometa o sistema em que é usado.

2. Certificação de componentes. Estreitamente relacionada com a confiabilidade está a questão de certificação. Foi proposto que avaliadores independentes devem certificar componentes para assegurar que estes são confiáveis. Contudo, não está claro como isso pode funcionar.

3. Previsão de propriedade emergente*. Devido aos componentes serem opacos, a previsão de suas propriedades emergentes é particularmente difícil. Consequentemente, você pode descobrir que, quando os componentes são integrados, o sistema resultante tem propriedades indesejáveis que limitam seu uso.

4. Compromisso de requisitos. Geralmente, você precisa ter compromissos entre requisitos ideais e componentes disponíveis no processo de especificação e projeto do sistema. Nesse momento, ter esses compromissos é um processo intuitivo. Nós necessitamos de um método de análise estruturado e sistemático de compromissos para ajudar os projetistas a selecionar e configurar componentes.

(Fonte: Engenharia de Software, 8ed, Sommerville, Cap 19)

PS. No capítulo 2, Sommerville explica que propriedades emergentes de um sistema são características do sistema como um todo, em vez de seus componentes. São propriedades como desempenho, confiabilidade, usabilidade, segurança e proteção. Ou seja, são propriedades que não podem ser atribuídas a qualquer parte específica do sistema. Ao contrário, elas aparecem apenas após a integração de todos os componentes do sistema. O sucesso ou falha de um sistema geralmente depende dessas propriedades.

Voltando para as alternativas,
a) Errado. Se os componentes estiverem em conformidade com os padrões, a operação será independente de linguagem de programação. Componentes escritos em linguagens diferentes podem ser integrados em um mesmo sistema. (pag 292)
b) Errado. O próprio enunciado da questão destaca que os "componentes de software reusáveis padronizados". Mesmo assim, isso não deveria ser um problema pois um componente deve ter as seguintes características: Padronizado, Independente, Passível de Composiçao, Implantável e Documentado. (pag 294)
c) Errado. Explicado pelo Saulo Guerra.
d) Correta.

Alguém poderia argumentar o porquê da alternativa b ser incorreta?

Acredito que a alternativa B seja incorreta por ser taxativa, leva a entender que os componentes reusados não possuem padrão.

Assim como o Saulo Guerra comentou, a existência de padrão é um pressuposto, portanto o problema a ser enfrentado é esperar que os componentes sejam confiáveis e certificados.