Project Flow Graphs - A Meta-Model To Support Quality ... - CiteSeerX

Project Flow Graphs - A Meta-Model To Support Quality Assurance in Software-Engineering Dr.-Ing. Detlef Kips a and Georg Heidenreich 1,b aBASYS

GmbH, Am Weichselgarten 4, D 91058 Erlangen, Germany

bIMMD

2, Informatik, Universität Erlangen, Martensstraße 3, D 91058 Erlangen, Germany, [email protected] Abstract Since complexity of industrial software projects keeps growing, the limits in common software engineering methods become more and more obvious. Today, it is not the particular CASE method which makes up a successful project. Systematic quality assurance measures urgently need a supplement with a generic development plan, a so called meta model of software development processes. The method of project flow graphs allows for practically as well as for theoretically well founded meta modeling of software development and thus serves as an appropriate basis for examining and supporting various quality assurance methods in software engineering. This is illustrated with practical examples by describing typical processes and situations in the software life cycle with project flow graphs. Furthermore, the relations between project flow graphs and traditional graph theoretic concepts like petri nets and graph grammars are also evaluated. 1

Quality Assurance in Software Engineering

The term of quality assurance is in everyday's use in various engineering disciplines, namely in production engineering, but it has nearly been a foreign word in software engineering not so long ago. Surprisingly, because already in the beginning of the 70s the necessity for structuring and systematizing software construction was recognized clearly. As a consequence of that growing insight the principles of structured programming have been developed, with its famous representatives SA/SD [1], SADT, ERD a.o. Depending on the area of application and practical usability, they have been accepted and have spread widely. Simultaneously, the number of computer based tools has grown, they support one or many stages of software development from analysis and design to coding and systematic test specification and offer comfortable formal or semiformal means. The various graphical and syntax driven editors which should ease the task of software design using diagram techniques or formal specification languages are very widespread. However, nearly all these tools share the disadvantage of using a specific determined design- and development method and above that are only suited for special areas of application, what reduces their practical use significantly. [2]. 1This

work has been partly supported by the German Federal Department of Research and Technology under contract number FKP 0004401B4A

Especially in larger development projects, a number of problems and phenomena appear, almost independent of the application field or of the tools and methods used throughout development, which nevertheless have a striking influence on the quality of the software being produced. In fact these are mainly problems in connection with project planning, -coordination and -documentation. When this was recognized, a standard for quality especially in software engineering was created with the aim of standardizing the means of quality assurance for the process of software development [3]. Among others the ISO standard calls for a systematic concept to deal with the following questions: • Project Planning: Every larger software project must be based on a detailed development plan which defines development phases and milestones in terms of time and contents and assigns responsibilities for different tasks to the members of the project team. • Method and Tool Integration: Considering the phases and activities of the development plan, it has to be settled, which methods, formalisms and especially which computer based tools are to be used and in what stage of development. This aspect is of special importance if the results of one phase are to be used as input to the next one in an automated or semi automated way. • Document Management: Every larger software project deals with a lot of files and documents which are handled by different personnel. A thorough quality assurance demands for systematic assignment of responsibilities when editing, validating, releasing, changing and archiving files and documents. • Configuration Management: During development, a lot of revisions are written or generated that have to be handled, updated and checked for consistency. Backtracking of changes must be possible as well as keeping control of syntactic and semantic dependencies. • Project Documentation: All relevant activities related to planning and progress of the project have to be recorded. The best case would be a seamless documentation of the project history. One can clearly see that these and some similar aspects are rather independent of definite development methods, tools and even of implementation languages. We therefore demand a superordinate conception for development which models the software development process from a meta layer, abstracted from all phenomena related to projects, methods or tools. One might even implement a computer based meta CASE framework that supports all those tasks of project management listed above and ideally allows for the integration of arbitrary CASE tools for definite methods. In the sequel we will sketch the fundamentals of a theoretically well defined graphical model that focuses on the meta aspects of software engineering and thus makes up a well suited base for exploring and supporting quality assurance means according to ISO 9000 part three. 2 Definition of Project Flow Graphs The centre of our model is the so called project flow graph (PFG), which allows to characterize objects and activities and the relations between them within the framework of a software project with sufficient exactness. We subsequently introduce various kinds of nodes and edges and finally explain the concept of views onto the project flow graph.

2.1 Objects in a PFG In a PFG one can distinguish the following kinds of nodes: • document nodes represent documents like the requirements definition, the requirements specification, the design specification, the source code or the documentation (node set D, graphically represented by circles) • file nodes represent text and graphical files respectively, files in arbitrary formats, source files, executable code files (node set F, graphically represented by circles, too) • revision nodes represent different variants of files and documents (node set R, represented by triangles) • tool nodes represent for instance text or graphical editors, transformers, compilers, generators (node set W, represented by rectangles) In a PFG the nodes will be labelled with the names of the documents, files or tools they represent. Revision nodes are labelled with the file names and a revision number. 2.2 Object relations in a PFG The relations between nodes will be represented by different kinds of edges that we will now describe in a semi formal way. Depending on their meaning one can distinguish the following classes of relations : • compositional relations • processing relations • dependency relations design specification d1 d contains

contains

data model f1

f2

d2

has-rev

has-rev functional model

has-rev

interfaces contains

contains d.r1 f3

ER model

f4

d.r3 d.r2

JSD model

Fig. 1: Examples for aggregational relations

Fig. 2: Revisions of a file

Compositional relations allow for refining the contents of documents hierarchically and thus modularize the documents. A document can be built up from files and from other documents. This hierarchy can be expressed by an aggregation relation (formally: a subset of D × (D ∪ F)) and can be shown in a PFG by edges with the label contains . The hierarchy ends at file nodes, which can not be refined anymore. Figure 1 shows a document consisting of two files. From now on we will simply assume that documents consist

of a single file. For a file there are usually several releases or variants. We call them revisions, connected to the file name by the revision relation. The corresponding edges are labelled with has-rev and run from an F node to an R node: has-rev ⊆ F × R, an example is given by figure 2. Processing relations are connections between file generating and file consuming tools. In the PFG this will be represented by input edges and output edges. Input edges run from file nodes to tool nodes, output edges from tool nodes to file nodes. Thus input and output relations are subsets of F × W and W × F, respectively. Imagine m input edges running from the file nodes f1, ..., fm to a tool node W and n output edges running from W to the file nodes f1’, ..., fn’. This situation illustrates that a tool W, when being fed with inputs of revisions of all the files f1, ..., fm (conjunction) produces output to revisions of the files f 1’, ..., fn’ . dep-on in interface definitions

out preprocessor

source file, expanded interface definitions

in editor

out

header file

in

dep-on in editor

source code out

in structurechart

out generator

source code

dep-on

Fig. 3: Processing relations between files & tools Fig. 4: Dependencies between files

The processing relation typically describes call sequences and connections between transformers, generators and compilers in a PFG, like the "makefiles" or script procedures do that in their plain text notation. Figure 3 gives examples for both edge types. Dependency relations describe semantical dependencies between documents and files as well as between revisions of the same or of different files. Semantical dependency means the inclusion, reference or assumption of "knowledge" in a broader sense from one document in another. We distinguish three kinds of semantic dependencies: The dependency between files and documents (subset of (D∪F)×(D∪F)), the dependency between several revisions of a single file (subset of R×R) and the dependency between revisions of different files (subset of R×R). Considering the dependency relation between files, one states that document d2 uses information of document d1 by establishing d2 dep_on d1. An example is given in figure 4 which also shows processing edges (dashed edges). Note that the processing relation implies a dependency relation in a trivial way which means, for arbitrary file nodes f, f’ and tool nodes W : f in W ∧ W out f’ ⇒ f’ dep-on f. holds, but the statement cannot be reversed because there are also dependencies between documents which are not processing relations but there are rather semantical dependencies between these documents. In a similar way one can also define dependency relations for revisions of a single file. Let d be a file with two different revisions r2 and r1, i. e. d has-rev r1 and at the same time d has-rev r2. The relation r2 dep-on r1 then means, that

revision r2 of file d directly depends on revision r1 in a historical and/or logical way. Regarding the possiblities of splitting and joining revisions, the dependency relation of revisions is a directed acyclic subgraph of the PFG. An example is given in figure 5. Checking consistency within a software system (i. e. all documents of the PFG) makes it necessary to check compatibility between revisions of different files. Let d1 and d2 be documents and r1, r2 their corresponding revisions with d1 has-rev r1 and d2 has-rev r2. Then: r1 dep-on r2 ⇒ d1 dep-on d2 holds. Again, the reverse implication is not necessarily true. Instead you can find revisions which have no semantical or logical dependency in parallel to dep-on edges between their documents. This is a situation which may cause inconsistencies in the set of revisions as a whole. Figure 6 shows the use of dep-on edges between revisions of different files. Dependencies of the related files and the has-rev-edges are also shown. The latter ones are drawn with dashes.

has-rev dep-on has-rev dep-on dep-on dep-on

has-rev

Csource code

dep-on dep-on

has-rev dep-on dep-on

has-rev

Fig. 5: Dependencies between revisions

Fig. 6: Dependencies between files

2.3 Views onto PFGs In most cases, only parts of the project flow graph are of interest. In fact the representation of all nodes and edges for a real life project may be confusing. Therefore views are used which focus only on certain aspects of the project flow graph and some of the nodes and edges are discarded. The figures 7 and 8 show examples for views under the assumption that there are only 1:1 relationships between files and documents. The underlying software project uses editors for graphical design languages and a code generator. If you are interested only in the compositional relations between documents and files, you can leave out dependency and processing relations. The hierarchical view thus shows a tree for both the contains edges and the has-rev edges. If one wishes to concentrate on processing relations between tools and documents, which describe the so-called project dataflow, the representation of dependencies and revisions is no longer needed. The operational view onto the PFG (figure 7) thus leaves out revisions nodes and the dep-on- and has-rev-edges. To trace back semantic connections it is sufficient to look at the dep-on-relations. In the semantical view we therefore discard processing relations and tool nodes. However processing relations have an indirect influence on semantical views. All documents connected by tools are also connected by the dep-on relation. The semantical view in figure 8 shows solid arrows for the dependency between documents and dashed arrows for the dependency between revisions.

SA/SD editor

SA/SD diagram

SCD editor

JSP/ code

structurecharteditor

SA/SD diagram

C code

JSP/ code

interface

text editor

requirements

JSD editor

ER editor

DTD editor

JSD/ data

C code

interface

type definitions

C compiler

JSD/ data

specifications

dep-on

dep-on ER diagram

Fig. 7: Operational View onto a PFG

dep-on

type definitions

ER diagram

Fig. 8: Semantical View onto a PFG

2.4 Examples of Applications The project flow graph in figure 7 describes a typical array of tools namely with several graphical editors which may be used in many software projects. Using this example one can consider topicality and consistency without having to know about a certain project or making assumptions about the meaning of special diagram techniques. Consistency means a property of a set V of revisions and all its ancestors in pairwise different documents so that (r1 ∈ V ∧ r2 ∈ V ∧ d1 has-rev r1 )⇒ i) d1 has-rev r2 ⇒ r1 = r2 and ii) d2 has-rev r2 ∧ d1 dep-on d2 ⇒ r1 dep-on r2 holds, said verbosely: i) means that one document has only one revision in V and ii) demands that document dependency in the PFG implies revision dependency in V. If V has revisions for all documents in the PFG, then V is called a version of the software managed by the PFG.

JSD/ Data

specification

JSD/ data

specifi cation

is_author

dep-on dep-on

1

dep-on

dep-on

A

type definitions

writes 1

1

1

type-definitions dep-on

dep-on

dep-on 2

2

B

2 dep-on

dep-on ER diagram

dep-on

2

is_reader

A

is_author reads writes

Fig. 9: Consistency in Project Flow Graphs

Fig.10: Actors during Construction

Figure 9 shows a simplified semantical view onto the same PFG by leaving out dependencies between documents implied by dependencies on revisions. This situation includes an inconsistency concerning revision A of the "type definitions".

