7. complex models (and the origins of uml)
DESCRIPTION
7. Complex Models (and the Origins of UML). Overview 7.1 Issues 7.2 Object Modeling Technique 7.3 Use Case Approach. 7.1 Issues. Complex systems demand superior methods must cover specification & design thoroughly must provide a rich repertoire of concepts and tools - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/1.jpg)
[ §8 : 1 ]
7. Complex Models (and the Origins of UML)
Overview
7.1 Issues 7.2 Object Modeling Technique 7.3 Use Case Approach
![Page 2: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/2.jpg)
[ §8 : 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
![Page 3: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/3.jpg)
[ §8 : 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
![Page 4: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/4.jpg)
[ §8 : 4 ]
7.2 Object Modeling Technique
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
![Page 5: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/5.jpg)
[ §8 : 5 ]
Model Overview
processing requirements
object instances
Functionality
Concepts
class (inheritance)
constraints (associations)
behavior (scenarios)
![Page 6: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/6.jpg)
[ §8 : 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?
season
setting : (summer, winter, none) = none
heat cool shut down
![Page 7: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/7.jpg)
[ §8 : 7 ]
Classes and Inheritance
Classes provide object generalization
from instances to conceptsSwitch
position : (off, up, down) = off
moveup goback movedown
movedown = skip
Relay
status : (idle, run) = idle
set reset
Device
Setting
value : (60..90) = 75
increase decrease
TwoWaySwitch
name :
![Page 8: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/8.jpg)
[ §8 : 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
Heater A/C unit
Temperature control unit
Dual unit
temperature probe
delay timer
pilot active sensor
pressure sensor
requries requries
requries requries requries
![Page 9: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/9.jpg)
[ §8 : 9 ]
Structure
Object instances model the abstract state of the system
Controller
(Switch) season
(TwoWaySwitch) fan
(Relay) furnace
(Relay) air conditioner
(Relay) air circulation
(Setting) target temperature
![Page 10: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/10.jpg)
[ §8 : 10 ]
Dynamic Model
Switch
Setting
Relay
up
off
down
run
idle
goback moveup
movedown goback
reset set
decrease to T-1 if
T > 60
increase to T+1 if
T < 90
T
![Page 11: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/11.jpg)
[ §8 : 11 ]
Functional Model
check season switch
check setting
cooling target
current temperature
probe
activate fan
activate cooling
cooling needed
fan ready
etc.
![Page 12: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/12.jpg)
[ §8 : 12 ]
Strengths of OMT (and successors)
Comprehensive application analysis Powerful object-oriented model Inclusion of relational concepts (semantic
constraints) Reliance on established models
![Page 13: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/13.jpg)
[ §8 : 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
![Page 14: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/14.jpg)
[ §8 : 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
![Page 15: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/15.jpg)
[ §8 : 15 ]
uses
extends
authorization
phone call
charging
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)
![Page 16: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/16.jpg)
[ §8 : 16 ]
Analysis Model
Objects are divided into three categories interface entity control
![Page 17: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/17.jpg)
[ §8 : 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
![Page 18: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/18.jpg)
[ §8 : 18 ]
Concerns with OO Software Engineering
Complexity and cost associated with developing the domain object model
Overly optimistic expectations regarding the transition to design
![Page 19: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/19.jpg)
[ §8 : 19 ]
8. Reviews
Overview
8.1 Rationale 8.2 Technical Objectives
![Page 20: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/20.jpg)
[ §8 : 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
![Page 21: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/21.jpg)
[ §8 : 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
![Page 22: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/22.jpg)
[ §8 : 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?
![Page 23: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/23.jpg)
[ §8 : 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
![Page 24: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/24.jpg)
[ §8 : 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 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
![Page 25: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/25.jpg)
[ §8 : 25 ]
Design Verification 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
![Page 26: 7. Complex Models (and the Origins of UML)](https://reader036.vdocuments.net/reader036/viewer/2022062520/56815930550346895dc6647f/html5/thumbnails/26.jpg)
[ §8 : 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.