Collaborative DRE (CDRE) was created to allow DRE to be utilized in a real-world distributed environment. It functions as part of a client/server architecture, where individual workstations contain only the code necessary to view and operate the DRE metrics calculator, and centralized data and application servers provide the bulk of the DRE operation software. Instructions for the Standard DRE provides a good introduction to the basics of CDRE as well; we suggest that you review this section of these help files, as most of the interface between DRE and CDRE is exactly the same. Differences between the two operations will be covered here.
As CDRE is distributed, some extra configuration and requirements are necessary to get the software running. Configuration instructions for CDRE Clients and CDRE Servers are provided separately. However, both client and servers have some common requirements, listed here:
Click on a topic or scroll down to view the help information.
As CDRE works over the network, a user must authenticate himself by logging into the remote server before he can use it. The main display now includes an extra menu on the menu bar. From this menu, the "Login" function can be selected.
When the user selects the login function, he will be prompted with a userID and password dialog box. The user ID and password must be valid or the user will receive an error message.
Note that if the user does not log in before attempting to use the remote system, he will be prompted to log in immediately.
User IDs are not simply used as authentication devices. Permissions are granted based on user ID, and this will affect what the user is allowed to access and alter. Details of these will be discussed in following sections.
Group access has also been designed in the system. Implementation is not complete, meaning that it is currently disabled, but eventually group membership will enhance user permissions.
In DRE, the user defines Projects locally, and all relation/generality markings are features of the Project. The user needs to save a Project every time he has made changes to it. Projects are stored as flat text files on the local hard drive, and must be located by the user when re-opening them.
CDRE changes these rules somewhat. Unlike DRE, where a default Project may be used to run the metrics, CDRE requires that a named project be created before it be populated with classes. Class marking information is separated from Project data; as these markings belong to the classes, not to the Projects, the markings are stored elsewhere, and the Project data only contains the listing of classes that belong to the Project. This data is stored in a database, meaning that the user is no longer required to "save" a Project; all changes are stored instantly. In addition, CDRE keeps track of all Projects that a user can access, and presents that list to the user when he wishes to open one automatically.
Any user may create a Project, and he will be the only person allowed to view/alter the project. However, this owner can grant permissions to other users of CDRE. Under the "Project Administration" menu, an owner has the power to change lists of owners, manipulators, users, and groups. General users are people who have access to view the Project and run the metrics; the owner of the Project can add any or all users of CDRE to be users of his project. Manipulators are users that have the added ability to alter the contents of the Project; manipulators may be team members who have created their own classes that are involved in the Reuse calculations, and they can add their new classes to the Project contents. Owners are super-users, who have access to run metrics and change the contents of a Project, but also have full control of the Project, including creation/deletion of the Project and assignment of users to the project. Whereas each project contains at least one owner, manipulators and general users are unneccessary. Future work will enable groups of users to have general user access. To change any of these lists, an owner must use the "Project Administration" menu to alter the menu list that he wishes to change (red indicates owners, blue indicates manipulators, and black indicates general users).
All source files that contain classes exist need to exist on the server, so that the running metrics will be able to parse and classify the couplings of the code. To that end, adding source classes to a project utilizes a remote file selector. This selector allows the user to view the directories and source file contents of the remote server. (Note that the remote server's file permissions may be limited by the operation system login ID under which the DRE Server is running). A user can add classes to his project using this selector in the same way that he would do it locally on standard DRE.
Remember that generality and relation markings are now stored with the class data, not with the project. Therefore, this information is persistent, even after the project in which it is first defined is destroyed. As such, class ownership is a new feature of CDRE. By defeault, the first user that opens up a class, in any project, becomes the owner of that class. He is the only one allowed to set the generality and add or remove relations on that class. This occurs, because it is assumed that only the developer who has coded the class fully understands its workings. Any user who has access to DRE can reuse his class, and its associated markings, but only the owner can alter the class' definitions. As with Projects, a "Class Administration" submenu allows the owner to classify other DRE users as owners of the project, allowing them to change the markings also. Future work will involve listing groups as owners of classes also. To activate these changes, select the class whose ownership is to be changed, and choose the appropriate menu selections. If the menu selections are disabled (greyed-out), then the current user is not the owner of the selected class, and cannot change its ownership.
CDRE functions in the same method of DRE for these other topics. Setting generalities and relations occurs in exactly the same fashion; although the persistent storage is in a different format, it is blind to the user who can operate the exact same controls to set this information. Remember, thought, that a user can only change these markings on classes in which he is listed as an owner. Calculation of the metrics occurs in the same mode, but occurs on the server instead of the client, with the resulting information passed over the network to the client. Simulation is currently disabled for CDRE; its future is questionable.