WO2007101487A1 - Verfahren zur automatischen erzeugung von aktuellen architekturinformationen eines software-systems - Google Patents
Verfahren zur automatischen erzeugung von aktuellen architekturinformationen eines software-systems Download PDFInfo
- Publication number
- WO2007101487A1 WO2007101487A1 PCT/EP2006/069826 EP2006069826W WO2007101487A1 WO 2007101487 A1 WO2007101487 A1 WO 2007101487A1 EP 2006069826 W EP2006069826 W EP 2006069826W WO 2007101487 A1 WO2007101487 A1 WO 2007101487A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- software system
- architecture
- architectural
- description
- information
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/73—Program documentation
Definitions
- the invention relates to a method for generating current architectural information of a software system in which subsystems and their relationships are graphically displayed on the basis of the architectural information.
- Such graphs are used with standard layout algorithms, e.g. Hierarchically by inheritance, by use, or grouped by weighted relationship strength. Often, such graphs are then reworked by hand or the architecture of the software system by moving, coloring or arranging the nodes by hand into account.
- the object of the invention is now to provide a method for the automatic generation of current architectural information, in which fast under
- the invention is that an implemented structure of a software system, such as that provided by a code analysis tool, is enriched with the order information of the architecture and thus automatically information for graphs which are correct with respect to the implementation state of the software system and to consider the order of the architecture to be generated automatically.
- a code analysis tool is enriched with the order information of the architecture and thus automatically information for graphs which are correct with respect to the implementation state of the software system and to consider the order of the architecture to be generated automatically.
- architectural representations regarding the implementation exactly. The representations are reproducible since they are generated completely automatically on the basis of predefined data. The topological order is preserved across the versions.
- the systems developed on the same platform eg. B. product families, there is a cross-system awareness of. Platform components.
- FIG. 1 is a schematic diagram for explaining the method according to the invention
- Figure 2 shows a conventional architectural representation
- FIG. 3 shows an opposing representation of a system with subsystems, wherein the mutual relationships are shown on the one hand as relationship arrows and on the other hand as a marking pattern, and
- Figure 4 is an architectural representation based on the method according to the invention and also for a system of medium size.
- Software system, or the dynamic architecture, ie the installed software system, transferred. 1 shows a schematic diagram for explaining the method according to the invention, wherein, in a first step, from the sources Q of a software system, a quality model QM and a so-called "build guide" BA, the usual way make or project Files, using a CA tool CAT to create structure and metric data SMD of the software system and store it in the CA tool's "repository” CAR.
- the structure and metric data SMD are then read out of the repository CAR and a topological order of the associated architecture is added via the human-machine interface HMI, in which case the presentation of metrics is additionally selected and / or further layout parameters are defined ,
- the result is stored as an architectural description AB in an optional step.
- a ready-made description can be used. If subsystems have been added or dropped, this must be adapted in the architectural description.
- a filter F reads the architecture description AB and the stored structure and metric data SMD 'from the repository CAR and arranges the structure data accordingly.
- the result is an arranged structure description ASD, for example in XML, with layout parameters.
- a layout L then transforms the arranged structure ⁇ description ASD in a corresponding plot SVG.
- the layout of the architectural representation first selects the size and then the position of the graphical objects selected to represent the artifacts.
- the Representations are hierarchical in principle, with the hierarchically lower levels being embedded in the objects of the higher levels.
- each graphical object is determined depending on an implicit size metric. It is proportional to the metric values of the objects of the same level. Thus, the relative sizes of the objects reflect the conditions of the metric ⁇ these objects values again.
- the position of the graphical objects or the arrangement of the clusters is specified on each hierarchical level by the user, for example with respect to a grid.
- Each cluster therefore has a unique coordinate consisting of column and row information.
- CA tools use arrows to represent relationships. This type of representation of relationships often requires very confusing architectural representations already for medium-sized systems, which is shown by way of example in FIG.
- FIG. 3 by way of example, three subsystems A, B, C are shown with their mutual relationships, the relationships on the left, as usual, being represented only by arrows and on the right by marking patterns only.
- Relationship strength is expressed in the latter case, if necessary, by the strength of the marker and the topological order is reflected in the marker pattern or in the color.
- Relationship strength is expressed in the latter case, if necessary, by the strength of the marker and the topological order is reflected in the marker pattern or in the color.
- Mixed forms with arrows and marking patterns are also possible, with, for example, particularly emphasized relationships continuing to be represented as arrows.
- FIG. 4 also shows an architectural representation, as in FIG. 2, for a system of medium size, which however was formed with the aid of the method according to the invention, wherein a service container frame R is surrounded by at least one Application Al, A2, A3 is arranged in the form of a frame and contains at least the services FS required by these applications in the frame R.
- the entire representation is hierarchical or recursive, ie in this example that these applications Al, A2, A3 themselves each have such a frame Rl, R2, R3 and the application Al within the frame Rl an application All with a corresponding frame RlI having.
- SOA Service Oriented Architecture
- the individual layers of these architectures themselves contain large software systems that follow their own architectures, resulting in recursive architectures.
- the graphic metaphors are embedded in each other for their presentation.
- the quality of the considered implementation of the software systems can be captured with a variety of metrics and presented as quality information. These metrics can be calculated and displayed either for the entire system or for the individual subsystems. To obtain a quick and easy overview of the status or differences of the individual subsystems, the quality key figures are explicitly or implicitly inserted into the architectural representation. Especially for volume metrics and structural rules, such as relationship strength, forbidden relationships, cycles, cyclic groups with the weakest connections, intuitive understandable graphical metaphors are advantageously used.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Library & Information Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
Die Erfindung besteht im Wesentlichen darin, dass eine implementierte Struktur eines Software-Systems, wie sie bspw. ein Code-Analyse-Tool liefert, mit der Ordnungsinformation der Architektur angereichert wird. Auf diese Weise werden Informationen für Graphen automatisch erzeugt, wobei diese Graphen korrekt bzgl. des Implementierungsstandes sind und die Ordnung der Architektur berücksichtigen. Hiermit sind Architekturdarstellungen bezüglich der Implementierung genau. Die Darstellungen sind reproduzierbar, da sie ja auf Basis vordefinierter Daten vollständig automatisch erzeugt werden. Die topologische Ordnung wird über die Versionen hinweg erhalten. Werden die Systeme auf gleicher Plattform entwickelt, z. B. Produktfamilien, ergibt sich eine System übergreifende Widererkennbarkeit bzgl. der Plattform-Komponenten.
Description
Beschreibung
Verfahren zur automatischen Erzeugung von aktuellen Architekturinformationen eines Software-Systems
Die Erfindung betrifft ein Verfahren zur Erzeugung von aktuellen Architekturinformationen eines Software-Systems, bei dem Subsysteme und ihre Beziehungen auf Basis der Architekturinformationen graphisch dargestellt werden.
Große Software-Systeme müssen für ihre Erstellung und Wartung verständlich und handhabbar sein. Da nur eine relativ kleine Menge von Systemkomponenten oder Beziehungen von einem Bearbeiter überschaut werden kann, ist es vorteilhaft dies bei der Strukturierung eines Software-Systems zu berücksichtigen. Hierzu ist es notwendig ein großes Software- System in eine kleine Menge von Teilsystemen mit wenigen Beziehungen zueinander aufzuteilen. Für große Systeme sollte diese Aufteilung in mehreren Stufen erfolgen, um die Teilsysteme in einer überschaubaren Größe zu erhalten. Um die Beziehungen der Teilsysteme untereinander gering zu halten werden zusätzliche Beschränkungen definiert, die festlegen, welche Teilsysteme untereinander in Beziehung stehen dürfen. Eine verteilte und/oder inkrementelle Entwicklung Personalwechsel, Integration, Versionisierung und Konfigura¬ tion stellen besondere Herausforderungen auf diesem Gebiet dar .
Heute existierende Lösungsansätze beinhalten hauptsächlich manuelle Lösungen die von Experten erarbeitet werden.
Graphisch ansprechende Architektur-Darstellungen werden von Hand mit z.B. üblichen allgemeinen Präsentationswerkzeugen erstellt. Diese Darstellungen sind zwar sehr aufwendig, aber zur Kommunikation sehr gut geeignet. Da diese Darstellung in der Regel aber unabhängig von der Implementierung und ohne diese zu berücksichtigen erzeugt werden, stellen diese so erstellten Architekturdiagramme nicht notwendigerweise das
reale Software-System dar. Hieraus können folgenschwere Fehlentscheidungen entstehen.
Um die Struktur eines Software-Systems, also die Untereinheiten und ihre Beziehungen, darzustellen, kommen bislang auch Code-Analyse-Tools bzw. CA-Tools zum Einsatz, wie z.B. „Sotograph" oder understand4C/C++ . Nähere Informationen hierzu finden sich bspw. unter h11p : / /www . softwάie-tomography . com/htm1/sotograph_._rit_m
Solche Graphen werden mit Standard-Layoutalgorithmen, z. B. hierarchisch nach Vererbung, nach Verwendung oder gruppiert nach gewichteter Beziehungsstärke angeordnet. Oft werden solche Graphen dann von Hand nachgearbeitet bzw. die Architektur des Software-Systems durch verschieben, färben oder anordnen der Knoten von Hand berücksichtigt.
Die der Erfindung zu Grunde liegende Aufgabe besteht nun darin ein Verfahren zur automatischen Erzeugung aktueller Architekturinformationen anzugeben, bei dem schnell unter
Berücksichtigung des aktuellen Standes des Software-Systems möglichst aussagekräftige Ist-Architektur-Informationen als Basis für die Erstellung von Architekturdiagrammen automatisch erzeugt werden.
Diese Aufgabe wird erfindungsgemäß durch die Merkmale des Patentanspruchs 1 gelöst. Die weiteren Ansprüche betreffen vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens .
Die Erfindung besteht im Wesentlichen darin, dass eine implementierte Struktur eines Software-Systems, wie sie ein Code-Analyse-Tool liefert, mit der Ordnungsinformation der Architektur angereichert werden und so automatisch Informationen für Graphen die korrekt bzgl. des Implementierungsstandes des Software-Systems sind und die Ordnung der Architektur berücksichtigen automatisch erzeugt werden.
Hiermit sind Architekturdarstellungen bezüglich der Implementierung genau. Die Darstellungen sind reproduzierbar, da sie ja auf Basis vordefinierter Daten vollständig automatisch erzeugt werden. Die topologische Ordnung wird über die Versionen hinweg erhalten. Werden die Systeme auf gleicher Plattform entwickelt, z. B. Produktfamilien, ergibt sich eine System übergreifende Widererkennbarkeit bzgl. der Plattform-Komponenten .
Die Erfindung wird nun an Hand von in der Zeichnung dargestellten bevorzugten Ausführungsbeispielen näher erläutert . Dabei zeigt
Figur 1 eine Prinzipdarstellung zur Erläuterung des erfindungsgemäßen Verfahrens,
Figur 2 eine herkömmliche Architekturdarstellung mit
Beziehungspfeilen für ein System mittlerer Größe,
Figur 3 eine gegenüberstellende Darstellung eines Systems mit Subsystemen, wobei die gegenseitigen Beziehungen zum einen als Beziehungspfeile und zum anderen als Markierungsmuster dargestellt sind, und
Figur 4 eine Architekturdarstellung auf der Basis des erfindungsgemäßen Verfahrens und ebenfalls für ein System mittlerer Größe.
Für die Darstellung der Architektur eines Software-Systems werden 3 Sichten empfohlen, nämlich eine logische, eine statische und eine dynamische Sicht. Im Folgenden wird hauptsächlich auf die statische Architektur, also die
Struktur des implementierten Software-Systems eingegangen.
Die dargestellten Prinzipien lassen sich aber auch auf die logische Architektur, d. h. die funktionale Aufteilung des
Software-Systems, bzw. die dynamische Architektur, d. h. das installierte Software-System, übertragen.
In Figur 1 ist eine Prinzipdarstellung zur Erläuterung der erfindungsgemäßen Verfahrens gezeigt, wobei, in einem ersten Schritt, aus den Quellen Q eines Software-Systems, einem Qualitätsmodell QM und einer so genannten „Build-Anleitung" BA, die üblicher Weise make- oder projekt-Dateien aufweist, mit Hilfe eines CA-Tools CAT Struktur- und Metrikdaten SMD des Software-Systems erstellt und im „Repository" CAR des CA- Tools abgelegt werden. In einem zweiten Schritt werden dann die Struktur- und Metrikdaten SMD aus dem Repository CAR ausgelesen und es wird über die Mensch-Maschine-Schnittstelle HMI eine topologische Ordnung der zugehörigen Architektur hinzugefügt, wobei zusätzlich die Darstellungsform von Metriken ausgewählt und/oder weitere Layoutparameter definiert werden.
Das Ergebnis wird, in einem optionalen Schritt, als Architekturbeschreibung AB gespeichert. Bei einer wiederholten Darstellung des Software-Systems kann eine vorgefertigte Beschreibung verwendet werden. Sind Subsysteme hinzugekommen oder weggefallen ist dies in der Architekturbeschreibung anzupassen.
In einem dritten Schritt liest ein Filter F die Architekturbeschreibung AB und die gespeicherten Struktur- und Metrikdaten SMD' aus dem Repository CAR und ordnet die Strukturdaten entsprechend an. Das Ergebnis ist eine angeordnete Strukturbeschreibung ASD, bspw. in XML, mit Layoutparametern .
Ein Layouter L transformiert dann die angeordnete Struktur¬ beschreibung ASD in eine entsprechende graphische Darstellung SVG.
Beim Layout der Architekturdarstellung werden zuerst die Größe und dann die Position der für die Darstellung der Artefakte gewählten graphischen Objekte gewählt. Die
Darstellungen sind vom Prinzip her hierarchisch, wobei die hierarchisch unteren Ebenen in die Objekte der übergeordneten Ebenen eingebettet werden.
Die Größe jedes graphischen Objektes wird abhängig von einer impliziten Größenmetrik bestimmt. Sie ist proportional zu den Metrikwerten der Objekte gleicher Ebene. Somit spiegeln die Größenverhältnisse der Objekte die Verhältnisse der Metrik¬ werte dieser Objekte wieder.
Die Position der graphischen Objekte bzw. die Anordnung der Cluster wird auf jeder Hierarchieebene vom Benutzer, bspw. bezüglich eines Rasters, vorgegeben. Es weist also jeder Cluster eine eindeutige aus Spalten- und Zeilenangabe be- stehende Koordinate auf.
CA-Tools verwenden zu Darstellung von Beziehungen Pfeile. Diese Art der Darstellung von Beziehungen bedingt oft sehr unübersichtliche Architektur-Darstellungen bereits für mittelgroße Systeme, was in Figur 2 beispielhaft gezeigt ist.
In Figur 3 ist sind beispielhaft drei Subsysteme A, B, C mit ihren gegenseitigen Beziehungen dargestellt, wobei links die Beziehungen, wie üblich, nur durch Pfeile und rechts nur durch Markierungsmuster repräsentiert sind. Die
Beziehungsstärke wird im Letzteren Fall, falls notwendig, durch die Stärke der Markierung ausgedrückt und die Topologische Ordnung spiegelt sich im Markierungsmuster bzw. in der Farbe wieder. Es sind auch Mischformen mit Pfeilen und Markierungsmustern möglich, wobei bspw. besonders hervorzuhebende Beziehungen weiterhin als Pfeile dargestellt werden .
In Figur 4 ist eine Architekturdarstellung ebenfalls, wie in Figur 2, für ein System mittlerer Größe dargestellt, das jedoch mit Hilfe des erfindungsgemäßen Verfahrens gebildet wurde, wobei ein Servicecontainer-Rahmen R um mindestens eine
Applikation Al, A2, A3 rahmenförmig angeordnet ist und mindestens die von den im Rahmen R diesen Applikationen benötigten Services FS enthält. Die gesamte Darstellung ist hierarchisch bzw. rekursiv, d. h. in diesem Beispiel, dass diese Applikationen Al, A2, A3 selbst wiederum jeweils einen solchen Rahmen Rl, R2, R3 aufweisen und die Applikation Al innerhalb des Rahmens Rl eine Applikation All mit einem entsprechenden Rahmen RlI aufweist.
Integration von mehreren großen Software-Systemen zu einer
DV-Verfahrens-Landschaft . Ein aktuelles Stichwort hierfür ist SOA (Service Oriented Architecture) . Früher nannte man diese aus mehreren Schichten aufgebauten Integrations-Architekturen z.B. ERP-System, Toolbus, CORBA (Common Request Broker Architecture) . Die einzelnen Schichten dieser Architekturen enthalten selbst wieder große Software-Systeme, die ihren eigenen Architekturen folgen, was zu rekursiven Architekturen führt. Um solche verschachtelten Architekturen zu berücksichtigen werden die graphischen Metaphern zu ihrer Darstellung in einander eingebettet.
Die Qualität der betrachteten Implementierung der Softwaresysteme lässt sich mit verschiedensten Metriken erfassen und als Qualitätsinformation darstellen. Diese Metriken lassen sich entweder für das Gesamtsystem oder für die einzelnen Subsysteme berechnen und darstellen. Um einen schnellen und einfachen Überblick über den Zustand bzw. die Unterschiede der einzelnen Subsysteme zu erhalten werden die Qualitätskennzahlen explizit oder implizit in die Architekturdarstellung eingefügt. Speziell für Volumenmetriken und Strukturregeln, bspw. Beziehungsstärke, verbotene Beziehungen, Zyklen, zyklische Gruppen mit den schwächsten Verbindungen, werden vorteilhafter Weise intuitive verständliche graphische Metaphern verwendet.
Die für das Layout vorgegeben Ordnung der Subsysteme folgt dem Architektur-Prinzip das bei der Entwicklung des Software-
Systems zu Grunde gelegt wurde. Es gibt oft verwendete Architektur-Archetypen. Um den Nutzer bei der Auswahl und Definition der Ordnungskriterien zu unterstützen, werden Architektur-Archetypen mit typischen Anordnungen definiert und ihnen graphisch Metaphern zugeordnet.
Claims
1. Verfahren zur automatischen Erzeugung von aktuellen Architekturinformationen eines Software-Systems, - bei dem, in einem ersten Schritt, mit Hilfe eines Code
Analyse-Werkzeugs (CAT) Struktur- und Metrikdaten (SMD) des Software-Systems erstellt und gespeichert werden, - bei dem, in einem zweiten Schritt, über die Mensch- Maschine-Schnittstelle (HMI) den Struktur- und Metrikdaten eine topologische Ordnung der zugehörigen Architektur hinzugefügt und eine Architekturbeschreibung (AB) gebildet wird, wobei zusätzlich die Darstellungsform von Metriken ausgewählt und/oder weitere Layoutparameter definiert werden, und - bei dem, in einem dritten Schritt, ein Filter (F) die
Architekturbeschreibung AB und die gespeicherten Struktur- und Metrikdaten (SMD' ) anordnet und die Architekturinformation in Form einer angeordneten Strukturbeschreibung (ASD) mit Layoutparametern bildet.
2. Verfahren nach Anspruch 1, bei dem die Architekturbeschreibung (AB) gespeichert wird und durch aktuell hinzukommende oder wegfallende Subsysteme nur entsprechende Anpassungen der gespeicherten Architekturbeschreibung vorgenommen werden.
3. Verfahren nach Anspruch 1 oder 2, bei dem die Mensch-Maschine-Schnittstelle Architektur- Archetypen mit typischen Anordnungen zur Verfügung stellt, denen graphische Metaphern zugeordnet sind.
4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem über die Mensch-Maschine-Schnittstelle die Position der graphischen Objekte für die Applikationen auf jeder Hierarchieebene vorgegeben werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem das Filter (F) für die Applikationen auf den jeweiligen Hierarchieebenen die jeweils benötigten Services (FS) ermittelt.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem für das Software-System mit Hilfe von Metriken Metrikwerte gebildet werden und bei dem über die Mensch-Maschine-Schnittstelle Metrikwerte als Layoutparameter ausgewählt und zur angeordneten Strukturbeschreibung (ASD) hinzugefügt werden.
7. Verfahren nach Anspruch 6, bei dem der Layoutparameter die Größe eines graphischen Objektes zur Darstellung einer jeweiligen Applikation ist.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102006009463.8 | 2006-03-01 | ||
| DE102006009463 | 2006-03-01 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2007101487A1 true WO2007101487A1 (de) | 2007-09-13 |
Family
ID=38197610
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2006/069826 WO2007101487A1 (de) | 2006-03-01 | 2006-12-18 | Verfahren zur automatischen erzeugung von aktuellen architekturinformationen eines software-systems |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2007101487A1 (de) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11537414B2 (en) | 2020-06-04 | 2022-12-27 | Bank Of America Corporation | Architecture mapping of applications |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002095576A1 (en) * | 2001-05-24 | 2002-11-28 | Conexant Systems, Inc. | System and method for manipulation of software |
-
2006
- 2006-12-18 WO PCT/EP2006/069826 patent/WO2007101487A1/de active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002095576A1 (en) * | 2001-05-24 | 2002-11-28 | Conexant Systems, Inc. | System and method for manipulation of software |
Non-Patent Citations (4)
| Title |
|---|
| DUCASSE S ET AL: "Polymetric views - A lightweight visual approach to reverse engineering", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, IEEE, NEW YORK, NY, US, vol. 29, no. 9, September 2003 (2003-09-01), pages 782 - 795, XP011101657, ISSN: 0098-5589 * |
| ROBITAILLE S ET AL: "Bridging program comprehension tools by design navigation", SOFTWARE ENGINEERING, 2000. PROCEEDINGS. INTERNATIONAL CONFERENCE ON OCTOBER 11-14, 2000, PISCATAWAY, NJ, USA,IEEE, 11 October 2000 (2000-10-11), pages 22 - 32, XP010522513, ISBN: 0-7695-0753-0 * |
| TELEA ET AL: "An open toolkit for prototyping reverse engineering visualizations", PROCEEDINGS OF THE SYMPOSIUM ON DATA VISUALISATION, 2002, Barcelona, Spain, pages 241 - 249, XP008080974, Retrieved from the Internet <URL:http://portal.acm.org/citation.cfm?id=509740.509781> [retrieved on 20070705] * |
| TERMEER M ET AL: "Visual exploration of combined architectural and metric information", 2005 3RD IEEE INTERNATIONAL WORKSHOP ON VISUALIZING SOFTWARE FOR UNDERSTANDING AND ANALYSIS 25 SEPT. 2005 BUDAPEST, HUNGARY, 25 September 2005 (2005-09-25), 2005 3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis (IEEE Cat. No. 05EX1225) IEEE Piscataway, NJ, USA, pages 21 - 26, XP008080973, ISBN: 0-7803-9540-9 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11537414B2 (en) | 2020-06-04 | 2022-12-27 | Bank Of America Corporation | Architecture mapping of applications |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| DE3416939C2 (de) | ||
| DE112015005994B4 (de) | Softwareerzeugungseinrichtung | |
| DE10051645A1 (de) | Verfahren und Vorrichtung zur Versionskontrolle und Protokollierung in einem Prozesssteuersystem | |
| DE10394033T5 (de) | Verfahren und Vorrichtung zum Importieren von Vorrichtungsdaten in ein in einer Prozessanlage verwendetes Datenbanksystem | |
| EP1061422A1 (de) | Informationstechnisches System zur Definition, Optimierung und Steuerung von Prozessen | |
| DE10197097B4 (de) | Programmierwerkzeug | |
| EP1638028A2 (de) | Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen | |
| DE102010042999A1 (de) | Verfahren zur Bereitstellung eines Bedienmenüs für ein Feldgerät der Prozessautomatisierungstechnik | |
| EP0838054B1 (de) | Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem | |
| EP1347376B1 (de) | Software zur Visualisierung hierarchisch stufbaren Objekten | |
| EP1901148B1 (de) | Anzeigesystem zur grafischen Darstellung von Alarmmeldungen einer technischen Anlage oder eines technischen Prozesses | |
| WO2007101487A1 (de) | Verfahren zur automatischen erzeugung von aktuellen architekturinformationen eines software-systems | |
| EP2642359A1 (de) | Entwicklungseinrichtung und Verfahren zum Erstellen eines Steuergeräteprogramms | |
| EP0860759B1 (de) | Verfahren und Vorrichtung zur multimedialen Darstellung komplexer Systeme | |
| DE60026847T2 (de) | Verfahren, einem objekt in einer datenbank eine identität zuzuweisen | |
| DE102020119853B3 (de) | Verfahren zum Steuern eines Automatisierungssystems mit Visualisierung von Programmobjekten eines Steuerprogramms des Automatisierungssystems und Automatisierungssystem | |
| DE10055168A1 (de) | Industrielle Steuerung auf der Basis verteilbarer Technologischer Objekte | |
| EP1655663A1 (de) | Datenflussmodellierung in Engineering-Systemen | |
| EP1505399B1 (de) | Verfahren zum Erzeugen von Testdaten zum Austesten der Funktionsfähigkeit einer datenverarbeitenden Schaltung | |
| EP2249219A2 (de) | Verfahren zur Auswahl eines einem Übertragungsnetz eines Automatisierungs-Systems zugeordneten Kommunikationssystems | |
| DE10311055B3 (de) | Verfahren und Anordnung zur Projektierung eines elektrischen Systems | |
| DE102004039884A1 (de) | Verfahren und System zur Beschreibung und Ausführung automatischer Tests | |
| EP1502164B1 (de) | Verfahren ZUR UNTERSTÜTZUNG EINER PLANUNG UND REALISIERUNG EINES AUTOMATISIERTEN TECHNISCHEN PROZESSES | |
| DE10033812A1 (de) | Verfahren zum Erzeugen von Informationsmodellen | |
| WO1995014281A1 (de) | Verfahren zur automatischen modellierung eines teilprozesses aus einem gesamtprozess durch einen rechner |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 06841420 Country of ref document: EP Kind code of ref document: A1 |