Data Explorer (DEX) RWTH Aachen University Page 2 DEX is a - - PDF document

Generative Software Engineering

• 2. Generating Data Explorers
• Prof. Dr. Bernhard Rumpe

Software Engineering RWTH Aachen University http://www.se-rwth.de/

qualified_association Class Type attribute Class Type method() «interface» Interface qualifier 1 * composition role CD

Farbe!

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 2

Data Explorer (DEX)

• DEX is a generator for (parts of) business applications
• Input: Class Diagram, (OCL constraints)
• Generated result
• Running application
• We use DEX to study
• how a generator works
• how to adapt and extend it’s components

DEX generator

Java Swing Application UML/P CD textual class diagram

Generative Software Engineering

• 2. Generating Data Explorers

2.1. Class Diagrams as Input

• Prof. Dr. Bernhard Rumpe

Software Engineering RWTH Aachen University http://www.se-rwth.de/

qualified_association Class Type attribute Class Type method() «interface» Interface qualifier 1 * composition role CD

Farbe!

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 4

Class Diagrams

• We assume that you are familiar with CDs, here a short overview

(and excerpt of our case study “Social Network”):

this is a class diagram

Person Date lastVisit String firstName String secondName Date dateOfBirth «abstract» Profile String profileName /int numberOfPosts /int friends Group boolean isOpen Date created String purpose /int headcount profileName 1

• rganizer

1 Relationship boolean pending Date requested Date accepted «enum» RelationType FRIEND FAMILY COLLEAGUE FOLLOWER OTHER

• rganized

* 1 invited * 1 initiated * member * *

CD

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 5

Person Date lastVisit String firstName String secondName Date dateOfBirth int zip String city String country «abstract» Profile String profileName /int numberOfPosts /int friends

Social Network – The Full Domain Model

Group boolean isOpen Date created String purpose /int members profileName 1 *

• rganizer

1 tagged 1 * replyTo 0..1 Relationship boolean pending Date requested Date accepted «enum» RelationType FRIEND FAMILY COLLEAGUE FOLLOWER OTHER Tag boolean confirmed Photo double height double width picture InstantMessage Date timestamp String content 1.. * * 1 «interface» Post PhotoMessage

• rganized

* 1 invited * 1 initiated * member * * * * received 1 * sent {ordered} {ordered}

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 6

Concepts we know in CD’s

• Classes
• Interfaces, abstract classes, enumerations
• Attributes
• Name + Type + Visibility
• derived attributes
• Associations
• Name, role names, cardinalities
• Composition
• Qualified associations
• Qualifier
• {ordered} association
• Stereotypes like <<singleton>>

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 7

We use a textual notation for CDs

• Text is easier to process
• Text is easier to define
• A class diagram thus becomes a text-file of this form

and is stored in SocNet.cd

• We next define the textual input …

classdiagram SocNet { class ... class ... association ... }

CD

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 8

CD SocNet

Textual Form for Classes

• A class looks pretty similar to Java code, but no methods:

classdiagram SocNet { interface Post; class InstantMessage implements Post { Date timestamp; String content; } }

InstantMessage Date timestamp String content «interface» Post

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 9

Textual Form for Enumerations

• An enumeration in a CD looks like this

(and can be used as type elsewhere in the class diagram):

1 Relationship boolean pending Date requested Date accepted «enum» RelationType FRIEND FAMILY COLLEAGUE FOLLOWER OTHER

class Relationship { boolean pending; Date requested; Date accepted; } enum RelationType { FRIEND, FAMILY, FOLLOWER, COLLEAGUE, OTHER; } association Relationship -> RelationType [1];

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 10

Textual Form for Associations -1

• An association in the CD:
• Navigation directions: ->, <-, <-> and –
• Assoc. name, multiplicities are optional

association member [*] Person <-> Group [*]

multiplicity, e.g. [*], [1], [2..6], [0..1] navigation direction, class name

member * * Group Person

• assoc. name

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 11

Textual Form for Associations -2

• An association in the CD:
• Role names for navigation
• Qualifier is an attribute of the opposite class

association [*] Person (organizer) <-> (organized) [profileName] Group [*]; role name

profileName

• rganizer

*

• rganized

* Group Person

qualifier

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 12

Lets define classes:

«abstract» Profile String profileName /int numberOfPosts /int friends

abstract class Profile { String profileName; /int numberOfPosts; /int friends; } class Group extends Profile { boolean isOpen; Date created; String purpose; /int headcount; }

Group boolean isOpen Date created String purpose /int headcount

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 13

Lets define more:

«interface» Post * replyTo 0..1 InstantMessage Date timestamp String content

interface Post; class InstantMessage implements Post { Date timestamp; String content; } association [*] InstantMessage <-> (replyTo) InstantMessage [0..1]; class PhotoMessage extends InstantMessage;

PhotoMessage

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 14

CDDefinition = "classdiagram" Name "{“ (CDClass | CDInterface | CDEnum | CDAssociation)* "}" CDClass = "abstract"? "class" Name ("extends" ReferenceType ("," ReferenceType)*)? ("implements" ReferenceType ("," ReferenceType)*)? (CDClassBody | ";") CDClassBody = "{" CDAttribute* "}" CDAttribute = "/"? Type Name ("=" Value)? ";" CDInterface = "interface" Name ("extends" ReferenceType ("," ReferenceType)*)? ";" CDEnum = "enum" Name (CDEnumBody* | ";") CDEnumBody = "{" (CDEnumConstant ("," CDEnumConstant)* ";")? "}" CDEnumConstant = Name CDQualifier = "[" Name "]" RoleName = "(" Name ")" CDAssociation = "association" "/"? Name? Cardinality? QualifiedName CDQualifier? RoleName? ( "->" | "<-" | "<->" | "--" ) RoleName? CDQualifier? QualifiedName Cardinality? "<<ordered>>"? ";" Cardinality = "[" ("*" | Int | Int ".." Int | Int ".." "*") "]";

Grammar of UML/P CD lite language

This is the compact, readable grammar for the concrete

• syntax. For the full language

spec please see: http://www.monticore.de/dex

Appendix

MG

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 15

package dex; import java.util.*; classdiagram SocNet { abstract class Profile { String profileName; /int numberOfPosts; /int friends; } class Person extends Profile { Date lastVisit; String firstName; String secondName; Date dateOfBirth; int zip; String city; String country; } class Group extends Profile { boolean isOpen; Date created; String purpose; /int headcount; } association member [*] Person <-> Group [*]; association [1] Person (organizer) <-> (organized) [profileName] Group [*];

The full CD SocNet in textual form -1

Excerpt from SocNet.cd

Appendix

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 16

class Relationship { boolean pending; Date requested; Date accepted; } association invited [*] Relationship <-> Profile [1]; association initiated [*] Relationship <-> Profile [1]; enum RelationType { FRIEND, FAMILY, FOLLOWER, COLLEAGUE, OTHER; } association Relationship -> RelationType [1]; interface Post; association received [*] Profile <-> Post [*] <<ordered>>; association sent [1] Profile <-> Post [*] <<ordered>>; class InstantMessage implements Post { Date timestamp; String content; } association [*] InstantMessage <-> (replyTo) InstantMessage [0..1]; class PhotoMessage extends InstantMessage; association [1..*] Photo (picture) <-> PhotoMessage; class Photo { double height; double width; } class Tag { boolean confirmed; } association [1] Person (tagged) <-> Tag [*]; association [*] Tag <-> Photo [1]; }

The full CD SocNet in textual form -2

Appendix

CD SocNet

Generative Software Engineering

• 2. Generating Data Explorers

2.2. How to Use DEX

• Prof. Dr. Bernhard Rumpe

