73
Arquiteturas de Software Francilene Garcia Projeto I 2008.2

Arquiteturas de Software

  • Upload
    chelsey

  • View
    37

  • Download
    0

Embed Size (px)

DESCRIPTION

Arquiteturas de Software. Francilene Garcia Projeto I 2008.2. Conceitos Básicos. Um sistema computacional. Nós temos tecnologia. Podemos construí-lo. Um sistema computacional isolado…. ?. computador. No espaço, ninguém escuta o seu. Stakeholders…. QA. Operador. Consumidor. - PowerPoint PPT Presentation

Citation preview

Page 1: Arquiteturas de Software

Arquiteturas de Software

Francilene Garcia

Projeto I

2008.2

Page 2: Arquiteturas de Software

Conceitos Básicos

Page 3: Arquiteturas de Software

Um sistema computacional

Page 4: Arquiteturas de Software

Um sistema computacional isolado…

No espaço, ninguém escuta o seu

?

Page 5: Arquiteturas de Software

Stakeholders…

Arquiteto

Operador

CEO Fornecedor

Técnico Desenvolvedor

AdminSys

Consumidor

QA

BillGatesCEO Cliente

Page 6: Arquiteturas de Software

Outros sistemas…

CadastrosLabs Estudantes

Infra Rede

ContabilidadeGerador de Relatórios

Ativos

Page 7: Arquiteturas de Software

Oportunidades e riscos…

Venda acelerada de sistemas

Entrada na Bolsa

Chega tarde ao mercado

Venda fraca de sistemas

Desempenho fraco

Construção de imagem

Impostos

Mercado imaturo

BillGates

Page 8: Arquiteturas de Software

Restrições e aspectos críticos…

SistemaOperacional

Padrões Políticas

Legislação

Processador + rápido

Sistemas Legados

Alta oferta de desenv.Java

Falta desenv.de BD

Ética e meio ambiente

Page 9: Arquiteturas de Software

É complicado.

Page 11: Arquiteturas de Software

Ciclo de vida do desenvolvimento

Preliminaryrequirements

analysis

Design ofarchitecture and

system core

Developa version

Deliver aversion

Elicitcustomerfeedback

Incorporatecustomerfeedback

Softwareconcept

A arquitetura desempenha um papel vital na definição da estrutura do sistema, desde cedo no

ciclo de vida do desenvolvimento

“The evolutionary delivery lifecycle model”(Rapid Development, Steve McConnell)

Arquitetura define a estrutura do sistema

Primeira release libera o core do sistema

Page 12: Arquiteturas de Software

Vida útil do sistema

A arquitetura antecipa decisões que afetam toda vida útil do sistema

Inception

Development

Deployment

Maintenance

Alteration

Legacyoperation

Vision

Death

Operation

Page 13: Arquiteturas de Software

Definições…

Um sistema é um

conjunto de partes

…e formam um todo que

atendem a expectativas

As partes se relacionam entre si…

Page 14: Arquiteturas de Software

Alguns exemplos…

Antes: Na engenharia, trabalha-se com muitos modelos. Um modelo é uma representação que abstrai detalhes menos essenciais, e pode ser

manuseada de uma forma que o “objeto real” não permite.

Page 15: Arquiteturas de Software

Boletim Web (Blog)

Forums andposts

Posting andnavigation

Administration

Administration

Forums and postsUsers and sessions

Logic

Presentation

Data

Navigation

Uma arquitetura em 3-camadas – muito

utilizada em sistemas client-

server e web

Disponibilidade

Segurança

Page 16: Arquiteturas de Software

Processamento de imagem

Algorithmcontrol

ScalingRecognitionCompression

Modulescheduler

Imagestorage

Capture

O processamento tipo “pipeline” é muito

utilizado em sistemas de tempo real e embarcados

Desempenho

Portabilidade

Page 17: Arquiteturas de Software

Isto é tudo!

• Questões?

Page 18: Arquiteturas de Software

Referências e Leituras Recomendadas

• "An Introduction to Architecture." Chapter 1 of A Software Architecture Primer, by John Reekie and Rohan McAdam.

• "Architectural Analysis." Chapter 2 of A Software Architecture Primer, by John Reekie and Rohan McAdam.

• Jan Bosch, ``Design of Software Architectures,'' Chapter 2 of Design and Use of Software Architectures: Adopting and Evolving a Product-line Approach, pp 23--40. Addison-Wesley, 2000.

