I am doing UML class diagram for the first time. I have put a data store in class diagram I am not sure if I can . Also, is it possible to get feedback on this class diagram I have uploaded?
Basically its a hotel management system.
I am explaining the story point wise here. I have removed the unwanted stuffs from the story.
1) Login - Allow user to search room if he is a registered user. If not he/she should be able to register to hotel management system.
2)User should be able to search the available rooms from the system and select a type of room-Available rooms based on check in and check out dates.
3)Hotel employee should be able to charge for the facilities availed.
4)Store user information for marketing Purposes.
5)User should be able to cancel made reservation of rooms.
6)Make payments online.
7)User/receptionist should be able to modify/update rooms booked, User information from the information they have. - I added data store.
Placing login method in the class which gains login does not seem to be reasonable. Authorization should be a class of its own and a user may gain access through it.
There is nothin modeled which shows the occupation of rooms. I'd expect some Occupation class which links rooms to time ranges.
The same. What is the basis for the occupation? There needs to be an Occupation class which relates Room with time frames.
What are marketing purposes? You could implement some user statistics that traces when a user has booked rooms, how punctual he paid, etc. Those are not modeled.
Since you have not modeled a Reservation you will not be able to cancel it.
The Payment is related to nothing. So you don't know for what a payment was made. Your book keeping will love you for that :-(
As above: no reservation modeled - no modification possible.
You should probably find some mentor to sit together and do some basic modeling.
Edit (as on the updated model): This is not the way to go. The datastore will serialize the single objects, and not be a class of its own. The way you need to do it is to construct a model with the relevant classes. Those will finally result in persistent objects in the database. FacilityAvailed does not look sensible. This looks like information you can compute from Reservation (which needs a relation to Room which is now missing completely). Well, you should dump this approach and start all over. Just model the business objects (BO): Room, Reservation, User, Payment, etc. Relate those meaningful. What are the attribute of each BO (Room: Number, Size, Cost,... User:Role, Name, ...). Then try to relate them. E.g. a Reservation may relate Room and User, but could also be simply for refurbishment/cleaning etc.
Related
I want to start a project in JEE and I need to confirm about my class diagram. I need to know if the methods used are correct and if the composition I used is correct or not.
This is my class diagram:
The project is about an online sales store, that wants to set up a management tool to sell products, and to manage its products. This tool must include the following features:
Identification module: identification of clients, managers, supervisors
Sales module: make purchases for users
Product Management Module: Adding / Deleting Products
Statistical module: visualization of sales statistics
Functional Specifications
It is necessary to act on the application, to connect to the application with a user ID and password. To facilitate its use and in order to avoid any mishandling thereafter, here is the solution:
User Profile:
The user will be able to visualize the products sold by My Online Races. The user can place an order, provided that he has registered with the site My Online Races.
Manager profile:
The manager will be able to manage the products:
Add / Edit / Delete Products
Add / Edit / Delete category
These data insertions can be made using CSV or XML files, but also through various forms on the website.
The manager will be able to view the sales statistics.
Supervisor Profile:
The supervisor can add managers whose roles are specified above.
The supervisor will be able to view the sales statistics.
The supervisor will be able to view all the actions performed by the managers, a sort of audit trail.
Well I wish to know already if you have remarks about my design. As well as I have a confusion for several methods, for example adding, modifying and deleting a product. Should I put them in the manager or product class? Is the composition I put correct or should I remove it?
Quick review of the diagram and advices
First some minor remarks about class naming: Ordered should be called Order.
The composition between Article and Order is just wrong (not from a formal view, but from the meaning it conveys). Use a normal one-to-many association: it would reflect much better the real nature of the relation between the two classes. Please take into account that a new article may exist without having been ordered, so it shoud be 0..* instead of 1..*
+belongs and +do in the middle of an association are syntactically incorect. You should use a plain triangle instead (or nothing at all). The triangle should be oriented in the reading direction Person do |> Order and Article belongs to |> Category
The methods seem ok. You do not need to add a suffix.
How shall objects be managed (created/updated/deleted) ?
A more advanced concern is not about the diagram but about how you want to organise persistence (i.e. database storage):
do you really want the object to be an active record, that is an object that adds, updates and deletes itself (to the database) ? It's simple to set up, works well, but makes the class dependent on the underlying database implementation and thus makes maintenance more difficult;
or wouldn't it be better to use a repository for each object ? In this case the repository acts as a collection that manages all the database operations. The domain object (Article, order, User, ...) then have nothing to know about the database, wich leads to more maintainable code.
But this is a broader architectural question. If it's just for a first experimental project with JEE, you can very well use the active records. It's simpler to set up. Be sure however in this case to disambiguate the Add/Update/Delete on Person, since it currently may give the impression that any person can add anyone.
Improvement of the model
A final remark, again not about the diagram itself, is about the domain. Your model considers that an Order is about a single Article.
In reality however, orders are in general about one or several articles: if this would also be the case here, your Order would become an OrderItem and the real Order would be inserted between Person and OrderItem. You could then make the relation between Order and OrderItem a composition (i.e: OrderItem is owned by Order, which has responsibility for creating its items, and the items have no sense without the related order).
I'm working on preparing a class diagram for mobile application. The application is meant to be something like a diary from journeys. Here are the requirements:
One user can create many trips.
One trip can be to one or more places (destinations, cities).
There might be assigned many albums with pictures to each trip, categorised in custom way, for example one album is for food pictures, one is for people user met during a trip etc.
Each picture can (but doesn't have to) have a description.
User can add contacts to a contact book.
I have created a very simple UML class diagram using StarUML. I am not sure if it all is correct, maybe there should be some association class used instead of something or maybe different kinds of relationships.
Could someone please check it and maybe give some tips and corrections?
id is nothing you would like to have in an object. It has it's integral ID already given by the run time system. Remove it (unless you have good reasons for it, like being a passport id or so)
Category appears twice. Not a good idea. Choose unique names.
Your Contact appears to be way too simplistic.
Delete() in Trip does not seem to make sense since you'd apply that to a collection which Trip is not.
Naming associations is not that helpful. Rather assign role names to either end.
I'm building an application that manages most of the LOB stuff at my company. I'm trying to wrap my head around DDD... starting with customer management. Many examples are very, very simple in regards to the domain model which doesn't help me much.
My aggregate root is a Customer class, which contains a collection of Addresses (address book), a collection of Contacts, and a collection of communication history.
Seems like this aggregate root is going to be huge, with functions to modify addresses, contacts (which can have x number of phone numbers), and communication.
E.G.
UpdateCustomerName(...)
SetCustomerType(...) // Business or individual
SetProspect(...) // if the customer is a prospect
SetDefaultPaymentTerms(...) // line of credit, etc. for future orders
SetPreferredShippingMethod(...) // for future orders
SetTaxInfo(...) // tax exempt, etc.
SetCreditLimit(...)
AddAddress(...)
RemoveAddress(...)
UpdateAddress(...)
VerifyAddress(...)
SetDefaultBillingAddress(...)
SetDefaultShippingAddress(...)
AddContact(...)
UpdateContact(...)
RemoveContact(...)
SetPrimaryContact(...)
AddContactPhoneNumber(...)
RemoveContactPhoneNumber(...)
UpdateContactPhoneNumber(...)
AddCommunication(...)
RemoveCommunication(...)
UpdateCommunication(...)
etc.
I've read that value objects don't have identity. In this system, each address (in the database) has an ID, and has a customerId as the foreign key. If Address is it's own aggregate root, then I wouldn't be able to have my business logic for setting default billing / shipping. Many examples have value objects without an ID... I Have no idea how to persist the changes to my Customer table without it.
Anywho, feels like I'm going down the wrong path with my structure if its going to get this ginormous. Anyone do something similar? Not sure how I can break down the structure and maintain basic business rules (like making sure the address is assigned to the customer prior to setting it as the default billing or shipping).
The reason that you're butting up against the issue of where business logic should lie is because you're mixing bounded contexts. LoB applications are one of the typical examples in DDD, most of which show the application broken up into multiple bounded contexts:
Customer Service
Billing
Shipping
Etc.
Each bounded context may require some information from your Customer class, but most likely not all of it. DDD goes against the standard DRY concept when approaching the definition of entities. It is OK to have multiple Customer classes defined, one for each bounded context that requires it. In each bounded context, you would define the classes with properties and business logic to fulfill the requirements within that bounded context:
Customer Service: Contact information, contact history
Billing: Billing address, payment information, orders
Shipping: Line items, shipping address
These bounded contexts can all point to the same database, or multiple databases, depending on the complexity of your system. If it is the same database, you would set up your data access layer to populate the properties required for your bounded context.
Steve Smith and Julie Lerman have a fantastic course on Pluralsight called Domain-Driven Design Fundamentals that covers these concepts in depth.
I am trying to study some aspects of ddd with the domain of a car rental website.
The user/customer selects a car from a start and destination station and the time period.
The price calculation depends on various things like payment method, time, car classification and so on. The data is retrieved from a subsystem which differs in data access strategy from the rest of the application.
There are several actors in the domain like station service, call center...
Idea for the bounded context are
Company (employee, car, station)
Booking (reservations, model for booking request process)
Pricing (the price model)
Billing (rental billing, positions, customer)
After defining the bounded context I am unsure if the aggregated roots of each are correct. My thoughts are
Company: all three of them
Booking: reservation (access to billings, the car and customer)
Pricing: tariff matrix
Billing: customer (access to reservations, billings)
If needed I can add some class diagrams to show the different bounded context.
If more information is needed, a class diagram or this should be migrated to an other section feel free to ask/do it.
With what little experience I have with the car rental domain, I'd say you are on the right track. A couple of things you should be aware of: Bounded Context are a logical separation, not a physical one. As such, using something like a compositional UI, would allow you to display pricing information as part of the booking process. You'd be hosting UI components from different BCs side by side, and using them to guide the end user through the process he's trying to complete. The other thing is, you're looking for aggregate roots in all of the BCs, but I do hope you realize that you don't need a domain model in each and every one of them. Maybe a simple datamodel will do if things are not "core" to your business or crud-based by nature. That's the beauty of BCs, the ability to make deliberate technology choices.
I've got a system that allows classroom instructors and graders to log in and manage classes and grade papers. A user can be both an instructor and a grader, and can be so for particular semesters. Other users, like students, are also bound to this semester scheme. Still others, like administrators, have accounts that don't run by semester.
When someone is no longer a grader or instructor, she still needs to be able to access past grading or classroom records, albeit with fewer privileges (view only).
I've thought about implementing a roles table with a semester as a part of the key, but that doesn't apply to all users. I've also thought about keeping the semester data separate from the roles, but making roles like "PastGrader" and "PastInstructor" to cover those people who need to have access to past information but should not be allowed to participate in this semester.
What is the optimal data model/roles model for this application?
I think you're on the right track. I would keep the semester out of the roles table, but use them together where needed.
Here is what I did recently that will also work in your scenario:
Create a FunctionalRole table that has the following columns:
FunctionalRoleId, FunctionalRoleName
These roles will be like jobs. Teacher, Grader, etc.
Add another table called FeatureRole, with the following columns:
FeatureRoleId, FeatureRoleName
These roles will be for specific features in the application. GradePapers, ViewPapers, etc.
Then create a third table... call it RoleMember, that has these columns:
FunctionalRoleId, FeatureRoleId
That way, the admin can assign roles more simply by the job and all of the feature roles will automatically be assigned.
And like I said, keep the semester information separate.
Gabriel
I think that you need an additional entity to help you out. You clearly have the domain object of a CLASS to represent a specific class (ie: Composition II is a class). You also clearly have a domain object for PARTICIPANT to represent the people that attend the class. I think you have already identified those two.
Next, you need a domain object to represent a specific semester/timeslot/classroom where a CLASS will be held. Let’s call that domain object a CLASSSCHEDULE. You will need a relationship from CLASS to CLASSSCHEDULE to show what topic will be taught in that room during that semester.
Now you need a domain object to represent how a PRATICIPANT interacts with a CLASSSCHEDULE. We can call this domain object an ENROLLMENT. The ENROLLMENT object is where you put your privileges for the PARTICIPANT. The PARTICIPANT is ENROLLed in the CLASSSCHEDULE as a learner or a grader. Your role is attached to the ENROLLMENT object. In this way, each PARTICIPANT will have a different privilege level for each CLASSSCHEDULE that they are involved with.