Software Engineering RWTH Aachen University http://www.se-rwth.de/ Farbe!

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 18

Data Explorer (DEX)

• DEX is a generator for (parts of) business applications
• Input: Class Diagram, OCL constraints
• Generated result
• Running application for managing data fitting to

the class diagram

• A graphical user interface
• Support for storing data in the cloud

DEX generator

DEX product: Java Swing Application UML/P CD The model: A textual class diagram

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 19

DEX Product Features

• Frontend features
• CRUD (create, read, update, delete) management for
• bjects and associations
• Browsing, search and filter functionality
• Support for Java types (e.g. List<int>, Date)
• Feedback on invalid input
• Uses dummy values for testing
• Backend features
• Database support
• Multiuser support
• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 20

Using the DEX generator

• Important steps for installation

1. Install JDK Version 6 or higher 2. Set JAVA_HOME path variable to the JDK directory e.g. to C:\Programme\Java\jdk1.7.0_51 3. Download dex-cli-*-SNAPSHOT.zip from http://www.monticore.de/dex/ 4. Unzip it 5. Go to dex-cli 6. Run the DEX generator

• java -jar dex-cli-*-SNAPSHOT.jar examples/dex/SocNet.cd out

7. Launch generated result:

• Go to out
• java -cp "./gen/;./gen/rte.jar" dex.socnet.SocNet
• Sources, installation, user instructions, trouble shooting
• http://www.monticore.de/dex/
• Parameters for the generator are (can be adapted):
• examples/dex/SocNet.cd

source CD

• ut

target directory for all code

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 21

Lets do a DEX generator demonstration

• Let’s modify our SocNet-example
•  adapt the SocNet.cd file
• and lets make another example
•  create or use other cd-Files

classdiagram MyOwnCD { class ... }

DEX generator

Generative Software Engineering

• 2. Generating Data Explorers

2.3. Architecture of the Generated Product

• Prof. Dr. Bernhard Rumpe

Software Engineering RWTH Aachen University http://www.se-rwth.de/ Farbe!

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 23

Structure of a generated Product

Parame- terized generator This is the principal structure of the generated code: Now we have a look, how DEX builds sub-structures Generator script/template Map: concept code model manually written code runtime system Environment: hardware, GUI, frameworks generated code + included parts

Predefined

components

Predefined

components

Predefined

components

API API

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 24

Structure of Generated Files

• The generator stores all files into
• dex-cli/out
• …/symtab
• … symboltable entries (not so interesting for the moment)
• …/gen/protocol, …/gen/reporting
• … detailed information about how dex generates files (cryptic)
• …/gen/dex
• … the desired java classes
• Java has its own package structure reflected in directories, so actually

we have all classes generated from SocNet.cd in

• …/gen/dex/socnet
• …/gen/dex/socnet/gui
• …/gen/dex/socnet/gui/impl
• …/gen/dex/socnet/persistence
• In total we have 206 Java files (from 10 classes in SocNet)

(on April 11, 2014)

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 25

Architectural Pattern: 3-Tier Reference Architecture

• DEX structures its generated products in the same way as standard

applications

• User interface never directly accesses (imports) persistence
• Persistence encapsulates access to data storage (includes DB)
• Application core is derived from domain data model
• Dimension #D1 of product structure:
• An appropriate architectural pattern / style

The architectural pattern: SocNet (generated) package structure:

Persistence Application Core GUI socnet socnet/gui socnet/gui/impl socnet/persistence

storage commands data structure

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 26

Examining Generated Files for SocNet.cd

• Counting classes and loc:
• Package

#classes #loc

• socnet

51 10967

• socnet/gui

26 2368

• socnet/gui/impl

106 24366

• socnet/persistence

23 4136

• Sum:

206 41837

• SocNet: 10 classes, 11 associations, ~ 70 #loc
• Result: a lot can be generated.
• But how much really needs to be generated?

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 27

