Volume 16 Number 2
April 2019
Article Contents
Xi-Wen Wu, Chen Li, Xuan Wang and Hong-Ji Yang. A Creative Approach to Reducing Ambiguity in Scenario-based Software Architecture Analysis. International Journal of Automation and Computing, vol. 16, no. 2, pp. 248-260, 2019. doi: 10.1007/s11633-017-1102-y
Cite as: Xi-Wen Wu, Chen Li, Xuan Wang and Hong-Ji Yang. A Creative Approach to Reducing Ambiguity in Scenario-based Software Architecture Analysis. International Journal of Automation and Computing, vol. 16, no. 2, pp. 248-260, 2019. doi: 10.1007/s11633-017-1102-y

A Creative Approach to Reducing Ambiguity in Scenario-based Software Architecture Analysis

Author Biography:
  • Xi-Wen Wu received the B. Sc. degree in Jiangxi Normal University, China in 2012, and received the M. Sc. degree in computer science from Shanghai Jiao Tong University, China in 2016. Currently, he is a software engineer in VIPSHOP, China. His research interests include software architecture and software reliability.E-mail: sjtuwxw@163.comORCID iD: 0000-0002-8920-8945

    Chen Li received the B. Sc. degree in computer science and technology from University of Science and Technology of China, China in 2003, the M. Sc. degree in computer applications technology from the University of Shanghai for Science and Technology, China in 2010, and the Ph. D. degree in computer science and technology from Shanghai Jiao Tong University, China in 2015. Currently, he is a research associate in Department of Computing, Imperial College London, UK. He has published about 34 refereed journal and conference papers. He is a member of China Computer Federation (CCF) and Institute of Electrical and Electronics Engineers (IEEE). His research interests include software architecture, software reliability and formal methods.E-mail: lcroy2010@gmail.comORCID iD: 0000-0001-6249-8957

    Xuan Wang received the B. Sc. degree in communication engineering from Changchun University of Science and Technology, China in 2010. She is currently a Ph. D. degree candidate in creative computing at Bath Spa University, UK. Her research interests include creative computing and interdisciplinary research.E-mail: xuan.wang13@bathspa.ac.uk (Corresponding author)ORCID iD: 0000-0003-4223-1168

    Hong-Ji Yang received the B. Sc. and M. Sc. degrees in computer science from Jilin University, China in 1982 and 1985, respectively, and the Ph. D. degree in computer science from Durham University, UK in 1994. He was a faculty member at several universities, i.e., Jilin University, China in 1985, Durham University, UK in 1989, De Montfort University, UK in1993, and Bath Spa University, UK in 2013. Currently, he is a professor in School of Humanities and Cultural Industries, Bath Spa University, UK. He has published about 400 refereed journal and conference papers. He has become IEEE Computer Society Golden Core Member since 2010. Also, he is a member of Engineering and Physical Sciences Research Council (EPSRC), Peer Review College since 2003. He is the Editor-in-chief of International Journal of Creative Computing, Inder Science. His research interests include software engineering, creative computing, web and distributed computing.E-mail: h.yang@bathspa.ac.ukORCID iD: 0000-0001-6561-3631

  • Received: 2016-09-26
  • Accepted: 2017-08-04
  • Published Online: 2018-01-17
Fund Project:  This work was supported by the Japam Society for the Promotion of Science (JSPS) KAKENHI (Nos. 25420232 and 16K06203)
通讯作者: 陈斌, bchen63@163.com
  • 1. 

    沈阳化工大学材料科学与工程学院 沈阳 110142

  1. 本站搜索
  2. 百度学术搜索
  3. 万方数据库搜索
  4. CNKI搜索

Figures (12)

Metrics

Abstract Views (901) PDF downloads (30) Citations (0)

A Creative Approach to Reducing Ambiguity in Scenario-based Software Architecture Analysis

Fund Project:  This work was supported by the Japam Society for the Promotion of Science (JSPS) KAKENHI (Nos. 25420232 and 16K06203)

Abstract: In software engineering, a scenario describes an anticipated usage of a software system. As scenarios are useful to understand the requirements and functionalities of a software system, the scenario-based analysis is widely used in various tasks, especially in the design stage of software architectures. Although researchers have proposed various scenario-based approaches to analyse software architecture, there are still limitations in this research field, and a key limitation is that scenarios are typically not formally defined and thus may contain ambiguities. As these ambiguities may lead to defects, it is desirable to reduce them as many as possible. In order to reduce ambiguity in scenario-based software architecture analysis, this paper introduces a creative computing approach to scenario-based software requirements analysis. Our work expands this idea in three directions. Firstly, we extend an architecture description language (ADL)-based language – Breeze/ADL to model the software architecture. Secondly, we use a creative rule – combinational rule (CR) to combine the vector clock algorithm for reducing the ambiguities in modelling scenarios. Then, another creative rule – transformational rule (TR) is employed to help to transform our Breeze/ADL model to a popular model – unified modelling language (UML) model. We implement our approach as a plugin of Breeze, and illustrate a running example of modelling a poetry to music system in our case study. Our results show the proposed creative approach is able to reduce ambiguities of the software architecture in practice.

Xi-Wen Wu, Chen Li, Xuan Wang and Hong-Ji Yang. A Creative Approach to Reducing Ambiguity in Scenario-based Software Architecture Analysis. International Journal of Automation and Computing, vol. 16, no. 2, pp. 248-260, 2019. doi: 10.1007/s11633-017-1102-y
Citation: Xi-Wen Wu, Chen Li, Xuan Wang and Hong-Ji Yang. A Creative Approach to Reducing Ambiguity in Scenario-based Software Architecture Analysis. International Journal of Automation and Computing, vol. 16, no. 2, pp. 248-260, 2019. doi: 10.1007/s11633-017-1102-y
    • For a given software system, its software architecture defines its structure, communication and interrelation among its components[1], and its scenarios describe its usages[2]. As scenarios are useful to improve the quality of an architecture[3], the scenario-based analysis of software architecture has been a hot research topic in recent years[36]. Although this research direction is intensively studied, Sibertin-Blanc et al.[7] complain that even the basic diagram notation and sequence diagrams may contain ambiguities, since existing work typically does not define scenarios formally. For example, a sequence diagram may show that component A receives two messages $m_1$ and $m_2$ from components $B$ and $C$, respectively, and component A delivers another message $m_3$. From the sequence diagram, it is tricky to determine the partial order between $m_1$, $m_2$ and $m_3$, since sequence diagrams do not define the conditions of messages. Here, component A may need one message ($m_1$ or $m_2$) or both messages ($m_1$ and $m_2$) to deliver $m_3$, and different conditions lead to different message orders. The ambiguities in the design phase may lead to defects in the latter phase of software development. As it takes much effort to fix those defects in software, it is desirable to reduce the ambiguities as many as possible.

      Thus, we introduce the creative computing combining with popular algorithm and modelling language into our approach. In software architecture, the architecture description language (ADL) is commonly used to formally define architectures. Although researchers[812] have proposed various ADLs, it is still a blind spot to model scenarios with ADLs. In practice, programmers typically use the sequence diagram of unified modelling language (UML)[13] to model scenarios. As the state of the art, UML is a general-purpose modelling language in the field of software engineering, and it provides a standard way to visualise the design of a system. As a result, Pandey[1] criticises that the informal UML can lead to ambiguities and inconsistencies. As far as the definition of scenarios is concerned, ADL has advantages over UML[1], since ADL presents a formal way to define scenarios, and thus allows automating architecture-level scenario-based analysis (e.g., [36]). However, it is challenging to reduce such ambiguities in scenario-based software architecture analysis with ADLs:

      Challenge 1. Although it is relatively easy to introduce new features for modelling scenarios, it is tricky to detect and reduce possible ambiguities in scenarios.

      Challenge 2. To make our approach more general and compatible with existing works, we need rules to translate ADL into a general model. It is tricky to choose a popular modelling language and define such rules and to ensure the correctness during the translation.

      To address the above challenges, in this paper, we present a creative computing approach to reducing ambiguity in scenario-based software architecture analysis and propose combinational rule and transformational rule. Based on the creative rules, we extend our previous tool, called Breeze. Our extension supports the formalisation of scenarios, the elimination of possible ambiguities, and the translation from ADLs to UMLs. This paper makes the following key contributions:

      1) Based on combinational rule, we propose an extended ADL, called Breeze/ADL, that introduces new features for modelling scenarios, and an algorithm to reduce possible ambiguities in scenarios. We leverage the combination rule to borrow ideas from the vector clock algorithm[14] that produces positive results in determining event orders in distributed systems.

      2) Based on transformational rule, we choose UML as our target model and define mapping relations between Breeze/ADL and the UML sequence diagram. The mapping relations allow us to translate Breeze/ADL into UMLs, which allows integrating our approach with existing tools. A user may design more accurate architectures with our tool, and then translate these architectures to UML to gain the benefits of existing industry tools.

      3) A plugin of Breeze is implemented for our approach. The latest version of Breeze is now available at Github①. With the support of the extended Breeze, we conducted a case study on modelling a poetry to music system. The results show the effectiveness of our approach.

      The rest of the paper is organised as follows. Section 2 introduces the related work. Section 3 proposes the scenario modelling in Breeze/ADL. Section 4 presents combinational rule and Breeze/ADL. Section 5 presents transformational rule and the mapping between Breeze/ADL and UML. Section 6 presents a case study. Section 7 concludes.

    • Creative computing. With the rapid development of information technology, a great deal of novel computing emerges, such as Google search engine and Facebook, which make human life much more convenience and colorful. This kind of computing could be considered as creative computing. The nature of creative computing, grammatically, focuses on the term “creative”. It can be seen that the meaning of creativity is the core of creative computing.

      Creativity can be defined as the ability to generate novel and valuable ideas[15]. If we look carefully at many examples of human creativity that surrounds us, we can see that there are three different ways in which creativity occurs. Novel ideas may be produced by combination, by transformation, or by exploration[16].

      Combinational creativity means to combine familiar ideas to produce unfamiliar ones, through making associations between ideas[16]. Examples include many cases of poetic imagery, collage in visual art, and mimicry of cuckoo song in a classical symphony. Analogy is a form of combinational creativity that exploits shared conceptual structure and is widely used in science as well as art.

      In transformational creativity, the space or style itself is transformed by altering (or dropping) one or more of its defining dimensions. As a result, ideas that can now be generated simply could not have been generated before the change[16]. For instance, if all organic molecules are basically strings of carbon atoms, then benzene cannot be a ring structure. In suggesting that this is indeed what benzene is, the chemist Friedrich von Kekule had to transform the constraint string (open curve) into that of ring (closed curve).

      Exploratory creativity rests on some culturally accepted style of thinking, or conceptual space[16]. This may be a theory of chemical molecules, a style of painting or music, or a particular national cuisine. The space is defined (and constrained) by a set of generative rules. Usually, these rules are largely, or even wholly, implicit. Every structure produced by following them will fit the style concerned, just as any word string generated by English syntax will be a grammatically acceptable English sentence. In exploratory creativity, the person moves through the space, exploring it to find out what′s there (including previously unvisited locations) and, in the most interesting cases, to discover both the potential and the limits of the space in question.

      In this paper, we propose related rules based on combinational creativity and transformational creativity.

      Scenario-based analysis of software architecture. Kazman et al.[3] analyse relations between quality attributes and scenarios, and also propose software architecture analysis method (SAAM)[17] and architecture trade-off analysis method (ATAM)[18] which became the foundation of many of scenario-based software architecture analysis methods. Lassing et al.[19] work on a similar research problem, with an emphasis on the impacts of complex scenarios. Lung et al.[20] present an approach that estimates the reusability of software architectures through scenarios. Bose[4] models scenarios with finite-state machines and verifies their consistency. Tekinerdogan et al.[2] propose an approach that analyses the reliability of software architecture. Yacoub et al.[5] propose a reliability analysis method that is based on scenarios of component interactions. Rodrigues et al.[21] propose a reliability prediction approach that is based on scenarios. Cheung et al.[6] employ scenarios to predict the reliability of concurrent systems. Williams and Smith[22] present a scenario-based approach that estimate performance at architecture level. The above approaches typically do not formally define scenarios. Although Bose[4] uses finite-state machines to model scenarios, it is not helpful to detect many ambiguities in sequence diagrams, e.g., the sample ambiguous sequence diagrams shown in Section 1, since finite-state machines do not define conditions for transitions either. Our work complements the preceding approaches, since it presents a formal language to define scenarios as well as puts forward an algorithm to reduce such ambiguities.

      Sequence diagram. In practice, the sequence diagram of UML is widely used to describe scenarios[23]. Fig. 1 shows an example sequence diagram, and we present more details on UML sequence diagrams in Section 5. Although it is popular, Pandey[1] complains that UML suffers the incapability of automated analysis, since it is informal. As a part of UML, sequence diagrams also have the same limitation. Furthermore, as shown by Sibertin-Blanc et al.[7], sequence diagrams may suffer from ambiguity. Our work complements the notation of sequence diagrams, since our extended Breeze/ADL is formal and it allows our algorithm to reduce ambiguities in scenarios.

      Figure 1.  An example of basic interaction

      Breeze/ADL. As the underlying ADL of our Breeze tool[8, 24], Breeze/ADL models software architecture in the formats of both XML and graphs. Fig. 2 shows the schema file of the existing Breeze/ADL. To support modelling scenarios, our work in this paper extends the Breeze/ADL in Fig. 2 with more elements. Furthermore, we propose an algorithm to reduce ambiguities of scenarios, and implement a translator from Breeze/ADL to UML sequence diagrams.

      Figure 2.  Schema for Breeze/ADL

    • The specification of UML② defines the concrete and abstract syntaxes of sequence diagrams. After inspecting elements of sequence diagrams, we find that the basic modelling elements in the BasicInteractions package of UML are quite useful. For example, most approaches in Section 2 use only these basic modelling elements. As a result, in this paper, we focus on these basic modelling elements.

      In this section, we present new elements to model scenarios (Section 3.1), and the vector clock algorithm to ensure that scenarios are defined without ambiguities (Section 4.2).

    • From the viewpoint of software architecture, scenarios are interactions among the components of a software system. Here, components can be many, and their interactions may be in parallel. To define scenarios formally, we need to focus on the two aspects of scenarios such as the definition of scenarios and the interactions among their components. In particular, we introduce four additional elements to define a scenario, and the formal definition of a scenario is as follows:

      Definition 1. Scenario=$\{$Description, ComponentList, MessageList, ParallelScenario$ \}$ represents a scenario, where:

      1) Description is a brief introduction of this scenario.

      2) ComponentList is a set of components that involve in a scenario $S$. Components in ComponentList follow the traditional definition of software architecture.

      3) MessageList denotes the messages among components, and each Message is defined in the next definition.

      4) ParallelScenario is a vector that defines possible active instances of scenarios. Here, in a vector $\{ {a_1}, {a_2}, \cdots, {a_m}\} $, ${a_i}$ denotes number of possible active instances of the $i {\text{-}} {\rm{th}}$ scenario $S_i$, and $m$ denotes the total number of scenarios. For example, if $S_1$, $S_2$, $S_3$ and $S_4$ are four scenarios and their vector is $ \{ {0}, {0}, {3}, {\infty}\}$, the first “0” and the second “0” denote that $S_1$ and $S_2$ cannot have active instance, “3” denotes that $S_3$ can have 3 active instances; and “${\infty}$” denotes that $S_4$ can have infinite active instances.

      Definition 2. Message=$ \{$SourceComponent, TargetComponent, VectorClock, Type$\}$ represents a message, where:

      1) SourceComponent is a component that sends a message.

      2) TargetComponent is a component that receives a message.

      3) VectorClock is a vector clock that defines timestamps of messages.

      4) Type is the type of a message. We define two types of messages, i.e., a request or a response.

      In Fig. 3, the left part shows the elements that are added to define scenarios, and the right part shows an example scenario that is defined in Breeze/ADL. In this example, the two components are Client and Server, and they are defined inside the componentlist label. The messages between the two components are defined inside the messagelist label, and the definition of a message includes its attributes such as type, source and target.

      Figure 3.  Added elements for Breeze/ADL and an example

    • Combinational rule leads to improve the result and reduce ambiguity in scenario-based software architecture analysis. The rule is described as below.

      Definition 3. A combinational rule (CR) is to combine different requirements modules ($x_i$) based on variety weights ($k_i$) (i.e., probability of the selected modules) for inferring related requirements modules ($y$) where $i$ is the index of the module. The formal definition of $CR$ is as

      ${k_0}{x_0} + {k_1}{x_1} + \cdots + {k_n}{x_n} \to y$

      (1)

      where $n$ is the total number of the possible modules, the sum of the $k_i (i=1, 2, \cdots, n)$ should equal to 1, i.e.,

      ${k_0} + {k_1} + \cdots + {k_n} = 1.$

      (2)

      By using the above rule, we define $x_0$ as Breeze/ADL model, and introduce the vector clock algorithm (see Section 4.2) as $x_1$. Thus the equation for our approach can be written as

      $\begin{array}{l} {k_0}(Breeze/ADLModel) + {k_1}(VectorClockAlgorithm) \to \\ \quad\quad{(Breeze/ADLModel)^\prime }. \end{array}$

      (3)
    • This section presents the vector clock algorithm that reduces ambiguities. After we present the details of the algorithm, we next illustrate the algorithm with the sample ambiguous sequence diagram as shown in Section 1.

      The vector clock algorithm is a kind of logical time which is widely used in distributed systems to define the partial order of events[14]. A partial order set[25] consists of a set and a binary relation. In such a set, a pair of elements $a \to b$ denotes that $a$ precedes $b$, and the relation is called a partial order. In a partial order set, the relation between two elements ($a$ and $b$) falls into three categories, $a \to b$, $b \to a$, or $a \ \| \ b$, where $a \ \| \ b$ denotes that there is no order relation between them.

      Algorithm 1 shows the detail of the vector clock algorithm. For a software architecture that contains $n$ components, we use $Arc = \{ {C_1}, {C_2}, \cdots, {C_n}\} $ to denote the architecture, where ${C_i}$ denotes the $i{\text{-}}{\rm th}$ component of $Arc$. In the algorithm, a component is associated with an $n$-dimensional, non-negative vector $v{t_i}[1 \cdots n]$, where $vt_i[i]$ records the timestamps of messages that are sent by $C_i$. The $n$-dimension vector of each component is initialised as a zero vector, and is updated according to the following rule. If component $C_i$ is about to send out a message $M$, our algorithm updates every dimension of its clock and chooses the message whose dimension is the biggest one happens before $M$. Here, our algorithm increases $vt_i[i]$ by 1 before $C_i$ sends the message. We assume that a component cannot send out more than one message at a time, so we separate messages by adding decimals. As the algorithm concisely define the partial order of message sending or receiving in scenarios, the ambiguity example in Section 1 will be eliminated.

      In our approach, the timestamps have the basic property of isomorphism. We find that the timestamps of $vt_i$ and $vt_j$ follow the three relations:

      1) $v{t_i}\! \le \!v{t_j} \!\Leftrightarrow \!\forall x \in [1, n]:floor(v{t_i}[x])\! \le \! floor(v{t_j}[x])$

      2) $v{t_i}\! < \!v{t_j} \! \Leftrightarrow \!v{t_i} \!\le\! v{t_j}\;{\rm{and}}\;\exists x \in [1, n]:floor(v{t_i}[x]) <$$ floor(v{t_j}[x])$

      3) $v{t_i}\;||\;v{t_j} \Leftrightarrow not(v{t_i} < v{t_j})\;{\rm{and}}\;not(v{t_i} > v{t_j}).$

      Here, $floor(x)$ rounds $x$ downward. For example, if $x=1.6$, $floor(x)$ returns 1.

      As the relation $ \to $ defines partial orders, timestamps of messages follow the two properties:

      ${m_1} \to {m_2} \Leftrightarrow vt_i^{{m_1}} < vt_j^{{m_2}}$

      (4)

      ${m_1}\;||\;{m_2} \Leftrightarrow vt_i^{{m_1}}\;||\;vt_j^{{m_2}}.$

      (5)

      Here, $m_1$ is a message sent by component $C_i$, and $m_2$ is a message sent by component $C_j$. Their timestamps are $vt_i^{m_1}$ and $vt_j^{m_2}$, respectively. For these two equivalence relations, if (4) holds, (5) also holds. As a result, we need to prove only (4). Furthermore, according to Algorithm 1, if $ {m_1} \to {m_2}$, $vt_i^{m_1} < vt_j^{m_2}$. As a result, we need to prove only $vt_i^{m_1} < vt_j^{m_2} \Rightarrow {m_1} \to {m_2}$, and the proof is as follows:

      1) $vt_i^{m_1} < vt_j^{m_2}$ and ${m_1} \ || \ {m_2}$.

      2) $vt_i^{m_1}=x$. The only way component $C_j$ can obtain a value for the $i {\text{-}} {\rm{th}}$ entry of its vector, is that at least $x$ is through a chain of messages originating from $C_i$ (at message $m_1$ or later).

      3) Such a chain implies that $m_1$ and $m_2$ are not concurrent. However, we find a contradiction, so the assumption does not hold. For example, if $vt_i^{m_1} < vt_j^{m_2}$, ${m_1} \to {m_2}$ or ${m_2} \to {m_1}$. At the same time, if ${m_2} \to {m_1}$, $vt_i^{m_2} < vt_j^{m_1}$. Here is a contradiction. Therefore, $vt_i^{m_1}\! < \! vt_j^{m_2}\! \Rightarrow \!{m_1}\! \to {m_2}$.

      4) In summary, (4) holds.

      In summary, there exists an isomorphism between the set of partial ordered messages and the timestamps that attach to them. As a result, timestamps are useful to determine the relations between two messages.

      We illustrate how to use our algorithm for detecting the ambiguity in the sequence diagram in Section 1. For simplicity, we assume that this scenario consists of only the three components (i.e., $A$, $B$ and $C$), and we assume that $B$ and $C$ do not send any messages before $m_1$ and $m_2$ are sent. Under this assumption, the timestamps of $m_1$ and $m_2$ are $\langle0, 1, 0\rangle$ and $\langle0, 0, 1\rangle$, respectively. If A needs both $m_1$ and $m_2$ to deliver $m_3$, the resulting timestamp of $m_3$ will be $\langle1, 1, 1\rangle$ to $m_3$. On the other hand, if A needs only $m_2$ (or $m_3$), the resulting timestamp of $m_3$ will be $\langle1, 1, 0\rangle$ (or $\langle1, 0, 1\rangle$). As every set of timestamps corresponds to a unique sequence, our approach detects an ambiguity, if more than one set of timestamps is produced during analysis.

      Algorithm 1. Vector clock algorithm

      1) Initialise the local clock for each component as a zero vector.

      2) if component $C_i$ is about sending a message $M$ then

      3)  dims $\leftarrow$ the total number of dimensions of $vt_i$

      4)  for $j=0$ to dims do

      5)   tol $\leftarrow$ all of the MessageOccurrenceSpecifications happen before sending $M$

      6)   for each MessageOccurrenceSpecifications $M_p$ in tol do

      7)    if $vt_i^{M_p}[j]>vt_i[j]$ then

      8)     $vt_i[j] \leftarrow vt_i^{M_p}[j]$

      9)    end if

      10)   end for

      11)  end for

      12)  $vt_i[i]=vt_i[i]+1$

      13)  while there exists another message $M_1$ on component $C_1$ whose $vt_i^{M_1}[i]$ equals $vt_i[i]$ do

      14)   $vt_i[i] \leftarrow vt_i[i]+0.1$

      15)  end while

      16)  timestamp $M$ with clock $vt_i$ and send it

      17) end if

    • Transformational rule leads to change the thinking pattern of users and provides more practical way to implement it in the industry area. The rule is inspired by machine learning algorithm. To be specific, we borrow some ideas from decision tree[26] which helps us determine the transformation directions. The rule is defined as follows:

      Definition 4. A transformational rule (TR) is to retrieve the module ($x'$) which has the maximum entropy ($E$) based on the current requirements module ($x_i$) according to the users′ preference ratio ($k_i$) (i.e., weight for the module feature). The formal definition of $TR$ is as

      $\max ({E_1} \times {k_1}, {E_2} \times {k_2}, \cdots, {E_n} \times {k_n}) \to x'$

      (6)

      where $n$ is the total number of the possible modules, $E_i$ is entropy of module $x_i$ and the sum of the $k_i$ should equal to 1, i.e.,

      ${k_0} + {k_1} + \cdots + {k_n} = 1.$

      (7)

      Here we consider some popular models which are used to model architecture in the high level in different areas. The candidate models are selected as Petri net, UML model, architecture analysis and design language (AADL) model and layered queueing network (LQN) model. The above equation can be written as

      $\begin{split}& \max ({E_{Petri}} \times {k_1}, {E_{UML}} \times {k_2}, {E_{AADL}} \times \\ & \quad\quad {k_3}, {E_{LQN}} \times {k_n}) \to GeneralModel.\end{split}$

      (8)

      According to the domain expert experience, the UML is the most popular modelling language in industry area and the corresponding entropy is the maximum.

    • To make our approach more general, we provide a set of mapping rules between Breeze/ADL and UML. The benefit of mapping is that we can combine the advantages of both ADL and UML. The combination not only supports formally modelling scenarios at architecture-level, but also allows translating scenarios from Breeze/ADL to UML sequence diagrams that are supported by industrial tools, e.g., rational rose, enterprise architect (EA), and PowerDesigner.

      As EA is a professional and famous tool in industry, our approach translates scenarios from Breeze/ADL to EA style XML files. In this section, we define the mapping relations in the concrete syntax (Section 5.2) and the abstract syntax (Section 5.3), respectively.

    • To illustrate the mapping relations, we first present the concrete syntax of sequence diagram (CSSD).

      Definition 5. CSSD=$\{$Lifeline, Message, MessageOccurrenceSpecification, ExecutionSpecification$ \}$ is the concrete syntax of sequence diagrams, where

      1) Lifeline is a set of participants of an interaction and a participant is defined as a component in Breeze/ADL.

      2) Message is an invocation/response among components.

      3) MessageOccurrenceSpecification specifies the occurrence of the events, e.g., sending and receiving of messages, or invoking and receiving of operation calls. As defined in UML&#9314;, it is a type of messages.

      4) ExecutionSpecification is a specification of the execution or an action within a Lifeline.

      As in Breeze/ADL, components in componentlist correspond to lifelines in the sequence diagram, Fig. 4 illustrates the mapping rule. The invocations in Breeze/ADL are mapped to messages between lifelines in sequence diagrams. In sequence diagrams, a message has two attributes including a type (source or target) and a label. In particular, sequence diagrams use solid arrows to denote requests, and dot arrows to denote responses. Our approach maps these attributes to the corresponding attributes in Breeze/ADL.

      Figure 4.  Component and message translation

      Each message in Breeze/ADL corresponds to two events, i.e., a request and a response, in sequence diagrams. Our approach translates these events into MessageOccurrenceSpecification elements in sequence diagrams. As a result, each lifeline may have many MessageOccurrenceSpecification elements. In sequence diagrams, the interval between the earliest and latest MessageOccurrenceSpecification elements on the lifeline is specified by the ExecutionSpecification element. For example, the sequence diagram in Fig. 1 includes two MessageOccurrenceSpecification elements on Client, i.e., sending request and receiving response. The timestamp of sending request $\langle1, 0\rangle$ is smaller than that of receiving response $\langle1, 1\rangle$, which means that sending request happens before receiving response. Fig. 5 shows an example translation from Breeze/ADL to sequence diagrams. The event order is encoded in the ExecutionSpecification element of the lifeline.

      Figure 5.  Translation of execution specification

    • The abstract syntax of sequence diagrams is defined in the meta-modelling language of UML. In particular, several fragments are related to sequence diagrams, e.g., the BasicInteractions package and the Fragments package. Breeze/ADL focuses on the elements in the BasicInteractions package, and it covers lifelines, messages, message ends, interactions, and general orders of sequence diagrams. Fig. 6 shows the relations among these elements. In particular, a GeneralOrdering element denotes a binary relation among OccurrenceSpecification elements, and the binary relation defines that an OccurrenceSpecification element must occur before the other in a valid trace. This mechanism allows defining partial orders of OccurrenceSpecifications. When using the sequence diagram to depict scenarios, the partial order depicted by vector clock between messages is mapped to the GeneralOrdering. When transforming Breeze/ADL into sequence diagrams, our approach infers partial orders between messages by comparing their timestamps, which is based on the isomorphism property of the vector clock algorithm.

      Figure 6.  Part of the abstract syntax of the basic interactions package

    • We implemented our approach as a plugin of Breeze, and with the support of the tool, in this section, we illustrate our approach using a poetry to music system. The latest version of Breeze is available at Github:

      https://github.com/BreezeCSA/Breeze

    • The implementation of the poetry to music system should follow the model view controller (MVC) framework&#9315;. As defined in the framework, the requests from customers are delivered to control components, and components further invoke function modules to accomplish functionalities that are requested by customers. For simplicity, we focus on the functionalities of querying poetry style and generating related music list. To accomplish the two tasks, the system should at least implement the functionalities in the following scenarios:

      1) Loginning ($S_1$). Customers sign in the poetry to music system with their usernames and passwords.

      2) Querying poetry style information ($S_2$). Customers query poetry with keywords, and find their corresponding style.

      3) Generating candidate music list ($S_3$). According to poetry style, the system retrieval music library and generate candidate music list.

      4) Confirmation ($S_4$). The system arrange the music list and return results to customers.

      We focus on only modelling $S_3$, due to space limit. Following the model view controller (MVC) framework, when a customer enters keywords, the ${\rm WebUI}$ component sends a request, Generate candidate music list, to the Control component. To accomplish this request, the Control component retrieves the poetry style and customer information from the PoetryStyleInfo component and the CustomerInfo component, respectively. After that, the Control component returns the information to the WebUI component, and the latter component presents the feedback to the customer.

    • According to the requirements as described in Section 6.1, with UML, the best choice for a designer is to draw a sequence diagram to describe $S_3$. Fig. 7 shows such an example, and it presents many details of $S_3$ (e.g., components and their messages). However, when developers implement the system according to the sequence diagram, they may easily become confused. For example, a developer may wonder whether there exists a strict order between RequestPoetryStyleInfo and RequestCustomerInfo, and whether both PoetryStyleInfo and CustomerInfo are required or only one of them is required before Reply.

      Figure 7.  Scenario of generating candidate music list ($S_3$) illustrated in a sequence diagram

    • As introduced in Section 2, Breeze supports two modelling languages such as Breeze/ADL and its graph format. Fig. 8 shows the built architecture of the poetry to music system, in both formats. In particular, the upper part of Fig. 8 shows the WebUI and Control components in Breeze/ADL. Due to space limit, we do not present the definitions of the other components. The Breeze/ADL file defines the ports of the two components and the interactions among these ports. According to directions of their messages, ports have three types such as $in$, $out$ and $inout$. An interaction is defined as an edge between two ports. For example, $ \left\langle {} \right.$edge ID=“e1” source=“p12” target=“p21”$\left. {} \right\rangle$ denotes an $e_1$ interaction from the $p_{12}$ port to the $p_{21}$ port. The lower part of Fig. 8 shows the architecture of the whole poetry to music in the graph format of Breeze/ADL. In the graph, the small rectangles adhering to components represent ports, and lines represent interactions between ports.

      Figure 8.  Software architecture of poetry to music system

    • Our extension first encodes the components and their messages of the architecture in Section 6.3. Fig. 9 shows the encoded architecture in Breeze/ADL. In the encoded Breeze/ADL file, the components in this scenario are defined in the componentlist tag, and the messages among the components are defined in the messagelist tag. The ParallelScenario vectors of scenarios are defined in the parallelscenario tag. The parallelscenario of $S_3$ is $\langle \infty, \infty, \infty, 0\rangle$, which means that the execution of $S_3$ has no impact on $S_1$, $S_2$, or itself, and $S_3$ cannot run in parallel with $S_4$, since a user has to input keywords before returning the results to customers.

      Figure 9.  Scenario of generating candidate music list ($S_3$) illustrated in Breeze/ADL

      Each component is associated with a vector. As $S_3$ contains 5 components, a timestamp in this scenario is a 5-dimension vector. According to Algorithm 1, the vectors are set to zero vectors initially. When the WebUI component sends the message Generate candidate music list, Breeze updates the timestamp of the component by executing $vt_1[1] \leftarrow vt_1[1]+1$, and attaches the new timestamp, $\langle 1, 0, 0, 0, 0\rangle$, to the message Generate candidate music list. When other messages such as RequestPoetryStyleInfo, SearchPoetryStyleInfo, SearchCustomerInfo, PoetryStyleInfo, CustomerInfo and Feedback are sent, Breeze updates their vectors in a similar way.

      When the Control component sends the RequestCustomerInfo message, Breeze executes $vt_2[2] \leftarrow vt_2[2]+0.1$, and the adaption avoids its timestamp from equaling to the timestamp of RequestPoetryStyleInfo. As Reply is the last message that involves the PoetryStyleInfo component and the CustomerInfo component, the timestamps of the two components become the largest, after sending the message.

      After the timestamps are calculated, Breeze presents the partial order between these messages. In this scenario, there is no partial order between messages RequestPoetryStyleInfo and RequestCustomerInfo, since $floor(vt_{i}^{PoetryStyleInfo})=floor(vt_{i}^{CustomerInfo})$. It is also very convenient for developers to obtain the information from these timestamps that both message PoetryStyleInfo and CustomerInfo are needed to deliver message Reply. As each set of timestamps corresponds to a unique condition and sequences of events, a designer is able to determine which sequence best fits the requirements by choosing the correct set of timestamps.

      Breeze allows translating the scenario from Breeze/ADL to a UML sequence diagram. Based on the mapping rules, each component is translated to a lifeline. In the sequence diagram, Breeze fills in ExecutionSpecification elements based on the timestamps of the MessageOccurrenceSpecification elements.

      In this example, the designer decides that the following timestamps best fit the desirable functionality:

      1) RequestPoetryStyleInfo ($\langle1, 1, 0, 0, 0\rangle$)

      2) RequestCustomerInfo ($\langle1, 1.1, 0, 0, 0\rangle$)

      3) Reply ($\langle1, 1.1, 1, 2, 2\rangle$)

      4) Feedback ($\langle1, 2.1, 1, 1, 2\rangle$).

      Based on the timestamps, Breeze determines the order of the four messages, and encodes the event order in the ExecutionSpecification element of the lifeline.

    • This section illustrates how to use Breeze to model and to translate scenarios step by step.

      Step 1. Adding scenarios. As introduced in Section 6, after modelling the software architecture of the poetry to music system (Fig. 8), we add the corresponding scenarios such as Login, Query poetry style information, Generate candidate music list, and Confirmation (Fig. 10).

      Figure 10.  Adding scenarios

      For each scenario, the user of Breeze needs to specify its name, ID, and scenarios that can run in parallel run with the scenario.

      Step 2. Initialising scenarios. The user of Breeze needs to initialise each scenario by adding all involved components and messages. Fig. 11 shows the component list and the message list of the $S_3$ scenario. The columns in the message list correspond to the attributes that are defined in Breeze/ADL.

      Figure 11.  Adding components and messages

      Step 3. Generating scenario model. Breeze generates scenarios in Breeze/ADL, when its user clicks the corresponding button in Fig. 10.

      Step 4. Translating scenarios. Breeze translates scenarios from Breeze to sequence diagrams, when its user clicks the Generate UML button in Fig. 10. Breeze generates sequence diagrams that are in the format of enterprise architect. EA displays translated sequence diagrams in its editor, and elements of scenarios in its project browser. Fig. 12 shows the translated $S_3$ scenario.

      Figure 12.  Scenario generate candidate music list in enterprise architect

    • In this paper, we reduce ambiguity in scenario-based software architecture analysis by proposing a creative scenario modelling and analysing approach, based on our extended Breeze/ADL, which facilitates designers to define scenarios in an unambiguity way. The modelling results are useful to support subsequent scenario-based analysis at architecture level. In addition, to combine the advantages of both Breeze/ADL and UML, we propose a set of rules for model transformation. These rules allow us to translate scenarios from Breeze/ADL to sequence diagrams automatically.

      There are still some issues that should be addressed in our next step work. As Breeze does not support all the elements in sequence diagrams, it cannot eliminate all ambiguities in sequence diagrams, but we plan to introduce exploratory rule to add more related elements in future work. In addition, we plan to extend Breeze, so it can translate existing sequence diagrams into Breeze/ADL for scenario-based software architecture analysis.

    • This work was partially supported by the Japam Society for the Promotion of Science (JSPS) KAKENHI (Nos. 25420232 and 16K06203).

Reference (26)

Catalog

    /

    DownLoad:  Full-Size Img  PowerPoint
    Return
    Return