Application of object-oriented technology in software reuse and architecture
Author: Tian Jingcheng Published: 2001/01/08
Thesis:
Object-oriented technology provides a new cognition and representation of the world's thoughts and methods, which affect the computer industry far. Computer practitioners use it proposing object-oriented computer programming languages, object-oriented software design methods, object-oriented databases, and more. At the same time, object-oriented technology provides strong support for software industry, is the concept of object-oriented technology to create components, components, intermediate parts.
text:
Object-oriented technology provides new cognitive and representation of object-oriented technology in software reuse and architecture, which is far-reaching in the world's impact on computer industries. Computer practitioners use it proposing object-oriented computer programming languages, object-oriented software design methods, object-oriented databases, and more. At the same time, object-oriented technology provides strong support for software industry, is the concept of object-oriented technology to create components, components, intermediate parts. 1 The continuous development of the reusable software component computers provides a large number of technologies, powerful application software systems, and also bring corresponding problems to software developers and users: · Software system is large, developing cycle Long, high maintenance cost; · Software system is too complicated, integrating various functions in a system, most features can not flexibly loading, separate upgrades or reuse; · Application software is not easy to integrate, even if applications are used The programming language is written and run on the same computer, and the data and functions of a particular application cannot be provided to other applications. To overcome the above difficulties, implement the software "plug and play" in the whole industry, the key is to solve the operability, scalability, language independence, and cross-platform operability. As a solution for solving such problems, object-oriented programming ideas have been developed for more than 20 years. Isolated object-oriented thinking is powerful, but current development has been close to the limit, resulting in a large number of "object dislocation". Object-oriented ideas and component programming ideas have developed new roads to this field. In general, software components are a well-defined independent, reusable binary code, including functional modules, encapsulated object classes, software frameworks, and software system models. At the end of the 1960s to the early 1980s, structural modular software development idea dominates, the meaning of the components at the time refers to some defined methods or functional modules. Since the 1980s, object-oriented software development ideas rapidly developed, and the meaning of software components is the class library. Although the class provides encapsulation, polymorphism, and inheritance, it is necessary to rely on specific programming languages, high coupling degree, and require users to understand the structure and host language of the class library. Therefore, the software cannot be fully reached Reuse of portability and interoperability requirements. After the 1990s, the connotation of the components was further strengthened, and the polymerization, independence and reuse were further improved. Currently, components in an object-based component software architecture refers to binary codes and data that can be easily inserted into a language, tool, operating system, and network system. Such software components can be seen as a software integrated circuit component, with the following features: software IC has natural aggregates of hardware ICs, constitutes a size freedom of granularity, easy to expand; · Classify a unified binary standard The intelligent interoperability mechanism and language independence; · The outside world is only accessed by the interface; · Multi-side resistance, that is, the semantic level of the component expression can be connected from different sides, the external characteristics are not unique; · Support package , Polymorphism. Component model based on classical orientation technology is a strong support for software architecture design and large application software development, which has been widely accepted for software industries. Microsoft's OLE / COM and SUNSOFT Javabeans are typical software components specifications.
1.1 JavaBeans Java Bean is a Java environment, visible, stereotable, reusable component; JavaBeans component model is SunSoft's software component standard for Bean, which specifies the framework based on all beans to ensure that Bean is available While specific functions, it is also possible to be identified, manipulated, and can save these design information, guiding the operation of running. As the visual component, all JavaBeans have the following features: Introspection mechanism, can tell the software constructor to complete the functionality, allowing the software constructor to manipulate it when design; user customization (Customization) Mechanism, allowing programmers to use software construction tools to change the appearance and behavior of beans in software development phases. • Event mechanism, capture events, trigger events, and inform the software constructor to generate and process events. · Properties mechanism, in addition to supporting user customization in software development stages, making software systems to process and control BEANs at runtime; • Presistence mechanism, save programmers, using constructor to use Construction Tools to Bean Make changes and recovery at runtime. · Design timing function and runtime functional separation. JavaBean is mainly used for visualization environments, which can be used for software constructors, but can also be manipulated directly through program interfaces, and corresponding control classes are provided in the Java class library. 1.2 OMA / CORBA Object Management Group OMG (Object Management Group) is an international software industry association. The main purpose is to promote object-oriented methods in software engineering applications, and on the basis of object-oriented software engineering methods. Develop software architectural models and general interface specifications for the development and application of large-scale parallel systems (open parallel computing) software. OMG proposed a reference structure OMA (Object Management Architecture) of an object management structure at the end of 1990. OMA mainly involves a unified term system for object-oriented language, system, database, and application framework, an abstract framework for object-oriented software systems and distributed software system reference models based on object-oriented technology. In order to construct the above reference model, OMA specifies four standards: 1. Object Request Broker, that is, a critical communication unit, sends a message in a highly synergistic manner between different application objects; 2. Object model, that is, independently designed, portable abstract models, can communicate with other object-oriented systems that meet OMA specifications; 3. Object service, use ORB to implement basic object functions, determine logical models and physical storage methods of objects; 4 General components contain basic functions for many applications, which can be obtained by matching the OMA specifications. OMG is the Corba (Common Object Request Broker Architecture) proposed by the end of 1991, which is a technical specification in an OMA reference model. This standard specifies how to define, create, scheduling, reference objects, and how to communicate between objects. ORBs that match the CORBA specification are typical middleware that allows the client object to send a request to the service object. The basic composition of the CORBA specification is shown in Figure 5.1 Figure 5.1 The basic composition of the CORBA specification mainly includes: • Object Request Broker, is the core of CORBA. As a software component, the object can send a request and receive a response via the ORB.
In CORBA, all communications are carried out through ORB, so regardless of an object is local or remote, it is equivalent to other objects that communicate with it. CORBA does not specify how to implement an ORB, almost every different product has its specific ORB implementation. • Interface Definition Language IDL (Interface Definition Language) is an advanced symbol language for describing the object interface. IDL does not involve the implementation details of any interface, all COBRA systems implements interfaces in a particular language according to IDL. Corba has made specifications for C, C , SmallTalk, and Java, and the mapping specifications for ADA95 and COBOL are also developed. The IDL description is usually stored in the interface repository. · Interface repository, including all IDL definitions that describe service object properties, operation, custom data type, and exception processing. · Basic object adapter BOA (Basic Object Adapter) describes the interface between ORB and server-side applications. BOA is responsible for scheduling the objects maintained by the server, and exchanges messages with the service object. · Static request interface SII (Static Invocation Interface). SII assumes that the customer objects can clearly understand the interface of the service object, that is, the relationship between the customer and the server should be known, fixed, and any change in the service interface will cause recompilation of the software system. SII is described by IDL. • Dynamic Request Interface DII (Dynamic Invocation Interface) is a set of unrelated to the server. Information related to new service objects and their behavior can be obtained through the interface library, and the client program can dynamically construct a request at runtime based on this information. DII makes it possible to develop intelligent plug-and-play software systems, but it is necessary to involve a large number of CORBA API calls, increasing the complexity of the software. In summary, CORBA provides an integrated framework that can be inserted into the framework as long as the application is written to the interface definition language IDL (Interface Definition Language), and works with other objects to achieve different applications in a distributed environment. Integration of plug-and-play provides strong support. 1.3 OLE / COM, like CORBA, Microsoft's OLE / COM is an open standard based on distributed object models, supports multi-system software developers, independent software development (ISV) merchants, and users. OLE is actually a set of high-level technologies based on the component object model (COM). From the perspective of the basic middleware function view, COM is very similar to CORBA, which also supports communication between the object's definition, creation, scheduling, reference, and objects, and provides the Interface Definition Language (IDL). But there is also a significant difference between the two. For example, COM supports binary compatibility between objects implemented by different programming languages or different compilers, and OLE Automation, etc. The structure of OLE / COM is shown in Figure 5.2. The core of this structure is the component object model (COM), supports the definition, creation, elimination and scheduling of objects, and provides traversal and inquiry object interface. Figure 5.2 OLE / COM Structure Services Control SCM (Service Control Manager) Conses into search service objects and establishes channels between customers and servers. When the customer issues an initialization request to a particular object, the SCM determines whether the service program containing the object has been running. If it is not, then the location of the service program is located via the registry. Subsequently, the client SCM establishes the RPC channel connected to the server-side SCM; the server-side SCM also performs the same processing, and starts the service program in the case of necessary. Finally, SCMs at both ends of the channel load the agent (Proxy Stub) into the client process and server processes.
OLE / COM provides a similar advanced description language similar to CORBA IDL to define interfaces on COM concepts, namely a set of logic related operations or methods. Another feature of the OLE / COM structure is Automation, allowing client programs to dynamically construct requests (including method names, related parameters, etc.), and send requests to remote objects. In CORBA, the client program can obtain information about the object interface through the interface library; and OLE / COM further, any OLE / COM specification can automatically provide the interface information they can support. 2 Distributed Object Middleware Since the 1990s, computing technology has gradually entered the network-centered new period, and users are urgently hoped to build more distributed client / server applications on the Internet; not only implement data sharing, but also support knowledge sharing and Sharing of various types of computing resources; and can achieve collaborative work including each level of the entire enterprise. In order to adapt to the above requirements, the distribution object technology has become the mainstream direction of the development of distributed computational environment. Its technical features are: 1. Mainly for application interoperability in heterogeneous environments; 2. The core object management of the system will combine the client / server model with object-oriented technology; 3. Provide object-oriented API; Become a core technique for establishing an integrated framework and software component standard. On this basis, in order to solve the contradiction between the integration and scalability of the large application system, the Middleware (Middleware) technology came into being. The middleware is a functional hierarchy between the application layer and the network layer, enabling the application system independent of the underlying environment consisting of the heterogeneous operating system, the hardware platform and the communication protocol. The middleware expands the client / server structure, forming a three-layer structure and multi-level structure including customers, middleware, and servers, providing powerful support for developing reliable, scalable, complex transaction-intensive applications. . The middleware can be divided into four types: 1. A middleware based on the RPC (Remote Procedure Calls). RPC is an extension of process call in traditional programming language, and the object being called can be on any physical platform in the distribution system. OSF's DCE and SunSoft's ONC , etc. are such middleware. 2. Middleware for messages, support inter-process communication methods based on messaging. Such middleware is applicable to the client / server model, but also for peer models, which typically have higher operating efficiency than RPC-based intermediates. Typical systems include: Sunsoft's Tooltalk, PeerLogic Pipes and Talarian's SmartSockets, etc. 3. Someial parts based on ORBS (Obecjt Request Brokers), such middleware is the first choice for object-oriented applications. The message is routed through the ORB, and the ORB handles integration and security issues. Microsoft's OLE / COM / DCOM and OMG CORBA are all such middleware. 4. Database Middleware Supports transparent access to the heterogeneous traditional relational database. The existing such system includes Sybase's Open Server, Oracle SQL Connect, and WebLogic's WebLogic, etc. 3 Application Software Architecture Software Arranges Based on Object-Oriented Technologies is an organizational structure of a program or system, and the relationship between them and principles and guidelines for designing and evolution of domain design systems. Generally, a system software architecture describes all computing components, interactions between components, and how to combine components and connectors together. The primary issue of research software architecture is how to represent software architecture, which is how to model software architecture. For applications where the scale is increasing, the structure and increasingly complex application applications, the design goal of the system model is to improve the openness and integration of the actual application system, while taking care of efficiency. The openness of the software system includes the openness of the data, the openness of the function and the expansion of the system, and whether it has good openness substantially on the system model.
The integration of the software system refers to the consistent information description and processing mechanism to unify each function subsystem to the same integrated environment, and the quality of integration is basically on the system model. The efficiency of the software system usually includes efficiency and application development efficiency and application development. Running efficiency is the time and space complexity of the system runtime, and the efficiency of application development refers to the evolution and execution efficiency of development. Most of the efficiency depends on the system model and is also related to the specific implementation of the system. The open system model makes the integration of sub-function components, and it is also necessary to improve the efficiency of application development; integration and efficiency, which are beneficial to better achieve the purpose of opening up. These three complement each other, which is based on openness as an integration and efficiency, only openness is integrated, only openness is efficient. In response to the openness of the application software system, many types of system models have emerged, representing different stages of application software technology and industrial development. Representative system models in each stage are: with data-centric system models to perform centered system models, object-oriented system models, and bus-based system models. The data-centric system model is shown in Figure 2A. Such models put the database in the core level sharing of the system, each functional component adopts a unified data description, the development process of each subsystem is completely independent; there is a unified data exchange interface between the subsystem; the overall expansion is good, can be arbitrary Increase applications that meet data exchange standards. However, this model is loose, and the integration is not good; only data reuse can not be done, causing a large number of code redundancy; it is difficult to define all application requirements due to the existence of application related data. Data interface criteria, therefore there will be data semantic distortion. From an open perspective, such systems have only data openness and does not have functional openness, but their expandability is very good. The implementation-centered system model focuses on the sharing and consistency of data and user interface through a unified execution center, as shown in Figure 2B. Such models are separated from the application from the application, put in the execution center, avoid code redundancy; user interaction with the system is separated from the application, which is easy to implement unified user interface; and database Any data exchange must be carried out through the execution center, which is conducive to the strict management of the data to ensure the consistency of the data. Such models solve problems with code redundancy and interface style of data-centric system models and interfacial style, but there are still some defects: the functional design of the execution center is complex, it is difficult to define the set of functions that meet all application requirements, and It is also quite difficult to implement; the implementation of the Center maintains communication with the user interface and all applications, and manages data, the burden is over, and it is easy to form a bottleneck. In summary, this type of model has both the openness of data, and has the openness of function, and the expansion is also better than the data-centric system model. With the maturity of object-oriented technology, more simply object-oriented system models have a large difference with the design idea of the first two types of models, as shown in Figure 2C. Among them, the system kernel object package is data and corresponding operations that can be shared for user interface objects and all application objects; user interface objects are packaged by user interface data and corresponding operations; application data is applied in application objects And the corresponding operation. All of these objects accomplish the specified feature by communication coordination between each other. From the perspective of the system, the structure of such a model is not centered, and the system consists of each object entity, and each object entity has an equal position, which is different from the data-centered and performing a center model. The main advantage of object-oriented system model is that the rational package of data and functions reduces overhead and operational complexity on communication due to centralized management of data and functions; in addition, the system's non-central structure also enables the system The composition has become more flexible.
Overall, object-oriented system models must be better than the top two models regardless of its openness or their effectiveness. Object-oriented models have made great progress than previous models, but there is still enough: the connection between objects is a direct contact with point-to-point. When the number of objects in the system increases, the number of communication links will increase in square level; To support communication, each object entity must maintain a functional service information library containing all object entity function service information, which is not only repeated, but also guarantees its consistency. These overheads have damaged the efficiency of the system. A bigger problem is that the object's interface has no consistent criteria, causing the random and irregularity when the object is expanded, which is not conducive to the system maintenance and the multiplexing of the object. The gradual maturity of the object-oriented component and the middleware technology is introduced to the application of software system into new ideas, producing a bus-based system model, as shown in Figure 2D. Components, middleware is the new software engineering technology that has developed after object-oriented technology is an extension of object-oriented technology. The bus-based system model is still an object-oriented structure, but the object in the system is a module designed according to the specification, which is a good software module (component) coexistence in the system and fully interacts. According to this configuration, several components can be combined to establish greater and more complex systems. The key to this model is a highly efficient bus structure that enables the components to be connected to each other with a public interface, and the components are plugged, and seamlessly integrate. In this model of this model, the number of communication links between components is linear, and since the complexity of communication is greatly reduced due to consistency of each component interface specification, the interoperability of the components is also improved. The components in the application software system can be divided into two levels according to the difference in the status of the components in the system: core components and application components. Compared with the core components, the system services required by the application component are much less, and the frequency of requesting services is also low. Accordingly, the bus can also be divided into a core bus and a bus to form a dual bus structure. In this bus structure, the core component and application components still maintain good interoperability, but the application bus shields a part of the service request of the application component, reducing the traffic on the core bus, thus improving the core of the application software system. effectiveness. The core components and core bus constitute the prototype and framework of the application software system, and is integrated with each application components on this basis. Usually in a distributed environment, the application component is not directly connected to the application bus (also known as Broker), but is indirectly connected to the bus through a software agent (Agent), as shown in Figure 3. The role of Agent is that on the one hand, the complex communication process of application components, enabling application components more focused on functional implementation; on the other hand, the heterogeneous data inside the components that adapt to different application needs into group data to ensure Broker Communication language unity. It can be seen that in the bus-based system model, Broker and Agent constitute an intermediate between application components (customers) and core systems (servers). 4 Parallel object-oriented technology parallel computing is the development direction of future computers. The combination of object-oriented and parallel calculations is a relatively new research area, and many problems are to be resolved. At present, some popular object-oriented programming languages (such as C ) only provide the ability to describe program sequence; even if some languages (such as SmallTalk) provide a mechanism for concurrent execution, but often use some traditional concurrent control modes and facilities There is no characteristics from the object model itself to consider concurrent control, resulting in concurrent conflicts with some concepts (such as packages, inheritance and autonomy) in the object model.
In recent years, many protocols for object-oriented concurrent programming can be proposed, can be summarized as three different methods: 1. Design new concurrently-oriented language; 2. Extended existing sequential orientation language; 3. Object-oriented using existing sequence Language, provide concurrent abstraction through external libraries. The concurrent library is the most important method in which object-oriented technologies is. The advantage of this method is that it is not necessary to modify the original sequential object-oriented language, retain the original programming method, can better use some of the characteristics in object-oriented technology, and users are easily accepted. In order to introduce concurrent mechanisms in the object-oriented model, the design of the concurrent library must be able to organically integrate some existing features in the object model to extend the ability to describe the system and issue the system-oriented programming language. In addition, this method generally requires support of a certain underlying special software (operating support system), and all the complexity of the support system is hidden in the class library. The sequential object model consists of a group of passive objects. The execution behavior of the system is that the outside world activates a method of an object, and the execution of the method sends a message to other objects in the system, thereby activating the execution of these objects. The message transmission here is the process call, that is, the message sender must wait until the corresponding method of the message recipient can continue to perform, and the entire system has only one thread. In the object-oriented concurrent model, the basic unit that can be implemented concurrently is an object, called concurrent object. Different from ordinary objects, concurrent objects have their own control clues and separate address spaces, and multiple concurrent objects can run concurrently, and the interaction is requested by way of the method (message delivery). There are currently two typical schemes for constructing concurrent objects: 1. Send with asynchronous messages. That is, an object is sent to another object, the former does not have to wait for the latter to process the message to continue, the latter is cache the message; 2. Object can have a body (Body), once the object is created, this body start execution. In Scheme 1, a new execution thread is generated by the asynchronous message, thereby causing concurrent system. Since asynchronous messaging is used, it is necessary to provide a facility how to obtain return values in the future. The shortcomings of asynchronous messages are: it makes the behavior of the program, which is not conducive to the reasoning of the program. Solution 2 Generates a new execution thread by creating a new object, while the object is executed, the object can also receive and send a message, and the message transmission can be synchronously, but the interior of the object should be allowed, otherwise it is easy to cause a deadlock. Objects in concurrent environments, always face concurrent and transfer of their methods. In order to ensure the consistency and integrity of the object state, it must be synchronously controlled. Synchronization control can be executed by the message sender or executed by the message recipient. However, if synchronous control is only performed by the message sender, when the message sender does not perform synchronous control due to various reasons, the summary and call of the message recipient method will result in inconsistency and incompleteness of the internal state of the message recipient. Therefore, the message recipient itself must provide synchronous control. Synchronous control of concurrent objects can be divided into two categories: condition synchronization and mutual exclusion. Conditional synchronization means that the object can only accept certain messages in some state; mutually exclusive means that when the object in some state can accept (processing) multiple messages, because the processing of these messages may use the object. Member variables, if they are executed simultaneously, there is a member variable problem of shared objects, in order to ensure the integrity and consistency of the object, these methods must use the shared variables. How to describe the synchronous control of the object in concurrent object classes, generally there are two ways: centralized control and dispersion control. The centralized control mode is to describe the synchronous control of the object in a certain place in the object (class).
