modelos de design arquitetural - dimap.ufrn.brjair/as/slides/modelosdesignarquitet... · •refinar...

13
1 Modelos de design arquitetural Jair C Leite Arquitetura de Software, © Jair C Leite Modelos de design arquitetural • Objetivo Guiar o arquiteto nas etapas para desenhar a arquitetura Deve considerar diferentes visões arquiteturais Atualmente existem diferentes modelos de design que consideram Domínios de aplicação Família de produtos – Etc. Os diferentes modelos possuem características

Upload: truongtuyen

Post on 05-Dec-2018

216 views

Category:

Documents


0 download

TRANSCRIPT

1

Modelos de design arquitetural

Jair C Leite

Arquitetura de Software, © Jair C Leite

Modelos de design arquitetural

• Objetivo– Guiar o arquiteto nas etapas para desenhar a

arquitetura• Deve considerar diferentes visões arquiteturais• Atualmente existem diferentes modelos de

design que consideram– Domínios de aplicação– Família de produtos– Etc.

• Os diferentes modelos possuem características

2

Arquitetura de Software, © Jair C Leite

Modelos

• Exemplos de métodos com aplicação naindústria– Attribute-Driven Design (ADD) Method (Bass et al.,

2003)– Siemens’ 4 Views (S4V) method (Hofmeister et al.,

1999)– Rational Unified Process 4 + 1 views (RUP 4 + 1)

(Kruchten, 1995, 2003)– Business Architecture Process and Organization

(BAPO) – Philips Research (America et al.,2003;Obbink et al., 2000)

– Architectural Separation of Concerns (ASC) –Nokia (Ran, 2000)

Arquitetura de Software, © Jair C Leite

Attribute-Driven Design (ADD)

• Desenvolvido pelo grupo do SEI (SoftwareEngineering Institute).

• Processo recursivo de decomposição.• A cada etapa táticas e padrões são escolhidos

para satisfazer atributos de qualidade.• As visões são escolhidas de acordo com as

características do projeto.– Visão de módulo– Visão de concorrência– Visão decomposição

3

Arquitetura de Software, © Jair C Leite

Etapas do ADD

• Escolher o módulo para decompor. A decomposiçãodeve ser baseada em restrições, requisitos funcionais enão-funcionais (qualidades).

• Refinar o módulo de acordo com os seguintes passos:– Escolher direcionadores a partir de cenários concretos de

atributos de qualidade– Escolher um padrão arquitetural que satisfaça os

direcionadores. Os padrões são baseados em táticas.– Instanciar módulos e alocar funcionalidade a partir de casos de

uso. Representar os resultados nas diferentes visões.– Definir interfaces e restrições de interação dos módulos filhos– Verificar e refinar os casos de uso e atributos de qualidade para

os módulos filhos, preparando-os para decomposição.• Repetir os passos acima para todos os módulos que

necessitem de decomposição.

Arquitetura de Software, © Jair C Leite

Visão geral do ADD

4

Arquitetura de Software, © Jair C Leite

ADD e outros métodos do SEI

• ADD não é um método de desenvolvimento completo.• Ele é utilizado com outros métodos do SEI que

complementam o processo de software.

Arquitetura de Software, © Jair C Leite

Outros métodos do SEI

• QAW - Quality Attribute Workshop– Ajuda na compreensão do problema através da

eliciação de requisitos de qualidade na forma decenários de atributos de qualidade.

• VaB - The Views and Beyond– Abordagem para a documentação da arquitetura

utilizando visões de acordo com as necessidades dosenvolvidos.

• ATAM - Architecture Tradeoff Analysis Method– Provê um guia detalhado para análise da arquitetura

e obter um feedback antecipado sobre riscos.

5

Arquitetura de Software, © Jair C Leite

Método Siemens’ 4 Views (S4V)

• Desenvolvido pela Siemens CorporationResearch

• Baseado nas melhores práticas arquiteturaispara sistemas industriais

• As 4 visões são:– Visão conceitual– Visão de módulo– Visão de código– Visão de execução

• As 4 visões separam diferentes aspectos deengenharia para reduzir a complexidade datarefa do arquiteto.

Arquitetura de Software, © Jair C Leite

Etapas do S4V

• Análise Global– Identificar e analisar fatores– Explorar desafios e aspectos chaves– Elaborar estratégias de design para solucionar os

desafios e aspectos• Aplicar estratégias e avaliar decisões de design

– As decisões devem ser avaliadas para evitar conflitose interações inesperadas com desafios e aspectos

– Design e avaliação são atividades entrelaçadas• Estas atividades acontecem para cada visão

arquitetural

6

Arquitetura de Software, © Jair C Leite

Análise Global

• Fatores– Requisitos que influenciam a arquitetura– Qualidades desejáveis e não cobertas pela

especificação de requisitos• Categorias de fatores

– Organizacionais• Políticas, normas e outras restrições organizacionais

– Tecnológicos• Disponibilidade e limitações tecnológicas

– Produto• Qualidades do produto

Arquitetura de Software, © Jair C Leite

Identificar desafios e aspectos chave

• É difícil dar conta do conjunto de fatoresidentificados com um todo.

• Aspectos chaves dos fatores– Conflitos– Falta de flexibilidade– Alta mutabilidade– Impacto global

7

Arquitetura de Software, © Jair C Leite

Design e avaliação

• Estratégias de design são elaboradas para solucionar osdesafios e aspectos chaves

• Estratégias são:– Princípios de engenharia de software

• Escondendo informação, alta-coesão e baixo-acomplamento– Heurísticas– Estilos e padrões

• Camadas, Tubos e filtros, MVC, Blackboard• As estratégias devem ser aplicadas às visões

arquiteturais• A aplicação de uma estratégia a uma determinada visão

é uma ‘decisão de design’• Avaliação

– Ocorre de forma intercalada com o design– Deve-se avaliar conflitos entre as decisões nas diferentes visões

Arquitetura de Software, © Jair C Leite

Visão geral do S4V

8

Arquitetura de Software, © Jair C Leite

Processo Unificado da Rational (IBM)

•O RUP propõeum processocentralizado naarquitetura.

•Análise edesign daarquitetura sãoatividadesconjuntas

•Uso da UML evisões “4+1”

• Desenvolvido pela IBM/Rational

Arquitetura de Software, © Jair C Leite

Artefatos no design arquitetural do RUP

• O design arquitetural ocorre em várias iteraçõesda fase de elaboração

• O design arquitetural recebe como entrada– O documento de visão do produto– O modelo de casos de uso– A especificação suplementar de requisitos não-

funcionais• Cada iteração deve produzir um protótipo da

arquitetura que será incrementado com asdiferentes visões proporcionadas

• Preenchimento iterativo das visões

9

Arquitetura de Software, © Jair C Leite

O design arquitetural no RUP - fases eartefatos

Primeira arquitetura candidata é produzida

Documento de visãoModelo de casos de uso

Especificação suplementar

Arquitetura de Software, © Jair C Leite

Etapas do design arquitetural no RUP

• Definir uma arquitetura candidata– Baseada em casos de usos significantes.– Utilizando uma arquitetura de referência da organização ou do

domínio.– Elabora-se um protótipo da candidata à qual novos elementos

arquiteturais podem ser empregados• Realizar a síntese arquitetural

– Construir um prova-de-conceito arquitetural– Avaliar viabilidade em relação aos requisitos

• Refinar a arquitetura– Identificar elementos de design

• Classes, processos, etc.– Identificar mecanismos de design

• Padrões arquiteturais e serviços– Revisar a arquitetura

10

Arquitetura de Software, © Jair C Leite

Preenchimento iterativo das visões 4+1

O processo sugere aelaboração de cenários apartir de requisitos (casosde uso) de negócio e desistema.

Com base nos cenários sãoelaborados diagramas deseqüência e colaboração.

Em seguida os diagramasde classes (ainda visãológica) a partir das quaispode-se código fonteorganizados em módulos esub-sistemas.

A visão de processo permite ver aexecução de processos concorrentes ecomo eles estão alocados nos nósprocessadores do sistema (visão deimplantação).

Arquitetura de Software, © Jair C Leite

Business Architecture Process andOrganization (BAPO)• Desenvolvido e praticado pela Phillips Research• Trabalha com 5 visões

– Cliente, Aplicação, Funcional, Conceitual, Realização• Processo iterativo

– Elaborar uma das visões– Analisar atributos de qualidade da visão– Estabelecer ligações entre as visões– Estabelecer ligações com Negócio, Processo e Organização

• A fase de processo considera que a partir da arquiteturapode-se estabelecer o desenvolvimento por linha deprodução

• Ideal para indústrias com famílias de produtos desoftware

11

Arquitetura de Software, © Jair C Leite

BAPO - visão geral

Arquitetura de Software, © Jair C Leite

Architectural Separation of Concerns (ASC)

• Desenvolvido e praticadopela Nokia

• Requisitos fazem parte demetas de desenvolvimento

• ... que afetam decisõesarquiteturais

• ... que são representadaspor descrições daarquitetura

• ... que são utilizadas paraverificar as decisões

• A descrição e aimplementação devem serconsistentes - validação

• A avaliação verifica se asmetas foram atingidas

12

Arquitetura de Software, © Jair C Leite

Um modelo geral para designarquitetural• Busca unificar características dos modelos

existentes• Três atividades principais:

– Análise arquitetural• Articula os requisitos significantes baseados no

contexto e em interesses– Síntese arquitetural

• Resulta em soluções arquiteturais candidatas quesatisfaçam os requisitos

– Avaliação arquitetural• Assegura que as decisões tomadas foram as

corretas

Arquitetura de Software, © Jair C Leite

Atividades e artefatos

• Interesses arquiteturais– Interesses que pertencem ao desenvolvimento e

operação do sistema e outros aspectos críticos eimportantes para os envolvidos

• Contexto– Determina características e circunstância políticas, de

operacão e desenvolvimento.• Requisitos arquiteturais significantes

– Requisitos que influenciam a arquitetura– Soluções parciais, alternativas e ‘rationale’

• Arquiteturas validadas– Soluções candidatas que satisfazem os requisitos

arquiteturais significantes.

13

Arquitetura de Software, © Jair C Leite

Referências

• C. Hofmeister et al. / The Journal ofSystems and Software 80 (2007) 106–126