Hello
Let me put my humble opinion here.
We use Use Cases for gathering requirements ( as I believe most
of you do ) so there are two sides communicating via Use Cases
1. Business people
2. Analists
For business people all the relationships, inheritance (they even don't
know this word, that's whu it was replaced with "generalization" i guess:-)
they all just entangle the whole picture. They all want to see functionality
doesn't matter if browsing the list of partners has some common part
with browsing list of employees. That's why only "include" and "extend"
relations have use in this world.
Other part wants to prepare Use Cases for design ie separate common parts,
generalize requirements as possible. So generalization is viable part of the
picture for analysts.
I believe this contradiction can be solved by having separate use cases
focused on generalization and separate ones focused on aggregation.
Former ones are interface between analysis and customers/businesses etc.
Latter are interface between analysis and design.
Egor A. Shokurov
Netreflector.com
> -----Original Message-----
> From: Michael Hill [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 28, 2000 11:28 PM
> To: 'Romuald Restout '; Michael Hill; '''Smoly Walter MET ' '
> '; ''''Eric D. Tarkington' ' ' '
> Cc: '''Rose Forum (E-Mail) ' ' '
> Subject: RE: (ROSE) Bar Bet #1
>
>
>
> I would have to agree on everything but number 2, I don't
> believe that
> aggregations are a necessary part of the analysis model.
> Inheritance and
> abstraction may be important parts, but for me, the analysis
> model should be
> simple without a lot of fancy associations and relationships.
>
> -----Original Message-----
> From: Romuald Restout
> To: 'Michael Hill'; ''Smoly Walter MET ' '; '''Eric D. Tarkington' ' '
> Cc: ''Rose Forum (E-Mail) ' '
> Sent: 11/28/00 2:20 PM
> Subject: 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]
> <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]>
> < 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]>
> < 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>
> < 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>
> < http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> <http://www.rational.com/products/rose/usergroups/rose_forum.j
> tmpl> >
> * 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
> <http://www.rational.com/support>
> < 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>
> < http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> <http://www.rational.com/products/rose/usergroups/rose_forum.j
tmpl> >
* 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
<http://www.rational.com/support>
< 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>
< 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
*
************************************************************************
*
************************************************************************
* 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
*
*************************************************************************
