Introduction to Programming Technology

1. Introduction toProgramming Technology Roman Muslinov Intel Corp

2. Agenda • What programming is • Development process • SW success metric • PT, methods & tools Extended example: Game

3. Terms • Program, System/Component • Behavior (expected, unexpected), Error • Developer, User • Complexity, Quality of SW • Design feature • Programming technology

4. What a program is • User’s point of view • A program may be viewed as a black box, that is, a convertor of certain types of input into the proper output • Developer’s point of view • A program is a system consisting of interacting components • Examples of programs • Shell, GUI, compiler, OS, text editor, browser, game, school progs (matrices, lists, calculators, etc)

5. Working with a program User gives evaluates input output program modifies Input/output may be empty Crash/hangup are also kinds of output Developer Error := output differs from the expected one Developer may act as User But not vice-versa!

6. The task of development • SW life cycle • Idea • Development • Design • Implementation • Debugging • Exploiting • Design • Input: use cases (input->output mapping) description • Output: functionality outline; system decomposition (structural, OO, …) • Implementation • Input: design output • Output: codebase (+tests) • Debugging • Input: codebase • Output: sources ready for exploitation (having certain reliability level)

7. Types of development

8. Program characteristics • Functionality • Portability • User-friendliness • Performance (speed) • MT support • … • Reliability • Error expectation • Coverage • Design quality • Flexibility (upgradeability) • Inspectability • Readability • Debugability • Debug info/debug version • Debug prints • Self-verification

9. SW success metric • SW quality for user (QU) = functionality * reliability • SW quality for developer (QD) = QU * (design quality) = QU * inspectability * flexibility • SW success = QD / (development time)

10. Problems of development • Lacks and losses of information user → developer → program Causes: • Complexity • Lack of time • Bad communication btw/developers • On-the-fly change of plans and design • Overestimation of workforce • PT ignorance

11. Programming technology • A set of methods and tools aimed to maximize SW success metric • Acts throughout the entire development process • Helps to minimize information (and => quality) losses on different stages of development • Fights with consequences of inevitable human mistakes • Especially useful in team development • Still, PT can’t replace human brains 

12. Main PT methods • Complexity reduction • Decomposition + minimization of dependencies btw components • Explication (clear interfaces, all DFs doc-d) • Re-usage of components (incl. external ones) • Quality regression prevention • Automated checks • Auto-build, auto-testing, self-checks in code • Quality monitoring process • Version control, bugtracking, code-reviews

13. PT methods & tools checklist • Incremental development • Source control • SVN, CVS • Auto-build • Make • Auto-testing • Bugtracker • Bugzilla • Code-writing style • Co-development • Code review • Refactoring

14. Version control • Distributed development • Development history • Isolated development • Use cases • Svn checkout/update/commit • Svn log/diff • Svn copy/merge

15. Code-writing style • Common ground for team development • Same tools for everyone (copy exactly) • Readability of sources • Naming conventions • Code structuring conventions • Bug prevention through PT methods enforcement • Functional decomposition • Interfaces design (and header files) management • Checks/asserts • Documenting

16. Co-development • Responsibility sharing • Speedup of development • Parallel works • Upper limit defined by task decomposition • Learning speedup • Mentoring

17. Summary • SW development is a more serious thing than commonly conceived • Team development brings additional complexity • System decomposition is projected on people • Usage of PT allows to increase SW success probability • Mistake avoidance • Knowledge explication • Quality assurance

18. Backup

19. Design features • Implicit suppositions (sacred knowledge) about • Input data • State of calculation • Data layout • Objects interrelation/dependencies • Control flow • … And anything else that’s not explicitly stated in interfaces btw program components • Should be avoided if possible, else fully explicated/documented

20. Common mistakes • Unnecessary usage of global variables • Big functions • Code optimizations, that can be done by compiler • Non-trivial macro-generation of code • Too general algorithms w/o coverage testing • Simplification before design completed • Double implementation (code copying) • Re-implementation of functionality (instead of using libraries) • Optimization ahead of design

21. Good code • Modules • Small functions • Speaking names (types, variables and functions) • Uniform code-writing style • Asserts (pre-, post-conditions, invariants) • Documented • Covered by unit-tests or some other tests

22. Quick assessment • What is an error in SW? Is segfault always an error? • What is the difference between research and industrial SW development? • How is the quality of SW estimated? • What are the root causes of errors in SW? • What is PT? • What are the basic PT methods? • What are the most common PT tools? And what are they used for? • How to make branch in SVN? Why bother?

23. Thank you for attention!