Docstoc

Systematic OO Programming with Axiomatic Design

Document Sample
Systematic OO Programming with Axiomatic Design Powered By Docstoc
					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???

				
DOCUMENT INFO