Upload
oliver
View
22
Download
0
Embed Size (px)
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 Presentation
Citation preview
[ §8 : 1 ]
7. Complex Models (and the Origins of UML)
Overview
7.1 Issues 7.2 Object Modeling Technique 7.3 Use Case Approach
[ §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
[ §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
[ §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
[ §8 : 5 ]
Model Overview
processing requirements
object instances
Functionality
Concepts
class (inheritance)
constraints (associations)
behavior (scenarios)
[ §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
[ §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 :
[ §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
[ §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
[ §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
[ §8 : 11 ]
Functional Model
check season switch
check setting
cooling target
current temperature
probe
activate fan
activate cooling
cooling needed
fan ready
etc.
[ §8 : 12 ]
Strengths of OMT (and successors)
Comprehensive application analysis Powerful object-oriented model Inclusion of relational concepts (semantic
constraints) Reliance on established models
[ §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
[ §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
[ §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)
[ §8 : 16 ]
Analysis Model
Objects are divided into three categories interface entity control
[ §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
[ §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
[ §8 : 19 ]
8. Reviews
Overview
8.1 Rationale 8.2 Technical Objectives
[ §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
[ §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
[ §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?
[ §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
[ §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
[ §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
[ §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.