EMU/SRS

Revision as of 10:05, 27 April 2006 by Barnski (Talk | contribs) (Change-Log)

The Parts

  • EMU-Protocol
  • EMU-Server
  • EMU-Client
  • EMU-IDE integration

Developer Requirements

EMU-Protocol

defines Client/Server communication with

  • client/server states
  • available messages
  • client/server actions

EMU-Server

  • stores and manages code-repository
  • synchronizes code of clients
  • manages Locking-System
  • Account-System
  • project update
  • add/create new code (classes)
  • change-logging
  • optional: Media-upload
  • optional: BackUp-System
  • optional: Release-versions
  • optional: Server-Admin-Tool

Locking-System

  • list of locked code
  • check if code (class) is locked
  • lock / unlock code (class)

Code-Synchronization

  • broadcast code-changes
  • bring user code up to date

Account-System

The server uses an account-system to organize its projects and users. Every project has its own users assigned.

Project-Accounts

  • project name
  • project-admin(s)
  • user lists
  • project status
  • editable / creatable with a project-admin-tool

User-Accounts

  • usernames
  • used for logins
  • assign locked code & changes to users
  • online status

Change-Log

Every lock/unlock action is logged with following data:

  • user name
  • date and time
  • type of action
  • code element (class name)

Additionally, it provides the possibility for the user to add comments (e.g what he changed, what doesn't work yet...) The Log helps the users to know what has changed during their last login.

EMU-Client

  • interface for IDE and server
  • provides features to login and communicate with server on an abstract base
  • upload/download code elements to/from server
  • notify IDE of server-messages (code-updates)
  • modular / independent of IDE-integration
  • optional: upload media files

IDE-Notifications

The client needs to notify the IDE of the new changes.

EMU-IDE integration

  • minimal change to existing ES-classes and features.
  • modular integration: activatable and removable / hideable


User Requirements

  • easy to use
  • target is a small project group of up to 20 developers.
  • code synchronisation process mostly hidden from user
  • minimal extra work (less total work)
  • better efficiency