SOP - Subject-Oriented Programming
By Augusto César Melo de Oliveira and Sabrina Bet

Na da década de 90, descobriu-se que a Engenharia de Software orientada a objetos não era suficiente para a resolução de diversos problemas encontrados durante o design de Softwares, de forma que se tornou necessário a criação de novas abordagens.

A Programação Orientada a Sujeitos (SOP – Subject-Oriented Programming), apresentada aqui, é uma dessas abordagens, e teve seus estudos iniciais em 1993 por Harrison e Ossher, do IBM T.J. Watson Research Center.

Conteúdo

Introdução
Conceitos
Exemplo Pattern Decorator
Ferramentas
HyperJ
Implementação
Conclusões
Referências Bibliográficas

Introdução

A Decomposição é uma técnica crítica em todos os estágios de desenvolvimento de um projeto. Deve ser usado para quebrar um problema em vários problemas tornado a resolução mais fácil, distribuindo a responsabilidade entre designers e desenvolvedores aumentando a eficiencia do trabalho.

Desde que o objetivo é desenvolver um sistema completo, a decomposição usualmente implica em uma recomposição: o modelo de um sistema é decomposto para deixar o processo de desenvolvimento manipulável, mas as partes devem ser recombinadas em um estágio para deixar o sistema completo. Uma variedade de técnicas, como herança múltipla, em linguagens orientadas a objetos para alcançar esse objetivo. Mas a composição orientada a sujeitos é mais flexível que todas essas técnicas.

Paradigmas Projeto Orientado a Sujeitos:

Baseado em características: decomposição do problema verticalmente em separadas características com uma base de características contento as funcionalidades comuns. Projetar e implementar cada característica separadamente, e então compor essas características para produzir o sistema completo.
Estágio: decompor o projeto horizontalmente em estágio de implementação, onde cada um é uma extensão do seu predecessor. A implementação sucessiva dos estágios permite uma extensão do sistema.
Extensão imprevista: após definido o problema, verifica-se novas necessidade. Projeta-se um sistema (parcial) relacionado a esta necessidade e implementa como uma extensão. Faz-se a composição desta extensão com o sistema completo.
Composição imprevista: a composição de dois sistemas. Deve-se projetar e implementar uma "bridge" com coordenadas complementando as funcionalidades dos dois sitemas, então fazer a composição desta bridge com os dois programas.

A Programação Orientada a Sujeitos complementa a programação orientada a objetos, resolvendo um grande número de problemas criados aos se utilizar a tecnologia orientada a objetos no desenvolvimento de grandes sistemas ou suítes para integração de aplicativos. De maneira resumidas, a SOP nos permite:

Criar extensões e configurações de software
- Sem modificação do código original
- Encapsular deltas para múltiplas plataformas, versões e características
Customizar e integrar sistemas e componentes reutilizáveis
Facilitar desenvolvimento de sistemas por diferentes grupos
- Através de domínios de problemas comuns, relacionados ou independentes
Permitir desenvolvimento descentralizado de classes
- Eliminando conflitos de concorrência
Manter a correspondência entre requerimento e código
Simplificar códigos de design patterns
- Decorator, abstract factory, visitor, strategy, adapter, etc.

Assim as vantagens vem em forma de:

Redução da complexidade de softwares e melhor compreensão;
Limitação do impacto das mudanças, facilitando a evolução, adaptação e customização do software;
Facilidade na reutilização;
Simplificar na integração de componentes.

Conceitos

A Programação Orientada a Sujeitos é uma tecnologia de composição de programas que suporta a construção de sistemas orientados a objetos através de sujeitos. Um sujeito (subject) é uma coleção de classes ou fragmentos de classes o qual modela um domínio sob um ponto de vista. Um sujeito pode ser uma aplicação completa por si só, ou pode ser um fragmento de uma aplicação que composta com outros sujeitos produz uma aplicação completa. A composição de sujeitos (subject composition) combina classes para produzir novos sujeitos de forma a incorporar funcionalidades em um sujeito já existente.

A Programação Orientada a Sujeitos desta forma, suporta a construção de sistema orientada a objetos como composição de sujeitos de forma a estender e integrar sistemas através de composição de sujeitos (como se fosse “colar” ou “adaptar” sujeitos).

A flexibilidade da composição de sujeitos introduz uma nova oportunidade para o desenvolvimento e modularização de programas orientados a objetos. Programação Orientada a Sujeitos em grande escala envolve a determinação de como dividir o sistema em sujeitos e criar regras de composição (composition rules), necessárias para compor os sujeitos corretamente, pois estas regras especificam como os sujeitos serão compostos.

Exemplo Pattern Decorator

Será apresentado aqui uma parte do software PunkJunk, que controla uma máquina de troca de moesdas, escrito pelo hacker Dewey Cheatem [3]. O PunkJunk representa as partes da máquina através de objetos, como por exemplo o display, distribuidor, etc. O Objeto Display (instancia do tipo Display) é representado desta forma:

Objeto Original escrito por Dewey Cheatem

Inicialmente, PunkJunk fazia apenas a troca de moedas. Após muitas reclamações dos usuários, Dewey resolveu que PunkJunk aceitaria notas de papel também. Apenas foi aumentada aumentou a Classe Display, para conhecer também notas de papel. Mais especificamente, foi aumentado o método show() para mostrar mensagens de troca de notas, e para incluir uma referencia associada ao objeto BillChanger. Para isso foi utilizado o design patter Decorator para não precisar modificar a classe Display:

Classe Display com o Pattern Decorator

Porém esta solução não era tão boa quanto o esperado. Existia dois problemas significantes (apontados na figura anterior):

PunkJunk, manipulando o objeto Display, deveria fazer uma troca para usar a classe DisplayDecorators;
Cada display agora é representado por dois objetos (decorator e o display atual).

Não sendo suficiente, foi feita a reimplementação do Decorator com o auxílio da Programação Orientada a Sujeitos. Definiu-se uma classe chamada Extensions, a qual implementa aprimora o método show() e a instância BillChanger necessária para o Display. Então é feita a composição da classe Extension com a classe Display (original), assim criando uma nova classe com as funcionalidades de ambas classes Display e Extension:

Solução utilizando SOP

A composição do Display inclui show() da classe Extensions, as características da classe original Display, e inclui todas as instâncias de variáveis e outros métodos de ambas as classes Display e Extensions.

O uso da Programação Orientada a Sujeitos na implementação do decorator significa:

O Código original do PunkJunk não precisa ser modificado;
Cada display é representado por um simples objeto;
O método show() da classe composta Display é definido na classe Extensions e também da classe Display, assim: Extensions::show() overrides Display::show(). Ou seja, a classe composta Display contem todos os membros (dados e métodos) definidos na classes originais Display e Extensions.

Código do Exemplo:

Código Original - PunkJunk

Código com Decorator em C++

Solução utilizando SOP

class CoinChanger;
class Dispenser;
class KeyPad;

class Display
{
public:
virtual void show() {
cout << " Display::show: CoinChanger, Dispenser and KeyPad" << endl;
};
virtual void clear() {};
// ...
protected:
virtual void beep() {// helper function called by show() and clear()
cout << " Display::beep" << endl;
};
private:
CoinChanger* _changer;
Dispenser* _dispenser;
KeyPad* _keyPad;
};

class BillChanger;

class DisplayDecorator
{
public:
DisplayDecorator (Display* d) { _display = d; }

virtual void show() {
cout << " Display::show: CoinChanger, Dispenser and KeyPad" << endl;
};
virtual void clear() { _display->clear(); };
// ... (assume only show() needs to change)
protected:
virtual void beep() {// helper function called by show() and clear()
cout << " Display::beep" << endl;
};
private:
Display* _display;
BillChanger* _billChanger;
};

class BillChanger;

class Extensions
{
public:
virtual void show () { // enhanced or extended implementation
cout << " Extensions::show: CoinChanger, Dispenser, KeyPad and BillChanger" << endl;
};
private:
BillChanger* _billChanger;
};