Both dependency paths starting from revision A refer to the requirements specification, but to different revisions of that document [4]. Managing access rights to files might be used to coordinate parallel development activities of the team members, whose roles and involvements into the software project are visualized by actor nodes (drawn as rhombi). Figure 10 shows actor nodes with the static is-author and is-reader relation to file nodes and the dynamic reads and writes relation (the latter one implies a reads-relation) to revisions of those files. For one document and one actor there is at most one revision with a reads edge: d has-rev r1 ∧ d has-rev r2 ∧ a reads r1 ∧ a reads r2 ⇒ r1 = r2 Revision 2 of the "JSD/Data" document has been generated by a so-called CheckOut. Figure 11 shows the subsequent phase of validating the new revision, which has fixed revision 2 by performing a Check-In temporarily cancelling write permission to revisions of the current document. is_author

JSD/ Data

specification

is_author

dep-on

reads

dep-on

reads

1

1

JSD/ Data

specification

type-definitions dep-on

1

1

type-definitions

dep-on dep-on

dep-on

dep-on

dep-on

A

dep-on

2

A

2

2

2 is_reader reads

is_reader reads

is_author

is_author

reads

dep-on B

writes

Fig.11: Actors during validation of revisions

Fig. 12: Final step of generating a revision

Figure 11 however reveals, that changes made to revision 2 have to be propagated from "JSD/Data" to the document of "type definitions". In a similar way to figure 10 it is shown in figures 12 and 13 how to do a CheckOut and a subsequent CheckIn for the "type definition" revisions. Note that advanced CheckIn/ CheckOut-concepts beyond the scope of this paper allow for developing several documents at the same time. By the definition of these procedures the set of revisions built with CheckIn/ CheckOut is consistent and makes up the so called configuration which is crucial to rebuilding software, tracking down errors, doing reviews and supporting different customized software versions. While in the early (typically: design) stages of software development each document has just one author and documents typically have linear sequences of revisions (ordered by time of creation and file size), documents in later (typically: coding) stages are big, grow slowly and have many authors, who store revisions and variants with only a few changes in terms of code which however may cause major changes in the behaviour of the system under construction. Locking whole documents especially those of later development stages (with CheckOut) causes bottlenecks for the whole project. This gives rise to the so-called "long transaction" concept, allowing people to work simultaneously on the same document and joining their revisions synchronously using the "LongCheckIn", as far as pairwise nonintersecting parts of context-free file formats are to be joined with respect to a common ancestor. This can be done automatically and without making any further

assumptions. Joining revisions with context-sensitive formats however needs manual rebuilding, joining revisions with intersecting changes needs a jury to select and join options for the final version.

JSD/ Data

specification

is_author

dep-on reads

1

1

dep-on dep-on dep-on

JSD/ Data dep-on

A

dep-on

2

writes

type-definitions

2

reads

1

is_reader reads

A

dep-on

dep-on is_author

B

2 writes reads

Fig. 13 : The final phase of validation

Fig. 14: The parallel Long Check-Out

There are several approaches to merging automatically, but they all make specific assumptions about contents and the syntax of the files, which reduces the generality and usability of those models.

reads JSD/ Data

dep-on

A dep-on

1 dep-on

2

reads

B reads

Fig. 15: The synchronous Long Check-In

Figure 14 shows a simplified example after two Check-Out-operations which need not be synchronized. In that situation two different authors work on their copies of the same document, whereas the remaining team members only see (a read edge only gives read permission) the common ancestor of both revisions. Figure 15 shows the result of joining all new revisions into a single one readable for the whole team. Making variant lines of software can be seen as making revisions with a LongCheckOut by some super-actor (representing the project supervisor), without ever CheckingIn but allowing team members to work with these revisions according to any of the revision management models depicted in the sceneries above.

3

Dynamic aspects of Project Flow Graphs

Our considerations were implicitly based on a static view onto PFGs up to now, i. e. dependencies, compositions and process relations have been shown as if being given by the project and thus being fixed. In fact, this is a completely insufficient assumption, because all the views we have seen up to now only represent a snapshot of the current state of the project. Realistically modeling the software development process thus requires making the PFG dynamic so that the structure of the graph is changed incrementally during the progress of development. Typical situations which cause modification of the PFG or its subgraphs include: • • • • • •

