Framework and Business Logic Components

CHAPTER 5 Theory of ‘Business Logic Components’

So far, we have discussed what a practical and effective component-based reuse system is, by zeroing in on business programs in business fields, such as production management and sales management. In this chapter, without limiting the fields of application, i.e. generally, we will attempt to find out what a practical and effective component-based reuse system is.

Some people with software-development experience have a strong distrust of software components that are nothing but generalized business logic components. This is likely due to the fact that high expectations for software components, which many people secretly harbor, are often shot down or fail to pan out when component-based trials do not go well. Such experiences have fomented distrust.

As we pursue a generalized construction technique for component-based reuse systems, we are realizing that making such a system effective is as hard as discovering a goldmine. Therefore, our inability to realize such a system or our regarding it as impossible now seems reasonable. Moreover, it makes the breaching of the goldmine entrance during SSS (Triple S) R&D feel incredibly fortunate.

In order to understand this matter and to include a sense of conclusion, this chapter will develop our slightly abstract theory concerning a generalized construction technique for component-based reuse systems. We would also like to study the RRR family, a specific example of ‘Business Logic Components’ that we discussed in Chapter 3, in light of this theory.

5.1 Requirements for Practical and Effective Component-Based Reuse Systems

Up to now, component-based reuse in software has been carried out by general subroutines (small unit) or business packages (large unit). Furthermore, component-based reuse on a personal basis for most software assets has been flourishing. Based on the understanding that component-based reuse is carried out in that manner, looking into what a component-based reuse system should be like to have a greater effect, the following three requirements come to mind:

• Software products must be built up solely by combining components.

(Reuse such as with general subroutines when possible is half-hearted.)

• The system must be able to meet all customization requests.

(Responding only to customization requests envisioned ahead of time, such as for business packages, is inadequate.)

• Large numbers of developers must systematically benefit from component-based reuse.

(Component-based reuse on a personal basis will lead nowhere.)

In the following sections, we will individually describe the significance and difficulty of fulfilling each of the three requirements. After reading this information, I would like the reader to judge whether a component-based reuse system would be able to meet the majority’s expectations if all of these requirements were fulfilled.

5.1-a First Requirement for Practical and Effective Component-Based Reuse Systems

According to stories from experienced developers devoted to preparing libraries for business programs in business fields, you reach the saturation point once you collect about 400 general subroutines, and any more you add after that will be used only on very rare occasions. They also say their goal is to cover forty percent of program code with general subroutines, but that is very hard to achieve. It seems there is a limit to the use of subroutines (the extraction of meaningful general functionality).

Many people have probably experienced not getting the business app they expected when they merely combined general subroutines, and there are likely those who felt the limitations of component use therein.

To transcend the sort of component-based reuse system, that uses general subroutines and their built-in call mechanisms, we require increasing the percentage of code that can be covered with components. Accordingly, we should consider the first requirement of a desirable component-based reuse system to be “Software products must be built up solely by combining components” in order to transcend the half-hearted level of using suitable components if they can be found. In other words we are talking about trying to construct one hundred percent of a business program’s program code using only components.

There is probably no need for a long-winded account of the difficultly of fulfilling this requirement, even if we look at the fact that almost no cases of attempting to do so have been reported. There are also those who think that it is impossible to fulfill this requirement because it is too severe.

However, the mixing in of bad currency, that cannot be called components, will have a negative impact even on portions where component use would be achievable, thereby making reuse difficult. Hopefully, it would be achieved by removing bad currency and re-minting them.

5.1-b Second Requirement for Practical and Effective Component-Based Reuse Systems

If all we had to do were meet customization requests envisioned ahead of time, it would be best to develop a business package and then employ parameter customization. You could say that a business package was a system that carries out component-based reuse by thinking of software as a product unit, or in other words, “component = product.”

Transcending the component-based reuse system of a business package requires the ability to meet all requirements as with a custom business program. Accordingly, we should consider the second requirement of a desirable component-based reuse system to be “being able to meet all customization requests,” not just the customization requests envisioned ahead of time. In short, we should aim for a component-based reuse system that is able to develop custom business programs.

The difficulty of fulfilling this requirement can be easily explained using the concept of NCA (Need for Creative Adaptation). Refer to Note 10. We will put aside a description of this term for now. Suffice to say there is a need for solutions through the creation of new programs, i.e. program customization, because NCA is high in business fields, and that is why it is difficult to fulfill this requirement.

Note 10: Creative adaptation here means creating a new program when trying to meet a variety of requests in a certain application field or area and uncreative means, such as setting pre-existing parameters, do not go well. Parameter customization can meet requests in areas in which NCA is low (low NCA areas), but that is not so in areas in which NCA is high (high NCA areas). In the latter case, adaptation by creating a new program, i.e. program customization, is required. Note that a parameter here means declarative information with clear-cut meaning as viewed externally just as with parameters in parameter customization.

A look at business packages will reveal that a gap exists between those with a wide variety of customization requests and those without, depending on the type of business and industry for which they are intended. For example, due to the constraints of legal provisions that must be obeyed in financial accounting, the types of customization requests will also be limited, but in production control, there are a wide variety of customization requests, most likely because possibilities are pursued in a free-for-all environment.

In relation to this, I would like the reader to recall the content of “Topic 1: Dreaming of the “Golden Egg” Business Package” discussed in 1.1 “Differences between Custom Business Programs and Business Packages.”

Perceiving the gap in ease of adaptation in simplistic terms may lead to the false idea that parameter customization can adequately meet all customization requests simply by increasing the number of parameters, even in an application field with a wide variety of customization requests. However, NCA for that application field is what determines whether it is acceptable to think in such simple terms. If NCA is high, there is no end to the parameters that could be added. This may be an overstatement, but new customization requests occur each time a new customer (enterprise) is encountered. Furthermore, there is no knowing what those new requests will be ahead of time.

Consequently, there is no simple answer as to whether meeting a wide variety of customization requests requires a large number of parameters or just a few. If anything, we should question whether the NCA for the application field is high or low by directing our attention to the root qualities causing such differences. Incidentally, many business programs in business fields are developed and were developed as custom business programs rather than business packages because NCA is high in these fields as a general rule.

