AHM_Core1

judgedrunkshipΔιακομιστές

17 Νοε 2013 (πριν από 3 χρόνια και 1 μήνα)

70 εμφανίσεις

Core 1 @ Stanford University

BioPortal

Lynn Murphy

Archana Vembakam


Goal






Software development process


how we
achieve our goal


Demo

Topics

GRANT

BioPortal

Goal
-

What are we trying to produce?


Enterprise level, production quality
software


Industrial
-
strength, mission critical, robust,
scalable


Custom web application


Functionality specific to the ontology community


User experience and interface design tailored


Not generic

Software Development
Process

-

How we achieve our goal

Analysis and

Software

Requirements

Gathering

Design

Development

Testing

Deployment

Oct

2005

Nov

2005

Dec

2005

Feb

2006

Jan

2006

Mar

2006

Project

Start

Effective Start

Date for Archana

and Lynn

Software Development Process:

Analysis / Requirements


Extracted requirements from grant proposal


Gathered functional requirements from Berkeley
regarding current OBO at Sourceforge


Many requirements general, high level
-

translation into specific tasks necessary


Developed functional requirements document which
identified users, user roles, and
large

list of functional
requirements for the project


Requirements drive the design and architecture of
system



early identification of requirements key


Must have, nice to have (rank)


Changing requirements slows development

BioPortal Functionality
Overview


Ontology submission


Submission pipeline


Validation
-

file type/completeness, syntax, content


Versioning


Ontology metadata


Categorize ontologies


Associate provenance & ontology editing info with
particular ontology classes


Support a web
-
of
-
trust platform for rating ontology
quality

File / Version

Submission

Basic Validation

Further Validation

Background

Processing

File to

Holding Bin

User Notified

By Email

OBO Librarian Review

Convert file to

LexGrid DB Schema

Indexing Using LexGrid

Alignment
-

PROMPT

User Interface

Control back to UI

Success?

DB Status

Change

Workflow
Ontology Submission

Format Validation

Success?

Success?

Success?

DB Status

Change

Yes

No

Yes

Yes

No

No

Yes

BioPortal Functionality
Overview
-

Continued


Ontology indexes and services


All ontology content in the BioPortal is parsed,
validated, and indexed


URIs for all terms, even if none provided


Term alignment across ontologies


Terminological services (LexGrid
-

Mayo)


Double metaphone, exact and partial search


Web services for users and applications


Find ontology terms


Map free
-
text to ontologies

BioPortal Functionality
Overview
-

Continued


Ontology visualization


Tree display


Graph
-
based visualization


Interactive visualization (Jambalaya
-

UVic)


Ontology navigation (UVic)


Personalized guidance (degree
-
of
-
interest modeling)


Tools to let users focus on
ontology subsets

pertinent to
their
context

(e.g., data to be annotated)


Pictorially
-
guided navigation of ontologies


Ontology subsets based on biological scale
(organ/tissue/cell/molecule)


Ontology alignment and difference


Alignment
-

find related ontologies


Difference
-

track changes in versions of ontologies

BioPortal Functionality Overview:

Ontology Visualization

Dynamically
-
generated graph to display subsets of large ontologies


BioPortal Functionality Overview:

Ontology Visualization

Jambalaya provides graphical metaphors for dynamically navigating ontologies

Work by Nigam Shah

BioPortal Functionality Overview:

Ontology Visualization

Pictorial
-
guided ontology navigation

Software Development Process:


Phased Development


Developed project plan


functionality developed in phases


Phase 1
-

build framework / subsystem which will translate into a
scalable, robust application


“Unsexy before sexy”


Functionality


Authorization / Authentication


sign in, sign out, user
registration, password assistance, account maintenance


Ontologies


tabular list, category (tree) list, view (text), download


New ontology submission


file upload and metadata capture,
versioning


Metadata


view details, update, download in XML


Versions


list, view details, update, version submission

Software Development Process:


Design


Investigated software resources


Protégé, PROMPT, LexGrid


Necessary to install, determine features and examine code to
determine if and how technologies could be used


Example: installed LexGrid, determined functionality gaps,
communicated requirements to Mayo


Looking beyond Phase 1 to future phases so other teams can begin
needed work now


Researched technology stack (Java, JBoss, Java Server Faces,
JMS, etc.)


Prototyped functionality


authentication / authorization, serving
files through Apache / Tomcat, connection between user
interface and session beans, etc.


Designed architecture

Software Development Process:


Design Considerations


Disparate user interface


need for remote and local
access


Distributed transactions


Cache


Aspect oriented programming (AOP)


Background and message driven processing


Rapid development (POJO)


SOAP


Authentication and Authorization

JAAS

Authorization &

Authentication

JBoss Application Server

JMS

Messaging

Java Mail

Generic Subsystem

Oracle

Database

Soap Services

External access

WebDAV

File access

module

Apache Web Server

User Interface

JSF, JSP, Servlets,

Applets, CSS, HTML

Message Driven

Beans

Session Beans

Entity Beans

PROMPT API

Protégé API

LexGrid API

Architecture

Software Development Process:

Development


Yay! We finally get to code!



Spent time setting up development
environment


Subversion, build scripts, etc.


Began coding mid
-
January



approximately
6 weeks


~70 Java files, 20+ screens already


Writing production code


not one
-
off
development

Software Development Process:

Testing & Deployment

Testing


Need to develop unit tests so that new features can
be incorporated without introducing instability


Crucial to be able to roll out later phases

Deployment


Ongoing meetings with various Stanford IT
departments


Cost benefit analysis as to where BioPortal should
be hosted


Backup and failover strategy, power considerations,
hardware specifications, machine configurations

Demo


Demo is actual working code


not one
-
off
development


Design, color scheme, layout
will

change


No navigational features (tabs, etc.)


Data hand
-
entered for purposes of testing
and demo


may be inaccurate

Summary


Goal is production quality, enterprise level custom web
application


Development processes in place to ensure quality, robust,
supportable

software


Functionality introduced in phases


base system and framework
first


Requirements drive architecture


Phase 1 rollout


Approximate date


June


Gating factors


Moving files, their versions and associated metadata from current
Sourceforge site


Availability of production environment


Logo


???