Introducing new documents or files Splitting or melting documents or files. Storing new revisions Splitting or melting revisions Changing processing relations, for example by introducing new tools Changing dependency relations, for example by introducing new references to existing documents Each of these activities comes along with non-trivial modifications of the PFG that typically affect several or all relations (by deleting existing or introducing new edges). For modeling all dynamic aspects of a PFG one can employ the traditional theory of graph replacement calculi, like for instance graph grammars [5] [6]. With these grammars, typical modifying activities are described as a system of graph productions that are being applied to the evolving PFG successively. By tracing the application of graph-productions to the PFG, a complete documentation of the project history is obtained as a spin-off. As opposed to serial or synchronous productions supporting parallel work like in chapter two, it is important from the dynamic perspective to detect and avoid conflicts in the parallel application of productions. For that situation one can rely on a rich set of research reports on the subject of parallel graph replacement systems, see e. g. [7] or [8]. A reduced but sufficient view for many practical purposes can be obtained by just focusing on the processing relation and by interpreting the remaining bipartite graph (with file nodes on the one side and tool nodes on the other) according to Petri net semantics (see [9] [10]). Tool nodes can be seen as transitions of the Petri net, they "fire" when all the documents (or files resp.) from which input edges run into the tool node are "labelled" i. e. they are topical in the sense of revision control. The tool successfully generates its output documents and in turn these are labelled as being the current ones. 4

Goals and Perspectives

The model of project flow graphs is being examined in the framework of the research project "Concepts and Methods of Quality Assurance in Software Engineering" which BASYS GmbH, a software engineering company, conducts together with the University of Erlangen-Nürnberg. The research project is supported by the Federal Department of Research and Technology (BMFT) in the program "research cooperation" .

The centre of further activities will be the following aspects: 1. While trying to develop a well-founded base for revision and consistency control it is being examined, which general theoretic statements can be found for relations within PFGs. Especially modeling of subtle interference and connections between composition, processing and dependency relations that affect the progress of software development turns out to be non-trivial. 2. The dynamic PFGs sketched in chapter three using graph grammars or petri nets will be described formally and be examined in detail. It is expected that several properties which have been proved for graph grammars and petri nets can be easily transferred to PFGs and thus allow for an easy understanding of dynamic processes. 3. Typical scenarios of design databases, for instance like the CAD repositories with group check-out, nested transactions and parallel document access have not yet been described in terms of formal methods. By using PFGs as an appropriate notation, one can obtain basic statements about the behaviour of these innovative database concepts. 4. Finally, at the background of theoretical statements about PFGs, it is to be examined whether the models for software engineering can be used as a conceptual base for a computer-based Meta-CASE-Framework in the sense we explained in the introduction of this article. Considering the tasks of project documentation, configuration management and tool integration the PFG approach seems extremely promising. A prototype implementation of the Meta-CASE-Frameworks is planned in a later stage of the research project. The authors are currently planning a prospective consortium for software process technologies research within the 4th european research programme possibly starting in 1995. 5 Related Work A lot of extended transactions on design databases, especially for integrated circuit design, have been suggested by R. H. Katz [11] [12]. An object-oriented approach is given in [13]. Applications to software development can be found in [14]. A complete model for revision management and control of consistency for a software design database is presented by [15]. However, this approach is restricted to representating all file contents with graphs. Since, in our opinion, this reduces the practical use of quality assurance environments, we did not make any assumptions about the internal structure of file contents. 6

Summary

We have presented a formal model for various configuration management activities, which is suitable for modelling typical situations in large software development teams, independently of life-cycle-models or CASE methods. The model can easily be implemented on arbitrary platforms and integrates the use of typical CASE tools, it is not restricted to software development, but supports all technical documentation and design activities instead. Our transaction mechanism separates persistence (small steps) from consistency (large steps) by using configurations as the local storage space for each design transaction.

7

Acknowledgements

