Book a Demo

Author Topic: Requirements Hierachy  (Read 4042 times)

rilancaster

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Requirements Hierachy
« on: December 17, 2007, 01:28:46 pm »
I have a series of requirements that I've arranged into a Hierachy - they are nestedClassifier'd in the XMI.

I also have several Requirements diagrams that show this Hierachy using aggregate/composite associations... Basically reproducing the same info.

I'm using my own transforms over the XMI and the nested form is easy to use, but find the Diagrams useful for showing to people.

Would it be possible to have a Diagram property, that allows a diagram display a given hierachy of objects without actually specifying the associations.

i.e Yes/No Display all Hierachy as <Aggregate/Composite>...

and where associations between objects are actually specified - override the default and display the actual relationship..


Can't take too long ;->

Rob Lancaster

Dynamic Controls


Oh Yes  and when the hierachy is modified: Redraw the diagram. ;->





« Last Edit: December 17, 2007, 01:30:09 pm by rilancaster »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Requirements Hierarchy
« Reply #1 on: December 17, 2007, 01:51:53 pm »
Quote
Can't take too long ;->
Won any good lotteries lately Rob?

Some of us have been waiting over three years for simple stuff orders of magnitude less complex than what you ask for...

Still, since your name isn't Paolo, you may be lucky...

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Requirements Hierachy
« Reply #2 on: December 18, 2007, 06:13:38 am »
Hi Rob,

Actually, this sounds like a good idea. At first I thought it might involve a breaking change in diagrams, but I'm beginning to think it would be gentle instead.

How and where the option should best be specified would require some thought. I'd hate to have to deal with this on all diagrams, of all types.

Perhaps this could be integrated with a more robust implementation of aggregation. Since EA began to support UML 2.x it has been possible to create - in the same model, or even on the same diagram - aggregations with both UML 2.x and UML 1.x semantics; there's no way to differentiate the two, and there's no graceful way to clean this up.

Paolo's right, but also taking a narrow view - certainly justified considering some of the things we've been awaiting for so long. However, Sparx is often quite responsive, so perhaps this request will hit the jackpot.

I suggest you make a feature request. First, think out exactly what you want to accomplish. This will help Sparx characterize and contain the request; if they don't do that there's little hope they can address it.

Search my recent posts for a best practice we use for feature requests and bug reports, to keep everyone in the loop.

David
No, you can't have it!