You are here: ProjetSEG Web>URNMetaModel>URNMetaModelOld (29 Jun 2009)

URN Metamodel - Old Versions

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

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).

-- Daniel Amyot - 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 Component Ref? (x, y, labelX, labelY), and I created the class UCMmodel Element?, 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.

-- Daniel Amyot - 13 Mar 2005

Third version (URN_03.mdl)

  • Fixed data types (Integer -> int, real -> double)
  • Fixed multiplicities for Path Node?
  • 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 Empty Point?, Failure Point?, Direction Arrow?
  • Added URN links between UCMmodel Element? and GRLmodel Element? (out of scope).

-- Daniel Amyot - 15 Mar 2005

Fourth version (URN_04.mdl)

  • Removed title from Map
  • Fixed Map->PluginBinding multiplicity
  • Added timeoutPath relationship between Timer and Node Connection?. 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.

-- Daniel Amyot - 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).

-- Daniel Amyot - 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 Component Element?.
  • Added "empty" Boolean attribute to Responsibility. Outside the scope of your project (but not of Jason's job!)
  • Removed Open Workload? and Closed Workload? classes. Added "closed" and "population" attributes to Workload.

-- Daniel Amyot - 20 May 2005

Seventh version (URN_07.mdl)

  • Workload class was abstract, now is concrete.

-- Daniel Amyot - 02 Jun 2005

Eigth version (URN_08.mdl)

  • Added GRL metamodel
  • New interfaces that define common element in GRL and UCM (Diagram, Connection, Node, Component Ref? 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 in the implementation)
  • Removed Path Graph? in UCM-Map package

-- Jean Francois Roy - 26 Oct 2005


  • 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 Evaluation Scenarios? for GRL, which is used for the evaluation labels
  • Added GRLNode as super class for Intentional Element Ref? and Belief
  • Modification of the assocations between Element Link? and Intentional Element?

List of name modifications between metamodel 8 and 9 -- Jean Francois Roy - 29 Jan 2006


  • Modified Evaluation Scenario? (and renamed them Evaluation Strategy?)
  • Moved criticality and priority attribute from Intentional Element? to Intentional Element Ref?
  • Added author attributes in Beliefs and Evaluation Strategy?
  • Removed id, name, description and type from URNLinks

-- Jean Francois Roy - 24 Feb 2006


  • Modification of some associations visibility
  • Added aggregation for the Evaluation

-- Jean Francois Roy - 07 Apr 2006


  • Add expression property to Responsibility (definition)
  • Remove link between UCMspec and Scenario Def?.
  • Create recursive link between Scenario Def? and itself for included scenarios (0...*).
  • Make Scenario Def? included in at most one Scenario Group? instead of 1...*
  • Remove link between Variable and Condition.
  • Add class Enumeration Type? extends UCMmodel Element? (to be similar to Variable)
    • string name (already in URNmodel Element?)
    • string description (already in URNmodel Element?)
    • string [] values
  • Add class Scenario Start Points?
    • boolean enabled
  • Add class Scenario End Points?
    • boolean enabled
    • boolean mandatory
  • Composition Enumeration Type? inside UCMspec (as with Variable) (1 to 0...*)
  • Link from Variable to Enumeration Type? (1 Variable to 0...1 Enumeration Types?)
  • Link from Scenario Def? to Scenario Start Points? (0...*)
  • Link from Scenario Def? to Scenario End Points? (0...*)
  • Link from Scenario Start Points? (0...*) to Start Point? (1)
  • Link from Scenario End Points? (0...*) to End Point? (1)
  • Link from Scenario Def? to Condition (0...*) named Preconditions
  • Link from Scenario Def? to Condition (0...*) named Postconditions
  • Add class Initializations
    • string value
  • Link from Scenario Def? to Initializations (1 to 0...*)
  • Link from Initializations to Variables (1 to 1)
  • Scenario Def? should not be abstract.
  • Add Metadata class for URNmodel Element? annotations

-- Jason Kealey - 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.

-- Daniel Amyot - 14 Nov 2006


  • General Resource? (Performance) is now a UCMmodelelement

-- Daniel Amyot - 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)

-- Daniel Amyot - 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

-- Daniel Amyot - 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)

-- Daniel Amyot - 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.

-- Daniel Amyot - 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 Node Connection? of the Timer is identified as a timeout path).
  • Please review the relationship between Plugin Binding? and Map. We think a Map should be related to 0..* Plugin Bindings?, 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 End Points? have conditions).
    • DA: End Points? must have postconditions. Some Node Connection? objects need conditions (e.g., the ones connected to the outputs of an OR-fork).
Topic revision: r1 - 29 Jun 2009 - 18:08:15 - Daniel Amyot
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback