- Email: [email protected]
Integrating diagrams in CASE tools through modelling transparency
Integrating diagrams in CASE tools through modelling transparency S Brinkkemper*
Modellhlg transparency is introduced as the fimctionality of CASE tools that supports relathzg diagrams to each other. Efficient transfer between the t'arious diagram editors hi CASE tools is needed for the highly hirer-related diagrams of complex applications. Sequential dependency and parallel dependency of diagrams hz systems det'elopment pro&wts are discussed. A scale o f f our degrees of modelling transparency is h~tro&tced to positio n the modelling transparency hnplemented hz a particzdar CASE tool. The recta-model of the repository and an editor transfer chart are proposed to specify the modellhlg transparency hz CASE tools. CASE tools, diagram editors, modr models, editor transfer chart
transparency, meta-
CASE tools have gained a major place in the everyday working practice of requirements engineers. The efficiency of project performance and the effectiveness of deliverable composition improves with the availability of increasingly powerful tools. Various tedious tasks, like consistency checking, diagram storage and project management, are nowadays adequately supported. Well harmonized use of CASE tools throughout the whole systems development cycle is, however, still problematic. The lack of integration of the various tools, or parts thereof, require well co-ordinated use and accurate clerical work. Integration of CASE tools can be viewed along many dimensions (see Norman and Chen ~ for a collection of papers): systems development phase, diagramming tools, user interface, operating platform, informal and formal specification techniques, repository. This paper will focus on the integration of diagram editors in CASE tools, and for this purpose views a CASE tool as a set of diagram editors that store and retrieve diagrams in a common repository (see Figure 1). Typically, 'a CASE tool may consist of editors for entity-relationship diagrams (ERD), data flow diagrams (DFD), structure charts (SC), data dictionary (DD), control flow diagram (CFD), or any other popular diagramming technique. Design MethodologyGroup, Departm[nt of Computer Science,Universityof Twente,P.O. B6x 217, 7500 AE Enschede,The Netherlands *The paper was written while the author was at the Department of Management Sciences and Information Systems of the University of Texas at Austin, USA. This research is partially supported by grant NF 62-333/92 of the National Facility for Informaticsof The NetherlandsOrganizationfor ScientificResearch Vol 35 No 2 February 1993
The many diagrams resulting from a requirements engineering process using CASE tools are extensively inter-related. The data flow diagrams relate to data views modelled in entity-relationship diagrams, the screens of the user interaction to certain processes in the hierarchy of the DFDs, structure charts to certain database tables, and so forth. CASE tools supporting integrated diagramming techniques should enable the creation, change and removal of relationships among the diagrams and the change-over from one diagramming technique to another according to a particular dependency between the diagrams. Because of the resulting transparency of the diagrams and the diagramming techniques in relation to each other, we call this functionality of a CASE tool modellblg transparency. This term was chosen to reflect the need for coherent support of the modelling tasks of requirements engineering. Transparency indicates the absence of intermediate user operations to transfer from one diagram editor to another. The extent to which intermediate operations are needed in tools is called the 'degree of the transparency'. Apparent absence of such operations makes the one diagram transparent to the other and is defined as a high degree of modelling transparency. The presence of many intermediate operations complicates the connections between diagrams and is called a 'low degree of transparency'. This paper discusses the rationale behind modelling transparency and its support in integrated CASE tools. The following section introduces sequential and parallel dependencies between diagrams and gives some examples. The various degrees in which modelling transparency is supported by CASE tools are discussed in the third section. The fourth section explains the metamodel of the repository, which locates the presence or absence of modelling transparency. The paper concludes with some observations regarding the present status of modelling transparency in tools. DIAGRAM
DEPENDENCIES
The requirements engineering process creates an intricate web of dependencies among the diagrams of the requirements specifications. Systems development methods prescribe certain relationships between the diagramming techniques and their constituent modelling components, like entity types, data flows, processes, modules, etc. These relationships can exist between two
0950--5849/93/020101-059 1993 Butterworth-Heinemann Lid
101
hztegrathzg diagrams h~ CASE tools through modelling transparency
I
.opos,to
I
Figure I. General structure of a CASE tool "components, between a component and a diagram, or between two diagrams. Some examples of diagram dependencies are shown in Figure 2. Note, that for the sake of simplicity, the term 'diagram' is used for graphical models as well as for textual representations, like tables and (pseudo-)programming code. Figure 2 shows that the entity type 'Customer' of the ERD is related with the whole entity type description diagram, which depicts its attributes from 'Customer id' to 'Credit limit'. The latter diagram is in turn related with the SQL code which consists of its table definition and an index. Furthermore, as the requirements engineering process consists of many diagramming activities that are either in parallel or sequential, we distinguish between sequential dependencies and parallel dependencies.
Sequential dependehcy A diagram is said to be sequentially dependent on another already defined diagram if its components need to be brought into agreement with components in the other diagram. This type of dependency is introduced because various properties of artefacts belonging to the application domain are modelled in different diagrams in successive activities of the development process. Sequential dependency relates mostly to diagrams of a different type. Assume, for instance, that the entity relationship diagram of Figure 2 has been definitely established. This then gives rise to the creation of corresponding entity type descriptions of the entity types 'Customer', 'Sales rep', 'Order', and 'Article', in which the attributes will be specified. Clearly, in principle, departure from these sequential dependencies is not allowed. Should a departure be necessary, however, the analyst should consider amending the already established diagram first. A special kind of sequential dependency is related to so-called 'generative activities'. These are activities during requirements engineering, in which new diagrams are generated from available diagrams. An example is the generation of a relational database structure from an entity type description diagram, as is shown in Figure 2. Essential features in the database, such as attributes, keys and optionality, should never be modified without altering the" corresponding aspects in the entity type description.
Parallel d~pendency Two diagrams are dependent in parallel if they (I) model properties of a particular common set of artefacts, and (2) are developed in parallel with each other and 102
are more or less simultaneously established. Parallel dependencies can exist between diagrams of the Same type as well as between diagrams of a different type. For example, some entity types may be shared by the entity. relationship diagrams that model the data of two distinct processes in one application. The definitions of these entity types, including attributes, data types and cardinalities, should be in agreement with each other or be brought into agreement. As neither of the two diagrams can prescribe anything for the other, any modifications should be well co-ordinated. Today various diagrams are created and maintained by means of CASE tools, from which the requirements engineers assemble the intermediate and final specification documents. Therefore CASE tools must be able to deal with these diagram dependencies. CASE tools currently available support the placing and maintaining of dependencies to a very divergent degree. Some only allow to relate diagrams to each other as a supplementary comment: others provide direct support for the change-over from one diagramming editor to another according to an existing dependency.between the diagrams. Again other CASE tools process changes in a diagram directly in the repository and make the effect immediately visible in all related diagrams. The next section introduces a scale for the rating of implementations of modelling transparency in CASE tools. Diagram dependencies can be determined by creating a detailed process model of requirements engineering. is account 0f II
i
i
Entity-Relationship
diagram
I Or"r
contains
I/I I'1
Article J
ENTITYTYPE: Customer Entity Type Description
Ul
Customer id Name
Ul
Street City State Zip code Tel nr Fax nr Credit limit
SOL Code
CREATE TABLE C U S T O ~ R ( CUSTOMER Ie INTEGER(6) NOT NULL, NAME CHAR(32),
ST~ET CrUU~ 32).
CITY CHAR(32), STATE CHAR(2), Z I P C O D E INTEGER(5), TEL NR INTEGER (10), FAX--NR INTEGER (10), CREDIT LIMIT INTEGER(St); CREATE UNIQUE Ih~EX CUSTOMER IDX
o . CUSTOHeR (CUSTOHZR._ID)7
Figure 2. Exan~les of diagram dependencies Information and Software Technology
S BRINKKEMPER
This model, also called the meta-process model 2, gives r i s e t o sequential dependencies, when diagrams are related and are created in sequential tasks. Activities that can be performed concurrently and share modelled objects, suggest the need for parallel dependencies.
these links can only be shown by abandoning the one diagram editor, starting up the other CASE tool and displaying the other diagram with it. Because of this time-consuming process, developers will still handle many of the dependencies themselves. This is transparency degree ! (see Figure 3). Some vendors have complied their tools to a standard repository, allowing dependencies between diagrams to be recorded. However, smooth transfer from one diagram to another is not possible and therefore this degree of transparency applies. In practice, a CASE tool with this degree can only be used properly if all parallel dependencies are supported within one tool and the change-over from the one to the other tool is restricted to sequential dependencies. . A better form of modelling transparency is offered by CASE tools providing direct support in switching from one diagram to the other and back (see Figure 3). The best result is achieved if both diagrams can be shown side by side on the screen and changes to the one diagram are immediately visible in the other. This is degree 2 of modelling transparency. Assume, for instance, that a data model of a particular data store occurring in a DFD has to be constructed. Ideally one should be able to create an ERD uniquely related to the data store. Vice versa, the entity types in this ERD should allow access to the original DFD with the data store. . Transparency degree 3 is for CASE tools offering the so-called hypertext functionality (see Smith and Weiss3) and accordingly this degree is referred to as 'Hyper-CASE '4. Hyper-CASE means that the CASE tool user can place links from each component or group of components in a particular diagram to other diagrams at will. The related diagrams then become immediately accessible to each other, making it possible to traverse the dependencies of the diagrams in an arbitrary, user-defined way (see Figure 3). This is in contrast to CASE tools with transparency degree 2, which permit only those traverses established in the CASE tool. Hyper-CASE offers flexibility to the user of the CASE tool, but should only be used by very experienced developers because of the difficulties in managing the network of unstructured dependencies.
DEGRF~ES OF MODELLING TRANSPARENCY We distinguish four degrees of modelling transparency, defined in terms of the functionality of a tool (see also Brinkkemper~). Figure 3 illustrates these degrees, where it is assumed that a dependency is to be established between an entity-relationship diagram and a data flow diagram. 0. Stand-alone CASE tools with a non-accessible repository do not support modelling transparency. Users of the tool are forced to recognize and keep records of all dependencies between diagrams themselves. We call this modelling transparency degree 0 (see Figure 3). 1. CASE tools with an open, accessible repository enable dependencies to be established. However,
0
I
1
9
I
2
Repository
9 L ~
~
._.__....~--~.____~~
9 L.
"
Repository
I
9 I_
_
9 .L
J
3 H er-Case ~to~oo: (YP l l co.t.~ m ....... I
9
'}:.:.'.,
IFn~uencie~/ lu~,,~,: ,,x Ilnsoaio~: "'"
li:~etio~: ~J
/
."
,"
..."
z:.::"
'..
I~
". I ~ c ~ ~ 1 7 6 1 7 6 1 7 6 '- I X)OOO(XXX~
Figure 3. Degrees of modelling transparency Vol 35 No 2 February 1993
I I
The objective of.'a diagram technique determines which dependencies may exist, as in the examples referred to above. By making the dependencies in a diagram subject to inquiry, the CASE tool simplifies the management of dependencies by the developer. Considering this, the author concludes that CASE tools aiming at an integrated system development support should provide modelling transparency facilities. Structured system development projects involving several analysts perform best with a set of diagram dependencies that are the same for everyone. One must therefore be very careful with dynamic dependencies and hyper-CASE. 103
Integrating diagrams in CASE tools through modellhzg transparency of processes are developed in the process model. The incoming and outgoing data flows of the process are set out in the action diagram. When further completing the action diagram, the data used by the process can be inserted, while a check is carried out to ensure that these data are actually input. An example of parallel dependency is the development of a process decomposition. A process decomposition can be shown in its entirety with the help of a decomposition diagram. A horizontal level of this decomposition can be shown in the form of a data flow diagram. The addition of a process within the decomposition diagram results immediately in the addition of the same process in the data flow diagram and vice versa. It is also possible with this dependency to link up a process to another process, after which one's attention is drawn to data flows which may possibly become lost. Recently, the Application Developers Workbench, the OS-2 version of this CASE tool, became available. The multitasking capabilities provide the user to some extent with control over the degree of modelling transparency. Since all diagram editors are integrated in the repository and, moreover, can be activated concurrently in separate windows, any dependency can be visualized on the screen of the CASE tool. This feature allows dynamic configuration of diagram editors in a group to support user defined development phases and special purpose development tasks. Such a configuration should consist of editors for data modelling and process modelling for an ordinary analysis phase, but a database development project would require the diagram editors related to the data perspective to be configured together. Dynamic configuration also simplifies the derivation of guidelines for the use of a CASE tool in a certain method, the so-called 'derived method-companionship' 7. The manual of the method prescribes the various development tasks and their products, from which the most optimal configurations could be deduced.
As already mentioned, the latter may only be effective for highly qualified system developers or in one-person projects. The design and realization of modelling transparency of a set of diagramming techniques in a CASE tool within the constraints of the hardware, the operating system and its user interface are not trivial tasks. Most commercially available tools support transparency of degree 1. Dependencies between diagrams can be recorded in the repository, but are not effectuated as links between diagram editors. However, recent innovations in the operating systems technology, like graphical direct manipulation user interfaces and multitasking, offer new opportunities for the implementation of modelling transparency. This evolution is illustrated with the 'Information engineering workbench' and the 'Application development workbench '5, both from KnowledgeWare. Modelling transparency degree 2 is implemented within a workstation of the IEW. This CASE tool, running on a PC platform under MS-DOS, consists of four workstations for, respectively, the planning, analysis, design and construction phases of the hformation enghzeerh2g method 6. Not all diagram techniques are available on aU~ The workstations support a selection of the techniques according to the guidelines of the IE method, which therefore also predefines the dependencies between the diagram editors. The user interface permits the placing of several diagrams on the screen. Additions to and changes in, for instance, an Association Matrix can be shown directly in an entity-relationship diagram. To manage dependencies between diagrams created on different workstations, it is necessary to switch from one workstation to the other, which corresponds to transparency degree 1. However, the grouping of diagram editors per workstation is done in such a way that dependencies between the various workstations are exclusively sequential, which reduces the need for transfers between the workstations. Sequential and parallel dependencies occur in various forms in the IEW. For example, sequential dependency occurs in the IEW if action diagrams for the lowest level
META-MODEL
OF REPOSITORY
One way to find out what degree of modelling transparency is supported in a tool at hand is of course by testing
9 is involv1~d in
Entity type ,I,
involves ~/ /f
describes
I
,I
"t I
Process
describes
!
"~1 Attribute
" - - consTs~sof- . . . . . . . . . . . . . . .
l I
I.
source destinatTon
stores retrieves
Relationship I ,t
type
J
I
~._~. .....
9
Data store I -
?.1 -I
~.
!
i
!
! Z
Data flow
. . . . . . . . . . . . . . . . . . . . . . . . .
from
-[
J
agent
Figure 4. Partial meta-data mode/ofa CASE too/ 104
Information and Software Technology
:
S BRINKKEMPER
the tool. The repository software manuals ought to contain this information. The so-called meta-data model, i.e. the data model of the repository:, is used to disclose the diagram components and their mutual relationships. In Figure 4 a part of a meta-data model of a CASE tool (adapted from Brinkkemper et al. 7) is shown in a simplified entity-relationship notation. In the u"pper half of this model we see the components 'Entity type', 'Relationship type' and 'Attribute type' of the entity-relationship diagramming technique. Three relationships are shown, e.g. 'Attribute type describes Entity type'. The lower part shows the data flow diagramming components 'Data store', 'Data flow' 'Process' and 'External agent', and their relationships, e.g. 'Process consists of Process' depicts the decomposition of processes in data flow diagrams. Besides these are the dependencies between both diagramming techniques denoted with dashed relationships. We can infer that the tool facilitates the specification of data models in ERDs of data stores and data flows. Vice versa, the data stores and data flows can be related to entity types, relationship types, or attributes in which these are involved. The ability to transfer from the ERD editor to the DFD editor and back can be ttepicted in a so-called 'editor transfer' chart. A sample of such a diagram is shown in Figure 5. It represents the diagram editors in a kind of state transition diagram. An arrow with the name of a diagram component denotes the capability of the tool to transfer from the one editor to the other by choosing (or clicking) any of the instances of the component. For example, the editor transfer chart in Figure 5 reveals that one can transfer from the ERD editor to the DFD editor via an instance of an entity type. The option to descend through a DFD decomposition hierarchy (in some tools called the 'explosion option') is depicted by the 'subprocess' arrow looping from and to the DFD editor. The chart in Figure 5 is not, of course, intended to be a complete chart. The meta-model of the repository and the editor transfer chart contain valuable information for CASE tool users, which is not solely related to the support of modelling transparency. For instance, editor transfer charts also help planning the use of the various editors in the requirements engineering process. We therefore advocate the inclusion of both diagrams in CASE tool manuals. subprocess
""I" Figure 5. Sample editor transfer chart Vol 35 No 2 February 1993
$ubprocess
CONCLUSIONS Support of modelling transparency is an important functionality to increase the productivity of CASE tools. Next to more overall criteria, like lifecycle coverage, supported diagramming techniques and reporting facilities 8, it may serve as one of the quality requirements in a tool selection or tool evaluation process. Modern window-based user interfaces demand a proper implementation of modelling transparency in CASE tools. Analysis of the diagramming techniques and their inter-relationships resulting into a meta-model, will assist CASE tool developers to design a Well-motivated network of dependencies denoted in an editor transfer chart. Transfer links between the diagram editors can be implemented accordingly. The question whether dynamic links, or hyper-CASE should be implemented, depends on the envisioned calibre of its users and the type of the applications. Highly qualified requirements engineers or complex applications may benefit from customizable diagram linkage. The scale of modelling transparency, as presented above, could be refined by distinguishing placement, alteration and removal of dependencies, or b y differentiating the extent to which tool repositories are integrated. However, the magnitude of variations that could be possible would obscure a simple linear scale ofdegrees. The author invites readers to check upon the support of modelling transparency and the associated degree in their favourite tools*. Meta-models and editor transfer charts can be derived from tool functionality and its manuals. Although a truly integrated CASE environment is not achieved just by having a high degree of modelling transparency, we believe its support is one of the absolute requirements for advanced systems development. REFERENCES 1 Norman, R J and Chen, M (eds) 'Integrated CASE' IEEE Soft. Vol 9 No 2 (March 1992) 2 Brinkkemper,S Formalisation of h~formation systems modellingThesis Publishers,Amsterdam,The Netherlands(1990) 3 Smith, J B and Weiss, S F 'Hypertext' Comm. ACM Special issue on Hypertext, Vol 31 No 7 (July 1988) pp 816-819 4 Cyhulski, J L and Reed, K 'A hypertext based software engineering environment' IEEE Soft. Vol 9 No 2 (March 1992) pp 62-68 KnoMedgeWare, 'Application development workbench' Users' Guhte (1990) and 'Information engineering workbench ESP' Plannhlg, Analysis and Design IVorkstation Guide (1988) 6 Martin, J lnfor~tation enghwerhlg Vol 1, 2 and 3 Savant Research Studies, Lancashire (1988) 7 Brinkkemper,S, de Lange, M, Lnoman,R and van der Steen, F H G C 'On the derivation of method companionship by 9 meta-modelling' Soft. Eng. Notes, Journal of the Special Interest Group on Software Engineering of the ACM Vol 15 N o l (January 1990) pp 49-58 8 Mimno, P R 'Survey of CASE-tools' in Ng, P A and Yeh, R T (eds) Modern software enghleerhlg:foundations and current perspectires Van Nostrand Reinhold (1990) pp 323-350 *Correspondence, including meta-models and editor transfer charts, can be addressed to the author
105
Modellhlg transparency is introduced as the fimctionality of CASE tools that supports relathzg diagrams to each other. Efficient transfer between the t'arious diagram editors hi CASE tools is needed for the highly hirer-related diagrams of complex applications. Sequential dependency and parallel dependency of diagrams hz systems det'elopment pro&wts are discussed. A scale o f f our degrees of modelling transparency is h~tro&tced to positio n the modelling transparency hnplemented hz a particzdar CASE tool. The recta-model of the repository and an editor transfer chart are proposed to specify the modellhlg transparency hz CASE tools. CASE tools, diagram editors, modr models, editor transfer chart
transparency, meta-
CASE tools have gained a major place in the everyday working practice of requirements engineers. The efficiency of project performance and the effectiveness of deliverable composition improves with the availability of increasingly powerful tools. Various tedious tasks, like consistency checking, diagram storage and project management, are nowadays adequately supported. Well harmonized use of CASE tools throughout the whole systems development cycle is, however, still problematic. The lack of integration of the various tools, or parts thereof, require well co-ordinated use and accurate clerical work. Integration of CASE tools can be viewed along many dimensions (see Norman and Chen ~ for a collection of papers): systems development phase, diagramming tools, user interface, operating platform, informal and formal specification techniques, repository. This paper will focus on the integration of diagram editors in CASE tools, and for this purpose views a CASE tool as a set of diagram editors that store and retrieve diagrams in a common repository (see Figure 1). Typically, 'a CASE tool may consist of editors for entity-relationship diagrams (ERD), data flow diagrams (DFD), structure charts (SC), data dictionary (DD), control flow diagram (CFD), or any other popular diagramming technique. Design MethodologyGroup, Departm[nt of Computer Science,Universityof Twente,P.O. B6x 217, 7500 AE Enschede,The Netherlands *The paper was written while the author was at the Department of Management Sciences and Information Systems of the University of Texas at Austin, USA. This research is partially supported by grant NF 62-333/92 of the National Facility for Informaticsof The NetherlandsOrganizationfor ScientificResearch Vol 35 No 2 February 1993
The many diagrams resulting from a requirements engineering process using CASE tools are extensively inter-related. The data flow diagrams relate to data views modelled in entity-relationship diagrams, the screens of the user interaction to certain processes in the hierarchy of the DFDs, structure charts to certain database tables, and so forth. CASE tools supporting integrated diagramming techniques should enable the creation, change and removal of relationships among the diagrams and the change-over from one diagramming technique to another according to a particular dependency between the diagrams. Because of the resulting transparency of the diagrams and the diagramming techniques in relation to each other, we call this functionality of a CASE tool modellblg transparency. This term was chosen to reflect the need for coherent support of the modelling tasks of requirements engineering. Transparency indicates the absence of intermediate user operations to transfer from one diagram editor to another. The extent to which intermediate operations are needed in tools is called the 'degree of the transparency'. Apparent absence of such operations makes the one diagram transparent to the other and is defined as a high degree of modelling transparency. The presence of many intermediate operations complicates the connections between diagrams and is called a 'low degree of transparency'. This paper discusses the rationale behind modelling transparency and its support in integrated CASE tools. The following section introduces sequential and parallel dependencies between diagrams and gives some examples. The various degrees in which modelling transparency is supported by CASE tools are discussed in the third section. The fourth section explains the metamodel of the repository, which locates the presence or absence of modelling transparency. The paper concludes with some observations regarding the present status of modelling transparency in tools. DIAGRAM
DEPENDENCIES
The requirements engineering process creates an intricate web of dependencies among the diagrams of the requirements specifications. Systems development methods prescribe certain relationships between the diagramming techniques and their constituent modelling components, like entity types, data flows, processes, modules, etc. These relationships can exist between two
0950--5849/93/020101-059 1993 Butterworth-Heinemann Lid
101
hztegrathzg diagrams h~ CASE tools through modelling transparency
I
.opos,to
I
Figure I. General structure of a CASE tool "components, between a component and a diagram, or between two diagrams. Some examples of diagram dependencies are shown in Figure 2. Note, that for the sake of simplicity, the term 'diagram' is used for graphical models as well as for textual representations, like tables and (pseudo-)programming code. Figure 2 shows that the entity type 'Customer' of the ERD is related with the whole entity type description diagram, which depicts its attributes from 'Customer id' to 'Credit limit'. The latter diagram is in turn related with the SQL code which consists of its table definition and an index. Furthermore, as the requirements engineering process consists of many diagramming activities that are either in parallel or sequential, we distinguish between sequential dependencies and parallel dependencies.
Sequential dependehcy A diagram is said to be sequentially dependent on another already defined diagram if its components need to be brought into agreement with components in the other diagram. This type of dependency is introduced because various properties of artefacts belonging to the application domain are modelled in different diagrams in successive activities of the development process. Sequential dependency relates mostly to diagrams of a different type. Assume, for instance, that the entity relationship diagram of Figure 2 has been definitely established. This then gives rise to the creation of corresponding entity type descriptions of the entity types 'Customer', 'Sales rep', 'Order', and 'Article', in which the attributes will be specified. Clearly, in principle, departure from these sequential dependencies is not allowed. Should a departure be necessary, however, the analyst should consider amending the already established diagram first. A special kind of sequential dependency is related to so-called 'generative activities'. These are activities during requirements engineering, in which new diagrams are generated from available diagrams. An example is the generation of a relational database structure from an entity type description diagram, as is shown in Figure 2. Essential features in the database, such as attributes, keys and optionality, should never be modified without altering the" corresponding aspects in the entity type description.
Parallel d~pendency Two diagrams are dependent in parallel if they (I) model properties of a particular common set of artefacts, and (2) are developed in parallel with each other and 102
are more or less simultaneously established. Parallel dependencies can exist between diagrams of the Same type as well as between diagrams of a different type. For example, some entity types may be shared by the entity. relationship diagrams that model the data of two distinct processes in one application. The definitions of these entity types, including attributes, data types and cardinalities, should be in agreement with each other or be brought into agreement. As neither of the two diagrams can prescribe anything for the other, any modifications should be well co-ordinated. Today various diagrams are created and maintained by means of CASE tools, from which the requirements engineers assemble the intermediate and final specification documents. Therefore CASE tools must be able to deal with these diagram dependencies. CASE tools currently available support the placing and maintaining of dependencies to a very divergent degree. Some only allow to relate diagrams to each other as a supplementary comment: others provide direct support for the change-over from one diagramming editor to another according to an existing dependency.between the diagrams. Again other CASE tools process changes in a diagram directly in the repository and make the effect immediately visible in all related diagrams. The next section introduces a scale for the rating of implementations of modelling transparency in CASE tools. Diagram dependencies can be determined by creating a detailed process model of requirements engineering. is account 0f II
i
i
Entity-Relationship
diagram
I Or"r
contains
I/I I'1
Article J
ENTITYTYPE: Customer Entity Type Description
Ul
Customer id Name
Ul
Street City State Zip code Tel nr Fax nr Credit limit
SOL Code
CREATE TABLE C U S T O ~ R ( CUSTOMER Ie INTEGER(6) NOT NULL, NAME CHAR(32),
ST~ET CrUU~ 32).
CITY CHAR(32), STATE CHAR(2), Z I P C O D E INTEGER(5), TEL NR INTEGER (10), FAX--NR INTEGER (10), CREDIT LIMIT INTEGER(St); CREATE UNIQUE Ih~EX CUSTOMER IDX
o . CUSTOHeR (CUSTOHZR._ID)7
Figure 2. Exan~les of diagram dependencies Information and Software Technology
S BRINKKEMPER
This model, also called the meta-process model 2, gives r i s e t o sequential dependencies, when diagrams are related and are created in sequential tasks. Activities that can be performed concurrently and share modelled objects, suggest the need for parallel dependencies.
these links can only be shown by abandoning the one diagram editor, starting up the other CASE tool and displaying the other diagram with it. Because of this time-consuming process, developers will still handle many of the dependencies themselves. This is transparency degree ! (see Figure 3). Some vendors have complied their tools to a standard repository, allowing dependencies between diagrams to be recorded. However, smooth transfer from one diagram to another is not possible and therefore this degree of transparency applies. In practice, a CASE tool with this degree can only be used properly if all parallel dependencies are supported within one tool and the change-over from the one to the other tool is restricted to sequential dependencies. . A better form of modelling transparency is offered by CASE tools providing direct support in switching from one diagram to the other and back (see Figure 3). The best result is achieved if both diagrams can be shown side by side on the screen and changes to the one diagram are immediately visible in the other. This is degree 2 of modelling transparency. Assume, for instance, that a data model of a particular data store occurring in a DFD has to be constructed. Ideally one should be able to create an ERD uniquely related to the data store. Vice versa, the entity types in this ERD should allow access to the original DFD with the data store. . Transparency degree 3 is for CASE tools offering the so-called hypertext functionality (see Smith and Weiss3) and accordingly this degree is referred to as 'Hyper-CASE '4. Hyper-CASE means that the CASE tool user can place links from each component or group of components in a particular diagram to other diagrams at will. The related diagrams then become immediately accessible to each other, making it possible to traverse the dependencies of the diagrams in an arbitrary, user-defined way (see Figure 3). This is in contrast to CASE tools with transparency degree 2, which permit only those traverses established in the CASE tool. Hyper-CASE offers flexibility to the user of the CASE tool, but should only be used by very experienced developers because of the difficulties in managing the network of unstructured dependencies.
DEGRF~ES OF MODELLING TRANSPARENCY We distinguish four degrees of modelling transparency, defined in terms of the functionality of a tool (see also Brinkkemper~). Figure 3 illustrates these degrees, where it is assumed that a dependency is to be established between an entity-relationship diagram and a data flow diagram. 0. Stand-alone CASE tools with a non-accessible repository do not support modelling transparency. Users of the tool are forced to recognize and keep records of all dependencies between diagrams themselves. We call this modelling transparency degree 0 (see Figure 3). 1. CASE tools with an open, accessible repository enable dependencies to be established. However,
0
I
1
9
I
2
Repository
9 L ~
~
._.__....~--~.____~~
9 L.
"
Repository
I
9 I_
_
9 .L
J
3 H er-Case ~to~oo: (YP l l co.t.~ m ....... I
9
'}:.:.'.,
IFn~uencie~/ lu~,,~,: ,,x Ilnsoaio~: "'"
li:~etio~: ~J
/
."
,"
..."
z:.::"
'..
I~
". I ~ c ~ ~ 1 7 6 1 7 6 1 7 6 '- I X)OOO(XXX~
Figure 3. Degrees of modelling transparency Vol 35 No 2 February 1993
I I
The objective of.'a diagram technique determines which dependencies may exist, as in the examples referred to above. By making the dependencies in a diagram subject to inquiry, the CASE tool simplifies the management of dependencies by the developer. Considering this, the author concludes that CASE tools aiming at an integrated system development support should provide modelling transparency facilities. Structured system development projects involving several analysts perform best with a set of diagram dependencies that are the same for everyone. One must therefore be very careful with dynamic dependencies and hyper-CASE. 103
Integrating diagrams in CASE tools through modellhzg transparency of processes are developed in the process model. The incoming and outgoing data flows of the process are set out in the action diagram. When further completing the action diagram, the data used by the process can be inserted, while a check is carried out to ensure that these data are actually input. An example of parallel dependency is the development of a process decomposition. A process decomposition can be shown in its entirety with the help of a decomposition diagram. A horizontal level of this decomposition can be shown in the form of a data flow diagram. The addition of a process within the decomposition diagram results immediately in the addition of the same process in the data flow diagram and vice versa. It is also possible with this dependency to link up a process to another process, after which one's attention is drawn to data flows which may possibly become lost. Recently, the Application Developers Workbench, the OS-2 version of this CASE tool, became available. The multitasking capabilities provide the user to some extent with control over the degree of modelling transparency. Since all diagram editors are integrated in the repository and, moreover, can be activated concurrently in separate windows, any dependency can be visualized on the screen of the CASE tool. This feature allows dynamic configuration of diagram editors in a group to support user defined development phases and special purpose development tasks. Such a configuration should consist of editors for data modelling and process modelling for an ordinary analysis phase, but a database development project would require the diagram editors related to the data perspective to be configured together. Dynamic configuration also simplifies the derivation of guidelines for the use of a CASE tool in a certain method, the so-called 'derived method-companionship' 7. The manual of the method prescribes the various development tasks and their products, from which the most optimal configurations could be deduced.
As already mentioned, the latter may only be effective for highly qualified system developers or in one-person projects. The design and realization of modelling transparency of a set of diagramming techniques in a CASE tool within the constraints of the hardware, the operating system and its user interface are not trivial tasks. Most commercially available tools support transparency of degree 1. Dependencies between diagrams can be recorded in the repository, but are not effectuated as links between diagram editors. However, recent innovations in the operating systems technology, like graphical direct manipulation user interfaces and multitasking, offer new opportunities for the implementation of modelling transparency. This evolution is illustrated with the 'Information engineering workbench' and the 'Application development workbench '5, both from KnowledgeWare. Modelling transparency degree 2 is implemented within a workstation of the IEW. This CASE tool, running on a PC platform under MS-DOS, consists of four workstations for, respectively, the planning, analysis, design and construction phases of the hformation enghzeerh2g method 6. Not all diagram techniques are available on aU~ The workstations support a selection of the techniques according to the guidelines of the IE method, which therefore also predefines the dependencies between the diagram editors. The user interface permits the placing of several diagrams on the screen. Additions to and changes in, for instance, an Association Matrix can be shown directly in an entity-relationship diagram. To manage dependencies between diagrams created on different workstations, it is necessary to switch from one workstation to the other, which corresponds to transparency degree 1. However, the grouping of diagram editors per workstation is done in such a way that dependencies between the various workstations are exclusively sequential, which reduces the need for transfers between the workstations. Sequential and parallel dependencies occur in various forms in the IEW. For example, sequential dependency occurs in the IEW if action diagrams for the lowest level
META-MODEL
OF REPOSITORY
One way to find out what degree of modelling transparency is supported in a tool at hand is of course by testing
9 is involv1~d in
Entity type ,I,
involves ~/ /f
describes
I
,I
"t I
Process
describes
!
"~1 Attribute
" - - consTs~sof- . . . . . . . . . . . . . . .
l I
I.
source destinatTon
stores retrieves
Relationship I ,t
type
J
I
~._~. .....
9
Data store I -
?.1 -I
~.
!
i
!
! Z
Data flow
. . . . . . . . . . . . . . . . . . . . . . . . .
from
-[
J
agent
Figure 4. Partial meta-data mode/ofa CASE too/ 104
Information and Software Technology
:
S BRINKKEMPER
the tool. The repository software manuals ought to contain this information. The so-called meta-data model, i.e. the data model of the repository:, is used to disclose the diagram components and their mutual relationships. In Figure 4 a part of a meta-data model of a CASE tool (adapted from Brinkkemper et al. 7) is shown in a simplified entity-relationship notation. In the u"pper half of this model we see the components 'Entity type', 'Relationship type' and 'Attribute type' of the entity-relationship diagramming technique. Three relationships are shown, e.g. 'Attribute type describes Entity type'. The lower part shows the data flow diagramming components 'Data store', 'Data flow' 'Process' and 'External agent', and their relationships, e.g. 'Process consists of Process' depicts the decomposition of processes in data flow diagrams. Besides these are the dependencies between both diagramming techniques denoted with dashed relationships. We can infer that the tool facilitates the specification of data models in ERDs of data stores and data flows. Vice versa, the data stores and data flows can be related to entity types, relationship types, or attributes in which these are involved. The ability to transfer from the ERD editor to the DFD editor and back can be ttepicted in a so-called 'editor transfer' chart. A sample of such a diagram is shown in Figure 5. It represents the diagram editors in a kind of state transition diagram. An arrow with the name of a diagram component denotes the capability of the tool to transfer from the one editor to the other by choosing (or clicking) any of the instances of the component. For example, the editor transfer chart in Figure 5 reveals that one can transfer from the ERD editor to the DFD editor via an instance of an entity type. The option to descend through a DFD decomposition hierarchy (in some tools called the 'explosion option') is depicted by the 'subprocess' arrow looping from and to the DFD editor. The chart in Figure 5 is not, of course, intended to be a complete chart. The meta-model of the repository and the editor transfer chart contain valuable information for CASE tool users, which is not solely related to the support of modelling transparency. For instance, editor transfer charts also help planning the use of the various editors in the requirements engineering process. We therefore advocate the inclusion of both diagrams in CASE tool manuals. subprocess
""I" Figure 5. Sample editor transfer chart Vol 35 No 2 February 1993
$ubprocess
CONCLUSIONS Support of modelling transparency is an important functionality to increase the productivity of CASE tools. Next to more overall criteria, like lifecycle coverage, supported diagramming techniques and reporting facilities 8, it may serve as one of the quality requirements in a tool selection or tool evaluation process. Modern window-based user interfaces demand a proper implementation of modelling transparency in CASE tools. Analysis of the diagramming techniques and their inter-relationships resulting into a meta-model, will assist CASE tool developers to design a Well-motivated network of dependencies denoted in an editor transfer chart. Transfer links between the diagram editors can be implemented accordingly. The question whether dynamic links, or hyper-CASE should be implemented, depends on the envisioned calibre of its users and the type of the applications. Highly qualified requirements engineers or complex applications may benefit from customizable diagram linkage. The scale of modelling transparency, as presented above, could be refined by distinguishing placement, alteration and removal of dependencies, or b y differentiating the extent to which tool repositories are integrated. However, the magnitude of variations that could be possible would obscure a simple linear scale ofdegrees. The author invites readers to check upon the support of modelling transparency and the associated degree in their favourite tools*. Meta-models and editor transfer charts can be derived from tool functionality and its manuals. Although a truly integrated CASE environment is not achieved just by having a high degree of modelling transparency, we believe its support is one of the absolute requirements for advanced systems development. REFERENCES 1 Norman, R J and Chen, M (eds) 'Integrated CASE' IEEE Soft. Vol 9 No 2 (March 1992) 2 Brinkkemper,S Formalisation of h~formation systems modellingThesis Publishers,Amsterdam,The Netherlands(1990) 3 Smith, J B and Weiss, S F 'Hypertext' Comm. ACM Special issue on Hypertext, Vol 31 No 7 (July 1988) pp 816-819 4 Cyhulski, J L and Reed, K 'A hypertext based software engineering environment' IEEE Soft. Vol 9 No 2 (March 1992) pp 62-68 KnoMedgeWare, 'Application development workbench' Users' Guhte (1990) and 'Information engineering workbench ESP' Plannhlg, Analysis and Design IVorkstation Guide (1988) 6 Martin, J lnfor~tation enghwerhlg Vol 1, 2 and 3 Savant Research Studies, Lancashire (1988) 7 Brinkkemper,S, de Lange, M, Lnoman,R and van der Steen, F H G C 'On the derivation of method companionship by 9 meta-modelling' Soft. Eng. Notes, Journal of the Special Interest Group on Software Engineering of the ACM Vol 15 N o l (January 1990) pp 49-58 8 Mimno, P R 'Survey of CASE-tools' in Ng, P A and Yeh, R T (eds) Modern software enghleerhlg:foundations and current perspectires Van Nostrand Reinhold (1990) pp 323-350 *Correspondence, including meta-models and editor transfer charts, can be addressed to the author
105