8 : 1

1
7. Complex Models (and the Origins of UML)

• Overview
• 7.1 Issues
• 7.2 Object Modeling Technique
• 7.3 Use Case Approach

2
7.1 Issues

• Complex systems demand superior methods
• must cover specification design thoroughly
• must provide a rich repertoire of concepts and
  tools
• Effective application of such techniques
• may require specialized training in methodologies
• and to a lesser extent, tools
• requires a deep understanding of fundamentals
• based on a sound computer science and software
  engineering education
• entails project by project customization
• possibly from reusable artifacts
• expect to acquire expertise gradually
• continuing education is needed to apply training
  effectively

3
7.1 Issues, Continued

• Multiple models must be integrated formally
• state transition models
• class and object models
• data flow and message flow models
• Graphical representations not always economical
  intuitive
• Look for representations that best capture models
  semantics
• Watch out for superficial (easy) vs. deep
  (effective) representations
• Established methods do not always deliver
• Need extensibility to address new cases not
  previously considered
• Some degree of questioning the realism of
  tools/methods is helpful

4
7.2 Object Modeling Technique

• Object/class models
• application-specific information (structure) is
  captured in terms of objects having attributes
  and operations
• classes and inheritance are used to generalize
  objects
• links and associations define logical
  relationships among objects and classes
• Dynamic model
• the dynamic behavior of objects is captured using
  state machine models
• Functional model
• the processing of environmental inputs is
  captured by means of a dataflow model

• Object Modeling Technique (OMT)
• Rumbaugh et al.
• Attempts to integrate several traditional methods
  with object-oriented analysis
• Combined with the (Grady) Booch method, and
  Jacobsens Use Cases, led to UML

5
Model Overview
6
Objects

• An object is characterized by
• visible attributes
• operations (services) it provides
• Objects often are immediately identifiable in the
  application
• E.g., look for nouns in RDD/SRS
• Initial definitions may be misleading
• may need rethinking (semantics)
• may refactor or extend accordingly

• What does it do?
• What happens in the US?
• What happens in Australia?

7
Classes and Inheritance

• Classes provide object generalization
• from instances to concepts

8
Constraints and Associations

• Established data modeling techniques provide the
  means for defining semantic constraints existing
  in the application
• Such models help analysis
• Associations and constraints may give rise to new
  classes
• E.g., Traffic Simulations constraint evaluator

9
Structure

• Object instances model the abstract state of the
  system

10
Dynamic Model
11
Functional Model
12
Strengths of OMT (and successors)

• Comprehensive application analysis
• Powerful object-oriented model
• Inclusion of relational concepts (semantic
  constraints)
• Reliance on established models

13
Concerns with OMT ( successors)

• Complex graphical notation
• Lack of precise formal definition
• This has been aided in UML via state charts
• Weak integration among models
• Inadequate treatment of the environment
• Again aided in UML via use cases
• Use of models whose effectiveness is sometimes
  questionable (dataflow)
• Unrealistic expectations regarding direct
  transition to design
• Tool support (e.g., code generation) helps, but
  not completely

14
7.3 Use Case Approach

• Use Case Approach (OOSE) (Jacobson et al)
  combines object-oriented modeling with a strong
  emphasis on processing scenarios

• RDD (requirements model)
• interfaces
• domain object model
• use case model (scenarios)
• SRS (analysis model)
• object-oriented model of the functionality

15
Use Case Model

• Actors
• model the environment and the users
• initiate activity by providing stimuli
• can be primary or secondary
• Use cases
• are complete courses of action initiated by
  actors (basic or alternative)
• can be extended by (interrupt analogy) or use
  other use cases (call analogy)

16
Analysis Model

• Objects are divided into three categories
• interface
• entity
• control

17
Strengths of OO Software Engineering

• Comprehensive application analysis
• Emphasis on processing scenarios and scenario
  composition
• Reliance on simple forms of established models
• Powerful object-oriented model
• Emphasis on the development process

18
Concerns with OO Software Engineering

• Complexity and cost associated with developing
  the domain object model
• Overly optimistic expectations regarding the
  transition to design

19
8. Reviews

• Overview
• 8.1 Rationale
• 8.2 Technical Objectives

20
8.1 Rationale

• Early error detection reduces development costs
• Good requirements are critical to the success of
  the project
• correct reflection of evolving customer needs
• readily understood and maintained by the
  development team
• clearly satisfied by the design and realization
• Reviews play a key role in ensuring the accuracy
  and quality of the requirements
• Reviews make sure that the requirements do shape
  the entire development process
• Reviews help refine the development process

21
Technical Objectives

• Requirements impact technical reviews throughout
  the development life-cycle
• Critical reviews involving requirements are
• requirements verification
• requirements validation
• design verification

• Highly specialized reviews relating to
  requirements include
• project planning
• testing procedures
• performance analysis
• error pattern analysis

22
Requirements Verification

• Requirements verification is a strictly technical
  review which attempts to establish
• soundness
• consistency
• completeness

• These notions must rely on criteria provided by
  some underlying model
• are all inputs used?
• are all outputs produced?
• is the information needed to carry out each
  function available?
• are interfaces used in a manner inconsistent with
  the physical reality?

23
Requirements Verification

• The SRS is the prime target for the requirements
  verification
• Informal documents are very difficult to verify
  but some useful tools do exist
• check lists
• standard formats

24
Requirements Validation

• Requirements validation is a customer-centered
  evaluation of the requirements documentation
• Its goal is to ensure that the requirements are
  an accurate reflection of the customers needs
• as presented originally by the customer in the
  RDD
• as reformulated by the technical team in the SRS

• Customer participation is critical
• The customer needs access to information but not
  the ability to read the documentation
• specialized presentations
• rapid prototypes
• expert technical support
• Consistency and traceability between RDD and SRS
  are important in the validation

25
Design Verification

• The objective behind design verification is to
  show that
• all functional requirements have been allocated
  to the designtraceability
• all constraints are likely to be satisfied by the
  realizationdesign evaluation studies

• The top-level design (reflecting all critical
  design decisions) is checked against the SRS
• interface consistency
• state mappings
• behavior mappings
• constraints satisfaction

26
Reading List

• Davis, A. M., Software Requirements,
  Prentice-Hall, 1993.
• Jacobson, I., et al, Object-Oriented Software
  Engineering, Addison-Wesley, 1992.
• Roman, G.-C., "A Taxonomy of Current Issues in
  Requirements Engineering," Computer 18, No. 4,
  April 1985, pp. 14-23.
• Rumbaugh, J., et al, Object-Oriented Modeling and
  Design, Prentice-Hall, 1991.
• Sommerville, I., Software Engineering,
  Addison-Wesley Pub. Co., 1996.