Author Topic: Use Cases coverage from System Processes (Read 24368 times)

viarellano · « **on:** March 13, 2009, 07:11:03 pm »

Hi all.

Need you support on best practices.

I'm describing my system by grouping several types of elements such User interface, Logical Data Model, System Services (through BPMN notation) and so. Each group of elements compose a System Process like the part of the system that is used to implements specific business logic (like Create Account which includes two web pages, one service and 3 high level entities).
What i need to do is to specifie:

The Use Cases (previously created in EA) covered by each element of a System Process. Also i have to specified which changes i have to do in this element cause new Use Cases and the cost (difficult) of it.

(I'm thinking to use "require" of each element to adding use cases)
[/list]

Which elements belongs to each System Process

Which use cases covers the System Process ( although if i have both of the above i could have this, i'm thinking in a more direct way to do this).

Maybe y would have to create stereotypes for my "types" of elements, adding also new stereotypes properties both for Use Case(s) and System Process.

Thanks in advance

Vi

Geert Bellekens · « **Reply #1 on:** March 13, 2009, 11:11:04 pm »

I believe the collaboration is the type of object you are looking for.
From UML superstructure 2.1.2

Quote

A collaboration describes a structure of collaborating elements (roles), each performing a specialized function, which
collectively accomplish some desired functionality. Its primary purpose is to explain how a system works and, therefore,
it typically only incorporates those aspects of reality that are deemed relevant to the explanation.

The usecase would then be the desired functionality, and the GUI's, classes and services all work together (collaborate) to achieve the functionality described by the usecase.

viarellano · « **Reply #2 on:** March 14, 2009, 03:42:05 am »

Hi.

Yes, that was my first option but was rejected by the client. I will do this but dragging class from different stereotypes into the same diagram and stablishing thge connections between them.

I need to make the traceability between them and system process and use cases in other way.

Thanks

Geert Bellekens · « **Reply #3 on:** March 14, 2009, 04:20:23 am »

In that case I would just make <<trace>> dependencies between usecase and the elements that realise its functionality.
You could do that in a diagram or use a traceability matrix.

viarellano · « **Reply #4 on:** March 14, 2009, 04:29:10 am »

And if a do that, which the most elegant option for me. how cuold i make a search for all the use cases that are covered by the group of elements represented?

Think that i would trace one use case to the user interface element within my system process and others use cases to system service element within the same system process that is represented.

Oliver F. · « **Reply #5 on:** March 16, 2009, 10:17:06 pm »

Quote

And if a do that, which the most elegant option for me. how cuold i make a search for all the use cases that are covered by the group of elements represented?

The relationship matrix should be of help for you. You can select elements for rows and columns and then define the type of relationship between those to filter for.

Oliver

bioform · « **Reply #6 on:** March 17, 2009, 02:58:45 am »

Quote

In that case I would just make <<trace>> dependencies between usecase and the elements that realise its functionality.
You could do that in a diagram or use a traceability matrix.

Why not use the "realize" type instead? That is what I have been doing... Would this not be the correct association?

Thanks,
David

Oliver F. · « **Reply #7 on:** March 17, 2009, 04:25:37 am »

Quote

Why not use the "realize" type instead? That is what I have been doing... Would this not be the correct association?

Thanks David for mentioning this- I had this on my mind when I read this thread first but it was soon hiddenbehind some other thoughts.

The advantage of using the "realize" type is that it can directly be used in the relationship matrix while all stereotyped derivates of "dependency" can not be distintinguished.

Oliver

bioform · « **Reply #8 on:** March 17, 2009, 05:01:12 am »

LOL it's funny because now that you said that about the stereotyped "dependency" issue with the RTM, that IS the reason I went with "Realize!"

Thanks for helping me to remember what I had forgotten!

And I believe that the request to support RTM steretypes has been mentioned and requested previously too.

Geert Bellekens · « **Reply #9 on:** March 17, 2009, 05:27:58 pm »

Yes you are right. A realization would be a valid relationship to express what you need.
From the UML 2.1.2 superstructure:

Quote

Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification
(the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model
stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

But I usually prefer to keep the realization only for the relation between an interface and its implementing class. But that is my personal preference off course.
Furthermore, if the relationship matrix cannot distinguish between the different types (stereotypes) of dependencies then indeed, that should be changed.

viarellano · « **Reply #10 on:** March 19, 2009, 11:01:41 pm »

Hi all.

What about using business use-case realization to represents System Process?.

It will represents my System Process, it will "realize" some Use Cases and elements in my system process also "realize" my Business Use-Case Realization.

Any comments?

Vi.

Geert Bellekens · « **Reply #11 on:** March 20, 2009, 01:16:31 am »

Sure that could be helpfull, but be aware that a business use-case realization is not UML.
Depends on whether you want to do free-style modelling or UML.

bioform · « **Reply #12 on:** March 20, 2009, 01:47:27 am »

Well if you are creating a stereotype of a use case, I would believe that it would be UML compliant would it not?

I am doing something similar with BPM to BusUC to SysUC, then on down the ladder. Of course you do have to realize that the business use cases may cross multiple system boundaries i.e., the realizations could be sysUC in other than the (system under development SUD)

I usually do not detail my BusUC to any great extent, but rather use them as a source of needs and possible work context for the SysUCs that realize the BusUC?

BusUC: Manage Helpdesk Agents

Adjusting Agent Schedules and Availability
Add/Remove, and Retire Agents
Review Agent Productivity
Review Helpdesk Workload
Manage Agent Training

David

viarellano · « **Reply #13 on:** March 20, 2009, 03:11:03 am »

this is the <<business use-case realization>> stereotype for Collaboration class under Busines Modeling toolbox, i think this is UML compliant, isn't it?

Vi

bioform · « **Reply #14 on:** March 20, 2009, 03:32:46 am »

Yes it is...
I just ordered a book that might be very helpful:
Workflow Modeling: Tools for Process Improvement and Application Development, 2nd Edition.

Daviid

Sparx Systems Forum

News: