Object-Oriented Design
4. Object-Oriented Design Activities
4.1. Allocate Objects to Four Sub domains
Heuristics for Allocating Objects to Human, Hardware, Software, and Data Subdomains
The first step is to allocate the problem domain processes to one of the subdomains: hardware, software, data, and human interface. Each process and the data it requires from its object3 are examined to determine whether they are best implemented as part of the human interface, hardware, software, or data subdomains. There is no particular order to the allocation process. It is recommended to allocate the software domain last, because it is the default for all processes not allocated elsewhere. Since these implementation alternatives are usually not broken apart by other methodologies, and since hardware is usually completely ignored, the consideration of these subdomains and explicit allocation of objects to them provides useful detail that is explicitly documented for maintenance. Also, since hardware options are becoming more numerous and common (e.g., automated teller machines have local intelligence and some of the application code for deposit and withdrawal processing), this mechanism accommodates hardware and firmware in design decisions.
We will discuss data first, because current guidelines demonstrate some of the shortcomings of current OOD writing. Booch suggests that standard database activities should be assumed to be under the control of the data domain, including create, retrieve, update, and delete processes (i.e., CRUD). All other data manipulations or computations are allocated 'somewhere else.' Coad & Yourdon, and most authors published after 1992, assume the use of a DBMS and usually an object-oriented one that includes the properties of persistence, inheritance, and abstract object-oriented data definition. Some authors assume use of an SQL-compatible database with an equally unobject-like language, recommending that the data functions should be separated from the application which will maintain its object-like properties for all non-data operations.
Keep in mind that this is an inexact process that is highly dependent on the implementation language and the implementation environment. For example, if we were using Smalltalk, in which everything is an object, separation of data access and manipulation
is usually more efficient than keeping the functions all together. Conversely, if an OODBMS, such as Gemstone, were used, the DBMS object performs the physical CRUD actions and the application objects usually control the logical CRUD functions that
are grouped by object. The key idea is that judgment on allocation of functions is required and needs to be done with knowledge of the entire implementation environment.
If the application needs to use a nonOODBMS, then evaluating whether data integrity, security, and access controls can be adequately maintained by not using the DBMS language is required. If the application can both perform the functions faster, and provide for integrity and so forth, then there should be a real analysis of where the functions should be. The application requirements for execution and response time may force use of a programming language when constraints are tight, and default to use of the DBMS language when there are no constraints. Table 12-2 summarizes this discussion, showing that allocation of physical and logical read, write, and delete actions and the control over security, integrity, and access be tied to constraints and t~e type of database environment used. If no DBMS IS used, the alternatives are either to allocate DBMS functions to each object, or to design data control objects that perform DBMS functions, or to design a polymorphic reusable object that performs all DBMS functions.
We said before that DBMSs illustrate the problem of all authors in object-oriented design. For the most part, 00 authors do not work in commercial business and do not build commercial applications; they work in defense-related businesses and build
real-time, embedded applications which function as part of some larger system. For instance, defense applications might include building a guidance system for a missile, a monitoring system for airplane radar, or a reporting system on the Hubble microscope.
These applications all have no persistent data; rather, they work on sensor data and pass on the information they filter for processing or feedback by other systems.
Type Database Functional or response time constraints |
OO Y |
OO N |
Non-OO Y |
Non-OO N |
None _ |
---|---|---|---|---|---|
Allocate CRUD to DBMS | Phys. | All | *Phys. | *Phys. *Log. |
_ |
Allocate CRUD to Object or generic | Log. | _ | *Phys. Log. |
Log. | All |
Allocate security, integrity checking, access control to DBMS | _ | All | _ | *All | _ |
Allocate security, integrity checking, access control to Object or create generic objects | *All | _ | All | *All | All |
The problem with applying embedded-system thinking to persistent object problems is that there is little overlap in designing for temporary and persistent data. Persistent data and, in particular, DBMS-stored persistent data, have entirely different thinking
processes that the computer-scientist authors of most object -oriented methods do not recognize. Because of this lacking recognition, these heuristics on object allocation are more crude than those of, say, process methods which have been tried for
the last 20 years.
A similar problem occurs in the hardware domain. Object-oriented authors most often are designing state-of-the-art hardware as part of their application design including customized operating systems and software. Most business applications use off-the-shelf
hardware that is generalized in function and has many user features. The only custom development in most business applications is the application software itself. So, the design problem with hardware is opposite that of DBMSs. For hardware, the methodology
authors do more detailed levels of development than is necessary in most business applications. You will see this problem again when we discuss service object definition.
Now let's consider allocation of functions to the other subdomains. The human interface is exactly what you think it is, the interactions with people, usually through a terminal device, that provides the essential inputs and outputs of the application. The human interface is discussed poorly in the OOD books that do exist (including all of those in the references of this chapter) because of the traditional lack of human users in object-oriented applications. Because of this lack, they are discussed in Chapter 14 as one of the 'forgotten activities' of systems analysis and design.
In general, the activities that provide human interface control, such as screen interactions, are recommended to be relegated to the human component of the application. Again, there are no compelling reasons for blindly making this decision, therefore it is subject to analysis. Activities that can be grouped across objects, such as line control, error message display, and screen reads and writes can all be abstracted out of the individual objects and placed in reusable, generic objects. The actual editing of data from screens should remain with the original object unless there are sufficient similarities across screens and data items to warrant abstracting them out as well, or unless the functions will be assigned to human interface hardware. To perform this abstraction requires listing all the detailed, primitive actions required of screen interactions for each object, identifying which actions are performed automatically by the DBMS or other application software and removing them from the list, and reevaluating the remaining items to determine whether or not there are commonalities across objects.
This primitive level of detail may be deferred
automatically when you relegate all screen interactions to the human interface. This deferral allows
you to build the interface during proto typing even
though you may not know all of the primitives during the first iterations. In other words, allocating
screen interactions to the human interface is a means
of deferring detailed design decisions until initial
prototype development.
The more distributed devices and processors, the more likely that processing might be allocated to firmware embedded in otherwise unintelligent devices. For instance, automatic teller machines include some intelligence for editing magnetic strip information from the cards used for withdrawal and deposit of funds from banks. They can, for instance, tell what type of card, such as Visa, is being used, and whether or not the personal ID number (PIN) is a valid combination of digits. They cannot tell whether or not the PIN matches the card number entered because that requires access to a database that is not stored locally. In addition, specific hardware functions, such as accepting a deposit envelope, are functions that would be allocated to hardware.
Allocation of processes to hardware/firmware is
determined by the need for fast response time, minimum communication delay, and minimum processing time. Whenever any of these three constraints are
present in an application's functional specification,
hardware process allocation should be investigated.
Some authors recommend that allocation to hardware can include functions to be performed by the
resident operating system. When there is access to
these functions and they can be used as generics, this
is a useful, time-saving idea. So, for instance, in
systems such as Unix and Smalltalk, where the
environment, operating system, and application are
essentially inseparable, thinking of operating systems and hardware as one simplifies design thinking.
Finally, we have allocation of processes to software. This allocation assumes that all problem-domain processes not already allocated elsewhere will
be implemented in software in the software domain.
This allocation includes remaining service and problem domain objects after the other allocations are
complete. Now, let us tum to ABC Video to see what
allocation means in this application.
ABC Video Example of Subdomain Allocation
ABC's rental application will be an interactive, multithread set of processes which will service up to six threads of control, with growth to some higher number. Therefore, the concurrent processing requirements of the application should be considered when allocating processes to subdomains to ensure that timing requirements will be met.
To refresh your memory, we had decided to use
an SQL-compatible database to implement the
application. We can interface the SQL language
with other languages, but, as is typical of most
DBMS software, all data accesses must go through
the DBMS. This implies that the create, retrieval,
update, and delete (CRUD) functions will all be
allocated to the data subdomain as discussed above.
By doing this allocation, we explicitly are deciding what is and is not object-oriented. SQL is not object-oriented. Therefore, any functions performed in SQL are not object-oriented. The design can proceed in an object manner until the primitive level is reached, then the design is completed in SQL.
If we look at the output from the analysis where
we allocated objects to processes, we can identify all
those processes relating to these functions. Each
object has simple CRUD functions as well as a need
for CRUD functions on a user-view of the database
that incorporates Customer, Inventory, and VideoOnRental. Eventually, for SQL implementation, we will
collapse the superset objects back with the class/
objects and will control the use of add and read functions by logic in the SQL DBMS application code.
Any access control on superset objects is controlled
by the DBMS.
Figure 11-20 processes are listed in Table 12-3 with their subdomain allocations. First, consider the data subdomain. From Table 12-2 we know that we can allocate the data functions based on application requirements. We are using a non-object DBMS and have no constraints on processing. Part of the attraction of the fourth generation database is its ease of use, therefore, anything that can be allocated to the DBMS should be. As Table 12-3 shows, all CRUD functions are allocated to the data function. Similarly, printing, which interfaces with external devices, is allocated to hardware. Print control is allocated to hardware because in a LAN, spooling and printing are network operating system functions that are not under application control.
All data entry functions are allocated to the human interface for design and control. Remaining processes are allocated to the software subdomain.