Our example concerns the simulation of the quality control aspects of an assembly line. The most abstract stratum is shown below and represents a high-level view on the system's structure. The system has a main quality control unit (QualityControl) that must be accessible as a singleton instance, hence the corresponding annotation. It controls an assembly line that consists of a variable number of control stations (ControlStation). The method process checks a given item passed to it by the single instance of class QualityControl. Items are represented by the abstract class Item and the concrete classes Nut and Screw. Adding a new item at the beginning of the assembly line shifts the existing items to the next control station (QualityControl.processOne).
Each control station is attached to a tester which checks the current item. For each tested item, a test report (ItemTest) is created. Testers come in two kinds: manual testers (here, Human) that are able to perform very complex tests, and automatic testers, e.g., industry-robots that are specialized for testing a single property of an item (here, Scale and Extensometer). The purpose of class ItemFactory is to create objects of type Screw and Nut in a random fashion, in order to test the quality control features. All mentioned methods already contain Java code (in total approx. 50 lines) which represents the application specific functionality for this (comparatively high) level of abstraction.
Both QualityControl and ItemFactory are annotated with a Singleton refinement annotation to make sure that only one instance of these classes exists respectively.
The Visitor annotation defines which product hierarchy (see the link element to Item) is inspected by which measurement facilities (the leafs of the Tester hierarchy, see the link abstractVisitor). The three concreteVisitor links designate the methods that need to receive an implementation in a stratum lower down the hierarchy. Finally, link kickOffVisitor defines the method that shall invoke the visitor.
The Observer annotation defines Tester to be an observer of ControlStation. Link notifyLocation defines the method which triggers update notifications to attached observers, whereas state refers to the state to be observed.
Annotation CollectionView is responsible for attaching a generic visualization framework to the system. This way, we obtain a rather fancy visualization of our sample system (almost) for free.
Subsequently, the ``Collection View'' transformation checks for an elementObserver link, referring to an Observer annotation. If this exists (as in our example), the transformation adds a second concreteObserver link to it, linking it to the class ElementVisualizer, which is also part of the visualization framework. If no link named elementObserver is found, the transformation will search for links state and notifyLocation which are used to parameterize a new Observer annotation. The link concreteObserver will again refer to the class ElementVisualizer.
Finally, class QualityControlVisualizerStartup is created so that it may set up the visualization framework and attach it to the quality control system. The result can be seen in the following figure (For simplicity reasons the Visitor annotation and associated classes have been hidden).
After the Observer annotations have been refined the last step is to unfold both Singleton and the Visitor annotation. The latter is associated with a refinement transformation that nicely illustrates how transformations involving iteration over model elements can still rather concisely be captured using Fujaba's Story driven modelling. The transformation rule is shown in the next figure.
The first activity matches the annotation links element and kickOffVisitor, then the necessary model elements are created (omitted here). The next two activities create the visit... methods: The bottom left-hand side activity iterates over all concreteVisitor links, executing for each the bottom right hand side activity. After all visit... methods have been created, the annotation is removed from the diagram, resulting in the final system:
Once the most detailed stratum has been obtained by unfolding refinement annotations, Fujaba's codegenerator may be used to generate the executable code. This involves converting all model-related constructs (classes, associations, etc.) into plain Java code and combining it with the code that has been accumulated by all strata refinements. The following screenshot shows the running application:
