Arquitertura de Software

Architectural Blueprints —The “4+1” View Model of Software Architecture

Este artigo apresenta um modelo para descrever a arquitectura de sistemas complexos de software, com base na utilização de múltiplos pontos de vista, simultâneas. Este uso de múltiplos pontos de vista permite abordar separadamente as preocupações dos vários 'stakeholders' da arquitetura: o usuário final, desenvolvedores, engenheiros de sistemas, gerentes de projeto, etc., e para lidar separadamente os requisitos funcionais e não funcionais. Cada um dos cinco pontos de vista é descrito, juntamente com uma notação de capturá-lo. As vistas são projetadas usando uma, scenariodriven, processo de desenvolvimento iterativo centrado na arquitetura.

Introdução

Nós todos vimos muitos livros e artigos em que um diagrama tenta capturar a essência da arquitetura de um sistema. Mas olhando atentamente para o conjunto de caixas e setas indicadas nos diagramas, torna-se claro que os seus autores têm lutado duro para representar mais de um modelo do que pode realmente expressar. São as caixas que representam os programas em execução? Ou pedaços de código fonte? Ou computadores físicos? Ou simplesmente agrupamentos lógicas de funcionalidade? São as setas que representam as dependências de compilação? Ou fluxos de controle? Ou fluxos de dados? Normalmente, é um pouco de tudo. Será que uma arquitetura precisa de um único estilo arquitetônico? Às vezes, a arquitetura do software sofre cicatrizes de um projeto de sistema que foram longe demais em prematuramente particionamento do software, ou a partir de uma ênfase exagerada sobre um aspecto de desenvolvimento de software: engenharia de dados, ou de tempo de execução a eficiência, ou estratégia de desenvolvimento e organização da equipe . Muitas vezes, também a arquitectura não aborda as preocupações de todos os seus "clientes" (ou "stakeholders", como são chamados na USC). Este problema tem sido observado por vários autores: Garlan & Shaw1, Abowd & Allen na CMU, Clements na SEI. Como um remédio, propomo-nos a organizar a descrição de uma arquitetura de software usando vários pontos de vista simultâneos, cada um abordando um conjunto específico de preocupações.

Um modelo de arquitetura

A arquitetura de software lida com a concepção e implementação da estrutura de alto nível do software. É o resultado de montagem de certo número de elementos arquitectónicos em algumas formas bem escolhidos para satisfazer os principais requisitos de funcionalidade e desempenho do sistema, bem como alguns outros requisitos, não-funcionais, tais como confiabilidade, escalabilidade, portabilidade e disponibilidade . Perry e Wolfe colocá-lo muito bem neste formula2, modificado por Boehm: Arquitetura de Software = {elementos, formulários, Fundamentação / Restrições} arquitetura de software lida com abstração, com decomposição e composição, com estilo e estética. Para descrever uma arquitetura de software, nós usamos um modelo composto de vários pontos de vista ou perspectivas. A fim de, eventualmente, tratar arquiteturas grandes e desafiadores, o modelo que propomos é composta por cinco principais pontos de vista:
• A visão lógica, que é o modelo de objeto do projeto (quando um método de design orientado a objeto é usado),
• a visão de processo, que capta os aspectos de concorrência e sincronização do design,
• o ponto de vista físico, que descreve o mapeamento (s) do software para o hardware e reflecte o seu aspecto distribuído,

• o ponto de vista de desenvolvimento, que descreve a organização estática do software em seu ambiente de desenvolvimento.

A descrição de uma arquitectura de as decisões tomadas, pode ser organizado em torno desses quatro pontos de vista, e, em seguida, ilustrado por alguns casos de uso ou cenários selecionados, que se tornam um quinto vista. A arquitetura é, de facto, parcialmente evoluído a partir desses cenários, como veremos mais tarde. Nós aplicamos a equação de Perry & lobo independentemente em cada ponto de vista, ou seja, para cada vista, definimos o conjunto de elementos a usar (componentes, recipientes, e conectores), nós capturamos as formas e padrões que funcionam, e nós capturar a lógica e os constrangimentos, ligar a arquitectura para alguns dos requisitos. Cada vista é descrito por um modelo utilizando a sua própria notação particular. Para cada ponto de vista também, os arquitetos podem escolher certo estilo arquitetônico, permitindo assim a coexistência de vários estilos em um único sistema.

Vamos agora olhar em volta em cada um dos cinco pontos de vista, dando para cada seu propósito: o que preocupa é endereços, uma notação para o projeto arquitetônico correspondente, as ferramentas que usamos para descrever e gerenciá-lo. Pequenos exemplos são extraídos do projeto de um PABX, derivado do nosso trabalho na Alcatel Negócios Sistema e um system3 Controle de Tráfego Aéreo, mas em muito simplificada forma-a intenção aqui é apenas para dar um sabor de
os pontos de vista e sua notação e não para definir a arquitetura desses sistemas.

O "4 + 1" modelo de exibição é bastante "genérico": outras notações e ferramentas podem ser usadas, outros métodos de design pode ser usado, especialmente para o e as decomposições lógicas e de processo, mas nós indicamos as que usaram com sucesso .

A arquitetura lógica

A decomposição A arquitetura lógica orientada a objetos suporta principalmente os requisitos funcionais-o que o sistema deve fornecer em termos de serviços aos seus usuários. O sistema é decomposto em um conjunto de abstrações-chave, tomadas (principalmente) de o domínio de problemas, na forma de objectos ou classes de objectos. Eles exploram os princípios da abstração, encapsulamento e herança. Esta decomposição não é apenas para fins de análise funcional, mas também serve para identificar mecanismos comuns e elementos de design entre as várias partes do sistema. Nós usamos a abordagem Rational / Booch para representar a arquitetura lógica, por meio de diagramas de classe e classe templates. 4 Um diagrama de classes mostra um conjunto de classes e suas relações lógicas: associação, uso, composição, herança e assim por diante. Conjuntos de classes relacionadas podem ser agrupados em categorias de classe. Modelos de classe concentrar em cada classe individual; eles enfatizam as principais operações de classe, e identificar as principais características do objeto. Se for importante para definir o comportamento interno de um objecto, isto é feito com a transição de estado diagramas, gráficos ou estaduais. Mecanismos ou serviços comuns são definidos de utilitários de classe. Como alternativa a uma abordagem OO, uma aplicação que é orientada dados muito pode usar alguma outra forma de vista lógico, tais como diagramas ER.