ARQUITETURA DE SOFTWARE 1

Introdução • O que é arquitetura?

• Disposição das partes ou elementos de um edifício ou espaço urbano. [Aurélio]

• A estrutura e organização lógica de funcionamento de um sistema computacional. [Aurélio]

• Considerando essas definições, como desenvolver sistemas mais complexos, sem pensar em sua arquitetura??

• Como fica a qualidade desses sistemas sem “cuidar” da arquitetura??

2

Introdução • À medida que a complexidade e o tamanho dos

sistemas de software têm aumentado, engenheiros de software têm lançado mão de princípios de projeto, tais como a modularização e o ocultamento da informação, de modo a obter sistemas com maior qualidade e a um baixo custo.

• Para isso, o projeto da estrutura global do software (arquitetura de software) é uma questão que vem sendo considerada.

3

Motivação

• Projetos simples podem ser realizados por uma única pessoa • Pouca modelagem

• Ferramentas simples

• Processo simples

• Pouco projeto

• Pouca especialização para construir 4

Motivação

• Projetos complexos/Maiores exigem arquitetura • Mais modelagem

• Ferramentas mais poderosas

• Processos mais bem definidos

• Mais projeto

• Alta especialização para construção 5

Visões Arquiteturais • Para um edifício, são usados tipos diferentes de plantas para

representar diversos aspectos da arquitetura.

6

Visão 4+1 da Arquitetura - RUP

7

Visão Lógica

8

Visão de Implementação

9

Visão de Processo

• Focaliza assuntos como concorrência e paralelismo, tolerância a falhas e objetos distribuídos.

• Interoperabilidade

• Escalabilidade

• Disponibilidade

10

Visão de Implantação

11

Visão de Casos de uso

• Contém alguns cenários-chave usados para dirigir a descoberta e projeto da arquitetura e posteriormente, para validar as diferentes visões.

12

Arquitetura é o elemento central do desenvolvimento de sw

13

Introdução • A arquitetura de software é dita como tendo

principal papel na determinação da qualidade e da manutenibilidade do software.[Wasserman, 1996]

• Os atributos de qualidade dos sistemas de software são estreitamente relacionados às suas arquiteturas. [SEI, 2005]

• Atributos de qualidade:

• performance/desempenho, confiabilidade, manutenibilidade, portabilidade,...

14

O que é arquitetura de software?

• “Uma arquitetura de software deve conter: a definição dos elementos de projeto que compõe o software; a descrição das interações entre estes elementos; os padrões de composição dos elementos; e um conjunto de restrições sobre estes padrões.”

[Shaw 96]

15

O que é arquitetura de software?

• “A descrição da arquitetura de software é um passo intermediário entre a análise de requisitos e o projeto. Esta descrição consiste de elementos arquiteturais, as interações entre estes elementos, e as restrições sobre estes elementos e sobre as suas interações.”

[Perry 92]

16

Definições

• Instância arquitetural:

• Refere-se à arquitetura de um determinado sistema de software.

• Estilo arquitetural:

• Definem as restrições sobre a forma e a estrutura de uma família de instâncias arquiteturais. Exemplos: • Camadas (duas, três ou quatro camadas)

• Pipes and Filters

• Centrada na base de dados

• Cliente-Servidor

• Estilos resultantes da combinação de estilos arquiteturais.

17

Estilo arquitetural • Permite que um profissional (projetista, arquiteto ou

engenheiro) determine a classe a qual pertence a organização de um sistema.

• O que ajudam a identificar o estilo que retrata a arquitetura de software do sistema? • Características dos componentes (subsistemas) e conectores do

sistema

• Topologia da arquitetura

• Restrições semânticas

• Mecanismos de interação entre os componentes.

• O uso de estilos arquiteturais no desenvolvimento de software facilita:

• a comunicação entre as pessoas envolvidas no desenvolvimento

• o entendimento do projeto em desenvolvimento

18

Vantagens de uma arquitetura explícita • Comunicação entre stakeholders

• A arquitetura pode ser utilizada como o foco de discussão entre os interessados

• Reutilização em larga escala

• A arquitetura pode ser reutilizada em uma variedade de sistemas

• Análise do sistema

• A arquitetura pode ser utilizada para análise preliminar sobre a possibilidade do sistema atender seus requisitos não-funcionais

19

Atributos de arquitetura • Performance

• Localizar operações de modo a minimizar a comunicação entre subsistemas

• Segurança

• Utilizar uma arquitetura em camadas com recursos críticos localizados em camadas internas

• Disponibilidade

• Incluir componentes redundantes na arquitetura

• Manutenção

• Utilizar componentes especializados e auto-contidos

20

Arquitetura de referência • Alguns autores utilizam os termos estilos arquiteturais e

