Design Engineering

• software design
  • a meaningful engineering representation of the software product to be built
  • elements can be traced to the customer's requirements
  • can be assessed for quality against predefined criteria
    
    
• we transform the analysis model into a design model
  
  
  

• design model elements
  • describe the data structures, system architecture, interfaces, and components
  • many UML diagrams used in the design model are refinements of diagrams created in the analysis model
    
    
• architectural design (Ch 10)
  • from the class-based elements and flow-oriented elements of the analysis model
  • data flow diagrams
  • control flow diagrams
  • processing narratives
  • define the relationships among the major structural elements of the software
    
    
  • represents
    • information about the application domain
    • relationships and collaborations among specific analysis model elements
    • availability of architectural patterns and styles
  • usually depicted as a set of interconnected systems that are often derived from the analysis packages
    
    
• data/class design (Ch 10 & 11)
  • transform the analysis model class-based elements
    • class diagrams
    • analysis packages
    • CRC models
    • collaboration diagrams
  • into classes and data structures required to implement the software
    
    
  • design of data structures and operators is essential to creation of high-quality applications
    • translation of data model into database is critical to achieving system business objectives
    • reorganizing databases into data warehouse enables data mining or knowledge discovery
  • modeled using UML class diagrams
    
    
• component-level design (Ch 11)
  • using information obtained form the analysis model
    • class-based elements,
    • flow-oriented elements,
    • and behavioral elements
  • transform the structural elements defined by the software architecture into a procedural description of the software components
    
    
  • describes the internal detail of each software component
  • defines
    • data structures for all local data objects
    • algorithmic detail for all component processing functions
    • interface that allows access to all component operations
  • modeled using UML component diagrams, UML activity diagrams, and pseudocode (PDL)
    
    
• interface design (Ch 12)
  • from the analysis model scenario-based elements
  • use-case text
  • use-case diagrams
  • activity diagrams
  • swim lane diagrams
  • from flow-oriented elements,
  • and from behavioral elements
    • state diagrams
    • sequence diagrams
  • describe how the software elements, hardware elements, and end-users communicate with one another
    
    
  • a set of operations that describes the externally observable behavior of a class and provides access to its operations
  • important elements
    • user interface (UI)
    • external interfaces to other systems
    • internal interfaces between various design components
  • modeled using UML collaboration (or sequence) diagrams
    
    
• software quality attributes
  • A good design must
    • implement all explicit requirements from the analysis model
    • accommodate all implicit requirements desired by the user
    • be a readable and understandable guide for those who generate code, test components, or support the system
    • provide a complete picture (data, function, behavior) of the software from an implementation perspective
      
      
• design quality guidelines
  • A design should
    • exhibit good architectural structure
    • be modular
    • contain distinct representations of data, architecture, interfaces, and components (modules)
    • lead to data structures that are appropriate for the objects to be implemented and be drawn from recognizable design patterns
    • lead to components that exhibit independent functional characteristics
    • lead to interfaces that reduce the complexity of connections between modules and with the external environment
    • be derived using a repeatable method that is driven by information obtained during software requirements analysis
      
      
• A Generic Design Task Set
  1. select an architectural pattern appropriate to the software based on the analysis model
  2. partition the analysis model into design subsystems, design interfaces, and allocate analysis functions (classes) to each subsystem
  3. examine information domain model and design appropriate data structures for data objects and their attributes
  4. create a set of design classes
     • translate analysis class into design class
     • check each class against design criteria and consider inheritance issues
     • define methods and messages for each design class
     • select design patterns for each design class or subsystem after considering alternatives
     • revise design classes and revise as needed
  5. design user interface
     • review task analyses
     • specify action sequences based on user scenarios
     • define interface objects and control mechanisms
     • review interface design and revise as needed
  6. conduct component level design
     • specify algorithms at low level of detail
     • refine interface of each component
     • define component level data structures
     • review components and correct all errors uncovered
  7. develop deployment model
     
     
     
• Design Concepts

• abstraction
  • allows designers to focus on solving a problem without being concerned about irrelevant lower level details
    
    
  • data abstraction - named collection of data objects
    
    
    
    
  • procedural abstraction - named sequence of events
    
    
    
    
• software architecture
  • overall structure of the software components
  • the ways in which that structure provides conceptual integrity for a system
  • architectural design should draw upon repeatable patterns that are commonly encountered
    
    
• design pattern
  • description of a design structure that solves a particular design problem within a specific context
  • using patterns in design
    • architectural patterns - define overall structure and relationships of software components (classes, packages, subsystems)
    • design patterns - address specific design elements (component aggregations, component relationships, or communication)
    • coding patterns - language specific implementations for algorithms or communications mechanisms
      
    
    
• modularity
  • the degree to which software can be understood by examining its components independently of one another
  • modular design method evaluation criteria
    • decomposability - provides systematic means for breaking problem into subproblems
    • composability - supports reuse of existing modules in new systems
    • understandability - module can be understood as a stand-alone unit
    • continuity - side-effects due to module changes minimized
    • protection - side-effects due to processing errors minimized






• functional independence
  • achieved by developing modules with single-minded purpose and an aversion to excessive interaction with other models
  • effective modular design will lead to functional independence - modules have high cohesion and low coupling
    
    
    
    
• information hiding
• information (data and procedure) contained within a module is inaccessible to modules that have no need for such information
  
  
  
  
  
  
• refinement
  • process of elaboration where the designer provides successively more detail for each design component
    
    
    
    
• refactoring
  • process of changing a software system in such a way that internal structure is improved without altering the external behavior
    
    
    
    
• framework
  • collection of "plug points"- hooks or slots that enable it to be adapted to a specific problem domain
  • plug points enable designers to integrate problem specific functionality within the skeleton
  • in an object-oriented context a skeleton is a collection of cooperating classes
    
    
• Design Classes
  
  
  
  
  • class
    • generalized description (template or pattern) that describes a collection of similar objects
    • refine analysis classes by providing detail needed to implement the classes
    • provide infrastructure to support the business solution (boundary & controller classes)
      
      
      
      
  • objects
    • encapsulate both data and data manipulation procedures
      
      
  • inheritance
    • provides a means for allowing subclasses to reuse existing superclass data and procedures
    • provides mechanism for propagating changes
      
      
  • polymorphism
    • a mechanism that allows several objects in an class hierarchy to have different methods with the same name
    • instances of each subclass may respond to messages by calling their own version of the method
      
      
  • messages
    • the means by which objects exchange information with one another
      
      
      
      
• Design Model Development
  • process dimension - indicates design model evolution as design tasks are executed during software process
  • abstraction dimension - represents level of detail as each analysis model element is transformed into a design equivalent and refined
    
    
    
    
  • recommended UML quick reference from Alan Holub
    

Notes and figures from:

• Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005