1. Separation Of Concerns: Mixins + Variability Models + Aspects in Umple CSER – June 2013 – Montreal Timothy C. Lethbridge, University of Ottawa tcl@eecs.uottawa.ca http://www.eecs.uottawa.ca/~tcl http://www.umple.org

2. 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 Umple2

3. In Umple: Modeling and programming are merged Round-tripping is banished T. Lethbridge CSER 2013 - Separation of Concerns in Umple3

4. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple4

5. 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 quality T. Lethbridge CSER 2013 - Separation of Concerns in Umple5

6. Approaches to Separation of Concerns Various 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple6

7. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple7

8. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple8

9. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple9

10. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple10

11. 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? T. Lethbridge CSER 2013 - Separation of Concerns in Umple11

12. 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>; T. Lethbridge CSER 2013 - Separation of Concerns in Umple12

13. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple13

14. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple14

15. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple15

16. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple16

17. 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/vmlhttp://try.umple.org/vml T. Lethbridge CSER 2013 - Separation of Concerns in Umple17

18. 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 Airplane>; } The above would synergistically combine with mixins T. Lethbridge CSER 2013 - Separation of Concerns in Umple18

19. 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 T. Lethbridge CSER 2013 - Separation of Concerns in Umple19

20. Questions? T. Lethbridge CSER 2013 - Separation of Concerns in Umple20