Viale Sarca, Milano, Italy

Transcription

1 Defining Software Architectures Software Architecture course version February 2014 DRAFT V1 Francesco Tisato 1 and Diego Bernini 1 {tisato, bernini}@disco.unimib.it 1 DISCo, Università degli Studi di Milano - Bicocca, Viale Sarca, Milano, Italy Abstract. This report presents a preliminary definition of a methodological approach to the analysis and the design of software architectures. The overall process consists of five views. Problem Architecture is the result of an analysis focused on the significant aspects of data, activities and information flows from a user perspective. Logical Architecture groups activities into logical components, by taking into account the relevant dimensions of the problem. Concrete Architecture specializes logical components and information flows in terms of concrete components and interactions styles. Implementation Architecture defines platform-dependent implementations of concrete components and their interactions. Finally, Deployment Architecture assigns the concrete components to computing nodes. The discussion is carried on via a reference example. Pros and cons of different solutions are discussed and additional examples are sketched. 1

2 1 Introduction "In conclusion, we offer the following conjecture: perhaps the reason for such slow progress in the development and evolution of software systems is that we have trained carpenters and contractors, but no architects." (Dewayne E. Perry and Alexander L. Wolf, 1992) 1.1 Goals of the report The aim of this report is to provide a designer with some insights allowing the complexity of large IT systems to be managed. Managing the complexity implies to be both abstract and concrete. Abstract, because a complex problem cannot be faced without abstraction. Concrete, because a cost-effective systems cannot be effectively built without a proper mapping of abstractions into implementations This requires to carefully consider how the fulfilment of domain constraints and non-functional requirements like performance, cost, scalability, availability, configuration and administration depend on design, implementation and technological issues. In the presented approach a software architecture can be designed in several phases, corresponding to more or less abstract views (if you prefer, abstractions levels, though the abuse of the term "level" might be confusing): Problem Architecture, Logical Architecture, Concrete Architecture, Implementation Architecture and Deployment Architecture. This organization borrows some central ideas from the Model Driven Architecture (MDA) approach [1]. In particular the views above roughly correspond to the typical phases of a MDA-like approach. The Problem Architecture view is the result of an analysis focused on the significant aspects of data, activities and information flows from a user perspective. The Logical Architecture view groups activities into logical components. A logical component is a cluster of activities. The activities are classified in several conceptual dimensions and are grouped to ensure a high degree of compactness and insulation in each dimension. The goal is to keep logical components as independent as possible and to minimize their interactions. The Concrete Architecture view specializes logical components and information flows in terms of concrete, but platform-neutral, components and interactions styles. The Implementation Architecture view defines concrete platform-dependent implementations of the concrete components and of their interactions. The Deployment Architecture assigns concrete components to computing nodes. UML2 is used as a communication tool and as a guideline. UML2 is used as a communication language and as a guideline. We exploited SPARX Enterprise Architect 1 as UML modelling tool for drawing the diagrams and testing the concepts. This tool was very important for us in the process of modeling and presenting our approach: it was the right tool for achieving our goals. 1.2 The Software Architecture area As the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a 1 2

3 new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives. This is the software architecture level of design. [2] Software architecture is concerned with system structure - organization of the software, assignment of responsibilities to components, and assurance that interactions among the components satisfy the system requirements [3] Software architecture = {Elements, Forms, Rationale/Constraints}." (originally given by Perry and Wolf, modified by Boehm and reported in [4]) There are many further definitions of software architecture. However, as observed by [5], all authors intend software architecture as the gross, large-scale organization of a software system. As highlighted by [6], every software system has an architecture, although it may not be explicitly modelled. So, even without recognizing a dedicated step on the design phase, the design choices lead to a specific architecture. The key point is to explicitly recognize the concept of software architecture, dedicating to its definition a specific moment on the development process. This is the goal of architectural design, the design process for identifying the subsystems making up a system and the framework for subsystem control and communication [7]. The output of this design process is a description of the software architecture [7], which defines [8]: the main components of a system and the relationships among those components ; the rationale used for the decomposition of the system into its components, and the constraints that must be respected by any design of the components Components and connectors Shaw and Garlan in [9] identify two constitutive elements of any software architecture, components and connectors. In the Software Architecture literature, components are defined as computational entities which encapsulate computations and state. Other areas of Software Engineering, like Component Based Software Engineering, define a component in a more restrictive way, in order to support strongly software reuse according to the construction by composition metaphor (see, for example, [10] and [11]). Clements and Kazman in [11] (Chapter 21) highlights that when used by the software architecture community, the term component is a primitive which describes any collection of coherent computation".. In the following with component we intend a software entity which encapsulates computations and state. It interacts with the external environment through well-defined interfaces an independent unit of deployment: a component can be executed entirely on a single computational node (which satisfies some required computational capabilities). Connectors are entities which represent and manage the interaction among components with a particular interaction protocol. Connectors mediate communication, coordination, or cooperation among components [3]. They are ducts that exchange data or control among components [12]. A connector provides mechanisms which enables communication among components; hence a connector requires some form of agreement among the connected components (for example a shared data representation) [13]. Components and connectors are abstractions, which are primarily used for analysis and design. Components are implemented through well separated entities which keep the encapsulation of computations and state (collections of modules, objects). Connectors are implemented through specific mechanisms (local or remote procedure calls, messages, etc.) that rarely are well separated and encapsulated in discrete entities. Various works (for example [14] and [15]) regards the definition of explicit connectors implemented as first-class entities, which are visible and manageable at run-time. 3

4 1.2.2 Architectural models, views and styles The term software architecture is often referred to the software architecture description. A system architecture is intangible, hence it can be only actually described, modelled, represented. A software architecture can be described by various models, everyone focused on a particular perspective. For example, following [7] we can identify: static structural model that shows the major system components; dynamic process model that shows the process structure of the system; interface model that defines sub-system interfaces; relationships model that shows sub-system relationships. It is also useful to distinguish logical architecture and deployment architecture. The first one describes the system in terms of its conceptual organization, interfaces, and subsystems; the second one describes the system in terms of the allocation of processes to processing units, and the network configuration [16]. These terms must not be amazing: they are different facets of a software architecture, not different architectures". This is the notion of architectural view: a representation of a set of system elements and relations associated with them [17]. [18] highlights their importance analogously to the architecture of a building. As observed by [7] the architectural model of a system may conform to a generic architectural model, called an architecture style: a set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done [3]. [2,3] describe some common styles. [2] observes that an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined". However the allowable kinds of components and connectors are primary discriminators among styles. Selecting the types of constituent parts does not, however, uniquely identify the style. Control disciplines, data organizations, and the interaction of control and data all affect style distinctions" [3] Software Architecture as research area Software architecture is the principled study of the overall structure of software systems, especially the relations among subsystems and components. From its roots in qualitative descriptions of useful system organizations, software architecture has matured to encompass broad explorations of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. [19] According to [8], software architectures became independent subjects of research at beginning of the 90s, developing a specific research area inside Software Engineering (the Software Architecture area). Figure 5 is taken by [20] and highlights its origins ( time spans for phases are suggested by the dates of the work mentioned in the corresponding sections, discounting foundational works from the 1960s and 1970s ). 4

5 Figure 1 Maturation of the software architecture field, from [20] Carnegie Mellon University and Software Engineering Institute are two important references. The seminal work by Shaw and Garlan [9] is an initial systematic study of the field. Some other important lectures, that we have not yet mentioned, with a very important practical impact are [21], [22] and [23]. Finally, a research line regards formal languages for software architectures specification, called Architectural Description Languages (ADL). Through a formal specification it is possible to manage software architectures as formal objects, performing strong analysis and evaluations over them. Shaw and Garlan in [24] and [25] provide a framework for this issue. The Wright language [26] is a significant example, it supports formal specification and verification of components and connector. Other languages like Unicon [27] are implementation-oriented and provide built-in connectors. 1.3 Reference Example The example below will be used as reference in the following. A shop chain has several shops and one central warehouse. Each shop has a local warehouse. The goal is to manage the demand chain. Sold items are recognized at each POS via RFID (or, possibly, via code bar or keyboard). The stocks are managed at three levels: shelf (to notify an operator about the need for replenishment), local shop inventory (to require the delivery of goods from central warehouse to local warehouse), global inventory (to plan purchases or production). Shelf operators fill up shelves whenever the level of a product in a shelf becomes low. When a product level on a shelf becomes low, the need for replenishment must be recognized within a few minutes. Shop managers drive the transfer of products from the central warehouse to the local ones. Products are assumed to be delivered daily from central to local warehouses, therefore the need for supply must be recognized within a few hours. A purchase manager is in charge of planning purchases and generates orders according to central strategies. Decisions about purchases are taken weekly. 5

6 2 Problem Architecture This view of the problem investigates its intrinsic structure by performing a problem analysis under a user perspective. Different communities of researchers and designers look at IT systems from different viewpoints, according to their technological habits and skills (Figure 4.2.1). Communication people focus on hard real-time streaming of data without significant semantic transformation. Computing people focus on algorithms that transform information, possibly with soft real-time constraints. Database people focus on the semi-static storage of information and on complex queries. Though all these viewpoints are by themselves right and co-exist in real-life systems, such technologydriven approaches suffer from several drawbacks. Designers often start from a-priori solutions and devise systems that are biased by specific technological approaches, so that an IT system is primarily conceived either as a communication system or as a HPS (High Performance System) or as a DBMS (Database Management System), whereas complementary aspects are treated as technological commodities. Figure 2 Classical views of information flows Moreover, the emphasis on technological aspects introduces a wide semantic gap between the languages of users and of technicians. Users are not interested in technological solutions. They are interested in information about the real world and in the conceptual aspects of the information. Hence, the identification of the problem architecture focuses on information and information flows which are significant from the user s viewpoint. In this view technicalities and design decisions should be carefully avoided: the main goal is to model the domain by capturing the key elements of the problem. This can be done by answering the following questions: Who actors and information sources and sinks are (roles) What the interesting information is (domain abstractions) How the interesting information is generated, processed and transmitted (activities and information flows) Why activities are triggered 6

7 When activities have to be performed (e.g. elaboration timings) Where actors, sources and sinks are physically and logically located Every question leads to the identification of properties of information and activities. Properties include functional aspects (e.g., what information an activity generates), non-functional aspects (e.g., the average frequency of an activity or the size and quality of some information) and constraints (e.g., the acceptable delay for the completion of a sequence of activities). Properties correspond to dimensions that will be exploited in later phases of the design process to classify problems and provide a conceptual framework for the evaluation of alternative design solutions. The rest of this section answers the basic questions for the reference example. Properties are domain- and problem-specific; though many of them can be exploited in different application domains, the definition of a general model of the properties and of a general meta-model for representing them falls out of the scope of this paper. Several UML formalisms will be used in the following to effectively model properties. Roles, information and information flows are modelled via use case, class and activity diagrams respectively. Nonfunctional properties are mostly modelled via UML stereotyped notes specifying either quantitative or qualitative property values. Designers could devise more synthetic formalisms (e.g., tables) to express properties. The following sections will focus mainly on non-functional aspects that are often neglected during the analysis phase, which typically focuses on functional aspects. Non-functional aspects heavily affect the overall design of a cost-effective architecture, whereas functional aspects are related to the design and implementation of correct and efficient algorithms that are encapsulated inside specific components. 2.1 Who actors are "Who" identifies actors, be they users or devices. Actors participate in use cases where they act either as sources or as sinks of information flows. In the example there are three major use cases (Figure 3) with the corresponding actors: shelf operators fill up shelves whenever the level of a product in a shelf becomes low; shop managers drive the transfer of products from the central warehouse to the local ones; a purchase manager is in charge of planning purchases and generates orders according to central strategies. Points of Sale (POS), be they operators or automatic devices, are involved in all the use cases, as they are the sources of information about sold items. Class diagrams (see Section 2.2) model the flowing information. Input and output events in activity diagrams (see Section 2.3) model interactions among actors and system. 7

8 Figure 3 Who : actors and use cases 2.2 What we are talking about A key aspect of a problem analysis is to identify what we are talking about i.e., relevant data, information and concepts. In Object-oriented analysis (see for example [16]) this aspect is covered by the definition of an appropriate domain model (also called ontology by other research communities), which represents relevant data and information as classes capturing the concepts of interest at different levels of abstraction. Objects i.e., instances of the classes, are run-time images either of physical entities or of abstract concepts that are useful for the application. Figure 4 "What": information classes The abstract class Goods (Figure 4) subsumes information exploited by most activities of the case study: a product, uniquely identified by a product code, and a number of items; for example, ten cans of Coke. Note that individual items of a product are not explicitly modelled because they are not relevant in this problem domain. Product items (e.g., cans of Coke) are undistinguishable: they are not characterized by an individual id, nor they are individually managed. Things may be different, for example, when dealing with 8

9 car selling: in this case each car has an identity e.g., a serial number, and each car is subject to individual management. The semantics of the abstract information modelled by Goods is different for different activities, even if the syntax is similar. Significant properties of the information depend on the semantics; therefore the abstract class Goods is specialized to highlight different meanings, measurement units and properties. For example, the Sold subclass models an instantaneous value i.e., how many items of a product are being currently cashed at a POS. Need models how many items are needed to refurnish a container, be it a shelf or a warehouse (see also Section 2.3). On the opposite, ShelfLevel, ShopLevel and CentralLevel model state information i.e., how many items there are in a container. As highlighted in Figure 4, the subclasses of Goods differ not only because item numbers are expressed by different measurement units, but also because they exhibit different properties and constraints that should be carefully examined because they will be the basis for an effective design of the logical architecture (see Section 3). <<Size>> is a general property of any subclass of Goods, which can be roughly estimated to some tenth of bytes <<Products>> is a relevant domain-specific property, expressing that any instance of Goods deals with exactly one product <<Abstraction>> models the abstraction level of the information. In the case study four abstraction levels can be identified: POS, Shelf, Shop and Central. Such level are domain-specific, but the identification of proper abstraction levels is a key aspect in many domains <<Precision>> defines the required precision of the number attribute for specific subclasses of Goods. Strong means that number of items must be exact, otherwise the allowed error is expressed as a percentage. This is a simple example of QoS (Quality of Service) constraint on the information quality. 2.3 How information flow This question leads to the identification of how information are generated by computational activities and transmitted among activities to generate information flows. An activity is modelled as a behaviour that gets input data (information) and produces output data (information) that are transmitted to other activities. The overall model is essentially data (information) driven. The activity diagram in Figure 5 shows a simplified definition of information and activities for the demand chain example; see Figure 3 for a comparison with the use cases and Figure 4 for the definition of the information classes. A1-A10 denote elementary actions, which in turn (for example, A7) may cause the execution of complex activities Input and output actions (A1, A8, A9, A10) model interactions between system and actors I1-I7 are the significant information, modelled as objects in the object flow <<data store>> denotes information, whose lifetime may overcome the lifetime of the activities exploiting them. An outgoing arrow from a <<data store>> means that the information is red, but not removed. The two-way object flow between A2 and I2 highlights that activity A2 both inspects and updates I2 The most relevant property of the activities is their computational complexity. 9

10 A8 - Fill request A9 - Supply request A10 - Send order I5 :Need I6 :Need I7 :Need A5 - Check shelf level A6 - Check shop level A7 - Plan purchases «property» «data store» I2 :ShelfLevel «data store» I3 :ShopLevel «data store» I4 :CentralLevel «Complexity» {high} A2 - Update shelf level A3 - Update shop level A4 - Update central level «property» A1 - Get sold items I1 :Sold «Complexity» {low} Figure 5 Information flows The diagram shows the overall behaviour of a structured activity for a single execution. The activity can start whenever sold goods are recognized by a POS, performs elementary activities according to data and control flows, and terminates as soon as all the elementary activities have been completed. An execution of the overall activity deals with information that regard only one POS, one product item, one product and one shop warehouse. The diagram focuses on monitoring activities that decrease levels of goods and lead to notifications of needs. The symmetric replenishment, supply and purchase activities, whose effect is to increase levels of goods, are not shown for simplicity. "How" just defines necessary conditions (i.e., the availability of information) for the execution of activities. It does not model "why" and "when" activities are performed (see Sections 2.4 and 2.5). For example, the availability of information I1 is a prerequisite for the execution of activities A2, A3 and A4, but this does not imply that these activities are performed as soon as information I1 becomes available, nor that they are necessarily performed each time an item is sold. 2.4 Why actions are performed Answering the Why question refines the necessary conditions ( How ) by specifying why an activity should be executed, provided that its input data are available. In many cases this is not specified by the Problem Architecture and will be defined by the Concrete Architecture (see Section 4). In other cases Why specifications may arise from user requirements. 10

11 For example, there are not explicit requirements about why action A6 must be executed. On the opposite, the specifications might require that the check shelf level action A5 is performed each time an item is sold; this is represented by a control flow from A2 to A5 (Figure 6). Purchase planning (action A7) should be performed weekly; this can be modelled by an external timing event Week elapsed. Decision nodes above A5, A6 and A7 model why needs are generated. The conditions are purposely left generic; a more detailed analysis should define what need for replenishment and similar conditions mean. This is matter of programming-in-the-small. A naive solution would be to generate a Need whenever the shelf level is below a threshold. The identification of more clever solutions is up to the reader. A8 - Fill request A9 - Supply request A10 - Send order [need for replenishment] [need for supply] [need for order] I5 :Need I6 :Need I7 :Need A5 - Check shelf level A6 - Check shop level A7 - Plan purchases Week elapsed «data store» I2 :ShelfLevel «data store» I3 :ShopLevel «data store» I4 :CentralLevel A2 - Update shelf level A3 - Update shop level A4 - Update central level A1 - Get sold items I1 :Sold Figure 6 Why actions are performed 2.5 When: frequencies and timing constraints Answering the When question implies to identify frequencies and timing constraints. A sound domain analysis should provide an estimate of the average frequency of input and output events. The domain analysis should also identify timing constraints i.e., the maximum allowed delays between input events and corresponding output events. Do not confuse average frequencies and timing constraints: they are separate 11

12 and sometimes orthogonal issues. For example the recognition of an abnormal situation is hopefully a rare input event, but the corresponding output event (an alarm) must be generated with a short delay. This implies reasoning about quantitative non-functional aspects that are often neglected during the analysis phase, which typically focuses on functional aspects. Non-functional aspects heavily affect the overall design of a cost-effective architecture, whereas functional aspects are related to the design and implementation of correct and efficient algorithms that are encapsulated inside specific components. «Frequency» {100/hour} «Frequency» {100/hour} «Frequency» {1/hour} «property» A8 - Fill request «property» A9 - Supply request «property» A10 - Send order «constraint» «constraint» I5 :Need I6 :Need I7 :Need [need for replenishment] A5 - Check shelf level [need for supply] A6 - Check shop level [need for order] A7 - Plan purchases Week elapsed «data store» I2 :ShelfLevel «data store» I3 :ShopLevel «data store» I4 :CentralLevel A2 - Update shelf level A3 - Update shop level A4 - Update central level «Delay» {3 min} I1 :Sold «Delay» {3 hours} «constraint» A1 - Get sold items «constraint» «property» «Frequency» {10/second} Figure 7 - Frequencies and timing constraints Figure 7 refines Figure 6 by highlighting time-related issues. For simplicity decision blocks above A5, A6 and A7 are omitted. The diagram sketches the <<Frequency>> properties of input and output events, which derive from the following rough assumptions aimed at identifying orders of magnitude: The overall system includes 10 shops and 10 POS per shop 12

13 There are 1000 products A POS generates a Sold information every 10 seconds, thus the overall frequency of A1 actions is 10/second Shelves are replenished with amounts of good items that are expected to suffice for 100 hours (roughly a week). A product is assumed to be hosted by one shelf in each shop. The expected frequency of A8 action for shelf and for product is 1/(100 hours), thus the overall frequency of A8 action is (1/(100 hours) * 1000 *10) = 100/hour Shop warehouses host items enough for one week (100 hours). As for A8, the overall frequency of A9 actions is 100/hour Orders are planned within a time horizon of 10 weeks (1000 hours). Therefore the overall frequency of A10 actions is 1/hour. Figure 7 also highlights the acceptable delays between significant events (captured by action A1) and notifications (actions A8, A9 and A10). Note that A8 and A9 actions have the same frequency, but they are subject to very different timing constraints. When a product level on a shelf becomes low, the need for replenishment must be notified (A8) within a few minutes. On the other side products are assumed to be delivered daily from central to local warehouses, so that a supply request (A9) must be notified within a few hours. According to similar remarks, a delay of a few days is compatible with the weekly order planning. 2.6 Where actors are Where the end-points (actors, sensors and devices) of the communication flows are physically located may be a relevant aspect, in particular for large systems in mobile environments. Even in the case study this aspect, sketched in Figure 8, will be of interest in the following steps of the architectural design. Figure 8 Where actors are 13

14 3 Logical Architecture After the problem architecture has been defined by identifying information, activities, information flows and their properties, we must consider how to group activities. This choice turns into the Logical Architecture, which defines clusters of coherent activities called logical components and their interactions. The definition of a logical component should not embed concrete and implementation choices dealing with interaction paradigms, with the internal behaviour of a component and with technological platforms. Such choices are the subject of concrete, implementation and deployment architectures, which will be discusses later. Activities defined by the problem architecture can be grouped in many ways. There is not a recipe for the choice of a good grouping, which is a prerequisite for designing a cost-effective system. This is a major design issue that requires experience and creativity. There is not the right architecture: a designer should choose the best compromise with regard to the most relevant dimensions for a specific domain and problem. What designers usually do is to choose a dominant dimension as a driver and to check the resulting architecture against other dimensions. As we shall exemplify, choosing different dimensions as drivers may lead to dramatically different logical architectures. As usual, this approach fits a fountain process because the relevance of a dimension may emerge at later stages due to implementation or deployment issues that imply a revision of the logical architecture. The next section defines in more detail the concept of dimension and introduces the compactness and insulation criteria as guidelines for characterizing a logical architecture according to the problem dimensions. Then the use of the criteria is discussed through the reference example. 3.1 Definitions Some definitions may be useful for the following discussion. They are not formal definitions; they are just intended to fix a vocabulary for the qualitative reasoning that underlies the definition of logical components. A logical component is a set of activities. Example: Update shelf level and Check shelf level may be (but not necessarily are!) grouped into a logical component An activity is associated with functional and non-functional properties. The association may be either direct or indirect. Examples: Update shelf level is directly associated with the Complexity property. It is indirectly associated with the Precision and Products properties of the ShelfLevel information it exploits A dimension is associated with a property. It defines the set of continue or discrete values of the property and some elementary metrics allowing activities to be characterized in the dimension. Examples: Frequency is a property with continuous values. Complexity is a property with discrete qualitative values e.g. {low, medium, high}. Some additional concepts, which will be exemplified in the following, are not supported by all dimensions; in particular, the ordering among values and the distance among values The following definitions, which will be exemplified later through the reference case study, apply to logical components i.e., clusters of activities: The projection of a logical component over a dimension is the set of property values of its activities in that dimension The spread of a component over a dimension is a quantitative estimate of how its projection over that dimension is spread The intersection of two logical components over a dimension is the intersection of their projections The overlap of a component over a dimension is the union of its intersections with other components The interference of a component over a dimension is a quantitative estimate of its overlap on that dimension 14

15 The footprint of a logical component is the set of its spreads and interferences on the problem dimensions, provided that the estimates of both spreads and interferences are somehow quantified according to a uniform scale. 3.2 Compactness and insulation The above definitions support the identification of two basic criteria the definition of coherent components. A logical component should be compact and insulated. Compactness means that the spreads of a component over all the dimensions should be small. This is another way of stating the classical principle of separation of concerns: a component should include activities that are homogeneous in the problem dimensions. For example, the activities of a component should deal with a limited number of object types at the same level of abstraction. They should also have similar complexity and timing constraints, so that different components can rely on the technological platforms that best fit their requirements. Low compactness would lead to a monolithic architecture or, at best, to heavy interdependencies among concrete components, significant overhead and, ultimately, poor software design. Insulation means that the interferences of a component over all the dimensions should be small. This is relevant, in particular, for the dimensions that deal with the what question. In other terms, information flows and information sharing among components should be kept as low as possible. This minimizes communication overheads and provides a high degree of flexibility with regard to distribution. Compactness and insulation criteria can be summarized by stating that the footprint of a component should be as small as possible. Compactness and insulation are neither binary nor quantitative properties. They will be used in the following with an intuitive and qualitative meaning. If these terms could be defined in a precise and quantitative way, the problem would turn into an optimization problem: both footprints and footprint overlaps should be minimized. More precisely, it is an optimization with constraints problems: components must be as compact and insulated as possible, provided that the constraints are fulfilled. Compactness and insulation should be evaluated by having in mind the distinction between component type and component instance. A logical component (component type) defines a behaviour, but there may be several concurrent executions of the same behaviour (component instances). This leads to the concept of component multiplicity. Concrete, implementation and deployment architectures define how this can be realized. In terms of logical architecture, compactness is a structural issue that does not depend on the component multiplicity. On the opposite, insulation is a dynamic issue that depends on the multiplicity, because different instances of the same component might heavily interact, thus leading to a low insulation. If it seems not possible to define logical component with high compactness and insulation, there are two extreme cases. Either the analysis is poor, and you have to go back to the Problem Architecture; or the problem includes activities that intrinsically have low compactness and insulation. In this case the problem is intrinsically hard. In most practical cases, as we shall exemplify in the following, it is difficult to identify components that are highly compact and insulated over all the problem dimensions. A component might be spread on some dimensions, provided that its overall footprint is reasonably small. This may lead to alternative solutions, which can be compared at later stages of the overall fountain process. Finally, a logical component exhibits logical properties that derive from the properties of the activities it includes. A logical property is often the worst case of the properties associated with the component activities: for example, if a component includes at least one activity with high complexity, the overall complexity of the component is high. Logical properties play an essential role in later stages of the design process (concrete, implementation and deployment architectures), but they mainly affect dimensioning and scaling aspects that are not the most relevant ones for the definition of the logical architecture. 15

16 3.3 Horizontal partitioning Goods-driven partitioning A straightforward partitioning is goods-driven : a logical component groups all the activities to be executed as consequence of goods being sold. Figure 9 Horizontal, goods-driven partitioning Partition Goods driven in Figure 9 models such a component, where control and information flows are slightly rearranged to highlight that the concurrent activities of Figure 6 can be reduced to a unique sequential activity. The assumption is that a shop level update (A3) is performed only whenever shelf replenishment is needed, and a central level update (A4) is performed only whenever a shop supply is needed. Such assumptions are coherent with the precision and timing constraints (see Figure 4 and Figure 7). 16

17 Though this partitioning may seem obvious (there is only one logical component), it deserves some remarks. A logical component specifies a behaviour that is activated whenever action A1 is executed i.e., some goods are sold. This means that many instances of the same logical component can be simultaneously active. Concrete, implementation and deployment architectures define how this can be realized; at the logical level, it can be assumed that there are no limitations on the multiplicity of component instances, as highlighted by the <<Multiplicity>> property in Figure 9. Ultimately, the system can be viewed as a collection of logical components (more precisely, component instances) with the same structure and at the same level of the architecture; this is why this partitioning style, that can be exploited in many application domains, can be denoted as horizontal partitioning. Information I2, I3 and I4 are purposely kept out of the partition because they do not belong to a specific instance of the component. In fact such information are long-lived and are exploited by many component instances. This, together with the multiplicity of a component, is a relevant aspect when discussing compactness and insulation criteria Projections and overlaps This section sketches projections and intersections of the Goods driven component on several relevant problem dimensions. Projections and intersections of the component are described by stereotyped notes on the right side of the Goods driven partition in Figure 9. The projections of the component over significant dimensions are discussed first. In many cases the discussion may look obvious, because the partitioning is trivial: there is only one component type. However, this straightforward example will help the discussion of more complex situations. <<Goods>>: the component (more precisely, an instance of the component) deals with only one instance of Goods. This is a good example of separation of concerns, which can be expected to lead to simple and modular code <<Abstraction>>: the component deals with all the abstraction levels of the information (shelf, shop, central) <<Complexity>>: the component includes all the activities, thus all their degrees of complexity <<Frequency>>: as above <<Delay>>: as above <<Location>>: as above. Recall that the dimensions we are considering deal with problem properties. Therefore they model aspects that are significant from the user viewpoint. For example, <<Frequency>> is the projection of the component properties on the frequency dimension, which models the frequency of interactions with the environment (actions A1, A8, A9, A10). <<Location>> is the projection on the location dimension, which models the locations of the actors (see Figure 8). Other dimensions deal with the intersections of the component and are slightly less obvious. They primarily deal with the dynamic behaviour of the component: <<Extra Flows>> models the intensity of information flows between the component and the external environment i.e., the actors. There is only one component type, which obviously interact with all the actors; therefore the intersection is high <<Intra Flows>> models the intensity of the information flows with other components (more precisely, with other component instances). In the example there are no flows among instances of the (unique) component <<Sharing>> models the intensity of the sharing of (typically persistent) information with other component instances. The last point deserves some discussion. Shared information is modelled by I2, I3 and I4 in Figure 9. It might seem that all the instances of the component share all the information. However, what is meaningful in 17

18 terms of performance is the probability that two component instances conflict for the same information at the same time. Shared information, modelled by subclasses of Goods (Figure 4), are related to individual products. On the other side, a component instance deals with one product only. Therefore, if the number of component instances is significantly less than the number of products, the sharing degree (i.e., the overlap of the component with other components on the <<Sharing>> dimension) can be expected to be not very high Footprint In order to provide a synthetic and impressive view of compactness and insulation, projections and overlaps should be somehow quantified in terms of spreads and interferences. The quantification is still a subjective issue: both spread and interference are quantified in a scale ranging from 0 to 100, by assuming that 10 means the smallest possible spread and 100 means the largest possible spread. For example, the spread for <<Goods>> is 10 (only one good); the spread for <<Abstraction>> is 100 (all the possible abstractions). The value 0 means meaningless, typically because the property has a null or undefined value: for example, the interference for <<Intra Flows>> is 0 because there are no intra flows. Table 1 summarizes the estimates and Figure 10 is a Kiviat chart providing an intuitive view of the overall component footprint. Goods 10 Abstraction 100 Complexity 100 Frequency 100 Delay 100 Locations 100 Extra Flows 100 Intra Flows 0 Sharing 40 Table 1 Goods driven spreads and interferences Goods 100 Sharing Abstraction Intra Flows 20 0 Complexity Extra Flows Frequency Locations Delay Figure 10 Goods driven footprint 18

19 3.4 Vertical partitioning Abstraction-driven partitioning An alternative partitioning criterion is abstraction-driven: a component groups all the activities that correspond to a well-distinguished level of abstraction of the information (see What in Figure 4), namely POS, Shelf, Shop and Central level. This partitioning style, that can be exploited in many application domains, can be denoted as vertical partitioning. The resulting partitioning is shown in Figure 11, where the POS partition is highlighted for completeness (it just includes the capture of sold items at a POS). For the moment, as for horizontal partitioning, there is no limit on the multiplicity of the components. Figure 11 Vertical abstraction driven partitioning Projections and overlaps This section sketches projections and intersections of the abstraction driven components on several relevant problem dimensions. Projections and intersections of the component are described by stereotyped notes on top of the partitions in Figure 11. The POS component is straightforward and is not discussed for shortness. In the following projections and intersections for the Shelf logical component are examined in detail. Similar remarks apply to the other components. 19

20 <<Goods>>: the input for Shelf is I1, generated by POS components at a frequency of 10/second. Fill requests are generated by Shelf components at a lower frequency (100/hour). Depending on the concrete architecture of Shelf, on the deployment architecture and on the features of the communication subsystem, it might happen that a Shelf instance must concurrently manage several Goods <<Abstraction>>: the spread is minimal, because a component defined according to the abstractiondriven strategy by definition deals with only one abstraction level of the information <<Complexity>>: a component has a well distinguished level of complexity, therefore the spread is minimal. For example, the Shelf component includes activities with low complexity only, whereas the Central component includes activities with high complexity <<Frequency>>: as above <<Delay>>: as above <<Location>>: the component interacts with actors that can be located at any shop. Dimensions dealing with the intersections of the component: <<Extra Flows>>: each component interacts with only one actor type, which is multi-instantiated (one or more Shelf managers for each shop) <<Intra Flows>>: each component interacts with the component at the level above and with the one at the level below <<Sharing>> interference is low because a Shelf instance only shares I2 information with other instances of Shelf itself, if any Footprints Table 2 summarizes the estimates for the abstraction driven Shelf component and Figure 12 is a Kiviat chart providing an intuitive view of the overall component footprint. Estimates and footprints for the other abstraction driven components are very similar and are left to the reader. Goods 50 Abstraction 10 Complexity 10 Frequency 10 Delay 10 Locations 90 Extra Flows 50 Intra Flows 50 Sharing 30 Table 2 Abstraction driven Shelf spreads and interferences 20

21 Sharing Goods Abstraction Intra Flows 20 0 Complexity Extra Flows Frequency Locations Delay Figure 12 Abstraction driven Shelf footprint 3.5 Discussion In general, the footprint of an optimal partitioning should have a very small area, as both spread and interference on each dimension should be small to ensure compactness and insulation respectively. An immediate remark is that the goods driven horizontal partitioning has several highlights together with several lowlights. The abstraction driven vertical partitioning looks somehow better. Of course, the area of the footprint has just a qualitative meaning; the axes of the chart do not correspond to absolute values of logical properties and cannot be directly interpreted as cost indicators. They just provide estimates of compactness and insulation, which are rough indicators of the goodness of basic architectural choices. A more precise evaluation of the cost-effectiveness of a solution relies on a quantification of the costs for each dimension, which unavoidably requires to go through the further stages of the architectural design. However, diagrams like the ones in Figure 10 and Figure 12 can provide preliminary, but meaningful, hints at this stage. If compared with similar diagrams related to different partitioning criteria, they can help avoiding metaphysical discussion about the best solution. At the logical stage what is relevant is the coherency of the overall partitioning, which is expressed by qualitative indicators like spread and interference. As pointed out in Section 3.2, the indicators could be quantified and exploited at subsequent stages of the design process to better estimate the costs. A comparison of the footprints in the two cases above suggests some remarks. Though the discussion is related to the case study and to some particular choices, the two architectures rely on two partitioning criteria the horizontal and the vertical one that can be easily applied in other domains. Horizontal partitioning lead to a monolithic component that is poor in terms of compactness. Moreover the component interacts with distributed actors; this may imply high communication costs and increases the criticality of the communication subsystem. On the other side, the unique component has a simple internal structure and can be easily replicated in multiple instances. Intra-flows are negligible, therefore the number of instances may be increased without producing significant communication overhead. This leads to a high degree of scale-ability. The typical scenario, as we shall discuss later, is that of a large server farm, which can be cost-effective if communications are cheap and highly available. The vertical partitioning criterion leads to a good level of compactness in terms of data abstraction, complexity and timing. These dimensions are in some sense isomorphic: more abstract activities have less 21

22 critical timing requirements, lower frequency and higher complexity. This is a frequent situation in many real life systems and, in particular, in monitoring and control systems. It can be anticipated that vertical partitioning is a good basis for vertical scale-ability and for distribution even on heterogeneous platforms, as it leads to components that are internally coherent and have different complexity and timing constraints. However, pure vertical partitioning is not the silver bullet. Layering and distribution can imply higher costs in term of underlying platform, software structure, communication mechanisms and deployment. There are three different components to be coherently developed and maintained; this can lead to non trivial versioning and deployment problems. The spreads on the <<Locations>>, <<Extra Flows>> and <<Sharing>> dimensions suggest that the internal structure and the communication activities of a component could become expensive in terms of both development and overhead. 3.6 Multi-dimensional partitioning More effective solutions can be achieved if several dimensions drive the partitioning. For example, using both abstraction and location as drivers leads to the logical architecture shown in Figure 13. Figure 13 Abstraction and location-driven partitioning Abstraction-driven partitions are in turn partitioned according to locations. This choice has major implications on some dimensions: <<Multiplicity>>: a component at a given level of abstraction manages information dealing with containers of goods i.e., shelves, shops and central warehouse, which are under the responsibility of 22

23 actors at specific locations. It is reasonable (though not necessary) to assume that the multiplicity of a component coincides with the multiplicity of the container it deals with. Thus there might be one instance of Shelf per shelf, one instance of Shop per shop and one instance of Central <<Location>>: an instance of Shelf interacts with actor(s) at that shelf only. The same holds for instances of Shop and Central <<Sharing>>: an instance of Shelf manages I2 information that are related to that shelf only, so that there is no interference due to sharing among instances of Shelf. The same holds for instances of Shop. The resulting spreads, interferences and footprint for Shelf are shown in Table 3 and Figure 14 respectively. Goods 50 Abstraction 10 Complexity 10 Frequency 10 Delay 10 Locations 10 Extra Flows 50 Intra Flows 50 Sharing 10 Table 3 Abstraction-location driven Shelf spreads and interferences Goods 100 Sharing Abstraction Intra Flows 20 0 Complexity Extra Flows Frequency Locations Delay Figure 14 Abstraction-location driven footprint The result is a logical architecture that paves the way to a high degree of distribution. Shelf and Shop component instances can be decentralized. Critical timing constraints are up to components that can be deployed on peripheral computing nodes, thus reducing communication costs and criticalities of the communication subsystem. On the opposite, complex but not time-critical computations like order planning are up to a component that can be hosted by a high-performance computing node. Finally, note that horizontal and vertical partitioning can be combined. In particular, each layer deriving from vertical partitioning is subject to horizontal partitioning in order to improve scalability. Other partitioning criteria are aimed at ensuring compactness and insulation in other dimensions like: 23

24 Geographical location, according to communication facilities (ad-hoc net-works, etc.); Organizational space, according to EAI (Enterprise Application Integration) and security issues; Architectural space, according to the presence of specialized processors; Personal space for nomadic users with local working environments; Product types, if different products are managed with different strategies. 24

25 4 Concrete Architecture The Concrete Architecture aims to reify the Logical Architecture. As stated in the subsection 1.2.1, with component we intend, coherently with the Software Architecture perspective, a computational entity which encapsulates computations and state, with well-defined interfaces, and which is an independent unit of deployment. The Logical Architecture defines components in a logical perspective, in fact it prescribes: what the system components are, by specifying their responsibilities in terms of the actions (activities) they must perform; what the interactions among components are in terms of information flows. The Concrete Architecture reifies the logical components, considering: how information flows are reified in terms of concrete interaction styles; the internal design of the components: what is the software organization which reifies the actions (activities) that have to be performed. Hence in this view we talk about concrete components. A concrete component is a design reification of a logical component. Moreover with concrete object we intend a well encapsulated data structure, which is typically managed by concrete components. A concrete architecture is the set of concrete components specifications, which show the reification of the interactions among components and their internal design. 4.1 Interaction styles A logical information flow can be reified according to various concrete interaction styles. With concrete interaction style we intend an interaction protocol like local and remote procedure calls, messages, and so on. In other words, according to the terminology of subsection 1.2.1, the reification of an information flow consists in choosing one specific connector type. [12] presents some common connector types. In the following some basic styles are discussed. The diagram in Figure 15 shows a generic information flow between two activities, A and B. According to the UML2 semantics, the diagram highlights a one-way flow of some information (represented by the conceptual Information object) from A to B. The transferred information is typically exploited by B to execute some operation. Suppose that A is reified by a concrete component CA (source), B by a concrete component CB (sink) and the Information by one or more concrete objects. There are two basic stiles to reify a logical flow: asynchronous messages and procedure calls. 25

26 A :Information B Information «use» «use» CA CB + execute(information) : void + send(information) : void + call(information) : Result «use» «use» Result Figure 15 A generic information flow The asynchronous interaction style (Figure 16) is often called non-blocking, because A can generate the information and continue its execution without waiting for any return information from B. In the sequence diagram of Figure 16 CB exposes a send() operation allowing other components (e.g., CA) to deliver information to CB. The send() operation turns into an asynchronous message. After sending the message, CA is not blocked. After receiving the message CB will eventually execute some operation exploiting the received information. This is the most natural interaction style for distributed systems, because basic communication platforms (e.g., TCP/IP) support one-way, asynchronous information transfer. :CA :CB send(information) execute(information) Figure 16 - Asynchronous interaction The other basic interaction style is the synchronous one, which derives from the classic procedure call mechanism. As shown in Figure 17, CA calls CB and waits until CB executes some operation and returns a result. This is the most natural interaction style for non-distributed system, which rely on programming paradigms supporting procedure calls. 26

27 :CA :CB call(information) :Result return(result) execute(information) Figure 17 - Synchronous interaction Though things look simple, a more carefully examination shows that they are in fact complicated. One should not confuse different abstraction levels: in particular, one should carefully separate the concrete styles of interaction, which depend on user requirements and on domain constraints, from the interaction mechanisms that are supported by the underlying implementation platforms. The basic styles sketched in Figure 16 and Figure 17 do not clearly separate data and control flows. In the synchronous style the two flows coincide. In the asynchronous style the data flow only is specified, because the two components are implicitly assumed to have independent threads and there are no assumptions about why and when CB executes its operation. The asynchronous style implies that there is some buffering mechanism unless we accept either that the send() operation become blocking, or that data can be lost. In both cases CA must somehow know CB. This may be obvious in a non-distributed system turning into a monolithic, single-language application, but it is less obvious in a distributed system Control flows In this section we discuss how synchronous and asynchronous control flows can be realized by exploiting the underlying platform mechanisms. Note that also the basic platform mechanisms may be either synchronous or asynchronous; however, as pointed out before, any concrete interaction style, defined according to domain requirements, can be realized by relying on any platform mechanism. We do not deal here with information flows, which will be discussed in the next section. Therefore we shall use pure events (also called signals) i.e., empty messages, and parameter-less procedures. CT2 CE2 + sendevent() : void + execute() : void 27

28 :CT2 :CE2 sendevent() execute() Figure 18 - Asynchronous control based on asynchronous mechanisms Figure 18 shows how asynchronous control can be realized by relying on asynchronous platform mechanisms. CT2 (the Trigger) is in charge of triggering the execution of an operation of CE2 (the Executor), thus realizing the Why concept. Both CT2 and CE2 are assumed to have independent threads. A significant case is that of a Timer which plays the role of Trigger. This allows the Executor operations to be triggered at a fixed rate. Alternatively, the Executor itself can set the Timer, for example via a sleep() operation. Note that the scheme shown in Figure 18 does not suffice to exactly state When the operation will be executed. In fact, the control event is just a necessary condition for the execution of the operation, which will be actually performed at some later time instant. Somebody (a Strategist) exploits some activation strategy to trigger the execution of the operation. There are two basic possibilities: The When issue is not relevant for the application domain. In this case, the underlying kernel plays the role of Strategist. This means that the application has little or no control on When the operation is executed. The Strategist is an application component. In this case the application explicitly controls When operations are executed, provided that the underlying kernel provides suitable mechanisms for controlling the execution of the operations in a deterministic way. In practice, there are several solutions depending on the underlying platform. For example, the use of priorities, even if this does not ensure precise timings. For the moment we assume that the CE2 operation is executed with a delay which is negligible if compared against the timing constraints of the application domain. Figure 19 shows how asynchronous control can be based on synchronous mechanisms. CT3 CE3 + notifyevent() : void + execute() : void 28

29 :CT3 :CE3 notifyevent() execute() Figure 19 - Asynchronous control based on synchronous mechanism CE3 exposes a synchronous notifyevent() operation, that is invoked by CT3. In order to emulate an asynchronous interaction style, the execution of the operation should be as short as possible. Therefore it just stores the event and returns. After that, the behaviour of both CT3 and CE3 is similar to the behaviour of CT2 and CE2 in Figure 18, if CE3 ensures that the operation is executed as soon as possible after the event notification. When related issues are similar to the previous ones, including the role of the Strategist. Figure 20 shows how synchronous control can be based on synchronous mechanisms. This is the typical situation of a local procedure invocation, though the procedure invocation is used just to control the execution of an operation of CE4, not to transfer information, as we shall discuss later. CT4 CE4 + notifyevent() : void + execute() : void :CT4 :CE4 notifyevent() execute() Figure 20 - Synchronous control based on synchronous mechanism Finally, Figure 21 shows how synchronous control can be based on asynchronous mechanisms. This is the typical situation of a remote procedure invocation. Again, it is used just to control the execution of the operation. 29

30 CT5 + notifycompletion() : void CE5 + notifyevent() : void + execute() : void :CT5 :CE5 notifyevent() execute() notifycompletion() Figure 21 - Synchronous control based on asynchronous mechanism Information flows Let us consider now the information transfer issue. We assume that the information is provided by one or more Source components, which do not coincide with the Trigger component we discussed above. In general, an Executor can execute an operation if it has been triggered by a control event and the proper information is available. Therefore the interaction fragments that will be shown in this section must be executed as a prologue to the execution of the requested operation. We shall also provide some significant examples of how control and information transfer styles can be combined. Figure 22 shows a push information transfer style based on an asynchronous communication mechanism. CS6 is a component that plays the role of information Source, CE6 is an Executor. CE6 CS6 + pushinfo(information) : void :CE6 :CS6 pushinfo(information) 30

31 Figure 22 - Push information transfer (asynchronous) Figure 23 exemplifies how the asynchronous control interaction style of Figure 18 and the asynchronous information push style of Figure 22 can be combined. In the example the CTS7 component plays both roles of Source and of Trigger. It should be clear that pushinfo(information) and sendevent() can be easiy combined into a unique message, which is both a control event and an information carrier. This leads to the widespread situation of messages that both carry information and act as triggers for the execution of actions; however, this should be viewed as a particular, though frequent, case. Control async async::ct2 Info push::cs6 Control async async:: CE2 Info push::ce6 + sendevent() : void + execute() : void + pushinfo(information) : void CTS7 CE7 ::CE2 + sendevent() : void + execute() : void ::CE6 + pushinfo(information) : void :CTS7 :CE7 pushinfo(information) sendevent() execute() Figure 23 - Combining asynchronous control and asynchronous information push Figure 24 shows a pull information transfer style based on a synchronous communication mechanism. CS8 is a component that plays the role of information Source, CE8 is an Executor. CE8 CS8 + pullinfo() : Information 31

32 :CE8 :CS8 pullinfo() :Information Figure 24 Pull information transfer (synchronous) An interesting situation arises from the combination of the asynchronous control style in Figure 18 and of the synchronous pull information transfer style of Figure 24. Trigger and Source are different components. For example, the Source might be an application component which asynchronously asks the Executor for an operation requiring information from a peripheral Source component, that is synchronously polled by the Executor. Control async async:: CE2 Info pull::ce8 + sendevent() : void + execute() : void Control async async::ct2 CE9 ::CE2 + sendevent() : void + execute() : void Info pull::cs8 + pullinfo() : Information :CT2 :CE9 :CS8 sendevent() pullinfo() :Information execute() Figure 25 - Combining asynchronous control and synchronous pull information transfer 4.2 Components design The other relevant issue at the concrete architecture level is the internal design of the components: what is the software organization which reifies the actions (activities) that have to be performed. As one may expect, the internal design of a component is tightly related with the styles of its interactions with other components. 32

33 interaction. In the following we assume that a concrete component that plays the role of Executor defines a protected execute() method, which implements the actions of the component. A first distinction is between passive and active components. A passive component (Executor) is executed in the thread of the invoker (Source); accordingly, a passive component exposes a synchronous doexecute() operation. This is the case of a local procedure invocation. An active component has an autonomous execution thread; this is unavoidable in case of a distributed system. A second distinction is between stateless and stateful components. A stateless component does not preserve a significant internal status between two invocation i.e., it behaves as a pure functional component. A stateful component has an internal status which is preserved across invocations i.e., it behaves as a state machine. As sketched in Figure 26, the possibilities deriving from the two basic classifications above can be combined. ConcreteComponent # execute() PassiveComponent ActiveComponent StatelessComponent StatefulComponent ::ConcreteComponent # execute() «sync» + doexecute() ::ConcreteComponent # execute() «async» + sendmessage() ::ConcreteComponent # execute() - status ::ConcreteComponent # execute() PassiveStateless ::ConcreteComponent # execute() «sync» ::PassiveComponent + doexecute() PassiveStateful ::StatefulComponent - status ::ConcreteComponent # execute() «sync» ::PassiveComponent + doexecute() ActiveStateless ::ConcreteComponent # execute() «async» ::ActiveComponent + sendmessage() ActiveStateful ::StatefulComponent - status ::ConcreteComponent # execute() «async» ::ActiveComponent + sendmessage() Figure 26 - Classification of concrete components Behaviour of active stateless components In the following we discuss some basic behaviours of stateless components i.e., pure functional components. We refer to active components and to an elementary, but widespread, situation: asynchronous control and asynchronous push information flows, where control and information flow coincide. In other terms, the interaction turns into asynchronous messages that both carry information and trigger the activity of the receiver. Accordingly, an active component exposes an asynchronous sendmessage() operation. The 33

34 behaviour of passive components is straightforward, as it turns into a synchronous procedure call. The extension to other interaction styles is left to the reader. ActivityInitial new message reception execute (::) messages delivery ActivityFinal Figure 27 - One-shot executor Figure 27 shows a one-shot executor which is newly created whenever needed, gets a message, executes its actions, deliver messages (if needed) to other components and terminates. This the case, for example, of a (possibly remote) fork() in a Unix-like environment. Note that the invocation is asynchronous, therefore the source continues its execution while the executor performs its actions (Figure 28). Different sources may dynamically create different instances of the executor, which are concurrently executed in arbitrary order. S1 :ConcreteComponent S2 :ConcreteComponent sendmessage() E1 :OneShotStateless sendmessage() E2 :OneShotStateless execute() execute() Figure 28 One-shot interactions The one-shot solution is suitable if the activity of the executor is seldom required and if the creation of a new executor does not imply too much overhead in comparison with the duration of the activity it performs. In other cases (for example, an executor which performs short activities, is frequently invoked and is hosted on a remote node) the sequential executor of Figure 29 is more suitable. The executor is create once and for all. It cyclically waits for request messages, then sequentially executes the activity. ActivityInitial message reception execute (::) messages delivery Figure 29 - Sequential executor 34

35 Figure 30 shows that, in this case, different sources may rely on a unique instance of executor, but their requests are sequenced (this implies some kind of message buffering in the interaction style). S1 :ConcreteComponent S2 :ConcreteComponent E1 :SequentialStateless sendmessage() execute() sendmessage() execute() Figure 30 - Sequential interaction This drawback can be overcome by exploiting a concurrent executor (Figure 31). A main thread is created once, loops waiting for messages and starts a new execution thread each time a message is received. Note that this is different from the one shot solution, which typically involves the creation of a new process for each received message. Instead, a concurrent executor can be instantiated once an for all and internally activates a new thread for each received message, then waits for another message. This allows activities triggered by different messages to be concurrently executed (Figure 32) with little overhead (compare Figure 28 with Figure 32), though the executor has a more complex internal structure and concurrent execution threads are bound to be hosted by the same process (thus by the same computing node). ActivityInitial message reception execute (::) messages delivery FlowFinal Figure 31 - Concurrent executor 35

36 C1:Concurrent Stateless Component S1 :ConcreteComponent S2 :ConcreteComponent Main: :ConcurrentStateless sendmessage() start() :LocalThread sendmessage() start() :LocalThread execute() execute() Figure 32 - Concurrent interaction Both one-shot and concurrent executors support the concurrent execution of activities; this can be mandatory if the computational activity has unpredictable, and possibly long, duration. The one-shot solution supports distributed computing, provided that a remote fork() is supported by the underlying platform; its major drawback is that it implies a high overhead, in particular in case of remote fork(), because a new message implies the creation of a new process. On the other side, the concurrent executor implies only the limited overhead of starting a new thread, but all the threads are co-resident inside the same process so that distributed computation (thus real concurrency) can be hardly supported. A reasonable and widespread solution is provided by a farm approach. A farm manager, which once and for all instantiates a set of sequential executors, possibly hosted by different computing nodes, and delivers an incoming massage to a free sequential executor, if any. The farm executor (Figure 33) is in charge of initializing a pool of sequential executor. Then it waits for an incoming message and redirects it to an available sequential executor, if any. If needed, the farm executor enqueues incoming messages. Individual executors may be usual sequential executors and are not highlighted in Figure 33. message reception message enqueuing (::) ActivityInitial executors start-up «centralbuffer» MessageQueue avalable executor message redirection Figure 33 - Farm manager, anonymous stateless executors 36

37 Figure 34 exemplifies an interaction sequence for a farm manager. It assumes that executors interact with the manager in synchronous pull style to get messages from the message queue, which is possibly the simplest solution to implicitly notify the manager that an executor is available. The figure also shows that there is no relationship between what source generates messages and which executor exploits them. As we shall discuss in the next section, this holds in case of stateless executors only. In this case, executors are anonymous i.e., it does not matter who sends a request message nor what executor executes the corresponding action. S1 :ConcreteComponent S2 :ConcreteComponent :FarmManager create() E1 :FarmExecutor create() E2 :FarmExecutor sendmessage() enqueuemessage() getmessage() execute() sendmessage() enqueuemessage() getmessage() sendmessage() enqueuemessage() getmessage() execute() execute() Figure 34 - Farm interaction The farm scheme is especially suitable in case of a server farm, consisting of a set of identical computing nodes each executing the same stateless components. The straightforward interaction scheme of Figure 34 ensures automatic load balancing because, as soon a node terminates an activity, the executor it hosts gets the next available message Behaviour of stateful components Stateful components have an internal status. In particular, stateful executors preserve a status through a sequence of request messages. This, for example, the case of a classical shop cart, where a message means that the customer added an item to the cart and the overall content of the cart must remain stored. In more 37

38 complex cases, for example an electronic payment, the current state of the executor determines what messages can be accepted and how the executor reacts to an incoming message by executing a proper action. This implies that executors are no more anonymous: once a source started an interaction sequence, all the message from that source must be delivered to the same executor which, of course, must keep alive until the sequence terminates. Therefore incoming messages must be somehow tagged wither with information allowing (e.g., who the source is) allowing the message to be delivered to the proper executor. In communication parlance, this means that the system must manage sessions between sources and executors. In database parlance, this means that the system must manage long-lived transactions. Such remarks apply, in general, to all the types of asynchronous executors discussed in the previous section. In particular, we discuss the case of a farm execution scheme. Structure and behaviour of a simple stateful sequential executor that gets messages in synchronous pull mode are sketched in Figure 35. The executor embeds the representation of states and transitions and has a current state defining how it reacts to incoming messages. Complex stateful behaviours would be better modelled via state diagrams. transition FarmExecutor FarmStatefulExecutor # init() # execute1() # execute2() # setstate() current 0..* 2..* 1 State :State ActivityInitial «pull» initial message init (::) «pull» message execute1 (::) «pull» message excute2 (::) messages delivery Figure 35 - Stateful sequential executor The interaction diagram in Figure 36 presents the pattern of how a source, a manager and a stateful executor interact in a farm scheme after a an interaction sequence (i.e., a session) has been set up. The diagram shows operation parameters and returned values, to highlight what information must be provided by the components and exploited by the manager to properly deliver the messages. The detailed definition of FarmStatefulManager is a refinement of Figure 33 and is left to the reader. 38

39 source :ConcreteComponent manager :FarmStatefulManager executor :FarmStatefulExecutor sendmessage(message, source) enqueuemessage(message,executor) getmessage(executor) :Message execute() setstate() Figure 36 - Interaction farm pattern with stateful executors The interaction diagram in Figure 37 exemplifies how two sources interact with two stateful executors in a farm scheme. For simplicity, the initial instantiation of the executors (see Figure 34) is omitted. The internal setstate actions of the executors are also omitted. Recall that an interaction diagram is just an example of the many possible interaction sequence that could arise: how the operation of the executors interleave depends on the load of executing nodes, on the strategies of the OSs, on network traffic, on the reactivity of the human users and so on. In comparison with the stateless situation of Figure 34, note that the FarmStatefulManager is in charge of ensuring that, after an executor has been assigned to a new session started on behalf of an initial message from a source, all the messages from the same source must be delivered to the same executor. This can be done, for example, by managing a message queue for each executor. 39

40 S1 :ConcreteComponent S2 :ConcreteComponent M1 :FarmStatefulManager E1 :FarmStatefulExecutor E2 :FarmStatefulExecutor sendmessage(initial1, S1) getmessage(e1) :initial1 sendmessage(m1.1, S1) sendmessage(initial2, S2) getmessage(e2) :initial2 sendmessage(m2, 1, S2) getmessage(e2) :m2.1 execute1() getmessage(e1) :m1.1 execute1() sendmessage(m2.2, S2) sendmessage(m1.2, S1) getmessage(e1) :m1.2 getmessage(e2) :m2.2 execute2() execute2() Figure 37 Farm interaction with stateful executors Context-sensitive components Till now we assumed the behaviour of a component depends on incoming information only i.e., components are context-free. State information, if any, is embedded inside the components. In many cases components rely also on a context i.e., long-lived information, hosted by a data store (usually a database), whose lifetime overcomes the execution of actions (in case of stateless executors) and of sessions (in case of stateful executors). In general, several components share and manipulate context information (Figure 38). 40

41 ConcreteComponent ContetSensitiveComponent 1..* exploits 1..* «data store» Context + getinfo() + putinfo() Figure 38 - Context-sensitive component One can rely on a persistent context to manage the concept of session by overcoming the difficulties arising from the management of stateful components. It suffices that the state information that defines the evolution of a session (or, if you prefer, of a long-lived transaction) is stored as a private context (typically inside a database). Therefore executors are no more responsible for preserving the session state and can be stateless and it is possible to rely again on the basic farm scheme of Figure Discussion Combining the patterns The concrete patterns presented in the previous sections can be combined in several ways, leading to a wide range of concrete architectures. In particular, the basic concrete interaction styles presented in Section 4.1 are building blocks allowing more complex concrete interaction styles to be built. A major design problem is to choose the most cost-effective architecture for the domain at hand. Example - in a business-oriented three-tier architecture, the business logic usually reacts to user requests, performs computations and perform queries and updates a central database. Typically the business logic interleaves user interactions, computations and database operations. It is easy to recognize that such architecture combines patterns in the most complicated way. The business logic consists of components which are stateful, as they maintain a state across the steps of long-lived transactions; have a private data-store, as they maintain local data; have a shared data-store i.e., the database. Information and states are everywhere: inside the components, inside local data-store, inside the shared datastore and often - even worse- inside the presentation layer. Sometimes it works, but the overall architecture is complex and does not encourage a proper separation of concerns. This, on one side, increases development and maintenance cost. On the other side, scalability can be hardly achieved. In many cases the concrete architecture can be designed by exploiting in a consistent way a limited number of patterns. This increases modularity and scalability. Example - the guidance system of an autonomous vehicle interacts via events (see section 4.4) with the environment (and, possibly, with other vehicles). The system is a stateless component, which relies on a private context. The private data-store hosts information which provides a subjective image of the world - including the vehicle itself. When an event occurs the component reasons on the basis of the event and of the private data-store. Example - a decentralized business system consists of several components, one for each office. They interact by exchanging documents i.e., high-level events, according to a suitable communication protocol. Each office is a stateful component whose state machine implements the protocol. Each component has a private data-store including a local archive of documents. Example - in a RFID-based stock management system the state of the stocks is stored in a shared data-store (i.e., a central database). On behalf of an RFID event, a one-shot stateless component is activated. The component exploits and asserts facts hosted by the shared data-store. The choice of the patterns may also depend on implementation issues. As we shall discuss later, this is especially true when scalability is a major requirement. 41

42 Example - a stateful component might be transformed into a stateless component, provided that the state of the components is modelled by auto-representation information in a data-store (e.g., a centralized database) Service-Oriented vs. Event-Driven From the user perspective there are two important high level interactions models: Service-Oriented model: the environment (i.e., the users) interacts with the IT system by requesting services, which turn into activities that provide a response to the service requestor. Event-Driven model: the IT system observes the emergence of significant facts about the environment (which often is a physical system instead than a set of human users). The emergence of a fact triggers the activities that, in turn, generate new facts notified either to other components or to the environment itself. It is up to the system to decide why and when to perform its activities. The Service Oriented model has proven to be effective in many business areas, where the service" metaphor properly mirrors the organization and the user's working style. This is the widespread situation of a business system, where the user explicitly asks for a service. However, this approach does not model real-life situations where the environment (possibly, the user) does not ask for services. In many cases the environment is not even aware of being observed. The environment (be it a user or a physical system) generates events that are observed by the IT system, which is in charge of deciding what and why to do. The environment does not rely on the explicit invocation of services. The generation of events is conceptually invisible to the environment. Example - a surveillance system can be hardly viewed as something that provides services to the environment. Rather, it observes the environment (which is not aware of the existence of the system) and decides what, why and when to do something. An event-driven activity may generate in turn events to other event-driven activities and - possibly back to the environment itself, as in case of a closed-loop control system. However, this does not mean that the controlled system asks for a service. Example - a guidance system allowing a vehicle to autonomously control its movement by interacting with other vehicles in order to avoid collisions. Example - an RFID-based system reacts to events from the RFIDs in order to manage a warehouse. What to do for updating the warehouse information and when to do it is up to the system. It can be hardly asserted that the system provides services to the RFIDs. Example - the service a cashier requires is to print out a receipt, not to update the state of a warehouse. The event (item sold) triggers activities about the shelf level, which, in turn, generates events exploited for reasoning about the warehouse level. Example - a process control system gets events from the controlled environment, but it autonomously decides when to take decisions and when to deliver events (commands) to the controlled system. Again, the IT control system does not provide services to the controlled physical system. Anyway, the choice between a Service-Oriented and an Event-Driven is matter of problem architecture. This does not imply the choice of specific interaction styles, exactly as interaction styles do not imply specific implementation mechanisms, as discussed in Section 4.1. The misuse of the keywords Service-Oriented" and Event-Driven" leads to misconceptions. These terms can be used to model the conceptual architecture of the interactions or the concrete organization of IT system itself. According to our view, they are relevant models at the level of Problem Architecture: they are userlevel interaction styles, because they express interactions from the user point of view. In other words, they are different interaction paradigm at analysis level. In the Concrete Architecture we can reify these models according to either procedure calls or asynchronous messages: a service oriented model is directly supported by procedure calls. However, it can be reified through two asynchronous messages, representing the request and the response; 42

43 the event-driven model is directly supported by asynchronous messages, but it can be reified by procedure calls which send/get event functions. In particular, whenever there is a couple of oneway flows between two activities, we can reify them just with a function call, according to a push ( send event ) or a pull ( get event ) way. Misconceptions emerge because often the same terms are used to denote concrete mechanisms provided by technological platforms. Some platforms are service-oriented", as they provide basic mechanisms for requesting services - which could be asynchronous services, and whose semantics is up to the applications - therefore a service" can be exploited to notify an event. On the opposite, some platforms provide basic event notification mechanisms, which can be exploited by an application to mimic a service request through a pair of request-response events. In conclusion, one should carefully separate the user-level interaction style adopted for the analysis on the Problem Architecture from the concrete styles chosen for the design on the Concrete Architecture. The term architecture" is used at both levels, so that it is not clear what Service Oriented Architecture and Event Driven Architecture mean. 4.4 Reification of basic partitioning Interaction style In the reference example we can observe that the information flows among activities are not characterized by an actual periodicity. A1- Recognize item at POS is driven by the item sold event. The selling dynamics could be properly estimated as sketched in section 2, however we do not know exactly the time between two selling occurrences. The same happens for the information flows among A1 and the update activities A2- A3-A4 and the need items flows by the check activities A5, A6, and A7. Hence, for every proposed partitioning, the reification of their information flows should be through asynchronous messages or procedure calls in the push way Goods-driven partitioning: Anonymous Components A first solution for the Goods-driven partitioning exploits anonymous components. This choice relies on some major assumptions: as defined by the correspondent logical partitioning, each component instance is capable of managing any kind of information; components are stateless. This implies that, in case of long-lived transactions, the intermediate state of a transaction must be stored in a shared data-store. There is a shared data-store hosting domain information, which must be visible to any component. Components are anonymous and are created on the fly whenever needed. Figure 39 shows a model for the reference example. Figure 40 shows an example of collaboration. 43

44 Figure 39 - Anonymous product manager Figure 40 - Collaboration example Abstraction-Based partitioning: Level Managers In case of abstraction-based partitioning a straightforward choice is to assign to dedicated components the activities related to an abstraction level, and to partition the context information accordingly. In the simplest case, each abstraction level can be supported by a sequential component (Figure 41). Figure 42 shows an example of collaboration. The figure highlights that inter-level events have different timing constraints, so that intra-level collaboration sequences can be independently triggered. 44

45 Figure 41 - Level managers Figure 42 - Collaboration example 45

46 4.4.4 Abstraction and location based partitioning Figure 43 - Level managers oriented to the locations Figure 43 looks very similar to Figure 41, but, according to the logical architecture, they differ on the cardinality of shelf and shop managers and of the related data-stores. There are many managers and datastores, possibly one for each shop. The managers are fully compact and insulated, so that they can be hosted by different processors without communication overhead and without any need for aligning the local contexts. 46

47 5 Implementation Architecture The Implementation Architecture defines an implementation of the Concrete Architecture. Choices at this level regards the adoption of programming languages and development environments, computing and communication platforms, libraries and development framework, middleware, and so on. These choices must be consistent with the fulfilment of all the non-functional properties of the components (and their interactions) defined in the Logical and Concrete views. Obviously, effective choices at Implementation Architecture are not enough for a successful system. This requires an effective analysis (Problem Architecture) and an effective design (Logical and Concrete Architecture). On other side, effective choices at Problem, Logical and Concrete Architecture could be made ineffective by bad implementation choices. In the following we summarize some basic points about the implementation of components and interactions styles. 5.1 Implementation of interactions styles A lot of technologies are available for implementing (remote) procedure calls and asynchronous messages. Different aspects has to be evaluated to perform a choice, including software and hardware requirements (computing and space needs, operating systems and other libraries which may be required); performance, robustness and scalability; license costs; development status and support by the producer. In particular, we can distinguish among language-specific and interoperable technologies. Language-specific technologies are available only for a particular programming language. Interoperable technologies are supported by different programming languages. In this case a reference language is identified and a mapping with every specific programming language is defined through a set of specific libraries. Hence they support the interaction among components written in different languages. In the following we mention various widespread technologies Procedure calls technologies Local procedure calls are supported by every language, either imperative languages (for example C, C++, Java) or functional (LISP) or declarative ones (Prolog). Remote procedure calls (RPC) are supported by the most common languages. Java-RMI [29] is the specific RPC technology for the Java language. CORBA [30] is a standard proposed by the OMG (Object Management Group). It adopts a specific language (IDL, Interface Definition Language) for the procedure specification and invocation. DCOM [31] was proposed by Microsoft in alternative to CORBA. XML-RPC [32] is an interoperable technology which uses XML as reference language and HTTP as transmission protocol. Web Services [33] is a standard proposed by World Wide Web Consortium (W3C), which exploits a language (WSDL) and a transmission protocol (SOAP) based on XML. Web Services are the most widespread solution for interoperability, especially in Enterprise Application Integration. 47

48 5.1.2 Asynchronous messages technologies The basic mechanism for sending and receive asynchronous messages is given by the socket abstraction. A socket is an endpoint of a bidirectional communication between two running programs [34]. Sockets are supported by the common operating systems and programming languages. They allow sending and receive messages according to different network protocols (for example TCP). Moreover there are different platforms which enable message exchanging with many additional features. JMS [35] is the Java specific technology for asynchronous messages. IBM WebSphere MQ [36] is a IBM proprietary platform which supports different programming languages. 5.2 Implementation of concrete components Generally a concrete component is implemented as a collection of modules of a programming language which can be packaged as a whole and which can be instantiated and executed entirely on a computational node (with some required computational capabilities). In Object Oriented programming languages 2 a concrete component can be realized as set of classes plus additional resources (external libraries, text files, etc). This set of classes can be packaged on a library, with different formats (for example static and dynamic library for C++, JAR file for Java). Typically there is a class playing a special role (Facade role [28]). It exposes public operations to interact with the component (at least a start operation, see Concrete Architecture). JavaBeans [6] and Enterprise Java Beans (EJB) [4] are two ways to implements concrete components in a standard way in the Java language. Different technologies like CORBA, DCOM (and EJB so) aims at providing a reference schema for the implementation of components written in different languages and giving a unified platform to interact. Concrete components of the same system may be implemented in different languages. In particular, according to domain constraints or deployment choices, components could be executed on different computational nodes with different supported languages and environments. In this case interoperable interaction technologies acquire a central role. Example. Suppose that a component of Graphical User Interface has to be executed on smart phone. Clearly it has to be implemented in languages and technologies supported by the smart phone operating system. Generally these technologies are different from those supported by classical server machines (for example Java Mobile [37] versus full Java environment). Finally, components could have alternative implementation with an equivalent semantics not only to support different computational nodes. We could have various implementations (in the same o different language) to cover different values of non-functional qualities. For example an implementation could guarantee strong response times but with high memory occupation. Another implementation could guarantee lower response times with lower memory occupation. 2 In particular, we refer to class-based object-oriented programming languages. 48

49 6 Deployment Architecture The Deployment Architecture view defines the allocation of concrete components to computing nodes. Here physical technologies are also considered: what computational nodes are required, what networks and their configuration, other physical devices (RFID sensors in the example). In the following we present some common deployment strategies that can be adopted according to the chosen partitioning. 6.1 Horizontal scalability Horizontal partitioning paves the way to a high degree of horizontal scalability (Figure 48) by exploiting the farm-based pattern. Figure 44 Horizontal scalability Pros High scalability. Anonymous components may run on different computing nodes. The event delivery mechanism may be straightforward (in the simplest case, just an event queue from which the delegators take inputs whenever possible). As a matter of fact, this pattern is typical of a so-called server farm, where each computing node executes anonymous components. The capability of creating components whenever needed improves the scalability even if the reasoning activities are computing intensive and if the application domain does not suggest partitioning by entity type. 49

50 Cons o Example - a video surveillance system, where images must be concurrently processed and the processing time depends on the features of each image. Simple configuration and system administration (all the processors host the same software components). Components are more complex, because each component must be capable of managing any product. The access to a unique shared context may be a bottleneck. This can be avoided if the shared context is partitioned (e.g., by products) so that the probability that components conflict is kept low. The communication infrastructure and the event switcher may become a bottleneck. 6.2 Vertical scalability Vertical partitioning leads to a layered system paving the way to vertical scalability (Figure 45). Figure 45 Vertical scalability Figure 49 sketches a straightforward solution, where a processor is devoted to each abstraction level. Though this solution exhibits several drawbacks, it is introduced to highlight the difference from the solution based on horizontal scalability (Figure 44). More sophisticated solutions will be discussed in the following. Figure 45 highlights that contexts are partitioned according to the abstraction level, so that they can be efficiently hosted by the same computing node that hosts the reasoning activities of that level. Pros Clean separation of concerns. 50

51 Cons: Layers with different timing constraints correspond to different computing nodes, which can exploit different technologies (OS, languages etc.) in a cost-effective way. Activities and facts hosted by each node have a high degree of autonomy, so that a reasonable degree of availability is ensured even in case of intermittent availability of the communication system or of failure of the high-level computing node. Inter-node communications are not time-critical, carry aggregate information and are less frequent at higher abstraction levels. Therefore bandwidth is not critical. not suitable whenever each event from the environment triggers the whole chain of elementary activities (i.e., the timings of the flows of events among levels are not different). Individual layers may become bottlenecks. Limited support for decentralization. System configuration, set-up and administration may be complex. 6.3 Abstraction and location-driven scalability In this case, every shop has proper computing nodes and there is an instance of LocalShelfManager and LocalShopManager for each shop (Figure 46). Of course, both horizontal and vertical partitioning criteria can be added and combined in order to get a highly scalable architecture. Pros: Figure 46 Abstraction and location based deployment 51

52 in the example, space and organizational dimensions coincide with abstraction levels, so that a high degree of compactness over many dimensions is achieved. Clean separation of concerns, leading to simpler software and database (managers and contexts deal with one shop only). Local managers and contexts may have different implementations. This is a key issue in Enterprise Integration perspective. Support for both geographical and organizational decentralization. Low requirements in terms of network bandwidth and availability. Gracefully degradation (shop activities continue even in case of failure of the network and/or of the central node). Cons: complex configuration, deployment and system administration. 6.4 Partitioning vs. Deployment We showed how proper partitioning criteria can be mapped into cost-effective deployment schemes. We point out, however, that a proper partitioning is the basis for a sound software architecture even if, for costperformance reasons, the deployment turns into a centralized physical architecture (which, in turn, is subject to horizontal scalability). Figure 47 shows an alternative deployment for the partitioning scheme of Figure 49. The components are the same, but all of them are deployed on a unique centralized processing node. In a sense, we go back to a centralized architecture, which is cost-effective if there is broad bandwidth at a low cost and with a high availability. 52

53 Figure 47 Centralized deployment of Vertical Partitioning Pros: Cons: There is still a clean separation of concerns (different contexts for different shops). The central computing node may exploit horizontal scalability. Simple configuration, deployment and system administration. No graceful degradation - central processing node and communication infrastructure become critical. High communication bandwidth is required. Peripheral device directly communicate via a broadband (and possibly energy-wasting) network. This might be a critical issue for energy-critical sensors. 53