1. Requirements Analysis 1. 1 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Objects, Classes and Associations Department of Information Systems

2. Requirements Analysis 1. 2 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Overview v Understand how object instances model real world concepts v Understand how classes are derived from objects v Understand object links and class associations v Learn UML notation for these concepts

3. Requirements Analysis 1. 3 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Instances v A use case realisation is a snapshot of object instances needed to make the use case ‘happen’ on one specific occasion v Several notations for instance: :Account006574:Account:006574 Named object.Named instance of known class. Anonymous instance of class.

4. Requirements Analysis 1. 4 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Instances v Alternative notation for instances: :Account006574:Account006574006574:Account owner = S McRobb type = current balance = £0.23p Anonymous instance of class Named instance of class Named object Named instance of class with attribute values v Note: attributes may be shown on instances, but operations are not shown

5. Requirements Analysis 1. 5 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Instances v The objects in this collaboration are all specific instances, though none are named :Cashier interface 1: identify 5: dispense :Withdrawal 2: request withdrawal :Account 3: validate and withdraw :Dispenser 4: authorise dispense

6. Requirements Analysis 1. 6 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Attributes v Objects have attributes v On a superficial level, attributes are simply data that describes an object: –A student called “Jethwa” – belongs to 99/00 cohort – identified as P990145672 :Student name = P Jethwa cohort = 99/00 ID = P990145672

7. Requirements Analysis 1. 7 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Attributes v In fact this is too simplistic v Some attributes are better modelled as associations to another class  Is cohort an attribute of Student or an object in its own right?  Depends on business needs: does cohort play a role in any use case realisation?

8. Requirements Analysis 1. 8 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Attributes v It is also too simplistic in another way v There needs to be some rigour about how attributes are allocated to objects v Normalisation provides one systematic approach (but beyond scope of this module)

9. Requirements Analysis 1. 9 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Object Responsibilities v In analysis, general responsibilities are identified, not specific operations v Example: –An account object has responsibilities to: v Each will translate to several operations in the design model

10. Requirements Analysis 1. 10 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Responsibilities and Operations Class Name Course Description The Course is responsible for maintaining information about a set of course sections having a common subject, requirements and syllabus Responsibilities To maintain information about the course AttributesDescription Course TitleThe name of the course DescriptionA short description of the course

11. Requirements Analysis 1. 11 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Responsibilities and Operations v Responsibilities are modelled as one or more operations  For Course analysis object: “responsible for maintaining information about a set of course sections having a common subject, requirements and syllabus ” v...corresponding operations are likely to be distributed between several classes

12. Requirements Analysis 1. 12 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Responsibilities and Operations v As a rule, we only model an operation in the analysis model if it represents a business process: addCourseSection is OK (may be complex, would at least create a new association)  But not newCourse (probably just an object constructor method)  And not getCourseDetails (just returns attribute values)

13. Requirements Analysis 1. 13 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Responsibilities and Operations v Collaborations help identify ‘homes’ for operations v But this is a temporary view and may change v Emphasis at all times: does model support known business requirements? v Requirements will also evolve

14. Requirements Analysis 1. 14 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Objects, Classes and Types v A class is: “a description of a set of objects that share the same attributes, operations, methods, relationships and semantics” v … While a type is: “A stereotype of class used to specify a domain of instances together with the operations applicable to the objects” Rational (1997) UML Semantics Guide

15. Requirements Analysis 1. 15 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Objects, Classes and Types v Some authors prefer type to class for a description of a set of real world objects v Class carries connotations of software implementation v But in UML and RUP, class means both analysis (problem domain) concept and design (solution domain) construct

16. Requirements Analysis 1. 16 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Objects and Classes v From instances we can infer classes :Student name = K Brooks cohort = 97/98 ID = P970557723 :Student name = P Jethwa cohort = 99/00 ID = P990145672 :Student name = A Bains cohort = 99/00 ID = P990245566 Student enrol cohort ID name graduate :Student name = N Lee cohort = 98/99 ID = P980385431 v Attributes are shown without values (only an instance can have a value) v Operations are shown

17. Requirements Analysis 1. 17 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Associations & Links v Links exist between object instances. – E.g. if you are a student on BIS you:StudentBIS:Course v An association between two classes describes a set of possible links between instances of those classes

18. Requirements Analysis 1. 18 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Associations and Links v From a link, we can infer an association v Also guess at constraints on number of links a:StudentBIS:Coursed:Student CS:Course e:Student c:Student b:Student

19. Requirements Analysis 1. 19 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Associations and Links v Some links must exist: any:Student a:Cellphone v Others just may exist: some:Student a:Car v Some are limited in number: 1:Student BIS:Course 64:Student …..:Student

20. Requirements Analysis 1. 20 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Multiplicity v Multiplicity is a formal way of recording constraints on associations v Caters for both:

21. Requirements Analysis 1. 21 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Associations StudentModule ** isRegisteredFor

22. Requirements Analysis 1. 22 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Associations Car Owner 1..*1 isOwnedBy

23. Requirements Analysis 1. 23 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Associations StaffMember ParkingPlace 0..1 isAllocatedTo v A staff member has just one parking place allocated to them, or none at all v A parking place is allocated to just one member of staff, or to no-one at all

24. Requirements Analysis 1. 24 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Business / Enterprise Rules v Association multiplicity constraints represent business or enterprise rules v E.g. bank accounts commonly have a sole designated account holder Sole Account AccountHolder 1..*1 isHeldBy v This gives contractual protection to both bank and customer

25. Requirements Analysis 1. 25 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Business or Enterprise Rules v Our model must reflect all relevant business rules v Software must mirror real-world legal and operating constraints v Failure to do this properly may bring commercial disaster v E.g. your bank‘s ATMs allow other customers to use your bank account!

26. Requirements Analysis 1. 26 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Summary v Understood how object instances model real world concepts v Understood how classes are derived from objects v Understood object links and class associations v Learned UML notation for these

27. Requirements Analysis 1. 27 Introduction - 2005b514.ppt © Copyright De Montfort University 2000 All Rights Reserved Reading v Bennett, S., McRobb, S. & Farmer, R. (1999) “Object- Oriented Systems Analysis and Design using UML”, McGraw-Hill, Maidenhead. (especially Chs 5 and 7) v Cook, S. and Daniels, J. (1994) “Designing Object Systems: Object-Oriented Modelling with Syntropy”, Prentice-Hall, Hemel Hempstead.