The entity is a person.
So the entity have a birthdate and maybe already have a deathdate.
But this dates can or cannot be informed (depends of the entity and avaibility of the informations) ; so the entity might have none of those.
But I feel to do mess with the cardinality and the relation type.
How should I represent that ?
I have created an abstract class Individual. It leads to 2 final class : Person (identified person) or Pseudonym (anonym person).
It linked to a class Birthdate and a class Deathdate (both are generalized as a class Date).
[Birthdate]----<>[Individual] relationship is :
one (optional)-to-many (0..1 - 1..*)
0..1 : Because birthdate can be omitted and individual can have just one date of birth.
1..* : Because birthdate must concern at least one, but can concern severals individual.
[Deathdate]----<>[Individual] relationship is :
one (optional)-to-many (0..1 - 1..*)
0..1 : Because the individual isn't dead yet and can die just once.
1..* : Because deathdate must concern at least one but can concern severals individual.
But since, theoretically, everyone have a birthdate (and will have a deathdate) I was tempted by a composition. But some might prefer keep these dates secret and I wondered if composition could allow that.
Futhermore one date can correspond to severals individuals and here also I guess composition isn't possible then OR else it's me who did the confusion between Individual class and its instances (the individuals) and then Composition would be possible but not with the aforementionned cardinality.
At the moment I chose that :
Aggregation :
___________ _______________
|Birthdate|0..1-----1..*< >| |
___________ | <<Individual>>|
|Deathdate|0..1-----1..*< >|_______________|
But I hesitate with this one
Composition :
___________ _______________
|Birthdate|0..1-----1<#>| |
___________ | <<Individual>>|
|Deathdate|0..1-----1<#>|_______________|
What is the right answer ? Thanks for the attention.
There is a number of issues with the approach.
First - using a class for dates is simply an overkill. Both birthdate and deathdate are attributes of a specific person and can be easily modelled as inline properties of the Individual class. Unless there is some significant reason to use something more than the good old Date DataType, keep with the standard approach.
For visibility issue, as object oriented principles say you should not expose the properties directly anyway. Rather than that you should have an operation responsible for retrieving birthdate and deathdate that will control if the date can be read or not. You may add boolean attributes that will support that, but it isn't necessary if the ability to see the dates depend on some state of the Individual or other things (e.g. "who" asks). In the former case you may also wish to still show explicitly those boolean attributes as derived ones.
If you insist on using a class for dates (e.g. as you want to have a Wikipedia-style "Born on date"/"Deceased on date" collections) you should create just one class Date and build associations to this class pretty much similar to the way you did in your second approach. In such situation, the multiplicity does not work "database style" but is a property of association itself. In particular association you have one birthdate/deathdate and one Individual. By default you will have two 1-0..1 association one for each but depending on the approach you may have much more complex approach as well.
I'll later add diagrams for more clarity.
One last remark.
Do not use << >> for the class name. Those are reserved to indicate stereotypes.
If you want to indicate that Individual is abstract either show it in italics or (if your tool doesn't allow that) use <<abstract>> stereotype.
Related
I am trying to do a simple UML model about a car dealership.
The company has at least one store where in each they sell at least one type of a car. Each store has a name and each car has a name, type, and price. Each outlet also keeps stock of every car they sell.
I have outlined the idea in this image:
In addition to this, after every day, the number of cars sold gets recorded into a database. How would I add this to the model? Also, is there a better way to model the amount of cars in stock than to have it as a separate class? If there is a better diagram to model this type of scenario with I'd also be interested.
Thanks for any help!
There are many ways to model sales records. The simplest and most common is to have a sales ledger. It creates sales entries for items. The item is a separate (association) class that records the number of sold items, the price paid, the sales date, the sales person, and more. Pretty simple and straight forwards, until you get to the gory details. Ask your next dealer...
You can model a sales record as a separate class. Let's call it DaySales. Each day, you have a new instance of DaySales, containing the date and the amount of cars sold. I have given attribute date the data type 'String', because UML does not define a Date type. But if you define it yourself, you could better use Date than String.
I have removed the association between Car and Outlet, because it is already implicitly defined via Stock, but you can keep it as a redundant association, if you like.
I have altered the multiplicity of the association between Car and Stock, because there will be multiple cars in stock.
Now i have two classes, named patient and doctor:
Patient() {
public:
//functions here
private:
Doctor doctor;
Date dateAdmitted;
Date dateDischarged;
}
Doctor() {
public:
//functions here
private:
//data members here
}
In my UML class Diagram for patient class, do i need to include the doctor and date as attribute? or i just represent them by linking them as association?
If attribute it should be like:
Patient
doctor : Doctor
dateAdmitted : Date
dateDischarged : Date
According to UML syntactical rules, both solutions are valid - both class attributes and associated classes are so called class properties and can be shown as attributes (inside the class) or as separate classes, linked via association. For both these class features you can define name, multiplicity, scope, etc. Please refer to UML spec for detailed technical information.
However, the common practice if the following:
if the property is basic data type (int, boolean, date, etc) -> show
it inside a class, as attribute
if the property is full fledged
class -> show it as a separate class entity and use association to
display their relationship
This practice make sense, as "int", "boolean" or "date" do not have their own custom properties and it is enough to show them inside a class (withoult losing information about them). Classes, on the other side, have their own features (attributes, methods and own associations, generalizations, etc) and therefore "deserve" more space on the diagram.
Concluding with the direct answer to your question: show Doctor as a separate class on the diagram, connected with Patient via association (note the property name displayed as associationEnd name). Keep both dates inside the Patient class:
The following diagram is equivalent and valid, but you might agree that the first one is visually clearer (imagine some atts, methods and relationships or the Doctor class) and therefore recommended:
UPDATE (after the comments)
Note: Composition is used for Dates, to reflect a strong relationship of the Whole-Part kind and the fact that these Dates cannot be unlinked from their context.
The other association (Patient-Doctor) is a common assotiation and the corresponding link can be broken anytime (for example to change a Patient's Doctor).
In UML, you would model relationships between classes as an association. Attributes should be for data types.
That they will most likely end up as fields in e.g. Java does not play a role at this stage yet.
Say I'm modeling a school, so I have 2 Entities: Student and Class. For whatever reason, I want each class roster to have a custom sort order. In a simple relationship, this would mean giving Student a sortOrder attribute and just sorting the list by this number. Issue is, a Student might be order 3 in one Class and order 6 in another. How would I store these orderings in Core Data in a way that I can easily access them and sort my lists properly?
Student Class
classes <<--------->> students
^ ^
| |
unordered ordered
This diagram might help explain what I'm trying to do. The students "roster" I would want to be fetched in a specific order stored somewhere, which could be any ordering. Storing this ordering is what I'm not sure how to do in a way that's the most efficient. Creating a bunch of Order objects and trying to manage the links sounds like a lot of overhead, and it feels like there must be a better way.
If the ordering of students can be described by one or more NSSortDescriptors, you could create a fetched property on the Class entity that fetches the students and applies the sort descriptor. Alternatively, it may be easier (depending on your use case) to apply the sort descriptor(s) to the NSFetchedResultsController that you're using to deal with the class' students collection.
If you can't use an NSSortDescriptor, then you'll need an index attribute (or name of your choice) on the Student entity if there's only one ordering or a collection of Order entities describing the index in each ordering for each Student. You'll be responsible for maintaing these index values. Unfortunately, there's no easy way to do this in Core Data. It's just a lot of work.
Student <<->> StudentClass <<->> Class
StudentClass
----
studentID
order
classID
Then you can select as necessary.
For example, you have a student. Fetch all StudentClass where StudentID is student.studentID. You then have the order, as well as access to the Class.
You'll likely want to add some business logic to make your life easier. Also, if you're not already using it, take a peek at MOGenerator: https://github.com/rentzsch/mogenerator
EDIT: I'd really like to know why this is getting voted down. Comments would be much appreciated.
I am new to architecture design and need some help on this.
I have two class namely 'Part' and 'Supplier'. A part will have supplier.
In my class design, should i have 'int SupplierID' (type is 'int') or 'Supplier supplier' (type is 'Supplier' ) as my property in Part class ?
Which one is better? What is the Pros and Cons of them?
Kinldy provide your input on this.
Supplier supplier
Having Supplier as a type and having SupplierID as a property of Supplier would make more sense to me. The initial benefit is that you can do some basic validation on the supplier ID. Sure you are representing it as an int now but this could (and probably will) change in the future. For example, you may decide to represent the ID as a string and int internally but when reporting it you will represent it as a string: XYZ1234, where XYZ is the Supplier company name(string) and 1234 is the unique ID (int) (bad contrived example maybe, but it is still likely to change in some way)/
The real advantage of having Supplier as a type is due to the fact you will be able to use Dependancy Injection to assign the Supplier to the Part when you create an instance of Part. So your constructor for Part should look like:
Part(Supplier supplier)
{
_supplier = supplier;
}
Now your Part class is not dependant on changes in your Supplier class. I.e. it is not dependant on it.
Note: If your not familiar with Dependancy Injection, this article from Martin Fowler should explain:
http://martinfowler.com/articles/injection.html
A polymorphic association is similar to a foreign key or many-to-one relationship, with the difference being that the target might be one of a number of types (classes in the language, tables in the db).
I'm porting a database design I've been using for some years from PHP to Java. In the old code, I had rolled my own ORM, which wasn't optimal for a number of reasons. Although I might start to tweak things later, and maybe end up implementing things myself again, for now I'd like to use an off-the-shelf ORM and JPA on my entity classes.
Now, there's one thing about the database layout that I don't know how to express in JPA:
I have a Node and an Edge table storing a graph (a DAG, if it matters). Each node may optionally reference one other entity from the database. These entites may be refrenced multiple times throughout the graph and there may also be "orphaned" entites, which wouldn't be accesible for the user, but which may make sense to keep at least for a while.
These objects are not at all related in terms of inheritance etc. but have a natural hierarchy, similar to Customer->Site->Floor->Room. In fact, years ago, I started out with just foreign key fields pointing to the "parent" objects. However, this hierarchy isn't flexible enough and started falling apart.
For example, I want to allow users to group objects in folders, some objects can have multiple "parents" and also the relations change over time. I need to keep track of how the relations used to be, so the edegs of the graph have a timespan associated with them, that states from when to when that edge was valid.
The link from a node to an object is stored in two columns of the node table, one carries the id in the foreign table, one carries its name. For example (some columns omitted):
table Node:
+--------+-------+----------+
| ixNode | ixRef | sRefType |
+--------+-------+----------+
| 1 | NULL | NULL | <-- this is what a "folder" would look like
| 2 | 17 | Source |
| 3 | 58 | Series | <-- there's seven types of related objects so far
+--------+-------+----------+
table Source (excerpt):
+----------+--------------------+
| ixSource | sName |
+----------+--------------------+
| 16 | 4th floor breaker |
| 17 | 5th floor breaker |
| 18 | 6th floor breaker |
+----------+--------------------+
There might be a different solution than using JPA. I could change something about the table layout or introduce a new table etc. However, I have thought about this a lot already and the table structure seems OK to me. Maybe there's also a third way that I didn't think of.
I think you've already hit on an answer. Create an abstract class (either #Entity or #MappedSuperclass) and have the different types extend it.
Something like this might work
#MappedSuperclass
#Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public abstract class Edge {
// . . .
#OneToMany
Collection<Node> nodes;
}
#Entity
public class Source extends Edge {
}
#Entity public class Series extends Edge {
}
#Entity
public class Node {
// . . .
#ManyToOne
Edge edge;
}
I understand you might not want to imply a relationship between the Source and Series, but extending a common abstract (table-less) class is the only way I can think of to do what you want.
InheritanceType.TABLE_PER_CLASS will keep Source and Series in separate tables (you could use SINGLE_TABLE to do something like the previous answer).
If this isn't what you're looking for, many JPA providers provide a tool that creates mappings based on an existing set of tables. In OpenJPA it's called the ReverseMappingTool [1]. The tool will generate Java source files that you can use as a starting point for your mappings. I suspect Hibernate or EclipseLink have something similar, but you could just use the OpenJPA one and use the entity definitions with a different provider (the tool doesn't generate any OpenJPA specific code as far as I know).
[1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_pc_reverse
The answer would be:
inheritance (as suggested already by Mike)
plus #DiscriminatorColumn to provide information which column stores the information about which subclass should be used: sxRef. The only doubt I see is the "sxRef" being a nullable column. I guess that it's forbidden.
Have you looked at the #Any annotation? It's not part of JPA but is a Hibernate Annotation extension to it.
How much information is stored in the Source and Series tables? Is it just a name? If so, you could combine them into one table, and add a "type" column. Your Node table would lose its sRefType, and you would have a new table that looks like this:
ixSource sName sType
16 4th floor breaker SOURCE
17 5th floor breaker SOURCE
18 6th floor breaker SOURCE
19 1st floor widget SERIES
20 2nd floor widget SERIES
This table would replace the Source and Series tables. Do Source and Series both belong to a superclass? That would be a natural name for this table.