chapter 01 - introduction to object oriented concepts

5/25/2018 Chapter 01 - Introduction to Object Oriented Concepts

1/49

Introduction toObject-Oriented Concepts

1


2/49

Outline

Software Development: Challenges and

Process

Introduction to Object-Oriented Concepts

The Fundamental Concepts of Object Object-oriented Software

Development: Unified Process

2


3/49

Software Development ProcessAn overview

3


4/49

3- 4

Software Development

Process Address:

Requirements Gathering This activity determines the requirements that the product must

address.

Feasibility Study Determines whether it is possible technically, economically, legally

or organizationally to build a certain software.

Domain Analysis Discovers the meaning of requirements within the context,

concepts within the domain that are related to the problem and canaffect the solution, and possibly the consequences of the solution onthe problem domain.

Analysis Analyzing the requirements to build a conceptual model of the solution(the product).

Design Transforms the what into how. Design itself consists of several

distinct activities; logical design, physical design, and architecturaldesign.


5/49


Process Address:

Implementation Turns the blueprints of design into an actual product.

Programming is usually the most important component of thisactivity, but it is not the only one.

Testing and Quality Control Verifies that the product functions according to specifications.

Deployment and Training This activity consists of ensuring the correct installation on the

target platform, user training, creating help files and usermanuals, setting up of Web sites to guide users, packaging, etc.

Maintenance Solving problems that may emerge after the deployment of the software,

or changes in the environment.

5


6/49

Waterfall model

Incremental and iterative(In practice, most large systems are developed using a

process that incorporates elements from all of these

models) Spiral model

Agile methods

Prototyping

Rapid Application Development (RAD)

etc.

Software Development Process

Models

6


7/49

The waterfall model

7

The waterfall model specifies a set of sequential

phases for software development


8/49

Incremental development: starts with small functional

subsystem and adds functionality with each new release

Iterative development: starts with full system, thenchanges functionality of each subsystem with each new

release

Incremental and Iterative

8


9/49

Incremental and Iterative

The Benefits

The cost of accommodating changing customer requirements is

reduced.

The amount of analysis and documentation that has to be

redone is much less than is required with the waterfall model.

It is easier to get customer feedback on the development work that

has been done.

Customers can comment on demonstrations of the software and

see how much has been implemented.

More rapid delivery and deployment of useful software to the

customer is possible.

Customers are able to use and gain value from the software

earlier than is possible with a waterfall model.

9


10/49

The Spiral Model The spiral model is a risk-oriented lifecycle model that breaks a

software project up into mini-projects.

It has been very influential in helping people think about iteration

in software processes and introducing the risk-driven approach

to development.

10


11/49


Process Address:

Many different software development approaches but all

involve:

Analysis (i.e., requirements engineering) analysing

and defining what the system should do;

Design and Implementation defining the organization

of the system and implementing the system;

Verification and Validation testing; checking that it

does what the customer wants;

Evolution (i.e., maintenance) changing the system in

response to changing customer needs.

The terminology and details of each process may differ,

but the generic activities remain reasonably consistent.

11


12/49

The Challenges of Software

Development

12


13/49

COMPLEXITY

Software system being developed today areoften very large and complex.

Complexity is dictated by the problems the

systems are intended to solve and theservices they are intended to provide.

Methodologies, techniques and tools must

be effectively used.

13


14/49

MAINTAINABILITY

Software system are often in service for

very long periods of time. Evolving to accommodate changes in

users need and environment is difficult to

maintain. Maintenance involves cost, time and also

degrade the quality

Maintenance costs far exceeddevelopment costs.

14


15/49

Maintainability should be focused

because:

Software is long lifetimes

Current development technology does

not yield high reliability. Reliability isattained through repeated corrections.

High maintainability requires flexibility

in design and implementation ofsoftware

15

MAINTAINABILITY (cont.)


16/49

DEALING WITH COMPLEXITY

Complex systems are hard to understand

Three ways to deal with complexity Abstraction and Modeling

Decomposition

Hierarchy

16


17/49


Abstraction and Model

Abstraction allows us to ignore unessential

details Ideas can be expressed by models

A model is an abstraction of a system

A system that no longer exists An existing system

A future system to be built.

17


18/49

Modeling the Real World

Model: abstraction of a

part of the real world

18


19/49

Modeling for Software

Development

Modeling, as a methodology, is the systematic

representation of the relevant features of a productor a system from particular perspectives.

Software modeling is shaped by four interweaved

factors: how the real world is seen,

how software is defined,

the process of development, and the modeling language.

19


20/49


Decomposition

A technique used to master complexity

(divide and conquer)

Two major types of decomposition

Functional decomposition Object-oriented decomposition

20


21/49


Decomposition

Functional decomposition

The system is decomposed into modules

Each module is a major function in the application

domain

Modules can be decomposed into smaller

modules.

Object-oriented decomposition

The system is decomposed into classes

(objects) Each class is a major entity in the application

domain

Classes can be decomposed into smaller classes21


22/49

22

SUPPORT MAINTAINABILITY

Changeable

The various aspects of softwaresystems should be easily changeable.

Minimal impact

Impact of change should be confinedto a small region.

The correctness of the change should

be reasoned by examining only thesmall affected region rather than theentire software.


23/49

SUPPORT MAINTAINABILITY

Simplicitymake things simple

Less error-prone

Easier to show correctness

Errors become more obvious andcorrecting errors is easier.

Divide-and-conquer approach

23


24/49

Why an Object-Orientation

Development?

Object-oriented technologyis mature and rules the

market.

Object-oriented software development is iterative.

Object-oriented decomposition is concerned with

identifying object classes, their attributes and operations

Reusability and maintainability

A full object-oriented development requires three things:

an object-oriented technology,

an object-oriented analysis and design, and

a project plan adapted to an object-oriented

approach

24


25/49

The Fundamental

Concepts of Object

25


26/49

What is an Object?

Something that is perceived as an entityandreferred to by name;

In its basic definition, an object is an entity that

contains both data and behavior.

This is the key difference between the moretraditional programming methodology, proceduralprogramming, and O-O programming.

26

Software systemReal world

Data-oriented model (70~80s)

Software systemReal world

Object-oriented model (90s~)


27/49

Procedural vs OO Programming

Traditional programming languages were procedural

(e.g., C, Pascal, BASIC, Ada and COBOL)

In procedural programming data and operations on

the data are separated

Data is placed into separate structures, and ismanipulated by these methods.

27

Method AMethod B

Data

e.g., if you want to send information,

only the relevant data is sent with the

expectation that the other program

know what to do with it.


28/49

Nice Packages

Objects address these problems by combining data

and behavior into a nice, complete package.

The fundamental advantage of OO programming is

that the data and the operations that manipulate the

data are both contained in the object.

28


Object

Attributes (data)

Methods

e.g., when an object is

transported, the entire object,

including the data and behavior

goes with it.


29/49

Object Data

The data stored within an object represents the

state of the object.

In O-O programming terminology, this data iscalled attributes.

29



30/49

Object Behaviors

The behaviorof an object is what the objectcan do.

In procedural languages the behavior isdefined by procedures, functions, and

subroutines.

In O-O programming terminology thesebehaviors are contained in methods, and you

invoke a method by sending a message to it.

30



31/49

Benefits of OO Programming

Save development time (and cost) by reusing

code Once an object class is created it can be

used in other applications

Easier debugging Classes can be tested independently

Reused objects have already been tested

31


32/49

The Unified Process

Object-Oriented Software Development

32


33/49

Too many methodologies

1986: Booch came up with the object-oriented design

concept, the Booch method.

1987: Sally Shlaer and Steve Mellor came up with the

concept of the recursive design approach.

1989: Beck and Cunningham came up with class-

responsibility collaboration(CRC) cards.

1990: Wirfs-Brock, Wilkerson, and Wiener came up withresponsibility-driven design.

1991: Peter Coad and Ed Yourdon developed the Coad

lightweight and prototype-oriented approach.

1991: Jim Rumbaugh led a team at the research labs ofGeneral Electric to develop the object modeling technique

(OMT).

1994: Ivar Jacobson introduced the concept of the use case.33


34/49

Implication

Split, Competitive & Confusing

Same basic concepts in different notations

Second-generation OO methodologies

combining best aspects

34


35/49

The Unified Approach

The idea behind the UA is not to introduce yet another

methodology.

The main motivation here is to combine the best

practices, processes, methodologies, and guidelines

along with UML notations and diagrams.

Focuses on improving the maintainabilityand reusabilityof software systems through a set of techniques,

notations, tools, and criteria.

Rational Unified Process (RUP) a detailedrefinement of UA developed by IBMs Rational Software

35


