One of the model defined in this methodology is the Entities Model, which consists of identifying the main business entities in the application and its features.
Entities group all the data and behavior of a (real or abstract) object that operates in the system.
This model is meant for identifying and specifying the following elements for each entity:
- The Entity’s components
- The Entity’s properties and semantic classification
- The Entity’s rules
- The Entity’s basic activities
- Services provided
An entity’s data may be scattered in different components, where each of them is designed as a GeneXus transaction with its own data and rules.
An entity may consist of a single component or several components (1 transaction or N transactions).
For instance, four components are defined for the Product Entity, as follows:
 |
| A sample entity |
The criteria for dividing an entity’s data into different components or transactions are given by any of the following causes:
- They describe aspects of the entity that are quite diverse (for instance, data about a product’s purchases and storage constitutes separate components)
- A component may be “turned off” (for example, when a product is not stockable, the storage component must be "turned off")
- These components are used, at different moments and by various individuals (storage data is entered by the ones in charge of the storage and acquisition data is entered by the individual responsible for acquisitions)
- It may be required to associate some generic components with several entities (example: categorization)
- Components are associated with a GeneXus transaction.
The rules applicable to a single component (such as the product having a non-empty name) are defined as rules of each transaction.
Entities may be defined in a generic and extensive manner (indicating its components, data and rules, and services), or, we can also identify the semantics of the entity in the application. We do this with the Entity’s Properties and Semantics classification. Defining semantics for entities implies the specification of its meaning.
Example: When we can define that an entity is an event (something that takes place in an organization) then we can take patterns that have already been thought of for that purpose. We can know some of the requirements associated with the events, and this contravenes the definition of general purposes entities.
Classifying entities semantically enables us to:
- Apply designs already thought of and tested.
- Discover non-explicit functionalities.
- The possibility, in the future, to automate the inference of data, design and services.
A commonly used semantics classification applicable to almost every business application is the following:
- Actors: Individuals or organizations interacting with the application, which include in them the initiative (users, customers, providers, the company).
- Objects: Objects with no initiative in the system. It is possible to specify tangible objects from reality (Products, Currencies) or they may be objects created to classify and define a more sophisticated behavior for systems (Categories, Payment Conditions, etc.)
- Events: Entities that materialize things that "take place" in a company (purchase order, invoice, etc.)
 |
| Entities classification |
With these semantics we can more easily infer the data that the entities could have.
- Data they must have (the entity’s components –address in the case of an actor, dates and planning for events, etc.),
- Rules to abide by (rules of components),
- Services to be provided.
In our system we can have general features or properties that we will want an entity to abide by or not.
Here is an example: an entity may be subject to categorization, extensible (data), auditable, interoperable, or not. By indicating such properties for each entity, we can know the components or functionality we must provide it with (categorize it, and the possibility of defining dynamic attributes, set it as auditable, for it to have the services necessary for interoperating with other entities).
The rules that every component must abide by are designed in the component’s GeneXus transaction. In the product example, the basic data will have its rules and its storage data will have other rules. But if an entity includes several components, there may be global rules for the entity (and not for each component). For instance, in the case of products, when a product may be stocked, it must activate the component of the storage data; otherwise, it must not do it. The articulator of the various components (Entity Manager or Wizard) must manage these rules, regardless of each component’s rules.
There are basic user activities that most entities should have, such as:
- Work With
- Entity Manager
- Selection List (multiple or simple)
- Security
- Possibility to be audited
These activities are generated by K2BTools automatically.
An entity that must interoperate with other entities should provide a group of services to the rest of the application in order for it to be handled in a programmatic manner, from others, or otherwise. They are basic operations that act upon an entity which will provide the rest of the application to enable operations with it without coupling.
Usually, the most common services to be defined are: New, Update, Delete, Get, List, Import, Export.
The entity’s semantics may participate in order to identify the services that it must provide.
For instance, in the case of an entity that is an economic event, we can infer that it will have some kind of accounting records and provide a service that returns the event’s necessary values, for the corresponding accounting to be posted.
|