Brincando com LEGO! O que são componentes em uma arquitetura de software.

Olá pessoal, tudo certo?!

Com frequência, quando me solicitam uma definação para arquitetura de software, repito quase sem pensar:

Arquitetura de Software é a definição dos componentes de um sistema, seus papéis, relacionamentos e responsabilidades.

Mas, o que quero dizer com componentes?! Esse é o tema do post de hoje.

Para entrar no clima

As decisões que compreendem a arquitetura de um software abrangem a interação rica e a composição de muitos elementos diferentes. Estes elementos tratam de aspectos centrais do software, incluindo:

• Processamento, (aka funcionalidade ou comportamento);
• Estado, (aka informação ou dados);
• Interação, (aka interconexão, comunicação, coordenação ou mediação).

Elementos que encapsulam o processamento e os dados na arquitetura de um sistema são componentes.

Ou, em uma inversão simples

Componentes de software são os elementos da arquitetura que encapsulam os estado e/ou processamento do sistema.

A interação entre os componentes é realizada atrávés conectores (outro conceito-chave, volto a ele em um post futuro).

 

Analogia com blocos de LEGO

Gosto bastante de pensar em componentes de software como “blocos de LEGO”.

Ou seja, pequenas “partes”, extremamente bem-definidas, que podem ser combinadas em diferentes “sistemas” mais complexos.

 

Vejamos um pouco mais do conceito para ver como essa analogia se encaixa (estou pândego hoje)

Definição (um pouco mais) formal para componente

Um componente de software é uma entidade arquitetural que :

1. encapsula um subconjunto de funcionalidades do sistema e/ou dados;
2. restringe acesso para este subconjunto via uma interface explicitamente definida;
3. tem dependências explicitamente definidas em seu contexto de execução.

Colocado de outra forma, um componente de software é uma “consolidação” de computação e estado em um sistema.

Qual o “tamanho ideal” de um componente

Um componente pode ser tão simples como uma única operação ou tão complexo quanto um sistema inteiro. Isso depende:

• da arquitetura;
• da perspectiva adotada (tema para outro post);
• das necessidades do sistema.

O único aspecto-chave de qualquer componente é que este só pode ser “visto” por seus usuários, humanos ou software, apenas do lado de fora, e somente via o que sua interface define como público. Em outras palavras, um componente deve ser uma “caixa preta”.

Como orientação geral,

Componetes de software devem ser tão grandes quanto possível. Entretanto, devem ser uma “visão concreta”  dos princípios de abstração, encapsulamento e modularidade.

Relações de um componente com seu contexto

Componentes de software se tornam (re)utilizáveis em várias aplicações conforme a qualidade do tratamento explícito destinado ao contexto de execução necessário.

Quanto ao contexto, me refiro a:

• Interfaces necessárias para o funcionamento do componente. Isto é, as interfaces dos demais serviços em um sistema;
• Disponibilidade de determinados recursos, tais como arquivos de dados ou diretórios;
• Softwares necessários, tais como ambientes de execução, middleware, sistemas operacionais, protocolos de rede, drivers de dispositivos, etc;
• Configurações necessárias de hardware para executar o componente.

Ao projetar um componente, é necessário considerar fortemente seu contexto de execução.

Relação de componentes e aplicações

Outro aspecto a considerar em um componente de software é a relação deste com uma aplicação em que seja utilizado. Componentes são frequentemente dirigidos ao processamento e gestão de dados necessários para uma aplicação em particular; isto é, eles são ditos “específicos para a aplicação”.

Esta característica pode não estar presente sempre. Algumas vezes, componentes são projetados para atender as necessidades de diversas aplicações que compartilhem um mesmo domínio. Neste caso, são ditos “específicos para o domínio”.

Finalmente, certos componentes de software são utilitários que são necessários e podem ser reutilizados em muitas aplicações, sem atender a uma característica específica do domínio. Nesse caso, são ditos “utilitários”.

Concluindo …

• Fracione sua aplicação em componentes com “processamento” e/ou estado independentes;
• Faça os seus componentes tão grandes quanto possível sem sacrificar os princípios de abstração, encapsulamento e modularidade;
• Defina interfaces claras e “fixas”;
• Considere cuidadosamente a demanda por serviços externos, consumo de recursos (software e hardware);
• Classifique seu componente como “específicos da aplicação”, “específicos de domínio” ou “utilitários” tão cedo quanto possível;
• Favoreça o desenvolvimento de componentes “específicos de domínio” visando favorecer a reutilização.

Por hoje, era isso.