(Slide 26)

One of the primary goals of chain models formalism is to provide a language for formally specifying the meaning of physical systems (such as engineering artifacts and other products). The formal specification makes it possible to automate many of the time consuming tasks that are currently done manually. Without a formal specification, it is virtually impossible to automate these tasks. Drawing again on the analogy with electrical circuits, we can see four related tasks that are supported by chain models. The first is specification. Just as a circuit may be described by its input/output characteristics, so a chain model can be used to define the desired behavior of a physical object. The problem of synthesis is to create a physical object that has the characteristics specified by some specification. Because chain models are expressed in terms of primitive components of various kinds together with rules for assembling them, it is possible to synthesize an physical object analogously. Once one has constructed a chain model of a physical object, the model can be used to analyze and simulate the behavior of the object. This has well recognized cost and time advantages. And finally, the analysis can be used to verify that a given artifact satisfies a specification. Thus we can image a scenario where a company requires a subassembly that they must subcontract out. Using the language of chains, the express the desired behavior of the subassembly. An important aspect of this specification is that they are required only to specify the minimum amount of information to subcontractors. (For instance, in general the I/O characteristics of a circuit tell you neither how to build the circuit (protection for the subcontractor) or what it is for (protection for the contractor). This will become increasingly important as the internet is used to communicate engineering information between competitors, and security becomes paramount -- not just in the sense of protecting against the theft of information, but also in minimizing the extraneous content in legitimately obtained information. Following the scenario, the subcontractor may design their proposed component, perhaps using a chain model based software methodology for representing physical objects. When they believe that they have a viable design, they contact the contractor, and make computer access to their model available. The contractor performs various tests, and is either satisfied, requires changes, or renegotiates the contract to satisfy their actual requirements. When and if the negotiations reach that stage, the subcontractor builds an actual physical model, and tests it against the specification to verify it. Similarly, the contractor may perform the same tests, against the same chain model specification. Perhaps the subcontractor finds, upon building the subassembly, that it does not satisfy the specification. In that case, he might choose more conservative models (i.e., overengineering) for the future. As time progresses, both the models and the artifacts they represent become better, as engineering knowledge and experience is captured and represented within the computer system.