From System Specifications to Component Behavioral Models
Total Page:16
File Type:pdf, Size:1020Kb
From System Specifications 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 fkrka,gedwards,ybrun,[email protected] 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) re- quired 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 implemen- tation 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 inter- face 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 op- erations. 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