MASENO UNIVERSITY

BSC. IN COMPUTER CSIENCE

YEAR 2 SEMESTER 2

CIR 204 OBJECT ORIENTED ANALYSIS AND DESIGN

COURSE NOTES

An Overview of Object Oriented System and Development

Introduction
 Software development is dynamic and always undergoing major changes.
 A vast number of tools and methodologies are available for system development.
 System development refers to all activities that go into producing information system
solution.
 System development activities consist of system analysis, modelling, design,
implementation, testing and maintenance.
 A software development methodology is series of processes that, if followed, can lead to
the development of an application.
 The original goal based on the system requirements.
 Object-Oriented (OO) systems development is a way to develop software by building
self-contained modules that can be more easily:
 Replaced
 Modified
 Reused.

Object Oriented System Development Methodology:

 OO development offers a different model from the traditional software development
approach. This is based on functions and procedures.
 To develop s/w by building self contained modules or objects that can be easily replaced,
modified and reused.
 In OO environment, s/w is a collection of discrete object that encapsulate their data as
well as the functionality to model real world objects
 Each object has attributes (data) and method (function).
 Objects grouped into classes and each object is responsible for itself

Benefits of Object Orientation

 Faster development,
 Reusability,
 Increased quality

1
  Object technology emphasizes modeling the real world and provides us with the stronger
equivalence of the real world‘s entities (objects) than other methodologies.
 Raising the level of abstraction to the point where application can be implemented in the
same terms as they are described.
Overview of the Unified Approach
 The UA, based on methodologies by Booch, Rumbaugh, Jacobson, and others, tries to
combine the best practices, processes, and guidelines.
 UA based on methodologies by Booch, Rumbaugh and Jacobson tries to combine the best
practices, processes and guidelines along with the object management groups in unified
modelling language.
 UML is a set of notations and conventions used to describe and model an application.
 UA utilizes the unified modeling language (UML) which is a set of notations and
conventions used to describe and model an application.

Object basic concepts:

What is an object?
 An object is an entity that has attributes and methods.
 Attributes or properties describe object‘s state (data) and methods define its behavior.

Object:
 In object-oriented system, everything is an object: numbers, arrays, records, fields, files,
forms, an invoice, etc.
 An Object is anything, real or abstract, about which we store data and those methods that
manipulate the data.
 Conceptually, each object is responsible for itself.
 A window object is responsible for things like opening, sizing, and closing itself.

Object-Oriented Approach
Object’s Attributes
 Attributes represented by data type.
 They describe objects states.
 In the Car example the car‘s attributes are:
 color, manufacturer, cost, owner, model, etc.

Object’s Methods
 Methods define objects behavior and specify the way in which an Object‘s data are
manipulated.
 In the Car example the car‘s methods are:

2
  drive it, lock it, tow it, carry passenger in it.

Objects are Grouped in Classes

 The role of a class is to define the attributes and methods (the state and behavior) of its
instances.
 The class car, for example, defines the property color.
 Each individual car (object) will have a value for this property, such as "maroon,"
"yellow" or "white."

Types of classes:
There are two main types of classes: Concrete classes and abstract classes.
 Concrete classes: A concrete class is a class that can have both subclasses and class
instances. The implementation details of the methods in a concrete class are fully defined.
The definition of a concrete class starts with the keyword class followed by the class
name
 Abstract classes: An abstract class is a class that can have subclasses but cannot have
class instances. The methods in an abstract class do not have implementation details. The
implementation details of these methods are included in the subclasses that inherit the
abstract class. The definition of an abatract class starts with the keywords abstract class
followed by the class name

Class Hierarchy
 An object-oriented system organizes classes into subclass-super hierarchy.
 At the top of the hierarchy are the most general classes and at the bottom are the most
specific
 A subclass inherits all of the properties and methods (procedures) defined in its super
class.

Motor vehicle

Bus Truck Car

3
Inheritance (programming by extension)

 Inheritance is a relationship between classes where one class is the parent class of
another (derived) class.
 Inheritance allows classes to share and reuse behaviors and attributes.
 The real advantage of inheritance is that we can build upon what we already have and,
 Reuse what we already have.

Vehicle

Car

Ford

Mustung Taurus Thunderbird

Multiple Inheritances
 OO systems permit a class to inherit from more than one super class.
 This kind of inheritance is referred to as multiple inheritance.

For example utility vehicle inherent from Bus and Truck classes.

Motor vehicle

Bus Truck Car

Utility vehicle

4
Encapsulation and Information Hiding

 Information hiding is a principle of hiding internal data and procedures of an object.

 By providing an interface to each object in such a way as to reveal as little as possible
about its inner workings.
 Encapsulation protects the data from corruption.

Possible operations
Public protocol

Private protocol

Data

Messages

Polymorphism:
 Is a mechanism that enables different methods to have the same name but different
implementations.
 During program execution, the different methods are differentiated by the method
signature (the method name and the number of arguments used during the method call)

Encapsulation:
 Is the binding together of the components of a class to make the class self contained and
provide data hiding.
 The components that are bound together are the data elements and the methods that are
used to manipulate the data.

Data abstraction:
 Is a mechanism that enables a developer to pick the most important data items of a class
and ignore the rest during program development.
 Abstraction enhances reusability of existing classes.

5
Method overloading:
 Is the ability to create different methods with the same name but different definitions.
 During program execution, each method performs its function according to its
implementation details.

Method overriding:
 This is a mechanism that allows a method that was defined in a super class to be
redefined in a subclass.
 The function of the method in the subclass will follow the new definition in the subclass.

Interface:
 An interface is a structure in object oriented programming that is defined using the
keyword interface followed by the interface name.
 An interface contains constants and abstract methods that do not have implementations.
 An interface cannot operate on its own, instead, it is implemented within a class.
 The implementation details of the abstract classes declared in the interface are defined in
the class that implements the interface.
 An interface is also used by an object as a means to communicate with other external
objects.

Message:
 Objects interact by exchanging messages.
 Objects perform operations in response to messages.
 A message is sent to another object through method call.
 The message is composed of method name and parameter value.

The Rational Unified Process

 The Rational Unified Process is a Software Engineering Process.

 It provides a disciplined approach to assigning tasks and responsibilities within a
development organization.
 Its goal is to ensure the production of high-quality software that meets the needs of its
end-users, within a predictable schedule and budget.
 The Rational Unified Process enhances team productivity, by providing every team
member with easy access to a knowledge base with guidelines, templates and tool
mentors for all critical development activities.
 The Rational Unified Process activities create and maintain models.

6
  Rather than focusing on the production of large amount of paper documents, the Unified
Process emphasizes the development and maintenance of models - semantically rich
representations of the software system under development.
 The Rational Unified Process is a guide for how to effectively use the Unified Modeling
Language (UML).
 The UML is an industry-standard language that allows clear communication of
requirements, architectures and designs.
 The Rational Unified Process captures many of the best practices in modern software
development in a form that is suitable for a wide range of projects and organizations.

Effective Deployment of 6 Best Practices

The Rational Unified Process describes how to effectively deploy commercially proven
approaches to software development for software development teams. These are called “best
practices” because they are observed to be commonly used in industry by successful
organizations. The six best practices include:

1. Develop software iteratively

2. Manage requirements
3. Use component-based architectures
4. Visually model software
5. Verify software quality
6. Control changes to software

Develop Software Iteratively

 Given today’s sophisticated software systems, it is not possible to sequentially first
define the entire problem, design the entire solution, build the software and then test the
product at the end.
 An iterative approach is required to allow an increasing understanding of the problem
through successive refinements, and to incrementally grow an effective solution over
multiple iterations.
 The Rational Unified Process supports an iterative approach to development that
addresses the highest risk items at every stage in the lifecycle, significantly reducing a
project’s risk profile.
 This iterative approach helps you attack risk through demonstrable progress frequent,
executable releases that enable continuous end user involvement and feedback.
 Because each iteration ends with an executable release, the development team stays
focused on producing results, and frequent status checks help ensure that the project
stays on schedule.

7
  An iterative approach also makes it easier to accommodate tactical changes in
requirements, features or schedule

Manage Requirements
 The Rational Unified Process describes how to elicit, organize, and document required
functionality and constraints; track and document tradeoffs and decisions; and easily
capture and communicate business requirements.
 The notions of use case and scenarios proscribed in the process has proven to be an
excellent way to capture functional requirements and to ensure that these drive the
design, implementation and testing of software, making it more likely that the final
system fulfills the end user needs.

Use Component-based Architectures

 The process focuses on early development and baselining of a robust executable
architecture, prior to committing resources for full-scale development.
 It describes how to design a resilient architecture that is flexible, accommodates change,
is intuitively understandable, and promotes more effective software reuse.
 The Rational Unified Process supports component-based software development.
Components are non-trivial modules, subsystems that fulfill a clear function.
 The Rational Unified Process provides a systematic approach to defining an architecture
using new and existing components.

Visually Model Software

 The process shows you how to visually model software to capture the structure and
behavior of architectures and components.
 This allows you to hide the details and write code using “graphical building blocks.”
 Visual abstractions help you communicate different aspects of your software; see how the
elements of the system fit together; make sure that the building blocks are consistent with
your code; maintain consistency between a design and its implementation; and promote
unambiguous communication.
 The industry standard Unified Modeling Language (UML), is the foundation for
successful visual modeling.

Verify Software Quality:

 Poor application performance and poor reliability are common factors which dramatically
inhibit the acceptability of today’s software applications.
 Hence, quality should be reviewed with respect to the requirements based on reliability,
functionality, application performance and system performance.
 The Rational Unified Process assists you in the planning, design, implementation,
execution, and evaluation of these test types.

8
  Quality assessment is built into the process, in all activities, involving all participants,
using objective measurements and criteria, and not treated as an afterthought or a separate
activity performed by a separate group.

Control Changes to Software

 The ability to manage change is making certain that each change is acceptable, and being
able to track changes is essential in an environment in which change is inevitable.
 The process describes how to control, track and monitor changes to enable successful
iterative development.
 It also guides you in how to establish secure workspaces for each developer by providing
isolation from changes made in other workspaces and by controlling changes of all
software artifacts (e.g., models, code, documents, etc.).
 And it brings a team together to work as a single unit by describing how to automate
integration and build management.

The Unified Process Overview

 The Unified process describes the object oriented system development process.
 The process can be described in two dimensions, or along two axes:
 The horizontal axis represents time and shows the dynamic aspect of the process
as it is enacted, and it is expressed in terms of cycles, phases, iterations, and
milestones.
 The vertical axis represents the static aspect of the process: how it is described in
terms of activities, artifacts, workers and workflows.

9
The Iterative Model graph shows how the process is structured along two dimensions

Phases and Iterations - The Time Dimension

This is the dynamic organization of the process along time.

The software lifecycle is broken into cycles, each cycle working on a new generation of the
product. The Rational Unified Process divides one development cycle in four consecutive phases

 Inception phase
 Elaboration phase
 Construction phase
 Transition phase

Each phase is concluded with a well-defined milestone - a point in time at which certain critical
decisions must be made and therefore key goals must have been achieved

10
The phases and major milestones in the process

Each phase has a specific purpose.

Inception Phase

 During the inception phase, you establish the business case for the system and delimit the
project scope.
 To accomplish this you must identify all external entities with which the system will
interact (actors) and define the nature of this interaction at a high-level.
 This involves identifying all use cases and describing a few significant ones.
 The business case includes success criteria, risk assessment, and estimate of the resources
needed, and a phase plan showing dates of major milestones.
The outcome of the inception phase is:
 A vision document: a general vision of the core project's requirements, key features, and
main constraints.
 An initial use-case model (10% -20%) complete.
 An initial project glossary (may optionally be partially expressed as a domain model).
 An initial business case, which includes business context, success criteria (revenue
projection, market recognition, and so on), and financial forecast.
 An initial risk assessment.
 A project plan, showing phases and iterations.
 A business model, if necessary.
 One or several prototypes.

Milestone: Lifecycle Objectives

At the end of the inception phase is the first major project milestone: the Lifecycle Objectives
Milestone.
The evaluation criteria for the inception phase are:
 Stakeholder concurrence on scope definition and cost/schedule estimates.
 Requirements understanding as evidenced by the fidelity of the primary use cases.

11
  Credibility of the cost/schedule estimates, priorities, risks, and development process.
 Depth and breadth of any architectural prototype that was developed.
 Actual expenditures versus planned expenditures.
The project may be cancelled or considerably re-thought if it fails to pass this milestone.

Elaboration Phase

 The purpose of the elaboration phase is to analyze the problem domain, establish a sound
architectural foundation, develop the project plan, and eliminate the highest risk elements
of the project.
 Architectural decisions have to be made with an understanding of the whole system: its
scope, major functionality and nonfunctional requirements such as performance
requirements.
 At the end of this phase, the decision on whether or not to commit to the construction and
transition phases is made.
 While the process must always accommodate changes, the elaboration phase activities
ensure that the architecture, requirements and plans are stable enough, and the risks are
sufficiently mitigated, so you can predictably determine the cost and schedule for the
completion of the development.
 Conceptually, this level of fidelity would correspond to the level necessary for an
organization to commit to a fixed-price construction phase.
 In the elaboration phase, an executable architecture prototype is built in one or more
iterations, depending on the scope, size, risk, and novelty of the project.
 This effort should at least address the critical use cases identified in the inception phase,
which typically expose the major technical risks of the project.
 While an evolutionary prototype of a production-quality component is always the goal,
this does not exclude the development of one or more exploratory, throwaway prototypes
to mitigate specific risks such as design/requirements trade-offs, component feasibility
study, or demonstrations to investors, customers, and end-users.
The outcome of the elaboration phase is:
 A use-case model (at least 80% complete) — all use cases and actors have been
identified, and most use case descriptions have been developed.
 Supplementary requirements capturing the non functional requirements and any
requirements that are not associated with a specific use case.
 A Software Architecture Description.
 An executable architectural prototype.
 A revised risk list and a revised business case.
 A development plan for the overall project, including the coarse-grained project plan,
showing iterations” and evaluation criteria for each iteration.
 An updated development case specifying the process to be used.

12
  A preliminary user manual (optional).

Milestone: Lifecycle Architecture

 At the end of the elaboration phase is the second important project milestone, the
Lifecycle Architecture Milestone.
 At this point, you examine the detailed system objectives and scope, the choice of
architecture, and the resolution of the major risks.
The main evaluation criteria for the elaboration phase involve the answers to these questions:
 Is the vision of the product stable?
 Is the architecture stable?
 Does the executable demonstration show that the major risk elements have been
addressed and credibly resolved?
 Is the plan for the construction phase sufficiently detailed and accurate? Is it backed up
with a credible basis of estimates?
 Do all stakeholders agree that the current vision can be achieved if the current plan is
executed to develop the complete system, in the context of the current architecture?
 Is the actual resource expenditure versus planned expenditure acceptable?
The project may be aborted or considerably re-thought if it fails to pass this milestone.

Construction Phase

 During the construction phase, all remaining components and application features are
developed and integrated into the product, and all features are thoroughly tested.
 The construction phase is, in one sense, a manufacturing process where emphasis is
placed on managing resources and controlling operations to optimize costs, schedules,
and quality.
 In this sense, the management mindset undergoes a transition from the development of
intellectual property during inception and elaboration, to the development of deployable
products during construction and transition.
 Many projects are large enough that parallel construction increments can be spawned.
These parallel activities can significantly accelerate the availability of deployable
releases; they can also increase the complexity of resource management and workflow
synchronization.
The outcome of the construction phase is a product ready to put in the hands of its end-users. At
minimum, it consists of:
 The software product integrated on the adequate platforms.
 The user manuals.
 A description of the current release.

13
Milestone: Initial Operational Capability

 At the end of the construction phase is the third major project milestone (Initial
Operational Capability Milestone).
 At this point, you decide if the software, the sites, and the users are ready to go
operational, without exposing the project to high risks.
 This release is often called a “beta” release.
The evaluation criteria for the construction phase involve answering these questions:
 Is this product release stable and mature enough to be deployed in the user community?
 Are all stakeholders ready for the transition into the user community?
 Are the actual resource expenditures versus planned expenditures still acceptable?
Transition may have to be postponed by one release if the project fails to reach this milestone.

Transition Phase

 The purpose of the transition phase is to transition the software product to the user
community.
 Once the product has been given to the end user, issues usually arise that require you to
develop new releases, correct some problems, or finish the features that were postponed.
 The transition phase is entered when a baseline is mature enough to be deployed in the
end-user domain.
 This typically requires that some usable subset of the system has been completed to an
acceptable level of quality and that user documentation is available so that the transition
to the user will provide positive results for all parties.
This includes:
 “beta testing” to validate the new system against user expectations
 parallel operation with a legacy system that it is replacing
 conversion of operational databases
 training of users and maintainers
 roll-out the product to the marketing, distribution, and sales teams

The transition phase focuses on the activities required to place the software into the hands of the
users. Typically, this phase includes several iterations, including beta releases, general
availability releases, as well as bug-fix and enhancement releases. Considerable effort is
expended in developing user-oriented documentation, training users, supporting users in their
initial product use, and reacting to user feedback. At this point in the lifecycle, however, user
feedback should be confined primarily to product tuning, configuring, installation, and usability
issues. The primary objectives of the transition phase include:
 Achieving user self-supportability

14
  Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision
 Achieving final product baseline as rapidly and cost effectively as practical

This phase can range from being very simple to extremely complex, depending on the type of
product. For example, a new release of an existing desktop product may be very simple, whereas
replacing a nation's air-traffic control system would be very complex.

Milestone: Product Release

At the end of the transition phase is the fourth important project milestone, the Product Release
Milestone. At this point, you decide if the objectives were met, and if you should start another
development cycle. In some cases, this milestone may coincide with the end of the inception
phase for the next cycle. The primary evaluation criteria for the transition phase involve the
answers to these questions:
 Is the user satisfied?
 Are the actual resources expenditures versus planned expenditures still acceptable?

Iterations
 Each phase in the Rational Unified Process can be further broken down into iterations.
 An iteration is a complete development loop resulting in a release (internal or external) of
an executable product, a subset of the final product under development, which grows
incrementally from iteration to iteration to become the final system.

Benefits of an iterative approach

Compared to the traditional waterfall process, the iterative process has the following advantages:
 Risks are mitigated earlier
 Change is more manageable
 Higher level of reuse
 The project team can learn along the way
 Better overall quality

Static Structure of the Process

A process describes who is doing what, how, and when. The Rational Unified Process is
represented using four primary modeling elements:
 Workers, the ‘who’
 Activities, the ‘how’
 Artifacts, the ‘what’
 Workflows, the ‘when’

15
Activities, Artifacts, and Workers

Workers, activities, and artifacts

Worker
 A worker defines the behavior and responsibilities of an individual, or a group of
individuals working together as a team.
 The responsibilities we assign to a worker includes both to perform a certain set of
activities as well as being owner of a set of artifacts.

People and Workers

16
Activity
An activity of a specific worker is a unit of work that an individual in that role may be asked to
perform. The activity has a clear purpose, usually expressed in terms of creating or updating
some artifacts, such as a model, a class, a plan. Every activity is assigned to a specific worker.
The granularity of an activity is generally a few hours to a few days, it usually involves one
worker, and affects one or only a small number of artifacts. An activity should be usable as an
element of planning and progress; if it is too small, it will be neglected, and if it is too large,
progress would have to be expressed in terms of an activity’s parts.
Example of activities:
 Plan an iteration, for the Worker: Project Manager
 Find use cases and actors, for the Worker: System Analyst
 Review the design, for the Worker: Design Reviewer
 Execute performance test, for the Worker: Performance Tester

Artifact
An artifact is a piece of information that is produced, modified, or used by a process. Artifacts
are the tangible products of the project, the things the project produces or uses while working
towards the final product. Artifacts are used as input by workers to perform an activity, and are
the result or output of such activities. In object-oriented design terms, activities are operations on
an active object (the worker), artifacts are the parameters of these activities.
 Artifacts may take various shapes or forms:
 A model, such as the Use-Case Model or the Design Model
 A model element, i.e. an element within a model, such as a class, a use case or a
subsystem
 A document, such as Business Case or Software Architecture Document
 Source code
 Executables

Workflows
A workflow is a sequence of activities that produces a result of observable value. In UML terms,
a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity
diagram.

Below is a form of activity diagram showing a workflow.

17
Example of workflow

Core workflows

There are nine core process workflows in the Rational Unified Process, which represent a
partitioning of all workers and activities into logical groupings.

18
The nine core process workflows

The core process workflows are divided into six core “engineering” workflows:
1. Business modeling workflow
2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow
And three core “supporting” workflows:
1. Project Management workflow
2. Configuration and Change Management workflow
3. Environment workflow

19
Although the names of the six core engineering workflows may evoke the sequential phases in a
traditional waterfall process, we should keep in mind that the phases of an iterative process are
different and that these workflows are revisited again and again throughout the lifecycle. The
actual complete workflow of a project interleaves these nine core workflows, and repeats them
with various emphasis and intensity at each iteration.
Business Modeling
One of the major problems with most business engineering efforts is that the software
engineering and the business engineering community do not communicate properly with each
other. This leads to the output from business engineering not being used properly as input to the
software development effort, and vice-versa. The Rational Unified Process addresses this by
providing a common language and process for both communities, as well as showing how to
create and maintain direct traceability between business and software models. In Business
Modeling we document business processes using business use cases. This assures a common
understanding among all stakeholders of what business process needs to be supported in the
organization. The business use cases are analyzed to understand how the business should support
the business processes. This is documented in a business object-model.

Requirements
The goal of the Requirements workflow is to describe what the system should do and allows the
developers and the customer to agree on that description. To achieve this, we elicit, organize, and
document required functionality and constraints; track and document tradeoffs and decisions.
A Vision document is created, and stakeholder needs are elicited. Actors are identified,
representing the users, and any other system that may interact with the system being developed.
Use cases are identified, representing the behavior of the system. Because use cases are
developed according to the actor's needs, the system is more likely to be relevant to the users.
The following figure shows an example of a use-case model for a recycling-machine system.

20
An example of use-case model with actors and use cases

Each use case is described in detail. The use-case description shows how the system interacts
step by step with the actors and what the system does. Non-functional requirements are described
in Supplementary Specifications. The use cases function as a unifying thread throughout the
system's development cycle. The same use-case model is used during requirements capture,
analysis and design, and test.

Analysis and Design

The goal of the Analysis and Design workflow is to show how the system will be realized in the
implementation phase. You want to build a system that:
 Performs—in a specific implementation environment—the tasks and functions specified
in the use-case descriptions.
 Fulfills all its requirements.
 Is structured to be robust (easy to change if and when its functional requirements
change).

Analysis and Design results in a design model and optionally an analysis model. The design
model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of
how the source code is structured and written. The design model consists of design classes
structured into design packages and design subsystems with well defined interfaces, representing
what will become components in the implementation. It also contains descriptions of how objects
of these design classes collaborate to perform use cases. The figure below shows part of a sample
design model for the recycling-machine system in the use-case model shown in the previous
figure.

21
Part of a design model with communicating design classes, and package group design
classes.

The design activities are centered around the notion of architecture. The production and
validation of this architecture is the main focus of early design iterations. Architecture is
represented by a number of architectural views. These views capture the major structural design
decisions. In essence, architectural views are abstractions or simplifications of the entire design,
in which important characteristics are made more visible by leaving details aside. The
architecture is an important vehicle not only for developing a good design model, but also for
increasing the quality of any model built during system development.

Implementation
The purpose of implementation is:
 To define the organization of the code, in terms of implementation subsystems organized
in layers.
 To implement classes and objects in terms of components (source files, binaries,
executables, and others).
 To test the developed components as units.
 To integrate the results produced by individual implementers (or teams), into an
executable system.

The system is realized through implementation of components. The Rational Unified Process
describes how you reuse existing components, or implement new components with well defined
responsibility, making the system easier to maintain, and increasing the possibilities to reuse.
Components are structured into Implementation Subsystems. Subsystems take the form of
directories, with additional structural or management information. For example, a subsystem can
be created as a directory or a folder in a file system, or a subsystem in C++ or Ada, or packages
using Java.

Test
The purposes of testing are:
 To verify the interaction between objects.
 To verify the proper integration of all components of the software.
 To verify that all requirements have been correctly implemented.
 To identify and ensure defects are addressed prior to the deployment of the software.

The Rational Unified Process proposes an iterative approach, which means that you test
throughout the project. This allows you to find defects as early as possible, which radically
reduces the cost of fixing the defect. Tests are carried out along three quality dimensions
reliability, functionality, application performance and system performance. For each of these

22
quality dimensions, the process describes how you go through the test lifecycle of planning,
design, implementation, execution and evaluation.

Deployment
The purpose of the deployment workflow is to successfully produce product releases, and deliver
the software to its end users. It covers a wide range of activities including:
 Producing external releases of the software.
 Packaging the software.
 Distributing the software.
 Installing the software.
 Providing help and assistance to users.
 In many cases, this also includes activities such as:
 Planning and conduct of beta tests.
 Migration of existing software or data.
 Formal acceptance.

Although deployment activities are mostly centered around the transition phase, many of the
activities need to be included in earlier phases to prepare for deployment at the end of the
construction phase. The Deployment and Environment workflows of the Rational Unified
Process contain less detail than other workflows.

Project Management
Software Project Management is the art of balancing competing objectives, managing risk, and
overcoming constraints to deliver, successfully, a product which meets the needs of both
customers (the payers of bills) and the users. This workflow focuses mainly on the specific
aspect of an iterative development process. The goal of this workflow is to make the task easier
by providing:
 A framework for managing software-intensive projects.
 Practical guidelines for planning, staffing, executing, and monitoring projects.
 A framework for managing risk.

Configuration & Change Management

In this workflow, the description of how to control the numerous artifacts produced by the many
people who work on a common project is provided. Control helps avoid costly confusion, and
ensures that resultant artifacts are not in conflict due to some of the following kinds of problems:

23
  Simultaneous Update: When two or more workers work separately on the same artifact,
the last one to make changes destroys the work of the former.
 Limited Notification: When a problem is fixed in artifacts shared by several developers,
and some of them are not notified of the change.
 Multiple Versions: Most large programs are developed in evolutionary releases. One
release could be in customer use, while another is in test, and the third is still in
development. If problems are found in any one of the versions, fixes need to be
propagated between them. Confusion can arise leading to costly fixes and re-work unless
changes are carefully controlled and monitored.

This workflow provides guidelines for managing multiple variants of evolving software systems,
tracking which versions are used in given software builds, performing builds of individual
programs or entire releases according to user-defined version specifications, and enforcing site-
specific development policies. You describe how you can manage parallel development,
development done at multiple sites, and how to automate the build process. This is especially
important in an iterative process where you may want to be able to do builds as often as daily,
something that would become impossible without powerful automation. You also describe how
you can keep an audit trail on why, when and by whom any artifact was changed. This workflow
also covers change request management, i.e. how to report defects, manage them through their
lifecycle, and how to use defect data to track progress and trends.

Environment
The purpose of the environment workflow is to provide the software development organization
with the software development environment—both processes and tools—that are needed to
support the development team. This workflow focuses on the activities to configure the process
in the context of a project. It also focuses on activities to develop the guidelines needed to
support a project. A step-by-step procedure is provided describing how you implement a process
in an organization. The environment workflow also contains a Development Kit providing you
with the guidelines, templates and tools necessary to customize the process.

Overview of modeling: notations, and standards

OBJECT ORIENTED METHODOLOGIES

Basic Definition
 A methodology is explained as the science of methods.
 A method is a set of procedures in which a specific goal is approached step by step.
 Many methodologies are available to choose from for system development.

24
  The methodologies developed by Rumbaugh et al., Booch, and Jacobson are the origins
of the Unified Modeling Language (UML) and the bases of the UA

Strength of the Methods

• Rumbaug : Describing Object Model or the static structure of the system

• Jacobson: good for producing user-driven analysis models

• Booch : Detailed object-oriented design models

Rumbaugh Methodologies OMT (Object Modeling Technique) describes a method for the
analysis, design, and implementation of a system using an object-oriented technique. Class
attributes, method, inheritance, and association also can be expressed easily.
Phases of OMT
 Analysis
 System Design
 Object Design
 Implementation

OMT consists of four phases, which can be performed iteratively:

 Analysis. The results are objects and dynamic and functional models.
 System design. The result is a structure of the basic architecture of the system.
 Object design. This phase produces a design document, consisting of detailed objects and
dynamic and functional models.
 Implementation. This activity produces reusable, extendible, and robust code.

OMT Modeling OMT separates modeling into three different parts:

 An object model, presented by the object model and the data dictionary.
 A dynamic model, presented by the state diagrams and event flow diagrams.
 A functional model, presented by data flow and constraints.

Booch Methodology
 The Booch methodology covers the analysis and design phases of systems development.
 The Booch method consists of the following diagrams:
1. Class diagrams
2. Object diagrams
3. State transition diagrams
4. Module diagrams

25
 5. Process diagrams
6. Interaction diagrams

• The Booch methodology prescribes

o A macro development process
o A micro development process.
The Macro Development Process
It serves as a controlling framework for the micro process. The primary concern is Technical
Management of the System. The macro development process consists of the following steps:
1. Conceptualization
2. Analysis and development of the model.
3. Design or create the system architecture.
4. Evolution or implementation.
5. Maintenance.

Conceptualization:
• Establish the core requirements of the system
• Establish a set of goals and develop prototype to prove the concept

Analysis and development of the model

• Using the class diagram to describe the roles and responsibilities the objects are to carry out in
performing the desired behavior of the system
• Using the object diagram to describe the desired behavior of the system in terms of scenarios
or, alternatively
• Using the interaction diagram to describe behavior of the system in terms of scenarios

Design or create the system architecture

• Using the class diagram to decide what mechanisms are used to regulate how objects
collaborate
• Using the module diagram to map out where each class and object should be declared
• Using the process diagram to determine to which processor to allocate a process. Also,
determine the schedules for multiple processes on each relevant processor

Evolution or implementation
• Successively refine the system through many iterations.
• Produce a stream of software implementations, each of which is refinement of the prior one

26
Maintenance
• Make localized changes to the system to add new requirements and eliminate bugs

The Micro Development Process

• The micro development process consists of the following steps:
• Identify classes and objects.
• Identify class and object semantics.
• Identify class and object relationships.
• Identify class and object interfaces and implementation.

Jacobson Methodologies The Jacobson et al. methodologies (e.g., OOBE, OOSE, and
Objectory) cover the entire life cycle and stress traceability between the different phases.

Object-Oriented Software Engineering: Objectory

• Object-oriented software engineering (OOSE), also called Objectory, is a method of object-
oriented development with the specific aim to fit the development of large, real-time systems.

• Objectory is built around several different models:

1. Use case model.
2. Domain object model.
3. Analysis object model.
4. Implementation model.
5. Test model

Object-Oriented Business Engineering (OOBE)

 Object-oriented business engineering (OOBE) is object modeling at the enterprise level.
 Use cases again are the central vehicle for modeling, providing traceability throughout
the software engineering processes.
• OOBE consists of:
o Analysis phase
o Design
o Implementation phases and
o Testing phase.

Patterns
• A pattern is an instructive information that captures the essential structure and insight of a
successful family of proven solutions to a recurring problem that arises within a certain context
and system of forces.

27
• The main idea behind using patterns is to provide documentation to help categorize and
communicate about solutions to recurring problems.
• The pattern has a name to facilitate discussion and the information it represents.
• A good pattern will do the following:
1. It solves a problem. Patterns capture solutions, not just abstract principles or strategies.
2. It is a proven concept. Patterns capture solutions with a track record, not theories or
speculation.
3. The solution is not obvious. The best patterns generate a solution to a problem
indirectly—a necessary approach for the most difficult problems of design.

4. It describes a relationship. Patterns do not just describe modules, but describe deeper
system structures and mechanisms.
5. The pattern has a significant human component.
6. All software serves human comfort or quality of life; the best patterns explicitly appeal to
aesthetics and utility.

Frameworks
• A framework is a way of presenting a generic solution to a problem that can be applied to all
levels in a development.

• A single framework typically encompasses several design patterns and can be viewed as the
implementation of a system of design patterns.

Differences Between Design Patterns and Frameworks

• Design patterns are more abstract than frameworks.
• Design patterns are smaller architectural elements than frameworks.
• Design patterns are less specialized than frameworks.

The Unified Approach (UA)

• The main motivation of UA is to combine the best practices, processes, methodologies, and
guidelines along with UML notations and diagrams.
• The unified approach to software development revolves around (but is not limited to) the
following processes and components:

• Use-case driven development.

• Object-oriented analysis.
• Object-oriented design.

28
• Incremental development and prototyping.
• Continuous testing.

UA Methods and Technology

• Unified modeling language (UML) used for modeling.
• Layered approach.
• Repository for object-oriented system development patterns and frameworks.
• Promoting Component-based development.

UA Object-Oriented Analysis: Use-Case Driven

• The use-case model captures the user requirements.
• The objects found during analysis lead us to model the classes.
• The interactions between objects provide a map for the design phase to model the relationships
and designing classes.

UA Object-Oriented Design
• Booch provides the most comprehensive object-oriented design method.
• However, Booch methods can be somewhat imposing to learn and especially tricky to figure
out where to start.
• UA realizes this by combining Jacobson et al.'s analysis with Booch's design concept to create
a comprehensive design process.

Iterative Development and Continuous Testing

• The UA encourages the integration of testing plans from day 1 of the project.
• Usage scenarios or Use Cases can become test scenarios; therefore, use cases will drive the
usability testing.

Modeling Based on the Unified Modeling Language

• The UA uses the unified modeling language (UML) to describe and model the analysis and
design phases of system development.

29
Unified Modeling Language (UML)

A model is an abstract representation of a system, constructed to understand the system prior to

building or modifying it. Most of the modeling techniques involve graphical languages.

Static or Dynamic Models

Static Model Dynamic Model

• A static model can be viewed as • Is a collection of procedures or behaviors

"snapshot" of a system's parameters at rest that, taken together, reflect the behavior of
or at a specific point in time. a system over time.
• The classes‘structure and their • For example, an order interacts with
relationships to each other frozen in time inventory to determine product availability.
are examples of static models.

Why Modeling?
o Models make it easier to express complex ideas.
o For example, an architect builds a model to communicate ideas more easily to clients.

Advantages of Modeling
 Models reduce complexity by separating those aspects that are unimportant from those
that are important.
 Models enhance learning.
 The cost of the modeling analysis is much lower than the cost of similar experimentation
conducted with a real system.
 Manipulation of the model (changing variables) is much easier than manipulating a real
system.

Modeling Key Ideas

 A model is rarely correct on the first try.
 Always seek the advice and criticism of others.

30
  Avoid excess model revisions, as they can distort the essence of your model. Let
simplicity and elegance guide you through the process.

What Is the UML?

The Unified Modeling Language (UML) is a language for

Specifying
Visualizing
Constructing
Documenting
the software system and its components.

UML is
• A way to describe your software
• more precise than English
• less detailed than code

UML is used to:

 Trace external interactions with the software
 Plan the internal behavior of the application
 Study the software structure
 View the system architecture
 Trace behavior down to physical components

31
SYMBOLS COMMONLY USED IN UML AND THEIR MEANIGS

Symbol Meaning

Use case: Defines what the user should achieve from the system
Class name Class diagram: Represents classes forming the system
Attributes
Methods
Class:Object
Object diagram: Represents the objects of the system
Attributes

System boundary: Encloses all the components of the system

Package: Used to group system components

Activity: Represent the action to be taken in activity diagram

State name
State symbol: Represents the state of an object after an event has occurred
State variables
Association: Represent the relationship between any two interacting objects
Activities
Generalization: Represents inherence relationship

Aggregation: Represents part-whole relationship where part component can exist on its own

Composition: Represents part-whole relationship where part component cannot exist on its own

Dependency: Defines a relationship where a base use case depends on another use case to operate.

Asynchronous: A form of communication where feedback is not required for communication to

continue.

Synchronous: A form of communication where feedback is required for communication to continue.

Simple: A straightforward transfer of control

Start of state or activity diagram.

End of state or activity diagram

<< >> Stereotype: Label attachments that add extra classification to model items

Actor: Anything that interacts with the system to achieve given objectives

32
UML Diagrams

The UML defines nine graphical diagrams:

1. Class diagram (static)
2. Use-case diagram
3. Behavior diagrams (dynamic):
3.1. Interaction diagram:
3.1.1. Sequence diagram

3.1.2. Collaboration diagram

3.2. State chart diagram

3.3. Activity diagram

4. Implementation diagram:

4.1. Component diagram

4.2. Deployment diagram

Diagrams Are Views of a Model

Use case Class Object

Diagrams Diagrams Diagrams

Activity
State
Diagrams
Diagrams
Model
Sequence
Component
Diagrams
Diagrams
Collaboration Deployment

Diagrams Diagram

33
Use Case Diagram

 A use case represents the functionality that a user should achieve from the system being
developed.
 Use case diagrams are created to visualize the relationships between actors and use cases
 An actor is someone or something that must interact with the system under development
 A use case is a pattern of behavior the system exhibits
 Use cases are written from an actor point of view
 The diagram below shows a use case diagram for an ATM cash system.
 The diagram has one actor represented by Client and three use cases namely: Withdraw
money, Transfer money and check money.

Transfer Money

Withdraw Money Check Money

Client

 For a given use case to be realized by an actor, some steps must be followed. These
steps are called use case scenarios.

If we take Withdraw money use case from the above diagram, the use case scenarios will be:

 Customer puts card into machine and enters PIN number

 The machine reads the card and checks the PIN number in its database
 The PIN is confirmed
 The machine asks the customer which service they want: Withdraw money, Transfer
money or check money.
 The customer chooses withdraw money and specifies how much.
 The machine checks that the customer has enough money in their account.

34
  The customer has enough money, so the machine returns the customer’s card.
 The money is dispensed through the slot in the front of the machine.

An example of use case analysis of an Online system

Connect externally
System administrator

Provides security levels

Use email Clerical staff

Store files

Project manager
Access company documents

Share printers
Marketing manager

Connect to internet

Online shopping
Sales representative

If we take online shopping use case, the scenarios are:

 The customer browses the online catalogue and selects the items that he/she would like
to purchase
 These items are added to the shopping basket.
 When the customer has finished browsing and wishes to pay, the customer then enters
the credit card details and decides how goods should be delivered.
 The system checks the authorization on the credit card and confirms the sale both
immediate and by email.

35
Relationships

Relationships may exist between use cases themselves, as well as between

actors and use cases. There are four types of use case to use case
relationships:

 Inclusion;
 Generalisation;
 Extension;
 Grouping.

Inclusion Use Case

If you find that some behaviours are being repeated in two or more sections, the
UML provides a solution to avoid repetition. Inclusion allows developers to
create use cases that can simply be referred to each time they are needed,
rather than laborious rewriting or a lot of cut and pasting. Apart from the time
saved, another advantage of this approach is that the developer can make
changes to one particular use case. If the behaviour had been repeatedly
rewritten, the amendments would also need to be rewritten by hand for each
occurrence. Inclusion use cases are dependent on the use case that contains
them. They therefore cannot be used on their own, and must be used in
conjunction with the use case that includes them.

Example
You may find that if you were designing a drinks machine, you would need to
follow a distinct sequence of events every time you needed to restock or service
the machine. The following steps could be used to create an open machine use
case, which would form the basis of other use cases, such as a refill machine
.

Open machine inclusion use case.

 Unlock the machine.

 Enter a security code.
 Open the door.

36
 <<Include>>
Restock the
drinking machine Open machine

<<extend>> <<Include>>

Close machine
Restock according
to best seller

A use case diagram showing extension and inclusion relationships

Notation for stereotype: Stereotype is a label attachment that adds extra classification to
model items. The symbolic representation of a stereotype is << >>. E.g. <<include>>,
<<extend>>, <<interface>>.

Generalization use case

Use cases can inherit behavior and meaning from parents in the same way that
classes can. This type of modification is known as generalization.

Example1
For instance, you may already have a use case for buying a drink that you could add
behaviors to. The buy a drink use case could then be used as the parent for buy a glass
of drink. The generalization could then add steps for adding mixers, ice and lemon in a
child use case.

Steps from buy drink use case:

 Add tonic or bitter lemon

 Add ice
 Add lemon

37
Example2
If there are three use cases: order shoes, order books and order goods. These use
cases can be represented by a generalization relationship as follows:

Order goods

Order books Order shoes

Generalization relationship

Extension Use Case

You may find that you need to make additions to your standardized or base use
case. The base use case can therefore be extended to form the basis of new
use cases. The person who maintains the machine may find that there are
certain types of drink that are most commonly bought. The supplier may decide
to increase the number of cans of these brands, and no longer stock the less
popular brands. The use case for restocking the machine could be extended to
allow for restocking according to demand. Extension use cases only occur at
specified points within the base use case’s sequence. The points where
extensions occur are called extension points.

Example of Base Use Case

 Browse items online.
 Make selection and add to shopping basket.
 Go to checkout.
 Log on to account.
 Verify account details.
 Verify items in shopping basket.
 Final confirmation.
 Place order.

38
Example of Extension Use Case
Someone wishing to buy items from an online shop must log on to the system,
and provide their account details. These will link the billing and delivery details
for the customer with the items in the shopping basket. New customers however,
will not have an existing account with the company, and will need to create one
before they can complete their order. The extension point occurs at log on to
account.

 Enter name.
 Enter address and telephone number.
 Enter email address.
 Enter password.
 Confirm password
 Enter payment details

Purchase items <<Include>>

Log onto Account

<<Extend>>

Create Account for

new user

A use case diagram showing extension relationship

Grouping Use Cases

The developer may find it helpful to organize use cases, if there are several in
existence. It may be that the system is comprised of several subsystems, or the
client is being interviewed about the system requirements. Each system
requirement would be a discrete use case, and it may prove useful to be able to
organize and categorize these requirements.

39
Grouping Notation

The notation for grouping use cases is to simply include them inside a package,
as shown in Figure below

Customer
Browse Catalogue
Log onto system

Add to shop basket

Check order status

Buy goods

An example of a customer package

Business and System Use Cases

These two types of use case are concerned with two different aspects of system
design. Business use cases are concerned with how a business responds to a
particular customer or event, whereas system use cases are concerned with the
interaction between the system or software and the user.

A business use case can be useful when considering how to meet an actor’s
goal, for example, how best to allow the customer to buy the goods they desire.
Sometimes it is more productive to change the business practice to a solution to
a problem, rather than try to change the system to accommodate the problem.
A system use case is more useful for planning the system, and is concerned with how
the system behaves in particular scenarios. For each business use case that has been
identified, there should follow a set of system use cases.

40
Class Diagrams

 A class diagram describes the types of objects in the system and the various kinds of
static relationships that exist among them.
 A class diagram is a graphical representation of a static view on declarative static
elements.
 A class diagram shows the existence of classes and their relationships in the logical view
of a system

Essential Elements of a UML Class Diagram

 Class
 Attributes
 Operations
 Relationships
 Associations
 Generalization
 Dependency
 Realization

Constraint Rules and Notes

A class is the description of a set of objects having similar attributes, operations, relationships
and behavior.

Class name Window Window

Window
size : Size size : Size
Attributes visibility: Boolean visibility: Boolean
No inference can be
display() drawn about the presence
Operations
or absence of elements in
hide()
a missing compartment

41
Attributes
 Classes have attributes that describe the characteristics of their objects.
 Attributes are atomic entities with no responsibilities.
 Attribute syntax (partial):
o [visibility] name [ : type ] [ = defaultValue ]
 Class scope attributes are underlined

Visibility
• Visibility describes whether an attribute or operation is visible and can be referenced from
classes other than the one in which they are defined.
• Language dependent
o Means different things in different languages
• UML provides four visibility abbreviations: + (public) – (private) # (protected) ~ (package)

UML modeling elements in class diagrams

• Classes and their structure, association, aggregation, dependency, and inheritance relationships
• Multiplicity and navigation indicators, etc.

Associations
• A semantic relationship between two or more classes that specifies connections among their
instances.
• A structural relationship, specifying that objects of one class are connected to objects of a
second (possibly the same) class.
• Example: “An Employee works for a Company”
• An association between two classes indicates that objects at one end of an association
“recognize” objects at the other end and may send messages to them.
• This property will help us discover less trivial associations using interaction diagrams
42
 Role name
Association name

Instructor Instructs
StaffMembers Student
1..* *
Role
Multiplicity
Navigable (Uni-
directional)
association *
Prerequisites
Courses

0..3
Reflexive
Association

Aggregation

 It is a special form of association that models a whole-part relationship between an

aggregate (the whole) and its parts.
 The part component can exist on its own

2..* 1..*
Car Door House

Whole Part

Composition

 It is a relationship in which the components of the class they constitute are in a part-
whole association.
 It is represented as a hierarchy with the whole class at the top and the components
below.
 Each part component must belong to the whole
 Each part component cannot exist on its own

43
 Coin

Tail Head

Generalization

Generalization indicates inheritance relationship. A sub-class inherits from its super-class. A

generalization relationship may not be used to model interface implementation.

Shape

(Abstract)

Draw(){abstract}

Circle Rectangle

draw() draw()

Dependency

A dependency is a relation between two classes in which a change in one may force changes in
the other although there is no explicit association between them. A stereotype may be used to
denote the type of the dependency.

44
 <<Friends>>
Iterator Vector

Realization

A realization relationship indicates that one class implements a behavior specified by another
class (an interface or protocol). An interface can be realized by many classes. A class may realize
many interfaces.

LinkedList <<Interface>> LinkedList

List
List

Object Diagrams

An object diagram represents an instance of a class. The name is represented as

ClassName:ObjectName. The object diagram contains attributes and not methods because the
methods are assumed to be automatically inherited from the class.

Class diagram Object diagram

Student Student:Student1

RegistrationNumber RegistrationNumber=”BBIT 001/2013 ”

Name Name=”Ken Nyabuto”

Course Course=”BBIT”

AverageMarks AverageMarks=78
SetDetails( )
Grade Grade=’A’
getDetails( )

printDetails( )

45
Differences between class diagram and an object diagram

Class diagram Object diagram

The class has three compartments: name, The object has only two compartments:
attribute, and operation name and attribute
The class name stands a lone in the class The format for an object name is: Object
name compartment name, colon, class name, with the entire
expression underlined.
The class attribute compartment defines the The object defines only the current value of
properties of the attributes each attribute for the test or example being
modeled.
Operations are listed in the class Operations are not included in the object
because they would be identical for each
object of the same class
The classes are connected with an The objects are connected with a link that
association with a name, multiplicity, has a name and no multiplicity. All links
constraints, and roles. Classes represent a are one-to-one, so multiplicity is irrelevant.
“classification” of objects, so it is Roles may be used on links.
necessary to specify how many may
participate in the association

Interactive Diagrams

Interaction diagrams describe how groups of objects collaborate to get the job done. Interaction
diagrams capture the behavior of a single use case, showing the pattern of interaction among
objects. The purpose of Interaction diagrams is to:
 Model interactions between objects
 Assist in understanding how a system (a use case) actually works
 Verify that a use case description can be supported by the existing classes
 Identify responsibilities/operations and assign them to classes

Interaction diagrams include: Sequence diagrams and Collaboration diagrams

Sequence Diagrams

46
Sequence diagram show how objects in the system will interact with each other. An object is an
instance of a class, that is, it is an occurrence of a class. For example a teacher is an instance of a
human being class. Taking a microwave oven as example: A microwave has a number of
components including: A timer, heating element and a turn table. The use case for cooking food
in the microwave involves the following steps:
 The timer is set for a number of minutes
 The turntable rotates
 The heating element is activated to cook the food
 The timer reaches the end of its set time
 The turntable stops rotating
 The heating element is turned off

:Timer :Heating element :Turntable

Set time

Press start Turn on turntable

Turn on heating
element

Keep
Time
Keep
rotating
15 minutes rotating

Turn off heating

element

Turn off turntable

Sequence diagrams come in two forms to deal with real life scenarios: the first deals
with an action in which one scenario, and only one scenario, is possible. This is known
as an instance sequence diagram. The second deals with actions, following which a
number of scenarios can occur. This is known as a generic sequence diagram. It is
probably useful to remember that for every use case, a sequence diagram is used to

47
illustrate the activities, sequence and relationships therein.

A real life example serves to illustrate the difference. When a bank customer
attempts to draw money from a cashpoint terminal, there are two possible
scenarios. The first is that in which everything happens as it should. His/her card
is inserted, the PIN number is checked, the card is checked for validity, the bank
balance is checked to see if sufficient funds are available to cover the withdrawal
amount, the cash dispenser checks to see it has sufficient funds of the selected
denomination and the cash is then dispensed.

In an ideal world, all of the above would be correct and could be considered a
unique instance, and an instance sequence can occur.

The sequence follows the following steps:

a. The customer inserts his/her cashpoint card into the card slot.
b. The PIN number is entered and the amount of money required selected.
c. The account is checked for available funds.
d. The dispenser is checked for available funds of the correct denomination.
e. Assuming everything is correct, the card is ejected.
f. The correct amount of cash is dispensed through the cash slot.

An instance sequence diagram modelling this ideal scenario is shown in Figure below.

48
 :CashPoint Panel :Register :Dispenser

Insert(Input)

Select(Amount) Send(Input, Amount)

Send(Amount)

Deliver(Amount)

The instant sequence diagram modeling the best case scenario

If the situation turns out to be less than ideal and a number of eventualities could
prevent the cash being issued to order. For example:

 If the PIN number is incorrect.

 If the customer’s bank account does not contain adequate funds.
 If the bank’s funds do not cover the amount of cash requested.

These situations are catered for and are modelled as a generic sequence
diagram, as shown in Figure below.

49
 :CashPoint Panel :Register :Dispenser

Insert(Input) [Input=PIN] Check(PIN)

[PIN=OK] Request( Amount)

Select(Amount) [Pin Not OK] Display(Message)

Send(Amount) [Amount<Funds] Check(Cashstore)

[Amount>Funds] Display (message)

[CashStore>Amount] Disense(Amount)

[CashStore<Amount] Display (message)

The generic sequence diagram modeling multiple scenarios

Collaboration Diagrams

Collectively, the objects which interact to perform some task, together with the links between
them, are known as a collaboration
 Objects: Each object is shown as a circle or a rectangle, which is labeled as objectName:
className
 Links: Links between objects are shown like associations in the class model.
 Actors: Actors can be shown as on a use case diagram

