Analysis and Design with the Universal Design Pattern by Koni Buhrer Software Engineering Specialist Rational Software Developing large software systems is notoriously difficult and unpredictable. Software projects are often canceled, finish late and over budget, or yield low-quality results -- setting software development apart from established engineering disciplines. As others have observed, the key to successful software development is a good, resilient architecture. The Universal Design Pattern (which I discussed in the December 2000, January 2001, and February 2001 issues of The Rational Edge) is a set of design rules that can help software developers create quality architectures in a systematic fashion. In this fourth article, I will outline how the rules of the Universal Design Pattern should be applied for software analysis and design. The Universal Design Pattern fits very nicely into the framework of the Rational Unified Process (RUP ): A software architect can easily apply the Universal Design Pattern when deriving the initial architectural design of a software system from a use-case model. Let me start by summarizing the key features of the Universal Design Pattern, a design method based on an abstract set of design elements and narrative rules. The Universal Design Pattern is truly universal because it applies to software of all application domains. Software developers can use the Universal Design Pattern no matter what design language, modeling tools, or programming languages they employ. The Universal Design Pattern features four types of design elements: Data Entities, I/O Servers, Transformation Servers, and Data Flow Managers. Each type of design element is concerned with exactly one specific aspect of system operation:
Data entities represent the input data, output data, and internal persistent data of the software system. Data entities are solely concerned with data structures and primitive operations on those data structures. A data entity is an entirely passive object -- pure data -- oblivious to system algorithms, external interfaces, or sequence of actions. I/O servers encapsulate the external (hardware) interfaces and internal databases the software system interacts with. I/O servers are solely concerned with input/output and servicing external (hardware) interfaces. An I/O server may be concerned with I/O timing, but not with scheduling or triggering other system actions. I/O servers do not perform any algorithmic tasks with respect to the input or output data they handle. Transformation servers perform the transformation from input data to output data -- possibly updating internal state data. Transformation servers are solely concerned with system algorithms. A transformation server never has to worry about where data is coming from or where it is going. All operations of a transformation server are sequential and deterministic. Transformation servers are not concerned with data representation, external interfaces, or sequence of actions. Data flow managers obtain input data from the I/O servers, invoke the transformation servers (which transform input data into output data), and deliver output data to the I/O servers. Data flow managers are concerned solely with data flow and sequence of actions. Data flow managers know what actions the system needs to perform and in what sequence, but they are not concerned with the details of those actions: the algorithms and external (hardware) interfaces. While data flow managers own the internal state data, they are not concerned with its representation. See Figure 1 for an example of a very simple architectural design.
Figure 1: A Simple Architectural Design Translating Use-Case Models Use-case modeling is one of the most compelling and successful techniques for finding and capturing functional software requirements. The requirements workflow of the Rational Unified Process describes the usecase modeling technique at length. As a brief summary, we can say that use cases specify the externally visible behavior of a software system: how a system interacts with external entities (called actors). Figure 2 is an example of a simple use case as it might appear in a use-case model.
Figure 2: A Simple Use Case A use case is realized by three kinds of analysis classes: boundary classes, control classes, and entity classes. The Analysis & Design Workflow of the Rational Unified Process explains at length how to find analysis classes. We can summarize by saying that actor/system interactions give rise to boundary classes, the use-case behavior gives rise to a control class, and stored information gives rise to entity classes. The use case depicted in Figure 2, for example, might be realized by boundary classes, control classes, and entity classes, as shown in Figure 3. Figure 3: A Simple Analysis Class Diagram As we will see below, there is a simple correspondence between the analysis classes/objects and the modeling elements of the Universal Design Pattern. A software architect can therefore easily refine the analysis model and create an architectural design model according to the rules of the Universal Design Pattern. Of course, requirements analysis with use cases is not a prerequisite for applying the Universal Design Pattern. There are many ways a software developer can discover data entities, I/O servers, transformation servers, and data flow managers when studying the software requirements. Often, considering external interfaces and the data transformations that are needed to produce output data from the input data will lead a developer to create a reasonable architectural design that obeys the rules of the Universal Design Pattern. Boundary Classes A boundary class embodies several aspects of the interface with which it is associated, including the physical I/O device, the available input and output operations, the data the system produces or retrieves for processing, and the layout of the information presented to, or requested from, the actor. The Universal Design Pattern requires that an architect
separate these aspects in the design model. Each boundary class translates to a set of design elements: An I/O Server. The I/O server encapsulates the driver that controls the interface hardware. Often the driver does not interact with the hardware directly (though it can), but with lower level I/O servers or operating system drivers. The I/O server also provides the abstract input and output operations other design elements of the system use. Finally, the I/O server encapsulates the layout of the external interface and its components. Many input data entities and output data entities. The data entities embody the logical structure and operations of the data objects other design elements exchange with the I/O server. The input and output data entities are the parameters of the input and output operations of the I/O server. Note that the structure of the input and output data entities is independent of the layout of the external interface. Upon refining the design of the I/O server, a software developer will often discover other data entities and subordinate I/O servers that are needed for its implementation. Also, a single I/O server often implements many or all boundary classes that are associated with the same external interface. See Figure 4 for an example of a design model with an I/O server derived from the RadarReceiverInterface and the RadarTransmitterInterface boundary classes. Figure 4: Refined Class Diagram of RadarReceiverInterface Control Classes A control class represents the behavior of a use case, the sequence of events the software system responds to, and the sequence of actions the system performs while the use case is executed. If there are several use cases that describe communication with the same actor or through the
same external interface, then the control classes of all these use cases can often be translated into a single modeling element: A Data Flow Manager. Note, however, that a data flow manager never responds to an event; a data flow manager always acts. The flow of events of a use case is usually described in reactive terms. The software developer has to translate that description into a sequence of pure actions performed by the data flow manager. Consider, for example, the following use-case outline, which is realized by the RadarLoopControl class: The UpdateTrackerPosition use case is executed every 20 milliseconds. 1. The use case starts when the radar receiver sends a telegram with target position data to the system. 2. The system retrieves the filter state and computes the new tracker position. The system then updates the filter state. 3. The system sends the new tracker position to the tracker motor. In skeletal Ada, the corresponding data flow manager would look like this: TASK Tracking_Loop_Manager IS State : Filter_State; BEGIN LOOP Radar_Io_Server.wait_for_20ms_telegram(20ms_telegram); Filter.compute_new_position (State, 20ms_telegram, new_tracker_position); Tracker_Io_Server.set_position(new_tracker_position); END LOOP; END; Note how the data flow manager is actively waiting for and retrieving the input data provided by the I/O server (the Radar_Io_Server in this example). The I/O server does not invoke the data flow manager or send data to the data flow manager. Entity Classes Entity classes represent data the system stores across several executions of a use case. An entity class embodies several aspects of the data, namely its structure, its operations, and the means by which it is stored persistently in the system. The Universal Design Pattern requires that an architect separate these aspects in the design model. Furthermore, an entity class can translate to different sets of modeling elements, depending on the significance of the data the entity class represents. We
mainly have to consider two cases: 1) If the entity class represents persistent data the system stores in an internal database, then the entity class translates to two modeling elements: A persistent data entity. The persistent data entity embodies the logical structure of the stored data objects. A persistent data entity typically has few operations. In particular, it should not have any operations that pertain to the means by which it is stored. A database I/O server. This I/O server embodies the database object that stores the data objects. The operations of the database I/O server are typically of the get and put type and take an in or out parameter of the persistent data entity above. The database I/O server encapsulates any internal structures (e.g., index tables) and functionality needed to store the data objects in the database. See Figure 5 for an example of a design model with a database I/O server and a persistent data entity derived from the TacticalData entity class. Figure 5: Refined Class Diagram of TacticalData If the tactical data resides on some kind of external medium, then it obviously has to be represented by a database I/O server, because it is accessed through an external (hardware) interface. But even if the tactical data is kept in memory, it must be represented by a database I/O server to separate the data structure aspects from the storage/retrieval aspects. 2) If the entity class represents internal state data associated with a system algorithm, then the entity class translates into a Transformation Server. The transformation server embodies both the logical structure of the state data and the algorithm. The transformation server has a compute type operation that takes an input data entity and an output data entity as parameters. Note that in non-object-oriented programming languages, the internal state data object would also be a parameter that is passed in and out.
See Figure 6 for an example of a design model with a transformation server derived from the FilterState entity class. Figure 6: Refined Class Diagram of FilterState An internal state data object is always owned by a single data flow manager. Although different data flow managers may use the same transformation server (which is a class), they maintain independent state data objects (which are instances of the transformation server class). The Four Realms of Software The Universal Design Pattern divides a system's software into four separate realms at the highest level of design: The realm of data entities (representing the problem domain) The realm of transformation servers (representing the domaindependent solution space) The realm of I/O servers (representing the target environment) The realm of data flow managers (representing the targetdependent solution space) These four realms are quite distinct from one another, and the classes/objects of each realm are likely to be modeled and implemented in different ways. Note that data entities and transformation servers usually constitute the bulk of a software system. The Realm of Data Entities The realm of data entities represents the problem domain. Most objects or concepts within the problem space are represented by data entities. Data entities are largely oblivious to the target environment of the software system. Together with transformation servers, data entities model the problem domain reality.
Each data entity is a class of a data objects, and its primitive operations are class operations. Data entities are often related to other data entities; for example: Data entities can be composed of other, more fundamental data entities. Data entities can be derived from more fundamental ancestor data entities. Primitive operations can be inherited from ancestor data entities. Data entities represent all the input data, output data, and persistent data a software system handles. Any number of data objects (instances of data entities) may exist in a software system at any given time. Data objects come and go; they are created and destroyed continually as the software executes. Data entities are entirely passive. Although other types of design elements pass them around and invoke their operations, they cannot truly interact with data entities. Data entities are best modeled with an object-oriented design language like the Unified Modeling Language (UML). UML is very powerful and provides a broad range of features, however, and many of those features are unsuitable for data entity design. A software developer should observe the following restrictions: Message sequence diagrams, object interaction diagrams, and state machines have no place in data entity design. Remember, data entities are entirely passive; they do not exchange messages and do not have state (in fact, they are state). Primitive operations must not invoke global methods or otherwise interact with global objects. A primitive operation of a data entity may invoke other operations of that data entity, operations of its component data entities, or operations of its parameters, but nothing else. In particular, a primitive operation must not invoke operations of any I/O servers or transformation servers. Data entities (the classes) must not have global, static state. The detailed structure of a data entity or its primitive operations need not be exposed in the top-level design of a software system. The top-level data entities usually correspond to the input data and output data of the software system, as well as persistent data identified during requirements modeling. A software developer always introduces new data entities while refining the top-level data entities and breaking them into smaller objects. Data entities can only be composed of other data entities, though. No I/O servers, transformation servers, or data flow managers ever emerge during the detailed design of a data entity. Note that it is a mistake to start data entity design by identifying domain concepts. Data entities representing domain concepts will emerge eventually, as the design model is refined, but they should never be the starting point of architectural design.
The Realm of Transformation Servers The realm of transformation servers represents the domain-dependent solution space. Each transformation server represents a domain-specific algorithm pertinent to the problem a software system solves. Transformation servers are oblivious to the target environment. Together with the data entities, they model the problem domain reality. Each transformation server implements an algorithm (sometimes several algorithms) that is sequential and deterministic. A transformation server is thus simply modeled as a class with operations implementing the algorithm. All the usual elements of procedural languages and structured design languages can be used to implement transformation server operations: loops, conditional statements, subroutines, parameters, recursion, etc. You might think that transformation servers would functionally decompose a software system, but that is not the case. A transformation server is usually associated with a transformation state. The transformation state is internal data a transformation operation uses and updates whenever it is invoked. And the transformation state is the class with which a transformation operation is associated. For example, in C++: class Filter { public: void compute_next_position (20msTelegram &input, TrackerPosition &output); private: FilterState state; }; In the procedural programming language C we would specify the transformation server class as follows: struct FilterState { }; void compute_next_position (FilterState *pstate, 20msTelegram *pinput, TrackerPosition *poutput);
Note that both code snippets specify a class! In the C example, the FilterState object is explicitly passed as an in-out parameter when the transformation server operation is invoked. In the C++ example, the FilterState object is passed implicitly as the object to which the compute_next_position operation belongs. The following guidelines apply to transformation server design and implementation: A transformation server (the class) must not have any global, static state. All data objects a transformation server uses must be passed as parameters to its transformation operation -- either explicitly or implicitly. The algorithm implemented by a transformation server must depend only on its parameters. A transformation server may invoke the operations of other transformation servers or primitive operations of its parameters. But a transformation server must not invoke I/O server operations. The restrictions above ensure that all transformation server operations are reentrant. Any object-oriented or structured design language is adequate to model transformation servers. After all, a transformation server is nothing more than an algorithm; therefore, any design language able to describe algorithms will do. The detailed structure of a transformation server does not need to be exposed in the top-level design. The algorithm of a transformation server can often be broken into discrete steps. Each of these steps can itself be represented as a subordinate transformation server. Some of the steps may already be implemented by an unrelated transformation server, and can be invoked. As the software developer refines the design of a transformation server, he will normally introduce new transformation servers and new data entities. The data entities emerge as a by-product, representing parameters the transformation server passes to subordinate transformation servers. I/O servers and data flow managers never emerge during the detailed design of a transformation server. It's important to note that transformation servers and data entities are conceptually very different design elements. Although they are both modeled and implemented as classes, they have different responsibilities within a software system. Data entities model domain objects and concepts; transformation servers model algorithms pertinent to the software solution. The Realm of I/O Servers The realm of I/O servers represents the target environment. Each I/O server encapsulates an external (hardware) interface or internal database
with which the software system interacts. I/O servers are concerned only with the target environment of the software system, not with problem domain objects or concepts. Together with the data flow managers, the I/O servers model the target environment reality. I/O servers are best characterized as passive-reactive. They are passive until they either receive an external signal or a client invokes an input/output operation. Once activated, however, an I/O server autonomously performs all the necessary steps to either serve the external (hardware) interface it encapsulates or to satisfy the client request. Note that the only clients of an I/O server are data flow managers. An I/O server can be fairly complex and expensive to implement, depending on the nature of the external interface it encapsulates. Imagine, for example, an I/O server representing a CORBA interface or implementing a TCP/IP stack. However, the complexity of an I/O server should be related solely to the input/output operations it performs and the external (hardware) interface it services. I/O servers should not be concerned with any computations related to the data they receive, transmit, or store. The following guidelines apply to I/O server design and implementation: An I/O server may invoke the operations of another I/O server but not of a transformation server. An I/O server should use operations of input or output data entities only to create or destroy them. To access the external interface, an I/O server should use its own thread of control. When a client delivers output data to an I/O server, the data should always be copied into a local buffer. When a client obtains input data from an I/O server, the data should always be copied out of a local buffer. An I/O server can be modeled as a class, although I/O servers are usually solitary objects. The input and output operations an I/O server provides often depend only on the target environment, not on the problem domain. I/O servers typically have get, put, and wait type operations. Here is an example in Ada:
PACKAGE Radar_Io_Server IS PROCEDURE wait_for_20ms_telegram (output : OUT Telegram20ms); PROCEDURE put_control_telegram (input : IN ControlTelegram); END; No design language is entirely adequate for modeling an I/O server. Skeletal, high-level language code is therefore often the best choice. The capsules of UML/RT capture the passive-reactive nature of I/O servers very well. However, capsule-interaction by signals and messages is inadequate to describe some of the interactions between I/O servers and data flow managers -- especially waiting for input data. The detailed structure of an I/O server does not need to be exposed in the top-level design. Higher-level I/O servers often rely on subordinate, lowerlevel I/O servers to perform the required input/output operations. Sometimes a lower-level external interface is already encapsulated by an I/O server, and a higher-level I/O server can invoke operations of the latter. As the software developer refines the design of an I/O server, he will normally introduce new I/O servers and new data entities. Data entities emerge as a by-product, representing parameters the I/O server passes to subordinate I/O servers. Transformation servers and data flow managers never emerge during the detailed design of an I/O server. The Realm of Data Flow Managers The realm of data flow managers represents the target-dependent solution space. Each data flow manager represents a sequence of actions the system performs. Data flow managers are largely oblivious to the problem domain -- domain concepts and domain-specific algorithms. Together with the I/O servers the data flow managers model the target environment reality. The data flow managers are the active elements of a system. Each data flow manager implements an independent thread of control. In a system that is implemented in Ada, the data flow managers would most likely be Ada tasks. Data flow managers are the means by which a software developer implements concurrency within a software system. All data flow managers of a software system perform their actions concurrently. The following guidelines apply to data flow manager design and implementation: A data flow managers always acts on I/O servers and transformation servers; it never reacts. Data flow managers have no interface. It is therefore not possible
for other design elements to invoke a data flow manager or to send messages to a data flow manager. A data flow manager performs its actions as quickly as possible; data flow managers are not controlled by a clock. When a data flow manager retrieves input data from an I/O server, it may have to wait for the input data to become available. But because waiting for input is considered to be an action, a data flow manager still performs its actions as quickly as possible. Data flow managers may explicitly synchronize with each other, though explicit synchronization should be avoided if at all possible. Explicit synchronization is considered to be an action. A data flow manager does not have to perform all its actions sequentially. It can perform some actions conditionally or repeatedly. A data flow manager should never be concerned with the details of the actions it performs. A data flow manager knows what the software does and in what sequence, but not how it is being done. The actions of a data flow manager must be simple, such as invoking operations of an I/O server or a transformation server. Algorithms or input/output details should be implemented not in the data flow manager itself but in the operation it invokes. A data flow manager may temporarily store data entities. It must not, however, use any of the operations of those data entities. In skeletal Ada, for example, a data flow manager might look like this: TASK Tracking_Loop_Manager IS State : Filter_State; BEGIN LOOP Radar_Io_Server.wait_for_20ms_telegram(20ms_telegram); IF Filter.is_new_asm(State, 20ms_telegram) THEN Filter.start_asm_tracking(State); Console_Io_Server.sound_asm_alarm; END IF; Filter.compute_new_position (State, 20ms_telegram, new_tracker_position); Tracker_Io_Server.set_position(new_tracker_position); END LOOP; END; Data flow managers can be modeled with a variety of modeling languages,
although -- just as for modeling I/O servers -- none is entirely adequate. A software developer can easily use UML's activity state diagrams or skeletal high-level language code to describe the sequence of actions a data flow manager performs. Note that a UML/RT capsule cannot represent a data flow manager because data flow managers are active, and not reactive, design elements. All data flow managers of a software system must be present in the toplevel design. A data flow manager is not composed of any subordinate objects and cannot be broken into subordinate design elements, other than the actions it performs. As far as data flow managers are concerned, the design of a software system is flat. This forces a software architect to provide a detailed model of the operationally complicated interactions within a software system -- interactions between the data flow managers and other design elements -- at the highest level of design. The operationally simple bulk of the software system however -- I/O servers, transformation servers, and data entities -- does not need to be detailed at a high level. Although I/O servers may interact with other I/O servers and transformation servers may interact with other transformation servers, these interactions are simple because they are sequential and hierarchical. Model Each Realm Separately As we have seen, it is quite easy to obtain initial design elements from the use-case model of a software system. Each design element belongs to one, and only one, realm of software. It is either a data entity, a transformation server, an I/O server, or a data flow manager. A software developer can refine and relate those design elements according to the rules of the Universal Design Pattern (as provided above) to obtain a quality architectural design. It is imperative though, that a software developer does not introduce design elements that belong to multiple realms! Similarly, the general rule that a design element can only be composed of design elements of the same type (data entities being a by-product of decomposition) is absolutely essential. Note that this is the way we design systems in other industries. When designing a car, for example, we would never introduce arbitrary design elements -- say a front-end and a back-end -- and then discover later that the front-end contains a driver's seat, spark plugs, and tires. No; we would divide the elements of the car into separate realms at the highest level of design -- such as passenger comfort, power train, and rolling gear - - and then model the design elements of each realm separately. For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!
Copyright Rational Software 2001 Privacy/Legal Information