In order to improve the development efficiency, software enterprises pay more and more attention to the reuse of software elements. Therefore, architects must pay attention to reuse when designing architecture, for example, considering the enrichment of enterprise components and the full use of existing components.
Closely related to reuse technology is the concept of component (component). There is no recognized definition of component in the industry. The following are several common definitions.
Definition 1: A component is a component of a software system that can be clearly identified. The Reusable Component refers to those components that have independent functionality and reusable value. Definition 2: A component is an assembly unit that has a reduced-specification interface and an explicit dependency environment. Definition 3: A component is an assemblable software entity in a software system that has relatively independent functions, can be clearly identified, interfaces specified by contract, and has an obvious dependency on context, and can be deployed independently.
A broader understanding of artifacts is that all kinds of work products (for example, various documents, scenarios, plans, test cases, code) are reusable artifacts.
Standard specification for commercial components
At present, the mainstream commercial component standard specifications include OMG (Object Management Group) CORBA, SUN J2EE and Microsoft DNA.
CORBA 1.1
CORBA (Common Object Request Broker Architecture) is mainly divided into three levels: Object Request Broker, Common Object service and Common facilities.
Object Request Broker (ORB) is the “soft bus” in the distributed Object system, which defines the definition (interface) and language mapping of distributed objects and realizes the communication and interoperation between objects. There are many common services defined on top of the ORB that can provide a variety of services such as concurrent services, name services, transaction (transaction) services, security services, and so on. The topmost common facilities define the component framework, provide services that can be used directly by business objects, and specify the rules of agreement that business objects need to collaborate effectively.
CORBA CCM (CORBA Component Model) is a specification of server side Component Model developed by OMG for developing and configuring distributed applications. It mainly includes the following three contents. (1) Abstract component model: a structure used to describe server-side component structure and interoperability between components. (2) Component container structure: to provide a universal component operation and management environment, and support the integration of security, transaction, persistent state and other system services. (3) Configuration and packaging specifications of components: CCM uses packaging technology to manage the executable code and configuration information of binary and multi-language versions of components, and formulates specific content and document content standards of component packages.
J2EE 1.2
In J2EE, SUN provides a complete application specification for enterprise distribution based on Java language. J2EE also supports RMI (Remote Method Invocation, Remote method call) and IIOP (Internet Inter-ORB Protocol), and the construction form of distributed application on the server side includes Java Servlet, JSP, EJB and other forms to support different business requirements. And Java application program has the cross-platform characteristic, causes J2EE technology to get the rapid development in the publishing computing field.
1.3 DNA of 2000
Microsoft DNA2000 is a new distributed computing architecture and specification released by Microsoft after extending the distributed computing model and transforming the distributed computing products of Back Office server on the basis of Windows2000 series operating system platform. On the server side, DNA2000 provides application support of ASP, COM, Cluster, etc. DNA2000 incorporates today’s most advanced distributed computing theories and ideas, such as transaction processing, scalability, asynchronous message queuing, clustering, etc. DNA can develop server component applications based on The Microsoft platform, where database transaction services, asynchronous communication services and security services are provided by the underlying distributed object system. Microsoft DCOM/COM/COM + technology, based on DNA2000 distributed computing structure, presents a new distributed component application model. First, DCOM/COM/COM + components still use the normal COM (Component Object Model) Model. As the component technology of Microsoft desktop system, COM is mainly local OLE (Object Linking and Embedding) application service. But with the release of Microsoft server operating system WindowsNT and DCOM (Distributed Component Object Model), COM extends component technology to distributed applications through remote support at the bottom. DCOM/COM/COM + extends it as a business logic middleware for server-side distributed applications. Through the related service facilities of COM +, such as load balancing, in-memory database, object pool, component management and configuration, DCOM/COM/COM + combines COM, DCOM, MTS (Microsoft Transaction Server, Microsoft transaction processing server (MS) organically unified functions, formed a conceptual, functional component application architecture.
It is a common choice to improve the efficiency of application software development by purchasing commercial artifacts (platforms) and following their development standards.
Application system cluster and component system
In addition to the special enterprise development artifacts, development and application system of enterprise will also develop their own application system components: usually as the business matures, gradually developed from sorting out some components of the application system, in turn, will these component reuse to optimize and integrate existing applications or complex for developing new application system in the system.
After all, the reuse rate in an application system is limited. Software component reuse is usually carried out in the application system cluster. When several related application systems to be developed, we can according to the requirement of reuse, defined the “feature” of a set of application system, according to these common features, model, and according to the requirements of reuse, the model is decomposed into appropriate size and structure of components, these components are design, implementation, packaging, documentation, Form reusable components that are easy to use.
These reusable components will be used for the development of various application systems supporting the application cluster. A component here refers specifically to an encapsulated code module or a large-grained execution module. Software enterprises organically organize the related components together to form component system (higher level than component library). The software enterprises that implement reuse usually have multiple component systems, some of which are purchased, some of which are developed by themselves. Both application and component systems are system products (not work products). They can all be defined in terms of model and structure types.
In general, the component system is only used in the development unit, while the application system is provided to external customers. Compared with the application system, the component system has universality and reusability, which requires the implementation of more strict engineering specifications in the development process of the component system.
A component system is a system product that provides a set of reusable features. The components in the component system should be highly cohesive and low coupling, but there should be several relationships among them. You can send messages to other components; Can be federated with other components to support collaborative work. Component systems should be easy to understand and use, and components should be carefully modeled, implemented, documented, tested, etc., for effective maintenance and improvement in the future. Usually to support component reuse, a toolbox should be developed to match component systems.
An application system can input components to a component system whose needs originate from the application system or modules in the application system, and in turn, the component system outputs components to the application system. This is how component systems acquire and provide components.
Organization structure based on reuse development
Unlike traditional development organizations, reuse-based development organizations require a portion of the resources devoted to developing reusable assets, which should be separated from the development resources of specific application systems to ensure that they are not occupied.
A more balanced organizational structure, as shown in Figure 1, has three functional departments: component Systems Development, which develops reusable assets; The second is the application system project development Department (multiple), which reuse assets; The third is the support department, which is optional. It further isolates the above two main departments. Although some efficiency is sacrificed, the standardization of components is guaranteed. Its main responsibilities are to identify the reusable assets provided by the component development department, classify and catalog the component library, inform and distribute the reusable assets to the engineers developing application systems, provide necessary documentation, and collect feedback and defect reports from the reusable. It can be understood as follows: the component system developed by the component system development department is promoted to the application development department by the support department, that is, the support department is the promotion department within the enterprise. Externally purchased commercial components are also maintained and managed by the support department.
Above these three parallel departments is a senior manager (reuse manager) who focuses on the overall goals and coordinates the interrelationships. On the one hand, component developers should be as close as possible to application developers so that the components they develop can meet the actual needs as far as possible. On the other hand, component developers and application developers are two separate departments, freeing component developers from the daily stress of application projects and ensuring the development and continuous improvement of reusable assets.
Reuse managers should balance the benefits of component development against the benefits of application project development to ensure that long-term goals are not affected by near-term project pressures.