System Design

1. System Design

2. System Design :-- • Design is the first step to moving from the problem domain towards the solution domain. Design is essentially the bridge between requirements specification and the final solution. • The design of a system is essentially a blueprint or a plan for a solution for the system.

3. Design Objectives :- Some desirable properties for a software system design are: • Verifiability • Completeness • Consistency • Efficiency • Traceability • Simplicity/understandability

4. Verification:- The design should be correct. We would like the design to be such that its correctness could be verified. Verifiability of design is concerned with how easily the correctness of the design can be argued. • Completeness :- requires that all the different components of the design should be specified. That is all the relevant data structure, modules, external interfaces, and module interconnections are specified. Consistency requires that there are no inconsistencies in the design.

5. 3 Traceability (Visible) : is an important property that can aid design verification. It requires that design element must be traceable to the requirements. 4 Efficiency : of any system is concerned with the proper use of resources by the system. • Simplicity and understandability are most important quality criteria for software systems. • During maintenance, the first necessary step that a maintainer has to undertake is to understand the system to be maintained. A simple and understandable design will make the job of the maintainer easier.

6. Design principles • Producing the design of large system can be an extremely complex task. Ad-hoc methods for design will not be sufficient; some basic guiding principles that can be employed to produce the design of a system principle are as under. • The principles discussed here form the basis for most of the design methodologies:

7. 1. Problem partitioning : When solving small problem, the entire problem can be tackled at once. For solving larger problems, the basic principle is the time-tested principle of “divide and conquer”. These principles mean “divide into smaller pieces, so that each piece can be conquered separately”. For software design, therefore, the goal is to divide the problem into manageably small pieces that can be solved separately. The basic motivation behind this restriction is the belief that if the pieces of a problem are solvable separately, the cost of solving the entire problem is more than the sum of the cost of solving all the pieces.

8. As the number of components increases, the cost of partitioning together with the cost of this adds complexity, and may become more than the saving achieved by partitioning. It is at this point that no further partitioning needs to be done. The designer has to make the judgment about when to stop partitioning.

9. 2. Abstraction • Abstraction is a very powerful concept. Abstraction is tool that permits a designer to consider a component at an abstract level, without worrying about the details of the implementation of the component. • Abstraction is the required part of the design process, and is essential for problem partitioning.

10. Abstraction is used for existing components as well as new components that are being designed. Abstraction of existing components plays an important role in the maintenance phase. • The basic goal of system design is to specify the modules in a system and their abstractions. Once the different modules are specified, during the design the designer can concentrate on one module such that the abstract specifications of each module are satisfied.

11. 3. Top-down and Bottom- up strategies • A system consists of components, which have components of their own, thus system is a hierarchy of components, the highest level component corresponding to the total system. To design such a hierarchy, there are two different approaches possible-top-down and bottom-up. The top-down approach starts from the highest level components of the hierarchy and proceeds through to lower levels. A bottom-up approach starts with the lowest level component of the hierarchy and proceeds through progressively higher levels to the top-level component.

12. Top-down design methods often result in some form of stepwise refinement. More concrete level, until we reach a level where no more refinement. More concrete level, until we reach a level where no more refinement is needed and the design can be implemented directly. • Bottom-up methods work with layers of abstraction. Starting from the very bottom, operations are implemented that provide a layer of abstraction. The operations are implemented that provide a layer of abstraction. The operations of this layer are then used to implement more powerful operations and a still higher layer of abstraction, until the stage is reached where the operations supported by the layer are the ones that are desired by the system.

13. Module Level Concepts • A Module is logically separable part of a program. It is a program unit that is discrete and identifiable with respect to the compiling and loading. • Module can be macro, a function, a procedure, a process or a package. Partitioning a system into modules is useful only if the modules are solvable separately, and the modifiable separately. • Some criteria must be used to select modules so that the modules support this coupling and cohesion is two such modularization criteria which are often used together.

14. 1. Coupling (Combination, Paring, Mixture): • Two modules are considered independent if one can function completely without the presence of other. Obviously if two modules are independent. Then they are solvable modifiable separately. However all the modules in a system cannot be independent of each other as they must interact with other such that together they can produce the desired external behavior of the system. The more connections between modules, the more dependent they are in the sense that more knowledge about the one module is required to understand or solve the other module. • The notion of the coupling attempts capture this concept of “how strongly” different modules are interconnected with each other.

15. In general, the more we must know the about module A in order to understand module B, the more closely connected A to B. “Highly Coupled” modules are joined by string interconnections, while “Loosely Coupled” modules have weak interconnections. Independent modules have no interconnections. • Coupling between modules, among them the most important are: • The type of connection between modules, the complexity or the interface, and the type of information flow between modules.

16. Factors affecting coupling

17. 2. Cohesion (Unity, Consistency ): • Cohesion of modules represents how tightly bound the internal element of the module are to one-another. • Cohesion & coupling are clearly related; usually the greater the cohesion of each module in the system, the lower will be the coupling between modules. This correlation is not perfect. But has been observed in practice. There is several of cohesion. • Coincidental • Logical • Temporal • Procedural • Communicational • Sequential • Functional

18. CoincidentalCohesion occurs when there is no meaningful relationship among the elements of module. It can occur if an existing program is “modularized” by splitting it into pieces and making different pieces to be modules. • A module has Logical Cohesion if there is some logical relationship between the elements of a module, and the elements perform functions that fall in the some logical class.

19. Temporalcohesion is the same as logical cohesion, except that the elements are also related in time, and are executed together. Modules that perform activities like “initialization”, ”clean-up” and “termination” are usually temporally bound. • A Procedurallycohesive module contains elements that being to a common procedural unit. For examples, a loop or a sequence of decision statements in a module may be combined to from a separate module. A module with only procedural cohesion may contain only part of a form a separate module. A module with only part of a complete function or parts of several functions.

20. A module with communicational cohesion has elements that are related by a reference to the same input or output data. • Functional cohesion is the strongest cohesion. In a functionally bound module, all the elements of the module are related to performing a single function. • E.g. A module like “compute square root” and “sort the array”

21. Structured Design Methodology Structureddesign methodology (SDM) views every software system as having some inputs which are converted into desired outputs by the software system. SDM attempts to reduce the complexity of software by dividing it into functional modules, which have few interconnections between them in terms of cohesion and coupling we can say that the primary goal of structured design is to divide problems into modules.

22. 1. Structured Chart In SDM , the design is represented by structured chart. The structured chart of a program is a graphic representation of its structures. In structured chart a module is represented by a box, with the module name written in a box. An arrow from a module A to another module B represents that module A invokes the module B. B is called subordinate of A and A is called the super ordinate of B. The arrow is labeled by the parameters received by B as input, and parameters returned by B as output, with the direction of flow of input and output parameters represented by small arrow. Figure: Iteration and Decision representation B C D A A B C D

23. 1.1 (A) Input , output, Transform and Coordinate Modules Input module: some modules takes information from their subordinates, and then pass it to their supriordinate. Output module: some modules takes information from its superiordinate , and pass it on its subordinate. Transform module: some modules that exists for transforming data into other form. E.g. Computational module Coordinate module: there are modules which manage flow of data to and from different subordinates. Composite module: module performs functions of more than one type. (Data to (Data from superiordinate) superiordinate) Input Composite transform coordinate output

24. Functional oriented approach :- • The function-oriented methods for design and describe one particular methodology—the structured design methodology— in some detail. • In a function-oriented design approach, a system is viewed as a transformation function, transforming the inputs to the desired outputs. • The purpose of the design phase is to specify the components for this transformation function, so that each component is also a transformation function. That is, each module in design supports a functional abstraction. • The basic output of the system design phase, when a function oriented design approach is being followed, is the definition of all the major data structures in the system, all the major modules of the system, and how the modules interact with each other.

25. Object-oriented approach An Object Oriented model closely represents the problem domain, which makes it easier to produce and understand designs. As requirements change, the objects in a system are less immune to these changes, thereby permitting changes more easily. Inheritance and close association of objects in design to problem domain entities encourage more reuse, that is, new applications can use existing modules more effectively, thereby reducing development cost and cycle time. Object-oriented approaches are believed to be more natural and provide richer structures for thinking and abstraction. Common design patterns have also been uncovered that allow reusability at a higher level.

26. Design specification In case of structured chart, each module is represented by a box with a name. the functionality of module is communicated by name of box and interface is communicated by data items labeling the arrows. Relying only on a name to communicate what the module does is clearly not sufficient and can lead ambiguities later on. To avoid this problem, the design document is made, which is used as reference for design phase for later activities like detailed design and implementation. A design specification should contain: Problem specification Major data structure Modules and their specifications Design decision

