Responsibilities on Associations

[Sean Kearon]

It would be nice to be able to attach responsibilities to associations (maybe attributes and methods also).  This would allow the mapping of requirements fullfilled by the association/attribute/method.

[Javier]

SeanKaron,

What is your need?  I do not see the value of methods for an association, and what additional attributes would you be looking for?

UML (and EA) allows you to qualify the association today (multiplicity, roles, name, etc.), but obviously you have a need in your specific project.  Could you provide additional detail?

Regards,

Javier

[Sean Kearon]

Hi Javier

I am not after methods or attributes on associations, but responsibilities as in the responsibility tab on class properties in EA.  This allows me to track the requirements that are fulfilled by the class.  I just want to be able to do the same associations.

Sean

[JonathanBB]

I would also like to do something like this - to add tags, or additional text items, or even links to other elements (such as Requirements) to interactions/messages in a Sequence Diagram.

I was thinking of modelling a Test Scenario where the steps of the test are interactions in the Sequence Diagram and would like to hold the "instructions to testers" for each step in the Notes field. Then I would like to hold the expected outcome of the step in a (new) separate field. For completeness, I might also want to add traceability links back to the original User Requirements.

This would allow me to generate test script documents from the model that could be used directly by the testing team.

If I had a "Files" tab on the Messge Properties specification aswell then I might be able to think about automating the tests (independently of EA, from the generated documentation) by placing the stimulus and response for each test step in the associated file.

sounds mad .... but it could just work!

Jonathan

[Sean Kearon]

Jonathon

I think that is a really good idea - we would be pretty likely to do something similar too.  

Sean

[Javier]

SeanKearon, jbeebe,

I see the value to attach responsibilities to the class, but not to the associations.  In my opinion, the association ***already represents a responsibility for the class***, and defining the association correctly will define the responsibility correctly.  My question is, what would you define in the association that is not already there? multiplicity? role? constraints? ordered?  On the other hand, I think that the association can be tracked to a requirement--a Customer shall have a maximum of 5 accounts.  In this case, I agree that it is valuable to have this information, but doesn't the current association properties dialog box cover most of this already?  It seems to me that it is overkill to "track" the requirement by having to maintain the dialog box than by inspecting the class diagram.

On the other hand, in my experience, sequence diagrams are used to support use case realizations---they're merely a way to see a "collaboration" in action.  Granted, you can use them to track requirements, and a particular requirement can be realized by a collaboration represented in a sequence diagram, but again, I think it is overkill to maintain this information in the model.  What I usually do is that I associate a sequence diagram with a use case realization by creating it underneath it.  That way I maintain the relationship and know what it's realizing.  I also try to give the happy sequence diagram and a couple of failure scenarios to exemplify the most common paths.

My standpoint does not come from a "naysayer" perspective.  It's that I've always had to strike a balance between how much information I want in the model and how much time I have for a particular project.  In addition, let's not forget that whenever something changes, the model needs to be maintained, too.  Too soon it becomes prohibitive to have to maintain all this information in a medium to large project.

Regards,

Javier

[Sean Kearon]

Hi Javier

Documentation and similar artifacts are time consuming to create and maintain, but centralising them into the model makes this effort a little easier and also more consistent.  In my opinion, EA does an excellent job in this area, integrating areas such as change management, testing, defect management etc. into the model.  In this particular case, the placing of requirements management directly into the model is a great feature as it makes it a lot easier when reviewing requirements against design.  The other options are to do the requirements management in another place or not to do it (formally) at all - the former is less good, the latter is a recipe for disaster!

The way I have it set up in EA at the moment is that I have the requirements in a package, then when an area of the design satisfies on of these I show this by using a realisation between the requirement and the area that fulfills it.  When you generate your rtf documentation, you have all the information in there.  I would say that this saves work, not creates it.  

As for an association representing a responsibility for the class, this is true to an extent.  However, the responsibility tab takes us up to the level of (external) requirements, which are not directly visible from the class or association.

Regards

Sean

[Javier]

Sean,

I think I have to clarify my position.

What we have in our company is a software development process that creates the following (most important) artifacts:

- System Specification and Design.

The artifact is a document where we specify the use cases for the system.  Requirements that are not part of the use cases are specified in the document.  At the moment, we DO NOT track requirements--although we have the tool, RequisitePro, we just use it to store the use case documents and associate it with a Rose model's use cases.  Only one requirement is created in RequisitePro: the one created by Rose to associate a use case document with RequisitePro.  The use case document is beefed up.  We've polished it very well over the years and the participants know how to obtain information from there.

- Software Architecture Document

Out of the specification, we may come out with several of these.  Again, these include use case realizations from the specification.  The name is a little bit of a misnomer, because it reflects either the software architecture for the system or the detailed design of a specific component in the system.

When used as a software architecture, this component identifies the software architecture for the system, the main components and their interaction.

When used as detailed design of a component, this artifact includes the specific component to be delivered, the UML model and the specific technology and programming language to use.  We're very thorough with the technology and programming language aspects--a component has to be implemented somehow ;-).

Like several shops out there, our resources are limited.  We have a team of 4 people that may produce system design and specs, 3 that produce software architectures and a team of 10 developers.  I'm in all three groups, and some of the other people is in two groups.

Some of the problems (and relevant to this discussion) that we face as a team are:
- Time to market.  Missing a business opportunity because of a delayed product is BIG for the company, perhaps more significant than other companies (though competition).

- UML knowledge.  All of our teams know the necessary UML to fulfill their task.  It's been until this year that we're discussing raising the bar for our developers, because us modelers can express more in our designs with the experience and feedback that we've obtained in the last 5 years.

So, when you say to track something in the model, my position is that you have to strike a balance.  I agree that in an ideal world everything should be in the model, but is it really cost effective?  Updating the model takes time (I came back a few days ago from a design review and I haven't been able to catch up on the changes that have to be done), and, although MDA will address this very problem, it'll take years for the industry to buy into that approach--same as it was for UML.

You may be asking yourself, how do you then address the problem? orally:  let the developer talk to the modeler.  You'd be surprised that this approach works most of the time.  We modelers decide to eliminate some detail from the model, knowing that the developer will have some questions, but we address it with an office chat.  Ultimately, what we try to do is to get the best bang for the buck when it comes to time.

Of course, this is my soapbox ;-), but I'll step down now.

We're (still) a Rational tools shop and we integrate Rose and RequisitePro, using SoDA to generate the documents.  I'm evaluating EA because I see it as a superior UML tool, but it must be able to generate artifacts similar to what we have today with the same automatic features.

Regards,

Javier