User Stories

Parts Repository

1. The program must display a list of all available parts. The program requests a hierarchical list of all part names, part types, and their part ids from the Parts Repository (PR). Upon receiving the list, the program sorts the parts into different categories based on the part type, chooses a display icon for each type, and presents the list of part names with their part type icons to the user.
2. The user wishes to change the type of chassis. The program retrieves a list of all chassis names and chassis ids from the PR and presents it to the user.
3. The program must display a list of all types of parts. It requests a list of all part types and their part type ids from the PR. Then it displays the list of part names to the user.
4. The program must display all of the information about a single part. It gives the part id to the PR and receives a full description of the part in return. It then displays the part information to the user.
5. The program must save a CellML model of a part. It gives the part id to the PR and receives a segment of CellML in return. It then saves the CellML to file.

Constraints Repository

1. The program must show all possible interactions to a particular part. It passes the part id to the Constraints Repository and receives a list of all possible interaction ids in return. It then retrieves the details of each interaction with the interaction id. It then shows the possible interactions to the user.

Evolutionary Algorithm

1. The user finally wants to evolve her model in silico. The program collects the starting model, composed of a series of part ids, and the proposed behaviour in the form of a truth table, and gives it to the Evolutionary Algorithm (EA) for evolution. The program shows a “busy working” screen while the Evolutionary Algorithm computes the best model. When the EA finishes, the program receives the proposed best model(s) and displays them, along with their behaviour, to the user.

Outcome

DiS: The Ideal and the Reality

It is possible to paint a very rosy-tinted picture of how the user might interact with DiS. Bolded items have been implemented in the current incarnation of DiS.

1. The user fires up the workbench by double clicking an icon on the desktop etc.
2. A nice splash screen appears welcoming them to 'Darwin in Silico: Synthetic Biology Workbench'
3. The main application window appears. If this is the first time the program has run then a wizard may appear asking them to setup configuration details for the rest of the components of the system. If not, then it know where all of these are located by reference to its own internal persistence store of some kind.
4. The application consists of a working area where a genetic circuit can be specified and a pallete of 'parts' read from the parts repository. These parts have pretty 'BioBrick' type icons and can be expanded to give the actual instances of the various part types available in the database.
5. The user selects 'New Project' and has to define some initial starting information. They have to enter their name etc and some pre-saved details about them pop up. They modify some information about the in silico experiment purpose etc.
6. They are then taken to the blank working area where they can start to define details of the circuit to be evolved. See Figure A.
7. Somewhere is a menu relating to chassis details. They select Bacillus subtilis 168 from a drop down list or the like.
8. Immediately the parts list is constrained by the parts that are available for operation in B. subtilis 168.
9. The user begins to add the initial parts to the circuit to be evolved. They know that they want the circuit to essentially respond to the concentration of three (of course may be more or less than this) peptides that are signaling molecules from outside. She select free peptides from the palette at the side and drags them on to the canvas on eat a time where they appear; AIP (a Staph aureus virulence regulating peptide), CSP (a competence stimulating peptide from Streptococcus pneumoniae) and papR (a virulence controlling peptide from Bacillus anthracis, the causative agent of anthrax). See Figure B.
10. She defines these quantitative levels of these peptides as inputs to the system somehow.
11. She then selects coding regions from the palette, and navigates to Green Fluorescent protein (gfp) coding region and drags the rectangular icon on to the work area. She repeats this exercise for orange and red fluorescent (ofp and rfp) protein. They automatically appear with a RBS that is optimal for the chosen chassis. She leaves them promoterless for now.
12. She highlights the fluorescent protein coding regions and marks them as system outputs in terms of the absolute levels of the proteins they encode. See Figure C.
13. Next she specifies the functions that specify the behaviour of the outputs for a specified input concentration, again specified by a truth table. In this case she specifies a high initial concentration for AIP and a corresponding high output for gfp and ofp. She assigns zero production to CSP, PapR and rfp.
14. She repeats this exercise for a new set of states. This time she chooses a high initial concentration for PapR and a corresponding high production to rfp and ofp. She assigns a zero production for CSP, AIP and gfp.
15. The process of 13 and 14 is repeated until the desired system behaviour has been fully specified. See Figure D.
16. Next she chooses the chassis location for the fluorescent protein coding regions. She right clicks on them and chooses high copy number plasmid pBD9 (she could have chosen chromosome instead or a range of other vectors)
17. She is almost ready to invoke the evolutionary algorithm. However, she has the option to narrow down the range of parts available to the evolutionary algorithm. In this case she restricts it to all transcription factors and their modifiers and all promoters that operate in the chosen chassis. See Figure E.
18. She then clicks the 'evolve this' button. Behind the scenes, the model representing this initial set of parts, together with metadata and data about the input/output behaviour is sent to the EA component.
19. A dialog box showing the progress of the EA component pops up.
20. Once the EA has completed a window pops up showing the ID list of models that meet the fitness function specifications. The user can browse the selection graphically by selection of the relevant model. The graphical selection can be viewed as a conventional pictorial diagram of genetic regulation beloved of biologists or as a graph based view of the model. See Figure F.
21. The user is able to view the levels of the different species in the model over time or with varying concentrations of the input signals as line type graphs.
22. Ideally, she is able to pick one model tweak it and ask for it to be re-evolved.
23. Finally once happy with the model, she clicks on 'model to sequence converter' and the chosen model is sent to the model to sequence converter. A GFF or EMBL formatted record is returned, for each of the genetic elements that require to be synthesised.

Figure E:In the Evolve tab, the user selects where the circuit should be placed - in a specified vector, or in the chromosome, for example. Then she chooses the parts that should be evolved, and clicks the 'Evolve!' button.

Figure F: Someday, when DiS is hooked up to the EA, the Results tab will be populated with a series of potential models that the user can save, edit and re-evolve, or export for synthesis and in vitro biological experiments.

Further Reading

Contributors