Using Graph Grammars for Modeling Wiring Harnesses - Springer Link

Using Graph Grammars for Modeling Wiring Harnesses – An Experience Report Albert Z¨ undorf1 , Leif Geiger1 , Ralf Gemmerich1 , Ruben Jubeh1 , J¨ urgen Leohold2 , Dieter M¨ uller3 , Carsten Reckord1, 1 Christian Schneider , and Sven Semmelrodt4 1

4

University of Kassel 2 Volkswagen AG 3 Sumitomo Siemens VDO Automotive AG

Abstract. The Fujaba project has created a light weight graph grammar approach allowing the use of graph grammar concepts in usual Java programs. Fujaba comes with visual editors for graph schemas / class diagrams, control structures / activity diagrams, and graph rewrite rules / extended object diagrams. Thereby the user may specify executable programs that are translated into complete Java programs without any need for further low level Java programming. In addition, Fujaba provides dedicated visual language support for scenario based testing. This is complemented with support for model versioning and distributed applications. Last but not least Fujaba provides model level debugging. This paper is an experience report applying Fujaba techniques for requirements analysis and implementation in an industrial project in the automotive industry. The considered project has created a tool for the design of car electronic systems. This project involved an enormous amount of domain knowledge. The challenge was to involve the domain experts in the analysis, design, and implementation activities such that the transfer of domain knowledge is fostered. This paper reports how we used graph grammar based Fujaba techniques and languages to achieve domain expert involvement.

1

Introduction

Modern software development processes, as e.g. the Rational Unified Process [JBR99], use textual use case descriptions for requirements elicitation. During further requirements analysis, analysis classes are identified and one may e.g. use collaboration diagrams or sequence diagrams in order to outline use case behavior. This is then further refined into design and implementation classes and into actual behavior implementation. This process may be executed iteratively, addressing small chunks of functionality one after the other. Due to our experiences, such a process requires decent skills in abstraction, object orientation, analysis, design, design patterns, etc. Frequently, the result of an object oriented analysis or design phase will be documented and discussed G. Engels et al. (Eds.): Nagl Festschrift, LNCS 5765, pp. 512–532, 2010. c Springer-Verlag Berlin Heidelberg 2010

Using Graph Grammars for Modeling Wiring Harnesses

513

using architecture diagrams or more specifically class diagrams. Unfortunately, class diagrams are quite abstract and their interpretation and the judgment of the represented design decisions requires special skills and training, too. While many computer scientists and professional software developers have these skills as part of their every day professional work, a project frequently involves a large number of other stakeholders like business managers, administrative experts, domain experts and potential system users. These people may have quite different backgrounds and skills. These different skills and the corresponding domain knowledge are of crucial importance for the success of the overall project. Unfortunately, many of these important people will have difficulties to interpret the information and design decisions contained in architecture and class diagrams. Thus, the domain experts are frequently not able to communicate their knowledge with the software experts, appropriately. In order to overcome these communication problems, the Fujaba Process proposes to use object diagrams or graphs or graph scenarios as an intermediate representation or analysis means during analysis, design and implementation, cf. [DGZ05, KNNZ00, FNTZ99]. Usual collaboration or sequence diagrams stay on a level of abstraction where certain components exchange certain messages in order to exemplify the internal process that realizes the considered use case, cf. [JBR99, BRJ99]. Our graph scenarios usually describe the internal process in much more detail. We employ concrete objects with concrete attribute values and concrete links or edges between each other. Thereby, we pinpoint the representation of certain domain information in our implementation model quite early in the development process. In the reported project, it turned out, that the design and implementation decisions outlined in graph scenarios were still easily recognized by our domain experts. Pinning down certain design and implementation aspects quite early then fertilized the further refinement and elicitation of related functional requirements, considerably. In multiple iterations, our domain experts used the refined designs to enhance their textual requirements descriptions until it became easy to implement them. As implementation language, the Fujaba approach uses programmed graph transformations, so-called Fujaba story diagrams. Since story diagrams use a graphical notation which is very close to our graph scenario notation, our domain experts were even able to review our implementation. This enabled very valuable feedback from our domain experts to the software developers. For the goals of the reported project cf. [GSZ et al. 05]. Note, this paper is an extended version of [ZLM et al. 06]. First, we have added more details. Second, we have added an explicit description of the Fujaba process. In addition, we made the relation to graph grammars more explicit. The following section gives a short overview of the Fujaba process and relates graph grammar terminology to object oriented terminology. Section 3 introduces the application domain and the software development project that serves as example in this paper. This is followed by the main section 4 showing how we applied our software development approach to the example application. After a

514

A. Z¨ undorf et al.

short discussion of related modeling languages the last section concludes with lessons learned.

2

The Fujaba Process FUP

The Fujaba process (FUP) is a light weight, iterative, use case driven process deploying graph grammar techniques for the development of object oriented applications. For each feature or functionality of the desired software, the Fujaba process proposes the following steps, cf. [DGZ05]: Step 1: Textual scenarios Once a feature has been identified, the desired functionality is outlined with the help of scenario descriptions in natural text. Such a scenario focuses on one concrete situation and on the steps that should be executed in this dedicated situation. To facilitate this step, we stay at the domain level, i.e. we do not yet map the application domain to the implementation domain. Step 2: Graph / model level scenarios: story boards For each scenario step, we now model an example graph (object structure) that reflects the relevant aspects of the described situation and we model the modifications of that graph that reflect the execution of the scenario step. We call a textual scenario with object models for each step a story board. A story board maps domain concepts to the domain of graphs or object structures thus achieving a large step towards implementation. However, to facilitate this modeling step, we stay at the level of example situations and we exploit that the textual scenarios have already been split into a number of smaller steps which are now easier to model. Note, due to our experiences, since our graph scenarios stay at the level of concrete example objects, even non IT experts are able to read and understand them, easily. However, to facilitate the recognition of graphs / object diagrams for non IT domain experts even more, we frequently use icons from the application domain to enrich the representation of objects. The domain experts grasp the semantics of such domain icons immediately. Step 3: Class diagram adaption Deriving a graph schema or a class diagram from an object diagram is a straight forward task. The result is a conceptual model / class diagram that covers the identified domain concepts. Usually, this conceptual model will be refined towards implementation aspects. For example, there will be extensions for implementation concepts and refactorings for the introduction of design patterns. Note, usually we do not bother non IT domain experts with these class diagrams. They are mainly of use for the software developers. Step 4: Graph or model implementation Our approach does not deploy a generic graph implementation or a generic graph database. Instead, our Fujaba tool provides a code generator that implements models using plain old Java objects/classes. However, our code generator uses a dedicated programming style for the implementation of bidirectional associations. This association implementation guarantees referential integrity while


515

still providing an excellent runtime efficiency. This referential integrity turns the used object structures into graphs. Alternatively, we also generate EMF ([EMF]) based model implementations. This enables the use of a large number of EMF based tools for our graphs. Step 5: Test derivation Once our class diagrams are implemented, our code generator turns the story boards into automatic JUnit tests, cf. [GZ05]. Basically, such a test creates the object structure modeling the start situation, triggers the described user actions and validates that the object structure shows the modifications described in the story board as the effects of the executed operations. Step 6: Textual algorithm design Now we are ready to design the desired functionality. To facilitate this complex development task, we start with the design of an appropriate algorithm on the domain level using natural text. Step 7: Model level algorithm design Once we have outlined the general algorithm, we go through its steps and refine them towards the level of our object model. This means, domain level sentences are refined to refer to model elements. At this step, we leverage that the general algorithm outline has already been done. Thus, we deal with one algorithm step after the other which facilitates this step, considerably. Step 8: Implementation The model level algorithm description is now implemented. While this could be done directly in Java, our approach proposes to use programmed graph rewriting for this approach. In Fujaba, we use activity diagrams for the modeling of control flow and enriched objects diagrams as notation for graph transformations. Our code generator translates this to Java code either based on our own simple model implementation or based on an EMF model implementation. Step 9: Algorithm validation Now we validate our implementation by running the JUnit tests derived from the story boards in step 5. Although this does not provide a systematic whitebox test, due to our experiences the scenario based tests achieve already a reasonable coverage of the implementation. If occasionally certain parts of the implementation are not covered by scenario tests, most of the time the programmer has already implemented alternative behavior which is not yet addressed by the provided scenarios. Our approach takes such uncovered implementation as an advice to build additional scenarios covering this not yet addressed behavior and to go back to the domain experts to discuss whether the implemented behavior for these special cases meets their expectations. Step 10: Refactoring Once the functionality has been validated, we may perform some structuring of our code and some refactorings as recommended in agile processes. Note, we use the Fujaba process since several years in our research projects and for the development of new features of the Fujaba tool itself. We also teach the Fujaba process and its underlying graph based techniques since 2003 in our

516


courses on programming methodologies at Kassel University. All these experiences resulted in many enhancements and refinements of the Fujaba process until we reached the state described above. While our experiences with the Fujaba process are very encouraging, its enhancement and the improvement of its tool support are ongoing work. However, one strength of the Fujaba process and its technologies is the high level of abstraction reached by the underlying graph concepts. Together with the scenario oriented approach, this facilitates the involvement of non IT domain experts, considerably. A striking example of a successful involvement of domain experts in the development of a complex expert system for the optimization of wiring harnesses is outlined in the remainder of this paper. Fujaba and the Fujaba process have been developed in the context of graph grammar theory. However, Fujaba and the Fujaba process are frequently used for object oriented modeling and implementation. In the domain of graph grammars, we use graph grammar terms like, node, edge, or graph. In the domain of object oriented modeling and implementation, we use OO terms like object, link, or object structure instead. Table 1 shows the relation between graph grammar terms and OO terms. Through the rest of this paper, we will use the OO terms.

3

The OBA Application

The considered example project is called OBA for ”Optimization of car electric system architectures” (in German: ”Optimierung von Bordnetz-Architekturen”). Our task was to develop a tool that enables a car manufacturer to optimize the costs of the electronic system within a car. The considered electronic system of a car includes actors (e.g. lights, motors, ...), sensors (e.g. on/off switches, temperature sensors, rotation sensors, ...), electronic control units (ECUs), fuses, and all the wires connecting these components. The costs of the electronic system of a car consist of the costs for the parts plus the costs for assembling them within the car plus the costs of extra material as e.g. cable ties or screws, etc. Prerequisites for the development of a car electronic system are usually the employed sensors and actors including their placement within the car. In addition, the geometry of the car body is usually already defined including possible spaces for the placement of ECUs and including all channels where cables may be laid and mounted. The placement of ECUs and the laying of cables has to respect a large number of additional constraints, e.g. some components must not be accessible from the outside (e.g. anti theft devices), some components should not get wet, some components should not get too hot (e.g. near the engine), some components may interfere with each other (electromagnetic compatibility). There are also robustness and security constraints, e.g. the cable diameters have to be designed according to the connected power consumption and fuses have to be designed to enable the desired power consumption but to prevent cable fire, the driving lights must not depend on a single fuse, etc.


517

Table 1. Graph terms vs. object oriented terms Graph Term node edge

OO Term object link or pointer

Remark

Generally, edges are bidirectional. To achieve this in OO programming languages like Java, Fujaba uses pairs of forward an backward pointers. graph object structure A set of objects related by links between these objects. graph object diagram We distinguish between runtime object structures and (UML) object diagrams, which are drawings of object structures used in documentation or in Fujaba for programming. graph scenario story board Sequence of object diagrams outlining the evolution of an object structure during the execution of an operation. graph schema class diagram Beyond graph schemas, class diagrams may also declare methods. graph rewrite rule story pattern In Fujaba, a story pattern is an object diagram extended by modification annotations. At runtime, the story pattern is matched against an appropriate part of the runtime object structure. The matched elements are then modified as specified by the modification annotations. programmed graph story diagram In Fujaba, story diagrams are UML activity ditransformation agrams where the activities hold story patterns. Story diagrams specify the control flow between story patterns. Story diagrams are attached to methods and thus provide the method implementations.

Fig. 1. An example car electric system

518


The main architectural decisions for a car electric system are how many ECUs it employs, where these ECUs are placed in the car and which control functionality is placed on which ECU. Similarly, the number and placement of fuse boxes have to be chosen. Depending on these decisions, the wiring of the car has to be routed to connect the ECUs with each other and with the sensors and actors they need to access and to provide the power supply to all components with minimal costs but respecting the car geometry and the corresponding electrical constraints. Our task was to develop tool support for the developers of car electronic systems enabling them to study alternative architectures with minimal effort and helping them to optimize the electronic system with respect to overall costs and e.g. weight. As a prerequisite for the optimization of a car electric system, in a first project phase we have developed a cost model that allows us to compute the overall costs of a chosen electric system and to analyze the gain or loss caused by an alternative architecture. In order to facilitate the development of alternative architectures, the second project phase has developed support for labor-intensive work as the configuration of ECUs and the routing for the wiring harness once the main architectural decisions have been done. In a third project phase, the OBA tool shall automatically generate and compare alternative architectures. In this paper we utilize the cost model to illustrate how Fujaba enabled us to involve the domain experts. This means, this paper deals mainly with the first project phase. The cost model requires an enormous amount of domain specific knowledge. This knowledge is provided by the industrial partners in this project, namely the Volkswagen AG, a car manufacturer or OEM, Siemens VDO, a supplier of ECUs and electronic components, and VW Bordnetze, a manufacturer for wiring harnesses. In addition, there were a PhD student and a post-doc in electrical engineering from the University of Kassel involved, who had the task to transfer the domain knowledge into the project. These engineers were part time supported by the professor for car electric systems at University of Kassel. The software engineering and software development part of the project was executed by two PhD students in computer science together with some student programmers part time supported by the professor for software engineering at University of Kassel.

4

The OBA Cost Model

Since we employ complex data structures for the optimization of the wiring harness and for the conception of ECUs, and due to our experiences, we decided to develop the OBA tool with an object oriented model using the Fujaba environment [Fu09, FNTZ99] and to generate the actual implementation in Java. The modeling of the OBA application started with the car body. On top of this we have build the wiring model and the models for the ECUs and for the software functions. This is the basis for the optimization algorithms.


519

