Subject Name: Object Oriented Analysis and Design

Subject Code: IT-7002

Semester: 7th
Downloaded from be.rgpvnotes.in

UNIT-V

Unified Modeling Language (UML):

Unified Modeling language (UML) is a standardized modeling language enabling developers to specify,
visualize, construct and document artifacts of a software system. Thus, UML makes these artifacts scalable,
secure and robust in execution. UML is an important aspect involved in object-oriented software
development.
UML diagrams
Class Diagram-A class diagram models the static view of a system. It comprises of the classes, interfaces,
and collaborations of a system; and the relationships between them.
Component Diagram-Collaboration diagrams are interaction diagrams that illustrate the structure of the
objects that send and receive messages.
Deployment Diagram-A deployment diagram puts emphasis on the configuration of runtime processing
nodes and their components that live on them. They are commonly comprised of nodes and dependencies,
or associations between the nodes.
Object Diagram-An object diagram models a group of objects and their links at a point of time. It shows the
instances of the things in a class diagram. Object diagram is the static part of an interaction diagram.
Interaction Overview Diagram-Interaction diagrams depicts interactions of objects and their relationships.
They also include the messages passed between them
Sequence Diagram-Sequence diagrams are interaction diagrams that illustrate the ordering of messages
according to time
Use case Diagram-Use case diagrams present an outside view of the manner the elements in a system
behave and how they can be used in the context
Activity Diagram- Activity diagrams is graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams are intended to model both computational and organizational processes (i.e. workflows). Activity
diagrams show the overall flow of control.
Activity diagrams are constructed from a limited number of shapes, connected with arrows.
The most important shape types: rounded rectangles represent actions; diamonds represent decisions;
bars represent the start (split) or end (join) of concurrent activities; a black circle represents the start
(initial state) of the workflow; an encircled black circle represents the end (final state).Arrows run from the
start towards the end and represent the order in which activities happen. Activity diagrams may be
regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing concurrency
[citation needed. However, the join and split symbols inactivity diagrams only resolve this for simple cases;
the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.UML
activity diagrams in version 2.x can be used in various domains, i.e. in design of embedded systems. It is
possible to verify such a specification using model checking technique.

Page no: 1 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 5.1: Activity Diagram

USECASE MODELING:
The Use Case Model describes the proposed functionality of the new system. A Use Case represents a
discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit
of meaningful work; for example login to system, register with system and create order are all Use Cases.
Each Use Case has a description which describes the functionality that will be built in the proposed system.
A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own
behavior. Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts
with the system to perform meaningful work.

Actors
An Actor is a user of the system. This includes both human users and other computer systems. An Actor
uses a Use Case to perform some piece of work which is of value to the business.
The set of Use Cases an actor has access to define their overall role in the system and the scope of their
action, Constraints, Requirements and Scenarios.
The formal specification of a Use Case includes:

Requirements:
These are the formal functional requirements that a Use Case must provide to the end user. They
correspond to the functional specifications found in structured methodologies. These are the formal rules
and limitations that a Use Case operates under, and includes pre post and invariant conditions. A pre-
condition specifies what must have already occurred or be in place before the Use Case may start. A post-
condition documents what will be true once the Use Case is complete. An invariant specifies what will be
true throughout the time the Use Case operates.

Scenarios:
Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance. These are
usually described in text and correspond to a textual representation of the Sequence Diagram.
USE CASE RELATIONSHIPS.
Use case relationships is divided into three types
1. Include relationship
2. Extend relationship

Page no: 2 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

3. Generalization

1. Include relationship:
It is common to have some practical behavior that is common across several use cases.It is simply to
underline it or highlight it in some fashion
Example: Paying by credit: Include Handle Credit Payment

2. Extend relationship:
Extending the use case or adding new use case to the process Extending use case is triggered by some
conditions called extension point.

3. Generalization:
Complicated work and unproductive time is spending in this use case relationship. Use case experts are
successfully doing use case work without this relationship.
Includes and Extends relationships between Use Cases. One Use Case may include the functionality of
another as part of its normal processing. Generally, it is assumed that the included Use Case will be called
every time the basic path is run. An example may be to list a set of customer orders to choose from before
modifying a selected order in this case the <list orders> Use Case may be included every time the <modify
order>Use Case is run. A Use Case may be included by one or more Use Cases, so it helps to reduce
duplication of functionality by factoring out common behavior into Use Cases that are re-used many times.
One Use Case may extend the behavior of another - typically when exceptional circumstances are
encountered.
Generalization between Use Cases, Generalization between use cases is similar to generalization between
classes; child use case inherits properties and behavior of the parent use case and may override the
behavior of the parent.

NOTATION:
Generalization is rendered as a solid directed line with a large open arrowhead (same as generalization
between classes).Generalization between use cases, Association between Use Cases
Use cases can only be involved in binary Associations. Two use cases specifying the same subjectcannotbe
associated since each of them individually describes a complete usage of the system.

Extend Relationship
Extend is a directed relationship from an extending use case to an extended use case that specifies how
and when the behavior defined in usually supplementary (optional) extending use case can be inserted into
the behavior defined in the use case to be extended. The extension takes place at one or more extension
points defined in the extended use case. The extend relationship is owned by the extending use case. The
same extending use case can extend more than one use case, and extending use case may itself be
extended.
Extend relationship between uses cases is shown by a dashed arrow with an open arrowhead from the
extending use case to the extended (base) use case. The arrow is labeled with the keyword Registration
use case is meaningful on its own, and it could be extended with optional Get Help on Registration use
case. The condition of the extend relationship as well as the references to the extension points are
optionally shown in a Note attached to the corresponding extend relationship. Registration use case is
conditionally extended by Get Help on Registration use case in extension point Registration Help

Include Relationship
An include relationship is a directed relationship between two use cases, implying that the behavior of the
required (not optional) included use case is inserted into the behavior of the including (base) use case.
Including use case depends on the addition of the included use case. They include relationship is intended
to be used when there are common parts of the behavior of two or more use cases. This common part is
extracted into a separate use case to be included by all because cases having this part in common. As the

Page no: 3 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

primary use of the include relationship is to reuse common parts, including use cases are usually not
complete by themselves but dependent on the included use cases. Include relationship between uses cases
is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included
(common part) use case. The arrow is labeled with the keyword «include».

CLASS DIAGRAM:
The class diagram is the main building block of object oriented modeling. It is used both for General
conceptual modeling of the systematic of the application, and for detailed modeling Translating the models
into programming code. Class diagrams can also be used for data modeling.
The classes in a class diagram represent both the main objects, interactions in the application and the
classes to be programmed. The top part contains the name of the class. It is printed in bold and centered,
and the first letter is capitalized. The middle part contains the attributes of the class. They are left-aligned
and the first letter is lowercase. The bottom part contains the methods the class can execute. They are also
left-aligned and the first letter is lowercase. In the design of a system, a number of classes are identified
and grouped together in a class diagram which helps to determine the static relations between those
objects. With detailed modeling, the classes of the conceptual design are often split into a number of
subclasses.

Links
A Link is the basic relationship among objects.

Association
An association represents a family of links. A binary association (with two ends) is normally represented as
a line. An association can link any number of classes. An association with three links is called a ternary
association. An association can be named, and the ends of an association can be adorned with role names,
ownership indicators, multiplicity, visibility, and other properties.
There are four different types of association: bi-directional, unidirectional, Aggregation(includes
Composition aggregation) and Reflexive. Bi-directional and unidirectional associations are the most
common ones. For instance, a flight class is associated with a plane class bidirectional.
Association represents the static relationship shared among the objects of two classes.

Aggregation
Aggregation is a variant of the "has a" association relationship; aggregation is more specific than
association. It is an association that represents a part-whole or part-of relationship. As shown in the image,
a Professor 'has a' class to teach. As a type of association, an aggregation can be named and have the same
adornments that an association can. However, an aggregation may not involve more than two classes; it
must be a binary association.
Aggregation can occur when a class is a collection or container of other classes, but the contained classes
do not have a strong lifecycle dependency on the container. The contents of the container are not
automatically destroyed when the container is.
In UML, it is graphically represented as a hollow diamond shape on the containing class with a single line
that connects it to the contained class. The aggregate is semantically an extended object that is treated as
a unit in many operations, although physically it is made of several lesser objects.

INTERACTION DIAGRAMS:
Interaction Overview Diagram is one of the thirteen types of diagrams of the Unified Modeling Language
(UML), which can picture a control flow with nodes that can contain interaction diagrams. The interaction
overview diagram is similar to the activity diagram, in that both visualize a sequence of activities. The
difference is that, for an interaction overview, each individual activity is pictured as a frame which can
contain a nested interaction diagrams. This makes the interaction overview diagram useful to "deconstruct
a complex scenario that would otherwise require multiple if-then else paths to be illustrated as a single
sequence diag a . The other notation elements for interaction overview diagrams are the same as for

Page no: 4 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

activity diagrams. These include initial, final, decision, merge, fork and join nodes. The two new elements
in the interaction overview diagrams are the "interaction occurrences" and "interaction elements."

Figure 5.2: Interaction Diagram

STATE DIAGRAMS:
The state diagram in the Unified Modeling Language is essentially a Hare state chart with standardized
notation which can describe many systems, from computer programs to business processes.
In UML 2 the name has been changed to State Machine Diagram. The following are the basic notational
elements that can be used to make up a diagram:
Filled circle, representing to the initial state, hollow circle containing a smaller filled circle, indicating the
final state (if any)and Rounded rectangle, denoting a state. Top of the rectangle contains a name of the
state. Can contain a horizontal line in the middle, below which the activities that are done in that state are
Indicated Arrow, denoting transition. The name of the event (if any) causes this transition labels the arrow
body. A guard expression may be added before a "/" and enclosed in square-brackets (event Name [guard
Expression]), denoting that this expression must be true for the transition to take place. If an action is
Performed during this transition, it is added to the label following a "/" (event Name [guard
Expression]/action).
Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines
leaving. These denote join/fork, respectively.

PACKAGE, COMPONENT AND DEPLOYMENT DIAGRAMS:

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on
nodes. To describe a web site, for example, a deployment diagram would show what hardware
components ("nodes") exist (e.g., a web server, an application server, and a database server), what
software components ("artifacts") run on each node (e.g., web application, database), and how the
different pieces are connected (e.g. JDBC, REST, RMI).The nodes appear as boxes, and the artifacts
allocated to each node appear as rectangles within the boxes. Nodes may have sub nodes, which appear as
nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes,
such as a cluster of database servers.
Execution Environment Node Device nodes are physical computing resources with processing memory and
services to execute software, such as typical computers or mobile phones. An execution environment node
(EEN) is a software computing resource that runs within an outer node and which itself provides a service
to host and execute other executable software elements.

High Cohesion

Page no: 5 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable
and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that
the responsibilities of a given element are strongly related and highly focused. Breaking programs into
classes and subsystems is an example of activities that increase the cohesive properties of a system.
Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities.
Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain
and averse to change. The Indirection pattern supports low coupling (and reuse potential) between two
elements by assigning the responsibility of mediation between them to an intermediate object. An
example of this is the introduction of a controller component for mediation between data (model) and its
representation (view) in the Model-view-controller pattern.

Information Expert
Information Expert (also Expert or the Expert Principle) is a principle used to determine where to delegate
responsibilities. These responsibilities include methods, computed fields, and soon. Using the principle of
Information Expert, a general approach to assigning responsibilities is to look at a given responsibility,
determine the information needed to fulfill it, and then determine where that information is stored.
Information Expert will lead to placing the responsibility on the class with the most information required to
fulfill it. Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:
lower dependency between the classes, change in one class having lower impact on other classes, higher
reuse potential.

Polymorphism
According to Polymorphism, responsibility of defining the variation of behaviors based on type is assigned
to the types for which this variation happens. This is achieved using polymorphicoperations.The Protected
Variations pattern protects elements from the variations on other elements (objects, systems, subsystems)
by wrapping the focus of instability with an interface and using polymorphism to create various
implementations of this interface. A Pure Fabrication is a class that does not represent a concept in the
problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential
thereof derived (when a solution presented by the Information Expert pattern does not). This kind of class
is alled “e i e" in Domain-driven design.
Information expert
Name: Information Expert
Problem: What is a general principle of assigning responsibility to objects?
Solution: Assign a responsibility to the class that has the information needed to fulfill it
Example
In the NextGen application, some class needs to know the grand total of a sale Discussion
•I fo atio E pe t is f e ue tl used i the assig e t of espo si ilities; it is a asi guiding principles
used continuously in object design.
•The fulfill e t of a espo si ilit ofte e ui es i fo atio sp ead a oss diffe e t lassesofo je ts.
• E pe t usuall leads to desig s he e a soft a e o je t does those ope atio s that a e normally done to
the inanimate real
-world thing it represents.
•The I fo atio E pe t patte
–like many things in Object Oriented
– has a real
- World analogy.
• The e a e situatio s he e a solutio suggested E pe t is u desi a le, usuall e ause of problems in
coupling and cohesion

LOW COUPLING:
Name: Low Coupling
Problem: How to support low dependency, low change impact, and increased reuse?

Page no: 6 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Solution: Assign a responsibility so that coupling remains low

Example
Assume a need to create a Payment instance and associate it with the Sale, who should be responsible for
this?
Discussion
• Lo Coupli g is a p i iple to keep i i d du i g all desig de isio s; it is a u de l i g goal to
continually consider.
• Although, i ge e al, a lo oupli g is p efe ed, it should ’t e take to e ess. “o e moderate degree
of coupling between classes is normal and necessary to create an OO system in which tasks are fulfilled
by collaboration between connected objects Contradictions High coupling to stable elements and to
pervasive elements is seldom a problem.
Ex. a Java application can safely couple itself to the Java libraries (java.util, and so on) because they are
stable and widespread

Benefits
• Not affected by changes in other components
• Simple to understand in isolation
• Convenient to reuse

Choices:
– Rep ese ts the o e all s ste , a de i e, o a su s ste façade o t olle
– Represents a use case scenario (use case controller）
• Co t olle is none
- User interface object responsible for receiving or handling a system event.
• A o t olle defi es the ethod fo the s ste ope atio s System Discussion
• “ ste s e ei e e te all i put e e ts, t pi all i ol i g a GUI ope ated a pe so .
• I all ases, some handler for these events must be chosen
• The Co t olle patte p o ides guida e fo ge e all a epted, suita le hoi es.
• No all , a o t olle should delegate to othe o je ts the o k that eeds to e do e; it coordinates or
controls the acti it . It does ’t do u h o k itself.

SIGNIFICANCE:
• I eased pote tial fo euse a d plugga le i te fa es
• Oppo tu it to easo a out the state of the use ase I ple e tatio
• I ple e tatio Ja a “ i g: Ri h Clie t UI
• I ple e tatio ith Ja a Struts: Client Browser and Web UI Issues and Solutions: Bloated
Controllers
• Poo l desig ed, a o t olle ill ha e lo ohesio
– Unfocused and handling too many areas of responsibility
• “ig s of loati g
GRASP – HIGH COHESION
• Co ept – Cohesion:
– Cohesio is a easu e of elated ess .
– High Cohesion says elements are strongly related to one another.
– Low Cohesion says elements are not strongly related to one another. Ex:
• “ ste le el: ATM ith a use ase fu tio alled Telle Repo ts .
• Class le el: A “tude t lass ith a ethod alled get Driving Record ().
• Method le el: Methods ith the o d A d o O i the .
• Also applies to subsystem (package) level, component level, etc. Designs with low cohesion are
www.studentsfocus, difficult to maintain and reuse.
– One of the fundamental goals of an effective design is to achieve high cohesion with low coupling (which
we will see later) Problem: How do you keep complexity manageable?

Page no: 7 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

•“olutio : Assign responsibility so that cohesion remains high.

• Me ha i s: Look fo lasses ith too-few or disconnected methods. Look for methods that do too much
(hint: method name) Rework your design as needed

STRUCTURAL BRIDGE:
The bridge pattern is a design pattern used in software engineering which is meant to de ouple an
abstraction from its implementation so that the two can vary independently". The bridge uses
encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.
When a class varies often, the features of object-oriented programming become very useful because
changes to a program's code can be made easily with minimal prior knowledge about the program. The
bridge pattern is useful when both the class and what it does very often. The class itself can be thought of
as the implementation and what the class can do as the abstraction. The bridge pattern can also be
thought of as two layers of abstraction. When there is only one fixed implementation, this pattern is
known as the Pimple idiom in the C++world. The bridge pattern is often confused with the adapter pattern.
In fact, the bridge pattern is often implemented using the class adapter pattern, e.g. in the Java code
below. Variant: The implementation can be decoupled even more by deferring the presence of the
implementation to the point where the abstraction is utilized.

Figure 5.3: Abstraction

Abstraction (abstract class) defines the abstract interface maintains the Implement reference. Refined
Abstraction (normal class) extends the interface defined by Abstraction Implementer (interface) defines
the interface for implementation classes Concrete Implementer (normal class) implements the
Implementer interface

ADAPTER and STRUCTURE:

Intent Convert the interface of a class into another interface clients expect. Adapter lets classes work
together that couldn't otherwise because of incompatible interfaces. Wrap an existing class with a new
interface. Impedance match an old component to a new system Problem An "off the shelf" component
offers compelling functionality that you would like to reuse, but its "view of the world" is not compatible
with the philosophy and architecture of the system currently being developed. Structure category: wrapper
Similar patterns: Facade Proxy Discussion reuse has always been painful and elusive. One reason has been
the tribulation of designing something new, while reusing something old. There is always something not
quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing
or synchronization. It may be unfortunate assumptions or competing standards. It is very similar to the
electrical engineering activity of "impedance matching" – adapting the input resistance, inductance, and
capacitance of a load to match the output impedance of a source.

STRUCTURE:

Page no: 8 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Below, a legacy Rectangle component's display () method expects to receive "x, y, w, h"parameters. But
the client wants to pass "upper left x and y" and "lower right x and y". This incongruity can be reconciled by
adding an additional level of indirection – i.e. an Adapter object.

BEHAVIORAL – STRATEGY:
A generic value of the software community for years has been, "maximize cohesion and minimize
coupling". The object-oriented design approach is all about minimizing coupling. Since the client is coupled
only to an abstraction (i.e. a useful fiction), and not a particular realization of that abstraction, the client
could be said to be practicing "abstract coupling" .an object-oriented variant of the more generic
exhortation "minimize coupling".

CLASS DIAGRAM
A class diagram models the static view of a system. It comprises of the classes, interfaces, and
collaborations of a system; and the relationships between them.

Class Diagram of a System

Figure 5.4: Class Diagram

Let us consider a simplified Banking System. A bank has many branches. In each zone, one branch is
designated as the zonal head office that supervises the other branches in that zone. Each branch can have
multiple accounts and loans. An account may be either a savings account or a current account. A customer
may open both a savings account and a current account. However, a customer must not have more than
one savings account or current account. A customer may also procure loans from the bank.
The following figure shows the corresponding class diagram.
Classes in the system:
Bank, Branch, Account, Savings Account, Current Account, Loan, and Customer

Page no: 9 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Relationships:
 A Ba k has–a u er of Bra hes : composition, one–to–many
 A Branch with role Zonal Head Office supervises other Branches : unary association, one–to-many
 A Bra h has–a u er of a ou ts : aggregation, one–to–many
From the class Account, two classes have inherited, namely, Savings Account and Current Account.
 A Customer can have one Current Account : association, one–to–one
 A Customer can have one Savings Account : association, one–to–one
 A Bra h has–a u er of Loa s : aggregation, one–to–many
 A Customer can take many loans : association, one–to–many

OBJECT DIAGRAM

Figure 5.5: Object Diagram

An object diagram models a group of objects and their links at a point of time. It shows the instances of
the things in a class diagram. Object diagram is the static part of an interaction diagram. Example: The
following figure shows an object diagram of a portion of the class diagram of the Banking System.

COMPONENT DIAGRAM
Component diagrams show the organization and dependencies among a group of components.
Component diagrams comprise of:
 Components
 Interfaces
 Relationships
 Packages and Subsystems (optional)
Component diagrams are used for:
 Constructing systems through forward and reverse engineering.
 Modeling configuration management of source code files while developing a system using an object-
oriented programming language.
 Representing schemas in modeling databases.
 Modeling behaviors of dynamic systems.
Example
The follo i g figu e sho s a o po e t diag a to odel a s ste ’s sou e ode that is de eloped usi g
C++. It shows four source code files, namely, myheader.h, otherheader.h, priority.cpp, and other.cpp. Two

Page no: 10 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

versions of myheader.h are shown, tracing from the recent version to its ancestor. The file priority.cpp has
compilation dependency on other.cpp. The file other.cpp has compilation dependency on otherheader.h.

Figure 5.6: Component Diagram

DEPLOYMENT DIAGRAM
A deployment diagram puts emphasis on the configuration of runtime processing nodes and their
components that live on them. They are commonly comprised of nodes and dependencies, or associations
between the nodes.
Deployment diagrams are used to:
 Model devices in embedded systems that typically comprise of software-intensive collection of
hardware.
 Represent the topologies of client/server systems.
 Model fully distributed systems.
Example- The following figure shows the topology of a computer system that follows client/server
architecture. The figure illustrates a node stereotyped as server that comprises of processors. The figure
indicates that four or more servers are deployed at the system. Connected to the server are the client
nodes, where each node represents a terminal device such as workstation, laptop, scanner, or printer. The
nodes are represented using icons that clearly depict the real-world equivalent.

Figure 5.7: Deployment Diagram

Page no: 11 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

USE CASE MODEL

(a) Use case
A use case describes the sequence of actions a system performs yielding visible results. It shows the
interaction of things outside the system with the system itself. Use cases may be applied to the whole
system as well as a part of the system.
(b) Actor
An actor represents the roles that the users of the use cases play. An actor may be a person (e.g. Student,
customer), a device (e.g. Workstation), or another system (e.g. Bank, institution).
The following figure shows the notations of an actor named student and a use case called generate
performance report.

Figure 5.8: Use Case Model

(c) Use case diagrams
Use case diagrams present an outside view of the manner the elements in a system behave and how they
can be used in the context.
Use case diagrams comprise of:
 Use cases
 Actors
 Relationships like dependency, generalization, and association
Use case diagrams are used:
 To model the context of a system by enclosing all the activities of a system within a rectangle and
focusing on the actors outside the system by interacting with it.
 To model the requirements of a system from the outside point of view.
Example
Let us consider an automated trading house system. We assume the following features of the system:
 The trading house has transactions with two types of customers, individual customers and corporate
customers.
 Once the customer places an order, it is processed by the sales department and the customer is given
the bill.
 The system allows the manager to manage customer accounts and answer any queries posted by the
customer.

Page no: 12 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 5.9: Use Case Diagram

INTERACTION DIAGRAMS
Interaction diagrams depict interactions of objects and their relationships. They also include the messages
passed between them. There are two types of interaction diagrams:
 Sequence diagrams
 Collaboration diagrams
Interaction diagrams are used for modeling:
 The control flow by time ordering using sequence diagrams.
 The control flow of organization using collaboration diagrams.
Sequence diagrams
Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to time.
Notations: these diagrams are in the form of two-dimensional charts. The objects that initiate the
interaction are placed on the x–axis. The messages that these objects send and receive are placed along
the y–axis, in the order of increasing time from top to bottom.
Example: a sequence diagram for the automated trading house system is shown in the following figure.

Page no: 13 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Figure 5.10: Interaction Diagram

COLLABORATION DIAGRAMS
Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send and
receive messages.
Notations: in these diagrams, the objects that participate in the interaction are shown using vertices. The
links that connect the objects are used to send and receive messages. The message is shown as a labeled
arrow.
Example: collaboration diagram for the automated trading house system is illustrated in the figure below.

Figure 5.11: Collaboration Diagram

STATE–CHART DIAGRAMS
A state–chart diagram shows a state machine that depicts the control flow of an object from one state to
another. A state machine portrays the sequences of states which an object undergoes due to events and
their responses to events.

Page no: 14 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

State–chart diagrams comprise of:

 States: simple or composite
 Transitions between states
 Events causing transitions
 Actions due to the events
State-chart diagrams are used for modeling objects which are reactive in nature.
Example
In the automated trading house system, let us model order as an object and trace its sequence. The
following figure shows the corresponding state–chart diagram.

Figure 5.12: State Diagram

ACTIVITY DIAGRAMS
An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state
machine. Activities result in actions which are atomic operations.
Activity diagrams comprise of:
 Activity states and action states
 Transitions
 Objects
Activity diagrams are used for modeling:
 Workflows as viewed by actors, interacting with the system.
 Details of operations or computations using flowcharts.
Example
The following figure shows an activity diagram of a portion of the automated trading house system.

Figure 5.13: Activity Diagram

Page no: 15 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Object Mapping to Database System

Persistency of Objects
An important aspect of developing object-oriented systems is persistency of data. Through persistency,
objects have longer lifespan than the program that created it. Persistent data is saved on secondary
storage medium from where it can be reloaded when required.
Overview of RDBMS
A database is an ordered collection of related data.
A database management system (DBMS) is a collection of software that facilitates the processes of
defining, creating, storing, manipulating, retrieving, sharing, and removing data in databases.
In relational database management systems (RDBMS), data is stored as relations or tables, where each
column or field represents an attribute and each row or tuple represents a record of an instance.
Each row is uniquely identified by a chosen set of minimal attributes called primary key.
A foreign key is an attribute that is the primary key of a related table.
Representing Classes as Tables in RDBMS
To map a class to a database table, each attribute is represented as a field in the table. Either an existing
attribute(s) is assigned as a primary key or a separate ID field is added as a primary key. The class may be
partitioned horizontally or vertically as per requirement.
For example, the Circle class can be converted to table as shown in the figure below.

Figure 5.14: Class representation in RDBMS

Schema for Circle Table: CIRCLE (CID, X_COORD, Y_COORD, RADIUS, COLOR)
Creating a Table Circle using SQL command:
CREATE TABLE CIRCLE
(
CID VARCHAR2 (4) PRIMARY KEY,
X_COORD INTEGER NOT NULL,
Y_COORD INTEGER NOT NULL,
Z_COORD INTEGER NOT NULL,
COLOR
);
Mapping Associations to Database Tables
One–to–One Associations
To implement 1:1 associations, the primary key of any one table is assigned as the foreign key of the other
table. For example, consider the association between Department and Manager:

SQL commands to create the tables:

CREATE TABLE DEPARTMENT
(

Page no: 16 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

DEPT_ID INTEGER PRIMARY KEY,

DNAME VARCHAR2 (30) NOT NULL,
LOCATION VARCHAR2 (20),
EMPID INTEGER REFERENCES MANAGER
);

CREATE TABLE MANAGER

(
EMPID INTEGER PRIMARY KEY,
ENAME VARCHAR2 (50) NOT NULL,
ADDRESS VARCHAR2 (70),
);
One–to–Many Associations
To implement 1: N associations, the primary key of the table in the 1-side of the association is assigned as
the foreign key of the table at the N-side of the association. For example, consider the association
between Department and Employee:

SQL commands to create the tables:

CREATE TABLE DEPARTMENT
(
DEPT_ID INTEGER PRIMARY KEY,
DNAME VARCHAR2 (30) NOT NULL,
LOCATION VARCHAR2 (20),
);
CREATE TABLE EMPLOYEE
(
EMPID INTEGER PRIMARY KEY,
ENAME VARCHAR2 (50) NOT NULL,
ADDRESS VARCHAR2 (70),
D_ID INTEGER REFERENCES DEPARTMENT
);
Many–to–Many Associations
To implement M: N associations, a new relation is created that represents the association. For example,
consider the following association between Employee and Project:

Schema for Works_OnTable: WORKS_ON (EMPID, PID, HOURS, START_DATE)

SQL command to create Works_Onassociation: CREATE TABLE WORKS_ON
(

Page no: 17 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

EMPID INTEGER,
PID INTEGER,
HOURS INTEGER,
START_DATE DATE,
PRIMARY KEY (EMPID, PID),
FOREIGN KEY (EMPID) REFERENCES EMPLOYEE,
FOREIGN KEY (PID) REFERENCES PROJECT
);
Mapping Inheritance to Tables
To map inheritance, the primary key of the base table(s) is assigned as the primary key as well as the
foreign key in the derived table(s).
Example

Figure 5.15: Inheritance mapping into Table

Testing Object-Oriented Systems

Testing is a continuous activity during software development. In object-oriented systems, testing
encompasses three levels, namely, unit testing, subsystem testing, and system testing.
Unit Testing
In unit testing, the individual classes are tested. It is seen whether the class attributes are implemented as
per design and whether the methods and the interfaces are error-free. Unit testing is the responsibility of
the application engineer who implements the structure.
Subsystem Testing
This involves testing a particular module or a subsystem and is the responsibility of the subsystem lead. It
involves testing the associations within the subsystem as well as the interaction of the subsystem with the
outside. Subsystem tests can be used as regression tests for each newly released version of the
subsystem.
System Testing
System testing involves testing the system as a whole and is the responsibility of the quality-assurance
team. The team often uses system tests as regression tests when assembling new releases.
Object-Oriented Testing Techniques
Grey Box Testing
The different types of test cases that can be designed for testing object-oriented programs are called grey
box test cases. Some of the important types of grey box testing are:
State model based testing: This encompasses state coverage, state transition coverage, and state
transition path coverage.
Use case based testing: Each scenario in each use case is tested.
Class diagram based testing: Each class, derived class, associations, and aggregations are tested.
Sequence diagram based testing: The methods in the messages in the sequence diagrams are tested.
Techniques for Subsystem Testing
The two main approaches of subsystem testing are:

Page no: 18 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Thread based testing: All classes that are needed to realize a single use case in a subsystem are integrated
and tested.
Use based testing: The interfaces and services of the modules at each level of hierarchy are tested. Testing
starts from the individual classes to the small modules comprising of classes, gradually to larger modules,
and finally all the major subsystems.
Categories of System Testing
Alpha testing: This is carried out by the testing team within the organization that develops software.
Beta testing: This is carried out by select group of co-operating customers
Acceptance testing: This is carried out by the customer before accepting the deliverables.
Software Quality Assurance
Software Quality
“ hul e e a d M Ma us ha e defi ed soft a e ualit as the fit ess fo use of the total soft a e
p odu t . Good quality software does exactly what it is supposed to do and is interpreted in terms of
satisfaction of the requirement specification laid down by the user.
Quality Assurance
Software quality assurance is a methodology that determines the extent to which a software product is fit
for use. The activities that are included for determining software quality are:
 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system
Quality Factors
Correctness: Correctness determines whether the software requirements are appropriately met.
Usability: Usability determines whether the software can be used by different categories of users
(beginners, non-technical, and experts).
Portability: Portability determines whether the software can operate in different platforms with different
hardware devices.
Maintainability: Maintainability determines the ease at which errors can be corrected and modules can be
updated.
Reusability: Reusability determines whether the modules and classes can be reused for developing other
software products.
Object-Oriented Metrics
Metrics can be broadly classified into three categories: project metrics, product metrics, and process
metrics.
Project Metrics
Project Metrics enable a software project manager to assess the status and performance of an ongoing
project. The following metrics are appropriate for object-oriented software projects:
 Number of scenario scripts
 Number of key classes
 Number of support classes
 Number of subsystems
Product Metrics
Product metrics measure the characteristics of the software product that has been developed. The
product metrics suitable for object-oriented systems are:
Methods per Class: It determines the complexity of a class. If all the methods of a class are assumed to be
equally complex, then a class with more methods is more complex and thus more susceptible to errors.
Inheritance Structure: Systems with several small inheritance lattices are more well–structured than
systems with a single large inheritance lattice. As a thumb rule, an inheritance tree should not have more
than 7 (± 2) numbers of levels and the tree should be balanced.
Coupling and Cohesion: Modules having low coupling and high cohesion are considered to be better
designed, as they permit greater reusability and maintainability.

Page no: 19 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Response for a Class: It measures the efficiency of the methods that are called by the instances of the
class.

Process Metrics
Process metrics help in measuring how a process is performing. They are collected over all projects over
long periods of time. They are used as indicators for long-term software process improvements. Some
process metrics are:
 Number of KLOC (Kilo Lines of Code)
 Defect removal efficiency
 Average number of failures detected during testing
 Number of latent defects per KLOC

Page no: 20 Follow us on facebook to get real-time updates from RGPV

 We hope you find these notes useful.
You can get previous year question papers at
https://qp.rgpvnotes.in .

If you have any queries or you want to submit your

study notes please write us at
[email protected]