Well,
you are right, but I like to apply the distinction of "What" and "How" at
various level of abstraction, as the object orientation is suggesting, with
the main idea to add the details of the system incrementally. Here, I mean
as level of abstraction the following:
Use Cases
Subsystems
Components
Classes
Code
Furthermore, I like the idea that the "How" of a layer of abstraction is
the "What" of the layer belove it and so on from the top to the bottom. So,
I have:
Use Cases:
Here, we should describe the interactions between actors and the system
without any reference to the technology used, but specifying the kind of
information exchanged by the two. The scenarios are used to specify the
technology used by the system and the actors. Let's say that the scenarios
are used to specifying "how" the two entities communicates (I am focusing
on the external aspects of the system to be implemented).
Furthermore, I like the idea that the use cases diagrams are the "what" and
the use cases specifications (flow of events) are the "how" of a even
higher level of abstraction, but let not put to much stuff.
Subsystems:
Here, the scenarios become the what the system should do. While the
analysis classes (Boundaries, Entities, Controls) together with the
sequence diagrams become the "how" of this level of abstraction. Here the
comcept of subsystem is used to simplify this layer.
Components:
At this level, the subsystems become the "what" and their implementation
with components become the "how".
Classes:
Now, the components, the "what" at this level of abstraction, are
implemented with classes the "how".
Code:
Finally, the classes, or better their operations and attributes, represent
the "what" and the methods (the implementation with code of the operations)
the "how" of this level of abstractions.
Of course, everything must be defined incremently respecting a defined
architecture and using the use cases as the "Index" of such "book", the
system to be implemented. Each level of abstraction must be linked with the
level above it. In such way, in each level you add details, but not too
much, in order to maintaing a control on the development of the system. I
like to thing at this process as a pyramid where the use cases are at the
top of it.
This is may PERSONAL VIEW and what I have understood from the literature.
It helps me to decompose the complexity of software systems, but I know
that in many real world cases cannot be applyed. However, I hope this
clarify my definition of level of abstraction and what I mean with "What"
and "How" (Sorry, for this word game :)
Ciao
Walter
PS I think, the boundary between Analysis and Design is set by the elements
and the decisions that depends on real things such as programming
languages, components and so on that is used to develop the system, but
this is another story.
"Jason Gorman"
<jasong@xml-ob To: <[EMAIL PROTECTED]>
jects.com> cc:
Subject: RE: (ROSE) Bar Bet #1
28/11/00 20.53
I think there's a misunderstanding here about what use case scenarios
really
are.
Scenarios are not the "how" of the use case at any level (the "how" of a
use
case is its "realization"). Knowing every possible outcome of an
interaction
is not the same as knowing how that outcome is achieved. A use case
describes the Type Definition of the highest level state machine in the
system being modeled (the controller class). A scenario is a single
instance
of a use case where the input falls within a certain range, the system is
in
a certain discrete accepting state and the outcome is dependant on both of
these factors. Put simply, a use case stipulates that, given Input A while
the system is in a state B, the response will be C. A Type description is
definitely concerned with "what" as opposed to "how", and you should not
confuse a use case scenario with a sequence diagram or an activity diagram.
A scenario explains a single unique instance of a use case from the actor's
perspective, not in terms of objects and messages.
That is why there is such a direct link between system testing and state
machine testing - a system test is really a state machine test for the
controller class.
I hope this clears things up a little.
Jason Gorman
Object Technology Consultant
http://www.xml-objects.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: 28 November 2000 16:15
To: [EMAIL PROTECTED]
Subject: RE: (ROSE) Bar Bet #1
Walter DiCarlo
To: Michael Hill
<[EMAIL PROTECTED]>
28/11/00 17.13 cc:
Subject: RE: (ROSE) Bar Bet
#1(Document link: Walter Di Carlo)
The scenarios are the "How" of the use case at a different level of
abstraction of the design abstraction level mentioned by you.
You should think at a stack of level of abstractions with "What" and "How"
in each level.
Walter
----------------------------------------------------------------------------
-----------------
Walter Di Carlo
Software Engineer
Via Torino, 2
28831 Baveno (VB)
Italia
Tel +39 0323 922066
Fax +39 0323 925208
eMail [EMAIL PROTECTED]
www www.integra-italia.it, www.integra-welcome.com
----------------------------------------------------------------------------
-----------------
Michael Hill
<MHill@solutechinc. To: "'Smoly Walter MET
'"
<[EMAIL PROTECTED]>, "''Eric D. Tarkington' '"
com> <[EMAIL PROTECTED]>
Sent by: cc: "'Rose Forum
(E-Mail)
'" <[EMAIL PROTECTED]>
owner-rose_forum@ra Subject: RE: (ROSE) Bar
Bet #1
tional.com
28/11/00 15.13
Please respond to
Michael Hill
I am a little concerned with the statements on scenarios stating "How". A
Use Case deals with "What" the system is doing, the scenario describes in
steps of What is happening not "How".
The "How" deals with design, "How are we doing the What".
-----Original Message-----
From: Smoly Walter MET
To: 'Eric D. Tarkington'
Cc: Rose Forum (E-Mail)
Sent: 11/28/00 2:40 AM
Subject: AW: (ROSE) Bar Bet #1
It seems to me, that a third position is reasonable, which may be the
solution of the problem.
Are we talking about
1.) splitting use cases or
2.) splitting scenarios
Regarding 1.) I agree with position A.
Regarding 2.) I agree with position B.
Why ?
I'm used to concern a use-case consisting of two parts:
the specification, which describes the what
What should be done ?
What is the purpose ?
What data is needed as input ?
What is the result ?
and second the flow of events (scenarios), which describes the how
How must it be done, to get the task done ?
How must it be done, to fulfill the purpose ?
So, I think it is reasonable to structure the scenarios by itself
(according to structured programming), whitout making a separate
use-case of each sub-flow (except in case of reuse)
Like structuring the scenarios in vertical manner
main flow,
exceptional flows,
worst case,..
it is helpful to also structure them in horizontal manner (modelling
sub-flows in a separate sequence diagram and indicate them in a
high-level flow of events)
Kind regards
Walter
-----Urspr�ngliche Nachricht-----
Von: Eric D. Tarkington [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 28. November 2000 06:04
An: ROSE_FORUM
Betreff: (ROSE) Bar Bet #1
There is a collegial dispute between some of the instructors here at
Seneca. I won't tell you which side I'm on, but your comments would be
welcome. You can rest assured that I will pass them on -- if they
support me, of course.
Position A: One instructor says that you can't split a use case into
scenarios that cover less than a *complete* path through the FOE. This
agrees with Quatrani (start of chapter 5, VISUAL MODELLING), but may
produce long, awkward scenarios, and long, wide sequence diagrams.
Position B: The other says that's not good software practice, and
scenarios need to capture a small, natural unit of work in the FOE.
This contradicts Quatrani, but produces shorter scenarios with easier
sequence diagrams. One argument against is that the decomposition into
smaller scenarios may be confusing.
So, whadaya say? Do you favor position A or position B? Why?
-Eric
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
************************************************************************
*
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
************************************************************************
*
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
