Data -- entities, relationships
can be used for data modeling
Transformation (or data flow)
Structured analysis or data-flow diagrams
control flow analysis, SREM, STATEMATE
traditional analysis techniques
Object-Oriented Analysis (OOA)
emphasizes on data and transformation views
it has objects (entity and relationships) and methods (transformation)
Entity -- objects and attributes -- should we model an entity as an object or attribute?
data relationship -- one-to-one, one-to-many, many-to-many
inheritance relationship -- for modeling only
message passing relationships
Should we model relationships as objects?
relationship can be modeled as attributes
Data flow diagrams as functional specification
Processes and data flow among processes
Processes can be decomposed
Should we have within-object data-flow diagrams or inter-object data-flow diagrams?
How about the process of data-flow diagrams? Methods of objects?
Should we have both inter-object or within-object data-flow diagrams?
State transition diagrams, action diagrams
State diagrams can be decomposed, partitioned and abstracted.
Should we have within-object or inter-object STD or action diagrams?
If any view is missing at the global level, the specification would be difficult to understand. For example, if we have just the object model with its methods.
Difficult to figure out the control.
If we have the traditional paradigm, that is the procedural programs, it may be difficult to figure out the relationships among the data (this can be overcome by data and procedure dependence analysis).
Partitioning, decomposition, abstraction, integration
Objects, relationships (message relationships and data relationships), scenarios (STD), methods and data-flow diagrams can support various degree of partitioning, decomposition, abstraction
For example, object partition is OK but object decomposition is unclear, object abstraction is supported by class encapsulation
Integration between Object Model (OM) and Data Flow Diagram (DFD)
Each (sub) transformation must be a method of OM
Each method must be used at least once in the DFD
Integration between DFD and STD
Integration between OM and STD
Every (sub) transition within STD must be performed by methods in the OM
Each method must be used at least once in the STD
Integration among OM, DFD and STD
Integration between inter-object and within-object (STD, DFD)
Boehm discussed four V & V criteria
Completeness -- if all of its parts are present and each part is fully developed.
Consistency -- if no conflicts exist in the specification.
Feasibility -- it is possible to create the software and the benefit exceeds the cost.
Testability -- there exists a feasible technique for determining whether the developed software satisfies the specification.
Internal completeness and consistency -- the specification is complete with respect to its internal structures or documents, and no conflicts exist within the specification.
External completeness and consistency -- the specification completely covers the contents in external specifications or documents, and no conflicts exist between the design specification and the requirement specification.
A requirement specification is externally complete and consistent if the specification captures all user requirements of the proposed system and follows all the constraints specified by the application domain and the application itself.
A design specification is externally complete and consistent if all the requirements in the requirement specification are captured in the design specification and no conflicts exist between the design specification and the requirement specification.
Logical separation of bugs
Reference: University of Minnesota Lecture Notes