1. 1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 9 – More on objects and classes 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  Class model.  Association, aggregation, composition, generalisation.  Class diagram.  Case studies: ATM, Advertising company.  Class attributes and operations. Stevens & Pooley chapters 2, 3, 5; Bennett et al. chapter 7

3. 3COM6030 Systems Analysis and Design © University of Sheffield 2005 First part of the course Remember objects and classes An object is a thing you can interact with:  It receives and reacts to messages.  It behaves in a certain way according to its internal state which may change.  It interacts with other objects, normally by using their names – identity of an object. (Booch) A class describes a set of objects with an equivalent role.  Every object belongs to a class ( myClock object belongs to – or is inherited from - the class Clock ); classes are object factories.  A class will have a name, optionally some attributes and may provide specific operations.

4. 4COM6030 Systems Analysis and Design © University of Sheffield 2005 A simple class Systems analysis: user-oriented: actors and use cases; object-oriented: classes and relationships between them. Clock time: Time reportTime(): Time resetTimeTO(newTime: Time) Class name Attribute Operations Type Value returned Formal parameter (argument) Class identification: noun identification; responsibility driven approach (CRC cards).

5. 5COM6030 Systems Analysis and Design © University of Sheffield 2005 Class model  Consists of classes (with their attributes and operations) and their relationships.  Formally these models are represented by class diagrams. Some class symbols: Dog Bonzo: Dog {abstract} Animal Module name: String noOfStudents:int timetable:Timetable getStudents() listLectures() Module Class symbols Abstract class symbol Object symbols Class with attributes and operations Com6030:Module

6. 6COM6030 Systems Analysis and Design © University of Sheffield 2005 Associations  An association may be considered conceptually or from an implementation point of view:  if there is a real-world association (described by a sentence relevant to the system: a library member borrows a book; a module is taken by a student);  classes A and B are associated if: an object of class A sends a message to an object of class B; an object of class A creates an object of class B; an object of class A has an attribute whose values are objects of class B or collections of objects of class B; an object of class A receives a message with an object of class B as an argument.  Associations are defined by verbs and CRD cards collaborations identify them.

7. 7COM6030 Systems Analysis and Design © University of Sheffield 2005 Remember CRC cards relationships – ATM system Card ResponsibilitiesCollaborations Transaction ResponsibilitiesCollaborations BankAccount ResponsibilitiesCollaborations Dispenser ResponsibilitiesCollaborations

8. 8COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM system - class diagram Card BankAccountDispenserTransaction refers to dispenses registers Class diagrams is obtained directly from CRC cards by considering collaborations identified; it shows business classes. Classes are shown with no attributes and operations. Exercise. Draw up the class diagram for the Advertising company.

9. 9COM6030 Systems Analysis and Design © University of Sheffield 2005 Refining associations StudentTutor Association - undirected or bidirectional structural relationship. StudentUniversity Association – directed structural relationship; students associated with university. CampaignAdvert Aggregation – whole/part structural association. ChessBoardSquare Composition – whole/part exclusive association. Composition is a stronger version of aggregation. In composition each part lives and dies with the whole

10. 10COM6030 Systems Analysis and Design © University of Sheffield 2005 Refining associations DegreeModule Association - with end roles and multiplicities. Directed named association – with multiplicities and navigable direction. Aggregation – whole/part structural association. Association class – stores attributes and operations of an association. 1..312..32 courseunit LecturerModule 1* teaches BookPerson 1..30..1 itemborrower Loan

11. 11COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – refined class diagram Card BankAccountDispenserTransaction refers to dispenses registers For each Card there is one bank account, one dispenser and an arbitrary number of transactions. Each BankAccount should have one or more cards associated with. The Dispenser refers to all cards. Each Transaction has a unique card on it. All associations are named, directed and unidirectional. 1..* 1 * 1 1 *

12. 12COM6030 Systems Analysis and Design © University of Sheffield 2005 Advertising company – class diagrams Client Campaign Advert 1 * 1 * initiatescontains A Client might initiates a number of campaigns. Each Campaign should have an arbitrary number of adverts (alternatively a range may be used, if known). The associations are undirected (or bidirectional) relationships. The association “contains” is an aggregation; “initiates” is only an association.

13. 13COM6030 Systems Analysis and Design © University of Sheffield 2005 Generalisation Transaction Get balance BankCard manager  Generalisation indicates a “is a” relationship between classes.  Remember generalisation relationships between uses cases/actors. Saloon Hatchback CarVehicle

14. 14COM6030 Systems Analysis and Design © University of Sheffield 2005 Generalisation  Arrow shows direction of association between subclass and its superclass.  Useful for showing abstraction of common behaviours.  Abstract super-classes are not instantiated in the final system; they can be re-used elsewhere.  Sub-classes inherit all the properties (attributes and operations) of the superclass as well as all of the associations.  Avoid over use of generalisation. Large differences between subclasses and forced creation of superclass may lead to confusion.  For example Helicopter and Bicycle are both vehicles, but there is little to be gained from generalising both.  Are Book and Journal related by generalisation? SubclassSuperclass

15. 15COM6030 Systems Analysis and Design © University of Sheffield 2005 Examples of generalisations SuccessfulTrans Transaction FailedTrans NewspaperAdv TelevisionAdv UGModule MScModule Advert Module ATM system - generalisation diagram Advertising company - generalisation diagram University system - generalisation diagram

16. 16COM6030 Systems Analysis and Design © University of Sheffield 2005 Object’s state and behaviour The system that we build will consist of a collection of objects which interact. Interactions are shown through class diagrams. So far we have identified:  classes;  relationships (associations) between classes. Remember, an object is a thing which has behaviour, state and identity (Booch). The state is given by the attributes’ values and the behaviour is shown by operations.

17. 17COM6030 Systems Analysis and Design © University of Sheffield 2005 Operations and attributes  Operations define the ways in which objects interact:  an object sends a message to another, asking to perform an operation;  the receiver will invoke a method to perform the operation; there may be more than one method implementing an operation.  Attributes describe the data contained in an object of a class.  According to the conceptual approach on defining classes and their associations, only data and messages expected to be understood by an object are considered. Attributes implementing associations are not considered in this stage.  When is necessary/possible types associated with operations and attributes are identified – remember slide 4.

18. 18COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – Card class Card cardNo cardHolder pin dayLimit validatePIN() changePIN() startWidraw() Card class’ attributes and operations; validatePIN() validates the PIN introduced against the value in pin ; changePIN() changes the current pin value with what this operation provides; 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 asks BankAccount to update the balance and Dispenser to release the cash. Card Responsibilities Manage (validate, change) PIN. Initiate withdrawal. Collaborations Bank account provides bank details. Bank account provides balance and overdraft. Dispenser provides amount requested.

19. 19COM6030 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. BankAccount Responsibilities Provide balance. Check if amount available in the current balance and overdraft. Update balance. Collaborations

20. 20COM6030 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. Dispenser Responsibilities Check if cash available. Update cash available. Collaborations

21. 21COM6030 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; It uses recordTransaction() to store suitable values according to the attributes described. No CRC card has been produced so far for Transaction, but there is the following description from the last lecture: let’s consider that transactions involving cash withdrawal, either failed or successful, are recorded. In this case, session (retained as vague) will be reconsidered and Transaction is the class that it will be identified.

22. 22COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary  Objects, classes and relationships.  Class/object diagrams and their relationships to CRC cards.  Class attributes and operations.  Class operations obtained from CRC card responsibilities.  Class diagram associations and CRC card collaborations.