Domain-Oriented Software Process Re-engineering with Software ...
Proceedings of the 10th Knowledge-Based Software Engineering Conference (KBSE-95), pp. 97-104, Boston, November 1995.
Domain-Oriented Software Process Re-engineering with Software Synthesis Shell SOFTEX/S
Akiyoshi Sato,y Minoru Tomobe,y Toru Yamanouchi,y Masanobu Watanabe,y and Masashi Hijikataz y C&C Research Laboratories zDistribution and Service Industries Systems Development Division NEC Corporation 4-1-1 Miyazaki, Miyamae-ku, Kawasaki, 216 JAPAN [email protected]
2.
process reorganization to assign the unit work to persons and generators and to design the software process ow, and 3. forward engineering to design and implement the generators. In domain-speci c re-engineering, the re-engineering methods themselves are reusable for other domains even though the software synthesis systems are not reusable. From the view point of overall productivity, the total cost reduction due to re-engineering is given by the following equation: (overall cost reduction) = ( 0 ) 2 0 (1) where
Abstract
This paper proposes a domain-oriented software process re-engineering method that allows for ecient software process modeling and cuts overall software development cost. This is achieved by use of a software synthesis shell that supports the development of program generators from input speci cation syntax and rewrite rules. Application of the proposed method to the development of a large scale \chain store management system" resulted in the development of a speci cation checker, two program generators, a speci cation document generator, and a test data generator. The overall development cost, including re-engineering cost, for this store management system has been reduced by 164 man-months. 1
A
Introduction
Many software synthesis systems have been proposed in order to improve the productivity of software development, and some have succeeded in automating the programming phase [1] [8] as well as the design phase [3] [5] [6] by limiting the application domains. Although software synthesis can be regarded as a process reorganization { so-called re-engineering { for software development, these domain-speci c software synthesis systems focus on automating a speci c phase in the software life-cycle rather than on the overall process for software development. This neglect of the overall process re-engineering view point is one of the main reasons that software synthesis systems that are ecient in some domains are not easily used in other domains. This paper proposes a domain-oriented software development process re-engineering (DSPR) method using the software synthesis shell SOFTEX/S [7] and describes its application to the development of a large scale \chain store management system." The DSPR method consists of the following steps: 1. reverse engineering to analyze the domain and abstract unit work,
B
N
C;
A is the development cost with the conventional software process, B is the development cost with the new software process, N is the number of application systems developed with the new software process, C is the re-engineering cost.
In the development of general-purpose software processes, is large and ( 0 ) 2 , thus the re-engineering cost may be ignored. For domainspeci c processes, in contrast, the number is small and the re-engineering cost is an important factor determining the overall cost reduction. If the reengineering cost is high, re-engineering is not ef cient for a domain with a small The DSPR method proposed in this paper therefore reduces the re-engineering cost by using a software synthesis shell to support the forward engineering process generating generators. This approach improves overall productivity even for a small domain where only a single system is developed. N
A
B
N
C
C
N
N:
2
Target
Domain
Software Process
1
and
Conventional
GUI layout design
GUI layout check
Call-back function design
Test data design
Design and Implementation
Program test
GUI layout correction
Test
Call-back function correction
Debug
Figure 2: Conventional process for developing the software for the chain store management system. company are usually developed by using generalpurpose GUI tools with the Motif widget library and the C language, and these GUI systems are running with a full keyboard and a mouse. The characteristics of the store management system are di erent from those assumed by general purpose GUI tools. Therefore, there was great need for domain-oriented
Head office (computer center) Chain store
(a) Interactive
subsystem
Store computer
Order data input, Working hours management, etc.
(b) Batch
software process re-engineering.
subsystem
Sum up the sales, Exchange master data with a host computer, etc.
2.3
As shown in Figure 2, one cycle of the software development process before re-engineering consists of (1) GUI layout design, (2) GUI layout check, (3) call-back function design, (4) test data design, (5) program test, (6) GUI layout correction, and (7) call-back function correction. This process has the following two problems: each phase is totally manual { there are no e ective (general-purpose) GUI tools that can be used because of its hardware and software specialties, and the process is fully sequential { parallel development by many people is dicult. These problems increase the cost and lengthen the development term. With the conventional software process, the whole cost of developing the chain store management system is estimated to be more than 300 man-months. Despite these problems in the development process, there are no problems in the target software model (architecture) itself. Thus the target software model in this paper will be the same before and after re-engineering.
Figure 1: Target domain: chain store management system. 2.1
Chain Store Management System
2.2
Domain straints
The target software domain here is a chain store management system running on store computers. This system (Figure 1), is used daily by storekeepers and clerks to place an order, check the stock, manage working hours and do everything else related to store management. Each computer in a store is connected with a head-oce host computer through a wide-area network. The functions of the chain store management system can be classi ed into two parts: an interactive subsystem (e.g., to input ordering data or con rm the working hours of clerks) and a batch subsystem (e.g., to sum up the sales and to exchange master data with the host computer). This paper targets the development of an interactive subsystem that users operate through a graphical user interface (GUI). Thus, the main part of this software development is the development of GUI and call-back functions. This subsystem has about 200 GUI windows. Characteristics
and
The Conventional Software Process
3
Con-
Domain-oriented
Software
Process
Re-engineering
The characteristics of the target system are shown as follows: (1) with UNIX operating system and X Window system, (2) with a touch-panel and a small special-purpose keyboard rather than with a mouse or a full keyboard, (3) with a special-purpose compact widget library, and (4) to adopt COBOL as a development language. These characteristics were determined after careful consideration of cost and performance. Most X Window-based GUI systems in the authors'
3.1
Re-engineering Process
3.2
New Software engineering
The DSPR method (Figure 3) consists of the following three steps: (1) reverse engineering, (2) process reorganization, and (3) forward engineering, as described in Section 1. Process
after
Re-
The new software process for the target domain, after re-engineering by the DSPR method, is shown 2
Unit work for persons and generators 1. Reverse engineering Conventional software development process
GUI layout designer
Reorganized software development process flow
2. Process reorganization
(H1)
3. Forward engineering using the software synthesis shell SOFTEX/S
New software development process
Specification checker (G1)
Re-engineering
Check result
Figure 3: The method of the domain-oriented software development process re-engineering (DSPR). : using a generator
GUI layout (G1) check
Test data designer (H3)
( ( ( (
Debug
Design and Implementation
W W
GUI program
Event dispatcher Call-back function
Call-back function designer
link Store computer program
(H2)
Tester (H4)
W W
2) Event dispatcher design and programming, 3) Call-back function design and programming, 4) Test data design and implementation, and 5) Testing programs.
3.4
Process Reorganization Step
(1) Assigning the unit work
Figure 4: The re-engineered software development process for the chain store management system.
The rst substep in process reorganization is to assign the unit work to persons and generators, and to arrange them on a software design environment. Persons will be in charge of creative work and generators will be in charge of monotonous work. The reorganized and generator-based process structure shown in Figure 5 has three types of human designers and one types of human testers: ( 1) GUI layout designers who design, from requirements, GUI layout speci cations with arrangements of GUI objects and de nitions of their attributes. These designers take charge of the design part of ( 1), and they check the GUI layout speci cations in prototyping by using a speci cation checker. To reduce the editor development cost, general-purpose drawing tool \Tgif" has been used as the GUI speci cation editor. ( 2) Call-back function designers who design callback functions by referring to call-back function speci cation documents and event dispatcher structured program diagrams (SPD). They take charge of part of ( 3). These two documents are generated from GUI layout speci cations with generators to support cooperating design with GUI layout designers. ( 3) Test data designers who design test data by re-
in Figure 4. It is totally automated with ve generators and enables fully parallel development, so that the problems mentioned in Section 2.3 are solved. 3.3
(G2)
Event dispatcher generator (G3)
Call-back function specification document generator (G4) Call-back function specification document
Figure 5: Structure of the new software process after the process reorganization step.
Program test
Test
GUI program generator
Test data generator (G5) Test data
Call-back function correction
(G5)
GUI layout specifications
Test data specifications
GUI layout correction (G2)
(G4) Call-back function design Test data design
Test data structure specifications
(G1): Specification checker (G2): GUI program generator (G3): Event dispatcher generator (G4): Call-back function specification document generator (G5): Test data generator
GUI layout (G2) GUI layout (G2) outline design (G3)detail design
Human work Generator work
Reverse Engineering Step
The reverse engineering step analyzes the domain and abstracts the unit work for a software process. This step uses domain-speci c business knowledge related to the target domain. First, the interactive subsystem for the chain store management system is based on a graphical user interface (GUI), as described in Section 2. Thus, there is the unit work for the GUI layout design and programming, which is based on the X Window system. Secondly, many GUI events occur with GUI operations, and all the call-back functions are invoked by the GUI events (e.g., pushing buttons and entering data). Thus, there is the unit work for design and programming for event dispatchers and call-back functions. Thirdly, there is the unit work for testing the above-mentioned programs. The unit work for the target domain is therefore the following: ( 1) GUI layout design and programming,
H
W
H
W
H
W
3
GUI layout outline designers and the call-back function designers. Test data can also be designed in parallel with the GUI layout detail design and the call-back function design, because the test data speci cations depend only on the GUI layout outline designs. In the debugging phase of the process, the GUI layout correction and call-back function correction are also done in parallel.
ferring test data structure speci cations. They take charge of the design part of ( 4). ( 4) Testers who use test data to test GUI programs and store computer programs, and who report the test results to the designers. They take charge of ( 5). Figure 5 shows the generator structure after the process reorganization. There are the following ve generators: ( 1) A speci cation checker that detects errors in GUI layout speci cations. It takes charge of part of ( 1). Because a speci cation checker has been regarded as a speci cations checking result generator, a checker has been developed as a generator. ( 2) A GUI program generator that generates GUI programs from GUI layout speci cations. It takes charge of the programming part of ( 1). ( 3) A event dispatcher generator that generates event dispatch programs from GUI layout speci cations. It takes charge of the programming part of ( 2). ( 4) A call-back function speci cation document generator that generates two types of call-back function speci cation documents from GUI layout speci cations. It takes charge of part of ( 3). ( 5) A test data generator that generates test data from test data speci cations. It takes charge of the implementation part of ( 4). W
H
W
3.5
G
Software Synthesis Shell SOFTEX/S
The system concept for SOFTEX/S [7] which is used in forward engineering step described in the next subsection, is illustrated in Figure 6. This software synthesis shell supports the construction of software synthesis systems (generators) for each software model. Software model here means the combination of a speci cation model and an implementation structure. This shell has a language DSL to de ne a speci cation language for each speci cation model as well as rewrite rules, and a term rewriting rule compiler [4]. A software synthesis system for a speci c software model can therefore be constructed from the de nition of the speci cation language syntax and rewrite rules.
W
G
W
G
W G
Input specification language syntax
W
Rewrite rules
G
Software synthesis shell
W
SOFTEX/S
(2) Designing the software process ow
The second substep of the process reorganization in reengineering allocates the unit work into a ow chart. That is, it designs the software development process
ow. This substep uses knowledge of dependency between the work of people and the work of generators. The independent work will be in parallel as much as possible. Figure 4 shows the new process ow reorganized from the conventional process shown in Figure 2. There are ve generators to automate the software process. The GUI speci cation checker ( 1) automates speci cation checking. To develop the GUI layout design and the call-back function design in parallel, GUI layout design was divided into two parts: outline design and detail design. The GUI layout outline design selects GUI objects that are necessary for interactive subsystems of the store management. The detail design determines the attributes for the GUI objects (e.g., color and line-width). Once a list of GUI objects is selected by GUI layout outline design, GUI object attributes and call-back functions can be designed independently, and thus in parallel. The callback function speci cation document generator ( 4) supports this parallel designing by visualizing the list of GUI objects. 4 acts as an interface between the
Input specifications
Domain-specific software synthesis system (generator)
Output program
Figure 6: The concept of SOFTEX/S. Speci cation language syntax is de ned as a manysorted signature which consists of sort symbols and function symbols. Termdef and sortdef primitives of DSL enable the syntax of a speci cation language to be de ned by adding new function symbols and sort symbols on a signature. Each rewrite rule, which is speci ed with a relation primitive, consists of two terms: a lhs-term and a rhs-term. If there is a term in speci cations uni able with the left hand side of a rule, then the term is rewritten with the right hand side of the rule. The variables used in rules are de ned with a vardef primitive. The term rewriting rule compiler compiles rewrite rules into executable generators. DSL's syntax is as follows:
G
, , ... ; ( param1-sort, param2-sort,...) term-name1, term-name2, ... ; vardef var-sort var-name1, var-name2, ... ; relation rule-name eql ( lhs-term, rhs-term )
sortdef sort-name1 sort-name2 termdef sort-name
G
G
4
3.6
GUI layout specifications
Forward Engineering Step
This step uses the software synthesis shell SOFTEX/S. (1) Designing generator input/output syntax
SpecifiGUI cation program checker generator (G1) (G2)
This substep uses the knowledge of a formal language. Each generator is developed as a many-sorted term rewriting system, so their input and output syntax are de ned as a many-sorted signature. The following signature 61 determines the subset of the input speci cation language syntax of the speci cation checker ( 1), the GUI program generator ( 2), the event dispatcher generator ( 3), and the call-back function speci cation document generator ( 4):
Check result
Call-back function specification document generator
Event dispatcher generator (G3) Event dispatcher Call-back function program
GUI program
G
G
(a) The structure of generators: G1 to G4.
(G4) Call-back function specification document
G
f
61
G
GUI layout specifications
= sortdef FigureObj, ColorAttr, CoordAttr, FillAttr, PenAttr; termdef FigureObj(ColorAttr, CoordAttr, FillAttr, PenAttr) box; ...
GUI object selection (SG1)
g
GUI object list
The sort symbol FigureObj means GUI objects (e.g., boxes and strings of characters). Sort symbols ColorAttr, CoordAttr, FillAttr, and PenAttr mean attributes of GUI objects. The function symbol box constructs a box as a GUI object, which has a sort of FigureObj, with the arguments of ColorAttr, CoordAttr, FillAttr, and PenAttr. This signature 61 for example, constructs the following input speci cation : T = f box('black', coord(236,314,364,362),0,1),
SpecifiGUI cation checker program subsubgenerator generator (SG3) (SG2) Check result
;
GUI program
T
...
g
Because the general-purpose drawing tool Tgif is used as the GUI speci cation editor, GUI objects are de ned as combinations of Tgif gures such as boxes, lines and strings. The above-mentioned black-colored single box means a GUI label object. In similar ways, other input and output speci cations can be de ned as many-sorted signatures.
Call-back function program
Call-back funciton list (MS2) Call-back Event dispatcher function subgenerator specification (SG6) document subgenerator Event dispatcher (SG5) (MS3) Call-back function Call-back function specification document program merge (SG7)
Figure 7: Generator structure for the chain store management system.
G
Table 1: The subgenerator composition of each generator G1 G2 G3 G4 SG1
SG2
SG3
SG4
SG5
SG6
SG7
G
G
G
C
G
SG
(SG4)
(b) The new generator structure after subgenerator sharing.
The second forward engineering substeps is to design generator structure, and the key point of this substep is subgenerator sharing. Figure 7 (a) shows the structure of generators: 1 to 4. The test data generator ( 5) is implemented independently because it has no relation to the other generators. The generators 1 to 4 have the same input speci cations (GUI layout speci cations), so their generation process (i.e., subgenerators) can be shared. This process sharing reduces the re-engineering cost mentioned in Section 1. Figure 7 (b) shows the new generator structure after subgenerator sharing. Intermediate signatures called milestones connect subgenerators with each other. Speci cation checker 1 is divided into two subgenerators, 1 and 2. The milestone 1 (GUI object list) connects subgenerators 1 and SG
Call-back function list up
Event dispatcher Call-back function program
(2) Designing generator structure
G
(MS1)
Number of
MS
subgenerators
SG
5
2
2
4
3
Table 2: Generated software size and estimated cost with conventional software process.
2. GUI program generator 2 is also divided into two subgenerators, 1 and 3 and milestone 1 connects subgenerators, 1 and 3. Thus the subgenerator 1 is shared by the generators, 1 and 2. As can be seen in Table 1, this subgenerator sharing has reduced the number of necessary subgenerators from 11 to 7.
SG
G
SG
SG ;
SG
MS
SG
SG
G
G
Gene-
Lan-
Generated
rators
guage
software size
G2 G3
C COBOL C Document COBOL
G4
(3) Designing rewrite rules
Ratio
(K lines)
Man-months
(1 man-month
76.0 122.5 84.6 26.2
18.7% 30.2% 20.9% 6.5%
96.0 405.3
23.7% 100%
= 2.2 K lines)
34.5 55.7 38.5 11.9
The last substep of the forward engineering step is to design rewrite rules for each subgenerator that connect milestones. For example, the rule \the group of two
G5
rewrite rule R1:
of software generated by speci cation checker 1 is omitted in Table 2 because 1 does not generate any target software. Costs are expressed in units of manmonths, which re ects the cost of one person's work for one month. The conversion of Kilo-lines to manmonths is based on 1 man-month = 2.2 K lines, which is the standard of our group's productivity. The conventional software process development cost thus becomes 184.2 man-months + other cost , which includes the cost of requirement acquisition, call-back function design, testing, and debugging. Cost is estimated to be 140 man-months, but does not have to be analyzed in detail because it is constant before and after the re-engineering. Thus, cost = 184 2 man-months +
Total
black rectangles drawn as a Tgif gure is regarded as an input eld object" can be expressed in the following
G
G
vardef Coord1, Coord2, Fill1, Fill2, Pen1, Pen2; relation R1 eql ( group ( box('black', Coord1, Fill1, Pen1), box('black', Coord2, Fill2, Pen2) ), Field(max coord(Coord1, Coord2)) )
A
Variables, Coord1, ..., Pen2, are de ned by vardef. The left-hand side of rule R1 is the term group(...), and the right-hand side is the term Field(...). The subterm max coord ( Coord1, Coord2 ) in the right-hand side term means to select the larger rectangle of the two coordinates, Coord1 and Coord2. The total number of the rewrite rules for the chain store management system is 2500. 4 4.1
43.6 184.2
D
D
A
Evaluation
Because only one application system (the chain store management system) is developed with the new process, the in equation (1) is 1. Thus, the equation (1) becomes ( 0 0 ) 0 that needs to be satis ed for overall cost reduction. : development cost with the conventional software process The chain store management system has not actually been developed with the conventional software process described in Section 2, so the conventional development cost must be estimated from the size of programs developed with new software process and the average unit cost of programs developed with conventional software process. It is assumed here that the sizes of programs developed with conventional software process would be the same as those of programs developed with the new software process. This assumption is reasonable because the target software model and its coding style in this paper is the same before and after the re-engineering even though the software development process is reorganized. The sizes and costs of the software generated with the new software process is listed in Table 2. The size
Application function
GUI layout design
N
B
C
>
D:
Table 3: Application sizes and costs with the new software process.
Overall Cost Reduction
A
:
;
Application
Application
size
costs
189 4.1 windows man-months 200 1.0 data formats man-months
Test data design
A
: development cost with the new software process
B
Table 3 lists the sizes and costs for the chain store management system software developed with the new software process described in Section 3. GUI layout speci cations for 189 windows were developed in 4.1 man-months. The cooperative parallel development described in Section 3 helped reduce this application cost. Test data speci cations for 200 data formats were developed in 1.0 man-month. Thus, development cost with the new software process is given by cost = 5 1 man-months + : re-engineering cost Table 4 lists the development costs for the generators B
B
C
6
:
D:
all. The document generation by 4 takes only 6.5%, however, it helped the cooperation between the GUI layout designers and the call-back function designers. This is one of the key points for attaining the substantial cost reduction. Speci cation checker 1 helped the GUI layout designers for prototyping in the new software process and helped decrease the application cost.
Table 4: Generator development costs. Generators
Generator size
Lan-
(rules) 580 (8.8K lines) 53 (0.4K lines) 399 (3.5K lines) 472 (5.1K lines) 99 (0.9K lines) 754 (9.9K lines) 532 lines 33 (0.4K lines) 3055 lines 2500 (29.0K lines) 3587 lines
guage
SG1 SG2 SG3 SG4 SG5 SG6 SG7 G5
rule rule rule rule rule rule C rule C rule C
Total
G
Develop. cost (man-months)
5.5 0.5 3.0 1.5 0.3 2.0 0.2 1.5
G
Using software synthesis shell SOFTEX/S
Another primary factor of the cost reduction is the use of the software synthesis shell. It becomes a necessary condition for domain-speci cation that the reengineering cost is small, because the number of systems developed with the new software process is essentially small. The DSPR approach reduces the reengineering cost by providing methods for generating generators and for sharing subgenerators. SOFTEX/S supported the forward engineering step by generator generation, which was described in Section 3.6. Moreover, the subgenerator sharing also described in Section 3.6 has contributed to the reduction of the generator development cost. If the ve generators, 1 to 5, were developed independently without subgenerator sharing, the generator development would have required 31.0 man-months instead of 14.5 man-months (Tables 1 and 4). Through these discussions, it is clear that the software synthesis shell SOFTEX/S has played an important role in reducing re-engineering cost.
14.5
1 to 5 As described in Section 3.6, these generators share subgenerators with each other, and it has reduced the generator development cost signi cantly. The costs listed in Table 4 include almost all costs of re-engineering because the cost of the forward engineering step has been much greater than the costs of the reverse engineering step and the reorganization step. There was no need to redesign the target software model because it was invariable. (Generally speaking, the cost of designing the target software model is quite high if it has to be re-designed for the new process.) This paper considers the forward engineering cost as the re-engineering cost, so cost = 14 5 man-months.
G
G :
C
G
G
Overall cost reduction
The overall cost reduction resulting from reengineering the development process of the chain store management system becomes as follows: (overall cost reduction) = 0 0 = (184 2 + ) 0 (5 1 + ) 0 14 5 = 164.6 man-months. The DSPR approach has reduced the software development cost for 164.6 man-months (13.7 man-years) for the target chain store management system. The entire cost of developing the chain store management system with the conventional software process is estimated to be 324 man-months, so DSPR has reduced the total development cost by half. A
4.2
B
C
:
D
:
D
:
Flexibility of the Developed System
4.4
Reusability
Reusability of the re-engineering method
In domain-speci c software process re-engineering, software synthesis systems are not reusable in other domains. The domain-oriented software development process re-engineering methods themselves, however, are general-purpose methods and are reusable for other domains.
Primary Factors of the Overall Cost Reduction
Overall process re-engineering
One of the primary factors of the overall cost reduction, 164.6 man-months, is re-engineering of not only programming phase but also overall process including the speci cation checking, the document generation and test data generation. According to Table 2, software generated by call-back function document generator 4 and test data generator 5 takes 30% of G
4.3
The developed chain store management system is easily modi ed for speci cation update because only the GUI layout speci cations have to be modi ed. Three types of software { the GUI program, the event dispatcher, and the call-back function speci cation document { are generated from the speci cations automatically, so consistency among them is maintained automatically. The quality of the developed chain store management system has been so satisfactory that it has been in daily operation at more than ve thousand branch stores.
:
Reusability of the generators
Domain-speci c generators and their subgenerators are not readily reused in other domains, however, subgenerators are easily reused in other generators in the same domain. In the chain store management system domain, the subgenerator 1 was used in generators SG
G
7
Table 5: A comparison between DODE and DSPR.
DODE direction emphasis
user group
DSPR
design environment
development methods for design and implementation environment (re-engineering) overall process
upstream human-centered cooperative problem solving domain-orientation domain-speci c generators general-purpose re-engineering methods all stakeholders designers for DODEs and KBSAs (designers for target systems)
1 2 3 and 4 and the subgenerator 4 was used in 3 and 4. For example, 1, which analyzes the Tgif speci cations, was necessary in all the generators because they share the same speci cations as their input.
method has reduced the re-engineering cost by using the software synthesis shell for generator generation and subgenerator sharing. This approach can improve overall productivity even for a domain so small that only a single system is developed.
5
Acknowledgements
G ; G ; G ; G
G ;
G
SG
SG
Related Work
We thank Toshihiko Takahashi, Takashi Ohno, Junichi Tanaka, Shiro Muraoka, and Masahiro Yamamoto for their support during this research.
This section compares our approach with Fischer's domain-oriented design environment (DODE) approach [2]. The DSPR approach can be regarded as a method for developing DODEs and knowledge-based software assistants (KBSAs). That is, DSPR is a kind of meta-approach for DODE. DODE and DSPR are compared in Table 5. The DSPR approach emphasizes overall process re-engineering and overall cost reduction by reengineering. DSPR approaches not only the upstream
ow of the software process but also the downstream
ow { that is overall process { whereas DODE focuses on the upstream part of the software process. DSPR emphasizes a general-purpose re-engineering method which is reusable for other domains. Because of DSPR's meta-characteristics, a DSPR user group di ers from the DODE user group. 6
References
[1] Barstow, D.: Domain-Speci c Automatic Programming, IEEE Trans. Software Engineering, Vol. SE-11, No. 11, 1985.11. [2] Fischer, G.: Domain-Oriented Design Environments, Automated Software Engineering, Vol. 1, pp. 177-203, 1994. [3] Keller, R., and Rimon, M.: A Knowledgebased Software Development Environment for Scienti c Model-building, The Seventh KnowledgeBased Software Engineering Conference, pp. 192201,1992. [4] Klop, J. W.: Term Rewriting Systems: A Tutorial, Bulletin of the European Association for Theoretical Computer Science, No. 32, 1987. [5] Lowry, M., Philpot, A., Pressburger, T., and Underwood, I.: A Formal Approach to DomainOriented Software Design Environments, The Ninth Knowledge-Based Software Engineering Conference, pp. 48-57, 1994. [6] Smith, T., and Setli , D.: Towards Supporting Design Phase Synthesis, The Eighth KBSE Conference, pp. 20-27, 1993. [7] Yamanouchi, T., Sato, A., Tomobe, M., Takeuchi, H., Takamura, J., and Watanabe, M. : Software Synthesis Shell SOFTEX/S, The Seventh Knowledge-Based Software Engineering Conference, pp. 28-37, 1992. [8] Yamanouchi, T., Sato, A., Watanabe, H., Yamanaka, H. and Watanabe, M. : Software Synthesis Shell SOFTEX/S and Its Application to Switching Software, ATR International Workshop on Communication Software Engineering, 1994.
Conclusion
This paper has proposed a domain-oriented software development process re-engineering method DSPR using the software synthesis shell SOFTEX/S and has described its application to the development of a large scale chain store management system. In this application, the total development cost for the chain store management system has been reduced by half, from 324 man-months to 160 man-months. The developed chain store management system has been in daily operation at more than ve thousand stores. One of the key factors for attaining such substantial cost reduction, is that the overall development process has been reorganized, rather than programming phase alone being automated. Software synthesis shell SOFTEX/S has helped reduce the reengineering cost by supporting generator generation and subgenerator sharing. Through these discussions, it has shown that the domain-oriented software process re-engineering method DSPR can substantially improve overall software productivity even for a small domain. The DSPR 8
Domain-Oriented Software Process Re-engineering with Software Synthesis Shell SOFTEX/S
Akiyoshi Sato,y Minoru Tomobe,y Toru Yamanouchi,y Masanobu Watanabe,y and Masashi Hijikataz y C&C Research Laboratories zDistribution and Service Industries Systems Development Division NEC Corporation 4-1-1 Miyazaki, Miyamae-ku, Kawasaki, 216 JAPAN [email protected]
2.
process reorganization to assign the unit work to persons and generators and to design the software process ow, and 3. forward engineering to design and implement the generators. In domain-speci c re-engineering, the re-engineering methods themselves are reusable for other domains even though the software synthesis systems are not reusable. From the view point of overall productivity, the total cost reduction due to re-engineering is given by the following equation: (overall cost reduction) = ( 0 ) 2 0 (1) where
Abstract
This paper proposes a domain-oriented software process re-engineering method that allows for ecient software process modeling and cuts overall software development cost. This is achieved by use of a software synthesis shell that supports the development of program generators from input speci cation syntax and rewrite rules. Application of the proposed method to the development of a large scale \chain store management system" resulted in the development of a speci cation checker, two program generators, a speci cation document generator, and a test data generator. The overall development cost, including re-engineering cost, for this store management system has been reduced by 164 man-months. 1
A
Introduction
Many software synthesis systems have been proposed in order to improve the productivity of software development, and some have succeeded in automating the programming phase [1] [8] as well as the design phase [3] [5] [6] by limiting the application domains. Although software synthesis can be regarded as a process reorganization { so-called re-engineering { for software development, these domain-speci c software synthesis systems focus on automating a speci c phase in the software life-cycle rather than on the overall process for software development. This neglect of the overall process re-engineering view point is one of the main reasons that software synthesis systems that are ecient in some domains are not easily used in other domains. This paper proposes a domain-oriented software development process re-engineering (DSPR) method using the software synthesis shell SOFTEX/S [7] and describes its application to the development of a large scale \chain store management system." The DSPR method consists of the following steps: 1. reverse engineering to analyze the domain and abstract unit work,
B
N
C;
A is the development cost with the conventional software process, B is the development cost with the new software process, N is the number of application systems developed with the new software process, C is the re-engineering cost.
In the development of general-purpose software processes, is large and ( 0 ) 2 , thus the re-engineering cost may be ignored. For domainspeci c processes, in contrast, the number is small and the re-engineering cost is an important factor determining the overall cost reduction. If the reengineering cost is high, re-engineering is not ef cient for a domain with a small The DSPR method proposed in this paper therefore reduces the re-engineering cost by using a software synthesis shell to support the forward engineering process generating generators. This approach improves overall productivity even for a small domain where only a single system is developed. N
A
B
N
C
C
N
N:
2
Target
Domain
Software Process
1
and
Conventional
GUI layout design
GUI layout check
Call-back function design
Test data design
Design and Implementation
Program test
GUI layout correction
Test
Call-back function correction
Debug
Figure 2: Conventional process for developing the software for the chain store management system. company are usually developed by using generalpurpose GUI tools with the Motif widget library and the C language, and these GUI systems are running with a full keyboard and a mouse. The characteristics of the store management system are di erent from those assumed by general purpose GUI tools. Therefore, there was great need for domain-oriented
Head office (computer center) Chain store
(a) Interactive
subsystem
Store computer
Order data input, Working hours management, etc.
(b) Batch
software process re-engineering.
subsystem
Sum up the sales, Exchange master data with a host computer, etc.
2.3
As shown in Figure 2, one cycle of the software development process before re-engineering consists of (1) GUI layout design, (2) GUI layout check, (3) call-back function design, (4) test data design, (5) program test, (6) GUI layout correction, and (7) call-back function correction. This process has the following two problems: each phase is totally manual { there are no e ective (general-purpose) GUI tools that can be used because of its hardware and software specialties, and the process is fully sequential { parallel development by many people is dicult. These problems increase the cost and lengthen the development term. With the conventional software process, the whole cost of developing the chain store management system is estimated to be more than 300 man-months. Despite these problems in the development process, there are no problems in the target software model (architecture) itself. Thus the target software model in this paper will be the same before and after re-engineering.
Figure 1: Target domain: chain store management system. 2.1
Chain Store Management System
2.2
Domain straints
The target software domain here is a chain store management system running on store computers. This system (Figure 1), is used daily by storekeepers and clerks to place an order, check the stock, manage working hours and do everything else related to store management. Each computer in a store is connected with a head-oce host computer through a wide-area network. The functions of the chain store management system can be classi ed into two parts: an interactive subsystem (e.g., to input ordering data or con rm the working hours of clerks) and a batch subsystem (e.g., to sum up the sales and to exchange master data with the host computer). This paper targets the development of an interactive subsystem that users operate through a graphical user interface (GUI). Thus, the main part of this software development is the development of GUI and call-back functions. This subsystem has about 200 GUI windows. Characteristics
and
The Conventional Software Process
3
Con-
Domain-oriented
Software
Process
Re-engineering
The characteristics of the target system are shown as follows: (1) with UNIX operating system and X Window system, (2) with a touch-panel and a small special-purpose keyboard rather than with a mouse or a full keyboard, (3) with a special-purpose compact widget library, and (4) to adopt COBOL as a development language. These characteristics were determined after careful consideration of cost and performance. Most X Window-based GUI systems in the authors'
3.1
Re-engineering Process
3.2
New Software engineering
The DSPR method (Figure 3) consists of the following three steps: (1) reverse engineering, (2) process reorganization, and (3) forward engineering, as described in Section 1. Process
after
Re-
The new software process for the target domain, after re-engineering by the DSPR method, is shown 2
Unit work for persons and generators 1. Reverse engineering Conventional software development process
GUI layout designer
Reorganized software development process flow
2. Process reorganization
(H1)
3. Forward engineering using the software synthesis shell SOFTEX/S
New software development process
Specification checker (G1)
Re-engineering
Check result
Figure 3: The method of the domain-oriented software development process re-engineering (DSPR). : using a generator
GUI layout (G1) check
Test data designer (H3)
( ( ( (
Debug
Design and Implementation
W W
GUI program
Event dispatcher Call-back function
Call-back function designer
link Store computer program
(H2)
Tester (H4)
W W
2) Event dispatcher design and programming, 3) Call-back function design and programming, 4) Test data design and implementation, and 5) Testing programs.
3.4
Process Reorganization Step
(1) Assigning the unit work
Figure 4: The re-engineered software development process for the chain store management system.
The rst substep in process reorganization is to assign the unit work to persons and generators, and to arrange them on a software design environment. Persons will be in charge of creative work and generators will be in charge of monotonous work. The reorganized and generator-based process structure shown in Figure 5 has three types of human designers and one types of human testers: ( 1) GUI layout designers who design, from requirements, GUI layout speci cations with arrangements of GUI objects and de nitions of their attributes. These designers take charge of the design part of ( 1), and they check the GUI layout speci cations in prototyping by using a speci cation checker. To reduce the editor development cost, general-purpose drawing tool \Tgif" has been used as the GUI speci cation editor. ( 2) Call-back function designers who design callback functions by referring to call-back function speci cation documents and event dispatcher structured program diagrams (SPD). They take charge of part of ( 3). These two documents are generated from GUI layout speci cations with generators to support cooperating design with GUI layout designers. ( 3) Test data designers who design test data by re-
in Figure 4. It is totally automated with ve generators and enables fully parallel development, so that the problems mentioned in Section 2.3 are solved. 3.3
(G2)
Event dispatcher generator (G3)
Call-back function specification document generator (G4) Call-back function specification document
Figure 5: Structure of the new software process after the process reorganization step.
Program test
Test
GUI program generator
Test data generator (G5) Test data
Call-back function correction
(G5)
GUI layout specifications
Test data specifications
GUI layout correction (G2)
(G4) Call-back function design Test data design
Test data structure specifications
(G1): Specification checker (G2): GUI program generator (G3): Event dispatcher generator (G4): Call-back function specification document generator (G5): Test data generator
GUI layout (G2) GUI layout (G2) outline design (G3)detail design
Human work Generator work
Reverse Engineering Step
The reverse engineering step analyzes the domain and abstracts the unit work for a software process. This step uses domain-speci c business knowledge related to the target domain. First, the interactive subsystem for the chain store management system is based on a graphical user interface (GUI), as described in Section 2. Thus, there is the unit work for the GUI layout design and programming, which is based on the X Window system. Secondly, many GUI events occur with GUI operations, and all the call-back functions are invoked by the GUI events (e.g., pushing buttons and entering data). Thus, there is the unit work for design and programming for event dispatchers and call-back functions. Thirdly, there is the unit work for testing the above-mentioned programs. The unit work for the target domain is therefore the following: ( 1) GUI layout design and programming,
H
W
H
W
H
W
3
GUI layout outline designers and the call-back function designers. Test data can also be designed in parallel with the GUI layout detail design and the call-back function design, because the test data speci cations depend only on the GUI layout outline designs. In the debugging phase of the process, the GUI layout correction and call-back function correction are also done in parallel.
ferring test data structure speci cations. They take charge of the design part of ( 4). ( 4) Testers who use test data to test GUI programs and store computer programs, and who report the test results to the designers. They take charge of ( 5). Figure 5 shows the generator structure after the process reorganization. There are the following ve generators: ( 1) A speci cation checker that detects errors in GUI layout speci cations. It takes charge of part of ( 1). Because a speci cation checker has been regarded as a speci cations checking result generator, a checker has been developed as a generator. ( 2) A GUI program generator that generates GUI programs from GUI layout speci cations. It takes charge of the programming part of ( 1). ( 3) A event dispatcher generator that generates event dispatch programs from GUI layout speci cations. It takes charge of the programming part of ( 2). ( 4) A call-back function speci cation document generator that generates two types of call-back function speci cation documents from GUI layout speci cations. It takes charge of part of ( 3). ( 5) A test data generator that generates test data from test data speci cations. It takes charge of the implementation part of ( 4). W
H
W
3.5
G
Software Synthesis Shell SOFTEX/S
The system concept for SOFTEX/S [7] which is used in forward engineering step described in the next subsection, is illustrated in Figure 6. This software synthesis shell supports the construction of software synthesis systems (generators) for each software model. Software model here means the combination of a speci cation model and an implementation structure. This shell has a language DSL to de ne a speci cation language for each speci cation model as well as rewrite rules, and a term rewriting rule compiler [4]. A software synthesis system for a speci c software model can therefore be constructed from the de nition of the speci cation language syntax and rewrite rules.
W
G
W
G
W G
Input specification language syntax
W
Rewrite rules
G
Software synthesis shell
W
SOFTEX/S
(2) Designing the software process ow
The second substep of the process reorganization in reengineering allocates the unit work into a ow chart. That is, it designs the software development process
ow. This substep uses knowledge of dependency between the work of people and the work of generators. The independent work will be in parallel as much as possible. Figure 4 shows the new process ow reorganized from the conventional process shown in Figure 2. There are ve generators to automate the software process. The GUI speci cation checker ( 1) automates speci cation checking. To develop the GUI layout design and the call-back function design in parallel, GUI layout design was divided into two parts: outline design and detail design. The GUI layout outline design selects GUI objects that are necessary for interactive subsystems of the store management. The detail design determines the attributes for the GUI objects (e.g., color and line-width). Once a list of GUI objects is selected by GUI layout outline design, GUI object attributes and call-back functions can be designed independently, and thus in parallel. The callback function speci cation document generator ( 4) supports this parallel designing by visualizing the list of GUI objects. 4 acts as an interface between the
Input specifications
Domain-specific software synthesis system (generator)
Output program
Figure 6: The concept of SOFTEX/S. Speci cation language syntax is de ned as a manysorted signature which consists of sort symbols and function symbols. Termdef and sortdef primitives of DSL enable the syntax of a speci cation language to be de ned by adding new function symbols and sort symbols on a signature. Each rewrite rule, which is speci ed with a relation primitive, consists of two terms: a lhs-term and a rhs-term. If there is a term in speci cations uni able with the left hand side of a rule, then the term is rewritten with the right hand side of the rule. The variables used in rules are de ned with a vardef primitive. The term rewriting rule compiler compiles rewrite rules into executable generators. DSL's syntax is as follows:
G
, , ... ; ( param1-sort, param2-sort,...) term-name1, term-name2, ... ; vardef var-sort var-name1, var-name2, ... ; relation rule-name eql ( lhs-term, rhs-term )
sortdef sort-name1 sort-name2 termdef sort-name
G
G
4
3.6
GUI layout specifications
Forward Engineering Step
This step uses the software synthesis shell SOFTEX/S. (1) Designing generator input/output syntax
SpecifiGUI cation program checker generator (G1) (G2)
This substep uses the knowledge of a formal language. Each generator is developed as a many-sorted term rewriting system, so their input and output syntax are de ned as a many-sorted signature. The following signature 61 determines the subset of the input speci cation language syntax of the speci cation checker ( 1), the GUI program generator ( 2), the event dispatcher generator ( 3), and the call-back function speci cation document generator ( 4):
Check result
Call-back function specification document generator
Event dispatcher generator (G3) Event dispatcher Call-back function program
GUI program
G
G
(a) The structure of generators: G1 to G4.
(G4) Call-back function specification document
G
f
61
G
GUI layout specifications
= sortdef FigureObj, ColorAttr, CoordAttr, FillAttr, PenAttr; termdef FigureObj(ColorAttr, CoordAttr, FillAttr, PenAttr) box; ...
GUI object selection (SG1)
g
GUI object list
The sort symbol FigureObj means GUI objects (e.g., boxes and strings of characters). Sort symbols ColorAttr, CoordAttr, FillAttr, and PenAttr mean attributes of GUI objects. The function symbol box constructs a box as a GUI object, which has a sort of FigureObj, with the arguments of ColorAttr, CoordAttr, FillAttr, and PenAttr. This signature 61 for example, constructs the following input speci cation : T = f box('black', coord(236,314,364,362),0,1),
SpecifiGUI cation checker program subsubgenerator generator (SG3) (SG2) Check result
;
GUI program
T
...
g
Because the general-purpose drawing tool Tgif is used as the GUI speci cation editor, GUI objects are de ned as combinations of Tgif gures such as boxes, lines and strings. The above-mentioned black-colored single box means a GUI label object. In similar ways, other input and output speci cations can be de ned as many-sorted signatures.
Call-back function program
Call-back funciton list (MS2) Call-back Event dispatcher function subgenerator specification (SG6) document subgenerator Event dispatcher (SG5) (MS3) Call-back function Call-back function specification document program merge (SG7)
Figure 7: Generator structure for the chain store management system.
G
Table 1: The subgenerator composition of each generator G1 G2 G3 G4 SG1
SG2
SG3
SG4
SG5
SG6
SG7
G
G
G
C
G
SG
(SG4)
(b) The new generator structure after subgenerator sharing.
The second forward engineering substeps is to design generator structure, and the key point of this substep is subgenerator sharing. Figure 7 (a) shows the structure of generators: 1 to 4. The test data generator ( 5) is implemented independently because it has no relation to the other generators. The generators 1 to 4 have the same input speci cations (GUI layout speci cations), so their generation process (i.e., subgenerators) can be shared. This process sharing reduces the re-engineering cost mentioned in Section 1. Figure 7 (b) shows the new generator structure after subgenerator sharing. Intermediate signatures called milestones connect subgenerators with each other. Speci cation checker 1 is divided into two subgenerators, 1 and 2. The milestone 1 (GUI object list) connects subgenerators 1 and SG
Call-back function list up
Event dispatcher Call-back function program
(2) Designing generator structure
G
(MS1)
Number of
MS
subgenerators
SG
5
2
2
4
3
Table 2: Generated software size and estimated cost with conventional software process.
2. GUI program generator 2 is also divided into two subgenerators, 1 and 3 and milestone 1 connects subgenerators, 1 and 3. Thus the subgenerator 1 is shared by the generators, 1 and 2. As can be seen in Table 1, this subgenerator sharing has reduced the number of necessary subgenerators from 11 to 7.
SG
G
SG
SG ;
SG
MS
SG
SG
G
G
Gene-
Lan-
Generated
rators
guage
software size
G2 G3
C COBOL C Document COBOL
G4
(3) Designing rewrite rules
Ratio
(K lines)
Man-months
(1 man-month
76.0 122.5 84.6 26.2
18.7% 30.2% 20.9% 6.5%
96.0 405.3
23.7% 100%
= 2.2 K lines)
34.5 55.7 38.5 11.9
The last substep of the forward engineering step is to design rewrite rules for each subgenerator that connect milestones. For example, the rule \the group of two
G5
rewrite rule R1:
of software generated by speci cation checker 1 is omitted in Table 2 because 1 does not generate any target software. Costs are expressed in units of manmonths, which re ects the cost of one person's work for one month. The conversion of Kilo-lines to manmonths is based on 1 man-month = 2.2 K lines, which is the standard of our group's productivity. The conventional software process development cost thus becomes 184.2 man-months + other cost , which includes the cost of requirement acquisition, call-back function design, testing, and debugging. Cost is estimated to be 140 man-months, but does not have to be analyzed in detail because it is constant before and after the re-engineering. Thus, cost = 184 2 man-months +
Total
black rectangles drawn as a Tgif gure is regarded as an input eld object" can be expressed in the following
G
G
vardef Coord1, Coord2, Fill1, Fill2, Pen1, Pen2; relation R1 eql ( group ( box('black', Coord1, Fill1, Pen1), box('black', Coord2, Fill2, Pen2) ), Field(max coord(Coord1, Coord2)) )
A
Variables, Coord1, ..., Pen2, are de ned by vardef. The left-hand side of rule R1 is the term group(...), and the right-hand side is the term Field(...). The subterm max coord ( Coord1, Coord2 ) in the right-hand side term means to select the larger rectangle of the two coordinates, Coord1 and Coord2. The total number of the rewrite rules for the chain store management system is 2500. 4 4.1
43.6 184.2
D
D
A
Evaluation
Because only one application system (the chain store management system) is developed with the new process, the in equation (1) is 1. Thus, the equation (1) becomes ( 0 0 ) 0 that needs to be satis ed for overall cost reduction. : development cost with the conventional software process The chain store management system has not actually been developed with the conventional software process described in Section 2, so the conventional development cost must be estimated from the size of programs developed with new software process and the average unit cost of programs developed with conventional software process. It is assumed here that the sizes of programs developed with conventional software process would be the same as those of programs developed with the new software process. This assumption is reasonable because the target software model and its coding style in this paper is the same before and after the re-engineering even though the software development process is reorganized. The sizes and costs of the software generated with the new software process is listed in Table 2. The size
Application function
GUI layout design
N
B
C
>
D:
Table 3: Application sizes and costs with the new software process.
Overall Cost Reduction
A
:
;
Application
Application
size
costs
189 4.1 windows man-months 200 1.0 data formats man-months
Test data design
A
: development cost with the new software process
B
Table 3 lists the sizes and costs for the chain store management system software developed with the new software process described in Section 3. GUI layout speci cations for 189 windows were developed in 4.1 man-months. The cooperative parallel development described in Section 3 helped reduce this application cost. Test data speci cations for 200 data formats were developed in 1.0 man-month. Thus, development cost with the new software process is given by cost = 5 1 man-months + : re-engineering cost Table 4 lists the development costs for the generators B
B
C
6
:
D:
all. The document generation by 4 takes only 6.5%, however, it helped the cooperation between the GUI layout designers and the call-back function designers. This is one of the key points for attaining the substantial cost reduction. Speci cation checker 1 helped the GUI layout designers for prototyping in the new software process and helped decrease the application cost.
Table 4: Generator development costs. Generators
Generator size
Lan-
(rules) 580 (8.8K lines) 53 (0.4K lines) 399 (3.5K lines) 472 (5.1K lines) 99 (0.9K lines) 754 (9.9K lines) 532 lines 33 (0.4K lines) 3055 lines 2500 (29.0K lines) 3587 lines
guage
SG1 SG2 SG3 SG4 SG5 SG6 SG7 G5
rule rule rule rule rule rule C rule C rule C
Total
G
Develop. cost (man-months)
5.5 0.5 3.0 1.5 0.3 2.0 0.2 1.5
G
Using software synthesis shell SOFTEX/S
Another primary factor of the cost reduction is the use of the software synthesis shell. It becomes a necessary condition for domain-speci cation that the reengineering cost is small, because the number of systems developed with the new software process is essentially small. The DSPR approach reduces the reengineering cost by providing methods for generating generators and for sharing subgenerators. SOFTEX/S supported the forward engineering step by generator generation, which was described in Section 3.6. Moreover, the subgenerator sharing also described in Section 3.6 has contributed to the reduction of the generator development cost. If the ve generators, 1 to 5, were developed independently without subgenerator sharing, the generator development would have required 31.0 man-months instead of 14.5 man-months (Tables 1 and 4). Through these discussions, it is clear that the software synthesis shell SOFTEX/S has played an important role in reducing re-engineering cost.
14.5
1 to 5 As described in Section 3.6, these generators share subgenerators with each other, and it has reduced the generator development cost signi cantly. The costs listed in Table 4 include almost all costs of re-engineering because the cost of the forward engineering step has been much greater than the costs of the reverse engineering step and the reorganization step. There was no need to redesign the target software model because it was invariable. (Generally speaking, the cost of designing the target software model is quite high if it has to be re-designed for the new process.) This paper considers the forward engineering cost as the re-engineering cost, so cost = 14 5 man-months.
G
G :
C
G
G
Overall cost reduction
The overall cost reduction resulting from reengineering the development process of the chain store management system becomes as follows: (overall cost reduction) = 0 0 = (184 2 + ) 0 (5 1 + ) 0 14 5 = 164.6 man-months. The DSPR approach has reduced the software development cost for 164.6 man-months (13.7 man-years) for the target chain store management system. The entire cost of developing the chain store management system with the conventional software process is estimated to be 324 man-months, so DSPR has reduced the total development cost by half. A
4.2
B
C
:
D
:
D
:
Flexibility of the Developed System
4.4
Reusability
Reusability of the re-engineering method
In domain-speci c software process re-engineering, software synthesis systems are not reusable in other domains. The domain-oriented software development process re-engineering methods themselves, however, are general-purpose methods and are reusable for other domains.
Primary Factors of the Overall Cost Reduction
Overall process re-engineering
One of the primary factors of the overall cost reduction, 164.6 man-months, is re-engineering of not only programming phase but also overall process including the speci cation checking, the document generation and test data generation. According to Table 2, software generated by call-back function document generator 4 and test data generator 5 takes 30% of G
4.3
The developed chain store management system is easily modi ed for speci cation update because only the GUI layout speci cations have to be modi ed. Three types of software { the GUI program, the event dispatcher, and the call-back function speci cation document { are generated from the speci cations automatically, so consistency among them is maintained automatically. The quality of the developed chain store management system has been so satisfactory that it has been in daily operation at more than ve thousand branch stores.
:
Reusability of the generators
Domain-speci c generators and their subgenerators are not readily reused in other domains, however, subgenerators are easily reused in other generators in the same domain. In the chain store management system domain, the subgenerator 1 was used in generators SG
G
7
Table 5: A comparison between DODE and DSPR.
DODE direction emphasis
user group
DSPR
design environment
development methods for design and implementation environment (re-engineering) overall process
upstream human-centered cooperative problem solving domain-orientation domain-speci c generators general-purpose re-engineering methods all stakeholders designers for DODEs and KBSAs (designers for target systems)
1 2 3 and 4 and the subgenerator 4 was used in 3 and 4. For example, 1, which analyzes the Tgif speci cations, was necessary in all the generators because they share the same speci cations as their input.
method has reduced the re-engineering cost by using the software synthesis shell for generator generation and subgenerator sharing. This approach can improve overall productivity even for a domain so small that only a single system is developed.
5
Acknowledgements
G ; G ; G ; G
G ;
G
SG
SG
Related Work
We thank Toshihiko Takahashi, Takashi Ohno, Junichi Tanaka, Shiro Muraoka, and Masahiro Yamamoto for their support during this research.
This section compares our approach with Fischer's domain-oriented design environment (DODE) approach [2]. The DSPR approach can be regarded as a method for developing DODEs and knowledge-based software assistants (KBSAs). That is, DSPR is a kind of meta-approach for DODE. DODE and DSPR are compared in Table 5. The DSPR approach emphasizes overall process re-engineering and overall cost reduction by reengineering. DSPR approaches not only the upstream
ow of the software process but also the downstream
ow { that is overall process { whereas DODE focuses on the upstream part of the software process. DSPR emphasizes a general-purpose re-engineering method which is reusable for other domains. Because of DSPR's meta-characteristics, a DSPR user group di ers from the DODE user group. 6
References
[1] Barstow, D.: Domain-Speci c Automatic Programming, IEEE Trans. Software Engineering, Vol. SE-11, No. 11, 1985.11. [2] Fischer, G.: Domain-Oriented Design Environments, Automated Software Engineering, Vol. 1, pp. 177-203, 1994. [3] Keller, R., and Rimon, M.: A Knowledgebased Software Development Environment for Scienti c Model-building, The Seventh KnowledgeBased Software Engineering Conference, pp. 192201,1992. [4] Klop, J. W.: Term Rewriting Systems: A Tutorial, Bulletin of the European Association for Theoretical Computer Science, No. 32, 1987. [5] Lowry, M., Philpot, A., Pressburger, T., and Underwood, I.: A Formal Approach to DomainOriented Software Design Environments, The Ninth Knowledge-Based Software Engineering Conference, pp. 48-57, 1994. [6] Smith, T., and Setli , D.: Towards Supporting Design Phase Synthesis, The Eighth KBSE Conference, pp. 20-27, 1993. [7] Yamanouchi, T., Sato, A., Tomobe, M., Takeuchi, H., Takamura, J., and Watanabe, M. : Software Synthesis Shell SOFTEX/S, The Seventh Knowledge-Based Software Engineering Conference, pp. 28-37, 1992. [8] Yamanouchi, T., Sato, A., Watanabe, H., Yamanaka, H. and Watanabe, M. : Software Synthesis Shell SOFTEX/S and Its Application to Switching Software, ATR International Workshop on Communication Software Engineering, 1994.
Conclusion
This paper has proposed a domain-oriented software development process re-engineering method DSPR using the software synthesis shell SOFTEX/S and has described its application to the development of a large scale chain store management system. In this application, the total development cost for the chain store management system has been reduced by half, from 324 man-months to 160 man-months. The developed chain store management system has been in daily operation at more than ve thousand stores. One of the key factors for attaining such substantial cost reduction, is that the overall development process has been reorganized, rather than programming phase alone being automated. Software synthesis shell SOFTEX/S has helped reduce the reengineering cost by supporting generator generation and subgenerator sharing. Through these discussions, it has shown that the domain-oriented software process re-engineering method DSPR can substantially improve overall software productivity even for a small domain. The DSPR 8
