Descrição de Arquitetura de Software
Pontos principais
- A norma ISO/IEC/IEEE 42010 padroniza a descrição de arquitetura de software.
- A distinção entre 'visão' (o artefato) e 'ponto de vista' (a convenção) é central para a comunicação com múltiplos stakeholders.
- A SAD não aborda apenas questões técnicas, mas também custos, cronogramas e processos de negócio.
- A modelagem de arquitetura evoluiu de diagramas informais para linguagens formais e frameworks estruturados.
A Descrição de Arquitetura de Software (SAD, do inglês Software Architecture Description) compreende o conjunto de práticas utilizadas para expressar, comunicar e analisar a arquitetura de um sistema de software. De acordo com a norma ISO/IEC/IEEE 42010, a SAD é tanto o processo de aplicação dessas práticas quanto o produto resultante (o documento ou artefato) que expressa a arquitetura do sistema.
Frequentemente referida como representação, especificação ou documentação de arquitetura, a SAD serve como a ponte entre os requisitos de negócio e a implementação técnica, permitindo que diferentes partes interessadas compreendam a estrutura e o comportamento do sistema.
Conceitos Fundamentais
A descrição de arquitetura é essencialmente uma atividade de modelagem. Os arquitetos de software utilizam diversas técnicas e representações para registrar a arquitetura, que podem assumir formas variadas, como textos, desenhos informais, diagramas ou formalismos rigorosos baseados em linguagens de modelagem.
Stakeholders e Preocupações
Uma SAD raramente utiliza um único modelo, pois deve atender a múltiplos stakeholders (partes interessadas), como usuários finais, proprietários do sistema, desenvolvedores, engenheiros de sistemas e gerentes de projeto. Cada grupo possui preocupações (concerns) distintas, tais como:
- Funcionalidade: O que o sistema deve fazer.
- Segurança e Confiabilidade: Como o sistema evita falhas e protege dados.
- Escalabilidade: A capacidade de suportar o crescimento da carga de trabalho.
- Entrega e Custos: Prazos de implementação e viabilidade financeira.
Visões e Pontos de Vista (Views and Viewpoints)
Para gerenciar a complexidade, as descrições de arquitetura são organizadas em visões (views). Uma visão é a representação de um sistema que aborda preocupações específicas de interesse para determinados stakeholders.
Cada visão é baseada em um ponto de vista (viewpoint). Enquanto a visão é o artefato final, o ponto de vista é a especificação ou o "molde" que define as notações, convenções de modelagem e as técnicas que devem ser utilizadas para criar aquela visão específica.
Um desafio inerente ao uso de múltiplas visões é a consistência. Como as visões não são independentes, pode haver redundância ou contradições entre elas. Para mitigar isso, são utilizados mecanismos de correspondência para garantir que a alteração em uma visão seja refletida nas demais.
Evolução Histórica
Inicialmente, as descrições de arquitetura baseavam-se em desenhos informais e textos, prática que ainda é amplamente difundida na indústria. A evolução da área foi influenciada por conceitos de Engenharia de Software, como a abstração de dados e a "programação em larga escala" (programming in the large).
O trabalho com linguagens de interconexão de módulos (MILs) focou em propriedades de larga escala, como a definição de módulos (bibliotecas, sub-rotinas, subsistemas) e suas dependências. Essas ideias influenciaram linguagens de programação como Ada e notações de design como a UML (Unified Modeling Language), especificamente em pacotes e subsistemas.
A Contribuição de Perry e Wolf
Inspirando-se na arquitetura de edificações, Perry e Wolf propuseram que a representação de software deveria incluir elementos, forma e justificativa (rationale). Eles distinguiram três tipos de elementos fundamentais:
- Processamento: Como os dados são transformados.
- Dados: A informação utilizada e transformada.
- Conexão: O "adesivo" que mantém os outros elementos unidos.
Segundo os autores, a descrição de arquitetura deve prescrever restrições sem superespecificar a solução, separar a estética da engenharia e permitir a análise de dependências e consistência.
Mecanismos de Descrição de Arquitetura
Para evitar a reinvenção de processos a cada novo projeto, a engenharia de software utiliza mecanismos que facilitam a reuso de estilos de descrição:
- Pontos de Vista de Arquitetura: Definições padronizadas de como olhar para o sistema.
- Linguagens de Descrição de Arquitetura (ADLs): Linguagens formais projetadas especificamente para representar estruturas arquiteturais.
- Frameworks de Arquitetura: Estruturas organizacionais que fornecem modelos e diretrizes para a criação de SADs.
Perguntas frequentes
O que é uma Descrição de Arquitetura de Software (SAD)?
É o conjunto de práticas e o produto resultante (documentação) que expressam a arquitetura de um sistema de software, permitindo a comunicação e análise entre stakeholders.
Qual a diferença entre 'Visão' e 'Ponto de Vista' na arquitetura de software?
O Ponto de Vista (Viewpoint) é a especificação ou template que define as regras e notações; a Visão (View) é a aplicação desse template ao sistema real, resultando em um diagrama ou documento específico.
A SAD serve apenas para desenvolvedores?
Não. Ela é essencial para diversos stakeholders, incluindo clientes, gerentes de projeto e proprietários do sistema, pois aborda preocupações não técnicas como custos, prazos e viabilidade.
Para que serve a norma ISO/IEC/IEEE 42010?
Ela fornece um padrão internacional para a descrição de arquitetura, definindo conceitos como stakeholders, preocupações, visões e pontos de vista para garantir consistência na documentação.