Keynote: Object-oriented programming and generic programming and what else?

Bjarne Stroustrup

Programming styles

OOP and GP and Concurrency

We must evaluate programming styles/paradigms against a set of ideals.

Aims for
· For developers
· For programmers
· Etc

Programming languages are a means for expressing solutions; they still matter!

Classic OOP problems
· Double dispatch: intersection amon two objects
· Eternal polymorphism: adding operations to something
· Etc

Classic GP
Advantages
· Regularity and generality of code
· Shared implementation
· Composability
· Performance

Ex:
list lst;
int s1 = accumulate(lst.begin(), lst.end(),0)
int p1 = accumulate(lst.begin(), lst.end(),1,multiply());
vector v;
Matrix s2 accumulate(v.begin(), v.end(),0);

C++ GP: run-time efficiency with a high-level of abstraction
Classic template ex: prime # calculation by the compiler

Classic GP problems
· Irregularities of argument types
· No support for defining new types

OOP vs. GP

OOP: Ad-hoc polymorphism
GP: Parametric polymorphism

OOP: focus on design and use of hierarchies
GP: focus on design and use of algorithms

OOP: Dynamic (run-time) resolution of calls
GP: Static (compile-time) resolution of calls

OOP: Easy to add new type
GP: Hard to add new type

OOP: Hard to add new operation
GP: Easy to add new algorithm

There are solutions in the space that involves the combinations of these two styles.

Can we combine/extend these two styles to minimize problems? Bjarne’s guess: the convergence will hinge on concurrency

C++0x Concepts and Concept maps push GP support to more mainstream.

Concept maps help fix separately developed libraries together provided they are somewhat similar in semantics.

GP: runtime concepts (currently research)

References
· Design Patterns, 1994
· Concepts: Linguistics Support for Generic Programming in C++, OOPSLA ‘04
· Run-time concepts for the C++ standard library, SAC ‘08
· The C++ Programming Language, 2000

Move over svn, git, ...

Move over svn, git, ...

Tips on Use Cases

Terry Quatrani

Uses Cases: a way to communicate requirements

Requirements
· Functionally
· Usability
· Reliability
· Performance
· Supportability

Non-functional Requirements
· Design constraints: OS, Environment, Compatibly
· Legal and Regulatory

Use cases deal with Functional Requirements only! Other requirements are gathered at the same time but put into separate documents.

Uses cases
· enable communication.
· provide links to stake holders.
· identify who/what interact with system
· are a planning instrument
· drive analysis, design, and testing

Notation
· Actor
· Action
· System

What should NOT be in a use case
· implementation details
· user interface requirements
o gather at same time, but put into separate document
· non-functional requirements
o same thing
· business rules
o same thing

What should be IN a use case
· Brief Description
· Flow of Events
o Basic flow
o Alternate flow(s)
· Special Requirements
· Pre-conditions
· Post-conditions
· Extension Points

“Provide only the necessary details about the interactions between a system and its uses.”

Use case development: Iterative!
1. Discovery
2. Briefly Describe
3. Bulleted Outline
4. Essential Outline
5. Detail Description
6. Fully Describe

CRUD uses cases should be combined into one use case. CRUD = Create, Read, Update, Delete.

Avoid putting in too much detail, remember that a use case is for communication. Use case is for requirements, not design.