Process-Oriented Design

4.5. Design Program Packages

Rules for Designing Program Packages 

The activities for grouping modules into program packages are listed below; as you can see, they are general guidelines, not rules. There are no rules for packaging because it is an environment-dependent activity. Packages for firmware or an 8K micro computer are entirely different than packages for a mainframe. Also, the implementation language determines how and when some types of coupling are done. With these ideas in mind, the guidelines apply common sense to identifying program execute units.

1. Identify modules that perform functionally related activities, are part of iteration units, or which access the same data. The related modules identified should be considered for packaging together for execution. 

2. Develop pseudo-code for the logic functions being performed. Use only structured programming constructs: iteration, selection, and sequence. Document complex logic using decision tables or decision trees. 

3. Logically test the user views developed with the DBA to reevaluate their usefulness for each program package. 

4. Design each module to have one entry and one exit. 

5. Design each module such that its contents are unchanged from one execution to the next. 

6. Design and document messages for called modules. Reevaluate the messages to minimize coupling. 

7. Draw a diagram of the module and all other modules with which it interacts.

TABLE 8-5 ABC Data Requirements by Process

A program package is a collection of called modules, called functions, and in-line code that does some atomic process, and that will become an execute unit. The hierarchy of criteria for designing packages is to package by function, by iteration clusters, or by need to access the same data. At all times, you must keep in mind any production environment constraints that must also be part of the design. For instance, if the application will be on a LAN, you may want to design packages to minimize the possibility of multiple users for a process. Functional grouping is, by far, the most important. 

Functional grouping ensures high cohesion for the program. Any modules that are required to perform some whole function should be grouped together. The other two considerations frequently apply to functional groups as well. 

If a group of activities repeat as part of an iterative sequence, all activities in the group should be together in the program package. Individual modules can be coded and unit tested alone, but they should be packaged for integration testing and implementation. 

Grouping modules that access the same data minimizes physical reading and writing of files. The major goal is to read the same data record in anyone pass of the processes no more than once. We want to minimize physical I/O because it is the slowest process the computer performs. Grouping modules by data accessed minimizes the frequency of reading. Real-time applications, especially, are vulnerable to multiple reads and writes of the same data, slowing down response time.

Grouping modules by data access is a form of data coupling that minimizes the chance of unexpected changes to data. If we do not package modules together, but only read and write data once, the major alternative to common packaging is to use global data areas in memory. Global data is not protected and is vulnerable to corruption. 

When the packages are complete, develop Structured English pseudo-code for the logic functions being performed. Use only structured programming constructs-iteration, selection, sequence. Document complex logic using decision tables or decision trees. Include control structures and names for all modules. Pseudo-code may have been done as part of analysis, or earlier in design, as we did for ABC rental and return. Incidental activities, or less crucial activities, may have been overlooked or not refined. Pseudo-code is completed now and structured for use in program specifications.

Decision tables and trees might be used to document complex decisions. While a discussion of them is beyond this text, an example of each is shown in Figure 8-3l. 

As we design the program packages, we logically test the user views developed with the DBA to reevaluate their usefulness. The questions to ask are: Is all the needed data available? Is security adequate? Is extra data present? If any of these answers indicate a problem, discuss it with the DBA and determine his or her reasons for the design. If the design should change, the DBA is the person to do it. 

Design each module to have one entry and one exit. Multiple entrances and exits to program modules imply problems because of selection and go to logic required to implement multiple exits and entrances. If each module is kept simple with one of each, there are fewer testing, debugging, and maintenance problems.

Ideally, each module should have its internal data contents the same before and after a given execution. That is, the state and contents of the module should be unchanged from one execution to the next. This does not mean that no changes take place during an execution, only that all traces of changes are removed when the execution is complete. When a module must maintain a 'memory' of its last actions, coupling is not minimized. 

Design and document messages for called modules. Messages should contain, at most, calling/ called module names, data needed for execution, control couples, and variable names for results of execution. 

You might draw a diagram of the module and all other modules with which it interacts to facilitate visual understanding of the module and its role in the application.

ABC Video Example Program Package Design 

Working with the final structure chart in Figure 8-30, our biggest decision is whether or not to package all of rental/return processing together, and how. Do we write one program with performed modules, one with called modules, or a combination of the two? 

ABC is going to be in a SQL-compatible database environment, on a LAN, and requires access by PCs. The choice of language is not limited with these requirements, but packaging without knowing the language is not recommended. For this exercise, we will assume that Focus,4 the 4GL, will be used.

Focus' application generator, called the "Dialogue Manager," allows both in-line and called modules to be used. Calling modules of nonFocus languages are allowed but can be tricky. The language has its own DBMS that is SQL-compatible, but it is not fully relational. It falls in the category of DBMSs called 'born again relational,' that is, the DBMS is hierarchic, networked, or relational at the DBA's discretion. Relationality is allowed but not required in Focus. Focus does not support the integrity rules. We will not redesign the database here since the SQL code above could be recoded without design changes in the Focus DBMS language. 

At this point, we need to step back and decide how to package the entire application. What kind of 'glue' will hold customer maintenance, video maintenance, end-of-day, and rental/return processing together. We do not discuss screen design here because it is not in the methodology (it is in Chapter 14), but we would finalize screens while these decisions are being made. We need all of the above functions to do this application, so all of the functions must be available in a unified environment. This means that all functions must be available for execution within the same run environment. Screens are the 'glue' that users see that unify application processing. The code behind the screens mayor may not be unified depending on the design techniques and language. With Focus, unification is done through the Dialogue Manager.

FIGURE 8-31 Decision Table and Decision Tree

4GL and PC-DBMS languages are deceptively simple. To perform trivial tasks is easy, but to build application requires expertise. Focus is no different. The complexities with Focus relate to when, where, and how often the databases are opened and processed, how the databases are related, and how many concurrent users are allowed. The concurrent environment increases DBA complexity but changes the answers to the questions about databases; it does not change the application code. So, we will assume one user at a time for processing. 

Skeleton Focus code for the application is shown in Figure 8-32. Each DFD Level 0 process is accounted for at this level; we even have a query function that is new. Most applications require interactive file query and we have not talked about it at all as part of the rental return application. The trend in business today is for users to develop their own reports and queries using some 4GL. When the language has a built-in query facility, you can add it to the processing without any analysis or design work, as shown here with Focus. User developed queries allow users to 'stay in touch' with their data and remove a major design burden from IS personnel.

Now that the application is accommodated within one execute environment, we return to the problem of how to package rent/return processing. The ideal is to code and unit test each lowest level box on a structure chart as an independent module. Then, using the 'call' feature of the language, build a control structure, based on the design of the control and coordination boxes on the structure chart that calls modules as needed for execution. We will use this approach here as Figure 8-32 shows for the application, and Figure 8-33 shows for rental and return processing. 

The alternative to called modules is in-line code that is 'performed' or executed as a pseudo-called module. This choice is selected with 3GL languages such as Cobol, Fortran, or PL/1 because it can be easier to code, test, and maintain.