Illinois Institute of Technology

1
Illinois Institute of Technology

• CS487
• Software Engineering
• Implementation I
• Mr. David Lash

2
Linear Sequential Model
3
Unit Implementation Process
4
Detail Design

• Source design entity description
• Purpose
• Function
• Interface
• Data
• Processing
• Output
• Document (?)
• Comments for source code

5
Coding

• Purpose
• Translate design to machine readable format
• Input Detail Design
• Envelope
• Comments
• Output
• Source code
• Test harness (driver and data)

6
Coding Issues

• Functionality
• Does the software satisfy its purpose.
• Readability
• The ease with which a reader can determine the
  function of a function
• Maintainability
• The ease with which maintenance of a function can
  be performed in accordance with prescribed
  requirements iso

7
Structured Coding

• Avoid variable functions
• C - function pointers
• Cobol - alter
• Basic - goto depending on integer
• Assembler - routing vectors
• Make logic as linear as possible
• Limit the use of goto type instructions

8
Example C

• bool exitswfalse
• for (int i 0 i lt n i)
• for (int j 0 j lt m j)
• if (condition)
• exitsw true
• break
• if (exitsw) break

• for (int i 0 i lt n i)
• for (int j 0 j lt m j)
• if (condition)
• goto badexit
• return 0
• badexit
• return 1

9
Example Java

• Method 1
• public class Count
• public static void
• main(String args)
• for (int i1 ilt10 i)
• system.out.println(i)

• Method 2
• public class Count public static void
  main(String args) for(int i1ilt10i)
  system.out.println(i)

10
Program Documentation

• Program Header contains
• Module name
• Owner
• Purpose/Requirements
• Table of contents
• Function name
• Description
• Maintenance Log contains
• Date maintained
• Author
• Explanation of activity

11
Program Documentation

• Function Header Contains
• Function
• Inputs/Outputs/Returns
• Process

12
PSP Coding Standard

• Program Headers
• Begin all programs with a descriptive header
• //
• // Program Name
• File name of the program.
• // Requirements
• a short description what the program is required
  to do.
• // Description
• a short description of the program function.
• // Assumptions
• a list of the assumptions made to develop the
  module.
• //

13
PSP Coding Standard

• Listing Contents
• Provide a summary of the listing contents
  immediately after the program header
• //
• // Listing Contents
• // Reuse instructions
• // Modification instructions
• // Compilation instructions
• // Includes
• // Class declarations
• // CData
• // Aset

14
PSP Coding Standard

• // Source code in c\classes\CData.cpp
• // CData
• // CData()
• // Empty()
• //

15
PSP Coding Standard

• Reuse Instructions
• Describe how the program is used. Provide the
  declaration format, parameter values and types,
  and parameter limits.
• Provide warnings of illegal values, overflow
  conditions, or other conditions that could
  potentially result in improper operation

16
PSP Coding Standard

• //
• // Reuse Instructions
• // int PrintLine(char line_of_character)
• // Purpose
• // to print string, 'line_of_character', on
  one print line
• // Limitations
• // the maximum line length is LINE_LENGTH
• // Return
• // 0 if printer not ready to print, else 1
• //

17
PSP Coding Standard

• Identifiers
• Use descriptive names for all variables, function
  names, constants, and other identifiers.
• Avoid abbreviations or single-letter variables.
  However, when doing mathematical algorithms such
  as a summation, single-letter variable names are
  acceptable. Not using single-letter variables may
  actually make it more difficult to understand the
  algorithm being implemented.

18
PSP Coding Standard

• int number_of_students // This is GOOD
• float x4, j, ftave // These are BAD
• for (int i 1 i lt n i) //

19
PSP Coding Standard

• Comments
• Document the code so that the reader can
  understand its operation
• Comments should explain both the purpose and
  behavior of the code
• Unless the instruction usage is obscure, dont
  explain the operation of the instruction
• Comment variable declarations to indicate their
  purpose
• Except for variable declarations, line comments
  are discouraged. Use a comment that relates to
  the process definition.

20
PSP Coding Standard

• Good Comment
• //Step5 When all records are processed
• // then do the summary process
• if (record_count gt limit)
• Bad Comment
• if (record_count gt limit) // have all
  the records been processed?
• if (record_count gt limit) // check if
  record_count greater than limit

21
PSP Coding Standard

• Blank space
• Write programs with sufficient spacing so that
  they do not appear crowded.
• Separate every program construct with at least
  one space.
• Indentation
• Indent every level of brace from the previous
  one.
• Open and close braces should be on lines by
  themselves and aligned with each other.

22
PSP Coding Standard

• Capitalization
• Capitalize all defines
• Lowercase all other identifiers and reserved
  words
• Messages being output to the user can be
  mixed-case so as to make a clean user
  presentation
• Example
• define DEFAULT_NUMBER_OF_STUDENTS 15
• int class_size DEFAULT_NUMBER_OF_STUDENTS

23
Compiling

• Verification of coding process to the rules of
  the compiler (platform)
• Are all the variables defined?
• Is the syntax correct?
• Input
• Header Files
• Source Code
• Output
• Object module (?)

24
Unit Testing

• Verification of the detail design
• Unit testing is looking at the internal nature
  of the module/class under test.
• Uses white-box testing.
• Can use black-box testing.
• Done by developer. Some organizations use tester
  to develop driver and test cases

25
Unit Testing

• Input
• Source Code
• Process
• White-box tests
• Output
• Defects (?)
• Test report

26
Why Unit Test?

• Required because of the law of compound
  probability (product law)

• Example
• Given three modules in a function, that have 90
  of their defects are removed, what is the
  probability that the process will function
  correctly?

27
How do you Unit Test?

• Debuggers (instruction step)
• Test harnesses - drivers and stubs (A special
  program designed to test a specific module)
• Case tools
• Static Analyzers
• Dynamic Analyzers
• Profilers

28
Implementation Reviews
29
Code Reviews

• Where code reviews are placed during
  implementation depends on the software being
  built and the environment in which it is built.
• Life critical applications
• After every step
• Expensive target environment
• Before unit test
• In general, after unit test

30
Code Reviews

• Review Guidelines
• Check to ensure you design all the required
  program elements
• Verify the overall program structure and flow
• Check the programs logical constructs for
  correctness
• After you are reasonably sure the logic performs
  properly under normal conditions
• Check the function, method and procedure calls to
  ensure all the correct parameters and type are
  specified and each function is properly used
• Check all the special variables, parameters, data
  types and files

31
C Code Review Checklist
32
C Code Review Checklist
33
C Code Review Checklist
34
C Code Review Checklist
35
C Code Review Checklist
36
C Code Review Checklist