5.1-c Third Requirement for Practical and Effective Component-Based Reuse Systems

Component-based reuse on a personal basis occurs naturally. There are some painters who draw sketches of flowers and birds ahead of time, and then when the time comes to paint the actual picture, they refer to their sketches on paper or recall them from memory. Component-based reuse on a personal basis for all manner of software assets, such as specifications and program code, is exceedingly common.

Based on this current state of component-based reuse, obtaining more benefits than possible from component-based reuse on a personal basis, or a single pipe, so to speak, requires increasing the number of pipes in order to be effective. Accordingly, the third requirement of a desirable component-based reuse system should be “large numbers of developers systematically benefiting from component-based reuse,” rather than a single person benefiting from reuse on a personal basis.

This requirement assures that it is okay for the people who develop business logic components to be different from those who reuse them (for example, people who develop business packages with special customization facilities and those who carry out component customization). This sort of specialization is possible as long as this requirement is fulfilled. In short, this is a crucial requirement for allowing large numbers of developers to customize business packages with special customization facilities.

The difficulty in fulfilling this requirement is discussed hereafter.

When large numbers of developers start systematic component-based reuse, troublesome decipherment work on source program code becomes a major problem. First of all, when attempting to find modules that must be deciphered, developers may find that the correspondence between programs and specifications is complex or they may encounter modules that the original developers arbitrarily partitioned, making it difficult to even identify what should be deciphered. And then when decipherment starts, many difficulties may arise, such as the need to decrypt programs written in spaghetti-state code and the gradual increase of the range of code that must be deciphered as work progresses. Reusing source program code developed by someone else is generally never easy. Developers are thus faced with resolving these problems.

5.1-d Summing Up Requirements

We have so far provided an in-depth description of the three requirements for a practical and effective component-based reuse system. Refer to Figure 5-1 for a graphic representation of the requirements.

• Software products must be built up solely by combining components;

• The system must be able to meet all customization requests; and

• Large numbers of developers must systematically benefit from component-based reuse.

Figure 5-1: The Three Requirements for a Practical and Effective Component-Based Reuse System

You can probably see how a practical and effective component-based reuse system will result if the three requirements were all fulfilled. Such a system would appear to be able to rationalize the custom business program development industry and business package development industry from the bottom up in business fields. However, I would like the reader to understand the difficult problems that must be resolved before this would be realized.

Fulfilling the first of the three requirements, i.e. “Software products must be built up solely by combining components,” requires reconsidering what business logic components are. The reason for this is general subroutines only cover low NCA areas, and you cannot build business programs in business fields based on that alone.

Accordingly, we must think about building software products using a combination of a number of “component” types. And to cover high NCA areas, we need new types of ‘Business Logic Components.’ It is as if the appearance of an all-star cast of ‘Software Components’ were required by preparing the components that have not taken form on hard disk and then dragging them on stage.

As for the second and third of the three requirements, i.e. “the system must be able to meet all customization requests” and “large numbers of developers must systematically benefit from component-based reuse,” it would be relatively easy to find a method that fulfills only one of them. On the other hand, fulfilling both would be extremely difficult because working out such problems results in mutually exclusive situations as described hereafter.

When a large number of developers aim for systematic component-based reuse, they often fall into the mindset that they must enable reuse even without deciphering programs. However, by doing so they can only do about as much as could be done by parameter customization of a business package. Consequently, it would only be possible to meet the customization requests envisioned ahead of time.

If you aim for a system that must be able to meet all customization requests, you will always be faced by the need to decipher programs. Furthermore, this would seem to be an obstacle to systematic component-based reuse by a large number of developers.

5.1-e Area Covered by General Subroutines

This section discusses an important matter related to the second of the three requirements for a practical and effective component-based reuse system.

The same argument for NCA in the area covered by business packages can also be developed for NCA in the area covered by general subroutines. In other words, the ease of meeting customization requests depends on NCA across the entire application field of the business package, and with general subroutines as well, the ease of doing so depends on NCA in the problem area that they cover. Both cases are exactly the same in substance, regardless of the size of the area itself. There is really no need to repeat the same description here.

We would like to change the perspective here a bit and discuss important matters concerning the area covered by general subroutines. Specifically, it is said that merely combining general subroutines will not yield the business app you expected, so now let’s look into the reason why this is true.

If you think about common subroutines rather than general subroutines, it would be possible to build the business app you expect by developing subroutines and then combining them. This means there is some sort of difference between general subroutines and common subroutines. You can probably deepen your understanding by thinking about what is different while reading the following paragraphs.

When a developer provides a certain subroutine and has a user employ it, various requests for the addition of functionality may result. Sometimes those requests are fulfilled by developing new subroutines and turning them into a subroutine set. For example, adding a subroutine for calculating tax inclusion to where there was only a subroutine for calculating tax exclusion results in coverage beyond what was there before. And if the developer knew from the beginning that there would be both tax inclusion and tax exclusion calculations, it would be best to enable both by establishing parameters in a subroutine for calculating consumption tax.

Anyway, no matter whether the developer meets the requests using a subroutine set or parameters, there are areas that subroutines clearly cover, for example, the calculation of consumption tax.

When a developer develops and provides a subroutine, whether it truly covers the relevant area comes into question. If it does not, the user of the subroutine will claim that the degree of coverage is inadequate. Furthermore, they may make requests, such as wanting to enable the calculation of consumption tax when they select simplified taxation. Since NCA is lower in the area of consumption tax calculation, requests will also be limited. However, in the case of subroutines that cover high NCA areas, there is the potential for endless requests. Such pesky problems have a tendency to pop up. When they do, the only way to handle the situation is to either modify the subroutine each time or turn over the source program to the requesting user and tell him/her to fix it themselves. In short, there is no escaping program customization.

