Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

Similar presentations

Presentation on theme: "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"— Presentation transcript:

1 1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

2 CS42713-2 Midterm exam zYour opinion? yHard/easy? Long/short? Surprising/not? yReading books is important yDid you like format of questions? T/F? zGrades will be on Wiki by Friday, Oct 13 yIf you have questions, please let us know yIf you think we erred, please let us know

3 CS42713-3 Project groups zOnly groups 8 and 27 have 8 students so far y8 students is ideal; it may be 7 or 9 at the end zProject fair y5pm on Friday, Oct 13, room TBA (Wiki) yYou should come if xYou’re a representative of a group with <8 students xYou’re still looking for a group yEach representative will give a brief presentation yHW2 (due Oct 24) asks for details of your project

4 CS42713-4 Project grading zYou are graded on how well you follow your process (you decide XP or RUP) yYou must know it yYou must follow it yYou must prove you follow it zMake a log of what you do every day zProject is 35% of grade yHWs help you to make progress on the project

5 CS42713-5 Classic software engineering phases zPut them in correct order: code, design, maintenance, requirements, specification, test [ME: almost all correct answers] zWe covered requirements and some design zToday: specifications (specs) zDo customers and users need to understand requirements (or specs)? [ME: many wrong]

6 CS42713-6 Why phases? zBreak big job into smaller steps yLet people specialize yProvide check-points yProvide early feedback yProvide multiple views

7 CS42713-7 Other forms of decomposition zModules/components yFor each module, follow req-spec-design- code-test cycle zFeatures yFor each feature, follow req-spec-design- code-test cycle

8 CS42713-8 Specification zDefine system as a set of data items and operations on that data zSpecification is set of properties of data and operations zExample: bank balance is never negative zFormal spec: “forall a: Account. a.balance ≥ 0”

9 CS42713-9 Notations zEnglish yEasy to read yHard to analyze zProgramming language yEasy for programmers to read yOften not powerful enough zSpecial (formal) specification languages yWe don’t teach much on this topic in CS427

10 CS42713-10 Why formal languages? zCan describe many artifacts (specs, designs, requirements) [ME: many correct answers] yDocumentation (precise, unambiguous) yEnables (automatic!) machine reasoning zInformal: “everybody likes a winner”? 1)exists w: Winner. exists p: Person. p.likes(w) 2)exists w: Winner. all p: Person. p.likes(w) 3)all p: Person. exists w: Winner. p.likes(w) 4)all p: Person. all w: Winner. p.likes(w)

11 CS42713-11 Credit card zA credit card has a balance that is the sum of all charges minus the sum of all payments. If the balance is not paid within 20 days of billing, 1% of the unpaid balance is charged as interest. Each credit card has a particular day on which it is billed each month. Customers cannot charge if the charge would put balance over the limit. [Data and operations?]

12 CS42713-12 Data and operations zCredit card has ybalance ylimit ybilling day zOperations on credit card ypay(amount) ycharge(amount)

13 CS42713-13 Properties of operations zCan’t say balance equals sum of all charges minus sum of all payments due to interest yInvariant: what holds in all states zCan say “ = c.balance - a” yPostcondition: what operation establishes zCan say “if c.balance + a < c.limit then c.charge(a).balance = c.balance + a” yPrecondition: what operation assumes

14 CS42713-14 Question not on ME zConsider binarySearch(int[] a, int v) method zInput: array and a value to search for zOutput: position of value in the array zUses binary search zWhat should be precondition? ya is sortedT/F ya is not nullT/F

15 CS42713-15 Extending operations z“If the balance is not paid within 20 days of billing, 1% of the unpaid balance is charged as interest.”

16 CS42713-16 First approach zAdd “unpaid balance” to a credit card zunpaidBalance = balance on billing date zpayments get subtracted from unpaidBalance z20 days after billing, compute interest and charge it

17 CS42713-17 Second approach zAdd date to payments and charges zOperations on credit card ypay(amount, date) ycharge(amount, date) zCredit card has ybalance, limit, billing day yset of payments yset of charges

18 CS42713-18 Second approach For each credit card balance(date) = (sum a for d<=date of charges(a,d)) – (sum a for d<=date of payments(a,d)) There is a c in charges(a, billingDate + 20) where c.balance(billingDate) – sum a for d<=date of charges(a, d)

19 CS42713-19 Comparison zFirst approach yMore like programming yMore standard notation yLonger specs zSecond approach yShorter, more abstract, easier to reason about yMore to learn zPersonal experience: Java vs. Alloy

20 CS42713-20 Design and specification zSpecification needs to know data zSpecification needs to be structured zMust design module interfaces zSpecification is usually the design of the “entities”

21 CS42713-21 Executable specifications (1) zSome very high-level programming languages can be used to write specs yProlog (Hamlet and Maybee, you don’t need details) yLisp ySmalltalk yMaude (several courses on formal methods)

22 CS42713-22 Executable specifications (2) zWrite and test specification zRewrite in efficient language zWrite and test specification zRewrite to be more efficient

23 CS42713-23 Story about Ada zAda - language invented by military project around 1980 zSpecification, verification suite zFirst Ada compiler written in SetL y“Set Language” zSlow, but tested spec and verification suite zMoral: executable specifications are useful

24 CS42713-24 Story about concurrency zSystem for downloading data from cash registers (Prof. Johnson’s experience) zFrequent deadlock zAfter fourth attempt, developed formal specification and derived a design zMoral: formal techniques can solve hard problems zAutomated analysis: model checking

25 CS42713-25 Conclusion zSpecifications can be yInformal or formal yFor entire system or just a small part yExecutable or non-executable zYou must decide what you need yVery common in software engineering yMany things are vague and ambiguous yAdvice: use your experience (get some in CS427)

26 CS42713-26 Next time zRead chapter 10 of Hamlet and Maybee yBe familiar with the controversy yDon’t need to learn details of Prolog

Download ppt "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"

Similar presentations

Ads by Google