• Alistair Cockburn, ``Introduction,'' Chapter 1 of Writing Effective Use Cases, pp 1--19. Addison-Wesley, 2000.

Page 19: Arquiteturas de Software

Análise e Projeto Arquitetural

Page 20: Arquiteturas de Software

Arquitetura é arte?

Necessidadesdo Cliente

Arquitetura

desejável

Fatorescontextuai

s

Os clientes devem auxiliar no projeto da arquitetura

desejável, sem esquecer os fatores contextuais

Page 21: Arquiteturas de Software

Fatores contextuais – para casas

• Clima• Materiais disponíveis• Portabilidade• Riscos• Atividades

Page 22: Arquiteturas de Software

“Fatores contextuais”?

São exemplos de fatores.

onstraints

nablers

isks

“OS-Z melhora a segurança”

“OS-Z não é compatível”

“OS-Z não tem tal facilidade”

Page 23: Arquiteturas de Software

Tipos de fatores contextuais

• São buscados em vários lugares:– Mercado/concorrência– Empresas– Tecnologia– Políticas

“Padrão 3576 requer…”

“A legislação restringe falhas …”

“Esta janela de oportunidade…”

“Uma versão

atualizada de …”“A forte capacidade de

desenvolvimento Java…”

“O time de desenvolvimento

da India…”

Page 24: Arquiteturas de Software

Decisivos

• Mudança…!

• Estrutura organizacional

• Desempenho do time

Page 25: Arquiteturas de Software

Uso de narrativas

• Um caminho informal mas útil para descrever funcionalidades do sistema através de cenários

• Cria “personagens” e conta a “estória”

• Algumas vezes pode parecer levar à escrita de casos de uso

Preciso de um editor que “escute” minhas palavras e gere um histórico com meus discursos…

Page 26: Arquiteturas de Software

Um exemplo de narrativa

“Pedro está interessado em comparar paisagens do litoral nordestino com praias da costa espanhola usando padrões de fotografia. Ele tem acumulado e classificado dados nos últimos cinco anos, exportando-os de forma que os dados possam ser manuseados por um pacote estatístico.”

“Pedro” é um pesquisador do INPE.

Page 27: Arquiteturas de Software

Requisitos funcionais

• Surgem das necessidades dos stakeholders• Explicitam quais funcionalidades o sistema deve

prover• Abordagens variam:

– Linguagem estruturada (análise de requisitos)– Casos de uso– Modelos formais– Estórias de Uso (XP1)

Page 28: Arquiteturas de Software

Requisitos não-funcionais

• Expressados na forma de atributos de qualidade

• A arquitetura deve identificar, analisar e suportar a implementação de atributos de qualidade

Page 29: Arquiteturas de Software

Atributos runtime

• Atributos runtime afetam a execução do sistema em produção

• Cenários devem ser descritos com foco em instâncias específicas da execução

Page 30: Arquiteturas de Software

Um acrônimo bem utilizado…

sability

eliability

erformance

ecurity

Impacto de fatores humanos

Taxa de falhas, modos,severidade, e recuperação

Velocidade do process., utilização de

recursos, tempo de resposta

Integridade dos dados, confidencialidade,

resistência a ataques

São atributos usados para definir o “guarda-chuva” das

qualidades.

Page 31: Arquiteturas de Software

Qualidades não ligadas à execução

• São mais ligadas à vida útil do sistema

• Cenários são expressados em termos de incidentes que ocorrem durante o desenvolvimento, deployment, ou operação do sistema

Page 32: Arquiteturas de Software

Outros acrônimos…

aintainability

estability

eusability

onfigurability

calability

volvability

ntegrity

Page 33: Arquiteturas de Software

Algum outro atributo de qualidade?

availability auditability modifiability feasibility compatibility backwards-compatibility

standards-compliance continuity-of-view friendliness customizability learnability

memorability enjoyability responsiveness schedulability verifiability analyzability reparability adaptability integrability

interoperability predictability extensibility dependability safety portability survivability

expendability expandability extensibility distributability flexibility

Page 34: Arquiteturas de Software

Performance

• Pode se manifestar de diferentes formas:– Latência– Rendimento– Eficiência de memória

• Diferentes métricas de desempenho devem ser aplicadas a diferentes partes do sistema

Page 35: Arquiteturas de Software

