So our problem is, given a UML model (built in Rational Software Modeler) consisting of separate sections, how do we create a SoDA template that allows us to dynamically ‘pick’ sections to report on.
I solved this problem by creating a control element in the UML model. I then added logic to the template, which interrogates the control element, and depending on what it finds there, limits what it reports on. It is not important what UML element you use as your control element. I elected to use a Deployment Specification. To this, I added a number of attributes, one for each section we may or may not want to report on. The fig 1 depicts a sample of a project that we would typically work on. Notice that the model is split into a number of packages, one of which is called Document Control. Inside the Document Control package we have our Deployment Specification ‘control element’ called sections.
Now that we have our control element with attributes, we want a way of switching these attributes on and off. I use visibility, but any other on-off UML property will suffice. The advantage of using the visibility attribute is that Rational Software Modeler displays the public/private nature of an element very clearly in its project explorer.
The next step is to create a template that first examines the control elements attributes and then, depending on the visibility, includes or excludes sections. The pseudocode for this template looks as follows:
Open the model
Repeat through all packages and return the one called “Document Control”
Repeat through all Deployment Specifications and return the one called “Sections”
Limit omit if the next repeat returns nothing
Repeat through all attributes and return the one called “Section 1” if it is public
You may now add report logic you would like to display in this section.
End Repeat through all attributes
End Limit omit
End Repeat through all Deployment Specifications
End Repeat through all packages
Fig. 2 is a screenshot of my template
Looking at it from a high view, we can imagine it working as follows (depicted in fig. 3): Your control package tells the template what needs to be reported on. The template fetches the data from the other model packages. That data gets put into the final report. Bear in mind that this flow of control is not actually happening as shown, but it is a high level way of understanding it.
In ‘A More dynamic SoDA (Part 3)’ We will discus some of the advantages and disadvantages of this reporting model. Until next time.
Luck is the residue of design.
- Branch Rickey - former owner of the Brooklyn Dodger Baseball Team