Stem Objects

This is a Draft Non-technical White Paper

The Concept.

Many of us in Software Engineering are mimicking Biological functions to greatly improve our processes. Stem Objects is an attempt to do exactly that by mimicking the abilities of Stem Cells.

Software Functions and New Solutions Considered.

The pace of software development and sophistication continues to accelerate. Recent advances offer the potential for addressing the single greatest cost in software development – the organization’s need for a Developer. Finding a better, faster, and less expensive method of delivering application software ready to use would excite company planners and answer key Cost Benefit Analysis questions. In short, delivering products now and inexpensively would enable companies to make software changes for increased productivity and build stronger organizations. Technological advances now permit consideration of a new approach that has these attributes. This concept offers the ability to generate an adapted application from a set of descriptor files so that it is ready to use and adapt “on the fly”. Written in a “high level language”, this application creates any required code structure when needed, but also generates the desired User Interface automatically. It would deliver unparalleled speed by giving developers the ability to move into production parts of a system within hours of the project design being finalized. Also, the developer could respond immediately to the inevitable requirements changes that will abound. This approach also would focus on modifying the description layer of the application, instead of redesigning the lower level code of the project to achieve appropriate adaptation for use. Information Technology tools now permit this concept to be pursued and achieved in a relatively short period of time. So, now is the time to advance this concept to work “on the fly”.

Current Software Development.

Currently, software is developed using methodologies that address getting a product ready for the customer and responding to change requirements by structuring development into three layers – User Interface, Business Objects, and Data Layer. The User Interface is the Windows Screens, Web page, Hand Held Interface or any other interface. The Business Objects are the designated elements (or objects) the application must have to fulfill requirements (e.g. Employees, Orders, Products). Business Objects also have behaviors or activities associated with that Object (e.g. creating a new order, modifying an existing order, etc). Finally, the Data Layer is the database that the application uses to store information and the interactions that occur for each Business Object. This allows development to happen in all three layers at the same time while encouraging developers to leverage previous development code sets to ramp up faster. In the software development industry this has lead to the development of Frameworks. A Framework is a set of code that sets below the traditional 3 layers of application development.

Frameworks are generally very lightweight and can be incredibly complex at the same time. The dilemma with them is that they must provide nearly complete coverage of problems the developers are solving to be useful. This requires a complete description of what is expected. So if one layer of a framework is to provide connectivity to a database for applications it must;

The examples covers the Data Layer, but the largest return on ones investment lies in building a Framework of Business Objects. Problem is each and every business Object must be built from scratch (Employees, Products, Orders). As applications grow and more and more Business Objects are created, the need to build new objects is greatly reduced. Over time, it should take dramatically less time to build applications. While this is very labor intensive, the gains for companies and organizations can be enormous. Industry claims as much as 40% cost savings in application development once the Framework has been matured and used by the company.

Process Review: As Is vs To Be

In an effort to increase efficiency, we took this concept one-step further and used XML for both describing the Business Objects and the Database Interactivity. This allows for complete separation of the “most often changed items” from the compiled code into a document external of the application. Therefore, such changes no longer require us to recompile the application and complete a redistribution.

This started us to thinking; since the descriptions are already external of the code, in XML why not build one lower level framework that would generate the Business Objects when needed based on the XML description. This would give developers the ability to change the behavior of an Object easily and “on the fly”. For example, if there is a new requirement to modify an existing order, the change to that code would be made instantly in the XML. Then, from that moment on without any redistribution or recompile the behavior of the Order Object is changed.

The picture would now look like this.

New Solution

So the challenge is how to build an underlying code set that generates the business Objects for applications being developed at a company inside the framework.

Technological advances now permit us to build the Objects at Runtime, i.e. “on the fly”, by creating the Object from a library of built, but not described, behaviors. These behaviors are already described inside the XML for each Object, so using those descriptions to build the Objects on the fly when needed.

This also gives us the ability to generate the User Interface for each type of Object. Such advances get us to the ability to automatically generate the User Interface based on the description of the Object in XML.

1.Who will benefit from this technology

All Object Oriented application developers would benefit from this technology, especially those in a highly evolving application development process with daily requirements changes. By pulling the Business Objects into a much lower level Framework for generation at runtime the developer only has to describe each Object and its Behaviors in a hi level development environment (Yet to be developed). The framework takes care of the rest. For instance, it could generate a web page that allows users to create a new order from a list of products, fill out payment information and delivery options all from the XML.

2.Why will they benefit.

Applications will be built faster with more reliable code. This would force developers to leverage previously created code sets for their Objects. As the Object library grows, the need to create new ones decreases. Developers have the greatest gain in their ability to modify the Objects behavior to respond to changing requirements.

3.Where is the market, how potentially large is the market

The market is potentially as large as all software development. Certainly, all who are developing inside the technology this is written in (Microsoft .Net, C#) will benefit the most and the soonest. Frameworks are usually written in a manner that they can easily be used from most any development technology. Therefore any application developed that uses Business Objects and displays them for a user would benefit from this technology.

4.When could this technology be available

5.What will be the effort required to complete, what $$, what resources are necessary?

There are 3 main holes identified in the development of this product. Managing the creation of the Objects in the required order. Controlling the access levels to the Objects. Two current software packages have been identified that could potentially address the two largest holes, managing the Objects permissions and Creating the User Interface from the Objects description. These packages would need to be converted to our development environment. Potentially the only other holes are the Intelligence Engine and the Hi level development environment. Converting the existing packages and finishing up our work will take a small team of 4 developers one year to complete.

6.What are the barriers to completing development of the technology?

Time, Money and Technology Itself. Time and Money are self-explanatory. Technology: While building the Business Objects and Generating the User Interface for each type of Business Object is certainly doable, the main problem to be solved is managing the process of Object creation, its permissions and destruction. There are times when one Business Object will be reliant on the existence of another Object. So managing the order of creation will be an issue, but is certainly doable. The larger problem is of course the hardest to solve, but is solvable with incredibly strong designs and code development. The problem is, imagine an employee is created by a Human Resources (HR) application. While HR needs the rights to add/delete/modify an employee, other applications that just need the information about an employee certainly don’t require the same level of access to that employee. So are the Business Objects of the two employees created separately or are the limitations to certain behaviors of an Object managed separately?

See also NakedObjects?

You might try separating paragraphs with a newline to improve layout. Does the second paragraph under "New Solution" say what you meant it to?

This is a case of AuthorsDontRead, this is old stuff, nothing new here, its already been done many times, they are called ActiveObjectModels or AdaptiveObjectModels, not StemObjects. These systems are cool, some of the best stuff out there, but they are essentially an interpreted language on top of an existing language, and can be incredibly complicated if the authors don't realize they are building a language.

EditText of this page (last edited September 21, 2004) or FindPage with title or text search