Here is an historical view of modifications to the URN metamodel implemented in jUCMNav and their modifications. Please visit URN Metamodel
for the most recent version. All older versions can be downloaded from http://www.site.uottawa.ca/~damyot/urn/
Finally, here is the first version of the URN metamodel (URN_01.mdl). Should be sufficient to cover a lot of the jUCMNav requirements. Classes in yellow go beyond what is required, and there are a lot more to come (related to performance, scenario definitions, and GRL). Hopefully the names will be good enough to explain the relationships, otherwise I can provide more explanation (I intend to document the model in Rose as well).
- 12 Mar 2005
Second version (URN_02.mdl), which supersedes the precedent for the implementation. I made inherited attributes protected instead of private (samething with association ends), I added a few missing attributes to ComponentRef
(x, y, labelX, labelY), and I created the class UCMmodelElement
, a superclass of most UCM model elements which will enable one to more easily create various traceability/refinement links to/from GRL model elements (this goes beyond your tasks, but I plan for the future). I added stuff for dynamic responsibilities and pools, but again this is out of scope.
- 13 Mar 2005
Third version (URN_03.mdl)
- Fixed data types (Integer -> int, real -> double)
- Fixed multiplicities for PathNode
- Fixed the enumerated types (removed String)
- Added conditions as separate objects (there are a lot fewer pre/post conditions than in UCMNav, but these are the ones that make sense and that can be used during the model traversal),
- Merged static/dynamic stubs
- Added EmptyPoint, FailurePoint, DirectionArrow
- Added URN links between UCMmodelElement and GRLmodelElement (out of scope).
- 15 Mar 2005
Fourth version (URN_04.mdl)
- Removed title from Map
- Fixed Map->PluginBinding multiplicity
- Added timeoutPath relationship between Timer and NodeConnection. Timers are also linked to a Variable and to a Condition.
- The Performance package has changed quite a bit (and is not stable yet)... Many new classes and associations that should not affect what you have done so far as they are all optional.
- 15 Mar 2005
Fifth version (URN_05.mdl)
- Factored out labels as separate objects. They all have deltaX and deltaY attributes. This should make Jordan's life easier. I can add another name:String attribute if this can help (however, this is not needed from the model point of view; the name attribute of the containing UCM model element is what should be displayed/edited).
- 29 Mar 2005
Sixth version (URN_06.mdl)
- Made the compositions bi-directional. Added role names and multiplicities.
- Condition now a sub-class of Label. Removed compositions from Loop and Timer.
- Added "nextGlobalID" String attribute to URNspec (for unique IDs).
- Added "filled" Boolean attribute to ComponentElement.
- Added "empty" Boolean attribute to Responsibility. Outside the scope of your project (but not of Jason's job!)
- Removed OpenWorkload and ClosedWorkload classes. Added "closed" and "population" attributes to Workload.
- 20 May 2005
Seventh version (URN_07.mdl)
- Workload class was abstract, now is concrete.
- 02 Jun 2005
Eigth version (URN_08.mdl)
- Added GRL metamodel
- New interfaces that define common element in GRL and UCM (Diagram, Connection, Node, ComponentRef and Component)
- Modified UCM-Map package to implement the new interfaces (some associations and attributes have been refactored using the interfaces).
- Map is now called UCMmap (to resolve conflict with java.util.map in the implementation)
- Removed PathGraph in UCM-Map package
- 26 Oct 2005
List of name modifications between metamodel 8 and 9
- Modification of the name of the abstract interfaces for GRL and UCM
- New elements in the GRL section for graphical representation of the notation (Bendpoints)
- Added EvaluationScenarios for GRL, which is used for the evaluation labels
- Added GRLNode as super class for IntentionalElementRef and Belief
- Modification of the assocations between ElementLink and IntentionalElement
- 29 Jan 2006
- 24 Feb 2006
- Modification of some associations visibility
- Added aggregation for the Evaluation
- 07 Apr 2006
- 19 Sep 2006
- Removed association between Timer and Variable.
- Made Initialization-Variable link bidirectional.
- Reformated figures:
- Black and white, no Rose icons for visibility.
- Classes in yellow have no GUI support in jUCMNav yet.
- 14 Nov 2006
- 01 Mar 2007
Several modifications for CSM export:
- Removed: repetitionCount from PluginBinding (unused)
- Added: repetitionCount:String="1" to Stub (for CSM export, at the stub level). Used String to allow for $VariableName to be provided.
- Changed: repetitionCount from in to String in RespRef for the same reason.
- Added: hostDemand:String to RespRef
- Added: transaction : boolean = false to PluginBinding
- GeneralResource and ActiveResource are now abstract
- Removed: description attribute from ExternalOperation (already covered by superclass URNmodelElement)
- 16 Mar 2007
Several modifications for CSM export (to accommodate the schema version 1.0.3):
- Added association between PerfMeasure and GeneralResource, and two more between PerfMeasure and PathNode (for Responsibility / ResponsibilityRef / Stub).
- Renamed association role respTime (Workload -> PerfMeasure) to responseTime.
- Demand is now associated with ExternalOperation, not GeneralResource
- Attributes multiplicity and schedPolicy were added to GeneralResource
- Many performance attributes in Demand, ActiveResource, and Workload were converted to (untyped) strings
- 28 Mar 2007
Two modifications for Aspect-oriented URN:
- Added new concern class with associations (see new URNcore.URNconcern class diagram)
- Added new pointcut boolean for stubs (initalized to false for backward compatibility)
- 20 Apr 2007
- Added new KPIModel package (extension to GRL) for Key Performance Indicators modeling (by Pengfei Chen and Alireza Pourshahid)
- Added type attribute (String) to URNLink type
- Classes in yellow still not supported by jUCMNav.
- 17 Aug 2007
- Difference between id, name and title for a Map class.
- DA: ids are generated automatically and are unique within a URNspec. They will be used in the future serialization to XML (when a schema is available).
- DA: the name is what is used to select a map or a plug-in, whereas the title was meant to be a bit more verbose. Even is it is present in UCMNav, it may not be necessary after all given that a description will be available. I will remove it.
- Which name should we use for Component(Ref/Element) and Resp(Ref/Element). The one inside the Ref or instead the Element?
- DA: The ones in the Element. The constraint here is that these names and descriptions are the same anyway.
- We need to study z-orders to be able to layer filled components properly. This will have implications within the model.
- DA: How about the innermost component at the top, and the paths at the very top?
- Please discuss the Connect class.
- Is it a figure that does nothing more than an empty node, except that visually it shows an end point connected to a start point.
- If so, what about end points connected to start/timers? Do we have to derive this visual cue from the incoming/outgoing path numbers? Have to rely on the fact that the "2nd incoming path" represents the connection path just doesn't sound right. Especially considering when we might someday have another optional incoming path to maage.
- Or, does in represent an endpoint connected to a start/timer/wait?
- That can't be true, it would lose all the behavioural aspects that it would have if it were in the waiting place/timer hierarchy. (timeout paths)
- DA: Connect elements, as the name says, connect two other elements (stars/end, end/wait, end/timer, empty/wait, empty/timer, abort/empty, abort/stub, etc.). It has no visual representation (so the connected elements are still displayed as before). The connect object acts more or less like a constraint: if one of the connected elements moves, the other moves as well. It as also semantic meaning for the scenario generation and the traversal mechanism. There might be a better way to capture this, but this is what we have in UCMNav and it worked so far.
- Do waiting places have abort paths? Various information sources seem to point to different answers.
- DA: No, they don't. You should not worry too much about the abort symbol. If you are referring to timeout paths, this will be clearer in URN_04 (one of the successor NodeConnection of the Timer is identified as a timeout path).
- Please review the relationship between PluginBinding and Map. We think a Map should be related to 0..* PluginBindings, not just one. Our understanding of the current schema means that one plugin can only be included in one stub, meaning no diagram could have two stubs, both linking to the same diagram. (Maybe this is what you want)
- DA: Indeed! Thanks for noticing this. Fixed.
- Why do nodeconnections have conditions? (and its news to me that EndPoints have conditions).
- DA: EndPoints must have postconditions. Some NodeConnection objects need conditions (e.g., the ones connected to the outputs of an OR-fork).