Object Oriented Software Engineering

1
 Object-Oriented Analysis and Design
• Design review
• Object Modeling Technique
• Object-Oriented Analysis
• Object-Oriented Design
• Three models
• Object model
• Dynamic model
• Functional model

2
 Design - Review
• Design transforms requirements into
• an architecture diagram
• subsystems, modules and their relationships
• a detailed design
• a specification of the abstract interface, data structures, and algorithms of
each module
• Also develops
• a review plan for ensuring the design meets the requirements
• a test plan for ensuring the implementation meets the design

3
 Object-Oriented Software Development
• Object-Oriented Methodology
• development approach used to build complex systems using the concepts of
object, class, polymorphism, and inheritance with a view towards reusability
• encourages software engineers to think of the problem in terms of the application
domain early and apply a consistent approach throughout the entire life-cycle
• Object-Oriented Analysis and Design
• analysis models the “real-world” requirements, independent of the implementation
environment.
• design applies object-oriented concepts to develop and communicate the
architecture and details of how to meet requirements

4
 Object Modeling Technique
Process via UML (OMT turned into UML)
• OMT [Rumbaugh et al.,1991] consists of
• building three complementary models of the system
• adding implementation details to the models
• implementing the models
• OMT includes a set of
• phases [processes]
• diagramming techniques
• OMT has four phases
• object-oriented analysis builds a real-world model
• system design determines overall architecture of system
• object design decides upon data structures and algorithms
• implementation translates design into programming language

5
 OMT Stages and Models

- Static structure of objects and their relationships

Analysis
- Model of real-world situation
- What ?

- Control aspects of the system

- Data value transforamtions

System Design

(dataflow diagrams)

Functional Model
- Overall architecture (sub-systems)

Dynamic Model
(state diagrams)
(object diagram)

Object Model
Object Design
- Refinement of Design
- Algorithms/data structures to
implement each class

Implementation
- Translation of object classes and
time

relationships to a particular
object-oriented language
System
6
 Introduction to Object-Oriented Analysis
• Object-Oriented Analysis is the “requirements phase” of Object-Oriented Software
Development
–think of it as an alternative semi-formal technique

• Semi-formal technique • Reuses familiar tools

• class modeling • E-R diagrams
• dynamic modeling • Finite State Machines
• functional modeling • Data flow diagrams
• These steps focus on • Steps and diagrams
• data • are typically performed in parallel
• actions after initial class definition
• and their relationships • must be kept in synch

7
 Object-Oriented Analysis
• Builds a real-world model from requirements
• client interviews
• domain knowledge
• real-world experience
• Model is more precise and concise than the informal problem definition
• The model addresses three aspects of objects
• class structure and relationships
• sequencing of interactions and events
• data transformations and computations

8
 Models of Object-Oriented Analysis
• Class Model
• static structure • Data-Oriented
• what objects are in the system?
• how are they related?
• Dynamic Model
• behavioral aspects • Action-Oriented
• what events occur in the system
• when do they occur and in what
order?
• Functional Model
• data transformations • Both Data and Actions
• “what” does the system do

9
 OO Analysis and Design: Steps
• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel or out of order
• All models must be kept in synch as changes are made

10
 Class Modeling
• Identify objects and classes
• Prepare a data dictionary
• Identify associations between objects
• Identify class attributes and initial set of operations
• Organize object classes using inheritance

11
 Classes, Attributes and Operations
• Attributes define the properties of the objects
• every instance of the class has the same attributes
• an attribute has a data type
• the values of the attributes may differ among instances
• Operations define the behavior of the objects
• action performed on or by an object
• available for all instances of the class
• need not be unique among classes

Class
Class Attributes
Attributes Operations
Operations
ball
ball radius,
radius, weight
weight catch,
catch, throw
throw
football
football air
air pressure
pressure pass,
pass, kick,
kick, hand-off
hand-off
baseball
baseball liveness
liveness hit,
hit, pitch,
pitch, tag
tag

12
 Object Model Notation, Review

Class Name Classes are represented as rectangles;

InstanceVariable1 The class name is at the top, followed by attributes

InstanceVariable2: type (instance variables) and methods (operations)

Method1() Depending on context some information can be

Method2(arguments) return type hidden such as types or method arguments

Objects are represented as rounded rectangles;

(Class Name)
The object’s name is its classname surrounded by
InstanceVariable1 = value parentheses
InstanceVariable2: type
Method1() Instance variables can display the values that they
Method2(arguments) return type have been assigned; pointer types will often point
(not shown) to the object being referenced

13
 OMT Instantiation Notation

Class Name
Class
attribute_1: data_type_1 = default_1
attribute_2: data_type_2 = default_2
...
attribute_m: data_type_m =
default_m

(Class Name)

Instance attribute_1 = value_1

attribute_2 = value _2
...
attribute_m = value _m
14
 Instantiation - Example

Person (Person)

name Joe Smith

age age=39
weight weight=158

(Person)

Mary Wilson
age=27
weight=121

15
 Inheritance
• Classes with a set of similar attributes and operations may be organized into a
hierarchical relationship.
• Common attributes and operations are factored out and assigned to a broad
superclass (generalization):
• generalization is the “is-a” relationship.
• superclasses are ancestors, subclasses are descendants.
• A class can be iteratively refined into subclasses that inherit the attributes and
operations of the superclass (specialization).

16
 OMT Inheritance Notation

Generalization
Superclass

Class Ball
Attributes Radius, Weight
Operations Throw, Catch

Subclasses

Football Baseball Basketball

air pressure liveness air pressure , dimples
pass, kick, hand-off hit, pitch, tag shoot, dribble, pass

Specialization
 Association and Links
• An association is a relation among two or more classes describing a group of links,
with common structure and semantics.
• A link is a relationship or connection between objects and is an instance of an
association.
• A link or association is inherently bi-directional:
• the name may imply a direction, but it can usually be inverted.
• the diagram is usually drawn to read the link or association from left to right or
top to bottom.
• A role is one end of an association.
• roles may have names

18
 OMT Association Notation
Class, Association, and Roles
Person Company
Works For

equivalent

Company Person
Employs
Employer Employee

Object and Link

(Person) (Company)
Works For
Johnson IBM
19
 Association and Links

Country has-capital City

Class diagram
nam nam
e e

(Country) has-capital (City)

Canada Ottawa

(Country) has-capital (City)

Instance diagram
France Paris

(Country) has-capital (City)

Austria Vienna
20
 Multiplicity of Associations
• Multiplicity is the number of instances of one class that may relate to a single
instance of an associated class.

• 1-to-1
• 1-to-many (0 or more)
• 1-to-(zero-or-one) ‘optional’
• 1-to-(one-or-more) ‘required’
• 1-to-n 1+
n

21
 OMT Multiplicity Notation

Instructor Courses
1+ Teaches

Takes
6-65
Student

Each course has at least one instructor

and between 6 and 65 students
A student may take many courses
An instructor may teach many courses

22
 Link attributes for associations

Person works-for Company

name name
address
salary
job title

23
 Aggregation
• Aggregation is a special form of association that indicates a “part-of” relationship
between a whole and its parts.
• Useful when the parts do not have independent existence.
• A part is subordinate to the whole.
• In an aggregation, properties and operations may be propagated from the whole to
its parts.

24
 OMT Aggregation Notation

Window

TitleBar ScrollBar Border

25
 Multilevel aggregation

Microcomputer

1+

Monitor System box Mouse Keyboard

1+ 1+

Chassis CPU RAM Fan

26
 An Example
FastData Inc. wants a subsystem to process office supply orders via the Web. The user
will supply via a form their name, password, account number, and a list of supplies
along with an indication of the quantities desired. The subsystem will validate the
input, enter the order into a database, and generate a receipt with the order number,
expected ship date, and the total cost of the order. If the validation step fails, the
subsystem will generate an error message describing the cause of the failure.

27
 Purpose of Example
• We will demonstrate the UML /OMT using this example
• Class modeling will be done first
• Dynamic and Functional modeling will occur next
• Detailed design will also occur next

28
Concise Problem Definition
•Define the problem concisely.
• Use only a single sentence
“FastData, Inc. employees may order office supplies via the Web and receive a
receipt confirming the order”.
•This is the first step towards identifying the classes of the subsystem.

29
 Informal Strategy
•Identify the constraints governing the system
• Use only a single paragraph
“FastData, Inc. employees may order office supplies via the Internal Web and
receive a receipt confirming the order. The order must include the user name, user
password, account number, and the list of supplies. A receipt must be generated
containing an order number, ship date, and total cost. If the order is valid, it must be
entered into an order database. If the order is invalid, an error message must be
generated.”
•We now have more information to be used in identifying classes for the subsystem

