1. OBJECT ORIENTED ANALYSIS
AND DESIGN USING UML
Presented by :
Arifa Mehreen
M.Tech. , CSE

2. Outline
Introduction
Software Engineering techniques
Object Oriented Programming (OOP)
Elements of OOP
Object, Class, Data Encapsulation, Data
Abstraction, Inheritance, Polymorphism,
Overloading, Information Hiding.
Phases of Software Lifecycle : Feasibility
Study, Requirement Analysis and Specification,
Design, Coding, Testing, Maintenance.
Model
Unified Modeling language (UML)
Views of a System
 Use case Diagram
Case Study
Utility of use case diagrams
Factoring of use cases : Generalization,
Includes, Extends
Use case Packages

3. Introduction
Software : A generic term for organized collection of computer data and instructions to perform a
specific task.
Software Crisis : Development in software technology continue to be dynamic.
Issues that need to be addressed to face this crisis :
 How to represent real-life entities of problems in system design?
 How to ensure reusability and extensibility of modules?
 How to develop modules that are tolerant to any changes in future?
 How to improve software productivity, decrease software cost and improve quality of software?
 How to manage time schedules?

4. Solution
 Spread of Software Engineering practices among engineers.
Software Engineering is the application of a systematic, disciplined approach to the
development, operation, and maintenance of software, and the study of these
approaches, that is, the application of engineering to software.

5. Software Engineering Techniques
 Evolution of Software Engineering techniques :
 Early computer programming
 High level language programming
 Control flow based design
 Structured programming
 Data Structure oriented design
 Data Flow oriented design
 Object Oriented design.

6. Object Oriented Programming (OOP)
It is an approach that provides a way of modularizing programs by creating partitioned
memory area for both data and functions that can be used as templates for creating
copies of such modules on demand.

7. Characteristics of OOP
Emphasis is on data rather than procedure.
Programs are divided into what are known as objects.
Functions that operate on the data of an object are tied together in the data structure.
Data is hidden and cannot be accessed by external functions.
Objects may communicate with each other through functions.
New data and functions can be easily added whenever necessary.
Follows bottom-up approach in program design.

8. Elements of Object-Oriented Programming
 Objects
Classes
Encapsulation and Data Abstraction
Inheritance
Polymorphism
Information Hiding
Overloading

9. Objects
A system is designed as a set of interacting objects.
Objects are often real world entities and can also be conceptual entities.
Considering system as a set of objects provides decomposition of large problem into
smaller parts and makes easy to understand design and implementation of system.
Object consists of data (attributes) and functions (methods) that operate on data.

10. Class
 Class is a template for constructing objects. But only defining a class doesn't create any objects.
Objects are variables of the type class. Once a class has been defined we can create any number
of objects belonging to that class.
A class is thus a collection of objects of similar type.
Objects of same class possess similar attributes and methods.
DATA TYPE : A data type identifies a group of variables having a particular behavior. A data
type can be instantiated to create a variable. Ex:- int , char , etc.
METHODS : Operations supported by an object are implemented in the form of methods.

11. Data Encapsulation
Data encapsulation combines data and functions into a single unit called class.
When using data encapsulation data is not accessed directly; it is only accessible
through the methods present inside the class.
Data encapsulation enables data hiding, which is an important concept of OPP.
Fig : Data Encapsulation

12. Data Abstraction
Abstraction refers to the act of representing essential features without including the
background details or explanations.
Data abstraction increases the power of programming languages by creating user-
defined data types.
Classes use the concept of abstraction and are defined as a list of abstract attributes and
functions.
Data of an object can be accessed only through its methods. No object can directly
access data of other objects, only through methods.
Since classes use the concept of data abstraction, they are known as Abstract Data
Types (ADT).

13. Inheritance
This feature allows to define a new class by incrementally extending the features of an
existing class.
The original class is called base class also known as parent class/super class and the
new class obtained through inheritance is called derived class also known as child
class/sub class.
Benefits: It helps to reuse an existing part rather than hand coding every time. Thus it
increases reliability and decreases maintenance cost.
It not only supports reuse but also directly facilitates extensibility within a given
system.
When software system is constructed out of reusable components, development time is
less & product can be generated more quickly and easily.

14. Polymorphism
The ability to take more than one form is known as polymorphism.
An operation may exhibit different behaviours in different instances. The behaviour
depends upon the types of data used in the operation.
Polymorphism plays an important role in allowing objects having different internal
structures to share the same external interface.
It is extensively used in implementing inheritance.

