Final Project: Repository and Test Bed System - Software Engineering Studio | CSE 784, Study Guides, Projects, Research of Software Engineering

Download Final Project: Repository and Test Bed System - Software Engineering Studio | CSE 784 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

Final Project

Repository and Test bed System

A-Level Specification

Version 1.

Vijay Appadurai

12 October 2005

Repository and Testbed System (RTS)

1. Introduction:

The Repository Testbed System is designed to help manage and test code

produced in a large software development project. Repository and Testbed has

facilities for:

 Source code check-in, check-out and versioning.

 Defining, building, and executing test configurations remotely.

 Reporting test results.

Figure 1 – Repository and Testbed System Context Diagram FileInfo Requests (^) Files Repository Testbed Directory Services Network Services User Interface controls Display Information Messages Messages, Connection Requests User Commands Status Messages, error messages Test results, path, help info

Repository Server Testbed Server RT Client File Manager Test Harness Communication Component Manager Version Control Test Configurer Checkinout Manager Builder

Figure 2 – Repository and Testbed System Package Diagram

2. Reference Documents: 1. Repository and Testbed System Preliminary Architectural Concept, 25

September 2005.

2. Repository and Testbed System Statement of Work, 25 September 2005.

3.1. Functional Requirements The Repository and Testbed System supports the control, building, and testing of project code. 3.1.1. The Repository Server shall support check-in of items and test configurations from RT Clients. 3.1.2. Each check-in shall result in creating a new version number for the checked-in item and the marking of the item with a unique identifier^1. Any source code and documentation files supplied for this checking process shall be given new version numbers. All of these presented files shall then be stored in the Repository. 3.1.3. Check-in shall succeed only if the check-in process presents to the Repository Server an item file and all the files to which it refers, if those files do not already exist on the Repository Server. Also, check-in shall succeed only if one of the following two conditions is satisfied: 3.1.3.1. the item file is un-versioned, has no unique identifier, and the Repository Server does not contain another item with the same name^2. 3.1.3.2. the item file is versioned, has a unique identifier, latest version is closed, and the user requesting check-in is authenticated as the item’s Responsible Individual (RI). 3.1.3.3. Check-ins shall support an open version status. When open an item may be modified without changing its version by accepting new references to items and files or changing an existing reference. 3.1.4. Insertion of items which were previously open shall result in overwriting the previous files with the newer ones. Making a previously open item as closed during Insertion shall result in overwriting the previous files with newer ones and marking the item as closed. 3.1.5. Check-ins shall fail if the any of the items referenced by this item is open. 3.1.6. The Repository Server shall allow only the Responsible Individual of the item to change its status from open to closed. Once closed, the Repository Server shall not allow its status to be changed to open. 3.1.6.1 The Repository Server shall support only one RI for each module. 3.1.7. The Repository Server shall support check-out of items and test configurations by RT Clients. For check-out to succeed, the Repository shall authenticate the user as RI for the requested item and shall identify the item as checked out^3. Once checked out, the Repository Server shall support cancellation of check-out if requested by the user. 3.1.8. Check-outs of items which have previously been checked out shall fail. 3.1.9. Check-outs of old versions of an item shall fail. 3.1.10. Check-outs of an item with open status shall fail. 3.1.11. The Repository server shall provide a link to every item that is checked-in in a super component. Deletion of a component shall result in a link being removed from the super component. 3.1.12. The Repository Server shall have the hash values of all the referenced files in their item manifests. 3.1.13. The Repository server shall support browsing of all versions of an item. 3.1.14. shall support extraction of components^4 and test configurations by either the Testbed Server or RT Clients, using a Component Manager. No authentication as RI is required for extraction. Extracted items shall have their unique identifiers removed^5. 3.1.15. The Component Manager shall support stopping extraction at any time. 3.1.16. The Component Manager shall support multiple file uploads and extractions. (^1) Check in results in a new item being placed in the Repository, not the replacement of the older version. Thus, every item, once checked-in, becomes immutable. (^2) It may be necessary to use namespaces as part of the Repository’s naming convention. (^3) It is recommended that this be accomplished by marking each checked-out item with a secure hash which is also stored on the Repository Server. The stored hash would then be compared with the item’s hash to authenticate subsequent check-in. (^4) Extraction is accomplished by getting the files of the first item from the repository server and then recursively requesting referenced items from the repository server. (^5) Note that this implies that an item may be cloned by extracting from the Repository, given a new name, and presented for Check-in, starting a new version sequence. This is the accepted way to start a new branch of the versioning sequence, e.g., by starting with the branch as a new version root.

3.1.17. The Component Manager shall support scope for the extraction operation that is one of the following: (a) source code, (b) test and source code (c) all files including documentation or (d) only Xml Manifests. 3.1.18. Both check-out and extraction shall transfer only versions of files not currently existing on the target. This implies the presence of file caches on both the Testbed Server and RT Clients. 3.1.19. shall use Base64 conversion to transform files into strings that will become bodies of XML messages. 3.1.20. shall verify the hashes in the items’ manifests with the hash of the downloaded file. 3.1.21. shall support creation of items and test configurations on RT Clients^6. 3.1.22. Creation of an item shall consist of the creation a named XML manifest file that refers to all the items and files the item depends on directly. Each item shall define an Responsible Individual and shall provide keywords and a small amount of text describing the item^7. 3.1.23. Creation of a test configuration shall consist of creation of a named XML manifest that refers to one or more test source code files. Each test configuration shall provide a small amount of text describing the purpose of the test. 3.1.24. RT Clients shall support the creation of a test configuration by composition with existing configurations. 3.1.25. The Test Configurer shall allow the user to browse through test descriptions and configuration descriptions, to configure a new test run, composed, perhaps, of merging two existing configurations and adding new test libraries. That shall check-in the test configuration and extract files that make up the configuration, from the repository. 3.1.26. The Testbed Server shall support the execution of test configurations. All components and test configurations placed on the Testbed Server shall be transferred only from the Repository Server, using its extraction process. This transfer shall occur when an RT Client requests test execution of a configuration that does not currently exist on the server. 3.1.27. Upon receiving a request to execute a test configuration, the Testbed Server shall verify that a build exists for that configuration. If not, the Testbed Server shall request an extraction of the configuration and its corresponding components and build the required libraries that will be loaded by the Test Harness for execution^8. 3.1.28. The Test Harness shall log all results for each test configuration execution in the testbed server with a testing summary including all test module names, and pass or fail status for each. and send it back to the RT Client. 3.1.29. The Test Harness shall record time-date stamps for each test configuration execution. 3.1.30. shall support the display of test results on the RT Client requesting the execution of a specified test configuration with a testing summary including all test module names, and pass or fail status for each. 3.1.31. shall support the execution of test configurations on RT Clients for components and configurations. These are not required to originate from the Repository Server. 3.1.32. The Test Harness shall support the concurrent execution of test configurations. 3.1.33. Any RT Client shall be allowed to request a test execution without the authentication as the test configuration Responsible Individual. 3.1.34. The Testbed Server shall direct test output to the requesting RT Client. The Testbed Server shall also accept requests to change between quiet and verbose output modes. The Test Harness shall request tests to change mode on receipt of an output mode change request^9. (^6) It is desirable, but not required, that this be accomplished by drag and drop operations in the RT Client interface. (^7) Typically, this will be a phrase consisting of a few words. (^8) Note that builds do not get out-of-date. All components and test configurations are immutable. When an RT Client checks-in a new item, a test configuration for that version must be created in order to run tests against that version.

3.2.1.3. The User Interfaces shall delegate all operations, not directly associated with providing the user interfaces, to server modules, e.g., Communication, Data Management and all operations specifed in this document. 3.2.1.4. All modules shall be provided with manual pages and correct maintenance pages. 3.2.1.5. Each server module shall be provided with a test configuration that is held by the Repository Server and can be executed by the Testbed Server on request from an RT Client. 3.2.1.6. Code that implements services shared by Repository, Testbed, and or RT Clients shall be implemented with identical code, with the possible exception of configuration files^14. 3.2.2. Development 3.2.2.1. The Repository and Testbed development process shall use the Repository Server, Testbed Server, and RT Clients for final integration and for Qualification testing. 3.2.3. Development Environment 3.2.3.1. The Repository and Testbed System shall build and operate in the ECS clusters, e.g., 010 Link, 202 Link, or 2-122 CST. 3.2.4. Program Management 3.2.4.1. The Repository and Testbed System shall be developed subject to the conditions specified in the Repository and Testbed System Statement of Work, of the latest version. (^14) It is expected that each shared service is implemented by a single team, with the consultation of other affected teams.

Changes: REQUIREME NT VERSION 1.1 VERSION 1. 3.1.3.2 (^) the item file is versioned, has a unique identifier, and the user requesting check-in is authenticated as the item’s Responsible Individual (RI). the item file is versioned, has a unique identifier, latest version is closed, and the user requesting check-in is authenticated as the item’s Responsible Individual (RI). 3.1.3.3 (^) Check-in of open items which were previously open results in overwriting the previous files with the newer ones. Insertion of items which were previously open shall result in overwriting the previous files with the newer ones. 3.1.4 (^) Making a previously open item as closed during Check-in results in overwriting previous files with newer ones and marking the item as closed. Making a previously open item as closed during Insertion shall result in overwriting the previous files with newer ones and marking the item as closed. 3.1.7 (^) The Repository Server shall support check-out of items and test configurations by RT Clients. For check-out to succeed, the Repository shall authenticate the user as RI for the requested item and shall identify the item as checked out. The Repository Server shall support check-out of items and test configurations by RT Clients. For check- out to succeed, the Repository shall authenticate the user as RI for the requested item and shall identify the item as checked out. Once checked out, the Repository Server shall support cancellation of check-out if requested by the user. 3.1.37 (^) Each RT Client shall support a user interface providing operations for creating items and test configurations, checking items and test configurations in and out of the Repository Server, cancel checkouts and requesting test executions on the Testbed Server and pausing, resuming or stopping running tests, change between quiet and verbose modes. The RT Client interface shall also support the removal of specified files from the Client’s file cache. Each RT Client shall support a user interface providing operations for creating items and test configurations, checking items and test configurations in and out of the Repository Server, cancel checkouts and requesting test executions on the Testbed Server and pausing, resuming or stopping running tests, change between quiet and verbose modes. The RT Client interface shall also support the removal of specified files from the Client’s file cache.  Modified Data Flow Diagram  Added Repository Server Version Control State Diagram  Added State Table for Repository Server

Partitions: Repository Server: The Repository Server Team implements the Repository Server , the Checkinout Manager and the Version Control system. The Team is responsible for satisfying the following requirements. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1. 3.1.

Communication:

The Communication Team implements the Communication , the Component Manager

Test bed Server: The Test bed server team implements the Test bed Server , the Test Harness and the

• 3.1. and the File Manager The Team is responsible for satisfying the following requirements.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1. Team is responsible for satisfying the following requirements.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1. Builder The Team is responsible for satisfying the following requirements.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.
• 3.1.

CRITICAL ISSUES: Scanning: Problem: Traversing through the repository structure is accomplished by recursively scanning the manifests. Since the software dependency structure resembles a graph, it may result in scanning the same items over and over again. Possible Solution: Maintain a hash table of all the items visited and lookup this table before scanning the next items’ manifest. Deletion from Repository: Problem: Deletion of an item from the Repository should be done only when no other item is referencing it. However there is no way to identify directly if some other item is dependent on the item which we want to remove from the repository. Possible Solution: This can be done by keeping track of the number of references for each item in the super component. During check-in and check-out by the repository, we can add or subtract the number of references by comparing the previous references with the newer ones. Test Harness Loader Memory Problems: Problem: The Test Harness loads a set of test dlls continuously and executes tests on each one of them. When the number of dlls become large, the test harness may not have sufficient memory to load more dlls. Possible Solution: This can be overcome by loading the dlls in a child AppDomain instead of loading directly into the primary AppDomain. The child AppDomain can be loaded and unloaded dynamically and so it can load and unload dlls dynamically. Loader Locking Problems: Problem: The Test Harness runs each test configuration in a separate thread. It is possible that two test configurations can depend on a single build. If the loader in one of the threads is using a build’s dll or exe, it takes a read lock on the file to ensure that no changes are made to the underlying executable image, thus preventing other loaders from using it and hence severely affecting performance. Possible Solution: Loading the dll or exe by “Shadow Copying” solves this problem. It is recommended that shadow copying be enabled for each thread’s AppDomain. CLR Loader Optimization: Problem: The Test Harness will have Multiple Application Domains running at the same time. Since the JIT compiler generates code separately for each AppDomain by default, it becomes highly inefficient to load and compile code for common libraries from the GAC for each AppDomain. Solution: The Problem can be solved by using the Loader Optimization in the CLR. When the Loader optimization value is set to MultiDomainHost , it has a single copy for assemblies from the GAC and separate copies for the assemblies of local applications. Furthermore, the Test Harness can have a ability to start either in MultiDomain or MultiDomainHost mode, since using MultiDomain mode can help in sharing compiled code for assemblies shared by two

Item Type Item’s Previous Status Item’s requested Next State Action Unversioned N/A open Create new item in repository as Version 1 and mark item as open and status as “not checked out” Unversioned N/A Closed Create new item in repository as version 1 and mark item as closed and status as “not checked out” Versioned Checked-out Open Create next version and mark item as open and status as “not checked out” Versioned Checked-out closed Create next version and mark item as closed and status as “not checked out”

Appendix:

Repository Server:

Check-In:

Any other combinations of check-in shall fail.

Insert:

Item’s previous status Item’s previous state Item’s next state Action Not checked out and is the latest version of the item Open Open Insert new files in place of older files Not checked out and is the latest version of the item Open Closed Close the version and mark item as closed Any other combinations of insert shall fail.

Check-Out:

Item’s Previous Status Item’s previous state Action Not Checked out and latest version of the item Closed Send files to client and mark the item as checked-out Any other combinations of check-outs shall fail.

Extract:

Any item can be extracted from repository at any time.

Delete:

Allow if no other item is referring to this item.

Unversioned Versioned, Open, Not checked out, latest version Versioned, Closed (immutable), not checked out, latest version Versioned item, closed (immutable), checked out, latest version Check-in, mark open Check-in, mark closed Insert, close Insert, Open Check-out Check-in, closed Check-in, open Increment Version Cancel check-out Increment Version

STATE DIAGRAM FOR REPOSITORY SERVER