Chapters 7: System Design

Chapters 7: System Design.

In Chapter 6, the design goals and decomposition were dealt with. In this Chapter (7), the system design activities that addresses the design goals are to be dealt with. In particular, it is to be decided if : 1. Off-the-shelf and legacy components can be used to help in the development of the software. 2. Mapping of the subsystem to hardware. 3. Design of a persistent data management infrastructure. 4. Specification of access control policy 5. Design of global control flow 6. Handling of b oundary conditions.

An overview of System Design Activities:

Decomposition of the system is the bulk of the system design. It requires the division of the system into manageable pieces. Issues to be considered when decomposing a system are:

1. Hardware/software mapping: Hardware configuration? Intranet or internet or stand-a-lone? If multiple computers are involved, then the allocation of subsystems to computers needs to be carefully managed. Example, if servers are involved, etc. Furthermore, if multiple computers are used, then a virtual machine should be selected on which the system should be built. The virtual machine would include the operating system and any other software (e.g. DBMS or communication packages) that the system will need. However, constraints may evolve here. The client may already have their hardware system set up, hence, it may not be possible to set up a virtual machine. Also, setting up a virtual machine may involve added expense for the client, which they may not care for.

Also, additional subsystems may be defined especially those concerned with moving data around. Note, off-the-shelf components (GUI packages and DBMS) may be used to reduce cost.

2. Data management: Should there need to be persistent data and if so where should it be stored? Data access should be fast and accurate. If not, the whole system will be slow or cause a bottleneck situation to occur and if the data can be corrupted easily, then the system will fail.

3. Access control: Who can access the system? Etc. That is what kind of security measures will be implemented. If any are implemented, it must be consistent across subsystems.

4. Control flow: Can the system handle more than one user at a time? Event driven system where each subsystem provide event handlers integrating the subsystems; or thread driven where mutual exclusion must be guaranteed for critical sections.

1 5. Boundary Conditions: How is the system initialized? How is it shut down? How will it handle errors and exceptions? Etc.

As shown in Figure 7.1 pp 262, the activities attributed to system design is iterative in nature and may very well lead the revision of the subsystem decomposition. That is, new subsystems may be required or existing subsystems be redefined.

Selecting a hardware configuration and a platform:

Decide if the system will run on more than one computer – what kind of connection – intranet or internet. The need for a virtual machine is examined – Decide on operating system and any other software components (e.g. DBMS). In the MyTrip example used by the authors, they deduced that the PlanningSubsystem and the RoutingSubsyetem run on two different nodes – the former is a Web-based service on an Internet host and the latter runs on an onboard computer. According to this configuration, Figure 7-4 pp 265 shows the computers allocated - for webserver virtual machine - UNIX and for the Onboardcomputer virtual machine – Safari and IE.

There may be cases when nodes share common objects. When this happens, it is better to create another node and then connect these two nodes via the third node. In either of the original nodes, proxy objects may be created to act on behalf of the actual object that was supposed to be there. This is explained in Figure 7.5 pp 266.

We may also use Adapter pattern to deal with complexities. As complexities increase, we may be able to use off-the-shelf component to reduce the amount of coding we would have to do. To integrate this, we may have to use the Adapter class. Often we may buy components that may not be written in the same language or the same language. If the code is written in the same language, we would need to build an adapter class which we would use to integrate (encapsulate) the package. In JAVA, we include an “interface area” where we would define the classes that were to be included in the program. We then use the “implements” section to define the class.

The interface is a special type of abstract class that can only include the prototype of the methods that will be defined in the implements section.

Implements is very much like extends except for the following differences: 1. Extends applies to a class whereas implements applies to an interface. 2. A class which extends another class inherits all the data fields and methods of the class which is extended (except for a few exceptions). Note however that methods from the base class can be overridden in the derived class. 3. A class which implements an interface provides must provide definitions for all the methods declared in the interface. 4. A class may extend at most one class, but it may implement any number of interfaces.

When encapsulating codes that are written in a different language, we may use such tools as CORBA which defines protocols for allowing interoperability of distributed objects written in

2 different languages. However, the use of such tools and encapsulation of codes written in different languages must be considered very carefully. Technology may change which can affect this sort of implementation. Maintenance may become more expensive, etc.

Persistent Data Store:

1. Flat Files: Storage abstractions provided by operating system. Data stored as a sequence of bytes. This is relatively low level and could enhance speed. However, data can be corrupted or/and lost easily. Should be used for very small applications that may not grow in size.

2. Relational Database: Data stored in tables – each column is an attribute and each row represents a data item as a tuple of attribute values.

3. OO database: Provide similar services to relational databases, but stores data as objects and associations. It also provides inheritance and abstract data types. However, it is slower than relational database.

The table of page 269 Fig 7.7 gives the trade off of using flat files and databases.

Defining Access Control:

If the system is for a single user, then access control could be a non-issue. But when a system is developed for a multi-user scenario, then access control becomes a concern. We must decide who will gain access to the entire system, and who will gain access to different parts of the system. For example, the system administrator may have access to the entire system including the file that consist of the password to allow log-in to the system. On the other hand, other employees that would be using the system will not have access to the entire system.

When designing the system, a matrix (The Access matrix) is created to make this clear). Example on page 271 Table 7-2, gives an access matrix for a banking system and Figure7 -8 along with table 7-3 giving an example of the protection offered by firewalls during communications between hosts on intranet and hosts on the Internet with respect to packet size.

Methods of ensuring password protection: Use password in conjunction with a smart card or use biometric (a sensor analyze patterns of the user blood vessels in the person’s eyes and fingers, then give access. For security of data transmitted, use encryption to prevent intruders from accessing the data – where the message or data is encrypted (ciphertext) before translated. Only the user receiving the data would know how to convert the data back into plain text before using it.

Control Flow:

This is the sequencing of actions in a system. During analysis, this was not considered in detail as it was assumed that all objects will run simultaneously. However, this is not actually true so upon system design, the execution of each object need to be known. There are three possible control mechanisms:

3 1. Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. The example on page 276– the program prints a message and waits for user input.

2. Event-driven control: A main loop, also waits for an external event. Example code of page 276. A main loop used. Useful for testing subsystems. Also the most commonly used.

3. Threads: The system creates an arbitrary number of threads and run them concurrently. Each thread is run on the basis of procedure-driven. Example page 277.

Identify Services:

Having identified the main subsystems and allocating their main responsibilities, as suggested in the previous sections, it is now time to refine them with respect to the services they provide. This is done by reviewing the dependency between subsystems and defining an interface for each services identified.

Boundary Conditions:

Decide how the system is started, initialized and shut down and also includes how to deal with major failures such as data corruption, etc. These would include a new area – administration uses cases. These use cases should reflect the starting up of the system, shutting down of the system and error checking/correction. Note that when we get an exception, such exception could be caused by any of the following three conditions: 1. A user error: user enters out of range data, etc. 2. A hardware failure: Hardware could age and fail – a failure of a network link, etc. 3. A software bug: the system may consist of a design error which may not have been noticed.

Review:

We need to make sure that the system design model is correct, complete, consistent, realistic and readable. To do this we ask ourselves a number of questions as given on Pages 282 - 284. These questions that are asked pertain to: 1. Correctness. 2. Completeness. 3. Consistency. 4. Realism. 5. Readability.