1. 1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 10 – Classes and operations Dr Richard Clayton & Dr Marian Gheorghe Module (1 st part) homepage http://www.dcs.shef.ac.uk/~marian

2. 2COM6030 Systems Analysis and Design © University of Sheffield 2005 Outline  Classes with attributes and operations; types.  ATM classes – attributes and operations with types.  Operation specification; pre- and post- conditions.  Dynamic behaviour.  Requirements analysis - a survey. Stevens & Pooley chapter 6; Bennett et al. chapter 10

3. 3COM6030 Systems Analysis and Design © University of Sheffield 2005 A class example A class consists of: name – Clock; attributes and their types (not considered so far) - time ; operations with returning values and formal parameters (not considered so far) – reportTime(), resetTimeTo(). Clock time: Time reportTime(): Time resetTimeTO(newTime: Time) Class name (upper) Attribute (lower) Operations (lower) Type Value returned Formal parameter (argument)

4. 4COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Card class Card cardNo bankAccount pin dayLimit validatePIN() changePIN() startWidraw() i) checking that the amount requested is within dayLimit range; ii) checks with BankAccount that there is enough in the current bank account or the overdraft limit is sufficient for this transaction; iii) it also checks that there is enough cash in dispenser; if all these are fulfilled it updates daylimit, asks BankAccount to update balance and Dispenser to release the cash; it asks Transaction to record the transaction – it uses recordTransaction(). Card class’ attributes and operations: validatePIN() validates the PIN introduced against the value in pin ; checks bank account; changePIN() changes the current pin value with what this operation provides; startWithdraw() initiates the withdrawal by

5. 5COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Card class & types Card cardNo: Integer bankAccount: BankAccount pin: Integer dayLimit: Integer validatePIN(newPin: Integer): Boolean changePIN(newPin: Integer) startWidraw(amount: Integer): Boolean BankAccount that there is enough in the current bank account or the overdraft limit is sufficient for this transaction; iii) it also checks that there is enough cash in dispenser; if all these are fulfilled it updates daylimit, asks BankAccount to update balance and Dispenser to release the cash and returns true ; otherwise returns false ; it asks Transaction to record the transaction – it uses recordTransaction(). Card class’ attributes and operations: validatePIN() validates the PIN introduced, newPin, against the value in pin ; checks bank account; returns either true or false ; changePIN() changes the current pin value with what this operation provides, newPin ; startWithdraw() initiates the withdrawal by i) checking that the amount requested is within dayLimit range; ii) checks with

6. 6COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – BankAccount class BankAccount accountNo balance overdraft getBalance() checkWithdrawal() updateBalance() BankAccount class: getBalance() provides the current balance; checkWithdrawal() checks the amount requested is within balance range and does not exceed the overdraft limit; updateBalance() changes the current balance (and maybe the overdraft limit) value(s) according to the amount taken out from the account.

7. 7COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – BankAccount class & types BankAccount accountNo: Integer balance: Money overdraft: Integer getBalance(): Money checkWithdrawal (amount:Integer):Boolean updateBalance (amount: Integer) BankAccount class: getBalance() provides the current balance; checkWithdrawal() checks the amount requested is within balance range and does not exceed the overdraft limit; it returns true if both conditions are true and false otherwise; updateBalance() changes the current balance (and maybe the overdraft limit) value(s) according to the amount taken out from the account.

8. 8COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Dispenser class Dispenser cash checkCash() widrawCash() Dispenser has an attribute cash with the current available cash; it checks that a given request coming through checkCash() may be withdrawn (is less than cash value); withdrawCash() updates the current cash value by taking out the amount to be withdrawn.

9. 9COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Dispenser class & types Dispenser cash: Integer checkCash(amount: Integer): Boolean widrawCash(amount: Integer) Dispenser has an attribute cash with the current available cash; it checks that a given request, amount coming through checkCash() may be withdrawn (is less than cash value); if this is fulfilled then it returns true otherwise false ; withdrawCash() updates the current cash value by taking out the amount to be withdrawn.

10. 10COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Transaction class Transaction date cardNo accountNo status recordTransaction() Transaction keeps for every transaction the date, the card number and the account details as well as the status, either failed or successful –will use bool; It uses recordTransaction() to store suitable values according to the attributes described.

11. 11COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Transaction class & types Transaction date: Date cardNo: Integer accountNo: Integer status: Boolean recordTransaction(d: Date, cNo: Integer, accNo: Integer, st: Boolean) Transaction keeps for every transaction the date, the card number and the account details as well as the status, either failed or successful –will use bool; It uses recordTransaction() to store d, cNo, accNo, st, into date, cardNo, accountNo, status, respectively.

12. 12COM6030 Systems Analysis and Design © University of Sheffield 2005 Operation specification  Pre- and post- conditions (analysis). Specify an operation by defining conditions that  must be satisfied before an operation can take place;  apply after an operation is completed. The general syntax is Class::operation(parameter1:type1,…): return type pre:conditions post:conditions Example. max returns the maximum value of two integers, a and b : C::max(a:Integer, b:Integer): return Integer pre:C exists; a and b are integers post:if a >= b then max = a else max = b  Algorithmic approach – pseudo-code, activity diagrams (design).

13. 13COM6030 Systems Analysis and Design © University of Sheffield 2005 Object Constraint Language  OCL introduced to formally, unambiguously, and easily specify constraints in UML.  It relies a set of arithmetic ( +, -, *, / ), relational (, >=, <> ), logical ( and, or, not, implies, if, then, else ) operators.  Dot (. ) operator is used to specify the context of an entity.  The operation specified must have arguments and types associated with.  Conditions are formed with operators (see above) and operands (attributes, arguments).  Don’t follow a very strict OCL syntax – a constraint in clear English is much more useful than a constraint in a formal language that is buggy (Stevenson, Pooley p.84)

14. 14COM6030 Systems Analysis and Design © University of Sheffield 2005 Operation specification - Examples changePIN() changes the current pin value with what this operation provides, newPin. Card::changePIN(newPin:Integer) pre:Card exists post:pin = newPin updateBalance() changes the current balance (and maybe the overdraft limit) value(s) according to the amount taken out from the account. BankAccount::updateBalance(amount:Integer) pre:BankAccount exists; balance+overdraft >= amount post:if balance >= amount then balance = balance – amount else overdraft = overdraft –(amount – balance) balance = 0 Dispenser checks that a given request, amount coming through checkCash() may be withdrawn (is less than cash value); if this is fulfilled then it returns true otherwise false. Dispenser::checkCash(amount:Integer): return Integer pre:Dispenser exists post:if amount <= cash then return true else return false

15. 15COM6030 Systems Analysis and Design © University of Sheffield 2005 Operation specification - Example startWithdraw() initiates the withdrawal by i) checking that the amount requested is within dayLimit range; ii) checks with BankAccount that there is enough in the current bank account or the overdraft limit is sufficient for this transaction; iii) it also checks that there is enough cash in dispenser; if all these are fulfilled it updates daylimit, asks BankAccount to update balance and Dispenser to release the cash and returns true ; otherwise returns false ; it asks Transaction to record the transaction – it uses recordTransaction(). Card::startWithdrawal(amount:Integer) pre:Card, BankAccount, Dispenser, Transaction exist post:if amount <= dayLimit and amount <= BankAccount.balance + BankAccount.overdraft and amount <= Dispenser.cash then dayLimit = dayLimit – amount BankAccount.updateBalance(amount) * Dispenser.withdrawCash(amount) * Transaction.recordTransaction(currentDate, cardNo, BankAccount.accountNo, true) * else Transaction.recordTransaction(currentDate, cardNo, BankAccount.accountNo, false) * Note. Conditions * may be explicitly written.

16. 16COM6030 Systems Analysis and Design © University of Sheffield 2005 Dynamic behaviour  Class diagrams represent static/structural description of class content and interactions.  An object will react to messages – it shows a dynamic behaviour; objects are instantiated and destroyed. idle validatePIN() state transition points to the initial state

17. 17COM6030 Systems Analysis and Design © University of Sheffield 2005 Dynamic behaviour - Examples A Card object. idle validatePIN() PIN validated changePIN() startWithdrawal() A BankAccount object. positive balancenegative balance getBalance() checkWithdrawal() [amount<=balance] updateBalance() [amount>balance & amount<=balance+overdraft] updateBalance() checkWithdrawal() getBalance() Show overdraft=0 !

18. 18COM6030 Systems Analysis and Design © University of Sheffield 2005 Requirements - recap  Requirements analysis and specification  requirements capture;  systems analysis.  Requirements capture  fact finding;  select requirements;  resolve conflicts  final requirements document (plain English).  Systems analysis  user-oriented: actors and use cases;  object-oriented: classes and relationships between them.  User-oriented analysis  identify actors and main use cases; subsystems; use case descriptions;  >, >, generalisation relationships - further iterations.

19. 19COM6030 Systems Analysis and Design © University of Sheffield 2005 Requirements - recap  Object-oriented analysis  Identifying objects (nouns, CRC cards)  Classes (from CRC cards) attributes; operations; associations (including directions, multiplicities).  Class diagrams  Operation specification pre- and post-conditions; pseudo-code, activity diagrams. Object business layer should be associated with an interface specification

20. 20COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary  Types in attribute and operation specification.  Case study on types.  Operation specification: pre- and post-conditions.  Object dynamic behaviour.  Requirements analysis recap.