Software Engineering - Structured Analysis & OO Analysis

Author

Structured Analysis & OO Analysis

ball

2007-09-10, 4:20 am

Hi all,

Can anyone tell me what is really different between Structured
Analysis & OO Analysis? All I understand is that Structured Method
requires us to draw DFD, ERD, STD diagram & OO Analysis requires us to
draw Use-case diagram. However, I believe that just the top of the ice
mountain. I wonder what is beneath that? What is the different in term
of methodology (not just diagram)?

Can anyone help me to clarify?

Thank in advance

S Perryman

2007-09-10, 4:21 am

"ball" <agileball@gmail.com> wrote in message
news:1189403126.298680.305300@y42g2000hsy.googlegroups.com...

> Can anyone tell me what is really different between Structured
> Analysis & OO Analysis? All I understand is that Structured Method
> requires us to draw DFD, ERD, STD diagram & OO Analysis requires us to
> draw Use-case diagram. However, I believe that just the top of the ice
> mountain. I wonder what is beneath that? What is the different in term
> of methodology (not just diagram)?

> Can anyone help me to clarify?

The SA view of a system is of data flows between logical processes.
These processes transform the data from one form to another.

Allied to the data view is a control view.
These (type of) processes pass control info between each other.
More importantly, control processes control if/when data flow processes
are active.

The OO view is of a system of objects.
Objects encapsulate (ie organise) control and data transform behaviour
into a whole. Objects interact with each other to effect the desired
control and data transform behaviour.

The conceptual difference between the SA and OO view is the
organisation (decomposition, encapsulation, partitioning etc) . It is on
paper quite a difference.

The reality however is that the difference is not that great at all.
This was proven in the late 1980s / early 1990s with approaches that
mapped SA models to OO models, which were simply defined and
repeatable.

I and others had a great deal of success with these approaches,
both in taking SA models forward into OOD/OOP design/impls,
and in educating people from an SA background in the basics of
OO (often the claim one hears is that there are people who
"don't get" OO) .

Regards,
Steven Perryman

Phlip

2007-09-10, 7:08 pm

H. S. Lahman

2007-09-10, 7:08 pm

Responding to Ball...

> Can anyone tell me what is really different between Structured
> Analysis & OO Analysis? All I understand is that Structured Method
> requires us to draw DFD, ERD, STD diagram & OO Analysis requires us to
> draw Use-case diagram. However, I believe that just the top of the ice
> mountain. I wonder what is beneath that? What is the different in term
> of methodology (not just diagram)?

They are different enough so that they are fundamentally incompatible as
construction paradigms. OOA/D employs basically the same models as SA/D
because the underlying set and graph theory is the same. OOA/D provides
more links between the diagrams and uses different formats (e.g.,
swimlanes in an Interaction Diagram vs. DFD process bubbles). However,
the /way/ the diagrams are constructed is quite different.

In SA/SD functional decomposition dominated the construction paradigm
and reuse was achieved by instantiating higher level nodes in the
functional decomposition tree, which created hierarchical implementation
dependencies (aka Spaghetti Code) when those nodes were reused.

In OOA/D construction is based on abstracting the problem space into
objects and subsystems. Thus in OOA/D one aggregates based on
fundamental problem space structure rather than functional
decomposition. Those objects and subsystems then collaborate on a
peer-to-peer basis rather than hierarchically. OOA/D also makes heavy
use of relationship instantiation to limit access to knowledge (that is,
object attributes seem to be globally accessible in the diagrams but in
practice access is severely limited).

Also note that use cases are a form of requirements specification so
they can be used equally well for OOA/D and SA/D. It just happened that
Ivar Jacobson pioneered the use of use cases for OO construction
specification.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Andrew Gabb

2007-09-15, 7:06 pm

ball wrote:
> Can anyone tell me what is really different between Structured
> Analysis & OO Analysis? All I understand is that Structured Method
> requires us to draw DFD, ERD, STD diagram & OO Analysis requires us to
> draw Use-case diagram. However, I believe that just the top of the ice
> mountain. I wonder what is beneath that? What is the different in term
> of methodology (not just diagram)?

You've been given some good answers, including a couple of
conflicts, which is usual. There's no 'truth' in discussing this
subject, and a lot of distracting bullshit (present company
excluded) and religion.

Both approaches are valid. Both work. Both have produced excellent
systems.

OO is generally preferred for modern desktop operating systems
because the OS works on an OO basis itself. SA/SD is often preferred
for some large defence and other real time systems.

Some OO derived software should use SA/SD but doesn't because the
designers are not familar with SA/SD. And vice versa. Some system
developments have failed using an OO approach and fixed using SA/SD.
And vice versa. (Probably had more to do with the skills of the
people than the approach.) OO techniques can provide additional
insight into a SA/SD task. And vice versa.

If you're coming from one camp into the other, the first thing to
realise is that they're fundamentally different approaches. Although
there are obviously overlaps between the two, the analysis, design
and architecture will normally look quite different.

Despite what Steve says, mapping between the two is not at all easy
and won't make much sense to anyone except an expert in using such
tools. It's a bit like translating an Ada program into C. Possible,
yes, useful, maybe, but the result doesn't really look at all like a
C program written from scratch.

Try to understand both, including their strengths and weaknesses.

Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021
-----

