Model-Based Development of Software Systems - Software and ...

But:Ind

But:Ind

Mot:Dir

But:Ind

Mot:Dir

Window Control Bat:Vlt

Bat:Vlt

Error Store

Err:Cod

Bat:Vlt

Res:Inf

Window Control Unit

Window Control Unit

But:Ind

But:Ind

But:Ind

Bat:Vlt

Bat:Vlt

Bat:Vlt

Mot:Dir

Mot:Dir Diagnosis Control Unit

Window Control

Res:Inf

Diagnosis Control Unit

Req:Cmd

Bat?Lo,But?Up: Err!LV,Mot!Zr But?Dn:Mot!Zr,Err!OK

But?Up:Mot!Zr,Err!OK

Req:Cmd

Dia:Cmd Dia:Cmd

Sts:Cod

Sts:Cod

Up

Sts:Cod

Stop

Error Store

Req:Cmd

Bat?Lo,But?Dn: Err!LV,Mot!Zr

Down

Err:Cod

Res:Inf

Diagnosis Management Dia:Cmd

Req:Cmd

Res:Inf

Diagnosis Management

Err:Cod

Dia:Cmd

Dia:Cmd Dia:Cmd

Req:Cmd

Res:Inf

Mot:Dir

Err:Cod

Res:Inf

Mot:Dir

Err:Cod

Bat?Hi,But?Up: Mot!Up,Err!OK

Req:Cmd

Sts:Cod

Sts:Cod

Association

Sts:Cod

But?Hd: Mot!Hi,Err!OK

Base Level

Bat?Hi,But?Dn: Mot!Lo,Err!OK

But?Hd:Mot!Zr,Err!OK

But?Hd: Mot!Lo,Err!OK

Class

Domain Level Composition Port Interface

name

String

name

ErrorStore

Component

Req.No Err.OK Req.Rs Err.OK winErr

Set-Reset

"Err"

"Window Contro...

errName

winCtrlName

winCtrl

Product Level

Res!No winErrInterface "Window Control Unit"

Res

Req?Rs:

Req

winCompUnit ctrlUnit ctrlUnitName

Res.OK

Res.No Req.Vt Err.OK

Res!OK

Res.Ft Req.No Err.OK

empty

Res.No

Req.No Err.LV

Err?LV:

Err

Res.No

full

Model-Based Development of Software Systems From Models to Tools

Bernhard Schätz

Abstract Not only since the introduction of the Unified Modeling Language and Model-Based Architecture, model-based development has been considered a central approach to deal with the increase in software complexity. Often, however, it is misunderstood as substituting code-based by graphic-based implementation, adding platform-independence through code-generation. Applied in a broader understanding, model-based development is the central engineering paradigm allowing to tackle the increasing complexity of today’s software systems. Its core principles are adequate models focusing on domain-specfic core concepts and providing a concise interpretation as well as supporting mechanisms. Using these kind of models allows to improve the quality of the developed product as well as the efficiency of the development process. To elaborate these principles and thus to establish a general framework for model-based approaches, concept models - providing the concepts for the syntactic description of a system - and content models - providing the contents for the semantic interpretation - are introduced, explicating their characteristics and benefits in general, and illustrating their instantiation for the domain of reactive systems. For these classes of models, their application in a tool-based development process is demonstrated by providing operationalizations for the construction of concept models as well as for the analysis and synthesis for both classes of models. The potential of models for a development process is demonstrated by illustrating their implementation through model-based techniques for the analysis - via structured requirements elaboration and modular function composition – and design – via constraint-conformant construction and architectural refactoring – as well as test – via integrated test-case generation – of reactive systems.

1

Acknowledgement A project like this can hardly succeed without the support of colleagues, friends and family. Therefore, its a pleasure to thank all the people who helped realizing this project. Science and research cannot proposer without the opportunity to encounter interesting problems and the liberty to explore new directions. Therefore I am especially thankful to Manfred Broy for his support in carrying out industrial as well as scientific projects and his openness to new ideas. New approaches need to be encouraged and challenged to turn them into useful contributions. Our research group provided both the necessary supportive and competitive atmosphere for this work. I want to thank all the members of our group for many stimulating discussions and joint work, foremost Alexander Pretschner, Peter Braun, Stefan Wagner, Eva Geisberger, Christian Pfaller, and Franz Huber. I am especially grateful to Stefan Wagner for proof-reading the final version and providing improvements for the understandability of this work. Furthermore, thanks go to our IT and administrative staff, first and foremost Silke Müller and Franz Huber, for keeping every-day business running smoothly. Software Engineering is all about turning ideas into running systems. Therefore, I like to thanks all colleagues helping with the implementations of the ideas in this thesis, especially Florian Hölzl, David Trachtenherz, Markus Hermannsdörfer, Benjamin Hummel and Elmar Jürgens, as well as all the students and colleagues from the AutoFocus team. Finally, no work will succeed without a supportive background. Thus, last but not least I want to express my gratefulness to friends and family, foremost to Herbert Pfaffinger for his comments on this work from an engineer’s point of view, and to my parents and Ursula Baumgartl for enduring my enthusiasm even in off-work hours.

3

Contents 1 Introduction

1

1.1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2 Concept Model 2.1

2.2

2.3

2.4

7

Introduction: Concept Model . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.1

Contributions: Structured Specifications . . . . . . . . . . . . . . .

8

2.1.2

Overview: Concept Model . . . . . . . . . . . . . . . . . . . . . . .

8

Characteristics: Structured Description . . . . . . . . . . . . . . . . . . . .

8

2.2.1

Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.2

Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

Benefits: Concept Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.3.1

Principles of Contribution: Model Description . . . . . . . . . . . .

16

2.3.2

Principles of Application: Model Description . . . . . . . . . . . . .

17

Conclusion: Concept Model . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.4.1

Summary: Concept Model . . . . . . . . . . . . . . . . . . . . . . .

19

2.4.2

Related Work: Meta Models . . . . . . . . . . . . . . . . . . . . . .

20

3 Model-Based Requirements Specification 3.1

3.2

21

Introduction: Requirements Specification . . . . . . . . . . . . . . . . . . .

21

3.1.1

Principles: Model Instantiation . . . . . . . . . . . . . . . . . . . .

21

3.1.2

Overview: Requirements Specification . . . . . . . . . . . . . . . . .

22

Context: Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . .

22

i

ii

3.3

3.4

3.5

3.2.1

Problem: Textual Requirements Specification . . . . . . . . . . . .

23

3.2.2

Contribution: Review-Based Formalization . . . . . . . . . . . . . .

24

Approach: Requirements Formalization . . . . . . . . . . . . . . . . . . . .

25

3.3.1

Instantiation: Formalized Requirements . . . . . . . . . . . . . . . .

26

3.3.2

Operationalization: Requirements Specification . . . . . . . . . . .

33

Application: Review-Based Requirements Formalization . . . . . . . . . . .

34

3.4.1

Implementation: Requirements Formalization . . . . . . . . . . . .

34

3.4.2

Method: Review-Based Formalization . . . . . . . . . . . . . . . . .

38

Conclusion: Requirements Specification . . . . . . . . . . . . . . . . . . . .

46

3.5.1

Summary: Requirements Specification . . . . . . . . . . . . . . . .

46

3.5.2

Related Work: Requirements Elaboration . . . . . . . . . . . . . . .

46

4 Model-Based Conformance Constraints 4.1

4.2

4.3

4.4

4.5

49

Introduction: Conformance Constraints . . . . . . . . . . . . . . . . . . . .

49

4.1.1

Principles: Structure Analysis . . . . . . . . . . . . . . . . . . . . .

50

4.1.2

Overview: Conformance Constraints . . . . . . . . . . . . . . . . .

50

Context: Model Conformance Constraints . . . . . . . . . . . . . . . . . .

50

4.2.1

Problem: Conformant Model Construction . . . . . . . . . . . . . .

51

4.2.2

Contribution: Conformance Constraints Construction . . . . . . . .

52

Approach: Conformance Conditions . . . . . . . . . . . . . . . . . . . . . .

53

4.3.1

Instantiation: Model Contraints . . . . . . . . . . . . . . . . . . . .

53

4.3.2

Operationalization: Constraint Analysis . . . . . . . . . . . . . . .

57

Application: Conformance Analysis . . . . . . . . . . . . . . . . . . . . . .

59

4.4.1

Implementation: Constraints Automation . . . . . . . . . . . . . . .

59

4.4.2

Method: Conformant Construction . . . . . . . . . . . . . . . . . .

60

Conclusion: Model Conformance Constraints . . . . . . . . . . . . . . . . .

66

4.5.1

Summary: Model Conformance Constraints . . . . . . . . . . . . .

67

4.5.2

Related Work: Constraints Conformance Analysis . . . . . . . . . .

67

iii 5 Model-Based Architectural Refactoring 5.1

5.2

5.3

5.4

5.5

Introduction: Architectural Refactoring . . . . . . . . . . . . . . . . . . . .

69

5.1.1

Principles: Structural Transformation . . . . . . . . . . . . . . . . .

69

5.1.2

Overview: Architectural Refactoring . . . . . . . . . . . . . . . . .

70

Context: Architecture Construction . . . . . . . . . . . . . . . . . . . . . .

70

5.2.1

Problem: Architecture Restructuring . . . . . . . . . . . . . . . . .

71

5.2.2

Contribution: Refactoring Architecture Transformation . . . . . . .

73

Approach: Model-Based Architectural Refactoring . . . . . . . . . . . . . .

73

5.3.1

Instantiation: Structure Formalization . . . . . . . . . . . . . . . .

74

5.3.2

Operationalization: Architecture Transformation . . . . . . . . . . .

80

Application: Refactoring Execution . . . . . . . . . . . . . . . . . . . . . .

86

5.4.1

Implementation: Transformation Automation . . . . . . . . . . . .

87

5.4.2

Method: Refactoring Application . . . . . . . . . . . . . . . . . . .

88

Conclusion: Architectural Refactoring . . . . . . . . . . . . . . . . . . . . .

90

5.5.1

Summary: Architectural Refactoring . . . . . . . . . . . . . . . . .

90

5.5.2

Related Work: Architecture Transformation . . . . . . . . . . . . .

91

6 Content Model 6.1

6.2

6.3

6.4

69

93

Introduction: Content Model . . . . . . . . . . . . . . . . . . . . . . . . . .

93

6.1.1

Contributions: Modular Functionality . . . . . . . . . . . . . . . . .

94

6.1.2

Overview: Content Model . . . . . . . . . . . . . . . . . . . . . . .

94

Characteristics: Modular Composition . . . . . . . . . . . . . . . . . . . .

94

6.2.1

Notions: Behavior Composition . . . . . . . . . . . . . . . . . . . .

95

6.2.2

Formalization: Modular Behavior . . . . . . . . . . . . . . . . . . .

96

Benefits: Content Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.3.1

Principles of Contribution: Model Interpretation . . . . . . . . . . . 102

6.3.2

Principles of Application: Model Interpretation . . . . . . . . . . . 103

Conclusion: Content Model . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.4.1

Summary: Content Model . . . . . . . . . . . . . . . . . . . . . . . 105

6.4.2

Related Work: Modular Behavioral Descriptions . . . . . . . . . . . 105

iv 7 Model-Based Function Composition 7.1

7.2

7.3

7.4

7.5

Introduction: Function Composition . . . . . . . . . . . . . . . . . . . . . . 107 7.1.1

Principles: Behavior Analysis . . . . . . . . . . . . . . . . . . . . . 107

7.1.2

Overview: Function Composition . . . . . . . . . . . . . . . . . . . 108

Context: Function Modularization . . . . . . . . . . . . . . . . . . . . . . . 108 7.2.1

Problem: Modular Behavior Specification . . . . . . . . . . . . . . . 109

7.2.2

Contributions: Modular Function Composition . . . . . . . . . . . . 109

Approach: Function Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.3.1

Instantiation: Modular Functions . . . . . . . . . . . . . . . . . . . 110

7.3.2

Operationalization: Modularization Analysis . . . . . . . . . . . . . 116

Application: Composition Analysis . . . . . . . . . . . . . . . . . . . . . . 120 7.4.1

Implementation: Analysis Automation . . . . . . . . . . . . . . . . 120

7.4.2

Method: Composition Automation . . . . . . . . . . . . . . . . . . 125

Conclusion: Function Composition . . . . . . . . . . . . . . . . . . . . . . 129 7.5.1

Summary: Function Composition . . . . . . . . . . . . . . . . . . . 129

7.5.2

Related Work: Behavioral Analysis . . . . . . . . . . . . . . . . . . 130

8 Model-Based Test Case Integration 8.1

8.2

8.3

8.4

8.5

107

131

Introduction: Test Case Integration . . . . . . . . . . . . . . . . . . . . . . 131 8.1.1

Principles: Behavior Synthesis . . . . . . . . . . . . . . . . . . . . . 132

8.1.2

Overview: Test Case Integration . . . . . . . . . . . . . . . . . . . . 132

Context: Component Integration . . . . . . . . . . . . . . . . . . . . . . . 132 8.2.1

Problem: Integration Test . . . . . . . . . . . . . . . . . . . . . . . 132

8.2.2

Contribution: Component Test Integration . . . . . . . . . . . . . . 133

Approach: Test Case Generation . . . . . . . . . . . . . . . . . . . . . . . 134 8.3.1

Instantiation: Component Test Cases . . . . . . . . . . . . . . . . . 135

8.3.2

Operationalization: Test Case Integration . . . . . . . . . . . . . . 140

Application: Integration Generation . . . . . . . . . . . . . . . . . . . . . . 145 8.4.1

Implementation: Generation Automation . . . . . . . . . . . . . . . 145

8.4.2

Method: Integration Automation . . . . . . . . . . . . . . . . . . . 148

Conclusion: Test Case Integration . . . . . . . . . . . . . . . . . . . . . . . 150 8.5.1

Summary: Test Case Integration . . . . . . . . . . . . . . . . . . . 150

8.5.2

Related Work: Test Case Generation . . . . . . . . . . . . . . . . . 152

v 9 Conclusion

153

9.1

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

9.2

Open Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Bibliography

156

vi

Chapter 1 Introduction An increasing amount of coined phrases like ‘Model-Driven Architecture’ or ‘Model-Based Design’ tries to establish Model-Based Development of Software Systems as a new approach in software engineering, by lifting system development from code level to model level. However, since software itself is a representation of algorithms and data structures, interpreted by computer hardware, building models obviously has always been at the heart of software engineering. Furthermore, in other engineering disciplines like electrical or mechanical engineering, the use models is commonly underlying all methods in these domain, and does not even require to classify them as ‘model-based’. Therefore it is definitely too narrow an interpretation when reducing model-based development in software engineering to using graphical notations to describe systems in a platform-independent manner and applying a mechanism to generate executable and platform-specific code from them. Thus, to understand what exactly is at the core of model-based development as a software engineering paradigm and how it can improve the construction of software systems, the central question is: What are relevant characteristics of models for software systems and how can they be used to improve the effectiveness and efficiency of the development process? In the following chapters, this question is addressed. To systematically approach this question, it is necessary to understand how models can specifically contribute to the effectiveness and efficiency of system development: To make the development process more effective, the use of models should allow building more complex systems with a higher quality. To make it more efficient, the use of models should help avoiding unnecessary steps or reducing stereotypical steps. In the following chapters, principle aspects of models are introduced, relevant to achieve these goals in the engineering of software systems; furthermore, besides their introduction, the following chapter also demonstrate how these principles can be translated in tools supporting the engineering process. The remaining sections of this chapter give a short explanation of how this question is approached in the following chapters. Section 1.1 explains what the topics are to be addressed in the following and why these topics are relevant for the above central question. 1

2

Chapter 1. Introduction

Section 1.2 explains how these topics are systematically addressed, structuring the remaining chapters. Finally, Section 1.3 introduces some terms useful in the context of the following chapters.

1.1

Motivation

As mentioned above, model-based development must provide models supporting the goals of reducing the complexity of the system under development while increasing its quality, and avoiding superfluous steps and reducing stereotypic steps in the development of the system. The remaining chapters address specific issues concerning what kind of models are applicable for software development, what are their core properties, and how can they be effectively used in a tool-supported development process, to achieve this goals. To understand how models can affect the development of software systems, first the main characteristics of models must be identified. As discussed in [Sta73], a model is defined by three characteristics: • A model is a depiction, representing the original. • A model is a reduction, capturing relevant aspects. • A model has a purpose, defining its use. Following these characteristics, three questions have to be addressed when considering the use of models in the system development process: • What kind of representations can a modeled object be mapped to? • What are the relevant aspects that should be retained by the representation? • What are possible applications of these retained aspects? Each of these three questions are addressed in the remaining chapters with respect to the development of software systems in general and a specific focus on reactive systems. The question concerning the kind of representation is answered by introducing two kinds of models, each kind capturing a different aspect of specifying a software system: One kind of models captures the description of such a software system; the other kind of models captures the interpretation of such a description. The question concerning the relevant aspects is answered by providing the main characteristics that models should have for either the description or the interpretation of systems. Furthermore, these principles are illustrated by providing specific models for the domain of reactive systems. The question concerning the possible applications is answered by providing the principle possibilites of application – instantiation, analysis, synthesis – for these models of either kind. Additionally, these principles are illustrated by demonstrating the realisation of these possibilities in a tool-supported application for the domain of reactive systems

1.2. Organisation

3

Providing these kind of models including their applications contributes to the effectiveness and efficiency of the development process in different ways: Reduce complexity: By providing abstractions of the system under development, these kinds of models allow to reduce the complexity by focusing on relevant aspects only, and factoring out aspects not needed for specific tasks. Increase quality: They furthermore help increase the quality of the development: by instantiation, allowing to avoid errors via the restrictions imposed by their construction; by analytic techniques, allowing to detect errors mechanically; and by synthetic techniques, allowing to avoid errors performed in manually executed steps. Avoid superfluous steps: This increased quality also reduces the required amount of rework of a system due to the late detection of defects at a later stage; by using models also in the early stages of the development process, the quality assurance techniques reduce defects in the early products. Reduce stereotypic steps: The use of models enables the automation of mechanizable steps, allowing to synthesize new models from already exisiting ones, thus eliminating cumbersome stereotypic steps.

1.2

Organisation

The remainder of this work is organized in two parts, each part dealing with a fundamentally different class of models: Concept Models, dealing with the concepts providing the vocabulary of models, i.e. the “syntax” or description of models, Content Models, dealing with the contents providing the meaning of models, i.e., the “semantics” or interpretation of models. Each part, in turn, is organized according to a common scheme, consisting of Model Definition, describing how these models can be defined in a generic fashion suitable for a range of applications, and Forms of Application, showing how these generic models can be put to use in a specific setting in a model-based development approach. For each part, there is a single Definition chapter, and several Application chapters, to demonstrate the usability of these definitions. Each of the two Definition chapters are also structured according to a common scheme, containing Characeristics, introducing the basic ideas behind the model and their formalization to precisely describe models,

4


Benefits, the principles of contribution, improving the development process (i.e., expressiveness, restrictiveness, conciseness, modularity), and the principles of application, putting models to work (i.e., instantiation, analysis, synthesis), accompanied by an Introduction, describing the characteristics of each class of models and sketching the remainder of the chapter, and Conclusion, summarizing the chapter and discussing related work. Finally, for each of the Application chapters, again a common scheme is used, describing Context, by characterizing the targeted problem in the domain of application as well as the contribution to solve the problem, Approach, by demonstrating the instantiation of the generic models in the context of the specific problem, and the operationalization of the instantiated model, Application, by illustrating the practical application of the approach in form of a toolsupported method tackling the targeted problem, and the achieved possibilities by the approach, accompanied by an Introduction, describing the principle applied and sketching the remainder of the chapter, and Conclusion, summarizing the chapter and discussing related work.

1.3

Vocabulary

Since the notion of a model forms the foundation of any model-based development process, first a clear definition of this notion is necessary. According to [SS08], a model is a simplified description, esp. a mathematical one, of a system or process to assist calculations and predictions When analyzing the principles of model-based development, the focus of the analysis is not on the construction of simplified descriptions of a system or process per se, but rather on the construction or characterization of complete classes of models, each model in turn describing a specific system or process. Since such a class can be – and often is – itself understood as a model, a clear distinction between these interpretations of the term model is needed. In the context of model-based approaches, often the definition of the OMG (Object Management Group) is used, which distinguishes between (at least) three classes of models Model: The purpose of the model layer, often referred to as M1, is to provide a language to describe a specific (application) domain. A UML class diagram is a typical example for a model. Metamodel: The purpose of the metamodel layer, called M2 in the OMG terminology, is to define a language for specifying application domain models. The UML is a typical example of a metamodel.

1.3. Vocabulary

5

Meta-meta model: The purpose of this layer is to provide the language for specifying metamodels. MOF [Obj00] is an example of an OMG-defined meta-metamodel. The original objects modeled reside outside the metamodel hierarchy. The collection of these things, in the OMG-terminology often called M0, contains the run-time instances of model elements. Note that each model (i.e., metamodel and model) is an instance of a corresponding metamodel (i.e., meta-metamodel, and metamodel, resp.) meaning that every element of the model is an instance of an element in the metamodel, the notion of ‘model’ and ‘metamodel’ into relative notions. Therefore, to avoid any confusion between different interpretations of the notion of metamodel, in the following three different notions are used: Product Model: A description of a specific product within the domain, e.g, the controller for a power window Domain Model: A description of a specific domain, e.g., the domain of signal-based communicating components Base Model: A description of a specific base underlying the domain, e.g., classes and associations. In the following, • principles for the definition of domain models and their interpretation, • supporting the construction of models for specific products as instances of those domain models, and • allowing the formalization of those domain models as instances of these base models are introduced, that allow to perform machine-supported operations on those models, using reactive systems as example domain of application.

6


Chapter 2 Concept Model When building models for a system under development within a specific domain of application, like the domain of reactive components, description techniques – graphical or textual – are used providing domain-specific element to represent aspects of these systems, like component or channel. The essential part of these models is not, however, the specific notation used but the available elements and relations provided by it to form a structured specification. To provide an approach for describing the characteristics of those models, in this chapter the notion of a Concept Model is introduced, allowing to capture the concepts of a domain of application. Besides capturing these concepts in a vocabulary, a concept model allows to define how these concepts are structurally related and how a model of a specific product under development from such a domain of application can be constructed as an instance from such a reference domain model.

2.1

Introduction: Concept Model

The description techniques used within a domain of application are characterized by the concepts of this domain, reflected in the elements and their relations found in the description techniques. In the domain of reactive systems, those concepts are, e.g., components and subcomponents, associated ports, channels between ports, messages communicated across channels, values contained in messages, events indicating the sending and receiving of messages, etc. These concepts form the vocabulary used to describe both problems and solutions within that domain. Thus, when constructing a domain model, first these concept must be captured, independently of their concrete representation in actually used description techniques. Such a conceptual domain model represents the ‘syntactic’ elements and their relations, and defines how they are used to build models of the product under development. Besides precisely defining the vocabulary, the conceptual domain model allows to express and also 7

8

Chapter 2. Concept Model

analyze the well-formedness of those product models, as well as express relations between different product models and apply them as transformations from one to the other. In this chapter, the characteristics of such domain models are introduced, and the resulting benefits of building them are discussed.

2.1.1

Contributions: Structured Specifications

The concept model is intended to provide an adequate representation of the system under development, using the concepts of the domain of application. For that purpose, concept models must support the development of complex systems through all phases of the process by easing the construction of structured specifications. Therefore, in this chapter • the formalization of concept models as labelled graphs is introduced, allowing to represent complex descriptions built from classes and associations • the conformance relation between a reference and an instance model is introduced, allowing to define the former as an abstraction of the latter, with a elementary base concept model as the least model in that order • an interpretation of conceptual constrains is provided, allowing to define them on the level of the reference model to restrict possible instance models

2.1.2

Overview: Concept Model

In the remainder of this chapter, the basic principles of a concept model are introduced and its application for the definition of a structured specification are illustrated, using the class of component-based systems as an example. Section 2.2 introduces basic characteristics that are necessary to formalize a model capable of capturing domain and product descriptions. By providing concepts to describe class and associations, conformance between instance and reference models, and conceptual constraints, the approach allows to formalize rich domain-specific description formalisms. Section 2.3 discusses the benefits that are achievable by using a structured representation of the specification of a system by providing an expressive vocabulary with a restrictive structure, thus supporting well-formed instantiation as well as mechanical analysis and synthesis techniques for these representations.

2.2

Characteristics: Structured Description

As mentioned above, the purpose of a concept model is capturing the abstract syntax of domain-specific, often graphical, description techniques, used to construct product models. Figure 2.1 shows an example of such a graphical representation of a product model: It shows

2.2. Characteristics: Structured Description Window Control Unit But:Ind Bat:Vlt

Mot:Dir

But:Ind

Window Control

But:Ind Bat:Vlt

9

Err:Cod

Bat:Vlt

Mot:Dir Err:Cod

Dia:Cmd

Dia:Cmd

Error Store

Req:Cmd

Diagnose Management Dia:Cmd

Err:Cod

Res:Inf

Res:Inf Res:Inf

Sts:Cod

Mot:Dir

Req:Cmd

Req:Cmd Sts:Cod

Sts:Inf

Figure 2.1: System Structure Diagram of the Power Window Unit the architectural structure of a Power Window Unit component, with subcomponents Power Window, Error Store, and Diagnose Management, as it is used in the AutoFocus [BHS99] approach. Components like Error Store use input ports like Err and output ports like Res to communicate with other components or the environment by linking ports via channels like Err. To describe the characteristics of such a model capturing domain and product descriptions, in the following the basic notions behind such a concept model are introduced and formalized.

2.2.1

Notions

To construct formalized descriptions of a system under development, a ‘syntactic vocabulary’ in form of a concept model is needed. This concept model1 characterizes all possible product models built from the modeling concepts in form of families of modeling elements and families of their relations used to construct a description of a product. Typically, class diagrams are used to describe the conceptual classes and conceptual associations. These concepts are reflected in the techniques used to model a product. In the following subsection, a formalization of the base concept model and its instantiations in form of the domain concept model and the product concept model is given. To define the notion of a concept model more formally, the interpretation along the lines of [SH99] is used. It provides an interpretation for syntactical descriptions of ‘meta models’ like the ones shown in the AutoFocus domain concept model of Figure 2.2. The figure applies the above-mentioned class-diagram notation to define the conceptual classes and 1

In the context of technologies like the Meta Object Facility, the class diagram-like definition of a concept model is generally called meta model.

10

Chapter 2. Concept Model Composition 0..1 Component -name : string -comment : string

Interface 1

0..* Containment 1

0..*

0..* OutputLink

Port -name : string -comment : string -direction : Direction

1

InputLink

1

0..1

Channel -name : string -comment : string

0..1

0..*

0..*

1 PortType

Type -name : string -comment : string

1

ChanType

Figure 2.2: Class Diagram Representing the Structural Aspects of an AutoFocus Product conceptual associations used to describe the architectural structure of a system in the AutoFocus approach. Basically, a concept model consists of Classes: characterizing the elements used in a conceptual description; Associations: characterizing relations between those elements. In the case of the AutoFocus domain concept model, it consists of classes of elements like a Component as the basic building block, a Port as an interface point, or a Channel as linking element between ports, defining the structural description of a product; associations linking elements like the Composition of subcomponents to components, the use of ports as an Interface of a component, or the Containment of internal channels of a component. Generally, domain concept models make also use of basic classes – like the string type to define the name of a component or enumeration types like the Direction of a port to distinguish between input and output. Besides providing a syntactic vocabulary, concept models can be related by the notion of conformance between concept models at different levels of abstraction. Intuitively, a more concrete concept model is conformant to a more abstract concept model if the former is an instance of the latter respecting the restrictions imposed by it, i.e., classes and associations of the former are consistently mapped to classes and relations of the latter, resp. While

2.2. Characteristics: Structured Description winCtrl : Component comment = Functionality ... name = Window Control

ctrlUnit : Component unitCtrl:Composition

unitErr:Containment

winErr : Port

err : Channel errWin:OutputLink

errStore : Component

comment = Control unit cont... comment = Component... unitStr:Composition name = Window Control Unit name = Error Store

ctrlErr:Interface

comment = Error code ret... name = Err direction = output

11

comment = Channel to tr... name = Err

strErr:Interface

storeErr : Port errStr:InputLink

comment = Error code t... name = Err direction = input

Figure 2.3: Section from the Concept Product Model of the Power Window Unit conformance can be established between an arbitrary number of models, ordering these models according to their level of abstraction, here – as shown in Figure 2.4 – only three levels are considered: The base concept model, as the most abstract concept model; a domain concept model, as an intermediate instance conforming to the base model; and finally, the product concept model, as a concrete instance conforming to the domain concept model. Similar to the typing mechanism provided by programming languages, by means of conformance between a more abstract concept model and its more concrete instantiating model, the structural well-formedness of the latter with respect to the former is enforced. Thus, instantiating the domain concept model by a conforming product domain model ensures that the product model only uses the classes and associations provided by the domain model in a consistent manner. In case of the AutoFocus domain concept model shown in Figure 2.2, e.g., a product concept model for the system depicted in Figure 2.1 must respect the imposed restrictions. As illustrated by the object diagram in Figure 2.3 showing a section of the corresponding product model, a Channel element err named Err connects to Port elements winErr and storeErr – both also named Err – only via an OutputLink relation like errWin and an InputLink relation like errStr, resp. Similarly, Channel element err is connected to a Component element ctrlUnit named Window Control Unit only via Containment relation unitErr, etc. Besides providing those structural consistency contraints, a concept model often has associated additional conceptual constraints, characterizing additional restriction for an instance of the concept model to be enforced by means of the conformance relation.Typical examples are the “arity”-constraints found in meta-models represented as class diagrams. In case of the AutoFocus concept model shown in Figure 2.2, e.g., each Port or Channel element must have a corresponding Component in the Composition and Interface association, resp.; furthermore, each Channel must have an associated source and destination Port via the OutputLink association as well as InputLink association, resp. Obviously, the instan-

12


tiating product model – as partially shown in Figure 2.3 – corresponding to the system depicted in Figure 2.1 also respects these constraints.

2.2.2

Formalization

As mentioned in Subsection 2.2.1, to formalize the notions of conceptual modeling, formalization are needed for • the classes and associations characterizing the concepts needed to construct a specification • the conformance relation relating instantiated and instantiating concept models • the conceptual constraints imposing additional restrictions on the instantiating models Based on these, a concept model is then described by its classes and associations, a concept model it is conformant with, and a collection of conceptual constraints restricting possible instantiations of this model. In the following a simple formalization of the notions of a concept model and instantiating models is given, providing the basics to build, analyse, and transform product models in Chapters 3, 4, and 5. Classes and Associations Basically, a concept model M is formalized by a labelled directed multigraph GM = (CM , AM ) with • CM , the set of vertices of GM representing the classes of M • AM , the set of edges of GM , representing the associations of M The labels provide both vertices and edges with a name.2 Here, for an edge a ∈ AM the notationà is used to denote the source vertex of a while a´denotes the target vertex of a.3 Obviously, the most simple nontrivial concept model is the model B with graph GB = ({class}, {association}) with singular sets of vertices and edges holding only the element class and association, resp., with àssociation = class = association´ 2

Since these labels are only used to provide names for vertices and edges in the following and are not interpreted otherwise, they are not included in the formalization for simplification purposes. 3 In the following, as usual, binary associations are used and therefore simple edges are sufficient; for arbitrary associations, general hypergraphs can be used.

2.2. Characteristics: Structured Description

13 Base Level

Association

Class

Domain Level Composition Port Interface

winErr

name

"Err"

String

name

"Window Contro...

errName

Component

winCtrlName

winErrInterface

winCtrl

Product Level

winCompUnit ctrlUnit

"Window Control Unit"

ctrlUnitName

Figure 2.4: Conformance Relations between Base, Domain, and Product Concept Model

and named Class and Association, resp. The concept model corresponding to this graph will therefore be called the base concept model. All other concept models form instances of this one. Figure 2.4 shows the labelled graphs representing the base concept model as well sections of the AutoFocus domain concept model for the structural aspects from Figure 2.2 and of the AutoFocus product concept model from Figure 2.3. In general, concept models capture more elaborate conceptual structures, leading to more complex graphs. E.g., in case of the AutoFocus concept model for the structural aspect, the classes and associations of the concept model – corresponding to the class diagram in Figure 2.2 – can be formalized as graph GSSD = (CSSD , ASSD ) with

CSSD = {component, port, channel , type, string, direction}

14


for the introduced classes named Component, Port, and Channel, and basic classes string and Direction4 , as well as ASSD = { composition, interface, containment, outputLink , inputLink , portType, chanType, componentName, portName, channelName, typeName, componentComment, portComment, channelComment, typeComment, portDirection} for the associations like Composition and Interface between the introduced classes and the attribute associations for the attributes like name, comment, or direction. The sources and targets are defined by the direction of the edges, e.g., ìnterface = port and interface´ = component or`componentName = component and componentName´= string. Product concept models – as shown in Figure 2.3 – can obviously be formalized in the same way.5 Conformance Since a concept model is basically formalized as a graph, conformance – as a relation between concept models – is formalized as relation between graphs. By stating that one concept model is conformant to another, an instantiation relation is expressed: the latter is a generalization or an abstraction of the former. Therefore, the conformance relation between an instance model represented by graph GI = (CI , AI ) and its generalization represented by GG = (CG , AG ) can be understood as an abstraction function F = (CF , AF ) with CF : CI → CG and AF : AI → AG mapping concrete instances – both classes and associations – of the first model to the corresponding abstract generalizations of the second model by the total functions AF and CF .6 Obviously, for a consistent abstraction, this abstraction function F representing the conformance relation must be a graph homomorphism, i.e., àG = CF (àI ) and aG´= CF (aI´) for aG = AF (aI ). 4

Classes string and Direction are only used but not introduced in Figure 2.2. Since navigation is not an issue on the concept level in contrast to the implementation level, bidirectional associations are only interpreted as syntactic means to provide additional aliases for association names. 6 In general, neither AF nor CF are surjective or injective. 5

2.2. Characteristics: Structured Description

15

Trivially, the identity function is a form of an abstraction function, therefore each concept model is immediately conformant to itself. However, since an essential asset of conceptual modeling is to ensure well-formedness of conceptual descriptions, concept models are required to be conformant to an explicitly defined reference model. Thus, besides the graph GM representing the model itself, the formalization of a concept model M also comprises a reference model consisting of • the graph GR = (CR , AR ) of the reference model • the conformance relation FR mapping the graph of the instance model GM to the graph of the reference model GR For the base concept model, as the most abstract concept model, the base model itself is defined to be its reference model, with the identity function as its conformance relation. For all other concept models, a corresponding reference model is defined, allowing – due to the transitivity of the conformance relation – to construct layers of conformant models. Figure 2.4 illustrates these layers – base, domain, and product layers – for the case of the AutoFocus domain of architectural descriptions, providing the explicit mapping between classes and associations. E.g., elements winCtrl and ctrlUnit representing components of the product concept model are both mapped to the Component element of the domain concept model, which in turn is mapped to the Class element of the base concept model. Similarly, the composition relation winCompUnit of the product concept model linking these components is mapped to the Composition relation of the domain concept model, which in turn is mapped to the Association element of the base model. Conceptual Constraints To support well-formedness conditions enforced on a conformant instance of a reference concept model exceeding the structural criteria imposed by the conformance relation alone, conceptual constraints are added to the reference model. Conceptual contraints are formalized as graph properties over the instance model, generally expressed in predicate calculus using the concepts of the reference model. Here, the reference model provides the necessary vocabulary to formulate those constraints over the instance model with respect to the conformance relation. Since the universe of the instance model, over which these predicates are interpreted, consists of instances of the classes and associations of the reference model, here, two forms of base predicates are provided: Class Membership: The predicate e ∈ C states that an element e representing a vertex of the instance model is mapped to a class C of the reference model by the conformance relation F , i.e., CF (e) = C. Association Membership: The predicate r ∈ A states that a relation r representing an edge of the instance model is mapped to an association A of the reference model by the conformance relation F , i.e., AF (r) = A.

16


Furthermore, a base function for the construction of relations from elements is provided: Element-Relation Construction: The term (e1 , e2 ) constructs a relation representing an edge between the vertices represented by the elements e1 and e2 , i.e., `(e1 , e2 ) = e1 and (e1 , e2 )´= e2 . Using these three language constructs, additional conceptual constraints can be formalized. Like the structural properties of the concept model, they are often described via class diagrams as depicted in Figure 2.2 in form of multiplicity- or ‘arity’-constraints by adding ranges like ’0 . . . ∗’ or ‘1’ to association ends. These association constraints require minimum or maximum constraints of occurrences of elements of classes in relations of associations of the universe of the product model. Thus, e.g., for the channels of the AutoFocus structural model, it is required that each Channel element has exactly one Port element connected via the OutputLink relation; i.e., ∀chan ∈ Channel . ∃1 port ∈ Port. (chan, port) ∈ OutputLink Equivalent constraints are also imposed on ports and channels. Conceptual constraints are formalized using the vocabulary of the reference model and restricting the possible concept models instantiating the reference model. Therefore, besides being a graph homomorphism from the instance to the reference model, a conformance relation is required to respect the conceptual constraints imposed by the reference model. In total, a concept model consists of • the graph representing the model, • the reference model it conforms to, • the conceptual constraints it imposes on its instantiations • the conformance relation establishing the instantiation with respect to the reference model and its constraints

2.3

Benefits: Concept Model

In summary, a concept model allows to formalize the (syntactic) description of a domain of application or product under development. Subsection 2.3.1 discusses the principal advantages supplied by the formalized description provided by a concept model. Subsection 2.3.2 sketches the principal forms of application resulting from the use of concept models.

2.3.1

Principles of Contribution: Model Description

2.3. Benefits: Concept Model

17

The concept model provides a well-defined structured representation of a specification, either on the domain or the product level. For an adequate description, the representation must directly make use of the concepts of the domain of application; for that purpose, concept models support using expressive descriptions, providing a rich vocabulary from the domain of application. Furthermore, using concept models for specification leads to restrictive descriptions, enforcing the (structural) restrictions imposed by conformance to a reference model, and thus avoiding specifcations which are ill-formed. Expressiveness of Description Models are – generally – built using only simple concepts like component, port, channel and simple constructions like introducing compositions by combining subcomponent to components, defining interfaces by adding ports to components, or constructing links by connecting channels to ports. By making it possible to build models from these simple domain-specific concepts and constructions taken from the domain of application the models is intended for – models capture the relevant aspects of a system under development. Furthermore, models can – generally – be broken down into views, reducing the overall complexity of a model by focusing on horizontal abstractions like hiding the subcomponents of a component; or focusing on vertical abstractions like reducing a system to its structural, behavioral, or data aspects. By introducing modularity into the description of complex systems and thus allowing to impose a manageable structure on it, models improve an effective description of a system under development. The concept model captures the complete vocabulary of a domain. Using the concepts and associations, it allows to effectively describe all relevant aspects of the system under development, ensuring the expressiveness of the constructed model. Restrictiveness of Description The concept model enforces the use of the vocabulary of a domain. Providing only the relevant concepts and associations, it restricts the description of the system under development to the essential aspects. While this restriction limits the range of systems that can be described, it also limits the possibilities to construct unintended descriptions of a system, thus reducing the possibilites of constructing faulty descriptions. In case of the concept model for the description of the structural aspects of an AutoFocus system, as described in Subsection 2.2.1, e.g., a channel can only be introduced by immediately linking it to is source and destination port. Thus, by construction, the concept model ensures that no product model may contain “dangling” channels, which are linked to only one port, or even no port at all.

2.3.2

Principles of Application: Model Description

18


As stated in Subsection above, the concept model provides a well-defined structured representation of a specification, either on the domain or the product level. This representation can be applied in different ways to support the development process: By instantiation a concept model enforces the construction of well-formed product descriptions for a given domain of application. Additionally, providing a structured representation of the product under development, it can be used to mechanize analysis techniques for checking the validity of structural constraints. Finally, by supporting the specification of structural transformations, it enables the automated synthesis of additional, derived models. Instantiation As mentioned before, the domain concept model is defined as the collection of all wellformedness conditions which must hold for an instantiating product model throughout the development process; those conditions are restricted to conceptual constraints. Thus the concept model can be interpreted as the collection of all elements of the views (abstracting from their graphical representation) and all relations that hold invariantly. All other consistency conditions (concerning both concept and content) may be violated throughout the development process. Thus, the concept model characterizes the constraints of possible corresponding product models; or – in other words – a product concept model must always be an instantiation of the corresponding domain concept model. As a result, the definition of a concept model and the corresponding system development process are closely related. For instance, in a rigorous process a port might be only introduced with a defined type assigned to it. In a more flexible process, it might be possible to create a port leaving the type unfixed at the time of introduction. Therefore, for a rigorous process all conceptual constraints are integrated into the concept model; while this limits the construction possibilities of the designer by abolishing inconsistent views, it avoids the need for checking variable consistency conditions at certain steps. On the other hand, reducing the set of invariant consistency conditions leads to a more flexible process at the price of possibly inconsistent views. Chapter 3 shows how to apply this principle to the review-based construction of requirements specifications from textual requirements. There, the invariant constraints imposed by the concept model for the domain of requirements specifications characterize the operations applied in a step-wise process for the refinement and formalization of requirements. Analysis As mentioned above, conceptual conditions restricting the possible instances of a reference concept model are only one form of application of the vocabulary provided by the reference model. Besides imposing those invariant constraints, additional conditions can be formalized in the same fashion, which are only required to hold at certain points of the development process and therefore must be checked if needed. By providing a mechanism

2.4. Conclusion: Concept Model

19

to interpret these conditions over an instance of the reference model, this extended form of conformance can be automatically analyzed. Chapter 4 shows how to apply this principle to the conformance of architectural specifications to modeling constraints. There, the variant constraints imposed by the concept model for the domain of component architectures characterize the conditions enforced upon the model by conformance checks. Synthesis The vocabulary provided by the domain concept model is not restricted to specify constraints over the structure of a specific instantiating product model; the same vocabulary can also be used to describe relations between two different product models, constraining the structure of the one depending on the structure of the other. By interpreting one of these models as the input model and the other as the output model, such a relational contraint can be understood as the characterization of a transformation between models, synthesizing the latter from the former. If those transformation constraints are specified in a suitable form, a mechanism for the automatic execution of those transformations can be provided. Chapter 5 shows how to apply this principle to the refactoring of architectural specifications. There, the concepts and associations supplied by the concept model provide the vocabulary to formalize transformation steps for the refactoring of component architectures.

2.4

Conclusion: Concept Model

In this chapter, the notion of a concept model as a formalization of the structural aspects of a specification has been introduced. By providing the capability to capture the concepts of an application domain, concept models allow to apply these concepts to construct a model of the product under development.

2.4.1

Summary: Concept Model

In the approach resented here, concepts models are formalized, capturing the ‘syntactical’ representation of the domain of application as well its instances in form of products. The formalization is based on the concept of classes and associations, allowing to model complex descriptions as labelled graphs of domain elements and the relations between them. Between models of different level of abstraction – e.g., a reference domain concept model and its instantiating product concept model – a conformance relation is defined, mapping concrete elements and relations to their corresponding class and association types via an abstraction function in form of a graph homomorphism; an elementary base concept

20


model as the least element of this order consisting of a single class and a single association. Finally, the mapping between an instance model and its reference model is interpreted as type mechanism on the instance model, allowing to restrict the conformance relations by conceptual constraints defined on the level of the reference model to restrict possible instance models.

2.4.2

Related Work: Meta Models

Concept models capture the ‘abstract syntax’ of (textual or graphical) specifications of domains models was well as product models. Like meta-models, they address the issues of how to describe those models and the relations between models on different levels of abstraction. Similar to the Meta-Object Facility (MOF) [Obj00] and instantiating frameworks like the Eclipse Modeling Framework (EMF) [SBPM07] the approach here allows to generate implementations for instance models of a reference model, proving mechanisms for construction and persistance [BLSS00]. However, in the contrast to those approaches, here the model is focussed on simplicity and understandability, to characterize the principles of concept models rather than providing efficient implementations. Thus, e.g., associations between classes are introduced as base concepts instead of using attributes of classes. To address the issue of efficient implementations, additional intermediate concept models providing refined classes and associations between the base model and a domain model can be introduced. In contrast to approaches like [AP08], formalizing rich sets of implementation concepts provided by metamodeling techniques like MOF, here the focus is to supply a elementary yet expressive formalization of ‘syntactic’ models, providing core concepts like conformance. Therefore, the formalization here is reduced to the necessary concepts allowing to capture the of a domain model and its instantiating product models, to make the underlying principle more visible. Furthermore, unlike many approaches focusing on formalization of meta-models, from early ones like [EFLR99] to more recent ones like [MÁ05], the approach presented here focusses on providing a most direct and simple formalization of the core concept independent of its implementation and embed it into predicate logic rather than focusing on the direct expression of concept models in the logic itself; the question of analysing or transforming concept models is treated in Chapters 4 and 5. The approach presented here has close relations to [JB06] as also graphs are used to formalize models, and graph relations to formalize a conformance relations. Since, however, here the focus is put on the core concepts rather than the implementation issues like reflection or navigability, a simpler base model can be used to capture all concepts. Furthermore, here an interpretation for arbitrary conceptual constraints are included to allow the inclusion of non-invariant structural constraints.

Chapter 3 Model-Based Requirements Specification While software design is increasingly based on – well-structured or even formalized – models, requirements engineering is still generally performed using structured text. As a consequence, a systematic transition between these two phases is generally not supported. Providing a structured model for requirements and integrating it into the domain concept model used for the design of a system allows to supply tool-support for a review-based refinement and structuring of requirements, leading from textual descriptions to a formalized design-like model.

3.1

Introduction: Requirements Specification

Model-based approaches to software and systems engineering are generally associated with the design or implementation phase. Nevertheless, its principles can also be effectively applied to the analysis phase by introducing a concept model for requirements, thus supporting the step-wise formalization of requirements in the development process. Due to the increase in structure and precision of the specification, analysis and generation techniques are available already during requirements engineering, improving the quality and efficiency of the development process. In this chapter, a model-based approach for the development of requirements specifications is introduced.

3.1.1

Principles: Model Instantiation

Requirement engineering aims at obtaining the initial description of a system under development. As this initial description is jointly constructed by stakeholders with different backgrounds – including domain experts and users – generally textual descriptions as the 21

22

Chapter 3. Model-Based Requirements Specification

commonly agreed-upon specification formalism is used. Obviously, this generality is an important strength of textual specifications; besides being understandable by all stakeholders, they also support the construction of incomplete specifications, allowing for design decisions. However, this also has a down-side; their possible lack of precision forms an essential weakness, leading to defects like inconsistencies, or ambiguities. By applying a model-based approach, these down-sides can be avoided, simply by understanding the formalization of requirements as as the construction of a structured model, representing an instantiation of a concept model for the domain of requirements engineering. The use of adequate domain-specific models can drastically improve the quality of text-oriented requirements specifications, even though analytic and synthetic techniques are only applicable in a very limited fashion. Due to its structured and restrictive character, a formalized model of a requirement specification enforces increased preciseness, countering inconsistencies and ambiguities. By providing tool-support for the construction of these text-oriented, formalized requirements models, they can be efficiently used in practical applications.

3.1.2

Overview: Requirements Specification

In the remainder of this chapter, the potential of using a model-based approach to requirements engineering is demonstrated. Section 3.2 discusses domain-specific aspects of requirements engineering countered by a model-based approach: informal (textual) requirements as a major cause for requirements defects, and review-based step-wise formalization as a possibility to avoid these defects. Section 3.3 introduces the domain concept model supporting model-based requirements specification. The core issue of this model is the explicit structuring and classification of requirements, as well as their integration into the concept model for the design domain. In Section 3.4, the application of this integrated model is illustrated; to that end, those functionalities supporting a review-based, step-wise formalization of textual requirements are introduced as implemented in the AutoRAID extension [Aut04b] of the AutoFOCUS CASE-tool framework. Finally, in Section 3.5, a short summary of the application of a domain concept model to requirements engineering is given, and the presented approach is compared to related work.

3.2

Context: Requirements Analysis

Engineering of complex systems requiring the integration of different engineering disciplines and stakeholder, as well as the precise definition of the functionalities of the systems, demands to

3.2. Context: Requirements Analysis

23

Figure 3.1: Using Textual Requirements in AutoRAID • elaborate and analyze the constraints imposed on the system from the different participating disciplines, • systematically elaborate the functional requirements and properties, and • include the resulting requirements regarding design and realization of the system in an early phase into the specification of the system. Thus, development and analysis of requirements is a crucial step in the development process, targeting the precise specification of the system under development as a starting point for further development, based on – generally informal and interdisciplinary – requirements. Central steps are the capture and elaboration of the requirements – especially including their structuring and formalization starting from informal text – as well as their management – especially including the tracing and consistency analysis between themselves as well as more constructive models.

3.2.1

Problem: Textual Requirements Specification

24


Formalized descriptions of the system under development have repeatedly proved useful in the construction software systems (e.g., [Jon00]). However, in industrial application, the development process rarely starts with a formalized description of the system under development; instead, informal textual descriptions are used as the initial specification. As shown in Figure 3.1, these initial specifications often only use a section/sub-section hierarchy as their sole means of structuring. State-of-practice tools like DOORS, Caliber, or RequistePro are used to capture and further structure those textual requirements. As these tools in general only support the generic concepts requirement and sub-requirement, as a result of this step a tree-like structure of distinct textual requirements is obtained. Based on these textual descriptions, in a second step more formalized descriptions of the system under development are defined. To that end, tools like Rhapsody, Rational Rose, or TAU are used, supporting concepts like component, sub-component, channel, state, event, or data type. By manually working through the textual description in a review-like process, a specification of the system under development is constructed from these concepts, by adding corresponding model elements to the specification as suggested by the textual requirements. Due to their generally informal nature, ensuring the quality of requirements demands somewhat different techniques then applied when assuring the quality of design specifications. Here, standards like IEEE 1233-1998 [IEE98a] define criteria for requirements specifications to ensure quality in the early phases of development. By the approach presented here, five quality defects by means of constructive and analytic quality assurance are addressed: Inconsistency: The requirements of a specification contain or lead to contradictions. Ambiguity: The requirements of a specification can be interpreted in different possible ways. Intraceability: A requirement cannot be clearly linked to other parts of a specification – including goals, conditions, constraints, and design decisions – that are influencing or influenced by this requirements. Infeasibility, Verifiability: A requirement cannot be met by any implementation, or the realization of this requirement by the implementation cannot be established. As discussed in Subsection 1.3, generally manually performed, review- or form-based approaches are used; here a model-based and tool-supported approach is presented, which counteracts these defects.

3.2.2

Contribution: Review-Based Formalization

In the approach presented here, requirements engineering is integrated seamlessly in a well structured software development process. Based on the model, tool-supported structuring and classification mechanisms are offered to the developer, which are generally performed during an inspection or review process [DP04]. Besides supporting those structuring steps (e.g., identifying the different steps of a use case; identifying requirements concerning

3.3. Approach: Requirements Formalization

25

the interface of a system), analytical techniques commonly applied in an inspection can be mechanized (e.g., each identified functionality must be broken down into sub-functionalities or allocated to a system component). In the following, those integration techniques are presented that are implemented in the current version of the AutoRAID (AutoFocus Requirements Analysis Integrating Development) tool prototype [Aut04b]: Structured requirements model: Introducing domain-specific classes of requirements (e.g. architectural requirements, modal requirements, use case scenarios). Integration of textual requirements: Integrating textual requirements into the model and offering pragmatic mechanisms for including textual documents into the development process. Tool-based support for classifying and structuring: Mechanizing the step-wise structuring (e.g. identification of components in architectural requirements, of actuators in functional requirements) or generation (e.g. control states out of modal requirements). Tool-based transition to design-oriented model elements: Linking and generating classes of requirements to classes of design (e.g. modal requirements to control states, architectural requirements to components). This tool-supported review-based formalization process addresses the above-mentioned defects of requirements specifications: Inconsistency: By successively breaking down requirements into a detailed model with linked elements, inconsistencies are successively removed (e.g., when detailing scenarios of a system based on its interface). Ambiguity: By using a detailed model for the requirements, expressing the requirements in terms of this model successively leads to elimination of ambiguities (e.g., when classifying and detailing the steps of a scenario). Intraceability: By linking the detailed requirements on the fly to elements of the design, traceability is automatically ensured (e.g., when motivating a mode of the system out of a mode constraint). Infeasibility, Verifiability: By using a model with restricted expressibility for detailed requirements, a design-like precision of description is enforced, reducing the risk of infeasibility and verifiability (e.g., when specifying the interactions performed during a scenario). The model of design here is taken from the tool prototype AutoFocus [Sch04], targeting the development of reactive systems.

3.3

Approach: Requirements Formalization

26

Chapter 3. Model-Based Requirements Specification Requirement Specification Id: Integer Title: String Description: String refines Patron: String 1 0..* 0..* refined by

0..*

associated to

Figure 3.2: Core Requirements Model To construct formalized specifications of a system during development, a ‘syntactic vocabulary’ or concept model as introduced in Chapter 2 is needed. A rich domain concept model with sophisticated model elements and associations allows a well-structured specification with high degree of precision. However, in requirements engineering, this rigidness is generally not immediately applicable: as textual specifications – due to their generality and flexibility – are the predominant description formalism, the corresponding domain concept model must reflect this. On the other hand, the domain model must support a rigid formalization of requirements to avoid quality defects and support a smooth transition to later phases. Therefore, in this section a domain concept model for requirement specifications is introduced, supporting different degrees of rigidness, as necessary during the step-wise formalization of textual descriptions: structured requirements – as described in Subsection 3.3.1 – cover text-oriented descriptions; classified requirements – as described in Subsection 3.3.1 – adds the classification along the lines of [IEE98a] as a coarse form of formalization; finally, integrated requirements – as described in Subsection 3.3.1 – enabled a detailed formalization and direct integration with a design-oriented model. Thus, as explained in more detail in Section 3.4, the domain concept model supports the structuring, classification, formalization, and analysis steps in a review-based manner. To focus on the methodical issues, the domain concept model presented here is simplified; the actual implementation, as described, e.g., in [Tec05], is much more sophisticated.

3.3.1

Instantiation: Formalized Requirements

In order to obtain the required degree of rigidness of requirements, they must be formalized. To that end, a concept model of requirements is introduced, capturing different aspects of formalization. Structured Requirements


27

Even in the weakest form of formalization, a clear concept of textual requirements and the relations between them are necessary to add a simple structure to text-based requirement specifications. Therefore, as shown in Figure 3.2, a basic model of structured requirements is provided, by using attributed, refined, and associated requirements. Attributed Requirements When dealing with practical specifications consisting of large sets of individual requirements, a central aspect of requirements engineering deals with the issue of managing specifications. This includes elementary tasks like creating, identifying, retrieving, and changing the description of requirements. As shown in Figure 3.2, to that end, the domain model contains the concept of Requirement Specification. Besides its textual Description, each Requirement Specification offers additional attributes, including a unique ID, a short Title, and a responsible Patron. Other typical attributes not shown there, but used in AutoRAID are priority (high, medium, low), status (proposed, accepted, rejected), or rational. Though not shown in Figure 3.2, the concept model furthermore supports the distinction between business and application requirements to separate overall goals from concrete functionalities and constraints. Refined Requirements A major aspect in requirements engineering concerns the breaking down of requirements into sub-requirements. This step is also the main functionality of many state-of-the-art requirements tools like Caliber, DOORS, or Requiste Pro [HKS+ 05]. This functionality reflects the fact that complex requirements consist of more primitive sub-requirements. Generally, a textual specification contains an informal structure, e.g., in form of sections and subsections. Typically, these sections describe the interfaces of a system including – as shown in Figure 3.1 – the inputs received via its interface, its internal structure, the data managed, and the functions provided. Besides this refinement of sections in sub-sections, more implicit refinement relations are contained in textual descriptions; as furthermore shown in Figure 3.1, the Actual Number of Revolutions received via a CAN [Int03] interface is a sub-requirement of the section dealing with the Inputs received via the CAN interface. To explicitly capture this informal structure, an explicit notions of sub-requirements is needed in the concept model. As shown in Figure 3.2, to that end, the domain model contains the concept of a Requirement Specification that refines or is refined by another Requirement Specification. Explicitly maintaining this refinement relations between super-requirements and their subrequirements supports forward-Tracing [KS98] in order to track these associations. Associated Requirements The refinement relation is used to describe that a compound Requirement Specification consists of several individual sub-Requirement Specifications, leading to a hierarchic refined-by-relation between requirements.

28

Chapter 3. Model-Based Requirements Specification refined by

0..* 0..* 1 Requirement 0..* refines Specification

Architectural Specification

Modal Specification

Data Specification

associated with

Functional Specification 1 describes 0..* described by Scenario Specification 1 0..* Observation Specification

Figure 3.3: Classified Requirements Model During the analysis of a specification, however, it is often useful to express that several – hierarchically unrelated – requirements are addressing a common issue, e.g., different functional specifications with separate courses of actions, causing the same error message. As shown in Figure 3.2, to that end, the concept model offers the concept of associated requirements, allowing to explicitly state that a Requirement Specification is associated with another Requirement Specification. Classified Requirements To obtain a useful specification, certain classes of requirements should be present in a well-defined requirement specification. E.g., [IEE98a] explicitly suggests to include requirements addressing the data flow of a system including its interface, the possible modes of a system, the data processed by a system, and the functions provided by the system. Therefore, explicit categories for architectural requirements, modal requirements, data requirements, and functional requirements are introduced. As shown in Figure 3.3, this is achieved by introducing the concepts of Architectural Specification, Modal Specification, Data Specification, and Functional Specification into concept model as specific subclasses of the general concept Requirement Specification, Note that – in contrast to an Architectural Specification, a Modal Specification, or a Data Specification – a Functional Specification has a more detailed structure. To formalize the specification of function provided by the system, use cases described by tabular- or textbased Scenario Specifications can be used. Each scenario in turn is described by an (ordered) set of individual Observation Specifications. While these categories of requirements basically use the same form of structured textual representation – by means of ID, Title, Description, etc. – their (informal) description should


29

Architectural Specification 0..* motivated by motivates 0..1 Component

Name: String Description: String

motivated 0..* by

motivates 0..1 Port

0..* motivated by

0..1 motivates Channel



Figure 3.4: Architectural Requirements Model address different aspects of the system, which therefore require different formalizations. Thus, as shown in Figures 3.4, 3.5, and 3.6, the classification restricts the formalized specifications that can be deduced from (or motivated by) them. Architectural Requirements Architectural requirements address the topological aspects of the data flow within a system, describing the structure of a system. Therefore, components, their interfaces and communication paths between them are captured with these requirements. As shown in Figure 3.4, the corresponding concepts needed to formalize those specifications are Components, Ports, and Channels. As part of their formalization, each of these concepts is furthermore detailed by supplying a Name and a Description. On the one hand, each Component, Port, or Channel can by motivated by several corresponding Architectural Specifications. On the other hand, each Architectural Specification can at most motivate a single Component, Port, or Channel. Therefore, these specifications must be refined to the level of an atomic requirement, to motivate the corresponding architectural elements of a specification. Modal Requirements Modal requirements reflect that fact that the behavior of systems is often influenced by different modes of operation, e.g., initialization, normal operation, or error recovery. These modes are captured by this class of requirements. As shown in the left-hand side of Figure 3.5, to support the formalization of modes, the concept Control State, together with the attributes Name and Description is used. Again, modal requirements can be used to motivate a specific single ControlState, enforcing the identification of atomic requirements prior to motivation. Data Requirements By means of Data Specifications, requirements concerning the data stored or communicated by a system are addressed. On the one hand, these data requirements are used to specify that a specific data type – e.g., a message format – must be used

30

Chapter 3. Model-Based Requirements Specification Mode Specification

Data Specification

motivated 0..* by

motivated 0..* by

0..* motivated by

motivates 0..1 ControlState

motivates 0..1 Data Element

0..1 motivates Data Type




Figure 3.5: Modal and Data Requirements Model Functional Specification 1 describes

Sequence 0..* described by Scenario 0..* motivates Name: String Specification motivated 0..1 Description: String by 1 1

Mode Observation

0..* Observation Specification

State Observation

0..* 0..* motivates Observation motivated 0..1 Label: Integer by Description: String

Event Observation

Figure 3.6: Functional Requirements Model for communication and storage. On the other hand, data requirements can be used to specify that certain data elements – e.g., a calibration parameter – must be implemented in a system. The right-hand side of Figure 3.4 shows the corresponding concepts needed to formalize those specifications: Data Element and Data Type, again together with a Name and a Description. As before, a Data Specification may only motivate a single Data Element or Data Type, requiring atomic data requirements for motivation. Functional Requirements Functional requirements are used to specify the functions to be provided by a system. Most commonly, these functions are described in terms of use cases described by representative application scenarios of the system; each scenario in turn is described by a sequence of individual observations about the system and its interactions with its environment. As illustrated in Figure 3.6, the detailed structure of a Functional Specification – described by a set of Scenario Specifications in turn detailed by an (ordered) set of Observation

3.3. Approach: Requirements Formalization refined by

31

associated to

0..1

0..* 0..*

0..* 1..* Specification refines

SubComponents

0..* Modal Specification 0 ..*

Functional Architectural Specification Specification 1 0..* 0..* Scenario Specification 1 0..* Observation 0..* Specification

1

0..1 DataElement 0..*

0..*

Data Specification 0..*

0..1

1

1

1 0..*

0..*

1 Component 1 1 1

0..*

Port

2

0..2

Channel 1

1..*

0..* 0..*

Sequence 1

ControlState

0..* 0..1

1

0..*

1

DataType

1

Observation

0..*

2

0..*

Pattern

0..*

Transition

0..* Expression 0..* 0..* 1

0..*

Event Observation 0..* 0..*

State Observation

0..*

2

Condition

1

0..*

Figure 3.7: Simplified Integrated Requirements Model Specifications – requires a slightly more sophisticated concept model for the formalization of functions: a Sequence – additionally detailed by a Name and a textual Description – can be motivated by a single Scenario Specification; correspondingly, an Observation – additionally detailed by a Label and a textual Description – can be motivated by a single Observation Specification. Finally, depending of the class of observation made – the mode of operation

a system is currently in, the actual value held by a data element, the stimulus/response exchanged during an interaction – an Observation Specification itself can be classified as either Mode Observation, State Observation, or Event Observation. Integrated Requirements

As stated in Subsections 3.2.1 and 3.4.2, two of the main purposes of the introduced model is supporting quality-assurance for requirements and narrowing the gap between analysis and design. However, so far, the model used for formalized requirements only offers rather isolated concepts; this, however, is not suitable to meet these objectives. Therefore in the following, the model is enhanced by integrating the concepts of analysis and design, thus avoiding a breach in the development process. integrating the categories of requirements, thus increasing precision and consistency of the requirements specification.

32


Integrating Analysis and Design In Subsection 3.3.1, concepts like Component, ControlState, Data Type, or Sequence of Observations had been introduced to support a deeper classification and formalization of the individual requirements. Consequently, these concepts are part of the concept model of the requirements domain. However, a major objective of this concept model is the easy transition from an textual requirement specification to design-oriented description of the system, requiring a tight integration of the concept models for both domains. As the specification of the functionality of a system under development is both the endpoint of the analysis phase and the start-point of the design phase, it represent the interface between these phases. This overlap of the domains is reflected in the overlap of the concepts introduced for requirements analysis in Subsection 3.3.1 and for design construction in Chapter 4. Each model introduced there uses the concepts Component, Port, ControlState, Data Type, Data Element, Sequence, Observation, etc. By identifying these concepts, a tight integration of both models is achieved, thus supporting a seamless transition between analysis and design, by viewing the above concepts as elements of either phase, thus immediately supporting forward-tracing. Figure 3.7 shows the merging of these models. The greyed conceptual elements show the common parts of analysis and design model. Using the motivated by relations, the traceability between analysis and design is supported. Integrating Categories of Requirements As explained in Subsection 3.3.1, by means of classified requirements, textual requirements – described using a uniform scheme introduced in Subsection 3.3.1 – are separated into different categories. Based on these selected categories, different formalized concepts for these requirements can by motivated from them. So far, for each category only the main formalized concepts (e.g., Component, ControlState, Data Type, Observation) immediately motivated by the corresponding specification have been introduced, with no interrelation between them. However, as described in more detail in Chapter 4, an essential purpose of a concept model – as used in AutoFOCUS and AutoRAID – is the integration of different views of a system; in the design domain, typically, these views focus on specific but overlapping aspects like its architecture, its data, its operation, or its functionalities. In a similar fashion, in the requirements domain corresponding views on the system under development are introduced via the classification in architectural, data, mode, and functional requirements. As discussed in Chapter 4, in the design domain, the integration of these views on the concept model is enforced by obligatory relations between its elements. Figure 3.7 shows, e.g., that a Channel must be connected to two Ports and have a defined Data Type. In the previous subsection, the integration of the concept models of requirements and design domains resulted in an immediate embedding of the formalized concepts of the requirements domain into the design domain. Thus the integration of the views of the design domain directly carries over to the views of the requirements domain.


33

As a consequences of this integration, the formalization of requirements specifications during classification enforces the establishment of additional relations not introduced in 3.3.1. E.g., when a Architectural Specification is formalized and motivates a Channel, besides the Name and Description attributes, the Type and the associated Ports must also be identified.

3.3.2

Operationalization: Requirements Specification

This concept model consists of the modeling concepts and their relations used to construct the description of a system. From a CASE-oriented point of view, the concept model is the ‘static data model’ – described in a class diagram-like fashion in the previous subsection – of the specifications visibily supported by the tool. For its application, the CASE tool maps the (graphical) representation of the specifications to the concept model. By defining the structure of possible descriptions of a system, the concept models ensures (syntactic) consistency, avoids ambiguity, and supports the verifiability of specifications. As described in Chapter 2, syntactic consistency conditions can be invariant or variant. While the later may be relaxed during certain steps of the development process and are enforced during others, the former must hold invariantly throughout the development process. Therefore, they are enforced by construction. Generally, only simple consistency conditions are enforced as invariant consistency conditions. Furthermore, the distinction between invariant and variant conceptual consistency conditions is a matter of flexibility and rigorousness of the development process supported by the underlying model. In Subsection 3.3.1, three forms of invariant consistency conditions are imposed on the domain concept model for the formalization of requirements: Classification: Specifications are classified; e.g., each requirement is formalized as a Requirement Specification, which in turn can also be a Architectural Specification, a Model Specification, a Data Specification, or a Functional Specification. Attributation: Specifications are attributed; e.g., each Requirement Specification must have an Id, Title, Description, and Patron. Association: Specifications are associated; e.g., a Component can only be motivated by an Architectural Specification, but not by a Modal Specification; furthermore, an Observation Specification must be associated to a Sequence Specification, which in turn must be associated to a Functional Specification. These constraints imposed on the formalization of textual requirements is reflected in the concept model used: Classification: Each element is classified by assigning it to a conceptual class, e.g., Requirement Specification or Architectural Specification. Furthermore, using specialization, a Requirement Specification, can be refined to an Architectural Specification, a Model Specification, a Data Specification, or a Functional Specification. Attributation: Each element is assigned the required attributes; e.g., Id, Title, Description, and Patron are defined as the atributes of a Requirement Specification.

34


Association: Each element may only be associated to elements linked via an optional or required association; furthermore, it must be associated to elements linked via a required association; e.g., a Component can only by associated to an Architectural Specification via a motivates-relation, but not to a Modal Specification; furthermore, an Observation Specification must be associated to a Sequence Specification via a described by-relation, which in turn must be associated to a Functional Specification. As mentioned in Subsection 3.1.1, in this chapter the concept model is applied by using it to construct models of the product under development as instances of the domain model. Therefore, its is only indirectly operationalized by defining the operations to construct a product model; possible operations are basic operations like the introduction of new elements – e.g., a Requirement Specification, or an Observation Specification – and corresponding relations – e.g., refines, describes, or motivates. However, as the domain concept model does not allow to construct product models that do not respects its invariant consistency conditions, these operations ensure by construction these consistency conditions, leading to the intended structuring and precision of the requirement specification. Section 3.4 shows how these operations are implemented. To that end, the domain concept model is interpreted as the data model manipulated by these operations, as discussed in Subsection 3.1.1.

3.4

Application: Review-Based Requirements Formalization

The concept model of the requirements domain introduced in Section 3.2 supports the structured and formalized description of text-based requirements. However, to effectively use the structure provided by the model, a structured approach to the stepwise construction of this structure is necessary. In Subsection 3.4.1, structuring, classification, and formalization are introduced as the main steps of a review-based requirements engineering process. Furthermore, for an efficient and practical application of this process, these steps must be integrated into a structured development process. Subsection 3.4.2 illustrates the methodical application of these steps, as offered by the AutoRAID component of AutoFOCUS2. The complete functionality of AutoRAID is described in the AutoFOCUS2 Picture Book [Wil06].

3.4.1

Implementation: Requirements Formalization

As mentioned in Section 3.1, the AutoRAID approach supports the stepwise structuring and formalization of a textual specifications in a review-based manner, leading to a formalized model of the system under development. The main steps of this process are

3.4. Application: Review-Based Requirements Formalization

35

Figure 3.8: Describing a Requirement Structuring: Identifying, isolating, and relating sub-requirements of requirements Classification: Classifying requirements as architectural, modal, functional, or data requirements Formalization: Precisely describing requirements to ensure unambiguity and consistency In the following subsections, the basic activities to be performed in these steps are described. As an example, the requirements specification of an instrument board in a car is used. The formalization of requirements of a product under development is based on the principle of instantiation of the reference concept model of requirements, enforcing the structuring, classification, and formalization by – stepwise – construction. Therefore, a mechanism for the construction and persistance of instance models generated from a reference model can be used [BLSS00] to provide an implementation. Structuring A Textual Specification As mentioned in Subsection 3.3.1, the domain model of AutoRAID supports the concepts of sub-requirements and associated requirements to break down an unstructured textual

36


Figure 3.9: Describing Observations of a Scenario Specification

