Analysis Modeling

• analysis model objectives
  • describe what the customer requires
  • establish a basis for the creation of a software design
  • devise a set of requirements that can be validated once the software is built
    
    
    
    
• analysis model
  • the first technical representation of a system
  • uses a combination of text and diagrams to represent software requirements (data, function, and behavior)
  • makes it easier to uncover requirement inconsistencies and omissions
  • two approaches to analysis modeling
    • structured analysis
    • object-oriented analysis
• tools used in these approaches
  • scenario-based modeling - represents the system from the user's point of view
  • flow-oriented modeling - shows how data are transformed inside the system
  • class-based modeling - defines objects, attributes, and relationships
  • behavioral modeling - uses state transition diagrams to show how events modify state
    
    
• analysis model guidelines
  • analysis work products must be highly maintainable
  • problems of size must be dealt with using partitioning
  • graphics should be used whenever possible
  • differentiate between the logical (essential) and physical (implementation) considerations
    
    
    
    
• domain analysis
  • identification, analysis, and specification of common requirements from a specific application domain
  • typically for reuse on multiple projects within that application domain
  • activities include
    • define the domain to be investigated
    • categorize the items extracted from the domain
    • collect a representative sample of applications in the domain
    • analyze each application in the sample
      • identify candidate reusable objects
      • indicate reasons the objects may be reused
      • define adaptations of the objects that may be reused
      • estimate percentage of applications in the domain that might make reuse of the objects
      • identify objects by name and use configuration management techniques to control them
    • develop an analysis model for the objects
  • can speed the analysis greatly if you have reusable analysis models for your domain
    
    
• Structured Analysis model elements
  
  
  • Data Dictionary
    • contains the descriptions of all data objects consumed or produced by the software
    • contents include
      • name - primary name for each data or control item, data store, or external entity
      • alias - alternate names for each data object
      • where-used/how-used - a listing of processes that use the data or control item and how it is used
      • description
      • supplementary information - other data type information, preset values, restrictions, limitations, etc.
        
        
  • Entity Relationship Diagram (ERD)
    • depicts relationships between data objects
      
      
  • Data Flow Diagram (DFD)
    • provides an indication of how data are transformed as they move through the system
    • depicts functions that transform the data flow
    • a function is represented in a DFD using a process specification or PSPEC
      
      
  • State Diagram (SD)
    • indicates how the system behaves as a consequence of external events
    • states are used to represent behavior modes
    • arcs are labeled with the events triggering the transitions from one state to another
    • control information is contained in control specification or CSPEC
      
      
• Entity Relationship Diagrams
  • data modeling elements
    
    
    
    
• data object
  • any person, organization, device, or software product that produces or consumes information
    
    
    
    
    
    
• attributes
  • name a data object instance
  • describe its characteristics
  • or make reference to another data object
    
    
    
    
• relationships
  • indicate the manner in which data objects are connected to one another
    
    
    
    
• cardinality and modality (ERD)
  • cardinality
    • specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N)
  • modality
    • zero (0) for an optional object relationship
    • one (1) for a mandatory relationship
      
      
      
      
  • creating entity relationship diagrams
    • customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities
    • analyst and customer define connections between the objects
    • one or more object-relationship pairs is created for each connection
    • the cardinality and modality are determined for an object-relationship pair
    • attributes of each entity are defined
      
      
      
      
      
      
• Data Flow Diagram
• functional modeling and information flow
• shows the relationships of external entities, process or transforms, data items, and data stores
  
  
  
  
  
  
• DFD's cannot show procedural detail (e.g., conditionals or loops) only the flow of data through the software
  
  
  
  
  
  
  
  
  
  
  
  
• creating data flow diagrams
  • level 0 data flow diagram should depict the system as a single bubble
  • primary input and output should be carefully noted
  • label all arrows with meaningful names
  • information flow must be maintained from one level to to the next
  • refine one bubble at a time
  • write a PSPEC for each bubble in the final DFD
    
    
    
    
    
    
    
    
    
    
    
    
    
    
• creating control flow diagrams
  
  
  
  
  • begin by stripping all the data flow arrows form the DFD
  • control items (dashed arrows) are added to the diagram
    
    
    
    
    
    
  • add a window to the CSPEC for each bubble in the final CFD
    
    
    
    

Notes and figures from:

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