Padrões Arquiteturais

Agenda Conceitos

Padrões arquiteturais

Formato de um padrão arquitetural

Exemplos

Conceitos Arquitetura de software

descrição de subsistemas e componentes de um sistema de software e dos relacionamentos entre eles.

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

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

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

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

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

Arquitetura de uma ferramenta CASE

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

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

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

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?

Estilos arquiteturais Shaw and Garlan, 1996 Independent

Components

Communicating Processes

Event-Driven

Data Flow

Batch

Pipes & Filters

Data-Centric

Repository

Blackboard

Call & Return

Layered systems

Object Oriented

Main Program & Subroutine

Virtual Machine

Interpreter

Rule-Based

Layered systems [Shaw&Garlan94]

Estilos

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.

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

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.

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

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

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

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.

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”

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.

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

Padrões arquiteturais Buschman, 1996

From Mud to Structure Layers

Pipes & Filters

Blackborad

Distributed Systems Broker

Interactive Systems MVC

PAC

Adaptable Systems Microkernel

Reflection

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