Sistemas de Informação Distribuídos/Engenharia de Software para SIDs

IntroduçãoEditar

Não existe uma distinção formal entre a Engenharia de Software tradicional e a Engenharia de Software para Sistemas de Informação Distribuídos na literatura. A idéia central do capítulo é mostrar ao leitor que cuidados devemos ter na especificação de um sistema de informação distribuído para que fiquem claros quais componentes da arquitetura terão características de distribuição e como essa distribuição será feita.

O capítulo mostra um breve histórico da engenharia de software para depois apresentar os diferentes modelos de computação distribuída, no que tange o domínio de sistemas de informação. Dentro desses modelos apresentamos as suas características com relação à troca de mensagens, ao controle transacional e à distribuição dos dados.

Apresentada a parte mais formal, entramos nas tecnologias e tendências que consideramos interessantes para a implementação dos modelos apresentados. Componentes Distribuídos (CORBA, EJB, RMI, etc), Sistemas Orientados a Serviços, Arquitetura Orientadas a Serviço (SOA), Aplicações Compostas e Sistema de Sistemas (SoS).

Histórico da Engenharia de SoftwareEditar

O início da Engenharia de Software remete para a década de 1950. Segundo Boehm [1] na década de 50 a engenharia de software se assemelhava muito a engenharia de hardware, e os profissionais que trabalhavam com engenharia de software eram advindos de outras áreas tais como engenharia elétrica e matemática.

Na década de 60, a engenharia do software se distância da engenharia de hardware. Temos também algumas conferências na área, na qual a que mais se destaca é a 1968 NATO Conference on Software Engineering (inglês). Nesta década também vemos a utilização de linguagens de programação por pessoas não advindas da área de matemática, devido à estrutura dessas linguagens, são elas o COBOL e o FORTRAN. Segundo Boehm [1], a prática de codificar e arrumar, frequentemente utilizado nessa época, acabava pro criar um código spaguetti.

A década de 70 foi a década do surgimento de métodos formais para o processo de desenvolvimento de software. O modelo de desenvolvimento de software que ganhou mais destaque nessa época, sendo explicado até hoje nas disciplinas de engenharia de sofware, é o Modelo em cascata. Nesta época surge também o termo Crise do software, o qual se referia a dificuldade das técnicas de desenvolvimento de software em atender a demanda crescente por novos sistemas.

A procura da produtividade foi a marco de engenharia de software na década de 80, segundo Boehm [1]. A utilização de modelos orientados a objetos começaram a ser utilizados como ferramenta para a reutilização de código. Surgiu também o conceito de Fábrica de Software visando agregar reuso, performance e qualidade ao desenvolvimento de software, tornando o mesmo um processo formal dentro da fábrica. Em 1988 surge o modelo em espiral.

Na década de 90 é consolidado o modelo orientado a objetos (OO) e uma série de padrões de projetos são criados para o desenvolvimento OO. Surgem arquiteturas de software específicas para os diferentes domínios de aplicação. O surgimento de diversas ferramentas e metodologias também marcaram essa década. A UML surge como linguagem do modelagem mais utilizada no desenvolvimento de software. O surgimento da Internet torna distribuição uma característica comum aos sistemas de informação. Surge também o modelo Open Source de desenvolvimento e a Rational cria o RUP baseado no modelo em espiral.

A partir do ano 2000, surgem novos modelos que começam a ser utilizados na engenharia de software, tais como orientação a aspectos, métodos ágeis para desenvolvimento e Model Driven Development.

Modelos de computação distribuídaEditar

Os modelos de computação distribuída podem ser divididas em categorias, tais como: Cliente/Servidor, Arquitetura em Três camadas, Arquitetura em N camadas, Arquitetura de baixo acoplamento ou Clusterizada e P2P. Em seguida, é apresentado um breve descritivo sobre os modelos de computação distribuídos citados anteriormente.

Cliente/ServidorEditar

Segundo Berson [2], o modelo cliente servidor pode ser classificados conforme a característica de distribuição. Considere que o modelo tem três componentes básicos: dados, lógica da aplicação e apresentação. Esse três componentes podem estar no cliente e/ou no servidor e conforme a disposição desses componentes podemos classificá-los em cinco outros modelos, dentro da arquitetura cliente/servidor, são eles:

  • Apresentação Distribuída - neste modelo o servidor fica com os dados, a lógica de aplicação e a apresentação. O cliente fica somente com a apresentação, o exemplo clássico é uma aplicação web.
  • Apresentação Remota - este modelo difere do anterior somente na ausência de apresentação no servidor. Como exemplo temos uma aplicação clássica cliente/servidor implementada em Delphi, sem regram de negócio na interface.
  • Lógica Distribuída - neste modelo temos a distribuição da lógica da aplicação, ou seja, ela está tanto no cliente, como no servidor. A apresentação fica no cliente e os dados no servidor. Como exemplo temos uma aplicação em Visual Basic, em que o lado cliente, além de ter apresentação, tem regras de negócio junto com a interface visual.
  • Gerenciamento Remoto de Dados - nesta arquitetura a apresentação e a lógica de aplicação ficam no cliente e somente os dados ficam no servidor. Como exemplo, uma aplicação que somente o SGBD fica em no servidor.
  • Dados Distribuídos - neste caso, os dados é que são distribuídos, portanto, ficam tanto no cliente como no servidor. A apresentação e a lógica da aplicação ficam no cliente. Uma aplicação móvel que sincroniza os dados com o servidor somente quando possível, é um bom exemplo nesse caso.


Três CamadasEditar

Nesse modelo, separamos a aplicação em três unidades funcionais independentes: dados, lógica de aplicação e apresentacão. Com essa independência podemos colocar cada unidade em um servidor independente. Aplicações web que utilizam um servidor de aplicação, normalmente seguem esse modelo.

N CamadasEditar

Normalmente quando uma aplicação fornece serviços de diferentes formas, não se limitando a disponibilizar somente uma interface gráfica ao cliente, ela segue o modelo N Camadas. Os servidor de aplicações, tais como WebSphere, fornecem o middleware necessários para a implementação de arquiteturas bem rebuscadas e com uma série de funcionalidades: troca assíncrona de mensagens, web services, transações distribuídas, etc.

Baixo Acoplamento ou ClusterizadaEditar

Neste modelo, uma série de máquinas são combinadas para realizar uma tarefa, a qual é dividida em uma série de sub-tarefas que podem ser executadas em paralelo. Desta forma, é utilizada de forma mais eficiente o poder computacional do cluster computacional.

P2PEditar

Na arquitetura P2P, todas as máquina da rede podem exercer papel de cliente ou de servidor, conforme a situação do momento, resultando na ausência de um servidor central.

Proposta de arquiteturasEditar

Em um trabalho 2001 [3] Morisawa propõe nove arquiteturas para a distribuição de sistemas de informação baseado na arquitetura cliente/servidor. Seguindo o mesmo modelo da arquitetura cliente/servidor, Morisawa considera que uma aplicação pode ser dividida em três componentes básicos: dados, lógica de aplicação e apresentação. Morisawa também propõe uma classificação para o estilo de comunicação entre estes três componentes, são elas: mensagem transacional, mensagem por query e por notificação. A seguir apresento uma breve descrição dos nove estilos de arquiteturas propostas por Morisawa:

  • Transação Centralizada - Nessa arquitetura, temos duas máquinas uma cliente e uma servidora. A troca de mensagem entre as duas máquinas se dá através de mensagem transacional.
  • Transação Distribuída - essa arquitetura difere da anterior somente pelo fato de termos duas ou mais máquinas servidoras. A comunicação entre o cliente e os servidores, e entre os servidores acontece por mensagem transacional.
  • Transação Assíncrona - o modelo se assemelha muito ao anterior, a diferença é que a troca de mensagem entre os servidores se dá por notificação.
  • Query Centralizada - difere do modelo de Transação Centralizada somente no estilo da mensagem, que nesse caso é por query.
  • Query Distribuída - nessa arquitetura temos uma máquina cliente e duas ou mais máquinas servidoras e a troca de mensagem é feita por query.
  • Query Assíncrona - esse modelo é semelhante ao anterior, diferindo somente na forma de troca de mensagens entre os servidores, sendo ela feita por notificação.
  • Notificação Centralizada - neste caso temos uma máquina cliente e uma servidora e a troca de mensagem é feita via notificação.
  • Notificação Distribuída - semelhante a arquitetura anterior, porém temos duas ou mais máquinas servidoras e a troca de mensagem entre servidores é feita por mensagem transacional.
  • Notificação Assíncrona - nessa arquitetura temos uma máquina cliente e duas ou mais máquinas servidoras e a troca de mensagens entre todos os nodos se dá por notificação.

Tecnologias para implementação de SIDsEditar

Até agora foram apresentados os modelos para implementação de sistemas de informação distribuídos. A partir desse ponto serão explicados as tecnologias para implementar esse modelos. São elas: Componentes Distribuídos (CORBA, EJB, RMI, etc), Sistemas Orientados a Serviços, Arquitetura Orientadas a Serviço, Aplicações Compostas e Sistema de Sistemas (SoS).

Componentes distribuídosEditar

A utilização de componentes distribuídos tiveram um grande impacto na engenharia de software. O desenvolvimento orientado a componentes, o uso de componentes distribuídos nos modelos arquiteturais (N Camadas) e o uso da arquitetura MDA são citados por Emmerich [4] como impactos na engenharia de software do uso de componentes distribuídos.