Once a developer encounters, such as situation, they will be criticized for making poorly designed subroutines. Consequently, the subroutine designer will tend to deliberately choose low NCA areas and cover only such areas. In short, they end up aiming to cover every inch of the area by means of parameter customization that combines a subroutine set with parameters. In reality, it is possible to skillfully extract low NCA areas, and if a developer has adequate knowledge and experience in that field, they will be able to cover every nook and cranny of the area. Refer to Note 11. This eliminates the humiliation of having to switch to program customization later on. In short, there will be no annoyances from endless requests. If, on the other hand, the developer decides to cover high NCA areas, it will be highly likely that user requests that cannot be covered by setting up parameters will occur, no matter how many parameters the developer prepares ahead of time and how skillfully the design is. That is why the coverage of subroutines, particularly general subroutines, is limited to low NCA areas, and high NCA areas are left out of general subroutine coverage and remain untouched

In other words, this means there are areas that cannot be covered by general subroutines alone. This backs up the realization many people have had that merely combining general subroutines will not yield the business app they expected.

If you change the viewpoint, all customization requests should be able to be met simply by combining general subroutines, as long as you are talking about low NCA areas. However, there is no such luck in business fields because they are high NCA areas.

Note 11: Even for low NCA areas, developing subroutines without any forethought will cause a variety of problems. This is because subroutines will be poorly developed, which is another problem besides what is mentioned in this chapter.

5.2 Technique for Constructing Component-Based Reuse Systems and an Actual Example

This section will examine what should be done to construct a component-based reuse system that fulfills all three of the previously mentioned requirements.

Although there can be many types of component-based reuse systems, this book focuses on RSCAs. Specifically, when constructing a component-based reuse system capable of component synthesis for application programs in a certain field, this book adopts the idea that the source of the components must exist within the application program that actually runs in the field. Furthermore, skillful surgery on the application program that actually runs to partition it into little pieces (i.e. refactoring the application program to make it component-based) can transform it into a component-based reuse system, which we call a reuse system of componentized applications (RSCAs).

Based on this idea, this section will place the spotlight on RSCAs that can satisfy all three of the previously mentioned requirements. We will start by presenting a generalized construction technique for an RSCA. Next, we will compare the technique with the construction technique for the RRR family, a specific example of a component-based reuse system. Finally, we will evaluate the generalized construction technique for an RSCA.

5.2-f Generalized Construction Technique for a Reuse System of Componentized Applications

The “generalized construction technique for an RSCA” refers to a construction technique that can be applied to non-business fields as well. The details of this technique are described below.

Generalized Construction Technique for a Reuse System for Componentized Applications:

• Partition the area that software products cover into low NCA areas and high NCA areas.

• Cover all low NCA areas by using ‘Business Logic Components’ or ‘Software Components’ that provide the following quality (i.e. quality required of a ‘Black-box Component’):

- Ability to meet all envisioned requests in areas that must be covered by selecting components from component sets and specifying parameters (generality).

• Cover all high NCA areas by using ‘Business Logic Components’ or ‘Software Components’ that provide all of the following four qualities (i.e. qualities required of a ‘White-box Component’):

- Easy retrieval of desired components (retrievability).

- Number of components that must be revised is limited (locality).

- Size of each component is suitable (suitable size; suitable granularity).

- Each component is easy to decipher (readability).

This generalized construction technique was derived by organizing and breaking down the previously mentioned three requirements. For information on the process by which it was derived, refer to Appendix 5 “Generalized Construction Technique for a Reuse System of Componentized Applications.”

Note that if a certain software product can be constructed as a componentized application according to this technique, or in other words, if there is an RSCA that complies with this generalized construction technique, there is evidence for the theorem that the system truly can fulfill the three requirements in Appendix 5.

Since we are using the terms black-box component and white-box component in this generalized construction technique, let’s take a look at what these two terms mean.

A black-box component refers to a component that can be used without deciphering the program in which it is contained. To clearly define the meaning of terminology, this book uses quotation marks specifically for ‘Black-box Component’ when it provides the above-mentioned quality. As will be made clear later, a ‘Black-box Component’ is a type of “software component.” Note that a black box is generally considered to be something that can be freely used without knowing its internal structure.

A white-box component refers to a component that sometimes requires the decipherment of the inner program, before it can be used. As with a ‘Black-box Component,’ this book uses quotation marks for ‘White-box Component’ when it provides all of the four qualities - retrievability, locality, suitable size (suitable granularity), and readability - mentioned above. Refer to Figure 5-2. As we will make clear later, a ‘White-box Component’ is also a type of “software component.” Note that just because something is a ‘White-box Component’ does not mean decipherment is mandatory, but rather you can make heavy use of portions that are usable without decipherment.

Figure 5-2: Qualities Required of a “White Box Component”

What I would like the reader to focus on here is the demand for readability as one of the qualities required of a “white box component.” That is not demanded for a ‘Black-box Component,’ which does not require decipherment.

Note that “readability” includes not only “visibility” by means of structured programming, but also the quality of many things, such as clear-cut meaning and being easy to understand.

5.2-g Comparing RRR Family Construction Technique to Generalizing Construction Technique

Now that we have finished introducing the generalized construction technique for an RSCA, let’s take a look at this generalized technique in light of the construction technique for the RRR family. We will check whether the construction technique for the RRR family is in line with this generalized technique. By doing so, it will become clear that the generalized construction technique is substantive rather than a mere play on abstract terms. Furthermore, the use of an actual example of the RRR family makes it possible to provide a concrete image.

First, let’s look into the concrete meaning of the following statement within the generalized construction technique.

• Partition the area that software products cover into low NCA areas and high NCA areas.

For the RRR family, we extracted portions where the potential for program customization was high according to the partitioning guideline of demarcation of business and operation. Specifically, we narrowed down the portions where the potential for program customization was high to only programs related to business specifications. Consequently, this can be seen as a rough partitioning of low NCA areas and high NCA areas to start with, according to the partitioning guideline.

It should be fine for program portions related to operation specifications partitioned in this manner to be made the same as a general rule for Company A and B, and the need for program customization can be considered as quite rare. Therefore, such portions can be said to be low NCA areas.

At the same time, program portions related to business specifications may have common portions as well as company-specific portions, and these are portions where the potential for customization is high. Such portions can be thought of as high NCA areas or mixed areas.

