zOBJECT ORIENTED ANALYSIS AND DESIGN

UNIT 1
INTRODUCTION
Introduction to object oriented systems, UP phases: Inception, Elaboration, Construction and
Transition, Object-oriented metrics, OO Life Cycle Development
INTRODUCTION TO OBJECT ORIENTED SYSTEMS

Object Orientation is a term used to describe the object oriented (OO) method of
building software. In an OO approach, the data is treated as the most important
element and it cannot flow freely around the system.

Restrictions are placed on the number of units that can manipulate the data. This
approach binds the data and the methods that will manipulate the data closely and
prevents the data from being inadvertently modified.

What is OOAD?

Object-oriented analysis and design (OOAD) is a software engineering approach

that models a system as a group of interacting objects. Each object represents some
entity of interest in the system being modeled, and is characterized by its class, its
state (data elements), and its behavior.

Various models can be created to show the static structure, dynamic behavior, and
runtime deployment of these collaborating objects. There are a number of different
notations for representing these models, such as the Unified Modeling Language
(UML).

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the

functional requirements for a system. Object-oriented design (OOD) elaborates the
analysis models to produce implementation specifications. OOA focuses on what
the system does, OOD on how the system does it.

Object-oriented systems

An object-oriented system is composed of objects. The behavior of the system

results from the collaboration of those objects. Collaboration between objects

involves those sending messages to each other.

Sending a message differs from calling a function in that when a target object
receives a message, it itself decides what function to carry out to service that
message. The same message may be implemented by many different functions, the
one selected depending on the state of the target object.

The implementation of "message sending" varies depending on the architecture of

the system being modeled, and the location of the objects being communicated
with.

Object-oriented analysis

Object-oriented analysis (OOA) looks at the problem domain, with the aim of
producing a conceptual model of the information that exists in the area being
analyzed.

Analysis models do not consider any implementation constraints that might exist,
such as concurrency, distribution, persistence, or how the system is to be built.
Implementation constraints are dealt during object-oriented design (OOD). Analysis
is done before the Design.

The sources for the analysis can be a written requirements statement, a formal
vision document, and interviews with stakeholders or other interested parties. A
system may be divided into multiple domains, representing different business,
technological, or other areas of interest, each of which are analyzed separately.

The result of object-oriented analysis is a description of what the system is

functionally required to do, in the form of a conceptual model.

That will typically be presented as a set of use cases, one or more UML class
diagrams, and a number of interaction diagrams. It may also include some kind of
user interface mock-up. The purpose of object oriented analysis is to develop a
model that describes computer software as it works to satisfy a set of customer
defined requirements.

Object-oriented design

Object-oriented design (OOD) transforms the conceptual model produced in

object-oriented analysis to take account of the constraints imposed by the chosen
architecture and any nonfunctional technological or environmental constraints,
such as transaction throughput, response time, run-time platform, development
environment, or programming language.

The concepts in the analysis model are mapped onto implementation classes and
interfaces. The result is a model of the solution domain, a detailed description of
how the system is to be built.

UP (UNIFIED PROCESS) PHASES

The Unified Software Development Process or Unified Process is a popular

iterative and incremental software development process framework. The bestknown and extensively documented refinement of the Unified Process is the
Rational Unified Process (RUP).

Overview

The Unified Process is not simply a process, but rather an extensible framework
which should be customized for specific organizations or projects.

The Rational Unified Process is, similarly, a customizable framework. As a result it

is often impossible to say whether a refinement of the process was derived from UP
or from RUP, and so the names tend to be used interchangeably.

The name Unified Process as opposed to Rational Unified Process is generally used
to describe the generic process, including those elements which are common to
most refinements. The Unified Process name is also used to avoid potential issues
of trademark infringement since Rational Unified Process and RUP are trademarks
of IBM.

Unified Process Characteristics:

Iterative and Incremental the Unified Process is an iterative and incremental

development process. The Elaboration, Construction and Transition phases are

divided into a series of time boxed iterations. (The Inception phase may also be
divided into iterations for a large project.) Each iteration results in an increment,
which is a release of the system that contains added or improved functionality
compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g.
Requirements, Design, Implementation, Testing) the relative effort and emphasis
will change over the course of the project.

Use Case Driven:

In the Unified Process, use cases are used to capture the functional requirements
and to define the contents of the iterations.

Each iteration takes a set of usecases or scenarios from requirements all the way
through implementation, test and deployment.

Architecture Centric:

The Unified Process insists that architecture sit at the heart of the project team's
efforts to shape the system.

Since no single model is sufficient to cover all aspects of a system, the Unified
Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture
baseline which is created during the Elaboration phase.

Risk Focused:

The Unified Process requires the project team to focus on addressing the most
critical risks early in the project life cycle. The deliverables of each iteration,
especially in the Elaboration phase, must be selected in order to ensure that the
greatest risks are addressed first.

Project Lifecycle:
The Unified Process divides the project into four phases:

Inception

Elaboration

Construction

Transition

Inception Phase:
Inception is the smallest phase in the project, and ideally it should be quite short. If the
Inception Phase is long then it may be an indication of excessive up-front specification,
which is contrary to the spirit of the Unified Process.
The following are typical goals for the Inception phase.

Establish a justification or business case for the project

Establish the project scope and boundary conditions

Outline the use cases and key requirements that will drive the design tradeoffs

Outline one or more candidate architectures

Identify risks

Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.
Elaboration Phase:

During the Elaboration phase the project team is expected to capture a healthy
majority of the system requirements. However, the primary goals of Elaboration are
to address known risk factors and to establish and validate the system architecture.
Common processes undertaken in this phase include the creation of use case
diagrams, conceptual diagrams (class diagrams with only basic notation) and
package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an Executable

Architecture Baseline. This is a partial implementation of the system which includes
the core, most architecturally significant, components. It is built in a series of small,

time boxed iterations.

By the end of the Elaboration phase the system architecture must have stabilized and
the executable architecture baseline must demonstrate that the architecture will
support the key system functionality and exhibit the right behavior in terms of
performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule
estimates) for the Construction phase. At this point the plan should be accurate and
credible; since it should be based on the Elaboration phase experience and since
significant risk factors should have been addressed during the Elaboration phase.

The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

Construction Phase:

Construction is the largest phase in the project. In this phase the remainder of the
system is built on the foundation laid in Elaboration. System features are
implemented in a series of short, time boxed iterations.

Each iteration results in an executable release of the software. It is customary to

write full text use cases during the construction phase and each one become the
start of a new iteration. Common UML (Unified Modeling Language) diagrams
used during this phase include Activity, Sequence, Collaboration, State
(Transition) and interaction Overview diagrams.

The Initial Operational Capability Milestone marks the end of the Construction
phase.

Transition Phase:

The final project phase is Transition. In this phase the system is deployed to the
target users. Feedback received from an initial release (or initial releases) may
result in further refinements to be incorporated over the course of several
Transition phase iterations.

The Transition phase also includes system conversions and user training. The
Product Release Milestone marks the end of the Transition phase.

OBJECT-ORIENTED METRICS

Increasingly, object-oriented measurements are being used to evaluate and predict the
quality of software a growing body of empirical results supports the theoretical
validity of these metrics.

The validation of these metrics requires convincingly demonstrating that the metric
measures what it purports to measure (for example, a coupling metric really measures
coupling) and the metric is associated with an important external metric, such as
reliability, maintainability and fault-proneness.

Metrics for Analysis

When code is analyzed for object-oriented metrics, often two suites of metrics are
used, the Chidamber-Kemerer (CK) and MOOD suites. In this section, we enumerate
and explain the specific measures that can be computed using this tool.

Coupling

"Coupling is a measure of interdependence of two objects

For example, objects A and B are coupled if a method of object A calls a method or
accesses a variable in object B. Classes are coupled when methods declared in one
class use methods or attributes of the other classes.

Cohesion

Cohesion refers to how closely the operations in a class are related to each other.
Cohesion of a class is the degree to which the local methods are related to the local
instance variables in the class.

The CK metrics suite examines the Lack of Cohesion (LOCOM), which is the number of
disjoint/non-intersection sets of local methods.

There are at least two different ways of measuring cohesion:

1. Calculate for each data field in a class what percentage of the methods use that data
field. Average the percentages then subtract from 100%. Lower percentages mean
greater cohesion of data and methods in the class.
2. Methods are more similar if they operate on the same attributes. Count the number of
disjoint sets produced from the intersection of the sets of attributes used by the
methods.

High cohesion indicates good class subdivision. Lack of cohesion or low cohesion
increases complexity, thereby increasing the likelihood of errors during the
development process.

Classes with low cohesion could probably be subdivided into two or more subclasses
with increased cohesion. This metric evaluates the design implementation as well as
reusability.

Encapsulation

Information hiding is a way of designing routines such that only subsets of the
modules properties, its public interface, are known to users of the module.
Information hiding gives rise to encapsulation in object-oriented languages.

"Encapsulation means that all that is seen of an object is its interface, namely the
operations we can perform on the object.Information hiding is a theoretical technique
that indisputably proven its value in practice.

Attribute Hiding Factor (AHF)

The Attribute Hiding Factor measures the invisibilities of attributes in classes. The
invisibility of an attribute is the percentage of the total classes from which the
attribute is not visible.

An attribute is called visible if it can be accessed by another class or object. Attributes

should be "hidden" within a class

Method Hiding Factor (MHF)

The Method Hiding Factor measures the invisibilities of methods in classes. The
invisibility of a method is the percentage of the total classes from which the method is
not visible.

The Method Hiding Factor is a fraction where the numerator is the sum of the
invisibilities of all methods defined in all classes. The denominator is the total number
of methods defined in the project.

Inheritance

Inheritance decreases complexity by reducing the number of operations and operators,

but this abstraction of objects can make maintenance and design difficult.

The two metrics used to measure the amount of inheritance are the depth and breadth
of the inheritance hierarchy.

Depth of Inheritance Tree (DIT)

The depth of a class within the inheritance hierarchy is defined as the maximum
length from the class node to the root/parent of the class hierarchy tree and is
measured by the number of ancestor classes. In cases involving multiple inheritances,
the DIT is the maximum length from the node to the root of the tree.

Number of Children (NOC)

This metric is the number of direct descendants (subclasses) for each class. Classes
with large number of children are considered to be difficult to modify and usually
require more testing because of the effects on changes on all the children.

They are also considered more complex and fault-prone because a class with
numerous children may have to provide services in a larger number of contexts and
therefore must be more flexible.

Complexity
Weighted Methods/Class (WMC)

WCM measures the complexity of an individual class. A class with more member
functions than its peers is considered to be more complex and therefore more error
prone.

The larger the number of methods in a class, the greater the potential impact on
children since children will inherit all the methods defined in a class.

Classes with large numbers of methods are likely to be more application specific,
limiting the possibility of reuse. This reasoning indicates that a smaller number of
methods is good for usability and reusability.

OO LIFE CYCLE DEVELOPMENT

System development can be viewed as a process. The development itself, in essence, is a
process of change, refinement, transformation, or addition to existing product. The process
can be divided into small, interacting phases sub processes. Each sub process must have
the following:
1.

A description in terms of how it works

2.

Specification of the input required for the process

3.

Specification of the output to be produced

The software development process can be viewed as a series of transformations, where

the output of one transformation becomes the input of the subsequent transformation.

Analysis

Design

Implementation

Analysis

In academic environments software often seems to grow, without a clear plan or

explicit intention of fulfilling some need or purpose, except perhaps as a vehicle for
research.

In contrast, industrial and business software projects are usually undertaken to meet
some explicit goal or to satisfy some need.

One of the main problems in such situations, from the point of view of the developers
of the software, is to extract the needs from the future users of the system and later to
negotiate the solutions proposed by the team.

10

The problem is primarily a problem of communication, of bridging the gap between

two worlds, the world of domain expertise on the one hand and that of expertise in the
craft of software development on the other.

Analysis methods

Functional Decomposition = Functions + Interfaces

Data Flow Approach = Data Flow + Bubbles

Information Modeling = Entities + Attributes + Relationships

Object-Oriented = Objects + Inheritance + Message passing

Design

In an object-oriented approach, the distinction between analysis and design is

primarily one of emphasis; emphasis on modeling the reality of the problem domain
versus emphasis on providing an architectural model of a system that lends itself to
implementation.

One of the attractive features of such an approach is the opportunity of a seamless

transition between the respective phases of the software product in development.

The classical waterfall model can no longer be considered as appropriate for such an
approach. An alternative model, the fountain model, is proposed by Hend.

This model allows for a more autonomous development of software components,

within the constraints of a unifying framework.

The end goal of such a development process may be viewed as a repository of

reusable components.

Implementation

In principle, the phase of implementation follows on from the design phase. In

practice, however, the products of design may often only be regarded as providing
a post hoc justification of the actual system. The most important distinction
between design and implementation is hence the level of abstraction at which the
structure of the system is described. Design is meant to clarify the conceptual

11

structure of a system, whereas the implementation must include all the details
needed for the system to run.
UNIT II

MODELING
Booch Methodology-Unified Modeling Language Use case Diagram - Class Diagram Interactive Diagram- Package Diagram - Collaboration Diagram - State Diagram - Activity
Diagram
BOOCH METHODOLOGY
The Booch software engineering methodology provides an object-oriented development in
the analysis and design phases. The analysis phase is split into two steps.
The first step is to establish the requirements from the customer perspective. This analysis
step generates a high-level description of the system's function and structure.
The second step is a domain analysis. The domain analysis is accomplished by defining
object classes; their attributes, inheritance, and methods. State diagrams for the objects are
then established. The analysis phase is completed with a validation step.
Booch's methodology has its primary strength in the object system design. Grady Booch has
included in his methodology a requirements analysis that is similar to a traditional
requirements analysis, as well as a domain analysis phase.
Booch's object system design method has four parts, the logical structure design where the
class hierarchies are defined, and the physical structure diagram where the object methods are
described.
In addition, Booch defines the dynamics of classes in a fashion very similar to the
Rumbaugh method, as well as an analysis of the dynamics of object instances, where he
describes how an object may change state.
Booch suggests the following order of events for the formalization of the strategy:

Identify the classes and objects at a given level of abstraction.

Identify the semantics of these classes and objects.

12

Identify the relationships among these classes and objects.

Implement these classes and objects.

Identifying the classes and objects involves finding key abstractions in the problem space
and important mechanisms that offer the dynamic behavior over several such objects. These
key abstractions are found by studying the terminology of the problem domain.
Identifying the semantics involves establishing the meanings of the classes and objects
identified in the previous stage. The developer should view the objects from the outside,
define the object protocol and investigate how each object may be used by other objects.
Identifying relationships extends the previous work to include the relationships between
classes and objects and to identify how these interact with each other. Associations such as
inheritance, instantiation and uses between the classes are defined, as are the static and
dynamic semantics of the mechanisms between the objects. The visibility between classes
and objects is also decided upon
Implementing classes and objects involves delving into the classes and objects and
determining how to implement them in the chosen programming language. This is also the
step where components are used, and the classes and objects are structured into modules.
One of the major strength's of Booch's method is the rich notation available. There are
diagrammatic notations for producing:

class diagrams (class structure - static view)

object diagrams (object structure - static view)

state transition diagrams (class structure - dynamic view)

timing diagrams (object structure - dynamic view)

module diagrams (module architecture)

process diagrams (process architecture)

The notations for class and object modeling use annotations or variant symbols (e.g. different
kinds of arrow) to convey detailed information.

13

Booch suggests that a subset of the notations can be used in the earlier stages of design, with
the detail being filled in later.
There is also a textual form for each notation, consisting of templates for documenting each
major construct.
The Booch method includes six types of diagrams such as class diagrams, object diagrams,
state transition diagrams, module diagrams, process diagrams and interaction diagrams.
UNIFIED MODELING LANGUAGE
Unified Modeling Language (UML) is the set of notations, models and diagrams
used when developing object-oriented (OO) systems.
UML is the industry standard OO visual modeling language. The latest version is UML
1.4 and was formed from the coming together of three leading software methodologists;
Booch,
Unified Modeling Language (UML) is a standardized general-purpose modeling language
in the field of software engineering. The standard is managed, and was created by, the
Object Management Group. UML includes a set of graphic notation techniques to create
visual models of software-intensive systems.
The Unified Modeling Language is commonly used to visualize and construct systems
which are software intensive.
Because software has become much more complex in recent years, developers are finding
it more challenging to build complex applications within short time periods. Even when
they do, these software applications are often filled with bugs, and it can take programmers
weeks to find and fix them.
This is time that has been wasted, since an approach could have been used which would
have reduced the number of bugs before the application was completed. However, it
should be emphasized that UML is not limited simply modeling software.
It can also be used to build models for system engineering, business processes, and
organization structures. A special language called Systems Modeling Language was
designed to handle systems which were defined within UML 2.0.

