WO2003017105A2 - Procede de representation de l'architecture d'un systeme logiciel - Google Patents

Procede de representation de l'architecture d'un systeme logiciel Download PDF

Info

Publication number
WO2003017105A2
WO2003017105A2 PCT/EP2002/008503 EP0208503W WO03017105A2 WO 2003017105 A2 WO2003017105 A2 WO 2003017105A2 EP 0208503 W EP0208503 W EP 0208503W WO 03017105 A2 WO03017105 A2 WO 03017105A2
Authority
WO
WIPO (PCT)
Prior art keywords
displayed
view
window
software system
structural elements
Prior art date
Application number
PCT/EP2002/008503
Other languages
German (de)
English (en)
Other versions
WO2003017105A3 (fr
Inventor
Thomas Kohler
Roland Trauter
Original Assignee
Daimlerchrysler Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Daimlerchrysler Ag filed Critical Daimlerchrysler Ag
Publication of WO2003017105A2 publication Critical patent/WO2003017105A2/fr
Publication of WO2003017105A3 publication Critical patent/WO2003017105A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/323—Visualisation of programs or trace data

Definitions

  • the invention relates to a method for generating a representation of an architecture of a software system.
  • the source program of the software system in a certain programming language is given, as well as a formal specification of this programming language.
  • the architecture of the software system to be represented describes the structure and processes of the software system through structure elements, through the dependencies, relations and interactions between these structure elements as well as through the properties of the structure elements that are visible from the outside.
  • Structural elements are those elements of the P programming language that are used to define the structure or execution of a program in the P programming language. Structure elements combine definitions of data structures and / or program commands for processing instructions (or statements) in a source program to form different types of blocks.
  • the prior art knows four classes of tools that analyze a software system given as a source program, also with regard to its architecture.
  • Mechanics-based tools automatically derive characteristic values for a given source program and / or a formal specification for the software system, which is given in the form of a model, which provide summary information about the scope and quality of the software. These characteristic values are compared with specified limit values.
  • Testing tools compare a given source program with design rules and programming conventions for the programming language of the source program.
  • the source program is preferably compared with predefined rules. Parts of the source program are found that violate design rules or programming conventions.
  • visualization tools For a given source program, visualization tools generate a coarsened, abstracted model in the form of a graphical representation for the structure or the sequence of the source program.
  • the representation consists, for. B. from UML diagrams.
  • Tools with an interactive display select certain structural elements of the software system from the source program and display them in lists as known from Windows. These lists are also linked, in particular with tools with cross references (or cross referencing tools).
  • a method and a system are presented in US Pat. No. 6,247,020 B1 that support a user in the development of a software system. Is given on files shared source program of a software system in a programming language, e.g. B. Java.
  • the screen is divided into three different windows (or panes).
  • Software system files are displayed in a primary window (or navigation pane).
  • Such a file can be a Java file (or Java file) or a Java package z. B. with classes and interfaces (or Java package) of a certain / class (or class).
  • a hierarchical view shows a section of a family hierarchy (taxonomy) under classes in the primary window.
  • a first secondary window (or content pane) the content, e.g. B. the source text of a previously selected file.
  • the inner structure of the previously selected file is displayed in a second secondary window (or structure pane). If a user selects a "Java file" in the primary window, structural elements contained in the file are listed, for example classes, interfaces, variables and methods.
  • a method which generates a representation of a software system (or computer program) in which a user can navigate interactively.
  • the source program of the software system in a specific programming language, e.g. B. C ++ is given.
  • the software system comprises a collection of structural elements (or components). Several windows (or panes) are created on one screen of a data processing system. An optional tree-shaped or net-shaped representation of the structural elements of the software system is generated and displayed in a primary window (or left pane).
  • This representation includes e.g. B. all classes (or classes), methods of these classes and global variables (or globals). A user selects a structural element shown in the primary window. Information about this structural element is displayed in the secondary windows.
  • US Pat. No. 6,202,199 discloses a system and a method for analyzing the processing of a software system by a data processing system, performing step-by-step tracking (or tracing) and displaying the analysis results.
  • the analysis results are displayed in a primary window and several secondary windows.
  • the primary window (or trace tree pane) shows in a tree-like manner which functions are activated when the software system is being processed and which other functions are activated when a previously selected process (or thread) is executed during execution.
  • Secondary windows display detailed information about a previously selected function.
  • a user selects a function in a selection window (or fil ter tree pane).
  • This selection window consists of four different windows, of which the user selects one using a tab (or tab).
  • the functions are shown in a tree-like manner in these windows according to the files, classes, names or processes to which they belong.
  • a tree-like representation shows z.
  • No. 5,581,797 discloses a device which presents statistical information on a "hierarchy of things" (or hlerarchy of entities), in particular on a large software system, on the screen of a computer.
  • the disclosure teaches how the statistical information is transmitted the hierarchy of things is arranged in a hierarchy of two-dimensional areas on the screen.
  • the setup is limited to statistical information that is presented on a single screen. If a thing A in the hierarchy of things belongs to a thing B, so the area on the screen for thing A is included in the area for information about part B.
  • the dimensions of the area in which information about thing A is presented may depend on statistical characteristics of thing A.
  • US 6,118,447 discloses a system for error detection in software systems, in which a developer defines a set of tasks that the software system has to perform and a set of operating states in which the software system operates, as well as illegal states under these operating states. An end user selects one of the predefined tasks.
  • the system for error detection determines whether the software system would end up in an impermissible operating state due to the processing of the task and issues a warning to the end user and / or the developer. This system is therefore a test tool.
  • US 5,655,074 (corresponds to WO 97/02528) discloses a method for analyzing software systems.
  • the task is to support a software developer in recognizing the greatest risks in a software system.
  • the process consists of the following steps:
  • the components of the software are defined. Attributes are defined for each component and then measured. Use of the software system in the past yields data on performance.
  • a first probability theory distribution over the components is derived from the measurements of the attributes, and a second distribution from the performance data. The two distributions are compared to gain dependencies between the attributes and the performance.
  • a representation of the dependencies between different components of the software system is not generated in US 5,655,074. It is not disclosed how a clear representation of the generated information is generated. In addition, it is not disclosed how the components of the software system are systematically defined and automatically found.
  • WO 00/38051 discloses a method which carries out a method of reverse engineering (or reverse engineering process) for a system.
  • the process consists of the following steps:
  • the generated information is prepared for further processing in a development environment or for a representation for a person.
  • WO 00/38051 does not disclose how the visual representation is generated.
  • Tables with cross references are static tables with columns to show relations between the components of the software system. It is possible that one element is shown in the left column and 500 elements in the right. -
  • the advantages of flexible and dynamic display on a screen of a data processing system are increasingly being used, with modern browsing tools already using lists of graphical user interfaces for this purpose.
  • SNiFF + presents a user with lists and diagrams for structural elements of a given software system using a graphical user interface. Not all relations between structural elements are shown. When the user selects a structural element, SNiFF + shows the source code of these structural elements or offers the possibility to switch to another structural element in relation to the first structural element of another list. However, the connections created in this way are only partially and not systematically available. To close this gap, SniFF + provides search functions that operate directly on the source program and only compare character strings. If two structural elements have the same name, it remains the responsibility of direction of the user to find out which structural element is meant when the name appears in a list or diagram.
  • the invention has for its object to improve a method according to the preamble of claim 1 so that the display, which is to be generated automatically depending on the selection operations of a user, is clear and yet complete with respect to a predetermined criterion.
  • a model or a formal or natural language specification for the software system should not be required.
  • a device and a computer program product for carrying out the method have to be created.
  • the software system is available as a source program in a specific programming language P.
  • the architecture to be displayed includes structural elements and relations among these structural elements.
  • the architecture is automatically determined with the help of a data processing system.
  • the method according to the invention determines how this architecture is represented, e.g. B. on an output unit of the data processing system.
  • each view represents a set of structural elements of the software system, which are selected on the basis of a predetermined criterion, as well as relations of these structural elements to other structural elements of the software system. For this purpose, it is defined which types of structural elements and which types of relations between structural elements are defined in the programming language P. , Only these types of structural elements and relations can occur in the software system, and therefore only these types need to be shown.
  • the criteria for the views are defined depending on the types of structure elements and relations.
  • the representation to be generated comprises at least one view, which is selected from this set of views of the architecture before the representation is generated.
  • the representation to be generated can comprise several selected views or even all views of the set of views (claim 18).
  • the selected view is generated and displayed automatically. This creates a primary window of the view and at least one secondary window of the view.
  • At least one category of structural elements of the software system is selected. The structural elements that belong to at least one selected category are determined. A set of structural elements determined in this way is selected on the basis of a predetermined criterion and displayed in the primary window of the selected view.
  • Information about at least one structure element displayed and selected in the primary window is displayed in at least one secondary window of the selected view. This information includes a number of further structural elements that are in at least one specific relation to the selected structural element.
  • the structural elements are preferably classified by belonging to categories which depend exclusively on the programming language (P). When the method is carried out, it is automatically determined which structural elements of the determined architecture belong to which of these categories. A structural element can belong to several categories. The identification of the categories is an intermediate step in the creation of the views.
  • the solution according to the invention generates complete and systematic representations of information about the structural elements and their relations and thus about the structure of the given software system.
  • the division of the display into views with primary and secondary windows ensures that the generated display is clear.
  • the relatively complex information network of the structural elements and their relations among other is organized and thus made clearer.
  • the fact that a lot of information is only shown in the secondary window for the structure element previously selected in the primary window results in a user-friendly filtering of information.
  • different structural elements with the same name are automatically differentiated. Because different types of structural elements are assigned to several views, the views are also connected to one another via common structural elements. As a result, the architecture of the software system is completely mapped to the views.
  • the set of views can be used to represent the architecture of any software system whose source program is implemented in the P programming language. It is not necessary to redefine views for each software system.
  • the representation is preferably generated as a function of a user's selection operations. A user can make any selection operations among the alternatives offered to him. In this way, different representations of the architecture of the same software system, in particular different views of the architecture, can be generated for different users without the need for adaptation, for example for implementations.
  • the information is obtained from the source program of the software system without the need for a model or a formal specification for the software system.
  • the method according to the invention is therefore also suitable for software systems which are not documented at all or are insufficiently documented.
  • a set of structural elements is preselected according to claim 1 based on a predetermined criterion and displayed in the primary window of the selected view.
  • the preselection is carried out by preselecting all structural elements of at least one category. be chosen.
  • the preselection is carried out by preselecting those structural elements of at least one category that meet a previously defined filter condition.
  • categories include at least one of the following categories (claim 4): a category of the file management units, which comprises the files to which the source program is divided, a category of the data types, this category being the data types of the programming language (P) and the data types, which are defined in the software system, a category of data objects, which includes the variables and constants, a category of translation units, these are the structural elements from which a compiler or interpreter creates library units, a category of subroutines, which includes the functions and procedures , and a category of library units generated from translation units by a compiler or interpreter.
  • a category of the file management units which comprises the files to which the source program is divided
  • a category of the data types this category being the data types of the programming language (P) and the data types, which are defined in the software system
  • a category of data objects which includes the variables and constants
  • a category of translation units these are the structural elements from which a compiler or interpreter creates library units
  • a category of subroutines which includes the functions
  • At least one selected view is generated and displayed from a set of views.
  • This set preferably comprises the following views: a file source code view (claim 5) with at least one secondary window, a data type view (claim 6) with at least three secondary windows, a data object view (claim 7) with at least one secondary window, one Assembly view (claim 11) with at least one secondary window, a call view (claim 13) with at least two secondary windows
  • Structural elements of a certain category are determined. Some of the structural elements determined are preselected based on a criterion. Which this category is depends on which of these views are selected.
  • the source code of the selected file is displayed in a secondary window.
  • those library units that are imported by the selected library unit are displayed in a first secondary window, and those library units from which the selected library unit is imported are displayed in a second secondary window.
  • three secondary windows are generated after selection of the data object view and a variable or constant displayed in the primary window.
  • those library units of the software system are displayed that have write and non-read access to the selected variable or constant.
  • those library units ⁇ of the software system are displayed that have read and non-write access to the selected variable or constant.
  • those library units of the software system are displayed that have both read and write access to the selected variable or constant.
  • the preselected data objects are displayed in ascending or descending order according to their number of uses (claim 9). Depending on the user specification, it is counted how many library units only have write, read and / or write and read access to a variable or constant.
  • the primary window of the data object view is preferably divided into two columns (claim 10). After selecting the data object view, the names of the preselected data objects are displayed in a first column of the primary window (PF_1). The name of the library unit in which the data object is defined is displayed in a second column of the primary window (PF_1) next to a data object.
  • Two secondary windows are preferably generated after selection of the assembly view (claim 12). After selection of a structural element displayed in the primary window, the ones that are defined in the specification of the selected structural element are defined in a first secondary window. In a second secondary window, those structure elements are displayed that are used in the implementation of the selected structure element.
  • the preselected subroutines are displayed in ascending or descending order according to their number of uses.
  • the primary window of the call view comprises two columns. After selecting the call view, the names of the preselected subroutines are displayed in a first column of the primary window. In a second column of the primary window, in addition to the name of a subroutine, the name of the library unit in which the subroutine is defined is displayed.
  • step flow chart is additionally generated and displayed in accordance with claim 17.
  • This step-by-step plan shows which structural elements in which order the execution of the source program can be called and processed.
  • an additional step is carried out.
  • Structure elements are displayed in a secondary window of the selected view, one of these structure elements is selected.
  • Name SE this second selected structural element. From the set of views of the architecture, those are determined in which the structural element SE occurs in the primary window. After selecting at least one of these views, this second view is created and displayed.
  • the structural element SE is shown in the primary window of this second view, preferably highlighted.
  • a number of further structural elements are displayed for the structural element SE, which are in a specific relationship with the structural element SE.
  • An embodiment of claim 19 provides that all views are generated and displayed in which the structural element SE occurs in the primary window. For the selection of one or more of these views, a context menu for the structure element SE is preferably generated, which can be called up by selecting the structure element SE by pressing the right mouse button.
  • claim 19 provides that the method steps of claim 19 are carried out repeatedly in succession. For example, after selecting a second structural element, a second view is selected, generated and displayed. After selecting a third structure element in the primary window of the second view, a number of further structure elements are displayed in a secondary window. A fourth structural element is selected from this set. A third view is then selected, generated and displayed. After selecting a fifth structure element in the primary window of the third view, a second set of further structure elements is displayed in a secondary window of the third view. For this further A sixth structure door element is selected. A fourth view is then selected, generated and displayed. This sequence continues.
  • This configuration in particular supports a user in carrying out targeted navigation through the architecture of the software system.
  • the user has the option of jumping back and forth between different views.
  • Views with lists in primary and secondary windows are created one after the other. These lists are linked to each other by structure elements, which are shown in several windows. According to appropriate user specifications, the relationships shown in different views for one or more structure elements are displayed one after the other or next to one another.
  • the point at which the structure element is defined or used is displayed in the source program of the software system. (Claim 21). First, either a structural element is selected that is displayed in the primary window of the selected view, or a structural element is selected that is displayed in a secondary window of the selected view. The location in the source program is then displayed at which the selected structure element is defined or used.
  • An apparatus for performing the method according to one of claims 1 to 21 comprises according to claim 22
  • This device for generating a representation comprises according to claim 23
  • a device for selecting at least one view from a set of views (S 1, S 2) of the architecture a device for generating and displaying a selected view (S_l), the view comprising exactly one primary window (SE_1) and at least one secondary window (SF_1.1, SF_1.2),
  • FIG. 3 shows the data type view of FIG. 2 with a selection menu for specifying a filter condition and a sorting
  • FIG. 5 shows the data object view of FIG. 4 with a selection menu for defining a filter condition and sorting
  • FIG. 6 shows a construction view of the architecture with two secondary windows
  • 7 shows the structure view of FIG. 4 with a selection menu for defining a filter condition and a sorting
  • FIG. 9 shows the call view of FIG. 8 with a selection menu for defining a filter condition and a sorting
  • FIG. 11 the import-export view of FIG. 10, in which translation units are displayed for a library unit;
  • FIG. 12 shows the import-export view of FIG. 10 with a selection menu for defining a filter condition and a sorting
  • Fig. 13 Pictograms for the different types of structural elements
  • the software system is available as a source program in a specific programming language P.
  • a preferred embodiment of the method according to the invention consists of the following steps: a) A description of the types of structural elements that the programming language P consists of is read or automatically acquired in another way. This description includes a list of the types of structural elements and a description of the possible relationships among structural elements. This description of the types of structural elements is made once for the P programming language. It is valid for every source program that has been implemented in P. Only structural elements of this type can occur in the software system. b) A description of the set of views of the architecture of a software system that has been implemented in the programming language P is read in or otherwise automatically acquired.
  • This description defines which primary window and which secondary window each view has and which categories of structure elements are displayed in which primary and secondary windows after a view has been selected. Furthermore, the description includes a definition of filtering and sorting options for the primary window and a set of relations for the secondary windows of each view. This description of the set of views is created in advance for the structural elements of the P programming language. It is valid for every source program that has been implemented in P. c) The given source program for the software system is read. d) The architecture of the software system is analyzed. In particular, it is determined which structural elements occur in the software system, which types and categories these structural elements are and which relations exist between which structural elements. The description recorded in step a) and the source program read in step c) are used for this.
  • the result of the architecture analysis is stored in a temporary and / or permanent memory.
  • a sequence consisting of steps i) to iv) is carried out at least once: i) The result of the architecture analysis is recorded automatically. ii) User specifications are automatically recorded.
  • Information about the first structure element and / or a set of further structure elements that are in a specific relationship with the first structure element is displayed.
  • step d methods can be used which, for. B. for syntax analysis of a source program (or source code analysis) are known.
  • the expert knows techniques for compiler construction, for. B. from AV Aho, R. Sethi, JD Ullman: “Compilers: Principles, Techniques, and Tools", Addison-Wesley, 1985 or from St. Muchnick: “Advanced Compiler Design and Implementation", Morgan Kaufmann, 1997.
  • These techniques provide an executable program.
  • such a technique is modified so that it provides a description of the structural elements and their relationships.
  • a data structure with a semantic network is preferably generated.
  • the source program of the software system is analyzed and checked for syntactical correctness.
  • Step e) is usually carried out several times for a software system. It is therefore advantageous to save the results of step d) and reuse them.
  • the source program is in the programming language "Ada-95".
  • a formal definition of "ADA-95” is given by "ADA Reference Manual - ISO / IEC 8652” (1995).
  • a program in the programming language P is syntactically correct if and only if it can be derived from a given start character by applying the production rules.
  • Custom names are for ADA-95 e.g. B. from John Barnes.. "Programming in Ada95", Addison-Wesley, 2nd Ed, 1998
  • known blocks in a branch instruction are examples of structural elements without custom names structural elements without custom names to play for to be presented architecture of the software system only. subordinate role, since they cannot be referenced and can therefore only be used at the place of definition.
  • the formal definition of a programming language such as ADA-95 preferably includes a syntax in the form of a hierarchical representation of all elements of the programming language P. From non-terminal characters, other non-terminal characters or terminal characters are derived by so-called production rules with left and right sides. A program in the programming language P is syntactically correct if and only if it can be derived from a given start character by applying the production rules. Different structural elements of the same type can have the same name. They are always clearly identifiable by the scope, that is the context of their definition, or by distinguishing parts of the name.
  • a package (or package) groups data and processing instructions (or states) into a structural element.
  • a function or Function
  • a procedure or procedure
  • a task (or task) allows processes to be processed in parallel.
  • exception handling (or exception) processing instructions for handling errors are compiled.
  • types of structural elements are preferably combined into categories.
  • a type of structure element can belong to several categories. For example, the following categories of structural elements are defined and stored for ADA-95, which are given below with German and English names: the category of the file management units,
  • the category of data objects (or data objects), the category of translation units (or compile units), these are the structural elements from which an ADA-95 compiler uses syntax analysis and translation to generate library units, which are then performed with a main routine be bound to the executable software system, - and the category of library units (or library units) that are generated by an ADA-95 compiler from the aforementioned translation units.
  • the category of the file management units consists of the files (or files) between which the source program of the software system is divided and the file directories (or directories). Files contain source code of the source program. File directories group files in a tree structure.
  • Each data type is a structural element, namely both the data type predefined by ADA-95 (or pre-defined data type) and each user-defined data type (or user-defined) introduced in an ADA-95 source program using the predefined data types data type).
  • the following types of predefined data types are distinguished: Integer (or integer) real number ⁇ or real)
  • Pointer type (or access type), which is a data type for pointers to structure elements, usually to other data types
  • Data structure type (or record type), which is a predefined fixed data structure that is composed of elements of various other data types
  • Variable data structure type (or variant record), that is a predefined variable data structure that is composed of elements of various other data types and whose structure is made variable by differentiations (or discriminators).
  • Discriminants are a type of parameterization in which functions can be used. Derived data types (or derived types), that is a superclass for the user-defined data types, and sub-types (or sub types) are not discussed in more detail.
  • the category of data objects summarizes the following types of structure elements:
  • the category of translation units is divided into three subcategories, namely that of translation unit specifications (or compile unit specifications), that of translation unit implementations (or compile unit bodies) and the category of translation subunits (or compile subunits) , these are outsourced components of translation units that the compiler translates separately.
  • a translation unit In an ADA-95 source program, the specification of a translation unit (or compile unit specification) can be separated from its implementation (or compile unit body).
  • a translation unit specification essentially contains definitions of data types as well as interfaces to functions and procedures.
  • a translation unit implementation contains the definition of variables and constants as well as the processing instructions and thus in particular the use of structural elements. Parts of the implementation can be outsourced to translation subunits (or compile subunits).
  • An ADA-95 compiler generates from a translation unit specification, none or a translation unit implementation and none, one or multiple translation sub-units a library unit (or library unit).
  • Package implementation (or package body)
  • Procedure implementation (or procedure body)
  • the category of translation subunits summarizes the following types of structural elements:
  • Package implementation (or package body)
  • Procedure implementation (or procedure body)
  • Library units are generated by the compiler from translation unit specifications and translation unit implementations as well as translation subunits. Depending on the types of translation units, the following types of structural elements belong to the category of library units:
  • This subcategory includes the following types of structural elements:
  • a subroutine can be a library unit, an exportable subroutine or a local subroutine.
  • Relationships for data types and data objects are:
  • a data type is used in a procedure specification or function specifica tion or task specifica tion to determine the type of a call parameter.
  • a data type is used in a function specification or task specification to determine the type of the return value.
  • a function body, generic function body, procedure body or generic procedure body has read or write access to a variable or constant.
  • a function body, generic function body, procedure. body or generic procedure body calls other functions or procedures and uses variables or constants as call parameters.
  • a package is made up of exactly one package specification and no or exactly one package body, as well as none, one or more compile subunits.
  • a procedure arises from exactly one procedure specification and exactly one procedure body and from none, one or more compile subunits.
  • a function arises from exactly one function specification and exactly one function body and from none, one or more compile subunits.
  • a generic package is made up of exactly one generic package specification and no or exactly one generic package body and none, one or more compile subunits.
  • a generic procedure arises from exactly one generic procedure specification and exactly one generic procedure body and from none, one or more compile subunits.
  • a generic function arises from exactly one generic function specification and exactly one generic function body as well as from none, one or more compile subunits.
  • a package instance is created from exactly one generic package. Conversely, no, one or any number of package instances are generated from a generic package.
  • a procedure instance arises from exactly one generic procedure. Conversely, no, one or any number of package instances are generated from a generic procedure.
  • a function instance arises from exactly one greneric function. Conversely, no, one or any number of function instances are generated from a generic function.
  • the name of a library unit is the same as that of the translation unit from which the library unit is generated.
  • a translation unit specification and the associated translation unit implementation have the same name.
  • a translation unit A imports a library unit B. Both a translation unit specification and a translation unit implementation as well as a translation subunit can import a complete library unit. Conversely, a library unit B is exported to a translation unit A.
  • a translation unit imports none, one or more library units.
  • a library unit A imports a library unit B directly if a translation unit C imports the library unit B and the library unit A is generated using the translation unit C.
  • a library unit B is exported directly to a library unit A if B is exported to a translation unit C and the library unit A is generated using the translation unit C.
  • a library unit C is exported indirectly to a library unit A.
  • a library unit A extends a library unit B (or "library unit A is child of library unit B").
  • a library unit B is expanded by a library unit A (or “library unit B is parent of library unit A”).
  • the hierarchical relation "library unit A extends library unit B" means: If A is imported from another library unit, B is imported together with A into the other library unit.
  • a file directory is a subdirectory of another file directory.
  • the file directories form an arbitrarily branched tree structure.
  • a file belongs to exactly one directory. Conversely, a file directory contains no, one or more files.
  • a file contains at least one translation unit.
  • the permissible relations between structural elements are determined by automatically evaluating production rules defining the programming language P.
  • a description of the set of possible views of the architecture of a software system that has been implemented in the programming language P is read in or automatically acquired in some other way.
  • Most of the possible views can be used equally for many programming languages; some views require special properties of programming languages.
  • criterion is a set of structural elements selected to be displayed in the primary window of the view?
  • This criterion is preferably a category or a set of categories of structural element.
  • a filter condition under the structure elements of these categories can be effective.
  • the set of views comprises the following six views:
  • step e user specifications are automatically recorded.
  • one or more of the views are selected by these specifications, the representation to be generated comprises the selected views.
  • a primary window and a secondary window are displayed.
  • 1 shows the file source code view for an application example.
  • the primary window all files are listed, on which the source program of the software system is divided.
  • the following information about the files is preferably determined and displayed in the primary window:
  • the primary window is preferably divided into six columns.
  • the left column shows the names of the files in alphabetical order, the other five columns show the information about the file in the respective line.
  • An alternative embodiment provides that only an alphabetically sorted list with the names of the files is displayed in the primary window and the information about the file is shown after selection of a file name by "expanding" (or expanding).
  • a tree structure with the file directories (or directories) of the file management system and assigned files (or files) is displayed in the primary window of the file source text view.
  • the preselected files are displayed sorted in the primary window, sorted according to a user specification in one of the following ways: alphabetically according to the name of the structure element in ascending order or descending according to the total number of program lines in the file
  • the source text of the file is displayed in the secondary window (SF_1.1).
  • the keywords e.g. B. IF, THEN, END IF, highlighted in the source text.
  • SE_2 a second structure element whose name is contained in the displayed source text
  • SE_2 a second view is generated and displayed, in the primary window of which the second structure element is displayed.
  • a primary window and a secondary window are created.
  • 2 shows the data type view for an application example. All data types are listed in the primary window, i.e. all structure elements belonging to the category of data types described above. The number of the displayed data types is indicated in the heading of the primary window, in the example in FIG. 2 this is 148. The names of the data types and the names of the library units in which these data types are defined are preferably given in two columns in the primary window.
  • the primary window of FIG. 2 shows, for example, that the data type FORMAT_TYPE is defined in the library unit ADAR_FORMATS.
  • the preselected files are displayed sorted in the primary window, sorted in one of the following ways depending on a user preference:
  • the number of uses counts how many other structural elements use a data type in any way.
  • SE_1 After selecting a data type (SE_1) displayed in the primary window, all other structural elements (SE_2, SE_l.x) of the software system are displayed in the secondary window (SF_1.1), in which the selected data type is used in any way.
  • the names of the structural elements used and the names of the library units in which these structural elements are defined are also preferably displayed in two columns in the secondary window.
  • a primary window (PF_1) and three secondary windows (SF_1.1, SF_1.2, SF_1.3) are created.
  • Fig. 4 shows the construction view for an application example.
  • all variables and constants of the software system are preselected and listed in the primary window (PF_1).
  • the names of the preselected variables and constants, the names of the library units in which the preselected variables and constants are defined, are preferably displayed in four columns in the primary window.
  • a primary window (PF_1) and two secondary windows (SF_1.1, SF_1.2) are created.
  • 6 shows the construction view for an application example.
  • the primary window (PF_1) all library units as well as other structure elements with an inner structure, namely tasks, task types, protected type and protected objects are listed. All structure elements that either belong to the category of translation units or are tasks, task types, protected types or protected objects are preselected.
  • the number of the structure elements displayed is specified in the heading of the primary window (PF_1), in the example in FIG. 6 these are 1,048.
  • the preselected structure elements are displayed sorted in the primary window, sorted in one of the following ways depending on a user specification: alphabetically by name of the structure element first by type of structure element.
  • the similar structural elements are sorted alphabetically.
  • SE_1 After selecting a structure element (SE_1) in the primary window (PF_1), further structure elements are displayed in the two secondary windows, which have the following two relationships with the selected structure element (SE_1):
  • the first secondary window (SF_1.1) shows those structure elements that are defined in the specification of the selected structure element (SE_1). If the selected structural element (SE_1) is a library unit, the specification here means the translation unit specification that is used when the library unit is generated. If it is a protected object, the specification means the associated protected object specification.
  • the second secondary window SF_1.2
  • those structure elements are displayed that are used in the implementation of the selected structure element (SE 1).
  • SE 1 selected structure element
  • a package called PARSER_PCKG is selected.
  • the directory path and file name in which the package is defined are displayed in the first line and the name PARSER_PCKG of the package in the second line.
  • the structure of the PARSER_PCKG specification is listed in the following lines, in the order in which they appear in the source text.
  • the pictograms in front of the names indicate the type of structural element they contain.
  • the filter condition is determined by individual filter conditions.
  • the individual filter conditions can be switched on or off independently of each other.
  • the activated individual filter conditions are combined to the filter condition used for the preselection. 7 shows which individual filter conditions can be defined: -
  • the types of the structural element e.g. B. package (this makes library units of the type package) and protected objects, a single condition for the name of the structure element
  • a primary window and two secondary windows are created.
  • 8 shows the call view using an example. All subroutines are preselected in the primary window (PF_1), i.e. all structure elements that are functions or procedures and therefore belong to the subroutine category.
  • PF_1 the primary window
  • the number of subroutines displayed is specified; in the example in FIG. 8, this is 903.
  • the names of the subroutines and the names of the library units in which these subroutines are defined are preferably displayed in two columns in the primary window. H. in which their specification is included.
  • the primary window of FIG. 8 shows, for example, that the FORMAT subroutine is defined in the ADAR_FORMATS library unit.
  • the preselected subroutines are displayed sorted in the primary window (PF__1), sorted in one of the following ways depending on a user specification: alphabetically according to the name of the subroutines ascending or descending according to the number of uses.
  • Fig. 8 and Fig. 9 How many other subroutines a subroutine calls and uses?
  • the preselected subroutines in Fig. 8 and Fig. 9 are sorted in descending order by use. As FIG. 9 shows, both the number of times a subroutine is called and how many other subroutines it calls are counted.
  • SE_1 After selecting a subroutine (SE_1) in the primary window (PF_1), further structure elements (SE_2, SE_2.x) are displayed in the two secondary windows (SF_1.1, SF_1.2), which are in the following two relations with the selected subroutine (SE_1) :
  • FORMAT subroutine is selected, a function. FORMAT is called by 9 subroutines and calls 7 further subroutines.
  • the names of the subroutines and the names of the library units in which these subroutines are defined are preferably also in the secondary windows in two columns. H. in which their specification is included.
  • additional information about the subroutines and library units displayed in the two secondary windows is displayed, namely the line number in the source text of the structure element in which the subroutine is started.
  • This information is preferably displayed with the help of a tree view, which is “unfolded” and “folded in” again.
  • the source text is displayed, through which the subroutine is called.
  • not all subroutines are preselected, but only those that meet a filter condition defined by the user specifications.
  • the filter condition is determined by individual filter conditions.
  • the individual filter conditions can be switched on or off independently of each other.
  • the activated individual filter conditions are combined to the filter condition used for the preselection.
  • Fig. 9 shows which individual filter conditions can be defined:
  • Subroutines are selected that have multiple names (aliases), which is achieved via the mechanism of the rename.
  • Subroutines are selected which are exportable subroutines.
  • Subroutines that are local subroutines are preselected.
  • Pre-selected subroutines are used at least m times and / or at most n times. Depending on the corresponding user specifications, all uses or only the following uses are counted:
  • a primary window (PF_1) and four secondary windows (SF_1.1, SF_1.2, SF_1.3, SF_1.4) are created.
  • Fig. 10 shows the import-export view for an application example.
  • the primary window (PF_1) all Library units are listed, so all structural elements belonging to the category of library units are preselected. The number of library units displayed is specified in the heading of the primary window (PF_1).
  • the preselected library units are displayed in the primary window (PF 1) sorted in one of the following ways, depending on a user specification:
  • the preselected library units are sorted alphabetically in FIG. 10.
  • Fig. 12 the preselected library units are shown in descending order according to the number of import and / or export relations, which are called "uses" in Fig. 12.
  • all uses or only the following uses are counted: the direct and / or indirect imports into a translation unit specification, the direct and / or indirect imports into a translation unit implementation, the direct and / or indirect imports into a translation subunit, the direct and / or indirect exports into another library unit ,
  • All library units are displayed in the primary window, even those without an import or export relation to another library unit.
  • those library units are listed with which the library unit (SE_1) selected in the primary window is directly or indirectly connected via an import or export relation.
  • the first secondary window (SF_1.1) shows those other library units that are imported directly into the selected library unit (SE_1). In other words: those other library units are displayed that the selected library unit (SE_1) imports directly.
  • the second secondary window (SF__1.2) shows those other library units that are indirectly imported into the selected library unit (SE_1).
  • the third secondary window (SF_1.3) shows those other library units into which the selected library unit (SE_1) is exported directly.
  • the heading of the secondary window shows how many library units are displayed in each.
  • the other library units in the four secondary windows are either sorted alphabetically or differentiated according to specification, implementation and subunits.
  • Fig. 11 The user clicked on the "Expand” icon next to the "ADAR-COMP” library unit.
  • the translation units from which “ADAR-COMP” is generated are then displayed.
  • these are the translation unit specification “Specification”, the translation unit implementation “Body” and eight translation subunits.
  • PF_1 the primary window
  • PF_1 the filter condition specified by the user specifications.
  • the filter condition is determined by individual filter conditions.
  • the single filter conditions can be switched on or off independently of each other.
  • the activated individual filter conditions are combined to the filter condition used for the preselection.
  • Fig. 12 shows which individual filter conditions can be switched on or off:
  • the library units are preselected, which are of a certain type, e.g. B. all packages or all function instances.
  • the library units are preselected, the names of which meet a certain condition, e.g. B. start with A.
  • the direct exports to a translation unit specification the direct exports to a translation unit implementation, the direct exports to a translation subunit, the direct imports to another library unit, the indirect exports to a translation unit specification, the indirect exports to one Implementation of translation units, indirect exports to one translation subunit, indirect imports to another library unit.
  • the representation generated according to the invention is preferably on an output unit, for. B. a screen, a data processing system displayed.
  • Graphical user interface Surfaces ⁇ graphical user interfaces) such as MS Windows or UNIX versions offer different functions to display different windows on the screen, e.g. B. the primary window and the secondary window of a selected view.
  • extensive lists with names of objects (“list view”) can be displayed. If these functionalities are used for the method according to the invention, the objects to be displayed are structural elements of the software system.
  • two lists of structure elements are displayed in two secondary windows, which are in two specific relationships with a structure element previously selected in the primary window.
  • a user is able to select one of the displayed objects.
  • a structure element for example, a selection menu with possible actions is displayed.
  • B. Creation and display of a new view this is carried out. Further developments of this functionality show multi-column lists, so that relations between objects can be displayed in this way. With the help of a scrolling function, certain sections of the list can be displayed quickly. Further functionalities (“tree views”) indicate hierarchical relationships between objects.
  • An icon for the type of structure element is preferably displayed to the left of each structure element that is displayed in a primary or secondary window.
  • 14 shows an example of the pictograms for each type of structural element.
  • a context menu for the structure element is preferably shown after a corresponding user specification.
  • the user specification consists, for example, of pressing the right mouse button.
  • the next steps, which can be activated by selection in the context menu, include the generation of a second view according to claim 19.
  • 14 illustrates the creation of a second view.
  • a structure element (SE_2) that is displayed in a secondary window (SF_1.1, SF_1.2) of the selected view (S_l) is selected.
  • a second view (S_2) of the architecture is then selected, generated and displayed.
  • the second structure element (SE_2) is displayed in the primary window (PF_2) of the second view (S_2).
  • the second structure element (SE_2) or a third structure element (SE_3) which is displayed in the primary window (PF_2) of the second view (S_2), is selected in the primary window (PF_2) of the second view (S_2).
  • a secondary window (SF_2.1, SF_2.2) of the second view (S_2) a number of further structure elements (SE_4.1, SE_4.2) are displayed, which are linked to the second (SE_2) or third structure element (SE_3) stand in a certain relation.

