The document provides a comprehensive overview of principles of object-oriented analysis and design (OOAD), outlining the stages of software development including analysis, design, implementation, testing, and maintenance. It discusses the Unified Process (UP) for software development, detailing its iterative nature, phases, disciplines, and the use of the Unified Modeling Language (UML) for modeling software systems. Additionally, it includes case studies such as a point-of-sale (POS) system, emphasizing use case diagrams to illustrate system interactions and requirements.

1. KONGUNADU COLLEGE OF
ENGINEERING AND
TECHNOLOGY
Department of Information
Technology
20IT501PE
PRINCIPLES OF OBJECT
ORIENTED ANALYSIS AND
DESIGN

2. OBJECTIVES

7. Introduction
• Any software development approach goes through the
following stages:
1. Analysis,
2. Design,
3. Implementation
4. Testing and
5. Maintenance

8. Orthogonal views of SD
• Traditional views – Focuses on data and Functions
• OO methodologies – Focuses on objects
What is Analysis?
Analysis is the process of investigation of the problem and the
requirements, than finding its solution
What is Design?
Design is the process of finding conceptual solutions that fulfill
the requirements than implementing it.
• Analysis and design have been summarized in the phase
– Do the right thing (analysis), and
– Do the thing right (design).

9. Phases in OO Software Development
• Major phases of s/w development using OO methodology are
– Object-oriented analysis (OOA),
– Object-oriented design (OOD), and
– Object-oriented implementation or Object-Oriented Programming (OOP)

11. Object oriented analysis and design (OOAD)
• OOAD is comprised of two parts:
– Object Oriented Analysis (OOA)
– Object Oriented Design (OOD)
• OOA (What is OOAD?)
– Focuses on What the system does (its static structure and behavior),
• Emphasis is to identify and describe objects (concepts) in the problem domain.
Objects should be identified with responsibilities.
• Responsibilities are the functions performed by the object.

12. OOD
•Focuses on How the system does it.
•Emphasis is to define s/w objects & how they collaborate to fulfill the
requirements
In this stage,
The objects are collaborated according to their intended
association.
After the association is complete the design is also
complete.

13. OOP
• Third phase is object oriented implementation.
– Here, the design is implemented using object oriented languages like
Java, C++ etc.

14. Example – Library Information System
• During OOA, find the objects such as Book, Library.
• During OOD, a Book s/w object may have a title attribute and a getChapter method
• During OOP, design objects are implemented, such as a Book class in Java

15. Example – Flight Information System

16. Example
• The Key steps in the analysis and design include,
1.Define Usecases
2.Define domain model
3.Define interaction diagrams
4.Define design diagrams

17. Purpose of OOAD
• Purpose of OOAD can described as:
1. Identifying the objects of a system.
2. Identify their relationships.
3. Make a design which can be converted to executables using OO
languages.

18. Unified Process (UP)

19. Introduction
• A software development process describes an approach to building,
deploying, and possibly maintaining software.
• The Unified Process is a software development process for building
object-oriented systems
• UP combines
– An iterative lifecycle and
– Risk-driven development
• UP is
– Flexible
– Well documented process description

20. A detailed refinement of Unified Process is called as Rational Unified Process
(RUP)
Unified Process is an iterative process.

22. Iterative Development
• Here, s/w development is organized
– Into a series of short, fixed-length mini-projects called iterations;
• Each iteration includes its own requirements analysis, design, implementation, and
testing activities.
– the outcome of each is a tested, integrated, and executable system.
• The system grows incrementally over time, iteration by iteration, and thus
this approach is also known as iterative and incremental development
• Central ideas in iterative development are
– Small steps,
– Rapid feedback, and
– Adaptation

23. Iterative and incremental development.
• Each iteration includes its own
– Requirements analysis,
– Design,
– Implementation, and
– Testing activities.
• This approach is also known as iterative & incremental development
System may not be eligible for production deployment
Until after many iterations; for example, 10 or 15 iterations.
Result of each iteration is an executable but incomplete system

25. Feedback and Adaptation
• In this approach,
– End-users have a chance to quickly see a partial system, and
– Give feedback that helps for requirements clarification
• Feedback from building and testing
– Provides an opportunity to modify or adapt understanding of requirements or
design.
 This early feedback is worth its weight in gold
 End-users have a chance to quickly see a partial system and say, "Yes, that's
what I asked for, but now that I try it, what I really want is something slightly
different."1 This "yes...but" process is not a sign of failure;

26. Benefits of Iterative Development:
early rather than late mitigation of high risks (technical,
requirements, objectives, usability, and so forth)
early visible progress
early feedback, user engagement, and adaptation, leading to a
refined system that more closely meets the real needs of the
stakeholders
managed complexity;
the learning within an iteration can be methodically used to improve
the development process itself, iteration by iteration

27. UP Phases
• A UP organizes the work and iterations across 4 major phases:
1. Inception 2. Elaboration 3. Construction 4. Transition

28. Inception and Elaboration
• Inception:
– It is a feasibility phase, where investigation is done to support the decision to
continue or stop.
– Approximate vision, business case, scope, and vague estimates.
• Elaboration:
– It is a phase, where core architecture is iteratively implemented and high risk
issues are mitigated.
– The development cycle composed of many iterations,
and it is ends in the release of a system into production

29. Elaboration
• Elaboration includes
– Refined vision,
– Iterative implementation of the core architecture,
– Resolution of high risks,
– Identification of most requirements and scope,
– More realistic estimates.

30. UP Phases
• Construction
– Iterative implementation of the remaining lower risk and easier elements, and
– Preparation for deployment.
• Transition
– Beta testing & Deployment.
Beta testing:
Beta testing also known as user testing takes place at the end users site
by the end users to validate the usability, functionality, compatibility,
and reliability

31. UP Disciplines
• A discipline is a set of activities (and related artifacts) in one subject area.
• UP Disciples are originally called as workflows
• UP describes work activities, such as writing a use case, within the
disciplines
• In UP, an artifact is the general term for any work product :
– Such as code, Web graphics, DB schema, text documents, diagrams, models,
& so on.

32. Types of UP Disciplines
• There are 9 disciplines in UP
– Business Modeling
– Requirements
– Design
– Implementation
– Test
– Deployment
– Configuration & Change Management
– Project Management
– Environment

33. UP Disciplines
During one iteration,
the work goes on in all
disciplines

34. Artifacts in Major Three UP Disciples
• Business Modeling
– When developing a single application, this includes domain object modeling.
– When engaged in large-scale business analysis, this includes
dynamic modeling of the business processes across the entire enterprise.
• Requirements
– Requirements analysis for an application, such as writing use cases and
identifying non-functional requirements.
• Design
– All aspects of design, including the overall architecture, objects, databases,
networking, and the like.

35. Unified Modeling Language (UML)
Standard Visual Modeling Language
For specifying, visualizing, constructing, and
documenting the artifacts of s/w systems,
as well as for business modeling and
other non-software systems

36. About UML
• UML is a standard modeling language, not a software
development process.
• In 1997 UML was adopted as a standard by the Object
Management Group (OMG)
• In 2005 UML was published by the International Organization
for Standardization (ISO) as an approved ISO standard

37. Three Ways to Apply UML
• UML as Sketch – Informal and incomplete diagrams
– Created to explore the difficult parts of the problem
– They are usually focused on some aspect of the system and are not
intended to show every detail of it.
• UML as Blueprint – Relatively detailed design diagrams used either for
1. Reverse engineering
(to visualize & better understand existing code in UML diagrams)
2. Code Generation (forward engineering)
• UML as Programming Language
– Complete executable specification of a s/w system in UML
– Executable code will be automatically generated

