ReModeler: Augmented Modeling with UML/Java


Fernando Brito e Abreu, Filipa Silva, Vitor Gouveia

QUASAR Research Group
Faculty of Sciences and Technology
Universidade Nova de Lisboa


A chronic problem is faced by companies that develop software: the gap between business requirements modeling and software design. This traceability problem is a nightmare for software V&V and evolution and can be considered the founding cause of the legacy systems phenomenon. In this demonstration we will introduce the ReModeler process for mitigating the previous problem for soft­ware developers using UML and Java. This process supports what we coined as the “Augmented Modeling” approach and is supported by the ReModeler tool.

Augmented Modeling ameliorates the traceability across the whole lifecycle, namely by providing a series of abstractions such as the synchronized visual scenarios, extended CRC cards, requirement implementation CRUD matrices or colored class diagrams. These abstractions allow to (i) improve the negotiation between client and supplier, (ii) perform impact analysis, (iii) reduce the intangible­ness of software artifacts, (iv) bridge the gap between static and dynamic modeling, (v) support the testing process, (vi) avoid the legacy sys­tems trap and (vii) document the software products.


Augmented modeling, reverse engineering, UML, Java, XMI, use cases, sequence diagrams, visual scenarios, CRUD, CRC cards, impact analysis


- Illustrate software requirements 

- Trace requirements to software architecture

- Perform impact analysis

- Improve / facilitate the V&V process

- Document the project

- Improve product and process quality

Target audience

- Software managers of projects using UML and Java

- Requirement engineers using UML use cases and scenarios

- Software architects / designers using UML class diagrams

- Programmers using the Java language

- Black-box testers

- White-box testers

- Software quality managers


1        Motivation

For several decades, software development stakeholders have been recurrent victims of the well-known software crisis problems, where naturally emerges the one of the legacy systems. The promiseland of model-driven development is expected to effectively mitigate those problems. Although we are still very far from getting there, we have successfully accomplished the first step: the wide­spread adoption, both in industry and academia, of a common notation for the different perspectives of software artifacts. Indeed, UML is a generic language composed of many diagrams that allow capturing different facets of a software system during the whole development lifecycle. However, the use of UML in indus­try is often limited to the adoption of use case diagrams, in the early require­ments elicitation phase, and class diagrams in the preliminary architec­tural design. Dynamic modeling is not used to its required extent and, as a conse­quence, there is a gap between requirements and software architecture. This UML gap, the main traceability sin, is responsible for the fact that the ulti­mate delivery is source code. In other words, we keep falling in the legacy sys­tems trap …

To radically change the previous poor state of affairs, we propose the Augmented Modeling approach which advocates that modeling must be extended to the whole lifecycle, from requirements definition to final acceptance. Augmented Model­ing aims at extending the traditional frontiers of UML modeling, by adding other perspectives / mechanisms of perception, which increase the productivity of its users.

In this demonstration we will present the ReModeler proposal, composed of a tool and underlying process, which supports the Augmented Modeling approach for software development projects using the Java programming language. Among other things it allows to automate the reconciliation between static and dynamic modeling, granting traceability of functional requirements, described through use cases scenarios, to their internal execution, expressed by means of sequence diagrams.


2        The ReModeler process

In the following sections we briefly describe the generic steps of the ReModeler process, while we identify the software development stakeholders to which each step concerns the most.

Step 1: Defining the Use Case Scenarios

The first step in the ReModeler proposal, usually performed by a business ana­lyst or domain expert, is the production of a detailed functional description of the system under consideration, using UML.  ReModeler tool allows importing use case diagrams in XMI (XML Metamodel Interchange) format, and then editing the corresponding structured scenarios (steps and sub-steps). XMI is the standard interoperability language, for importing and exporting diagrams.

This fine-grained facility for describing use case scenarios is absent in most UML tools, as they usually only support the diagrammatic notation of use cases, where you can, at most, add UML notes.


Step 2: Capturing the scenarios in execution

Capturing scenarios may occur in two distinct modes. Either you are developing a new system, incrementally delivering use cases one after the other, or you already have an existing (legacy) system. In the former case (forward engineer­ing mode) you can capture the scenarios of a new use case, whenever one is considered stable and, as usual, the corresponding code is put under configura­tion management for V&V. In the latter case (reverse engineering mode), you can capture all scenarios in a single session. Notice that for interactive systems, a scenario basically corresponds to a test case. The execution of a scenario causes the internal triggering of many events, namely messages exchanged among objects in the system.

The capture of a scenario in execution involves two actors: a design expert and a domain expert (business analysts or final user). The design expert selects and adjusts a powerful message filtering mechanism, the Interaction Filter, which allows considering only the relevant entities (packages or classes). For example, the interactions with the native Java libraries such as mouse or keyboard events can be excluded, since in practice we are more concerned with our own classes, the ones we have implemented in the realm of our system and are more error prone. Without the Interaction Filter, we would be emerged by a huge amount of irrelevant messages that would clutter our picture of the system.

Then, the domain expert executes the Scenario Captor for each scenario sepa­rately. He progresses through the selected scenario step by step, as he would do in normal practice (or a tester would do when running a test case), while in a separate control window he marks with a tick which of the scenario steps he is currently performing. This procedure has an interesting side-effect: it acts as a validation of the scenarios description. If the scenario steps do not match the interactions that occur in practice, then the scenario description is incorrect.

The Scenario Captor seizes two deliverables: a film of the user interactions (black-box perspective), that we call visual scenario and the sequence of inter­nal message exchanges (white-box perspective), that can be represented by a sequence diagram. Both perspectives include timing marks that allow synchroniza­tion on playback. Besides, we also get semantic synchronization, that is, we know which scenario step is being executed at each point in time, in both perspectives.

After capturing a scenario we can calibrate the filtering mechanism by inspecting the Execution Tracer. The latter indicates how many times each method, grouped by class and package, was involved in running the scenario. After calibration, the scenario should be captured again.


Step 3: Capturing the architectural information

This step can be done in parallel with the previous ones, but is a precondition for the following one. Its main aim is recovering the design structure (packages, classes and their interdependencies) as represented by UML class diagrams. If you are using a development environment that allows the synchronization between source code and class diagrams, then you already have it. Otherwise, the normal approach will be to for a designer or programmer to use a UML tool with reverse engineering capabilities to recover your class diagram(s). In both cases you will export it to XMI and import it in the ReModeler tool.


Step 4: Using the Augmented Modeling facilities

For software architects / designers we offer the Synchronized Visual Scenarios Player that allows the visualization of the interaction films between the domain expert and the software system under consideration. These films are synchro­nized, scene after scene, with the corresponding scenario steps being executed. Beyond being an important documentation tool, the visual scenarios are aimed to support the construction of test cases, since they capture, in a trace­able way, the intentions and corresponding actions of the domain experts. The player allows reducing or increasing the speed of the execution of the origi­nal scenario, as well as progression step by step, forward or backward, pausing and rewinding.


For software architects and programmers, the ReModeler proposal allows improving the understanding of each requirement implementation, by offering three facets of Augmented Modeling at different levels of abstraction, as follows.

Use Case Implementation CRUD matrix: this matrix presents, in a synthesized way, which classes are used, and how, in each scenario. Therefore it allows tracing requirements to implementation. CRUD is an acronym for Create, Read, Update and Delete operations.

Extended CRC cards: these cards are automatically generated in hyperlinked html format to allow navigation among them. They increase the maintainability by showing how architectural building blocks (classes) collaborate to implement each business requirement. The CRC (Class-Responsibility-Collaborators) cards technique was originally proposed by Kent Beck and Ward Cunningham, but its manual conception is unfeasible for medium to large systems.

Automatically generated sequence diagrams: as mentioned before, the Scenario Captor generates a sequence diagram for each scenario. Since they are stored in XMI format, we can visualize them using a UML tool with XMI import facilities. This is the most fine-grained deliverable. The transitions between scenario steps are represented in the diagram, therefore tracing the white-box to the black-box perspective.


Testers use a tableau-de-bord named Test Navigator, which includes statistical information regarding execution traces of each scenario, discriminated by class or method, with package or class coverage analysis, as well as timing informa­tion. With this additional Augmented Modeling facility, testers can guide the process of conception of test battery, aligning it with the business requirements, something that is hardly found in current practice. Testers can also use the Colored Package Diagram, and Colored Class Diagram, where a gradient of colors is used to represent the execution coverage of each unit (package or class). These colored diagrams give a more abstract dimension to test coverage analysis.


The described steps and corresponding techniques will be shown in action with a case study.