• Object-oriented (OO) design techniques are extremely
– Inception in early 1980’s and nearing maturity.
– Widespread acceptance in industry and
– Unified Modelling Language (UML) already an ISO
standard (ISO/IEC 19501).
4. Object Oriented
• A system is designed as a set of interacting objects:
– Often, real-world entities: e.g. an employee, a book
– Can be conceptual objects also: e.g. Controller,
• Objects consists of data (attributes) and functions
(methods) that operate on data.
• Hides organization of internal information
– Data abstraction
5. Model of an Object
mi are methods
of the class
6. Components of Object Model
• Methods & Messages
7. Advantages of Object-Oriented
• Code and design reuse
• Increased productivity
• Ease of testing and maintenance
• Better understandability
• Elegant design:
– Loosely coupled, highly cohesive objects:
– Essential for solving large problems.
• Initially incurs higher costs
– After completion of some projects reduction in cost
• Using well-established OO methodology and environment:
– Projects can be managed with 20% -- 50% of traditional
cost of development.
8. Object modelling using UML
• Unified Modeling Language is a modelling language
– Not a system design or development methodology
• Used to document object-oriented analysis and design
• Independent of any specific design methodology
• UML developed in early 1990s
– To standardize the large number of object-oriented
modelling notations that existed.
• Current version is UML2.0
• Adopted by Object Management Group (OMG) in 1997
– OMG an association of industries that promotes
consensus notations and techniques
10. Flash Back
• Grady Booch was
working as Chief
Scientist of Rational
• Rational Software
Corporation hired James
Rumbaugh from General
Electric in 1994
• Ivar Jacobson joined
them at Rational in 1995
• And the History is made
12. What is UML
• UML a graphical modelling tool, easy to understand
• It provides many diagrams to capture different views
of a system
– Model is required to capture only important aspects
– Helps in managing complexity
16. Use Case Model
• Consists of a set of “use cases”
• It is the central model:
– Other models must conform to this model
– Not really an object-oriented model
– A functional model of the system
• Use Cases are the main tasks performed by the users of
• Use Cases describe the behavioral aspects of the system.
• Use Cases are used to identify how the system will be
• Use Cases are a convenient way to document the
functions that the system must support.
• Use Cases are used to identify the components (classes)
of the system.
17. Use Cases
• Normally, use cases are independent of each other
• Implicit dependencies may exist
• Example: In Library Automation System, renew-book and
reserve-book are independent use cases.
– But in actual implementation of renew-book--- A check is
made to see if any book has been reserved using
• Other Possible Use Cases in Library information system
– add-book, etc.
18. Representation of Use Cases
• Represented in a use case diagram
– A Use Case is represented by an ellipse
– System boundary is represented by a rectangle
– Users are represented by stick person icons (actor)
– Communication relationship between actor and
Use Case by a line
• External system by a stereotype
19. Ex1: Draw a Use Case Model
• Video Store Information System supports the
following business functions:
– Recording information about videos the store owns
• This database is searchable by staff and all customers
– Information about a customer’s borrowed videos
• Access by staff and also the customer. It involves video database
– Staff can record video rentals and returns by
customers. It involves video database searching.
– Staff can maintain customer, video and staff
– Managers of the store can generate various reports.
21. Development of a Use Case Diagram
• Identify all of the actors who will use the system.
• Interview these actors to identify the functions that
they need to perform. (use cases)
• Identify scenarios (sequence of steps to accomplish a
• Identify common steps within the different scenarios.
Separate them into different use cases so that they
can easily be included in other scenarios.
• Identify relationships between use cases.
• Actor - an entity external to the system that in some
way participates in the use case. Actor represents a
role that a user can play.
• An actor typically stimulates the system with input
events or receives outputs from the system or does
• Actors are treated like classes and can be generalized.
• Primary actor: Use the system to achieve a goal.
(found in left side of the use case diagram)
• Secondary actor: plays a supporting role to facilitate
the primary actor to achieve their goal. (right side)
23. Identification of Use Cases
– Identify the actors related to a system or
– For each actor, identify the processes they initiate or
– Identify the external events that the system must
– Relate the events to actors and use cases.
24. Factoring Use Cases
• Two main reasons for factoring:
– Complex use cases need to be factored into simpler
– To represent common behaviour across different
• Three ways of factoring:
• The child use case inherits the behaviour of the parent
– The child may add to or override some of the
behavior of its parent.
• When you have a piece of behaviour that is similar
across many use cases
– Break this out as a separate use-case and let the
other ones “include” it
• Examples of use case include
– Validate user interaction
– Sanity check on sensor inputs
– Check for proper authorization
Base use case Common
• Use when a use-case optionally can do a little bit
– Capture the normal behaviour
– Capture the extra behaviour in a separate use-case
– Create extends dependency
• Makes it a lot easier to understand
29. Ex2: Course Management Software
• At the beginning of each semester,
– Each professor shall register the courses that he is going
• A student can select up to four-course offerings.
– During registration a students can request a course
catalogue showing course offerings for the semester.
– Information about each course such as professor,
department and prerequisites would be displayed.
– The registration system sends information to the billing
system so the students can be billed for the semester.
• For each semester, there is a period of time during which
dropping of courses is permitted.
• Professors must be able to access the system to see which
students signed up for each of their course offerings.
• A class represents a set of objects having similar
attributes, operations, relationships and behaviour.
• Instances are objects
• Template for object creation
• Considered as abstract data type (ADT)
– Examples: Employees, Books, etc.
• Sometimes not intended to produce instances:
– Abstract classes
35. Methods & Messages
• Operations supported by an object:
– Means for manipulating the data of other objects.
– Invoked by sending a message (method call).
– Examples: calculate_salary, issue-book,
• Allows to define a new class
(derived class) by extending
or modifying existing class
• Represents generalization-
• Allows redefinition of the
existing methods (method
– Single/Simple; multilevel
• Enables objects to communicate with each other:
– Thus one object must “know” the address of the
corresponding object in the association.
• Usually binary:
– But in general can be n-ary.
Library Member Book
1 *borrowed by
• Represents whole-part relationship
• Represented by a diamond symbol at the composite
• Cannot be reflexive(i.e. recursive)
• Not symmetric
• It can be transitive
* Paragraph 1 *
• A stronger form of aggregation
– The whole is the sole owner of its part.
• A component can belong to only one whole
– The life time of the part is dependent upon
• The composite must manage the creation and
destruction of its parts.
• Dependency relationship can arise due to a variety of
– Stereotypes are used to show the precise nature of
Abstraction «abstraction» Relates two model elements, that represent
the same concept at different levels of
Binding «bind» Connects template arguments to template
parameters to create model elements from
Realization «realize» Indicates that the client model element is an
implementation of the supplier model element
Substitution «substitute» Indicates that the client model element
takes place of the supplier.
• Denotes poly (many) morphism (forms).
• Under different situations:
– Same message to the same object can result in
• Static binding
• Dynamic binding
Ability to parameterize class definitions.
Example: class stack of different types of elements:
Floating point stack
Define generic class stack:
Later instantiate as required