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 Arquiteto Consumidor Técnico Desenvolvedor CEO Cliente BillGates AdminSys CEO Fornecedor

Outros sistemas… Ativos Gerador de Relatórios Contabilidade Infra Rede Labs Estudantes Cadastros

Oportunidades e riscos… Impostos Venda fraca de sistemas Mercado imaturo Venda acelerada de sistemas Construção de imagem Entrada na Bolsa BillGates Desempenho fraco Chega tarde ao mercado

Restrições e aspectos críticos… Falta desenv. de BD Sistema Operacional Alta oferta de desenv. Java Processador + rápido Legislação Sistemas Legados Ética e meio ambiente Políticas Padrões

É 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 Arquitetura define a estrutura do sistema Primeira release libera o core do sistema “The evolutionary delivery lifecycle model” (Rapid Development, Steve McConnell) A arquitetura desempenha um papel vital na definição da estrutura do sistema, desde cedo no ciclo de vida do desenvolvimento

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

Definições… …e formam um todo que atendem a expectativas Um sistema é um conjunto de partes 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) Disponibilidade Segurança Uma arquitetura em 3-camadas – muito utilizada em sistemas client-server e web

Processamento de imagem Desempenho Portabilidade May wnt to configure different algoritthms O processamento tipo “pipeline” é muito utilizado em sistemas de tempo real e embarcados

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? Fatores contextuais Arquitetura Necessidades do Cliente Arquitetura desejável 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”? isks “OS-Z não é compatível” onstraints “OS-Z melhora a segurança” “OS-Z não tem tal facilidade” nablers São exemplos de fatores.

Tipos de fatores contextuais São buscados em vários lugares: Mercado/concorrência Empresas Tecnologia Políticas “O time de desenvolvimento da India…” “A legislação restringe falhas …” “Uma versão atualizada de …” “Padrão 3576 requer…” “A forte capacidade de desenvolvimento Java…” “Esta janela de oportunidade…”

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… Vorpal – coined by Lewis Carroll, for poem Jabberwocky. Vorpal is commonly assumed to mean "deadly" or "extremely sharp", or perhaps to imply that the blade has magical properties

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… erformance Velocidade do process., utilização de recursos, tempo de resposta sability Impacto de fatores humanos Taxa de falhas, modos, severidade, e recuperação eliability ecurity 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 volvability estability eusability ntegrity onfigurability calability

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: Availability = MTTF MTTF+MTTR 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

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 Baixa Média 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: Segurança é onerosa 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 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 Deve ser mensurável!

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, pp 319--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

Baseado numa fábula indiana. Um elefante… Uma parede! É como um leque! Uma árvore! Um arpão! Uma corda? Uma cobra! Baseado numa fábula indiana.

Um sistema de software… E as atividades de tempo real? Como vai funcionar a funcionalidade de mineração de dados? Vamos ver o deployment Quais as vantagens estratégicas ?

Alguns autores recomendam a construção de várias visões… outros não… Visões da arquitetura Uma visão expressa um aspecto particular da arquitetura Visão conceitual Implementação Domain-level responsibilities Execução Estrutura Build-time Estrutura Run-time Alguns autores recomendam a construção de várias visões… outros não…

Componentes e conectores Um componente relaciona um conjunto de responsabilidades Exemplos de responsabilidades: PlayBackClipSequence SynchronizeWithVideo PrefetchClips Um conector indica a comunicação entre componentes A arquitetura conceitual estrutura o sistema em termos de responsabilidades no nível do domínio

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 SRS Requisitos funcionais Requisitos do negócio

Vamos iniciar com um procedimento simples… 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 sistema A 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 chaves A 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 Cliente solicita Página person. Página pública Medidas dos clientes Pedido Kit base Variedade Produtos Templates Acct I/F Produção calçados

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

Devem ser contempladas as demandas de desempenho e disponibilidade Refine a arquitetura Acrescente ou quebre componentes Explicite melhor as responsabilidades Identifique os estereótipos Crie os modelos de dados Explore os comportamentos Um componente é um conjunto de responsabilidades relacionadas. Quebre o componente se as responsabilidades não se relacionam entre si … MuitoPesada Devem ser contempladas as demandas de desempenho e disponibilidade

Estereótipos conceituais Um componente tem algum tipo de responsabilidade especial? Interface Armazenamento persistente Tempo de resposta Um estereótipo indica que o componente (uma classe) possui algumas propriedades ou atributos.

Um exemplo de estereótipo Um diagrama que sintetiza aspectos da arquitetura. É útil para auxiliar na compreensão de aspectos mais complexos.

Arquitetura da Sapataria Gomes com estereótipos HTTP Personal Page Public Page Browse products Order shoes Customise shoes Shoe production Templates Acct I/F Customer accounts Customer meas. Product range

Modelos de dados Um modelo de dados captura a estrutura essencial do dado Dados e conectores Dados persistentes enrolled-in Student Course 0..* ID : integer name : String 0..* currently-taking Subject 0..* ID : integer points : integer

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? O sistema deve ter um comportamento em resposta a uma atividade definida nas narrativas Agent Analyzer Database Visualization toolkit Web UI Visualizer Viz UI Update manager What to search for Discovered data Analyzed data Data query Requested data Viz configuration Visualization data Webviz data Viz structuring Viz rendering Update throttle

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 CompA RespA1 EventName RespB3 RespC2 Mapas de caso de uso auxiliam a compreender o comportamento macro

Notação casos de uso AND-fork Continuation OR-fork SEQ-fork

Sapataria Gomes (1) HTTP Personal Page Public Page Browse products BrowseRange HTTP Personal Page Public Page Browse products Order shoes Customise shoes Shoe production Templates Acct I/F Customer accounts Customer meas. Product range

Uma conexão é necessária aqui? Sapataria Gomes (2) customiseShoe HTTP Personal Page Public Page Uma conexão é necessária aqui? Browse products Order shoes Customise shoes Shoe production Templates Acct I/F Customer accounts Customer meas. Product range

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 Simple Class B Simple Class A Everything Else Simple Class C Simple Class E Simple Class D

Versão arquitetural System controller 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 Courses Personal page System controller Course data User data

Refatoramento Re-design object-oriented Re-design arquitetural 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.