|
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.
|
- (ROSE) realizing the use cases Nizam
- Re: (ROSE) realizing the use cases rose_forum-owner
- (ROSE) Project Estimation for RUP SUBRATA SEN
- RE: (ROSE) realizing the use cases Kelly, Stephen
- RE: (ROSE) realizing the use cases BOWMAN, James
- RE: (ROSE) realizing the use cases Kim . Johnsson
- Re: (ROSE) realizing the use cases Vikram
- RE: (ROSE) realizing the use cases BOWMAN, James
