Last lecture What is a Use Case

Last lecture

What is a Use Case l Use cases are stories (scenarios) of how actors use (interact with) the system to fulfill his goal. • Examples • Process sale • Place Order • Loan book

How to document use cases ? l Verbal description o Describes the content of each use case o Typically uses a pre-defined template l Use Case diagrams o Give an overview of visible use scenarios in the system o Describes what actors that interact with the system o Describes any linkages between use cases

Defining system´s scope Boundary of the system (1) Actor (2) Use case (3) Linkage between use cases (4)

Who are Actors – stakeholders ? q Three kind of Actors - Stakeholders m Primary actor has user goals fulfilled through using services. (e. g. , the cashier). m Supporting actor provides a service (e. g. , the automated payment authorization service ). Often a computer system, but could be an organization or person (external interfaces) (e. g. : tax calculation ) m Offstage actor has an interest in the behavior of the use case, but is not primary or supporting (e. g. , a government tax agency).

How to find Use Cases ? As a primary actor , what are your goals ? 6 I should be able to ……. .

Use case example – Restaurant case UC 1 : Record Booking § Receptionist enters date of requested reservation; § System displays bookings for that date; § There is a suitable available: Receptionist enters details (customer’s name, phone number, time of booking, number of covers, table number); § System records and displays new booking. 3/18/2018 CPSC-4360 -01, CPSC-5360 -01, Lecture 3 7

Use case diagram- POS system Actor (person) Actor (system) use case

Use case rearrangement: Restaurant case System 3/18/2018 9

Adding a Use Case Extension Book Trip Customer «extend» Customer requests a rental auto Rent Automobile Agent

Cancel Trip Use Case Diagram Cancel Trip Customer «include» Cancel Flight «include» Cancel Hotel Agent

Domain Model Chapter 9 Applying UML and Patterns -Craig Larman

Introduction l Reminder: Use cases are not object-oriented requirement analysis , but they emphasize an activity view (illustrate user activities on the system) l A domain model is the most important and classic-model in Object Oriented Analysis 13

Your attention please 14

What is a Domain Model? l Problem domain : area (scope)of application that needed to be investigated to solve the problem l Domain Model : Illustrates meaningful conceptual objects in problem domain. l So domain model are conceptual objects of the area of application to be inestigated

Domain model representation? l A domain model is a visual representation of real world concepts (real-situation objects ), that could be : idea, thing , event or object…. . etc. ØBusiness objects - represent things that are manipulated in the business e. g. Order. ØReal world objects – things that the business keeps track of e. g. Contact , book. ØEvents that transpire - e. g. sale, loan and payment. l Not of software objects Is part of business Model artifact (document) l

Domain model representation? Domain Model may contain : ØDomain objects (conceptual classes) ØAttributes of domain objects ØAssociations between domain objects ØMultiplicity 17

Domain Model - UML Notation l Illustrated using a set of domain objects (conceptual classes) with no operations ( no responsibility assigned yet , this will be assigned during design). 18

A Domain Model is not a Software document Object responsibilities is not part of the domain model. (But to consider during Design) Sale Date Time Print() Avoid

Symbol, intension and extension. All the examp les of sales c all instan ed ces Fig 9. 5

Question : Why create Domain model ? Answer : Get inspiration to create software classes gn assi ilities We nsib o sign resp g de durin

How to find these conceptual classes and attributes ?

Method 1: Noun Phrase Identification l Identify Nouns and Noun Phrases in textual descriptions of the domain that could be : • The fully dressed Use Cases • The problem definition. But not strictly a mechanical process. Why ? • Words may be ambiguous ( such as : System ) • Different phrases may represent the same concepts. 23

l Main Success Scenario (or Basic Flow): • 1. Customer arrives at POS checkout with goods and/or services to purchase. • 2. Cashier starts a new sale. • 3. Cashier enters item identifier. • 4. System records sale line item and presents item description, price, and running total. • Price calculated from a set of price rules. • Cashier repeats steps 3 -4 until indicates done. • 5. System presents total with taxes calculated. • 6. Cashier tells Customer the total, and asks for payment. • 7. Customer pays and System handles payment. 24

l 8. System logs completed sale and sends sale and payment information to the external accounting system (for accounting and commissions) and Inventory system (to update inventory). l 9. System presents receipt. l 10. Customer leaves with receipt and goods (if any). l Extensions (or alternative Flows) l 7 a. Paying by cash: • 1. Cashier enters the cash amount tendered. • 2. System presents the balance due, and releases the cash drawer. • 3. Cashier deposits cash tendered and returns balance in cash to Customer. • 4. System records the cash payment. 25

