Computer-implemented method for generating a UML representation from JAVA source code

[0002] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

[0003] This application relates to the following co-pending application, assigned to the same assignee hereof, which is incorporated herein by reference.

[0004] U.S. Ser. No. 09/676,289, entitled A METHOD FOR SYNCHRONIZING JAVA WITH UML IN A VERSION CONFIGURATION MANAGEMENT SYSTEM;

[0005] U.S. Ser. No. 09/676,288, entitled A COMPUTER-IMPLEMENTED METHOD FOR GENERATING JAVA USING FROM A UML REPRESENTATION; and,

[0006] U.S. Ser. No. 09/676,284 entitled A METHOD FOR SYNCHRONIZING UML WITH JAVA IN A VERSION CONFIGURATION MANAGEMENT SYSTEM.

[0007] The present invention generally relates to software programming and in particular to a method for representing JAVA with the use of UML compliant tools.

[0008] UML is a diagrammatic language and by using any modeling tool that supports UML, UML models can be visually represented to a user. UML enables users to see what a particular program looks like in model form.

[0009] JAVA, on the other hand, is not diagrammatic. A JAVA programmer's view is limited to the JAVA code and program output. The user must create a separate UML model in order to obtain a visual representation of the JAVA code.

[0010] Accordingly, there is a need to translate and represent JAVA code in UML. This would allow JAVA programmers to diagram JAVA code without having to create a separate model. The translation and generation should be made possible at the class, package, and project levels.

[0011] There is also a need to generate JAVA code from UML. This would allow models existing within UML to be transformed into a JAVA implementation that is ready for compiling.

[0012] A parser and generator sit on top of a server within an object-oriented repository, such as UREP, which is available from the assignee hereof. The program imports code within a JAVA project to the server.

[0013] The program parses the Java code for each JAVA source file within a JAVA project. This is done by parsing class names, class attributes, field names, and other information from JAVA source files.

[0014] The parsed information is then mapped to UML constructs and stored in an extensible Markup Language Metadata Interchange (XMI) file. An XMI file is a representation of the UML. Using the XMI file, Rational Rose can display the UML representation of the JAVA classes, allowing users to see a visual model of the JAVA code.

[0015] When translating from JAVA to UML, parsing can occur at the project, package, and class levels. A source file is the base JAVA file. Classes can be logically grouped to form packages, and packages can be grouped to form Java projects.

[0016] A feature of the present invention resides in the ability to parse JAVA and generate UML in a distributed environment without being limited by an IDE implementation.

[0017] Still another feature of the present invention is the ability to transform JAVA with finer granularity by parsing JAVA at the class, package, and project level and generating UML representation of class, package, and project.

[0018] Another feature of the present invention is the ability to support any IDE from JAVA that supports Source Code Control (SCC) API.

[0019] A still further feature of the present invention is the ability to support XMI.

[0020] These and other objects, which will become apparent as the invention is described in detail below, are provided by a computer-implemented method for representing JAVA in UML in a computer system executing a repository program. The method comprises the steps of determining if a file is a JAVA package or project. If it is, then determining if there is a JAVA subpackage not represented in UML, and if so; recursively creating UML subpackages representing each nested JAVA subpackage. If it is determined that the file is not a JAVA package or project, then the method creates UML files representing each JAVA source file.

[0021] Still other objects, features and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only the preferred embodiment of the invention, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive, and what is intended to be protected by Letters Patent is set forth in the appended claims. The present invention will become apparent when taken in conjunction with the following description and attached drawings, wherein like characters indicate like parts, and which drawings form a part of this application.

[0022] FIG. 1 is a block diagram of a system that may execute the method of the present invention.

[0023] FIG. 2 is a diagram illustrating the path taken by the method of the present invention in representing JAVA in UML.

[0024] FIG. 3 is a flow chart of the process for representing JAVA in UML.

[0025] FIG. 4 is a flow chart of the process for representing a JAVA source in UML.

[0026] FIGS. 5A and 5B combined form a flow chart of the process for representing a JAVA class in UML.

[0027] FIGS. 6A and 6B combined form a flow chart of the process for representing a JAVA interface in UML.

[0028] Referring now to the drawings and FIG. 1 in particular, a block diagram of a system that may implement the process of the present invention is shown. Either a single computer 10 or a combination of the computer 10 and a server 11, which is shown coupled to the computer 10 by means of a TCP/IP or proprietary protocol 12, would be satisfactory for executing the process of the present invention. In the illustrated embodiment shown in FIG. 1, the computer 10 would typically be executing a variety of software 13, including a modeling tool, Unisys Integrated Component Framework (ICF) and JAVA development software. The server 11 in the illustrated embodiment is a server, which is capable of executing the NT operating system available from Microsoft Corporation of Redmond, Wash. The server 11 also executes a variety of software programs 14, including ICF, which is a framework that integrates third-party tools to provide full life-cycle model to deployment operation and management of components and a repository program 14A.

[0029] The repository 14A NOTE: WHERE IS 14A? further includes tools for cataloging, browsing, and managing components that make up an application. Methods to support these services are disclosed in several patents and patent applications assigned to the assignee of this application, including U.S. Pat. No. 5,671,398 for METHOD FOR COLLAPSING A VERSION TREE WHICH DEPICTS A HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE; U.S. Pat. No. 5,644,764 for METHOD FOR SUPPORTING OBJECT MODELING IN A REPOSITORY; U.S. Pat. No. 5,581,755 for METHOD FOR MAINTAINING A HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE; U.S. Pat. No. 5,557,793 for IN AN OBJECT ORIENTED REPOSITORY, A METHOD FOR TREATING A GROUP OF OBJECTS AS A SINGLE OBJECT DURING EXECUTION OF AN OPERATION; U.S. Pat. No. 5,889,992 for A METHOD FOR MAPPING TYPES IN A MODEL IN AN OBJECT-ORIENTED REPOSITORY TO LANGUAGE CONSTRUCTS FOR A C BINDING FOR THE REPOSITORY; U.S. Pat. No. 5,721,925, for METHOD FOR GENERICALLY INVOKING OPERATIONS IN AN OBJECT ORIENTED REPOSITORY; U.S. Pat. No. 5,848,273 for A METHOD FOR GENERATING OLE AUTOMATION AND IDL INTERFACES FROM METADATA INFORMATION; U.S. Pat. No. 5,765,039 for A METHOD FOR PROVIDING OBJECT DATABASE INDEPENDENCE IN A PROGRAM WRITTEN USING THE C++ PROGRAMMING LANGUAGE; U.S. Pat. No. 5,758,348, for A METHOD FOR GENERICALLY MANIPULATING PROPERTIES OF OBJECTS IN AN OBJECT ORIENTED REPOSITORY; U.S. Pat. No. 5,701,472, for A METHOD FOR LOCATING A VERSIONED OBJECT WITHIN A VERSION TREE DEPICTING A HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE; and U.S. Pat. No. 6,105,073, for A METHOD FOR PACKING/UNPACKING C OPERATIONS TO/FROM RPC COMPATIBLE FORMAT USING THE RPC PROTOCOL TO OPERATE REMOTELY WITH AN OBJECT-ORIENTED REPOSITORY, each of which are hereby incorporated by reference as if set forth in full herein.

[0030] The XMI protocol is further described in co-pending applications Ser. No. 09/282,345, filed Mar. 31, 1999, for A METHOD AND SYSTEM FOR GENERATING A SIMPLE DOCUMENT TYPE DEFINITION FOR DATA INTERCHANGE AMONG SOFTWARE TOOLS; Ser. No. 09/282,102, filed Mar. 31, 1999, for A METHOD AND SYSTEM FOR GENERATING A COMPACT DOCUMENT TYPE DEFINITION FOR DATA INTERCHANGE AMONG SOFTWARE TOOLS; Ser. No. 09/282,230, filed Mar. 31, 1999 for A METHOD AND SYSTEM FOR GENERATING A HIERARCHIAL DOCUMENT TYPE DEFINITION FOR DATA INTERCHANGE AMONG SOFTWARE TOOLS; Ser. No. 09/345,289, filed Jun. 30, 1999, for A METADATA DRIVEN SYSTEM AND METHOD FOR EFFECTING DATA INTERCHANGE AMONG SOFTWARE TOOLS IN A DISTRIBUTED ENVIRONMENT; Ser. No. 09/345,290, filed Jun. 30, 1999, for METHOD FOR IDENTIFYING UML OBJECTS IN A REPOSITORY WITH OBJECTS IN XML CONTENT; Ser. No. 09/322,137, filed May 28, 1999, for A SYSTEM AND METHOD FOR CONVERTING FROM ONE MODELING LANGUAGE TO ANOTHER; Ser. No. 09/345,291, filed Jun. 30, 1999, for A METHOD FOR VERSIONING A UML MODEL IN A REPOSITORY IN ACCORDANCE WITH AN UPDATED XML REPRESENTATION OF THE UML MODEL.

[0031] The function and operation of the present invention may be more fully appreciated with reference to FIG. 2, which is a diagram illustrating the path taken by the method of the present invention in representing JAVA in UML. A primary objective of this invention, as stated above, is to represent JAVA using UML, since JAVA is not a diagrammatic language like UML. In the diagram of FIG. 2, a JAVA source code 20 is translated into a UML representation 21 by use of the method of the present invention being executed by the server 11. The transformation from JAVA 20 to a UML representation 21 is shown in FIG. 3.

[0032] Referring now to FIG. 3, a flow chart illustrates the process for representing a JAVA source code in UML. The process begins with a start bubble 30, followed by an inquiry as to whether or not the file under examination is a package or a project (diamond 31). If the answer to this inquiry is yes, then another inquiry is made as to whether or not there is a JAVA sub-package not represented in UML (diamond 32). If the answer to this inquiry is yes, then UML sub-packages representing each nested sub-package are created recursively (block 33). If the answer to the inquiry depicted by either the diamond 31 or 32 is no, then UML files representing each JAVA source file are created (block 34). This part of the process is illustrated in greater detail in FIG. 4.

[0033] Referring now to FIG. 4 a flow chart illustrates the process for representing a JAVA file in UML. The process begins with a start bubble 40 followed by a step of parsing the JAVA source code to be represented in UML (block 41). Next, the JAVA constructs are discovered (block 42) followed by a step of storing the JAVA constructs discovered in memory structures (block 43). After this, a UML package representing the JAVA package statement is created (block 44), and UML packages representing the JAVA import statements are created (block 45).

[0034] Following the above, an inquiry is made as to whether or not there is a JAVA class not represented in UML (diamond 46). If the answer to this inquiry is yes, then a UML class representing the JAVA class is created (block 47) followed by a return back to the diamond 46 for the next class, if any. The step depicted by the block 47 is amplified in greater detail in FIGS. 5A and 5B, and described further hereinbelow. If the answer to this inquiry is no, then another inquiry is made as to whether or not there are is a JAVA interface not represented in UML (diamond 48). If the answer to this inquiry is yes, then a UML interface representing the JAVA interface is created (block 49 followed by a return back to the diamond 48 for the next interface, if any. The step depicted by the block 49 is amplified in greater detail in FIGS. 6A and 6B, and described further hereinbelow.

[0035] Referring now to FIG. 5A, the first of a two-sheet drawing illustrates the process for representing a JAVA class in UML. The process begins with a start bubble 50, followed by an inquiry as to whether or not there is a nested JAVA class not represented in UML (diamond 51). If the answer to this inquiry is yes, then UML classes representing each nested class are recursively created (block 52). On the other hand, if the answer to this inquiry is no, then another inquiry is made as to whether or not there is a non-primitive JAVA data member not represented in UML (diamond 53). If the answer to this inquiry is yes, then a UML association representing the JAVA data member is created (block 54). A return is then made back to the diamond 53 for the next non-primitive JAVA data member, if any. If the answer to the inquiry in the diamond 53 is no, then yet another inquiry is made as to whether or not there is a primitive JAVA data member not represented in UML (diamond 55). If the answer to this inquiry is yes, then a UML attribute representing the JAVA data member is created (block 56) and a return is made back to the diamond 55 for the next primitive JAVA data member, if any. If the answer to this inquiry is no, then a branch is made to FIG. 5B, as denoted by a connector A, for a continuation of the flow chart illustration.

[0036] Referring now to FIG. 5B at the connector A, still another inquiry is made as to whether or not there is a JAVA method not represented in UML (diamond 57). If the answer to this inquiry is yes, then a UML method representing the JAVA method is created (block 58). Next, a UML operation representing the JAVA method is created (block 59). After this, an inquiry is made as to whether or not there is a JAVA parameter or return type for the JAVA method not represented in UML (diamond 60). If the answer to this inquiry is yes, then a UML parameter representing the JAVA parameter or return type is created (block 61) followed by a return back to the diamond 60 for the next JAVA parameter/return type, if any. On the other hand, if the answer to the inquiry depicted by the diamond 60 is no, then a return is made back to the diamond 57 for the next JAVA method, if any. If the answer to the inquiry depicted by the diamond 57 is no, then the process ends.

[0037] Referring now to FIG. 6A, the process for representing a JAVA interface in UML is shown. The process begins with a start bubble 65, followed by an inquiry as to whether or not there is a non-primitive JAVA data member not represented in UML (diamond 66). If the answer to this inquiry is yes, then a UML association representing the JAVA data member is created (block 67). A return is then made back to the diamond 66 for the next non-primitive JAVA data member, if any. If the answer to this inquiry is no, then another inquiry is made as to whether or not there is a primitive JAVA data member not represented in UML (diamond 68). If the answer to this inquiry is yes, then a UML attribute representing the JAVA data member is created (block 69). A return is then made back to the diamond 68 for the next primitive JAVA data member, if any.

[0038] If the answer to the inquiry depicted by the diamond 68 is no, then yet another inquiry is made as to whether or not there is a JAVA method not represented in UML (diamond 70). If the answer to this inquiry is yes, then a UML method representing the JAVA method is created (block 71) followed by a step of creating a UML operation representing the JAVA method (block 72). If the answer to the inquiry depicted by the diamond 70 is no, then the process ends. On the other hand, after completion of the step depicted by the block 72 the process illustration continues in FIG. 6B as denoted by a connector B.

[0039] Referring now to FIG. 6B at the connector B, an inquiry is made as to whether or not there is a JAVA parameter or return type not represented in UML (diamond 73). If the answer to this inquiry is yes, then a UML parameter representing the JAVA parameter or return type is created (block 74). A return is then made back to the diamond 73 for the next JAVA parameter/return type, if any. On the other hand, if the answer to this inquiry is no, then a return is made back to connector C (FIG. 6A) for the next JAVA method not represented in UML.

[0040] The methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMS, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The methods and apparatus of the present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

[0041] Although the invention has been described with reference to a specific embodiment, this description is not meant to be construed in a limiting sense. Various modifications of the disclosed embodiment as well as alternative embodiments of the invention will become apparent to one skilled in the art upon reference to the description of the invention. It is therefore contemplated that the appended claims will cover any such modifications of embodiments that fall within the true scope of the invention.