18.3 Fit


Before the (building) architect Christopher Alexander influenced the software community with his book A Pattern Language[1], he also influenced thinking on requirements with an earlier book, Notes on the Synthesis of Form[2]. In this book, Alexander described design problems thus:

[E]very design problem begins with an effort to achieve fitness between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem. In other words, when we speak of design, the real object of discussion is not the form alone, but the ensemble comprising the form and its context. Good fit is a desired property of this ensemble, which relates to some particular division of the ensemble into form and context.

For the (software) architect, the "context" is certain critical properties of the system as a whole that determine the structure of the "form," the generated code for the system.

One approach is to proceed from the outside in, by examining the context: the manner in which the system's environment impinges on the system. A complementary approach is to proceed from the inside out, by understanding the form: the various dimensions of a software platform, such as data-access schemes, persistence, concurrency, and distribution.

A telephone switching system, for example, is highly asynchronous and concurrent: Each call is made independently of others; calls take place concurrently with no interference except for contention for resources; and access to long-term persistent storage, for the routing of the calls, is random. These are critical properties of the environment, and they can be established without reference to the specific semantics of the application.

The implementation must necessarily be distributed. A concurrent implementation, appropriately allocated, would minimize unnecessary coupling between calls. Some log(n) algorithm for data access would equalize data-access times, and so on. A model compiler that optimized for these properties would be ideal.

As another example, consider another highly asynchronous and concurrent application, telephone billing. This application has the additional property that no transaction can be lost: Once a transaction begins, it must complete successfully or roll back any intermediate stored data and try again.

A model compiler that included automatic transaction-safety and rollback would be ideal for this system's characteristics.

Now consider a pacemaker. This application has a loosely periodic nature that can be expressed asynchronously using timed signals to assume the responsibility for detecting the nonoccurrence of certain periodic events, such as a heartbeat. There is no need for concurrency, nor a distributed network of computers. Rather, the goal is to minimize the computing hardware required so it can be implanted in the body.

A model compiler that optimized memory usage and executed on a single chip without concurrency would be ideal for this situation.

The Executable UML models for the telephone switching system could be compiled using the model compiler optimized for transaction safety, but the implementation would be unnecessarily inefficient. Similarly, the telephone billing system could be compiled using the single-tasking model compiler, but this solution would not provide sufficient concurrency.

The goal is to select a model compiler (the form) that fits the way in which the environment impinges on the system (the context).



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net