Domanda

I have an assignment for developing a hotel reservation system! One of tasks is to develop UML class diagram! However, in the task description it is written "Class diagram should represent your database"

I am a bit confused about the rules, notations and etc... because I can't find any official UML class diagrams specifically for databases!

Could you help me please?

È stato utile?

Soluzione 2

First I would like to brief you about the different types of classes for a class diagram into which one can view the entire system in a static view.

  1. Some classes are entity(model) classes which define the database model for application domain persist for longer duration. In the above mentioned case it can be customer, hotel staff, hotel menu, seating info.

  2. Some classes define the GUI & presentation to the user such as view classes.

  3. Some classes define the control the program logic, process user events which can be called as control classes.

  4. Some classes can be viewed as the resource classes which are responsible for communication with external data resources.

For all the mentioned classes above the notations, rules followed in UML will be same but their usage, intent will be different.

For your problem, you need to capture these entity classes for the mentioned system through which you can model the database for your system. I hope it will help you a bit.

Altri suggerimenti

Yes, the latest UML standards threw off the data diagram. Nowadays Entity Relationship Diagram is NOT the part of UML. But the Class diagram still is there in UML and it will be enough.

Simply make a usual class diagram. The only difference is that you shouldn't use n-to-m dependencies, instead make a new class between the ends and you'll have n-to-1 and 1-to-m dependencies instead. Such class diagram can be realized in a database. For better understanding in every class you can set an attribute id to be used in the DB later.

The other thing for such class diagram is that you need not to describe any methods - they don't belong to DB tables. But in the reality you need them - so, I'd create one easier diagram - with instantiable classes and without methods, and the other, more thorough - that one will include also abstract classes, interfaces and methods.

Also, on the first one you needn't put classes that belong to the UI - classes, that show your data and edit them.

The language of UML class diagrams can be used for many different purposes. For instance, for making

  1. conceptual information models
  2. platform-independent information design models
  3. platform-specific data models for all kinds of executable languages dealing with data structures (including SQL and OO programming languages)

Each of these different types of models uses only certain UML class modeling elements, and not others. For instance, in SQL data models we don't use

  • visbility
  • interfaces
  • attributes whose type/range is another class
  • many-to-many (non-functional) associations
  • generalization

In fact, since SQL does not really have any explicit association concept, but only the concept of foreign key dependencies, which can be used for representing functional associations, we better shouldn't use any association in an SQL data model, but rather dependency arrows corresponding to foreign key dependencies.

It also makes sense to define two stereotypes for use in SQL data models:

  1. «pkey» as an attribute stereotype for primary key attributes
  2. «fkey» as a dependency stereotype for foreign key dependencies

See this tutorial for more information.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top