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

Introdução

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 Software

O início da Engenharia de Software remete para a década de 1950. Segundo Boehm 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 , 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 . 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ída

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/Servidor

Segundo Berson , 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 Camadas

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 Camadas

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 Clusterizada

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.

P2P

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 arquiteturas

Em um trabalho 2001 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 SIDs

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ídos

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 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ço

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 , é 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 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)

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 compostas

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

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.