|
| Re: Display "Spec-Hierarchy"'s long-name attribute in ProR's Specification Editor [message #885141 is a reply to message #885133] |
Tue, 12 June 2012 14:22   |
|
Hello Anass,
When you say "display the attribute", I assume that you mean to display it in the Specification Editor? ProR currently cannot do this (and I'll tell you why in a minute). However, the value is shown in the properties view.
An important concept of ProR is to keep the ReqIF model and the user's information model separate. The ReqIF model structure is rigid and defined by the OMG standard. Users who want to work with requirements build the structures they need on top of this model (in other words, the requirements model sits on top of the information meta-model, which sits on top of the ReqIF meta-meta-model). But the features of the ReqIF model are not meant for the end user, but for internal use.
This means that longName is not really meant for the end user. We show this information (and many other interal features), as we see ProR as a tool to inspect ReqIF files (amongst others). But this should be treated more then debug information, rather than end user data.
I am not (yet) familiar with Topcased requirements. But maybe you can model the Section class's identifier as an attribute of the SpecObject that the SpecHierarchy refers to? If you do that, then you simply have a "normal" Attribute that you can include in the Specification View.
Hope this helps!
- Michael
|
|
|
|
| Re: Display "Spec-Hierarchy"'s long-name attribute in ProR's Specification Editor [message #885287 is a reply to message #885203] |
Tue, 12 June 2012 18:43 |
|
Hello Anass,
Yes, I understand your concern. On the other hand, the data model of ReqIF allows the reuse of requirement information by referring to the same SpecObject multiple times (i.e. thTrough multiple SpecHierarchies). The idea is to separate the requirements information (the SpecObjects) from their presentation (i.e. the structure imposed on the view on the requirements data through the SpecHierarchy).
Quote:I'm somewhat concerned by the idea of adding SpecObjects containing no requirement data, and instead being used to provide information about its containing SpecHierarchy Is this something we're allowed to do under the ReqIf specification?
There is no way to attach requirements information directly to a SpecHierarchy - the actual information should always reside in the SpecObject (well, you could hack the SpecHierarchy by using longName, but that is not in the spirit of the standard). What you could do, however, is to constrain the GUI to not expose all ReqIF features. For instance, you could enforce through the GUI that there is always a one-to-one relationship between SpecHierarchy and SpecObject, i.e. that a SpecObject must always be referenced by exactly one SpecHierarchy, and that there must not be SpecHierarchies without SpecObjects.
It is useful to remember that ReqIF was designed as a data exchange format (and not a data model). Therefore, many tools do not support all ReqIF features. So specifically, if you would use, say, DOORS to author your requirements, the exported ReqIF would fulfill the constrains that I just described.
Best,
- Michael
|
|
|
Powered by
FUDForum. Page generated in 0.03887 seconds
] 
Search
Help
Register
Login
Home
