MASENO UNIVERSITY

BSC. IN COMPUTER CSIENCE

YEAR 2 SEMESTER 2

CIR 204 OBJECT ORIENTED ANALYSIS AND DESIGN

COURSE NOTES 1

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

Maintenance

26
• 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. Implementation model.

4. 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

27
• 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.
• 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.

28
• Object-oriented analysis.
• Object-oriented design.
• 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.

30
  Always seek the advice and criticism of others.
 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 symbol: Represents the state of an object after an event has occurred
State name

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