I have this assignment for school where I have to model a sort of e-commerce site that delivers grocery bags to customers (http://www.linasmatkasse.se/). I haven't received any use case, or anything.
The only directions I've been given is that it's supposed to be a domain model of max 40 classes, of a web based business (like described above).
This is what I have so far.
Are the aggregations decent? (Especially between Customer and Account)
Should OrderStatus & AccountStatus be associated or not?
Is there any use for inheritance here?
Are there any redundancies, or anything that should be added?
Appreciate any feedback! Thanks!
change colors and font size of the picture, please - it is very hard to read.
Aggregations aren't OK. Composition - black diamond means, that item belongs to container and can't exist without it. Of course, an item can't belong to two containers this way. Change to shared one or two compositions. Customer and account CAN be connected so. But better think of Account as of association between Customer and Website.
Connect Cart and Order
Why OrderStatus and AccountStatus should be connected? I don't understand, why they need to be connected directly?
ItemDescription connect to item, or better, to ClassName, not itemlist
Why OrderItemList is connected to WebSite? What is it at all? Why Order is not enough?
What is SalesLineItem? Maybe, it should belond to OrderItemList?
Change ClassName to ItemClass - don't use terms accepted for other things.
Yes, you could use inheritance - Cart and Order should not be independent in this sense. But you'll decide, who is the parent. Or make "cart" one more status of Order. Or use both.
Heaps of things could be added, but obviously, it is not the real task, merely a piece of play. Think way of delivery, way of payment. Show navigability. Show names of arrows, not of connections.
Set attributes and functions.
Related
I am trying to design a use case diagram for the following scenario.
I have a society that is distributing goods to clients based on their orders. These clients can be administrations, companies, or private individuals.
Depending on what the client is I want to know more or less of their info (name, number etc)
The use cases are different depending on whether the client is:
English
English and have used this service for more than 3 years
Foreign
For example:
The 1) English clients' orders are accepted only if they pay a small fee in advance.
The 2) English clients that have used the service for 3 years don't have to pay this fee but need to get approbation from a different actor (an Agent in this case)
The 3) Foreign clients' orders are always accepted no matter what.
This right here is where I run into trouble and need help with.
The orders from nglish clients that have a criminal record are always denied UNLESS they are an administration.
What are the most optimal actor choices here? I thought of going with English client, and Foreign clients but I don't know how to include the "Unless the client is an administration" in the use case.
The use case diagram is not the right place to put this information. As correctly pointed out by #Christophe, a use-case represents a goal for a user who is going to interact with the system to achieve the goal.
This means that there is only one single use case in your scenario: "Order Goods". However, it has a set of preconditions. You could list them as structured plain text. Since there is quite some complexity behind each of them, I recommend to put them into a separate decision chart. Then you have a nice clean separation of the diagram scopes, and they remain easily readable.
Sidenote: There could be a second one "distribute ordered goods" executed by a 2nd actor who is an employee who does fulfillment / routing / dispatching.
Actors in UML use-cases are classifiers. To decide about which actors to create requires to understand the actors their goals and behaviours and how they differ in the interaction with the system.
First of all, you need to clarify the super-ambiguous requirements:
"English client": is this a client with English nationality? Is it a client that lives permanently in the UK? Is this a client with an address in the UK? Is it a client with a +44 phone number?
"Foreign client": same kind of questions + can you define for sure the difference between Ensglish and Foreign? For example: what with bi-nationals? what with people having two addresses one being abroad?
"Using this service more than three years": what with a foreign customer who uses the service for 3 years and then settles in the UK?
Since you deliver goods, you might also need to consider a delivery address. What with an English client ordering on a foreign address or vis-versa ?
"criminal record": the criminal record might change over time: is it provided at each purchase? or is it part of the customer registration process ? In the latter case, is there a need to periodically renew this information ?
Use-cases should in principle be goal oriented. So a use-case represents a goal for a user who is going to interact with the system to achieve the goal. Use-cases are not meant to describe the detailed sequence of your process (if client is this, do that, etc...) and neither are actors meant for that purpose.
You should therefore consider reformulating the use-cases to represent how the actors would perceive them. If needed you may consider the status of the actor that could explain that an actor behaves very differently. Typically in your case, I could imagine :
New client: a new client may want to provide details (address, identification) or evidence that they are entitled to buy (criminal record - I suppose your activity is regulated if you request such details)
Public administration: behavior of administration in purchase is anyway different because of public procurement and legal constraints.
Privately owned company: behavior is different since it can involve several persons,
Private individual
The need to pay an advance fee seem to depend on the address, nationality, history. It's more related to the process (it's a part of it) than an independent goal for an actor. So I would neither show this as a use-case nor make different actors for this purpose.
The reason to deny an order is not something that is not relevant for the customer (no customer has a goal go get a purchase denied!). It's relevant to you and your system and is a consequence of the registration process. So no need to have a dedicated actor for that.
I'm working on preparing a class diagram for mobile application. The application is meant to be something like a diary from journeys. Here are the requirements:
One user can create many trips.
One trip can be to one or more places (destinations, cities).
There might be assigned many albums with pictures to each trip, categorised in custom way, for example one album is for food pictures, one is for people user met during a trip etc.
Each picture can (but doesn't have to) have a description.
User can add contacts to a contact book.
I have created a very simple UML class diagram using StarUML. I am not sure if it all is correct, maybe there should be some association class used instead of something or maybe different kinds of relationships.
Could someone please check it and maybe give some tips and corrections?
id is nothing you would like to have in an object. It has it's integral ID already given by the run time system. Remove it (unless you have good reasons for it, like being a passport id or so)
Category appears twice. Not a good idea. Choose unique names.
Your Contact appears to be way too simplistic.
Delete() in Trip does not seem to make sense since you'd apply that to a collection which Trip is not.
Naming associations is not that helpful. Rather assign role names to either end.
I am wondering how granular should a domain event be?
For example I have something simple, like changing the firstName, the secondName and the email address on a profile page. Should I have 3 different domain events or just a single one?
By coarse grained domain events when I add a new feature, I have to create a new version of the event, so I have to add a new event type, or store event versions in the event storage. By fine grained domain events I don't have these problems, but I have too many small classes. What do you think, what is the best practice in this case?
What's the problem with many classes? Really, why so many devs are afraid of having too many classes? You define as many classes as needed.
A domain event signals that the domain changed in a certain way. It should contain all the relevant information and it should be taken into consideration the fact that an event is also a DTO. You want clear events but it's up to the developer to decide how granular or generic an event is.
Size is not a concern, however if your event 'weights' 1 MB maybe you have a problem. And the number of classes is not a domain event design criteria.
I can agree with MikeSW's answer, but applying SRP during the modeling, you can end up with small classes, which is not a problem at all.
According to Greg Young the domain events should always express something that the user does from a business perspective. For example if the user has 2 reasons to change her phone number PhoneNumberChanged, and this information can be important from a business perspective, then we should create 2 event types PhoneNumberMigrated, PhoneNumberCorrected to store technically the same data. This clearly violates DRY, but that is not a problem, because SRP can override DRY in these cases as it does by sharing aggregates and their properties (most frequently the aggregate id) between multiple bounded contexts.
In my example:
I have something simple, like changing the firstName, the
secondName and the email address on a profile page.
We should ask the following: why would the user want that, has it any importance from the perspective of our business?
her account was stolen (security, not business issue)
she moved to another email address
she got married
she hated her previous name
she gave the account to somebody else on purpose
etc...
Well, if we have dating agency services then logging divorces can have probably a business importance. So if this information is really important, then we should put that it into the domain model, and create an UserProbablyDivorced event. If none of them are important, then we can simple say, that she just wanted to change her profile page, we don't care why, so I think in that case both UserProfileChanged or UserSecondNameChanged events can be acceptable.
The domain events can be in 1:1 and in 1:n relation with the commands. By 1:1 relation they name is usually the same as of the commands, but in a past tense. For example ChangeUserProfile -> UserProfileChanged. By 1:n relation we usually split up the behavior which the command represents into a series of smaller domain events.
So to summarize, it is the domain developer's decision how granular the domain events should be, but it should by clearly influenced from a business perspective and not just from a modeling a data schema perspective. But I think this is evident, because we are modeling business and not just data structure.
So I'm working on an assignment for school, where I am to model (using a domain model) a web shop that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se). I wish I could be more specific here, but this is all I have unfortunately.
I haven't received any use case, but the scenario would be something like, add bag to cart, create account/add info, pay.
This is what I have so far : http://i.imgur.com/BIljBtj.png?1
Are there any redundancies? (I only have to depict the model of the site, unsure how much to include).
Could/Should I add composition between for instance Customer and Account, Cart and OrderLineItem, Order and Cart?
Pretty uncertain about attributes & multiplicites in general. Any feedback or support here is appreciated.
Payment class? Is it needed? Should it have payment methods included?
Should I model human elements like support?
Should I model more of the delivery
Is association between customer and order needed?
Thanks a bunch! Again...
It should be a class diagram. So, such verbs as "has", "contains", should be shown as aggregation, "supplies", "describes", "makes" should appear on associations arrows only if these names are the names of the attribute in the source(for arrow) class. "owns" should be shown as a dot on the end of association. Also put attribute names really on ends of the associations. You can name the whole associations, but that implies, that the association itself, without the instances of the classes, somehow exists. If you want to write comments, they are to be placed on the notes. But normally that words as "supplies", "describes", "makes", "has", "contains", "owns", appear on the Use case diagram. Make it apart from the class diagram, if you want to think on this logic or discuss it with a client or a sales manager you work with.
Composition
That one between Account and Cart you have made very nicely. Thus you cay, that Cart doesn't exist out of its Account and any account has only one cart. So, the composition with multiplicity 1 to 1 is sensible and bears a lot of important info.
The customer as you made it, is useless. You need only Account.
Till now I don't understand the use of OrderLineItem and ItemList. If the use of some classes is not obvious, it is bad - at least put comments there or think, if you really need them.
Payment - yes, it is necessary. As for payment methods, put them in the specific Enumeration class block, name them there as items and connect Payment to PaymentMethods.
No human elements here! You are deep into the IT model, on the border of coding. You really want to do a use case diagram, don't you?
Delivery? Maybe more enumerations for way of delivery and supplier, ClientAddress that is seen from Account, Order. It is for you to decide if you want to cover this or that scope.
ItemDescription should be connected to Item only
All you associations are navigable in both ways. It is senseless. Choose the navigability.
If a class attribute is an instance of another class, put a dot on that another end of association (end owned by classifier).
Supplier connected to Order? Do you want to cover the theme of trade with suppliers, too? Then there should be more classes on that theme. And it could be another component and another class diagram. Or is there a graphic error?
I am creating a Class Diagram for a simple booking system for the theater. I would like to know if the diagram makes any sense and if anything needs to be changed (arrow directions) in order for it to be correct?
Thanks.
Image URL: http://i.stack.imgur.com/zWiGW.jpg
Here are some recommendations that you're free to incorporate or ignore as you see fit:
I don't agree with the relationship between Show and Venue. It seems more natural to have a Booking maintain the relationship between a Show and a Venue.
I don't see a Date for a Show anywhere. Did I miss it? That seems important.
Shows don't have Seats; a Venue has Seats.
A Ticket ought to entitle you to a Seat in a Venue on a particular date. I don't see that.
TicketType should be nothing but an enum.
Decompose User to have a Name, Address, and Credential classes. Separate the Credentials out from User.
A real payment system would need far more than what you have showing (e.g. CreditCard, etc.)
I think your model needs a lot of work.
In addition to what duffymo said, here are some generic observations not strictly related to this particular diagram but rather you modeling practices.
If an association is one way navigable then there is no need to name both ends. You have named both ends of all associations, but only navigable end needs a name.
Drop the 'can' from all association ends. In some cases there is a handy term, for example show can be hosted at a Venue. But in other cases it's perfectly fine and even common practice to name association ends same as the class at that end. (so name the Seat end simply Seats)
Avoid many to many relationships if you can. If you can't then look into adding an association class in between, it almost always makes sense.