Traditional engineerial disciplines are generally characterized by accepted methodical standards for notation, nomination and the use of measurements to specify the relevant result of construction in order to facilitate reusing them in a different context. Hence, o­nly by looking at a constructional drawing, an engineer is able to understand the construction and material properties of any work piece even though it is new to him. Furthermore, he can reuse these engineerial results as a solution for a problem he is facing in his own context, which might be considerably different.
In the field of software engineering and in particular in the field of development of business application systems, the situation looks completely different. To meet this need, the working group 5.10.3 has elaborated a memorandum of Standardized Specifications of Business Components which is available in its first version .

Memorandum and further informations...

To sell business information systems that are made of software components over markets is not a totally new concept: Already in the 1960's, it was discussed in theoretical as much as practical circles. However, a realization has never been achieved.

This leads to the question, which factors have made it impossible to establish markets for business components and what determines the limits for a market coordination.

This branch of our research focuses o­n the empirical assessment of the maturity of the software market and to determine adequate coordinating methods to market software components.

Contact person: Dr. Sven Overhage

To produce business application systems economically from prefabricated components, these have to meet the requirements as exactly as possible. However, practical reasons forbid to produce a separate component for every component. Therefore, components have to be customizable within certain limitations.

An important mechanism for customisation is the parametrization. The developer of a component includes in his analysis various scenarios, how the business component could be used. By setting parameters, the user of a component can decide o­n details of its functionality.

Which concepts of parametrization exist and how this parametrization scope of a business component should be specified is the concern of this working area. The results of this research are aimed to complement the Memorandum of Standardized Specifications of Business Components.

Contact person: Dr. Jörg Ackermann

When planning component-based and service-oriented business application systems' architectures, it is intended to support processes through the reuse of already available components and services. These become loosely coupled to overall systems with explicit dependencies only. In component- and service-oriented design and implementation, it is a particular advantage if the suitability of certain components and services can be assessed as early as possible. This can happen on the basis of supplier specifications which are complete, inter-subjectively comprehensible and, as the case may be, contractually clear. Such specifications can be validated vs. the customers' process models that are to be automated. This implies large amounts of difficult work, especially for the preparation of such tests. Therefore, in real operational businesses there is normally no full check of all possible process paths through the business domain to be automated vs. all specified properties of the supporting software.

An important research topic in this project is the question how, on the software demand side,  the most important business critical processes can be identified and provided with quantified oracles. Another research question is which specified properties of software components can then be checked against process oracles for their suitability to support the identified critical scenarios, and how.

The results of this research project shall improve the design process for business application software architectures through reuse of available components and services based on specifications.

Contact person: Oliver Skroch