Entity relationship modeling in object-oriented software development

ABSTRACT

In a course in Database Concepts, students design a database of their own choice. They use the Entity-Relationship approach to high level design. Students may be too free in expressing their designs with the ER approach, drawing connecting lines where inappropriate (between relationship figures), as paper and pencil do not sufficiently constrain their enthusiasm. This is similar to what is seen too often in the design of software generally. The diagram indicates that “dependent” is a weak entity set with defining relationship “Parent”, that “ssn” is the key to “employee” and that “supervision” is one-to-many from “supervisors” to “employee”. “Manages” is a one-one relationship. The software will also output a list of data definition templates for SQL, a popular relational database front end. A portion of the output for the above ER diagram is: CREATE TABLE employee ( ssn (), name (), managesdno (), supervisionssn () ); CREATE TABLE worksFor ( percentTime (), ssn (), dno () ), I have recently developed an application for Entity-Relationship modeling on a microcomputer. The software permits the database designer to sketch an ER diagram and to indicate several important properties of the design (weak entity sets, cardinality, categories, etc.). The software was developed using Object Pascal and runs on the Macintosh. An example appears below. This technique has a potentially greater impact, however, on the design of software systems generally. I have been exploring the idea of using the ER technique for logical design of abstract data types modeled on entities of the problem space. In object-oriented programming it is very useful to model such entities as objects in the system. Generally, these entities have some variable state and may exhibit some actions. This is highly consistent with the notion of an object in the sense of Smalltalk. As an example of the use of this technique in the early design of a software system consider the following example ER diagram which is an overview of the data types within the Entity-Relationship program itself. The program has two major data types. These items are commands and screen_shapes. Screen_shapes are composed of lines and other shapes and these have different properties. Three kinds of commands are needed, to modify screen_shapes and text_streams. The relationships (diamonds) show the necessary interactions between the entities. Early knowledge of these interactions aids the designer in choosing appropriate representations of the state variables of each data type. One may take the view that the relationship “modifies” between key_handlers and text_streams may be defined in terms of actions such as “enter”, “cut”, “paste”, “select”, “move”, and “undo”. These must be specified early on as a means of defining the user interface. We are a long way toward knowing what a text_stream must look like, as well as a key_handler. This technique, of modeling the data with ER diagrams, is most useful if the development will be undertaken using an object-oriented system, as the state and procedure information may be encapsulated within the objects themselves. Thus, the above mentioned software has objects to model screen_shapes and objects to represent commands and these encapsulate the ideas made visible in the ER diagram.

INDEX TERMS

Primary Classification:
  K. Computing Milieux
  K.6 MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS
      K.6.3 Software Management
          Subjects: Software development

Additional Classification:
  D. Software
  D.1 PROGRAMMING TECHNIQUES

  I. Computing Methodologies
  I.6 SIMULATION AND MODELING

General Terms:
Design, Management, Performance, Theory