Proceedings of the 12th Symposium of Mathematics and its Applications "Politehnica" University of Timisoara November, 5-7, 2009
ON MODELING SOME SOFTWARE ARCHITECTURAL STYLES Cristina MÎNDRUÞÃ West University of Timisoara
Abstract Software architectural styles are models of representative software structures. An architectural style defines a set of software element types, a set of relation types between elements and a set of constraints on using them. These definitions are rather informal, probably excepting constraints that are expressed in a logical language. In this paper we explore the ideea of using a previously proposed set-based metamodel for the type system of complex computing systems, in order to express type-related properties of some software architectural styles.1
1. Introduction “The software architecture of a program or computing system is the structure or structures of the system, which comprise the software elements, the externally visible properties of those elements, and the relationships among them.”. A software architectural style is a specialization for element types and relationship types, together with a set of constraints on their usage (Bass et. al (2003)) . 1
Mathematical Subject Classification(2008): 68N30 Keywords and phrases: software architecture, metamodel, system of types. 1
C.Mindruta
2
The objective of this paper is to experiment with a simple general metamodel the modeling of some representatives of the main families of software architectural styles. The metamodel we use is the model of a generic computing system seen from the virtual machine2 concept point of view. It offers a glassbox view of the virtual machine, defined in terms of types. Two abstraction levels may be considered in analyzing software architectural styles. In the high abstraction level the whole system is seen as a single virtual machine, and architectures differ by activation model implemented in the interpretation engine. The scope of this paper addresses the lower abstraction level, where the system is made of connected components, and we model each component as a virtual machine. We define constraints on interface types and on part of implementation types, for component types and for interaction approaches.
2. Set-based metamodel In this section we review a part of the formal model introduced and elaborated in Mîndruþã (2003) and refined in Mîndruþã (2004). It contains a setbased metamodel for the type system of computing components seen as virtual machines, divided into an interface model and an implementation model. 2.1 Static metamodel: interface model The interface of the virtual machine is formalized by the class of sets IE = {S, F, TE, AE} and by the set of correspondences IC = {fct, evt},where S is a finite set of types representing the interface data types, F is a finite set of types representing the interface functions, TE is a finite set of types representing the interface event types that can be generated by the virtual machine, and AE is a finite set of types representing the interface external events that can be received by the virtual machine. The correspondence fct:F P(S) associates to each function type the set of its arguments types and result types and the correspondence evt:F P(TE) associates its event types set to each function type.
In our approach, at a high level of abstraction a virtual machine is an assembly of two main components: API (application programming interface) and runtime environment. 2
On modeling software architectural styles
3
2.2 Static metamodel: implementation model The implementation model identifies underlying level types as implementation types and maps interface types into them. It also captures type relations for event handling and relations between event types. Let V be a finite set of carrier types, sources of types in S. The function Srs:S P(V) associates the carrier set sV P(V) to each sS. Let P be a finite set of carrier function types. The function Intp:F P(P) associates the set fP P(P) to each fPF. The set f P is the set of functions used in the implementation of f in a language defined over the alphabet P. The sets P and V are related by the function fct*:P P(V), similar to fct. In our approach, the internal events of a virtual machine, also called exceptions, are generated based on a logical predicate set implemented at the platform level and they result from the current activity on the virtual machine. They are not relevant to this paper. Asynchronous events (interrupts) are generated by entities in the virtual machine’s environment and are not synchronous with the current activity on the virtual machine. As specified in the interface model, AE is the set of external event types and is part of the virtual machine interface. The function Rut:AEP(P) associates the set of the functions in the implementation of the internal event handler for the event of type i, iP P(P), to each event type i AE.
3. Modeling dataflow styles The main representative of dataflow style is pipe-and-filter style. The structure of the software architectural design compliant to this style is determined by the motion of data form component to component. Each component (filter) reads streams of data on its inputs and produces streams of data on its outputs, usually while applying a transformation to the input stream, and processing them incrementally so that the output begins before the input is completely consumed. Each filter is completely independent of other filters: no shared state, control thread or identity. But communicating filters must agree on the data that is being transmitted between them. The component types specific to this style are filter, data source and data sink. In order to model them we have refined the metamodel to separate
C.Mindruta
4
argument types and result types of functions in F. The fct correspondence is refined into in:F P(S) and out:F P(TE), mappings of each function type to the set of its argument types and result types respectively. The component types of this style are characterized by the following relations: Filter: S ; F ; TE = ; AE = . Data source: S ; F = {1S}; TE = ; AE = . Data sink: S ; F = {1S}; TE = ; AE = . These relations represent interface restrictions meaning that all the component types have defined interface data types, that the filter may have interface function types that transform data, but data source and data sink do not transform data, so the function type is the identity on the data type set. It is also expressed that events are not present in the system, so no event type exists. In order to model interaction rules between components we have refined the metamodel by adding a new correspondence as follows: Let j and k be two virtual machines presenting the interfaces IE (j)= {S(j), F(j), TE(j), AE(j)} and IE (k)= {S(k), F(k), TE(k), AE(k)} The correspondence activate : F(j) F(k) maps a function type of virtual machine j to a function type of a virtual machine k to which it transfers data and/or control. From our type system point of view, the interaction rules between components of this style specify that communicating filters must agree on the data that is being transmitted between them, represented by: j,k if f F(j) and gF(k) and activate(f)=g , then in(g)=out(f).
4. Modeling call-return styles From call-return family of architectural styles we have selected the client/server style and the layered style. 4.1 The client/server style The client/server style has two component types, the client and the server. The server offers a set of services. The client sends a request to the server, for a service, via a connector. The server either rejects or performs the request and sends the response back to the client. The client initiates the activity and the server waits for requests to be made.
On modeling software architectural styles
5
The component types of the pure client/server style expose data types and function types in their interfaces, but do not throw or handle events: Client: S ; F ; TE = ; AE = . Server: S ; F ; TE = ; AE = . Let c be the client and s be the server. The characteristics of the interaction between client and server, represented from our type system point of view, are f F(c) and gF(s), the data types transferred when communicating to the server are part of the implementation data types of the client virtual machine, expressed by if activate(f)=g then in(g) V(c), and the result type transferred by the server is part of the implementation data types of the client virtual machine, expressed by if activate(g)=f then out(g) V(c). It results that fct(g) V(c). 4.2 The layered style Layers architectural style structures the applications that can be decomposed into groups of elements, each of which addressing a different level of abstraction. Relationships between layers are often implicit and is usually callreturn oriented. The component type is the layer, that exposes data types and function types in its interface, but does not throw or handle events: Layer: S ; F ; TE = ; AE = . The style has three main variants: basic, transparent layers and callback. Each has specific type constraints for component interaction. Basic layers can only call on services of the next lower layer that is, each layer provides services to the layer above it and calls on services provided by the layer below it. To model component interaction let us consider i, i-1 adjacent layers with i the upper layer and i-1 its next underlying layer. According to our model, the layer i-1 implements the layer i. This is represented by: F(i-1)=P(i) and S(i-1)=V(i). In the case of transparent layers, layers may call on services of other lower layers; one layer may provide services to more layers above it and may call
C.Mindruta
6
services provided by more layers below it. In other words, a layer i is transparent if it exposes to its upper layer a part of the interface of its underlying layer, modeled as F(i) ∩ P(i) . A stronger constraint, S(i) ∩ V(i) , expresses the fact that there are also data transferred through the transparent layer. When layers may call methods from the layers above we are in the variant with callback. In this case the type constraint for component interaction is F(i) ∩ P(i) , representing the nonempty set of callback function types, which are in the interface of the layer i and are called from its underlying layer i-1.
5. Modeling event-based styles Elements of event-based styles are loosely coupled concurrent processes. Elements communicate by sending and receiving events. The component types are event sender and event receiver. Event sender sends events generated by functions in F, and is modeled by S ; F ; TE ; AE = . Event receiver handles received events using functions in P, and is modeled by S ; F ; TE = ;
AE .
There are two main event-based styles. In explicit events style, event senders know identity of event recipients. The interaction restriction is modeled by (TE)∩(AE) , the nonempty set of all event types declared to be thrown that are handled in the system, that is communication takes place. The stronger constraint TE = AE means that for each event type defined to be thrown there exists a receiver, and all event types defined to be accepted may appear in the system. We can also represent all event types that a component k can send to another component in the system (including to itself) as TE(k)∩(AE), and the subset of all event types that can be sent to the component k as AE(k)∩( TE). In implicit events style (also named publisher-subscriber), identity of event recipients is not known by event senders. The interaction restriction is modeled by
On modeling software architectural styles
7
(TE)∩(AE) , the nonempty set of all event types published in the system for which at least one component has subscribed; that is, communication takes place. The stronger constraint (AE) (TE) means that all handled event types in the system are published, but not all published event types must be handled. Moreover, AE(k)∩(TE) represents the set of all event types that the component k is registred with, and TE(k)∩(AE) represents all event types published by a component k for which components in the system are registered.
6. Modeling data sharing styles The semantics of data sharing styles specify that on a central data structure called repository, that represents the current state of the system, operate independent components called data accessors. The repository can be passive or active. The component types of the data sharing style with pasive repository are: Data accesor, modeled as : S ; F ; TE = ; AE = . Data repository, modeled as: S ; F = {1S} ; TE = ; AE = . The type restriction for interaction of the components is k data accesor and rep the data repository, V(k)∩S(rep) meaning that each data accessor knows data types in the repository. We can also define the following stronger constraints: V(k) S(rep) meaning that accessor k works exclusively with data types existing in the repository, k, V (k) S(rep) meaning that each data accessor works exclusively with data types existing in the repository, S(rep) ∩V meaning that all data types in the repository are known to each data acccessor. An active repository notifies all the accessors (named knowledge sources) about changes in its state. The component types in this style are modeled as Knowledge source: Blackboard:
S ; F ; TE = ; AE .
S ; F= {1S} ; TE ; AE = .
C.Mindruta
8
Type constraints for component interaction are the same as with pasive repository, supplemented with k, AE(k) TE(rep) meaning that all types of the events sent by the blackboard are handled by each of the knowledge source.
7. Conclusions and future work Using a previously defined meta-model for a computing component, we have analyzed, from the type system point of view, some representatives of the main software architectural style families. The meta-model allows to identify some important differences between these styles. As future work we will explore the meta-model in order to model other software basic architectures and will try to model complex systems combining models of basic software architectures.
References [1] Len Bass; Paul Clements; Rick Kazman, “Software Architecture in Practice, Second Edition”, Addison-Wesley Professional, (2003). [3] C. Mîndruþã, Elements from a formal model for computing systems, Proc. 10th International Symposium of Mathematics and its Applications, “Politehnica” University of Timiºoara, Timiºoara, November 6-9, 2003, p.445-451. [4] C. Mîndruþã, A dynamic type changes model for adaptive simulation environments based on virtual machine meta-model, European Simulation and Modeling Conference ESMc'2004, UNESCO Paris, 25-27 October, 2004, p.74-78. [2] M.Shaw; D.Garlan, “Software Architecture. Perspectives on an Emerging Discipline”, Prentice Hall, (1996).
Cristina Mîndruþã - Department of Informatics, West University of Timisoara, Blvd. V. Pârvan 4, 300223, Timisoara, ROMÂNIA E-mail:
[email protected]
