Structured- Design by SanjuDudeja


									                              UCLA CS130 – Software Engineering
                                     Structured Design
                                        Winter, 2002
                                       Lecture Notes
                                      January 30, 2002


Summary of Last Lecture

Today’s Lecture

1. Topics
   1.1.     Design Concepts and Principles - Ch 13
            • The design process
            • Design principles
            • Design concepts
              • Abstraction
              • Refinement
              • Modularity
              • Structural Partitioning
              • Information Hiding
              • ...
            • Modular design – high cohesion (module does one thing), low coupling (a mod-
               ule is minimally dependent on another)
            • Heuristics
            • Design Document
   1.2.     Architectural Design – Ch 14
            • Data Design
            • Mapping Requirements to Software Architecture
            • Transform Mapping
            • Transaction Mapping
            • Refining the Architectural Design
2. Design Concepts and Principles
   2.1.     Design process
       2.1.1. Transforms analysis model into representation of system that will be built

              Diagram below shows how portions of analysis model map into software design

  Data object     ER         Data flow
  description                 diagram        Process                Component-
                                          specification             level design
                      dictionary            (PSPEC)
                                                                  Interface Design

                         state                                  Architectural Design
                                                                    Data Design

       Four components to software design
       • Data design – transforms information model into data structures required for
           implementation. Foundation of SW design since purpose of SW system is to
           transform input data into outputs. Appropriate data representations are key to
           quality systems.
       • Architecural design – defines relationship between main SW structural ele-
           ments, design patterns that can be used, and constraints affecting application
           of design patterns.
       • Interface design – describes communication within SW, between SW and
           other system components or external systems, between SW and user.
       • Component-level design – procedural details of software components. “How
           is a particular piece of processing done?”
2.1.2. Quality reviewed as design evolves via FTRs or design walkthroughs (Ch 8) McGlaughlin’s 3 characteristics of a good design
          Implements all explicit requirements – all explicit require-
                              ments in the analysis model. Customer’s implicit require-
                              ments should also be accommodated
          Readable and understandable – coders and testers will use
                              the design as a basis for generating code and test
                              cases/procedures. Support staff will need to use design to
                              understand software before they modify it.
          Complete – address data, functional, behavioral domains
                              from implementation perspective. Some design quality criteria – see text for complete list
          Modular design – SW partitioned into elements performing
                              specific functions. SW elements should not be a Swiss
                              Army knife that does everything.
          Distinct representations – Design should distinctly represent
                              data, architecture, interfaces, components so that each one of
                              these design components can be identified.

               Repeatable design method – should derive design using a
                                   repeatable method driven by information obtained during
                                   requirements analysis.
2.2.      Design principles
     2.2.1. SW design is a process and a model
    Model – equivalent of engineering drawings for a piece of machinery,
                        a blueprint for a house, etc. Refinement provides all the views that
                        will be necessary to construct the SW
    Process – sequence of steps enabling SW engineer to describe all as-
                        pects of system that will be built
     2.2.2. Principles – guidelines for navigating design process – complete list in text, sec-
             tion 13.3. Designs should exhibit following characteristics:
    Traceability – design should be traceable to the analysis model.
    Uniformity – a design should look like one person developed it. Use
                        rules of style, format to standardize representations.
    Integration – interfaces between design components accurately, consis-
                        tently, and completely defined.
    Design is not code – and code is not design. Design is at a higher level
                        of abstraction than code.
    Accommodate change – change can always occur, so make sure the
                        design can handle it. Design concepts of modularity, structural parti-
                        tioning, information hiding (upcoming discussion) help achieve this.
    “Graceful degradation” – make allowances for errors that can occur
                        (e.g., input out of range, unexpected sequence of control signals)
2.3.      Design concepts – help to answer following questions:
          • Criteria for partitioning software – what criteria should we use to partition soft-
             ware into individual components?
          • Separating detail from concept – how is functional or data structure detail sepa-
             rated from a conceptual representation of SW?
          • Quality criteria – what criteria are used to judge the technical quality of a SW de-
    2.3.1. Abstraction
    Each step of the design process refines the level of abstraction

                                     Refining Levels of Abstraction

                                            Requirements                    Implementation
            System Design                     Analysis

               System                       Statement in                     Source
               element                      Language of               ...     Code

       3 types of abstractions created during design:

         Procedural – named sequence of steps having a specific
                              function (e.g., “Start” for a car, “Monitor Power Usage” for
                              a factory)
         Data – named collection of data describing a data object
                              (e.g., Class, Student). In context of “Start” and “Monitor”
                              usage, data abstractions would be “Car” and “Factory”. ,
                              each having a set of attributes (e.g., Car – manufacturer,
                              model, engine type, starting mechanism). Procedural ab-
                              stractions make use of attributes of data objects.
         Control – implies program control mechanism without get-
                              ting into details (e.g., mutex for controlling access to com-
                              puter resources – can be hardware test-and-set instruction,
                              software implementation such as baker’s algorithm. An in-
                              terrupt is also an example of a control abstraction). Abstractions allow us to focus on a problem at the appropriate level
                  without worrying about irrelevant details
2.3.2.   Refinement Top-down design strategy – successively decomposing sections of the
                  program (procedures, data) into more detailed components. Refine-
                  ment ends when all procedures have been expressed in a programming
                  language. Analogous to partitioning and refinement used for requirements speci-
                  fication. Complementary to abstraction:
         Abstraction hides irrelevant detail
         Refinement helps reveal low-level details as design pro-
         Both ideas used in creating a complete design
2.3.3.   Modularity Concept almost as old as computers - introduced almost 50 years ago. SW divided into separately named and addressable components (mod-
                  ules) that are integrated to satisfy problem requirements Makes programs manageable – according to Myers, “modularity is the
                  single attribute of software that allows a program to be intellectually
                  manageable.” Large monolithic programs cannot be understood, but
                  dividing SW into modules that can be individually understood and in-
                  tegrated with other modules allows construction of large programs. Decompose SW into modules, but not into too many or too few:

                                                     Region of
                                                     minimal cost
                                                                       Total SW cost

                                                                        Integration cost

              Cost of effort


                                             Number of Modules
                               Want number of modules M to be such that we stay in region of mini-
                               mal cost. M often cannot be determined analytically- must rely on
                               previous experience.
  Evaluating design method with respect to modularity - 5 criteria below
                   help answer question of how good a design method is at producing a
                   modular design
          Decomposability – design method provides systematic
                              mechanism for decomposing problem into subproblems ->
                              design method reduces problem complexity and produces a
                              modular design.
          Composability – design method allows existing components
                              to be assembled into a system -> method produces a modu-
                              lar design
          Understandability – if a module can be understood on a
                              stand-along basis, method produces modular design
          Continuity – small changes in system requirements result in
                              changes to individual modules rather than systemwide
          Protection – effects of error condition contained within
2.3.4.   Software Architecture – refers to overall SW structure and how structure pro-
         vides conceptual integrity for system. Simplest form is hierarchical structure of
         modules. Architecture is one goal of SW design – we’ve seen this in the design
                   pyramid shown earlier. Serves as a framework for more detailed de-
                   sign activities (interface, component design). A set of architectural
                   patterns enables design reuse. Model that allows:
          Analysis of design – allows SW engineers to analyze effec-
                              tiveness of design in meeting requirements.

         Consideration of alternatives – at design stage, changes are
                             still relatively easy and cheap to make.
         Risk reduction – components having greater risks can be
                             identified, specific risks can be identified, plans for mitiga-
                             tion and contingency plans can be made. Properties that should be specified as part of architecture (Garlan and
         Structural – specify components (e.g.,modules, objects),
                             how they’re packaged, how they interact
         Extra-functional – deals with requirements for performance,
                             capacity, reliablity, security, other system characteristics
         Families of related systems – design should have ability to
                             reuse architectural building blocks. Architectural representations – architecture can be represented using
                  one or more models:
         Structural models – represent architecture as organized col-
                             lection of components
         Framework models – higher level of abstraction – identify
                             repeatable architectural design frameworks (patterns)
         Dynamic models – address behavioral aspects – how does
                             structure change as a function of external events
         Process models – focus on design of business or technical
                             process that system must accommodate
         Functional models – represent functional hierarchy of sys-
2.3.5.   Control Hierarchy Represents organization of program components, implies hierarchy of
                  control Does NOT represent procedural aspects (e.g., sequence of operations) Most common representation is control tree




2.3.6.   Structural Partitioning Horizontal partitioning – separate branches of hierarchy perform dif-
                    ferent functions. Control modules (shown in gray) coordinate com-
                    munication between and execution of functions.

                                        Function 2

                      Function 1                         Function 3

                                • Ease of testing
                                • Maintainability/extendability (changes localized to
                                   branch or new branch is added)
                                • Fewer side-effects propagated

                                  •    More data passed across interfaces
                                  •    Overall control more complicated, if processing requires
                                       rapid movement from one function to another.
      Vertical partitioning – control modules at top of hierarchy, “worker”
                        modules at lower levels.

               Decision modules


            Vertically-partitioned programs tend to be more maintainable:
            • Programs tend to change more in areas of input, transformation, output.
            • Control structure tends not to change too much
            • Less susceptible to side effects when changes are made.
   2.3.7.   Data Structure – should be familiar with this material from data structures class.
   2.3.8.   Software Procedure
   Processing details of individual modules (sequence of events, decision
                      points, repetitive operations, ...)
   Module processing must refer to all subordinate modules
   2.3.9.   Information Hiding
   Modules should be designed so that information within a module not
                      needed by other modules is not accessible to them.
   Defines and enforces access constraints to:
                      • Procedural detail within a module
                      • Local data structure used by module

                       Example – in defining a stack:
                       • Push and pop might be only procedural detail available to other
                       • Other modules wouldn’t be able to see all of the data in the stack,
                          just the topmost data item.
   Promotes maintainability – because most data and procedure hidden
                       from other modules, errors less likely to be propagated.
2.4.      Modular design
     2.4.1. Functional Independence

      Modules address specific subfunction of requirements – modules are
                        not Swiss army knives.
    Simple interface to other modules
    Measured by cohesion and coupling
     2.4.2. Cohesion – measure of relative functional strength of a module - extension of in-
             formation hiding
    Levels of cohesion
               Low – module performs a variety of tasks that are related to
                                    each other only loosely (coincidental cohesion)
               Moderate – processing elements of a module are related to
                                    each other to some extent (e.g., related processing elements
                                    must be executed in a specific order [procedural], all proc-
                                    essing focuses on one part of a data structure [communica-
               High – module performs one distinct procedural task
    High cohesion ideal; middle-range cohesion often acceptable. Avoid
                        defining low-cohesion modules.
     2.4.3. Coupling – measures interconnection among modules. Goal is to have low cou-
    Types of coupling
               Data coupling – simple arguments passed from module A to
                                    module B when A calls B. Low degree of coupling.
               Control coupling – control info passed from module A to
                                    module B that controls decisions in B. Moderate degree of
               Common coupling – several modules reference a global data
                                    item – high coupling.
               Content coupling – module A uses data or control informa-
                                    tion contained in module B. Highest degree of coupling.
2.5.      Heuristics – assist in developing modular designs
     2.5.1. Reduce coupling, improve cohesion – for example, look for common processing
             in two or more modules – can be redefined as cohesive module.
     2.5.2. Minimize structures with fan-out, strive for fan-in as depth increases
     2.5.3. Module scope of effect = module scope of control
     2.5.4. Reduce interface complexity, improve consistency – interfaces should be simple
             and consistent with function of modules at each end. Interface complexity major
             cause of SW faults.
     2.5.5. Avoid content coupling – e.g., don’t branch into the middle of another module,
             refer to data inside of it.
2.6.      Design Document – see outline at end of notes
    2.6.1. Scope – derived from software requirements document and analysis model
    2.6.2. Data design – database structure, external files, internal data structures
    2.6.3. Architectural design – how has architecture been derived from analysis model?
    2.6.4. Interface design – internal and external (includes user interface)
    2.6.5. Component design – procedural description of processing. Initially narrative de-
             scription, evolves to structured description (e.g., program design language).

       2.6.6.    Requirements cross matrix – traces to requirement document. Establishes all re-
                 quirements satisfied by design and indicates components critical to implementa-
                 tion of requirements
        2.6.7. Design constraints
        2.6.8. Module integration and test guidelines (deleted if a separate test plan is pro-
        2.6.9. Supplementary information – include algorithm descriptions, quotes from or ref-
                 erences to other documents.
3. Architectural Design
   3.1.      What is Architecture – as above – represents structure of data and program compo-
             nents required to build a SW system.
   3.2.      Data Design
        3.2.1. Translation of ER diagram/data dictionary from analysis model to data structures
                 at component level, database architecture. Today may include design of data
                 warehouse – a large, independent database (not directly integrated with day-to-
                 day applications) containing all of the data used by a business. Data warehouses
                 are organized by business subjects rather than by business process or function;
                 have consistent naming conventions, units, structures regardless of data source;
                 and data loaded in doesn’t change.
        3.2.2. Component-level data design – deals with representing data structures accessed
                 by one or more components – principles below:
        Apply systematic analysis principles – the same analysis principles
                            applied to function and behavior can and should be applied to data de-
                            sign. Make sure to consider alternative representations, especially in
                            early stages of data design.
        Defer low-level design decisions as long as possible
        Make use of information hiding – only those modules that need to
                            should know about a data structure’s representation
        Develop library of “useful” data structures and operations – reusable
                            structure templates (abstract data types) can reduce specification and
                            design time.
   3.3.      Architectural styles – section 14.3 of text – be familiar with taxonomy of styles and
             • Data-centered
             • Data-flow
             • Call and return
             • Object-oriented
             • Layered
             Also look at the questions to ask in determining what type of architecture a system
   3.4.      Analyzing Alternative Architectural Designs – section 14.4 of text – be familiar with
             Architecture Trade-off Analysis Method (ATAM) analysis activities. Don’t worry
             about quantitative evaluation of architectures.
   3.5.      Mapping Requirements to Architecture – comprehensive mapping accomplishing
             transition from requirements to variety of architectural styles doesn’t exist.

       3.5.1.   Structured design – one approach to mapping. Data flow-oriented design method
                (mechanism for transitioning from DFDs to architecture). 6 steps:
       Establish type of info flow
       Indicate flow boundaries
       Map DFD into program structure
       Define control hierarchy
       Refine structure – use design measures and heuristics
       Refine and elaborate architectural description

                Type of information flow drives type of mapping approach:
                • Transform flow:
                     • Data flow is sequential
                     • Data follows one or only a few “straight lines” through system
                     • Terminology:
                        • Data enters system along incoming flows – external data converted to
                            internal form.
                        • Incoming data pass through transform center and start moving out of
                        • Data moves out of system along outgoing flows – internal data con-
                            verted to external form.
                • Transaction flow (see diagram below):
                     • Single data item (transaction) triggers other data flow along one of many
                        • Action path – an info flow emanating from the process where incoming
                           transaction is evaluated.
                        • Transaction center – hub of info flow from which many action paths
                A single system can exhibit both types of information flow – in a transaction-
                oriented flow, info flow along an action path can have transform flow character-




3.6.       Transform Mapping – map DFD with transform flow characteristics to specific ar-
           chitectural style

3.6.1.    Example – spacecraft fault detection and fault repair software
                                                Spacecraft fault detection and recovery –
                                                              Level 0 DFD

                                                                           Fault               Command
                            Sensors              Value                 Identification
                                                                       and Recovery            Sensor-

                                                                                                     Command            Subsystem-           Spacecraft
                                                                                         d-         Subsystems          Command              Subsystems
                                                                                      -an t
                                                                                   and r-Lis
                                                                                mm te
                                                                              Co rame
            Sensor-          Read     Sensor-Name-
Sensors      Value          Sensors     and-Value

                                                                              an nso
                    Thr larm-

                                                                                d-c r-v
                                                                                   om alu

                                                                                     ma es-

                                                                                                      Send to           Sensor-Alarm-          Telemetry
             Alarm-                                                                                  Telemetry            Telemetry            Subsystem

                                                                             Select      Command-and-        Command          Subsystem-       Spacecraft
                                                                            Response     Parameter-List     Subsystems        Command          Subsystems
                                                            Ty arm-

          Sensor-       Read     Sensor-Name-
Sensors    Value       Sensors     and-Value
                                                          Se d-c
                                                            ns om

                                                              or m
               Thr larm-

                                                                -v a
                                                                  alu nd

                                                                     es s


                                                                             Format           Formatted-                                         Telemetry
                                                                                                             Send to         Sensor-Alarm-
           Alarm-                                                              for             Sensor-                         Telemetry         Subsystem
                                                                            Telemetry          Output       Telemetry

3.6.2.    7 design steps
 Review system model
 Review/refine DFDs for SW
                    • Refine processes until they exhibit relatively high cohesion
 Determine DFD characteristics – transform or transaction?
                    • Generally, info flow can always be represented as transform flow
                    • Use different mapping if encountering a transaction flow

                     Isolate transform center – do this by specifying incoming and outgoing
                                       flow boundaries. No hard and fast rules to establish boundaries – open
                                       to interpretation. Different engineers might pick different boundaries.
                                       Picking different boundaries is one way of looking at alternative de-
                                       signs. Boundaries should be “reasonable”, but don’t waste time opti-
                                       mizing boundary placement. Small variances in placement generally
                                       don’t affect final program structure.
                     First-level factoring – map DFD to call and return structure. At this
                                       stage control modules are identified. See diagram below

                                 Spacecraft Fault Detection and Recovery
                                          First Level Factoring
                                                                                                  Outgoing Paths

     Incoming Path                    Transform Center
                                                                           Select     Command-and-      Command      Subsystem-      Spacecraft
                                                                          Response    Parameter-List   Subsystems    Command        Subsystems
                                                            Ty rm-

          Sensor-       Read     Sensor-Name-
Sensors    Value       Sensors     and-Value
                                                        Se d-c
                                                          ns om

                                                            or m
               Thr larm-

                                                              -v a
                                                                alu nd

                                                                   es s


                                                                           Format       Formatted-                                    Telemetry
                                                                                                        Send to     Sensor-Alarm-
           Alarm-                                                            for         Sensor-                      Telemetry       Subsystem
                                                                          Telemetry      Output        Telemetry


                      Input               Alarm Condition                       Alarm Output
                    Controller               Controller                          Controller

                     Second-level factoring – map individual bubbles in DFD to modules
                                       within architecture. See below

                                 Spacecraft Fault Detection and Recovery
                                         Second Level Factoring
                                                                                                   Outgoing Paths

     Incoming Path                    Transform Center
                                                                            Select     Command-and-      Command      Subsystem-      Spacecraft
                                                                           Response    Parameter-List   Subsystems    Command        Subsystems

                                                             Ty arm-
          Sensor-       Read     Sensor-Name-
Sensors    Value       Sensors     and-Value

                                                         Se d-c
                                                           ns om

                                                             or m
               Thr larm-

                                                               -v a
                                                                 alu nd

                                                                    es s

                                                                            Format       Formatted-                                    Telemetry
                                                                                                         Send to     Sensor-Alarm-
           Alarm-                                                             for         Sensor-                      Telemetry       Subsystem
                                                                           Telemetry      Output        Telemetry


                     Read                       Determine                        Alarm Output
                    Sensors                     Alarm Type                        Controller

                                                                        Send to                  Command
                                                                       Telemetry                 Subsystems

                                                                       Format for                   Select
                                                                       Telemetry                   Response

                    Start at beginning of transform center boundary, move out-
                                        ward along incoming, then outgoing paths to map trans-
                                        forms into subordinate modules
                    One-to-one mapping of bubbles to modules not required –
                                        more than one bubble may map to a module, or vice versa
                    For each module, write a narrative description, adapted from
                                        analysis model’s PSPEC. Description describes module in-
                                        put and output, information retained by module, procedural
                                        description, and restrictions and special features. Narrative
                                        serves as first-generation Design Specification.
           Refine first-iteration architecture
                    Explode or implode modules to:

                                       •   Produce sensible factoring
                                       •   Increase cohesion
                                       •   Minimize coupling
                                       •   Allow structure to be easily implemented
                                       •   Produce testable SW – know what to test and know that
                                           it was tested.
                                       •   Produce maintainable software
3.7.        Transaction Mapping
       3.7.1. 7 steps – principal difference from transform mapping is how DFD is mapped to
      Review system model
      Review/refine DFDs for SW
      Determine DFD characteristics – is DFD a transaction flow?
      Identify transaction center – can be easily identified within DFD –
                         look for bubble with one input, many outputs.
      Map DFD to appropriate structure. See below

                             A                                 Transaction

                                                                           Dispatch branch
                                                    Reception branch
                             B                                                       (transaction

                                                    A         controller

                          action Hub
                                                        D         E           F






                      •   Architecture has 2 branches – incoming branch and dispatch
                      • Transaction hub in DFD is dispatch controller on dispatch branch
                          of architecture
                      • Mapping – start at transaction and work outwards along incoming
                          path and action paths
   Factor and refine transaction structure of each action path – for each
                      action path, determine what type it is (transform or transaction) and
                      apply the appropriate mapping method.
   Refine first-iteration architecture – use heuristics we’ve discussed to
                      improve quality
             Refinement goals same as for transform mapping
3.8.     Refining Architectural Design
    3.8.1. Program structure development/refinement followed by 6 tasks:
   Processing narrative – for each module, an unambiguous, bounded de-
                      scription of its processing is developed. Narrative describes:
                      • Inputs and outputs
                      • Processing tasks
                      • Decisions
   Interface description – for each module, describe its interfaces. Inter-
                      face descriptions for:
                      • Internal module interfaces
                      • External system interfaces
                      • User interface
   Define local and global data structure
   Note design restrictions and limitations – for example:
                      • Data type or format
                      • Timing limitations
                      • Input/output value ranges
   Review design – one or more reviews - emphasize:
                      • Traceability to requirements
                      • Architectural quality
                      • Correctness, completeness, consistency of interface descriptions
                      • Data structure descriptions – correct, complete, consistent, appro-
                          priate to problem domain?
                      • Implementation/test feasibility
                      • Maintainability
   Is further refinement needed?
                      • Encourage refinement during early design stages – consider alter-
                          native data representations, architectures.
                      • Guideline – strive for smallest number of modules consistent with
                          effective modularity and least complex data structure that satisfy


To top