1. Programming Language Syntax and semantics
UNIT I
Programming Language Syntax and semantics
BByy
Kainjan Sanghavi

2. Contents Software development process
Language and software development environments
Language and software design methods

4. SDLC
A framework that describes the activities performed at each stage of a software development project.

5. SDLC PHASES Requirements Gathering and Analysis Design
Development Testing Implementation Maintenance

6. SDLC PHASES

7. SDLC MODELS
To help understand and implement the SDLC phases various SDLC models have been created by software development experts, universities, and standards organizations.

8. Reasons for 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

9. Advantages of Choosing an Appropriate SDLC
Increased development speed Increased product quality Improved tracking & control Improved client relations Decreased project risk
Decreased project management overhead

10. Common Life Cycle
Models
Waterfall Spiral/Iterative Agile

11. Waterfall Model Analysis Design Development Testing
Deployment Maintenance

12. Waterfall 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

13. Waterfall 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

14. Waterfall 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

15. Waterfall Model Weaknesses
Difficult to integrate risk management
Significant administrative overhead,
costly for small teams and projects.

16. When to use the Waterfall 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.

17. Iterative Spiral/Iterative Model R e p e at Requirements Analysis
Requirements Design
Gathering
Iterative
R e p e at
Enhancement
Maintenance
Development
Quality
Assurance
Deployment

18. 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.

19. 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

20. 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

21. Spiral Model Weaknesses
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

22. When to use Spiral 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)

23. Agile Model Discover Test Discover Design Develop Test Discover Design

24. 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

25. 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)

26. 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

27. 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

28. 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

29. 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
See also the architecture chapter
© SE, Design, Hans van Vliet

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

35. 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

36. 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)
= sumto(1-1) = sumto(0)
= = …
= 3

37. 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.

38. 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.

39. 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.

40. Logic Programming Paradigm
edge(a,b).
edge(a,c).
edge(c,a).
path(X,X).
path(X,Y) :- edge(X,Y).
path(X,Y) :- edge(X,Z), path(Z,Y).
Reflexive transitive closure

41. 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.

42. Thank You!
Angelin