Author Topic: Relationship Matrix - Basic Issues (Read 21157 times)

Paolo F Cantoni · « **on:** October 12, 2009, 11:01:22 pm »

While the relationship matrix is an excellent concept (and one that drew me to EA nearly six years ago), it hasn't really changed much and STILL contains most of the basic issues it had six years ago... I think it's time Sparx had another look and upgrades it for the 21st century...

There is NO provision for multiple relationship types in the same matrix. This significantly decreases the utility of the matrix and you have to "know what you are looking for" a priori.
Similarly, there is no provision for multiple element types. Though, I suspect this is less important - but if you're going to allow the above, you might as well all this.
There is NO indication if there are multiple relationships in the nominated direction. (This needs to include each direction if "both" directions is selected). In particular, if there ARE multiple relationships, selecting edit relationship only selects one of them (instead of displaying the collection and allowing the user to select them).
There is no provision for filtering by stereotype - either for vertexes or arc. Filtering by many factors is needed - but since you can only create new "types" of elements and relationships by stereotyping existing ones, this is most important.

Before I submit a formal bug report, I thought I'd garner input from the forum.

TIA,
Paolo

Graham_Moir · « **Reply #1 on:** October 13, 2009, 12:30:54 am »

I agree

Luis J. Lobo · « **Reply #2 on:** October 15, 2009, 07:05:43 pm »

Vote!

Traceability matrices are one of the most important features in this kind of tools.

I think it needs to be enhaced at least in:

Rename a saved profile (buff!! now I need to "Save as new profile" and then delete the old one!)
Group matrix profiles: like "linked document templates" way
Filter by stereotype (elements & relations)
...

Oliver F. · « **Reply #3 on:** October 15, 2009, 07:28:44 pm »

Quote

There is no provision for filtering by stereotype - either for vertexes or arc. Filtering by many factors is needed - but since you can only create new "types" of elements and relationships by stereotyping existing ones, this is most important.

That one definitely has my vote.

Oliver

NeilS · « **Reply #4 on:** October 19, 2009, 09:49:14 pm »

My biggest frustration with the RM is that you cannot specify a package (and its sub-packages). When I found out about this limitation it became as much use as the proverbial chocolate tea pot!

Please add this to the list!

Paolo F Cantoni · « **Reply #5 on:** October 26, 2009, 11:57:46 pm »

Quote

My biggest frustration with the RM is that you cannot specify a package (and its sub-packages). [size=18]...[/size]

Hi Neil,

Can you clarify what you mean by this? If I select a high-level package and then select an element type the Matrix will provide a list of those element types at levels (packages) below the specified package.

I'm about to submit the feature request, so I'd like to make sure what I'm asking for.

HTH,
Paolo

Graham_Moir · « **Reply #6 on:** October 27, 2009, 12:14:43 am »

Paolo - I can confirm I see the same behaviour as you on both axes of the matrix.

G.

NeilS · « **Reply #7 on:** October 29, 2009, 10:56:56 pm »

Hi Paolo

Sorry for the delay, forgot to check the notfiy of replies option.

Last time I tried the RM I followed the instructions from the Doug Rosenberg book - p388. The RM generated was for all packages in the database - so I got far too much back, I could not specify a particular package and its sub-packages.

I last tried this on EA6.5 and gave up in disgust. I'll try and find the relevant packages and repeat using 7.5.849 if you think this has been changed.

Neil

Paolo F Cantoni · « **Reply #8 on:** October 30, 2009, 12:27:06 pm »

Hi Neil,

6.5 WAS a LONG time ago, in Sparxtime. Be wary of using any instructions for that long ago literally.

As you saw above, both Graham Moir and I think we've achieved what you were after. It was quite straight forward.

Cheerz,
Paolo

Newbe2 · « **Reply #9 on:** October 31, 2009, 03:23:56 am »

Another improvements to do in the matrix are:

1. To hide empty relations: if you havea big modelo i.e. 400 entities vs. 200 activities, you only want to see the croosses and/or have the option to hide/show the empty relations.

2. Choose custom icons instead arrows.

3. Include the matrix in the HTML report.

asking so much?

son-of-sargasso · « **Reply #10 on:** October 31, 2009, 08:24:57 am »

Quote

1. To hide empty relations: if you havea big modelo i.e. 400 entities vs. 200 activities, you only want to see the croosses and/or have the option to hide/show the empty relations.

+1 from me.
BUT! Action to hide empty columns, Action to hide empty rows, action to hide hide both. n.b. an action not an option.

bruce

Graham_Moir · « **Reply #11 on:** November 02, 2009, 11:40:54 pm »

I agree this should be an action, otherwise I can see the effect of an incorreclty set option - a false sense of security that everything is covered when in fact it isn't because of those "hidden" items.

Paolo F Cantoni · « **Reply #12 on:** November 03, 2009, 09:21:50 am »

Quote

I agree this should be an action, otherwise I can see the effect of an incorrectly set option - a false sense of security that everything is covered when in fact it isn't because of those "hidden" items.

Hi Graham,

Your point about the false sense of security is well taken; and, of course, I had considered it. However, it seems to me that if Sparx took the radical view of telling the user what they really need:

a (fairly) prominent indicator to say:

"Warning! Warning! Will Robinson... There are hidden cells on this matrix",

you could leave the option on/off or toggle...

Paolo

Graham_Moir · « **Reply #13 on:** November 03, 2009, 08:47:52 pm »

Yes agreed, that would work Paolo.

cty · « **Reply #14 on:** November 05, 2009, 01:16:26 am »

Hi,
I fully agree to most of the requested features you mentionned.
In my company we ask users to follow a simple methodology that force them to provide a minimum of traceability informations. Then, when I show them this relationship matrix (associated with the hierarchy view), they are really convinced of :

how it is useful to fill these traceability informations (requirements coverages, traceability from use-cases to functional or software components that implement them, ...)
how using EA and its relationship matrix can simplify their job, and make it more reliable

This relationship matrix is one of the features that is the most "sellable" (is this good english ?

) beside users and directors.

Concerning the capability to filter by links' stereotypes, it can be done by defining your own MDG technology. This implies you specify in a "Profile" diagram your own elements and links that inherits from the UML metamodel.
Then you build your MDG technology, configure your EA client with it, and your own stereotypes (link stereotype as well as elements stereotypes) are available in the "Type" or "Link Type" combos.

Easy, isn't it ??

Anyway, this does not work completly well. For example, it work fine for links that specialize associations, but not with links that specializes UseCaseLinks... will send a bug request very soon on that subject.

So.... I fully support your evolution request concerning this relationship matrix.

Some new features I would suggest :
- allow to specify some options for CSV export (in france, we use ";" as a delimiter, not ",")
- more friendly management of profile
- allow to integrate these profiles in MDG technology (er... isn't it alredy the case ? I did not have the time to check on latest releases)

Byyyyyyyye

Sparx Systems Forum

News: