JPH10105404A - Object directional software design pattern - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a software interface design pattern for constituting a sub-system being superior in a test property and a maintenance in object direction system development. SOLUTION: In an object directional system, the software interface design pattern is provided with at least a method for converting messages from client classes C1-C2 in order to perform access to the classes inside the sub-system in the object directional system so as to perform access to the classes B1-B5 inside the sub-system, the pointer of an instance to the classes B1-B5 in the sub-system and serve classes S1-S3 and the method for performing access to the server classes S1-S3.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software interface design pattern for the purpose of improving the reuse and quality of software of a subsystem in an object-oriented system, and further improving testability and maintainability. is there.

[0002]

2. Description of the Related Art Generally, in an object-oriented system, as shown in an example of an object relation diagram relating to a subsystem in FIG. 3, one and two client classes C (C1, C2) and four , 5, 6, 7
And eight classes B (B1, B2, B3, B4, B
In the case where there is a complicated dependency including the control procedure between the client class and the client class C5, the direct association between the client classes C1 and C2 and the class B in the subsystem as shown in FIG. This makes it difficult to reuse existing software and object models, makes it difficult to decipher software, and complicates software testing. For this reason, various software design patterns for object-oriented systems have been proposed.
In particular, there is a facade (FACADE) as one of the prior arts relating to interface design patterns.
The facade design pattern has a function of providing one unified interface to the client class C when the client class C accesses a plurality of classes B existing in the subsystem via the facade design pattern. I have.

For this reason, as shown in FIG. 2, when performing a basic operation from a client class C to a class B in a subsystem, a facade design pattern is introduced, and 19 facade classes having a simple interface function are provided. Has defined. A message is sent from the client classes C1 and C2 to the facade class, a request is received by a method in the facade class, and further converted from the facade class to an interface of an appropriate class B object, and the message is accessed by transferring the message. . As described above, by avoiding the client class C from directly accessing the class B (object) in the subclass, and by describing the control procedure of the client class C for the class B in the method in the facade class, the message from the client class C is obtained. The number can be reduced, and it is not necessary to know the detailed structure of the class B to access. Therefore, the independence and portability of the subsystem are improved.

The class B in the subsystem processes the work specified via the facade class in principle, but does not hold a reference (pointer) to the facade class as an attribute. Therefore, class B in the subsystem cannot send a message to the facade class, as shown in FIG. 2, from classes B2 to 9 server classes S1, 11 server classes S3, and class B3.
To server class S2 from 10 and further from class B5 to 1
A message is directly sent to each of the server classes S3.

Therefore, when the client class C is replaced with a test driver class and the server class S is replaced with a stub class, and a subsystem is tested, it is necessary to know a detailed structure such as a control procedure from the class B to the server class S. Yes, the interface is not uniform and cannot be easily tested.

Further, class B in the subsystem is not completely hidden via the facade class, and does not completely prohibit direct access from other low-level client classes without passing through the facade class. This configuration condition also complicates the testing of the subsystem.

As described above, when the interface between the subsystem and the client class C is performed using the conventional facade design pattern, the facade class provides the interface function having the above-described structure. There is no particular problem in sending a message from the to the class B in the subsystem via the facade class. However, when testing the subsystem, the client class C is replaced with a test driver class and the server class S is replaced with a stub class. When testing a subsystem, the connection configuration and control procedure with each server class S must be changed. After deciphering, it is necessary to prepare each interface individually, and there is a problem that a test is extremely troublesome and costs are increased.

Further, there are disadvantages such as difficulty in maintenance such as software quality and function expansion of subsystems. In addition, when a large number of messages that do not pass through the facade class are sent to the class B in the subsystem, it is difficult to test the subsystem independently, and the test becomes much more difficult. I have.

[0009]

SUMMARY OF THE INVENTION As described above,
When the conventional facade design pattern is used as an interface between the subsystem and the client class B, the connection between them becomes simple, but the interface is not sufficient when executing the test. When sending a message to the server class S, it is required to consider a test method in consideration of those interface conditions and control procedures for each class.
As described above, the facade design pattern is a software interface design pattern that does not ensure sufficient independence of subsystems, is not functionally sufficient as an interface considering testability, and has poor software quality and maintainability. However, it has the disadvantage of increasing the test period and cost.

An object of the present invention is to provide a software interface design pattern which solves the above problems, has an excellent interface function even in subsystem testing, and is excellent in software quality and reusability. It is in. Here, the design pattern of the present invention is hereinafter referred to as a connector design pattern.

[0011]

In an object-oriented system, in order to solve the above-mentioned problems, a message from a client class is converted and designated to access a class in a subsystem of the system. A method for accessing the class in the subsystem;
By using a software interface design pattern characterized by having at least a pointer to instances of the class and server classes in the subsystem and a method for accessing the server class, the above drawbacks are overcome. Resolve.

Further, the software interface
For the subsystem having a design pattern, a test driver class is defined instead of the client class, and a stub class is defined instead of the server class, and testing of the subsystem is performed through the software interface design pattern. The above-mentioned drawbacks are solved by using a test method characterized by performing the following.

As described above, the software of the present invention
Since an interface design pattern (connector design pattern) is provided, and the client class C and the server class S are connected to the class B in the subsystem via the connector class of the connector design pattern, the subsystem is connected to another class. It is completely independent of the client class and server class, and the extension or change of subsystem functions can be easily implemented without affecting other systems or classes. In addition, since it is easy to connect to the client class and server class and can provide a unified interface structure, the reusability of the subsystem is much higher than the conventional method, and the testability is also very good, and the maintainability is large. To be improved.

Therefore, by applying the software interface design pattern of the present invention to individual subsystems, development costs and maintenance costs can be greatly reduced, and the same subsystems as LSI chips or customized A wide variety of subsystems can be used.

[0015]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a software interface design pattern according to the present invention will be described below. One configuration example in which a connector design pattern as a software interface design pattern is applied to connect a client class C and a server class S to a subsystem class B via a connector class of the connector design pattern is shown in FIG. Shown in The client class and the server class are connected to the class B in the subsystem via the connector class. here,
In order to show the connection relation, input interface methods I1, I2, I3 and I4 in three connector classes are described in 12, 13, 14 and 15, respectively.
Also, 16, 17, and 18 are output interface methods O1, O2, and O3 in the connector class, respectively.
It is. Here, FIG. 4 shows an example of the definition of the connector class in the C ++ language. Unlike the facade class, server classes S (S1, S2, S3) are declared, respectively, and pointers of the respective instances are newly defined as attributes. Further, an output interface method O for accessing the message sent from the class B to the connector class and the server class S, respectively.
1, O2 and O3 are newly implemented.

Further, similarly to the case where the facade class is used, a method for accessing the class B in accordance with a message from the client class C is also defined. As described above, by defining the connector class in the connector design pattern as shown in FIG. 4, the input / output interface is prepared, and it is not necessary to know the detailed structure and control procedure of the class B. Very high connectivity and easy to test. In addition, as shown in an example of the definition of the class B in FIGS.
2, B3 and B5 are different from the case using the facade class, and are different from 5, 6 and 8 in the case of the facade due to the introduction of the connector class of the connector design pattern. Has been changed to Specifically, a connector class declaration, a method for accessing the connector class, and a pointer of an instance to a class accessed by the connector class are newly defined as attributes.

On the other hand, regarding the classes B1 and B4, the classes B1 (4) in FIG. 5 and the class B4 (7) in FIG.
For the client classes C1 and C2, the client class C1 (1) in FIG. 10 and the client class C2 (2) in FIG. 11, and for the server class S, the server class S1 (9) in FIG. The server class S2 (10) and the server class S3 (1
One example of the definition of 1) is listed, respectively, and these are the same as the case where the facade class of the facade design pattern is used.

For each of the above classes, a message is sent from the client class C to the connector class, transferred to the class B, and a message as a response from the class B is sent to the connector class according to the object relation diagram of FIG. A series of operations can be performed by receiving and transferring these to the server class S. Also,
When testing subsystems, client class C
Is replaced with a test driver class and the server class S is replaced with a stub class, so that the subsystem can be implemented without any change. Further, in this embodiment, the class B in the subsystem is supposed to be completely hidden via the connector class. However, if the class B does not significantly affect the test, the connector B cannot be used from other low-level client classes. You may allow direct access without going through the class.

[0019]

As described above, the connector design pattern is provided as the software interface design pattern of the present invention, and the client class and the server class are connected to the classes in the subsystem via the connector design pattern. It can provide a very stable interface function. Thus, the subsystem eliminates very complex direct dependencies between the client class C and server class S and the class B in the subsystem, and is completely independent of the client and server classes, Extensions and changes in subsystems can be implemented without affecting other systems or classes. In addition, the unified interface structure makes it easy to connect to the client and server classes, further improving the reusability of subsystems compared to the conventional method, and also greatly improving testability and greatly improving maintainability. Is done.

Therefore, by applying the software interface design pattern of the present invention to individual subsystems, it is possible to improve software quality, and significantly reduce development costs and maintenance costs.
As in the case of the LSI chip, a wide variety of subsystems made of the same software and customized subsystems can be used.

In the prior art, it has been difficult to consistently perform an input / output test between a class in a subsystem and a client class and between a server class in an object-oriented system. However, as described above, the connector design pattern of the present invention is not used. The application will significantly improve the testability and reusability of the subsystems, as well as their software quality, and will ultimately improve the software quality and maintainability of large object-oriented systems. It can achieve a very large economic effect.

[Brief description of the drawings]

FIG. 1 shows a configuration of a client class C and a server class S and a class B in a subsystem via a connector class in one embodiment using a connector design pattern as a software interface design pattern according to an embodiment of the present invention. It is an example of an object relation diagram.

FIG. 2 shows a client class C via a facade class when a conventional facade design pattern is used.
And an example of an object relation diagram between a server class S and a class B in a subsystem.

FIG. 3 is an example of an object relation diagram of a client class C and a server class S and a class B in a subsystem when a design pattern is not used.

FIG. 4 is an example of a definition of a connector class in the embodiment.

FIG. 5 is an example of a definition of a class B1 in the embodiment.

FIG. 6 is an example of a definition of a class B2 in the embodiment.

FIG. 7 is an example of a definition of a class B3 in the embodiment.

FIG. 8 is an example of a definition of a class B4 in the embodiment.

FIG. 9 is an example of a definition of a class B5 in the embodiment.

FIG. 10 is an example of a definition of a client class C1 in the embodiment.

FIG. 11 is an example of a definition of a client class C2 in the embodiment.

FIG. 12 illustrates a definition of a server class S1 according to the embodiment.
It is an example.

FIG. 13 shows a definition of a server class S2 in the embodiment.
It is an example.

FIG. 14 illustrates a definition of a server class S3 according to the embodiment.
It is an example.

[Description of Signs] 1 client class C1 2 client class C2 3 connector class 4 class B1 5 class B2 6 class B3 7 class B4 8 class B5 9 server class S1 10 server class S2 11 server class S3 12 method I1 13 for input interface Input Interface Method I2 14 Input Interface Method I3 15 Input Interface Method I4 16 Output Interface Method O1 17 Output Interface Method O2 18 Output Interface Method O3 19 Facade Class 20 Class B2 21 Class B3 22 Class B5

Claims (2)

[Claims] In an object-oriented system, in order to access a class in a subsystem of the system, a method for converting a message from a client class and accessing a specified class in the subsystem; A software interface design pattern characterized by holding at least pointers to instances of classes and server classes, and at least a method for accessing the server class. 2. The system according to claim 1, wherein, for the subsystem having the software interface design pattern, a test driver class is defined instead of the client class, and a stub class is defined instead of the server class. , The software interface
A test method for executing a test of the subsystem through a design pattern.