Ooad 1

Introduction OO paradigm
Lecture 1
Cont
• Course objective and outline
• OO Basics
– Functional decomposition and its problem
– Object-oriented paradigm z
– Object-oriented programming in action
– What’s OOAD? Z
– What’s UML
Objectives
• Learn O-O A&D methodology
• Understand why a methodology is useful for
real software projects
• Learn UML
• Learn O-O design patterns
• Build something that illustrates the concepts
• Our Textbook
• Craig Larman, Applying UML and Patterns: An
Introduction to Object-Oriented Analysis and
Design and the Unified Process, 3rd edition,
Prentice Hall PTR, 2010
• Detailed Intro to Object Oriented Analysis &
Design z Unified Modeling Language (UML)
• Design Patterns
• Unified Process
Functional Decomposition
• A very simple development case z You are

asked to write code to access a list of shapes
that were stored in a database then display
them
• What steps we need to achieve this?
– 1. Locate the list of shapes in the database
– 2. Open up the list of shapes
– 3. Sort the list according to some order
– 4. Display the individual shapes on the monitor
Functional Decomposition
• We might breakdown some step further

a. Identify the type of shapes
b. Get the location of the shape
c. Call the appropriate function that will
display the shape, giving it the shape’s location
This is called functional decomposition functional
decomposition because the analyst breaks down
(decomposes) the problem into the functional steps
that compose it.
Possible problems
• It is usually leads to having one program that

is responsible for controlling its subprograms z
• Too much responsibility is placed on the main
program Ensuring everything is working
properly, coordinating and sequencing
functions
• Consequence: very complex code
Possible problems
• Alternative solution:
• Make some sub functions responsible for their
own behavior
• There is nothing we can do to stop change.
But we do not have to be overcome by it.
The problem of requirements
• Requirements are incomplete

• Requirements are usually wrong
• Requirements ( and users) are misleading z
Requirements do not tell the whole story |
Requirements change because
• The users’ view of their needs changes after
discussion with developer
The problem of requirements
• The developer’s view of the users’ problem
domain changes as they get more familiar
with the software they are developing
• The environment in which the software is
being developed changes
Change happens! Deal with it
• We should not give up on gathering good

requirements
• We must write our code to accommodate
change.
Dealing with changes: Using functional decomposition
• Function: display shape

• Input: type of shape, description of shape
Action:
• switch (type of shape)
– case square: call display function for square
– case circle: call display function for circle
Perspectives in the software development
process
• Three perspectives
• Conceptual – represents the concepts in the
domain understudy. It answers the question
“what am I responsible for?”
• Specification – represents the interface of the
software. It answers the question, “how am I
used”
• Implementation – code itself. It answers the
question, “how do I fulfill my responsibilities?
The Object-oriented paradigm
• | Centered on the concept of the object
• Traditionally been defined as data with
methods
• Advantage of using objects
– Being able to define things that are responsible
for themselves.
• How to think about objects
• To think of it as something with responsibilities
• At the conceptual level, an object is a set of
responsibilities.
• At the specification level, an object is a set of
methods (behaviors)
• At the implementation level, an object is code
and data and computational interactions
between them.
• Objects are instances of classes
• Working with objects in the example
• Start the control program z Instantiate the
collection of students in the classroom
•
• Tell the collection to have the students go to
their next class
• The collection tells each student to go to his
or her next class.
• Each student
– Find where his next class is
– Determines how to get there
– Goes there
– Done
• The need for an abstract
• We must allow any type of student into the collection:
undergraduate student and graduate student
• Design an abstract class Student represented by two
concrete classes, RegularStudent and GraduateStudent
• Benefits
– The collection only needs to deal with Student
– Each kind of student is left to implement its functionality in
its own way
• Visibility
• public – anything can see it
• protected – only objects of this class and derived can
see it
• private – only objects from this class can see it
Encapsulation
• Objects generally do not expose their internal data
members to the outside world z Encapsulation means
hiding anything •
• Student hides the types of classes derived from it.
• Polymorphism
• Being able to refer to different derivations of
a class in the same way, but getting the
behavior appropriate to the derived class
being referred to
What is Analysis and Design
• Analysis emphasizes an investigation of the

problem rather than how a solution is defined
• Design emphasizes a logical solution, how the
system fulfills the requirements
O-O A&D
• The essence of O-O A&D is to consider a problem
domain and logical solution from the perspective
of objects (things, concepts, or entities)
• O-O Analysis emphasizes finding and describing
the objects – or concepts- in the problem domain
• O-O Design emphasizes defining logical software
objects (things, concepts, or entities) that have
attributes and methods
Unified Modeling Language
• “A language for specifying, visualizing and

constructing the artifacts of software system”
[Booch, Jacobson, Rumbaugh]
• It is a notational system aimed at modeling
systems using O-O concepts
• … not a methodology
• … not a process
UML
• Use case diagram
• Class diagram |
• Behavior diagrams:
• statechart diagram
• activity diagram
UML
• interaction diagrams:
Sequence diagram
– Collaboration diagram
• Implementation diagrams:
component diagram
– deployment diagram
End of Lecture 1

Ooad 1

Uploaded by

Copyright:

Available Formats

Ooad 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ooad 1

Uploaded by

Copyright:

Available Formats

Introduction OO paradigm

• A very simple development case z You are

• We might breakdown some step further

• It is usually leads to having one program that

• Requirements are incomplete

• We should not give up on gathering good

• Function: display shape

• Analysis emphasizes an investigation of the

• “A language for specifying, visualizing and

You might also like