Download Trusted Component Foundry - Final Project for Software Studio | CSE 784 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!
CSE 784 - Final Project
Trusted Component Foundry
version 1. 14 October 2002 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 Monday, December
Final product delivery of updated specifications and code will be on Monday, December 13. 1
Archive in an accessible place all versions of all components, but with no duplication of files. Thus if moduleA and moduleB both depend on File1, they will both refer to the same file, rather than storing away their own copies of that file.
Support the creation and management of modules, programs, and systems, as follows: A module is an XML file that refers, by name, to its lower level parts, e.g., source code files, test drivers, build scripts, documentation files, and perhaps, other modules. Similarly, a program is an XML file that refers to modules, test drivers, build scripts, and documentation files. A program’s XML file may not refer to another program. A System is an XML file that refers to programs, test drivers, build scripts, and documentation. Systems may not refer to other systems. When talking about these XML files from the perspective of their structure, we will call them manifests, for they are a manifest description of their contents. When talking about these files at a specific component level, we will refer to these same files as modules, programs, or systems. Each manifest contains descriptive text – a summary of its operations and character-istics, a set of keywords, a status description, references as cited above, and the name of a Responsible Individual, hereafter referred to as an RI. <module name=”TSQueue” type=”factory component” > The purpose of this module is to … Yada, Yada, Yada FIFO queue, multi-threaded, synchronized <respIndiv name=”John Doe” email=”[email protected]/> <created date=”10-18-2002” time=”3:02 AM” /> <modified date=”10-18-2002” time=”3:02 AM” /> passed unit test, available in testbed for integration <source ref=”TSQueue.h “/> < build ref=”TSQueue.cproj”> nonenone 4
Support extraction of copies of one or more components to a specified client directory, and insertion of modified files back into the Foundry. Extraction is based on component name. Requesting the extraction of myProg results in all the files that myProg refers to directly, or indirectly, being copied to a specified client directory. Source, documentation, and test driver files are extracted as readable and writeable. Build scripts and manifests are extracted as read-only. Individual source code, documentation, and test-drivers can be inserted into the Foundry. The Foundry will increment their version numbers on insertion if they have version numbers. The Foundry will not allow the insertion of any file with version number that has been modified outside the Foundry. Manifests may be inserted into the Foundry under the same rules as files, except that, for insertion to be allowed: o A manifest must contain at least one reference that has been changed from a previous version, and that referenced file must be in the Foundry or accompany the manifest. o If the manifest represents a module it must refer to a test driver existing in the Foundry, or be accompanied by the referenced test driver.
Support building executable images and dynamic link libraries from components. Each component will refer to a build script that will result in a dynamic link library (DLL) or executable (EXE). All modules will compile to DLLs and their accompanying test drivers will compile to an EXE that will load the DLL. Note that every module must have a test driver. All programs will compile to EXEs and the build script will insure that its top level DLLs are also built^4. All systems will compile to a collection of EXEs by invoking the build scripts of each referenced program. (^4) It is not necessary to build the lower level DLLs since higher level modules contain all the source code of the lower level modules, by reference. 6
Support viewing or building documentation for any component. The intent is that behavior and design documentation are always visible and always up-to- date, as they are part of the component structure. When the component is updated, so too is the documentation. Each component manifest will include as an XML element, or refer to an external document for, text describing its behavior model. A higher level may, but is not required to, refer for additional documentation to any lower level components it may refer to. This element will be given a unique XML tag, something like: This is some behavioral description. Yada, Yada, Yada This allows a developer to expose lower level behavior if it is appropriate, without duplicating the description it refers to. Documentation may include references to Visio diagrams using a reference tag: Each component manifest will provide design documentation in the same way, e.g.: , or YourLowerLevelDesign.Txt Provide tools in the Foundry to allow ANYONE to view, at ANY TIME, the behavioral and design models for every component. Any component in the Foundry without behavior and design documentation will result in a notification in an area associated with, but not the same as, the update notification area. Components without behavior and design documentation will be treated as incomplete and the RI will be sent daily notifications to that effect. Behavioral documentation is treated differently for components in the Factory than in the Clean Room. Components in the Clean Room are trusted and will not be tested before use. Therefore, their behavior documentation is stated in the present tense and has no shalls or test elements. Components in the Factory are not trusted, will be tested, and consequently have different behavior models. Contrary to standard practice, the Foundry behavioral documentation for Factory components will have not necessarily have shalls. Rather, each assertion that would conventionally have one or more shalls will be enclosed within a test element, e.g.: text describing the 7
Support creation of system test plans by extracting test descriptons from components in the Factory. The behavioral model for all parts of a system that belong to the Clean Room will be included in an appendix titled Behavior of Reused Software.
Associate, with every component, a change history^5. Change history is a separate document that lists, by version number, the reason for each change and descriptions of the changes made. Change histories are the only document contained in the Foundry that is not versioned. (^5) A change history is a text-based list of every change by date, with a title and brief description. 9
Preliminary Partitions and Their Functions:
The Processing required to support the Foundry’s activities is divided into the following:
FOUNDRY Server Supports storage and retrieval of all versions of all software components and documentation. It maintains associations between components and supports the operations of creation, addition, modification, and building of all software components. The FOUNDRY Server provides interface(s) for: FOUNDRY administrators to carry out these activities^6. client processes to carry out the same set of activities. The FOUNDRY Server accepts messages from one or more concurrent clients containing requests to carry out any of its supported activities.
Communication Subsystem The Communication Subsystem is responsible for transporting all requests and files between any FOUNDRY Client and the FOUNDRY Server. It uses threads to avoid blocking a Client process while serving one or more requests. It handles multiple concurrent clients.
FOUNDRY Client The FOUNDRY client provides an interface for displaying views of all the software components, their associations, and their creation time and times of last modification. It provides the controls necessary for a user to carry out any of the FOUNDRY activities, and views to display the results. FOUNDRY clients are responsible for requesting additions, modifications, and creation of components as well as extraction and build. They are also responsible for requesting associations (manifests) held by the FOUNDRY Server. The client provides an interface for running tool programs on a specified set of components.
Software Viewing Tools For this project the software viewing tools support: Viewing of any component. The view may be behavior, design, or source and can be switched between these at any time. A user should be able to step through each component, either in an alphabetical order, by selection, or by following associations, e.g., viewing a component will support the selection for view of any of the files it references. View the collection of all files, all modules, all programs, and all systems. Please support this by providing an indexModule that refers to all files, and indexProgram that refers to all modules, an indexSystem that refers to all programs, and an index which refers to all systems.
Build Tools This partition is responsible for creating DLLs and EXEs from components and documents from behavior and design descriptions. It is responsible for creating DLLs for any component on demand, along with an execution image of a test driver, referenced by the component. Note that if the component is a module, referring to lower level modules, only one DLL is build from the combined software. (^6) It is permitted, and probably desirable to have the administrator use a Foundry Client process on the Foundry server. 10
Software Project Manager
The SPM will manage the FOUNDRY project, with the help of the Software Architect, Test Manager, and all the Team Leaders.
Software Architect
The Software Architect is responsible for the FOUNDRY architecture concept and the FOUNDRY A Specification. The SA will also provide support for qualification testing.
Software Development Teams
Each of the components listed above will have a team for its development. There will also be test and prototyping teams. Each team, with the exceptions of test team and prototyping team will:
produce its own FOUNDRY behavior specification^7 , design description, and code
present their specifications and design during FOUNDRY specification and design reviews
conduct unit test on their code
integrate their software with that of the other teams
participate in final qualification testing
Prototyping Team
In addition to the development teams there will be a prototyping team. Their responsibilities are to build critical component prototypes quickly to test design and implementation ideas. Their products are “throw-away” proof of concept components. They will not be expected to heavily document their prototypes. However, they are expected to produce white papers that describe their results and provide access to their code. Members of the prototyping team will move into the development teams when prototyping is complete. The prototyping team will be responsible for a least the following:
Establish an early version of the communication subsystem to provide a backbone for FOUNDRY Clients and Server to conduct their developments.
To define an approach for association of Software products and managing the FOUNDRY database^8.
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 of integration testing and qualification testing.
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 which implement the tests described in the test plan for their software, under the joint direction of their team leader and the test team leader. (^7) The form of behavior and design descriptions will be as cited above in the Preliminary Architectural Concept. (^8) The term database is probably misleading. The Config database is simply a directory to hold all the software products and the code which manages those products. This is a prime role of the Config Server. 2
Team Assignments:
Software Project Manager Alexey Zaitsev
Software Architect Srinivasa Neerudu
Prototyping Team Team Leader: “ “ Norman Leach Jamshidur Rahman
Test Team Team Leader: Goldie Fernandes Apoorva Joshi Huseyin Tekin Cheng-We Yang
FOUNDRY Server Team Team Leader: Jeff Ting Eswara Balasu Girish Murthy Srinivas Shilagani
Communication Manager Team Team Leader:
FOUNDRY Client Team Team Leader: Yi-Yang Huang kuoChun Chin Alvaro Ramirez Vineet Sharma Mahesh Manglani
Software Tools Team Team Leader: Ozer Ozkaraoglu Tsung Shin Jei Aykut Sahin Sivaraj Shanmuganathan Baohua Tao 3
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^9. 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 FOUNDRY design including key classes. e. This work will be presented at the architecture review.
Lead Prototyping Team to test design approaches, look at critical issues.
Lead SW integration process.
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
Integration completed successfully on schedule
Support provided to SWPM and Test Leader during Qualification
An oral examination. (^9) Each server component should have means to test the validity of its operations, e.g., the database manager should be able to test the integrity of the database, directory manager test integrity of the directory indexes, file viewer test the integrity of its page handler if one is used. 5
Job Description: Test Leader (TsL)
The Test Leader is the technical lead for integration and qualification test. Does whatever is needed to detect and locate latent errors in project code. The TsL 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
provides templates for unit test drivers
identifies priorities for unit test
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 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. TsL 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 unit test, based on dependency analysis of each team’s code base. c. definition of unit test and qualification test templates d. qualification test descriptions and test procedures (about 90% of the whole)
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. 6
Job Description: Team Member (TM)
Concentrates on one specific part of the system. Does whatever necessary to make assigned parts successful. TM has primary responsibility for assigned classes/modules including design, implementation, and test. He/She prepares C-Spec for assigned functionality, presents that part at the design review, develops code, and conducts unit test. The TM supports the Team Leader in conducting integration if requested by TL. Responsibilities:
Reads B-specification
Prepares assigned part of the C-Spec and design.
Presents that part at Design Review.
Implements assigned part, paying attention to complexity, size, robustness, understandability.
Develops unit test drivers.
Tests every function and allocated requirement as early as possible
Takes full responsibility for assigned part of subsystem. Evaluation: Grade based on:
C-Spec Review presentation
quality of assigned code and test
robustness of code.
"reasonable" size and complexity
good understandability
success of team's assigned part
willingness to support team leader in documentation, design, implementation, and test 8
