Introdução à Arquitetura de Software

Introdução à Arquitetura de Software

Mestrado em InformáticaPUC Minas

Prof. Humberto Torres Marques NetoAbril / 2009

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

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.

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 e-mail para cada aluno de graduação da PUC;

... o acesso externo às bases de dados da ACM e do IEEE.

Dimensões da Complexidade de Software

Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance

Lower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performance

Highermanagement complexity - Large scale - Contractual - Many stake holders - “Projects”

Lowermanagement complexity - Small scale - Informal - Single stakeholder - “Products”

Defense MIS System

Defense Weapon SystemTelecom

Switch

CASE Tool

National Air TrafficControl System

Enterprise IS(Family of ISApplications)

CommercialCompiler

BusinessSpreadsheet

IS ApplicationDistributed Objects

(Order Entry)

Small ScientificSimulation

Large-ScaleOrganization/Entity

Simulation

An average software project - 5-10 people - 3-9 month duration - 3-5 external interfaces - Some unknowns & risks

EmbeddedAutomotive

Software

IS ApplicationGUI/RDB

(Order Entry)

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

Ilusão de simplicidade


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

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.


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.


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



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



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



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


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.


Precisamos de uma arquitetura para:– Entender o sistema– Organizar o desenvolvimento– Promover o reuso– Evoluir o sistema


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


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


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

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 projetoNão é um especialista de tecnologiaNão é um “lobo solitário”

– deve ter liderança e habilidade de comunicação


Responsabilidades do Arquiteto de Software

Definir e validar a arquitetura do sistemaManter a integridade conceitual do sistemaAvaliar e atacar os riscos do sistemaPropor 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 conflitosOrientar os membros da equipeEm conjunto com o gerente de projeto, deve

ser a referência do sistema


Atividades do Arquiteto de Software

Atividades do Arquiteto de Software: gerenciar escopo do sistema

Atividades do Arquiteto de Software:definir arquitetura candidata

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

Atividades do Arquiteto de Software:refinar a arquitetura

Atividades do Arquiteto de Software:estruturar o modelo de

implementação

Atividades do Arquiteto de Software:analisar o comportamento do

software

Arquitetura de Software: “Visão 4+1”

(Clements, et. al. Documenting Software Architectures)


Logical View

End-user Functionality

Implementation View

Programmers Configuration management

Process View

PerformanceScalabilityThroughput

System integrators

Deployment View

System topologyCommunication

Provisioning

System engineering

Conceptual Physical

Use Case View

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


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


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


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


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


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


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.


Um exemplo: Sistema dos Hotéis ACME

Sistema para evolução da rede de hotéis ACME, que ganhou um financiamento do BNDES.


Um processo didático e simplificado:1. Alinhar o projeto com a visão, objetivos,

requisitos e restrições dos interessados.

2. Desenvolver os requisitos arquiteturalmente significativos

3. Identificar e atacar riscos e restrições técnicas.

4. Modelar a arquitetura.

5. Construir fisicamente a arquitetura.

6. Avaliar a arquitetura.



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



02. Desenvolver os requisitos arquiteturalmente significativos



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.



02. Desenvolver os requisitos arquiteturalmente significativos• Classificando requisitos de qualidade.



02. Desenvolver os requisitos arquiteturalmente significativos• Classificando requisitos funcionais.



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.



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)




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.



04. Modelar a Arquitetura



04. Modelar a Arquitetura– Criar uma estrutura inicial para o modelo de design.– Mostrar pacotes de desenho arquiteturalmente

significativos.





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.






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.



05. Construir fisicamente a arquitetura.– Objetivo: Reduzir os riscos do projeto.

3/10 do tempo do projeto.Arquitetura executável

1/10 do tempo do projeto.Arquitetura candidata



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.



Documents

Introdução à Arquitetura de Software