This paper is interesting because it identifies a mature system of reuse (chemical enginerring) and compares it with an immature one (software engineering).

One observation sticks out and that is the use of ontologies. The author points out that the ontologies in chemical engineering are much more standardized and documented than in software engineering. The reason for this is that ontologies in software engineering only cover a few components

The author notes that chemical engineering has a "bible" type handbook where all information is collected through a process of standardization and construction of shared ontologies. Perhaps this concept could be applied to technical aspects of live performance making. I

With the agreement of shared ontologies, established, architectures for solving particular problems become possible. These share architectures become the bag of tricks for everyone to draw upon.

Problem with software engineering is that there are too many different types of support structures as opposed to chemical engineering (a boiler is a boiler and is a replaceable structure given the predecessor's parameters. Black boxes are more swappable because they truly don't depend upon the underling construction. For instance a process written in max and one in c++ and one in java are harder to integrate because of a lack of coordination between the languages.

Perhaps this educates a way to think about the environment that houses the black box components. It needs to be transparent to the underling construction of the box. A box can be written in any language and still function!

This is accomplished somewhat in max, but perhaps the problem is building up intermediate shareable units based upon the smaller units. Max patches are so complexly interconnected that perhaps this works against the reuse of architectures. Perhaps there is a way to foster this reuse through the interface itself?

The idea of sub-patches and embedded patches do this to some extent, but my experience with them is that there is still a missing something here. Perhaps, functions are two specific to a particular application, or there is simply not a quick way to share constructed modules?

Conclusions

• Design reuse in software engineering is progressing toward the types of

design reuse found in chemical engineering (e.g. CMU, OO frameworks,

OO design patterns, DSSA program). The efforts have to be coalesced

and the gaps have to be filled.

• We need to start developing a “Perry’s Handbook” for software engineering.

• We need to start developing a book of published architectures for software

engineering.

• We need to examine the business aspects of design reuse.

• We need architecture based cost estimation tools.