In the OBA project one major source of complexity was the sheer amount of aspects that had to be addressed. For example the costs for the wiring harness included aspects like: – Cable costs depending on cable length and cable kind. – Costs of cable mounting elements depending on the crossed car areas and their respective mechanical stress. Some car areas may require additional mounting elements including the respective costs. – Costs of wire protection means. For example, different (humid) car areas require different wrapping techniques with different tape material. Since tape may be as expensive as wires, we had to compute the length of the required tape, exactly. – Costs and kinds of connectors. For each bundle of wires reaching an ECU or an actor or a sensor, we had to compute an appropriate connector. Depending on the cross section of the different wires, pins of appropriate sizes have to be used. However, the whole connector must not exceed a certain size e.g. the size of the ECU itself or the size of hatches where the bundle has to be threaded through. In addition, for a connector with a high number of pins, the physical force required to put the connector in the socket must not exceed a certain maximum. – Cables may be split at a certain point in order to reach multiple target points with the same signal. This is achieved using so-called splices. However, there are a number of restrictions on the fan-out of such a splice and on the environmental conditions of the car area where this splice is placed. – The costs of mounting the wiring harness depends on the accessibility of the corresponding car areas and on the kind and number of mounting elements that are used and on the number of connectors that have to be placed. – So called threading costs. If some cable bundle needs to be threaded through some car body hatch or some rubber spout, this requires mounting costs according to the number of connectors that are to be threaded and according to the so-called threading length. This list is far from completeness. Covering ECUs, fuse boxes, communication busses etc. involved similar lists. One of the main challenges of the OBA project was to structure all of these aspects appropriately. This required a close collaboration between the domain experts and the software engineers. 4.1

Applying FUP Steps 1 and 2

As proposed by the Fujaba process, we started the elaboration of required functionality with the help of textual scenarios and object diagram scenarios. At the beginning of the development, our domain experts came up with textual requirements descriptions as shown in Figure 2. These requirements where of course quite coarse grain and thus insufficient for further analysis, design and implementation. In addition, most other requirements descriptions were based on the car body description, e.g. the description of spatial constraints for ECUs

520


or for the diameter of cable bundles. The next layer of requirements was based on these two lower requirements layers and so on. Without a clear common understanding of the basic requirement layers, it became progressively harder to read and write new requirements on top of them. 2.1 The car body … The car body consists of different car areas representing units of assembly and units of similar environmental conditions. The changeovers between car areas require additional protection means against different environmental conditions, e.g. humidity. In addition, car area changeovers require special mounting efforts. …The car areas contain all kinds of mutually connected wire channels, cavities, etc. …

Fig. 2. First textual requirements on car bodies

To overcome these problems, we had to pinpoint the requirement layers such that a common understanding between domain experts and software engineers was achieved and such that the next layer was easy to build on top of them. According to the FUP, we asked our domain experts to exemplify some typical situations with the help of object diagrams. After some training and some more discussion, we developed object diagrams as shown in Figure 3. Actually, the object diagram shown in Figure 3 has a large number of predecessors that were refined multiple times for each requirements layer. We started with object diagrams modeling car areas in order to deal with environmental conditions as hot and wet in the engine area or cold and dry in the cabin area, cf. objects ca1 and ca2 at the top of Figure 3 (attributes are omitted due to space restrictions). Then we added channels and nodes modeling the parts of the car body where wires may be routed, cf. objects ch1 through ch4 and node n1. In addition, the information on required wire protection means and required mounting means is attached to channels (not shown in Figure 3 due to space restrictions). Next we modeled ECUs and other electronic components, cf. ecu1 and comp1 and comp2. Based on this, we introduced wires, contacts and connectors. Finally, we introduced bundles of wires since some channels may contain multiple wire bundles where each bundle has its own costs for protection means and mounting means. Altogether this process resulted in a large number of detailed object diagrams exemplifying our modeling of the different aspects to be considered for our wiring harness cost model. With the help of the object diagrams, we had a lot of fruitful discussions with our domain experts. For example, in a first attempt our domain experts proposed that each channel object has its own attributes for the humidity and for the maximum temperature. We recognized, that many channel objects had the same values for these attributes and asked the domain experts, when these values will differ. They told us, that these values are determined by the car area and they differ only when the car area is changed. Thus, we moved the humidity

co2:Connector

con2:Contact

con1:Contact co5:Connector

con4:Contact

co3:Connector

con3:Contact

comp1:Component

metercosts=0,01 diamets=0,5

wk1 : WireKind

w1:Wire

b4:Bundle

b3:Bundle

b8:Bundle

sp1:Spout

ch3:Channel

n1:Node

co1:ChangeOver

Fig. 3. An object diagram exemplifying the threading costs

w2:Wire

w3:Wire

b7:Bundle

ch2:Channel

b2:Bundle

b6:Bundle

b1:Bundle

ecu1:ECU

co1:Connector

ch1:Channel

cav1:Cavity

ca1:CarArea

b5:Bundle

con5:Contact

ch4:Channel

ca2:CarArea

con6:Contact

co5:Connector

comp2:Component

Using Graph Grammars for Modeling Wiring Harnesses 521

522