27. Design Specification (continue) 1.Problem specification: Problem specification or restatement is first step of design process. In SDM for e.g. DFG is a restatements of requirements of the system. A complete hierarchical DFG, with specifications of data flows that occur in DFG , is problem specifications. 2. Major data structure: During system design the major D.S. for software are identified. In structure design these are the data elements traveling along the arcs in structured chart. 3. Module specification: For specifying a module the design document must specify: (a) The interface of module( all data items, their types and whether they are for input and /or output) (b)The abstract behavior of module(what the module does) by specifying the module's functionality or its input/output behavior.

28. Design Specification (continue) (c) All other modules used by the one being specified. This information is quite useful in maintaining and understanding the design. 4.Design Decision: In order to aid the understandability of the design , all major decision that were made by designers during design process should be explained explicitly. The choices that were available and the reasons for making a particular choice should be explained. This makes a design more visible and will help in understanding the design.

29. Design Verification The output of the system design, should be verified before proceeding with activities on the next phase. Design Review: The purpose of design reviews is to ensure that the design satisfies the requirements and that the design is of “good quality”. Detecting errors in design is aim of design reviews. In that a group of people get together to discuss the design with the aim of detecting design errors or undesirable properties. The review group must include a member of both system design team and detailed design team, the author of requirements documents , the author maintaining design document and independent s/w quality engineer. Each member study the design before the meeting and with the aid of a checklist, marks the items that the reviewer feels are incorrect or need clarification. The member ask the questions and chief designer tries to explain the situation

30. Design Verification The aim of meeting is to uncover design errors . The meeting ends with a list of action items, which are later acted by design team. Further reviews may be organized if needed. Perhaps the most significant design error is omission or misinterpretation of specified requirements. Sometimes design error is caused by ambiguities in the requirements. A Sample Checklist: Is each of the functional requirements taken into account? Are there analyses to demonstrate that performance requirements can be met? Are all assumptions explicitly stated, and are they acceptable? Are there any constraints on the design beyond those in the requirements? Are external specifications of each module completely specified? Have exceptional conditions been handled? Are all the data formats consistent with the requirements? Is the design modular, and does it conform to local standards? Are provisions made to guard against overflow? 

31. (B) Automated Cross-Checking: if the design is expressed in a language that is designed for machine processing, then most consistency checking can be automated. For e.g. if a language like PDL(Process design language) is used then design can be compiled to check for consistency. • Those module used in a module that is defined in system design must also be defined in design.e.g. prototype declaration of function • To check interface of a module is consistent with the way in which other module use it. • Whether data used is consistent with declaration in data structure of module.

32. Detailed Design In design document more detailed specification is given in natural language what a module is supposed to do. These non formal methods of specification can lead to problems during coding, if coder is different from designer. The reason is misinterpretation. So, first step is that the specification of module must be given precisely. Once, the module is precisely specified, the internal logic for module that will implement the given specifications can be decided.

33. 1.0 Module specifications Following are desirable properties that module specifications should have: It should be complete. That is given specifications should specify the entire behavior of module that only correct implementation satisfy the specifications. It should be unambiguous. The specifications should be easily understandable and specification language should be such that specifications can be easily written. The specifications should be implementation-independent. Specification should not suggest any particular method for implementation of module. Algorithm of module is not specified. It is best to provide operational specifications, where specifications are given in a very high-level specification language. If interpreter or compiler is available for specification language, then the added advantage of operational specification is that a prototype is available. This prototype can be used for actual testing or building a prototype of entire system.

34. 1.1 Specifying functional modules To specify the external behavior of a module supporting functional abstraction, one need to specify the inputs on which module operates, the outputs produced by module and relationship of outputs to inputs. One method for specifying modules was proposed by based on pre- and post-conditions. In this method constraints on the input of module were specified by a logical assertion on the input state called pre-condition. The output was specified as a logical assertion on output state called post-condition. No relationship is explicitly specified between the input and output. Validity of output is specified entirely by the post-condition assertion.

35. 1.1 Specifying functional modules( continue) As an example, consider a module sort to be written to sort a list L of integers in ascending order. The pre- and post- condition of this module are: Pre-Condition: non-null L Post- Condition: for all I, L[i]<=L[i+1] This specification states that if input state for the module sort is non-null L, the output state should be such that the elements of L are in increasing order. These specifications are not complete. It does not state anything about the implicit requirement of the sort module that the final state of the list L should contain the same elements as the initial list.

36. 1.2 Specifying Data Abstractions Data abstractions is extremely useful for hiding information and providing high-level abstraction. Many languages including Ada, C++ and Java support abstract data types. Axiomatic Specification technique is used for specifying abstract data types. axioms are used that specify the behavior of different interaction of operations. The interaction for which axiom are chosen are such that they completely describe the behavior of operations. For example: we define a stack has four operations: Create: to create a new stack Push: to push an element on a stack Pop: to pop the top element from the stack Top: returns an element on top of stack

37. 1.2 Specifying Data Abstractions( continue) The axiomatic specifications for stack of integers is as below: 1. stack[ integer] declare 2. create( )stack; 3. push (stack , integer ) stack; 4. pop ( stack ) stack; 5. top ( stack )integer U undefined; var 6. s: stack ; i: integer; forall 7. top ( create ( ))=undefined; 8. top (push (s, i))=i; 9. pop (create( ))= create(); 10. pop (push (s , i ) )=s; end;

38. 1.2 Specifying Data Abstractions( continue) Axiomatic specification language Syntactic specification Semantic specification 1.Header 2.operation declaration 3. Variable declaration • The semantics of operations in Axiomatic specification technique are • specified in semantic part by enumerating axioms for operations. The following constructs are allowed for writing axioms: • - free variables, ,if-then –else, Recursion , Boolean expression • e.g. top( push (s,i ) )=i; • Header: specifies name of data types and any parameter it may have. • e.g. stack [ integer ] • Operation declaration: all the operations of ADT must have a declaration in operation declaration part. The type can be ADT itself , Boolean or integer. • e.g. declare • create ( ) stack; • Variable declaration: variables can be declared only of types that have appeared before .The variables are declared for use in semantic specifications. E.g. S: stack ; i : integer;

39. 1.2 Specifying Data Abstractions( continue) Determining completeness of given set of axioms , we use notation of sufficient completeness. For defining sufficient completeness we divide into two sets S & O. Set of Operation Set O ( behavior type) e.g. top ( non behavior) Set S e.g. push, create, pop Constructors e.g. push , create Extension operator e.g. pop

40. 1.2 Specifying Data Abstractions( continue) The set S contains operations returning a value of type being specified. The set O , contains operations returning the value of types other than the type being specified Consider the following instance of type stack push ( pop (push ( push ( create( ) ,1 ) , 2 ) ) , 3 ) Even this instance can be created by following constructors Push ( push ( create ( ) , 1 ) , 3) Consider an expression consisting non constructor applied to a constructor. For data types with n operations if there are m constructors the total number of axioms generated will be : m * ( n – m ) e.g. pop ( push ( push ( create ( ) ,1),2 ) ),3) here n = 4 , m = 3 So : 3 * ( 4 – 3 ) =3 Total number of axioms will be 3

41. 2.0 Detailed design and Progress Design Language The methods used to specify the system design typically focus on external interfaces of modules and can not be extended to specify internals. There are 3 methods to communicate logic precisely: Process design language( PDL) Logic / algorithm design State modeling of classes PDL: PDL is combination of natural language (e.g. English) and formal language ( e.g. high level C,C++ etc.). High level language is useful for implementation but not important for communicating design. For example, consider the problem of finding the minimum and maximum of set of numbers in a file and outputting the numbers in a PDL is as shown.

42. PDL ( continue) PDL Description of minmax program Minmax( infile ) ARRAY a DO UNTIL end of input READ an item into a ENDDO max , min := first item of a DO FOR each item in a IF max < item THEN set max to item IF min > item THEN set min to item ENDDO END PDL has an over all outer syntax of a structured programming language and has a vocabulary of a natural language. One way to use PDL is to generate a rough outline of entire solution at a given level of detail. When the design is agreed at this level , more detail can be added. This allows successive refinement approach , and can save considerable cost by detecting the design errors early during design phase. It also aids design verification by phases which helps in developing error- free design.