30
 Formalize the Strategy
•Identify the nouns of the description, which serve as the basis for identifying the
subsystem’s classes.
• Look for out-of-domain nouns (and throw them out!)
• Look for abstract nouns (use these for attributes)
• The remaining nouns are good candidates!
“FastData, Inc. employees may order office supplies via the Internal Web and
receive a receipt confirming the order. The order must include the user name, user
password, account number, and the list of supplies. A receipt must be generated
containing an order number, ship date, and total cost. If the order is valid, it must
be entered into an order database. If the order is invalid, an error message must be
generated.”

31
 Nouns

• Out-of-Domain • Good Candidates

• Internal Web • employee
• Abstract • item (was office supplies)
• user name • receipt
• user password • order
• account number • order database
• order number • error message
• ship date • Notes
• total cost We have decided not to worry
• list of supplies about the Web in this design.
• office supplies -> item Instead we focus on the inputs
and outputs and defer the Web
details until later.

32
 Class Model

employee order order DB

name number
password account
total cost

error message receipt item

explanation order number name

ship date quantity
total cost price

33
 Class Model, continued
Since both receipts and error messages will be generated as output it might make
sense to have them as subclasses of a more general class. We do not know enough
yet to assign it attributes however.

response

error message receipt

explanation order number

ship date
total cost
34
 Class Model, relationships

employee order order DB

name
number
password
account
total cost

1+

error message receipt item

explanation order number name

ship date quantity
total cost price

35
 Overview - Object-Oriented Analysis and Design
• Three models
• Object model
• Dynamic model
• Functional model
• Four phases
• object-oriented analysis
• system design
• object design
• Implementation
• Detailed Design
• Integration Testing

36
 OMT Analysis and Design: Steps
• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel or out of order
• All models must be kept in synch as changes are made

37
 Dynamic Modeling
• Prepare scenarios
• Identify events between objects
• Prepare an event trace for each scenario
• Build a state diagram
• Match events between objects to verify consistency

38
 Dynamic Model Diagrams
• The dynamic model tracks behavior over time.
• described in terms of change in objects or event sequences between objects.
• Event Trace Diagrams
• show typical dialog or usage scenarios as well as exceptional and/or special cases.
• State Diagrams
• relates events, states, and state transitions.
• a scenario is a path through the state diagram.

39
 Events and Scenarios
• An event is something that occurs between objects
• events have attributes, which are the information transferred from one object to
another.
• A scenario is a specific sequence of events representing a path through a system’s
states
• Legitimate scenarios
• common paths (e.g. frequently used functionality)
• Error conditions and known exceptions
• An event trace extends the scenario to clarify events between objects

40
 Event classes and attributes
• Event Classes • Events
• airplane departs (airline, flight • United Flight 23 departs from
number, city) Rome
• mouse button pushed (button, • right mouse button pushed at (29,
location) 30)
• phone receiver lifted • phone receiver lifted
• digit dialed (digit) • digit dialed (2)

41
 An example scenario
• Scenario for a phone call
• caller lifts receiver
• dial tone begins
• caller dials digit (2)
• caller dials digit (7)
• caller dials digit (7)
• caller dials digit (6)
• specified phone rings
• etc.

42
 OMT Event Trace Notation
• objects are vertical lines • arrows indicate sender and receiver
• events are horizontal lines • time passes from top to bottom

Customer Pump Credit Corp

“select method of payment”
select “credit”
insert card
slide card through reader verify account
“select grade” return “approved”
select “premium”
“pump on”
display unit cost, total cost, gallons dispensed
pump gas
update display with total cost, gallons dispensed
charge total cost to account

43
 Event Trace: example
Caller Phone line Callee
caller lifts receiver
dial tone begins
dials (2)
dial tone ends
dials (7)
dials (7)
dials (6)
ringing tone phone rings
answers phone
phones connected phones connected
callee hangs up
connection broken connection broken
caller hangs up
44
 States and Transitions
• A state is an interval between events
• it may have an activity that can trigger starting, intermediate and ending events.
• defined in terms of a subset of object attributes and links.
• A state transition is a change in an object’s attributes and links
• it is the response of an object to an event.
• all transitions leaving a state must correspond to distinct events.

45
 OMT State Notation
• states represented as nodes: rounded rectangles with state name
• initial state represented as solid circle
• final state represented as bull’s eye
• transitions represented as edges between nodes and labeled with an event name

