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

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

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

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)

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

About the Architecture TBD

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

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.

Knowledge Management with a TWiki Pascal Durr Demo http://composestar.sf.net/

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

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

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

Design Documentation with UML Istvan Nagy

From Design to Code (XDE) Istvan Nagy

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)

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

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

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

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

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

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

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

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.

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