CS302: Software Engineering

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.

TABLE 12-2 Heuristics for Data Allocation Processes 

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.