specification into a hierarchy of individual atomic requirements. This step is performed by iteratively walking through the specification, locating coherent parts of the specification, and identifying them as individual requirements. As shown in Figure 3.8, during identification each individual requirement is assigned a unique Identifier, a Title, and further information (e.g., Status, Priority, or Rational), besides its textual Description obtained from the original specification. As already seen in Figure 3.1, generally, a textual specification contains an informal structure (e.g., paragraphs covering the interfaces of a system, the inputs received via its interface, its internal structure, the data managed, the functions provided); this informal structure can be used to obtain a first coarse structuring of the specification. In further structuring steps these still compound requirements are iteratively refined. E.g., as shown in Figure 3.8, the Description of an identified requirements specification dealing with the Inputs received via the CAN interface contains a coherent sub-requirement, describing the signal Actual_Number_of_Revolutions. In order to obtain a more adequately structured specification, this part of the Description dealing with the signal Actual_Number_of_Revolutions must be identified as an individual sub-requirement. This is achieved by creating a new Requirement Specification, which refines specification Inputs received via the CAN, with a Description consisting of the corresponding part of the original description. The main purpose of this step is to obtain individual requirements that can be classified in the next step. Therefore, if a requirement cannot yet be classified as described in the following section, it is further broken down in suitable sub-requirements that in turn can be classified accordingly. Classification of Requirements


37

Figure 3.10: Describing an Observation Specification After breaking down the complete specification in sufficiently atomic requirements, these requirements can be classified according to the scheme provided in Subsection 3.3.1. Using the above example, requirement Inputs received via the CAN is classified as an architectural requirement, stating that the controller of the rev meter has an interface (or port) over which CAN messages are received. Similarly, requirement Actual Number of Revolutions describes a data type requirement, defining the possible values for this type of signal. While basic architectural, model, and data type requirements have rather simple descriptions, functional requirements (described by use cases in from of sequences of observations) contain rather complex descriptions (as shown, e.g., in Figure 3.14 in use case Show RPM of engine in the back window). Their description contains a textual form of the sequence of observations. Therefore, as part of the classification, as shown in Figure 3.9, its textual description is re-structured into a scenario by identifying the individual steps of its sequence of observations (e.g., step 9 of scenario Standard Display Interaction stating that the RevMeter remains in Mode Normal Display Mode). As in the next step of the review process the classified requirements are formalized, all the leaf requirements of the refines-hierarchy – corresponding to, e.g., types, ports, modes, or scenarios – should be classified prior to that next step. Formalization of Requirements As discussed in Subsection 3.3.1 and prescribed by the elements of the concept model shown in Figures 3.2 and 3.3, structuring and classification of requirements basically take place

38


on the textual level. In contrast, the last step of the review process, their formalization, requires the more detailed concept model discussed in Subsection 3.3.1 and depicted in Figure 3.7. To obtain the necessary detailed information, the classified requirements are formalized based on their classification. Therefore, the description of the classified requirements are reviewed to identify the required associated parts of the model of the system. E.g., to formalize an Observation Specification in Figure 3.7, the corresponding Observation must be precisely described by supplying the corresponding Condition and Component (in case of a State Observation) or Expression and Channel (in case of an Event Observation). To that end, as as shown in Figure 3.10 (top window), each step of the scenario of a use case is assigned a type (e.g., Event Observation, State Observation), and then described accordingly. For an Event Observation, sender (e.g., RevMeter_Controller), receiver (e.g., Error_Display), channel (e.g., revmeter_error), and exchanged signal (e.g., No_Error_RPM) are defined.1

3.4.2

Method: Review-Based Formalization

Formalized notations (e.g., forms) for requirements engineering have proven to be best practices, especially in systems engineering [Jon00], especially due the enforced structure and precision. In a model-based approach, the concept domain model provides such a formalized description. AutoRAID therefore uses a concept model for the description of requirements, with its major advantages of providing Structure, allowing to identify common elements to support consistency Precision in form of defined elements of specification, increasing inambiguity Integration, combining analysis and design elements to avoid intractability Strictness by supporting only model-conform specifications, avoiding arbitrary specifications and supporting feasibility and verifiability AutoRAID offers dedicated functionality to structure textual requirements specifications. Figures 3.11 to 3.16 show the user interface of AutoRAID embedded into the AutoFOCUS framework [Sch04]. Its functionality is based on the core steps described in Subsection 3.4.1. AutoRAID assumes a review-based development process: After importing a textual requirement specification, the specification is structured by breaking it up into coherent requirements; these structured requirements in turn are classified ; by successively formalizing these classified requirements, increased precision is achieved. This formalized description is finally used for additional analysis steps and for bridging the gap to design. As depicted, e.g., in Figure 3.15, during all steps the structure of the model under development – for both the conceptual element of analysis and design – is shown in the model 1

Although basically identification of the Channel is sufficient, Sender and Receiver are additionally used for convenience purposes.


39

Figure 3.11: Identifying a Requirement

browser (left hand side of the window). The browser uses a tree-like representation for the requirements model (subtree Analysis) as well as the design-oriented model (subtree Component Car).2 The browser shows the generic specifications (Requirements) as well as classified specifications (Use Cases, Constraints). The working area (e.g., right hand side of Figure 3.15) is used to perform the steps described in the following. Generation and Import of Requirements To create an initial requirements specification as the base of the review process, AutoRAID allows to either manually enter requirements or reuse structured textual documents. When creating requirements manually, a each requirement is automatically assigned a unique ID. Furthermore, the required attributes like Title, Description, Patron, Status, Priority, Rational etc., introduced in Subsection 3.3.1, are added by the user. 2

As the concept model actually is a graph, the browser represents a spanning tree for it.

40


Figure 3.12: Refining a Requirement

By supporting the import of textual documents – either in HTML-format as supplied by word processing tools or in XML-format as supplied by DOORS – textual specifications including their structural information can be used as starting point of the review-based formalization. As shown in Figure 3.11, when creating requirements from an imported document, a ‘select-and-create’ functionality allows to conveniently transform selected source text into a requirement by incorporating the selected text into the Description of a requirement. To support tracing, the link between text and requirement is kept and displayed in the source text. Additionally, for documentation purposes, a structured HTML-document can be generated from the elaborated and refined requirements in AutoRAID.

Structuring Requirements To obtain a detailed structure of a requirement specification, it can be broken down into network of linked individual requirements. According to the relation offered by the concept model in Figure 3.2, AutoRAID offers two functionalities to establish such a structure:


41

Figure 3.13: Classifying an Architectural Requirement • A requirement can be related to one or more further requirements, to identify correlated requirements associated to each other or to describe a common sub-requirement that refines several super-requirements. • Out of an existing requirement a new requirement is created, which refines the original requirement to break up a compound specification in more atomic sub-specifications. Since a major part of structuring consists in splitting up requirements into sub-requirements, AutoRAID offers a convenient ‘select-and-createÕ functionality, to easily identify a part of a Specification to become a separate sub-specification. As shown in Figure 3.12, when a requirement is refined using this functionality, the selected part of the original Description is reused as the Description of the created requirement; additionally, also the original status, priority, etc. are transferred to the created requirement. Furthermore, both requirements are linked to indicate that the original requirement is refined by the newly created requirement. Classifying Requirements

42


Figure 3.14: Classifying a Functional Requirement and Identifying Steps of a Scenario By classification, generic requirements are grouped according to their contained information. By enforcing classification, specifications are broken down into sub-specifications until they are detailed enough to fit one of the categories defined in Figure 3.3 (architectural, modal, data, functional). AutoRAID offers a convenient mechanism to select the appropriated type (i.e., Architectural Requirement, Functional Requirement, etc.) of an identified requirement. As explained in Subsection 3.3.1, for architectural, modal, and data requirements, their descriptions do not differ from the description of generic requirements. Therefore, e.g., the representation of an architectural requirement as shown in Figure 3.13, analogue to a generic requirement. However, as also shown in Figure 3.13, the classification of requirements is reflected in the structural representation of the model browser: classified requirements are listed in the hierarchy of structured requirements as well as their respective category (Architectural Constraints, Modal Constraints, Data Constraints, or Use Cases). Functional requirements require the detailed description of scenarios during classification. Therefore, as shown in Figure 3.14, AutoRAID specifically supports the identification of the steps of a scenario of a use case. ,In a similar fashion to the ‘select-and-create’ mechanism


43

Figure 3.15: Detailing An Event of a Scenario

used for the identification and structuring of requirements, the comfortable construction of a detailed description is supported, automatically transferring the selected Description of a scenario to the Description of its respective step.

Formalizing Requirements To smoothly obtain the preciseness and strictness of a formalized description of requirements, again AutoRAID offers convenient mechanisms to ease the generation of formalized requirements integrated into the product concept model: during the formalization step, the corresponding concept (e.g., Component, ControlState, DataType, Observation) is created; necessary relations imposed by the domain concept model are established (e.g., the SubComponents relation for a Component, or the corresponding obligatory Component of a ControlState); finally, the link through which the corresponding concept is motivated by the originating requirement is established. Thus, e.g., when formalizing the step of a scenario as an event observation as illustrated in Figure 3.15, AutoRAID offers the appropriate concepts (i.e., Event Observation, State

44


Figure 3.16: Graphical Representation of a Scenario

Observation, Mode Observation) reflecting the type of observation corresponding to the

description of the step.

Furthermore, depending of this formalization, AutoRAID offers appropriate elements to establish links to. E.g., for the event observation, a selection of Sender and Receiver components as well as suitable communication Channels available for this scenario are offered. Finally, simple ‘cut-and-paste’ mechanisms allow to defined additional information, like creating the Signal from the Description of the observation. Obtaining Design Descriptions The formalization obtained in the previous step still uses a form-like, text-based description for a quick transition. However, at this level a specification is already formalized in a fashion respecting the strictness and preciseness of a detailed and integrated domain concept model as used for the design. To support a smooth transition to graphical description techniques generally found in design, these specification elements can alternatively be displayed in a graphical fashion.


45

As shown, e.g., in Figure 3.16, for a formalized scenario, a corresponding graphical representation in form of a sequence diagram can be alternatively generated. All Observation elements of the Sequence are depicted graphically; labeled arrows are used for Event Observations, Mode Observations or State Observations are represented by hexagonal boxes. Thus, AutoRAID allows giving a detailed description of the system under development either from the requirements point of view, adding, e.g., rationales to document development decisions; or, from the design point of view, focusing on a compact and comprehensible description. By using shared elements (with either textual and graphical representation), a deep integration of requirement and design specification is enabled. Especially, design elements can be easily traced back to motivating elements of the requirements model, as corresponding associations are established during the generation of the graphical representation. Additionally to the associations established automatically between the formalized requirements and their counterparts in the design model during generation, links can be defined manually between these elements. Analyzing Requirements By enforcing an incremental development process, adding structure and precision through structuring, classification and formalization, AutoRAID supports the step-wise analysis in a review-based and constructive fashion. Through the strictness of the applied model, the model-based formalization implicitly increases the quality of a requirements specification by removing inconsistencies or ambiguities (e.g., when identifying sender, receiver, and signal of a communication event). To additionally improve the overall quality of the model, analysis techniques in form of consistency conditions can be applied to detected possible weaknesses of the structured and formalized model. These consistency – or rather, soundness – conditions are defined in terms of the concepts, attributes, and relations of the domain model introduced in Section 3.3. Some of these conditions used in the AutoRAID approach are: • Status and priority of a requirement cannot be lower than status and priority of any requirement that refines it. • Each requirement must be classified or refined by a further requirement. • Each classified requirement must have a formalized conceptual element motivated by it. These conditions are formalized using the CCL infrastructure of AutoFOCUS [Sch01]. While the structuring, classification, and formalization steps are performed with assisted user interaction, consistency analysis is performed mechanically. Requirements violating these soundness conditions are automatically identified by the AutoFOCUS framework. This form of conformance checking is described in Chapter 4.

46

3.5


Conclusion: Requirements Specification

In this chapter, the benefits of the preciseness and rigidness of a model in model-based development have been illustrated, using the domain of requirements engineering as application domain. By mere application, a structured domain model – integrating different views of the system under development – supports the formalization of text-based requirements is a suitable application domain for this feature.

3.5.1

Summary: Requirements Specification

The proposed approach provides a model-based support for requirements analysis by a reference model of work products of the requirements engineering phase – i.e., a concept model for the requirements engineering domain – and a structured and stepwise transition from textual requirements to a design model. The domain concept model provides a communication base for interdisciplinary consolidation of requirements and guides the iterative refinement and completion to a problem-adequate system specifications. It contains a detailed concept model with different classes of requirements (e. g. business and application requirements, use cases, architectural constraints, modal constraints) and tool-supported steps for integrating requirements analysis and functional system design. Thus, it supports improved quality of the specification of the system, simply by imposing the rigid and precise structure of the domain concept model. As this rigid structure especially counteracts (syntactic) ambiguity and inconsistency by construction, the formalization of text-based requirements is a suitable application domain for this feature. To judge the feasibility of the approach, the tool support was applied in the domain of automotive body electronics with the review and structure system specifications for a dashboard controller and a power-window controller. Due to the structured, domain-specific concept model and strong user support, the approach scales to industrial-size specifications, helping to identify flaws in the functional system specifications otherwise generally only detected either during a structured review using formalized specification templates or during system design. Obviously, by improving the granularity of the model, e.g., by means of additional classifications (stimulus and response in communication events), more detailed structures (preconditions, post-conditions, or alternative executions in improved scenarios), the preciseness of the approach can be improved, however at the cost of the practicability of its application. Furthermore, additional consistency conditions can also be added to improve the approach.

3.5.2

Related Work: Requirements Elaboration

At its essence, model-based requirements engineering corresponds to using a formal model of requirements focusing on their structuring, classification, and integration.

3.5. Conclusion: Requirements Specification

47

Classification of requirements has become a standard practice – however more informaly – in approaches like the IEEE Guide for Developing System Requirement Specifications [IEE98b]. Structuring of requirements along the lines of IEEE 830-1998 [IEE98b] can, e.g., be found in [KS98], [DP04], as well as [vL01]. Core of [KS98] is the analysis and structuring of requirements according to services. The services of the system are described by scenarios. In turn these services can be specified by means of event traces and state transition diagrams. [vL01] defines a methodical concept for the refinement of goals and the mapping of the won detailed requirements to software components (agents). This way a structuring concept of requirements according to functional and non-functional is suggested. However, in none of these approaches a detailed domain concept model combined with stepwise elicitation and structuring of the requirements is given, leaving a gap between analysis and design. [PBG01] uses a meta-model based approach to integrate requirements with model-based approaches, however restricted to use cases and architectural models; no tool infrastructure for efficient development is supplied. A similar approach aiming at obtaining increased precision in a step-wise fashion is described in [DP04]. There, a form- and review-based approach is used to derive a detailed, model-based description of the system. However, while [DP04] uses manually filled-out forms and review-guide-lines, AutoRAID uses an explicit domain concept model incorporated into the AutoFOCUS CASE framework, therefore offering mechanized steps to incrementally develop a specification of the system.

48


Chapter 4 Model-Based Conformance Constraints The application of conformance constraints on the construction of software products – generally in the form of standards providing rules and guidelines for the construction of code – has repeatedly shown its merits in the development process concerning the quality of the product, both with respect to reliability as well as the maintainability. While the use of models in a development process provides an important constructive form of quality assurance, the rich and rigid structure and domain-specific nature of the models used in the development allow to add new forms of conformance constraints to the development process. Here, support for the definition of constraints on the models of the product under development as well the automated enforcement of these constraints proves to be an important asset, improving and front-loading this form of quality assurance in a modelbased approach.

4.1

Introduction: Conformance Constraints

Software systems have reached a level of complexity – in form of a large number of rather heterogeneous and intensively interconnected components – which, if not counter-measured, can easily lead to functional and non-functional quality defects like impaired functionality and reliability or degraded understandability and changeability. To countermeasure these issues in classical code-based approaches, products under development are generally required to conform to certain rules – called coding standards – describing measurable properties of the developed code, to ensure these quality aspects. While the application of conformance constraints has been traditionally exploited in codecentric approaches, due to the rich structure of domain-specific models, its principles can be even more effectively applied to a model-based development process. In this chapter, a model-based approach for the definition and application of conformance conditions is introduced. 49

50

4.1.1

Chapter 4. Model-Based Conformance Constraints

Principles: Structure Analysis

With models permeating the development process and increasing in size, quality aspects like understandability and changeability gain more and more importance. To enforce these quality aspects, constraints ensuring them can be imposed on the models, to hold at certain steps of the development process. Since concept product models are instances of a concept domain model, a rich structure of domain-specific concepts and their interrelations is superimposed on the model, already imposing invariant constraints on the product. However, this structure can furthermore be exploited to define additional variant conceptual constraints, imposed only at certain steps to ensure additional aspects of quality. By embedding those domain-specific concepts and relations into a suitable language, these additional aspects can by formalized as logical constraints. Then, by interpreting these constraints as conditions that must be fulfilled by the model of the product under development and providing a mechanism to automatically check the validity of these conditions with respect to the model, the conformance of the product with these modeling constraints is ensured. Using such a mechanism and structuring the conditions imposed according to the phases of the development process, a process guided by conformance constraints can be established.

4.1.2

Overview: Conformance Constraints

In the remainder of this chapter, the application of conformance constraints to a modelbased development approach is demonstrated. Section 4.2 discusses conformance conditions as a means to ensure the usability of models in a model-based development process: the construction of conformance constraints and their automatic analysis as a possibility to avoid these defects. Section 4.3 introduces the declaration of conformance constraints in a model-based approach. The core features are the declarative, logic-based formalization of conceptual conformance constraints, as well as their evaluation within the conceptual product model. In Section 4.4, the application of this approach is illustrated. To that end, the definition and evaluation of conditions embedded into a phase-oriented, constraint-guided development process is introduced as implemented, e.g., in the AutoMoDe version of the AutoFOCUS CASE-tool framework [Aut04a]. Finally, in Section 4.5, a short summary of the application of conceptual conformance constraints is given, and the presented approach is compared to related work.

4.2

Context: Model Conformance Constraints

4.2. Context: Model Conformance Constraints

51

As mentioned in Section 2.3, concept models applied in model-based development allow to construct a product under development using different models – or levels of abstraction – of the final product, starting from models using concepts of the (domain-specific) application domain and ending with models using concepts from the (platform-specific) solution domain. To construct those models, views are used, and arranged • vertically to reflect the different levels of abstraction (e.g., functional, logical, technical description), • horizontally, to reflect the different aspects of a system (e.g., structure-oriented, behavior-oriented), with each view additionally supporting hierarchical description (e.g., function/sub-function, component/sub-component). Therefore, obviously, in the practical application of a model-based development process, the models constructed generally exceed a size that makes it easy to ensure the validity in terms of completeness or consistency as well as usability in terms of understandability or maintainability. Since, however, a model-based process crucially depends on the quality of the models constructed – especially given the generally large number of different stakeholder found in a complete model-based process – modeling guidelines are established to provide a sufficient level as early as possible. To effectively use those modeling guidelines, consequently, mechanisms are needed to enforce their application.

4.2.1

Problem: Conformant Model Construction

Especially in the context of reliable systems, the importance of constructing models that are conformant to some quality constraints has increasingly gained attentions. Tools like MatLab [Mat02] provide mechanisms to ensure that the model under development respect design guidelines like [Mat07], as discussed in Subsection 4.5.2. Guidelines are given as a set of rules that must be fulfilled by the product under development. These rules impose constraints that must hold for the elements of the constructed model, their attributes, and their interrelations. Rules generally are classified (e.g., ‘Mandatory’, ‘Recommended’, ‘Optional’). Depending on the kind of rules and the characteristics of the development project (e.g., the safety-criticality of the developed system), safety-oriented process like IEC 61508 [Int98] require that models, which do not respect those rules and therefore are not guideline-conformant, are not acceptable as products of the development process. The purpose of constructing models conformant to a set of modeling constraints is to ensure different aspects of quality. On the one hand, typical quality attributes imposed are more formal notions of quality like Completeness: These rules require that certain elements must be present in a model considered conformant. Typical examples are ‘Each requirements must be refined by

52

Chapter 4. Model-Based Conformance Constraints another requirement or associated to a design element.’ or ‘Each channel must have a defined type.’.

Consistency: These rules require that the elements must obey specific relationships in a model considered conformant. Typical examples are ‘An architectural requirement can only be refined by another architectural, but not by a functional, data, or mode requirement.’, or ‘The type of a port and a channel connected to it must coincide.’. On the other hand, there are quality aspects rather dealing with less formal aspects of quality like the maintainability of a product in from of Understandability: These rules improve the comprehensibility of a model. Typical examples are ‘The names of the ports of a component should be unique’ or ‘A component must not have unconnected ports.’. Changeability: These rules improve the modifiability of a model. Typical examples are ‘A basic requirement is only linked to a single design element.’ or ‘A component must not have more than ten direct sub-components.’. The definition of such guidelines and their enforcement – through static analysis or manual review – has shown to be an effective means to reduce defects and improve reusability [Jon00].

4.2.2

Contribution: Conformance Constraints Construction

In the approach presented here, conformance constraints are integrated in a phase-oriented development process. Based on the concept model of the domain of application, techniques are introduced that allow to define conditions capturing constraints that ensure the conformance of the product under development with the imposed quality aspects, and to enforce those constraints at defined steps in the development process. In the following, those support techniques are presented that are implemented in the AutoFocus framework [Sch04]: Conceptual constraint language: Supplying a logical formalism for the definition of conformance constraints based on the classes and associations of the domain concept model. Mechanized analysis of validity: Providing a mechanism to check the validity of a constraint condition with respect to the product under development. Phase-oriented structuring of contraints: Assigning the conformance contraints to phases of the development process and enforcing their validity. The approach is demonstrated using the AutoFocus domain concept model but it can be immediately applied to other application domains.

4.3. Approach: Conformance Conditions

4.3

53

Approach: Conformance Conditions

In order to enforce conformance constraints on products of a specific domain of application, first a formalism has to be supplied which allows to express these constraints as logical conditions over the classes and associations of the concept model characterizing the domain of application. Obviously, this formalism should reflect the concept model introduced in Chapter 2 as closely as possible, to abstract from the actual technical representation of the model of the product. Subsection 4.3.1 introduces such a formalism, based on predicate logic with the classes and associations of the concept model as first-class-citizens. Once the constraints are expressed within this formalism, the corresponding conditions must be evaluated with respect to the model of the product under development to ensure their validity. To that end, in Subsection 4.3.2 a mechanism for evaluating those conditions is presented, determining the validity as well as supplying (counter)examples with respect to the evaluated model.

4.3.1

Instantiation: Model Contraints

The AutoFocus framework supports the definition and execution of analysis operations on instances of the AutoFocus concept model independently of implementation details of the concept model. Those operations are used to define consistency checks of the product model of the system under development. The language is designed to be as operational as possible while maintaining an abstract logical flavor for both efficient and high-level descriptions of model queries. The abstract flavor of the language is needed to support reasoning about the properties of operations defined using CCL (consistency constraint language). Similar to OCL [OMG97], CCL resembles a first order typed predicate calculus with the types (classes) and relations (associations) of the reference concept model; expressions are then evaluated with respect to an instance of the reference model. AutoFocus offers an evaluation mechanism for CCL expressions returning all counter-examples of the current instance of the reference model. These counter examples are then iteratively represented on the level of the description techniques to be inspected by the user. CCL and the Concept Model The overall structure of the CCL constraint analyzer for the AutoFocus system is shown in Figure 4.1. To create a new condition, a CCL description of the condition is defined. AutoFocus parses and internalizes the definition using the parse tree, thus generating an evaluation tree and an appropriate evaluation scheme described in [Sch01]. As the internal form represents the definition in an executable way (an object tree with nodes accessing the model, the user interface, or querying other nodes), the condition becomes part of the

54

Chapter 4. Model-Based Conformance Constraints User Interface

View Interface

CCL Condition

Optimized, internal form

Evaluation scheme

Constraint Analyzer

Product Model Interface

Product Model

Figure 4.1: Structure of the AutoFocus CCL System operations of AutoFocus. A detailed description of the AutoFocus modeling techniques, the definition of consistency conditions and the model based process is given in [HSE97a]. As discussed in Chapter 2, the concept domain model describes, which modeling concepts are used during the development process (like components, channels, ports, states, transitions) and how those concepts are related (for instance, “a channel connects two ports”). Depending on the domain the concept model is used for, different a modeling elements might be needed (for example, data oriented concepts like class, object, association, as found in UML [FS97]). In the following the basic domain concept model of AutoFocus is used; a simplified version – omitting some of the associations, role names, as well as all attribute names – is shown in Figure 4.2. A more complete version of an AutoFocus domain concept model explained in more detail in [BLSS00]. From the perspective of CCL, the reference concept model essentially defines the classes and associations representing the corresponding class diagram, as described in Chapter 2. If the domain concept model is compared with an E/R-diagram or a class diagram, the product concept model can be compared to a concrete instance of those like a database or an object diagram. Thus, while operations like SQL queries or CCL expression are defined using the E/R-diagram or the concept model, resp., the queries are analyzed using the database instance or the product model. Using the definition of a concept model introduced in Chapter 2, an instance concept model IM = (IE, IR) consists of a collection of (finite) sets of model elements IE = {E1 , . . . , Em } with each Ei corresponding to a conceptual class of the corresponding reference model, and a collection IR = {R1 , . . . , Rn }

4.3. Approach: Conformance Conditions DataElement

55 1

0..*

Type 1

0..* 0..* Component

Component

0..*

0..*

Port 1

1 Type 0..*

SourcePort

1

0..1 0..1

1 1

Channel

DestinationPort

0..*

SubComponent

1

DataType

InPattern

0..* 1 Pattern 1

ControlState

OutPattern

0..* 0..*

SubState

0..*

Connector 2 0..2

0..*

Transition

0..* 0..*

0..* InputPattern 1..* 0..* OutputPattern 1..* PreCondition PostCondition

Figure 4.2: Simplified AutoFocus Concept Model with Ri ⊆ Ei1 × Ei2 of model relations, again each Ri corresponding to a conceptual associations of the reference model. Subsection 4.4 explains how the evaluation scheme links CCL elements (variables quantified over conceptual model elements as well as basic predicates corresponding to conceptual relations) to the instance model. Basics of the Language The consistency constraint language (CCL) is used to define consistency conditions to be fulfilled by instances of the reference concept model. Basically, CCL corresponds to a typed first-order predicate logic with a collection of predefined types and predicates. As described in Subsection 4.3.1, those types and predicates are derived from the classes and associations of the reference model. A constraint is defined by an extended first order formula using universal and existential quantification as well as logical junctors like conjunction, disjunction, negation and implication. Thus, in a simplified version, the grammar is basically defined by the following production rules shown in Table 4.1. Here, Class and Association correspond to the names of classes and associations of the reference domain model. Furthermore, appropriate production rules for the definition of basic predicates are available. Basic Sorts, Predicates and Conceptual Model

56

Chapter 4. Model-Based Conformance Constraints Formula

::=

Formula

::=

Formula Formula

::= ::=

Predicate ::= Equation :: = Expression ::=

forall Variable : Class . Formula | exists Variable : Class . Formula Formula and Formula | Formula or Formula | Formula implies Formula | neg Formula ( Formula ) Predicate | Equation Association(Variable,Variable) Expression = Expression Expression.Selector | Variable

Table 4.1: Simplified CCL Grammar CCL allows to check an instance model of a reference model. This check is performed by evaluating a CCL formula. However, to evaluate the formulas for a given instance model, a connection between the basic types (used, e.g., with forall) and basic predicates (used, e.g., with SubComponent) and the instance model must be supplied. This connection is established by introducing a basic type for each conceptual class as well as basic predicate for each conceptual association of the reference model. Basic types are all entities of the reference model, i.e. • Basic types like Integer, Boolean, String. • Conceptual types like Component, Port, Channel, provided by the domain concept model Basis predicates are all associations of the reference model, i.e. • Basic associations like Name induced by attributes of components, ports, etc. like Name, etc. • Conceptual associations like SourcePort or SubComponent, provided by the relations of the domain concept model. Therefore, to formalize the condition that the names of all ports of a component must differ in a pairwise fashion, the corresponding CCL expression is forall p1 : Port . forall p2 : Port . ((p1.Component = p2.Component) and neg (p1 = p2)) implies neg (p1.Name = p2.Name) assuming the concept domain model from Figure 4.2. It provides quantification over Ports (as well as Components or Channels), as well as attribute relation Name and association

4.3. Approach: Conformance Conditions

57

relation Component (linking ports to components); the latter can be used for selector expressions as well as relation expressions. Alternatively, therefore exists c : Component . Component(p1,c) and Component(p2,c) could have been used instead of p1.Component = p2.Component Besides those basic sorts, more advanced sorts are also supported, e.g., sets of elements. Consequently, CCL also offers suitable constructs on these sets, including the definition of sets via set comprehension as well fixed-point construction, thus exceeding the possibilities of other languages like OCL.

4.3.2

Operationalization: Constraint Analysis

The AutoFocus system basically evaluates an CCL formula with respect to a given instance model and states whether the formula can be satisfied. Additionally, the set of satisfying assignments for the quantified variables of the expression is constructed. To check the validity of an expression and to generate counter examples it thus suffices to test the negation. In CCL, variables are quantified over the instances of reference model classes using forall or exisis. Consequently, when checking for the existence of a corresponding instance element by exists e : Class . ...

this corresponds to ∃e ∈ EClass . . . .. Accordingly, to check for the existence of an relation instance of the reference model association, the CCL basic predicate association(v1,v2)

corresponds to (e1 , e2 ) ∈ RAssocation for those ej bound to vj.

To evaluate complex expressions, two forms of information are needed. This information is constructed for each sub expression of the complete expression during the evaluation: Assignment of free variables: The mapping of variables not bound or bound by quantors ‘outside’ of the sub expression to values of the universe. Evaluation: The evaluation of the (sub) expression under consideration using the associated assignment of free variables. For the construction of suitable assignments of the bound variables of the (sub) expression leading to the Boolean value tested for the following forms of information are needed:

58


Goal value: The value the (sub) expression under consideration is tested for using the associated assignment of free variables and a possible assignment of bound variables. Set of assignments: A set of assignment for bound variables of the (sub) expression under consideration leading to the goal value as evaluation. The evaluation algorithm is defined as a run through the internal representation of the expression. In the following, the run is described as an attribute flow graph. For each node of the graph of the internal representation the associated attributes and the construction of their values are described. For the top-down flow, the following attributes are used: Free: The assignment of the free variables of the sub expression. Goal : The goal value the sub expression is tested for. For the bottom-up attribute flow the following attributes are needed: Value: The value the sub expression evaluates to using the assignment of free and bound variables. Bound: The set of assignments of all variables bound within the sub expression under consideration leading to the value of the sub expression. Depending on the kind of node, the attribute flow is computed differently. In case of disjunction, e.g., a simple scheme is sufficient: • The assignment of the free variables of the disjuncted expressions is the assignment of the free variables of the disjuncting expression. • The goal value of the disjuncted expressions is the goal value of the disjuncting expression. • The result value of the disjuncting expression is the disjunction of the result values of the disjuncted expressions. • The set of assignments of the disjuncting expression is the union of the assignments of the bound variables of the disjuncted expressions. In case of quantification, e.g., evaluation is performed by iteration over the evaluation for the qualified expression. For each iteration, depending on the range of the variable (e.g., Component, Port, Channel) the quantified variable is bound with a new instance element of the product model: • The assignment of the free variables of the quantified expression is the assignment of the free variables of the quantifying expression with addition of the corresponding assignment of the qualified variable for each iteration. • The goal value of the quantified expression is the goal value of the quantifying expression. • The result value of the quantifying expression is the conjunction of the result values of the quantified expression of each iteration.

4.4. Application: Conformance Analysis

59

• The assignment of the bound variables of the quantifying expression is the set of assignments of the bound variables with the addition of the assignment of the quantified variable for each iteration with the corresponding result value. Similar to quantification, the application of a base predicate relates the evaluation to the product model. Unlike the quantors, however, the base predicate is interpreted as a leave node of the evaluation tree. Thus, only the flow of the attribute values for bottom-up attributes must be defined: • The result value of the base predicate is true if such an instance of the named relation with the assignment of the free variables exists; otherwise, false. • The set of assignments of the bound variables of the base predicate is the assignments of the free variables if result and goal value are equal, else empty. A more detailed description of the evaluation algorithms, including the scheme for all the other elements of the language, can be found in [Sch01].

4.4

Application: Conformance Analysis

In Section 4.3 the formalization of conformance constraints over a concept model and their evaluation with respect to given product model was introduced. Based on these principles, conformance analysis can be understood as checking the validity of conceptual constraints imposed on the product under development. To effectively use conformance analysis, the application of constraints must be mechanized and structured. Subsection 4.4.1 demonstrates, how the evaluation of conditions can be automated. Furthermore, Subsection 4.4.2 illustrates how those conditions can be applied to a structured development process guided by conformance constraints.

4.4.1

Implementation: Constraints Automation

Although, conformance analysis can be understood as checking the validity of conceptual conditions, for practical application, issues besides the evaluation have to be considered. Therefore, as shown in Figure 4.3, in AutoFocus, the definition of a consistency condition consists of • a Constraint Name for selecting the the condition using the process interface • an informal Constraint Description, generally of the purpose of the condition and possible remedies in case the condition does not hold for the model • a CCL expression formalizing the Condition Definition As mentioned above, a consistency condition is described as a (CCL) predicate, which is supposed to hold for the model of a system. Therefore, besides the validity of the

60


Figure 4.3: Defining a Conformance Condition

consistency condition, the collection of all model elements not satisfying the condition are an important result in case the condition is not satisfied. Accordingly, the user is rather interested in in all model elements satisfying the complement of the consistency conditions. As described in Section 4.3.2, when evaluating an CCL expression, besides returning the validity of the expression, the interpreter returns the set of all satisfying assignments of the quantified variables of the expression. Therefore, when performing a check of a consistency conditions, the complement of the corresponding CCL expression is checked. If the complement is not satisfiable, the consistency condition holds for the model. Otherwise, which is the case used for model conformance analysis, the collection of model elements not satisfying the consistency condition is returned. This collection is constructed as a set of assignments for the quantified variables of the condition. As shown in Figure 4.4 in AutoFocus, this result is returned as a list of assignments; additionally, the informal description of the consistency check is presented to support the user in correcting the inconsistency. To simplify correcting a violated consistency condition, AutoFocus provides a simple navigation mechanism from such an assignment to the graphical representation of the model: by activating an assignment from the list of inconsistencies, the corresponding editors containing the violating element is presented.

4.4.2

Method: Conformant Construction

Conformance constraints are imposed in a development process to establish qualitative aspects of the product under development. As mentioned above, those conformance conditions are not always applicable throughout the development process, but rather at certain stages of the process. Thus, besides measuring the overall quality of the product, they can additionally be used to structure and guide the development process, by characterizing certain phases of development.


Figure 4.4: Counterexamples of a Constraint Evaluation

61

62


Phases define a coarse structure of a process. They can be associated to conditions that must be satisfied before or after the phase. Each phase has an associated set of activities that can be performed during this phase. Typical examples are phases like “requirements analysis” or “module implementation”. Simplified examples for corresponding conditions are “each requirement must be mapped to an element of the domain model” to hold at the end of requirements analysis or “each component has an implementable behavior” to hold at the end of the implementation phase. Using the consistency mechanism, development is guided by checking which conditions must be satisfied to move on in the process. By imposing an order of conformance constraints, these conditions indicate which activities should be performed when in the development process and increase the efficiency by additionally supplying – depending on the current phase of development – suitable operations support those activities. Thus, conformance constraints are used to indicate qualitative properties of a model, combined with activities to improve those qualities, as well as grouped into coherent phases to form a process. Consequently, a process is used in two different aspects: on the one hand, by the process engineer, defining a (domain-specific) development process by supplying suitable phases and activities; on the other hand, by the system engineer, using the process to model and build the system under development. Both aspects are described in the following. Process Introduction Once a concept model of the domain of development is given, conceptual conformance constraints can be defined. To structure them in a development process, three steps have to be taken: • defining conditions • grouping conditions to phases • grouping phases to processes These steps are explained in the following. Defining Conditions An entry condition for a phase can be understood as a conformance condition for this phase. Therefore, as mentioned above, essentially a condition consists of a CCL-description of the qualitative aspect of the product model under development to be enforced for this phase. To practically use the condition, additionally a descriptive name and an informal description is required; the former to assign a condition to a phase and to identify it in the checking procedure; the latter to provide a rational why this condition is imposed and to supply references to possible activities to remedy a product model not respecting this condition. Figure 4.3 shows the dialog for the definition of a condition. Once a condition is defined, it can be applied in defining the entry conditions of a phase.


63

Figure 4.5: Defining the Constraints and Activities of a Phase Defining Phases Phases basically consist of conditions imposed and activities supplied during the corresponding step of a development process. Therefore, for its definition, the following attributes are needed: • A Phase Name for selecting the phase during the execution of a process • A short informal Phase Description of the phase, providing its rational, including goals to be achieved in the phase • An abitrary number of Entry Conditions, which must be satisfied by the product under development upon entering the phase • An arbitrary number of Activities available for the modification of product under development during the phase The definition of activities in form of complex transformations of the conceptual description of a product unter development is described in more detail in Chapter 5. Figure 4.6 shows the dialog for the definition of a phase; since phases may impose and supply large collections of conditions and activities, resp., both can be hierarchically clustered to groups to improve their presentation during the application of a phase. Defining a Process Once the phases of a process have been defined by providing their associated entry conditions and available activities, these phases can be grouped together to

64


Figure 4.6: Defining the Phases of a Process form a complete development process. Figure 4.6 shows the definition of such a complete process with possibilities to add, delete, and edit its phases. Additionally, to provide a starting point for the application of a specific process, one of its phases can be marked to be initial to define the first phase during the execution. Process Application After a process has been defined, it can be applied to the development of a product by executing the process. The application of a defined process consists of • the selection of the current phase during the development process, and • the application of activities defined for the current phase. At the beginning of the development, the inital phase as defined by the process definition is selected by starting the execution of the selected process. By imposing entry conditions of phases, conformance conditions are successively imposed on the product under development. Additionally, activities can be provided to supply suitable activities helping to establish these conditions. Switching Phases During the development process, the current phase of a process can be set to a new phase, provided the entry conditions of the new phase are fulfilled by the current product. Once the conformance of the product to the imposed conditions has be established, the process can be switched to the new phase, thus also providing the activities defined by the new phase. Since processes may fork to provide alternative paths, entry


Figure 4.7: Selecting the Phase of a Process

Figure 4.8: Initiating the Check of Entry Conditions of a Phase

65

66


Figure 4.9: Checked Conditions of a Phase rather than exit conditions are used to guard alternative phases. Figure 4.7 shows the selection of a new phase provided by the currently executed process. Upon the selection of a new phase initiated from the current phase, the entry conditions of the selection are presented. In order to switch from one phase to another, the entry conditions of the new phase have to be checked. Figure 4.8 shows the dialog for the selection of a phase concerning the checking of the entry conditions. Once the conformance of the product to these conditions is established, the selection of the new phase can be completed. Checking Conditions Since the entry conditions form a necessary pre-requiste to switch from one phase to the next, their validity has to be established to actually perform the change of phases. To that end, the constraints of the entry conditions are evaluated as described in Subsection 4.4.1. If all conditions are satisfied, the phase can be changed. Otherwise – as shown in Figure 4.9 – violated entry conditions like ‘Unique Port Names’ are reported, and can be inspected as described in Subsection 4.4.1.

4.5

Conclusion: Model Conformance Constraints

In this chapter, the use of a concept domain model to support the analysis of its instances has been illustrated, with the development of models conformant to some modeling guideline as application context. By providing a language capable of expressing conditions about those instances, conformance constraints can be defined to formalize these guidelines.

4.5. Conclusion: Model Conformance Constraints

4.5.1

67

Summary: Model Conformance Constraints

The approach presented here supports a model-based development process using conformance constraints to guide the developer through the phases of the process. To that end, the approach exploits the fact that the conceptual domain model allows to define a conceptual product model to be interpreted as its instance, and furthermore provides a vocabulary capable of defining properties of such an instance. By adding a mechanism to automatically check for the validity of these properties with respect to a product model and report violations on the level of the product model, conformance analysis can be supported by translating constraints of the guidelines to conformance conditions and using this mechanism for their validation. Finally, by embedding this mechanism into a phase-oriented development, the concept model allows to support a development process guided by conformance constraints. Applied in the automotive power-train domain, the constraint language showed its capability to support tool-users in capturing conformance rules for a model-based design process. The application of a process with those rule to the development of logical architectures in the domain of automotive motor management – with several hundred components and check-times of a few seconds – has demonstrated the applicability to industrial-size models of a product under development, helping to detect and remove constraint violations during design. The quality-gate mechanism used here is rather strict concerning constraint violations. Extensions might include a more relaxed scheme, supporting the classification of conditions (e.g., ‘Mandatory’, ‘Recommended’, ‘Optional’) and guiding the process depending on additional parameters, e.g., the characteristics of the development project.

4.5.2

Related Work: Constraints Conformance Analysis

Since analyzing the conformance of a model of a product to a certain modeling guideline is becoming increasingly relevant for the model-based development process, corresponding functionalities are added to tools supporting this kind of process. For widely used tools like MatLab [Mat02] additional mechanisms – integrated into the tool itself or provided as a stand-alone checker – ensure that the model under development respect conformance constraints. However, since often those mechanisms use the API of the tools (e.g., MScript for MINT or Model Advisor [Mat02]; Java for MATE [SDP08]; MDL for ConQAT [DJH+ 08]), conformance constraints are rather defined on the level of the concepts of implementation than at level of the concepts of the domain of implementation. In [FR06], an approach is described similar to the mechanism introduced here concerning the formalization of conformance constraints; there, OCL is used to define conditions, thus leading to a less expressive language for formalizing conditions. Furthermore, unlike the approach presented here, it does not provide a mechanism to suggest remedies by referring to suitable operations to fix the defects.

68


Additonally, since the above-mentioned tools generally cover specific parts of the development process, they do not include the notion of process phases. Therefore, conformance constraints are not bundled up phase-specific sets of conditions, but are rather have to be enabled or disabled individually during each step. Finally, these tools are rather seen as advisory tools and are not integrated into a quality-gate controlled development process as shown here, where conformance constraints guide the phases of the development process.

Chapter 5 Model-Based Architectural Refactoring In the construction of complex systems, the design of the architecture plays an important role concerning many - especially non-functional – properties of the resulting system. Therefore, improving these properties by restructuring, or refactoring, the overall architecture of a system is an essentail step in systems engineering. In a model-based development process, architectural models are explicitly constructed during design and directly used in subsequent steps. Here, architectural refactoring can be especially effective by providing mechanisms to support the definition of refactoring patterns as well as their application to these models under development, improving the efficiency of the development as well as the quality of the resulting system.

5.1

Introduction: Architectural Refactoring

The architecture of a system defines the modularization and decomposition of the overall functionality of the system, thus influencing aspects like reliability and maintainability. Due to the importance of the architecture, architectural guidelines for its construction help to ensure a good structure of a system by defining rules how to identify elements of the architecture disrespecting these principles. Architecural refactorings – describing patterns of transformation of architectural models – provide a mechanism to improve these deficiencies using a set of standard solutions. Refactoring has so far mostly been used in code-oriented, and especially object-oriented approaches; nevertheless its principles can be readily carried over to a model-based approach, becoming even more effective due to the explicit use of models. Therefore, in this chapter, the use of transformations in a model-based approach to architectural refactorings is demonstrated.

5.1.1

Principles: Structural Transformation 69

70

Chapter 5. Model-Based Architectural Refactoring

Since the architecture plays a decisive role with respect to quality aspects like reliability or maintainability, restructuring architectural models to ensure those additional qualities becomes an important part of the development process. Here, refactorings, describing how to transform the structure of architectural models to improve those aspects, are suggested during the design phase. Similar to the case of the structural analysis of conceptual product models, the principle of structural transformation makes use of the fact that, in a model-based approach, a product model comes with an explicit structure composed of domain-specific concepts and their associations; therefore, transforming this structure corresponds to transforming the product model. By providing a language capable of relating properties of those structures of concepts and associations, a transformation can be understood as a relation between a product before and after the transformation. Then, by applying one argument of this relation to the model of the product under development and by providing a mechanism to constructively compute the other argument, the relation creates the transformed product. Thus, by formalizing standard operations of a development process – including architectural refactorings – as transformation relations, the process can be supported by mechanized operations.

5.1.2

Overview: Architectural Refactoring

In the remainder of this chapter, the application of architectural refactoring in a modelbased development process is illustrated. Section 5.2 discusses refactoring steps to improve the quality of the architecture of a system in a model-based development process: the definition of refactoring operations and their automatic execution as a possibility to perform refactorings. Section 5.3 introduces the declaration of transformation operations in a model-based approach. The main principles are the definition of simple operations to (de)compose conceptual product models, as well as their combination to form declarative, relational, and rule-based descriptions of transformations. In Section 5.4, the application of this approach is illustrated. To that end, the definition and (parameterized) execution of transformations embedded into a phase-oriented development process is introduced as implemented in the AutoFocus CASE-tool framework. Finally, in Section 5.5, a short summary of the application of transformation operations to refactor architectures is given, and the presented approach is compared to related work.

5.2

Context: Architecture Construction

Due to the central role of architecture to the overall development, an essential part of the construction of the architecture concerns its evaluation and improvement, requiring to

5.2. Context: Architecture Construction But:Ind

But:Ind

But:Ind

Mot:Dir

Window Control Bat:Vlt

Bat:Vlt

Bat:Vlt

Mot:Dir


Res:Inf

Window Control Unit

But:Ind

Error Store Res:Inf

Window Control Unit

Mot:Dir

Err:Cod

Err:Cod

71

Dia:Cmd Dia:Cmd

Req:Cmd

Res:Inf

Req:Cmd

Res:Inf

Req:Cmd

Bat:Vlt

Mot:Dir

Mot:Dir

Bat:Vlt

Bat:Vlt

Err:Cod


Res:Inf

Sts:Cod

Dia:Cmd

Dia:Cmd Dia:Cmd

Err:Cod

Res:Inf

Error Store

Req:Cmd

Diagnosis Management Sts:Cod

Mot:Dir

Err:Cod

Req:Cmd

Sts:Cod

But:Ind

Window Control

Diagnosis Management Dia:Cmd

But:Ind

Req:Cmd

Sts:Cod

Sts:Cod

Sts:Cod

Figure 5.1: Variations of Grouped Components • detect flawed parts of the model leading to a degradation of the quality of the system under development • identify potential solutions to eliminate these flaws from the model • apply a solution transforming the model to an improved model As shown in Chapter 4, in model-based development, conformance constraints can be used to detect flaws given in form of anti-patterns or ‘architectural smells’ and to guide the development process; typical applications of these constraints are conditions ensuring the improved reliability or maintainability of a system. Since a process based on quality gates enforces the validity of these standardized qualities, standard operations to countermeasure corresponding quality defects can especially improve this kind of process. To effectively use architectural refactoring in the above setting of architectural construction, it is necessary to associate refactorings to defects they can countermeasure and to provide a mechanism to apply them to those defects.

5.2.1

Problem: Architecture Restructuring

The impact of the choice of structure of a system – in form of class hierarchies – and therefore the use of refactoring steps – in form of restructuring classes including their interfaces and specialization hierarchy – has become common-place in the object-oriented paradigm. Libraries of refactoring patterns like [Fow00] provide a large collection of bestpractice transformations, improving code structures. However, the principle of refactoring can also be applied to structures like architectures of systems composed of interacting components. Especially the definition of the (logical) architecture during the design phase plays a central role in the development of a system: By breaking down a system into communicating and cooperating subsystems and thus deciding

72


about structural as well as functional decomposition, many properties like reliability or maintainability are essentially influenced by this step. Architecural refactorings – describing patterns of transformation of architectural models – provide a mechanism to improve these quality aspects using a set of standard solutions. Often, this architectural restructuring – changing the decomposition of the system – improves reliability or maintainability even without changing the functional aspects of the system. A typical example is the relocation of a subcomponent from a hierarchical component to a sibling component including its connecting channels, influencing, e.g., the number of subcomponents of those components as well as the number of ports between those components. Figure 5.1 – using the example of a window control steering a power window, combined with an error store and a diagnosis control unit for error management – illustrates the effect of restructuring the architecture of a system: On the left-hand side, component Window Control Unit contains subcomponents Window Control and Error Store, while component Diagnosis Control Unit contains only the Diagnosis Management. On the right-hand side, Error Store is a subcomponent of component Diagnosis Control Unit instead. Obviously, this refactoring allows to change the size of components (in number of sub-components) without influencing the functionality of the system. Additionally, grouping related functionalities in the right-hand side leads to smaller interfaces and thus, e.g., to improved maintainability. Refactoring steps may influence different parts of an architecture, therefore affecting different aspects of quality: • Refactorings only affecting the interface of a system, like ‘Internalizing an unconnected external port of a component, making it invisible at the interface’ and its inverse ‘Externalizing an unconnected internal port of a subcomponent, making it visible at the interface’. • Refactorings only affecting the structure of a system, like ‘Encapsulating a collection of components in a new component, turning them into subcomponents of the latter ’ and its inverse ‘Taking all subcomponents out of a component, eliminating the latter ’. • Refactorings affecting the structure and interface of a system, like‘Pulling a subcomponent out of a component, turning it into a sibling of the later ’ and its inverse ‘Pushing a sibling into a component, turning it into a subcomponent of the later’. Furthermore, refactorings can be combined to form more complex refactorings; e.g., encapsulation of a collection of components can be achieved by collectively pushing them into a new component. However, rearranging architectural models based on informal descriptions of refactorings and manual application is a cumbersome and error-prone task. Errors in the refactoring step may even introduce new faults into the system. Therefore, in the following, an approach is introduced, allowing a simple, precise, and modular specification of refactorings as well as their automatic execution. The approach uses a declarative relational style to provide a transformation mechanism. It is implemented on the Eclipse platform, using a

5.3. Approach: Model-Based Architectural Refactoring

73

term-based abstract representation of an EMF Ecore description and a Prolog rule-based interpretation.

5.2.2

Contribution: Refactoring Architecture Transformation

The approach presented in the following sections supports the transformation of concept product models using a declarative relational style in a rule-based fashion: Relational: A transformation is described as a binary relation between the models before and after the transformation; models themselves are described as relations. Declarative: The description of the transformation relation characterizes the models before and after the transformation rather than providing an imperative sequence of transformation operations. Rule-Based: The relations and their characterization of the models are described using a set of axioms or rules. To support this style of description with its simple, precise, and modular specification of transformation relations on the problem- rather than the implementation-level, three essential contributions are supplied by the framework presented here: 1. The term-structure representation of models based on the structure of the metamodels they instantiate, as well its implementation in the Eclipse framework, providing the translation of models of EMF Ecore-based meta-models into their corresponding term-structure. 2. The relational formalization of model transformations, as well as its implementation using a Prolog rule-based interpretation, providing the execution of transformations within the Eclipse framework. 3. The application of relations as execution of – generally parameterized – transformations, as well as its implementation as an Eclipse plug-in, providing support for the definition and the execution of relational transformation rules. While the approach is here demonstrated for the purpose of architectural refactoring of AutoFocus product models, it can be used to also define other forms of operations as well as applied to other concept models.

5.3

Approach: Model-Based Architectural Refactoring

As mentioned in Section 5.2, the purpose of the presented approach here is to provide a mechanism for the transformation of architectural descriptions of a system under development, supporting architectural refactoring. In this section, the refactoring by pushing-in or pulling-out a component as mentioned in Subsection 5.2.1 is used as example. The refactoring is demonstrated by refactoring a

74

Chapter 5. Model-Based Architectural Refactoring Contr

Context Out

Out

Out

OutDst Sib

OutLeft

OutSrc

InDst

Comp

InLeft

InMid Contr

InRight InMid

InSrc Sub

Figure 5.2: Example: Hierarchical Component Model simple model of a product shown in Figure 5.2, as it is used in the AutoFocus approach to describe the architectural structure of a system: the system Context, consisting of subcomponents Sib, Comp, and Contr, the latter with subcomponent Sub; the components have input and output ports like OutDst and MidIn, connected by channels like InLeft. Subsection 5.3.1 introduces a structure formalizing a concept product model suitable for transformation and shows its implementation within Prolog. Subsection 5.3.2 demonstrates how this structure can be exploited to implement transformation rules in a pattern-like fashion.

5.3.1

Instantiation: Structure Formalization

Following the notions of a reference concept model and an instance concept model introduced in Chapter 2, the reference model is understood to characterize all possible system models built from the modeling concepts and their relations used to construct a description of a system. Thus a reference model – like the AutoFocus domain concept model used to describe the architectural structure of a system shown in Figure 5.3 in the typical class diagram notation – with its conceptual classes and assocations provides a structuring of the elements and (binary) relations of the corresponding instance model. This structure imposed on an instance model is used in the following to provide a formalized representation of a product model, usable in declarative, relational transformation rules. Similar to the case of the conformance constraint analysis of the previous chapter, the transformation framework discussed in the following provides the possibility to define transformation rules independent of the actual implementation of the concept model. Analogue to the approach described in Subsection 4.3.1, the classes and associations of the reference concept model are mapped to the formalism used to define transformations, to make the corresponding conceptual elements and relations of an instance model available to the execution of these formalized transformations. However, instead of embedding them into a predicate-logic like calculus, in this subsection, a formalization of reference and instance models based on relations is used suitable for their representation in a declarative fashion using Prolog style. Formalization


75

SubComp Component -name : String -comment : String

portComp 0..* Port -name : String -comment : String -direction : Direction

1 1

0..*

chanComp 0..* Channel srcPort -name : String 0..2 -comment : String dstPort 0..2

Figure 5.3: Class Diagram Representing the Structure of the Model A (domain) concept model introduced in Chapter 2 does not distinguish between different kinds of classes and associations. However, as shown in Figure 5.3, often a distinction between domain concepts and base concepts – reflected in classes and attributes – can be found. Such a distinction also implies a distinction between regular associations – only used between classes – and property associations – used between classes and attributes – correspondingly. Assuming this distinction, a reference domain model consists of Concepts: Classes of entities used to describe a system; typical examples in the AutoFocus concept model are the concepts component, port, or channel to define the components, ports and channels of a structural description of a system. Attributes: Attributes assigned to those entities; typical examples in the AutoFocus concept model are the string attributes to define the name of a component and a channel, or the Direction attribute (input or output) to define direction of a port. Associations: Classes of relations between entities in a systems; typical examples in the AutoFocus concept model are the associations subComp, srcPort, or dstPort to define the subcomponents of a component, as well as the source and destination ports of a channel. Properties: Associations between entities and their necessarily defined attribute values; typical examples in the AutoFocus concept model are the properties name or direction to define the name of a component, port, or channel, as well as direction of a port. Within the framework introduced in Chapter 2, this can be achieved by an additional reference model ({class, attribute}, {association, property} with • àssociation = class, association´= class • `property = class, property´= attribute refining the base model.

76


This additional structure, of course, carries over to the instance model with its elements and relations. Here, while basically similar to the approach used in Subsection 4.3.1, the formalization of the corresponding graph additionally makes use of the fact that the attribute values of an element are always defined. Thus, the relational representation of an instance model consists of: Elements: Objects used to model a system; typical examples in the AutoFocus conceptual model are the instances of the concepts Component, Port, or Channel including the attribute values associated via their property relations name, comment, or direction. Relations: Dependencies between the elements; typical examples in the AutoFocus conceptual model are the instances of the assocations subComp, chanComp, or srcPort, without the property associations. Using this relational structure, an instance model IM = (IE , RE ) consists of a collection IE = (E1 , . . . , Em ) of relations Ei ⊆ Ci × Ai,1 × . . . × Ai,ki – with each Ci corresponding to a conceptual class and each Am,n corresponding to an attribute type – between elements and attribute values associated via property relations, and a collection of R = (R1 , . . . , Rn ) of (binary) relations Rj = Cj,1 × Cj,2 between elements.

In case of the AutoFocus conceptual domain for structural descriptions as provided in Figure 5.31 , examples for sets Ci are CompId = {comp 1 , comp 2 , . . .}, and PortId = {port 1 , port 2 , . . .}; typical examples for Ai are CompName = {‘Sib’, ‘Context’, . . .} or PortDir = {input, output}. Examples for sets Ei are Component = CompId ×CompName with values {(comp 1 , ‘Context’), (comp 2 , ‘Sib’) Port = PortId × PortName × PortDir with values {(port 1 , ‘OutStart’, output), . . .}, or Channel = ChanId × ChanName with values {(channel 1 , ‘OutLeft’), . . .}; typical examples for Ri are SubComp = CompId × CompId with values {(comp 1 , comp 2 ), . . .} or srcPort = ChanId × PortId with values {(channel 1 , port 1 ), . . .}. This structure of the instance concept model – imposed by the refined structure of the reference concept model – is reflected in the Prolog formalization presented in the following. Structure of the Model The transformation framework provides mechanisms for a pure declarative, rule-based approach to model transformation. To that end, the framework provides access to EMF Ecore [SBPM07] models. As described above, basically a product concept model is a collection of sets of elements (each described as a conceptual entity and its attribute values) and relations (each described as a pair of conceptual entities). To syntactically represent such a model, a Prolog term is used. Since these elements and relations are instances of classes and associations taken from an EMF Ecore model, the structure of the Prolog term – representing an instance of this 1

For simplification purposes, the Comment attribute is ignored in the following.


77

model – is deferred from the structure of the model. The term comprises the elements and relations, which are the instance of the classes and associations of the corresponding EMF Ecore model. The term is therefore grouped according to the structure of the EMF Ecore model, depending on the package structure of the model and the classes and references of each package. The structure of the model is built using only simple elementary Prolog constructs, namely compound functor terms and list terms. To access a model, the framework provides construction predicates to deconstruct and reconstruct a term representing a model. Since the structure makes only use of compound functor terms and list terms, only two classes of construction predicates are provided, namely the union operation and the composition operations. Term Structure of the Model A model term describes the content of an instance of a EMF Ecore model. Each model term is a list of package terms, one for each package of the EMF Ecore model. Each package term, in turn, describes the content of the package instance. It consists of a functor - identifying the package - with a sub-packages term, a classes term, and an associations term as its argument. The sub-packages term describes the sub-packages of the package; it is a list of package terms. The classes term describes the EClasses of the corresponding package. It is a list of class terms, one for each EClass of the package. Each class term consists of a functor – identifying the class - and an elements term. An elements term describes the collection of objects instantiating this class, and thus – in turn – is a list of element terms. Finally, an element term - describing such an instance – consists of a functor – again identifying the class this object belongs to – with an entity identifying the element and attributes as arguments. Each of the attributes are atomic representations of the corresponding values of the attributes of the represented object. The entity is a regular atom, unique for each element term. Similarly to the elements term, the associations terms describe the associations, i.e., the instances of the EReferences of the EClasses, for the corresponding package. Again, it is a list of association terms, with each association term consisting of a functor – identifying the association - and a relations term, describing the content of the association. The relations term is a list of relation terms, each relation term consisting of a functor – identifying the relation – and the entities of the related objects. In detail, the Prolog model term has the structure shown in Table 5.1. In the above BNF description of the term structure italic text is used for non-terminals, and courier text for terminals. The functors of the compound terms are deduced from the EMF Ecore model, which the model term is representing: • The functor of a PackageTerm corresponds to the name of the EPackage the term is an instance of.

78


ModelTerm PackageTerm PackagesTerm ClassesTerm ClassTerm ElementsTerm ElementTerm Entity Attribute AssociationsTerm AssociationTerm RelationsTerm RelationTerm

::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=

[PackageTerm (,PackageTerm )* ] Functor (PackagesTerm,ClassesTerm,AssociationsTerm) [] | [ PackageTerm (,PackageTerm)* ] [] | [ ClassTerm (,ClassTerm)* ] Functor (ElementsTerm) [] | [ ElementTerm (,ElementTerm)* ] Functor (Entity (,AttributeValue)*) Atom Atom [] | [ AssociationTerm(,AssociationTerm)*] Functor (RelationsTerm) [] | [ RelationTerm (,RelationTerm)*] Functor (Entity,Entity)

Table 5.1: The Prolog Structure of a Model Term • The functor of a ClassTerm corresponds to the name of the EClass the members of the term are an instance of. • The functor of an AssociationTerm corresponds to the name of the EReference the members of the term are an instance of. • The functor of an ElementTerm corresponds to the name of the EClass the term is an instance of. • The functor of a RelationTerm corresponds to the name of the EReference the term is an instance of. Similarly, the atoms of the attributes are deduced from the instance of the EMF Ecore model, which the model term is representing: • The Entity atom corresponds to the object identificator of an instance of an EClass • The Attribute corresponds to the attribute value of an instance of an EClass Construction Predicates In a strictly declarative rule-based approach to model-transformation, the transformation is described in terms of a predicate, relating the models before and after the transformation. Therefore, mechanisms are needed in form of predicates to deconstruct a model into its parts as well as to construct a model from its parts. As the structure of the model is defined using only compound functor terms and list terms, only two forms of predicates are needed: union and composition operations. In the following, these operators are described using the standard convention to indicate arbitrary/input/output arguments of predicates by ?/+/-.


79

List Construction The construction and deconstruction of lists is managed by means of the union predicate union/3 with template union(?Left,?Right,?All) such that union(Left,Right,All) is true if all elements of list All are either elements of Left or Right, and vice versa. Thus it can be used for joining two lists via union(+Left,+Right,-All), subtract one list from another via union(+Left,-Right,+All) or union(-Left,+Right,+All), or splitting a list via union(-Left,-Right,+All). Thus, e.g., union([1, 3,5],R,[1,2,3,4,5]) succeeds with R = [2,4]. Compound Construction Since the compound structures used to build the model instances depend on the actual structure of the EMF Ecore model, only the general schemata used can be described. Depending on whether the constructors of a package, class as well as element, or association as well as relation is described, different schemata are used. In all three schemata, however, the name of the package, class, or relation is used as the name of the predicate for the compound construction. The construction and deconstruction of packages is managed by means of package predicates of the form package/4 with template package(?Package,?Subpackages,?Classes,?Relations) where package is the name of the package corresponding to the term being constructed/deconstructed. Thus, e.g., a package named structure in the EMF Ecore model is represented by the compound constructor structure. The predicate is true if Package consists of subpackages Subpackages, classes Classes, and relations Relations. The predicate is generaly used in the form package(+Package,-Subpackages,-Classes,-Relations) to deconstruct a compound structure into its constituents, and package(-Package,+Subpackages, +Classes,+Relations) to construct a compound structure from its constituents. The construction and deconstruction of classes and elements is managed by means of class and element predicates of the form class/2 and class/N+2 where N is the number of the attributes of the corresponding class, with templates class(?Class, ?Elements) and class(?Element,?Entity,?Attribute1,...,AttributeN) where class is the name of the class corresponding to the term being constructed/deconstructed. Thus, e.g., the class named Component in the EMF Ecore model in Figure 5.3 is

80


represented by the compound constructor Component. The class predicate is true if Class is the list of Objects; it is generally used in the form class(+Class,Objects) to deconstruct a class into its list of objects, and class(-Class,+Objects) to construct a class from a list of objects. Similarly, the element predicate is true if Element is an Entity with attributes Attribute1,. . . ,AttributeN; it can be used to deconstruct an object into its element and attributes via class(+Element,-Entity,-Attribute1,...,-AttributeN), to construct an element from an entitiy and attributes (e.g. to change the attributes of an element) via class(-Element,+Entity,+Attribute1,...,AttributeN), or to construct an object including its element from the attributes via class(-Element,-Entity,+Attribute1,..., AttributeN). Thus, e.g., Component(Components,[Context,Sib,Contr]) is used to construct a class Components from a list of objects Context, Sib, and Contr. Similarly, Component(Contr,Container,"Contr","The container element") is used to construct an element Contr with entity Container, name "Contr", and comment "The container element". The construction and deconstruction of associations and relations is managed by means of association and relation predicates of the form association/2 and association/3 with templates association(?Association,?Relations) and association(?Relation,?Entity1,?Entity2) where association is the name of the association corresponding to the term being constructed/deconstructed. Thus, e.g., a relation named subComponent in the EMF Ecore model in Figure 5.3 is represented by the compound constructor subComponent. The relation predicate is true if Association is the list of Relations; it is generally used in the form association(+Association,-Relations) to deconstruct an association into its list of relations, and association(-Association,+Relations) to construct an association from a list of relations. Similarly, the relation predicate is true if Relation associates Entity1 and Entity2; it is used to deconstruct a relation into its associated entities via association(+Relation,-Entity1,-Entity2) and to construct a relation between two entities via association(-Relation,+Entity1,+Entity2). Thus, e.g., subComponent(subComps,[CtxtSib,CtxtComp,CtxtContr]) is used to construct the subcomponent association subComps from the list of relations CtxtSib, CtxtComp, and CtxtContr. Similarly, subComponent(CtxtContr,Context,Container) is used to construct relation CtxtContr with Container being the subcomponent of Context.

5.3.2

Operationalization: Architecture Transformation

5.3. Approach: Model-Based Architectural Refactoring Contr

Context Out Out

81

Out

OutDst

OutLeft

OutMid

Sib

Contr

OutRight OutMid

OutSrc

InDst

Comp

InRight

InSrc Sub

Figure 5.4: Example: Result of Pushing Down Component Comp into Container Contr The formalized structure derived from the concept model as defined in Subsection 5.3.1 is introduced to define transformations of system models as shown in Figure 5.2, in order to improve the development process by mechanized design steps. A typical transformation step is the pushing down of a component into a container component, making it a subcomponent of that container. Figure 5.4 shows the result of such a transformation pushing down component Comp of the system in Figure 5.2 into the container Contr. Besides changing the super component of Comp from Context to Contr, furthermore channel chains (e.g., InLeft, InRight) from a port of a subcomponent (e.g., Sub) of the container (e.g., InSrc) via an intermediate port of the container (e.g., InMid) to a port of Comp (e.g., InDst) have to be shortened by eliminating the first channel and the intermediate port. Symmetrically, a channel (e.g. OutLeft) from a port of the component (e.g., OutSrc) to a port (e.g., OutDst) of a sibling (e.g., Sib) of the component has to be extended by an additional channel (e.g., OutRight) and an intermediate port (e.g., OutMid). In a relational approach to the description of model transformations, such a transformation is described as a relation between the model prior to the transformation (e.g., as given in Figure 5.2) and the model after the transformation (e.g., as given in Figure 5.4). In this subsection, the basic principles of describing transformations as relations – or, more precisely, as predicates – are described as well as how rules similar to graph grammars can be used as a specific description technique. Transformations as Relations In case of the push-pull operation, the characteristic predicate of relation describing the transformation has the interface pushpull(PreModel,Comp,Contr,PostModel) with parameter PreModel for the model before the transformation, parameter PostModel for the model after the transformation, and parameters Comp and Contr for the component of the model to be pushed down and the component to contain the pushed-down component, respectively.2 In the relational approach presented here, a transformation is 2

Following the Prolog convention, capitalized arguments are variables; all other arguments are constants.

82

Chapter 5. Model-Based Architectural Refactoring Sib : Component

Context : Component

subComp

subComp

Contr : Component

subComp portComp

chanComp

Comp : Component

portComp Dst : Port

dstPort

Left : Channel name = CName comment = CCmt

srcPort

Src : Port name = PName comment = PCmt direction = output

Figure 5.5: Precondition of the Split-Merge-Transformation described by breaking down the pre-model into its constituents and building up the postmodel from those constituents using the relations from Subsection 5.3.1, potentially adding or removing elements and relations. With PreModel taken from the conceptual domain described in Figure 5.3 and packaged in a single package structure with no sub-packages, it can be decomposed in contained classes (e.g., Port and Channel ) and associations (e.g., portComp and srcPort) via structure(PreModel,PrePackages,PreClass,PreAssoc), union([PreComps,PrePorts,PreChans],RestClass,PreClass), channel(PreChans,InChans),port(PrePorts,InPorts), union([PrePortComp,PreSrcPort),RestAssoc,PreAssoc), portComp(PrePortComp,InPortComp),srcPort(PreSrcPort,InSrcPort)

with RestClass containing the terms of remaining classes (i.e., Component), and RestAssoc containing the remaining associations (i.e., subComp, chanComp, dstPort). In the same fashion, PostModel can be composed. Besides using the basic predicates to construct and deconstruct models (and add or remove elements and relations, as shown in the next subsection), new predicates can be defined to support a modular description of transformation, decomposing rules into sub-rules. E.g., in case of the pushpull predicate, the transformation can be decomposed into the reallocation of the component and the rearrangement of the channel-chains; for the latter, then a sub-rule splitmerge is introduced, as explained in the next subsection. Pattern-Like Rules To define the transformation steps for splitting and merging channels during the pushdown operation, we use a predicate splitmerge, which merges or splits a channel starting or ending at a port of the pushed-down component Comp. This predicate with interface


83

splitmerge( InPorts,InChans,InPortComp,InChanComp,InSrcPort,InDstPort, Context,Comp,Contr, OutPorts,OutChans,OutPortComp,OutChanComp,OutSrcPort,OutDstPort)

relates the Port and Channel elements as well as the PortComp, ChanComp, SrcPort, and DstPort associations of the models before and after the transformation, depending on the component Comp to be relocated, its container component Context, and the component Contr it is pushed into. The splitting/merging of a channel connected to Comp depends on whether the channel is an input or an output channel of Comp, and whether it is connected to Contr or a sibling component within Context. Therefore, in a declarative approach, we introduce four different – recursive– split/merge rules for those four cases, each with the interface described above. Furthermore, a fifth rule is added, covering the case that no channels have to be split/merged, thus ensuring the termination of the recursive rule application. To define the bodies of those rules, a pattern-like formalization, describing conditions over the models before and after the transformation step is used. These conditions are described in form of element and relation terms that must be present in these models. Figures 5.5 and 5.6 give a graphical representation of these conditions in form of object diagrams – defining the transformation rule for splitting an output channel of Comp connected to a sibling component Sib – by describing the elements and relations that must be contained in the model before and after the transformation.3 Elements and relations present in the precondition in Figure 5.5 but not in the postcondition in Figure 5.6 are removed during the transformation, elements and relations present in the postcondition but not in the precondition are added during transformation, all others are left unchanged during the transformation. Figure 5.5 states that before the transformation, Comp and Sib each have an associated port Src and Dst, connected by channel Left, owned by Context. Figure 5.6 states that after the transformation, Comp is a subcomponent of Contr. Furthermore, a port Mid of component Contr must be present with the same attributes as Src, as well as a channel Right owned by Contr, with Left connecting Mid and Dst, and Right connecting Src and Mid. To give a precise meaning to this graphical description of the transformation, the structure representation of a product model derived from the concept model as introduced in Subsection 5.3.1 is used. Figure 5.7 shows the relational rule-based formalization of this step by giving the Prolog body of the corresponding clause; underlined relations correspond to the construction predicates from Subsection 5.3.1.4 Note that this single rule combines the information of both graphical representations in Figures 5.5 and 5.6; it furthermore also describes the order in which individual split-merge steps are chained together in a modular 3

Grayed-out associations are not used in the patterns but added only for clarification. For ease of reading, functors for element relations from Figure 5.3 with capitalized identifiers like Port or Channel are written as port or channel; in the actual application, the versions ’Port’ and ’Channel’ are used. 4

84


Figure 5.6: Postcondition of the Split-Merge-Transformation fashion, which is especially important in transformations where the order of application influences the outcome. Within a graphical specification of transformations, this later step cannot by described using those object-diagram-like diagrams at all. Therefore, graphical specifications require to use additional forms of diagrams, e.g., state-transition diagrams as used in [VP04], [GGL05], or [SAL03]. Unlike those, the approach here allows to simply pass information in form of parameters from the execution of one rule to the next. Lines 1 to 7 describe the conditions before the transformation, and thus formalize the conditions described in Figure 5.5. Similarly, lines 11 to 16 describe the conditions after the transformation, thus formalizing the conditions described in Figure 5.6. Since the relational rule-based approach allows the use of recursively defined transformations, lines 8 to 10 introduce further transformation steps after removing the elements of the precondition and before introducing the elements of the postcondition. Lines 1 to 7 use a common scheme to ensure the validity of the conditions for the elements and relations taking part in the transformation: for each element and relation • its occurrence in the list of corresponding elements/relations of the pre-model is established via the union constructor • its contained entities and attributes within the pre-model are established via its corresponding functor Thus, e.g., line 5 ensures the existence of an port element SrcPort consisting of port entity Src and attributes PName, PComment, and output, while line 7 ensures the existence of a chanComp relation LeftCxt linking channel Left to component Context. The union constructor is not only used to establish the occurrence of elements and relations in the pre-model; it is furthermore used to remove the identified elements and relations from the pre-model. E.g., line 5 also removes the port element SrcPort from the port class PrePorts of the pre-model before assigning the remainder to the port class InPorts, which is used in line 8 as input parameter of the recursive application of the splitmerge relation.

5.3. Approach: Model-Based Architectural Refactoring 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

85

union([SrcComp,DistSib],InPortComp,PrePortComp), portComp(SrcComp,Src,Comp),portComp(DstSib,Dst,Sib), union([LeftSrc],InSrcPort,PreSrcPort),srcPort(LeftSrc,Left,Src), union([LeftDst],InDstPort,PreDstPort),dstPort(LeftDst,Left,Dst), union([SrcPort],InPorts,PrePorts),port(SrcPort,Src,PName,PComment,output), union([LeftChan],InChans,PreChans),channel(LeftChan,Left,CName,CComment), union([LeftCxt],InChanComp,PreChanComp),chanComp(LeftCxt,Left,Context), splitmerge(InPorts,InChans,InPortComp,InChanComp,InSrcPort,InDstPort, Context,Comp,Contr, OutPorts,OutChans,OutPortComp,OutChanComp,OutSrcPort,OutDstPort), chanComp(RightCnt,Right,Contr),union([LeftCxt,RightCnt],OutChanComp,PostChanComp), channel(RightChan,Right,CName,CComment),union([LeftChan,RightChan],OutChans,PostChans), port(MidPort,Mid,PName,PComment,output),union([SrcPort,MidPort,DstPort],OutPorts,PostPorts), dstPort(LeftMid,Left,Mid),dstPort(RightDst,Right,Dst),union([LeftMid,RightDst],OutDstPort,PostDstPort). srcPort(LeftSrc,Left,Src),srcPort(RightMid,Right,Mid),union([LeftSrc,RightMid],OutSrcPort,PostSrcPort), portComp(MidCnt,Mid,Contr),union([SrcComp,MidCnt,DstSib],OutPortComp,PostPortComp).

Figure 5.7: A Split-Merge Rule for Sibling Channels The scheme of lines 1 to 7 is used in symmetrical fashion in lines 11 to 16 to ensure the validity of the conditions for the elements and relations of the post-model. Thus, e.g., line 13 ensures that a port element MidPort, consisting of port entity Mid and attribute values defined by the variables PName and PComment, as well as the constant output of enumeration Direction, exists within port class PostPorts; similarly, line 11 ensures that a chanComp relation RightCnt, linking channel Right to component Contr, exists within compChan association PostChanComp, together with relation LeftCtx. In a purely relational interpretation of declarative transformations, the ordering of the relations used to define a rule is irrelevant. As a consequence, using that kind of interpretation, a transformation can be applied bi-directional. E.g., in case of the pushpulltransformation, the relation can be used to push-down a component into its container by assigning the pre- and post-models to the PreModel and PostModel parameter, respectively. Symmetrically it can be used to pull-up a component from a container by assigning the pre-model to the PostModel parameter and the post-model to the PreModel parameter. As however the Prolog engine interpreting the declarative transformation rules uses a sequential evaluation of the relations within a rule, the ordering becomes decisive concerning the efficiency of the application of the transformation. Figure 5.8 shows a variant form of the splitmerge relation, clarifying the effect of ordering.5 While the previous variant deals with the introduction of an additional channel connecting Comp to a sibling component Sib when pushing it down into Contr, this variant deals with the elimination of a channel connecting Comp to a subcomponent Sub of Contr. Again, lines 1 to 9 define the preconditions of the transformation, lines 13 to 18 define the postconditions, and lines 10 to 12 make use of the recursively defined splitmerge 5

For ease of reading, the anonymous variable “_” is used in the position of irrelevant attributes.

86 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18


union([SrcComp,MidContr,DstSib],InPortComp,PrePortComp),portComp(SrcComp,Src,Comp), portComp(MidContr,Mid,Contr),portComp(DstSib,Dst,Sib), union([RightSrc,LeftMid],InSrcPort,PreSrcPort),srcPort(RightSrc,Right,Src),srcPort(LeftMid,Left,Mid), union([RightMid,LeftDst],InDstPort,PreDstPort),dstPort(RightMid,Right,Mid),dstPort(LeftDst,Left,Dst), union([SrcPort,MidPort,DstPort],InPorts,PrePorts),port(SrcPort,Src,_,_,output), port(MidPort,Mid,_,_,output), union([LeftChan,RightChan],InChans,PreChans),channel(LeftChan,Left,_,_),channel(RightChan,Right,_,_), union([LeftCxt,RightCnt],InChanComp,PreChanComp),chanComp(LeftCxt,Left,Context), chanComp(RightCnt,Right,Contr), splitmerge(InPorts,InChans,InPortComp,InChanComp,InSrcPort,InDstPort, Context,Comp,Contr, OutPorts,OutChans,OutPortComp,OutChanComp,OutSrcPort,OutDstPort), union([LeftCxt],OutChanComp,PostChanComp), union([LeftChan],OutChans,PostChans), union([SrcPort],OutPorts,PostPorts), union([LeftDst],OutDstPort,PostDstPort), srcPort(LeftSrc,Left,Src),union([LeftSrc],OutSrcPort,PostSrcPort), union([SrcComp,DstSib],OutPortComp,PostPortComp).

Figure 5.8: A Split-Merge Rule for Container Channels relation. Since the two splitmerge rules are inverse transformation of each other, they can be essentially obtained by exchanging element and relation terms of the pre-models with those of the post-model, and the reordering of the clauses. Thus, e.g., the union-term of line 1 of Figure 5.7 corresponds to the union-term of line 18 of Figure 5.8 as well as the union-term of line 16 of the former corresponds to the union-term of line 1 of the latter, when swapping InPortComp and PrePortComp with OutPortComp and PostPortComp, resp. Similarly, the chanComp-functor terms in Figure 5.7 of lines 7 and 11 correspond to the chanComp-functor terms in Figure 5.8 of lines 13 and 9. Basically, by swapping the characterization of the pre- and post-models, inverting the sequence of predicates, an efficient version of splitmerge for the introduction of a channel is turned into an efficient version for the elimination of a channel. The reordering is based on the general principle to let predicates with more bound arguments precede predicates with less bound arguments. While some aspects of ordering are essential to obtain a feasible execution – especially putting the characterization of the pre-model before the recursive call and the characterization of the post-model after it – other reorderings – especially of predicates with no shared variables – have no or little effect on the usability of the execution.

5.4

Application: Refactoring Execution

Section 5.3 introduced a structural formalization for concept product models and demonstrated how pattern-like declarative transformation rules can be constructed using this

5.4. Application: Refactoring Execution

87

structure. Using this formalization, refactoring execution is simply achieved by rephrasing refactoring steps as transformations and applying them – combined with suitable parameters – to the model under development. Subsection 5.4.1 shows how, based on this formalization, transformations like architectural refactoring can be mechanized using Prolog-interpretation. Subsection 5.4.2 demonstrates how it is embedded in a phase-oriented process, supporting phase-specific operations, e.g., architectural refactoring during architecture construction.

5.4.1

Implementation: Transformation Automation

The presented approach as been implemented as an Eclipse plugin [CR06] using the tuProlog engine [DOR05]. While currently intended for the transformation of AutoFocus models, due to its generic nature it supports the transformation of EMF Ecore [SBPM07] models in general. The implemented plug-in provides tool support both for the definition of transformation and the transformation execution, as illustrated in the following subsection. Transformation Definition From the point of view of the designer of the transformation, the description of a transformation consists of • the declaration of the Prolog clauses forming the rules of the transformation relation • the declaration of the root clause of the rule set • the list of parameters of the head clause including their type (i.e., input model, output model, Boolean, Integer, String, or model entity) provided in form of an XML file. Since transformations depend on the structure of the model before and after the transformation, and transformations are intended to be designed at run-time of the AutoFocus framework, the designer of the model is provided with information on the structure of the domain concept model at runtime. As shown in the left-hand side of Figure 5.9, for that purpose, a model structure browser describing the term structure is provided as part of the online help documentation, based on the EMF Ecore reflection mechanism. By providing the term structure rather than the ECore structure, the declaration of the transformation rules is simplified. E.g., as shown in Figure 5.9, the structure package term can be broken up into lists of subpackage, class, and association terms using the functor structure; similarly, the channel element term can be broken up into the attributes name and comment using the functor Channel. Transformation Execution

88


Figure 5.9: Support for Defining and Applying Model Transformations The transformation is provided in form of a transformation wizard, available for AutoFocus models and basically guiding the user through the three transformation steps 1. Selecting the transformation declaration 2. Defining the parameters of the transformation 3. Declaring the result model plus an optional debug step. In the first step, the file containing the transformation description is selected. In the second step, as shown in the right-hand side of Figure 5.9, the parameters of the transformation rule – without the pre- and post model parameter – are defined. In the case of the push-pull transformation, suitable component entities must be assigned to the parameters Comp and Container for the component to be pushed down and the container component. To define entity parameters, a model browser is provided to select suitable elements from the pre-model. After declaring, i.e., naming and locating, a model to contain the result of the transformation in the third step, the transformation can be executed. Optionally, the execution can be traced in a fourth step for debugging purposes.

5.4.2

Method: Refactoring Application

Transformations are provided in a development process to provided standardized operations to construct the product under development. Obviously, those operations generally are only applicable at certain stages of the development process. Thus, by assigning those operations to certain phases of development, a structured construction of the product is ensured, help to avoid unwanted orders of operations. By using only a set of operations

5.4. Application: Refactoring Execution

89

Figure 5.10: Definition of Activities specific to a phase, e.g., conformance constraints ensured an the entry to that phase are avoided to be invalidated. Thus, by combining conformance constraints and well-defined transformations like refactoring steps into a guided process, development efficiency can be improved. Similar to conformance constraints in Section 4.4, application of refactoring consists, on the one hand, of supplying suitable phases and activities; on the other hand, in executing those activities. Both aspects are described in the following. Refactoring Introduction A refactoring operation for a phase essentially is a transformation description consisting of its Prolog-clauses, the declaration of the root clause and the list of its parameter, as mentioned above. Just like in the case of conformance conditions, however, additionally a descriptive name and an informal description are added. The former is required to assign an operation to a phase and to identify it during selection; the latter is added to provide a rational how this operation is useful or which defects it is intended to remedy for a product model not respecting a conformance condition. Figure 5.10 shows the dialog for adding activities to a phase, providing groups of activities, to improve presentation of during the application of a phase.

90


Refactoring Selection Once a process has been defined together with suitable refactoring steps, it can be applied to the development of a product by executing the process and applying suitable refactorings. Application of refactorings may be especially triggered by violations of conformance constraints. E.g., switching from the architectural design phase to component implementation may impose maintainability constraints like limiting the maximum number of subcomponents of a component. The violation of this constraint suggest to uses hierarchy refactoring to countermeasure this deficiency. By providing this refactoring step for the design phase, the construction of a maintainable architecture is supported.

5.5

Conclusion: Architectural Refactoring

In this chapter, the use of a domain concept model to support the synthesis of new product models – by transformation from existing instances – has been illustrated taking architectural improvement by refactoring as application context. By providing a language capable of expressing relations between those instances, transformations can be defined to specify those refactoring steps.

5.5.1

Summary: Architectural Refactoring

The approach presented in this chapter supports the use of refactoring steps in a guided model-based development process. To that end, the approach exploits the fact that the concept domain model allows to interpret a concept product model as its instance, and – by providing a vocabulary capable of defining properties of such an instance – allows to formalize transformations as relations between models. By adding a mechanism to automatically apply such relations to a product model, architectural refactorings can be implemented by formalizing them using that vocabulary and using this mechanism for their application. Thus the mechanism allows a simple, precise, and modular specification of transformation relations on the problem- rather than the implementation-level. As shown in the context of architectural refactorings of logical architectures of embedded software, this form of modular specifications does not only provide a mechanism to to define the needed transformations in an abstractr and modular fashion. Furthermore, by taking the operational aspects into consideration, the purely relational declarative form of specification can be tuned to ensure an efficient execution, making it practically feasible for real-world sized models (e.g, refactoring models consisting of more than 3000 elements and more than 5000 relations within a few seconds). Finally, by embedding this mechanism into a phase-oriented development, the concept model allows to support a guided process efficiently providing transformations throughout the development.

5.5. Conclusion: Architectural Refactoring

91

Obviously, the rule-based approach allows very general forms of application. Therefore, suitable extensions of the approach are other forms of application (e.g., view generation, transformations involving user interactions) as well as stronger applications of the backtracking mechanism to explore alternative transformation results, using guiding metrics to find optimized solutions like, e.g., balanced component hierarchies during architectural design.

5.5.2

Related Work: Architecture Transformation

In contrast to other development environment like the Eclipse Refactoring plug-in, providing a fixed set of refactoring rules, the generic mechanism introduced here allows the tool-user to enhance the functionality of the tool by defining domain-specific refactoring rules. The transformation framework of AutoFocus is used to describe graph transformations, using a relational calculus focused on basic constructs to manipulate nodes (elements) and edges (relations) of a concept model. This generic approach is also used in other graph-based frameworks like MOFLON/TGG [KKS07], Viatra [VP04], FuJaBa [GGL05], DiaGen [Min01], or GME [SAL03]. However, in contrast to those, the mechanism here not based on graph-grammars or graphical, rulebased descriptions [Roz97], but uses a textual description based on a relational, declarative calculus. As shown in Subsection 5.3.2, for the declaration of basic transformations the rulebased approach allows the definition of such transformations in a pre-model/post-model style of description similar to graph-patterns, both concerning complexity and readability of description. However, in contrast to those approaches, the approach introduced here uses only a single formalism to describe basic transformations as well as their compositions; thus, its avoids the problems of using different formalisms to describe transformation patterns, like object diagrams, OCL expressions, and state machines. Similarly, this relational rule-based approach makes the order of application and interaction of basic transformations explicit, avoiding the imprecision resulting from the underspecification of these dependencies. Considering the textual form of description, the transformation framework is similar to the QVT approach [OMG03] and its respective implementations like ATLAS [JAB+ 06], FLogics based transformation [GLR+ 02], or TefKat [LS06]. However, in contrast to those it comes with a precise and straightforward definition of models and transformations. This definition is directly reflected in the description of models and transformations: There is only a single homogenous formalism with two simple construction/deconstruction operators to describe the basic transformation rules and their composition. Complex analysis or transformation steps can be easily modularized since there are no side-effects or incremental changes during the transformation. Furthermore, the rule-based relational approach allows to arbitrarily mix more declarative and imperative forms of specification, which are strictly separated in those other approaches. Thus, e.g., it allows to construct an initial description of a specification in a purely declarative fashion, and to successively rephrase it into a more imperative and efficient form.

92


Another advantage of the presented approach is its capability to interpret loose characterizations of the resulting model, supporting the exploration of a set of possible solutions. By making use of the back-tracking mechanism provided by Prolog, alternative transformation results can not only be applied to automatically search for an optimized solution, e.g., balanced component hierarchies, using guiding metrics; the set of possibile solutions can also be incrementally generated to allow the user to interactively identify and select the appropriate solution. Finally, the approach presented here addresses a different form of application: While most of the above approaches intend to support the transformation from one modeling domain to another (e.g., from class diagrams to DB schemata), here the goal is rather to provide simple implementations for refactorings of models (e.g., combining a cluster of components).

Chapter 6 Content Model The notion of Concept Models introduced in Chapter 2 provides the concepts forming the vocabulary of models. This class of ‘syntactic’ models allows to build models, analyze their well-formedness, and transform those models into other models. However, this class does not allow to describe the intended interpretation of models. For that purpose, in the following the notion of a Content Model is introduced, which allows to capture the contents of those models, describing their meaning. In the domain of reactive systems, this content, e.g., consists of observations about the sending and receiving of messages or the activation and deactivation of functionality, about the executions of functions, and finally about the complete behavior of systems. It is used to interpret the descriptions of the problems and solutions constructed with the vocabulary of the concept model, in terms of observations about the system under development.

6.1

Introduction: Content Model

The content model of a product provides an interpretation of the concept model of a product by mapping the description of a product to its meaning, e.g., by mapping the static aspects of its functionality – like the description of its signal interface – to the dynamic aspects – like its observations about exchanged signals. Thus, when constructing a domain model, after defining is conceptual aspects, the interpretations must be characterized that can be associated with these aspects. Therefore, a content domain model provides the ‘semantics’ of the conceptual domain model. Besides providing an interpretation – generally in characterizing all possible observations – of the system under development, the content domain model also allows to analyze the validity of the observations about the product model, as well as to synthesize observations about it. In this chapter, the principles of building such models are illustrated and the resulting benefits of providing such models are discussed. 93

94

Chapter 6. Content Model

6.1.1

Contributions: Modular Functionality

As described in Chapter 2, concerning the conceptual description of a system under development, the complexity of such a system is handled by providing different views – horizontally as well as vertically – to provide a (de)composed description of the system. Since the content model is intended to provide an interpretation of such a (de)composed description, it must be defined in a modular fashion to allow integrating the content of each part of the description into its overall interpretation. As a result, the content model supports the development process of multi-functional systems by use of modular composition of functions. To illustrate the principle, in the following the context of reactive systems is used. Therefore, this chapter, besides discussing the basic characteristics of content models, • introduces functions as modular units of system construction, which provide a data flow interface describing the values observed and controlled by a function as well as a control interface describing the activation and deactivation of functions. • provides disjunctive and conjunctive composition as a means of combination, which allow to either alternatively or simultaneously combine functional behavior.

6.1.2

Overview: Content Model

In the remainder of this chapter, the principles of a content model for the definition of the behavior of a system is introduced, using the class of reactive systems for demonstration. Section 6.2 introduces basic concepts that are needed to compositionally construct the behavior, demonstrating these principles within the domain of reactive systems and formalizes them in a modular fashion. By providing concepts for data flow as well as control flow, this approach covers the interaction between components via message-exchange as well as the interaction between tasks by passing activation. Section 6.3 discusses the benefits that can be achieved by providing an interpretation of the specification of a system, both indirectly by providing a precise interpretation of conceptual descriptions as well as directly by mechanizing analysis and synthesis techniques for these interpretations.

6.2

Characteristics: Modular Composition

In this section, a content model for the modular composition of behavior is introduced, using functions as building blocks for the construction of reactive functionality. Since functions provide a specific content model, they are first informally introduced in terms of the generally needed constituents of a modular content model to demonstrate the characteristics of a content model. Based on that informal introduction, then a formal and compositional definition of functions is given.

6.2. Characteristics: Modular Composition

6.2.1

95

Notions: Behavior Composition

As mentioned above, to provide a modular interpretation of behavior, some basic notions must be provided by a content domain model. Similar to Chapter 2, where the base concept model characterizes the general structure of an instantiating concept domain model, here the general structure of a content domain model is prescribed by the base content model. In order to define a content model, several basic concepts are needed, as defined by the base model : Interface: An interface separates a system from its environment, allowing to hide internal information and thus modularizing a system. Observation: An observation describes a piece of behavior observable at the interface of a system, thus allowing to describe behavior abstracted from aspects hidden inside the interface. Behavior: The behavior defines the collection of all possible observations of a system, thus allowing to define the construction of complex behavior by combining the respective observations. Furthermore, besides providing those basic concepts, a content model must support mechanisms for its modular construction: Composition: By means of composition, sub-parts of a system are combined into the overall system, thus allowing to decompose a complex system into simpler parts. Since behavior is defined as collection of observations, standard compositions can be provided by conjunction and disjunction of behavior. Abstraction: Abstraction restricts an interface of a system, allowing to render parts of a system invisible to its environment. Since behavior is defined in terms of observation, abstraction can be achieved by projection. Finally, it must be possible to compare content models of different products: Ordering: By means of ordering, the behaviors of systems can be compared and related, making, e.g., one behavior a generalization of the other. Based on the interpretation of behavior via collections of observation, here set-induced orders can be used. These notions are introduced in the following, using the concept of a function as the core notion to instantiate the base model with a content domain model to describe the behavior of reactive systems: Interface: The interface of a function consists of a data flow and a control flow part; the former defines how data can be exchanged between a function and its environment by sharing signals between them using input and output variables, while the latter defines how control can be exchanged between them by activating and terminating a function using entry and exit locations.

96


Observation: An observation about a function consists of the activation of the function, the performed data exchange and its termination. Behavior: In the context of functions, it consists of the set of all observations of a function. Composition: For functions, disjunctive and conjunctive composition is provided; the former defines sequential executions of functions by handing over activation, while the latter defines parallel execution of functions by exchanging signals. Abstraction: In the context of functions, it consists of variable hiding and location hiding; the former defines how variables are removed from the interface turning external signals into internal ones, while the latter defines how locations are removed retaining activity inside a function. Ordering: For functions, refinement is provided; one system refining another corresponds to the behavior of the former being a sub-collection of the behavior of the latter. Furthermore, while not strictly necessary, for reasons of convenience the renaming of variables and locations is added. Besides these notions provided by a content model for (reactive) systems, a general content model must also support the concept of partiality. Since a content model for the description of a product must cover all phases of the development process, it must also specifically support the formalization of partial descriptions to cover, e.g., the requirements phase. Therefore, in contrast to approaches like [LT89], [Hen00], or [SS03] imposing a completely specified behavior defining a behavior of the system for each behavior of the environment, (via input enabledness, input permissiveness, or input completeness), a function needs not to be totally defined. For a partial specification, it is possible to have a behavior of the environment where no behavior of the function is defined by the specification. To define a formal framework for the construction of functions, in the following subsection a basic model is introduced and operators for the construction of complex functions from basic ones are supplied.

6.2.2

Formalization: Modular Behavior

Since functions are intended for the modular specification of components with input complete behavior, as semantical basis in the following we use a formalization similar to [Hen00] to introduce a set F un of functional descriptions as well as its interpretation. However in contrast to the former, more component-oriented approach, here a more general, functionoriented approach is introduced, supporting the description of functions with their partially defined behavior, especially allowing the introduction of new partiality by simultaneous combination as defined in the following. The distinction between completely defined component behavior and only partially defined function behavior plays an important role when combining components or functions, as


97

ctrl

ctrl Diagnosis Management Dia?Vt:Req!Vt,Sts!OK

Error Store Req?Vt:Res!OK Err

Req?Rs: Res!OK

Err?LV: Res!No

empty

Req

Req?No:Res!No

Req?Rs: Res!OK

Req?Vt:Res!Ft

Dia

full

Res?OK:

busy

Req

Req!No,Sts!OK Res

Res?Ft: Res

Req?No:Res!No

Dia?No: Req!No,Sts!No

idle

Res?No: Req!No,Sts!No Dia?Rs:Req!Rs,Sts!OK Req!No,Sts!Ft

Sts

Figure 6.1: Description of the Error Store and Diagnosis Management Functions discussed in more detail in Chapter 7. Generally, syntactic restrictions (e.g., disjointness of output interfaces or data states of composed components), ensure that the composition of components results in a component (with input total behavior); e.g., [Hen00] uses such a restriction. Due to their more general nature, such a restriction is not required for functions [SS03]. However, as a result, the combinations of functions (e.g., manual window control, position control) may lead to conflicts (e.g., upward movement of the window by manual control vs. stop of movement by position control) resulting in undefined behavior. To illustrate the approach, the example of an Error Diagnosis functionality is used. It consists of an Error Store functionality, shown in the left-hand side of Figure 6.1, storing possible error signals received via Err, and – upon receiving a request from the environment via Req to provide or reset the stored value – returning a corresponding result signal via Res. This functionality is activated and terminated via the ctrl location. Furthermore, Error Diagnosis consists of a Diagnose Management functionality, receiving diagnose commands from the environment via Dia and forwarding them via Req, then waiting for the result via Res and forwarding it back to the environment via Sts; as before, this functionality is activated and terminated via a ctrl location. Basics The structural aspects of a function are defined by its variables Var – used to transfer signal values between the function and its environment – as well as its control locations Loc – used to transfer execution control between the function and its environment. To describe the behavior of a function, the following concepts are used: −−→ State: A state s ∈ Var = Var → Val maps variables to their current values. Observation: An observation is either a triple (a, t, b) consisting of a finite sequence t of states corresponding to an execution starting at location a and ending at location b, changing variables according to t; or it is a pair (a, t) consisting of a finite sequence t of states, corresponding to a partial execution, starting at location a. Since in the

98

Chapter 6. Content Model Set-Reset

Reset

Err?LV:

Err

Req?Rs Res!OK

Req

Res!No

Req

full

empty

Res

Req?Rs:

Res

Res!OK

empty

full

Figure 6.2: Basic Functionality Reset and Combined Functionality Set-Reset following only continuous functions are introduced, a restriction to finite observations is sufficient. Behavior: The behavior of a function is the set Obs of all its observations. Consequently, Obs is prefix-closed, i.e., (a, t, b) ∈ Obs implies (a, t) ∈ Obs, and (a, t) ∈ Obs implies (a, s) ∈ Obs for any prefix s of t.

For a state s : V ar → V al with V ar� ⊆ V ar we use the notation s©V ar� for restrictions (s©V ar� )(v) = s(v) for all v ∈ V ar� . This restriction is extended to sequences of states through point-wise application. For sequences r and t we use the notation r ◦ t to describe the concatenation of r and t; furthermore, �� describes the empty sequence. Basic Functions The most basic function performs one step of computation. When entered through its entry location, it reads the values of its variables; depending on this variable state, it then changes the variable state by writing new values and terminates by exiting via its exit location. To describe a basic function, we use the notation introduced in [HSE97b]. The left-hand side of Figure 6.2 shows such a basic function Reset with variables Req and Res, and locations full and empty. Its behavior is described by a labeled transition from full to empty with a label consisting of Req?Rs and Res!OK. The first part of the label states that whenever the reset signal Rs is received via the request variable Req, then the transition is enabled. The second part of the label states that, whenever the transition is triggered, in the next state the OK-signal OK is sent via the result variable Res. These parts use a short-hand notation for reading pre-transition values and writing post-transition values. They correspond to terms `Req = Rs and Res´ = OK using variables `v with v ∈ V ar for values of v prior to execution of the transition, and variables v´with v ∈ V ar for values of v after its execution. The interface of Reset is defined by its variables V ar = {Req, Res}, and its locations Loc = {empty, full}. As shown in Figure 6.2, the data flow interface of a function is indicated by


99 Error Diagnosis

Store Management Err

Err

Error Store

Res

Err

Req

ctrl ctrl Dia

Dia

Res

Err

ctrl

ctrl

Res

Diagnosis Management Sts

Sts

Dia

Dia

Res Req

ctrl Req

Req

Error Store

Req

Res

Diagnosis Management Sts

Sts

ctrl

Figure 6.3: Open Store Management and Encapsulated Error Diagnosis Functions boxes connected to the function, while the control flow interface is described by circles connected to it. The transition itself is described by an arrow linking the corresponding control locations. Abstracting from a concrete graphical representation, a basic function is described as the structure (a, l, b) with entry location a, exit location b, and transition label l over a pair −−→ −−→ of state Var × Var . l corresponds to the conjunction of the pre- and the post-part of the label, with variables from `Var being interpreted over the first argument, and Var´ being interpreted over the second argument. Its behavior is the set of observations containing all elements • (a, before ◦ after , b) • (a, before ◦ after ) • (a, before) • (a, ��)

with l(before, after ). Consequently, the behavior of Reset is the set consisting of all observations (full, before ◦ after , empty), (full, before ◦ after ), (full, before), and (full, ��), such that full (Req) = Rs as well as after (Res) = OK. Alternative Combination Similar, e.g., to the Or -combination used in Statecharts [HP98], we use alternative combination to describe sequential behavior. The behavior of an alternative combination of two functions corresponds to the behavior of either function. Function Error Store in the left-hand side of Figure 6.2 shows the alternative combination of functions Reset and Set. It shares all the structural aspects of either function, and thus uses variables Err and Req, as well as Res. Furthermore, by means of the common interface locations empty and full, either Reset or Set can be activated and deactivated. Formally, the alternative combination of two functions A and B results in a function described by A + B that • uses the variables of either function: Var A+B = Var A ∪ Var B

100

Chapter 6. Content Model • accesses their combined control locations: LocA+B = LocA ∪ LocB

• exhibits the behavior of either function: (a, t, b) ∈ Obs A+B if (a, t©Var A , b) ∈ Obs A or (a, t©Var B , b) ∈ Obs B ; (a, t) ∈ Obs A+B if (a, t©Var A ) ∈ Obs A or (a, t©Var B ) ∈ Obs B Intuitively, the combined function offers observations that are offered by one of its subfunctions. If the sub-functions share a common entry location, observations of either function starting at that entry location are possible; similarly, if they share a common exit location, also observations ending at that common exit location are possible. Obviously, functions A + B and B + A are equivalent in the sense of having the same interface and behavior . By adding more functionality via alternative combination, function Set-Reset can be extended to function Error Store. Similarly, the complete functionality of function Diagnosis Management can be constructed. Simultaneous Combination Besides alternative combination, functions can be combined using simultaneous combination. The behavior of a simultaneous combination of two functions corresponds to the joint behavior of both functions, similar to an And -composition in Statecharts. Function Store Management in the left-hand side of Figure 6.3 shows the simultaneous combination of functions Error Store and Diagnosis Management. Its interface consists of variables Err of Error Store and Dia as well as Sts of Diagnosis Management, and furthermore variables Req and Res of both sub-functions; its set of locations Loc = {ctrl} consists of the shared location ctrl of these functions. Formally, the simultaneous combination of two functions A and B results in a function described by A × B that • use the variables of either function: V arA×B = V arA ∪ V arB

• accesses their shared control locations: LocA×B = LocA ∩ LocB

• exhibits the combined behavior of each function: (a, t, b) ∈ Obs A×B if (a, t©V arA , b) ∈ Obs A and (a, t©V arB , b) ∈ Obs B ; (a, t) ∈ Obs(A × B) if (a, t©V arA ) ∈ Obs A and (a, t©V arB ) ∈ Obs B

Intuitively, the combined functions offers observations that can be offered by both functions. Obviously, A × B and B × A are equivalent in the sense of exhibiting the same interface and behavior. Hiding Locations Hiding a location of a function renders the location inaccessible from the outside. As a consequence, when reaching a hidden location, the function does immediately continue its execution along an enabled transition linked to the hidden location. In Function Error Store


101

in the left-hand side of Figure 6.1, control location full is hidden to enable immediate reset of the error store. Formally, hiding a location l from a function A results in a function described by A\l that • uses the variables of A: V arA\l = V arA • accesses the control locations of A excluding l: LocA\l = LocA \{l}

• exhibits the behavior of A if entered/exited through locations excluding l and continuing execution at l: (a, t1 ◦ s1 . . . sn−1 ◦ tn , b) ∈ Obs A\l for a �= l �= b if (a, t1 ◦ s1 , l), (l, sn−1 ◦ tn , b) ∈ Obs A as well as (l, si−1 ◦ ti ◦ si , l) ∈ Obs A for i = 2, . . . , n − 1, tj ∈ S ∗ , and sj ∈ S; similarly, (a, t1 ◦ t2 ◦ . . .) ∈ Obs A\l for a �= l if (a, t1 , l)) ∈ Obs A and (l, ti , l) ∈ Obs A for i > 1. Finally, (a, t, b) ∈ Obs A\l for a �= l �= b if (a, t, b)Obs A and (a, t) ∈ Obs A\l for a �= l if (a, t)Obs A .

Obviously, (S\a)\b) and (S\b)\a) are equivalent in the sense of exhibiting the same interface and behavior. We write A\{a, b} for (A\a)\b. Renaming Locations

Renaming a location of a function changes the interface of the function, possibly unifying control locations. As, e.g., shown in Figure 6.1, the distinct control locations corresponding to the empty and idle locations of either function are renamed to the unique control location ctrl, to couple the functionality during simultaneous composition. Formally, renaming a location l in a function A to location m results in a function described by A[l/m] that • uses the variables of A: V arA[l/m] = V arA • accesses the control locations of A excluding l and including m: LocA[l/m] = LocA \{l}∪ {m} • exhibits the behavior of A after renaming: for a �= l �= b, (a, t, b) ∈ Obs A[l/m] if (a, t, b) ∈ Obs A as well as (a, t) ∈ Obs A[l/m] if (a, t) ∈ Obs A . Furthermore for a �= l �= b, (a, t, m) ∈ Obs A[l/m] if (a, t, l) ∈ Obs A and (m, t, b) ∈ Obs A[l/m] if (l, t, b) ∈ Obs A , (m, t, m) ∈ Obs A[l/m] if (l, t, l) ∈ Obs A , and finally (m, t) ∈ Obs A[l/m] if (l, t) ∈ Obs A . Hiding Variables Hiding a variable of a function renders the variable unaccessible from the outside. As shown in the right-hand side of Figure 6.3, the open function Store Management is encapsulated resulting in function Error Diagnosis by hiding the internal variables Req and Res. Formally, by hiding a variable v from a function A we obtain a function described by A\v that • uses the variables of A excluding v: V arA\v = V arA \{v} • accesses the control locations of A: LocA\v = LocA

102

Chapter 6. Content Model • exhibits the behavior of A for arbitrary v: (a, t©V arA , b) ∈ Obs A\v if (a, t, b) ∈ Obs A ; (a, t©V arA ) ∈ Obs A\l if (a, t) ∈ Obs A .

Obviously, (S\v)\w) and (S\w)\v) are equivalent in the sense of exhibiting the same interface and behavior. We write A\{v, w} for (A\v)\w. Renaming Variables

Renaming a variable of a function changes the interface of the function by changing the name of a signal variable. Here, renaming is restricted to a new name not already contained in the variables of function A. Formally, by renaming a variable v from a function A to w we obtain a function described by A[v/w] that • uses the variables of A excluding v and including w: V arA[v/w] = V arA \{v} ∪ {w} • accesses the control locations of A: LocA\v = LocA

• exhibits the behavior of A , substituting w for v: (a, s, b) ∈ Obs A\v if (a, t, b) ∈ Obs A and (a, s) ∈ Obs A\l if (a, t) ∈ Obs A where s©VarA \v = t©VarA \v and s©{w} = t©{v}.

6.3

Benefits: Content Model

The concept domain model discussed in Chapter 2 provides the – generally domain-specific – conceptual elements needed to describe the product under development, thus allowing to explicitly construct a syntactic model of the product using graphical or textual notations. In contrast to the concept model, the content domain model discussed in this chapter provides the – generally domain-independent – content elements needed to interpret the constructed product unter development, thus allowing to implicitly construct a semantic model of the product using logical formalisms. In short, in contrast to the concept model providing a formalized description of the product model, the content model provides a formalized interpretation of the product model. Subsection 6.3.1 characterizes the advantages provided by this formalized interpretation via the content model, while subsection 6.3.2 discusses how this formalization can be applied.

6.3.1

Principles of Contribution: Model Interpretation

The content model of a system provides the ‘semantical’ interpretation for the ‘syntactical’ representation of the corresponding concept model. However, for a useful interpretation of the concept model through the content model, the latter must integrate all the different elements of the former; to that end, a concise interpretation using only few but precise concepts is needed. Furthermore, the content model must mirror the view-based deconstruction of a description through the concept model by a corresponding modular interpretation.

6.3. Benefits: Content Model

103

Conciseness of Description In contrast to the concept model, which generally offers a rich selection of specialized views of the system – like using state-transition diagrams as well as sequence diagrams in AutoFocus [Wil06] to describe its behavior – and thus allows to describe systems directly using a rather domain-specific vocabulary, the content model generally uses rather elementary constituents, leading to reduced specificity but increased brevity of the model due to the smaller number of modeling elements. Furthermore, by providing only a rather small number of constituents, the different views used on the conceptual level are mapped to a common content model of the product, thus allowing to integrate these views. Reducing the description of a system to few elementary constituents allows to focus the interpretation, thus improving the clarity of the interpretation of the description. Together, by ensuring both clarity and brevity, overall the conciseness of a description of the system is ensured. Modularity of Construction A concept domain model provides the possibility to cope with the complexity of a system by breaking up the overall description into different, generally interdependent views, as discussed in Subsection 2.3.1. The content domain model, in turn, provides the possibility to map this modularized description to a single interpretation, integrating these different views. However, in order to allow an effective construction of such an interpretation, the construction of such an interpretation must respect the two main principles needed in a view-based description of a system: composition, i.e., the construction of a complex view by combination of sub-views, and abstraction, i.e., the hiding of this internal complexity. Since hierarchy – as used in the construction of vertical views of a system – is one of the prominent structuring mechanisms of the content model, the interpretation provided by the content model must deal with this mechanism. By providing modularity of construction, the content domain model allows to compositionally define an interpretation of a concept domain model, thus providing a generic scheme for the construction of an explicit content model of the product under development from the concept model of this product.

6.3.2

Principles of Application: Model Interpretation

As mentioned in Subsection 6.3.1, the content model of a product provides the means to integrate the description of a product given by its multi-view concept model. This is achieved by mapping descriptions constructed from the different notations provided by the concept model onto a common content model. While formalizing the concept model leads to a precise understanding of the content of a concept product model, it furthermore allows to establish relations between different conceptual descriptions on the

104


content level, enabling to analyse the product model. Furthermore, from the content model of the product model – or sub-models thereof with specific properties – descriptions on the conceptual level can be synthesized. Formalization The purpose of the content domain model is to provide an interpretation for the concept domain model, as well as their instances. To apply it, therefore a translation of the different description formalisms represented by the concept model – e.g., sequence diagrams, state diagrams – into the concise framework of the content model must be provided. This translation thus provides a formalization of the content of a concept product model, achieving a precise understanding of it. This form of application provides the basis for the analysis and synthesis mentioned in the following. Since, however, the translation is rarely ever used in itself – except to clarify and describe the semantics of a syntactical notation, e.g., to define its standard interpretation – but generally as means to perform analysis and synthesis, is not covered by an own chapter, but included in the Chapters 7 and 8. Analysis As mentioned in Subsection 6.2.1, the content model characterizes the behavior of a system by describing the collection of all its possible observations. It therefore allows to compare behaviors of systems by comparing their respective collections of behaviors. For the same reason, it allows to verify whether a system exhibits a specific behavior by checking whether the collection representing its behavior includes certain observations. These possibilities can be applied in the development process to analyse the validity of certain soundness-conditions imposed on the models under development. Thus, between different descriptions of the product under development an implementation relation can be established to ensure that a more concrete model refines a more abstract one. Furthermore, a single description can be checked to satisfy important standard properties like nondeterminisms or completeness. Chapter 7 shows how to apply this principle to the completeness and refinement checks of modular descriptions of functionalities. There, the precise characterization of the concepts of completeness and refinement, provided by the conciseness of the content model, allows an automatic check of these concepts based on the modular composition of behavior. Synthesis The analysis of the behavior of a system use the property of the content model to explicate the implicit interpretation of the concept model: the interpretation allows to construct an

6.4. Conclusion: Content Model

105

– potentially partial – explicit representation of the observations about the behavior of the specified system. This same principle can, however, also be applied in the development process to synthesize a specific behavior. By only implicitly characterizing the intended system, the same mechanism for the construction of an explicit representation can be used, instantiating a behavior by selecting suitable observations respecting the characterization. Chapter 8 shows how to apply this principle to the generation of test cases. There, the modular composition of a behavioral specification supplied by the content model allows to construct a concise (implicit) characterization of the intended test case, which can then be mechanically explicated in a concrete test case instance.

6.4

Conclusion: Content Model

In this chapter, the notion of a content model is introduced to formalize the interpretation of representations of a system given in form of a concept model. To demonstrate an actual formalization of a domain content model, an instantiation of the base content model in form of composable functions is provided, supporting the modular description of functionality in the domain of reactive systems.

6.4.1

Summary: Content Model

The approach presented in this chapter suggests content models as formalization for the definition of interpretations of system descriptions, with interface, observation, and behavior as the core concepts, and composition and abstraction as the core mechanism of composition, as well as an ordering of specifications. The approach is illustrated within the domain of reactive systems, introducing functions as construction units, with transitions as the most basic form, as well as disjunctive and conjunctive composition as well as hiding and renaming to combine subfunctions to more complex functions. Functions offer a means to precisely describe pieces of behavior as modular units of system construction, providing a data flow interface – describing the values observed and controlled by a function – for the communication with the environment as well as a control flow interface – describing the activation and deactivation of functions – for the synchronization with the environment. Finally, a refinement relation is provided to order functions according an implementation relation.

6.4.2

Related Work: Modular Behavioral Descriptions

Functions are modules of behavior, used for the construction of complex behavior from basic functionality. They offer interfaces for both data and control flow in a similar fashion to the ports and connectors introduced in [HSE97b].

106


As generally used, e.g., in embedded systems, functions are intended for the description of signal-based reactive systems, using asynchronous communication unlike [Hoa83] or [Mil83]. They use a communication paradigm similar to [LT89], [LL98], [Hen00], or [Hei02]. Therefore, they provide similar forms of conjunctive and disjunctive compositions as provided for the modules introduced in [Hen00] or the states introduced in [HP98]. However, while those are targeting the specification of reactive behavior in a constructive fashion, here a more descriptive form is used, using a more generalized form of (conjunctive) composition. In contrast to these constructive approaches, ruling out the introduction of partial behavior either syntactically by restricting compatible alphabets (e.g., [Hen00]) or semantically using interleaving of interactions instead of synchronization (e.g., [HP98], functions with their less restricted composition allow a more natural modular form of specification. Due to this form of composition, they are similar to service-oriented descriptions as used in [BKM07] or [SS03]. In contrast to those rather descriptive approaches with a large number of different composition operators, however, functions provide a more constructive form of decomposition. Similar to [Lam02], only conjunction and disjunction are used and a similar semantical models is used; but while there – due to its rather general form of specification without distinction between control and data flow – a more low-level formal form of description is needed, here by means of the explicit introduction ports and locations a more compact form of specification is possible.

Chapter 7 Model-Based Function Composition The construction of reactive systems often requires the combination of different individual functionalities, thus leading to a complex overall behavior. To achieve an efficient construction of reliable systems, a structured approach to the definition of the behavior is needed. Here, functional modularization supports a separation of the overall functionality into individual functions as well as their combination to construct the intended behavior, by using functional modules as basic paradigm together with conjunctive and disjunctive modular composition. Combined with a notion of refinement and including the treatment of partiality, both supported by automatic proof mechanisms, a methodical construction of complex reactive behavior is achieved.

7.1

Introduction: Function Composition

The increased technical possibilities of computing systems has lead to an increased demand of functionalities provided by those systems. In turn, the increasing number of functionalities and especially the increased degree of interaction between them has lead to a huge growth in the complexity of their (reactive) behavior. This complexity complicates the specification of the functionality of a system especially in the early phases of development, since there the traditional modularization techniques of design – e.g., breaking up a system into components – are not applicable. Therefore, to cope with issues like the understandability or the maintainability of complex functional specifications, a construction process must support the modular description of individual functions as well as their composition into the overall behavior.

7.1.1

Principles: Behavior Analysis

Function composition allows to modularize complex behavior by breaking it down into individual functions or features. However, in contrast to modular approaches like components, functions use more general composition techniques, which on the one hand do allow 107

108

Chapter 7. Model-Based Function Composition

to combine even contradicting functionality but on the other hand do not guarantee consistent descriptions by construction. Therefore, analysis techniques are needed to identify those problematic contradictions or ‘feature interactions’. Furthermore, since functionality can be specified in different forms from rather abstract, descriptive to rather concrete, constructive versions, further analysis techniques are needed to relate those descriptions. As described in Chapter 6, the content domain model formalizes these general compositions and therefore allows to explicitly construct the – otherwise implicit – interpretation of a product under development in form of its content model. This explicit formalization of the behavior of a product provided by the content model can then be mechanically analysed. To support a modular approach to the specification of reactive functionality, the analysis techniques – checking the absence of problematic feature interactions and existence of implementation relations between different abstractions of functionality – are formalized as constraints using the content domain model. Thus, by analyzing the validity of these constraints with respect to the content product model, the modular construction of a functional description of the system under development is facilitated.

7.1.2

Overview: Function Composition

In the remainder of this chapter, the potential of using a model-based approach for the development of functional specification is demonstrated. Section 7.2 discusses the specification of the overall system functionality during the early stages of development: complex, unstructured descriptions of the functionality of a system causing incomplete and incomprehensible specifications, and mechanisms to structure, analyse, and refine modular specifications as a possibility to avoid these defects. Section 7.3 introduces functions as the foundation to a model-based specification of system functionality. The core issue of this model is the explicit modular composition of functionality, as well as establishing compatibility, completeness, and refinement. In Section 7.4, the application of this model is illustrated, providing a mechanism to automatically check the validity of the imposed compatibility, completeness, and refinement of functional specifications. Finally, in Section 7.5, a short summary of the application of modular functional specifications is given, and the presented approach is compared to related work.

7.2

Context: Function Modularization

In the analysis phase of a development process, as shown in Chapter 3, one of the essential tasks consists in breaking down the overall functionality in single functional modules to

7.3. Approach: Function Analysis

109

further the understanding of a specification by separation of concerns. These single functions must then be integrated to form the specification of the system under development, to be implemented, e.g., in a component-based approach as described in Chapter 8. To effectively use functional modularization to support an integrated analysis and design, therefore, mechanisms to define, combine, and relate functions in a modular fashion are needed.

7.2.1

Problem: Modular Behavior Specification

In many application domains reactive systems are becoming increasingly complex to cope with the technical possibilities and requested functionalities. The behavior provided by the system often is a combination of different functions integrated in an overall functionality; e.g., an embedded controller managing the movement of a car power window combines control of the basic movement, position control to restrict motor overload, as well as power management to avoid battery wear. Implementing those combinations of individual functions is a complex and error-prone task. Since these functions in general influence each other, a modular development process ensures that the combined functionality respects the restrictions imposed by each individual function. Furthermore, due to the increased demand for possible variants of behavior, in general the development of reactive systems requires the recombination, restriction and extension of functionalities. Here, the use of functional modules can improve the development process by supporting the modular definition of the basic functions as well as their combination into the overall functionality.

7.2.2

Contributions: Modular Function Composition

Modular functional development aims at supporting the development process of multifunctional reactive systems by use of modular composition of functions. To that end, we • apply functions as modular units of system composition, to support the specification of descriptive as well as constructive models of system behavior. • use disjunctive and conjunctive composition as a means of combination, which allows to structure functional descriptions. • provide automatic proof support to check completeness and consistency of descriptive or constructive specifications as well as refinement between more descriptive and more constructive variants of specifications of funcionality.

110

Chapter 7. Model-Based Function Composition stp Power Position Controlled Window Bat

Mot!Lo

Bat?Hi Mot!Lo But?Dn

dn Pos?On Mot!Zr But Mot!Zr But?{Hd,Dn} But?Up Pos?Of

Pos

Bat?Hi But?Up Mot!Hi Mot!Zr Pos?On Mot!Zr up But?Dn

But?{Hd,Up} Pos?Of Mot!Hi

Mot

But?Hd Bat?Lo Mot!Zr Mot!Zr

Figure 7.1: Refactored Power Position Window Function

7.3

Approach: Function Analysis

As stated in Section 7.1, functions are intended to support the modular composition of complex functionalities in the development process by combining individual pieces of reactive behavior. Thus, the descriptive form of general functional descriptions eases the combination and reuse of functions and the reasoning about the overall functionality. However, for complex behavior it requires to analyze the description for absence of potential partiality to ensure the implementability of a function. Furthermore, the descriptive form must be linked to the constructive form by a implementation relation to avoid gaps in the development process. In this section, the content model introduced in Chapter 6 is used to provide a modular approach to the descriptive specification of complex functionality of a system, to ensure its implementability, and to link such a description to a corresponding constructive specification.

7.3.1

Instantiation: Modular Functions

Functions form the building block of the approach presented here. Basically, functions are capsules of behavior, defined by their (external) interface in terms of data and control flow as well as their (internal) implementation. The data flow between the function and its environment is described in form of data signals exchanged between them, allowing the function to observe and control shared signals. The control flow between the function and its environment is described in form of control locations used to pass control between them, allowing the function to be activated and deactivated. Figure 7.1 shows a function Power Position Controlled Window describing the functionality of a power window controller. It controls the motor of a car window, depending on the commands issued via a button. Position detection is used to switch off the movement if


111

the window reaches its final positions, overriding the button commands to avoid motor wear. Finally, the available voltage is checked, to avoid exhausting use of a low battery. The capsulated behavior is represented by a box, and identified by a function name (Power Window). Interface elements (e.g., Bat, stp) are attached to its border; its internal structure is depicted inside the box. The function observes user interactions via the But signal (with Up, Hd, and Dn signaling the up, hold, and down position of the switch), the current battery status via the Bat signal (with Hi and Lo signaling high and low voltage), and the current position of the window via the Pos signal (with On and Of signaling intermediate or end positions of the window). It controls the motor of the window via the Mot signal (with Hi, Lo, and Zr signaling upward, downward, or no movement). As shown in Figure 7.1, the input and output signals accessed by a function are indicated by boxes at the border of the function. To control the activation and deactivation of the function, it can be entered and exited via the control location stp. As shown in Figure 7.1, interface locations as well as internal control locations are indicated by outlined circles. Here, the behavior of the function is generally described in a state-transition manner. As shown in Figure 7.1 in case of Power Position Controlled Window, its internal control flow is described via locations dn, stp, and up (with stp being an internal control location as well as an interface location, indicated by the grayed-out line), as well as transitions between these locations. Transitions are influenced by observed signals and influence controlled signals. Furthermore, transitions might be influenced by values of local variables and influence local variables. Thus, if control resides in location stp, value Hi is received via the Bat signal (Bat?Hi), and a value Up is received via the But signal (But?Up), then value Hi is sent via the Mot signal (Mot!Hi) and control is transferred to location up. Obviously, a single transition can be understood as the most basic form of a function. Its interface is defined by the observed and controlled signals (and variables) as well as by its start and end locations. Decomposing Functionality The functionality of Power Position Controlled Window shown in Figure 7.1 can be decomposed in simpler functionalities, addressing special aspects of the combined behavior: power control, addressing issues of voltage-dependent window movement; position control, addressing issues of end position detection; and basic window control, addressing issues of button-controlled window movement. As shown by the white boxes in Figure 7.3, to obtain an equivalent functional decomposition Power Position Window of function Power Position Controlled Window, five basic functions are used: 1. Basic Window movement control, moving the window as requested by the interactions of the user,

112

Chapter 7. Model-Based Function Composition Basic Window But?Hd Mot!Zr But?Up But?Dn But But?{Hd,Dn}

Mot!Hi

Mot!Lo Mot!Zr

Mot!Lo

Mot!Zr

But?Up

dn

But?{Hd,Up} Mot Mot!Hi

But?Dn

stp

up

Figure 7.2: Basic Window Function 2. Position Check, restricting window movement to positions in between end positions, 3. Position Override, halting the window if reaching an end position, 4. Power Check, restricting window movement to situations with sufficient initial voltage, 5. Power Override, disabling window movement if lacking sufficient voltage. Obviously, all five functions control the motor movement via the Mot signal, interacting to realize the overall behavior. However, their combined behavior does not support a modularization of the behavior of the controller, failing to reflect the separation of concerns into individual functions. Therefore, if restricted to constructive formalisms (like Statecharts [HP98] or Masaccio [Hen00]), identifying these five functions in a modular fashion is not possible. As a result, ensuring that the overall behavior implements the intended interaction of these functions requires the use of an additional property-language (e.g., temporal logic). Figures 7.2, 7.4, and 7.5 show the corresponding basic functionalities. Function Basic Window provides basic window movement functionality, in form of upward movement caused by a Hi-value for the Mot-signal initiated by a Up-value for the But-signal in location stp; holding (But?Up) or relasing (But?Hd) the button continues the upward movement (Mot!Hi), while changing the button (But?Dn) will stop the movement (Mot!Zr). The functionality for the downward movement is supplied in a similar fashion. The function is activated and deactivated via interface location stp – corresponding to the internal control location representing a stopped motor – or via interface locations dn and up – corresponding to two internal control locations representing either downward or upward movement of the motor – shown at the interface of Basic Window. Position control, as shown in Figure 7.4, consists of Position Check, ensuring that the motor is restricted to intermediate positions, and Position Override, ensuring that the motor is stopped if an end-position is reached. Once activated by a motor movement


113 Power Position Window +

Power Position Controlled ×

Power Override

Position Window +

Power Check

Position Controlled ×

Position Override

Basic Window

Position Check

Figure 7.3: Functional Decomposition of Power Position Controlled Window (Mot!{Hi,Lo}), Position Check enforces that further movement requires a non-end position (Pos?Of:Mot!{Hi,Lo}) until deactivation (Pos?Of:Mot!Zr). Interface locations stp as well as dn and up correspond to a stopped or moving motor. Position Override provides an override functionality to stop a window movement when an end-position signal is detected. Similarly, power control consists of Power Check, ensuring that starting the motor movement requires sufficient voltage, and Power Override, ensuring that the motor is not activated in case of insufficient voltage. Composing Functionality To obtain the overall behavior of the controller of the power window, the functions introduced above are combined. Figure 7.3 also shows how Power Position Window is composed to obtain an equivalent functionality like Power Position Controlled Window: Basic Window and Position Check are combined by conjunctive composition – indicated by × – to function Position Controlled, which in turn is combined by disjunctive composition – indicated by + – with function Position Override to function Position Window. Using the same pattern of

114

Chapter 7. Model-Based Function Composition Position Check Mot!{Hi,Lo}

Mot!Hi,Lo} Pos?Of

Pos?Of Pos

Mot!Zr

Mot!{Hi,Lo}

Position Override

Mot!Zr

Pos?Of

Pos?On

Pos?On Mot

Mot!Zr Mot!Zr

Pos

Mot!{Hi,Lo}

Mot

Pos?Of

up

stp

dn

dn

stp

up

Figure 7.4: Position Control Functions Power Check

Power Override

Bat?Hi Mot!{Hi,Lo}

Mot!Zr Bat

Bat?Lo

Bat?Hi

Mot!{Hi,Lo}

Mot

Bat

Mot!Zr

Mot

Mot!Zr

stp

stp

Figure 7.5: Power Control Functions composition, Position Window is combined by conjunctive composition with Power Check to obtain function Power Position Controlled, which in turn is combined by disjunctive composition with Power Override to function Power Position Window. Disjunctive composition corresponds to the alternative combination of composed functions, while conjunctive composition corresponds to the simultaneous combination of the composed functions, as introduced in Chapter 6. Obviously, disjunctive composition is not sufficient to obtained the intended functionality, since position control and power control are supposed to restrict basic window movement. Similarly, simple conjunctive composition does not lead to a reasonable behavior, since basic movement, position control, and power control as defined above are in conflict to each other. Therefore, a more sophisticated form of combination is needed, describing the priorities between these (sub-)functions. Here, the content model introduced in Chapter 6 provides suitable formalizations of these combinations. Figures 7.6 and 7.7 describe these prioritized compositions. As shown in the left-hand side of Figure 7.6 , at the top level, the Power Position Window is realized by alternative combination – indicated by a light red background used inside the box representing a function – of the Power Override function together with the Controlled Position Window, ensuring that a lack of voltage does result in a blocked window movement. Activation and deactivation of the disjunctive composition Power Position Window via the stp interface

7.3. Approach: Function Analysis Bat

But

Power Position Window

115

Pos

Power Position Controlled Bat But Pos

Bat

Power Override stp

stp

Power Position Controlled

Mot

Mot

Bat Power

Bat

Mot

Check

Mot

stp But Pos

Mot

stp Position Mot Window

stp

stp

Figure 7.6: Power Position Window and Controled Position Window Functions stp Position Window Position Controlled

Pos

Pos But

Position dn Override up up

dn

stp

But

Position Mot Check stp dn up

But

Mot

Position stp Controlled

dn up stp Basic

Pos

But

stp

Mot

Pos Window Mot

dn

up

Figure 7.7: Position Window and Controlled Window Functions

location corresponds to the alternative activation and deactivation of either sub-function via stp. Furthermore, as Power Override and Power Position Controlled share the interface location stp, activation may pass from one to other and back. As the signal interfaces (Bat, But, Pos, and Mot) are linked to the corresponding interfaces of the sub-functions, signals are passed between the environment of Power Position Window and the currently activated sub-function. As Controlled Position Window is obtained by simultaneous combination – indicated by a light blue background used inside the box representing a function – of Power Check and Position Window, any window movement is only initialized in case of sufficient voltage. Activation and deactivation of the conjunctive composition Power Position Controlled via interface location stp corresponds to the simultaneous activation and deactivation of both sub-functions via stp. Furthermore, the signal interfaces (Bat, But, Pos, and Mot) of Power Position Controlled Power Check and Position Windoware simultaneously observed and controlled by the sub-functions via their corresponding linked signal interfaces.

116


A similar construction is applied to ensure position control. As Position Window is realized by alternative combination of Position Override and Controled Window, detection of an end position stops the movement of the window. By simultaneous combination of Position Check and Basic Window to form Controled Window, the basic window movement is restricted to intermediate positions of the window. Thus, by the order of composition, prioritization of the different functions is realized: By adding position control via conjunctive composition to the basic window functionality, position control overrides the basic behavior. Similarly, by adding power control via conjunctive composition to the position window functionality, power control overrides the position-controlled behavior.

7.3.2

Operationalization: Modularization Analysis

To use a modularized specification of the functionality of a reactive system in the development process, two analysis methods are of special importance: Completeness Analysis, to ensure that the specified functionality provides a reaction of the system for each action of the environment. Refinement Analysis, to ensure that a more concrete specification of a functionality refines a more abstract specification In the following, techniques for these two methods are introduced. While refinement requires a dynamic analysis of the involved systems, i.e., an analysis based on the exploration of their complete behavior, for the completeness analysis a weaker, static analysis, i.e., an analysis managing without this complete exploration, can be provided, which is a sufficient indicator for completeness. Basically, a function F is said to be complete iff for all (a, t) in Obs F • either ∃b ∈ LocF .(a, t, b) ∈ ObsF ,

• or ∀i ∈ I.∃o ∈ O.(a, t ◦ (i, o)) ∈ ObsF

Intuitively, a complete function can react with a suitable output on any input provided, while it is not yet terminated. Obviously, the completeness of a functional specification also requires the analysis of the corresponding behavior if no further restrictions are imposed on the function. This is, e.g., the case when functions are used descriptively for the specification the overall behavior of a system in the analysis phase of a development process. However, as shown in Chapter 8, functions can also be used more constructively in the design phase to define a component-based description of the system. For this case, completeness can be ensured for a structured function by establishing • data flow consistency • control flow consistency as introduced in the following subsection.


117

