traceablity troubles

[birdy]

Hi

I've got some serious problems with making the project in UML. The problem is that I (almost) understand the

notation and how to draw the concrete diagram, but I dont have an idea how to lacate the diagrams in packages and

assign links between them.

My goal is to build a fully traceable model. So that all the elements in the project where logically connected and I

(or any other man) could trace unambigiously from the top layer (use cases) to the bottom.

Well im a rookie in UML and modeling generally. Ive raed a lot of books on UML. But all they describe how create a

single diagram not telling a word about a set of them and their interconnections.

For example EA has a bunch of views (use case, logical, dymanic, ...). How should i use it? Ive looked through some

example projects for EA (for Rational too) and i was wondering why some activity diagrams where located in use case

view and some in dynamics view?

One more thing. Some realizations (diagrams or collaborations) of use cases are not connected with them - they just

may have the same name. Why? How could that be? If the project is pretty big you may never find it in the heap of

elements?

SO)) The main question is the following: HOW CAN I MAKE MY PROJECT TRACEABLE? and how to lacate the elements in

packages so that it would be INTUITIVELY clear what is what?


Maybe its a stupid question)) and there is no a recipe how to do it but the practice. But maybe there is some good

advices or ruses or even a simple rule how you do it.

I appreciate any advices/

Thanks a lot.

[GTM]

Traceablility is achieved by using Dependencies between elements. You can stereotype them, example:
Realization --<<satisfies>> --> Requirement
Additionally, you might want to look into the SysML profile.

The different views reflect stages of your process. So what is your process? RUP? Make that clear first, then it will become obvious which views to connect with each other. Remember you can use the same diagram/element in different stages of the process.

[thomaskilian]

Traceability is hard to achieve. Once in a while you will notice that all these dependencies become useless when there are too much of them. I'd try to find a meaningful package relation that helps in understanding the model transformation from Domain to Deployment. It's really difficult to put it in some short sentences

Recently I started to work with model transformation more intensively. At this point I do not have enough experience, but so far it looks promising. If you have a framework (you need to be a wizard to pull it out of your hat) it helps really a lot. Just a few clicks create a useable model from a domain sketch. But it is fixed to the framework. As soon as someone else needs a different one, you are lost and have to do it either manually or to work on your transformation. Not a PITA put clumsy with nearly no debugging; RPG as I say (the German acronym translation for this old language is Rate, Probiere, Gucke - Try, Guess, Look). But once you have it running, traceability is built-in.

[birdy]

Thanks for your advices.
So I'm really getting the idea to use packages. I think its quite useful.

Since i'me a novice it was just a shock for me when i've discovered ICONIX process. I think they DID IT RiGHT. I've been thinking over it for the last week i like it.

So thank you for the idea that the arrangement of the project depends on the process you use.

birdy

[thomaskilian]

ICONIX is a very good start. It helped me to find my way into usefulUML practice.