Conceito: Arquitetura de Sistema

Introdução

O termo arquitetura é, hoje em dia, amplamente utilizado fora de sua conotação tradicional de construção e existem muitas definições de "arquitetura" (no contexto de sistemas) e "arquitetura de sistema (ou sistemas)", por exemplo:

"Arquitetura de sistemas: a estrutura fundamental e unificadora do sistema definida sob o ponto de vista de elementos do sistema, interfaces, processos, restrições e comportamentos."
[definição de linha de base aprovada pelo Grupo de Trabalho de Arquitetura de Sistemas INCOSE na INCOSE '96 em Boston, MA, em 8 de julho de 1996]

"A arquitetura de sistema inclui as principais propriedades físicas, estilo, estrutura, interações e finalidade de um sistema."
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

"Arquitetura: os conceitos e regras que definem a estrutura, o comportamento semântico e os relacionamentos entre as partes de um sistema; um plano de algo a ser construído. Inclui os elementos que constituem o fato, os relacionamentos entre esses elementos, as restrições que afetam esses relacionamentos, um foco nas partes do fato e um foco no fato como um todo."
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, que referencia o ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations como a origem]

"Arquitetura: a estrutura de componentes em um programa/sistema, seus inter-relacionamentos e os princípios e diretrizes que controlam o design e a evolução ao longo do tempo."
[DoD 5000.59-P, "Modeling and Simulation Master Plan," Outubro de 1995]

Uma arquitetura é "a estrutura dos componentes, seus relacionamentos e os princípios e diretrizes que controlam o design e a evolução ao longo do tempo."
[IEEE STD 610.12, um pouco estendido pelo IAP (Integrated Architectures Panel) do C4ISR ITF (Integration Task Force) em DoD Architecture Framework, Versão 1.0]

Diferentes palavras e construções são utilizadas, e nem todas as definições abrangem exatamente os mesmos aspectos, mas existem sobreposições significativas. Essas definições mostram que a arquitetura de sistema trata-se do seguinte:

a estrutura do sistema em termos dos elementos, componentes e peças
os relacionamentos entre esses elementos
as restrições que afetam os elementos e seus relacionamentos
o comportamento mostrado pelo sistema e as interações que ocorrem entre os elementos para produzir esse comportamento
os princípios, regras e análise racional que caracterizam o sistema (e controlam sua evolução)
as características e propriedades físicas e lógicas do sistema
a finalidade do sistema

Portanto, a propagação completa de todos esses aspectos requer um rico e potencialmente complexo conjunto de informações, mas é necessário estar ciente de que nem todos os envolvidos precisam considerar ou compreender todos os aspectos simultaneamente. O conceito de pontos de vista permite a separação dessas diversas preocupações e a apresentação para uma classe de envolvidos apenas do que eles precisam para participação efetiva. Na perspectiva de um ponto de vista específico, você também pode visualizar o sistema em diferentes "resoluções", da baixa resolução, correspondente a um alto nível de abstração, à alta resolução, correspondente a uma especificação concreta (de partes, etc) para implementação.

Pontos de Vista

Um ponto de vista (em um sistema) é "uma forma de abstração alcançada utilizando um conjunto selecionado de conceitos arquiteturais e regras de estruturação, para manter o foco em preocupações específicas em um sistema" [ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations]. A tabela lista alguns pontos de vista escolhidos para capturar as diversas preocupações. Esses pontos de vista são alinhados com aqueles localizados em ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview.

Ponto de Vista	Preocupação	Impacto
Trabalhador	Trata das funções e responsabilidades dos trabalhadores da organização e do sistema (e as políticas que as afetam).	Atividades do trabalhador, interação humana/sistema. Especificação de desempenho humano e fatores humanos.
Informações	Os tipos de informações manipuladas pelo sistema e as restrições sobre o uso e a interpretação dessas informações.	Integridade de informações, limitações de capacidade. Acessibilidade às informações, oportunidade.
Lógico	A decomposição do sistema em um conjunto de subsistemas que interagem em interfaces, trabalhando em conjunto para fornecer os serviços do sistema.	O sistema apresenta o comportamento desejado. O sistema tem capacidade para extensão, adaptação e manutenção. Os recursos são reutilizáveis.
Distribuição/Físico	A infra-estrutura necessária para suportar a funcionalidade e a distribuição do sistema	Adequação de características físicas do sistema para hospedar a funcionalidade e atender aos requisitos não funcionais.
Processo	Simultaneidade, escalabilidade, desempenho, rendimento do processamento, confiabilidade.	Adequação do sistema ao pronto atendimento, rendimento do processamento e tolerância a falhas.

Pontos de Vista Comuns do Sistema.

Esses são alguns dos pontos de vista mais comuns para sistemas de software intenso. Muitas arquiteturas de sistema também requerem pontos de vista específicos do domínio adicionais. Exemplos incluem os pontos de vista de privacidade, de segurança e mecânicos. Os pontos de vista representam as diferentes áreas de preocupação que devem ser tratadas na arquitetura e no design do sistema. Se houver envolvidos ou especialistas do sistema cujas preocupações sejam importantes para a arquitetura global, provavelmente haverá a necessidade de um conjunto de produtos de trabalho de ponto de vista para capturar suas decisões de design.

É importante construir uma equipe de arquitetura de sistema que seja competente para cuidar dos diversos pontos de vista. A equipe pode ser composta de analistas de negócios e usuários que assumem a responsabilidade primária do ponto de vista do trabalhador, arquitetos de software que atendam ao ponto de vista lógico e engenheiros que se preocupem com o ponto de vista físico, bem como especialistas em pontos de vista específicos do domínio.

Níveis de Abstração

Além dos pontos de vista, uma arquitetura de sistema requer níveis de especificação. À medida que é desenvolvida, a arquitetura evolui de uma especificação geral e abstrata para uma especificação detalhada e mais específica. O RUP identifica quatro níveis de arquitetura, como mostra a tabela a seguir.

Nível do Modelo	Expressa
Contexto	O sistema e seus agentes.
Análise	Particionamento inicial do sistema para estabelecer a abordagem conceitual.
Design	Realização do Modelo de Análise para hardware, software e pessoas.
Implementação	Realização do Modelo de Design para configurações específicas.

Níveis de Arquitetura do RUP

Através desses níveis, o design passa do abstrato para o físico. O Modelo de Contexto captura todas as entidades externas (agentes) que interagem com o sistema. Esses agentes podem ser externos para a empresa que implementa o sistema ou podem ser internos para a empresa. Em ambos os casos, os agentes podem ser trabalhadores humanos ou outros sistemas. No nível de Análise, as partições não refletem escolhas de hardware, software e pessoas. Em vez disso, elas refletem abordagens de design para separar o que o sistema precisa fazer e como o esforço deve ser distribuído. No nível de Design, as decisões são tomadas quanto aos tipos de componentes de hardware e software e quanto às funções do trabalhador que são necessárias. No nível de Implementação, escolhas específicas de tecnologia de hardware e software são feitas para implementar o design. Por exemplo, no nível de Design, um servidor de dados poderia ser especificado. No nível de Implementação, a decisão é tomada para utilizar uma plataforma específica que esteja executando um aplicativo de banco de dados específico.

Modelos e Diagramas

Um modelo é uma representação de um sistema, normalmente tratando de alguma área específica de preocupação. Por conseguinte, um sistema é geralmente representado por um conjunto de modelos, pois há várias preocupações relativas ao desenvolvimento ou uso do sistema. Cada modelo pode ser construído com níveis variados de abstração, do mais geral, ocultando ou encapsulando detalhes, ao mais específico, expondo decisões de design mais explícitas e detalhadas.

Um ponto de vista, como o nome diz, é uma "posição" nocional a partir da qual alguns aspectos ou preocupações com o sistema ficam visíveis, envolvendo a aplicação de um conjunto de conceitos e regras para formar um filtro conceitual. Em geral, não é suficiente (para compreensão) examinar simplesmente o sistema; os modelos terão sido (ou terão que ser) construídos para representar e descrever as preocupações.

As visualizações são projeções de modelos que mostram entidades relevantes de um ponto de vista específico. Essas projeções são geralmente ilustradas por diagramas de algum tipo.

A interseção do nível de abstração ou especificidade do ponto de vista e do modelo contém (ou pelo menos identifica) visualizações de um ou mais modelos relevantes a esse ponto de vista ou preocupação, nesse nível de abstração.

A arquitetura de sistema é, então, capturada em um conjunto de modelos (e diagramas que os visualizam) que expressam a arquitetura de vários pontos de vista e níveis. Conforme mostrado na tabela de estruturas de modelo a seguir, não existe um modelo/diagrama para toda combinação no nível do ponto de vista. No nível da Implementação, um modelo único captura a realização dos componentes de hardware e software para cada configuração do sistema.

Nível do Modelo	Pontos de Vista
Nível do Modelo	Trabalhador	Lógico	Informações	Distribuição/Físico	Processo
Contexto	Visualização da Organização UML	Diagrama do Contexto do Sistema	Visualização dos Dados Corporativos	Visualização da Localidade Corporativa	Visualização do Processo de Negócios
Análise	Visualização do Trabalhador do Sistema Generalizado	Visualização do Subsistema	Visualização dos Dados do Sistema	Visualização da Localidade do Sistema	Visualização do Processo do Sistema
Design	Visualização do Trabalhador do Sistema	Visualizações da Classe de Subsistema Visualizações do Componente de Software	Esquema de Dados do Sistema	Visualização do Nó do Descritor	Visualização do Processo Detalhado
Implementação	Especificações e Instruções da Função do Trabalhador	Configurações: diagramas de implementação com componentes do sistema de software e hardware.

Muitas das visualizações especificadas na tabela são derivadas dos modelos UML padrão. Por exemplo, no nível de Análise do ponto de vista Lógico, o sistema é decomposto em subsistemas que trabalham em conjunto para atender aos requisitos do usuário. Os subsistemas são utilizados com a mesma semântica que aquela no padrão UML. Esses subsistemas, por sua vez, são decompostos em subsistemas ou (no nível mais básico) classes. O nível de Design do ponto de vista Lógico é a visualização do Modelo de Classe detalhado. O Modelo de Processo também é um modelo de classe UML padrão, com o foco em classes ativas no sistema. Os pontos de vista específicos do domínio também precisam ter visualizações de produtos de trabalho no local para um ou mais níveis. O conjunto de produtos de trabalho do projeto, nesta estrutura, precisa ser uma parte do caso de desenvolvimento do projeto.