Cobol - OO as a Form of Modular Programming

Author

OO as a Form of Modular Programming

Rick Smith

2007-02-20, 6:55 pm

The above subject is discussed in Bertrand Meyer,
"Object-Oriented Software Construction," Second
Edition, 1997, Chapter 3, "Modularity".

I have omitted much of the text in order to support
and emphasize the points I have raised recently.
OO [Design] is modular programming, and
Modular programming is design methods.

"Modular programming was once taken to mean the
construction of programs as assemblies of small pieces,
usually subroutines. But such a technique cannot bring
real extendibility and reusability benefits unless we have
a better way of guaranteeing that the resulting pieces
-- the modules -- are self-contained and organized in
stable architectures. ...

"A software construction method is modular, then, if it
helps designers produce software systems made of
autonomous elements connected by a coherent, simple
structure. ... The focus will be on design methods, but
the ideas also apply to earlier stages of system construction
(analysis, specification) and must of course be maintained
at the implementation and maintenance stages.

"... This chapter introduces a set of complementary
properties: five criteria, five rules and five principles of
modularity which, taken collectively, cover the most
important requirements on a modular design method.

"... The discussion will lead in a later chapter to the O-O
form of module -- the class -- ..."

-----

Found on the internet, some time ago:

C++ is the only current language making
COBOL look good. -- Bertrand Meyer

Howard Brazee

2007-02-20, 6:55 pm

On Tue, 20 Feb 2007 13:56:29 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:

>"Modular programming was once taken to mean the
>construction of programs as assemblies of small pieces,
>usually subroutines. But such a technique cannot bring
>real extendibility and reusability benefits unless we have
>a better way of guaranteeing that the resulting pieces
>-- the modules -- are self-contained and organized in
>stable architectures. ...

It's a changing target. But one requirement seems to be that each
module is something that has been created and assembled to create the
final product. Modular homes include pre-fabricated walls complete
with electrical wires. Re-usability hasn't been a requirement in the
past.

Larger modules are easier to work with. A house built with modular
rooms goes together faster than a house built with modular walls. And
objects go together faster than COMPUTE statements which go together
faster than assembler which replace machine language.

Modules can also be stronger and safer - that modular wall could have
been built in ideal conditions and tested before being incorporated in
the house.

Certainly objects are a type of module - with more power and utility
than paragraphs and copy members.

andrewmcdonagh

2007-02-20, 6:55 pm

On Feb 20, 6:56 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> The above subject is discussed in Bertrand Meyer,
> "Object-Oriented Software Construction," Second
> Edition, 1997, Chapter 3, "Modularity".
>
> I have omitted much of the text in order to support
> and emphasize the points I have raised recently.
> OO [Design] is modular programming, and
> Modular programming is design methods.
>
> "Modular programming was once taken to mean the
> construction of programs as assemblies of small pieces,
> usually subroutines. But such a technique cannot bring
> real extendibility and reusability benefits unless we have
> a better way of guaranteeing that the resulting pieces
> -- the modules -- are self-contained and organized in
> stable architectures. ...
>
> "A software construction method is modular, then, if it
> helps designers produce software systems made of
> autonomous elements connected by a coherent, simple
> structure. ... The focus will be on design methods, but
> the ideas also apply to earlier stages of system construction
> (analysis, specification) and must of course be maintained
> at the implementation and maintenance stages.
>
> "... This chapter introduces a set of complementary
> properties: five criteria, five rules and five principles of
> modularity which, taken collectively, cover the most
> important requirements on a modular design method.
>
> "... The discussion will lead in a later chapter to the O-O
> form of module -- the class -- ..."
>
> -----

sure...Modularity is a basic form of Fractal design.

We have OO types (classes, interfaces, Abstract Classes ,etc) which
are modules.
We Bundle certain instances of these types together to create
components (dataaccess layers, GUI libraries, etc) which are modules
We bundle these together to create applicants (Web Services, Web Apps,
Thick Clients etc) which are modules of Systems.
We link Systems together to create larger systems
(Customer ordering web site
-> Back office inventory management systems
-> Warehouse inventory systems
-> Robotic Pickers)

Its a fractal world after all.

Indeed, many OO Design Patterns consist of Fractals too (Model View
Control Uses the Listener aka Publish Subscribe pattern)

Andrew

andrewmcdonagh

2007-02-20, 6:55 pm

On Feb 20, 8:17 pm, "andrewmcdonagh" <andrewmcdon...@gmail.com> wrote:
> On Feb 20, 6:56 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
>
>
>
>
>
>
>
>
>
>
> sure...Modularity is a basic form of Fractal design.
>
> We have OO types (classes, interfaces, Abstract Classes ,etc) which
> are modules.
> We Bundle certain instances of these types together to create
> components (dataaccess layers, GUI libraries, etc) which are modules
> We bundle these together to create applicants (Web Services, Web Apps,
> Thick Clients etc) which are modules of Systems.
> We link Systems together to create larger systems
> (Customer ordering web site
> -> Back office inventory management systems
> -> Warehouse inventory systems
> -> Robotic Pickers)
>
> Its a fractal world after all.
>
> Indeed, many OO Design Patterns consist of Fractals too (Model View
> Control Uses the Listener aka Publish Subscribe pattern)
>
> Andrew

Its this fractal nature of things that causes some of the confusion,
we pick a word that describes somethign specific and others see the
same fractal pattern at a different level. So they use it too, but
then people start to get

as to the 'true' meaning of it,
instead of looking at the underlying principle of it.

My 2c

Andrew

LX-i

2007-03-02, 3:55 am

Howard Brazee wrote:
> Larger modules are easier to work with. A house built with modular
> rooms goes together faster than a house built with modular walls. And
> objects go together faster than COMPUTE statements which go together
> faster than assembler which replace machine language.
>
> Modules can also be stronger and safer - that modular wall could have
> been built in ideal conditions and tested before being incorporated in
> the house.

You're right - but that's where the "inheritance" principle in OO comes
in. A "room" will have 4 or more "wall" object, who themselves may have
"window" or "door" objects. While the room may be quite specific, the
lower-level components, such as doors or windows, are more generic.
Just because the room isn't assembled at the job site doesn't mean that
it didn't have to get assembled somewhere. :)

And, your room analogy illustrates another advantage of OO design.
Companies can combine low-level components into functional "larger
modules", which themselves can become the lower-level components of an
even larger module - for example, a house.

> Certainly objects are a type of module - with more power and utility
> than paragraphs and copy members.

The biggest problems we'd really started to run into was the global
nature of COBOL variables. Now yes, I know you don't have to do it that
way, but most people don't even know about nested subprograms, and even
fewer use them in their design and construction. We had a terrible time
with either left-over data, or data that was changed out from under the
application program.

OO solves that dilemma by encapsulating the data with the code. The
more I use it, the more I like it. :) And now, when I look at doing
something in COBOL, I find myself thinking in nested subprograms instead
of paragraphs.

(not that any of this is new to you - your post just brought those
thoughts to mind...)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine

Sponsored Links