CRUD Matrices for Detailed Object
Oriented Design
Journal of Computing Sciences in Colleges, Volume 18, Number 2
Daniel Brandon, Jr., Ph.D.
Christian Brothers University
Information Technology Management Department
650 East Parkway South
Memphis, TN 38104
Dbrandon@cbu.edu, 901.321.3615 [voice], 901.321.3566 [fax]
CRUD Matrices for Detailed Object Oriented Design
Introduction
CRUD (“create”, “read”, “update”, “delete”) analysis has been well established in
classical software systems analysis and design for many years. A classical CRUD matrix
maps data to process to action (C or R or U or D). One of the three dimensions goes on
the columns, another of the three goes on the rows, and another of the three goes in the
cells. Typically a classical CRUD matrix is created with the rows corresponding to data
items (records, database tables, or entities) such as “Employee” and the columns
corresponding to processes (applications, programs, procedures, screens, etc.) such as
“Hire” or “Payroll”. The cells of the matrix have the letters “C”, “R”, “U”, “D” indicating
that a particular process does one (or more) of these actions with/to a particular data item.
Another version for GUI systems, may have the data entities areas as major rows (such as
the Employee Screen) with the sub-processes as minor rows (actions available from that
screen). In this approach, the columns are labeled C R U D; then there are check marks in
the cells indicating what action each screen performs with regard to that entity.
Recently CRUD methods have been applied to object oriented (OO) analysis and
design. This paper describes and illustrates (via a small case study) a methodology for
applying CRUD principles to the detailed phase of object oriented design. When so
applied, the consistency between the static and dynamic models of a system can be better
visualized and reinforced. This is particularly helpful within teaching and learning
environments such as college software design and/or object oriented courses.
Background
Early in the evolution of OO methods, CRUD was not a part of the typical OO
analysis. Since OO software development involves classes and incorporates
“encapsulation”, each class should be constructed with create, read, update, and methods
(operations) for each attribute and relationship (data structure) of the class ( Dewitz,
1996; Satzinger, 2001; Brown, 2002). However the existence of an operation in a class
does not indicate where that operation is used, or even if the operation is used at all. It has
been further suggested that possibly each attribute of each class be checked for Read,
Update, and Clear (Brown, 2002); essentially the convention of providing “get” and “set”
encapsulation methods for each attribute.
More recently in the OO world, several authors have introduced and studied the
topic of an OO CRUD analysis. (Armour, 2001) The level at which these analyses have
been done revolves around the “use cases” or “scenarios”. One approach list use cases
along one axis (such as the columns) and object types along another axis (such as the
rows). Then the letters C R U D are placed in the matrix cells. This is illustrated in Figure
1 for the case study presented below.
In another approach, each scenario and the objects types (or “classes”) involved
are shown in a row of the CRUD diagram, and there is a column for each of the C R U D
letters. This approach realizes the OO nature of the system, namely that the processes are
encapsulated in the object types. Then a check mark is placed in the row and column
indicating where and how the object type is involved. This is illustrated in Figure 2 for
the case study presented below.
Detailed OO CRUD
CRUD analysis at the scenario level only suggests that each object type is created,
deleted, used, and updated during some scenarios. Each scenario is going to be detailed
typically in UML with one (or more) of the dynamic design drawings such as activity
(event) diagrams, state transition diagrams, sequence diagrams, or collaboration
diagrams. [Scott, 2001; Fowler, 2000] As well as the UML dynamic drawings, there will
be a static (structure) diagram showing the relationships between the classes and the class
attributes and operations. Before code generation (either automatic or manual), there is a
need to establish several types of consistency in the OO model [Erikson, 1998]:
Are the operations defined within each class in the static model, the same
as the operations shown in the dynamic diagrams.
Is each operation defined in the dynamic diagrams associated with one
class, or is that operation to be expanded into several lower level
operations.
Is the class containing that operation capable of performing the operation,
either individually or in collaboration with other class operations.
Does each class operation have at least one usage.
Is each object type created (C) in some specific operation.
Is each object deleted (D) in some specific operation.
Is each object read (R) in some specific operation, otherwise one questions
the need for that object.
Is each object type updated (U) in some specific operation.
We have devised a “Detailed OO CRUD Diagram” approach to answer these
consistency/completeness questions as well as to quantify the relationship between where
an operation is defined and where it is to be utilized. In our method the rows of the
CRUD matrix are used for the individual operations of each class and the columns
represent either the CRUD letters or a column to show where that operation is expanded
into lower level diagram (or a collaboration sequence). The cells of the matrix indicate
the dynamic drawing references to the use of the operation.
Case Study Illustration
For a small scale teaching example of the use of OO CRUD, the case study of a
freight dispatching operation is used here. The case study involves a company that has
trucks it dispatches to pick up freight from local customers. The local pick up region is
divided into geographic “areas”. Each customer is associated with one area, and each
truck serves one or more areas. The UML structure (static) diagram is shown in Figure 3.
The aggregation relations are “one-to-many” unless otherwise indicated. Object types
(classes) for the two transactions, freight (order) and assignment, are shown on the
diagram as well as the Date and Area object types. For simplicity here, we are only
defining two use cases (or scenarios). The first is the assignment of the freight, and the
second is a display of the loads (for all the trucks).
At some point in the OO modeling process, complete class diagrams (“expanded
class diagrams) will be completed such as shown in Figure 4. In that figure for the
Company object type, both the attributes and operations are specified. Different OO
modelers fully specify the attributes and operations at different points in their
methodology. Some designers use a “responsibility” methodology that defines the
operations first, and later determines the attribute content of the classes necessary to carry
out those operations. Other designers use a “data driven” approach, where the attributes
are specified first. In this small example here, we will work with the operations first, and
the CRUD approach here applies to this operation determination.
The main scenario of the dynamic portion of the model is shown in the UML
activity diagram of Figure 5 (activity diagram D1). Here a customer communicates an
order to the company (via phone or internet), and the company must assign a truck and
date for the freight pick up. As shown in that diagram, Customer objects are created (for
new customers) and Freight objects are created. In our activity diagrams here, we are
showing the object type which contains the operation via the stereotype notation.
(Brandon, 2002) We are also giving the operations a code number for shorthand use in
the detailed CRUD.
Figure 5 does not break the operations down to the lowest level (Martin, 1998). At
the lowest level an operation either creates an object, destroys an object, changes the state
of an object (by changing attribute values and/or relationships), or queries an object
(Martin, 1998). Figure 6 (activity diagram D2) shows a lower level activity diagram for
the expansion of the “assign freight” (O8) operation in Figure 5. Here we must go
through all the company’s trucks and find the first truck serving the customer’s area that
has room for the customer’s freight today; if not today, then the next day and so on.
Figure 7 (activity diagram D3) shows a lower level activity diagram for the expansion of
the “room on truck ?” (O5) operation in Figure 6. Here we must go through all the
assignments for a particular truck and date and sum the size and weight; then compare
these sums to the size and weight of the current freight object to see if it will fit on that
truck for that date.
Figure 8 shows the activity diagram (D4) for another scenario, namely displaying
the loads for each of the company’s trucks. Figure F9 (D5) is an expansion of the display
assignment operation (O2) in Figure 8.
Once the activity diagrams are completed (for all the required scenarios), the
expanded class diagrams (such as in Figure 4) can be completed for the operations of
each class. Again the stereotype notation of the operations in the class diagrams shows
which class will contain that operation.
Again, Figure 2 shows a CRUD diagram for the two scenarios (or use cases), and
this approach has been used by others in the field. Figure 10 shows our use of a so called
“Detailed OO CRUD” diagram, to access the completeness of dynamic model. The
operations on the activity diagram (and shown in the expanded class diagrams) are
mapped to the five columns on the CRUD spreadsheet. For completeness:
Each class operation has at least one usage (shows an activity diagram
reference via diagram number and operation code), and our ‘check’
column is used for that here. The ‘Expand’ column indicates that
an operation’s detail is expanded in a lower level activity diagram.
Each object type is created (C) in some operation.
Each object is deleted (D) in some operation (unless deletion is outside of
the scope of this model).
Each object should be read (R) in some operation, otherwise one questions
the need for that object.
Each object type is updated (U) in some operation, unless that object is
static in the model (such as dates and areas).
Through use of the detailed CRUD diagram, the activity diagrams are corrected
and refined as needed. Detailed CRUD diagrams may be done separately for each
scenario, and then merged into a master detail CRUD. In our small example here, both
scenarios were shown in one detailed CRUD diagram.
Next the OO language code (typically Java or C++) for “class skeletons” can be
automatically generated from the static and dynamic diagrams. Most UML products can
do such automatic generation and the generation of the skeleton classes can be “tailored”
via scripting capabilities in some UML products. An example of such a skeleton (for the
Company class) is shown in Figure 11. In our generation, we are using the Java language
with “type safe” vectors for the aggregations. Listing 1 shows the full Java code for the
classes as well as the “main” driver function.
Conclusion
We have presented and illustrated a methodology to analyze the completeness and
consistency of OO models, particularly those represented in UML drawings. The
methodology extends the CRUD approach down to the individual operations contained in
the OO classes. We have found this methodology useful both in improving the resulting
designs, and in the improved understanding of the entire OO design process by IT
students.
References
Armour, Frank and Miller, Granville. Advanced Use Case Modeling: Software Systems,
Addison Wesley, 2001
Bahrami, Ali. Object Oriented Systems Development, McGraw Hill, 1999
Brandon, Daniel. “Use of UML Stereotypes in Business Models”, Issues and Trends of
Information Technology Management in Contemporary Organizations, ISBN 1-93070839-4(print); ISBN 1-59140-031-7 (CD-Rom), Information Resources Management
Association (IRMA) Conference, May, 2002, Seattle, WA
Brown, David. An Introduction to Object Oriented Analysis, Wiley, 2002
Coad, Peter. Object Models: Strategies, Patterns, and Applications, Yourdon Press, 1997
Dewitz, Sandra. Systems Analysis and Design and the Transition to Objects, McGraw
Hill, 1996
Erikson, H. and Penker, M., UML Toolkit, Wiley, 1998
Fowler, Martin. UML Distilled, Addison-Wesley, 2000
Martin, James and Odell, James. Object Oriented Methods: A Foundation, Prentiss Hall,
1998
Satzinger, J. and Orvik, T., The Object Oriented Approach, Course Technology, 2001
Schach, Stephen. Object-Oriented and Classical Software Engineering, McGraw Hill,
2002
Scott, Kendall. UML Explained, Addison-Wesley, 2001
Figure 1
Use Cases
Assign Freight
Display Loads
Area
R
R
Company
R
R
Truck
RU
R
Customer
CU
R
Freight
CRU
R
Assignment
CRU
R
Figure 2
C
R
U
Assign Freight
Area
X
Company
X
Truck
X
Customer
X
Freight
X
Assignment
X
X
Display Loads
Area
X
Company
X
Truck
X
Customer
X
Freight
X
Assignment
X
D
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure
10
Detail CRUD Analysis
Operations
Class
Operation
Expand
C
R
U
D
Check
Area
Area(String, ini, int)
1
Main
~Area
1
Company (String)
1
~Company
1
addTruck(Truck)
1
Main
addArea(Area)
1
Main
addCustomer(Customer)
1
findArea(String):Area
1
D1/O4
findCustomer(String):Customer
1
D1/O2
assign(Freight):Assignment
1
D1/O8
display()
1
D1/O9
Truck (int,int, int)
1
~Truck
1
addArea(Area)
1
Main
addCustomer(Customer)
1
D1/O6
getTruckID():int
1
D5/O2
getAssignments():AssignmentVector
1
D4/O1
servesArea(Area):boolean
roomOnTruck(Freight,
Date):boolean
1
D2/O4
addFreight(Assignment)
1
Customer (String, Area)
1
~Customer
1
getName():String
1
getArea(): Area
1
Freight(Customer, Date, int, int)
1
~Freight
1
na
Company
Main
na
D1/O5
Truck
1
Main
na
D2/O5
D2/O7
Customer
D1/O5
na
D5/O7
D2/O2,
D5/O6
Freight
D1/O7
na
getSize():int
1
D3/O3,
D5/O8
getWeight():int
1
D3/O4,
D5/O9
getCustomer():Customer
1
D2/O1,
D5/O5
getDate():Date
1
D2/O3
setAssignment(Assignment)
1
Assignment(Freight, Truck, Date)
~Area
1
1
D2/O8
Assignment
getDate():Date
1
getFreight():Freight
getTruck():Truck
1
1
D2/O6
na
D3/O1,
D5/O3
D3/O2,
D5/O4
D5/O1