1 / 27

INFO2005 Requirements Analysis

INFO2005 Requirements Analysis. Objects, Classes and Associations Department of Information Systems. Overview. Understand how object instances model real world concepts Understand how classes are derived from objects Understand object links and class associations

hunter-galloway
Download Presentation

INFO2005 Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. INFO2005 Requirements Analysis Objects, Classes and Associations Department of Information Systems

  2. Overview • Understand how object instances model real world concepts • Understand how classes are derived from objects • Understand object links and class associations • Learn UML notation for these concepts

  3. :Account :006574 006574:Account Object Instances • A use case realisation is a snapshot of object instances needed to make the use case ‘happen’ on one specific occasion • Several notations for instance: Anonymous instance of class. Named object. Named instance of known class.

  4. :Account 006574:Account 006574 006574:Account owner = S McRobb type = current balance = £0.23p Object Instances • Alternative notation for instances: Named object Anonymous instance of class Named instance of class Named instance of class with attribute values • Note: attributes may be shown on instances, but operations are not shown

  5. 2: request withdrawal 1: identify :Cashierinterface 3: validate and withdraw :Account :Withdrawal 4: authorise dispense 5: dispense :Dispenser Object Instances • The objects in this collaboration are all specific instances, though none are named

  6. :Student name = P Jethwa cohort = 99/00 ID = P990145672 Object Attributes • Objects have attributes • On a superficial level, attributes are simply data that describes an object: • A student called “Jethwa” • belongs to 99/00 cohort • identified as P990145672

  7. Object Attributes • In fact this is too simplistic • 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. Object Attributes • It is also too simplistic in another way • There needs to be some rigour about how attributes are allocated to objects • Normalisation provides one systematic approach (but beyond scope of this module)

  9. Object Responsibilities • In analysis, general responsibilities are identified, not specific operations • Example: • An account object has responsibilities to: • Each will translate to several operations in the design model

  10. 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 Attributes Description Course Title The name of the course Description A short description of the course Responsibilities and Operations

  11. Responsibilities and Operations • 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” • ...corresponding operations are likely to be distributed between several classes

  12. Responsibilities and Operations • 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. Responsibilities and Operations • Collaborations help identify ‘homes’ for operations • But this is a temporary view and may change • Emphasis at all times: does model support known business requirements? • Requirements will also evolve

  14. Objects, Classes and Types • A class is: “a description of a set of objects that share the same attributes, operations, methods, relationships and semantics” • … 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. Objects, Classes and Types • Some authors prefer type to class for a description of a set of real world objects • Class carries connotations of software implementation • But in UML and RUP, class means both analysis (problem domain) concept and design (solution domain) construct

  16. :Student :Student :Student :Student name = A Bains name = P Jethwa name = N Lee name = K Brooks cohort = 97/98 cohort = 99/00 cohort = 98/99 cohort = 99/00 ID = P970557723 ID = P990245566 ID = P990145672 ID = P980385431 Student name cohort ID enrol graduate Objects and Classes • From instances we can infer classes • Attributes are shown without values (only an instance can have a value) • Operations are shown

  17. you:Student BIS:Course Associations & Links • Links exist between object instances. • E.g. if you are a student on BIS • An association between two classes describes a set of possible links between instances of those classes

  18. a:Student BIS:Course b:Student c:Student d:Student CS:Course e:Student Associations and Links • From a link, we can infer an association • Also guess at constraints on number of links

  19. 1:Student …..:Student BIS:Course any:Student some:Student a:Cellphone a:Car 64:Student Associations and Links • Some links must exist: • Others just may exist: • Some are limited in number:

  20. Association Multiplicity • Multiplicity is a formal way of recording constraints on associations • Caters for both:

  21. Student Module * * isRegisteredFor UML Notation: Associations

  22. Owner Car 1..* 1 isOwnedBy UML Notation: Associations

  23. ParkingPlace StaffMember 0..1 0..1 isAllocatedTo UML Notation: Associations • A staff member has just one parking place allocated to them, or none at all • A parking place is allocated to just one member of staff, or to no-one at all

  24. AccountHolder Sole Account 1..* 1 isHeldBy Business / Enterprise Rules • Association multiplicity constraints represent business or enterprise rules • E.g. bank accounts commonly have a sole designated account holder • This gives contractual protection to both bank and customer

  25. Business or Enterprise Rules • Our model must reflect all relevant business rules • Software must mirror real-world legal and operating constraints • Failure to do this properly may bring commercial disaster • E.g. your bank‘s ATMs allow other customers to use your bank account!

  26. Summary • Understood how object instances model real world concepts • Understood how classes are derived from objects • Understood object links and class associations • Learned UML notation for these

  27. Bennett, S., McRobb, S. & Farmer, R. (1999) “Object-Oriented Systems Analysis and Design using UML”, McGraw-Hill, Maidenhead. (especially Chs 5 and 7) Cook, S. and Daniels, J. (1994) “Designing Object Systems: Object-Oriented Modelling with Syntropy”, Prentice-Hall, Hemel Hempstead. Reading

More Related