Business Object Design and Implementation Workshop
Business Object Design and Implementation Workshop
Position Paper A
Common Business Object Framework: Experiences from building and
utilizing business objects 
Gerald
D. Zincke (100015.3475@compuserve.com)
Organization
Date/Place: 16 October 1995/Austin, TX
GMO is a well known software-house and consulting company in Austria, Germany and the Czech Republic. Our customers are large organisations in the financial and insurance industry with a strong presence at public authorities too.
Most of the software that we write for our customers are typical business information systems, that are focused around a relational database. It is not surprising, that we looked for a way to build such systems with less effort. So the idea was born to have a framework of reuseable classes, that is especially tailored to business-software development.
Commercially available application frameworks in most cases are GUI-frameworks only. Few of them deal with databases too and when they do it, they do it on a very low and technical level. Therefore we decided to build our own GMO Business Objects (GBO) framework.
In a good OO manner we tried to reuse as much as we could get on the market. We built the GBO framework on top of the Digitalk smalltalk class library, enhanced it with the WindowBuilder from ObjectShare and with the ODBTalk library (ODBC-interface) from LPC.
So we could rely on solutions for basic technical problems and could concentrate our efforts on building support for the ever-repeating problems of business-software.
The GBO Framework supports a multi-user client-server architecture with PC's as workstations and virtually any machine as a database-server. Naturally it can also be used to build single-user PC applications.
GBO applications consist of three parts:
The main task of the framework is to provide base-classes for implementing these parts and to provide the interconnection between the derived classes of the application.
A main goal of development was to keep every user-interface-specific or database-dependent code out of the business logic, that is implemented as business-object classes. With such a definition of business-objects it is more likely that they can be reused between applications.
The second goal was to provide an automatic mechanism to transfer business object data from a (relational) database into object-memory and from the object-memory to the screen and vice versa. Many business applications do nothing more than display data from the database on the screen. Complex computations are rather seldom, but movement of data is quite frequent.
A third goal was to provide a means for manipulating large database-tables. It is not possible to use a Smalltalk collection to manipulate the set of all customers of a large organisation. Object sets with more than a million entries are not so seldom in business data-processing.
An important design-pattern implemented by the GBO framework is that of a sortable and filtered list, called EntityList. That is a type-checked collection that can contain business-objects. The EntityList can be declared as persistent. In that case it directly maps a table in the database. Adding a new business-object to it causes inserting its data into the database, updating a business-object that is contained in a persistent EntityList causes transparent updates on the database and removing an object causes a delete-operation on the database.
A filter can be used in combination with an EntityList to define criteria that must hold true for all elements of the list. If an EntityList does contain business-objects that do not satisfy the filter-condition, they are excluded from any iterator-operation. One or more attributes of an EntityList can be declared as sorting-criteria, affecting the order how iteration is done.
There are derivations of EntityList (LargeList and UnlimitedList) that are especially tailored for handling large amounts of data (big tables). Both of them are persistent by default and provide a similar protocol to access their contents. They do only keep a part of their whole set of business-objects in main memory. EntityLists build a convenient base for implementing scrolling windows as they are needed for typical database-maintenance applications.
In fact the GBO Framework contains several classes that implement such scrolling windows, that can be used for any business object class and for updating any database-table. A simple mapping mechanism eases the task to transfer business objects data to the controls of a data-entry/update window and back. So the GBO framework provides the Smalltalk developer with 4GL-like functions, that allow rapid application development.
Compared with a traditional 4GL the framework offers the advantage, that it can be enhanced and modified in any direction and does not limit the developer in any way.
The framework also implements the pattern of a layout. The layout-classes are used to produce listings on the printer. A layout is a structure that defines how elements of a printout (text, bitmaps, lines) are to be placed on paper. The size of a layout can either be fixed or it can be determined by its contents , for instance the size of the text. Placement of layouts can be done either relative to other layouts or fixed relative to an edge of the paper. There are layouts that can contain other layouts, so it is possible to build a hierarchical structure of a document, that is very easy to modify.
The GBO framework has been used for several projects by our company and has served us very well.
We found, that the concept of business objects brought us advantages right from the design phase. The classes provide a ready-made architecture and the developer can concentrate on the more user-related aspects of the project (user-interface design and business-logic).
Our approach from the ER-model makes it easy to reuse knowledge about data-modeling and CASE-tools in an OO-project. It made it also very easy to find the relational database-design and the mapping from the relational to the object-oriented world.
We found also that business objects allow a rather easy partitioning of larger projects. Several project members can work in parallel without relying too much on each other.
The most important finding for us was that once you have a data-model, software-design in most cases software development is rather simple. We felt no need to use one of the object oriented design methods. There is a tremendous difference between business software design and framework design. Class hierarchies of business objects for instance are flat and seldom contain more than three levels.
The GBO framework has been made commercially available to our customers and we will continue to use it in our own projects. Today it contains more than 75 classes and approximately 1500 methods. It will never be finished. With every project it grows and there are many ideas for improvement. One of them is to make the step from a framework to a library of ready-made business objects for typical problems in business software design such as order-entry.
Business Object Design and Implementation
| Page Hits | |
|---|---|
| This Page |
|
| Since 9/2/95 | |