Functional Model for Catalog Ordering System

1. System Functional Model OOSD 담당조교 석사과정 이정환 Kyung Hee University

2. Basic Concept • The most part of software development system projects • Transforming a product description into a software implementation • Initial description of several forms or

3. Basic Concept (cont’d) • System requirements come in several varieties : • Functional requirement • Performance requirement • Minimum robustness of the system • While a system may have performance and robustness requirements, all systems have functional requirements

4. Basic Concept (cont’d) • UML provides two notational conventions for defining a system functional model • Use case diagram (static view) • Activity diagram (dynamic view)

5. A First Functional Model • Problem : creating a catalog ordering system • Customers can place orders for goods and perform various transactions, as follows: • A single order can be for multiple line items. (For example, with a single order a customers can purchase a sweater, a pair of boots, and an umbrella)

6. A First Functional Model (cont’d) • Customers can cancel both entire orders and individual items in orders. Canceling an order entails canceling all items in the order • An item can be canceled if it has not already if it has not already been shipped or previously canceled • Customers can also return items they do not want

7. A First Functional Model (cont’d) • A customer may have any number of orders pending at any time. The DryGoods.com system must generate a unique order number for each order. This number serves as a key the customer can use to identify the order • DryGoods.com maintains an inventory of goods. Order items are allocated from that inventory. When its inventory is exhausted, an item will be back-ordered from a supplier • Customer orders are funded from credit or debit cards. Hence, each order must include a credit or debit card number. DryGoods.com obtains funds from that card when the order is placed

8. A First Functional Model (cont’d) • DryGoods.com ships only complete orders. If one or more items in an order are currently unavailable, the shipment of the other parts of the order will be a delayed until those items become available • The order processing system must also interact with legacy software. DryGoods.com has a product warehouse legacy system that handles inventory management (including ordering goods form suppliers). It also has legacy shipping system that handles shipping (including tracking the progress of the shipment)

9. A First Functional Model (cont’d) • The functional model should provide at least three pieces of information by answering the following questions • What functions does the system offer? • What external agents interact with the system? • In what functions are those external agents involved?

10. A First Functional Model (cont’d) • Actors in the Business View • An actor in UML is anything outside the boundary of the system that interacts with the system in some way. Actors come in many forms. Including • A role played by a human user, such as a customer or sales manager • An external system, legacy system, client application, or component • An external device, such a light sensor or a fault monitor • Modeling actors enables you to see exactly what interacts with the system and how

11. A First Functional Model (cont’d) • Use Cases in the Business View • To model system functions, UML offers the use case. Jacobson adopted this term because a use case describes how an actor uses the system • What interactions with the system does the actor initiate? • What interactions with the actor does the system initiate?

12. A First Functional Model (cont’d) • In the business functional model for DryGoods.com, a Catalog Customer participates in at least five functions and initiates all five: • The placing of an order • The canceling of an order • The canceling of an order item • The returning of an order item • Various queries about orders

13. A First Functional Model (cont’d) • The following are textual specifications of the four use cases : • Place order : the customer places an order for one or more catalog items. The order is entered in the system after it is funded (for example, by a credit card). Each order item is allocated from available inventory, or form back-ordered inventory if no available inventory exists • Cancel order : the customer asks that an order be canceled. Each item in the order that has not already been shipped is canceled and returned and returned to available inventory

14. A First Functional Model (cont’d) • Cancel order item : the customer asks that an individual item in an order be canceled. The item may be canceled only of it has not been shipped; in which case, the item is returned to inventory • Return order item : the customer returns an item that was shipped. The item must be returned to inventory, and the customer must be credited for the return

15. A First Functional Model (cont’d) • A Use Case Diagram of the Business View • System : the system is depicted as a rectangle (possibly with the name of the system inside) • Actor : each actor is shown as a stick figure • Use case : each use case is shown as a solid-bordered oval labeled with the name of use case

16. A First Functional Model (cont’d)

17. A First Functional Model (cont’d) • Use Case Relationships • Use case diagrams can include relationships between actors and use cases • Use case diagram is a static model of functionality. The relationships in it, including relationships between use cases, are static relationships

18. A First Functional Model (cont’d) • The uses relationship • The Figure of Page 16 are related • When a catalog customer cancels an order, the order items in that order will also be canceled. In order words, the behavior of cancel order always includes the behavior of cancel order item • This relationship is modeled in UML as a uses relationship between the two use case. The UML Notation Guide describes this relationship as follows : • A use relation from use case A to use case B indicates that an instance of the use case A will also include the behavior as specified by [use case] B (78)

19. A First Functional Model (cont’d)

20. A First Functional Model (cont’d)

21. A First Functional Model (cont’d) • The Extends Relationship • A uses relationship describes the situation in which one use case always includes the behavior of another. What if one use case conditionally includes the behavior of another ?

22. A First Functional Model (cont’d) • Suppose, for example, that an Add Customer use case describes adding a new customer to the DryGoods.com customer database. This use case would be invoked when a Catalog Customer makes his or her initial order. In other words, sometimes while placing an order, the customer is added. This occurrence is based on an internal system condition in the Place Order use case – whether there is already a record of the customer or not

23. A First Functional Model (cont’d) • UML defines this concept as an extends relationship between use case. The UML Notation Guide states : • An extends relationship from use case A to use case B indicates that an instance of use case B may include (subject to specific conditions specified in the extension) the behavior specified by [use case] A (78)

24. A First Functional Model (cont’d)

25. A First Functional Model (cont’d) • Uses Versus Extends

26. A First Functional Model (cont’d) • A uses B means that A always invokes B, whereas B extends A means that A sometimes invokes B

27. A First Functional Model (cont’d) • An alternative way to think of these two relationships is as inheritance (subsumption) of behavior. (Each relationship is a stereotype of the specialization, or inheritance, relationship between classes)