Abstract

L'invention concerne un procédé permettant d'obtenir une représentation d'une architecture d'un système logiciel dont le programme source est donné. L'architecture représentée du système logiciel décrit la structure et les allures du système logiciel au moyen d'éléments de structure et de relations existant entre ces éléments de structure. L'architecture est déterminée automatiquement à l'aide d'un système de traitement de données. Conformément à l'invention, on définit une pluralité de vues de l'architecture. Une vue étant sélectionnée, on produit une fenêtre primaire de la vue et au moins une fenêtre secondaire de la vue. Une pluralité d'éléments de structure est sélectionnée suivant un critère prédéterminé et est visualisée dans la fenêtre primaire de la vue sélectionnée. Dans une fenêtre secondaire de la vue sélectionnée se trouve visualisée une pluralité d'autres éléments de structure en relation déterminée avec un élément de structure visualisé et sélectionné dans la fenêtre primaire. En sélectionnant de façon répétée un élément de structure dans une fenêtre secondaire et en visualisant cet élément de structure dans une fenêtre primaire d'une seconde vue, on obtient une navigation à travers l'architecture du système logiciel.
PCT/EP2002/008503 2001-08-16 2002-07-31 Procede de representation de l'architecture d'un systeme logiciel WO2003017105A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10140124.8 2001-08-16
DE2001140124 DE10140124A1 (de) 2001-08-16 2001-08-16 Verfahren zur Darstellung der Architektur eines Softwaresystems

