Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-12-03
2002-01-22
Chaki, Kakali (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C706S047000
Reexamination Certificate
active
06341369
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to an improved data processing system and in particular to an improved method and apparatus for managing a business system that relies on a large number of business rules. Still more particularly, the present invention relates to an improved method and apparatus for specifying and enforcing business rules in a business system.
2. Description of Related Art
Businesses use a wide variety of computer hardware and software products, for many different purposes. The hardware of a typical business information system includes a multitude of interconnected computers, printers, scanners, communications equipment, and other peripheral devices, allowing the business to automate much of the processing of its business information. The computers may be of different types, such as mainframes, minicomputers, or network servers supporting client workstations (personal computers, or PCs), or some combination of the foregoing. Business software includes (without limitation) accounting, word processing, database management, communications, publishing, and multimedia presentation software, as well as payroll, financial planning, project management, decision and support, personnel records, and office management software and further including specific business applications such as insurance claims and losses, credit approval, order entry and inventory, etc. All of these programs can run on a variety of platforms, including different operating systems. Businesses often have an Information Services or Information Technology (IT) department which is responsible for the overall management, support and planning of the company's information system needs.
One of the claims for object-oriented programming is that it makes it easier for software to model real-life business situation. The new vision of computing is of distributed Business Objects existing as independently developed executables or binaries, which can be redeployed as self-contained units anywhere in a network, and on any platform. While this represents a step forward, businesses are finding that encapsulating business logic into Business Objects provides insufficient additional flexibility over that provided by procedural-based applications.
Although the term Business Object has been in widespread use, no formal definition existed until the Object Management Group's (OMG) Business Object Management Special Group (BOMSIG) took the task of developing a consensus meaning for the term. Business Objects are representations of the nature and behavior of real world things or concepts in terms that are meaningful to the business. Customers, products, orders, employees, trades, financial instruments, shipping containers and vehicles are all examples of real-world concepts or things that could be represented by Business Objects. Business Objects add value over other representations by providing a way of managing complexity, giving a higher level perspective, and packaging the essential characteristics of business 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.
Implementing rules within Business Objects enables businesses to quickly change their automated policies and practices as business conditions change. For example, during the execution of an application, business rules can be used to decide whether to extend credit to a customer and if so under what terms. By implementing these determinations as externalized rules, they can be changed as needed without reworking the application that uses them.
Historically, developers creating business applications have embedded the rules of these applications directly in the applications themselves. Developers have built these systems without explicit regard for the changing nature of business rules. As a result, when business policies and practices change—and they're constantly changing—it's difficult, costly, and time consuming to reflect those changes in the applications that implement them.
More recently, developers have implemented business rules in database triggers. In response to database changes, database triggers are automatically invoked by a database server. The code in the triggers can execute some procedural logic as well as manipulate the database. Database triggers and stored procedures offer the advantage of modularity. They isolate business rules and technical data-manipulation rules from application logic. Triggers automate business rules processing and provide application independence (any application changing the database causes the triggers to be fired). However, triggers also have some serious disadvantages. They are hard to develop. They are intended to implement technical data-manipulation rules as well as business rules, and they are hard to maintain and extend particularly when they are used to implement business policies and practices.
Database triggers are frequently expressed in the dialect of the databases in which they're to be implemented. These languages are frequently proprietary and complex. Development is a text-editing task. There are few, if any, visual tools to assist developers in specifying trigger code.
Database triggers function on the elements and values of a database. Their specification is far more technically oriented then business oriented. Some triggers implement business rules, but many implement and enforce data integrity and data consistency. Applications builders who are using a trigger built by another developer might have difficulty deducing the business rules implemented by the trigger by looking at trigger code. Business analysts, the individuals who should be responsible for business rules specification, frequently find the triggers hard to learn and understand.
Database triggers are also hard to maintain. Developers may find it difficult to change triggers in response to business changes. Trigger development rarely fits into the overall flow of large-scale object-oriented application development. As a result, triggers tend to be hard to understand and relate to the application's business logic.
More recently, object-oriented business rules technologies have evolved which allow rules to route work through the tasks of a business process, where reasoning can be applied to complex decision-making, and where knowledge systems can perform operator assistance.
Object-oriented business rules technologies base rule processing on an application's object model or component model. Some products based on these technologies use inferencing techniques on an application's object model to create, delete, and manipulate variables and objects and to determine their values. Other products utilize a technique which always fires a rule before or after an object method. Both of these techniques are very programmer intensive, as they are built right into the objects themselves.
Business rules are different from Business Objects. Business Objects represent business entities like customers, products, and orders. They encapsulate the data and behavior needed to perform business functions. Business rules implement the policies and practices of an organization. They control the ways that Business Objects perform business functions. However, problems still exist for developers in specifying, identifying, and managing rules for an application.
One of the problems associated with specifying and applying rules to the decision points in an application system is that rule selection can be affected by the application's state at the time the decision point is encountered during execution of the application. Often different rules should be chosen to obtain the decision, based on the way things are classified by the business.
In light of the foregoing, it would be advantageous to-have a method and apparatus for specifying and applying rules to classification-based decision points in an application system.
SUMMARY OF THE INVENTION
The present invention pro
Degenaro Louis Ralph
Ehnebuske David Lars
McKee Barbara Jane Alspach
Rasmus Kevin Paul
Rouvellou Isabelle Marie Catherine
Chaki Kakali
Ingberg Todd
Mims Jr. David A.
Walder, Jr. Stephen J.
Yee Duke W.
LandOfFree
Method and data processing system for specifying and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and data processing system for specifying and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and data processing system for specifying and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2839117