[ §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.