Você está na página 1de 166

www.labes.ufpa.br

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Avaliação de Arquiteturas de Software

Rodrigo Quites Reis

(ministrante)

Com base em Evaluating Software Architectures: Methods and Case Studies

1 1

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Objetivos da Disciplina

Apresentar técnicas para avaliação de arquitetura de software

Apresentar exemplos Realização de Exercícios

2

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Origem do Curso

Dificuldade dos alunos em entender a

importância de esforços na elaboração da

arquitetura de software e temas correlatos:

Especificação de requisitos Cenários de testes

Formação de profissionais aptos a realização de avaliações de arquitetura na região

Curso de Residência em Arquitetura de Software

Demandas dos projetos do LABES e de empresas associadas

3

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Referencial bibliográfico

Evaluating Software Architectures:

Methods and Case Studies

Paul Clements, Rick Kazman, Mark Klein Addison-Wesley SEI Series in Software Engineering 2002

4

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Organização

Cap 1: O que é arquitetura de

software?

Cap 2: Avaliação de Arquitetura de Software

Cap 3: ATAM Um método para avaliação de arquitetura

Cap 4: Battlefield control

system estudo de caso do ATAM

Cap 5: Entendendo atributos de qualidade

Cap 6: Um estudo de caso na

aplicação do ATAM

Cap 7: Usando SAAM para

avaliar uma arquitetura

exemplo

Cap 8: ARID um método de avaliação para arquiteturas parciais

Cap 9: Comparação de

métodos para avaliação de arquitetura de software

Cap 10: Criando a

capacidade de avaliação de

arquitetura em uma

organização

5

www.labes.ufpa.br

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é arquitetura de software?

Capítulo 1

6 6

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é Arquitetura de Software?

Embora o uso do termo tenha se

popularizado nos 1990s, o assunto vem

sendo debatido há mais tempo

Pioneiros:

David Parnas, Fred Brooks, Edsger Dijkstra

Mudança na década de 1990: grandes

sistemas de software se tornaram comuns

7

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é Arquitetura de Software?

Razões pelas quais arquitetura é

importante para sistemas grandes e

complexos

Veículo para comunicação com stakeholders

Manifestação das primeiras decisões de projeto

É uma abstração reutilizável e transferível para um sistema

8

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é Arquitetura de Software?

Definição

A arquitetura de software para um programa ou sistema computadorizado é a estrutura ou estruturas do sistema que compreende: 1) os

componentes de software, 2) as propriedades

externamente visíveis destes componentes, e 3) seus relacionamentos (Bass 98)

9

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é Arquitetura de Software?

Implicações da definição

Arquitetura é uma abstração de um sistema/sistemas

Por ser uma abstração, são suprimidos detalhes puramente locais de um componente

Sistemas são compostos por muitas estruturas (visões). Nenhuma visão unitária consegue

representar uma arquitetura completamente.

10

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é Arquitetura de Software?

Outras arquiteturas ...

Business architecture Enterprise architecture Operational architecture Process architecture

Significado: “estrutura” ou “princípios de organização”

informal com respeito à definição de arquitetura de software

Arquitetura de referência: domínios específicos

11

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Diferentes interesses:

Usuário: quer um sistema usável, confiável e disponível Cliente: arquitetura será implementada no cronograma e orçamento previstos? Gerente: (além das preocupações do Cliente) equipe consegue trabalhar de forma independente? Desenvolvedor: os objetivos serão obtidos com o código? Testador: objetiva provar (ou reprovar) que os objetivos foram atingidos.

12

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visões Arquiteturais

Casa: projeto elétrico, hidráulico, ventilação, layout dos aposentos, etc (visões específicas) Especialistas visões específicas

Eletricista projeto elétrico Projetista de móveis layout dos aposentos, ventilação, hidráulico

13

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visões de software

Funcional (ou Lógica) Concorrência (ou visão de processos/threads) Código Desenvolvimento (ou implementação) Física

14

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visão Funcional

Abstração das funções do sistema e seus relacionamentos

Componentes: Funções (Abstrações principais do sistema), e Elementos de domínio Relacionamentos: Dependências e Fluxo de Dados

Usuários: Engenheiros de domínio, projetistas de linhas de produto, usuários finais

Percepção dos usuários: qual é a funcionalidade, como

é o fluxo de dados pelas partes, e qual é a variabilidade

permitida na funcionalidade

15

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visão de concorrência

Implantação de Sistemas complexos: mapeamento de um conjunto de processos/threads recursos computacionais

Componentes: processos e threads

Interação: fluxo de dados, eventos, e sincronização de recursos compartilhados

Usuários: preocupados com a implantação do sistema; preocupados com performance e disponibilidade do

sistema; integradores e testadores

Percepção: performance, disponibilidade e implantação

16

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visão de Código

É o que o programador enxerga Componentes: classes, objetos, procedures, funções, e suas abstrações/composições (subsistemas, camadas,

módulos) Relacionamentos: chamadas de métodos, herança, etc Usuários: programadores, projetistas Percepção: modificabilidade, manutenibilidade, portabilidade Exemplo: Padrões de Projeto GoF

17

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visão de Desenvolvimento

Visão da estrutura do código-fonte como um repositório onde vários usuários (programadores) criam, modificam e

gerenciam Componentes: arquivos e diretórios Relacionamentos: versão, composição Usuários: programadores, projetistas, gerentes de projeto, gerentes de configuração

18

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como veículo para

comunicação com stakeholders

Visão Física

Mostra como o sistema é implantado no hardware Complexidade e importância proporcionais ao número de componentes de hardware envolvidos com o

sistema Componentes: CPUs, sensores, armazenamento Relacionamento: redes de interconexão

Percepção: adequação do hardware, necessidades de upgrade

19

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Architecture Description

Languages (ADLs)

Linguagens especializadas para descrição

de arquiteturas

Ênfase em aspectos específicos de interesse dos seus criadores

Detecção de deadlock Consistência, Propriedades de sistemas de tempo real Etc

Uso restrito / falta de ferramentas