Publications (2)

Publication Number Publication Date
WO2003017105A2 true WO2003017105A2 (fr) 2003-02-27
WO2003017105A3 WO2003017105A3 (fr) 2004-02-05

Family

ID=7695570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2002/008503 WO2003017105A2 (fr) 2001-08-16 2002-07-31 Procede de representation de l'architecture d'un systeme logiciel

Country Status (2)

Country Link
DE (1) DE10140124A1 (fr)
WO (1) WO2003017105A2 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5918053A (en) * 1996-12-19 1999-06-29 International Business Machines Corp. Method and system for diagraming collaborations deduced from small talkcode using a design virtual machine
US6247020B1 (en) * 1997-12-17 2001-06-12 Borland Software Corporation Development system with application browser user interface

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410648A (en) * 1991-08-30 1995-04-25 International Business Machines Corporation Debugging system wherein multiple code views are simultaneously managed
WO1995000902A1 (fr) * 1993-06-28 1995-01-05 Taligent, Inc. Systeme dynamique de consultation rapide
US5794047A (en) * 1994-09-29 1998-08-11 International Business Machines Corporation Method of walking-up a call stack for a client/server program that uses remote procedure call
US6202199B1 (en) * 1997-07-31 2001-03-13 Mutek Solutions, Ltd. System and method for remotely analyzing the execution of computer programs

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5918053A (en) * 1996-12-19 1999-06-29 International Business Machines Corp. Method and system for diagraming collaborations deduced from small talkcode using a design virtual machine
US6247020B1 (en) * 1997-12-17 2001-06-12 Borland Software Corporation Development system with application browser user interface

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
INTERMETRICS INC.: "Ada 95 Reference Manual (Abschnitte 3.2-3.4, 6.1, 10.1.1)" [Online] XP002256993 Gefunden im Internet: <URL: http://www.adahome.com/rm95/rm9x-toc.html> [gefunden am 2003-10-07] in der Anmeldung erwähnt Absätze [03.2Ü-[03.4] Absatz [06.1] Absatz [10.1.1] *

