I think I need a spike in what concerns working with GEF. It is certainly possible to make the composition of two figures – the class rectangle and the dashed rectangle with the template parameters. But, I never worked with GEF and graphical programming isn't my game. So, just for fun, lets make this spike.
Provide a UI action to create a parameterized class. This should be similar to what is currently used to create a normal class. After creation, the parameterizable class properties shall be editable, as usually ocurs for the rest of the model elements. The user may immediatly enter the parameterized class name.
It is possible to create a parameter for a template. This should work in a similar way as creating / adding attributes to a class. By default the template parameter type is a Classifier, its name is PARAM and it has no default value.
The properties of a template parameter are visible and editable in similar ways as properties of other model elements.
Parameterized classes are constrained to have associations only with classes, being uni-directional from the template to the class. An exception is that a bound class is associated through a bind association to the template, being this directed from the bound class to the template.
NOTE: this is too restrictive for common use with programming languages that support templates and maybe we should relax the specified constrains.
The parameterized class is represented graphically as specified in the UML spec. It is possible to add parameterized classes in class diagrams. The template parameters are editable, but, must respect the rules of the UML spec. It is possible to hide the list of parameters, but, the dashed rectangle remains visible [I'm not totally sure if the spec realy means this].
In the context of a parameterized class it is possible to create a bound class. The parameters must be bound to actual values according to their types. ArgoUML must enforce this either by using default values or by rejecting the creation of the bound class.
The bound class is similar to a class with the added properties of the template parameters values and the bind association to the template. All the properties are visible and editable, with the exception of the bind association, the attributes and operations of the template which are read only.
The UML spec allows to have a bound class with the name explicitly showing its nature, e.g.,
ParameterizedClassName<Param1Value, Param2Value>. With this presentation it is possible to edit the parameter values in a very simple way. So, it is not needed to have a non-explicit name.
The bind association may show explicitly the parameter values in brackets, as exemplified in the UML spec.
The parameterized class template parameters are usable within the parameterized class for parameterizing its attributes and operations. This means, for instance, that the type of an attribute may be a template parameter.
It is possible to delete a parameterized class from the model. The usual model element deletion rules apply, which means, all bound classes are also deleted. A warning is shown to the user stating this, but he may silent it permanently.
It is possible to remove a template parameter from the model. The usual model element deletion rules apply, which means, all depending attributes, operations and operation parameters are also removed.
I'm now reviewing the UML support for Parameterized Classes. I'll simply take some notes here about my findings before starting to write User Stories. First a disclaimer, I used UML 1.5 spec since I don't have 1.4 available now. When I get the chance I'll look at that to see if there are changes in this area.
UML defines the
Template concept as a "parameterized model element". Strangely a restriction to this is that it "cannot be used directly in a model". Does this means that I cannot say that a
Parameterized Class specializes a normal Class? No, the spec explicitly allows two exceptions: "a template may be a subclass of an ordinary class" [ufff!] and one way associations from
Templates to other classes.
More strangely, the "«bind»" association is what is used in UML to create a normal class from a
Template, by specifying the parameters. Guess what, the association is from the resulting class – the
Bound Element to the
Template, thus violating the rule expressed just above. Well, I guess this should be the third exception: one way association with stereotype bind from Bound Elements to Templates.
All model elements may be Templates, but normally, in addition to Classes, the model elements that are parameterized are
Packages. I think that adding support for these two isn't much more effort since the semantics and notation are very similar.
While considering this I had the idea of a simple refactoring that is usualy done in programming languages that support templates and which may be supported by ArgoUML: creating a
Parameterized Class from a
Class. This is something interesting because UML does not allow it since the class normally has associations. So, it must be something specific to the tool.
Now that I've studied a bit XP and learned about the concept of Spike, I must consider the work up to now on
ModelerImpl as a huge Spike. The proof is my note when it was started after a big analysis effort that resulted just in some inconsistent ideas. The Spike, resulted in some very strong ideas:
ModelerImplmust delegate its reverse work to a tree of objects, each specialized in its own constructs, acting on a current context.
ModelerImplmust reverse to something else than the actual user model. Preferably it should do it to a new empty model that is in a subsequent step reconciled with the user model. Note that this should not preclude future optimization paths like simply checking if some file was already imported and comparing the previous taken MD5 signature with the current.
- Importing Context smells more and more like an aspect of the way I've implemented the importing, being based on callbacks from the parser. I wonder if I was using a built AST of the code, if I would recur to this...
- User Stories – I'll be the writer and creator, instead of being the result of input from a customer. The User Stories will be included each in the issue to enable gathering feedback early in the development for modifications and prioritization. It is possible that some will be grouped and handled in separate issues, with #1446 depending on those. I'll develop acceptance tests only when these are possible in a small ammount of time. The acceptance tests will be stored in ArgoUML as Unit Tests. Apart from these details I'll try to keep then as described in XP.
- Spike Solution – Support for parameterized classes implies changes in almost all the most important ArgoUML sub-systems. Due to the fact that I'm not acquainted with many of them I'll need to make quick and dirty attempts to know if some devised solution works. These will be my Spike Solutions; I'll record then in a minimum with small notes, the time spent on this will be accounted as part of the story implementation, the planning or whatever, and in the end their results will never be incorporated in the code directly.
- Test Driven Development (TDD) – This will be followed fully. I don't know how I'll do it for GUI (JFCUnit isn't used in ArgoUML), but, this must be done without exceptions.
- Refactor Mercilessly – Refactoring will be followed fully. The problem is code without tests that exists in ArgoUML and that committers may feel insecure to patch with my refactorings. So, this will probably be difficult, but, I'll try to make it happen!
- I don't have commit rights to ArgoUML, so, I can't enforce the integrate often rule because someone must commit my future patches;
- my time availability is variable and scarce, so, some times I leave unfinished parts during week time spans;
- state of the art support for both acceptance tests and continuous integration requires infrastructure that I don't have and that possibly would take very much time to set up with others' help, since I'm being pragmatic I won't try this for now.
Last but not least, the methodology taken as a whole seams to be more appropriate to teams than it is to individuals, even if working for an open source project with a good community. I would like to see examples of XP applied to open source projects by hobbyists. Probably these would not take the whole thing, even if all team members follow XP.
That's why I will continue to use the Process Dashboard and be inspired by its functionalities and underlying process. I must read the book one of these days!
Now I remember that I know of an open source project that follows XP, its the JyDT. I wonder if Red Robin would provide some feedback on his experience... It was XP before going open source, so, I wonder how he is doing it now...
I'll start now with issue #1446 – Lack of support for Parameterized Class (Template). This is a complex issue and so, I must handle it as such, by having a plan where I must define iterations for partial deliveries. I think I'll follow some of the eXtreme Programming (XP) practices in this development, such as Test Driven Development (TDD), small iterations for delivering complete user stories, Refactoring and simplicity.
Planning the development of 1446. For this activity I'll use the Process Dashboard tool to measure the time I spend in each of the tasks and a scheme similar to what I've developed in the previous work for C++ reveng support. The main difference is that I'll use user stories to drive the development, being the iterations necessarily more formal and regular. This step must be revisited as often as possible (in the end / start of a user story development cycle should be the norm), being sub-sequent updates to the plan documented here.
EE 25 Mh; SN – Planning
Review the XP practices that I'll use in this development – TDD, Refactoring, User Stories, automated builds and possibly more if applicable. The selection of practices will follow the pragmatic objective of choosing the ones that are possible with a minimum effort. For example, I've left out the continuous integration and acceptance tests since I don't have infrastructure for this. Some of the practices will be adapted to be practical, like the definition of user stories might be defined by me. This isn't subverting the practice totally since I'm also a user of ArgoUML ;-). In the end of this task I must have a list of the chosen XP practices, with descriptions of how some of these will be applied, where I can't follow closely the practice as defined elsewhere.
EE 8 Mh; SN – Review XP practices
Review the UML support for parameterization using the UML 1.4 specification. I must check also other UML elements where parameterization is possible, so that I'm able to develop a good set of user stories that is representative of the work. My objective is just to develop an overview, so, writing one paragraph with the conclusions is enough.
EE 4 Mh; SN – UML support for parameterization
Writing the set of user stories for guiding the development of support for parameterized classes in UML. I don't know very well what will be the result of this activity, since I'm not acquainted with user stories, but, after this step I must have a decent set of them written. It is likely that the first set of user stories won't be complete or correct. Any additional writing will be done here, unless it occurs just for the correction of one user story while developing it. In that case the time spent with this is accounted in the step of the given user story.
EE 10 Mh; SN – Writing user stories
This idea is buzzing inside my head for some months. Why not specifying test cases in UML? We may use the object representation to specify the instances involved in a test case. Then, a collaboration or sequence diagram may represent a test case. Also, test cases might be grouped in classes that have the
In my view we can support this by defining a UML profile called UML Unit and adding mapping for code generation and reverse engineering to ArgoUML to the existing unit testing frameworks: JUnit, CppUnit, NUnit, PyUnit, etc. It would be interesting to add support to this idea to AndroMDA also, since an obvious target is to enable Test Driven Modeling (TDM) at the PIM level. I know that the Executable UML supports this for years, but, this isn't available in open source tools. So, by having a simple mapping to POJO like PSM that could even be the source code, we could have the same thing without the need to have a UML virtual machine.
The assertion and verification may be modeled as OCL statements. But, this implies code generation support for OCL statements. This is something that isn't yet supported in ArgoUML, although OCL is supported for some years.
So, after verifying that issue #3552 isn't correct I'll change it to the documentation and fix the docs. Its name will be "header_incl warning in manual's C++ appendix is wrong and solving TODOs".
Michiel van der Wulp commited my patch to the documentation which includes the C++ generator documentation. Daniele Tamino created two of the above issues, but, I must check the problems I had with duplicate tagged values. In the ArgoUML GUI the duplicated values are shown and reloaded correctly. Maybe this is only replicable when the tagged values are queried like when the C++ module tries to find it... No, it works correctly, so, the warning and TODO will be replaced with a hint to use multiple times the tag.
The issues are: