EMU/SRS
Revision as of 09:09, 27 April 2006 by Barnski  (Talk | contribs) (→EMU-IDE integration:   changed to: ES integration)
Contents
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
The Log helps the users to know what has changed during their last login. It is also used as a look-up table for synchronisation with the clients. 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...).
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.
ES 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
 

