Section 25.2. MOTIVATION


25.2. MOTIVATION

Consider a collaborative travel planning application that is to be used by customers and travel agents to make travel bookings [12]. Examples of the user interfaces provided by such a system are illustrated in Figure 25-1 (left). Some of the software components composed to form such an application are illustrated in Figure 25-1 (right).

Figure 25-1. Example component-based application.


We built this component-based system by composing a set of software components that provide the necessary facilities. These include travel itinerary management, customer and staff data management, system integration with remote booking systems, and various user interfaces. Some components, such as the map visualization, database, and email server, are quite general and highly reusable.

Others components, such as the travel itinerary manager, travel item manager, travel booking interfaces, and integration components, are much more domain-specific.

When building such an application, a developer needs to identify and assemble many components. These have usually been built using "functional decomposition"organizing system data and functions into components based on the vertical piece(s) of system functionality they support. However, many systemic features of an application end up crosscutting many of the different components in the system [10, 20]. For example, user interfaces, data persistency, data distribution, security management, and resource utilization all have pandemic impact. Some components provide such functionalities; others require them [3]. We use the term "aspects" to describe these crosscutting, horizontally impacting concerns.

To illustrate how systemic aspects affect components, Figure 25-2 shows three components from the travel planner system: Tree Viewer, Travel Itinerary, and Database. Aspects User Interface, Persistency, Collaborative Work, and Transactions crosscut these components' methods and state. The Tree Viewer provides user interface and collaborative work support. The Travel Itinerary component requires user interface and persistency support in order to work but provides data to render and store itinerary items. A Database component provides data storage and transaction coordination support but requires transaction coordination. The three components must work together to provide the travel plan viewing, business process, and data management required by the system. Note that several aspects affect each of these components in different ways.

Figure 25-2. The concept of aspects crosscutting interrelated software components.


For each aspect that affects a component, we need to provide additional informationa set of aspect details. Each aspect detail may also be constrained by one or more aspect detail properties that describe detailed functional or non-functional constraints. In our example, we may assert that the Persistency aspect affects the Itinerary manager. We may then specify that the nature of this Persistency impact is that it requires a component providing data storage (a Persistency aspect detail). We may further specify that the data storage provided to it must meet some level of performance constraint. For example, 100 insert() and update() functions must be supported per second (an aspect detail property constraint for the data storage aspect detail). Other aspect details might specify the kind of awareness supported by the tree viewer (e.g., highlight of changed items), the kind of authentication or encryption used (Security aspect details), the upper bounds of resources used, performance required, or concurrency control techniques they enforce.

In aspect-oriented programming languages [20], aspects support code injection into methods. For example, in AspectJ, pointcuts can specify where to add persistency management, memory utilization, and user interface and distributed communication code [6]. In aspect-oriented design [3, 18, 34, 35], aspects are used to describe crosscutting concerns affecting the components. In dynamic aspect-oriented programming [30, 38, 40], components might be modified at runtime using the aspects to change their parameters or their running code.



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