Programming Language Syntax and semantics

UNIT I

BB yy

Kainjan Sanghavi

Contents

• Software development process • Language and software development

environments • Language and software design methods

A framework that describes the

activities performed at each stage of a

software development project.

SDLC

SDLC PHASES

Requirements Gathering and Analysis

Design

Development

Testing

Implementation

Maintenance

SDLC PHASES

To help understand and

implement the SDLC phases various

SDLC models have been created by

software development experts, universities, and standards

organizations.

SDLC MODELS

Reasons f o r Using SDLC Models

Provides basis for project planning, estimating & scheduling

Provides framework for standard set of terminologies, activities & deliverables

Provides mechanism for project tracking & control

Increases visibility of project progress to all stakeholders

an Appropriate SDLC

Increased development speed

Increased product quality

Improved tracking & control

Improved client relations

Decreased project risk

Decreased project management overhead

Advantages of Choosing

Common Life Cycle Models

Waterfall

Spiral/Iterative

Agile

Analysis

Design

Development

Testing

Deployment

Maintenance

Waterfal l Model

Waterfal l Model

Oldest and most well-known SDLC model

Follows a sequential step-by-step process from

requirements analysis to maintenance.

Systems that have well-defined and understood

requirements are a good fit for the Waterfall Model

Waterfal l Model Strengths

Easy to understand, easy to use

Provides structure to inexperienced staff

Milestones are well understood

Sets requirements stability

Good for management control (plan, staff, track)

Works well when quality is more important than cost or schedule

Waterfal l Model Weaknesses

All requirements must be fully specified upfront

Idealised, does not match reality well. Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end

Difficult and expensive to make changes

Waterfal l Model Weaknesses

Difficult to integrate risk management

Significant administrative overhead,

costly for small teams and projects.

When t o use the Waterfal l Model

Requirements are very well known

Product definition is stable

Technology is understood

New version of an existing product

Porting an existing product to a new platform.

Requirements Analysis

Requirements Design Gathering

Development

Quality Assurance Deployment

Maintenance

Enhancement

R e p e at

Iterative

Spiral / I t e r ative Model

Spiral Model

Spiral Model is a Disk-driven iterative model

Divides a project into iterations

Each iteration deals with 1 or more risks

Each iteration starts with small set of requirements and goes through development phase (except Installation and Maintenance) for those set of requirements.

Spiral Model

Iterate until all major risks addressed and the application is ready for the Installation and Maintenance phase (production)

Each of the iterations prior to the production version is a prototype of the application.

Last iteration is a waterfall process

Spiral Model Strengths

Provides early indication of insurmountable

risks, without much cost

Critical high-risk functions are developed first

The design does not have to be perfect

Users see the system early because of rapid

prototyping tools

Users can be closely tied to all lifecycle steps

Early and frequent feedback from users

Time spent for evaluating risks too large for small or low-risk projects

Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive

The model is complex

Risk assessment expertise is required

Spiral may continue indefinitely

May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

Spiral Model Weaknesses

When to use Spir a l Model

When creation of a prototype is appropriate

When costs and risk evaluation is important For medium to high-risk projects Users are unsure of their needs

Requirements are complex

New product line Significant changes are expected (research and exploration)

Discover

Test

Design Develop

Test

Discover

Design Develop

Test

Design

Develop

Discover

Agile Model

Agile Model

Speed up or bypass one or more life cycle phases

Usually less formal and reduced scope

Used for time-critical applications

Used in organizations that employ

disciplined methods

Some Agile Methods

Rapid Application Development (RAD)

Scrum

Extreme Programming (XP) Adaptive Software Development (ASD)

Feature Driven Development (FDD)

Crystal Clear

Dynamic Software Development Method (DSDM)

Rational Unify Process (RUP)

Agile Model Strengths

Deliver a working product faster than conventional linear development model

Customer feedback at every stage ensures that the end deliverable satisfies their expectations

No guesswork between the development team and the customer, as there is face to face communication and continuous inputs from the client

Agile Model Weaknesses

For larger projects, it is difficult to judge the

efforts and the time required for the project in the SDLC.

Since the requirements are ever changing, there is hardly any emphasis, which is laid on

designing and documentation. Therefore, chances of the project going off the track

easily are much more

Language and Software

Development Environment

Environment means group of H/w and S/w tools used by a developer to build software systems.

H/w tools

S/w tools

SDE

Language and Software

Development Environment

In development for Coding tools such as

Compilers, Linkers, Text Editors and

Libraries are used.

Integrated Development Environments

Debuggers are used to find faults and

programming errors

30

Programmer’s Approach to

Software Engineering

• Skip requirements engineering and design

phases; • start writing code

31

Why this programmer’s

approach? • Design is a waste of time

• We need to show something to the customer real

quick

• We are judged by the amount of LOC/month

• We expect or know that the schedule is too tight

32

However, ...

The longer you postpone coding, the sooner

you’ll be finished

33

Up front remarks

• Design is a trial-and-error process

• The process is not the same as the outcome of that process

• There is an interaction between requirements engineering, architecting, and design

Language and Software

Design Methods Most of the programming languages impose particular programming style…. and this style is known as Programming

Paradigm

Programming Paradigms

C / Pascal/ FORTRAN

• Imperative or Procedural

LISP/ML

• Applicative or Functional

PROLOG

• Rule Based or Logic

C++/ Java

• Object Oriented

Cuda

• Parallel

Generic

• Eiffel

Functional Style :

Illustration Definition: Equations sumto(0) = 0 sumto(n) = n + sumto(n-1) Computation: Substitution and Replacement

sumto(2) = 2 + sumto (2-1)

= 2 + sumto(1)

= 2 + 1 + sumto(1-1) = 2 + 1 + sumto(0)

= 2 + 1 + 0 = …

= 3

Procedural vs Functional

• Program: a sequence of instructions for a von Neumann m/c.

• Computation by instruction execution.

• Iteration. • Modifiable or

updatable variables..

• Program: a collection of function definitions (m/c independent).

• Computation by term rewriting.

• Recursion. • Assign-only-once

variables.

Object-Oriented

Style Programming with Abstract Data Types

ADTs specify/describe behaviors.

Basic Program Unit: Class Implementation of an ADT.

Abstraction enforced by encapsulation..

Basic Run-time Unit: Object Instance of a class.

Has an associated state.

Procedural vs

Object-Oriented • Emphasis on

procedural abstraction.

• Top-down design; Step-wise refinement.

• Suited for programming in the small.

• Emphasis on data abstraction.

• Bottom-up design; Reusable libraries.

• Suited for programming in the large.

Logic Programming

Paradigm 1. edge(a,b). 2. edge(a,c). 3. edge(c,a). 4. path(X,X). 5. path(X,Y) :- edge(X,Y). 6. path(X,Y) :- edge(X,Z), path(Z,Y).

Logic Programming

• A logic program defines a set of relations.

• This “knowledge” can be used in various

ways by the interpreter to solve different

“queries”.

• Make explicit HOW the “declarative

knowledge” is used to solve the query.

Thank You!

Angelin