SóProvas



Questões de Engenharia de Software Baseada em Componentes (ESBC)


ID
4996
Banca
CESGRANRIO
Órgão
TCE-RO
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Em Engenharia de Software, determinado conceito permite que, entre dois elementos de software A e B, seja possível postular alguma mudança de A, que pediria que B fosse mudado (ou, no mínimo, cuidadosamente verificado) a fim de preservar a exatidão global, e também postular alguma mudança, que pediria que tanto A como B mudassem juntos para preservar a exatidão global. Trata-se do conceito de:

Alternativas
Comentários
  • De onde raios veio esse conceito ? Tanenbaum ?
  • Texto copiado exatamente de um PowerPoint de um professor da UFRJ.........

    A congeneridade entre elementos A e B significa:
    1.Que uma mudança em A implica em mudança em B, ou pelo menos verificação cuidadosa, para preservar a exatidão global
    2.Que existem mudanças que exigiriam que, tanto A quanto B, fossem mudados juntos para preservar a exatidão geral
     
    Fonte: http://www.dcc.ufrj.br/~schneide/psi/cap8Encapsulamento.pps

ID
158038
Banca
FCC
Órgão
METRÔ-SP
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação à componentização e reuso, considere:

I. Se o componente sendo projetado é muito complicado, então, não é usável, por ser muito complexo ou apenas uma pequena porção desse componente é usada. Ao projetar um componente reusável, deve-se estar atento para que ele seja tão simples quanto possível.
II. Quando é projetada uma solução baseada em componentes, é possível obter um comportamento comum de modo que vários usuários possam utilizar. Uma outra forma para reuso de interfaces genéricas é o reuso da especificação. Uma vez que os componentes podem possuir múltiplas interfaces, é possível ter diferentes componentes.
III. No que concerne ao reuso dos componentes existentes, as interfaces podem ser projetadas para usar outras interfaces em tempo de design (desde que todas as implementações de componentes no sistema especificado suportem as interfaces) ou em tempo de implementação (usa os serviços de outras interfaces).

É correto o que consta em

Alternativas
Comentários
  • Com relação a proposição II, algém pode me explicar o que vem a ser: "Reuso da especificação" ???

    Tipo, eu faço uma especificação para criar um componente A. Que tem sua utilidade e particularidades...

    Depois eu vejo a necessidade de um novo componente B. Aí eu reutilizo a especificação de A para criar B??? Faz sentido isso?

    Se alguém interpretou a questão de outra maneira e poder explicar agradeço.
  • Lamentável essa questão.
    A I diz que "Se o componente sendo projetado é muito complicado, então, não é usável..."
    Usável é algo bem diferente de reusável.
    Nesse caso, entendo que a alternativa I esteja errada porque qualquer componente, se projetado corretamente, por mais complexo que seja, será usável para o propósito pelo qual foi projetado. Ele pode não ser reusável para outros própósitos, mas usável será.
  •  e)I, II e III.

  • Um breve resumo.


ID
321334
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em linhas de produtos,

Alternativas

ID
337720
Banca
CS-UFG
Órgão
UFG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A engenharia de software baseada em componentes consiste em um modelo genérico de desenvolvimento de software que se baseia em componentes de software reusáveis padronizados e um middleware de integração desses componentes. Embora seja uma das principais abordagens de desenvolvimento de sistemas de software
corporativos e comerciais, o analista de sistemas que decidir pelo reuso de componentes deve enfrentar o problema de

Alternativas
Comentários
  •  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.

  • Para Sommerville, embora a CBSE (Component-Based Software Engineering) esteja se desenvolvendo rapidamente em uma abordagem principal para o desenvolvimento de software, alguns problemas permanecem:

    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.


ID
362749
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em uma visão restritiva, muitas pessoas costumam associar o termo
software aos programas de computador. Software não é apenas o
programa, mas também todos os dados de documentação e
configuração associados, necessários para que o programa opere
corretamente. A respeito de engenharia de software, julgue os itens
de 61 a 65.

Na engenharia de software baseada em componentes, na qual se supõe que partes do sistema já existam, o processo de desenvolvimento concentra-se mais na integração dessas partes que no seu desenvolvimento a partir do início. Essa abordagem é baseada em reúso para o desenvolvimento de sistemas de software.

Alternativas
Comentários
  • 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. Logo, esse tipo de abordagem centra-se fundamentalmente na reutilização de componentes. Fonte: https://www.wikiwand.com/pt/Engenharia_de_software_baseada_em_componentes

  •  Engenharia é especializada em produzir componentes reusáveis. Engenheiros raramente fabricam um componente a partir do nada. Eles baseiam seus projetos em componentes exaustivamente testados em outros sistemas. Quando se fala em Modelo baseado em Componentes, refere-se a uma estratégia de engenharia de software na qual o processo de desenvolvimento é voltado à reusabilidade. Percebam, portanto, que há uma concentração dos esforços mais na integração de partes existentes do que no seu desenvolvimento desde o início.


