Introdução à Arquitetura de Software

Apresentação em tema: "Introdução à Arquitetura de Software"— Transcrição da apresentação:

1 Introdução à Arquitetura de Software
Mestrado em Informática PUC Minas Prof. Humberto Torres Marques Neto Abril / 2009

2 Objetivos Apresentar os conceitos básicos de arquitetura de software
Definir o papel do Arquiteto de Software Descrever um processo simples de arquitetura de software Promover discussões e reflexões para construção de uma arquitetura de software ubíquo

3 Referências Bibliográficas Básicas
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. The unified software development process. Addison Wesley, 1998. BOOCH, Grady. Handbook of software architecture. IBM Corporation, 2004. PRESSMAN, Roger S. Engenharia de Software. 6 ed. McGraw-Hill, 2006.

4 Como a falta de definição arquitetural pode comprometer...
... a promoção de venda on-line de passagens aéreas; ... o uso do comércio eletrônico na véspera do Dia das Mães; ... a declaração anual de imposto de renda; ... a criação de um para cada aluno de graduação da PUC; ... o acesso externo às bases de dados da ACM e do IEEE.

5 Dimensões da Complexidade de Software
Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance An average software project people - 3-9 month duration - 3-5 external interfaces - Some unknowns & risks Defense Weapon System Telecom Switch National Air Traffic Control System Commercial Compiler Embedded Automotive Software Large-Scale Organization/Entity Simulation Lower management complexity - Small scale - Informal - Single stakeholder - “Products” CASE Tool Higher management complexity - Large scale - Contractual - Many stake holders - “Projects” Small Scientific Simulation IS Application Distributed Objects (Order Entry) Enterprise IS (Family of IS Applications) Defense MIS System IS Application GUI/RDB (Order Entry) Business Spreadsheet Lower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performance Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

6 Ilusão de simplicidade
Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

7 Conceitos errados sobre Arquitetura de Software
Arquitetura são modelos e papéis. <Minha tecnologia favorita> é arquitetura. Trabalho unicamente do arquiteto de software. Arquitetura é uma ciência exata. Arquitetura é uma arte. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

8 O que é Arquitetura de Software?

9 O que é Arquitetura de Software?
A arquitetura de software direciona decisões significativas sobre a organização do sistema de software os elementos estruturais e suas interfaces que irão compor o sistema, bem como os seus respectivos comportamentos especificados a partir da colaboração entre esses elementos a composição dos elementos estruturais e comportamentais em cada sub-sistema o estilo arquitetural que direciona a organização desses elementos, suas colaborações e composições.

10 O que é Arquitetura de Software?
Entretanto, de acordo com os autores do Processo Unificado (Jacobson, et. al.) A arquitetura de software não está interessada apenas na estrutura e no comportamento do sistema, mas, também no seu uso, na sua funcionalidade, na sua performance, na sua resiliência, na sua capacidade de reuso, na sua compreensibilidade, na sua economia, nas restrições tecnológicas e trade-offs, e, por fim, na estética do software.

11 O que é Arquitetura de Software?
“A arquitetura de um software é a estrutura ou estruturas do sistema, o que compreende componentes de software, propriedades desses componentes que são visíveis externamente e o relacionamento entre eles”, Paul Clements, et. al. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

12 O que é Arquitetura de Software?
“A arquitetura de um sistema de software compreende um conjunto de componentes, conexões e restrições de sistema e de software; um conjunto de necessidades de stakeholders; uma lógica que demonstra que se os componentes, conexões e restrições definem um sistema que se implementando irá atender as necessidades dos stakeholders”, Barry Boehm, et. al. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

13 O que é Arquitetura de Software?
“A Arquitetura de Software é a organização fundamental de um sistema, incluindo seus componentes, o relacionamento entre esses componentes e com o ambiente e os princípios que definem o desenho e a evolução dos componentes.”, IEEE 1471/2000 Recommended Practice for Architectural Description of Software-Intensive Systems. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

14 O que é Arquitetura de Software?
“A Arquitetura de Software inclui o conjunto de decisões significativas sobre a organização de um software, tais como, a seleção dos elementos estruturais e suas interfaces; o comportamento entre esses elementos; a composição destes elementos estruturais e de comportamento em subsistemas maiores e o estilo arquitetural que guia esta organização.”, Booch, Kruchten, Reitman, Bittner, and Shaw. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

15 Por que é necessário definir a Arquitetura de um Software?
Todo sistema em produção possui uma arquitetura de software. Se você não investiu tempo e cuidado para construí-la, ela pode ser muito diferente do que você esperava! “Arquitetura de software é o conjunto de decisões que, se feitas incorretamente, podem causar o cancelamento do projeto.”  – Eoin Woods Palace 2, Rio de Janeiro. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

16 Por que é necessário definir a Arquitetura de um Software?
Precisamos de uma arquitetura para: Entender o sistema Organizar o desenvolvimento Promover o reuso Evoluir o sistema

