Software Engineering,
CPSC-4360-01, CPSC-5360-01,
Lecture 4
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
1
Review of Last Lecture





Introduction to Case Studies
Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
Activity Diagram
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
2
Overview of This Lecture

Analysis


Software Architecture
Use Case Realization


Domain Model Refinement

4/13/2015
Use Case → Sequence Diagrams
Domain Model → Partial Class Diagram
CPSC-4360-01, CPSC-5360-01, Lecture 4
3
Where are we now?

Requirement
Analysis

Analyze the system
requirements.
Use Case Realization:

Design
Implement
Understanding how
business entities can be
used to support use cases.
Test
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
4
Analysis: Overview

Inputs:



Use Cases.
Domain Model.
Activities:



4/13/2015
Draft Software Architecture.
Realize Use Cases into Sequence Diagrams.
Refine Domain Model into Analysis Class
Diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 4
5
Analysis: Overview




The first bridging step from the external view (system
behavior) to the internal view (system implementation).
Requirements (Use Cases) give the external view.
The Domain Model gives structural information about
business entities.
The Analysis is performed to understand how the
business entities can be implemented and support use
cases via Use Case Realization:


Adding operations to the business entities;
Move closer to an actual class in program.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
6
Difference between Analysis & Design

Distinction is not clear between the two activities:



Analysis:



Usually seen as one continuous activity with no clear
boundary;
Made worse by using the same UML diagrams.
Describes the structure of a real-world application;
Focus on requirements of system.
Design:


Describes the structure of a proposed software
system;
Focus on software structure that implements the
system.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
7
Difference between Analysis & Design



While analysis model refers to identifying relevant
objects in the real-world system, the design model is
adding specific implementation details to the underlying
analysis model.
Famous phrase (page 7, [Larman, 2005]): “do the right
thing (analysis), and do the thing right (design).”
Example: Flight Information System [Larman, 2005]


Analysis: finding and describing the concepts/objects: Plane,
Flight, Pilot, …
Design: defining software objects and how they collaborate to
fulfill the requirements: a Plane object may have a tailNumber
attribute and a getFlightHistory() method, …
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
8
What is Software Architecture?

High level description of the overall system:



Grouping of classes to:



Improve Cohesion.
Reduce Coupling.
Cohesion:


The top-level structure of subsystems.
The role and interaction of these subsystems.
Set of “things” that work well together.
Coupling:

4/13/2015
Inter-Dependency between two entities.
CPSC-4360-01, CPSC-5360-01, Lecture 4
9
Software Architecture: Example

Take the minesweeper game as an example, and
identify the high level components:

Display:


Application Logic:



Determining the flags, numbers.
Checking whether there are more
mines, etc.
Record Storage:

4/13/2015
Showing the game graphically.
Storing high scores, setting, etc.
CPSC-4360-01, CPSC-5360-01, Lecture 4
10
Minesweeper: System One
class Minesweeper{

public void ClickOnSquare( ){
if (square == bomb) {
gameState = dead
show dead icon
write high score to file
}
else if (square == number){
open neighboring squares
mark squares as opened
display new board
}
}
………..// some other code
}
4/13/2015
Bad Cohesion:




Display functions all
over the place.
Application logic buried
under other operations.
Storage function not
clearly separated.
Low Coupling:

Since there is only one
class, there is no interdependency!
CPSC-4360-01, CPSC-5360-01, Lecture 4
11
Minesweeper: System Two
class MSGUI {
class Minesweeper {
Minesweeper msApp;
MSStorage msStore;
MSStorage msStore;
public void openSquare(position){
if (square == bomb)
gameState = dead;
else if (square == number){
open neighboring squares
mark squares as opened;
}
}
public void mouseClickOnSquare( ){
msApp.openSquare(..);
board =
msApp.getCurrentBoard(..);
show(board);
}
public void menuExitClick( ) {
score = msApp.getHighScore( );
msStore.writeHighScore(score);
}
public Board getCurrentBoard() {
..
}
}
class MSStorage {
public void writeHighScore(..){ }
public void writeBoard(..) { }
public void saveCurrentBoard() {
msStore.writeBoard(..);
}
}
}
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
12
Minesweeper: System Two

Cohesion:


Each class groups logically similar functionality together:
 Class MSGUI: user interface, input/output to screen;
 Class Minesweeper: computation and logic;
 Class MSStorage: file operations.
Coupling:



