Modeling Requirements

Transcription

1 Modeling Requirements Robert B. France Colorado State University Robert B. France 3-1

2 Overview Requirements engineering review Requirements engineering = requirements elicitation + specification + analysis Class modeling review Use case review Advanced use case modeling Robert B. France 3-2

3 Requirements Engineering - Review Robert B. France 3-3

4 3.2 Requirements - purpose The purpose of the requirements workflow is to create a high-level specification of what should be implemented We interview the stakeholders to find out what they need the system to do for them their requirements Inception Elaboration Construction Transition Clear View Training 2010 v2.6 4

5 3.5 The importance of requirements Project Failures Incomplete requirements are the primary reason that projects fail! The Standish Group, "The CHAOS Report (1994) " Clear View Training 2010 v2.6 5

6 3.6 What are requirements? Requirements - A specification of what should be implemented : What behaviour the system should offer A specific property of the system A constraint on the system In UP we create a Software Requirements Specification (SRS) The beginning of the OO software construction process it is a statement of the system requirements for all stakeholders Organises related requirements into sections The SRS consists of: Textual descriptions of functional and non-functional requirements Use case model comprising actors and use cases Requirements class model Clear View Training 2010 v2.6 6

7 Requirements Engineering Focus on eliciting, analyzing, documenting and managing requirements for the software component of a system. Elicitation: extracting requirements from customers and users Analysis: analyzing and organizing requirements to gain deeper understanding Results of analysis reflected in models: Use Cases, Requirements Class Model Specification: detailed documentation of required behavior Validation: requirements are validated against customer/ user needs Requirements management: activities related to documenting, controlling and tracking requirements and changes to requirements Robert B. France 3-7

8 What is a software requirement? A requirement is a statement about the proposed software that all stakeholders agree must be made true in order for the customer s problem to be adequately solved. Says something about what the software does and what data it maintains All the stakeholders have agreed that it is valid A collection of requirements is a requirements document (e.g., the SRS in UP) Robert B. France 3-8

9 2 Broad Categories of Requirements types Previous types can be broadly categorized as Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development Examples: the software must restrict access to sensitive information; the software must deliver a response within a time interval after a particular event has occurred; the software must be usable by persons who are not computer literate. Robert B. France 3-9

10 Describing Functional Requirements Textual functional feature list Features in list are prioritized (e.g., necessary, desirable, cosmetic) Feature list used to focus activities in UP iterations Requirements models Class model: describes problem concepts and the their relationships Use cases: describe required features in terms of how users will interact with the software to accomplish goals Robert B. France 3-10

11 System Attributes (Non-Functional Requirements - NFRs) Three major types Categories reflecting: usability, efficiency, reliability, maintainability and reusability: Response time, Throughput, Resource usage, Reliability, Availability, Recovery from failure, Allowances for maintainability and enhancement, Allowances for reusability Categories constraining the environment and technology of the software. Platform Technology to be used Categories constraining the project plan and development methods Development process (methodology) to be used Cost and delivery date Often put in contract or project plan instead Descriptions of NFRs can be included in use cases Robert B. France 3-11

12 Textual Description of Functional Requirements System functions: Services provided by software system Function categories Evident: user-observable services that must be provided Hidden: services that must be provided that are not visible to users (e.g., logging transactions in a banking system) Frill: Optional services that enhance use of system Robert B. France 3-12

13 Function Specification Example Ref # Function Category R1.1 Handle cash payments, capturing amount tendered and calculating balance due evident R1.2 Log credit payments hidden Robert B. France 3-13

14 Documenting Attributes of System Functions Ref # Function Cat. Attribute Details Cat. R0.9 Display desc. and item price evident Response time 5 secs. max must interface Forms based must graphical want R1.2 Log credit payments hidden Fault tolerance Must log within 24 hrs even in power failure must Robert B. France 3-14

15 Modeling Requirements Describe required functionality using use cases Use case diagrams simply indentify the use cases and the actors that interact with them Use cases can be described textually or using activity diagrams Describe imposed structure on problem concepts using class models Robert B. France 3-15

16 Requirements Specification Structure Textual requirements description Requirements glossary/dictionary Functional requirements description NFR description Requirements models Requirements class model Requirements use cases Robert B. France 3-16

17 4.3.4 The Project Glossary Project Glossary Term1 Term2 Term3 Definition Synonyms Homonyms Definition Synonyms Homonyms Definition Synonyms Homonyms In any business domain there is always a certain amount of jargon. It s important to capture the language of the domain in a project glossary The aim of the glossary is to define key terms and to resolve synonyms and homonyms You are building a vocabulary that you can use to discuss the system with the stakeholders Clear View Training 2010 v2.6 17

18 A Requireme nts Class Diagram of a Video Rental System Robert B. France 3-18

19 A use case diagram Mail Order System use case diagram communication relationship Mail Order System PlaceOrder subject name system boundary CancelOrder ShipProduct ShippingCompany Customer CheckOrderStatus actor SendCatalogue use case Dispatcher Clear View Training 2010 v2.6 19

20 Do s and Don ts of writing use case descriptions Tip 1: Focus only on direct interactions between the software and a user Robert B. France 3-20

21 Models vs. Diagrams A diagram is a view on a model A diagram does not necessarily display all information in a model A class diagram may only show some of the classes, associations, attributes and operations included in a model A diagram is the same as a model if it displays all the information in the model. Robert B. France 3-21

22 Requirements Class Diagram Review Robert B. France 3-22

23 What is a class? A class is a description of a set of objects that share the same properties (expressed as attributes and relationships) At the requirements level a class describes a concept in the problem domain At the design level a class describes a concept in the solution domain At the programming level a class defines objects that will perform computations An object is a concept, abstraction, or thing with identity that has meaning for an application. An object is an instance of a class Each object knows its class Robert B. France 2-23

24 What is a Class Model? Syntactically, a class model is a structure of classes. Semantically, a requirements class model describes problem concepts and their relationships a design class model describes solution concepts and their relationships an implementation class model describes program-level objects (e.g., Java objects) and their links Key Question: What are the objects of interest in the problem/solution space? their properties (in terms of attributes and operations)? their relationships? Robert B. France 2-24

25 What should be an attribute? Properties with types that we want to treat as primitive are modeled as attributes Connections to other concepts are to be represented as associations, not attributes. Robert B. France 2-25

26 Identifying and specifying valid attributes It is not good to have many duplicate attributes If a subset of a class s attributes form a coherent group, then create a distinct class containing these attributes Robert B. France 2-26

27 Modeling Static Relationships Two kinds of static relationships: Associations Represent structural relationships among objects An association specifies a collection of links, where a link is a physical or conceptual connection among objects. Generalizations Represent generalization/specialization class structures The two kinds of relationships are orthogonal Robert B. France 2-27

28 Associations Robert B. France 2-28

29 Multiplicity Robert B. France 2-29

30 Association Roles When a class is part of an association it plays a role in the relationship. You can name the role that a class plays in an association by placing the name at the class s association end. Formally, a class role is the set of objects that are linked via the association. Robert B. France 2-30

31 class roles Person project leader project member managed project * assigned project * Project Robert B. France 2-31

32 My Requirements Class Modeling Rules All association ends must have multiplicities There is a default, but most people do not remember it; better to be explicit to avoid confusing the reader All associations must be named (either an association name or a role names at each end) Robert B. France 3-32

33 More Modeling Rules Do not put navigation arrows on associations in requirements class diagrams Determining which class is visible to another class is a design decision (also see below) Do not put operations in requirements class diagrams There can be more than one way to assign responsibilities to a class; this is a design decision To avoid making design decisions too early, novice modelers should not include operations in requirements class models Robert B. France 3-33

34 Do Not Use Attributes To Relate Concepts!!! Robert B. France 2-34

35 Association classes Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes The following are equivalent Student * * CourseSection Registration grade Student * Registration * grade CourseSection Robert B. France 2-35

36 Reflexive associations It is possible for an association to connect a class to itself successor * * Course * * prerequisite ismutuallyexclusivewith Robert B. France 2-36

37 UML Forms of Aggregation Composition (strong aggregation) parts are existent-dependent on the whole parts are generated at the same time, before, or after the whole is created (depending on cardinality at whole end) and parts are deleted before or at the same time the whole dies multiplicity at whole end must be 1 or 0..1 (weak) Aggregation Robert B. France 2-37

38 Composition 1 The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Window 1 1 scrollbar 2 title 1 body 1 T h The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Slider Header Panel Robert B. France 2-38

39 Guidelines to Identifying Associations Focus on associations for which knowledge of the relationship must be preserved for some duration An association should exist if a class possesses controls is connected to is related to is a part of has as parts is a member of, or has as members another class More important to identify concepts than associations Too many associations can lead to confusing models Avoid showing redundant/derivable associations Robert B. France 2-39

40 Actions versus associations A common mistake is to represent actions as if they were associations LibraryPatron borrow * * return * * CollectionItem Bad, due to the use of associations that are actions * Loan borroweddate duedate returneddate * * LibraryPatron CollectionItem Better: The borrow operation creates a Loan, and the return operation sets the returneddate attribute. Robert B. France 2-40

41 Generalization/Specialization A generalization (or specialization) is a relationship between a general concept and its specializations. Objects of specializations can be used anywhere an object of a generalization is expected (but not vice versa). Example: Mechanical Engineer and Aeronautical Engineer are specializations of Engineer Robert B. France 2-41

42 Generalization Robert B. France 2-42

43 Generalization Fig. 3-48, UML Notation Guide Robert B. France 2-43

44 Avoiding unnecessary generalizations Improved class diagram, with its corresponding instance diagram (Player-Role pattern) Inappropriate hierarchy of classes, which should be instances Recording * hascategory title artist RecordingCategory * subcategory description :RecordingCategory video :RecordingCategory audio subcategory :RecordingCategory music video subcategory :RecordingCategory jazz subcategory subcategory subcategory :RecordingCategory :RecordingCategory :RecordingCategory classical blues rock :Recording 9th Symphony Beethoven :Recording Let it be The Beatles Robert B. France 2-44

45 Handling multiple discriminators Creating higher-level generalization Robert B. France 2-45

46 Handling multiple discriminators Using multiple inheritance habitat Animal typeoffood AquaticAnimal LandAnimal Carnivore Herbivore AquaticCarnivore AquaticHerbivore LandCarnivore LandHerbivore Using the Player-Role pattern Robert B. France 2-46

47 Avoiding having instances change class An instance should never need to change class Robert B. France 2-47

48 Identifying generalizations and interfaces There are two ways to identify generalizations: bottom-up Group together similar classes creating a new superclass top-down Look for more general classes first, specialize them if needed Robert B. France 2-48

49 Handling Large Domain Models Use packages to provide views of large domain models Developers may not have to draw package boxes around groups as in this example. Rather, a CASE tool will allow drill down. Robert B. France 2-49

50 Object Diagrams An object diagram describes a structure of objects. One can view a class diagram as specifying a collection of object structures Conformant object structures have objects and links that satisfy the multiplicity and other constraints specified in the class diagram. Robert B. France 2-50

51 Object Diagram Example Pat:Employee Wayne:Employee OOCorp:Company OOCorp's Board: Ali:Employee Carla:Employee UML inc:company UML inc's Board Terry:Employee Robert B. France 2-51

52 Associations versus generalizations in object diagrams Associations describe the relationships that will exist between objects at run time. When you show an object diagram generated from a class diagram, there will be an instance of both classes joined by an association Generalizations describe relationships between classes in class diagrams. They do not appear in object diagrams at all. An instance of any class should also be considered to be an instance of each of that class s superclasses Robert B. France 2-52

53 Use Cases Robert B. France 3-53

54 3.4 Use case development - workflow Find actors and use cases System Analyst Structure the use case model Architect Prioritise use cases Use case specifier Detail a use case User interface designer Prototype user interface Clear View Training 2010 v2.6 54

