I have been given the class names, properties, and methods.
I'm not sure what the relationships are between them, so I'd appreciate it if someone can correct me below before I start drawing:
Games has a one to many relationship to Sport. Sport has a one to many relationship with Event.
Event has a one to many relationship with Race.
And Heat and Final are subclasses of Race.
What do you think?
What you have sounds like a pretty good foundation - I think you've captured the relationships pretty well. It seems to me to more of a data model than a class model per sé.
To fill your class diagram out, ask yourself the following questions:
What information do I want to be accessible from outside the system?
Who (or which class) is responsible for retrieving and collating this information? Should I be able to access Events directly, or should I access them via the Sport they belong to?
What questions should each class be able to answer about the information it knows? Then provide methods that answer those questions.
Post your solution in the question so we can see what you come up with :)
Related
I am learning UML and I've focused on a Netflix-like project on which to practice on.
I'm trying to create a simple sequence diagram for 'stream movie' consisting of only the entity classes (so ignoring objects like the user interface, server, and database).
The idea is that members can search the movie catalog, select a movie, the system will then verify whether they have an unlimited or limited membership. If unlimited, they can stream the movie, otherwise, the system must check whether they have reached their limit of 10 movies that month. If they have, then they can not stream the movie and must receive a message stating why, or be asked to upgrade their account, otherwise, they can stream the movie as normal.
This is the class diagram demonstrating the associations so far:
And this is the sequence diagram for 'stream movie' so far, which I need some assistance with:
What is the best way to build that sequence diagram, yet keeping it relatively simple?
Thanks in advance.
I’m not able to give you a “best way” but I can comment on what I see in your attached diagrams. Maybe you can use this to refine questions that are more specific.
Starting at the bottom, your sequence chart is obviously incomplete. My only comment so far on this is that I don’t understand the logic of the flow, being your member calls “search” movie catalogue which in turn immediately calls “select” movie which in turn calls verify membership. These seem like an unlikely sequence of calls. I sort of get what you mean, I think — I suspect you’re missing return messages, and maybe it should be member that selects movie not the catalogue? Also, you have a member object (identifiable by the colon in “:member”) and then classes for movie catalogue etc. which is not really logical except in very specific contexts.
At the top, your class diagram looks much more complete and understandable. I can only really comment here on design choices rather than UML semantics/syntax. I’m happy to answer any specific questions you have on that but as it’s opinion I won’t post thoughts currently.
I am clarification trying to draw up my class diagram for an app that I am looking to produce. I have been following some different tutorials and explanations of class diagrams but I am unsure if I am filling it in right.
What I have done so far is the actual classes and the classes for each of the database adapters. Within the adapters I feel like I am repeating myself and wondering if I need to repeat in every class or should I just have them in one and leave the rest?
I know I havnt added in any relations or parameters, I want to make sure what I have is right before moving forward.
One point where you are repeating yourself is in the Adaptor classes. All of these classes have databaseTableName, dbHelper, mDB, and mCTX, open() and close(). All these should be pulled up into something that is called AbstractAdapter. All the adaptors should extend from this (I am not sure what DB_Adaptor is... perhaps that is the super class you are intending?).
Secondly, there is too little information to proceed much further. Having quickly scanned over your diagram I can't find any composition relationships and some entities appear to be missing. Eg. What is SimpleCursorAdaptor?
Thirdly, you are missing the domain objects. A Recipe_Adaptor should have a reference to something like a Recipe, an Ingredient_Adaptor should have a reference to an Ingredient, etc. You really need to think about domain objects before you proceed much further.
I read many articles, and saw a lot of images and I can't answer the question whether objects of View classes or DB classes should be contained on the sequence diagram or it should be more generalized?
All classes that are going to relevant to the design of the operation contained within the sequence should be there.
By making too many things generalized you risk missing important detail. I tend to include references in my sequences from the UI element all the way to the DB. If you are worried that the View and the DB are not fixed and using concrete refs will make your disgram incorrect. This shows that the design will need a close look! Maybe the contract between the view and the middle tier and the DB and middle tier needs to be better defined. Then all you have to do is include references to the contract in a general diagram and further detail in seperate diagrams for each implementation.
You can see the depth that many go to in this intro.
Remember, UML is supposed to be about good communication of ideas/designs. Do what conveys all the iformation that is needed in the simplest way possible!
I am creating a Class Diagram for a simple booking system for the theater. I would like to know if the diagram makes any sense and if anything needs to be changed (arrow directions) in order for it to be correct?
Thanks.
Image URL: http://i.stack.imgur.com/zWiGW.jpg
Here are some recommendations that you're free to incorporate or ignore as you see fit:
I don't agree with the relationship between Show and Venue. It seems more natural to have a Booking maintain the relationship between a Show and a Venue.
I don't see a Date for a Show anywhere. Did I miss it? That seems important.
Shows don't have Seats; a Venue has Seats.
A Ticket ought to entitle you to a Seat in a Venue on a particular date. I don't see that.
TicketType should be nothing but an enum.
Decompose User to have a Name, Address, and Credential classes. Separate the Credentials out from User.
A real payment system would need far more than what you have showing (e.g. CreditCard, etc.)
I think your model needs a lot of work.
In addition to what duffymo said, here are some generic observations not strictly related to this particular diagram but rather you modeling practices.
If an association is one way navigable then there is no need to name both ends. You have named both ends of all associations, but only navigable end needs a name.
Drop the 'can' from all association ends. In some cases there is a handy term, for example show can be hosted at a Venue. But in other cases it's perfectly fine and even common practice to name association ends same as the class at that end. (so name the Seat end simply Seats)
Avoid many to many relationships if you can. If you can't then look into adding an association class in between, it almost always makes sense.
I am trying to draw a conceptual class diagram. In my system, I have one person who can be performing 2 roles. One being "teacher" and other being "student". The same person could be a teacher in one instance and the same person could be a student in another instance. In such a situation, is it good to depict them as 2 separate classes (in my conceptual diagram)?
Please advise.
Thanks
Unless the person is teaching themself, don't get caught up in trying to show relationships that cross a use-case boundary. Validate the links for each scenario separately; just realize that not all connections will be used for every scenario.
People fill roles. Try
Person associated with EducationRole
EducationRole has subclasses of 'Student' and 'Teacher'
Here is a diagram.
They can change the role they play depending on the situation. If you need to show a person teaching themself then create a subclass of EducationRole named 'Autodiadact' which just means self-teacher.
A commenter asked about changing the role using a method and I'd like to include the answer here.
So, yes you could code the ability to change the role in a method but back up and ask the bigger question, why are we changing the role? A teacher is becoming a student or a student is becoming a teacher, either way the model as shown allows a Person to have many EducationRoles (which is what the asterisk denotes) at the same time so there isn't really a need to change the role but support a person with multiple possible roles.
In the conceptual model you are attempting to illustrate relationships between any valid state of the system, not necessarily how the change might be executed (using a method).