精品其他业务收入业务流程图酒驾标准标准间羽毛球场地

精品其他业务收入业务流程图酒驾标准间羽毛球场地 Business-Object Architectures and Standards Cory Casanave Data Access Corporation 14000 S.W. 119 Avenue Miami Florida 33186 USA cory_casanaveomg.orgABSTRACT: Business information systems have become an integrated part of themodern enterprise and as such are required to enable the enterprise to serve and adaptto complex and dynamic business needs. An application architecture based on “businessobjects” is proposed as a way to build information systems to better meet these needs.Business objects are defined as components of the information system that directlyrepresent the business model.KEY WORDS: business object interoperability OMG BOMSIG CORBA Businessmodel.BIOGRAPHY: Cory Casanave is the founder and a co-president of Data AccessCorporation a developer of object-oriented application-development tools and chairmanof the OMG Business Object Domain Task Force BODTF as well as a member of theOMG board of directors.1. IntroductionThe quality of a company’s information system has become recognized as a strategiccorporate advantage. Information systems have become the backbone of the modernenterprise and as such are crucial to its functioning. An organization with the appropriateinformation tools can take advantage of business opportunities quickly and can adapt itselfto changing business requirements.Despite advances in hardware software client/server technology right-sizing distributedcomputing and better methodologies corporate information processing continues to fightthe complexity inflexibility and poor performance of its current mix of solutions.As the enterprise has become more dependent on its information-processing capabilitythis same growth of dependence has put stress on that very capability. Poor performancesoftware backlogs and inflexible systems are unfortunately the norm.Many solutions have come and some have gone to help with this problem. Some of thesesolutions—the ones that hold the most hope—are difficult to integrate and move to fromexisting technologies. Client/server and distributed-object computing in particular are seenas hopeful solutions—and are hard to integrate.Products services and techniques that help overcome these problems can be critical to thesuccess of the enterprise. OMG Business Objects and the Business-ApplicationArchitecture are intended to enable such products services and techniques by creating astandard framework for business applications using OMG’s CORBA.It is not the intent of this paper to define or specify a business-application architecture or abusiness-object protocol. Rather it is the intent to identify the advantages of need forand practicality of such standards in order to foster further work in this area.1.1 Terms usedTerms used in the Business-Object domain correspond to terms used for similar butlower-level concepts in other disciplines. The following table relates terms used in thismodel to the other domains.Business Objects Object-Oriented Software SmallTalk EngineeringBusiness Object Entity ModelPresentation Interface PresentationBusiness-Process Object Controller Control2. OMG Business ObjectsObject-oriented systems have existed for about twenty years but have only gainedwidespread acceptance in the last five years. In particular objects have come to dominateuser interfaces and system programming. Objects are visible to users as icons boxes andwindows on the screen that they manipulate directly. This style of user interface originallydeveloped by Xerox PARC has spawned a huge advance in the ease of use esthetics andpower of end-user software.Objects have also been used extensively by advanced programmers in systems softwareand applications. Objects are now part of the implementation of almost every major pieceof software. While not fully exploited object-oriented programming is currently helpingmake software more reliable and reusable.Paradoxically objects have not been widely used to represent the business itself. Abusiness can be “modeled” in terms of objects that make up and reflect it. Objects canrepresent inventory and invoices customers and salespeople. Objects can also representevents in a business such as purchases sales and other types of transactions.Modeling the world as objects and then implementing them in an object-oriented system isthe basis of object-oriented technology. It is time that the power and ease ofunderstanding inherent in objects be applied to the business itself. Anything that is relatedto the finances products or customers of an enterprise can be a business object and workas part of a cooperative business-object system.Put another way business objects represent things processes or events that aremeaningful to the conduct of the business. Business objects can be distinguished fromprogramming objects such as arrays and I/O channels or from user-interface objects suchas buttons and windows. Business objects can also be distinguished from system objectssuch as your word-processing program. Business objects make sense to business people.2.1 Definition of a Business Object A business object is a representation of a thing active in the business domain including at least its business name and definition attributes behavior relationships rules policies and constraints. A business object may represent for example a person place event business process or concept. Typical examples of business objects are: employee product invoice and payment. The business-object abstraction which models the real world is represented by an object in the information system. Each such object in the information system is a component of that information system and must be supported by a technology infrastructure. Burt 952.2 Description of an OMG Business ObjectThe following Description of an OMG Business Object has been adopted by OMGBOMSIG and is included here for reference Burt 95.OMG Business Objects are representations of the nature and behavior of real-world thingsor concepts in terms that are meaningful to the business. Customers products ordersemployees trades financial instruments shipping containers and vehicles are all examplesof real-world concepts or things that could be represented by Business Objects.Business Objects add value over other representations by providing a way of managingcomplexity giving a higher-level perspective and packaging the essential characteristics ofbusiness concepts more completely. We can think of Business Objects as actors role-players or surrogates for the real world things or concepts that they represent.Business Objects can act as participants in business processes because as actors they canperform the required tasks or steps that make up business processes. These BusinessObjects can then be used to design and implement systems in such a way that thesesystems exhibit and continue to maintain a close resemblance to the business that theysupport. This alignment is maintained because object technology allows the developmentof objects in software that mirror their counterparts in the real world.Business Objects allow an enterprise to communicate model design implementdistribute evolve and market the software technology that will enable them to run theirbusiness. The implications of Business Objects include: Communication: Business Objects provide common terms and ideas at a level of detail which can be shared among business and technical people to articulate and understand the business in business terms. Modeling: Business Objects have certain characteristics and behavior which enables them to be used naturally in modeling business processes and the relationships and interactions between business concepts. Design: Business Objects represent real-world things and concepts which enable design effort to be concentrated in manageable chunks. Implementation: Business Objects have late and flexible binding and well-defined interfaces so that they can be implemented independently. Distribution: Business Objects are independent so that they can be distributed as self- contained units to platforms with suitable installed infrastructure. Evolution: Business Objects can be used in a variety of roles and evolve with the needs of the business. They provide a means for integrating migrating and evolving existing applications. Marketability: Business Objects have the potential to be commercially distributed and combined with Business Objects from other sources to facilitate a market in Business Objects.More formally a Business Object and its component parts are defined as: Business object: a representation of a thing active in the business domain including at least its business name and definition attributes behavior relationships and constraints. A business object may represent for example a person place or concept. The representation may be in a natural language a modeling language or a programming language. Business name: the term used by business experts to classify a business object. Business definition: a statement of the meaning and purpose assigned to a business object by business experts. Attributes: facts about the business object relevant to fulfilling its business purpose. Behavior: the actions a business object is capable of performing to fulfill its purpose including: recognizing events in its environment changing its attributes and interacting with other business objects. Relationship: an association between business objects that reflects the interaction of their business purposes. Business Rules: constraints which govern the behavior relationships and attributes of a business object.2.3 Business Objects Are Not DBMS TablesBusiness Objects may at first seem much like tables in a relational DBMS since tablesalso represent business information. In some simpler cases there may be a directcorrespondence between a business object and a DBMS table. But in most cases thebusiness objects will be implementing rules and processes beyond the capability of aDBMS. They may be combining multiple tables managing distribution or managinginformation that is not even stored in a DBMS like online stock price quotations.Business objects represent multiple tables processes and rules at a higher level than theDBMS table.2.4 Business Objects and Legacy SystemsBusiness objects can be built using any form of new development tool or they can be builton top of existing software.For example let’s assume you have an application with 800 users running on a proprietaryDBMS and there is just no way for you to flip a switch and have these users run on anewly designed system. However you would like to add some new functions today andthen transition to a new more-powerful DBMS over time— howA business-object “wrapper” is written in the language of the existing DBMS businessobjects do not have to be implemented in an object-oriented language using a business-object framework. The relationships rules and procedures for using the object areimplemented as part of the business object using the existing libraries and methods of thelegacy application. This new business object can then be used as part of the new business-object architecture while still using the existing legacy application. Critical new functionscan be added on top of the business objects. This is using object techniques withoutchanging the legacy programming environment. Conceptually the user interface of the oldprogram can be replaced by the Business-Object framework.New presentations are designed with a business-object toolkit or another language to giveusers a consistent view of their applications through the business objects. These newpresentations can be used at the same time as the original programs.As time permits the legacy application can be replaced—piece by piece until it is gone.Once the legacy application is gone you are free to re-implement the business object withmore-current DBMS systems and tools without changing the other business objects orapplications presentations that depend on it.Legacy applications may be wrapped at the DBMS level as in the above example or atthe application level. Business-object wrappers may communicate directly with the legacyprograms which may or may not store information in a DBMS.It is a unique feature of the business-object architecture that it works so well for buildingnew applicationsand providing a transition strategy for legacy applications and data.Frameworks adaptors and re-engineering tools can be produced to assist with thetransformation of legacy systems in any language on any DBMS or transaction processor.3. The Business-Application ArchitectureThe Business-Application Architecture BAA represents an application architecture and aprotocol for “cooperative business objects” Sims 95. It is not the architecture of thebusiness or of a specific application but an architecture for how to represent andimplement business concepts as business objects. The BAA is the “glue” that binds thebusiness model with the technology. The BAA together with an appropriateimplementation will provide a architecture in which business-object attributesrelationships business rules and application rules can be implemented. Objectsimplemented in this way will then be interoperable with other business objects that wereimplemented in this way.All information systems have an architecture. That architecture may be formalized andstructured or it may be informal and implied. But for a system to operate there must beagreed-to conventions structures and protocols - this is the architecture. Most“application-development systems” combine an application architecture with tools andsometimes a language to help implement that architecture. The architecture becomes partof the way you use the system or language.The application architecture can be thought of as that layer between the high-levelbusiness objects being implemented and the low-level languages operating systemsobject-request brokers and DBMS systems. As part of the architecture a “protocol”exists for the components of that architecture to interact The protocol includes an objectmodel all interfaces rules constraints and ordering considerations.The BAA is not a standard business model it does not attempt to specify the standard orcommon components object structures or processes in a business. It is a standard way torepresent any business model as a structure of executable distributed objects.3.1 How Does the BAA Fit with Tools and LanguagesThe business-application architecture does not attempt to specify the correct or bestmethod for implementing business objects. Any combination of computer languages4GLs design tools frameworks rule-based systems and expert systems may be employedto implement a business object. Frameworks and other forms of tools and components areanticipated as products that assist developers or users in defining and implementingbusiness objects that enable the business-object protocol. The BAA and underlyingtechnologies provide a structural layer that allows differing implementation vehicles towork together in the same businesses.It is expected that higher-level interfaces will be provided so as to hide the highly technicalInterface-Description Language IDL interfaces from application developers. Thesehigher-level tools and frameworks will provide standard BAA-to-IDL interfaces as a“framework” that application developers can use more easily. The high-level frameworksand tools will provide interfaces appropriate for directly defining business objectsattributes relations and business rules. In that these high-level interfaces may interoperatevia the BAA protocol we do no.