Introduction toProgramming Technology

Roman Muslinov

Intel Corp

Agenda

• What programming is– Development process– SW success metric

• PT, methods & tools

Extended example: Game

Terms

• Program, System/Component

• Behavior (expected, unexpected), Error

• Developer, User

• Complexity, Quality of SW

• Design feature

• Programming technology

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)

Working with a program

program

input output

Developer

User

givesevaluates

modifies

Error := output differs fromthe expected one

Developer may act as UserBut not vice-versa!

Input/output may be empty

Crash/hangupare also kinds of output

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)

Types of development

Number of developers

Time reqsQuality reqs

Lifetime

Enterta-inment

1 No No Short

Research Several Weak No Middle

Industrial Many Strict Strict Long

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

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)

Problems of development

• Lacks and losses of informationuser → developer → program

Causes:• Complexity• Lack of time• Bad communication btw/developers• On-the-fly change of plans and design• Overestimation of workforce• PT ignorance

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

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

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

Version control

• Distributed development

• Development history

• Isolated development

• Use cases– Svn checkout/update/commit– Svn log/diff– Svn copy/merge

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

Co-development

• Responsibility sharing

• Speedup of development– Parallel works– Upper limit defined by task decomposition

• Learning speedup– Mentoring

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

Backup

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

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

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

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?

Thank you for attention!