Designing the System

1. Designing the System

2. What is design?(1) • Design is the creative process of transforming the problem into a solution What and How • Conceptual design tells the customer what the system will do. • Technical design allows system builders to understand the actual hardware and software needed to solve the customer’s problem.

3. “The user will be able to route messages to any other user on any other network computer.” Network topology Protocol used Prescribed bps rate . . . CONCEPTUAL DESIGN TECHNICAL DESIGN

4. What is design?(2) • Good conceptual design • It is written in the customer’s language. • It contains no technical jargon. • It describes the functions of the system. • It is independent of implementation. • It is linked to the requirements documents. • Technical design • A description of the major hardware components and their functions. • The hierarchy and function of the software components. • The data structure and the data flow.

5. Design description • Basis for detailed implementation. • Notation used in design documents • Graphical notation • Program description languages • Informal text

6. Design strategies • Functional design : Starting with a high-level view and progressively refining this into a more detailed design. • Object-oriented design : A collection of objects rather than functions

7. Design quality(1) • Maintainable design can be adapted to modify existing functions and add new functionality. • Cohesion • Measure of the closeness of the relationships between the components. • Cohesion is a desirable characteristic because it means that a unit represents a single part of the solution.

8. Design quality(2) • Coincidental cohesion • Logical cohesion • Temporal cohesion • Procedural cohesion • Communicational cohesion • Sequential cohesion • Functional cohesion • Object cohesion

9. COINCIDENTAL Parts unrelated LOGICAL Similar functions TEMPORAL Related by time PROCEDURAL Related by order of functions DATA COMMUNICATIONAL Access same data SEQUENTIAL Output of one part is input to next FUNCTIONAL Sequential with complete, related functions TIME T0 FUNCTION A FUNCTION A FUNCTION A TIME T0 + X FUNCTION B FUNCTION C FUNCTION B logic FUNCTION A’ FUNCTION E FUNCTION D TIME T0 + 2X FUNCTION C FUNCTION A” FUNCTION A FUNCTION A FUNCTION A - part 1 FUNCTION B FUNCTION B FUNCTION A - part 2 FUNCTION C FUNCTION A - part 3 FUNCTION C

10. Design quality(3) • Coupling • An indication of the strength of interconnections between the components in a desin. • Loosely/Tightly coupled system • Object -> Loosely coupled system • Content coupling : When one component modifies an internal data item in another component or when one component branches into the middle of another component. • Common coupling • Control coupling : When one component passes parameters to control the activity of another component. • Data coupling : When data are passed

11. Uncoupled - no dependencies Loosely coupled - some dependencies Highly coupled - many dependencies

12. A B C Component B D E Go to D1 Component D Go to D1 D1:

13. Global: A1 A2 A3 Variables: V1 V2 Common data area and variable names Component X Component Y Component Z Increment V1 Change V1 to zero V1 = V2 + A1

14. Design quality(4) • Understandability • Naming • Documentation • Complexity • Inheritance • Adaptability • A general estimate of how easy it is to change the design. • Design should be well documented. • Should have a high level of traceabillity. • For optimum adaptability, a component should be self-contained.

15. Architectural design(1) • The initial design process of identifying the sub-systems and establishing a framework for sub-system control and communication. • The process model has the following activities • System structuring • Control modeling • Modular decomposition • A sub-system is a system in its own right whose operation does not depend on the services provided by other sub-systems. • A module is a system component that provides one or more services to other modules. • Architectural design may be based on a particular model or style.

16. System structuring • The first phase of the architectural design activity is usually concerned with decomposing a system into a set of interacting sub-systems. • Block diagram • Repository model • Client-server model • Abstract machine model

17. The repository model(1) • Two ways of exchanging information • All shared data is held in a central DB that can be accessed by all sub-systems. • Each sub-system maintains its own DB. • Central DB and collection of components that operate on it to store, retrieve, and update information. • Characteristics • It is an efficient way to share large amounts of data. • However, sub-systems must agree on the repository data model. • Sub-systems which produce data need not be concerned with how that data is used by other sub-systems.

18. The repository model(2) • However, evolution may be difficult as a large volume of information is generated according to an agreed data model. • Activities such as backup, security, access control and recovery from error are centralized. • However, different sub-systems may have different requirements for security, recovery and backup policies. • The model of sharing is visible through the repository schema. • However, it may be difficult to distribute the repository over a number of machines.

19. The client-server model(1) • Distributed system model • Major components • A set of stand-alone servers which offer services to other sub-systems. • A set of clients that call on the services offered by servers. • A network which allows the clients to access these services. • Characteristics • Distribution is straightforward. Effective use can be made of networked systems with many distributed processors. • However, changes to existing clients and servers may be required to gain the full benefits of integrating a new server.

20. The abstract machine model(1) • A system organized into a series of layers each of which provides a set of services.(Layered model) • example : layered communication protocols • Characteristics • Supports the incremental development of systems. • Basic facilities which are required by all abstract machines may be provided by inner layers.

21. Cryptography File interface Key management Authentication Users

22. Control models • At the architectural level, these models are concerned with the control flow between sub-systems. • Two approaches • Centralized control • Event-based control

23. Centralized model • One sub-system has overall responsibility for control and starts and stops other sub-system. • Two classes • The call-return model : Top-down subroutine model where control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree. • The manager model : One system component is designated as a system manager and controls the starting, stopping and coordination of other system processes.

24. Event-driven systems(1) • Each sub-system can respond to externally generated events. • Two event-driven control models • Broadcast models • Interrupt-driven models] • Broadcast model • An event is broadcast to all sub-systems. Any sub-system which is designed to handle that event responds to it. • Evolution is relatively simple. • Sub-systems don’t know if or when events will be handled. • Debugger

25. Event-driven systems(2) • Interrupt-driven control model • In real-time systems where external interrupts are detected by an interrupt handler. They are then passed to some other component for processing. • It allows very fast responses to events to be validate. • It is complex to program and difficult to validate.

26. Modular decomposition • Two models • An object-oriented model • A data-flow model

27. Object models • A system structured into a set of loosely coupled objects with well-defined interfaces. • The decomposition is concerned with object classes, their attributes and operations. • Because objects are loosely coupled, the implementation of objects can be modified without affecting other objects. • To use services, object must explicitly reference the name and the interface of other objects.

28. Data flow models(1) • Functional transformations process their inputs and produce outputs. • Pipe and filter model • Characteristic • Need for a common format for data transfer which can be recognized by all transformation. • Some filters may duplicate preparatory functions of other filters.