Object-Oriented Design & Methodology

processroguishSoftware and s/w Development

Nov 18, 2013 (3 years and 8 months ago)

80 views

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

Projects

Success
16.2
%





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

Object
-
Oriented

Development

(structured,

data modeling,


ad hoc, etc )

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
and users?

What are the objectives and scope of the proposed
system?

What are the major risks involved?

List of requirements that can be used as
a starting point for development.

List of problem areas that fall within
the scope of the proposed system.

Assessment of risk factors.

Analysis

What does the system look like from the clients’ and
users’ perspective?

A set of models, each taking a different
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
the requirements?

Models from the analysis stage, refined
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
code?

A fully tested suite of programs.

Installation

What is needed to support clients and users and
ensure that they can use the new system
effectively?

User manual, technical documentation,
user training.

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

Inception

Elaboration

Construction

Transition

Requirement
s

Analysis

Design

Implementation

PHASES

WORKFLOWS

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
workflows
(activities) take
place during the
development of a
system


Requirements


Analysis


Design


Implementation


Testing

The Object
-
Orientated Approach

I n c e p t i o n

E l a b o r a t i o n

C o n s t r u c t i o n

T r a n s i t i o n

An iterative
process.

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

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
-
Orientated Approach

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 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


The Object
-
Orientated Approach

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
collaboration)

How a use case affects all the objects that are involved in it.

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

Deployment

Diagram

Use Case

Diagrams

Use Case

Diagrams

Use Case

Diagrams

Scenario

Diagrams

Scenario

Diagrams

Sequence

Diagrams

State

Diagrams

State

Diagrams

State

Diagrams

Component

Diagrams

Component

Diagrams

Component

Diagrams

Model

State

Diagrams

State

Diagrams

Object

Diagrams

Scenario

Diagrams

Scenario

Diagrams

Collaboration

Diagrams

Use Case

Diagrams

Use Case

Diagrams

Activity

Diagrams

State

Diagrams

State

Diagrams

Class

Diagrams

U
nified
M
odeling
L
anguage
(
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)



concrete things (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

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
element.


component

a modula
r, 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.




«interface»
Structural Modeling: Core Elements

Structural Modeling: Core Elements

(Continued)

Construct

Description

Syntax

constraint

a semantic condition or restriction.




{constraint}
package or

subsystem

a holder for grouping elements

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

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 th
e other modeling
element (the dependent element).




Structural Modeling: Core Relationships

(open arrow)

Composition

Construct

Description

Syntax

realization

a relationship between a specification
and its implementation.




Structural Modeling: Core
Relationships
(Continued)

(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,
2
nd 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,
2
nd 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
.