Home » Eclipse Projects » Requirements Modeling Framework » Improving upon the id presentation
| Improving upon the id presentation [message #1064949] |
Fri, 21 June 2013 20:15  |
 François Rey
Messages: 17
Registered: October 2012 |
Junior Member |
|
|
Hi,
I'm wondering how hard it would be to improve upon the existing id presentation.
Basically I'd like to have human ids that count within the same level and branch in the tree, and display concatenated ids reflecting the path taken to reach a line.
So, if we imagine 2 functional areas abbreviated BE and TM, and within each areas use cases prefixed UC, themselves containing scenarios prefixed SC, then it would look like this:
BE
..BE-UC01
....BE-UC01-SC1
....BE-UC01-SC2
..BE-UC02
....BE-UC02-SC1
....BE-UC02-SC2
..BE-UC03
TM
..TM-UC01
....TM-UC01-SC1
....TM-UC01-SC2
..TM-UC02
....TM-UC02-SC1
....TM-UC02-SC2
..TM-UC03
...
Such naming scheme makes it possible to know a few things by just knowing the id. Also renumbering would be automatic when inserting/deleting new lines.
I imagine that to implement such scheme, one would have to:
1. associate the counter with a certain level in the tree and a certain SpecType
2. access the path needed to reach a line from within a presentation object
3. retrieve information from objects on the path, i.e. their SpecType and presentation
4. selectively discard some objects on the path, e.g. section headings, when building the id
[/LIST]
I'm quite new to RefIf, ProR, so it would be great to get some guidance:
- not sure how this could play out with existing api and concepts, I assume presentations are for presentation, but we're talking about a reasonable amount of logic and state as well
- point 1 above has value in itself, and can be implemented separately
- if so, then some presentation composition/interaction is required in order to build a presentation upon an existing one
Cheers,
François
|
|
|
| Re: Improving upon the id presentation [message #1064965 is a reply to message #1064949] |
Sat, 22 June 2013 06:13  |
|
Hello François,
What you propose is doable, and it should not be too difficult to implement. However, this is very different from the current ID presentation: The generated ID will never change and thereby allow SpecObjects to be identified even as the specification changes. What you envision seems more similar to the outline numbering that you find for instance in Word. As the rows get inserted and deleted, the number of a given element changes.
Note that we already have something like this: The left column that is part of the table control (the row labels) already follow a similar dynamic naming scheme:
1
1.1
1.2
2.
...
Also note that it would be a bad idea to write the number into the actual content: A SpecObject could be referenced multiple times in different places of Specifications. Therefore, the same SpecObject could have different numbers in different places.
What I would recommend would be an improvement not of the ID Presentation, but of the Headline presentation, which you could extend to dynamically render (but not store) the Outline numbering in its cell. Or you could just create a new Presentation, wich would probably be a great exercise to get started with writing Presentation Plug-Ins.
Best,
- Michael
|
|
| |
| Re: Improving upon the id presentation [message #1065268 is a reply to message #1065057] |
Tue, 25 June 2013 08:02 |
|
Hi François,
There are two kinds of IDs. Do you know DOORS by any chance? There, each requirement has an ID that never changes. Also, Title elements have Outline numbering that changes. Outline Numbering is generated on the fly (and proabably not stored), as it used for structuring, not for identification. I am still not clear whether you are interested in identification or outline numbering.
As far as the technical realization is concerned: An outline number would not be stored anywhere (except maybe in a cache). To be specific: If you would want to modify the HeadlinePresentation, you could modify HeadlineCellRenderer.doDrawCellContent (and also .doDrawHTMLContent). You would then find, on the fly, generate the outline_number. You would do that by looking at the position of the current element within the Specification hierarchy. Then you could simply render outline_number + " " + text.
The tricky part is generating the outline number, wehere you probably would have to recursively jump from parent SpecHierarchy to SpecHierarchy, until you reach the parent Specification. If this turns out to be to slow, then you could cache outline_number.
Hope this answers your question.
- Michael
|
|
|
| Re: Improving upon the id presentation [message #1065976 is a reply to message #1065268] |
Fri, 28 June 2013 14:52 |
François Rey
Messages: 17
Registered: October 2012 |
Junior Member |
|
|
Hi Michael,
I don't know DOORS. My view on what I'd like to do is also evolving. I'm now thinking about a more generic presentation that would treat an attribute value as a template to be fed into a templating engine for rendering. Right now I'm thinking of StringTemplate because it's reasonably small, powerful, and self-contained. It also has ports to other languages which could help making such feature work across tools. Such feature should be reasonably easy to implement and can do much more:
- prefix and separator become part of the template, e.g. REQ-<count>
- named parameters enable different numbering scheme, e.g. <global-count>, <sibling-count>, <sibling-same-type-count>, <parent-ref>, etc.
- object property access becomes possible, so one can insert other attribute values, e.g. "<so.ref> <so.description>"
- comments in template can be used to store information, e.g. <! count=123 !>, <! old-values=REQ-2, REQ3 !>, etc.
What I described earlier would be something like "<parent-ref>-UC<sibling-same-type-count>".
About storing ids or not: when collecting requirements and nothing is shared or published, we do not need to have fixed references, these can dynamically change as we type along. But when a requirement document is shared, it could be interesting to have these human-friendly references set in stone. An easy way to do this would be transforming the attribute value into a literal, meaning it does not contain any elements for templating, it just gets rendered as is.
What do you think? I'm not completely set on this whole thing yet, I'm still discovering the innards of ProR, and it's a steep learning curve when you don't know EMF. It would be great if you could be provide some insight into the following:
- You talked about the possibility for a SpecObject to be referenced in several places, which is why ids should not be stored. I'm not clear on what reference feature you talk about, could you be more specific?
- Attribute default values don't appear in the GUI, despite being present in the ecore model and xsd. Setting default values in the SpecType would make it easier to specify a default template per SpecType, e.g. the UseCase spectype would have a default template value of "<parent-ref>-UC<sibling-same-type-count>". What would it take to make them editable?
Thanks,
François
|
|
| |
| Re: Improving upon the id presentation [message #1066090 is a reply to message #1065976] |
Sun, 30 June 2013 10:10 |
|
Hi François,
Quote:I'm now thinking about a more generic presentation that would treat an attribute value as a template to be fed into a templating engine for rendering.
That's a good idea. Again, you might want to look at the ID configuration, which already allows the prefix to be configured.
Quote:About storing ids or not: when collecting requirements and nothing is shared or published, we do not need to have fixed references, these can dynamically change as we type along. But when a requirement document is shared, it could be interesting to have these human-friendly references set in stone.
In requirements engineering, this is considered bad practice. Either you fix them from the beginning ("real" human-readable IDs), or not at all (Outline Numbering). Mixing the two will just create trouble (what if you accidentally forget to freeze the IDs and still share them?).
Quote:- You talked about the possibility for a SpecObject to be referenced in several places, which is why ids should not be stored. I'm not clear on what reference feature you talk about, could you be more specific?
If you look at the outline, you will find your requirements in the folder "Specifications" and in the folder "SpecObjects". Actual requirements are SpecObjects. To create a view on the data, you create Specifications, which consist of a tree structure of SpecHierarchies. Each SpecHierarchy references a SpecObject. Thus, you can have two SpecHierarchies referencing the same SpecObject. If you change the SpecObject, it looks like two elements in the Specification have changed.
The ProR GUI masks this, as users typically have a document-centric work style. Look at the "All Attributes" tab of the Properties View to see what is going on behind the scenes. For instance, there you can select the referenced SpecObject from a drop-down.
Hope this helps!
- Michael
|
|
|
| Re: Improving upon the id presentation [message #1066092 is a reply to message #1065977] |
Sun, 30 June 2013 10:14 |
|
Hi François,
Quote:BTW, I'm doing this on my free time, but as a freelance I would really enjoy some open source tools for requirements engineering.
Glad to hear that - this is what keeps open source alive.
Quote:If anything comes out of this, it certainly will be contributed. Besides this numbering scheme, the other nice thing I miss is a nice printout/report... Anything in the pipeline for this?
Right now, you can use "print" to create a HTML-Version of a Specification. Beyond that, we have a student at the university of Düsseldorf, who is working on reporting in the context of his Master's Thesis. Please contact him directly at said.salem at web.de - he is looking for stakeholders who can help him in validating his ideas.
Best,
- Michael
|
|
| |
| Storing the next available value [message #1067303 is a reply to message #1066930] |
Mon, 08 July 2013 09:16 |
|
Hi François,
Quote: the problem of storing the next available value for the counter remains. To that end I mentioned using the default value in SpecType, not only to store the template, but also to store other information in comments, such as the counter, since comments are ignored by the template engine and not even printed out.
What do you think of this idea?
This problem has been solved - please check out the ID Presentation. A presentation extends the ReqIF model (in the Tool Extensions), which allows the storage of arbitrary information. Check out
org.eclipse.rmf.reqif10.pror.presentation.id/model/ID.ecore
The IdConfiguration element has the attributes prefix and count, which hold exactly that kind of information.
Best,
- Michael
|
|
|
| Re: Improving upon the id presentation [message #1067307 is a reply to message #1066930] |
Mon, 08 July 2013 09:21 |
|
Hi François,
Quote:What would it take to make default attribute values editable? I tried to make them editable in the genmodel but there's more to it than that.
Editing the genmodel is certainly the first step, and should be sufficient (did you regenerate the code?). However, there is a reason that certain standard attributes are not editable (lastChange, for instance). The desc attribute, on the other hand, is already editable.
Irrespective of that, according to my previous reply, I don't think this is a good place for storing data for the problem at hand.
Hope this helps,
- Michael
|
|
|
| Re: Improving upon the id presentation [message #1067321 is a reply to message #1067307] |
Mon, 08 July 2013 09:57 |
François Rey
Messages: 17
Registered: October 2012 |
Junior Member |
|
|
Michael Jastram wrote on Mon, 08 July 2013 05:21
Editing the genmodel is certainly the first step, and should be sufficient (did you regenerate the code?). However, there is a reason that certain standard attributes are not editable (lastChange, for instance). The desc attribute, on the other hand, is already editable.
Hi Michael,
Yes I did regenerate, and the field appears to be editable in the GUI, one can enter text, but somehow the value is not retained, the field goes blank, and it looks like there's a drop-down behavior that interferes. My guess is there's more level of indirection before getting to a plain string field, so there's probably some configuration for these intermediate levels. I'm sure there's not much to do, I started to dig into EMF edit, so we're probably talking about some item providers and adapters, but it's not very obvious to me who never touched EMF before, so if you have any quick pointers, that would help a lot! 
|
|
|
| Re: Improving upon the id presentation [message #1068101 is a reply to message #1067321] |
Fri, 12 July 2013 07:49 |
|
Hi François,
Quote:so if you have any quick pointers, that would help a lot! Wink
Well, if I understand you correctly, you are referring to EMF attributes (e.g. lastChange, longName). On these, the genModel-Settings should be effective. A good starting point would be to analyze existing ones and play with them. The two I mentioned are good starting points, as lastChange is readOnly, longName is not.
With ReqIF-Attributes it is a different story, as Presentations have the ability to override the default behavior. For instance, the IdPresentation makes the ID attribute read-only, as it should not change, once assigned. This is realized in the Presentation itself.
Hope this helps!
- Michael
[Updated on: Fri, 12 July 2013 07:49] Report message to a moderator |
|
|
| Re: Improving upon the id presentation [message #1069688 is a reply to message #1068101] |
Tue, 16 July 2013 11:56 |
François Rey
Messages: 17
Registered: October 2012 |
Junior Member |
|
|
After a couple days of searching and reading about EMF I managed to find some interesting example in the EMF book, which I applied to our situation. I now have the attribute value editable without going through a child object. Actually, there's a way in the GUI to set a default value: right-click and create a child using the tree in the datatype configuration dialog, and then set the value in the property of the new child object. But this is really cumbersome, and the link back to the attribute definition should be set automatically and remain hidden.
Pretty soon I'll have some intermediate change/pull requests to submit and I was wondering what would be the best way for me to share the code. When contributing to egit I got used to gerrit, but you seem to be using an instance private to Dusseldorf university, is that right? What would you suggest? For example one change would be about editable default values as mentioned above. Another would be an augmented ReqIF10Util, including a reflective implementation of createAttributeValue(). They can be submitted together but it's nice to review them separately.
[Updated on: Tue, 16 July 2013 15:10] Report message to a moderator |
|
| | |
| Re: Improving upon the id presentation [message #1070523 is a reply to message #1069690] |
Thu, 18 July 2013 06:33 |
|
Hi François,
Quote:BTW, knowing e4 application model is based on EMF, the framework deserves proper respects. I do find EMF powerful, but also find it quite obtuse, often lacking a clear documentation, so you really have to dig deep to get going. Also when seeing such javadoc comment one wonders if even EMF authors know what they're doing, or if code is properly reviewed...
EMF has a steep learning curve, no doubt. I found the EMF Book (Ed Merks et.al.) extremely helpful - much more so than the JavaDoc. It's worth investing in (if you don't have it already).
Also, for EMF-specific questions, use the EMF-Forum. Ed usually answers in less than 24 hours.
- Michael
|
|
|
| Re: Improving upon the id presentation [message #1070526 is a reply to message #1070408] |
Thu, 18 July 2013 06:36 |
|
Hi François,
Quote:My confusion came from the contribution guide that mentioned some specific instructions for students of the Dusseldorf university.
Glad you figured it out, I'll check out the Gerrit this weekend probably.
We want to make sure that the Students use git properly (e.g. working with three repositories, etc.). If you have the time, feel free to edit that Wiki page to help non-University contributors to find the proper documentation.
Best,
- Michael
|
|
| | | |
| Re: Improving upon the id presentation [message #1076636 is a reply to message #1076320] |
Wed, 31 July 2013 17:18 |
François Rey
Messages: 17
Registered: October 2012 |
Junior Member |
|
|
I was wondering how to move forward with the need to associate the template presentation to a datatype and a spectype, so that it's possible to have a counter per spectype+datatype tuple. Right now it's only possible to associate a presentation to a datatype. Bug #387019 is closely related as it talks about removing the dataype attribute from the base presentation definition and let presentation providers specify their own criteria.
Also, I noticed it's possible to define more than one presentation for a single datatype, but only one gets applied. This logic is coded in org.eclipse.rmf.reqif10.pror.util.ConfigurationUtil.getPresentationConfiguration(DatatypeDefinition), whereby the first presentation matching the datatype is returned, ignoring others. One would think it would be a good idea to have multiple presentation for one cell/datatype, e.g. linewrapping and headline presentations. But then how to compose presentations together into a coherent cell renderer? This may not be as trivial, as not all presentation can compose well together, e.g. the existing id presentatino and proposed one based on templating. So this composition idea does not sound so good.
In fact, this hints to a larger problem: the presentation concept at it stands is used for two things that are typically handled separately: providing content and formatting the content. In other words, presentation are currently used as content provider (e.g. id) and renderer (e.g. headline and linewrap).
Regarding the rendering I don't think the idea of using composition of extensions is a good choice. Ultimately we should aim for a formatting language such as CSS and cell renderer that understand it. Eclipse e4 may be of inspiration here as it has SWT widgets that can be style with CSS.
In terms of providing content, which includes id generation, composition may not be so appropriate either and a good templating engine is probably sufficient for most cases.
So what I'm trying to say here is that eventually the presentation extension should be split into two separate concepts, for example contentprovider and cellrenderer. The way to associate them with actual attribute values could be common, maybe something similar to css selectors. Eclipse e4 CSS styling and selectors should provide a good source of inspiration, see this tutorial.
I filed bug #414160 where such discussion should continue.
Going back to generating ids based on templating, I can still make a presentation and ignore these other issues for now. But instead of removing the datatype as suggested in bug #387019, I'll have to add the spectype! This is because the logic to associate a presentation to a cell is outside the scope of the extension plugin in org.eclipse.rmf.reqif10.pror.util.ConfigurationUtil.getPresentationConfiguration(AttributeValue), and I don't want to redesign all this until what I talked about earlier is better understood.
|
|
|
| Re: Improving upon the id presentation [message #1076729 is a reply to message #1076636] |
Wed, 31 July 2013 19:48 |
|
Hi François,
Thank you for your suggestion. As you can imagine, some of your concerns already came up in internal discussions, and there is definitely room for improvement. When the initial Presentation extension point was built, it was mainly driven by the requirements of the ongoing research projects.
Rather than evolving the presentation mechanism, however, I would suggest to create one (or two) new extension point(s) and to build them up from scratch, while leaving the old one alone. This has the advantage of respecting the already existing legacy base, and being able to try both mechanisms in parallel. What do you think? I'd definitely support such an effort.
Not sure whether it makes sense to go this far, but there are also some shortcomings of the grid component we use, AgileGrid. You suggested the e4 SWT widgets. I am not sure whether we can use them: The main reason we went with AgileGrid was the fact that on Windows, all rows of a JFace Table have the same height. Not sure how much impact this fact has on your ideas. In general, it would be nice to use web technologies for rendering, as that would give us a lot of flexibility. I even once built a GWT-based editor for ProR (prototype), but there were a lot of problems.
> I filed bug #414160 where such discussion should continue.
I am not sure whether a bug is the right place, as the audience is very small (unless all developers subscribe to it). I would suggest rmf-dev@eclipse.org for this discussion, as that is where the developers communicate. 
Thanks,
- Michael
|
|
|
| Re: Improving upon the id presentation [message #1076784 is a reply to message #1076729] |
Wed, 31 July 2013 21:27 |
François Rey
Messages: 17
Registered: October 2012 |
Junior Member |
|
|
Hi Michael,
Michael Jastram wrote on Wed, 31 July 2013 15:48Rather than evolving the presentation mechanism, however, I would suggest to create one (or two) new extension point(s) and to build them up from scratch, while leaving the old one alone. This has the advantage of respecting the already existing legacy base, and being able to try both mechanisms in parallel. What do you think? I'd definitely support such an effort.
It certainly makes sense, especially if the presentation abstraction becomes more like a content provider/editor, and rendering and styling becomes the responsibility of a new feature/extension. Linewrap and Headline presentations would have to migrate to the new feature/extension.
Quote:Not sure whether it makes sense to go this far, but there are also some shortcomings of the grid component we use, AgileGrid. You suggested the e4 SWT widgets. I am not sure whether we can use them: The main reason we went with AgileGrid was the fact that on Windows, all rows of a JFace Table have the same height. Not sure how much impact this fact has on your ideas. In general, it would be nice to use web technologies for rendering, as that would give us a lot of flexibility. I even once built a GWT-based editor for ProR (prototype), but there were a lot of problems.
I don't suggest to use e4 SWT widgets, but to look at the way they do styling and see if it can be a source of inspiration. JavaFX is also using styling. I think ProR can certainly benefit from these implementations at least in terms of not reinventing the wheel. Migrating to a rendering technology that support styling and selectors should be considered. Hyperlinking could be interesting as well. I don't think there are many choices: e4, HTML5, JavaFX. Note that e4 could in theory support different renderer, but it isn't as straightforward as it seems, see this blog post.
Quote:> I filed bug #414160 where such discussion should continue.
I am not sure whether a bug is the right place, as the audience is very small (unless all developers subscribe to it). I would suggest rmf-dev@eclipse.org for this discussion, as that is where the developers communicate.
Funny you say that. The dev mailing list is where I wanted to go first, but then I though this is something that needs to be tracked as well, like a design enhancement. Feel free to close the bug if you prefer the dev list. As I said, I almost did that.
|
|
| | |
Goto Forum:
Current Time: Sat Dec 21 15:56:01 GMT 2024
Powered by FUDForum. Page generated in 0.05859 seconds |
] 
Search
Help
Register
Login
Home