Event-b
STATE-1 STATE-2

Event-a
Event- Event-e
c
STATE-3 Event-d result

46
 OMT State Diagram - Example
Chess game

checkmate
Start White´s Black wins
turn
stalemate

black white
moves moves Draw

stalemate

Black´s
White wins
turn
checkmate

47
 Guards, Activities and Actions
• Guards are boolean conditions on attribute values
• transition can only happen when guard evaluates to “true”
• automatic transitions occur as soon as an activity is complete (check guard!)
• Activities take time to complete
• activities take place within a state
• Actions are relatively instantaneous
• actions take place on a transition or within a state (entry, exit, event actions)
• output can occur with an event

A-STATE [guard-1]
STATE-1
entry / entry-action action-Event / action
do: activity-A
event-1 / action-1 output-Event / output
... guarded-Event [guard-2]
exit / exit-action
STATE-2

48
 Guards, Activities and Actions - Example
Vending machine model
coins in (amount) / set balance
Collecting money
Idle cancel / refund coins coins in (amount) / add to balance

[item empty] select (item)

[change < 0]

do: test item and compute change

[change = 0] [change > 0]

do: dispense item do: make change

49
 OMT State Relationships
• States can be nested or concurrent
• Events can be split and merged event-1

Superstate (nesting) Superstate (concurrency)

event-1 substate-1 substate-3
substate-1 substate-2
event-2

event-3 substate-2 substate-4

event-2

(Synchronization)
event-1 substate-3
split-event-0 substate-1 merged-event-3

event-2 merged-event-4
substate-2 substate-4

50
State Generalization: example

Transmission

push N
Neutral Reverse
push R

push N push F

Forward upshift upshift

stop
First Second Third

downshift downshift

51
 Returning to the FastData example
• Lets define a scenario for an office supply order processor: a successful order
• Alternatively we could describe a scenario for an unsuccessful order.
• Assumptions
• We are not going to consider how the order form is transmitted to our system nor how
our receipt is transmitted back.
• The employee object is responsible for validating the input to the system.

52
 A successful order
• input received (we don’t care how)
• create employee object
• pass input to employee
• validate name and password
• create order object
• validate account number
• for each item
• create item
• add item to order and validate item
• compute total cost
• add order to order DB and retrieve order number and ship date
• generate receipt
• return receipt (we don’t care how)

53
 Event Trace
Employee Order Item Receipt Order Employee Product Account
DB DB DB DB
validate name/password

validated

create

validate account number

validated

create

add
repeat

validate item

validated

54
 Event Trace, continued
Employee Order Item Receipt Order Employee Product Account
DB DB DB DB
compute cost

retrieve cost

add order

retrieve order number

retrieve ship date

create

55
 (One Possible) State Transition Diagram

input
Employee Initialization
Created
received
Idle validated
Employee Order
Validated Created
create
return
receipt validated

Finalize Process Order

Create [remaining
do: add order Item items > 0]
add
create receipt Process Order
Order Finished?
validated
[remaining items = 0]

56
 OMT Analysis and Design: Steps
• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel or out of order
• All models must be kept in synch as changes are made

57
 Functional Modeling
• Identify input and output values
• Build data flow diagrams showing transformation and functional dependencies
(expanding non-trivial processes).
• Describe functions (in some language).
• Identify constraints between objects. (add to DM and FM)

58
 OMT DFD Notation
• Processes transform data
• Actors are sources or sinks of data (= Active Objects)
• Data stores are persistent repositories of data, which may be accessed or
updated (= Passive Objects)
• Data flows between processes, actors, and data stores

data-1 sink-data
Process-1 Process-2 Actor-2

source-data data-2

Actor-1 DataStore-1
59
 Data Value Notation

• Data may be a composed, decomposed, or duplicated

data-1
composite

data-2

data-1
data-
1
composite data-1

data-1
data-
2
60
 Control Flow in the DFD

coded
password Account
verify
password password balance
OK
amount
Customer update
cash

61
 Hierarchical DFD
• High-level functionality iteratively refined into smaller functional units
• each high-level process may be expanded into a separate DFD
• top-level processes correspond to operations on complex objects, while lower-
level processes are operations on basic objects
• Nesting depth is dependent on application
• terminates with simple functions
• each level must be coherent
• Hierarchical DFD corresponds to the following
• context diagram shows boundaries of system
• mid-level DFDs show context decomposition
• primitive DFDs are simple functions that need not be expanded

