Software Design

CS215 Software Engineering
Reference: Software Engineering Concepts Richard Fairley

Software Design
The process of design involves conceiving and planning out in mind and making a drawing, pattern and sketch of it
Software Design External Design Architectura l Design Detailed Design

Internal Design

External Design
External Design involves conceiving, planning out, and specifying the externally observable characteristics of software product. The external design includes ‡ User displays and report format ‡External data source and sinks ‡Functional Characteristics ‡ Performance requirement and high level process structure.

Internal Design Internal design involves conceiving. planning out and specifying the internal structure and processing details of the software. The main aim is to record ‡Design decisions ‡Indicate why certain alternative and trade-off were chosen ‡Elaborate test plan ‡To provide a blue print for implementation. testing and maintenance activity. .

Internal Design Outcome of Internal Design are ‡ Architectural structure ‡ Details of algorithms and data structures ‡ Test plan .

Architectural Design ‡ Concerned with refining the conceptual view of the system. ‡ Identifying internal processing functions ‡ Decomposing high-level functions into sub functions. ‡ Defining internal data streams and data stores ‡ Establishing the relationship and interconnection between among functions and data streams and data stores. .

Detailed Design ‡ includes specification of algorithm that implement the functions. ‡ Concrete data structure that implement the data stores. ‡ The actual interconnection among the functions and data structures ‡ Packaging scheme for system .

Phases Analysis Design Implementation Coding Debugging and testing Activities External Planning and Architectural requirement Detailed definition Reviews SSR PDR CDR .

Phases in the design process Requirements specification Design activities Architectural design Abstract specificatio n Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Design products Data structure specification Algorithm specification .

Design phases ‡ ‡ ‡ ‡ Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system interfaces Component design Decompose sub-systems into components ‡ Data structure design Design data structures to hold problem data ‡ Algorithm design Design algorithms for problem functions .

Design Concepts ‡ ‡ ‡ ‡ ‡ ‡ ‡ Abstraction Structure Information hiding Modularity Concurrency Verification Design aesthetics .

. data streams and data stores have been established. ‡Abstraction permits the separation of conceptual aspects from the implementation details.Abstraction ‡Abstraction is the intellectual tool that allow us to deal with concept apart from their implementations. ‡Abstraction allow us to organize and channel out our thought process by postponing the structural consideration and detailed algorithm details until the functional characteristics.

Abstraction Mechanism ‡ Functional Abstraction ‡ Data abstraction ‡ Control abstraction .

‡ Functional abstraction can be generalized to selection of sub programs called as groups. The ability to parameterized a sub program and to bind different parameter values on different invocations of the subprogram is a powerful abstraction mechanism. . ‡ Some of these subprograms may have visible property and some may be hidden.Functional Abstraction ‡ Involves the use of parameterized sub program.

g.Data Abstraction ‡ Involves specifying a data type or data object by specifying legal operations on them. for stack can specify POP. representation and manipulation details are suppressed. . PUSH operation without their actual implementation. E. ‡ Abstract data type are abstract in the sense that the representation details of the data items and the implementation detail of functions that manipulate the data items are hidden within the group that implements the abstract data type.

e.g. IF and WHILE statements are example of abstraction of machine code implementation that involves conditional jump instruction.Control Abstraction ‡ Is used to state a desired effect without stating the exact mechanism of control. for all I in S sort files I .

‡ Design should begin with the a list of difficult design decisions and design decisions likely to change.Information Hiding ‡ Using Information hiding approach. each module in the system hides the internal details of its processing activities and modules communicate only through well defined interfaces. .

‡ The format of control blocks such as those for queues in an operating system. ‡ Character codes. and other implementation details.Information Hiding ‡ Each module is designed to hide such a decision from other modules. . Other candidates for information hiding include ‡ A data structure. ordering of character set. its internal linkages. and the implementation details of the procedures that manipulate it.

masking. .Information Hiding ‡ Shifting. and other machine dependent details.

. consisting of nodes and arcs.Structure ‡ The use of structuring permits the decomposition of large system into smaller. ‡ The most general form of the system structure is the network. ‡ The nodes can represent processing elements that transform the data and the arcs can be used to used to represent data links between nodes. more manageable units with well-defined relationships to the other units of the system. A computing network can be represented as directed graph.

‡ The most complex form of computing network is a distributed computing system in which each node represents a geographically distinct process with private memory. ‡ A network might specify the data flow and processing steps for single subprogram or the data flow among a collection of sequential subprograms.Structure ‡ Alternatively node can represent data stores and and the arcs data representation. .

‡ Each group might consist of visible specification part and a hidden body.data abstraction groups and control abstraction group. .Structure ‡ Inside each processes one might have functional abstraction groups .

.Modularity Modular systems consist of a well defined. ‡Each function manipulate no more than one major data types. ‡ Each function in each abstraction has a single. well defined purpose. manageable units with well defined interfaces among units Desirable properties of modular system includes] ‡ Each processing abstraction is a well defined sub system that is potentially useful in other application.

‡ Function that manipulate instances of abstract data types are encapsulated with the data structure being manipulated.Modularity ‡ Function share global data selectively. It is easy to identify all routines that shares a major data structure. .

.Concurrency ‡ Software systems can be categorized as sequential or concurrent. In sequential systems only one portion of the software is active at any time. ‡ Concurrent system can have independent processes that can be activated simultaneously if multiple processors are available.

.Concurrency ‡ Problems unique to concurrent system includes Deadlocks Mutual Exclusion Synchronization of processes ‡ Concurrency is the fundamental principle of software design because parallelism in software introduces added complexity and additional degrees of freedom into design process.

.Verification This is typically done in two steps: ‡ verification that the software requirement definition satisfy the customer needs( verification of requirements) ‡ verification that the design satisfy the requirements definition( verification of the design).

Aesthetics Simplicity. elegance and clarity of purpose distinguish products of outstanding quality from mediocre products .

Design Notations ‡ ‡ ‡ ‡ ‡ ‡ ‡ Data flow diagrams Structure charts HIPO diagrams Procedure specifications Pseudocode Structured English Structured Flowcharts .

.Data flow diagrams ‡ Data flow diagrams are directed graphs in which the node specify the processing activity and the arcs specify the data items transmitted between processing nodes.

Data Flow Diagram (depicting flow of data among components) Source or Destination of Data Flow of Data Processing Data Store .

Example of DFD Inventory Info Packaging Instructions Order Customer Invoice Process Order Shipping Instruction Package Order Customer Info .

parameters. ‡ The structure of a hierarchical system can be specified using a structure chart. as well as input and output parameter attribute. ‡ The chart can be augmented with module.bymodule specification of the input and output parameters. . ‡ During architectural design the parameter attributes are abstract: they are defined into concrete representation during detailed design. and interconnections in a system.Structure Charts ‡ Used during architectural design to document hierarchical structure.

.Difference Between Flow Chart and Structure Chart ‡ Structure chat has no decision boxes. ‡ Sequential ordering of task inherent in flow chart can be suppressed in structure chart.

Format of a structure chart A Repetition Selection B F C G out D E H in 1 2 3 4 5 6 7 8 Input Output Data Data .

‡ A set of HIPO diagrams contains a visual table of contents. and as external documentation aids for released products. . ‡ The visual table of contents is a directory to the set of diagrams in the package. a set of overview diagrams and a set of detail diagrams. a summary of contents of each overview diagram and a legend of symbol definition . it consists of a treestructured directory.HIPO diagrams ‡ HIPO diagrams( Hierarchy-Process-Input-Output) were developed at IBM as design representation scheme for top-down software development.

‡ Overview diagrams specify the functional processes in the system. Each overview diagram describes the inputs. An overview diagram can point to several subordinate detail diagrams. and outputs for the function being specified. as required. .HIPO Diagrams ‡ The visual table of contents is a stylized structure chart. processing steps.

--2.Visual Table of Contents for a HIPO package Legend 2 1 5 8 3 Contents 1. --3. --- 4 6 7 10 9 12 11 .

‡ They also provide a natural transition from architectural to detailed design and from detailed design to implementation. .Procedure Templates ‡ Procedure interface specifications are effective notations for architectural design when used in combination with structure charts and data flow diagrams.

