Entity Concept

Entities are the bearer and keeper of the application's informational contents. Each entity represents an object that is a natural part of and is important to the business and its business processes. Entity names typically ends up as nouns when the business is described in plain text. For example, customer order, sales part, warehouse, customer, price list, etc.

Defining entities can sometimes be a challenging task. It may be helpful to look at them as different kinds of entities that have slightly different characteristics. For example:

• Orders, requests, receipts and transactions
  These entities are typically quite easy to find, since they convey the transactional data that is processed by the application. For example, material requisition, customer order, travel expense sheet, etc.
• Proxies for external and internal interested parties
  In many cases, the business requires that the application knows quite a lot of the business environment, since that is an important input to the business processing. For example, trading partners with their products and services, distribution channels, etc.
• Things and services that the business is all about
  This is of course an important set of entities, since they describe what the business is all about. These entities are often quite complex and structured.
• Generally available information and known facts.
  The business logic often needs to have a record of things that are commonly used within the business community, particularly when passing information and transactions between business partners. Typical examples of these entities are ISO codes, currency exchange rates, etc.
• Process Settings and Agreements
  Depending on the complexity of the business processes, some of them will require additional data, typically in the form of settings and properties connected to the services provided and/or the interested parties. Examples of that are sales agreements, work schedules, etc.

Each entity contains attributes that describes its contents in adequate detail. To define the attributes and internal structure, the entities are broken down into master/detail structures.

Relationships

Entities are linked together by means of relationships (associations). How entities relate to one another is very similar to a traditional database model.

There are three types of relationships:

1. Parent
   A parent relationship is a link from the detail entity to the master entity in a master/detail relationship. For example. the parent of a CustomerOrderLine is the CustomerOrder.
2. Reference
   A reference relationship is a link to another entity, just like a foreign key reference in a database. For example, a CustomerOrder references a Customer.
3. Generalization
   The generalization relationship is used to indicate that an entity is to be derived from some other entity. The derived entity will inherit all attributes and operations from the base entity. New attributes and methods may then be added to the new derived entity. For example, SalesProduct and PurchaseProduct are derived from Product. Each will inherit the methods of Product.

States

States is a convenient way to control business logic and behavior that depends on information content. Each entity can have a set of finite states that uniquely describes its current contents. An instance of that entity can only have one of those states at any given time.

States are useful in several ways, for example:

1. Validations
   A unique set of validations can be connected to each state, in order to control which modifications to an entity instance that can be made depending on it's current state.
2. Basis for filters
   In many cases, activities that uses en entity as input requires that the entity must have a particular state. Since this is implemented by filters, each state will also typically need a corresponding filter.

Figure:  Entity source editor

This page is generated from IFS Developer Studio - for latest update, see help pages in the tool itself.