• Eugene
• Spectacles
• Kepler
• Data Model

Clotho - Greek Goddess and Software Tool (Courtesy of [http://christinetsin.designbinder.com/ Christine Tsin])

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 - Here we illustrate the five steps that our project focuses on. Also implicitly illustrated is a "bottom" up design process which begins at the "parts level" and continues upward to the "device" and "system" levels.

Step #1: Data Management - Clotho

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 [http://partsregistry.org/Main_Page 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 (flexible database support), we continue to allow flexible database support. Now however, we have provided a much more consistent interface to designers. We have done this in part by using Java's [http://www.hibernate.org hibernate] for data persistence. This involves the standardization of two APIs:

• Communication API - how tools talk to one another.
• Data API - how data is retrieved and stored from databases.

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 [http://en.wikipedia.org/wiki/Plug-in_(computing) "plug-ins"]. With this extension and simplified API, even those unfamiliar with Clotho can write their own tools easily. We can't wait to see all the tools that users come up with!

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.

Step #2: Specification - Eugene

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.

For example let's say you know that you want a basic device consisting of a [http://en.wikipedia.org/wiki/Promoter promoter], [http://en.wikipedia.org/wiki/Ribosomal_Binding_Site ribosome binding site], an [http://en.wikipedia.org/wiki/Open_reading_frame open-reading frame], and then a [http://en.wikipedia.org/wiki/Terminator_(genetics) terminator]. You can quickly specify this in Eugene. You can now share this high level design with others without actually specifying any low level details (e.g. the DNA sequence).

The next step would be to specify rules. You can specify that the promoter must have a specify strength, the binding site have a certain sequence, and the terminator be of a certain type. These rules will be triggered if a device is constructed with does not comply with these specification.

Finally, the executable nature of Eugene allows for permutations of devices which do not break rules to be generated automatically. In this way, large sets of correct-by-construction devices can be created and sent to other tools or assembly workflows.

Step #3: Construction - Spectacles

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.

The key here is that Eugene allows for abstract devices to be specified. Actual implementations (assigning DNA parts) can be done with Spectacles. Spectacles is a fully functioning Clotho tool which gives it access to number of other tools so that it is part of a complete design flow. Spectacles also produces Eugene files as well which can then be used in other parts of the design flow or by future Eugene-specific tools.

Step #4: Physical Assembly - Kepler

Once all the design has been done, it will be meaningless unless there is a path to physically create the DNA for the device. We are able to do this by leveraging knowledge about a parts construction (from Spectacles), its physical location in a plate (from Clotho's part's manager), its optimal assembly (via the algorithm manger), and the workflow to generate files for a liquid handling robot (via Kepler). Together we have created a flow whereby one can complete a design flow from start to finish from the comfort of their own computer.

Step #5: Design Flows

Design Flow Overview - Here we illustrate the interaction between Eugene, Spectacles, Kepler and Clotho. This is done via the Communication and Data APIs.

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. The figure above shows such a workflow. Here we point out the close relationship between the specification process in Eugene and the construction process in Spectacles. In addition we highlight the need for Data and Communication APIs. The dotted lines encapsulate tools within the Clotho framework. Kepler is an external tool which we are able to communicate to with the help of a special tool for invoking java methods remotely from other programs. This design flow represents the the power of creating tools which each handle different parts of the design process and are unified formally in a complete design environment.