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

Kyung Hee University Basic Concept  The most part of software development system projects  Transforming a product description into a software implementation  Initial description of several forms or

Kyung Hee University 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

Kyung Hee University Basic Concept (cont’d)  UML provides two notational conventions for defining a system functional model  Use case diagram (static view)  Activity diagram (dynamic view)

Kyung Hee University 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)

Kyung Hee University 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

Kyung Hee University 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

Kyung Hee University 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)

Kyung Hee University 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?

Kyung Hee University 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

Kyung Hee University 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?

Kyung Hee University 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

Kyung Hee University 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

Kyung Hee University 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

Kyung Hee University 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

Kyung Hee University A First Functional Model (cont’d)

Kyung Hee University 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

Kyung Hee University 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)

Kyung Hee University A First Functional Model (cont’d)

Kyung Hee University A First Functional Model (cont’d)

Kyung Hee University 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 ?

Kyung Hee University 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

Kyung Hee University 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)

Kyung Hee University A First Functional Model (cont’d)

Kyung Hee University A First Functional Model (cont’d)  Uses Versus Extends

Kyung Hee University 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

Kyung Hee University 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)