13. frameworks and patterns - framework extension...

Design Patterns and Frameworks, © Prof. Uwe Aßmann

1

13. Frameworks and Patterns -Framework Extension Patterns

Prof. Dr. U. AßmannSoftware Engineering Group

Faculty of InformaticsDresden University of Technology

Version 15-1.1, 1/2/16

1)Large Layered Frameworks

2)Role-Object Pattern

1)Flat R.O.P

2)Deep R.O.P

3)Example R.O.P.

3)Treating Object Schizophrenia withR.O.P.

4)Other Variants of R.O.P

5)GenVoca Pattern

6)Mixin Layer Pattern

7)Concerns for Layered Frameworks

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

2

Literature (To Be Read)

► Y. Smaragdakis and D. Batory. Mixin layers: an object-oriented implementationtechnique for refinements and collaboration-based designs. ACM Transactions onSoftware Engineering and Methodology, 11(2):215–255, 2002.

► [flat-ROP] D. Bäumer, D. Riehle, W. Silberski, M. Wulf. Role Object. Conf. On PatternLanguages of Programming (PLOP) 1997 , pp. 15-32 http://citeseer.ist.pst.edu/baumer97role.html

► D. Riehle, T. Gross. Role Model Based Framework Design and Integration. Proc.1998 Conf. On Object-oriented Programing Systems, Languages, and Applications(OOPSLA 98) ACM Press, 1998. http://citeseer.ist.pst.edu/riehle98role.html

► [deep-ROP] D. Bäumer, G. Gryczan, C. Lilienthal, D. Riehle, H. Züllighoven.Framework Development for Large Systems. Communications of the ACM 40(10),Oct. 1997. http://citeseer.ist.pst.edu/bumer97framework.html

► [HerejonBatory] Roberto E. Lopez-Herrejon and Don S. Batory. A standard problemfor evaluating product-line methodologies. In Jan Bosch, editor, GCSE, volume 2186of Lecture Notes in Computer Science, pages 10-24. Springer, 2001.

http://citeseer.ist.pst.edu/baumer97role.html

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

3

Further Literature

► D. Bäumer. Softwarearchitekturen für die rahmenwerkbasierte Konstruktion grosserAnwendungssysteme. PhD thesis, 1997, Universität Hamburg.

► JWAM sites– http://www.c1-wps.de/forschung-und-lehre/fachpublikationen/– www.jwam.de – http://sourceforge.net/projects/jwamtoolconstr/

► U. Aßmann. Composing Frameworks and Components for Families of Semantic WebApplications. Lecture Notes In Computer Science, vol. 2901, Nov. 2003.

► U. Aßmann, J. Johannes, J. Henriksson, and I. Savga. Composition of rule sets andontologies. In F. Bry, editor, Reasoning Web, Second Int. Summer School 2006,number 4126 in LNCS, pages 68-92, Sept 2006. Springer.

► Y. Smaragdakis, D. Batory. Mixin Layers: An object-oriented implementation forrefinements and collaboration-based designs.

► Y. Smaragdakis, D. Batory. Implementing layered designs with mixin layers. InLecture Notes in Computer Science (LNCS) 1998, Springer-Verlag.

http://www.c1-wps.de/forschung-und-lehre/fachpublikationen/

http://www.jwam.de/

http://sourceforge.net/projects/jwamtoolconstr/

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

4

Goal

► Studying extensible framework hook patterns– Understand patterns Extensions Object, Role Object, and

Genvoca– See how layered frameworks can be implemented by Role Object

and Genvoca

► Understand these patterns as extension points of frameworks,i.e., framework hook patterns

