COSC 3351 Software Design. Software Design Methodology. Edgar Gabriel. Spring Outline

Transcription

1 COSC 3351 Software Design Software Design Methodology Spring 2008 Outline Causes of difficulties in software design Vehicles to overcome difficulties Various strategies to solve software design problems Understand the basic structure of software design methodologies 1

2 Causes for difficulties Complexity Number of internal states of large software projects orders of magnitude higher than hardware products Complex interactions between elements Basically no identical/repetitive elements Abstracted to function/classes -> high probability for errors in requirements and specifications -> high probability for mis-communication among team members Causes for difficulties Conformity Software expected to conform to standards imposed by others, e.g. Hardware, Existing software (e.g. Operating System, Database), Legislators Changeability No other complex product encounter such frequent changes as software Invisibility Did you know that the source code of your microwave is > 200,000 lines? 2

3 Type of design errors Incorrectness: the design does not meet the requirements Inconsistency: e.g. two design statements make conflicting assumptions about the functionality of a component Ambiguity: e.g. the design specification can be interpreted multiple ways Inferiority: the design does not address quality requirements adequately. Examples: inefficiencies, inflexibilities. Vehicles to overcome difficulties Axioms for good design Separation of Concerns: A complex problem can best be solved by devising intermediate solutions expressed in terms of simpler, independent problems Comprehension: the mind cannot manipulate more than seven [+- two] things at a time Translation: A correct design that meets its interface and behavior specifications in one environment will continue to meet its specifications in another environment, provided that the new environment provides equivalent services Transformation: design correctness is unaffected by replacement of equivalent components 3

4 Basic rules for software design Modular design: create units with loose inter-unit coupling Portable design: employ abstract context interfaces Malleable design: malleability can be achieved by modeling the end-users view of the external environment Conceptual integrity: uniform application of a limited number of design forms Intellectual control: recording design as increasingly detailed abstractions Visualization: representing design in visual notations such as diagrams and figures The context of design E.g. in the V model: Input: functional specification and non-functional requirements as the result of the requirements analysis and functional specification phases Output: design specification that describes software architecture and module design of the software components Similar steps for all other models 4

5 Stages of software design Architectural design Organization of the system as a composition of components Assignment of functionality to components Global control structures Protocols for communication, synchronization and data access Physical distribution Scaling and performance Dimensions of evaluation Selection among alternatives Detailed design Design strategies (I) Decompositional methods Top-down approach Starts with the original description of the problem or model Decompose the problem into sub-problems Solve the sub-problems separately Compositional methods Starts by identifying a set of particular entities and objects involved in the problem Each entities/objects are described and grouped Define relationship between entities -> create larger components 5

6 Design strategies (II) Design templates Many problems have a great deal of similarities Abstract similarities into templates Reuse proven design templates Incremental and evolutionary strategies Trial-and-error a design solution for a carefully chosen subset of requirements Evaluate against other requirements Make modifications to meet other requirements while preserving the required properties that it already has satisfied Popular Design Methods Jackson structured Programming (JSP) and Jackson System Development (JSD) Structured Methods, e.g. SADT and SSADM Object oriented methods, e.g. UML Various formal methods 6

7 Jackson Structured Programming Structured programming based on correspondence between data stream structure and program structure JSP structures programs and data in terms of fundamental operations, sequences, iterations and Selections Each program input and output is modelled as a separate Datsa Structure Diagram (DSD) Input and Output Structures are merged into a Program Structure Diagram (PSD) Jackson Structured Programming A simple operation is drawn as a box A sequence of operations is represented by boxes connected with lines (e.g. A consists of B, C, D) 7

8 Jackson Structured Programming An iteration is represented with joined boxes. In addition, the iterated operation has a star in the top right corner A selection is similar to a sequence but with a circle in the top right corner (e.g. A consists of either B, C or D) JSP example: a run-length encoder Input: a byte stream Output: stream of pairs consisting of a byte along with a count of the byte s consecutive occurrences. First step: model input Stream of bytes which can be viewed as zero or more runs. Each run consists of one or more bytes of the same value 8

9 JSP example: a run-length encoder Model output Zero or more pairs each pair consisting of a byte and its count JSP example: a run-length encoder Describe the correspondence between the input and the output 9

10 JSP example: a run-length encoder Merge the structures JSP example: a run-length encoder #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { int c; c = getchar(); while (c!= EOF) { int count = 1; int first_byte = c; c = getchar(); while (c!= EOF && c == first_byte && count < 255) { count++; c = getchar(); } putchar(first_byte); putchar(count); } } return EXIT_SUCCESS; 10