1. Design-Making Projects Work (Chapter7) n Large Projects u Design often distinct from analysis or coding u Project takes weeks, months or years to create u Teams of people involved u Too large to “get your head around” n Small Projects u Informal u Short time frame u Perhaps a single designer/coder u Design often done in front of keyboard

2. Design - Getting Large Projects to Work! n Identify major sub-systems and connections between them u partition the program into major components u define the interfaces between components u determine what data is passed between components u black box n Divide sub-systems into modules n Divide and conquer

3. Creating Routines/Components that Work! (Chapter 5) Cohesion: Creating components where the operations within a routine solve a single task. Cohesion: “The goal is to have each routine do one thing well and not do anything else.” Effective cohesion increases reliability

4. Acceptable Cohesion n Functional Cohesion u the strongest and best kind u occurs when a routine performs one and only one operation u pick names that describe what routines do n Sequential Cohesion u routine contains operations that must be performed in a specific order u routines that share data from step-to-step but don’t make a complete function when done together.

5. Acceptable Cohesion n Communicational Cohesion u occurs when opeerations in a routine make use of the same data and aren’t related in any other way u GetStudentIDForceRegister F practical but not ideal F there might be a better way to create a solution

6. Acceptable Cohesion n Temporal Cohesion u occurs when operations are combined into a routine because they are all done at the same time. F Startup u Can lead to poor code that is hard to maintain u valid if used to organize other routines F Routine that calls other routines which actually do the work

7. Coupling: The connections that bind routines together n Coupling is: u the strength of the connection between two routines u a complement to cohesion u how strongly a routine relates to other routines “The goal is to create routines with internal integrity and small, direct, visible, and flexible relations with other routines.” “Create routines that depend little on other routines.”

8. Loose Coupling: Types of connections matter n Size: “Small is beautiful!” u the fewer parameters the better n Intimacy: Kiss and Tell u direct/intimate connections are best u parameters are “better” than global variables n Visibility:Do it in the Open u make the connection obvious u parameters are “better” than changes to global variables

9. What is Good Code? What makes it Good?

10. Coding Style n Coding style is the patterns used by a programmer to express an action or outcome. n Good programming style can overcome many of the deficiencies of a primitive programming language (FORTRAN, COBOL, BASIC) n Poor style can defeat the intent of an excellent language

11. Coding Style The goal of good coding style is to provide easily understood, straightforward, elegant code.

12. DOs of good coding style n Use a few standard, agreed-upon control constructs n Introduce user-defined data types to model entities in the problem domain n Hide data structures n Isolate machine dependencies in a few routines

13. DOs of good coding style n Provide standard documentation prologues n Carefully examine routines having fewer than 5 or more than 25 executable statements n Use indentation, parentheses, blank spaces, blank lines and borders around comment blocks to enhance readability

14. Don'ts of good coding style n Don't be too clever n Avoid null Then statements n Don't nest too deeply n Avoid obscure side effects n Don't sub-optimize n Carefully examine routines have more than five formal parameters n Don't use an identifier for multiple purposes

15. Documentation Guidelines Computer software includes the source code for a system and all the supporting documents generated during analysis, design, implementation, testing, and maintenance of the system

16. Internal documentation Standard prologues for compilation units and subprograms, the self documenting aspects of the source code, and the internal comments embedded in the source code

17. Supporting Documents n Requirements specifications, design documents, test plans, user's manuals, installation instructions, and maintenance reports are examples of supporting documents n These documents are the products that result of systematic development and maintenance of computer software.

18. Supporting Documents n Supporting documents of substandard quality, that are not available when needed, are a strong indication of problems with the process being used to develop and maintain software. n Supporting documents should evolve as a natural by-product of the development process.

19. Supporting Documents n The quality, quantity, timeliness, and utility of the supporting documents are primary measures of the health and well being of a software project.

20. Commenting conventions: 1. Minimize the need for embedded comments by using u Standard prologues u Structured programming constructs u Good coding style u Descriptive names from the problem domain u Self documenting features such as data encapsulation

21. Commenting conventions: 2. Attach comments to blocks of code that: u Perform major data manipulations u Simulate structured control constructs using goto statements u Perform exception handling

22. Commenting conventions: 3. Use problem domain terminology in the comments 4. Use blank lines, borders, and indentation to highlight comments 5. Place comments to the far right to document changes and revisions

23. Commenting conventions: 6. Don't use long, involved comments to document obscure, complex code. Rewrite the code! 7. Always be sure that comments and code agree with each other, and with the requirements and design specifications