Axiomatic Design - Advances and Applications

Axiomatic Design – Advances and Applications

Axiomatic Design – Advances and Applications
by Nam Pyo Suh, Massachusetts Institute of Technology,
Oxford University Press, New York. Oxford, 2001, Chapter 5, pp. 239-298.

Chapter 5: Axiomatic Design of Software

5.1	Introduction
5.2	Axiomatic Design Theory for Software Design
5.3	Software Design Process
5.4	Axiomatic Design of Object-Oriented Software Systems
5.5	Axiomatic Design of Object-Oriented Software System for Designers: Acclaro Software
5.6	Design of Rapid-Prototyping Software for Real-Time Control of Hardware/Software System
5.7	An Ideal Software System
5.8	Other Issues Related to Software Design
5.9	Implications of the Information Axiom in Software Design
5.10	Summary
	References

5.1 INTRODUCTION

This chapter presents the design of software systems based on axiomatic design (AD) theory, distinct from specific programming languages or computer algorithms. It provides a framework for software design for all systems, including those that involve only software and those that involve both hardware and software. The framework for software design is based on the same set of principles and methodologies of axiomatic design that were presented for products, processes, and various systems in the preceding chapters. This framework provides a general approach to designing software and software architecture regardless of the specific computer language used for programming.

Software design based on axiomatic design is self-consistent, provides proper inter-relationship and arrangement among modules, and is easy to change, modify, and extend. This is a result of making correct decisions at each stage of mapping and decomposition.

The final design of software is represented by a flow chart that displays the entire system architecture of the software, which can aid software programmers. The flow chart can also be used as a management tool during the software development phase. It provides clear guidelines to software engineers engaged in a collaborative development effort and gives the order of execution of the resulting program. Extensionality and reusability at any level are guaranteed when the software design is based on axiomatic design theory. When a system consists of hardware and software, the system architecture defines the interface between the software modules and the hardware modules.

As a case study, the development of Acclaro¹ – a commercial software system to aid designers who use axiomatic design–is presented. This software design is based on axiomatic design and is implemented using a modified version of object-oriented techniques (OOT) and the Java programming language, a platform-independent language. The use of OOT was necessary because the use of Java requires OOT. When axiomatic design is used, OOT can be considerably simplified.

Many other case studies – software for ABS used in automobiles, design of television tubes – are presented to illustrate the application of axiomatic design in designing hardware/software systems.

What are the key issues in software programming? Software is now ubiquitous in our modern life-style. It has transformed the way people live, work, and think. Even the way consumers purchase a variety of goods is undergoing changes, as evidenced by the latest Wall Street excitement created by the Internet stocks and electronic commerce. Software has also changed the inner workings of organizations and the governance of nations. It has changed the industrial infrastructure, hotels, transportation, and education. It forms the core of many machines, systems, and organizations. Indeed when software crashes, the world comes almost to a standstill until the problems are fixed. All the frantic activity to deal with the Y2K bug is an indication of the importance of computers in all sectors of the economy.

Software performs important functions in many physical products. Software controls individual components of a machine as well as integrating and controlling all functions of a hardware system. In some large systems consisting of hardware, sensors, and software, the software is embedded among hardware components and also integrates the system functions. Smart weapons, automobiles, machines, airplanes, instruments, telecommunications, and space stations would not exist without software. Even the functions of ordinary products, such as toys, movies, and appliances, are controlled by software. Software has replaced many mechanical components to give lower cost products that are more flexible and intelligent. The software in engine management systems (EMS) regulates the performance of automobile engines and matches the impedance of engines with that of the automatic transmission.

In many companies, the hardware part of the system is developed first and then turned over to the software engineers to develop software code to make the system function. This process does not work well, causing delays in product introduction. This current practice is also costly because many debugging and field-service problems are associated with or caused by poor interface between hardware and software. These symptoms are the result of ad hoc, heuristic approaches to software design. In addition, more and more complex applications have become possible because computers have become faster, cheaper, and more powerful. As a consequence, computational efficiency has become less of an issue relative to the cost of developing software and the reliability of the software. This low productivity associated with software development can be attributed to the lack of a proper design procedure and basic decision-making criteria.

To meet the ever-increasing need for software systems for all of these diverse applications, the software industry has become the most rapidly growing industry in the United States. The demand for software engineers is far greater than the supply as we begin the twenty-first century. American companies routinely hire programmers from all over the world, especially India, China, Russia, and Korea. Indeed, software has become a global industry, in part driven by the need to reduce the labor cost of software programming. To increase the productivity of software development, a systematic means of creating and maintaining software through the use of a design theory must be implemented.

How can axiomatic design be used in software design? The axiomatic approach to software design is intended to overcome some of the known shortcomings of the current practice and create a scientific framework for software synthesis. In many respects, it differs significantly from various methodologies used in software engineering:

Its framework is based on the idea that the software must be designed first to satisfy a set of functional requirements and constraints before commencing coding activities. It also provides a methodology for design that includes the idea of mapping, decomposition, and the creation of leaves.
The most important aspect of axiomatic design is that it provides a rigorous means of decomposition and the criteria for acceptable software design. Therefore, it is explicit and thus simple. The flow chart–a consequence of axiomatic design – describes the precise relationship between all modules, and provides a complete description of the software architecture and the computational sequence.
The axiomatic design framework is equally applicable for all software designs, including (a) software that consists of only software modules, (b) software that controls both hardware and software, and (c) rapid prototyping software that allows modification based on current sensor input.
The axiomatic design framework is not field specific, i.e., it can be used in telecommunications, machine control, and others. The framework consists of all the elements of axiomatic design: the design domains, mapping, decomposition through zigzagging, creation of hierarchies, the design equation, the design axioms, and the design matrix. The additional elements introduced for system design in Chapter 4 are equally valid in software design: the creation of flow charts for software design, the concept of “leaf,” and specific characteristics of each domain.
The flow chart for system architecture is generated as a result of the existence of the axiomatic design framework – in contrast to a heuristic approach that depends solely on the intuitive ideas and skills of individual software programmers. The use of the flowchart enables a large collaborative effort as the role of each programmer is explicitly identified by the flow diagram.
Axiomatic design creates software for real-time control of systems in an explicit manner. Thus the software can be efficient, minimizing the information content of the system.
Axiomatic design is a good framework for modeling systems that consist of hardware and software because the design matrix defines the PR/DP relationship that needs to be modeled.
Axiomatic design allows reusability and extensionality of software modules in an explicit manner.

What is software? Software may be defined as an information transformer that generates certain desired outputs given a set of inputs and an algorithm for execution within the bounds established by constraints.

Software development has typically consisted of the following stages:

Analysis of the need and gathering of requirements, functions, data, tools, and various information
Design – abstract design of the software
Coding – creating programs according to the design
Debugging – correcting errors
Testing – site experiments
Maintenance – customer service after release
Extension – major extension of the developed software to add new functions and features

The cost of correcting and changing software escalates as the software is coded at lower and lower levels. Therefore, significant effort should be expended to design the software correctly and completely before undertaking any coding activity. Axiomatic design is a particularly powerful tool for design of complex software systems.

A historical perspective on software technology development. Once a software system has been designed, it has to be coded in a suitable programming language. Programming language has evolved over the years. A brief history of programming language at this time may be appropriate.

Most popular programming languages of the late 1990s use the object-oriented techniques (OOT). However, even the use of OOT and modular design does not guarantee reliable software unless the coding is preceded by axiomatic design of the software. In fact, because OOT does not have a fundamental basis for design, it has created many complicated ways of describing the design with many definitions, some of which describe variants of the same thing, e.g., class, object, and behavior. Apparently this is done because OOT does not have an explicit means of dealing with decomposition ofFRs and DPs as well as their relationships. In the following section, OOT will be described, followed by a slight modification of OOT based on axiomatic design to simplify the software structure.

OOT is the latest in the history of computer languages, which have evolved with changes in software design methodology. During the mid-1970s and 1980s, software designers used structured analysis and design techniques (SADT) to design software, and wrote code using BASIC, FORTRAN, and C programming languages (DeMarco, 1979; Ross, 1977, 1985). Commercial software products were generated using these languages, which were appropriate in representing the idea of SADT. However, it was difficult to reuse some of the modules created using SADT, as the attributes (i.e., programming variables) were used concurrently in various modules.² The global variables such as COMMON block in FORTRAN and Header file in C coupled the modules. Therefore, to reuse some of the modules that were developed previously, they had to bemodified. Consequently, reusability became a key issue, as it affected the productivity of software development.

Object-oriented methodology was introduced to overcome this limited modularity and productivity of SADT (Cox, 1986). However, OOT had remained merely a concept until programming languages such as C++ and Java were developed. In these programming

languages, the attributes and methods are combined together to act like an object in the real world. No global variables are used in C++ or Java.

C++ and Java are structured quite differently from older languages, such as FORTRAN and C. Knowing how to program in FORTRAN or C offers only minimal advantages when developing software with C++ or Java. In order to develop software products with C++ or Java, the programmer must know about objects, classes, and relationships as these languages are the only tools used to represent the object-oriented method. Objects, classes, and relationships structure the code itself. The Java language depends on object-oriented methodology.

Object-oriented techniques emphasize both the need to design software correctly during the early stages of software development and the importance of modularity. However, even with object-oriented techniques, there are many problems that software programmers face in developing and maintaining software over its life cycle. Although there are several reasons for these difficulties, the main reason is that current software design methodologies do not provide any criterion for good software design.

What are the current shortcomings? In software engineering, it is well known that software has to be created with independent modules (Pressman, 1997). However, an assembly of independent modules does not in itself constitute effective software. To be good, software must be designed with functional independence in mind to make the relationship between the modules effective and explicit without coupling. The axiomatic design framework ensures that the modules are in the right place in the right order.

Most software products require extensive debugging when they are first developed and also require extensive maintenance during the course of use both expensive propositions. When software must be modified or changed after the original programmer has left the organization, it is extremely difficult to understand the intention of the previous designer and to implement the changes. In fact, many software programs developed, especially with government money, cannot be used at all. To overcome these problems, we must make software engineering more of a science than an art.

What is the relationship between axiomatic design and object-oriented programming? A direct comparison of axiomatic design of software with the object-oriented programming is difficult. There are both similarities and differences. Axiomatic design enables the design of complex systems from the top down, whereas OOT is a bottom-up process. Axiomatic design requires a clear definition of FRs, as it divides the design tasks into domains and requires mapping between the domains for decomposition. Furthermore, the design matrix explicitly defines the relationships between sets of FRs and DPs. OOT mixes FRs and DPs.

Although OOT emphasizes modularity, not every combination of the separate modules constitutes an acceptable design, as some combinations may violate the Independence Axiom. OOT does not provide criteria as to how these objects can be combined to deal with design tasks that have many highest level FRs and how the modules should be related to ensure acceptable performance of the overall system. Perhaps the greatest shortcoming with object-oriented techniques is that the decomposition of the software has to be done in the heads of the programmers based on their experience, as they do not map or zigzag or write down resign equations. OOT can be very cumbersome when there are many objects that must be dealt with at the same time. It uses various words to describe variants of the same thing to deal with issues that arise from decomposition of the FR, DP, and PV hierarchies.

Notwithstanding these shortcomings, object-oriented techniques have been used extensively to develop software systems. OOT has been incorporated in existing commercial codes such as the Java language. Therefore, by combining axiomatic design theory with a modified version of OOT, we can develop practical, productive, and reliable software systems, using the OOT tools.³ This idea is explored further in Section 5.3.

5.2 AXIOMATIC DESIGN THEORY FOR SOFTWARE DESIGN

Is the design of software any different from the design of systems in general? From the axiomatic design point of view, a software system is a subset of system design, and in this sense, software design is not much different from the design of other systems discussed in Chapter 4. Axiomatic design of software is based on the Independence and Information Axioms, the existence of domains, mapping, decomposition through zigzagging, design axioms, the design matrix, and the creation of hierarchy. Several new ideas have been introduced to deal with system design, such as a leaf, the module-junction structure diagram, and the creation and use of a flow chart that defines the sequence of execution of the system. All of these ideas are equally valid in software design (Kim, Suh, and Kim, 1991; Do, 1998).

There are four domains in the software design world as shown in Figure 5.1. As discussed in Chapter 1, the relationship between the two adjacent domains is “what we want to achieve” and “how to achieve what we want to achieve.” The “what” is represented by the domain on the left and the “how” is represented by the domain on the right.

The specific characteristics of CAs, FRs, DPs, and PVs depend on the specific nature or goals of the software and the “what”/”how” relationship as shown in the following:

CAs: The user’s needs or customer attributes that the software program must satisfy.
FRs: The outputs, specifications, or requirements of a software system. FRs are “objects” in object-oriented programming.
DPs:

The inputs to modules in the case of pure algorithms. In the case of object-oriented programming, DPs can be treated as “data.”
Signal from hardware sensors and application-specific integrated circuits (ASICs) in the case of systems that involve both software and hardware.
Program code that generates input to the modules.

PVs:

Subroutines
Machine codes
Compilers

Modules: The row of the design matrix (DM) is a “module” that corresponds to “relationship” when the DPs are provided.

5.2.1 Review of the Axiomatic Design Process for Software

Are the steps involved in designing software any different from those for other systems? The steps involved in designing software are identical to those used in designing other systems discussed in Section 4.4, but require a different knowledge base or database (Suh, 1995, 1997, 1998). For completeness, these steps are reviewed here.

STEP 1
Define FRs of the Software System

The first step in designing a software system is to determine the customer needs (CAs) or attributes in the customer domain that the software system must satisfy. Then the functional requirements (FRs) and constraints (Cs) of the software in the functional domain are determined to satisfy the customer needs. The FRs must be determined in a solution-neutral environment . defining FRs without thinking about DPs (i.e., the “how” or the solution). FRs must satisfy the customer needs with fidelity. The FRs are defined as the minimum set of independent requirements that the design must satisfy.

STEP 2
Mapping between the Domains and the Independence of Software Functions

The next step in axiomatic design is to map these FRs of the functional domain into the physical domain by identifying the design parameters (DPs). DPs are “how” we are going to satisfy specific FRs. DPs must be so chosen that they are consistent with the constraints. Once the DPs are chosen, designers must go to the process domain and identify the process variables (PVs), which are the “how’s” with respect to DPs. PVs may be subroutines or machine codes or compilers.

Consider, for example, a decoupled software design at the leaf level that can be stated as:

FR₁ = Add FRs.
FR₂ = Delete FRs.

We are going to satisfy these FRs by developing two algorithms: an ADD algorithm and a DELETE algorithm. To achieve FR₁ (add FRs) by means of the software, we will choose DP₁ to be an input that triggers the ADD algorithm. Similarly, we will choose DP₂ to be an input that triggers the DELETE algorithm.In this case, DPs are physical descriptors or data that trigger some action that enables the modules to produce FRs. Therefore, DPs may be written as

DP₁ = Input that activates the ADD algorithm
DP₂ = Input that activates the DELETE algorithm

Then the design equation may be written as

A₂₁ is a nonzero element, because “Add FRs” must precede the need to “Delete FRs.” Equation (5.1) may also be written as

FR₁ = M₁ DP₁
FR₂ = M₂ DP₂(5.2)
where M₁ and M₂ are modules⁴ defined as

M₁ is the ADD algorithm and M₂ is the DELETE algorithm.

During the mapping process, the design must satisfy the Independence Axiom, which requires that the independence of FRs be maintained. FRs are, by definition, a minimum set of independent FRs. The Independence Axiom requires that the functional independence be satisfied through the development of an uncoupled or decoupled design. In an ideal design, the number of FRs is equal to the number of DPs as per Theorem 4. This is a consequence of the Independence Axiom and the Information Axiom. In choosing DPs, we must also be mindful of the Cs and the information content.

STEP 3
Information Content for Software Systems to Select the Best Design

There can be many software designs that are equally acceptable from a functional point of view if they satisfy the Independence Axiom. However, one of these designs may be superior to others in terms of the Information Axiom, which states that the one with the highest probability of success (i.e., the lowest information content) is the best design.

The Information Axiom requires the minimization of the information content. According to the Information Axiom, the design that has the least information content is the best design. The information content is defined in terms of the probability of achieving the FRs. The relative merit of equally acceptable designs that satisfy functional independence is determined by measuring their information contents. The Information Axiom is a powerful tool in identifying the best design when there are many FRs that the software must satisfy.

How do we measure the information content of a software system? Conventionally, the complexity of software programs is measured in terms of the number of lines of software code or the central processing unit (CPU) time, as the number of lines is a function of the number of layers of decomposition and the number of the highest level FRs of the software. Unfortunately, these are not absolute measures of the inherent complexity of the software program, as less skilled software designers may use more lines of software code than highly skilled designers would to achieve the same objective. We need a more absolute measure for complexity of the software program than either the number of lines of code or the CPU time.

In Chapter 1, complexity is equated with the information content, which is defined in terms of the probability of achieving the specified FRs.⁵ Thus, the design that has a lower probability of success is more complex and has a higher information content. This definition implies that two different software programs that satisfy the same highest level FRs equally well and have the same information content are equally complex, irrespective of the length of the software program. This defies common sense, as the shorter software program that uses less CPU time is likely to be faster and cheaper to use, although its information content is the same as that of a longer program. We may draw two conclusions from this. First, the longer software program is likely to have higher information content because the probability of making a mistake is greater as the length of the code increases. Second, the information content is not necessarily a measure of the efficiency or the cost of the computing, although there may be a weak inverse correlation between the efficiency and the information content.

Many software programs have “bugs,” which means that the FRs are not fully satisfied some of the time. Programs with bugs have a finite information content, as they cannot satisfy the FRs under all conditions. Such a program runs some of the time, but once in a while, it crashes because of bugs. In this case, the information content may be computed by determining the probability of the “up-time” of the program.

In some cases, there is no design range of an FR for a software program . either it fulfills the FR or it does not. That means that the information content is either zero or infinity. When the design range can be specified for an FR, the information content can be determined by whether the actual output of the software meets the intended functional requirements.

STEP 4
Decomposition of {FR}, {DP}, {PV}, and Software Modules

As discussed in Chapter 4, FRs, DPs, and PVs must be decomposed to the leaf level, where the design can be implemented without further decomposition. The programming then consists of coding the rows of a design matrix, which are called modules. When these modules are combined according to the flow chart or the module-junction diagram, we have the complete software system. This is discussed further in Section 5.5.

STEP 5
Object-Oriented Programming and the Modules for Leaves

At the leaf level, any software programming language, e.g., C++ or Java, can be used to write the modules as long as they are internally consistent. Java requires the use of object-oriented techniques.

STEP 6
Design Matrix and Module-Junction Diagrams

In Chapter 4, a “module-junction structure diagram” is presented as a means of representing the relationship between the modules. The summation junction, S, is used to represent an uncoupled design; the control junction, C, is used for the decoupled junction; and the F junction is used for a coupled design. The same notation system will be used for software design.

STEP 7
Flow Chart Representation of Software System Architecture

In Chapter 4, the concept of flow chart (sometimes called flow diagram) is presented as a means of representing system architecture. The flow chart consists of only the modules of leaves. Of the three different ways discussed in Chapter 4 of representing the system . the hierarchical trees, module-junction diagram, and the flow chart – the flow chart is the most convenient means of representing a software system. Based on the flow diagram, individual modules can be developed and linked to create a software system that can yield the highest level FRs.

STEP 8
System Control Command (SCC)

The flow chart also provides the software implementation scheme, which is simple and graphic. The flow chart shows the sequence of computation/operation of the software to achieve the highest level FRs. To operate the software, the operation must always begin from the innermost modules that represent the lowest level leaves in each major branch. Then we move to the next higher level modules following the sequence indicated by the system architecture.

The execution of the system architecture may be done using the system control command (SCC), which is sometimes called the system command and control module. The sequence of operation may be stated as follows:

Construct the lowest level modules of all branches. Multiply these modules with appropriate DPs (or make these modules operational byproviding DPs as inputs) to obtain lowest level FRs corresponding to “leaves.”
Combining these lowest level FRs according to the system architecture, obtain the next higher level FR. Repeat this process until the highest level module is obtained.
Execute this procedure simultaneously at all branches where such an action can be achieved independently so as to minimize the operational time.

Sometimes the inverse process may be necessary. When the highest level FRs and their tolerances are specified, the allowable values for the lowest level DPs can be determined. However, the sequence of the programming should follow the process described in this section.

5.2.2 Application of the Flow Diagram

The system architecture for the software represented by the flow chart can be used in many different ways, some of which are listed below:

Diagnosis of software failure – The failure of a complex software system can be diagnosed based on the system architecture. The flow chart should reduce the cost of maintaining the software system.
Software change orders – During the development process, it is inevitable that changes will need to be made. The system architecture and the flow diagram can be used to identify all the related modules that must be changed when a single change in the system architecture is proposed.
Job assignment and management of the software development team – The flow diagram can be used to organize development projects and to assign tasks to various participants, as it defines the interrelationships between various modules. This will aid in project execution and management.
Distributed systems – When a large development project is executed, the lower level tasks are often performed by various people including employees, subcontractors, and subsubcontractors, many of whom are located at remote locations. The flow diagram of the software system provides the road map by which various tasks can be assigned and coordinated.
Software design through assembly of modules – Ultimately, software must be designed by assembling existing software modules in a software database or knowledge base. The systems architecture can guide the software development process.
Systems consisting of hardware and software – When a complex machine is being designed, some of the modules are hardware and some are software. The flow diagram shows how the software and hardware must be integrated to enable the system to function as an integrated unit.
Interactive software program – When human operators interact with software, some of the modules in the system architecture must be performed by human beings. The human-machine interface can be defined clearly using the system architecture.

5.3 SOFTWARE DESIGN PROCESS

In this section, the software design process discussed in Section 5.2.1 is illustrated, using two simple examples.

EXAMPLE 5.1 Design of a Software System for a Library⁶

Consider the design of a software system for use by libraries. The task of the library software system is to assign a call number to a new incoming book, update the keyword database, and process a search query without missing any book that is relevant to the query.

Creation of the FR and DP Hierarchy

STEP 1
Establishment of the Highest Level FRs and Mapping in the Physical Domain

The following FRs of the library software system are established to meet the user’s needs:

FR₁ = Generate the call number and keyword database for new incoming books.
FR₂ = Provide a list of books that corresponds to subject keywords of a search query.

We must search for a DP₁ that can satisfy FR₁. Then we must select a DP₂ that satisfies FR₂ but does not affect FR₁ in order to create an uncoupled or at least a decoupled design. An appropriate set of DPs that satisfies the FRs may be chosen as

DP₁ = A classification system based on the content of the book
DP₂ = A search system based on the set of subject keywords

The design matrix at this level is a triangular matrix that indicates that the design is a decoupled design, i.e.,

where X represents a nonzero element.

STEPS 2 and 3
Zigzagging and Decomposition

Because the DPs at the first level are not detailed enough to provide the desired output, these FRs must be decomposed. For the design defined by the selected set of DPs, FR₁ may be decomposed into FR₁₁ and FR₁₂ as

FR₁₁ = Assign a call number (ID number) to a new book.
FR₁₂ = Generate subject keywords for the new book.

FR₂ is similarly decomposed as

FR₂₁ = Find relevant reference books.
FR₂₂ = Generate a list of relevant references in response to a request.

STEP 4
Mapping FR₁₁ and FR₁₂ to Lower Level DPs

The second-level DPs, DP₁₁ and DP₁₂, are now selected to satisfy the second-level FRs, FR₁₁ and FR₁₂, as

DP₁₁ = Information on the title information page of the book (field title, author, publisher, year, etc.)
DP₁₂ = The table of contents of the book

It should be noted that these DPs are inputs that enable the module to generate FR₁₁ and FR₁₂.

This library uses the Library of Congress Classification (LCC) system. The field, title, authors, and other headline information are the key inputs (DP₁₁) to the call number system that can classify and assign a number to a new incoming book (FR₁₁). Because the LCC system already exists as a subroutine in the designer’s database, FR₁₁ does not need to be decomposed any further.

FR₁₂ requires that the new book be registered in the keyword database for future search purposes. Atypical user does not have the exact information about the book being searched. Therefore, the user must generate a query with a series of most appropriate and commonly understood keywords that can properly represent the context of the book. Assuming the table of contents of the book has sufficient information about its contents, it is selected as DP₁₂. However, because DP₁₂ is not a complete design entity that can be implemented to satisfy FR₁₂ without further decomposition. Steps 6 and 7 must be taken.

Because the call number must be assigned before the keyword database is generated, DP₁₁ also affects FR₁₂. Thus, the design is a decoupled design with a triangular design matrix given by

STEP 5
Mapping FR₂₁ and FR₂₂ to Lower Level DPs

Effective DPs that can control FR₂₁ and FR₂₂, may be selected as

DP₂₁ = Number of keywords that describe the field of interest
DP₂₂ = String of keywords to find references that contain all of the relevant books

To process a search/query without missing any relevant book that corresponds to the query (FR₂₁), the query should consist of as many subject keywords as possible. However, a large number of keywords will generate a longer list of references that must be screened – a time-consuming task. Therefore, a cross-indexing method of search using a string of keywords connected by the Boolean operator OR is adopted here. This search selects the call numbers of books only in the common domain of the keywords when the keywords are connected by the OR operator. The cross-indexing method effectively reduces the size of the reference list, but may increase the probability of missing relevant references.

This mapping for FR₂₁ and FR₂₂ has resulted in a coupled design, which violates the Independence Axiom. Under a normal design situation, it is necessary to go back to the “drawing board” and search for an uncoupled design. However, to illustrate the use of the flow chart, the coupled solution will be used as part of this design solution. The design equation for this coupled design may be written as

STEPS 6 and 7
Decomposition of R₁₂

FR₁₂ (generate keywords for the new book) is decomposed for the selected DP₁₂ (the table of the contents of the book) as

FR₁₂₁ = Extract nouns in the table of contents to generate keywords for the new book.
FR₁₂₂ = Generate a cross-indexing keyword database.

The keyword database created from the table of contents should be rich enough not to miss any search query. This can be accomplished by putting every noun in the table of contents of the book into the keyword database. To reduce the size of the keyword list, we want to create a cross-indexing system. A synonym dictionary may be used to reduce the size of the keyword database to a small set by replacing the number of nouns extracted from the table of contents with a small set of key nouns. This synonym-based keyword database can be used later to retrieve the desired book by generating a new set of keywords before beginning the search. Then the selected set of DPs for FR₁₂₁ and FR₁₂₂ may be stated as

DP₁₂₁ = Nouns extracted from the table of contents
DP₁₂₂ = Synonym dictionary

The design matrix is triangular, indicating that we created a decoupled design.

The resulting design hierarchy is shown in Figure E5.1.a, which depicts the system architecture for the library system. This diagram, together with the design equation, is sufficient to describe the design of the software system.

Termination of Decomposition and a “Leaf”

When the decomposition process propagates down to lower levels, the design eventually reaches the leaf level, where one or more FRs can be fully satisfied (or controlled) by the selected set of DPs without further decomposition. The design process terminates when all of the lowest branches of the FR tree are leaves. In Figure E5.1.a, a leaf is shown as a bold-outlined box.

As defined in Section 4.6.2, a module is a row of the design matrix that generates an FR when it is multiplied by or supplied with a DP. Each FR leaf has one module of software that generates the FR given the input of DP. For example, FR₁₂₁ in Figure E5.1.a is generated when DP₁₂₁ is input to the module M₁₂₁. A module is an algorithm.

Based on this process of decomposition and development of uncoupled or decoupled designs, axiomatic design inherently ensures good modularity, because the design satisfies the Independence Axiom and the modules are generated from a diagonal or triangular matrix. Furthermore they contain less information than coupled designs.

It is often stated in the software field that “modularity” ensures a good software design. However, it should be noted that modularity itself does not guarantee a good software design if the Independence Axiom is violated.

A Flow Chart for the Library Software

Using the junction characteristics, the module-junction structure diagram can be easily converted to a flow chart diagram that shows the flow of data stream among modules and the sequence of execution. Figure E5.1.b shows the flow chart of the library software, which represents the system architecture of the software for the library system and has more information than the decomposed hierarchical trees of FRs and DPs shown in Figure E5.1.a. The flow chart diagram is based on the hierarchical tree structure of FRs and DPs and the design matrix. This diagram contains sufficient information to build the software system. Modules for FR leaves are program codes (i.e., algorithms) that can be constructed into a system to yield the specified FRs.

After the system architecture based on the axiomatic design of the software is completed, the programmers should then start creating program codes for each module. Then the modules can be combined to develop the main module that yields the final results upon execution.

Based on the flow chart shown in Figure E5.1.b, a software program can be developed using the object-oriented technique (OOT) discussed in Sections 5.4 and 5.5.

EXAMPLE 5.2 Design of Software for Design of a Rib in Injection Molding of Plastic Parts⁷

The axiomatic approach to software design for a library system has been described in the preceding section. To illustrate the concepts of axiomatic design for a manufacturing-related system, the design of a software system for injection molding of plastic parts will be described in this section.

Design Process

Consider the design of a molded part. The primary shape of an injection-molded part is usually designed by an application engineer to satisfy a set of FRs, including the desired external appearance. The moldability of the part and its mechanical performance are also considered separately based on the product design, which must be provided by a mold designer. Supplementary features are then added to the primary shape by experienced mold engineers to reinforce the structure, to facilitate the melt flow, and to supplement the FRs with additional FRs. Ribs and bosses are the typical supplementary features that are added to the primary shape of the injection-molded parts.

The major role of a rib structure is to enhance the structural rigidity of a plastic part while maintaining uniform wall thickness and minimizing the cycle time of the molding process. A rib can also play the role of a secondary runner that quickly delivers the polymer melt to the remote region where the slow filling may cause defects such as short shots, flow marks, and voids. A bad design of a rib structure may deteriorate the quality of the product by causing sink marks, warpage, short shot, and difficulty in removing the part from the mold. Therefore, the design task for a rib structure consists of the specification of reinforcing requirements, the choice of shape parameters to meet the reinforcing requirements and moldability, and the check of the procedure for molding defect-free parts. A software system needs to be developed that can assist mold designers to make the primary shape of a plastic part moldable and mechanically sound.

STEP 1
Establishment of the Highest Level FRs and Mapping in the Physical Domain

The customer needs may be mapped into FRs in the functional domain. The highest level FRs are

FR₁ = Specify the reinforcement requirement.
FR₂ = Generate supplementary geometry.
FR₃ = Check the performance of the reinforced structure by simulation.

The DPs that satisfy the FRs are selected as

DP₁ = Primary shape of the plastic part
DP₂ = Ribbed structure (core side)
DP₃ = Applied loads

The design matrix at this level is a triangular matrix, which indicates that the solution is decoupled.

At this level, it is recognized that once DP₁ and DP₂ are determined, then FR₃ becomes an FR leaf in the functional domain. FR₃ can be readily generated using a module M₃ that is a commercially available structural analysis software package (ANSYS is selected as M₃ in this case study). The module M₃ constitutes the row of the design matrix FR₁ and FR₂ need to be decomposed further as the selected DPs cannot finalize the design.

STEP 2
Second-Level Decomposition

To decide if reinforcement is required, the structural performance of the given primary geometry must be quantified under certain loading conditions. However, the loading conditions of most plastic parts are not prespecified explicitly, but are given so as to avoid the maximum allowable deflection of the lid plate or the possible stress concentrations at corners and handles, and so forth. Therefore, the use of a finite-element program for the complete structural analysis is not warranted at this time.

FR₁ (Specify the reinforcement requirement) is decomposed as

FR₁₁ = Characterize the structural performance of the primary geometry under implicit loading conditions.
FR₁₂ = Calculate the reinforcement requirements.

Depending on the shape of the part, the regions in which the maximum deflection or stress concentration occurs are identified by the designer, based on his or her experience (i.e., database). Likewise, the complex shape of the primary geometry can be characterized by a set of geometric elements in which simple structural formulas for thin plates and beams can be applied as the initial guess for the reinforcing requirements. In this study, three elementary geometric elements for the rib reinforcement are formulated-for example, a rectangular plate, a circular plate, and a curved beam-for which appropriate structural formulas are available in handbooks (for example, Orr, 1977). The selected DPs are

DP₁₁ = Elementary geometric elements
DP₁₂ = Structural formulas from the handbook

The resulting design matrix is triangular.

FR₂ is decomposed as

FR₂₁ = Generate ribs that do not adversely affect the manufacturability of the part.
FR₂₂ = Generate ribs that can meet the reinforcement requirements.

FR₂₁ can be satisfied only if both the DPs in the physical domain and the PVs in the process domain do not violate the Independence Axiom. Assuming that the PVs will be selected appropriately, the cross-sectional shape of the rib is the key input that controls FR₂₁. The number of ribs and their locations should be determined to meet the reinforcing requirements after the cross-sectional shape parameters are determined. This can be accomplished by determining the moment of inertia of the ribbed structure that is composed of a number of ribs of a certain cross-sectional shape to provide an equivalent stiffness to that of the reinforced structure of flat plate. This generates a decoupled design. The DPs that can control FR₂₁ and FR₂₂ are selected as

DP₂₁ = Cross-sectional shape of a rib structure
DP₂₂ = Number of ribs

The design equation is

At this level, it seems that FR₁₁, FR₁₂, and FR₂₂ can be satisfied by the selected set of DPs. These FRs form the terminal nodes of the FR hierarchy, from which the software modules for the FR leaves can be developed. However, FR₂₁ needs to be decomposed further as DP₂₁ is not sufficient to fulfill the design goal.

STEP 3
Third-Level Decomposition of FR₂₁

The manufacturability of ribs can be specified for ejectability, prevention of excessive warpage, and minimization of a sink mark that is a local dent formed on the surface opposite to the rib. FR₂₁ (Generate ribs that do not adversely affect the manufacturability of the part) is decomposed as

FR₂₁₁ = Avoid warpage.
FR₂₁₂ = Ensure ejectability.
FR₂₁₃ = Minimize sink marks.

The cross-sectional shape of a rib should be based on the process characteristics of injection molding. Cross-sectional parameters include the height, the root thickness, the fillet radius, and the draft angle. The wall thickness and the material to be injected are predetermined together with the primary geometry, and will act as constraints (Cs). For a given material and wall thickness, the cross-sectional parameters have design ranges in order to prevent jamming, warping, or sink mark formation. By considering the major causality between the defects and cross-sectional parameters, the following DPs are selected:

DP₂₁₁ = Rib height
DP₂₁₂ = Draft angle
DP₂₁₃ = Root thickness

However, the design matrix becomes coupled if the allowable warpage (given interms of tolerances) cannot be satisfied by the process.

Injection molding is inherently a coupled process between the flow and the solidification of polymer melts (Kirn and Suh, 1987). Therefore, it is very difficult to select DPs that can make the design matrix uncoupled or decoupled unless the tolerance is very large. In this case, the decomposition process must include zigzagging not only between the PR and DP domains but also between the DP and PV domains in order to yield the FRs through proper processing. Because of the coupled nature of the injection molding process, mold design for precision parts is done through trial-and-error processes. Often a compromised shape must be accepted as the Independence Axiom cannot be satisfied.

One way of handling this kind of problem (design for manufacture) is the use of the knowledge-based system. The Cs and expert knowledge are used to determine the cross- sectional parameters using an expert system module RIBBER (Jackson, 1975) and other equivalent programs. The expert system provides information on the cause of defects and acceptable cross-sectional geometry for the ribs. Such an approach will provide a compromised solution that may be acceptable in the absence of any uncoupled or decoupled solutions.

Module-Junction Structure Diagram

The hierarchical structures of FRs and DPs can be constructed based on the design Equations (a) through (d). The terminal nodes are formed when the selected DPs can satisfy the FRs. Figure E5.2 shows the module-junction structure diagram of the rib design software that represents both the hierarchical structures and design matrices.

It should be noted that because the injection molding process cannot be completely uncoupled, an expert system was used to obtain the most acceptable solution for FR₂₁. This coupled nature of injection molding limits its applications to geometry with large tolerances, which was solved recenty by the use of microcellular plastics (see Chapter 7). Based on the module-junction structure diagram, we can construct a software system.

EXAMPLE 5.3 Software Development for Design Automation for Glass-Bulb Design⁸

The task of this project was to automate the design process for the design and manufacture of television tubes for a large consumer electronics company (Do, 1997; Do and Park, 1996). The new software system by Do and Park has reduced the design cycle from 3 weeks to 6 hours by one designer. The secret behind their success was that they recognized a coupled process and developed a decoupled software system based on axiomatic design.

Design of the Software Architecture for Glass-Bulb Design

The glass bulb is a unit element of a TV tube, which is sometimes called a “Brown tube.” The tube consists of a shadow mask, an electron gun, aband, and a glass-bulb that consists of a panel and a funnel. The panel is the front part and the funnel is the rear part of the glass bulb shown in Figure E5.3.a.

Figure E5.3.b shows the top and section view of the picture tube and design variables of the panel. In the original manual design process, the radii are supplied by the customer, but the position dimensions (in italics) are established by the designer through a trial-and-error process to satisfy geometric compatibility. Similarly, Figure E5.3.c shows the top and section view of the funnel section with design variables. As in Figure E5.3.b, the radii are supplied by customers, and the position dimensions (in italics) were determined by the designer through a trial-and-error process from a rough drawing. Therefore, in the original trial-and-error process, the designer needed a rough drawing, which was supplied by a CAD system.

The original manual design process consisted of several steps as shown in Figure E5.3.d. Step 1 is “Product Request,” which consists of receiving an order from a customer who supplies the basic specifications or drawings. Based on this information. Step 2 consists of generating a rough drawing using CAD software, which requires some information on the final shape. To achieve this goal, an approximate final shape has to be generated by connecting tangential points between curvatures and lines, thickness of some parts, etc. In Step 3, the three-dimensional shape of the tube is generated using a software program, which uses the output of Steps 1 and 2 as well as part of information generated by Step 5 -an iterative process. After the tube shape is generated, stress analysis is performed in Step 4. After the entire design specifications are determined, the final step (Step 5) generates the complete drawings. Some of this information is used in Steps 3 and 4, requiring iterations between Steps 2 through 5.

According to the original process of tube design, the designer gathers the basic design information, constructs the full product shape, conducts stress analysis, and generates the drawing. The functional requirements of this process are

FR₁ = Construct the basic.information of the product (Steps 1 and 2).
FR₂ = Establish the product shape.
FR₃ = Verify the mechanical characteristics of the product.
FR₄= Generate the product drawing.

If we analyze the original design process, the design parameters are

DP₁ = A set of basic data – those supplied by the customer (Step 1 of Figure E5.3.d) and the rough drawing generated by CAD software (Step 2 of Figure E5.3.d)
DP₂ = The three-dimensional shape structure (panel/funnel)
DP₃ = Loading condition on panel and funnel
DP₄ = A set of drawing data

The design equation for the highest level FRs is

Equation (a) states that the design is a coupled design, requiring many iterations and approximations. FR₁ (construct the basic information of the product) is influenced by DP₁ (basic specification data supplied by the customer) and DP₄ (rough drawing). FR₂ (establish product shape) is affected by DP₁ (basic specification data), DP₂ (three-dimensional shape structure), and DP₄ (rough drawing data). FR₃ (verify the mechanical characteristics of the product) is similarly affected by DP₁, DP₂, and DP₃ (loading conditions on the panel and funnel). FR₄ is controlled by DP₁, DP₂, and DP₄. This design equation shows that the design process is very complex (or has a high degree of uncertainty).

To overcome this shortcoming of the complex manual process discussed above. Do and Park adopted the axiomatic design approach to develop an improved and “automatic” design process. The decomposition process for glass-bulb design is described below.

STEP 1
Mapping at the Highest Level FR DP

First, FR₁ (construct the basic information about the product) was satisfied by the inputs from the customer (Step I shown in Figure E5.3.d). Thus, DP₁ is “a set of the specifications for the tube received from the customer.” Then Step 2 was eliminated by fulfilling FR₂ (establish the product shape) using a numerical analysis program that automatically generated the information that used to be incorporated in the rough drawing and estimating the three-dimensional shape structure-the new DP₂. Then to satisfy FR₄ (generate the product drawing), DP₄ became only the accessory data needed to complete the set of drawings. By making these changes, the design process became decoupled. Do and Park also created a database that contained all the design data and the bulb shape information. This database is a PV in the process domain.

To satisfy the FRs at the highest level, the new DPs are

DP₁ = A set of specifications supplied by the customer for the new product
DP₂ = The three-dimensional shape structure of the panel and funnel
DP₃ = Loading conditions on the panel and funnel
DP₄ = A set of accessory drawing data

The design equation is

The first-level design is a decoupled design, because the set of accessory drawing data does not affect the construction of the database (i.e., FR₁), the three-dimensional shape of the glass-bulb (i.e., FR₂), and the mechanical strength of the Brown tube (i.e., FR₃).

STEP 2
Decomposition by Zigzagging DP FR

Because the relationship between FRs and DPs at the highest level is not detailed enough to provide the desired output, decomposition of the FRs is required. For the design defined by the selected set of specifications (DP₁), FR₁ may be decomposed as

FR₁₁ = Assign an ID number to a new product.
FR₁₂ = Construct a set of data for a new product.

Similarly, FR₂ and FR₄ are decomposed as:

FR₂₁ = Check the curvature, panel flatness, and funnel axis profile.
FR₂₂ = Calculate the three-dimensional shape.
FR₂₃ = Consider the manufacturability.
FR₄₁ = Represent the shape of the product.
FR₄₂ = Display accessory of the drawing.

STEP 3
Second-Level Mapping FR DP

Having established the second-level FRs, we need to map them in the physical domain to find DPs. For FR₁₁ and FR₁₂, the second-level DPs are

DP₁₁ = Representative code of new product
DP₁₂ = A set of specific data for a new product

The design matrix is triangular, indicating that it is a decoupled design.

The lower level DPs for FR₂₁, FR₂₂, and FR₂₃ are

DP₂₁ = Inside/outside curvature for the product
DP₂₂ = Characteristic geometric equation for the product
DP₂₃ = A set of data for mold manufacture

The design equation indicates that the design is decoupled.

For FR₄₁ and FR₄₂, the DPs are

DP₄₁ = A set of data for product design
DP₄₂ = A set of data for accessory

This is an uncoupled design and therefore the design matrix is diagonal.

STEP 4
Zigzagging Back to the Functional Domain DP FR

FR₂₃ is decomposed based on the selected DP₂₃ as

FR₂₃₁ = Check the useful screen dimension for the panel.
FR₂₃₂ = Evaluate the ejectability.
FR₂₃₃ = Examine the deflection angle of a scanning line for the funnel.

STEP 5
Third-Level Mapping FR DP

The selected DPs for the decomposed FR₂₃ are

DP₂₃₁ = Distance of blending circle center position
DP₂₃₂ = Angle of the side wall
DP₂₃₃ = Inside curvature of the yoke part

This design is an uncoupled design.

Now the decomposition process is complete because the highest level FRs can be controlled by the DPs selected. The lowest level FRs of each decomposition branch are leaves of the hierarchical tree. Figure E5.3.e shows the PR and DP hierarchies and the decomposition process.

Module-Junction Structure Diagram

Based on the information provided by Figure E5.3.e and the design matrices of the glass-bulb presented in this section, the module-junction structure diagram may be constructed as shown in Figure E5.3.f. Each FR leaf in Figure E5.3.e can be transformed into an independent module. Each leaf can be executed independently and has separate input and output. FRs are the output of the software, and DPs are the key input or input files to the software that can control the corresponding FRs. The software code is a set of design matrices that transforms DPs to FRs at each level of the hierarchy. Each module can be utilized in different environments, which include operating systems, compilers, languages, and so forth. A module or a commercial software system can be programmed.

The Flow Chart Diagram for Software Architecture-Glass Bulb

Using the module-junction structure diagram of Figure E5.3.f, the flow diagram for the architecture of the glass-bulb design can be constructed as shown in Figure E5.3.g to illustrate the design sequence. As presented earlier, the design equation is represented at each node by either S for an uncoupled design or C for a decoupled design. Figure E5.3.g represents the complete software architecture developed using axiomatic design. Once Figure E5.3.g is finalized, the software engineer does not have to know anything about the development of the FR and DP hierarchies to develop the software. It should be noted that the larger module M₁ is constructed from M₁₁ and M₁₂, etc. The final design objective is achieved through four modules. M₁, M₂, M₃, and M₄ that relate DP₁ to FR₁, DP₂ to FR₂, DP₃ to FR₃, and DP₄ to FR₄, respectively.

Software Development for a Glass Bulb

A system that can automatically design the glass-bulb system has been developed based on the flow chart diagram shown in Figure E5.3.g. The structure of the program is shown in Figure E5.3.h. The sequence of execution is controlled by the graphic user interface (GUI). Each major module (M₁, M₂, M₃, and M₄) is shown as a bubble in Figure E5.3.h. Each module can be a developed program, commercial software, or a combination of the two.

The GUI controls the glass-bulb design process shown in Figure E5.3.h. Do and Park (1996) used an X-Window (MOTIF) system, which is a standard graphics tool in a UNIX operating system.

The M₁ module deals with data generation. To reduce the programming effort. Do and Park used commercial software called ORACLE. The SQL language is supported for the transaction commands in the ORACLE database.

Do and Park developed a module for three-dimensional shape generation. The shape-generation module uses geometric interrelations and some specific numerical analysis algorithms. From the design variables, the geometry of the glass bulb is constructed by module M₂.

The strength analysis module M₃ is used to determine the strength of the tube using fracture theory for brittle materials after the three-dimensional shape has been generated by M₂. Special mesh generation routine is used to compute the stress distribution in the bulb. Commercial software can be used for this purpose. If the results of the stress analysis cannot be accepted, the designer can go back to the 3-D shape-generation algorithm to repeat the process, which is indicated by the dotted line in Figure E5.3.h. Do and Park used ANSYS, a commercial algorithm, to determine the stress.

The last module is the drawing module M₄. A commercial package was used to produce the drawing, which could interface with other programs.

In addition to these modules. Do and Park also used a commercial graphic library to confirm the shape of the glass bulb during the design process.

5.4 AXIOMATIC DESIGN OF OBJECT-ORIENTED SOFTWARE SYSTEMS ⁹

In this section, the development of a software system based on axiomatic design and the object-oriented programming technique is presented. This Axiomatic Design of object-oriented Software Systems (ADo-oSS) is a major new paradigm shift in the field of software engineering. It combines the power of axiomatic design with a popular software programming methodology called the object-oriented programming technique (OOT). The goal of ADo-oSS is to make software development a subject of science rather than an art and thus reduce or eliminate the need for debugging and extensive changes.

In software engineering, it is well known that software should be developed or written with independent modules.¹⁰ However, a collection of modules can also lead to coupling of functions as will be evident when the details of software design methodology are presented later in this section. Furthermore, the decomposition of software is often done in the heads of the programmers, based on their experience, as they do not explicitly define FRs, or map, or zigzag, or write down design equations. Therefore, the use of separate modules does not in itself generate uncoupled software design. To have good software, the relationship between the modules must be designed to make them work independently and explicitly. These shortcomings can be overcome by designing software first based on axiomatic design.

The AD framework ensures that the modules are correctly defined and located in the right place in the right order. A “V model for software” will be used here to explain the concept of ADo-oSS.¹¹ The first step is to design the software, build the software hierarchy that follows the top-down approach of axiomatic design, and then generate the full design matrix table to define modules. The final step is to build the object-oriented model with a bottom-up approach, following the AD flow chart for the designed system. Figure 5.2 schematically represents the concept.

The right side of the V model shown in Figure 5.2 can be used with any software design methodology, e.g., SADT. However, the object-oriented method is used in most commercial software products, which exclusively use C++ or Java. Before we discuss the details of ADo-oSS, the essence of the object-oriented technique is reviewed in Section 5.4.1.

5.4.1 Object-Oriented Techniques¹²

In this section, OOT is introduced without any modification. In Section 5.4.2, OOT will be modified to make it simpler and consistent with axiomatic design. One of the difficulties associated with learning object-oriented techniques (OOT) is the definition of keywords that describe the method. Too many keywords are used to describe the same thing because OOT cannot deal with the hierarchical nature of design and the decomposition through zigzagging between the domains in a systematic manner. In this section, OOT will be described by using the keywords used in OOT and also by providing equivalent terms used in axiomatic design, where appropriate, to facilitate the learning process.

Object-oriented methodology (OOM) is a conceptual process that is independent of any programming language until the final stage. This is a formal method of creating a software structure and abstraction, helping designers to express and communicate abstract concepts. The fundamental construct for the object-oriented method is the object,¹³ which is equivalent to an FR. Object-oriented design decomposes a system into objects. Objects “encapsulate” both data (equivalent to DPs), and method (equivalent to relationship between FR_i and DP_j, i.e., module) in a single entity. An object retains certain information on how to perform certain operations, using the input provided by the data and the method imbedded in the object. In terms of axiomatic design, this is equivalent to saying that an object is [FR_i = A_ij DP_j]. A graphic representation of object is shown in Figure 5.3.

Object-oriented design generally uses four definitions to describe its operations: identity, classification, polymorphism, and relationship. Identity means that data – equivalent to DPs – are incorporated into specific objects. Objects are equivalent to an FR with a specified [FR_i = A_ij DP_j] relationship, where DPs are data or input and A_ij is a method ora relationship. In axiomatic design, the design equation explicitly identifies the relationship between FRs and DPs.

Classification means that objects with the same data structure (attributes) and behavior (operations or methods) are grouped into a class. The object is represented as an instance of a specific class in programming languages. Therefore, all objects are instances of some classes. A class represents a template for several objects and describes how these objects are structured internally. Objects of the same class have the same definition both for their operations and for their information structure. There are two types of object diagram: class diagram and instance diagram. A class diagram is a schema, pattern, or template for describing many possible instances of data. An instance diagram describes how objects relate to each other. A class diagram describes object classes. An instance diagram describes object instances. Figure 5.4 illustrates the concept graphically.

An object is linked to other objects through messages, which require an object to perform certain functions by executing a method (i.e., algorithm). The object performs the function using the internal operations that may not be apparent to other objects-equivalent to the elements of the design matrix that link specific FRs to specific DPs.

Sometimes an object is also called a tangible entity that exhibits some well-defined behavior. Behavior is a special case of FR. The relationship between objects and behavior may be compared to the decomposition of FRs in the FR hierarchy of axiomatic design. Object is the parent FR, relative to behavior, which is the child FR. That is, the highest level FR among the two layers of decomposed FRs is “object” and the children FRs of the object FR are “behavior.”

Polymorphism means that the same operation may behave differently on different classes, and, therefore, two or more classes of objects may respond to the same message each in its own way. The move operation, for example, may behave differently on the Window and Chess-Piece classes.

Relationship describes the interactions between objects or classes. It can be of the following types, as shown in Figure 5.5 (Rumbaugh et al., 1991).

The relationships between objects and classes are established by means of links and associations (Rumbaugh et al., 1991; Booch, 1994). A link is a physical or conceptual connection between objects. An association represents a group of bidirectional links with common structure and common semantics.

Aggregation refers to the “part-whole” or “a-part-of” relationship in which objects represent the components of an object that represents the entire assembly (Rumbaugh et al., 1991; Booch, 1994).

Sharing similarities between classes while preserving their differences is encapsulated in generalization and inheritance. Inheritance allows the conception of a new class of objects as a refinement of another and abstraction of the similarities between classes [Wirfs- Brock, Wilkerson, and Wiener, 1990). Generalization defines the relationship between a class and one or more refined versions of it. The superclass is the class being refined, and a subclass is a class that inherits behavior from another class, which is a refined version of superclass. Attributes and operations common to a group of subclasses are attached to the superclass and shared by each subclass, which inherits the features of its superclass. Generalization and inheritance are transitive across an arbitrary number of levels.

The following software design sequence describes the object-oriented technique based on these concepts:

Define the problem or task.
Identify objects and their attributes and input data.
Identify operations that may be applied to objects.
Establish interfaces by showing the relationship between objects and operations.
Repeat Steps 1, 2, 3, and 4.

Steps 2 and 3 are summarized as class definition, sometimes called modeling or analysis. Step 4, called the design step, utilizes many diagrams, such as the data flow diagram and the entity relation (ER) diagram to realize the relationships. As shown in Figure 5.6, the object diagram is generated when all these steps are finished. It is really difficult to tell whether the design is good from an object diagram because no design-verification criterion exists, which is a shortcoming of OOT.

Figure 5.6 describes the following:

Each box is a class or an object. The top section of the box (e.g.. Box in the left top box of the figure) is the name of the class, the middle section of the box (e.g., text in the figure) describes the attributes of the class, and the bottom section of the box (e.g., cut) defines the operations of the class.
An object is represented as an instance of a specific class (e.g., object Box is an instance of Box class). However, sometimes each box in Figure 5.6 may be called an object.
Object Link has two relationships with the attributes of object Box.
Object Collection is an aggregation of the attribute of Box and the operation of Link with many relationships. That is, object Collection can have many Box and Link objects.
Object Collection is the superclass of subclasses Selection, Buffer, and Sheet.
Object Drawing, which has a relationship with object Drawing file, can have many Sheet objects.
Object Link is an aggregation of object Line segment, which in turn is an aggregation of object Point. That is, object Line segment is a part of object Link with many relationships.

5.4.2 Modified OOT for Compatibility with Axiomatic Design

The distinction between superclass, class, object, and behavior is necessary in OOT to deal with FRs at successive layers of a system design. In OOT, class represents an abstraction of objects and thus is at the same level as object in the FR hierarchy. However, object is one level higher than behavior in the FR hierarchy. The use of these keywords, although necessary in OOT, adds unnecessary complexity when the results of axiomatic design are to be combined with OOT. Therefore, we will modify the use of these keywords in OOT.

We will use one keyword “Objects with indices” to represent all levels of FRs, i.e., class, object, and behavior. For example, class or object may be called Object i, which is equivalent to FR_i. Behavior will be denoted as Object ij to represent a second-level FR_ij. Conversely, a third-level FR_ijk will be denoted as Object ijk. Thus, Object i, Object ij, and Object ijk are equivalent to FR_i, FR_ij, and FR_ijk, respectively, which are FRs at three successive levels of the FR hierarchy.

To summarize, the equivalence between the terminology of axiomatic design and that of OOT may be stated as follows:

FR can represent an object.
DP can be data or input for the object, FR.
The product of a module of the design matrix and DP can be a method, i.e., FR = A . DP.
Different levels of FRs are represented as objects with indices, that is, FR_i, FR_ij and FR_ijk are equivalent to Object i, Object ij, and Object ijk, respectively.

5.4.3 Basics of Axiomatic Design of Object-Oriented Software Systems

The axiomatic design of object-oriented software system (ADo-oSS) shown in Figure 5.2 involves the following steps:

STEP 1
Define FRs of the Software System

The first step in designing a software system is to determine the customer attributes in the customer domain that the software system must satisfy. Then the functional requirements (FRs) of the software in the functional domain and constraints (Cs) are established to satisfy the customer needs. FRs must satisfy the customer needs with fidelity.

STEP 2
Mapping between Domains and the Independence of Software Functions

The next step in axiomatic design is to map these FRs of the functional domain into the physical domain by identifying the DPs. DPs are the “how’s” that satisfy specific FRs of the design. DPs must be chosen to be consistent with the constraints. During the mapping process, the design must satisfy the Independence Axiom, which requires that functional independence be maintained throughout the development of an uncoupled or decoupled design. A design matrix is used for this evaluation.

STEP 3
Decomposition of FRs, DPs, and PVs

The FRs, DPs, and PVs must be decomposed until the design can be implemented without further decomposition. These hierarchies of FRs, DPs, PVs, and the corresponding matrices represent the system architecture. The decomposition of these vectors cannot be done by remaining in a single domain, but can be done only through zigzagging between domains. This is illustrated in Figure 5.7. From FR₁ in the functional domain, the designers go to DP₁ in the physical domain. Then the designers return to the functional domain to generate

FR₁₁ and FR₁₂ that collectively satisfy the highest level FR₁ and the corresponding DP₁. Then the designers move to the physical domain to find DP₁₁ and DP₁₂ which satisfy FR₁₁ and FR₁₂, respectively. This process continues until the FRs can be satisfied without further decomposition. Each terminal FR and DP (those that are not further decomposed) is called a “leaf” in the tree structure.

As stated earlier, the software design methodology that was favored in the mid-1970s and 1980s uses similar decomposition with the top-down approach. As shown in Figure 5.8, structured analysis and design technique (SADT) is a well-known example (Ross, 1977, 1985; Marca and McGowan, 1988). However, SADT decomposition is conducted only in the physical domain from an axiomatic design viewpoint. Because of this nonzigzagging process, there is no guarantee of functionality or productivity. Therefore, those methods faded away as the requirements for software systems increased and the object-oriented method was introduced.

STEP 4
Definition of Modules – Complete Design Matrix

One of the most important features of the AD framework is the design matrix, which provides the relationships between the FRs and the DPs. For software creation, the design matrix provides two important bases. One important basis is that each element in the design matrix can be a method (or operation) in terms of the object-oriented method. The other basis is that each row in the design matrix represents a module to satisfy a specific FR when a given DP is provided. In most cases, the off-diagonal terms in the design matrix are important as the coupling comes from these off-diagonal terms. However, it is possible to avoid coupling with a proper sequence of change if the design matrix is triangular – a decoupled design.

As illustrated in Figure 5.9, it is important to construct the complete design matrix based on the leaf-level FR-DP-A_ij to check for consistency of decisions made during decomposition. In Figure 5.9, the decomposition of FR_x.2 shows a relationship between DP_x.2.3 and FR_x.1, whereas before decomposition, it was decided that there is no relationship between FR_x.1 and DP_x.2. Designers must check for the consistency of every layer of the design hierarchy to make sure that the design decisions are made correctly at every step of decomposition (Baldwin, 1994; Tate, 1999; Kirn, Suh, and Kirn, 1991). If an off-diagonal term is shown in a lower level matrix, contrary to the higher level matrix, the designer must correct this inconsistency by checking the FRs, DPs, design matrices, and Cs.

STEP 5
Identify Objects, Attributes, and Operations

Because all DPs in the design hierarchy are selected to satisfy FRs, it is relatively easy to identify the objects. The leaf is the lowest level object in a given decomposition branch, but all leaf-level objects may not be at the same level if they belong to different decomposition branches. Once the objects are defined, the DPs (attributes or data) and products of modules with DPs (operations or methods) for the object should be defined to construct the object model. This activity should use the complete design matrix table.

EXAMPLE 5.4 Software Design for a Simple Line Drawing Program¹⁴

Design a software program that can draw a straight line. Translate the resulting axiomatic design into the object-oriented method.

SOLUTION

The highest level FRs may be stated as

FR₁ = Define line element.
FR₂ = Detect the drawing location.
FR₃ = Draw the line element through the window.

The corresponding DPs are selected as

DP₁ = Line characteristic
DP₂ = Mouse click information
DP₃ = GUI for the drawing

The design matrix may be written as

The FRs and DPs may be decomposed as follows:

Second Level for FR₁

FR₁₁ = Define start.
FR₁₂ = Define end.

DP₁₁ = Start point
DP₁₂ = End point

The design matrix may be written as

Second Level for FR₂

FR₂₁ = Detect mouse push.
FR₂₂ = Detect mouse release.

DP₂₁ = Event for push
DP₂₂ = Event for release

The design matrix may be written as

Second Level for FR₃

FR₃₁ = Prepare the drawing environment.
FR₃₂ = Draw the line.

DP₃₁ = Window type
DP₃₂ = Graphics information

The design matrix may be written as

The above design can be put in OOT format as shown in Table E5.4. The top box of the four-tiered object box in Table E5.4 is for the name of the object for each of the FRs. The second boxes are for the second-level FRs, i.e., FR₁₁, FR₁₂, FR₂₁, etc. (in OOT, these were called behaviors). The data, which are DP₁₁, DP₁₂, and so on, are in the third-tier boxes. The fourth-tier boxes are for methods (or operations), which are a^*DP₁₁, b^*DP_12,and so on. We can keep the parent-level relationships (i.e., FR₁–A₁₁-DP₁, FR₂–A₂₂-DP₂, and FR₃–A₃₃-DP₃) in a library for future use; this ensures reusability as each one of these relations reveals the fundamental object structure.

TABLE E5.4 Two Different Levels of Objects

	Object 1 (for FR₁)		Object 2 (for FR₂)		Object 3 (for FR₃)

Second-level objects (behavior in OOT)	Object 11 (for FR₁₁: Define start	Object 12 (for FR₁₂: Define end	Object 21 (for FR₂₁: Detect mouse push	Object 22 (for FR₂₂: Detect mouse release	Object 31 (for FR₃₁: Prepare the drawing environment	Object 32 (for FR₃₂: Draw the line
Attribute or data	DP₁₁: Start point	DP₁₂: End point	DP₂₁: Event for push	DP₂₂: Event for release	DP₃₁: Window type	DP₃₂: Grahics information
Operation or method	a^*DP₁₁	b^*DP₁₂	c^*DP₂₁	d^*DP₂₂	e^*DP₃₁	f ^DP₃₁ + g^DP₃₂

We will name the sets (FR₁–A₁₁-DP₁), (FR₂–A₂₂-DP₂), and (FR₃–A₃₃-DP₃) as Object 1d for FR₁, Object 2d for FR₂, and Object 3d for FR₃, respectively. The “d” is added to the object number to denote the fact that they represent only the diagonal element.

We now have to take care of the off-diagonal terms. This can be done if we name (FR₃–A₃₁-DP₁ / FR₃–A₃₂-DP₂) as Object 3^* for FR₃^*. The asterisk is used to denote the off-diagonal elements. Then FR₃ is “Object 3 for FR₃,” which is an “aggregate” of Object 3d for FR₃ and Object 3^* for FR₃^*. This can be represented in terms of the OOT notation, as shown in Figure E5.4.

The complete design matrix with FRs and DPs can be translated into the OOT structure, as shown in Figure 5.10. This is illustrated further in Figure 5.11. The FRs are equivalent to objects and the DPs are equivalent to data.

STEP 6
Establish Interfaces by Showing the Relationships between Objects and Operations

Most efforts are focused on this step in the object-oriented method as the relationship is the key feature. However, it lacks information about functional relationships because the relationship is represented only by lines between objects (or classes) as shown in Figure 5.12. To overcome this lack of information, the Axiomatic Design methodology presented in this chapter utilizes the off-diagonal elements in the design matrix as well as the diagonal elements at all levels. A design matrix element represents a link or association relationship between different FR branches that have totally different behavior. All of these concepts are illustrated in Figure 5.12 for the case of Figure 5.11.

STEP 7
Construct the System Architecture of the Software System

One of the advantages of the AD framework is that it represents the interrelationships between modules in the design hierarchy. To represent the properties of junctions at each level of decomposition, a “module-junction structure diagram” is defined (see Chapter 4). The module-junction structure diagram shown in Figure 5.13 is for the design given by Equation (5.4).

It should be noted that the higher level modules are obtained by combining lower level modules. For example, by combining modules M₁₂₁, M₁₂₂, and M₁₂₃ with a control junction (C), we obtain the next higher level module M₁₂. Then M₁₁ and M₁₂ are combined to obtain M1 using a control junction (C) again. M₁ and M₂, although not shown because they are not leaves, are simply summed as indicated by the symbol “S.”

When the AD framework is used, the entire process can be clearly shown by a flow chart that represents the system architecture, which was discussed in Chapter 4. Figure 5.14 shows the final flow diagram for the design represented by Equation (5.4).

The sequence of software development begins at the lowest level, which is defined as the leaves. To achieve the highest level FRs, which are the final outputs of the software, the development of the system must begin from the innermost modules shown in the flow chart that represent the leaves. Then move to the next higher level modules (next innermost box) following the sequence indicated by the system architecture; that is, go from the innermost boxes to the outermost boxes. In short, the software system can be developed in the following sequence.

Construct the core functions using all diagonal elements of the design matrix.
Make a module for each leaf FR, following the sequence given in the flow chart that represents the system architecture.
Combine the modules to generate the software system, following the module-junction diagram.¹⁵

When this procedure is followed, the software developer can reduce the coding time as the logical process makes software construction a routine operation. It also guarantees minimal effort for maintenance or extension if either is required in the future. These points are further clarified through the case study described in Section 5.5.

5.5 AXIOMATIC DESIGN OF OBJECT-ORIENTED SOFTWARE SYSTEM FOR DESIGNERS: ACCLARO SOFTWARE¹⁶

5.5.1 Introduction

In Section 5.4, the basic concept of designing software based on axiomatic design of object-oriented software systems (ADo-oSS) was presented. In this section, a case study involving the design of a large, commercial software package based on ADo-oSS will be presented. The software – called Acclaro¹⁷ – an interactive, general-purpose software package for designers who practice axiomatic design. The Acclaro software, which means “make clear” in Latin, was developed very quickly because the (ADo-oSS) methodology was used in developing the software. The entire software package has many layers of decomposition with about several hundred FRs and DPs. For obvious reasons, only a limited portion of the software design will be discussed in this section.

The Acclaro software was designed to aid designers in their design tasks. The software can be used to design a variety of different things in many different fields, including hardware, software, organizations, strategic plans, processes, systems, and products. The ultimate output of the software is a design that satisfies the PRs and Cs. The designer provides inputs to the software, such as the FR, DP, and PV vectors, when prompted by Acclaro software. The designer then answers questions on the relationships between these characteristic vectors, again prompted by the software. Based on these inputs, Acclaro creates design matrices and helps the designer make correct design decisions. It also prompts the designer when a mistake is made, based on various theorems of axiomatic design. The final outcome of the software is the system architecture, which is represented in the form of the {FR}/{DP}/{PV} tree diagram, the module-junction diagram, and the flow diagram. The Acclaro software also generates the final design documentation.

5.5.2 Axiomatic Design of Acclaro Software

Acclaro software was developed top-down as shown in Table 5.1. A constraint is that the software must be independent of specific operating systems and run on many computers without change or modification. Therefore, the Java language was chosen as the programming language. These top-level FRs and DPs are decomposed until the design task is completed.

The desired first-level FRs of the software are described in Table 5.2. A group of customer attributes, which are listed in Table 5.3, provides the basis for generating the first-level FRs.

TABLE 5.1 Top-Level Decomposition of Acclaro

FR₁		Make a decision-making tool which has impact on the design world
DP₁		Computerized system with the Axiomatic Design software
C		Independent of the operating system

TABLE 5.2 First-Level Decomposition of Acclaro

	Functional Requirements	Design Parameters
	FR_1.x	DP_1.x

P	Make a decision-making tool which has impact on the design world	Computerized system with the axiomatic design software
1	Manage design workflow	Design roadmap
2	Provide decision-making environment	Provide decision-making criterion
3	Support ease of use while using software	Graphic user interface (GUI)
4	Provide efficient data I/O	Data manager
5	Provide utility function	Plug in software

TABLE 5.3 Some Customer Attributes for Acclaro

CA₁		Make design document
CA₂		User-friendly graphical user interface
CA₃		Indicate the user’s mistake or guide
CA₄		Provide a collaborative design environment
CA₅		Provide efficient database
CA₆		Provide decision-making environment
CA₇		Manage the design activity
. . .		. . .

TABLE 5.4 Second-Level Decomposition for FR_1.2

	Functional Requirements	Design Parameters
	FR_1.2.x	DP_1.2.x

P	Provide decision-making environment	decision-making criterion
1	Provide design sequence in terms of axiomatic design	Decomposition roadmap
2	Maintain functional independence	Criterion for Independence Axiom
3	Make suggestions for better design	Criterion for Information Axiom and robust design

Equation (5.5) shows the first-level design equation. It is a decoupled design, although with the sequence shown, the matrix has Xs above and below the diagonal.

Equation (5.6) shows the rearranged design matrix, indicating that the sequence of development or operation should follow a certain order, FR₁₁-FR₁₂-FR₁₄-FR₁₅-FR₁₃. The design matrix shows that the GUI is the most involved module in the first level because it is affected by all DPs.

FR₂ (provide decision-making environment) may be decomposed into a sublevel with DP₂ (decision-making criterion). Table 5.4 shows the second-level decomposition for FR₂ and Equation (5.7) shows the relationships in the second level for FR₂.

In this manner, the software system can be designed using the AD framework. The Acclaro software design has a-nine-level hierarchy and well over 1000 leaves, the number of which may increase as other features are added.

5.5.3 Axiomatic Design on the FR₁₁₄₁ Branch

Figure 5.15 illustrates the complete design matrix table with module information for the FR₁₁₄₁ branch, which deals with the data structure for FRs, DPs, and design matrices in Acclaro software. Figure 5.16 also gives more detailed information for one of the modules to clarify the definition of modules. The FR₁₁₄₁₂ branch module for the data structure of FRs, which is located in the upper-left comer in Figure 5.15, is selected as an example. The off-diagonal term reveals the interrelationship between FRs and DPs located in different branches. It will guide the integration sequence between objects or classes that will be defined later.

5.5.4 Object-Oriented Model: Bottom-Up Approach

The representation of the design for the FR₁₁₄₁ branch based on the FR and DP hierarchies and the design matrix can be transformed into the OOT representation as shown in Figure 5.17. This is done by using indices for objects in a manner consistent with the indices for FRs and DPs, and also treating the object as consisting of a diagonal element whose index is suffixed by “d” and an off-diagonal element whose index is suffixed by a “^*“. Using this system, the software designer can generate an object-oriented model such as that shown in Figure 5.17, which is derived from Figure 5.15.

5.5.5 Coding with the System Architecture

The system architecture for the FR₁₁₄₁ branch may be illustrated as Figure 5.18. After the diagonal element in the full design matrix is coded, this flow diagram guides the coding sequence as well as maintenance sequences.

As discussed in Section 5.2.2, the flow chart shown in Figure 5.18 can be used in many different ways, such as

Diagnosis of software failure
Software change orders
Job assignment and management of software-development team
Distributed systems
Software design through assembly of modules
System consisting of hardware and software
Interactive software program

Figure 5.19 shows an example screen of the Acclaro software.¹⁸

5.6 DESIGN OF RAPID-PROTOTYPING SOFTWARE FOR REAL-TIME CONTROL OF HARDWARE/SOFTWARE SYSTEM¹⁹

In an ideal software-design situation, we should be able to define the FR to be satisfied, select the DP we want to use to control the FR, and determine the design matrix and the modules through modeling without resorting to any experimental verification. However, in some physical situations, we find that although the FR and the DP are chosen, the modules cannot be determined because the modeling technique is not sufficiently accurate to predict the FR/DP relationship. In this case, we have to depend on experimental results to determine the modules. The software must be so programmed that the modules can be determined based on test results.

An example of such a case is the design of the software for an antilock braking system (ABS). Igata (1996) investigated the use of axiomatic design theory for the specific case of developing software for the ABS, which cannot be fully specified from the beginning because of the complicated physical environment that the vehicle experiences during its lifetime. Although in theory, such a dynamic system can be modeled, the validity of the model must be independently verified through testing. Even then, it may be difficult to capture all possible events analytically. Therefore, in these situations, it may be quicker and easier to develop a small portion of the software to evaluate and modify through real-time testing until the desired software system is fully developed.

In the case of a system involving both hardware and software, a part of the hardware may constitute the module. The DP is input to this hardware. The product of the module and the DP generates the FR. The input DP can come from the lower level DPs, in accordance with the DP hierarchy and the associated design matrix. This is illustrated using the design of a software system for the ABS (Igata, 1996).

ABS was introduced in the 1970s to help automobile drivers to control and stop a vehicle in the shortest possible distance when driving on slippery roads. The idea behind ABS is that when the wheel completely locks up too quickly, the car will skid because there is not sufficient friction between the tire and the road. When the car skids, the driver loses control of the vehicle and the vehicle may move transversely as well as longitudinally. To prevent this skidding, the speeds of the four wheels are monitored and compared with the estimated vehicle speed to apply intermittent braking force to prevent a premature lock-up of the wheels and bring the vehicle to a stop in the shortest possible distance.

The functional requirements at the highest level of ABS are

FR₁ = Minimize the stopping distance.
FR₂ = Maintain stability and steerability of the vehicle.
FR₃ = Inform driver of the vehicle condition.
FR₄ = Maintain reliability.
FR₅ = Generate self-diagnosis.

The C is the total system cost. In 1996, the price of the ABS offered to the original equipment manufacturer was in the range of $100 to $200. Therefore, the manufacturing cost must be substantially less than $100.

To minimize the stopping distance, the maximum resisting force to longitudinal motion is required. To have maximum stability, the resisting force to transverse motion must also be large. To have the maximum friction force along the longitudinal direction, there must be a very small slip between the tire and the road surface. That is, the tangential velocity of the tire must be slightly lower than the vehicle speed. However, the transverse friction force is at a maximum when there is no slip, and as the slip increases, the transverse force decreases. This is a well-known tribological phenomenon, i.e., the friction force is at a maximum along the direction of the resultant sliding velocity. This situation is schematically illustrated in Figure 5.20 in terms of the slip ratio S, which is defined as (V_b– V_w) / V_b, where V_b is the vehicle speed and V_w is the tangential velocity of the wheel.

In view of the tribological nature of the friction force between the tire and the smooth road, FR₁ and FR₂ may be combined to come up with a new FR₁. The new set of FRs may be stated as

FR₁ = Minimize the stopping distance while maintaining stability and steerability.
FR₂ = Inform driver of the vehicle condition.
FR₃ = Maintain reliability.
FR₄ = Generate self-diagnosis.

The corresponding set of DPs may be chosen as

DP₁ = Slip ratio S
DP₂ = Brake pedal vibration
DP₃ = Redundant mechanism
DP₄ = Self-diagnosis module

The design matrix is a diagonal matrix, indicating that at the highest level, the design is a completely uncoupled design.

As discussed earlier, one of the critical inputs for decision making is the absolute velocity of the vehicle, as the slip ratio S must be known. However, many of the current commercially available ABS products do not have an independent sensor that can measure the absolute vehicle velocity. In this case, the vehicle speed must be estimated from the peeds of the four wheels.

Figure 5.21 shows a method used to estimate vehicle speed, which is plots of the vehicle speed versus time. Figure 5.21a shows the case when the vehicle is running at constant speed, i.e., S = 0. Figure 5.21b shows a normal braking case when some brake force is applied and the vehicle stops at t = t₁. In this case, S is nonzero while braking because the wheel speed is slightly below the vehicle speed and we have maximum deceleration. Figure 5.21c is the case of excessive braking force, causing lock-up of the wheels while the vehicle is still moving forward. In this case, the lateral frictional force is very small and the vehicle is unstable and out of control. Figure 5.21d shows the case of the ABS system acting properly. The brake force is controlled to prevent wheel lock-ups by taking the maximum of the four wheel speeds to estimate the vehicle speed. When the speed of the four wheels drops synchronously, the deceleration can be calculated and compared with a reference value that is typically 1.0g.

Based on the FR₁/DP₁ mapping, FR₁ can be decomposed in many different ways.Igata (1996) decomposed it as follows:

FR₁₁ = Detect the wheel speed.
FR₁₂ = Estimate vehicle speed.
FR₁₃ = Calculate the slip ratio S from the wheel speed and the vehicle speed.
FR₁₄ = Determine the output signal so that S is controlled at the target value.
FR₁₅ = Convert the output signal to brake force.

The corresponding DPs are:

DP₁₁ = Wheel speed sensor and calculation module
DP₁₂ = Vehicle speed estimation module
DP₁₃ = Slip ratio calculation module
DP₁₄ = Output signal calculation module
DP₁₅ = Brake force actuator

The design equation is

This is a coupled design. The coupling is caused by the fact that we estimate the absolute velocity of the vehicle rather than measuring it directly. This problem can be overcome if we use an accelerometer to measure the deceleration directly, as is done in many four- wheel-drive vehicles, i.e., make DP₁₂ = accelerometer. Then the design matrix becomes triangular, and the design becomes decoupled.

Some of the FRs at this level may require further decomposition. For example, FR_l4 must be further decomposed in order to achieve the objective of determining the output signal so that the slip ratio S can be controlled to a set value. Because DP₁₄ is the output calculation module, FR₁₄ be decomposed as

FR₁₄₁ = Estimate other vehicle condition parameters.
FR₁₄₂ = Calculate the output signal.
FR₁₄₃ = Correct the output signal based on other vehicle conditions.

The DPs at this level of decomposition are

DP₁₄₁ = Input from sensors supplied to vehicle condition estimation module M₁₄₁
DP₁₄₂ = Sensor output that feeds the output estimation module M₁₄₂
DP₁₄₃ = Sensor output that feeds the signal correction module M₁₄₃

This is a decoupled design, but further decomposition may be necessary if some of the modules are not available in the marketplace or within the company.

The flow diagram for this ABS design is shown in Figure 5.22. If we proceed with further decomposition, there will be additional boxes inside of the innermost boxes shown in Figure 5.22.

Some of the modules can be constructed based on test results such as those shown in Figure 5.22. Others can be determined through mathematical modeling. However, this is not done in this section.

5.7 AN IDEAL SOFTWARE SYSTEM

The Independence Axiom states that at a given level of the FR hierarchy, all of the FRs must be maintained independent when any DP is changed to alter its respective FR. This fact can be used to create a thinking design machine for products and processes (Sub, 1990; Suh and Sekimoto, 1990). This same concept can be used to develop a software design system that will considerably simplify the software design process.

For this purpose, consider a functional requirement hierarchy where the lowest level FRs, designated FR^Ls (i.e., “leaves”), do not require further decomposition. The higher level FRs can be constructed by means of the lowest level FR^Ls. Then we can construct a software database that consists of the product of modules and design parameters as follows:

where MDP_i is the product of module M_i and DP_i. The $ sign signifies the fact that any one of the MDP₁ modules can satisfy the functional requirement FR₁^L. For example, the first equation for FR₁^L states that any one of the modules (e.g., MDP₁^a , MDP₁^b, MDP₁^c, etc.) in the database can be used to control FR₁^L. Similarly, any one of the MDP₂^x can satisfy FR₂^L An MDP may be subroutines, machine language, or any software that yields an FR_ijkl(d), where FR_ijkl(d) is obtained from the diagonal element of an FR_ijkl / DP_ijkl relationship discussed in Section 5.4.3. The FR_ijkl^* due to an off-diagonal element may be stored only for specific situations, because there are too many combinations of FR_i / DP_j relationships to store for unforeseen events. Equations (5.10) constitute a library of software modules.

Now suppose that we need to develop software for a problem consisting of the following three leaves, FR₁^L, FR₂^L and FR₃^L. The best software package is the one that consists of DPs, each of which affects only one of the FR^Ls, i.e., there are no FR^L^*. This can be expressed as

In conceptualizing the design solution represented by Equation (5.11), only those DPs that affect just one of the FRs are chosen. The above software package is an uncoupled design, which satisfies the Independence Axiom. The flow chart diagram for the above design is simply ajunction S connecting the three modules.

When we cannot find an uncoupled design, we may look for a decoupled solution, which also satisfies the Independence Axiom. For example, when we first look for a DP that can yield FR₁^L, it can be anything in the database, for example, DP₁^c or DP₁^h. However, when we then look for the software module that can yield FR₂^L we must look for a DP₂^x that does not affect FR₁^L. Finally, when we look for a DP₃ that can satisfy FR₃^L after FR₁^L and FR₂^L are taken care of, there are now two conditions to satisfy the Independence Axiom: the DP3x in the database must not affect either FR₁^L or FR₂^L Then the design equation for the decoupled software may be written as

An interesting question arises when the elements of the design matrix given by (?) are not known. Obviously, it is desirable to know them. However, even if they are not known, the software can execute the computation when the desired outputs, FR₁^L, FR₂^L, FR₃^L are known and measurable. This can be done if the modules are computed in the sequence indicated in Equation (5.12), i.e., DP¹ first, then DP², and finally DP³. Such a program will involve two control junctions in the flow chart diagram.

If the database (i.e., library of modules) is given for FRs at higher levels, the software can be constructed without going through the decomposition process. Whatever is in the library is for the lowest level FRs, as we do not have to decompose these modules. The higher level FRs can be constructed from the elementary-level FR^Ls through vertical integration.

The key to the creation of an idealized software package is the creation of the complete data (i.e., module) base and the creation of uncoupled or decoupled designs.

In many situations, the database is so extensive that we may be able to find another set of DPs that also satisfies FR₁^L, FR₂^L, FR₃^L independently. Then the question becomes: “Which set of DPs is a better solution for a given set of FRs?” To decide which is a better solution, we have to invoke the Information Axiom. Different software modules may satisfy FR^Ls with different degrees of accuracy. That is, we must evaluate how well the FRs are satisfied by the chosen DPs. The best solution, according to the Information Axiom, is the one with the minimum information content.

5.8 OTHER ISSUES RELATED TO SOFTWARE DESIGN

5.8.1 Reusability

One of the important issues in software engineering is reusability. The fact that a library of software knowledge exists means that when certain software is created, it can be stored in the library and retrieved at will. Thus, reusability is ensured. In describing software design in Section 5.5, it was noted that the best way of having a robust library of software for reusability is to create modules for FR_i, and DP_i, that involve only the diagonal elements. The additional component of the module for any off-diagonal elements can be treated ad hoc for each individual case and later added to the module for diagonal elements to create a complete module.

5.8.2 Extensionality

Whenever a new FR needs to beadded at any level, the PR to be inserted must be consistent with the overall architecture of the software system. For example, an FR cannot be inserted at a mid-level of a system architecture if it cannot be obtained by decomposing a higher level FR to be consistent with the criterion for decomposition. The criterion is that the lower level FR must be consistent with its parent FR and must represent the FRs of the parent DP. If there is clear need for a certain FR but it cannot be generated from the higher level FRs move up the design hierarchy to a level where it can be added. In the extreme case, a new FR can be added only at the highest level.

When a new FR is inserted, it should show in the flow diagram as a separate box that does not create coupling with other boxes. If the FR is decomposed further, there will be inner boxes inside this outer box.

5.8.3 Knowledge and Information Requirements in Software Design

The purpose of design is to achieve the goals articulated by the functional requirements. We design artifacts that satisfy the specified FRs and constraints. One question that comes up in all design situations is: “Do we have to have complete knowledge about a proposed design to come up with a viable design solution?” Or “What is the minimum knowledge that is necessary and sufficient to make design decisions given a set of DPs for a given set of FRs?” Obviously, it would be desirable and reassuring if complete knowledge about a given design were available. However, there are situations in which the available knowledge may not be complete.

The required knowledge about a design depends on whether the proposed design satisfies the Independence Axiom. In the case of a coupled design, which is not a good design, we need the knowledge that will enable us to formulate all elements of the design matrix precisely. The same is true of the decoupled design. However, in the case of a decoupled design, when there is a state change (i.e., when the FRs change from State A to State B), the effect of the state change must be isolated to minimize the information required for the decoupled design.

Consider an ideal design that consists of three FRs. For an uncoupled design, which is the simplest case, the design equation may be written as

A₁₁, A₂₂, and A₃₃ relate FRs to DPs. They are constants in the case of linear design, whereas in the case of nonlinear design A₁₁ is a function of DP₁, etc. To set the values of FR₁, FR₂, and FR₃, we need to know only that the design matrix is a diagonal matrix for the chosen DP₁, DP₂, and DP₃. We do not need any other information, although to have a robust design, the magnitudes of the diagonal elements should be small.

Theorem Soft 1 (Knowledge Required to Operate an Uncoupled System)

Uncoupled software or hardware systems can be operated without precise knowledge of the design elements (i.e., modules) if the design is truly an uncoupled design and if the FR outputs can be monitored to allow a closed-loop control of FRs.

Again consider the three-FR case, but this time the design is a decoupled design given by the following design equation:

In the case of the decoupled design given by Equation (5.14), we need to know the diagonal elements A_ii. It is also desirable to know the off-diagonal elements A_ij. However, in the absence of complete information, we can proceed with the design and make design decisions even if we do not know the off-diagonal elements, especially if they are smaller in magnitude than the diagonal elements, i.e., A_ij < A_ii. For instance, we can vary DP₁ to set the value of FR₁ first, which will also affect FR₂. Then we may proceed to set the value of FR₂ by varying the value of DP₂. When we choose DP₂, we must be certain that it does not affect FR₁, but it is not necessary that we have any information on A₂₁, especially if DP₂ has the dominant effect on FR₂, i.e.. A₂₂ > A₂₁, and if FR₂ can be measured to allow a feedback control scheme. Similarly, as long as DP₃ does not affect FR₁ and FR₂, we can proceed with the design, even if we do not have any information on A₃₁ and A₃₂.

The point is that we can proceed with design decisions even when we do not know the relationship between FR_i and DP_j precisely if the system is going to operate in a closed-loop mode. In this case, to make a correct decision, we must vary the DPs in the right sequence, i.e., we must know the design equation and the design matrix.

Theorem Soft 2 (Making Correct Decisions in the Absence of Complete Knowledge for a Decoupled Design with a Closed-Loop Control)

When the software system is a decoupled design, the FRs can be satisfied by changing the DPs if the design matrix is known to the extent that knowledge about the proper sequence of change is given, even though precise knowledge about the design elements may not be known, if the output FRs can be measured.

The design matrix must be truly triangular. Otherwise, Theorem Soft 2 does not hold true. Suppose that the upper triangular elements are not quite equal to zero but have very small values a₁₂, a₁₃, and a₂₃ as shown in Equation (5.15).

The absolute magnitudes of the elements a_ij are much smaller than those of A_ij, i.e., |a_ij| << |A_ij|. In this case, FR₁ will be affected by large state changes of DP₂ and DP₃ and this effect may not be negligible as

where denotes a major change in the states of DPs and FRs. When DP₁ changes by DP₁ for a linear design, FR₁ also changes by FR₁. In this case, the effect of the state change (e.g., the change in FR₁ due to the change in DP₂ when the system goes from State A to State B) must be subtracted from the value of FR. For this to be possible, the magnitude of the a_ij‘s and A_ij‘s must be known. In this case, the decision making becomes much more difficult. The best thing to do is to develop a design such that all aij’s are zeros.

When the design is coupled, we must have complete knowledge of the design matrix to be able to satisfy FRs by changing DPs. Even a closed-loop control will not be useful, as a feedback control of one FR may negatively affect the outcome of other FRs. Thus, much more exact information is required to search for the unique operating point of a coupled system. When the system knowledge is incomplete, uncoupled designs cannot be operated with precision.

5.9 IMPLICATIONS OF THE INFORMATION AXIOM IN SOFTWARE DESIGN

One of the key issues in developing a software system is the evaluation of the quality of the system. In axiomatic design, it is done through the application of the Information Axiom and the measurement of the information content. The Information Axiom states that the information must be minimized, and the information content is a measure of the probability of success in achieving the stated FRs.

5.9.1 Qualitative Implementation of the Information Axiom

The Information Axiom can be applied both qualitatively as well as quantitatively. In a qualitative sense, it means any way the information content can be reduced by maximizing the probability of success in achieving the FRs. For example, the number of the lines of a computer code may be minimized; this assumes that by minimizing the length of the computer code, the probability that a computer program performs the desired functions correctly increases. Another way might be to minimize the number of computational steps by developing an efficient algorithm.

5.9.2 Quantitative Measure of the Information Content

In previous chapters, the information content was defined as the probability of success in achieving the FRs and was measured by determining the area of the common range, which is the area of the probability density function (pdf) of the system range that is inside the design range. There may be situations in which the design range and the system range for a software system can be defined quantitatively, so that the information content may be calculated by determining the area of the common range. In some software systems, the design range may not be definable because the software gives either the right answer or a wrong answer. In this case, we may define the information content as

If we have two software systems that satisfy the same set ofFRs and the information contents are the same, but one goes through 20 times the computational steps, is one of these software systems more complex than the other? Since they achieve the same FRs with the same probability of success, they are equivalent but not identical. The difference between these two software systems is the computational efficiency, which is different from the information content. This subject will be revisited in Chapter 9 in relation to complexity.

5.10 SUMMARY

This chapter presents a framework for software design based on axiomatic design that provides a systematic way of designing software. Many case studies and examples are given to illustrate the axiomatic design of software.

The AD framework has been applied to the design and development of an object- oriented software system. In particular, axiomatic design for object-oriented software system (ADo-oSS) is presented as a specific methodology for developing software. The AD framework supplies a method to determine the viability of software systematically. It ensures that the modules are in the right place in the right order, when the modules are established as a row of the design matrix. Axiomatic design methodology for software development can help software engineers and programmers to develop effective and reliable software systems quickly.

A case study was presented to show how ADo-oSS can be designed and implemented using the Java language. The interactive software system called Acclaro has been developed for designers who design hardware, software, systems, and processes. It automatically generates the FR/DP/PV hierarchies and the flow chart to represent the system architecture. It makes suggestions for design improvements based on the design axioms. It also generates engineering documents automatically.

In summary, the axiomatic approach to software systems can be characterized in terms of the following features:

The software design begins with the specification of FRs from the perceived needs of the user.
The axiomatic approach recognizes the existence of independent domains and spaces in software design.
The design process requires mapping between these domains.
There are two design axioms that must be satisfied by the mapping process in order to develop an acceptable system.
Each domain has a characteristic vector that can be decomposed to establish a hierarchical tree. In software design, the outputs constitute the FR tree in the functional domain, while key inputs form the DP tree in the physical domain.
The decomposition process requires zigzagging between two adjacent domains.
The decomposition process terminates when all branches of the FR hierarchical tree (FR leaves) can be fully satisfied by the selected set of DPs.
Each FR leaf has one module of software that is a row of the design matrix that describes the relationship between the FR leaf and the selected DP.
Modularity of the software system does not guarantee a good software design. The modules must satisfy the Independence Axiom.
These modules are reusable in axiomatic design when the identical FR is to be satisfied by the same DP. These modules can be stored in a library of modules.
The module-junction structure diagram is devised to represent the vertical integration of the modules. Three types of junctions are defined based on the coupling property of the design matrix, i.e., summation, control, and feedback junctions.

¹Trademark of Axiomatic Design Software, Inc., Boston, MA.
²The term “module” used in software engineering may be different from the definition given in Chapter 4, which is restated later in this chapter. The definition used in axiomatic design enables the design of complex systems.
³ This was first done by Dr. Sung-Hee Do, while he was a postdoctoral researcher at MIT. He is now Vice President for Technology of Axiomatic Design Software, Inc.
⁴ In Section 4.6.2, a module M, is defined as the row of the design matrix that yields an FR when it is provided with the input of its corresponding DP, which may be expressed as

⁵ The issue of complexity is discussed further in Chapter 9.
⁶ Adapted from Kim, Suh, and Kim (1991).
⁷ From Kim and Suh (1987).
⁸ From Do and Park (1996).
⁹ This section is taken from Do and Suh (1999).
¹⁰ Modules used in typical software may not meet the rigid definition of module used in axiomatic design.
¹¹ A “V model” concept was introduced to improve the quality in mechanical systems based on axiomatic design (El-Haik, 1999). This idea was adapted to show a “V model for software.”
¹² The best-known methods for object-oriented designs are Rumbaugh et al.’s (1991) object modeling technique (OMT) and Booch’s (1994) object-oriented design (OOD).
¹³ Words italicized in this section have specific definitions.
¹⁴ Contributed by S.-H. Do (August 1999).
¹⁵ Coding of the software can be done using either the module-junction diagram or the flow chart. The module-junction diagram is complementary to the flow chart. The module-junction diagram is similar to the SADT structure, but has more information, such as combining sequences based on the design matrix. Software programmers familiar with the SADT structure may be more comfortable with the module-junction diagram than with the flow chart.
¹⁶ his software was developed by Dr. Sung-Hee Do, which is included as part of Do and Suh (2000).
¹⁷ Acclaro is the trademark of Axiomatic Design Software, Inc.
¹⁸ An introduction to Acclaro can be found on the web page of Axiomatic Design Software, Inc., http://www.axiomaticdesign.com.
¹⁹ From Igata (1996).

REFERENCES

Baldwin, D. F. “Microcellular Polymer Processing and the Design of a Continuous Sheet Processing System,” Ph.D. Thesis, Massachusetts Institute of Technology, 1994.
Booch, G. Object-Oriented Analysis and Design with Applications, 2nd ed., Benjamin/Cummings, San Francisco, CA, 1994.
Cox, B. J. Object-Oriented Programming, Addison-Wesley, Reading, MA, 1986.
DeMarco, T. Structured Analysis and System Specification, Prentice-Hall, Englewood Cliffs, NJ, 1979.
Do, S.-H., and Park, G.-J. “Application of Design Axioms for Glass-Bulb Design and Software Development for Design Automation,” Presented at the CIRP Workshop on Design and Intelligent Manufacturing Systems, Tokyo, June 20-21, 1996.
Do, S.-H. “Application of Design Axioms to the Design for Manufacturability for the Television Glass Bulb,” Ph.D. Thesis, Hanyang University, Seoul, Korea, 1997.
Do, S.-H. “Axiomatic Design Software,” Unpublished paper of the MIT Axiomatic Design Group, August 1999.
Do, S.-H., and Suh, N. P. “Axiomatic Design of Software Systems,” CIRP Annals, Vol. 49, No. I, 2000.
EI-Haik, B. “The Integration of Axiomatic Design in the Engineering Design Process,” 11th Annual RMSL Workshop, May 12, Detroit, MI, 1999.
Igata, H. “Application of Axiomatic Design to Rapid-Prototyping Support for Real-Time Control Software,” S.M. Thesis, Massachusetts Institute of Technology, May 1996.
Jackson, M. A. Principles of Program Design, Academic Press, San Diego, CA, 1975.
Kim, S. G. and Suh, N. P. “The Knowledge Synthesis System for Injection Molding,” International Journal of Robotics and CIM, Vol. 3, No. 3, 1987.
Kim, S. J., Suh, N. P., and Kim, S.-K. “Design of Software Systems Based on Axiomatic Design,” Annals of the CIRP, Vol. 40, No. I, pp. 165-170, 1991 [also Robotics & Computer-Integrated Manufacturing, 3:149-162,1992].
Marca, D. A., and McGowan, C. L. SADT: Structured Analysis and Design Technique, McGraw-Hill, New York, 1988.
Orr, K. Structured Systems Development, Yordon Press, New York, 1977.
Park, G. J. “Axiomatic Design vs. Software Engineering,” NSF Sponsored Axiomatic Design Workshop for Professors, MIT, Boston, MA, June, 1998.
Pressman, R. S. Software Engineering-A Practitioners Approach, 4th ed., McGraw Hill, New York, 1997.
Ross, D. T. “Structured Analysis (SA): A Language for Communicating Ideas,” IEEE Transactions on Software Engineering, Vol. SE-3, No. I, pp. 16-34, 1977.
Ross, D. T. “Applications and Extensions of SADT,” IEEE Computer, Vol. 18, No. 4, pp. 25-35, 1985.
Rumbaugh, J. Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991.
Suh, N. P. The Principles of Design, Oxford University Press, New York, 1990.
Suh, N. P. “Design and Operation of Large Systems,” Journal of Manufacturing Systems, Vol. 14, No. 3, pp. 203-213, 1995.
Suh, N. P. “Design of Systems,” Annals of CIRP, Vol. 46, No. I, pp. 75-80, 1997.
Suh, N. P. “Axiomatic Design Theory for Systems,” Research in Engineering Design, Vol. 10, pp. 189-209,1998.
Suh, N. P. and Sekimoto, S. “Design of Thinking Design Machine,” Annals of CIRP, Vol. 39/1, pp. 145-148,1990.
Tate, D. “A Roadmap for Decomposition: Activities, Theories, and Tools for System Design,” Ph.D. Thesis, Massachusetts Institute of Technology, 1999.
Wirfs-Brock, R., Wilkerson, B., and Wiener, L. Designing Object-Oriented Software, Prentice-Hall, Englewood Cliffs, NJ, 1990.