1. SE goes software engineering; managing the Compose* project.
The Compose* Team
Christian Vinkes
Frederik Holljen
Istvan Nagy
Lodewijk Bergmans
Pascal Durr
Raymond Bosman
Sverre Boschman

2. Scope Composition Filters Implementation
Compose* is a modular language extension
Current target: extend .NET
Implementation
implementation is crucial
for our own verification
for the trust of the community
for the learning process internal/external
many past implementations
throw-away prototypes; wasted effort

3. Managing the Project: Main Goals
Communication
integration
avoid redundant efforts
Continuity
keep the knowledge
keep the quality
documentation

4. Overview of the Process
It is informal & light-weight
Steps:
architecture: grows evolutionary [Lodewijk]
design: UML diagrams--Rose XDE [Istvan]
code: Java, J#, C#
synchronize with design (XDE) [Istvan]
use Eclipse and Visual Studio [Christian]
document with ‘doxygen’ [Raymond]
automate testing [Raymond]
code inspections

5. Overview of the infrastructure
Communication
Sourceforge: bug tracking, mailing lists,.. [Frederik]
Knowledge management
Wiki: cf. project web site [Pascal]
Source code sharing
CVS [Frederik]
Build & Deployment
Make files, multi-platform, executables

6. About the Architecture
TBD

7. Knowledge Management with a TWiki Pascal Durr
What is TWiki
Webbased collaboration platform
Accessible from any descent webbrowser
Main Features:
Easy editable
Simple text formatting
Revision Control
Topic locking

8. Knowledge Management with a TWiki Pascal Durr
TWiki and the Compose* project
The #1 place for information about the project.
Entry point for developers and users.
Used for long term storage of information.
Each developer has their own space.
One place to rule them all.
Keeping it structured is a problem.

9. Knowledge Management with a TWiki Pascal Durr
Demo

10. Communication with SourceForge Introduction
world's largest Open Source software development web site
free (as in beer)
open licences only
Reasons for choosing SourceForge
Attracting contributions from the outside
Provides communication infrastructure

11. Communication with SourceForge Major features provided
Bug tracker
Forums
Mailing lists
Web/disk space
Compile farm
Administrative access rights
CVS

12. Source code sharing with CVS (Concurrent Versioning System)
Central repository for source code
edit one file simultaneously
Versioning system, you can:
commit changes to a file
roll back files to a previous state
see log of changes
Supports tagging and branching

13. Design Documentation with UML Istvan Nagy

14. From Design to Code (XDE) Istvan Nagy

15. Development with Visual Studio Christian Vinkes

16. Code documentation with DOXYGEN Raymond Bosman
Same syntax as Javadoc
Supports also other languages (C, C++, PHP, etc.)
Widely used
Open source

17. Automate testing Raymond Bosman
Overview:
Why do we need selftesting code?
Input output testing
Unit testing

18. Automate testing Selftesting code
Can test the whole system within several seconds
Advantages:
Bug prevention
Think about what to implement
Can program faster
Helps to refactor faster

19. Automate testing Input output testing
Tests if the output of the program matches the expected output.
Needed files:
Input files: *.in
Output files: *.out
Keyboard input: *.kb

20. Automate testing Unit testing
Most classes have their own test class.
We test:
Only the important classes.
Test only methods that can go wrong.
Boundaries, Exceptions and some combinations.
We use:
JUnit for Java and J#.
dotUnit for C# code.

21. Summary/Conclusion