How to disable Requirement Title uniqueness ?

[Former Member]

hallo ,

i tried to find a point where in Requirement Model ( Model Options ..." etc.) i could disable the uniqueness check for Title.

(Code is unique) but if i add with vbs a new Requirement with same Title i get an error.

The Base Problem is that the Business Analysts will switch the Requirements to a new Requirement ( with same "Title" ) but a new Code

and set a Extended Prop. "State"  to  Active or Inactive.

The impl. of new Ext. Prop is easy but i raise the "Feature" of uniqness Titles

I think in other Models the Code / Name could be different ?

thanks

/br

[Former Member · Accepted solution]

Thomas,

This is not really the answer you are looking for, but I used to struggle with the same issue.  In the long run I just surrendered and then found I really didn't need or want that capability.  One of the things I like about PD is how it enforces/teaches methodologies or practices.  I learned more about database design and object design from "Check Model" than anywhere else.

Overall one of the best practices that has become second nature to me is the concept of unique titles for everything.  If no two things have the same name they can never get confused.  Some things that are tough to avoid at first though is making hierarchies of names, like Product_Edition_Version_Release_Requirement1.

With requirements, I had rookie analysts that were used to writing requirements in Word.  Some requirements were a sentence (or fragment), and others might be a paragraph.  Forcing then to provide a short project wide unique title and then description made them better analysts quickly.

If you really need duplication you can do things like using stereotypes.  If you create a stereotype and make it a metaclass then you can have duplicate names as long as they aren't in the same stereotype.  Stereotyping also adds another dimension to classification in requirements beyond the hierarchy.

[Former Member · Accepted solution]

thanks , thanks ,  thanks this help me a lot ,

i try this and it works well.

and if this is a common PD feature i did not know it´s maybe helpfull with other problems to .

i understand now that the Key for PD is not only Code/Name/Title it includes the Stereotype as well

i try this with Entity also and it works also there .

br

[Former Member · Accepted solution]

Yes, the PK includes the stereotype.  You can use them just about everywhere to give another level of abstraction.  They have a lot of features like adding custom attributes or collections at the stereotype level.  One of the most helpful and simple is custom symbols in your diagrams.  For me a custom symbol is not usually a symbol change (except in EAM), but just a format change.  So in your example you could add a custom symbol for Active Objects that changes only the background color to green, and Inactive Objects background to yellow.  Then your diagrams are easier to understand (and prettier ) I always create a custom symbol for all of my "Lookup" tables.  In some analysis I have ended up with 5X the number of lookups over base tables.  Having different background colors automatically assigned by stereotype really clarified the overall diagrams.  I usually keep one diagram I call Top that has every object in the model so I get a global view.  Having different colors for different types of objects makes this a usable model.

If you go the color route spend some time up front creating a palette ("add to custom colors") you can use across your models or enterprise.  That way things are consistent and you avoid color clashes (hello Sybase).  Am I the only one that things the art director for Sybase and PD was colorblind?  Every time I see the default background color for a PDM table I think of my kids - actually their dirty diapers.

If you haven't, check out the PD MetaModel, under Help.  It will help you understand PD better and also give you some real appreciation for the original design.

[Former Member]

Thomas,

the title is only an alias of a requirements name, Name and code of each object in PD have to be unique in a namespace.

For requirements you can only use a title more than once, in this special case:

.... The Title must be unique for requirements at same level but a sub-requirement can share the same title value

(from Metaobject Help)