Skip to content

Instantly share code, notes, and snippets.

@emgeier
Last active January 18, 2023 18:11
Show Gist options
  • Save emgeier/f61a436826be7823bde349a6198ef9e1 to your computer and use it in GitHub Desktop.
Save emgeier/f61a436826be7823bde349a6198ef9e1 to your computer and use it in GitHub Desktop.

Unit1 PromiseDao Design Review

Overview

What's the problem with the way the PromiseDao currently works?

The PromiseDao only supports one source of delivery promises: the Delivery Promise Service (DPS). We already need to get promises from another service, the Order Fulfillment Service (OFS), so this is a good time to make the design more flexible.

Use Cases

A promise will be made by the Order Fulfillment Service (OFS). When the PromiseDao get() method is called with a customerOrderItemId to obtain a list of Promises, the promises made by OFS will be on the list. The promises that the DPS makes will be unchanged and the actual delivery dates will continue to supplant the promised delivery dates.

If there is no promise made by the OFS, when the PromiseDao get()method is called, then the promise list is unaffected. If there are no promises made by OFS or DPS the program will continue to run, with appropriate messaging to the user.

What ways will the CS representatives use the new multiple-client PromiseDao?

The CS representatives will be able to see the dates by which different services are expecting to have orders delivered.

How does the PromiseDao work right now?

The PromiseDao uses two soures of data, the DeliveryPromiseServiceClient and the Order Manipulation Authority Client, to generate a list of promised delivery dates from the former, check the ids against the later, then update the list of promised delivery dates with actual dates of delivery where possible. Its get() method then returns the updated list of promised and fullfilled delivery dates. (The PromiseDao implements a ReadOnlyDao with a String and List and get()method as specified.)

Sequence diagram of how the current PromiseDao works:

sequenceDiagram
    participant Shell
    participant PromiseHistoryClient
    participant GetPromiseHistoryByOrderIdActivity
    participant PromiseDao
    participant DPSClient
    participant Promise
    Shell->>PromiseHistoryClient: getPromiseHistoryByOrderId(orderId: String)
    PromiseHistoryClient->>GetPromiseHistoryByOrderIdActivity: getPromiseHistoryByOrderId(orderId: String)
   
    GetPromiseHistoryByOrderIdActivity->>PromiseDao: getCustomerOrderItemId())
    PromiseDao->>DPSClient: getDeliveryPromiseByOrderItemId(orderItemId: String)
    DPSClient->Promise: builder
    DPSClient->>PromiseDao: Promise
    
    PromiseDao->>GetPromiseHistoryByOrderIdActivity: List<Promise>
    GetPromiseHistoryByOrderIdActivity->>PromiseHistoryClient: PromiseHistory
    PromiseHistoryClient->>Shell: PromiseHistory
    

Loading

Original UML Diagram: deliveringonourpromise_CD.puml

Proposed Solution

Overview

Short description

I will create an interface, PromiseServiceClient, to be implemented by any Service Clients that are used to get promises from services that will make delivery promises. It will enable consistency, standardizing a way to get promises by calling a getPromiseByOrderItemId(String customerOrderItemId) method, ensuring all new PromiseServiceClients will have a method that can be called to process data from all the services that will make promises now and in the future. When a CS Rep asks for a Promise History they will recieve a list including all promises made and by which service.

Out of Scope

I will only be changing the PromiseDao's method of creating a list of Promises, by allowing more than one source of promises. No functional changes will be made.

Details

Sequence Diagram with Proposed Changes:

