OO analysis vs. Function analysis
neww...@my-deja.com
after UML standard released. Although Jacobson
insisted that Use Cases can be regarded as a kind
of Object since the Use Cases have their own
status and can enable the status change, the Use
case is more functionally oriented. It describes a
sequence of actions that systems perform. The
decomposition of scenarios with sequence diagrams
is also more like function decomposition although
objects are identified in this phase.
As many people feel more comfortable by Use
Case than other OO analysis such as CRC, is it
mean that function analysis is more powerful than
OO analysis, at least in requirement analysis
phase?
Thanks.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
neww...@my-deja.com
Tom Boy
> As many people feel more comfortable by Use
> Case than other OO analysis such as CRC, is it
> mean that function analysis is more powerful than
> OO analysis, at least in requirement analysis
> phase?
course <g>.) Use Cases is one thing, CRC is another, OMT 'devices' yet
another set of tools--all have their uses and together constitute
UML--that's what the "U" stands for, 'unified'. If you have a toolbox,
you got some hammers there, and screwdrivers, and some tape, and so
on--all are needed in some cases and aren't direct equivalents of one
another.
Rob Searle
>> neww...@my-deja.com wrote: [much snipping]
>> Use Case diagrams are most popular for OO analysis
>> after UML standard released.
Disagree that Use Cases are part of Requirements Analysis - part of
Requirements Elicitation.
>> the Use case is more functionally oriented. It describes a
>> sequence of actions that systems perform. The
>> decomposition of scenarios with sequence diagrams
>> is also more like function decomposition although
>> objects are identified in this phase.
Agree that Use Cases are functionally driven.
Do not believe that Use Cases can be used directly to create a good OO
analysis,
design and implementation as a consequence.
Strongly believe that Use Cases are the best currently available way to
achieve the following
very desirable effects at the start of a project (in no particular
order) :
1 Directing the effort towards functionality that directly improves
the customer/user
business goals (goal directed not feature lists)
2 Generating testable requirements
3 Facilitating agreement with customer in the language of the customer
4 Facilitating control of requirements change (creep) during project
5 Facilitating prioritised iterative development.
neww...@my-deja.com
Rob Searle <robert...@tait.co.nz> wrote:
> >> neww...@my-deja.com wrote: [much snipping]
>
> >> Use Case diagrams are most popular for OO analysis
> >> after UML standard released.
>
> Disagree that Use Cases are part of Requirements Analysis - part of
> Requirements Elicitation.
>
So is there any formal or semi-formal notations for requirement
analysis available, like Use Case in Requirements Elication, or like
Class diagrams in design phase? In requirment engineering, it seems
only to provide some guidlines such as interview, discussion for this
phase although this phase is very important.
> Strongly believe that Use Cases are the best currently available way
to
> achieve the following
> very desirable effects at the start of a project (in no particular
> order) :
> 1 Directing the effort towards functionality that directly improves
> the customer/user
> business goals (goal directed not feature lists)
> 2 Generating testable requirements
> 3 Facilitating agreement with customer in the language of the
customer
>
> 4 Facilitating control of requirements change (creep) during project
> 5 Facilitating prioritised iterative development.
>
Some people(e.g. Cockburn) have pointed out one of the problems of Use
Case is that Use Case do not describe goals. Goal-drvien is truly a
good way to analyze Non-Functional requirements, however, I do not
think that goal is the power of Use Case. To my opinion, in your list,
1,2,and 4 are all advantegous of goal driven method, which make the
requirement easy to traceable.
Cockburn(1997) Using goal-based use cases, Journal of Object-Oriented
Programming 10(5) 1997.
Thanks!
f_be...@hotmail.com
neww...@my-deja.com wrote:
> In article <3783C8FA...@tait.co.nz>,
[snip]
> So is there any formal or semi-formal notations for requirement
> analysis available, like Use Case in Requirements Elication, or like
> Class diagrams in design phase? In requirment engineering, it seems
> only to provide some guidlines such as interview, discussion for this
> phase although this phase is very important.
>
[snip]
> Some people(e.g. Cockburn) have pointed out one of the problems of Use
> Case is that Use Case do not describe goals. Goal-drvien is truly a
> good way to analyze Non-Functional requirements, however, I do not
> think that goal is the power of Use Case. To my opinion, in your list,
> 1,2,and 4 are all advantegous of goal driven method, which make the
> requirement easy to traceable.
>
> Cockburn(1997) Using goal-based use cases, Journal of Object-Oriented
> Programming 10(5) 1997.
>
> Thanks!
[snip]
Well, in Germany, particularly in the field of business applications,
use cases are sometimes discarded for business process models. In these
models, the business process is described as a series of events and
process steps (thereby determining the triggers for each activity).
Mature methods also describe organisational structures, goals and
objectives, information objects, ie. "pieces of information" required to
fulfill the goals and objectives of the process steps, and deliverables
(goods, services). Information objects, roles (the finest level of
organisational unit; can also be customers etc.), deliverables,
sometimes events (depending on how they are defined) are excellent
starting points for OOA, in my opinion. One can not only derive the
relevant business objects, but also the structure (associations,
aggregations) between them. Eg., if a deliverable is the post-event of a
process step and some other thing (an order) is the input, you can
derive an association between the order and the deliverable (with the
deliverable being dependent upon the order; how you describe this in UML
is up to you).
Take a look at ARIS (architecture of integrated information systems) as
an example of such a method. A reference is:
Scheer, A-W: "ARIS. Business Process Modeling."
Springer, Berlin, 1998
ISBN 3540644385
neww...@my-deja.com
can describe complex process, so many icons always make me confusion.
UML can cover most phases of software development but provide less
notations than ARIS. Too complex notations at least bring about two
problems: (1) hard to learn (2) so specific and have to depend on
specific methodology. In my opinion, the power of ARIS is other
components, like simulation and monitoring components, which are not so
formal as eEPC. Is there a simple (like notations provided for design)
and more formal (not just discussion or simulation) method provide for
requirement analysis? Or is it possible?
Thanks again
Rolf
<tomboy@nopeitsnota_url.org> wrote:
>neww...@my-deja.com wrote:
>> As many people feel more comfortable by Use
>> Case than other OO analysis such as CRC, is it
>> mean that function analysis is more powerful than
>> OO analysis, at least in requirement analysis
>> phase?
>Not at all, and btw all of the above is nonsense
I would like to get the "nonsens" explained in more detail.
Is it nonsens if one says "...modeling interaction between the
users and the system, that is modeling the functions of the system"?
Rolf
<robert...@tait.co.nz> wrote:
>
>>> neww...@my-deja.com wrote: [much snipping]
>
>>> Use Case diagrams are most popular for OO analysis
>>> after UML standard released.
>
>Disagree that Use Cases are part of Requirements Analysis - part of
>Requirements Elicitation.
>
What's the difference between Analysis and Elicitation?
David Alex Lamb
>What's the difference between Analysis and Elicitation?
A lot of us old fogies used to call everything to do with requirements
'requirements analysis' - but there's at least 3 potentially separable
activities
- getting customers/ clients/ users/ domain experts/ etc/ to talk about the
problem domain ('eliciting' requirements)
- studying ('analysing') the collection of requirements, looking for
omissions, ambiguities, contradictions
- developing a rigorous description of the requirements for the developers to
use ('specification')
There doesn't necessarily have to be a rigid dividing line between the
activities -- for example, drafting a specification might be a good way to
organize one's approach to analysis, and analysis may lead to questions to ask
the 'customers' as part of further elicitation.
One reason for the divisions can be that one doesn't necessarily want to force
customers to cope with the kinds of notations that technical people want to
use during analysis and specification.
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/
Rob Searle
Requirements Elicitation - communication with customers, users and other
project stake holders to agree what the requirements are.
Requirements Analysis - Formalisation and (what's another word for
analysis ?) of the elicited requirements in order to ensure that they
are complete, self consistent, feasible ...
Rolf wrote:
> On Thu, 08 Jul 1999 09:39:06 +1200, Rob Searle
> <robert...@tait.co.nz> wrote:
>
> >
> >>> neww...@my-deja.com wrote: [much snipping]
> >
> >>> Use Case diagrams are most popular for OO analysis
> >>> after UML standard released.
> >
> >Disagree that Use Cases are part of Requirements Analysis - part of
> >Requirements Elicitation.
> >
Kenneth Brown
Rob Searle wrote:
--
"When I am working on a problem, I never think about beauty. I think only of
how to solve the problem. But when I have finished, if the solution is not
beautiful, I know it is wrong." -- R. Buckminster Fuller