The Business Object Hierarchy Tree [For those who can't code or design]

Introduction

Identifying objects and classes in a business application is often a cumbersome task that starts with the analysis of the requirements given. Requirements tend to be incomplete, unclear and forever changing. During the analysis there could be problems like misunderstanding of the requirements, poor documentation, new ideas and limitations of the proposed design. Therefore a lot of time and effort is spent before finalizing an application's objects and the relationships between objects. Even in good conditions designing objects is a tedious and iterative process. This article attempts to make designing easier by creating a hierarchy tree for all the business objects in the application.

Background

A well-known class in dotnet framework is that the System.Object class which is the ultimate base class of all the classes in dotnet. This class provides basic functionality so that all the dotnet objects have some common mandatory behaviour. In the same way we could have an ultimate base business class for all business objects in a business application so that all business objects have common business functionality and attributes. I have named this class as System.BObject. Here the word 'System' is an alias for the software application being developed and not the System namespace used in the dotnet framework.

Why a base business class?

Business objects are used to implement workflows, business rules, or represent real world objects in an application. Non-business objects usually end up as part of the application's framework where they provide data access, exception handling, event handling, logging and similar functionality. Non-business objects are at times reusable across applications whereas business objects are application specific.

All business objects within a given business application are related to each other, as they are members of the same business application. Therefore they could have an ultimate base class that provides some behaviour common across business objects. By deriving objects from the base object we create an object hierarchy tree. By trying to fit in objects in the hieraarchy tree makes it easier understand their purpose and helps to justify the application's design. If an object cannot be fitted into the hierarchy tree, it would indicate that need for the object has not been understood properly or that the design is flawed in some way.

Advantages of creating the hierarchy tree

Each class would have ready methods and attributes from classes higher up the hierarchy. Whenever required the child classes could either override or shadow methods in its base class(es).

Optionally we could create a hierarchy tree using interfaces. By using interfaces we could easily shift classes between components within an application. The classes implementing the interfaces would have to have its own implementation of the interface methods and properties.

At this stage of design it doesn’t really matter whether you go with classes or interfaces, as the main purpose here is to identify the objects and their attributes, properties and methods.

By placing all business objects within a hierarchy tree we could also up cast and downcast objects. This means we can handle the base object dynamically depending upon what type it can be downcast to. It also allows for parent types to be assigned to the child object similar to what is done using dotnet framework objects.

eg. System.Object o = new System.OutOfMemoryException();

In the above line any derived class of the System.Object class can be assigned to a System.Object type.

Once a hierarchy tree has been created it is easier to identify probable associations between the objects. If we simply defined objects without placing them in the hierarchy tree, it would difficult to even perceive that a relationship could have existed between some of the objects.

For example if we created objects called company, services, customers, users, offers, policies, and departments without putting them in the hierarchy tree it would not be clear how these objects are associated with each other (if at all). A hierarchy tree would not show associations either but it would be easier to identify possible relationships just by studying the tree.

Another advantage of building the tree is that if helps in finalizing the requirements. If the business analysts were to do this exercise along while writing workflows and use cases it would ease their understanding of the scope of the application to be developed and identify shortcomings in their documentation.

Estimation of the application would become easier too. The number of man hours to develop each object in the tree could also be worked out by studying the number of public methods in each object's class or interface. For more information on estimation read the articles 'How to estimate a software project' and estimate man-hours.

How to build the tree?

A few simple steps shown below should get the ball rolling.

· First start by suggesting business objects for your application after analyzing the requirements.

· Then place these object in your tree and show them all as directly deriving from a base object say BObject.

· Identify as many objects however trivial they may seem.

· Once you have a dozen or more objects try to see if any of them share common attributes or have similar features.

· Then place the common features into an intermediate base object which is placed between the BObject and your specific business object.

· Continue doing the above steps and you should have acceptable hierarchy tree in a few hours.

· In case the tree is getting to be too big it could be split up into several diagrams. The first diagram would have only those business objects that are higher up the hierarchy. The derived objects could then be shown in separate lower level trees.

Objects that do not fit into this tree could be framework objects like those used for exception handling, database access, emails etc. These objects would usually inherit from some dotnet framework class or interface while a business object would not. In case one cannot fit all business objects in the tree then treat such objects in utility objects or generalized objects.

A fictitious business application

In the above figure we have a top-level class (ultimate base class) namely the BObject class. Most business objects would normally have an unique identification number or code, a name, a description and an activated status. Let us name the corresponding attributes as ID, Name, Desc and ActivatedStatus. Therefore these attributes could be placed in the BObject class and because of inheritance all the derived classes of BObject would also have these attributes.

Inheritance

Next let us identify some attributes for the Registration class other than those already provided in the BObject class. To register a user we usually have a user name, password, first name, last name, email, address, state, country and telephone. To register a business enquiry we could have customer name, contact person name, email, address, state, country, telephone and requirement details. Requirement details could be another business object having its own class (including derived classes). To register a sale we could have customer name, contact person name, email, address, state, country, telephone, invoice/order number, bill number and receipt number. By observation we can have the email, address, state, country, telephone as the common attributes for the registration class. As the (person/contact/user) name attribute is common across the classes we could create a new class called Name for handling different types of names. The Name class could have properties called username, firstname, lastname, customername, contactname, companyname etc. This would help prevent the base Registration class from getting cluttered with too many attributes and also avoid having to name separate set of attributes in the derived classes. In the same way we could go on identifying and placing common features for a set of related classes.

But the key issue is that without the object hierarchy tree figuring out what objects to create and how these objects fit into the design would be a more difficult task. By first creating the tree using the System.Business.Object as the ultimate base class we can derive the business classes/objects and create the hierarchy tree. This makes it easier understand and justify where they fit in and how to separate out the parent and child classes.

Associations

Another useful feature of creating the hierarchy tree is that we can identify the possible relationships between classes more easily. Looking again at the figure above the following relationships are possible,

Class BObject.Organisation.Division.Department.Team.Member and the BObject.User.Staff [Operator, Visitor, Admin] have a one to one relationship. i.e. one team member can map to only one type of user.

Class BObject.Report.Internal.Sales and the BObject.Registration.RegisterSale could have a one is to many relationship. i.e. the sales report may use several instances of the RegisterSale object to gather details for the report.

Class BObject.Registration.RegisterSale and the BObject.Report.Enternal.Bill could have a one is to many relationship. Here one sale could involve several bills as a sale to a customer could be extended in case the customer requires more items after the first set of items were finalized.

Class BObject.Report.Internal and the BObject.Organisation could have a many is to many relationship. Here the internal report could involve several features of the organization and again an organization could require several types of internal reports.

The RegisterEnquiry class may be functionally more suitable to the user or the Organization but its real parent would be the Registration class. The RegisterEnquiry adds more definition to the Registration class and is related to other classes derived from the Registration class. But it doesn’t add more meaning to the Organization class. Instead it would be an attribute of the Organization class or its derivatives.

The Services and User classes could be an attribute of the Organization class.

Thanks to the hierarchy tree it is easier to understand and finalize the relationships between the objects.

Conclusion

Each business object is related to other business objects for a given system. Once the hierarchy tree has been created for a system's business objects it is easier to understand how the business objects fit into the system and how they interact with each other.

The hierarchy tree represents the entire structure of the business application in a object format.

Links

The Data Hierarchy Tree

http://www.dotnetspider.com/technology/kb/ShowSample.aspx?SampleId=589

email to: diontrish@sify.com