Proseminararbeit. Model Querys zur Überprüfung von sicherheitsrelevanten Eigenschaften. Jens Knipper 8. Juli 2015

Transkript

1 Proseminararbeit Model Querys zur Überprüfung von sicherheitsrelevanten Eigenschaften Jens Knipper 8. Juli 2015 Prof. Dr. Jan Jürjens Lehrstuhl 14 Software Engineering Fakultät Informatik Technische Universität Dortmund Otto-Hahn-Straße Dortmund

2 Jens Knipper Matrikelnummer: Studiengang: Bachelor Angewandte Informatik Prüfungsordnung: BPO2007 Proseminar: Werkzeugunterstützung für sichere Software Thema: Model Querys zur Überprüfung von sicherheitsrelevanten Eigenschaften Eingereicht: 8. Juli 2015 Betreuer: Jens Bürger Prof. Dr. Jan Jürjens Lehrstuhl 14 Software Engineering Fakultät Informatik Technische Universität Dortmund Otto-Hahn-Straße Dortmund

3 i

4 ii Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Dortmund, den 8. Juli 2015 Jens Knipper

5 INHALTSVERZEICHNIS iii Inhaltsverzeichnis 1 Einleitung 1 2 Modellgetriebene Softwareentwicklung Grundkonzepte Zusammenfassung Eclipse Modeling Framework Einführung Technologie UML XML Model Querys EMF Validation Framework Validierung Vor- und Nachteile EMF Model Queries Vor- und Nachteile EMF-IncQuery Querys Vor- und Nachteile Überprüfung sicherheitsrelevanter Eigenschaften Sicherheitsrelevante Eigenschaften Überprüfung Fazit 12 Literaturverzeichnis 13

6 iv INHALTSVERZEICHNIS

7 KAPITEL 1. EINLEITUNG 1 1 Einleitung Die Modellgetriebene Softwareentwicklung stellt eine besondere Art der Programmierung dar, welche durch ihre Nähe am Modell und ihrer Übersichtlichkeit eine einfach zu erlernende Art der Programmierung darstellt. Die automatische Erzeugung des Codes ermöglicht es diese auch besonders leicht zu testen. Das macht vor allem das Auffinden von Sicherheitslücken einfacher und erhöht die Qualität des Codes. Für diese Funktionen gibt bereits einige sehr gute Lösungen, von denen einige im Rahmen diese Seminararbeit vorgestellt werden. Model Querys sind ein elementarer Bestandteil der Modellgetriebenen Softwareentwicklung und dienen zur Validierung und der Simulation von Modellen. Mit ihnen ist es möglich das Modell automatisiert auf bestimmte Eigenschaften zu untersuchen. In dieser Arbeit liegt der Fokus auf das Überprüfen von sicherheitsrelevanten Eigenschaften. Dies soll eine höhere Qualität der Software und ein hohes Maß an Sicherheit garantieren. Dies ist vor allem bei wachsenden Systemen von Vorteil, da dadurch eine durchgängige Sicherheit garantiert werden kann. Der erste Teil der Arbeit wird auf die Modellgetriebene Softwareentwicklung eingehen und die dahinter stehenden Verfahren und Arbeitsabläufe genauer erläutern. Die dahinterstehenden Sprachen, die Modellierungssprachen, werden im Anschluss daran erklärt. Als Beispiel dienen hierbei UML und textuelle Modelle. Nachdem die Grundlagen geschaffen wurden, gehe ich auf ein praktisches Beispiel für die Modellgetriebene Softwareentwicklung, dem Eclipse Modeling Framework, ein. An diesem sollen Vorgänge und Arbeitsabläufe näher erläutert werden. Anhand des Frameworks soll die Funktionsweise von Queries auf Modellen erläutert werden und diese anschließend zum testen auf Sicherheitsrelevante Eigenschaften genutzt werden.

