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,
Business objects are sometimes called domain objects;
a domain model represents the set of domain objects and the relationships
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
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
A concept such as a part, product, change description, or
A document such as a drawing, brochure, specification, or
A description such as a solid model or N/C path.
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)
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 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.
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.
Business objects may have associated documents and other generic
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
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
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.
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
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 objects
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.
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)