Object Oriented Paradigm

1. Activities performed in object-oriented analysis

1. Modeling the functions of the system.

2. Finding and identifying the business objects.
3. Organizing the objects and identifying their relationships.
4. Modeling the behavior of the objects.
Designing concepts

• Defining objects, creating class diagram from conceptual diagram: Usually map entity to class.
• Identifying attributes.
• Use design patterns (if applicable): A design pattern is not a finished design, it is a description of a
solution to a common problem, in a context.[1] The main advantage of using a design pattern is that it
can be reused in multiple applications. It can also be thought of as a template for how to solve a problem
that can be used in many different situations and/or applications. Object-oriented design patterns
typically show relationships and interactions between classes or objects, without specifying the final
application classes or objects that are involved.
• Define application framework (if applicable): Application framework is usually a set of libraries or
classes that are used to implement the standard structure of an application for a specific operating
system. By bundling a large amount of reusable code into a framework, much time is saved for the
developer, since he/she is saved the task of rewriting large amounts of standard code for each new
application that is developed.
• Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single
runtime of the application. If a relational database is used, design the object relation mapping.
• Identify and define remote objects (if applicable).

OOA
OOD
UML
Structural Diagrams
Class Diagram
2. Use Case Diagram
Sequence Diagram
What is 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. [11, 13] Two Dimensions
The process can be described in two dimensions, or along two axis:

• 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.
 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 [10]

• 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 [2].

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. [10, 14] The outcome(ARTIFACTS) of the inception phase
is:

• A vision document: a general vision of the core project's requirements, key features, and main
constraints.
• A 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.
• 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. To
accomplish these objectives, you must have the “mile wide and inch deep” view of the system.
Architectural decisions have to be made with an understanding of the whole system: its scope, major
functionality and nonfunctional requirements such as performance requirements.

It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this
phase, the hard “engineering” is considered complete and the project undergoes its most important day
of reckoning: the decision on whether or not to commit to the construction and transition phases. For
most projects, this also corresponds to the transition from a mobile, light and nimble, low-risk
operation to a high-cost, high-risk operation with substantial inertia. 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.
• 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 involves 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. A robust architecture and an
understandable plan are highly correlated. In other words, one of the critical qualities of the
architecture is its ease of construction. This is one reason why the balanced development of the
architecture and the plan is stressed during the elaboration phase. The outcome of the construction
phase is a product ready to put in 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.

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

• Achieving stakeholder concurrence that deployment baselines are complete and consistent with
theevaluation 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?

Workflows
A mere enumeration of all workers, activities and artifacts does not quite constitute a process. We need
a way to describe meaningful sequences of activities that produce some valuable result, and to show
interactions between workers.

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. We use a form of activity diagrams in this white paper.

Example of workflow

Note that it is not always possible or practical to represent all of the dependencies between activities.
Often two activities are more tightly interwoven than shown, especially when they involve the same
worker or the same individual. People are not machines, and the workflow cannot be interpreted
literally as a program for people, to be followed exactly and mechanically.

In the next section we will discuss the most essential type of workflows in the process, called Core
Workflows.
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.
 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

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 is 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 so called 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. Many projects may choose not to
do business modeling.

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.

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
usecase model is used during requirements capture, analysis & design, and test.

Analysis & Design

The goal of the Analysis & 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 & 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 welldefined 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 next
figure shows part of a sample design model for the recycling-machine system in the use-case model
shown in the previous figure.

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 [9]. 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 Rational/Apex for 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 quality dimensions, the process describes how
you go through the test lifecycle of planning, design, implementation, execution and evaluation.

Strategies for when and how to automate test are described. Test automation is especially important
using an iterative approach, to allow regression testing at then end of each iteration, as well as for each
new version of the product.

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.

Components of RUP: Activities, Disciplines, Artifacts, Role or Worker

Four Ps of Software Development
Design Pattern

According to GoF definition of design patterns:

“In software engineering, a software design pattern is a general reusable solution to a commonly
occurring problem within a given context in software design. Design patterns are formalized best
practices that the programmer can use to solve common problems when designing an application or
system.”

