There will be some problems when using object-oriented architecture and technology. These issues must be solved in full understanding of architectural and technical meaning. Defining object-oriented problems and component techniques containing object technology have been discussed earlier, and the comparative situation of object technology and other technologies (eg, process-oriented techniques) has been discussed. There are also some other problems and requirements for specific categories. Security issues on performance, reliability, and Internet, and how to integrate these technologies and plans in important market share are important issues in our adoption of these technologies. Some of the following contents explain some basic concepts that describe the object-oriented architecture of business and application ends. Moreover, the case is designed for applications for open system technology in the development practice of object software. In addition, it also talked about issues development issued by applications such as object technology, integrating traditional systems, monitoring these technologies in implementation and development. We must focus on the business technology based on open systems is evolved in accordance with the basic principles of determination. These principles are clearly defined by a model established by Carl Cargill, which describes five phases of standardization (Figure 17). When you create an open system standard step, it is necessary to define a reference model. The reference model defines the common rules, concepts, and the terms used throughout the standard family. These reference models are also applied to the integration of object-oriented architecture and application systems. The reference model is an element that is often forgotten in the software engineering step, but it can solve complex problems. Establish a formal reference model by formal open system steps requires a lot of effort.
Figure 17 Standardized five stages
A typical reference model of the International Standardization Organization requires approximately ten years to form a clear expression. According to the reference model, a large number of industry standards can be established, and it is a little shorter when it is officially standardized. It takes about seven years. Reference models and industry standards are usually the intelligence of many technical manufacturers. These standards are performed as the most common technical name based on the maximum number of consumer bases. To apply these technologies, there is a need to define a number of outcomes to serve as a role in a specific range or application system collection (Figure 2.13b). Summary Description is divided into two categories: Functional Profiles, generally defining standards for some application in a specific range. These typical ranges may include mortgage or automotive manufacturing. Functional summary defines a general practice of multiple companies in the same industry. Functional Summary can be a product of information technology vendors, but is usually the combination of technologies and manufacturers. Summary of the next level is called System Profiles. The system summary defines how a specific set of systems uses some or some standards. The group system is usually associated with a business or virtual enterprise. For example, a set of electronic data exchange criteria used by Ford Motor defines how the company and its manufacturing process vendors provide real-time inventory management, so that the Ford's production line can produce organized and will not be interrupted. The system summary is the Application Systems, which is a specific implementation. Although the concept of summary is brand new for many software engineers, all systems have been implemented, and of course it may be implicitly implemented. Regardless of the standard or commercial technology to apply some general purpose, some decisions on how to use this technology are made, and these decisions form an outline. Unfortunately, many important summary is hidden by the implementation details of the information system. Please note that the time span for establishing each type of specification is shortened. It is intended that the reference model provides a framework for stabilizing architecture for all standards, summary and systems for long-term development. The industry standard provides the next level of stability and coherence, providing the stability and consistency of multiple scope and application groups, all of which support the rapid establishment of applications that belong to half a year and a half. Figure 18 shows a reference model for a particular information technology vendor. In general, a vendor uses a single reference model across multiple industry standards. The manufacturer implements technologies that meet these standards, followed by different application developers and vertical markets to define these technologies in a very valuable business system. This has a amplification factor for vendors. By using this approach, potential large consumers are activated by the technologies they provide. Figure 18. Standards of vendor perspectives
Figure 19 describes this concept from the perspective of the terminal application developer. Based on fuzzy judgment, this chart is a bit funny, but it is a representative challenge facing the object-oriented architecture in various types of information technology. For a given application system, a large number of standards and reference models potentially apply to the development of the system. A small amount of functional profiles and system profiles can be obtained by the framework to guide the development of the application system. There will be some access in the application implementation and industry standard summary. Because the summary is basically the responsibility of the user, it is appropriate to be blamed during the guidance.
Figure 19. Standards for users and application developers
When there is no summary between application system items, possible results is that the system will not interact, even if they use the same industry standard, even products from the same manufacturer. This is a confused and hindered situation for the application architecture. In order to solve such problems in future system development, we understand these principles are necessary.
