1. Introduction
1.1 Purpose
The purpose of this Software Design Specification (SDS) is to present the design concept for eccvs, a version control system. The SDS is a tool for implementing the project and guide for the design review process. This SDS focuses on the high level structures of the project.
1.2 Scope
eccvs is a version control system, intended to perform software configuration management. The user interacts with the system through the sophisticated GUI that makes the version control simpler and easier. This system will enable the user to perform only the basic and much needed functionalities of version control. The main objective of this software is to provide an uncomplicated version control mechanism to the novice user.
1.3 Definitions, Acronyms and Abbreviations
- CVS - Concurrent Versions System
- eccvs - easy concurrent versions system
- GUI - Graphial User Interface
- NA - Not Applicable
- Widget - A standardized on-screen representation of a control that may be manipulated by the user.
1.4 References
- Software Requirements Specification for "eccvs", Version-2.0
- Object Oriented Systems Development by Ali Bahrami, 1999, McGraw Hill Publications
- UML Distilled by Martin Fowler
- UML Reference Guide by Grady Booch, Ivar Jacobson, and James Rumbaugh
- http://cvsgui.sourceforge.net/ - for the cvsgui protocol version-1.0
- http://www.cvshome.org/docs/ - "The Cederqvist" by Per Cederqvist et al
- http://cvsbook.red-bean.com/ - "Open Source Development with CVS, 3rd Edition" by Moshe Bar and Karl Fogel
- http://www.cvshome.org/ - CVS home page
1.5 Overview of Document
The section-2 of this document identifies the components and subsystems of this project, their interrelationships and user interface issues. Section-3 presents the detailed information of each identified component followed by the description of design decisions made in this software development process in the next section. The document is arranged in such a way that the information is more grained as we progress through it.
2. System Architecture Description
2.1 Overview of Modules/Components
This project is broadly viewed as composure of five modules:
- CvsInterface module - Carries out the user requested feature by interacting with the CVS tool through the "cvsgui" interface protocol.
- MainUI module - Presentation module to enable the user to interact with the system.
- Input module - Provision to read the input from the user and it packs the data along with values read from global settings.
- Output module - Module to present the output as well as error information to the user.
- Parser module - Analyzes the error and output streams, based on the status value, and gives the structured information.
2.2 Structure and Relationships
The relationship among the various components identified is shown below. As shown in the diagram, the user interacts with the MainUI module to activate any funtionality of his concern. After the functionality is triggered, the Input module (for that functionality) gets the input from the user (if necessary) and packs it in a particular format. This packed input is passed to the CvsInterface module to actually execute the intended funtionality. Once the CVS process is completed, the Output (of this process) is parsed by the Parser module. The Ouput module takes care of displaying the parsed output to the user.
The following Class diagram shows the relationships among various classes that constitutes the CvsInterface Module. Although it doesn't have an hierarchical structure, the aggregations and associations are concrete.
The Input abstract class has a generic public interface that can be used to derive other functionality classes. The following hierarchical diagram shows the relations between various input classes.
Since all the functionalities have common procedure to process the output, the Output class is kept common. The Ouput class simply needs to show either the ouput or the error or both based on the parser's return code.
The Parser abstract class with its member funtions with public visibility is shown below. The specific functionality parser classes have to be derived from this abstract Parser class.
2.3 User Interface Issues
The users of the system are differentiated with their usage style and way of activating the feature. Hence all the user classes identified in the SRS will have a generalized user interface whose sketches are included as follows:
|
|
| The MainUI without Browser and misplaced CvsToolbar |
|
|
| The Browser widget in old-eccvs-MainUI-layout |
3. Detailed Description of Components
3.1 Component Template Description
| Identification |
The unique name for the component |
| Type |
A module, a sub program, a data file, a control procedure, a class, etc |
| Purpose |
Function and performance requirements implemented by the design. |
| Function |
What the component does, the transformation process, the specific inputs that are processed, the algorithms that are used, the outputs that are produced, where the data items are modified. |
| Subordinates |
The internal structure of the component, the constituents of the component, and the functional requirements satisfied by each part. |
| Dependencies |
How the component's function and performance relate to other components. How this component is used by other components. The other components that use this component. |
| Interfaces |
Detailed descriptions of all external and internal interfaces as well as of any mechanisms for communicating through messages, parameters or common data areas. |
| Resources |
A complete description of all resources external to the component but required to carry out its functions. |
| Processing |
The full description of the functions presented in the function sub section. |
| Data |
For the data internal to the component, describe the representation method, initial values, use, semantics and format. |
3.2 MainUI Module
| Identification |
MainUI, the main user interface module |
| Type |
A module (collection of classes) |
| Purpose |
This module acts as a launch pad for every other functionality offered by this system.
Although this module doesn't implement any user stated requirements, it is mandatory derived requirement, which actually improves the usability of the system. |
| Function |
Whenever the user activates a particular functionality (through Menu and Tool bar subsystem or Context menu), this module gets the relevant data from Browser, and creates Input, Parser and Output objects of the corresponding functionality.
The collected information is then sent to a generalized subroutine (executeCmd), which actually executes the command (functionality). |
| Subordinates |
MainUI contains various modules, which include:
- Menu and Toolbar subsystem
- Notebook subsystem - deals with queuing multiple pages of interface elements
|
| Dependencies |
This module depends on Browser module and executeCmd subroutine to carryout its function. |
| Interfaces |
This module provides an application level UI which consists of menus, toolbars, and status bar along with the main notebook component which takes care of queuing the multiple output widgets. |
| Resources |
NA |
| Processing |
NA |
| Data |
NA |
3.2.1 Browser Module
| Identification |
Browser, the working copy browser |
| Type |
A module (Collection of classes) |
| Purpose |
This module enables the user to browse through their working copy with differentiated content (files/directories) based on their status. It does also provide context menu that depends on the (file) selections in the browser. |
| Function |
Whenever the user activates a directory, the browser simply sends request to the CvsFileSystem module, which returns the content of that directory along with status information. The browser renders the content (files and/or directories) in its window with differentiating icons and emblems. |
| Subordinates |
It consists of the minor components like the one that deals with emblems and icons. |
| Dependencies |
The MainUI module uses this module to view the working copy contents.
This module depends on CvsFileSystem module, which actually provides the directory contents along with their status information.
It also depends on the MainUI module to get context menu stuff. |
| Interfaces |
This is an UI component, which displays directory contents using captioned icons. |
| Resources |
NA |
| Processing |
This module maps appropriate emblem for a given file system entity. |
| Data |
NA |
3.2.1.1 CvsFileSystem Module
| Identification |
CvsFileSystem |
| Type |
A module (Collection of Classes) |
| Purpose |
The sole purpose of this module is to provide a list of files and/or directories along with their status information contained in a given directory. |
| Function |
The input to this module is a directory. It simply gets the contents of the directory from File System module and merges it with the information obtained from CVS Entries file (if exists). The merged list is the output. |
| Subordinates |
NA |
| Dependencies |
This module depends on the File System module, which is a wrapper for file system related operations.
The browser module obtains the output from this module. |
| Interfaces |
NA |
| Resources |
NA |
| Processing |
This module merges two height-balanced trees (one with directory content and the other with CVS Entries content) to superimpose the CVS information on the directory structure. |
| Data |
Height balanced trees (with the above mentioned content) are used for faster searching during the merging operation. |
3.2.2 executeCmd Function
| Identification |
executeCmd |
| Type |
A function or subroutine |
| Purpose |
Its main purpose is to execute the given command. |
| Function |
This function accepts the Input, Output, and Parser objects as input parameters. It uses the public interface of these objects to access their services.
It gets input relevant to the corresponding functionality using the Input object and executes the CVS using CvsInterface module. The output from the CvsInterface is then passed to the Parser object, which produces structured output. This output is then given to the Output object, which displays it to the user in a methodical way. |
| Subordinates |
NA |
| Dependencies |
This subroutine depends on CvsInterface to actually execute the required functionality. MainUI module uses this subroutine to execute activated (triggered) functionality. |
| Interfaces |
NA |
| Resources |
NA |
| Processing |
NA |
| Data |
NA |
3.3 CvsInterface Module
| Identification |
CvsInterface |
| Type |
A Module |
| Purpose |
Carries out the user chosen activity by interacting with the CVS tool through the "cvsgui" interface protocol. |
| Function |
Gets the packed data from the MainUI module and performs the execution. Requires the username and password details in case of remote repository access. Returns the exit code of the process to the calling module. |
| Subordinates |
Constitutes the following classes to accomplish its functionalities:
- UcvsPass - Class to authenticate the user during remote repository access.
- UcvsBusy - Aggregate class to inform the progress of the currently active process to the user.
|
| Dependencies |
Used by the MainUI module as soon as the control is returned from the input module. |
| Interfaces |
Provides the user with the option to view the progress of the process through selective console. Error and information to be displayed to the user will be done using the dialogs. Intimates the user with progress bar for time consuming process. |
| Resources |
cvsgui is a protocol used here to carry out its functions. |
| Processing |
Execution of the feature is carried out by calling the appropriate methods of the interface protocol. User is intimated about the process through the dialogs and progress bar. |
| Data |
NA |
3.3.1 UCvsBusy Class
| Identification |
UcvsBusy |
| Type |
Aggregate Class |
| Purpose |
Serves to inform the user regarding the progress of the undergoing process. |
| Function |
Mainly notifies the user with the progress bar about the process. The progressively collecting details can be shown to the user if required.
Contains procedure to show or hide console depending on the action taken by the user. |
| Subordinates |
Constitutes the following class to accomplish its functionalities:
- UCvsConsole - Class to show the process details in a console.
It also contains procedures to show the progress bar.
|
| Dependencies |
Depends on the CvsInterface module to get activated. For displaying purpose, UCvsConsole class is used. |
| Interfaces |
Displays the content retrieved during the execution of CVS functionality to the user. |
| Resources |
NA |
| Processing |
NA |
| Data |
NA |
3.3.1.1 UCvsConsole Class
| Identification |
UCvsConsole |
| Type |
Class |
| Purpose |
To show the progressive output to the user. |
| Function |
Displays the output of the ongoing process continuously as the process is progressing. |
| Subordinates |
NA |
| Dependencies |
Depends on the UCvsBusy class to read the choice of user regarding whether to show or hide output console. |
| Interfaces |
A simple widget to display the progressive output given by the UCvsBusy module. |
| Resources |
NA |
| Processing |
NA |
| Data |
NA |
3.3.2 UCvsPass Class
| Identification |
UCvsPass |
| Type |
Class |
| Purpose |
Deals with the login issues during remote repository access. |
| Function |
UCvsPass simply gets the password required to login into a remote repository and returns it to the UCvsInterface module. |
| Subordinates |
NA |
| Dependencies |
Depends on the UCvsInterface module to get the remote repository details entered by the user. |
| Interfaces |
Displays the login window to the user with username already entered. |
| Resources |
NA |
| Processing |
The window to read password will be displayed with user name field filled. This is accomplished with the help of UCvsRoot class, which will provide the necessary details about the remote login. |
| Data |
NA |
3.4 Input Module
| Identification |
Input |
| Type |
Abstract class |
| Purpose |
Defines the public interface to get the input arguments. |
| Function |
Intended to read the inputs from the user, validates the given details and packs them in the appropriate format. Global preference values are also taken into consideration during packing process. Produces the packed data as output along with the current directory information. |
| Subordinates |
Constitutes the following modules to accomplish its functionality:
- CvsArgs - Class to pack the input data in the appropriate format.
|
| Dependencies |
Used by the MainUI module to get input from the user.
Each functionality has to implement this input interface, so that the execution of the same (using executeCmd) can be made generic. This will make the design extensible.
|
| Interfaces |
If validation fails, it will provide an error message to the user and requests the user to feed details again. |
| Resources |
NA |
| Processing |
Validation of inputs is carried out. |
| Data |
NA |
3.5 Parser Module
| Identification |
Parser |
| Type |
Abstract class |
| Purpose |
Defines the public interface to extract the needed information from the raw stream of data.
|
| Function |
It accepts the exit status, output stream, and error stream of the CVS process as input and decides which stream should be scanned based on the exit status.
Then the actual parsing process is carried over to produce the required output.
|
| Subordinates |
NA |
| Dependencies |
Used by the MainUI module to parse the output.
Each functionality has to implement this parser interface, so that the execution of the same (using executeCmd) can be made generic. This will make the design extensible.
|
| Interfaces |
NA |
| Resources |
NA |
| Processing |
Processing of the output differs for the each and every functionality (that would be derived from this abstract class).
|
| Data |
The captured output and error stream data of the CVS process. |
3.6 Output Module
| Identification |
Output |
| Type |
Abstract class |
| Purpose |
To show the output (details, confirmation or error message) to the user. |
| Function |
Receives the parse status, output widget and error widget as input.
If the parse status is SUCCESS then requests the MainUI module to append the output widget.
If the parse status is ERROR then show the error widget in a new window.
If the parse status is PARTIAL then append the output widget in MainUI and show the error widget in a new window.
|
| Subordinates |
NA |
| Dependencies |
Used by the MainUI module to display the output.
This module also requests the MainUI module to append the output widget. |
| Interfaces |
The UI of this module can have either the output widget or error widget or both.
|
| Resources |
NA |
| Processing |
NA |
| Data |
NA |
4. Reuse and Relationships to Other Products
We have designed the software modules with adequate foresight so that whatever we implement can finally be extended and implemented later on a larger scale with added features.
5. Design Decisions and Tradeoffs
The decision to use "cvsgui" protocol to communicate with the CVS process has reduced the design complexity. It also ensures the reliability of the communication.
6. Pseudo-code for Components
Not Applicable
7. Appendices
The following screenshots illuminate few UI elements of the eccvs.
|
|
| The UCvsBusy Widget with UCvsConsole in action |
|
|
|
| Password Authentication Dialog |
Progressbar in action |
 |
| Sample Message Dialog |
Change Log for the SDS
- January 28, 2005: The initial version released
|