How individual are Generated Files? -1

• Experiment: take Experiment.cd with
• nly one class “XSpecific”, no attributes
• Result
• Package

#classes #loc

• ...

8 684

• .../gui

3 80

• .../gui/impl

12 1034

• .../persistence

7 379

• Sum:

30 2177

• 2177 loc in total, but only 927 unique lines.
• “XSpecific” occurs 321 times in many variants (incl. comments)
• 19 Java filenames contain “XSpecific”
• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 28

How individual are Generated Files? -2

• Experiment 2: we compare SocNet.cd and Experiment.cd
• Package

#classes Experiment SocNet

• ...

8 51

• .../gui

3 26

• .../gui/impl

12 106

• .../persistence

7 23

• Sum:

30 206

• Result

#loc #loc

• SocNet

8512 unique (41837 total)

• Experiment 927 unique

( 2177 total)

• f which 630 lines are shared with SocNet
• and 297 individual to Experiment
• One filename in common (but different content)

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 29

How individual are Generated Files? -3

• Experiment 3:

compare two sets of generated files from same source SocNet.cd

• Result

#loc #loc

• SocNet

8512 unique (41837 total)

• f which 8507 lines are equal
• and

5 lines are individual

• Reasons for changed lines:
• Date and timestamp of generation process, e.g.
• "10:20:39 on day 11.04.2014"
• // generated at 10:20:39 on day 11.04.2014 from …
• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 30

How much Code is Generated?

• Some experiments show
• An empty CD with zero classes has

~ 450 #loc

• For each additional element we get roughly

~ 1800 #loc / class ~ 150 #loc / attribute ~ 1600 #loc / *-* association, bidirectional ~ 900 #loc / 1-1 association, unidirectional

• Results vary, because of different forms of attributes and classes

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 31

Common Code - Runtime Environment (RTE)

• DEX products also consist of immutable classes
• always in the product, independent of the domain model
• see: out/gen/rte.jar with currently more than 3425 classes
• DEX uses e.g.
• java.util.* etc.

standard functionality (e.g. Lists)

• com.google.common.*

useful stuff

• com.jidesoft.awt.*

for the GUI

• dex.*

DEX RTE

• mc.*, mc.umlp.cd.*

MontiCore runtime

• … and more
• DEX uses a DEX specific Runtime Environment (RTE)
• The RTE has ~195 classes, in the dex.* packages
• Dimension #D2 of product structure:
• Generated Code vs. RTE vs. Standard Components

(to be extended later by handcoding)

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 32

Runtime Environment (RTE)

• Runtime Environment (RTE)
• implements the core behavior of a computer language.

(Wikipedia)

• is a predefined set of classes assisting the generated code to

fulfill its function. (own)

• RTE is usually
• defined as common, domain independent functionality used by

the generated code

• or imported from existing libraries / frameworks
• Synonyms: run-time system, runtime system, or just runtime

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 33

Generated Code vs. RTE vs. Standard Components

• According two the two dimensions #D1, #D2

the DEX product architecture thus looks like this:

generated RTE standard components

Application Core

generated RTE standard components

GUI

generated RTE standard components

Persistence

• Legend: reflect possible static knowledge (import)
• Specific classes may import more general classes

Generative Software Engineering

• 2. Generating Data Explorers

2.4. Mapping Domain Classes to Code

• Prof. Dr. Bernhard Rumpe

Software Engineering RWTH Aachen University http://www.se-rwth.de/ Farbe!

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 35

Mapping of the Concepts of CD Lite

• The DEX generator maps each concept of CD Lite to code
• Classes
• Interfaces, abstract classes, enumerations
• Attributes
• Name + Type
• derived attributes
• Associations
• Name, role names, cardinalities
• Qualified associations
• Qualifier
• {ordered} association
• So we need to understand how these concepts (and their variations)

are mapped to code

• We concentrate on the application core of the product, because

we will later be interested to use and extend this core

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 36

Mapping a Domain Class to what?

• Given class Person:
• What should we generate

in the application core?

• interface Person
• class PersonImpl
• factory PersonFactory for object creation
• manager for existing Person Instances

class Person extends Profile { String firstName; // … } CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 37

Java

Mapping a Domain Class to an Interface

• Given class Person:
• DEX generates an interface
• signature of the domain objects
• attributes get access functions

class Person extends Profile { String firstName; // … }

public interface Person extends dex.data.DexObject, dex.socnet.Profile { public String getFirstName(); public void setFirstName(String firstName); // … }

methods for each attribute some standard functionality necessary for each domain object CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 38

Mapping a Domain Class to an Implementation

• Each class gets a default implementation
• DEX generates
• 2 constructors, getter/setter

class Person extends Profile { String firstName; // … } public class PersonImpl extends dex.socnet.ProfileImpl implements dex.socnet.Person, dex.socnet.Profile { protected PersonImpl() { super(); } protected PersonImpl (String firstName, … ) { this.firstName = firstName; // … } public String firstName ; public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; // … } … Java CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 39

Additional Implementation elements

• DEX generates some

additional implementations for methods from

• Object
• dex.data.DexObject

class Person extends Profile { String firstName; // … } public class PersonImpl extends dex.socnet.ProfileImpl implements dex.socnet.Person, dex.socnet.Profile { … // their behavior is based on all domain attributes public int compareTo(dex.socnet.Profile o) { … } public int hashCode(){ … } // these are used for deletion of objects public void removeObjFromAssocs() { … } // and for representation in the GUI public String dexguiGetScreenName() { … } } Java CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 40

Mapping Model Inheritance to Code

• Inheritance and implementation relation is preserved
• (CD lite doesn’t allow multiple inheritance, nor does DEX need it)

interface A; interface B; class C implements A; class D implements B inherits C; Model-CD

«interface» B DImpl «interface» D

Product-CD

«gen» «interface» A CImpl «interface» C

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 41

Mapping a Derived Attribute

• A derived attribute generates
• getter signature
• no attribute, no setter
• empty getter implementation
• (the class is complete and can be instantiated)
• The signature is given, but the implementation is useless and

needs to be added by

• handcoding (see Chapter 3) or by
• generating the implementation from OCL (see later)

class Group extends Profile { String /headcount; // … } public class GroupImpl extends … { public int getHeadcount() { return 0; } // nothing to support calculation or storage of headcount } Java CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 42

Object Creation for a Domain Class

• Normally to create an object :
• constructor is called,
• thus class must be known

(instead of interface)

• Adaptation by subclasses is then not possible.
• Solution: Use factory instead of constructor. DEX generates:

class Person extends Profile { String firstName; // … }

public class PersonFactory { // … // public access through static method (Singleton) // empty default constructor public static Person create() { // … finally it executes: return new PersonImpl(); } // 2nd constructor with attributes as parameters (in order they appear) public static Person create(String firstName, …) { } }

Java CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 43

Object Management for a Domain Class

• Given class Person DEX generates:
• a PersonManager
• it serves as
• access point to load/store objects
• manages the collection of objects of a type (incl. subclasses)
• manager uses different implementations (online / demo mode)

class Person extends Profile { String firstName; // … } Java

public class PersonManager { // … public static void remove(Collection<Person> objs) {} public static void add(Person obj) {} public static void update(Person obj) {} public static void synchronize() {} public static Person get(Person obj) {} public static void add(Person obj) {} public static boolean contains(Person obj) {} public static void clear() {} }

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 44

Views of a Domain Class

• A class in the domain model serves several viewpoints:
• 1) How to assess a class (for the generator user)
• the interface Person and the factory interface PersonFactory
• 2) How does it work internally (for the generator writer)
• the implementation PersonImpl
• 3) How can I adapt and extend the generated code and interface

(for the product programmer)

• later (see Chapter 3)
• Decoupling into interface and implementation nicely corresponds to

the first two viewpoints

Generative Software Engineering

• 2. Generating Data Explorers

2.5. Mapping Associations to Code

• Prof. Dr. Bernhard Rumpe

Software Engineering RWTH Aachen University http://www.se-rwth.de/ Farbe!

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 46

Internals of SocNet Core - Associations

• Associations in CDs are realized in DEx with respect to their
• Cardinality

e.g. 0,1,*

• Direction
• >, --, <->, <-
• Modifiers

abstract, / (derived)

• Qualifiers

e.g. [qualifier], <<ordered>>

• Optional role and association names
• The core idea is to map the variants of associations to appropriate

signatures and implementations

• The developer only needs to deal with the signatures
• But we also look at one or the other implementation to

understand the generator

• … and possibly adapt it.

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 47

Unidirectional Association, Cardinality [1]:

• Unidirectional association with cardinality [1]
• is mapped to methods for set/get (quite like an attribute)
• Additional, internal signatures are created
• e.g. when the object is deleted, so shall be the link.
• Direction determines where the methods are located
• methods are added on the source side of each navigation

association Relationship -> RelationType [1];

interface Relationship { … public RelationType getRelationType(); public void setRelationType(RelationType o); }

Java CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 48

Bidirectional Associations, Role Names

• Bidirectional association provide methods for link management on

both sides

• here is the direction <- and the role name given:
• + methods for class Person for other direction

Java

interface Tag { public Person getTagged(); public void setTagged(Person o); }

association [1] Person (tagged) <-> Tag [*]; CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 49

Association, Cardinality [*]:

• Association with cardinality [*]
• is mapped to methods for collection management

(quite like the Set<X> signature)

association [1] Person (tagged) <-> Tag [*]; Java

interface Person { public boolean containsAllTags(Collection<Tag> o); public boolean containsTag(Tag o); public boolean isEmptyTags(); public Iterator<Tag> iteratorTags(); public int sizeTags(); public boolean addTag(Tag o); public void clearTags(); public boolean removeTag(Tag o); }

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 50

Implementation of Associations

• Implementation depends on cardinality:
• [1], [0..1] map to an ordinary attribute
• [*], [1..*], [2..7] etc. map to a collection
• Redundant storage of links on both sides!
• Consistency needs to be ensured

Java

public class PersonImpl implements …Person { private java.util.Set<Tag> tags = new java.util.HashSet<Tag>(); // Tag-methods delegate functionality to Set, e.g. public boolean containsTag(Tag o) { return tags.contains(o); } } public class TagImpl implements …Tag { private Person tagged; // + getter/setter }

association [1] Person (tagged) <-> Tag [*]; Java CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 51

Consistency in Bidirectional Associations

• We need to ensure that links are consistent on both sides
• adding a link automatically adds the link on the other object
• DEX generates additionaly xGENXaddTag, xGENXremoveTag
• xGENX-methods are assessed from outside: thus public,

but should not be used by the developer: thus unusual name

association [1] Person (tagged) <-> Tag [*]; public class PersonImpl … { public boolean xGENXaddTag(Tag o) { return tags.add(o); } public boolean xGENXremoveTag(Tag o) { return tags.remove(o); } public boolean addTag(Tag o) {

• .xGENXsetTagged(this);

return tags.add(o); } } Java

Called from opposite side of link to make Bidirectional consistent Calling the opposite link

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 52

Unspecified Cardinality on Associations

• In case a cardinality isn’t given, defaults are taken:
• navigable side is assumed to be [0..1]
• not navigable side is assumed to be [*]
• Thus:
• A -> B ≙

[*] A -> B [0..1],

• A <-> B ≙

[0..1] A <-> B [0..1],

• A -- B ≙

[0..1] A -- B [0..1]

• Please note: not navigable direction still store references in opposite

directions for consistency reasons, e.g. in case when target objects are deleted (exception enums)

default:bidirectional

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 53

Deleting linked Objects

• Two realizations of the same structure:
• As discussed: for consistency DEX generates additional xGENX-

methods for the association

• and handle the associations as bidirectional
• DEX does that also for attributes,
• because when user deletes a Photo-object DEX also removes

the links in all places where the object was referenced

• Decision for DEX:
• Deletion is always possible and null is a possible value in

attributes as well as [1]-associations to classes (other than enums) defined in the CD.

class Tag { Photo photo; } association [*] Tag -> Photo [1]; CD

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 54

Derived Association

• a derived association means (in analogy to a derived attribute):
• only retrieval functionality is provided in the interface,
• but with emtpy / useless implementation in the Impl-class
• this is to be handcoded (Chap. 3)

association / member [*] Person <-> Group [*];

interface Person { public boolean containsAllMembers(Collection<Group> o); public boolean containsMember(Group o); public boolean isEmptyMembers(); public Iterator<Group> iteratorMembers(); public int sizeMembers(); } association name no manipulation methods

Java CD

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 55

Qualified Association

• a qualified association has same methods as unqualified assoc. plus
• methods from Map<X,Y> signature

Java association [1] Person (organizer) <-> (organized) [profileName] Group [*]; interface Group { //… boolean containsOrganizer(Person o); boolean containsOrganizer(String key); boolean isEmptyOrganizers(); java.util.Iterator<Person> iteratorOrganizers(); int sizeOrganizers(); java.util.Set<String> keySetOrganizer(); java.util.Collection<Person> valuesOrganizer(); Person getOrganizer(String key); void addOrganizer(Person o); void putOrganizer(String key, Person o); void clearOrganizers(); void removeOrganizer(Person o); }

key = attribute

• f type String

target type role name

CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 56

Ordered Association

• An <<ordered>> association provides List<X>-like signature
• More than 20 methods, here an excerpt:

Java association sent [1] Profile <-> Post [*] <<ordered>> interface Profile { //… boolean containsSent(Post o); boolean isEmptySents(); int sizeSents(); boolean addSent(Post o); void addSent(int index, Post o); Post getSent(int index); int indexOfSent(Post o); int lastIndexOfSent(Post o); void clearSents(); boolean removeSent(Post o); boolean removeSent(int index); void setSent(int index, Post o); } CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 57

Ordered Association – 2

• More functionality:

Java association sent [1] Profile <-> Post [*] <<ordered>> interface Profile { //… boolean containsAllSents(java.util.Collection<Post> o); Iterator<Post> iteratorSents(); ListIterator<Post> listIteratorSents(); ListIterator<Post> listIteratorSents(int index); boolean addAllSent(Collection<? extends Post> o); boolean addAllSent(int index, Collection<? extends Post> o); boolean removeAllSent(Collection<Post> o); List<Post> subListSent(int start, int end); } CD SocNet

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 58

Summary – Associations

This is the implementation and provided signatures:

• [1]-assoc.

 attribute + get/set

• [*]-assoc

 Set<X> + Set methods

• <<ordered>> List<X>

+ List methods

• qualified

 Map<qualifier,X> + Map methods

• DEX chooses to implement always bidirectional
• Consistency of bidirectional assocs is guaranteed
• Cardinality constraints are not guaranteed
• because DEX currently does not know how to handle violations
• DEX also provides search functions for [*] assocs

• Prof. Dr. B. Rumpe

Software Engineering RWTH Aachen University

Page 59

Summary – Lessons learned

• How to write class diagrams in CD lite
• How the DEX generator is started
• What DEX generates
• The architecture of the product
• Runtime environment vs. generated code
• How DEX maps classes and associations to code
• In particular we have seen:
• translation of associations has many facets
• the ratio output #loc / input #loc hints towards a

tremendous speedup in generative software development