62
Data Flow Diagram: Office Supply example

Employee Account
DB DB

verification name/ verification

account
password number

Web input validate employee validate order

Server stream employee order

response (receipt)

63
Data Flow Diagram: Office Supply example

Product Order
DB DB

verification item order order

info
order process validated finalize
order order order

response (receipt)

64
 OMT Analysis and Design: Steps
• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel
or out of order
• All models must be kept in synch as changes are made

65
 Add Operations to the Object Model
• From the Object Model:
• Reading/writing object attributes (e.g., get_width, get_height of Rectangle)
• From Events, State Actions, and Activities in the Dynamic Model:
• Each event sent to an object => operation
(e.g., Vending machine: set_balance)
• Actions/activities may be operations
(e.g., Vending machine: do: test item and compute change)
• From Functions in the Functional Model:
• Each function in the DFD corresponds to an operation (e.g., bank example: subtract
withdrawal from Account)

66
 Relation of the three models

Things
object model

Transformations
Interactions functional model
dynamic model
67
 Relation of Dynamic Model to Class Model
• Dynamic model provides a second dimension - time - to objects and classes
• Dynamic model builds upon and is derived from object model
• states in dynamic model represent sets of attribute and link values in object model
• events in dynamic model represent operations in object model
• Relation between organization
• inherent differences in objects are distinguished in object model as distinct classes
• temporal differences in object attributes are distinguished in dynamic model as distinct
states

68
Relation of Functional Model to Class and Dynamic
Model
• Functional model describes the actions (what), the dynamic model describes the
timing (when), and the class model describes what takes action (who)
• Functional model builds upon and is derived from class model
• processes in the functional model correspond to operations on objects
• The input streams of processes in the functional model identify objects that are related by
function
• data flows in the functional model correspond to objects or attribute values in the class
model
• Functional model may capture actions not part of any scenario

69
 OMT: Four phases
• Object-oriented analysis
• builds a real-world model
• System design
• determines overall architecture of system
• Object design
• decides upon data structures and algorithms
• Implementation
• translates design into programming language

70
 System Design
• Devises high-level strategy for solving problem.
• Set trade-off priorities
• Construct system architecture by organizing into subsystems (system structuring).
• Choose an approach for persistent data management (repository model)
• Allocate components to processors and tasks (distribution model)
• Choose the implementation of control in software system (control modeling).
• Identify concurrency inherent in the problem
• Define access to global resources
• Divide problem into implementable components (modular decomposition).

71
 Object Design
• Full definition of all the classes in the system
• Implementation alternatives evaluated and chosen
• Combine three models to obtain class operations
• Design algorithms to implement operations
• Optimize access paths to data
• Implement control for external interactions
• Adjust class structure to increase inheritance
• Design associations
• Determine object representation
• Package classes and associations into implementable modules

72
 Detailed Design
• Detailed design is the process of completely specifying an architectural design
such that module implementation can proceed (independently).
• Interface specifications
• brief description of each module
• attributes
• brief description and specify types
• operations
• brief description
• list of parameters and parameter types
• return type (if applicable)

73
 Detailed Design, continued
• Algorithm and data structure specification
• the designer can give hints as to what algorithms or data structures might be most useful
for a particular module
• also, the client may have specified a particular algorithm or data structure that must be
used
• in addition, constraints in the requirements may require one approach over another
• for instance, implementing a data structure so that it uses the minimum amount of memory possible vs.
keeping everything in memory for speed

74
 Mapping design into code
• Most programming languages provide very similar sets of features
• user-defined types
• control structures
• if...then...else...
• while x do y
• for i = 1 to x
• etc
• etc.
• This means that, in general, operations can be expressed in many different
languages

75
 Mapping design into code, continued
• Major differences between languages usually fall into these categories
• compiled vs. interpreted
• procedural vs. object-oriented
• general purpose vs. application/domain specific
• e.g. C++ vs. FileMaker Pro’s scripting language
• If a design takes advantage of, or depends on, one or more of these features
then certain programming languages have to be excluded from implementation

76
 Modularity Mechanisms
• One import feature of any programming language is how it can represent
modules directly.
• C and C++ have separate header and body files
• Java has package names and class files
• Ada has a construct called a package with a specification and body (implementation)
• etc.
• These features are important since it makes it easier to map the design into code
and to trace a code module back to its design counterpart.

77