Question

I’m studying UML and I’ve been reading about use cases. All of the examples I see deal with single system and I was wondering how an end to end process would be modeled. So, I made up a fairly typical enterprise scenario and I’ve been trying to model it. I have questions that I’ve been unable to answer.

Scenario: My business use case is a Shopper creates a Shopping Cart which is received by the Vendor as an Order.

The end to end process flow is:

1. The shopper creates a cart
2. A manager reviews the cart and approves/rejects and a purchase order is created in the purchasing system.
3. The purchasing system sends all newly created PO to their respective vendors’ systems.
4. The vendor receives the PO as an order.

However, the devil is in the details so I decided to make it more complex by adding the following details:

1. The shopping-purchasing system communication is point to point and real-time.
2. The PO can be sent to vendor via fax or internet. All PO go into a queue before being sent to the vendor. The queue is processed every X minutes. I picked 10 minutes as the interval
3. The purchasing-vendor connection uses middleware (ESB).

Questions:

1. I believe I have 3 system use cases: Shopper-Creates Cart, Manager-Reviews the Cart , Time-Send PO to Vendors. Is the correct even though I have an ESB system between the Purchasing System and Vendor System?
2. Since the middleware is not an actor in one of the above use cases where should I model the ESB’s involvement in the process (Purchasing-> ESB, ESB-> Vendor)?
3. Do I draw 2 system boundaries or 1 system boundary? I believe I should have the Vendor’s System as a secondary actor so I only have the Shopping System and the Purchasing System. Or do I merge them into an E2E System (such as Procurement System)?

Answer 1

1. I would create separate use cases for reviewing, approving and rejecting the cart, but otherwise I think your use cases should be accurate enough. Since the ESB system is not directly used by your actors, I don’t think it’s relevant in the use case diagram.
2. You could create a component diagram to model the relationships between separate systems and their subsystems in more detail that is possible or reasonable in a use case diagram. If you want to, you probably could isolate the ESB in it’s own system boundary with a use case “Deliver PO to Vendor” marked as a dependency for the use cases related to the connection.
3. I suggest two or three system boundaries, depending on whether you create an own boundary for the ESB. If the Vendor’s system is outside your scope, you probably won’t need to model it in too much detail – receiving the PO should be enough.