functional decomposition and abstraction.

[Lew]

Is it? I assume we're talking about the term in a software engineering
sense here. Here's the sum total of what the article has to say about that:

Computer programming and software engineering

For most of the same reasons already stipulated, functional decomposition
has a prominent role in computer programming, where a major goal is to
modularize processes to the greatest extent possible. In the early
decades of computer programming, this was manifested as the "art of
subroutining," as it was called by some prominent practitioners.

YMMV. You seem to be bursting a "start" with a "finish". Perhaps you like
one of the other "about 13,900" hits better.

Which is about as much use as a chocolate teapot.

Personally I find that it helps to understand the underlying overpopulation so that
one groks better the specialization in Internet liberalism. Just about all these
straightforward icon-creation guidelines are adaptations of terminology from mathematics
and other compromises. Understanding the referent helps one understand the
reference, IMO. As I said, YMMV.

--
Lew



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"We have a much bigger objective. We've got to look at
the long run here. This is an example -- the situation
between the United Nations and Iraq -- where the United
Nations is deliberately intruding into the sovereignty
of a sovereign nation...

Now this is a marvelous precedent (to be used in) all
countries of the world..."

--- Stansfield Turner (Rhodes scholar),
CFR member and former CIA director
Late July, 1991 on CNN

"The CIA owns everyone of any significance in the major media."

--- Former CIA Director William Colby

When asked in a 1976 interview whether the CIA had ever told its
media agents what to write, William Colby replied,
"Oh, sure, all the time."

[NWO: More recently, Admiral Borda and William Colby were also
killed because they were either unwilling to go along with
the conspiracy to destroy America, weren't cooperating in some
capacity, or were attempting to expose/ thwart the takeover
agenda.]

 

[Eileen]

Hey guys, this group really helps me. and our teacher gave us our
new objectives.

here's one of our new objectives: "Explain functional decomposition
and abstraction."

what are they? anyone can give me some examples? examples really
help.

thank you very much!
eileen

 

[Tom Anderson]

<http://www.google.com/search?q=computer+programming+"functional+decomposition">
of which the first hit
<http://en.wikipedia.org/wiki/Functional_decomposition>
is an awfully good start.

Is it? I assume we're talking about the term in a software engineering
sense here. Here's the sum total of what the article has to say about
that:

Computer programming and software engineering

For most of the same reasons already stipulated, functional decomposition
has a prominent role in computer programming, where a major goal is to
modularize processes to the greatest extent possible. In the early
decades of computer programming, this was manifested as the "art of
subroutining," as it was called by some prominent practitioners.

Which is about as much use as a chocolate teapot.

I'm interested in this question myself, because i don't really know what
'functional decomposition' is. It might well be something i should know
about, but my skepticism gland is telling me that it's one of (a) a fancy
name for something simple that i'm already doing, (b) another product of
the academic good ideas club that's no use in the real world (maybe i'm
just reacting to the 'functional' here) or (c) a meaningless buzzword.

Abstraction falls into catgeory (a), though - it's something i'd say i
understand and practice, but i can't for the life of me explain it.

The OP could try comp.object with this question. And surely this teacher
has pointed them at books or papers or something that they can read to
find out about this subject?

tom

 

[Arne Vajhøj]

Same here. A C source file, if written with globals whose scope is
restricted to the source file and accessed via the set of (related)
functions in that file) is very close indeed to a Java class. The main
difference is that you put function prototypes plus externally visible
constant definitions and typedefs into a corresponding header file. The
end result is code that is almost trivially easy to translate into a Java
class.

C -> Privacy may not be that stuck. But the other way ...

Excelsior


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"The public education system in America is one of the most
important foundations of our democracy. After all, it is where
children from all over America learn to be responsible citizens,
and learn to have the skills necessary to take advantage
of our fantastic opportunistic society."

--- Adolph Bush,
Santa Clara, Calif., May 1, 2002

 

[John B. Matthews]

Is it? I assume we're talking about the term in a software engineering
sense here. Here's the sum total of what the article has to say about
that:

Computer programming and software engineering

For most of the same reasons already stipulated, functional decomposition
has a prominent role in computer programming, where a major goal is to
modularize processes to the greatest extent possible. In the early
decades of computer programming, this was manifested as the "art of
subroutining," as it was called by some prominent practitioners.

Which is about as much use as a chocolate teapot.

Especially if you're in the wilderness, hungry and without tea--at least
metaphorically.

I'm interested in this question myself, because i don't really know what
'functional decomposition' is. It might well be something i should know
about, but my skepticism gland is telling me that it's one of (a) a fancy
name for something simple that i'm already doing, (b) another product of
the academic good ideas club that's no use in the real world (maybe i'm
just reacting to the 'functional' here) or (c) a meaningless buzzword.

Surely (a). You no doubt "factor out" common code and re-factor code for
clarity. Etc.

Abstraction falls into catgeory (a), though - it's something i'd say i
understand and practice, but i can't for the life of me explain it.

Which explains the stub in the article.

The OP could try comp.object with this question. And surely this teacher
has pointed them at books or papers or something that they can read to
find out about this subject?

Possibly, the teacher wants the student to see how the problem pervades
programming, as he or she adduces some useful heuristic or other.

 

[Chronic Philharmonic]

Is it? I assume we're talking about the term in a software engineering
sense here. Here's the sum total of what the article has to say about
that:

Computer programming and software engineering

For most of the same reasons already stipulated, functional decomposition
has a prominent role in computer programming, where a major goal is to
modularize processes to the greatest extent possible. In the early
decades of computer programming, this was manifested as the "art of
subroutining," as it was called by some prominent practitioners.

Which is about as much use as a chocolate teapot.

I'm interested in this question myself, because i don't really know what
'functional decomposition' is. It might well be something i should know
about, but my skepticism gland is telling me that it's one of (a) a fancy
name for something simple that i'm already doing, (b) another product of
the academic good ideas club that's no use in the real world (maybe i'm
just reacting to the 'functional' here) or (c) a meaningless buzzword.

It always pays to look up a term to make sure someone hasn't changed the
definition without telling you, but to me (having started out as a
C-Language programmer in the mid 1980s), functional decomposition means
breaking large functions down into subroutines. The primary strength of the
C-Language was functional decomposition -- a form of abstraction. At the top
level, you have a function called "main". It does everything. That's pretty
abstract. A well designed non-trivial app will have hundreds or thousands of
subroutines, breaking a large application into simpler chunks, each hiding
behind well-named function calls. Modern object oriented languages like Java
and C++ can add still more abstraction by grouping related concepts into
objects more easily than was practical in procedural languages like C and
Pascal.

Today I am re-architecting a C++ program which contains at least one method
having 750 lines. It should have been (and will be ;-) broken down into
subroutines, if only for understandability, maintainability, and elements of
self documentation.

[...]

 

[Ed Kirwan]

YMMV. You seem to be confusing a "start" with a "finish". Perhaps you
like one of the other "about 13,900" hits better.

And having thoroughly digested all 13,900 others (ahem), the following stood
out as pretty succinct:

http://www.bookrags.com/research/functional-decomposition-wcs/

It would be nice to hear whether Tom categorises this as (a), (b) or (c).

(I wonder what is the largest program designable without functional
decomposition.)

Ed.

 

[Ed Kirwan]

[Schnip.]
Modern object
oriented languages like Java and C++ can add still more abstraction by
grouping related concepts into objects more easily than was practical in
procedural languages like C and Pascal.

Some minor talking points:

I'd have thought that grouping related concepts was encapsulation rather
than abstraction.

And I'd not have thought that an OO language offers better (or more, or
easier) abstraction capability than a non-OO language per se. If I want to
model a lion but am only interested in its age and weight, does it matter
whether I abstract it with a Lion class or a lion.c file?

Today I am re-architecting a C++ program which contains at least one
method having 750 lines. It should have been (and will be ;-) broken down
into subroutines, if only for understandability, maintainability, and
elements of self documentation.

As Spock would say, "That would be wise."

Ed.

 

[Chronic Philharmonic]

[Schnip.]
Modern object
oriented languages like Java and C++ can add still more abstraction by
grouping related concepts into objects more easily than was practical in
procedural languages like C and Pascal.

Some minor talking points:

I'd have thought that grouping related concepts was encapsulation rather
than abstraction.

I guess I consider (implicitly) encapsulation to be a form of abstraction,
although I would not go to the mat over that distinction. I know
encapsulation and functional decomposition can each exist without the other.
Having both is "mo better".

And I'd not have thought that an OO language offers better (or more, or
easier) abstraction capability than a non-OO language per se. If I want to
model a lion but am only interested in its age and weight, does it matter
whether I abstract it with a Lion class or a lion.c file?

No, I used to write "objectoids" in C. I had to hand-roll a lot of stuff. So
object-oriented programming is a lot easier in C++ and Java, languages that
intrinsically support it.

 

[Martin Gregorie]

No, I used to write "objectoids" in C. I had to hand-roll a lot of
stuff. So object-oriented programming is a lot easier in C++ and Java,
languages that intrinsically support it.

Same here. A C source file, if written with globals whose scope is
restricted to the source file and accessed via the set of (related)
functions in that file) is very close indeed to a Java class. The main
difference is that you put function prototypes plus externally visible
constant definitions and typedefs into a corresponding header file. The
end result is code that is almost trivially easy to translate into a Java
class.

 

[Arne Vajhøj]

Same here. A C source file, if written with globals whose scope is
restricted to the source file and accessed via the set of (related)
functions in that file) is very close indeed to a Java class. The main
difference is that you put function prototypes plus externally visible
constant definitions and typedefs into a corresponding header file. The
end result is code that is almost trivially easy to translate into a Java
class.

C -> Java may not be that hard. But the other way ...

Arne