Towards Aspect-oriented Design and Architecture Holger Giese Computer Science, University M¨ unster
[email protected]
Alexander Vilbig Computer Science, TU M¨ unchen
[email protected]
Abstract. This paper proposes a novel technique for aspectoriented design and architecture of component-based software systems. It separates design into domain-oriented, possibly nonorthogonal aspects for which an optimal, local design may be developed first. Later, the individual aspects are combined into an overall system design. To this means, we introduce well-defined contracts for the specification of interface, interaction protocol, and applicable restrictions. A constructive composition algorithm is presented which reliably detects conflicts between individual aspects.
Current production equipment offers a variety of interfaces for configuration of a given machine, monitoring of relevant parameters, or control of the actual production process. In the following, we first consider Production Chain and Machine Control as logical, non-orthogonal aspects of the application domain and provide an optimal design for them in isolation. Later, in Section 3, we demonstrate how these partial specifications may be combined into an overall system design using the proposed technique.
1
The most essential task of the assembly line is to ensure proper processing of products and thus a correct interplay of all machines. In the PPC system, we represent machines as software components with suitable interfaces while the physical connections between machines are mapped to logical connections between these interfaces. In order to derive a suitable design for this aspect, we may apply the pipes-and-filters architectural style [9]: Machines are regarded as special filters on the material flow while the conveyor belts between them represent pipes. Based on this style, we design the aspect Production Chain by an overall structure as shown in Figure 1 as well as a dedicated behavior specification for the necessary interaction protocol.
2.1
Introduction
Current software is usually an extremely complex product due to its continually increasing functionality with always new or changing requirements. Consequently, the development of software is also a very complex and difficult task. Object-oriented and component-based approaches to software development introduce the notions of object or component to decompose a software system into smaller, manageable subunits [10]. Software architecture and design determines the actual structure of the system as well as the interactions between the involved subunits on different levels of abstraction. To this means, architectural styles and design patterns provide valuable guidelines which also facilitate understanding and documentation of the system [9, 4]. Nevertheless, the design of large software systems in practice often results in a complex mixture of different structures, confusing interactions, undefined dependencies between components, and an overall architecture which is difficult to comprehend. As a consequence, the implementation, maintenance, and evolution of such systems requires enormous efforts. Recently, another well-known principle for managing complexity, namely separation of concerns, has gained popularity for software development with approaches like aspect-oriented programming (AOP) [6] or subject-oriented design [3]. Individual, usually orthogonal aspects of the system in question are developed in isolation first, until the composition of all aspects results in an overall system design or implementation at the end of the process. In this paper, we build on this idea by elaborating a technique which allows to specify and compose non-orthogonal, domainoriented aspects in order to produce an overall componentoriented system architecture. It is based on rigorous, formal contract specifications for component behavior and a constructive composition algorithm which reliably detects conflicts between individual aspects. Thereby, optimal solutions for individual aspects of a software system may be achieved while reducing the involved complexity of the overall design. The presented approach is illustrated by a simplified application example introduced in Section 2. Section 3 covers the necessary formal foundation for aspect composition and applies the presented concepts to selected aspects of the application example. Section 4 compares the approach to related work while Section 5 concludes with a summary.
2
Aspect 1: Production Chain
Figure 1: Structure of Production Chain For the latter, we employ the concept of a contract [10] which is associated with components of the system. Generally, a contract defines a particular subset of a component´s behavior relevant to the interaction with other components. A given component is said to fulfill one or several contracts if its implemented behavior matches the given specifications. Consider the example of the contract SimpleProcess as illustrated in Figure 2. The required behavior is specified by a state diagram (cf. [8, 5]) which determines both the set of available operations, i.e. transitions between states, and the service-oriented interaction protocol.
Application Example
The example used throughout this paper considers a production planning and control system (PPC). It is used to drive a simplified production facility which consists of an assembly line where products are passing through successive stages with different machines connected by conveyor belts (cf. Figure 1).
Figure 2: Contract SimpleProcess The contract SimpleProcess specifies that each client of a machine needs to register for product delivery. Once this registration is
1
done and the contract state switches from Free to Processing, the machine subsequently accepts and processes parts via the putPart operation until the logical connection is no longer required and the client cancels registration. Consequently, the contract is again in state Free. This registration protocol ensures that only one client may use a given machine at any point in time as relevant for MachineE in Figure 1.
2.2
In our example, this only applies to the components of type Machine. The composition of both considered aspects requires them to provide the contracts Control, and SimpleProcess while using the contract SimpleProcess of a different machine as indicated by Figures 1 and 3. The composition of individual aspects is rather simple if the specified contracts are completely orthogonal, i.e. the usage of a contract provided by a given component will never effect other clients which use different contracts of the same component. Clearly, this assumption will not hold in the majority of cases. Consider, for example, a client which uses the Control contract of a given machine to turn it off via a shutDown message (cf. Figure 4): any other client which currently uses the SimpleProcess contract of the same machine to deliver parts via a putPart message (cf. Figure 2) is liable to fail unexpectedly because the machine is simply not working anymore. The previous example illustrates the need to reliably identify and resolve potential conflicts when composing behavior specified in different aspects of the overall design. To this means, it is necessary to provide a rigorous model of component behavior, extend the notion of a contract with propositions about consistency restrictions, and develop an algorithm using these restrictions to detect potential conflicts during behavior composition.
Aspect 2: Machine Control
Within this aspect, we consider the overall control-related functionality of the PPC system, i.e. the coordinated startup and shutdown of the assembly line. Although a central control facility is desirable, the system should also support fault tolerance by providing local control for each stage. Therefore, we design a hierarchical structure of control components (loosely based on the Broker -pattern [2]) which propagates the commands of the central control as shown in Figure 3.
3.1
In order to describe the behavior related to a single contract in terms of states and atomic actions, we use a labeled transition system. This model of component behavior includes internal steps (τ -steps, cf. LOTOS [1]) which are also used to consider contract autonomous non-determinism as described later in this section.
Figure 3: Structure of Machine Control
Definition 1 A labeled transition system with τ steps (S, A, → , S i ) is defined by a set S = {s0 , s1 , . . .} of states, an alphabet A without τ , a step relation →⊆ S × A ] {τ } × S and a non-empty set of initial states ∅ = 6 S i ⊆ S. As an abstraction from internal τ τ steps, the multi step relation →∗ is defined as the reflexive and τ transitive closure of →. Additionally, we define the set of initial a possible external steps by init(s) := {a|∃s0 ∈ S, a ∈ A s → s0 }.
For behavior specification, a set of contracts is associated with the components Line Control, Stage Control and the involved machines. Within the example, however, we concentrate on the behavior of a machine because the other components are only relevant to this particular aspect. For the sake of simplicity, the Control contract only considers three essential states of a machine: Off, StandBy, and Running (cf. Figure 4). The machine accepts control operations which cause a change between these contract states. For example, the operation WarmUp instructs the machine to calibrate itself and then change from state Off to StandBy.
From a methodical point of view, it is important to emphasize the distinction between the two different forms of non-determinism implied by Definition 1: Multiple transitions with the same label originating from the same state represent alternative paths in the specified interaction protocol. These alternatives are explicit to the client of a contract and only relate to the nature of interaction for this particular contract. Therefore, we relate to this form of non-determinism as contract usage non-determinism. Another possible form of non-determinism results from autonomous behavior of the contract provider and interferences with behavior specified in other contracts. We use τ steps to describe that a system might arbitrarily change its state due to autonomous component behavior or the interaction with other contracts. Consequently, we denote this notion of non-determinism as contract autonomous non-determinism. To clarify this distinction, consider the example of the Process contract as presented in Figure 5, an extended version of the SimpleProcess contract (cf. Figure 2). The additional states Halted and Stopped are introduced to represent the fact that a machine may not be working and thus not available for processing. However, the events that lead to a stop or halt of the machine are not within the scope of the contract in question. They are a result of internal machine behavior (e.g. a failure) or potential interactions with other contracts. Therefore, only τ steps relate Free with Halted and Processing with Stopped. Note that these additional states represent a local view of the Process contract on the machine — they are not the result of explicit knowledge about the Control contract.
Figure 4: Contract Control
3
Formal Model of Behavior
Aspect Composition
The composition of individually designed aspects has to address two areas of the system in question, namely structure and behavior. The structural view is concerned with the superposition of partial structures, i.e. the identification of common components, the assignment of specified contracts to these components, and the establishment of connections between them as specified by the individual aspects. The behavior-related part of design is then used to identify and resolve potential problems due to conflicting interactions. For components considered in multiple aspects, the set of provided or used contracts is simply the union of the individual contracts.
2
definition of contract conform which denotes this desired property for any parallel product: Definition 3 Any restricted parallel product M = (S, →, A, S i ) of a given set of labeled transition systems M1 = (S1 , →1 , A1 , S1i ), . . . , Mn = (Sn , →n , An , Sni ) is contract conform for Mk (1 ≤ k ≤ n) (denoted as M |= Mk ) iff ∀(s1 , . . . , sn ) ∈ Sl init(sk ) ⊆ init((s1 , . . . , sn )) M |= M1 , . . . , Mn ⇐⇒ M |= M1 ∧ . . . ∧ M |= Mn Intuitively, a given parallel product of two or more labeled transition systems is contract conform, if each state combination (s1 , . . . , sn ) is associated with at least the set of outgoing transitions for the individual state components s1 to sn as specified by their original contracts. Note, that the full parallel product is always contract conform due to its construction.
Figure 5: Process Contract This behavior is thus modeled by contract autonomous nondeterminism within Process. However, if we wanted to specify explicitly that a call of register may actually result in a state Halted or Stopped, we would have to add accordingly labeled transitions using contract usage non-determinism.
3.2
3.3
Contract Composition
The composition of two contracts representing different aspects of system design initially results in the product transition system, i.e. a complete state space with all possible combinations of individual states as well as all allowed transitions between them. For the proposed approach to contract composition, the distinction between contract autonomous and contract usage non-determinism is a crucial one. Therefore, we have to compose the regular behavior of one contract, as specified by labeled transitions, with τ steps of the other one while preserving all τ steps of the product for later composition steps. The following definition provides a formal foundation for this composition approach: Definition 2 For a given pair of labeled transition systems M1 = (S1 , →1 , A1 , S1i ) and M2 = (S2 , →2 , A2 , S2i ) where S1 ∩ S2 = ∅ = A1 ∩ A2 , we define the full parallel product labeled transition system M3 = M1 × M2 := (S3 , →3 , A3 , S3i ) by S3 := S1 × S2 , →3 :=→31+2 ∪ →32+1 ∪ →3τ , A3 := A1 ] A2 and S3i := S1i × S2i . For a ∈ A3 we define: a 3
τ 1
a 2
→31+2 := {(s01 , s02 ) → (s001 , s002 )|s01 →∗ s001 ∧ s02 → s002 }
Definition 4 For the overall state set S, the overall alphabet A and a labeled transition system Mk = (Sk , →k , Ak , Sik ) a restriction is a predicate Rk : Sk × ℘(S − Sk ) × ℘(A − Ak ) → {true, false}1 .
Thus, any combination of multiple τ steps in M1 and a single, non-τ step in M2 results in a possible step for M3 . a 3
a 1
Contract Restrictions
Any given implementation of a component in the system has to fulfill all its assigned contracts representing the different relevant aspects of design. Ideally, if all aspects were orthogonal, the implementation could simply perform all specified interaction protocols independently, for example by parallel execution of the individual transition systems or a suitable implementation of their full parallel product. In practice, however, many aspects are liable to effect each other and there exist various dependencies and interferences between them. Within the presented approach, we propose to formulate restrictions as predicates over states and transitions which may be attached to existing contracts. They are evaluated during contract composition and may thus lead to the exclusion of particular state combinations in the resulting parallel product. Obviously, it is then necessary to check the restricted product for contract conformance with the original contracts (cf. Definition 3). Generally, a restriction for a parallel product M of M1 , . . . , Mn is a predicate Rk : S1 × · · · × Sn → {true, false} for a given contract Mk . This may be formalized by a restriction of the parallel product M that relates to a particular state of Mk , the set of states of the other contracts of M, and the set of transitions of other contracts:
τ 2
→32+1 := {(s01 , s02 ) → (s001 , s002 )|s01 → s001 ∧ s02 →∗ s002 } The previous proposition considers the complementary case where each combination of a single, non-τ step in M1 and multiple τ steps in M2 results in a possible step for M3 . τ 3
τ 1
τ 2
→3τ := {(s01,s02) → (s001,s002 )|(s01 → s001 ∧ s02 = s002 ) ∨ (s02 → s002 ∧ s01 = s001 )} Additionally, all τ steps are preserved in the combined transition system. Such a full parallel product of two labeled transition systems represents their complete combined behavior with all possible state combinations. In practice, a particular selection of state combinations may be considered meaningless or explicitly excluded by restrictions as described later in Section 3.3. Therefore, it is further useful to also define the notion of a restricted parallel product M |S0 which comprises only a subset of the product state space S 0 ⊆ S. For a restricted parallel product, however, it is necessary to ensure that each contained state pair still fulfills the set of interactions offered in each original contract. Therefore, we introduce the
Figure 6: Classification of Contract Transitions Although it is possible to formulate restrictions by explicit references to particular states and transitions of other contracts, a more encapsulated and abstract way of referring to them is preferred in practice. Thereby, we avoid having to repeatedly address 1 ℘(X)
3
denotes the powerset of a given set X
3.5.1
individual elements of numerous, previously known contracts during restriction specification. Therefore, we introduce a classification scheme for states and transitions of the system which groups them into meaningful classes. As an example, consider the classification of transitions for the PPC system as shown in Figure 6. It separates possible Actions of the system into Modifiers and Observers. The latter comprises transitions like getStatus or getData of monitoring-related contracts, while the former category is further refined to Work and Control operations. The transition putPart of the Process contract represents the only classified Work operation while all other transitions of the system are considered to be Control operations. A corresponding classification scheme for states of the PPC system is shown in Figure 7. The states Free, Running, and Processing are considered Regular states while StandBy, Off, Stopped, and Halted are classified as NotRegular.
Note that the transitions warmUp, shutDown, start, and stop in the category Modifier are part of the Control contract itself and are therefore not considered by restriction RC (cf. Definition 4). The labeled transition system specified in the Control contract ensures that only warmUp may be used to leave the state Off. Figure 8 shows the result of the composition of SimpleProcess (which has no specific restrictions) and Control as a tabular diagram. The original transition systems of the contracts are depicted on top and to the left of the table while the resulting state pairs of the parallel product form the cells of the table. Their label is derived from the first letter of the original states. In all cases, an initial state is drawn with a heavy border. Additionally, the effects of the composition algorithm in Section 3.4 are represented with different colors: yellow denotes state combinations of the product which are removed during step 2 because of applicable restrictions, while blue and red indicates product states removed during the first and second cycle of step 3 because of missing contract conformance. Note that the resulting transitions of the product are not shown for reasons of clarity, although they may easily be derived from the original state transition systems.
Figure 7: Classification of Contract States In Section 3.5 we present exemplary restrictions for Process and Control contract which employ the previous classifications for the expression of localized, aspect-related consistency conditions.
3.4
SimpleProcess and Control
When combining any contract with Control, it is reasonable to assume that a machine in control state Off may only provide the transition warmUp within the category Modifier. Moreover, a machine in state StandBy is designed to allow no activity classified as Work. These assumptions reflect the particular view of the Control aspect and result in the following formal restriction for this contract: A ∩ Modifier = ∅ : s = Off RC (s, S, A) := A ∩ Work = ∅ : s = StandBy true : s = Running
Composition Algorithm
Using the previous definitions, it is possible to provide an algorithm for the composition of finite aspect-related behavior. For a given pair of contracts C1 and C2 with labeled transition systems M1 = (S1 , →1 , A1 , S1i ) and M2 = (S2 , →2 , A2 , S2i ) as well as restrictions R1 and R2 , we outline the algorithm as follows: 1.) Construct the full parallel product labeled transition system M3 = (S3 , →3 , A3 , S3i ) as defined in Definition 2. 2.) Evaluate the restrictions R1 and R2 by determine the restricted state set S3r := {s3 ∈ S3 |R1 (s3 ) ∧ R2 (s3 )}. 3.) Consider three possible cases: • If S3r does not contain any initial state the algorithm terminates with an empty result. • For S3r = S3 the algorithm terminates with transition system M3 as result. • Otherwise remove states which are not contract conform using S30 := {(s1 , s2 ) ∈ S3r |init(s1 ), init(s2 ) ⊆ init((s1 , s2 ))} and proceed with the restricted transition system M3 := M3 |S30 by repeating step 3 until the algorithm terminates.
Figure 8: Composition of SimpleProcess and Control The evaluation of restriction RC results in a removal of the product states F+O and P+O because Modifier transitions exist (register and deRegister) which are excluded for state combinations with Off. Product state P+S is deleted as well, since it offers a Work operation (putPart) which is not allowed in combinations with state StandBy. The algorithm will terminate at this point because the initial test of step 3 determines that there is no initial state left (F+O has been removed) and thus the composition is not consistent. In order to further illustrate the algorithm, we assume that such an optimization is disabled and proceed with the check of contract conformance. It turns out that both F+S and P+R are not contract conform: F+S has no register transition (required by contract Process) and no shutDown transition (required by contract Control), while P+R has no stop transition (required by contract Control). Consequently, F+S and P+R are removed from the parallel product. Finally, in a second cycle of the check for contract
Note that the deletion of states which are not contract-conform may render other states not contract-conform as well (see Section 3.5.1 for an example of this effect).
3.5
Application of Behavior Composition
In this section, we apply all previously described concepts of the presented approach to the example of the PPC system as described in Section 2. We add restrictions to the individual contracts of the component Machine by employing the classification schemes shown in Figures 6 and 7. We then try to iteratively combine pairs of contracts using the composition algorithm in Section 3.4.
4
conformance, F+R is deleted as the required stop and register transitions are now missing due to the previous removal of F+S and P+R. In all cases, the algorithm indicates that both contracts are not compatible and thus no suitable implementation exists, given the assumed restrictions. Intuitively, both aspects are not compatible because SimpleProcess regards a machine to be always available while Control is actually meant to render it temporarily unavailable.
3.5.2
this reason, AOP mainly pertains to crossover functionality like, for instance, persistence or error handling. In contrast to approaches which consider non-functional requirements with meta object protocols [12], the presented approach explicitly addresses the separation of non-orthogonal, functional aspects by means of contracts with non-determinism. Moreover, aspect weaving is usually carried out on the level of program code as opposed to the composition of specifications proposed in this paper. A considerable exception is subject-oriented design [3] which is also a synthesis-based approach and supports select, merge or overwrite as user defined options. Role-based modeling [7] supports several, dedicated views on a system and thus may help to identify suitable contracts. The presented approach, however, considers the question whether a set of contracts with explicit consistency conditions may be satisfied by a single component.
Process and Control
In contrast to the somewhat ”naive” specification of SimpleProcess, the Process contract takes a temporarily unavailable machine into account by including τ transitions to states Halted and Stopped (cf. Figure 5). The specification assumes that both states represent irregular machine behavior, possibly a failure or maintenance situation. Consequently, the restriction RP for the Process contract requires that they may not be composed with states classified as Regular (cf. Figure 7). S ∩ Regular = ∅ : s = Halted true : s = Free RP (s, S, A) := true : s = Processing S ∩ Regular = ∅ : s = Stopped
5
Conclusion
In this paper, we presented a novel technique for the design of complex, component-based software systems. It separates the overall design into multiple, possibly non-orthogonal functional aspects for which an individual, optimal design may be developed independently first. Later, these partial solutions are combined, using localized consistency conditions to detect possible conflicts with a tractable algorithm. We argue that this approach facilitates modular development, understanding, and maintenance of complex systems although there obviously remains a lot of work to integrate this technique into a comprehensive design methodology.
The resulting composition of contracts Process and Control with restrictions RC and RP is presented in Figure 9 using the previously introduced description technique.
References [1] LOTOS — A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour. Technical Report 8807, International Organization for Standardization (ISO), Gen` eve, Sept. 1989. [2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture – A System of Patterns. Wiley & Sons, 1996. [3] S. Clarke, W. Harrison, H. Ossher, and P. Tarr. Subject-Oriented Design: Towards Improved Alignment of Requirements, Design and Code. In Confernece on Object-Oriented Programming, Systems, Languages, and Applications, November 1-5, 1999, Denver, Colerado, USA, pages 325–339, 1999. [4] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison-Wesley, 1994. [5] D. Harel. Statecharts: A Visual Formalism for complex systems. Science of Computer Programming, 3(8):231–274, 1987. [6] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.M. Loingtier, and J. Irwin. Aspect-Oriented Programming. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP), number 1241 in LNCS. Springer Verlag, 1997. [7] T. Reenskaug. Working with Objects: The OOram Software Engineering Method. Addison-Wesley/Manning, 1996. [8] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison Wesley Publishing Company, December 1998. [9] M. Shaw and D. Garlan. Software Architecture: Perspectives on an emerging Discipline. Prentice Hall, 1996. [10] C. Szyperski. Component Software, Beyond Object-Oriented Programming. Addison-Wesley, 1998. [11] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton. N degrees of separation: multi-dimensional separation of concerns. In Proceedings of the 1999 international conference on Software engineering May 16 - 22, 1999, Los Angeles, CA USA, pages 107–119, 1999. [12] B. Vanhaute, E. Truyen, W. Joosen, and P. Verbaeten. Composing Non-orthogonal Meta-programs. In First Workshop on MultiDimensional Separation of Concerns in Object-oriented Systems (at OOPSLA ’99), 1999.
Figure 9: Composition of Process and Control In this case, the evaluation of restriction RC results in deleting F+O, P+O and S+O because there exist Modifier transitions which are not allowed in state combinations with Off. Moreover, P+S is deleted due to its putPart transition which violates the restriction for StandBy. Additionally, the combinations H+R and S+R are excluded by RP because Running is a Regular state. Subsequently, the test for contract conformance further deletes the state F+S since the transition register required by the Process contract is not available anymore due to the deletion of P+S. Finally, the composition algorithm will not remove further states and thus returns a non-empty, consistent transition system which successfully combines both specified aspects of a machine.
4
Related Work
The presented work is strongly related to and inspired by aspectoriented programming (AOP) [6] and related approaches as summarized by the notion of multi-dimensional separation of concerns [11]. The main idea is to independently develop suitable aspects of the system and to automatically weave them together later. However, the individual aspects — at least in the original proposals — are required to be orthogonal to each other. For
5
