General Axiomatic Design Concepts
Whether the design solution is a tangible product, service, software, process, or something else, designers typically follow these steps:
- Understand their customers' needs
- Define the problem they must solve to satisfy these needs
- Create and select a solution
- Analyze and optimize the proposed solution
- Check the resulting design against the customers' needs
The axiomatic design process guides designers through these same steps. They can use all of their existing design tools and software and efficiently arrive at a successful new design, or diagnose and correct an existing design.
There are four main concepts in axiomatic design:
- design axioms
The fundamental concept of axiomatic design is that of domains, one for each kind of design activity:
For each pair of adjacent domains, the left domain represents "what we want to achieve," while the right one represents the design solution of "how we propose to achieve it." The contents of each domain are:
||The benefits customers seek
||Functional requirements of the design solution
||Design parameters of the design solution
For example, in the customer domain, suppose the customer needs to preserve food. There are several means to accomplish this in the functional domain, such as canning, dehydrating, or cooling the food. From these choices the designer selects cooling and then decides on a refrigerator in the physical domain. The process domain describes how to manufacture the refrigerator.
Definitions associated with the domains in axiomatic design are:
||Functional requirements (FRs) are a minimum set of independent requirements that completely characterize the functional needs of the design solution in the functional domain.
||Constraints (Cs) are bounds on acceptable solutions.
||Design parameters (DPs) are the elements of the design solution in the physical domain that are chosen to satisfy the specified FRs.
||Process variables (PVs) are the elements in the process domain that characterize the process that satisfies the specified DPs.
Decisions in one domain are mapped into the domain on its right. In the earlier example, the need in the customer domain for preserving food was mapped into cooling the food in the functional domain, then this functional requirement was conceptualized as a refrigerator in the physical domain. This shows how the "What" in the left domain is mapped into the "How" of the right domain: Food preservation ("What") maps to cooling ("How"); in turn, cooling ("What") maps to refrigerator ("How"); and lastly, refrigerator ("What") maps into the manufacturing process ("How").
The mapping is represented by a design matrix which shows the relationships between FRs and DPs, and between DPs and PVs. This is an example of a design matrix:
An X or O in a cell indicates whether the column�s DP affects the row�s FR or not. In this matrix, DP1 affects all three FRs, while DP2 affects only FR2, and DP3 affects only FR3. Instead of a simple X or O, each cell can contain the mathematical relationship between the FR and the DP. Design matrices contain a wealth of information about the design and are central to the application of axiomatic design.
The second main concept of axiomatic design is hierarchies, which represent the design architecture. Beginning at the highest level, the designer selects a specific design by decomposing the highest-level FRs into lower-level FRs. This can be done once the highest level DPs are chosen. Decomposition proceeds layer by layer to ever lower levels until the design solution can be implemented. Through this decomposition process the designer establishes hierarchies of FRs, DPs and PVs.
Continuing the refrigerator example, the highest-level FR, FR1, is cooling the food. Since the highest-level DP is a refrigerator, the next-level FRs would be:
||Keep the food within a specified temperature range, T�DT
||Maintain a uniform temperature within the box
The third main concept of axiomatic design is zigzagging that describes the process of decomposing the design into hierarchies by alternating between pairs of domains. In the previous paragraph, FR1 (cooling food) decomposed into FR1-1 (keeping food within ?T) and FR1-2 (keeping temperature uniform). These lower-level FRs are valid only for the DP we chose, a refrigerator; if, instead, we had chosen to can the food, the lower-level FRs would be different. Therefore, the designer follows a procedure of zigzagging between the �What� and �How� domains to the lowest level of the hierarchies, as the arrows indicate in the figure above.
The fourth main concept is the two design axioms:
The Independence Axiom
|Maintain the independence of FRs: In an acceptable design, the DPs and the FRs are related in such a way that a specific DP can be adjusted to satisfy its corresponding FR without affecting other FRs.
The Information Axiom
|Minimize the information content: Among alternative designs which satisfy Axiom 1, the best has the minimum information content which means the maximum probability of success.
||Designs which do not satisfy the Independence Axiom are called coupled. An everyday example is a typical water faucet. The two FRs are "control the temperature" and "control the flow rate." The two DPs are the hot- and cold-water handles. This design is coupled because it is impossible to adjust either DP without affecting the other FR: Each handle affects both temperature and flow rate.
||Designs which satisfy the Independence Axiom are called uncoupled or decoupled. The difference is that in an uncoupled design, the DPs are totally independent, while with a decoupled design, at least one DP affects two or more FRs. As a result, the order of adjusting the DPs in a decoupled design is important. In the above example, the two FRs- "control the temperature" and "control the flow rate" are independent. One DP does not effect the other so this design is uncoupled.
Software Specific Concepts
Axiomatic Design applies equally well to software. In particular it develops a key principle of independence:
The goal of system design is to reduce the dependencies between subsystems, especially avoiding circular dependencies.
Let's look at the earlier familiar example that illustrates this issue, which applies equally well to software: the hot-cold faucet example.
Axiomatic technology uses easy to read maps to show how design elements affect the functions of the design. In these dependency maps, each column is a design element, while each row is a function. The cell shows whether the column's design element affects the function of that row: If so, the cell has an X, if not there is no X. According to theory, a design is independent - that is, contains no circular dependencies - when all the Xs are inside the triangle.
For water faucets, the desired functions are to adjust the flow rate and temperature of the water. This dependency map of the single-lever faucet shows that the up-and-down motion adjusts flow rate only, while side-to-side adjusts just the temperature. In contrast, both valves of the dual-valve design affect both flow rate and temperature, just as we said earlier. We can see in this map that the dual-valve design is not independent because one X is outside the triangle.
Dual knob faucet:
Lever arm faucet:
These principles apply to software. Let's look at this simple example to understand how this works.
Imagine an application that calculates results from a user's input and displays the result. The diagram above represents an architecture to solve this problem. The application is split into two logical routines: Main and GUI. The Main routine encapsulates the calculation routines and passes results to the GUI routine to be displayed. The GUI routine displays the calculation output and allows users to change inputs and drive the calculation functions in Main. Because the Main routine calls GUI functions and vice-versa, the code has a circular dependency.
Having identified a circular dependency, we should consider ways to remove it. One way to do this is to separate logically the calculation functionality from the user response functionality in Main. To do this, we can design a new interface, Listener, which encapsulates the user response functionality. Now, Main inherits this interface rather than implementing it directly. The resulting design and corresponding dependency map are shown here. As the diagram shows, this solution provides identical functionality as the previous solution, but no longer with circular dependencies since all the Xs are in the triangle. Of course, with this simple example we can see whether we have a circular dependency in the diagram, but imagine how difficult that would be in a complex application with hundreds of classes along with method and procedure calls. With this tool, we can recognize circular dependencies immediately even in very large applications.
When we reverse engineer the original design, we get this map showing the circular dependency between Main and GUI that we discussed earlier.
Development benefits result from this approach include:
- elimination of "spaghetti" code through the identification of a logical structure to define classes
- identification of the sequence to write objects for the shortest development time
- mapping business needs to specific code for documentation
- analyzing existing code to help with enhancements and maintenance
For more information, please contact us.