4/13/2015
Some interdependencies. Can be improved.
Observe that MSGUI uses MSStorage directly.
Hence, if we substitute another user interface, the high
score saving functionality needs to be recorded.
CPSC-4360-01, CPSC-5360-01, Lecture 4
13
Minesweeper: System Three
class MSGUI {
Minesweeper msApp;
// MSStorage msStore;
class Minesweeper {
MSStorage msStore;
Not needed
.. .. ..
.. .. ..
public void menuExitClick( ) {
msApp.closingDown( );
}
public void closingDown() {
msStore.writeHighScore(..)
}
}
public void saveCurrentBoard() {
}
class MSStorage {
}
public void writeHighScore(..){ }
public void writeBoard(..){ }
}
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
14
Minesweeper: System Three

Coupling:


Reduced. MSGUI depends on Minesweeper only.
Minesweeper depends on MSStorage only.
Low coupling enables easy maintenance, e.g.:


4/13/2015
Changing MSGUI to MSTextUI would not affect the
main application at all.
Can swap in another storage class, e.g., database
storage, by providing the same methods.
CPSC-4360-01, CPSC-5360-01, Lecture 4
15
Minesweeper: Systems Comparison
System 1
System 2
System 3
MSGui
Minesweeper
Minesweeper
Minesweeper
MSGui
MSStorage
MSStorage
Bad Cohesion
Good Cohesion
Good Cohesion
No Coupling
Medium Coupling
Low Coupling
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
16
Minesweeper: Observations

Trade off between cohesion and coupling:


The three categories of functionality are quite widely
applicable:




Improving cohesion usually implies worse (higher) coupling
and vice versa.
User Interface.
Main Application Logic.
Storage (Persistency).
These observations help shaping Software
Architecture:

4/13/2015
splitting a system into sub-systems.
CPSC-4360-01, CPSC-5360-01, Lecture 4
17
The Layered Architecture


One of the oldest idea in Software Engineering.
Split into three separate layers:

Presentation Layer


Application Layer



The underlying logic.
Implements the functionality of system.
Storage Layer


User Interface.
Deals with data storage: files, database, etc.
The layers are higher level abstraction:

4/13/2015
Each may contain several classes, or several packages
(group of classes).
CPSC-4360-01, CPSC-5360-01, Lecture 4
18
UML Package Diagram
Package:
Collection of
classes or subpackages.
4/13/2015
Dependency:
Represent the “make
use of” relationship .
CPSC-4360-01, CPSC-5360-01, Lecture 4
19
Minesweeper: Package Diagram
Presentation
MSGUI

Application
Minesweeper
Corresponds to
programming construct:


Java: Package.
C++: namespace.
Storage
MSStorage
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
20
Layered Architecture: Advantages


Layers aim to insulate a system from the
effects of change.
For example, user interfaces often change:



but the application layer does not use the
presentation layer.
so changes to system should be restricted to
presentation layer classes.
Similarly, details of persistent data storage
are separated from the application logic.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
21
Analysis Class Stereotypes

Within this architecture, objects can have
various typical roles:





boundary objects: interact with outside actors.
control objects: manage use case behaviour.
entity objects: maintain data.
These are represented explicitly in UML by
using analysis class stereotypes.
Give extra informal information for objects.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
22
Class Stereotype Notation


Stereotypes can be text or a graphic icon.
The icon can replace the normal class box.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
23
Use Case Realization: Overview
Use case realization = implementation of the use case.
 Steps:




Possible refinements:




Go through each use case.
Identify interaction using a UML sequence diagram.
Refine the domain class diagram.
Adding a new class and/or data.
Define association nagivability (direction) and role name.
Adding operation to an existing class.
Focus is on System Functionality during Analysis phase.


Ignore other layers (Presentation and Storage).
Concentrate on the Application layer.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
24
Sequence Diagram

UML Diagram to:





Emphasize the interaction in the form of messages.
Identify the party involved in the interaction.
Outline the timing of the message.
Be mainly used in Analysis and Design activities.
Analogy to help you understand:



In OO programs, objects interact with each others via method
invocation (method call).
Method invocations can be modeled as messages passing
between objects:
 ObjectA calls method M of ObjectB, is equivalent to
 ObjectA passes message M to ObjectB.
Sequence Diagram records these message passing.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
25
Sequence Diagram Notation

Simpler version of the sequence diagram used in
design activity.
Entities
Actors or Classes
involve in
interaction
Message
With parameter
Class
Actor
Message ( Para )
Activation
Bar
Lifeline
Returned value
Time
Passes
Return
Control and
possibly value
are returned
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
26
Sequence Diagram: Explanation


