1. 9/18/011 Software Requirements Analysis and Design (Continued)

2. 9/18/012 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 Larman)

3. 9/18/013 System Behavior 4 Objective –identify system events and system operations –create system sequence diagrams for use cases

4. 9/18/014 System sequence diagram-Example :Cashier :System makeNewsale() endSale() Description, total [* more items] enterItem(itemID, quantity) total with taxes makePayment(amount) change due, receipt Box to enclose an iteration area.

5. 9/18/015 System sequence diagram [1] 4 A system sequence diagram illustrates events from actors to systems and the external response of the system. 4 This activity occurs during the analysis phase of a development cycle; dependent on the creation of the use cases and identification of concepts. 4 UML notation - Sequence Diagram not System Sequence Diagram. 4 One diagram depicts one scenario. This is the main success scenario. 4 Frequent or complex alternate scenarios could also be illustrated. 4 A system is treated as a black box. 4 SSD is often accompanied by a textual description of the scenario to the left of the diagram.

6. 9/18/016 System sequence diagram [2] 4 Identify the system boundary…what is inside and what is outside. 4 System event: An external event that directly stimulates the (software) system. 4 Events are initiated by actors. 4 Name an event at the level of intent and not using their physical input medium or interface widgets. –enterItem() is better than scan(). 4 Keep the system response at an abstract level. –description, total is preferred over display description and total on the POS screen.

7. 9/18/017 Conceptual (or Domain) model [1] 4 Illustrates meaningful concepts in the problem domain. 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 (of the system under development). 4 No operations are defined or specified in the conceptual model. 4 Should show concepts, associations between concepts, and attributes of concepts. 4 Serves as a source of software objects.

8. 9/18/018 Conceptual model [2] 4 Objectives –identify concepts related to current development cycle requirements –create initial conceptual model –Identify attributed –add specification concepts

9. 9/18/019 Partial domain model of POS Concept 1 0..1 1..* Records-sale-of Contained-in Sale date time 11 Attributes Sales LineItem quantity Item Store address name 1 Stocked-in Register Houses 1 1..* Captured-on 1 1

10. 9/18/0110 Finding concepts [1] 4 Finding concepts using Noun Phrase identification in the textual description of the domain. 4 Finding concepts using the concept category list (refer to page p134 in Larman): –Physical objects: register, airplane, blood pressure monitor –Places: airport, hospital –Catalogs: Product Catalog

11. 9/18/0111 Finding concepts [2] 4 Examine use case descriptions. 4 Example: Process Sale use case: –Main success scenario: Customer arrives at a POS checkout counter. Cashier starts a new sale. Cashier enters an item ID. System records sale line item. It then presents a description of the item, its price, and a running total. …. 4 Possible source of confusion: Is it an attribute or a concept? If X is not a number or a text then it probably is a conceptual class.

12. 9/18/0112 Finding concepts [3] Concepts from “Unreal” world ? Message Connection Port Use terms familiar to those in the problem domain. POST or register? Are these concepts or attributes: Store Flight Price

13. 9/18/0113 Concepts in POS domain 4 POST 4 Item 4 Sale 4 Store 4 Payment 4 SalesLineItem 4 ProductCatalog

14. 9/18/0114 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

15. 9/18/0115 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

16. 9/18/0116 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.

17. 9/18/0117 Specification - Example ProductDesciption description price UPC Item Serial Number *1 describes *1 Item Serial Number description Price itemID Which of these two is a better choice of concepts?

18. 9/18/0118 Conceptual Models - Association 4 Objective –Identify associations for a conceptual model –distinguish between need-to-know associations from comprehension-only associations

19. 9/18/0119 Associations 4 Association - a relationship between concepts that indicates some meaningful and interesting connection Association

20. 9/18/0120 Finding Associations 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 Other associations –A uses or manages or controls B (Pilot -airplane) –A owns B (Airline -airplane)

21. 9/18/0121 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

22. 9/18/0122 Roles in Associations 4 Each of the two ends of an association is called a role. Roles have –name –multiplicity expression –navigability

23. 9/18/0123 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

24. 9/18/0124 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

25. 9/18/0125 Associations - Contd. Associations are generally read left to right, top to bottom

26. 9/18/0126 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.

27. 9/18/0127 Conceptual Model - Attributes 4 Objectives –identify attributes in a conceptual model –distinguish between correct and incorrect attributes

28. 9/18/0128 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. 9/18/0129 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. 9/18/0130 Attributes 4 Attributes in a conceptual model should preferably be simple attributes or pure data values 4 Common simple attribute types include –boolean, date, number, string, time

31. 9/18/0131 Attributes worse better Relate with associations, not attributes, in conceptual model Cashier name currentPost not a "simple" Cashier name POST number 1 1 uses 1

32. 9/18/0132 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. 9/18/0133 Complex Attributes 4 It is desirable to show non-primitive attributes as concepts in a conceptual model Product specification UPC 11 *

34. 9/18/0134 Recording terms in Glossary 4 Define all terms that need clarification in a glossary or model dictionary.

35. 9/18/0135 System Sequence diagram [1] 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

36. 9/18/0136 System Sequence Diagram [2] 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)

37. 9/18/0137 System Events, Operations 4 System event - external input event generated by an actor 4 system operation - operation of the system that executes in response

38. 9/18/0138 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)

39. 9/18/0139 Contracts 4 A contract describes detailed system behavior in terms of state changes to objects in the domain model. 4 A contract is a system operation. It is offered in the system’s public interface. 4 Note that one use case may require one or more system operations (events) to complete a scenario.

40. 9/18/0140 Contract: Example 4 Operation: enterItem(itemID: ItemID, quantity: integer) 4 Cross References: Use case: Process sale 4 Preconditions: There is a sale underway. 4 Postconditions: A salesLineItem instance, sli, was created. sli was associated with the current Sale. sli.qty becomes quantity (attribute modification). sli was associated with ProductSpecification based on itemID match.

41. 9/18/0141 Artifacts of Analysis