Requirements Capture: example UML Use Case Models And Class Models The following emerges after discussions: the library has books and journals (several copies of either) some books are available for a short term loan only there is a borrowing limit of up to 6 books for students and 12 for staff New books and journals arrive all the time and have to be catalogued, and old ones are sometimes disposed of. At the end of each year journals have to sent off to be bound Books and journals borrowed by library members must be recorded, and the new system should issue reminders when a book is overdue Users need to be able to browse for a book on any topic to see if it available for loan, and if not, they can reserve a copy. 2 nd sem 2003 1 2 nd sem 2003 2 UML: Use case models Use case diagram Use cases describe the system behaviour from the user s viewpoint help capture requirements and help planning and testing Actors (external users of the system - includes other systems) Use cases (how the system can be used by the user) Reserve book Borrow Copy of book Browse Browser For example, in a library system we identify: a BookBorrower actor a use case for this actor would be Borrow Copy of Book. We need to define this use case: A BookBorrower presents a book, the system checks the user is a library member, and that the maximum numbers of loans for this user has not been exceeded the loan is recorded, otherwise it is refused BookBorrower JournalBorrower Return copy of book Extend loan Borrow Journal Update Catalog Librarian Return Journal 2 nd sem 2003 3 2 nd sem 2003 4
Actors: UML: Use case models (2) identify the beneficiaries of use cases actors identify the roles that actors play may lead to different actors representing the same user non-human actors should be identified at a high level of abstraction: e.g. another library s computer Use cases: A scenario is an instance of a use case - just one possible interaction between the system and its users or other systems e.g. Book borrower Fred Bloggs tries to borrow the 2nd copy of Star Wars from the library which has it an acceptable instance of the Borrow copy of book use case Scenarios are linked by the performing of essentially the same task, but with alternative or unusual outcomes UML: Use case models (3) Using use cases: requirements capture identify the actors identify what they want from the system even at this early stage it is useful to get an idea of how much information an actor needs from the system (and record it) Using use cases: development to support planning, we need the use cases: we know what each use case is, and who wants it (and hopefully how much they want it) we can work on examining the high risk use cases, and then on estimating how long each use case will take to develop project schedule from a political point of view, the use cases that users want the most should be delivered first from a technical point of view, the use cases that carry the highest risk should be delivered first 2 nd sem 2003 5 2 nd sem 2003 6 UML: Use case models (4) UML: Class models Using use cases: system validation and testing since each use case describes a requirement, a correct design realizes all use case requirements we can test for each use case develop test cases to test every scenario in the use case Possible problems: use cases are not inherently OO (which is how we want to build our system architecture) because they capture what the user wants (and they don t really care how the system does it) doing design while capturing requirements thinking about scenarios at too low a level in a fixed order may miss some requirements if too use-case driven UML class diagrams describe the logical view of the system, i.e. the static structure - what the classes are and how they are related BUT NOT how they interact Identifying classes and objects: we want to meet all the system requirements from the system objects we construct from the classes we design a good class model is made up of classes that will endure and not depend on the specific functionality required by the system Ways to build the class model: this is a highly iterative process - easy to start with the problem domain objects, and abstract domain classes from them, e.g. copy of War and Peace class Book two common ways: data-driven design and responsibility-driven design (classes have both) 2 nd sem 2003 7 2 nd sem 2003 8
Digression class model EmailA ddres s username : String machinename : String university : String organization : String country : String getusername() : String setusername(argusername : String) getmachinename() : String UML: Class identification Noun identification: identify candidate classes from the nouns and noun phrases in the requirements specification discard candidates which are redundant, vague, outside the system scope, part of the specification language, an event or operation (of another class), an attribute (of another class) CRC cards: class, responsibilities and collaborations - all on one card for each class Class Name Responsibilities What the class has to do Collaborators What classes interact with this class 2 nd sem 2003 9 2 nd sem 2003 10 Identifying classes Example of noun identification The library contains books and journals. It may have several copies of a book. Some of the books are for short term loans only. All other books can be borrowed by any library member for three weeks. Members of the library can borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned, enforcing the above rules. Produces a list of candidate classes reduce library - outside this software system short term loan - really an event member of the library - same as library member week, time - measures of time or outside the system system, rule - part of language of requirements, not the system Identifying classes (2) Remaining classes: book, journal, copy (of a book), library member, staff member Don t need to get this exactly right: not an exact science ok to agree some definitions need more work not trying to design the system yet, just capture the important real-world objects within the problem domain Can refine when we look at how classes associate: used to clarify understanding of the problem domain check the coupling between classes - remember we want high cohesion and low coupling, but if objects are closely coupled then this needs to be identified as early as possible 2 nd sem 2003 11 2 nd sem 2003 12
Lecture Summary UML: Use case models for requirements capture UML: Class models - what are they really? they describe objects with equivalent roles in the system all real-world objects will belong to a class, e.g. book, unit all roles that objects can take on are also classes, e.g. library member, student objects in our system only represent real-world objects - so we only want to know about information that is relevant for our system model of the object Next UML : Class associations UML: Class Associations 2 nd sem 2003 13 2 nd sem 2003 14 UML: Class Associations Associations between classes: can often be found from the verbs in the specification, e.g. a library member borrows a book if some object of class A needs to know something about object of class B must be an association. an association relates a pair of classes and an instance of an association relates a pair of objects Class A Association Class B UML: Class Associations (2) Simple association: Copy Is a copy of 1..* 1 Book Multiplicities: the number of instances of classes at each end of associations, e.g. we may have from 1 to many (1..*) copies of a book for each book (1) Object A Association instance Object B Attributes: describes the data in the class Operations: methods invoked with parameters Title : String Book copiesonshelf () : Integer 2 nd sem 2003 15 2 nd sem 2003 16
UML: Generalization Generalization: specialised classes (i.e. subclasses) must perform all the operations and have the same attributes as their superclass (i.e. objects of a specialised class can be substituted for an object of a more general class) e.g. MemberOfStaff is a generalization of LibraryMember (i.e. every LibraryMember is also a MemberOfStaff ) in UML the open arrow head points to the more generalized class (or superclass) common to have a is a relationship, i.e. specialized class is a generalized class, e.g. collie is a breed of dog Object Object MemberOfStaff LibraryMember Generalized class Specialized class UML: Inheritance Inheritance is the implementation of generalization in OO languages (generalization also applies to types) Inheritance can bring problems if overused: subclasses are dependent on changes in superclasses can force recompilation of all subclasses composition is a useful alternative: e.g. suppose we have a List class that we wish to use to implement an AddressBook class could let AddressBook inherit from List, or could let AddressBook own a copy of List by defining an attribute addresses: List still useful to define abstract type relationships (even if not implemented with inheritance) Cash Payment Payment Amount: Money Cheque Payment Credit Payment 2 nd sem 2003 17 2 nd sem 2003 18 UML: More associations Aggregation and composition: showing an object of one class is part of an object of another class Aggregation - e.g. unit is part of a degree: UML: More on associations (2) Roles: Associations can be described by roles at either end or be named in the middle Lecturer +Course Advisor +Advisee Student BEdegree year unit 1..* 4 1..* 8 An association name is not usually needed - but is legal Composition - e.g. square is part of a chess board: chessboard Composition is stronger, all parts of an object are owned by the whole object multiplicity of owner must be 1 or 0..1 1 64 square 2 nd sem 2003 19 Navigability: restrict direction of messaging between classes Student is taking 1..* 8 Use of bi-directional navigability should be sparing as too many classes knowing about other classes limits potential reuse (e.g. Unit in the above example) Unit 2 nd sem 2003 20
Lecture Summary UML: Class associations Simple associations generalization inheritance aggregation composition roles & navigability Next Dynamic models & interactions between classes 2 nd sem 2003 21