Professional Documents
Culture Documents
April 2004
caBIG™ Proteomics LIMS
protLIMS prototype v.1.0
Software Requirements and Specification Document
Version 2.1
TABLE OF CONTENTS
SOFTWARE REQUIREMENTS AND SPECIFICATION DOCUMENT.....................................................................I
1. INTRODUCTION...................................................................................................................................................1
1.1 SCOPE....................................................................................................................................................... 1
1.1.1 Identification.....................................................................................................................................1
1.1.2 System Overview................................................................................................................................2
1.1.3 Document Overview..........................................................................................................................2
1.2 REFERENCE DOCUMENTS........................................................................................................................... 2
2. PROJECT DESCRIPTION....................................................................................................................................3
2.1 PROJECT PERSPECTIVE............................................................................................................................... 3
2.2 PROJECT FUNCTIONS................................................................................................................................. 4
2.3 USER CHARACTERISTICS............................................................................................................................ 4
2.4 CONSTRAINTS........................................................................................................................................... 4
2.4.1 protLIMS Statement Of Work............................................................................................................4
2.4.2 caBIG™ Compliance........................................................................................................................4
2.4.3 Additional constraints, programming language and tools being employed....................................4
2.5 QUALIFICATION PROVISIONS...................................................................................................................... 5
2.6 ASSUMPTIONS AND DEPENDENCIES............................................................................................................ 5
3. REQUIREMENTS..................................................................................................................................................6
3.1 SECURITY................................................................................................................................................. 6
3.2 INTERFACES.............................................................................................................................................. 6
3.2.1 User Interface....................................................................................................................................6
3.2.2 Application Programming Interface (API).......................................................................................6
3.3 BUSINESS TIER.......................................................................................................................................... 6
3.3.1 Business Façade................................................................................................................................6
3.3.2 Business Logic...................................................................................................................................6
3.3.3 Logic Utilities....................................................................................................................................7
3.4 FILE STORAGE........................................................................................................................................... 7
3.5 RELATIONAL DATABASE............................................................................................................................. 7
4. SYSTEM ARCHITECTURE.................................................................................................................................8
4.1 SYSTEM ARCHITECTURE OVERVIEW........................................................................................................... 8
4.2 ARCHITECTURAL DESIGN.......................................................................................................................... 8
5. COMPONENTS....................................................................................................................................................10
5.1 WEB MODULE......................................................................................................................................... 10
5.2 COMMON MODULE................................................................................................................................. 13
5.3 BUSINESS FACADE MODULE.................................................................................................................... 13
5.4 FILE ACCESS COMPONENT........................................................................................................................ 15
5.5 DATA ACCESS MODULE........................................................................................................................... 15
5.6 EJB MODULE.......................................................................................................................................... 16
5.7 SECURITY MODULE................................................................................................................................. 18
5.8 DATABASE MODULE................................................................................................................................ 18
5.9 LOGIC UTILITIES MODULE....................................................................................................................... 18
6. SIGN OFF..............................................................................................................................................................19
6.1 APPROVAL............................................................................................................................................... 19
Appendix A – Acronym List.........................................................................................................................................20
1. INTRODUCTION
This Software Requirements and Specification Document (SRSD) captures the complete software
requirements for the proteomics LIMS (protLIMS) and describes the design decisions,
architectural design and the detailed design needed to implement the software. It provides the
acquirer 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, record
retrieval, 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 where sample are
prepared for mass spectroscopy. This entails recording of biological sample data, sample
preparation, protein separation/resolution (if any is performed), and isolated protein sample
preparation (if separation was performed and further preparation is performed). Goals of the
protLIMS development are:
1. Allow the recording of all necessary, and desired, data and metadata pertaining to
proteomic 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 & Research
Institute.
1.1 SCOPE
The Fox Chase Proteomics Laboratory Information Management System (protLIMS) is being
developed as part of the Cancer Bioinformatics Grid (caBIG™) initiative sponsored by the
National Cancer Institute and facilitated by Booz Allen Hamilton. The system is being developed
in 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 the realm
of proteomics. The goal of the current version is to capture the data and metadata to the point 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 Management
System (protLIMS).
Section 2. Project Description: Describes the general factors that affect the protLIMS.
http://cabigcvs.nci.nih.gov/viewcvs/viewcvs.cgi/proteomicslims/caBIG_Use_Case_protLIMS_
2005_03_08.doc
Other documentation is also available at the Fox Chase Cancer Center Bioinformatics Facility
website:
http://bioinformatics.fccc.edu/software/caBIG/protLIMS/protlims.shtml
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 the
data collected by researchers conducting proteomic analyses. These data may be from
heterogeneous sources and may be used as input to other analyses. As such, efforts are being
made 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 the
same biological materials by parallel research domain spaces.
Development of the protLIMS has begun using model drive architecture (MDA) and an iterative
development process (IDP). Each development iteration of the IDP will complete a classic
software development cascade including:
2.4 CONSTRAINTS
• A relational database back-end is required for protLIMS functionality. Fox Chase Cancer
Center is using Oracle for this purpose but protLIMS is being developed to allow for
alternate databases to be used. PostgreSQL (www.postgresql.org) is being used as a freely
available 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
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 regression
tested.
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 normal operation
does not require any software that is not explicitly stated in the requirements.
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 LDAP and alternative
method for non-LDAP users (database or password file)
protLIMS allows user and role based authorization. Initial protLIMS prototype version will be
designed with these authorization requirements in mind, but may actually contain user and role
based authorization only partially.
3.2 INTERFACES
Maintenance of data (create and update) with EJB (Enterprise Java Beans)
Nonlinear Dynamics Progenesis image analysis export file for Microsoft Excel
4. SYSTEM ARCHITECTURE
Web Web Application Database
Browser Server Server Server &
Directory
Network Network Network
Files
Web
Services*
Common
Update Key Data
Object Object
Security Model Logic Utilities
5. COMPONENTS
Function The Web Module allows user to access, update and create information via web
browser.
Subordinate The Web Module is implemented with Jakarta Struts framework. The Web
module consists of jsp pages, struts forms, actions and configuration files, and
also resource, style-sheet and java script files.
Dependencies Web interface appearance may depend on used web browser. Primary browsers
are: Internet Explorer on Windows, Safari on MacOS and Mozilla Firefox on
other operating systems. Web interface is not guaranteed to be displayed
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 about
detected spots (DeCyder and Progenesis)
The Web Module accesses system logic via Business façade module.
The Web Module uses data objects defined in the Common Module to
communicate with the Business Façade.
The Web module uses the Security Model to provide Authentication and
Authorization.
Each web component deals with its corresponding business façade components.
For example, SampleSvcWebComponent:
Interfaces
Controller Model
get data
Form Bean—A helper class that contains get and set methods for all the
attributes that can be submitted via an HTML form.
Purpose Describes the LIMS shared data structures for generation of, and LIMS
interaction with, the user interface (section 3.2.1).
Function The Common Module contains objects that are used to transfer information
between modules inside system and also between system itself and other
applications.
Subordinate Common module contains two separate modules:
Dependencies None
Interfaces None
Purpose Control tier-to-tier (Web Unit to Business Logic Model) communication, and
therefore improves network traffic performance in the LIMS.
Function The business facade model provides access to business logic. It allows the
presentation model to use the data and access the methods provided by
Business Logic Model components.
Subordinate Business façade components: one for each ejb bean plus one BrowserSvc
Business Facade Component for all DAC components.
Dependencies None
Interfaces Business façade serves as firewall between presentation and business logic tiers:
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
Interfaces
Purpose Provide upload and download of native file to and from directory file storage
(see section 3.4).
Dependencies File Storage for File Access Component is located on the servers’ local file
system.
Processing Each non-null attribute in filter update objects is parsed as additional query
condition. If all attributes are null, all available entries are retrieved from
appropriate view.
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 of objects
sometimes called domain views (not to be confused with database views)
business façade session bean several entity beans database
Dependencies Two sets of scripts and configuration files are provided (one for Oracle and one
for PostgreSQL) to handle differences between two supported DBMS.
Interfaces None
.
Function Utilities provide classes to handle input file parsing. Currently supported
formats are xls files exported from Progenesis or created by researcher
according to upload format requirements.
Subordinate UploadParser interface, implementations for all supported formats, factory
class.
Dependencies UploadParser implementations heavily depend on input file format each
particular implementation is supposed to parse. Changes in these formats
should be reflected in UploadParser implementation changes.
Interfaces Factory class provides access to appropriate UploadParsers for web and
business façade modules. Obtained by factory UploadParser interface provides
method for parsing input file stream into information about spot analysis or gel
plug pick list.
6. SIGN OFF
6.1 APPROVAL