Conceptual Model Analysis: Use Case for Buying Items in a POS System

1. Tuesday 09/14/99 Revised: September 11, 2000 (APM) Analysis

2. Use Case - Buy Item Version 1 Use Case: Buy Items - version 1 Actors: Customer, Cashier Purpose: Capture a sale and its cash payment Overview: A customer arrives at a checkout with items to purchase. The cashier records the purchase items and collects a cash payment. On completion the customer leaves with the items. Type: Primary Typical course of Events (please refer to page 79 T1)

3. Building a conceptual model • Objectives • identify concepts related to current development cycle requirements • create initial conceptual model • distinguish between correct and incorrect attributes • add specification concepts

4. Conceptual model • Illustrates meaningful concepts in a problem domain • the most important artifact to create during OO analysis • usually expressed in the form of static diagrams (in Rational this implies a high-level class diagram) • is a representation of real-world things; not software components • no operations are defined in conceptual model • should show concepts, associations between concepts,attributes of concepts

5. Partial conceptual model No responsibilities or methods

6. Concepts - definition • Concept - an idea, thing or object • Primary distinction of object oriented analysis - division by concepts rather than division by functions

7. Concepts in POS domain • Store, POST, Sale • better to over specify the conceptual model than to under specify • it is common to miss some in the initial phase; discover them later • finding concepts using the concept category list (refer to page 91, UML) • finding concepts using Noun Phrase identification - example in Buy Items version 1 - sales transaction

8. Candidate concepts POS domain • POST • Item • Sale • Store • Payment • SalesLineItem • ProductCatalog

9. Report Objects - Include? • Receipt - record of a sale and payment; important concept in the problem domain • Should it be included in the model? • Some factors to consider: • receipt is a record of a sale - generally not useful, since all its information is derived from other sources • receipt has a special role in terms of the business - the buyer is entitled to a receipt of the sale • So how do we make a decision?

10. POS Conceptual Model

11. Conceptual Modeling Guidelines • List the candidate concepts using the concept category list • add associations necessary to record the relationships for which there is a need to preserve some memory • add the attributes necessary • Use the mapmaker strategy (leave irrelevant features, name using the business terms, UML page 96) • if a thing X cannot be thought of either number or text, then X is probably a concept (example, destination airport) • if in doubt, make it a concept (hmm)

12. Specification Concepts • When are they needed? • Add a specification concept when: • deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained • it reduces redundant or duplicated information

13. Specification Example • Assume the following • an item instance represents a physical item in the store; as such it has a serial number • an item has a description, price and UPC which are not recorded anywhere else • every time a real physical item is sold, a corresponding software instance of item is deleted from the database • With these assumptions, what happens when the store sells out of a specific item like “burgers”? How does one find out how much does the “burger” cost? • Notice that the price is stored with the inventoried instances

14. Specification Example - Contd • Also notice the data is duplicated many times with each instance of the item • This example illustrates the need for a concept of objects that are specifications or descriptions of other things (often called a Proxy or Surrogate) • Description or specification objects are strongly related to the things they describe.

15. Specification - Example

16. UML definitions • Class - a description of a set of objects that share the same attributes, operations, methods, relationships and semantics • operation - a service that can requested from an object to effect behavior

17. Conceptual Models - Association • Objective • Identify associations for a conceptual model • distinguish between need-to-know associations from comprehension-only associations

18. Associations • Association - a relationship between concepts that indicates some meaningful and interesting connection Association

19. Finding Associations • Refer to page 108 (larman) • High priority associations • A is a physical or logical part of B • A is physically or logically contained in/on B • A is recorded in B • Finding concepts is much more important than finding associations. The majority of time spent in conceptual model creation should be devoted to identifying concepts, not associations

20. Association Guidelines • Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (need-to-know associations) • more important to identify concepts than associations • too many associations tend to confuse the conceptual model • avoid showing redundant or derivable associations

21. Roles in Associations • Each end of an association is called a role. Roles have • name • multiplicity expression • navigability

22. Multiplicity • Multiplicity defines how many instances of type A can be associated with one instance of type B at a particular moment in time Multiplicity of the role

23. Association - Multiplicity • Multiplicity: indicates the number of objects of one class the may be related to a single object of an associated class • can be one of the following types • 1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n

24. Associations - Contd. Associations are generally read left to right, top to bottom

25. Associations - Contd. Multiple associations between two types During analysis phase, an association is not a statement about data flows, instance variables, or object connections in the software solution

26. Point of Sale Association • Refer to pages 113 - 117

27. Conceptual Model - Attributes • Objectives • identify attributes in a conceptual model • distinguish between correct and incorrect attributes

28. Attributes • Attribute - is a logical data value of an object • Include the following attributes in a conceptual model • those for which the requirements suggest or imply a need to remember information • For example, a sale receipt normally includes a date and time attribute

29. Attributes Attribute: Named property of a class describing values held by each object of the class Attribute Type: A specification of the external behavior and/or the implementation of the attribute Attribute Name:attribute Type

30. Attributes • Attributes in a conceptual model should preferably be simple attributes or pure data values • Very common simple attribute types include • boolean, date, number, string, time

31. Attributes worse better Relate with associations, not attributes, in conceptual model

32. Complex Attributes • Pure data values - expressed as attributes; they do not illustrate specific behaviors; • Example - Phone number • A Person can have many Phone numbers • Non-primitive attribute types • represent attributes as non-primitive types (concepts or objects) if • it is composed of separate sections (name of a person) • there are operations associated with it such as validation • it is a quantity with a unit (payment has a unit of currency)

33. Complex Attributes • It is desirable to show non-primitive attributes as concepts in a conceptual model

34. Attributes for the POS system • Refer to page 126 - 129 T1

35. Recording terms in Glossary • Define all terms that need clarification in a glossary or model dictionary (refer to T2 glossary, T1 page 131)

36. System Behavior • Objective • identify system events and system operations • create system sequence diagrams for use cases

37. System sequence diagram • A system sequence diagram illustrates events from actors to systems • UML notation - sequence diagram • This activity occurs during the analysis phase of a development cycle; dependent on the creation of the use cases and identification of concepts

38. Sequence diagram • Use cases suggest how actors interact with the software system • an actor generates events to a system, requesting some operation in response • Example - when a cashier enters an item’s UPC, the cashier requests the POST system to record that item purchase. That request event initiates an operation upon the system • desirable to isolate and illustrate the operations that an actor requests of a system

39. Sequence Diagram • Shows for a particular scenario of a use case, the events that external actors generate, their order and inter-system events • A scenario of a use case is a particular instance or realized path • should be done for a typical course of events of the use case (usually for the most interesting ones)

40. Sequence Diagram - POS • Refer to page 138 T1 for an example of a system sequence diagram. • Note that the System Sequence Diagram is different from the Collaboration Diagrams that are described later with design.

41. System Events, Operations • System event - external input event generated by an actor • system operation - operation of the system that executes in response

42. Recording System operations • Set of all required systems operations is determined by identifying the system events • Examples: enterItem(UPC,quantity); endSale(); makePayment(amount) • UML notation - Operation(arg:ArgType=defaultvalue,,,):ReturnType(s)

43. System behavior - Contracts • Objective • create contracts for system operations

44. System behavior - contracts • Help define system behavior • describe the effect of operation(s) on the system • UML notation - pre and post conditions of operations • contracts are useful documentation of the system behavior in terms of what a system’s state changes are when a system operation is invoked

45. Contracts - Example • Refer to page 148