CSE 413: Software Engineering Paradigms and Processes

● A paradigm is an example or pattern that can be copied. Paradigms consist of "a

set of assumptions, concepts, values, and practices that constitutes a way of
viewing reality for the community that shares them, especially in an intellectual
discipline."

● When applied to software development, a paradigm guides the way that

developers view a given problem and organize the solution.

● To develop large, complex software systems, developers break the overall

development process up into smaller, more manageable steps or phases. Jurison
notes that, "The choice of the software development process has a significant
influence on the project's success. The appropriate process can lead to faster
completion, reduced cost, improved quality, and lower risk. The wrong process
can lead to duplicated work efforts and schedule slips, and create continual
management problems" (1999).

The Software Development Process

Although different processes frequently incorporate different phases or name similar

phases differently, some phases are common to most processes. We consider three
common phases here. (The "OO" appearing in the acronyms below stand for
object-oriented.)

Analysis (OOA)

During analysis, emphasis is placed on the problem not on the solution. An

initial model is created by abstracting the essential aspects or features of the
problem. The model is expressed in a notation that can be understood by
customers, domain experts, and implementers. However, the model is generally
independent of any programming language or system at this time.
Design (OOD)

● A design bridges the gulf between analysis and implementation by

forming a solution architecture.

● The architecture reflects the domain knowledge that was discovered and
recorded during the analysis phase and provides the framework upon
which the final solution is constructed.

● It is often necessary to add data structures and their associated operations

to the model that do not appear in the original problem but that are
required by a software solution.

● It is also common that details that were overlooked during analysis are
added during the design phase while details that prove to be extraneous
are removed.

● The design is often partitioned into several sub-models focused on

specific, related tasks. Some common are:

● User interface
● Data management
● Task management
● Communications management

Implementation (also known as Programming or OOP)

The implementation phase produces a usable tool or system. A software project

ultimately delivers a program or system of programs; a combination of
hardware and software is delivered if the software is embedded in a physical
product (e.g., a car or aircraft).

Software Development Paradigms

Historically, Software developers have experimented with three major software

development paradigms: procedural, data driven, and object-oriented. Additionally,
much of the earliest software produced was developed based on ad hoc or impromptu
paradigms. As Figure 1 suggests, each of these paradigms attempts to solve a
real-world problem with a software solution. The illustration further suggests that
each paradigm is able to do this but that some are able to do so more quickly than
others.

Procedural
The procedural paradigm focuses on the algorithms or steps necessary to solve a
problem. It decomposes the problem into more simple sub-problems represented by
procedures, functions, or methods. The procedural decomposition was typically
depicted as a hierarchy, either a list or a tree. Computer scientists typically draw
hierarchical trees with the root (denoting the complete program in this case) at the top
and the leaves (denoting individual procedures or functions) at the bottom. There were
no well-defined rules for performing decomposition or for determining when the
functions were sufficiently simple to allow programming to begin. This means that
two different but experienced practitioners could create two quite different designs.
It is relatively easy, following this paradigm, to transition from design and analysis to
implementation. However, as the size and complexity of the problem increases, the
procedural paradigm begins to suffer from a large gap between the problem domain
(i.e., the real world) and analysis and design. The connection between the problem
and tree of functions is arbitrary and largely intangible, and as a result the procedural
paradigm produces poor problem domain understanding. Furthermore, the resulting
function trees are difficult for customers to follow, and changes to the decomposition
(i.e., to the trees) have widespread effects that ripple unpredictably through the trees.
Finally the procedural paradigm and its associated decomposition trees often results in
global data and coupled functions (discussed later). Nevertheless, the procedural
model is still appropriate for small, simple programs, and what we learn while
studying the procedural model will carry over to our study of the object-oriented
paradigm.

Data Driven
● Numerous data driven paradigms were utilized from the mid-1970s through the
mid-1990s, but each of these sub-paradigms had one essential feature in
common: they followed the data as it entered the system, passed through
processes that transformed the data, and continued to follow the data until it left
the system.

