ID's are generated by using system clock.
They remain the same until you delete the item.
More information on this is spelled out in technical note below:

################################################################
TN ID: 8565
PRODUCT: Rational Rose
OS: All
DEFECT #: N/A
PATCH #: N/A
REFERENCES: N/A
CREATED: 22-jul-1999
REVISED: 08-jan-2001

QUESTION:

When opening a model, I am getting the following message:

> Warning: This model has multiple objects with the same unique id.

What does this mean and how can I fix this problem?

ANSWER:

Warning: This model has multiple objects with the same unique id:

 1. What is a unique id?
 2. How to fix this error?
 3. How this error is caused.
 4. petal file keywords for ids

-------------------------------------------------------------------
1. What is a unique id?
-------------------------------------------------------------------

 Each element in a model has a unique ID, which is set internally.
 You cannot set this value, but you can retrieve if you have a need 
 to by using Rose scripting (see GetUniqueId Method).

 A unique id is simply the current time expressed as the number 
 of seconds elapsed since some point in time in the past, 
 concatenated with the fraction of a second of the current time, 
 in milliseconds.  Specifically, on windows we use the _ftime 
 function which returns the time elapsed since Jan. 1, 1970.  On 
 unix, we use gettimeofday.

 The generation algorithm also guarantees that the id will be 
 unique during any given session of Rose and in general, will be 
 unique for all models/units generated on a single machine, 
 assuming the date never gets set backwards.  It's not likely 
 that duplicate ids will be generated, however the resolution 
 algorithm makes it even less likely that it would lead to a 
 problem, because:

 a) most references are resolved by name first and only if name 
 resolution fails, e.g. the name changed while the referencing 
 item was in an unloaded unit, will it check unique ids.

 b) When resolving a unique id reference, the kind of thing being 
 searched for is always used.  For example, if the code searches 
 for uid 12345, kind Class, it would never find a package even if 
 there was one that had uid 12345.

 How and when Rose needs these UIDs, i.e. how Rose is accessing 
 elements. This is done with the following algorithm:

 1. Rose searches after the Qualified Name of the element (i.e.
    package-hierarchy::element.name
 2. When not finding the element, Rose searches within all model 
    elements of the same element type (i.e. it doesn't search the 
    use cases, if it's searching a class) after the element with the 
    same UID.
 3. if it doesn't find the element type WITH matching UID, it 
    places the (M) circle sign in the diagram, or places 
    parenthesis around the textual references.
    (i.e. if you attached a class to an object in a scenario diagram, 
    and then delete the class, the name will stay there, but in 
    paranthesis. If you then recreate the class (which gives it 
    another UID!), it is 'reconnected' to the object)

-------------------------------------------------------------------
2. How to fix this error?
-------------------------------------------------------------------

 Fix-up capability, is conditional on there being a rose.ini 
 entry, "FixDuplicateIds=Yes".  The fix entails changing the uids 
 of units as they are read in if a duplicate uid is detected. 

 Please note that you need to have Rose 98 Service Pack 1
 or a newer version to be able to fix the problem.
 (the fix will not work in older versions).

 You can resolve this error by adding the following setting to
 the rose.ini file.

 FixDuplicateIds=Yes

 The fix entails checking the rose.ini setting, FixDuplicateIDs, 
 and if set, regenerate unique ids when duplicates are encountered.  
 This rose.ini setting is not written out by default and defaults 
 to false if not specified, so the fixup code would never execute 
 unless you specifically set it.

 You need to keep the following in mind when using this feature:

 1) MAKE SURE YOU FIRST DO A BACK UP BEFORE TURNING ON FIX-UP MODE.  

 2) It's impossible to fix references to the uids since we don't 
    know which one the reference should point to.  We have to rely 
    on resolution by name, and if that doesn't work, some 
    references might get resolved to the wrong model item.

 3) uids are used by many code generators (stored in the source 
    code), so changing uids could have negative impact.

 4) all units should be writable and special care should be taken 
    to do the fix-up if the unit is read-only (make it writable) 

 5) if unit is shared among models, make sure all models are 
    updated or if the unit is shared by several models (make 
    sure name hasn't changed).

 6) user should turn off this setting as soon as the model is 
    fixed up.
 
 To enable this fix:
  
 1) Close Rose.
 2) Locate rose.ini 

 rose.ini default location under windows:

 NOTE: below is the DEFAULT location for rose.ini.  This
 location can be changed by modifying the following
 registry setting:

 HKEY_CURRENT_USER\Software\Rational Software\Rose\IniFileDir

 Win95:
 
  rose.ini default location is in Rose's home directory 
  (location of the rose.exe).

 NT:

  rose.ini under profiles is used.
 
  Each user (login id) will have their own profile. By default
  the rose.ini is stored under application_data of the profile
  directory of the user.

  C:\WINNT\Profiles\<<login_id>>\Application Data\Rational\Rose\6.0

  For example if you log in as administrator, the following 
  location is used:

  C:\WINNT\Orofiles\administrator\Application Data\Rational\Rose\6.0

  NOTE: Making changes to rose.ini in home dir under NT has 
  NO effect!

 Windows 2000:

  rose.ini file is located in the following default location:

  C:\Documents and Settings\<<username>>\Application Data\Rational\Rose\6.0

  NOTE: By default this is now a hidden file and directory
  in Windows 2000, which was not the case under NT.  To see it:

  1. Right-click My Computer, and then click Explore.
  2. On the Tools menu, click Folder Options.
  3. On the View tab, click Show hidden files and folders, and 
     then click OK.

  NOTE: Making changes to rose.ini in home dir under Window 2000 has
  NO effect!

 .rose.ini location under unix:

 It is a hidden file in the home directory:

  $HOME/.rose.ini.

 You should see it if you do a ls -a $HOME.

 This file is copied from the location listed below,

  /rational_dir/releases/rose.6.0.9158/Rose.ini

 The first time you start Rose.

 Rose script program to confirm location of rose.ini

 To determine the location of rose.ini you can run the following 
 Rose script (Tools:New Script).

 Sub Main
  MsgBox RoseApp.GetRoseIniPath()
 End Sub

 3) Open rose.ini in text editor
 4) Locate the section that beings with
    [Rational Rose]
 5) Add the following line anywhere below [Rational Rose] section.
      FixDuplicateIds=Yes.
    Note: this setting does not currently exist
    i.e. FixDuplicateIds=No setting, so you must add it.    
 6) Save
 7) Start Rose, load problem model, then File:Save

 When FixDuplicateIds=yes is set in the rose.ini
 there should be a checkbox on the save subunits dialog box.
 This box has to be checked in order for this to work...
 Units are not marked as modified will not get fixed.
 So you will either have to touch affected units
 to get the new uids written, or check the checkbox on the 
 "Save subunits" dialog to force a save of all loaded units.

 Save subunits
 Save modified subunits of <filename>.mdl?
 [] Force save of unmodified subunits that are loaded and writable
 [Yes]  [No]

 8) Quit Rose and turn off this setting as soon as the model is 
    fixed.
 9) If a unit is shared among models, make sure all models can 
    load the unit correctly after the uids have been modified.

 OTHER possible fixes:

 1) 
 If the number of duplicate unique id's is small, you can fix the 
 model by hand editing the petal files and just removing one of 
 the uid's that is duplicated--a new one will be generated when 
 it's read back in.  

 SEARCH ON duplicate id # reported in log 

 EXAMPLE:

 Warning: This model has multiple objects with the same unique id:
 366BE08D0373.

 SEARCH on "366BE08D0373"

 in BOTH .mdl and .cat files.

 DELETE THE ENTIRE LINE:

 quid     "396658380360"
 quidu    "396658380361"

 EXCEPT if () on line

 Leave Parenthesis

 i.e.

 quid     "3966586E0277"))

 after deletion looks like:

                        ))
 EXAMPLE:

 BEFORE:

 (object Class_Category "NewPackage"
    is_unit     TRUE
    is_loaded   TRUE
    quid        "39665845037D"
    exportControl       "Public"
    logical_models      (list unit_reference_list)
    logical_presentations       (list unit_reference_list))

 AFTER:

 (object Class_Category "NewPackage"
    is_unit     TRUE
    is_loaded   TRUE
    exportControl       "Public"
    logical_models      (list unit_reference_list)
    logical_presentations       (list unit_reference_list))

 A new one will be generated when the file is MODIFIED AND
 SAVED. If you do not modify the file, then the blank line
 will still exist!  However this should not effect the loading
 of the file, i.e. you should not recieve any error on the
 file assumming you delelted only the quid $ ###### from
 the file.

 2)
 To isolate the offending object I usually unload all packages and 
 load them one at a time until I get the unique ID warning message.  
 Then use it the model integrator to locate the offending class.  

 Rational provides the model integrator which assist in comparing 
 and merging multiple models, it will list objects which have the 
 same unique ID but different names.  This would allow you to 
 compare different model units for conflicting object IDs. 

-------------------------------------------------------------------
3. How this error is caused.
-------------------------------------------------------------------

 Multiple objects with the same unique id  can be created by 

 - editing the mdl file directly and using Cut and Paste. 
 
 - loading controlled units into an existing model, and the 
 controled units contained classes which already existed in and 
 the model.  
 
 - I have seen a user drag an item from one control unit to 
 another as a way of copying the item. They then modify the item 
 and save the "changed" control unit but don't save the control 
 unit the item was dragged from. They do not realize that they 
 have relocated an item rather than copied it. When they open  
 both control units the next time, they have two items with the 
 same ID.

 - In our environment, the most common cause of duplicate ID's 
 comes when users start moving elements between different cat 
 files. Usually, someone check's out two cat files then moves 
 an element (e.g., a class) between them. Then, they save the 
 destination but abandon the check-out of the source. That means 
 that the source reverts to a version that still contains the 
 element but they now have a second instance of it in the 
 destination. Sometimes, a developer will want to move an item 
 but can't because the source is not writable. In this case, they 
 occasionally go into browse units and write enable the package. 
 That allows them to move the element. But, because the package 
 (underlying cat file) was not really writable, you cannot record 
 the fact that something is now missing and end up retaining the 
 original. Again, the element ends up in both files. 

 - The duplicate QUID have been introduced when Package Units 
 were saved as various file names in an attempt to "copy" them 
 like a template.

 - I typically get this error when I load controlled units into 
 an existing model, and the controled units contained classes 
 which already existed in and the model.  

 - A procedural way to force multiple unique IDs.
 DO NOT DO THIS !

 File New
 Create 2 packages A and B
 control both of them
 In pkg A create a pkg X and add 3 classes to X
 control X ( as X.cat)
 unload A (do not uncontrol it)
 go to pkg B
 import X.cat
 control X.cat (from pkg B, overwriting the original X.cat)
 Save the model and subunits.
 reload

 - Known defects with older versions of Rose:

 1) ROSE 98: import
 2) Problem with control Units, Rose 4.0.6 and earlier
 3) ROSE Visual Basic 4.0.6

 1) ROSE 98: import

 Known defect,
 DEFECT 131810 Getting hundreds of warnings of multiple unique ids

 export a package
 open the exported .ptl file in a new design
 edit the names of everything in the package (e.g. add a prefix to the
 package and class names)
 re-export it
 open the original model
 import the edited package
 Since all the names have changed, no import errors will be reported, but
 everything in the imported package will have the same unique id as the
 originals.

 Rose 4.0 didn't report duplicate id warnings when loading this type of
 model, but rose98 does. The root of the problem is the export: UID's 
 should not be preserved when doing an export.

 2) Problem with control Units, Rose 4.0.6 and earlier:

 Known problem:
 DEFECT 124145 - "Duplicate unique IDs" warning messages when loading a
 controlled unit

 FIXED in post 4.0.6 releases.

 3) ROSE Visual Basic 4.0.6

 In Rose\Visual Basic 4.0.6 when you open a model file that
 contains more than one file (1 mdl file + 1 or more cat files) you
 will get the following warning "This model has multiple objects
 with the same unique id: xxxxxxx"

 This is a defect in Rose VB. If the model is composed of different 
 files then some of the item names will be found in different files. 
 For example the same cat id will be in the mdl file and the cat 
 file itself. In this case Rose should not cause the warring message 
 above. But unfortunately it does.

 This defect is FIXED in a update to Rose\Visual Basic, 4.0.6a.

 This update will not remove the multiple object messages in a model
 already created, but will prevent it from happening.  All you need to
 do is, ignore the message, save and re-open.

-------------------------------------------------------------------
4. petal file keywords for ids
-------------------------------------------------------------------

 - petal file keywords for ids:

 uid - old keyword used for operation unique ids.  Operation
 unique id's have been around since 2.0 since they were needed by
 C++ RTE.

 quid - Rose 3.0 expanded the uid mechanism so that a unique id
 could be associated with anything, but only associations and
 operations used them in 3.0 (now, everything uses them).
 The q stands for quasi.

 A QUID is the definition of the element, example :
   (object Class_Category "pack1"
     is_unit            TRUE
     is_loaded          FALSE
     file_name          "$MODEL_ROOT\\p1.cat"
     quid               "39A65F9A0274")

 quidu - a reference to a unique id (the u stands for uses).

 A QUIDU is a reference to the definition element, example:
   (object CategoryView "Logical View::pack1" @1
        location        (336, 688)
        font            (object Font
            size        10
            face        "Arial"
            bold        FALSE
            italics     FALSE
            underline   FALSE
            strike      FALSE
            color       0
            default_color       TRUE)
        label           (object ItemLabel
            Parent_View         @1
            location    (192, 604)
            fill_color  13434879
            nlines      2
            max_width   288
            justify     0
            label       "pack1")
        icon_style      "Icon"
        line_color      3342489
        fill_color      13434879
        quidu           "39A65F9A0274" <--- QUIDU
        width           300
        height          180)

 If you look in petal, a relationship will have a quid
 (its unique id in case anything needs to refer to it, such as
 views of the relationship shown in diagrams) and a quidu (the
 unique id of the supplier of the relationship--e.g. if A inherits
 from B, the quidu of the inherit relation will refer to B).
################################################################

Patrick Kennedy
 Rational Support

-----Original Message-----
From: Tom Tanner [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 04, 2002 7:51 AM
To: [EMAIL PROTECTED]
Subject: (ROSE) Rose identifiers





Does anyone know how the rose class identifier numbers (the quid numbers in
the
model) are generated. I suppose the question I'm asking is:

   How unique are they between models? They seem to be unique within a
model.
   Are they stable (once you've created a class, will it always have that ID
in
   the model)?

Cheers

Tom


************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Post or Reply to: [EMAIL PROTECTED]
* Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
*    http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*    To: [EMAIL PROTECTED]
*    Subject: <BLANK>
*    Body: unsubscribe rose_forum
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Post or Reply to: [EMAIL PROTECTED]
* Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
*    http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*    To: [EMAIL PROTECTED]
*    Subject: <BLANK>
*    Body: unsubscribe rose_forum
*************************************************************************

Reply via email to