UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN

❖ Usage Scenarios:
➢ As requirements are gathered, an overall vision of system functions and features begins to materialize.
However, it is difficult to move into more technical software engineering activities until you understand
how these functions and features will be used by different classes of end users. To accomplish this,
developers and users can create a set of scenarios often called use cases, which provide a description of how
the system will be used.

• Developing Use Cases:

✓ The first step in writing a use case is to define the set of “actors” that will be involved in the story.
Actors are the different people (or devices) that use the system or product within the context of the
function and behavior that is to be described. Actors represent the roles that people (or devices) play as
the system operates. Defined somewhat more formally, an actor is anything that communicates with the
system or product and that is external to the system itself. Every actor has one or more goals when using
the system. It is important to note that an actor and an end user are not necessarily the same thing.

✓ Because requirements elicitation is an evolutionary activity, not all actors are identified during the first
iteration. It is possible to identify primary actors during the first iteration and secondary actors as more
is learned about the system. Primary actors interact to achieve required system function and derive the
intended benefit from the system. They work directly and frequently with the software. Secondary actors
support the system so that primary actors can do their work.

✓ The basic use case presents a high-level story that describes the interaction between the actor and the
system.

➢ In many instances, uses cases are further elaborated to provide considerably more detail about the
interaction. For example, Cockburn suggests the following template for detailed descriptions of use cases:

• Safe Home System: The home security function would protect against and/or recognize a variety of
undesirable “situations” such as illegal entry, fire, flooding, carbon monoxide levels, and others. It’ll use
our wireless sensors to detect each situation. It can be programmed by the homeowner, and will
automatically telephone a monitoring agency when a situation is detected.

Use case template for initiating Monitoring in Safe Home System is as below:

Use case: Initiate Monitoring

Primary actor: Homeowner.

Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains
inside.

Preconditions: System has been programmed for a password and to recognize various sensors.

Trigger: The homeowner decides to “set” the system, i.e., to turn on the alarm functions.

Scenario:

1) Homeowner: observes control panel

2) Homeowner: enters password

3) Homeowner: selects “stay” or “away”

4) Homeowner: observes read alarm light to indicate that Safe Home has been armed

Page | 1
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
Exceptions:

1) Control panel is not ready: homeowner checks all sensors to determine which are open; closes
them.

2) Password is incorrect (control panel beeps once): homeowner reenters correct password.

3) Password not recognized: monitoring and response subsystem must be contacted to reprogram
password.

4) Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated.

5) Away is selected: control panel beeps three times and an away light is lit; all sensors are activated.

Priority: Essential, must be implemented

When available: First increment

Frequency of use: Many times per day

Channel to actor: Via control panel interface

Secondary actors: Support technician, sensors

Channels to secondary actors: Support technician: phone line Sensors: hardwired and radio frequency
interfaces

Open issues:

1) Should there be a way to activate the system without the use of a password or with an abbreviated
password?

2) Should the control panel display additional text messages?

3) How much time does the homeowner have to enter the password from the time the first key is
pressed?

4) Is there a way to deactivate the system before it actually activates?

❖ Use-Case Diagrams:
➢ To model a system the most important aspect is to capture the dynamic behaviour. To clarify a bit in details,
dynamic behaviour means the behaviour of the system when it is running /operating. So only static
behaviour is not sufficient to model a system rather dynamic behaviour is more important than static
behaviour.

➢ So in brief, the purposes of use case diagrams can be as follows:

✓ Used to gather requirements of a system.

✓ Used to get an outside view of a system.
✓ Identify external and internal factors influencing the system.
✓ Show the interacting among the requirements are actors.

Page | 2
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
➢ There are five relationships in a use-case diagram:

1. Association between an actor and a 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.

Figure.1 Association Relationship

2. Generalization of an Actor :

➢ Generalization of an actor means that one actor can inherit the role of another actor. The descendant inherits
all the use cases of the ancestor. The descendants have one or more use cases that are specific to that role.
Lets expand the previous use case diagram to show the generalization of an actor.

Figure.2 Generalization Relationship

3. Extend Relationship Between Two Use Cases:

➢ Many people confuse the extend relationship in use cases. As the name implies it extends the base use case
and adds more functionality to the system. Here are few things to consider when using the <<extend>>
relationship.

➢ The extending use case is dependent on the extended (base) use case. In the below diagram the “Calculate
Bonus” use case doesn’t make much sense without the “Deposit Funds” use case.

➢ The extending use case is usually optional and can be triggered conditionally. In the diagram you can see
that the extending use case is triggered only for deposits over 10,000 or when the age is over 55.

➢ The extended (base) use case must be meaningful on its own. This means it should be independent and must

Page | 3
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
not rely on the behavior of the extending use case.

➢ Lets expand our current example to show the <<extend>> relationship.

Figure.3 Extends Relationship

4. Include Relationship Between Two Use Cases:

➢ Include relationship show that the behavior of the included use case is part of the including (base) use case.
The main reason for this is to reuse the common actions across multiple use cases. In some situations this is
done to simplify complex behaviors. Few things to consider when using the <<include>> relationship.

➢ The base use case is incomplete without the included use case. The included use case is mandatory and not
optional.

➢ Lest expand our banking system use case diagram to show include relationships as well.

Figure.4 Include Relationship

Page | 4
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
5. Generalization of a Use Case:

➢ This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant.
This is used when there are common behavior between two use cases and also specialized behavior specific
to each use case.

➢ For example in the previous banking example there might be a use case called “Pay Bills”. This can be
generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

❖ Examples of Use-Case diagrams

1) Hospital Management System

2) University Course Registration System

Page | 5
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
3) ATM System

4) Library Management System

Page | 6
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
5) Hotel Management System

❖ Activity Diagram :
➢ The UML activity diagram supplements the use case by providing a graphical representation of the flow of
interaction within a specific scenario.

Activity Diagram Symbols' Meaning

The start symbol represents the beginning of a
process or workflow in an activity diagram. It can be
used by itself or with a note symbol that explains the
starting point.

The activity symbol is the main component of an

activity diagram. These shapes indicate the activities
that make up a modeled process.

The connector symbol is represented by arrowed lines

that show the directional flow, or control flow, of the
activity. An incoming arrow starts a step of an
activity; once the step is completed, the flow
continues with the outgoing arrow.

The join symbol, or synchronization bar, is a thick

vertical or horizontal line. It combines two concurrent
activities and re-introduces them to a flow where only
one activity occurs at a time.

Page | 7
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
A fork is symbolized with multiple arrowed lines
from a join. It splits a single activity flow into two
concurrent activities.

The decision symbol is a diamond shape; it represents

the branching or merging of various flows with the
symbol acting as a frame or container.

This indicates End of a process. Usually unsuccessful

end

This indicates end of all Processes successfully

➢ Activity Diagram does not show any message flow from one activity to another. Activity diagram is some
time considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.

➢ So the purposes can be described as:

✓ Draw the activity flow of a system.

✓ Describe the sequence from one activity to another.
✓ Describe the parallel, branched and concurrent flow of the system.

❖ Examples of Activity diagram are as follows:

1) Airport Check-in

Page | 8
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
2) Online Course Registration

❖ Class Based Modeling:

➢ Class-based modeling represents the objects that the system will manipulate, the operations (also called
methods or services) that will be applied to the objects to effect the manipulation, relationships (some
hierarchical) between the objects, and the collaborations that occur between the classes that are defined. The
elements of a class- based model include classes and objects, attributes, operations, class responsibility-
Collaborator (CRC) models, collaboration diagrams, and packages.

➢ Analysis classes manifest themselves in one of the following ways:

✓ External entities (e.g., other systems, devices, people) that produce or consume information to be used
by a computer-based system.
✓ Things (e.g., reports, displays, letters, signals) that are part of the information domain for the problem.
✓ Occurrences or events (e.g., a property transfer or the completion of a series sof robot movements) that
occur within the context of system operation.
✓ Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
✓ Organizational units (e.g., division, group, team) that are relevant to an application.
✓ Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the
overall function of the system.

Page | 9
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
✓ Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related
classes of objects.

➢ Coad and Yourdon suggest six selection characteristics that should be used as you consider each potential
class for inclusion in the analysis model:

1. Retained information. The potential class will be useful during analysis only if information about it
must be remembered so that the system can function.
2. Needed services. The potential class must have a set of identifiable operations that can change the value
of its attributes in some way.
3. Multiple attributes. During requirement analysis, the focus should be on “major” information; a class
with a single attribute may, in fact, be useful during design, but is probably better represented as an
attribute of another class during the analysis activity.
4. Common attributes. A set of attributes can be defined for the potential class and these attributes apply to
all instances of the class.
5. Common operations. A set of operations can be defined for the potential class and these operations
apply to all instances of the class.
6. Essential requirements. External entities that appear in the problem space and produce or consume
information essential to the operation of any solution for the system will almost always be defined as
classes in the requirements model.

Example of Identifying Potential classes of Safe Home System is given below:

➢ The class diagram shows the building blocks of any object-orientated system. Class diagrams depict a static
view of the model, or part of the model, describing what attributes and behavior it has rather than detailing
the methods for achieving operations. Class diagrams are most useful in illustrating relationships between
classes and interfaces. Generalizations, aggregations, and associations are all valuable in reflecting
inheritance, composition or usage, and connections respectively.

• Classes

➢ A class is an element that defines the attributes and behaviors that an object is able to generate. The
behavior is described by the possible messages the class is able to understand, along with operations that are
appropriate for each message. Classes may also have definitions of constraints, tagged values and
stereotypes.

Page | 10
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
• Class Notation

➢ Classes are represented by rectangles which show the name of the class and optionally the name of the
operations and attributes. Compartments are used to divide the class name, attributes and operations.

➢ In the diagram below the class contains the class name in the topmost compartment, the next compartment
details the attributes, with the "center" attribute showing initial values. The final compartment shows the
operations set Width, set Length and set Position and their parameters. The notation that precedes the
attribute, or operation name, indicates the visibility of the element: if the + symbol is used, the attribute, or
operation, has a public level of visibility; if a - symbol is used, the attribute, or operation, is private. In
addition the # symbol allows an operation, or attribute, to be defined as protected, while the ~ symbol
indicates package visibility.

• Interfaces
➢ An interface is a specification of behavior that implementers agree to meet; it is a contract. By realizing an
interface, classes are guaranteed to support a required behavior, which allows the system to treat non-related
elements in the same way – that is, through the common interface.

• Associations
➢ An association implies two model elements have a relationship - usually implemented as an instance
variable in one class. This connector may include named roles at each end, cardinality, direction and
constraints. Association is the general relationship type between elements. For more than two elements, a
diamond representation toolbox element can be used as well. When code is generated for class diagrams,
named association ends become instance variables in the target class. So, for the example below, "playsFor"
will become an instance variable in the "Player" class.

Page | 11
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
• Generalizations

➢ A generalization is used to indicate inheritance. Drawn from the specific classifier to a general classifier, the
generalize implication is that the source inherits the target's characteristics. The following diagram shows a
parent class generalizing a child class. Implicitly, an instantiated object of the Circle class will have
attributes x_position, y_position and radius and a method display ( ). Note that the class "Shape" is abstract,
shown by the name being italicized.

• Aggregations

➢ Aggregations are used to depict elements which are made up of smaller components. Aggregation
relationships are shown by a white diamond-shaped arrowhead pointing towards the target or parent class.

➢ A stronger form of aggregation - a composite aggregation - is shown by a black diamond-shaped arrowhead

and is used where components can be included in a maximum of one composition at a time. If the parent of
a composite aggregation is deleted, usually all of its parts are deleted with it; however a part can be
individually removed from a composition without having to delete the entire composition.

➢ Compositions are transitive, asymmetric relationships and can be recursive.

➢ The following diagram illustrates the difference between weak and strong aggregations. An address book is
made up of a multiplicity of contacts and contact groups. A contact group is a virtual grouping of contacts; a
contact may be included in more than one contact group. If you delete an address book, all the contacts and
contact groups will be deleted too; if you delete a contact group, no contacts will be deleted.

• Dependency

➢ It is often confused as Association. Dependency is normally created when you receive a reference to a class
as part of a particular operation / method. Dependency indicates that you may invoke one of the APIs of the
received class reference and any modification to that class may break your class as well. Dependency is
represented by a dashed arrow starting from the dependent class to its dependency. Multiplicity normally

Page | 12
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
doesn’t make sense on a Dependency.

❖ Examples of class Diagram

1) Address book Management

2) Order System

Page | 13
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
3) Company Reporting system

❖ Creating a Behavioral Model

➢ The behavioral model indicates how software will respond to external events or stimuli. To create the
model, you should perform the following steps:

1. Evaluate all use cases to fully understand the sequence of interaction within the system.
2. Identify events that drive the interaction sequence and understand how these events relate to
specific objects.
3. Create a sequence for each use case.
4. Build a state diagram for the system.
5. Review the behavioral model to verify accuracy and consistency.

❖ State Diagram:
➢ Using a state machine one can model the behavior of an individual object. It specifies the sequence of states
of an object response to a message. A State diagram shows how an object will react to the arrival of an
event.
➢ An event represents the receipt of a signal or the effect of an operation call.
➢ An action represents the sending of a signal, or the call of an operation
➢ Two basic elements are there.
(1) Rounded rectangle represents the state.
Name

