Software Engineering SI334
Lessons 24, 26 – 28 & 30:
Classical & Object-Oriented Design
October 6, 8, 10, 15, 2014
Software Engineering SI334
Data and Actions

Two aspects of a product
 Actions that operate on data
 Data on which actions operate

The two basic ways of designing a product
 Operation-oriented design
 Data-oriented design

Third way
 Hybrid methods
 For example, object-oriented design
© The McGraw-Hill Companies, 2011
2
Software Engineering SI334
* Object-Oriented Design

Classes are extracted during the object-oriented analysis
workflow, and
 Designed during the design workflow

Accordingly
 Classical architectural design corresponds to part of the
object-oriented ____________workflow
analysis

Classical detailed design corresponds to part of the
object-oriented ____________workflow
design
© The McGraw-Hill Companies, 2011
4
Software Engineering SI334
*Object-Oriented Design

Goal: Design product
in terms of objects identified during OOA

OOD consists of two key steps:
1. Complete the detailed class diagram
2. Perform the detailed design
5
Software Engineering SI334
*Object-Oriented Design

Completing the detailed class diagram consists of:
1. Determining the formats of the attributes
a.
Formats of attributes generally deduced directly from analysis
artifacts
2. Determining the methods and assigning them to the relevant
classes
a.
b.
Methods determined by constructing interaction diagrams for each
scenario. Two flavors:
i. Collaboration diagrams (Spatial) and
ii. Sequence Diagrams (Temporal)
Methods assigned to classes by designing the product in terms of
clients of objects
6
Software Engineering SI334
*Determining Class’ Attributes
Consider class Elevator Controller
 If User wants to check and update
requests, needs requests attribute
 Needs methods:
 check requests,
 update requests
Detailed: As used here means that all
method names, and (as a by-product)
attributes ID’d by designer, are
represented on the diagram
7
Software Engineering SI334
Interaction Diagrams

Construct interaction diagrams for each scenario; focus is
on objects and the messages passed between them.
 “Passing a message” between objects really means having
one object invoke a public method of another object.
An interaction is implemented by a group of objects that collaborate by
exchanging messages.
These messages are represented along the links that connect the objects,
using arrows pointed towards the recipient of the message.
open doors
Elevator Controller
Elevator Doors
close doors
Example: An elevator
controller that asks the doors
to open and close themselves
9
Software Engineering SI334
*Collaboration Diagrams: spatial representation

Focus is on the relationships between objects
 Structure becomes clear
 Timing info is obscure, messages numbered to indicate
sending order
Actors represent the triggering of interactions by
Example: Elevator Controller
requesting Elevator move up one
floor
an element that is external to the system
Example: A Person Calling an Elevator
Elevator Controller
*move up
one floor
Elevator
10
Software Engineering SI334
*Sequence Diagrams: temporal representation

Focus is on message broadcast chronology of interactions
between objects.



An object is represented by a rectangle and a vertical bar called the object's lifeline.
The message sending order is indicated by position of message on vertical axis.
Vertical axis may be labeled to express temporal constraints precisely.
Loops and conditional branches may be represented.
Example: Shows that object A sends a message to
object B or object C according to a condition (X).
11
Software Engineering SI334
Use Scenarios to Create Interaction Diagrams
Example of a Normal Use Scenario
13
Software Engineering SI334
Collaboration Diagram
Start with diagram of objects and actors
14
Software Engineering SI334
*Collaboration Diagram
Use scenario to identify messages passed among objects
Some messages, such as
start timer (steps 7, 15) go
from an object to itself
Most other messages, such as press floor button
(step 1) open doors (steps 6, 14) go from an actor
to an object, or from one object to another
15
Software Engineering SI334
*ICE- Complete Elevator Collaboration Diagram
16
Software Engineering SI334
*Equivalent Sequence Diagram
17
Software Engineering SI334
Homework- Interaction Diagrams
Produce an interaction diagram (your choice of sequence or
collaboration) for the Apartment Automatic Garage Door
Scenario 1: “User swipes card and drives car into garage.”
Scenario 1
1.
2.
3.
4.
5.
6.
7.
8.
Driver A swipes card.
If door is open, GarageDoorController resets timer.
If door is closed, GarageDoorController sends msg to
Garage Door to open.
When door is fully opened, DoorOpenSensor notifies
GarageDoorController.
GarageDoorController resets timer.
Timer times out; GarageDoorController notified.
GarageDoorController sends msg to GarageDoor to
close.
When door is fully closed, DoorClosedSensor notifies
Garage DoorController.
19
Software Engineering SI334
*Assigning Methods to Classes


A well-structured Interaction Diagram gives very specific
information on what responsibilities a class should have.
Main question, do we assign an action to a class or to a
client of that class?
Things to consider:
• Information hiding
• Reducing # of copies of an action
• Responsibility-driven design


