Function-Class Decomposition

I developed a rather common-sense methodology which I've been using for a number of years now (it's been documented on this website since October 1999, but it was developed in its original form in 1996. I'm gratified to learn that the approach actually has a name. The December 2001 issue (Vol.34 No.12) of Computer magazine (published by the IEEE Computer Society) describes something amazingly similar in an research feature entitled Function-Class Decomposition: A Hybrid Software Engineering Method. Except for differences in terminology and diagramming (the authors use a new diagramming method, whereas I stick with UML iconography that replaces my earlier use of Data Flow Diagrams and Entity Relationship Diagrams) the technique is the same.

In the simplest possible terms the technique is this: when engineering any system, object-oriented or not, design from the top down, Refine and implement from the bottom up.

After the publication of a truncated form of this letter, I was contacted by the authors of the Function-Class Decomposition article asking permission to use it on their website. This led to a gratifying exchange of correspondence which resulted in an invitation for me to join the SABRE Consortium, which I happily accepted.

Subject: Function-Class Decomposition
Date: Fri, 7 Dec 2001 16:11:29 -0500
From: Dave Leigh
To: computer@computer.org

To the Editor:

I read with great interest the research feature entitled "Function-Class Decomposition: A Hybrid Software Engineering Method." This is a method that cannot be touted highly enough. For those of us in the field it amounts to prior art, as we've been using it (under a different name) with great success for some years now. As long as I've been designing, whether object-oriented or not, the rule of thumb has been simply, "Design from the top down, refine and implement from the bottom up."

I'd like to point out a couple of areas where we are using techniques I think are useful to FCD, and which enhance the method.

First, I don't believe it's necessary to have an additional type of diagram as described by the authors. For some time now we've been doing top-down design using UML's package diagrams to represent functional modules (FMs). It is useful to define interactions between functional entities (represented by packages) choosing the rough message format and transport mechanism (i.e. "XML via socket") on the way down, and to define the details of the messages (i.e. schema) on the way back up. While it may be true that some UML diagramming tools do not facilitate top-down design in this manner, that is clearly a fault of the tools, not of the UML. It seems to me that while the diagramming method described in the article illustrates the heirarchy of functional modules, it does a poor job of illustrating their interactions. Frankly, in our experience it's as or more important to clearly illustrate the interactions between FMs as it is to illustrate the structural model. In any case, having seen the alternative I prefer the use of UML package diagrams for this purpose. (Of course, I endorse creative use of UML, and often represent UI elements as "classes" during Functional System Design in order to illustrate the operation of a proposed system to the users using UML sequence diagrams).

Second, I don't think you can sufficiently stress the need to normalize a design after the first pass at it. Redundancies are rarely a problem when a single individual does the design, but on large systems (where FCD shines) it's not uncommon to split the design work up once the high-level FMs are defined. A side effect of this is often redundant classes; so at some stage of your iterative process you need to set aside time to normalize your design, balancing redundancy with efficiency.

Finally, we've found that this approach -- even though it requires additional discipline -- can actually yield significant reduction in the time to design a moderate-to-large sized system over the purely OO iterative approach trumpeted for the past few years. Unfortunately we've been too busy meeting deadlines to objectively quantify the difference; however, here are some anecdotal reasons why you should see a positive benefit.

1. FCD allows you to return to the discipline of coding to a specification, which reduces the uncertainties of "scope creep."
2. Standard OO modeling works well on small projects, and FCD has the effect of breaking a large project into small ones, increasing the efficiency of the standard techniques. Each of these smaller "projects" is easier to estimate than the system-at-large, and easier to assign among developers.
3. In large systems, top-down design reduces the amount of interaction between designers necessary to bring any particular FM to operational status. At any level of iteration the amount of complex interaction should remain the same or less as you move from the bottom back up.

There are other reasons that I won't trouble you with in a letter. The major resulting benefit (in addition to those stated in the article) is that FCD greatly improves the ability of the project manager to estimate development costs of the overall project. Customers love kept promises. They pay for them, and come back to pay for more once you've demonstrated your ability to deliver.

Dave Leigh
Software Management Consultants, Inc.
dave.leigh@cratchit.org
http://www.cratchit.org

I won't reproduce an entire conversation here... for one thing, I have no desire to invade other people's privacy by publishing their words. But here's a response I gave to to Jane Huang's observation that my major critique of their method was in regard to notation (she didn't receive the entire text of the above letter until I forwarded it to her).

Quite frankly, I have no problems with your approach at all. The notation isn't central to the method. That's why when [the editors at Computer] cut it down "in the interest of space" I said go ahead and publish, but I asked them to pass the letter on to you. I just assumed that they'd give you the unexpurgated version. Silly me.

In reading your approach, I get a sense of coming home, because this is almost exactly what I do in practice (notation notwithstanding). I found that my last clients, who insisted on rigid conformance with their own methodology, didn't even notice that my development team followed what was basically FCD for the last four years. All they noticed was that we were consistently on or ahead of schedule and our team members were all uncommonly well versed in the overall system.

Of course, this last is simply due to the fact that the team got the overview early, and everything we did was a refinement of a system that we basically "designed" as a group in the first team session! (My P/As joke that I'd jump out of an airplane without a parachute because, "that's just a detail, it's not important yet." ). They're only half right. It probably is my signature quote, but every detail that's postponed is nonessential and is slated for design on the way back up. I like to think of it as "fractal design:" Every revision to the design exposes more detail without ever changing its overall shape.


The important thing to take away here is that FCD gets your team members involved early; gives them a good overview of the system; and maintains the overall structure even as details are added during bottom-up design. Since the bottom-up design has the top-down structure to use as a guide, modules can be designed more quickly as you have a greater understanding of how they will be fit into the final product; and you don't need all the details to get started. In my opinion, adopting FCD is the most effective methodology to couple with extreme programming (XP).