55 4.2 Use case modelling Use case modelling is a form of requirements engineering Use case modelling proceeds as follows: Find the system boundary Find actors Find use cases Use case specification Scenarios It lets us identify the system boundary, who or what uses the system, and what functions the system should offer Clear View Training 2010 v2.6 55

56 4.3 Find actors and use cases Business model [or system model] System analyst Use case model [outlined] Requirements description Find actors and use cases Feature list Project glossary Clear View Training 2010 v2.6 56

57 4.3.1 The subject Before we can build anything, we need to know: Where the boundary of the system lies Who or what uses the system What functions the system should offer to its users We create a Use Case model containing: Subject the edge of the system also known as the system boundary Actors who or what uses the system Use Cases things actors do with the system Relationships - between actors and use cases subject SystemName Clear View Training 2010 v2.6 57

58 4.3.2 What are actors? An actor is a role that I played by anything that interacts directly with the system Actors identify who or what uses the system and so indicate where the system boundary lies Actors are external to the system An Actor specifies a role that some external entity plays when interacting with the system Customer «actor» Customer Clear View Training 2010 v2.6 58

59 Identifying Actors When identifying actors ask: Who or what uses the system? What roles do they play in the interaction? Who installs the system? Who starts and shuts down the system? Who maintains the system? What other systems use this system? Who gets and provides information to the system? Does anything happen at a fixed time? Time Clear View Training 2010 v2.6 59

60 4.3.3 What are use cases? A use case is something an actor needs the system to do. It is a case of use of the system by a specific actor Use cases are always started by an actor The primary actor triggers the use case Zero or more secondary actors interact with the use case in some way Use cases are always written from the point of view of the actors PlaceOrder GetStatusOnOrder Clear View Training 2010 v2.6 60

61 Identifying use cases Start with the list of actors that interact with the system When identifying use cases ask: What functions will a specific actor want from the system? Does the system store and retrieve information? If so, which actors trigger this behaviour? What happens when the system changes state (e.g. system start and stop)? Are any actors notified? Are there any external events that affect the system? What notifies the system about those events? Does the system interact with any external system? Does the system generate any reports? Clear View Training 2010 v2.6 61

62 A use case diagram Mail Order System use case diagram communication relationship Mail Order System PlaceOrder subject name system boundary CancelOrder ShipProduct ShippingCompany Customer CheckOrderStatus actor SendCatalogue use case Dispatcher Clear View Training 2010 v2.6 62

63 4.4 Use case model [outlined] Supplementary requirements Detail a use case Use case specifier Detail a use case Detailed use case can be textual or an activity diagram Glossary Clear View Training 2010 v2.6 63

64 4.5 Use case specification use case name use case identifier brief description the actors involved in the use case the system state before the use case can begin the actual steps of the use case the system state when the use case has finished alternative flows Use case: PaySalesTax ID: 1 Brief description: Pay Sales Tax to the Tax Authority at the end of the business quarter. Primary actors: Time Secondary actors: TaxAuthority Preconditions: 1. It is the end of the business quarter. Main flow: The use case starts when it is the end of the business quarter. The system determines the amount of Sales Tax owed to the Tax Authority. The system sends an electronic payment to the Tax Authority. Postconditions: 1. The Tax Authority receives the correct amount of Sales Tax. Alternative flows: None. implicit time actor Clear View Training 2010 v2.6 64

65 Naming use cases Use cases describe something that happens They are named using verbs or verb phrases Naming standard 1 : use cases are named using UpperCamelCase e.g. PaySalesTax 1 UML 2 does not specify any naming standards. All naming standards are our own, based on industry best practice. Clear View Training 2010 v2.6 65

66 4.5.5 Pre and postconditions Preconditions and postconditions are constraints Preconditions constrain the state of the system before the use case can start Postconditions constrain the state of the system after the use case has executed If there are no preconditions or postconditions write "None" under the heading Use case: PlaceOrder Preconditions: 1. A valid user has logged on to the system Postconditions: 1. The order has been marked confirmed and is saved by the system Clear View Training 2010 v2.6 66

67 4.5.6 Main flow <number> The <something> <some action> The flow of events lists the steps in a use case It always begins by an actor doing something A good way to start a flow of events is: 1) The use case starts when an <actor> <function> The flow of events should be a sequence of short steps that are: Declarative Numbered, Time ordered The main flow is always the happy day or perfect world scenario Everything goes as expected and desired, and there are no errors, deviations, interrupts, or branches Alternatives can be shown by branching or by listing under Alternative flows (see later) Clear View Training 2010 v2.6 67

68 Branching within a flow: If Use case: ManageBasket Use the keyword if to indicate alternatives within the flow of events There must be a Boolean expression immediately after if Use indentation and numbering to indicate the conditional part of the flow Use else to indicate what happens if the condition is false (see next slide) ID: 2 Brief description: The Customer changes the quantity of an item in the basket. Primary actors: Customer Secondary actors: None. Preconditions: 1. The shopping basket contents are visible. Main flow: Postconditions: None. The use case starts when the Customer selects an item in the basket. If the Customer selects "delete item" If the Customer types in a new quantity The system removes the item from the basket. The system updates the quantity of the item in the basket. Alternative flows: None. Clear View Training 2010 v2.6 68

69 Repetition within a flow: For We can use the keyword For to indicate the start of a repetition within the flow of events The iteration expression immediately after the For statement indicates the number of repetitions of the indented text beneath the For statement. Use case: FindProduct ID: 3 Brief description: The system finds some products based on Customer search criteria and displays them to the Customer. Actors: Customer Preconditions: None. Main flow: 1. The use case starts when the Customer selects "find product". 2. The system asks the Customer for search criteria. 3. The Customer enters the requested criteria. 4. The system searches for products that match the Customer's criteria. 5. For each product found 5.1. The system displays a thumbnail sketch of the product The system displays a summary of the product details The system displays the product price. Postconditions: None. Alternative flows: NoProductsFound Clear View Training 2010 v2.6 69

70 Repetition within a flow: While We can use the keyword while to indicate that something repeats while some Boolean condition is true Use case: ShowCompanyDetails ID: 4 Brief description: The system displays the company details to the Customer. Primary actors: Customer Secondary actors: None Preconditions: None. Main flow: 1. The use case starts when the Customer selects "show company details". 2. The system displays a web page showing the company details. 3. While the Customer is browsing the company details 4. The system searches for products that match the Customer's criteria The system plays some background music The system displays special offers in a banner ad. Postconditions: 1. The system has displayed the company details. 2. The system has played some background music. 3. The systems has displayed special offers. Alternative flows: None. Clear View Training 2010 v2.6 70

71 4.5.7 Branching: Alternative flows We may specify one or more alternative flows through the flow of events: Alternative flows capture errors, branches, and interrupts Alternative flows never return to the main flow Potentially very many alternative flows! You need to manage this: Pick the most important alternative flows and document those. If there are groups of similar alternative flows - document one member of the group as an exemplar and (if necessary) add notes to this explaining how the others differ from it. Use case main flow alternative flows Only document enough alternative flows to clarify the requirements! Clear View Training 2010 v2.6 71

72 4.5.7 Referencing alternative flows List the names of the alternative flows at the end of the use case Find alternative flows by examining each step in the main flow and looking for: Alternatives Exceptions Interrupts Use case: CreateNewCustomerAccount ID: 5 Brief description: The system creates a new account for the Customer. Primary actors: Customer Secondary actors: None. Preconditions: None. Main flow: The use case begins when the Customer selects "create new customer account". While the Customer details are invalid The system creates a new account for the Customer. Postconditions: 1. A new account has been created for the Customer. Alternative flows: Invalid Address InvalidPassword Cancel The system asks the Customer to enter his or her details comprising address, password and password again for confirmation. The system validates the Customer details. Clear View Training 2010 v2.6 72

73 4.5.7 An alternative flow example notice how we name and number alternative flows Alternative flow: CreateNewCustomerAccount:Invalid Address ID: 5.1 Brief description: The system informs the Customer that they have entered an invalid address. Primary actors: Customer Secondary actors: None. Preconditions: 1. The Customer has entered an invalid address always indicate how the alternative flow begins. In this case it starts after step 2.2 in the main flow Alternative flow: The alternative flow begins after step 2.2. of the main flow. The system informs the Customer that he or she entered an invalid address. Postconditions: None. The alternative flow may be triggered instead of the main flow - started by an actor The alternative flow may be triggered after a particular step in the main flow - after The alternative flow may be triggered at any time during the main flow - at any time Clear View Training 2010 v2.6 73

74 4.6 Requirements tracing Given that we can capture functional requirements in a requirements model and in a use case model we need some way of relating the two There is a many-to-many relationship between requirements and use cases: One use case covers many individual functional requirements One functional requirement may be realised by many use cases Hopefully we have CASE support for requirements tracing: With UML tagged values, we can assign numbered requirements to use cases We can capture use case names in our Requirements Database If there is no CASE support, we can create a Requirements Traceability matrix Requirements Use cases R1 R2 R3 R4 R5 Requirements Traceability Matrix U1 U2 U3 U4 Clear View Training 2010 v2.6 74

75 4.7 When to use use case analysis Use cases describe system behaviour from the point of view of one or more actors. They are the best choice when: The system is dominated by functional requirements The system has many types of user to which it delivers different functionality The system has many interfaces Use cases are designed to capture functional requirements. They are a poor choice when: The system is dominated by non-functional requirements The system has few users The system has few interfaces Clear View Training 2010 v2.6 75

76 Requirements advanced use case modelling Clear View Training 2010 v2.6 76

77 5.1 More relationships We have studied basic use case analysis, but there are relationships that we have still to explore: Actor generalisation Use case generalisation «include» between use cases «extend» between use cases Clear View Training 2010 v2.6 77

78 5.2 Actor generalization - example The Customer and the Sales Agent actors are very similar They both interact with List products, Order products, Accept payment Additionally, the Sales Agent interacts with Calculate commission Our diagram is a mess can we simplify it? Customer SalesAgent Sales system ListProducts OrderProducts AcceptPayment CalculateCommission Clear View Training 2010 v2.6 78

79 5.2 If two actors communicate with the same set of use cases in the same way, then we can express this as a generalisation to another (possibly abstract) actor The descendent actors inherit the roles and relationships to use cases held by the ancestor actor We can substitute a descendent actor anywhere the ancestor actor is expected. This is the substitutability principle Actor generalisation ancesto r or generalisation parent Customer abstract actor Purchaser SalesAgent descendents or children Sales system ListProducts OrderProducts AcceptPayment CalculateCommiss Use actor generalization when it simplifies the model Clear View Training 2010 v2.6 79

80 5.3 Use case generalisation The ancestor use case must be a more general case of one or more descendant use cases Child use cases are more specific forms of their parent They can inherit, add and override features of their parent Use case generalization semantics Use case element Inherit Add Override Relationship Yes Yes No Extension point Yes Yes No Precondition Yes Yes Yes Postcondition Yes Yes Yes Step in main flow Yes Yes Yes Customer Sales system FindProduct FindBook FindCD Alternative flow Yes Yes Yes Clear View Training 2010 v2.6 80

81 5.4 The base use case executes until the point of inclusion: include(inclusionusecase) Note: Control passes to the inclusion use case which executes When the inclusion use case is finished, control passes back to the base use case which finishes execution Base use cases are not complete without the included use cases Inclusion use cases may be complete use cases, or they may just specify a fragment of behaviour for inclusion elsewhere «include» Manager base use case Personnel System ChangeEmployeeDetails «include» ViewEmployeeDetails «include» Clear View Training 2010 v FindEmployeeD «include» DeleteEmployeeDetails inclusion include use case relations hip When use cases share common behaviour we can factor this out into a separate inclusion use case and «include» it in base use cases

82 5.4 «include» example Use case: ChangeEmployeeDetails Use case: FindEmployeeDetails ID: 1 ID: 4 Brief description: Brief description: Primary The Manager actors: changes the employee details. Primary The Manager actors: finds the employee deta Manager Seconday actors: Manager Seconday actors: Preconditions: None Preconditions: None 1. The Manager is logged on to the system. 1. The Manager is logged on to the sy Main flow: Main flow: 1 include 1 The Manager enters the. ( FindEmployeeDetails ). Postconditions:. employee's ID. Postconditions: 2 The system displays the 1. 2 The system has finds found the the employe Alternative flows: 1.. The employee employee details. Alternative details have been changed.. employee details. 3 The Manager flows: None. changes the None. Clear View Training 2010 v employee details.

83 5.5 «extend» «extend» is a way of adding new behaviour into the base use case by inserting behaviour from one or more extension use cases The base use case specifies one or more extension points in its flow of events The extension use case may contain several insertion segments The «extend» relationship may specify which of the base use case extension points it is extending Librarian Library base use system case ReturnBook BorrowBook FindBook «extend» IssueFine extend extens relations ion hip use case The extension use case inserts behaviour into the base use case. The base use case provides extension points, but does not know about the extensions. Clear View Training 2010 v2.6 83

84 5.5 Base use case extension point name base use case extension use case «extend» (overduebook) ReturnBook extension points overduebook IssueFine extension point Use case: ReturnBook ID: 9 Brief description: The Librarian returns a borrowed book. Primary actors: Librarian Secondary actors: None. Preconditions: 1. The Librarian is logged on to the system. Main flow: The Librarian enters the borrower's ID number. The system displays the borrower's details including the list of borrowed books. The Librarian finds the book to be returned in the list of books. extension point: overduebook 4. The Librarian returns the book. Postconditions: 1. The book has been returned. Alternative flows: None. There is an extension point overduebook just before step 4 of the flow of events Extension points are not numbered, as they are not part of the flow Clear View Training 2010 v2.6 84

85 5.5.1 Extension use case ReturnBook extension points overduebook Extension Use case: IssueFine ID: 10 Brief description: Segment 1: The Librarian records and prints out a fine. Primary actors: Librarian the single insertion segment in IssueFine is inserted at the overduebook insertion point in the ReturnBook use case «extend» (overduebook) IssueFine Secondary actors: None. Segment 1 preconditions: 1. The returned book is overdue. Segment 1 flow: 1. The Librarian enters details of the fine into the system. 2. The system prints out the fine. Segment 1 postconditions: 1. The fine has been recorded in the system. 2. The system has printed out the fine. Extension use cases have one or more insertion segments which are behaviour fragments that will be inserted at the specified extension points in the base use case Clear View Training 2010 v2.6 85

86 5.5.2 the first segment in IssueFine is inserted at overduebook and the second segment at payfine Multiple insertion points Extension Use case: IssueFine «extend» (overduebook, payfine) ReturnBook extension points overduebook payfine IssueFine If more than one extension point is specified in the «extend» relationship then the extension use case must have the same number of insertion segments ID: 10 Brief description: Segment 1: The Librarian records and prints out a fine. Segment 2: The Librarian accepts payment for a fine. Primary actors: Librarian Secondary actors: None. Segment 1 preconditions: 1. The returned book is overdue. Segment 1 flow: 1. The Librarian enters details of the fine into the system. 2. The system prints out the fine. Segment 1 postconditions: 1. The fine has been recorded in the system. 2. The system has printed out the fine. Segment 2 preconditions: 1. A fine is due from the borrower. Segment 2 flow: 1. The Librarian accepts payment for the fine from the borrower. 2. The Librarian enters the paid fine in the system. 3. The system prints out a receipt for the paid fine. Segment 2 postconditions: 1. The fine is recorded as paid. 2. The system has printed a receipt for the fine. Clear View Training 2010 v2.6 86

87 5.5.3 Conditional extensions ReturnBook extension points overduebook payfine «extend» (overduebook) [first offence] IssueWarning IssueFine «extend» (overduebook) [!first offence] condition We can specify conditions on «extend» relationships Conditions are Boolean expressions The insertion is made if and only if the condition evaluates to true Clear View Training 2010 v2.6 87