A typical result of the underlaying filestructure of Rose. If Rose had a
proper database-repository, where a class was a configuration-manageable
entity on it's own (NOT stored in some .cat-file), this would probably not
be a problem at all.
> - 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.
>
When modeling in UML, I do not want to have to focus on tens- or hundreds-
of files, and trying to remember to save (and which to save) as a result of
only moving (or copying) a class from one place in my model to another.
(Besides, doesn't Rose give you a warning if you exit Rose and still have
unsaved controlled units open ?). With a DB-repository, the change (move or
copy) would be "stored" immediately, and you wouldn't have to bother at all
with keeping track with saved- or unsaved files.
Anyway, I've had a "round" with Rational about the use of plain ASCII-files
being used as repository before, and they seem to be of the opinion that it
is the best solution.
To bad that one do not wish to re-investigate other alternatives to the
ASCII-flat-file repository concept. Rose is otherwise a very good
UML-modelling tool, and would (in my opinion) be excellent if a better
solution for the repository had been chosen (not to mention the improvement
it would give to the multi-user aspects of the tool).
Regards
Arne
> -----Original Message-----
> From: Wimsatt, Sabrina [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 6:20 PM
> To: 'Yoder, Jeffrey'; '[EMAIL PROTECTED]'
> Subject: RE: (ROSE) Duplicate Unique ID's
>
>
>
> HI Jeffery,
>
> The Technote below explains information on how to fix this
> error and what
> causes this error.
>
> 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).
>
>
> For more information, contact Rational Software Technical Support.
>
> Please let me know if there is anything else that I can do for you.
>
> Thank you,
>
> Sabrina Wimsatt
> Technical Support Engineer
> > Rational Software
> > the e-development company
> (781) 372 - 3482
>
>
> -----Original Message-----
> From: Yoder, Jeffrey [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 12:06 PM
> To: '[EMAIL PROTECTED]'
> Subject: (ROSE) Duplicate Unique ID's
>
>
>
> I've done something that is causing my model to have
> "multiple objects with
> same unique ID." What sort of things can cause this (so I
> can avoid them in
> the future), and how do I resolve them?
>
> Thanks!
>
> Jeff Yoder
> ITT Aerospace/Communications Division
> Software Engineering Specialist
> 1919 W. Cook Road
> Fort Wayne, IN 46818
> (219)451-6508
> [EMAIL PROTECTED]
>
>
> **************************************************************
> **********
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * 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
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
This email, its content and any attachments is PRIVATE AND CONFIDENTIAL to
TANDBERG Television. If received in error please notify the sender and
destroy the original message and attachments.
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
