Subject-Oriented Programming Sérgio Soares GENTe

Objetivo geral zFacilitar o desenvolvimento e a evolução de aplicações cooperantes yque compartilham objetos xou tipos! yque contribuem para a execução das operações

Deve ser possível zDesenvolver aplicações em separado e depois compô-las yas aplicações não devem ter dependências explícitas zAdicionar uma nova aplicação na composição ysem impacto nas demais ynem nos objetos já persistentes ysem precisar recompilar o sistema zManter as vantagens de encapsulamento, information hiding, polimorfismo, e herança em todas as aplicações

Motivação zComo modelar (projetar) uma árvore? zQuais seriam seus atributos?

Visão 1 - fonte de estudo

Visão 2 - fonte de renda

Visão 3 - fonte de alimento

Subject-Oriented Programming zCada visão pode ser vista como uma aplicação cliente da definição de árvore zComo a programação orientada a objetos resolve este problema? yadicionando novas propriedades à definição de árvore xnão haveria reuso (todas as propriedades em um único tipo) ydefinindo subclasses para cada visão xas visões vêem árvores com diferentes propriedades e métodos, não faz sentido o reuso dos mesmos zComo integrar diferentes visões em um mesmo projeto?

Outros problemas de OO zProjetar classes antecipando (adivinhando) possíveis evoluções ycusto de planejamento/modelagem zComo obter reuso “máximo”? zTangled code ycusto de manutenção e extensão

Subject-Oriented Programming zSubject ycoleção de classes ypedaços de classes xatributos xmétodos ydecompostos segundo um subject zRegras de composição ycomo pedaços de aplicação (subjects) se compõe para xcriar uma aplicação xoutros subjects xextender um sistema xintegrar sistemas

Subject-Oriented Programming zDividir 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 zEquate(App, ); ycompõe dois subjects.  App é uma aplicação zEquate(operation App.o, ); ydefine uma nova operação compondo duas outras.

SOP permite zCriar extensões para e configurações de software ysem alterar o código fonte ygerar várias versões de software (multiplataforma) zCustomizar e integrar sistemas e componentes reusáveis zFacilitar o desenvolvimento multi-equipe ycom modelos de desenvolvimento dependentes ou não zPermitir o desenvolvimento descentralizado de classes (evitando conflitos) zSimplificar a codificação do uso de vários padrões de projeto!!

Exemplo zDesenvolvimento de duas aplicações ysistema de folha de pagamento xid, função, salário, e cidade e estado (cálculo de impostos) ysistema de localização de empregados xnome e endereço (incluindo cidade, estado, e cep) zOpções de desenvolvimento yuma aplicação é uma extensão da outra yas aplicações são desenvolvidas ao mesmo tempo com alguma comunicação entre as equipes xestruturas de classe, assinaturas de métodos yas aplicações são desenvolvidas ao mesmo tempo sem comunicação alguma entre as equipes

Opção 1 - extensão zTime 1 decide modelar duas classes yEmpregado xid, nome, função, salário, cidade e estado xmétodos get e set ximprimir yLista de empregados xno, proximo xinserir ximprimir

zTime 2 baseado nas classes modeladas define sua definição das mesmas yEmpregado xid, nome, linha1, linha2, cidade, estado, cep xmétodos get e set ximprimir yLista de empregados xno, próximo, anterior xinserir xremover xsetNext ximprimir Opção 1 - extensão

zComposição yescrever regras de composição que adicionam as novas funcionalidades definidas pelo time 2 ao sistema definido pelo time 1 zConclusões ynão foi necessário a comunicação entre os times ynão há impacto no código fonte do time 1 xnada foi alterado ynão houve perda de tempo na modelagem do time 1, pensando em extensões futuras

Opção 2 - composição zTime 1 modela suas classes bem como o time 2, da mesma forma mostrada na opção 1. zObjetivo: Gerar uma aplicação com ambas funcionalidades, compondo as aplicações geradas pelos times 1 e 2.

zNecessidade de uma terceira entidade que escolhe quem será composto com quem yEquate(App, ); ypermite a duplicidade de métodos xinserir, imprimir... ya terceira entidade escreve regras que sobrescrevem uma implementação com a outra  a implementação mais completa sobrescreve a menos completa Opção 2 - composição

zConclusões yos códigos fontes das duas aplicações não foram modificados yas aplicações podem ser vendidas separadamente ou compostas ynão houve custos adicionais em ambos os times para prever extensões Opção 2 - composição

zDiferenças entre as classes modeladas nos exemplos anteriores yo tipo do id do empregado é string em uma aplicação e int em outra yo nome da lista de empregados difere entre as aplicações (EmpList e Emp_List) yo mesmo acontece com o atributo nome zObjetivo: Gerar uma aplicação com ambas funcionalidades, compondo as aplicações geradas pelos times 1 e 2. Opção 3 - diferenças mais radicais

zNecessidade de uma terceira entidade que escolhe quem será composto com quem yEquate(App, );  não faz mais sentido uma vez que existem nomes diferentes que não podem mais ser “casados” zA 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 zA regra não diz nada sobre os atributos em conflito e seus métodos get/set ylogo serão definidos em duplicidade zDefinir um subject cola (glue) ymantém os atributos e redefine o método get para cada aplicação (o método set altera os dois atributos) yusa uma única instância reimplementando os métodos get/set de uma aplicação

zConclusões yos códigos fontes das duas aplicações não foram modificados yas aplicações podem ser vendidas separadamente ou compostas ynão houve custos adicionais em ambos os times para prever extensões Opção 3 - diferenças mais radicais

Referências zHomepage do projeto zWilliam 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 1993Subject- Oriented Programming - A Critique of Pure Objects