1. PVK-HT03bella@cs.umu.se1 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Analysis Design Testing Coding Operation and Maintenance Installation Require- ments Requirements Specification Planning

2. PVK-HT03bella@cs.umu.se2 Detailed Design Activities Choose specific data structures and algorithms Refine the components from architectural design Define HOW Comments are NOT enough: Give sufficient information, so that the implementation teams can do a good job. procedure replaceText( var text: TextFile; oldWords, newWords: WordList); (* Replace in the text text all occurrences of the i-th word in oldWords by *) (* the i-th word in newWords ; oldWords and newWords must have the same*) (* length*)

3. PVK-HT03bella@cs.umu.se3 Open Questions What are the word delimiters? oblank, EOL, EOF, TAB o`.´, `,´, `;´, `:´,...`_´, `&´,... Is the matching case sensitive? Must replacements have the same length? How to solve conflicts? oSeveral different replacements for the same old word oSome words in newWords appear also in oldWords oAssume the following: text :... ABC... ; oldWords: AB, BC ;newWords: X, Y alternative1:... XC... alternative2:... AY...

4. PVK-HT03bella@cs.umu.se4 Approaches to Detailed Design Informal oStructured English Semi-formal oProgram Design Languages (PDLs) oDiagrammatical techniques Formal oFormal Specifications (e.g. Z, VDM,...) oPre-/postconditions & invariants (sometimes called programming by contracting)

5. PVK-HT03bella@cs.umu.se5 Programming by Contracting Clients and servers of services “sign” contracts, i.e. servers guarantee the effects of their services offered, if and only if clients use these services correctly. function getPosition( a: array of Element; el: Element) return integer ; (* Returns the relative position of el in a *) precondition  i  [a`First..a`Last]: a[i] = el (* such an element exists *) postcondition a[getPosition( a, el)] = el and a = a.old (* getPosition really returns the position of el in a and a is unchanged *) You could even specify that the array must be sorted in ascending order to allow for a faster algorithm by adding the following to the precondition: and  i,j  [a`First..a`Last]: i < j  a[i] < a[j]

6. PVK-HT03bella@cs.umu.se6 Implementation Transform the detailed design into concrete programming language code Ensure that this code correctly implements the detailed design OOPS! Many modern programming languages contain detailed design elements, e.g. Eiffel

7. PVK-HT03bella@cs.umu.se7 Programming Style... Remember that programs are for people to read oAlways choose the simpler alternative oReject clever code that is hard to understand oShorter code is not necessarily better Choose good names oMake them highly descriptive oDo not worry about using long names

8. PVK-HT03bella@cs.umu.se8 Programming Style … Comment extensively oComment whatever is non-obvious oDo not comment the obvious oComments should be 25-50% of the code Organize class elements consistently oVariables, constructors, public methods then private methods Be consistent regarding layout of code

9. PVK-HT03bella@cs.umu.se9 Programming Style … Avoid duplication of code oDo not ‘clone’ if possible Create a new method and call it Cloning results in two copies that may both have bugs –When one copy of the bug is fixed, the other may be forgotten

10. PVK-HT03bella@cs.umu.se10 Programming Guidelines Use separate files for each module, class, macro, inline,... definition Use separate files for the definition/specification and implementation when possible Call operations only when all preconditions are satisfied (this is the caller´s responsibility) Do not mix user interface code with non-user interface code oInteract with the user in separate classes This makes non-UI classes more reusable Avoid pointers to pointers Commit to effective naming conventions

11. PVK-HT03bella@cs.umu.se11 Coding Standards Java coding standards: oThe Elements of Java Style; Vermeulen et.al. SIGS Books. ohttp://java.sun.com/docs/codeconv/html/CodeCon vTOC.doc.html Smalltalk Best Practice Patterns by Kent Beck Recommended C Style and Coding Standards by David Keppel C Programming Guidelines by Thomas Plum Ada Quality and Style: Guidelines for Professional Programmers by Software Product Consort

12. PVK-HT03bella@cs.umu.se12 What is a Good Low Level Module? Black box aspects: Fulfilled functionality Fulfilled characteristics Easy to use Integratable Reusable Testable Traceable White Box Aspects: Deductable Understandable Modifiable