A design pattern is a general repeatable solution to a commonly occurring problem in software

design. A design pattern isn't a finished design that can be transformed directly into code. It is a
description or template for how to solve a problem that can be used in many different situations.
The pattern is not a specific piece of code, but a general concept for solving a particular problem.
We can follow the pattern details and implement a solution that suits the realities of our own
program

Programming Paradigm Vs Design Pattern:

Programming paradigm is a method, a way, a principle of programming. It describes the programming
process, which is the way programs are made. It explains core structure of program written in certain
paradigm, everything that program consists of and its components. Some of programming paradigms:
Procedural paradigm, functional paradigm, object-oriented paradigm, modular programming, and
structured paradigm etc.

According to GoF definition of design patterns:

“In software engineering, a software design pattern is a general reusable solution to a commonly
occurring problem within a given context in software design. Design patterns are formalized best
practices that the programmer can use to solve common problems when designing an application or
system.”
Design patterns are formalized solutions to common programming problems. They mostly refer to
object oriented programming, but some of solutions can be applied in various paradigms.

Importance of Design Patterns:

1. Off-the-shelf solution-forms for the common problem-forms.
2. Teaches how to solve all sorts of problems using the principles of object-oriented design.
3. Helps in learning design and rationale behind project, enhances communication and insight.
4. Reusing design patterns helps to prevent subtle issues that can cause major problems.
5. Improves code readability for coders and architects familiar with the patterns.
 6. Design patterns provide general solutions, documented in a format that doesn't require specifics
tied to a particular problem.
7. Speed up the development process by providing well tested, proven development/design
paradigm.

Project Management
Structural Design Pattern
Software Architecture
Architectural Pattern
MVC
Design Pattern
According to GoF definition of design patterns:
“In software engineering, a software design pattern is a general reusable solution to a commonly
occurring problem within a given context in software design. Design patterns are formalized best
practices that the programmer can use to solve common problems when designing an application or
system.”
Programming Paradigm Vs Design Pattern:
Programming paradigm is a method, a way, a principle of programming. It describes the
programming
process, which is the way programs are made. It explains core structure of program written in certain
paradigm, everything that program consists of and its components. Some of programming paradigms:
Procedural paradigm, functional paradigm, object-oriented paradigm, modular programming, and
structured paradigm etc.
According to GoF definition of design patterns:
“In software engineering, a software design pattern is a general reusable solution to a commonly
occurring problem within a given context in software design. Design patterns are formalized best
practices that the programmer can use to solve common problems when designing an application or
system.”
Design patterns are formalized solutions to common programming problems. They mostly refer to
object oriented programming, but some of solutions can be applied in various paradigms.
Importance of Design Patterns:
1. Off-the-shelf solution-forms for the common problem-forms.
2. Teaches how to solve all sorts of problems using the principles of object-oriented design.
3. Helps in learning design and rationale behind project, enhances communication and insight.
4. Reusing design patterns helps to prevent subtle issues that can cause major problems.
5. Improves code readability for coders and architects familiar with the patterns.
6. Design patterns provide general solutions, documented in a format that doesn't require specifics
tied to a particular problem.
7. Speed up the development process by providing well tested, proven development/design
paradigm.
Creational design patterns
Structural patterns are concerned with how classes and objects are composed to
form larger structures.
Behavioral patterns are concerned with algorithms and the assignment of responsibilities between
objects. Behavioral patterns describe not just patterns of objects or classes but also the patterns of
communication between them.
In the UML, the basic unit of concurrency is the thread. Threads are associated with a stereotype of
objects, called «active» objects; that is, an «active» object is special in the sense that it is the root of a
thread of control.
The recommended way of adding concurrency into an object model is to identify the desired threads
through the application of task identification strategies (see [7] for a list of several such strategies).
Once a set of threads is identified, the developer creates an «active» object for each. The "passive"
objects are then
added to the «active» objects via the composition (strong aggregation) relation. The role of the
«active»
object is to run when appropriate and call or delegate actions to the passive objects that it owns. The
passive objects execute in the thread of their «active» owner.
Principles that lead to good design
Architectural pattern vs design pattern
Requirement Analysis

In systems engineering and software engineering, requirements analysis focuses on the tasks that
determine the needs or conditions to meet the new or altered product or project, taking account of the
possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and
managing software or system requirements.
Software Quality
Configuration management (CM) is a systems engineering process for establishing and maintaining
consistency of a product's performance, functional, and physical attributes with its requirements, design, and
operational information throughout its life

The change management process in systems engineering is the process of requesting, determining
attainability, planning, implementing, and evaluating of changes to a system. Its main goals are to support the
processing and traceability of changes to an interconnected set of factors.[1]
Design as 4 dimensional view of a system
Use Case Driven

A use case is a sequence of actions, performed by one or more actors (people or non-human entities outside of
the system) and by the system itself, that produces one or more results of value to one or more of the actors.
One of the key aspects of the Unified Process is its use of use cases as a driving force for development. The
phrase use case driven refers to the fact that the project team uses the use cases to drive all development work,
from initial gathering and negotiation of requirements through code. (See "Requirements" later in this chapter
for more on this subject.)

Use cases are highly suitable for capturing requirements and for driving analysis, design, and implementation
for several reasons.

To quote, "A use - case realization describes how a particular use case is realized within the Design Model, in
terms of collaborating objects" [RUP]. More precisely, a designer can describe the design of one or more
scenarios of a use case; each of these is called a use case realization (though non - standard, perhaps better
called a scenario realization). Use case realization is a UP term used to remind us of the connection between
the requirements expressed as use cases and the object design that satisfies the requirements
Player-Role Pattern
Observer Pattern
Interaction Diagram

Reuse

n computer science and software engineering, reusability is the use of existing assets in some form within the
software product development process; these assets are products and by-products of the software development
life cycle and include code, software components, test suites, designs and documentation. The opposite concept
of reusability is leverage, which modifies existing assets as needed to meet specific system requirements.
Because reuse implies the creation of a separately maintained version of the assets [clarification needed], it is preferred
over leverage.[1]

Code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new
software,[1] following the reusability principles.

Designing with reuse is complementary to designing for reusability.

you can build reusability into algorithms,

classes, procedures, frameworks and complete applications whereas in reuse you just reuse.
Analysis Model vs Design Model
Enterprises are typically comprised of hundreds if not thousands of applications that are
custom-built, acquired from a third-party, part of a legacy system, or a combination thereof,
operating in multiple tiers of different operating system platforms. It is not uncommon to find an
enterprise that has 30 different Websites, three instances of SAP and countless departmental
solutions.
Real-time and embedded systems (RTE systems) must execute in a much more constrained environment
than "traditional" computer systems such as desktop and mainframe computers. RTE systems must be
highly efficient, optimally utilizing their limited processor and memory resources, and yet must often
outperform systems with significantly more compute power. In addition, many RTE systems have
important safety-critical and high-reliability requirements because they are often used in systems such as
avionics flight control, nuclear power plant control, life support and medical instrumentation. The creation
of RTE systems to meet these functional and quality of service requirements requires highly experienced
developers with decades of experience. Yet, over the years, these developers have encountered the same
problems over and over—maybe not exactly the same problems but common threads. The very best
developers abstract these problems and their solutions into generalized approaches that have proved
consistently effective. These generalized approaches are called design patterns. They are often best applied
at the level of the system or software architecture—the sum of design decisions that affect the fundamental
organization of the system. Real-Time Design Patterns is an attempt to capture in one place a set of
architectural design patterns that are useful in the development of RTE systems.
Factory Method
Applicability & Examples
The need for implementing the Factory Method is very frequent. The cases are
the ones below:
when a class can't anticipate the type of the objects it is supposed to create
when a class wants its subclasses to be the ones to specific the type of a newly
created object

Façade Pattern
Architecture Centric