1 / 18

CSC 395 – Software Engineering

CSC 395 – Software Engineering. Lecture 21: Overview of the Term & What Goes in a Data Dictionary. In This Lecture. Review software engineering process so far One benefit of software engineering Problems that arise when developing software How software engineering tries to solve them

Download Presentation

CSC 395 – Software Engineering

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. CSC 395 –Software Engineering Lecture 21: Overview of the Term & What Goes in a Data Dictionary

  2. In This Lecture • Review software engineering process so far • One benefit of software engineering • Problems that arise when developing software • How software engineering tries to solve them • What this means for the data dictionary • Approaches that can help fix this • How to write documentation that might eventually help someone

  3. Eliminating Bugs is (NP-)Hard • Halting problem states we cannot develop system that proves if a program halts • Also cannot prove program free from bugs • People seem to like software that works • Also demand program be reliable & not crash • This ignores several other basic problems • Maintaining software years beyond creation • Average programmer’s… unique social skills

  4. Software Engineering • Task of developing software is impossible • And given last slide, we CANprove this • Most incapable of performing the impossible • Enable specialization & proficiency development • Software engineering includes the client • Clients/customers are only source of information • Starts with use-cases defining ACTUAL problem • Everything flows from these initial use-cases

  5. Faults != Good • (Software) Companies care about money • Not particularly interested in anything else • Will not discuss this point further(this is CSC395, not PHI395) • Companies act to improve their profitability • Faults take time to fix • Time == money • Bugs therefore take money to fix • Companies therefore care about faults

  6. Good Software Lifecycles • Then performs actions developing solution • None of these actions performed alone • Interlocking methods check & recheck results • Each new action begins by reproving result • Uses this check to take next step forward • Periodically recheck all of the results • Prevents building castles on sand • Exposes bugs early

  7. What Else Is There? Ambiguity equals

  8. Why Ambiguity? • Faults can be solved; ambiguity cannot • Literally, ambiguity created by lack of solutions • Once in existence, destroys everything it touches • Ambiguity also cannot be detected • Rather ironic if we could develop test, though • Software engineering creates laborious process to limit ambiguity • Unfortunately, nothing limit this work

  9. How SE Avoids Ambiguity • Insure all possible cases included • Develop scenario after scenario after scenario • Language is ambiguous • Develop entirely new, precise, language to use • Give each symbol & connection specific meaning • Require everything live up to this level of precision • Ambiguity can be created in translations • Require documentation of everything • Trace all ideas back to the original problem • Document everything at obscene levels

  10. Data Dictionary • Bad idea • Work in English again! • Worse idea • Leave documentation in programmer’s hand • Ugly idea • Make documentation main decider of code reuse • Good idea • Make $%&# certain documentation is perfect • Develop precise ways of describing code

  11. Details in Data Dictionary • Do not discuss implementation details • List what someone else needs to use this code • Describe class & methods in detail • What each can do, why each can do it, limits of where each is defined, & what each cannot do • Describe expected values for all parameters and what these values mean (use @param) • Describe what a result will be, why it will be that way, and what the result means (use @return) • Describe exceptional situations (use @throws)

  12. Details in Data Dictionary • Document important maintenance information • Associations on which class or method relies: what is associated are, why association exists, and importance of association • @see class @see #method @see class#method • Each of the class’ attributes (fields), value it holds, what value means, limits for which value defined • Algorithms to be used in implementation • Data structures on which it relies • Documentation hidden after design phase • Move from javadoc to inside module

  13. What About Ambiguity? • Previous documentation avoids errors • Does not prevent ambiguity from entering debate • Use three custom javadoc tags • Custom tags documented only when specified on command-line • Tags make assumptions explicit • If assumptions revisited, allows for proper fixes javadoc -tag pre:cm:“Preconditions:” -tag post:cm:“Postconditions:”–tag inv:cmt: “Invariants:”

  14. Assumptions & Restrictions • Precondition must be true at method start • Calling method responsible for ensuring met • Method only defined for these situations • Postcondition true when method completes • Called method responsible for guaranteeing this • Should consider what will happen when precondition not met • Enables programming-by-contract • Lack of implementation details improves reuse

  15. Pre & Post Silly Example /** * Compute & print out square root of a number. * * @param x Value whose square root we use * @pre x ≥ 0. System crashes when not met. * @post x1/2 printed out on System.err */public void printSquareRoot(int x) { System.err.println(“…”);}

  16. Invariants • Invariants define properties met at all times • Field values that are somehow linked • Range over which field is defined • Assumptions about how fields, parameters, or other values used • Listed using @inv tag • Normally included as part of class definition • In limited situations, could also include in method

  17. Why List Assumptions? Ambiguity equals

  18. Why List Assumptions? • Makes code-correctness proofs easier • Can feed to theorem provers to automate proof • Brings correctness proofs to nearly reasonable levels • Removes ambiguities during implementation • Clarifies responsibilities and actions in modules • Reduces need to understand code before use • Greatly reduces maintenance costs & improves reuse

More Related