Team:Berkeley Software/Eugene

From 2009.igem.org

(Difference between revisions)
 
(31 intermediate revisions not shown)
Line 3: Line 3:
|video=
|video=
<center><html><object width="560" height="340"><param name="movie" value="http://www.youtube.com/v/cR2xCdqP4hA&hl=en&fs=1&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/cR2xCdqP4hA&hl=en&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="560" height="340"></embed></object></html></center>
<center><html><object width="560" height="340"><param name="movie" value="http://www.youtube.com/v/cR2xCdqP4hA&hl=en&fs=1&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/cR2xCdqP4hA&hl=en&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="560" height="340"></embed></object></html></center>
 +
 +
__NOTOC__
|rightSideBox=
|rightSideBox=
Line 11: Line 13:
|intro=
|intro=
-
With the rise of partification in synthetic biology, there needs to be a formal specification to describe standard biological parts, especially when designing complex devices. The specification needs to be both human-writable and human-readable, a language that raises the level of abstraction where bioengineers can work. Eugene is such a language. Engineering at the part level requires both flexibility and rigidity. Eugene allows the user to mix custom parts with predefined parts from established databases. Parts can encapsulate an arbitrary amount of information, anything from a DNA sequence to experimental history. When designing a device in Eugene, parts can be freely stitched together on a whim, or strictly joined together based on rules. The design process is meant to be systematic yet intuitive. The user considers what information parts include, constructs parts to be used in the design, enforces restrictions on how parts can interact, and creates devices that are composites of the parts or other devices. Being a textual design, a device specified in Eugene is portable and easily lends itself to being translated into other formats, such as XML. In synthetic biology, the notion of part changes regularly and is debated tirelessly. Thus, Eugene tries to be adaptable and expressive in any climate. This page goes into the language specification in detail.<br><br>
+
[[Image:Eugene.png|112px|right|thumb|<span style="font-family: Georgia, serif;">Eugene - Red-headed stepchild and language (Courtesy of [http://christinetsin.designbinder.com/ Christine Tsin])</span>]]
-
 
+
<font size="4">W</font>ith the rise of partification in synthetic biology, there needs to be a formal specification to describe standard biological parts, especially when designing complex devices. The specification needs to be both human-writable and human-readable, a language that raises the level of abstraction where bioengineers can work. Eugene is such a language. Engineering at the part level requires both flexibility and rigidity. Eugene allows the user to mix custom parts with predefined parts from established databases. Parts can encapsulate an arbitrary amount of information, anything from a DNA sequence to experimental history. When designing a device in Eugene, parts can be freely stitched together on a whim, or strictly joined together based on rules. The design process is meant to be systematic yet intuitive. The user considers what information parts include, constructs parts to be used in the design, enforces restrictions on how parts can interact, and creates devices that are composites of the parts or other devices. Being a textual design, a device specified in Eugene is portable and easily lends itself to being translated into other formats, such as XML. In synthetic biology, the notion of a part changes regularly and is debated tirelessly. Thus, Eugene tries to be adaptable and expressive in any climate. This page goes into the language specification in detail. We break the discussion up into four sections. We first discuss the language definition. Here we provide the basics of the language and how to construct a design using Eugene. Next we discuss some [https://2009.igem.org/Team:Berkeley_Software/Eugene_Examples example designs created with Eugene]. This is followed by a discussion on how the language is [https://2009.igem.org/Team:Berkeley_Software/Eugene_Implementation implemented and the data structures required]. Finally we provide some [https://2009.igem.org/Team:Berkeley_Software/Eugene_Results sample results] which illustrate the power of Eugene when applied to a number of published designs. Each section can be accessed with the buttons provided. Enjoy!<br><br>
-
<table align=center>
+
<br clear="all">
 +
<!---<table align=left frame="box">
<tr>
<tr>
-
<td>'''<span id="contentMenu">Contents</span>''':
+
<th>'''<span id="contentMenu">Contents</span>'''</th>
-
<li>[[#Introduction|Introduction]]
+
-
<li>[[#Language_Definition|Language Definition]]
+
-
<li>[[#Examples|Examples]]
+
-
<li>[[Team:Berkeley_Software/Eugene_Implementation|Implementation]]
+
-
<li>[[Team:Berkeley_Software/Eugene_Results#Results|Results]]
+
-
<li>[[Team:Berkeley_Software/Eugene_Results#Conclusions|Conclusions]]
+
-
</td>
+
</tr>
</tr>
-
</table>
+
<tr><td>[[#Introduction|1. Introduction]]</td></tr>
 +
<tr><td>[[#Language_Definition|2. Language Definition]]</td></tr>
 +
<tr><td>[[Team:Berkeley_Software/Eugene_Examples|3. Examples]]</td></tr>
 +
<tr><td>[[Team:Berkeley_Software/Eugene_Implementation|4. Implementation]]</td></tr>
 +
<tr><td>[[Team:Berkeley_Software/Eugene_Results|5. Results]]</td></tr>
 +
</table>-->
 +
 
 +
 
 +
<center><div>
 +
<html>
 +
<a href="https://2009.igem.org/Team:Berkeley_Software/Eugene_Examples">
 +
<img src="https://static.igem.org/mediawiki/2009/0/02/ExampleButton.png">
 +
</a>
 +
<a href="https://2009.igem.org/Team:Berkeley_Software/Eugene_Implementation">
 +
<img src="https://static.igem.org/mediawiki/2009/c/c6/ImplementationButton.png">
 +
</a>
 +
<a href="https://2009.igem.org/Team:Berkeley_Software/Eugene_Results">
 +
<img src="https://static.igem.org/mediawiki/2009/b/b3/ResultsButton.png">
 +
</a>
 +
<!--- https://static.igem.org/mediawiki/2009/3/39/Language.png --->
 +
</html>
 +
</div></center>
 +
 
|content=
|content=
<span id="Language_Definition"><H3>Language Definition</H3></span>
<span id="Language_Definition"><H3>Language Definition</H3></span>
-
In this section we describe the elements in the language. These involve: [[#Primitives|primitive data types]], [[#Properties|properties]], [[#Parts|parts]], [[#Devices|devices]], [[#Rules|rules]], and [[#ConditionalSt|conditional execution]]. The relationships between these language elements are shown in Figure 2. Here you can see that each subsequent category is built upon the previous category.
+
In this section we describe the elements in the language. These involve: [[#Primitives|primitive data types]], [[#Properties|properties]], [[#Parts|parts]], [[#Devices|devices]], [[#Rules|rules]], [[#ConditionalSt|conditional execution]], and [[#Functions|functions]]. The relationships between these language elements are shown in Figure 1. Here you can see that each subsequent category is built upon the previous category.
-
<br>[[Image:DataModelHierarchy.png|450px|thumb|left|<p style="text-align: center;"><font size = "2"><span style="font-family: Georgia, serif;">Figure 2: Relationship between Eugene Categories</span></font></p>]]
+
<br>[[Image:DataModelHierarchy.png|450px|thumb|left|<p style="text-align: center;"><font size = "2"><span style="font-family: Georgia, serif;">Figure 1: Relationship between Eugene Categories</span></font></p>]]
-
 
+
<br><br>
<span id="Primitives"><b><font size="3">Primitives </font></b><br></span>
<span id="Primitives"><b><font size="3">Primitives </font></b><br></span>
The language supports five predefined primitives. These are txt, num, boolean, txt[], and num[]. Strings (sequences of characters) are represented through the data type “txt”, where the actual text is specified in double quotes. Real numbers and integers are supported by the data type “num” and logical values by the data type “boolean”.  Ordered lists of num and txt values can be created and individual members inside a list accessed by specifying an integer in the range from 0 to &#124;List&#124; - 1. <br><br>
The language supports five predefined primitives. These are txt, num, boolean, txt[], and num[]. Strings (sequences of characters) are represented through the data type “txt”, where the actual text is specified in double quotes. Real numbers and integers are supported by the data type “num” and logical values by the data type “boolean”.  Ordered lists of num and txt values can be created and individual members inside a list accessed by specifying an integer in the range from 0 to &#124;List&#124; - 1. <br><br>
Examples (1) and (2) are two real code snippets of how primitives can be specified in Eugene. “listOfSequences” is simply a list of 3 arbitrary DNA sequences. “specificSequence” is the last element of “listOfSequences” (i.e. “ATCG”). Examples (3) and (4) show how the data type “num” can support integers and decimals.<br><br>
Examples (1) and (2) are two real code snippets of how primitives can be specified in Eugene. “listOfSequences” is simply a list of 3 arbitrary DNA sequences. “specificSequence” is the last element of “listOfSequences” (i.e. “ATCG”). Examples (3) and (4) show how the data type “num” can support integers and decimals.<br><br>
-
<table><font size="2"><span style="font-family: Georgia, serif;">
+
[[Image:ScreenshotPrimitives.png|center]]<br><br>
-
<tr>
+
-
<td>txt[] listOfSequences = [ “ATG”, “TCG”, “ATCG”]; </td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(1) </td>
+
-
</tr>
+
-
<tr>
+
-
<td>txt specificSequence = listOfSequences[2];</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(2)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>num[] listOfNumbers = [2.5, 10, 3.4, 6];</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(3)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>num one = listOfNumbers[0]; </td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;</td>          
+
-
<td>(4)</td>
+
-
</tr>
+
-
</span></font>
+
-
</table><br><br>
+
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<span id="Properties"><b><font size="3">Properties</font></b><br></span>
<span id="Properties"><b><font size="3">Properties</font></b><br></span>
Properties represent characteristics of interest and are defined by primitives and associated with Parts. For example a user could define a property “Sequence” (the DNA sequence), ID (the uuid for a relational database which may hold the part), or Orientation (e.g. a forward or backward promoter). Examples 5-8 show how such properties would be defined. Property definitions must be defined by the five primitive types. In [[#Part_Definition|Part definitions]] properties will be bound to that Part as placeholders for the instantiation of values in [[#Part_Declaration|Part declarations]]. Properties have to be defined before Parts can use them. The user can create new Property labels or use those created by other users and captured in [[#Header_Files|header files]]. For example, the following Properties are predefined in the header file PropertyDefinition.h and do not need to be defined again if the header file is included in the main program:<br><br>
Properties represent characteristics of interest and are defined by primitives and associated with Parts. For example a user could define a property “Sequence” (the DNA sequence), ID (the uuid for a relational database which may hold the part), or Orientation (e.g. a forward or backward promoter). Examples 5-8 show how such properties would be defined. Property definitions must be defined by the five primitive types. In [[#Part_Definition|Part definitions]] properties will be bound to that Part as placeholders for the instantiation of values in [[#Part_Declaration|Part declarations]]. Properties have to be defined before Parts can use them. The user can create new Property labels or use those created by other users and captured in [[#Header_Files|header files]]. For example, the following Properties are predefined in the header file PropertyDefinition.h and do not need to be defined again if the header file is included in the main program:<br><br>
-
<table><font size="2"><span style="font-family: Georgia, serif;">
+
[[Image:ScreenshotProperties.png|center]]<br><br>
-
<tr>
+
-
<td>Property ID(txt);            </td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>// in header file</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(5) </td>
+
-
</tr>
+
-
<tr>
+
-
<td>Property Sequence(txt);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>// in header file</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(6)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>Property Orientation(txt);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>// in header file</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(7)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>Property RelativeStrength(num); </td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>// in header file</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>          
+
-
<td>(8)</td>
+
-
</tr>
+
-
</span></font>
+
-
</table><br><br>
+
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<span id="Parts"><b><font size="3">Parts</font></b><br></span>
<span id="Parts"><b><font size="3">Parts</font></b><br></span>
Line 104: Line 70:
Part definitions do not construct any Parts, but rather specify which Parts can be constructed. This can be done in the header file or in the main program. When the header file PartDefintion.h and PropertyDefintion.h are included, the following Parts and their corresponding property labels are predefined. For instance, the Part “Promoter” will have three properties associated with it and all instances of Promoter will inherit ID, Sequence and Orientation:<br><br>
Part definitions do not construct any Parts, but rather specify which Parts can be constructed. This can be done in the header file or in the main program. When the header file PartDefintion.h and PropertyDefintion.h are included, the following Parts and their corresponding property labels are predefined. For instance, the Part “Promoter” will have three properties associated with it and all instances of Promoter will inherit ID, Sequence and Orientation:<br><br>
-
<table><font size="2"><span style="font-family: Georgia, serif;">
+
[[Image:ScreenshotParts.png|center]]<br><br>
-
<tr>
+
-
<td>Part Promoter(ID, Sequence, Orientation);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(9) </td>
+
-
</tr>
+
-
<tr>
+
-
<td>Part ORF(ID, Sequence, Orientation);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(10)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>Part RBS(ID, Sequence, Orientation);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(11)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>Part Terminator(ID, Sequence, Orientation);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>          
+
-
<td>(12)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>Part RestrictionSite(ID, Sequence, Orientation);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>          
+
-
<td>(13)</td>
+
-
</tr>
+
-
<tr>
+
-
<td>Part PrimerSite(ID, Sequence Orientation);</td>
+
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>          
+
-
<td>(14)</td>
+
-
</tr>
+
-
</span></font>
+
-
</table><br><br>
+
If the properties are unknown during Part Definition process, the Part can be defined either empty or with the known properties. Later property labels can be added through the function addProperties() provided the property labels have been created beforehand. RBS will have four property labels after the following statement:<br><br>
If the properties are unknown during Part Definition process, the Part can be defined either empty or with the known properties. Later property labels can be added through the function addProperties() provided the property labels have been created beforehand. RBS will have four property labels after the following statement:<br><br>
-
<table><font size="2"><span style="font-family: Georgia, serif;">
+
[[Image:ScreenshotAddProperties.png|center]]<br><br><br>
-
<tr>
+
-
<td>RBS.addProperties(RelativeStrength);</td>
+
-
<td> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
+
-
<td>(15)</td>
+
-
</tr>
+
-
</span></font></table><br>
+
<span id="Part_Declaration"><font size="3">''Part Declaration''</font><br></span>
<span id="Part_Declaration"><font size="3">''Part Declaration''</font><br></span>
Part declarations make instances of predefined Parts and assign values to their properties. If the declaration specifies a list of values, it is assumed that every property will be assigned a value, where the order of the values corresponds to the order of the properties in the Part Definition as shown in example (17). Otherwise, a “dot notation“ followed by the name of the property can be employed, where the order becomes irrelevant as specified in the example below (16). The Part instance BBa_K112234_rbs has three properties associated with the Part RBS. These are ID, Sequence and Orientation. The identification label of a particular part from a database is stored in the ID placeholder to allow future access to the database. Sequence stores the DNA of a Part, while Orientation specifies the direction of the Part. Since dot notation is used, the ID value instantiation can be left out from the statement. Part declarations can be found in the header file PartDeclarations.h and are predefined if the header files are included in the main program.  
Part declarations make instances of predefined Parts and assign values to their properties. If the declaration specifies a list of values, it is assumed that every property will be assigned a value, where the order of the values corresponds to the order of the properties in the Part Definition as shown in example (17). Otherwise, a “dot notation“ followed by the name of the property can be employed, where the order becomes irrelevant as specified in the example below (16). The Part instance BBa_K112234_rbs has three properties associated with the Part RBS. These are ID, Sequence and Orientation. The identification label of a particular part from a database is stored in the ID placeholder to allow future access to the database. Sequence stores the DNA of a Part, while Orientation specifies the direction of the Part. Since dot notation is used, the ID value instantiation can be left out from the statement. Part declarations can be found in the header file PartDeclarations.h and are predefined if the header files are included in the main program.  
<br><br>
<br><br>
-
<table><font size="2"><span style="font-family: Georgia, serif;">
 
-
<tr>
 
-
<td>RBS BBa_K112234_rbs (.Sequence("GATCTtaattgcggagacttt"), .Orientation("Forward")); </td>
 
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
 
-
<td>(16)</td>
 
-
</tr>
 
-
<td>RBS BBa_K112234_rbs (“BBa_K112234_rbs”, "GATCTtaattgcggagacttt", “Forward”);</td>
 
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
 
-
<td>(17)</td>
 
-
<tr>
 
-
</tr>
 
-
</span></font></table><br><br>
 
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
[[Image:ScreenshotPartDeclaration.png|950px|center]]<br><br>
 +
 
 +
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<span id="Devices"><b><font size="3">Devices</font></b><br></span>
<span id="Devices"><b><font size="3">Devices</font></b><br></span>
-
Devices represent a composite of standard biological Parts and/or other Devices. In a Device declaration, the same Part and/or device can be used more than once. Property values of devices can be accessed with the dot operator; however, the value is the union of the property values of its members returned as a list. If the property is a txt or num, a txt[] or a num[] is returned. If the property is a txt[] or a num[], a txt[] or a num[] is also returned that consists of the lists appended together. For example the sequence of Device BBa_K112133 is the ordered union of the sequence of Part BBa_K112126 and the Device BBa_K112234. These two Devices are shown in Figures 3a and 3b, where the icon figures use true [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language Visual BioBrick Open Language symbols (vBOL)] icon graphic.<br><br>
+
Devices represent a composite of standard biological Parts and/or other Devices. In a Device declaration, the same Part and/or device can be used more than once. Property values of devices can be accessed with the dot operator; however, the value is the union of the property values of its members returned as a list. If the property is a txt or num, a txt[] or a num[] is returned. If the property is a txt[] or a num[], a txt[] or a num[] is also returned that consists of the lists appended together. For example the sequence of Device BBa_K112133 is the ordered union of the sequence of Part BBa_K112126 and the Device BBa_K112234. These two Devices are shown in Figures 2a and 2b, where the icon figures use true [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language Visual BioBrick Open Language symbols (vBOL)] icon graphic.<br><br>
<p align=center><b>Table 1: Relationship between vBOL and Eugene</b></p>
<p align=center><b>Table 1: Relationship between vBOL and Eugene</b></p>
<table border="1" CELLPADDING=8 align=center><font size = "2"><span style="font-family: Georgia, serif;">
<table border="1" CELLPADDING=8 align=center><font size = "2"><span style="font-family: Georgia, serif;">
Line 177: Line 95:
<tr>
<tr>
<td>[[Image:Spectacles_screenshot_BBa_K112133.jpg|center]]</td>
<td>[[Image:Spectacles_screenshot_BBa_K112133.jpg|center]]</td>
-
<td><b>Figure 3a:</b> [http://partsregistry.org/Part:BBa_K112133 Device BBa_K112133], consisting of one <br>[http://partsregistry.org/Part:BBa_K112126 Part Promoter BBa_K112126] and one [http://partsregistry.org/Part:BBa_K112234 Device BBa_K112234]</td>
+
<td><b>Figure 2a:</b> [http://partsregistry.org/Part:BBa_K112133 Device BBa_K112133], consisting of one <br>[http://partsregistry.org/Part:BBa_K112126 Part Promoter BBa_K112126] and one [http://partsregistry.org/Part:BBa_K112234 Device BBa_K112234]</td>
<td>Device BBa_K112133(BBa_K112126, BBa_K112234);  </td>
<td>Device BBa_K112133(BBa_K112126, BBa_K112234);  </td>
</tr>
</tr>
<tr>
<tr>
<td>[[Image:Spectacles_screenshot_BBa_K112234.jpg|center]]</td>
<td>[[Image:Spectacles_screenshot_BBa_K112234.jpg|center]]</td>
-
<td><b>Figure 3b</b>: [http://partsregistry.org/Part:BBa_K112234 Device BBa_K112234], consisting of one <br> Part Ribosome Binding Site and one Part Open Reading Frame</td>
+
<td><b>Figure 2b</b>: [http://partsregistry.org/Part:BBa_K112234 Device BBa_K112234], consisting of one <br> Part Ribosome Binding Site and one Part Open Reading Frame</td>
<td>Device BBa_K112234(BBa_K112234_rbs, BBa_K112234_orf); </td>
<td>Device BBa_K112234(BBa_K112234_rbs, BBa_K112234_orf); </td>
</tr>
</tr>
Line 188: Line 106:
Individual Parts can be accessed through the use of square brackets and an index. The first member is indexed at zero. Square brackets can be stacked in the case of devices within devices. To access the first element BBa_K112234_rbs of Device BBa_K112234 through Device BBa_K112133, the following notation is supported:<br><br>
Individual Parts can be accessed through the use of square brackets and an index. The first member is indexed at zero. Square brackets can be stacked in the case of devices within devices. To access the first element BBa_K112234_rbs of Device BBa_K112234 through Device BBa_K112133, the following notation is supported:<br><br>
-
<table><font size="2"><span style="font-family: Georgia, serif;">
 
-
<tr>
 
-
<td>BBa_K112133[1][0]</td>
 
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
 
-
<td>// references BBa_K112234_rbs</td>
 
-
<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</td>
 
-
<td>(18)</td>
 
-
</tr>
 
-
</span></font></table><br><br>
 
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
[[Image:ScreenshotAccessingDevice.png|950px|center]]<br><br>
 +
 
 +
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<span id="Rules"><b><font size="3">Rules</font></b><br></span>
<span id="Rules"><b><font size="3">Rules</font></b><br></span>
-
The specification of rules provides the ability to validate Device declarations. Rule declarations in themselves do not perform the validation. They have to be “noted”, “asserted” or used as expressions inside an if-statement to give meaning. Rule declarations are single statements consisting of a left and right operand and one rule operator. The rule operators BEFORE, AFTER, WITH, NOTWITH, NEXTTO, NOTCONTAINS, NOTMORETHAN can be applied to Part instances or Device instances. Property values of Part/Device instances or primitives in relation with one Part/Device can be operators in rule declarations when using the relational operators <, <=, >, >=, !=, ==. These operators are overloaded when evaluating text and the text is compared according to alphabetical meaning. Table 2 provides a summary of the operators for Eugene rules.<tr><tr>
+
The specification of rules provides the ability to validate Device declarations. Rule declarations in themselves do not perform the validation. They have to be “noted”, “asserted” or used as expressions inside an if-statement to give meaning. Rule declarations are single statements consisting of a left and right operand and one rule operator. The rule operators BEFORE, AFTER, WITH, NOTWITH, NEXTTO, NOTCONTAINS, NOTMORETHAN can be applied to Part instances or Device instances. Property values of Part/Device instances or primitives in relation with one Part/Device can be operators in rule declarations when using the relational operators <, <=, >, >=, !=, ==. These operators are overloaded when evaluating text and the text is compared according to alphabetical meaning. Table 2 provides a summary of the operators for Eugene rules.<br><br>
 +
 
<p align=center><b>Table 2: Eugene Operators for Specifying Rules</b></p>
<p align=center><b>Table 2: Eugene Operators for Specifying Rules</b></p>
<table border="1" align=center CELLPADDING=8><font size = "2"><span style="font-family: Georgia, serif;">
<table border="1" align=center CELLPADDING=8><font size = "2"><span style="font-family: Georgia, serif;">
Line 236: Line 148:
</tr>
</tr>
<th align=left colspan=2>Comparison Operators</th>
<th align=left colspan=2>Comparison Operators</th>
-
</tr>
 
<tr>
<tr>
<td><</td>
<td><</td>
Line 319: Line 230:
</span></font></table><br><br>
</span></font></table><br><br>
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<b><font size="3">Asserting and Noting Rules</font></b><br>
<b><font size="3">Asserting and Noting Rules</font></b><br>
Line 325: Line 236:
<font size="3">''Rule Assertion''</font><br>
<font size="3">''Rule Assertion''</font><br>
These statements are strong assertions and the program terminates with an error once a Device composition violates the statement. The following statement will check if BBa_K112234_rbs is not contained together with BBa_K112234_orf in the Device and their sequences should not be equal. In this case an error will terminate the program since both parts are components of the device, therefore violating the Assert statement.<br><br>
These statements are strong assertions and the program terminates with an error once a Device composition violates the statement. The following statement will check if BBa_K112234_rbs is not contained together with BBa_K112234_orf in the Device and their sequences should not be equal. In this case an error will terminate the program since both parts are components of the device, therefore violating the Assert statement.<br><br>
-
<font size="2"><span style="font-family: Georgia, serif;">
+
 
-
<pre>
+
[[Image:ScreenshotAssert.png|center]]<br><br>
-
Assert ((NOT r4) AND (NOT r2));
+
 
-
Device BBa_K112234(BBa_K112234_rbs, BBa_K112234_orf);
+
-
</pre>
+
-
</span></font><br><br>
+
<font size="3">''Rule Notes''</font><br>
<font size="3">''Rule Notes''</font><br>
Notes issue warnings in the output when the violation occurs. But the program continues running. In the following example the Device BBa_K112133 meets the first note’s condition. However, the next note is violated and the program will issue a warning.<br><br>
Notes issue warnings in the output when the violation occurs. But the program continues running. In the following example the Device BBa_K112133 meets the first note’s condition. However, the next note is violated and the program will issue a warning.<br><br>
-
<font size="2"><span style="font-family: Georgia, serif;">
 
-
<pre>
 
-
Note (r2 AND r3);
 
-
Note (NOT r1);
 
-
Device BBa_K112133(BBa_K112126, BBa_K112234);
 
-
</pre>
 
-
</span></font><br><br>
 
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
[[Image:ScreenshotNote.png|center]]<br><br>
 +
 
 +
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<span id="ConditionalSt"><b><font size="3">Conditional Statements</font></b><br></span>
<span id="ConditionalSt"><b><font size="3">Conditional Statements</font></b><br></span>
Line 347: Line 250:
<font size="3">''Rule validating if-Statement''</font><br>
<font size="3">''Rule validating if-Statement''</font><br>
Rules can be checked not just through Assert and Note statements but also in an if-statement. In this approach only specific rules will be considered, as they might not apply to all Devices.  The notation should specify a list of Devices and a logical combination of rule instances pertaining to that list. Suppose we would like to test a rule only on the specific Device instance BBa_K112133, where the Promoter BBa_K112126 comes before the Ribosome Binding Site BBa_K112234_rbs. Then the following conditional statement can achieve such conditional evaluation. In this case, the if statement will evaluate to true:<br><br>
Rules can be checked not just through Assert and Note statements but also in an if-statement. In this approach only specific rules will be considered, as they might not apply to all Devices.  The notation should specify a list of Devices and a logical combination of rule instances pertaining to that list. Suppose we would like to test a rule only on the specific Device instance BBa_K112133, where the Promoter BBa_K112126 comes before the Ribosome Binding Site BBa_K112234_rbs. Then the following conditional statement can achieve such conditional evaluation. In this case, the if statement will evaluate to true:<br><br>
-
<font size="2"><span style="font-family: Georgia, serif;">
+
 
-
<pre>
+
[[Image:ScreenshotifRule.png|center]]<br><br>
-
Rule r7(BBa_K112126 BEFORE BBa_K112234_rbs);
+
-
if(on (BBa_K112133) r7) {
+
-
Block statement, in case of true evaluation
+
-
} else {
+
-
Block statement, in case of false evaluation
+
-
}
+
-
</pre></span></font><br><br>
+
<font size="3">''Standard if-Statement''</font><br>
<font size="3">''Standard if-Statement''</font><br>
Expressions not pertaining to rules and Devices can be evaluated by the standard if-statement which supports the relational operators <, <=, >, >=, !=, == as well as the logical operators AND, OR, NOT.<br><br>
Expressions not pertaining to rules and Devices can be evaluated by the standard if-statement which supports the relational operators <, <=, >, >=, !=, == as well as the logical operators AND, OR, NOT.<br><br>
-
<font size="2"><span style="font-family: Georgia, serif;">
 
-
<pre>
 
-
boolean test = true;
 
-
if(test) {
 
-
Assert(ruleWith);
 
-
} else {
 
-
Assert(NOT ruleWith);
 
-
}
 
-
Device BBa_K112133(BBa_K112126, BBa_K112234);
 
-
</pre></span></font><br><br>
+
[[Image:ScreenshotBooleanIf.png|center]]<br><br>
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
 +
 
 +
<span id="Functions"><b><font size="3">Functions</font></b><br></span>
 +
Functions are convenient actions users can invoke that are processed during runtime. The print function simply prints the argument to the console on a new line. The permute function automates the specification of many devices that share the same structure. It creates a device for every combination of predefined parts, maintaining the part type of each component in the argument device. If a component of the device is a device, even ones with only one part, it is not changed and appears in every permutation. Permutations are named <original device name>_<x> where <original device name> is the name of the argument device, and x is a number starting at 1. They can be accessed and manipulated like normally instantiated devices.<br><br>
 +
 
 +
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
<span id="Header_Files"><b><font size="3">Header Files</font></b><br></span>
<span id="Header_Files"><b><font size="3">Header Files</font></b><br></span>
The inclusion of header files allows the use of predefined Properties, Parts and Part Instances in the program. The manageability of code in the main file is more efficient by hiding the low level implementation of sequence and Parts. The user needs only to define Devices in the main file. On such a level the program can be written quickly and it is less error prone. Also, this allows each lab to have their own header file libraries. At the same time the option to change or declare other Properties, Parts and Part instances exists in the language.<br><br>
The inclusion of header files allows the use of predefined Properties, Parts and Part Instances in the program. The manageability of code in the main file is more efficient by hiding the low level implementation of sequence and Parts. The user needs only to define Devices in the main file. On such a level the program can be written quickly and it is less error prone. Also, this allows each lab to have their own header file libraries. At the same time the option to change or declare other Properties, Parts and Part instances exists in the language.<br><br>
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
 
-
-----
 
-
<span id="Examples"><H3>Examples</H3></span>
 
-
Several Device constructs have been selected from the Registry of [http://partsregistry.org/ Standard Biological Parts] to show the creation of visual and textual designs. The visual representation has been implemented using [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language Visual BioBrick Open Language symbols] and [[Team:Berkeley_Software/Spectacles|Spectacles]], a visual tool editor, while Eugene was employed to demonstrate a textual representation. Due to the one to one relationship between standard biological parts and the Eugene syntax, the conversion could easily be achieved in both directions.<br><br>
 
-
[http://partsregistry.org/Part:BBa_K112809 BBa_K112809] is T4 Lysis Device with Pbad as the inducible Promoter. The Lysis device allows for the easy release of any product produced in the cell. The main file in Figure 3b displays the construct as an ordered list of Parts, while the header files are imported to hide the details of the Part declarations. With only one line of declaration, a complicated Device construct can be reproduced while the detailed information can still be accessed.<br><br>
 
-
 
-
<p align="center">'''Figure 3a: Visual representation of BBa_K112809'''</p>
 
-
[[Image:Spectacles_screenshot_BBa_K112809.jpg|center]]<br>
 
-
 
-
<p align="center">'''Figure 3b: Textual representation of BBa_K112809'''</p>
 
-
[[Image:BBa_K112809Picture.png|900px|center]]<br><br>
 
-
 
-
[http://partsregistry.org/Part:BBa_E7104 BBa_E7104] is a GFP Reporter Device. Again, each new Device can be created using very few lines of code as Figure 4 demonstrates.<br><br>
 
-
 
-
<p align="center">'''Figure 4a: Visual representation of BBa_E7104'''</p>
 
-
[[Image:Spectacles_screenshot_BBa_E7104.jpg|center]]<br>
 
-
 
-
<p align="center">'''Figure 4b: Textual representation of BBa_E7104'''</p>
 
-
[[Image:BBa_E7104Picture.png | center]]<br><br>
 
-
 
-
[http://partsregistry.org/Part:BBa_K118021 BBa_K118021] in Figure 5a is a Promoter characterization Device. The second Part in [http://partsregistry.org/Part:BBa_K118021  BBa_K118021] is a Reporter as specified by the [http://partsregistry.org/ Standard Registry of Parts]. It has no image associated, since technically speaking [http://partsregistry.org/Part:BBa_J33204 BBa_J33204] is a Device. However, currently with the available standards and specifications, there does not exist a way of breaking this Device cleanly into separate existing Parts. For example, there needs to be a way of specifying point mutation, which could be a feature of Devices, currently not supported by Eugene but is considered for future releases. Therefore, [http://partsregistry.org/Part:BBa_K118021 BBa_K118021] was specified as the Part Reporter rather than Device in the code.<br><br>
 
-
 
-
<p align="center">'''Figure 5a: Visual representation of BBa_K118021'''</p>
 
-
[[Image:Spectacles_screenshot_BBa_K118021.jpg|center]]<br>
 
-
 
-
<p align="center">'''Figure 5b: Textual representation of BBa_K118021'''</p>
 
-
[[Image:BBa_K118021Picture.png|center]]<br><br>
 
-
 
-
[http://partsregistry.org/Part:BBa_I8510 BBa_I8510] in Figure 6a is an Inverter that takes 3OC6HSL as input and produces lacZalpha as output. It also creates an orthogonal GFP protein generator.<br><br>
 
-
 
-
<p align="center">'''Figure 6a: Visual representation of BBa_I8510'''</p>
 
-
[[Image:Spectacles_screenshot_BBa_I8510.jpg|center]]<br>
 
-
 
-
<p align="center">'''Figure 6b: Textual representation of BBa_I8510'''</p>
 
-
[[Image:BBa_I8510Picture.png|center]]<br><br>
 
-
<p style="text-align: right;">[[#contentMenu|back to Contents]]</p>
+
<p style="text-align: right;">[[#Language Definition|Back Up]]</p>
}}
}}

Latest revision as of 07:18, 26 April 2010



Eugene

Introduction

Eugene - Red-headed stepchild and language (Courtesy of [http://christinetsin.designbinder.com/ Christine Tsin])

With the rise of partification in synthetic biology, there needs to be a formal specification to describe standard biological parts, especially when designing complex devices. The specification needs to be both human-writable and human-readable, a language that raises the level of abstraction where bioengineers can work. Eugene is such a language. Engineering at the part level requires both flexibility and rigidity. Eugene allows the user to mix custom parts with predefined parts from established databases. Parts can encapsulate an arbitrary amount of information, anything from a DNA sequence to experimental history. When designing a device in Eugene, parts can be freely stitched together on a whim, or strictly joined together based on rules. The design process is meant to be systematic yet intuitive. The user considers what information parts include, constructs parts to be used in the design, enforces restrictions on how parts can interact, and creates devices that are composites of the parts or other devices. Being a textual design, a device specified in Eugene is portable and easily lends itself to being translated into other formats, such as XML. In synthetic biology, the notion of a part changes regularly and is debated tirelessly. Thus, Eugene tries to be adaptable and expressive in any climate. This page goes into the language specification in detail. We break the discussion up into four sections. We first discuss the language definition. Here we provide the basics of the language and how to construct a design using Eugene. Next we discuss some example designs created with Eugene. This is followed by a discussion on how the language is implemented and the data structures required. Finally we provide some sample results which illustrate the power of Eugene when applied to a number of published designs. Each section can be accessed with the buttons provided. Enjoy!





Language Definition

In this section we describe the elements in the language. These involve: primitive data types, properties, parts, devices, rules, conditional execution, and functions. The relationships between these language elements are shown in Figure 1. Here you can see that each subsequent category is built upon the previous category.


Figure 1: Relationship between Eugene Categories



Primitives
The language supports five predefined primitives. These are txt, num, boolean, txt[], and num[]. Strings (sequences of characters) are represented through the data type “txt”, where the actual text is specified in double quotes. Real numbers and integers are supported by the data type “num” and logical values by the data type “boolean”. Ordered lists of num and txt values can be created and individual members inside a list accessed by specifying an integer in the range from 0 to |List| - 1.

Examples (1) and (2) are two real code snippets of how primitives can be specified in Eugene. “listOfSequences” is simply a list of 3 arbitrary DNA sequences. “specificSequence” is the last element of “listOfSequences” (i.e. “ATCG”). Examples (3) and (4) show how the data type “num” can support integers and decimals.

ScreenshotPrimitives.png


Back Up

Properties
Properties represent characteristics of interest and are defined by primitives and associated with Parts. For example a user could define a property “Sequence” (the DNA sequence), ID (the uuid for a relational database which may hold the part), or Orientation (e.g. a forward or backward promoter). Examples 5-8 show how such properties would be defined. Property definitions must be defined by the five primitive types. In Part definitions properties will be bound to that Part as placeholders for the instantiation of values in Part declarations. Properties have to be defined before Parts can use them. The user can create new Property labels or use those created by other users and captured in header files. For example, the following Properties are predefined in the header file PropertyDefinition.h and do not need to be defined again if the header file is included in the main program:

ScreenshotProperties.png


Back Up

Parts
The data type Part represents a standard biological Part. A Part can be defined empty initially and then property labels can be added through the function addProperties() or properties can be bound to a Part during the definition.

Part Definition
Part definitions do not construct any Parts, but rather specify which Parts can be constructed. This can be done in the header file or in the main program. When the header file PartDefintion.h and PropertyDefintion.h are included, the following Parts and their corresponding property labels are predefined. For instance, the Part “Promoter” will have three properties associated with it and all instances of Promoter will inherit ID, Sequence and Orientation:

ScreenshotParts.png


If the properties are unknown during Part Definition process, the Part can be defined either empty or with the known properties. Later property labels can be added through the function addProperties() provided the property labels have been created beforehand. RBS will have four property labels after the following statement:

ScreenshotAddProperties.png



Part Declaration
Part declarations make instances of predefined Parts and assign values to their properties. If the declaration specifies a list of values, it is assumed that every property will be assigned a value, where the order of the values corresponds to the order of the properties in the Part Definition as shown in example (17). Otherwise, a “dot notation“ followed by the name of the property can be employed, where the order becomes irrelevant as specified in the example below (16). The Part instance BBa_K112234_rbs has three properties associated with the Part RBS. These are ID, Sequence and Orientation. The identification label of a particular part from a database is stored in the ID placeholder to allow future access to the database. Sequence stores the DNA of a Part, while Orientation specifies the direction of the Part. Since dot notation is used, the ID value instantiation can be left out from the statement. Part declarations can be found in the header file PartDeclarations.h and are predefined if the header files are included in the main program.

ScreenshotPartDeclaration.png


Back Up

Devices
Devices represent a composite of standard biological Parts and/or other Devices. In a Device declaration, the same Part and/or device can be used more than once. Property values of devices can be accessed with the dot operator; however, the value is the union of the property values of its members returned as a list. If the property is a txt or num, a txt[] or a num[] is returned. If the property is a txt[] or a num[], a txt[] or a num[] is also returned that consists of the lists appended together. For example the sequence of Device BBa_K112133 is the ordered union of the sequence of Part BBa_K112126 and the Device BBa_K112234. These two Devices are shown in Figures 2a and 2b, where the icon figures use true [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language Visual BioBrick Open Language symbols (vBOL)] icon graphic.

Table 1: Relationship between vBOL and Eugene

vBOL Description Eugene
Spectacles screenshot BBa K112133.jpg
Figure 2a: [http://partsregistry.org/Part:BBa_K112133 Device BBa_K112133], consisting of one
[http://partsregistry.org/Part:BBa_K112126 Part Promoter BBa_K112126] and one [http://partsregistry.org/Part:BBa_K112234 Device BBa_K112234]
Device BBa_K112133(BBa_K112126, BBa_K112234);
Spectacles screenshot BBa K112234.jpg
Figure 2b: [http://partsregistry.org/Part:BBa_K112234 Device BBa_K112234], consisting of one
Part Ribosome Binding Site and one Part Open Reading Frame
Device BBa_K112234(BBa_K112234_rbs, BBa_K112234_orf);

Individual Parts can be accessed through the use of square brackets and an index. The first member is indexed at zero. Square brackets can be stacked in the case of devices within devices. To access the first element BBa_K112234_rbs of Device BBa_K112234 through Device BBa_K112133, the following notation is supported:

ScreenshotAccessingDevice.png


Back Up

Rules
The specification of rules provides the ability to validate Device declarations. Rule declarations in themselves do not perform the validation. They have to be “noted”, “asserted” or used as expressions inside an if-statement to give meaning. Rule declarations are single statements consisting of a left and right operand and one rule operator. The rule operators BEFORE, AFTER, WITH, NOTWITH, NEXTTO, NOTCONTAINS, NOTMORETHAN can be applied to Part instances or Device instances. Property values of Part/Device instances or primitives in relation with one Part/Device can be operators in rule declarations when using the relational operators <, <=, >, >=, !=, ==. These operators are overloaded when evaluating text and the text is compared according to alphabetical meaning. Table 2 provides a summary of the operators for Eugene rules.

Table 2: Eugene Operators for Specifying Rules

Compositional Operators
BEFORE operand 1 appears before operand 2 on devices
AFTER operand 1 appears after operand 2 on devices
WITH operand 1 appears with operand 2 on devices
NOTWITH operand 1 does not appear with operand 2 on devices
NEXTTO operand 1 is adjacent to operand 2 on devices
NOTMORETHAN operand 1 (a part instance) occurs not more than operand 2 times in a device
NOTCONTAINS unary operator, where operand 2 is not contained in device
Comparison Operators
< less than for numbers, comes before alphabetically for text
<= less than or equal to for numbers, comes before alphabetically or is equal to for text
> greater than for numbers, comes after alphabetically for text
>= greater than or equal for numbers, comes after alphabetically or is equal to for text
!= not equal to
== equal to
Boolean Operators
AND operand 1 AND operand 2
OR operand 1 OR operand 2
NOT NOT operand


Table 3: Examples of Rule Declarations

Eugene Syntax Description
Rule r1(BBa_K112234_rbs BEFORE BBa_K11223_orf); Illustrates a rule where all Parts BBa_K112234_rbs have to come before all Parts BBa_K11223_orf
Rule r2(BBa_K112234_rbs WITH BBa_K112234_orf); Illustrates a rule where the Part BBa_K112234_rbs has to be contained together with BBa_K112234_orf inside a Device
Rule r3(BBa_K112126 NEXTTO BBa_K112234); Illustrates a rule where the Part BBa_K112126 has to be next to BBa_K112234 when a Device is declared
num x = 2;
Rule r4(BBa_K112234_rbs NOTMORETHAN x);
Illustrates a rule where the Part BBa_K112234_rbs cannot occur more than x (=2) times in a Devie
Rule r5(NOTCONTAINS BBa_B0032); Illustrates a rule where a Device cannot contain the Part BBa_B0032
Rule r6(BBa_K112234_rbs.Sequence != BBa_K112234_orf.Sequence); Illustrates a rule that checks whether the sequence of BBa_K112234_rbs is equivalent to the sequence of BBa_K112234_orf
Rule r7(BBa_K112234_rbs.RelativeStrength > BBa_B0032.RelativeStrength); Illustrates the comparison of Property values of Parts, where the “RelativeStrength” Property value for Part BBa_K112234_rbs has to be greater than the “RelativeStrength” Property value for Part BBa_B0032
num relativeS = BBa_B0032.RelativeStrength;
Rule r8(p.RelativeStrength > relativeS);
Shows a similar comparison but uses the variable “relativeS” for comparison


Back Up

Asserting and Noting Rules
In order to take effect, rules need to be “asserted” or “noted”, once they are declared. The scopes of all assert or note statements encompass every new Device. Every time a new Device is declared and provided “Assertions” and “Note” statements exist, the validation process is performed on the newly created Device. Rule instances can be combined with each other through the use of the logical operators AND, OR, NOT in the statements. The difference between rule assertions and rule notes lies in the strength of the consequence once a violation is found. If no violation is found the program continues running.

Rule Assertion
These statements are strong assertions and the program terminates with an error once a Device composition violates the statement. The following statement will check if BBa_K112234_rbs is not contained together with BBa_K112234_orf in the Device and their sequences should not be equal. In this case an error will terminate the program since both parts are components of the device, therefore violating the Assert statement.

ScreenshotAssert.png


Rule Notes
Notes issue warnings in the output when the violation occurs. But the program continues running. In the following example the Device BBa_K112133 meets the first note’s condition. However, the next note is violated and the program will issue a warning.

ScreenshotNote.png


Back Up

Conditional Statements
The use of conditional statements breaks up the flow of execution and allows certain blocks of code to be executed. Eugene supports two kinds of if-statements to achieve this: Rule validating if-statement and standard if-statement. The three logical operators AND, OR, NOT can combine statements of each type but not together.

Rule validating if-Statement
Rules can be checked not just through Assert and Note statements but also in an if-statement. In this approach only specific rules will be considered, as they might not apply to all Devices. The notation should specify a list of Devices and a logical combination of rule instances pertaining to that list. Suppose we would like to test a rule only on the specific Device instance BBa_K112133, where the Promoter BBa_K112126 comes before the Ribosome Binding Site BBa_K112234_rbs. Then the following conditional statement can achieve such conditional evaluation. In this case, the if statement will evaluate to true:

ScreenshotifRule.png


Standard if-Statement
Expressions not pertaining to rules and Devices can be evaluated by the standard if-statement which supports the relational operators <, <=, >, >=, !=, == as well as the logical operators AND, OR, NOT.

ScreenshotBooleanIf.png


Back Up

Functions
Functions are convenient actions users can invoke that are processed during runtime. The print function simply prints the argument to the console on a new line. The permute function automates the specification of many devices that share the same structure. It creates a device for every combination of predefined parts, maintaining the part type of each component in the argument device. If a component of the device is a device, even ones with only one part, it is not changed and appears in every permutation. Permutations are named <original device name>_<x> where <original device name> is the name of the argument device, and x is a number starting at 1. They can be accessed and manipulated like normally instantiated devices.

Back Up

Header Files
The inclusion of header files allows the use of predefined Properties, Parts and Part Instances in the program. The manageability of code in the main file is more efficient by hiding the low level implementation of sequence and Parts. The user needs only to define Devices in the main file. On such a level the program can be written quickly and it is less error prone. Also, this allows each lab to have their own header file libraries. At the same time the option to change or declare other Properties, Parts and Part instances exists in the language.

Back Up