Abstra

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

2
Ponto de Vista ou Visão de um Sistema

• Envolvidos
• Usuário
• Arquiteto
• Implementador

• Banco de Dados
• Conceitual
• Lógico
• Físico

3
Desenvolvimento Predial
Visão do Estilo Estilo Arquitetônico barroco
Visão do Projeto Projeto da Arquitetura Projeto de Engenharia plantas
Visão da Realidade Construção Igreja Bom Jesus de Matosinhos
4
Visões da Arquitetura
Arquitetura Corporativa
Composta de Arquitetura de Negócios Arquitet
ura de Dados Arquitetura das Aplicações (
Sistemas ) ? Arquitetura da Tecnologia da
Informação ?
São orientados pelo Estilo da
Arquitetura
5
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
6
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

7
Solução mais comum sobre Arquitetura

• 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

8
Solução atual sobre Arquitetura

• 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

9
Metodologias Clássicas

• Resultam em sistemas difíceis
  de
• Acompanhar
• Manter
• Modificar

Funcional Dados Processos

• 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

10
Diagrama de Fluxo de Dados
11
Modelo de Entidade e Relacionamentos
12
Modelos Orientados a Objetos
Correspondência clara entre os modelos dos
domínios do problema, do projeto e da
implementação
Diagramas da UML
13
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

14
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
15
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 )

16
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

17
Componente de Software Exemplo
Componente Cálculo de Preço Final Manuseia
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

18
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

19
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

20
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

21
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

22
Uso de Componentes Vantagens

• Té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

23
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 )

24
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
25
Não se pensa em linhas de código Java ou Cobol

• Tem um contrato, o qual consume e produz
• Documentos de Negócios
• Integra várias aplicações para resolver
• Problemas de Negócios

Em vez de se ver dados
Visão de Serviços de Negócios
26
Serviço Capacitação em Inglês no nível B
Consumidor Aluno
Contrata
Provedor Escola
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ágin
as Amarelas
27
Arquitetura Orientada a Serviços - SOA -
Publicação
Lógica de Negócios Dados
Apresentação
28
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

29
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
30
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.