In the modeler, relationship is represented by a line between two entities. It would be no problem if the relationship has no descriptive attributes. But if it has, how can I represent the descriptive attributes? For example, the relationship set advisor, between entity set student and entity set instructor, has a descriptive attribute date to record the data an instructor become the advisor of a student. How I can represent the attribute?
A relationship can be viewed as an assertion. I believe the assertion that represents the relationship here is: An instructor acts as an adviser to a student.
There are 3 nouns in the assertion which implies that there are 3 entities involved in the relation:
Instructor
Student
Adviser
There are 2 fundamental entities (Student and Instructor) upon which the associative entity (Adviser) depends. In other words, an instance of Adviser needs an instance of Instructor and Student to make sense.
The simple answer is to simply make the date an attribute of Adviser. Unfortunately, life is often not that simple.
Are are the following two assertions valid?:
Jim acts as an adviser to Jane from 01/01/2009 to 06/30/2009.
Jim acts as an adviser to Jane from 01/01/2011 to 06/30/2011.
If so, then a new entity (Advisory Period) is required. An Advisory Period the amount of time during which an instructor acts as an adviser to a student.
The Advisory Period entity would be dependent on Adviser (necessitating a dependent 1:m relation between Adviser and Advisory Period) and the start and end dates of the period would be recorded as non-key attributes of the Advisory Period.
Hope this helps
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.
I am learning UML and have a practice question I am working on for class diagrams.
I've put together a first version of the diagram but i'm confused about part e. This is the practice question:
and this is what I have so far:
Where it says 'Each customer can store a number of debit/credit cards used for payments' does it mean that the customer then has an association with the debit and credit card subclasses? or is the credit card type stored in the customer class as an attribute?
The proposal of Thomas Kilian is not yet the complete solution. You should rename "CreditCard" to "PaymentCard" and make it a union type by partitioning it into the two disjoint subclasses "CreditCard" and "DebitCard". Give the Customer-PaymentCard association a 1-* multiplicity. Then add a many-to-one association between Payment and PaymentCard.
It's just that you need an attribute inside Customer for a number of credit card numbers. A card number is less than 2^43. So you can take a (64 bit) integer. Or use a String for that.
The dot-notation says that card is an attribute inside Customer and since it has a multiplicity not equal one it's an array (or a collection). Vice versa the CreditCard has a unique owner.
CONTEXT: I have an abstract class Student. From this class I derive three concrete classes SchoolStudent, UnderGradStudent, PostGradStudent. I have another class Vehicle. A school student must NOT drive a vehicle however, an undergrad or a postgrad student may or may not drive a vehicle.But every vehicle must be driven by somebody hence the Vehicle class has a reference to a student.
PROBLEM: I have association between classes UnderGradStudent & Vehicle and another association between PostGradStudent & Vehicle. However, I am a little confused about the multiplicity.
As I understand the problem, the UML class diagram should look something like this:
However, I suspect the above diagram suggests that each Vehicle will have one UnderGradStudent as well as one PostGradStudent.
Is the above diagram correct as to what I want to model corresponding to the context?
As you've drawn this UML diagram, it implies (but does not say correctly) that a Vehicle must be driven by both one UnderGradStudent and one PostGradStudent. It also implies that an UnderGradStudent can drive any number of Vehicles and a PostGradStudent can drive any number of Vehicles (at the same time). I don't think that's what you intended. The reason I say "implies" is that you have overlaid two associations on one end. Last I checked, that is invalid UML.
I think you wanted to say that a Vehicle may be driven by up to one Undergrad Student or Postgrad Student. To say that, I recommend the following model:
What this says is:
A valid instance of Student must be one of School Student, Undergrad Student, or Postgrad Student (and not multiply classified)
A valid instance of Allowed Driver must be one of Undergrad Student or Postgrad Student (and not multiply classified)
A Vehicle can be driven by up to one Allowed Driver (at a time)
An Allowed Driver drives up to one Vehicle (at a time)
This describes a valid situation at any point in time, which is really useful. Think of it as a way to evaluate the validity of any frame in a movie.
If you need to record all the drivers of every vehicle ever, you would need to make many changes. A Person actually plays the role of a Student (among other roles, usually), and that role can change over time. You would need to record the start and end time of every role change and the start and end time of every driver / vehicle change. Think of this as recording all the frames in a movie, but without the ability to express the validity of any given frame in the movie. You lose that ability when you relax multiplicities.
You can get the benefits of the "single frame" and the "whole movie" approach by combining all of the associations I mentioned.
Your problem will easily be solved by using a 0..1 multiplicity near the *Student classes from the Vehicle. This will tell the reader that both are allowed to have a related optional vehicle. To avoid both using the same car you need to attach a constraint like this:
Alternatively you can do it the following way:
I'm not good in writing OCL but you could formalize the constraint as well.
Simple question:
I have e-r model. I have entity Car. Car can be either BMW or Opel. If it is BMW then it must have color. If it is a Opel then it must have attribute - amount of passangers.
How can it be displayed in e-r model? I mean IF clase.
Thanks!
In an ER model this is normally represented as a sub-type.
http://en.wikipedia.org/wiki/Enhanced_entity%E2%80%93relationship_model
Sub-types can be exclusive or non-exclusive, depending on whether more than one of the sub-types should apply simultaneously. For example, a Bank Account entity might have sub-types for Current Account or Savings Account. These would be exclusive sub-types since a bank account cannot be both. Depending on the type of the account, one of the sub-types is used to "extend" the main entity. On the other hand an entity named Sportsman could have sub-types Golfer and Footballer. The Sportsman entity would contain common information such as name, and the sub-types would contain only the additional attributes applicable to the sport (e.g. Golf Handicap). Records only exist in the sub-type entities when the main entity is of the applicable type. These would be non-exclusive sub-types since it is quite possible that someone plays both golf and football.
In IDEF1X notation it is represented like this