1. Object-Oriented Paradigm
• Object-oriented paradigm
– Reaction to perceived shortcomings in structured
paradigm
– Problem of larger products
– Data and action treated as equal partners
CS540 Software Design 1 Lecture 14 & 15
2. Object-Oriented Analysis (OOA)
• Semi-formal specification technique
• Multiplicity of different methods
• All essentially equivalent
• Nowadays, we represent OOA using UML (unified
modeling language)
CS540 Software Design 2 Lecture 14 & 15
3. The Three Steps of OOA
• 1. Use-case modeling
– Determine how the various results are computed by the
product (without regard to sequencing)
– Largely action oriented
• 2. Class modeling (“object modeling”)
– Determine the classes and their attributes
– Purely data-oriented
• 3. Dynamic modeling
– Determine the actions performed by or to each class
– Purely action-oriented
• Iterative process
CS540 Software Design 3 Lecture 14 & 15
14. Use Case
• Use Case Name
• Actors
• Pre-Conditions
• Normal Flow
• Post-Conditions
• Exceptions or Alternate Flows
CS540 Software Design 14 Lecture 14 & 15
15. Class Modeling
• Extract classes and their attributes
• Represent them using an entity-relationship
diagram
• Deduce the classes from use cases and their
scenarios
• Often there are many scenarios
– Possible danger: too many candidate classes
CS540 Software Design 15 Lecture 14 & 15
16. Two Approaches to Class Modeling
• Noun extraction
– Always works
• CRC classes
– Need to have domain expertise
CS540 Software Design 16 Lecture 14 & 15
17. Noun Extraction
• Stage 1. Concise Problem Definition
– Define product in single sentence
• Buttons in elevators and on the floors control the
motion of n elevators in a building with m floors.
CS540 Software Design 17 Lecture 14 & 15
18. Noun Extraction (contd)
• Stage 2. Informal Strategy
– Incorporate constraints, express result in a
single paragraph
• Buttons in elevators and on the floors control
movement of n elevators in a building with m floors.
Buttons illuminate when pressed to request the
elevator to stop at a specific floor; illumination is
canceled when the request has been satisfied. When
an elevator has no requests, it remains at its current
floor with its doors closed.
CS540 Software Design 18 Lecture 14 & 15
19. Noun Extraction (contd)
• Stage 3. Formalize the Strategy
– Identify nouns in informal strategy. Use nouns as candidate
classes
• Nouns
– button, elevator, floor, movement, building, illumination, do
or
– floor, building, door are outside problem boundary —
exclude
– movement and illumination are abstract nouns — exclude
(may become attributes)
• Candidate classes: Elevator and Button
• Subclasses: Elevator Button and Floor Button
CS540 Software Design 19 Lecture 14 & 15
20. First Iteration of Class Diagram
• Problem
– Buttons do not communicate directly with elevators
– We need an additional class: Elevator Controller
CS540 Software Design 20 Lecture 14 & 15
21. Second Iteration of Class Diagram
• All relationships
are now 1-to-n
– Makes design and
implementation
easier
CS540 Software Design 21 Lecture 14 & 15
22. CRC Cards
• Class Responsibility Collaboration (CRC)
• Used since 1989 for OOA
• For each class, fill in card showing
– Name of class
– Functionality (responsibility)
– List of classes it invokes (collaboration)
– Now automated (CASE tool component)
• Strength
– When acted out by team members, powerful tool for
highlighting missing or incorrect items
• Weakness
– Domain expertise is needed
CS540 Software Design 22 Lecture 14 & 15
23. 3. Dynamic Modeling
• Produce UML state
diagram
• State, event, predicate
distributed over state
diagram
• UML “guards” are in
brackets
CS540 Software Design 23 Lecture 14 & 15
24. Testing during the OOA Phase
• CRC cards are an excellent testing technique
CS540 Software Design 24 Lecture 14 & 15
25. CRC Cards
• Consider responsibility
– 1. Turn on elevator button
• Totally unacceptable for object-oriented
paradigm
• Responsibility-driven design ignored
• Information hiding ignored
• Responsibility
1. Turn on elevator button
should be
1. Send message to Elevator Button to turn itself on
CS540 Software Design 25 Lecture 14 & 15
26. CRC Cards (contd)
• A class has been overlooked
– Elevator doors have a state that changes during
execution (class characteristic)
– Add class Elevator Doors
– Safety considerations
• Reconsider class model
• Then reconsider dynamic model, use-case
model
CS540 Software Design 26 Lecture 14 & 15
28. Third Iteration of Class Diagram
CS540 Software Design 28 Lecture 14 & 15
29. Second Iteration of Normal Scenario
CS540 Software Design 29 Lecture 14 & 15
30. Elevator Problem: OOA (contd)
• All three models are now fine
• We should rather say:
– All three models are fine for now
• We may need to return to the object-
oriented analysis phase during the
object-oriented design phase
CS540 Software Design 30 Lecture 14 & 15
31. Why Is All This Iteration Needed?
• Perhaps the method is not yet mature?
– Waterfall model (explicit feedback loops)
– Rapid prototyping model (aim: to reduce iteration)
– Incremental model, and
– Spiral model
• Latter two explicitly reflect iterative approach
• Iteration is an intrinsic property of all software
production
– Especially for medium- and large-scale products
– Expect iteration in the object-oriented paradigm
CS540 Software Design 31 Lecture 14 & 15
33. Use case diagrams
A use-case diagram gives the user’s view of a system: it
shows how users communicate with the system. A use-case
diagram uses four components: system, use cases, actors and
relationships. A system, shown by a rectangle, performs a
function.
Figure 10.6 An example of use case diagram
10.33
34. Class diagrams
The next step in analysis is to create a class diagram for the
system. For example, we can create a class diagram for our
old-style elevator. To do so, we need to think about the
entities involved in the system.
Figure 10.7 An example of a class diagram
10.34
35. State chart
After the class diagram is finalized, a state chart can be
prepared for each class in the class diagram. A state chart in
object-oriented analysis plays the same role as the state
diagram in procedure-oriented analysis.
10.35
55. USE CASE:
How do we find the use cases?
• What functions will the actor want from the system?
• Does the system store information? What actors will create, read, update.
Or delete that information?
• Does the system need to notify an actor about changes in its internal
state?
55
56. USE CASE:
• Generic format for documenting the use case:
- Pre condition: If any
– Use case : Name of the case.
– Actors : List of actors(external agents), indicating who
initiates the use case.
– Purpose : Intention of the use case.
– Overview : Description.
– Type : primary / secondary.
– Post condition: If any
• Typical Course of Events:
ACTOR ACTION : Numbered actions of the actor.
SYSTEM RESPONSE : Numbered description of system responses.
56
57. USE CASE:
USE CASE documentation example:
• The following use case describes the process of opening a new account in
the bank.
Use case :Open new account
Actors :Customer, Cashier, Manager
Purpose :Like to have new saving account.
Description :A customer arrives in the bank to open the new
account. Customer requests for the new account
form, fill the same and submits, along with the
minimal deposit. At the end of complete successful
process customer receives the passbook.
Type :Primary use case.
57
58. Grouping USE CASES:
• Those use case functionality which are directly dependent on the system
environment are placed in interface objects
• Those functionality dealing with storage and handling of information are
placed in entity objects
• Functionality's specific to one or few use cases and not naturally placed in
any of the other objects are placed in control objects
By performing this division we obtain a structure which helps us to
understand the system from logical view
58
59. OOAD --- USE CASE driven
Analysis Design &
Implementation Test
Use cases make up the glue
Implement Verify that use cases
Capture,clarify use cases are satisfied
& validate use cases
59
60. SYSTEM BOUNDARY:
What is System Boundary?
• It is shown as a rectangle.
• It helps to identify what is external verses internal, and what the
responsibilities of the system are.
• The external environment is represented only by actors.
60
61. RELATIONSHIP:
What is Relationship?
• Relationship between use case and actor.
Communicates
• Relationship between two use cases
Extends
Uses
• Notation used to show the relationships:
<< >>
61
62. RELATIONSHIP:
• Relationship between use case and actor is often referred as
“communicates” .
• Relationship between two use cases is refereed as either uses or
extends.
USES:
• - Multiple use cases share a piece of same functionality.
• - This functionality is placed in a separate use case rather than
documenting in every use case that needs it.
62
63. RELATIONSHIP:
Contd...
• A uses relationship shows behavior that is common to one or
more use cases.
EXTENDS:
• It is used to show optional behavior, which is required only
under certain condition.
63
64. USE CASE diagram:
Use case diagram for the shown functionality.
Balance status
report
extends
Clerk Withdraw cash
Customer
uses
Validation
ATM
Manager
64
65. Objective
• To understand and capture the detailed specification of a system to be
developed, from user perspective.
65
66. Beginning Analysis and Design
• Completion of first version of use case diagram initiates the processes of
analysis and design.
• UML provides the framework to carry out the process of analysis and
design in form of set of diagrams.
• Every diagram and notation used in the diagram carries the semantics.
• First step towards analysis and design is to specify the flow of events.
66
67. Flow of Events:
• A flow of events document is created for each use case.
• Details about what the system must provide to the actor when the use is
executed.
• Typical contents
– How the use case starts and ends
– Normal flow of events
– Alternate flow of events
– Exceptional flow of events
• Typical Course of Events has:
Actor Action(AA)
System Response(SR)
67
68. Normal Flow of Events:
For withdrawal of cash:
• 1.(SR) The ATM asks the user to insert a card.
• 2.(AA) The user inserts a cash card.
• 3.(SR) The ATM accepts the card and reads its serial number.
• 4.(SR) The ATM requests the password.
• 5.(AA) The user enters 1234.
• 6.(SR) The ATM verifies the serial number and password with the
bank and gets the notification accordingly.
• 7.(SA)The ATM asks the user to select the kind of transaction.
• 8.(AA)User selects the withdrawal.
68
69. Normal Flow of Events:
Contd...
• 9.(SR)The ATM asks for the amount of cash; user enters Rs. 2500/-
• 10.(SR)The ATM verifies that the amount of cash is within predefined
policy limits and asks the bank, to process the transaction which
eventually confirms success and returns the new account balance.
• 11.(SR) The ATM dispenses cash and asks the user to take it.
• 12.(AA) The user takes the cash.
• 13.(SR) The ATM asks whether the user wants to continue.
• 14.(AA) The user indicates no.
69
70. Normal Flow of Events:
Contd...
• 15.(SR) The ATM prints a receipt, ejects the card and asks the user to take
them
• 16.(AA) The user takes the receipt and the card.
• 17.(SR) The ATM asks a user to insert a card.
70
71. Alternative Flow of Events:
For withdrawal of cash use case:
• 9. The ATM asks for the amount of cash; the user has change of mind and
hits the “cancel”.
71
72. Exceptional Flow of Events:
For withdrawal of cash use case:
• 3 Suspicious pattern of usage on the card.
• 10 The machine is out of cash.
• 11 Money gets stuck in the machine.
72
73. Why flow of events?
• It helps in understanding the functionality of a system to be developed.
• Flow of events helps in finding objects of the system to be developed.
• Happens to be most important and very first step towards analysis and
design.
73
74. What is Scenario?
• The functionality of the use case is captured in flow of the
events.
• A scenarios is one path through the flow of events for the use
case.
• Scenarios are developed to help identify objects, classes and
object interactions for that use case.
74
75. USE CASE Realizations:
• The use case diagram presents an outside view of the system
• Interaction diagrams describe how use cases are realized as interactions
among societies of objects.
• Two types of interaction diagrams
– Sequence diagrams
– Collaboration diagrams
75
76. What is Interaction diagram?
• Interaction diagrams are models that describe how groups of objects
collaborate in some behavior
• There are 2 kinds of interaction diagrams
• Sequence diagram
• Collaboration diagram
• Sequence diagrams are a temporal representation of objects and their
interactions
• Collaboration diagrams are spatial representation of objects, links and
interrelations
76
77. What is sequence diagram?
• Typically these diagrams capture behaviors of the single scenario.
• Shows object interaction arranged in time sequence.
• They show sequence of messages among the objects.
• It has two dimensions, vertical represents time & horizontal
• represents objects.
• Components of sequence diagram:
-objects
-object lifeline
-Message
-pre/post conditions.
77
78. OBJECT & OBJECT LIFE LINE:
•Object are represented by rectangles and name of the objects are
underlined.
•Object life line are denoted as dashed lines. They are used to
model the existence of objects over time.
Name:Class
78
79. MESSAGES:
• They are used to model the content of communication between objects.
They are used to convey information between objects and enable objects
to request services of other objects.
• The message instance has a sender, receiver, and possibly other
information according to the characteristics of the request.
• Messages are denoted as labeled horizontal arrows between life lines.
• The sender will send the message and receiver will receive the message.
79
80. MESSAGES:
Contd…
• May have square brackets containing a guard conditions. This is a Boolean
condition that must be satisfied to enable the message to be sent.
• May have have an asterisk followed by square brackets containing an
iteration specification. This specifies the number of times the message is
sent.
• May have return list consisting of a comma -separated list of names that
designate the values of returned by the operation.
• Must have a name or identifier string that represents the message.
• May have parentheses containing an argument list consisting of a comma
separated list of actual parameters passed to a method.
80
81. Sequence diagram [for withdrawal of cash, normal flow]
:Customer :ATM :Bank
Insert card
Request password
Enter the password
Verify account
Account o.k.
Request option
Enter option Create
Request amount
Transaction
:Transaction
Enter the amount
Update transaction
Transaction commit
Transaction
Dispense cash complete
Request take cash
Take cash
Request continuation
Terminate
Print receipt ,eject card
Request take card
Take card
Display main screen and prompt for the card.
81
82. What is Collaboration diagram?
• Collaboration diagrams illustrate the interaction between the
objects, using static spatial structure.
• Unlike sequence diagram the time is not explicitly represented in these
diagrams
• In collaboration diagram the sequence of messages is indicated by
numbering the messages. The UML uses the decimal numbering scheme.
• In these diagrams, an actor can be displayed in order to represent the
triggering of interaction by an element external to the system.
• This helps in representing the interaction, without going into the details
of user interface.
82
83. Components of collaboration diagram:
• Named objects
• Links: Links are represented by a continuous line between objects, and
indicates the exchange of messages.
• Messages has following attributes:
• Synchronization --thread name, step within thread.
• Sequence number
• Message labels : The name of the message often corresponds to an operation
defined in the class of the object that is the destination of the message. Message
names may have the arguments and return values.
• *[iteration].
• It uses decimal notation.
• Message direction.
83
84. Semantics of components:
• Object names identify which objects are participating and the links show
which objects collaborate
• A link between two objects must exist for one object to send message to
another and vice a versa.
• Messages in the collaboration diagram get transformed to more detailed
signature.
• They use the decimal notation system for numbering the messages.
• The direction of the message defines the sender and receiver of the
message
84
85. The elements of message:
• Predecessor
• Role names
• Message qualifiers
– Iteration expression
– Parameters
– Return values
– Guard
– Message stereotypes
• Concurrent thread sequencing
• Thread dependencies
• Message expression
[Pre] A1:*(expression):doIt(p,r):return value
85
86. The examples of message:
4:Display(x,y) Simple
message
3.3.1:Display(x,y) Nested
message
4.2:subtract[Today,Birthday]:age Nested
message with
return value
[Age >=18] 6.2:Vote() Conditional
message
4.a,b.6/c.1:Turnon(Lamp) Synchro. with
other flow of
execution
1*:wash() Iteration
3.a,3.b/4*||[i:=1..n]:Turnoff() Parallel
iteration
86
87. Collaboration diagram [for withdrawal of cash, normal flow.]
1. Insert card
Enter password, Enter kind
Enter amount,
Take cash, Take card
cancel,Terminate, Continue Create Transaction
Transaction complete
CUST- TRANSA-
ATM CTION
OMER Display main screen
unreadable card message,
request password,
request kind, request amount,
canceled message, eject card, failure message,
dispense cash, request take cash Transaction succeed
request continuation, Transaction failed
print receipt, request take card account o.k.
bad account message, Verify account, bad account,
bad bank account message process transaction bad password,
bad bank code
BANK
87
88. Objective of the fifth module
• To know the interaction among the objects in temporal and spatial form.
• To know how objects collaborate among each other and hence delegate
the responsibility to the respective objects.
• To understand how the messages get matured with more information.
88
90. What is Class diagram?
• A class diagram shows the existence of classes and their relationships in
the logical view of a system
• UML modeling elements in class diagrams are:
– Classes, their structure and behavior.
– relationships components among the classes like
association, aggregation, composition, dependency and inheritance
– Multiplicity and navigation indicators
– Role names or labels.
90
91. Major Types of classes:
Concrete classes
• A concrete class is a class that is instantiable; that is it can have different
instances.
• Only concrete classes may be leaf classes in the inheritance tree.
Abstract classes
• An abstract class is a class that has no direct instance but whose
descendants classes have direct instances.
• An abstract class can define the protocol for an operation without
supplying a corresponding method we call this as an abstract operation.
• An abstract operation defines the form of operation, for which each
concrete subclass should provide its own implementation.
91
93. 10-3 DESIGN PHASE
The design phase defines how the system will
accomplish what was defined in the analysis phase. In
the design phase, all components of the system are
defined.
10.93
94. Procedure-oriented design
In procedure-oriented design we have both procedures and
data to design. We discuss a category of design methods that
concentrate on procedures. In procedure-oriented design, the
whole system is divided into a set of procedures or modules.
10.94
95. Structure charts
A common tool for illustrating the relations between
modules in procedure-oriented design is a structure chart.
For example, the elevator system whose state diagram is
shown in the previous slides can be designed as a set of
modules shown in the structure chart below
10.95
A structure chart
96. Modularity
Modularity means breaking a large project into smaller parts
that can be understood and handled easily. In other
words, modularity means dividing a large task into small
tasks that can communicate with each other. The structure
chart discussed in the previous section shows the modularity
in the elevator system. There are two main concerns when a
system is divided into modules: coupling and cohesion.
Coupling is a measure of how tightly two modules are bound
to each other.
i
Coupling between modules in a software system
must be minimized.
10.96
97. Another issue in modularity is cohesion. Cohesion is a
measure of how closely the modules in a system are related.
We need to have maximum possible cohesion between
modules in a software system.
i
Cohesion between modules in a software system
must be maximized.
10.97
98. Object-oriented design
In object-oriented design the design phase continues by
elaborating the details of classes. As we mentioned in
Chapter 9, a class is made of a set of variables (attributes)
and a set of methods. The object-oriented design phase lists
details of these attributes and methods. Figure 10.9 shows an
example of the details of our four classes used in the design
of the old-style elevator.
Figure 10.9 An example of classes with attributes and methods
10.98