Download Remote Software Assistant: A Tool for Software Development and Testing and more Exams Software Engineering in PDF only on Docsity!
CSE 784 - Software Studio
CSE 784 - Final Project
Remote Software Assistant
Jim Fawcett version 1. 25 September 2006 Instructions: This is a cooperative project requiring the combined efforts of everyone in the class. Participants will be assigned roles in the project, and grades will be based on:
- how well each of your carries out your assigned role, as measured by products you generate.
- quality of the final product.
- conduct of a series of specification, design, and test reviews leading up to the final product qualification test An Architectural description is provided on the next page, along with additional notes and comments. Also included are job descriptions for each of the roles to be assigned. The project will be completed and a qualification test conducted on Friday, December 8th. Final product delivery of updated specifications and code will be on Monday, December 11.
CSE 784 - Software Studio Fall 2006
Remote Software Assistant
Preliminary Architectural Concept
version 1. Jim Fawcett 25 September 2006
CSE 784 - Software Studio Fall 2006 model structure. The Design Document is populated with details, either through an entry form or manually. v. The Module Builder can also create the code for Test Libraries, directly from the model for each module. This generated code should be directly compatible with the RSA Test Harness, e.g., support the interface expected by the Test Harness. vi. All the documents and code – modules and test drivers – have structures that are designed as part of this project, do not change, other than having information inserted, and are understood by the model builder and parser. vii. The diagrams are intended to be simple, displaying nothing but lines with arrow heads, ovals, rectangles, and names. Clicking on any oval or rectangle pops up a form that displays its information and supports editing, formatted by the underlying XML model structure. Some support for positioning of ovals and rectangles is expected, keeping intact their lines^2 , but no other processing is expected.
- Parsing code and documents to create revised models:
- Documents and code produced by Remote Software Assistant have a specific structure, designed in part to be easily parsed.
- Any code or document, produced by the Software Assistant, and modified by a developer in a manner consistent with the RSA’s model structures, can be parsed to create an updated model. Usually, such updates will consist of adding code to function shells, adding new functions, and adding text to comments created by the model building process.
- The model builder will not generate code or documents unless they are new, or were parsed from existing code or documents. This is necessary to prevent loss of developer modifications by overwriting with a model with less detail.
- Naming Service:
- RSA stores all names of packages, classes, and documents in namespace.declared_name form.
- The Model Builder uses this service to deny use of a name previously assigned to any other developer on the current project.
- Testing Support:
- RSA provides a test harness environment that executes tests loaded in the form of Dynamic Link Libraries. Each library consists of a test interface inherited by all test drivers, a derived test driver, and the code being tested.
- A test harness is part of RSA. It loads tests dynamically and, at the conclusion of testing, issues a Test Report. (^2) It is recommended that each oval and rectangle define a set of connection points to which lines attach. Positioning may be effected by selecting an oval or rectangle and double-clicking on the new location. Initial positioning should be dispersed throughout the Builder window, based on dependency order (given by the arrow heads).
CSE 784 - Software Studio Fall 2006
- A specific test run is defined by a Test Configuration, an XML file that identifies the test libraries to be executed.
- The Model Builder generates test driver shells, for any specified code model. Testing details are provided manually by the developer.
- Code and Document Maintenance:
- RSA provides a Repository for documents and code that supports versioning.
- The interface to the repository will consist of XML messages that support check-in, check-out, and extraction.
- Check-in saves a new version. Check-out extracts an existing version for modification. Extraction sends managed documents and code to a client, but will not allow Check-in of those items.
- A check-in can be either open or closed. i. If check-in is open, then further changes can be made without changing the version number, but no other component is allowed to depend on this code until its version is closed. The Repository should enforce this rule. An open check-in can be closed at any time. ii. If check-in is closed it becomes immutable, and other components are allowed to refer to this version.
- Shared Data:
- RSA provides a shared data service that is composed of three parts: i. A shared dictionary that supports sharing of key-value pairs as data that is accessible and mutable by any application. ii. Storage of messages for later use, perhaps by a disconnected client. iii. A relational database, used by tools, accessed by queries within messages.
- Communication System:
- RSA provides a message-passing communication system implemented with both sockets and web-services.
- Message targets include: i. Repository ii. Test facility iii. Toolset iv. Data manager v. Any client currently registered and logged into the RSA.
- Supported Tools:
- RSA will be delivered with a tools set that consists of newly developed tools and existing tools.
- Newly developed tools include Model Builder, Bug Tracker, Requirements Database, and Change logger, that use the Shared Data resource, provided by RSA, and do all their communication via messages.
- Legacy tools include the source code analyzer, anal, found in the Handouts/CSE784/code directory. Legacy tools are wrapped, as shown in Figures 2, 4, and 5.
CSE 784 - Software Studio Fall 2006 XSL Code Model to Code Transformation Template XML Document Model Template XML Code Model Template Code Document Parser Code Parser XSL Transformation Model Building Tool Figure 1 - Code and Document Generation Concept XSL Document Model to Document Transformation Template XSL Code Model to Document Model Transformation Template Document
CSE 784 - Software Studio Fall 2006 Graphical User I nterface Local Executive Local Application Wrapper Local Library Wrapper Message-Passing Communication Remote Executive Remote Application Wrapper Remote Library Wrapper XML mesages XML mesages XML mesages XML mesages XML mesages XML mesages XML mesages Library procedure calls Application Commandline, File, IPC, Memory-mapped files Library procedure calls Application Commandline, File, IPC, Memory-mapped files procedure calls Library
Figure 2 - Pluggable Remote Executive Architecture
XML mesages Shared Data Management XML mesages
CSE 784 - Software Studio Fall 2006 Wrapper dispatcher PostMsg(msg) msg queue ArrayList of references to registered objects Wrapped Library function call (^) return PostMsg(msg) msg Optional Child thread
Figure 4 - Library Wrapper
CSE 784 - Software Studio Fall 2006 Wrapper dispatcher msg queue ArrayList of references to registered objects Wrapped Application Command line msg Optional Child thread
Figure 5 - Application Wrapper
Redirected File Std Output PostMsg(msg) PostMsg(msg)
CSE 784 - Software Studio Fall 2006
- Tool Set A set of executables that support: Tracking requirements Tracking bugs Recording all changes to code and documents, used by the check-in manager of the repository. Analyzing code held in the repository or in a client’s machine.
- Communication System A facility that: provides the means to send messages between processes in a machine or between machines, using sockets, and across the internet, using web services. Provides facilities, used by all other tools and processes in the RSA, to build and parse messages, including messages that send files from one machine to another.
CSE 784 - Software Studio Fall 2006 +write() +showAll() «interface» ILogger MemoryLogger +test() : bool +registerTest() : void
- ArrayList
- failed : unsigned int tester +test() : bool +title() : string - tout : ILogger - title : string test aTest - Application Specific Test Driver 1 * MemoryStream ConsoleLogger Console FileLogger FileStream +test() : bool «interface» ITest
- 1 class from Tested Module # 1 +GenerateNext() : object «interface» ITestVectorGenerator TestVectorGenerator ApplicationTVG ApplicationFL ApplicationCL ApplicationML Test Harness Concept
CSE 784 - Software Studio
Software Project Manager
The SPM will manage the Remote Software Assistant program, with the help of the Software Architect, Test Manager, and all the Team Leaders.
Software Architect
The Software Architect is responsible for the Remote Software Assistant’s architectural concept and A Specification. A preliminary A-Specification is provided as part of this package, but will evolve as the team and customer negotiate system structure and capabilities. The SA will also provide support for qualification testing.
Software Development Teams
Remote Software Assistant development will be carried out by teams, defined in this document. There will also be a test team, responsible for developing and executing Qualification Test. Each team, with the exception of test team, will:
- produce its own behavior specification^4 , design description, and code
- present their specifications and design during Software Assistant System specification and design reviews
- conduct unit test on their code
- integrate their software with that of the other teams
- participate in final qualification testing
Test Team
The test team will prepare a test plan which contains at least the following:
- A schedule of key milestones and their contents.
- A schedule for integration testing and qualification testing. The integration test schedule will be phased and clearly describe when each team’s software must be available for integration.
- A set of qualification test descriptions, procedures, and definition of all instrumentation, logs, and analyses needed to conduct qualification testing.
- Definition of a process for baselining and accessing test code, including a class build directory structure and error reporting mechanism. Integration testing is the joint responsibility of the development team leaders and test team leader. Qualification testing is the responsibility of the Software Project Manager, supported by the test team and its manager. Each development team will be responsible for developing qualification tests, in collaboration with the Test Team member assigned to them, which implement the tests described in the test plan in for their software, under the joint direction of their team leader and the test team leader. (^4) The form of behavior and design descriptions will be as cited above in the Preliminary Architectural Concept.
CSE 784 - Software Studio
Team Assignments:
- Software Project Manager Rahul Chandrasekaran
- Software Architect Tilakumar Patel
- Test Team and Tool Set Nandita Chakraborti – Team Leader Sandeep Divekar Garima Dixit Aditya Kota Samir Patel Milind Raut
- Model Builder Matthew Vanderhoof – Team Leader Ajay Challa Avinash Gupta Mario Tayah
- SA Client and Executors Rahul Taing Chandresh Karira Kester Marrain
- SA Repository and Data Mgmt Avinash Suresh – Team Leader Rahul Chandrasekaran Simin Zhao Francisco Zurita
- SA Testbed Jay Vora – Team Leader Nandita Chakraborti Akshay Menon Deepak Sindagi
- Communication Manas Kelshikar Naitik Dani Tilakumar Patel Shreya Vyas
CSE 784 - Software Studio
Job Description: Software Architect (SA)
The Software Architect is responsible for the architectural concept, effectiveness and ease of use of the user interface, modularity and robustness of the design. He/She supports the team leaders in developing elegance and quality in the final product. The SA is required to know the entire design and provides support for team leaders during major reviews. He/She has responsibility for consistency and integrity of all requirements with special focus on the user interface. The SA is also responsible for the top-level physical structure, organizing principles, and built in test^5. Built in test should directly support qualification testing. SA participates in all weekly meetings, spending at least some time with each team, making sure they understand the architecture and testbed, and helps with problem solving as needed by each team. The SA is responsible for ensuring that the requirements are sensibly allocated to individual teams and that each team understands their allocation. Responsibilities:
- Prepare an Architectural Concept Document which includes: a. Organizing principles for project including processing partitions for each team b. Definition of user interface c. Definition of, and logical model for, top level processes and data flows, e.g., one DFD per team (worked out with respective Team Leader) d. Updated to include definition of, and logical model for, each module in the Software Assistant System design, including key classes. e. This work will be presented at the architecture review.
- Support SW integration process^6.
- Provide technical support to teams during Specification Review, Design Review, and Qualification test.
- Help with design and implementation when needed.
- Assist SWPM and Test Leader with final product Qualification Test Evaluation: The Software Architect's grade is based on:
- Architectural Concept Document
- Success of reviews
- Support provided to teams during integration so that subsystems behavior reflects architectural goals and the subsystem interfaces are understood by all teams.
- Support provided to SWPM and Test Leader during Qualification
- An oral examination. (^5) Each subsystem should have means to test the validity of its operations. (^6) This is a technical support role, not a managerial role.
CSE 784 - Software Studio
Job Description: Test Manager (TsM)
The Test Manager is the technical lead for integration^7 and qualification test. Does whatever is needed to detect and locate latent errors in project code. The TsM is required to know the entire design and provides support for team leaders during integration testing. He/She shares responsibility for qualification test with the Software Project Manager, assisted by the SA. The Test Leader:
- prepares a test plan, including qualification test descriptions and procedures
- reports status of unit testing, solicited from the Team Leaders.
- coordinates integration test schedule and supports team leaders in integration
- provides qualification test templates
- conducts the mechanics of qualification test while the Software Project Manager leads the test and signs off on tests with the customer
- manages a test bed^8 which includes all released codes which are shared between teams or modules within a team. The test bed is built around a directory structure established by the Test Leader with the Software Architect and ECS cluster system administrators. TsM participates in all weekly meetings, spending at least some time with each team, making sure they understand the test process and testbed, and helps with problem solving as needed by each team. Responsibilities:
- Prepare a Test Plan Document which includes: a. test schedule b. priorities for integration test, based on dependency analysis of each team’s code base. c. definition of qualification test templates d. qualification test descriptions and test procedures (about 90% of the Test Plan)
- Provide technical support to teams during integration and qualification test.
- Manage the testbed used for the project.
- Help with design and implementation when needed.
- Help team leaders plan and conduct integration test.
- Plan and share responsibility with the Software Project Manager for final product Qualification Test. Evaluation: The Test Leader's grade is based on:
- Test Plan Document
- Success of qualification testing
- Integrity of the final product
- An oral examination. (^7) Team leaders conduct the integration process, as scheduled by the Test Manager. This schedule should be negotiated with everyone agreeing that it can be met. Should this be difficult, please consult the customer. (^8) The test bed starts out as a set of directories globally accessible to the development teams, with permissions established to control the evolving product. As Qualification Test approaches the test bed typically contains a number of tools designed by the test team to support qualification testing.
