i2MAP: An Incremental and Iterative Modeling and ... - CiteSeerX

i2 MAP: An Incremental and Iterative Modeling and Analysis Process Sascha Konrad,1, Heather J. Goldsby,2 and Betty H.C. Cheng2, 1

Siemens Corporate Research, Inc. 755 College Road East Princeton, NJ 08540 USA 2 Software Engineering and Network Systems Laboratory Department of Computer Science and Engineering Michigan State University, 3115 Engineering Building East Lansing, Michigan 48824 USA [email protected],{hjg,chengb}@cse.msu.edu

Abstract. Detecting errors early within the development process for an embedded system assists a developer in avoiding excessive error correction costs and minimizing catastrophic losses resulting from failures in deployed systems. Towards that end, this paper presents i2 MAP, an iterative and incremental goal-driven process for constructing an analysislevel UML model of an embedded system. The UML model is formally analyzed for adherence to the behavioral properties captured in a companion goal model. The process uses goal modeling to capture the requirements of the system, and uses UML to capture analysis-level structural and behavioral information. Both types of i2 MAP models can be used to drive a rigorous approach to model-driven development of embedded systems. In this paper, we illustrate the i2 MAP process and the accompanying tool suite in the development of an embedded system model for an adaptive light control system.

1

Introduction

The cost of correcting errors introduced early in the development process is significantly more expensive than the cost of correcting errors introduced in later stages [1]. To further exacerbate this problem, the increasingly popular model-driven development, such as that promoted for use in the model drivenarchitecture (MDA) by the OMG [2], successively refines models from analysis to design and eventually to code. Thus, undetected errors may be propagated from

This work has been supported in part by NSF grants EIA-0000433, CDA-9700732, CCR-9901017, CNS-0551622, CCF-0541131, Department of the Navy, Office of Naval Research under Grant No. N00014-01-1-0744, Eaton Corporation, Siemens Corporate Research, and a grant from Michigan State University’s Quality Fund. A significant portion of this work was completed while this author was a doctoral student at Michigan State University. Please contact this author for all correspondences.

G. Engels et al. (Eds.): MoDELS 2007, LNCS 4735, pp. 451–466, 2007. c Springer-Verlag Berlin Heidelberg 2007

452

S. Konrad, H.J. Goldsby, and B.H.C. Cheng

analysis models created early in the development process to code, potentially resulting in expensive correction costs. Within the embedded systems domain, the detection of errors is particularly important, not only because of the high costs of error detection and correction, but also because failures of embedded systems may lead to catastrophic losses [3]. In addition to correctness, embedded systems also need to balance several, often contradictory non-functional system qualities, such as performance and development cost [4]. This paper presents i2 MAP (iterative and incremental Modeling and Analysis Process), an iterative and incremental process for constructing an analysis-level UML model of an embedded system, which is guided by an accompanying goal model. While the UML model contains structural and behavioral information, the goal model captures high-level requirements and behavioral properties to which the model should adhere. As part of i2 MAP, the UML model is formally analyzed for adherence to the behavioral properties. Iterative and incremental development practices are advocated by numerous software development processes, such as the Spiral Model [5] and the Rational Unified Process (RUP) [6]. Generally, iterative development constructs increasingly more complex versions of software development artifacts [7], such as UML models or code. Using this strategy, these processes enable developers to detect errors and conceptual misunderstandings of requirements sooner, and incorporate feedback from previous iterations. Several researchers have attempted to combine iterative development practices with the use of formal methods [8, 9, 10]. In contrast to our approach, they have either focused on specification languages other than UML [8] or do not support formal analysis [9, 10]. In addition, none of the aforementioned approaches includes support for goal modeling. i2 MAP uses two different types of models to capture complementary information. A goal model is used to capture high-level functional and non-functional requirements and their rationale. Behavioral properties to which the system should adhere are captured as constraint goals in the goal model, which are specified in terms of formally-analyzable natural language properties. In addition, a UML model is used to capture an operationalization of the requirements in terms of structural and behavioral UML diagrams. Both of these models are realized in increments, where each increment represents the addition of specific functionality to the models. Specifically, the goal model is augmented with goals to capture the functionality that is required for the current increment, while the UML model is extended with structural and behavioral diagram elements realizing the increment’s functionality. These modifications to the models are performed in iterations, each of which comprises three phases: (1) the goal model is augmented, (2) the UML model is extended to adhere to the goal model, and (3) both models are formally analyzed for behavioral consistency. In addition, traceability techniques are used to check the models for syntactic consistency [11]. If errors in either the goal or UML model are uncovered during the analysis, then these errors need to be corrected in a subsequent iteration before progressing to the next increment. The process is complete when all requirements for the system

