Section 19.4. ASPECTS AS THEMES: EXAMPLES


19.4. ASPECTS AS THEMES: EXAMPLES

We now look at some more examples of well-known aspects designed using crosscutting themes. These examples illustrate how crosscutting requirements may be designed independently from any base design, making aspect design truly reusable. The aspects illustrated are synchronization and the Observer pattern.

19.4.1. Library Base Design

The base design on which the aspect examples are applied is a small library design (Figure 19-6). This library has books of which all copies are located in the same room and shelf. A book manager handles the maintenance of the association between books and their locations. The book manager also maintains an up-to-date view of the lending status of book copies.

Figure 19-6. Base library design.


19.4.2. Example 1: Synchronization Aspect

The first crosscutting requirement is that the book manager should handle several requests to manage books and their locations concurrently. This aspect example, first described in [16], supports the book manager handling several "read" requests concurrently while temporarily blocking "write" requests. Individual "write" requests should block all other services.

19.4.2.1 Pattern Specification

Synchronization of concurrent processes is a common requirement, and therefore, it is useful to design this behavior without any reference to our library example. Figure 19-7 illustrates how this can be achieved. The Synchronize theme has one pattern class, SynchronizedClass, representing any class requiring synchronization behavior.

Figure 19-7. Synchronization aspect design.


Within this pattern class, two template parameters are defined, called _read(..) and _write(..), to represent reading and writing operations. This example also illustrates how non-template elements may be specified within a pattern class to define the inherent crosscutting behavior. These elements are merged unchanged into the composed class. Synchronization behavior introduces a number of such elements, both structural and behavioral, to synchronized classes. Structural properties activeReaders and activeWriters maintain counts of the number of read and write requests currently in process (for write requests, this number will never be greater than 1). Two interaction patterns define the required behavior for reading and writing. The read pattern ensures that any currently writing process is completed prior to processing a read request. The write pattern ensures that all currently reading and writing processes are completed prior to processing a write request. The designer represents the actual replacing of read and write operations with an "_" prepended to the template parameter namethat is, using _read(..) and _write(..), and the generated operations realized by the interactions as read(..) and write(..). In this way, when a replacing operation is executed in the context of synchronization, the required behavior is clearly defined within the interactions.

19.4.2.2 Pattern Binding

Specifying how to compose the Library base design theme with the Synchronize theme is a simple matter of defining a composition relationship between the two, denoting which class(es) are to be supplemented with synchronization behavior, and which read and write operations are to be synchronized.

In this case, the library's BookManager class replaces the pattern class in the output, add() and remove() operations are defined as write operations, and the search() operation is defined as a read operation (see Figure 19-8).

Figure 19-8. Composing Synchronize with Library.


19.4.2.3 Composition Output

Pattern specification and binding, as previously illustrated, are all the designer has to do to define reusable aspect patterns and specify how they are to be composed with base designs. The composition process, utilizing UML template semantics, produces the design illustrated in Figure 19-9, where BookManager now has synchronizing behavior. Note also that the object names in the interactions have been renamed as appropriate.

Figure 19-9. Library design with Synchronize.


19.4.3. Example 2: Observer Aspect

The second example is the Observer pattern [8], which, unlike the synchronization example, describes the pattern of collaborative behavior between more than one objecta subject and observers. This example also illustrates how non-pattern classes may be used within a theme.

19.4.3.1 Pattern Specification

In the Observer theme, two pattern classes are defined. Subject is defined as a pattern class representing the class of objects whose changes in state are of interest to other objects, and Observer is defined as a pattern class representing the class of objects interested in a Subject's change in state (see Figure 19-10).

Figure 19-10. Observer aspect design.


The interaction in Figure 19-10 illustrates another example of specifying behavior that crosscuts templates, with Subject's template parameter _aStateChange(..) supplemented with behavior relating to notifying observers of changes in state. This is achieved by referring to the actual replacing operation with a prepended "_", i.e., _aStateChange(..). Here also is an example of an operation template parameter that does not require any delegating semantics. The update() operation in observers is called within the pattern and is not, itself, supplemented otherwise. It is defined as a template so that replacing observer classes may specify the operation that performs this task.

This pattern also supports the addition and removal of observers to a subject's list using _start(.., Subject, ..) and _stop(.., Subject, ..) template parameters, where each is replaced by operations denoting the start and end, respectively, of an observer's interest in a subject. For space purposes, the interactions are not illustrated here, as they do not illustrate any additional interesting properties of Theme/UML.

19.4.3.2 Pattern Binding

As with the Synchronize pattern, the composition of Library with the Observer pattern is achieved by specifying a composition relationship between the two, defining the class(es) acting as subject, and the class(es) acting as observer. In this example, there is only one of each (see Figure 19-11), BookCopy and BookManager, respectively.

Figure 19-11. Composing Observer with Library.


One additional point of interest with this binding is how the meta-properties of a design theme's elements may be queried to assess an element's eligibility to join a set of replacing elements. UML's Operation meta-class defines more properties for operations than most coding languagesfor example, in addition to its signature, a designer may specify that an operation is a query operation. Theme/UML supports the discrimination of replacing operations on the basis of any of a design element's properties.

In this example, the _aStateChange() template parameter is replaced with all operations within BookCopy that have been defined as being non-queryi.e., those operations that affect a change in state that may be of interest to an observer. The keyword meta within the set parameter specification denotes that a UML meta-property is queried, and only those operations with isQuery=false will replace _aStateChange() for the purposes of Observer.

19.4.3.3 Composition Output

The output of composing Observer with Library, illustrated in Figure 19-12, shows BookCopy demonstrating subject behavior, with the operations borrow() and return() initiating the notification of observers, as they are the only state-changing operations. BookManager, as an observer, has defined updateStatus() as the operation to be called for notification purposes. Though not shown, addView(..) and removeView(..) initiate a BookCopy adding and removing a BookManager from its list of observers.

Figure 19-12. Library design with Observer.




Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

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