17 Por que é necessário definir a Arquitetura de um Software?
Entender os sistemas modernos é uma atividade desafiadora porque: eles possuem comportamentos complexos eles funcionam em ambientes complexos eles são tecnologicamente complexos eles frequentemente combinam sistemas distribuídos, plataformas e produtos comerciais (SO e SGBDs, por exemplo) e também reusam componentes e frameworks eles precisam satisfazer a demanda de indivíduos e organizações em alguns casos, eles são tão grandes que precisam ser divididos em vários projetos

18 Por que é necessário definir a Arquitetura de um Software?
Organização do desenvolvimento uma boa arquitetura de software é aquela que explicitamente define as interfaces entre os envolvidos no projeto para reduzir os possíveis problemas de comunicação Promoção do reuso uma boa arquitetura de software ajuda o desenvolvedor conhecer onde procurar e como encontrar elementos reutilizáveis

19 Por que é necessário definir a Arquitetura de um Software?
Evolução do sistema softwares devem ser resilientes e tolerantes a mudança uma arquitetura ruim pode prejudicar a evolução do sistema decorrente das mudanças do ambiente

20 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Arquiteto de Software Pessoa, time ou organização responsável pela arquitetura de um software Responsável por decisões, realizadas, normalmente em retaguarda Não é um designer de auto nível precisa avaliar a viabilidade da solução Não é o gerente de projeto Não é um especialista de tecnologia Não é um “lobo solitário” deve ter liderança e habilidade de comunicação Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

21 Responsabilidades do Arquiteto de Software
Definir e validar a arquitetura do sistema Manter a integridade conceitual do sistema Avaliar e atacar os riscos do sistema Propor a ordem e o conteúdo dos releases do software (planos de iteração) Facilitar a comunicação entre os membros da equipe e resolver conflitos Orientar os membros da equipe Em conjunto com o gerente de projeto, deve ser a referência do sistema Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

22 Atividades do Arquiteto de Software
22

23 Atividades do Arquiteto de Software: gerenciar escopo do sistema
23

24 Atividades do Arquiteto de Software: definir arquitetura candidata
24

25 Atividades do Arquiteto de Software: realizar a síntese arquitetural
25

26 Atividades do Arquiteto de Software: refinar a arquitetura
26

27 Atividades do Arquiteto de Software: estruturar o modelo de implementação
27

28 Atividades do Arquiteto de Software: analisar o comportamento do software
28

29 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Arquitetura de Software: “Visão 4+1” (Clements, et. al. Documenting Software Architectures) Logical View Implementation View End-user Programmers Configuration management Functionality Use Case View Process View Deployment View Performance Scalability Throughput System integrators System engineering System topology Communication Provisioning Conceptual Physical Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

30 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Adaptação das Visões Nem todos os sistemas requerem todas as visões Processo simples (ignorar a visão de processo) Programa pequeno (ignorar a visão de implementação) Processamento simples (ignorar a visão de implantação) Alguns sistemas requerem visões adicionais Visão de dados Visão de segurança Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

31 Visão Lógica ou Visão de Projeto
Visão da arquitetura de software que engloba o vocabulário do problema e o espaço de solução, as colaborações que realizam os casos de uso, os sub-sistemas que permitem a decomposição do sistema e as interfaces com outros sistemas e com o próprio sistema como um todo. Foco em: Funcionalidades Abstrações chaves Mecanismos Separação de interesses e distribuição de responsabilidades Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

32 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Visão de Processo Visão da arquitetura de software que engloba as threads e processos que formam a concorrência do sistema e a sincronização de mecanismos. Foco em: Performance Escalabilidade Throughput Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

33 Visão de Implementação
Visão da arquitetura de software que engloba os componentes utilizados na compilação e o “versionamento” do software. Foco em: Gerência de configuração Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

34 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Visão de Implantação Visão da arquitetura de software que engloba os nós que formam a topologia de hardware utilizada pelo sistema. Foco em: Distribuição Comunicação Provisionamento Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

35 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Visão de Implantação Visão da arquitetura de software que engloba os nós que formam a topologia de hardware utilizada pelo sistema. Foco em: Distribuição Comunicação Provisionamento Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

36 Adaptação de transparência elaborada por Grady Booch (IBM Fellow)
Visão de Caso de Uso Visão da arquitetura de software que engloba os casos de uso que descrevem o comportamento do sistema como ele visto pelos usuários finais e demais envolvidos. Adaptação de transparência elaborada por Grady Booch (IBM Fellow)

37 Um exemplo: Sistema dos Hotéis ACME
Sistema para evolução da rede de hotéis ACME, que ganhou um financiamento do BNDES. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

38 Um exemplo: Sistema dos Hotéis ACME
Um processo didático e simplificado: Alinhar o projeto com a visão, objetivos, requisitos e restrições dos interessados. Desenvolver os requisitos arquiteturalmente significativos Identificar e atacar riscos e restrições técnicas. Modelar a arquitetura. Construir fisicamente a arquitetura. Avaliar a arquitetura. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