14

The Unified Modeling Language is important for a number of reasons. First, it has been
used as a catalyst for the advancement of technologies which are model driven, and some
of these include Model Driven Development and Model Driven Architecture.
Because an emphasis has been placed on the importance of graphics notation, UML is
proficient in meeting this demand, and it can be used to represent behaviors, classes, and
aggregation. While software developers were forced to deal with more rudimentary issues
in the past, languages like UML have now allowed them to focus on the structure and
design of their software programs.
It should also be noted that UML models can be transformed into various other
representations, often without a great deal of effort. One example of this is the ability to
transform UML models into Java representations.
USE CASE DIAGRAM
A use case diagram is a graphic depiction of the interactions among the elements of a
system. A use case is a methodology used in system analysis to identify, clarify, and organize
system requirements. Use case diagrams are employed in UML (Unified Modeling
Language), a standard notation for the modeling of real-world objects and systems.
Use case diagrams are usually referred to as behavior diagrams used to describe a set of
actions (use cases) that some system or systems (subject) should or can perform in
collaboration with one or more external users of the system (actors).
Each use case should provide some observable and valuable result to the actors or other
stakeholders of the system.
UML 2 use case diagrams overview the usage requirements for a system. They are useful for
presentations to management and/or project stakeholders, but for actual development you will
find that use cases provide significantly more value because they describe "the meat" of the
actual requirements. Figure 1 provides an example of a UML 2 use case diagram.
Use case diagrams depict:

Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.

15

Actors. An actor is a person, organization, or external system that plays a role in one
or more interactions with your system. Actors are drawn as stick figures.

Associations. Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with an
interaction described by a use case. Associations are modeled as lines connecting use
cases and actors to one another, with an optional arrowhead on one end of the line.

System boundary boxes (optional).. System boundary boxes are rarely used,
although on occasion I have used them to identify which use cases will be delivered in
each major release of a system.

Packages (optional). Packages are UML constructs that enable you to organize model
elements (such as use cases) into groups. Packages are depicted as file folders and can
be used on any of the UML diagrams, including both use case diagrams and class
diagrams.

Use case diagrams are drawn to capture the functional requirements of a system. So after identifying
the above items we have to follow the following guidelines to draw an efficient use case diagram.

The name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.

Give a suitable name for actors.

Show relationships and dependencies clearly in the diagram.

Do not try to include all types of relationships. Because the main purpose of the diagram is
to identify requirements.

Use note when ever required to clarify some important points.

A use case diagram looks something like a flowchart. Intuitive symbols represent the system
elements. Here's a simple example:

16

CLASS DIAGRAM
Class diagram in the unified Modelling Language is a static structure diagram that describes
the structure of a system by shoeing all these in the system, their attributes, and the
relationships between the classes.

Class diagrams are widely used to describe the types of objects in a system and
their relationships. Class diagrams model class structure and contents using design
elements such as classes, packages and objects.
Class diagrams describe three different perspectives when designing a system,
conceptual, specification, and implementation.1 These perspectives become
evident as the diagram is created and help solidify the design.

17

 This example is only meant as an introduction to the UML and class diagrams. If
you would like to learn more see the Resources page for more detailed resources
on UML.
Classes are composed of three things:
1. name,
2. attributes, and
3. operations.
Below is an example of a class.

Class diagrams also display relationships such as containment, inheritance, associations and
others.
2 Below is an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The
association shows the relationship between instances of classes.
For example, the class Order is associated with the class Customer. The multiplicity of the
association denotes the number of objects that can participate in then relationship.1 For
example, an Order object can be associated to only one customer, but a customer can be
associated to many orders. Another common relationship in class diagrams is a

18

generalization. A generalization is used when two classes are similar, but have some
differences.
Look at the generalization below:

In this example the classes Corporate Customer and Personal Customer have some
similarities such as name and address, but each class has some of its own attributes
and operations.
The class Customer is a general form of both the Corporate Customer and Personal
Customer classes.1 This allows the designers to just use the Customer class for
modules and do not require in-depth representation of each type of customer.
When to Use: Class Diagrams
Class diagrams are used in nearly all Object Oriented software designs. Use them to
describe the Classes of the system and their relationships to each other.
How to Draw: Class Diagrams
Class diagrams are some of the most difficult UML diagrams to draw. To draw
detailed and useful diagrams a person would have to study UML and Object Oriented
principles for a long time.
Therefore, this page will give a very high level overview of the process. To find list of
where to find more information see the Resources page.

19

 Before drawing a class diagram consider the three different perspectives of the system
the diagram will present; conceptual, specification, and implementation. Try not to
focus on one perspective and try see how they all work together.
When designing classes consider what attributes and operations it will have. Then try
to determine how instances of the classes will interact with each other.
These are the very first steps of many in developing a class diagram. However, using
just these basic techniques one can develop a complete view of the software system.

The Relationship in a class diagram

1. Instance level Relationship

External link
Association
Aggregation
Composition

2. Class level Relationship

Generalization
Realization
Dependency
Multiplicity

20

INTERACTIVE DIADRAM

From the name Interaction it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. So this interaction is a part of
dynamic behaviour of the system.
This interactive behaviour is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram. The basic purposes of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram
emphasizes on the structural organization of the objects that send and receive messages.
Purpose:
The purposes of interaction diagrams are to visualize the interactive behaviour of the system.
Now visualizing interaction is a difficult task. So the solution is to use different types of
models to capture the different aspects of the interaction. That is why sequence and
collaboration diagrams are used to capture dynamic nature but from a different angle. So the
purposes of interaction diagram can be describes as:
To capture dynamic behaviour of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.
How to draw Component Diagram?
The purpose of interaction diagrams is to capture the dynamic aspect of a system. So to
capture the dynamic aspect we need to understand what a dynamic aspect is and how it is
visualized. Dynamic aspect can be defined as the snap shot of the running system at a
particular moment. We have two types of interaction diagrams in UML.
One is sequence diagram-The sequence diagram captures the time sequence of
message flow from one object to another and

21

 The collaboration diagram -describes the organization of objects in a system taking

part in the message flow.
So the following things are to identified clearly before drawing the interaction diagram:

Objects taking part in the interaction.

Message flows among the objects.

The sequence in which the messages are flowing.

Object organization.

Following are two interaction diagrams modelling order management system. The first
diagram is a sequence diagram and the second is a collaboration diagram.
The Sequence Diagram:
The sequence diagram is having four objects (Customer, Order, SpecialOrder and
NormalOrder). The following diagram has shown the message sequence for SpecialOrder
object and the same can be used in case of NormalOrder object. Now it is important to
understand the time sequence of message flows. The message flow is nothing but a method
call of an object. The first call is sendOrder () which is a method of Order object. The next
call is confirm () which is a method of SpecialOrder object and the last call is Dispatch ()
which is a method of SpecialOrder object. So here the diagram is mainly describing the
method calls from one object to another and this is also the actual scenario when the system
is running.

22

Collaboration Diagram:
The second interaction diagram is collaboration diagram. It shows the object
organization as shown below. Here in collaboration diagram the method call sequence
is indicated by some numbering technique as shown below.
The number indicates how the methods are called one after another. We have taken
the same order management system to describe the collaboration diagram. The
method calls are similar to that of a sequence diagram.
But the difference is that the sequence diagram does not describe the object
organization where as the collaboration diagram shows the object organization.
Now to choose between these two diagrams the main emphasis is given on the type of
requirement. If the time sequence is important then sequence diagram is used and if
organization is required then collaboration diagram is used.

Where to use Interaction Diagrams?

23

 Interaction diagrams are used to describe dynamic nature of a system. To understand

