abstratt's blog

Feature: shorthand notation for aggregation and composition

16th September, 2008 - Posted by rafael.chaves - No Comments

Shorthand notation for both composite and aggregate associations has just been checked in (r99-r100). It follows the same spirit as the existing shorthand for plain associations (a.k.a. references).

composition <end-name> : <referenced-type-name>;

or

aggregation <end-name> : <referenced-type-name>;

That will result in a new unnamed association with two member ends, one named, owned by the declaring classifier, with composite or shared aggregation type, and another unnamed, owned by the association itself.

Change set explained

When adding a new feature to the notation, the typical change set contains:

• updates to the affected grammar production rules
• implementation of the corresponding model generation handling code
• a few test cases.

In the case of the features presented in this post, the grammar change was quite simple (nicer view):

--- trunk/plugins/com.abstratt.mdd.frontend.textuml.core/textuml.scc	2008/09/16 05:47:13	99
+++ trunk/plugins/com.abstratt.mdd.frontend.textuml.core/textuml.scc	2008/09/16 05:47:20	100
@@ -341,7 +341,9 @@

   attribute_decl = attribute identifier colon type_identifier optional_subsetting semicolon ;

-  reference_decl = reference identifier colon type_identifier optional_subsetting  semicolon ;
+  reference_decl = reference_type identifier colon type_identifier optional_subsetting  semicolon ;
+
+  reference_type = {association} reference | {composition} composition | {aggregation} aggregation ; 

   optional_subsetting = subsets qualified_identifier | {empty} ;

In other words, where one could declare a reference, one can now declare also a composition or an aggregation (gotta love the readability of SableCC grammars…).

The corresponding model generator (a.k.a. compiler) changes were quite trivial as well, even more so if you consider I inadvertently checked in a fix to an unrelated bug around comments (just ignore the changes in lines not in the 300′s).

In terms of lines of code, the bulk of the changes were in the test class for associations, where I added three test cases. I had postponed writing tests for the reference shorthand notation, so I took this opportunity to write a test for it too.

As most test cases in the TextUML Toolkit test suite, the new test cases in AssociationTests have the following layout:

• one or more compilation units with TextUML source code are declared
• source code is compiled and the resulting errors verified (most test cases won’t expect errors)
• the resulting model is checked – were the expected elements created? Do they have the expected features?

Talking about tests

The TextUML Toolkit has a modestly sized test suite (~130 test cases) at this time. It could use dozens, probably hundreds more, but most features are covered to so some extent.

However, as important as coverage, is how much one can learn about the piece of software being tested by reading its test suite. And here is where I believe the TextUML Toolkit’s test suite shines. For example, by reading the test classes, one could (maybe more effectively than by reading the notation guide), learn how the following UML features are exposed by the TextUML notation:

• classes and structural features
  
• packages, imports, profiles
• associations
• multiplicity
• template classes

Trivia: can you find out from the test suite the difference between a private and a public package import? Give it a try and let me know if I am lying… by the way, the notation guide does not cover that yet, although the UML specification, of course, does.

Read More