If we assume that program portions related to business specifications are mixed areas, we should be able to focus on low NCA areas within this mixed area and extract them as general subroutines. This is nothing but the extracting of general subroutines related to business specifications as has been commonly done in the past.

As you can see from the above observation, low NCA areas in the RRR family are program portions related to operation specifications and general subroutines related to business specifications, and high NCA areas are program portions related to business specifications excluding general subroutines. Refer to Figure 5-3.

White portions represent high NCA areas, and they are covered by white-box components.

Black portions are low NCA areas, and they are covered by black-box components. For example, the black ovals in the program portion related to business specifications (NCA generally is high) are low NCA areas that can be covered by general subroutines (black-box components).

Figure 5-3: Areas in Which NCA (Need for Creative Adaptation) is High/Low

The concrete meaning of the following second statement of the generalized construction technique becomes clear once you understand the above-mentioned information.

• ‘Business Logic Components’ or ‘Software Components’ that provide the following quality demanded by ‘Black-box Component’ cover all low NCA areas:

- Ability to meet all envisioned requests in areas that must be covered by selecting components from component sets and specifying parameters (generality).

The RRR family covers program portions related to operation specifications by using general main routines (see Note 12) and partially covers low NCA areas within business specification by using general subroutines.

Note 12: Just as generalizing a common subroutine results in a general subroutine, generalizing a common main routine results in a general main routine (a framework in the narrow sense). Note that, generalization means enabling the ability to meet any envisioned request by selecting components from component sets and specifying parameters. In other words, generalization is nothing but providing the qualities required of a ‘Black-box Component.’

The above-mentioned second statement will be satisfied as long as general main routines and general subroutines provide the qualities required of a ‘Black-box Component.’ In short, they are satisfying one of the required conditions that the RRR family comply with the generalized construction technique. Accordingly, it would seem best to investigate whether such components can really be called a ‘Black-box Component’ that has generality.

It is great to have general main routines and general subroutines, but if we could completely build in what was necessary for providing the qualities required of a ‘Black-box Component,’ we should be able to meet any customization requests for these portions by means of parameter customization. Thus, we should investigate whether customization requests are being met in this manner. Frankly, there are few places where it is difficult to say we can meet customization requests completely, but we can say that the RRR family is more or less meeting customization requests by means of parameter customization. It is rare to have to customize the portions that we assumed as the low NCA areas. Consequently, we can say that general main routines and general subroutines are essentially ‘Black-box Components.’

Furthermore, we also can come to understand the concrete meaning of the following third statement which is one of the generalized construction techniques.

• ‘Business Logic Components’ or ‘Software Components’ that provide all of the following four qualities demanded of a ‘White-box Component’ cover all high NCA areas.

- Easy retrieval of desired components (retrievability).

- Number of components that must be revised is limited (locality).

- Size of each component is suitable (suitable size; suitable granularity).

- Each component is easy to decipher (readability).

The RRR family covers nearly all-high NCA areas (i.e. portions where NCA is high within areas related to business specifications) by using data item components. Therefore, the above-mentioned third statement, which is a required condition for the RRR family to comply with the generalized construction technique, is true as long as data item components provide the qualities required of a ‘White-box Component.’

A look into this to provide a concrete image will reveal that data item components provide the qualities required of a “white-box component” as discussed in the following paragraphs.

The quality of easy retrieval of desired components (retrievability) is one of the major features of data item components (this has already been discussed). Specifically, data item components are easy to retrieve because they are assigned names that begin with the name of their data item. In other words, they take advantage of the feature of specification change requests being represented by data item names in business fields. What I would like the reader to focus on here is the fact that the retrievability obtained in this manner is a naturally endowed quality of components and differs from forced retrieval using a component retrieval system.

The number of components that must be revised is limited (locality). This quality refers to whether there are few data item components that require decipherment and revision when meeting customization requests. To have fewer of such data item components is obviously advantageous. Based on our experience with customization in the RRR family thus far, most of the time the extent of impact is limited to one or two data item components. Having to revise one hundred or two hundred components is very rare. One reason for this quality is related to the feature of specification change requests being represented by data item names in business fields. Another reason can be attributed to the extraction of components according to an orthogonal coordinate system in n dimensional space consisting of n data items. This would not be so if something that differed from the coordinate system of the specification change request were adopted as the coordinate system for component extraction. Decipherment and revision of many locations would likely be required.

To satisfy the quality of the size of each component being suitable (suitable size), components would have to be one hundred lines or less. Any larger and it becomes difficult to say that decipherment would be easy. Based on the track record of RRR component sets, the average size of a single component is 55 lines. And since one data item component is comprised of two or three high-level event procedures (hook methods), it can be partitioned into blocks of twenty lines give or take a few.

The quality of each component being easy to decipher (readability) is determined by whether a component’s meaning is clear, whether its content is simple, whether it is stereotypical, and whether it can be understood independent of other components. It also includes “visibility” through structured programming. Since data item components fit into types, are stereotypical, and have clear meaning, once you have deciphered ten or so, decipherment for the rest will be easier. In addition, as long as you decipher that much, you will be able to understand them without knowing anything about other data item components. Consequently, data item components can be said to be easy to decipher.

Systematic component-based reuse is being implemented by the majority of developers because data item components provide all of these four wonderful qualities (easy retrieval, limited number, suitable size, and easy decipherment). Over three hundred developers who do customization fulltime are actually using the RRR family and SSS in their customization work. These people are not related to the development of the RRR family.

Adopting partitioning with data item association, as one of the partitioning guidelines for the compartmentalization of components is what has made this possible. In other words, you could say that partitioning with data item association was by chance able to fully provide the qualities required of a “white box component”

Based on the three points mentioned above, the RRR family can be said to comply with the generalized construction technique for an RSCA.

Topic 10: Size of ‘Business Logic Components’

The size of ‘Business Logic Components’ (or‘Software Components’) must be suitable and easy to handle.

An extreme point of view is that it would be possible that each and every statement of a program is a primitive software component, but this holds no benefits whatsoever. Although it is possible for a software component, which is compartmentalized according to a certain ideal, to just happen to be a single statement, it is generally clear that software components will only help improve productivity if they are built out of multiple statements.