and temperature attributes from the channels to the containing car areas thereby reducing the data redundancy a lot. Similarly, at the beginning, each wire had its own attributes for meter costs, diameter and wire type. After some while, we found out that only 7 different wire diameters are used in a car and that the costs per meter were the same for all wires with the same diameter and the same wire type. To improve this, we introduced a catalogue of wire kind objects holding the price information and each wire just refers to its wire kind. Thereby, it became easy to handle changing market prices for wires. Later on, we introduced such catalogue objects also for contact kinds, connector kinds, chip kinds, etc. Another important point was the discussion of associations. We did not ask our domain experts whether class CarArea should have a contains association to class Channel or whether we should introduce a composite pattern at this place. Due to our experiences, it is not fruitful to discuss with non software domain experts on this level of abstraction. Instead, we asked our domain experts, whether there is an example of deeper nesting of car areas. Indeed, some car areas contain sub car areas. In addition, there were examples where car areas contained cavities which in turn contained channels. Thus, we decided to use a composite pattern to model this hierarchy and told our domain experts that arbitrary nesting of car areas, cavities, and channels are enabled, now. Note, this design decision has been elaborated during the derivation of class diagrams corresponding to step 3 of the Fujaba process. Thus, it would belong to the next subsection. However, while the software experts used class diagrams to identify the problem, the team used object diagrams to discuss the problem with the domain experts. This corresponds to step 2 of the Fujaba process and thus it belongs to the current subsection, too. Actually, these steps may be executed intertwined. Overall, the object diagrams provided the domain experts with a clear understanding how the software models the different aspects of the application domain. This also facilitated the textual description of the requirements, considerably. As an example for a more complex requirement description developed this way, we now discuss the computation of threading costs for cable bundles. Figure 4 shows a small example for a wiring harness connecting three components where the right component is reached via a car area changeover that is protected by a rubber spout. To mount the wiring harness, some cable bundle needs to be threaded through the spout. This is a very tedious work with high mounting costs. Originally, the computation of these threading costs was quite unclear and hard to explain, cf. Figure 5. This first textual requirements description was hard to implement since it was quite unclear, how one finds the wires on the two sides of a spout and how the length is computed. With the help of example object diagrams, it became clear, that one has to consider the bundles within the spout. In addition, it became clear that there are two cases to be considered. If the spout leads directly to a channel, one may just lookup the bundles in that channel. If the spout leads to a node, one has to consider all channels attached


523

Fig. 4. Example for the threading of cable bundles

to the node. In the project, the graphs were just discussed with the software developers. In this exceptional case, we lazily did not write down the improved requirements description that resulted from the discussion. However, for this paper, we created an improved textual requirements description referring to the graph of Figure 3 in order to exemplify how the graphs helped to improve the requirements description, cf. Figure 6.

Computing Threading Length and Threading Direction Consider each wire passing a rubber spout and sum up all lengths of all used cable channels before the spout. The distance of spouts and cavities is computed via the lengths of the cable channels. Consider only cavities connected by wires threaded through the spout. Compare the maximal lengths for each side of the spout. The lower one is the required threading length. This also identifies the threading side, i.e the side from which the cable bundle is threaded through the spout. Consider also the number of plugs at the threading side. Fig. 5. First iteration requirement description

To summarize, with the help of object diagrams the requirements became very detailed and concrete. Such detailed requirements accompanied with elaborated object diagram examples were an excellent basis for the implementation of the desired functionality. Thus, the object diagrams enabled our domain experts to contribute very valuable aids to the design and implementation of the system. 4.2

Applying FUP Steps 3 and 4

Usually, architecture and class diagrams play an important role in software projects. Commonly, these diagrams are used for design discussions. In the OBA project, most of the design decisions have been done based on the discussion of object diagrams. At the first glance, class diagrams have been derived from these object diagrams by just collecting the employed classes, attributes and

524


Threading Length • If a bundle of wires, cf. bundle b4 in Figure 4, needs to be threaded through a spout sp1, this requires mounting time according to the number of connectors that need to be threaded and to the length of the bundle that needs to be threaded. • To compute the threading length, both sides of the spout have to be considered, in our example channel ch4 and node n1 are direct neighbors of spout sp1. • If the direct neighbor is a channel, we consider the wires belonging to bundles that belong to the spout and to the neighbor channel. In our example, channel ch4 contains bundle b5 containing wires w1 and w2. • If the direct neighbor is a node, we consider the neighbor channels connected to that node. Only, wires belonging to the spout and to one of these neighbor channels are considered. In our example, this are again wires w1 and w2. Note, wire w3 must not be considered since it does not cross the spout. • The length of a wire is the sum of the lengths on channels containing bundles that contain the wire. • The maximal length of the two sides of the spout is the threading length.

Fig. 6. Improved requirement description based on object diagrams (Created to exemplify object diagram discussions)

associations. Actually, during the editing of object diagrams, we used class diagrams mainly as a glossary. This means, if one creates a new object, he decides whether the type of this object is already known and may be reused or whether a new object kind, i.e. a new class, needs to be introduced. Similarly, we handled the reuse of attribute declarations and associations. Thereby, the class diagrams leveraged the consistent use of classes, attributes and links through the different object diagrams. However, inheritance structures and design patterns were introduced at class diagram level. This was the task of the software experts. Discussing these class diagrams with the domain experts was not fruitful. As an example, Figure 7 shows some central classes of the OBA model. As already discussed, OBA needed a flexible hierarchy of car body elements. This was enabled by a composite pattern created through the class HierarchyElement and its contains association. In addition, OBA employs several graph like substructures. For example, channels, nodes, and cavities form a graph for the layout of the wiring harness. Similarly, wires, contacts, connectors, ECUs, and components form a graph. These graphs require a certain flexibility since e.g. at the beginning wires are directly connected to components and later on contacts and connectors are introduced. To achieve the required flexibility, we introduced the at association for class HierarchyElement. This at association allows arbitrary graph connections between car elements, even between car body elements and wiring elements which is more then we wanted to achieve. A better modelling would have employed UML 2.0 association refinement features in order to separate between different graph structures. While we wanted to employ these UML 2.0 features, we had no sufficient tool support for the generation of the


525

contains

0..n

at

0..n

0..1

HierarchyElement groupedWith

0..n

0..n

Contact

0..n

collapsed

CarArea

Node

collapsed

SpatialElement

Bundle

collapsed

collapsed

collapsed

0..n

wires 0..n

ChangeOver

Channel

Cavity

collapsed

collapsed

collapsed

collapsed

collapsed

wires 0..n

0..n

Wire collapsed

threadedConnectors Connector

0..n

0..n

Spout

collapsed

collapsed

collapsed

collapsed

Fig. 7. Some central OBA classes

implementation of such refined associations available and thus we stick to the general solution. Conventional approaches tend to express as many requirements and constraints in the class diagram as possible. Such conventional approaches frequently use additional OCL expressions to statically constrain the class diagram even more. If class diagrams are your central document, you need to put all your findings there. Contrarily, the Fujaba process proposes to document the central findings in story boards. Thus, class diagrams become secondary documents and as in the above example the class diagrams used in the Fujaba process are usually less restrictive than conventionally. Due to our experiences, such less restrictive class diagrams and designs turn out to be more flexible in case of new requirements showing up in later phases. In our example, the general at association allows to connect wires directly to actors while in reality the wires end in a connector that then is plugged to the actor. However, during implementation, it became handy to connect wires to actors first and to insert connectors later

526


after all wires had been added. In our relaxed design this intermediate object structure was no problem. A conventional design may have easily forbidden it. 4.3

Applying FUP Steps 5 through 8

Once the major design for some functionality had been developed based on detailed textual requirements, object diagrams and class diagrams, we implemented that piece of functionality in an iterative process. Since this paper focuses on the usage of object diagrams and story boards for the involvement of domain experts, we do not discuss the algorithm development here. However, as implementation language we used so-called story diagrams, i.e. a combination of activity diagrams and a variant of object diagrams, so-called story patterns, cf. [KNNZ00, DGZ05, Z¨ un02]. As an example, Figure 8 shows the specification of method getThreadingCostsPerCarArea of class Spout. The activity diagram part of a story diagram specifies the control flow as within a flow diagram. Story patterns specify a query to the object structure in the program’s main memory. For such a story pattern, the Fujaba environment generates usual Java code. This Java code searches for a match of the depicted object diagram and if this is successful, the depicted operations are executed, cf. [Z¨ un02]. For example, the first story pattern of Figure 8 specifies a query for three objects this, obasystem, and params that are connected by an allObaElems link and by a parameters link, as depicted. Query objects that are shown without a type are so-called bound objects, i.e. they are already known, e.g. the this object. The Java code generated for such a query starts from known objects and uses getters and iterators to look-up the other query objects. If these look-up operations fail to retrieve valid matches for all participating objects, the story pattern execution fails. Story diagrams provide special transitions in order to react on the failure or success of a story pattern, cf. Figure 8. The middle story pattern of Figure 8 looks-up all wires belonging to two bundles that belong to the this object and to the (channel)neighbor object, respectively. For each match1 , the depicted collaboration message computes the threading length for that wire and the maximal threading length is collected in variable threadingLength. Similarly, the last but one story pattern handles the case that the neighbor of the current spout is a node and all channels attached to that node have to be considered. The point is, that our method implementation with story diagrams use a graphical notation (cf. [KNNZ00, DGZ05, Z¨ un02]) that again employs a variant of object diagrams. Since object diagrams have already become familiar to our domain experts during the requirements analysis, with some training, our domain experts were able to review our implementation. We had a lot of fruitful discussions, where the software developers explained their story diagrams and then the domain experts started to point to special cases. In these discussions, the domain experts again used object diagrams to illustrate the special cases they were concerned about. Then the software developers used simple walk throughs 1

Potentially, a story pattern query may deliver multiple matches. For-each activities depicted by two stacked activity shapes allow to iterate through all such matches.


527

Fig. 8. Computation of the threading costs

to check whether these special cases were already addressed or whether the story diagram had to be adapted to handle such a special case, appropriately. Actually, in the threading length example, such a review discussion revealed that the first implementation attempt erroneously considered wires that only bypass a spout. Thus we had to extend the last but one story pattern of Figure 8 by the bundle object contained within the spout in order to ensure, that only threaded wires are considered.

