SSE04 Project

Overall

The goal of your SSE04 project is to gain concrete experience with (1) model-driven software development and (2) defining your own software development process. The project is not part of the exam, but doing a good project will make it much easier for you to do well at the exam. Regarding model-driven software development, the overal goal is to define a program family (a set of related programs from the same problem domain), and subsequently make it very easy to develop new programs within the program family. Concretely, you will implement one or two members of a small program family, make a code generator for auto-generating part of each member of your program family, and then define a domain-specific language (DSL) for describing the programs in your domain using XML syntax. The code generator will be implementede using a simple template-based code generation technique resembling java server pages (JSP). Regarding the software development process, during your project you will derive a software development process that fits your project (e.g., what you are doing and who the project members are). This will be done iteratively as you progress, and the idea is to have the appropriate process at the end of the project. Concretely, you will be using the Crystal Clear development process which fits very well with your working context (course project) and moreover is designed exactly for this kind of iterative improvement.

Project topics

The set of project topics is open-ended. For inspiration you may want to look at the three examples in the 'materials' directory: network, tuples, and GAS. Here is a list of project suggestions, use them directly or for inspiration.

• Friendly GUI helpers: use DSL to describe a wizard that helps users achieve a specific task, generate implementation of the wizard.
• Network protocol fun: use DSL to describe network protocol at a fairly high level, generate a dedicated implementation of the network stack.
• Programmers assistant: use DSL to describe design pattern or architectural pattern implementations in a system, generate classes with specific purposes tailored to the programmers concrete needs.
• Course project generator: take a project from another course, define a program family where it is a member, generate multiple implementations (in addition to software courses, AI or robotics courses are also an option).

In general, a good project has a well-defined program family where the generated code interfaces directly with custom code. Feel free to reuse any part of the example programs, for example by building on top of them (all of them lack significant features).

(*) More advanced projects can also include some kind of abstract analysis at the level of the DSL. For example, the wizard could include a verification step that the wizard always can terminate and that all pages are included in some sequence. (The asterix (*) is used to denote parts of the project that are more difficult, see exam for details.)

Note that we use eclipse and JET for code generation, meaning that the code generator is written in Java. The generated code can however be in any language.

Suggested iteration plan

The end goal is to have a generator for a program family, with at least three working examples of generated programs, including custom code as appropriate.

• Inception (iteration 0): select program family (thus defining the project) and [manually] implement minimal versions of one or two members of your program family. (Concrete example of iteration end-goal: see the 'network' example under materials.)
• Iteration 1: implement a minimal generator for common functionality in your program family, extending the set of family members to three programs. (Concrete although minimal example of iteration end-goal: see the 'tuples' example under materials, ignoring the version that has an XML front-end.)
• Iterations 2+: add extra functionality to your applications, increase the percentage of code that is auto-generated. (Concrete although a bit large example of iteration end-goal: see the 'GAS' example under materials.)

According to the Crystal Clear methodology, every iteration should include reflection over what practices you are using in your project. Please note that you are required to try out a number of practices from the list below.

Agile software development practices

During your project, you should try out an appropriate number of agile software development practices. Below is a list of suggested practices it makes sense to try out in the first one or two iterations; a project must try at least one from each category (recommended starting practices are emphasized):

• Code review techniques:
  • Side-by-side programming
  • Peer programming
• Automated tests:
  • Unit testing
  • Test-first development
  • Continuous integration
  • Acceptance tests
• Project management:
  • Poker planning
  • Stand-up meetings
  • Planning game
  • Blitz planning
  • User stories/story cards

The list will evolve after the lecture on agile software development, since many of the practices will not really make sense without the prooper context. (Note that you probably will not try all of them, consult with Ulrik if in doubt as to how much you are required to try out.)