ID
425017
Banca
UFBA
Órgão
UFBA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No processo de software baseado em componentes, cada componente projetado para reuso é uma entidade executável independente, que deve manipular exceções.

Alternativas
Comentários
  • No processo de software baseado em componentes, cada componente projetado para reuso é uma entidade executável independente, que deve manipular exceções.(Acredito que o erro seja esse)
  • O problema da questão está em "Que deve  manipular exceções", não é obrigatório que todo componente manipule exceção. Pode haver alguns que manipule.
  • 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.


  • 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: Errado

    Fonte: Engenharia de Software 8ª Edição. Sommerville
  • O "processo de software baseado em componentes" são considerados, na literatura, como sendo de um nível mais algo de abstração do que os objetos (que são implementações, códigos), sendo assim não há obrigação de "uma entidade executável independente", como diz a questão. Pode haver ou não, a pergunta afirma, está errado isso.


ID
645361
Banca
AOCP
Órgão
BRDE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre Engenharia de Software orientada a reúso e seus estágios intermediários em um processo orientado ao reúso, analise as assertivas e assinale a alternativa que aponta a(s) correta(s).

I. Dada a especificação de requisitos, é feita uma busca por componentes para implementar essa especificação. Em geral, não há correspondência exata, e os componentes que podem ser usados apenas fornecem alguma funcionalidade necessária. Esse é o estágio da Análise de componentes.

II. A engenharia de software orientada a reúso, em relação ao modelo Cascata, tem a vantagem da obtenção do feedback dos clientes sobre o desenvolvimento que foi feito.

III. No estágio da Modificação de requisitos, requisitos são analisados usando-se informações sobre os componentes que foram descobertos. Em seguida, estes serão modificados para refletir os componentes disponíveis. No caso de modificações impossíveis, a atividade de análise de componentes pode ser reinserida na busca por soluções alternativas.

IV. Do ponto de vista de gerenciamento, esta abordagem tem um problema que é o de o processo não ser visível. Os gerentes precisam de entregas regulares para mensurar o progresso.

Alternativas
Comentários
  • I. Dada a especificação de requisitos, é feita uma busca por componentes para implementar essa especificação. Em geral, não há correspondência exata, e os componentes que podem ser usados apenas fornecem alguma funcionalidade necessária. Esse é o estágio da Análise de componentes. (correto) Lembrando que, tipicamente, em termos técnicos, os componentes utilizam Orientação a Objetos.

    II. A engenharia de software orientada a reúso, em relação ao modelo Cascata, tem a vantagem da obtenção do feedback dos clientes sobre o desenvolvimento que foi feito. (errado) O feedback dos clientes está relacionado a prototipação.

    III. No estágio da Modificação de requisitos, requisitos são analisados usando-se informações sobre os componentes que foram descobertos. Em seguida, estes serão modificados para refletir os componentes disponíveis. No caso de modificações impossíveis, a atividade de análise de componentes pode ser reinserida na busca por soluções alternativas. (correto)

    IV. Do ponto de vista de gerenciamento, esta abordagem tem um problema que é o de o processo não ser visível. Os gerentes precisam de entregas regulares para mensurar o progresso. (errado) Acredito que seja possível realizar planejamento prévio na orientação a componentes, sendo viável outras formas de mensurar o progresso, não necessariamente entregas regulares.
  • LETRA B.

    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.
    Este modelo se diferencia dos outros já citados por possuir atividades específicas:

    • Análise de Componentes - Com base na especificação dos sistemas, os componentes disponíveis que possam ser utilizados são selecionados e analisados.
    • 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.
    • Projeto 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.
    • 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.

    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.
    Fonte: http://www.linux.ime.usp.br/~cef/mac499-05/monografias/rec/daw/eng_soft.html


ID
677395
Banca
FEC
Órgão
DETRAN-RO
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo de desenvolvimento baseado em componentes compõe aplicações a partir de componentes de software previamente preparados. Esses componentes são conhecidos como:

Alternativas
Comentários
  • e)rotinas.

    Rotinas são basicamente qualquer sequencia de codigo que visa reaproveitamento no corpo do programa


ID
835921
Banca
FDC
Órgão
MAPA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação ao reuso de produtos COTS (produtos de prateleira), são problemas relacionados à integração de sistemas COTS os abaixo relacionados, EXCETO:

Alternativas
Comentários
  • Sommerville expõe quatro problemas com integração de sistemas COTS:
    1. Falta de controle sobre a funcionalidade e desempenho. Embora a interface publicada possa parecer oferecer os recursos necessários, estes podem não ser adequadamente implementados ou podem ser executados insatisfatoriamente.
    2. Problemas com a interoperabilidade de sistemas COTS. Às vezes é difícil fazer com que produtos COTS trabalhem juntos porque cada produto incorpora suas próprias suposições sobre como será usado.
    3. Nenhum controle sobre a evolução do sistema. Os fornecedores de produtos COTS tomam suas próprias decisões sobre mudanças de sistema em resposta às pressões de mercado. Novas versões podem ter funcionalidade adicional não desejada e versões anteriores podem tornar-se indisponíveis e deixarem de contar com o suporte dos fornecedores.
    4. Suporte de fornecedores de COTS. O nível de suporte disponível dos fornecedores varia muito. Devido a esses sistemas serem comerciais, o suporte do fornecedor é particularmente importante quando surgem problemas, pois os desenvolvedores não tem acesso ao código-fonte e à documentação do sistema. Enquanto os fornecedores podem se comprometer a fornecer suporte, mudanças de mercado e circunstâncias econômicas podem dificultar o cumprimento desse compromisso.

    (Fonte: Engenharia de Software, 8ed, Sommerville, pag 285)
    Gabarito letra "E". 

ID
1523659
Banca
FEMPERJ
Órgão
TCE-RJ
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes afirmativas sobre o desenvolvimento de software baseado em componentes (CBD – Component-Based Development):

I. Incorpora algumas das características do modelo de desenvolvimento em espiral;
II. Induz o reaproveitamento de software;
III. Benefcia-se da tecnologia de orientação para objetos;
IV. Faz uso do conceito de composição.

Está correto somente o que se afirma em:

Alternativas
Comentários
  • Prezados,

    Basicamente o CBD prevê é pegar elementos de uma coleção de componentes reutilizáveis e construir aplicações apenas fazendo as ligações necessárias entre esses componentes.

    Então, o CBD incorpora algumas características do modelo em espiral , pois o produto vai sendo construído em etapas, acoplando-se os componentes e testando , depois acoplando mais. Ele induz fortemente o reaproveitamento de software, e faz muito uso da orientação a objetos. O CBD também usa o conceito de composição, visto que o software é feito da composição dos componentes.

    Portanto a alternativa correta é a letra B.


ID
1815724
Banca
FUNDEP (Gestão de Concursos)
Órgão
Prefeitura de Bela Vista de Minas - MG
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que apresenta CORRETAMENTE o modelo de processo de software que enfatiza a integração de componentes reutilizáveis.

Alternativas
Comentários
  • A engenharia de software baseada em componentes (component-based software engineering, CBSE) é um processo que enfatiza o projeto e a construção de sistemas baseados em computador usando "componentes" de software reutilizáveis (PRESMMAN, 2002).

    A prática da tecnologia de software baseado em componentes baseia-se no desenvolvimento através de componentes reutilizáveis, levando a redução de tempo de desenvolvimento, e facilitando as mudanças e a implantação de novas funcionalidades.

    Dessa forma, o processo de engenharia de software baseada em componentes tem mudado o modo pelo qual sistemas são desenvolvidos, pois desloca a ênfase da programação do software para a composição de sistema de software com base em componentes (PRESMMAN, 2002)

    Referência: http://www.linhadecodigo.com.br/artigo/3119/engenharia-de-componentes-parte-1.aspx#ixzz5AUffC3y0


ID
3055522
Banca
FCC
Órgão
TCE-RS
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

A arquitetura baseada em componentes se constitui em um paradigma de importância crescente na engenharia de software. Nesse tipo de arquitetura,

Alternativas
Comentários
  • A. detalhes da implementação de cada componente são abertos [fechados], ou seja, conhecidos [desconhecidos] por todos os demais componentes do sistema.

    B. componentes são independentes, no sentido de que não há interferência entre eles.

    C. a substituição de um componente sempre obriga a [não ocasiona na] realização de alterações de porte no sistema afetado.

    D. na substituição de um componente por outro, sua interface sempre requer [não precisará de] alterações.

    E. [não existe] um número máximo de componentes em cada sistema.


ID
3226183
Banca
INSTITUTO AOCP
Órgão
PRODEB
Ano
2018
Provas
Disciplina
Engenharia de Software
Assuntos

O React é uma biblioteca utilizada para desenvolvimento de interfaces (frontend) que tem como base o princípio do desenvolvimento de componentes. O React utiliza-se de uma técnica de dividir as estruturas complexas em partes menores e desenvolver para cada uma delas um componente. Como é o nome dessa técnica?

Alternativas
Comentários
  • Component Driven Development.