Figure 1.
A schematic of RosettaScript operations.
(A) When parsing an XML protocol, a series of objects are instantiated. The DataMap is used to store some of these elements as they are parsed, and to store any additional objects that the elements define (e.g., constraints from text files). Movers and Filters can access and modify the elements stored in the DataMap. After parsing completes, the DataMap is deallocated, though the objects it once held may persist in memory. (B) Starting from a structure read in from disk, protocol execution consists of a series of Mover and Filter applications. A structure can either pass or fail a Filter: failure causes execution to return to the beginning, whereas success causes execution to proceed. At the end of execution a protein model and its score are written to file. Though the DataMap does not persist beyond the parsing of the XML file, any of its former elements that are pointed to by Movers and Filters remain in memory, thus allowing communication between Movers and Filters during execution.
Figure 2.
Unified-Modeling Language (UML) class diagram of Rosetta's factory scheme.
The creation of Movers, Filters, and TaskOperations is controlled by similar factory setups. Pictured here are the classes responsible for the instantiation of generic “Widget” classes. The singleton WidgetFactory maintains a map from strings to WidgetCreators. Each WidgetCreator is responsible for instantiating a particular Widget; e.g., the derived WidgetCreator class, DerivedWidgetCreator, is responsible for instantiating the derived Widget, DerivedWidget. The factory registration system allows new Movers, Filters, and TaskOperations (and their corresponding MoverCreators, FilterCreators, and TaskOperationCreators) to be defined outside of the Rosetta3 libraries and yet to be included in the RosettaScripts framework without requiring the addition of any new dependencies to the Rosetta3 libraries.