Arquitetura de Software

Aula 4: Engenharia de Software Baseada em

Componentes
Prof. Dr. Bruna C. Rodrigues da Cunha
bruna.rodrigues@ifsp.edu.br
Desenvolvimento baseado em componentes
● A engenharia de software baseada em componentes (ESBC) é uma
abordagem de desenvolvimento de software que depende do reuso de
entidades denominadas "componentes de software".
● A abordagem emergiu do fracasso do desenvolvimento Orientado a
Objetos para apoiar o reuso.
● Componentes são mais abstratos que classes de objetos e podem ser
considerados como provedores de serviços independentes. Eles podem
existir como entidades independentes.
● A ESBC também é uma alternativa a arquitetura em camadas em que os
elementos, apesar de independentes, não fornecem uma ampla
capacidade de reuso.
Essência da ESBC
● Seus Componentes são independentes e especificados por suas
interfaces.
● Padrões devem ser utilizados para facilitar a integração de componentes.
● Um Middleware que fornece suporte para interoperabilidade de
componentes.
● O processo de desenvolvimento é voltado para reutilização.
Princípios de Design da ESBC
Além dos benefícios do reuso, a ESBC baseia-se em sólidos princípios de
design de engenharia de software:
● Os componentes são independentes, portanto não há interferência entre
eles;
● Implementações de componentes são ocultas;
● A comunicação é realizada através de interfaces bem definidas;
● Um componente pode ser substituído por outro se sua interface for
mantida.
Padrões de ESBC
● Considerando que componentes podem ser desenvolvidos em diferentes
linguagens e/ou podem ser distribuídos, é necessário estabelecer
padrões para que os componentes possam se comunicar entre si e
interoperar.
● Infelizmente, vários padrões de componentes concorrentes foram
estabelecidos:
○ Enterprise Java Beans (EJB)
○ Component Object Model (COM) da Microsoft
○ CORBA
● Na prática, esses múltiplos padrões têm dificultado a aceitação da ESBC. É
impossível que componentes desenvolvidos usando diferentes padrões
trabalhem juntos.
Engenharia de Software Orientada a Serviços
● Um serviço é um tipo de componente independente. Ele tem uma
interface "fornece", mas não uma interface "requer".
● Desde o início, os serviços foram baseados em padrões, de modo que
não há problemas na comunicação entre serviços oferecidos por
diferentes fornecedores.
● Os dados fornecidos seguem padrões de fácil integração.
● O desempenho do sistema pode ser mais lento (nem sempre!), mas essa
abordagem substituiu a engenharia baseada em componentes na maioria
dos sistemas.
● Porém, recentemente uma abordagem baseada em componentes tem
sido muito utilizada no desenvolvimento de aplicações Web
Componente como provedor de serviço
● Componentes fornecem um serviço sem levar em conta onde o
componente está executando ou sua linguagem de programação
Componente como provedor de serviço
● O componente é uma entidade executável independente. Ele não precisa
ser compilado antes de ser usado com outros componentes.
● Os serviços oferecidos por um componente são disponibilizados por meio
de uma interface publicada e todas as interações de componentes
ocorrem por meio dessa interface.
● A interface do componente é expressa em termos de operações
parametrizadas e seu estado interno nunca é exposto.
Interfaces de Componentes
Fornece interface
● Define os serviços fornecidos pelo componente para outros
componentes.
● Essa interface, essencialmente, é a API do componente. Ele define os
métodos que podem ser chamados.
Requer interface
● Define quais serviços devem ser disponibilizados para que o componente
seja executado conforme especificado.
● Isso não compromete a independência ou a capacidade de implantação,
a interface não define como esses serviços devem ser fornecidos.
Diagrama de Componentes UML
Diagrama de Componentes UML
Componentes (uso moderno)
● Atualmente existem diversos Websites com funcionalidades complexas e
interfaces que exibem uma grande quantidade de informações de forma
independente
● Desenvolvedores identificaram a necessidade de quebrar a interface em
componentes para facilitar o reuso, além de possibilitar o carregamento
dinâmico, ágil e independente de partes de uma página
● Existem bibliotecas e frameworks que se baseiam em uma arquitetura
baseada em componentes para otimizar o desenvolvimento Web (e.g.,
React, Angular2)
● Esse será um dos temas dos seminários da disciplina
Componentes (uso clássico)
● Os componentes são acessados usando Chamadas de Procedimento
Remoto (RPCs).
● Cada componente tem um identificador único (geralmente uma URL) e
pode ser referenciado em qualquer computador em rede.
● Portanto, ele pode ser chamado de maneira semelhante a um
procedimento ou método executado em um computador local.
● Um modelo de componente é uma definição de padrões para
implementação, documentação e implementação de componentes.
● Exemplos de modelos de componentes: EJB, COM, CORBA
● O modelo especifica como as interfaces devem ser definidas e os
elementos que devem ser incluídos em uma definição de interface.
Componentes
● Nos próximos slides vamos tratar do uso clássico de componentes, ou
seja, aqueles que conversam entre si por meio de RPC e constituem
grandes servidores de aplicação
● Apesar de seu uso ter diminuído em consequência do aumento do uso de
soluções baseadas na arquitetura orientada a serviços, diversos conceitos
de componentes são úteis e inspiraram soluções arquiteturais atuais
● Além disso, até mesmo um software em pequena escala pode aplicar o
uso de componentes ao criar módulos reutilizáveis e independentes com
interfaces claras
Modelo de Componentes
Interface
● Componentes são definidos especificando suas interfaces. O modelo de
componente especifica como as interfaces devem ser definidas (nomes de
operações, parâmetros e exceções)
Uso
● Para que os componentes sejam distribuídos e acessados remotamente, eles
precisam ter um nome ou identificador global e único. O modelo auxilia no
gerenciamento e acesso de identificadores.
Implantação
● O modelo de componente inclui uma especificação de como os componentes
devem ser empacotados para implantação como entidades executáveis
independentes.
Modelo de Componentes
● Modelos de componentes proveem o middleware que fornece suporte
para a execução de componentes.
● As implementações suportadas por modelos de componentes fornecem:
○ Serviços de plataforma que permitem que componentes escritos de acordo com o
modelo se comuniquem;
○ Serviços de suporte que são serviços independentes de aplicativos usados por diferentes
componentes.
● Para usar os serviços fornecidos por um modelo, os componentes são
implantados em um contêiner. Ele provê um conjunto de interfaces
usadas para acessar as implementações de serviços, desde que os
serviços sigam o padrão fornecido pelo modelo.
Modelo de Componentes EJB
● EJB é um dos principais componentes da plataforma Java Enterprise Edition (Java
EE) para desenvolvimento de sistemas corporativos. Com ele é possível criar
aplicações baseadas em componentes, separando-os de forma simples e objetiva.
● O EJB provê um padrão para definição das interfaces dos componentes, assim
como API para comunicação entre componentes, como a RMI (Remote Method
Invocation), que faz acesso remoto a outros componentes de forma simples, sendo
possível acessar componentes que estão em outros containers.
● Além de padronizar as interfaces de comunicação entre os componentes, o EJB
oferece serviços de persistência de dados, controle de concorrência, envio de
mensagens, serviço de agendamento, chamadas a métodos remotos, etc.
Modelo de Componentes EJB
● Os componentes EJB são classes Java onde são desenvolvidas as lógicas
de negócio da aplicação. Estas classes, por sua vez, podem ser de lógica
de negócio ou de persistência de dados.
● No EJB, existem três tipos de componentes: Beans de Sessão, MDB
(Message-Driven Bean) e Entity.
● Os Beans de sessão e os MDBs são responsáveis por conter as lógicas de
negócio corporativas, enquanto as Entities possuem toda a lógica de
persistência.
● Enquanto algumas soluções do EJB são consideradas legadas, algumas
são muitos utilizadas, como a JPA (Java Persistence API)
Modelo de Componentes EJB
Processos ESBC
● Os processos da ESBC são processos de software que suportam
engenharia de software baseada em componentes.
Desenvolvimento para reuso:
● Este processo está relacionado ao desenvolvimento de componentes ou
serviços que serão reutilizados em outros aplicativos. Geralmente envolve
a generalização de componentes existentes.
Desenvolvimento com reuso:
● Esse processo é o processo de desenvolvimento de novos aplicativos
usando componentes e serviços existentes.
Desenvolvimento para Reuso
● A ESBC para reutilização se concentra no desenvolvimento de
componentes.
● Componentes desenvolvidos para uma aplicação específica geralmente
precisam ser generalizados para torná-los reutilizáveis.
● É mais provável que um componente seja reutilizável se associado a uma
abstração de domínio estável (que não sofrerão modificações).
● Por exemplo, em um hospital, abstrações de domínio estáveis são
associadas ao propósito fundamental - enfermeiros, pacientes,
tratamentos, etc.
Desenvolvimento para Reuso
Diretrizes:
● Remova os métodos específicos da aplicação, eles devem ser movidos
para seu local de contexto.
● Altere os nomes de métodos para torná-los gerais.
● Torne o lançamento e/ou tratamento de exceções consistente.
● Adicione uma interface de configuração para adaptação de componentes.
● Integre os componentes necessários para reduzir dependências.
Desenvolvimento para Reuso
● Componentes para reutilização podem ser especialmente construídos
pela generalização dos componentes existentes.
○ Deve refletir abstrações de domínio estáveis;
○ Deve esconder a representação do estado;
○ Deve ser o mais independente possível;
○ Deve publicar exceções por meio da interface do componente.
● Trade-off entre reuso e usabilidade: quanto mais geral a interface, maior a
reutilização, mas é mais complexa e menos específica e, portanto,
apresenta menor usabilidade.
● Trade-off entre reuso e desempenho: componentes genéricos podem ser
menos eficientes em termos de espaço e podem ter tempos de execução
mais longos do que seus equivalentes específicos.
Desenvolvimento com Reuso
● O processo de reutilização tem que encontrar e integrar componentes
reutilizáveis.
● Ao reutilizar componentes, é essencial fazer concessões entre os
requisitos ideais e os serviços efetivamente fornecidos pelos
componentes disponíveis.
● Você precisa confiar no fornecedor de um componente. Na melhor das
hipóteses, um componente não confiável pode não funcionar como
anunciado; na pior das hipóteses, pode violar sua segurança.
● Componentes podem ter funcionalidades indesejadas. Como testar se
isso não irá interferir com a sua aplicação?
Desenvolvimento com Reuso
● A validação de componentes envolve o desenvolvimento de um conjunto
de casos de teste para um componente.
● O principal problema com a validação de componentes é que a
especificação do componente pode não ser suficientemente detalhada
para permitir que você desenvolva um conjunto completo de testes de
componentes.
● Além de testar se um componente para reutilização faz o que você
precisa, talvez seja necessário verificar se o componente não inclui
nenhum código mal-intencionado ou funcionalidade que você não
precisa.
Desenvolvimento com Reuso
● Em 1996, o primeiro voo de teste do foguete Ariane 5 terminou em
desastre quando o lançador saiu do controle 37 segundos após decolar.
● O problema foi devido a um componente reutilizado de uma versão
anterior do lançador (o Sistema de Navegação Inercial) que falhou porque
as suposições feitas quando esse componente foi desenvolvido não
foram válidas para o Ariane 5.
● A funcionalidade que falhou neste componente não era necessária no
Ariane 5.
Desenvolvimento com Reuso
● Sistemas legados existentes que preenchem uma função comercial útil
podem ser reempacotados como componentes para reutilização.
● Isso envolve a gravação de um componente wrapper que implementa
fornece e requer interfaces, em seguida, acessa o sistema legado.
● Embora caro, isso pode ser muito menos caro do que reescrever o
sistema legado.
Referências
Capítulo 16
SOMMERVILLE, Iam. Engenharia de Software. 10 ed. São Paulo: Pearson,
2019. 768 p.

Enterprise Java Beans: https://www.devmedia.com.br/enterprise-

javabeans/26402
Exercício
1. Por que é importante que sejam definidas interfaces para os serviços fornecidos e requeridos por componentes
de software?
2. Quais são as diferenças fundamentais entre componentes como elementos de programa e componentes com
serviços?
3. Considerando os seguintes princípios:
○ Remova os métodos específicos da aplicação, eles devem ser movidos para seu local de contexto.
○ Altere os nomes de métodos para torná-los gerais.
○ Torne o lançamento e/ou tratamento de exceções consistente.
○ Adicione uma interface de configuração para adaptação de componentes.
○ Integre os componentes necessários para reduzir dependências.
Desenhe diagramas de blocos simples para organizar um sistema de gerência de um hospital. Pense que o hospital
deve ter os seguintes subsistemas: gerência de funcionários, gerência de pacientes (registros de consultas,
internações, cirurgias, histórico médico), contabilidade, gerência de uso de quartos/salas. Todos esses sistemas
precisam ser integrados e trocar informações entre si (e.g., o paciente precisa pagar o plano/consulta/internação,
médicos precisam tratar pacientes em determinadas salas).