role player

cabbagepatchtapeInternet and Web Development

Feb 5, 2013 (4 years and 5 months ago)

152 views

PatchWork

Metaediting the Document Structure


Talk Structure


Why PatchWork?


What are the goals?


Which way are we going?


Basic concepts of our approach


Suggestions for a graphical notation


A “real
-
world” example: Visitor Pattern



Where do we go from here?

The Problem


Documents get complex


... and intertwined



... as the author‘s different intentions


produce overlapping structures,


and get lost in the sea of code

We are used to one view on the code: Syntax
-
based


Overall goal

A Model
-
View
-
Controller document editor


Where:


the source code is the Model


structures offer different Views


... and Controllers


The Goals


Make even complex tangled document
structures manageable


Enable programmers to pull the strings


Explicate arbitrary intention
-
driven
structures


Offer language independent support


Which way?

Separation of concerns ...


lead to meta
-
programming


macro
-
based transformations?


aspect
-
like code parts to be woven into the code
base?


design patterns as first
-
class objects?


We focus on meta
-
editing the structure


in parallel to the managed source code

The structures are there ... we want to make them usable

System Architecture


Basic meta
-
modeling framework


Roles, relations, constraints, operations



Domain
-
specific extensions


Layers of different extension


Multiple extensions can be combined

Basic Concepts


Role


Entity Type, Entity, Role Player


Relation


Projection


Constraint


Cardinality, Semantic Constraints


Operation


Add / Remove Role Player and Relation Fact


Structure


Structure Class, Structure Instance

Role

A
role

is


a
placeholder



(in the structure class)


for a
set of entities

(in the structure instance)


A
role player

is


an
entity playing a role
,


i.e. a member of the role’s set

Typing of Roles

Every role is typed:


I.e. its set can contain only entities

of a certain type


The players of a role form a subset of the
extension of the role’s entity type



Internally we use an unary predicate for
typing


From here on …

Diagrams may look

like UML,

but they are not UML

Notation for Roles

Each role has


a name


an associated entity type


«Role Type Name»

RoleName

«Java Class Role»

Operation

Example:

A role for Java Classes

Role Players

Role Players can be modeled directly

«Java Interface Role»
abstractVisitor
Example:

A Java interface for the

common Visitor supertype





The role player defines its own anonymous role

(analog to Ruby’s one object class)


Even for multiple instances of the structure this
one and only player will be used

(analog to class variables)

Relations


A
mathematical relation R

is a subset of a
cross product of some sets

n
S
S
S
R





2
1

A
relation

can be seen as
logical predicate


Elements

of a relation are regarded as
logical facts


We use relations as “backbone” for
constraints over roles

Notation for Relations


Similar to Entity
-
Relation
-
Models and UML:






A
B
C
D
E
F
G

unary


binary n
-
ary

Projections


We can derive relations using projections:



B
A
R
S
R
C
B
A





,
R
A
B
C
/S
«proj»
Semantic Constraints

Semantic constraints are defined on relations.


Their semantics are defined using:


roles

involved in the underlying relation


players

of these roles


facts

of the underlying relation

Notation for Cardinality


Unary cardinality

(absolute)

G
card
1..*
G
+ card : 1..*
D
E
0..1
A
B
C
1

Binary cardinality


n
-
ary cardinality

Example: Cardinality Constraints

Let’s define the cardinality of a role:


Let R be a relation on the n+1 roles S
1
, …, S
n

and T.




Card
T
t
R
t
s
s
S
S
s
s
n
n
n







