Design_ HOW to implement the system

Document Sample
Design_ HOW to implement the system Powered By Docstoc
					Design: HOW to implement a system

      l   Goals:
           » Satisfy the requirements
           » Satisfy the customer
           » Reduce development costs
           » Provide reliability
           » Support maintainability
           » Plan for future modifications
Dillon: CSE470: SYSTEM DESIGN                1
                         Design Issues

      l   Architecture          l   Operations

                                l   Data
      l   User Interface
      l   Data Types
                                l   Algorithms

Dillon: CSE470: SYSTEM DESIGN                         2
      l   System design (high level design)
           » Focus on architecture
           » Identification of subsystems

      l   Object design (lower level design)
           » Modules and their implementations
           » Focus on data representations and
Dillon: CSE470: SYSTEM DESIGN                    3
                        System Design
      l   Choose high-level strategy for
          solving problem and building
      l   Decide how to organize the system
          into subsystems
      l   Identify concurrency / tasks
      l   Allocate subsystems to HW and SW
Dillon: CSE470: SYSTEM DESIGN                 4
                        System Design
      l   Major conceptual and policy
           » Approach for management of data
           » Access mechanism for global resources
           » Software control mechanism
      l   Handle boundary conditions
      l   Prioritize trade-offs
Dillon: CSE470: SYSTEM DESIGN                        5
                    Design Principles
      l   Consider alternative approaches
           » Do pro and con analysis
           » Delay decisions until superior choice is
           » Isolate decisions so alternative
             implementations can be evaluated later
      l   Avoid unnecessary embellishments
      l   But don’t oversimplify

Dillon: CSE470: SYSTEM DESIGN                           6
          Design Principles (cont.)
      l   Make design traceable to
      l   Use uniform documentation style
      l   Reuse existing designs when
      l   Keep design simple unless
          performance, maintainability, etc.
          DEMAND otherwise
Dillon: CSE470: SYSTEM DESIGN                  7
          Design Principles (cont.)

      l   Define interfaces between modules
      l   Consider how to handle the
      l   Don’t code!!
      l   Document decisions
      l   Review, review, review . . .
Dillon: CSE470: SYSTEM DESIGN                 8
                System Architecture
      l   Overall organization of system
          into subsystems
      l   Decide basic interaction patterns
      l   Numerous architectural styles
          for different applications
      l   Architecture provides context for
          detailed design decisions
Dillon: CSE470: SYSTEM DESIGN                 9
          Subsystem Identification
      l   Divide system into a manageable
          number of components
      l   Each major component is a
      l   Subsystem groups components
          with common properties/function
Dillon: CSE470: SYSTEM DESIGN               10

      l   Collection of              l   Interrelated
                                          » Good cohesion
           » Classes
                                     l   Well-defined, small
           » Associations                interface with other
           » Operations                  subsystems
           » Events                       » Low coupling
                                     l   Identified by the
           » Constraints
                                         service it provides

Dillon: CSE470: SYSTEM DESIGN                                   11
             Subsystem Discussion
      l   Provide services for other sub-
           » Group of related functions
           » Share a common purpose
      l   Divide system into components (>20)
      l   Subsystems are decomposed . . .
           » Module is the lowest level of subsystem

Dillon: CSE470: SYSTEM DESIGN                          12
          Subsystem Relationships

      l   Client-Server relationship
           » Client subsystems actively drive the
             system by requesting services provided
             by a server subsystem
      l   Peer-to-peer relationship
           » Subsystems interact and communicate
             to accomplish a common goal
Dillon: CSE470: SYSTEM DESIGN                         13
      Client-Server Relationship
      l   Server supplies services for clients
           » Need not know identity of clients
           » Need not know interface of clients
      l   Client calls server
           » Client knows interface of server
           » Server performs some service and
             returns a result

Dillon: CSE470: SYSTEM DESIGN                     14
          Peer-to-Peer Relationship

      l   Subsystems call one another
      l   The results of/responses to calls
          may not be immediately visible
      l   Subsystems must know the
          interfaces of other subsystems
      l   More likely to have communication
Dillon: CSE470: SYSTEM DESIGN                 15
                         Strategies for

      l   Layers: Horizontal decomposition
           » Open
           » Closed

      l   Partitions: Vertical decomposition
      l   System topology:
           » General decompositions
Dillon: CSE470: SYSTEM DESIGN                  16
                Layered Subsystems

      l   Set of “virtual” worlds
      l   Each layer is defined in terms of the
          layer(s) below it
           » Knowledge is one way: Layer knows about
             layer(s) below it
      l   Objects within layer can be independent
      l   Lower layer (server) supplies services for
          objects (clients) in upper layer(s)

Dillon: CSE470: SYSTEM DESIGN                          17
         Example: Layered architecture

                       Interactive Graphics Application

                                Windows Operations

                                 Screen Operations

                                  Pixel Operations

                                Device I/O Operations

Dillon: CSE470: SYSTEM DESIGN                             18
               Closed Architectures
      l   Each layer is built only in
          terms of the immediate lower
      l   Reduces dependencies
          between layers
      l   Facilitates change
Dillon: CSE470: SYSTEM DESIGN            19
              Open Architectures
      l   Layer can use any lower layer
      l   Reduces the need to redefine
          operations at each level
      l   More efficient /compact code
      l   System is less robust/harder
          to change
Dillon: CSE470: SYSTEM DESIGN             20
                    Properties of Layered

      l   Top and bottom layers specified
          by the problem statement
           » Top layer is the desired system
           » Bottom layer is defined by available
             resources (e.g. HW, OS, libraries)
      l   Easier to port to other HW/SW
Dillon: CSE470: SYSTEM DESIGN                       21

      l   Divide system into weakly-
          coupled subsystems
      l   Each provides specific services
      l   Vertical decomposition of

Dillon: CSE470: SYSTEM DESIGN               22
            Ex: Partitioned Architecture
      Operating System

              File              Process   Memory    Device
            System              Control   Manage-   Control

Dillon: CSE470: SYSTEM DESIGN                                 23
          Typical Application Architecture

                                Application package

                                 Window graphics
         dialogue                Screen graphics      package
                                  Pixel graphics

                                 Operating system

                                Computer hardware

Dillon: CSE470: SYSTEM DESIGN                                      24
                    System Topology

      l   Describe information flow
           » Can use DFD to model flow
      l   Some common topologies
           » Pipeline (batch)
           » Star topology

Dillon: CSE470: SYSTEM DESIGN            25
                Ex: Pipeline Topology
   program         Lexical      token stream   Semantic
                  analyzer                     analyzer

             abstract syntax tree

                                code                       object
                   Code         sequence         Code      code
                 generator                     optimizer

Dillon: CSE470: SYSTEM DESIGN                                       26
                      Ex: Star Toplogy
     Monitoring system:
           Sensors               sensor
                                 status              On/Off signals,
                                                     alarm type

                    commands,         SafeHome
                       data            software          Telephone
                                                  number    line
            panel               display           tones

Dillon: CSE470: SYSTEM DESIGN                                          27
      l   Organize modules according to
          resources/objects/data types
      l   Provide cleanly defined interfaces
           » operations, methods, procedures, ...
      l   Hide implementation details
      l   Simplify program understanding
      l   Simplify program maintainance

Dillon: CSE470: SYSTEM DESIGN                       28
      l   Control abstraction
           » structured control statements
           » exception handling
           » concurrency constructs
      l   Procedural abstraction
           » procedures and functions
      l   Data abstraction
           » user defined types

Dillon: CSE470: SYSTEM DESIGN                29
               Abstraction (cont.)

      l   Abstract data types
           » encapsulation of data
      l   Abstract objects
           » subtyping
           » generalization/inheritance

Dillon: CSE470: SYSTEM DESIGN             30

      l   Contents of a module should be
      l   Improves maintainability
           » Easier to understand
           » Reduces complexity of design
           » Supports reuse

Dillon: CSE470: SYSTEM DESIGN               31
          (Weak) Types of cohesiveness

      l   Coincidentally cohesive
           » contiguous lines of code not exceeding
             a maximum size
      l   Logically cohesive
           » all output routines
      l   Temporally cohesive
           » all initialization routines

Dillon: CSE470: SYSTEM DESIGN                         32
          (Better) Types of cohesiveness

      l   Procedurally cohesive
           » routines called in sequence
      l   Communicationally cohesive
           » work on same chunk of data
      l   Functionally cohesive
           » work on same data abstraction at a
             consistent level of abstraction

Dillon: CSE470: SYSTEM DESIGN                     33
             Example: Poor Cohesion
      package Output is
       procedure DisplayDice( . . .);
       procedure DisplayBoard( . . .);

              I/O               Output

Dillon: CSE470: SYSTEM DESIGN                    34
            Example: Good Cohesion
      package Dice is
       procedure Display ( . . .);
       procedure Roll( . . .);


Dillon: CSE470: SYSTEM DESIGN                35

      l   Connections between modules
      l   Bad coupling
           » Global variables
           » Flag parameters
           » Direct manipulation of data structures
              by multiple classes

Dillon: CSE470: SYSTEM DESIGN                         36
                    Coupling (cont.)
      l   Good coupling
           » Procedure calls
           » Short argument lists
           » Objects as parameters
      l   Good coupling improves maintain-
           » Easier to localize errors, modify
             implementations of an objects, ...

Dillon: CSE470: SYSTEM DESIGN                     37
              Information Hiding
      l   Hide decisions likely to change
           » Data representations, algorithmic
             details, system dependencies
      l   Black box
           » Input is known
           » Output is predictable
           » Mechanism is unknown
      l   Improves maintainability

Dillon: CSE470: SYSTEM DESIGN                    38
              Information Hiding

Dillon: CSE470: SYSTEM DESIGN      39
                  Abstract data types
      l   Modules (Classes, packages)
           » Encapsulate data structures and their
           » Good cohesion
               – implement a single abstraction
           » Good coupling
               – pass abstract objects as parameters
           » Black boxes
               – hide data representations and algorithms

Dillon: CSE470: SYSTEM DESIGN                               40
          Identifying Concurrency

      l   Inherent concurrency
           » May involve synchronization
           » Multiple objects receive events at the
             same time with out interacting
           » Example:
               – User may issue commands through control
                 panel at same time that the sensor is
                 sending status information to the SafeHome

Dillon: CSE470: SYSTEM DESIGN                                 41
          Determining Concurrent Tasks

      l   Thread of control
           » Path through state diagram with only one
             active object at any time

      l   Threads of control are implemented
          as tasks
           » Interdependent objects
           » Examine state diagram to identify objects that
             can be implemented in a task

Dillon: CSE470: SYSTEM DESIGN                                 42
          Management of Data Stores

      l   Data stores permit separations
          between subsystems
           » Internal or external

      l   Common types of data stores
           » Files
           » Databases
Dillon: CSE470: SYSTEM DESIGN              43
                       File Data Stores
      l   When to use a database
           » Require access to voluminous data at
             fine levels of detail by multiple users
           » Access can be efficiently managed with
             DBMS commands
           » Application must port across many HW
             and OS platforms
           » Store is to be accessed by multiple
             application programs
Dillon: CSE470: SYSTEM DESIGN                          44
               Database Data Stores
      l   Advantages
           » Infrastructure support
           » Common interface
           » Standard access language (SQL)
      l   Disadvantages
           » Performance penalty
           » Awkward programming language
Dillon: CSE470: SYSTEM DESIGN                 45
                       File Data Stores

      l   When to use file data stores
           » Data does not fit structure of DBMS
           » Voluminous data that is low in
             information density
           » “Raw” data
           » Volatile data
               – only retained for a short time

Dillon: CSE470: SYSTEM DESIGN                      46
                    Global Resources

      l   Identify global resources and
          determine access patterns
      l   Examples
           » physical units (processors, tape drives)
           » available space (disk, screen, buttons)
           » logical names (object IDs, filenames)
           » access to shared data (database, file)

Dillon: CSE470: SYSTEM DESIGN                           47
      Software Control Mechanism
      l   How SW will control interactions
          between objects
           » Internal control
               – flow of control within a process
           » External control
               – flow of externally-visible events among

      l   Uniform control style for objects

Dillon: CSE470: SYSTEM DESIGN                              48
                      Internal Control

      l   Under control of programmer
      l   Structured for convenience
           » efficiency, clarity, reliability, . . .
      l   Common types of control flow
           » Procedure calls
           » Quasi-concurrent inter-task calls
           » Concurrent inter-task calls

Dillon: CSE470: SYSTEM DESIGN                          49
                   External Control

      l   Procedure-driven systems

      l   Event-driven systems

      l   Concurrent systems

Dillon: CSE470: SYSTEM DESIGN         50
          Procedure-driven systems

      l   Control resides within the
          program code
           » procedure issues request, waits for
             reply, then continues execution
      l   System state defined by
           » program counter, stack of procedure
             calls, local variables

Dillon: CSE470: SYSTEM DESIGN                      51
             Event-Driven Systems
      l   Control resides within a central
           » calls to the dispatcher send output or
             enable input
           » dispatcher invokes procedures when
             events occur (“call back”)
           » state maintained
               – using global variables, or
               – by dispatcher for procedures

Dillon: CSE470: SYSTEM DESIGN                         52
                Concurrent Systems

      l   Control resides concurrently in
          independent tasks
      l   Events are implemented as
          messages between tasks
      l   OS schedules tasks for

Dillon: CSE470: SYSTEM DESIGN               53
              Boundary Conditions
      l   Initialization
           » Constants, parameters, global variables,
             tasks, guardians, class hierarchy
      l   Termination
           » Release external resources, notify other
      l   Failure
           » Clean up and log failure info

Dillon: CSE470: SYSTEM DESIGN                           54
          Identify Trade-off Priorities
      l   Establish priorities for choosing
          between incompatible goals
      l   Implement minimal functionality
          initially and embellish as appropriate
      l   Isolate decision points for later
      l   Trade efficiency for simplicity,
          reliability, . . .

Dillon: CSE470: SYSTEM DESIGN                      55

Shared By: