Subject-Oriented Programming

Sérgio Soares

GENTe

Objetivo geral

Facilitar o desenvolvimento e a evolução de aplicações cooperantes que compartilham objetos

ou tipos! que contribuem para a execução das

operações

Deve ser possível

Desenvolver aplicações em separado e depois compô-las as aplicações não devem ter dependências explícitas

Adicionar uma nova aplicação na composição sem impacto nas demais nem nos objetos já persistentes sem precisar recompilar o sistema

Manter as vantagens de encapsulamento, information hiding, polimorfismo, e herança em todas as aplicações

Motivação

Como modelar (projetar) uma árvore?Quais seriam seus atributos?

Visão 1 - fonte de estudo

ArvorealturalarguranumeroFolhaspesoidadeespeciefamilia

Visão 2 - fonte de renda

ArvoreprecoVendametragemtempoCorte

Visão 3 - fonte de alimento

ArvoresaborvalorNuticional

Subject-Oriented ProgrammingCada visão pode ser vista como uma aplicação

cliente da definição de árvoreComo a programação orientada a objetos resolve

este problema? adicionando novas propriedades à definição de árvore

não haveria reuso (todas as propriedades em um único tipo) definindo subclasses para cada visão

as visões vêem árvores com diferentes propriedades e métodos, não faz sentido o reuso dos mesmos

Como integrar diferentes visões em um mesmo projeto?

Outros problemas de OO

Projetar classes antecipando (adivinhando) possíveis evoluções custo de planejamento/modelagem

Como obter reuso “máximo”?Tangled code

custo de manutenção e extensão

Subject-Oriented Programming Subject

coleção de classes pedaços de classes

atributos métodos

decompostos segundo um subject Regras de composição

como pedaços de aplicação (subjects) se compõe para criar uma aplicação outros subjects extender um sistema integrar sistemas

Subject-Oriented Programming

Dividir um sistema em subjects e escrever regras de composição para os mesmos

subject: A Operations: m() Classes: X with Variables: x1, x2; Mapping:Class X, Operation m() { ... }

subject: B Operations: n() Classes: X with Variables: x3; Mapping:Class X, Operation n() { ... }

Exemplo de regra de composição

Equate(App, <A,B>); compõe dois subjects. App é uma aplicação

Equate(operation App.o, <A.m, B.n>); define uma nova operação compondo duas

outras.

SOP permiteCriar extensões para e configurações de software

sem alterar o código fonte gerar várias versões de software (multiplataforma)

Customizar e integrar sistemas e componentes reusáveis

Facilitar o desenvolvimento multi-equipe com modelos de desenvolvimento dependentes ou não

Permitir o desenvolvimento descentralizado de classes (evitando conflitos)

Simplificar a codificação do uso de vários padrões de projeto!!

ExemploDesenvolvimento de duas aplicações

sistema de folha de pagamentoid, função, salário, e cidade e estado (cálculo de impostos)

sistema de localização de empregadosnome e endereço (incluindo cidade, estado, e cep)

Opções de desenvolvimento uma aplicação é uma extensão da outra as aplicações são desenvolvidas ao mesmo tempo com

alguma comunicação entre as equipesestruturas de classe, assinaturas de métodos

as aplicações são desenvolvidas ao mesmo tempo sem comunicação alguma entre as equipes

Opção 1 - extensão

Time 1 decide modelar duas classes Empregado

id, nome, função, salário, cidade e estadométodos get e setimprimir

Lista de empregadosno, proximoinseririmprimir

Time 2 baseado nas classes modeladas define sua definição das mesmas Empregado

id, nome, linha1, linha2, cidade, estado, cepmétodos get e setimprimir

Lista de empregadosno, próximo, anteriorinserirremoversetNextimprimir

Opção 1 - extensão

Opção 1 - extensão

Composição escrever regras de composição que adicionam as

novas funcionalidades definidas pelo time 2 ao sistema definido pelo time 1

Conclusões não foi necessário a comunicação entre os times não há impacto no código fonte do time 1

nada foi alterado não houve perda de tempo na modelagem do

time 1, pensando em extensões futuras

Opção 2 - composição

Time 1 modela suas classes bem como o time 2, da mesma forma mostrada na opção 1.

Objetivo: Gerar uma aplicação com ambas funcionalidades, compondo as aplicações geradas pelos times 1 e 2.

Necessidade de uma terceira entidade que escolhe quem será composto com quem Equate(App, <A,B>); permite a duplicidade de métodos

inserir, imprimir ... a terceira entidade escreve regras que

sobrescrevem uma implementação com a outraa implementação mais completa sobrescreve a menos

completa

Opção 2 - composição

Conclusões os códigos fontes das duas aplicações não

foram modificados as aplicações podem ser vendidas

separadamente ou compostas não houve custos adicionais em ambos os

times para prever extensões

Opção 2 - composição

Diferenças entre as classes modeladas nos exemplos anteriores o tipo do id do empregado é string em uma

aplicação e int em outra o nome da lista de empregados difere entre as

aplicações (EmpList e Emp_List) o mesmo acontece com o atributo nome

Objetivo: Gerar uma aplicação com ambas funcionalidades, compondo as aplicações geradas pelos times 1 e 2.

Opção 3 - diferenças mais radicais

Necessidade de uma terceira entidade que escolhe quem será composto com quem Equate(App, <A,B>); não faz mais sentido uma vez que existem nomes

diferentes que não podem mais ser “casados”A terceira entidade escreve regras que

explicitamente descrevem a correspondência entre os tipos, atributos e operações das aplicações

Opção 3 - diferenças mais radicais

default rules: NoCorrespondence, Merge

A application class employee

corresponds to

B application class employee

A application class employee instance variable state

corresponds to

B application class employee instance variable state

A application class emplist

corresponds to

B application class employee_list

Opção 3 - diferenças mais radicais

A regra não diz nada sobre os atributos em conflito e seus métodos get/set logo serão definidos em duplicidade

Definir um subject cola (glue) mantém os atributos e redefine o método get

para cada aplicação (o método set altera os dois atributos)

usa uma única instância reimplementando os métodos get/set de uma aplicação

Conclusões os códigos fontes das duas aplicações não foram

modificados as aplicações podem ser vendidas

separadamente ou compostas não houve custos adicionais em ambos os times

para prever extensões

Opção 3 - diferenças mais radicais

Referências

Homepage do projeto http://researchweb.watson.ibm.com/sop/

William Harrison and Harold Ossher, Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, September 1993