Data Flow Consistency For a structured function to be consistent concerning its data flow, it must be composed from sub-functions which are compatible concerning the exchange of signals via their variables. To define the consistency concerning data flow, the variables of a function are classified as input and output variables. Input variables are used to transfer signals from the environment to a function, while output variables are used to transfer signals from a function to its environment. The distinction between input and output variables is defined inductively over the structural composition of a function. For a basic function A described by the structure (a, t, b), the input variables In A are the variables v that are used as `v in t. Similarly, the output variables Out A of A are the variables v that are used as v´ in t. Considering the example of basic function Position Override shown in Figure 7.4, its variables are defined by V ar = In ∪ Out with In = {But} and Out = {Mot}.

For the alternative combination of two functions A and B, the function described by A + B uses the input and output variables of either function: InA+B = InA ∪ InB , and OutA+B = OutA ∪ OutB . Therefore, in case of function Position Window in Figure 7.7, it uses input variables But of Position Override and Position Controled, input variable Pos of Position Controled, as well as output variable Mot of and Position Override and Position Controled. For the simultaneous combination of two functions A and B, the function described by A × B uses input and output variables: InA×B = InA ∪ InB \OutA×B , and OutA×B = OutA ∪ OutB . Thus, in case of function Position Controlled shown in Figure 7.7, its data flow interface consists of input ports In = {But} of Position Check and In = {Pos} of Basic Window as well as of their common output port Out = {Mot} of both sub-functions. For the hiding of a variable v from a function A, we obtain a function described by A\v that uses the input and output variables of A excluding v: InA\v = InA \{v}, OutA\v = OutA \{v}.

Finally, the hiding and renaming of control locations leaves the input and output variables unchanged: InA\l = InA and OutA\l = OutA , as well as InA[l/m] = InA and OutA[l/m] = OutA . Based on the definition of the input and output ports of a structured function, the concept of interface consistency concerning data flow is defined. Since basic functions as well as hiding and renaming of variables and locations only deal with a single function, no consistency restrictions are imposed for these constructions. Furthermore, since alternative combination does not lead to a direct interaction between the involved functions, here, too, no restrictions are imposed. However, for the simultaneous combination A×B, unless we require the interface constraint generally imposed for the composition of components – by Out A ∩Out B = ∅ – simultaneous combination of functions may result in output variable conflicts, leading to the introduction

118


of (additional) partiality in the behavior of the combined functions. Therefore, for simultaneous combination this restriction is imposed to ensure interface consistency concerning data flow. Control Flow Consistency For a structured function to be consistent concerning its control flow, it must be composed from sub-functions which are compatible concerning the transfer of control via their locations. To define the consistency concerning control flow, the locations of a function are assigned entry and exit conditions. Entry conditions are used to describe states that allow the transfer of control to a function from its environment, while exit conditions are used to describe states that require the transfer of control from a function to its environment. The assignment of entry and exit conditions is defined inductively over the structural composition of a function. For a basic function A described by the structure (a, t, b), the entry condition of location a −−→ −−→ is the set entry of states from VarA with (a, entry ◦ exit, b) in ObsA for some exit from VarA . −−→ The entry condition of location b is the empty set of state from VarA . Symmetrically, the −−→ exit condition of location b is the set exit of states from VarA with (a, entry, exit, b) in ObsA −−→ for some entry from VarA . The exit condition of location a is the empty set of state from −−→ VarA . Considering the example of basic function Position Override shown in Figure 7.4, the entry condition of location mv is the set of all states entry with entry(Pos) = On; its exit condition is the empty set. Similarly, the exit condition of stp is the set of all states exit with exit(Mot) = Zr; its entry condition is the empty set. For the alternative combination of two functions A and B, the function described by A + B uses the union of the entry and exit conditions of locations of either function: a entryA+B = entryAa ∪ entryBa , and exitaA+B = exitaA ∪ exitaB for joint locations a. For disjoint locations, entry and exit conditions are the entry and exit conditions of either function.1 For the simultaneous combination of two functions A and B, the function described by A × B uses the intersection of the entry and exit conditions of locations of either function: a entryA×B = entryAa ∩ entryBa , and exitaA×B = exitaA ∩ exitaB for joint locations a. Since disjoint locations are not part of the combined interface, their entry and exit conditions are not defined.2 For the hiding of location l from a function A, the function described by A\l uses the entry a and exit conditions of function A for its locations: entryA\l = entryAa , and exitaA\l = exitaA for location a from Loc A\l . For the renaming of a location l of a function A to m, the function described by A[l/m] a uses the entry and exit conditions of function A, substituting l for m: entryA[l/m] = entryAa , 1

For Var A �= Var B , sA ∈ entry aA and sB ∈ entry aB are extended to sA+B ∈ entry aA+B via sA = sA+B ©Var A and sB = sA+B ©Var B , resp. The same extension is used for exit conditions. 2 For Var A �= Var B , the same extension mechanism is used for the entry and exit conditions.


119

a and exitaA[l/m] = exitaA for location a from Loc A \{l}; entryA[l/m] = entryAa , and exitaA[l/m] = a exitA for location m.

For the hiding of a variable v from a function A, the function described by A\v uses the a restriction of the entry and exit conditions of function A for its locations: entryA\v = a a a entryA ©Var A \{v}, and exitA\v = exitA ©VarA \{v} for location a from Loc A[v/w] . For the renaming of a variable v from a function A to w, the function described by A[v/w] uses the subsitution of the entry and exit conditions of function A for its locaa a a tions: entryA[v/w] ©Var A \{v} = entryA ©Var A \{v}, and entryA[v/w] ©{w} = exitaA ©{v} for location a from Loc A[v/w] ; similarly, exitaA[v/w] ©Var A \{v} = exitaA ©Var A \{v}, and exitaA[v/w] ©{w} = exitaA ©{v} for location a from Loc A[v/w] .

Finally, based on the definition of the entry and exit conditions of a structured function, the concept of interface consistency concerning control flow can be introduced. Since basic functions as well as hiding and renaming of variables and renaming of locations do not deal with the direct transfer of control flow, no consistency restrictions are imposed for these constructions. Furthermore, since combinations do not transfer but rather coordinate control flow between the involved functions, here, too, no restrictions are imposed. However, for the hiding of location, control flow within a function F can only be internally transfered immediately if the entry condition of the hidden location l is a superset of the exit condition of this location, i.e, entry lF ⊇ exit aF and therefore the execution cannot deadlock here, leading to the introduction of new partiality in the behavior of the combined functions. Therefore, for hiding of locations this restriction is imposed to ensure interface consistency concerning control flow. Refinement While the use of the general, descriptive form supports a structured development of the overall functionality, a more compact and constructive variant is generally more preferable for its effective implementation. As shown in the examples, the definition of Power Position Window from the basic functions (Basic Window, Position Check, Position Override, Power Check, Power Override) leads to a more structured description. In contrast, the definition of Power Position Controlled Window is more suited for implementation using state-of-the-art tools. Thus, in a function-based development process, the former should be used in the early stages of defining the function under development, while the latter should be used in the later stages. However, for a sound and integrated development process, it is furthermore necessary to establish an implementation relation between those functions. Formally, a function F1 is said to implement a function F2 iff

120

Chapter 7. Model-Based Function Composition • they provide the same closed signal interface: InF1 = In = InF2 and OutF1 = Out = OutF2 and V arF1 = In ∪ Out = V arF2 • they provide the same control interface: LocF1 = LocF2

• every possible observation of F1 is also a possible observation of F2 : ObsF1 ⊆ ObsF2

Basically, functional refinement corresponds to standard trace inclusion. Since here continuous reactive systems are considered with simultaneous input/output actions using a signal-based communication with input enabledness, partial execution traces provide a suitable semantical basis. Obviously, this notion of implementation is transitive and reflexive. Furthermore, the operators introduced in Chapter 6 are monotonic with respect to this implementation relation. Using this notion of implementation, Power Position Controlled Window is an implementation of Power Position Window and vice versa.

7.4

Application: Composition Analysis

As introduced in the previous sections, functions are intended to support the modular construction of complex functionalities in the development process by combining individual pieces of reactive behavior. However, while the descriptive form of general functional descriptions eases the combination and reuse of functions and the reasoning about the overall functionality, for the final implementation of the intended behavior in general more constructive forms of descriptions are used, as provided, e.g., by corresponding tools like [HP98], [Hei02], or [HSE97b]. As mentioned in Section 7.1, these descriptions correspond to a restricted form of functions, avoiding the introduction of partiality and ensuring completeness or input enabledness. On this constructive level, input enabledness is either established implicitly by completion (as, e.g., in [HSE97b]) or explicitly by analysis (as, e.g., in [Hei02]). Thus, to integrate these different applications of functional descriptions in a function-based development process, these more descriptive forms must be accompanied by a mechanism to exclude partiality and link to more constructive forms by a mechanism ensuring the implementation relation, as introduced in Subsection 7.3.2. To that end, in this section, a formalization of techniques in Section 7.3 in machine-analyzable form is introduced, and its application in the automation of function composition is illustrated.

7.4.1

Implementation: Analysis Automation

To provide mechanisms to analyse functional specifications with respect to partiality or refinement, a formalism is needed supporting the description fo those specifications and analysis techniques. Since the content model introduced in Chapter 6 uses behaviors described as sets of observations, which are based on sequences of variable assignments, WS1S

7.4. Application: Composition Analysis

121

(weak second order monadic structure with one successor function) provides a suitable formalism for the formalization of functions and their analysis techniques. WS1S-Functions To effectively use the implementation relation in a sound development process, (automatic) support for the verification of the implementation relation between two functions is necessary. Since the behavior of functions is defined by (possibly infinite) sets of finite traces, and the implementation relation is defined by the inclusion relation over those sets, a trace-based formalism is best-suited. Therefore, here WS1S is used to implement automatic proof support. This formalism is, e.g., supported by the modelchecker Mona [KM01]. Using WS1S, functions are specified by predicates over sets of observations. The operators introduced in Chapter 6 can be directly implemented, allowing a compositional construction of the corresponding trace sets. Similarly, the implementation relation can be defined as a relation on observation sets. Besides proving the refinement relation between two functions, Mona can be used to generate a counter-example for functions violating the refinement relation. Basically, to define predicates over behaviors of functions, the logic of WS1S provides elementary propositions about observations. Obviously, for a variable carrying a signal, the most basic proposition expressible states that this variable has a certain signal value assigned at a specific instance in time. For example, looking at the functionality of the basic window in Figure 7.2, a basic proposition might concern the variable But, carrying the signal for the button indicating the requested direction of the window movement, stating that “variable But has value Up assigned at instance time”. Such basic propositions are formalized over sequences of states, using the set of indices within such sequences characterizing states with variable But having value Up assigned. In case of the above example, such a proposition is formalized as time in ButUp with time characterizing the index for instance time in the sequence of states, and ButUp characterizing the set of indices of states with But having Up assigned as value. To define general predicates over sequences of states, basic propositions for • all variables within the state of the system, and • all values for each variable are introduced. In case of the variable But with potential values Up, Hd, and Dn, the sets ButUp, ButHd, and ButDn are used to exactly describe the assignments of values to But for a sequence of states. Thus time in ButUp & time notin ButHd & time notin ButDn

122


states that variable But exactly has value Up at instance time. To define predicates over those sequence of states, WS1S provides variables (as well as quantors) for such sets of indices. In case of the But variable, the corresponding WS1S variables for the sets are var2 ButUp, ButHd, ButDn with var2 indicating the second-order character, i.e., sets of indices for which the basic propositions must hold, of those variables. Besides the sequence of states, an observation also consists of a start location, and – possibly – an end location. A similar scheme as in the case of the sequence of states is used to characterize the start and end locations of an observation. For each possible location as well as the start and end case a corresponding basic proposition is used. Thus, in case of observations over locations Stp, Up, and Dn, (SStp & ~SDn & ~SUp) & (~EUp & ~EDn) states that the start location definitely is Stp and end location possibly is EStp, using basic non-indexed proposition SStp, SDn, and SUp, as well as EStp, EDn, and EUp. Again, WS1S provides variables (and quantors); for the above locations, var0 SStp, SUp, SDn as well as var0 EStp, EUp, EDn are used, with var0 indicating the zero-order character, i.e., non-indexed basic propositions, of those variables. Using this scheme of representation, a basic function in form of a simple transition can be formalized by pred StpButUpMotHiUp(var0 SStp, SUp, var1 stime, var2 ButUp, ButHd, ButDn, var2 MotLo, MotZr, MotHi, var1 etime, var0 EStp, EUp) = (SStp & ~SUp) & (~EStp & EUp) & (stime + 1 = etime) & (stime in ButUp & stime notin ButHd & stime notin ButDn) & (etime notin MotZr & etime notin MotLo & etime in MotHi);


123

characterizing the transition StpButUpMotHiUp leading from start location Stp to end location Up upon receiving signal value Up via variable But, and sending signal value Hi via variable Mot.3 Note that the WS1S implementation does not directly reflect the content model used in Chapter 6. In contrast to the model described there, here the sequence of states characterized by an observation predicate like StpButUpMotHiStp does not only cover the states observed between entering a function through the start location and exiting the function through the exit locations. The predicate rather covers longer sequences including states before and after the execution of the function described. However, the predicate leaves the states before and after the execution unrestricted, limiting the characterized values to the states observed between entering through the start location at time stime and exiting through the exit location at time etime. This form of representation allows to simplify the implementation of the composition operators introduced in Chapter 6. Thus, e.g., the alternative combination of basic functions functions StpButUpMotHiUp and – a similarly formalized – UpButDnMotZrStp to a function WindowButUp can be directly formalized as pred WindowButUp(var0 SStp, SUp, SDn, var1 var2 ButUp, ButHd, ButDn, var2 MotLo, MotZr, MotHi, var1 etime, var0 EStp, EUp, EDn) StpButUpMotHiStp(SHd, SUp, SDn, stime, ButUp, ButHd, ButDn,MotLo, MotZr, etime, EHd, EUp, EDn) | UpButDnMotZrStp(SHd, SUp, SDn, stime, ButUp, ButHd, ButDn,MotLo, MotZr, etime, EHd, EUp, EDn);

stime, = MotHi, MotHi,

In a similar fashion, simultaneous composition as well as hiding and renaming can be formalized. Implementability Analysis As mentioned in Subsection 7.3.2, basically, to ensure that no partiality is contained in a function to be implemented, the behavior of this function must be be analyzed to ensure that each observation can be extended to a terminating one ending at an end location of that function, or extended by another output assignment for each input assignment. While this property can directly be formalized in WS1S as well, here the formalization of the statically verifiable rule is illustrated, leading to a sufficient conditions for non-partiality. 3

For improved readability, actually only the longest observation is formalized, which can be weakend to the general case. Additional conditions ensuring the uniqueness of values for But for times other than stime and of Mot for times other than etime are left out here and in the following.

124


For the static analysis approach, to ensure that no partiality is contained in a function to be implemented, a function must be data flow consistent, avoiding to introduce partiality by adding contradicting functionality, and control flow consistent, avoiding to keep partiality by leaving out necessary functionality. Data flow consistency only concerns the vocabulary of functions and thus can be checked using techniques of the conceptual level, similar to the conformance analysis discussed in Chapter 4. To ensure consistency of the control flow, however, the entry and exit conditions of the locations must be analyzed, requiring to formalize them in WS1S. For the function StpButUpMotHiUp and locations Stp and Up, they can be formalized as pred EntryStp(var0 SButUp, SButHd, SButDn, var0 SMotLo, SMotZr, SMotHi) = ex0 EButUp, EButHd, EButDn: ex0 EMotLo, EMotZr, EMotH: (SButUp & ~SButHd & ~SButDn) & (~EMotZr & ~EMotLo & EMotHi); and – equivalently – pred ExitUp(var0 EButUp, EButHd, EButDn, var0 EMotLo, EMotZr, EMotHi) = ex0 SButUp, SButHd, SButDn: ex0 SMotLo, SMotZr, SMotH: (SButUp & ~SButHd & ~SButDn) & (~EMotZr & ~EMotLo & EMotHi); thus obtaining the characteristic predicates for the corresponding set of states, using the scheme introduced above. Since here states rather then sequences of states are characterized, similar to the representation of locations zero-order variables are used, together with the zero-order existential quantor ex0 to identify values for the variables of the exit and entry states, resp. Using this formalization, again, the entry and exit conditions for composed functions can be directly formalized in WS1S. Finally, to ensure the control flow consistency for hiding a location like Up, the corresponding superset conditions is formalized as all0 ButUp, ButHd, ButDn: all0 MotLo, MotZr, MotHi: ExitUp(ButUp, ButHd, ButDn, MotLo, MotZr, MotHi) => EntryUp(ButUp, ButHd, ButDn, MotLo, MotZr, MotHi) enabling Mona to check its validity.


125

Refinement Analysis To check whether a more concrete function implements a more abstract one, it has to be ensured that • they provide the same data flow interface, • they provide the same control flow interface, and • each observation of the concrete function is also an observation of the abstract function. Again, the interface aspects can be checked on the conceptual level using the techniques discussed in Chapter 4. The inclusion relation of the behaviors of the functions can be directly formalized in WS1S. Thus, to check e.g., the refinement of Power Position Controlled Window by Power Position Window, the condition all2 ButUp, var2 ButHd, var2 ButDn: all2 PosOn, var2 PosOf: all2 MotLo, var2 MotZr, var2 MotHi: all1 end: all0 Stp: PowerPositionWindow(true,0,BatLo,BatHi,ButUp,ButHd,ButDn,PosOn,PosOf, MotLo,MotZr,MotHi,end,Stp) => PowerPositionControlledWindow(true,0, BatLo,BatHi,ButUp,ButHd,ButDn,PosOn,PosOf, MotLo,MotZr,MotHi,end,Stp) can be verified using Mona, stating that each observed execution of the function Power Position Window starting at time 0 in location stp and ending at time end – possibly but not necessarily by termination at location stp – is also an observable execution of function Power Position Controlled Window.

7.4.2

Method: Composition Automation

In the late analysis and early design phase, the content model formalizing functions provides an interpretation for the modular description of behavior. Based on this interpretation, modular development of functional descriptions is then supported using the three steps • modular composition of functional specifications • automated analysis of implementability • automated analysis of refinement as shown in the following.

126


Figure 7.8: AutoFocus Specification of Modular and Integrated Functions

Modular Composition When composing a modular specification of the functionality of a system under development, the principle of vertical views as discussed in Chapter 2 are used. Similar to other modular approaches to system specification, the specification of the functionality is composed in a hierarchical fashion, building functions from sub-functions via the composition operators introduced in Chapter 6. For the elementary functions as well as their composition, suitable descriptions techniques are provided. Figure 7.8 shows the specification of functions in the modular, descriptive version (lower windows) and in the integrated, constructive version (upper window) using the AutoFocus notation. While for the (syntactic) description of the specified behavior the concept model is sufficient, the interpretation of the concept product model via the content product model is required for an effective integration of the functional specification in the development


127 stp

Power Position Controlled Window Bat But Pos

Mot!Lo

Bat?Hi Mot!Lo But?Dn

dn Pos?On Mot!Zr Mot!Zr But?Hd But?Up Pos?Of

Bat?Hi But?Up Mot!Hi Mot!Zr Pos?On Mot!Zr up But?Dn

But?Hd Pos?Of Mot!Hi

Mot

But?Hd Bat?Lo Mot!Zr Mot!Zr

Figure 7.9: Defect Power Position Window Function with Partiality process. Only the explicit construction of the corresponding content model enables the automated analysis described in the following. Automated Analysis While during the analysis a rather descriptive, modular description of the intended functionality is more profitable, during the design phase generally a rather constructive description of the functionality is best-stuited, facilitating techniques like simulation or code generation. Changing from analysis to design therefore requires to relate the descriptive and constructive versions of specifications, ensuring that the latter is an implementable refinement of the former. Control Flow Analysis. Implementability is verified by ensuring data flow and control flow consistency, as described above. In the design phase, simultaneous composition is restricted to classical composition of components, reducing data flow consistency into a consistency condition on the conceptual level. Therefore, and since Power Position Controlled Window is implemented as a single component, only control flow consistency is investigated here. To demonstrate control flow analysis, instead of the Power Position Controlled Window functionality in Figure 7.1 the defect version in Figure 7.9 with partiality at location dn and up – in form of the missing transition with labels But?Dn ∧ Pos?Of : Mot!Lo and But?Up ∧ Pos?Of : Mot!Hi is considered. Computing the entry conditions of these locations leads to But = Up ∨ Pos = On ∨ (But = ¬Hd ∧ Pos = Of) and But = Dn ∨ Pos = On ∨ (But = ¬Hd ∧ Pos = Of)

128


which corresponds – considering the possible values of the signals – to ¬(But = Dn ∧ Pos = Of) and ¬(But = Dn ∧ Pos = Of) resp. Similarly, the computation of the exit conditions of these locations leads to Mot = Lo and Mot = Hi resp. Obviously, checking the subset relation on the entry and exit conditions leads to Mona reporting a violation in either case. Using its counter example mechanism, explanations BatLo ButUp PosOf MotLo

= = = =

true, BatHi = false false, ButHd = false, ButDn = true true, PosOn = false true, MotZr = false, MotHi = false

= = = =

true, BatHi = false true, ButHd = false, ButDn = false true, PosOn = false false, MotZr = false, MotHi = true

and BatLo ButUp PosOf MotLo

illustrate the states violating the control flow consistency. Refinement Analysis. Besides establishing the implementability of a constructive specification of a function, obviously the refinement relation to its corresponding descriptive variant must also be established. The interface conditions – identical data and control flow interfaces – are checked on the conceptual level. For the subset relation on the set of observations, again Mona is used. When comparing the functional specifications of Power Position Window of Figure 7.7 (including Figures 7.6, 7.4, and 7.2) and Power Position Controlled Window of Figure 7.1, Mona confirms that the latter is a refinement of the former (and vice versa). Of course, the refinement relation can also be checked between the more constructive versions. Comparing Power Position Controlled Window of Figure 7.1 with the defect version in Figure 7.9, Mona again confirms that the latter is a refinement of the former. However, the opposite does not hold, which is demonstrated by the counterexample

7.5. Conclusion: Function Composition BatLo BatHi ButUp ButHd ButDn PosOf PosOn MotLo MotZr MotHi

= = = = = = = = = =

129

{1} {0} {0,1} {} {} {0,1} {} {0,1} {} {}

being a possible execution of the complete version, but not of the version with partiality due to the laking transitions.

7.5

Conclusion: Function Composition

In this chapter, a modular development process supporting the construction of complex reactive behavior composed from simpler individual functions is introduced. By breaking down the description of the behavior into modules, the resulting descriptive specification reduces the complexity. As this modularity, however, requires to analyze the interaction between these modules, analysis techniques to address consistency and refinement issues of the overall specification are provided.

7.5.1

Summary: Function Composition

In the approach presented in this chapter functional modular development is introduced, using functions as construction units, with transitions as the most basic form, as well as disjunctive and conjunctive composition to combine subfunctions to more complex functions. Offering separation of concern by modular composition of functions, reasoning about the overall behavior is simplified by conjunctive and disjunctive construction of functionalities, which allow to either alternatively or simultaneously combine functional behavior. Using the precise definition of the notion of a function, properties of functions can be formally introduced and analyzed. Since modular construction may lead to partiality due to inconsistency or incompleteness, the use of analysis to ensure data flow consistency as well as control flow consistency is demonstrated, which is specifically interesting for the modular construction of complex behavior. Finally, a formal implementation relation between two functional descriptions is established, which allows to precisely define and check the refinement of one functionality by another. Since the combination of highly interacting functions does in general not lead to a large state space compared to the composition of loosely connected components, the approach

130


proves to be feasible in domains with a more reactive than computational behavior. Applied in the domain of automotive body electronics, where generally enumeration type signal and state variables are used instead of integer or float values, the tool infrastructure can successfully handle the combination of several dozens of functions, and analyse their consistency and completeness within seconds.

7.5.2

Related Work: Behavioral Analysis

Functions, providing a modular description of behavior, support the construction of complex behavior from basic functionality. However, for their effective application, analysis techniques are required for the specified behavior to detect issues with the completeness of a specification or the refinement between specifications. The notion of completeness and refinement are similar to those used in other approaches, e.g, [BS01], [Hen00], or [LT89]. While however these approaches enforce complete behaviors, here, completeness is not imposed per default but rather checked as a possible option. Furthermore, unlike in those approaches, an automatic analysis mechanism for refinement based on behavior implication is provided here. As mentioned above, the combination of partial descriptions to form a complete specification is closely related to the problem of feature interaction. Since this problem has been studied carefully in the context of telecommunication, especially the issue of consistent specifications has been addressed there [CM00]; however, besides being more complex, those approaches generally add implementation details or other restrictions. Furthermore, the issue of the incompleteness of combined service descriptions is treated here, which is generally not considered in the other approaches. Like in [Hei02], modular specifications are checked for completeness. Unlike in that approach, however, here the notion of completeness is adapted to the extended interface notion, enforcing completeness only for internal locations. Furthermore, here, also verification of refinement relations are supported. Due to this form of composition, they are similar to services-oriented descriptions as used in [BKM07] or [SS03]. However, in contrast to those approaches, here control and data flow are explicitly modeled by means of the explicit introduction ports and locations, supporting a more compact form of specification. As a consequence, here, specific concepts are provided to check the completeness of specifications based on the control flow locations. Finally, the approach introduced here extends [Sch05] by focusing on refinement rather than refactoring, and providing automated proof support by use of modelchecking.

Chapter 8 Model-Based Test Case Integration In a component-based development approach system integration generally implies the packaging and deployment of a group of software components on hardware units, possibly hiding the interface of a component inside the unit. As a result, testing generally is performed during the integration phase on the (logical) component as well as the (technical) unit level, to ensure the correctness of the implemented functionality of each component in isolation as well as of the complete system influenced by the implementation platform. However, analysing the correct functionality of a bundled and deployed component requires direct access to the interface of the component. Here, integrating a component test case into the behavior of the remaining system provides means to verify the functionality of a component from the interface of the unit without additional instrumentation of the complete system deployed to the unit.

8.1

Introduction: Test Case Integration

During the verification phase in component-oriented approaches to (embedded) system development component tests are generally followed by system tests, often using different testing specifications and environments. Thus, when integrating components in the overall system, the actual implementation platform may differ from the development platform, leading to a deviation in the component behavior. This raises the issue of testing the functionality of a component integrated in a larger system without the use of an – instrumented – development platform, allowing to perform glass-box-testing. Providing a formalization of test cases and their integration allows to mechanize the transformation of a test case of a component into a black-box test case of the overall system, allowing to deduce the validity of the test case of the component from the validity of the test case of the system. This is especially useful in the context of regression testing, helping to locate defects in a modified component of an otherwise unchanged system. 131

132

8.1.1

Chapter 8. Model-Based Test Case Integration

Principles: Behavior Synthesis

Test case integration deals with deriving the description of a test case for the system under integration, given the description of a test-case for a subcomponent of that system as well as the description of the behavior of the other subcomponents of the system. As described in Chapter 6, the content models explicates the – otherwise implicit – interpretation of the descriptions of a product under development. Such an explicit representation then can be processed mechanically, either for inspection – as in Chapter 7 – or for manipulation, as demonstrated in this chapter. In case of the domain of reactive components, the content model allows to derive an explicit representation of behaviors of the subcomponents of the system under development as well of a test case of the component. Furthermore, it allows to combine these representations and to synthesize an explicit representation of an integrated test case of the complete system under development. This explicit representation can then be re-expressed using the description techniques of the application domain, and thus integrated in the standard development process.

8.1.2

Overview: Test Case Integration

After discussing issues of testing in the context of integration on the target platform and highlighting the contribution of the presented approach in Section 8.2, Section 8.3 presents an adaption of the content model of Chapter 6 to components, networks of components and test cases, providing the basics for the applied techniques. Furthermore, it introduces a characterization of test cases on a system level derived from test cases for components. Section 8.4 demonstrates how the introduced formalizations combined with this method can be used for automatically generating such test cases and using them for integration testing. Finally, in Section 8.5 the presented approach is summarized, and compared to other methods of test case generation.

8.2

Context: Component Integration

In the domain of embedded software sytems, a component-based approach to the construction of (software) system has become the foundation of state-of-the-art software engineering. Besides reducing the complexity of the overall engineering process, component-based software engineering also supports the construction of customized systems by combining pre-fabricated components with others custom-made for the specific system.

8.2.1

Problem: Integration Test

8.2. Context: Component Integration

133

In a component-based approach, quality assurance in the constructive phase is usually performed in the form of component tests, and integration or system tests. However, especially in the construction of customized embedded systems like automobiles, quality assurance is faced with two problems, which often occur during system evolution where most components of the system are reused and only a few components are changed or replaced: • testing of the final implementation should be restricted as much as possible to the changed/custom-made components to efficiently cope with the large number customized systems • system tests have to be performed on the implementation-level platform, which does not supply glass-box-testing with access to all internal data needed for testing a component without costly or invasive instrumentation of the implementation In software testing test cases are derived for a certain system under test (SUT) with the aim of detecting faults in this SUT. The test cases are defined over the interface of the considered SUT, and the interface of the test execution and observation harness usually reflects this interface of the SUT; thus test cases can by applied directly. However, besides this standard situation of test case derivation and execution, there is a more problematic situation: A specific component, which is already an integrated part of a larger system (consisting of further components), is tested while there is no direct access to the component’s interface from the system interface. This leads to the problem of how to test the (sub-)component if test cases can only be executed and observed at the interface of the complete system. To distinguish between the complete system and the considered specific component, the term component under test (CUT) for such a component is used. Such situations occur if there is already a test harness for executing tests at the system level, but no test harness or execution environment for test cases on component level is available. This is, e.g., the case if a new component is integrated in an otherwise unchanged system. Setting up a specific test execution environment for every component may be to costly and too time consuming, if possible at all. Especially, if embedded devices are to be tested on the implementation level control unit, internal data within that unit may not be accessible from the outside. Such an approach is also useful to deduce from the hypothesis of a certain defect in an integrated sub-component the effect of that defect to the complete system at the interface of the implementation-level platform. Finally, reuse may also be a motivation for executing component tests on system interface level: Often component tests have already been specified during the implementation of a component and these should be translated in a way that they can be executed at the integration level.

8.2.2

Contribution: Component Test Integration

The introduced method aims at deducing a system test from a component test, allowing to verify that component test case at the system level without instrumentation of the system. Therefore, in the following, an approach is introduced that allows to transform component

134

Chapter 8. Model-Based Test Case Integration But:Ind

But:Ind

Mot:Dir

Mot:Dir

Window Control

Bat:Vlt Bat:Vlt

Err:Cod Err:Cod

Res:Inf Res:Inf

Dia:Cmd

Req:Cmd

Diagnose Management Dia:Cmd

Error Store Req:Cmd

Sts:Inf

Sts:Cod

Figure 8.1: Power-Window Control Unit: System including Error Store tests to system tests, supporting the verification of test cases for individual components using only the interface of the overall system (if possible). To that end, this chapter • introduces a common formalization of behavioral specifications in the form of the exemplary behavior – like test case descriptions – as well as complete behavior – like component descriptions – including the combination of components to networks. • defines the notion of a test case to be satisfied for a component or system, allowing to check for the validity of a test case. • defines the concept of a system test case verifying a test case for a component of that system. • provides automatic support to generate a test case for the overall system from a test case of a component, verifying that test case of the component if such a test case exists.

8.3

Approach: Test Case Generation

To illustrate the approach, the example of an automotive electronic control unit of a powercontrolled window is used. As shown in Figure 8.1, the control unit holds three software components: Window Control, which translates a button signal received via port But – indicating the direction of the intended movement of the window (Ind = Up, Hd, Dn) – into a motor signal sent via Mot – indicating the executed movement of the window (Dir = Lo, Zr, Hi) – provided the battery signal received via Bat – indicating the current voltage (Vlt = Lo, Hi) – states sufficient power; otherwise an error signal sent via port Err – indicating the error code (Cod = LV, OK) – provides a low voltage error. Error Store, which stores an error signal received via port Err indicating the error code; if requested to return or reset the error status by a request signal received via port Req

8.3. Approach: Test Case Generation

135

– indicating the command (Cmd = Vt, Rs, No) – the result of the request is returned as result signal via port Res – indicating the corresponding information (Inf = Ft, OK, No). Diagnose Management, which translates a diagnostic signal received via port Dia – in-

dicating the diagnostic command – into a corresponding request signal sent via port Req – indicating the requested command – and forwards the result signal received via port Res – indicating the returned information – as a status signal sent via port Sts – indicating the status information.

Since all three components are packaged onto the control unit, only the external signals received and sent via Bat, But, Dia, Mot, and Sts are available for testing any software component deployed on the unit. Thus, to check the validity of a test case as shown in Figure 8.5, verifying the reset-set-query functionality of the Error Store component, a corresponding test case is needed that is immediately executable at the interface of the control unit and is indirectly assuring the validity of the test case of the component.

8.3.1

Instantiation: Component Test Cases

In this subsection, components are introduced as building blocks for the construction of reactive systems. The behavior of a component is described as a transition system, controlling the interaction of the component with its environment or surrounding system via input and output signals. Extending the content model introduced in Chapter 6, it is formalized as the set of possible executions about the interaction with its environment, described by the history of exchanged signals. Additionally, the notion of observations is extended to systems described as networks of communicating components. Finally, test cases are introduced as (sets) of observations. Transition Systems To describe the behavior of a reactive component, often transition systems are used in the form of state-transition-diagrams. Here, the content model provided in Chapter 6 with the notation introduced in [SH99] is used which allows the modular formalization of clocked, hierarchical transition systems. Figure 8.2 shows the graphical notation used to describe the transition system of a component for the example of the Error Store component, with • the set Loc of control locations, used to describe its control state; e.g., the set Loc = {Normal, Failure}

• the set V ar of variables, used to describe its data state; e.g., the set V ar = {Err, Req, Res} • the set T rans of transitions of the form (a, pre, post, b), each consisting of a start location a and end location b from the set of locations Loc, as well as a pre-state

136

Chapter 8. Model-Based Test Case Integration Req?Vt,Err?OK :Res!OK

Req?Vt:Res!Ft

Req?No,Err?LV: Res!No

Req?Rs,Err?OK: Res!OK

Normal

Req?Vt,Err?LV: Res!OK

Req?Rs,Err?LV: Res!OK

Failure

Req?Rs, Err?LV:Res!OK Req?Rs,Err?OK: Res!OK

Req?No,Err?OK: Res!No

Req?No:Res!No

Figure 8.2: Behavior of the Error Store Component pre and post-state post expressions assigning values to variables from V ar; e.g., the transition covering the simultaneous occurrence of a voltage error and the empty command is described by the labeled transition from Normal to Failure with a label consisting of Req?No, Err?LV and Res!No, separated by a colon. To describe a transition, the notation described in [SH99] is used. Using the above example, the first part of the label states that whenever the no-command signal No is received via variable Req and – at the same time – the voltage-error signal LV is received via variable Err, then the transition is enabled. The second part of the label states that, whenever the transition is triggered, in the next state the no-error signal No is sent via variable Err. These parts use a short-hand notation for reading pre-transtion values and writing posttransition values. They correspond to terms Èrr = LV and Res´ = No, respectively, using variables`v with v ∈ V ar for values of v prior to execution of the transition, and variables v´with v ∈ V ar for values of v after its execution. Using these elements, an equivalent formalization of transition systems as introduced in Chapter 6 can be directly provided, using basic functions to capture transitions, as well as alternative combination and hiding of locations systems of transitions.

Note that transitions need not explicitly assign a value to each of its variables from V ar; non-assigned variables are implicitly treated as getting a value nondeterministically assigned. E.g., The request-transition in the Failure-location of Figure 8.2 with label Req?Vt : Res!Ft corresponds to a set of executions of the above form with before(Err) ∈ {OK, LV}.

Furthermore, for the transition system of a component, completeness in the sense of input enabledness as discussed in Chapter 7 is assumed, which can be either achieved explicitly via the specification of the transition system, or implicitly using completions like, e.g., idel completion as in [Sch04]. Component Behavior


137

The description of a component capsules the transition system describing its behavior. Graphically, it consists of the description of the transition system, e.g., provided by Figure 8.2, and by the description of its interface, e.g., provided by the Error Store element in Figure 8.1. Therefore, besides its transition system formalized by its set of corresponding observations, a component is described by • declaring a (non-empty) subset Init ⊆ Loc of initial control locations; e.g., the location Normal, marked by a black dot in Figure 8.21 • declaring a (non-empty) subset of InOut ⊆ V ar of input and output variables for exchanging signals with the environment; e.g., the input variables Err and Req as well as output variable Res, depicted by empty and filled circles in Figure 8.1 Based on these additional descriptions, the behavior of a component can be defined. Based on the observations corresponding to the behavior of the associated transition system, the executions of a component are defined. Since executions of a component are restricted to its interface, locations as well as non-input/output-variables have to be re−−−→∗ moved from the observations to form executions. Therefore, the set Ex ⊆ InOut of all executions s of a component is defined by the set of all observations (a, t, b) and (a, t) where • a is an initial location of the component, i.e., a ∈ Init 2

• s is the restriction of t to the component interface, i.e., s = t©InOut Finally, the behavior of a component is the set all its executions. Using the example of the Error Store, (Normal, s1 ◦ s2 ◦ s3 , Failure) with • s1 (Err) = OK, s1 (Req) = No, s1 (Res) = No • s2 (Err) = OK, s2 (Req) = Rs, s2 (Res) = No • s3 (Err) = LV, s3 (Req) = No, s3 (Res) = OK is a possible observation of the component. Therefore, s1 ◦ s2 ◦ s3 as defined above is a possible execution of the component, since here InOut = Var and Normal ∈ Init. Component Networks To deal with the issues of system integration described in Section 8.1, the definition of observations of components must be extended to hierarchical systems, i.e., components which themselves contain subcomponents communicating via common variables. Chapter 6 basically provides a formalization of networks of components via simultaneous combination and hiding of variables. Since, however, the behavior of a component – in contrast to a 1

Generally, as discussed in Chapter 7, a distinction between input and output variables is used to provide a notion of data flow compatibility; here, for reasons of brevity, this distinction is dropped. 2 As an extension, also initial values of output variables may be defined.

138

Chapter 8. Model-Based Test Case Integration Res?OK: Req!No,Sts!Ft

Dia?Vt,Res?OK: Dia?Vt,Res?Ft: Req!Vt,Sts!OK Req!Vt,Sts!Ft

Dia?Vt:Req!Vt,Sts!OK

Res?No: Req!No,Sts!No

Res?OK:Req!No, Sts!OK

Ready Dia?No,Res?No: Req!No,Sts!No

Res?Ft: Req!No,Sts!Ft

Busy

Dia?Rs:Req!Rs,Sts!OK

Res?Ft: Req!No,Sts!Ft

Dia?Rs,Res?OK: Dia?Rs,Res?Ft: Req!Rs,Sts!OK Req!Rs,Sts!Ft

Figure 8.3: Behavior of the Diagnose Management Component function – is defined without the use of interface locations, a slightly adapted version is needed. Graphically, networks of components communicating over variables are described by component diagrams as shown in Figure 8.1. The communication via common variables is indicated by lines, linking output variables to input variables. For each non-hierarchical component its behavior is described by a transition system; e.g., the behaviors of Diagnose Management and Window Control are shown in Figures 8.3 and 8.4. Formally, a network of components can be defined using composition and abstraction, corresponding to the equivalent operations defined for functions. Intuitively, composition of two components corresponds to their concurrent execution, providing communication via message exchange. Formally, the composition A � B of two components A and B results in a component that • provides the joint interface InOut A�B of both components, i.e., InOut A�B = InOut A ∪ InOut B • exhibits the joint behavior Ex A�B of both components, i.e., s ∈ Ex A�B if s©InOut A ∈ Ex A and s©InOut A ∈ Ex B

Obviously, composition is commutative and associative.

Furthermore, abstraction from a part of the interface of a component renders internal communication invisible at the interface of a component. Formally, the abstraction C\Hid from Hid ⊆ InOut C of the interface of a component C results in a component that • provides the restricted interface InOut C\Hid of the component, i.e., InOut C\Hid = InOut C \Hid • exhibits the behavior Ex C\Hid of the component restricted to the visible interface: s©InOutC \Hid ∈ Ex C\Hid if s ∈ Ex C

Obviously, as composition, abstraction is commutative and associative.


139

Bat?Lo,But?Up: Err!LV,Mot!Zr

Bat?Lo,But?Dn: Err!LV,Mot!Zr

But?Dn:Mot!Zr,Err!OK

Up

But?Up:Mot!Zr,Err!OK

Stop Bat?Hi,But?Up: Mot!Up,Err!OK

But?Hd: Mot!Hi,Err!OK

Down Bat?Hi,But?Dn: Mot!Lo,Err!OK

But?Hd:Mot!Zr,Err!OK

But?Hd: Mot!Lo,Err!OK

Figure 8.4: Behavior of the Window Control Component Using composition and hiding, networks of components as shown in Figure 8.1 are constructed in approaches like AutoFocus [Sch04]. Since in those approaches the composition of a system S out of subcomponents C1 , . . . Cn and the hiding of internal variables is performed in a single step, in the following the combined form t©InOut S ∈ Ex S ⇔

�

i=1,...,n

t©InOut Ci ∈ Ex Ci

(8.1)

is used to characterize the behavior of a network of components. −−−→∗ In following, instead of using the set-based notation Obs C ⊆ Var C from Subsection 8.3.1 for the observations of a component C with interface Var C , an equivalent predicate-based −−−→∗ notation C : Var C → B is used via the characteristic predicate C(t) ⇔ t ∈ Ex C

Test Case Specification Intuitively, a test case describes an observation of a component or system, i.e., a sequence of values sent and received on the interface of a component or systems. Since above the behavior of a component or system is described as a set of observations about it, a test case simply is an element of that set. While basically such an element can be described by a simple (linear) transition system, often special diagrams are used. Graphically, a test case can, e.g., be specified using variations of Message Sequence Charts or Sequence Diagrams. Figure 8.5 shows the representation of such a test case, using timed Extended Event Traces as introduced in [SH99]. The test case description consists of

140

Chapter 8. Model-Based Test Case Integration • a labeled life line described by a vertical line for the component participating in the test case, indicating the sequence of observations from top to bottom; e.g., the life line of the Error Store component • a set of interactions depicted as labeled arrows describing the exchange of data between the participating component as well as its environment; e.g., receiving the value Rs via variable Req from the environment (or test bed), or sending the value No via variable Res to the environment (or test bed) • a set of time regions delimited by dashed lines collecting simultaneous interactions within those regions; e.g., the region containing the simultaneous receiving of No and LV via Req and Err, resp., as well as the sending of OK via Res

Note that this technique can also be applied to describe the interaction between several components as well as their environment. Figure 8.6 shows such a description for a sequence of interactions of Error Store, Diagnose Management and Window Control. Formally, such a diagram can be described as an observation (or set of observations) about the interface of the participating components; the diagram describes a sequence (or set of sequences) of states, with each state assigning a value to an interface variable according to its corresponding time region. Thus, e.g., Figure 8.5 describes an observation of length 5, with the third state assigning the values OK, No, and LV to the variables Res, Req, and Err, resp. In the setting of components with input and output variables as described above, the description of a test case consists of two parts: 1. the specification of the input signals received by the system under test from the environment during the execution of the test 2. the specification of the output signals sent from the system under test to the environment during the execution of the test The system under test satisfies this test case, when the output actually provided by the system corresponds to the output prescribed by the test case, given the system received the input prescribed by the test case. Similar to the description of the components, a predicate-based notation is also used for test case via def

T (t) = t©In C ∈ Ex T ©In C ⇒ t©Out C ∈ Ex T ©Out C for a set Ex T characterizing the behavior specified by a test case for a component C with input variables In and output variables Out.3

8.3.2 3

Operationalization: Test Case Integration

The restriction t©Var is extended to restrictions on sets of sequences via element-wise application.


141

ErrorStore Req.No Err.OK Req.Rs Err.OK

Res.No

Res.No

Res.OK Req.No Err.LV Res.No Req.Vt Err.OK Res.Ft Req.No Err.OK

Figure 8.5: Reset-Set-Query-Test Case of the Error Store Applying the content model to the definition of the behavior of a single component as well as the composition of components to an integrated system on the one hand, and the definition of a test case specification, provides the formalization of the products of integration testing. In this subsection, this formalization is now operationalized by defining the validity of a test case of a component as well as introducing the concept of an integrated test case. By exploiting the possibilites of synthesizing solutions from the content model, in the next section, this operationalization can be used to tackle the problem of generating such an integrated test case. Test Case Verification Intuitively, a test case and its graphical representation is interpreted as an observation – or, more generally, a set of observations – about the component under test that correspond to the prescribed behavior, i.e., with either an input differing from the prescribed input or an output corresponding to the prescribed output. Thus, a test case characterizes a possible sub-behavior of that component under test; it therefore is a subset of all the expected observations of the component, corresponding to an existential interpretation of a sequence diagram [DH01].

142

Chapter 8. Model-Based Test Case Integration Window Control

Mot.Zr Bat.Hi But.Up Mot.Hi Bat.Lo But.Up Mot.Zr Bat.Hi But.Up Mot.Hi Bat.Hi But.Up Mot.Hi Bat.Hi But.Up Mot.Hi Bat.Hi But.Up

Diagnose Managment

ErrorStore

Res.No

Sts.OK

Err.OK

Req.No

Dia.Rs

Err.OK

Res.No Req.Rs

Sts.No Dia.No

Res.OK

Sts.No

Err.LV

Res.No Err.OK

Dia.No Sts.No Dia.No

Req.No Res.No

Err.OK

Sts.OK

Req.Vt Res.Ft

Err.OK

Dia.Vt

Req.No

Req.No

Sts.Ft Dia.No

Figure 8.6: Composed Observation of ErrorStore, DiagnoseManagement, WindowControl Consequently, a test case is valid for a given component if the set of observations corresponding to the test case is contained in the set of observations corresponding to the behavior of the component under test. If interpreting the description of the test case as well as the behavior of the component as predicates over observations over the alphabet of the component, the following definition of the validity of a test case is obtained. Formally, a system or component C satisfies a test case T if −−−→∗ ∀t ∈ Var C .C(t) ⇒ T (t)