8 2 2 Modellgetriebene Softwareentwicklung Die Modellgetriebene Softwareentwicklung (engl. Model Driven Development, MDSD) ist eine Weiterentwicklung der Programmierung, in der Modelle, z.b. in Form von UML-Diagrammen, nicht mehr allein zum Zweck der Dokumentation von Software dienen. Stattdessen sind sie mit dem Code gleichzusetzen, welcher automatisch aus Modellen erzeugt werden soll. So sollen Inkonsistenzen und hoher Anpassungsaufwand vermieden werden.[hvse12] 2.1 Grundkonzepte Um modellgetrieben entwickeln zu können, wird eine Modellierungssprache benötigt. Mit dieser können Modelle erstellt werden, aus welchen, z.b. von einem Interpreter, Code erstellt werden kann. Dabei ist es unwichtig, welche Art von Modell genutzt und wie der Code umgewandelt wird. In der Praxis wird dies, allerdings häufig durch das benutzte Tool vorgegeben. [HVSE12] Um generierten und selbst geschriebenen Code voneinander zu trennen, wird häufig die dreistufige Vererbung genutzt (siehe Abbildung 2.1). In der Plattformschicht befinden sich die Basisklassen zur Erstellung von Modellen. Daraus können in der Modellschicht Zwischenklassen abgeleitet werden, welche dort als Teil des Modells auftauchen. Die letzte Schicht ist manuell implementiert, was von den entsprechenden Entwicklern vorgenommen wird, die entsprechende Modelle erstellen. [HVSE12] Abbildung 2.1: Die Dreistufige Vererbung. [HVSE12]

9 KAPITEL 2. MODELLGETRIEBENE SOFTWAREENTWICKLUNG Zusammenfassung Der größte Vorteil der Modellgetriebenen Softwareentwicklung ist die Programmierung in einer höheren Abstraktionsebene [HVSE12], wodurch Zusammenhänge schneller deutlich werden und die Komplexität des Programms auf einzelne Bausteine, z.b. Entitäten, reduziert wird. Daraus resultiert auch, dass der Code einheitlich, immer auf dieselbe Art und Weise, übersetzt wird und somit frei von persönlichen Stilen und Präferenzen ist [HVSE12]. Durch die Gleichsetzung von Code und Modell, werden Inkonsistenzen und Aufwand für Anpassungen an den Modellen vermieden. Dies führt zu einer besseren Dokumentation und einer erheblichen Zeitersparnis. Da für ein Modell verschiedene Generatoren benutzt werden können, kann aus diesem, Software in verschiedenen Sprachen und für verschiedene Plattformen entwickelt werden [HVSE12]. Trotz des hohen Anteils an generiertem Code, muss in den meisten Fällen noch Code ergänzt werden, da mit der Modellgetriebenen Entwicklung meist nur ein Grundrahmen und keine große Funktionalität geschaffen werden kann [SBMP08].

10 4 3 Eclipse Modeling Framework Das Eclipse Modeling Framework (kurz EMF) ist ein mächtiges Werkzeug, um modellgetrieben in Java zu entwickeln. Es ist ein Framework in Eclipse, welches die Grundkonzepte der Modellgetriebenen Softwarentwicklung umsetzt. Verschiedene Arten von Modellen können damit einfach ineinander umgewandelt werden und zum Erzeugen von Code benutzt werden. Dabei soll laut [SBMP08] der generierte Code genau so sauber, einfach und effizient sein, wie selbst geschriebener. Zusätzlich zur Entwickeln ist es mit dem EMF möglich Modelle mittels Querys zu validieren. 3.1 Einführung Das Framework vereinigt verschiedene Sprachen,welche wie in Abbildung 3.1 zu sehen ist, alle ineinander umgewandelt werden können. Abbildung 3.1: Das Eclipse Modeling Framework vereinigt XML, UML und Java. [SBMP08] Zusätzlich ist es möglich aus Java-Interfaces Modelle zu erzeugen [SBMP08]. Dies ist ein elementarer Bestandteil des Frameworks, da alle Modelle in entsprechende Interfaces umgewandelt werden und die eigentliche Programmierung in extra dafür bereitgestellten Dateien stattfindet. So wird eine einheitliche Trennung von automatisiertem und selbst geschriebenem Code gewährleistet und Inkonsistenzen zwischen diesen vermieden. 3.2 Technologie Das EMF enthält ein Metamodell, welches die Regeln der Modellerstellung definiert. Daraus folgt, dass sämtliche Modelle nur nach dem vorgegebenen Schema erstellbar sind. Alle Objekte stammen laut Vorgabe von der Oberklasse EObject ab. Die daraus

11 KAPITEL 3. ECLIPSE MODELING FRAMEWORK 5 abgeleiteten Elemente bilden die Basisklassen in der dreistufigen Vererbung und sind in Abbildung 3.2 zu sehen. Zu diesen Elementen gehören unter anderem Referenzen (EReference), Attribute (EAttribute), Datentypen (EDataType) und Klassen (EClass). Abbildung 3.2: Das Ecore-Metamodell. [SBMP08] Die Hauptelemente sind dabei Klassen, welche mittels Referenzen Assoziationen untereinander bilden. Zudem können Klassen mehrere Attribute haben, die immer von einem bestimmten Datentyp sind (Abbildung 3.2). Vererbung ist laut [BURV] ebenfalls möglich. Auf dem ersten Blick ist ersichtlich, dass das Metamodell in seinem Aufbau dem der UML-Klassendiagramme entspricht. Es definiert Regeln zur Erstellung entsprechender Diagramme UML UML ist eine der am weitesten verbreiteten Modellierungssprachen. Durch die Vielzahl an unterschiedlichen Modellen ist es möglich ein System aus verschiedenen Sichtweisen zu beschreiben. Dadurch wird es möglich größere Softwarearchitekturen und komplette Programmabläufe übersichtlich zu modellieren. Das Eclipse Modeling Framework unterstützt nur die Umsetzung von UML-Klassendiagrammen und der daraus folgenden Generierung von Code. Weitere Modelle werden von dem Framework nicht beachtet uns sind somit in diesem Zusammenhang unwichtig. Das Abbildung 3.3: Beispiel eines UML-Diagramms, welches einen Supermarkt modelliert. Beispiel in Abbildung 3.3, welches das Einkaufen in einem Supermarkt simuliert, wird auch im weiteren Verlauf zum Erläutern diverser Techniken genutzt werden.

12 TECHNOLOGIE XML XML ist ein Sprache, mit der unter Anderem textuelle Modelle beschrieben werden können. Diese gelten im Vergleich zu den grafischen, als weniger gut leserlich, was vor allem daran liegt, dass diese Assoziationen etc. nicht so stark hervorheben, wie es z.b. bei UML der Fall ist. Abhängigkeiten und Zugehörigkeiten werden so nicht so schnell ersichtlich. Die Leserlichkeit kann trotzdem durch Einrückung und einer farbigen Darstellung verbessert werden (vgl. [HVSE12]). Wie in Abbildung 3.1 zu sehen ist es möglich mit XML Modelle für das Eclipse Modeling Framework zu definieren. Für den weiteren Verlauf der Ausarbeitung ist die Sprache allerdings nicht mehr relevant.

13 KAPITEL 4. MODEL QUERYS 7 4 Model Querys Model Querys dienen der unter anderem der Validierung und der Simulation von Modellen in der Modellgetriebenen Softwareentwicklung [BURV]. Dafür gibt es einige Lösungen für das Eclipse Modeling Framework. Zum einen wird durch das Validation Framework und das Query Framework, im EMF integrierte Lösungen bereitgestellt diese durchzuführen, als auch durch die Erweiterung EMF IncQuery. Im folgenden sollen die Unterschiede zwischen diesen herausgestellt und die jeweiligen Stärken und Schwächen erläutert werden. 4.1 EMF Validation Framework Das Validation Framework ist ein Bestandteil des Eclipse Modeling Framework und bietet die Möglichkeit, mittels Beschränkungen und Invarianten, Modelle zu validieren. Diese können direkt in das Modell eingetragen werden, wobei der zugehörige Code automatisch genieriert wird und durch den Nutzer erweitert werden kann, bzw bei Invarianten auch erweitert werden muss ([SBMP08]) Validierung Die Möglichkeiten der Validierung bestehen darin, Beschränkungen und Invarianten zu erstellen. Beschränkungen gelten nur für einen bestimmten Zeitpunkt. Das kann z.b. eine Vorbedingung oder ähnliches sein ([SBMP08]). Wie diese im Code des Java-Interfaces deklariert werden ist in Listing 4.1 zu sehen. 1 / annotation = http : / /www. e c l i p s e. org /emf /2002/ Ecore c o n s t r a i n t s = ValidPrice 3 / 4 p u b l i c i n t e r f a c e Product 5 { } Listing 4.1: Deklaration einer Beschränkung Dies kann stattdessen auch im XML-Schema oder mittels der grafischen Oberfläche in Eclipse realisiert werden. Bei der Code-Generierung wird anschließend eine Validator-Klasse erzeugt, in der die Beschränkung in einer ebenfalls generierten Methode genauer spezifiziert werden muss ([SBMP08]). In unserem Beispiel soll der Preis eines Produktes (Abbildung 3.3) zu einem bestimmten Zeitpunkt nicht negativ

14 EMF MODEL QUERIES sein. Dies muss nur, wie in Listing 4.2 zu sehen ist, in die entsprechende if-anweisung eingetragen werden. 1 p u b l i c boolean v a l i d a t e P r o d u c t V a l i d P r i c e ( Product product, DiagnosticChain d i a g n o s t i c s, Map<Object, Object> context ) { 2 i f ( product. g e t P r i c e ( ) < 0) { } 5 return true ; 6 } Listing 4.2: Erstellen einer Beschränkung Aus Gründen der Übersichtlichkeit wurde generierter Code entfernt, in welchem die Auswertung im Fehlerfall spezifiziert wird. Die erzeugten Variablen diagnostics und context sind dafür notwendig ([SBMP08]). Invarianten sollen zu jedem Zeitpunkt gültig sein und sind dementsprechend mächtiger als Beschränkungen. Sie werden als Methoden in der entsprechenden Klasse definiert. Im Anschluss muss, ähnlich wie bei den Beschränkungen, eine Bedingung vervollständigt werden ([SBMP08]) Vor- und Nachteile Die Sprache eignet sich, durch die Möglichkeit Beschränkungen und Invarianten zu beschreiben, nur zur Validierung des Modells und nicht dazu Querys auf diesem durchzuführen. Das durchführen von Querys auf Modellen, mittels des Query Frameworks, wird im folgenden Kapitel behandelt. 4.2 EMF Model Queries Das Query Framework unterstützt die Object Constraint Language (OCL), um mit dieser Querys auf Modellen durchzuführen ([EMFb]). OCL ist eine Erweiterung von UML und dient dazu Beschränkungen für Objekte zu definieren. Anhand dieser Beschränkungen kann eine Query auf ein Modell durchgeführt werden ([Ber]). Wie im Beispiel, in Listing 4.3, muss zunächst eine Beschränkung definiert werden, Diese wird benötigt,um eine SQL-artige Query auf dem Modell durchzuführen. In dem Beispiel wird überprüft, ob es ein Produkt gibt, dessen Preis unter 0 liegt. 1 Resource myresource = products 2 3 OCL o c l = org. e c l i p s e. o c l. e c o r e.ocl. newinstance ( ) ; 4 Condition c o n d i t i o n = new BooleanOCLCondition<E C l a s s i f i e r, EClass, EObject >( 5 o c l. getenvironment ( ), 6 s e l f. g e t P r i c e ( ) < 0, 7 EXTLibraryPackage. L i t e r a l s.writer) ; 8 9 SELECT statement = new SELECT(SELECT.UNBOUNDED, f a l s e, 10 new FROM( myresource. getcontents ( ) ), new WHERE( c o n d i t i o n ), 11 new NullProgressMonitor ( ) ) ; IQueryResult r e s u l t s = statement. execute ( ) ; Listing 4.3: Eine einfache OCL-Query. [EMFa]

15 KAPITEL 4. MODEL QUERYS 9 Des weiteren ist es möglich mehrere Beschränkungen in einer Query mittels logischer Operationen miteinander zu verknüpfen und so fortschrittlichere Anfragen auszuführen ([EMFb]) Vor- und Nachteile Die Sprache ermöglicht ein einfaches Abfragen von Bedingungen auf Objekten. Sie ist allerdings nicht ausdrucksstark genug für fortschrittlichere Anwendungsfälle. Es fehlen immer noch wichtige Features, wie zum Beispiel Rekursion. Zudem können Referenzen nicht rückwärts durchlaufen werden ([BURV]). Zur Überprüfung Sicherheitsrelevanter Eigenschaften ist sie somit nur eingeschränkt geeignet. 4.3 EMF-IncQuery EMF-IncQuery ist eine graphenbasierte Anfragesprache für EMF-Modelle. Mit ihr ist es möglich sowohl globale Model Querys, welche das gesamte Modell auswerten, als auch lokale Model Querys, welche nur Informationen bezüglich eines gegebenen Modell-Elements zurückgeben. Das Ziel ist es eine präzise und gut verständliche Sprache, welche an die Modelle des EMF angepasst ist, zu bieten ([BURV]) Querys Im Folgenden soll EMF-IncQuery anhand eines Beispiels genauer erläutert werden. Als Ausgangspunkt dient hierbei ebenfalls Abbildung 3.3, das UML-Diagramm von einem Supermarkt. In Listing 5.1 wird eine Query durchgeführt, welche überprüft, ob ein übergebenes Produkt queryproduct einen negativen Preis besitzt. 1 pattern v a l i d P r i c e ( queryproduct ) = { 2 Product ( queryproduct ) ; 3 EFloat ( queryproduct. p r i c e ) ; 4 check ( queryproduct. p r i c e > 0) ; 5 } ; Listing 4.4: Eine einfache Query. Die erste zu erfüllende Bedingung ist, dass queryproduct vom Typ Product ist. Das enthaltene Attribut, der Preis des übergebenen Produktes, soll den im Modell vorgegebenen Typen, float, haben. Danach ist sichergestellt, dass der Vergleich des Preises von queryproduct anwendbar ist. Dieser wird in der folgenden Zeile mittels check durchgeführt. Nun ist es ein leichtes die Query auf alle Artikel des Store durchzuführen. Dazu kann einfach die bereits erstellte Query wiederverwendet werden Vor- und Nachteile Mittels EMF-IncQuery ist es einfach ausdrucksstarke Querys zu spezifizieren und Modelle dadurch zu validieren. Die Möglichkeit einer transitiven Hülle und Rekursion, sowie das Erzeugen von Java-Ausdrücken sind durch die Sprache gegeben ([BURV]). Zudem ist sie kurz und prägnant, was das Lesen und Erlernen deutlich einfacher macht. Zur Überprüfung Sicherheitsrelevanter Eigenschaften ist sie somit sehr gut geeignet.

16 10 5 Überprüfung sicherheitsrelevanter Eigenschaften Der Aspekt Sicherheit wird in der heutigen Zeit der Softwareentwicklung immer wichtiger und sollte möglichst in den Prozess dieser einbezogen werden. Um dies zu gewährleisten ist eine automatische Überprüfung der sicherheitsrelevanten Eigenschaften besonders praktisch ([MWY]). Verschiedene Arten sicherheitsrelevanter Eigenschaften für Software sollen im folgenden Kapitel erläutert werden und beispielhaft anhand einer Query überprüft werden. 5.1 Sicherheitsrelevante Eigenschaften Sicherheitsrelevante Eigenschaften werden formuliert, um Dinge, wie Daten, Personen oder beides, zu schützen. Ein Beispiel dafür ist laut [MWY] unter Anderem Zugriffskontrolle. Es soll sichergestellt werden, dass der Zugriff zu sensiblen Daten nur an autorisierten Benutzern gewährt wird, um Missbrauch dieser zu vermeiden. Allerdings müssen die Nutzer genug Berechtigungen haben, um mit der Software ihre Arbeit erledigen zu können. Weitere Eigenschaften sind zum Beispiel, dass bestimmte Daten verschlüsselt übertragen werden sollen. Die Lösung des Problems, besteht darin entweder die entsprechenden Daten oder den gesamten Datenverkehr von Ende zu Ende zu verschlüsseln ([BGR + ]). Redundanz ist eine weitere Eigenschaft, welche vor allem bei Datenbanken etc. besonders wichtig ist. Sie soll vor Datenverlust und schützen und die Integrität der Daten bewahren ([BURV]). Die benötigten Eigenschaften sollten allerdings immer mit bedacht gewählt werden, da sich diese gegenseitig widersprechen können. Beispiele dafür sind unter anderem Nachweisbarkeit und Anonymität. Für solche Paradigmen wird es schwer Querys zu formulieren, die nicht verletzt werden ([BGR + ]). 5.2 Überprüfung Die Überprüfung von Sicherheitsrelevante Eigenschaften soll mittels EMF Inc-Query geschehen, da diese von den bereits genannten Anfrage-Sprachen die mächtigste und vergleichsweise einfachste ist. In [BURV] werden zwei sicherheitsrelevante Eigenschaften auf einem gegebenen Modell überprüft. Bei dem Modell müssen Akteure, welche sich untereinander vertrauen, Anforderungen erfüllen. Aufgaben können von Akteur zu Akteur weitergereicht werde. Dabei soll sichergestellt werden, dass nur ein Akteur eine Anforderung abschließt, welcher vertrauensvoll ist oder der Pfad an Zwischenakteuren vertrauensvoll ist und dass dieser mehrmals, Redundant, ab-

17 KAPITEL 5. ÜBERPRÜFUNG SICHERHEITSRELEVANTER EIGENSCHAFTEN 11 geschlossen wird. Das Modell und die Querys in dem Beispiel sind allerdings sehr komplex und nicht für diese Ausarbeitung geeignet, weshalb dieses in einer vereinfachten Form erläutert wird. Ein vereinfachtes Modell könnte wie in Abbildung 5.1 aussehen. Akteure können sich Abbildung 5.1: Vereinfachtes Modell gegenseitig vertrauen und Aufgaben abschließen. Ein einfaches Beispiel zur Überprüfung der Redundanz eines Objektes wird in Listing 5.1 dargestellt. 1 pattern redundancyoa ( redundancydegree ) = { 2 f i n d t r u s t R e f e r e n c e ( object, redundancydegree ) ; 3 } 4 5 pattern redundancy ( object, redundancydegree ) = { 6 check ( redundancydegree <= count o b j e c t ) ; 7 } Listing 5.1: Überprüfung auf Redundanz Es wird im Pattern redundancy einfach die Häufigkeit des entsprechenden Objektes gezählt und mit dem vorgegebenen Grad der Redundanz verglichen. Die Query ist erfüllt, wenn die Anzahl an Objekten höher ist als der Grad. Um das gesamte Modell auf diese Anforderung zu testen muss diese Query nur noch auf alle Elemente durchgeführt werden. Dadurch wird die Redundanz von allen Objekten in dem Modell sichergestellt. Dies wird ermöglicht, indem in das Pattern mit einer leeren Variable als Objekt aufgerufen wird. Dadurch versucht Inc-Query die Bedingung mit jeder möglichen Kombination zu erfüllen. Die andere in [BURV] genannte Eigenschaft kann soweit vereinfacht werden, dass ein Akteur, dem vertraut wird einen Vorgang abschließen darf. Dazu muss nur ein anderer Akteur gefunden werden, welcher dem abschließenden vertraut. Dies wird durch Listing 5.2 erreicht. 1 pattern i s T r u s t e d ( t r u s t e d ) = { 2 f i n d t r u s t R e f e r e n c e ( anytruster, t r u s t e d ) ; 3 } 4 5 pattern t r u s t R e f e r e n c e ( t r u s t e r, t r u s t e d ) = { 6 Actor. t r u s t s ( t r u s t e r, t r u s t e d ) ; 7 } Listing 5.2: Überprüfung auf Vertrauen Das Pattern trustreference versucht eine Referenz zwischen den beiden übergebenen Akteuren zu finden. Dies wird im übergeordneten Pattern istrusted aufgerufen, wobei als truster eine leere Variable übergeben wird. Falls ein Pfad gefunden wird gilt die Bedingung als erfüllt.

18 12 6 Fazit Sicherheitsaspekte nehmen einen immer wichtigeren Teil in der Softwareentwicklung ein, wodurch es nötig ist diese besonders sorgfältig zu testen und möglichst früh in die Software einzubinden. Durch die Modellgetriebene Softwareentwicklung und Model Querys kann dies schon in der Projektplanung, beim erzeugen von Modellen, gemacht werden. Das spart hohen Anpassungsaufwand, führt zu einer besseren Qualität der Software und besser durchdachten Sicherheitsmechanismen, die strikt eingehalten werden können. EMF Inc-Query ist zum Testen von Eigenschaften besonders geeignet, da es eine einfach zu erlernende, aber mächtige Anfragesprache ist. Sämtliche Anfragen können dadurch abgebildet werden und zum Überprüfen auf sicherheitsrelevante Eigenschaften genutzt werden. Model Querys sind somit gut geeignet Software von Anfang an zu überwachen und bei stetig wachsenden Anforderungen dessen Sicherheit zu garantieren.

19 LITERATURVERZEICHNIS 13 Literaturverzeichnis [Ber] [BGR + ] Gábor Bergmann. Translating ocl to graph patterns extended version*. Technical report, Budapest University of Technology and Economics, Department of Measurement and Information Systems. Jens Bürger, Stefan Gärtner, Thomas Ruhroth, Johannes Zweihoff, Jan Jürjens, and Kurt Schneider. Restoring security of long-living systems by co-evolution. Technical report, Chair of Software Engineering, TU Dortmund, Germany, Fraunhofer ISST, Dortmund, Germany, Software Engineering Group, Leibniz Universit at Hannover, Germany. [BURV] Gábor Bergmann, Zoltán Ujhelyi, István Ráth, and Dániel Varró. A graph query language for emf models. Technical report, Department of Measurement and Information Systems, Budapest University of Technology and Economics, 1117 Budapest, Magyar tudósok krt. 2. [EMFa] EMF Inc-Query. Abruf: [EMFb] EMF Model Query Developer Guide. org/online_books/eclipse_documentation/eclipse_emf_model_ query_developer_guide/topic/org.eclipse.emf.query.doc/ tutorials/eclipse_emf_model_query_oclquerytutorial.html. Abruf: [HVSE12] Arno Haase, Markus Völter, Thomas Stahl, and Sven Efftinge. Modellgetriebene Softwareentwicklung. dpunkt.verlag, Heidelberg, 2 edition, [MWY] Lionel Montrieux, Michel Wermelinger, and Yijun Yu. Tool support for uml-based specification and verification of role-based access control properties. Technical report, Centre for Research in Computing and Computing Department, The Open University, Milton Keynes, UK. [SBMP08] Dave Steinberg, Frank Budinsky, Ed Merks, and Marcelo Paternostro. EMF: Eclipse Modeling Framework, Second Edition. Addison-Wesley Professional, 2 edition, 2008.