DE102010001765A1 - Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur - Google Patents

Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur Download PDF

Info

Publication number
DE102010001765A1
DE102010001765A1 DE201010001765 DE102010001765A DE102010001765A1 DE 102010001765 A1 DE102010001765 A1 DE 102010001765A1 DE 201010001765 DE201010001765 DE 201010001765 DE 102010001765 A DE102010001765 A DE 102010001765A DE 102010001765 A1 DE102010001765 A1 DE 102010001765A1
Authority
DE
Germany
Prior art keywords
source code
delta
model
elements
structure model
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
DE201010001765
Other languages
English (en)
Inventor
Jens 67655 Knodel
Dirk 67663 Muthig
Dominik 68165 Rost
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
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 Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority to DE201010001765 priority Critical patent/DE102010001765A1/de
Publication of DE102010001765A1 publication Critical patent/DE102010001765A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • 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/72—Code refactoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

Bei einem Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur wird zunächst ein Ausgangs-Strukturmodell einer Software-Architektur bereitgestellt, so dass das Ausgangs-Strukturmodell die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt. Dann wird eine Abbildungsvorschrift bereitgestellt, so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung und Rückrichtung definiert ist. Dann wird ein Delta-Quellcodeteil empfangen, der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist. Dann wird ein Delta-Quellcodemodell ermittelt, basierend auf dem Delta-Quellcodeteil, so dass das Delta-Quellcodemodell Abhängigkeiten, die in dem Delta-Quellcodeteil enthalten sind, beschreibt. Dann wird ein Delta-Struktur-Modell ermittelt, das gegenüber dem Ausgangs-Strukturmodell verändert ist, basierend auf dem Delta-Quellcodemodell unter Verwendung der Abbildungsvorschrift, so dass das Delta-Strukturmodell die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteils veränderten Delta-Quellcodeteils definiert ist, beschreibt. Schließlich wird das Delta-Strukturmodell mit einem Referenz-Strukturmodell verglichen, um ein Vergleichsergebnis zu erhalten, das eine Regeltreue des Delta-Quellcodeteils oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Deltaquellcodeteil umfasst, beschreibt. Hierbei wird bei dem Ermitteln des Delta-Quellcodemodells, bei dem Ermitteln des Delta-Strukturmodells oder bei dem Vergleichen des Delta-Strukturmodells mit dem Referenzstrukturmodell eine Neubestimmung von Informationen, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil unabhängig ist, selektiv unterdrückt oder vermieden.