Examples
• close doors assigned to? Elevator Doors
• move one floor down assigned to? Elevator
Typical: Class at head of arrow on Interaction Diagram gets tasked with the
labeled responsibility, and implements it as a method.
20
Software Engineering SI334
*Determine Clients of Objects

Design Product in Terms of Clients of Objects to determine
which objects should create other objects



Draw a single arrow from each object to a client of that object
Objects that are not clients of any object have to be initiated,
probably upon system launch, Additional methods may be needed.
elevator controller needs method elevator event loop
so that elevator application can call it.
This Completes
High-Level Design
for OOD!
21
Software Engineering SI334
ICE- Detailed Class Diagrams
ICE: Complete the Detailed Class Diagram for the
Elevator, showing all method names and attributes
identified by the designer for each class.
22
Software Engineering SI334
Homework- Detailed Class Diagrams
Homework: Produce a Detailed Class Diagram for the
Apartment Automatic Garage Door, showing all method
names and attributes identified by the designer.
Scenario 1
1.
2.
3.
4.
5.
6.
7.
8.
Driver A swipes card.
If door is open,
GarageDoorController resets timer.
If door is closed,
GarageDoorController sends msg to
Garage Door to open.
When door is fully opened,
DoorOpenSensor notifies
GarageDoorController.
GarageDoorController resets timer.
DoorCloseTimer times out;
GarageDoorController notified.
GarageDoorController sends msg to
GarageDoor to close.
When door is fully closed,
DoorClosed
Sensor notifies
GarageDoorController
23
Software Engineering SI334
*Step 2 of OOD: Perform Detailed Design

Detailed design of method elevator event loop, draws
heavily from prior UML diagrams. Design Team:
 Should not do too much:
• Detailed design should not become complete code

Should not do too little:
• It is essential for detailed design to fully indicate how all
functionality is met.

So, what should detailed design’s output be?

Detailed Design’s output is program description language for all
the Classes in Detailed Class diagram, with fully described
interfaces.
24
Software Engineering SI334
*Step 2 of OOD: Perform Detailed Design
[button pushed,
button lit]
[no requests pending,
doors closed]
Elevator Controller Loop
[button
pushed,
button
unlit]
[elev ator
mov ingin
direction d,
f loor f is next
]
[elev ator
stopped,
request(s)
pending]
Process Request
do/ update requests
do/ turn on button
[elev ator
stopped,
no requests
pending]
Go Into Wait State
do/ close elev ator doors
af ter timeout
Determine If Stop Requested
do/ check requests
[no request
to stop at
f loor f ]
[user has
requested stop
at f loor f ]
Continue Moving
do/ mov e elev ator
one f loor in
direction d
Close Elevator Doors
do/ close doors af ter
timeout
Stop At Floor
do/ stop elev ator
do/ open doors
do/ update requests
[elev ator
button
lit]
[f loor
button
lit]
[f loor
button
unlit]
Floor Button Off
do/ turn of f f loor
button
[elev ator
button
unlit]
Elevator Button Off
do/ turn of f elev ator
button
Process Next Request
do/ mov e elev ator one f loor
in direction of next
request.
25
Software Engineering SI334
ICE/Homework- Detailed Design
ICE/Homework: Produce a Detailed Design for method
garageDoorControlLoop in class GarageDoorController for the
Apartment Automatic Garage Door, using Java-like pseudo-code.
26
Software Engineering SI334
Real-Time Design Techniques

Difficulties associated with real-time systems
 Inputs come from the real world
• Software has no control over the timing of the inputs

Frequently implemented on distributed software
Major difficulty in design
• Communications implications
of real-time systems?
• Timing issues
• Determining whether

Problems of synchronization
• Race conditions
• Deadlock (deadly embrace)
© The McGraw-Hill Companies, 2011
timing constraints are met
by the design
27
Software Engineering SI334
* Design Testing

Design reviews are essential
 A client representative is not usually present (except in
DoD procurements)

Types of faults uncovered:




logic faults
interface faults
lack of exception handling
non-conformance to specification
© The McGraw-Hill Companies, 2011
28
Software Engineering SI334
*Testing During the Design Workflow

Goal of Design Testing- answer the following:
 Is the specification accurately and completely
incorporated into the design?
 Is the design itself correct?
• No logic faults
• Interface for each class fully defined.

Design reviews. Purpose is to show that Design correctly
reflects the Specification. How can this be shown?


Show how each normal/abnormal scenario is met by the design.
Critical that proper set of scenarios was developed during OOA.
29
Software Engineering SI334
Formal Techniques for Detailed Design


Implementing a complete product and then proving it
correct is hard
However, use of formal techniques during detailed design
can help
 Correctness proving can be applied to module-sized
pieces
 The design should have fewer faults if it is developed in
parallel with a correctness proof
 If the same programmer does the detailed design and
implementation
• The programmer will have a positive attitude to the
detailed design
• This should lead to fewer faults
© The McGraw-Hill Companies, 2011
30
Software Engineering SI334
*Case Tools for OOD

UpperCASE tools
 Examples of UpperCASE tools:
