introduction to programming technology
Post on 09-Jan-2016
14 Views
Preview:
DESCRIPTION
TRANSCRIPT
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!
top related