Management Model: Formal Speci cation To formalize the management model introduced in the previous chapter, we use the speci cation language PROGRES [Schurr 1989; Schurr 1990; Schurr 1994; Schurr et al. 1995; Schurr et al. The PROGRES speci cation of the management model serves in turn as a starting point for the implementation of the management system to be described in the next chapter. Note that the speci cation concerns the internal representation used by man- agement tools.
In contrast, in the previous chapter many gures showed external representations of graphs visible at the user interface. These levels have to be separated clearly. Internal representations include all details which have to be taken care of by sophisticated management tools. On the other hand, a simple and readable representation is required at the user interface.
This chapter is structured as follows: Firstly, we give a brief introduction to PROGRES and motivate its application to the management of development processes (Section 9. The subsequent sections are devoted to the speci cation of the submodels for product, activity, and resource management (Sections 9.5, we explain how general base models can be adapted to a speci c application domain. Afterwards, we discuss our experiences gathered in using the PROGRES language (Section 9.7 compares related work, and Section 9.8 gives a short summary.1 PROGRES at a First Glance Building tools for engineering design applications is a challenging task. Such tools operate on complicated internal data structures representing e.
CAD de- signs, manufacturing plans, SA diagrams, software architectures, or programs. In order to realize commands to be executed on such documents, sophisticated operations on the corresponding internal data structures have to be performed. Before implementing these operations in a programming language such as C, Ada, or Modula-2, a high-level speci cation is required from which the imple- mentation may be derived. To satisfy this need, the speci cation language PROGRES [Schurr and Zundorf 1996] has been developed within our group.
The PROGRES language integrates concepts from various disciplines (database systems, knowledge-based systems, graph rewriting systems, programming languages) into one coherent language whose semantics is de ned by means of logic calculus the discussion of B. Westfechtel: Managing Development Processes, LNCS 1646, pp. c Springer-Verlag Berlin Heidelberg 1999 194 9. Management Model: Formal Speci cation which goes beyond the scope of this book (see [Schurr 1991; Schurr 1996]).
Let us brie y summarize the most important language features: { PROGRES is based on attributed graphs as the underlying data model. Nodes, which may carry attributes, are connected by binary, directed relationships (edges), which may not carry attributes. { A graph schema de nes types of nodes, edges, and attributes, thereby serving as a database schema. Node types are organized into a multiple inheritance hierarchy.
All graph operations have to conform to the graph schema. { Derived data may be de ned in graph schema as well. This includes derived attributes, paths (i., derived binary relationships), restrictions (unary rela- tionships, i., conditions on nodes), and constraints. { Graph transformations are described declaratively by means of graph rewrite rules (rule-based programming style).
A graph rewrite rule essentially consists of a left-hand side | the graph pattern to be matched | and a right-hand side | the replacing subgraph. \Declarative" means that the user of PROGRES is not concerned with the algorithms for pattern matching and replacement. In particular, the left-hand sides can be very general graph patterns containing paths, restrictions, optional nodes, set nodes, negative application conditions, etc. { In addition, PROGRES o ers graph tests which can be considered graph rewrite rules performing identical replacements (i., a graph test searches for a pattern and leaves the host graph una ected).
{ In case the rule-based programming style does not suÆce, PROGRES provides control structures for calling graph rewrite rules and graph tests (sequence, branch, various forms of loops, etc. These control structures take non-determinism into account | which is inher- ent to graph rewrite rules because there are often di erent pattern matches among which one can be selected for replacement. In particular, if the appli- cation of a rule fails, backtracking is triggered so that the solution space is explored through depth- rst search. The PROGRES development environment [Schurr et al.
1995; Schurr et al. 1996; Schurr et al. 1999] o ers tightly integrated, syntax-aided tools for con- structing speci cations. The PROGRES language is hybrid in that it contains both textual and graphical parts.
The editor guarantees correctness with re- spect to the context-free syntax and checks the rules of the context-sensitive syntax incrementally. The browser supports navigation along both context-free and context-sensitive relationships (in the underlying syntax tree and along bind- ings of identi ers to their declarations, respectively). The interpreter executes an intermediate graph code which is incrementally generated from the speci cation. The tools are integrated seamlessly in that commands provided by di erent tools can be invoked in almost any order (e., the speci cation can be edited during interpretation).
In this chapter, we use PROGRES to specify the structure of the management database and the operations performed on it. Attributed graphs are well suited 9.2 Product Management Model 195 to represent version histories, con gurations, task nets, etc. in a natural way. The overall product management graph is a quite sophisticated graph structure which has to ful ll many consistency constraints.
Operations on the product management graph perform complicated changes which can be speci ed with the help of graph rewrite rules such that these consistency constraints are not violated. In the following, we present cut-outs of the speci cation of the management model developed in the SUKITS project. The speci cation fragments to be pre- sented were created with the help of the PROGRES environment, which also provides a tool for transforming the speci cation into a text-processing format. In our presentation, we do not assume that the reader is familiar with the PRO- GRES language.
Rather, the language constructs are explained as required. For further information on PROGRES, the reader is referred to [Schurr 1996; Schurr 1998].2 Product Management Model After having introduced the product management model in an informal way in Section 8.1, we now turn to its formal speci cation [Westfechtel 1994; Westfechtel 1996a]. First, we describe the schema for product management graphs , including constraints. Next, we specify consistency-preserving operations.1 Graph Schema Node classes, edge types, and attributes PROGRES is based on attributed graphs.
An attributed graph consists of nodes decorated with attributes and edges which do not carry attributes. An edge represents a binary, directed rela- tionship. When a node is deleted, all adjacent edges are deleted as well (referen- tial integrity). Furthermore, an edge may be traversed in both directions (from source to target and vice versa).
As in database management systems, the elements of graphs of a certain class | e., product management graphs to be discussed below | are declared in a graph schema. Nodes and edges are classi ed into node classes and edge types, respectively. A node class de nes the attributes which its instances will carry. An edge type de nes the classes of source and target nodes and the cardinality of its instances.
Node classes are organized into a multiple inheritance hierarchy. A subclass inherits from its superclasses all attributes and adjacent edge types. Inheritance on edge types is not supported. A graph schema may be represented both textually and graphically.1 displays a graphical schema diagram for product management graphs; later on, we will also use the textual notation as required.
In the diagram, each node class is represented by a box which contains the name of the class and its attributes. Dashed and solid arrows stand for inheritance relationships and edge types, respectively. configuration object graph DOCUMENT_OBJECT CONFIGURATION_OBJECT ––––––––––––––––––––––– is_a Variants : string [0:n] is_a 1 1 OC_Contains OD_Contains n O_Master, n object O_ActsAs OBJECT_COMPONENT O_Dependent OBJECT_DEPENDENCY OBJECT plane –––––––––––––––––––––––––– –––––––––––––––––––––––––– ––––––––––––– 1 n n OC_Variants : string [0:n] 1 OD_Variants : string [0:n] Name : string 1 1 1 1 HasHistory O_HasInstance OC_HasInstance OD_HasInstance n n n version n VERSION V_ActsAs 1 n plane n 1 ––––––––––––––––––– VERSION_COMPONENT VERSION_DEPENDENCY HISTORY VersionNo : integer 1 n n V_Master, n Predecessor, Stable : boolean V_Dependent Successor VC_Contains VD_Contains 1 1 CONFIGURATION_VERSION version graph is_a –––––––––––––––––––––– Graph schema for product management Variant : string [0:1] 9. Management Model: Formal Speci cation is_a configuration version graph DOCUMENT_VERSION –––––––––––––––––– Location : string Locked : boolean DOCUMENT_VERSION node class –––––––––––––––––– edge type inheritance Location : string Locked : boolean attributes 9.2 Product Management Model 197 The graph schema was designed according to the following rules: { Relationships, which were represented as arrows in the gures presented in Section 8.1, are modeled as nodes and adjacent edges (e., a successor rela- tionship is modeled as a HISTORY node and Predecessor/Successor edges).
This solution allows for attaching attributes to relationships, and for estab- lishing relationships between relationships. { Each subgraph of the product management graph is represented by a root node which is connected to all nodes belonging to this subgraph (e., a con- guration version graph is represented by a CONFIGURATION VERSION node which is connected to VERSION COMPONENT and VERSION DEPENDENCY nodes by VC Contains and VD Contains edges, respectively. The graph model is constructed such that subgraphs are mutually disjoint. In particular, we distin- guish between applied occurrences (e., OBJECT COMPONENT) and declarations (e.
{ Apart from HISTORY nodes, each node of the version plane is connected to the corresponding node of the object plane by an (incoming) HasInstance edge. Such a node of the version plane may be regarded as an instance of exactly one node of the object plane. In this way, the re nement relationship between object plane and version plane is represented. Note that this kind of instantiation is user-de ned (on top of PROGRES) and has to be distinguished from PROGRES instantiations (e., a node is an instance of a node class).
More speci cally, the graph schema is structured as follows: { Each OBJECT carries a unique Name attribute. The corresponding version graph contains VERSION and HISTORY nodes. VersionNo identi es a version uniquely among the versions of one object. Stable indicates whether the version may still be modi ed.
Furthermore, a DOCUMENT VERSION carries additional at- tributes Location, which identi es the place where the version contents are stored, and Locked, which indicates whether the version has been reserved for modi cation. { A CONFIGURATION OBJECT may exist in multiple structural variants each of which is a member of the Variants set1. The corresponding con guration ob- ject graph contains OBJECT COMPONENT and OBJECT DEPENDENCY nodes whose attributes indicate the variants to which they belong. Each OBJECT COMPONENT is connected to its corresponding OBJECT by an incoming O ActsAs edge.
{ A CONFIGURATION VERSION is an instance of a speci c structural Variant2. A con guration version graph contains nodes of class VERSION COMPONENT, which are connected to the corresponding VERSION and OBJECT COMPONENT by incoming V ActsAs and OC HasInstance edges, respectively, and nodes of class VERSION DEPENDENCY, each of which has an incoming OD HasInstance edge from the corresponding OBJECT DEPENDENCY. 1 For the sake of simplicity, only a single attribute for characterizing variants is intro- duced in the graph schema. 2 If structural variants are not used, the Variant attribute is absent, and the Variants set of the CONFIGURATION OBJECT is empty.
198 O_HasInstance configuration object graph Fig. 1 : CONFIGURATION Shaft OBJECT OC_Contains OD_Contains OC_Contains OD_Contains OC_Contains 2 : OBJECT O_Master 3 : OBJECT O_Dependent 4 : OBJECT O_Master 5 : OBJECT O_Dependent 6 : OBJECT COMPONENT DEPENDENCY COMPONENT DEPENDENCY COMPONENT Design RawDesign Plan OC_HasInstance OD_HasInstance OC_HasInstance OD_HasInstance OC_HasInstance Design.3 7 : VERSION V_Master 8 : VERSION V_Dependent 9 : VERSION V_Master 10 : VERSION V_Dependent 11 : VERSION COMPONENT DEPENDENCY COMPONENT DEPENDENCY COMPONENT VC_Contains VD_Contains VC_Contains VD_Contains VC_Contains 12 : CONFIGURATION configuration VERSION version graph Shaft.3 Example of a product management graph 9.