TA C252 Computer Programming

1. TA C252 Computer Programming Today’s Agenda • Course Motivation • Course Outline • Course Administration

2. Course Motivation • Programs • Programming • Software • Lifecycle • Process

3. Programs • Compare: Plan, Recipe, and Program. • Plan: • e.g. New Year Plans (stop postponing things, reduce TV time) • e.g. Five Year Plans (generate 10 million jobs, increase tax revenue) • Question: How is the plan implemented?

4. Programs • Recipe: (Don’t try at home!) • E.g. Eggplant Casserole: 1 cup pasta, 4 tender brinjals; 100gms of cheese; 1 tablespoon pepper, 2 teaspoons olive oil. Slow roast brinjals in olive oil. Boil pasta until it is soft. Add cheese and brinjals. Add pepper and salt to taste and stir fry for a few minutes. • Question: teaspoon vs. tablespoon? Whose taste? How soft? • Question: What will be the result?

5. Programs • Plans are not (necessarily) feasible: execution is arbitrary. • Recipes are (often) feasible, but (as often) • are ambiguous • do not have predictable results • are not (necessarily) repeatable: across time or persons.

6. Programs • Programs are specifications of solutions to problems. They • are unambiguous. • are formal (i.e., they are – or should be – constructed systematically out of basic steps) • are executable (by a machine or even by a human brain within limited scale) • have predictable and repeatable results.

7. Programs • Definition: A program is a formal, unambiguous and executable specification of a solution to a problem.

8. Programs • Observations: • “executable by machine” requires “formal and unambiguous”. • “formal and unambiguous” implies “repeatable and predictable”. (Ignore Schrodinger’s cat!) • Question: Does “formal and unambiguous” imply “executable by machine”?

9. Programs • Not so obvious but yes – “formal and unambiguous” does imply “executable by machine”. • (Reasonable) Assumptions – basic steps are “realizable in finite time using finite space”.

10. Programs • Alternative (equivalent) definitions of a Program: • A formal and unambiguous specification of a solution to a problem. • An executable specification of a solution to a problem.

11. Course Motivation • Programs • Programming • Software • Lifecycle • Process

12. Programming • The process of “constructing programs” • It is an engineering activity! • Limited resources (Time, Hardware and Software). • “Program” is the resultant product. • Typical engineering activities apply: design, implement and test.

13. Software • Program vs. Software: • Program has a single functionality. • Program is not “packaged”. • (Rudimentary) Definition: • Collection of one or more programs often packaged as a unit. • Analogous to the difference between “produce” and “commodity”.

14. Course Motivation • Programs • Programming • Software • Lifecycle • Process

15. Lifecycle • All products have a “life” after production. • Hallmark of “good engineering”: • Ability to determine post-production “behavior” during the production process. • Applies for software as well. • But post-production life for software is different (from that of other products)!

16. Lifecycle • Software is (expected to be) “re-usable”: • by any number of people • any number of times • for any number of purposes • in any number of contexts and environments • Implication: • Production Process is critical!

17. Process • Typical Software (Development) Process: • Phases • Requirements (Analysis & Specification) • Design • Development (Coding) • Quality Assurance (Testing) • Deployment • Maintenance • Teams of people

18. Process • Personal Programming Process: • Phases • Design • Development (Coding) • Testing • Single Person • Course Focus!

19. Course Outline • Goals • Approach • Modules

20. Course Goals • Generic • To motivate programming as a problem solving framework • To provide a disciplined personal approach to programming • To demonstrate the transition from concepts to practice of programming

21. Approach • Simple Personal Process. • Problem Solving Focus • Data-driven programming.

22. Process • 3-step process: Design, Develop, & Test. • Design includes: • An algorithm • Correctness arguments • Efficiency arguments • Test Case Identification

23. Process • Development includes: • Translation of design to C code • Structuring of C code into modules • Overall emphasis on process: • Reading a solution (i.e., a program) from a book is of no use unless you can solve other (similar) problems on your own!

24. Approach • Simple Personal Process • Problem Solving Focus • Data-driven programming

25. Problem Solving Focus • Problems are used as motivation for tools and techniques • Use C on a “need to know” basis: • Not everything in C will be discussed. • Constructs and techniques will be used only when needed for solving (a class of) problems.

26. Approach • Simple Personal Process • Problem Solving Focus • Data-driven programming

27. Data Driven Programming • Structure of the data  Structure of the program • Foundation for Data Processing, Data Structures and Object Oriented Programming.

28. Today’s Agenda • Course Motivation • Course Outline • Course Administration

29. Course Administration • Lectures • Instructors • LNS Prakash Goteti (Email: goteti) - IC • Sundar Balasubramaniam (Email: sundarb) • Focus on the process, concepts, and illustrative examples. • Websites • http://csis/faculty/goteti • http://csis/faculty/sundarb

30. Course Administration • Tutorials (Hands on) • Weekly once • Should go only to registered section. • Focus on practical aspects of programming and complex problem solving. • All tutorials are evaluated. (cf. Handout) • Students are also expected to practice C programming on their own.