UMLoquent expression of AWACS software design

views with their associated artifacts, but also as a means to validate the software architecture for fidelity and completeness. The diagram in Figure 4b is representative of NMT’s use case diagram usage and models a portion of its surveillance design. Using the UML to Express a Contract Across Systems Three geographically dispersed companies are responsible for developing the NMT software. One develops the user interface, another develops the tracking software, while Boeing is the primary contractor developing the remaining functionality in addition to being responsible for software integration. A CORBA solution has been chosen to glue the various systems together in the most seamless and extensible manner possible. The contract defining the interfaces between these external systems is expressed using the Interface Definition Language (IDL) and is generated by forward engineering UML artifacts from the logical view. The stubs and skeletons produced by preprocessing the forward-engineered IDL are used in support of one of NMT’s most important design patterns, the Embassy pattern. The Embassy pattern is a hybrid of the Observer, Bridge, and Remote Proxy patterns [3] and has several important architectural objectives discussed here. The classes contributing to the Embassy pattern are captured in Figure 5. The Embassy pattern is a metaphor for the notion of an embassy being used to represent another country’s interests in a foreign land. Modeling the real world, NMT’s embassy abstraction represents the interests of an external system within the confines of a foreign computer. The Embassy pattern uses the Bridge pattern to decouple external systems from the implementation of NMT’s domain classes as well a Remote Proxy pattern to represent the interests of objects residing in different address spaces. The embassy abstraction is supported by two classes: the attaché and the correspondence. An embassy is composed of any number of attachés, each of which has a unique interest in the problem domain. An attaché is an observer of specific domain objects in which it has particular interest and embodies the rules of when and what is sent to the external system it represents in response to changes in those domain objects. The attaché also acts in the capacity of a bridge by transforming the desires of the external system it represents into actions upon NMT domain objects. The correspondence class plays an important role in NMT’s objectives of abstracting the fact that an ORB is being used to support its middleware needs. A correspondence object not only embodies the message content that is sent to or received from external systems but it also encapsulates the means by which the message is actually sent. Difficulties Expressing the NMT Design While the UML is strong in expressing the logical view of the NMT architecture, we have found it to be less powerful in its ability to describe our process and deployment views. Accurately capturing the alloCOMMUNICATIONS OF THE ACM October 1999/Vol. 42, No. 10 59 Figure 4a. Domain level usage of class diagram.