Team:Berkeley Software/Project

From 2009.igem.org

(Difference between revisions)
Line 6: Line 6:
|rightSideBox=
|rightSideBox=
{{imageMap|imap|/wiki/images/6/65/BerkeleySoftware_MenuFaded.png|300|350|
{{imageMap|imap|/wiki/images/6/65/BerkeleySoftware_MenuFaded.png|300|350|
-
{{imageMapLink|Eugene|106|0|193|208|/wiki/images/7/79/BerkeleySoftware_EugenelPuzzlePiece.png}}
+
{{imageMapLink|Eugene|111|0|189|202|/wiki/images/7/79/BerkeleySoftware_EugenelPuzzlePiece.png}}
-
{{imageMapLink|Spectacles|0|149|193|200|/wiki/images/e/e7/BerkeleySoftware_SpectaclesPuzzlePiece.png}}
+
{{imageMapLink|Spectacles|0|154|187|196|/wiki/images/e/e7/BerkeleySoftware_SpectaclesPuzzlePiece.png}}
-
{{imageMapLink|Kepler|118|150|181|199|/wiki/images/e/ef/BerkeleySoftware_KeplerPuzzlePiece.png}}
+
{{imageMapLink|Kepler|123|155|177|195|/wiki/images/e/ef/BerkeleySoftware_KeplerPuzzlePiece.png}}
-
{{imageMapLink|DataModel|0|0|184|213|/wiki/images/b/bd/BerkeleySoftware_DataModelPuzzlePiece.png}}
+
{{imageMapLink|DataModel|0|0|178|206|/wiki/images/b/bd/BerkeleySoftware_DataModelPuzzlePiece.png}}
}}<html>
}}<html>
 +
<style>
 +
#rightSideBox p { margin: 0; }
 +
#imap { margin: 0; }
 +
</style>
<ul id="imap">
<ul id="imap">
<li id="Eugene"></html>[[Team:Berkeley_Software/Eugene|Eugene]]<html></li>
<li id="Eugene"></html>[[Team:Berkeley_Software/Eugene|Eugene]]<html></li>

Revision as of 08:44, 18 October 2009






Video placeholder

Our Project

Contents

Introduction

Clotho - Greek Goddess and Software Tool

In any design process there exists a hierarchy of design activities. Higher level activities build upon lower level activities leading to two design approaches: bottom up design and top down design. Bottom up design begins with primitive elements. These elements are combined to form more complex designs. This process is driven by a number of local objective functions. These objectives are abstracted at each level until at the end of the process, a large global objective is met. Top down design, starts with a specification and global objectives. The problem is decomposed into smaller sub-problems each with their own local objectives. This continues until all the primitive elements are specified. As synthetic biology moves toward a more engineering oriented discipline we see a hierarchy appearing as well. This consists of:

  • System Design - collections of devices whereby large system behavior can be simulated and analyzed
  • Device Design - the composition of primitive parts to produce specific functionality
  • Part Design - the encapsulation of DNA sequence information along with information for composition with other parts

Each level has a number of design activities associated with it. A sample of these are shown on the right hand side in the figure below. With this hierarchy in place it now becomes a task of creating software tools which span this hierarchy. It is not enough to just put tools in place at each level however. They must be unified such that design flows are enabled which allow both top down and bottom up design activities.

Our project attempts to do just that. By beginning with the Clotho design environment as our foundation, we focused on device level activities with Eugene, Spectacles and Kepler. In addition, we strengthened part level development by totally revamping Clotho's core data model and associated APIs. Clotho now is a much more developer and user friendly experience. The figure and sections below provide a brief introduction to each of the various sub-projects we focused on. For more in-depth information we invite you to visit the individual project pages. Enjoy!



Project Overview

#1 Data Management

The key challenges in data management are: storing data, retrieving data, using data, and sharing data. These challenges in synthetic biology are made more difficult by the relative infancy of the field coupled with the vast number of differing interpretations regarding data organization and data relationships. As registries such as MIT's registry of standardized biological parts focus on storing data, we focus on making data retrieval, data usage, and data sharing easier.

In keeping with a the major achievement of Clotho, we continue to allow flexibly database support. Now however, we have provided a much more consistent interface to designers. This involves the standardization of two APIs:

  • Communication API
  • Data API

The communication API provides a way for Clotho tools to "talk" to one another much more easily. In addition, all Clotho tools now all extend a basic ClothoTool object which essentially makes all tools "plug-ins". With this extension and simplified API, even those unfamiliar with Clotho can write their own tools easily.

The data API provides Clotho Tools a very simple way of looking up data. The API, combined with a "keyword" list allows tools to be written without complex queries or an understanding of how the underlying database is organized. Getting and saving data now simply relies on a basic "datum" object.

#2 Specification

We have created a domain specific language named Eugene for the specification of biological constructs. Not only does this allow users to capture and share human readable specifications but also the specification is now a language which can be executed by Clotho tools as an executable specification for the creation of devices, the specification of rules, and a intermediate data exchange format between tools.


#3 Construction

In order to design composite devices, Spectacles provides a visual editing environment. Not only does this allow for a complete drag and drop "schematic" editor style design experience, but it also checks and enforces Eugene based rules, provides visual cues regarding the design's properties, and is completely integrated with the rest of the Cloth design environment. The latter allows the user to assign actual parts from registries to the functional concept captured by Spectacles.

#4 Physical Assembly

#5 Design Flows

Design Flow Overview

The key to a truly useful set of tools is a design flow that helps the designer not only be more productive and efficient but also perform correct-by-construction design.