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 READS 4 47 2 authors: Amjad Hudaib Carlo Montangero University of Jordan Università di Pisa 88 PUBLICATIONS 426 CITATIONS 82 PUBLICATIONS 731 CITATIONS SEE PROFILE SEE PROFILE 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 All content following this page was uploaded by Carlo Montangero on 22 March 2014. The user has requested enhancement of the downloaded file.
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 of 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 1
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 occurs. 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. 2
Recommend
More recommend