15. Overloading
A single method name can be used to handle different number and different types of
arguments to exhibit different behaviour. This is similar to a particular word having
several different meanings depending on the context.
Using a single method name with different parameter types to perform different types
of tasks is known as method overloading.
For ex: “<<“ operator is used in C++ as insertion operator i.e. for printing output on to
screen. Whereas “<<“ operator is also used as bit-wise left shift operator. This process of
making an operator to exhibit different behaviours in different instances is known as
operator overloading.

16. Information Hiding
Information hiding means that the implementation details of an object’s state and
behaviour are hidden from users and other objects to protect the state and behavior from
unauthorized access.
Fig : Information Hiding

17. Benefits of Object Oriented Programming
Since it provides a better syntax structure, modelling real world problem is easy and
flexible.
Complex software systems can be modularised on the basis of class and objects.
Data encapsulation and information hiding increases software reliability and
modifiability. It do not allow unauthorized users to access the data.
Polymorphism and dynamic binding increases flexibility of code by allowing the
creation of generic software components.
Inheritance allows software code to be extensible and reusable.

18. Software Lifecycle Model
A software life cycle model (also called process model) is a descriptive and
diagrammatic representation of the software life cycle.
A life cycle model represents all the activities required to make a software product
transit through its life cycle phases.
It also captures the order in which these activities are to be undertaken.

19. Need for Software Lifecycle Model
A software life cycle model is needed for development of the software product to be in
a systematic and disciplined manner.
When a software is being developed there must be clear understanding among team
members about when and what to do.
Otherwise it will lead to chaos and project failure.
It defines entry and exit criteria for every phase which must be satisfied during the
process of development.
It helps monitor the progress of the project.

20. Phases of Software Lifecycle
Feasibility study
 Requirement Analysis and Specification
 Design
 Coding and Unit Testing
 Integration and System Testing
 Maintenance

21. Feasibility Study
To determine financial and technical feasibility to develop the product.
Study input data to system and output produced by the system.
What kind of processing can be done on system and various constraints of the system.
Look for different solutions possible.
Examine each solution in terms of resources required, cost and time. Pick the best among them.
Determine if customer budget meets cost of product and if they have sufficient technical expertise
in area of development.

22. Requirement Analysis and Specification
To understand exact requirements of customer and document them properly.
Collect all relevant information from customer regarding product to remove incompleteness and
inconsistencies.
Collect data from users and customers through interviews and discussions.
Organize requirements into SRS (Software Requirement Specification) document.
SRS document contains functional requirements , non-functional requirements and goals of
implementation.

23. Design
Aim is to transform requirements in SRS document in a structure that can be
implemented in some programming language.
Software architecture is derived from SRS document.
 Traditional Design Approach
- Structured analysis of requirements specification followed by structured design.
Object Oriented Design Approach
- Objects in problem and solution domain are identified , then relationship among
objects are identified. Object structure is refined to obtain detailed design.

24. Coding and Unit Testing
Also called implementation phase.
Purpose is to translate software design into source code.
Each component of design is implemented as a program module.
End product is set of program modules that have been individually tested.
Testing each module in isolation is an efficient way to debug errors.

25. Integration and System Testing
Individual modules are integrated in a planned manner, normally incrementally over a
number of stages.
At each step, partially integrated system is tested and more modules added as
previously planned.
When all modules are integrated, system testing is carried out to ensure all
requirements specified in SRS document is present in the developed system.
 Three phases of system testing : Alpha testing, Beta testing , Acceptance testing.
System Test Plan document contains test related activities, schedule of testing, allocates
resources, lists test cases and expected output for each test case.

26. Maintenance
Corrective Maintenance :
Correcting errors that were not discovered during product development phase.
Perfective Maintenance :
Improving, enhancing functionalities of system according to customer’s requirements.
Adaptive Maintenance :
Porting software to work in a new environment.

27. 27
Model
What is a model?
A model is constructed by capturing important aspects of the application while ignoring the
rest.
A model can be graphical , textual or code based.
 Model of a problem is called analysis model.
 Model of a solution is called design model which is obtained by iterative refinements to
analysis model using design methodology.

28. Benefits of Modeling a Software
Model helps manage complexity.
Easy to understand and construct.
Models used not only to document results but also to arrive at the result themselves.
Useful in documenting design and analysis results.
Model varies depending on purpose for which it is being created.

29. Unified Modeling Language (UML)
UML is a graphical modeling tool.
It is used to visualize, specify, construct and document artifacts of a software system.
UML has its own syntax and semantics to create visual model of the system.
UML models both large and small problems.

30. UML Diagrams
 UML diagrams facilitates comprehensive understanding of the system.
Used to construct nine different types of diagrams.
Such models can be refined to get actual implementation of the system.
UML diagrams can capture five views of the system which are :
 User’s view
 Structural view
 Behavioral view
 Implementation view
 Environmental view

31. Views of a System
Fig : Different types of diagrams and views supported in UML

32. User’s View
 Defines functionalities made available by system to its users.
 Captures external users view of system in terms of functionalities offered by system.
 Black box view of system where internal structure, dynamic behavior of different
system components, implementation , etc are not visible.
It is a functional model compared to object model of all other views.
User’s view is represented by :
 Use Case diagram

33. Structural View
Defines kinds of objects (classes) important to system working understanding and its
implementation.
Also captures relationships among classes / objects.
Also called static model since structure of a system does not change with time.
Structural view is represented by :
 Class diagram
 Object diagram

34. Behavioral View
Captures how objects interact with each other to realize the system behavior.
System behavior captures dynamic behavior of the system.
Behavioral view is represented by :
 Sequence diagram
 Collaboration diagram
 State Chart diagram
 Activity diagram

35. Implementation View
The implementation view captures important concepts of system and their
dependencies.
Implementation view is represented by :
 Component diagram

36. Environmental View
This view models how different components are implemented on different pieces of
hardware.
Environmental view is represented by :
 Deployment diagram

37. Use Case Model
The use case model for any system consists of a set of use cases.
Use cases represent different ways in which system can be used by the users.
Way to find all use cases :
 Ask question : “What users can do using the system?”
Purpose of use cases is to define behavior without revealing internal structure of the
system.
Use case represents a sequence of interactions between user and system.
There is a mainline sequence and there may be variations / alternative paths to it.

38. Use Case Diagram
A use case model can be documented by drawing a use case diagram and writing an
accompanying text elaborating the drawing.
Name of use case is written inside ellipse.
All ellipses (use cases) of system are enclosed within a rectangle which represents
system boundary with the name of system being modeled written inside rectangle.
Different users of system are represented by stick person icon referred to as actors.
Line connecting actor and use case is called communication relationship which indicates
that actor uses functionality provided by use case.
Both human users and external systems can be represented by stick person icons.

39. Use Cases Model Example
Fig : Example use case model

40. Use Cases Model Example
Fig : Use case model for supermarket prize scheme

41. Text Description
Fig : Text description example for a scenario

42. Utility of use case diagrams
Use cases along with accompanying text description serve as a type of requirements
specification of the system and form the core model to which all other models must
conform.
Identifying different types of users (actors) helps implementing a security mechanism
through a login system, so that each actor can involve only those functionalities to which
he is entitled to.
Another use is in preparing the documentation (e.g. users’ manual) targeted at each
category of user.
Further, actors help in identifying the use cases and understanding the exact functioning
of the system.

43. Factoring of use cases
Complex use cases need to be factored into simpler component use cases.
Use cases need to be factored whenever there is common behaviour across different use
cases.
Factoring makes it possible to define such behaviour only once and reuse it whenever
required.
This makes analysis of the class design much simpler and elegant.
UML offers three mechanisms for factoring of use cases : Generalization, Includes,
Excludes.

44. Generalization
Use case generalization is used when one use case that is similar to another, but does
something slightly differently or something more.The child use case inherits the
behaviour and meaning of the parent use case.
The base and the derived use cases are separate use cases and should have separate text
descriptions.
Fig : Representation of use case generalization

45. Includes
The includes relationship involves one use case including the behaviour of another use
case in its sequence of events and actions.
The includes relationship occurs when a chunk of behaviour is similar across a number
of use cases.
It explores the issue of reuse by factoring out commonality across use cases which helps
in not repeating the specification and implementation across different use cases.
In the includes relationship, a base use case compulsorily and automatically includes the
behaviour of the common use cases. The base use case may include several use cases.

46. Includes..
Fig : Example of use case inclusion

47. Extends
The extends relationship among use cases allows to show optional system behaviour. An optional
system behaviour is executed only if certain conditions hold, otherwise the optional behaviour is
not executed.
The extends relationship is similar to generalisation. But unlike it, the extending use case can add
additional behaviour only at an extension point only when certain conditions are satisfied.
The extends relationship is normally used to capture alternate paths or scenarios.
Fig : Example of use case extension

48. Use case Packages
Packaging is the mechanism provided by UML to handle complexity.
Any modelling element that becomes large and complex can be broken up into packages.
Any element of UML (including another package) can be put in a package diagram. The symbol
for a package is a folder.
Just as a large collection of documents is organized in a folder, UML elements are organized into
packages

49. Use case Packages....
Fig : Use case packaging example

50. Thank You..