Information Systems Analysis
and Design
Overview of OOAD, UML, and RUP
INFO 620
Glenn Booker
INFO 620
Lecture #1
1
Syllabus
• This course is about learning and applying
Object-Oriented Analysis and Design
(OOA&D), expressed using the Unified
Modeling Language (UML)
• Primary text is Larman’s Applying UML
and Patterns (2nd ed.)
• Quatrani’s Visual Modeling with Rational
Rose 2002 and UML is for Rose users
INFO 620
Lecture #1
2
Your Background
• How much experience do you have with:
– Programming?
– Object oriented programming?
– If any, what programming languages are
you most comfortable using?
• Other than your grade, are there any
aspects of this course in which you’re
most interested?
INFO 620
Lecture #1
3
More than Software
• The texts are focused only on software
• Remember that your system will probably
involve other things, such as:
–
–
–
–
INFO 620
Hardware
Users
Training
Documentation, etc.
Lecture #1
4
What is Object Oriented?
• Earlier analysis methods were focused on
process (such as a Data Flow Diagram, or
DFD) or data (e.g. using an Entity
Relationship Diagram, or ERD)
• Object oriented (OO) methods blend data
and process into objects, and focuses on
how those objects interact using methods
(passing messages)
INFO 620
Lecture #1
5
What is Object Oriented?
• Traditional design creates entities (data
tables), and changes them using scripts,
procedures, macros, or other techniques
• OOA&D creates objects from classes,
and applies them using their methods
or operations
Image from Apple, “Object-Oriented
Programming and the Objective-C Language”
INFO 620
Lecture #1
6
What is an Object?
• “An entity with a well-defined boundary
and identity that encapsulates state and
behavior. State is represented by attributes
and relationships, behavior is represented
by operations, methods, and state machines.
An object is an instance of a class.”
(UML 1.5 spec – see slide 22)
INFO 620
Lecture #1
7
Huh?
• Attributes are the data contained by an
object, if any
• Relationships describe which objects are
allowed to talk to each other
• The operations and methods describe the
ways objects can interact with each other
• So objects are a set of data which can only
be acted on in certain prescribed ways
INFO 620
Lecture #1
8
What is a Class?
• “A description of a set of objects that share
the same attributes, operations, methods,
relationships, and semantics. A class may
use a set of interfaces to specify collections
of operations it provides to its
environment.” (UML 1.5 spec)
• Hence a class is a group of similar objects
INFO 620
Lecture #1
9
OO Languages
• Common object-oriented languages include
the cousins C++, Java, and C# (C sharp)
• Lesser known OO languages include
–
–
–
–
INFO 620
Smalltalk (first OO language, 1980)
Ada 95 (highly reliable, real-time systems)
Objective-C (Macintosh)
And many, even more obscure languages
Lecture #1
10
The Old Ways
• Process Oriented Methodology
–
–
–
–
INFO 620
Invented in the 1960’s
Focuses on using DFD
Weak for projects over 50k LOC
Subject to frequent change (every time a
process is tweaked, the DFD changes)
Lecture #1
11
The Old Ways
• Data Oriented Methodology
– Introduced in 1976, and primary method
used from the 1980’s to today
– Focuses on using the ERD
– Doesn’t change as often as the DFD
– Shows business rules through cardinality
(0, 1, )
– Works for systems up to about ½ million LOC
INFO 620
Lecture #1
12
The New Way
• Object Oriented Methodology
– Encapsulates data and processes to allow large
system development (millions of LOC)
– Getting standardized (UML, CORBA)
– Slow to be adopted by industry, mostly due
to inertia of data and process methods (large
installed base)
INFO 620
Lecture #1
13
OO Objectives
• We want a development method which:
– Is able to guide us through analysis, design, and
implementation using one consistent paradigm
throughout those phases
– Is less likely to generate errors
– Contains checks to help eliminate errors
– Facilitates reuse of designs and code
INFO 620
Lecture #1
14
Object Oriented Analysis
• OOA is “a method of analysis that examines
requirements from the perspectives of the
classes and objects.” (Booch 1995)
• Emphasis is on finding and describing
conceptual objects which are relevant to
your problem
INFO 620
Lecture #1
15
Object Oriented Design
• OOD is “a method of design encompassing
the process of OO decomposition and a
notation for depicting both logical and
physical as well as static and dynamic
models of the system.” (Booch 1995)
• Emphasis is on defining software objects,
and how they collaborate to fulfill
system requirements
INFO 620
Lecture #1
16
Analysis and Design
• Like the process and data methodologies,
note that:
– OO Analysis is done with no concern of how it
will be implemented
– OO Design considers implementation issues
• Also note that there are conceptual objects
(analysis) and software objects (design)
INFO 620
Lecture #1
17
Analysis vs. Modeling
• Analysis is the process of understanding
something
• The results of analysis may be captured
(expressed) using modeling
• Modeling depends on have some language
to express the concepts
• UML is a language for modeling OOA&D
INFO 620
Lecture #1
18
Why use UML?
• UML replaced a herd of competing OO
methods from the early to mid 1990’s, e.g.:
–
–
–
–
–
–
INFO 620
OMT method (most popular, Rumbaugh)
Mainstream Objects(MO) method, Ed Yourdon
Objectory method (Jacobson)
Booch method (Booch *duh*)
CRC method (Wirfs-Brock)
Fusion method (developed by Coleman (HP))
Lecture #1
19
Why use UML?
• Around 1995, five OO methods shared 75%
of the market
– OMT led with 34-40% of market, hence UML
was based on the OMT method
– Booch and Schlaer Mellor were also popular
• All other methods shared remaining 25%
of the market, including corporate-defined
OO methods
INFO 620
Lecture #1
20
Unified Modeling Language
• The “three amigos” created UML in 1997-8
– Grady Booch
– James Rumbaugh
– Ivar Jacobson
• Their three 1999 books are instant classics:
– The UML: User Guide
– The UML: Reference Manual
– The Unified Software Development Process
(ISBNs 0201571684, 020130998X, and 0201571692)
INFO 620
Lecture #1
21
Intro to UML
• UML is defined by the Object Management
Group (www.omg.org), a worldwide
consortium of OO product vendors
• First standardized in 1997
• Latest version is 1.5 (March 2003)*
• Booch, Rumbaugh, and Jacobson all work
for Rational Software Inc. (rational.com)
*A rather dry 736-page tome…but nice glossary!
INFO 620
Lecture #1
22
UML Goals
• The goals of UML are:
– To model systems using OO concepts
– To establish an explicit coupling between
conceptual and software artifacts (objects)
– To address the issues of scale inherent in
complex mission critical systems
– To create a modeling language usable by both
humans and machines
INFO 620
Lecture #1
23
UML Lineage
• UML not only replaced the methods by
Booch, Rumbaugh, and Jacobson, but also
borrowed from:
– Fusion (Operation description &
message numbering)
– Embley (Singleton class)
– Meyer (Pre- and post-conditions)
– Shlaer and Mellor (Object life cycles)
INFO 620
Lecture #1
24
UML Lineage
–
–
–
–
Martin and Odell (Classification)
Wirfs-Brock (Responsibilities)
Harel (State charts)
Gamma, et al (Patterns)
• So UML borrowed from all of the best ideas
INFO 620
Lecture #1
25
UML and OOA&D
• UML has twelve diagrams, but three types
are most commonly used
– “Use case” modeling
– Class modeling
– Interaction modeling with patterns
• Just because English has 600,000 words
doesn’t mean you need to use them all –
3000 is plenty for most occasions
INFO 620
Lecture #1
26
UML Method
• A method needs a language, and a process
to describe how to use the language
Method = Language + Process
• The Rational Unified Process (RUP or UP)
was designed to be used with UML
– UP is an iterative process
– Provides a structure for system development
INFO 620
Lecture #1
27
More RUP Info
• Rational has lots of white papers if you’re
interested in the Rational Unified Process
(good even if you’re not using Rose), Rose,
or the Suite DevelopmentStudio (sic)
• Or you can buy additional documentation
on their products (extremely optional!)
– See Rose download instructions for more
documentation info
INFO 620
Lecture #1
28
Iterative Development
• System is defined by use cases
Larman
p. 15
– A “use case” is a major way of using the
system, or a major type of functionality
• High level planning needs to
– Define what are the major use cases
– Determine in what order they will be done
– Estimate development time for each use
case (“timeboxing”)
INFO 620
Lecture #1
29
Iterative Development
• Each development iteration creates one
use case
– Includes the entire life cycle (requirements
analysis, design, implementation, and testing)
– Results in an executable portion of the system
or some other clearly defined end product
• E.g. an ATM which can only do withdrawals
– Is planned with a fixed time to completion
INFO 620
Lecture #1
30
UP Phases
•
•
•
•
Larman
p. 19
Inception
Elaboration
Construction
Transition
INFO 620
Lecture #1
31
Inception Phase
• Conduct feasibility study
• Define approximate vision, business cases,
and scope for project
• Develop vague estimates (size, cost,
and schedule)
INFO 620
Lecture #1
32
Elaboration Phase
• Refine vision
• Identify most requirements and scope
• Do iterative implementation of the
system’s core architecture
• Resolve high risks
INFO 620
Lecture #1
33
Construction Phase
• Do iterative implementation of the system’s
easier and lower risk elements
• Prepare for deployment
INFO 620
Lecture #1
34
Transition Phase
• Conduct beta tests
• Deploy system
INFO 620
Lecture #1
35
UP Disciplines
• A discipline is a set of activities and the
related artifacts created by those activities
• An artifact is any work product – code,
documents, diagrams, models, etc.
• This course focused on three disciplines:
– Business Modeling
– Requirements Analysis
– Design
INFO 620
Lecture #1
36
Other UP Disciplines
• Other UP Disciplines include
Larman
p. 21
– Implementation (programming & building
the system)
– Test
– Deployment (releasing the system)
– Configuration and Change Management
– Project Management
– Environment (create development environment)
INFO 620
Lecture #1
37
Iteration, Disciplines, Phases
• Each iteration may use some or all of the
disciplines, depending on when that
iteration occurs in development
• Likewise, the Phases may each correspond
to one or more iterations (p. 22 Larman),
so each Phase will also use some or all of
the disciplines
INFO 620
Lecture #1
38
Larman’s Text Approach
• Larman uses three iterations
–
–
–
–
Inception
Iteration 1
Iteration 2
Iteration 3
• Course only uses one big iteration, due to
time constraints
INFO 620
Lecture #1
39
Larman’s Text Approach
• Inception
– Basic requirements analysis
– Use case modeling
• Iteration 1
– Fundamental OOAD
– Assign responsibilities (define who does what)
– Build domain models (class models and
interaction diagrams)
INFO 620
Lecture #1
40
Larman’s Text Approach
• Iteration 2
– Object design with design patterns
– GRASP patterns (a Larman term)
• Iteration 3
– Architectural analysis and framework design
– Relating use cases
– Refine domain models with generalization and
advanced modeling
INFO 620
Lecture #1
41
OO Concepts – Class
• A Class is a group of objects with common
features and common behaviors such as
– Attributes
– Operations
– Relationships with other objects
• A Class has two components
– Data (SSN, height, price, ISBN, etc.)
– Operations (interfaces or methods)
INFO 620
Lecture #1
42
OO Concepts - Object
• An Object is any meaningful concept,
abstraction, or thing for the problem at hand
• An Object is an instance of a class
– Bill Clinton is an object, of the class Customer
• Objects have three components
– Data
– Operations (interfaces or methods)
– Object identity (OID); like entity’s primary key
INFO 620
Lecture #1
43
OO Concepts – Operations
• Interface
– A logical description of the way objects interact
– Describes the functions (play, record, hire)
• Method
– A physical implementation of how objects
interact; or of an operation for a class
– “Pushing the VCR button” is a method
INFO 620
Lecture #1
44
OO Paradigm
• All OO things (A&D methods, databases,
interfaces, operating systems, etc.) have
four common characteristics:
–
–
–
–
INFO 620
Abstraction
Encapsulation
Generalization & Specialization, Inheritance
Polymorphism
Lecture #1
45
Abstraction
• Abstraction is the process of modeling only
relevant features
– Hide unnecessary details which are irrelevant
for current purpose (and/or user), like eye color
• Reduces complexity and aids understanding
• Done via class, inheritance, association, and
aggregation concepts
INFO 620
Lecture #1
46
Encapsulation
• Encapsulation is the integration of data and
operations into a class
• Supports information hiding by concealing
implementation of the object
• Allows us to call a function without
knowing, or caring, how it’s implemented
– Sqrt(x)
INFO 620
Lecture #1
47
Encapsulation
We don’t access
data directly –
ever!
Only access data
via messages
between objects
INFO 620
Lecture #1
48
Generalization & Specialization
• Generalization is the process of identifying
common features among classes leading to
superclasses
• Specialization is the process of creating
more specialized subclasses from an
existing class
INFO 620
Lecture #1
49
Inheritance
• Subclasses inherit all of the properties and
operations defined for the superclass, and
will usually add more
• Sometimes modeled using “is a” or “AKO”
(a kind of) concepts
INFO 620
Lecture #1
50
Inheritance
Vehicle
Superclass
Generalization
Wheeled
Not Wheeled
Class
Specialization
Two wheeled
Four wheeled
Tank
Subclass
INFO 620
Lecture #1
51
Inheritance
• Is an implementation concept
• Substitutability means the subclass must
be usable when its superclass object
is expected
• Subtyping is using inheritance based
on substitutability
• Example could also be broken by powered
vs. unpowered, or land vs. air, or other ways
INFO 620
Lecture #1
52
Inheritance
• Could also look to biology for examples
• A “human being” inherits properties and
characteristics from
– Primates, and
– Mammals, and
– Animals
• But it doesn’t perform the function
photosynthesis, because it isn’t a Plant
INFO 620
Lecture #1
53
Polymorphism
• Means “many shapes”
• Allows dynamic substitution of objects
within an inheritance hierarchy
• Allows services to be shared by many
classes (a.k.a. overloading a function)
– A method called “calculate area” for a class
“drawing object” will have different definitions
depending on whether the drawing object is a
triangle, square, diamond, circle, etc.
INFO 620
Lecture #1
54
Architectural Concepts
• Software is often written to different levels
of the system’s architecture –
– User Interface (what the user sees)
– Application (the body of your software)
– Technical Services (general purpose services to
support your application)
• These later correspond to different
computer systems which implement them
INFO 620
Lecture #1
55
Inception Phase
• The inception phase focuses on analyzing
the feasibility of a project
– Can we make a business case to prove this
project is a good idea?
– Is this project technically feasible?
– Very roughly, how much time and money will
this project need?
– What risks can we foresee?
INFO 620
Lecture #1
56