1. SE goes software engineering; (practically) managing the Compose
SE goes software engineering; (practically) 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 (TBD)

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: TBD

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
Two development environments
J# (runtime part: Visual Studio)
Java (preprocessing / compiletime: XDE / Eclipse)
Why?
first idea: only J#:
Java syntax & semantics
supports both JDK and .NET libraries
but generates only .NET bytecodes (assemblies)

16. Development with Visual Studio
Problems
very limited JDK support ( small part 1.2)
can’t use external libraries directly
External libraries
JVM bytecodes
.NET requires .NET assemblies
Visual J++ 6 could load JARs

17. Development with Visual Studio
Microsofts ‘solutions’
source available:
recompile
conversion wizard (Java to C#)
no source:
.JAR / class converter

18. Development with Visual Studio
Problems
conversion errors (e.g. Swing)
only JDK 1.1.4
lots of tweaking necessary
in case of external libraries requiring others:
converting process increases exponentially

19. Development with Visual Studio
Solution
only use J# for runtime
no C#, unless needed
message interception
later conversion to Java
use Java for compiletime
Added benefit
portability
short demo...

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

21. Automate testing Raymond Bosman
Overview:
Why do we need selftesting code?
Input output testing
Unit testing
Advantages:
Bug prevention
Think about what to implement
Can program faster
Helps to refactor faster

22. 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

23. 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# (J#?) code.

24. Summary/Conclusion Compose* environment is extremely volatile:
students are temporarily
architecture settles slowly (bottom-up process)
lots of specific knowledge involved
Tools, techniques & infrastructure
can contribute to communication & quality
our process is informal, light-weight and state-of-the- practice