the practical application we need to understand the basic nature of sequence and
collaboration diagram.
The main purposes of both the diagrams are similar as they are used to capture the
dynamic behaviour of a system. But the specific purposes are more important to
clarify and understood.
Sequence diagrams are used to capture the order of messages flowing from one object
to another. And the collaboration diagrams are used to describe the structural
organizations of the objects taking part in the interaction.
A single diagram is not sufficient to describe the dynamic aspect of an entire system
so a set of diagrams are used to capture is as a whole.
The interaction diagrams are used when we want to understand the message flow and
the structural organization.
Now message flow means the sequence of control flow from one object to another
and structural organization means the visual organization of the elements in a system.
In a brief the following are the usages of interaction diagrams:
To model flow of control by time sequence.
To model flow of control by structural organizations.
For forward engineering.
For reverse engineering.

PACKAGE DIAGRAM:
A package diagram is a UML diagram composed only of packages and the dependencies
between them. A package is a UML construct that enables you to organize model elements,
such as use cases or classes, into groups.
Packages are depicted as file folders and can be applied on any UML diagram. Create a
package diagram to:
Depict a high-level overview of your requirements (overviewing a collection of UML
Use Case diagrams)
Depict a high-level overview of your architecture/design (overviewing a collection of
UML Class diagrams).
24

 To logically modularize a complex diagram.

To organize Java source code.
There are guidelines for:
1. Class Package Diagrams
2. Use Case Package Diagrams
3. Packages

1. Create UML Component Diagrams to Physically Organize Your Design.

2. Place Sub packages Below Parent Packages.
3. Vertically Layer Class Package Diagrams.
4. Create Class Package Diagrams to Logically Organize Your Design. Error! Reference
source not found. Depicts a UML Class diagram organized into packages.

25

In addition to the package guidelines presented below, apply the following heuristics to
organize UML Class diagrams into package diagrams: Place the classes of a framework in
the same package.
Classes in the same inheritance hierarchy typically belong in the same package.
Classes related to one another via aggregation or composition often belongs in the same
package. Classes that collaborate with each other a lot, information that is reflected by
your UML Sequence diagrams and UML Collaboration diagrams, often belong in the
same package.
Use cases are often a primary requirement artifact in object-oriented development
methodologies, this is particularly true of instantiations of the Unified Process, and for
larger projects package diagrams are often created to organize these usage requirements.

Packages
A package in the Unified Modelling Language is used to group elements, and to provide a
namespace for the grouped elements.
The advice presented in this section is applicable to the application of packages on any UML
diagram, not just package diagrams.
1. Give Packages Simple, Descriptive Names
2. Apply Packages to Simplify Diagrams
3. Packages Should be Cohesive
4. Indicate Architectural Layers With Stereotypes on Packages
5. Avoid Cyclic Dependencies Between Packages
6. Package Dependencies Should Reflect Internal Relationships
Use Case Package Diagrams
Use cases are often a primary requirement artefact in object-oriented development
methodologies, this is particularly true of instantiations of the Unified Process, and for larger
projects package diagrams are often created to organize these usage requirements.

26

1. Create Use Case Package Diagrams to Organize Your Requirements

2. Include Actors on Use Case Package Diagrams
3. Horizontally Arrange Use Case Package Diagrams.
There are two special types of dependencies between packages,
Package import
Package merge
Package import:
It is a relationship between an importing namespace and a package, indicating that the
importing namespace adds the names of the members of the packages to its own namespace.
This is the default relationship.
Package merges:
It is directed relationship between two packages, which indicates that the content of the two
packages are to be combined.
It is very similar to Generalization in the sense that the source element conceptually adds the
characterised of the target element to its own characterized resulting in an element that
combines the characterises of both.
COLLABORATION DIAGRAM
A collaboration diagram, also called a communication diagram or interaction diagram, is an
illustration of the relationships and interactions among software objects in the Unified

27

Modeling Language (UML). The concept is more than a decade old although it has been
refined as modeling paradigms have evolved.
Collaboration diagrams show the message flow between objects in an OO application, and
also imply the basic associations (relationships) between classes. Collaboration diagrams are
often used to:

Provide a birds-eye view of a collection of collaborating objects, particularly within a

real-time environment.

Allocate functionality to classes by exploring the behavioral aspects of a system.

Model the logic of the implementation of a complex operation, particularly one that
interacts with a large number of other objects.

Explore the roles that objects take within a system, as well as the different
relationships they are involved with when in those roles.

There are guidelines for:

1. General issues
2. Messages
3. Links

1. General

Fig1. An Instance-Level UML Collaboration diagram.

28

1. Use Instance-Level Diagrams To Explore Object Design Issues. Instance-level UML

Collaboration diagrams, such as the one shown in Figure 1, depict interactions
between objects (instances). Instance-level diagrams are typically created to explore
the internal design of object-oriented software.
2. Use Specification-Level Diagrams to Explore Roles. Specification-level UML
Collaboration diagrams, such as the one shown in Figure 3, are used to analyze and
explore the roles taken by domain classes within a system.
3. Collaboration Diagrams Do Not Model Process Flow.
4. When Sequence Is Important Use a Sequence Diagram.
5. Apply Sequence Diagram Guidelines To Instance-Level Collaboration Diagrams.
Because UML Collaboration diagrams depict an alternate view of the same
information as UML Sequence diagrams much of the same style advice applies. The
following lists of guidelines, originally presented for UML Sequence diagrams, are
applicable to collaboration diagrams:

Name Objects When Your Reference Them In Messages

Name Objects When Several of the Same Type Exist

Apply Textual Stereotypes Consistently

Apply Visual Stereotypes Sparingly

Focus on Critical Interactions

Prefer Names Over Types for Parameters

Indicate Types as Parameter Placeholders

Do Not Model a Return Value When it is Obvious What is Being Returned

Model a Return Value Only When You Need to Refer to it Elsewhere

Model Return Values as Part of a Method Invocation

Indicate Types as Return Value Placeholders

29

2. Messages
Figure 2 presents the notation for invoking messages on UML Collaboration diagrams. For
example in Figure 1 the message 1.2: orderTotal := calculateTotal() indicates a sequence
number of 1.2, there is no loop occuring, a return value of orderTotal and an invoked method
named calculateTotal().
Fig 2. A UML Collaboration diagram depicting concurrent message invocations.

1. Indicate a Return Value Only When It Isn't Clear

2. Indicate Parameters Only When They Aren't Clear
3. Depict an Arrow For Each Message
4. Consolidate Getter Invocations. When you have several getters invoked in a row a
good short cut is to model a single message such as getInfo() in Figure 1to act as a
placeholder.
5. Indicate Concurrent Threads With Letters.
Links
The lines between the classifiers depicted on a UML Collaboration diagram represent
instances of the relationships - including associations, aggregations, compositions, and
dependencies - between classifiers.
Fig 3. A Specification-Level UML Collaboration diagram.

30

1. Model "Bare" Links On Instance-Level Collaboration Diagrams

2. Show Role-Pertinent Information on Specification-Level Diagrams. In Figure 3 you
see that the roles taken by classes as well as the high-level multiplicities (either blank
or an asterisk to represent many) are depicted.
3. Prefer Roles on Links Instead of Within Classes
4. Indicate Navigability Sparingly
5. Links Should Be Consistent Static Relationships
STATE DIAGRAM

State diagrams are used to describe the behavior of a system. State diagrams describe
all of the possible states of an object as events occur.

Each diagram usually represents objects of a single class and track the different states
of its objects through the system.

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases
of the system.

Only use state diagrams for classes where it is necessary to understand the behavior of
the object through the entire system.

Not all classes will require a state diagram and state diagrams are not useful for
describing the collaboration of all objects in a use case.

State diagrams are other combined with other diagrams such as interaction diagrams
and activity diagrams.

How to Draw: State Diagrams

31

State diagrams have very few elements. The basic elements are rounded boxes

representing the state of the object and arrows indicting the transition to the next state.
The activity section of the state symbol depicts what activities the object will be doing
while it is in that state.

All state diagrams being with an initial state of the object. This is the state of the

object when it is created.

After the initial state the object begins changing states. Conditions based on the
activities can determine what the next state the object transitions to.

Below is an example of a state diagram might look like for an Order object. When the

object enters the Checking state it performs the activity "check items."
After the activity is completed the object transitions to the next state based on the

conditions [all items available] or [an item is not available].

If an item is not available the order is canceled. If all items are available then the
order is dispatched. When the object transitions to the Dispatching state the activity

"initiate delivery" is performed.

After this activity is complete the object transitions again to the Delivered state.

32

State diagrams can also show a super-state for the object. A super-state is used when

many transitions lead to the a certain state.

Instead of showing all of the transitions from each state to the redundant state a superstate can be used to show that all of the states inside of the super-state can transition to

the redundant state.

This helps make the state diagram easier to read. The diagram below shows a superstate. Both the Checking and Dispatching states can transition into the Canceled state,

so a transition is shown from a super-state named Active to the state Cancel.

By contrast, the state Dispatching can only transition to the Delivered state, so we
show an arrow only from the Dispatching state to the Delivered state.

The state diagram in the Unified Modeling Language is essentially a Harel

statechart with standardized notation[1] ,[2] which can describe many systems, from
computer programs to business processes. In UML 2 the name has been changed

33

to State Machine Diagram. The following are the basic notational elements that can
be used to make up a diagram:

Filled circle, pointing to the initial state

Hollow circle containing a smaller filled circle, indicating the final state (if any)

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) causing this transition
labels the arrow body. A guard expression may be added before a "/" and enclosed in
square-brackets ( eventName[guardExpression] ), 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 "/" ( eventName[guardExpression]/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.

ACTIVITY DIAGRAM

Activity diagram is UML behavior diagram which shows flow of control or object flow with
emphasis on the sequence and conditions of the flow.
The actions coordinated by activity models can be initiated because other actions finish
executing, because objects and data become available, or because some events external to the
flow occur.
The

following

nodes

and

edges

are

typically

drawn

on UML activity

diagrams: activity, partition, action, object, control, activity edge.

Activity
Activity is a parameterized behavior represented as coordinated flow of actions.
The flow of execution is modeled as activity nodes connected by activity edges. A node can
be the execution of a subordinate behavior, such as an arithmetic computation, a call to an
operation, or manipulation of object contents.
Activity nodes also include flow of control constructs, such as synchronization, decision, and
concurrency control. Activities may form invocation hierarchies invoking other activities,

34

ultimately resolving to individual actions. In an object-oriented model, activities are usually

invoked indirectly as methods bound to operations that are directly invoked.
Activity contains activity nodes which could be:
1. Action
2. Object
3. Control
Activities may contain actions of various kinds:

Occurrences of primitive functions, such as arithmetic functions.

Invocations of behavior, such as activities.

Communication actions, such as sending of signals.

Manipulations of objects, such as reading or writing attributes or associations.

There are actions that invoke activities - either directly using call behavior action or
indirectly with call operation action.
Activity could be rendered as round-cornered rectangle with activity name in the upper left
corner and nodes and edges of the activity inside the border. UML 2.4 specification examples
show activity name in bold.

Online Shopping activity.

Activity parameters are displayed on the border and listed below the activity name as:
parameter-name: parameter-type.

35

Authenticate User activity with two parameters - Login Id and Password.

As a behavior activity could have pre- and post-condition constraints. If present, these are
shown with the keywords precondition and post condition, respectively.
The keyword single Execution is used for activities that execute as a single shared
execution (singleton), otherwise, each invocation executes in its own space.
The round-cornered activity border may be replaced with the frame notation for diagrams.
The kind of the frame in this case is activity or act in short form. Activity parameters if any
are displayed on the frame.

Authenticate User activity frame with two parameters - Login Id and Password.
The notation for classes with the keyword activity can be used to show the features of a
reflective activity, to indicate it is an activity class. Association and state machine notation
can also be used as necessary.
UML allows behaviors to produce tokens that are activities and which can in turn be
executed at the runtime.
Activity Partition
An activity partition is activity group for actions that have some common characteristic.
Partitions often correspond to organizational units or business actors in a business model.
Partitions provide a constrained view on the behaviors invoked in activities. Constraints
could be selected according to the type of the element that the partition represents. The
following constraints are normative (standard) in UML 2.4:

Classifier

Instance

Part

Attribute and value

36

For example, partitions could represent specific classifiers. In this case actions in each
partition should be operations or signals targeting objects that are instances of the
corresponding classifier.
A partition may represent some attribute and its subpartitions - specific values of that
attribute. For example, a partition may represent the location at which a behavior is carried
out, and the subpartitions would represent specific values for that attribute, such as New
York.
Activity partition may be shown using a swim lane notation - with two, usually parallel
lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any
activity nodes, e.g. actions and edges placed between these lines are considered to be
contained within the partition.

Activity partitions Customer and Order Dept as horizontal swimlanes

Activity partitions Customer and Order Dept as vertical swimlanes

Hierarchical partitioning is represented using swimlanes for subpartitions as illustrated
below.

37

Hierarchical partitioning with subpartitions

A partition may be marked as a dimension for its subpartitions to contain (group) those
subpartitions along dimension. For example, an activity may have one dimension of partitions
for location at which the contained behaviors are carried out, and another for the cost of
performing them. Dimension partitions cannot be contained by any other partition.
Diagrams can also be partitioned multidimensionally, where each swim cell is an intersection
of multiple partitions. The partitions within each dimension may be grouped into an enclosing
activity partition with isDimension=true, whose name is the dimension name. Rather than
being shown as a partition itself, however, the dimension is indicated by placing its name
along side the set of partitions in the dimension.
Partition could represent an external entity to which the partitioning structure does not
apply. External partitions are intentional exceptions to the rules for partition structure. For
example, a dimension may have partitions showing parts of a structured classifier. It can have
an external partition that does not represent one of the parts, but a completely separate
classifier. In business modeling, external partitions can be used to model entities outside a
business.
When activities are considered to occur outside the domain of a particular model, the
partition can be labeled with the keyword external. Whenever an activity in a swimlane is
marked external, this overrides the swimlane and dimension designation.

38

Buy action occurs in external partition Customer

In the situations when swimlanes can't be used to show partitions, alternate text notation with
qualified action name could be used instead. In this case partitionname is placed in
parenthesis above the action name. A comma-delimited list of partition names means that the
node is contained in more than one partition. A double colon within a partition name indicates
that the partition is nested, with the larger partitions coming earlier in the name.

Buy action occurs in the external partition Customer

Following are the main usages of activity diagram:

Modeling work flow by using activities.

Modeling business requirements.

High level understanding of the system's functionalities.

Investigate business requirements at a later stage.

UNIT III
ANALYSIS

39

Identifying UseCase -Use Case driven approach-Approaches for identifying classes

-Attributes and methods
IDENTIFYING USECASE
A Use Case captures a contract between the stakeholders of a system about its behavior. Use
cases describes the systems behavior under various conditions as the system responds to
requests from its users (actors) specifying how the actors goals get delivered or fail.

A use case is:

a set of scenarios that describe the behavior of the system and its users
at a high level of detail
with sunny-day and rainy-day scenarios being defined

A use case gathers the scenarios related to the (primary) actors goal

Actors are the people and/or computer systems that are outside the system under
development (SuD)and interact with it:
Primary actor a stakeholder who requests that the system deliver a goal
Supporting/secondary actor an external system against which the SuD
has a goal

Scenarios are dialogs between actors and the system

A use-case is
a set of activities within a system
presented from the point of view of the associated actors
leading to an externally visible result
a (simplified) part of a business process model

40

User Goal Technique

This is a rather obvious approach that involves talking to users and getting them to discuss
their goals for the new system. The analyst would typically list all the stakeholders who are
likely to interact with the system, think through their roles and identify what they would need
to get their work done.
By analyzing existing systems and asking users how they would like to use the new system,
the analyst can come up with an array of use cases. Use cases are thus, a combination
of existing system functions and newly requested functions.

CRUD Technique
Another technique used for identifying use cases is CRUD, an acronym for Create, Read or
Report, Update and Delete. Here, the analyst identifies all the data elements to be processed
by the system and creates use cases that create, report on, update, and delete the data items.
Heres a guide to using the CRUD technique, using an online ordering website as an example:
1. Identify the data items to be handled by the system. The data items involved relate to
customer, order, inventory item and shipment.
2. Examine each data item and state the use cases that create the data; read or report on the
data; update the data; and delete the data.
Actors

An actor is an entity that is outside of the system

Actors will interact with the system:

An actor will often request the system to perform some actions on behalf
of the actor
An actor may also receive responses from the system

An actor plays a role in the use of the system

41

The name given to an actor is usually the role name: for example, an actor who is a
Person will usually be called a User, Operator, Administrator, or something like that

Each role might be treated as a different actor in the use cases

Communication between actors and the system

In each use case, a primary actor starts things off: that actor initiates an interaction
with the system

The system will then respond to messages and might send messages of its own to
other actors

In a use case, the primary actor is trying to achieve a specific goal:

The use case consists of all the possible interactions that take place in the attempt
to reach the goal
there may be many scenarios in a use case - each scenario shows an alternative
course that is based on the success or failure of some of the intermediate steps
the goal might not be reached (because of some of the failures)

Scenarios

A scenario is a little story

it is an outline of some expected sequence of events

A scenario is used to convey the fundamentals of how things work

It usually includes at least one actor

Each actor can make requests of the system or respond to system activity

Identifying actors

An Automated Teller Machine (ATM) permits customers to withdraw money from

their accounts, make deposits, and check their account balances. The ATM machine
communicates with a computer system in the banks central office to validate
passwords and account information. The ATM is serviced on a regular basis by bank
employees, to collect deposit envelopes and to load in more cash and receipt paper.
42

Creating a simple scenario

Draw a sequence diagram for one of the scenarios in the ATM system. One prominent
use case in this system is customer performs an ATM transaction, and one scenario
in that use case is customer withdraws money. Assume we are in the sunny-day
scenario.

USE CASE DRIVEN APPROACH

OOA phase of UA uses actors & use cases to describe system from users perspective. Actors
are external factors that interact with system; use cases are scenarios describe how actors
use system
Actors are external factor that interact with the system
Usecases are scenarios describe how actors use the system
The OOA process consists of following steps: 1. Identify the actors:
who is using system?
In new case, who will be using the system?
2. Develop a simple business process model using UML activity diagram
3. Develop the use case:
What are the users doing with the system?
In case of new system, what will users be doing with the system?
Use cases provide us with comprehensive documentation of system under study
4. Prepare interaction diagrams:
Determine the sequence,
Develop collaboration diagrams
5. Classification develop a static UML class diagram:

43

 Identify classes,
Identify relationships
Identify attributes
Identify methods
6. Iterate and refine: if needed, repeat the preceding steps
APPROACHES FOR IDENTIFYING CLASSES

Noun phrase approach

The common class patterns approach

The use-case driven, sequence/collaboration modeling approach

The Classes, Responsibilities, and Collaborators (CRC) approach

Noun phrase approach:

Nouns in the textual description are considered to be classes and verbs to be methods of the
classes. All plurals are changed to singular, the nouns are listed and the list divided into
relevant classes, fuzzy classes and irrelevant class.
Three categories:

Relevant classes.

Fuzzy classes.

Irrelevant classes.

Identifying tentative classes.

Look for noun phrases and nouns in the use cases.

Some classes are implicit or taken from general knowledge.

All classes must make sense in the application domain.

Carefully choose and define class names.

44

Selecting classes from the relevant and fuzzy classes.

Redundant classes.

Adjective classes.

Attribute classes.

Irrelevant classes.

The common class patterns approach

Concept class

Events class

Organization class

People class

Places class

Tangible things and devices class

The use-case driven, sequence/collaboration modeling approach

1. Create sequence/collaboration diagram
2. Identify class from the diagram
3. Identify operation from the diagram
4. Identify collaboration from the diagram
The Classes, Responsibilities, and Collaborators (CRC) approach

1. Identify classes responsibilities (and identify classes)

2. Assign responsibilities
3. Identify collaborator
IDENTIFYING ATTRIBUTES AND METHODS:

Identifying attributes and method is like finding classes, still a difficult activity and an
iterative process.

Once again use case and other UML diagrams will be our guide for identifying
attributes, methods and relationship among the classes.

45

Responsibilities identify problems to be solved

Attributes are things an object must remember such as color, cost and manufacturer

Identifying attributes of a systems classes starts with understanding the systems

responsibilities

Following questions help in identifying the responsibilities of classes and deciding

what data elements to keep track of: 1. What information about an object should we
keep track of? 2. What services must a class provide?

Defining attributes by analyzing usecases and other UML diagrams:

Attributes can be derived from scenario testing; therefore, by analyzing the usecases
and sequence/collaboration, activity and state diagrams, we can begin to understand
classes, responsibilities and how they must interact to perform their tasks.

Main goal here is to understand want the class is responsible for knowing.
Responsibilities is the key issues

Using previous OOA results for analysis patterns can be extremely useful in finding
out what attributes can be reused directly and what lessons can be learned for
identifying attributes Guidelines for defining attributes.

Some of the guidelines for identifying attributes of classes in use cases:

Attributes usually correspond to nouns followed by prepositional phrases such

as cost of the soup. Attributes also may correspond to adjectives/adverbs

Keep the class simple; state only enough attributes to define the object state

Attributes are less likely to be fully described in the problem statement

Omit derived attributes
Do not carry discovery of attributes to excess
Object Responsibility: Methods and Messages:

Objects not only describe abstract data but also must provide some services

46

Methods and messages are the workhorses of OO system .In an OO environment,

every piece of data, or object is surrounded by a rich set of routines called methods.

These methods do everything from printing the object to initializing its variables
.Every class is responsible for storing certain information from the domain knowledge

It also is logical to assign the responsibility for performing any operation necessary on
that information.

Operations (method/behavior) in the OO system usually correspond to quieries about

attributes of the objects.

In other words, methods are responsible for managing the values of attributes such as
query, updating, reading and writing.

Defining methods by analyzing UML diagrams and Use cases

In a sequence diagram, the objects involved are drawn on the drag as vertical
dashed lines, the events that occur between object are drawn between the vertical
object lines

An event is considered to be an action that transmits information, these action are

operation that the object must perform and as in the attributes, methods also can
be derived from scenario testing

Sequence diagram can assist in defining te services the object must provide.

47

UNIT-IV
DESIGN
OO Design Process and Design Axioms
INTRODUCTION

Main focus of the analysis phase of SW development what needs to be done

Objects discovered during analysis serve as the framework for design

Classs attributes, methods, and associations identified during analysis must be

designed for implementation as a data type expressed in the implementation language

During the design phase, we elevate the model into logical entities, some of which
might relate more to the computer domain (such as user interface, or the access layer)
than the real world or the physical domain (such as people or employees). Start
thinking how to actually implement the problem in a program.

The goal to design the classes that we need to implement the system.

Design is about producing a solution that meets the requirements that have been
specified during analysis.

Object-Oriented Design Process and Design Axioms

Analysis Phase

Classs attributes, methods and associations are identified

Physical entities, players and their cooperation are identified

Objects can be individuals, organizations or machines

Design Phase

Using Implementation language appropriate data types are assigned

Elevate the model into logical entities (user interfaces)

48

Focus is on the view and access classes (How to maintain information or best way to
interact with a user)

Importance of Good Design

Time spent on design decides the success of the software developed.
Good design simplifies implementation and maintenance of a project.
To formalize (celebrate, honor) design process, axiomatic (clear) approach is to be followed
Activities of OOD Process
(1).Apply design axioms to design classes, their attributes, methods, associations, structure
and protocols.

Refine and complete the static UML class diagram by adding details to the
UML class diagram. This steps consists of the following activities:

Refine attributes

Design methods and protocols by utilizing a UML activity diagram to

represent the methods algorithm.

Refine association between classes (if required)

Refine class hierarchy and design with inheritance (if required). 1.2 Iterate and
refine again.

(2) Design the access layer

Create mirror classes: For every business class identified and created, create one
access layer

Eg , if there are 3 business classes (class1, class2 and class3), create 3 access layer
classes (class1DB, class2DB and class3DB)

Identify access layer class relationships

Simplify classes and their relationships main goal is to eliminate redundant classes and
structures

Redundant classes: Do not keep 2 classes that perform similar translate request and
translate results activities. Select one and eliminate the other.

Method classes: Revisit the classes that consist of only one or two methods to see if
they can be eliminated or combined with existing classes.

Iterate and refine again.

49

(3) Design the view layer classes

Design the macro level user interface, identifying view layer objects

Design the micro level user interface, which includes these activities:

(a) Design the view layer objects by applying the design axioms and corollaries.
(b) Build a prototype of the view layer interface

Test usability and user satisfaction

Iterate and refine

(4) Iterate and refine the whole design. Reapply the design axioms and if needed , repeat the
preceding steps.

An axiom is a fundamental truth that always is observed to be valid and for which
there is no counterexample or exception.

They can not be proven or derived but they can be invalidated by counterexamples or
exceptions.

A theorem is a proposition that may not be self-evident (clear) but can be proved from
accepted axioms.

A corollary is a proposition that follows from an axiom or another proposition that has
been proven.

Types of Axioms

AXIOM-1 (Independence axiom): deals with relationships between system

components such as classes, requirements, software components.

AXIOM-2 (Information axiom): deals with the complexity of design

Axioms of OOD

The axiom 1 of object-oriented design deals with relationships between system

components (such as classes, requirements and software components) and axiom 2
deals with the complexity of design.

Axiom 1. The independence axiom. Maintain the independence of components.

According to axiom 1, each component must satisfy its requirements without affecting
other requirements. Eg. Let us design a refrigerator door which can provide access to

50

food and the energy lost should be minimized when the door is opened and closed.
Opening the door should be independent of losing energy.

Axiom 2. The information axiom. Minimize the information content of the design. It
is concerned with simplicity. In object-oriented system, to minimize complexity use
inheritance and the systems built in classes and add as little as possible to what
already is there.

Types of corollaries
The design rules or corollaries derived from design axioms are stated below.
Corollary 1: Uncoupled design with less information content.
Corollary 2: Single purpose.
Corollary 3: Large number of simple classes.
Corollary 4: Strong mapping.
Corollary 5: Standardization.
Corollary 6: Design with inheritance.

Object Storage

A database management system (DBMS) is a set of programs that enables the creation &
maintenance of a collection of related data.

The fundamental purpose is to provide a reliable, persistent data storage facility &
mechanisms for efficient, convenient data access & retrieval

Persistence refers to the ability of some objects to outlive the programs that created them.
A program will create a large amount of data throughout its execution.

Each item of data will have a different life time. Atkinson et al. describe six broad
categories of life time of data:

Transient results to evaluation of expressions

Variables involved in procedure activation (parameters & variables with a localized

scope)

Global variables & variables that are dynamically allocated

Data that exist between the executions of a program

51

Data that exist between the versions of a program

Data that outlive a program

The first three categories are transient data, data that cease to exist beyond lifetime of
creating process. The other three are non-transient or persistent data

A file or a database can provide a longer life for objects longer than duration of process
in which they were created. From a language perspective, this characteristic is called
persistence. Essential elements in providing a persistent store are

Identification of persistent objects or reachability (object ID)

Properties of objects & their interconnections. The store must be able to coherently
manage non-pointer & pointer data (i.e., inter-object references)

Scale of the object store. The object store should provide a conceptually infinite store.

Stability: The system should be able to recover from unexpected failures and return the
system to a recent selfconsistent state. This is similar to reliability requirements of a
DBMS.

Designing Classes:

The single most important activity in designing an application is coming up with a set
of classes that works together to provide the needed functionality. Underlying the
functionality of any application is the quality of its design

OOD Philosophy: A great benefit of OO approach is that classes organize related

properties into units that stand on their own. Applying design axioms and carefully
designed classes can have a synergistic effect, not only on the current system but on
its future evolution

UML OCL: UML is a graphical language with a set of rules & semantics in English
in form of OCL. Object Constraint Language (OCL) is specification language that
uses simple logic for specifying properties of a system. Syntax of some common
navigational expressions is shown here,

Item.selector: The selector is name of an attribute in item. The result is the value of attribute
Item.selector [qualifiervalue]: The selector indicates a qualified association that qualifies the
item. Result is related object selected by qualifier, eg., array indexing as form of
qualification.
Set select (Booleanexpression): Boolean expression is written in terms of objects within set

52

Designing Classes The Process: It constitute of step 1 of OOD process is an iterative

process and at each iteration, the design has been improved

Class visibility: The main objective is designing well defined public, private &
protected protocols

Public protocols define the functionality & external messages of an object; private
protocols define implementation of an object

Private Protocol (visibility) of class includes messages that normally should not be
sent from other objects. In protected protocol (visibility), subclasses use method in
addition to class itself

The problem of encapsulation leakage occurs when details about a classs internal
implementation are disclosed through the interface

Refining Attributes: Attributes identified in OOA must be refined on implementation

during this phase. In design phase, detailed information must be added to the model.
The main goal is to refine existing attributes or add attributes that can elevate the
system into implementation.

Attribute Types: The three types of attributes are 1. Singlevalue attributes 2.

Multiplicity or multivalue attributes and 3. Reference to another object, or instance
connection

UML Attribute representation: The following is attribute presentation suggested by

UML
Visibility name: typeexpression = initialvalue where visibility is one of following
+ public visibility (accessibility to all classes)
# protected visibility (accessibility to subclasses & operations of class)
__ private visibility (accessibility only to operations of the class)
Type expression is languagedependent specification of implementation type
of an attribute. Initial value is languagedependent expression for initial value of
newly created object and is optional. Multiplicity indicated by placing a multiplicity
indicator in brackets.

Designing Methods and Protocols: -

53

The main goal of this activity is to specify the algorithm for methods identified so far.
A class can provide several types of methods: Constructor, Destructor, Conversion
method, Copy method, Attribute set, Attribute get, I/O methods, Domain specific

Use private and protected protocols to define the functionality of the object.
Remember five rules to avoid bad design:
1. If it looks messy, then its probably a bad design
2. If it looks too complex, then its probably a bad design
3. If it is too big, then its probably a bad design
4. If people dont like it, then its probably a bad design
5. If it doesnt work, then its probably a bad design

Apply design axioms and corollaries to avoid design pitfalls and use UML operation
presentation which is similar to syntax of UML attribute representation.

Packages and Managing classes:

The UML package is grouping of model elements. IT can organize the modeling
elements including classes. Packages themselves may be nested within other
packages.

A package may contain both other packages and ordinary model elements. The entire
system description can be thought of as a single, highlevel sub system package with
everything else in it

OOD is an iterative process. Designing is as much about discovery as construction. At

each iteration we can improve the design

The advisable trick is to fix the design as early as possible; redesigning late in
development cycle is problematic and may be impossible.

System Design
Object-oriented system design involves defining the context of a system followed by
designing the architecture of the system.

Context : The context of a system has a static and a dynamic part. The static context
of the system is designed using a simple block diagram of the whole system which is
expanded into a hierarchy of subsystems. The subsystem model is represented by

54

UML packages. The dynamic context describes how the system interacts with its
environment. It is modelled using use case diagrams.

System Architecture : The system architecture is designed on the basis of the context
of the system in accordance with the principles of architectural design as well as
domain knowledge. Typically, a system is partitioned into layers and each layer is
decomposed to form the subsystems.

Real Time Example:

Systems which monitor and control their environment

Inevitably associated with hardware devices

Sensors: Collect data from the system environment

Actuators: Change (in some way) the system's environment

Time is critical. Real-time systems MUST respond within specified times

A real-time system is a software system where the correct functioning of the system
depends on the results produced by the system and the time at which these results are
produced

A soft real-time system is a system whose operation is degraded if results are not
produced according to the specified timing requirements

A hard real-time system is a system whose operation is incorrect if results are not
produced according to the timing specification Stimulus/Response Systems

Given a stimulus, the system must produce a response within a specified time.

For example, a temperature sensor may be polled 10 times per second

Aperiodic stimuli. Stimuli which occur at unpredictable times

For example, a system power failure may trigger an interrupt which must be
processed by the system Architectural considerations

Because of the need to respond to timing demands made by different stimuli /

responses, the system architecture must allow for fast switching between stimulus
handlers

55

Timing demands of different stimuli are different so a simple sequential loop is not
usually adequate Real Time Software Design:

Designing embedded software systems whose behavior is subject to timing constraints

To explain the concept of a real-time system and why these systems are usually
implemented as concurrent processes

To describe a design process for real-time systems

To explain the role of a real-time executive

To introduce generic architectures for monitoring and control and data acquisition
systems Real-time systems:

Systems which monitor and control their environment

Inevitably associated with hardware devices Sensors: Collect data from the system
environment Actuators: Change (in some way) the system's environment

Time is critical. Real-time systems MUST respond within specified times Definition:

A real-time system is a software system where the correct functioning of the system
depends on the results produced by the system and the time at which these results are
produced

A soft real-time system is a system whose operation is degraded if results are not
produced according to the specified timing requirements

A hard real-time system is a system whose operation is incorrect if results are not
produced according to the timing specification Stimulus/Response Systems:

Given a stimulus, the system must produce a response within a specified time

Periodic stimuli. Stimuli which occur at predictable time intervals For example, a
temperature sensor may be polled 10 times per second

Because of the need to respond to timing demands made by different

stimuli/responses, the system architecture must allow for fast switching between
stimulus handlers

Timing demands of different stimuli are different so a simple sequential loop is not
usually adequate

Real-time systems are usually designed as cooperating processes with a real-time

executive controlling these processes A real-time system model:

Non-stop system components:

56

Configuration manager Responsible for the dynamic reconfiguration of the system

software and hardware. Hardware modules may be replaced and software upgraded
without stopping the systems

Fault manager Responsible for detecting software and hardware faults and taking
appropriate actions (e.g. switching to backup disks) to ensure that the system
continues in operation Burglar alarm system

e.g A system is required to monitor sensors on doors and windows to detect the
presence of intruders in a building

When a sensor indicates a break-in, the system switches on lights around the area and
calls police automatically

The system should include provision for operation without a mains power supply
Sensors

Movement detectors, window sensors, door sensors.

50 window sensors, 30 door sensors and 200 movement detectors

Voltage drop sensor

When an intruder is detected, police are called automatically.

Lights are switched on in rooms with active sensors.

An audible alarm is switched on.

The system switches automatically to backup power when a voltage drop is detected.
The R-T system design process:

Identify stimuli and associated responses

Define the timing constraints associated with each stimulus and response

Allocate system functions to concurrent processes

Design algorithms for stimulus processing and response generation

Design a scheduling system which ensures that processes will always be scheduled to
meet their deadlines Control systems:

A burglar alarm system is primarily a monitoring system. It collects data from sensors
but no real-time actuator control

Control systems are similar but, in response to sensor values, the system sends control
signals to actuators

57

An example of a monitoring and control system is a system which monitors

temperature and switches heaters on and off Data acquisition systems:

Collect data from sensors for subsequent processing and analysis.

Data collection processes and processing processes may have different periods and
deadlines.

Data collection may be faster than processing e.g. collecting information about an
explosion.

Circular or ring buffers are a mechanism for smoothing speed differences

Reactor data collection:

A system collects data from a set of sensors monitoring the neutron flux from a
nuclear reactor.

Flux data is placed in a ring buffer for later processing.

The ring buffer is itself implemented as a concurrent process so that the collection and
processing processes may be synchronized. Reactor flux monitoring: Sensors (each
data flow is a sensor value) Sensor identifier and value Sensor Sensor data Process
process buffer data Mutual exclusion:

Producer processes collect data and add it to the buffer. Consumer processes take data
from the buffer and make elements available Reactor data collection:

A system collects data from a set of sensors monitoring the neutron flux from a
nuclear reactor.

Flux data is placed in a ring buffer for later processing.

The ring buffer is itself implemented as a concurrent process so that the collection and
processing processes may be synchronized. Reactor flux monitoring: Sensors (each
data flow is a sensor value) Sensor identifier and value Sensor Sensor data Process
process buffer data Mutual exclusion:

Producer processes collect data and add it to the buffer. Consumer processes take data
from the buffer and make elements available

Producer and consumer processes must be mutually excluded from accessing the
same element. The buffer must stop producer processes adding information to a full
buffer and consumer processes trying to take information from an empty buffer
System Design.

58

UNIT-V
IMPLEMENTATION & ASSURANCE
Mapping Models to code
Restructuring, optimization and coding

Transformations
1. Model transformations
2. Refactoring
3. Forward engineering

Mapping Associations

Mapping Contracts to Exceptions

Mapping Object Models to Tables

59

Activities

Developers perform transformations to the object model to improve its modularity

and performance and to transform it to the code.

Many of these activities are intellectually not challenging

They have a repetitive and mechanical flavor that makes them error prone.

Transformation Principles

Each transformation must address a single criteria

Each transformation must be local

Each transformation must be applied in isolation to other changes

Each transformation must be followed by a validation step.

Refactoring

Improving the design of existing code without affecting its external behavior

Before you start refactoring make sure that you

Test cases

A test case is a set of input data and expected results that exercises a component with
the purpose of causing failures and detecting faults.

A test case has five attributes: name, location, input, oracle, and log table.

The name of the test case allows the tester to distinguish between different test cases.

A heuristic for naming test cases is to derive the name from the requirement it is
testing or from the component being tested.

For example,
If you are testing a use case Deposit(), you might want to call the test case Test_Deposit. If a
test case involves two components A and B, a good name would be Test_AB.
The location attribute describes where table Attributes of the class TestCase.
Attributes
name

Description
Name of test case

60

location

Full path name of executable

input

Input data or commands

oracle

Expected test results against which the output of the test is

compared

log

Output produced by the test

The test case can be found. It should be either the pathname or the URL to the
executable of the test program and its inputs.

Input describes the set of input data or commands to be entered by the actor of the test
case (which can be the tester or a test driver). The expected behavior of the test case is
the sequence of output data or commands that a correct execution of the test should
yield.

The expected behavior is described by the oracle attribute. The log is a set of timestamped correlations of the observed behavior with the expected behavior for various
test runs.

Once test cases are identified and described, relationships among test cases are
identified.

Aggregation and the precede associations are used to describe the relationships
between the test cases.

Aggregation is used when a test case can be decomposed into a set of subtests.

Two test cases are related via the precede association when one test case must precede
another test case.

Test cases are classified into black box tests and white box tests, depending on which
aspect of the system model is tested.

Black box tests focus on the input/output behavior of the component.

Black-box tests do not deal with the internal aspects of the component nor with the
behavior or the structure of the components. White box tests focus on the internal
structure of the component.

A white box test makes sure that, independently from the particular input/output
behavior, every state in the dynamic model of the object and every interaction among
the objects are tested.

61

White box testing goes beyond black box testing. In fact, most of the white box tests
require input data that could not be derived from a description of the functional
requirements alone.

Unit testing combines both testing techniques: black box testing to test the
functionality of the component and white box testing to test structural and dynamic
aspects of the component.

Quality Assurance (QA)

QA is a collection of activities during software development that focus on increasing the
quality of the software being produced.
SQA includes,

Analysis, design, coding and testing methods and tools

Formal Technical reviews during software development

A multi-tiered testing strategy Control of software documentation and the changes

made to it

Procedures to ensure compliance with software development standards

Software measurement and reporting mechanisms

SQA is often conducted by an independent group in the organization Often this group
has the final veto over the release of a software product

QA Activities
1. Application of Technical Methods

Tools to aid in the production of a high quality specification

i.e. specification checkers and verifiers

Tools to aid in the production of high-quality designs

i.e. design browsers, checkers, cross-references, verifiers

Tools to analyze source code for quality

2. Formal Technical Reviews

Group analysis of a specification or design to discover errors

62

3. Software Testing
4. Enforcement of standards

Specification and design standards

Implementation standards, e.g portability

Documentation standards

Testing standards

5. Control of Change

Formal management of changes to the software and documentation

Changes require formal request to approving authority

Approving authority makes decision on which changes get implemented and when
Programmers are not permitted to make unapproved changes to the software

Opportunity to evaluate the impact and cost of changes before committing resources
Evaluate effect of proposed changes on software quality

6. Measurement

Ongoing assessment of software quality

Track quality changes as system evolves

Warn management if software quality appears to be degrading

7. Record Keeping and Reporting

Collect output and reports of SQA activities

Disseminate reports to software managers

Maintain archive of SQA reports Maintain log of software development activity

(especially testing) to satisfy legal requirements

Maintain institutional memory of the software development effort

63

64