i2 MAP: An Incremental and Iterative Modeling and Analysis Process

453

have been captured in the models. Requirements that have not been realized yet are evident as goals missing from the goal model. i2 MAP leverages and extends several previously developed methods and tools to create a comprehensive modeling and analysis process supported by a research prototype tool suite. To assist the developer in augmenting the models for realizing an increment, we have developed Cobra (Constraints and Objects for Requirements Analysis) patterns [12] that provide goal model templates and UML diagram templates to capture analysis-level structural and behavioral information of the system. The details of the Cobra patterns are described in [12]; here we only overview the patterns. The goal model template declaratively specifies the functional and non-functional requirements of the embedded system using softgoals, and refines the requirements into system constraints using a structured natural language. The UML model template operationally specifies, at the requirements-analysis level, UML elements that satisfy the requirements. Structural information is captured using UML class diagrams, while behavioral information is captured using UML state diagrams. Syntactic consistency can be established between the goal model and the UML structural diagrams using traceability techniques [11]. Behavioral consistency can be established between the goal model and the UML behavioral diagrams by formally analyzing the UML models for adherence to the constraints from the goal model. In order to translate UML models to formal specifications, we use Hydra [13], a previously developed metamodel-based UML formalization framework. To translate the natural language constraints into formal specifications, we leverage Spider [14], a customizable natural language specification environment, to generate the corresponding temporal logic formulae. In this paper, we illustrate the i2 MAP approach and tool suite through the development of an adaptive light control system. Overall, i2 MAP combines UML and goal modeling, the accessibility of natural language descriptions, and the rigor of formal analysis to support an incremental process for creating and refining requirements-level models. The remainder of the paper is organized as follows. Section 2 briefly overviews Cobra patterns. Section 3 describes the i2 MAP process and presents our supporting tool suite. Section 4 applies the process to the development of an adaptive light control system. Section 5 examines related work. Finally, in Section 6 we present conclusions and discuss directions for future work.

2

Cobra Patterns

Cobra patterns have been designed to assist developers in the creation of complementary UML and goal models for the requirements analysis of embedded systems. Specifically, the goal model captures non-functional requirements and declaratively specifies functional requirements and constraints and the UML model operationally specifies behavior that satisfies the requirements. To date, the Cobra patterns have focused on capturing sensors and actuators, specifying the behavior of important system components, and capturing interaction with

454


the user. While this section briefly overviews the Cobra patterns, details of the patterns are described in [12]. Goal models, in general, specify both functional and non-functional system objectives and the relationships between objectives. Developers can use goal models to evaluate alternative solutions and to document the rationale behind requirements [15]. Our Cobra patterns contain goal model templates specified using the Non-Functional Requirements (NFR) modeling notation [16]. Four types of goals are specified with NFR: softgoals (non-functional goals whose satisfaction cannot be fully achieved usually), functional goals (describing functional objectives of the system that can be achieved), softgoal operationalizations (identifying an applicable Cobra pattern and its instantiation), and constraint goals (describing system objectives to which the system should adhere). Contribution relationships (depicted as a line with the word “helps” or “hurts”) connect an element to a softgoal and indicate whether the element helps or hurts, respectively, the realization of the softgoal. Due to space constraints, this paper focuses on the constraint goals and their relationships to the UML model. Other elements of the goal model are described in more detail in [12]. In order to enable the formal analysis of constraint goals, these goals are specified as structured natural language properties that are amenable to formalization using Spider [14]. Thus far, the Cobra pattern repository consists of eleven patterns. Table 1 overviews the main functional goals of the patterns and shows how the Cobra patterns can be evaluated for their contribution to some non-functional requirements. Each Cobra pattern has a primary functional goal that describes the basic functionality captured by the pattern, which is further elaborated by a number of a softgoals that describe the impact of applying the pattern. In general, the developer can select an appropriate pattern to apply based on the primary functional goal. However, if two patterns, such as the Passive Sensor and Active Sensor , have similar functional goals, then the softgoals can be used to assist the developer in evaluating the alternatives. For example, the primary functional goal of both the Passive Sensor and Active Sensor Cobra patterns is to Monitor environment (as seen in Table 1). However, in the Active Sensor pattern, a sensor always sends the information to the computing component when the value changes (information push). As such, the computing component always has the most current value when performing a computation. Nevertheless, the system has to be able to handle the potentially increased number of messages sent by the sensors when a value changes often, which may affect the system cost. In the Passive Sensor pattern, the computing component only requests a sensor value when it is actually needed (information pull). However, the decision process for making the request and executing the request takes time and may impact the performance of the system. Figure 1 depicts an elided portion of the goal model template for the Passive Sensor pattern. As denoted in Table 1 and Figure 1, the softgoal (A) Performance is hurt, while the softgoals (B) Affordability and (C ) Reusability are helped by the (D) Passive sensor pattern. This pattern is AND-refined by (E ) Passive


