1 / 12

Contents

Requirements. Analysis. Specification. Require- ments. Planning. Design. Coding. Testing. Installation. Operation and Maintenance. Contents. Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance.

ave
Download Presentation

Contents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Detailed Design Activities Give sufficient information, so that the implementation teams can do a good job. • Choose specific data structures and algorithms • Refine the components from architectural design • Define HOW • Comments are NOT enough: 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 *) bella@cs.umu.se

  3. Open Questions • What are the word delimiters? • blank, EOL, EOF, TAB • `.´, `,´, `;´, `:´, ...`_´, `&´, ... • Is the matching case sensitive? • Must replacements have the same length? • How to solve conflicts? • Several different replacements for the same old word • Some words in newWords appear also in oldWords • Assume the following: text: ... ABC ...;oldWords: AB, BC; newWords: X, Y alternative1: ... XC ... alternative2: ... AY ... bella@cs.umu.se

  4. Approaches to Detailed Design • Informal • Structured English • Semi-formal • Program Design Languages (PDLs) • Diagrammatical techniques • Formal • Formal Specifications (e.g. Z, VDM, ...) • Pre-/postconditions & invariants (sometimes called programming by contracting) bella@cs.umu.se

  5. 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) returninteger; (* 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] bella@cs.umu.se

  6. 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 bella@cs.umu.se

  7. Programming Style ... • Remember that programs are for people to read • Always choose the simpler alternative • Reject clever code that is hard to understand • Shorter code is not necessarily better • Choose good names • Make them highly descriptive • Do not worry about using long names bella@cs.umu.se

  8. Programming Style … • Comment extensively • Comment whatever is non-obvious • Do not comment the obvious • Comments should be 25-50% of the code • Organize class elements consistently • Variables, constructors, public methods then private methods • Be consistent regarding layout of code bella@cs.umu.se

  9. Programming Style … • Avoid duplication of code • Do 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 bella@cs.umu.se

  10. 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 • Interact with the user in separate classes • This makes non-UI classes more reusable • Avoid pointers to pointers • Commit to effective naming conventions bella@cs.umu.se

  11. Coding Standards • Java coding standards: • The Elements of Java Style; Vermeulen et.al. SIGS Books. • http://java.sun.com/docs/codeconv/html/CodeConvTOC.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 bella@cs.umu.se

  12. 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 bella@cs.umu.se

More Related