views:

1084

answers:

4

Functional Decomposition, what is it useful for and what are it's pros/cons? Where are there some worked examples of how it is used?

+14  A: 

Functional Decomposition is the process of taking a complex process and breaking it down into its smaller, simpler parts.

For instance, think about using an ATM. You could decompose the process into:

  1. Walk up to the ATM

  2. Insert your bank card

  3. Enter your pin

well...you get the point.

You can think of programming the same way. Think of the software running that ATM:

  1. Code for reading the card

  2. PIN verification

  3. Transfer Processing

Each of which can be broken down further. Once you've reached the most decomposed pieces of a subsystem, you can think about how to start coding those pieces. You then compose those small parts into the greater whole. Check out this Wikipedia Article:

Decomposition (programming)

The benefit of functional decomposition is that once you start coding, you are working on the simplest components you can possibly work with for your application. Therefore developing and testing those components becomes much easier (not to mention you are better able to architect your code and project to fit your needs).

The obvious downside is the time investment. To perform functional decomposition on a complex system takes more than a trivial amount of time BEFORE coding begins.

Personally, I think that amount of time is well worth it.

Justin Niessner
+2  A: 

Here's an example: your C compiler.

First there's the preprocessor: it handles #include and #define and all the macros. You give it a file name and some options and it returns a really long string. Let's call this function preprocess(filename).

Then there's the lexical analyzer. It takes a string and breaks it into tokens. Call it lex(string). The parser takes tokens and turns them into a tree, call it parse(tokens). Then there's a function for converting a tree to a DAG of blocks, call it dag(tree). Call the code emitter emit(dag), which takes a DAG of blocks and spits out assembler.

The compiler is then:

emit(dag(parse(lex(preprocess(filename)))));

We've decomposed a big, difficult to understand function (the compile function) into a bunch of smaller, easier to understand functions. You don't have to do it as a pipeline, you could write your program as:

process_data(parse_input(), parse_config())

This is more typical; compilers are fairly deep programs, most programs are broad by comparison.

Dietrich Epp
+2  A: 

Functional decomposition is a way of breaking down the complex problem into simpler problems based on the tasks that need to be performed rather than the the data relationships. This term is usually associated with the older procedure-oriented design.

A short description about the difference between procedure-oriented and object-oriented design.

Mark
+2  A: 

It's the same as WorkBreakDown Structures (WBS), mindMapping and top down development - basically breaking a large problem into smaller, more comprehensible sub-parts.

Pros

  • allows for a proactive approach to programming (resiting the urge to code)
  • helps identify the complex and/or risk areas of a project (in the ATM example, security is probably the more complex component)
  • helps identify ALL components of a project - the #1 cause of project/code failure (via Capers Jones) is missing pieces - things not thought of until late in the project (gee, I didn't realize I had to check the person's balance prior to handing out the $)
  • allows for decoupling of components for better programming, sharing of code and distribution of work

Cons - there are no real CONS in doing a decomposition, however there are some common mistakes

  • not breaking down far enough or breaking down to far - each person needs to determine the happy level of detail needed to provide them with the insight to the component without overdoing it (don't break down into programming lines of code...)
  • not using pre-existing patterns/code modules into consideration (rework)
  • not reviewing with clients to ensure the scope is correct
  • not using the breakdown when actually coding (like designing a house than forgetting about the plan and just starting to nail some boards together)
meade