Abstrações de um Sistema

• Utiliza um conjunto selecionado de conceitos e regras de forma a focar em aspectos específicos de interesse num sistema.

• Visão do Sistema– Representação de um sistema a partir da perspectiva de

um ponto de vista definido.

Ponto de Vista ou Visão

de um Sistema

Banco de Dados

•Conceitual

•Lógico

•Físico

Envolvidos

•Usuário

•Arquiteto

•Implementador

Visão do Estilo

Estilo Arquitetônico

barroco

Visão do Projeto

Projeto da Arquitetura

Projeto de Engenharia

plantas

Visão da Realidade

ConstruçãoIgreja Bom Jesus de Matosinhos

Desenvolvimento Predial

Visões da Arquitetura

Arquitetura Corporativa

Composta de:

Arquitetura de Negócios

Arquitetura de Dados

Arquitetura das Aplicações ( Sistemas )

Arquitetura da Tecnologia da Informação

São orientados pelo

Estilo da Arquitetura

Estilo da Arquitetura

Compreende os princípios e os meios que permitem que se obtenha de forma mais efetiva a VISÃO DE PROJETO

Estilos de Arquitetura Disponíveis

Modelos Visuais

Baseado em Objetos

Baseado em Componentes

Baseado em Processos de Negócios

Orientado a Serviços

Baseado em Eventos

Arquitetura de Sistemas – Necessidade

•Toda a aplicação ( ou conjunto de aplicações ) tem uma arquitetura na qual foi construída ( mesmo que no seu desenvolvimento ela não tenha sido considerada )

•Uma arquitetura mal construída tornará a aplicação difícil de desenvolver, administrar e modificar

•Uma boa arquitetura elevará o nível de flexibilidade, controle e reusabilidade que se tem sobre a aplicação, o que tem como consequência a diminuição do tempo de desenvolvimento

Solução mais comum sobre Arquitetura

Aplicação B Aplicação CAplicação A

Arquitetura

Aplicação

B

Arquitetura

Aplicação

C

Arquitetura

Aplicação

A

•Investimento redundante em arquiteturas não adequadas

•Ciclo de desenvolvimento redundantes

•Maiores custos de projeto e manutenção da aplicação

•Má utilização dos recursos

Solução atual sobre Arquitetura

Aplicação CAplicação A Aplicação B

Arquitetura

Com Estilo

Consistente

•Arquitetura reusável e provada

•Desenvolvimento mais rápido e sustentável

•Ação gerencial simplificada

•Aplicações flexíveis capazes de responder a requisições de mudança

Fazem com que a estrutura do sistema:

• dependa da visão de baixo nível ( tecnologia )

•seja definida no início do desenvolvimento ( mudança nos requisitos invalidam tudo )

•não tenha nada com o domínio do problema

Metodologias Clássicas Resultam em sistemas difíceis de:

•Acompanhar

•Manter

•ModificarFuncional Dados Processos

Diagrama de Fluxo de Dados

Modelo de Entidade e Relacionamentos

Modelos Orientados a Objetos

Diagramas da UML

Correspondência clara entre os modelos dos domínios do problema, do projeto e da implementação

Desenvolvimento de Sistemas Orientados a Objetos

•Necessita ambientes de desenvolvimento extremamente rigorosos e formais, com pessoal altamente treinados

•Nos grandes projetos abstrações corretas são difíceis de realizar

•Modelos de objeto mal realizados criam mais problemas do que soluções

•O nível de granularidade dos objetos é muito baixo, o que torna complexo o controle da dependência entre eles

Componentes

Definição: Um pequeno grupo de objetos trabalhando agrupados a fim de prover uma função do sistema

Os objetos dentro do componente não são conhecidos por outra parte do sistema, exceto pelo próprio componente

Características dos Componentes

•Tem todas as características de um objeto

•Tem limites impostos pela plataforma para a qual foi projetado

•Podem existir independentes dos outros componentes, exceto daqueles que usa na mesma plataforma

•Tem uma interface fixa e comum a todos os demais componentes do sistema

•São auto descritos ( os seus clientes sabem como usá-los )

Componentes de Software

•Conjunto discreto, administrável de lógica

•Código que implementa um conjunto pré-definido de interfaces

•Não são aplicações inteiras

•Não rodam sozinhos

•São usados como peças de quebra-cabeça para resolver um problema maior

•Um componente que resolve um determinado problema pode ser comprado e combinado com outros para resolver um problema maior

Componente de Software: ExemploComponente Cálculo de Preço FinalManuseia informações sobre o preço de um conjunto de produtos, fornecendo o preço total da compra

