Question:
I'm going to make my first trading system using C#. The system will be used to manage the guests and rooms of a small hotel, for now that's all he asked for. Obviously I'm happy with that, while knowing that I'm going to need to learn a lot of specific things to deliver the system.
At the moment I've already met with the system guy and collected the requirements, which in fact are not many. Then I'm going to model the bench and show it to him, and it seems to me that this part will be smooth. The only thing that is really worrying me is that I have no idea what to do to organize myself in relation to classes, what their properties and methods will be.
I know there is UML, but I have a problem using it. I don't know UML, and as I have 3 weeks to develop the system, I don't believe I'll be able to learn UML in that short period of time.
So I wanted to know if there's a simple way to get just that: which classes I'm going to use, what their attributes and methods will be.
Answer:
The UML is a visual language used primarily to document and communicate design decisions made using object orientation. You don't need to know UML to build your software in this paradigm, especially if you're going to work alone. Still, the day you have a little time it would be worth studying the Use Case and Class diagrams. The first is useful in communicating with the customer and understanding their problem and expectations. The second is useful precisely in the scope of your question: understanding what to produce in terms of classes, attributes and methods.
Well, in Object Orientation and computational problem solving occurs through the exchange of messages between objects instantiated from classes. Each class has well-defined responsibilities (it does something) and to help with that it maintains internal states through attributes (it has something). Consider, for example, in your problem domain, a quarto class and a cliente class. The quarto class has important attributes related to the real world entity, such as room number, occupancy status (occupied, vacant), cleanliness status (needs cleaning, clean room), indication of whether or not to have a TV, number of beds , etc. In addition, it has methods that allow performing actions involving rooms, such as booking (for a given cliente ), blocking (preventing reservations, in case of maintenance), requesting cleaning (involving another potential camareira class), etc.
The choice of classes, their attributes and the relationship between them (this dependence on whether the quarto can be reserved for a cliente , for example) depends heavily on your problem domain . That is, it depends on what needs to be implemented to solve your customer's problem (in this case, the hotel). Regardless of whether or not you use a UML Class Diagram, you will first need to list the entities, concrete or abstract, that need to be represented so that your system is able to offer the solution that your client (the hotel) expects. For example, cliente , quarto , camareira , estadia , reserva , mensagem left at reception, minibar consumível item, etc. Then, you will need to list the attributes of each of these classes, that is, what data they will need to store and manipulate in their respective scopes. For example, cliente has nome , CPF , etc; estadia has data de início data de fim , quarto , cliente , etc. Finally you will need to define the methods that each class should provide for public use (which can be executed/called/invoked by other classes) and privately (which is for its own internal use only). These methods are usually "functions" that perform something important in the scope of the class . For example, the quarto might have the reservar method, which does exactly what it says: it reserves the room for use by a cliente ; the camareira may have the alocar method, which records the quarto and time of day when the employee needs to clean.
One difficulty that you will certainly have is knowing how to differentiate what is important enough to be represented as a class or should just be represented as an attribute of another class. For example, if in your problem domain the TV needs to be handled by your system (because your system must control the released channels, since this depends on the package that the customer will pay), you will certainly need to have a TV class that have attributes for the different channels and methods to release or block them (besides of course having to implement the interface with the real TV even directly in the room!). On the other hand, if your system does not have this type of interface and the TV is merely something that may or may not exist in the room, just have it as an attribute of the quarto class (a Boolean attribute indicating whether or not it has a TV, or a numeric attribute that identifies the type of TV – 0 for simple TV, 1 for cable TV with few channels, 2 for cable TV with many channels, etc).
Finally, note that the Class Diagram (whether or not represented/documented in UML) is not exactly the same thing as the Entity-Relationship Model (your database tables). Naturally, your system will need to persist (store in tables) the data it manipulates, and the choice of how this is done depends on what needs to be represented in the system (in classes). But they are different representations. Objects instantiated from classes have references to each other (customer is in a room, which are both referenced by reservation, for example), whereas in your database tables use codes (in primary and foreign keys) to make this reference indirectly. Such codes may or may not be interesting for display to humans. For example, the hotel attendant will likely need to reference the guest code and room number, but the reservation may or may not have a code. Perhaps the hotel is used to "thinking" of booking in terms of just the customer and the room. This is not to say that your system does not need to use an internal identifier to reference reservations (in other words, the "reservation" table in the database must have a primary key).
So, I would suggest first working on the domain model (on classes, attributes and methods) to understand well what your system needs to represent and manipulate, and only then think about how these entities need to be persisted/stored.
I also suggest that you read a lot about Object Orientation. Right here in SOPT there is the object-orientation tag that has a lot of useful stuff. And, eventually, if you have doubts, post new questions in a punctual way (for example: I thought about making the X class with the Y attribute, but I don't know how to represent this, any tips?).