Lecture 07

Programming Paradigms &

SW Development Methodology

Please be on time
1
(better: before time)
 During the last lecture …
• We discussed the role of programming
languages in computing

• We also discussed the differences among

low- & high-level, interpreted & compiled.

2
 Today’s Lecture
• What is Programming paradigms?
• Which Criteria can be used in a good
language design?
• Development process of reasonably complex
SW systems does not consist of “coding”
only and structured & object-oriented Design
• We will become familiar with the various
phases of the process that developers follow
to develop SW systems of reasonable
complexity
3
 Programming Paradigms
• We will here look at the meaning of the word 'paradigm',
as it appears in 'The American Heritage Dictionary of the
English Language, Third Edition':
• "An example that serves as pattern or model.“
• Programming Paradigms can be classified as follows:

4
 Programming Paradigms
• Structured programming
• Involves building of program using small modules.
• The problem to be solved in broken down into small
task that can be written independently.

• S.Programming int to two ways

• Procedural programming
• Modular Programming
• C , COBOL and Pascal are example of structured
programming

5
 Programming Paradigms
• Object-Oriented programming
• Programming languages specifically designed to
make it easy to implement object-oriented design
• OOP focuses on developing the software based on their
component objects.
• The components interact with each other to provide the
functionality of the software.
• Each component consists of data and the methods that operate
on the data.
• The components are re-usable.
• Examples: Smalltalk, C++, Java

6
 Criteria in a good language design
• Writability:
• The quality of a language that enables a programmer to
use it to express a computation clearly, correctly,
concisely, and quickly.
• Readability:
• The quality of a language that enables a programmer to
understand and comprehend the nature of a computation
easily and accurately.
• Orthogonality:
• The quality of a language that features provided have as
few restrictions as possible and be combinable in any
meaningful way.
• Reliability:
• The quality of a language that assures a program will not
behave in unexpected or disastrous ways during
execution.
 Criteria in a good language design
• Maintainability:
• The quality of a language that eases errors can be found
and corrected and new features added.
 Generality:
 The quality of a language that avoids special cases in the
availability or use of constructs and by combining closely
related constructs into a single more general one.
 Uniformity:
 The quality of a language that similar features should look
similar and behave similar.
 Extensibility:
 The quality of a language that provides some general
mechanism for the user to add new constructs to a
language.
 Criteria in a good language design
Standardability:
 The quality of a language that allows
programs written to be transported from
one computer to another without significant
change in language structure.
Implementability:
 The quality of a language that provides a
translator or interpreter can be written. This
can address to complexity of the language
definition.
 Factors for Selecting a Language for
Coding an Application
• Nature of the application
• Familiarity with the language
• Ease of learning the language
• Availability of program development tools
• Execution efficiency
• Features of a good programming language
Programming

SW
? Development
11
SWDesign
Methodology?
12
The set of (often flexible) rules and
guidelines a team of developers
follow to construct reasonably
complex SW systems

13
SW Life-Cycle?
14
 SW Life-Cycle
• The sequence of phases a SW goes through
from the concept to decommissioning

• It is important to think about all those phases

before the design work starts

• Thinking about the future phases generally

results in:
• Shorter delivery times
• Reduced costs of development
– A system of higher quality
15
Let us now take a look at a very
simple SW life-cycle

16
Concept

Development

Operation & Maintenance

Decommissioning
17
That was a very simple view

Now we look at a more detailed view of

the life-cycle for a SW system of a
reasonable size

18
Concept & Feasibility
User Requirements
Developer Specs
Planning
Design
Implementation
Integration Testing
Opr. & Maintenance
Retirement
19
Concept & Feasibility Concept: What needs
User Requirements to be done?
Developer SpecsFeasibility: Preliminary
exploration of possible
Planning
solutions, technologies,
Design suppliers
Implementation
Integration Testing
Opr. & Maintenance
Retirement
20
Concept & Feasibility The user
documents as
User Requirements
much as he knows
Developer Specs about the job the
system must do
Planning
Design
Implementation
Integration Testing
Opr. & Maintenance
Retirement
21
Concept & Feasibility Developer
analyses users
User Requirements
requirement,
Developer Specs performs further
Planning investigation,
and produces
Design unambiguous
Implementation specifications
Integration Testing
Opr. & Maintenance
Retirement
22
 Detailed plan
Concept & Feasibility
specifying the
User Requirements required
Developer Specs resources and
expected
Planning deliverables
Design
Implementation
Integration Testing
Opr. & Maintenance
Retirement
23
 Concept & Feasibility
User Requirements
Developer Specs
Architecture: Decompose the problem into
subsystems and define their relationships
Planning
Design
Implementation further such that
Detailed Design: Decompose
one person can manage eachTesting
Integration sub-subsystem

Opr. & Maintenance

Retirement
24
Concept & Feasibility
User Requirements
Developer Specs
Planning
Design Design
Implementation Coding
Integration Testing
Opr. & Maintenance
Retirement
25
Concept & Feasibility
User Requirements
Bring the sub-
subsystems together
Developer Specs to form subsystems
Planning and test. Bring
subsystems together
Design
to form the system
and test
Implementation
Integration Testing
Opr. & Maintenance
Retirement
26
Concept & Feasibility
User Requirements
Developer Specs
Planning Use
Design Enhance
Implementation Adapt
Integration Testing Correct
Opr. & Maintenance
Retirement
27
Concept & Feasibility
User Requirements
Developer Specs
Planning
Design
Implementation Phase it
out when
Integration Testing the time
comes
Opr. & Maintenance
Retirement
28
29
Concept & Feasibility
User Requirements
Test
Developer Specs
Test
Planning
Test
Design
Test
Implementation
Test
Integration Testing
Acceptance Test Opr. & Maintenance
Retirement
30
 Key
Issues
31
 Customer’s lack of
Concept & Feasibility
knowledge about
User Requirements requirements
Developer Specs
Planning
Design
Implementation
Integration Testing
Opr. & Maintenance
Retirement
32
Concept & Feasibility
User Requirements
Lag
Developer Specs
Planning
Design
Implementation
Integration Testing
Opr. & Maintenance
Retirement
33
 Other Life-Cycle Models
• The sequence of phases (or the life-cycle
mode) that I showed is just one example of the
several sequences that SW developers follow

• This one is called the “Waterfall” model

• You will learn about some more models (e.g.

the Spiral model) in your future courses

34
 In Today’s Lecture

• We became familiar with the various phases

of the process that developers follow to
develop SW systems of reasonable
complexity

• We looked at a couple of problems related to

the Waterfall SW development model

35