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

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

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

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

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

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

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

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

Summary/Conclusion