(2) Labeled arrow indicates the transition

Event [guard condition] [/Action]
✓ Here, event is the message that is sent
✓ guard condition is the Boolean expression of attribute values that allows a state transition only if the

Page | 14
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
condition is true
✓ An action is the behavior that occurs when the state transition occurs

❖ Examples of State diagram:

1) Order Placement

Page | 15
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
2) Course Registration

Within
deadline
Propose
Course offer

Course open
Schedule
for
registration
Dispaly Last date
Course
assigned Enroll Withdraw

Full Close course

Course full

Student dropped
Vaccancy exist

Session started
Course being
taught

Feedback
Display
marks

3) Microwave oven

Page | 16
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
4) Control panel of Safe Home System

❖ Sequence Diagram :
➢ A sequence diagram shows object interactions arranged in time sequence. It depicts the object and classes
involved in the scenario and the sequence of messages exchanged between the objects needed to carry out
the functionality of the scenario. Typically, a sequence diagram captures the behaviour of a single activity
or a use case.

➢ A sequence diagram is a two dimensional chart. The chart is read from top to bottom. The objects
participating in the interaction are shown at the top of the chart as boxes attached to a vertical-dashed line.

➢ Inside the box the name of the object is written with a colon separating it from the name of the class and
both the name of the class and object are underlined. Sometimes an anonymous object (only class name and
underlined) is also used.

Page | 17
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN

➢ The objects appearing at the top signifying that the object already existed when the use case execution was
executed.

➢ However, if some object is created during the execution of the use case and participates in the interaction,
then that object should be shown at the appropriate place on the diagram where it was created

➢ The vertical dashed line in the sequence diagram is called the object’s life time. The life time indicates the
existence of the object at any particular point of time. A rectangle is used on the life time to indicate the
activation symbol and implies that the object is active as long as the rectangle exists.

Page | 18
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
➢ Messages in Sequence diagram: Two objects in a sequence diagram interacts with passing messages
between them. Each message is indicated as an arrow between the lifelines of two objects. The order of
message is very important in the sequence diagram. They should appear in chronological order from top to
the bottom. That is, reading the diagram from the top of the bottom would show the sequence in which the
message occurs. Each message is labeled with the message name diagram.

➢ Messages can be synchronous or asynchronous: Synchronous Message waits until the receiver has
finished processing. Whereas Asynchronous message can send another message immediately.

➢ Messages can be lost or found. Lost messages are those that are either sent but do not arrive at the
intended recipient, or which go to a recipient not shown on the current diagram. Found messages are those
that arrive from an unknown sender, or from a sender not shown on the current diagram. They are denoted
going to or coming from an endpoint element.

Page | 19
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN

➢ A self-message can represent a recursive call of an operation, or one method calling another method
belonging to the same object. It is shown as creating a nested focus of control in the lifeline’s execution
occurrence.

➢ Some control information can also be included:

Two types of control information are particularly known:

1) A condition (e.g. [vacant = true]) indicates that a message is sent, only if the condition is true.

2) An iteration marker (*) is used to indicate that the message is to be repeated many times to multiple
receiver objects (e.g. when it is required to iterate over a collection or an array of elements).

Page | 20
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN

➢ Instantaneous and Non-instantaneous Message: By default, a message is shown as a horizontal line

which means instantaneous message (It takes negligible time to reach to the receiver). Since the lifeline
represents the passage of time down the screen, when modeling a real-time system, or even a time-bound
business process, it can be important to consider the length of time it takes to perform actions. By setting a
duration constraint for a message, the message will be shown as a sloping line known as non-instantaneous
message.

Page | 21
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
➢ Opt Fragment:

If you want to show that several messages are conditionally sent under the same guard, you'll have to use an
'opt' combined fragment. The combined fragment is shown as a large rectangle with an 'opt' operator plus a
guard, and contains all the conditional messages under that guard.

➢ Alt Fragment:

If you want to show several alternative interactions, use an 'alt' combined fragment. The combined fragment
contains an operand for each alternative. Each alternative has a guard and contains the interaction that
occurs when the condition for that guard is met.

Page | 22
 UNIT 5: OBJECT ORIENTED ANALYSIS AND DESIGN
❖ Examples of Sequence Diagrams:
1) Atm Pin Validation

2) Processing Order

Page | 23