39 Um exemplo: Sistema dos Hotéis ACME
01. Alinhar o projeto com os princípios, visão, objetivos, requisitos e restrições dos interessados. Visão: Suportar o crescimento do hotel ACME e a automação dos principais processos de negócio que envolvem potenciais clientes e hóspedes. Princípios: Simplicidade, flexibilidade, alinhamento com negócio. Requisitos Funcionais: Reserva self-service Reserva Pagamento Login Check-in Check-out Cadastro de hóspede Registro de serviços Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

40 Um exemplo: Sistema dos Hotéis ACME
02. Desenvolver os requisitos arquiteturalmente significativos Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

41 Um exemplo: Sistema dos Hotéis ACME
02. Desenvolver os requisitos arquiteturalmente significativos Requisitos de qualidade/não-funcionais. O hóspede pode fazer sua reserva remotamente (WWW) e de forma segura. Pico de 1000 acessos simultâneos em alta temporada. Tempo de resposta para reserva pelo hóspede: 8 seg. Tempo de resposta para reserva por funcionário: 5 seg. A interface para o funcionário deve ser rica (gráfica, drag-n-drop , Ajax) e acessível pela intranet. Requisitos de infra-estrutura Disponibilidade do sistema de 99,9%. Estimativa de crescimento de 20% ao ano. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

42 Um exemplo: Sistema dos Hotéis ACME
02. Desenvolver os requisitos arquiteturalmente significativos Classificando requisitos de qualidade. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

43 Um exemplo: Sistema dos Hotéis ACME
02. Desenvolver os requisitos arquiteturalmente significativos Classificando requisitos funcionais. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

44 Um exemplo: Sistema dos Hotéis ACME
03. Identificar e atacar riscos e restrições técnicas. O sistema de autorização de cartões de crédito (SACC) é provido por terceiros e as transações serão realizadas através de webservices. O servidor de aplicações deve ser o Sun GlassFish. O SGBD deve ser o Oracle 10G. A aplicação web deve ser compatível com IE 6 e Firefox 2 ou versões superiores. Principais riscos identificados:Apesar de ser compatível com Java EE, o servidor de aplicações não é conhecido pelos desenvolvedores. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

45 Um exemplo: Sistema dos Hotéis ACME
03. Identificar e atacar riscos e restrições técnicas. Ações de mitigação de riscos e aos requisitos de qualidade mais severos (POC – Provas de Conceito) Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

46 Um exemplo: Sistema dos Hotéis ACME
04. Modelar a Arquitetura Explorar e avaliar opções arquiteturais de alto-nível.Prover um entendimento da estrutura para os patrocinadores e demais interessados. Levar em consideração: Desenho da rede pré-existente. Bancos de dados pré-existentes. Ambiente web. Configuração dos servidores. Uso de padrões. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

47 Um exemplo: Sistema dos Hotéis ACME
04. Modelar a Arquitetura Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

48 Um exemplo: Sistema dos Hotéis ACME
04. Modelar a Arquitetura Criar uma estrutura inicial para o modelo de design. Mostrar pacotes de desenho arquiteturalmente significativos. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

49 Um exemplo: Sistema dos Hotéis ACME
04. Modelar a Arquitetura Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

50 Um exemplo: Sistema dos Hotéis ACME
04. Modelar a Arquitetura Mecanismos de análise e desenho. Decisões táticas que irão realizar a arquitetura. Alguns mecanismos de análise: Persistência. Segurança. Gerência de transações. Troca de informações/Interoperabilidade. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

51 Um exemplo: Sistema dos Hotéis ACME
04. Modelar a Arquitetura Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

52 Um exemplo: Sistema dos Hotéis ACME
05. Construir fisicamente a arquitetura. Time (arquitetos, projetistas e desenvolvedores) escolhem cenários de risco e constroem juntos a arquitetura executável do sistema. Em processos como o UP, entre 5 a 20% dos requisitos mais prioritários e complexos são endereçados até o 3/10 do tempo do projeto. Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

53 Um exemplo: Sistema dos Hotéis ACME
05. Construir fisicamente a arquitetura. Objetivo: Reduzir os riscos do projeto. 1/10 do tempo do projeto. Arquitetura candidata 3/10 do tempo do projeto. Arquitetura executável Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes

54 Um exemplo: Sistema dos Hotéis ACME
06. Avaliar a Arquitetura O objetivo é rever o resultado e analisar alternativas. Avaliação do grau de atendimento dos requisitos de qualidade. Testabilidade da arquitetura. Utilização de checklists para validação. Métodos clássicos: ATAM, CBAM, SAAM e ARID (SEI / Carnegie Mellon). Ferramentas de análise estrutural e arquitetural podem auxiliar na avaliação arquitetura e conformidade do código. Rational Software Architect, SA4J, Metrics (plugin do Eclipse), SourceMonitor, Jdepend. ARID ATAM CBAM SAAM Adaptação de transparência elaborada pelo Prof. Marco Aurélio S. Mendes