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 :)).
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.
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.
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.
Beginer in UML, I have the followings rules for an Aikido club management:
R1: Every member should participate to the training practices.
R2: The trainees can come from other clubs in the same city or country as well as abroad.
I identify 2 classes:
To take into account the second rule:
Member (1) and Trainee (0..1)
Trainee(1.. *) and Training (1.. *)
Is there a correct way in what I am doing?
Your diagram is a beginning. The diagram as proposed by Thomas Killian is more complete. However, in both of these diagrams there is no notion of constraints or rules. It is simply not what class diagrams are used for. What you can express (with your diagram) is that one or more members can participate in a training and that a training is frequented by at least one member.
To express that every member must participate in training courses, you could need to express that, for all the instances of your class diagram, all members are covered with at least one association towards training. To do so you will need to formulate constraints, possibly using OCL, the Object Constraint Language designed to supplement UML and address the specific shortcomings you are facing now.
Basically this is ok. But the m-n relation between Member and Training should better be modeled as association class:
In this case you are able to add individual properties of members per training. When implementing this you will likely feel the need to introduce some glue (like a table in a database) between both.
I have also added a Club class assuming that a member is bound to just a single club. If you want to model multi-club relations you would probably again use an association class.
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?