After some confusion with mixing use case and class diagrams, managed to clear some doubts and come up with the following class diagram. Felt more comfy with this than use case. Hope am not wrong. Would like some feedback on any errors and improvements on it. Thank you.
Question:
A new library has books, videos, and CDs that it loans to its users. All library material
has a unique identification number and a title. In addition, books have one or more authors,
videos have one producer and one or more actors, while CDs have one or more artists.
The library maintains one or more copies of each library item (book, video or CD). Copies of all
library material can be loaned to users. Reference-only material can only be loaned for a
maximum of two hours and can’t be removed from the library. Other material can be loaned for
up to two weeks. For every loan, the library records the user, the loan date and time, and the
return date and time. For users, the library maintains their name, address and phone number.
Draw a class diagram for the description above.
Class Diagram: link to diagram
Don't use notes for multiplicities 1..*. Edit associations or their ends instead and write it there.
Write multiplicities on ends, not in the middle of the line.
Arrows should be subscribed by names of attributes.
Libraries can have many Videos, books, CD's and so on. So, there multiplicities should be in both ends.
No arrows on the line is the same as arrows on both ends. Check it on the right sides.
Write attributes inside blocks when they are of types not present on the diagram. If they are not, put their names on the opposite ends of the associations, near arrows.
You should use some empty diamonds on the left side.
You should decide the multiplicity of the producer.
Divide Title from Copy. And maybe, from Edition.
Don't mix plural and singular - hold to some system. I use plurals only for collections, but you needn't take it, of course. Plurals in class names are senseless - all classes apart from singletones have many instances.
You don't need toconnect library to CD and Video - they are merely subsets of Books. And books already are connected. The same with three lists in the Library block.
Loan should be connected to Book.
According to standards, loan() is a constructor of the class Loan. It can't be in another class.
Related
I never understood the difference between these types of association. How should I interpret and in which scenarios should I use each one?
Given your diagrams all three cases are equivalent. So, I would go with the simplest version.
Adding a Purchase class allows to define features and behaviors of the link objects.
In the second case, Purchase is classifying the binary links between User objects and Product objects. That means each Purchase object is the link between exactly one User object and exactly one Product object. The outcome is the same as in the third case. Only there you have two link objects and one regular object, making the model a little more complicated. On the other hand, in this case you don't need to explain to your readers what an AssociationClass is.
In earlier versions of UML the two latter cases had a subtle difference. If the two ends of the AssociationClass are unique, each pair of User and Product can have at most one link. For a Purchase this is probably not what you want, because the user might buy the same product multiple times. But a stack overflow user can earn each badge only once. The AssociationClass would allow to model this.
Unfortunately this distinction has been thrown out. Therefore, AssociationClasses now don't have more expressive power than regular Classes, making them obsolete. I wrote a specification issue asking to put uniqueness back in.
So, according to my college teacher, the first and second one are equivalent. The second one would be "more correct" if the purchase had other atributes, since it doesn't you would opt for the first.
The third one differs a bit from the rest in the way that there can be multiple purchases where the User X bought the Product Y.
So, the first and second would be useful if we only want one record of a purchase between a User and a Product, and the third if we wanted to keep a purchase history for example
The first one is a named association. The name of the association (being purchase) is pretty pointless unless you are doing some exotic stuff. In this case User and Product have both some array referencing objects on the other side.
The second and third are just alternative notations for the same thing. That is you have an association class Purchase which in this case connects User and Product by adding some (not shown) functionality/attributes. Here the classes left/right do not see each other. It's only Purchase which makes the references.
Edit As noted by #JimL. the 2nd and 3rd differ in one respect: #2 has two* left and right where there should be a 1 to make it a match for #3. This would be the usual use for an association class. The * would make it different and probably very uncommon for the obvious application here.
I have to complete a program that implements a car Park system.
I started with the UML diagram as I think it is easier for the program to be done after that, but I am a bit stack.
The scenario is:
Design and implement a class Vehicle (abstract) and the subclasses Car, Van, Motorbike. The classes should include appropriate methods and hold information about the ID plate of the vehicle, the brand of the vehicle and the entry time/date in the parking.
In particular:
• The Car class should also include appropriate methods and hold information
about the number of the doors of the car and the color.
• The Van class should also include methods and information about the cargo
volume of the van.
The class Motorbike should also have methods and information about the size
engine of the motorbike.
You should implement a class DateTime to represent the time/date of the entrance of
the vehicle in the parking. Do not use any predefined library.
Design and implement a class called MyCarParkManager, which extends the
interface CarParkManager. MyCarParkManager maintains the list of the
vehicles currently in the parking.
The class should display in the console a menu from which the user can select among
the following management actions:
• Add a new vehicle in the parking if there are free lots (considering that the max number of lots is 20) and return the number of the free lots remaining. Consider that a Van occupied 2 lots. Display a message with the number of free lots or informing that there are no lots available.
• Delete a vehicle, selecting the ID plate, from the list when the vehicle leaves the car park and return the vehicle instance. Display the type of the vehicle leaving the parking (if it is a car, a van or a motorbike).
• Print the list of the vehicles currently parked. For each vehicle print the ID plate, and the entry time and the type of vehicle (if is a car, a van or a motorbike). The list should be ordered chronologically, displaying the last vehicle entered in the parking as the first in the list.
And this is what I've got so far. My Solution
Since class Vehicle is abstract and cannot be instanced, what should I use to create different vehicle objects, might it be an array? And how should the output be changed, I mean depending on what the input is going to be: If it is car, to ask for color also, if it is a van for cargo volume?
Thanks a lot in advance to who take the time to read it and see if this UML seems right.
Analyze the statement
An important skill that you will start to develop in this module is analyzing a problem statement in order to identify the details needed to develop a solution.In this assignment the first task you should perform is a careful analysis of the problem statement in order to make sure you have all the information to elaborate a solution. Do not make assumption about what is needed! If you are not sure, about the information provided, ask questions.
Design a solution:
The design of your system should be consistent with the Object Oriented principles and easy to understand by an independent programmer.
Source: 5COSC001W Object Oriented Programming - Assignment 1
Suggest you:
class: "VehicleCardInfo" for storing cars information and status
class: RulesForCarPark for validate all data in "VehicleCardInfo"
vocabulary for: car types e.t.c.
CarParkManager as Actor use UseCase "Managing Cars" for CRUD operation for "VehicleCardInfo" objects.
Maybe we need some rules for people to logging and use this application.
UML diagram maybe easy for above (we don't use associations, use dependency).
I want to display the booking list of a restaurant for a given date. I omit the boundary object here. In the first diagram, the restaurant object maintains the complete set of booking made for the restaurant. In the second diagram, the restaurant object is not used. Are there any benefits using restaurant object?
The main benefit is encapsulation. Different restaurants can handle bookings in different manner. All you have to do is to build common interface for a Restaurant.
Secondly in the former case the BookingSystem immediately have information about the restaurant (and you probably want to present that to either staff or a client). The latter one would have to handle this information in some other way.
If your app is for one restaurant only, then everything that happens in your app is related to that restaurant and this object would not add significant benefit to this design: it could well be made implicit (second diagram).
The drawback is that your app design then relies completely on this underlying assumption. Very often, successful restaurant entrepreneurs open a second and a third venue. Some even become so popular to become a franchise with several thousands of restaurants. So keeping restaurant in the design (first diagram) has the advantage to cover a broader range of needs and easier reuse of the software, at a marginal additional thinking effort. (And the app could be more reusable and interest successful restaurant owners who would not consider it if you'd be mono-restaurant).
P.S: The * in the booking lifeline is not standard UML. The sequence diagram represent a scenario of interactions between lifelines that each represent an individual object. The communication diagram, a close cousin of the sequence diagram, has a * notation, but for the message numbering and not for instances either. Usually, in sequence diagram, a loop fragment is used to show an iteration. More about this topic in this other question
First, don't think i'm trying to get the job done by someone else, but i'm trying to design a class diagram for a domain model and something I do is probably wrong because I'm stuck, so I just want to get hints about what i'm not doing correctly to continue...
For example, the user needs to search products by categories from a product list. Each category may have subcategories which may have subcategories, etc.
The first diagram I made was this (simplified):
The user also needs to get a tree list of categories which have at least one product.
For example, if this is all the categories tree:
Music instruments
Wind
String
Guitars
Violins
Percussion
Books
Comics
Fiction
Romance
I can't return a tree of Category which have at least one product because I would also get all subCategories, but not each sub category has a product associated to it.
I also can't remove items from the Category.subCategories collection to keep only items which have associated products because it would alter the Category entity, which may be shared elsewhere, this is not what I want.
I thought of doing a copy, but than I would get 2 different instances of the same entity in the same context, isn't it a bad thing ?
So I redesigned to this:
Now I don't get a collection of child categories I don't want with each Category, I only know about its parent category, which is ok.
However, this creates a tree of categories which is navigable only from the bottom to the top, it makes no sense for the client of ProductList who will always need a top -> bottom navigation of categories.
As a solution I think of the diagram below, but i'm not sure it is very good because it kinda dupplicates things, also the CategoryTreeItem does not seems very meaningful in the domain language.
What am I doing wrong ?
This is rather an algorithmic question than a model question. Your first approach is totally ok, unless you were silent about constraints. So you can assign a category or a sub-category to any product. If you assign a sub-category, this means as per this model, the product will also have the parent category. To make it clear I would attach a constraint that tells that a product needs to be assigned to the most finest know category grain. E.g. the guitar products would be assigned to the Guitar category. As more strange instrument like the Stick would get the Strings category (which not would mean its a guitar and a violin but just in the higher category.
Now when you will implement Category you might think of a method to return a collection of assignedInstruments() which for Guitar would return Fender, Alhambra, etc. You might augment this assignedInstruments(levelUp:BOOL) to get also those instruments of the category above.
Generally you must be clear about what the category assignment basically means. If you change the assignment the product will end up in another list.
It depends on the purpose of the diagram. Do you apply a certain software development method that defines the purpose of this diagram in a certain context and the intended readers audience?
Because you talk about a 'domain model', I guess your goal is to provide a kind of conceptual model, i.e. a model of the concepts needed to communicate the application's functionality to end users, testers etc. In that case, the first and the second diagram are both valid, but without the operations (FilterByCategory and GetCategories), because these are not relevant for that audience. The fact that the GUI only displays a subset of the full category tree is usually not expressed in a UML diagram, but in plain text.
On the other hand, if your intention is to provide a technical design for developers, then the third diagram is valid. The developers probably need a class to persist categories in the database ('Category') and a separate class to supply categories to the GUI ('CategoryTreeItem'). You are right that this distinction is not meaningful in the domain language, but in a technical design, it is common to have such additional classes. Please check with the developers if your model is compatible with the programming language and libraries/frameworks they use.
One final remark:
In the first diagram, you specified multiplicity=1 on the parent side. This would mean that every Category has a parent, which is obviously not true. The second diagram has the correct multiplicity: 0..1. The third diagram has an incorrect multiplicity=1 on the composition of CategoryTreeItem.
From my perspective your design is overly complex.
Crafting a domain model around querying needs is usually the wrong approach. Domain models are most useful to express domain behaviors. In other words, to process commands and protect invariants within the correct boundaries.
If your Product Aggregate Root (AR) references a Category AR by id and this relationship is stored in a relationnal DB then you can easily fulfill any of the mentionned querying use cases with a simple DB query. You'd start by gathering a flat representation of the tree which could then be used to construct an in-memory tree.
These queries could be exposed through a ProductQueryService that is part of the application layer, not the domain as those aren't used to enforce domain rules or invariants: I assumed they are used to fullfil reporting or UI display needs. It is there you could have a concept such as ProductCategoryTreeItemDTO for the in-memory representation.
You are also using the wrong terms according to DDD tactical patterns in your diagrams which is very misleading. An AR is an Entity, but an Entity is not necessarily an AR. The Entity term is mostly used to refer to a concept that is uniquely identified within the boundary of it's AR only, but not globally.
I have a problem with my UML diagram and I'll be happy if you help me. I have relationships like
Object A (1)<>----(0..*) Object B
Object B (1)<>----(0..*) Object A
and I'd like to unite them. How can I do it? Thanks a lot.
Can you please define the term "unite them"? What exactly would you like to achive? An example could probably help.
Meanwhile, I can try to guess and give you two possible solutions. Maybe they help you to rephrase your question or even to find the solution:
In the Solution 1, I've just made a single relationship that describes both of yours. This can be used if there is only a single and clear criterion of the linkage between the objects. A typical n..m relationship. Objects A will each hold a collection of related objects B and vice versa.
For example a Person (A on the diagram) can join several Clubs (B) and a Club can have several members - there is only one logical relation behind this situation - membership.
Solution 2 is where there are actually 2 different ways to relate between those elements, each one 1..n. So, A holds a collection of Bs and B holds collection of As, but they are unrelated.
Extending the same example - a Person (A) can join only 1 Club (B) and a Club can have many members and hold their reference (col_a on the diagram). In the same time, a Club can have only 1 owner, and a Person can own several Clubs (col_b). Here we have two different logical relations - membership and ownership.
Of course, other multiplicities and navigabilities are possible, this is just an example to give you an idea.
Does one of these situations sound like yours?
UPDATE (after the 1st comment):
So, here is the updated solution 1:
This is an aggregation used here, and this is more a Group-member relationship. It suits perfectly the description of my first solution up there. Members (B) can be "shared" between the Groups (A) and Gruop does not have any special control over their lifetime.
The real Whole-part relationship would employ composition instead of aggregation (visually depicted with a black diamond, instead of a white one). Its semantics it that Whole object has a full control over the life of the contained objects (parts). In consequence, the Parts cannot be shared between several Wholes and must be destroyed if the Whole itself is destroyed.
Now you just need to find out which situation describes your problem the best, pick-up on of this solutions and eventually fine tune the multiplicities.
Here is a way you could represent this scenario in UML.
One server can contain 0 or many Functions (ie. aggregate relationship).
Each function must belong to one server. Or if it is a distributed function then it can belong to many servers.