On object-oriented methods and software reuse relationships
Yin Zhixi
(This article is reproduced from Software Engineering Expert Network www.21cmm.com)
1. Features and status quo of software multiplexing
Software multiplexing is to use existing software components to construct new software systems. Software components that can be reused are generally referred to as a reused member, whether or proper use of the reuse member, it is still used, and it can be called multiplexed as long as it is used to construct new software. . Software multiplex is more than just a reuse of the program, but it also includes multiplexing of finished products produced by any activity in the software production, such as project plan, feasibility report, demand definition, analysis model, design model, detail Description, source program, test case, etc. If you use one of the same software components multiple times in a system, it is not called multiplexing, referred to as sharing; modifications to a software so that it is not called multiplexing in new hardware and software platforms, and Software transfer value. The current and recent future most likely to have significant benefits are multiplexed software products for some major development phases in the software lifecycle, which can be divided into the following multiplexed levels according to the degree of abstraction.
(1) Recourse
Includes the multiplexing of the target code and source code. The maximum reuse level of the target code is the longest, and the current operating support system of most programming languages provides functions such as linking, binding, and other functions to support this multiplex. The multiplex level of the source code is slightly higher than the target code, and the programmer copies some of the code segments you want to multiplex into their own program when programming, but this tends to generate errors that do not match the new and old code. Recognition of a large-scale implementation source program is only relying on a component library that contains a large number of reused components. For example, "Object Links and Embed" (OLE) technologies support both source-level definition components and to construct new systems, but also make these components at the level of the target code are still some independent reusable components, which can be running Flexible new combination is a variety of different applications.
(2) Recourse
The design results are higher than the abstract level of the source program, so its multiplexing is less impact, thereby enabling more opportunities for multiplexed components being reused, and less modifications need. This multiplex is three ways, the first way is to extract some of the reusable design components from the design results of the existing system, and apply these components to the design of the new system; the second way is to put an existing All design documents of the system are re-implemented on the new software and hardware platform, which is to use a design to use in multiple specific implementations; the third pathway is independent of any specific application, and has planned some accessible design. member.
(3) multiplexing analysis
This is a higher-level multiple-level multiplexing than the design results, which is a solution to certain things in the problem or some problems, which is small, and the design techniques and realization conditions are small. Available opportunities. There are three ways to multiplex, that is, extracting the analysis of the reused components from the analysis results of the existing system for new systems; use a complete analysis document to generate more different hardware platforms and other conditions. Item design; independently of specific applications, specializes in developing some of the accessible analysis components.
(4) Recurrence of test information
It mainly includes multiplexing of test cases and multiplexing of testing process information. The former is used in new software testing in new software testing, or in a new round of testing when making modifications. The latter is automatically recorded the process information of the test through the software tool during the test process, including everything of the tester, input parameters, test cases, and operating environments. This multiplexed level, inconvenience, and analysis, design, programming multiplex levels are accurate because of the different abstractions of the same thing, but another information, but from this information Generally, the level is equivalent to the program code.
Since the software production process is mainly forward process, most software production process is to evolve software products from higher morphology to abstract levels, so higher-level multiplexing is easy to drive lower levels Use, the higher the level, the higher the level, the larger the reward, so the analysis results and design results are currently valued. Users can purchase manufacturers' analyzers and designs, design or program, master the system's tailoring, expansion, maintenance, evolution, etc. 2. The fundamental of software reuse is difficult
The difficulties of software multiplexing, whether technical issues or non-technical issues affect the wide implementation of software reuse.
(1) Technical factors.
The difference between the components and the application system. Some developers have developed components to do just right when they are used by other people. They are justified from content to the external interface, or make few modifications, this is not a simple matter; components should To reach a certain amount, it can support effective multiplexing, while the need for a large number of components requires high input and long-term accumulation; discovering the difficulties of the combined components, when the component reaches a large number, the user wants to find one from it. The desired components, and conclude that it is really what you need, not a light and easy thing; multiplexing software development methods and software processes are a new research practice area, require some new theory, technology and support environment, The research results and practical experience in this area are not sufficient.
(2) The factors of people.
Software development is a creative job. People who have long been engaged in this industry have formed a professional habit: I like to create something that I don't like to use others, especially when I have to develop some people to make some modifications, they often Like yourself to write one.
(3) Management factors
In the management of software production, from the past, some institutions and policies that have been uncoordinated from the past, such as calculating the workload, play a lot of discounts, even if it is not a workload; It is not consciously efforts to reuse the components at the beginning of the project, but after it is completed, see if some can be found. These disadvantages hinder the improvement of the renewal level and the expansion of the multiplexing scale, and even contused to the enthusiasm of multiplexed people.
(4) Educational factors
In the education and training of software science and technology, there is a lack of content about software reuse, and there are very few special textbooks and courses in this regard, even in other textbooks and courses mentioned software reuse, the space and content is quite weak.
(5) Legal factors
There are still some problems in the legal, for example, a reusable component has an error in an application system, and the developer of the component is not a manufacturer, who should be liable? In addition, there are some unresolved issues in copyright, government policies. In addition, software products are a spiritual product, which is almost entirely the result of human brain thinking. Its value is almost completely in which the idea of condensation; its material carrier manufacturing process and value content are insignificant . The production of material products is limited by human manufacturing capabilities. The complexity of existing material products has not exceeded this limitation, but the software does not have this limit. As long as people's brain can think of problems, they may require software to solve The complexity of the problem that the human brain can think is far from the complexity of the material products that humans can manufacture, thus making the software more difficult.
3. OO method support for software multiplexing
Supporting software reuse is one of the main hopes that people are pinned to object methods, and this method is also one of the main reasons for extensive attention. The object-oriented method is particularly advantageous for software reuse because it is very consistent with the main concepts and principles and software reuse. Object-oriented methods develop from object-oriented programming to object-oriented analysis and design, so that this method supports software reuse can start a role from the previous stage of the software lifecycle, so that the OO method supports software multiplexing Reached a higher level. An important advantage of object-oriented methods is that it can achieve concepts, principles, terms, and expiration of the concept, principles, terms, and representations throughout the software life cycle. Such consistency makes each system ingredient although there are different forms in different development and evolutionary phases, there may be a good mapping throughout the software lifecycle. This advantage makes the OO method not only support software reuse at all levels, but also forms a unified, efficient support for each level of multiplexing, and achieves a good global effect. The necessary condition for this is that the pre-session-oriented preliminary stage - OOA will make a reuse of support software as a key issue. The object class defined by the OOA method has many features that are suitable as a reuse member, and the OOA result is a good mapping of the problem domain, making the developers of the same system easy to start from the problem, discovers different particle size in the existing OOA results. Reparable components.
(1) OOA model
The system model established by the OOA method is divided into basic model (class diagram) and supplementary model (topic map and interaction map), emphasizing only the most important system modeling information in the OOA basic model, and more detailed information is in detail Break out. This representation strategy enables the OOA basic model to reflect higher abstraction, making it easier to be a reusable system architecture. When this architecture is multiplexed in different application systems, in many cases, the system can be referred to in the system, and therefore, the system components are less modified.
(2) Division of OOA and OOD
OOA focuses on information related to problem domain and system responsibility, OOD considers factors related to implementation conditions. This division makes the OOA model independently of the specific implementation conditions, so that the analysis results can be multiplexed in multiple systems that have different conditions in terms of problem domain and system responsibilities, and analyzed from multiple systems from the same field. Field model creates favorable conditions.
(3) The representation of the object
All objects are used as an abstract description. Objects, including objects, behavior, and external relationships, etc. are all represented by object classes. As a reusable component, the system model does not cause the system model due to this type of object instance when applied to different systems.
(4) General - special structure
Introducing a representation of polymorphism in general-special structures, thereby enhancing the reusability of classes. By represented the polymorphism, a class can be multiplexed in a system similar to the same requirements.
(5) Overall - partial structure
Use some classes as the reused component throughout the class, the principle of this policy is consistent with the general class in a special class, but in some cases, the mapping of the problem domain is reused by inheritance More nature. It can also be defined as partial objects by separating a set of properties and services that can be reused from the domain range by overall-part structural support domain.
(6) instance connection
It is recommended to express a variety of complex relationships and multi-relationships with simple binary relationships. This strategy makes the basic components (object classes) of the system and the relationship between them in terms of formatting and implementation of this normative and consistent such normative and consistent for the organization, management and use of the reusable components. It is very helpful.
(7) Class Description Template
As an OOA detailed description template, the description of the relationship between the object is noted that the user is different from the user, and only the relationship between the user is given to the relationship between the user. This shows that the dependency between the reuse member is not equal. Thus, the relationship between the user of inheritance, polymerization, example connection, and message connection is described, which is conducive to these relationship information and simultaneous multiplexing of dependent components they indicated. The relationship is not described at one end of the consumer, avoiding the modifications caused by the different reuse occasions. (8) Using Case
Since using CASE is a standardized description of user needs, it has stronger reusability than ordinary demand documents. Each use of CASE is a description of an interactive activity when an active is using a function of the system, which has integrity and certain independence, so it is well suited as a reuse member.
4. Reuse technology support for OO methods
The relationship between object-oriented software development and software reuse is complementary. On the one hand, the basic concept of the OO method, principles and technologies provide advantageous conditions for implementing software reuse; on the other hand, software multiplexing technology also provides strong support for object-oriented software development.
(1) Class library
In object-oriented software development, class libraries are basic conditions for implementing object class multiplexing. It has been developed many of the various OOPL programming libraries, which strongly supports the software multiplexing of the source program level, but to implement software multiplexing on a higher level, only the programming class library is not enough. Realize the reuse of OOA results and OOD results, must have support for analyzing class libraries and design class libraries. In order to better support multiple levels of software multiplexes, each class can be established between the OOA class library, the OOD class library, and the OOP class library, and the corresponding and evolutionary relationships of various classes in different development phases can be established. That is, a clue is established, indicating which (or which) OOD classes correspond to each OOA class, and each OOD class corresponds to which OOP class in various OO programming language libraries.
(2) component library
Class libraries can be seen as a special reusable component library that provides a basic support for software reuse in object-oriented software development. However, the class library can only store and manage the reusable components of classes in units, and other forms of components cannot be saved; however it can more maintain the structure and connection relationship between the components. The reusable member in the component library can be either a class or other system unit; how to organize the same relationship with the object classes, it can be tested according to the general component description, classification and retrieval method. In the object-oriented software development, a reusable member than the object class is larger, such as a reusable component, such as a reusable component, can also refine other forms, such as use case or interaction. Fig. In these component libraries, the forms and contents of components are richer than class, which can be more supported for object-oriented software development.
(3) architecture library
If an OOA model of one or more systems has been established in an application field, each OOA model should be saved to provide a reference for the development of new systems in this area. When multiple OOA models have multiple OOA models in a field, a reusable software architecture can be produced by further abstraction. A more formal approach to forming this reusable software architecture is to conduct a domain analysis. Software architects obtained through regular domain analysis will more accurately reflect the commonality of each application system in a field, with stronger accessible value.
(4) Tool
Effective implementation of software reuse requires some support multiplexed software tools, including management, maintenance and browsing tools, components, and description tools, and component retrieval tools, and components. The OOA tools and OOD tools that support support for the background also have corresponding requirements, and the tools for the tool to the OOA / OOD process should include: from the class library or component / architecture to find a reusable component; Modify, and join the current system model; submit the newly defined classes (or other components) in the current system development to the class library (or component library). (5) OOA process
The OOA procedure supported by multiplexing technology can be organized according to two strategies. The first strategy is that the original OOA process proposed by this OOA method is basically maintained, and the support of the various activities introduced in this basis; another policy is to reorganize the OOA process.
The first strategy is to increase the support of the multiplexing technology on the original OOA process. It should be supplemented that the OOA process under multiplexing technology should add an activity that submits new components. That is, in the development of a specific application system, if some components that have a reuse of other systems are defined, it should be submitted to the reusable component library. The premise of the second strategy is that before the object-oriented method is used to target an object-oriented method, the domain-oriented method is used to obtain a domain architecture and a batch of domain-oriented methods. Class components and support for component / architectural libraries, class libraries, and corresponding tools. Under this condition, the relationship between the contents and activities of the various activities in the OOA process, and strive to produce an OOA model in an assembled manner, which will make the OOA process more reasonably and achieve higher development efficiency.