Description

  • Ausführungsbeispiele der Erfindung beziehen sich auf ein Verfahren zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur in Echtzeit.
  • Weitere Ausführungsbeispiele der Erfindung beziehen sich auf ein System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur.
  • Weitere Ausführungsbeispiele der Erfindung beziehen sich auf eine direkt übertragene Konformitätsprüfung („Live Compliance Checking”).
  • Bei einer Konformitätsprüfung („Compliance Checking”) wird der Grad einer Regeltreue einer Implementierung einer Software-Architektur ermittelt. 4 zeigt die fünf konzeptionellen Phasen 410, 420, 430, 440, 450 der analytischen Konformitätsprüfung 400, zusammengefasst aus konkreten Techniken, die den aktuellen Stand der Technik darstellen.
  • In der Architekturphase 410 modelliert der Architekt 402 die beabsichtigte Strukturunterteilung des Systems bezüglich Komponenten und Beziehungen zwischen denselben. Diese Beschreibung des zukünftigen Plans ist die Vorgabe für die Entwickler 403, um die Implementierung zu beginnen. Außerdem dient das Strukturmodell 415 als Vorgabe für die Konformitätsprüfung 439 in der Analysephase 430.
  • In der Implementierungsphase 420 übersetzen Entwickler 403 dies in den Quellcode 425-1, 425-2, 425-3 (d. h. Algorithmen und Datenstrukturen). Durch Verfeinern der abstrakten grobkörnigen Entitäten implementieren sie viele feinkörnige konkrete Codeelemente. Typischerweise erzeugen Entwicklerteams den Quellcode gleichzeitig oder modifizieren und erweitern bestehenden Code. Schließlich wird der Quellcode 425-1, 425-2, 425-3 in einem Depot 427 gespeichert.
  • In der Analysephase 430 verarbeitet die Analyse das vordefinierte Strukturmodell 415 und eine Momentaufnahme (snapshot) 435 des Quellcodes 425-1, 425-2, 425-3, um die Konformitätsprüfung auszuführen. Es ist möglich, modellbasierte oder regelbasierte Konformitätsprüftechniken anzuwenden. Unabhängig von der gewählten Technik sind die Ergebnisse jedoch äquivalent. Die Prüfergebnisse 445 unterscheiden zwischen Konformität 447 und Verletzungen 449.
  • In der Kommunikationsphase 440 überprüft der Architekt 402 die Prüfergebnisse 445 und definiert strukturelle Reparaturaufgaben für die jeweiligen Entwickler 403. Die gleichen Entwickler, die die Verletzungen verursachen, wären der ideale Kandidat zum Korrigieren derselben.
  • Die Korrekturphase 450 realisiert dann die Strukturreparatur. Erneut gestalten Entwicklerteams gleichzeitig verletzende Codeteile um. Die Korrektur führt zu einer weiteren Implementierungsphase, d. h. erneutes Wiederholen aller Phasen, um unerwünschte Nebeneffekte zu vermeiden und die korrigierten Verletzungen zu verifizieren.
  • Die Zeichenerklärung 401 der 4 zeigt die entsprechenden Symbole für Architekt 402, Entwickler 403, Informationsfluss 404 und Konformitätsprüfung 439.
  • In der US 2009/0276757 A1 werden Systeme, Computerprogrammprodukte und Methoden zum Extrahieren, Auswerten und Aktualisieren der Architektur eines Softwaresystems beschrieben. Bei einem Ausführungsbeispiel arbeitet die Methode durch Definieren der geplanten Architektur für das System und Extrahieren der implementierten Software-Code-Architektur aus dem Quellcode des Systems. Die Methode vergleicht die eigentliche Architektur mit der geplanten Architektur, die definiert ist, um architektonische (strukturelle) Abweichungen zu identifizieren, und vorgeschlagene Änderungen für die Architektur werden identifiziert basierend auf den strukturellen Abweichungen. Die modellierte Code-Architektur- und definierte geplante Architektur-Information ermöglicht eine Verifikation und Bestimmung, ob ein Quellcode eines Softwaresystems mit der beabsichtigten Struktur des Systems übereinstimmt bzw. konform ist. Der Vergleich der Code-Architektur mit der geplanten Architektur ermöglicht ferner eine Analyse und Anzeige der Einflüsse, die Änderungen im Quellcode auf die Struktur des Softwaresystems haben könnten.
  • Ferner wurden industrielle Softwareentwicklungsorganisationen beobachtet, um ein praktisches Problem zu identifizieren. In einer Erhebung, die mehrere Anwendungsbereiche abdeckte, konnte gezeigt werden, dass die Entwicklung von Softwareimplementierungen zeitaufwendig und arbeitsintensiv ist. Ein gemeinsamer Faktor, den alle analysierten Softwareimplementierungen gemeinsam hatten, war der Mangel an Konformität, was für die Entwicklungsorganisation einen wesentlichen Mehraufwand verursacht beim Erreichen ihrer Entwicklungsziele oder beim Anwenden von Umgestaltungs- bzw. Refaktorierungs- oder Umstrukturierungsprojekten, um die Implementierung zu reparieren.
  • Die Kontextfaktoren, die die Probleme beeinflussen, werden analysiert, um das darunterliegende wissenschaftliche Problem zu identifizieren und es in Einzelheiten zu untersuchen. Es wurden drei Wiederholungen eines gesteuerten Experiments durchgeführt, mit Konformität als einzigem veränderlichen Faktor. Das Lösen einer beispielhaften Entwicklungsaufgabe für die Variante, die Strukturverletzungen umfasste, führte zu Aufwandsdaten, die zweimal höher (204%) waren im Vergleich zur Lösung der gleichen Aufgabe für die konforme Variante.
  • Ein generelles Problem in der industriellen Softwareentwicklung ist somit, dass das Überprüfen und die Korrektur einer Regeltreue einer Implementierung einer Software-Architektur üblicherweise mit einem großen Zeit- und Arbeitsaufwand verbunden ist.
  • Die Aufgabe der vorliegenden Erfindung besteht darin, ein Konzept zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur zu schaffen, das ein effiziente Implementierung einer Software-Architektur mit Konformität ermöglicht.
  • Diese Aufgabe wird durch ein Verfahren nach Anspruch 1, ein System nach Anspruch 13 oder ein Computerprogramm nach Anspruch 16 gelöst.
  • Ausführungsbeispiele der Erfindung schaffen ein Verfahren zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur in Echtzeit. Dabei wird zunächst ein Ausgangs-Strukturmodell einer Software-Architektur bereitgestellt, so dass das Ausgangs-Strukturmodell die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt. Dann wird eine Abbildungsvorschrift bereitgestellt, so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung in Rückrichtung definiert ist. Dann wird ein Delta-Quellcodeteil empfangen, der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist. Dann wird ein Delta-Quellcodemodell ermittelt basierend auf dem Delta-Quellcodeteil, so dass das Delta-Quellcodemodell Abhängigkeiten, die in dem Delta-Quellcodeteil enthalten sind, beschreibt. Dann wird ein Delta-Strukturmodell ermittelt, das gegenüber dem Ausgangs-Strukturmodell verändert ist, basierend auf dem Delta-Quellcodemodell unter Verwendung der Abbildungsvorschrift, so dass das Delta-Strukturmodell die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteil veränderten Delta-Quellcodeteil definiert ist, beschreibt. Schließlich wird das Delta-Strukturmodell mit einem Referenz-Strukturmodell verglichen, um ein Vergleichsergebnis zu erhalten, das eine Regeltreue des Delta-Quellcodeteils oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Delta-Quellcodeteil umfasst, beschreibt. Hierbei wird bei dem Ermitteln des Delta-Quellcodemodells, bei dem Ermitteln des Delta-Strukturmodells oder bei dem Vergleichen des Delta-Strukturmodells mit dem Referenz-Strukturmodell eine Neubestimmung von Information, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil unabhängig ist, selektiv unterdrückt oder vermieden.
  • Der Kerngedanke der vorliegenden Erfindung ist, dass die oben genannte effiziente Implementierung einer Software-Architektur mit Konformität erreicht werden kann, wenn beim Überprüfen einer Regeltreue der Implementierung ein Delta-Quellcodeteil, der gegenüber einem entsprechenden Ausgangs-Quellcodeteil eines Software-Projekts verändert ist, empfangen wird und eine Neubestimmung von Information, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil unabhängig ist, selektiv unterdrückt oder vermieden wird. Dadurch kann der Zeit- und Arbeitsaufwand für das Überprüfen der Regeltreue verringert werden, was eine effiziente Implementierung einer Software-Architektur mit Konformität ermöglicht.
  • Bei weiteren Ausführungsbeispielen der Erfindung kann das Ermitteln des Delta-Quellcodemodells, das Ermitteln des Delta-Strukturmodells und das Vergleichen des Delta-Strukturmodells mit dem Referenz-Strukturmodell ansprechend auf ein Speichern eines einzigen Delta-Quellcodeteils erfolgen, während sich andere Quellcodeteile in Bearbeitung befinden. Somit kann ein Software-Entwickler unabhängig von der Quellcodebearbeitung anderer Software-Entwickler eine sofortige Rückmeldung des Vergleichsergebnisses empfangen.
  • Weitere Ausführungsbeispiele der Erfindung schaffen ein System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur. Dabei weist das System zum Überprüfen der Regeltreue einen Ausgangs-Strukturmodell-Bereitsteller, einen Abbildungsvorschrift-Bereitsteller, eine Verarbeitungseinrichtung und eine Ausgabe-Einrichtung auf. Der Ausgangs-Strukturmodell-Bereitsteller ist ausgelegt, um ein Ausgangs-Strukturmodell einer Software-Architektur bereitzustellen, so dass das Ausgangs-Strukturmodell die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt. Der Abbildungsvorschrift-Bereitsteller ist ausgelegt, um eine Abbildungsvorschrift bereitzustellen, so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung in Rückrichtung definiert ist. Die Verarbeitungseinrichtung ist ausgelegt, um einen Delta-Quellcodeteil zu empfangen, der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist. Die Verarbeitungseinrichtung ist ferner ausgelegt, um ein Delta-Quellcodemodell zu ermitteln basierend auf dem Delta-Quellcodeteil, so dass das Delta-Quellcodemodell Abhängigkeiten, die in dem Delta-Quellcodeteil enthalten sind, beschreibt. Die Verarbeitungseinrichtung ist ferner ausgelegt, um ein Delta-Strukturmodell zu ermitteln, das gegenüber dem Ausgangs-Strukturmodell verändert ist, basierend auf dem Delta-Quellcodemodell unter Verwendung der Abbildungsvorschrift, so dass das Delta-Strukturmodell die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteil veränderten Delta-Quellcodeteil definiert ist, beschreibt. Schließlich ist die Verarbeitungseinrichtung ausgelegt, um das Delta-Strukturmodell mit einem Referenz-Strukturmodell zu vergleichen, um ein Vergleichsergebnis zu erhalten, das eine Regeltreue des Delta-Quellcodeteils oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Delta-Quellcodeteil umfasst, beschreibt. Hierbei wird bei dem Ermitteln des Delta-Quellcodemodells, bei dem Ermitteln des Delta-Strukturmodells oder bei dem Vergleichen des Delta-Strukturmodells mit dem Referenz-Strukturmodell eine Neubestimmung von Information, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil unabhängig ist, selektiv unterdrückt oder vermieden. Dadurch können wiederum die oben genannten Vorteile bei der Implementierung erreicht werden. Die Ausgabe-Einrichtung ist ausgelegt, um das Vergleichsergebnis gegenüber einem Software-Entwickler auszugeben.
  • Bei weiteren Ausführungsbeispielen der Erfindung kann das System durch eine Client-Server-Client-Implementierung realisiert sein. Insbesondere kann dabei der Ausgangs-Strukturmodell-Bereitsteller durch einen ersten Client, die Verarbeitungseinrichtung durch einen Server und die Ausgabe-Einrichtung in einem zweiten Client implementiert sein. Dadurch kann einerseits eine Verteilung der Rollen geschaffen werden, so dass der Ausgangs-Strukturmodell-Bereitsteller, die Verarbeitungseinrichtung und die Ausgabe-Einrichtung jeweils getrennt und unabhängig voneinander auf dem ersten Client, dem Server und dem zweiten Client ausgeführt werden können, und andererseits kann dadurch das System beispielsweise als SAVE (Softwarearchitekturvisualisierung) Plug-In (Programmerweiterung) in der Entwicklungsumgebung Eclipse integriert werden.
  • Ausführungsbeispiele der Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Figuren, in denen gleiche oder gleichwirkende Elemente mit gleichen Bezugszeichen bezeichnet sind, näher erläutert. Es zeigen:
  • 1 ein Flussdiagramm eines Verfahrens zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur in Echtzeit gemäß einem Ausführungsbeispiel der Erfindung;
  • 2 eine schematische Darstellung eines Systems zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur gemäß einem Ausführungsbeispiel der Erfindung;
  • 3 eine schematische Darstellung einer erfindungsgemäßen Client-Server-Client-Implementierung;
  • 4 eine schematische Darstellung einer analytischen Konformitätsprüfung gemäß dem Stand der Technik;
  • 5 eine schematische Darstellung einer erfindungsgemäßen konstruktiven Konformitätsprüfung;
  • 6 eine schematische Darstellung einer Prozessübersicht einer erfindungsgemäßen konstruktiven Konformitätsprüfung;
  • 7 eine schematische Darstellung des Entwurfsprozessteils der in 6 gezeigten konstruktiven Konformitätsprüfung;
  • 8 eine schematische Darstellung des Codierprozessteils der in 6 gezeigten konstruktiven Konformitätsprüfung;
  • 9 eine schematische Darstellung des Konformitätsprüfungsprozessteils der in 6 gezeigten konstruktiven Konformitätsprüfung;
  • 10. eine schematische Darstellung konzeptioneller Bausteine eines SAVE LiFe (Softwarearchitekturvisualisierung mit direktübertragener Rückmeldung) Werkzeugs;
  • 11. eine schematische Darstellung einer konzeptionellen Ansicht von SAVE LiFe und SAVE;
  • 12 eine schematische Darstellung eines erfindungsgemäßen ersten Clients (SAVE LiFe Architekturverwalter);
  • 13 eine schematische Darstellung eines erfindungsgemäßen Servers (SAVE LiFe Konformitätsprüfer als erweiterbare Analyse- und Kommunikationsplattform);
  • 14 eine schematische Darstellung eines erfindungsgemäßen zweiten Clients (SAVE LiFe Entwicklungsüberwachungseinrichtung);
  • 15 eine schematische Darstellung eines Metamodells der Strukturansicht;
  • 16 eine schematische Darstellung eines Metamodells des Quellcodes;
  • 17 eine schematische Darstellung eines Metamodells der Abbildung; und
  • 18 eine schematische Darstellung eines Reflexionsmodellbeispiels: Strukturmodell (links), Quellcodemodell (Mitte) und Konformitätsprüfungsergebnisse (rechts).
  • 1 zeigt ein Verfahren 100 zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur in Echtzeit gemäß einem Ausführungsbeispiel der Erfindung. Das Verfahren 100 weist beispielsweise die folgenden Schritte auf.
  • Zunächst wird ein Ausgangs-Strukturmodell 115 einer Software-Architektur bereitgestellt (Schritt 110), so dass das Ausgangs-Strukturmodell 115 die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt. Dann wird eine Abbildungsvorschrift 125 bereitgestellt (Schritt 120), so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung in Rückrichtung definiert ist. Dann wird ein Delta-Quellcodeteil 135 empfangen (Schritt 130), der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist. Dann wird ein Delta-Quellcodemodell 145 ermittelt (Schritt 140) basierend auf dem Delta-Quellcodeteil 135, so dass das Delta-Quellcodemodell 145 Abhängigkeiten, die in dem Delta-Quellcodeteil 135 enthalten sind, beschreibt. Dann wird ein Delta-Strukturmodell 155 ermittelt (Schritt 150), das gegenüber dem Ausgangs-Strukturmodell 115 verändert ist, basierend auf dem Delta-Quellcodemodell 145 unter Verwendung der Abbildungsvorschrift 125, so dass das Delta-Strukturmodell 155 die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteil veränderten Delta-Quellcodeteil 135 definiert ist, beschreibt. Schließlich wird da Delta-Strukturmodell 155 mit einem Referenz-Strukturmodell 105 verglichen (Schritt 160), um ein Vergleichsergebnis 165 zu erhalten, das eine Regeltreue des Delta-Quellcodeteils 135 oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Delta-Quellcodeteil 135 umfasst, beschreibt. Hierbei wird bei dem Ermitteln (Schritt 140) des Delta-Quellcodemodells 145, bei dem Ermitteln (Schritt 150) des Delta-Strukturmodells 155 oder bei dem Vergleichen (Schritt 160) des Delta-Strukturmodells 155 mit dem Referenz-Strukturmodell 105 eine Neubestimmung von Information, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil 135 unabhängig ist, selektiv unterdrückt oder vermieden.
  • Insbesondere kann bei weiteren Ausführungsbeispielen der Erfindung das Ermitteln (Schritt 140) des Delta-Quellcodemodells 145, das Ermitteln (Schritt 150) des Delta-Strukturmodells 155 und das Vergleichen (Schritt 160) des Delta-Strukturmodells 155 mit dem Referenz-Strukturmodell 105 ansprechend auf ein Speichern eines einzigen Delta-Quellcodeteils 135 erfolgen, während sich andere Delta-Quellcodeteile in Bearbeitung befinden. Dadurch kann ein Software-Entwickler unabhängig von der Quellcodebearbeitung anderer Software-Entwickler eine sofortige Rückmeldung des Vergleichsergebnisses 165 empfangen.
  • 2 zeigt eine schematische Darstellung eines Systems 200 zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur gemäß einem Ausführungsbeispiel der Erfindung. Das System 200 weist einen Ausgangs-Strukturmodell-Bereitsteller 210, einen Abbildungsvorschrift-Bereitsteller 220, eine Verarbeitungseinrichtung 230 und eine Ausgabe-Einrichtung 240 auf. Der Ausgangs-Strukturmodell-Bereitsteller 210 ist ausgelegt, um ein Ausgangs-Strukturmodell 115 einer Software-Architektur bereitzustellen (Schritt 110), so dass das Ausgangs-Strukturmodell 115 die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt. Der Abbildungsvorschrift-Bereitsteller 220 ist ausgebildet, um eine Abbildungsvorschrift 125 bereitzustellen (Schritt 120), so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung in Rückrichtung definiert ist. Die Verarbeitungseinrichtung 230 ist ausgebildet, um einen Delta-Quellcodeteil 135 zu empfangen (Schritt 130), der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist. Die Verarbeitungseinrichtung 230 ist ferner ausgebildet, um ein Delta-Quellcodemodell 145 zu ermitteln (Schritt 140) basierend auf dem Delta-Quellcodeteil 135, so dass das Delta-Quellcodemodell 145 Abhängigkeiten, die in dem Delta-Quellcodeteil 135 enthalten sind, beschreibt. Die Verarbeitungseinrichtung 230 ist ferner ausgebildet, um ein Delta-Strukturmodell 155 zu ermitteln (Schritt 150), das gegenüber dem Ausgangs-Strukturmodell 115 verändert ist, basierend auf dem Delta-Quellcodemodell 145 unter Verwendung der Abbildungsvorschrift 125, so dass das Delta-Strukturmodell 155 die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteil veränderten Delta-Quellcodeteil 135 definiert ist, beschreibt. Schließlich ist die Verarbeitungseinrichtung 230 ausgebildet, um das Delta-Strukturmodell 155 mit einem Referenz-Strukturmodell 105 zu vergleichen (Schritt 160), um ein Vergleichsergebnis 165 zu erhalten, das eine Regeltreue des Delta-Quellcodeteils 135 oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Delta-Quellcodeteil 135 umfasst, beschreibt. Hierbei wird bei dem Ermitteln (Schritt 140) des Delta-Quellcodemodells 145, bei dem Ermitteln (Schritt 150) des Delta-Strukturmodells 155 oder bei dem Vergleichen (Schritt 160) des Delta-Strukturmodells 155 mit dem Referenz-Strukturmodell 105 eine Neubestimmung von Information, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil 135 unabhängig ist, selektiv unterdrückt oder vermieden. Die Ausgabe-Einrichtung 240 ist ausgebildet, um das Vergleichsergebnis 165 gegenüber einem Software-Entwickler auszugeben.
  • 3 zeigt eine schematische Darstellung einer erfindungsgemäßen Client-Server-Client-Implementierung 300. Bei Ausführungsbeispielen der Erfindung kann der Ausgangs-Strukturmodell-Bereitsteller 210 durch einen ersten Client 310, die Verarbeitungseinrichtung 230 durch einen Server 320 und die Ausgabe-Einrichtung 240 in einem zweiten Client 330 implementiert sein. Dabei kann die Ausgabe-Einrichtung 240 beispielsweise einen Bildschirm oder einen Drucker 340 aufweisen, so dass das Vergleichsergebnis 165 beispielsweise in einem Quellcodeeditor gegenüber einem Software-Entwickler dargestellt wird.
  • 5 zeigt eine schematische Darstellung einer erfindungsgemäßen konstruktiven Konformitätsprüfung 500 und deren Funktionsweise. Um die Anforderungen und Beschränkungen zu verstehen, die durch die konstruktive Konformitätsprüfung 500 auferlegt werden, wird dieselbe von der in 4 gezeigten analytischen Konformitätsprüfung 400 abgegrenzt. Im Gegensatz zu der analytischen Konformitätsprüfung 400 gibt es bei der konstruktiven Konformitätsprüfung 500 jedoch nur zwei Phasen 510, 520, die der Architektur (Phase 510) und der Implementierung (Phase 520).
  • Wie in 5 gezeigt, ist die Architekturphase 510 die gleiche wie bei der analytischen Konformitätsprüfung aus 4. Das Strukturmodell 515 ist die Eingabe für die nachfolgende Phase 520. Hierbei entsprechen die Phasen 510 und das Strukturmodell 515 im Wesentlichen der Phase 410 bzw. dem Strukturmodell 415. In der Implementierungsphase 520, die beispielsweise mit direkt übertragener (Live) Analyse und Direktkommunikation angereichert ist, erzeugen, wie bei der analytischen Konformitätsprüfung 400, Entwickler 403 Quellcode 521-1, 521-2, 521-3 auf der Basis des Strukturmodells 515. Aber im Gegensatz dazu ist die Implementierungsphase 520 angereichert mit einer Liveanalyse aller Deltas 523-1, 523-2, 523-3 (d. h. des eben geschriebenen Codes) und einer Direktkommunikation über Verletzungen 527-1, 527-2, 527-3 an die Entwickler 403, die dieselben verursachen (d. h. direkt übertragene („Live”) Rückmeldung an den Verursacher). Weil sie sofortige Rückmeldungen („Feedback”) empfangen, sind die Entwickler 403 in der Lage, direkt zu reagieren. Sie sind noch mit dem aktuellen Kontext beschäftigt (d. h. sie arbeiten noch an der gleichen Aufgabe und haben soeben die verletzenden Quellcodezeilen geschrieben). Somit können sie die Struktur mit minimalem bzw. beinahe ohne Aufwand sofort reparieren. Anders ausgedrückt, die Konformitätsprüfung 525-1, 525-2, 525-3 und die Korrektur geschehen, während die Entwickler 403 implementieren. Somit werden die Entwickler 403 fortlaufend über die Architektur geschult und trainiert. Die Zeichenerklärung (Legende) der 5 entspricht im Übrigen derjenigen aus 4.
  • 6 zeigt eine schematische Darstellung einer Prozessübersicht einer erfindungsgemäßen konstruktiven Konformitätsprüfung 600. Insbesondere ist dabei der Prozess zum Erreichen von architekturkonformen Implementierungen von Softwaresystemen dargestellt. Bei Ausführungsbeispielen der Erfindung umfasst er drei Prozessteile: Entwerfen 611, Codieren 631 und Konformitätsprüfung 621. Das Entwerfen 611 und Codieren 631 werden durch Architekten 610 bzw. Entwickler 630 ausgeführt, während die Konformitätsprüfung 621 ein Vorgang ist, der durch einen der anderen zwei Prozessteile ausgelöst wird und dann eine Sequenz von vollständig automatischen Aktivitäten ausführt.
  • Bei weiteren Ausführungsbeispielen der Erfindung besteht der Prozess, der die Prinzipien der konstruktiven Konformitätsprüfung 600 realisiert, aus zwei locker gekoppelten Schleifen. Die erste Schleife wird durch die (typischerweise wenigen) Architekten 610 ausgeführt, während die zweite Schleife durch die typischerweise vielen Entwickler 630 (oder mehrere Entwicklerteams) ausgeführt wird. Die lockere Kopplung entsteht aufgrund der Tatsache, dass die Architektur, die durch Architekten 610 verwaltet wird, für die Codierung 631 eingegeben wird, die durch die Entwickler 630 ausgeführt wird. Beide Schleifen werden fortlaufend ausgeführt (d. h. die ganze Zeit, während die Entwicklung läuft) und ständig (d. h. jedes Mal, wenn eine Änderung durchgeführt wird, entweder an der Architektur oder an dem Quellcode). Folglich wird der Prozessteil für Konformitätsprüfung 621 ebenfalls fortlaufend und ständig ausgelöst.
  • Eine Schleife des Architekten 610 wird beispielsweise über vier Aktivitäten (Schritte 613, 615, 617, 619) wiederholt (iterativ) durchgeführt.
  • Bei dem Schritt des Entwerfen 613 entwerfen Architekten 610 gemäß ihrer Natur das Softwaresystem bzw. Software-Projekt. Sie definieren, dokumentieren und entwickeln die grundlegende Organisation des Softwaresystems. Die Abstraktionen, die durch die Architektur bereitgestellt werden, ermöglichen die effiziente Entwicklung des Softwaresystems. Sobald eine Iteration der Architektur abgeschlossen und konsolidiert wurde, kann die Architektur kommuniziert werden. Das Entwerfen (Schritt 613) hört jedoch nie wirklich auf. Aufgrund neuer oder sich ändernder Anforderungen, Geschäftsziele oder Organisationsaufgaben entwickelt sich die Architektur, solange das System lebt.
  • Bei dem Schritt des Kommunizieren 615 der Architektur kommunizieren Architekten 610 die Architektur entweder verbal oder über Dokumentation an die Entwickler 630. Die Entwickler 630 verwenden die Architektur (und zusätzliche Informationsquellen, wie z. B. Anforderungen), um den Codierungsprozess zu beginnen.
  • Bei dem Schritt des Veröffentlichen 617 der Architektur veröffentlichen Architekten 610 die neueste Stufe der Architektur (insbesondere ihre sogenannte Strukturansicht) für den Konformitätsprüfer 620. Ab diesem Punkt ist Konformitätsprüfung 621 aktiv und kann Entwickler 630 mit konstruktiver Liverückmeldung unterstützen.
  • Bei dem Schritt des Veröffentlichen 619 des Konformitätsstatus veröffentlicht der Konformitätsprüfer 620 den Konformitätsstatus auf Nachfrage. Architekten 610 können die Konformität als eine wesentliche Qualität verfolgen und können auf den Gesamt-Konformitätsstatus des Systems zugreifen. Der Konformitätsprüfer 620 ermöglicht das Veröffentlichen 619 des Konformitätsstatus. Der Gesamt-Konformitätsstatus des Systems umfasst die Bewertung des neuesten Zustands des vollständigen Quellcodes. Der Architekt 610 kann hochentwickelte graphische Visualisierungskonzepte verwenden, um den Status aus der Sicht eines globalen Systems zu analysieren und die Konformitätsprüfungsergebnisse zu navigieren. Falls notwendig, entwerfen und führen die Architekten Verfeinerungen durch aufgrund von wiederkehrenden Konformitätsproblemen. Das Integrieren solcher Verfeinerungen startet einen weiteren Entwurfszyklus, der schließlich zu einer Aktualisierung der veröffentlichten Architektur führt. Somit führen Entwickler 630 den Codierungsprozess 631 immer nur gegenüber der neuesten veröffentlichten Version der Architektur aus.
  • Die Schleife der Entwickler 630 wiederholt sich ebenfalls beispielsweise über die folgenden vier Aktivitäten (Schritte 633, 635, 637, 639). Im Gegensatz zu den grobkörnigen Aktivitäten der Architekten 610 sind die Aktivitäten der Entwickler 630 feinkörnig und werden individuell von jedem einzelnen Entwickler selbst ausgeführt.
  • Bei dem Schritt des Codieren 633 codieren Entwickler 630 die Quellcodedateien der Implementierung. Sie schreiben Anweisungen unter Verwendung der Konstrukte, die von der Programmiersprache angeboten werden, die Lösungsideen in Algorithmen und Datenstrukturen transformiert. Aller Quellcode zusammengenommen realisiert schließlich das Softwaresystem wie vorgegeben (falls alles gut funktioniert). Eingabe für den Codierprozess (Schritt 633) ist die Architektur, die die beabsichtigte Strukturunterteilung in Komponenten und die Beziehungen zwischen denselben vorschreibt.
  • Bei dem Schritt des Sendens 635 von Deltas senden Entwickler 630 das Delta bzw. den Delta-Quellcodeteil an den Konformitätsprüfer 620. Jede Modifikation, die durch irgendeinen Entwickler 630 durchgeführt wird, wird an den Konformitätsprüfer 620 weitergeleitet, aber anstatt den gesamten Quellcode zu senden, wird nur das lokal geänderte Delta des Entwicklers 630 weitergeleitet, während anderer unveränderter Quellcode ignoriert wird. Das Senden (Schritt 635) geänderter Deltas wird automatisch ausgelöst und durchgeführt (d. h. ohne direkte Beteilung des Entwicklers 630), basierend auf Ereignissen in der integrierten Entwicklungsumgebung.
  • Bei dem Schritt des Sendens 637 von Liverückmeldung empfangen Entwickler 630 Liverückmeldung, die durch den Konformitätsprüfer 621 gesendet wird, über die Verletzungen, die in dem weitergeleiteten Delta enthalten sind. Falls es keine Verletzungen gibt, können die Entwickler 630 ohne Unterbrechung fortfahren. Anderenfalls werden die Verletzungen in dem Quellcodeeditor sanft hervorgehoben. Dadurch wird die Rückmeldung auf die einzelnen Entwickler 630 zugeschnitten und fokussiert nur auf ihren lokalen Gültigkeitsbereich (d. h. richtet sich an die Entwickler, die gerade die geänderten Deltas übermittelt haben). Die schnelle Antwortzeit liefert die Ergebnisse, während die Entwickler 630 die gleichen Quellcodefragmente bearbeiten. Ihre Gedanken sind noch im gleichen Kontext, was das sofortige Korrigieren der Verletzungen ermöglicht.
  • Bei dem Schritt des Korrigieren 639 korrigieren Entwickler 630 die Strukturverletzungen, was äquivalent ist zum Schreiben von Quellcode. Somit bilden die eben geschriebenen oder modifizierten Anweisungen automatisch das nächste Delta, das zu dem Konformitätsprüfer 620 weiterzuleiten ist. Potenzielle Nebeneffekte der Korrektur, die erneut Strukturverletzungen verursachen, werden sofort erfasst, weil der Konformitätsprüfer 620 sofort verarbeitet. Anders ausgedrückt, die Korrektur ist äquivalent zum Schreiben von Quellcode, aber mit dem Zweck des Erreichen von Konformität, was somit einen weiteren Zyklus des Codierprozessteils 631 auslöst.
  • Im Folgenden werden die Prozessteile Entwerfen 611, Codieren 631 und Konformitätsprüfung 621 näher beschrieben. Im Übrigen weisen in 6 Mitteilungen, die zwischen Konformitätsprüfung 621 und Entwerfen 611 bzw. Codieren 631 ausgetauscht werden, unterschiedliche Größen auf. Während die Schritte des Veröffentlichen 617, 619 für Lange-Mitteilungen-Übertragungsmodelle stehen, stellen die Schritte des Sendens 635, 637 eher kurze Mitteilungen dar. Ferner zeigt die Zeichenerklärung 601 der 6 die entsprechenden Symbole für Akteur 602, Prozessteil 603, Aktivität 604, Informationsfluss 605, Arbeitsprodukt 606 und Dokument 607 an.
  • 7 zeigt eine schematische Darstellung des Entwurfsprozessteils 700 der in 6 gezeigten konstruktiven Konformitätsprüfung 600. Dabei entspricht der Entwurfsprozessteil 700 aus 7 im Wesentlichen dem Entwurfsprozessteil 611 aus 6. Bei Ausführungsbeispielen der Erfindung umfasst der Entwurfsprozessteil 700 den Zyklus von Aktivitäten 604, die nur durch Architekten 610 durchgeführt werden (siehe 7). Alle Aktivitäten 604 bzw. Verfahrensschritte arbeiten nur auf architekturbezogenen Arbeitsprodukten 606 und werden offensichtlich durch den Architekten 610 durchgeführt. Der Einfachheit halber wurden andere Lebenszyklusphasen ignoriert (z. B. Konstruktionsanforderung).
  • 7 listet beispielhaft sieben Aktivitäten auf, die durch den Architekten 610 durchgeführt werden. Während die ersten zwei Aktivitäten, d. h. das Entwerfen (Schritt 613) und Kommunizieren (Schritt 615) der Architektur 710, den regelmäßigen Arbeitsfluss von Architekten 610 darstellen, sind alle anderen Aktivitäten Erweiterungen, die insbesondere eingeführt wurden, um konstruktive Konformitätsprüfung zu ermöglichen. Der Entwurfsprozessteil 700 weist beispielsweise die folgenden Schritte auf.
  • Die Schritte des Entwerfen 613 und des Kommunizieren 615 der Architektur 710 entsprechen im Wesentlichen denjenigen der in 6 beschriebenen.
  • Bei dem Schritt des Formalisieren 715 des Strukturmodells formalisiert der Architekt 610, um die Konformitätsprüfung 621 zu ermöglichen, die Architektur 710, was zu dem Strukturmodell 720 führt. Falls dies zum ersten Mal ausgeführt wird, wird das Modell erzeugt, während später (optional) Erweiterungen dieser Aktivität nur geringe Verfeinerungen ergeben.
  • Bei dem Schritt des Definieren 725 der Abbildung definieren die Architekten 610 die Abbildung 730, die das Strukturmodell 720 mit dem Quellcode verbindet. Falls dies zum ersten Mal ausgeführt wird, muss der Architekt 610 die Abbildung 730 vollständig definieren. Daher ist es nötig, dass der Architekt 610 Kenntnis über das Quellcodemodell hat. Spätere Ausführungen dieser Aktivität sind optional und führen typischerweise zu Verfeinerungen aufgrund von Änderungen in der Hierarchie des Quellcodemodells oder neuer Quellcodeelemente. Sobald das System reift, ist diese Aktivität eher optional.
  • Bei dem Schritt des Veröffentlichen 617 der Architektur wird bzw. werden die Architektur 710 (d. h. das Strukturmodell 720 und die Abbildung 730) wie im Vorhergehenden beschrieben, veröffentlicht.
  • Bei dem Schritt des Anfordern 735 des Konformitätsstatus fordert der Architekt 610 den Gesamtstatus von dem Konformitätsprüfer 620 an. Der Konformitätsstatus 740 enthält die Sammlung aller Deltas, die seit dem Beginn der Entwicklung hergestellt wurden (d. h. den neuesten Zustand des Quellcodes). Der veröffentlichte Konformitätsstatus 740 wird dem Architekten 610 auf Nachfrage verfügbar gemacht.
  • Bei dem Schritt des Überprüfen 745 des Konformitätsstatus überprüft der Architekt 610 dann den Konformitätsstatus 740. Abhängig von dem Status fährt der Architekt 610 entweder mit dem nächsten Architekturzyklus fort oder fordert eine Aktualisierung des Konformitätsstatus 740 zu einem späteren Zeitpunkt an. Die Zeichenerklärung der 7 entspricht im Übrigen derjenigen aus 6.
  • 8 zeigt eine schematische Darstellung des Codier- bzw. Codierungsprozessteils 800 der in 6 gezeigten konstruktiven Konformitätsprüfung 600. Der Codierungsprozessteil 800 der 8 entspricht im Wesentlichen dem Codierungsprozessteil 631 aus 6. Bei Ausführungsbeispielen der Erfindung umfasst der Codierungsprozessteil 800 den Zyklus von Aktivitäten 604, die nur von Entwicklern 630 durchgeführt werden (siehe 8). Alle Aktivitäten 604 arbeiten nur auf quellcodebezogenen Arbeitsprodukten 606. Die einzige Ausnahme ist die Architektur 710, die als die Gesamtvorgabe für alle Codieraktivitäten wirkt. Der Codierprozessteil 800 wird durch jeden Entwickler 630 durchgeführt, der Quellcode 810 schreibt. Der Einfachheit halber wurden hier andere Lebenszyklusphasen (z. B. Testen) ignoriert.
  • 8 listet beispielhaft sechs Aktivitäten auf, die durch Entwickler 630 durchgeführt werden. Während die erste Aktivität, d. h. das Codieren (Schritt 633), den regelmäßigen Arbeitsfluss von Entwicklern 630 darstellt, sind alle anderen Aktivitäten Erweiterungen, die insbesondere eingeführt werden, um konstruktive Konformitätsprüfung 621 zu ermöglichen. Der Codierungsprozessteil 800 weist beispielsweise die folgenden Schritte auf.
  • Der Schritt des Codierens 633 von Quellcode 810 erfolgt wie im Vorhergehenden beschrieben.
  • Bei dem Schritt des Bestimmens 815 des lokalen Delta schreibt der Entwickler 630 Quellcode, und der lokale Gültigkeitsbereich wird automatisch bestimmt. Der Gültigkeitsbereich umfasst die lokal geänderten Kompilierungseinheiten, d. h. das Delta 820 oder die Hinzufügung bezüglich Quellcode, die eben durch den Entwickler 630 erzeugt wurden. Die Bestimmung verwendet Merkmale der integrierten Entwicklungsumgebung, um lokal geänderte Kompilierungseinheiten zu überwachen und zu verfolgen. Bei bestimmten einzelnen Ereignissen (z. B. Speichern einer Kompelierungseinheit, Übertragen an das Konfigurationsverwaltungssystem) wird die Deltabestimmung (Schritt 815) automatisch ausgelöst (d. h. ohne direkte Beteiligung des Entwicklers 630).
  • Der Schritt des Sendens 635 des Delta erfolgt auch wie im Vorhergehenden beschrieben.
  • Bei dem Schritt des Empfangen 825 von Liverückmeldung empfangen die Entwickler 630 direkt übertragene (Live) Konformitätsrückmeldung über ihre individuelle Modifikation durch den Konformitätsprüfer 620. Die Rückmeldung kann aufgrund der schnellen Antwortzeit als Live (direkt übertragen) angesehen werden (d. h. sofortige Rückmeldung). Im Gegensatz zu der analytischen Technik liefert die konstruktive Konformitätsprüfung, wie beispielsweise in 5 gezeigt, die Ergebnisgrößen schneller aufgrund der Begrenzung der Tatsachenextrahierung, Erhebung und Prüfung auf nur das Delta. Die Liverückmeldung wird automatisch empfangen durch die integrierte Entwicklungsumgebung und ohne Interaktion mit den Entwicklern 630. Die empfangenen Ergebnisse umfassen den Satz von Verletzungen, die für das gesendete Delta 820 relevant sind (d. h. die lokal modifizierten Kompilierungseinheiten).
  • Bei dem Schritt des Anzeigen 835 von Deltaergebnissen 830 liefert die Liverückmeldung den Entwicklern 630 die Ergebnisse der Konformitätsprüfung. Die integrierte Entwicklungsumgebung zeigt die Verletzungen in dem Quellcodeeditor auf sanfte Weise an (d. h. unaufdringlich, nicht störend, aber trotzdem angemessen). Die Präsentation der Ergebnisse ermöglicht es Entwicklern 630, die Strukturverletzungen und ihren Kontext wahrzunehmen (d. h. welche Anweisungen verursacht die Verletzungen, welche Art von Verletzung liegt vor und in welchen Architekturelementen sind Ursprung und Ziel enthalten). Das Wahrnehmen der Ergebnisse erhöht die Bewusstheit von Entwicklern 630 und befähigt sie, durch Korrigieren der Verletzungen eine architekturkonforme Implementierung zu erreichen.
  • Der Schritt des Korrigierens 639 erfolgt schließlich wie im Vorhergehenden beschrieben. Ferner entspricht die Zeichenerklärung (Legende) der 8 derjenigen aus 6.
  • 9 zeigt eine schematische Darstellung des Konformitätsprüfungsprozessteils 900 der in 6 gezeigten Konformitätsprüfung 600. Der Konformitätsprüfungsprozessteil 900 der 9 entspricht im Wesentlichen der Konformitätsprüfung 621 aus 6. Insbesondere zeigt 9 den Konformitätsprüfungsprozessteil 900, der vollständig automatisch ist. Bei Ausführungsbeispielen der Erfindung hat die Konformitätsprüfung 900 zwei getrennte Eintrittstellen, eine ausgelöste durch Entwerfen (Schritt 611) und die andere ausgelöste durch Codieren (Schritt 631). Während die Eintrittstelle, die durch Entwerfen (Schritt 611) verwendet wird, ein einzelnes Element ist (d. h. die Architektur wird in einer zentralen Stelle verwaltet), kann die Eintrittstelle, die durch Entwickler 630 verwendet wird, viele Konformitätsprüfteile gleichzeitig parallel aktivieren.
  • Nachfolgend wird der Konformitätsprüfungsprozessteil 900 durch die Eintrittstellen beschrieben. Die Eintrittstelle, die von Architekten 610 verwendet wird, ist das Gegenstück der Aktivität „Veröffentlichen der Architektur” (Schritt 617), wie beispielsweise im Prozessteil „Entwerfen” 700 gezeigt. 9 zeigt beispielhaft die folgenden Aktivitäten.
  • Der Schritt des Empfangen 901 der veröffentlichten Architektur erfolgt wie im Vorhergehenden beschrieben.
  • Bei dem Schritt des Aktualisieren 905 des Strukturmodells wird das Strukturmodell 910 aktualisiert, basierend auf den Informationen, die durch den Architekten 610 veröffentlicht werden. Die vorhergehende Version des Modells wird ersetzt durch die neu veröffentlichte. Bei jeder Aktualisierung kann der Architekt 610 die Strukturunterteilung modifiziert oder verfeinert haben, an die sich die Entwickler 630 halten sollten. Als Nebeneffekt können sich Abhängigkeiten, die vorher konform waren, zu Verletzungen ändern, wenn eine Aktualisierung der Architektur veröffentlicht wird und umgekehrt. Ein Vorteil ist, dass Entscheidungen über die Struktur direkt an alle Entwickler 630 weitergeleitet werden, die von der überarbeiteten Entscheidung betroffen sind.
  • Bei dem Schritt des Aktualisierens 915 der Abbildung 920 kann es sein, dass der Architekt 610 neben dem Strukturmodell 910 auch die Abbildung 920 aktualisieren möchte. Erneut wird die vorhergehende Version der Abbildung durch die neu veröffentlichte ersetzt, und Entscheidungen werden ebenfalls sofort weitergeleitet.
  • Bei dem Schritt des Veröffentlichens 619 des Konformitätsstatus können die Architekten 610 zu jedem Zeitpunkt den Konformitätsstatus 950 anfordern. Diese Anforderung wird nach Anfrage ausgelöst und aktiviert den Konformitätsprüfer 620, um den aktuellen Status zu veröffentlichen, der das Gesamtergebnis der Konformitätsprüfung 621 umfasst, basierend auf dem neuesten Zustand des Quellcodemodells 940 (d. h. der Ansammlung aller Deltas). Der veröffentlichte Konformitätsstatus 950 ist dann die Basis für fundamentale Analysen oder Überprüfung durch die Architekten 610.
  • Die Eintrittsstelle, die durch Entwickler 630 verwendet wird, ist das Gegenstück der Aktivität „Senden von Delta” (Schritt 635), wie beispielsweise im Prozessteil „Codieren” 800 gezeigt. 9 zeigt beispielhaft die entsprechenden Aktivitäten.
  • Bei dem Schritt des Empfangen 903 von Delta empfängt der Konformitätsprüfer 620 das Delta, das durch den Entwickler 630 gesendet wird. Für jedes gesendete Delta handhabt ein neuer Zyklus des Konformitätsprüfers 620 die Verarbeitung des Deltas. Folglich können viele Deltas gleichzeitig verarbeitet werden, und Konformitätsprüfungsunterstützung für viele unterschiedliche Entwickler 630 wird bereitgestellt.
  • Bei dem Schritt des Extrahieren 925 von Deltatatsachen wird das Delta bzw. Deltamodell 930 (d. h. beispielsweise die Kompilierungseinheit, die Änderungen umfasst) der Tatsachenextraktion unterzogen, die das Delta nach relevanten Informationen durchsucht.
  • Bei dem Schritt des Aktualisieren 935 des Quellcodemodells aktualisiert der Konformitätsprüfer 620 den Quellcode 940, so dass derselbe den neuesten Quellcodezustand umfasst. Dabei wird die Historie des Modells beibehalten, die es ermöglicht, jeden Zustand wie bei einem Daumenkino zu durchsuchen.
  • Bei dem Schritt des Herausdestillierens 955 von Deltaverletzungen destilliert der Konformitätsprüfer 620 zum Vorbereiten der Antwort die Verletzungen als Teil der Deltaergebnisse 960 heraus, die durch das Delta verursacht werden, das von dem Entwickler 630 empfangen wird. Der Satz von Deltaverletzungen wird dann an den Verursacher zurückgesendet (Schritt 637).
  • Der Schritt des Sendens 637 von Liverückmeldung erfolgt wie im Vorhergehenden beschrieben.
  • Die grundlegendste und wesentlichste Aktivität der konstruktiven Konformitätsprüfung 900 ist selbstverständlich das Prüfen 945 der Konformität. Dasselbe ist zentral für beide Eintrittsstellen als auch am Wichtigsten für den Prozess (siehe 9). Es berechnet die tatsächlichen Ergebnisse, basierend beispielsweise auf der Reflexionsmodelltechnik. Bei Ausführungsbeispielen der Erfindung umfasst die Aktivität beispielsweise die folgenden sechs Schritte.
  • Zunächst wird bei dem Schritt des Anheben des Deltas das Deltamodell 930 als Teil des Quellcodemodells 940 angehoben unter Verwendung der Abbildung 920, was dazu führt, dass beide Modelle auf der gleichen Abstraktionsebene sind wie das Strukturmodell 910.
  • Dann wird bei dem Schritt des Vergleichens von Modellen der Konformitätsstatus 950 durch den Modellvergleich aktualisiert, basierend auf dem Strukturmodell 910, dem Quellcodemodell 940 und dem Deltamodell 930. Die Verfügbarkeit der Modelle mit spezifizierter Struktur und des implementierten Systems ermöglicht das Durchführen des Vergleichs. Der Konformitätsstatus 950 wird aktualisiert durch hinzugefügte, modifizierte oder gelöschte Modellelemente, während umgeänderte Elemente ihren Status beibehalten.
  • Dann werden bei dem Schritt des Berechnen von Konvergenzen Konvergenzen durch den Konformitätsprüfer berechnet. Dabei stellen Konvergenzen Abhängigkeiten dar, die so implementiert sind, wie es durch den Architekten 610 beabsichtigt ist.
  • Dann werden bei dem Schritt des Berechnen von Abweichungen Abweichungen durch den Konformitätsprüfer berechnet. Dabei stellen Abweichungen (Divergenzen) unerwünschte Abhängigkeiten dar, die in dem Delta enthalten sind, die durch Entwickler 630 verursacht wurden.
  • Schließlich werden bei dem Schritt des Berechnens von Abwesenheiten Abwesenheiten durch den Konformitätsprüfer berechnet. Dabei stellen Abwesenheiten beabsichtigte Abhängigkeiten dar, die aber (noch) nicht implementiert sind. Die Legende der 9 entspricht wiederum derjenigen aus 6.
  • Zusammenfassend gesagt ermöglicht das Ausführen aller drei Prozessteile 611, 621, 631 den Gesamtprozess für konstruktive Konformitätsprüfung. Der Prozess ist integriert in den regulären Arbeitsfluss von beiden Rollen, die durch neue spezielle Aktivitäten erweitert werden. Die Erweiterungen für die Architekten ermöglichen es denselben, die Konformität vom Tag 1 der Entwicklung an zu verfolgen, und zwar während der Implementierung und während der Entwicklung. Modifikationen an der Architektur werden zu der Konformitätsprüfung weitergeleitet, und somit empfangen Entwickler Informationen über sich ändernde Pläne für die Struktur. Sie implementieren immer gegenüber dem neuesten veröffentlichten Zustand der Architektur.
  • Die Erweiterungen für die Entwickler sind unaufdringlich, automatisch und integriert in die Entwicklungsumgebung. Bei Ausführungsbeispielen der Erfindung zeigt der Quellcodeeditor die Verletzungen in dem aktuellen Gültigkeitsbereich (d. h. die Deltas) an. Die Rückmeldung wird im Wesentlichen sofort (live) empfangen, während die Entwickler nach wie vor die gleichen oder nahegelegene Anweisungen bearbeiten. Entwickler müssen die Verletzungen „nur” wahrnehmen. Das Anzeigen in dem Editor erhöht die Bewusstheit des Entwicklers, ohne ihn von seiner aktuellen Aufgabe abzulenken. Und sobald er sich der Verletzungen bewusst ist, kann er sie sofort entfernen. Anders ausgedrückt, konstruktive Konformitätsprüfung hält die beabsichtige Struktur in den Implementierungen aufrecht und stellt Verfolgbarkeit zwischen Architektur und Quellcode sicher.
  • Bei Ausführungsbeispielen der Erfindung kann die konstruktive Konformitätsprüfung durch das Werkzeug SAVE LiFe realisiert werden. SAVE LiFe steht für Software Architecture Visulization and Evaluation with Life Feedback (Software-Architektur-Visualisierung und Auswertung mit Live-Rückmeldung). Der folgende Abschnitt führt die konzeptionelle Architektur des Werkzeugs ein.
  • SAVE Live 1010 besteht aus drei einzelnen logischen Bausteinen 1020, 1030, 1040, die in 10 dargestellt sind. Der Architekturverwalter 1020 ist verantwortlich für das Realisieren des Prozessteils, der für den Architekten 402 definiert ist, und die Entwicklungsüberwachungseinheit 1040 ist verantwortlich für den Codierprozessteil. Beide kommunizieren mit dem Konformitätsprüfer 1030, der den verbleibenden Prozessteil realisiert. Folglich sind die Rollen durch die Akteure Architekt 402 und Entwickler 403 dargestellt.
  • Die nächsten Unterabschnitte führen die konzeptionelle Ansicht und ihre Absichten für die unterschiedlichen Bausteine ein. Dann fahren wir damit fort, die verteilte Kommunikationsplattform zu erörtern und schließlich die Entwicklungsumgebungsintegration von SAVE LiFe 1000 zu zeigen. Die Legende 1001 der 10 zeigt die entsprechenden Symbole für Baustein 1002, Akteur 1003, Datenspeicher 1004 und Informationsfluss 1005.
  • Die konzeptionelle Ansicht ist die abstrakteste Architekturansicht, die zum Erfassen des Anwendungsbereichs verwendet wird, durch Abbilden der Funktionalität des Systems auf konzeptionelle Komponenten und Zeigen von Datenspeichern, externen Schnittstellen und Hardwaregeräten. Sie zeigt auch die Beziehungen zwischen den konzeptionellen Elementen. 11 zeigt die konzeptionelle Ansicht 1100 der SAVE-Produktlinienarchitektur („Fraunhofer SAVE – Software Architecture Visualization and Evaluation = Softwarearchitekturvisualisierung und Auswertung”), die (teilweise oder vollständig) für jeden SAVE-Analysator instantiiert wird, während Tabelle 1 und Tabelle 2 die konzeptionellen Komponenten und Datenspeicher beschreiben.
    konzeptionelle Komponente Verantwortlichkeit
    Visualisierung Die konzeptionelle Komponente Visualisierung ist verantwortlich für die Visualisierung von Informationen, die in dem SAVE-Depot gespeichert sind. Die Informationen, die in Modellen visualisiert sind, die Entitäten und Beziehungen umfassen, werden durch die konzeptionellen Komponenten Extrahierer oder Analysator erzeugt. Die visualisierten Informationen können in Graphik-, Diagramm-, Tabellen- oder Textform angezeigt werden. Der Akteur Nutzer ist in der Lage, interaktiv die Informationen, die präsentiert werden, zu navigieren, zu durchsuchen, zu filtern und zu manipulieren, um Kenntnis aus diesen Informationen zu erlangen.
    Extrahierer Die konzeptionelle Komponente Extrahierer analysiert bestehende Systemartefakte durch Anlegen der Tatsachenextraktionsfunktionalität (z. B. Syntaktisches Analysieren, Musteranpassung, Filtern oder Daten importieren), um Informationen über die verarbeiteten Systemartefakte zu sammeln.
    Generator Die konzeptionelle Komponente Generator ist verantwortlich für das Erzeugen von Systemartefakten, die erzeugt werden basierend auf den Informationen, die in dem SAVE-Depot gespeichert sind. Dadurch können Systemartefakte neu erzeugt werden oder bestehende können modifiziert werden.
    Analysator Die konzeptionelle Komponente Analysator liefert Analysefunktionalität zum Abstrahieren, Zusammenstellen, Vergleichen, Transformieren oder Anreichern eines SAVE-Modells. Jede Rechenfunktionalität verarbeitet Informationen von zumindest einem bestehenden Modell in dem SAVE-Depot und modifiziert dasselbe oder erzeugt ein neues Modell/neue Modelle, das/die ebenfalls in dem SAVE-Depot gespeichert wird/werden. Die Informationen, die durch die konzeptionelle Komponente Extrahierer extrahiert werden, werden typischerweise durch den Analysator verarbeitet, um das SAVE-Depot nach relevanten und wesentlichen Informationen zu durchsuchen. Analysator werden entweder durch den Akteur Nutzer initialisiert oder (halb-)automatisch durch einen externen Client ausgeführt. Falls notwendig, liefert der Akteur Nutzer oder der Akteur Client Eingabe oder entscheidet über die Parameter und Konfiguration für eine spezifische Ausführung eines Analysators.
    Depot-Verwaltung Die konzeptionelle Komponente Depotverwaltung ist verantwortlich für das Erzeugen, Zugreifen auf, Verwalten, Laden und Speichern des SAVE-Depots, des internen Datenmodells von SAVE. Alle Zugriffe auf ein SAVE-Depot müssen eine Depotverwaltung verwenden, kein direkter Zugriff ist erlaubt.
    Tabelle 1 SAVE LiFe: konzeptionelle Komponenten
    Datenspeicher Verantwortlichkeiten
    Systemartefakte (1050) Der Datenspeicher Systemartefakte umfasst alle Artefakte des Systems. Das am häufigsten analysierte Artefakt ist der Quellcode; Extrahierer sind jedoch nicht auf darauf begrenzt. Systemartefakte umfassen Daten von Konfigurationsverwaltungssystemen (z. B. CVS, SVN), instrumentierte Laufzeitspuren, Zwischendarstellungen (z. B. GXL, RSF, CSV), CASE-Werkzeuge (z. B. Rational Modeler), Defektdatenbanken (z. B. BugZilla, JIRA), Dritt-Metrikwerkzeuge (z. B. Understand, JHawk), Aufbauskripte (z. B. Makefiles, Antfiles) und andere verfügbare Artefakte.
    SAVE-Depot Das SAVE-Depot ist der zentrale Datenspeicher von SAVE. Aufgrund seiner Art speichert er alle Daten, die durch einen der Extrahierer und Analysator erzeugt werden und ist die Basis für die Ausgabe, die durch Generatoren erzeugt wird.
    Tabelle 2 SAVE LiFe: Datenspeicher
  • Die konzeptionelle Ansicht trennt die abstrakten logischen Konzepte, die durch SAVE LiFe realisiert werden. In der Tat wird diese konzeptionelle Ansicht auch gemeinschaftlich verwendet mit SAVE, dem Vorläufer zum Analysieren von Systemmomentaufnahmen.
  • Der Akteur Nutzer 1105 interagiert mit SAVE LiFe 1110 unter Verwendung der Visualisierung 1120 oder der Benutzerschnittstellen (UI) 1152, 1162, 1172 der konzeptionellen Komponenten. Clients 1107 (entfernt oder lokal) greifen direkt auf die Logik der konzeptionellen Komponente zu. Die konzeptionellen Komponenten sind unabhängig voneinander. Diese Charakteristik ermöglicht es, viele unterschiedliche Extrahierer 1150, Analysatoren 1170 oder Generatoren 1160 parallel innerhalb einer SAVE LiFe oder SAVE-Konfiguration zu haben. Wesentlich für die unterschiedlichen Interaktionen ist die Depotverwaltung 1130, die eine Kopplung auf der Datenebene ermöglicht (d. h. ein Analysator 1170 kann an Daten arbeiten, die durch einen Extrahierer 1150 bereitgestellt werden). Tabelle 1 stellt die Beschreibung der konzeptionellen Komponente näher dar, während Tabelle 2 die Rolle der Datenspeicher erläutert. Die Legende 1001 der 11 entspricht derjenigen aus 10.
  • Im Zusammenhang mit einem Client-Server-Client-Einsatz sind die drei Bausteine, Architekturverwalter bzw. erster Client 1200, Konformitätsprüfer bzw. Server 1300 als Anwendung auf der erweiterbaren Analyse- und Kommunikationsplattform und Entwicklungsüberwachungseinrichtung bzw. zweiter Client 1400, jeweils in 12, 13 bzw. 14 dargestellt.
  • Durch Bewahren des Layouts und der Positionierung für die gleichen Elemente in den Figuren (d. h. 12 bis 14) können die Unterschiede zwischen dem ersten Client bzw. Fat-Client 1200, dem zweiten Client bzw. Thin-Client 1400 und dem Server 1300 dargestellt werden. Unter einem sogenannten „Fat-Client” ist ein Client mit vergleichsweise hoher Rechenleistung zu verstehen, und unter einem sogenannten „Thin-Client” ist ein Client (abhängiger Computer) mit vergleichsweise kleiner Rechenleistung zu verstehen.
  • Der Fat-Client 1200 („SAVE LiFe: Fat Client: Architekturverwalter”) instantiiert die konzeptionelle Ansicht vollständig. Wir markierten die erweitere Depotverwaltung 1130, die die Modellaustauscheinrichtung 1220 enthält. Die Modellaustauscheinrichtung 1220 ist verantwortlich für den Schritt 1207 des Veröffentlichens der Architektur und des Empfangens des neuesten Konformitätsstatus über den Kommunikationskanal 1205. Der Konformitätsstatus ermöglicht das Durchsuchen, Navigieren und das Eintauchen in Einzelheiten. Der Fat-Client 1200 ist sehr ähnlich wie die unabhängige Version von SAVE. Er ermöglicht das Analysieren einer Momentaufnahme des Systems, die in diesem Fall immer der neueste Zustand der Entwicklung ist. Unter Verwendung des Historienmerkmals von SAVE kann der Architekt 402 zeitlich zurück navigieren unter Verwendung einer Durchsuchung, wie bei einem Daumenkino, die die durchgeführten Änderungen visualisiert, die zu bestimmten Zeitpunkten aufgetreten sind.
  • Der Server 1300 („SAVE LiFe: Server: Konformitätsprüfer”) realisiert die grundlegende Kommunikations- und Analyseplattform von SAVE LiFe. Bei Ausführungsbeispielen der Erfindung kommuniziert er mit zwei Clients, dem Architekturverwalter 1200 und der Entwicklungsüberwachungseinrichtung 1400. Der Server 1300 läuft unabhängig von jedem externen Akteur. Er wird ausgelöst durch ankommende Daten auf einem der beiden Kommunikationskanäle 1305-1, 1305-2 und antwortet auf die beabsichtigte Weise, beispielsweise entweder durch Veröffentlichen 1307-2 des Konformitätsstatus auf dem Kommunikationskanal 1305-2 oder durch Senden 1307-1 der Liverückmeldung über die Konformität auf dem Kommunikationskanal 1305-1. Ferner kann die Kommunikation auch durch Empfangen der Architektur auf dem Kommunikationskanal 1305-2 oder durch Empfangen des Deltas auf dem Kommunikationskanal 1305-1 stattfinden. Alle drei Figuren (12, 13 und 14) zeigen die relevanten Enden der Kommunikationskanäle 1205; 1305-1, 1305-2; 1405. Der Thin-Client 1400 („SAVE LiFe: Thin Client: Entwicklungsüberwachungseinrichtung”) umfasst nur Visualisierung 1120, um die Liverückmeldung anzuzeigen, und den Extrahierer 1150, um den lokalen Gültigkeitsbereich zu bestimmen, der dann an den Konformitätsprüfer gesendet wird. Insbesondere kann der Thin-Client 1400 durch den Schritt 1407 des Sendens des Deltas oder des Empfangens der Liverückmeldung über den Kommunikationskanal 1405 kommunizieren. Die Entwicklungsumgebung (IDE) 1403 löst die Funktionalität automatisch aus, wenn vordefinierte Ereignisse auftreten (z. B. Speichern einer Kompilierungseinheit). Typischerweise verwenden viele Entwickler 403 viele Thin-Clients, die mit einem zentralen Server kommunizieren. In den 12 bis 14 umfassen die Schritte 1207; 1307-1, 1307-2; 1407 jeweils die Schritte 617, 735; 901, 619; 635, 825. Ferner entspricht die Legende 1001 der 12 bis 14 derjenigen aus 10.
  • Somit umfassen Ausführungsbeispiele der Erfindung zwei Clients, den Architekturverwalter 1200 und die Entwicklungsüberwachungseinrichtung 1400, und einen zentralen Server 1300, den Konformitätsprüfer. Die Client-Server-Client-Kommunikation überträgt Daten von Clients 1200; 1400 zum Server 1300 und umgekehrt. Die verteilten Datenstrukturen, Strukturmodell, Quellcodemodell, Abbildungsmodell, Deltaquellcodemodell, Konformitätsstatusmodell und Deltakonformitätsstatusmodell werden im Folgenden beschrieben.
  • Der Beschreibung der Datenmodelle folgt die Funktionsweise des Client-Server-Client-Systems, insbesondere des Konformitätsprüfers (siehe 9). Dadurch entsprechen die Schritte bestimmten Verfahren, die unter Verwendung von Pseudocode beschrieben werden, und zwar für den SAVE LiFe Fat-Client 1200 (Architekturverwalter), den SAVE LiFe Thin-Client 1400 (Entwicklungsüberwachungseinrichtung) und den SAVE LiFe Server 1300 (Konformitätsprüfer).
  • 15 zeigt eine schematische Darstellung eines Metamodells 1500 der Strukturansicht. Die Strukturansicht erfasst die statische Struktur eines Systems, beispielsweise bezüglich Schichten, Teilsystemen und Komponenten, den Schnittstellen, die durch dieselben bereitgestellt werden und die Beziehungen zwischen den verschiedenen Elementen. Die Strukturansicht beschreibt nur die statische Struktur eines Systems und liefert daher keine Informationen über dynamische Aspekte und Verhalten. Im Folgenden werden die relevanten technischen Datenmodelle beschrieben.
  • Die Strukturansicht (siehe 15 für das Metamodell) wird dargestellt unter Verwendung mehrerer Strukturmodelle, die das System in Architekturelemente untergliedern. Architekturelemente haben bestimmten Verantwortlichkeiten und umfassen bestimmte Funktionalitäten. Um dieses Ziel zu erreichen, interagieren Architekturelemente mit anderen Elementen. Diese Zwischenelementbeziehungen ermöglichen das Zusammenspiel der Architekturelemente, um schließlich die funktionellen und qualitativen Anforderungen des Systems zu realisieren.
  • Insbesondere zeigt 15 das Metamodell 1500 der Strukturansicht unter Verwendung der UML-Notation. Ein Architekturelement 1510 ist eine hierarchische Entität, die andere Architekturelemente enthalten kann. Das Architekturelement 1510 ist eine Verallgemeinerung von konkreten Elementen (z. B. Schichten 1512, Teilsystemen 1514, Komponenten 1516 oder Clustern 1518; hier ist anzumerken, dass 15 nur die am üblichsten verwendeten Elemente darstellt). Alle Architekturelemente 1510 können als Behälter agieren und können andere Elemente enthalten. Jedes Architekturelement 1510 kann einen Satz von Zwischenelementbeziehungen 1520 ansammeln (z. B. Abhängigkeitsregeln 1522 und Verbinder 1524). Eine Zwischenelementbeziehung 1520 verbindet zwei Architekturelemente 1510 miteinander. Tabelle 3 erläutert die Modellelemente von 15 in näheren Einzelheiten.
    Modellelement Beschreibung
    Architekturelement Ein Architekturelement ist ein abstrakter hierarchischer Behälter, der durch konkrete Elemente instantiiert werden kann.
    Schicht Schichtbildung untergliedert die Strukturansicht in mehrere horizontale Abstraktionsebenen. Eine Schicht umfasst Funktionalität auf unterschiedlichen Abstraktionsebenen (z. B. Benutzerschnittstelle, Geschäftslogik, Dienst und Hardwareabstraktionsschicht). Schichtbildung ermöglicht nur Zwischenelementbeziehungen von oben nach unten. Strenge Schichtbildung erzwingt eine strenge Hierarchie, so dass es jeder Schicht nur erlaubt wird, die Schicht direkt unter derselben zu verwenden.
    Teilsystem Ein Teilsystem ist ein Gruppierungselement, das idealerweise einen hohen Zusammenhang und eine geringe Kopplung mit anderen Teilsystemen aufweist. Ein Teilsystem kann entweder andere Teilsysteme oder Komponenten enthalten.
    Komponente Komponenten sind die Bausteine eines Softwaresystems. Komponenten haben eine vordefinierte Schnittstelle, die ihre Interna einkapselt. Die Interna von Komponenten realisieren die Funktionalität, die die Komponente bereitstellt. Einzelne Komponenten umfassen viele Quellcodeelemente, die die funktionale und qualitative Anforderung implementieren, die für die Komponente spezifiziert ist.
    Cluster Clusterbildung unterteilt die Strukturansicht in mehrere vertikale Cluster. Clusterbildung ermöglicht es, dass Elemente in einem Cluster nur auf andere Elemente in dem gleichen Cluster oder nicht geclusterte Elemente zugreifen. Strenge Clusterbildung erzwingt den Zugriff nur innerhalb eines Clusters. Clusterbildung und Schichtbildung werden häufig gemeinsam verwendet, um eine vertikale und horizontale Unterteilung zu erreichen.
    Zwischenelementbeziehung Eine Zwischenelementbeziehung ist eine abstrakte direkte Abhängigkeit von einem Architekturelement zu einem anderen, die durch konkrete Zwischenelementbeziehungen instantiiert werden kann.
    Abhängigkeit Eine Abhängigkeit spezifiziert, wie ein Architekturelement von einem anderen abhängen kann. Sie definiert den erlaubten Zugriffstyp (z. B. umfasst Anweisungen, Verfahrensaufrufe oder Funktionsaufrufe, Lese- oder Schreibzugriffe auf Variablen, Vererbung usw.). Abhängigkeiten können regelmäßige Ausdrücke oder Strukturen verwenden, um Kriterien zu definieren, die mit einem Satz von Architekturelementen übereinstimmen.
    Verbinder Ein Verbinder ist ein abstrakter Mechanismus, der Kommunikation, Koordination oder Kooperation unter Komponenten vermittelt (z. B. gemeinschaftlich verwendete Darstellungen, entfernte Prozeduraufufe, Mitteilungsweiterleitungsprotokolle und Datenströme).
    Tabelle 3 Elemente des Strukturansicht-Metamodells
  • Die Strukturansicht der Architekturen kann mehr als nur ein Strukturmodell haben, aber alle sind eine Instantiierung des gleichen Metamodells. Mehrere Strukturmodelle zu haben, trennt die Differenzunterschiede von Akteuren, d. h. nicht alle Informationen sind relevant für jeden. Ferner ergibt nur ein einzelnes Strukturmodell eine komplexe und komplizierte Strukturansicht der Architektur, der jegliche Einkapselung fehlt. Um die Klarheit, Lesbarkeit und Leichtigkeit der Verwendung und Wartung zu optimieren, ist die Unterteilung in mehrere Strukturmodelle eine ansprechende und bevorzugte Option. In der Praxis entwerfen Architekten mehrere, aber einheitliche Strukturmodelle, die die Strukturansicht der Softwarearchitektur des Systems umfassen.
  • 16 zeigt eine schematische Darstellung eines Metamodells 1600 des Quellcodes. Der Quellcode eines Softwaresystems besteht aus den geschriebenen Anweisungen, die durch die Entwickler implementiert werden. Der Quellcode wird in einer spezifischen Programmiersprache beschrieben, der die Konstrukte vorschreibt, die Entwickler verwenden können, um Lösungen für Algorithmen, Datenstrukturen, usw. zu realisieren. Insbesondere zeigt 16 (unter Verwendung des UML-Notation) das generische Quellcodemetamodell 1600.
  • Das Quellcodemodell erfasst die statische Struktur eines Systems zur Entwicklungszeit. Im Gegensatz zur Strukturansicht umfasst das Quellcodemodell ganze Größenordnungen von mehr Elementen. Diese Quellcodeelemente 1610 sind der Schlüssel des allgemeinen Quellcodemodells. Durch ihre Allgemeinheit stellen sie jeweilige Codeelemente dar, die viele unterschiedliche Programmiersprachen umspannen. Somit erfordert jede Programmiersprache eine Interpretation, um die Programmiersprachenkonstrukte den Elementen des allgemeinen Quellcodemodells zuzuweisen. Ein Quellcodeelement 1610 weist beispielsweise einen Ordner 1612, eine Kompilierungseinheit 1614, eine Routine 1616 oder eine Variable 1618 auf.
  • Quellcodeelemente 1610 sind durch Quellcodebeziehungen 1620 miteinander verbunden. Eine Quellcodebeziehung 1620 ist eine gerichtete Verbindung von einem konkreten Codeelement zu einem anderen. Erneut müssen die konkreten Abhängigkeiten, die durch Programmiersprachkonstrukte implementierbar sind, der allgemeinen Quellcodebeziehung zugewiesen werden. Tabelle 4 erläutert die Modellelemente von 16 in näheren Einzelheiten.
    Modellelement Beschreibung
    Quellcodeelement Ein Quellcodeelement ist eine abstrakte Darstellung, die durch konkrete Elemente instantiiert werden kann.
    Ordner Ein Ordner stellt ein Gruppierungselement dar, das entweder in dem Dateisystem (d. h. einem Verzeichnis) sichtbar ist oder die Konstrukte der Programmiersprache (z. B. Programmpakete in Java). Ordner sind hierarchische Elemente, die andere Ordner, Kompilierungseinheiten oder beides enthalten können.
    Kompilierungseinheit Kompilierungseinheiten sind die Quellcodeelemente, die durch die Entwickler geschrieben werden. Kompilierungseinheiten sind spezielle Elemente, die einzeln durch den Kompilierer verarbeitet werden. Kompilierungseinheiten stellen Klassen oder Dateien dar. Sie enthalten Routinen oder Variablen.
    Routinen Routinen sind geschlossene Fragmente von Quellcode in Kompilierungseinheiten, die spezifische Aufgaben durchführen und eine vordefinierte Signatur aufweisen (d. h. Routinen können Parameter und Rückgabewerte aufweisen). Abhängig von der Programmiersprache werden Routinen häufig als Subroutinen, Funktionen, Verfahren, Prozeduren oder Unterprogramme bezeichnet. Routinen werden ausgeführt (d. h. gerufen oder aufgerufen) durch andere Routinen.
    Variablen Variablen stellen Identifizierer in dem Quellcode dar. Sie sind symbolische Darstellungen, die verwendet werden, um eine Variable an eine Speicherposition zu binden. Die Variable speichert Werte eines Datenobjekts in dieser Position, so dass auf das Objekt zugegriffen werden kann und es zu einem späteren Zeitpunkt manipuliert werden kann.
    Quellcodebeziehung Eine Quellcodebeziehung stellt eine Abhängigkeit eines konkreten Quellcodeelements von einem anderen dar (z. B. siehe oben). Der Beziehungstyp hängt von Fähigkeiten der Programmiersprache ab (z. B. ist es in Java möglich, Importe, Verfahrensaufufe, Variablenzugriffe, Vererbungen usw. zu implementieren). Quellcodebeziehungen sind gerichtet, d. h. sie haben einen Ursprung und ein Ziel.
    Tabelle 4 Elemente des Quellcodemetamodells
  • Aufgrund seiner Kompatibilität wird das Quellcodemodell für spezifische Programmiersprachen instantiiert. Eine solche Instantiierung kann die Hinzufügung weiterer konkreter und programmiersprachenspezifischer Elemente umfassen; das in 16 dargestellte Metamodell war jedoch ausreichend, wenn Softwaresysteme analysiert wurden, die in Programmiersprachen wie JAVA, C/C++ oder DELPHI implementiert waren. Tabelle 5 stellt die Zuweisung von Programmiersprachenkonstrukten zu dem allgemeinen Quellcodemodell dar. Dabei wählten wir zwei Vertreter, JAVA für objektorientierte und C für verfahrensorientierte (prozedurale) Sprachen. Wie Tabelle 5 zeigt, können alle relevanten Sprachkonstrukte dem Metamodell zugewiesen werden. Es ist jedoch möglich, das Quellcodemodell zu filtern und sich nur auf einen begrenzten Satz von Elementen zu konzentrieren (z. B. sich nicht mit Einzelheiten zu befassen und alle Quellcodebeziehungen von Ordnern oder Kompilierungseinheiten ausgehen zu lassen).
    Modellelement Sprachkonstrukte in Java Sprachkonstrukte in C
    Ordner Javadatenpaket Dateisystemverzeichnis
    Kompilierungseinheit Javaklasse C Implementierungsdatei (.c) C Anfangsblockdatei (.h)
    Routinen Klassenverfahren Funktion
    Variablen Klasseninstanzen globale Variablen lokale Variablen globale Variablen lokale Variablen
    Quellcodebeziehungen Klassenimport Klassenvererbung Klasseninstanzzugriff Verfahrensaufruf Variablenzugriff Schnittstellenimplementierung Anfangsblockumfassung Funktionsimplementierung Funktionsaufruf Variablenzugriff
    Tabelle 5 Zuweisung von Programmiersprachenkonstrukt zur Quellcodemodellelementen
  • Architekturen schreiben die Struktur nicht in allen Einzelheiten vor, sondern liefern eher eine Skizze und die Regeln, die definieren, wie die Architekturelemente 1510 und ihre Zwischenelementbeziehung 1520 in Quellcode übersetzt werden sollten. Somit erfasst die Strukturansieht die Untergliederung aus der Perspektive eines globalen Systems. Lokale Entscheidungen (d. h. Einzelheiten auf der Quellcodeebene) werden nach wie vor durch die Entwickler getroffen. Daher ist es nicht überraschend, dass funktional gleiche Systeme, die basierend auf der gleichen Architektur realisiert werden, aber durch zwei unterschiedliche Entwickler codiert werden, höchst wahrscheinlich zwei unterschiedliche Implementierungen ergeben.
  • Um die Verschiedenartigkeit bei der Implementierung zu begrenzen, gibt es typischerweise Abbildungsanweisungen für Entwickler. Solche Anweisungen schreiben vor, wie die Quellcodeelemente zu benennen und hierarchisch zu strukturieren sind. Idealerweise werden die Strukturmodelle klar reproduziert durch die Hierarchie von Ordnern und Kompilierungseinheiten. Aufgrund der Abstraktionslücke stellen viele Quellcodelemente 1610 ein Architekturelement 1510 dar, das gleiche gilt für Beziehungen. Bei der Vorwärtsentwicklung (Forward Engineering) erzeugen die Entwickler Quellcodeelemente und benennen dieselben basierend auf diesen Abbildungsanweisungen, und sie erzeugen die interne Zusammensetzung von Architekturelementen. Beispiele für Abbildungsanweisungen sind Benennungskonventionen, wie Vorzeichen für alle Kompilierungseinheiten, die den Komponentennamen codieren, Darstellungen jedes Teilsystems als getrennten Ordner in dem Teilsystem oder getrennte Abbildungsmodelle, die eine beliebige Untergliederung von Architekturelementen entwerfen und im Detail darstellen. Eine der Verantwortlichkeiten von Architekten ist das Bereitstellen dieser Abbildungsanweisungen für Entwickler.
  • Durch Implementieren von Architekturelementen wie Komponenten wird der Quellcode hergestellt. Entwickler schreiben viele neue Quellcodedateien und modifizieren bestehende, anders ausgedrückt, sie füllen eine anfängliche Skelettimplementierung mit Inhalt. Dadurch verwenden Entwickler andere Quellcodedateien, und sie erzeugen somit gerichtete Abhängigkeiten zwischen den Kompilierungseinheiten. Die Position der Ursprungs- und Zielkompilierungseinheit klassifiziert die Beziehung entweder als interne oder externe Abhängigkeit. Interne Abhängigkeiten verbleiben innerhalb einer Komponente, während externe Abhängigkeiten eine Beziehung zwischen zwei Komponenten realisieren, wobei es selbstverständlich konkrete Instanzen für die Beziehungen auf Codeebene geben kann.
  • Die Dokumentation, wie der Zwischenraum zwischen Strukturansicht und Quellcode zu überbrücken ist, ist der Zweck der Abbildung (sog. Mapping). 17 zeigt eine schematische Darstellung eines Metamodells 1700 der Abbildung unter Verwendung der UML-Notation. Die Abbildung 1705 definiert die Beziehung von Architekturelementen 1510 zu Quellcodeelementen 1610 und umgekehrt. Das gleiche gilt für die Architekturzwischenelementbeziehung 1520 und die Quellcodebeziehungen 1620. Typischerweise ist eine Entität der Architekturebene durch zahlreiche Entitäten auf der Quellcodeebene dargestellt. Die Abbildung wurde als getrenntes Metamodell definiert, um eine klare Trennung der beiden Abstraktionsebenen zu erreichen. Strukturmodell und Quellcodemodell bleiben unabhängig voneinander, und es gibt keine direkten Abhängigkeiten von einem Modell zum anderen.
  • Die Abbildung 1705 umfasst alle Informationen zum Überbrücken der Abstraktionsebene von Architektur zu Quellcode. Informationen über die jeweiligen Gegenstücke können extrahiert werden von den Verweisen der Elementabbildung 1715 und der Beziehungsabbildung 1725. Die Elementabbildung 1715 verbindet Architekturelemente 1510 und Quellcodeelemente 1610. Die Extrahierung jeweiliger Gegenstücke ist für beide Richtungen möglich. Die Beziehungsabbildung 1725 liefert die gleiche Verbindung zwischen der Architekturzwischenelementbeziehung 1520 und der Quellcodebeziehung 1620. Tabelle 6 erläutert die Modellelemente von 17 in näheren Einzelheiten.
    Modellelement Beschreibung
    Abbildung Die Abbildung ist ein Behälter für alle Abbildungen, entweder Elementabbildungen oder Beziehungsabbildungen. Die Abbildung ist die Wurzel zum Überbrücken der Abstraktionszwischenraumabbildung zwischen der Architektur und dem Quellcode.
    Elementabbildung Die Elementverbindung verbindet ein Architekturelement mit einem Quellcodeelement.
    Architekturelement siehe Beschreibung oben
    Quellcodeelement siehe Beschreibung oben
    Beziehungsabbildung Die Beziehungsabbildung verbindet ein Architekturelement mit einem Quellcodeelement.
    Zwischenelementbeziehung siehe Beschreibung oben
    Quellcodebeziehung siehe Beschreibung oben
    Tabelle 6 Elemente des Abbildungsmetamodells
  • Das Definieren der Metamodelle 1500; 1600; 1700 für Strukturansichten, Quellcode und deren Abbildung ermöglicht das Spezifizieren der Konformitätsmetrik. Diese Metrik misst die Konformität für konkrete Instanzen der jeweiligen Metamodelle.
  • Das Delta-Quellcodemodell bzw. Deltamodell 930 ist eine Instanz des Quellcodemodells 940 (siehe 9), die für das lokal modifizierte Delta des Entwicklers erzeugt wird. Somit dient das Metamodell 1600 des Quellcodes auch als Metamodell für das Deltamodell 930.
  • Ferner ist das Konformitätsstatusmodell ein kommentiertes Komponentenmodell, das die Architekturverletzungen des Systems unter der Bewertung offenbart. Somit dienst das Metamodell 1500 des Komponentenmodells bzw. Strukturmodells (siehe 15) auch als Metamodell für den Konformitätsstatus 950.
  • Die Kommentare des Komponentenmodells zeigen das Ergebnis der Konformitätsprüfung an durch Zuweisen eines Attributs zu jeder Zwischenelementbeziehung (auch bezeichnet als externe Abhängigkeit, d. h. Abhängigkeit zwischen zwei Komponenten). Die externen Abhängigkeiten von Architekturelementen erfassen, zu welchem Grad die spezifizierten Architekturzwischenelementbeziehungen durch die Entwickler realisiert wurden. Es gibt drei Kategorien für externe Abhängigkeiten, Konvergenz, Divergenz und Abwesenheit. Die Konvergenz oder konvergente Abhängigkeit (echte Positive) ist eine Beziehung zwischen zwei Architekturelementen, die, wie spezifiziert, implementiert wurde. Die Divergenz oder divergierende Abhängigkeit (falsche Positive) ist eine Beziehung zwischen zwei Architekturelementen, die implementiert, aber nicht spezifiziert wurde. Und die Abwesenheit oder abwesende Abhängigkeit (echte Negative) ist eine Beziehung zwischen zwei Architekturelementen, die spezifiziert, aber nicht implementiert wurde.
  • Durch Anheben von Quellcodeleementen auf die Ebene der Softwarearchitektur unter Verwendung der Abbildung werden die externen Abhängigkeiten ebenfalls angehoben. Somit ist objektiver automatische Messung möglich. 18 zeigt eine schematische Darstellung eines beispielhaften Reflexionsmodells 1800 mit Strukturmodell 1810 (links), Quellcodemodell 1820 (Mitte) und Konformitätsprüfungsergebnisse 1830 (rechts). Das Strukturmodell 1810 (siehe links in 18) spezifiziert beispielsweise drei Architekturelemente, nämlich Komponenten hlm1 1812, hlm2 1814 und hlm3 1816. Die Pfeile zwischen den Komponenten zeigen die vorgeschriebenen Zwischenelementbeziehungen an. Das syntaktische Analysieren der Implementierung erzeugt das Quellcodemodell 1820 (siehe Mitte in 18), das auch drei Elemente umfasst, nämlich scm1 1822, scm2 1824 und scm3 1826. Die Pfeile in dem Quellcodemodell 1820 stellen die Quellcodebeziehungen dar.
  • Die Ergebnisse 1830 der Konformitätsprüfung (siehe rechts in 18), die unabhängig davon sind, welche konkrete Technik angewendet wird, offenbaren, dass die Entwickler zwei Fehler in der Implementierung haben: die Zwischenelementbeziehung 1825 von hlm3 zu hlm1 wurde nicht realisiert (angezeigt durch das X), und eine zusätzliche Abhängigkeit 1835 von hlm2 zu hlm3 wurde implementiert (angezeigt durch das Ausrufezeichen). Nur die Zwischenelementbeziehung 1815 von hlm1 zu hlm2 wurde, wie spezifiziert, implementiert.
  • Wie im Vorhergehenden beschrieben, hebt die Abbildung die Quellcodemodelle auf die Abstraktionsebene der Strukturansicht an. Für das in 18 gegebene Beispiel definiert die Abbildung, wie die Architekturelemente des Strukturmodells 1810 auf die Elemente des Quellcodemodells 1820 abgebildet werden. Für das Beispiel ist dies eine eher einfache und unaufwendige Aktivität, die zu der folgenden Abbildung führt: hlm1 1812 ist implementiert durch scm1 1822, hlm2 1814 durch scm2 1824 und hlm3 1816 durch scm3 1826. Für beide, die Spezifizierung und die Realisierung, ist es möglich, das Modell als einen Satz von Zwischenelementbeziehungen zu beschreiben. Die Spezifizierung umfasst die Tupel A = {(hlm3, hlm1), (hlm1, hlm2)}, während die Realisierung A' = {(hlm1, hlm2), (hlm2, hlm3)} implementiert.
  • Das Anheben beider Modelle auf die gleiche Abstraktionsebene durch die Abbildung ermöglicht den Vergleich, d. h. die tatsächliche Berechnung der Ergebnisse. Die Berechnung des Reflexionsmodells weist jeder Zwischenelementbeziehung einen von drei Typen zu, die als Mengenoperationen ausgedrückt werden können, und zwar Konvergenz (d. h. Konvergenzen = A ∩ A'), Divergenzen (d. h. Divergenzen = A'\A) und Abwesenheit (d. h. Abwesenheiten = A\A'). Die Visualisierung, die von dem Ergebnistyp der Berechnung abhängt, zeigt dann die Konformitätsprüfungsergebnisse 1830, wie es beispielsweise in 18 rechts dargestellt ist.
  • Schließlich ist das Deltakonformitätsstatusmodell eine Instanz des Quellcodemodells, die für das lokal modifizierte Delta des Entwicklers erzeugt wird, kommentiert durch den Konformitätsstatus, vorgedrungen zu dem Quellcodemodell unter Verwendung der Abbildung. Somit dient das Metamodell 1600 des Quellcodes (siehe 16) auch als Metamodell für den Deltakonformitätsstatus. Hierbei gelten die gleichen Anmerkungen wie gerade im Zusammenhang mit dem Konformitätsstatusmodell definiert für den Deltakonformitätsstatus.
  • Im Folgenden werden weitere Ausführungsbeispiele des in 1 und 2 gezeigten Verfahrens 100 bzw. Systems 200 aufgezeigt.
  • Bei weiteren Ausführungsbeispielen der Erfindung wird das Ausgangs-Strukturmodell 115 verändert, um das Ausgangs-Strukturmodell 115 in das Delta-Strukturmodell 155 zu überführen.
  • Bei weiteren Ausführungsbeispielen der Erfindung ist das Referenz-Strukturmodell 105 eine Soll-Vorgabe, die von einem Software-Architekten vorgegeben wird. Im Gegensatz dazu stellt das Delta-Strukturmodell 155 ein Ist-Strukturmodell dar, das mit der Soll-Vorgabe verglichen wird, um das Vergleichsergebnis 165 zu erhalten.
  • Bei weiteren Ausführungsbeispielen der Erfindung liegen die Elemente des Strukturmodells auf einer im Vergleich zu den zugeordneten Quellcodeelementen höheren Abstraktionsebene. Wie entsprechend in 17 gezeigt, kann bei weiteren Ausführungsbeispielen der Erfindung die durch die Abbildungsvorschrift 125 definierte Zuordnung eine Elementabbildung zwischen Elementen des Ausgangs-Strukturmodells 115 und Ausgangs-Quellcodeelementen oder eine Elementabbildung zwischen Elementen des Delta-Strukturmodells 155 und Quellcodeelementen des Delta-Quellcodemodells 145 oder eine Beziehungsabbildung zwischen Zwischenelementbeziehungen von Elementen des Ausgangs-Strukturmodells 115 und Quellcodebeziehungen von Ausgangs-Quellcodeelementen oder eine Beziehungsabbildung zwischen Zwischenelementbeziehungen von Elementen des Delta-Strukturmodells 155 und Quellcodebeziehungen von Elementen des Delta-Quellcodemodells 145 aufweisen.
  • Bei weiteren Ausführungsbeispielen der Erfindung wird während des Ermitteln 140 des Delta-Quellcodemodells 145 der Programmcode des Delta-Quellcodeteils 135 geparst. Insbesondere kann hierbei, wie beispielsweise in 16 gezeigt, ein Quellcodeelement des Delta-Quellcodemodells 145 beispielsweise ein Ordner, eine Kompilierungseinheit, eine Routine, eine Variable oder eine Quellcodebeziehung sein.
  • Bei weiteren Ausführungsbeispielen der Erfindung weist die Abbildungsvorschrift 125 Benennungskonventionen für die Quellcodeelemente auf. Wie im Vorhergehenden erwähnt, können die Benennungskonventionen beispielsweise Vorzeichen für alle Kompilierungseinheiten, die den Komponentennamen codieren, aufweisen.
  • Bei weiteren Ausführungsbeispielen der Erfindung werden bei dem unveränderten Quellcodeteil die daraus zuvor abgeleiteten Abhängigkeiten beibehalten. Dadurch ergibt sich insbesondere eine Reduzierung des Rechenaufwands, da diese Abhängigkeiten nicht erneut berechnet werden müssen.
  • Bei weiteren Ausführungsbeispielen der Erfindung werden bei dem Vergleichen 160 konvergente, divergente oder abwesende Abhängigkeiten als Vergleichsergebnis 165 ermittelt. Insbesondere können dabei die Abhängigkeiten beispielsweise mittels eines Reflexionsmodells, wie beispielsweise in 18 gezeigt, ermittelt werden.
  • Bei weiteren Ausführungsbeispielen der Erfindung wird bei dem Bereitstellen des Ausgangs-Strukturmodells 115 das Ausgangs-Strukturmodell 115 von einem ersten Client 310 zu einem Server 320 übertragen. Ferner erfolgt das Vergleichen 160 des Delta-Strukturmodells 155 mit dem Referenz-Strukturmodell 105 durch den Server 320. Schließlich wird das Vergleichsergebnis 165 von dem Server 320 zu einem zweiten Client 330 übertragen.
  • Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blue-Ray-Disk, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM ohne eines Flash-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein. Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektrisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
  • Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahingehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft. Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
  • Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Träger gespeichert ist.
  • Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahren somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft. Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
  • Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahingehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
  • Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahingehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.
  • Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
  • Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, um manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware, wie einen Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
  • Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt seien.
  • Ein erfindungsgemäß codiertes Signal, wie beispielsweise ein erfindungsgemäßes Quellcodeelement, kann auf einem digitalen Speichermedium gespeichert sein oder kann auf einem Übertragungsmedium, wie beispielsweise einem drahtlosen Übertragungsmedium oder einem verdrahteten Übertragungsmedium, z. B. dem Internet, übertragen werden.
  • Ferner kann bzw. können das erfindungsgemäße Computerprogramm und die entsprechenden Algorithmen in dem am Ende der Beschreibung gezeigten Pseudocode dargestellt werden. Die Legende des Pseudocodes umfasst insbesondere die Übersetzungen der Kommentare, Anweisungen, Datentypen und Variablen der relevanten Methoden.
  • Bei Ausführungsbeispielen der Erfindung schätzen wir einerseits die Vorteile bzw. positiven Effekte der konstruktiven Konformitätsprüfung. Ein Experiment zeigt, dass Liverückmeldung in der Tat die Anzahl an Strukturverletzungen in den Implementierungen reduziert. In diesem Fall verglichen wir sechs Teams, die aus einer Gesamtzahl von 19 Entwicklern bestanden, die Komponenten ähnlicher Größe realisierten und ungefähr den gleichen durchschnittlichen Aufwand pro Entwickler erbrachten. Drei Teams empfingen Unterstützung durch SAVE LiFe, während die anderen drei Teams – die Kontrollgruppe – einen gewöhnlichen Entwicklungslösungsansatz anwendeten (d. h. ohne SAVE LiFe). Beide Gruppen entwickelten ein Softwaresystem über eine Periode von 35 Tagen, die die Lebenszyklusphasen Implementierung, Integration und Testen umfasste. Das Experiment zeigte, dass die Gruppe, die durch SAVE LiFe unterstützt wurde, ständig 60% weniger Architekturverletzungen hatte, als die Kontrollgruppe. Somit liefert das Experiment einen Beweis für die positiven Effekte von SAVE LiFe auf die Konformität. Die Entwickler der Gruppen, die durch konstruktive Konformitätsprüfung unterstützt wurden, erbrachten ungefähr den gleichen Aufwand in allen Phasen wie die Kontrollgruppen.
  • Falls man sich die Reparatur der Strukturverletzungen vorstellt, die in den oben erwähnten Komponenten enthalten sind, sind die Vorteile offensichtlich, die das konstruktive Konformitätsprüfen im Vergleich zu seinem analytischen Zwilling aufweist.
  • Insbesondere ist die Anzahl von Verletzungen um 60% reduziert, was schließlich 60% weniger Elemente bedeutet, die repariert werden müssen. Dies führt zu einem wesentlich geringeren Aufwand zum Erreichen der Konformität. Ferner gibt es keinen Bedarf an Workshops oder Meetings, wo der Architekt den Entwicklern die Reparaturaufgaben erläutert. Alle Entwickler wissen bereits von den Verletzungen, weil sie die Verletzungen plus Kontextinformationen in ihrem eigenen Quellcodeeditor markiert sehen.
  • Die Konformitätsrückmeldung richtet sich an den Verursacher oder lokalen Experten und ist auf denselben zugeschnitten. Entwickler, die für einen Satz von Kompilierungseinheiten verantwortlich sind, empfangen nur Rückmeldungen über ihren lokalen Gültigkeitsbereich. Es gibt keinen Bedarf, die Menge an Verletzungen erst zu zerteilen, um zu identifizieren, wer der verantwortliche Entwickler für die Durchführung der Reparatur wäre.
  • Im Allgemeinen schafft die Erfindung somit ein Konzept für eine konstruktive Konformitätsprüfung (constructive complience checking), d. h. ein Verfahren bzw. System zum Erstellen von Softwareimplementierungen mit Konformität, um die Struktur in Implementierungen aufrecht zu erhalten.
  • Bei der folgenden Betrachtung wird ein weiterer Vorteil deutlich. Die Zeitpunkte für die analytische Konformitätsprüfung können wie folgt formuliert werden: tArchitektur << tImplementierung << tAnalyse < tKommunikation << tKorrektur. Außer zwischen Analyse und Kommunikation gibt es eine erhebliche Verzögerung (d. h. mehrere Tage, Wochen oder Monate) zwischen den Stufen. Konstruktive Konformitätsprüfung führt die vier Phasen (d. h. Implementierung, Analyse, Kommunikation und Korrektur) im Wesentlichen gleichzeitig aus. Die hohe Ausführungsfrequenz mit Liverückmeldung rechtfertigt die Klassifizierung als einen konstruktiven Qualitätskonstruktionslösungsansatz, der zu tArchitektur << (tImplementierung = tAnalyse = tKommunikation = tKorrektur) führt. Obwohl es nach wie vor eine Verzögerung zwischen Architektur und den nachfolgenden Phasen gibt, werden alle anderen Phasen im Wesentlichen gleichzeitig durchgeführt.
  • Die Erfindung schafft somit ferner ein Konzept zum Ermitteln der Regeltreue, bei dem aus den geänderten Dateien bzw. dem Delta-Quellcodeteil das Delta-Quellcodemodell ermittelt wird. Temporär wird beispielsweise eine Kopie des Referenz-Strukturmodells erstellt, indem durch die Abbildungsvorschrift die durch Änderungen betroffenen Elemente und Strukturmodelle identifiziert werden. Somit kann das Delta-Strukturmodell erstellt werden, welches die Auswirkung der geänderten Dateien wiederspiegelt. Durch den Vergleich mit dem Referenz-Strukturmodell wird dann die Regeltreue ermittelt.
  • Durch das selektive Verarbeiten der veränderten Quellcodedateien ergibt sich daraus ein Geschwindigkeitsvorteil. Unter der Annahme, dass ein Beispielsystem aus 1000 Dateien besteht, wird der Geschwindigkeitsvorteil deutlich: Herkömmlich müssten alle 1000 Dateien verarbeitet werden, um ein Quellcodemodell als Ausgangsbasis für den Vergleich zu erstellen. In dem neuen Verfahren werden aber nur die wenigen, tatsächlich geänderten Dateien verarbeitet. Dadurch erklären sich die Vorteile bezüglich Rechenaufwand und Geschwindigkeit des Verfahrens.
  • Die oben beschriebene Delta-Analyse wirkt sich also vorteilhaft aus, da nur veränderte Dateien berücksichtigt werden. Die drastische Einschränkung der Eingabemenge beschleunigt das Verfahren insgesamt, und ermöglicht somit die Durchführung der Überprüfung der Regeltreue in Echtzeit (live) mit direktem Feedback bzw. Rückmeldung für die Entwickler.
  • Die Erfindung kann in der kompletten Software-Entwicklung eingesetzt werden.
  • Im folgenden wird ein Pseudoprogrammcode beschrieben, der bei der Realisierung des Erfindungskonzepts verwendet werden kann.
  • SAVE LiFe Fat Client: Architekturverwalter
  • Die Architektur führt die Verfahren publishArchitecture() und requestComplianceStatus() auf Nachfrage aus. Beide Verfahren sind von der Benutzerschnittstelle des Architekturverwalters aus zugreifbar. Methode ”publish Architecture”:
    Figure 00380001
    Figure 00390001
    Methode ”request Compliance Status”:
    Figure 00390002
  • SAVE LiFe Thin Client: Entwicklungsüberwachungseinrichtung
  • Die Entwicklungsüberwachungseinrichtung verfolgt die Arbeit jedes Entwicklers in der integrierten Entwicklungsumgebung einzeln. Die Entwicklungsüberwachungseinrichtung integriert sich in den inkrementalen Projekterzeuger der Entwicklungsumgebung ein (z. B. für Eclipse org.eclipse.core.internal.events). Der Erzeuger wird jedes Mal ausgeführt, wenn physikalische Ressourcen (d. h. Dateien oder Ordner) geändert und gespeichert werden. Wenn er ausgeübt wird, wird das Verfahren monitorCodeandSendDelta() der Entwicklungsüberwachungseinrichtung automatisch aufgerufen. Somit wird das Verfahren für jede Änderung ausgeführt, die an dem Quellcode durchgeführt wird. Methode ”monitor code and send Delta”:
    Figure 00400001
    Methode ”determineLocalDelta”:
    Figure 00400002
    Figure 00410001
    Methode ”receiveLiveFeedback”:
    Figure 00410002
    Figure 00420001
    Methode ”displayDeltaResult”:
    Figure 00420002
  • SAVE LiFE Server: Konformitätsprüfer (erweiterbare Analyse und Kommunikationsplattform)
  • Die Verfahren des Konformitätsprüfers werden durch den jeweiligen Client entfernt ausgelöst. Der Architekturverwalter ruft entweder receivePublishArchitecture() oder publishComplianceStatus() auf, während die Entwicklungsüberwachungseinrichtung sendDelta() aufruft.
  • Nachdem die Konformitätsprüfung stattgefunden hat, ruft der Server receiveLiveFeedback() in der Entwicklungsüberwachungseinrichtung auf, so dass Entwickler sofort über die Verletzungen – falls es welche gibt – informiert werden. Methode ”receivePublishedArchitecture”:
    Figure 00430001
    Methode ”updateStructuralModel”:
    Figure 00430002
    Methode ”updateMapping”:
    Figure 00430003
    Figure 00440001
    Methode ”publishComplianceStatus”:
    Figure 00440002
    Methode ”receiveDelta”:
    Figure 00440003
    Figure 00450001
    Methode ”extractDeltaFacts”:
    Figure 00450002
    Figure 00460001
    Methode ”parseCompilationUnit”:
    Figure 00460002
    Methode ”updateSourceCodeModel”:
    Figure 00460003
    Figure 00470001
    Figure 00480001
    Methode ”checkCompliance”:
    Figure 00480002
    Figure 00490001
    Methode ”distillViolations”:
    Figure 00490002
    Figure 00500001
  • LEGENDE
  • Im folgenden werden die in dem Pseudo-Programmcode verwendeten Variablen, Methoden, Anweisungen und Datentypen näher erläutert.
    • public
    öffentlich
    int
    ganzzahlig (Datentyp)
    publishArchitecture()
    veröffentliche Architektur()
    ArchitectureManager
    Architekturverwalter
    Client
    Client
    ArchitectureManagerClient
    Architekturverwalter-Client
    getClient()
    erhalte Client()
    ComplianceChecker
    Konformitätsprüfer
    server
    Server
    getServer()
    erhalte Server()
    StructuralModel
    Strukturmodell
    structure
    Struktur
    getStructuralModel()
    erhalte Strukturmodell()
    MappingModel
    Abbildungsmodell
    Mapping
    Abbildung
    getMapping()
    erhalte Abbildung()
    TransferData
    Übertragungsdaten (Datentyp)
    transferData
    Übertragungsdaten (Variable)
    buildTransferData(structure, mapping)
    erstelle Übertragungsdaten (Struktur, Abbildung)
    boolean Ok
    Boolesch (Datentyp) Ok
    server
    Server
    receivePublishedArchitecture
    empfange veröffentlichte Architektur
    if(Ok){return;}
    falls(Ok){springe zurück;}
    else{displayErrorMSG()
    sonst {zeige Fehlermitteilung an();
    requestComplianceStatus()
    fordere Konformitätsstatus an()
    publishComplianceStatus()
    veröffentliche Konformitätsstatus()
    ComplianceStatusModel
    Konformitätsstatusmodell
    complianceStatus
    Konformitätsstatus
    retrieveComplianceStatusModel()
    gewinne Konformitätsstatusmodell wieder()
    setComplianceStatus(compliance)
    setze Konformitätsstatus (Konformität)
    visualizeComplianceStatus()
    visualisiere Konformitätsstatus()
    void
    leer (Datentyp)
    monitorCodeandSendDelta()
    überwache Code und sende Delta()
    DevelopmentMonitor
    Entwicklungsüberwachungseinrichtung
    Files
    Dateien
    modifiedFiles
    modifizierte Dateien
    determineLocalDelta
    bestimme lokales Delta
    ResourcesPlugin
    Ressourcen-Plug-In
    getWorkspace
    erhalte Arbeitsbereich
    getRoot
    erhalte Hauptverzeichnis
    getProjects()
    erhalte Projekte()
    buildTransferData
    erstelle Übertragungsdaten
    receiveDelta
    empfange Delta
    Iproject
    Abstrakte Schnittstelle Projekt
    projects
    Projekte
    foreach project in projects
    für jedes Projekt in Projekten
    foreach file in project
    für jede Datei im Projekt
    Status
    Status
    ConfigurationManagementAdapter
    Konfigurationsverwaltungsadapter
    getFileStatus
    erhalte Dateistatus
    getResource
    erhalte Ressource
    file
    Datei
    if
    falls
    MODIFIED
    MODIFIZIERT
    add
    addiere
    return modifiedFiles
    sende modifizierte Dateien zurück
    receiveLiveFeedback
    empfange Liverückmeldung
    DeltaResultModel
    Deltaergebnismodell
    deltaResults
    Deltaergebnisse
    setDeltaResults
    setze Deltaergebnisse
    displayDeltaResults()
    zeige Deltaergebnisse an()
    getDeltaResults()
    erhalte Deltaergebnisse()
    foreach deltaResult in deltaResults
    für jedes Deltaergebnis in Deltaergebnissen
    String
    Zeichenfolge
    projectName
    Projektname
    getProjectName()
    erhalte Projketname()
    Ipath
    Abstrakte Schnittstelle Pfad
    Path
    Pfad
    getPath()
    erhalte Pfad()
    IworkspaceRoot
    Abstrakte Schnittstelle Hauptverzeichnis
    Root
    Hauptverzeichnis
    getProject
    erhalte Projekt
    projectName
    Projektname
    IcompilationUnit
    Abstrakte Schnittstelle Kompilierungseinheit
    unit
    Einheit
    project
    Projekt
    findElement
    finde Element
    getCompilationUnit()
    erhalte Kompilierungseinheit()
    clearMarker()
    lösche Markierung()
    createMarkers
    erzeuge Markierungen
    getViolation()
    erhalte Verletzung()
    updateStructuralModel
    aktualisiere Strukturmodell
    updateMapping
    aktualisiere Abbildung
    retrieveStructure()
    gewinne Struktur wieder()
    setStructure
    setze Struktur
    structure
    Struktur
    MappingModel
    Abbildungsmodell
    mapping
    Abbildung
    setMapping
    setze Abbildung
    receiveDelta
    empfange Delta
    retrieveModifiedFiles()
    gewinne modifizierte Dateien wieder()
    deltaModel
    Deltamodell
    new DeltaModel()
    neues Deltamodell()
    foreach file in modifiedFiles
    für jede Datei in modifizierte Dateien
    IcompilationUnit
    I-Kompilierungseinheit
    extractDeltaFacts
    extrahiere Deltatatsachen
    updateSourceCodeModel
    aktualisiere Quellcodemodell
    DeltaComplianceStatus
    Deltakonformitätsstatus
    DeltaCompliance
    Deltakonformität
    checkCompliance
    prüfe Konformität
    distillDeltaViolations
    destilliere Deltaverletzungen heraus
    buildTransferData
    erstelle Übertragungsdaten
    sendLiveFeedback
    sende Liverückmeldung
    DeltaSourceCodeModel
    Deltaquellcodemodell
    CompilationUnitHandler
    Kompilierungseinheitshandhabungseinrichtung
    Handler
    Handhabungseinrichtung
    new CompilationUnitHandler()
    neue Kompilierungseinheitshandhabungseinrichtung()
    parseCompilationUnit
    analysiere (”parse”) Kompilierungseinheit
    return deltaModel
    sende Deltamodell zurück
    private DeltaSourceCodeModel
    privates Deltaquellcodemodell
    ASTParser
    AST(= Abstrakter Syntaxbaum)-Parser
    newParser()
    neuer Parser()
    setSource
    setze Quelle
    CompilationUnit
    Kompilierungseinheit
    rootCU
    Hauptverzeichnis-Steuereinheit
    parser
    Parser
    createAST
    erzeuge AST
    null
    null
    if
    falls
    accept
    akzeptiere
    new ASTVisitor
    neuer AST-Besucher
    updateSourceCodeModel
    aktualisiere Quellcodemodell
    GregorianCalendar date
    Datum des gregorianischen Kalenders
    new GregorianCalendar()
    neuer gregorianischer Kalender()
    SourceCodeModel
    Quellcodemodell
    SourceModel
    Quellmodell
    getSourceCodeModel()
    erhalte Quellcodemodell()
    foreach modelElement in deltaModel
    für jedes Modellelement im Deltamodell
    exists
    existiert
    modelElement
    Modellelement
    true
    wahr
    updateState
    aktualisiere Zustand
    date
    Datum
    foreach modelDependency of modelElement
    für jede Modellabhängigkeit des Modellelements
    modelDependency
    Modellabhängigkeit
    existsInSourceCodeModel()
    existiert im Quellcodemodell()
    else
    sonst
    addModelElementWithDependencies
    addiere Modellelement mit Abhängigkeiten
    state
    Zustand
    getModificationDate
    erhalte Modifikationsdatum
    deleteDependency
    lösche Abhängigkeit
    CheckCompliance
    prüfe Konformität
    DeltaSourceCodeModel
    Deltaquellcodemodell
    LiftedCodeModel
    angehobenes Codemodell
    lift
    hebe an
    new DeltaComplianceStatus()
    neuer Deltakonformitätsstatus
    foreach plannedDependency in structure
    für jede geplante Abhängigkeit in der Struktur
    plannedSourceElement
    geplantes Quellelement
    plannedDepdency
    geplante Abhängigkeit
    getSourceElement()
    erhalte Quellelement()
    plannedTargetElement
    geplantes Zielelement
    getTargetElement()
    erhalte Zielelement()
    foreach actualDependency in liftedCodeModel
    für jede tatsächliche Abhängigkeit im angehobenen Codemodell
    actualDependency
    tatsächliche Abhängigkeit
    equals
    ist gleich
    CONVERGENCE
    KONVERGENZ
    break
    Unterbrechung
    ABSENCE
    ABWESENHEIT
    actualSourceElement
    tatsächliches Quellelement
    actualTargetElement
    tatsächliches Zielelement
    foreach plannedDependency in structure
    für jede geplante Abhängigkeit in der Struktur
    DIVERGENCE
    DIVERGENZ
    return deltaCompliance
    sende Deltakonformität zurück
    DistillViolations
    destilliere Verletzungen heraus
    foreach dependency in deltaCompliance
    für jede Abhängigkeit in der Deltakonformität
    dependency
    Abhängigkeit
    getStatus()
    erhalte Status()
    remove
    entferne
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 2009/0276757 A1 [0011]

Claims (16)

  1. Verfahren (100) zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur in Echtzeit, mit folgenden Schritten: Bereitstellen (110) eines Ausgangs-Strukturmodells (115) einer Software-Architektur, so dass das Ausgangs-Strukturmodell (115) die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt; Bereitstellen (120) einer Abbildungsvorschrift (125), so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung in Rückrichtung definiert ist; Empfangen (130) eines Delta-Quellcodeteils (135), der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist; Ermitteln (140) eines Delta-Quellcodemodells (145) basierend auf dem Delta-Quellcodeteil (135), so dass das Delta-Quellcodemodell (145) Abhängigkeiten, die in dem Delta-Quellcodeteil (135) enthalten sind, beschreibt; Ermitteln (150) eines Delta-Strukturmodells (155), das gegenüber dem Ausgangs-Strukturmodell (115) verändert, basierend auf dem Delta-Quellcodemodell (145) unter Verwendung der Abbildungsvorschrift (125), so dass das Delta-Strukturmodell (155) die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteil veränderten Delta-Quellcodeteil (135) definiert ist, beschreibt; Vergleichen (160) des Delta-Strukturmodells (155) mit einem Referenz-Strukturmodell (105), um ein Vergleichsergebnis (165) zu erhalten, das eine Regeltreue des Delta-Quellcodeteils (135) oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Delta-Quellcodeteil (135) umfasst, beschreibt; wobei bei dem Ermitteln (140) des Delta-Quellcodemodells (145), bei dem Ermitteln (150) des Delta-Strukturmodells (155) oder bei dem Vergleichen (160) des Delta-Strukturmodells (155) mit dem Referenz-Strukturmodell (105) eine Neubestimmung von Informationen, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil (135) unabhängig ist, selektiv unterdrückt oder vermieden wird.
  2. Verfahren nach Anspruch 1, bei dem das Ausgangs-Strukturmodell (115) verändert wird, um das Ausgangs-Strukturmodell (115) in das Delta-Strukturmodell (155) zu überführen.
  3. Verfahren nach Anspruch 1 oder 2, bei dem das Referenz-Strukturmodell (105) eine Soll-Vorgabe ist, die von einem Software-Architekten vorgegeben wird.
  4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem die Elemente des Strukturmodells auf einer im Vergleich zu den zugeordneten Quellcodeelementen höheren Abstraktionsebene liegen.
  5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem die durch die Abbildungsvorschrift (125) definierte Zuordnung eine Elementabbildung zwischen Elementen des Ausgangs-Strukturmodells (115) und Ausgangs-Quellcodeelementen oder eine Elementabbildung zwischen Elementen des Delta-Strukturmodells (155) und Quellcodeelementen des Delta-Quellcodemodells (145) oder eine Beziehungsabbildung zwischen Zwischenelementbeziehungen von Elementen des Ausgangs-Strukturmodells (115) und Quellcodebeziehungen von Ausgangs-Quellcodeelementen oder eine Beziehungsabbildung zwischen Zwischenelementbeziehungen von Elementen des Delta-Strukturmodells (155) und Quellcodebeziehungen von Elementen des Delta-Quellcodemodells (145) aufweist.
  6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem während des Ermittelns (140) des Delta-Quellcodemodells (145) der Programmcode des Delta-Quellcodeteils (135) geparst wird, wobei ein Quellcodeelement des Delta-Quellcodemodells (145) ein Ordner, eine Kompilierungseinheit, eine Routine, eine Variable oder eine Quellcodebeziehung ist.
  7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem die Abbildungsvorschrift (125) Benennungskonventionen für die Quellcodeelemente aufweist.
  8. Verfahren nach einem der Ansprüche 1 bis 7, wobei bei dem unveränderten Quellcodeteil die daraus zuvor abgeleiteten Abhängigkeiten beibehalten werden.
  9. Verfahren nach einem der Ansprüche 1 bis 8, wobei bei dem Vergleichen (160) konvergente, divergente oder abwesende Abhängigkeiten als Vergleichsergebnis (165) ermittelt werden.
  10. Verfahren nach Anspruch 9, bei dem die Abhängigkeiten mittels eines Reflexionsmodells (1800) ermittelt werden.
  11. Verfahren nach einem der Ansprüche 1 bis 10, bei dem das Ermitteln (140) des Delta-Quellcodemodells (145), das Ermitteln (150) des Delta-Strukturmodells (155) und das Vergleichen (160) des Delta-Strukturmodells (155) mit dem Referenz-Strukturmodell (105) ansprechend auf ein Speichern eines einzelnen Delta-Quellcodeteils (135) erfolgt, während sich andere Quellcodeteile in Bearbeitung befinden, so dass ein Software-Entwickler unabhängig von der Quellcodebearbeitung anderer Software-Entwickler eine sofortige Rückmeldung des Vergleichsergebnisses (165) empfängt.
  12. Verfahren nach einem der Ansprüche 1 bis 11, wobei bei dem Bereitstellen (110) des Ausgangs-Strukturmodells (115) das Ausgangs-Strukturmodell (115) von einem ersten Client (310) zu einem Server (320) übertragen wird, das Vergleichen (160) des Delta-Strukturmodells (155) mit dem Referenz-Strukturmodell (105) durch den Server (320) erfolgt und das Vergleichsergebnis (165) von dem Server (320) zu einem zweiten Client (330) übertragen wird.
  13. System (200) zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur, mit folgenden Merkmalen: einem Ausgangs-Strukturmodell-Bereitsteller (210), der ausgelegt ist, um ein Ausgangs-Strukturmodell (115) einer Software-Architektur bereitzustellen, so dass das Ausgangs-Strukturmodell (115) die Software-Architektur eines Software-Projekts, das durch eine Mehrzahl von Ausgangs-Quellcodeteilen definiert ist, beschreibt; einem Abbildungsvorschrift-Bereitsteller (220), der ausgebildet ist, um eine Abbildungsvorschrift (125) bereitzustellen, so dass eine Zuordnung der Elemente eines Strukturmodells zu entsprechenden Quellcodeelementen sowie eine Zuordnung in Rückrichtung definiert ist; einer Verarbeitungseinrichtung (230), die ausgebildet ist, um einen Delta-Quellcode-Teil (135) zu empfangen, der gegenüber einem entsprechenden Ausgangs-Quellcodeteil verändert ist, um ein Delta-Quellcodemodell (145) zu ermitteln, basierend auf dem Delta-Quellcodeteil (135), so dass das Delta-Quellcodemodell (145) Abhängigkeiten, die in dem Delta-Quellcodeteil (135) enthalten sind, beschreibt, um ein Delta-Strukturmodell (155) zu ermitteln, das gegenüber dem Ausgangs-Strukturmodell (115) verändert ist, basierend auf dem Delta-Quellcodemodell (145) unter Verwendung der Abbildungsvorschrift (125), so dass das Delta-Strukturmodell (155) die Software-Architektur des Software-Projekts, das zumindest durch einen gegenüber dem entsprechenden Ausgangs-Quellcodeteil unveränderten Quellcodeteil und den gegenüber dem entsprechenden Ausgangs-Quellcodeteil veränderten Delta-Quellcodeteil (135) definiert ist, beschreibt, und um das Delta-Strukturmodell (155) mit einem Referenz-Strukturmodell (105) zu vergleichen, um ein Vergleichsergebnis (165) zu erhalten, das eine Regeltreue des Delta-Quellcodeteils (135) oder eine Regeltreue eines Gesamt-Softwareprojekts, das den Delta-Quellcodeteil (135) umfasst, beschreibt, wobei bei dem Ermitteln des Delta-Quellcodemodells (145), bei dem Ermitteln des Delta-Strukturmodells (155) oder bei dem Vergleichen des Delta-Strukturmodells (155) mit dem Referenz-Strukturmodell (105) eine Neubestimmung von Informationen, die auf einem unveränderten Quellcodeteil basiert und von dem Delta-Quellcodeteil (135) unabhängig ist, selektiv unterdrückt oder vermieden wird.
  14. System (300) nach Anspruch 13, wobei der Ausgangs-Strukturmodell-Bereitsteller (210) durch einen ersten Client (310) implementiert ist, wobei die Verarbeitungseinrichtung (230) durch einen Server (320) implementiert ist und wobei die Ausgabe-Einrichtung (240) in einem zweiten Client (330) implementiert ist.
  15. System (200; 300) nach Anspruch 13 oder 14, wobei der zweite Client (320) eine Anzeige (340) aufweist, so dass das Vergleichsergebnis (165) im Wesentlichen in Echtzeit in einem Quellcodeeditor für einen Softwareentwickler dargestellt wird.
  16. Computerprogramm mit einem Programmcode zum Durchführen des Verfahrens nach Anspruch 1, wenn das Computerprogramm auf einem Computer abläuft.
DE201010001765 2010-02-10 2010-02-10 Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur Ceased DE102010001765A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE201010001765 DE102010001765A1 (de) 2010-02-10 2010-02-10 Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE201010001765 DE102010001765A1 (de) 2010-02-10 2010-02-10 Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur

Publications (1)

Publication Number Publication Date
DE102010001765A1 true DE102010001765A1 (de) 2011-08-11

Family

ID=44316420

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201010001765 Ceased DE102010001765A1 (de) 2010-02-10 2010-02-10 Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur

Country Status (1)

Country Link
DE (1) DE102010001765A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111274652A (zh) * 2018-12-04 2020-06-12 通用电气公司 所设计、所制造、所测试、所运行和所服务的耦合数字孪生生态系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1926021A1 (de) * 2006-11-27 2008-05-28 Sysopen Digia Oyj Softwaretestfallerzeugung
US20090119650A1 (en) * 2004-09-09 2009-05-07 International Business Machines Corporation Generating sequence diagrams using call trees
US20090276757A1 (en) 2008-04-30 2009-11-05 Fraunhofer Usa, Inc. Systems and methods for inference and management of software code architectures

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090119650A1 (en) * 2004-09-09 2009-05-07 International Business Machines Corporation Generating sequence diagrams using call trees
EP1926021A1 (de) * 2006-11-27 2008-05-28 Sysopen Digia Oyj Softwaretestfallerzeugung
US20090276757A1 (en) 2008-04-30 2009-11-05 Fraunhofer Usa, Inc. Systems and methods for inference and management of software code architectures

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111274652A (zh) * 2018-12-04 2020-06-12 通用电气公司 所设计、所制造、所测试、所运行和所服务的耦合数字孪生生态系统
CN111274652B (zh) * 2018-12-04 2023-11-24 通用电气公司 根据优化的制造过程制作新零件的方法和系统

Similar Documents

Publication Publication Date Title
DE10121790B4 (de) Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
Ameller et al. Dealing with non-functional requirements in model-driven development
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE112017006164T5 (de) Differenzvergleich von ausführbaren Datenflussdiagrammen
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
WO2015044374A1 (de) Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
WO2003071455A2 (de) Engineeringverfahren und engineeringsystem für industrielle automatisierungssysteme
DE102017106023A1 (de) Verfahren und System zum automatisierten Benutzerschnittstellentesten über modellgetriebene Techniken
DE102007040823A1 (de) Editier- und Berichts-Tool für Grafische Programmiersprachenobjekte
DE112013005993T5 (de) Verfahren, Vorrichtung und computerlesbares Medium für eine optimale Bestimmung von Daten-Teilmengen
EP1516250A2 (de) Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme
DE102006039829A1 (de) Verfahren und Vorrichtung zur Anbringung von Anmerkungen oder Kommentaren an Bildern
DE112020004967T5 (de) Änderungsverwaltung und analytik für microservices
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
EP1920357A1 (de) Migration und transformation von datenstrukturen
Cremer et al. Graph‐based tools for re‐engineering
DE102021116315A1 (de) Verfahren zum Zusammenführen von Architekturinformationen
DE112020000657T5 (de) Dienstverwaltung in einem dbms
DE112017002779T5 (de) Formatspezifische Datenverarbeitungsoperationen
DE102010001765A1 (de) Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur
EP1202166B1 (de) System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-Entwurfswerkzeugen
DE102016005519A1 (de) Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur
Krämer et al. Automated urban management processes: integrating a graphical editor for modular domain-specific languages into a 3D GIS
Weise et al. Supporting state-based transactions in collaborative product modelling environments
DE102017212612A1 (de) Verfahren zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs

Legal Events

Date Code Title Description
R016 Response to examination communication
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final