Object-Oriented Design & Methodology

CS 312

OO Modeling
CS 214

Fall 2011
 There will be a two hours lab.

 We will work on Rational Rose software. It is

recommended to install it in your machine.
 Introduction:
form

UML and C++: A Practical Guide To

O-O Development

Richard C. Lee
Currently:

-Software projects costs are going up and hardware

costs are going down

-Software development time is getting longer and

maintenance costs are getting higher

-Software error getting more frequent while hardware

errors becomes almost rare.

- Software is developed using a rigid structured

process that is inflexible.
Software project costs by development
phase
Work step %
Requirements 3
Design 8
Programming 7
Testing 15
Maintenance 67
 Modern Corporations are headed toward
disaster

Any corporation decisions based on the

output of incorrect software can threaten the
ability of a business to be financially strong
tomorrow
 Success 16.2%

Projects Challenged 52.7%

Impaired 31.1%
Successful projects deliver full functionality
on-time and on-budget
Challenged projects deliver, but less than
full functionality, over-budget, and late
Impaired are cancelled during development
For 1995, the cost of challenged and
impaired projects was $1400 billion
in USA
 Many projects are started with the wrong
goals and find themselves having to start
over again from the beginning.

 Starting over does not support delivering at

the original deliver date.

 Standish Group found that for every 100

Projects that start, there are 94 restarts.
Approximately 28% of projects exhibit cost
overruns of 150% to 200% of their original
cost estimate.
A common joke about delivering software:

Do you want it on time or fully functional

 What does the customer want
A customer wants a solution that:

 Meets functional requirements

 Adapts to the rapidly changing business

environment.

 Fits the run time (time/Space) constrains

A customer wants a software that is:

 Maintainable
 Developed within budgeted resources
( time/ space / people )
 Designed with appropriate longevity in mind
 Classical
(structured,
Development data modeling,
ad hoc, etc )

Object-Oriented
A Student Guide Object-Oriented
Development

Carol Britton & Jill Doake

Course Aim

To look at how a software system is

developed using an object orientated
approach
System Life Cycle – Why?
 Need an agreed framework for the
development
– Identify milestones
– Structure activities
– Monitoring deliverables
System Life Cycle – Why?
 Advantages of agreed framework
– An overall picture of the development
process
– A basis for development
– Consistency in approach
– Ensures quality
• Structure for planning, monitoring and
controlling the development process
Traditional High Level System Life Cycle
Stage of life cycle Issues addressed Deliverables

Requirements What are the problems, needs and wishes of clients List of requirements that can be used as
and users? a starting point for development.
What are the objectives and scope of the proposed List of problem areas that fall within
system? the scope of the proposed system.
What are the major risks involved? Assessment of risk factors.
Analysis What does the system look like from the clients’ and A set of models, each taking a different
users’ perspective? view of the system, which together
give a complete picture. The
models may be text, diagrams or
early prototypes.
Design How can the system be constructed, so as to satisfy Models from the analysis stage, refined
the requirements? to illustrate the underlying
architecture of the system. These
models take account of
technological considerations and
constraints arising from the
implementation environment.
Implementation How can the models produced be translated into A fully tested suite of programs.
code?
Installation What is needed to support clients and users and User manual, technical documentation,
ensure that they can use the new system user training.
effectively?

Note - Stage names reflect activities carried out at each stage

Problems with Traditional Approach
 Functional Decomposition
– Functions and data separated
– Data accessible by several processes
Major problem - data not protected

 Poor modularity
 Data versus function
Problems with Traditional Approach
 Functional Decomposition
 Poor modularity
– Ideally modules should be self-
contained
– Have well defined purpose
– Be independent
Major problem – interdependency
between modules
 Data versus function
Problems with Traditional Approach

 Functional Decomposition
 Poor modularity
 Data versus function
– System functionality is more likely to
change than the data
– Over time the functionality is more
unstable than the data
The Object-Orientated Approach
Phases (stages) of Development
 Inception
 Elaboration
 Construction
 Transition

These indicate the state of the system at

each phase NOT the activities involved at
that point in development
The Object-Orientated Approach
Phases (stages) of Development
 Inception – the initial work required to set
up and agree terms for the project.
Includes establishing the business case
– Feasibility
– Basic risk assessment
– Scope of the system to be delivered
The Object-Orientated Approach
Phases (stages) of Development
 Inception
 Elaboration – deals with putting the basic
architecture of the system in place
– All main project risks are identified

 Construction

 Transition
The Object-Orientated Approach
Phases (stages) of Development
 Inception
 Elaboration
 Construction – involves bulk of work on
building the system
– Ends with beta-release of system

 Transition
The Object-Orientated Approach
Phases (stages) of Development
 Inception
 Elaboration
 Construction
 Transition – process involved in
transferring the system to the clients and
users
Workflows
 The activities implied by the stages in a
traditional structured modelling approach
are referred to as Workflows in the object-
orientated approach
 Workflows -
– Requirements
– Analysis
– Design
– Implementation
– Testing
Workflows - activities
PHASES WORKFLOWS

Inception Requirement
s

Elaboration Analysis

Construction Design

Transition Implementation
The Object-Orientated Approach
Iterative Process -
 Workflows may be carried out during
any phase of development
 In each phase a range of workflows
(activities) may be carried out several
times before moving on to the next
phase
The Object-Orientated Approach

A range of Requirements
workflows Analysis
(activities) take
Design
place during the
Implementation
development of a
Testing
system
The Object-Orientated Approach
Inception
An iterative
process.

Elaboration The ellipses

represent iterations
of workflows
(requirements,
Construction analysis, design,
implementation,
testing)

Transition
The Object-Orientated Approach
A seamless Development Process
 Phases less distinct than in a