● The data flows were modeled as data arrows entering and leaving process
bubbles (as illustrated below). Sometimes multiple arrows entered a bubble and
were merged into a single exiting flow; sometimes a single flow entered only to
be separated into multiple flows leaving the process. The end result was a web
of data and processes that described a given problem.
● An analysis based on any of the data driven paradigms resulted in better
problem domain understanding than an analysis based on a procedural
decomposition. Furthermore, the models of the problem created during analysis
and elaborated during design were more useful in most contexts than the
corresponding models based on the procedural paradigm.

● Specifically, data flow-based models provided better support for software

testing, validation, and documentation, and the data flow diagrams were easier
for customers familiar with a problem to read than were the procedural
decompositions. Unfortunately, there was a large gap between the data flow
diagrams and the programs written during the implementation phase. This large
gap made programming difficult and greatly reduced the data driven paradigm's
usefulness.
Object-Oriented
● The object-oriented paradigm encapsulates data and the procedures or
operations that may access and operate on that data into an entity called an
object. A group of similar objects are described by a class. Classes are typically
documented with a graphical notation; the illustration below includes four
classes arranged in a class diagram using the Unified Modeling Language
(UML) notation. A cookie cutter and the cookies that it creates is a frequently
used analogy to classes and objects: the class is like a cookie cutter and objects
are like the cookies. Just as the size and shape of each cookie is determined by
the cookie cutter, so the "size" and "shape" of an object is determined by the
class: the class determines what data and operations each object will support
but the values stored for each data element of one object is independent of the
other objects.

● Objects existing in the real world are identified during analysis and are
abstracted into classes. During the design phase, detail is added to the classes,
new classes may be added, and some classes may be eliminated, but for the
most part, the classes discovered during analysis are carried over to design.
Furthermore, the classes refined during design are carried over into the
 implementation phase. Implementing the classes requires translating the UML
class diagrams into an appropriate programming language. Fortunately, the
translation process is well-defined and one-to-one (meaning that aside from
cosmetic nuances there is only one way to do the translation). More
fundamentally, the concepts of classes and objects do not change from one
phase to another. This conceptual consistency forms bridges between the
real-world, analysis and design, and implementation.

● The ability of the object-oriented paradigm to bridge the gaps between the
phases and to smoothen the development process is only one of its many
strengths. It retains the best characteristics of the procedural and data driven
paradigms while overcoming or minimizing their worst characteristics. For
example, as objects represent data, the models created during analysis provide
the same problem domain understanding as did the data driven paradigms. But
as classes also denote operations or procedures, the transition from design to
 implementation is much easier. Furthermore, as each class defines a new,
intermediate scope (the region of a program where a variable is visible and
accessible), the object-oriented paradigm also allows some but not all of the
procedures in a program to access the data.
● Controlling data access reduces the functional coupling that ultimately set an
upper limit to the size and complexity of software systems that could be
practically created based on the procedural paradigm. The many strengths of
the object-oriented paradigm make it the current best practice for creating large,
complex software systems.
● In software engineering, coupling is the degree of interdependence
between software modules; a measure of how closely connected two
routines or modules are; the strength of the relationships between modules.
Paradigms: Java versus C++
● Java is a pure object-oriented language. Being a pure object-oriented language
means that Java only has support for the object-oriented paradigm, which
further implies that everything in a Java program must be defined inside of a
class, including library methods and symbolic constants. Alternatively, C++ is a
hybrid language. Being a hybrid language means that C++ supports both the
procedural and the object-oriented paradigms. C++ allows a developer to
choose the paradigm most appropriate for a given problem: often the
object-oriented paradigm, but the procedural paradigm for smaller,
less-complex problems.

References
Jurison, J. (1999). Software project management: The manager's
view. Communications of the Association for Information Systems, 2, Article 17, 1-57.