Arquiteturas de Software

1. Arquiteturas de Software Francilene Garcia Projeto I 2008.2

2. Conceitos Básicos

3. Um sistema computacional Nós temos tecnologia Podemos construí-lo

4. Um sistema computacional isolado… ? computador No espaço, ninguém escuta o seu

5. Stakeholders… QA Operador Consumidor Arquiteto Técnico Desenvolvedor CEO Cliente BillGates AdminSys CEO Fornecedor

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

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

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

9. É complicado.

10. Qual o papel da arquitetura? ? Leaning tower image from Gary Feuerstein. Other images from The Big Ball of Mud, by Yoder and Foote.

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

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

13. Definições… …e formam um todo que atendem a expectativas Um sistema é um conjunto de partes As partes se relacionam entre si…

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

15. Boletim Web (Blog) Disponibilidade Segurança Uma arquitetura em 3-camadas – muito utilizada em sistemas client-server e web

16. Processamento de imagem Desempenho Portabilidade O processamento tipo “pipeline” é muito utilizado em sistemas de tempo real e embarcados

17. Isto é tudo! • Questões?

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

19. Análise e Projeto Arquitetural

20. Arquitetura é arte? Fatores contextuais Arquitetura desejável Necessidades do Cliente Os clientes devem auxiliar no projeto da arquitetura desejável, sem esquecer os fatores contextuais

21. Fatores contextuais – para casas • Clima • Materiais disponíveis • Portabilidade • Riscos • Atividades

22. onstraints nablers isks “Fatores contextuais”? “OS-Z não é compatível” “OS-Z melhora a segurança” “OS-Z não tem tal facilidade” São exemplos de fatores.

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

24. Decisivos • Mudança…! • Estrutura organizacional • Desempenho do time

25. 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…

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

27. 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)

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

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

30. Um acrônimo bem utilizado… Velocidade do process., utilização de recursos, tempo de resposta erformance sability Impacto de fatores humanos Taxa de falhas, modos, severidade, e recuperação eliability Integridade dos dados, confidencialidade, resistência a ataques ecurity São atributos usados para definir o “guarda-chuva” das qualidades.

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

32. Outros acrônimos… aintainability volvability estability eusability ntegrity onfigurability calability

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

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

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

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

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

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

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

40. Endereçando atributos de qualidade • Narrativas (ou cenários) • Comportamento • Patterns (padrões) • Estilos • Táticas

41. 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!

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

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

44. Visões contempladas na arquitetura de software

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

46. 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 ?

47. 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…

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

49. 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!

50. SRS Projetando uma arquitetura? Atributos de qualidade Requisitos funcionais Requisitos do negócio