455

sensor name, which provides context by naming the pattern instance. This goal is AND-refined by its functional goals, which include (F ) Sense environment and (G) Restrict to legal values. Each of the functional goals are, in turn, AND-refined

by constraint goals that describe specific, analyzable properties that the UML model should realize. AND-refinement requires all child goals to hold for the parent goal to be satisfied, while OR-refinement only requires one child goal to hold. Table 1. Cobra pattern evaluation table Classification

Primary Functional Goal

Active Sensor

Structural

Passive Sensor

Structural

Actuator

Structural

Control Controller Decompose Indicator Communication Link

Structural Structural Structural Behavioral

Computing Component Corrector Detector Fault-Handler

Behavioral Behavioral Behavioral Behavioral

Monitor environment; broadcast of environment information (push) Monitor environment; requires explicit request for environment information (pull) Influence environment by setting an actuator value Receive information from user Decompose system into components Provide information to user Interact with external device, e.g., for fault diagnostics Distribute computational tasks Correct faults Detect faults Centralized handling of faults

NFR Performance Modifiability Affordability Reusability

Pattern Name

+

- +

-

+ + +

+ +

- + + - + - +

- + - + - + - + -

Instantiating a goal model template has two steps. First, the developer should customize the template by replacing the generic text of the goal model elements with information about the specific embedded system under development.1 We use underlining in the goals to highlight generic text that needs to be customized. Second, the developer should relate the customized goal model template to the goal model for the overall embedded system by establishing a hurt or help relationship between the softgoal describing the pattern and a softgoal of the goal model (e.g., the hurt relationship between (D) Passive sensor pattern and softgoal (A) Performance in Figure 1). The Cobra patterns also provide UML model templates. Specifically, the Cobra patterns use UML class diagrams to capture structural information, and sequence and state diagrams to capture behavioral information. Due to space constraints, we do not present UML model templates for the Cobra patterns (please refer to [12] for more details), but we do include example instantiations of UML model templates in the case study description. 1

Customizing a natural language template refers to replacing the underlined text with free-form text to apply the goal to a specific system. The property can then be instantiated by replacing the underlined text with Boolean propositions in terms of UML model elements.

456


A

B Performance

Affordability Softgoal

help

hurt

C

Operationalized softgoal

Reusability

D

Passive sensor pattern

help Functional goal

AND

E

Constraint goal

Passive sensor name

helps / hurts Contribution relationship

AND

F

Sense Environment

G

AND / OR

Restrict to legal values

Refinement relationship

q

label

AND Send values to the computing component

AND

I

AND Globally, it is always the case that if a computing component queries the value of a passive sensor, then eventually the computing component receives the value.

H

Globally, it is never the case that a sensor value is less than its minimum.

Globally, it is never the case that a sensor value exceeds its maximum.

Globally, it is never the case that a sensor value is invalid.

Fig. 1. Passive Sensor pattern goal model template

3

Process

In this section, we present i2 MAP and describe the supporting i2 MAP tool suite. Specifically, i2 MAP guides a developer in the cooperative construction of a goal model and an analysis-level UML model of the embedded system in increments, where an increment is a unit of functionality. An increment is realized by declaratively specifying the functionality, including constraints, in the goal model and operationally specifying the functionality with structural and behavioral elements in the UML model. Realizing an increment may require several iterations, each of which is a single attempt to declaratively and operationally specify the increment. The realization is complete when the UML model adheres to the constraints, specified as part of the goal model. If discrepancies are detected, then these discrepancies need to be corrected during a subsequent iteration within the current increment. An increment may correspond to the application of a Cobra pattern, which provides goal and UML model templates to assist the developer in the specification of the increment functionality. In order to identify suitable patterns, a developer reviews the Cobra pattern repository to look for goals that capture the functional and non-functional requirements needed for the current increment. To begin the process, the developer seeds the goal model with a high-level objective of the system. Specifically, the primary goal of the system is identified and then decomposed into subgoals until each child goal describes the unit


457

of functionality realizable in one increment, such as what can be matched by the objective of a Cobra pattern. The relationship between the softgoals and operationalized softgoals added during the refinement process is denoted by contribution relationships that are labeled with the keywords “helps” or “hurts”. The developer has two options for realizing an increment: (1) using one or more Cobra patterns or (2) without Cobra patterns. In general, the process is simplified if an increment is realized using a Cobra pattern. But it is also possible to use i2 MAP without the Cobra patterns. In those cases, there is more burden placed on the developer to develop UML model refinements and goal model refinements without guidance from patterns and templates. For simplicity, we assume in the remainder of the paper that an increment corresponds to the application of one Cobra pattern. In addition to seeding the goal model, the developer uses the child goals to identify a preliminary list of increments and an initial realization order. Empirical studies [17] have shown that the order in which increments are completed (i.e., specific pattern applications) may affect the complexity of formal analysis, since there may be dependencies between increments. Resolving these dependencies in a suboptimal order could result in large and complex models earlier than necessary. Once a preliminary increment realization order has been determined, the developer begins to realize increments, where each increment has three phases: (1) planning (augmenting the goal model), (2) modeling (extending the UML model to adhere to the goal model), and (3) analysis (formally analyzing the goal and UML model to determine whether the increment has been completed successfully). Figure 2 gives a data flow diagram overviewing the i2 MAP tool suite supporting the process, where ovals represent processes, arrows denote data flow, two parallel lines depict data stores, and external entities are represented by rectangles.2 Numbers are used to indicate which components are used in which phase. We next explain each phase in detail and show how it is supported in our tool suite. 3.1

Planning

In the planning phase, the developer augments the goal model by including operationalized softgoals describing the non-functional requirements affected by the current increment; and functional and constraint goals are used to capture functional requirements. Since we assume a developer realizes an increment by applying a Cobra pattern, the goal model template provided by the pattern is used to guide the planning phase. Instantiating a goal model template has two steps. First, each goal in the template is customized by replacing the generic underlined text with information about the specific embedded system under development. The customized constraint goals specify properties to be satisfied by the UML model. In the i2 MAP tool suite, this specification is created in structured natural language (NL) [14] using the Increment Specifier (Process 1 in Figure 2). 2

We use a data flow diagram rather than a UML activity diagram to highlight the flow of data between the different phases of the process.

458


COBRA patterns

2. UML CASE tool ( , Rational XDE)

UML templates

Property templates

e.g.

i2MAP Model elements

1. Increment Specifier

NL properties

Model elements selection Increment realization order Analysis results and visualization

UML model 3b. UML Formalizer ( , Hydra)

3a. Property Instantiator

Increment Increment description and description property specification with NL properties

Developer

UML model

e.g.

Formal system model

Instantiated NL properties

3c. Model Analyzer

Formal property

Formal analysis tool (e.g., Spin, SMV)

Analysis results

Fig. 2. Abstract view of i2 MAP key steps

Second, the developer links the instantiated goal model template to the goal model for the overall embedded system by establishing a helps contribution relationship between the softgoal naming the pattern instance (e.g., (D) Passive sensor name) and a softgoal in the system goal model. Currently, this association needs to be done manually in the companion goal model and is not supported by our tool suite. Techniques exist for establishing the correctness of goal models [18, 19], however, it is outside the scope of our current work. 3.2

Modeling

Next, the UML model is augmented to include the functionality required by the goals. To create the UML model, the developer uses a UML CASE tool (Entity 2 in Figure 2). For instance, our i2 MAP tool suite currently uses Rational XDE [20]. The structure of the system is captured using UML class diagrams and behavior is captured in terms of UML state and sequence diagrams. To facilitate this process, the Cobra patterns provide templates to guide the creation and refinement of the UML diagrams. These diagram templates are designed to realize the properties specified by the constraint goals for a selected Cobra pattern. To denote a specific instance of the system that should be analyzed, an object diagram is created instantiating the class diagram. 3.3

Analysis

Once the modeling phase is complete, the analysis phase begins. In order to determine whether an increment has been completed successfully, we formalize the


459

constraint goals and analyze the UML model for adherence to these goals. An increment is considered successful if sufficient constraint goals are satisfied so that (1) for each goal with AND child goals, all child goals are satisfied and (2) for each goal with OR child goals, at least one child goal is satisfied. Two tasks need to be performed before the properties specified by the constraint goals can be analyzed. First, constraint goals of the goal model need to be instantiated with modelspecific elements. For this purpose, the developer replaces the underlined text in the placeholders of the structured natural language specifications with Boolean expressions describing specific system conditions (extracted from the class and state diagrams). In the i2 MAP tool suite, the natural language properties specified in the constraint goals are instantiated by the Property Instantiator (Process 3a in Figure 2), which leverages Spider [14] to perform the instantiation and formalization (i.e., translate the natural language properties to LTL). To facilitate this process, Spider provides user assistance to generate Boolean expression fragments based on information automatically extracted from a UML model. For details on these capabilities, please refer to previously published work [14, 21]. Second, the UML model is translated to a formal system model for the targeted formal analysis tool. In our tool suite, this translation is performed using the UML Formalizer (Process 3b in Figure 2). Here, Hydra [13] translates the UML diagrams into a formal model to be analyzed with the Spin model checker [22]. After the properties are instantiated and formalized and the formal system model is created, the UML system model is analyzed for adherence to the constraint goals. The analysis is initiated by the Model Analyzer (Process 3c in Figure 2), which iteratively performs the analysis of the formal model for adherence to all constraint goals. The Model Analyzer also processes the output received from the formal analysis tool and creates sequence diagram visualizations of the generated error traces. The visualizations can assist a developer in determining the source of each error. If a more interactive visualization is desired, then the developer may alternatively use Theseus [23], a tool that visualizes the model checker error trace in terms of animations on the original UML diagrams. If errors are uncovered during the analysis, then the source of the error needs to be determined and the error must be corrected in another iteration before the increment can be considered complete. As such, this analysis enables developers to find and correct errors quickly, whether the errors were newly introduced in the most recent increment or were introduced in earlier increments but revealed by the latest increment. However, since the size of the system model (in UML) and the number of properties that need to be analyzed is increasing with each iteration, the analysis phase also represents the greatest overhead of our process. Finally, if no errors are found in the analysis phase, the developer has specified all of the properties for the goal model, as well as constructed all the UML elements for an increment, then the process proceeds to the next increment, or ends when the goal model captures all requirements and, therefore, all increments have been completed.

460

4


Example Application

Next, we describe the application of i2 MAP to the modeling and analysis of an adaptive light control system (ALCS). The ALCS attempts to achieve a user-specified brightness in a single room. The user can select a desired brightness value between 0 and 1000 lux, and the system then attempts to maintain this brightness level. In order to achieve this goal, the system is equipped with a brightness sensor that measures the brightness in the room; and should the brightness be insufficient, the system can activate a dimmer to achieve the desired brightness level. The system is also equipped with a motion sensor. Using the motion sensor, the system can determine whether the controlled room is occupied. If the room is vacant, then the controller will turn off the light after a timeout period. In addition to the automatic mode, the controller also offers a manual mode. When a user activates the manual mode, the controller will set the dimmer to the maximum value for a period of time, and then switch back to automatic mode. To begin the process, the developer seeds the goal model with the primary goal Provide adaptive light control and child goals. Each child goal corresponds to an increment that can be realized using a Cobra pattern. Note that a given Cobra pattern may be used for realizing more than one child goal. Table 2 enumerates the ALCS increments. Specifically, it shows one possible realization order, the increment description, and the name of the Cobra pattern used to realize the increment. In the first few increments, the ability to sense and influence the environment via sensors and actuators is modeled. Next, the Indicator pattern provides the functionality needed to indicate the current state of the system to the user. Finally, automatic and manual control are realized using the Computing Component pattern. Table 2. Increment realization order for ALCS No 1 2 3 4 5 6

Increment Name Detect motion Measure brightness Control dimmer Display status information Automatic control Manual control

Applied Cobra Pattern Passive Sensor pattern Passive Sensor pattern Actuator pattern Indicator pattern Computing Component pattern Computing Component pattern

For illustration purposes, we describe next the realization of an intermediate increment, (2) Measure brightness, instead of the initial or final increment. Planning. At this point, the developer has successfully realized one increment: (1) Detect motion (to model the motion sensing functionality). For the second increment (2) Measure brightness, the developer needs to model the brightness

sensor to measure the brightness level of a room. For this increment, the developer has decided to apply the Passive Sensor Cobra pattern (refer to Table 2).


461

Modeling. The UML model of the ALCS is refined to include the functionality required by the current increment Measure brightness. As a result, the class diagram (depicted in Figure 3(a)) is augmented to include a BrightnessSensor, which will monitor the brightness level of a room. The BrightnessSensor’s behavior is elaborated by a state diagram (depicted in Figure 3(b)).

Computing Component 1 reads values from 1

1 reads values from 1

Motion Detector

Brightness Sensor

1 monitors 1

1 monitors 1

Environment

(a) ALCS class diagram

/^Computing Component. setBrightness Value(brValue)

Idle getBrightnessValue()[]/

Value Received

BrValue Requested

setBrightnessValue (brValue)[]/

[]/Ênvironment. getBrightness Value()

WaitingFor Environment

(b) Elided state diagram of the BrightnessSensor

Fig. 3. UML models for the ALCS

Analysis. Once the modeling for the increment Measure brightness is complete, analysis begins. The developer uses Hydra to formalize the UML model and Spider to instantiate and formalize the constraint goals specified by the goal model. However, formal analysis of the second increment Measure brightness reveals that two constraint goals for this increment (shown in Expression 1(a) and 2(a), which are instantiations of the constraint goals (I ) Globally, it is never the case that a sensor value exceeds its maximum. and (H ) Globally, it is never the case that a sensor value is less than its minimum. in Figure 1) are violated: 1(a) Globally, it is never the case that BrightnessSensor.brightnessValue > 1000.

and 2(a) Globally, it is never the case that BrightnessSensor.brightnessValue < 0.

After inspection of the UML model and the violation trace provided by the analysis tool, the cause for the violation was determined to be the following UML model error: “When the model of the brightness sensor was created, the developer forgot to have the brightness sensor v alidate the value returned by the Environment, enforcing upper and lower bounds.” Therefore, it was possible for the Environment to return a brightness value greater than 1000 lux or less than

462


0 lux. This error can be seen in the elided state diagram of the BrightnessSensor depicted in Figure 3(b), where the BrightnessSensor sends the ComputingComponent the value that was received in state ValueReceived, without performing any validity checks on the value. The corrected state diagram for the BrightnessSensor is depicted in Figure 4, where the shaded transitions, state, and variable name indicate corrections. Once these changes were made to the model, further analysis did not detect any violations. Due to the analysis of all constraint goals after each iteration, this error was uncovered early in the process. If this error had been detected in subsequent increments, then determining the source of the error would have been more complicated due to a more complex system model. If this error had not been detected in the subsequent increments, it could have potentially been propagated into subsequent development phases and, possibly, even the final product, since even testing techniques may have missed the subtle error.

/^Computing Component. setBrightnessValue (correctedBrValue)

Value Checked [brValue>=0 && brValue