Section 25.4. COMPONENT SPECIFICATION AND DESIGN WITH ASPECTS

25.4. COMPONENT SPECIFICATION AND DESIGN WITH ASPECTS

Our approach gives developers a way to capture crosscutting impacts of systemic functionality and associated non-functional constraints as aspects. Note that using aspects is only one approach for doing this. Approaches using some form of multi-perspective or viewpoint representations are also common [1, 8, 13]. Using aspects gives developers a way to categorize the impact of these concerns on different components and different parts of components.

During requirements engineering, we use aspects to document the functional and non-functional properties of a component. These are then grouped using a set of aspect categories. Common categories include user interface, collaborative work, component configuration, security, transaction processing, distribution, persistency, and resource management. Domain-specific aspects can also be used. In the example domain, these include services relating to travel itinerary management, payment, and order processing.

Figure 25-4 illustrates a simple use of aspects when specifying two interrelated software components. In this example, the travel planner's requirements identify several components that must provide extensible user interfaces, where one component provides a user interface that another adapts at runtime. This adaptation is usually the structured addition of a new user interaction "affordance." For example, the travel itinerary construction use case says that new "travel item" construction facilities must be able to be added dynamically to the itinerary planning user interfaces.

Figure 25-4. A simple component specification example using aspects.

Figure 25-4 shows the itinerary editor component, which uses a tree editor and multiple itinerary item creation (factory) components. The aspects of the itinerary editor specify that it provide (among other things) an extensible affordance user interface facility. This means other components can extend its user interface in certain controlled ways. Another component, an itinerary item factory, is used to create particular kinds of itinerary itemsflights, hotel rooms, rental cars, and so on. This factory requires a component with an extensible affordance so it can add a button, menu item, or drop-down menu item to this user interface for creating different kinds of travel items. In this example, the provided user-interfaceextension aspect detail in the itinerary editor aspects satisfies the required one in the factory's aspects. This approach can be used to describe a large range of provided and required component functional and non-functional properties. Developers can then reason about the interrelationships of components.

During design, developers refine component specifications into detailed designs and then design implementation solutions. They also refine the aspect specifications to a much more detailed level. To describe their designs, developers create additional design diagrams. Each diagram focuses on particular aspects affecting a group of related components. An example from the travel planner system is shown in Figure 25-5, an annotated Unified Modeling Language (UML) sequence diagram. This describes component interactions in the travel planning system as a user constructs part of a travel itinerary. In the example, the user interacts with a web-based thin-client interface for the itinerary editor. This in turn interacts with application server-side components. Additional middleware and database components provide the infrastructure for the architecture of this design.

Figure 25-5. Component interaction design example.

In this example, we have used UML stereotypes to indicate the aspects affecting each component. Both method invocations and component objects have been annotated in this way. We have used UML note annotations to further characterize particular method invocations between components. These indicate "provided" and "requires" aspect details. Some details are also characterized by adding non-functional constraints. In this example, they include the type of security and data storage required and required performance measures of the distributed system communication.

Such aspect-augmented design diagrams allow developers to capture richer information about their component designs. Developers can augment existing diagrams or create new ones. New diagrams allow them to focus on particular parts of a system or particular component interactions. Our aspects give developers a way to capture and document both functional and non-functional constraints during design.