Professional Documents
Culture Documents
CRUD With Figures
CRUD With Figures
Oriented Design
Journal of Computing Sciences in Colleges, Volume 18, Number 2
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.
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 companys 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 operations 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
Company
Truck
RU
Customer
CU
Freight
CRU
Assignment
CRU
Figure 2
Assign Freight
Area
Company
Truck
Customer
Freight
Assignment
Display Loads
Area
Company
Truck
Customer
Freight
Assignment
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure
10
Operation
Expand
Check
Area
Area(String, ini, int)
~Area
Main
Company (String)
~Company
addTruck(Truck)
Main
addArea(Area)
Main
addCustomer(Customer)
findArea(String):Area
D1/O4
findCustomer(String):Customer
D1/O2
assign(Freight):Assignment
D1/O8
display()
D1/O9
~Truck
addArea(Area)
addCustomer(Customer)
getTruckID():int
D5/O2
getAssignments():AssignmentVector
D4/O1
servesArea(Area):boolean
roomOnTruck(Freight,
Date):boolean
D2/O4
addFreight(Assignment)
~Customer
getName():String
getArea(): Area
~Freight
na
Company
Main
na
D1/O5
Truck
Main
na
Main
D1/O6
D2/O5
D2/O7
Customer
D1/O5
na
D5/O7
D2/O2,
D5/O6
Freight
getSize():int
getWeight():int
1
1
D1/O7
na
D3/O3,
D5/O8
D3/O4,
getCustomer():Customer
D5/O9
D2/O1,
D5/O5
getDate():Date
D2/O3
setAssignment(Assignment)
1
1
D2/O8
Assignment
getDate():Date
getFreight():Freight
getTruck():Truck
1
1
D2/O6
na
D3/O1,
D5/O3
D3/O2,
D5/O4
D5/O1