Other Design Considerations - Software Design - Software Engineering: A Methodical Approach (2014)

Software Engineering: A Methodical Approach (2014)

PART C. Software Design

Chapter 13. Other Design Considerations

We have looked at all the major aspects of software design. However, there are a few outstanding areas that need some attention. This chapter covers these areas as outlined below:

· System Catalog

· Product Documentation

· User Message Management

· Design for Real-Time Software

· Design for Reuse

· System Security

· Summary and Concluding Remarks

13.1 The System Catalog

The system catalog (also called data dictionary) is a very useful and effective management and analysis tool for the software engineer or system manager. It stores critical control information that will be useful to anyone managing or working on the development/maintenance of the software.

Typically it commences its existence during the design phase, but may be introduced as early as during the preparation of the requirements specification. Once introduced, it serves the project for the rest of its useful life.

13.1.1 Contents of the System Catalog

The system catalog contains database related information as well as operational control information.

Essential database-related contents of the system catalog are the following:

· Name, description, proper coding and aliases of each information entity (or object type) in the system

· Name, description, proper characteristics (e.g. type and length) and coding of data element in each information entity

· Required editing and integrity checks on data elements

· Indication as to whether a data element references another element in another entity (object type) and the type of reference (relationship)

Operational contents include:

· Name and description of sub-systems (and/or modules)

· Name and description of each operation (or function) — including super-operations as well as sub-operations

· For each operation, specification of entities (object types) used and/or impacted

Business rules include:

· Relationships among entities (object types)

· Data integrity rules (if not already specified above)

· Calculation rules for operations

· Other operational rules

Image Note In purely OO environments, the approach is somewhat different: For each object type, a set of allowable operations is specified. The reason for this is that purely OO software tools will allow the software to encapsulate the object’s related operations with its data structure into a class (review chapter 9).

13.1.2 Building the System Catalog

The system catalog may be constructed in any of three of ways:

· Via Static Tables: In the absence of a sophisticated software development environment, the catalog can be built using static table(s) via some word processor e.g. Word Perfect, Microsoft Works, Microsoft Word etc. Maintenance will be particularly challenging, since any change to the model will necessitate manual changes to the tables.

· Via Dynamic Files: Again assuming an environment devoid of sophisticated software development tools, an alternative to static tables would be to create data file(s) that can store the pertinent information, then load and manage the information via some entry/update application program(s). This could be done in any programming language.

· Automatic Creation: A few business-oriented operating systems (e.g. System i) have the facility to allow the software engineer to define and maintain a data dictionary as an important component of software developed in that environment. Additionally, the more sophisticated software development products (CASE tools and DBM suites e.g. Oracle, DB2, Informix, etc.) have built-in features to automatically build and maintain a system catalog, while a software product is being developed. The software engineer can then access this catalog.

Whichever of the first two methods is employed, a top-down approach to defining the system catalog is recommended:

· Specify all sub-systems of the software system

· Specify all entities (object types)

· Specify all elements of entities

· Specify all operations

13.1.3 Using the System Catalog

The system catalog is an excellent means of system documentation:

· You can obtain assorted views of the system e.g. entity-operations lists; operation-entities lists; entity-elements lists; terms and aliases; list of system operations; list of system entities; etc.

· You can also obtain information about relationships. In the case of automatic creation, you might even be able to obtain an ERD/ORD from the catalog.

· You will also be able to obtain assorted views of the systems business rules on a system-wide basis, by operation, or by entity (object type).

The system catalog is very effective in guiding the design phase (particularly with respect to database, operations, menu interface, and business rules). It can also be used as a management tool in design, development and maintenance phases. Figure 13-1 provides a very basic illustrationof the kind of information that a system catalog could provide.

image

Figure 13-1. Illustration of System Catalog

13.2 Product Documentation

Product documentation typically involves three main areas: the system help facility, the users’ guide, and a more technical document often referred to as the system guide. Of course, there are variations according to the product, as well as the organization of responsibility. For instance, the users’ guide and system guide may be merged as one document or set of documents. Also, if the software system is very large and complex, there may be a product overview document.

13.2.1 The System Help Facility

In help design, the software engineer specifies exactly how the help system will be structured and managed for the software in question. Two important considerations here are:

· The structure of the help system

· Content of the help system

Structure of the Help System

There are three alternatives for structuring the help system: it may be panel-by-panel, context sensitive, or hypermedia-based.

· Panel-by- panel Help: Each panel displayed by the software has a corresponding help panel, invoked when the user makes a request for it. The user request is typically affected by pressing a given function key on the keyboard, or clicking at a help button on the screen.

· Context Sensitive Help: Depending on the cursor position at the time of user request, help information, specific to that locality is provided. This approach is difficult to develop and maintain, since there must be close synchronism between cursor location and help information provided. For example, the operating system called System i (formerly OS-400) has a help facility that is completely context sensitive.

· Hypermedia-based Help: The help facility is developed as a hypermedia system, invoked by the user making an explicit request (clicking help menu/button or pressing a function key). The user accesses information based on the choices made from a menu, an index or a hyperlink. This approach has become very popular, because it comes close to offering the same conveniences as the context sensitive help, but with much less complexity of design.

Content of the Help System

The content of the help system must be relevant to the software it is designed for. Quite often, the help system is developed by practicing system documenters, and not the software engineers who design or develop the product. In such circumstances, close coordination is required, if a high quality product is be the outcome.

Unfortunately, the content of the help system has been a problem area for software systems. Very often, the product documentation that is marketed with the software is voluminous, but inadequate. Different vendors try to document, each producing documents with their own inadequacies. The end result is an inundation of documentation that the user has to scan through in order to get a good handle of the product. The situation is particularly worrying when the product is a software development tool which software engineers need is order to be more proficient on the job.

Ideally, the software engineers should be closely involved in the design and development of the help system (but due to market dynamics, this is often impractical). Alternately, system documenters should have sound appreciation of software engineering.

13.2.2 The User’s Guide and System Guide

Traditionally, when a business application is developed for the organization, there used to be a distinction between the user documentation (user’s guide) and the system documentation (system manual). The former was a non-technical document for end users of the system, the latter, a more technical document for the information systems professional. This approach is still relevant for such categories of software. However, as more sophistication is added to the business applications, this distinction is becoming more nebulous.

The user’s guide is a non-technical document, suited for the end-users. It contains step-by-step instructions on how to use the software, preferably on a module-by-module basis. The system manual is a technical document that is ideally suited for system managers and software engineers, whose responsibility it will be to maintain the system. It is a technical summary of the system, outlining:

· The main components

· The operating constraints and configuration issues

· Security issues

· Syntax and explanations of system commands (for command interface)

· Explanations of system commands (for menu or graphical interface)

For other categories of software such as development tools for software engineering, this distinction is not relevant. What is required here is a comprehensive set of documents that the user (in this case the software engineer) can use. Typically, the set begins with a product overview, then depending on the complexity and scope of the product, there is a document or set of documents for different aspects of the software. This may also be supported by comprehensive (set of) system manual(s). In the era of command based user interfaces, system manuals were very voluminous. Nowadays (in the era of GUIs), they are not as bulky.

Another contemporary trend is to provide the system documentation in electronic form rather than via large volumes as used to be the case. This cuts down on the marketing cost of software engineering companies, allowing for easier packaging, shipping and handling.

Ideally, the software engineers should be closely involved in this aspect of software documentation. Failure to do so often results in poor quality in the documentation of the product. There is no scarcity of software products that have been poorly documented.

Rational Software (now a division of IBM), the company responsible for Rational product line and the Unified Modeling Language (UML), provides a positive example of good software documentation. Most of the product documentation was done by the chief software engineers behind the products — Grady Booch, Ivar Jacokson and James Rumbaugh (see [Rumbaugh, 1999]). The product documentation for Oracle (despite being quite voluminous) also provides an excellent example of good product documentation: it is comprehensive, non-intimidating, easy to use, well organized and packed with good illustrations.

13.3 User Message Management

Undoubtedly, it will be necessary for the operations of the software system to provide user messages to guide the user along. There are three kinds of user messages that a software system may provide:

· Error Messages inform the user that an attempted activity is invalid, or an entry is invalid. For example keying in an invalid date, or attempting to access a data item (record) that does not exist, should each elicit a software response that that activity is not permissible at that point in time.

· Status Messages inform the user on the current state of an ensuing activity, for example displaying the number of records read from a database file.

· Warning Messages alert the user that an attempted activity could result in problems.

There should be some standard as to how and where on the screen, user messages will be displayed. Two possibilities are on the last line of the screen, or in a pop-up window.

In message management, the software engineer specifies how messages will be stored, retrieved and displayed to users of the software. In many scenarios, message management is addressed in predetermined software development standards (review chapter 9).

13.3.1 Storage and Management of Messages

Two approaches to storing and managing user messages are possible:

· Each application operation stores and manages its own user messages. This is the easy way out. The main problems are:

· It promotes inconsistencies.

· It makes the software difficult to maintain.

· There is no independence between system errors and system applications.

· Store all user messages in a system-wide message file. Messages are given unique identification codes and can be accessed by any application operation. This is the preferred approach and avoids the problems of the first approach.

Obviously, the second approach is preferred to the first, since it provides more flexibility and control, particularly as the size and complexity of the project increases. It also leads to a more maintainable software product.

13.3.2 Message Retrieval

If the operation-confined approach described above is employed, message retrieval is not an issue. However, if the system-wide approach is employed, then it might be prudent to define and specify an operation to retrieve user messages and return them to calling operations. This retrieval operation would accept an input argument of the message identification code and return it with an additional argument containing the message text.

The calling operation would determine how and where that message is displayed, possibly to established standards (chapter 9).

13.4 Design for Real-Time Systems

Not only are computers used to manage information, but also complex manufacturing processes. In many instances, computers are required to interact with hardware devices. The hardware designed in such circumstances is embedded real-time software. Real-time software must react to events generated by hardware and issue control responses that will determine the behavior of the system.

The stages in the design of real-time systems are mentioned below:

1. Stimulus Identification: Identify the stimuli that the system must respond to and the appropriate response to each stimulus.

2. Timing Constraints: For each stimulus and response, establish a timing constraint.

3. Aggregation: Aggregate stimuli into classes (categories). Define a process for each class of stimuli, with allocation for concurrent processes.

4. Algorithm Design: Design the required algorithm for each stimulus-response combination. By aggregation, derive algorithms for processes.

5. Scheduling: Design a scheduling system that will synchronize processes according to established (time) constraints.

6. Integration: Establish a method of integrating the system into a larger system if necessary, via a real-time executive.

13.4.1 Real-Time System Modeling

In modeling real-time systems, the software engineer indicates precisely, all the state transitions (the causes and effects). Techniques used include (review state transition diagrams of chapter 6):

· Finite state machines (state diagrams)

· State transition diagrams

Since these techniques were introduced earlier (chapter 6) and will be explored in more advanced courses (OOM as well as Compiler Construction), they will not be discussed further.

13.4.2 Real-Time Programming

Real-time programming remains an exciting (and lucrative) arm of software engineering. Real-time programming is typically done using:

· Assembly language, where the programmer has full control

· Intermediate-level languages such as C, C++, and Ada

· OOPLs such as Java and C#

A real-time executive is a software component that manages processes and resource allocation in a real-time system. It determines when processes start and stop, and what resources the processes access. The essential components of a real-time execution are:

· A real-time clock

· An interrupt handler

· A scheduler

· A resource manager

· A dispatcher (responsible for starting and stopping processes)

13.5 Design for Reuse

Like in other engineering disciplines, software must be designed with reuse as a given necessity. Hence:

· Where possible, software must be constructed by using tested and proven components.

· New software must be designed so that they can be reused in constructing other software products.

In order for this to be achieved:

· Software engineers must be adequately trained.

· The industry must strive towards a zero-tolerance level for blatant software errors.

· Standardization must take more preeminence than it has taken in the past.

· Software (and components) documentation must be an integral part of software engineering.

Software reuse may be considered at different levels:

· Application systems and subsystems

· System components such as object types (classes) and operations

· Ubiquitous algorithms e.g. sort algorithms, forecasting algorithms, date validation, etc.

· Methodologies

Advantages to reusable software include:

· Improved software quality

· Reduction of development time and cost

· Enforcement of software engineering standards

· Improved reliability of software

· Reduction of risks for new software engineering projects

13.6 System Security

System security has always been, and will continue to be an integral part of software design. There are three levels of security that should be addressed:

· Access to the system

· Access to the system resources

· Access to system data

13.6.1 Access to the System

Access to the system typically involves a login process. Each legitimate user is provided with an account, without which they cannot access the system. Figure 13-2 provides some details that are stored in the user account.

image

Figure 13-2. Details Stored About a User Account

Among the categories of software that employ a system level user account are the following:

· Management Information System

· Strategic information System

· Decision Support System and Executive Information System

· Data Warehouses

· Business Intelligence Systems

· Operating Systems

· Web Information Systems

· Computer Aided Design

· Computer Aided Manufacturing

· Computer Integrated Manufacturing

· Database Management Systems

· CASE Tools and RAD Tools

For these systems, the user accounts are stored in an underlying database file. When the user attempts to log on, this file is accessed to determine whether this is a legitimate user. If the test is successful, the user is admitted in; otherwise, an error message is returned to the user. Of course, the database file must be appropriately designed to store all required details about the user.

Of course, not all software products require the use of system level user accounts as described above. Some products make use of user accounts already defined and stored in the underlying operating system. Others use no system level security at all. Desktop applications and multimedia enabling software are two categories of software that embody this latter approach.

13.6.2 Access to System Resources

Once a user gains access to the system, the next level of security to be addressed is access to system resources. By system resources, we mean database files, source files, commands, programs, services, etc. Depending on how complex the system is, this could be quite extensive, involving the storage and (often transparent) management of a user-resource matrix (also called an access matrix). When the user attempts to access a resource, the access matrix is checked to determine whether the attempted access is legitimate. If it is, the operation is allowed; otherwise, an error message is returned to the user.

One way to implement the resource access matrix is to incorporate its design into the underlying database for the software system, and include related operations for managing it. This approach will become much clearer to you when you study database systems (and learn more about the system catalog) as well as operating systems. Alternately, the matrix may be implemented as an independent system and integrated in the current software system. While the first approach is easier, the latter approach provides more flexibility, and the ability to reuse the resource access matrix in multiple projects.

13.6.3 Access to System Data

If your system involves access of user data in an underlying database, then it might be desirable to manage access to actual data contained in the database. One very effective and widely used methodology for this is the use of logical views. As mentioned earlier, a logical view stores the definition of the virtual database file (table), but stores no physical data. It is simply a logical (conceptual/external) interpretation of data stored in core database files. Figure 13-3 provides an example of a situation requiring logical views. You will learn more about, and develop a better appreciation of logical views after you have completed a course in database systems.

image

Figure 13-3. Example of a Situation Requiring Logical Views

13.7 Summary and Concluding Remarks

Let us summarize what has been discussed in this chapter:

· The system catalog is a data dictionary of the software system. It contains information such as the name, description, and characteristic details of the main system components including information entities and operations. It may also contain definition of system rules.

· With a sophisticated DBMS suite or CASE tool, the system catalog is automatically created and maintained by the software development tool. In a more primitive software development environment, the catalog can be created and maintained as static word processing documents or dynamic files maintained by utility programs.

· Once created, the system catalog should be carefully maintained as it contains useful information about the software system.

· Software documentation typically includes a help facility, a user’s guide, and a system guide.

· The help facility may be panel-by-panel, context sensitive, or hypermedia-based. Whichever approach is used, the help facility must be carefully planned.

· The system guide is a technical document, for software engineers and/or managers of the system. The user’s guide is a non-technical document for end users. Both should be carefully planned.

· User messages may be error messages, status messages or warning messages. They are designed to assist the user in successfully using the software system.

· User messages may be managed on an operation-by-operation basis, or via a system-wide message file. The latter approach is preferred as it provides more flexibility to the software engineer, and leads to fewer problems during software maintenance.

· Real-time software systems are hardware-intensive systems that operate in real time based on hardware signals and responses, rather than human intervention. A real-time system passes through the stages of stimulus identification, timing constraints, aggregation, algorithm design, scheduling and integration.

· Real-time system modeling involves extensive use of diagramming techniques such as finite state machines, state transition diagrams, and activity diagrams. Real-time system programming involves low-level programming.

· Code re-use is not magic; it must be carefully planned and managed.

· There are three levels of software system security: access to the system, access to system resources, and access to system data. Thoughtful design of the security mechanism is paramount to the success of the software system.

By following the principles and methodologies in this and the previous four chapters, you are now in a position where you can confidently put together a design specification for your software system. Remember, we are assuming reversibility between phases of the SDLC as well as between stages within any given phase of the SDLC. The alternative to this assumption is to assume the waterfall model; however, as was mentioned in chapter 1, this model is particularly problematic, especially for large, complex systems.

Take some time to review the ingredients of the design specification (see chapter 9), and the various issues discussed in this division of the text. Then examine the sample design specification of appendix 10 with fresh eyes. You have been armed with the basic skills needed to design quality software! The next three chapters will discuss software development issues.

13.8 Review Questions

1. What details might be stored in a system catalog? How might it be constructed? How might it be used?

2. Briefly discuss three approaches to structuring the help system of a software product.

3. What information is normally provided in the user’s guide of a software product?

4. Describe how you would manage error and status messages for a large software engineering project.

5. Describe the six stages in the design of real-time systems.

6. Describe the three levels of security that many software products are required to address. For each level, outline an effective approach for dealing with security at that level.

13.9 References and/or Recommended Readings

[Foster, 2010] Foster, Elvis C. with Shripad Godbole. Database Systems: A Pragmatic Approach. Bloomington, IN: Xlibris Publishing, 2010. See chapters 13 and 14.

[Harris, 1995] Harris, David. Systems Analysis and Design: A Project Approach. Fort Worth, TX: Dryden Press, 1995. Chapter 6.

[Kendall, 2005] Kendall, Kenneth E. and Julia E. Kendall. Systems Analysis and Design 6th ed. Upper Saddle River, NJ: Prentice Hall, 2005. See chapters 8 and 15.

[Rumbaugh, 1999] Rumbaugh, James, Ivar Jacobson and Grady Booch. The Unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley, 1999.

[Schneiderman, 2005] Shneiderman, Ben. Designing the User Interface 4th ed. Reading, MA: Addison-Wesley, 2005. See chapter 13.

[Sommerville, 2006] Sommerville, Ian. Software Engineering 8th ed. Boston, MA: Addison-Wesley, 2006. See chapters 15 and 30.