36/49

UA Methods and Technology

The methods and technology employed includes:

Unified Modeling Language (UML) used formodeling.

Layered approach

Repository for object-oriented system development

patterns and frameworks

Promoting Component-based development

36


37/49

Rational Unified Process (RUP)

Initial version officially released in 1998

Revised versions introduced in 2000 and 2003

Developed at Rational Corporation by the three

principal Developed at Rational Corporation by the

three principal developers of the OMT, Booch and

OOSE (Objectory) methodologies: Rumbaugh, Boochand Jacobson

UML-based

Use case driven, a feature inherited from OOSE Iterative incremental development

Covering the full generic lifecycle

37


38/49

RUP: Process - Phases

Overall development cycle consists of four phases:

Inception: defining the scope and objectives of the

project, as well as the business case Elaboration: capturing the crucial requirements,

developing and validating the architecture of the

software system, and planning the remaining

phases of the project

Construction: implementing the system in an

iterative and incremental fashion based on the

architecture developed in the previous phase Transition: testing and releasing the system

38


39/49

RUP: Process Iterations and

Disciplines

Each phase can be further broken down into iterations

An iteration is a complete development loop resultingin a release of an executable increment to the system

Each iteration consists of nine work areas (disciplines)

performed during the iteration

For each discipline, RUP defines sets of:

Artefacts (work products)

Activities (units of work on the artefacts)

Roles (responsibilities taken on by development

team members)

39


40/49

RUP: Process Disciplines

Business Modeling: describing business processes and the

internal structure of a business. A Business use Case Model

and a Business Object Model are developed. Requirements Management: eliciting, organizing, and

documenting requirements. The Use Case Model is

produced.

Analysis and Design: creating the architecture and thedesign of the software system; results in a Design Model and

optionally an Analysis Model.

Implementation: writing and debugging source code, unit

testing, and build management. Source code files,

executables, and supportive files are produced.

Test: integration-, system- and acceptance-testing

40


41/49

RUP: Process Disciplines

Deployment: packaging the software, creating installation

scripts, writing end-user documentation and other tasksneeded to make the software available to its end-users.

Project Management: project planning, scheduling and

control.

Configuration and Change Management: version- andrelease-management, and change-request management.

Environment: adapting the process to the needs of a project

or an organization, and selecting, introducing and supporting

development tools necessary infrastructure to develop

a system

41


42/49

RUP: Process Disciplines in

Iterations

42

RUP P Di i li i


43/49

43

RUP: Process Disciplines in

Iterations and Phases

Each phase is

broken down

into one/more

iterations


44/49

RUP

Complete software engineering process.

Goal to ensure the production of high-

quality software that meets the needs ofits end users within a predictableschedule and budget (Booch et al., 1999)

It is a process framework that can beadapted and extended to suit the needs ofdifferent organizations and different typesof projects.

44


45/49

RUP good practice

Develop software iteratively

Plan increments based on customer priorities and

deliver highest priority increments first.

Manage requirements

Explicitly document customer requirements and

keep track of changes to these requirements.

Use component-based architectures

Organize the system architecture as a set of

reusable components.

45


46/49

RUP good practice

Visually model software

Use graphical UML models to present static and

dynamic views of the software.

Verify software quality

Ensure that the software meets organizational

quality standards.

Control changes to software

Manage software changes using a change

management system and configurationmanagement tools.

46

RUP: The Object Oriented


47/49

RUP: The Object-Oriented

Development

47


48/49

RUP: Strengths and Weaknesses

Strengths

Iterative-incrementalprocess

Well-documented

Weaknesses

Very complexprocess

48


49/49

References

Matt Weisfeld (2013), Object-oriented Thought Process, 4th Ed., Addison-Wesley

Professional

Kruchten, P., Rational Unified Process: An Introduction, 3rd Ed., Addisn-Wesley,

2003

Sommerville (2011). Software Engineering, 9th Edition, Pearson.

Bennett, McRobb and Farmer (2010). Object-oriented systems analysis and

design using UML, 4th edition, McGrawHill.

Pfleeger and Atlee (2010). Software Engineering. Pearson.

www.cs.utep.edu/cheon/cs3331/notes/oosd.ppt

Etc..

49

chapter 01 - introduction to object oriented concepts

Documents

object oriented concepts

fundamental concepts

outline software development

incremental development

iterative85252018 chapter

software andsee

certain software

waterfall model incremental