528


To summarize the implementation phase, the use of story diagrams enabled our domain experts to review our implementation and to point us to special cases. In our experience, similar reviews by our domain experts would not have been possible for an implementation in a textual programming language like Java or C++. 4.4

Deployment

The Fujaba process focuses on the central software development activities. In the OBA project, it turned out that this is only a part of the overall project. For the deployment of the developed software, we needed not only to model the required car data but we had also to collect all the actual data of a car electrical system. The data on a car electrical system is distributed over a large number of heterogenous data sources. First of all, the car body geometry is provided by a CAD system owned by the OEM. In addition, the OEMs electrical engineers use another CAD tool to develop the circuit diagrams for the electronic system of the new car. In the next step the circuit diagrams are enriched with information on wire kinds, etc. This information is then joined with the car body geometry in order to determine the actual layout and length of cables. This is again enriched with information on required mounting and protection elements. As an example, Figure 9 shows a cutout of the final 3D CAD drawing for the wiring harness in the front left area of an example car. For the manufacturing of the wiring harness, the 3D CAD drawing is finally exported into a so-called form board diagram, a 2D flattening of the wiring harness.

Fig. 9. Cutout of a 3D drawing of a wiring harness

While the described tool chain was well established at the industrial partners of the OBA project, the development process still involved many manual steps and frequently the data produced by one tool is interpreted by a human executing a subsequent step. Thus, we had to collect data e.g. from paper print-outs


529

and from several spreadsheets. While semi-formal, the spreadsheet data contains numerous data cells where automatic data import failed, e.g. because an engineer had entered some additional comment to the data. This is helpful for a human interpreting the data but crashes automatic data import routines. In addition, the data was frequently not on the level of detail that we needed for OBA. For example the size of connectors was usually not contained in the plans while OBA needed to ensure that the connectors still fit through hatches and do not exceed the size of e.g. the ECU they are connected to. At the beginning of the process the domain experts where quite confident about the quality of the available car data. They have a well established tool chain and process and they are producing quite some cars with this process. However, with the help of the story board scenarios, it was easy for the team to elaborate which detail of data was actually required for the OBA tool. It was also easy to exemplify why e.g. certain comments in a spreadsheet cell are not easy to interpret for the OBA tool and that certain data like connector sizes are not yet available at all. This common understanding on data requirements was the key to solve the data retrieval problem. The common understanding was important because finally, the domain experts had to figure out where in the enterprises and in the existing tool chain such data might be retrieved. And, sometimes, the domain experts had to convince their colleagues that they have to extend the existing tool chain to provide additional data. This would not have been possible for the software developers from outside the enterprises.

5

Other Approaches

The Fujaba diagrams are derived from UML diagrams and try to stay as close as possible to UML. However, in UML related processes class diagrams have a much more central role and object diagrams are somewhat marginal. In the Fujaba process, object diagrams and story boards are central. Accordingly, Fujaba extends these diagrams, slightly. In SYSML, inner block diagrams are a big step in the direction of the Fujaba approach. These inner block diagrams allow to specify block instances and their relations at runtime and may be compared to our use of object diagrams. The main difference is that in SYSML, the blocks usually represent functional units that pass data values to each other via their connections. Restructuring operations on such nets of blocks are not central to SYSML. Thus, SYSML is well suited to model nets of functional blocks and how data is processed within such a net. Fujaba story boards are well suited to represent complex internal states of object oriented systems and how such complex states evolve during operation execution.

6

Lessons Learned

The main complexity of the OBA project was the sheer amount of domain details that contribute to the construction of a car electric system. The OBA project was initiated by our professor for car systems at Kassel University. Thus, the

530


project employed two domain experts from the research group of car systems. For the design and implementation work, there were only two PhD students from the software engineering group of University Kassel. At the beginning, the software engineering group thought that one domain expert and three software developers would make a better team. However, after roughly 6 years of software development, we have to state that the emphasis on domain experts was actually a key to success for the project. More precisely, since we had only two software developers, we were forced to involve the domain experts into the development process as much as possible. Using object diagrams we were able to do this in the requirements analysis phase. After a short learning curve, the domain experts were actually driving the requirements process. For each new aspect, they developed object diagram examples. These were discussed with the software experts in some iterations. Frequently, the domain experts from University of Kassel had to interview the domain experts in the contributing enterprises in order to clarify details. Thus, the domain experts at Kassel University served as some kind of mediators between the actual customers and the software developers. Through object diagrams, this worked out very well. Similarly, the contribution of detailed implementation reviews by our domain experts was of unmeasurable value for the project. Again, this was enabled by the object diagram like notation used in story diagrams. For the deployment, the gathering of actual car data became a crucial issue. Many data came from tools without appropriate data export features. Some data was provided in paper format, only. And some data needed to be retrieved from the domain knowledge of the participating enterprises. Before the project, this data was used by human experts, only. While these experts were able to deal with slight inconsistencies and some missing data, the OBA tool requires consistent and complete data. Thus, the retrieval of the actual car data required a lot of negotiation with the domain experts working in the participating enterprises. During these negotiations it was crucial to communicate the detailed data needs of the OBA system and why the existing data sources failed to deliver the required details. Again, object diagrams turned out to be very helpful in communicating how OBA processes car data and which detailed information is needed for which calculation step. This helped tremendously to raise the mutual understanding of all partners and to ease the collaboration. One may argue, that the Fujaba process requires the elaboration of a large number of object diagrams and story boards compared to a much smaller number of class diagrams used in conventional approaches. This is true. The cost model of the OBA project produced about 165 object diagrams and 107 pages of textual requirements. This resulted in 108 classes with 312 major methods which corresponds to about 8 class diagrams. However, creating the object diagrams is much easier than creating class diagrams, directly. In addition, skipping the object diagrams and creating the class diagrams directly would not have helped us to involve the domain experts. Many problems in our design would not have been discovered by the domain experts and we probably would have build the wrong system. In addition, after a short learning period, most of the object


