[BBF Standards] Two separate standards

[Ralph Santos]

Drew,

It occurs to me that one could borrow a concept from software 
engineering to make something that could be extremely useful for the 
working group.

If what you describe here were developed into a set of use cases to be 
used as reference material by the working group I think it might become 
a valuable tool.

For those who are not familiar concept, the Wikipedia page is a good 
starting point:

  http://en.wikipedia.org/wiki/Use_case

Others might have better suggestions for those interested in more 
information about use cases.

Basically, a use case is a sort of brief or write-up describing how a 
particular kind of user will use a piece of software to accomplish a 
particular task, and they are written using language and terms set by 
the user and specifically exclude details specific to particular 
implementations like user interface details.  Traditionally they are 
used by software engineers to capture the scope and functional 
requirements of a system, and I believe the working group could also use 
them here.

Your message describes something extremely important--critical, 
even--for the working group to consider which to this point I don't 
think the working group has had a chance to properly address yet, which 
is to work on defining architectural requirements to help us articulate 
what we need out of a particular system.

To elaborate on what I mean here, check out the data exchange standards 
wiki page.  There's a discussion of modeling biobricks, and then there's 
some proposed architectures.  Current discussions have given us lots to 
think about as regards how to codify our descriptions of biobricks, and 
this is all to the good, I do not wish to criticize any of that.  
However, when we are approached with a particular technical 
architecture, like those which have been posted on the wiki page, we've 
hardly begun to think about how we articulate what we need out of a 
software system to do what we want to accomplish, or how to evaluate 
what a particular technology can offer.  This is not a criticism, this 
is merely an observation.

What I believe has started us in this direction is the application 
scenarios.  This is all to the good, and it has helped us in that we've 
seen how these scenarios have come up in the course of discussions.  
However, Drew, I think your message highlights something critical we 
should add to the application scenarios, which is how these scenarios 
apply to different engineers in different roles.  Some of these 
scenarios may apply to everyone equally, and some may not, and some may 
change depending upon what type of engineer is doing the same task.  
Another important aspect is that the separations you describe--the 
limits and structures on communications--will ultimately translate into 
system architecture requirements.  Different kinds of engineers will 
need to work through a system to interact with each other, and that 
system must support certain divisions of work and to do that it has to 
do certain things. Any data exchange standard has to address what we 
need out of any such process.

Of course all of that is a big job, but your message provides an 
excellent starting point on a particular critical piece:  I think that 
if we developed general profiles of what each kind of engineer should 
know and do during the course of their work, and how they'll communicate 
with one another, all of that is critical information to help us 
translate what we want out of the biology into requirements for a system 
to achieve and criteria for evaluating technical solutions brought 
before us.

I'd like to see the application scenarios on the wiki page expanded into 
a collection of scenarios describing representative exchanges between 
the different engineers you describe in your message to build a 
biological system.  The important part is representative.  It need not 
be comprehensive, as we should count on adding to this group of 
scenarios over time.  But within them we should see descriptions of how 
these engineers work together to get the job done.

Put another way, you should consider writing the script for another 
comic book, but with a different cast of characters to exemplify the 
roles you describe.  In the comic book I see three characters suggestive 
of the roles you describe but not clearly.  The young budding engineer 
seems to be mostly system designer.  The white-coated woman who acts as 
a sort of guide or mentor may or may not be a part and/or device 
designer, but we don't see anything of how she does what she does.  The 
third character is of course, our little green buddy who plays the 
unfortunate role of chassis, but that's neither here nor there.  :-)

Of course, the purpose isn't really to write something for general 
consumption, but to write something for the working group, so this 
"comic script" would be structured by the need to articulate a set of 
transaction scenarios, not to tell an engaging story.  Also, the 
ultimate form of the product would not be a narrative and dialogue, but 
a set of use cases.

What do you think of such an idea?

---ralf


Drew Endy wrote:
> Exactly correct.
>
> DNA engineers will be concerned with how to construct DNA.
>
> Parts engineers will be concerned with how to build parts at the  
> primary nucleic and amino acid sequence level (and whatever else  
> synthetic biological parts get made from).
>
> Device engineers will be concerned with how parts are best organized  
> to make devices.
>
> System engineers will be concerned with how devices are best organized  
> to make systems.
>
> Each type of engineer needs to be able to communicate at least one  
> level "down" and "up" in this abstraction hierarchy.  Such  
> communication should be limited and well structured.
>
> Meanwhile, I don't mean to add fuel to any "larger than life T7  
> autogene fires," but check out the last 6 pages from the synthetic  
> biology comic book, if you've not seen it before.
>
> http://www.nature.com/nature/comics/syntheticbiologycomic/index.html
>
> Pages 7-8 detail making a device from parts.
>
> Pages 9-12 detail some issues of common signal carriers for  
> transcription based devices.
>
> Cheers!
> D.
>
>
>
>
> On Mar 15, 2008, at 2:11 PM, Herbert Sauro wrote:
>
>   
>> I think Deepak has made a useful observation. At one level an engineer
>> won't care about the DNA sequence, of more interest is the functional
>> properties of the boxes he/she is putting together. On the other hand,
>> the designer of functional boxes will be concerned with the DNA  
>> sequence
>> since in designing for example a promoter or gene with a specific
>> property the DNA sequence is clearly paramount. It looks like there  
>> may
>> be a natural separation here.
>>
>> Herbert Sauro
>>
>>
>> _______________________________________________
>> Standards mailing list
>> Standards at biobricks.org
>> http://biobricks.org/mailman/listinfo/standards_biobricks.org
>>     
>
>
> _______________________________________________
> Standards mailing list
> Standards at biobricks.org
> http://biobricks.org/mailman/listinfo/standards_biobricks.org
>