Software Engineering, Page 030

IV. System design

A. Overview

As we leave the analysis activity, let us assume that we have done a reasonably thorough job at identifying the system requirements and creating an analysis model. During system design we will strive to:

Construct a list of design goals that will address the constraints placed on the system by the non-functional requirements. These goals should help us see practical actions that can be taken to meet these constraints.
Develop an architecture for our system. This should reveal the essential software components that need to be developed, their interactions with each other, and their deployments on various machines.

There are certain "big picture" issues that need to be addressed as early as possible. The decisions here need to be compatable and can profoundly affect the system as a whole:

Hardware/software mapping.
- What hardware is available or could become available?
- What sort of communication exists or is possible between the nodes? Physical connections? Logical connections? Speeds? Ease-of-use? Level of support?
- What functionality is already provided by existing nodes? Could (should) this be altered?
- Given a possible architecture, where should the various components be placed to maximize good things like speed, throughput, maintainability?
- Do we need an additional subsystem(s) for (better) node-to-node communication and data (object) management? If so, where do we get this? Vendor or in-house? Etcetera.
Data management.
- Which data needs to be persistent?
- What form should it be stored in?
- What sort of system do we want to use to maintain it? Flat files? Database? If database, relational or O-O, and whose?
- What sort of access speeds can we expect (under different traffic conditions)?
- How much should we worry about data integrity? Are we willing to trade off access speed for more integrity?
Access control.
- Who gets to use what?
- How should this be controlled?
- How critical is security? Is it worth a major effort?
- Purchase existing software for this?
Control flow.
- What is the order of events in using the system?
- Multi-user access? If so, to what limit?
- Is the system (or part of it) event-driven? If so, how will events be promptly handled? Do we need reentrant event handlers? How bad could this get? Will regular processing be seriously impeded by this?
- Is the system multi-threaded (multi-programming)? If so, what are the threads? How do they interact? Can they seriously delay one another? Is deadlock a possibility? If so, how can it be resolved?
Boundary conditions.
- How does the system start up?
- How does the system shut down?
- If system is distributed is there adequate coordination here?
- What about exception handling? (Related to control flow but focused here on the coordination of the various nodes.)

There is likely to be significant thinking and rethinking about the architecture and its deployment in an effort to find adequate answers to all of the above issues (and undoubtedly many other such issues). As with analysis, system design requires a good deal of flexibility and reevaluation.