1. CS48709-1/32 Illinois Institute of Technology CS487 Software Engineering Component Level Design & Design Documentation Instructor: David A. Lash

2. CS48709-2/32 Design Process Functional Design

3. CS48709-3/32 Component-level Design u Purpose: Translate the design model into operational software – Establishes the algorithmic detail of the design – Normally done by software engineer – Determines what the program will do before worrying about the details of the code. – Output is generally a graphic representation, table, text-based pseudo-code – Generally reviewed via design review

4. CS48709-4/32 Component-level Design - Structured Programming u Concepts formed in 1960s, by Dijkstra and others – Proposed a set of logical constructs from which any program can be formed. u Each construct have a “predictable logical structure”. (once identified can understand easier) – Sequence – Repetition – Condition u The idea has been to limit procedural design to a small number of constructs – enhance readability, testability and maintainability.

5. CS48709-5/32 Component-level Design - Structured Programming

6. CS48709-6/32 SP Constructs Use u Using the 3 only can be quite useful u Strict use of only the 3 constructs can lead to inefficiency and be awkward: – Sometimes escape from loop or nesting conditions use SP constructs only can become awkward. u Either redesign or allow an “escape branch”

7. CS48709-7/32 Program Design Language (Pseudocode) u Original developed as a design tool for assembler language programmers. u As a design tool today it is not often used because of high-level and middle-level language. u Works well in teaching. – Showing logical coding fragments. u Analysis is an iterative process that requires some design. Pseudocode provides a view of what is required.

8. CS48709-8/32 Pseudocode Characteristics u Can use any language syntax. i.e. Ada or C u Characteristics for a design language – Fixed syntax of keywords with structured constructs – Free syntax describing processing features – Data declaration facilities (scalar and complex) – Subprogram definition and calling conventions

9. CS48709-9/32 Pseudocode Examples PROCEDURE security.monitor; INTERFACE RETURNS system.status; keywords Interface declaration Statement Termination

10. CS48709-10/32 Pseudocode Example (data declaration) TYPE signal IS STRUCTURE DEFINED; name IS STRING LENGTH VAR; address IS HEX device location; bound.value IS upper bound SCALAR; message IS STRING LENGTH VAR; END signal TYPE; Structure or record declaration

11. CS48709-11/32 Pseudocode (Commands and Instruction) Initialize all system ports and reset all hardware; CASE OF control.panel.switches (cps); WHEN cps = “test” SELECT CALL alarm PROCEDURE WITH “on” for test.time in seconds; Procedure Statement Case Statement

12. CS48709-12/32 More Pseudocode REPEAT UNTIL activate.switch is turn off reset all signal.values and switches; DO FOR alarm.type = smoke, fire, water, burglar; READ address[alarm.type] signal.value; IF signal.value > bound[alarm.type]; THEN phone.message = message[alarm.type]; set alarm.bell to “on” for alarm.seconds; PARBEGIN, PAREND ENDIT ENDFOR ENDREP Loop Construct Decision Statement

13. CS48709-13/32 Design Process Write Document

14. CS48709-14/32 Design Documentation Detail u IEEE/ANSI Std1016 Recommended Practice for Software Design Descriptions – Defines elements necessary for functional design – Provides suggested organizational concepts

15. CS48709-15/32 Functional Design: Recommended Practices u Key Concepts: – Design entity - An element of a design that is structurally and functionally distinct from other elements and that is separately named and referenced – Some Sample Design Entities: u a component Level module - processing, function, u an architectural layer - design restrictions and limitations u The global and local data structures - data type restrictions, bounding values, memory usage limitations

16. CS48709-16/32 Functional Design: Recommended Practices u Key Concepts: – Entity attribute - A named characteristic or property of a design entity. It provides a statement of fact about the entity u Its identify, type, purpose, function, etc

17. CS48709-17/32 Functional Design: Entity Attributes u Design Entity Attributes – Identification - The name of the entity – Type - A description of the kind of entity, u i.e. function, process, data store, interface, etc. – Purpose - A description of why the entity exists – Function - A statement of what the entity does

18. CS48709-18/32 Functional Design: Entity Attributes u More Design Entity Attributes – Processing - description of the processing of each module u that is, the tasks, decisions, and I/O u the rules used by the entity to achieve its function – Data - A description of data elements internal to the entity (major structures in design) – Interface for each entity - A description of how other entities interact with this entity u that is, internal module, external system and human/computer description

19. CS48709-19/32 Functional Design - Entity Attributes u More Design Entity Attributes – Subordinates - The identification of all entities composing this entity – Dependencies - A description of the relationships of this entity with other entities – Resources - A description of the elements used by the entity that are external to the design. i.e. printers, scanners, software services, etc.

20. CS48709-20/32 Narratives to Attributes u Single words – Identification – Type u Narrative – Purpose (One sentence) – Function (One or two paragraphs) – Processing u Lists – Data (major internal structures) – Resources

21. CS48709-21/32 Relating Diagrams to Attributes u E/R Diagram – Dependencies (data) - A description of the relationships of this entity with other entities – Subordinates (data) - The identification of all entities composing this entity u Data Flow Diagram – Processing - A description of the rules used by the entity to achieve its function – Dependencies – Interfaces - A description of how other entities interact with this entity

22. CS48709-22/32 Relating Diagrams to Attributes u State Diagram – Processing - A description of the rules used by the entity to achieve its function – Dependencies u Structure Chart – Subordinates - The identification of all entities composing this entity – Dependencies - A description of the relationships of this entity with other entities – Interface - A description of how other entities interact with this entity

23. CS48709-23/32 Design Process Write Document

24. CS48709-24/32 Methods of Organizing the Design Document u Design View – A subset of design entity attributes information that is specifically suited to the needs of a software project activity.

25. CS48709-25/32 IEEE Suggested View

26. CS48709-26/32 IEEE Suggested View

27. CS48709-27/32 A modern View Architectural diagram

28. CS48709-28/32 Design Process Review

29. CS48709-29/32 Design Specification Review Checklist u General Review issues – Are diagrams clear? u Are they labeled correctly? u Is there enough supporting detail to make them clear? – Is the language clear? u Was active voice used? u Written in the present tense? – Is the behavior consistent with process? – Do inconsistencies and omission exist?

30. CS48709-30/32 Design Specification Review Checklist u Design Specification Review issues: – Are all functions referenced to the requirements specification? – Are the requirement constraints met? – Are the interfaces complete? – Are the interface broader than necessary? – Does each entity achieve its purpose? – What is the cohesion and if not functional then why? – What is the coupling and if not data then why?

31. CS48709-31/32 Design Specification Review Checklist u Suggestion – Document some hypothetical test cases and use then to exercise the design

32. CS48709-32/32 Design Methodologies u What is a design methodology? – A collection of rules and procedures that govern how the analysis and design process proceeds u The myth – A magical solution that resolves all of the problems with software development u The reality – Software design is hard work and there are no magic solutions; just the application of sound principals.