The order and specificity of creating class diagrams

Class diagram basics

Class diagram «from analyst» and after object design

When communicating with the customer, the analyst uses diagrams to create an idea of the subject area, which is subsequently refined and supplemented by the developer in accordance with the requirements of the architecture and the generation of the future project. A project with diagrams from the analyst usually contains in the title the specification «As it should be,», and the developer’s project - «Implementation».

The developer details the subject area so that:

  • there are no many-to-many links (intermediate classes are added),
  • there are no aggregation type relationships (only association, composition, and inheritance can be used), as well as one-to-one multiplicity relationships,
  • all attributes have been assigned the data type necessary for storage and processing,
  • there are no contradictions in the structure of the diagram, which can lead to generation failures,,
  • classes have been categorized by type (entity, enumeration, custom type, etc. - more in Module 3 in the «application model» Menu screencast.
  • the diagrams were distributed in catalogs specifying the purpose of classes (reference books, description of a specific group of classes, for example, personalities, territories, etc.),
  • methods were written for the class, if they are needed at the design and prototyping stage of the application.

The developer also creates forms and representations for the subsequent generation of a prototype of the future application. In the next screencast, we will show about adding and editing classes and relationships on a class diagram.

Add and edit classes and relationships

A class can have different sterotypes: entity, application, enumeration, etc. (More details in the screencast Module 3: Application Model). Relationships are mainly established between »entity« classes (implementation). Also, a relationship can be established between an entity and an interface or an external interface.

The properties of an Association

  • Description of relation – explanation of communication (e.g. what it was or why exactly this).
  • Master class role name – the name of the role from the main class, duplicate role name in the diagram.
  • Publication name for maaster class this is the name of the main class property in the OData interface (it is a web-oriented API for accessing and manipulating data).
  • Multiplicity of master class – can be 0..1 (then in the database for the primary class value of the main class may be Null) or 1 (then in the database for the primary class value of the main class can only be Not Null).
  • Master class access modifier is protected (#),that is, access is restricted to the class or type containing the class; public (+), that is, the property is public; private (-), that is, access to the property is restricted. The connection with the main class is stored – this is a flag for generating a field in the database with a reference to the main class.
  • Master class role name is the name that will appear in the main class in the table. For example, for the table Order it will be the Storekeeper.
  • Publication role name for master class is the name of the properties of the main class in the OData interface.
  • Multiplicity of Master class this is * any value.This option supports only for generation. If you need a specific value that is different from *, it is necessary to control in code.
  • Autogenerated TypeUsage – identifier for an attribute that restricts the list of types in the inheritance hierarchy.
  • TypeUsage - an attribute that restricts the list of types in the inheritance hierarchy to which this relationship applies.When using inheritance, there is a problem of determining the right type when using an association.In other words, if the type master is an inheritance-associated type, it is not clear which particular type of the inheritance hierarchy is the master.Class A has a master M, from which there are at least two heirs: M1 and M2. To resolve the problem, you can use special metadata that allows you to specify that a property M (link to the artisan class) in the class data A, in this particular (practical) case, can take only values of type M, and also M1 and M2. This is done at the level of program code. Accordingly, if a data object (an instance of class A) that his master could be an instance of any of the classes M, M1, M2.

A typeusage

  • Name of connection to database is the name of the field in the database in which to store a reference to the master

Properties of the composition

  • Connection description - explanation of communication (e.g. what it was or why exactly this).
  • Aggregator Role name – the name of the role from the beginning of the track that duplicates the role name in the diagram.
  • Publication role name for aggregator is the name of the aggregator properties in the OData interface.
  • `Detail role name - the name that will appear in the main class in the table. For example, for the Order Status table, this will be an Order..
  • Detail Publication role name is the name of the aggregator properties in an OData interface
  • Multiplicity in aggregator is always 1, as in the case of compositions in the database for the primary class value of the master can not be Null.
  • Auto-generated aggregator TypeUsage – similar to the same property of the Association.
  • Aggregator TypeUsage – similar to the same property of the Association.
  • Connection name to Database is the name of the field in the database in which to store a reference to the master
  • Autogenerated child TypeUsage – similar to the same property of the Association.
  • Detail TypeUsage – similar to the same property of the Association.

The attributes and attribute types data classes

Class attributes can be edited from the list of classes in the application model (app Model-group Entities – class click – edit) and charts (Charts-corresponding class diagram-a class is selected-the button edit (icon) – opens the same edit form class). The attribute has name (how it will be displayed in DB and code), caption (as the name will be displayed in the app), description (for example, for which this attribute) and the type. The attribute can be stored and unstored (in this case, its value is calculated in application code and is used for operations in code, without storing in DB). The attribute type must be specified because it is necessary to store data in the database and operations in the program code. Flexberry Designer Online uses built-in data types (string string, int – integer, double point, bool – logical, etc., also there are types to store null values and the ability to create their own type).

The types of relationships between classes and non-obvious restrictions of the object structure

The class whose multiplicity is equal to 1 (in rare cases 0..1 for an association) is the main, that is Master. For example, a shelf and a product on a shelf: there may be many products on one shelf, but the same product cannot lie on different shelves (it is the product, not the type, that is, a specific book, pen, jar, etc.). This connection will be associative, because if the shelf breaks, the product can simply be moved to another. The situation will be quite different with the house and an apartment.There may be many apartments in one house, but a particular apartment always belongs to one house, it cannot be moved to another. Accordingly, if the house disappears, the apartment will also not be. This is referred to as composition. Accordingly, a class whose multiplicity can range from 0 to n will be subordinate, that is, detail class. Classes in relations can be assigned a role (set a name for the foreign key of the database). In the example of the Warehouse application (example of building a Class Diagram) such roles have relations from the Employee class (Manager, Storekeeper, Accountant). The name of the role will be used to name the column in the details’s table for the master table. Show in the class diagram

Limitations when constructing class diagrams

1.Detail of any level cannot be the heir of a master class, since in such a case the object of the heir must include itself

Example of the limitations of charts 1

2.The heir from the detail class cannot be the detail of the heir of the master class.

Example restrictions chart 2

3.You cannot do loops in inheritance

Example constraint diagrams 3

4.You cannot inherit a class from more than one class (a class may have many heirs but only one parent).

Example constraint diagrams 4