Having a class Customer that has a list of up to 10 Orders:
Customer
--------
+orders:Order[0..10]
But that means Customer is associated with Order class via aggregation, also:
Customer Order
-------- <>-------------------> --------
+orders:Order[0..10]
Should I also indicate 0-10 in the class association? Because I saw many diagrams do but on the other hand, this is specified in the attribute of Customer.
In fact you have to choose how you want to show the fact that a customer has a list of up to 10 Orders. You can depict it as an attribute or an aggregation or both but this latest option could be confusing. In all case if you want to model that as association (or composition or aggreagation) you have to show the multiplicity otherwise it would not be clear...
For more information take look a the 9.5.3 section of UML 2.5 specification
Related
I don't yet completely seem to understand how association class works, why the role class attributes can't just be inside the person class?
as example:
Person
name
position
description
Suppose we live in a world where a person must have a role in a company in order to live and a company may exist without persons at all.
If that is all you want to know about the relationship between persons and companies, i.e. only the fact that there are such relationships and nothing more, you model it like this:
Then if you want in addition to capture position and description of the Person's role you use so called AssociationClass (Role in our case):
Each instance of Role has four properties (both an attribute and an end of an association are Properties in UML):
Company
Person
position
description
For example, suppose a person named Scott Tiger has roles in two companies - Food Inc and Water Ltd and each company knows that Scott Tiger has role in it. Then there will be two instances of Role (shown as tuples):
(Food Inc., Scott Tigger, eater, eats here)
(Water Inc., Scott Tigger, drinker, drinks here)
Now, returning to you question, it should be clear that an instance of Person with name, position, description attributes actually "lacks" Company and if you "add" an Company you will get Role, not Person!
So what you proposed in the end of your question is a valid design, if you model Company and Role and a person is just an attribute of Role:
It reads as follows: each instance of Company has zero or more Roles and each instance of Role has only one Company. Both ends of the association are navigable, i.e. Role knows its Company and Company knows its Roles.
UML Specification in clause 9.5.3 gives you the following advice:
A Property may represent an attribute of a Classifier, a memberEnd of an Association, or in some cases both simultaneously.
A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association
end, while a property whose type is a kind of DataType is not. This convention is not enforced by UML.
why the role class attributes can't just be inside the person class?
notice the multiplicity 1..*, if you move position and description into Person you have to manage a collection of them and to associate each to the corresponding Company.
[from your remark]
For a given Person the position and description depends on each associated Compagny, so it is not possible to have the fields you propose except if position and description are both a collection, and to have a way/rule to know which entry in position and description correspond to the right Compagny.
Moving also these information in Person you remove the symmetry, it is also possible to move these information in Compagny, with the same remarks as for Person
An association class is both a class and a relation, when you implement it in a language like C++ or Java etc of course that concept does not exist, so one way is as you propose to move the fields in one of the two classes, or to create a third class having the expected fields more one to a Person and one to Company.
The advantage of the third class is to have all the associated information grouped having the equivalent of :
As example an object diagram can be :
Without the third class you need to know how to associate all the separated information, for instance having all in Person using three vectors to memorize the company and position and description you may use the same index value for all, but this is less clear and when you add/remove a Company for a Person you have to update all these vectors.
I would need some help with a problem we're facing in a company, trying to model every process and entity.
So far we have used an enhanced conceptual model with entities and attributes with relationships but there are some objects that don't exactly match a dimension or a fact table, and this is an entity that can be called "Shops with sales over X units". There is the entity "sales" and "shop" obviously, that would have it's representation in UML as independent entities and represent at the lower level, each sale and shop.
What we need to indicate in UML is an entity that stores the counter of shops with sales over X units, so this has some kind of behavior or conditions.
If we consider the entity, it would need date-from and date-to, and the value (counter), and creating a connection with the shop entity seems enough, but we miss the behavior that expresses "more than x sales". So the behavior could be for example: Go to the shop entity, take the 1st element and navigate to the sales entity, calculating the sales. If it's over X, then value+1, and so on.
I made a simple version of the problem. Blue boxes represent the entities already created, and the orange one is the counter that should count the shops with some constraints.
Is there any way of using some kind of UML diagram that can help us to solve this problem?
You could realize that with an association class:
ShopSales relates Shop and Sales so you can store the number of sales along with other things you might need in that conjunction. The ShopSalesStats could give you the shops by number of sales.
Another (of many) way(s) would be to just hold the count as public property of Shop and let ShopSalesStates handle the counts on all associated Shops.
In scope of visualizing different parts of the system I would like to exactly show dependency between different attributes.
In my case the use case will be in UI where a User have to to choose Country and based on his selection values for Product have to be updated in corresponding dropdown eg.
Values for Class Country:
Country1
Country2
Country2
Values for Class Product:
Product1 (available ONLY for Country1)
Product2 (available for Country1 AND Country2)
Product3 (available ONLY for Country2)
Product4 (available ONLY for Country3)
I've read about derived properties and constraints as it might be my case.
Also some links might be related to the same issue:
https://softwareengineering.stackexchange.com/questions/386816/how-to-model-attribute-dependency-inside-one-class-in-uml-class-diagram
But for now I do not have a working solution.
For general purpose I've tried to represent these relationships with abstract Class diagram but it's hard for me to do this with exact values of these Classes within Object diagram
You would likely model that as association class:
The CountryProduct needs to filled with the according information (so it my contain the price which is used for a product in a country).
You "could" model that as constraints on the association between Product and Country as well. But I'd bet that business will not be happy with that since it sets all in concrete when coding, while business expects quite some flexibility here.
Just use an Association between Product and Country. If you want to capture attributes for each Product-Country-pair, such as the price mentioned by #Thomas, an AssociationClass is the natural choice.
In an Object-Diagram Instances of the Association (links) can be shown as lines. You would have lines between Country1 and Product1, and Country2 and Product2 and Product3...
This could be used to illustrate the structure of your system and how it evolves over time. To really define it, other diagrams are better suited.
I don't see, how constraints on the Association can help. Textual Constraints could be on some additional Class Selection. The start of the constraint could be: context Selection: product = product1 implies country in (country1). This would not allow to later add new products. And the constraints defined by the Links between countries and products are much more readable.
I have 4 tables:
Doctors
ID,Name,roomNumber
Appointments
ID,whenOccured,ifAttended
Patients
ID, name, address
DPappointments
DoctorID,PatientID,AppointmentID
this roughly becomes
However, i now want to change it such that an appointment can be made to see either a Doctor OR a NURSE?
How can i change the class diagram to reflect an 'OR' type relation?
Depending on the rest of your model's structure, there are different solutions. I supose there is also a class Nurse and that id does not have any special relationship with the Doctor (like inheritance from Employee or similar). So, this would be a generic solution.
Add add an association between Appointment and Nurse, similar to the existing one with a Doctor. The corresponding multiplicity on the Doctor (and Nurse) side should be 0..1 and an additional rule should be added - an Appointment object must have either a link to the Doctor object or to a Nurse object.
This rule could be specified in OCL (if you like a formal style) or as a simple textual note on the diagram.
There are some other ways to model this, with no additional restrictions, but the model itself would (maybe) be necessery complicated. For example, you could derive Doctor and Nurse from an abstract class - AppointmentRespondent and link it with the Appointment using the multiplicity 1..1 on that side. This model permits more flexibility and is more exdensible (easy adding new potential AppointmentRespondents), no OCL, no restrictions.
It's up to you to chose the method that is more in line with your model and future extensions.
P.S. Not that this is not an OR-type of relation, but rather XOR - in each Appointment there MUST be somewhone on behalf of the hospital (this is a reasonable guess :)).
Can someone check my class diagram because I am not too good at drawing this type of uml diagram
A User can be a PersonalUser or a BusinessUser
An Administrator is a special type of PersonalUser
A PersonalUser or BusinessUser can create many Auction
But an Auction can be created by only one PersonalUser or only one BusinessUser
There an Auction cannot exist without an PersonalUser or a BusinessUser
An Auction can contain only one Item
An Item can be in only one Auction
An Item cannot exist without an Auction
An Auction cannot exist without an Item
An Item has one Category
Category can has many item
An Item cannot exist without a category
A Category can has a Parent Category but this is not mandatory
A Category can has many Attributes
But an Attribute is for only one Category
An Attribute cannot exist a Category
An Attribute can has many AttributeOption
But an AttributeOption is linked to only one Attribute
An AttributeOption cannot exist without an Attribute
An Auction can has many bids
A bid is only for one auction
A Bid cannot exist without an Auction and a Personal User or a BusinessUser
An Item can has many picture
A picture is only for once item and a picture cannot exist without an Item
A User can create many ForumTopics but a ForumTopic can be created only by one User
A ForumTopics can contain one or more ForumMessage
A ForumTopic cannot exist without a User and a ForumMessage cannot exist without a ForumTopic
A BusinessUser can has many BusinessContactNumber but a BusinessContactNumber is only for one BusinessUser
A BusinessContactNumber cannot exist without a Business
At first glance, you used a lot of aggregations. This is quite uncommon. I have never seen a good example of when an aggregation is justified. It's usually either a plain association (no whole-part relationship) or a composition (the part is deleted when the whole is deleted).
Cannot exists without does not imply aggregation. A proper multiplicity is sufficient. Can create does not imply aggregation. Creation is usually modeled with an appropriately stereotyped use-relation (i.e. dashed arrow), unless an association between the creator and the creation exists (in which case creation need not be mentioned explicitly).
4 But an Auction can be created by only one PersonalUser or only one BusinessUser.
Then the multiplicity of the Auction-PersonalUser association cannot be 1 at the PersonalUser end (because the Auction might have been created by a BusinessUser) and the multiplicity of the Auction-BusinessUser association cannot be 1 at the BusinessUser end (for much the same reason). Use 0..1 as multiplicity, but beware of what I will write about 3.
3 A PersonalUser or BusinessUser can create many Auction
This is equivalent to a User can create many Auction.
6 An Auction can contain only one Item
7 An Item can be in only one Auction
8 An Item cannot exist without an Auction
9 An Auction cannot exist without an Item
Then there is a single association between Item and Auction with multiplicity of 1 at both ends. Don't make aggregations out of it and don't use two associations for it.
13 A Category can has a Parent Category but this is not mandatory
That would be made clear if you label the association ends.
25 A User can create many ForumTopics but a ForumTopic can be created only by one User
This is only vaguely related to Auctions and might as well exists independent of them. Put the Forum stuff into a separate package. Then maybe the auction stuff and the user stuff also deserve a separate packages.
BTW: You did not mention the Bidding Service. It seems solely to model the concept of theses objects do not exist in thin air, they are actually used by some software. In that case, leave it out.
I largely agree with previous respondent, so I will present only differences and additional opinions.
To be a bit more precise, "Can create..." should be depicted using dependency relationship (not uses).
It is not entirely equivalent if some distinction should exist. You might use User class with an enumeration or UserType class if you want to avoid enumerations for some reason.
6.-9. So no Auction or Item object can exist. Either loosen the relationship in one way and use composition or merge those two to one class or create an association class.
Maybe one category can contain many subcategories? If true, edit the corresponding multiplicity.
Same as 4., view the other answer.
Also rethink the amount of classes in your design. Classes are not just data holders, they should have behaviour. What will be the behaviour of AttributeOption or Attribute or BusinessContact etc? Getters and setters do not count for a behaviour... I guess you planned to have all of this behaviour in BidingService, so I advise you to remove it and split those methods according to what class of objects should be responsible for behaviour achieved through the respective method.