43. PDL ( continue) The DO construct is used to indicate repetition. The construct is indicated by: DO iteration criteria one or more statements ENDDO The iteration criteria can be chosen to suit the problem, and unlike a formal programming language, they need not be formally stated. Example are: DO WHILE there are characters in input file DO UNTIL the end of file is reached A verity of data structures can be defined and used in PDL such as lists, tables and integers.

44. (B) Logic / Algorithm Design The basic goal of detailed design is to specify the logic for different modules that have been specified during system design. Specifying the logic will require developing an algorithm that will implement given specifications. An algorithm is a sequence of steps that need to be performed to solve the given problem. A procedure is a finite sequence of well-defined steps or operations, each of which requires a finite amount of memory and time to complete. There are a number of steps that one has to perform while developing an algorithm. The starting step is statement of problem. The problem for which an algorithm is being designed has to be precisely and clearly stated The next step is development of a mathematical model for the problem. In modeling one has to select the mathematical structures that are best suited for problems.

45. (B) Logic / Algorithm Design ( continue ) 3. The next step is design of algorithm. During this step the data structure and program structure are decided. 4. The most common method for designing algorithms is use of stepwise refinement techniques. The stepwise refinement technique breaks the design problem into a series of steps. During refinement, both data and instruction have to be refined. A stepwise refinement technique is top-down method for developing detailed design. For stepwise refinement use PDL because it is enough flexible and having high degree of precision. An example: Let us consider the problem of counting different words in a text file. e.g. a count module is specified whose job is to determine the count of different words. A simple strategy for the first step is given below: int count ( file ) FILE file; word-list wl; { read file into wl; sort (wl); count= different-words (wl); printf (count ); } Figure: strategy for the first step in stepwise refinement

46. (B) Logic / Algorithm Design ( continue ) The “primitive” operations used in this strategy are very high level and need to be further refined. Specially there are 3 operations that need refinement. There are: Read a file into word list, whose purpose is to read all the words from the file and create a word list. Sort (wl), which sorts the word list in ascending order. Count different words from a sorted word list. Refinement of 1 step, read a file into word list read-from-file( file , wl) FILE file; word-list wl; { initialize wl to empty; while not end of file { get-a-word from file; add word to wl; } } figure : Refinement of reading operation

47. (B) Logic / Algorithm Design ( continue ) For next refinement step we select the counting function. int different-words ( wl ) word-list wl; { word last, cur; int cnt; last = first word in wl; cnt =1; while not end of list { cur= next word from wl if ( cur <>last) { cnt = cnt +1; last = cur; } } return ( cnt ); }

48. (B) Logic / Algorithm Design ( continue ) Similarly, we can refine the sort function. Once these refinement are done , we have a design that is sufficiently detailed and needs no further refinement. For more complex problems many successive refinements might be needed for a single operation. Design for such problems can proceed in two ways- Depth first and Breath first. In depth first approach, when an operation is being refined , its refinement is completely finished( which might require many levels of refinement) before refinement of other operations begins. In breath first approach, all operations needing refinement are refined once. Then all the operations specified in this refinement are refined once. This is done until no refinement is needed. A combination of both approach could also be followed. In stepwise refinement, in each refinement step we specify the operations that are needed. But in structured design, the focus is on partitioning the problem into input , output and transform module.

49. 3.0 Verification Validating that the system as design is consistent with the requirement of the system is not stressed during detailed design. The focus is on showing that the detailed design meets the specification laid down during system design. Three different verification methods are: Design walkthroughs Critical Design Review Consistency Checkers Design walkthroughs: A design walkthrough is manual method of verification. A design walkthrough is done in an informal meeting called by the designer or the leader of designer’s group. The walkthrough group is usually small and contains along with the designer , the group leader and /or or another designer of the group. In a walkthrough the designer explains the logic step by step, and members of the group ask questions, point out possible errors or seek clarifications. A beneficial side effect is that during process of explanation of design, the designer can himself can uncover some of the errors.

50. 3.0 Verification ( continue) 2. Critical Design Review: The purpose of critical design review is to ensure that the detailed design satisfies the specifications laid down during system design. This is similar to design walkthrough but here there is formal meeting. The reviewer group includes author of detailed design, a member of system design team, a programmer responsible for coding the modules and s/w quality engineer. Each member studies the design before hand and with the help of a checklist marks items that the reviewer feels are incorrect and need clarification. The member ask question and designer tries to explain the situation. During discussion design errors are revealed. The meeting should end with list of action items , be acted on later by the designer.