RE: (ROSE) Bar Bet #1

Romuald Restout Tue, 28 Nov 2000 13:06:32 -0800

Title: RE: (ROSE) Bar Bet #1

I do agree with that.
Analysis objects describe the What. Messages between those objects are described as "services" rather than "methods".

1-Unfortunately, in real life, you rarely have enough time to have an analysis model, a design model, the synchronization between your both models !

Except if you MUST have different implementations of the same analysis model.
So you have one model that you refine little by little.
2-I don't know for other analysts, but when I create my analysis model, I use all object concepts (abstraction, inheritance, aggregation, ..) , thus starting to describe the "How".

Some would say that is already "Design". However, those concepts may be essential to make complex problem understantable.

I think that the frontier between Analysis and Design may be tenious.
Wanting absolutely to have this frontier "clear" can bring you to analysis paralysis. IMHO ;-)

Romuald

-----Original Message-----
From: Michael Hill [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 28, 2000 1:20 PM
To: 'Romuald Restout '; Michael Hill; ''Smoly Walter MET ' '; '''Eric D.
Tarkington' ' '
Cc: ''Rose Forum (E-Mail) ' '
Subject: RE: (ROSE) Bar Bet #1

I agree with you somewhat, but those objects idenified are analysis objects
not design objects. The analysis objects are part of the analysis model,
once the analysis model is mature and correct with respect to the
requirements, then you can start the design with the analysis model. In the
analysis model, each object has a set of responsibilities(services). Those
responsibilities will translate into one or more operations in the design
model. These responsibilities are "What" each object will do. The analysis
model is the requirements modeled in a visual format(objects and classes)
along with Activity diagrams, state diagrams, and interaction diagrams to
explain how the requirements flow in a picture. When I talk about Use Cases
I mean Requirements, when I talk about Use Case Realizations I mean design.

-----Original Message-----
From: Romuald Restout
To: 'Michael Hill'; 'Smoly Walter MET '; ''Eric D. Tarkington' '
Cc: 'Rose Forum (E-Mail) '
Sent: 11/28/00 10:20 AM
Subject: RE: (ROSE) Bar Bet #1

Hi,

If you use sequence diagrams to modelize your scenarios, you will have
to define some objects.
So even if you use business objects, you already start to think about
the How. That is :
- What objects are needed for my use-case ?
- What services are needed ?
- How do I split my services through my objects, i.e. what object is
responsible for what service ?
- How do I link all my services and objects, so the job is done ?
Sequence diagram impose you to think about that, while you can do it
very "high-level"

The solution to deal only with the What, is to use only textual
description.
This may be quite complicated and unreadable when dealing with complex
use-cases.

Romuald Restout
Senior Analyst
Recruitsoft
The Leading ASP for enterprise Hiring Management Systems
[EMAIL PROTECTED]

Shoot for the moon. Even if you miss, you'll land among the stars.

-----Original Message-----
From: Michael Hill [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Tuesday, November 28, 2000 9:13 AM
To: 'Smoly Walter MET '; ''Eric D. Tarkington' '
Cc: 'Rose Forum (E-Mail) '
Subject: RE: (ROSE) Bar Bet #1

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]
<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
<http://www.rational.com/support>
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
<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
*
************************************************************************

*
************************************************************************

RE: (ROSE) Bar Bet #1

Reply via email to