Ferramentas

A Programação Orientada a Sujeitos é uma tecnologia independente de linguagem. A IBM possui as ferramentas que permitem a programação SOP sendo elas: VAC++ (para C++), HyperJ (Java). E para Smalltalk existe apenas um protótipo, sem previsão para desenvolvimento.

HyperJ

O HyperJ, suporta a Separação Multidimencional de Interesses (Multi-Dimensional Separation of Concerns -MDSC). Isso facilita a adaptação, composição, integração, modularição imprevista e até mesmo a uma remodularição de componentes.

Esta separação de interesses é o objetivo principal da decomposição. E a decomposição deve ser feita até que cada unidade do problema possa ser compreendida e construída, e cada unidade da decomposição deve apresentar apenas um interesse.

MDSC permite a decomposição de interesses em: classes, objetos, procedimentos, métodos, entre outros.

O HyperJ oferece uma poderosa habilidade na composição, que pode ser usada para na combinação de sujeitos em um programa ou componente. Com isso é possível criar versões de sistemas contendo diferentes características. Pode ser usado também para estender ou adaptar um componente.

Este ambiente pode ser usados em qualquer estágio do ciclo de vida de um software – projeto, implementação, integração, evolução de sistema, reengenharia, etc:

Projeto ou Implementação: permite separar todos os sujeitos do sistema ou componente.
Integração: o mecanismo de composição pode ser usado na integração de diferentes softwares, incluindo componentes reutilizáveis, permitindo customizar e adaptar o software conforme as necessidades para o uso em um particular contexto.
Evolução de Sistema: o mecanismo de separação de sujeitos permite focar exatamente nas partes do sistema que são relevantes para sua evolução, sendo possível modificar o código existente sem afetar o restante do sistema.
Reengenharia: é possível decompor, compor novos módulos no sistema sem mudanças em partes importantes no código.

No caso especial do SOP os módulo de interesses são identificados como Sujeitos.

O HyperJ implementa HyperSpaces que seria a representação de software em múltiplas dimensões. O HyperSpace é composto pelo Hyperslices que encapsulam os interesses e Hypermodule que é um conjunto de hyperslices e relacionamentos de integração (regras de composição e relacionamento entre interesses).

Implementação Container

A Implementação do Container foi realizada com a divisão do container em duas visões simples. A visão de inclusão de objetos e a exclusão de objetos. Esses são os dois sujeitos propostos no trabalho. A composição foi a união das remoção e inserção, conforme pode ser vista na figura a seguir.

Visões do Container

Especificação do Hipermódulo:

- hyperspace (Arquivos que serão compostos)
hyperspace ContainerHyperspace
composable class container.*;
composable class container.sort.*;

-concerns (Mapeamento de Interesses)
package container : Feature.container
package container.sort : Feature.sort

-hypermodules (Relacionamentos (Regras) de Composição)
hypermodule ContainerSCE
    hyperslices:
        Feature.container,
        Feature.sort;
    relationships:
        mergeByName;
end hypermodule;

Códigos Originais:
- Remoção: Deque, Fila, Pilha
- Inserção: Deque, Fila, Pilha
Código Gerados na Composição:
- Deque, Fila, Pilha

Conclusões

Referências Bibliográficas

[1] TARR, Peri; OSSHER, Harold. (2000). “Hyper/J User and Installation Manual”. IBM Research. IN: http://www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm.

[2] IBM Corporation. (1996). "Subject-oriented programming". IBM Research. IN: http://www.research.ibm.com/sop/.

[3] VLISSIDES, John. (1998). "Subject-Oriented Design". C++ Report. IN: http://www.research.ibm.com/sop/sopdpegs.htm.

[4] KAPLAN, Mattew; OSSHER, Harold; HARISSON, William; KRUSKAL, Vicent. (1996). "Subject-oriented design and the Watson Subject Compiler". Position paper for OOPSLA'96 Subjectivity Workshop. IN: http://www.research.ibm.com/sop/papers/position96.htm.