Semantic Analysis Patterns

Development of SAPs

SAPs are based on well-known principles such as abstraction, composition, minimal coupling, and regularity. They also incorporate other principles not usually included in most methods , such as authorization, precision, and testability [Fernandez2000C]. We illustrate here the use of some of these principles in the development of an SAP for inventories.

Abstraction

Abstraction is the most fundamental principle of the object-oriented approach. It implies including only the essential aspects of a model, leaving out details that are not relevant or needed. We illustrate this concept with a basic model for an inventory system for discrete items. Its basic functions can be summarized as follows .

1. Keep track of different varieties of stock. Keep track of the quantities of each item in stock. Several kinds of quantities may be needed—for example, onHand and Available .

2. Keep track of the locations of items. The inventory should record the distribution of items in specific locations. Locations could be subdivided for easier location of items. Each flow of stock material between locations should be reflected in the inventory distribution.

The most basic inventory model just keeps track of the quantities of some type of item in stock (see Figure 47.1). The items in this inventory can be finished products, components used in manufacturing, machinery, and so on; in other words, anything of whose existence and quantity we want to be aware. Each item belongs to a unique type, ItemType . This is a fundamental abstraction that corresponds to requirement 1. Any inventory system model must have this model as a component. Similarly, we can make abstractions of any other requirements. To realize requirement 2, we need to break down the inventory quantity into location quantities (usually there exist several locations where an inventory item can be stored). This model is shown in Figure 47.2

We can consider the diagrams shown in Figures 47.1 and 47.2 to be atomic analysis patterns. They describe two abstractions that correspond to the following two fundamental use cases:

• Keeping track of quantities of discrete items (Figure 47.1).

• Keeping track of the locations of those items (Figure 47.2).

Each stage of XP typically implements one or two of these use cases or stories.

Decomposition

To be able to model a complex system, we need to apply decomposition, the divide-and-conquer principle. For example, a manufacturing system is far too complex to handle as a single unit. A decomposition for this system would consist of a set of UML packages such as Inventory Control, Shop Orders, Customer Orders, Shipping, and Money. The interactions between packages are important to define the needed operations in the classes of each package. Decomposition is very important for XP; each stage implies an explicit or implicit decomposition of the requirements.

Composition

Patterns can be composed to build larger models [Fernandez2000A]. For example, we can compose the patterns of Figures 47.1 and 47.2 to form a larger pattern that keeps track of stock quantities and their distribution. Figure 47.3 shows the composite pattern (this includes authorization, discussed later). Clearly, this principle is also basic for XP, to put together the results of each stage.

Projection

Projection is the combination of different diagrams or views of the system to provide a more complete picture. It can be likened to the need to describe a mechanical piece using different views, or projections; a single view would give a distorted and incomplete picture of its three-dimensional properties. This is a principle not emphasized XP. In particular, complex applications need several diagrams to be fully understood .

Minimal Coupling

This principle is frequently used in design patterns, in which a main objective is flexibility [Gamma+1995]. It is also heavily used in Fowler's analysis patterns [Fowler1997]. The idea is to separate some aspects to enable them to evolve independently.

In the example, if we had a detailed description of the structure of items, we could use the Composite pattern [Gamma+1995] to describe this structure recursively. This would decouple the structural aspects of a component or product from more basic aspects. We could also decouple other aspects of the item description.

Precision

A model such as the one shown in Figure 47.1 may not be precise enough to represent some of the constraints in the requirements. For example, to indicate that the sum of inventory quantities must be constant in inventory transfers between locations, we need to add a UML constraint. This can be added to the class Inventory as follows:

{sum of quantities must be constant}

However, this is not precise enough for many cases. If we had more complex constraints, statements of this form may be ambiguous. This ambiguity cannot be tolerated in safety-critical applications, for example. Both Z [Cook+1994] and OCL [Wanner+1998] have been used to add precision to UML constraints. A comparison of Z and OCL as constraint languages is given in [Jiang+1999].

Authorization

When we build systems using atomic patterns or SAPs, we know the actor roles in the use cases that correspond to these units. These actors need specific rights to perform the functions defined in the use case. We can then define authorization rules according to the principles of Role-Based Access Control (RBAC) [Fernandez+1997]. For example, in the inventory, we could include the authorizations shown in Figure 47.3, where classes such as StockManager indicate roles (denoted by the UML stereotype <<role>> ). For example, in Figure 47.3 the InventoryManager is authorized to transfer stock between locations.

Testability

Use cases (or user stories) correspond to the necessary interactions with the system and define sequences of actions that can be used to test the system [Jacobson+1998]. A system defined following use cases is then implicitly highly testable. For example, for the inventory, we could build test cases to follow the actions of the sequence diagrams of this application [Fernandez2000B] and check whether a Shop Order changes state and the inventory quantities are updated when specific events occur.