Introduction to Object Oriented Modeling and Design

1. Introduction
Preeti Mishra
Course Instructor

2. Motivation
• You got a gun
• You were the proud owner of the nice gun!
• You used it:
• You claimed you know how to use a gun!

3. Motivation
• You learnt Java…
• You know the syntax and semantics.
• You have written small programs that work.
• You claimed you know object-oriented software
development!!
• This syndrome is not restricted to students alone…

5. Our Project Manager For the Rest
of the Course!
Hopelessly
incompetent at
management. He
does not understand
technical issues but
always tries to
disguise this, usually
by using buzzwords
that he does not
understand himself.
Often lacks Ethics…

7. Object
• Any real world entity: chair, fan, student, cow
• Object has crisp boundaries
• You can physically or logically perceive an object
• Object has:
• State ( values of attributes)
• Behavior( method response)
• Identity( address+name)

9. Taking about the dog
Attributes(these will be common
to all dogs)
State( talking about dog obove)
Breed Labrador
Owner Mr. crazy
Batch_no 420_IM
Vaccinated No
Hobbies Music
badhabbits smoking

10. • Behavior:
• gets_vaccination
• Runs
• Listensongs….
• Identity:
• Batch_no ( it is unique for all dogs)

11. Task:
• Think of an object
• Give its state- now deduce the
attributes from this state
• Talk of the identity

12. Modeling
• "Modelling" is describing something you know. A good model
makes correct assertions. (problem domain)
• "Designing" is manipulating space for things you don't know.
A good design e.g., lets you change things easily (there are
many dimensions of 'goodness').( moving towards solution
domain)

13. Putting it together
• Object Oriented Modeling and Design

14. Outcomes of the course
• To gain enough competence in OOAD to tackle a complete
OO project
• It gives a thought to talk about a common language talking
about requirements , design and interfaces
• Address main principles of OO design and what major
tasks are appropriate for developing OO models and
software, the issues and options in reuse and component
based development

15. Abstraction
Object Oriented Concepts:

17. What we learned
• People tend to see the same thing in
different manner
• Why So??
– Due to various perspectives, interests
• Technically we will refer this syndrome as
Abstraction

18. What is..
• An abstraction focuses on the outside view of an object and
separates an object’s behaviour from its implementation
• a simplified description, or specification, of a system that
emphasizes some of the system's details or properties while
suppressing others. A good abstraction is one that
emphasizes details that are significant to the reader or
user and suppresses details that are, at least for the
moment, immaterial or diversionary“
• Nearly all programming languages designed since 1980
support data abstraction

21. Thus
• “An abstraction denotes the essential characteristics of an
object that distinguish it from all other kinds of objects
and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer”
-Grady Booch

22. Realized in programming by..
• Abstract data types/ classes
• Abstract keyword
• Class…

23. Encapsulation

24. Need??
• Large programs have two special
needs:
– Some means of organization, other than
simply division into subprograms
– Some means of partial compilation
(compilation units that are smaller than
the whole program)

26. Hence encapsulation
• “Encapsulation is a mechanism used to hide the data,
internal structure, and implementation details of an object.
• All interaction with the object is through a public
interface of operations.”
• Abstraction and encapsulation are complementary
concepts: abstraction focuses upon the observable
behaviour of an object, whereas encapsulation focuses
upon the implementation that gives rise to this behaviour.
• For abstraction to work, implementations must be
encapsulated"

27. Defined as..
• “Encapsulation is the process of
compartmentalizing the elements of an abstraction
that constitute its structure and behaviour;
encapsulation serves to separate the contractual
interface of an abstraction and its implementation.”
– Grady Booch

28. Encapsulation is achieved through
• Encapsulation is most often achieved through information
hiding, which is the process of hiding all the secrets of an
object that do not contribute to its essential
characteristics; typically, the structure of an object is
hidden, as well as the ,implementation of its methods.

29. In programming
• Encapsulation Abstraction= Class
• For eg: think of a person as student
• From this perspective think of his
description/properties
• Now compartmentalize these properties into:
– attributes + behavior
– Make attributes as : member variables/ data members
– Make behavior: member functions/ methods
– Name the entity as some noun : Student (because its meaningful
according to the perspective)

30. And we have..
Class Student
{
int roll_no, marks;
String Name, branch, year;
int get_Attendence()
int check_percentage()
}

31. Modularity

35. Thus
• The act of partitioning a program into individual
components can reduce its complexity to some degree. .
• Although partitioning a program is helpful for this
reason, a more powerful justification for partitioning a
program is that it creates a number of well defined,
documented boundaries within the program.

36. • modularization consists of dividing a program into
modules which can be compiled separately, but which
have connections with other modules.
• The overall goal of the decomposition into modules is the
reduction of software cost by allowing modules
to be designed and revised independently. .

37. Defined as..
• Modularity is the property of a system that has been
decomposed into a set of cohesive and loosely coupled
modules

38. Heirarcy

41. What is the need
• A set of abstractions often forms a hierarchy, and by
identifying these hierarchies in our ,design, we greatly
simplify our understanding of the problem

42. Defined as..
• Hierarchy is a ranking
or ordering of
abstractions.

43. • Is-a relation
• Kind-of

44. Polymorphism

47. We learned
• Generally, the ability to appear in many forms.
• The same invocation can produce “many forms” of
results
• The same method name and signature can cause
different actions to occur,
– depending on the type of object on which the
method is invoked
• Promotes extensibility
• New objects types can respond to existing
method calls

49. • Polymorphism exists when the features of
inheritance and dynamic binding interact. It is
perhaps the most powerful feature of object-
oriented programming languages

50. Defined as..
• In object-oriented programming, polymorphism
refers to a programming language's ability to process
objects differently depending on their data type or
class. More specifically, it is the ability to redefine
methods for derived classes.

51. Concurrency,
Persistancy, Typing

53. Typing
• "A type is a precise characterization of structural or
behavioural properties which a collection of entities all
share“
• Concept of Typing and class are similar but
• Typing is the enforcement Of the class of an object, such,
that objects of different types may not be interchanged, or
at the most, they may be interchanged only in very
restricted ways.

54. An OO-Programming
language can be:
• Strongly typed(violation of type conformance can be detected at the
time of compilation)
• Weakly typed(have tendencies toward strong typing, but it is
possible to ignore or suppress the typing rules.)
• Untyped (Violations of type conformance may not be known until
execution, and usually manifest themselves as execution errors)

55. Typing in
• Static and Dynamic Binding
• Support polymorphic behavior

57. Concurrency
• For certain kinds of problems, an automated system may
have to handle many different events simultaneously.
• Other problems may involve so much computation that they
exceed the capacity of any single processor.
• In each of these cases, it is natural to consider using a
distributed set of computers for the target implementation
or to use processors capable of multitasking.

58. Thus ..
• concurrency focuses upon process abstraction and
synchronization
• The object is a concept that unifies these two different
viewpoints:
• each object may represent a separate thread of control (a
process abstraction). Such objects are called active. In a
system based on an object-oriented design,
• we can conceptualize the world as consisting of a set of
cooperative objects, some of which are active and thus
serve as centres of independent activity.

59. Persistency
• objects in a database outlive the execution of a single
program.
• This spectrum of object persistence encompasses the
following:
– “Transient results in expression evaluation
– Local variables in procedure activations
– Own variables [as in ALGOL 60], global variables, and heap items
whose extent is
– different from their scope
– Data that exists between executions of a program
– Data that exists between various versions of a program
– Data that outlives the program"

60. Contd..
• introducing the concept of persistence to the object model
gives rise to object-oriented databases
• In practice, such databases build upon proven technology,
such as
– sequential,
– indexed,
– hierarchical,
– network, or
– relational database

61. Defined as..
• Persistence is the property of an object through
which its existence transcends time (i.e. the
object continues to exist after its creator ceases
to exist) and/or space (i. e. the objects location
moves from the address space in which it was
created).

62. OOD
Object-oriented design is a method of
– design encompassing the process of object-
oriented decomposition and
– a notation for depicting both
• logical and
• physical as well as
• static and
• dynamic models
of the system under design.

63. Object
•State
•Behavior/ operations
•Identity
•Roles-responsibility
•Life span

64. What is an Object?
• From the perspective of human
cognition, an object is any of
the following:
– A tangible and/or visible thing
– Something that may be
apprehended intellectually
– Something toward which
thought or action is directed
– something that exists in time
and space.

65. Defined as
• An object has state, behaviour, and identity; the structure
and behaviour of similar objects are defined in their
common class; the terms instance and object are
interchangeable.

66. Object: State
Property
(attribute)
Current
value(State)
Amount of money $45
No to slots 20
No of empty slots 5
No of filled slots 10
Price per slot …

67. State: defined as
• The state of an object encompasses all of the
(usually static) properties of the object plus the
current (usually dynamic) values of each of these
properties.

68. Behavior
• the behaviour of an object
represents its outwardly
visible and testable
activity
• behaviour also notes that
the state of an object
affects its behaviour as
well.

69. Behavior : defined as
• Behaviour is how an object acts and reacts, in
terms of its state changes and message passing.
• Thus:
– The state of an object represents the cumulative
results of its behaviour

70. Operations: means to show behaviour
(Operation/methods/memberfunctions)
• An operation denotes a service that a class offers to its clients.
• In practice, we have found that a client typically performs five kinds of
operations upon an object:
– Modifier :An operation that alters the state of an object
– Selector :An operation that accesses the state of an object, but does not
alter the state
– Iterator :An operation that permits all parts of an object to be accessed in
some well-defined order
– Constructor: An operation that creates an object and/or initializes its state
– Destructor An operation that frees the state of an object and/or destroys
the object itself

71. Task to do
• For a Stack data
structure identify :
• State: properties and
current values
• Behavior
• Operations of different
categories

72. Identity

73. New terms??
• Copying, Assignment, and Equality
• What’s the difference???

74. Identity: defined as
• “Identity is that property of an object which
distinguishes it from all other objects "

75. Roles and Responsibilities
• all of the methods and free subprograms associated with a
particular object comprise its protocol.

76. Roles
• object's allowable behavior, and so comprises the entire static
and dynamic view of the object.
• For most nontrivial abstractions, it is useful to divide this larger
protocol into logical groupings of behavior.
• These collections, which thus partition the behavior space
• of an object, denote the roles that an object can play.
• a role is a mask that an object wears , and so defines a contract
between an abstraction and its clients

77. Responsibility
• The responsibilities of an object to "include two key
items:
– the knowledge an object maintains and
– the actions an object can perform.
• Responsibilities are meant to convey a sense of the
purpose of an object and its place in the system.
• The responsibilities of an object are all the services it
provides for all of the contracts it supports"

78. Object : Life Span
• Object Life Span :The lifetime of an object extends from
the time it is first created (and thus first consumes space)
until that space is reclaimed .
• To explicitly create an object, we must either declare it or
allocate it.
• Object destruction may vary …
• Persistent objects have slightly different semantics
regarding destruction

79. •Object Oriented Methodologies
Uniform Approach Modeling

80. Object Oriented
Development
• Object-Oriented development requires that object-
oriented techniques be used during
– the analysis, and
– implementation of the system.
• An object-oriented approach to the development of
software was proposed in late 1960s.

81. Object Modeling
Technique

82. What is modeling??
• A model is an abstraction of something for the purpose of
understanding it before building it.
• Because, real systems are generally very complex. In order
to understand the real system, we have to simplify the
system.
• So a model is an abstraction that hides the non-essential
characteristics of a system and highlights those
characteristics, which are pertinent to understand it.
• Model is a simplified representation of reality.

83. What is modeling??
• Most modeling techniques used for analysis and design
involve graphic languages or set of symbols.
• These symbols are used according to certain rules of
methodology for communicating the complex relationships
•

84. Why do we
model/modeling??
• To test a physical entity before actually building it.
• To set the stage for communication between customers and
developers.
• For visualization i.e. for finding alternative representations.
• For reduction of complexity in order to understand it.

85. Object Oriented
Methedologies

86. Introduction.. To OOM
• Object Oriented Methodology (OOM) is a new system
development approach encouraging and facilitating reuse of
software components
• OOM requires that object-oriented techniques be used
during the:
– analysis,
– design and
– implementation of thesystem.
• This methodology makes the analyst to determine :
– what the objects of the system are,
– how they behave over time or in response to events,
– and what responsibilities and relationships an object has to other
objects.

87. steps
• The basic steps of system designing using OOM are:
– System Analysis
– System Design
– Object Design
– Implementation

88. (Object -Oriented)
Analysis- Design- Implementation
• Object-oriented analysis has the analyst:
– look at all the objects in a system,
– their commonalties, difference, and
– how the system needs to manipulate the objects.
• During design:
– overall architecture of the system is described.
• During implementation phase:
– the class objects and the interrelationships of these classes are
translated and actually coded using the programming language.
– The databases are created and the complete system is made
operational.

89. Advantages of OOM
• The systems designed using OOM are closer to the real
world Because of this, it becomes easier to produce
and understand designs.
• The objects in the system are immune to requirement
changes because of data hiding and encapsulation features
of object-orientation. •
• OOM designs encourage more reusability. The classes once
defined can easily be used by other applications..
• Another way of reusability is provided by the inheritance
feature of the object-orientation.

90. Advantages of OOM
• Object Oriented Methodology closely represents the
problem domain. Because of this, it is easier to produce and
understand designs.
• Object Oriented Methodology approach is more natural. It
provides nice structures for thinking and abstracting and
leads to modular design.

91. Popular OOM
• Booch Methodology [1994]: He developed the Object
Oriented Analysis and Object Oriented Design (OOA/OOD)
concepts.
• RDD Methodology [1990]: Wirfs-Brock, Wilkerson, and
Wiener developed Responsibility Driven Design (RDD)
methodology.
• OMT methodology [1991]: James Rumbaugh led a team at
research labs of General Electric to develop the Object
Modeling Technique (OMT).
• OOSE [1994]: Ivar Jacobson developed the Object Oriented
Software Engineering (OOSE).

92. Models supported by OMT
• Object/static Model - This model describes the objects
in a system and their interrelationships. This model
observes all the objects as static and does not pay any
attention to their dynamic nature.
• Dynamic Model - This model depicts the dynamic aspects
of the system. It portrays the changes occurring in the
states of various objects with the events that might occur
in the system.
• Functional Model - This model basically describes the data
transformations of the system. This describes the flow of
data and the changes that occur to the data throughout
the system.

93. Summary of Unit 1
• We learned about:
– Object Oriented Concepts:
• Abstraction
• Encapsulation
• Hierarchy
• Modularity
• Polymorphism
• Typing, persistency, concurrency
– Object:
• State
• Behavior
• Identity
• Roles and responsibility
• Life time
• Object Oriented
Development
• Object Oriented
Methodology
• Object modeling
technique(introduction):
• Object/ static
modeling
• Dynamic modeling
• Functional modeling

94. Course Outcome Mapping
• Unit 1: Introduction
– The successful completion
contributed towards partial
achievement of :
• Course outcome 1
• Course outcome 3

95. End of Unit 1