My mind is all over the place and I am not sure how to go about starting this UML diagram. This is the problem:
The library consists of a lot of publications in several types of media – books, periodicals (also called magazines), newspapers, audio, and video. Each publication falls into a particular genre – fiction, nonfiction,
self-help, or performance – and target age – children, teen, adult, or restricted (which means adult only). Each publication also includes a unique ISBN identifier, which is just text. Design an object-oriented application that manages these publications as objects. We'll want to know the title, author, copyright year, genre, media, target age, and ISBN for each of our
publications. We'll also want to know if the publication is checked in or checked out to a customer, and if checked out to a customer, who that customer is (their name and telephone number). It's OK to enter
the customer information each time a publication is checked out.
Each publication object should be able to print its contents and its check out status something like this:
“The Firm” by John Grisham, 1991 (adult fiction book) ISBN: 0440245923
Checked out to Mike Williams (817-272-3785)
We'll need a simple console application with 5 operations: (1) Create a new publication, (2) List all
publications created in the system, (3) Check out a publication to a patron, recording their name and
phone number, (4) Check in a publication that was previously checked out, and (5) some short, basic
documentation on how to use the system. (Persistence is NOT required. Each time your program is run,
it may start without publications.)
You should design this system in UML first, creating (at least) a basic Use Case diagram, an Activity
diagram for at least action (3) above, and a class diagram.
For Use case diagram determine all the use cases and actors, then draw an use case diagram. Just google how such diagram looks like and create yours.
For Activity diagram determine what steps these use cases would consist of and show on a diagram.
For Class diagram identify all the candidate classes and think which ones you would keep or discard. You can also deterine attributes of each class. Then draw a diagram.
Related
Please take note of my class diagram. It shows an excerpt from a software for the management of movie showings in a cinema and comes from a study book.
The study book explains that there is a composition between the room and the seat. If a cinema employee deletes a room, the seats must of course also be deleted.
About my problem: I want to extend the example with the classes Showtime, Reservation and Movie. However, a reservation always refers to a concrete seat. I would pass a reference to a seat to the reservation:
In this case, can the composition between Room and Seat still remain or does it becomes an aggregation?
Translated with www.DeepL.com/Translator (free version)
Preliminary side remark: for the sake of simplicity, you could remove all the shared aggregation (white diamonds), because UML doesn’t define their semantic and they do not fundamentaly change the meaning compared to ordinary associations.
Let’s look at the whole scenario and keep the composite aggregaton. The consequence is the following:
If you delete a room, the seat would die. This sounds logic, because the seat does not make any sense without the enclosing room.
If you accept that a room gets deleted if still in use by a showtime, you accept that some showtimes may not be linked anymore to a room.
In a similar manner, this may propagate to the reservation, since some reservations would loose their link to a seat.
Now is this scenario a problem? I routinely have a reservation for a flight without the reservation being linked to a seat. So it is up to you to decide how you want to handle it:
You could constrain the deletion of the room to require that it is not linked to any showtime. You therefore avoid the described situation.
You could accept any room deletion, if you decide to offer some reallocation functions that would allow to deal with showtime and reservations without room and seat (at least temporarily) and reassign a showtime and the reservation to a different room.
You may even go further and opt for a mixed scenario, and accept that deletion of the room is possible if no showtime exist in the future (active showtime) bust simply do not care for for reservations on past showtimes.
In various locations of the Social Tables API documentation (and within the application UI), I have seen reference to the following terms: Venues, Bookable Spaces, and Room Diagrams. Can you please provide an explanation for what each of these are?
Sure!
Bookable Rooms are the actual floorplans of the rooms you are planning in. For instance, if you are planning an event in a large Hotel in the Grand Ballroom, the Ballroom floorplan is represented in our system by a bookable room.
A venue are a generic term that is used, but if you're referring to a venue id: Sometimes it refers to a bookable room, in these cases is is prepended with an S. But Social Tables events can also be planned with a PDF or Image background if we don't have a floorplan CAD of the space you're planning in.
Diagrams are the actual end product of using our main diagramming product. Think of it as a document with a collection of tables, chairs and other items.
Hope that helps.
Quick question about an ER/EER Diagram.
I have made this Entity Relationship Diagram, but I have been told, that there is something wrong with it by a friend. Is there something wrong with it?
The ER diagram is a design of a Library Management System, where a member can borrow 5 books at a time. The rest of the functionality of the system is how a normal library functions.
Library Management System EER
i don't understand the utility of the relationship between the librarian and the card and i don't understand why the books are splitted in two entities.
I would do 3 entities:
-member
-card
-book
every member has one card, every card is of one member;
every member can take many books, every book can be taken by many members,
the relation between member and book create another table in the logic schema: loans. before inserting a new loan you can check if the member has alredy 5 active loans (by checking the attribute active in the loans table).
Your given context is incomplete for me. I do not see the whole description of your problem/situation, so I will answer based on assumptions, and the experience I had during my life. So let's see...
The tino user questioned the existence of two entities, title and volume, which is something important. Let me explain this for a moment, which will eliminate this as an error. Previously (a time ago) we had video rental stores (I don't know if this the right name where you live, english is not my native language). Remember? We used to go there to rent VHS tapes to watch at home.
What we rented were not films, but more copies/midia of them. A film will always have the same actor, director, title, etc., but a copy could have different attributes/properties, like the year that the media was manufactured, the available languages, the expiration year, among other things. So we had distinctly two different things.
But despite this, we have to consider whether there is a need to create two entities for persistence. We have to remember if we need to persist this information. If a copy/midia has no attributes, then it's entity should not exist, and what a user would rent really would be the movies titles.
In your case, the relationship between volume and title, I belive, is really expressing this discrepancy.
Let's talk about the relationship between librarian and title. What a librarian manages? Does It manages the titles that never change and are abstract things, or the physical objects present in the library? :)
Finally, let's talk about the borrows relationship. When we break down 1-N (or N-1) relationships, we always pass the primary key from the 1 side to the N side, solving the relationship to the formation of the Physical Model in a Entity-Relationship Diagram.
Despite this relationship here is a 0-5, to decompose it, we will not have exactly a 0-5 relationship. We would have in anyway to pass the primary key from the two sides to the table formed by this relationship. Therefore, here we have initially a N-N relationship between member and volume.
N-N relationships allow optional relations between entities. This means we can have the zero side cardinality here. To limit the number of books that can be rented, you need to implement a restriction/constraint with SQL, or with any procedural language in your database. In this case, you can implement a before insert trigger. This trigger has a duty to verify this restriction to allow or denny the completion of the operation as a whole.
Let it be clear that I'm not saying you should remove this notation. Your Conceptual Model should express it. But when you are decomposing, you have to remember that. I think you should just correct it.
Remember one important rule: Relations that have attributes/properties (the attributes/properties) can only exist in N-N relationships. If you have to put attributes/properties in a 1-N (or a N-1) relation, they (the attributes/properties) will always be on the N side. In summary, there are no N-1 (or 1-N) relationships with attributes in the relation. Only N-N relations can have attributes/properties. So be careful with this.
Any questions or clarification, please comment and I will answer.
I see no reason to distinguish member and card. Volume and Librarian don't have primary keys. Are they supposed to be weak entities? That doesn't make sense for Librarian and Volume needs an identifier to distinguish different copies.
I am currently designing a database for a library a project for my database class. Below is the ER diagram so you can see the basic formatting of the database:
I have completed all of the requirements of the assignment, so please don't think that I am asking for someone to do my homework. What I am asking for assistance with is an idea. We can add extra features into this here such as a report generator, entry form, etc. I have added in a report generator to show the most active member/most popular book and an entry form. But I cannot think of anything else I can add into here to increase the usefulness, any suggestion would be appreciated.
There are a lot of possibilities:
Popularity can be split by gender, which could be interesting.
You could also work on popularity by address to make a geographical analysis, but if this is a local library you probably won't get much out of that.
Another stat that could be worthwile is the average length of borrow.
But the more interesting reports could be those that combine popularity, popularity by gender, average length of borrow with the catalog attributes... so you could have a view by author, by publisher or by publication year.
That is with the current structure. If you were to add genre or media type (book, magazine, CD, DVD) attributes, you would open up a whole lot of new dimensions.
Update Edited to reflect clarifications requested by Chris Holmes below. Originally I was referring to a Terminal as a Site but changed it to better reflect my actual domain.
At heart, I think this is a question about modeling a many to many relationship between two root entities where the relationship itself carries some semantic meaning.
In my domain
You can think of a Terminal as a branch location of our company
A Terminal can have a relationship with any number of customers
A customer can have a relationship with any number of terminals (standard many to many)
A customer\terminal relationship means that a customer can potentially store products at the Terminal
This relationship can be enabled\disabled. To be disabled merely means you are temporarily not allowed to store product, so a disabled relationship is different from no relationship at all.
A customer can have many Offices
A Terminal that has a relationship with a customer (enabled or not) must have a default office for that customer that they communicate with
There are some default settings that are applied to all transactions between a Customer and a Terminal, these are set up on a Terminal-Customer Relationship level
I think my objects here are pretty clear, Terminal, Customer, Office, and TerminalCustomerRelationship (since there is information being stored specifically about the relationship such as whether it is enabled, default office, ad default settings). Through multiple refactorings I have determined that both Terminal and Customer should probably be aggregate roots. This leaves me with the question of how to design my TerminalCustomerRelationship object to relate the two.
I suppose I could make the traversal from Terminal to TerminalCustomerRelationship unidirectional toward the relationship but I don't know how to break the relation from the relationship to the customer, especially since it needs to contain a reference to an Office which has a relationship to a Customer.
I'm new to this stuff and while most of DDD makes perfect sense I'm getting confused and need a fresh outlook. Can someone give me their opinion on how to deal with this situation?
Please note that I say Relationship not relation. In my current view it deserves to be an object in the same way that a Marriage would be an object in an application for a wedding chapel. Its most visible purpose is that it relates two objects, but it has other properties that rightfully belong to it as well.
By your description, you definitely need a "TerminalCustomerRelationship" entity to track the associated information. I would also convert the 'IsEnabled' flag into a first class 'Event' entity with a timestamp - this gives you the ability to save a history of the state changes (a more realistic view of what's happening in the domain.)
Here's a sample application (in VS2008) that refects your problem. You can tweak/test the code until the relationships make sense. Run "bin/debug/TerminalSampleApp.exe" and right-click "Terminal->Create Example" to get started.
Let me know if you find it useful.
Names can often clarify an object's responsibilities and bring a domain model into focus.
I am unclear what a Site is and that makes the entire model confusing, which makes it difficult for me to offer better advice. If a Site were a Vendor, for instance, then it would be easy to rename SiteCustomerRelationship as a Contract. In that context it makes perfect sense for Contract to be its own entity, and have the the model look like Vendor-Contract-Customer-Office.
There are other ways to look at this as well. Udi has a decent post on this sort of many-to-many relationship here.
You should not have a object Like SiteCustomerRelationship, its DB specific.
If its truly DDD you should have a Relation like:
Aggregate<Site> Customer.Site
IEnumerable<Aggregate<Office>> Customer.Offices
and perhaps
Aggregate<Office> Customer.DefaultOffice