CS3 Programming Methodology Lecture Note D1, 2 November 2000 System Design and Modular Programming System design involves meeting competing requirements and satisfying constraints on the system and the system development process. The system should satisfy the functional requirements and the measurable attributes of the system should be adequate (e.g. efficiency, reliability, maintainability, usability). The development process is constrained by cost, available staff, external regulation, etc. The final system represents a compromise that attempts to satisfy these competing requirements and constraints. The approach to satisfying the requirements depends on the chosen lifecycle. Waterfall takes the specification as a target and attempts to meet it. The spiral model sees successive prototypes as approximations to the ideal specification (the specification may change as a result of prototyping). Evolutionary delivery attempts to partition the specification into many small sub-specifications and attempts to meet each sub-specification with a product delivered to the customer (the specification may change as a result of earlier delivery). This note is an overview of the design process. We consider what a design should contain, the design process, criteria to judge the quality of a design, an overview of design techniques, the design evaluation process and how structured approaches to design can be supported by programming language structures. These components will play a part in the design process in whatever lifecycle model structures the development process. The distribution of the activities will be different but all will take place. System Design In design the problem specified by the requirements specification is solved, either completely (waterfall), or approximately (spiral) or partially (evolutionary). For most real-world systems this solution takes two forms: the conceptual design and the technical design. The technical design is an internal document and forms the specification from which detailed program design is undertaken. The conceptual design is derived from the technical design and is intended for presentation to the individual or group who commissioned the project. Technical Design The technical design should specify: 1. the hardware required, 2. the structure of the software to a level of detail that provides the facilities in the requirements specification, and 3. the specification of the data structures and data flows. Traditionally, the hardware has been specified by providing an architecture that specifies the hardware components and the data flow connections between the components. More recently software architecture has become an area of intense study and the large-scale structure of the software is described by identifying the components of the system and how they interconnect via different style of connector. We return to software architecture in later notes. In Computer Science it is common to make no distinction between items 2 and 3 above. The reason for separating them out in the literature on system design is pragmatic. Many commercial systems have large volumes of stored data and it is important to identify different collections of data and to document the existing format of the data and the format of any new data generated by the system. Many commercial systems follow uncomplicated procedures requiring little in the way of programming but they do require tight control over very large 1
volumes of data which may be of a sensitive nature. In these systems much of the time of the designer is occupied in ensuring that security and recovery procedures are adequate. An important aspect of the design is that it provides a trace back to the specification. The justification for the inclusion of any particular feature of the design must be justified in terms of some aspect of the specification (or in support of some design feature that implements some aspect of the specification, and so on...). Since the specification should be traceable back to requirements, all aspects of the design should ultimately be justified from the requirements. Conceptual Design The conceptual design must be comprehensible by non-designers. The conceptual design is often the document on which contracts are agreed so it is important that it is accurate. Though this is not an exhaustive list the conceptual design should have the following features: (i) it should be derived from the technical design, (ii) it should be comprehensible by the commissioner of the project, (iii) it contains no technical jargon, (iv) it describes the humancomputer interaction of the system (v) it describes the functions provided by the system (vi) it is independent of implementation issues (vii) it makes clear how all components relate to the requirements, which requirements are met and which are not. This information must be presented in sufficient detail that the commissioner of the project can make informed comment on the design and is able to tell whether it meets the requirements adequately. The conceptual design should be traceable back to the specification. Design Process The primary goal of the design process is to ensure that the requirements are met. There are three dominant approaches to design: Decomposition (top-down): This takes the functional component of the requirements as primary and attempts to solve the problem by decomposing it into subproblems and methods for combining solutions to the subproblems to solve the main problem. The non-functional requirements are taken as constraints on the solution proposed at each decomposition step. The structure of the decomposition provides the modules comprising the final system design. Composition (bottom-up): This takes the collections of data in the system as primary and attempts to compose collections of data and the operations defined on them to composite collections of data with more complex operations defined on the composite. Again this results in a modular decomposition but it is constructed bottom-up. This approach is favoured by those who advocate object-oriented design. (Object oriented techniques are dealt with in the companion course, Software Engineering with Objects and Components.) Architectural: Recently, software architecture [7] has become a popular method of bridging the gap between high-level specifications and low level libraries. An architecture is a collection of components, connected in a configuration by some connectors. The idea is to fix the gross structure of the system in some detail. This structure allows detailed design of the components within an agreed structure. Architectures can be complex, and represent a significant portion of the design effort, but they persist from system to system thereby promoting reuse. They are also strong determinants of the ease of demonstrating certain functional characteristics of the system and provide the basis for tradeoff analysis for the measurable attributes between one architecture and another. An architectural style is defined by the kinds of components and connectors we allow. For example, if the connectors allow data flow (e.g. UNIX pipes ) then we have a data flow style, other styles might be message passing or signal processing or polled units. Each will have strengths in different areas of application. 2
There is no standard approach to system design and the approaches to it remain somewhat informal. However, the structured method approach has become popular in commercial environments. These approaches should not be confused with mathematical methods. Structured methods define a particular strategy for tackling classes of commonly occurring problems. Generally these methods permit the designer to describe the system by viewing it from different angles and allow for testing the consistency of these views 1. Most commonly they provide: 1. An entity-relationship view of the system describing the data in the system and how it is related. This provides a high-level view of the system concentrating on data and their relationships. 2. A data flow view in which the system is modelled by the flow of data in the system and the transformations that take place as it is processed. 3. A structured view of the functionality where large-scale functions are expressed as compositions of smaller functional components. There is a wide range of such methods including structured design [2], structured systems analysis [4] and RAPID/USE [8]. A special issue of IEEE Transactions on Software Engineering [5] outlines some different approaches to system design. Design Quality Though the primary aim of the design process is to meet the specification, the quality of a design has a profound influence on modifiability, maintainability, reliability and testability of a system. The idea of the quality of a design has grown up around structured methods and are therefore oriented towards measuring the quality of the decomposition of the system into separate components or modules. Attributes of modules can be useful in assessing the quality of a design. Though this is not an exhaustive list it is helpful in guiding the design towards a decomposition that eases implementation, testing and maintenance: Cohesion: Modules should be as cohesive as possible. Generally module systems are designed to limit the visibility of objects and their representation. A group of objects (i.e. functions, types, data etc.) cohere if they require the visibility of similar objects at a similar level of abstraction. Do not dump functions and types together for no good reason. If the result is not cohesive, think about splitting the module. Of course there are different criteria for cohesion. For example: definitional cohesion (components are interdefined), temporal cohesion (components are active at the same phase in the computation), location cohesion (components are active at the same site in a distributed system), communication cohesion (components pass messages between themselves), and functional cohesion (components all contribute to a particular user function) Coupling: Aim for a system with a low level of dependency or coupling between modules. Modules that depend on many other modules are undesirable because modification in any one of these may require it to be changed. Modules that are required by many modules should also be avoided because change in such modules may require a large number of modules to change. The criteria for coupling are diverse: definitional coupling (the definition of one module uses another), shared reference (modules share assignable store or files), shared data types, shared structures. Comprehensibility: This is particularly important in the maintenance phase of the system lifecycle. Generally the maintainer will be different from the author of a module and thus the comprehensibility of a module is important if it is to be redesigned. The following are important in assessing comprehensibility: 1 You will see one structured method approach when you study UML in Software Engineering with Objects and Components. 3
Naming: Are the names meaningful? Do they reflect the meaning of the real-world action/entity they model? Documentation: is the module adequately documented? Complexity: are the algorithms used easily comprehensible? Modifiability: Most important here is relatively loose coupling so design changes propagate only locally. Cohesion is also important here because the more self-contained a module is the fewer changes will be required in a redesign. Finally, low complexity is important if the module is to be capable of safe redesign. The time and effort taken to generate a design may be considerable, but it is still substantially less than that required to implement a system. The system design phase is the time to evaluate a diverse collection of solutions to the problems presented by a system. Usually it is assumed that all systems being evaluated meet the basic requirements of the system but they may differ widely when attributes like cohesion, coupling, comprehensibility, modifiability, testability and efficiency are taken into account. Often these considerations are crucial in making the choice between potential system designs. Design Techniques The literature abounds with techniques and tools to document and control the design process. As well as those cited earlier in the discussion on structured methods we have, for example, [3, 6]. SSADM is a particular approach to the design of systems [1]. This is mandated by the UK government for certain classes of data-processing applications. SSADM is typical of these techniques in having a strong bias towards one particular class of system. Generally speaking, techniques of system design involve modelling the data and control in a system and then automating and augmenting the functions carried out by the agents in the system. The representation of the system components is usually diagrammatic. The following kinds of information are seen as being useful: Data Structure Diagrams: These give a broad brush view of the data stored by the system. They generally describe each collection of data in the system (and are backed up by forms describing the structure and format of each collection). In addition the relationships between the data collections are documented. These relationships are important to the consistency of the data. For example, in an inventory control system one may have product data that records, for every product, the reference number of all the components in the product and component data recording the supplier of every component. An important relation between product and component is that every component in the product database appears in the component data base. Data Flow Diagrams: These document the flow of data in the system. They document input and output databases for system functions and may specify intermediate databases to be created by the system. Often the system functions are simple and the data flow diagram can specify them. Structure Charts: If system functions are complex some form of structure chart may be used to decompose system functions into sub-functions and specify: choice, iteration etc. A typical example of this kind of diagram may be found in [6]. Figure 1 illustrates each of the different kinds of diagram. In the data structure diagram the arcs represent relationships between the different collections of data in the system. In the data flow diagram the flows of different kinds of data are represented together with the transactions carried out on them. In the structure chart the make transaction diagram is decomposed into sub-operations. At the top level there is choice between three different types of transactions (represented by the o for option in the second level boxes) and at the second level the keycard 4
transaction is further decomposed. The structure chart notation is further augmented with notations for iteration to indicate that a particular operation may be repeated some number of times. If some non-functional requirement is particularly important it may be necessary to employ prototypes to decide if that requirement can be met. Typical non-functional requirements are the usability of the human interface or performance requirements for the responsiveness of the system. Design Reviews Design reviews play an important rôle in deciding whether a system design meets all the requirements. Usually there are two meetings: the preliminary review in which some semicompleted designs are presented and the critical review in which the final design is reviewed. The structure of the preliminary design review meeting is: Membership: Commissioners of the project, potential users, requirements analyst, system designers, a moderator, a secretary, other designers and analysts not involved in the project. Input Documents: Requirements, initial system design(s). Schematic Agenda: The following points should be covered: Hardware required by the design. Functionality of the design. Performance of the design. Human interface. Interfaces to other systems Output Documents: Report of the review, requests for revisions of the requirements, areas requiring further design. The rôle of the secretary is purely to maintain a fair record of the meeting. The moderator should be ensuring that the main orientation is that the requirements are met and if necessary clarified and that quality of design is paramount. The rôles of the other members of the meeting should be obvious. The critical design review is similar to this but program designers are present and an expected outcome is an agreed system design. Documentation An important input to the design reviews and the final outcome of the design process is the conceptual design. The design process is primarily driven by the needs of the technical design but the documentation should be prepared to contribute to the conceptual design. The following should be described in non-technical diagrams and words: Hardware structure. The human interface: menus, formats, interaction methods, reports, error reporting and recovery. Inputs required from the system: source and format information. Outputs generated by the system: destination and format information. Functionality: modular structure of the system. Performance estimates. Security, recovery, error detection. 5
Customer Transaction customer transactions MAKE TRANSACTION statements debit/credit 6 Figure 1: Some kinds of diagram used in design Account DATA STRUCTURE DIAGRAM MAKE TRANSACTION o o TELLER KEYCARD DIRECT DEBIT o ACCOUNT DATA FLOW DIAGRAM accept card do request return card STRUCTURE CHART
Modular Programming The argument for the provision of modular programming facilities is that the modular level should take care of large scale issues while normal programming languages provide small scale facilities. Small scale programming involves the algorithmic solution of particular problems, issues of data structure choice and the efficiency of particular methods. By contrast large-scale programming involves the overall structure of the system, how its parts relate, the visibility of names and so on. Structure Hiding The ability to hide structure is crucial to the construction of large scale systems. Ensuring that certain details of the system are denied to other designers and users is a means to control the complexity of systems. The commonest use of structure hiding is in the provision of abstract data types where we deny access to the implementing structures to all functions other than those implementing the data type. The notion is more generally useful since we often want to hide subsidiary functions and often in systems with state it is useful to partition the store between different modules thereby ensuring that certain parts of the store can only be affected by a specified group of functions. This method of controlling store access is an attractive part of the object-oriented approach. Dependency Structure Providing the means to explicitly specify the functions, types etc. required by a module provides a means of tracking the potential effects of change in a particular module through the rest of the system. By running along the chain of dependencies one should be able to find all the potentially affected modules. In practice the efficacy of this approach can be undermined by failures in the type system coupled to the use of store in modules, but it remains a useful tool in controlling the effects of change. Examining the dependency structure of a system can also help the designer restructure systems displaying undesirable features. Typical problems are: One module A may depend on many other modules. This indicates either that A is too large and should be subdivided, or that intermediate modules are necessary between A and the modules it depends on to build intermediate structures from which A can be constructed. A module A may contribute directly to many other modules. Again this suggests that A may be too large and can be split into two simpler modules, or that the facilities provided by A are too primitive for the modules using it. In the latter case it may be necessary to construct new modules derived from A to provide higher-level facilities to be used by the modules that formerly used A directly. System Building In subdividing the work of building systems, often all we need to know about other modules is the interface they present to the outside world, i.e. the visible functions and types provided by the module. By separating the interface from the implementation, module systems allow the independent construction of modules by different designers. The provision of dependency information and the specification of module interfaces provides opportunities for tools that reduce the amount of effort required to compile and rebuild systems when they are modified. Because the dependency information and interface are explicitly provided, it is possible to separately compile modules and it is also possible to determine which modules require re-compilation or linking when a module is modified. 7
Software Reuse The interface that is associated with an implementation documents the facilities provided by that code. The existence of the interface encourages the disciplined re-use of existing code rather than an ad hoc approach involving either the development of new code or the piecemeal modification of existing code. Different interfaces can be associated with the same code when it is used for different purposes, taking advantage of the separation of interface from implementation. Modular Programming Facilities All the above considerations have shaped the formulation of a variety of approaches to the modularisation of code. These vary from the informal but disciplined use of files to provide modular structure commonly practised by C programmers to languages incorporating module facilities e.g. Modula-2 [9] or ML. There is a substantial level of agreement that a reasonable module system should incorporate at least the following facilities: Hiding: Some means should be given to hide structures: functions, procedures, types, stores etc. Dependency: The facility to express what objects are required by a particular module and what other modules should provide them. Interfaces: The existence of interfaces as independent entities expressing the facilities provided by a module but not the method by which they are provided. Implementations: The possibility to link code to interfaces and check that the implementation provides the facilities promised by the interface. References [1] C. Ashworth and M. Goodland. SSADM A practical approach. McGraw-Hill 1991. [2] L.L. Constantine and E. Yourdon. Structured Design. Prentice-Hall, 1979. [3] T. DeMarco. Structured Analysis and System Specification. Yourdon Press, 1978. [4] C. Gane and T. Sarson. Structured System Analysis. Prentice-Hall, 1979. [5] IEEE Transactions on Software Engineering 12(2), March 1986. [6] M. Jackson. System Development. Prentice-Hall, 1983. [7] SEI page on software architecture, http://www.sei.cmu.edu/technology/ architecture/. [8] A.I. Wasserman. User software engineering and the design of interactive information systems. Proc. 5th Intl. Conf. on Software Engineering. IEEE Press, 1981. [9] N. Wirth, Programming in Modula-2, 4th edition. Prentice-Hall, 1989. 8