A UML profile to support the formal presentation of software - - PDF document

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/3974631

A UML profile to support the formal presentation of software architecture

Conference Paper · February 2002

DOI: 10.1109/CMPSAC.2002.1044555 · Source: IEEE Xplore

CITATIONS

4

READS

47

2 authors: Some of the authors of this publication are also working on these related projects: Whale Optimization Algorithm for Requirements Prioritization View project Agile Requirements Prioritization View project Amjad Hudaib University of Jordan

88 PUBLICATIONS 426 CITATIONS

SEE PROFILE

Carlo Montangero Università di Pisa

82 PUBLICATIONS 731 CITATIONS

SEE PROFILE

All content following this page was uploaded by Carlo Montangero on 22 March 2014.

The user has requested enhancement of the downloaded file.

1

An UML Profile to Support the Formal Presentation of Software Architecture Amjad Hudaib and Carlo Montangero

Dipartimento di Informatica – Universitá di Pisa {Amjad, Monta} @ di.unipi.it

Abstract

We present an UML profile that accommodates the specialized dynamic models that support the Oikos_adtl approach to software architecture. The profile reflects some core modeling Oikos_adtl concepts in the UML framework. We propose the related notations and diagrams, which map into the new models. Since we rely on the standard UML extension mechanisms, we are also setting the requirements for add-ins to the standard UML tools, to support our approach to the formal specification and analysis of software architectures. For instance, we foresee an add-in to extract logical formulae from a model, and feed it to other tools, like Mark, a semi-automatic theorem prover tailored for Oikos_adtl. We look at these diagrammatic notations as an enhancement of the usability

• f Oikos_adtl as a software architecture description language.

Key Words Software Architecture, Software Architecture Patterns, Oikos_adtl, UML Diagrams, UML Extensions.

• 1. Introduction

Software architectures provide models for the large-scale structural properties of systems and usually appear in system descriptions as a diagrammatic representation of the structure of the system, in terms of components, connectors and their relationships. These diagrams may be conveniently represented in the Unified Modeling Language (UML), a graphical language to specify, visualize, construct, and document software artifacts (Rambaugh et al., 1999). Indeed, UML has been accepted as a standard by OMG (OMG, 2001), and has been advocated as a candidate standard for software architectures (Booch, 1999; Kobryn, 1999). However, there is still much discussion on the best way to express the architectural core concepts in the UML: a good picture of the state of the art can be found in the proceedings of the recent ICSE 2001 Workshop on Describing Software Architecture with UML. Besides, it has been argued (Montangero, 1998) that some core concepts, namely connectors, tend to be exploited too early in the presentation of architectures, and that a more abstract view of the relationships between the components could be useful from many points of view, e.g. understandability and reusability. Finally, there is an issue of the level of formality in the presentation of an architecture, especially in view of the consequences on the kind and breadth of analysis that can be supported. We are currently pursuing an approach that fosters the shift of focus, in the description of software architecture, from the connectors to the explicit remote effects that an interaction has on the partner. Therefore, we can view the interactions among components as a special kind of association, and describe abstractly software architectures in terms of components and their associations. We are also proposing to give precise semantics to the interactions, by relating them to formulae in a suitable logic, Oikos_adtl (Montangero and Semini, 1999). The gain we expect form this relationship is to be able to perform a number of analysis on the architecture, namely to derive global functional properties from those of the components, taking into account the interactions. The technical contribution of this paper is the definition of an UML profile that accommodates the specialized dynamic models that support our approach, by reflecting some core modeling Oikos_adtl concepts in the UML framework. We also propose the related notations and diagrams, which map into the new models. Since we rely on the standard UML extension mechanisms, we are also setting the requirements for add-ins to the standard UML tools that can support our approach to the formal

2 specification and analysis of software architectures. For instance, we foresee an add-in to extract logical formulae from a model, and feed it to other tools, like Mark, a semi-automatic theorem prover tailored for Oikos_adtl (Ferrari et al., 2002). We look at these diagrammatic notations as an enhancement of the usability of Oikos_adtl as a software architecture description language. As an illustration of the approach, we apply the notations to a simple case study, the Server-Proxy- Broker (SPB) pattern, adapted from (Buschman et al., 1996). This pattern provides a server that registers its services in a broker, to make them available to its clients. Since it may be inefficient and/or insecure to let the server register directly in the broker, a proxy in interposed. The remainder of the paper is organized as follows: section 2 gives a short description of Oikos_adtl. Section 3 presents the UML profile for Oikos_adtl. Section 4 introduces the notations and the mapping to the models. Section 5 presents the case study, section 6 discusses related works, and section 7 presents concluding remarks.

• 2. Oikos_adtl

Oikos_adtl is a specification language for distributed systems based on asynchronous communications. It is a temporal logic, which extends Unity (Chandy and Misra, 1988), to deal with components and events (Montangero and Semini, 1999). It is designed to support the composition of specification , and fosters the expression of global properties in terms of the local properties of the components, according to composition templates. Oikos_adtl is intended to give designers a language to express the properties of interest in a natural

• way. It has been used to specify software architectures and patterns (Hudaib and Montangero, 2001;

Montangero and Semini, 1996) and to analyze security issues in mobile systems (Ferrari et al., 2000). We recall the most important concepts in the next paragraphs. A system is characterized by a list of component names M = M, N, O,… and a set T of state transitions, where each transition is associated to one component. A computation is a graph of states like the one in Figure 1, where dotted arrows denote multiple transitions, and plain arrows denote single transitions or remote interactions.

Figure 1: A sample computation of a system with two components

A system is specified by liveness (something good eventually happen in all executions of a system) and safety (nothing bad will happen in any execution of a system) properties of the evolution of the state of its

• components. An event occurs when a given condition is established in a component. In this paper, we will

concentrate on the operators CAUSES (liveness) and BECAUSE (safety). CAUSES relates an event and a condition, and specifies that the occurrence of the event is sufficient to arrive in a state in which the condition holds. BECAUSE also relates an event and a condition, but specifies that the condition is a necessary one for the event to occur, namely that the condition must hold in the state before the event

• ccurs. A specification consists of a set of component names M, and a set of formulae F. Examples of

formulae are: M: p WHEN c CAUSES S: q (1) S: q WHEN c BECAUSE (S: r /\ M: p) (2) Formula 1 is read “event p in M when c holds causes condition q in S” and states that any state of M in which c holds and p becomes true, is eventually followed by a state of S satisfying q, as in the computation in Figure 2.

3

Figure 2: A model computation of M: p WHEN c CAUSES S: q

Formula 2 is read ”event q can occur in S when c holds, only if r and p held previously in S and M, respectively”, as in the computation in Figure 3.

Figure 3: A model computation of S: q WHEN c BECAUSE (S: r ^ M: p)

• 3. A UML Profile for Oikos_adtl

The UML is based on a four-layer structure: user objects, model, metamodel, and meta-metamodel. The declarative semantics of UML concepts is expressed in the metamodel, which is decomposed into three logical subpackages: Foundation, Behavioural Elements and Model Management. The metamodel architecture is a proven infrastructure for defining the precise semantics required by complex models that need to be reliable stored, shared, manipulate. It is also responsible of defining a language for specifying models. The UML Profile for Oikos_adtl defines how to customize UML to capture the essential semantic concepts of Oikos_adtl that we want to use in the description of software architecture: the causal relationship (Causes, for short) between two components. This relationship occurs when an event in one component is a necessary and sufficient cause of another event in another component. In the logic it is described by a pair of formulae, shaping A: p CAUSES B: c and B: c BECAUSE A: p Quite naturally, in the following we will refer to A: p as the Premise of the causal relationship, and to B: c as the Consequence. The profile exploits the extensibility mechanisms of UML, i.e. stereotypes, constraints, and tagged

• values. We also use, when it helps, already defined UML stereotypes, entities and associations, without

discussing them in detail. Stereotypes are specialization of entities in the metamodel, subject to given

• constraints. Tags introduce features of the new entities, and are associated to their domain (the tag values).

Constraints are directly attached to model element and describe semantic restrictions that model element must obey. The relevant information about stereotypes and tags is summarized in Table 1. In the rest of this paper, UML terms are in Courier, and the defined stereotypes and tags in Italic. We also assumes some knowledge of the UML metamodel for Collaborations. An Oikos_adtl Model is a stereotyped Model that describes a system as a set of components that interact asynchronously. The model contains an OCollaboration, a stereotype that defines a set of Oikos_adtl formulae that describe the behavior of the system. An OCollaboration possibly contains also InteractionInstanceSets that represent compliant computations, by instantiating stereotyped Interactions.

4

Table 1: Summary of the UML Profile for Oikos_adtl

Stereotype Base Class Parent Tag Type Multiplicity

Oikos_adtl Model Model N/A OCollaboration Collaboration N/A OComponent ClassifierRole N/A intEvent String * Causes AssociationRole Association Role intAxiom String * Premises AssociationEndRole AssociationEndRole event String 1 Consequences AssociationEndRole AssociationEndRole condition String 1 OAction Action N/A OInteraction Interaction N/A Cause Message N/A

3.1 Oikos_adtl Collaboration An OCollaboration is a stereotype that restricts Collaboration to show the context in which causal relationships occur. Its contents are modeling elements that interact within a given context, and it shows several roles together with their classifiers, associations, and causal relationships. To use an OCollaboration, each role must be bound to an actual classifier or association, as required by the role. More specifically, an OCollaboration contains an ensemble of OComponents and Causes associations. It may also contain a set of OInteractions that provide instances of the computations performed by the participating OComponents. Instances will be described in the next section. Here we consider the models at the descriptor level, where OCollaboration describes the structure of the causal relationships among the participant OComponents. The abstract syntax of the relevant part of the profile is given in Figure 4 according to the UML metamodelling conventions. We discuss in the following the stereotypes and tags. An OComponent is a specialized ClassifierRole that describes a specific role played by a participant in an OCollaboration. It specifies a restricted view of a Classifier, defined by what is required in the collaboration. The OComponent may be connected to a set of Causes, via stereotyped

• AssociationEndRoles. The Causes is a specialized stereotyped AssociationRole that describes a

specific usage of an association needed in an OCollaboration. The main difference with standard Collaborations is that in the latter, usually there is at most

• ne association between two ClassifierRoles, to indicate communication exchanges between the

ClassifierRoles. Causes is a finer specification, describing communication in terms of triggering Premises and Consequences on the state of the target role. It specifies a particular kind of association that defines the causal relationship between OComponents. Each Causes is a composition of two stereotyped AssociationEndRoles (Premises and Consequences). It relates an event, from Premises, to another, from Consequences, and specifies that the occurrence of the former is a sufficient and necessary cause for the latter. Premises is a stereotyped AssociationEndRole that specifies an endpoint of an association as used in an OCollaboration. The Premises is part of a Causes and specifies the connection to an

• OComponent. It has a tag event, which specifies the triggering event in the causal relationship. Similarly,

Consequences specifies an endpoint and has a tag, condition, which specifies the condition established in the causal relationship. Other tags in the profile, besides event and condition, are intEvent and intAxiom. The intEvent specifies the internal Oikos_adtl events that are relevant to describe the local behaviour of a

• ClassifierRole. The other one, intAxiom, permits the specification of local causal relationships. Tag

values are Strings, with the same syntax of the relevant parts of Oikos_adtl. In fact, some simplifications are possible, thanks to the context provided by the model: the axiom “A: p WHEN s CAUSES A: c” is written “p WHEN s CAUSES c”, when used as the value of the tag intAxiom of component A. Finally, in Figure 4, an association with role base links a classifier (association) which is a view, to its base, i.e. the full classifier (association).

5

Figure 4: UML Profile for Oikos_adtl: OCollaboration

3.3 Oikos_adtl Interactions An OInteraction contains a set of stereotyped Messages, Cause, that specify some communications between a set of OComponents of the owing OCollaboration. That is, the OCollaboration defines the context in which an OInteraction takes place. The Cause defines the particular kind of communication that supports the causal relationships between OComponents. It is connected to an OAction, a stereotyped Action, which is restricted to be either Send or Call, and identifies the Signal to be invoked in the

• communication. Any implementation of the model will provide concrete realizations of the signals and

actions: here, we distinguish only between remote Send Action and local Call Action.

6 Figure 5 gives the abstract syntax of the profile that is relevant to the instance level, where OCollaboration describes the dynamic behaviour of the causal relationships among the participant OComponents. An OInteraction specifies the communications between an ensemble of OInstances, a stereotyped Instance, that interact according to the causal relationships defined in the OCollaboration. These OInstances are connected to Ocomponents, which declare the structure and define the behaviour of the

• OInstances. The OInstances are included and referenced in a CollaborationInstanceSet. The

CollaborationInstanceSet contains an InteractionInstanceSet, which references the collection of Ostimulus, a stereotyped Stimulus, that constitute the actual communications between the

• OInstances. An OInteraction can be used to represent computations that exemplify the behaviour specified

by the axioms represented by the including collaboration.

Figure 5: The UML profile for Oikos_adtl : the InteractionInstanceSet

• 4. Notations for Causal Relationships

We propose to use three different diagrams, at decreasing levels of abstractions, to describe the dynamics of a software architecture. The first one is the standard Collaboration Diagram, at the descriptor level, which describes the communication paths among the Classifier Roles. The boxes are mapped to ClassifierRoles, and may show a compartment for Features, with values from the internal Event that maps to the tag intEvent. This compartment declares the Oikos_adtl events that are relevant to describe the local behaviour of the ClassifierRoles, to reach the goals of the collaboration. The associations between boxes are mapping to AssociationRoles. Figure 6 shows an example of Collaboration Diagram at the descriptor level.

7

Figure 6: The Collaboration Diagram at the Descriptor Level.

The next level of description is given by the Oikos_adtl Collaboration Diagrams that refine the standard collaborations by introducing causal relationships. An example is given in Figure 7. Each box maps to an OComponent, with the name shown in the upper part of the box. The double stick arrowhead (reminiscent

• f the asynchronous messages in the standard notation) maps to a Causes, with prem and cons as the

Premises and Consequences tag values, respectively. Also, internal Axiom maps to the tag value intAxiom. The OCollaboration represented by the diagram contains the Oikos_adtl specification. For example, the collaboration in Figure 7 represents the liveness axiom “RoleA: prem CAUSES RoleB: cons” and its companion safety axiom “RoleB: cons BECAUSE RoleA: prem”. An add-on to standard UML tools could check that the Oikos_adtl Collaboration Diagrams represent behavioural models that satisfy the static constraints on the communications expressed by the associations in the Collaboration Diagram. An add-on could easily export the axioms to Oikos_adtl specific tools, like Mark (Ferrari et al, 2002), that can perform a number of analysis on the architecture.

Figure 7: Causal Relationships in the Oikos_adtl Collaboration Diagrams

The Oikos_adtl Collaboration Diagrams define the causal relationships induced by the communications among the OComponents, but do not address their timing, being at the descriptor level. Oikos_adtl Sequence Diagrams are introduced to define CollaborationInstanceSet, which contains timed instances, i.e. model computations of the axioms represented in the Oikos_adtl Collaboration Diagrams. In the Oikos_adtl Sequence Diagrams, each object box with its lifeline maps into an OInstance, which conforms to an OComponent in the CollaborationInstanceSet’s

• collaboration. An arrow maps into a Stimulus connected to two Instances: the sender and the
• receiver. The Link used for the communication of the OStimulus plays the role specified by the Causes

connected to the Cause of which the OStimulus is an instance. The correct Link can be determined from the Oikos_adtl Collaboration Diagrams, because it is unambiguously decorated with Premises and Consequences tag values. The order of the arrows, in Oikos_adtl Sequence Diagrams, maps onto the predecessor association between the stimuli. A predecessor relationship is established, corresponding to successive arrows in the vertical sequence. The Oikos_adtl interpretation of the predecessor relationship is the reachability relationship: if OStimulus A precedes B, then the state in which the OAction associated to B is performed follows the state in which the signal generated by A occurs. To stress the intended interpretation of these diagrams, we propose a distinguished notation for the OStimuli, namely the same double stick headed arrow already used, but with a bend, to indicate asynchronous communication with delay (and remind the standard UML slent arrow) (Figure 8, left). It also turns out that in this way Premises and Consequences are better accommodated in the diagrams.

8 Oikos_adtl Sequence Diagrams may present intra component OStimuli, due to Call Actions. They can be seen as local Causes, and make use of the intEvent tag values that are listed in devoted compartments in the ClassifierRoles in the OCollaboration. Figure 8 (right) shows an example of an instance of a cause relating two internal events.

Figure 8: Causal Relationships in the Oikos_adtl Sequence Diagram

The next section applies the notations to a software architecture pattern, and illustrates the kind of properties that can be derived from the induced formal description.

• 5. Example: Server-Proxy-Broker Pattern

In this section we show how to apply the notations for causal relationships to provide a high-level presentation of an architectural pattern. We follow the format of the best known books on patterns (Buschman et al., 1996; Schmidt et al., 2000; Gamma et al., 1994). However, since we concentrate on the formal description of patterns at a high-level of abstraction, and following the suggestion in (Hudaib and Montangero, 2001), we make the explicit formal description a main element of the pattern presentation. Here, the presentation is kept very short, for reason of space, and we provide details only of the two items (Dynamics and Formal Description) that are relevant to illustrate how the graphical notations help in conveying the intended behaviour. These detailed items are preceded by a summary of the other items that would appear in the standard presentation of the pattern. The Server-Proxy-Broker (SPB) pattern provides a solution to the problem of a server that wants to register its services with a broker to make its services available to its clients. The problem appears when it is inappropriate to let the register directly with the broker, since it may be inefficient and insecure to let the server be aware of the broker physical location. The solution follows the first POSA book (Buschman et al., 1996): the server registers its service with the broker through a proxy server. So, the pattern has three components: A server that needs to introduce its services; A broker that is responsible for coordinating communications between clients, such as forwarding requests and transmitting back results and exceptions; A proxy server which is interposed between the two, to guarantee the desired decoupling. The components playing the server, the proxy server, and the broker have identities S, PS, and B respectively, to identify them in the communication protocols. DYNAMICS: Figure 9 depicts the gross structure of the interaction among the pattern participant that is it shows how the associations bind the components. This Collaboration Diagram states that the server and the proxy communicate to ensure the blind subscription, i.e. without disclosing unnecessary details, while the proxy and the broker communicate to establish the actual subscription. The intEvent updateRep expresses that the proxy and the broker need to keep track of all the necessary binding information and store them into their respectively repositories. The finer structure of the interaction, still at

9 the descriptor level, is given in Figure 10, which introduces the causal relationships that constrain the behaviour as needed. Figure 9: The Collaboration Diagram of SPB Pattern. Figure 10: The Oikos_adtl Collaboration Diagram of SPB Pattern An instance of the intended computations is given by the Oikos_adtl Sequence Diagram at the instance level in Figure 11. The server starts the protocol when it needs to register its service, by sending a message to its proxy server needToReg(service, S). This causes the event reg(service, S) in the proxy server, which forwards the registration, regService(service, PS), to the broker. As the broker receives the incoming registration request from the proxy server, enterService(service, PS), it extracts all the necessary information from the message and stores it into its repository updateRep (service, PS). Then, an acknowledgment is sent back to the proxy server, ack (service, PS, B). After receiving the acknowledgment from the broker, which causes the event serviceRegistered(service, PS, B), the proxy server stores it into its repositories, updateRep(service, S, B). Finally, the proxy returns to the server a message to tell it that its service has been registered in the broker, return(service, S, B), which causes the event registeredService(service) in the server, and closes the protocol.

10 FORMAL DESCRIPTION: The main purpose of this section is to present the results of the formal analysis of the pattern, i.e. a set of properties that characterize the pattern. For instance, SPB can be characterized by formula (3). This property links the events highlighted in bold in Figure 11, and reads: any request to register a service will be honored; besides, the broker and the proxy will hold the necessary information to manage the related communications. S: needsToReg (service) CAUSES B: updateRep(service, PS) ^ PS: updateRep (service, S, B) ^ S: registeredService(service) (3) This model is admittedly naïve, and needs to be extended, to take care of failures and exceptions. However, it should convey the essence of the approach. The formal description section presents also, for easy reference, the collection of the formulae that are implied by the diagrams above, plus those auxiliary axioms that may be needed in the formal analysis to prove the relevant properties. Figure 11: The Oikos_adtl Sequence Diagram of SPB Pattern

• 6. Related work

Several researchers have attacked the problem of providing rigorous semantics to UML, some with a perspective similar to our own. For instance, (Polack and Laleau, 2001) presents a variant of UML 1.3 suitable for the specification of the static structure of an information system (IS). The approach has been developed to derive formal specifications (in the B notation) from object-oriented class and behavioural

• models. It presents metamodels for the main concepts required to model the static aspects of information
• system. (Cibrán et al., 2000) proposes a formalization of the syntax and semantics of Collaboration

Diagrams in Object-Z. They take into account both levels of abstraction that are present in a Collaboration Diagram: specification level (syntax) and instance level (semantics).

11 On another side, the work in (Zarras et al., 2001) specifically targets UML-based architecture modeling, and identifies the UML modeling elements that best match the three basic architectural elements (component, connectors, and configuration). The needed extensions to the UML metamodel are: the ADLComponent stereotype, based on the subsystem element, and the ADLConnector as a stereotype based

• n the Association element. The distinguishing feature of the ADLConnector is that it defines the roles that

are bounded by the connector. Then, a configuration is defined by specializing the subsystem stereotype, constraining its instances to be assembly of instances of ADLComponent via instances of ADLConnector. Finally, the paper outlines how to extend the profile to specify Wright-like architectures, by using CSP model tagged values in the specialization of the architectural stereotypes. Besides the different languages that are used in the tagged values to describe behaviours, the main difference with our work is that they attach their CSP tagged values to model elements that belong to the UML structural level, while we exploit the UML dynamic models. We think that this tighter embedding will be better accepted by the user, and facilitate the construction of the necessary add-ins. The UML subsystem concept may be adapted for architectural modeling. For instance, (Storrle, 2001) tries to integrate architectural modeling concepts, namely those of Real Time Object Oriented Modeling (ROOM), into the UML. The approach is based on the modification of the subsystem modeling element, rather than exploiting stereotypes. It introduces the concept of architectural unit, and its relatives, that is, views to structure them, ports to define their interface, and connectors to glue them together. An interesting survey of the main properties of the UML concepts that have been used to model various aspects of software architecture is found in (Selic, 2001). It examines subsystems, components, classifiers and composite classifiers (that encapsulate one or more structural features that are instances of

• ther classifiers). It also proposes a model of the Acme component, without involving the semantic extras

associated with UML components. (Hofmeister, C. et al., 1999) take a very general view to the description of Software Architecture with UML, separating it four views (conceptual, module, execution and code): each view has particular elements that are described in UML diagrams.

• 7. Conclusions

This paper defines an UML profile that accommodates the specialized dynamic models that reflect the core Oikos_adtl modeling concepts in the UML framework. It also presents the related notations and diagrams and how they map into the new models. We look at these diagrammatic notations as an enhancement of the usability of Oikos_adtl as a software architecture description language. Indeed, the graphical notations make it easier to understand the structure of an architectural description in Oikos_adtl. Future work includes the design and implementation of add-ins to interface standard UML tools to Oikos_adtl specific tools that can perform architectural analysis. In these activities, we expect to reap the benefits of the fact that we have relied on the standard UML extension mechanisms to introduce the new

• notations. Besides, we plan to validate the proposal, by applying the notations to other, more complex, case

studies.

• 8. References

Buschman, F. Meunier, R. Rohnert, H. Sommerlad, P. and Stal, M. 1999. A System of Patterns: Pattern – Oriented Software Architecture, John Wiley & Sons, Chichester, England. Booch, G. 1999. UML in Action. Communication of the ACM 42, 10. Chandy, K. M. and Misra, J. 1988. Parallel Program Design: A Foundation, Addison-Wesley, Reading Mass. Cibrán, M. A. Mola, V. Pons, C. and Russo. W. M. 2000. Rigorous Description of the Syntax and Semantics of UML Collaborations, ECOOP´2000 Workshop on Defining Precise Semantics for UML .

• Eds. Moreira, A. Bruel, J. France, R. and Kent, S. Cannes/Sophia-Antipolis, France.

Fawler, M. 1997. Analysis Patterns, Addison-Wesley Longman, Inc, Massachusetts, USA.

12 Ferrari, G. Montangero, C. Semini L. and Semprini, S. 2000. Mobile Agents Coordination in Mobadtl, In A. Porto and G.-C. Roman, editors, Proc. 4th Int. Conf. on Coordination Models and Languages, COORDINATION'00, LNCS, Limassol, Springler-Verlag, Cyprus. Ferrari, G. Montangero, C. Semini, L. and Semprini, S. 2002. Mark: A reasoning Kit for Mobility, Journal

• f Automated Software Engineering, (to appear).

Gamma, E. Helm, R. Johnson, R. and Vlissides, J. 1994. Design Patterns. Elements of Reusable Object- Oriented Software, Addison-Wesley Longman, Inc, Massachusetts, USA. Hofmeister, C. Nord, R. L. and Soni, D. 1999. Describing Software Architecture with UML. In P. Donohoe, editor, Proceedings of Working IFIP Conference on Software Architecture, 145-160. Kluwer Academic Publishers. Hudaib, A. and Montangero, C. 2001. Formal Patterns for Secure Software Architectures in Oikos_adtl, Workshop Sistemi Distribuiti: Algoritmi, Architetture e Linguaggi, WSDAAL'01, Como, Italy. Kobryn, C. 1999. UML 2001: A Standardization Odyssey. Communications of The ACM. V.42, No. 10, 29-37. Montangero, C. and Semini, L. 1996. Refinement by Architectural Styles or Architecting by Refinements, Joint Proceedings of the SIGSOFT ’96 Workshops, Second International Software Architecture Workshop, 76-79. Montangero, C. 1998. A Case for Refinement Calculi in Software Architecture Design. Invited position paper for ROSATEA, an NSF- and CNR-sponsored International Workshop on the Role Of Software Architecture in Testing E (and) Analysis, Marsala. Montangero, C. and Semini, L. 1999. Composing Specification for Coordination, Proc. COORDINATION 99, Amsterdam, LNCS 1594, Springer, 118-133.

• OMG. 2001. OMG Unified Modeling Language Specification, V 1.4. http://www.omg.org.

Polack, F. and Laleau, R. 2001. A Rigorous Metamodel for UML Static Conceptual Modelling of Information Systems, In CAiSE2001: 13th International Conference on Advanced Information Systems Engineering, Interlaken, Switzerland, LNCS 2068. Springler-Verlag. Rambaugh, J. Jacobson, I. and Booch, B. 1999. The Unified Modeling Language Reference Manual, Addison-Wesley Longman, Mass, USA. Selic, B. 2001. On Modeling Architectural Structures with UML, ICSE 2001 Workshop on Describing Software Architecture with UML, Toronto. Shaw, M. 1994. Patterns for Software Architecture, First Annual Conference on the Pattern Languages of Programming. Schmidt, D. Stal, S. Rohnert, H. and Buschmann, F. 2000. Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Vol. 2, John Wiley & Sons, New York, USA. Storrle, H. 2001. Turning UML-Subsystems into Architectural Units, ICSE 2001 Workshop on Describing Software Architecture with UML, Toronto. Zarras, A. Issarny, V. Kloukinas, C. and Nguyen. V. K. 2001. Towards a Base UML Profile for Architecture Description, ICSE 2001 Workshop on Describing Software Architecture with UML, Toronto.