Arquiteturas de Referência

Definições – IEEE 1471/ISO/IEC 42010:2007 Visão: representação de um software (ou parte) a partir de uma perspectiva particular. coleção de modelos representando a arquitetura do software.

Alguns modelos de arquitetura em múltiplas visões Kruchten 4+1 IEEE 1471 Siemens (Soni et al)

Logical View Relativo principalmente aos requisitos funcionais (o que o software deve fazer). Identificação dos principais pacotes, subsistemas e classes Diagrams mais comuns: UML Class, Package and Sequence diagrams. ER diagrams

Process View Um processo é um grupo de tarefas. A comunicação entre tarefas ocorre de várias formas: síncrona, assíncrona, broadcast, ... A visão de processos preocupa-se com tópicos como: concorrência e distribuição, integridade do software, tolerância a falhas, Como abstrações da visão lógica operam na visão de processos da arquitetura.

Process View Principais estilos: client/server, pipes and filters, publish-subscribe middleware. Essa visão mostra onde e como classes/elementos definidos na visão lógica são usados. Notações usadas: Sequence diagrams, Activity diagrams, Class diagrams (focus on active classes), Components

Implementation/Development view Organização de módulos do software (código, arquivos de dados, componentes, executáveis, bibliotecas,...) Principais elementos: módulos, subsistemas, camadas. Normalmente o estilo é em camadas A visão de desenvolvimento considera requisitos como facilidade de desenvolvimento, e restrições do ambiente de desenvolvimento e da linguagem

Implementation/Development view A visão de desenvolvimento é a base para: alocação de requisitos e de trabalho entre equipes Avaliação de custos Monitoração do projeto Reuso, portabilidade e segurança.

Physical/Deployment View Elementos identificados: redes, processadores, tarefas, objetos, e o mapeados em vários nós. Várias configurações físicas diferentes podem ser usadas: algumas para desenvolvimento e testes, outras para a implantação do software em diferentes locais/clientes. Mostra como os vários executáveis e componentes são mapeados para plataformas e nós físicos Mostra distribuição física de elementos do sistema Notações: proprietária, pacotes, nós, UML deployment diagram

Scenario/Use Case View Mostra como os elementos das 4 visões trabalham juntos. Notações: Use Cases Linguagem natural Pode-se especificar os use-cases com diagramas UML (Sequência, Atividades) Principais objetivos: Direção para descobrir os elementos da arquitetura Validação e ilustração da arquitetura do software Ponto de partida para desenvolvimento e testes

ANSI-IEEE 1471-2000/ ISO/IEC 42010:20Systems and Software Engineering -- Recommended practice for architectural description of software-intensive systems 07

Análise do Framework Um sistema existe em um ambiente (contexto). O ambiente do sistema pode influenciar o sistema. O ambiente determina as circunstâncias de desenvolvimento, operacionais, e políticas. O ambiente determina os limites que definem o escopo do sistema em relação a outros sistemas. Um sistema possui um ou mais stakeholders. Cada stakeholder tipicamente possui interesses (concerns) no sistema. Um sistema existe para realizar uma ou mais missões. Todo sistema possui uma arquitetura. Uma arquitetura (conceito) é estabelecida por uma descrição de arquitetura (produtos concretos).

Exemplo

Quantas visões? Nem todo software precisa de todas as 5 visões do 4+1 Nem todo software precisa de várias visões Ex. Um único processador → não precisa da visão de deployment Um único processo → não precisa da visão de processos

Siemens Diferentes estruturas são usadas em diferentes fases do processo de desenvolvimento. A arquitetura conceitual descreve o sistema em termos dos principais elementos de design e suas relações A arquitetura de interconexão de módulos é composta por duas estruturas ortogonais: decomposição funcional e camadas. A arquitetura de execução descreve a estrutura dinâmica de um sistema. A arquitetura de código descreve as bibliotecas e o código fonte organizados no ambiente de desenvolvimento.