20

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como Manifestação das

Primeiras Decisões de Projeto

Arquitetura de software é uma coleção

coerente e justificada do primeiro conjunto

de decisões de projeto

Constatações:

Desenho da arquitetura permite avaliar praticamente todos os atributos de qualidade de um sistema

A arquitetura irá afetar a organização (empresa)

As primeiras decisões de projeto irão restringir a implementação subsequente

21

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como Manifestação das

Primeiras Decisões de Projeto

Desenho da arquitetura permite avaliar

praticamente todos os atributos de

qualidade de um sistema

Performance atenção na comunicação entre componentes e no tempo de execução dos

componentes

Modificabilidade atenção no encapsulamento dos componentes

Segurança atenção na comunicação entre componentes, fluxo de dados e talvez introduzir componentes especiais (funções de criptografia /

protocolo de comunicação entre componentes)

22

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como Manifestação das

Primeiras Decisões de Projeto

A arquitetura irá afetar a organização (empresa) Existe correspondência entre estruturas arquiteturais e organizacionais?

Projeto pode levar a necessidade de uma equipe específica para lidar com planejamento,

modelagem e afinação de performance

Ou sugerir uma equipe que lide como as falhas do sistema serão detectadas e gerenciadas

SoC Humana depende de SoC Software (e vice versa): equipe de DBMS x equipe de telecom

23

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como Manifestação das

Primeiras Decisões de Projeto

As primeiras decisões de projeto irão

restringir a implementação subsequente

Decisões sobre a adoção de um protocolo, um SGBD, ou tecnologia afetam o processo

Oracle, Web Services, Enterprise Java Beans, JBOSS, Apache,

Tomcat, etc.

24

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como Manifestação das

Primeiras Decisões de Projeto

Uma das primeiras decisões: formas da infraestrutura

como os componentes se comunicam, inicializam, encerram, fazem self test, reportam falhas, etc.

Estrutura computacional Framework quando construída primeiro permite:

Uma versão executável do software mais cedo

 

pode ser apenas startup/shutdown, mas mostrando interconexão com outros sistemas

Outros sistemas podem ser apenas stubs com nada real implementado

Melhoria na “moral” da equipe envolvida

 
 

25

Diminuição nos riscos

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estilos Arquiteturais

Escolha de estilo arquitetural: freq uma das

primeiras decisões de projeto

Estilo:

Descreve uma classe de arquiteturas ou componentes arquiteturais significativos

É encontrado repetidas vezes na prática

É coerente com um conjunto de decisões de projeto

Possui propriedades bem conhecidas sobre seu uso e limitações

26

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estilos Arquiteturais

Shaw & Garlan (1996)

Componentes indepentes: processos comunicantes, invocação implícita e invocação explícita Fluxo de dados: sequencial em batch, pipe and filters Centrado em Dados: repositório, blackboard Máquina virtual: interpretada, baseada em regras Call/Return: programa principal x subrotina, OO, camadas

Obs: há várias outras coleções/classificações de estilos arquiteturais

27

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estilos Arquiteturais

Cada estilo arquitetural consiste de (1/2):

Um conjunto de tipos de componentes

Ex: repositório de dados, processo, objeto

Um conjunto de tipos de conectores/mecanismos de interação

Ex: chamada de subrotina, evento, pipe

Um layout topológico dos componentes

Ex: estrela, anel, hierárquico

(Continua)

28

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estilos Arquiteturais

Cada estilo arquitetural consiste de (2/2):

Um conjunto de restrições na topologia e comportamento

Ex: pipelines são acíclicos; comunicação entre camadas de cima para baixo

Uma descrição informal com os custos e benefícios do estilo

Ex: Use o Pipe & Filter quando reuso é desejado e performance não é prioridade

29

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como uma Abstração

Reutilizável e Transferível de Sistema

Arquitetura:

modelo reutilizável que pode se tornar base para uma família de sistemas de um determinado segmento de mercado (gerando

uma Linha de produto de software)

Uma arquitetura é um ativo da organização que foi criado com um custo considerável

Este custo deve ser compartilhado com outros projetos, com a devida reutilização

30

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como uma Abstração

Reutilizável e Transferível de Sistema

Criação de uma linha de produtos: mais

complexa que produto individual

Criação e gerência de um conjunto de

ativos “core”: crucial e desafiador

Decisão do que é “core” (comum, invariável) vs o que é específico de produto

Garantir o atendimento de requisitos de

qualidade através da linha de produtos x

Garantir a variabilidade mantendo uma

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Arquitetura como uma Abstração

Reutilizável e Transferível de Sistema

Variantes:

Exemplo 1) criação de uma versão do produto que seja pequena, barata, de baixa performance, p/ hw monoprocessado vs

Exemplo 2) Grande, caro, Alta performance, multiprocessado

Infraestrutura básica para atender esta

variação não pode por si própria consumir

muito do poder de processamento

32

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Questões

Encontre 4 ou 5 definições para arquitetura

de software em livros ou websites.

Verifique se consegue destilar as diferenças

e semelhanças essenciais.

Alguns projetistas utilizam uma visão de

atribuição de tarefas que divide um sistema

em áreas de responsabilidade para serem

trabalhadas por diferentes equipes. Qual/is

visão/ões descritas neste capítulo

constituem esta informação?

33

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Questões

O estilo em camadas é extremamente

popular e útil. Qual visão você iria utilizar

para descrever uma arquitetura em

camadas?

Que visões você iria escolher para

descrever o fluxo de dados de um sistema?

34

www.labes.ufpa.br

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Avaliação de Arquitetura de Software

Capítulo 2

35 35

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estrutura do Capítulo 2

Introdução

Por que avaliar?

Quando avaliar?

Quem são os envolvidos?

Qual resultado uma avaliação produz?

Para quais qualidades

se pode avaliar uma

arquitetura?

Por que os atributos

de qualidade são

muito vagos para análise?

Quais são os

resultados de uma avaliação?

Quais são os benefícios e custos de realizar uma avaliação?

36

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Avaliando a Arquitetura de

