1.1 Programming Paradigm: Language? What Do We Need To Know To Program in A Language? There Are Three Crucial
1.1 Programming Paradigm: Language? What Do We Need To Know To Program in A Language? There Are Three Crucial
A design pattern is a proven solution for a general design problem. It consists of communicating
‘objects’ that are customized to solve the problem in a particular context.
Patterns have their origin in object-oriented programming where they began as collections of
objects organized to solve a problem. There isn't any fundamental relationship between patterns
and objects; it just happens they began there. Patterns may have arisen because objects seem so
elemental, but the problems we were trying to solve with them were so complex.
Architectural Patterns: An architectural pattern expresses a fundamental structural
organization or schema for software systems. It provides a set of predefined subsystems,
specifies their responsibilities, and includes rules and guidelines for organizing the
relationships between them.
Design Patterns: A design pattern provides a scheme for refining the subsystems or
components of a software system, or the relationships between them. It describes commonly
recurring structure of communicating components that solves a general design problem
within a particular context.
Idioms: An idiom is a low-level pattern specific to a programming language. An idiom
describes how to implement particular aspects of components or the relationships between
them using the features of the given language.
1.2.2 Components:
A component must be compatible and interoperate with a whole range of other components.
Examples of components: “Window”, “Push Button”, “Text Editor”, etc.
Two main issues arise with respect to interoperability information:
1. how to express interoperability information (e.g. how to add a “push button” to a “window”;
2. how to publish this information (e.g. library with API reusable via an “include” statement)
1.2.3 Software Architecture:
Software architecture is the structure of the components of the solution. A particular software
architecture decomposes a problem into smaller pieces and attempts to find a solution
(Component) for each piece. We can also say that an architecture defines a software system
components, their integration and interoperability:
Integration means the pieces fit together well.
Interoperation means that they work together effectively to produce an answer.
There are many software architectures. Choosing the right one can be a difficult problem in itself.
1.2.4 Frameworks:
A software framework is a reusable mini-architecture that provides the generic structure and
behavior for a family of software abstractions, along with a context of metaphors which specifies
their collaboration and use within a given domain.
Frameworks can be seen as an intermediate level between components and a software
architecture.
Example: Suppose an architecture of a WBT system reuse such components as “Text Editing
Input object” and “Push buttons”. A software framework may define an “HTML Editor” which
can be firther reused for building the architecture.
2 Software Engineering and Software Paradigms
The term "software engineering" was coined in about 1969 to mean "the establishment and use of
sound engineering principles in order to economically obtain software that is reliable and works
efficiently on real machines".
This view opposed uniqueness and "magic" of programming in an effort to move the
development of software from "magic" (which only a select few can do) to "art" (which the
talented can do) to "science" (which supposedly anyone can do!). There have been numerous
definitions given for software engineering (including that above and below).
Software Engineering is not a discipline; it is an aspiration, as yet unachieved. Many approaches
have been proposed including reusable components, formal methods, structured methods and
architectural studies. These approaches chiefly emphasize the engineering product; the solution
rather than the problem it solves.
Software Development current situation:
People developing systems were consistently wrong in their estimates of time, effort, and
costs
Reliability and maintainability were difficult to achieve
Delivered systems frequently did not work
1979 study of a small number of government projects showed that:
2% worked
3% could work after some corrections
45% delivered but never successfully used
20% used but extensively reworked or abandoned
30% paid and undelivered
Fixing bugs in delivered software produced more bugs
Increase in size of software systems
NASA
StarWars Defense Initiative
Social Security Administration
financial transaction systems
Changes in the ratio of hardware to software costs
early 60's - 80% hardware costs
middle 60's - 40-50% software costs
today - less than 20% hardware costs
Increasingly important role of maintenance
Fixing errors, modification, adding options
Cost is often twice that of developing the software
Advances in hardware (lower costs)
Advances in software techniques (e.g., users interaction)
Increased demands for software
Medicine, Manufacturing, Entertainment, Publishing
Demand for larger and more complex software systems
Airplanes (crashes), NASA (aborted space shuttle launches),
"ghost" trains, runaway missiles,
ATM machines (have you had your card "swallowed"?), life-support systems, car systems, etc.
US National security and day-to-day operations are highly dependent on computerized
systems.
Manufacturing software can be characterized by a series of steps ranging from concept
exploration to final retirement; this series of steps is generally referred to as a software lifecycle.
Steps or phases in a software lifecycle fall generally into these categories:
Requirements (Relative Cost 2%)
Specification (analysis) (Relative Cost 5%)
Design (Relative Cost 6%)
Implementation (Relative Cost 5%)
Testing (Relative Cost 7%)
Integration (Relative Cost 8%)
Maintenance (Relative Cost 67%)
Retirement
Software engineering employs a variety of methods, tools, and paradigms.
Paradigms refer to particular approaches or philosophies for designing, building and maintaining
software. Different paradigms each have their own advantages and disadvantages which make
one more appropriate in a given situation than perhaps another (!).
A method (also referred to as a technique) is heavily depended on a selected paradigm and may
be seen as a procedure for producing some result. Methods generally involve some formal
notation and process(es).
Tools are automated systems implementing a particular method.
Thus, the following phases are heavily affected by selected software paradigms
Design
Implementation
Integration
Maintenance
The software development cycle involves the activities in the production of a software system.
Generally the software development cycle can be divided into the following phases:
Requirements analysis and specification
Design
Preliminary design
Detailed design
Implementation
Component Implementation
Component Integration
System Documenting
Testing
Unit testing
Integration testing
System testing
Installation and Acceptance Testing
Maintenance
Bug Reporting and Fixing
Change requirements and software upgrading
Derived from other engineering processes in 1970. Offered a means of making the development
process more structured. Expresses the interaction between subsequent phases.
Figure: Waterfall model
Each phase cascades into the next phase. In the original waterfall model, a strict sequentially was
at least implied. This meant that one phase had to be completed before the next phase was begun.
It also did not provide for feedback between phases or for updating/re-definition of earlier phases.
Implies that there are definite breaks between phases, i.e., that each phase has a strict, non-
overlapping start and finish and is carried out sequentially.
Critical point is that no phase is complete until the documentation and/or other products
associated with that phase are completed.
2.2.2 Modified Waterfall Model
Needed to provide for overlap and feedback between phases. Rather than being a simple linear
model, it needed to be an iterative model. To facilitate the completion of the goals, milestones,
and tasks, it is normal to freeze parts of the development after a certain point in the iteration.
Verification and validation are added. Verification checks that the system is correct (building the
system right). Validation checks that the system meets the users desires (building the right
system).
Types can be weak or strong. Strong type means that at any point in the program, when it is
running, the type of a particular chunk of data (i.e. variable) is known. Weak type means that
imperative operators may change a variable type.
Example:
var PersonName; /*variable of a weak type”*/
PersonName = 0; /*PersonName is an “integer”*/
PersonName = ‘Nick’; /*PersonName is a “string”*/
Obviously, languages supporting weak variable types need sophisticated rules for type
conversions.
Example:
var PersonName; /*variable of a weak type”*/
PersonName = 0; /*PersonName is an “integer”*/
PersonName = PersonName + ‘Nick’ + 0; /*PersonName is a string “0Nick0”*/
To support weak typing, values are boxed together with information about their type - value and
type are then passed around the program together.
3.2 Functions (Procedures)
Programmers have dreamed/attempted of building systems from a library of reusable software
components bound together with a little new code.
Imperative (Procedural) Programming Paradigm is essentially based on concept of so-called
“Functions” also known as “Modules”, “Procedures” or “Subroutines”.
A function is a section of code that is parceled off from the main program and hidden behind an
interface:
function factorial(parameter)
{
var i = 1;
var result = 1;
while(i <= parameter)
{
result = result * i;
i++;
}
return(result);
}
The code within the function performs a particular activity, here generating a factorial value
The idea of parceling the code off into a subroutine is to provide a single point of entry.
Anyone wanting a new factorial value has only to call the “factorial” function with the
appropriate parameters.
Here's what the conventional application based on the Imperative (Procedural) Programming
Paradigm looks like:
Main procedure determines the control flow for the application
Functions are called to perform certain tasks or specific logic
The main and sub procedures that comprise the implementation are structured as a hierarchy
of tasks.
The source for the implementation is compiled and linked with any additional executable
modules to produce the application
There might be two different techniques for such replacement which are known as: passing an
argument value and passing an argument reference.
In case of passing a value, a current argument value is duplicated as a value for new parameter
variable dynamically created for the procedure. In this case, variables used as arguments for
calling sub-routines cannot be modified by imperative operators inside of the sub-routines.
In case of passing a reference, the sub-routine gets control (i.e. reference) to a current value of the
argument variable. In this case, variables used as arguments for calling sub-routines can be
modified by imperative operators inside of the sub-routines.
Thus, types of variables defined as parameters of a function should be equivalent to (or at least
compatible with) types of variables (constants) used as arguments.
3.3.2 Polymorhic Languages
When strong static typing is enforced it can be difficult to write generic algorithms - functions
that can act on a range of different types. Polymorphism allows "any" to be included in the type
system. For example, the types of a list of items are unimportant if we only want to know the
length of the list, so a function can have a type that indicates that it takes lists of "any" type and
returns an integer. Moreover, polymorphism allows to combine functions implemented by means
of different programming languages supporting potentially different types of variables.
Pragmatically speaking, polymorphic languages allow to define new types as hidden functions
which should be automatically applied to values of such “user-defined type” to convert it to
values of a “standard” language type.
3.3.3 Variable Scope
Normally, variables that are defined within a function, are created each time the function is used
and destroyed again when the function ends. The value that the function returns is not destroyed,
but it is not possible to assign a value to the variable inside the function definition from outside.
Example:
function one()
{
var dynamicLocalVariable = 25;
two();
/* at this point just one variable “dynamicLocalVariable” exists */
alert(dynamicLocalVariable);
/* this operator displays the current value “25” */
}
function two()
{
var dynamicLocalVariable = 55;
/* at this point two variables “dynamicLocalVariable” exists */
alert(dynamicLocalVariable);
/* this operator displays the current value “55” */
}
Such variables are called dynamic local variables. There may be also so-called static local
variables. Static local variables that are defined within a function, are created only once when the
function is used for a first time. The value of such variable is not destroyed and can be reused
when the function is called again.
Example:
function one()
{
var x = two();
alert(x);
/* this operator displays the current value “10” */
x = two();
alert(x);
/* this operator displays the current value “20” */
}
function two()
{
var static staticLocalVariable = 0;
staticLocalVariable = staticLocalVariable + 10;
return(staticLocalVariable);
}
Note that function “two” returns different values for one and the same set of arguments. Such
functions are called reactive functions. Generally, testing and maintenance of projects having
many reactive functions becomes a very difficult task. For practical reasons many software
projects do use some static data.
Note, it is still not possible to assign a value to the local static variable inside a function from
outside.
There may be also so-called static global variables. Static global variables that are defined within
any function, are created only once when the whole software system is initiated. The value of
such variable is never destroyed and can be reused by imperative operators inside any function.
Example:
function one()
{
var global globalLocalVariable = 0;
two();
alert(globalLocalVariable);
/* this operator displays the current value “10” */
two();
alert(globalLocalVariable);
/* this operator displays the current value “20” */
}
function two()
{
globalLocalVariable = globalLocalVariable + 10;
}
Here, the function “two” also demonstrates a “reactive” behavior. Maintaining and testing of
projects heavily based on global variables becomes even more difficult than in case of local static
variables. Nevertheless, for practical reasons many software development paradigms do use such
global static variables.
4 Software Design Methodology (Procedural Paradigm)
Benefits of the Paradigm:
Re-usability: anyone that needs a particular functionality can use an appropriate module, without
having to code the algorithm from scratch.
Specialization: one person can concentrate on writing a best possible module (function) for a
particular task while others look after other areas.
Upgradability: if a programmer comes up with a better way to implement a module then he/she
simply replace the code within the function. Provided the interface remains the same - in other
words the module name and the order and type of each parameter are unchanged - then no
changes should be necessary in the rest of the application.
However procedural modules have serious limitations:
For a start, there is nothing to stop another programmer from meddling with the code
within a module, perhaps to better adapt it to the needs of a particular application.
There is also nothing to stop the code within the function making use of global
variables, thus negating the benefits of a single interface providing a single point of
entry.
Obviously, the paradigm is best suited for the waterfall model of software development.
4.1 Design
A particular software system is viewed in terms of its modules and data flowing between them
starting with a high-level view.
In this case, software design methodology can be categorized as a Top-down modular design
(functional design viewpoint).
The basic design concepts include:
Modularity
Modules are used to describe a functional decomposition of the system
A module is a unit containing:
executable statements
data structures
other modules
A module:
has a name
can be separately compiled
can be used in a program or by other modules
System design generally determines what goes into a module
Cohesive
Single clearly defined function
Description of when and how used
Loosely Coupled Modules (Modules implement functionality, but not parts of other
modules)
Black Boxes (information hiding)
each module is a black box
each module has a set of known inputs and a set of predictable outputs
inner workings of module are unknown to user
can be reusable
Preliminary and Detailed Design specify the modules to carry out the functions in the
DataFlow Diagrams (DFD).
Preliminary design deals mainly with Structure Charts
Hierarchical tree structure
Modules - rectangle boxes
calling relationships are shown with arrows
arrows are labeled with the data flowing between modules
Module Design
Title
Module ID - from structure charts
Purpose
Method - algorithm
Usage - who calls it
External references - other modules called
Calling sequence - parameter descriptions
Input assertion
Output assertion
Local variables
Author(s)
Remarks
Preliminary Design Document
Cover Page
Table of Contents
Design Description
Software Structure Charts
Data Dictionary
Module Designs
Module Headers
Major Data Structures Design
Design Reviews (Examination of all or part of the software design to find design anomalies )
Overview of Detailed Design
select an algorithm for each module
refine the data structures
produce detailed design document
4.2 Implementation
Coding (for each Module)
Source Code
Documentation
Integration
Decide what order the modules will be assembled
Assemble and test integration of modules
After final assembly perform system test
Note, coding and testing are often done in parallel
4.3 Testing
Types of testing
Unit testing
Integration testing
Acceptance testing
As it was mentioned above, the paradigm is best suited for the waterfall model of software
development. Implementing change requirements and especially rapid prototyping are weak
points of the programming paradigm.