Nevertheless, they will be unsuitable if they are too big. Something as big as a single business program, for example a business package, should be called a finished product rather than a component. Only if the finished product is built from multiple software components will there be profit in combining semi-finished products.

Programs concerned with a single form or a report form should be called semi-finished products, but there is also the point of view that they are also business logic components. This point of view may seem believable, but there is a problem because no method has been considered for supporting the customization of what is associated with forms and report forms. Here it is required that forms and report forms be built from a number of small business logic components and be easy to customize. In short, there must be a hierarchical structure in which small business logic components build forms and report forms, and these in turn build business programs. If that is the case, forms and report forms can be called semi-finished components, otherwise they are nothing more than mere semi-finished products.

Software components can be classified as black-box components whose contents are not visible and white-box components (type where the source program is disclosed) whose contents are visible. It does not matter how big black-box components are because their content is not subject to decipherment. However, white-box components should be kept at around one hundred lines at most to ensure easy decipherment.

There are also opinions to the effect that size is not the only problem; content must also be closely examined. When you are in a situation where you are using white-box components and you extract one component, a weak, insubstantial component that is useless will be just as troubling as a complex, difficult-to-understand component that is useful. A good balance is important between “suitable size” and “suitable ease of use” for the content of software components.

5.2-h Comparing RRR Family to the Three Requirements

The fact that the RRR family is in line with the generalized construction technique for an RSCA is as previously discussed. Based on that, we can say that the RRR family is fulfilling the three requirements for an effective system because we can deduce it through syllogism if we use the theorem provided in Appendix 5. Specifically, we can deduce this by using the theorem that says if a certain software product is constructed as a componentized application according to this generalized construction technique, it will certainly fulfill the three requirements.

Reaffirming this will simply be repeating our discussion, so in the following paragraphs we will reaffirm that RRR family fulfills the three requirements one by one, while considering whether there are problem points. We will use as critical an eye as possible.

• Software products must be built up solely by combining components.

General subroutines alone cannot satisfy this requirement. Accordingly, the RRR family fulfills this requirement by combining them with general main routines, which fulfill the roles of operability-related processes among other things, and data item components that cover high NCA areas.

The main part of the RRR family is actually comprised of the three components known as general subroutines, general main routines, and data item components. Since each is really a “software component,” we can say that software products can be built from ‘Software Components’ alone.

Strictly speaking, however, there are also cases of accumulated data item components not being able to cover what is needed, necessitating the development of a number of new ones. In addition to data item components corresponding to a single data item object, there are, to a lesser extent, relation check components corresponding to multiple data items and form components corresponding to a form object. Whether these can be called ‘Software Components’ requires some debate.

If we were to make a comprehensive judgment of these, we should probably say that they more or less satisfy this requirement.

• The system must be able to meet all customization requests.

Fulfilling this requirement is no problem as long as it is for data item components for which you are resigned to performing program customization. However, general subroutines and general main routines that do not permit program customization require selective checking. An in-depth look into these will reveal that they basically provide the qualities required of a ‘Black-box Component’ to some extent. Consequently, we can say that the majority can meet all customization requests.

There are, however, unusual cases where the insides of ‘Black-box Component’ must be revised. For example, there are cases where components developed as ‘Black-box Components’ lack adequate generality, as well as cases where the need for creative adaptation rarely exists even if you are talking about low NCA areas.

Although there are cases that necessitate the revision of ‘Black-box Component’ content as mentioned above, the frequency of customization for such areas is low, and they can be handled without problems from a practical standpoint. Specifically, the best response would be to secure a developer who specializes in such customization. Furthermore, since the need for such a response occurs at a low frequency, there needs to be only a relatively few number of specialties. However, if no steps are taken, caution must be observed because of problems that may occur such a “frustrating lack of freedom” that we introduced as a problem with 4GLs.

• Large numbers of developers must systematically benefit from component-based reuse.

There is no problem with fulfilling this requirement as far as general subroutines and general main routines that do not permit program customization are concerned. However, data item components that require program decipherment should be selectively checked. Accordingly, you will find that they provide all of the qualities required of a “white box component.” That is exactly the reason why systematic component-based reuse by a large numbers of developers is possible.

Besides data item components, relation check components and form components are few and far between, and it is somewhat debatable whether they can be called ‘Business Logic Components’ as we have already discussed.

5.2-i Historical Development of Component-Based Reuse Systems

If you look into whether 4GLs and visual development support tools are fulfilling the three requirements for a practical and effective component-base reuse system, you can verify the superiority of the RRR family.

Not even 4GLs or visual development support tools can fulfill all three of the requirements. They only fulfill about half of the requirement that “Software products must be built up solely by combining components.” And although they almost totally fulfill the second requirement that “the system must be able to meet all customization requests,” doing so will end up preventing the fulfillment of the third requirement that “large numbers of developers must systematically benefit from component-based reuse.” In short, it is difficult for the second and third requirements to co-exist.

Based on our studies thus far, we have yet to find a component-based reuse system that can fulfill all three of the requirements, besides systems developed based on SSS tools. Therefore, we consider the RRR family to be on the cutting edge of component-based reuse systems.

Looking back on the history of component-based reuse systems, we can say that the range covered by ‘Software Components’ has expanded as shown in Figure 4-2.

It started with the use of subroutines. In the first stage, only ‘Business Logic Components’ in the form of general subroutines were used, and there was nothing else that could be called ‘Software Components.’ Consequently, the target for component-based reuse was limited to an extremely narrow range.

Next, fill-in systems, 4GLs, and visual development support tools opened the way for the reuse of main routines, thereby widening the range in which component-based reuse could be easily performed. We call this the second stage. The event procedures of 4GLs and visual development support tools, however, were not anything that could be called ‘Software Components.’

After that, we enter the third stage in which data item components will play a major role. For example, by adopting a componentized event-driven system, the RRR family has enabled the use of ‘Software Components,’ which are data item components (i.e. componentized event procedure) that extend the range that general main routines cover and are cleanly partitioned per data item. This makes it easy to carry out component-based reuse for all software products.

5.3 Meaning and Significance of ‘Business Logic Components’

This section will consider the meaning and significance of ‘Business Logic Components,’ not only from a technical viewpoint, but also based on the impact they have on custom business program development firms. We will also clearly show that ‘Business Logic Component Technology’ is effective for not only customization work, but also general maintenance work.

5.3-j What are ‘Business Logic Components’?

The first ‘Business Logic Components’ (in the narrow sense) were born when we were able to prepare them by partitioning them into modules during the development process for the SSS component set. The reason for the name ‘Business Logic Components’ was we wanted to use an analogy with mechanical components where a problem spot is apparent at a glance and limited to a specific component, which means the problem itself will be readily understandable if you extract that component.

At first, the term ‘Business Logic Components’ indicated something extremely specific. Therefore, we strived to widen the meaning by pointing out the thing itself and emphasizing the fact that “such and such is a “business logic component,” but the others are not.”

Generally, when some sort of equipment is invented, such as a hardware device, it seems best to point out the thing itself. In that respect, ‘Business Logic Components’ too is a term pointing out the thing itself. However, the wording “this is what a business logic component is” was regarded as being against better judgment and self-righteous. The thing itself, i.e. source program, which we took the trouble of pointing out, was not understood without protest. People who manage development cannot evaluate programs because they are not in the habit of reading them, and since developers are so proud of the fact that they can develop programs themselves, they are not interested in an approach that renders programming unnecessary.

Accordingly, we conducted a theoretical study and then explained it in this book so that people could understand even without looking at programs. Furthermore, this book clarified the conditions to construct component-based reuse systems as mentioned below when defining ‘Business Logic Components.’ In this manner too we opened a way for discovering ‘Business Logic Components,’ although there is no guarantee that similar things will not be found besides SSS-style ‘Business Logic Components.’ Consequently, a definition of a “business logic component” in a form that clearly specifies conditions will avoid criticism that it is self-righteous, and this might enable us to receive some sort of evaluation. We welcome any evaluations by readers.

The definition of a “business logic component” in this book is as described hereafter. It is a slightly revised definition based on the “generalized construction technique for an RSCA” with which the reader is already familiar.

‘Business Logic Components’ are fragments (modules) that partition and prepare software products covering a certain area so as to fulfill the following three conditions:

Condition 1: Partition the area into a number of modules that cover low NCA areas (these are called ‘Black-box Components’) and a number of modules that cover high NCA areas (these are called ‘White-box Components’).

Condition 2: Prepare and enhance functionality so as to provide the following quality for ‘Black-box Components’:

- Ability to meet all envisioned requests in areas that must be covered by selecting components from component sets and specifying parameters (generality).

Condition 3: Adjust and prepare (i.e. refactoring) partitions so as to provide the following four qualities for ‘White-box Components’:

- Easy retrieval of desired components (retrievability).

- Number of components that must be revised is limited (locality).

- Size of each component is suitable (suitable size; suitable granularity).

- Each component is easy to decipher (readability).

In the final analysis, whether something is a “business logic component” depends upon the definition of a “business logic component.” And whether the definition is thought of as appropriate or not is ultimately a subjective and sense-based judgment of each individual.

As much as possible, I would like people in general to accept that what we have defined in this book are ‘Business Logic Components’ without having to add the disclaimer “according to this book.”

Now we will carefully examine whether the above-mentioned definition is appropriate.

Since the definition is essentially the same as the generalized construction technique for an RSCA, we can deduce from it that the three requirements discussed earlier in this chapter are being fulfilled. Once you understand this, there is no doubt that you will consider this definition to be appropriate.

Conceivably, some may think that the conditions for this definition are too strict. Specifically, they may criticize the conditions by saying there are SSS-style ‘Business Logic Components’ in business fields but maybe not in other fields, or there are only SSS-style ‘Business Logic Components’ in business fields. They may have doubts because they feel it is just like the old trick of a large organization wanting to buy a specific company’s product and a condition for eliminating other products. It is troubling when people say that, but to alleviate such suspicions even a little bit, it is probably better to make the definition in the form of requirements rather than conditions when building ‘Business Logic Components.’ And if the requirements are too strict, we should study how much they can be eased later on.

Based on such thinking, we tried to define a “business logic component” by indicating requirements as shown in the following paragraphs.

We call the components of software products synthesized by a component-based reuse system that fulfills the following three requirements ‘Business Logic Components.’ The following three requirements are the “three requirements” you are already familiar with, and we use them to try to define ‘Business Logic Components.’

• Software products must be built up solely by combining components;

• The system must be able to meet all customization requests; and

• Large numbers of developers must systematically benefit from component-based reuse.

Even if we define ‘Business Logic Components’ in this manner, it may seem almost the same as the previous definition, but it may appear that the scope of ‘Business Logic Components’ widens only by the portion that is vague.

The ‘Business Logic Components’ that descended from SSS, which we have discussed in this book, fit in with either of the above-mentioned definitions. They also obviously fit in with the definition that further eases these requirements.

If so desired, the requirements can even be appropriately eased here.

For example, let’s try to limit the target to which the three requirements are applied to a certain portion of a software product, rather than the entire software product. In other words, let’s make the following changes. Such changes appear to be meaningful.

• Certain portions of software products must be built up solely by combining components;

• The system must be able to meet all customization requests for those portions of software products; and

• Large numbers of developers must systematically benefit from component-based reuse for those portions of software products.

Based on the above definitions, we will call the portions that can be covered by ‘Business Logic Components,’ among those software products, “component-enabled portions” By doing so; we will have component-enabled portions in varying degrees in all application fields. And in the business field, we can say that component-enabled portions are nearly one hundred percent. Furthermore, promoting component-based reuse can be said to be maximizing component-enabled portions in each field.

As an example of easing requirements, let’s say that the scope of the three requirements is portions that can be covered by general subroutines among certain software products. Once we say this, it is obvious that the general subroutines considered to be business logic components in the past really are ‘Business Logic Components.’ When the definition is eased that much, it ends up being just like the old one, and thus there is nothing to be thankful for. Nevertheless, thinking this way enables us to confirm that the definition demanding the original strict requirements includes general subroutines within ‘Business Logic Components,’ and thus, it is in an extended form in order to be more effective. Still, easing the requirements in this manner limits the situations in which they are helpful, making them impractical. Consequently, I would like for them not to be eased too much.

I think the reader’s understanding will grow in light of that. Wouldn’t you give your approval if you could truly accept as the general definition for ‘Business Logic Components,’ a definition in the form of the above-mentioned conditions, a definition in the form of requirements, or a definition that demands maximizing component-enabled portions?

Topic 11: Are ‘Business Logic Components’ Modules?

One person who read a rough draft of this book asked whether ‘Business Logic Components’ were program modules. Since both are fragments into which programs are partitioned, I answered with a conditional yes. Originally, modules were intended to be combined in order to develop software as if making a mosaic. Actually, software is comprised of a number of modules. As a result, there is no doubt that ‘Business Logic Components’ in this book are a type of module.

The reverse, i.e. modules are ‘Business Logic Components,’ is not necessarily true. Generally, module partitioning has a high degree of freedom. What to make a module is basically up to the developer, and thus a module is born as result of arbitrary development. Conversely, a “business logic component” is something that is skillfully partitioned and prepared so as to fulfill strict conditions that are suitable to it. You could say that no matter who partitions modules, they will become blocks just the same, as long as those conditions are fulfilled. Module partitioning conditions are that strict and clear. Therefore, it is hard to think of freely partitioned modules as being the same as ‘Business Logic Components.’

In retrospect, arbitrarily leaving module partitioning to each developer is not a good idea, and that is why partitioning guidelines are created at the beginning of a development project. Thus, we can say that ‘Business Logic Components’ will result if we carry out module partitioning after adopting the qualities of ‘Business Logic Components’ in this book as guidelines. Generally speaking, however, module-partitioning work can hardly be expected to achieve its aims because it has been carried out haphazardly thus far. To better understand this, try imagining a situation where a work instruction for module partitioning is given. I would like the reader to stand in the shoes of a development manager or developer and try imagining what the outcome would be according to the following order. Here, let's clearly define the guidelines.

The special feature of ‘Business Logic Components’ in this book is the covering of high NCA areas with ‘White-box Components.’ ‘Black-box Components,’ the other form of modules, are no particular change from the conventional partitioning method used when extracting general subroutines. Therefore, we will focus on ‘White-box Components’ here. Since the following four statements are qualities required of a “white box component,” we will use them as our guidelines.

- Easy retrieval of desired components (retrievability).

- Number of components that must be revised is limited (locality).

- Size of each component is suitable (suitable size).

- Each component is easy to decipher (readability).

Accordingly, let’s try to imagine a scene where a person in the position of a development manager who points out these four qualities to developers and then instructs them by saying, “Make the fulfilling of all the qualities their partitioning guidelines for module partitions so as to make customization work easier.” There is one important matter when doing so. We should note that rather than simple partitioning, an ingenuity, such as a special technique, preparation, or refactoring is crucial. This is often neglected despite its significance.

The most likely response to this instruction would be for a developer to say, “I don’t have the confidence to skillfully partition even if I am told about such an ideal, but I’ll try to make an effort.” It is actually extremely difficult to fulfill all four of these qualities. Generally speaking, there is no guarantee that partitioning that fulfills them is even possible. Therefore, it appears to be considered as a mere ideal that is impractical. It is also highly likely that the developer will quit after only a halfhearted effort and say, “I tried, but it’s just impossible, so give me a break!” But guidelines are after all just guidelines. Since it is not customary for development to strictly follow guidelines, you can imagine the result when developers consider them to be impossible.

To begin with, conforming to the above-mentioned guidelines requires experience with and knowledge of customization requests. As a result, most developers who do not have this experience just give up. It is probably seen as a form of bullying, like being forced to deal with impossible problems.

However, after receiving the above-mentioned instruction, a developer just might say, “I did it” after succeeding in partitioning and preparing modules that fulfill all four of the qualities, although this is a most unlikely response. This book’s standpoint is if the result were to fulfill the above-mentioned guidelines, then it would be nothing other than a ‘White-box Component.’

Actually, only one partitioning technique that fulfills these guidelines has been discovered, and that was the result of repeated trial and error over more than a year while trying to provide component-like qualities during SSS component set development. This was like trying to strike gold that was unlikely to be found. This was a major success, although the applicable scope was limited to the business field.

It is generally very difficult to carry out ideal module partitioning that fulfills the guidelines as mentioned above. There is little hope of discovering a good method without extensive consideration over at least a year. Consequently, the custom of carrying out module partitioning each time a business system is developed is mistaken. Once an ideal solution to module partitioning is found, that solution must be reused. ‘White-box Components’ in this book indicate components for which module partitioning and preparation has already been completed. Therefore, to enhance a lineup of ‘White-box Components,’ we simply must create them in line with the partitioning method. This is not particularly difficult to do. Devising the ideal module partitioning method is difficult, but reusing that method is easy.

Based on this, ‘White-box Components’ should be perceived as distinct from modules that do not have any special benefits. The adopting of event procedures would be a better comparison.

For event procedures, module partitioning is determined by the combination of object and event types. This aspect is similar to ‘White-box Components.’ In addition, enhancing an event procedure lineup is not very difficult and only requires creating event procedures in line with the designated partitioning method. This aspect too is similar to “white-box components.” However, ordinary event procedures do not fully provide the qualities required of a ‘White-box Component’s. That is where the difference with ‘White-box Components’ lie.

Note that a ‘White-box Component’ layer can be established on an event procedure by revising the event architecture for event procedures and building in a mechanism for update propagation. In short, a componentized event-driven system can be created. MANDALA, which serves as the core of RRR tools, can be called a component synthesis tool that integrates and synthesizes ‘White-box Components’ as previously mentioned into programs that actually run.

5.3-k Near-Future Image of ‘Business Logic Components’

Due to differences in industry and business, there are several hundred business programs in business fields, but if it were possible to develop one business package with special customization facilities per application field, custom business program development firms and business package development firms could rationalize from the ground up. Furthermore, the development of custom business programs for each and every enterprise due to subtle differences in business procedures between customers would no longer be permitted. This is because a component customization on a suitable business package with special customization facilities would suffice, thereby making it possible to supply a perfectly suited business program at a reasonable price.

Actually, it is likely that business programs that are even better suited than before would be demanded. To realize the effect of really utilizing a computer, you must carry out functional tuning while breaking in the business system as discussed in “Topic 4: End-User Development and the Spiral Model” in Chapter 3. Until now, developers could not handle such tuning because of all the redundant, wasteful development, but from now on; they will have the luxury of doing so. In light of this, we can predict that customization firms will undergo a massive transformation into tuning firms, thereby forming a new market.

A lineup of business packages with special customization facilities is required before this can happen. The creation of this lineup is work in which business programs are reconfigured using ‘Business Logic Components.’ This work may seem like a major undertaking because it must target several hundred-business programs, but it appears that the lineup can be completed quicker than thought because of the following three points.

First, the size of the programs that must be developed will decrease (by about one-half or less) because of ‘Business Logic Component Technology.’ In the past, it was usual for COBOL programs to mix together portions related to operation and portions related to business. The use of general main routines will thereby eliminate the need for programs related to operation, which means all a developer has to do is prepare portions related to business as a program (i.e. collect and incorporate portions that have already been developed or develop new ones). Doing so raises development speed just like using a commercially available 4GL.

Second, some ‘Business Logic Components’ can be used across multiple application fields. Just as some subroutine libraries could be used in financial accounting, production management, and sales management in the past, some data item components related to business can be commonly used in a number of application fields, and this can accelerate advances into various fields.

Third, a mad dash of many development projects is expected, and this is likely to have the greatest effect. Since Japan has far more software development firms than the kinds of business programs that are necessary, the lineup will be completed in one to two years if each firm develops one program.

A lineup of business packages with special customization facilities will be completed surprisingly fast because of the above-mentioned three points and this will conceivably rationalize custom business program development firms and business package development firms from the ground up. In reality, not one but several business packages with special customization facilities will likely be developed per application field. And once competition in business packages with special customization facilities begins, firms will not be able to even participate with such competition unless they employ ‘Business Logic Component Technology.’

From a primarily technical viewpoint, this is expected to happen quickly. However, it is also true that there are ill feelings toward the rationalization of software development out there. These feelings are not out in the open like the protest movement against mechanization in the early stage of the Industrial Revolution, but rather they are a touchy matter just because they are deeply woven into people’s psyche. Consequently, there will likely be only a slow change. In particular, the awareness of executives and managers at business program development firms is a crucial key in deciding the pace of change. The pace of change will pick up speed only after they realize that merely gathering people and accepting work is not enough.

Predicting the pace of change in this manner is difficult, but rationalization will surely proceed at any rate. Furthermore, incorporating ‘Business Logic Component Technology’ as soon as possible will surely lead to high profit and high growth.

5.3-l Customization and Maintenance

Thus far, this book has clearly stated that the reaping of the benefits of ‘Business Logic Component Technology’ has been due to customization work, in the broad sense, at custom business program development firms and business package development firms in the business field. However, ‘Business Logic Component Technology’ is similarly beneficial even for general maintenance work.

The software assets retained by large enterprises consist of millions of lines, and the burden of maintenance work for them is becoming a routine problem. Maintenance work is often carried out in-house because it is difficult to contract externally. One theory holds that seventy percent of information department employees are engaged in maintenance work. Alternatively, the cost of tying down a related software development company accounts for a major percentage of fixed costs. A maintenance hell is a word that represents such a dead-end state at an enterprises’ information department. Note that maintenance work can include things like debugging, revisions accompanying business content changes, and miscellaneous improvements, but here we are mainly talking about non-debugging maintenance work.

Customizing a business program for a certain industry/business field into a version for Company A and another for Company B is very similar to maintaining a business program for a certain enterprise to create a Month A version and Month B version. The former customization work is a spatial expansion while the latter maintenance work is a temporal expansion, and therefore, they are essentially the same; it is only the difference of space or time.

By replacing the word customization with maintenance, this book can be changed into a book about improving maintenance work. The problems and solutions when large numbers of developers get systematically involved in trying to meet various customization requests are similar to the problems and solutions when the people besides the original creators (original developers) get involved in trying to meet various maintenance requests.

Still, reaping the benefits of ‘Business Logic Component Technology’ requires a switch to the refined asset architecture of ‘Business Logic Components.’ Unfortunately, this technology is not a magic cure for current maintenance hell. Instead, it is a specific cure for internal improvements at present and the prevention of maintenance hell in the future. Consequently, the sequential application of ‘Business Logic Component Technology’ from development in the works is practical. For example, we recommend it be applied along with a migration to an open system.

Finally, let’s touch on the subject of NCA (Need for Creative Adaptation) in relation to the exchange of time and space. At information departments, there are anguished voices that say such things as “why is so much maintenance necessary?” Actually, this too is related to NCA. The explanation that new customization requests occur each time a new customer (enterprise) is encountered when NCA is high is a spatial perception. A temporal perception results in new maintenance requests occurring as time passes when NCA is high. This is a phenomenon seen in highly competitive industries and businesses subject to rationalization. The special feature of ‘Business Logic Component Technology’ in this book lies in delving into high NCA areas and then using ‘White-box Components.’ Accordingly, we recommend the prescribing of this technology based on a long-term vision as a specific cure for maintenance anguish.

AppliTech, MANDALA and workFrame=Browser are registered trademarks of AppliTech, Inc.

Macintosh is a registered trademark of Apple Computer, Inc.

SAP and R/3 are registered trademarks of SAP AG.

Smalltalk-80 is a registered trademark of Xerox Corp.

Visual Basic and Windows are registered trademarks of Microsoft Corp.

Java is a trademarks or registered trademark of Sun Microsystems, Inc.

===> Chapter 6