Downloads Screenshots FAQ

Software Design Specification for "eccvs"

Version 1.0
January 28, 2005

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

  1. CVS - Concurrent Versions System
  2. eccvs - easy concurrent versions system
  3. GUI - Graphial User Interface
  4. NA - Not Applicable
  5. Widget - A standardized on-screen representation of a control that may be manipulated by the user.

1.4 References

  1. Software Requirements Specification for "eccvs", Version-2.0
  2. Object Oriented Systems Development by Ali Bahrami, 1999, McGraw Hill Publications
  3. UML Distilled by Martin Fowler
  4. UML Reference Guide by Grady Booch, Ivar Jacobson, and James Rumbaugh
  5. - for the cvsgui protocol version-1.0
  6. - "The Cederqvist" by Per Cederqvist et al
  7. - "Open Source Development with CVS, 3rd Edition" by Moshe Bar and Karl Fogel
  8. - 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:

  1. CvsInterface module - Carries out the user requested feature by interacting with the CVS tool through the "cvsgui" interface protocol.
  2. MainUI module - Presentation module to enable the user to interact with the system.
  3. Input module - Provision to read the input from the user and it packs the data along with values read from global settings.
  4. Output module - Module to present the output as well as error information to the user.
  5. 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:
  1. Menu and Toolbar subsystem
  2. 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 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:
  1. UcvsPass - Class to authenticate the user during remote repository access.
  2. 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:
  1. 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 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:
  1. 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