Download Treebase Software Architecture Document

Treebase Software Architecture Document
Treebase Software Architecture Document
Revision History
Date
Version
Description
Author
10/28/05
0.5
Initial.
Jin Ruan
12/04/05
0.6
Update usecase model
JR
Table of Contents
1.
Introduction
2
1.1
1.2
1.3
1.4
2
2
2
2
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
2.
Architectural Goals and Constraints
2
3.
Use-Case View
3
3.1
3.2
3.3
3.4
3.5
3.6
3
4
6
7
9
9
4.
Administrative use-cases
Submission use-cases
Search use-cases
Analysis use-cases
Integration use-cases
Non functional use-cases
Logical View
10
4.1
4.2
4.3
10
10
12
Overview
Architecturally Significant Design Packages
Use-Case Realizations
5.
Process View
12
6.
Deployment View
12
7.
Implementation View
12
8.
Size and Performance
12
9.
Quality
12
1
Treebase Software Architecture Document
Treebase Software Architecture Document
1.
Introduction
1.1
Purpose
This document provides a comprehensive architectural overview of the Treebase II system, using a number
of different architectural views to depict different aspects of the system. It is intended to capture and
convey the significant architectural decisions which have been made on the system.
1.2
Scope
This document provides a comprehensive architectural overview of the Treebase II system. The Treebase
II project is mainly developed in SDSC for the Cipres project (http://www.phylo.org/ ).
The document is based on the Software Architecture Document Template from the Rational Unified
Process. See http://www-306.ibm.com/software/awdtools/rup/ The UML diagrams are copied from the
Analysis and Modeling modules.
We follow an iterative development process. This is a living document that would be updated each
iteration.
1.3
Definitions, Acronyms, and Abbreviations
1.4
References
2.
Architectural Goals and Constraints
The architectural goals for the Treebase project:

Use proven state of art technologies and best practices to assemble a light weight, agile, easy to
test, and easy to maintain software system.

The architecture should be flexible and extensible, ensure reusability for the next phase of the
development.

Ease of integration with external systems.

High performance I/O for large dataset.

Based on Open Source Software as much as possible.
Some key requirements and feature constraints that may have a significant impact on the current
architecture:

Interactions with the Notebook project have not been defined.

The Cipres-dev project would use the Treebase as the data store. The requirement has not been
defined.

Nexus file parser constraint: Nexus file has a very flexible format.
2
Treebase Software Architecture Document
3.

Potential performance impact by large dataset.

Requirement limitation due to the natural of the scientific software: new data requirement,
different options on implementation from the scientific community.
Use-Case View
This section describes the scenarios and/or use-cases that represent the significant and central functionality,
especially those use-cases that affect the architecture.
The Treebase usecases are organized into packages and are based loosely on the functional areas:
3.1

Administrative use-cases

Submission use-cases

Search use-cases

Analysis use-cases

Integration use-cases

Non functional use-cases
Administrative use-cases
This package contains administrative usecases such as user management.
Login
A user (submitter, administrator, Treebase editor, and any 3rd party software system) needs to login to
perform authorized tasks. The login process includes the authentication and authorization.
3
Treebase Software Architecture Document
Manage User
A user can create and update the user profile. An administrator can assign special role to an existing user
or delete any user account.
Email User
An administrator can notify users via email.
Usage Report
Generate usage report.
Backup and Recovery
Data backup and recovery usecases.
3.2
Submission use-cases
This package contains usecases in the Treebase submission process. The actors involved are: study
authors, anonymous reviewers / editors, and the Treebase study publisher.
4
Treebase Software Architecture Document
Review Authorization
A reviewer is anonymous. S/He cannot be identified or authenticated. This usecase describes the process
to authorize a reviewer to access a non-published study without the authentication.
Manage Study
Study management such as create, edit, and delete.
Manage Analysis
Analysis management such as create, edit, and delete analysis. Also includes analysis step management.
Manage Data
Submit actual data to the Treebase.
5
Treebase Software Architecture Document
Manage Tree
Part of the Manage Data usecase. Submit tree data.
Manage Matrix
Part of the Manage Data usecase. Submit matrix data.
Manage Taxonomy
Part of the Manage Data usecase. Use an external service to specify/verify the taxonomy for the submit
data.
Parse Nexus File
Use an external Nexus parser service to parse the Nexus file into Java objects.
Review Non-Published Study
A reviewer or journal editor can view non-published study data in Treebase.
Publish Study
After the submitted study is accepted/published in a Journal, the submitter requests the study to be
published to the Treebase. After a study has flagged to request publish, the TreeBASE editor can publish
the study to the public.
GenBank Submission
It would be nice also submit the sequence to other databases like GenBank.
3.3
Search use-cases
This package contains usecases for browsing and searching the published Treebase data. The Visitor actor
can perform these usecases. No login is required.
6
Treebase Software Architecture Document
Study Related Queries
Include study browsing, basic and advanced search for studies. Provide search GUI and web service API.
Tree Related Queries
Include tree browsing, basic and advanced search for trees. Provide search GUI and web service API.
Matrix Related Queries
Include matrix browsing, basic and advanced search for matrixes. Provide search GUI and web service
API.
3.4
Analysis use-cases
This package contains usecases for analyzing and downloading the published Treebase data. The Visitor
actor can perform these usecases. No login is required.
7
Treebase Software Architecture Document
Visualize Matrix
Visualize matrix data.
Generate Nexus File
Generate file in Nexus or a XML format (to be defined later).
Generate Matrix Block
Generate matrix block in Nexus or a XML format (to be defined later).
Generate Tree Block
Generate tree block in Nexus or a XML format (to be defined later).
Visualize Tree
Visualize the tree structure.
Draw Tree
Draw the tree structure, using a third party component.
8
Treebase Software Architecture Document
Tree Surfing
Browse the neighboring trees.
Build Supertree
Compute a supertree for marked trees.
3.5
Integration use-cases
This package contains usecases that defines the interactions with external components and services.
<TODO>
3.6
Non functional use-cases
This package contains non functional yet architecture significant usecases.
Internationalization
Minimal support for different character sets, for example in the bibliographic records.
Performance
This usecase defines the acceptable performance metrics for important usecases.
9
Treebase Software Architecture Document
Security
This usecase defines the acceptable security requirements for important usecases.
4.
Logical View
4.1
Overview
The Treebase system has a layered design. The Data Tier is implemented in DB2. The Server Tier
contains the core functional layers that have following major components: domain-object model, domain
logic process, persistence access, and web MVC presentation framework. The Service Layer implements
different interfaces for accessing external resources, like Cipres CORBA services, and 3 rd party Web
Services.
Client
Tier
3rd Party
Web Browser
Software
HTTP
SOAP
Web View Layer
Web Service API
Spring Web MVC
Framework
Service Layer
Cipres
Transaction
Security
Business
Server
Tier
Logging
IIOP
Object Model
Hibernate
JDBC
Data
Tier
DB2
Treebase II Architecture Overview
4.2
Architecturally Significant Design Packages
Database Layer
10
CORBA
Services
Logic
Persistence
API
Java IDL
Treebase Software Architecture Document
The DB2 enterprise edition is selected mainly due to it is free for us. The data schema is mostly generated
using Hibernate.
Persistence Layer
Hibernate is used for persistence access implementation: including object – relational mapping, data
caching, query, schema generation, and transactional object life cycle support. The persistence classes are
located in the org.cipres.treebase.dao.* packages.
Object Model Layer
Object model consists of interconnected domain objects, each with properties as well as behaviors. The
object model layer also includes the persistence access interface, the business service interface, and the
domain object validation logic. The domain classes are in the org.cipres.treebase.domain.* packages.
Business Services Layer
The business services layer provides the interfaces for the entry points to the business logics. These
interfaces separate the client and the server. They are usually coarse grained API that represents the
application behaviors defined in the use case realizations.
This layer also handles transaction demarcation. The services classes are in the
org.cipres.treebase.service.* packages.
Web MVC Controller Layer
Apache Tomcat is used as the servlet container.
Spring MVC framework is selected to be the web Model-View-Controller (MVC) framework. It provides
tight integration with the underlying business services layer. It is also very flexible to integrate different
web view technologies.
The “OpenSessionInViewFilter” pattern in the Spring framework is used by the web controllers to open a
Hibernate session for each incoming HTTP request.
Web Presentation Layer
This layer consists of the user interface to be displayed as web pages to the users.
Spring Framework
The Spring framework is used as the main application framework to integrate different layers and
components. The main advantages for the Spring framework: light weight, highly flexible, and open
source. Specifically, Spring framework provides excellent out-of-box support for the components we use:
Hibernate, Spring MVC, Java IDL, Web services API, and JUnit.
Spring framework supports two main technologies: Dependency Injection and Aspect Oriented
Programming (AOP). We use dependency injection to separate the interfaces and their implementation to
reduce the code coupling, especially between the different layers. The dependency injection also makes the
unit testing very easy. We use the AOP support to implement declarative transaction management,
security, logging, and exception handling.
11
Treebase Software Architecture Document
Java Annotation
We take advantage of the J2SE 5.0 annotation support in Hibernate to define the O/R mappings in the
domain classes.
4.3
Use-Case Realizations
[A use-case implementation usually composes of different subcomponents in different layers. These
subcomponents form a vertical slice of a use-case realization.]
<TODO> To be added in the later iterations. Add an example, like the Create User usecase or a more
complicated one. Need component diagram and collaboration diagram.
5.
Process View
[This section describes the system's decomposition into lightweight processes (single threads of control)
and heavyweight processes (groupings of lightweight processes). Organize the section by groups of
processes that communicate or interact. Describe the main modes of communication between processes,
such as message passing, interrupts, and rendezvous.]
6.
Deployment View
The system is deployed in a server environment. Potential alternate deployments scenarios can arise,
depends on the requirements for the Notebook project and the Cipres-dev project.
7.
Implementation View
[This section describes the overall structure of the implementation model if it differs significantly from the
Logic View. For example, the decomposition of the software into layers and subsystems in the
implementation model, and any architecturally significant components.]
<TODO>
8.
Size and Performance
[A description of the major dimensioning characteristics of the software that impact the architecture, as
well as the target performance constraints.]
9.
Quality
[A description of how the software architecture contributes to all capabilities (other than functionality) of
the system: extensibility, reliability, portability, and so on. If these characteristics have special significance,
such as safety, security or privacy implications, they must be clearly delineated.]
12