Also Published As

Publication number Publication date
DE10140124A1 (de) 2003-03-06
WO2003017105A3 (fr) 2004-02-05

Similar Documents

Publication Publication Date Title
DE60001916T2 (de) Plattformunabhängige speicherabbild analysearchitektur zur programmfehlerbeseitigung
DE10051645B4 (de) Prozesssteuersystem und Verfahren zum Kontrollieren eines Prozesses
EP1303797B1 (fr) Systeme de support d&#39;une analyse de cause d&#39;erreur
EP1723513B1 (fr) Procede pour configurer un programme informatique
DE602005005924T2 (de) Einheitliches Datenformat für Messgeräte
DE10308725A1 (de) System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
DE19960050A1 (de) Grafische Benutzerschnittstelle zur Entwicklung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek
DE10144390A1 (de) Visualisierung eines Vergleichsergebnisses mindestens zweier in Verzeichnisbäumen organisierter Datenstrukturen
DE102004043788A1 (de) Programm Generator
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE102010033861A1 (de) Auf einer formellen Analyse basierte Entwicklung von Anforderungsspezifikationen
EP1005215B1 (fr) Procédé et système pour l&#39;édition des données de configuration pour systèmes de télécommunication
DE10041072A1 (de) Verfahren zur automatischen Erzeugung von Programmcode
DE10008632B4 (de) Verfahren und System zum Erzeugen eines Computerprogramms
WO2003017105A2 (fr) Procede de representation de l&#39;architecture d&#39;un systeme logiciel
DE60010078T2 (de) System zur analyse von daten für den elektronischen handel
EP1324218A1 (fr) Système de categoriser des objets de donnés et procédé de vérifier la consistance des categories designees aux objets d&#39;information
DE4310615C2 (de) Entwurf elektrischer Vorrichtungen mit mehreren Entwurfswerkzeugen, die zumindest teilweise untereinander inkompatibel sind
DE102018115630B4 (de) Verfahren zum Erstellen und Betreiben einer Website mit Eingabemöglichkeit
EP1600854A2 (fr) Procédé pour travailler avec les langages de programmation Kontaktplan et Funktionsplan et éditeur graphique approprié
EP0560342B1 (fr) Méthode pour le débogage de programmes HDL
DE102013204245A1 (de) Verfahren und Vorrichtung zum Bereitstellen von extrahierten Daten
WO2003094049A2 (fr) Systeme de traitement de donnees
DE102019126791A1 (de) Verfahren zum Automatisieren der Erkennung eines Testobjektes für eine zu testende Anwendung
EP1668494A1 (fr) Procede et systeme de configuration vocale d&#39;un programme informatique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): US

Kind code of ref document: A2

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FR GB GR IE IT LU MC NL PT SE SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase