Design Decomposition

Check Your Design Decomposition

Use the Decomposition Matrix to see if you can improve your design decomposition or get some new ideas. This is a free service.

When you press Submit, you will go to the next page where you will complete the Decomposition Matrix. Also, on the next page, you can change the number of inputs and outputs, if needed.

Design in a Different Way

The Decomposition Matrix provides you with a way to think differently about the system you are designing -- and it might improve your design.

• If you would like more background on using the Decomposition Matrix, see the "Get Started" section below, the decomposition example in the Blog, and the entry for the Decomposition Matrix in the Wiki on this site.
• Use the Decomposition Matrix to create either a Business Process or Data Flow Diagram. These diagrams are used because they provide a generally understood visual vocabulary.
• The Decomposition Matrix is intended to augment existing methodologies. More on this below.

Four Possible Ways to Use the Decomposition Matrix

1. Create a initial decomposition: Sometimes the first-level decomposition is the hardest. Use the Decomposition Matrix to draft your initial decomposition.

2. Work through a problematic portion of a decomposition: Everyone gets stuck at one time or another. Use the Decomposition Matrix to see if the diagram it generates offers any new ideas for your decomposition.

3. Help gather requirements: The Decomposition Matrix can be used to gather a portion of your project's requirements. It can document which inputs are related to which outputs. You can then check those requirements by generating a diagram based on the Decomposition Matrix. If the diagram does not appear to make sense, then there is likely something wrong with the Decomposition Matrix. Therefore, something is likely wrong either with the requirements related to the relationships between the inputs and outputs in the matrix or you are missing inputs or outputs.

4. Validate an existing decomposition: Use the inputs and outputs of an existing diagram to set up a Decomposition Matrix. Then have users, technical people, managers, and anyone else involved in the project add checkmarks to the matrix. Have the group agree on a merged matrix. Generate a diagram based on the matrix and compare this to your existing decomposition. Sometimes this process brings out important details that were previously overlooked.

Please contact us if you have suggestions for other ways to use the Decomposition Matrix.

Augment Your Methodology

The Decomposition Matrix is intended to augment your existing methodology. For example, it is an easy way to involve subject-matter experts early in development without requiring them to learn any notation. Here are some other examples:

• Basic Business Process or Data Flow Modeling: This is the most obvious use of the Decomposition Matrix. You can use the Decomposition Matrix as part of whatever methodology you use for business process models or data flow diagrams. See the next section on ways to use the Decomposition Matrix.

• SOA Service Modeling: Thomas Erl describes service modeling starting on page 397 in Service-Oriented Architecture: Concepts, Technology, and Design. The Decomposition Matrix could assist with two steps in this modeling process. First, business process diagrams generated using the Decomposition Matrix could assist with the "Decompose business process" step. Second, data flow diagrams generated using the Decomposition Matrix could assist with the "Create business service candidates" step. See the Data Flow Diagram Example for Services in the Blog.

• Model Driven Architecture (MDA): The business process diagrams generated using the Decomposition Matrix could assist with the development of models in the Business Process Modeling Notation (BPMN) used as input to the Business Process Definition Metamodel (BPDM) as part of the Computation Independent Metamodel (CIM) in the Model Driven Architecture (MDA).

• Scrum: Scrum is intended for the management of software development projects, maintenance teams, and program management. Like the Decomposition Matrix, Scrum is agnostic about the software development methodology used. Scrum can be used with any methodology that may, at times, also use the Decomposition Matrix.

• Agile Techniques: The Decomposition Matrix could be used at any point to work through a decomposition problem as part of agile software development.

• Rational Unified Process (RUP): The Decomposition Matrix could assist with three disciplines in the Rational Unified Process. Business process diagrams generated using the Decomposition Matrix could assist with the requirements discipline and the business modeling discipline. Data flow diagrams generated using the Decomposition Matrix could assist with the analysis and design discipline. You would, of course, need to convert the data flow diagrams to Unified Modeling Language (UML) notation.

Can you suggest another methodology that can be augmented by the Decomposition Matrix? If so, please contact us.

Think of the Decomposition Matrix as a Helper

You should think of using the Decomposition Matrix as being much like having another designer help you work through a design issue at a whiteboard. The results may provide you with some new ideas or help you get past an issue that has you stuck. This service is not a design methodology. It is simply helps you with decomposition that you can, in turn, use with the methodology or development technique of your choice.

Get Started

To get started, you need to have some idea of the number of inputs and outputs for your design. This generally known as the design context. If you already know this, enter the number of inputs and outputs in the form near the top of this page.

The inputs and outputs for your context are used by the Decomposition Matrix. One aspect of the Decomposition Matrix is that it forces you to look at a problem differently. Instead of jumping to immediately drawing boxes or bubbles to describe a system, it requires that you to think about the inputs and outputs of a system and how those inputs and outputs relate to each other. This avoids the potential hazard of getting bogged down in drawing techniques or having to teach a visual vocabulary to users, managers, and other non-technical people involved in a design effort.

The Decomposition Matrix results are presented as either business process or data flow diagrams. The two presentations are representative of various diagramming techniques that show either sequencing of tasks or the flow of data:

• Business process diagrams are representative of techniques to show the sequencing of tasks.
• Data flow diagrams are representative of techniques to show the flow of data between processes.

The two types of presentations are meant to provide designers a visual vocabulary with which they are accustomed. One limitation of the Decomposition Matrix is that the information provided in the matrix precludes generating all the diagramming artifacts that a designer might use. The results do not show data sinks and sources, types of gateways, etc. Yet, the presentations are complete enough to help designers work through design problems. For most designers, the missing artifacts should be easy to add. Also, these diagrams can readily be translated by designers to other visual vocabularies such as UML swimlanes.

Background

The Decomposition Matrix is based on work done by Mike Adler in the late 1980s when we both worked in Corporate Research and Engineering at Control Data Corporation. Mike developed an algebra for design decomposition. I have implemented that algebra (with a few changes and enhancements) to analyze a Decomposition Matrix.

Finally, be advised that I am still tinkering with both the decomposition algebra and its implementation. Please let me know if you have any suggestions for improvement.

- Douglas K Barry

Decomposition

In software design and modeling, decomposition is the separation of a system into simpler or basic sub-systems. As many experienced designers know, it is often a difficult task to create an optimal decomposition of a system. It is often as much a people problem as a technical problem. An optimal decomposition requires gathering all the necessary requirements from people and then using those requirements to design the appropriate decomposition of systems and sub-systems. It is also often difficult to know if you have all the requirements. And, given you actually have all the requirements, it is difficult to create an optimal decomposition. See the discussion of design decomposition in the Wiki on the site for more on how the Decomposition Matrix can help with design decomposition.

Community

To help advance the understanding of software design decomposition, this site has three other features:

1. Blog: There you will find my thoughts, observations, and ideas about design decomposition and commentary on the state of the industry.
2. Wiki: This an ongoing effort to create a resource for using the Decomposition Matrix for design. In addition to my contributions, I am hoping other people in the design community will contribute to this Wiki. If you would like to contribute, contact us.