Baseado num conjunto de Regras de Definição de Preços

•Preços unitários dos produtos

•Quantidade de itens de produto comprados

•Desconto de quantidade/ cliente / região

•Sobretaxas ( impostos, transporte )

Pode ser Usado:•Serviço de Correio para definir o preço de remessa de pacotes

•Fabricante de automóveis para descriminar o preço do automóvel vendido

Separação da Interface e da sua Implementação

Interface do Componente

•Define o contrato do componente com o código do outro componente que o chama

•Esconde de seus clientes os detalhes de sua construção

•Permite que seus clientes somente tratem com os resultados finais de suas próprias operações

Implementação do Componente

•Lógica da programação interna, escondida de seus clientes

•Pode ser mudada sem alterar do código de seus clientes

Desenvolvimento Baseado em Componentes

•Um sistema complexo pode ser considerado como um conjunto composto de um número arbitrário de pequenos sistemas coesivos ( componentes )

•Cada componente é construído para implementar um conjunto definido de responsabilidades

•Cada componente é auto contido e acoplado a outros componentes

•Componentes são projetados para serem utilizados dentro de uma plataforma que integra todos os componentes numa aplicação

Plataforma baseada em Componentes

•Facilita a construção, administração e manutenção de componentes

•Deve ser padronizada

Deve conter:

•Ferramentas para desenvolver componentes

•Um Container para gerenciar os componentes utilizados:

Ambiente runtime para executar os componentes

Inclui conjunto de serviços que os componentes necessitam

•Ferramentas para implementação e manutenção

Customização de componentes para ambientes específicos

Plataforma baseada em Componentes

•Permite o desenvolvimento e a utilização de sistemas baseado em componentes

•Cria instâncias runtime de componentes

•Permite a componentes descobrir e se comunicar com outros componentes

•Provê serviços comuns adicionais, como:

Persistência

Transações

Independência de localização

Segurança

Monitoramento

Uso de Componentes: VantagensTécnicas

•A complexidade é melhor administrada, permitindo melhor qualidade nas soluções

•Funcionalidade técnicas ( não de negócios ) é concentrada na plataforma

Negócios

•Produtos de melhor qualidade

•Tempo menor para desenvolvimento de sistemas

•Melhor utilização de recursos humanos

•Habilidade de resposta a mudanças

•Custo reduzido

•Alto reuso para projetos futuros

Uso de Componentes: Desvantagens

•Os componentes são fortemente acoplados uns aos outros: uma mudança no código de um deles pode levar a mudanças nos demais

•A administração da complexidade da dependência entre os componentes em grandes sistemas é difícil: um componente ainda tem que saber muito sobre os demais ( aos quais se acopla )

•As soluções proprietárias:

( DCOM – MS, CORBA )

Serviço

Um comportamento provido por um componente, baseado somente numa interface do tipo de contrato

O conjunto de contratos ( sub-serviços ) caracteriza um serviço de negócios

Visão de Serviços de Negócios

•Tem um contrato, o qual consume e produz

Documentos de Negócios

•Integra várias aplicações para resolver

Problemas de Negócios

Não se pensa em linhas de código Java ou Cobol

Em vez de se ver dados

Serviço: Capacitação em Inglês no nível B

Consumidor: Aluno

Provedor: Escola

Contrata

Procura / Coordena / Integra sub-serviços:

Aluguel da sala, Limpeza, Pintura, Oferta de aulas, Instalação do Laboratório

Diretório de Serviços disponíveis

Jornal

Páginas Amarelas

Lógica de Negócios

DadosApresentação

PublicaçãoArquitetura

Orientada a

Serviços

- SOA -

SOA - Características Arquiteturais

•Distribuída: os elementos funcionais da aplicação são utilizados em múltiplos sistemas ( provedor, consumidor, publicador ), localizados em pontos diferentes

•Acoplamento Fraco: as ligações entre os elementos funcionais não são fixas ou rígidas, podendo ser assíncronas

•Escalável: novos elementos podem ser agregados, um serviço pode ser composto de outros serviços, sistemas legados, sistemas de pacotes

•Baseada em Padrões: independente de vendedores específicos

Tecnologias Básicas dos Serviços

Web Services

Conjunto de padrões tecnológicos emergentes:

WSDL – Web Services Defination Language

UDDI – Universal Description Descovery and Integration

SOAP – Simple Object Acess Protocol

Integrados por XML

Para saber mais:

• Dissertação de Mestrado:– Um Arcabouço Baseado em Componentes,

Serviços Web e Arquivos Abertos para Construção de Bibliotecas Digitais de Pablo A Roberto, Março de 2006.