38. Three Perspective to Apply UML
• Conceptual Perspective
– Diagrams are interpreted as describing things of the real world
• Specification (s/w) Perspective
– Diagrams describe s/w abstractions or components with specifications & interfaces,
– But no commitment to a particular implementation
(for example, not specifically a class in C# or Java)
• Implementation (s/w) Perspective
– Diagrams describe s/w implementations in a particular technology
(such as java)

39. Different Perspective with UML
Conceptual Perspective
(domain model)
Raw UML class diagram
notation used to visualize
real-world concepts.
Specification or
Implementation
Perspective
(design class diagram )
Raw UML class diagram
notation used to visualize
software elements .
2
Die
faceValue : int
getFaceValue () : int
roll()
DiceGame
die1 : Die
die2 : Die
play()
DiceGame Die
faceValue
Includes 2
1
Domain Model shows a conceptual perspective
Design Model shows a specification or implementation perspective

40. “Class” in Different Perspectives
• Rectangular boxes are classes.
– But they can be physical things, abstract concepts, software things, events, …
– When UML boxes are drawn in Domain Model, they are called as conceptual class
(or domain concept)
– When UML boxes are drawn in Design Model, they are called as design class

41. “Class” in Different Perspectives
• Use class-related terms consistent with the UML and the UP :
1. Conceptual class
– Represents the real-world concept or thing
– UP Domain Model contains conceptual classes
2. Design class
– A class representing a specification or implementation perspective of s/w
component
3. Implementation class
– A class implemented in a specific OO language (such as Java)

42. Categories of UML Diagrams
• Structure diagrams
– Show the static structure of the system
– Show the things in a system being modeled.
– In a more technical term, they show different objects in a system.
• Behavioral diagrams
– Show the dynamic behavior of the objects in a system
– Shows what should happen in a system.
– They describe how the objects interact with each other to create a
functioning system.

44. UML Structural Diagrams
• Class Diagram
– Shows a collection of static model elements such as classes and types, their contents,
and their relationships.
• Package Diagram
– Shows how model elements are organized into packages and dependencies b/w
packages

45. UML Structural Diagrams
Physical Diagrams
• Component Diagram
– Depicts the components that compose an application, system, or enterprise.
– Components, their interrelationships, interactions, and their public interfaces are depicted.
• Deployment diagram
– Shows the execution architecture of systems.
– This includes nodes, either hardware or software execution environments, and the
middleware connecting them.

46. UML Behavioral Diagrams
• State Diagram
– Represents different states that objects in the system undergo during their life cycle.
• Activity Diagram
– Displays a special state diagram where most of the states are action states and most of
the transitions are triggered by completion of the actions in the source states
– Focuses on flows driven by internal processing
• Use Case Diagram - Describes “HOW” the system works.
– Displays the relationship among actors and use cases
– Identifies the primary elements and processes that form the system.
• Interaction Overview Diagram
– A variant of an activity diagram which overviews the control flow within a system or
business process.
– Each node/activity within the diagram can represent another interaction diagram

47. UML Behavioral Diagrams
Interaction Diagrams
• Sequence diagram
– Displays the time sequence of the objects participating in the interaction
– This consists of the vertical dimension (time) and horizontal dimension (different objects)
• Collaboration diagram (Communication Diagram)
– Displays an interaction organized around the objects and their links to one another
– Numbers are used to show the sequence of messages

49. Case Study
NextGen point-of-sale (POS) system
Computerized application
used to record sales and handle payments
typically used in a retail store

50. Introduction
• POS system is a replacement for a cash register
• Components
– Hardware: computer and bar code scanner etc.
– Software
• Interfaces to various service applications, such as
– A third-party tax calculator and
– Inventory control

51. Features
• Systems is fault-tolerant;
– Even if remote services are temporarily unavailable (inventory system), they
must still be capable of capturing sales and handling at least cash payments
• A POS system support multiple & varied client-side terminals & interfaces.

52. Architectural Layers:
1.User Interface
2.Application Logic
3.Technical services

53. Brief Use Case
Example 1
 Use case: Buy Items
 Actors: Customer, Cashier
 Type: Primary
 Description:
 A customer arrives at checkout with items to purchase.
 Cashier
 Records the purchase items, and
 Collects payment,
 On completion, the Customer leaves with the items.

54. Use case
Diagrams
Buy
Items
Log In
Refund
Purchased
items
Cashier Customer
POST
System
boundary
Actor
Use case
Information
Flow

55. Use Case Scenario: Buy
Items 1
1.Customer arrives at POS terminal,tocheckout with items to purchase.
2.Cashier records each items.
If there is more than one of an item, Cashier can enter the
quantity
3.System determines the item price and adds the item information to
running sales transaction.
Description and price of the current item are presented.
4. On completion of item entry,
Cashier indicates to the POS Terminal that item entry is
complete.
5. System calculates and presents the sale total.
6. Cashier tells the Customer the total.

56. Use Case Scenario: Buy
Items 2
7. Customer choose payment type:
If cash payment, see section Pay by Cash.
If credit payment, see section Pay by Credit.
8. System logs the complete sale.
9. System updates inventory.
10. System generates a receipt.
11. Cashier gives the receipt to the Customer.
12. Customer leaves with the items purchases.
Variation
2.1. If invalid item identifier entered, indicate error.
7.1. If Customer could not pay, cancel sales transaction.

57.  Use case: Handle Returns
 Main success scenario
 A customer arrives at a checkout with items to return.
 Cashier uses the POS system to record each returned item …
 Alternate Scenarios:
If the customer paid by credit,
If refund transaction to their credit account is rejected,
 pay them with cash.
If the item identifier is not found in the system,
suggest manual entry of the identifier code (perhaps it is
corrupted).

58. Use Case Diagram
Graphic depiction of the interactions
among the elements of a system

59. Use Case Diagram
• Use case diagrams
– Specify the events of a system and their flows.
– Shows the relationship among the actors & use-case within a system
– Never describes how they are implemented.
• Use case diagrams are used at following places :
– Requirement analysis and high level design.
– Modeling the context of a system.
– Reverse engineering.
– Forward engineering.

60. Use Case Diagram
• Use cases can be denoted both textual and visual
representation (i.e. use case diagram).
• It helps us design a system from the end user's perspective.
• It is an effective technique for communicating system
behavior in the user's terms by specifying all externally visible
system behavior

61. Purpose of Use Case Diagram
• Purpose of use case diagram
– To identify functions and how roles interact with them
– To capture the dynamic aspect of a system
– Used to gather requirements of a system.
– Used to get an outside view of a system.
– Identify external and internal factors influencing the system.

63. Notations in Use Case Diagram
• Use case diagrams consists of
– Actors,
– Use cases,
– System, and
– Package
• Actor is any entity that performs a role in one given system
An actor could be
a person, organization or an external system

64. Actor
• Someone interacts with use case (system function).
• Named by noun.
• Actor plays a role in the business
• Similar to the concept of user, but a user can play different
roles
• Actor triggers use case(s).
• Actor has a responsibility toward the system (inputs), and
Actor has expectations from the system (outputs).

65. Use Case
• System function (process - automated or manual)
• Named by verb + Noun (or Noun Phrase).
• i.e. Do something
• Each Actor must be linked to a use case, while some use
cases may not be linked to actors.

66. Communication Link
• The participation of an actor in a use case is shown by
connecting an actor to a use case by a solid link.
• Actors may be connected to use cases by associations,
indicating that the actor and the use case communicate with
one another using messages.

67. Use Case Diagram Objects
• System boundary
• It is an optional element
– Used to define the scope of the use case
– Drawn as a rectangle.
– Useful when your visualizing large systems
• Package is optional element
– Used to group together use cases
– Extremely useful in complex diagrams.

69. Relationships in Use Case Diagrams
• Use case relationships can be one of the following:
1. Communicates (Association)
2. Extends
3. Include or uses
4. Generalization

70. Association
Association Between Actor and Use Case
• This one is straightforward and present in every use case diagram. Few
things to note.
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case

71. Communicates (Association)
• Participation of an actor in a use case is shown by
– Connecting the actor symbol to use case symbol by a solid path.
• Actor is said to 'communicates' with the use case.
• This is only relation between an actor and use cases

72. Generalization
• This relationship is a parent-child relationship b/w use cases
• In this relationship,
– Child use case is an enhancement of the parent use case.

73. It is shown as a directed arrow with a triangle arrowhead.
•Child use case is connected at the base of the arrow.
•Tip of the arrow is connected to the parent use case.
•You can add generalization relationships to capture attributes, operations,
and relationships in a parent model element and then reuse them in one or
more child model elements.

74. Extends
• An extends shows the relationships between use cases.
• Tip of arrowhead points to the parent use case
• Child use case is connected at the base of the arrow
• Example : Validating the user for a system.
– A invalid password is extension of validating password use case

75. Extend is a directed relationship that specifies how and when
the behavior defined in usually supplementary (optional)
extending use case can be inserted into the behavior defined in
the extended use case.

76. Include (Uses)
• In this relationship,
– A use case includes the functionality described in another use case
• Tip of arrowhead points to the child use case
• Parent use case connected at base of the arrow.
Deposit Funds and Withdraw Cash use cases
include Customer Authentication use case.
Checkout use case includes several use cases –
Scan Item, Calculate Total and Tax, and Payment

77. Use include when you are repeating yourself in two or more
separate usecases and yet want to avoid repetition

79. Concrete usecase:
Initiated by actor
Ex: Process sale
Abstract usecase:
It is a sub function usecase that is part of another usecase
Handle credit payment
Base Usecase:
A usecase that includes another usecase
Process sale - Handle credit payment
Additional usecase:
A usecase that is included another usecase

80. Generalization Extend Include
Base use case could be
abstract use case(incomplete)
or
concrete (complete).
Base use case is complete
(concrete) by itself, defined
independently.
Base use case is incomplete
(abstract use case).
No explicit location to use
specialization.
Has at least one explicit
extension location.
No explicit inclusion location
but is included at some location.
No explicit condition to use
specialization.
Could have optional extension
condition.
No explicit inclusion condition.

81. A use case with most of scenarios found in use case diagrams