separation of concerns: mixins + variability models + aspects in umple cser – june 2013 –...

Separation Of Concerns:Mixins + Variability Models + Aspects

in Umple

CSER – June 2013 – Montreal

Timothy C. Lethbridge, University of Ottawa

[email protected]

http://www.eecs.uottawa.ca/~tcl

http://www.umple.org

Umple: Simple, Ample,UML Programming Language

Open source textual modeling tool and code generator

—Adds modeling to Java,. C++, PHP etc.

—Sample features- Proper referential integrity and multiplicity constraints on

associations

- Infinitely nested state machines, with concurrency

Tools

• Command line compiler

• Web-based tool (UmpleOnline) for demos and education

• Eclipse plugin

T. Lethbridge CSER 2013 - Separation of Concerns in Umple 2

In Umple:

Modeling and programming are merged

Round-tripping is banished


A Quick Look at Selected Umple features

Hello World

• http://helloworld.umple.org

State Machines

• http://statemachines.umple.org

• Switch to ‘GraphViz state diagram’ in the options menu


Separation of Concerns (SoC)Concern: Functionality or quality of a software system of

interest to stakeholders and which can be conceptualized separately

Separation of concerns

• Ability to develop a concern in a software system with:

—Minimal need for knowledge of other concerns

—Minimal conflicts with development of other concerns

—Minimal need to change requirements/model/design of the concern when other concerns change

—i.e. fewer dependencies

• Ability to include/omit the concern or compose with others

• Result: Simpler system, greater flexibility, greater qualityT. Lethbridge CSER 2013 - Separation of Concerns in Umple 5

Approaches to Separation of ConcernsVarious types of modules (files, functions, classes, packages,

libraries, services, aspects, variants, etc)

Various mechanisms to include/invoke/compose/separate concerns, while (ideally) minimizing coupling:

• Cloning (deprecated)

• Calling

• File inclusion/import

• Inheritance

• Aspect orientation

• Mixins and traits

• Variants

• Transformations

• Service invocation


Mixins and traits

Mixin

• Ability to define some code/model that can be included (or not) in a various classes

• Explicit copy at compile time, as opposed to inheritance

• Popular in Ada, Ruby

Trait

• Closely related to Mixins

• Behaviour (abstract methods, or code calling only such methods) that can be included (or not) in classes

• Scala


Pros and cons of traits/mixins

+ Facilitate SoC without the complexity of inheritance

+ Can give some of the power of multiple inheritance in languages without it

+ Form natural building blocks for features that can be included in variants

- Code/model for classes becomes ‘spread out’ (delocalized)

• Hard to know entire class content unless there is tool support to show this


Intra-Class Mixins in Umple

Mixins allow including attributes, associations, state machines, groups of states, stereotypes, etc

Example:

class X { a; }

class X { b; }

• The result would be a class with both a and b.

It doesn’t matter whether the mixins are

• Both in the same file

• One in one file that includes the other in an other file

• In two separate files, with a third file invoking them


Why Did We Decide to Support Mixins?

Alternative use Cases:

• Separating abstractions

—High level: Class diagram concepts, state machines,

—Lower level: Methods

• Separating methods in multiple languages

• Separating features

Demo

• http://metamodel.umple.org


Limitations of Mixins in Umple

A mixin cannot be included in multiple classes, except:

• When the mixed in code is inherited

• When mixing in state machines defined as first-class entities

Limitations haven’t proved much of a problem in practice

Our research questions

• Should we lift the limitations?

• Are there compelling use cases for more capability?

• If so what syntax and semantics?

• What would be the favourable or adverse consequences?


One Possible Umple Extension:Patterns as Reusable Concerns

Composite pattern in file GeneralHierarchy.umpp class Node {

// Methods that apply to all nodes

}

class SuperiorNode {

0..1 -- * Node;

isA Node;

// Methods would go here; could be mixed in

}

Invocation to create an organizational chart use GeneralHierarchy.umpp <

Node ->> Employee,

SuperiorNode ->> Manager>;


Key Philosophies in Extending Umple 1

We must have a concrete problem to solve

• Ideally an application of the concept in the Umple compiler as well as some other system

• Not just ‘toy’ or ‘academically interesting’ examples

Adding a new feature must have net benefit when considering

• Umple usability

—Ease of learning

—Speed of development for end-users

• Maintenance and other qualities of Umple itself


Key Philosophies in Extending Umple 2

Syntax and semantics must be as harmonious as possible with

• C family languages (C++ / Java / PhP etc.)

• UML

• Existing Umple features

We should boldly go where others haven’t

And yet …

Follow others where they have blazed a trail


Aspect Orientation

Create a pointcut that specifies (advises) where to inject code at multiple points elsewhere in a system

• Pieces of code that would otherwise be scattered are thus gathered into the aspect

But: There is potentially acute sensitivity to change

• If the code changes the aspect may need to change

• Yet without tool support, developers wouldn’t know this

Delocalization even stronger than for mixins


Aspect Orientation in Umple

Pointcuts are currently limited

• Just inject code before and after execution of methods

—Currently only generated methods

• Cannot cross class boundaries

—except when the injected advice is inherited

Again, we have found these limited abilities nonetheless solve key problems and

• we don’t crave too much more


Variability Modeling in Umple/VML

Define bits of model as variants that can be put together to create different versions of a product line

Currently

• Concerns list sets of variation points

• Variation points can be filled by variants

—Blocks of Umple code- Hence also Java, PhP, C++ etc.

—Optional, required, and/or, etc.

Demo: http://try.umple.org/vml


Ideas for Improving Variability Modeling in Umple

Can we simplify to just have ‘variations’?

variation xxx {

//Umple Code

class X {}

use gef.ump;

requires aaa and bbb; // These are also included (

requires not ccc; // ccc cannot be present at the same time

requires ddd or eee; // At least one of these is required

requires fff xor ggg; // Either of these but not both

// Rename elements from pattern using generics

requires zzz <Vehicle=>Airplane>;

}

The above would synergistically combine with mixins


Conclusions

Umple, as a text-based platform combining modeling and coding allows us to experiment with separation of concerns

We have found basic mixin and aspect capabilities combined are very useful

We believe the language may be improved by further synergistic additions:

• Limited extensions to mixins and aspects• Simple variant capability

But ‘loading on the features’ may be counterproductive


Questions?


separation of concerns: mixins + variability models + aspects in umple cser – june 2013 –...

Documents

concerns changei

umplein umple

state machineshttp

software system

tool support

graphviz state diagram

simpler system

variants codemodel