Time passes from top to bottom.
Classes and actors at top:



only show those participating in this interaction.
each instance has a lifeline.
Messages shown as arrows between lifelines:



4/13/2015
labelled with operation name and parameters.
return messages (dashed) show return of control.
activations show when the receiver has control.
CPSC-4360-01, CPSC-5360-01, Lecture 4
27
Sequence Diagram: Simple Example
class A {
public void example( ) {
B objB;
int result;
:B
:A
method ( 123 )
//Sequence diagram shows the
//following interaction
result = objB.method(123);
Returned 456
}
}
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
28
Case Study 1: Use Case Realization

Take Display Booking use case as example:
Display Bookings: Basic Course of Events

Staff enters a date;

System displays bookings for that date.

The initial realization consists of:



4/13/2015
Staff sends a
message.
System
returns
results.
The Staff actor.
The System.
Message(s) passed between them.
CPSC-4360-01, CPSC-5360-01, Lecture 4
29
Case Study 1: Use Case Realization

The domain model shown in Lecture 3 does not
contain a System class.


The Domain Model only concentrates on entities in the
real world.
A new class BookingSystem is added:


An example of domain model refinement.
Categorized as a control stereotype:



Receives a high level request from the user.
Contacts the relevant classes to fulfill the request.
Boundary stereotype is not appropriate:

4/13/2015
Emphasizes on the use case behavior, not input/output.
CPSC-4360-01, CPSC-5360-01, Lecture 4
30
Case Study 1: Sequence Diagram
New class
added
System
Message

The display(date) message originates from outside
the system (it was called by an external user - Staff):

4/13/2015
Termed as System Messages (opposite to Internal
Messages, called from an object of the system).
CPSC-4360-01, CPSC-5360-01, Lecture 4
31
System Sequence Diagram (SSD)

Is a Sequence Diagram that shows only
system messages:




4/13/2015
An informal subtype of sequence diagram.
Concentrates on user-system exchange only.
Graphical representation of a use case.
Serves as a starting point for a more complete
sequence diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 4
32
Case Study 1: Refining SSD
?



How does the BookingSystem retrieves the bookings?
Who should keep track of the bookings?
Bad choices:


4/13/2015
BookingSystem (why?)
Booking (why?)
CPSC-4360-01, CPSC-5360-01, Lecture 4
33
Case Study 1: Refining SSD


A class to store a collection of Bookings is needed.
Adding this ability to BookingSystem is undesirable:



Booking class in domain model:


BookingSystem should only handle system messages.
Lower the cohesion of the class.
Only records details of one booking. Not a collection.
Hence, another new class is needed:


4/13/2015
Restaurant class is a reasonable choice.
Can take care of other collections:
 Tables.
 Customers.
CPSC-4360-01, CPSC-5360-01, Lecture 4
34
Case Study 1: Sequence Diagram Ver.1
New
Class
New
Internal
Message
UI is not the focus at
this stage. A
placeholder function.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
35
Case Study 1: Sequence Diagram Ver.1

The sequence diagram tells us:



Staff wants to check a booking for a particular date.
BookingSystem receives the request and asks the
Restaurant to provides all bookings on that date.
Follow up:


How can Restaurant find the relevant bookings from
all bookings record?
One plausible way:

4/13/2015
Checks the date on each booking record, and collects
only those that match.
CPSC-4360-01, CPSC-5360-01, Lecture 4
36
Case Study 1: Sequence Diagram Ver.2
* denotes
multiple
messages
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
The Booking class
identified in the
domain model
37
Case Study 1: Display Booking realization



At this point, a plausible sequence of messages to achieve
the use case has been identified.
The sequence diagram can be used to refine the domain
model.
Several key refinements:


New Restaurant and BookingSystem classes with an
association between them.
A new association from Restaurant to Booking.



Restaurant maintains links to all bookings.
Messages sent from restaurant to bookings.
Association from BookingSystem to Booking.
•
•
4/13/2015
BookingSystem maintains links to currently displayed bookings.
If these were not stored once they had been displayed, then
whenever the display was updated, the current bookings would
have to be retrieved again from the Restaurant object.
CPSC-4360-01, CPSC-5360-01, Lecture 4
38
Case Study 1: Updated Class Diagram
(Partial)
New class
added
New
association
added
Operation
added
Association
refined
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
39
Refining Association