sequenceDiagram
    participant Shell
    participant PromiseHistoryClient
    participant GetPromiseHistoryByOrderIdActivity
    participant PromiseDao
   
    participant OFSClient
    participant DPSClient
    participant OMAClient
    participant Promise
    Shell->>PromiseHistoryClient: getPromiseHistoryByOrderId(orderId: String)
    PromiseHistoryClient->>GetPromiseHistoryByOrderIdActivity: getPromiseHistoryByOrderId(orderId: String)
    GetPromiseHistoryByOrderIdActivity->>PromiseDao: get(customerOrderItemId: String)
    PromiseDao->>DPSClient: getPromiseByOrderItemId(orderItemId: String)
    PromiseDao->>OFSClient: : getPromiseByOrderItemId(orderItemId: String)
    PromiseDao->>OMAClient: : getCustomerOrderItemByOrderItemId(customerOrderItemId)
    DPSClient->>PromiseDao: getPromiseByOrderItemId(String): Promise
    DPSClient->>Promise: .builder
    OFSClient->>PromiseDao: getPromiseByOrderItemId(String): Promise
    OFSClient->>Promise: .builder
    OMAClient ->>PromiseDao: OrderResultItem
    PromiseDao->>GetPromiseHistoryByOrderIdActivity: List<Promise>
    GetPromiseHistoryByOrderIdActivity->>PromiseHistoryClient: PromiseHistory
    PromiseHistoryClient->>Shell: PromiseHistory
  
Loading

Redesigned UML diagram of new PromiseDao design: //www.plantuml.com/plantuml/png/hLFHRe9047o_hzZ45st33zIcaPPOVJ2Oqdx01RPuoN6GOp4XrdyloicHU89D-dWxixF3ihCeYMkgCidUaROwpqI9Ar5IhklNEjG9wdNYnoJsWchml1Smd83dZ4Kxb19iqJI-IO6AcAju8eyFOepPCQUMS1brehRU0C7s1X1k_1QmMX7glOZH687d7y-p_KCaE_q3UH8gMJTJ3DPVHoS63nPXuT9LPIoMl2p1BmeuC020HpYKn4d4HqX7DpITmTCzYnmJRfrPjMjixj2m7ttkj4yN-MpfGZMFsyGDLwAeP5FCbL_HBjU2-Yx7I2xX0ANOewuTlxWL7IBypUc8n_lT3VWQM3Bnqv_3peKjpHaxcfDhKpkH8jrHgh46Su0UE1DRt3mA3_nF_wj4lU8gaQX1gA8YyxXocN6XfhF6XL24-fl72FquMJyzWZEKarnpbU8bGJPV1ZWmUwANH11cwsGQaHOgXToMPjtrTki9jl-bjq2LL9dy1G00

Narrative of Details

The software will use the App class to instantiate all the client objects. The PromiseDao will call the client service classes that create promises in order to create a list of current promises, checked against the list of delivery dates that have already been met. The clients that create promises for the promise list created by PromiseDao will be implementing a template of the interface PromiseServiceClient which demands a single method -getPromiseByOrderItemId of its corresponding classes. A CS representative will be able to access the Shell to enter an OrderId to obtain the PromiseHistory through the PromiseHistory Client with the method getPromiseHistoryByOrderId. The PromiseHisoryClient uses the getPromiseHistoryByOrderIdActiviy to get the promise history from the PromiseDao. The PromiseDao will now call both the DPSClient and the OFSClient to ask for promises associated with given customerOrderItemIds. It will still check the promises against the list of already delivered items provided by the OMACLient.

The complexity (BigO) of this solution

n = size of the list of Promises from OFS O(n); This solution adds a building of promises process for every promise in the system. This will increase by n with each to process run. There are no imbedded for or if loops written, the if loop written in PromiseDao for OFS is independent of the DPS one. They run in parallel. //PS This was changed after the suggestion by Darek. Now there is a for loop with an if statement and a set and an add method within it.

@pemheath
Copy link

pemheath commented Nov 8, 2022

This is fantastic! Your use cases are detailed and well thought out. I think the final word of "narrative of details" should be OMAClient. I am a little behind on the BigO so I will not comment on that part, but otherwise I think this looks great. I'm not sure how to access the UML diagram you mentioned, it looks like it is a link to a file on your local machine, but I could be wrong about that. You write very well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment