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 What this means for the data dictionary Approaches that can help fix this How to write documentation that might eventually help someone

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

Software Engineering Task of developing software is impossible And given last slide, we CAN prove 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

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

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

What Else Is There? Ambiguity equals

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

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

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

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 Describe what a result will be, why it will be that way, and what the result means Describe exceptional situations

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 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

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:”

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

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

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 tag Normally included as part of class definition In limited situations, could also include in method

Why List Assumptions? Ambiguity equals

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