| Framework and Business Logic Components | Preface Notes Keywords |
Preface
Conventional, arbitrary software development substantially differs from the development that employs the method of ‘Business Logic Components’ (see Note 1). This difference is comparable to the one between sailing a boat and driving a car.
Note 1: To avoid ambiguous interpretations of the term business logic components, this book offers a clear definition. The term is enclosed within single quotation marks when the definition is met. Also, for generalized business logic components, I give the name ‘Software Component’ within single quotation marks.
On the sea, there is neither obstruction nor paved road that can be seen on the ground; instead, you can see how the wind and waves make their patterns on the sea surface. To take the shortest way to the destination, the ultimate technique of yacht racing would require analyzing the changing patterns to take the fastest zigzag course. However, if not in a race, the course would be unrestrained. Simply by letting the wind decide your course, you could still arrive at the destination.
On the other hand, driving a car on the road shows considerably different characteristics. For example, when going from one place to another, any taxi driver will take approximately the same route. This is not a straight-line connecting two points, nor is it a zigzag course depending on the wind or current; rather, it is a course determined by suitability. On the road, although traffic regulations must be respected, a driver can arrive at the destination by fully utilizing the engine power.
Many of the conventional software development works are likened to a yacht sailing on the ocean. If the ultimate technique of yacht sailing were pursued, the best course for each development would likely be found. Yet, it is possible to develop software without struggling to seek the ultimate technique. In fact, most software development may have allowed the developers to seemingly pursue the ultimate technique, more so for personal gratification than for the sake of efficient development.
On the contrary, the software development that employs ‘Business Logic Component Technology’ (see Note 2) would resemble driving a car on the road. In a sense, this is to benefit from social order by imposing traffic regulations and creating systems. This way, the computer power enables any developer to take the same course without any predicament. This would lead to offering economical, convenient traffic regulations, even though it might diminish their pride to pursue the ultimate technique.
Note 2: I identify the technology of practical and efficient ‘Business Logic Components’ that meets the definition of this book by enclosing it within single quotation marks. Likewise, the technology of ‘Software Components’ that meets this book’s definition is enclosed within single quotation marks.
This book is intended to demonstrate the effectiveness of ‘Business Logic Component Technology’ in developing business application programs in the business field. How can I prove its effectiveness? It can be explained by the underlying fact of the duplicated developments of similar business application programs. Even if two application programs seem similar, for example, there are generally some differences between a program aimed for Company A and that for Company B. For this reason, they are usually developed independently of each other. Yet, if asked, “What are the differences,” they are frequently only slight (at least they are perceived to be so). Accordingly, application programs in the same category should be able to be developed jointly. With differences of ten percent, for instance, the remaining ninety percent can be made common. Nevertheless, this proper sense of making common parts common is considered difficult. Unreasonably, this is commonplace in the business application program development industry.
There are causes that have formed this unreasonable situation. This book presents one methodology to technically analyze those causes and facilitate efficient development by changing that unreasonable situation. In other words, it manifests the fact that practical and effective component-based reuse is possible through ‘Business Logic Component Technology.’ Moreover, it points out a way to make it effective to develop business application programs in the business field.
At this point, let me ask a question before you read further. “What do you think ‘Business Logic Components’ are?”
Many people typically associate them with general subroutines. Others would claim that business logic components are the objects that are based on object-orientation, which is being repeatedly talked about in the topic of component-based reuse. Other than these, there are many different ideas of what business logic components should be. Also, others may still believe that the realization of the idea is a future issue, even with obscure expectations regarding business logic components. Meanwhile, some critical people claim that it is nonsense in the first place to ask the question, “What are business logic components,” since there are no such things as software components. Those kinds of people are likely to criticize saying, “Only putting together general subroutines doesn’t make a business application program. You know what I mean through your experiences, right?”
Hence, there is no standard that defines the term “business logic components.” Whereas some people have ambiguous expectations of business logic components or software components, others deny their existence.
This book offers clear answers to those who are suspicious of business logic components, while demonstrating what is meant by practical and effective ‘Business Logic Components.’ The ‘Business Logic Components’ of this book are results of a few peoples’ challenges in an undeveloped field, but enough activities to publicize its usefulness have not been held yet. Thus, this book is written to fairly take up and report on these newly developed ‘Business Logic Components.’ However, since it would not be very easy to understand the concept only by explaining ‘Business Logic Components’ alone, I also describe related technologies in a comparative manner in this book. Therefore, this book not only explains ‘Business Logic Components’ but also illuminates some of the existing development support tools simultaneously.
I made this book readable for anyone who is interested in streamlining business application program development in the business field. For this reason, I made it easy to understand this book’s main points at issue by inserting them as “Topics.” At the same time, I intend to discuss those points at issue from various viewpoints.
I presume that this book is mainly intended for the following readers; however, any other types of readers will be more than welcome.
• Those who are concerned with the development of business application programs and those who use them in a corporate environment;
• Those who are concerned with the development of usual business packages and those who use them;
• Those who develop business application programs according to customers’ orders and the customers themselves; and
• Those students who are seeking a job such as the ones listed above.
In the recent discussions on ERP (enterprise resource planning) packages, conventional business packages have been reconsidered, and competition has arisen between them and custom application programs. ‘Business Logic Component Technology’ of this book is intended to streamline the development process of general business application programs, including ERP packages, and its applicable scope covers the whole business field. Meanwhile, this technology facilitates to break the wall between usual business packages and custom application programs. Consequently, I believe that this book will surely be instrumental in streamlining a wide range of development processes.
April 1998
Yasuhito Tsushima
p.s. Please mail your opinion to me.
For revision
This book was originally written five years ago. Now, making terms updated to suit the recent environment, I changed the title from “Software Components” to “Framework and Business Logic Components.” The reason is that I felt the need to clarify the issue of “components” since the concept of them has been twisted due to the recent prevailing propaganda that is described later.
Although Microsoft Corporation has promoted so-called VBX (Visual Basic Extension) — later renamed as OCX and then as ActiveX control — as a component, this is the GUI component used by pasting in and designing a form. It is a contributor that built the “component market,” but not a business logic component. Similarly, EJB (Enterprise Java Beans) developed by Sun Microsystems cannot be a business logic component, but rather it is nothing more than a module with a good interface with the middleware, called an application server, even though some people call EJB a component. This is because EJB’s reusability cannot be enhanced without painstaking effort. The reusability of most software products can be improved through continuous efforts. In that connection, EJB is not an exception. Only taking the shape of EJB does not enhance reusability. Though I am happy to see the rise in awareness of ‘Business Logic Components’ in response to the emergence of those would-be “components,” I am concerned about the potential under evaluation on the capability of ‘Business Logic Components.’
In the previous version of this book, “Software Components,” I made clear the requirements needed to be called practical and effective components. Nevertheless, it is not desirable that many “component” believers abuse the term “component” without considering those criteria. It would be understandable if they created new requirements. Yet, saying “components” only as an advertising catchphrase is not acceptable and is misleading.
Yet, it is not impossible that this kind of “component” is considered a “component” in a casual sense. Thus, I re-titled this book as “Framework and Business Logic Components” and set a hurdle to see whether components alone can completely cover business logic.
Now, witnessing this social trend, I cannot help but thinking that the development technologies of business programs have not been improved. Also, it is seen that although taken up as a topic, “components” are yet to be analyzed in depth. Despite this slightly pessimistic view, I can recognize a steady improvement as well, so that I can now describe some concepts with widely accepted terminology that I did not even know what to call when I authored the previous version.
For example, we can now apply the term “refactoring” (used in Extreme Programming) to major surgery that separates programs related to operation specifications from those for business specifications in a settled state.
We can also express what I describe as common main routines in the section of “Demarcation of Figure and Ground When Recognizing Something” of this book, using the term “inversion of control.”
Furthermore, the skeleton routine of this book is a program that covers the frozen area and can be a framework, in the narrow sense. Likewise, the slot of this book means the hot spot, and the supplementary routine units of this book are not different from the hook methods. With the long-term view, we can observe technological progress.
Different from these widely prevailing terms, there appears to be some newly created terms such as operation base. Operation base means the programs for operation that are located at the front-end, on the contrary to databases at the back-end. As for its form, it is generally engineered as a framework, in the narrow sense.
Lastly, note that I designate the term “need for creative adaptation” as NCA in its abbreviated form. This is not an imitative “adaptation” but a creative one (because I needed to create the new term for what had never existed). By the way, at this time careful consideration was necessary to refine terminology, even though NCA was not greatly required.
November 2003
Yasuhito Tsushima
p.s. Please mail your opinion to me.
Author's Notes
In writing this book, I paid attention to the points that are explained below. By understanding them, this book would become more instrumental.
First, let me talk about terminology. In the field of business application programs, there is an agreed-upon standard called the data-oriented approach, which cautions the use of homonyms and synonyms. This book basically follows that standard, with the exception of the following.
I basically tried to avoid synonymy; however, I employed shortened forms for excessively lengthy terms such as “business app” for “business application program,” “business system” for “business application system,” and “custom business program” for “custom business application program.” But, where I need to emphasize terms as “program,” I used the original terms such as “business application program” without shortening them. Along with this shortening process, I changed the term, “custom business application program development firm (industry)” to “custom business program development firm (industry).”
I intentionally did not unify some terms with similar meanings when they involve subtly different implications. “Software,” “program,” and “procedure” are typical examples as well as “gene” and “DNA.”
In spite of the same meaning, different institutions sometimes use different terms for the same concepts. In cases like this, although trying to show their synonymy, I intentionally did not unify the terms.
I also tried to avoid homonymy. To do this, I devised expressions or attached adjectives to potentially indefinite terms to facilitate their distinctions. For instance, I attached adjectives to an ambiguous term “system” so as to separate one term from another unless the meaning is obvious. Some examples are “business system,” “manufacturing management system,” “sales management system,” “component-based reuse system,” “fill-in system,” “component retrieval system,” “component management system,” “prototype system,” and “reuse systems of componentized applications.” In addition, to avoid homonymy, I used capitalization such as “case statement” and “CASE tools” and used italicization such as “parameter” and “parameter.”
In the cases where I assign unique meanings to terms (assignment of a unique meaning to terms), I enclose them within single quotation marks for distinction. They are ‘Business Logic Components,’ ‘Software Components,’ ‘Business Logic Component Technology,’ ‘Software Components Technology,’ ‘Black-box Component’ and ‘White-box Component.’
I mostly use terms in accordance with generally agreed-upon usages, but when I use unique terms that I created in this book, they are, as explained in the main text, extracted and described as “Keywords for Understanding This Book.” The same is true with existing terms that are assigned a particular meaning. Refer to those explanations for terms and the relationships between terms when appropriate.
Aside from the use of terms, italicized parts in this book are intended to explain how to read this book.
Next, let me mention my viewpoint in writing this book.
This book is aimed to make ‘Business Logic Components’ valued fairly, rather than either overvalued or undervalued. Thus, I wrote the book with much care so that no exaggeration would be committed.
Today is the time when the computer is transforming itself from the realm of the mystical to an entertainment system. When the computer was first introduced, it was almost apotheosized, just as words, letters, and paper as mediums were considered nearly mystical a long time ago. Possibly, in accordance with this bygone age, people still tend to blindly accept things as accurate and optimum simply because a computer was used. Beliefs like this mystical idea may be welcomed by computer businesses since they help popularize computers through some kind of mind control effects. Therefore, no effort has been made in redressing it, but we should stop regarding the computer as the realm of the mystical. Used as stationery and as an entertainment tool, a computer does not deserve to be apotheosized. To show how the computer really is, will enormously ease the understanding of it. Any exaggerated expression that may cause illusions should be refrained because there are already a massive number of perplexing technologies in the computer world. So, in writing this book, I tried to negate these illusions, or at least, did not try to promote them.
This book not only discusses ‘Business Logic Components’ themselves, but also compares them to their peripheral technologies. However, this inadvertently resulted in criticizing those technologies partly because we faced the need to redress the over evaluation on development support tools by today’s commercialism and commerce-oriented computer journalism. I then remained consistent, asserting, “The naked king is naked.”
Generally, today’s trendy high-tech keywords contain, more or less, over-expressions. To those who are accustomed to them, this book’s non-sensational expressions may look rather quiet, or it may seem that the book lacks impact because of insufficient high-tech feeling. If one applies to this book a high-tech field’s unwritten rule, the strange principle, “it must be gorgeous,” the book might not be appreciated right away. If possible, I hope you will evaluate ‘Business Logic Components’ in this book with a cautious mind against those bright high-tech keywords. Also, take enough time to read this book because it opens a new perspective that has been left behind, while scrutinizing it with critical eyes to see whether I myself overstate ‘Business Logic Components.’
I could have discussed ‘Business Logic Components’ by focusing on concrete examples of programs just as physics is clearly explained with mathematical formulas. However, usually people, even those who have a strong programming background, are likely to be reluctant to read programs written by others. Therefore, I did not involve programming examples in this book so that it could be enjoyed by anyone.
Due to this orientation, some readers may find explanations in this book abstract. If you are interested in confirming what is argued about in this book with real programming samples, information is available on those samples at the address below:
Programming commonly takes place in each person’s mind, and those who experience that process are only a fraction of the whole population; besides, few efforts are made to show its actual circumstances. In addition, it is difficult to capture the actual circumstances solely by observing programmers from the outside. So, by disclosing the substance, I tried to provide readers with a solid understanding of programming. Refer to Appendix 1 “What Does Running a Program Mean?” if you are not familiar with programming.
Yet, if you have ever speculated about programming simply with your own imagination, it would be better to read this book after resetting your mind to blank. For example, if you believed that writing programs resembles manufacturing products, I would like you to forget it. Similarly, I would like you to forget the idea that software development productivity can easily be evaluated with numbers, if you believed so.
Lastly, let me clarify some points about this book’s main theme, the component-based reuse system.
Because this book begins with the topic of the usual business package, you might have the thought that ‘Business Logic Components’ are something related only to customization work in business packages. However, I emphasize here that that is a misunderstanding. Of course, they are effective in maintenance work, either, and more importantly, in the development work for new application programs, if related to an already developed field. For instance, they are effective in the new development of business fields such as one where Fourth-Generation Languages (4GLs) exerted their effectiveness since they can reuse the results of that field that have already been developed.
Unfortunately, on the other hand, the component-based reuse system is ineffective for software development in a completely new field that is not related to any already developed field (nor is it to a business field). However, once a new field has been developed, it may be changed to the stage where ‘Software Components’ and others flourish. If that happened, component-based reuse systems could exercise their effectiveness in order to utilize the results of the new field. In either way, they are not useful until a development process is completed. To clarify what is meant here, note that this condition applies not only to the ‘Business Logic Components’ of this book, but also to component-based reuse systems in general.
Keywords for Understanding This Book
This section presents this book’s unique terms and the terms to which I assigned a particular meaning.
Generally, at the beginning of a program, variables and constants used in that program are acknowledged. According to this rule, let me explain here the significant keywords in this book, which correspond to the variables and constants.
These terms are explained in the main text as well, so I recommend that you glance through this section and go on to the main text, and that you refer to this section when you are confused about unknown terms.
===> Black-box component
===> Bloat
===> Business logic components
===> Business logic component technology
===> Business packages with special customization facilities
===> Common main routines (framework in the narrow sense)
===> Component set
===> Component-based reuse system
===> Componentized event-driven system
===> Data item component
===> Fourth-Generation Language operation base (4GL operation base)
===> Framework
===> General main routines (framework in the narrow sense)
===> GUI operation base
===> Improvement rate of productivity by reuse
===> Need for Creative Adaptation (NCA)
===> Reuse by copying
===> Reuse by referencing
===> Reuse systems of componentized applications (RSCAs)
===> RRR family
===> Seeds
===> Software components
===> Software component technology
===> SSS
===> White-box component
Black-box component:
Component that is used (usable) without deciphering an inside program.
In other words, they are components that disallow program customization, and the source programs are not usually disclosed.
In this book, the black-box components that have generality are noted within single quotation marks as ‘Black-box Component.’ ‘Black-box Components’ are a type of ‘Business Logic Component.’
General subroutines and general main routines are examples of ‘Black-box Components.’
The argument for this term appears in 5.2-f “Generalized Construction Technique for a Reuse System of Componentized Applications.”
Bloat:
Redundant portion of a program. Although many programs are constructed for a similar outcome, the most compact of them are regarded as the standard with no bloat. With this kind of standard, it is revealed that other programs have the same amounts of bloat as the difference between the most compact one and others.
A typical example of bloat is a redundant portion of a program (removable parts). Another example of bloat is a portion that can be compacted by replacing it with common subroutines but has not yet been compacted. Also, if you re-develop the program stored in the library without reusing it, then that is bloat too.
The argument for this term appears in 4.1-c “Minimum Information Content of a Program.”
Business logic components:
The component sets used for the software component-based reuse system.
General subroutines are a typical example of business logic components.
In this book, the business logic components with particular qualities are noted within single quotation marks as ‘Business Logic Components.’ ‘Business Logic Components’ are categorized either as ‘Black-box Components,’ which have generality, or as ‘White-box Components,’ which have all the four qualities of retrievability, locality, suitable size (suitable granularity), and readability.
General subroutines, general main routines, and data item components are other examples of ‘Business Logic Components.’
The argument for this term appears in 5.3 “Meaning and Significance of ‘Business Logic Components’.”
Business logic component technology:
The technology that utilizes ‘Business Logic Components.’
In this book, the technology that utilizes ‘Business Logic Components’ with the prescribed set of qualities are noted within single quotation marks as ‘Business Logic Component Technology.’
With ‘Business Logic Component Technology,’ customization work can be made extremely easy through “component customization” that can improve the productivity of program customization work.
The argument for this term appears in 5.3 “Meaning and Significance of ‘Business Logic Components’.”
Business packages with special customization facilities:
Business packages that can cope with special customizations, such as custom business programs. Because business packages with special customization facilities must accurately match a customer’s special order, program customization needs to be done in some way. If customization costs can be controlled, a substantial cost reduction can be achieved through business packages with special customization facilities, compared to custom business programs.
SSS and RRR families are examples of business packages with special customization facilities. For these packages, customization costs are controlled through component customization.
The argument for this term appears in 1.3 “Business Packages with Special Customization Facilities.”
Common main routines (framework in the narrow sense):
The routines that consist of common portions extracted from a program that function as main routines rather than those portions that function as subsidiary works. In the majority of development projects, there is the convention to extract common subroutines from programs that function as subsidiary works. So, from a slightly different point of view it should be possible to extract common main routines in the same way.
Some examples of common main routines are the models of a primitive program, the skeleton routines of a classic fill-in system, 4GL operation bases, GUI operation bases, and frameworks in the narrow sense, many of which are mainly used to carry out operational processes in the common process.
In development projects where only common subroutines are the focus, it could be possible to find common portions that have been overlooked by trying to find common main routines that have not been found. If common main routines are discovered, productivity can be improved by reusing them. Employing the object-oriented programming (OOP) language easily facilitates writing common main routines because it can better manage the inversion of control.
The argument for this term appears in 3.2.2-n “4GL and Fill-In Systems.”
Compensated productivity:
The value that is approximated to “true productivity or the value of productivity after completely removing bloat” by revising plain productivity.
Although plain productivity is easily obtained, if one depends on this value, a compact program loaded with dense substance is likely to be undervalued, while one inflated with redundancy is likely to be overvalued. As a result, it could suffocate the effort to compact a program and endorse the attempt to inflate it with bloat. Compensated productivity is a measure invented to avoid harmful effects like this.
To revise productivity, each time bloat is found in a program, subtract the amount of the bloat from the total value to re-calculate productivity.
The argument for this term appears in 4.2-d “How to Compensate Productivity that is based on Number of Program Lines.”
Component customization:
The customization for application programs that apply ‘Business Logic Component Technology.’ In other words, it is the program customization using ‘White-box Components’ practically.
Although the component customization is categorized into program customization, in the broad sense, it is capable of extremely reducing its workload, compared to general program customization.
The reason for the workload reduction is that program codes which should be modified are nothing other than a hundred percent ‘components’ (worthy to be called so). This means, ‘components’ have the favorable qualities that are effective in reducing workload. For example, ‘White-box Components’ require the work to modify its internal codes, even though ‘White-box Components’ have the four favorable qualities of retrievability, locality, suitable size (suitable granularity), and readability - that are effective in reducing workload. By the way, this book insists it is not a “component” if it has these favorable qualities.
An example of the component customization is the business program customization made of data item components.
The argument for this term appears in 1.3-j “Custom Business Program or Business Package? (Part 3: Conclusion).”
Component set:
The set of components that constitutes a component-based reuse system. Also, a component-based reuse system usually consists of component sets and component synthesis tools.
Examples of a component set include a general subroutine library, and RRR component sets for sales management and financial accounting.
The argument for this term appears in 3.2.3-q “Improvements for RRR Family.”
Component-based reuse system:
The system by which software assets are reused in the form of a component or of components.
Component-based reuse systems usually consist of component sets and component synthesis tools.
In this book, I discuss only the component-based reuse system in the form of the reuse system of componentized applications.
It can be said that the call mechanism slotted into a subroutine and the general subroutine library are classic examples of the component-based reuse system. If expanding this classic system with ‘Business Logic Component Technology,’ we can transform a business app into the component-based reuse system that can be solely comprised of ‘Business Logic Components.’
The argument for this term appears in 2.2 “Reuse Systems of Componentized Applications and Object Orientation.”
Component synthesis tools:
The tools that compose a component-based reuse system, which in turn consists of component synthesis tools and a component set.
Component synthesis tools function to elaborate an application program by synthesizing designated business logic components.
Classic fill-in systems and RRR tools are examples of component synthesis tools.
The argument for this term appears in 3.2.3-q “Improvements for RRR Family.”
Componentized event-driven system:
The system created by improving general event-driven systems so that event procedures are equipped with the qualities required of the ‘White Box Component.’
An example of the tool that employs a componentized event-driven system includes MANDALA, which is the core of RRR tools. Event procedures of general event-driven systems have not shown clear partitions among data items. For the componentized event-driven system, it became obvious that these partitions were important, so MANDALA adopted the structure of update propagation to realize this goal.
The argument for this term appears in 3.2.3-s “Second Improvement of Partitioning Guidelines for Compartmentalization of Components.”
Data item components:
The components into which a business app is divided according to corresponding data items. Since in the business field specification change requests are expressed by data item names, if we let data item component names begin with each data item name, we can retrieve the components effortlessly without a sizable retrieval system.
Possessing all the four qualities of retrievability, locality, suitable size (suitable granularity), and readability, data item components are considered a representative example of a ‘White-box Component.’ Also, because the ‘White-box Component’ is a kind of ‘Business Logic Component,’ data item components are a type of ‘Business Logic Component.’
Examples of data item components involve product code components, product unit price components, and important customer code components, and so forth.
The argument for this term appears in 1.3-i “Program Partitioning with Data Item Association.”
Fourth-Generation Language operation base (4GL operation base):
When you think that something may be calling a 4GL event procedure of an event-driven type, that something is the 4GL operation base. Put in another way, the 4GL operation base is something that calls the event procedures and determines when each should be carried out.
Also, it is conventional that when an operation base is developed, it is engineered in the form of the framework in the narrow sense. Furthermore, if developed proficiently, it can become the framework with the function of reuse by referencing, a trump card to improve productivity.
The argument for this term appears in 3.2.2 “Fourth-Generation Languages (4GLs).”
Framework:
In the narrow sense, it is almost the same as common main routines or general main routines.
In the broad sense, on the other hand, it involves not only common main routines and general main routines but also the results of module partition (component partition), including common subroutines and general subroutines.
The argument for this term appears in 3.2.1-j “Second Branch in a Fill-In System.”
General main routines (framework in the narrow sense):
The common main routines altered for versatile purposes. Just as the common subroutine becomes the general subroutine through generalization, the common main routine is changed to the general main routine in the same way.
Also, generalization means to give the ability to meet all envisioned requests in areas that must be covered by selecting components from component sets and specifying parameters. Alternatively put, generalization is not different from equipping a routine with the qualities required of a ‘Black-box Component.’
With object-oriented programming (OOP) language, writing common main routines becomes easier because of the improved facility to manage the inversion of control.
The argument for this term appears in 5.2-g “Comparing RRR Family Construction Technique to Generalizing Construction Technique.”
GUI operation base:
When you think that something may be calling some of the event procedures of a GUI application program, that something is the GUI operation base. Put in another way, the GUI operation base is something that calls the event procedures and determines when each should be carried out.
A GUI (graphical user interface) is a method of visual operation using GUI controls (also known as widgets), such as buttons, menu items, list boxes, or text boxes laid out in a window.
The argument for this term appears in 2.2.2-m “Object Orientation and GUI Operation.”
Improvement rate of productivity by reuse:
The index that expresses how much productivity is actually improved by reuse. An approximate value of the improved rate of productivity by reuse can be obtained by dividing plain productivity by compensated productivity.
The utilization of ‘Business Logic Component Technology’ is a typical example of improving productivity by reuse.
Reuse in this sense can be classified into two categories; reuse by copying and reuse by referencing.
The argument for this term appears in 4.4-l “Improvement Rate of Productivity by Reuse.”
Need for Creative Adaptation (NCA):
The extent to which creative adaptation is needed. Creative adaptation means managing various requirements in a certain applicable area or field by creating new programs when it is not feasible to depend on the passive means of specifying existing parameters. Requirements are met by parameter customization in areas in which the need for creative adaptation (NCA) is low; however, they are not in high NCA areas. In areas like that, the adaptation by creating new programs, or in other words program customization, is needed. Parameters here mean declarative information with clear-cut meaning as viewed externally, like parameters of parameter customization.
Generally, NCA is high in the business field in which creative innovations frequently occur. Yet, as an exception, NCA is not very high in financial accounting since laws and regulations restrain creative innovation.
The argument for this term appears in 5.1-b “Second Requirement for Practical and Effective Component-Based Reuse Systems.”
Reuse by copying:
The reuse method that utilizes the copies of original software. For software reuse methods, there is reuse by referencing, besides reuse by copying.
An example of reuse by copying is the development in which a program model is distributed, and then some modification is made to the copy of it. In addition, the development that employs pre-generators (software tool) is a type of reuse by copying.
Reuse by copying superficially seems to accelerate development processes and improve plain productivity; however, it tends to generate programs inflated with bloat and swell maintenance loads.
The argument for this term appears in 4.4-n “Two Methods for Improving Productivity by Reuse.”
Reuse by referencing:
The reuse method that uses original software by specifying and referring to it, but without copying it. In software reuse method; there is reuse by copying, besides reuse by referencing.
An example includes building and utilizing general subroutine libraries to their fullest. The development by post-generators (software tool) is a type of reuse by referencing as well.
With reuse by referencing plain productivity is not improved since it does not increase the program size. Nevertheless, it can achieve the same outcome as when productivity is improved. Then by getting rid of bloat assets, it reduces the amount of software resources that need maintenance.
The argument for this term appears in 4.4-n “Two Methods for Improving Productivity by Reuse.”
Reuse systems of componentized applications (RSCAs):
The component-based reuse system that reuses componentized applications. For the componentized application, an application program is cut into pieces, each of which functions as a ‘Business Logic Component.’
In this book, I mainly focus on the component-based reuse system exclusively in the form of reuse systems of componentized applications (hereafter RSCAs).
SSS and the RRR family are examples of the products composed of reuse systems of componentized applications.
The argument for this term appears in 2.2 “Reuse Systems of Componentized Applications and Object Orientation.”
RRR family:
A successor of SSS that uses ‘Business Logic Component Technology.’ It adopts the componentized event-driven system, a new system that did not exist when SSS was developed. It also has advanced to ERP packages that are used for sales management, financial accounting, and manufacturing management. RRR consists of RRR tools and RRR component sets.
The argument for this term appears in 3.2.3-q “Improvements for RRR Family.”
Seeds:
The policies, facilities, structures, reasons, ideas, and so forth that improve software development productivity. To improve productivity, we should take up the most effective seed after evaluating the effectiveness of each of them that have been raised as candidates. In order to do this, it is required to calculate the improvement rate of productivity for each of the seeds by a certain method, for example, the build-up method.
Some examples of seeds, that have been around for a while, include the supporting functionalities for address calculations by an assembler, the conversion from a programming language to a machine language, the supporting facilities for the task of writing diagrams, and the extraction of information possibly usable as documents out of programs, to name but a few.
The argument for this term appears in 4.2-e “Implementation Verification for Determining Improvement Rate of Productivity.”
Software components:
The elements that constitute a component set used for software component-based reuse systems.
A general subroutine is a representative example.
In this book, the software components with the particular qualities are noted as ‘Software Components.’ ‘Software Components’ involves ‘Black-box Components,’ with generality, and ‘White-box Components,’ which possess all of the four qualities of retrievability, locality, suitable size (suitable granularity), and readability.
Some examples of ‘Software Components’ are general subroutines, general main routines, and data item components.
The argument for this term appears in 5.3 “Meaning and Significance of ‘Business Logic Components’.”
Software component technology:
The technology that uses ‘Software Components.’
In this book, the software component technology that uses the ‘Software Components’ with the prescribed qualities are expressed as ‘Software Components.’
With this technology, component customization can be used that improves productivity of program customization, so customization work becomes extremely easy.
The argument for this term appears in 5.3 “Meaning and Significance of ‘Business Logic Components’.”
SSS:
The first business packages with special customization facilities aimed for sales management operations (sales management activities) developed with ‘Business Logic Component Technology.’ Consisting of about 2,000 pieces of data item components, it was characterized by its customization facilities. SSS is comprised of SSS tools and SSS component sets. The RRR family is the successor of SSS.
The argument for this term appears in 1.3-i “Program Partitioning with Data Item Association.”
Two-stage customization:
The customization method made by taking up only the best traits of both parameter customization and program customization.
With two-stage customization, ordinary customization requirements are managed by parameter customization, whereas program customization is used as the trump card only when the parameter customization method fails.
In this way, regular customization tasks are easily done by parameter customization, while at the same time any kind of customization requests can be handled by program customization.
The argument for this term appears in 1.1-b “Customization Methods.”
White-box component:
The component that has the characteristics that the decipherment of its inside program may be needed. Alternatively, a white-box component is one for which program customization in the broad sense may be needed, and its source program is disclosed.
In this book, the white-box component with all the four qualities of retrievability, locality, suitable size (suitable granularity), and readability - is expressed as a ‘White-box Component.’ It is a kind of ‘Business Logic Component.’
The data item component is a representative example of a ‘White-box Component.’ Also, the program customization for ‘White-box Components’ is especially called component customization.
The argument for this term appears in 5.2-f “Generalized Construction Technique for a Reuse System of Componentized Applications.”
Copyright © 1995-2003 by AppliTech, Inc. All Rights Reserved.
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 1