Component Level Design

• for each software component identified in the architectural design define
  • data structures
  • algorithms
  • interface characteristics
  • communication mechanisms
• occurs after the data, architectural, and interface designs are established
• represents the software in a way that allows the designer to review it for correctness and consistency, before it is built
• work product is a design for each software component, represented using graphical, tabular, or text-based notation.
• design walkthroughs are conducted to determine correctness
  
  
  
  
• object-oriented view
  • a component contains a set of collaborating classes
    
    
• traditional view
  • a component (or module) serves one of three roles
  • problem domain components implement a function required by the customer
  • control components coordinate invocation of all other problem domain components
  • infrastructure components are responsible for functions needed to support the problem domain components
    
    
    
    
  • a component consists of
    • logic
    • internal data structures that are required to implement the processing logic
    • an interface that enables the component to be invoked and data to be passed to it
      
      
    
    
    
• process-related view
  • emphasizes building systems out of existing components chosen from a catalog of reusable components as a means of populating the architecture
    
    
• Object-Oriented Component Design
  • focuses on
    • the elaboration of domain specific analysis classes
    • the definition of infrastructure classes
      
      
      
      
  • prior to beginning construction activities we need detailed descriptions of
    • class attributes
    • operations
    • interfaces
      
      
  • principles for designing class-based components
    • Open-Closed Principle (OCP) - class should be open for extension but closed for modification
      
      
      
      
    • Liskov Substitution Principle (LSP) - subclasses should be substitutable for their base classes
    • Dependency Inversion Principle (DIP) - depend on abstractions, do not depend on concretions
    • Interface Segregation Principle (ISP) - many client specific interfaces are better than one general purpose interface
    • Release Reuse Equivalency Principle (REP) - the granule of reuse is the granule of release
    • Common Closure Principle (CCP) - classes that change together belong together
    • Common Reuse Principle (CRP) - classes that can't be used together should not be grouped together
      
      
  • component-level design guidelines
    • components
      • establish naming conventions during architectural modeling
      • architectural component names should have meaning to stakeholders
      • infrastructure component names should reflect implementation specific meanings
      • use of UML stereotypes may help identify the nature of components
    • interfaces
      • use lollipop representation rather than formal UML box and arrow notation
      • for consistency interfaces should flow from the left-hand side of the component box
      • show only the interfaces relevant to the component under construction
    • dependencies
      • for improved readability model
        • dependencies from left to right
        • inheritance from bottom (derived classes) to top (base classes)
      • component interdependencies should be represented by interfaces rather that component to component dependencies
        
        
  • cohesion
    • a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself
    • utility cohesion - components grouped within the same category but are otherwise unrelated
    • temporal cohesion - operations are performed to reflect a specific behavior or state
    • procedural cohesion - components grouped to allow one be invoked immediately after the preceding one was invoked with or without passing data
    • communicational cohesion - operations that require the same data are grouped in the same class
    • sequential cohesion - components grouped to allow input to be passed from first to second and so on
    • layer cohesion - exhibited by package components when a higher level layer accesses the services of a lower layer, but lower level layers do not access higher level layer services
    • functional cohesion - module performs one and only one function
      
      
  • coupling
    • a qualitative measure of the degree to which classes are connected to one another
    • data coupling - occurs when long strings of arguments are passed between components
      
    • stamp coupling - occurs when parts of larger data structures are passed between components
      
    • control coupling - occurs when one component passes control flags as arguments to another
      
    • external coupling - occurs when a component communicates or collaborates with in infrastructure component (e.g., database)
      
    • common coupling - occurs when several components make use of a global variable
      
    • content coupling - occurs when one component surreptitiously modifies internal data in another component
      
    • routine call coupling - occurs when one operator invokes another
      
    • type use coupling - occurs when one component uses a data type defined in another
      
    • inclusion or import coupling - occurs when one component imports a package or uses the content of another
      
      
  • conducting object-oriented component level design
    
    
    
    
    • collaboration diagram with messaging
      
      
      
      
    • refactoring
      
      
      
      
    • activity diagram
      
      
      
      
    • state diagram
      
      
      
      
  • Object Constraint Language (OCL)
    • complements UML by allowing a software engineer to use formal grammar and syntax to construct unambiguous statements about design model elements
    • parts of OCL language statements
      1. a context that denotes the limited situation in which the statement is valid
      2. a property representing some characteristics of the context
      3. an operation that manipulates or qualifies a property
      4. keywords used to specify conditional expressions
         
         
         
         
• Structured Component Design
  • each block of code has a single entry at the top
    
  • each block of code has a single exit at the bottom
    
  • oly three control structures are required:
    • sequence
    • condition (if-then-else)
    • repetition (looping)
      
  • reduces program complexity by enhancing readability, testability, and maintainability
    
    
  • design notation
    • flowcharts - arrows for flow of control, diamonds for decisions, rectangles for processes
      
      
      
      
    • decision table - subsets of system conditions and actions are associated with each other to define the rules for processing inputs and events
      
      
      
      
    • Program Design Language (PDL) - structured English or pseudocode used to describe processing details
      
      
      
      
      • PDL characteristics
        • fixed syntax with keywords providing for representation of all structured constructs, data declarations, and module definitions
        • free syntax of natural language for describing processing features
          
        • data declaration facilities for simple and complex data structures
          
        • subprogram definition and invocation facilities
          
          
      • design notation assessment criteria
        • modularity - notation supports development of modular software
          
        • overall simplicity - easy to learn, easy to use, easy to write
          
        • ease of editing - easy to modify design representation when changes are necessary
          
        • machine readability - notation can be input directly into a computer-based development system
          
        • maintainability - maintenance of the configuration usually involves maintenance of the procedural design representation
          
        • structure enforcement - enforces the use of structured programming constructs
          
        • automatic processing - allows the designer to verify the correctness and quality of the design
          
        • data representation - ability to represent local and global data directly
          
        • logic verification - automatic logic verification improves testing adequacy
          
        • easily converted to program source code (makes code generation quicker)
          

Notes and figures from:

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