From use cases to classes in UML A

From use cases to classes (in UML)

A use case for writing use cases Use case: writing a use case Actors: analyst, client(s) Client identifies and write down all the actors. Analyst writes down all the actors. Client identifies the use cases, i. e. , goals that actors can achieve step by step. Analyst draws a use case diagram documenting the relationships between the actors and use cases. Analyst describes main scenario for a use case, step by step. Analyst describes any alternatives to the main case. Analyst reviews the use case with client to make sure it is understandable and correct. Alternative: Refine use case 7 a. If client may request changes then go to relevant step above

Exercise I am the manager of a theatre. I want to create an automated movie ticket machine. You are analysts who need to describe what the customer wants as a set of use cases Simplifying assumptions: n n One movie showing at a time Movie time is same every day, only one time, same price Only manager can change/add movie Customer can only buy tickets Who or what are the actors? What are the use cases (goals of actors)?

Use case diagram for Movie Ticket Machine Why are there three Actors? Why three use cases for Customer? Which use cases look easy to write?

Use cases for Manager Use case: Set title Actors: Manager, Machine 1. Manager requests a change of movie title 2. Machine asks manager for new movie title 3. Manager enters movie title Use case: Set price Actors: Manager, Machine 1. Manager requests a change of ticket price 2. Machine asks manager for new price for movie title 3. Manager enters ticket price Alternatives: Invalid price If manager enters price below $1 or greater than $10 3 a. Machine asks manager to reenter price Use case: Set seats Actors: Manager, Machine 1. Manager requests a change in number of seats 2. Machine asks manager for number of seats in theatre 3. Manager enters number of seats Alternatives: Invalid number of seats If manager enters number less than 20 or greater than 999 3 a. Machine asks manager to reenter number of seats

Use cases for Customer Use case: # of tickets Actors: Customer, Machine 1. Customer enters number of tickets 2. Machine displays total balance due Alternative: Customer wants zero tickets At step 1, customer enters zero tickets 1 a. Display thank you message 1 b. Set balance to $0. 0 Use case: Return change to customer Actors: Customer, Machine 1. Customer requests change 2. Machine dispenses money 3. Machine updates customer balance Use case: Buy tickets Actors: Customer, Machine 1. Customer requests tickets 2. Machine tells customer to put balance due in money slot 3. Customer enters money in money slot 4. Machine updates customer balance 5. Customer requests tickets 6. Machine prints tickets 7. Machine updates number of seats Alternative: Insufficient seats At step 1, if number of tickets requested is less than available seats, 1 a. Display message and end use case Alternative: Insufficient funds At step 5, if money entered < total cost, 5 a. Display insufficient amount entered 5 b. Go to step 3

Domain analysis So far we’ve looked at requirements analysis— understanding what the customer wants. Domain analysis understands the customer’s problem— by identifying the classes comprising a problem domain. Booch: "an attempt to identify the objects, operations, and relationships [that] domain experts perceive to be important about the domain. “ Result of OO analysis is a UML class diagram modeling the concepts and relationships in problem domain. Separation of concerns principle: Keep problem domain model distinct from user interface or database modeling. Why?

Identifying classes is category‑formation Objects simulate a slice of the world which a computer system models Why are objects are a natural construct for simulation? n Classes of objects are a natural way to organize classes n Infants learn to recognize objects and how to categorize them in their first few months n A key insight of the child psychologist Piaget and cognitive science n Adults rely on categorization to understand the world n We create new categories all the time. Examples? n New makes of cars, new technological gadgets, new courses and curricula…. Natural categories, can be hard to define precisely n Natural kinds: how do you define an elephant? a game? n Prototypes: people see how close objects match a prototypical member of a category n Why is the fuzziness of natural kinds a problem for OOSE? n It's hard to be precise about defining categories That's why we need methodology for OO analysis and design

Candidates for classes Tangible things referred to by common nouns in requirements spec n I. e. , cookie, factory, triangle Events with associated information (i. e. , flight, game). Abstract data stores (i. e. , buffer, tree, hash table) External interface ports (i. e. , terminal, printer, window, menu) Complex processes or operations (i. e. , sort, edit command) Note: verbs can also be classes! n n Especially processes than store state information Parsing -> Parser, Scanner as a subclass of String Can anything be a class? What isn't a class? n n n Indeed, category‑formation is a fundamental human activity Proper nouns are instances of classes, not classes Classes have content: store state information and perform operations If it doesn’t store state and perform multiple operations, keep it simple Classes with just one or two routines (probably not worth classifying) Redundant classes: merge synonyms, reuse classes in libraries

Defining terms Why is defining a glossary of terms especially helpful to OO analysis? Brief dictionary‑like definitions describe how the term is used in domain Terms can help with the discovery of classes and their structure Maintain glossary files throughout development, finally as documentation

From use cases to classes 1. Identify classes of objects in the problem description Heuristic: nouns may be classes But: verbs can be nominalized (iterate->iteration, withdraw->withdrawal) Heuristic: does it store state (does it have attributes) and does it have operations? 2. Identify attributes of each class: What characteristics are important to keep track of? What data must be maintained or remembered during object’s life? 3. Identify methods of each class: What actions must the object be able to perform? What actions can be done to the object (e. g. , to change its state)? Use cases may correspond to methods 4. Identify parameters and return types of methods: What input does a method need from caller? These are parameters. Does the method generate a result value? The return type must match the data type of data to be returned.