iCSC2005
Advanced Software Theme
Details of all lectures
An introduction to
Entreprise Computing
| |
|
|
Thursday 24 February |
|
|
09:00 - 09:55 |
Design Block |
Lecture 1 |
An introduction to
Entreprise
Computing |
Giovanni Chierico |
|
The objective of this lecture is to
introduce the principles of Enterprise Computing and o
describe the major challenges |
|
Introduction
Common EC Problems & Solutions
|
Design Patterns
| |
|
|
Thursday 24 February |
|
|
10:05 - 11:00 |
Design Block |
Lecture 2 |
|
Design Patterns |
Ruben Leivas Ledo
Brice Copy |
|
Using design patterns is a widely accepted method to improve
software development. There are many benefits of the
application of patterns claimed in the literature. The most
cited claim is that design patterns can provide a common
design vocabulary and therefore improve greatly
communication between software designers. Most of the claims
are supported by experiences reports of practitioners, but
there is a lack of quantitative research concerning the
actual application of design patterns and about the
realization of the claimed benefits. We will explore this
information to gain an insight into the differences of
software development with and without design patters. |
|
Part 1 by
Ruben Leivas Ledo
1. Why patterns?
2. Group of Four Taxonomy of Design Patterns
-
Creational Patterns
-
Structural Pattern
-
Behavioral Patterns
3. Classification of Design Patterns
4. Elements of Design Patters
-
Name
-
Problem
-
Solution
-
Consequences
5. Some interesting examples applied to the real life of
programmers
6.- Implementing Design Patterns as Declarative Code
Generators
7.- Patterns for Java and Distributed Computing
Part 2: Important Enterprise Patterns by
Brice Copy
8.- MVC in Web applications (Struts, Spring MVC)
9.- Inversion of Control, Dependency Injection (Spring) |
Security in Computer Applications
| |
|
|
Thursday 24 February |
|
|
11:30 - 12:25 |
Theory Block |
Lecture 3 |
Security in Computer Applications |
Sebastian Lopienski |
|
The lecture will address the following issues:
-
how to think of
about security, how to design a secure computer system,
and how to implement it
-
what are the
common errors, pitfalls, bugs and traps while
implementing, what are common ways for attackers to
exploit some code,
-
how to make a
good use of cryptography (which algorithms to use,
length of keys, validity of certificates etc.),
-
threats appearing
on the human-machine (or human-application) interface,
and threats coming from dishonest users
-
many real-life
examples of good security, poor security, misunderstood
security and security which in fact makes things less
secure
|
| |
|
• |
What is security in computer world |
|
| |
|
• |
Is it an issue for average software
developer (at CERN)? |
|
| |
|
• |
Prevention, detection and
counteraction |
|
| |
|
• |
Why security is difficult to achieve |
|
| |
|
• |
General rules: simplicity,
modularity etc. |
|
| |
|
• |
What about security by obscurity? |
|
| |
|
• |
Bugs, flaws, vulnerabilities |
|
|
3. Architecture and design
|
| |
|
• |
Advantages of modularity |
|
| |
|
• |
Security of the whole system is only
as strong as its weakest element |
|
| |
|
• |
Least privilege principle |
|
| |
|
• |
Other design principles |
|
| |
|
• |
Readable and understandable code |
|
|
5. Enemy number one: input data
|
| |
|
• |
Strings and buffer overflow issue |
|
| |
|
• |
Canonical representation problems |
|
|
6. Common problems, pitfalls, traps
while implementing
|
| |
|
• |
Environment variables and settings |
|
| |
|
• |
Parallel or non-atomic execution |
|
| |
|
• |
Deal with error / Catch exceptions |
|
| |
|
• |
Dumping core/leaving debug
information |
|
| |
|
• |
Open source vs. proprietary
solutions |
|
|
9. Identification, authentication,
authorization
|
| |
|
• |
Authentication with something you
know, something you have, something
you are (or a combination) |
|
|
10. Cryptography - practical review
|
| |
|
• |
Encryption (symmetric and asymmetric
algorithms) |
|
| |
|
• |
Cryptography in network protocols
(ex.: SSL) |
|
|
11. How cryptography can help
|
| |
|
• |
keys: confidential, algorithm:
public |
|
| |
|
• |
Don’t implement cryptographic
algorithms |
|
|
12. Other interesting techniques
|
|
13. Social engineering risks
|
| |
|
• |
How can we help users (education,
restrictive software, clear design) |
|
| |
|
• |
What is the main message? |
|
| |
|
• |
Future readings (at the lecture's
web page) |
|
|
|
Change Control:
Iterative Development /
Advanced CVS
| |
|
|
Thursday 24 February |
|
|
14:00 - 14:55 |
Integration Block
|
Lecture 4
|
Change Control:
Iterative Development /
Advanced CVS
|
Brice Copy
Sebastian Lopienski |
|
This lecture is formed of two
parts. In the first one,
Brice Copy presents the principles of
Iterative Development, why
it was introduced, where it is used and what the various
components are. In the second part,
Sebastian Lopienski,
after a setting the scene, presents the latest development
of CVS, advices about common problems and
pitfalls, suggest ways to use it and compare it to other
similar tools. |
|
Part 1 by
Brice Copy
|
What Is Iterative Development ?
|
— |
As opposed to monolithic approaches
(cascade model) |
|
|
— |
Perform full, fast and complete
development cycles (spec, code,
build, integrate, test and back
again) |
|
|
— |
In line with modern risk management
techniques |
|
|
— |
Enables you to cope with changing
requirements |
|
Why Iterative Development Was Introduced
|
— |
Cascade development too cumbersome |
|
|
— |
Full development cycles lets your
team members (Dev, QA, System) work
in parallel |
|
Where Is It Used
Ingredients List
|
— |
Source control management (SCM)
system |
|
|
— |
Somebody to write requirement and
design specifications |
|
|
— |
An eager team of developers ready to
work in parallel |
|
|
— |
Quality Assurance people |
|
|
— |
An integrated build tool (your Swiss
army knife) |
|
Integrated Build Tool
| |
|
— |
Remote invocations stubs (Web
services, RMI etc...) |
|
|
— |
SCM integration (CVS, Perforce,
SourceSafe?
etc...) |
|
|
— |
Code compilation (from various
sources to various targets) |
|
|
— |
Functional and regression testing |
|
Integrated Build Tool (2)
|
— |
Deployment as a named deliverable |
|
| |
|
— |
Shared library repository |
|
|
— |
Documentation generation |
|
| |
|
— |
Specification in various formats (XDoc,
PDF etc...) |
|
Apache Ant
|
— |
All of the above plus more |
|
|
— |
Not Java specific, but well err.. |
|
|
— |
Easy to extend through Ant Tasks |
|
Apache Maven
|
— |
Your project is seen as a high level
object |
|
|
— |
Your project must follow a certain
structure |
|
|
— |
Really aimed at Java projects |
|
Automated Build Tools
|
Part 2 by
Sebastian Lopienski
Objectives of the presentation
|
• |
Basic and not so basic but still
useful functionality of CVS
(including branching, merging,
tagging, watching etc.) |
|
|
• |
Demystify the vocabulary
(repository, revision, tag, attic,
karma etc.) |
|
|
• |
Present available clients (command
line clients, GUIs and IDE
integrated clients) for both
Unix-like and Windows platforms |
|
|
• |
Present others tool for CVS (Web
interfaces etc.) |
|
|
• |
Show some good (and also bad) CVS
users' habits |
|
|
• |
warn about some common problems and
pitfalls |
|
|
• |
Discuss access control in CVS and
security issues |
|
|
• |
Suggest ways to use CVS in build
process |
|
|
• |
Mention other revision control
systems like SourceSafe, Subversion
etc. |
|
|
• |
Collect and present links to books,
tutorials etc. |
|
|
• |
Prepare some exercises to be
downloaded and run for further
studies. |
|
|
|
Debugging Techniques
|
|
|
|
Friday 25 February |
|
|
15:05 - 16:20 |
Maintenance Block |
Lecture 5 |
Debugging Techniques |
Paolo Adragna |
|
The lecture addresses the problem of eliminate bugs from
software. It is targeted on programmers who develop software
on Unix-like platform using C/C++ language, but a large part
of the content is general purpose and can be exploited also
in a different context (platform or language). |
|
Introduction and general comments
about debugging |
|
|
In the introduction the general
background required by debugging is
reviewed
|
|
1) Noting and localizing a bug
|
|
Part one - General debugging |
|
|
The first part of the lecture presents
advices for general purpose debugging
|
|
1) Exploiting compiler feature: static
analysis, warning option, optimization
flag
|
|
2) Reading the right documentation
|
|
3) The abused cout debugging technique:
general description, disadvantages.
|
|
4) Defensive programming and the assert
macro (as a solution of cout technique)
|
|
5) The debugger. The example of gdb/ddd.
|
|
6) ANWB debugging technique: not really
a technique actually, rather a method to
flush out bugs
|
|
7) Code walkthrough: really an advice
(possibly a citation of Gerhard's
lecture)
|
|
Part two - C/C++-generated
problems and tools to solve them |
|
|
The second part addresses problems
usually generated by C/C++ programming
|
|
1) Preprocessor: problems with versions,
headers
|
|
3) System call examination and
interaction with the system: the example
of strace
|
|
5) Dynamic storage allocation: general
description of the problem.
|
|
- |
Exploitable tools: libraries (to be
linked) or external programs
|
|
- |
Libraries: MEMWATCH, Electric Fence
(with examples)
|
|
- |
Executables: YAMD, Valgrind (with
examples)
|
|
6) Incremental building: description of
the problem and citation of make
|
|
|
Code Reviews: Best Practices
|
|
|
|
Friday 25 February |
|
|
15:20 - 16:00 |
Maintenance Block |
Lecture 6 |
Code Reviews: Best Practices |
Gerhard Brandt |
|
This lecture addresses the following
questions
|
|
— |
How to write code that's readable
and understandable ? |
|
|
— |
Which tools can you use to make this
easier ? |
|
|
— |
How to understand already existing
code ? |
|
|
|
| |
|
Starting points for this lecture:
|
| |
|
Other people have engineered code for
you.
|
| |
|
|
— |
It's your honor to adjust this code
where it shows |
|
| |
|
|
|
suboptimal behaviour ( = fix bugs )
|
| |
|
|
— |
You learn from their ingeniosity and
apply your experience |
|
| |
|
|
|
as you and others contribute new code
|
| |
|
Approaching a foreign body of code
top-down:
|
| |
|
Read it in increasing level of detail
|
| |
|
|
— |
Read File/Directory Structure |
|
| |
|
|
|
(like Design Patterns, Interfaces,
Libraries, makefiles)
|
| |
|
stay on top - dive only as required!
|
| |
|
( = don't try to read 100k lines of code
from the beginning to the end )
|
|
* High-level Orientation in an unknown
body of code
|
| |
|
|
— |
Documentation and its Generation |
|
|
* Use the command line, like: Simple
heuristics
|
| |
|
|
* cvs: Watch what happens during
checkout
|
| |
|
|
* ls: directory structure
|
| |
|
— |
Condense code to structural
elements: {} , ; |
|
| |
|
— |
ref: Cunningham W., OOPSLA 2001
Software Archeology Workshop |
|
| |
|
|
— |
Real-time access to CVS |
|
| |
|
|
— |
View Changes, Diffs, Tags, ...
immediately |
|
|
* LXR - Linux Cross Reference
|
| |
|
|
— |
Perl script that generates xref'ed
source code in HTML from C++ |
|
| |
|
|
— |
Not real-time on CVS - rerun by
webserver about once a day |
|
|
* Generating documentation from code
|
| |
|
|
— |
many different tools - incompatible
formats |
|
| |
|
|
— |
Used with ROOT based applications (eg.
H1OO?) |
|
| |
|
|
— |
Classes to be documented must be
included in ROOT |
|
| |
|
|
|
(ClassDef ?,
ClassImp ?
Macros) |
| |
|
|
— |
Need code that sees ALL classes to
generate complete documentation |
|
| |
|
|
|
(eg. executable that links everything)
|
| |
|
|
— |
Non C++ Files not documented |
|
| |
|
|
— |
Bugs (eg. inline functions don't
work correctly) |
|
| |
|
|
— |
Unofficial outlook: THtml2 |
|
| |
|
|
|
|
— |
ROOT team choice: rewrite doc tool
from scratch, incl. C++ parser etc. |
|
| |
|
|
|
|
— |
more features: more output formats,
code browsing from CINT cmdline, ... |
|
| |
|
|
— |
good results for un-enriched code |
|
| |
|
|
— |
too many bells and whistles? |
|
| |
|
|
— |
Graph generation tool from BellLabs? |
|
| |
|
– graphical representation of code
structure
|
| |
|
|
— |
used by Doxygen for its graphs |
|
| |
|
|
|
|
|
— |
Notation for type and scope? |
|
| |
|
|
— |
example: messages/error logging |
|
| |
|
|
— |
often old/suboptimal solution |
|
| |
|
|
* Headers, Initialization
|
| |
|
|
— |
Checking Contributions by others |
|
|
— |
Available in other languages: C++
cppunit |
|
|
— |
normally used for test driven
development |
|
| |
|
-> not identical to correctness checking
|
|
— |
Example H1OO?
- H1 Fast Validation |
|
|
— |
Check code based on changes in
physics variables |
|
|
— |
Compare set of observables from
identical data |
|
| |
|
but reconstructed from two different
releases
|
|
— |
Differences must make sense from
physics POV |
|
| |
|
-> if not, infer indirectly to problems
in the code
|
|
— |
Very simple implementation, great
success for our purposes |
|
|
* Enforcing Coding standards: Code
Beautifiers
|
| |
|
|
* Jalopy (a java code beautifier)
|
| |
|
|
* Code analyzers PMD (Java)
|
| |
|
|
Testing coverage reports (Clover,
JBlanket)
|
| |
|
— |
Spinellis D., Code Reading, Addison
Wesley 2003 |
|
| |
|
— |
McConnell?
s., Code Complete, Microsoft Press,
2nd Ed 2004 |
|
| |
|
— |
... Test Driven Development |
|
|
|
|
|
|
