Eclipse Community Forums: Requirements Modeling Framework » represent ProR SpecRelations with BIRT

Home » Eclipse Projects » Requirements Modeling Framework » represent ProR SpecRelations with BIRT

represent ProR SpecRelations with BIRT [message #1415864]

Wed, 03 September 2014 17:24

Eclipse User

Hello community,
is there any idea to represent the spec relations of ProR with BIRT? As known, the SpecRelations are in another sub tree than the Specs itselfes inside the reqif file ( xml formed). I've tried with different approaches without success yet. If it would be possible to have inside the Spec table an additional column containing all the SpecRelations (in comma separated form or so), then a java script could filter by string match. However, I haven't found a function like "getAllRows" in BIRT yet.
Maybe, I'm completely on the wrong tack and it would be necessary to use "Data Cubes" or so.
Any ideas or hints?

Re: represent ProR SpecRelations with BIRT [message #1416084 is a reply to message #1415864]

Thu, 04 September 2014 05:36

Eclipse User

Hello,

Uh, I have no idea, as I know nothing about BIRT. Sounds to me that this is a question for the BIRT community, considering that the ReqIF model is just another EMF model.

Best,

- Michael

Re: represent ProR SpecRelations with BIRT [message #1417178 is a reply to message #1416084]

Thu, 04 September 2014 18:07

Eclipse User

Ok, I'll try to setup a qualified request in the BIRT forum. I'm BIRT and EMF newbie and not so familiar with the wording yet (like 'CDO', 'SDO' etc.)

My current approach is to write a post processor which evaluates the 'spec relation sub tree' and inserts the relations as simple text in additional dedicated new elements at each spec object. For it, I've added two columns 'To' and 'From' for each spec object.
Doing this, I've noticed that the 'VALUES's order seems not to be deterministic, e.g.:

<SPEC-OBJECT IDENTIFIER="_846D0B45EeSO977ZA_Yi6w" ...>
  <VALUES>
    <ATTRIBUTE-VALUE-STRING THE-VALUE="REQ_S1">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_-JJIMB4vEeSKpdGqS6WWug</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE="Text 1">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_E7QtEhAKEeSSMJsDiwMa7w</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE=".">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_kCMugDRqEeSBBsuDZrCkTw</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE=".">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_ScEI0DRrEeSBBsuDZrCkTw</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
  </VALUES>
  <TYPE>
    <SPEC-OBJECT-TYPE-REF>_E7QtERAKEeSSMJsDiwMa7w</SPEC-OBJECT-TYPE-REF>
  </TYPE>
</SPEC-OBJECT>
<SPEC-OBJECT IDENTIFIER="_UG4w4B47EeSO977ZA_Yi6w" ...>
  <VALUES>
    <ATTRIBUTE-VALUE-STRING THE-VALUE="REQ_S2">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_-JJIMB4vEeSKpdGqS6WWug</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE="Text 2">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_E7QtEhAKEeSSMJsDiwMa7w</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE="SA1000">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_9Cm88B46EeSO977ZA_Yi6w</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE=".">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_ScEI0DRrEeSBBsuDZrCkTw</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
    <ATTRIBUTE-VALUE-STRING THE-VALUE=".">
      <DEFINITION>
        <ATTRIBUTE-DEFINITION-STRING-REF>_kCMugDRqEeSBBsuDZrCkTw</ATTRIBUTE-DEFINITION-STRING-REF>
      </DEFINITION>
    </ATTRIBUTE-VALUE-STRING>
  </VALUES>
  <TYPE>
    <SPEC-OBJECT-TYPE-REF>_E7QtERAKEeSSMJsDiwMa7w</SPEC-OBJECT-TYPE-REF>
  </TYPE>
</SPEC-OBJECT>

(some parts omitted and replaced by "...") In this example '_kCMugDRqEeSBBsuDZrCkTw' and '_ScEI0DRrEeSBBsuDZrCkTw' are in different sequence, even though both specs are of same type '_E7QtERAKEeSSMJsDiwMa7w'.

This can make the column / order mapping a little bit more complicated. So, my question: Can I fasten the order of the elements of spec object?

Re: represent ProR SpecRelations with BIRT [message #1418016 is a reply to message #1415864]

Sat, 06 September 2014 07:05

Eclipse User

I've stopped at the following topic: In the reqif file, empty elements are not contained. For saving disk space it's ok. However, an xpath query like

/ATTRIBUTE-VALUE-STRING[3]/@THE-VALUE

don't address the correct element, if another is located before, currently empty and will set. When, the set element becomes the third [3] and the original the fourth [4].
Unfortunately, the BIRT xml data source spec https://www.eclipse.org/birt/release20specs/BPS23-XmlDataSourceSpec.pdf says:
"2. Only the following predicates are recognized:
• A single position predicate in the abbreviated form, e.g., "author[2]".
• A single equality condition based on an attribute value. E.g., "title[@lang='en']".
3. XPath functions are not supported"

If the <ATTRIBUTE-DEFINITION-STRING-REF> would be a attribute instead of an element, the query could match to the unique data type identifier inside the reqif file. A match query for element/text is not supported by BIRT.
Possible solution could be:
a) re-specify the data type as attribute instead of text inside the reqif file
b) support element/text match query in BIRT
c) support further data types like <ATTRIBUTE-DEFINITION-STRING1-REF>, <ATTRIBUTE-DEFINITION-STRING2-REF>, ATTRIBUTE-DEFINITION-BOOLEAN2-REF> etc.

Is this realistic? Any further ideas?

Re: represent ProR SpecRelations with BIRT [message #1419141 is a reply to message #1418016]

Mon, 08 September 2014 02:40

Eclipse User

Hi ProR User,

I don't think it's a good idea to process the XML, instead of working on the EMF model. Issues like ordering are trivial, if you process the model.

Having said that, you probably saw the work Said did on reporting [1]. I believe that he implemented a ReqIF-to-Json transformation for his Birt prototype. He checked his code into gitHub [2], so you can check it out and use the pieces that make sense to you (focus on org.eclipse.rmf.reqif10.pror.reporting.*). I have his email, so if you want to contact him, send me an email and I'll forward it.

Hope this helps!

- Michael

[1] http://www.formalmind.com/en/blog/reporting-pror-results
[2] https://github.com/sasalem/ProR_filter

Previous Topic:	Glossary in ProR
Next Topic:	does it exist a complete chain for requirements managament, uml, development and tests

Goto Forum:

-=] Back to Top [=-

Current Time: Sun May 11 21:38:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter