Patent Application
20070220481
An application environment sometimes incorporates a process wherein source code is generated based on a corresponding model. Thus, for a given model element (e.g., a model element contained in a model file, in a database, in memory, etc.), related source code may be defined in one or more source code files. A substantial portion, if not the majority, of source code may be generated through a process that involves making reference to a corresponding model.
As the size and complexity of models increase, the initial creation of source code files upon loading, regardless of whether created previously, can become very slow and expensive in terms of processing resources. Further, it is often desirable that generated source code be recreated to reflect changes made in the model. Thus, source code files may be overwritten or recreated many times during the life of a corresponding model. The process of regenerating code files in response to model changes is also often slow and expensive. In some instances, all code files may be regenerated for each model change, including code files that are not affected by the change.
The discussion above is merely provided for general background information and is not intended for use as an aid in determining the scope of the claimed subject matter. Further, it should also be emphasized that the claimed subject matter is not limited to implementations that solve any or all of the disadvantages of any currently known systems noted in this section.
A model corresponds to a collection of source code files. A determination is made that a change has occurred to the model. A sub-set of the collection of source code files is updated or regenerated to reflect the change to the model.
This Summary is provided to introduce, in a simplified form, a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended for use as an aid in determining the scope of the claimed subject matter.
Embodiments are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with various embodiments include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, telephony systems, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Some embodiments are designed to be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules are located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed-above and illustrated in
A user may enter commands and information into the computer 110 through input devices such as a keyboard 162, a microphone 163, and a pointing device 161, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
The computer 110 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110. The logical connections depicted in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
It is sometimes desirable to regenerate source code to reflect changes to a corresponding model (e.g., changes such as when one or more model elements are added, changed, removed, etc.). It is almost always true that a given model change will impact a limited portion of the total source code (e.g., a limited set of the total number of source code files). Thus, at least for the purpose of avoiding unnecessary processing, it is desirable to respond to model changes by selectively regenerating a limited amount of source code.
It is to be understood that system 200 is a simplified example intended only for the purpose of illustration. Actual systems are likely to be far more complex. For example, model 202 is likely to include many more model elements with many different relationships between elements. It is to be understood that additional code generators and related components are likely to be implemented for a other model elements in a manner that similarly reflects the functional relationship between code generator 204 and element B, which will now be described in greater detail.
Code generator 204 illustratively contains logic for generating B.g.cs based on 1) model element B; and 2) based on a subset of model elements directly and/or transitively referenced by model element B. In the context of the example depicted in
Those skilled in the art will appreciate that the need to regenerate source code 208 arises in a variety of different circumstances. For example, with reference to
Source code generator 204 is illustratively equipped with access to a notification functionality that enables it to become aware when model element changes, that might be worthy of source code regeneration are made. In one embodiment, an observer 218 is affiliated with code generator 204 and configured to monitor changes to related dependent model elements. When a change that may be worthy of source code regeneration is detected, observer 218 communicates appropriate notification to code generator 204. Code generator 204 then reads the model as necessary to support regeneration of source code.
In accordance with block 304, a change is detected relative to at least one monitored dependent model element (e.g., a change such as when one or more model elements are added, changed, removed, etc.). Finally, in accordance with block 306, a code generator is activated to cause a limited regeneration of source code directly related to the change. In one embodiment, only source code related to dependent model elements affected by the change is regenerated. In one embodiment, source code related to all monitored dependent model elements is regenerated, regardless of which of the dependent model elements is actually affected by the change.
Opportunities to improve processing efficiency do arise in other scenarios. For example, another scenario occurs during the initial creation of source code files upon initial loading of the model, regardless of whether the files have been created previously. Another scenario might occur when model changes made off-line are eventually brought on-line. In at least both of these cases, the source code may be outdated relative to the model. It would be desirable to update the source code without total regeneration. It would be desirable to exclude regeneration of many source code files that are not impacted by model element changes.
In accordance with one embodiment, after dependent objects have been enumerated for a given code generator, the code generator can be configured to initiate an update of the corresponding source code in response to a trigger other than a change notification received from a model element observer. Examples of alternate triggers will now be described.
Thus, in one embodiment, assuming model elements contain a “last changed” indication, the code generator illustratively compares the indication for its dependent objects with the time stamp for the corresponding source code (e.g., B.g.cs). If the source code is newer, then there is no need to regenerate the source code. Otherwise, the code is regenerated.
It should be noted that the scope of the present invention is not limited to a timestamp implementation. For example, a checksum can instead be calculated from dependent objects and compared with a checksum that is stored in a file next to the source code or directly within the source code. The checksum implementation could be desirable to avoid inconsistencies in timestamps caused, for example, by moving model elements and files between machines whose clocks are not synchronized.
In accordance with one embodiment, for a given code generator, after source code is brought up to date with corresponding dependent model elements, monitoring of the elements is then passed to a listener object (i.e., a dependent object observer) that subscribes to add/change/remove/etc. events. If one or more dependent objects are changed, the listener object notifies the code generator about it, and the code generator regenerates source code accordingly (e.g., regenerates B.g.cs.). In one embodiment, when even one dependent object is changed, the entire corresponding set of dependent objects is recalculated because the entire set may have also changed.
The described system can be configured to provide customized support for a transaction-based modeling framework in which multiple model elements can be changed (e.g., added/changed/removed) in one transaction. For example, the system can be configured such that the listener object (i.e., the dependent object observer) is made aware of multiple changes to dependent objects arising from a single user or system action. The listener object can be configured to respond to these circumstances by aggregating the events. When the actual transaction is completed, a single event is raised to the code generator. This avoids unnecessary intermediate regeneration.
Those skilled in the art will appreciate that the concepts of the present invention are easily extensible. For example, the so-called “model elements” described herein are not limited to being in-memory elements loaded from a file. For example, they could alternatively be rows in a database or something similar. Alternatively, a model element might be an image, a document, or any other representation of information. Further, the generated files described herein are not limited to being source code. Nor are they even limited to being files at all. They also could be rows in a database or something similar.
Further, it should be emphasized that the changes that occur to model elements and trigger source code regeneration do not have to occur in an on-line or especially dynamic environment. For example, in one embodiment, changes to the model occur offline. When a connection is re-established, the changes that occurred offline are utilized to update the model, thereby triggering source code regeneration in accordance with the systems and methods described herein.
Still further, a source code file may contain multiple parts, for example, a generated part and a user-controlled part. Those skilled in the art will appreciate that it is within the scope of the present invention to facilitate selective automated updating or regeneration of all or less than all of the parts of a given source code file (e.g., regeneration may be limited to only the generated part or only the user-controlled part). What is referred to singularly herein as a source code file (e.g., “a” or “the” source code file) may actually be a set of related files, all or some of which might be configured for selective automatic regeneration.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