(8.2)

For example, the sequence diagram in Figure 8.5 shows a possible behavior of the Error Store specified by the transition system of Figure 8.2. Test Case Integration In the following, components C and B are subcomponents of system A, with interfaces Var C , Var B , and Var A , resp., where Var A = Var B ∪ Var C . Furthermore, C is assumed to be completely integrated into A, i.e., having no direct connection to the environment of


143

A; Figure 8.1 shows an example of such a situation with C corresponding to ErrorStore, B corresponding to DiagnoseManagement and WindowControl, and A corresponding to their composition. The following definition, theorem, and proof can be easily extended to the more general case with C being only partially integrated. As mentioned in Section 8.1, during integration the interface of a component C embedded into the overall system might not be directly observable. Therefore, to ensure a certain property given in form of a test case T , indirect observation may be needed. Intuitively, the suggested approach provides a test case S for the overall system – consisting of C and the rest of the system B – such that if the system under test fulfills that test case S, also C must fulfill test case T . This concept of a test case for a component, integrated into a overall system to deduce a test case for the complete system, is captured in the following definition, again interpreting a test case as well as system specification as a predicate over the observations corresponding to the test case and system specification, resp. Formally, a test case S is a test case for T integrated into B if def

S(s) = ∀t ∈ Var ∗B .(s = t©Var C ∧ B(t)) ⇒ T (t©Var C )

(8.3)

For example in the case of the power window implemented by the network of ErrorStore, DiagnoseManagement, and WindowControl as shown in Figure 8.1, the reset-set-query test case shown in Figure 8.5 cannot be directly validated since the interface of ErrorStore is completely hidden within the control unit. Any observation on its ports Err, Req, and Res can only be made indirectly over the interface of the control unit. The explicit characterization of an integrated test case S given by 8.3, which is especially suited for the application of text case generation as shown in Section 8.4, can also be equivalently characterized more implicitly: S(t©Var A ) ⇔ (B(t©Var B ) ⇒ C(t©Var C )

(8.4)

This characterization will be used in the following to verify the intended properties of an integrated test case. Thus, to verify that Error Store actually satisfies the behavior prescribed by the component test case, a second test case is needed, which is • ensuring the validity of the test case for Error Store • relying only on the behavior of Diagnose Management and Window Control, but not on the behavior of Error Store • reading and writing the values of Err, Req, and Res through the interface of the control unit.

144


Figure 8.6 shows the description of such an integrated test case. The greyed-out parts of the test case description correspond to execution of the reset-set-query test case of Error Store, which is not directly observable from the interface of the control unit; the solid parts correspond to the reading and writing of ports at the interface of the unit, performed, e.g., by the test-bed for the control unit. This is reflected in the life lines of the integrated test case. While the interactions attached to the life line of Error Store correspond to the component test case shown in Figure 8.5, the interactions attached to the life lines of Diagnose Management and Window Control reflect their corresponding behavior as described by the transition systems in Figures 8.3 and 8.4. If the values of the input ports Bat, But, and Dia are written as described by the integrated test case, the behaviors of Diagnose Management and Window Control ensure that the corresponding values of the internal ports Err and Req are assigned to the values prescribed by the component test case. Symmetrically, the behavior of Diagnose Management (and Window Control) ensures that if the values of the output port Sts (and Mot) are read as described by the integrated test case, the values of the internal port Res are assigned to the values prescribed by the component test case. Integration Application A system test executable in a test-bed for the control unit can be obtained from Figure 8.6 simply by removing the greyed-out part corresponding to the component test. Note that the validity of the system test ensures the validity of the component test: An integrated test case S actually is a positive system test for the component test, i.e., component C satisfies test case T if the system consisting of B and C satisfies S. This follows immediately using first-order logic: Assuming that • the system under test A consists of B and C • the system under test A satisfies test case S • S is a test case for T integrated into B we then can conclude that • C satisfies test case T by means of (8.2, 8.1) ⇒ ∀t.(B(t©Var B ) ∧ C(t©Var C )) ⇒ S(t©Var A ) (8.4) ⇒ ∀t.(B(t©Var B ) ∧ C(t©Var C )) ⇒ (B(t©Var B ) ⇒ T (t©Var C )) ⇒ ∀t.(B(t©Var B ) ∧ C(t©Var C )) ⇒ T (t©Var C ) ⇒ ∀t.B(t©Var B ) ⇒ (C(t©Var C )) ⇒ T (t©Var C )

8.4. Application: Integration Generation

145

and thus (8.2) also holds for C and T , within the context of B. Note that an integrated test case may not exist, e.g., because B cannot ensure that only input values for C are used as required by T based on input values delivered by the environment; or because B cannot ensure that only output values of C are provided as prescribed by T based on output values delivered to the environment. In such a case, only the trivial solution S(t) = F exists. Furthermore, the invalidity of the system test ensures the invalidity of the component test: A nontrivial integrated test case S actually is a negative system test for the component test, i.e., component C does not satisfy test case T if the system consisting of B and C does not satisfy S. Again, the proof can be preformed immediately using first-order logic: • the system under test A consists of B and C • C does satisfy test case T • S is a nontrivial test case for T integrated into B we then can conclude that • the system under test does satisfy test case S by means of (8.2) ⇒ ⇒ ⇒ (8.4, 8.1) ⇒

∀t.C(t©Var C ) ⇒ T (t©Var C ) ∀t.(B(t©Var B ) ∧ C(t©Var C ) ⇒ T (t©Var C ) ∀t.(B(t©Var B ) ∧ C(t©Var C ) ⇒ (B(t©Var B ) ⇒ T (t©Var C )) ∀t.A(t©Var A ) ⇒ S(t©Var A )

and thus (8.2) also holds for A and S.

8.4

Application: Integration Generation

In this section, the notion of an integrated test case, introduced in Section 8.3, is applied in a tool-supported development process. First, the automatic generation of integrated test case using model checking is illustrated. Then, the methodical application in a process is sketched.

8.4.1

Implementation: Generation Automation

To provide tool-support for the generation of integrated test cases, the model of component test cases – as provided in Subsection 8.3.1 – must be implemented in a way that enables the mechanization of their integration – as introduced in Subsection 8.3.2 – using a suitable framework. In the following, the use of a symbolic model checker for the implementation and mechanization is demonstrated.

146


WS1S Formalization To effectively use the definition of integrated test cases, (automatic) support for the generation of test cases is necessary. Since behavior is defined by (possibly infinite) sets of finite traces, test cases are defined as elements of such sets, and integrated test cases are defined via first-order expressions over those sets, a trace-based formalism is best-suited. Therefore, as in case of the analysis of composed modular functions in Chapter 7, here also WS1S (weak second order monadic structure with one successor function) is used to implement automatic test case generation. This formalism is, e.g., supported by the model checker Mona [KM01]. Using WS1S, behavior is specified by predicates over observation traces, which are – as defined in Subsection 8.3.1 – sequences of states, i.e. sequences of assignment of values to variables. Intuitively, these predicates are built up from the most elementary propositions about observations, declaring that a variable has a certain value at a specific point in time in a observation. E.g., looking at the observation corresponding to the reset-set-query-test case in Figure 8.5, a suitable proposition is “variable Req has value Vt in the fourth state”. Using this approach, a trace can be precisely described by characterizing the states, for which a certain variable has a specific value. E.g., in the above example, a part of the description is characterized by “variable Req has value No in states 0,2,4, value Rs in state 1, and value Vt in state 3 ” (numbering states beginning with 0). Using this approach, predicates are defined by characterizing a trace via the sets of state indices, for which these basic propositions – linking variables and values – hold. WS1S provides variables (and quantors) over sets of indices, called second-order variables (or quantors) in contrast to zero-order and first-order variables (quantors) for Booleans or indices. Using these second-order variables for sets corresponding to all combinations of variables and values, the above test case can be formalized as pred ErrorStoreTest( var2 ErrOK, var2 ErrLV, var2 ReqNo, var2 ReqVt, var2 var2 ResNo, var2 ResOK, var2 (0 in ErrOK & 0 in ReqNo & (1 in ErrOK & 1 in ReqRs & (2 in ErrLV & 2 in ReqNo & (3 in ErrOK & 3 in ReqVt & (4 in ErrOK & 4 in ReqNo &

ReqRs, ResFt) = 0 in ResNo) & 1 in ResNo) & 2 in ResOK) & 3 in ResNo) & 4 in ResFt);

with var2 declaring second-order parameters, and e.g., ReqNo corresponding to the set of indices characterizing states with Req = No.4 Using the same principle, also the observations of transition-systems can be formalized in a similar fashion, leading to corresponding 4

For reasons of readability disjointness assertions like ReqNo inter ReqRs ensuring unique signal values are skipped here.


147

predicates for WinCtrl and DiagMgt for the WindowControl and DiagnoseManagement components. The definition of an integrated test case in Section 8.3.2 can be directly implemented in WS1S, allowing an automatic construction of the corresponding trace using the witness functionality provided by Mona: pred SystemTest( var2 BatLo, BatHi, var2 ButDn, ButHd, ButUp, var2 DiaVt, DiaRs, DiaNo, var2 MotLo, MotZr, MotHi, var2 StsNo, StsOK, StsFt) = all2 ErrOK, ErrLV: all2 ReqNo, ReqVt, ReqRs: all2 ResNo, ResOK, ResFt: (( WinCtrl(BatLo, BatHi, ButDn, ButHd, ButUp, MotLo, MotZr, MotHi, ErrOK, ErrLV) & DiagMgt(RqSRd, RqSBs, DiaNo, DiaVt, DiaRs, ResNo, ResOK, ResFt, ReqNo, ReqVt, ReqRs, StsNo, StsOK, StsFt)) => ErrorStoreTest(ErrOK, ErrLV, ReqNo, ReqVt, ReqRs, ResNo, ResOK, ResFt));

Observation Synthesis To effectively generate an observation, the witness functionality of model checkers can be exploited. By use of this functionality, the model checker selects an element from a satisfiable, i.e., non-empty model. In case of WS1S, Mona selects a shortest observation, satisfying the predicate characterizing the integrated test case. For example, using the witness functionality of Mona and applying it to the example of the Error Store component, the sequence diagram in Figure 8.5 can be synthesized. Using the above predicate SystemTest, Mona can check for its satisfiability, returning the following witness: BatLo BatHi ButDn ButHd ButUp DiaVt DiaRs DiaNo

= = = = = = = =

{1} {0,2,3,4,5} {} {} {0,1,2,3,4,5} {2} {0} {1,3,4,5}

148 MotLo MotZr MotHi StsNo StsOK

Chapter 8. Model-Based Test Case Integration = = = = =

{} {0,2} {1,3,4,5} {1,2,4} {0,3} StsFt = {5}

This corresponds to the observation in Figure 8.6, using the notion for sequence diagrams. Note that instead of deducing an observation about the overall system from a given observation of a component plus the remainder of the system, also the opposite approach – deducing the required component behavior from the observed system behavior – has its merits in the context of system evolution. This is especially helpful in the context of fault localisation, e.g., when trying to identify possible faulty behavior of a changed component that can result in a faulty behavior at system level, identified during the testing of the otherwise unchanged system. To solve that problem of deducing a component observation from a system observation as well as the behavioral specification of the rest of the system, the same formalizations and techniques can be applied.

8.4.2

Method: Integration Automation

The application of test case integration consists of a two-step method: First, the specification of a test case for the component under test – e.g., given by a sequence diagram – is integrated into the specification of the rest of the system - e.g., given by an architectural description as well as the behavior of the remaining components – using the approach described in the previous subsection. Then, the instantiation of the obtained integrated test case is verified with respect to the actual implementation. To illustrate the application, the integration of a changed Error Store component in an otherwise unchanged Power-Window Control Unit system is demonstrated. Test Generation Figure 8.7 shows the specification of the overall system architecture using AutoFocus and the AutoFocus description techniques: A System Structure Diagram to define the architecture of the Power Window Control, State Transition Diagrams to define the behavior of the Window Control component and the Diagnose Management (not shown), an Extended Event Trace to define the test case for the Error Store component, as well as the Data Type Definitions for the signals (not shown). Based on these specifications, the corresponding WS1S formalizations can be automatically generated along the lines presented in the previous subsection. Adding the WS1S-definition of the integrated test case, the complete specification is handed over to the Mona model checker for processing. If a non-trivial solution exists, a suitable shortest test case is generated; otherwise, the user is informed that no suitable test case can be generated since the specification of the integrated test case is unsatisfiable.


149

Figure 8.7: AutoFocus-Model of the Power Window Control

Test Execution Once the integrated test case has been generated, the behavior of the overall system – containing the component under test – has to be verified with respect to the test case, to show whether the overall system – and therefore also the component under test – respects the prescribed behavior. Figure 8.8 shows the actually implemented behavior of the Error Store component. It deviates from the intended behavior – as described in Figure 8.8 – in the output generated during the registration of a low voltage error Err?LV and an empty request Req?No when changing from state Normal to state Failure: while the intended behavior is the provision of an empty result Res!No, the actual behavior is the provision of the OK result Res!OK. To check whether the implemented system actually satisfies the integrated test case, the implementation – e.g., in form of an electronic control unit – is embedded into test environment allowing to write the inputs and read the outputs at the system interface and thus to execute the – instantiated – test case. To instantiate the test case, its abstract input signals – e.g., the diagnostic command signals Vt, Rs, No – are translated in corresponding concrete binary signals – e.g., 0x00, 0x01, 0x02 – and each round sent to the

150

Chapter 8. Model-Based Test Case Integration Req?Vt,Err?OK :Res!OK

Req?Vt:Res!Ft

Req?No,Err?LV: Res!OK

Req?Rs,Err?OK: Res!OK

Normal

Req?Vt,Err?LV: Res!OK

Req?Rs,Err?LV: Res!OK

Failure

Req?Rs, Err?LV:Res!OK Req?Rs,Err?OK: Res!OK

Req?No,Err?OK: Res!No

Req?No:Res!No

Figure 8.8: Defect Behavior of the Error Store Component implementation via the test bed. Similarly, the concrete binary signal received each round are translated back to abstract signals. Comparing the abstract output values obtained through the test environment with the outputs prescribed by the integrated test case shows whether the system under test satisfies the test case. In case of the defect Error Store component, the observation shown in Figure 8.9 is obtained, demonstrating that the system under test does not satisfy the integrated test case. Note that the test result is only conclusive in case the remainder of the system actually respects the specified behavior.

8.5

Conclusion: Test Case Integration

The previous sections gave a detailed account of the basics and techniques supporting an automated method for integrating component tests into system tests. In this section, a short summary of the presented approach is given. Furthermore, it is set into perspective to other work on automatic test case generation.

8.5.1

Summary: Test Case Integration

In the previous sections, an approach was introduced for the automatic generation of test cases for integrating a component into a larger overall system. This approach allows to combine a given test case for a component of a system with the behavioral description of the rest of the system, to analyse the behavior of that component without direct access to the interface of the component. This combination delivers a test case executable at the interface of the overall system, which verifies that the component satisfies the given component test case in case that the overall system satisfies the resulting system test case.

8.5. Conclusion: Test Case Integration

Window Control

Mot.Zr Bat.Hi But.Up Mot.Hi Bat.Lo But.Up Mot.Zr Bat.Hi But.Up Mot.Hi Bat.Hi But.Up Mot.Hi Bat.Hi But.Up Mot.Hi Bat.Hi But.Up

151

Diagnose Managment

ErrorStore

Res.No

Sts.OK

Err.OK

Req.No

Dia.Rs

Err.OK

Res.No Req.Rs

Sts.No Dia.No

Res.OK

Sts.No

Err.LV

Res.OK Err.OK

Dia.No Sts.OK Dia.No

Req.No Res.No

Err.OK

Sts.OK

Req.Vt Res.Ft

Err.OK

Dia.Vt

Req.No

Req.No

Sts.Ft Dia.No

Figure 8.9: Deviation from Integrated Testcase caused by defect Error Store Component

152


A typical area for the application of such an approach is, e.g., the construction of embedded software; here, on the implementation level often no means are provided of directly observing the interface of a component integrated in a larger system. This approach is especially useful in the context of system evolution, when only the component under test has been altered, leaving the rest of the system unchanged. While the infra structure of symbolic model checkers often does not scale for the analysis of systems composed from several components, the approach proves to be feasible in the domain of reactive body control using enumeration data types for signal and state variables. Since the tool-supported method allows a stepwise construction of the integrated test case, avoiding an explicit construction of the complete behavior of the remaining system, only the relevant ‘cone of behavior’ is built from the integrated test case. Thus, even integrated test cases with up to hundred interactions can be constructed within a time-range of seconds, making the approach suitable for practical application.

8.5.2

Related Work: Test Case Generation

In this chapter the use behavior synthesis in test case derivation was illustrated generating tests on the system level for testing a sole component – using the explicit construction of the content model of system under development with the help of a model checking tool. On component level, model-based test case generation by model checking has been investigated in different approaches: In [CSE96] the SPIN model checker is used to verify execution traces and to generate further test cases. Ammann et al. generate test cases by using the SMV model checker on mutants of the original specification [ABM98]. In [RH01] model checking is used to generate test cases fulfilling structural coverage on the test model. A similar approach is presented in [HdMR04]. For test case generation in general various further techniques exist, as for example using constraint logic programing [PL01]. Regardless of the specific technique, model-based test generation techniques generally assume that the test model is given at the interface level of the system under test and the SUT’s interface is also the interface for test case execution. In contrast to these approaches the presented method here uses test cases over the component interface and extends these test cases to the interface of a whole system in which the component is integrated in. Using model checking allows to decide if a test case is able to unambiguously verify intended behavior or detect errors caused by the component under test (and not by other parts of the system). The described technique in this paper is focused on supporting issues of integration testing. Other approaches on integration testing include methods based on coverage criteria for integration testing like [HS91] (data-flow coverage) or [JO95] (coverage based on component coupling). In [DMM01] mutation testing by mutants of the coupling on the internal interfaces is described as a method for integration testing. [JJBP05] gives an overview of various techniques of component testing, which are able to be applied by the component user during system integration.

Chapter 9 Conclusion Even though the term ‘Model-Based Software Engineering (MBSE)’ may lead to the impression that computer science and especially software engineering just recently discovered the use of models in the software and system development, actually, it is not justified to speak of a fundamental change of paradigms: The use of mathematics and logics to model soft- and hardware has been a core component of the foundations of computer science. Furthermore, in software engineering the importance of models beyond code – especially for the construction of systems of industrial size – has been common-place not only since the definition of entity relationship models (E/R) by Peter Cheng in 1976 or the introduction of data flow models within the Structured Analysis (SA) by Tom DeMarco in 1978. Nevertheless, model-based software development is more than just a buzzword, as shown in the previous chapters and summarized below: It is not about the fact that models are used, but how they are applied. Using explicit, formalized and domain-specific models for the concepts and the contents of a system under development combined with suitable analysis and synthesis techniques can substantially enhance the engineering process compared to the use of those general-purpose, implicit, or informal models mentioned above. However, as also discussed below, while model-based software development has successfully addressed many fundamental and practical issues, several issues of industrial application are still left open.

9.1

Summary

As shown in the previous chapters, the capability of models to provide a precise and formalized description of a system under development, and the resulting possibility to – manually or automatically – investigate and manipulate these models to analyse an existing or synthesis a new model lies at the core of model-based system development. This has an essential impact on the industrial application concerning the use of models: • Models can be used in all phases of the development processes, starting with the specification of requirements during analysis, including the construction of compo153

154

Chapter 9. Conclusion nents during design, and ending with the definition of test cases during integration and acceptance test. • Models can be used simultaneously for manifold purposes, including communication to the customer, identification of specification defects, and execution and transformation to implementations, as well as support of quality assurance and test.

Thus, the use of models, as demonstrated in the previous chapters, is an increasingly influential economic factor in system development: • Models allow to reduce the complexity of a system by consistent modularization of this system in various views (e.g., functional, logical, and technical view or structural, data, and behavioral view). • Models allow to improve the quality of the system under development using constructive techniques by means of their restricting nature (e.g., structured requirements) as well as analytical techniques by means of checking properties of the model (e.g., modeling standards). • Models allow to increase the efficiency of the development process by early quality assurance (e.g., simulation), automated development steps (e.g., code generation or test case instantiation), and improved reuse (e.g., pattern libraries). Of course, the use of explicit models adds the effort of building and maintaining these models. However, as shown in the previous chapters, in industrial applications these explicit and formalized models generally correspond to those more implicit or informal models used, e.g., in requirement or design specifications and built without the help of concept or content models. Here, a model-based engineering process can leverage the limited use of those models by the additional possibilites of precise and formalized descriptions.

9.2

Open Questions

In spite of the achieved results, the potential of models exceeds the techniques introduced in the previous chapters. For a more thorough exploitation, the above-mentioned principles allow and require additional methods of application. Especially for the industrial applicability, the question of the scalability of the presented approaches – both on the concept and the content level – is decisive. While on the conceptual level, investigating and manipulating models generally pose no major problem, analyzing and synthesizing models on the content level still cannot be tackled easily, especially with data- or computation-intensive behavior. Here, the question of sound abstractions and modular compositions need to be solved to ensure better applicability. Furthermore, with a more widespread use of industrial-scale models throughout the development process, ‘classical’ problems found in code-oriented development start to impact a model-based development in a similar manner: The legacy of long-living models requires

9.2. Open Questions

155

to address issues of model evolution, model-versioning, or reuse of models. However, the use of concept-rich, domain-specific models with a precise interpretation, forming the basis of model-based system development, suggests that existing solutions for a code-based development, relying on code providing a weaker-structured, more generic form of representation, can be adapted and even extended, leading to an increasingly efficient development of high-quality systems.

156

Chapter 9. Conclusion

Bibliography [ABM98] P. Ammann, P. Black and W. Majurski. Using model checking to generate tests from specifications. Formal Engineering Methods, 1998. Proceedings. Second International Conference on, pages 46–54, December 1998. [AP08]

M. Alanen and I. Porres. A metamodeling language supporting subset and union properties. Software and System Modeling, 7(1):103–124, 2008.

[Aut04a] AutoFOCUS 2 website, 2004. www4.in.tum.de/ãf2. [Aut04b] AutoRAID website, 2004. www4.in.tum.de/ãutoraid. [BHS99] M. Broy, F. Huber and B. Schätz. AutoFocus - Ein Werkzeugprototyp für die Entwicklung eingebetteter Systeme. Informatik Forschung und Entwicklung, 14(3), 1999. [BKM07] M. Broy, I. H. Krüger and M. Meisinger. A formal model of services. ACM Transactions on Software Engineering Methodology, 16(1), 2007. [BLSS00] P. Braun, H. Lötzbeyer, B. Schätz and O. Slotosch. Consistent Integration of Formal Methods. In Proc. 6th Intl. Conf on Tools for the Analysis of Correct Systems (TACAS), LNCS 2280, 2000. [BS01]

M. Broy and K. Stoelen. Specification and Development of Interactive Systems. Springer, 2001.

[CM00]

M. Calder and E. H. Magill. Feature Interaction in Telecommunication and Software Systems IV. IOS Press, 2000.

[CR06]

E. Clayberg and D. Rubel. Eclipse: Building Commercial-Quality Plug-ins. The Eclipse Series. Addison Wesley Professional, 2006. Second Edition.

[CSE96] J. Callahan, F. Schneider and S. Easterbrook. Automated software testing using modelchecking. In Proceedings 1996 SPIN Workshop, August 1996. Also WVU Technical Report #NASA-IVV-96-022. [DH01]

W. Damm and D. Harel. LSCs: Breathing Life into Message Sequence Charts. Formal Methods in System Design, 19(1), 2001.

[DJH+ 08] F. Deissenboeck, E. Juergens, B. Hummel, S. Wagner, B. M. y Parareda and M. Pizka. Tool Support for Continuous Quality Control. IEEE Software, 25(5), 2008. 157

158

BIBLIOGRAPHY

[DMM01] M. Delamaro, J. Maidonado and A. Mathur. Interface Mutation: An approach for integration testing. IEEE Transactions on Software Engineering, 27(3):228– 247, 2001. [DOR05] E. Denti, A. Omicini and A. Ricci. Multi-paradigm Java-Prolog Integration in tuProlog. Science of Computer Programming, 57(2):217–250, 2005. [DP04]

C. Denger and B. Paech. An Integrated Quality Assurance Approach for Use Case Based Requirements. In B. Rumpe and W. Hesse, editors, Modellierung 2004. Springer, 2004.

[EFLR99] A. Evans, R. B. France, K. Lano and B. Rumpe. The UML as a Formal Modeling Notation. In UML’98: Selected papers from the First International Workshop on The Unified Modeling Language, volume 1618 of Lecture Notes In Computer Science, pages 336–348. Springer, 1999. [Fow00] M. Fowler. Refactoring. Improving the Design of Existing Code. Addison-Wesley, 2000. [FR06]

T. Farkas and H. Röbig. Automatisierte, werkzeugübergreifende Richtlinienprüfung zur Unterstützung des Automotive-Entwicklungsprozesses. In B. Rumpe, H. Giese, T. Klein and B. Schätz, editors, Modellbasierte Entwicklung eingebetteter Systeme, 2006.

[FS97]

M. Fowler and K. Scott. UML Distilled. Addison-Wesley, 1997.

[GGL05] L. Grunske, L. Geiger and M. Lawley. A Graphical Specification of Model Transformations with Triple Graph Grammars. In A. Hartman and D. Kreische, editors, Model Driven Architecture, volume 3748 of LNCS. Springer, 2005. [GLR+ 02] A. Gerber, M. Lawley, K. Raymond, J. Steel and A. Wood. Transformation: The Missing Link of MDA. In Graph Transformation, volume 2505 of LNCS, 2002. [HdMR04] G. Hamon, L. de Moura and J. Rushby. Generating efficient test sets with a model checker. In Software Engineering and Formal Methods, 2004. SEFM 2004. Proceedings of the Second International Conference on, pages 261–270, 2004. [Hei02]

C. L. Heitmeyer. Software Cost Reduction. In J. J. Marciniak, editor, Encyclopedia of Software Engineering. 2002.

[Hen00]

T. A. Henzinger. Masaccio: A Formal Model for Embedded Components. In Proceeding of the First International IFIP Conference of Theoretical Computer Science, pages 549–563. Springer, 2000. LNCS 1872.

[HKS+ 05] C. Hood, A. Kre´’s, R. Stevenson, G. Versteegen and R. Wiebel. iX-Studie Anforderungsmanagement. Heise Zeitschriften Verlag, 2005. [Hoa83]

C. A. R. Hoare. Communicating Sequential Processes. Communications of the ACM, 26(1):100–106, 1983.

BIBLIOGRAPHY

159

[HP98]

D. Harel and M. Politi. Modeling Reactive Systems with Statecharts. MacGrawHill, 1998.

[HS91]

M. Harrold and M. Soffa. Selecting and using data for integration testing. Software, IEEE, 8(2):58–65, March 1991.

[HSE97a] F. Huber, B. Schätz and G. Einert. Consistent Graphical Specification of Distributed Systems. In Industrial Applications and Strengthened Foundations of Formal Methods (FME’97), LNCS 1313, pages 122–141. Springer Verlag, 1997. [HSE97b] F. Huber, B. Schätz and G. Einert. Consistent Graphical Specification of Distributed Systems. In Industrial Applications and Strengthened Foundations of Formal Methods (FME’97), LNCS 1313, pages 122–141. Springer Verlag, 1997. [IEE98a] IEEE Software Engineering Committee of the Computer Society. IEEE Guide for Developing System Requirements Specifications. IEEE Computer Society, 1998. IEEE Standard 1233-1998. [IEE98b] IEEE Software Engineering Committee of the Computer Society. IEEE Guide for Software Requirements Specifications (ANSI). IEEE Computer Society, 1998. IEEE Standard 830-1998. [Int98]

International Electrotechnical Commission. Functional safety of electrical/electronic/ programmable electronic safety-related systems, 1998.

[Int03]

International Organisation for Standardization. Road vehicles – Controller area network (CAN), 2003. ISO 11898.

[JAB+ 06] F. Jouault, F. Allilaire, J. Bézivin, I. Kurtev and P. Valduriez. ATL: a QVT-like transformation language. In OOPSLA ’06, pages 719–720. ACM Press, 2006. [JB06]

F. Jouault and J. Bézivin. KM3: a DSL for Metamodel Speci?cation. In R. Gorrieri and H. Wehrheim, editors, Formal Methods for Open Object-Based Distributed Systems, volume 4037 of Lecture Notes in Computer Science. Springer, 2006.

[JJBP05] M. Jaffar-ur Rehman, F. Jabeen, A. Bertolino and A. Polini. Software Component Integration Testing: A Survey. Technical Report 2005-TR-41, Consiglio Nazionale delle Ricerche, Istituto di Scienza e Technologie dell’Informazione "Alessandro Faedo" (ISTI), Pisa, Italy, 2005. [JO95]

Z. Jin and A. Offutt. Integration testing based on software couplings. Computer Assurance, 1995. COMPASS ’95. ’Systems Integrity, Software Safety and Process Security’. Proceedings of the Tenth Annual Conference on, pages 13–23, June 1995.

[Jon00]

C. Jones. Software Assessments, Benchmarks, and Best Practices. AddisonWesley, 2000.

[KKS07] F. Klar, A. Königs and A. Schürr. Model Transformation in the Large. In ESEC/FSE’07. ACM Press, 2007.

160

BIBLIOGRAPHY

[KM01]

N. Klarlund and A. Møller. MONA Version 1.4 User Manual. BRICS, Department of Computer Science, University of Aarhus, 2001.

[KS98]

G. Kontonya and I. Sommerville. Requirements Engineering: Processes and Techniques. Wiley, 1998.

[Lam02] L. Lamport. Specifying Systems. Addison-Wesley, 2002. [LL98]

B. Lee and E. A. Lee. Hierarchical Concurrent Finite State Machines in Ptolemy. In 1st International Conference on Application of Concurrency to System Design (ACSD ’98). IEEE Computer Society, 1998.

[LS06]

M. Lawley and J. Steel. Practical Declarative Model Transformation with Tefkat. In J.-M. Bruel, editor, MoDELS Satellite Events, volume 3844 of LNCS. Springer, 2006.

[LT89]

N. Lynch and M. Tuttle. An Introduction to Input/Output Automata. CWI Quarterly, 2(3):219–246, 1989.

[MÁ05]

F. Martínez and J. A. T. Álvarez. A Precise Approach for the Analysis of the UML Models Consistency. In J. Akoka, S. W. Liddle, I.-Y. Song, M. Bertolotto, I. Comyn-Wattiau, S. S.-S. Cherfi, W.-J. van den Heuvel, B. Thalheim, M. Kolp, P. Bresciani, J. Trujillo, C. Kop and H. C. Mayr, editors, Perspectives in Conceptual Modeling, volume 3770 of Lecture Notes in Computer Science. Springer, 2005.

[Mat02] The MathWorks. Using MATLAB, 2002. [Mat07] MathWorks Automotive Advisory Board. Control Algorithm Modeling Guidelines Using MATLAB Simulink, Simulink, and Stateflow, 2007. [Mil83]

R. Milner. CCS - A Calculus for Communicating Systems, volume 83 of Lecture Notes in Computer Science. Springer Verlag, 1983.

[Min01]

M. Minas. Spezifikation und Generierung graphischer Diagrammeditoren. Habilitation, Universität Erlangen-Nürnberg, 2001.

[Obj00]

Object Management Group, Inc. Meta Object Facility (MOF) Specification, 2000. http://www.omg.org/.

[OMG97] OMG. Object Constraint Language Specification. Technical Report 1.1, ad/9708-08, Object Management Group (OMG), http://www.omg.org, 1997. [OMG03] OMG. Initial submisison to the MOF 2.0 Q/V/T RFP. Technical Report ad/0303-27, Object Management Group (OMG), http://www.omg.org, 2003. [PBG01] K. Pohl, M. Brandenburg and A. Gülich. Integrating Requirements and Architecture Information: A Scenario and Meta-Model based Approach. In 17th International Workshop on Requirements Engineering: Foundation for Software Quality, 2001.

BIBLIOGRAPHY

161

[PL01]

A. Pretschner and H. Lötzbeyer. Model Based Testing with Constraint Logic Programming: First Results and Challenges. In Proc. 2nd ICSE Intl. Workshop on Automated Program Analysis, Testing and Verification (WAPATV’01), Toronto, 2001.

[RH01]

S. Rayadurgam and M. Heimdahl. Coverage based test-case generation using model checkers. In Engineering of Computer Based Systems, 2001. ECBS 2001. Proceedings. Eighth Annual IEEE International Conference and Workshop on the, pages 83–91, 2001.

[Roz97]

G. Rozenberg, editor. Handbook on Graph Grammars and Computing by Graph Transformation: Foundations. World Scientific, 1997.

[SAL03] J. Sprinkle, A. Agrawal and T. Levendovszky. Domain Model Translation Using Graph Transformations. In ECBS2003 - Engineering of Computer-Based Systems, 2003. [SBPM07] D. Steinberg, F. Budinsky, M. Paternostro and E. Merks. EMF: Eclipse Modeling Framework. Addison Wesley Professional, 2007. Second Edition. [Sch01]

B. Schätz. The ODL Operation Definition Language and the AutoFocus/Quest Application Framework AQuA. Technical Report TUM-I0111, TU München, 2001.

[Sch04]

B. Schätz. Mastering the Complexity of Embedded Systems - The AutoFocus Approach. In F. Kordon and M. Lemoine, editors, Formal Techniques for Embedded Distributed Systems: From Requirements to Detailed Design. Kluwer, 2004.

[Sch05]

B. Schätz. Building Components from Functions. In Proceedings 2nd International Workshop on Formal Aspects fo Component Software (FACS’05), Macao, 2005.

[SDP08] I. Stürmer, C. Dziobek and H. Pohlheim. Modeling Guidelines and Model Analysis Tools in Embedded Automotive Software Development. In B. Rumpe, H. Giese, T. Klein and B. Schätz, editors, Modellbasierte Entwicklung eingebetteter Systeme, 2008. [SH99]

B. Schätz and F. Huber. Integrating Formal Description Techniques. In J. M. Wing, J. Woodcock and J. Davies, editors, FM’99. Springer Verlag, 1999. LNCS 1709.

[SS03]

B. Schätz and C. Salzmann. Service-Based Systems Engineering: Consistent Combination of Services. In Proceedings of ICFEM 2003, Fifth International Conference on Formal Engineering Methods. Springer, 2003. LNCS 2885.

[SS08]

C. Soanes and A. Stevenson. Oxford Dictionary of English. 2008.

[Sta73]

H. Stachowiak. Allgemeine Modelltheorie. Springer, 1973.

[Tec05]

Technische Universität München. AutoFocus 2 Model and Model API – Developer Manual, 2005.

162

BIBLIOGRAPHY

[vL01]

A. van Lamsweerde. Goal-Oriented Requirements Engineering: A Guided Tour. In RE’01 - International Joint Conference on Requirements Engineering, 2001.

[VP04]

D. Varro and A. Pataricza. Generic and meta-transformations for model transformation engineering. In T. Baar, A. Strohmeier, A. Moreira and S. Mellor, editors, UML 2004. Springer, 2004. LNCS 3273.

[Wil06]

D. Wild. AutoFocus 2 Bilderbuch. Technische Universität München, 2006.