A collaboration diagram represents a set of objects related in a particular context, and the
exchange of their messages to achieve a desired outcome.
 Used for design of: components, object, subsystems
 Diagrams show entity event responses
 Event is equivalent to receiving a message

50
 :Name1

1:Add( )

3:Update( )

:Name3 :Name2

2:Modify( )

The collaboration diagram can deal with conditions in the same way that the
sequence diagrams do. Remember, the process still has to be addressed
sequentially and to address this, the messages are numbered sequentially.
Examining the example of the ‘best case’ scenario for the cashpoint machine,
i.e. the customer puts in his/her card and withdraws the cash amount required,
the collaboration diagram would look as in Figure below.

51
 Insert(Input, amount)

:Cashpoint Panel

1:add(input, amount)
3:deliver(amount)

:Dispenser :Register

2:deliver(amount)
Collaboration diagram for best case scenario cash withdrawal

Conditions are represented in the same way as in the sequence diagram by putting
them inside square brackets and following this with the message label. The example of
the cashpoint machine illustrates the use of sequence numbering and also the use of
conditions. In this example, the following conditions have to be considered:
 The PIN number is incorrect.
 The customer’s bank account does not contain adequate funds.
 The bank’s funds do not cover the amount of cash requested.
If the PIN number is wrong, the step in which a message is displayed on the
front panel needs to be added, along with the conditions. If the funds in the
customer’s account do not cover the withdrawal amount, a step to send a
different message to the front panel is included (again with the necessary
conditions). Finally, if the cash held in the cashpoint (the cashstore) does not
cover the cash required, a further step needs to be added to send another
message to the front panel. The collaboration diagram to model this example
with the conditions stated, is shown in Figure below.

52
 Insert(Input,amount)

:Cashpoint Panel
1:add(input,amount)

[PIN = OK]4: send(amount)

7:Dispense(amount) [PIN = OK]3.1: request(amount)

[PIN Not OK]3.2: display(message)
[amount > funds]5.2: display(message)
[cashstore < amount]6.2:display(message)

:Dispenser :Register

[Input = PIN] 2: Check(PIN)

[amount < funds]5.1: check(cashstore)
[cashstore > amount]6.1: dispense(amount)

Collaboration diagram for multiple conditions at cash point machine

Note: After any condition statement, the number before the decimal point
sequentially states the sequence and the number after the decimal point states
the alternative branches that can be taken when the condition statement is
checked. This is called nesting.

Active object

It may be necessary for a specific object to control the flow and interacts with
other passive objects to maintain the workflow. This object is referred to as an
active object and is shown in the collaboration diagram as a rectangle, but to
differentiate it from the passive objects, the rectangle’s border is made bold. As
an example, an office typing pool has an administrator whose job it is to receive
incoming work and allocate it to the typists. The collaboration diagram is shown
in Figure below with the administrator shown as an active object.

53
 3:do(Letter)
:Administrator :Typist

1:TypingRquest(Letter) 4:lookup(Report)
5:return(Report)
2:getRquest(Report)

5:return(Report)

:Manager :Typist

Collaboration diagram highlighting an active object

Synchronization
Synchronization arises when an object can only send a message when, and only when,
several other messages have been sent. In effect, it has to synchronize its message
along with a set of other messages. As a practical example to demonstrate this, a house
building company has the following process in place for building a new housing estate:

a) The architect who has designed the estate, asks the quantity surveyor to
calculate the materials and labour to be used.
b) The quantity surveyor asks the construction manager to produce a bill of
materials to collate all the materials required.
c) The construction manager asks the buyer to obtain quotations for the
materials from a local supplier.
d) The buyer asks the local supplier for a quotation.
e) After the construction manager has produced a bill of materials, the
accounts department requires a copy to budget for the development.

The key point here is that step e) cannot be undertaken until steps b) and have been
completed. In other words, the system needs to synchronize. The collaboration diagram
syntax is to show step e) as a separate process. This time, instead of preceding the
message with a number, it is preceded with a list of the messages that have to be
completed before step e) can take place. A comma separates one list item from another
and the list ends with a slash (/). The diagram in Figure below illustrates this scenario.

54
 1:calculate(materials,estate)
:Architect

:QuantitySurveyor
2:assign(materials,estate)

:ContsructionManager

:Accountant 3:requestQuotation(materials,estate)

:Buyer
2,3/calculateBudget(materials,estate)

:Budget
*[Suppliers] 4:getQuotation(materials,estate)
:Supplier

Synchronization between objects in a collaboration diagram

Packages

A package is a general purpose grouping mechanism. A package can be used to group any UML
element (e.g. use case, actors, classes, components and other packages. Commonly used for
specifying the logical distribution of classes. A package does not necessarily translate into a
physical sub-system.

Name

55
Packages and Class Diagrams
• Emphasize the logical structure of the system (High level view)

c a

Emphasize the interface between packages by showing relations and dependencies between
public classes. Add package information to class diagrams

State Diagram
A statechart diagram (also called a state diagram) shows the sequence of states that an object
goes through during its life in response to outside stimuli and messages. A statechart diagram is a
view of a state machine that models the changing behavior of a state. Statechart diagrams show
the various states that an object goes through, as well as the events that cause a transition from
one state to another.

State chart diagram model elements

The common model elements that state chart diagrams contain are:
 States
 Start and end states
 Transitions
 Entry, do, and exit actions

A state represents a condition during the life of an object during which it satisfies some
condition or waits for some event. Start and end states represent the beginning or ending of a
process. A state transition is a relationship between two states that indicates when an object
can move the focus of control on to another state once certain conditions are met.

56
Actions in a Statechart diagram
 Each state on a state chart diagram can contain multiple internal actions.
 An action is best described as a task that takes place within a state.
 There are four possible actions within a state:
 On entry
 On exit
 Do
 On event

State symbol Transition

symbol
Name

State variables

Activities

End point of a
Starting point
Activities sequence
of a sequence

Activity Diagram
• Activity Diagram is a special kind of Statechart diagram, but showing the flow from activity to
activity (not from state to state).

• Activity is an ongoing non-atomic execution within a state machine. Activities ultimately result
in some action.
– A real world process or execution of a software routine
• Action is made up of executable atomic computations that result in a change in state of the
system or the return of a value (i.e., calling another operation, sending a signal, creating or
destroying an object, or some pure computation).

Activity diagrams commonly contain:

• Activity states and action states
• Transitions
• Objects

57
Action states - executable, atomic computations (states of the system, each representing the
execution of an action) – cannot be decomposed.

Activity states – non-atomic; can be further decomposed; can be represented by other activity
diagrams – a composite whose flow of control is made up of other activity states and action
states

Activity diagram for building construction

Select site

Commission architect

Develop plan

Bid plan

[not accepted]

[else]

Do site work Do trade work

:CertificateOfOccupancy
Finish construction

[completed]
An

Activity diagram to compute the sum of a mathematical series

The series is calculated by the sum of the previous two numbers in a number series to
arrive at the next number. The first two calculations automatically become 1, as there
are not two numbers before them. The next number is 2, so the calculation can be

58
performed, i.e. 1+2=3, and the next becomes 3+2=5 and then 5+3=8. The resulting
series is: 1,1,2,3,5,8,13,21…and so on. The operation activity diagram is shown in
Figure 5.61.

Activity diagram to compute the sum of a mathematical series

Format:
calculateNumber(n)
“The” Counter “th
Number is:” Answer
Answer1:=1

Counter:=1

[n=1] Print(Answer,counter)
Answer:=Answer1

[n>1]

Answer2:=1

Counter:=2

[n=2]
Answer:=Answer2

[n>2]

Answer:=Answer1+Answer2

Counter:=Counter+1

mm

[n>counter]

Answer1:=Answer2

Answer2:=Answer

59
Component Diagram

Component diagrams, along with deployment diagrams are solely concerned with the
development of computer systems. Modern development processes use components, which is
an important aspect in projects that rely on a team for development. A component can be a
table, data file, executable program and many other things. If a Student class represents an
abstract form of a set of attributes and behaviors, then Undergraduate class or Postgraduate
class represents component diagram implementation of a software of Student class e.g
Undergraduate.exe (a software executable of Undergraduate class).

Undergraduate.exe

Deployment Diagram

Deployment diagram shows the configuration of run-time processing elements and the
software processes living on them. The deployment diagram visualizes the distribution of
components across the enterprise

OBJECT ORIENTED ANALYSIS

60
Object oriented analysis involves:

 Identifying Use cases

 Object Analysis - Classification
 Identifying Object Relationships, Attributes and Methods

Identifying Use Cases

The use-case approach to object-oriented analysis and the object-oriented analysis process.
 Identifying actors.
 Identifying use cases.
 Documentation.

Analysis
Analysis is the process of transforming a problem definition from a fuzzy set of facts and myths
into a coherent statement of a system‘s requirements. The main objective of the analysis is to
capture:
 a complete, unambiguous, and consistent picture of the requirements of the system and
 what the system must do to satisfy the users' requirements and needs.

Requirements Difficulties
Three most common sources of requirements difficulties are:
1. Incomplete requirements.
2. Fuzzy descriptions (such as fast response).
3. Unneeded features.

The Object-Oriented Analysis (OOA) Process

The process consists of the following steps:
1. Identify the actors:
i) Who is using the system?
ii) Or, in the case of a new system, who will be using the system?
2. Develop a simple business process model using UML activity diagram.
3. Develop the use case:
a) What the users are doing with the system?
b) Or, in the case of a new system, what users will be doing with the system? Use cases
provide us with comprehensive documentation of the system under study.

4. Prepare interaction diagrams:

61
  Determine the sequence.
 Develop collaboration diagrams

5. Classification—develop a static UML class diagram:

 Identify classes.
 Identify relationships.
 Identify attributes.
 Identify methods.

6. Iterate and refine: If needed, repeat the preceding steps.

Develop Develop Identify Refine

Use case Interaction Classes, and
diagrams Diagrams Relationships iterate
, Attributes
and methods
Prototyping
Identify actors

O-O Analysis

Developing Business Processes Modeling

Develop an activity diagram of the business processes that can provide an overall view of the
system.

62
Use Case Model

Use cases are scenarios for understanding system requirements. The use-case model describes
the uses of the system and shows the courses of events that can be performed. Use case
defines what happens in the system when a use case is performed. The use-case model tries to
systematically identify uses of the system and therefore the system's responsibilities.

"A Use Case is a sequence of transactions in a system whose task is to yield results of
measurable value to an individual actor of the system."

Use Case Key Concepts

 Use case: Use case is a special flow of events through the system.
 Actors: An actor is a user playing a role with respect to the system.
 In a system: This simply means that the actors communicate with the system's use case.
 A measurable value: A use case must help the actor to perform a task that has some
identifiable value.
 Transaction. A transaction is an atomic set of activities that are performed either fully or
not at all.

Use Associations
The use association occurs when you are describing your use cases and notice that some of them
have common subflows. The use association allows you to extract the common subflow and
make it a use case of its own.

Extends Associations
The extends association is used when you have one use case that is similar to another use case
but does a bit more or Is more specialized; in essence, it is like a subclass.

63
 Library

Borrow books Uses

Checking library
Extends card
Uses
Inter library loan

Return books

Calculation
Performing search clerk
Member
Reading books and
news paper

Supplier
Purchasing supplies

Types of Use Cases

 Use cases could be viewed as concrete or abstract.
 An abstract use case is not complete and has no initiation actors but is used by a concrete
use case, which does interact with actors.

Identifying the Actors

i) The term actor represents the role a user plays with respect to the system.
ii) When dealing with actors, it is important to think about roles rather than
people or job titles.
iii) Who affects the system? Or,
iv) Which user groups are needed by the system to perform its functions? These
functions can be both main functions and secondary functions, such as
administration.
v) Which external hardware or other systems (if any) use the system to perform
tasks?
vi) What problems does this application solve (that is, for whom)?
vii) And, finally, how do users use the system (use case)? What are they doing
with the system?

64
Guidelines for Finding Use Cases
 For each actor, find the tasks and functions that the actor should be able to perform or
that the system needs the actor to perform.
 Name the use cases.
 Describe the use cases briefly by applying terms with which the user is familiar.

Separate Actors from Users

• Each use case should have only one main actor.
• Isolate actors from other actors (separate the responsibilities of each actor).
• Isolate use cases that have different initiating actors and slightly different behavior.

Documentation
An effective document can serve as a communication vehicle among the project's team members,
or it can serve as initial understanding of the requirements.

Effective Documentation: Common Cover

All documents should share a common cover sheet that identifies the document, the current
version, and the individual responsible for the content

Familiar Vocabulary
 Use a vocabulary that your readers understand and are comfortable with.
 The main objective here is to communicate with readers and not impress them with buzz
words.

Make the Document as Short as Possible

 Eliminate all repetition;
 Present summaries, reviews, organization chapters in less than three pages.
 Make chapter headings task oriented so that the table of contents also could serve as an
index.

The main objective of the analysis is to capture a complete, unambiguous, and consistent picture
of the requirements of the system. You should Construct several models and views of the system
to describe what the system does rather than how it does them. Capturing use cases is one of the
first things to do in coming up with requirements. Every use case is a potential requirement. The
key in developing effective documentation is to eliminate all repetition; present summaries,
reviews, organization chapters in less than three pages. Use the 80–20 rule: 80 percent of the
work can be done with 20 percent of the documentation.

65
Object Analysis: Classification
Classification involves:

 The concept of classification

 How to identify classes

Intelligent classification is intellectually hard work and may seem rather arbitrary. Martin and
Odell have observed in object-oriented analysis and design, that “In fact, an object can be
categorized in more than one way.”

Approaches for Identifying Classes

 noun phrase approach
 common class patterns approach
 use-case driven approach
 classes, responsibilities, & collaborators (CRC) approach

Guidelines for Naming Classes

• The class should describe a single object, so it should be the singular form of noun.

• Use names that the users are comfortable with.

• The name of a class should reflect its intrinsic nature.

• By the convention, the class name must begin with an upper case letter.

• For compound words, capitalize the first letter of each word - for example, Loan Window.

Identifying Object Relationships, Attributes, and Methods

Goals:
 Analyzing relationships among classes
 Identifying association
 Association patterns
 Identifying super and subclass hierarchies

Three Types of Objects Relationships

 Association
 Super-sub structure (also known as generalization hierarchy)
 Aggregation and a-part-of structure

66
Guidelines for Identifying Super-sub Relationships: Top-down
 Look for noun phrases composed of various adjectives on class name.
 Example, Military Aircraft and Civilian Aircraft.
 Only specialize when the sub classes have significant behavior.

Bottom-up
 Look for classes with similar attributes or methods.
 Group them by moving the common attributes and methods to super class.
 Do not force classes to fit a preconceived generalization structure.

Reusability
 Move attributes and methods as high as possible in the hierarchy.
 At the same time do not create very specialized classes at the top of hierarchy.
 This balancing act can be achieved through several iterations.

Multiple inheritance
 Avoid excessive use of multiple inheritances.
 It is also more difficult to understand programs written in multiple inheritance system.

Class Responsibility: Identifying Attributes and Methods

 Identifying attributes and methods, like finding classes, is a difficult activity.
 The use cases and other UML diagrams will be our guide for identifying attributes,
methods, and relationships among classes.

Identifying Class Responsibility by Analyzing Use Cases and Other UML Diagrams
 Attributes can be identified by analyzing the use cases, sequence/collaboration, activity,
and state diagrams.

Guidelines for identifying attributes of classes

 Do not carry discovery of attributes to excess.
 You can always add more attributes in the subsequent iterations.

67
OBJECT ORIENTED DESIGN

Designing systems using self-contained objects and object classes

 To explain how a software design may be represented as a set of interacting objects that
manage their own state and operations

 To describe the activities in the object-oriented design process

 To introduce various models that describe an object-oriented design

 To show how the UML may be used to represent these models

Characteristics of OOD

 Objects are abstractions of real-world or system entities and manage themselves

 Objects are independent and encapsulate state and representation information.

 System functionality is expressed in terms of object services

 Shared data areas are eliminated. Objects communicate by message passing

 Objects may be distributed and may execute sequentially or in parallel

Design axioms

 Main focus of the analysis phase of software development ”what needs to be done”

 Objects discovered during analysis serve as the framework for design

 Class‘s 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.

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

 Analysis Versus Design.

Analysis Design
 Focus on understanding
the problem  Focus on understanding the solution
 Idealized design  Operations and attributes
 Behavior  performance
 System structure  close to real code
 Functional requirements  object lifecycles
 A small model  non-functional requirements
 a large model

OO design process in the unified approach

Apply design Design view

Design
axioms /access layers
classes,
& prototype
methods and
attributes

Refine UML class

User satisfaction
diagrams
Continue testing & usability tests
based on use-
cases

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

69
Design Patterns
 Provides a scheme for refining the subsystems or components of a sw system or the
relationships among them

 Are devices that allow systems to share knowledge about their design, by describing
commonly recurring structures of communicating components that solve a general design
problem within a particular context

 The main idea to provide documentation to help categorize & communicate about
solutions to recurring problems

 The pattern has a name to facilitate discussion and the information it represents

Designing classes
Objectives - To explain how a software design may be represented as a set of interacting objects
that manage their own state and operations To describe the activities in the object-oriented
design process To introduce various models that describe an object-oriented design To show how
the UML may be used to represent these models

Characteristics of OOD
 Characteristics of OOD Objects are abstractions of real-world or system entities and
manage themselves Objects are independent and encapsulate state and representation
information.
 System functionality is expressed in terms of object services Shared data areas are
eliminated.
 Objects communicate by message passing Objects may be distributed and may execute
sequentially or in parallel

Advantages of OOD
 Advantages of OOD Easier maintenance.
 Objects may be understood as stand-alone entities Objects are appropriate reusable
components For some systems, there may be an obvious mapping from real world entities
to system objects

Object-oriented development
Object-oriented analysis, design and programming are related but distinct OOA is concerned
with developing an object model of the application domain OOD is concerned with developing
an object-oriented system model to implement requirements OOP is concerned with realizing an
OOD using an OO programming language such as Java or C++

70
Objects and object classes
Objects and object classes Objects are entities in a software system which represent instances of
real-world and system entities Object classes are templates for objects. They may be used to
create objects Object classes may inherit attributes and services from other object classes

Objects
An object is an entity which has a state and a defined set of operations which operate on that
state. The state is represented as a set of object attributes. The operations associated with the
object provide services to other objects (clients) which request these services when some
computation is required. Objects are created according to some object class definition. An object
class definition serves as a template for objects. It includes declarations of all the attributes and
services which should be associated with an object of that class.

The Unified Modeling Language:

The Unified Modeling Language has several different notations for describing object-oriented
designs that were proposed in the 1980s and 1990s. The Unified Modeling Language is an
integration of these notations It describes notations for a number of different models that may be
produced during OO analysis and design. It is now a de facto standard for OO modelling

Object communication
Conceptually, objects communicate by message passing. Messages - The name of the service
requested by the calling object. Copies of the information required to execute the service and the
name of a holder for the result of the service. In practice, messages are often implemented by
procedure calls Name = procedure name. Information = parameter list.

Message examples:
// Call a method associated with a buffer
// object that returns the next value
// in the buffer
v = circularBuffer.Get () ;
// Call the method associated with a
// thermostat object that sets the
// temperature to be maintained
thermostat.setTemp (20) ;

Generalisation and inheritance:

Generalisation and inheritance Objects are members of classes which define attribute types and
operations Classes may be arranged in a class hierarchy where one class (a super-class) is a
generalisation of one or more other classes (sub-classes) A sub-class inherits the attributes and

71
operations from its super class and may add new methods or attributes of its own Generalisation
in the UML is implemented as inheritance in OO programming languages

Advantages of inheritance
Advantages of inheritance It is an abstraction mechanism which may be used to classify entities
It is a reuse mechanism at both the design and the programming level The inheritance graph is a
source of organizational knowledge about domains and systems

Problems with inheritance:

 Object classes are not self-contained - they cannot be understood without reference to
their super-classes
 Designers have a tendency to reuse the inheritance graph created during analysis - Can
lead to significant inefficiency
 The inheritance graphs of analysis, design and implementation have different functions
and should be separately maintained

Inheritance and OOD

There are differing views as to whether inheritance is fundamental to OOD.
View 1. Identifying the inheritance hierarchy or network is a fundamental part of object-oriented
design. Obviously this can only be implemented using an OOPL.
View 2. Inheritance is a useful implementation concept which allows reuse of attribute and
operation definitions. Identifying an inheritance hierarchy at the design stage places unnecessary
restrictions on the implementation Inheritance introduces complexity and this is undesirable,
especially in critical systems

UML associations
Objects and object classes participate in relationships with other objects and object classes. In the
UML, a generalized relationship is indicated by an association Associations may be annotated
with information that describes the association. Associations are general but may indicate that an
attribute of an object is an associated object or that a method relies on an associated object

Concurrent objects:
The nature of objects as self-contained entities make them suitable for concurrent
implementation. The message-passing model of object communication can be implemented
directly if objects are running on separate processors in a distributed system

Servers and active objects:

The object is implemented as a parallel process (server) with entry points corresponding to object
operations. If no calls are made to it, the object suspends itself and waits for further requests for

72
service Active objects Objects are implemented as parallel processes and the internal object state
may be changed by the object itself and not simply by external calls.

System Implementation
System implementation is the translation of the system design into an object oriented
programming language that can be executed in a computer to generate the expected output. The
example below represents a program that comprises two classes that demonstrate inheritance.
Object instantiation, method overriding, and accessibility scope concepts are clearly illustrated,

Example:

#include <iostream.h>
#include <string.h> // must be included to handle string of characters
# define TAX_RATE 0.15 // constant declaration

class Employee
{
protected:

typedef char string[30]; // used to declare a user defined data type

int employeeNo;
string name;
double salary;
double houseAllowance;
double tax;

public:

// methods to assign data values

void setEmployeeNo(int eNo)

{ employeeNo = eNo;}

void setName(string name1)

{ strcpy(name,name1);} // strcpy function is used to write name1 value to name
variable

void setSalary(double sal)

{ salary = sal;}

73
 void setHouseAllowance(double hAllowance)
{ houseAllowance = hAllowance ;}

// methods to retrieve data values

int getEmployeeNo()
{ return employeeNo;}

double getSalary()
{ return salary;}

double getHouseAllowance()
{ return houseAllowance;}

double computeTax()
{
double tax = (salary + houseAllowance)*TAX_RATE;
return tax;
}

double computeGrossPay()
{
double gPay = salary + houseAllowance;
return gPay;
}

double computeNetPay()
{
double gPay = salary + houseAllowance;
double tax = gPay*TAX_RATE;
double nPay = gPay - tax;
return nPay;
}

void displayInfo()
{
cout<<"\n"<<"Name : "<<name;
cout<<"\n"<<"EmployeeNo : "<<employeeNo;
cout<<"\n"<<"Salary : "<<salary;

74
cout<<"\n"<<"HsAllowance : "<<houseAllowance;
cout<<"\n"<<"GrossPay : "<<computeGrossPay();
cout<<"\n"<<"TaxAmount : "<<computeTax();
cout<<"\n"<<"NetPay : "<<computeNetPay();
cout<<"\n";

}; // End of Employee class declaration

/*
Inheritance declaration. Manager class is created from Employee class and inherits all public
and protected members of Employee class
*/
class Manager:public Employee

{
protected:
double carAllowance; // Unique to manager
double medicalAllowance; // Unique to manager

public:

void setCarAllowance(double cAllowance)

{ carAllowance = cAllowance;}

void setMedicalAllowance(double mAllowance)

{ medicalAllowance = mAllowance;}

double getCarAllowance()
{ return carAllowance;}

double getMedicalAllowance()
{ return medicalAllowance;}

//Function overridding

double computeTax()

75
 { double tax = (salary + houseAllowance + carAllowance +
medicalAllowance)*TAX_RATE;
return tax;
}

double computeGrossPay() //Function overridding

{ double gPay = salary + houseAllowance + carAllowance + medicalAllowance;
return gPay;
}

double computeNetPay() //Function overridding

{ double gPay = salary + houseAllowance + carAllowance + medicalAllowance;
double tax = gPay*TAX_RATE;
double nPay = gPay - tax;
return nPay;
}

void displayInfo() //Function overridding

{
cout<<"\n"<<"Name : "<<name;
cout<<"\n"<<"EmployeeNo : "<<employeeNo;
cout<<"\n"<<"Salary : "<<salary;
cout<<"\n"<<"HsAllowance : "<<houseAllowance;
cout<<"\n"<<"CarAllowance : "<<carAllowance;
cout<<"\n"<<"MedAllowance : "<<medicalAllowance;
cout<<"\n"<<"GrossPay : "<<computeGrossPay();
cout<<"\n"<<"TaxAmount : "<<computeTax();
cout<<"\n"<<"NetPay : "<<computeNetPay();
cout<<"\n";

}; // End of Manager class declaration

main()
{

//Variable declaration

76
char name[30];
int empNo;
double salary;
double houseAllowance;
double carAllowance;
double medicalAllowance;

Employee emp; //Object declaration

Manager man; //Object declaration

int choice;

cout<<"\n Type 1 to choose ordinary employee OR 2 to choose Manager: Then Type Enter
Key";
cout<<"\n";
cin>>choice;

switch(choice)
{
case 1:
cout<<"\n Enter Name, EmployeeNo, Salary, House Allowance: separated by spaces :
Then Type Enter Key ";
cout<<"\n";
cin>>name>>empNo>>salary>>houseAllowance;

// method call

emp.setName(name);
emp.setEmployeeNo(empNo);
emp.setSalary(salary);
emp.setHouseAllowance(houseAllowance);
emp.displayInfo();
break;

case 2:

cout<<"\n Enter Name, EmployeeNo, Salary, HouseAllowance, CarAllowance,

MedicalAllowance: separated by spaces : Then Type Enter Key ";
cout<<"\n";

77
 cin>>name>>empNo>>salary>>houseAllowance>>carAllowance>>medicalAllowance;

// method call

man.setName(name);
man.setEmployeeNo(empNo);
man.setSalary(salary);
man.setHouseAllowance(houseAllowance);
man.setCarAllowance(carAllowance);
man.setMedicalAllowance(medicalAllowance);
man.displayInfo();
break;

default:

cout<<"\n Invalid Entry: Type 1 to choose ordinary employee OR 2 to choose Manager ";
cout<<"\n";
break;

return 0;

System Testing

Introduction
Testing is a process of detecting errors in a software program. The detected errors must be
corrected to ensure that the software meets its specifications and user requirements. Any
testing process applied throughout software development is either static or dynamic. Static
testing process involves reading and checking documents concerning requirements, reading
and checking of code without running the software. Dynamic testing process involves running
the code to check its output. Both types of testing process have been done. Dynamic testing
can be done using two approaches – black box testing and white box testing. Black box testing
treats the system as a black box that receives inputs and produce outputs. It is based on
assessment of requirements and functionality of the system. White box testing involves the
coverage of code statements, branches, paths and conditions of execution. It tests the internal
logic of the application’s code. The documentation in this chapter covers types of dynamic

78
testing and evaluation of the test results. In order to conduct testing process, a test plan is
required. The content of a test plan includes:

 The identity of the component to be tested

 The purpose of the test
 Condition for carrying out the test
 Test data to be used(includes correct and incorrect data)
 Expected result

Component testing
This refers to testing of each individual module in a suite of programs. Each module is tested
with correct and incorrect data to reveal loopholes in the code. It often takes place in parallel
with coding to provide intermediate results that reveal logic, functionality and error handling of
a unit. This testing is done at the source or code level for language, specifically for identifying
programming errors such as bad syntax, logic errors or to test particular functions or code
modules.

Functional/integration testing

Specific functional user requirements would be tested to ensure that the system meets these
requirements and ensure that the developer has developed the right product. Each user specific
function would be thoroughly tested to ensure that they perform their tasks properly. The test
would try to find errors within inputs and outputs of these functions. The results display and
format would be closely examined to make sure that it meets user requirements. This test would
also include tests such as:
 The interfaces to ensure that they are functioning well by checking if the interface
components are properly integrated and behaving as expected – especially verifying that
the appropriate action is associated with correct interaction method of designed mouse
click events, key strokes etc.
 The interaction of the system’s graphical user interface (GUI) and the backend database.
In this case, data would be inserted from the front end using data entry forms and check if
each entry corresponds to the correct database table field, also check if data inserted is in
the desired format.
 The form interaction design would also be tested to ensure that the information
presentation to the user is in a manner that the users can easily find and/or perform the
operation they want. The design should be an abstract representation of the abstract
physical forms that the system employees use.

79
System testing
The system would be properly tested to verify its functionality. This would be achieved by
ensuring that relevant tests have been performed such as integration tests, unit tests, functional
tests and acceptance tests. This test would be used as the overall testing of the system after the
system has fully been developed just before it is taken to the client, where the client will perform
acceptance testing with the developer and raise any adjustments they want at different system
levels. This type of testing would be designed to ensure that the system meets all functional and
non functional user requirements. This test would also focus on the behavior of the system once
it is subjected to different inputs. It would also focus on how different components of the system
interact with each other for optimal performance of the system (integration testing). Different
user demand would be tested against the system which would include error message testing and
several screen mappings.

Acceptance testing
This is done by the system client and after all other types of testing have been performed. The
system is taken to the commissioner to test whether it adheres to the agreed upon functional
requirements in System Requirements Specification Document (SRS). The client also uses black
box testing to evaluate the system functionality. Mission critical errors in functional
requirements are corrected immediately and regression testing performed to ensure that changes
made do not affect other system components or functions. Upon successful acceptance testing,
the system will then be implemented; a process that will see the developed system is in place and
working as intended.

Performance testing
This type of testing relates to the expected level of the processing time of the transaction or response time
especially when the system is being fully utilized.

Volume testing
This testing ensures that the system can handle the expected number of users or transaction’s processing
speed.

Regression testing
This involves ensuring that the system corrections do not result in the same or other errors as corrections
are being made.

Evaluation testing
For accurate results on testing, once alpha test is finished an independent body will be assigned to carry
out a beta test. This will guarantee software quality since the body does not have idea on the system
structure. Therefore they will use different test data which may help in discovering more errors. Their
recommendations will be considered and errors corrected accordingly. Later the system will be released
to the end user. For the purpose of software maintenance and documentation, all the test records and
test logs will be recorded and documented for future reference both for alpha and beta test.

80