The authors wish to thank Prof. Dr. H. J. Schneider, Erlangen, for supporting their research on software engineering. Also special thanks to J. Landauer, G. Viehstaedt and M. Zanzinger for lots of helpful comments. Bibliographical References 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

Yourdon, E.: "Techniques of Program Structure and Design", Prentice-Hall, New York, 1975 McClure, C.: "The 3 R‘s of Software-Auto mation", Hanser, München 1992 Int. Standards Organization: "ISO 9000 part 3", Beuth Verlag, Berlin 1993 Gilb, T., S. Finzi: "Principles of Software Engineering Management", AddisonWesley, Reading MA, 1989 Nagl, M.: "Graph-Grammatiken", Vieweg, Braunschweig 1979 Göttler, H.: "Graphgrammatiken in der Softwaretechnik", Springer, Berlin, 1989 Ehrig, H., B. Rosen: "Parallelism and Concurrency of Graph Manipulation", in: Theoretical Computer Science, Bd. 11, pp. 247-275, Elsevier, Amsterdam, 1980 Löwe, M., H. Ehrig: "Parallel and Distributed Derivations in the SinglePushout-Approach", Report 91/01, Technische Universität Berlin, 1991 Reisig, W.: "Petrinetze", Springer, Berlin 1986 Zanzinger, M.: "ROSE - Konzeption und Implementierung einer Programmierumgebung für rechnerorganisierte Software-Entwicklung", Ph. D. thesis, Universität Erlangen-Nürnberg., IMMD2, Erlangen 1992 Katz, R. H.: "Computer-Aided Design Databases", in: Ariav G., J. Clifford (eds.): "New Directions for Database Systems", , pp. 110-123, Ablex Publ. Corp, Norwood NJ, 1986 Katz, R. H.: "Towards a Unified Framework for Version Modeling in Engineering Databases", ACM Comp. Surveys, vol 22, no. 4, Dec. 1990, pp. 375408, New York 1990 Xu, H., Kakeshita, T.:"A Toolkit Approach for Concurrency Control in Design Database Systems Using Design Status", in: Chen, Q., Y. Kambayashi, R. Sacks-Davis: "Future Databases 92", Proc 2nd Conf. on Future Database Systems, World Scientific Publ. Corp., Singapore 1992 Kaiser, G. E.: "A Flexible Transaction Model for Software Engineering", in : Proc. 6th Intern. Conf. on Data Engineering, pp. 560-567, IEEE Computer Society Press, Los Alamitos CA, 1990 Westfechtel, B.: "Revisions- und Konsistenzkontrolle in einer integrierten Software-Entwicklungsumgebung", IFB 280, Ph. D. thesis, Springer, Berlin 1991

Project Flow Graphs - A Meta-Model To Support Quality Assurance in Software-Engineering Dr.-Ing. Detlef Kips, CEO, BASYS GmbH, Am Weichselgarten 4, D 91058 Erlangen, Germany, Phone +49 9131 7774-0, Fax 49 9131 7774-44 Diplom-Informatiker (univ.) Georg Heidenreich, IMMD 2 (Programming Languages and Compilers), Technische Fakultät, Universität Erlangen-Nürnberg, Martensstraße 3, D 91058 Erlangen, Germany, Phone +49 9131 85-7935 email: [email protected] This paper has been accepted as a full paper at IEPM´95 to be held in Marrakech, Morocco, April 4-7, 1995 This work has been partly supported by the German Federal Department of Research and Technology under contract number FKP 0004401B4A Abstract Since complexity of industrial software projects keeps growing, the limits in common software engineering methods become more and more obvious. Today, it is not the particular CASE method which makes up a successful project. Systematic quality assurance measures urgently need a supplement with a generic development plan, a so called meta model of software development processes. The method of project flow graphs allows for practically as well as for theoretically well founded meta modeling of software development and thus serves as an appropriate basis for examining and supporting various quality assurance methods in software engineering. This is illustrated with practical examples by describing typical processes and situations in the software life-cycle with project flow graphs. Furthermore, the relations between project flow graphs and traditional graph theoretic concepts like petri nets and graph grammars are also evaluated.