• Software through Pictures,
• Visual Paradigm
• Rational Rose
 Built around data dictionary
 Screen, report generators
 What automated support could be provided by a case tool
that represents OOD using UML?
• Automated conversion between Diagrams,
• Generation of Class Constructs from Class Design with Class names,
attributes, methods filled in.
• Programmers focus on fleshing out method bodies
31
Software Engineering SI334
*Metrics for OOD


What Metrics can be used to describe various aspects of
the Design?
One is McCabe’s Cyclomatic complexity. Measure based
on # of control flow decisions, can apply to pseudo-code.
 the number of binary decisions plus 1,
 a metric of design quality, the lower the M the better
• Advantage: Easy to compute, can be automated
• Disadvantage: Measures control complexity only, does not measure data
complexity.

What other aspects of a Design can be Measured?


Raw number of modules gives a crude measure of size of the targeted product.
Couplings between Modules and Cohesiveness of Modules.
32
Software Engineering SI334
Design and Abstraction

Classical design activities
 Architectural design
 Detailed design
 Design testing

Architectural design



Input:
Output:
Specifications
Modular decomposition
Detailed design

Each module is designed
• Specific algorithms, data structures
© The McGraw-Hill Companies, 2011
33
Software Engineering SI334
Data and Actions

Two aspects of a product
 Actions that operate on data
 Data on which actions operate

The two basic ways of designing a product
 Operation-oriented design
 Data-oriented design

Third way
 Hybrid methods
 For example, object-oriented design
© The McGraw-Hill Companies, 2011
34
Software Engineering SI334
Operation-Oriented Design

Data flow analysis
 Use it with most specification methods (Structured
Systems Analysis here)

Key point: We have detailed action information from the
DFD
Figure 14.1
© The McGraw-Hill Companies, 2011
35
Software Engineering SI334
Data Flow Analysis

Every product transforms input into output
Figure 14.1
36
Software Engineering SI334
Data Flow Analysis


Every product transforms input into output
Determine
 “Point of highest abstraction of input”
 “Point of highest abstract of output”
After Figure 14.2
37
Software Engineering SI334
Data Flow Analysis (cont.)

Use these points to decompose the product into three
modules
Figure 14.2

Repeat stepwise until each module has high cohesion
(degree of interaction within a module)
 Minor modifications may be needed to lower the
coupling (degree of interaction between two modules)
© The McGraw-Hill Companies, 2011
38
Software Engineering SI334
*Mini Case Study: Word Counting

Example:
Design a product which takes as input a file name, and
returns the number of words in that file (like UNIX wc )
Figure 14.3
© The McGraw-Hill Companies, 2011
39
Software Engineering SI334
*Mini Case Study: Word Counting (cont.)

First refinement
Figure 14.4

Now refine the two modules of communicational cohesion*
(*module performs series of operations (on same data) related by sequence of steps to be followed)
© The McGraw-Hill Companies, 2011
40
Software Engineering SI334
Mini Case Study: Word Counting (cont.)

Second refinement

All eight modules now have functional cohesion*
(*module that performs exactly one operation or achieves a single goal)
© The McGraw-Hill Companies, 2011
Figure 14.5
41
Software Engineering SI334
Data Flow Analysis Extensions

In real-world products, there is
 More than one input stream, and
 More than one output stream
© The McGraw-Hill Companies, 2011
42
Software Engineering SI334
Data Flow Analysis Extensions (cont.)

Find the point of highest abstraction for each stream

Continue until each module has high cohesion
 Adjust the coupling if needed
© The McGraw-Hill Companies, 2011
Figure 14.8
43
Software Engineering SI334
ICE- Course Project Data Flow Analysis
ICE: Produce a high-level Data Flow Diagram
(DFD) for your course project, showing the point of
highest abstraction of input and point of highest
abstraction of output.
44
Software Engineering SI334
*Detailed Design

The architectural design is complete
 So proceed to the detailed design

Two formats for representing the detailed design:


Tabular
Pseudocode (PDL—program description language)
© The McGraw-Hill Companies, 2011
45
Software Engineering SI334
Detailed Design: Tabular Format
© The McGraw-Hill Companies, 2011
Figure 14.6(a)
46
Software Engineering SI334
Detailed Design: PDL Format
Figure 14.7
© The McGraw-Hill Companies, 2011
47
Software Engineering SI334
Data-Oriented Design

Basic principle
 The structure of a product must conform to the structure
of its data

Three very similar methods
 Michael Jackson [1975], Warnier [1976], Orr [1981]
48
Software Engineering SI334
Data-Oriented Design

Basic principle
 The structure of a product must conform to the structure
of its data

Three very similar methods
 Michael Jackson [1975], Warnier [1976], Orr [1981]

Data-oriented design
 Has never been as popular as action-oriented design
 With the rise of OOD, data-oriented design has largely
fallen out of fashion
50
Software Engineering SI334
Recap: Relationships Between UML Diagrams
51