UNIT I Programming Language Syntax and semantics. Kainjan Sanghavi

Transcription

1 UNIT I Programming Language Syntax and semantics B y Kainjan Sanghavi

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

3

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 SDLC for Using 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 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.

17 Spiral / I t e r ative Model Requirements Analysis Requirements Gathering Design R e p e at Maintenance Enhancement Iterative Development Deployment Quality Assurance

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 Spir al 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 Develop Design Test Discover Develop Design Test Discover Develop 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 30

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 31

32 However,... The longer you postpone coding, the sooner you ll be finished 32

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 33

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 C++/ Java Object Oriented Cuda Parallel LISP/ML Applicative or Functional PROLOG Rule Based or Logic 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 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).

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