Re: How to Introduce OO to Structured-Method IT Person?

From: Universe (no email)
Date: 11/08/04 

Date: Mon, 08 Nov 2004 02:17:05 -0500

gohbn2000@yahoo.com.sg (BoonNam Goh) wrote:

> I am looking into how to introduce OO to a Structured-Method Person
> (ie. IT professional who is new to OO but who has done things via
> structured or functional decomposition method).
>
> Appreciate advice:
> Can I say as a simplification, that one of the first benefits of OO is
> that it allows for "normalization" of methods -- similar to
> logical-data-modelling's (ie. LDM's) normalisation of data?
>
> Let me explain:
> In LDM, data is normalised to 3rd normal form (3NF) where there will
> be no duplication of data items in the various data entities.
>
> Similarly, for OO, when we analyse the objects and draw them into a
> class diagram and use GRASP (or other similar methods) to assign
> methods to relevant classes, we are sort of also "normalising" the
> methods so that algorithms only appear in one place in the whole
> system -- ie. there is no duplication. This automatically makes all
> algorithms reuseable as "subroutines".
>
> Eg. In functional decomposition, we could have two processes/modules
> to develop in a system - say, "buy book" and "catalog book". When we
> do the functional decomposition, we may end up with duplicate
> algorithms for ValidateISBNCheckDigit in each module and we have to
> realise that there are such duplicates before we can move them out
> into a common subroutine.
>
> In the case of OO, we would have naturally put ValidateISBNCheckDigit
> as a method into a suitable class (eg. "Book") the first time we did
> an analysis for the first module - say, "buy book". When we do OO
> analysis of the 2nd module - "Catalog Book", the
> ValidateISBNCheckDigit method would again naturally go to the same
> class. Creation and reuse of a "subroutine" would come about
> naturally.
>
> Does the above sound valid as a sort of simplification to one aspect
> of OO?

Yes, but it is akin for many projects to prematurely doing performance
tuning--attempted before requirements task logic has been completed.

I suggest that *modelling*, or the same thing *abstracting* -
eliminating things irrelevant to the requirements and representing or
enhancing things relevant to project requirements - the project domain
and requirements should be the starting point of virtually *all*
software development.

The essence of OO sw engineering is reducing complexity by modelling -
abstracting* - major requirements relevant role responsibilities, in
the domain and in the requirements, as a network of collaborating
object modules.

"Object-oriented [OO] programming. A program execution
is regarded as a physical model, simulating the behavior
of either a real or imaginary part of the world...The
notion of a physical model should be taken literally."
 ~ Computerized physical models
   by Madsen, Moeller-Pederson, Nygaard (co-founder of OO)

Similarly the essence of Structured sw engineering is reducing
complexity by modelling - abstracting - major requirements relevant
data handling processes and entities, in the domain and in the
requirements, as a network of collaborating event modules.

There's more to 'em obviously, different secondary things, like "avoid
goto" for Structured - but these are the core skeletal definitions.

Dependency management (DM), has 2 critical success factors (CSF):
        ` minimally loose inter-module coupling
        ` maximally higher intra-module cohesion
DM has a cornucopia of techniques for achieving its CSF's, like:
                - localizing declaration and definition code
                - Law of Demeter (for *both* Structured and OO)
                - minimizing code duplication
                - minimizing interface size
However applying these DM techniques should be secondary to creating
the overall system modelling framework, and DM should serve and
strengthen the operation of the processing model.

"We will introduce concepts such as information processes and systems
and discuss abstraction, concepts, classification and composition. The
framework provides a means to be used when modeling phenomena and
concepts from the real world, it is thus a fundamental basis for
object-oriented analysis and design. It is, however, also important
for implementation, since it provides a means for structuring and
understanding the objects and patterns generated by a program
execution. The approach presented in this book is that analysis,
design and implementation are programming or modeling activities, but
at different abstraction levels."
~ Object-Oriented Programming in the BETA Programming Language
    Ole Lehrmann Madsen, Birger Møller-Pedersen, Kristen Nygaard

[Nygaard is one of the 2 (1st among equals, imo) co-creators of the OO
sw paradigm.]
        
Of course, many multi-layered software system architectures often use
different modelling paradigms for various layers. I.e. the domain and
requirements layers may have OO modelling, while the data layer has
Chen Entity/Relational modelling.

To repeat, I think its best to begin with a focus on
modelling/abstraction to reduce complexity in general, with objects
as the key, or core, granule of system abstraction.

Modelling in mainstream OO sw engineering has multiple overlapping
functions. Modelling is the basis for understanding the domain and
use case requirements. And fortunately, a key thing that makes OO
modelling a big win, the OO analysis models - class, sequence, state,
etc - can and should serve as the core skeleton of the system's high
level - user interface, domain model, and requirements model -
physical design. Just as Nygaard et al state in the last excerpt.

This is the way OO's *seamless* design is realized. This means key
analysis object model entities should be preserved as the skeleton for
the system's high level physical design.

Elliott

Relevant Pages