Arquitetura baseada em componentes
A arquitetura baseada em componentes se concentra na decomposição do design em componentes funcionais ou lógicos individuais que representam interfaces de comunicação bem definidas contendo métodos, eventos e propriedades. Ele fornece um nível mais alto de abstração e divide o problema em subproblemas, cada um associado a partições de componentes.
O objetivo principal da arquitetura baseada em componentes é garantir component reusability. Um componente encapsula a funcionalidade e os comportamentos de um elemento de software em uma unidade binária reutilizável e auto-implantável. Existem muitas estruturas de componentes padrão, como COM / DCOM, JavaBean, EJB, CORBA, .NET, serviços da web e serviços de grade. Essas tecnologias são amplamente utilizadas no design de aplicativos GUI de desktop local, como componentes gráficos JavaBean, componentes MS ActiveX e componentes COM que podem ser reutilizados simplesmente arrastando e soltando.
O design de software orientado a componentes tem muitas vantagens sobre as abordagens tradicionais orientadas a objetos, como -
Tempo de mercado reduzido e custo de desenvolvimento com a reutilização de componentes existentes.
Maior confiabilidade com a reutilização dos componentes existentes.
O que é um componente?
Um componente é um conjunto modular, portátil, substituível e reutilizável de funcionalidade bem definida que encapsula sua implementação e a exporta como uma interface de nível superior.
Um componente é um objeto de software, destinado a interagir com outros componentes, encapsulando certa funcionalidade ou um conjunto de funcionalidades. Ele tem uma interface obviamente definida e está em conformidade com um comportamento recomendado comum a todos os componentes de uma arquitetura.
Um componente de software pode ser definido como uma unidade de composição com uma interface especificada contratualmente e dependências de contexto explícitas apenas. Ou seja, um componente de software pode ser implantado de forma independente e está sujeito à composição por terceiros.
Vistas de um componente
Um componente pode ter três visualizações diferentes - visualização orientada a objetos, visualização convencional e visualização relacionada ao processo.
Object-oriented view
Um componente é visto como um conjunto de uma ou mais classes cooperantes. Cada classe de domínio do problema (análise) e classe de infraestrutura (design) são explicadas para identificar todos os atributos e operações que se aplicam à sua implementação. Também envolve definir as interfaces que permitem às classes se comunicarem e cooperarem.
Conventional view
É visto como um elemento funcional ou um módulo de um programa que integra a lógica de processamento, as estruturas de dados internas que são necessárias para implementar a lógica de processamento e uma interface que permite que o componente seja chamado e os dados sejam passados para ele.
Process-related view
Nesta visualização, em vez de criar cada componente do zero, o sistema está construindo a partir de componentes existentes mantidos em uma biblioteca. Conforme a arquitetura do software é formulada, os componentes são selecionados da biblioteca e usados para preencher a arquitetura.
Um componente de interface de usuário (IU) inclui grades, botões chamados de controles e componentes de utilitários que expõem um subconjunto específico de funções usadas em outros componentes.
Outros tipos comuns de componentes são aqueles que consomem muitos recursos, não são acessados com frequência e devem ser ativados usando a abordagem just-in-time (JIT).
Muitos componentes são invisíveis, os quais são distribuídos em aplicativos de negócios corporativos e aplicativos da web da Internet, como Enterprise JavaBean (EJB), componentes .NET e componentes CORBA.
Características dos Componentes
Reusability- Os componentes geralmente são projetados para serem reutilizados em diferentes situações em diferentes aplicações. No entanto, alguns componentes podem ser projetados para uma tarefa específica.
Replaceable - Os componentes podem ser substituídos livremente por outros componentes semelhantes.
Not context specific - Os componentes são projetados para operar em diferentes ambientes e contextos.
Extensible - Um componente pode ser estendido de componentes existentes para fornecer um novo comportamento.
Encapsulated - O componente AA representa as interfaces, que permitem ao chamador usar sua funcionalidade e não expõe detalhes dos processos internos ou quaisquer variáveis internas ou estado.
Independent - Os componentes são projetados para ter dependências mínimas de outros componentes.
Princípios de Design Baseado em Componentes
Um projeto de nível de componente pode ser representado usando alguma representação intermediária (por exemplo, gráfica, tabular ou baseada em texto) que pode ser traduzida em código-fonte. O projeto de estruturas de dados, interfaces e algoritmos deve estar em conformidade com diretrizes bem estabelecidas para nos ajudar a evitar a introdução de erros.
O sistema de software é decomposto em unidades de componentes reutilizáveis, coesivas e encapsuladas.
Cada componente tem sua própria interface que especifica as portas necessárias e as portas fornecidas; cada componente oculta sua implementação detalhada.
Um componente deve ser estendido sem a necessidade de fazer código interno ou modificações de design nas partes existentes do componente.
Os componentes dependem de abstrações não dependem de outros componentes concretos, o que aumenta a dificuldade de dispensabilidade.
Conectores conectavam componentes, especificando e regendo a interação entre os componentes. O tipo de interação é especificado pelas interfaces dos componentes.
A interação de componentes pode assumir a forma de invocações de método, invocações assíncronas, transmissão, interações orientadas por mensagem, comunicações de fluxo de dados e outras interações específicas de protocolo.
Para uma classe de servidor, interfaces especializadas devem ser criadas para atender às principais categorias de clientes. Apenas as operações que são relevantes para uma determinada categoria de clientes devem ser especificadas na interface.
Um componente pode se estender a outros componentes e ainda oferecer seus próprios pontos de extensão. É o conceito de arquitetura baseada em plug-ins. Isso permite que um plugin ofereça outra API de plugin.
Diretrizes de projeto em nível de componente
Cria uma convenção de nomenclatura para componentes que são especificados como parte do modelo de arquitetura e, em seguida, refina ou elabora como parte do modelo de nível de componente.
Obtém nomes de componentes de arquitetura do domínio do problema e garante que eles tenham significado para todos os envolvidos que visualizam o modelo de arquitetura.
Extrai as entidades de processos de negócios que podem existir independentemente, sem qualquer dependência associada a outras entidades.
Reconhece e descobre essas entidades independentes como novos componentes.
Usa nomes de componentes de infraestrutura que refletem seu significado específico de implementação.
Modela todas as dependências da esquerda para a direita e a herança de cima (classe base) para baixo (classes derivadas).
Modele quaisquer dependências de componente como interfaces em vez de representá-las como uma dependência direta de componente a componente.
Conduzindo Projeto em Nível de Componente
Reconhece todas as classes de design que correspondem ao domínio do problema, conforme definido no modelo de análise e no modelo de arquitetura.
Reconhece todas as classes de design que correspondem ao domínio da infraestrutura.
Descreve todas as classes de design que não são adquiridas como componentes reutilizáveis e especifica os detalhes da mensagem.
Identifica interfaces apropriadas para cada componente e elabora atributos e define tipos de dados e estruturas de dados necessários para implementá-los.
Descreve o fluxo de processamento em cada operação em detalhes por meio de pseudocódigo ou diagramas de atividades UML.
Descreve fontes de dados persistentes (bancos de dados e arquivos) e identifica as classes necessárias para gerenciá-los.
Desenvolve e elabora representações comportamentais para uma classe ou componente. Isso pode ser feito elaborando os diagramas de estado UML criados para o modelo de análise e examinando todos os casos de uso que são relevantes para a classe de design.
Elabora diagramas de implantação para fornecer detalhes adicionais de implementação.
Demonstra a localização dos principais pacotes ou classes de componentes em um sistema usando instâncias de classe e designando hardware específico e ambiente de sistema operacional.
A decisão final pode ser feita usando princípios e diretrizes de design estabelecidos. Designers experientes consideram todas (ou a maioria) das soluções alternativas de design antes de se decidir pelo modelo de design final.
Vantagens
Ease of deployment - À medida que novas versões compatíveis se tornam disponíveis, é mais fácil substituir as versões existentes sem impacto nos outros componentes ou no sistema como um todo.
Reduced cost - O uso de componentes de terceiros permite distribuir os custos de desenvolvimento e manutenção.
Ease of development - Os componentes implementam interfaces conhecidas para fornecer funcionalidade definida, permitindo o desenvolvimento sem impactar outras partes do sistema.
Reusable - O uso de componentes reutilizáveis significa que eles podem ser usados para distribuir o custo de desenvolvimento e manutenção em vários aplicativos ou sistemas.
Modification of technical complexity - Um componente modifica a complexidade por meio do uso de um contêiner de componente e seus serviços.
Reliability - A confiabilidade geral do sistema aumenta, pois a confiabilidade de cada componente individual aumenta a confiabilidade de todo o sistema por meio da reutilização.
System maintenance and evolution - Fácil de alterar e atualizar a implementação sem afetar o resto do sistema.
Independent- Independência e conectividade flexível de componentes. Desenvolvimento independente de componentes por diferentes grupos em paralelo. Produtividade para o desenvolvimento de software e futuro desenvolvimento de software.