Fig. 9. 7 There is no such things as a correct list. Brainstorm what you consider noteworthy to be a candidate. But in general , different modelers will find similar lists. Important :

Identification of conceptual classes • Identify candidate conceptual classes • Go through them and : q Exclude irrelevant features and duplications q Do not add things that are outside the scope ( outside the application area of investigation) 27

Method 2 : By Category List (read p 140 -141) Common Candidates for classes include: • Descriptions , Roles , Places , Transactions • Containers , Systems , abstract nouns , Rules • Organizations, Events, Processes, catalogs , Records , services. 28

When to model Specification/Description Conceptual Classes? Suppose all the items (Object. Burgers) are sold out and then deleted. Someone ask you : How much do Object. Burgers cost ?

How to model Specification/Description • Product. Description is a class that records information about an item • It avoids duplication of recording the descriptive information with each instance of the item.

Attributes l A logical data value of an object. l Imply a need to remember information. l Use case scenarios are examined to discover also attributes • Sale needs a date. Time attributte • Store needs a name and address • Cashier needs an ID 31

Fig. 9. 19

Fig. 9. 20

A Common Mistake when modeling the domain. Classes or Attributes? Rule l If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class. l If it takes up space, then it is likely a conceptual class. Examples: l Is a store an attribute of a Sale ? 34

Represent waht may be considered as primitive data type as a non primitive class if : • • It is composed of separate sections Ø Phone number , name of person There are operations usually associated with it, such as validation Ø Social security number • It has other attributes • It has a quantity with a unit Ø Promotional price could have a strat date and end date Ø Payment of an amount with currency 35

Should the “Item. ID” class be shown as a separate class ? It depends on how the domain model is being used. Item. ID is a ne w its own attribut type with es Fig. 9. 24 Item. ID a types(n re primitive umber, b charac ter, stri oolean, ng…et c)

l Case study : Restaurant part (1) 37

How to find these associations and multiplicities?

Association: Relationship between classes (more precisely, between instances of those classes)indicating some meaningful and interesting connection Fig. 9. 12

Common association list l A is a physical part of B. • l Wing - Airplane A is a logical part of B • Sales. Line. Item - Sale l A physical contained in B • Register-Sale 40

Common association list l A is a logical contained in B • Item. Description - Catalog l A is a description of B. • l A is a member of B • l Item. Description - Item Cashier – Store A uses or manage B • Cashier-Register 41

Common association list l A is recorded in B • Sale. I-Register l A is an organization subunit of B. • l Departement - Store A communicate with B • Customer - Cashier 42

Common association list l A is related to a transaction B • Customer - Payment l A is a transaction related to another transaction B. • l A is owned by B • l Payment - Sale Register - Store A is an event related to B • Sale- Customer 43

High priority association • A is a physical or logical part of B • A is physically or logically contained in/on B • A is recorded in B l NB: • Avoid showing redundant or derivable associations • Do not overwhelm the domain model with associations not strongly required 44

Association or attribute ? q Most attribute type should be “primitive” data type, such as: numbers , string or boolean (true or false) q Attribute should not be a complex domain concept(Sale , Airport) q Current. Register is of type “Register”, so expressed with an association

Association or attribute ? A destination airport is not a string, it is a complex thing that occupies many square kilometers of space. So “Airport” should be related to “Flight” via an association , not with attribute

Multiplicity l “many ” ( 0 or m ore ) Multiplicity indicates how many instances can be validly associated with another instance, at a particular moment, rather than over a span of time. l Example : monogamy

“many” ( 0 or more ) How to determine multiplicity ? l Ask these 2 questions : l 1 store may stock how many item ? l 1 item may be stocked in how many stores ?

How to determine multiplicity ? Person 0. . * works for Association Name 1 Company

Multiplicity

How to create a domain model l l Identify candidate conceptual classes Go through them • Exclude irrelevant features and duplications • Do not add things that are outside the scope Draw them as classes in a UML class diagram Add associations necessary to record the relationship that must be retained Add attributes necessary for information to be preserved

But remember l There is no such thing as a single correct domain model. All models are approximations of the domain we are attempting to understand. l We incrementally evolve a domain model over several iterations on attempts to capture all possible conceptual classes and relationsships.

l Case study : Restaurant part (2) 53