|
)
,
,
,
(
:
)
,
,
(
1
1
1



Where
Card

is the set of valid cardinal numbers.

E.g. “1..*” = {1, 2, 3, …} (natural numbers)

Operations on Structures

Two purposes to invoke an operation:

1.
„Repairing“ an invalid structure


a constraint is violated


=> add, remove or replace role players

2.
„Editing“ a structure


„scaling“ a structure


transforming between different structures

Basic Operations


add
,
remove

and
replace

relation fact


includes add, remove
role player



domain independent

(analog to JTransformer‘s language independant changes)


Complex Operations

Can we, should we offer options to ... ?



compose operations


analogical to composed conditional
transformations in ConTraCT


to the structure modeller.


Users


Structure
-
User


Develops new structure instances


Uses a set of structure models


Structure
-
Modeller


Develops new structure models


Uses certain domain
-
specific extensions


Domain
-
Engineer


Develops new domain meta models


Uses the basic framework and ist extension mechanism

Use Cases for Domain Engineer


define new entity types


bind the entity types to an implementation
with read/write access


define new constraint types



guidelines, but no tool support

Use Cases for Structure Modeller


specify a new structure class


change a given structure class


Support planned:


textual specification (XML, Prolog)


graphical notation based on UML/MOF


tool support with a graphical structure class editor


maybe support to define composed operations
using ConTraCT


Use Cases for Structure User


create a new instance of a structure


add entities as role players to a structure
instance


remove entities from a structure instance


Tool support:


validation of instances against class


interactive graphical instance editor

Example: Defining Visitor

Intention:



Provide classes for a data structure


Provide operations on the data structure


Keep data definition together


Keep operation definitions together


Do it in Java

Define Class Role for Data Elements


«Java Class Role»

DataElement

+ card : 1..*

Define Role for Operations


«Java Class Role»

DataElement

+ card : 1..*

«Java Class Role»

Operation

+ card : 1..*

Define Role for Data Specific Operators


«Java Class Role»

DataElement

+ card : 1..*

«Java Class Role»

Operation

+ card : 1..*

DataSpecificOperator

Relate the roles


«Java Class Role»

DataElement

+ card : 1..*

«Java Class Role»

Operation

+ card : 1..*

«Java Method Role»

DataSpecificOperator

-

/card : 0..*

1

Assure correct relation of operators


each operator provides one operation ...

1

«proj»

1

«proj»

«Java Class Role»

DataElement

+ card : 1..*

«Java Class Role»

Operation

+ card : 1..*

«Java Method Role»

DataSpecificOperator

-

/card : 0..*

1


and works on one data type

Add implementation
-
specific details


«Java Class Role»

DataElement

+ card : 1..*

«Java Class Role»

Operation

+ card : 1..*

«Java Method Role»

DataSpecificOperator

-

/card : 0..*

1

1

«proj»

«proj»

1

«Java Interface Role»

abstractVisitor

«Java Method Role»

OperationAcceptor

-

/card : 1..*

1

in
-
scope

implements

Current Issues & Open Questions

We‘re in the middle ... so there is plenty ...


Diploma Thesis on Structure Class Editor


Diploma Thesis on Structure Instance Editor



More complete formalization of basis framework


Examples for domain meta
-
models:


Java


Java & Documentation

Further thoughts


Semantics


Where and how do semantics emerge?


Is structural meta
-
modeling related to the philosophical
area of structuralism?



Software
-
Engineering as a dynamical system


Is it a chaotic system?


Can structure classes provide attractors?


Or is this idea just nonsense?

PatchWork @ ROOTS


Dual view on software transformations


Complementary to JTransformer, ConTraCT,
Condor etc. ...?


PatchWork suits JTransformer well


elementary operations (add, remove) for


atomic entity types


PatchWork could feed ConTraCT


Changes on the run
-
time parts of a structure could
trigger refactorings (e.g. “renameMethod”)


Using Roles, UML and „Patterns“


seems related to Yan Han‘s experience

PatchWork model for Visitor

«Java Class Role»
DataElement
+ card : 1..*
«Java Class Role»
Operation
+ card : 1..*
«Java Method Role»
DataSpecificOperator
- /card : 0..*
1
«Java Interface Role»
abstractVisitor
«use»
«Java Method Role»
OperationAcceptor
- /card : 1..*
1
1
1
«proj»
«proj»
Larger
Example: Composition

«Java Class Role»
CompositeType
+ card : 1..*
«Java Class Role»
LeafType
+ card : 0..*
«Java Method Role»
ComponentAdder
- /card : 1..*
«Java Method Role»
ComponentRemover
- /card : 1..*
1
1
1
1
«Java Class Role»
/AllowedComponentType
+ card : 1..*
«Java Class Role,Union»
ComponentType
- /card : 1..*
«use»
1
1..*
«Java Method Role»
Operator
- /card : 0..*
«Java Method Signature Role»
Operation
+ card : 0..*
1
R
1
/T
1
/S
«proj»
«proj»
Example: Getter & Counter


Composing two structures

Example: Getter


«Java Variable Role»
Variable
+ card : 0..1
«Java Method Role»
Getter
- /card : 0..1
«Java Variable Read Access Role»
VariableReader
- /card : 0..1
reads
1
1
«use»
1
1
non-local variable
calls
«use»