7. Complex Models (and the Origins of UML)

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. Object Modeling Technique (OMT) Rumbaugh et al. Attempts to integrate several traditional methods with object-oriented analysis Combined with the (Grady) Booch method, and Jacobsen’s Use Cases, led to UML 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 7.2 Object Modeling Technique

5. Model Overview

6. 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? Objects

7. Classes provide object generalization from instances to concepts Classes and Inheritance

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 Simulation’s constraint evaluator

9. Object instances model the abstract state of the system Structure

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. 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 7.3 Use Case Approach

15. 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) Use Case Model

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. 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 Technical Objectives

22. 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? Requirements Verification

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 is a customer-centered evaluation of the requirements documentation Its goal is to ensure that the requirements are an accurate reflection of the customer’s 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 Requirements Validation

25. The objective behind design verification is to show that all functional requirements have been allocated to the design—traceability all constraints are likely to be satisfied by the realization—design evaluation studies The top-level design (reflecting all critical design decisions) is checked against the SRS interface consistency state mappings behavior mappings constraints satisfaction Design Verification

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.