Nizam,
 
A 'realise' relationship should always map a higher level / more abstract concept onto a lower level / more detailed concept.
 
A Use Case is an abstract description of one piece of functionality. In UML it is best realised by sequence diagrams (collaboration diagrams) and abstract classes (and maybe statecharts).
 
Just to be sure we're on the same page, in your Use Case view (which is the requriements specification) you will have one or more Use Case diagrams. On each Use Case diagrams you will have one or more Use Case objects (represented as a single oval with a title). Each Use Case object names (and describes in supplementary documentation) one specific task / function. Each Use Case object should be mapped (through realisation) to a more detailed specifications in the Analysis Model (in the Logical View). (One point, if you don't / can't map a Use Case then it shouldn't be there in the first place.)
 
(Aside: One of the most common mistakes made with Use Case diagrams is to think of them as flow charts of some sort. Often people produce Use Case diagrams which they read as 'the user does this and then this and then ... etc.
A Use Case Diagram should say nothing about the sequence of things. Each Use Case on a diagram should represent a complete, self-contained piece of functionality. Thus, for example, in a system in which a requirement is that the user logs in before doing anything else one should have a Use Case for logging in which is unrelated to the Use Cases for other functionality - the fact that logging in occurs first should be described in supplementary specifications.)
 
To proceed to the Analysis, what we usually do is create Use Case realisations (in Rose, a use case object with the <<use-case realisation>> stereotype). A realisation is related to a Use Case (in the Use Case view) with the 'realises' relationship. Then within this Use Case realisation we produce sequence diagrams which specify the steps involved in realising the function / task. Essentially, the sequence diagrams are a formal description of the basic flow of the Use Case, and any alternative flows. To produce the sequence diagrams we need to think about objects that are needed, so we define classes (abstract) during this process. What we end up with is a set of sequence diagrams and classes that describe (at a high level) what each Use Case should do. (Note, it is in the sequence diagrams that we start to bring in the specifcations about the 'flow'. Also, we may use statecharts to represent requirements like 'the user logs in before doing anything else'.)
 
Anyway, the important point is that the process of going from requirements specifications (Use Case view) to an implementation (usu. Component view) is a process of refining, through realisation, higer level concepts (artifacts) with lower level concepts (artifacts).
 
Stephen.
-----Original Message-----
From: Nizam [mailto:[EMAIL PROTECTED]]
Sent: 05 October 2001 06:19
To: [EMAIL PROTECTED]
Subject: (ROSE) realizing the use cases

Hi..
I need guidence to realize my use case.
    I have identified use case  in my use case view.
I am using VB as frame work for my model.
I want to realize my uc in logical view.
 
1>Should I copy my uc from use case view to logicaI view ?
2>should I create once more uc in logical view then draw a realize relation between them?
 
Thanks In Advance
Nizam

Reply via email to