Usability

• Usabilidade apresenta vários aspectos:– Aprendizagem– Atratividade– Tempo para completar a

tarefa– Taxa de erros

• Para um bom resultado, deve ser analisado por um perito em usabilidade

Page 36: Arquiteturas de Software

Reliability

• Um campo complexo:– Falhas de hardware/software– Mean time to failure (MTTF)– Mean time to repair (MTTR)

• Demandas por Reliability dependem de sua criticalidade:– Indesejável– Perda de receita– Perda de vida

Availability =MTTF

MTTF+MTTR

Page 37: Arquiteturas de Software

Reliability

• Conceito varia para sistemas diferentes:– Sistemas financeiros podem se

tornar indisponíveis, MAS nenhum dado pode ser perdido

– Sistemas de Telecom podem perder dados MAS devem se recuperar agilmente

– Sistemas de controle devem manter o controle, em qualquer situação

• Capacidade de recuperação

Page 38: Arquiteturas de Software

Criticality

• Consequência do sistema de falha– Não-crítica

• Perturba a atividade

– Baixa• Perda de negóco, mas não séria

– Média• Perda de longo prazo para o negócio

– Alta• Prejuízo, perda de vida, etc.

Page 39: Arquiteturas de Software

Security

• Todo sistema trata de alguma maneira:– Ataque externo (network)– Fragilidade da política– Integridade dos dados

• Segurança é onerosa

• Técnicos especializados podem ajudar

Page 40: Arquiteturas de Software

Endereçando atributos de qualidade

• Narrativas (ou cenários)

• Comportamento

• Patterns (padrões)

• Estilos

• Táticas

Page 41: Arquiteturas de Software

Narrativas

• Uma narrativa ou cenário que reforça o atributo de qualidade buscado– Contexto– Ação– Resposta

Deve ser mensurável!

Preciso de um editor que “escute” minhas palavras e gere um histórico com meus discursos… a cada 15 minutos de fala deve ser gerado um documento

Page 42: Arquiteturas de Software

Performance

“A consulta no caixa eletrônico deve gerar um retorno em menos de 2 segundos.”

Page 43: Arquiteturas de Software

Referências e Leituras Recomendadas

• "Architectural Design." Chapter 3 of A Software Architecture Primer, by John Reekie and Rohan McAdam.

• Michael Hirsch, ``Making RUP agile,'' OOPSLA 2002 Practitioners Reports, 2002.

• William J. Brown, Hays W. McCormick III, and Scott W. Thomas. ``One Size Fits All,'' in AntiPatterns in Project Management, pp319--366. John Wiley and Sons, 2000.

• Frederick P. Brooks Jr. The Design of Design. Turing Award Lecture, 2001.

Page 44: Arquiteturas de Software

Visões contempladas na arquitetura de software

Page 45: Arquiteturas de Software

Um elefante…

Baseado numa fábula indiana.

Uma cobra!

Uma corda?

É como um leque! Uma

árvore!

Uma parede!

Um arpão!

Page 46: Arquiteturas de Software

Um sistema de software…

Vamos ver o deployment

E as atividades de tempo

real?

Quais as vantagens

estratégicas ?

Como vai funcionar a

funcionalidade de mineração de

dados?

Page 47: Arquiteturas de Software

Visão conceitual

Execução

Implementação

Visões da arquitetura

Uma visão expressa um aspecto particular da arquitetura

Alguns autores recomendam a construção de várias visões…

outros não…

Domain-level responsibilities

Estrutura Run-timeEstrutura Build-time

Page 48: Arquiteturas de Software

Componentes e conectores

Um componente relaciona um conjunto de responsabilidades

A arquitetura conceitual estrutura o sistema em termos de responsabilidades no nível do

domínio

Exemplos de responsabilidades:•PlayBackClipSequence•SynchronizeWithVideo•PrefetchClips

Um conector indica a comunicação entre

componentes

Page 49: Arquiteturas de Software

Interfaces externas

Interfaces externas (incluindo sistemas legados)

Algumas restrições físicas do sistema

conhecidas

Interfaces essenciais com

hardware

Nota: Um stakeholder não é um sistema externo!

Page 50: Arquiteturas de Software

Projetando uma arquitetura?

Atributos de qualidade

Requisitos do negócio

Requisitos funcionais

SR

S

Page 51: Arquiteturas de Software

Não desista…

Design é um processo iterativo.

A cada passo, descobre-se mais sobre o problema,

e mais ainda sobre a solução.

Vamos iniciar com um

procedimento simples…

Page 52: Arquiteturas de Software

1. Busque uma narrativa do sistemaA Sapataria Gomes pretende ter um plano de propaganda utilizando os mecanismos tradicionais, mas que necessita de um site web para ser o local central no qual os clientes podem conhecer os modelos e ordenar calçados com medidas e estilos customizados. Eles também querem usar o site web como interface de entrada para o sistema financeiro.

O gerente da Sapataria Gomes explicou:“O que nós queremos é desenvolver um kit com informações básicas para envio aos nossos clientes e receber de volta o seu pedido. Nos últimos anos, nós aprendemos muito sobre como ofertar calçados customizados e montamos o kit. Assim que recebemos as medidas e preferências dos clientes, nós podemos fabricar qualquer sapato – todos customizados – aplicando padrões de material, cores e acabamentos!”

Page 53: Arquiteturas de Software

2. Identifique conceitos chavesA Sapataria Gomes quer fazer publicidade utilizando meios convencionais, mas requerem um website como local central no qual os clientes podem obter informações sobre o kit base, entender os padrões existentes, e solicitar seu sapato customizado. Eles também querem usar o website como interface para o sistema financeiro.

O Gerente da Sapataria Gomes disse:“Queremos dissmeinar o kit base para nossos clientes e receber um retorno deles. … Nós podemos produzir qualquer sapato aplicando uma grande variedade de padrões …!”

Page 54: Arquiteturas de Software

3. Refine os componentes

Propaganda - conceito abstrato X

Website - implementação ?

Clientes - stakeholder Cliente do sistema contábil +

Página personalizada

Faixa de cliente Diversidade de produto

Kit base Medidas históricas de clientes

Sapato customizado Pedido do sapato Sistema contábil – sistema externo Acct I/F

Sapato produzido – sistema externo Shoe production

Padrões e acabamentos – parte do Kit base

Page 55: Arquiteturas de Software

4. Projete e conecte

HTTP

Acct I/F

Pedido

Página públicaPágina person.Cliente solicita

Variedade Produtos

Kit base

Templates

Produção calçados

Medidas dos clientes

Page 56: Arquiteturas de Software

Este é o ponto de partida

Outras iterações deverão melhorar a arquitetura de forma a melhor mapear as funcionalidades e

os atributos de qualidade

Restructurefor qualities

Extractdomain

elements

Elaboratefunctionality

Phase 1 Phase “N”

Page 57: Arquiteturas de Software

Refine a arquitetura• Acrescente ou

quebre componentes

• Explicite melhor as responsabilidades

• Identifique os estereótipos

• Crie os modelos de dados

• Explore os comportamentos

MuitoPesada

Um componente é um conjunto de responsabilidades

relacionadas. Quebre o

componente se as

responsabilidades não se

relacionam entre si …

Devem ser contempladas as

demandas de desempenho e disponibilidade

Page 58: Arquiteturas de Software

Um estereótipo indica que o componente (uma classe) possui algumas propriedades

ou atributos.

Estereótipos conceituais

• Um componente tem algum tipo de responsabilidade especial?– Interface– Armazenamento

persistente– Tempo de

resposta

Page 59: Arquiteturas de Software

Um exemplo de estereótipo

Audio In

Recording andClip Processing

TrackPlayback

Audio Out

Video Sync

Clip and TrackLibraries

Track and SceneConstruction

DiskRecorders

UserConsoles

Um diagrama que sintetiza aspectos da arquitetura. É útil para auxiliar na

compreensão de aspectos mais complexos.

Page 60: Arquiteturas de Software

Arquitetura da Sapataria Gomes com estereótipos

PublicPage

Personal Page

Customer accounts

Customer meas.

Product range

Order shoes

Customise shoes

Shoe productio

n

Browse products

TemplatesAcct I/F

HTTP

Page 61: Arquiteturas de Software

Modelos de dados

• Um modelo de dados captura a estrutura essencial do dado– Dados e

conectores– Dados

persistentes

Student

ID : integer

Subject

ID : integerpoints : integer

Course

name : String

enrolled-in

currently-taking

0..*

0..*

0..*

Page 62: Arquiteturas de Software

O que é um comportamento

Um sistema envolve

funcionalidades, uma estrutura

e comportamentos

• Comportamento reúne um conjunto de ações que o sistema executa

• Podem ser explorados da seguinte forma:– Papel a ser desempenhado– Casos de Uso– Diagramas de sequência

Page 63: Arquiteturas de Software

Como podemos explorar mais?

Agent

Analyzer DatabaseVisualization

toolkit

Web UI

Visualizer

Viz UI

Update manager

What to search forDiscovered data

Analyzed data

Data queryRequested data

Viz configuration

Visualization dataWebviz data

Viz structuring

Viz rendering

Update throttle

O sistema deve ter um comportamento em

resposta a uma atividade definida nas

narrativas

Page 64: Arquiteturas de Software

Explore eventos das narrativas

Pedro trabalha na UFCG. Ele prefere escolher o estilo de calçados. Ele ouviu falar da Sapataria Gomes e quer experimentar. Ele navega no site e escolhe alguns padrões. Ele prefere algo em tons claros de um couro liso num solado confortável. Ele preenche dados com suas preferências. Ele não quer fazer o pedido final ainda, ele deixa o pedido numa lista de produtos desejados.

browseWebsite

customiseShoe

saveToWishList

Page 65: Arquiteturas de Software

Eventos definem mapas de casos de uso

• Casos de uso ajudam a visualizar o fluxo– Mostra a sequência de

atividades– Atividade responde a um

evento– Cada vez que um evento

se dá, exercita-se uma responsabilidade

CompB

Data

CompC

CompARespA1

EventName

RespB3

RespC2

Mapas de caso de uso auxiliam a compreender o comportamento macro

Page 66: Arquiteturas de Software

Notação casos de uso

ContinuationAND-fork

OR-forkSEQ-fork

Page 67: Arquiteturas de Software

Sapataria Gomes (1)

PublicPage

Personal Page

Customer accounts

Customer meas.

Product range

Order shoes

Customise shoes

Shoe productio

n

Browse products

TemplatesAcct I/F

HTTP BrowseRange

Page 68: Arquiteturas de Software

Sapataria Gomes (2)

PublicPage

Personal Page

Customer accounts

Customer meas.

Product range

Order shoes

Customise shoes

Shoe productio

n

Browse products

TemplatesAcct I/F

HTTP customiseShoe

Uma conexão é necessária aqui?

Page 69: Arquiteturas de Software

O que não fazer…

Um AntiPadrão que ocorre frequentemente

nas arquiteturas de software…

Um anti-padrão descreve uma solução indesejável para um conjunto de fatores contextuais recorrentes.

Também ajuda a descrever como refatorar tal situação e obter uma solução desejável.

Page 70: Arquiteturas de Software

Versão object-oriented

• Uma classe controller rodeada por classes simples

• Um procedimento comum no mundo OO

• Obtida de requisitos que ditam soluções procedurais

• Um resultado pobre em termos de evolução

Everything Else

SimpleClass A

SimpleClass B

SimpleClass C Simple

Class D

SimpleClass E

Page 71: Arquiteturas de Software

• Um aplicação complexa ou componente lógico rodeado por componentes de interface ou dados

• Levam nomes como “controller” ou “manager”

• Indicam a incapacidade de decompor o sistema em função das responsabilidades retiradas do domínio

Versão arquitetural

CoursesPersonal

page

Systemcontroller

Userdata

Coursedata

Page 72: Arquiteturas de Software

Refatoramento

• Re-design object-oriented– Rever comportamentos– Identificar “lumps”– Agregar classes simples relacionadas

entre si

• Re-design arquitetural– Identificar todas as responsabilidades– Obter múltiplos componentes baseados

nas responsabilidades

• Ou ainda:– Jogar fora e reiniciar

AntiPatterns compilam experiências do mundo real na forma de problemas recorrentes & indicam soluções

Page 73: Arquiteturas de Software

Referências e Leituras Recomendadas

• "Conceptual Architecture." Chapter 4 of A Software Architecture Primer, by John Reekie and Rohan McAdam.

• Phillippe Kruchten, " Architectural Blueprints—The “4+1” View Model of Software Architecture", in IEEE Software 12 (6) November 1995, pp. 42-50.

• R. J. A. Buhr, A. Hubbard,"Use Case Maps for Engineering Real Time and Distributed Computer Systems: A Case Study of an ACE-Framework Application", in IEEE 1996.