SCORE Project: Umple Game

Title: Distributed Multiplayer Game Modeled in Umple

Sponsor: Timothy Lethbridge

For this project your team will create a distributed multi-player game while exercising a maximum of features of the Umple modeling technology (www.umple.org). The goals of the project are: a) To demonstrate the power of Model Driven Development and Umple in software engineering; b) To uncover and help solve any issues with Umple in realistic projects.

Project Description

Umple (http://www.umple.org) is a modeling technology that allows code generation from many UML features, such as most of the capabilities of class and state diagrams. It also incorporates modeling features that go beyond UML. Users of Umple typically write ‘code’ that embeds modeling constructs in Umple syntax with methods written in ‘traditional code’ in Java, C++ and PHP. The Umple compiler then generates a complete system. Additionally, the Umple compiler automatically generates and displays UML diagrams representing the system. Umple can be developed in Eclipse or using command-line tools. Small Umple systems can also be developed using an online IDE called UmpleOnline.

In this project, participants will develop a multi-player distributed game in Umple. The game domain was chosen in order to be fun, but also because it is a rich domain than can allow for lots of modeling of both structure and behaviour. Details of the game are totally up to the team.

The game could have a rich graphical user interface if desired, or could have a visually-simple UI – even a textual one. The game could be web-based or app-based. What is more important is that the players have a good experience interacting with a richly modeled environment and game rules.

Project Scope

The scope of the project is that is should be a multi-player distributed game. More detailed management of the scope is up to the team.

Process Requirements

Your project must be written in Umple (see ‘Environment Constraints’ below). The use of Umple implies that model-driven development must be followed: Models (state machines and class diagrams in particular) must be created and drive development.

The project must follow an agile process. User stories must be created and used to drive short agile sprints.

Test-driven development is also required: Unit tests and system tests must be created as each new user story is developed; these will serve as detailed specifications. All existing tests should be run every time the system is updated, and 100% test pass rate is expected.

The project must be open source on a platform such as GitHub. It must use an open license such as the MIT license.

If issues arise with Umple’s semantics, or if bugs are found in Umple, they must be raised as issues in the Umple bug tracking system.

It is requested that project team members each maintain a detailed log of their experiences in their projects’ wiki. Records of team meetings should also be maintained in the project wiki.

Environmental Constraints

The project must be written in Umple; anything that can be done in Umple should be in Umple.

In particular, to the greatest extent possible all new classes must be written in Umple, relationships among classes must be modeled using UML/Umple associations, and behavior should, be modeled using state machines. Other features of Umple should be used where applicable, including language generation templates, concurrency capabilities, aspect orientation, traits and so on.

Code must be generated from the Umple, and generated code must not be edited, following Umple’s philosophy. Methods need to be embedded in Umple classes. Umple’s ‘before’ and ‘after’ constructs can be used to adapt the behaviour of generated code.

The generated language may be Java, PhP, C++ or a combination.

Third party code or libraries may be reused and linked to the Umple-generated parts of the system, provided the reused code uses a compatible license to rest of the system. It is permissible to modify such code to a limited extent if absolutely necessary and if the license of that code permits it. If major adaptations of existing code are contemplated, then it is strongly asked that ‘umplification’ of that code be first undertaken.

Since the Sponsors primarily use Apple OS X, Apple iOS and Linux machines, it must be possible for the game to run on one or more of these platforms. That does not preclude it also running on Windows, Blackberry and Android platforms.

Level of Sponsor Involvement

The sponsor of this project would be interested in regularly reviewing and giving feedback and help regarding the use of Umple throughout the period of the project. The extent of that help will depend of the total number of teams that undertake to use Umple.

The Sponsor will endeavor to allocate a student to help fix any bugs in Umple, should they arise, and/or the Sponsor will help the team find a workaround. That said, it needs to be understood that Umple is still undergoing research and when its boundaries are pressed, unexpected issues may arise. The project team should therefore be prepared to, in an agile fashion, adapt their project to work around Umple issues that cannot be immediately solved. The Sponsor will consider submission of fixes to the Umple compiler as an integral part of the work of this project.

Sponsor contact: tcl (at) eecs.uottawa.ca . Other members of the Umple team may also become contacts for groups.

Project Restrictions

The restrictions have already been described above. The most important one is that Umple be used.