► Understand how roles can be implemented in currentmainstream object-oriented languages (e.g., Java, C#)

with delegation in the Role-Object Pattern

► Understand the problem of object-oriented compared to role-oriented programming (Object Schizophrenia)

► Understand the problem of identity and state Delegation versus Forwarding

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

5

Frameworks Must Be Extensible

► Frameworks must evolve, be adapted► Idea: instead of variability hooks, use extensibility hooks

– based on basic extensibility patterns

► Presented in this lecture:– Gamma's Extension Object Pattern (EOP) – Layered frameworks

● Riehle/Züllighoven's RoleObject pattern (ROP)● Batory's mixin layer pattern (GenVoca pattern)


6

13.1 Extensibility of Frameworkswith Layers

... with Layered Frameworks based on Roles

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

7

Case Study GEBOS

► GEBOS is a banking application for RWG banking group with450 banks, south of Germany

– Banking applications, with services: tellers, loans, stocks,investment, self-service

– 2500 C++ classes, arranged in frameworks, Arranged in layers

► Concepts of the bank application domain Banks organize themselves in business sections (tellers, loans,

etc.)● Department of specialists that have a certain expertise (loans, teller,

investment) Business domain

Business objects such as bill, order, account Workplace contexts

● Service centers offer customers an all-in-one service● Services of the business sections● Every workplace needs different application systems

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

8

Application Framework Layers

AdviserDesktop

TelephoneBanking

Teller

Application Layers

Teller Loans Investment

Business Section Layers

Account Loan Product

Business Domain Layer

...

...

...

Desktop Layer

Tool

Folders

Values

...

TechnicalKernel Layer

GraphicInterface

Collections

MOP

► Gebos demonstrates that it is advantageous to structure anapplication framework into layers

– Application layers, Business Section layers, Business domain layers– Desktop Layer, Technical kernel layer

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

9

GEBOS Layers

► Technical Kernel Layer– Service layer, independent of other layers– Domain independent, application independent– Is a framework itself

● Collections, Middleware, Wrappers ● Garbage collection, late creation, factories, trace support

– Is a blackbox framework

► Desktop Layer– Support for interactive workplaces– Contains a tool construction framework (for the Tools&Materials

approach)– MVC framework, Folder framework, Value framework for business and

domain values● AccountNumber, clientNumber, Money etc

– Look and feel, reusable for office domains with GUI applications

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

10

GEBOS Layers

► Business Domain Layer contains the business core concepts:Account, customer, product, value types

– Shares knowledge for all business sections– Think about how to divide the knowledge between business domain

layer and business section layers

► Business Section Layers– Subclassing business domain and desktop layers, “inherits” knowledge

from both– Business section concepts: Borrower, investor, garantor, loan, loan

account, tools. Organizational entities and notions– Distinguish from business domain

► Application Layers– Application concepts– Separate from Business Sections, because workplaces need different

functionality from different business sections– Uses (and inherits) from all other layers

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

11

Goals in Framework Design of GEBOS

► Minimize coupling between frameworks and application systems– Frameworks should never be touched when developing an

application system

► Model different facets of business sections, products, andbusiness domain concepts

– Use role-object design pattern

► Minimize coupling between the layers– Separate concepts from implementation– Move implementation to lower layers

► Achieved with the RoleObject pattern

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

12

The JWAM Framework

► Java WAM (Werkzeug Automat Material) is a layered framework for theTools&Material pattern language www.jwam.de http://sourceforge.net/projects/jwamtoolconstr/

► The JWAM site has a lot of interesting papers, e.g., the PhD thesis ofBäumer

Application Layer

Business Section Layer

Subject Layer (Domain Layer)

...

...

...

Desktop Layer

Tool

Folders

Values

...

TechnicalKernel Layer

Messaging

Collections

MOP

Technical Layer (including JDK)

Language Extension Layer (other frameworks, such as JUnit)

http://www.jwam.de/

http://sourceforge.net/projects/jwamtoolconstr/

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

13

JWAM has a Kernel

► 100 classes and interfaces► Simple applications can be built with the kernel only► Extensions can be added, extension components:

– Equipment components● Ready to use packages such as desktop, registry, form-service

– Integration components● Database connection...


14

13.2 The Role-Object Pattern

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

15

Framework Extensibility with Riehles Role-Object Layers

► The Role-Object Pattern (ROP) is both a variability andextensibility pattern

– Realizes the “dispatch on all layers” for application frameworks– Can easily be extended with new layers

► Extension of a core layer (a blackbox framework of coreobjects) with layers of delegatees (role objects)

– A conceptual object (complex object, subject) of theapplication is split over all layers

– Core and role objects conceptually belong together to theconceptual object, but distribute over the layers

– Role objects are views on the conceptual object

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

16

Application Layers


Riehle/Züllighovens Role-Object Pattern (ROP)can be Used in GEBOS-like Architectures

Client

Customer

Guarantor InvestorBorrower

CustomerCore CustomerRole*

potential run-time access

static knowledge


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

17

Structure of Flat Role-Object Pattern

Dirk Bäumer, Dirk Riehle, Wolf Siberski, and Martina Wulf: Role Object Pattern. In: Pattern languages of program design (PLoP) 4, pp. 15-32

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

18

Application

Layer 2

Core Layer 1

Riehle/Züllighovens Role-Object PatternVariant 1 (“Flat Roles”)

ClientConceptual

Role2 Role3Role1

Core Role*

<<interfaces>>

<<implementations>>

Layer 3

Role2 Role3Role1

<<implementations>>

► Flat roles: Roles directly know cores

[flat-ROP]

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

19

Run-Time Structure: Flat Roles

<<applicationlayer 2>>

InvestorAppl

<<business domain layer>>CustomerCore

<<business section layer>>Investor

core

role

role

<<application layer 1>>Client

► At runtime, RoleObjects pass service requests (queries) on to the core– RoleObjects are directly linked to the core (flat roles)

– The core redistributes requests to those roles who can deliver the service

Mediator

Colleague

Colleague

core

<<applicationlayer 2>>StockAppl

role

core

Colleague


20

13.2.2 Variant 2: The Deep Role-Object Pattern

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

21

Application Layers


Deep Role-Object Pattern (ROP)[Riehle/Züllighoven]

Client

Customer



potential run-time access

static knowledge


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

22

Application Layer



Deep Role-Object Pattern

Client

Customer



<<interfaces>>

<<implementations>>

<<template classes>>

<<static>>

<<dynamic>>

[deep-ROP]

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

23

Run-Time Structure: Deep Roles


InvestorAppl



next

role

role


► At runtime, RoleObjects pass service requests (queries) on to the core– RoleObjects can be stacked in a Decorator chain (deep roles)

► The core knows all RoleObjects, and distributes requests (Mediator)– The core manages the RoleObjects in a map that can be dynamically extended

Mediator

Colleague

Colleague

next<<application

layer 2>>StockAppl

role

Colleague

Decorator

Decorator

Decorator

Decorator

Decoratee

next

next

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

24

Variant “Flat Roles”: Run-Time Structure


InvestorAppl



next

role

role


► At runtime, RoleObjects pass service requests (queries) on to the core– RoleObjects can be stacked in a Decorator chain

► The core knows all RoleObjects, and distributes requests (Mediator)– The core manages the RoleObjects in a map that can be dynamically extended

Mediator

Colleague

Colleague

next

<<applicationlayer 2>>StockAppl

role

Colleague

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

25 Application

Layer 2

Core Layer 1

Role-Object Pattern with More Layers(“Deep Roles”)

ClientConceptual

Role2 Role3Role1

Core Role*

<<interfaces>>

<<implementations>>

Layer 3

Role2 Role3Role1

<<implementations>>[deep-ROP]

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

26

Application

Core Layer

Structure of Core Layer Client

Conceptual

Core Role*

service1()service2()service3()

addRole()removeRole()

hasRole()giveRole()



hasRole()giveRole()


hasRole()giveRole()


<<delegate>>

new

► Management functions control theallocation of roles

► Services are■ directly available (black): role object

is registered, service in role object■ available (red): then role object is

registered; service is not in role, butcan be delegated via core

■ loadable (green): interface exists in“Conceptual”, but role must becreated and registered to bedelegatable; role map must be boundwith role object

■ loadable and hidden (blue): thenservice is defined in a role subclass,NOT existing in “Conceptual”; but canbe loaded and accessed from the roledirectly; role map must be extended

Role Map

SubRole

service4()

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

27

Run-time Behavior of ROP

► Change of role:– Different Role Objects may belong to the same role type (same

ability)– Over time, the role object for a role type may change, due to

polymorphic behavior of the role– This expresses states of the role type in the application– E.g., Borrower --> UnsafeBorrower --> TrustedBorrower

► Roles are created on-demand– In the beginning, the Subject is slim, i.e., carries few roles.– At service requests, the core creates roles and enters them in

the role map

► Roles are invisible: – The protocol of the role-object Pattern mediates all service

requests to the right role via the core


28

13.2.3 Role-Object PatternEmail Example

A Dialog asking a User for itsEMail-Address

[Courtesty to Dr. Sebastian Götz]

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

29

A Dialog Requesting an Email-Address

Provide EMail-Address

Please provide your Email-Address:

[email protected]

OKCancel

► User shall provide his Email-Address► Application want's to ensure that the provided address is valid

(Pattern: [email protected])

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

30

A Dialog Requesting an Email-Address

Provide EMail-Address

Please provide your Email-Address:

[email protected]

OKCancel

► User shall provide his Email-Address► Application want's to ensure that the provided address is valid

(Pattern: [email protected]) ► Application want's to visualize invalid Email-Addresses

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

31

Purpose of Role-Object Pattern

► Transparently adapting objects to client context► Management of role playership, where roles are represented

as individual objects

addressField: TextFieldChild

root : Dialog

Parent

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

32




addressField: TextFieldChild DataSource

root : Dialog

Parent

formProcessor : Validator DataSink

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

33




addressField: TextFieldChild DataSource

root : Dialog

Parent

formProcessor : Validator DataSink

2nd Client = 2nd Context =Validation

1st Client = 1st Context = Drawing

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

34

Running Example: Email Checking

TextFieldCore

Child DataSource

TextFieldRole

TextField

Parent DataSink

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

35

Roles Can be “Allocated”

description: TextFieldCore

descriptionChild: Child

addRole(descriptionChild);

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

36

..and Exchanged...

description: TextFieldCore


addRole(descriptionDS);

descriptionDS: DataSource

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

37

Here: Both Roles are Alternatives

description: TextAreaCore

removeRole(descriptionChild);


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

38

Running Example: Email Checking

description: TextAreaCore



drawer : Parent

validator : DataSink


39

11.3 Treating ObjectSchizophrenia with ROP

How the Problem of SplitObjects is Treated by the ROP

Protocol

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

40

The Problem of Split Objects

► Object schizophrenia covers the problems, which arise fromsplitting a conceptual object into multiple parts.

TextField

DataSourceChild

TextField

DataSourceChild

TextField

text : Stringparent : Parent

TextField

text : String

Child

parent : Parent

DataSource

text : String

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

41


► Object schizophrenia arises from splitting a conceptual objectinto multiple parts:

► Question for identity depends on which object is asked.“Who are you?”

User: “I'm a TextField.” Drawer: “I'm the child of this parent.” Validator: “I'm a data source for you.”

TextField

DataSourceChildUser

Drawer Validator

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

42


► Who manages the state of the compound object? The text of the field is required for both roles The size of the field is specific to the drawing task The color of the text crosscuts both roles (drawing + validation)

► When should a role delegate to the player and when should a playerdelegate to its roles?

TextField

DataSourceChildUser

Drawer Validator

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

43

The ROP Protocol Treats ObjectSchizophrenia

► Clients may have access to a role or the core► If the role does not directly provide the service, it will pass it on to the

core object The clients implicitly “ask” the core object (the mediator)

► The core object delegates the call to the respective role► The core object represents the identity, asking questions for

THIS/SELF► The core manages its roles and creates them on-demand

Role management code AddRole, RemoveRole, Operation

Code for reflection HasRole, GetRole

► Roles need to be implemented aware of their core Delegation to core object for every method call, as it could be

overridden by another role object, which is currently being played.


44

11.3.2 Delegation vs.Forwarding

The meaning of this

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

45

Delegation vs. Forwarding

► What does this or self actually mean?

ClassA ClassB

m1()m2()

m1()m2()

class B { A a; m1() { a.m1(); } m2() { print(“B”); }}

a

class A { m1() { this.m2(); } m2() { print(“A”); }}

a = new A();b = new B(a);

b.m1();

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

46

Delegation Changes this While RunningThrough References

► this or self is changed during traversal of references

► Delegation Semantics:this bound to delegatee(i.e., this = a)

ClassA ClassB

m1()m2()

m1()m2()


a


// client codea = new A();b = new B(a);

b.m1();

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

47

// client codea = new A();b = new B(a);

b.m1();

Forwarding Retains this While RunningThrough References

► Forwarding “stays” within one object

► Forwarding Semantics:no delegation of this(i.e., this = b)

ClassA ClassB

m1()m2()

m1()m2()


a


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

48

Forwarding in Java

► Java does not directly support forwarding Workaround required: Passing this to the receiver

► Keep this in mind when implementing operations in the Role-Object Pattern!

ClassA ClassB

m1(me : Object)m2()

m1()m2()

class B { A a; m1() { a.m1(this); } m2() { print(“B”); }}

a

class A { m1(Object me) { me.m2(); } m2() { print(“A”); }}


49

13.4 Variants of the Role-Object Pattern

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

50

Application

Layer 2

Core Layer 1

Rpt.: Role-Object Pattern Variant 1 (“FlatRoles”)

ClientConceptual

Role2 Role3Role1

Core Role*

<<interfaces>>

<<implementations>>

Layer 3

Role2 Role3Role1

<<implementations>>

► Flat roles: Roles directly know cores

[flat-ROP]

<<dynamic>>

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

51Application Layer



Variant 2: Deep Role-Object Pattern

Client Customer



<<interfaces>>

<<implementations>>

<<template classes>>

<<static>>

<<dynamic>>

[deep-ROP]

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

52

Core Layer 1

Variant 3: Core Layer with Traded Call

Conceptual

Core *

<<interfaces>>

accept(ServiceDescription)service1()


hasRole()giveRole()


addRole()addRole(ServiceDescription)

removeRole()hasRole()giveRole()

Role


hasRole()giveRole()


Role Map

// Traded call //Interpret serviceDescription;Lookup concrete service in role map;Call;

► To add services dynamically (beyond the service interfaces in theconceptual object), add a trader to the core

● A trader is a method that interprets a service request based on a servicedescription

// enter traded role //Interpret serviceDescription;add concrete role and service under service description in role map;

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

53

RoleObjectPattern and Other Patterns

► Deep-ROP is not only a Decorator with Mediator– It is based on 1-H<=T, i.e., 1-ObjectRecursion

● All role objects inherit from the abstractum● 1-ObjectRecursion based patterns lend themselves to extension

– And 1-H<=T framework hook patterns provide extensibleframeworks

– 1:n relationship between core and role objects– Role objects decorate the core object, and pass requests on to

it

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

54

Business Section Loan Layer

Business Section Investment Layer


Role-Object Pattern Vs Inheritance (White-Box Framework Layers)

Customer

Investor

Borrower


Account

SavingsAccount

LoanAccount

<<whitebox framework (H<T)>><<ROP framework>>(n-TrH)

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

55




Role-Object Pattern Vs Inheritance (White-Box Framework Layers)

Customer

Investor

Borrower


Account

SavingsAccount

LoanAccount

AccountCore AccountRole*

<<ROP framework>>(n-TrH)

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

56

Comparison of Role Objects withInheritance

► White-Box frameworks rely on inheritance as mini-connector(H<T)

Simple inheritance has one instance of a subclass at a time Subclass can change over time (polymorphism)

► The role object has many of them at the same time– All role objects can change (role polymorphism)

► Only changes in the base layers (technical, presentation,business) affect other layers

– Changes in the business section layers do not affect the businessdomain layers

► The relation of core and role objects is a special form of part-of(combined with inheritance)

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

57




Role-Object Pattern with Template andHook Stereotypes

Customer

Investor

Borrower


Account

SavingsAccount

LoanAccount

AccountCore AccountRole

<<template class>>

<<template class>>

<<template class>>

<<template class>> <<hook class>><<hook class>>*

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

58




Role-Object Pattern and Role Models onRole Layers

Customer

Investor

Borrower


Account

SavingsAccount

LoanAccount


► Usually, roles of one subject talk to other roles of another subject on thesame layer (within a role model)

► Cores never talk to each other directly

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

59

Switching Variable Role Layers

► At run time, entire role models on role layers can be exchanged(variable role layers)




Customer

Garantor

Borrower


Account

GaranteeContract

LoanAccount


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

60

Riehle/Züllighovens Layer Pattern AsFramework Hook Pattern

C

R

Core-Role-Pattern

R

R

C

n-TrH mini-connector

R

Conceptual

Role n-TrHT2 has H parts

H and T2 inheritfrom T1

Core

Special partOf

Con

T1

H

T2

n n

n

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

61

ROP Ensures Extensibility

► The ROP lends itself not only to variability, but also to staticand dynamic extensibility

– If a framework hook is a Role-Object Pattern, the hook can beextended in unforeseen ways without changing the framework!

– New layers of the application or the framework can be added atdesign time or runtime

► Powerful extension concept with ROP-Trader– Whenever you have to design something complex which should

be extensible in unforeseen ways, consider Role Object

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

62

Riehle/Züllighovens Layered Role ObjectFramework

C

RCore Layer

R

R

Role Layer 1 Role Layer 2 Role Layer 3

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

63

Extension in Layered Role Object Frameworks

C

RCore Layer

R

R

Role Layer 1 Role Layer 2 Role Layer 3

R

Role Layer 4

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

64

ROP Can Implement Dimensions That AreNot Independent

► The role objects implement dimensions– Core object implements primary dimension– Role object secondary dimension

► Role objects realize one conceptual object, instead of a rolemodel crosscutting several conceptual objects

– Facets are independent dimensions of a conceptual objects– Every dimension can be varied independently

► ROP generalizes the implementation of facets by Multi-Bridge(see Chapter “Simple Extensibility”)

– Multi-Bridge has no inheritance between ConceptualObject, Coreand Role

– Multi-Bridge suffers from object schizophrenia, ROP canimplement “this()” on itself without object schizophrenia

– Calls to the role are not dispatched to the LogicalObject– Bridges must not inherit from each other, RoleObjects can

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

65

Beneft ofLayered Role-Object Frameworks

► Implements conceptual objects with layered dependentdimensions

– Not only independent dimensions

► Together with layering, – Easily extensible– Enormous variability– Simple structure for extensible product line architecture results

► For instance: Layered Frameworks for Business Software– Dispatch on all layers is necessary

● Implementation without multimethods (in standard languages)very hard. Only CLOS, Cecil, and MultiJava are good here

– That is one reason why business frameworks are so hard● SanFrancisco business framework of IBM didn't make it though

a dynamic extensibility pattern● That's also why these applications are so expensive


66

13.5 The GenVoca Pattern, MixinLayers, and Layered MixinFrameworks

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

67

The Mixin Concept

► A mixin is a partial class, for an extension of another class

► A mixin-base is a class with a generic super, a mixin parameterizes this generic super

► Some languages have mixins (Scala, C#, Eiffel); otherwise, mixins can be expressed as classfragments that can be parameterized with a superclass (C++)

► Mixins can implement (static) roles and facets

template <class Super> class EmployeeMixin extends Super {

// class extension..Salary salary;Employer emp;

}

template <class Super> class EmployeeMixin extends Super {

// class extension..Salary salary;Employer emp;

}

EmployeeMixin<Person> employeeOfPerson;EmployeeMixin<German> employeeOfGerman;EmployeeMixin<Club> employeeOfClub;

EmployeeMixin<Person> employeeOfPerson;EmployeeMixin<German> employeeOfGerman;EmployeeMixin<Club> employeeOfClub;

Person

EmployeeMixin

<<parameterize>>

EmployedPerson

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

68

The GenVoca Pattern

► If several mixin parameterizations are nested, the GenVocapattern results [Batory]

// C++-like syntaxtemplate <class S> class EmployeeMixin extends S {

Salary salary;Employer emp;

}template <class S> class ParentMixin extends S {

Child child;Money kindergeld;

}template <class S> class HobbyMixin extends S {

Hobby hobby;}// Persons composed with GenVoca patternHobbyMixin<ParentMixin<EmployeeMixin<Person>>>> assmann;EmployeeMixin<ParentMixin<HobbyMixin<Person>>>> assmann2;// Have assmann and assmann2 the same type?

// C++-like syntaxtemplate <class S> class EmployeeMixin extends S {

Salary salary;Employer emp;

}template <class S> class ParentMixin extends S {

Child child;Money kindergeld;

}template <class S> class HobbyMixin extends S {

Hobby hobby;}// Persons composed with GenVoca patternHobbyMixin<ParentMixin<EmployeeMixin<Person>>>> assmann;EmployeeMixin<ParentMixin<HobbyMixin<Person>>>> assmann2;// Have assmann and assmann2 the same type?

Person

EmployeeMixin

ParentMixin

HobbyMixin

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

69

GenVoca Variations

► When different variants exist for a “abstraction layer”,parameterizations express configurations of a product line

// VariantsPerson: Man, WomanParentMixin: FatherMixin, MotherMixinEmployeeMixin: TimedEmployee, PermanentEmployeeHobbyMixin: PigeonFriend, Sportsman, GolfPlayer

// CompositionsGolfPlayer<TimedEmployee<Father<Man>>>> assmann;PigeonFriend<PermanentEmployee<Father<Man>>>> miller;GolfPlayer<PermanentEmployee<Mother<Woman>>>> brown;

// VariantsPerson: Man, WomanParentMixin: FatherMixin, MotherMixinEmployeeMixin: TimedEmployee, PermanentEmployeeHobbyMixin: PigeonFriend, Sportsman, GolfPlayer

// CompositionsGolfPlayer<TimedEmployee<Father<Man>>>> assmann;PigeonFriend<PermanentEmployee<Father<Man>>>> miller;GolfPlayer<PermanentEmployee<Mother<Woman>>>> brown;

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

70

Variations on Diferent Abstraction Layersform Product Variants

► Variants can be formed on every layer

Person

ParentMixin

<<parameterize>>

EmployeeMixin

<<parameterize>>

HobbyMixin

<<parameterize>>

Man

Father

TimedEmployee

GolfPlayer

PermanentEmployee

PigeonFriend

Woman

Mother

PermanentEmployee

GolfPlayer

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

71

Variations on Diferent Role Layers

► Abstraction layers correspond to role layers of complex objects► Roles collaborate, but are not implemented by role objects, but

by mixins

Person

ParentMixin

<<parameterize>>

EmployeeMixin

<<parameterize>>

HobbyMixin

<<parameterize>>

Man

Father

TimedEmployee

GolfPlayer

PermanentEmployee

PigeonFriend

Woman

Mother

PermanentEmployee

GolfPlayer

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

72

Discussion

► A mixin layer groups all mixins of a role abstraction layer► Mixins play in the GenVoca pattern the same role as role

objects in the Role-Object Pattern and layered role frameworks– However, all role objects are embedded into one physical object– There is a physical identity for the entire logical object– No object schizophrenia to be avoided– GenVoca applications are more efficient, since they merge all

roles together into one physical object (see the Aßmann's law onrole merging)

► Similarly to layered role object frameworks, layered GenVocaframeworks can model big product lines

– Every abstraction layer (mixin layer) expresses variability– New mixin layers model extensibility


73

13.6 The Mixin Layer Pattern

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

74

The Mixin Layer Pattern Combines SeveralGenVoca Patterns► While the GenVoca pattern deals with single stacking of parameterizations, the MixinLayer

pattern groups all roles of an abstraction layer together and composes entire layers

► MixinLayer treats all logical objects of an application

Person

ParentMixin

<<parameterize>>

EmployeeMixin

<<parameterize>>

HobbyMixin

<<parameterize>>

Work

ParentalWork

WorkRights

LeisureWork

Location

Home

Workshop

HobbyLocation

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

75

FullTimePerson FullTimeWork FullTimeLocation

PartTimePerson PartTimeWork PartTimeLocation

FullTimeLayer

PartTimeLayer

Mixin Layers as Compositional Unit

► A mixin layer gets a name and can be exchanged consistentlyfor a variant, changing the behavior of the entire layer

Person

Father

<<parameterize>>

<<parameterize>>

Work

ChangingDiapers

Location

Toilet

Mother BreastFeeding ChildrensRoom

NoContract Deliberate Home

NoContract Forced Home

<<parameterize>>

ChildrenAsHobby

FatherLayer

MotherLayer

ForcedToWork

Deliberate

WorkAsHobby

WorkNotAsHobby

ChildrenNotAsHobby

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

76

Composition of Mixin Layers

► Mixin layers are composed similarly to single GenVoca mixins– Meaning: All role classes are consistently exchanged with their

layerCoreLayer: FullTime, PartTimeParentLayer: FatherLayer, MotherLayerEmployeeLayer: Deliberate, ...HobbyLayer: WorkAsHobby, Slave....

// This is now mixin layer composition!WorkAsHobby<Deliberate<FatherLayer<FullTime>>>> assmann;

CoreLayer: FullTime, PartTimeParentLayer: FatherLayer, MotherLayerEmployeeLayer: Deliberate, ...HobbyLayer: WorkAsHobby, Slave....

// This is now mixin layer composition!WorkAsHobby<Deliberate<FatherLayer<FullTime>>>> assmann;

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

77

Implementation of Mixin Layers withGenVoca Pattern and Inner Classes

► The role classes of upper layers form super classes of the layerclass

► The following pattern allows for separate parameterization of allrole mixins, not the layer as a whole

► The role classes of upper layers form super classes of the layerclass

► The following pattern allows for separate parameterization of allrole mixins, not the layer as a whole

// Java-like syntaxclass Layer <class Super, class RoleSuper

1, .., class RoleSuper

n>

extends Super {class Role

1 extends RoleSuper

1 { .. }

..class Role

n extends RoleSuper

n { .. }

.. additional classes..}

// Java-like syntaxclass Layer <class Super, class RoleSuper

1, .., class RoleSuper

n>


1 extends RoleSuper

1 { .. }

..class Role

n extends RoleSuper

n { .. }


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

78

Implementation of Mixin Layers withDesignated Inner Classes

► If the target language permits to have inner classes that can bedesignated by an expression, mixin layers can be inherited as awhole

► The super mixin layer can be selected by one single expressionL<L1>

class Layer <class Super> // The class Super has n inner role classes RoleSuper

1, ..,

// RoleSupern


1 extends Super.RoleSuper

1 { .. }

..class Role

n extends Super.RoleSuper

n { .. }


class Layer <class Super> // The class Super has n inner role classes RoleSuper

1, ..,

// RoleSupern


1 extends Super.RoleSuper

1 { .. }

..class Role

n extends Super.RoleSuper

n { .. }


Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

79

GraphUndirected VertexWithAdjac

GraphDirected VertexWithoutAdj

RepresentationLayer

Example: A Graph Framework [HerrejonBatory]► Graph applications can be structured into mixin layers

► ConnectedOnDFTUndirected = CRL1<CL1<VN1<TL1<RL1>>>>>

► ConnectedOnBFTRevDirected = CRL1<CL1<VN2<TL2<RL2>>>>>

Graph

DFT

Node

VertexDFT

Workspace

BFT VertexBFT

VertexNumber WorkspaceNumber

VertexReverseNumber

WorkspaceNumber

GraphCycleCheck

TraversalLayer

Vertex NumberingLayer

CycleLayer

ConnectedRegionLayer

GraphConnected

NodeCycleCheck WorkspaceCycleCheck

NodeConnected WorkspaceConnected

CL1

CRL1

VN2

VN1

TL2

TL1

RL2

RL1

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

80

Layered Mixin Frameworks vsLayered Role Object Frameworks

► Every mixin layer corresponds to a role layer► Mixin layers form frameworks that can be extended by mixin

layer composition towards applications► Same variability effects for big product lines

Person

ParentMixin

EmployeeMixin

HobbyMixin

Work

ParentalWork

WorkRights

LeisureWork

AdviserDesktop

TelephoneBanking

Teller

Application Layers





...

...

...

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

81


► Unfortunately, the direction of generality is usually drawn in theopposite way in mixin layer frameworks and role objectframeworks

► If we agree to put the “most general abstraction layer”downmost, the dependencies go into the same direction

► Features on the upper layers depend on the lower layers

Person

ParentMixin

EmployeeMixin

HobbyMixin

Work

ParentalWork

WorkRights

LeisureWork

AdviserDesktop

TelephoneBanking

Teller

Application Layers





...

...

...

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

82


► Essentially, layered role object frameworks and layered mixinframeworks provide the same concept for variability andextensibility

► Difference: mini-connector– Layered role object frameworks use as mini-connector the Role-

Object Pattern– Layered mxin frameworks use as mini-connector the GenVoca

pattern


83

13.7 How To Find Concerns for aLayered Framework

Example: Layered Frameworks for the Semantic Web

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

84

Example: A New Application Area: Semantic Web Applications

► Semantic web:– Standardization technology for the Web and many application

domains– Definition of ontologies, standard dictionaries– Based on inheritance and constraints

► Every application domain will have its “Semantic Web ontology”► How to build product families for those domains?

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

85

Component Language Semantics

Component Model

Architectural Style Constraints

Application Family Constraints

Application Constraints

User Constraints (Personalization)

Architectural Concerns

Core Conceptual Concerns

Application Concerns

The Concerns of an Application in theSemantic Web

► Which concerns exist?► After a little thought: three groups of concerns. (This is not

complete, there might be more)

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

86

Layered Frameworks for Product Lines onthe Semantic Web

► We can sort the acyclically dependent concerns into a layeredarchitecture, in which several ComplexObjects crosscut all layers

– On every level, there are constraints to check the layer for consistency– All role objects on the layer are checked by the constraints

Generic Component Layer

Composition Time Layer

Component Language Layer

Concrete Component Model Layer

Architectural Style Layer

Application Family Layer

Application Layer

User Layer (Personalization)

Architectural Layers

Core Conceptual Layers

Application LayersConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

87

Layered Frameworks for CompositionSystems

► Even a composition system for web applications can bearranged in role layers




Concrete Component Model Layer



Application Layer




Application LayersConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

ConcernConstraints

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

88

Layers can be Instantiated Diferently

► On every layer of the layered framework, there is variation andextensibility

► New user constraints► New application constraints► New application family constraints► New architectural constraints► New component models► New component languages

► Different Languages in One Framework– Since the language is a layer, it can be exchanged– Several ontology languages can be used for components in

Semantic Web applications● BPEL, Datalog, Prolog, OWL




Concrete ComponentModel Layer



Application Layer


Component



Application Layers

FragmentComponent

Datalog

Prolog

BinaryDatalog

OWL

WebServices Model

Transaction-basedWeb Services Model

Banking Transaction-basedWeb Services

MoneyDeposit Inc.Web Services

Uwe AssmannBanking Portfolio

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

90

Diferent Architectures are Possible forOne Component Model

► Since the architectural styles can be exchanged for the samecomponent model







Application Layer


Component



Application Layers

FragmentComponent

Datalog

EJB

BinaryDatalog

JSP

RuntimeComponent

Tax Event-basedWeb Services

Tax AuthoritiesWeb Services

Uwe AssmannTex Portfolio

Event-basedWeb Services Model





WebServices Model

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

92

Diferent Component Models Can Coexist

► Interoperability of Semantic Web application is simplified







Application Layer


Component



Application Layers

FragmentComponent

Datalog

EJB

BinaryDatalog

JSP

Web Services Model I

RuntimeComponent

Tax Event-basedWeb Services

Tax AuthoritiesWeb Services

Uwe AssmannTex Portfolio

Event-basedWeb Services Model





Web Services Model II

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

94

Layered Frameworks and ComponentModels

► Once, if languages and component models are layers, layeredframeworks can be generalized considerably.

– Implementation with Layered ROP frameworks or Layered mixinframeworks

► It becomes possible to build totally heterogeneous applications:– Different framework and component languages– Different architectures and architectural styles– Different product lines (application families)

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

95

What Have We Learned?

► How can we structure a Product Line as Layered Framework?– ExtensionObjects is a simple extension mechanism for frameworks– Layered frameworks provide variability and extensibility for thousands of

different products in a product line

► Process for layered frameworks:– Identify concerns (abstraction layers), which crosscut all or many

objects. These concerns are similar to facets, but not independent– Sort them according to their (acyclic) dependencies– Use ROP or Genvoca pattern for implementation– Use framework role layers or mixin layers for a layered application

► The Role-object Pattern Realization of roles in object-oriented languages Using delegation and forwarding

► Object Schizophrenia Problem of identity Problem of state management

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

96

The End


97

13.A.1 The ExtensionObjectsPattern (EOP)

Extensions of Objects, visibile for the Client

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

98

Structure of ExtensionObjects

► Whenever a complex object has non-mandatory parts that can be added, if necessary

► Extension is the base class of all extensions

► AbstractExtension defines an interface for a concrete hierarchy of extension objects

► Extensions can be added, retrieved, and removed by clients

Subject

ConcreteExtension2

ConcreteExtension3

ConcreteExtension1

Extension

1 or n

AbstractExtension

getExtension(name)addExtension(name, Extension)removeExtension(name)

ConcreteSubject


extension

owner

Client

AbstractExtension

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

99

Example: Spellcheckers in DocumentModels

► E.g., OpenDoc or OLE documents

Document

EnglishSpellchecker

GermanSpellchecker

FrenchSpellchecker

Extension

1 or n

<<template>>

Spellchecker


ConcreteDocument


extension

owner

Client

WordCounter

<<hook>>

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

100

Discussion of EOP

► If there is 1 extension object, naming is not necessary► If there are n extension objects, a dictionary (map) has to map names

to extension objects► Advantages

– Complex objects can be split into simpler parts– Extensions can model (optional) roles of objects– Extensions can be added dynamically and unforeseen

► Disadvantage– Clients have to manage extension objects themselves, and hence,

are more complex– Extension objects suffer from the object schizophrenia problem: the

logical this of an extension object is the subject, but the physical this isthe extension object

► Relations to Other Patterns– If many objects of an application have the same roles that are realized

by extension objects, ExtensionObjects can be generalized to the Role-Object Pattern

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

101

Framework

ExtensionObjects at Framework Borders

► Since with EOP, clients have to manage extensions themselves,the use of the template object in the framework does not help touse the hook objects

Subject

ConcreteExtension2

ConcreteExtension3

ConcreteExtension1

Extension

1 or n

<<template>>

AbstractExtension


ConcreteSubject


extension

owner

Client

AbstractExtension

<<hook>>

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

102

EOP as Framework Hook Pattern

► Since the hook object is not mandatory, also 1-H=T is a realextensibility pattern for frameworks

T H

n-H=TT has n H partsT owns H parts

nT H

1-H=TT has 1 H partT owns H

1

T H= T H=*

Pro

f. U

we

Aß

ma

nn, D

esig

n P

att

e rns

an d

Fra

me

wo

rks

103

Optional Tools for Documents in an OfceFramework

Office Framework

SpellChecker

Document

WordCount

=*

a.s.o