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

2. 6/8/992 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. 6/8/993 Building a conceptual model 4 Objectives –identify concepts related to current development cycle requirements –create initial conceptual model –distinguish between correct and incorrect attributes –add specification concepts

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

5. 6/8/995 Partial conceptual model No responsibilities or methods

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

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

8. 6/8/998 Candidate concepts POS domain 4 POST 4 Item 4 Sale 4 Store 4 Payment 4 SalesLineItem 4 ProductCatalog

9. 6/8/999 Report Objects - Include? 4 Receipt - record of a sale and payment; important concept in the problem domain 4 Should it be included in the model? 4 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. 6/8/9910 POS Conceptual Model

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

12. 6/8/9912 Specification Concepts 4 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. 6/8/9913 Specification Example 4 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 4 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? 4 Notice that the price is stored with the inventoried instances

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

15. 6/8/9915 Specification - Example

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

17. 6/8/9917 Conceptual Models - Association 4 Objective –Identify associations for a conceptual model –distinguish between need-to-know associations from comprehension-only associations

18. 6/8/9918 Associations 4 Association - a relationship between concepts that indicates some meaningful and interesting connection Association

19. 6/8/9919 Finding Associations 4 Refer to page 108 (larman) 4 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 4 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. 6/8/9920 Association Guidelines 4 Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (need- to-know associations) 4 more important to identify concepts than associations 4 too many associations tend to confuse the conceptual model 4 avoid showing redundant or derivable associations

21. 6/8/9921 Roles in Associations 4 Each end of an association is called a role. Roles have –name –multiplicity expression –navigability

22. 6/8/9922 Multiplicity 4 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. 6/8/9923 Association - Multiplicity 4 Multiplicity: indicates the number of objects of one class the may be related to a single object of an associated class 4 can be one of the following types –1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n

24. 6/8/9924 Associations - Contd. Associations are generally read left to right, top to bottom

25. 6/8/9925 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. 6/8/9926 Point of Sale Association 4 Refer to pages 113 - 117

27. 6/8/9927 Conceptual Model - Attributes 4 Objectives –identify attributes in a conceptual model –distinguish between correct and incorrect attributes

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

29. 6/8/9929 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. 6/8/9930 Attributes 4 Attributes in a conceptual model should preferably be simple attributes or pure data values 4 Very common simple attribute types include –boolean, date, number, string, time

31. 6/8/9931 Attributes worse better Relate with associations, not attributes, in conceptual model

32. 6/8/9932 Complex Attributes 4 Pure data values - expressed as attributes; they do not illustrate specific behaviors; –Example - Phone number –A Person can have many Phone numbers 4 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. 6/8/9933 Complex Attributes 4 It is desirable to show non-primitive attributes as concepts in a conceptual model

34. 6/8/9934 Attributes for the POS system 4 Refer to page 126 - 129 T1

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

36. 6/8/9936 System Behavior 4 Objective –identify system events and system operations –create system sequence diagrams for use cases

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

38. 6/8/9938 Sequence diagram 4 Use cases suggest how actors interact with the software system 4 an actor generates events to a system, requesting some operation in response 4 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 4 desirable to isolate and illustrate the operations that an actor requests of a system

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

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

41. 6/8/9941 System Events, Operations 4 System event - external input event generated by an actor 4 system operation - operation of the system that executes in response

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

43. 6/8/9943 System behavior - Contracts 4 Objective –create contracts for system operations

44. 6/8/9944 System behavior - contracts 4 Help define system behavior 4 describe the effect of operation(s) on the system 4 UML notation - pre and post conditions of operations 4 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. 6/8/9945 Contracts - Example 4 Refer to page 148