Systems Analysis and Design I Session 4 Use case models and requirement analysis

Recap Models and diagrams Activity Diagrams Requirements Capture Section 5.2 (pp. 114 – 122), Section 7.2 (pp. 181 – 184) Activity Diagrams Section 5.3 (pp. 122 – 128) Requirements Capture Section 6.2 (pp. 138 – 142) Section 12.5.3 (pp. 360) Section 21.4.2 (p. 622 – 623) , Section 6.3 (pp. 142 – 150) Information technology is the machinery that makes an IS work

Today Use Case Models Requirements Analysis Use Case Modelling: Section 6.6 – 6.6.2 (pp. 154 – 159); Prototyping: Section 3.3.2 (pp. 73 – 76), Section 6.6.3 (pp. 159 – 161) Requirements Analysis Class Diagrams: Section 7.3 (pp. 184 – 194), Section 7.5.5 – 7.5.10 (pp. 208 – 215), Section 7.5.2 (pp. 198 – 201)

Use Case Models Use Case Modelling Prototyping Section 6.6 – 6.6.2 (pp. 154 – 159) Prototyping Section 3.3.2 (pp. 73 – 76) Section 6.6.3 (pp. 159 – 161)

Use Cases Use Cases – descriptions of the functionality of the system from the users’ perspective. Use Case diagrams show which users will communicate with the system define the scope of the system Use Case descriptions specify the interaction between the users (actors) and the system for each use case as the users see it could be further elaborated by communication/sequence diagrams. Shortcoming: focus on the functionality of the system, not good for non-functional requirements What are the key activities that make this business work? 5 5

System or subsystem boundary Use Case Diagrams Four aspects: actors use cases Communication association system/subsystem boundary System or subsystem boundary Actor Use case Communication association Staff Contact Change a client contact 6 6

Use Case Diagrams: Actor Describe the role that people, other systems or devices take when communicating with a particular use case not the same as job title or a specific person one job title may play the roles of several actors one actor may represent several job titles Drawn as a stick figure with a name Note: they are not necessarily human users of the system (may be other systems: computer, automated machinery/equipment) Staff Contact Lecturer Taolue Chen Role: Admission Tutor Professor Mark Levene Role: Research Tutor 7 7

Use Case Diagrams: Use Case Describe a sequence of actions that the system performs to achieve an observable result of value to an actor Drawn as a bubble (ellipse) with a name in or below the name is usually an active verb and a noun phrase Change a client contact 8 8

Use Case Diagrams: Communication Association Describes the communication link between an instance of the use case and an instance of the actor Drawn as a line between the actor and the use case Change a client contact Staff Contact 9 9

Use Case Diagrams: Sub-system drawn as a rectangle around a group of use cases that belong to the same sub-system Change a client contact When use cases for different sub-system are placed in separate use case diagrams, such rectangles are redundant 10 10

Extend and Include relationships Use Case Diagrams: Extend and Include relationships The extend and include relationships between Use Cases shown as stereotyped dependencies [a stereotype is a special use of a model element that is constrained to behave in a particular way] Stereotype are shown by using a keywork in match guillemets «extend» and «include» (text strings in guillemets) Warning: easy to confuse extend and include! Dependencies Extend and Include relationships between use cases shown as stereotyped dependencies stereotypes are written as text strings in guillemets: «extend» and «include» 11 11

Use Case Diagrams: «extend» Extend means: One use case provides additional functionality that may be required in another use case “does something over and above what is done” There may be multiple ways of extending a use case represent variations in the way that actors interact with the use case Rather than capturing all variations in one use case, document the core functionality in one and then extend it with other The extension points show when the extension occurs A condition can be placed in a note joined to the dependency arrow 12 12

Use Case Diagrams: «extend» Campaign Manager Check campaign budget summary «extend» Print campaign Summary print extension points Condition {print option selected} extension point: Summary print Note: is not put in square brackets, unlike conditions in other diagrams.) Fig. 6.7 13 13

Use Case Diagrams: «include» When there is a sequence of behaviour that is used frequently in a number of use cases Want to avoid copying the same description everywhere separate out the sequence of behaviour that is used in many use cases One use case includes the functionality of another use case A use case may include more than one other Do not overuse: Should not be used to create a hierarchical functional decomposition of the system 14 14

Assign staff to work on a campaign Use Case Diagrams: «include» Campaign Manager «include» Find campaign Assign staff to work on a campaign Fig 6.8 15 15

Note: you do not need to show all the details of the extension points

Use Case Diagrams: Generalisation Between use cases: there may be similar use cases with common functionality best represented by generalising out that functionality in to a “super-use-case” shows that one use case provides all the functionality of the more generalised use case and some additional functionality Between actors: shows that one actor can participate in all the associations with use cases the more specific actor can plus some additional use cases 17 17

Use Case Diagrams: Generalisation Record completion of an advert Staff Contact Change a client contact Fig. 6.10 Super use case Assign individual staff to work on a campaign Assign staff to work on a campaign Assign team of staff to work on a campaign Campaign Manager 18 18

Use Case Diagrams: Exercise Vending machine 19

Assign staff to work on a campaign Use Case Descriptions Using a simple paragraph (very brief) Assign staff to work on a campaign The campaign manager wishes to record which staff are working on a particular campaign. This information is used to validate timesheets and to calculate staff year- end bonuses. Assign staff to work on a campaign Campaign Manager 20 20

Use Case Descriptions Using a step-by-step breakdown of interaction between actor and system Assign staff to work on a campaign Actor Action System Response 1. The actor enters the client name. 2. Lists all campaigns for that client. 3. Selects the relevant campaign. 4. Displays a list of all staff members not already allocated to this campaign. 5. Highlights the staff members 6.Presents a message confirming to be assigned to this campaign. that staff have been allocated. Alternative Courses Steps 1–3. The actor knows the campaign name and enters it directly. scenario Referred to as scenario 21 21

Use Case Descriptions Using a template (a blank form to be filled in) name of use case pre-conditions post-conditions purpose description alternative courses (routes) errors 22 22

Use Case Descriptions Use Case Description Examples Record employee leaving the line Normally employees are recorded as leaving the line when they clock off at the end of a working shift. Although there are breaks in the operation of the line during a shift (e.g., lunch breaks and downtime due to faults), when this happens employees are not normally recorded as leaving the line. In all circumstances, date, time and location are recorded. Stop line When the production line stops for a routine reason, e.g., for a break, to restock or to reload equipment, the line supervisor records the time the run stopped and the reason. 23 23

Supporting Use cases: Prototyping Why? Users find difficult to imagine how requirements will be translated into a working system Overcome many of the potential misunderstandings and ambiguities that may exist in the requirements A prototype is a system or a partially complete system that is built quickly to explore some aspects of the system requirements and that is not intended as the final working system. Prototyping can be used to support use case modelling Help elicit functional requirements Test out system architectures based on the use cases in order to meet the non- functional requirements 24 24

Prototyping Focus on HCI What data should be presented to/captured from users Investigate the most suitable form of interface Determine whether a particular implementation platform can support certain processing req Determine the efficacy of a particular language/DBMS Perform an initial analysis. All software development activity utilizes valuable re­sources. Embarking upon a prototyping exercise without some initial analysis is likely to result in an ill-focused and unstructured activity producing poorly designed software. Define prototype objectives. Prototyping should have clearly stated objectives. A proto­typing exercise may involve many iterations, each iteration resulting in some improv­ement to the prototype. This may make it difficult for the participants in a prototyping exercise to determine if there is sufficient value to continue the prototyping. However, with clearly defined objectives it should be possible to decide if they have been achieved. Specify prototype. Although the prototype is not intended for extended operation it is important that it embodies the requisite behaviour. It is almost certainly the case that the proto­type will be subject to modification and this will be easier if the software is built according to sound design principles. Construct prototype. Since it is important that prototype development is rapid, the use of a rapid development environment is appropriate. For example, if an interactive system is being prototyped, environments such as DelphiTM or Visual Basic® can be most effective. Evaluate prototype and recommend changes. The purpose of the prototype is to test or explore some aspect of the proposed system. The prototype should be evaluated with respect to the objectives identified at the beginning of the exercise. If the objectives have not been met then the evaluation should specify modifications to the prototype so that it may achieve its objectives. The last three stages are repeated until the objectives of the prototyping exercise are achieved. 25 25

Prototyping: pros and cons Early demonstrations of system functionality help identify any misunderstandings between developer and client Missed client requirements can be identified Difficulties in the interface can be identified The feasibility and usefulness of the system can be tested, even though, by its very nature, the prototype is incomplete The client may perceive the prototype as part of the final system The prototype may divert attention from functional to solely interface issues Prototyping requires significant user involvement Managing the prototyping life cycle requires careful decision making 26 26

User selects Client Campaigns listed. User Interface prototypes For user interface prototypes, storyboarding can be used with hand-drawn designs User interface prototypes can be implemented using languages other than the one that the system will be developed in. Dialogue initialised. User selects Client Campaigns listed. User selects Campaign. 27 27

Take Home Messages Use Case Modelling Prototyping Use Case Diagrams Use Case Descriptions Prototyping In this lecture you have learned about … 28 28

Requirements Analysis Class Diagrams Section 7.3 (pp. 184 – 194) Section 7.5.5 – 7.5.10 (pp. 208 – 215) Section 7.5.2 (pp. 198 – 201)

Class Diagrams Class (and Object/Instance) Stereotypes Attributes (and State) Associations (and Links) Multiplicity Operations Symbols of Instances, States, and Links are used in other UML diagram types (Object Diagrams, Communication Diagrams, etc.) 30 30

Notation: Class class name compartment attributes compartment Client companyAddress companyEmail companyFax companyName companyTelephone class name compartment attributes compartment operations compartment 31 31

companyAddress=Evans Farm, Norfolk Notation: Object/Instance :Client Anonymous instance object name compartment FoodCo:Client companyAddress=Evans Farm, Norfolk companyEmail=mail@foodco.com attribute values companyFax=01589-008636 companyName=FoodCo companyTelephone=01589-008638 instances do not have operations 32 32

Attributes Attributes are: part of the essential description of a class the common structure of what all objects of the class can ‘know’ each object has its own value for each attribute of its class attribute values characterise state of the object Campaign actualCost campaignFinishDate campaignStartDate completionDate datePaid estimatedCost title checkCampaignBudget ( ) getCampaignContribution ( ) recordPayment ( ) setCompleted ( ) 33 33

Links a link is a logical connection between two objects FoodCo:Client Yellow Partridge:Client Soong Motor Co:Client Grace Chia:StaffMember Carlos Moncada:StaffMember a link is a logical connection between two objects Note: A link can also connect instances of the same class 34 34

Associations An association is an abstraction that connects two classes represents the possibility of links (logical relationship or connection) between objects of one class and objects of another If two objects can be linked, their classes have an association Class describes a set of similar objects Association describes a set of similar links 35 35

Notation: Associations association role Client StaffMember companyAddress staffContact staffName companyEmail staffNo liaises with companyFax staffStartDate companyName Only staff members in the role of staff contact can participate in this association companyTelephone association name direction in which name should be read (optional) Only staff members in the role of staffContact can participate in this association 36 36

Association End association role Professor "playing the role" of author is associated with textbook end typed as Book. The idea of the role is that the same class can play the same or different roles in other associations. For example, Professor could be an author of some Books or an editor.

Multiplicity The multiplicity of an association is the range of permitted cardinalities of its participating objects (i.e., #objects that can participate in the association) Decided by business rules. for example: any bank customer may have one or more accounts every individual account is for one, and only one, customer n: exactly n *: any number m..n: any number in the range m to n (inclusive) 0..1: optional (i.e., either none or 1) 1..*: at least one 38 38

Notation: Multiplicity StaffMember staffName staffNo staffStartDate Client companyAddress companyEmail companyFax companyName companyTelephone 1 0..* liaises with multiplicities A staff member may liaise with any number of clients (including 0) Each client is liaised with exactly one staff member 39 39

Multiplicity: more examples (p. 191)

Operations Operations are: part of the essential description of a class the common behaviour that all objects of the class can ‘do’ get or set attribute values (not specified in Analysis Model) perform calculations send messages to other objects create or destroy links (not specified in Analysis Model) services that objects of a class can provide to other objects Campaign actualCost campaignFinishDate campaignStartDate completionDate datePaid estimatedCost title checkCampaignBudget ( ) getCampaignContribution ( ) recordPayment ( ) setCompleted ( ) 41 41

Static Analysis with UML Requirements Model → Analysis Model → Design Model To Draw an Analysis Class Diagram Identify Classes Determine Stereotypes (particular classes that will occur again and again) Find and Locate Attributes Add Associations Determine Multiplicity Find and Locate Operations Section 7.5 p 197 42 42

Looking for Potential Classes Category Examples People Mr Harmsworth (a campaign manager), Dilip (a copywriter). Organisations Jones & Co (a forklift truck distributor), the Soong Motor Company, Agate’s Creative Department. Structures Team, project, campaign, assembly. Physical things Fork-lift truck, electric drill, tube of toothpaste. Abstractions of people Employee, supervisor, customer, client. Abstractions of physical things Wheeled vehicle, hand tool, retail goods. Conceptual things Campaign, employee, rule, team, project, customer, qualification. Enduring relationships between members of other categories. Sale, purchase, contract, campaign, agreement, assembly, employment. 43 43

Identifying Classes Should this really be considered as a class? Is it beyond the scope of the system? Does it refer to the system as a whole? Does it duplicate another class? Is it too vague? Is it too specific? Is it too tied up with physical inputs and outputs? Is it really an attribute? Is it really an operation? Is it really an association? If any answer is ‘Yes’, consider modelling the potential class in some other way (or do not model it at all). 44 44

Take Home Messages Class Diagrams Class (and Object/Instance) Attributes (and State) Associations (and Links) Multiplicity Operations In this lecture you have learned about … 45 45