Arquiteturas de Software

Arquiteturas de Software

Francilene Garcia

Projeto I

2008.2

Conceitos Básicos

Um sistema computacional

Um sistema computacional isolado…

No espaço, ninguém escuta o seu

?

Stakeholders…

Arquiteto

Operador

CEO Fornecedor

Técnico Desenvolvedor

AdminSys

Consumidor

QA

BillGatesCEO Cliente

Outros sistemas…

CadastrosLabs Estudantes

Infra Rede

ContabilidadeGerador de Relatórios

Ativos

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

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

É complicado.

Qual o papel da arquitetura?

Leaning tower image from Gary Feuerstein.Other images from The Big Ball of Mud, by Yoder and Foote.

??

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

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

Definições…

Um sistema é um

conjunto de partes

…e formam um todo que

atendem a expectativas

As partes se relacionam entre si…

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.

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

Processamento de imagem

Algorithmcontrol

ScalingRecognitionCompression

Modulescheduler

Imagestorage

Capture

O processamento tipo “pipeline” é muito

utilizado em sistemas de tempo real e embarcados

Desempenho

Portabilidade

Isto é tudo!

• Questões?

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.

Análise e Projeto Arquitetural

Arquitetura é arte?

Necessidadesdo Cliente

Arquitetura

desejável

Fatorescontextuai

s

Os clientes devem auxiliar no projeto da arquitetura

desejável, sem esquecer os fatores contextuais

Fatores contextuais – para casas

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

“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”

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…”

Decisivos

• Mudança…!

• Estrutura organizacional

• Desempenho do time

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…

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.

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)

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

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

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.

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

Outros acrônimos…

aintainability

estability

eusability

onfigurability

calability

volvability

ntegrity

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

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

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

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

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

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.

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

Endereçando atributos de qualidade

• Narrativas (ou cenários)

• Comportamento

• Patterns (padrões)

• Estilos

• Táticas

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

Performance

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

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.

Visões contempladas na arquitetura de software

Um elefante…

Baseado numa fábula indiana.

Uma cobra!

Uma corda?

É como um leque! Uma

árvore!

Uma parede!

Um arpão!

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?

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

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

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!

Projetando uma arquitetura?

Atributos de qualidade

Requisitos do negócio

Requisitos funcionais

SR

S

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…

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!”

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 …!”

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

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

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”

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

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

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.

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

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..*

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

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

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

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

Notação casos de uso

ContinuationAND-fork

OR-forkSEQ-fork

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

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?

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.

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

• 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

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

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.