531

diagrams have been created and elaborated by the domain experts. Thus, the domain experts did this extra work. Thereby the domain experts facilitated the work of the software engineers considerably. Actually, in other projects we made the observation, that software developers tend to need a much smaller number of less detailed object diagrams and story boards to cover some functionality. Non IT domain experts tend to use more examples and to elaborate them in larger details in order to ensure themselves that they did not miss any problem. In combination, the software developers do not need to invest too much time into the elaboration of object diagrams and the domain experts ensure that no important domain detail is missed. Still, the large number of object diagrams create a certain maintenance problem. If the organization of the object structure changes reasonably, this may require only a small change to the corresponding class diagrams while this may cause changes in many object diagrams that contain the changed structure. For example, moving the temperature attributes from cable channels to car areas was a small change in the OBA class diagrams but quite a number of object diagrams needed to be adapted. Luckily, in the OBA project, again the domain experts did this work. Generally, improved editing support as e.g. copy and paste mechanisms and macro recording mechanisms need to be provided to minimize this effort. Overall the incorporation of the domain experts worked out very well in this project. The key to success was, to enable the experts to contribute detailed domain knowledge within requirements analysis and even within the implementation phase. This worked due to the usage of object diagrams and story diagrams, i.e. due to graph grammar techniques.

References [BRJ99] [DGZ05]

[EMF] [FNTZ99]

[Fu09] [GZ05]

Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Addison Wesley, Reading (1999) Diethelm, I., Geiger, L., Z¨ undorf, A.: Applying Story Driven Modeling to the Paderborn Shuttle System Case Study. In: Leue, S., Syst¨ a, T.J. (eds.) Scenarios: Models, Transformations and Tools. LNCS, vol. 3466, pp. 109–133. Springer, Heidelberg (2005) The Eclipse Modeling Framework, http://www.eclipse.org/modeling/emf/ Fischer, T., Niere, J., Torunski, L., Z¨ undorf, A.: Story Diagrams: A new Graph Grammar Language based in the Unified Modeling Language. In: Ehrig, H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.) TAGT 1998. LNCS, vol. 1764, pp. 296–309. Springer, Heidelberg (2000) Fujaba Homepage, Universit¨ at Paderborn, http://www.fujaba.de/ Geiger, L., Z¨ undorf, A.: Story Driven Testing. In: Proc. 4th International Workshop on Scenarios and State Machines: Models, Algorithms and Tools (SCESM 2005), ICSE 2005, Workshop (2005)

532


[GSZ et al. 05]

[JBR99] [KNNZ00]

[UR05]

[ZLM et al. 06]

[Z¨ un02]

Gemmerich, R., Semmelrodt, S., Z¨ undorf, A., Reckord, C., Leohold, J., Trippler, J., Brabetz, L., M¨ uller, D., Schrey, U., Weil, H.-G.: An integrated approch for the generation and optimization of car electric systems. In: VDI (Hrsg.): 12th International Conference and Exhibition Electronic Systems for Vehicles Baden-Baden, pp. 597– 608 (2005) Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Software Development Process. Addison Wesley, Reading (1999) K¨ ohler, H., Nickel, U., Niere, J., Z¨ undorf, A.: Integrating UML Diagrams for Production Control Systems. In: Proc. of ICSE 2000, Limerick, Ireland, pp. 241–251. ACM Press, New York (2000) Ungerer, M., Rabe, O.: VDA KBL - Harness Description List (KBL); VDA working group CAD/CAM (2005), http://www.ecad--if.de/documents/KBL_Data_model.pdf Z¨ undorf, A., Leohold, J., M¨ uller, D., Gemmerich, R., Reckord, C., Schneider, C., Semmelrodt, S.: Using object scenarios for requirements analysis - an experience report. Modellierung, Insbruck (2006) Z¨ undorf, A.: Rigorous Object Oriented Software Development with Fujaba (2002), http://www.se.eecs.uni--kassel.de/se/fileadmin/se/ publications/Zuen02.pdf