S Perryman

2007-09-16, 8:04 am

Andrew Gabb wrote:

[color=darkred]
> Both approaches are valid. Both work. Both have produced excellent systems.

> OO is generally preferred for modern desktop operating systems because
> the OS works on an OO basis itself. SA/SD is often preferred for some
> large defence and other real time systems.

> Some OO derived software should use SA/SD but doesn't because the
> designers are not familar with SA/SD. And vice versa. Some system
> developments have failed using an OO approach and fixed using SA/SD. And
> vice versa. (Probably had more to do with the skills of the people than
> the approach.) OO techniques can provide additional insight into a SA/SD
> task. And vice versa.

> If you're coming from one camp into the other, the first thing to
> realise is that they're fundamentally different approaches. Although
> there are obviously overlaps between the two, the analysis, design and
> architecture will normally look quite different.

> Despite what Steve says, mapping between the two is not at all easy

1. The mapping of RTSA models into OOA models is actually not so difficult
(despite what you may believe) .

2. The design/impl produced from an SD approach is obviously fundamentally
different to its equivalent OOD/OOP form.

Back in the day, there were a number of proposed approaches (I recall
Paul Ward wrote an IEEE article etc) . The approach I used was written by
a UK consultancy who (then) specialised in RTSASD consultancy/training.

Apart from the simplicity of the mapping rules, their paper had an immense
credibility the others did not. For the example they used was not some
toytown vending machine etc, it was from a fragment of an RTSA model that
was used to develop an engine management system for a military aircraft.

The old-hand SASD guys got the key concepts of OO because they had a
reference point, an excellent example, and some simple rules to apply, not
because they immediately force-fed an OOP syntax or concepts such as
inheritance etc.

Regards,
Steven Perryman

topmind

2007-10-02, 10:11 pm

On Sep 10, 4:38 am, Phlip <phlip2...@gmail.com> wrote:
> ball wrote:
>
> The best rule-of-thumb for design is to remove duplication from code,
> especially duplicated behavior.
>
> You don't _only_ design by drawing diagrams, but we will get back to that.
>
> You are describing Structural Programming. OO adds to that a new system to
> remove duplication while managing complexity. In an OO program, some method
> calls are virtual. Given foo(x){ x.bar() }, the type of x can vary between
> calls, forcing foo() to call a different bar() each time.
>
> This helps you avoid packing foo() full of conditional statements to
> determine which bar() to call. This also fixes the duplication with any
> other site that wants to call x.bar().

I challenge you to prove it with actual code. If this is another case/
if versus polymorphism claim, then I've demonstrated it wrong at:

http://www.geocities.com/tablizer/inher.htm

They are generally the same amount of code (although there may be
language-specific differences.)

Plus, IF statements are more flexible than polymorphism for common
changes. They "degenerate" better when the granularity of variance
changes after the original design is finished. Hierarchical taxonomies
are problematic because the real world changes at its own granularity
and shape. Polymorphism's granularity is too blunt and too difficult
to change for most actual change patterns (and the exceptions are hard
to identify up front). This applies to the Strategy pattern also.

OO design often has the assumption that your design can "surf on" a
hierarchical (or at least DAG) taxonomy of domain nouns to simplify
dispatching and code. This has proven to be mostly caca[1] for biz
apps. It is usually smarter to store the domain noun classification
system in a database and use set theory instead of trees for domain
noun classification instead of app code. I stand by this technique
over OOD because it is usually easier to change data than to change
code (and can be done by users instead of programmers).

>
> --
> Phlip
> http://www.oreilly.com/catalog/9780596510657/
> ^ assert_xpath
> http://tinyurl.com/23tlu5 <-- assert_raise_message

-T-

[1] poop

topmind

2007-10-02, 10:11 pm

H. S. Lahman wrote:
> Responding to Ball...
>
>
> They are different enough so that they are fundamentally incompatible as
> construction paradigms. OOA/D employs basically the same models as SA/D
> because the underlying set and graph theory is the same. OOA/D provides
> more links between the diagrams and uses different formats (e.g.,
> swimlanes in an Interaction Diagram vs. DFD process bubbles). However,
> the /way/ the diagrams are constructed is quite different.
>
> In SA/SD functional decomposition dominated the construction paradigm
> and reuse was achieved by instantiating higher level nodes in the
> functional decomposition tree, which created hierarchical implementation
> dependencies (aka Spaghetti Code) when those nodes were reused.

That is the old 70's style. The newer style of procedural design uses
event-driven programming and moves noun "taxonomies" and complex
"structures" into a database instead of app code.

>
> In OOA/D construction is based on abstracting the problem space into
> objects and subsystems. Thus in OOA/D one aggregates based on
> fundamental problem space structure rather than functional
> decomposition. Those objects and subsystems then collaborate on a
> peer-to-peer basis rather than hierarchically. OOA/D also makes heavy
> use of relationship instantiation to limit access to knowledge (that is,
> object attributes seem to be globally accessible in the diagrams but in
> practice access is severely limited).
>
> Also note that use cases are a form of requirements specification so
> they can be used equally well for OOA/D and SA/D. It just happened that
> Ivar Jacobson pioneered the use of use cases for OO construction
> specification.
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman

-T-

Sponsored Links