Re: Use Cases and RM-ODP

[Konstantin Beznosov <beznosov@baptisthealth.net>]

Jinny Uppal wrote:
> 
> Well said. At the same time, it seems to me that Use Cases are essentially
> used to capture the requirements of the system, the "things" that you
> should be able to do with the system. In traditional OOAD you draw
> Use Cases in the analysis phase. Ofcourse when you have an object model
> you would want to verify the correctness of the model by checking if the
> use case is 'doable'. In other words, all the other models (for ex in the
> information and computational viewpoints of RMODP) you would verify the
> 'doability' of Usecases already drawn (in the enterprise model? I would
> think so. Which viewpoint are you in when you do analysis, which is really
> understanding the requirements of the business under question?).

Why do you think that system requirements are for enterprise view and
they are only business ones?
If you want to integrate a new system in your enterprise environment
you have to understand and mandate requirements for all viewpoints.
Here is a simple example: if you, as a customer, provide just business
requirements and forget to ask that the distributed system should use
TCP/IP stack (technology viewpoint) you will end up with a system that
may
completely satisfy your business requirements (enterprise viewpoint) and
yet to be very expensive to integrate in the the existing network
environment.


> 
> > Just a reminder: "Use-case diagrams provide a way of describing the external
> > view of the system and its interactions with the outside world." And further:
> > "You should use them any time you want to understand the requirements of your
> > system."
> Exactly. The external view. System requirements. Things that you would
> definitely capture in enterprise view. right?

As I discussed above, system requirements are not only at the enterprise
viewpoint.

> BTW, who are you quoting?

some online tutorial on UML.

> 
> > Use cases can be employed in any view where there is any sort of interaction.
> 
> i am not quite sure about that. if you need to capture interaction at
> computational/info views then you could use Object interaction/
> sequence/collaboration/state diagrams which are more accurate than use
> cases. use cases seem more like processes in the system.

Yes and no. I general, I do not see a valid reason to limit someone from
using use cases if they seem to be helpful.

> 
> > It's clear that in the enterprise view, you can employ use cases to illustrate
> > some aspects of workflow. When you work with the computational view, use cases
> > are also useful because they help to show how and in what sequence different
> > services and components interact via corresponding interfaces. You can play
> 
> maybe its a choice of words. I'd call those figures Object interaction/
> sequence diagrams. ofcourse these very interaction may serve to
> demonstrate a pariticular use case (ex: register a patient for an
> inpatient encounter. this is a use case and you should be able to show a
> series/sequence of interactions that 'do' the case)
> 
> > several scenarios here. In the engineering view, it is important to have use
> > cases in order to show how different transparencies are achieved.
> i dont know about that, since i dont fully understand that viewpoint.


What do others think on this subject?

Konstantin

To unsubscribe send a note to majordomo@cs.fiu.edu with the body of the message
being: unsubscribe cadse-orb