As we move closer to internal representation of
the system, more technical information is
needed for association.
A

rName
B
Two possible refinements:


4/13/2015
Add navigability: The arrow above shows only A
can interact with B, but not vice versa.
Add role name: A uses rName as the reference
name of B.
CPSC-4360-01, CPSC-5360-01, Lecture 4
40
Refining Association: Example
Human
Eats >
1
Mee
Eats >
Human
1
Mee
myFood
Domain Model

Class Diagram
The refined class diagram tells us:


Only Human is aware of the Mee, i.e.,
Human sends message to Mee, but not
the other way around.
Human uses a reference myFood to
refer to the instances of Mee, i.e.:
class Human {
Mee myFood;
void method( ) {
myFood.cook( );
}
}
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
41
Case Study 1: Display Booking realization


The Display Booking use case realization is
complete at this point.
Review:




4/13/2015
Stop at System Sequence Diagram to make sure
that every exchange between user and system is
modeled.
From the SSD, figure out how entities in domain
model can help to fulfill the request.
Add in the appropriate messages.
Refine domain model.
CPSC-4360-01, CPSC-5360-01, Lecture 4
42
Case Study 1: Continuing Use Case
Realization


The basic technique has already been
explained.
Several Use Case realizations are chosen
from Case Study 1 to highlight:

Additional notation for Sequence Diagram:



4/13/2015
Object Creation/Deletion.
Role Name to distinguish objects of the same class.
Other possible refinement to domain model.
CPSC-4360-01, CPSC-5360-01, Lecture 4
43
Case Study 1: Record Booking realization


Restaurant is responsible for maintaining all bookings.
makeReservation() should be handled by Restaurant.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
44
Case Study 1: Record Booking realization

Bookings must be linked to Table and
Customer:


Restaurant retrieves these with the given identifying
data in booking details.
New objects shown at point of creation:


4/13/2015
Lifeline starts from that point.
Objects created by a message arriving at the
instance, i.e., constructor.
CPSC-4360-01, CPSC-5360-01, Lecture 4
45
Case Study 1: Creating New Booking
Object
Constructor Message
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
New Object
46
Case Study 1: Cancel Booking realization

A three-stage process:




Object deletion represented by a message with
a <<destroy>> stereotype.


Select the booking to be cancelled.
Confirm cancellation with user.
Delete the corresponding booking object.
Lifeline terminates with an ‘X’.
Role names used to distinguish the selected
object from others.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
47
Case Study 1: Cancel Booking Sequence
Diagram
Destruction
message
4/13/2015
Role
Name
Lifeline
Terminated
CPSC-4360-01, CPSC-5360-01, Lecture 4
48
Case Study 1: Domain Model
Refinement Continues
Association
Added


BookingSystem has the responsibility to
remember which booking is selected.
Adds an association to record this.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
49
Case Study 1: Record Arrival Realization
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
50
Case Study 1: Record Arrival Realization

Selected Booking must be a Reservation.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
51
Case Study 1: Refining Class Diagram

Should setArrivalTime( ) be defined in
Booking or in Reservation class?



On the one hand, it doesn't apply to Walk-Ins.
But a common interface to all bookings is
desirable.
Define operation in Booking class.


4/13/2015
Default implementation does nothing.
Override in Reservation class.
CPSC-4360-01, CPSC-5360-01, Lecture 4
52
Case Study 1: Refining Class Hierarchy
Common
interface for
all
subclasses
Override
in
subclass
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
53
Case Study1: Complete Analysis Class
Model
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
54
Where are we now?
Requirement

Analysis
Design
Typical Artifacts:



Software Architecture
Sequence Diagrams
Analysis Class Diagram
Implement
Test
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
55
Summary

Analysis has led to:




A set of use case realizations.
A refined class diagram.
We can see how the class design is going to
support the functionality of the use cases.
This gives confidence that the overall design
will work.
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
56
Reading Suggestions


Chapter 4 of [Bimlesh, Andrei, Soo; 2007]
Chapter 5 of [Priestley; 2004]
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
57
Coming up next



Object-oriented design – Chapter 5 of
[Bimlesh, Andrei, Soo; 2007]
Design - Chapter 6 of [Priestley; 2004]
UML Class and Object Diagrams - Chapter 8
[Priestley; 2004]
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
58
Thank you for your attention!
Questions?
4/13/2015
CPSC-4360-01, CPSC-5360-01, Lecture 4
59