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.
4