Sistemas de Informação Distribuídos/Engenharia de Software para SIDs
Histórico da Engenharia de Software
editarO 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 de 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ída
editarOs 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
editarSegundo 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 Camadas
editarNesse 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
editarNormalmente 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
editarNeste 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
editarNa 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
editarEm 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 SIDs
editarAté 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
editarA 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ço
editarNos ú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
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
editarA 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)
editarSistemas 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.
Bibliografia
editar- ↑ 1,0 1,1 1,2 Boehm, Barry. "A View of 20th and 21st Century Software Engineering", ICSE’06, 2006.
- ↑ Berson, A. Client/Server Architecture, McGraw-Hill 1992, ISBN 0070050767
- ↑ Morisawa, Yoshitomi; Torii, Koji. "An Architectural Style of Product Lines for Distributed Processing Systems, and Practical Selection Method", ESEC/FSE, 2001.
- ↑ Emmerich , Wolfgang. "Distributed Component Technologies and their Software Engineering Implications", ICSE’02, 2002.
- ↑ 5,0 5,1 Tsai, W. T. "Service-Oriented System Engineering: A New Paradigm", SOSE’05, 2005.
- ↑ 6,0 6,1 Keyser, Chris "Composite Applications: The New Paradigm"