structured approach
 Difficult to say when one phase ends
and another begins
 Driven by a single unifying idea – the
object
The Object
 Basic building block
 Objects in the real world translate
into objects in the software system
– Physical (customers, products)
– Conceptual (orders, reservations
– Organisation (companies, departments)
– Implementation (GUI Windows)
The Object-Orientated Approach
 The foundation of all development
work is the object
 No new system models introduced at
different stages
 Early models developed and refined
through the development process
 An iterative design process
Modelling

 To capture the whole of a system we

need to view it from different aspects
 Each diagram provides some but not
all of the information – abstraction
 Each model is an abstraction of the
complete system
 System is broken down into small
workable chunks - decomposition
Unified Modelling Language - UML

 A notation or language for development

 Not a development method
 Set of diagrammatic techniques
 Industry standard for modelling OO
systems
 UML Creators – Ivar Jacobson, Grady
Booch, James Rumbaugh
 Principal UML Models
Model View of the system
Use case How the system interacts with its users.
Class The data elements in the system and the relationships
between them.
Interaction (sequence and How a use case affects all the objects that are involved in it.
collaboration)
State How the different objects of a single class behave through
all the use cases in which the class in involved.
Activity The sequence of activities that make up a process.

Component The different components of the system and the

dependencies between them.
Deployment The software and hardware elements of the system and the
physical relationships between them.
The UML Provides Standardized
Diagrams
State
State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Activity Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Sequence
Diagrams State
Diagrams
Diagrams Model Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Component
Collaboration
Diagrams Deployment Diagrams
Diagrams Diagram Diagrams
Unified Modeling Language (UML)

“A graphical language for visualizing,

specifying, constructing, and documenting
the artifacts of a software intensive system.”
[Booch]
 UML in One Sentence

The UML is a graphical language for

 visualizing
 specifying
 constructing
 documenting
artifacts of a software-intensive
system.
 Visualizing
 explicit model facilitates communication
 some structures transcend (pass or more)
what can be represented in programming
language
 each symbol has well-defined semantics
behind it
 Specifying

The UML addresses the

specification of all important
analysis, design, and
implementation decisions.
Constructing
 Forward engineering: generation of code
from model into programming language

 Reverse engineering: reconstructing

model from implementation

 Round-trip engineering: going both ways

UML and Blueprints
The UML provides a standard way to write a
system’s “blueprints” to account for

conceptual things (business processes,

system functions)

concretethings (C++/Java classes, database

schemas, reusable software components)
In UML, we have a state diagram for
dynamic behavior. The state diagram
shows:

-State
-Transition
-Event
-Condition
-Action
Structural Modeling: Core Elements
Construct Description Syntax
class a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
interface a named set of operations that
characterize the behavior of an «interface»

element.
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
node a run-time physical object that
represents a computational
resource.
Structural Modeling: Core Elements
(Continued)

Construct Description Syntax

constraint a semantic condition or restriction.
{constraint}

package or
a holder for grouping elements
subsystem
Structural Modeling: Core Relationships
Construct Description Syntax
association a relationship between two or more
classifiers that involves connections
among their instances.
aggregation A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and
Composition the component part.
generalization a taxonomic relationship between a
more general and a more specific
element.
dependency a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element). (open arrow)
 Structural Modeling: Core
Relationships (Continued)

Construct Description Syntax

realization a relationship between a specification
and its implementation.
(closed arrow)

Realization relationship connects a model element such as a class, to

another model element, such as an interface that supplies its
behavioral specification but not its structure or implementation. The
client must support ( by inheritance or by direct declaration) at least
all the operations that the supplier has.
Class Diagram Concepts
 A static model that shows the
classes and relationships among
classes that remain constant in the
system over time
Class Diagram for Manage
Appointment
HW1: due date one week from today:
Model the following using a class diagram:
Your company writes student and course data management software for universities.
You are writing a data management package for a university with several campuses.
Employees in the administration office of each campus has to enter several student
and class input parameters; these will be stored in a central database in the main
campus. CORBA has been chosen to send this data. There will be two kinds of data:
per student data, and per course data.
For each student, the administration employee will enter a social security number, a
3 line home address, and the current semester’s grades (the student will have taken at
least one class, and no more than 5 classes). If the student is also a university
employee, the administration employee will enter the student’s salary.
For each course, the administration employee will enter the instructor’s name, the
time of day the course meets, the days of the week the course meets, the date and time
of the final exam, and the number of hours of the course. The administration
employee will also enter a student name and social security number for each student
in the course.
The central database software will provide values in return. For each student, the
student’s new GPA (based on existing plus new classes) will be returned, along with
total number of courses the student has taken at the university. For each course, the
central database software will provide the total number of courses the instructor is
teaching this semester. If the final exam time entered does not match that stored in
the central database, then the final exam time variable will be corrected
Further reading

 Bennett, S., McRobb, S. and Farmer, R. Object-Oriented Systems

Analysis and Design Using UML, 2nd Ed, London: McGraw-Hill,
2002.
 Brown, D. Object-Oriented Analysis: objects in plain English, New
York: John Wiley, 1997.
 Fowler, M. UML Distilled: a brief guide to the standard object
modeling language, 2nd Ed, Reading Massachusetts: Addison-
Wesley, 2000.
 Jacobson, I. Object-Oriented Software Engineering: A Use Case
Driven Approach, Wokingham, England: Addison-Wesley, 1992.
 Larman, C. Applying UML and patterns: an introduction to object-
oriented analysis and design, New Jersey: Prentice Hall, 1998.
 Stevens, P., with Pooley, R. Using UML. Software Engineering
with Objects and Components Updated edition, Harlow: Addison-
Wesley, 2000.