Software

Como você pode ter certeza que a

arquitetura escolhida para o seu software é

a correta?

Como você pode ter certeza que ela não lhe

levará a calamidade, mas ao invés irá

pavimentar o caminho para um

desenvolvimento suave e e um produto

bem sucedido?

37

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Avaliando a Arquitetura de

Software

Arquitetura é uma aposta, uma

“adivinhação” sobre o sucesso de um

sistema

Não seria bom se você soubesse antecipadamente se apostou em um vencedor, ao invés de esperar até quase o fim de um desenvolvimento para vislumbrar um fracasso?

Até algum tempo não haviam técnicas ou metodologias respeitáveis que apoiassem esta

tarefa

38

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Avaliando a Arquitetura de

Software

Métodos desenvolvidos pelo SEI para

avaliação (suíte de avaliação):

ATAM: Architecture Tradeoff Analysis Method SAAM: Software Architecture Analysis Method ARID: Active Reviews for Intermediate Design

39

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Revisão de conceitos

Arquitetura define os componentes

(módulos, objetos, processos, subsistemas,

unidades de compilação, etc) e relações

relevantes (chamadas, sincronização, uso,

instanciação, etc) entre eles.

É resultado de decisões iniciais de projeto -

antes que um grupo de pessoas trabalhe na

construção

Quanto maior ou mais distribuído o grupo,

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é Arquitetura?

Variantes:

Qual a diferença entre uma arquitetura e um projeto de alto nível?

Detalhes como prioridades dos processos são arquiteturais?

Por que detalhes de implementação como buffer overflow são tratados como arquiteturais?

As interfaces de componentes são parte da arquitetura?

(continua)

41

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é arquitetura?

Variantes:

Se eu tenho um diagrama de classes, preciso de algo mais?

A arquitetura se preocupa com o comportamento de execução ou estrutura

estática?

O Sistema Operacional faz parte da arquitetura? A linguagem de programação?

Se eu estou restrito a um produto comercial específico, isto é arquitetural? Se estou livre

para escolher, isto é arquitetural?

42

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é arquitetura?

Revitando a definição de arquitetura

“1) os componentes de software, 2) as propriedades externamente visíveis destes componentes, e 3) seus relacionamentos (Bass

98)”

Não tem explícita a noção de contexto Exemplo: estruturas de dados de um programa

Normalmente: elementos de implementação

Porém, a propriedade de algumas estruturas de permitirem acesso concorrente afeta performance e confiabilidade

43

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

O que é arquitetura?

Critérios para ser arquitetural:

componente, relacionamento entre componentes, ou propriedade que precisa ser externamente observável para permitir o

raciocínio sobre a habilidade do sistema em

atender seus requisitos de qualidade ou permitir a decomposição do sistema em partes

independentemente implementáveis

44

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Por que avaliar uma arquitetura?

Mais cedo um erro é encontrado, melhor

será

Arquitetura determina a estrutura de um

projeto:

Orçamentos e prazos, objetivos de performance, estrutura da equipe, organização da documentação, e atividades de teste e manutenção

Se deficiências na arquitetura são descobertas tardiamente, o projeto completo pode se

tornar um caos

45

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Por que avaliar uma arquitetura?

A avaliação de arquitetura é uma maneira

barata de se evitar um desastre.

Os métodos são aplicáveis ainda quando o

sistema está no papel.

Analogia: na construção de uma casa, não

se pensa em prosseguir antes de uma

avaliação cuidadosa dos projetos.

46

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Quando uma arquitetura pode

ser avaliada?

Visão clássica: avaliação antes da

implementação

Processos iterativos: ciclo mais recente

Early (cedo)

Avaliação pode ocorrer em qualquer momento da criação de uma arquitetura desde que requisitos tenham sido identificados

Late (tardia)

Avaliação de um sistema legado

47

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Quem está envolvido?

Evaluation team

Conduzem a avaliação e realização a análise Não é recomendado que tenham participado do desenho da arquitetura

Stakeholders

Quem possui interesse no sistema

48

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Qual o resultado de uma

avaliação arquitetural?

Em síntese, a avaliação produz um laudo

Formatos variados

Responde a duas questões principais:

Esta arquitetura é adequada para o sistema? Qual destas duas ou mais arquiteturas propostas é mais adequada para um sistema?

49

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Qual o resultado de uma

avaliação arquitetural?

Arquitetura adequada?

O sistema resultante atende os objetivos de qualidade

Sistema irá:

Rodar de forma previsível e rápido o bastante para atender os requisitos de tempo

Ser passível de modificações planejadas Atender as demandas de segurança ...

O sistema pode ser construído com os recursos disponíveis:

Pessoal, orçamento, sw legado (se houver), e tempo

50

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Qual o resultado de uma

avaliação arquitetural?

Para avaliar se uma arquitetura é adequada

é necessário avaliar os requisitos /

objetivos do sistema

Onde estão estes requisitos? Documento de requisitos?!

Na prática, não existem; estão desatualizados Pior: os requisitos são frequentemente especificados de forma muito restrita, com foco

apenas no sistema em questão e não na sua arquitetura (RFs e não RNFs)

51

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Qual o resultado de uma

avaliação arquitetural?

Resultado:

SIM , NÃO

Onde estão os riscos (conflitos, custos, decisões importantes, etc) do projeto

52

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Qual o resultado de uma

avaliação arquitetural?

Quando aplicada a um conjunto de

arquiteturas competidoras avaliação

mostra pontos fortes e fracos de cada

alternativa

Decisão final sobre qual caminho a seguir

fica a cargo do Gerente do Projeto

53

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Para quais qualidades se pode

avaliar uma arquitetura?

Não basta olhar uma arquitetura para

avaliar a qualidade um software

Implementação pode se distanciar do que foi especificado

Arquitetura por si só não consegue determinar a qualidade global do sistema

54

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Para quais qualidades se pode

avaliar uma arquitetura?

Usabilidade

Medida pela habilidade do usuário em usar um sistema de forma efetiva

Arquitetura lida com usabilidade do ponto de

vista do fluxo dos Inputs dos usuários até

produzir os Outputs solicitados

Atributo de qualidade difícil de se determinar a partir de uma avaliação arquitetural

55

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Para quais qualidades se pode

avaliar uma arquitetura?

Critérios que podem ser avaliados (ATAM)

Performance Confiabilidade Disponibilidade Segurança Modificabilidade Portabilidade Funcionalidade Variabilidade Subsetability Integridade conceitual

56

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Por que os atributos de

qualidade são tão vagos?

Citar os atributos de qualidade não é útil:

O sistema deve ser robusto O sistema deve ser altamente modificável O sistema deve ser seguro para evitar invasões O sistema deve possuir performance aceitável

57

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Por que os atributos de

qualidade são tão vagos?

Atributos de qualidade dependem do

contexto

Um sistema é modificável (ou não) com respeito a um tipo específico de mudança

Um sistema é seguro (ou não) com respeito a um tipo específico de ameaça

Um sistema é confiável (ou não) com respeito a um tipo específico de falha

Uma arquitetura é viável (ou não) com respeito às restrições de tempo e orçamento

58

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Por que os atributos de

qualidade são tão vagos?

Em outras palavras

Um sistema não pode ser considerado confiável sob todas as circunstâncias

Falha elétrica, furacão, administrador enfurecido de posse de uma moto-serra.

59

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Por que os atributos de

qualidade são tão vagos?

O melhor dos mundos é uma especificação

livre de ambiguidade

Técnica usada: cenário (semelhante a Use

case - mas com aplicação mais ampla)

Script

Exemplo: cenário da manutenção do

software: (1) atualização do sistema

operacional; (2) incorporação de nova

funcionalidade

60

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Quais são as saídas de uma

avaliação de arquitetura?

Saídas Comuns - ATAM, SAAM e ARID (1/3)

Definição priorizada de requisitos / atributos de qualidade

Necessária para qualquer avaliação arquitetural

Mapeamento das abordagens para os atributos de qualidade

Mostra como as abordagens arquiteturais atendem (ou falham em atender) os atributos de qualidade

requeridos

61

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Quais são as saídas de uma

avaliação de arquitetura?

Saídas Comuns - ATAM, SAAM e ARID (2/3)

Riscos e Não-Riscos

Riscos são decisões arquiteturais potencialmente problemáticas

Ex:

As regras para escrever os módulos de lógica de negócios na 2ª camada do seu sistema de 3 camadas não estão bem definidas (uma decisão não foi tomada). Isto pode resultar na replicação de funcionalidade, comprometendo assim a modificabilidade da 3ª camada.

62

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Quais são as saídas de uma

avaliação de arquitetura?

Saídas Comuns - ATAM, SAAM e ARID (3/3)

Riscos e Não-Riscos

Não-riscos são boas decisões que se baseiam em hipóteses que frequentemente são implícitas na

arquitetura

Ex: Assumindo que a taxa de chegada de mensagens é de uma por segundo, o tempo de processamento de 30 milissegundos, e a existência

de um processo de prioridade mais alta (decisão

arquitetural), o limite de 1 seg parece razoável uma vez que a taxa de chegada é restrita e os efeitos preemptivos dos processos de prioridade mais alta

são conhecidos.

63

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Esforço

   

Stakeholders

 

Fase

Equipe de avaliação (5

Tomadores de Decisão do projeto

 

Outros

membros)

(arquiteto,

stakeholders

gerente, cliente)

 

Fase 0: Preparação

  • 1 pessoa-dia líder

  • 1 pessoa-dia

0

Fase 1: Avaliação inicial (1 dia)

  • 5 pessoas-dias

  • 3 pessoas-dias

0

     

16

pessoas-dias

  • 9 pessoas-dias + 2

(maioria dos

Fase 2: avaliação

completa (3 dias)

  • 15 pessoas-dias

pessoas-dias para

preparação

stakeholders presentes por 2 dias apenas)

   
  • 3 pessoas-dias para

 

Fase 3: follow up

  • 15 pessoas-dias

leitura e respostas

0

TOTAL

  • 36 pessoas-dias

18 pessoas-dias

16

pessoas-dias

64

www.labes.ufpa.br

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Avaliação de Arquitetura de Software

Capítulo 3

ATAM A Method for Architecture

Evaluation

65 65

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estrutura do Capítulo 3

Sumário

Descrição detalhada dos passos de ATAM

As fases de ATAM

Leituras adicionais

Questões para discussão

Material adicional disponível em

http://www.sei.cmu.edu/reports/00tr004.pdf

66

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Introdução

Architecture Tradeoff Analysis Method

Tradeoff

1 : a balancing of factors all of which are not attainable at the same time

Fonte www.m-w.com (Merriam Webster)

67

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Introdução

ATAM

Não apenas revela quão bem uma arquitetura satisfaz metas de qualidade específicas, mas também provê apoio em como estas metas de

qualidade interagem umas com as outras How do they tradeoff against each other Pode ser usado para avaliar sistemas legados

68

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

ATAM

Serviram de inspiração para o ATAM:

A noção de estilos arquiteturais

As comunidades de análise de atributos de qualidade

SAAM Software Architecture Analysis Method (predecessor do ATAM)

69

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Resumo do Processo ATAM

Apresentação

Investigação e Análise

Teste

Relatando os resultados

70

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Resumo do Processo ATAM

Apresentação

Apresentação do ATAM

O líder descreve o método de avaliação

Apresentação das diretrizes do negócio

Gerente descreve os objetivos de negócio que motivam o projeto e as questões

Apresentação da Arquitetura

Investigação e Análise

Teste

Relatando os resultados

71

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Resumo do Processo ATAM

Apresentação

Investigação e Análise

Identificar as abordagens arquiteturais adotadas (ainda sem análise) Geração da árvore de atributos de qualidade Análise das abordagens arquiteturais (riscos, não-riscos, pontos de sensibilidade e pontos de tradeoff)

Teste

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Resumo do Processo ATAM

Apresentação

Investigação e Análise

Teste

Brainstorm e priorização de cenários Análise das abordagens arquiteturais

Relatando os resultados

73

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Resumo do Processo ATAM

Apresentação

Investigação e Análise

Teste

Relatando os resultados

Apresentação dos resultados

74

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 1 Apresentação do ATAM

Explicação do processo Sumário:

Descrição do processo ATAM

As técnicas que serão usadas para elicitação e análise: geração de árvore utilitária, elicitação e análise da arquitetura, e brainstorming/priorização de cenários

As saídas da avaliação: os cenários elicitados e priorizados, as questões usadas para entender e avaliar a arquitetura, ...

75

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 2 Apresentar diretrizes de negócio

Equipe de avaliação precisa conhecer o contexto do sistema e suas motivações

Deve descrever:

As funções mais importantes do sistema Todas as restrições técnicas, gerenciais, econômicas ou políticas

Os objetivos de negócio e como eles se relacionam

com o projeto Os principais interessados As diretivas da arquitetura elaborada

76

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

www.labes.ufpa.br
www.labes.ufpa.br

77

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 3 Apresentar a arquitetura

Apresentação em “nível adequado de detalhe”:

Quanto da arquitetura foi elaborado ou documentado

Quanto tempo está disponível

A natureza dos requisitos comportamentais e de qualidade

78

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 3 Apresentar a arquitetura

Deve mostrar:

Restrições técnicas (S.O., Hardware, ou middleware prescritos)

Outros sistemas que interagem

Abordagens arquiteturais adotadas para atender os requisitos de qualidade

79

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

80

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

81

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 4 Identificar as abordagens

arquiteturais

Abordagens arquiteturais: estilos/padrões de projeto, decisões arquiteturais, etc.

Definem estruturas importantes do sistema e

Descrevem a maneira que o sistema pode crescer, responder a mudanças, evitar ataques, integrar com

outros, etc.

Somente identificar, não analisar (ainda)

82

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 4 Identificar as abordagens arquiteturais

www.labes.ufpa.br © Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009 Descrição detalhada ATAM

83

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 5 Gerar árvores utilitárias de

atributos de qualidade

84

www.labes.ufpa.br

medium importance to the success of the system and low

risk to achieve

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

85

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

Passo 6 Analisar as Abordagens

Arquiteturais

86

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

87

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

88

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

89

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

90

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

91

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

www.labes.ufpa.br
www.labes.ufpa.br

92

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Descrição detalhada ATAM

93

www.labes.ufpa.br

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Capítulo 4 The Battlefield Control System

O Primeiro estudo de caso aplicando

o ATAM

94 94

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Battlefield Control System

Preparação

Fase 1

Fase 2

Resultados da Avaliação BCS

Sumário

95

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Introdução

Battlefield Control System (BCS)

Usado por batalhões do Exército para controlar a movimentação, estratégia, e operações das tropas em tempo real no campo de batalha

96

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Preparação

Battlefield Control System

Fase 0

Concordância em realizar avaliação ATAM no BCS

Reunião entre avaliador-chefe, representantes do cliente, e arquitetos Documentação inicial muito vaga

Descrição do fluxo de dados sem mapeamento para componentes do software

Nenhuma discussão (avaliação) sobre as abordagens arquiteturais usadas

97

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Preparação

Battlefield Control System

Fase 0 (cont): perguntas que motivaram

revisão da documentação

Qual é a arquitetura do software de gerência de mensagens?

Quais facilidades existem (se alguma) para auto-teste e monitoração dos componentes de software?

Quais facilidades existem para redundância, monitoração de sobrevivência (liveness)?

Qual é a visão de processos/tarefas do sistema, incluindo o seu mapeamento para o hardware?

98

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Preparação

Battlefield Control System

Fase 0 (cont): perguntas que motivaram

revisão da documentação

Quais dependências funcionais existem entre os componentes de software?

Quais dados são armazenados no banco de dados?

Qual é a expectativa sobre a frequência e volume dos dados transmitidos pelos

componentes do sistema?

99

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 1: apresentar o ATAM

Passo 2: apresentar os objetivos de negócio

Apresentação do cliente

Informações sobre os tipos de missões de combate que este sistema deve auxiliar e os requisitos específicos para cada missão.

Ex: nó commander que comanda um conjunto que nós soldier e seus equipamentos (incluindo armamento e sensores)

100

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 2: apresentar os objetivos de negócio

O sistema deve possuir interface com vários outros sistemas que fornecem informação sobre ordens e inteligência

Estes sistemas externos também periodicamente obtêm info do BCS sobre as missões atuais

Restrições sobre hardware e software:

A necessidade de níveis extremos de robustês física

A necessidade de adaptação frequente a mudanças no

formato das mensagens recebidas de outros sitemas A necessidade de atender metas de performance

101

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 3: Apresentar a arquitetura

Visões apresentadas:

Dinâmica: como os subsistemas se comunicam Diagramas de sequência: interações de runtime Visão do sistema: implantação física no hardware Source view: subsistemas em termos de objetos

102

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 3: Apresentar a arquitetura

Arquitetura C/S Mensagens via rádio encriptadas Canal de comunicação

compartilhado:

apenas um nó pode transmitir em cada momento

www.labes.ufpa.br © Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009 Fase 1 Battlefield

103

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 4: identificar abordagens arquiteturais Noção inicial: apenas servidores e clientes Elementos adicionais identificados da descrição inicial

Um commander backup foi incorporado

Para atender o requisito de disponibilidade

Um conjunto de padrões de projeto de domínio específico

Para atender o requisito de modificabilidade

Uma abordagem independente para comunicação de componentes foi proposta

Para atender os objetivos de performance

104

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 5: gerar a árvore de atributos de

qualidade

Requisitos mais importantes para clientes:

Modificabilidade e performance

Após argumentação foi acrescentada:

disponibilidade

105

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 5: gerar a árvore de atributos de qualidade

106

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens arquiteturais

Questões adicionais (disponibilidade):

Como a falha de um componente é detectada?

Como a falha no canal de comunicação é detectada?

Qual é a latência para que um componente substituto se torne um componente real?

De que forma um componente em falha é marcado para substituição?

Como os componentes em funcionamento são notificados que devem usar os serviços de um substituto?

107

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

O diagrama fornece poucas informações Análise

(1) Abordagem do Backup Commander

(2) Abordagem da Comunicação independente de componentes

(3) Análise de modificabilidade método SAAM (excluída)

108

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

(1) Abordagem do Backup Commander

Atributo chave: disponibilidade Questão central: quais recursos são replicados?

Uso de abordagem cliente-servidor: suspeita que o servidor é um potencial problema (ponto único)

Sistema operante:

1 nó Commander e qualquer número de nós Soldier

109

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

(1) Abordagem do Backup Commander

Falha no Commander leva ao colapso no sistema Provisão:

Habilidade de transformar um Soldier em Commander (i.e., converter cliente em um servidor)

Recovery time: tempo para tornar um nó Soldier em Commander

Falha no Commander é detectada por comunicação humana

110

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

(1) Abordagem do Backup Commander

Principal estímulo: falha de um nó (especialmente, o commander)

Razões: ataque, falha de hardware, ou falha de software

Arquitetura original: nó Soldier de backup definido estaticamente

Msgs de estado (ack) enviadas ao nó backup para manter o estado de prontidão do sistema

111

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

(1) Abordagem do Backup Commander

A impossibilidade de se criar novos backups para o Commander leva ao sistema não atender o req de

disponibilidade

Levou à avaliação de alternativas arquiteturais que considerem o tempo necessário para levantar um novo servidor

112

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

(1) Abordagem do Backup Commander

Alternativa arquitetural para que múltiplos nós Soldier (possivelmente todos) atuem como

monitores da comunicação Commander-to-backup

Ack backups: requer reenvio de pacotes perdidos Silent backups (passivos) Mistura dos acima (n ack backups / m silent backups)

No caso que pacotes não sejam confirmados, o estado do sistema irá migrar do Commander e algum backup será chamado para assumir

113

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Alternativas para melhorar distribuição de dados para os backups

Análise

Um backup poderia ser um backup de confirmação (acknowledge) mantido em completa sincronia com o Commander

Pouco impacto contínuo na performance, mas o backup se torna pronto para assumir sempre que chamado

Um backup pode ser apenas um

Não impacta na performance, mas o

backup passivo e não solicita retransmissão quando uma mensagem é perdida. Obs: Implica em algum mecanismo para determinar a perda de msg (ex:

backup pode possuir dados incompletos

numeração)

Um backup quando se tornar um novo Commander ou se tornar um backup ack pode requisitar as informações perdidas de outros sistemas acima ou de outros soldiers

Não impacta na performance, mas o backup precisa baixar os dados que faltam, aumentando o tempo de recuperação

114

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6:

O sistema não precisa ter uma única opção para backups

Pode possuir n acknowledging backups e m passive backups

Disponibilidade do sistema aumenta com (n+m), mas principalmente com n

Ack backups podem assumir o Commander mais rapidamente (sem necessidade de negociação)

Tradeoff: com o aumento em n há maior impacto na comunicação.

115

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6:

Abordagem de comunicação independente

Caracterização de performance leva em consideração quais recursos estão restritos

Em sistema C/S: (sempre se) suspeita que o servidor é o principal gargalo

Velocidade de comunicação de 9600 bits por seg: é o principal limitador de velocidade

116

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6:

Abordagem de comunicação independente

Cenários de avaliação:

Cenário A: Atualizações periódicas e regulares (msgs de tamanho e frequência variadas)

Cenário B: Transformar um Soldier em um backup; esta troca requer que o backup obtenha informação sobre todas as missões, atualize o banco de dados, ordens atribuídas, localização dos Soldiers, inventário dos

Soldiers

117

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6:

Abordagem de comunicação independente

Considerando: 9600 bits / seg, máximo de 25 soldiers por commander (um sendo usado como

commander = 24) Download de planos de missão:

280 Kbits ÷ 9.6 Kbits/seg 29,17 seg

Atualização do banco de dados do ambiente:

66 Kbits ÷ 9,6 Kbits/seg 6,88 seg

Obter ordens atribuídas (para 24 soldiers):

24 × (18 Kbits ÷ 9,6 Kbits/seg) = 45,0 seg

118

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6:

Abordagem de comunicação independente

Obter localização e situação dos soldiers (24):

24 × (12 Kbits ÷ 9,6 Kbits/seg) = 30,0 seg

Obter inventário (24 soldiers):

24 × (42 Kbits ÷ 9,6 Kbits/seg) = 105,0 seg

Total 216,05 seg para um Soldier se tornar backup Considerando que nenhuma outra comunicação pode ser realizada em paralelo

119

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 1

Battlefield Control System

Passo 6: Analisar as abordagens

arquiteturais

Manter cada backup em estado de prontidão requer que se torne ack backup

Ou, em estado menor de prontidão, passive backup

Ambos os casos requerem atualização periódica do servidor Total de mensagens: 59.800 bits a cada 10 minutos Cada backup requer 99,67 bits / seg 1% da largura de banda do sistema

120

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 7: Brainstorm e Priorização dos

Cenários

Passo 8: Análise das Abordagens

Arquiteturais

Passo 9: Apresentação dos resultados

121

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 7: Brainstorm e Priorização de

cenários

Define uma quantidade limitada de cenários para avaliação Importância definida pelos stakeholders No BCS, cada stakeholder possuía 12 votos

10-15 cenários: normal para um dia de trabalho

122

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 7: Brainstorm e Priorização de

cenários

Cenário

Descrição

1

Mesma informação apresentada ao usuário, porém com apresentação diferente (localização, fonte, tamanhos, cores, etc)

2

Usuário solicita a alteração de um diálogo

3

Um novo dispositivo é adicionado a rede. Por exemplo: GPS

4

Um dispositivo existente adiciona campos que atualmente

não são tratados pelas mensagens

6

Formato do mapa é modificado

7

O Tempo de inicialização é reduzido de 5 minutos para 90 seg

8

Velocidade do modem é multiplicada por 4

123

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 7: Brainstorm e Priorização de

cenários

Cenário

Descrição

9

Sistema operacional alterado para Solaris

10

Mudança no número de nós Soldier de 25 para 35

11

Mudança no número de missões simultâneas de 3 para 6

12

Mudança no formato das mensagens recebidas

...

...

124

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 8: Análise das Abordagens

Arquiteturais

Conjunto de cenários selecionados: usados como casos de teste para a arquitetura

No caso de um cenário que implique em mudança na arquitetura, o arquiteto deve demonstrar o que será afetado (componentes

adicionados, alterados, removidos, conectores

e interfaces)

Para cenários de CDUs o arquiteto deve fornecer o fluxo de execução previsto

125

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 8: Análise das Abordagens

Arquiteturais

No BCS, cada cenário de alta prioridade foi mapeado para a arquitetura prevista.

Ex1: para disponibilidade e performance descrever os cenários que descrevem a execução e falhas

126

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 9: Apresentação dos resultados

pontos de sensibilidade

Tráfego de mensagens que flui pelo canal de comunicação Número de backups ack e passivos (n, m)

n e m são os pontos de tradeoff entre

Performance geral do sistema (em termos da latência sobre o meio de comunicação) e

Disponibilidade do sistema (em termos do número de backups do Commander)

127

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Fase 2

Battlefield Control System

Passo 9: Apresentação dos resultados

Para determinar a criticidade do trafeoff de forma mais precisa, seria necessário prototipar

Sugere-se também a prototipação do tempo de recuperação caso não haja backups ack

(apenas passivos)

Sugestão para mitigar a limitação de largura de banda: planejamento de novo hardware de

comunicação

128

www.labes.ufpa.br

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Capítulo 6 Estudo de caso aplicando ATAM

129 129

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

Contexto

EOSDIS

Fase 0

Fase 1

Hiato entre Fase 1 e 2

Fase 2

Fase 3

130

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

Contexto

EOSDIS

Avaliação realizada em 2000 Cliente: Goddard Space Flight Center NASA Earth Observing System (EOS)

Constelação de satélites da NASA com nomes como Terra, Aqua e Landsat, e Sensores na terra e no ar

Alimenta o US Global Change Research Program

EOSDIS data Information System

Info sobre vegetação, iluminação, mudanças na superfície, ventos, cor do oceano, atividade

vulcânica, etc

131

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

Contexto

EOSDIS

Antes do EOSDIS, os dados eram armazenados e formatos de maneira específica para cada satélite

EOSDIS é uma maneira padrão para armazenar, acessar e processar os dados

Primeira versão: 1999

Avaliação da NASA visava identificar se a sua arquitetura atende as demandas futuras de performance, escalabilidade, modificabilidade

e operabilidade.

132

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

Requisitos

EOSDIS

Processar, arquivar e distribuir dados de 24 sensores em 10 espaçonaves (com aumento previsto) terabyte por dia de info

Integrar com 250 produtos para cálculos

Arquivar os dados e seus produtos em 8 centros de dados nos EUA

Permitir acesso externo aos centros de dados + 45 serviços

Fornecer capacidade para testar e incorporar novos algoritmos, além de mecanismos de buscas

Atender o crescimento da demanda

133

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 1: Apresentar o ATAM

Resumo

Entradas

Slides de apresentação do ATAM

Uma descrição escrita do ATAM, para deixar no cliente para posterior leitura

Artigos publicados sobre ATAM (opcional pode ser considerado muito técnico)

Dados sobre o esforço requerido na implantação do ATAM em exercícios anteriores

Material anedotário sobre os benefícios - opcional

134

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

Fase 0, Passo 1: Apresentar o ATAM

Resumo

Atividades

Representante da empresa avaliadora se certifica que o cliente entende a mecânica do método da avaliação

Realizar apresentação sobre o método Fornecer ao cliente uma descrição do produto/serviço

Saídas

Nomes e endereços de contatos de todos interessados em adotar o ATAM

135

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 1: Apresentar o ATAM

Descrição do passo

Frequentemente é o primeiro momento que o cliente aprende ouve algo mais detalhado sobre o

ATAM e avaliação arquitetural, e como podem ser

úteis

Como foi realizado

Gerentes da NASA estudaram o ATAM através do site do SEI e artigos publicados

Convencimento foi prévio

136

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 1: Apresentar o ATAM

Experiência prática

Apresentação informal com poucas pessoas presentes

Mínimo: 1 da avaliação + 1 do cliente

Ambos têm de chegar ao acordo sobre objetivos e prazos

137

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 2: Descrever o sistema

candidato

Sumário: Entradas

Diagramas do sistema candidato (opcional)

Outros documentos sobre o sistema candidato especialmente sobre sua arquitetura (opcional)

Formulários NDA non disclosure agreement (se requeridos pelo cliente)

138

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 2: Descrever o sistema

candidato

Sumário: Atividades

Representantes do cliente descrevem o sistema candidato com detalhe suficiente (objetivos do

negócio, requisitos, restrições)

Acordo entre cliente e avaliadores acerca da documentação arquitetural necessária para a avaliação

Identificar informações confidenciais e controlar seu sigilo na divulgação

Registro de todas as pendências

139

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 2: Descrever o sistema

candidato

Sumário: Saídas

Lista de objetivos de negócio e restrições arquiteturais

Lista da documentação técnica que será entregue para a equipe de avaliação

Formulários NDA para serem assinados pela equipe de avaliação (opcional somente se requerido pelo cliente)

140

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 2: Descrever o sistema

candidato

Principal objetivo: subsidiar a decisão go/no-go do próximo passo

Existe uma arquitetura que possa ser avaliada?

141

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 2: Descrever o sistema

candidato

Como foi realizado?

Avaliação em sistema pronto, funcionando

Foi perguntado ao gerente do projeto por que realizar avaliação neste caso

