arquitetura de sistemas

7/28/2019 Arquitetura de Sistemas

1/45

Arquitetura de Sistemas

Envolve os seguintes aspectos

Composio / Decomposio do Sistema ( Subsistemas / Mdulos )

Componentes e a Interao entre eles

Nveis / Camadas e a Interao entre eles ( Ordem / Estrutura )

Organizao das partes fsicas do software a serem implementadas

Restries do software ( naturais ou auto-impostas )

Descrio geral do software

Estrutura Esttica / Dinmica de um SistemaEstilo que orienta o desenvolvimento e a evoluo do software

Funcionalidade do software

Outras consideraes : reuso, desempenho, escalabilidade


2/45

Arquitetura de um Sistema

Definio: Representa a estrutura esttica ecomportamental de um sistema, compreendendo os

servios do sistema, realizados pelos componentes desoftware, que rodam nos processadores disponveis

Est associada a detalhes internos do software namedida que esses detalhes manifestam-se

externamenteNo pode ser representada por um simplesdiagrama: multifacetada


3/45

Est associada a:Uso

Funcionalidade

Desempenho

Resilincia

Reuso

Compreendibilidade

EconomiaRestries e compromissostecnolgicos

Esttica

Arquitetura de um Sistema


4/45

Todo sistema j criado tem sua

Arquitetura

Ela existe independente do seuconhecimento pelo projetista de sistemas


5/45

O Por Qu da Arquitetura

Uma abordagem adhoc leva a sistemas difceis de mudar ouadaptar

Decomposio de sistemas em partes menores torna o softwaremais fcil de entender, administrar, desenvolver, manter

Auxilia no desenvolvimento baseado em componentes

Auxilia desde o incio na administrao do desempenho

Leva a um reuso melhor

Influencia a segurana, a testabilidade, a manutenbilidade e aadministrao do sistema


6/45

Conceitos Bsicos da Arquitetura

duma Aplicao Corporativa

Decomposio

Componentes

Frameworks

Patterns ( Padres )

Nvelamento

Camadas ( Tiers )


7/45

Decomposio

Particionamento do sistema em partes menores, lgicas

Que tornam fcil a administrao de sua complexidade

Auxilia a definio e descrio das interfaces entre as diferentespartes do sistema, de forma a facilitar a sua iterao

Facilita a distribuio do software atravs de mltiplosprocessadores

Prov uma partio natural das tarefas de desenvolvimento e facilitaa distribuio das tarefas em equipes grandes


8/45

Decomposio com a UMLPacotes

Subsistemas

Mdulos


9/45

Componentes

Unidade coesa de software que prov um conjunto relacionado deservios e funes

til somente no contexto de um modelo padro( CORBA, EJB, DCOM )

Infraestrutura bsica para composio einterao do componente

Tem uma interface ( contrato entre o componente e a aplicao )

bem definida que permite a sua interao com outros componentesDebaixo de um mesmo modelo padro e com a mesma interfacepodem ser substitudos

Podem conter outros componentes


10/45

Por que usar componentes

Em relao ao software tradicional so maisfceis de manter e modificar

Tem o potencial de melhorar a produtividadecom o reuso e componentes pr-fabricados

Desenvolvimento de aplicaes mais flexveis

Podem ser comprados e vendidos na medidaque existir um mercado consolidado nesta rea

Facilitam a partio mais natural do softwareem unidades coesas


11/45

Granulao dos Componentes

Componentes de alta granularidade / Subsistemas de altonvel

Devem ter poucas dependncias, bem definidas

Disponibilizam capacidade de negcios discretas ecomplexas

Ex.: Mdulo de Controle de Estoques

Componentes de baixa granularidade

Comparvel com objetos tradicionais

Tem maior nmero de dependncias

Ex.: Java Beans


12/45

Componentes em UMLCom suas interfaces

Com seu comportamentoInterno

Diagrama de Atividades

Diagrama de Estado

Componente como um:

subsistema

mdulo executvel


13/45

Framework

Qualquer poro pr-definida de softwaredesenvolvido e testado para ser reusado em vriosprojetos de desenvolvimento de aplicaes numdomnio especfico

Tipo de micro arquitetura, abrangendo um conjuntode padres que trabalham em conjunto pararesolver um problema bsico, num domnio comum

Permite a especificao, agrupamento e reuso deelementos para se construir efetivamente algumsistema


14/45

Framework na UML

Estereotipo de

Pacote

Contendo

ColaboraesDiagramas


15/45

FrameworkModo de Utilizao

BibliotecaConjunto de componentes reusveis

Gabarito

Base para novas aplicaes

Desenvolvimento de um Framework

ser simples de se entender

prover documentao adequada

Identificar mecanismos concretos de sua prpriaextenso


16/45

Padres ( Patterns )

Soluo em um determinado contexto, que foiobtida atravs de experincia e se mostroueficaz para resolver um problema bsiconessa rea.

Utilidade

Capta conhecimento comprovado obtido atravs de anos deexperincia

Ajuda na soluo de problemas complexos encontrados emsituaes similares

Favorece a comunicao na equipe, provendo contexto bsicopara discusses


17/45

Padro MVC ( Design )

Como separar os objetos de entidade

da aplicao ( Model ) da maneiracomo estes so apresentados para o

usurio ( View ) e de como o usurio

faz o controle sobre os mesmos (

Controller )

Exemplo


18/45

Model

Sabe tudo sobre:

Os dados persistentes que devero ser mostrados

As operaes que sero aplicadas para transformar

os objetos

Sabe nada sobre:

As interfaces do usurio

Como os dados sero mostrados

As aes das interfaces usadas para manipular os

dados

Representa os dados da aplicao e as regras de negcioque governam o acesso e a atualizao desses dados


19/45

View

Refere-se ao objeto Model

Dispara as operaes de consulta do Model

para obter os dados e visualiz-los

Define como os dados sero visualizados

pelo usurio

Mantm consistncia na apresentao dos

dados quando o Model muda


20/45

Controller

Sincroniza as aes do View com as

aes realizadas pelo Model

Trabalha somente com sinais e no com

os dados da aplicao

Sabe os meios fsicos pelos quais os

usurios manipulam os dados no Model


21/45

Vantagens da utilizao do padro MVC

Mltiplos Views utilizando um mesmo

Model

Suporte fcil para novos tipos de usurio

do sistema

Projeto mais bem definido e modular

Facilidade de ampliao do sistema

Utilizao em sistemas distribudos


22/45

Dinmica do sistema em UML


23/45

Classes Gerais de Padres

RefernciaAnlise ( Negcios )

Arquitetnicos

Projeto ( Design )De Cdigo

Nvel deAbstrao

+

-


24/45

Pattern Arquiteturas de Referncia

Uma arquitetura geral e abstrata que pode ser instanciada para

situaes especficas:Completada, detalhada

Parametrizada, adaptada

Extendida, selecionada

Relacionada um certo tipo deorganizao

Telecomunicaes

Governo

Bancos

Tcnica

SOAMDA


25/45

Padres de Anlise

Exemplo:

Hierarquia de umaOrganizao

Modelos do domnio de sistemas ( contas ) emcontextos especficos ( finanas )

Repositrio - Fowler
http://www.martinfowler.com/ap2/index.htmlhttp://www.martinfowler.com/ap2/index.htmlhttp://www.martinfowler.com/ap2/index.htmlhttp://www.martinfowler.com/ap2/index.htmlhttp://www.martinfowler.com/ap2/index.html


26/45

Padres Arquitetnicos

Trata da estrutura dos sistemas , seuscomponentes, ambientes de processamento ecomo eles se relacionam entre si

Exemplo:

E-Business Patterns ( IBM )
http://www-106.ibm.com/developerworks/patterns/http://www-106.ibm.com/developerworks/patterns/http://www-106.ibm.com/developerworks/patterns/http://www-106.ibm.com/developerworks/patterns/


27/45

Padro de Aplicao Directly Integrated Single Chanel

para o Padro de Negcios Self-Service


28/45

Pattern Runtime para o Pattern de AplicaoDirect Integrated Single Chanel


29/45

Mapeamento de produtos Windows 2000 para o Patternde Aplicao Direct Integrated Single Chanel


30/45

Padres de Design

Usados a nvel de classes e objetos

Tipos:

De Criao: solues para configurao einicializao do design

Estrutural: estrutura de modo especfico asinterfaces e as relaes das respectivas classes

Comportamental: identifica caminhos nos quaisum grupo de classes interage com os demais,para alcanar um certo comportamento

Catlogo JavaPatterns - Sun
http://java.sun.com/blueprints/patterns/http://java.sun.com/blueprints/patterns/http://java.sun.com/blueprints/patterns/http://java.sun.com/blueprints/patterns/


31/45

Pattern de Criao

Exemplo

Pattern Singleton

Garante que uma classe tenha somente umainstncia e prov um ponto global de acesso a ela


32/45

Pattern Estrutural

Exemplo

Pattern Proxy

O objeto Proxy prov um mecanismo indireto de acesso

a outro objeto ( RealSubject ). Os dois objetos

trabalham integrados atravs de uma mesma interface (

Subject ).

Vantagem: acesso mais fcil ao sistema ( atravs de

Proxy ) quando existem restries ( por exemplo de

segurana )


33/45

Pattern Comportamental

Exemplo: Pattern Subject-Observer

Uma pessoa ( Observer ) tem interesse em certo produto ( Subject ). Elase registra esse interesse no sistema do fabricante, visando receberatualizaes ( update ) sobre o produto.

Quando o produto atualizado os Observer recebem notificaes damudana. Os Observer individualmente podem consultar o Subjectespecfico para saber detalhes.

EspecificaoComportamental


34/45

Patterns: Representao em UML

Uso de Colaborao: conjunto de objetos e seusvnculos, que interagem num certo contexto, paraimplementar certa estrutura ( Diagrama de Classes ) oucomportamento ( Diagrama de Interao ou Estados )


35/45

Pattern Subject-Observer

Especificao Estrutural


36/45

Nvelamento ( Camadas )

Pattern para decomposioTratar complexidade

Partio lgica de sistemas( subsistemas, mdulos )

Abstrai tipos especficos de funcionalidades (camadas funcionais )

Prov limites conceituais ( entre conjuntos deservio )

Agrupa, separa, restringe o uso de itens dosistema


37/45

Tipos de Nivelamento

Por Responsabilidades Camadas

Distribuio do sistema em diversos processoscolocados em mltiplos processadores ou num nico

Ex.: Arquitetura Cliente-Servidor

Por Reuso

Desenvolvimento do sistema de forma que os diversosnveis prestam servios aos outros nveis

Ex.:

Nvel de fornecimento de informaes ao usurio (Apresentao )

Nvel de servios gerais: log, tratamento de erros


38/45

Camadas ( tiers ) da Plataforma J2EE

Camadas

Componentes

Servios


39/45

Caractersticas Bsicas

Cada camada prov servios para as outras camadas

Existe baixo acoplamento entre as camadasO relacionamento entre as camadas hierrquico por natureza

Cada camada pode contar com a camada logo abaixo, no aocontrrio

No deve existir dependncia entre camadas que no sejam vizinhas

Camadas podem ter suas sub-camadas

Normalmente as camadas

Mais baixas: so mais fortemente ligadas ao hardware e ao sistemaoperacional ( servios bsicos )

Intermedirias: so a base para se construir diversos sistemas comcapacidade similar ( servios gerais )

Superiores: voltadas para as peculariedades do usurio


40/45

Nivelamento em UML

ArquiteturaNivelada


41/45

Arquitetura J2EE multi-camadas

Camadas

Cliente: interao do usurio

Apresentao: resultados das consultas de negcios

Negcios: principais regras de negcios

Dados: interface com o armazenamento dos dadospersistentes


42/45

Colocando tudo Junto

O que vem primeiro ?

Arquitetura do sistema

Anlise do sistema

Processo Interativo

Ao requisitos so entradas

importantes para se definir aarquitetura

Na medida que se trabalha naarquitetura v-se a necessidadede se ajustar ou clarear os

requisitos

Definir a Arquitetura muito mais um processoevolutivo

Ela toma forma na medida que as decises sotomadas considerando-se os requisitosespecficos e os compromissos do sistema


43/45


44/45


45/45

arquitetura de sistemas

Documents