Patent Application
20110161846
The creation of computer diagrams (diagrams in computer systems that can be displayed, such as by displaying on a computer display or displaying by printing) is a common practice. Many different types of computer diagrams can be created and changed (building floor plans, business process flow diagrams, etc.). One example is software architectural diagrams (diagrams that represent aspects of the organizational structure and/or function of software, and may also represent aspects of associated hardware), which are commonly used in software development systems, such as Microsoft's Visual Studio® software development system. Software architectural diagrams may include various different diagrams, such as unified modeling language diagrams or other diagrams (e.g., class diagrams, component diagrams, composite structure diagrams, deployment diagrams, object diagrams, package diagrams, profile diagrams, activity diagrams, state machine diagrams, use case diagrams, communication diagrams, interaction overview diagrams, sequence diagrams, timing diagrams, layer diagrams, etc.).
Software architectural diagrams can be created in various ways, such as manual creation or drawing, generation from source code, and/or generation from tracing a running application. Some such diagrams may be created within a software development system, and others may be imported from other diagramming tools, such as Microsoft's Visio® diagramming software.
It is also common to change diagrams after they are created. For example, software architecture diagrams may be changed to outline software design changes. Often, these changes are subsequently reflected in the source code of the application. This may happen automatically or in response to detailed user input.
The tools and techniques described herein relate to highlighting diagram changes on the diagram itself. Whatever the advantages of previous computer diagramming tools and techniques, they have neither recognized the diagramming tools and techniques described and claimed herein, nor the advantages produced by such tools and techniques.
In one embodiment, the tools and techniques can include displaying on a computer display a diagram having initial visual design elements. Changes can be made to the diagram to produce modified visual design elements. For example, the modified visual design elements may be added elements, modified versions of initial visual design elements, or even the space left by deleting initial visual design elements. The changes can be tracked as they are made, to produce change tracking information. The change tracking information can be one or more of a variety of different types of information obtained by tracking changes to the diagram. For example, the tracking information can include information that would allow changes to be undone or accepted by a user. The change tracking information can be processed to automatically highlight at least a portion of the modified visual design elements in a display of the diagram. Highlighting refers to giving modified visual design elements different visual properties than the same type of visual design elements would have if they were not modified. However, highlighting can take many different forms, such as the examples of highlighting discussed below.
In another embodiment of the tools and techniques, a baseline diagram having initial visual design elements can be generated. A modified diagram can be generated, such as by directly modifying the baseline diagram or by generating a new diagram with changes from the baseline diagram. The modified diagram can have modified visual design elements. Representations of a set of changes between the baseline diagram and the modified diagram can be captured. These changes may be changes made directly to the baseline diagram (such as changes requested directly by user input, where the changes are made to generate the modified diagram), or indirectly between diagrams (such as where a software architectural diagram (the baseline diagram) is generated from computer code, the computer code changes, and another software architectural diagram (the modified diagram) is generated from the modified computer code to visualize changes in the computer code). A first subset of the changes can be filtered out. As used herein, filtering refers to selecting one or more changes for particular highlighting treatment (such as highlighting in less conspicuous way, not highlighting at all, highlighting only at a group level rather than an individual level, etc.). The modified diagram can be displayed with the modified visual design elements. Displaying the modified diagram can include automatically highlighting a second subset of the one or more changes that does not include the first subset (i.e., highlighting changes that were not filtered out).
In yet another embodiment of the tools and techniques, a computer software architectural diagram can be displayed on a computer display. The diagram can have initial visual design elements, which can represent features of computer software code. In response to receiving user input, the following can be performed: making changes to the diagram to produce modified visual design elements; tracking the changes as they are made to produce change tracking information; and processing the change tracking information to automatically highlight at least a portion of the changes in a display of the diagram. Processing the change tracking information can include filtering the change tracking information.
In yet another embodiment of the tools and techniques, a baseline diagram can be generated from initial computer code. Changes can be made to the initial computer code to produce modified computer code, and a modified diagram can be generated from the modified computer code. The modified diagram can be displayed, including automatically highlighting at least a portion of the changes between the baseline diagram and the modified diagram, where the changes between the baseline diagram and the modified diagram can represent the changes to the initial computer code.
This Summary is provided to introduce a selection of concepts in a simplified form. The concepts 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 to be used to limit the scope of the claimed subject matter. Similarly, the invention is not limited to implementations that address the particular techniques, tools, environments, disadvantages, or advantages discussed in the Background, the Detailed Description, or the attached drawings.
Embodiments described herein are directed to techniques and tools for improved computer diagram editing, where changes can be highlighted on the diagram itself. Such improvements may result from the use of various techniques and tools separately or in combination.
Such techniques and tools may include tracking changes made to a computer diagram. The information resulting from such tracking can be used to highlight the changes on the diagram itself. For example, if a diagram feature has been modified, the feature may be changed to a different color, line weight, and/or line style from other features in the diagram. Many other types of highlighting can be used instead of or in addition to these types of highlighting.
The information representing diagram changes may be filtered, so that the changes can be highlighted more clearly on a diagram. For example, such filtering can filter out insignificant changes to the diagram and not highlight the insignificant changes. As another example, such filtering may highlight more significant changes in a different way from less significant changes. As yet another example, a group of related changes may be filtered to highlight less than all the affected diagram features (e.g., only one diagram feature may be highlighted to represent changes to an entire group of features). However, this filtering may be reverted so that all the changes can be undone (at least if the changes have not yet been accepted by a user), including the representative highlighted change(s) and the represented changes that may not be highlighted.
Accordingly, the tools and techniques described herein can allow computer diagram changes to be effectively communicated on the computer diagram itself. For example, this may be useful to communicate design changes from a base diagram to an entire team of designers. As another example, a base diagram can be sent to an entire team of designers, and each team member's changes can be highlighted when the changed diagrams are sent back to the diagram author. As yet another example, a single user may be able to view changes made by that user, and make those same changes to some other object (e.g., software code) that is represented by the diagram.
However, the subject matter defined in the appended claims is not necessarily limited to the benefits described herein. A particular implementation of the invention may provide all, some, or none of the benefits described herein. Although operations for the various techniques are described herein in a particular, sequential order for the sake of presentation, it should be understood that this manner of description encompasses rearrangements in the order of operations, unless a particular ordering is required. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Techniques described herein with reference to flowcharts may be used with one or more of the systems described herein and/or with one or more other systems. For example, the various procedures described herein may be implemented with hardware or software, or a combination of both. Moreover, for the sake of simplicity, flowcharts may not show the various ways in which particular techniques can be used in conjunction with other techniques.
The computing environment (100) is not intended to suggest any limitation as to scope of use or functionality of the invention, as the present invention may be implemented in diverse general-purpose or special-purpose computing environments.
With reference to
Although the various blocks of
A computing environment (100) may have additional features. In
The storage (140) may be removable or non-removable, and may include computer-readable storage media such as magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment (100). The storage (140) stores instructions for the software (180).
The input device(s) (150) may be a touch input device such as a keyboard, mouse, pen, or trackball; a voice input device; a scanning device; a network adapter; a CD/DVD reader; or another device that provides input to the computing environment (100). The output device(s) (160) may be a display, printer, speaker, CD/DVD-writer, network adapter, or another device that provides output from the computing environment (100).
The communication connection(s) (170) enable communication over a communication medium to another computing entity. Thus, the computing environment (100) may operate in a networked environment using logical connections to one or more remote computing devices, such as a personal computer, a server, a router, a network PC, a peer device or another common network node. The communication medium conveys information such as data or computer-executable instructions or requests in a modulated data signal. A modulated data signal is 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 include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
The tools and techniques can be described in the general context of computer-readable media. Computer-readable media are any available media that can be accessed within a computing environment. By way of example, and not limitation, with the computing environment (100), computer-readable media include memory (120), storage (140), and combinations of the above.
The tools and techniques can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing environment. In a distributed computing environment, program modules may be located in both local and remote computer storage media.
For the sake of presentation, the detailed description uses terms like “determine,” “choose,” “adjust,” and “operate” to describe computer operations in a computing environment. These and other similar terms are high-level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being, unless performance of an act by a human being (such as a “user”) is explicitly noted. The actual computer operations corresponding to these terms vary depending on the implementation.
The change tracking information (230) may be stored, and it may also be used for techniques other than change highlighting. For example, for software architectural diagrams, the change tracking information (230) may be used to generate and/or modify computer code that is represented by one or more diagrams. As another example, the change tracking information (230) may be used to generate a work list or a set of work items to be performed. For example, these work items may represent tasks to be performed by software developers in implementing change represented by the change tracking information (230).
As just one example, the baseline diagram (212) may be a diagram that is represented in XML-formatted data in a diagram file. Of course many other alternative diagram formats could be used. In this XML-formatted data example, the XML data can be modified to make the indicated changes to the baseline diagram (212) according to standard practices. The XML data can also be modified to include the change tracking information (230), such as by including additional or modified properties on objects or fields in the XML data. The modified XML data can then be processed to display the modified diagram (250) with highlighting. Other ways of storing and/or maintaining the change tracking information (230) may be used. For example, a separate database may be used to store the change tracking information (230). The filtering module (240) can include a set of rules regarding the significance of changes and/or regarding the way that changes are to be highlighted. Those may be applied in different ways. In the example using XML data, the rules may be applied before changes are made to the XML data and/or when processing the changes that have been made to the XML data to display the modified diagram (250) with highlighting.
As noted above, the filtering module (240) can filter the change tracking information (230) before and/or after the change tracking information (230) is stored. This can be done to highlight the changes being made without making the resulting modified diagram (250) too busy or cluttered. For example, when changes are made to a group of visual elements on a diagram, it may be useful to highlight only one of them (only the item whose change initiated the other cascading changes, only a border for the group, etc.). For example, in software architectural diagrams highlighting may not be done for the closure of elements associated with the element that was actually changed (e.g., if a particular message is changed, all the messages contained in its closure may also change, but those other messages may not be highlighted). Additionally, insignificant changes may be filtered out and not be highlighted or be highlighted in less conspicuous ways. A set of filtering rules, such as the examples provided in the tables below, can define whether changes are significant.
A user may still make manual changes that override highlighting. For example, if a user manually changes the color of an item that would otherwise be changed to a highlighting color, the highlighting color change may be ignored. This may be done to respect the user's choice for color change. However, in such a situation, other types of highlighting may be used. For example, line thickness changes may still be made to highlight changes.
If a user makes a gesture to undo a change in the modified diagram (250), the diagram change module (210) can undo the change, and can undo highlighting for that change as well. Similarly, a user may accept a single change or group of changes. In response, the highlighting in the modified diagram (250) associated with the accepted change can be removed, and the change to the modified diagram (250) can remain. Similarly, a user may accept all changes to the modified diagram (250) to produce a new baseline diagram with no highlighting. Change tracking may remain active after changes are accepted, so that accepting all changes to the modified diagram (250) can denote that the modified diagram (250) is to be used as a new baseline with changes being tracked from that point forward.
A user may also make a gesture to provide input indicating that change tracking is to be turned on or off. This can result in some changes being tracked when change tracking is on, and others not being tracked when change tracking is off.
III. Example of a Software Architectural Sequence Diagram with Change Highlighting
An example of change highlighting for a software architectural sequence diagram will now be described. For example, the sequence diagram may be a sequence diagram in a software development system such as Microsoft's Visual Studio® development system, and the development system may include a diagram change module that can track and highlight changes. It should be understood that the description herein is not limited to a sequence diagram or even software architectural diagrams in general. Moreover, the description is not limited to the particular types of filtering and/or highlighting described in this example. Rather, a software architectural sequence diagram is provided herein as an example of just one implementation of some tools and techniques described herein.
The baseline sequence diagram (300) includes message 1 (320) from lifeline 1 (310) to lifeline 2 (312) near the tops of the lifelines. An execution occurrence (322) can be illustrated as a rectangle over lifeline 2 (312), extending down from the end of the arrow for message 1 (320). At the bottom of the execution occurrence (322), a return message (324) can extend back from lifeline 2 (312) to lifeline 1 (310). Farther down lifeline 1 (310), a create message (330) can extend from lifeline 1 (310) to lifeline 3 (314), and an execution occurrence (336) can extend down from an end of the create message (330) on lifeline 3 (314). Additionally, an alt-type fragment (360) can extend between lifeline 1 (310) and lifeline 2 (312) below the create message (330) and to the left of the execution occurrence (336). The fragment (360) can begin with a guard, such as a guard that begins “if(profile.shoppingcart.count =”.
The baseline sequence diagram (300) can be changed, and some of the changes may affect the underlying code of software represented by the baseline diagram (300), while other changes may not affect the underlying code. The following table lists some representations of types of changes that could be made to such diagrams, as well as a representation of an example of filtering rules that can be applied to information from such changes.
In this example, changes are considered significant if they can affect the underlying software code, and insignificant changes (those that cannot affect the underlying software code) are not highlighted. However, some significant changes may not be highlighted. For example, deletions are significant (can affect code), but they are not highlighted because highlighting of such deletions may be deemed to create too much clutter in modified diagrams. Other filtering rules could be used for sequence diagrams. Moreover, different filtering rules can be used for other types of software architectural diagrams, and for other diagrams other than software architectural diagrams. For example, other criteria for determining significance could be used. For example, in diagrams that represent user interface features, significance may be based on distance, the amount of area that is affected by a change, or some other criteria. Also, filtering rules may be modifiable by users. Moreover, as noted above, filtering may include filtering out some changes to highlight a group of changes in a simpler way.
The following table illustrates some examples of how un-highlighted features may differ from highlighted features in a modified sequence diagram.
Many different types of highlighting could be used by changing colors, line thicknesses, fill types, etc. For example, because color differences are not shown in
Referring still to
If a user were to reject the highlighted changes in the modified diagram (400) of
Several computer diagram change highlighting techniques will now be discussed. Each of these techniques can be performed in a computing environment. For example, each technique may be performed in a computer system that includes at least one processor and a memory including instructions stored thereon that when executed by the at least one processor cause the at least one processor to perform the technique (a memory stores instructions (e.g., object code), and when the processor(s) execute(s) those instructions, the processor(s) perform(s) the technique). Similarly, one or more computer-readable storage media may have computer-executable instructions embodied thereon that, when executed by at least one processor, cause the at least one processor to perform the technique.
Referring to
The diagram can represent one or more features of computer code. For example, the diagram may be a software architectural diagram. Additionally, the initial visual design elements can be automatically generated from the computer code.
Processing (540) the change tracking information can include filtering the information. For example, the filtering can include classifying the change(s) into multiple categories (for example, additions, modifications, moves, reordering, etc.), and processing the change tracking information can include highlighting one subset of the categories and not highlighting another subset of the categories. Filtering can be done based on a set of filtering rules, and filtering can be based on significance of the change(s), such as visual significance of the changes and/or the effects of the changes on something (e.g., computer code) represented by the diagram. Highlighting can include highlighting a visual design element to represent a group of multiple changes to a group of visual design elements.
Referring still to
Referring to
Generating the baseline diagram can include generating the baseline diagram from initial computer code, and the technique can also include changing the initial computer code to produce modified computer code. Generating the modified diagram can include generating the modified diagram from the modified computer code. Also, the second subset of one or more changes between the baseline diagram and the modified diagram can represent one or more changes between the initial computer code and the modified computer code.
Displaying (650) may include displaying without highlighting the first subset of the one or more changes. Alternatively, displaying (650) may include highlighting the first subset of the one or more changes in a first way, and highlighting the second subset of the one or more changes in a second way. For example, the first subset of one or more changes may be highlighted with smaller line weights or with lighter colors than the second subset of one or more changes.
Referring to
Referring to
Filtering can include identifying one or more of the change(s) to highlight, and automatically highlighting can include highlighting less than all of the change(s). Also, filtering can include identifying a first subset of one or more of the changes to highlight in a first way and identifying a second subset of one or more of the changes to highlight in a second way. Filtering can be done based on significance of the one or more changes.
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.
