Display of source code semantic layers

Example systems and methods of displaying semantic layers of source code of a computer program are presented. In one example, a user selection of a first portion of the source code is received. The first portion is displayed in a first display area and corresponds to a first semantic layer of the source code. A user command referring to a second portion of the source code related to the first portion is received, with the second portion corresponding to a second semantic layer of the source code. In response to the user command, a second display area for the second portion of the source code is displayed to indicate a relationship between the first and second portions while indicating a difference in semantic layers between the first and second portions.

FIELD

This application relates generally to computer programming and, in an example embodiment, to the representation of semantic layers of source code of a computer program.

BACKGROUND

Many programming languages, such as ABAP® (Advanced Business Application Programming) by SAP AG, Java® by Oracle Corporation, and others, including both object-oriented and non-object-oriented languages, possess the quality of semantic “layers” or levels. For example, in the object-oriented quality of inheritance, a derived class may inherit and redefine certain behaviors and attributes from a superclass. In such cases, the derived class and its related superclass may be considered as occupying separate semantic layers in the same computer program. In ABAP, enhancement sections are code sections or modules that replace code sections or modules of original source code. Thus, an enhancement section may be viewed as representing a different semantic layer from the code that it replaces. Many other examples of varying semantic layers in a computer program, such as code stubs, proxies, and façades, exist. Further, such semantic layers may be represented in commands, data structures, code modules, data patterns, and other constructs employed in source code. Generally, a programmer's knowledge and understanding of the various semantic layers exhibited by the source code of a particular computer program aid in the programmer's overall understanding of the program during program development, testing, and debugging.

DETAILED DESCRIPTION

FIG. 1is a block diagram of an example computer system100providing an integrated development environment (IDE)102in which methods of displaying two or more semantic layers of source code may be performed. The IDE102may allow a programmer or other user to develop, execute, test, and debug source code for use as a computer program or application. In the example ofFIG. 1, the IDE102may include a source code editor110, a compiler/interpreter112, a linker/loader114, and a monitor/debugger116. In some implementations, other modules or applications may be included in the IDE102, while some modules shown inFIG. 1may be omitted in other embodiments. In one implementation, a user may access the IDE102directly via a user interface of the computer system100. As a result, the computer system100may be, for example, a desktop computer, a laptop computer, a tablet computer, or the like. In another example, the computer system100may be a server system which the user may access over a communication network, such as a wide area network (WAN) or a local area network (LAN), via a client device, such as a desktop, laptop, or tablet computer, or a mobile communication device, such as a smartphone, personal digital assistant (PDA), or the like.

The source code editor110ofFIG. 1may allow a user to write and edit source code, resulting in one or more source code files130being generated for a program or application. The source code editor110may aid the user in programming in one or more programming languages, such as ABAP®, Java®, C++, or other compiled or interpreted languages. The source code editor110may also provide additional programming support, such as recognitions of language-specific keywords or operators, syntax-checking, and so on.

A compiler/interpreter112may compile or interpret the source code files130, possibly in addition to other preexisting source code files130, to generate one or more object code files132that are in a format that is understandable by the computer system100or another physical or virtual computer system or machine. A linker/loader114may receive the object code files132as input to generate an executable file134for the program or application, which is in a form to be executed directly by the computer system100or another system or machine. A user may then employ the monitor/debugger116to test the resulting executable file134, debug any problems encountered, and make changes to one or more of the source code files130via the source code editor110. The edited source code files130may then be compiled, linked, loaded, executed, and the like as described above to retest the resulting executable file134. Further, the user may employ this process using the IDE102in an iterative manner until the executable file134operates as desired.

In some examples, at least one of the source code editor110and the monitor/debugger116of the IDE102may employ one or more aspects of the display of semantic layers of the source code files130, as described in greater detail below. In other implementations, any other type of application that displays source code to a user, such as a source code editor not provided as part of an IDE, may implement one or more aspects of semantic layer display described hereinafter.

FIG. 2is a flow diagram illustrating an example method200of displaying semantic layers of source code. While at least some of the operations of the method200and other methods described herein may be performed in the computer system100ofFIG. 1, other devices or systems may be employed to perform the method200in other embodiments.

In the method200, source code of a computer program, such as source code from one of the source code files130ofFIG. 1, may be displayed in a first display area (operation202), such as by way of a computer monitor or other display device. A user selection of a first portion of the source code corresponding to a first semantic layer is received (operation204). A user command referring to a second portion of the source code related to the first portion and corresponding to a second semantic layer is also received (operation206). In response to the user command, a second display area for the second portion may be displayed (operation208). The second display area may indicate a relationship between the first and second portions of the source code, and may also indicate a difference in the semantic layers between the first and second portions.

In one example, the second display area may include the second portion of the source code at the time the second display is presented to a user. In such an example, an editor, debugger, or other application or module providing the display may generate and/or access previously generated data that indicates how different portions of the source code are related to each other in a semantic context, such as which portions of code serve as code stubs for other portions. In the system ofFIG. 2, such information may be generated by the source code editor110, the compiler/interpreter112, the linker/loader114, the monitor/debugger116, or another module or system. In another implementation, the second display area may present to a programmer an area into which new code for the second portion may be entered.

As discussed further below, portions of source code may be identified or associated with separate semantic levels or “layers.” More specifically, one portion of source code may be logically related to another portion of source code according to some hierarchy or order, in which the source code of one semantic layer may be logically viewed as being related to source code of a higher or lower semantic layer. As mentioned above, derived classes of object-oriented source code may be viewed as residing within a higher semantic layer relative to its base class or superclass. Similarly, ABAP® enhancement code sections that replace other code sections may be viewed as belonging to a higher semantic layer of the source code than the code sections they replace. These and other code constructs that involve more than one semantic layer are described below. Further, other code constructs not specifically described or mentioned herein, which may involve commands, data structures, code modules, data patterns, code patterns, and the like, may also represent one or more semantic layers capable of being displayed using aspects of the various embodiments presented herein.

While the operations202through208of the method200ofFIG. 2are shown in a specific order, other orders of operation, including possibly concurrent or continual execution of at least portions of one or more operations, may be possible in some implementations of method200, as well as other methods discussed herein. For example, the display of the source code in a first display area (operation202) may overlap any or all of the receiving of the user selection (operation204), the receiving of the user command (operation206), and the displaying of the second display area (operation208) in some embodiments.

FIGS. 3A through 3Eare a series of example displays of source code exemplifying an example method of displaying semantic layers within the source code. In one example, the displays are provided via a user interface for an editor, monitor/debugger, or other application or module capable of displaying source code, such as what may be provided in an IDE. InFIG. 3A, a section of source code300is displayed to a user, such as via a computer monitor, touchscreen, or other display device or component. In this particular example, the source code is written in the ABAP® language, although source code written in any other programming language may benefit from application of the various aspects of the embodiments described herein.

InFIG. 3B, a user selection of a first portion302of the source code300is received. In one example, a user may highlight the first portion302using a pointer device, such as a mouse, touchpad, touchscreen, or similar device to select a block of text as the first portion302of the source code300. In another example, the user may employ one or more keys of a keyboard, such as directional keys, a “shift” key, an “enter” key, and the like, to select the first portion302of the source code300. As shown, the first portion302is a contiguous block of the source code, although other implementations may not be limited in such a manner. Also, while the entire first portion302may be seen in the display ofFIG. 3B, only a part of the first portion302may be visible to the user at any one time if a large number of lines of the source code300have been selected as the first portion302. In one example, the area of the display in which first portion302is located may be considered a first display area304.

FIG. 3Cdepicts the selection of a user command306referring to a second portion of the source code300. In this specific example, the user has accessed a drop-down menu305, such as by way of a right-button mouse click on the selected first portion302of the source code300, to access the command (e.g., “Create Code Stub”), such as by way of a left-button mouse click to create a code stub (e.g., a second portion of the source code) for the first portion302. Other methods of accessing such commands, including drop-down menus from a menu bar associated with a source code editor, manual text entry of the command, and so on, may be utilized in other examples. In this particular example, the command306facilitates the creation of a code stub to be entered by the user to operate in place of the first portion302of the source code300. For example, if the first portion302has not been tested sufficiently to provide some level of confidence in its operation, the code stub may perform a much simpler operation to return data ordinarily expected from the first portion302so that other portions of the source code300may be tested effectively.

As shown inFIG. 3D, a second display area310associated with the first display area304is presented in response to the command306. In this implementation, the second display area310is located atop the first display area304, thus covering at least some of the first portion302of the source code300, thus providing a three-dimensional representation of the second display area310and the first display area304. In one example, the second display area310includes a title bar312, which may include a default title (e.g., “TEST-STUB 1”) that the user may update with a customized title. At the time of the presentation of the second display area310, the second display area310provides a blank text entry area within which the user may type source code to be employed as a code stub for the first portion302of the source code300.

FIG. 3Edepicts a display in which the user has begun typing a second portion314of the source code300within the second display area310to serve as a code stub for the first portion302of the first display area304. Thus, the second portion314represents a second, higher semantic level of the source code300relative to the first, lower semantic level of the first portion302, as the first portion302is, in effect, hidden or blocked from operating via the second portion314of the source code300. In this example, the relationship of the first portion302to the second portion314is indicated by way of the overlap of the first display area304by the second display area310in a three-dimensional fashion. However, other ways of denoting the relationship graphically or visually exist, either by way of two-dimensional or three-dimensional visual effects.

In addition to code stubs, aspects of the implementation ofFIGS. 3A through 3Emay also be applied to similar semantic layer structures, such as mock objects and code injections. A mock object, for example, is an object that can simulate the behavior of one or more other, more complex objects to facilitate the testing of yet one or more other objects of the source code. As a result, a mock object may represent a higher semantic layer of source code compared to the semantic layer of the complex object being simulated.

In another example, a beneficial code injection is the injection or insertion of source code into a separate location within the source code to facilitate additional or different functionality than what would be available in the absence of the injected code. Such a code injection is distinguished from a malicious code injection, in which code is injected into a system from an external source to cause a malicious effect, such as modifying a database to compromise the data within, to extract confidential information in an unauthorized manner, or to initiate some other malevolent action. With a beneficial code injection, the portion code being injected may be considered to reside at a higher semantic level than the portion of code surrounding the injection site. Accordingly, implementations described above and below may be applied to both code injections and mock objects to enhance the understanding of a user or programmer of the overall structure of the source code.

In the example ofFIG. 3E, each of the first display area304and the second display area310is surrounded by a border or similar graphical boundary. However, either or both of the first display area304and the second display area310may be designated via other means, such as, for example, by rendering the first portion302and/or the second portion314of the source code300in bold, underlined, or italicized characters; by using text of one or more colors; by providing backgrounds of different colors; or via other means.

As shown inFIGS. 3D and 3E, and as mentioned above, a three-dimensional graphic distinguishes the first semantic layer of the first portion302from the second, higher semantic layer of the second portion314of the source code300.FIGS. 4A and 4Bdescribe another example in which semantic layers are distinguished via a two-dimensional graphical scheme. More specifically,FIG. 4Ais an example display of a first portion400of source code that represents a first semantic layer. In one example, the first portion400may be selected from a larger part of the source code, as described above in conjunction withFIG. 3B.

FIG. 4Bis an example display of the first portion400of the source code ofFIG. 4Athat includes a second display area406for a second portion of the source code representing a second semantic layer related to the first portion400according to a two-dimensional arrangement. More specifically, a user command may be received that refers to the second portion of the source code at the second semantic layer that is to be generated, with the second portion being related to the first portion400representing a first semantic layer of the source code. In response to the command, the second display area406is generated, which surrounds a first display area402that includes the first portion400of the source code in a two-dimensional graphical arrangement that allows the user to view the code of both the first display area402and the second display area406simultaneously. The second display area406provides an area in which the user may enter the second portion of the source code, such as, for example, replacement code for the first portion400. Accordingly, the replacement code represents a second, higher semantic layer that is to replace the original code of the first portion400. In this specific example, the second display area406surrounding the first display area402signifies that the second portion of the source code is related to the first portion, and also resides at a higher semantic layer than the first portion400. As also shown inFIG. 4B, the first display area402includes a first display title area404while the second display area406includes a second display title area408, into each of which the user may enter a customized title for each of the first portion400and the second portion, respectively.

FIGS. 5A through 5Care a series of example displays of the first portion400and second portion referred to inFIG. 4Bthat include associated collapse/expand controls. As shown inFIG. 4B, the first display area402and the second display area406are shown relative to each other in a two-dimensional arrangement inFIG. 5A. Additionally, the first display area402includes a first collapse control502, and the second display area406includes a second collapse control504, thus allowing the user to collapse either or both of the display areas402,406independently, thus hiding the code associated with the collapsed display area402,406. In response to the user activating the first collapse control502, the first display area402is collapsed, or reduced in size, resulting in the display depicted inFIG. 5B. In addition, the first collapse control502is converted to a first expand control506to allow the user to expand the first display area402to its original configuration. If the user then activates the second collapse control504, the display ofFIG. 5Cmay result, in which both the second display area406is collapsed, and the second collapse control504is replaced with a second expand control508to allow the user to expand the second display area406to its original configuration.

As shown in the display ofFIG. 5C, the second display area406, when collapsed, completely hides the first display area402. In one example, the first display area402may be hidden under such circumstances regardless of whether the first display area402is in a collapsed or expanded state.

FIGS. 6A and 6Bexpand upon the example ofFIG. 4Bby allowing the first display area402to be moved or relocated within the second display area406. As shown inFIG. 6A, the user has entered a second portion600of the source code, with the second portion600serving as a second, higher semantic layer relative to the first semantic layer of the first portion400. The user may then decide to relocate the first display area402within the second display area406. In one example, the user may use a cursor to “grab” the first display area402and move it toward the upper end of the second display area406, as is shown inFIG. 6B. In response, individual lines of the second portion600of the source code may be relocated from above the first display area402to below the first display area402to accommodate the new location of the first display area402. In one example, the user may employ such functionality so that the location of the first display area402is positioned in a more logical location within the second portion600of the source code illustrated in the second display area406.

In contrast to the two-dimensional examples ofFIGS. 4B,5A,5B,5C,6A, and6B,FIG. 7is an example display of source code representing separate semantic layers in a three-dimensional arrangement. In this example, an enhancement section (“Enhancement Imp. XY”)700in a second display area706representing the higher semantic layer at least partially covers or obscures a first display area702of the lower semantic layer. In this example, the second display area706is opaque in appearance, resulting in none of the first portion of the source code in the first display area702remaining visible to the user. In other examples, the second display area706may appear translucent or transparent, thus allowing at least some portion of the first display area702to remain visible to the user.

In another three-dimensional arrangement,FIG. 8is an example display of source code depicting nested sections of source code representing separate semantic layers. In this example, a first display area810of a first portion800of source code is surrounded by a second display area812of a second portion802serving as enhancement code for the first portion800. Further, the first display area810appears at a lower graphical level from the point of view of the user compared to the raised second display area812, thus indicating graphically that the first portion800of source code resides at a lower semantic layer than that of the second portion802.

Additionally, the first portion800constitutes part of a larger third portion801of the source code. Accordingly, the first display area810, as well as the second display area812, is surrounded by a third display area814for the third portion801. As with the first display area810, the third display area814is shown at the lower graphical level to indicate that the first portion800and the third portion801reside at the same semantic level. Further, the third display area814, and thus the first display area810and the second display area812, are surrounded by a fourth display area816that includes a fourth portion806of source code serving as enhancement code for the third portion801. Also, the fourth portion806is portrayed as residing in the second semantic layer with the second portion802. In one example, the second display area812and the fourth display area816are identically labeled (“Enhancement Imp. XY”), possibly indicating that their associated code portions802,806are to be implemented together in code versions in which the enhancement section is to be incorporated in the source code.

FIGS. 9,10, and11are example two-dimensional displays that distinguish code of different semantic layers under three separate scenarios. For instance,FIG. 9is an example display of source code representing separate semantic layers involving a redefined object-oriented method and its redefinition. In this example, a first display area902includes a first portion900of source code for a method that is being redefined. In other words, the first portion900represents a method of a base class or superclass. A second display area906that surrounds the first display area902includes a second portion910of code that specifies a method of a subclass that redefines or overrides the method of the redefined class. In one example, the display ofFIG. 9may be generated by way of a user selecting the redefined method in the first portion900in the source code and requesting a redefinition of the method, if available. In another example, the second display area906may be opened to allow the user to enter the second portion910of the source code in response to a selection of the first portion900and a command to create a redefinition of the selected first portion900. In yet another implementation, the display ofFIG. 9may be provided in response to the user selecting the redefinition in the source code and requesting display of a corresponding method being redefined.

FIG. 10is an example display of source code representing separate semantic layers involving a façade class and its related subclasses. Generally, a façade class in object-oriented programming provides a simplified interface to one or more other classes, or to a class library. In the example ofFIG. 10, a CPU class is displayed as a first portion1012of source code in a first display area1002, a Memory class is displayed as a second portion of source code in a second display area1004, and a HardDrive class is displayed as a third portion of source code in a third display area1006. As shown, each of the first display area1002, the second display area1004, and the third display area1006is collapsible or expandable, as described above in conjunction withFIGS. 5A,5B, and5C. In the display ofFIG. 10, the first display area1002is in an expanded state, while the second display area1004and the third display area1006are in a collapsed state.

Also shown inFIG. 10is a fourth display area1000with a fourth portion1010of the source code that is a class called Computer, which serves as a façade class for the CPU, Memory, and HardDrive classes shown. As a result, the façade class of the fourth display area1000represents a higher semantic layer than the semantic layer associated with the CPU, Memory, and HardDrive subclasses. In one example, the user may select each of the CPU, Memory, and HardDrive subclasses in the source code, and select a command to generate a façade for those classes. In response, the fourth display area1000may be presented as surrounding the three selected subclasses, with the fourth display area1000providing a region in which the user may write the source code for the related façade class. In other examples in which the façade code has already been written, the user may select one of the three subclasses and select a command to display any façade classes related thereto. Oppositely, the user may select a façade class and issue a command requesting display of each subclass for which the selected class operates as a façade.

More generally, the implementation ofFIG. 10may be applied to many different types of façades and proxies often employed in source code. Generally, a façade, including the façade class described above, simplifies the interface to an underlying software object, class, data structure, or other construct. Similarly, a proxy, as employed within object-oriented source code, is a class that functions as an interface to a software resource that is difficult to duplicate, such as a large memory object, a file, or a network connection. Thus, as both façades and proxies may represent higher semantic layers relative to the constructs for which they serve as interfaces, these software patterns, as well as the underlying source code for which they provide an interface, may be displayed according to the various implementations described herein.

FIG. 11is an example display of source code representing separate semantic layers related to shadowed variables. Generally, a shadowed variable is a variable within a particular limited scope of the source code, such as an inner class, method, or code block, that possesses the same name as another variable declared outside the limited scope associated with the shadowed variable. Consequently, the shadowed variables may be viewed as representing a lower semantic level compared to that of the identically-named variables of the outer scope.

In the example ofFIG. 11, a first portion1106of source code in a first display area1104is a declaration of a variable (labeled “x”) that is being shadowed, while a second display area1100includes a second portion1102of the source code that includes the variable of the outer scope that shadows the shadowed variable. In one implementation, a user may select a particular scope of the source code, such as a particular class or method, as the second portion1102in the second display area1100, and then initiate a command to display any variables that are shadowed within that scope as the first portion1106via a first display area1104. In another example, the user may select one or more variables that may be shadowed as the first portion1106of the first display area1104and initiate a command to show variables that shadow any variables of the first portion1106as the second portion1102of the source code in the second display area1100.

While each of the examples discussed above involve two semantic layers, other implementations of the embodiments discussed herein may involve three or more semantic layers without limitation. Further, while several different types of semantic layers have been discussed herein, the embodiments described above may also be applied to other types of source code semantic layers not specifically addressed herein. Also, each example that employs a two-dimensional graphical arrangement may employ a three-dimensional representation in alternate embodiments, and vice-versa. Further, aspects of any example described herein may be combined with one or more aspects of other examples to generate additional embodiments.

According to at least some embodiments described herein, a code editor, monitor, debugger, or other application presenting source code to a user may include the display of related multiple sections of source code corresponding to different semantic layers to increase the comprehension or understanding of a programmer, tester, or other user regarding the code. The display may relate which portions of code are related to each other, as well as their semantic relationship to each other. In some examples, the application may also facilitate the generation by the user of a particular type of code for a portion of preexisting code, such as the addition of a code stub, a façade class, and the like, as explained above.

FIG. 12depicts a block diagram of a machine in the example form of a processing system1200within which may be executed a set of instructions1224for causing the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

The machine is capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example of the processing system1200includes a processor1202(e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory1204(e.g., random access memory), and static memory1206(e.g., static random-access memory), which communicate with each other via bus1208. The processing system1200may further include video display unit1210(e.g., a plasma display, a liquid crystal display (LCD), or a cathode ray tube (CRT)). The processing system1200also includes an alphanumeric input device1212(e.g., a keyboard), a user interface (UI) navigation device1214(e.g., a mouse), a disk drive unit1216, a signal generation device1218(e.g., a speaker), and a network interface device1220.

The disk drive unit1216(a type of non-volatile memory storage) includes a machine-readable medium1222on which is stored one or more sets of data structures and instructions1224(e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The data structures and instructions1224may also reside, completely or at least partially, within the main memory1204, the static memory1206, and/or within the processor1202during execution thereof by processing system1200, with the main memory1204and processor1202also constituting machine-readable, tangible media.

The data structures and instructions1224may further be transmitted or received over a computer network1250via network interface device1220utilizing any one of a number of well-known transfer protocols (e.g., HyperText Transfer Protocol (HTTP)).

In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may include dedicated circuitry or logic that is permanently configured (for example, as a special-purpose processor, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuitry (for example, as encompassed within a general-purpose processor1202or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (for example, configured by software) may be driven by cost and time considerations.

Modules can provide information to, and receive information from, other modules. For example, the described modules may be regarded as being communicatively coupled. Where multiples of such hardware modules exist contemporaneously, communications may be achieved through signal transmissions (such as, for example, over appropriate circuits and buses) that connect the modules. In embodiments in which multiple modules are configured or instantiated at different times, communications between such modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple modules have access. For example, one module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further module may then, at a later time, access the memory device to retrieve and process the stored output. Modules may also initiate communications with input or output devices, and can operate on a resource (for example, a collection of information).

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors1202or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors1202, not only residing within a single machine but deployed across a number of machines. In some example embodiments, the processors1202may be located in a single location (e.g., within a home environment, within an office environment, or as a server farm), while in other embodiments, the processors1202may be distributed across a number of locations.

While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of claims provided below is not limited to the embodiments described herein. In general, the techniques described herein may be implemented with facilities consistent with any hardware system or hardware systems defined herein. Many variations, modifications, additions, and improvements are possible.