Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Requirements Modeling Framework  » Display "Spec-Hierarchy"'s long-name attribute in ProR's Specification Editor
Display "Spec-Hierarchy"'s long-name attribute in ProR's Specification Editor [message #885133] Tue, 12 June 2012 14:12 Go to next message
RADOUANI anass is currently offline RADOUANI anassFriend
Messages: 3
Registered: March 2012
Junior Member
Hi,

Is there a way to display "Spec-Hierarchy"'s long-name attribute in ProR's Specification Editor?

Regards,
Anass
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 Go to previous messageGo to next message
Michael Jastram is currently offline Michael JastramFriend
Messages: 161
Registered: April 2010
Location: Düsseldorf, Germany
Senior Member
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 #885203 is a reply to message #885141] Tue, 12 June 2012 15:49 Go to previous messageGo to next message
RADOUANI anass is currently offline RADOUANI anassFriend
Messages: 3
Registered: March 2012
Junior Member
Thank you for your reply,

As I understand it, the SpecHierarchy object is only used to define a hierarchy, with the requirement data itself being contained in the associated (if any) SpecObject.

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?

Regards,
Anass
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 Go to previous message
Michael Jastram is currently offline Michael JastramFriend
Messages: 161
Registered: April 2010
Location: Düsseldorf, Germany
Senior Member
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
Previous Topic:Proposal for importing requirements from Excel
Next Topic:org.agilemore.agilegrid 1.2.3 can not be resolved
Goto Forum:
  


Current Time: Thu Nov 27 14:55:29 GMT 2014

Powered by FUDForum. Page generated in 0.06447 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software