the Concept of the master, detail, relationships between classes, stereotypes of classes

Key concepts

The data structure defines the structure of the application. The basis of the system is placed to the data structure, expressed as a UML class diagram.

Consider the example of the class diagram concepts on the basis of elementary concepts UML (not the concepts of attribute, method, method parameter, type, role, Association, etc., because they are obvious and entirely borrowed from UML). This class diagram also illustrates typical situations that arise in the design. Any other situation — the implications of this chart.

Class, relatively to which in a particular situation are considered Association, called внутренним классом and the rest внешними.

Вложением (subobject) called class attribute whose type is another class.

Artisans Association

Association similar to the Association between Internal and Master1 called the mechanics, and the outer class from the multiplicity 1 or 0..1 is called мастеровым or мастером.

Artisans Association can be drawn between the classes, each of which is detalam, and hat they have in common. An example of this is the Association Detail2-Detail3.

Decalogue composition, aggregator, hat

Association aggregation or aggregation-composition, such Internal-Detail1 called metalowymi and the external class — детейловым, or just детейлом. Inner class in relation to detailo also called агрегатором or шапкой.


Association of inheritance, such Internal-InternalChild called inheritance, an internal class in the Association — предок and the external потомок.

When you inherit the attribute structure and composition of links is always increasing and can not be reduced.

Flexberry ORM fully implements object-oriented concept, because in addition to encapsulation and polymorphism makes it possible to use inheritance with object-relational mapping.


Classes on the class diagram, the stereotypes attributed to that allows you to specify the appointment of an UML class.

In Flexberry Designer the following predefined stereotypes:

  • Implementation, the stereotype of default (the charts specify an empty value), the usual UML class implemented in the source code of classes of data objects. Classes can contact any ассоциациями;
  • TypeDef, a stereotype indicating the type of synonym. When generating code synonyms are given to basic types in the target language by the user (in the code gets the base type, but a synonym does not specify in any way). The diagrams may not be associated with any ассоциациями;
  • Type, the stereotype to introduce a new type. When generating code in the target language you declare the type, and when declaring members of classes, parameters, etc is used.
  • Enumeration, a stereotype that introduces the enum type. The diagrams may not be associated with any ассоциациями;
  • Interface, stereotype, introducing .Net interface. The interfaces can contact any ассоциациями;
  • BusinessServer, the stereotype, the corresponding business server .Net class, where the implementation of the business operations of applied системы;
  • EditForm, a stereotype that corresponds to the edit form — .Net class, where the implementation of forms for editing of the object данных;
  • ListForm, a stereotype that conforms to the shape of the list — .Net class, where the implementation of the form for displaying list of objects данных;
  • PrintForm, stereotype corresponding to the form of printing .Net class, where the implementation of forms for печати;
  • UserForm, stereotype corresponding to the empty форме;
  • EventArg, stereotype corresponding to the parameters of the event (event), when generating the resulting class inherits from System.EventArgs;
  • Application, a stereotype that corresponds to the application: the form of desktop and adjustment классу;
  • Role, stereotype, appropriate role in the system полномочий;
  • External, a stereotype that corresponds to any external (not declared in CASE, language) class.
  • ExternalInterface, a stereotype that corresponds to any external (non-declared) interface.
  • User can specify arbitrary stereotype.

non-Obvious restrictions of the object structure (what not to do)

Notation UML describes the purpose of its elements, but does not declare the correctness of the» «their use.

Therefore, we consider the main non-obvious restriction that is not described notation, cause difficulty in understanding, impossible in implementation, to avoid.

Cyclic detaily

Detail any level can not be the heir to the caps, as in this case, it turns out that the object of the heir should include himself.

Contradictory aggregation

The heir of detail may not be detalam heir hats.

However ####

This situation is possible: