1. Field of the Invention
The present invention relates to visualization of changes in source code in an integrated development environment (IDE) and more particularly to visualization of changes in a business object model in an object modeler.
2. Description of the Related Art
Software development has evolved from the primitive specification of program code on punch cards to a source code file driven compilation and build workflow. Early, simplistic software development projects involved a single developer coding to a specification on a single development computer using a text editor to access a source code file and separate compile and build programs processing the source code file into an executable binary. As the complexity of the computer program grew in parallel to the growth of computing power, software development evolved into a multi-developer endeavor requiring sophisticated source code management and debugging tools to corral and coordinate the efforts of the developers.
Principal to the modern software development workflow is the integrated development environment (IDE). Initially introduced as the primary user interface to a particular coding language such as the venerable PASCAL or ubiquitous C++ and Java programming languages, the IDE has morphed into its own stand-alone computing product and now, is more akin to a high end word processor coupled to a document management enterprise system rather than a user interface to a hodge-podge of coding and debugging tools.
Object modeling performs a complimentary function to software development. In this regard, object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. Business Object Models (BOMs) are abstract data models (i.e. sets of packages, classes, class members and properties of the classes) meant to adapt an enterprise data model to the specific needs of a business application and business users. Those data models are abstract in the sense they have no concrete implementation by themselves. Rather, the rely on translations techniques to transform raw enterprise data structures represented in various formats into a form suitable for the end user, and translating back the end user's actions on the entities presented into updates to the low level enterprise data structures.
Versioning and managing such kinds of large object models like BOMs raises a number of issues. First, the object model is often designed and maintained by a different team than the teams who manages the applications that use the object model. Many independent applications may thus rely on the same BOM. The life cycle of a BOM tends to be longer than the applications that use the BOM. The BOM strongly relies on the information systems of the enterprise, but authorizes some decoupling to make writing rules easier and closer to the business users. As a result, BOMs are strongly coupled to both the underlying external model they represent and to the high level application (such as a set of production rules using this model). This means that when the underlying data structures are modified, some local changes must be performed on the BOM and its translation properties to maintain the consistency of the application rules that use it.
Such changes are very difficult to automate, as they mostly require contextual decisions to be made about each change. For instance, the addition or removal of a member may make some business logic obsolete, ambiguous, or even contradictory. Hence, changes to an external object model may require more than simply propagating the changes to the BOM. It may mean rewriting part of the business logic that sits on top of it. For this reason, common design guidelines recommend that the BOM definitions be cast in stone at the beginning of application development, and the golden rule is to update the BOM only when absolutely necessary and with careful control of all the implications of the changes performed.
At present, analysis and management of BOMs is done essentially with textual tools—namely text editors, textual search (sometimes with autocompletion), and some general purpose visual tools such as visual differentiators within a versioning system. The issue with these types of analysis tools is that they provide little overview information, and make it difficult to relate dependant parts of the BOM to each other. In this regard, given the vast nature of a BOM model, comparing two versions of the same BOM in a versioning user interface can be impossible to exploit as both BOMs appear to be completely different.
USPTO Backgrounds
USPTO Backgrounds