Resposta: preocupação se o sistema estaria apto para lidar com quantidades muito maiores de dados

Maior número de satélites, maior número de clientes

Planejamento para novas iterações com base na priorização de cenários do ATAM

142

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 2: Descrever o sistema

candidato

Experiência

Quase sempre há alguma documentação do projeto Manter expectativa sobre a qualidade e maturidade da documentação arquitetural bem baixa

143

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 3: Tomar decisão Go/No-Go

Entradas

Critérios específicos go/no-go para sua empresa

Na prática, nem a equipe que propôs ATAM tem isto

Documentos do sistema candidato (passo 2)

Atividades

Aplicar o critério go/no-go

Saída

Se “no goentão enviar carta ao cliente explicando as razões para declinar do serviço e sugerindo passos para remediar a situação para permitir trabalho futuro

144

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 4: Negociar a definição do

trabalho

Custo, esforço, prazos

Fase 0, Passo 5: Montar núcleo da equipe

de avaliação

Prazos, agendas, definições de papéis e responsabildiades

Fase 0, Passo 6: Realizar reunião de kick-off

145

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 7: Preparação para a Fase 1

Avaliador líder

Monta agenda Confirma local e horário Define pauta Solicita ao cliente uma apresentação do sistema Solicita ao arquiteto uma apresentação da arquitetura Garantir a presença de todos os envolvidos

146

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 0, Passo 8: Revisão da Arquitetura

Entrda

Documentação arquitetural identificada no passo 2

Saída:

Lista de questões para o arquiteto

147

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 1: Apresentar ATAM

Fase 1, Passo 2: Apresentar objetivos de

negócio

Atividades:

Cliente ou gerente apresenta visão geral do sistema Equipe de avaliação identifica o escopo, requisitos, interação com outros sistemas, restrições

Ao final, o avaliador líder recapitula os itens principais.

148

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 2: Apresentar objetivos de

negócio

Como foi feito

Descrição do projeto feita pelo Gerente da NASA ECS processa, arquiva e distribui dados científicos sobre a Terra de 15 instrumentos nos 7 principais satélites Objetivo: tornar os dados disponíveis amplamente, em escala mundial, por 24/7. Vida útil prevista: 1999 a 2013

149

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 2: Apresentar objetivos de

negócio

1,2 Milhões de LOCs 50 produtos COTS incorporados Arquivamento de 1,5 TeraBytes novos de dados por dia Distribui 2 TBs de dados/dia em dif formatos 34 sistemas externos

150

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 2: Apresentar objetivos de

negócio

Principais metas de negócio

Apoiar a evolução científica interdisciplinar sobre estudos da Terra

Adquirir, produzir e distribuir grande volume de dados

One-stop shopping

Transparência de localização para componentes e dados do sistema

151

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 2: Apresentar objetivos de negócio

Metas secundárias de negócio

Permitir que algoritmos e aplicações científicas desenvolvidas externamente sejam incorporadas

Reprocessamento de dados científicos

Gerência de versão, processamento e reprocessamento, incluindo a evolução dos algoritmos usados)

Outras metas

Dados disponíveis sempre para todos

Garantia da integridade dos dados

Alto nível de automatização para reduzir custos operacionais

152

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 2: Apresentar objetivos de

negócio

Produziram antecipadamente a árvore utilitária

Meta de qualidade

ID

Requisito específico de qualidade

 

Manutenibilidade

M1

Mudanças em um subsistema não requerem mudanças nos demais

 

M2

Implantação independente de subsistemas

 

M3

Reduzir os testes de regressão de 5 dias

para 1 dia

 

M4

Reduzir o tempo para atualização do

Sistema Operacional, SGBD,

para 6

, meses após o lançamento ou 50% (o

que for menor)

153

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 2: Apresentar objetivos de

negócio

Meta de qualidade

ID

Requisito específico de qualidade

Operabilidade

O10

Sistema deve permitir a repriorização de 1000 pedidos em 20 minutos por classe do usuário, tipos de dados, tipo

de mídia, destino ou usuário

 

O14

Sistema deve atender 1000 requisições concorrentes através do gateway V0 ou MTM sem intervenção do operador

154

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Meta de qualidade

ID

Requisito específico de qualidade

Escalabilidade

S2

Sistema deve atender até 50 sites

 

S3

Sistema deve agregar até 100 fontes de dados

 

S4

Sistema deve permitir a distribuição

eletrônica para até 2000 sites

155

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 3: Apresentar a arquitetura

Entradas

Descrição dos atributos importantes

Toda documentação disponível para a arquitetura sendo avaliada

Descrição das abordagens arquiteturais usadas

Atividades

Arquiteto descreve restrições técnicas, outros sistemas com os quais haverá interação

Registro das explicações fornecidas

156

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 3: Apresentar a arquitetura

Como ocorreu

Subsistemas de BD e servidor de dados Subsistema de aquisição de dados Subsistemas de processamento e planejamento de dados Subsistemas de gerenciamento e interoperabilidade Subsistema de interface com usuário ....

157

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 3: Apresentar a arquitetura

Experiência

Cuidar com a sobrecarga de informações

Arquitetos orgulhosos em mostrar o trabalho

158

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 4: Identificar abordagens

arquiteturais

Propósito

Iniciar a formulação de perguntas e Desenhar conclusões preliminares

Sobre como a arquitetura atende os objetivos traçados

159

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 4: Identificar abordagens

arquiteturais

Como ocorreu?

Cliente-Servidor: usado com frequência em função de ser um sistema centrado em dados Repositórios distribuídos de dados são usados para:

Acomodar distribuição dos usuários Melhorar performance e disponibilidade

Objetos distribuídos com transparência de localização são usados para atingir modificabilidade em contexto distribuído

...

(cont)

160

www.labes.ufpa.br

© Carla A. Lima Reis e Rodrigo Quites Reis (LABES-UFPA) / 2009

Estudo de caso aplicando ATAM

EOSDIS

Fase 1, Passo 4: Identificar abordagens

arquiteturais

Como ocorreu?