CS3354 – Object Oriented Design
and Implementation
Object Oriented Design with UML – Part 1
Instructor: Vangelis Metsis
Review of software engineering
• Software Engineering is a collection of techniques, methodologies
and tools that help with the production of
✦a high quality software system
✦with a given budget
✦before a given deadline
• while change occurs.
• Software engineering is an engineering discipline that is
concerned with all aspects of software production
2
Software Engineering Activities

Specification – defining what the system should do (stating the
requirements)

Development – defining the organization of the system (aka the
design) and implementing the system

Validation – checking that the system does what the customer wants

Evolution – changing the system in response to customer needs.

Waterfall vs. Iterative Development
3
Object-oriented software development
• Specification:
✦Requirements elicitation
✦Object-Oriented Analysis
• Development
✦System design
✦Object-Oriented Design
✦Object-Oriented Implementation
• Testing
• Evolution
4
Analysis

Analysis: an investigation of the problem (rather than developing a
solution)

Functional Specification





Completely defines tasks to be solved
Free from internal contradictions
Readable both by domain experts and software developers
Reviewable by diverse interested parties
Testable against reality
5
Design
• Design: a conceptual solution (not code) that fulfills the requirements. It
describes the structure and behavior of the program.
✦Ultimately, designs can be implemented.
Goals
• Identify classes
• Identify behavior of classes
• Identify relationships among classes
Artifacts
• Textual description of classes and key methods
• Diagrams of class relationships
• Diagrams of important usage scenarios
• State diagrams for objects with rich state
6
Object-oriented programming (or
implementation)
• Designs are implemented in an object-oriented language such as
Java or C++.
✦A Java class for the Book object is written/implemented.
✦Expressed in a program (source code)
•
•
•
•
Implement and test classes
Combine classes into program
Avoid "big bang" integration
Prototypes can be very useful
7
Object Oriented
Analysis + Design + Implementation
Analysis
investigation
of the problem
Book
(concept)
Domain concept
Design
logical solution
Book
title
print()
Visualization of
domain concepts,
represented using
models
Implementation
code
public class Book {
public void print();
private String title;
}
Representation in an
object-oriented
programming language.
8
What is UML?

Unified Modeling Language

UML is a notation to articulate complex ideas in Object-Oriented
software development

UML resulted from a unification of many existing notations.

The goal of UML is to provide a standard notation that can be used by
all object-oriented development methods (software processes)

UML includes:
✦
✦
✦
✦
✦
✦
Use Cases and Use case diagrams
Class Diagrams
Sequence Diagrams
State Diagrams
Activity Diagrams
etc.
9
What is a Model?
• A Model is
✦ a means for dealing with complexity.
✦ an abstract description of a system that focuses on interesting aspects and ignores
irrelevant details
✦an abstraction describing a subset of a system.
✦NOT a diagram or notation
10
Object-oriented modeling
• The application domain is all aspects of the customer’s “problem”.
✦ physical environment
✦ users and other people
✦ their work processes, etc.
✦Object-oriented analysis models the application domain
• The solution domain is the modeling space of all possible solutions.
✦ represents system design and object design
✦ richer and more volatile than application domain, more detail.
✦ Object-oriented design models the solution domain
• Both use the same representation (classes, associations, etc)
11
Object and Class Concepts

Object: Three characteristic concepts

State


Behavior


The operations (or methods, as they are called in Java) that an object
supports.
Identity


The collection of all information held by an object.
It is possible for two or more objects to support the same operations
and to have the same state, yet to be different from each other.
Class: Collection of similar objects
12
Identifying Classes
Case Study: A Voice Mail System
Rule of thumb: Look for nouns in problem description
 Mailbox
 Message
 User
 Passcode
 Extension
 Menu
Focus on concepts, not implementation
 MessageQueue stores messages
 Don't worry yet how the queue is implemented
13
Categories of Classes

Tangible Things


Agents


MailSystem to represent the voice mail system in its entirety
System interfaces and devices


Administrator
Systems


MouseEvent class
Users and Roles


Agent classes often end in “er” or “or”. E.g. Scanner
Events and Transactions


Mailbox, Message, Document, Footnote.
File class.
Foundational Classes

14
String, Date, …
Identifying Responsibilities
Rule of thumb: Look for verbs in problem description
Behavior of MessageQueue:

Add message to tail

Remove message from head

Test whether queue is empty



OO Principle: Every operation is the responsibility of a
single class
Example: Add message to mailbox
Who is responsible: Message or Mailbox?
15
Class Relationships

Dependency ("uses")
Aggregation ("has")
Inheritance ("is")

Dependency Relationship





16
C depends on D: Method of C manipulates objects of D
Example: Mailbox depends on Message
If C doesn't use D, then C can be developed without knowing
about D
Coupling

Minimize dependency: reduce coupling

Example: Replace
void print() // prints to System.out
with
String getText() // can print anywhere

Removes dependence on System, PrintStream
17
Aggregation




Object of a class contains objects of another class
Example: MessageQueue aggregates Messages
Example: Mailbox aggregates MessageQueue
Implemented through instance fields
Multiplicities
1:1 or 1:0..1 relationship:

public class Mailbox {
private Greeting myGreeting;
}
1:n relationship:
public class MessageQueue {
private ArrayList<Message> elements;
}18
Inheritance







More general class = superclass
More specialized class = subclass
Subclass supports all method interfaces of superclass (but
implementations may differ)
Subclass may have added methods, added state
Subclass inherits from superclass
Example: ForwardedMessage inherits from Message
Example: Greeting does not inherit from Message
(Can't store greetings in mailbox)
19
Use Cases







Analysis technique
Each use case focuses on a specific scenario
Use case = sequence of actions
Action = interaction between actor and computer system
Each action yields a result
Each result has a value to one of the actors
Use variations for exceptional situations
20
Sample Use Case
Use case: Leave a Message
1.
Caller dials main number of voice mail system
2.
System speaks prompt
Enter mailbox number followed by #
User types extension number
System speaks
3.
4.
You have reached mailbox xxxx. Please leave a
message now
Caller speaks message
Caller hangs up
System places message in mailbox
5.
6.
7.
21
Sample Use Case -- Variations
Variation #1
 1.1. In step 3, user enters invalid extension number
 1.2. Voice mail system speaks
You have typed an invalid mailbox number.

1.3. Continue with step 2.
Variation #2
 2.1. After step 4, caller hangs up instead of speaking message
 2.3. Voice mail system discards empty message
22
Use Case Diagrams
• An Actor is an external entity that interacts with the system.
✦ different kinds of users, other systems, etc.
• A Use case is a textual description of the behavior of the system
from an actor’s point of view.
✦ overview of one user/system interaction
✦ focused on one goal of an actor
✦ described as a set of events.
✦ yields a visible/observable result for the actor
• When actors and use cases exchange information they are said to
communicate.
23
Use case diagram for a simple watch
• Actors are stick figures
• Use cases are ovals, with name usually inside or under the oval
• The boundary of the system is the box
• Each oval must have a textual description of the use case!!
24
Use Case Diagrams:
• 4 kinds of relationships
✦ Communication (or Association)
•
Usually between an actor and a use case
✦ Inclusion
•
Between uses cases
✦ Extension
•
Between use cases
✦ Inheritance (or Generalization)
•
Between actors or between use cases
25
Association (Between Actor and Use Case)

Each use case represents a unit of useful functionality
that subjects provide to actors. An association between an actor and a
use case indicates that the actor and the use case somehow interact or
communicate with each other.
Customer actor is associated
with two use cases - Browse
Items and Place Order.
26
Manage Account use case is
associated with Customer
and Bank actors.
Include relationship
• Use case include is a directed relationship between two use cases which
is used to show that behavior of the included use case (the addition) is
inserted into the behavior of the including (the base) use case.
The include relationship could be used:
• to simplify large use case by splitting it into several use cases,
• to extract common parts of the behaviors of two or more use cases.
• Include relationship between use cases is shown by a dashed arrow with an
open arrowhead from the including (base) use case to the included (common
part) use case. The arrow is labeled with the keyword «include».
27
Include relationship
Use cases B and C are extracted from
larger use case A into separate use cases.
Checkout use case includes several use
cases - Scan Item, Calculate Total and
Tax, and Payment.
•Dashed arrow points
to the included use case
28
Extend relationship
• Extend is a directed relationship that specifies how and when the behavior defined
in usually supplementary (optional) extending use case can be inserted into
the behavior defined in the extended use case.
• Extended use case is meaningful on its own, it is independent of the extending use
case. Extending use case typically defines optional behavior that is not necessarily
meaningful by itself.
• The extend relationship is owned by the extending use case.
• The same extending use case can extend more than one use case, and extending
use case may itself be extended.
• Extend relationship is shown as a dashed line with an open arrowhead directed from
the extending use case to the extended (base) use case. The arrow is labeled
with the keyword «extend».
29
Extend relationship
Registration use case is complete and
meaningful on its own.
It could be extended with optional Get
Help On Registration use case.
•Dashed arrow points to
the extended use case
Registration use case is conditionally
extended by Get Help On Registration
use case in extension point Registration
Help.
30
Inheritance (or Generalization) relationship
• Used when one use case is a specialization of another
✦It adds more detail
•Solid arrow points to the generalized use case
Note: Actors can also inherit from other actors.
31
Use Case Relationships Compared
Generalization
Extend
Include
Base use case could
be abstract use
case(incomplete) or
concrete (complete).
Base use case is complete
(concrete) by itself, defined
independently.
Base use case is incomplete
(abstract use case).
Specialized use case is
required, not optional, if
base use case is abstract.
Extending use case is
optional, supplementary.
Included use case required,
not optional.
No explicit condition to use
specialization.
Could have optional
extension condition.
No explicit inclusion
condition.
32
A larger sample use case diagram
How could the names of
the use cases be improved?
Answer: Convert them to
verbs!
e.g. StartSession,
PerformTransaction, etc.
33
When and how to use Use Case (Diagram)s
• Use during requirements analysis to capture the requirements.
✦Do it in combination with modeling the application domain concepts (this helps
explain and uncover new use cases).
• Remember: Use cases represent an external view of the system (don’t
expect them to appear as classes in the system).
• With Use Cases, the textual descriptions are more important than the Use
case diagrams.
✦ The use case textual descriptions contain the details necessary for design and
implementation.
✦ The diagram is just a good summary of the use cases.
34