Em um capítulo anterior desse wikibook são explicadas as tecnologias mais utilizadas para a implementação de componentes distribuídos. O capítulo fala sobre CORBA, WebServices, EJB, DCOM .NET Remoting / Windows Communication Foundation (WCF) e Internet Communications Engine (Ice). O capítulo é o de Processos dentro de Interoperação.

Sistemas orientados a serviçoEditar

Nos últimos anos tem se falado muito de sistemas orientados a serviços, e esse termo vem ocorrendo em diversas áreas da informática: redes de computadores, engenharia de software, arquitetura de sistemas. A idéia central da engenharia de sistemas orientados a serviços (no inglês, Service-Oriented System Engineering - SOSE), segundo Tsai [5], é um novo paradigma que envolve computação orientada a objetos e a baseada em componentes. Ela divide os desenvolvedores em três entidades que colaboram entre si: os construtores de aplicação, os publicadores de serviços e os desenvolvedores de serviços. A responsabilidade dos desenvolvedores de serviços é desenvolvedor serviços com baixo acoplamento, os publicadores se responsabilizam por publicar esses serviços e os construtores de aplicação em construir aplicações baseadas nos serviços disponíveis ao invés do tradicional projetar e codificar.

Tsai [5] apresenta técnicas colaborativas para diferentes fases do desenvolvimento, são elas:

  • Especificação e Modelagem - MDA, Ontologias
  • Verificação - Checagem dinâmica do modelo, simulação dinâmica
  • Projeto - Reconfiguração dinâmica, composição e recomposição dinâmica (confiabilidade, segurança, vulnerabilidade)
  • Implementação - Sistemas automáticos de composição e geração de código
  • Avaliação em tempo de execução - Profiling dinâmico (confiabilidade, segurança, vulnerabilidade)
  • Operaração e Manutenção - Reconfiguração e recomposição dinâmicas, “re-verificação” e “re-validação” dinâmicas

Arquitetura orientada a serviços (SOA)Editar

A arquitetura orientada a serviços (do inglês, Service-oriented architecture - SOA) é uma arquitetura de sistema que sugere que a maioria das funcionalidades de um software pode ser disponibilizada como serviço. A seguir é apresentada uma lista de características desejáveis de uma arquitetura orientada a serviço.

  • Encapsulamento
  • Baixo Acomplamento
  • Contrato
  • Abstração
  • Reusabilidade
  • Poder ser usado em uma “composição”
  • Autonomia
  • Otimização
  • Discoverability - capaz de ser “descoberto” por mecanismos de busca.

Aplicações compostasEditar

A idéia principal de aplicações compostas é compor novas aplicações baseadas em aplicações já existentes. Normalmente, as aplicações devem ser projetadas para que possam ser "compostas" com outras, criando assim novas aplicações. Keyser [6] define quatro camadas de composição de aplicação:

  • Interface do Usuário - Web 2.0, portais, portlets, ajax, etc.
  • Composições de Serviços - Service Brokers.
  • Composições de Dados/Informação - Problema mais difícil de ser resolvido, ETL / Data Warehouses
  • Composição de Serviços fim-a-fim

Keyser [6] também descreve uma série características que os sistemas terão que ter para poderem ser usados em composições:

  • Identidade
  • Software as a Service (SaaS)
  • Sensível ao Contexto
  • Infra-estrutura de eventos - Web services são limitados nesse ponto
  • Repositórios e mecanismos de descobrimento - UDDI
  • Interface do Usuário
  • Frameworks de modelagem

Sistema de Sistemas (SoS)Editar

Sistemas de Sistemas (do inglês, System of System SoS) é um termo relativamente novo que vem sendo utilizado para designar sistemas que se integram de forma heterogênea em múltiplos níveis e em múltiplos domínios para resolver problemas inter disciplinares.

BibliografiaEditar

  1. 1,0 1,1 1,2 Boehm, Barry. "A View of 20th and 21st Century Software Engineering", ICSE’06, 2006.
  2. Berson, A. Client/Server Architecture, McGraw-Hill 1992, ISBN: 0070050767
  3. Morisawa, Yoshitomi; Torii, Koji. "An Architectural Style of Product Lines for Distributed Processing Systems, and Practical Selection Method", ESEC/FSE, 2001.
  4. Emmerich , Wolfgang. "Distributed Component Technologies and their Software Engineering Implications", ICSE’02, 2002.
  5. 5,0 5,1 Tsai, W. T. "Service-Oriented System Engineering: A New Paradigm", SOSE’05, 2005.
  6. 6,0 6,1 Keyser, Chris "Composite Applications: The New Paradigm"