Purpose of this post:
  • Determine how to name our model elements
  • Determine how to give an id to all of our model elements.
  • Determine which are supposed to be read-only, which are supposed to be unique.

Here is my view on the situation and correct me if I am mistaken:
  • all elements have an ID and a Name.
  • the ID should be read-only
  • the ID and the Name should be unique inside one .UCM file, meaning inside one URNspec.

One implementation strategy:
  • we're already creating all elements in ModelCreationFactory, usually via the static ModelCreationFactory.getNewObject(Class).
  • there are other ways (non-static) to use ModelCreationFactory
  • Elements to be named here.
  • Modify the getNewObject methods so that they can pass an optional parameter, an instance of URNspec.
  • add a method that will find a proposed name, given an instance of URNspec as described below.
  • if no URNspec is passed, no name is set.
  • the other method can still be called later, if we're creating many instances of an object but only picking one later on (see the Palette)
  • ModelCreationFactory should name its elements using this pattern:
    • ClassName{d}+
    • where ClassName, for example, ComponentRef, StartPoint, etc. (these can be derived from the Class passed in parameter to getNewObject).
    • d is be a non-empty sequence of digits.
    • d is one more than the highest suffix number of all instances of the prefix ClassName in the URNspec.

This strategy would be very slow and require verbose coding to figure out all the possible locations of a certain type of class in the URNspec. For example, to find a name for the next ComponentRef, we would need to check all ComponentRefs in all maps in all ucmspecs for the URNspec. However, if one would create ComponentRef1, delete it and insert a new one, we would get another ComponentRef1.

Another idea:
  • Keep a global naming registry that speeds up the computation.
  • Keep it in the multipage editor.
  • Reload it when the file is changed.
  • Explicitely invoke this registry to obtain a name when you're sure that you'll be keeping this object. We can't name the object in the factory because we would be incrementing counters for no purpose while using the palette.

Other ideas:
  • Just name them the same way the class is named; drop the requirement that the name must be unique.
  • Make it unique unless it is null; leave the default name at null.

None seem very good...

For the IDs:
  • ID = number of milliseconds/microseconds since 1970 ?

What did UCMNav do for this?

-- JasonKealey - 09 May 2005

Each time a class would request a new object from our creation factory it would look in a HashMap to see if the URNspec of the object was used before (we could use the eContainer method until we find the URNspec). If it was not used before we just add it in the hashmap, but if it was used before we could generate the name according to the value returned by the size of the list of components for exemple... The only problem with this is if we create for example 3 components and then delete 2 components the returned name would be like component1 when there could still be a component1 in the diagram with this name that was not deleted... Hum, I don't know if we could fix this...

-- EtienneTremblay - 09 May 2005

This solution would also imply that we have duplicates of all of our previous model elements in memory.

-- JasonKealey - 09 May 2005

Note: I'm not to sure if having a unique name is necessary (quite strong). It's not because we can't think of an occasion where elements should have the same name that we should force them to be unique. The ID's already garanty unicity, what do we gain from making the Name unique? (From the problems below, we seem to be losing on the implementation side, what compensation do we get on the application logic side?) Is there a critical reason why Names need to be unique?

-- JordanMcManus - 09 May 2005

No two responsibilities can have the same name. No two components can have the same name. Many responsibility references can refer to the same responsibility (and hence share the same name). Same idea about component references. Some other names (e.g. Boolean variables, scenario names, ...) will likely be unique within their sub-domain, but you do not have to worry about them since they are out of the project scope. IDs are certainly unique within the scope of one URNSpec, and they should be read-only. Names are bit more flexible, as Jordan observed (e.g., I don't think we should enforce unique names for start points and end points). Unique names for responsibilities and components ensure that when the name is used, then we are talking about the same concept (not just from a tool point of view, but also when the model is exported, transformed, or printed on paper).

UCMNav is not proposing default names, so there is no name generation per se. For unique IDs, it had several static counters. Gunter has recently fixed UCMNav to make sure IDs are not reused after loading/saving many times (this is required for integrating UCMNav with external tools like DOORS).

Mechanisms to generate element/component names and unique IDs should be kept simple. I do not care if some ID numbers are skipped. I do not think that using the clock to generate IDs is a good idea (but I may be wrong).

-- DanielAmyot - 10 May 2005

Currently when a UCM is loaded, UCMNav keeps track of the highest ID for each class (there are separate ID counters for maps, components, component references, hyperedges, devices, boolean variables, ...). I don't recommend doing that again. There should be one single ID mechanism for EVERYTHING in a UCM file.

UCMNav checks only if there are no duplicate component and responsibility names (references to components and responsibilities do not really have there own names as they are using the component and responsibility names). The user has to decide which name to use. The tool has to check that the user does not decide on a name which is already in use for the element.

The ID approach currently used by UCMNav guarantees unique IDs which remain constant when loading and saving a UCM file. It does not guarantee that an ID is not reused. If the element with the highest ID is deleted, the UCM then saved and reloaded, UCMNav has no idea that an element with such an ID did exist. It will reuse the ID. This has not been a real problem until now but it's only a question of time until it will.

I have questions:
  • can you guarantee that IDs generated with the clock are unique? (different computers are always set to different times).
  • how readable are IDs generated with the clock? (I spend too much time looking at UCM files, so that this is actually a concern).
  • does the "incrementing counters for no purpose while using the palette" problem also apply to ID generation? is yes, why is it a problem?
  • what's the range for an ID? is it likely to ever run out of ID space even if many IDs are skipped due to the internal logic of jUCMNav?

One way to make sure that IDs are always unique is to save the highest ID ever used in the file. Then, one could ensure that IDs of previously deleted elements won't be reused. Just in case, this saved ID would have to be double checked against the actual IDs used in the file when loading the file.

-- GunterMussbacher - 10 May 2005

I like your last thought; clean and simple.

To answer your questions:
  • if the file is edited on one single computer that doesn't change its time, yes, otherwise no.
  • non-sequential, probably badly readable
  • yes, but I have just created a test that downplays this disadvantage. if you select any element from the palette and then move your cursor over the drawing board, GEF calls our model creation factory and requests a new instance of an object, positioned at the cursor location. (actually, it is more complex than that). I thought that new elements were constantly created but in fact, one is created for the first possible location and is kept when the cursor is moved. Another one is created for the actual click. Therefore we would not have sequential IDs but close enough.
  • We can define it. The meta-model has them as strings right now. What do you propose in order to keep them readable? Do we want them to be defined as as ClassName{d}+ where {d}+ is the highest ID ever used in the file?
  • If we went for that solution, we might simply auto-name our components by their ID and let the user change them to meaningful (and unique) names.

-- JasonKealey - 10 May 2005

I would like to know your opinions on empty names and spaces in names. Right now, Responsibilities/Components cannot have empty names, but the rest can. There are no restrictions on spaces either. (Although I think I am trimming extra spaces from strings). -- JasonKealey - 20 May 2005
Topic revision: r9 - 20 May 2005, JasonKealey
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