arquitetura de referência como sinônimos.

• Contudo, arquitetura de referência é: • Uma estrutura que provê uma caracterização das funcionalidades dos

sistemas de software de um dado domínio de aplicação.

• Exemplos:

• ADAGE um arquitetura de referência para o apoio ao desenvolvimento de sistemas de software no domínio de controle de aviões (Batory et al., 1995),.

• Arquitetura de referência para sistemas de comércio eletrônico (Bass et al., 2003).

• Arquitetura de referência para servidores WWW.

• Arquitetura de referência para sistemas baseados em componentes

• Arquitetura de referência para sistemas orientados a serviços 21

Arquitetura de referência

• Constituem um elemento fundamental para o desenvolvimento de linhas de produto (do inglês, product lines)

• Podem também ser consideradas como o primeiro e essencial passo para o desenvolvimento de frameworks de aplicação.

• Propor arquiteturas de referência para sistemas de um dado domínio de aplicação não é uma tarefa trivial.

22

Arquitetura de software de domínio específico • Base estrutural para a interoperabilidade de

componentes dentro de um domínio.

• Pode dar apoio a uma abordagem de desenvolvimento de domínio específico que possibilite a configuração de componentes reutilizáveis.

• Compreende um modelo de domínio, requisitos de referência, uma arquitetura de referência, infraestrutura ou ambiente de apoio e um processo de desenvolvimento.

23

Projeto arquitetural

• processo de construção de uma arquitetura de software explícita

• ligação entre os processos de especificação e de projeto detalhado de software

24

Projeto arquitetural

• Principais atividades

• Decomposição do sistema de software em subsistemas e componentes

• Identificação das interações e comunicação entre eles

• Modelagem arquitetural

25

Projeto arquitetural

• Problemas

• O projeto de arquiteturas de software específicas (ainda) é baseado em intuição e experiência

• Métodos pouco ajudam!

• Documentação (arquitetura e decisões)

• Modelagem arquitetural

26

Arquitetura de Software

• Elementos [Shaw 96]

• componentes

• conectores

• configurações

• estilos

27

Componente • Unidade de computação ou de armazenamento de

dados

• clientes, servidores

• databases

• filtros

• camadas

• ADTs

• Simples ou composto

28

Conector

• Elemento que modela

• interações entre componentes

• regras que governam tais interações

29

Conector

• interações simples

• chamadas de procedimentos

• acesso a variáveis compartilhadas

• interações complexas

• protocolos cliente-servidor

• protocolos de acesso a base de dados

• broadcast de eventos

• piped data streams

30

Configuração • Uma configuração arquitetural ou topologia é um grafo

de componentes e conectores que descrevem a estrutura arquitetural • aderência a regras de estilo

• Componentes compostos são configurações

31

Componentes e conectores

32

Arquitetura de uma ferramenta CASE

33

Tradutor de

projeto

Editor de

projeto

Gerador de

código

Analisador

de projeto

Gerador de

relatório

Editor de

programa

Repositório

de projeto

Sistema de controle robotizado de embalagem

34

Sistema

de Visão

Sistema de

identificação de

objetos

Controlador de

braço

Controlador

de garra

Sistema de

seleção de

embalagem

Sistema de

embalagem Controlador de

transportadora

Cliente-servidor

35

Rede de banda larga

Cliente 2 Cliente 4

Servidor de

catálogo

catálogo

Servidor de

vídeo

Arquivos de

clipes de filmes

Servidor de

fotografias

Fotografias

digitalizadas

Servidor de

hipertexto

Web de

hipertexto

Cliente 3 Cliente 2 Cliente 3 Cliente 4 Cliente 1

Arquitetura baseada em eventos

36

Subsistema

1

Subsistema

2

Subsistema

3

Subsistema

4

Manipulador de eventos e mensagens

Questões

• Como escolher subsistemas e componentes?

• Quais as suas propriedades? E responsabilidades?

• Como componentes interagem?

• Como incorporar e explicitar propriedades não-funcionais?

• Como descrever uma arquitetura?

37

Estilos Arquiteturais

Estilo Arquitetural

• Padrões ou idiomas de projeto que guiam a organização de módulos e sub-sistemas em sistemas completos. (Shaw & Garlan)

• Abstração de características de composição e interação recorrentes de um conjunto de arquiteturas. (Taylor)

• Idiomas de projeto “chave” que permitem a exploração de padrões estruturais e evolutivos adequados e que facilitam a reutilização de componentes, conectores e processo. (Medvidovic)

39

Estilo arquitetural

• Um estilo arquitetural define uma família de sistemas em termos de um padrão de organização estrutural.

• Um estilo arquitetural define • Um vocabulário de tipos de componentes e

conectores

• Um conjunto de restrições sobre como podem ser combinados

• Um ou mais modelos semânticos que especificam como as propriedades sistêmicas podem ser determinadas a partir das propriedades de suas partes

40

Estilos arquiteturais

• O modelo de arquitetura de um sistema pode estar em conformidade com um modelo ou estilo genérico

• Um conhecimento destes modelos pode simplificar o problema de definição de arquiteturas de sistemas

• Sistemas de grande porte, no entanto, são heterogêneos e não seguem um único estilo

41

Estilos Arquiteturais Shaw and Garlan, Software Architecture, 1996

• Independent Components

• Communicating Processes

• Event-Driven

• Data Flow

• Batch

• Pipes & Filters

• Data –Centric

• Repository

• Blackboard

• Call & Return

• Layered

• Object Oriented

• Main Program & Subroutine

• Virtual Machine

• Interpretter

• Rule-Based

42

Estilos

43

Layered systems [Shaw&Garlan94]

44

Padrões Arquiteturais POSA

Padrões

• Projetistas e arquitetos experientes…

• procuram aderir a princípios e promover boas práticas de design.

• usam padrões para documentar e reutilizar experiência comprovadamente boa em novos projetos (de software)

• Abordagem orientada a problemas

46

O que é um padrão?

• Um padrão é uma regra envolvendo 3 partes, que expressa uma relação entre um certo contexto, um problema e uma solução.

• Contexto

• uma situação que dá margem a um problema

• Problema

• o problema recorrente que surge em tal contexto

• Solução

• uma solução comprovada para o problema.

47

Contexto Exemplos

• "your environment is a distributed and possibly heterogeneous system with independent cooperating components".

• "interactive applications with a flexible human-computer interface".

• "building systems that support their own modification a priori".

48

Problema Exemplos

• “... From a developer"s viewpoint, there should essentially be no difference between developing software for centralized systems and developing for distributed ones”...

• “User interfaces are especially prone to change requests. When you extend the functionality of an application, you must modify menus to access these new functions”...

• “Software systems evolve over time. They must be open to modifications in response to changing technology and requirements”... 49

Solução Exemplos • “Introduce a broker component to achieve better

decoupling of clients and servers”...

• “Use the Model-View-Controller (MVC). MVC was first introduced in the Smalltalk-80 programming environment. MVC divides an interactive application into the three areas: processing, output, and input”...

• “Make the software self-aware, and make selected

aspects of its structure and behavior accessible for adaptation and change. This leads to an architecture that is split into two major parts: a meta level and a base level”...

50

Forças

• “As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves”.

• Forças?

• O termo força denota qualquer aspecto do problema que deve ser considerado ao propor a solução.

51

Forças Exemplos

• Requisitos que a solução deve atender

• “peer-to-peer inter-process communication must be efficient”

• Restrições a serem consideradas

• “inter-process communication must follow protocol XPTO”

• Propriedades desejáveis

• “changing software should be easy”

52

Forças MVC

• O padrão Model-View-Controller especifica duas forças:

• Deve ser fácil modificar a interface do usuário, mas...

• O núcleo funcional do software não deve ser afetada por essa modificação.

53

Forças

• Forças discutem o problema a partir de diversos pontos-de-vista e ajudam a compreensão de detalhes

• Forças podem complementar ou contradizer umas às outras.

• Extensibilidade de um sistema versus minimização de seu código

54

Padrões arquiteturais Buschman, 1996 • Padrões arquiteturais expressam esquemas fundamentais

para a organização estrutural de sistemas de software

• Padrões arquiteturais oferecem um conjunto pré-definido de subsistemas, especificam suas responsabilidades e incluem regras e orientações (guidelines) para organizar os relacionamentos entre eles.

55

Padrões arquiteturais Buschman, 1996

• Distributed Systems • Broker

• Interactive Systems • MVC

• PAC

• Adaptable Systems • Microkernel

• Reflection

• From Mud to Structure • Layers

• Pipes & Filters

• Blackborad

56

Categorias

Categorias de Padrões do livro POSA • Justificativa

• Organizar padrões em função da principal propriedade sistêmica global que incorporam

• Categorias • From Mud to Structure

• padrões que ajudam a evitar um ‘mar' de componentes.

• Distributed systems • suporte à estruturação de sistemas com componentes distribuídos

• Interactive systems • facilidade de adaptação de interface do usuário

• Adaptable systems • suporte à extensão de aplicações e sua adaptação à tecnologia em

evolução e à mudança em requisitos não funcionais 57

Client-server

58

Client-server Multi-tier

59

Broker

60

Publish-Subscribe

61

Peer-to-peer

62

Exemplos

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

Referências

• Resources for Software Architects

• http://www.bredemeyer.com/index.html

93