Having a bit of trouble coming with a class diagram using the following information:
A services company provides its customers with services.
Customers can be of two types : Residential of Corporate
Residential customers can buy only residential services , Corporate customers allowed to buy corporate and residential services.
Residential services can be prepaid or postpaid , corporate services always postpaid
prepaid service can be renewed by the customer , postpaid service renewed automatically
3G and ADSl Services sold to Residential and Corporate Customers , iFly Service sold to residential only.
Here is the UML Diagram that i made,would it work?
As you have to learn doing UML, I will let you draw you the schema. But here some hints to start your class diagram:
"A services company provides its customers with services" => this is just the general frame. We need a Customer and a Service class
"Customers can be of two types : Residential of Corporate" => you need classes Residential and Corporate that have a generalization relation to Customer.
"Residential customers can buy only residential services, Corporate customers allowed to buy corporate and residential services" => You need a ResidentialService and CorporateService class that have a generalization relationship to Service. In addition you can draw the relationships that are mentionned.
"Residential services can be prepaid or postpaid , corporate services always postpaid" => there are several ways to do this. For example: you could a class PaymendMode and a relation with Service. Add then an annotation on the link with the constraint written between { } - Another way would be to forsee classes PrepaidProduct, PostpaidProduct inheriting from PaidProduct and draw the mandatory or optional relation (using cardinalities)
"prepaid service can be renewed by the customer , postpaid service renewed automatically" => again, several ways to do this. One way could be to add a method renewal() to the service and clarify the special case with an anotation - Or if you opted for the payment mode hierarchy with relations, you could make a generalization relation from ResidentialService to PrepaidProduct and from BusinessService to PaidProduct, and add the interface method on the parent.
"3G and ADSl Services sold to Residential and Corporate Customers , iFly Service sold to residential only" => this is a trap: 3G, ADSL and iFly are objects, not classes, so they have nothing to do on a class diagram. On the other side, this could be a hint that you need a class Product that would be related to Service.
Edit: some corrections to your diagram
Your diagram should represent the inheritance in the other way round:
The array notation that you use to show a multivalued attribute:
is in fact the same as a relationship with a cardinality. Prefer the relationship:
For the rest, the logic seems fine to me. Except that the prepaid/postpaid in the different services: Cardinality should be 0..1 (optional) (or 1 for mandatory).
Final remark: about prepaid/postpaid: it's not clear if the service has just to indicate which payment methods are accepted (independently of the customer) or if this attribute is customer specific. If it's the latter, you should then use an association class between the customer and the relevant service (see here)
Related
In some countries, Company ABC's customers need to have ownership of phone numbers that they want to use as 'From Numbers' for sending messages or as 'caller IDs' for making voice calls in that country. There are two ways customers can achieve this:
Use numbers they rent from ABC for this
Use numbers they have rented elsewhere and get them 'whitelisted' with ABC
To 'whitelist customer numbers, ABC, needs to be sure about the following:
Customer is a legal business registered in the US with a valid registration number and proof
Customer has access to (and control over) the numbers being whitelisted
ABC's customers who will need to achieve the above includes 'resellers' who in turn sell ABC's offerings to other customers as part of their own offerings.
Define customer facing RESTful APIs which the customers can use to achieve the above objectives. The APIs need to be generic so that they can be expanded for other related / similar use cases as well.
This is an interview question. My approach was around having 4 APIs basically-
RENT OUT NUMBERS-
1.1 Get the set of available numbers
1.2 Rent the numbers
WHITELIST & SUBSCRIBE
2.1 Establish the legality of the customer
2.2 Whitelist the number
I have to build an Entity Relationship Diagram and therefore wanted to ask you, if I did it the right way. Any help is highly appreciated!
Here is the assignment:
"Lisa is the owner of the cleaning company CleanAlp. Her company's primary customers are property management companies that manage residential complexes (properties). The customers book one or more services for every property. For this purpose, CleanAlp and the respective customer agree to a contract. There can also be more than one contract for one property (e.g. after termination and new assignment) or temporary additional cleaning services in exceptional cases. Every cleaning service has an interval (e.g. weekly, fortnightly, monthly), which has been agreed to in the contract. A cleaning service refers to a catalogue containing the cleaning services offered by Cleanalp (e.g. sweeping the stairwell, cleaning windows). Lisa employs several people. For each property, one employee is responsible for executing the cleaning services. The responsible person can change during the contract term, but it must be kept track of who and when was responsible. Invoices are sent to customers monthly—the amount to be paid as agreed upon in the contract."
My solution:
Entity Relationship Diagram
Thank you very much!
Sincerely,
Johann
I've been developing for many years and a common problem I face is how best to separate out the service layer. I've been using the repository pattern mainly, but I still struggle with this common scenario.
Customer service that returns a single customer.
Invoice service that returns a list of invoices by customer.
The consumer of the service sometimes wants just a Customer other times they want the customer and the invoices which is fine to leave as two calls.
But a new requirement may be they want the Customer, but also want the total number of invoices the respective customer has.
I do not want to corrupt the GetCustomer method and do not want to return a list of invoices and have them do a count (this would work). Is there a best practice without getting into create a lot of one of methods while still keeping performance and round trips in mind? I see a lot of designs where there will get GetCustomer, GetCustomerDeepLoad, etc.
thanks.
It's simple. Don't overthink it.
Services need to meet the needs of the clients. If the client wants customer details, the service sends a representation of customer details and nothing more; if the client wants a customer and all their orders, the service obliges; and so on. In doing so, you might need more than just a Customer object; for example, you might need a CustomerOrderList object made up of CustomerOrderItem, etc.
What you MUST NOT do is mix the concerns of order management and customer management, meaning that the CustomerOrderItem that you return will be a version suited for customer management and not the full-fledged OrderItem that would be modelled for order management.
That's the reason why I have switched to CQRS. Operations (writing/commands) often targets a single entity type while reads (queries) often want a composition of entities.
You dont want to get those queries into the repositories as the repositories tend to get leaky abstractions when you do that.
In your case you can have two types of services: Entity services which are responsible of taking care of changes and query services which are responsible of taking care of supplying information to the client (composition of different entities).
I typically use repositories only on the write side and let the query services query the database directly. That works as you have your business logic contained in the entity services.
I am trying to learn domain modeling , now lets consider a shopping cart example.Lets user can browse catalog of products and add products to shopping cart, purchase those products.To purchase products he will place order.User can trace his order details.He can call up customer rep to know about status of his order.
Please validate my Domain model in full scope.
Below is Domain Model i have designed , i am having issues in representing order and order status what is the right way to do
How would i link product and order.
A (conceptual) domain model is a solution-independent description of a problem domain produced in the analysis phase of a software engineering project. It may consist of information models (typically in the form of UML class diagrams), process models (typically in the form of BPMN diagrams), and possibly other types of models.
A domain class model contains only conceptual elements, such as properties (possibly without datatypes) and associations. It does not specify the visibility of properties and methods, as visibility is a platform-specific concept.
Your model is incomplete in many respects (e.g. it does not describe order lines/details, which are taken from the cart), and it does not contain any association. Clearly, an order is associated to one customer and to many items/products (via its order lines).
OrderStatus should be modeled as an enumeration, which is a UML datatype that is stereotyped with <>, and Order should have a status attribute with this enumeration as its range.
The model below may be a bit more general than what you had in mind, because it allows for several warehouses from which an order item can be sourced, and it also distinguishes between private and corporate customers.
You can make "order details" an associative class for the relationship between order and product. See the example:
IBM example of an associative class
Note that yours is really a class diagram. A domain diagram shows the dependencies on different problem domains such as
Order fullfillment
Database
RemoteCommunications
SystemMaintenance
etc.
We have an app which is exposing a RESTful API to a UI for purchasing an item. I have a question regarding API design. Lets say the following action should be taken in order
Item to be chosen for purchase
Next give the address to be delivered to
My question is: should we design a single API which gets both data perform both? Or should we design two API calls - one that creates a purchase record and second that update the address to be delivered to?
The recommended SOA approach is to choose coarse-grained services, which would seem to argue the minimum amount of API calls.
However, from a business point of view, item selection and purchase and item delivery are two very different concerns that should be separate components in your architecture. For item selection, you need to consider things like inventory and pricing. For delivery address, you need to consider user address lists, address validation, shipping, and taxation.
Those two components are not likely to interact much except maybe some external association between an item id and address id. For this reason, I'd recommend two API calls. Functionally, this would also allow your API users do things like update the delivery address without re-purchasing an item, send the bill to one address and the item to another address, etc.
As you state that you design a RESTful API you usually start by designing resources instead of the intended calls. Later on, resource representations can be chosen that include other resources for optimised HTTP request counts.
You might want to choose to proceed the following way:
Model the item list resource (GET - lists all items, POST - allows item creation) /items/
Model the address list resource /addresses/
Model the item instance resource /items/item/resourceId
Model the address instance resource /addresses/address/resourceId
Now all of your resources are available you can think about usage patterns. All your resources are generically available and can be mashed up.
Possible approaches to answer your questions would be:
Extend the item instance resource with the needed address details (coarse grained as lreeder stated)
Model a resource /deliverydetails/ as list and instance resource containing item(s) and address, make the deliverydetails to be queried by item id or whatever your use case fits best
Hope that helps!
Btw. you are automatically following SOA approaches with a Resource Oriented Design. Interfaces will be naturally fitting your business requirements and generic enough to support more advanced use cases.
Here is a good example