Systematic OO Programming with Axiomatic Design Sung-Hee Do & Nam P. Suh, Axiomatic Design Axiomatic Design • Offers a systematic and orderly way to proceed through the software development process • Provides for a methodology that ensures developers make the best design decisions by providing decision-making criteria in the form of 2 axioms: The independence axiom The information axiom Independence Axiom • Suggests that the best designs maintain the independence of the functional requirements, ensuring that the design can achieve each function without inadvertently affecting any other functions. (Coupling) Information Axiom • Suggests that the best designs minimize their information content. Thus the solution with the greatest likelihood of success is the simplest solution. Benefits of Axiomatic Design • The quality of design can be determined upon the degree to which it satisfies the defined functional requirements; • The design ensures that each function is satisfied independently and that coupling does not occur (con’t.) Benefits of Axiomatic Design (con’t.) • Job assignment and team management is easier because they can use the system architecture diagram to assign tasks and define the inter-relationships between various modules or classes • Software change orders can be handled quickly and easily because the system architecture identifies the modules affected by a change The Process… Investigate customer attributes to discover customer’s needs. Note these needs and determine the design’s functional requirements (FRs) by answering the question: “What must this design do to satisfy the customers’ needs?” Developers determine the answers and record the results as FRs in the left column of a design matrix. (here) Developers record the design parameters (DPs)- physical solutions that satisfy each functional requirement. More than one design DP may satisfy each FR, but the information axiom will help determine the best solution. This process is recorded across the top of the design matrix. Developers may indicate a relationship between the FRs and the DPs with an X in the matrix or with an equation. The matrix checks that each DP satisfies only one FR. Developers decompose the design, working through each part to determine the subfunctional requirements and subdesign of their previous design until they’ve completed the entire design. Axiomatic development pushes the development team to define the problem explicitly, envisioning the entire design before writing a single line of code. Axiomatic Development Process Axiomatic Design Example The authors make use of a case study to illustrate the effectiveness of axiomatic design. The Acclaro design software is the first implementation of a software design package using axiomatic design principles. State tasks in terms of what the software must accomplish at the highest level. Highest level FR – “to help developers succeed with software design”. Find associated DPs & choose most feasible solution – “create axiomatic design software” Define next level of FRs and DPs P in the leftmost column represents the parent level; items in numbered rows below it represent highest level DPs and FRs Continue from system level down to individual modules in increasing specific detail until the design is decomposed into manageable pieces. The matrix tracks decomposition; ensuring that DPs satisfy the FRs and are not coupled. Fourth level branch of Acclaro X’s represent specific functions. Outmost FRs and DPs are parents. Numbers are assigned to the first level that further define the parent level. Sub FRs and Sub DPs acquire additional numbers. Compare these numbers with those in Table1. (Relationship) Module 1141 excerpt. (4th level branch) -Outermost layer is 1141, next deeper is 11412. -Module 1141 has sub-module 11411- Module 11412 is five layers deep -Only diagonal X’s describe independence of FR-DP relationships (ie 114121 and 114122 are independent of one another) -Module 114123 is decoupled- its impacted by 114121 and 114122. Developers make decisions about 114123 only after making those for 114121 & 112122. Corresponding system architecture for example design matrix. Circled S’s represent summations of modules; the circled C’s represent control points that indicate one step must precede the other. System architecture • Serves as a graphical representation of the matrix • Gives order in which to make design decisions • Indicates how those decisions will impact other design functions Development Ordering • Core functions are diagonal matrix X’s and should be developed along the diagonal in order • Off-diagonal terms do not represent core functions-but are considered in development • The matrix helps developers establish and organize the relationships Object Orientation • DP leaves can represent attributes, methods, or arguments of a specific class • One or two levels up, the DPs can also be defined as a class combining the leaves below. • Once classes are defined, developers can define attributes and operations, then create interfaces by establishing relationships bewteen objects and operations, using the design matrices. ???Questions???
Pages to are hidden for
"Systematic OO Programming with Axiomatic Design"Please download to view full document