attributes. purposes.purpose) INPUT ASSERTION: ( preconditions) OUTPUT ASSERTION:(post conditions) GLOBALS:( name.modes. modes.attributes. shared with) SIDE EFFECTS: LEVEL 2 .Procedure Templates PROCEDURE NAME: PART OF( subsystem name & number) CALLED BY: PURPOSE: DESIGNER/DATE(s): LEVEL 1 PARAMETERS:(names.

structure flow chart. attributes.purposes) EXCEPTIONS: (conditions. responses) TIMING CONSTRAINTS: OTHER LIMITATIONS: LEVEL 3 PROCEDURE BODY: (pseudocode. decision table) LEVEL 4 .Procedure Templates LOCAL STRUCTURES: (names. structured English.

Key words and indentation describes the flow of control while English phrases describes the processing actions. concise. and End. English language phrases that are structured by keywords such as IFTHEN-ELSE. .Pseudocode ‡ Used in both the architectural and detailed design phases. While-DO. ‡ Using pseudocode the designer describes the system characteristics using short.

‡ E.g. each English phrase is expanded into more detailed pseudocode until the design specification reaches the level of detailed implementation language.Open file Read the first text record .Pseudocode ‡ Using the top-down design strategy \. Initialize tables and counters.

.Structure Flow Charts ‡ Traditionally used for specifying and documenting algorithmic details in a software system. directed arcs for specifying interconnections between boxes and a variety of symbols for representing input and output. ‡ Unlike flow chart structure charts are restricted to composition of certain basic terms. ‡ Flowcharts incorporate rectangular boxes for actions. diamond shape boxes for decisions.

. ‡ Structured flow chart are preferred in situations where clarity of control flow is to be emphasized. They have same expressive power as pseudo code. ‡ Structure flowchart are logically equivalent to pseudo code.‡ The basic forms are characterized by single entry into and single exit from the form.

Structured Flow Charts S1 S2 P S REPEAT S UNTIL P IF P THEN S1 ELSE S2 WHILE P DO S S P P S1 S2 .

3.Preheat Oven to 350 degree F.Add flour and baking soda.MIX eggs.milk.Pour into a greased baking dish 5. Structured English is often used to specify cookbook recipes. 1. 4. Structured English can be used at any desired level of detail.Structured English Structured English can be used to provide a step-bystep specification for an algorithm. and vanilla. 2.Cook until done. .

. They are useful for specifying algorithm logic during detailed design.Decision Tables Decision tables can be used to specify complex design logic in a high level software specification.

coupling and cohesion are two modularization criteria. which are often used together. ‡ In a system using functional abstraction. . ‡ A module is a logically separable part of a program.Module-Level Concepts ‡ Now we will consider some concepts specific to function oriented design.

.Cohesion ‡ Cohesion of a module represent how tightly bound the internal elements of the module are to one another. ‡ We are interested in determining how closely the elements of module are related to one another. ‡ The greater the cohesion of each module in the system. the lower the coupling between module is.

Cohesion ‡ A measure of how well a component 'fits together' ‡ A component should implement a single logical entity or function ‡ Cohesion is a desirable design component attribute as when a change has to be made. it is localised in a single cohesive component ‡ Various levels of cohesion have been identified .

Cohesion levels ‡ Coincidental cohesion (weak) ± Parts of a component are simply bundled together ‡ Logical association (weak) ± Components which perform similar functions are grouped ± For example: output text to screen output line to printer output record to file ± Seems ok ± Problem is it carries out a range of similar but different actions ± No single well defined action .

Cohesion levels ‡ Temporal cohesion (weak) ± ± Components which are activated at the same time are grouped For example: clear screen open file Initialise total ± ± again not related solution is to make initialisation module all other specialised modules: call init_terminal call init_files call init_calculations .

Cohesion levels ‡ Procedural cohesion (weak) ± The elements in a component make up a single control sequence ‡ Communicational cohesion (medium) ± All the elements of a component operate on the same data ± e.g. display and log temperature ‡ Sequential cohesion (medium) ± The output for one part of a component is the input to another part .

Cohesion levels ‡ Functional cohesion (strong) ± optimal type of cohesion ± performs a single well-defined action on a single data object ± e.g. calculate average ± Each part of a component is necessary for the execution of a single function ‡ Object cohesion (strong) ± Each operation provides functionality which allows object attributes to be modified or inspected .

Cohesion as a design attribute ‡ Not well-defined. Often difficult to classify cohesion ‡ Inheriting attributes from super-classes weakens cohesion ‡ To understand a component. the super-classes as well as the component class must be examined ‡ Object class browsers assist with this process .

Coupling ‡ A measure of the strength of the inter-connections between system components ‡ Loose coupling means component changes are unlikely to affect other components ‡ Shared variables or control information exchange lead to tight coupling ‡ Loose coupling can be achieved by state decentralisation (as in objects) and component communication via parameters or message passing .

Tight coupling Module A Module B Module C Module D Shared data area .

Loose coupling Module A A’s data Module B B’s data Module C C’s data Module D D’s data .

Assembler) ‡ Modifying data within another module ± fault that appears in one module may be due to another ± complicated understanding and debugging ± can be done via global variables or pointers or call be reference in C++ / Java ‡ Shared or global data .Coupling levels ‡ Altering another modules code (LISP.

length). ‡ Procedure call with parameters that are pure data ± ideal is call by value.1. where a small number of parameters are used and a copy of the data is passed to the procedure invoked ± clear what information is being communicated . write open.2 for read. length). device buffer.Coupling levels ‡ Procedure call with a parameter that is a switch (or a function pointer in C) ± io (command. better to use ± read( device. ± where command is 0. buffer.

Coupling levels ‡ Passing a serial data stream ± ± ± ± ± ± most ideal situation one module passes stream of data to another once passed data is outside control of process/module like piping in UNIX data can be thought of as a temporary intermediate file only possible in languages that support concurrency such as Ada and Erlang and Parallel C .

Coupling and inheritance ‡ Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing ‡ However. Such changes must be carefully controlled . Changes made to the attributes or operations in a super-class propagate to all sub-classes. an object class is coupled to its super-classes.

DESIGN TECHNIQUES Several techniques have been developed for software design. These are ‡ Step-Wise Refinement ‡ Levels of abstraction ‡ Structured Design ‡ Integrated top down development ‡ Jackson Design method .

Step-Wise Refinement
Step-wise refinement is a top-down technique for decomposing a system from high-level specifications into more elementary levels. This is also called as stepwise program development and successive refinement . It involves following activities: ‡ Decomposing design decision to elementary levels. ‡ Isolating design aspects that are not truly interdependent.

‡ Postponing decisions concerning representation details as long as possible. ‡ Carefully demonstrating that each successive step in the refinement process is faithful expansion of previous steps.

Benefits of step-wise refinement
‡ ‡ ‡ ‡ Top-down decomposition incremental addition of details Postponement of design decisions Continual verification of consistency

Integrated Top-Down Development ‡ Integrated top-down development integrates design. ‡ Lower-level routines can not access the high-level routines. ‡ They have the primary function function of coordinating and sequencing lower-level routines. . ‡ Design proceeds top-down from the highest level routine. implementation. and testing.

PUT TEST GET DESIGN GET CODE GET TEST MAIN GET DESIGN PROCESS CODE PROCESS STUBS FOR SUB1. PUT. GET. GET. SUB2 TEST MAIN GET PROCESS DESIGN PUT CODE PUT TEST MAIN. PUT. PROCESS. PROCESS. PUT DESIGN SUB1 CODE SUB1 TEST MAIN. PROCESS. PROCESS.STRATEGY: MAIN GET PROCESS PUT SUB1 SUB2 DESIGN MAIN CODE MAIN STUBS FOR GET.SUB1 DESIGN SUB2 CODE SUB2 TEST MAIN GET.SUB2 .SUB1.

. ‡ Design and coding are integrated. ‡ Test cases are developed systematically and each routine is tested in actual operating environment.Advantages ‡ This technique provide orderly and systematic framework for software development.

Disadvantages ‡ Early high level design decisions may have to be reconsidered when the design progresses to lower levels ‡ System may be very expensive test harness for newly added procedures .

‡ The problem is modeled by specifying the input and output data structure using tree structured diagrams. ‡ The structural model of the program is expanded into a detailed design that contains the operations needed to solve the problem. . ‡ The input-output model is converted into a structural model for the program identifying points of correspondence between nodes in the input and output trees.Jackson Structured Programming This a systematic technique for mapping the structure of problem into a program structure to solve the problem.

and alternate data items. repetition of data items. A B C D E o F 0 O selection * Zero or more occurrences G * H I Specification of object A using Jackson Structured Programming notation .Input and output data is specified using a graphical notation to specify data hierarchy. sequence of data.

‡ . b) the operations are associated with the program structure c) Program structure and operations are expressed in a notation called schematic logic. Control flow for selection and iteration are specified in this step.The second step of Jackson method involves converting the input and output structures into a structural model of the program. which is stylized pseudocode. ‡ The third step expands the structural model of the program into a detailed design model a) A list of operations required to perform the processing steps is developed.

Input and output structure of an inventory program INPUT FILE Part Group* Movement * record Issue o Receipt o NET * MOVEMENT TIME Output Report heading Body .

Correspondence between Input and output structure of an inventory program INPUT FILE Part Group* Movement * record Issue o Receipt o NET * MOVEMENT TIME Output Report heading Body .

Program Structure for an inventory problem Program Process heading Process Body Process PTGP * and line Process PTGP Body Process Record * Process Issue o Process Receipt o` Process line .

8. OPEN FILES CLOSE FILES STOP RUN READ A RECORD INTO PART_NUM. 2. 5. 3. 4.Operations needed in the inventory program 1. MOVMNT WRITE HEADING WRITE NET_MOVEMENT LINE SET NET_MOVMNT TO ZERO ADD MOVMNT TO NET_MOVMNT . 7. 6.

Association of operations wit Program Structure Program Process 5 heading Process Body 1 4 2 3 Process PTGP * and line 7 4 9 Process PTGP Body Process Record * Process Receipt o` Process line 6 Process Issue o 8 .

Sign up to vote on this title
UsefulNot useful