From System Specifications to Component Behavioral Models

From System Speciﬁcations to Component Behavioral Models

Ivo Krka, George Edwards, Yuriy Brun, and Nenad Medvidovic Computer Science Department University of Southern California Los Angeles, CA 90089-0781, USA {krka,gedwards,ybrun,neno}@usc.edu

Abstract express partial but straightforward views of the system that are useful for communicating intent among stakeholders. Early system specifications, such as use-case scenarios Numerous existing techniques [4,9, 10, 11] leverage sce- and properties, rarely completely specify the system. Partial nario and/or property specifications to derive concrete be- models of system-level behavior, derived from these speci- havioral models of system components that can be lever- fications, have proven useful in early system analysis. We aged for architectural analysis and assessment. However, believe that the scope of possible analyses can be enhanced these approaches ignore the partial and limited nature of by utilizing component-level partial models. In this pa- such specifications by attempting to generate complete be- per, we outline an algorithm for deriving a component-level havioral models. Instead, we argue that designers need for- Modal Transition System (MTS) from system-level scenario mal models that describe systems in terms of (1) behavior and property specifications. The generated MTSs capture required by the scenarios, (2) behavior prohibited by the the possible component implementations that (1) necessar- constraints, and (3) potential behavior that is neither re- ily provide the behavior required by the scenarios, (2) required nor forbidden by the specifications. strict behavior forbidden by the properties, and (3) leave the Recently, researchers have developed automated pro- behavior that is neither explicitly required nor forbidden as cesses for deriving Modal Transition Systems (MTSs) [3], undefined. We discuss how these generated models can help a partial behavior modeling formalism, from system sce- discover system-design flaws, support requirements elicita- narios and properties [6,7]. An MTS describes the be- tion, and help select off-the-shelf components. havior of a system via states with transitions, which are labeled as either required or potential transitions. MTSs have proven useful in requirements elicitation, architectural 1 Introduction refinement [6,7], and verification that a system implementation satisfies specified properties [2]. Design activities that take place during the early phases Current approaches to MTS derivation adopt a system- of system development, such as elicitation, definition, and wide view and synthesize only system-level MTSs. How- refinement of requirements, occur in the context of incom- ever, modern systems are typically built from indepen- plete information and uncertainty. These activities benefit dent components, and behavioral models that exploit a from, and also result in, partial system specifications that component-oriented perspective are required for rigorous capture high-level system behavior while deferring many architectural analysis. We are developing algorithms and decisions to subsequent design phases. Two commonly methods for (1) deriving component-level MTSs from sys- used types of such specifications are (1) scenarios (e.g., tem-level scenarios and properties, and (2) leveraging com- UML sequence diagrams) that model examples of impor- ponent-level MTSs in system development. tant system use cases, and (2) properties (e.g., OCL con- In this paper, we outline our algorithm for component- straints) that model conditions and constraints on as well as level MTS generation from system scenarios and properties relationships among system elements. (Section3) and describe how our algorithm can help dis- Scenarios and properties form a basis for gradual defi- cover system-design flaws (Section4). We also envision nition and refinement of system requirements and architec- component-level MTSs (1) assisting in requirements elic- ture, and can be used for early system analysis (e.g., dis- itation, (2) supporting selection of candidate off-the-shelf covery of design defects and conflicting requirements). The components, and (3) enabling comparison of as-intended utility of scenarios and properties arises from their ability to and as-implemented systems.

ICSE’09, May 16–24, 2009, Vancouver, Canada 978-1-4244-3494-7/09/$25.00 c 2009 IEEE 315 Companion Volume Scenario: Constraints: System specifications Phase 3 Sequence Client Cache Server requestCacheData() responseCacheData() SDs Diagram requestServerData() pre: cached = true annotation post: responseServerData() OCL constraints Annotated sequence responseCacheData() requestServerData() diagrams pre: cached = false OCL, SDs, requestCacheData() post: interfaces Component- Phase 4 responseCacheData() responseServerData() level constr. Final MTS pre: generation generation post: cached = true Phase 1 Interfaces: Client Final MTSs provided: dataUpdate() Initial MTSs responseCacheData() pre: OCL constraints post: cached = false Cache Initial MTS provided: Server dataChanged() generation requestCacheData() provided: pre: Phase 2 responseServerData() requestServerData() post: cached = false dataChanged() dataUpdate() Figure 2. Phases of the MTS-generation algorithm Figure 1. Scenario, property, and component interface specifications for a web cache system. specification, which is not realistic during early design [8]. The work we present here addresses this problem by generating partial component-level behavioral models from 2 Background and Related Work partial system-level specifications. Furthermore, the main conceptual distinction between our work and the work done in [6,7] is that we generate component-level MTS models In order to ease the adoption of our techniques, we em- as opposed to the system-level MTS models. By moving the ploy previously defined specification formalisms that are al- focus from the system-wide perspective to a component- ready in widespread use [3,5]. We use basic UML sequence level perspective, we enable the benefits outlined in Sec- diagrams [5] to depict scenarios and OCL [5] to capture in- tion1. tended system properties. Like other research on behavioral models [8, 10], we leverage only a subset of OCL: con- junctive (AND) clauses of Boolean expressions on system 3 Generating Component-Level MTSs variables that define pre- and postconditions of system operations. Figure1 illustrates an example specification of a In this section, we outline our algorithm for generating web cache system (described in further detail in Section3). component-level MTSs from scenario and property spec- The MTS [3] formalism extends on the LTS formal- ifications. Figure2 depicts four phases of the algorithm. ism [9] to permit modeling of potential transitions (in ad- The inputs to the algorithm are UML sequence diagrams dition to required transitions). The strong refinement rela- describing system execution scenarios and OCL constraints tion [1] of MTSs results in the conversion of potential tran- defining pre- and postconditions on component operations. sitions into required transitions or removal of the potential The scenarios can be defined on different sets of compo- transitions, based on new knowledge about system behav- nent operations, while the OCL constraints are defined on a ior. MTS N is a refinement of MTS M if and only if every set of system state variables. Additionally, we assume the required transition in M is also required in N and every po- availability of provided interface specifications for system tential transition in N is also potential in M. We refer the components, e.g., such as those typically provided in UML reader to [1] for formal, complete definitions of MTSs and class diagrams. the strong refinement relation. The algorithm first derives component-level constraints In related work, Whittle and Schumann [10] proposed (Phase 1), which are later used to define the state space an algorithm to generate component statecharts from sce- of generated MTSs (Phase 2) and derive the conditions narios and properties. Makinen¨ and Systa¨ [4] developed a on system state variables under which scenarios can exe- semi-automated approach for synthesizing statecharts from cute (Phase 3). The returned set of component-level MTSs sequence diagrams with architect guidance. The method (Phase 4) requires all behavior specified in scenarios and of Ziadi et al. [11] synthesizes component statecharts from allows behavior that does not conflict with component-level sequence diagrams with complex constructs (such as refer- constraints as potential behavior. ences, loops, and forks). Finally, Uchitel et al. [9] put for- Figure1 depicts an example specification for a simple ward a technique to generate component-level LTS models web caching system. In the given scenario, a Client requests and compose those models to discover implied scenarios. data from the Cache, which then fetches the data from the All four of the above approaches presume complete system Server. The Cache handles the subsequent request from the

316 Client. We now provide the functional descriptions of the agrams. For component A, we refine potential behavior in phases of the algorithm. the initial MTS by adding required behavior captured in Phase 1: Component-level constraint generation. The the corresponding annotated scenario. A potential transi- first phase of our algorithm translates the system-level con- tion from state S to state P on operation o is changed to a straints, defined on system state variables, into constraints required transition if the scenario annotation (i.e., expres- on the behavior of each component. First, using the OCL sion truth assignments) before o is satisfied in S, and the constraints, we determine which system state variables scenario annotation after o is satisfied in P . We also refine (called component’s relevant state variables) constrain invo- state P into two new states P1 and P2, each one account- cations of each component’s required operations. Second, ing for a particular subset of P ’s incoming transitions. Both for each component, we determine which constraints (called P1 and P2 have the same outgoing transitions as P . Fig- the component-level constraints) contain only the expres- ure3 shows the final MTS for the Cache component with sions from the pre- and postconditions of that component’s potential transitions marked with “?” and required transi- interface operations defined on that component’s relevant tions in bold. There are no required transitions for opera- state variables. For example, the Client from Figure1 does tion dataChanged as this operation does not appear in the not have any relevant state variables as the specifications scenario specification. Further, from the final MTS, we can do not constrain the Client in sending requests to Cache. observe that cached changes from false to true during the Cache, however, has cached as the relevant state variable responseServerData operation. because Cache’s behavior is constrained by the value of cached. Cache’s component-level constraints are thus de- 4 Utilizing Component-Level MTSs fined on cached. Phase 2: Initial MTS generation. The second phase In this section, we outline the design flaws our MTS gen- of our algorithm creates initial component MTSs that cap- eration process can discover and discuss potential uses of ture all potential behaviors of components, i.e., behaviors component-level MTSs. Component-level MTSs can facil- that are not proscribed by component-level constraints from itate a number of benefits, including: (1) requirements elic- Phase 1. We construct the initial MTS for a component itation, (2) selection of candidate OTS-components, and (3) A as follows. First, we create a set of states, such that comparison of designed and implemented components. each state is assigned a unique truth assignment of the ex- Discovery of specification discrepancies. The annota- pressions in A’s component-level constraints. We then add tion of sequence diagrams (Phase 2) directly exposes two a potential transition labeled o from each state S to each types of potential problems in system specifications: con- state P if and only if the preconditions of o hold in S and flicts between the specified scenarios and properties and the the postconditions of o hold in P . For example, the ini- presence of inconsistent component states. Discrepancies tial MTS of the Cache has a potential transition labeled between scenarios and properties occur when constraints responseServerData from state cached = false to state prohibit the sequence of operations described in a sequence cached = true. diagram. A discrepancy may be the result of either overly Phase 3: Sequence diagram annotation. The third restrictive constraints or misspecified scenarios. Inconsis- phase of our algorithm derives the conditions under which tent states arise when multiple components’ expected values the given scenarios can execute. The scenario specifications for a system state variable differ. convey information about the sequences of events the sys- Requirements elicitation. Eliciting requirements from tem should exhibit, but usually do not provide information system-level MTSs, as in [7], can introduce design flaws be- about the conditions under which these sequences can ac- cause requirements gathered using a system-level perspec- tually execute. We address this issue in a manner similar tive can conflict with what is implementable at the com- to Whittle et al. [10]: for each component, we annotate ponent level. For example, a new scenario extracted from that component’s interactions in each scenario with the truth a system-level MTS might only be possible when all par- assignments of component-level constraint expressions that ticipants have global knowledge. However, this assump- must be satisfied before and after the interaction occurs. For tion does not hold in component-based systems without in- instance, this phase of our algorithm discovers that, from curring significant synchronization overhead. On the other Cache’s perspective, cached must initially be false but must hand, eliciting requirements using component-level MTSs ultimately be true in the given scenario. This phase of the provides some assurance that inconsistent assumptions are algorithm also discovers discrepancies between the scenario not introduced. In the web cache system, the Cache MTS and property specifications. can serve as the basis of new requirements such as: (1) the Phase 4: Final MTS generation. The last phase of dataChanged operation may be invoked at any time, and our algorithm produces desired component-level MTSs by (2) requestServerData shall be invoked only when there combining the initial MTSs and the annotated sequence di- is a pending Client request.

317 RPS? RQC? RQS? RPS?

DC? RQC RQC RQS RQS? RPS RPS? RPC RPC? RQC RQC?

S0 S1 S2 S3 S4 S5

RPS? DC? RQC RPC RPS? dataChanged = DC DC? requestCacheData = RQC DC? requestServerData = RQS responseServerData = RPS DC? responseCacheData = RPC DC?

Figure 3. Generated component-level MTS for a web cache component

Off-the-shelf (OTS) component selection. Modern ing it with other model synthesis techniques, and (3) im- component-based systems rely heavily on reuse. However, plement tool support for creating and utilizing component- OTS-component selection processes are often based on ad- level MTSs. We will assess the tractability and usability hoc and labor-intensive analyses of stakeholder interests. of all four ways of utilizing MTSs described in this pa- Component-level partial behavioral models can guide the per. We envision the automated generation of component- OTS-component selection process because they capture the level MTSs greatly influencing the early system develop- required behavior that must be implemented in the final ment processes. system and the potential behavior that is neither explicitly required nor prohibited by the requirements. Component- References level MTSs may thus be used to mine OTS-component repositories for suitable components that exhibit the re- [1] D. Fischbein and S. Uchitel. On consistency and merge of quired behavior and possibly provide a subset of the po- modal transition systems. In Proc. of FSE, 2008. tential behavior. [2] P. Godefroid, M. Huth, and R. Jagadeesan. Abstraction- As-intended vs. as-implemented system comparison. based model checking using modal transition systems. In Generated component-level MTSs capture architects’ in- Proc. of CONCUR, 2001. tent, as defined in scenarios and properties. However, the [3] K. G. Larsen and B. Thomsen. A modal process logic. Logic implemented system might differ significantly from those in Computer Science, 1988. intentions. While comparing whole-system behavior to the [4]E.M akinen¨ and T. Systa.¨ MAS — an interactive synthesizer specification is a complex task, component-level compari- to support behavioral modelling in UML. In Proc. of ICSE, 2001. son may be far simpler. Further, identification of differences [5] D. Pilone and N. Pitman. UML 2.0 in a Nutshell. O’Reilly between the specification and the implementation may as- Media, Inc., 2005. sist analysis of potential risks associated with providing [6] G. Sibay, S. Uchitel, and V. Braberman. Existential live se- functionality that was not originally intended and/or remov- quence charts revisited. In Proc. of ICSE, 2008. ing or modifying functionality that was nominally required. [7] S. Uchitel, G. Brunet, and M. Chechik. Behaviour model synthesis from properties and scenarios. In Proc. of ICSE, 2007. 5 Summary [8] S. Uchitel, J. Kramer, and J. Magee. Behaviour model elaboration using partial labelled transition systems. In Proc. of Generating component-level MTSs from system-level FSE, 2003. scenario and property specifications detects discrepancies [9] S. Uchitel, J. Kramer, and J. Magee. Incremental elaboration within the specifications, assists further requirements elici- of scenario-based specifications and behavior models using tation, facilitates OTS-component selection, and can verify implied scenarios. ACM TOSEM, 13(1), 2004. the consistency of a component’s implementation with its [10] J. Whittle and J. Schumann. Generating statechart designs specification. Our planned next steps are to (1) prove our from scenarios. In Proc. of ICSE, 2000. [11] T. Ziadi, L. Helouet, and J.-M. Jezequel. Revisiting state- algorithm’s correctness by ensuring that it does not create chart synthesis with an algebraic approach. In Proc. of ICSE, conflicts with the specifications under any circumstances, 2004. (2) evaluate its utility on real-world systems, also compar-

318