Business objects are objects in an object-oriented application that represent the entities in the business domain that the software is designed to support. For example, an order entry program might have business objects to represent orders, line items, and invoices.
Business objects are sometimes called domain objects; a domain model represents the set of domain objects and the relationships between them.
Business objects can represent any object related to the domain for which a developer is creating business logic. A business object often encapsulates all of the data and business behavior associated with the entity that it represents.


OBEROn manages business objects: documents and related information / data.

For example, think about products of a furniture industry like chairs, tables, armchairs, sofas and so on; OBEROn can efficiently represents these domain objects filled with all the documents and related information needed by people within the company or by external partners / customers.
When we access to the OBEROn database, we find business objects. Each object represents information needed by the application users.
In this example each chair, table, armchair, and sofa instance is a separate business object in OBEROn.

A business object might be one of the following types:
• A concept such as a part, product, change description, or comment.
• A document such as a drawing, brochure, specification, or memo.
• A description such as a solid model or N/C path.

Object Classes
The business object class defines the business object characteristics, identifies the object type and the collection of features it can have. Each business object has a name or code and is defined as a specific class having specific attributes (fields) and behaviours.
In the furniture example, business objects might be of these basic classes: chair, table, armchair, sofa, etc.

As in an object oriented language, a class can have any number of sub-classes, creating a hierarchy; the sub-classes inherit the parent classes properties (fields and behaviours). For example, the chair class can be sub-divided into modern-chairs, classic-chairs, design-chairs, country chairs and so on; each sub-class adds additional properties and behaviour to the chair's basics.

Each business object is uniquely identified by OBEROn by its class, its name, and if it is versionable by its revision. It can be graphically represented with an icon for its class and with a pictorial image.

Object Fields
Object properties are specified in OBEROn with fields; a field is any characteristic that we can assign to an object or to its link with other objects.
For example, any chair might have fields describing characteristics about itself (description, color, weight, dimensions ...) as well as information related to a product catalog (price, availability, ...).
A field can represent a numeric value (integer or real), a boolean value (true/false), a date, a free text or a specific value selected from a range set.

Object Links
OBEROn manages the connections between objects to organize them into structures of objects.
A linktype is a type of relationship made between associated business objects. These links show how one business object relates to other objects.
In OBEROn we can define many different types of links, each specifying the classes of objects that can be connected. The definitions determine the meanings of each end of the link as well as any field it may have. In addition, to performing database searches for business objects, we can navigate through OBEROn object links and retrieve information without knowing in advance where an object is located or how objects are connected.
Through object navigation, OBEROn makes identification and retrieval of information quick and easy.

Object Attachments
Business objects may have associated documents and other generic files.
An OBEROn object may be used to store files that have been generated by any software application. For example, a Drawing object can have attached CAD files.
The filetype specifies a kind of file (such as TEXT, OFFICE, CAD, etc.) that may be placed into an object. It defines the default extension for the filename (.txt, .pdf, .xls, etc.) and the mime-type which represent the programs to launch for document editing, viewing, or printing.
A single object may have files in various types.

The OBEROn file-put feature allows files of various formats to be managed by the object.
The file is logically placed into a filespace depending on the object lifecycle's rules and it is physically placed into the local file system or into a remote file system associated to the FileSpace.
If we retrieve a file from an object it is placed on our workstation; the file is always copied to the destination folder during file-get operation. The file is not deleted from the FileSpace and remains under the control of OBEROn at all times, until you explicitly delete it.
A file can be locked during the file-get so that no one else can update the copy saved in OBEROn while we are working on it. When we complete the work on this file, we must put the file back into OBEROn in order to update the system with the new version.

Object Lifecycles
A lifecycle is a sequence of stages that an object instance can assume during the its existence. Each class of business object can have different lifecycles. When a new OBEROn object instance for a specific class is created it is associated with a lifecycle selected from those available for that class.
The lifecycle governs all activities at each stage, for example it defines the conditions that must be satisfied for the promotion to the next stage (the progress operation) or to go back to the previous stage (the regress operation). The lifecycle is also a set of rules that determine for each stage who can read and edit the object fields, who can connect or disconnect the object with other objects who can handle the attachments and more access privileges.
OBEROn keeps the history of actions that take place on the business object. At any stage you can define the actions to be monitored and you are able to access and view this history log at any time.

The lifecycle can have multiple branches; it means that we can move the object status from a stage to another skipping other stages in the sequence. In OBEROn this behaviour is called stagefork.
Validations provide a means to authorize the promotion of an object, and indicate at what stage it will move.
If a stage allows more paths toward other stages you can choose the next stage validating its relative validation(s) on the path between the current and the next stage (fork path). A single fork path can have multiple validations to be satisfied so the progress operation can be performed only when all validations are validated (or ignored).
An OBEROn object is fully controlled by its current lifecycle: revisioning schemes, file types associated with the object, file storage locations, access privileges, event management and so on depend on it. A lifecycle may govern more than one class of objects, and there may be more than one possible lifecycle for any object class. But specific object instances follow the rules of just one lifecycle at any one time.

OBEROn actors: user, team, assignments
Within the lifecycle, the various types of access are defined for the roles that people (or actors) have in the application context. The actors can have different access privileges depending on whom they are and their assignments.
A single person is defined in OBEROn as a user. A user definition tells OBEROn who we are and enables us to own and access business objects in OBEROn. Users can be (recursively) grouped into teams. A team identifies a set of users who are members of the same organization, department or division. Members of a team may share access to business objects for a common reason, such as a particular project or functional skills. Depending on current lifecycle-stage different people in different teams may work on the same project or use the business objects related to it.
Within a team, people of different talents and abilities may act in different assignments.
The assignment is basically the role that a user play in the application context or in other words the job function (like director,call operator, sales responsible, product developer). It is possible for a user to have more than one role within OBEROn. For example, a user might be a Designer and a Product Responsible at the same time.

Privileges may vary during an object’s lifecycle, they depend on the object's current stage. Depending on their teams and assignments, users have access in defined ways to specific classes of business objects. In details, an OBEROn user has access to a specific function for a particular object instance if he can directly perform the operation or if he belongs to a team or he has at least an assignment enabled to do so at the current object's stage. In addition, he can inherits privileges form other users on a single business object when these users delegate him to perform the action that they are enabled to.

Object and Link Ownership
Access privileges of a business object may change in each stage, as specified within the lifecycle. In OBEROn the user who may have special privileges for an object respect to other users is called the holder. The holder keeps the temporary ownership of an object and he can manage it according to the lifecycle's rules. The holder can transfer the object's ownership to another user if the lifecycle allows this action. Also link instances have the holder and you can define, in the linktype, special privileges for it. If not changed, the object / link holder is the user who created the instance. Object and link ownership can be temporarily or permanently extended to alternative holders with the same access rights.

Object Revisions
A revision of a business object is a special kind of copy of an object. Usually we use the revision index to indicate a new version (or a review) of an object keeping the main characteristics.
The revised object may have (or not) all of the same attribute values and the same lifecycle of the original. When an object is revised, its class and name remain the same, however, the revision index changes to identify the new object.
The lifecycle's revision rule specifies the scheme for labeling revisions with letters and/or numbers. For example, revision index might appear such as: (numbers) 00,01,02.. or (letters) AA,AB,AC.. or (roman numbers) I,II,III, IV... or (alphanumeric) 01A,01B,01C...