software requirements and...
TRANSCRIPT
caBIG™ Software Requirements and Specification Template
April 2004
SOFTWARE REQUIREMENTS AND SPECIFICATION DOCUMENT
caBIG™ Proteomics LIMS
DOCUMENT CHANGE HISTORY
Version Number Date Description
1.0 June 2005 Draft
1.1 July 2005 Modified first version
2.0 January 2006 Revisited to add architecture and component chapters
2.1 February 2006 Unused notes and appendixes are deleted
caBIG™ Proteomics LIMS
protLIMS prototype v.1.0
Software Requirements and Specification Document
Version 2.1
[Insert approval date of document]
[Project Name] Software Requirements and Specification
[SRSD_Project_Version.doc] i [Publish Date]
Document Change Record
Version Number Date Description
1.0 June 2005 Draft
1.1 July 2005 Modified first version
2.0 January 2006 Revisited to add architecture and component chapters
2.1 February 2006 Unused notes and appendixes are deleted
[Project Name] Software Requirements and Specification
[SRSD_Project_Version.doc] ii [Publish Date]
TABLE OF CONTENTS
SOFTWARE REQUIREMENTS AND SPECIFICATION DOCUMENT ................................................. I1. INTRODUCTION .......................................................................................................................... 1
1.1 SCOPE .................................................................................................................................... 11.1.1 Identification................................................................................................................ 11.1.2 System Overview ........................................................................................................... 21.1.3 Document Overview....................................................................................................... 2
1.2 REFERENCE DOCUMENTS .......................................................................................................... 22. PROJECT DESCRIPTION............................................................................................................. 4
2.1 PROJECT PERSPECTIVE ............................................................................................................. 42.2 PROJECT FUNCTIONS................................................................................................................ 52.3 USER CHARACTERISTICS........................................................................................................... 52.4 CONSTRAINTS.......................................................................................................................... 5
2.4.1 protLIMS Statement Of Work .......................................................................................... 52.4.2 caBIG™ Compliance..................................................................................................... 52.4.3 Additional constraints, programming language and tools being employed .............................. 5
2.5 QUALIFICATION PROVISIONS ..................................................................................................... 62.6 ASSUMPTIONS AND DEPENDENCIES............................................................................................. 6
3. REQUIREMENTS ......................................................................................................................... 73.1 SECURITY ............................................................................................................................... 73.2 INTERFACES ............................................................................................................................ 7
3.2.1 User Interface............................................................................................................... 73.2.2 Application Programming Interface (API).......................................................................... 7
3.3 BUSINESS TIER ........................................................................................................................ 73.3.1 Business Façade ........................................................................................................... 73.3.2 Business Logic ............................................................................................................. 73.3.3 Logic Utilities .............................................................................................................. 8
3.4 FILE STORAGE ......................................................................................................................... 83.5 RELATIONAL DATABASE........................................................................................................... 8
4. SYSTEM ARCHITECTURE........................................................................................................... 94.1 SYSTEM ARCHITECTURE OVERVIEW ........................................................................................... 94.2 ARCHITECTURAL DESIGN .......................................................................................................... 9
5. COMPONENTS........................................................................................................................... 115.1 WEB MODULE........................................................................................................................ 115.2 COMMON MODULE................................................................................................................. 155.3 BUSINESS FACADE MODULE .................................................................................................... 155.4 FILE ACCESS COMPONENT ....................................................................................................... 175.5 DATA ACCESS MODULE........................................................................................................... 175.6 EJB MODULE......................................................................................................................... 185.7 SECURITY MODULE ................................................................................................................ 205.8 DATABASE MODULE ............................................................................................................... 205.9 LOGIC UTILITIES MODULE........................................................................................................ 20
6. SIGN OFF................................................................................................................................... 226.1 APPROVAL ............................................................................................................................ 22
APPENDIX A – ACRONYM LIST ..................................................................................................... 23
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 1 [Publish Date]
1. INTRODUCTION
This Software Requirements and Specification Document (SRSD) captures the completesoftware requirements for the proteomics LIMS (protLIMS) and describes the design decisions,architectural design and the detailed design needed to implement the software. It provides theacquirer visibility into the design and provides information needed for software support.
The purpose of protLIMS is to allow the recording of all experimental samples, processes,procedures, analyses, and results of proteomics studies to a searchable relational database.Recording of such data, and associated metadata, will provide improved record keeping, recordretrieval, and report generation and review.
protLIMS is a LIMS system dedicated to studies in the realm of proteomics. The initial goal(goal of this version) is to develop the system to the point in the analytical workflow wheresample are prepared for mass spectroscopy. This entails recording of biological sample data,sample preparation, protein separation/resolution (if any is performed), and isolated proteinsample preparation (if separation was performed and further preparation is performed). Goals ofthe protLIMS development are:
1. Allow the recording of all necessary, and desired, data and metadata pertaining toproteomic analyses.
2. Allow interoperability with parallel LIMS and/or analytical systems.
3. Remain caBIG™ compliant.
4. Though not required, design with future web services is in mind.
The system is being developed in collaboration with the Fox Chase Cancer Center (FCCC)Proteomics Facility and the caBIG™ adopters: H. Lee Moffitt Cancer Center & ResearchInstitute.
1.1 SCOPE
The Fox Chase Proteomics Laboratory Information Management System (protLIMS) is beingdeveloped as part of the Cancer Bioinformatics Grid (caBIG™) initiative sponsored by theNational Cancer Institute and facilitated by Booz Allen Hamilton. The system is being developedin collaboration with the Fox Chase Cancer Center Proteomics Facility and the caBIG™adopters: H. Lee Moffitt Cancer Center & Research Institute.
The goal of this project is to develop a stand-alone LIMS system dedicated to studies in therealm of proteomics. The goal of the current version is to capture the data and metadata to thepoint in the analytical workflow where sample are prepared for mass spectroscopy.
1.1.1 Identification
This is the initial version of the Fox Chase Proteomics Laboratory Information ManagementSystem (protLIMS).
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 2 [Publish Date]
1.1.2 System Overview
This is the initial version of the Fox version of the Fox Chase Proteomics Laboratory InformationManagement System (protLIMS). Choices on which data to store and some use cases wereinitially taken from the caLIMS project. The caLIMS data model, however, did not satisfy thefull needs of the proteomics laboratories. As a result data models devoted to proteomics, PeDROand its successor, HUPO’s Proteomics Standards Initiative/General Proteomics Standards(PSI/GSP), are being leveraged. In addition, an effort is being made to coordinate with othercaBIG™ proteomics efforts (e.g., Rproteomics) and to harmonize the object model with relatedobject models (e.g., MicroArray and Gene Expression [MAGE]) to improve and simplifyprotLIMS interoperability with other systems.
1.1.3 Document Overview
This SRSD captures the complete software requirements for initial development of the FoxChase Proteomics Laboratory Information Management System (protLIMS), as part of NCI’scaBIG™ initiative
There are no additional or specific security or privacy considerations associated with thisdocument. The document and associated software system is being developed transparently andas open source. Questions, comments and requests may be submitted to the Fox Chase CancerCenter Bioinformatics Facility.
The remaining SRSD sections are organized as follows:
The remaining SRSD sections are organized as follows:
• Section 2. Project Description: Describes the general factors that affect the protLIMS.
• Section 3. Requirements: Describes all the software requirements to a level of detailsufficient to enable designers to design a system to satisfy those requirements.
• Section 4. System architecture: Describes architectural aspects of the system as a whole.
• Section 5. Components: Describes functional and architectural aspects of the systemcomponents.
• Appendix A. Acronym List: Defines the abbreviations used on the project.
1.2 REFERENCE DOCUMENTS
For additional project, and requirement specific information, refer to the following documents:
• Use-case requirements document is available at the caBIG™ cvs server:http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/proteomicslims/caBIG_Use_Case_protLI
MS_2005_03_08.doc
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 3 [Publish Date]
Other documentation is also available at the Fox Chase Cancer Center Bioinformatics Facilitywebsite:
http://bioinformatics.fccc.edu/software/caBIG/protLIMS/protlims.shtml
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 4 [Publish Date]
2. PROJECT DESCRIPTION
The protLIMS records the data associated with the complete workflow of proteomic analyses,and will provide a data pipeline from analysis step to analysis step. protLIMS is affected by thedata collected by researchers conducting proteomic analyses. These data may be fromheterogeneous sources and may be used as input to other analyses. As such, efforts are beingmade to harmonize the protLIMS object model with those systems from other domains, e.g.,microarray analysis. This will allow and simplify interoperability of systems used to analyze thesame biological materials by parallel research domain spaces.
Development of the protLIMS has begun using model drive architecture (MDA) and an iterativedevelopment process (IDP). Each development iteration of the IDP will complete a classicsoftware development cascade including:
• Analysis which produces an SRS revision
• Design which produces a Software Design Document revision
• Construction which produces a new code revision
• Quality Assurance Testing both at the Unit Test and Integration System Test levels
2.1 PROJECT PERSPECTIVE
The system is being developed in collaboration with the Fox Chase Cancer Center ProteomicsFacility and the caBIG™ adopters: H. Lee Moffitt Cancer Center & Research Institute.
protLIMS is being designed to allow its function, optionally, as (1) a stand-alone proteomicsLIMS [present] or as (2) an integrated component of interoperable LIMSs [future] or (3) acaGRID service [future].
Programming is in Java to allow platform independence for the application server (e.g., JBossbeing used in FCCC’s implementation). As a user interface, Internet web pages will be generatedby the protLIMS to allow conventional web browsers to provide a graphic user interface.Administrative functions will also be available via the web interface.
protLIMS employs an external relational database and the server’s directory file system (or itsequivalent). The relational database provides data storage and file location information for filesstored by protLIMS. Fox Chase Cancer Center is using Oracle for this purpose but the system isbeing developed to allow for alternate databases to be used. Data collected into the relationaldatabase may be either entered directly through the web interface, or by uploading files to beparsed by protLIMS. Parsed files may be generated by a variety of proteomics analytical toolsand are parsed by the system automatically into the database as well as being stored in theserver’s directory file system (or its equivalent). In addition, the directory file system is used byprotLIMS for the storage of other native proteomics data files, e.g., gel images, and ancillary files(“attachments”) that the user chooses to associate with the data.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 5 [Publish Date]
2.2 PROJECT FUNCTIONS
This project will be focused on the creation of a caBIG™-compliant proteomics LaboratoryInformation Management System (LIMS), namely: protLIMS. The initial version will track thelab processes from biological sample registration through 2D gel electrophoresis separation ofproteins and excision of protein “spots” for analysis by mass spectroscopy. The schema anddata model support the addition of additional data types and new data types, as they emerge.The availability of an open source proteomics LIMS will ultimately allow a distributeddevelopment model in which additional modules can be contributed by other centers.
2.3 USER CHARACTERISTICS
Anticipated end-users of protLIMS are protein analysts in research laboratories or, morespecifically, dedicated proteomics facilities. In addition, researchers who are not performing theanalyses themselves, but have proper permissions to access the system and specific datasubset(s), may also act as end users.
2.4 CONSTRAINTS
2.4.1 protLIMS Statement Of Work
We are constrained to work within the context of our statement of work (SOW). We expect thatthe system description will evolve in the course of our analysis but our core product and resourceutilization will remain framed by our SOW.
2.4.2 caBIG™ Compliance
We are constrained to comply with all caBIG™ standards on silver compatibility level. It is arequirement that protLIMS participate as a fully functioning component of caBIG™. We seekto adopt all caBIG™ sanctioned architectural patterns within a reasonable time after they areestablished. When caBIG™ compatibility issues emerge abruptly in contrast to our developmentstream we will adjust at the start of our next development iteration.
Silver level compatibility guidelines can be found at:https://cabig.nci.nih.gov/guidelines_documentation
2.4.3 Additional constraints, programming language and tools being employed
• Java is the programming language being used to allow platform independence.
• A Java application server is required for protLIMS implementation. FCCC’simplementation is being developed utilizing the JBoss Application Server(www.jboss.org), a freely available, J2EE 1.4 certified, open standards and open source,Java application server.
• A relational database back-end is required for protLIMS functionality. Fox Chase CancerCenter is using Oracle for this purpose but protLIMS is being developed to allow for
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 6 [Publish Date]
alternate databases to be used. PostgreSQL (www.postgresql.org) is being used as a freelyavailable open source model relational database.
• Programming tools
Function Application
UML modeling tools Sybase PowerDesigner 10.0
Sparx Systems - Enterprise Architect
Compuware OptimalJ 3.3
MDA modeling tool Compuware OptimalJ 3.3
Source code generation tool Compuware OptimalJ 3.3
Java IDE JetBrains IntelliJ IDEA 4.5
JSP and HTML code editor Macromedia DreamWeaver MX 2004
Database modeling tool Sybase PowerDesigner 10.0
Database mining tool Benthic Software Golden 5.7
2.5 QUALIFICATION PROVISIONS
• Project management requires that all generated and non-generated code and interfaces(application program interface [API] and graphical user interface [GUI]) will be tested.
• Change management requires that all generated and non-generated code and interfaces(application program interface [API] and graphical user interface [GUI]) will be regressiontested.
• All non-generated code shall be documented in the IDE.
• Unit testing includes empty data tests, known incorrect data tests, and limit testing.
System tests will be performed on newly installed machines to demonstrate that normaloperation does not require any software that is not explicitly stated in the requirements.
2.6 ASSUMPTIONS AND DEPENDENCIES
protLIMS is a LIMS dedicated to those areas of research involved in protein isolation, separationand identification – i.e., “proteomics.” As such, it is assumed that proteomics researchers,analytical systems and tools are available for interaction with protLIMS.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 7 [Publish Date]
3. REQUIREMENTS
3.1 SECURITY
protLIMS is required to use Java Authentication and Authorization Service (jaas)implementation to provide security aspect of the system. Authentication options include LDAPand alternative method for non-LDAP users (database or password file)
protLIMS allows user and role based authorization. Initial protLIMS prototype version will bedesigned with these authorization requirements in mind, but may actually contain user and rolebased authorization only partially.
3.2 INTERFACES
3.2.1 User Interface
protLIMS is accessed by user via internet browser, thus a web user interface is required. Theweb interface is created with by the Jakarta Struts Framework composed of Struts forms, JSPs,and Struts actions.
User interface provides user access to system functionality defined by use cases (see Referenceddocuments section). User interface allows user to create and review information about conductedproteomics research. User interface also allows authorized personnel to administer protLIMS.
3.2.2 Application Programming Interface (API)
Silver level compatibility requires that a well-described API’s provide access to data in the formof data objects that are instances of classes represented by a domain model.
3.3 BUSINESS TIER
3.3.1 Business Façade
A Business Façade is required in the protLIMS architecture to handle communication betweenthe presentation and web tiers and the business logic (EJB) tier. Functionally this hides orexposes business component functionality. In addition, the Business Façade manages datatransfer to and from the business components and handles Application transactions.
3.3.2 Business Logic
Business logic implements all system functions:
• Maintenance of data (create and update) with EJB (Enterprise Java Beans)
• Read-only querying of data with DAC (Data Access Components)
• File upload/download to/from File Storage
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 8 [Publish Date]
3.3.3 Logic Utilities
Logic utilities provide functionality for parsing of supported format data files. Initial version ofprotLIMS supports:
• Nonlinear Dynamics Progenesis image analysis export file for Microsoft Excel
• Pick list in Microsoft Excel file
3.4 FILE STORAGE
protLIMS requires access to, and use of, the server’s local file system (or its equivalent) as adedicated named user (e.g., user_name “protLIMS;” group_name “lims”). This access is used forthe storage of data, and associated files in their native format. protLIMS control of the relevantdirectory tree organization is required and organized in a project oriented structure. In this way,if for any reason the directory tree must be accessed directly by the System Administrator, thetree may be navigated logically.
Data and associated files stored may be of any type of electronic storage format (e.g., digitalimages [e.g., jpeg or tiff], digital text [e.g., XML or pdf], or binary files). Metadata about filelocation is retained in the required relational database (Section 3.6). If for some unforeseen reasonstored files are damaged or deleted by external means, protLIMS is required to fail retrieval“gracefully” returning an appropriate error message about file unavailability.
Limitation of file size and total storage space are independent of protLIMS, being a limitation ofthe computer storage operating system and storage media. Earlier operating systems hadmaximum file sizes of approximately 2 gb, but this limit has been increased more recently. Filesize is not a likely limitation to use. Total storage media does become a concern due to therelatively large size of files, and number of files, the proteomics experiments generate.
3.5 RELATIONAL DATABASE
A relational database back-end is required for protLIMS functionality. Fox Chase Cancer Centeris using Oracle for this purpose but protLIMS is being developed to allow for alternate databasesto be used. PostgreSQL (www.postgresql.org) is being used as a freely available open sourcemodel relational database. No other database alternative is being tested in the immediate future.Alternatives must be capable of views and hierarchical queries.
The relational database retains all data entered through the web interface and network paths todata and associated files. It is required that no data is ever deleted from the database, itself,though the user may use the web interface “delete” function to delete data entries from the list ofviewed data. In this way all data is retrievable for future access if necessary, e.g., for auditingpurposes.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 9 [Publish Date]
4. SYSTEM ARCHITECTURE
4.1 SYSTEM ARCHITECTURE OVERVIEW
The protLIMS utilizes a multi-tiered systems architecture (Figure 4.1-1). The system is beingbuilt using model driven architecture (MDA). This separates functional roles in the system intoindividual domain models. The “application model” (Platform Specific Model; PSM) is generatedfrom the “domain model” (Platform Independent Model; PIM) using technology patterns ofJ2EE.
User access is provided by an internet/web interface (Tier 1: Client Tier). The client accesses theinterface using an internet/web browser application of their choosing.
The Client Tier communicates with the systems web components composed of the web serverand (Tier 2: Web Tier) and application server (Tier 3: Business Tier). These tiers are isolatedfrom the user by system modules providing a business façade and business logic.
The Business Tier communicates with the Database Server (Tier 4: Data Storage Tier) for datastorage and retrieval. As specified in the present requirements and specifications document, inaddition to the relational database, collateral files are stored in a dedicated file directory structure.
Tier 1: Client Tier
• HTML
Web
Browser
Tier 2: Web Tier
• Java Server
Pages • Struts
Web
Server
Tier 3: Business Tier
• EJB session
beans • EJB entity
beans • Data access
components
Application Server
Tier 4: Data Storage
Tier • JDBC • Connector
technologies
Database Server & Directory
Network Network Network
Figure 4.1-1: System Architecture Overview
4.2 ARCHITECTURAL DESIGN
The user interface (Figure 4.1-1, see: Presentation) is generated by a Jakarta Struts framework:Struts forms, Java Server Pages (JSPs), and Struts Actions. The Presentation Tier and BusinessLogic components communicate with the Business Façade by utilization of shared componentsaccessible to all components of the system (Figure 4.1-1, see: Common). Methods of the sessionbeans of the Business Logic component (Figure 4.1-1, see: Business Logic) access Entity Beansand Data Access Components (DAC) as appropriate for user selected functions. Data of thedatabase records are recorded and retrieved by methods of the Entity Beans and DAC as
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 10 [Publish Date]
necessary for user selected functions. Similarly, files stored in the protLIMS directory tree arestored and retrieved as necessary for user selected functions.
Presentation Business Facade
Business Logic
Files
DBMS
Update Object
Key Data Object
Collection, List Collection, List
Common
Collection, List
Struts Forms
Struts Actions
JSPs Business Facade
Session Beans
Entity Beans
Data Access
Components
Web Services*
Security Model
File Access
Component
Logic Utilities
Figure 4.2-1: protLIMS Architectural Design
* Web services integration is not part of first year requirements
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 11 [Publish Date]
5. COMPONENTS
5.1 WEB MODULE
Purpose The Web Module provides the user interface (section 3.2.1)
Function The Web Module allows user to access, update and create information via webbrowser.
Subordinate The Web Module is implemented with Jakarta Struts framework. The Webmodule consists of jsp pages, struts forms, actions and configuration files, andalso resource, style-sheet and java script files.
Dependencies Web interface appearance may depend on used web browser. Primarybrowsers are: Internet Explorer on Windows, Safari on MacOS and MozillaFirefox on other operating systems. Web interface is not guaranteed to bedisplayed correctly on other browsers.
Interfaces User-to-Web Module (for Input files to be parsed by the system):
- Files exported from gel image analyzing software with data aboutdetected spots (DeCyder and Progenesis)
- Pick list (exported by software and modified by researcher)
Interfaces Web Module-to-Business Façade, and vice versa:
• The Web Module accesses system logic via Business façade module.
• The Web Module uses data objects defined in the Common Module tocommunicate with the Business Façade.
• The Web module uses the Security Model to provide Authenticationand Authorization.
Each web component deals with its corresponding business façadecomponents. For example, SampleSvcWebComponent:
- Uses SampleSvcBusinessFacade to create the sample in the database
- Uses SpeciesTypeBusinessFacadeComponent to populate thedropdown menu list of available species in the user interface
- Uses SampleProviderBusinessFacadeComponent to populate thedropdown menu list of available providers in the user interface
- and so on for other dependent look-ups
Other components work in a similar fashion: RawSampleSvc, GelImageSvc,ProjectSvc, ProcedureSvc, etc.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 12 [Publish Date]
ProjectSvc, ProcedureSvc, etc.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 13 [Publish Date]
Interfaces
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 14 [Publish Date]
Processing The Web Module is implemented with Jakarta Struts framework:
Client
Browser
Controller
ControllerServlet
Struts-Config.xml
JSP
BusinessFacade
FormBean
ActionClass
EJB Tier
SessionBean
EntityBean
Model
Web Tier
r/wdata
r/wdata
r/wdata
r/wdata
r/wdatar/w
data
r/wdata
read
get data
View
request
HTMLresponse
create
Create
forward
DataObject
Read
UpdateObject
Elements of the Struts framework include:
• Controller Servlet—Implements the Controller part of the MVC. Itreceives and forwards requests using the struts-config.xml file
• Actions Classes—Implement the Model part of the MVC. Theyperform actions and return statuses
• JavaServer Pages (JSPs)—Implement the View part of the MVC. Theyare filled with data from the update objects and produce an HTML outputto the client
• Struts-config.xml—Defines the action mapping
• Form Bean—A helper class that contains get and set methods for all theattributes that can be submitted via an HTML form.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 15 [Publish Date]
5.2 COMMON MODULE
Purpose Describes the LIMS shared data structures for generation of, and LIMSinteraction with, the user interface (section 3.2.1).
Function The Common Module contains objects that are used to transfer informationbetween modules inside system and also between system itself and otherapplications.
Subordinate Common module contains two separate modules:
• Core data elements – Reflect the database tables
• Browser – Reflects the database read-only views
Dependencies None
Interfaces None
5.3 BUSINESS FACADE MODULE
Purpose Control tier-to-tier (Web Unit to Business Logic Model) communication, andtherefore improves network traffic performance in the LIMS.
Function The business facade model provides access to business logic. It allows thepresentation model to use the data and access the methods provided byBusiness Logic Model components.
Subordinate Business façade components: one for each ejb bean plus one BrowserSvcBusiness Facade Component for all DAC components.
Dependencies None
Interfaces Business façade serves as firewall between presentation and business logictiers:
web module business façade entity bean
web module business façade session bean
web module business façade File Access Component
web module business façade Logic utilities
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 16 [Publish Date]
Interfaces
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 17 [Publish Date]
5.4 FILE ACCESS COMPONENT
Purpose Provide upload and download of native file to and from directory file storage(see section 3.4).
Function Saves uploaded file from LimsFileSvcUpdateObject into file storage
Checks if requested file is available for reading
Copies downloaded file from file storage to LimsFileSvcUpdateObject
Subordinate None
Dependencies File Storage for File Access Component is located on the servers’ local filesystem.
Interfaces void uploadFile(limsFileSvcUO LimsFileSvcUpdateObject)
void downloadFile(limsFileSvcUO LimsFileSvcUpdateObject)
boolean isReadyForDownload (limsFileSvcUO LimsFileSvcUpdateObject)
5.5 DATA ACCESS MODULE
Purpose Provide read-only access to big subsets of information
Function Perform queries on database views
Subordinate Data Access Components - one for each database view
Dependencies Oracle supports hierarchical queries, PostgreSQL doesn’t. Sample-datahierarchy DAC analyzes connection metadata to determine current DBMS, andfor Oracle hierarchical queries are performed (where applicable), for otherDBMS (including PostgreSQL) hierarchical queries are replaced by simplequeries that only retrieve one level of children/parents
Interfaces Each DAC has findByProperties() method:
findByProperties (filter <NameOfTheView>UpdateObject) returns<NameOfTheView>UpdateObjectCollection
NameOfTheView>UpdateObjects belongs to“browser” part of commonmodule
Sample-data hierarchy DAC also provides findAllChildren() andfindAllParents() methods to retrieve information about pedigree for particularsample or datafile.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 18 [Publish Date]
Processing Each non-null attribute in filter update objects is parsed as additional querycondition. If all attributes are null, all available entries are retrieved fromappropriate view.
5.6 EJB MODULE
Purpose Manage information
Function Store data to persistence (database) tier
Subordinate Entity components and Session components
Dependencies EJB 2.0
Interfaces Entity beans are used by business façade to retrieve information from database:
business façade entity bean database
Interfaces Session beans are used by business façade to create and update groups ofobjects sometimes called domain views (not to be confused with databaseviews)
business façade session bean several entity beans database
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 20 [Publish Date]
5.7 SECURITY MODULE
Security module purpose is to provide authentication and authorization methods to the system.In the current version of the system authentication will be provided by Java Authentication andAuthorization Service (jaas) implementation developed at Fox Chase Cancer Center.Authorization features will be limited to “laboratory personnel – laboratory project” accessrestriction (stored in database).
Java Authentication and Authorization Service is a set of APIs that enable services toauthenticate and enforce access controls upon users. Future releases of the protLIMS shouldfully support user-based authorization
5.8 DATABASE MODULE
Purpose Provide data storage
Function Keep data, response to queries
Subordinate Tables and views
Dependencies Two sets of scripts and configuration files are provided (one for Oracle and onefor PostgreSQL) to handle differences between two supported DBMS.
Interfaces None
.
5.9 LOGIC UTILITIES MODULE
Purpose Provide logic utilities to web and business façade modules
Function Utilities provide classes to handle input file parsing. Currently supportedformats are xls files exported from Progenesis or created by researcheraccording to upload format requirements.
Subordinate UploadParser interface, implementations for all supported formats, factoryclass.
Dependencies UploadParser implementations heavily depend on input file format eachparticular implementation is supposed to parse. Changes in these formatsshould be reflected in UploadParser implementation changes.
Interfaces Factory class provides access to appropriate UploadParsers for web andbusiness façade modules. Obtained by factory UploadParser interface providesmethod for parsing input file stream into information about spot analysis or gelplug pick list.
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 22 [Publish Date]
6. SIGN OFF
6.1 APPROVAL
Architecture Workspace Rep Print Name Date
VCDE Workspace Rep Print Name Date
Adopter Rep Print Name Date
[Project Name] Software Requirements and Specification
[caBIG™_SRSD_Template.doc] 23 [Publish Date]
APPENDIX A – ACRONYM LIST
Term/Abbreviation Description
protLIMS Proteomics Laboratory Information Management System
API Application Programming Interface
caCORE Cancer Common Ontologic Reference Environment
caDSR Cancer Data Standards Repository
CDE Common Data Element
CSM Common Security Module
DAC Data Access Component
DBA Database Administrator
DBMS Database Management System
EVS Enterprise Vocabulary Services
FCCC Fox Chase Cancer Center
GUI Graphical User Interface
HUPO Human Proteomics Organisation
JSP Java Server Pages
LIMS Laboratory Information Management System
MAGE MicroArray and Gene Expression (MGED Society)
MGED Microarray Gene Expression Data
PDF Portable Document Format (Adobe)
PM Project Manager
PSI/GPS Proteomics Standards Initiative/General Proteomics Standards (Human ProteomicsOrganisation [HUPO])
RM Requirements Manager
RTM Requirements Traceability Matrix
SCM Software Configuration Management
SDK Software Development Kit
SDLC Software Development Lifecycle
SDP Software Development Plan
SE Software Engineering
SEPG Software Engineering Process Group
SM Software Manager
SOP Standard Operating Procedure
SOW Statement of Work
SPI Software Process Improvement
SQA Software Quality Assurance
SRS Software Requirements Specification
SW Software
TBD To Be Determined
TM Test Manager
UML Unified Modeling Language
XMI XML Metadata Interchange (Object management Group [OMG])
XML Extensible Markup Language (World Wide Web Consortium [W3C])