The internal, or technical, design of an information system is the description of how the system will be implemented. Most of the work done here is intimately dependent on the architecture adopted, but we can identify a few general principles that apply across the board. This will be the simplest and the most useful if we look at the end result of the design rather than the process to get there,
The internal design identifies and describes all of the components of the system: hardware, software, communications protocols. For each component, it describes which functions are fulfilled by, or allocated to, that component. The decomposition/allocation should meet the following criteria:
- Completeness. Each functional requirement (see section 5 above) is allocated to a component.
- High cohesion: Each component performs functions that belong logically together. For example, extending and totaling the lines of an invoice and the computation of sales tax arguably belong together; checking a user’s password does not.
- Low coupling: Each component interfaces as simply as possible with other modules. For instance, an on-line ordering application might have a module to process credit card payments. The invoicing program should just communicate the invoice amount to the credit card payment module, which, after processing the credit card data entered by the user should simply indicate to the calling module whether the payment was accepted or not.
One particular strategy of allocation is worth bringing out: object orientation. Whereas traditional systems allocate functions to modules based on the processing flow, object orientation uses the data structure as the criterion. Each object (corresponding to an entity in the entity-relationship diagram or a table in a relational database) is packaged with its code The functions that such an object can perform are typically to modify the value of an attribute (say, the customer address) or to send the value of an attribute back to the requesting program. The application still needs to implement a flow of processing (for example, log in, followed by browsing of the catalog, depositing items in a virtual shopping cart, checking out and paying). The object-oriented paradigm can be made systematic by considering each such process as an object in itself, even though it is not an entity in the entity-relationship diagram.
Object orientation has the advantage of making it easy to meet all three of the criteria enumerated above. The structure of the system is simpler and more reliable than traditional systems design. The disadvantages are that performance may be a problem and that the approach is less familiar, especially for IS professionals of a certain age.
- 1282 reads
