In der vorliegenden Masterarbeit wird die Optimierung der Geschäftsprozesse in der Tourismusbranche, insbesondere bei der Organisation großer Menschenmengen, mittels
eines ganzheitlichen Softwaresystems umgesetzt. Ausschlaggebende Faktoren sind hierfür Funktionalität, Benutzerfreundlichkeit, Erweiterbarkeit, Wartbarkeit und Rentabilität.
Die Arbeit umfasst das MVC-Paradigma mit allen Aspekten, die RFID-Technologie unter automatischen Identifikationssystemen und die Implementierung eines Systems zu Demonstrationszwecken. Die Zahl der RFID-Anwendungen in verschiedenen Branchen
steigt kontinuierlich, allerdings kommen wenige Implementierungen in der Tourismusbranche vor. Unternehmensübergreifende und internationale
Informationssysteme können für alle Beteiligten der Tourismusbranche Nutzen haben. In der Logistik wird der Einsatz von RFID in der Optimierung der Supply Chain Prozesse durch Informationsfluss, Lagerbestände und Transporte umgesetzt. Um auch die Geschäftsprozesse der ReiseveranstalterInnen in der Tourismusbranche effizienter und effektiver zu implementieren, die Ziele des Unternehmens zu erreichen und Zufriedenheit der KundInnen zu erhöhen, werden nach diesem Prinzip die Daten der KundInnen mithilfe
eines ePasslesegeräts in einer zentralen Datenbank gespeichert und für die weitere Bearbeitung zur Verfügung gestellt.
Inhaltsverzeichnis
1 EINLEITUNG
1.1 Kurzbeschreibung
1.2 Gliederung und Vorgehensweise
1.3 ZIELSETZUNG UND ZIELGRUPPE
2 MVC-PARADIGMA UND SOFTWAREARCHITEKTUR
2.1 Softwarearchitektur
2.1.1 Architektursichten
2.1.2 Schichtenarchitektur
2.1.3 Drei-Schichten-Architektur
2.1.4 Drei-Schichten-Architekturen bei verteilten Systemen
2.1.5 MVC und Drei-Schichten-Architektur
2.2 Entwurfsmuster
2.3 Model-View-Controller
2.3.1 Model
2.3.2 View
2.3.3 Controller
2.3.4 Beziehungen zwischen Model, View und Controller
2.3.5 Vor- und Nachteile
2.4 MVC-Frameworks
2.4.1 MVC-Frameworks in JAVA
2.4.2 ASP.NET MVC Framework
2.4.3 Eine Übersicht der PHP MVC-Frameworks
2.4.4 Phalcon Framework
2.4.4.1 Einstiegsdatei
2.4.4.2 Verarbeitungsprozess
2.4.4.3 Dependency Injection und Service Container
2.4.4.4 Model-View-Controller in Phalcon
2.4.4.5 Controller und Aktion
2.4.4.6 Model
2.4.4.7 View
2.4.4.8 Weitere Komponenten
2.4.5 Yii Framework
2.4.5.1 Einstiegsdatei
2.4.5.2 Verarbeitungsprozess
2.4.5.3 Applikationskomponenten
2.4.5.4 Controller und Aktion
2.4.5.5 Filter
2.4.5.6 Model
2.4.5.7 View
2.4.5.8 Weitere Komponente
2.4.6 Zend Framework 2
2.4.6.1 Einstiegsdatei
2.4.6.2 Verarbeitungsprozess
2.4.6.3 Model-View-Controller im Zend Framework 2
2.4.6.4 Initialisierungsprozess
2.4.6.5 Controller und View
2.4.6.6 Weitere Komponente
2.4.7 Entwicklung eines MVC-Frameworks
2.4.7.1 Einstiegsdatei: index.php
2.4.7.2 Bootstrapping: Application Klasse
2.4.7.3 Verarbeitungsprozess
2.4.7.4 Konfiguration des Frameworks: Config Klasse
2.4.7.5 Zentrale Register: Registry Klasse
2.4.7.6 Automatische Loader: Loader Klasse
2.4.7.7 Dispatcher: Dispatcher Klasse
2.4.7.8 View: View Klasse
2.4.7.Э Controller: Controller Klasse
2.4.7.10 Model: Model Klasse
2.4.7.11 Weitere Komponenten: Debugger und Translater
2.4.7.12 Zusammenfassung
2.4.8 Auswahlkriterien für PHP-Frameworks
2.4.9 Auswahl des geeigneten Frameworks
3 AUTOMATISCHE IDENTIFIKATIONSSYSTEME
3.1 RFID-Technologie
3.1.1 Geschichtliche Entwicklung der RFID-Technologie
3.1.2 Aufbau des RFID-Systems
3.1.3 Datenspeicherungskonzepte
3.1.4 Datenschutz und Datensicherheit
3.1.5 Chancen und Risiken des RFID-Einsatzes
3.1.6 Elektronischer Reisepass
4... PROTOTYPISCHE IMPLEMENTIERUNG
4.1 Webapplikationen
4.1.1 Eigenschaften
4.1.2 Vorteile
4.1.3 Nachteile
4.1.4 Entscheidungsgründe für Webapplikation
4.2 Vorgehensmodell
4.3 Ausgangssituation und Anforderungsanalyse
4.4 Nutzen der Applikation aus Sicht der Beteiligten
4.4.1 Nutzen für PilgerInnen
4.4.2 Nutzen für Reisebüros
4.4.3 Nutzen für beteiligte Dienstleistungsunternehmen
4.4.4 Nutzen für Behörden
4.5 Smart Pilgrimage System
4.5.1 Architektur
4.5.2 Entwurf der Kontextabgrenzung
4.5.3 Entwurf der Verteilungssicht
4.5.4 Anwendungsfall des Systems
4.6 Definition und Modellierung der Geschäftsprozesse
4.6.1 Modellierung des Prozessüberblicks
4.6.2 Definition der Geschäftsprozesse
4.6.3 Modellierung des Geschäftsprozesses: Anfrage-Angebot-Auftrag
4.6.4 Modellierung des Geschäftsprozesses: Pilgerdaten erfassen
4.7 Implementierung
4.7.1 Dokumentenstruktur der Anwendung
4.7.2 Einstiegsdatei der Anwendung
4.7.3 Konfiguration der Anwendung
4.7.4 Services der Anwendung
4.7.5 Datenbankverbindung
4.7.6 Zugriff auf das Passlesegerät und Daten lesen
4.7.6.1 Die View für Steuerung des ePasslesegeräts
4.7.7 Erfassung der Daten
4.7.7.1 Die View des Pilgrim-Controllers
4.7.7.2.. Der Pilgrim-Controller
4.7.7.3 Das Pilgrim-Model
4.7.8 Das Benutzerin- und Rechtemanagement
4.7.9 Internationalisierung
4.7.10 REST-ΑΡΙ
4.8 Datenschutz und Datensicherheit
5 ZUSAMMENFASSUNG
LITERATURVERZEICHNIS
ABBILDUNGSVERZEICHNIS
LISTINGSVERZEICHNIS
TABELLENVERZEICHNIS
1 Einleitung
Organisationen mit Menschenmengen haben viele Herausforderungen, die bewältigt werden müssen. Wenn viele Beteiligte bei einer Organisation dabei sind, haben sie unterschiedliche Anforderungen, und somit sind diese sehr schwer zu realisieren. Als Beispiel für solche Organisationen kann Haddsch, Umra, Kumbh Mela und Sportorganisationen wie Olympiaden genannt werden.
Bei großen Organisationen mit Menschenmengen können Probleme mit geeigneten Technologien größtenteils gelöst werden, indem die Geschäftsprozesse so optimiert werden, dass es für alle Beteiligten einen Nutzen bringt.
Bei einem solchen Gesamtsystem müssen Anforderungen der unterschiedlichen Benutzertypen unterstützt werden. Benutzertypen können Menschen oder Maschinen sein. Dafür müssen unterschiedlichen Schnittstellen angeboten werden.
Für die Implementierung eines solchen Gesamtsystems kann das MVC-Paradigma bei den besprochenen Anforderungen eine entscheidende Rolle spielen. Insbesondere bei der Fragestellung: "How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts?"[1] und aufgrund der Tatsache, dass "several problems can arise when applications contain a mixture of data access code, business logic code, and presentation code. Such applications are difficult to maintain, because interdependencies between all of the components cause strong ripple effects whenever a change is made anywhere"[2], spielt MVC bei der vorliegenden Implementation eine zentrale Rolle.
In dieser Arbeit wird aus diesem Grund einerseits das MVC-Paradigma mit samt Aspekten analysiert, andererseits wird die RFID-Technologie als unterstützendes Element des Gesamtsystems behandelt.
Damit in der Arbeit keine Wiederholung entsteht, wird hierfür die detaillierte Beschreibung der Ausgangsituation sowie der Anforderungsanalyse des konkreten Falles auf Kapitel 4.3 und für das Nutzen aus verschiedenen Sichten auf Kapitel 4.4 verwiesen.
Die Anwendung wird für die Verwaltung der Benutzertypen und für die Rechte der BenutzerInnen ein Rechteverwaltungssystem beinhalten, genauso wie eine auf REST[1] basierte Schnittstelle zur weiteren Anwendungsprogrammierung, ein Datenverwaltungssystem und nicht zuletzt die Internationalisierung des Systems.
Im Zuge der Implementierung des Entwurfsmusters des Modell-View-Controllers werden die wichtigsten Themen der Softwaretechnik behandelt.
1.1 Kurzbeschreibung
Wie in der Einleitung beschrieben wurde, wird in dieser Arbeit die Antworten auf die folgenden Fragen gesucht: Wie können organisatorische oder technische Probleme bei den Organisationen der Menschenmengen und die daraus resultierenden Folgeprobleme gelöst werden? Welche Technologien können eine realisierbare Lösung gestatten?
Für die Beantwortung der angegebenen Fragestellungen wird einerseits die Softwaresicht, andererseits die Hardwareunterstützung des vorgeschlagenen Gesamtsystems diskutiert. Damit die Antwort der angeführten Frage umfangreicher behandelt wird, wird zuerst in der vorliegenden Arbeit das MVC-Paradigma mit den theoretischen Hintergründen beschrieben, danach wird mit der Leistung der RFID-Technologie ein Gesamtsystem entwickelt. Dabei wird das MVC-Paradigma genauer analysiert und mithilfe der Implementierungsphase die Aspekte des MVC-Paradigmas umgesetzt.
Es gibt in der Literatur sehr viele Informationen über die RFID-Technologie. Aus dieser Tatsache werden in dieser Arbeit nicht alle Einzelheiten über die Hardwaresicht diskutiert.
Zu Demonstrationszwecken wird der folgende reale Fall behandelt:
Jährlich fliegen Millionen Muslime nach Mekka in Saudi Arabien um ihr Pilgerfahrtsgebot durchzuführen. Jedes Jahr erhöht sich die Anzahl der PilgerInnen. Die Organisation einer solchen Veranstaltung istfüralle Beteiligten relativ kompliziert.
In der Literatur wurden verschiedenen Lösungen für einen Teil der Problematik behandelt. In dieser Arbeit wird ein Gesamtsystem für die Lösung der Probleme, die in den Quellen[3],[4],[5] oder[6] genannt werden, vorgeschlagen. Wobei das Framework von[6] als einführende Grundlage für die vorliegende Lösung gedient hat.
Die Masterarbeit soll den konkreten Fall behandeln, dass eine entsprechende Lösung für die Problematik aller Phasen der Pilgerfahrt, nämlich beginnend vom Angebot, dem Visumsantrag, der Flugreservierung, der Hotelreservierung bis zu den Herausforderungen während der Pilgerfahrt, empfiehlt.
Die wichtigste Anforderung ist dabei, dass personenbezogene Daten der PilgerInnen in einer gut geschützten Datenbank mit einem Verschlüsselungsmechanismus auf einem separaten Datenbankserver als Applikationsserver für weitere Geschäftszwecke gespeichert werden. Die Daten von den PilgerInnen und die Applikationsdaten werden zweifach - einmal durch MVC Entwurfsmuster in der Software und einmal per Schichtenarchitektur der Systemarchitektur - getrennt. Dieses angewandte Strukturierungsprinzip verhindert die Verletzung der Privatsphäre.
1.2 Gliederung und Vorgehensweise
Die vorliegende Arbeit gliedert sich in drei Hauptteile.
Teil 1 beschäftigt sich mit dem Thema des MVC-Paradigmas, wobei es die Beschreibung der Softwarearchitekturen bis zur detaillierten Beschreibung des MVC-Entwurfsmusters beinhaltet.
Teil 2 beinhaltet eine Einführung der automatischen Identifikationssysteme und eine einführende Auseinandersetzung der RFID-Technologie mit allen Aspekten.
In Teil 3 wird eine prototypische Implementierung basierend auf dem MVC-Entwurfsmuster durchgeführt. Dabei wird die RFID-Technologie anhand eines ePasslesegeräts in einer Webapplikation integriert und die Implementierungsvorgänge des MVC-Entwurfsmusters werden in einer realen Situation erläutert. Die vorliegende Arbeit beinhaltet abschließend eine Diskussion über die gesellschaftlichen Spannungsfelder wie Privatsphäre und Datenschutz.
Zum Abschluss der Arbeit folgt eine Zusammenfassung.
1.3 Zielsetzung und Zielgruppe
Zur Förderung der Servicequalität in der Tourismusbranche ist eine Weiterentwicklung der IT-Infrastruktur und Umstrukturierung der Geschäftsprozesse notwendig. Mit der innovativen Geschäftsprozessänderung werden diese beschleunigt, die Produktivität erhöht und die Beziehung zu den KundInnen besser gepflegt.
Ziel der Optimierung der Geschäftsprozesse ist dabei, qualitativ hochwertige Dienstleistungen anzubieten und die Zufriedenheit der KundInnen zu erhöhen. Zusätzlich werden die Geschäftsprozesse effizienter gestaltet und die durch Fehler oder manuelle Arbeiten entstehenden Kosten eingespart.
Die vorliegende Masterarbeit soll SoftwareentwicklerInnen, StudentInnen und BeraterInnen helfen, einen Überblick über das MVC-Paradigma und die Integration der RFID- Technologie in einer Webapplikation zu erwerben.
Die Arbeit richtet sich speziell an EntwicklerInnen, die bereits Erfahrung mit Webapplikationen haben, und an EntscheidungsträgerInnen eines Unternehmens, die sich für die Umsetzung einer Webapplikation mit Hardwareunterstützung interessieren.
Die Theorie wurde aus Platzgründen bewusst kurz gehalten. Für weiterführende Details wird auf die reichhaltige Literatur im Literaturverzeichnis verwiesen.
2 MVC-Paradigma und Softwarearchitektur
ln der Literatur wird argumentiert, dass der Entwurf oder die Übernahme einer Architektur für die erfolgreiche Entwicklung großer Systeme entscheidend ist. [7, p. 53]
Grechenig et al. erörtern, dass im Entwurf Entscheidungen zur Mikro- und Makroarchitektur getroffen werden, wobei die Makroarchitektur den Rahmen für die Mikroarchitektur bestimmt. [8, p. 241]
Aus diesem Grund und wegen der Diskussion im Kapitel 2.1.5 beschäftigt sich der Autor zuerst mit der Architektur des Systems.
Um die Softwarearchitektur des vorliegenden Systems zu bestimmen, werden an dieser Stelle vorher die theoretischen Grundlagen erarbeitet. Damit eine Entscheidung über die Architektur des Systems, die das System skalierbar macht, getroffen wird. Dabei wird im Auge behalten, dass für alle Benutzerinnen die Möglichkeit des Zugriffs auf die entsprechenden Ressourcen besteht.
2.1 Softwarearchitektur
Einführend zur Softwaresicht der Fragestellung setzt sich der Autor mit der Definition der Architekturen auseinander.
Wie Starke [9, p. 14] nimmt der Autor dieser Arbeit von den vielen Definitionen der Literatur diejenige des IEEE Standards.
Softwarearchitekturen werden definiert als: "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution."[10]
Gemäß dieser Definition können folgenden Eigenschaften festgestellt werden:
Architektur enthält Strukturen, Komponenten, Schnittstellen und Beziehungen untereinander.
Architektur enthält sowohl statische als auch dynamische Aspekte, denn sie beschreibt eine Lösung. Erst durch eine konkrete Implementierung wird aus einer Architektur ein reales System, ein verwendbares Produkt. Architektur basiert auf Entwurfsentscheidungen und diese Entscheidungen bilden die Grundlage für den Entwurf der Komponenten. Architektur beteiligt sich von der Fragestellung bis zur Implementierung in allen Phasen mit der Softwarearchitektur. Architekturen zeigen das System aus unterschiedlichen Sichten.
Wenn es mit der Bauarchitektur verglichen wird, sind dies der Grundriss, der Lageplan, die Schnittpläne, der Elektroplan, der Wasser- und Heizungsplan. Jede dieser einzelnen Sichten beschreibt Aspekte des Gesamtsystems. Jede Sicht hat für bestimmte Stakeholder eine Bedeutung. Für Softwarearchitekturen gilt das genauso, da sie die Komplexität von Systemen verständlich und übersichtlich machen kann. Architektur abstrahiert für eine bestimmte Aufgabe nur die benötigten Informationen, um eine spezifische Sicht der Architektur darzustellen und verständlicher zu halten. Neue Projektmitarbeiterinnen können sich mit dem System schnell vertraut machen. Die Architektur hilft den Mitarbeiterinnen bei der Wartung des Systems und kann die Erweiterbarkeit eines Systems sicherstellen. Sie berücksichtigt die Auswirkungen externer Einflussfaktoren organisatorischer und technischer Art auf das System. Architektur kann die Qualität der Software gewährleisten, hierzu zählen Performanz, Flexibilität, Wartbarkeit, Funktionalität und Erweiterbarkeit. [9, pp. 14-18]
In Softwareentwicklungsprozessen spielt die Architektur eine der wichtigsten Rolle. "Sie fungiert als Brücke zwischen Analyse und Implementierung. Gleichzeitig dient die Architektur fast allen Projektbeteiligten als Leitbild oder Referenz." [9, p. 27]
Die Architektur ermöglicht die Kontrolle des Fortschritts der Software und das Management der Einhaltung der Kosten und Dauer.
Die Architektur ist wie ein Stadtplan, der alle Komponenten des Computersystems darstellt. Ohne diesen Plan ist es unwahrscheinlich ein qualitatives und funktionierendes Informationssystem zu realisieren. Mit der Analyse und Erarbeitung der Architektur wird ein einfacher Gesamtüberblick aller Systemstrukturen geschaffen.
Die Architektur kann auch als die Menge aller Komponenten eines Systems und als die Wechselwirkung dieser Komponenten betrachtet werden. In Anhang A zeigt die Abbildung [9, p. 27] die Softwarearchitektur und andere Entwicklungsaufgaben, die sich gegenseitig beeinflussen.
2.1.1 Architektursichten
Die verschiedenen Sichten können praxisrelevante Softwarearchitekturen beschreiben. Diese können mit unterschiedlichen Werkzeugen erstellt werden.
Starke gibt eine Liste von diversen Plänen beim Entwurf und Bau von Immobilien als Bespiel zur Motivation. Diese verschiedenen Pläne dienen ihrer Zielgruppe bezüglich ihrer jeweiligen Projektaufgabe. Sie "sind allesamt Modelle, d.h. Abstraktionen der Realität. Kein einzelner Plan gibt die gesamte Komplexität eines Hauses wieder, jeder Plan (jede Sicht) vernachlässigt gewisse Details". [9, p. 78]
In der Abbildung 4.3 [9, p. 80] sind die vier wichtigsten Arten von Sichten - Kontextabgrenzung, Laufzeitsichten, Bausteinsichten, Verteilungssichten - gezeigt.
Sichten haben Wechselwirkungen und besitzen meistens Abhängigkeiten. Kontextabgrenzungen beschreiben die Schnittstellen zu Nachbarsystemen, die Interaktionen mit den wichtigsten Beteiligten und die wesentlichen Teile der Infrastruktur. Bausteinsichten beschreiben ausgehend von einer Kontextsicht den internen Aufbau eines Systems.
Laufzeitsichten beschreiben das Zusammenwirken von Bausteinen während der Laufzeit. Verteilungssichten beschreiben die Hardwarekomponenten der Systemumgebung.
Eine Architektur soll grundsätzlich wegen ihrer Komplexität und Vielschichtigkeit aus mehreren Sichten beschrieben werden. Dieses Prinzip ermöglicht die Konzentration auf einzelne Aspekte und bestimmte Details des Systems, weil alle Projektbeteiligten unterschiedliche Bedürfnisse haben, zeigt eine Sicht das System aus einer bestimmten Perspektive. EntwicklerInnen haben andere Bedürfnisse bei der Softwareentwicklung als Projektleiterinnen oder AuftraggeberInnen. [9, pp. 78-79]
Dokumentationen von Software, Entwicklungsprozessen und Architektur haben ebenso verschiedene Sichten. "Die Diagramme oder textlichen Beschreibungen einer Sicht können auch unterschiedliche Abstraktionsebenen oder Detaillierungsstufen beschreiben. Damit können sie verschiedene Teile einer einzigen Sicht beispielsweise für unterschiedliche Adressaten nutzen." [9, p. 79] Die EntwicklerInnen und EntscheidungsträgerInnen bekommen somit unterschiedliche Darstellungen und Dokumente.
2.1.2 Schichtenarchitektur
Ein Netzwerk bzw. das Internet ist grundsätzlich nichts anderes als eine Menge von Computern, die miteinander mittels unterschiedlicher Medien verbunden sind und über ein vereinbartes Protokoll Daten austauschen können. Die Medien wie Hardware, Kabel oder Software ermöglichen die Kommunikation zwischen beteiligten Computern bzw. Computersystemen.
Die Schichtenarchitektur ist ein oft verwendetes Strukturierungsprinzip für die Architektur von Softwaresystemen. Das Prinzip besagt, dass alle Aspekte des Softwaresystems in unterschiedlichen Schichten unterteilt werden sollen, wobei Zwei-Schichten-, DreiSchichten- oder Mehrschichtenmodelle Bespiele dafür sind.
Bei der Client-Server-Architektur läuft die Datenbankanwendung mit allen Daten auf der Serverseite und die Anwendung selbst, die die Verarbeitung der Daten durchführt, auf der Clientseite.
Bei der Drei-Schichten-Architektur wird die Anwendung in weitere zwei Teile aufgeteilt. Die Anwendungslogik läuft genauso wie das Zwei-Schichten-Modell auf einem Server, meistens auf einem Webapplikationsserver, und übernimmt die Verarbeitung der Daten. Auf der Clientseite bleibt die Aufgabe der Interaktion, nämlich die Kommunikation mit den Endbenutzerinnen. Als Beispiel für diese Architektur ist die vorliegende Arbeit oder SAP R/3 zu nennen.
Für das Mehrschichtenmodell kann beispielsweise das ISO/OSI-Modell[2] genannt werden. Dieses Modell wird allgemein als Sieben-Schichten-Modell bezeichnet. Es wird für die Kommunikation zwischen zwei oder mehreren Computern in einem Netzwerk eingesetzt. Eine effiziente und genau überlegte Architektur ist die Grundlage für ein stabiles Gesamtsystem.
Eine Schichtenarchitektur ist hinsichtlich der Art und Anzahl ihrer Schichten nicht beschränkt.
Im nächsten Kapitel werden weiter die Drei-Schichten-Architekturen bei verteilten Systemen behandelt. Für weitere Details über Client-Server-Architektur oder Mehrschichtenarchitektur wird auf die Literatur[7] verwiesen.
2.1.3 Drei-Schichten-Architektur
In der folgenden Abbildung wird das Prinzip der Architektur mit UML-Notation dargestellt. Dabei ist ersichtlich, dass höhere Schichten tiefere Schichten verwenden bzw. darauf zugreifen können, aber im Gegensatz dazu können die tieferen Schichten die höheren nicht sehen bzw. verwenden.
Hinsichtlich der Ausprägung der Architektur werden strenge oder flexible Trennungen der Schichten bevorzugt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1.3-1: Drei-Schichten-Architektur, vgl.[11]
Die dreischichtige Architektur besteht, wie in der Abbildung 2.1.3-1 gezeigt, aus den folgenden Schichten: [7, p. 57]
1. Präsentationsschicht: zuständig für die Interaktion mit Benutzerinnen
2. Anwendungsschicht: zuständig für die Verarbeitung der Anwendungslogik
3. Datenhaltungsschicht: zuständig für die Verwaltung der persistenten Daten
Für weitere Details über Systemarchitekturen und Beschreibung der Mehrschichtenarchitekturen verweist der Autor an dieser Stelle den Leser oder die Leserin auf die Literatur[7].
2.1.4 Drei-Schichten-Architekturen bei verteilten Systemen
Server erledigen mehr als nur den Abruf von Dokumenten, sie ermöglichen im Rahmen einer Drei-Schichten-Architektur die Ausführung aller Arten von Programmen. [7, p. 593] Drei-Schichten-Architekturen bei verteilten Systemen ermöglichen die Auftrennung der Präsentationsschicht, Anwendungsschicht und Datenhaltungsschicht auf separate Systeme. Diese Trennung ermöglicht für alle Benutzerinnen den Zugriff auf die Dienste. Zum Beispiel kann ein Benutzertyp per Browser die Dienste verwenden, während ein anderer Benutzertyp per API-Schnittstelle die Dienste verwendet.
Die Architektur erhöht die Skalierbarkeit des Systems und die bessere Verwaltung der einzelnen Schichten.
Aus diesem Grund basiert die vorgeschlagene Implementierung auf der Drei-SchichtenArchitektur. Folglich können die personenbezogenen Daten in einer separaten Datenbank mit einem guten Verschlüsselungsmechanismus gepflegt werden. Dieser Ansatz gewährleistet die Erfüllung der Anforderungen bezüglich Datenschutz und Datensicherheit, die in Kapitel 4.3 behandelt werden. Dieser ermöglicht auch die Reduzierung der Komplexität von Abhängigkeiten innerhalb des gesamten Systems und somit kann die Unabhängigkeit der einzelnen Komponenten erreicht werden.
2.1.5 MVC und Drei-Schichten-Architektur
Dieses Kapitel ist der Diskussion über den Unterschied von Drei-Schichten-Architektur und MVC gewidmet. Dies ist die Folge des vorherigen Kapitels 2.1, das als Grundlage zum Verständnis gedient hat.
Grechenig et al. argumentieren, dass MVC ein Beispiel für den Übergang zwischen Architekturmuster und Entwurfsmuster ist [8, p. 232]. Der Autor dieser Arbeit und die Autoren des folgenden Zitats vertreten dieses Argument nicht.
"Wir haben in der Praxis und in der Literatur schon häufiger eine Interpretation von MVC vorgefunden, die unserer Meinung nach einfach falsch ist." [12, p. 516]
Lahres und Rayman argumentieren, dass MVC bloß ein Entwurfsmuster für die Implementierung der Präsentationsschicht ist. [12, p. 517]
Die Präsentationsschicht bedient in beiden Fällen ähnliche Zwecke, jedoch spielen die Anwendungs-und Datenhaltungsschicht unterschiedliche Rollen.
MVC sollte nicht mit der Schichtenarchitektur verwechselt werden, denn diese ist nur für die Trennung der Komponenten innerhalb einer Software zuständig.
Das Modell ist nicht für die Umsetzung der Datenhaltungsschicht zuständig, also nicht für die Persistenz der Daten. Ein Modell, wie der Name verrät, bildet diese Daten ab, und ist ausschließlich eine Referenz für persistente Daten.
Im Gegenteil dazu liegt die Idee hinter der Drei-Schichten-Architektur in der Trennung von Anwendung und Datenhaltung.
Zum Verständnis sollen folgende Abbildungen analysiert werden. Im ersten Fall, wie aus der Abbildung 2.1.5-1 hervorgeht, wird die Anwendungsschicht wie ein Controller angenommen, und in diesem Fall übernimmt die Datenhaltungsschicht die Rolle des Modells. Allerdings beinhaltet kein Modell die Daten persistent, weil es die Daten nicht dauerhaft speichert. Die Daten werden in einer Datenbank, in einer Datei usw. gespeichert. Ein gutes Beispiel ist aus Yii Framework zu entnehmen, wobei Yii zwei verschiedene Modelle anbietet. Eines ist das CFormModel, das andere ist das CActiveRecord. Das letzte abstrahiert die Tabellen in einer Datenbank. Es bildet die Zeilen der Tabelle als ein Objekt ab. Ein aus CFormModel erweitertes Modell hingegen bildet die Form einer HTML-Seite ab. Jedes Input-Element der Form entspricht einer Spalte der Datenbank. In beiden Modellen können die Daten nicht dauerhaft gespeichert werden. Sie bilden die echten
Daten einer Datenhaltungsschicht ab. Aus diesem Grund sollte die Datenhaltungsschicht nicht mit Modellen verwechselt werden.
Die Verarbeitung der Daten wird im Modell durchgeführt. Angenommen dies in der Anwendungsschicht passiert, dann übernimmt die übrig gebliebene Datenhaltungsschicht die Rolle des Controllers, wie es in der Abbildung 2.1.5-2 dargestellt ist. In diesem Fall ist der Vergleich der Drei-Schichten-Architektur mit dem MVC ganz falsch, weil der Controller keine Daten verwalten kann. Ganz im Gegenteil soll ein Controller nicht einmal auf die Daten direkt zugreifen können, das bedeutet, dass ein Controller in einer Datenbank keine der CRUD-Operationen durchführen darf.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1.5-2: Drei-Schichten- Architektur und MVC Vergleich 2
Irfan argumentiert: " [...] ließe sich die Vereinigung aus anwendungsrelevanten Daten und Mechanismen zu ihrer Verarbeitung - also die Logikschicht der 3-tier Architektur - als MVC-Datenmodell auffassen; jedoch bliebe der Programmsteuerung nur noch die verfehlte Rolle der Datenhaltungsschicht im MVC-Kontext."[13]
MVC besteht zufälligerweise wie die Drei-Schichten-Architektur auch aus drei Elementen nämlich "Model", "View" und "Controller". Allerdings sieht MVC bloß eine Trennung der Komponenten der Anwendung vor. Diese Komponenten sind unter anderem Klassen, Module, Plugins, Erweiterungen einer einzigen Anwendung und noch weitere. Im Gegenteil dazu bestehen Drei-Schichten-Architekturen aus mehreren Schichten bzw. mehreren Anwendungen.
Die Drei-Schichten-Architektur beschreibt die Struktur von verteilten Systemen, die einem gesamten Computersystem entspricht.
Die Drei-Schichten-Architektur verwendet meistens unterschiedliche Computersysteme, wie ein Clientsystem, einen Anwendungsserver und eventuell einen Datenbankserver.
Als Beispiel angeführt: SAP R/3 beruht auf einer dreischichtigen Architektur, wobei diese Schichten jeweils spezifische Zwecke erfüllen. Abbildung 2.1.5-3 nach Herth et al. [14, p. 109] zeigt die Architektur:
1. Präsentationsschicht übernimmt SAP GUI.
2. Ausführung und Abarbeitung der Anwendungslogik übernimmt der Applikationsserver.
3. Das Verwalten von Daten übernehmen Datenbanken.
Abbildung in dieser Leseprobe nicht enthalten
Die präsentierte Beispielarchitektur beinhaltet alle drei Schichten und somit kann diese mindestens eine auf MVC-basierte Anwendung für eine Präsentationsschicht kapseln. Unter anderem kann SAP GUI oder eine Webapplikation für SAP-Dienste auf der Basis von MVC entwickelt werden.
2.2 Entwurfsmuster
Entwurfsmuster beschreiben Lösungen der wiederholten Probleme als Best Practices.
Trotz Entwicklungen in den höheren Programmiersprachen, "die zu immer kompakteren Programmen führen, müssen für bestimmte Probleme immer wieder ähnliche Lösungen ausprogrammiert werden." [15, p. 113]
Damit man das Rad nicht ständig neu erfindet, sollte es aufgrund der Ähnlichkeiten einen Ansatz geben, der diese Problematik löst. Architekt Christopher Alexander nennt als Erster den Begriff Muster im Zusammenhang mit Entwürfen. Doch der Begriff "Entwurfsmuster" hat sich erst mit dem Erscheinen des Entwurfsmusterbuchs[3] im Jahr 1995 in der Informatik durchgesetzt. [15, p. 113]
2.3 Model-View-Controller
Das MVC-Entwurfsmuster wurde in 1979 erstmals von Trygve Reenskaug beschrieben. Er hatte einen neuen Ansatz für die Entwicklung der interaktiven Applikationen bekannt gemacht, der diese in drei Teile unterteilt.
MVC wurde zusammen mit der objektorientierten Programmiersprache Smalltalk für GUI- Entwicklung in der Software eingeführt. Es handelte sich ursprünglich um ein Konzept für die Trennung der Daten und deren Darstellung. "Dabei ist der Controller für die Verarbeitung der Eingaben (zum Beispiel Mausklicks) zuständig und für deren Kommunikation an das Model." [12, p. 513]. Die Autoren erörtern, dass sich viele Varianten von MVC teilweise aufgrund eines falschen Verständnisses des ursprünglichen MVC-Musters oderauch als Weiterentwicklung oder Anpassung an neueAnwendungsfälle herausgebildet haben.
Das "Model-View-Controller Entwurfsmuster" basiert auf einer klaren Trennung der Daten, der Präsentation und der Programmsteuerung. Dabei wird ein flexibler Programmentwurf ermöglicht, der eine spätere Änderung oder Erweiterung ohne großen Aufwand erlaubt und die Wiederverwendbarkeit der Komponenten, insbesondere von Controller und von Views unabhängiger Modelle ermöglicht.
Dies bietet die Möglichkeit unterschiedliche Benutzeroberflächen zu implementieren. Für EntwicklerInnen mit unterschiedlichen Fähigkeiten und Kenntnissen wird die Möglichkeit angeboten, in einem geeigneten Bereich zu arbeiten. MVC ermöglicht die Testbarkeit der einzelnen Applikationskomponenten.
In folgenden Abbildungen zeigen die unterschiedlichen Linienstärken die Beziehungen zwischen Komponenten, wobei stärkere Linien umfangreiche Interaktionen bedeuten. Die Linienrichtungen zeigen die Beziehungsrichtungen.
Bei einer Webapplikation existieren mindestens zwei separate Systeme. Eines ist das, was die BenutzerInnen verwenden, und das andere ist ein Webserver.
Wie aus den beiden Abbildungen ersichtlich, stellt die grüne Farbe das System der Benutzerinnen dar.
In folgenden Kapiteln werden alle Komponenten ausführlicher beschrieben.
Durch die Abbildungen können komplizierte Sachverhalte einfacher erklärt werden, darum werden zuerst zwei Abbildungen der unterschiedlichen Anwendungsfälle von Implementierungen des MVC-Entwurfsmusters gezeigt, um das Verständnis des MVC- Paradigmas zu erhöhen.
Die Präsentationsschicht wird in der zweiten Abbildung 2.1.5-2 "View" als GUI dargestellt, während sie in der ersten Abbildung 2.1.5-1, wie meistens, als HTML-Seite gezeigt wird. Allerdings ist in beiden Fällen die Datenhaltungsschicht nicht im Modell implementiert, sondern sie wird in einer separaten Schicht realisiert. So ist auch die Diskussion im Kapitel 2.1.5 mit dieser Visualisierung noch einmal begründet.
Der Controller kann unterschiedliche Views rendern. Ein Modell kann vom Controller und von der View verwendet werden. Jedoch sieht ein Modell keine anderen Komponenten und ist unabhängig von allen. Das Modell steht in Beziehung mit einer Datenbank (z.B. MS- Access, MySQL) oder einer Datei (z.B. XML), um die Daten speichern, lesen, aktualisieren oder löschen zu können.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1.5-1: MVC in einem Client-Server-System
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1.5-2: MVC auf einem einzigen System
2.3.1 Model
Das Modell dient als Referenz für die Darstellung und verwaltet die Zustandsänderung des gesamten Konstrukts. Es muss einen Zustand verwalten können, darstellbar sein und auf Aufforderungen zu Änderungen reagieren können. [12, pp. 515-516]
Dieser Bestandteil von MVC ist für CRUD-Operationen von Daten verantwortlich. Diese Operationen können auf einer Datenbank, Dateien oder Webdiensten erfolgen.
Bei den meisten Webapplikationen werden Daten in einer Datenbank gespeichert. Das Modell verwendet in den meisten modernen Frameworks das ORM[4] um die CRUD- Operationen durchzuführen. Dadurch wird die Entwicklung von vielen Klassen für die Datenbankoperationen nicht mehr gebraucht.
Ein Modell ermöglicht die Wiederverwendung und Erweiterung der Klassen. Es ist von der View und vom Controller unabhängig.
2.3.2 View
Die View ist allgemein für die Darstellung der Daten in einem beliebigen Format verantwortlich. Sie stellt die Daten aus dem Modell und die Steuerelemente des Controllers dar.
Einerseits stellt die View die von Controller bereitgestellten Daten aus einem oder mehreren Modellen bereit, andererseits dient sie als eine Schnittstelle zur Funktionalität eines Controllers. Sie bietet per Buttons, Links oder anderen Steuerelementen die Möglichkeit zum Aufruf der Methoden des Controllers, Jede View besitzt eine eigene Steuerung.
Wichtig ist zu verinnerlichen, dass die View keine Steuerungslogik oder Datenverarbeitung beinhaltet.
Der/die Entwicklerin der View benötigt keine Kenntnisse über den inhaltlichen Aufbau eines Controllers oder eines Modells des Systems. Diese Eigenschaft gilt auch vice versa.
2.3.3 Controller
Lahres und Rayman erörtern, dass ein Controller in MVC eine generische Aufgabe hat. [12, p. 515]
Der Controller nimmt die Benutzeranfragen entgegen, verarbeitet sie und bei Bedarf ruft er ein Modell oder mehrere Modelle bzw. Dienste auf und gibt die Ergebnisse an die View für eine Antwort weiter. Der Controller spielt dabei eine verwaltende Rolle. Er wird auch wegen seiner bestimmenden Rolle als Anwendungslogik bezeichnet. Dieser Bestandteil von MVC besitzt die Intelligenz für das Verarbeiten der Benutzerinteraktionen.
Der Controller selbst implementiert die Methoden für die Datenverwaltung nicht, er ruft dafür die Methoden der Modelle auf. Dieser ist für die Steuerung des Programms zuständig. Er instanziiert das Modell, ruft die benötigte Methode aus dem Modell auf, transferiert die erhaltenen Daten an die View und rendert die View.
Wichtig ist beim Controller zu wissen, dass er keinen Code für die Darstellung oder Verwaltung der Daten besitzen soll.
Seine einzige und wichtige Aufgabe ist die Behandlung der Ereignisse aus der View und die Steuerung des Datenflusses zwischen dem Modell und der View.
2.3.4 Beziehungen zwischen Model, View und Controller
1. Zwischen einem Modell und einer View besteht eine 1-N-Beziehung. Nämlich ein Modell kann von mehreren Views dargestellt werden und eine View kann nur genau ein Modell darstellen.
2. Zwischen einem Modell und einem Controller besteht eine N-M-Beziehung. Ein Controller kann mehrere Modelle verwenden und ein Modell kann von mehreren Controllern verwendet werden.
3. Zwischen einer View und einem Controller besteht eine 1-1-Beziehung. Denn ein Controller kann während der Laufzeit nur eine View verwenden und eine View kann von genau einem Controller verwendet werden.
2.3.5 Vor- und Nachteile
MVC-Entwurfsmuster ermöglicht einen flexiblen Programmentwurf, sodass die Wiederverwendbarkeit, Erweiterbarkeit und Änderbarkeit einer Software mit geringem Aufwand gewährleistet.
Folgende Vorteile sind nennenswert:
1. Trennung der Anwendungslogik von den Darstellungen, Benutzerinteraktionen
2. Testgetriebene Entwicklung
3. Erweiterbarkeit der bestehenden Systeme
4. Unterstützung der Entwicklerkenntnisse und Fähigkeiten
5. Wiederverwendung der meisten Komponenten insbesondere Modelle für weitere Anwendungen
Folgende Nachteile sind zu berücksichtigen:
1. Mehr Aufwand für kleine Anwendungen
2. Mehr Codes wegen der Kommunikation und Synchronisation der Komponenten
2.4 MVC-Frameworks
ln diesem Kapitel setzt sich der Autor im Schnelldurchlauf mit der Besonderheit von MVC- Frameworks in Java und ASP.NET auseinander. Dabei werden die Abläufe der Frameworks näher betrachtet und die wichtigsten Komponenten kurz beschrieben. Selbstverständlich werden in dieser Arbeit nicht alle auf dem Markt vorhandene Frameworks vorgestellt, sondern es werden nur die PHP-Frameworks detaillierter beschrieben, denn der Autor bevorzugt letzteres wegen ihrer guten Lizenzbedingungen, günstigen Kosten und besseren Entwicklungskenntnissen der Sprache PHP.
2.4.1 MVC-Frameworks in JAVA
SUN Model 1: Variante des MVC-Musters von Sun implementiert die MVC, wie in folgender Abbildung 2.4.1-1 gezeigt.
Aus dem Browser kommende Anfragen werden in einer JSP-Seite bearbeitet und direkt daraus wird auf die Modelle zugegriffen. Dabei existiert kein Controller aber die JSP-Seite übernimmt die Rolle des Controllers.
Die Modelle sind als Java-Beans repräsentiert.
SUN Model 1 ist, wie aus der Abbildung 2.4.1-1 hervorgeht, einfach und überschaubar, jedoch sollte es nicht für große Anwendungen verwendet werden.
SUN Model 2 fügt, siehe Abbildung 2.4.1-2, eine weitere Komponente, nämlich den Controller-Servlet hinzu, das die aufgeforderte JSP-Seite festlegt.
"Jakarta Struts Framework" implementiert diesen Ansatz[12].
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4.1-1: SUN Model 1, Quelle. Abbildung 2.4.1-2 SUN Model 2, Quelle:[16] [16]
Spring 3 Framework[17] implementiert MVC wie in der folgenden Abbildung 2.4.1-3.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4.1-3: MVC bei Spring 3 Framework, Quelle: [17, p. 176]
Der Ablauf von Spring 3 ist folgender [17, pp. 176-177]:
1. Der Client schickt eine Anfrage an DispatcherServlet.
2. DispatcherServlet bekommt die Anfrage und versucht per HandelerMapping- Komponente passende Controller zu finden.
3. DispatcherServlets bestimmt passenden Controller.
4. Der Controller verpackt ein ModelAndView Objekt und retourniert es zum DispatcherServlet.
5. DispatcherServlet fragt den ViewResolver nach der eigentlichen JSP-Seite.
6. Ein Modell aus dem ModelAndView Objekt wird für die Generierung der Daten verwendet, anschließend wird die View gerendert.
7. Erstellte View wird an den Client als Antwort gesendet.
Controller in Spring MVC sind Klassen, die die Schnittstelle zur Funktionalität der Anwendung repräsentieren. Sie nutzen alle Vorteile von Dependency Injection und der Spring AOP. [17, p. 446]
In ModelAndView Objekt ist die Model-Map und der Name der View enthalten. Das ModelAndView Objekt kapselt die View und die Modeldaten, die von der View gezeigt werden.
ModelAndView Konstruktor besitzt drei Parameter: den Namen der View, das Modelobjekt, und deren Ausprägung. Das Modell basiert auf der Map-Schnittstelle.
Der Name der View kann mithilfe verschiedener Methoden, per einer Eigenschaftendatei, eigener Implementierung von ViewResolver oder Bean-Name festgestellt werden. Das Modell wird in ein passendes Format umgewandelt und die View wird generiert.
"Das Spring-Framework besitzt ein leistungsfähiges und flexibles Web-Framework, das wiederum auf den Spring-Grundsätzen der lockeren Kopplung, Dependency Injection und Erweiterbarkeit beruht." [17, p. 446]
2.4.2 ASP.NET MVC Framework
Eine klassische ASP.Net-Anwendung arbeitet mit verschiedenen ASPX-Seiten, den sogenannten "Webformularen". Wegen der fehlenden Trennung der verschiedenen Funktionalitäten und mit der Implementierung des MVC Frameworks hat Microsoft ASP.NET MVC präsentiert. [18, p. 362]
Franz und Lorenz stellen die MVC und Web Forms Ansätze gegenüber und argumentieren, dass das MVC Framework einige Vorteile bietet. Allerdings wäre diese nicht in jedem Fall eine bessere Lösung als eine klassische ASP.NET-Anwendung. [18, p. 362]
Die Autoren beschreiben den Nutzen des MVC mit diesen Sätzen: „Eine saubere Trennung innerhalb der Anwendung ist gegeben. Dadurch, dass die Verträge innerhalb des Frameworks auf Schnittstellen basieren, ist es leicht, Attrappen zu erstellen, mit denen dann Tests durchgeführt werden können“. Sie geben weiter an, dass MVC stark erweiterbar ist, dass per URL-Mapping das Erstellen von Anwendungen mit sprechenden und nicht überlangen URLs möglich ist und wichtige ASP.NET Features weiter unterstützt werden. [18, pp. 363-366]
Die anschließende Abbildung 2.4.2-1 zeigt die ASP.NET MVC Implementierung.
1. Der/die Benutzerin schickt eine Anfrage.
2. Die Anfragen werden zunächst mithilfe vorher erstellter Routen untersucht.
3. Der Controller wird bestimmt. Sobald ein Controller gefunden wurde, wird die gewünschte Aktion-Methode gesucht und eventuell vorhandene Parameter übergeben.
4. Die Aktion-Methode erhält eventuell Daten aus dem Modell und übergibt sie an die View.
5. Die View rendert das Modell und formatiert die Daten.
6. Die View sendet die gewünschte Antwort an den Client zurück.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4.2-1: MVC-Schema des ASP.NET Frameworks, Quelle: [19]
ASP.NET MVC hat ein paar Nachteile gegenüber JAVA- oder PHP-Frameworks.
1. Zwangsweise Verwendung des Microsoft Betriebssystems
2. Hohe Kosten wegen Beschaffung der Microsoft-Produkte, Lizenzgebühren usw.
Zhu beschreibt umfassend, wie eine Applikation auf Basis des ASP.NET MVC Frameworks entwickelt werden kann. Damit in dieser Arbeit keine Wiederholung stattfindet und nicht unnötige Details erklärt werden, verweist der Autor dieser Arbeit den Leser oder die Leserin auf die originale Artikelserie: "Build a Front End of an E-commerce System Using ASP.NET MVC Framework".[19]
2.4.3 Eine Übersicht der PHP MVC-Frameworks
Die wichtigsten Begriffe bezüglich der PHP MVC-Frameworks werden als Nächstes kurz zusammengefasst, genauso, was bei PHP-Frameworks beachtet werden soll.
PHP-Version
Bei allen Frameworks sollte die Version von PHP beachtet werden. Ob die richtige Version für das Framework vorliegt, sollte als erstes kontrolliert werden.
Das Zend Framework 2 oder Phalcon Framework benötigt mindestens die PHP-Version 5.3, wobei Yii 1 mit PHP 5.1 ebenfalls funktioniert und CakePHP 1.3 mit PHP 4.3 betrieben werden kann.
PHP Namespaces und Traits
Die modernen Frameworks verwenden auch aktuelle Eigenschaften von PHP. In PHP 5.2 und allen vorherigen Versionen wurden keine Namespaces unterstützt. Viele Frameworks haben deswegen künstliche Namensräume verwendet, damit es in den Klassen nicht zu Namenskollisionen mit anderen Klassen aus anderen Verzeichnissen bzw. Bibliotheken kommt. Seit PHP 5.4.0 gibt es in PHP eine Möglichkeit der Wiederverwendung von Code, die "Traits" genannt wird. Das heißt, ein Trait kann für die Überwindung der Beschränkungen der einfachen Vererbung der Sprache PHP verwendet werden, das als eine Vielzahl von Methoden der Klassen implementiert wird.
Fullstack Frameworks und Glue Frameworks
Die PHP-Frameworks unterscheiden sich grundsätzlich architektonisch aufgrund des Zusammenspiels der Komponenten und Klassen, und ob sie fest miteinander verbunden oder entkoppelt sind. "Zend Framework" und "Phalcon" sind Beispiele für "Glue Frameworks", die auch als "Fullstack Framework" verwendet werden können. Jedoch sind die meisten PHP-Frameworks beispielsweise wie "Yii", "CakePHP", "Codelgniter", "Kohana" "Fullstack Frameworks".
Die Komponenten von "Fullstack Frameworks" können nicht ohne Änderungen für andere Anwendungen verwendet werden. Im Gegensatz zu "Fullstack Frameworks" erlauben es "Glue Frameworks", wie Symfony, ihre Komponenten auch in fremden Frameworks oder Anwendungen zu verwenden.
Dependency Injection, Service Container, Service Locator und Registry Entwurfsmuster
Die Frameworks verwenden unterschiedliche Ansätze um die Instanziierung ihrer Komponenten und die Kommunikation dazwischen zu ermöglichen.
"Dependency Injection" bezeichnet ein Konzept für objektorientierte Programmierung, das die Initialisierung von benötigten Objekten während der Laufzeit reglementiert. In einem klassischen Vorgehen der objektorientierten Programmierung ist jede Klasse selbst für ihre benötigten Objekte und Ressourcen zuständig. "DI" übernimmt diese Aufgabe, anstatt die Initialisierung von benötigten Objekten unmittelbar in einem Objekt hardzukodieren, indem sie diese Aufgabe im Nachhinein während der Laufzeit entweder per Schnittstelle (Interface Injection), die von abhängigen Klassen implementiert wird, erledigt. Dies kann auch über Parameter des Konstruktors (Constructor Injection) von der abhängigen Klasse realisiert werden oder das benötigte Objekt wird via Methode (Setter Injection) der abhängigen Klasse gesetzt.
Mit diesem Konzept wird einerseits die Entkopplung der Komponenten ermöglicht, andererseits die Erstellung von Unit-Tests erleichtert.
Für weitere Details wird eine entsprechende Literatur für das Verständnis des Konzepts empfohlen. Beispielsweise der Artikel von Tom Butler[5] "PHP Dependency Injection Container Performance Benchmarks".
Ein "Service Container" ist ein Objekt, das die Dienste einer Applikation verwaltet und bereitstellt. Jedes Mal, wenn das Framework eine Komponente braucht, fragt sie nach dem Namen des Dienstes aus dem Service Container und dieser stellt das Objekt für die Verwendung bereit.
Aufgrund der Tatsache, dass "Phalcon Framework" und "Zend Framework 2" keine "Fullstack Frameworks" sind, spielt ein Service Container eine zusammenfügende Rolle der Komponenten, die zusammenhängen oder zueinander abhängig sind.
Der Begriff des Service Locators definiert ein Entwurfsmuster, das die zentrale Registrierung von Objekten zur späteren Nutzung ermöglicht. Der Unterschied zu RegistryEntwurfsmuster liegt daran, dass dabei auch eine Instanziierung der Objekte stattfindet.
Event-Driven Architektur
Die Ereignisgesteuerte Architektur ermöglicht die Interaktion und Kommunikation unterschiedlicher Komponenten mithilfe von Ereignissen. Insbesondere "Glue Frameworks", wie zum Beispiel "Zend Framework 2", implementieren dieses Entwurfsmuster um lose gekoppelte Komponenten durch Ereignisse während der Laufzeit miteinanderzu verbinden.
"Zend Framework 2" verwendet dieses Architekturmuster um die Synchronisation der Informationen zwischen seiner Komponenten zu ermöglichen. "Phalcon" benutzt diese Architektur um so genannte "hooks"[6] für die Steuerung des Verarbeitungsprozesses zu ermöglichen.
Rapid Development und Scaffolding
Manche Frameworks wie "CakePHP" oder "Phalcon" bieten Möglichkeiten des sofortigen Einsatzes einer prototypischen Applikation. "Rapid Development" basiert auf der Idee, dass bei der Entwicklung einer Software möglichst schnell ein Prototyp zu erstellen ist, die die wesentlichen Funktionalitäten des Systems repräsentiert. Scaffolding ist eine Eigenschaft des Frameworks, die es ermöglicht, ohne eine einzige Zeile Code zu schreiben, eine funktionierende Applikation auf Basis einer Datenbank, die als Basis für den Prototyp verwendet wird, zu erzeugen. [20, p. 4]
ORM
Fast alle Frameworks bieten heute "ORM Komponenten", um die Verwaltung der Daten einfacher und sicherer durchzuführen. Die objektrelationale Abbildung ist eine Technik der Softwareentwicklung, indem eine Zeile in der Tabelle auf einer Datenbank als ein Objekt abgebildet wird. Die Spalten der Tabelle können wie Eigenschaften eines Objektes verwendet werden.
CRUD
CRUD steht für "Create, Read, Update und Delete", und fast jede auf einer Datenbank basierte Anwendung verwendet mindestens einer dieser Funktionen. MVC Frameworks führen diese Operationen in Modellen aus.
CRUD Operationen werden im Zusammenhang mit den persistenten Daten in dynamischen Anwendungen sehr oft ausgeführt. [20, p. 5]
DRY
"Don't Repeat Yourself" ist einer der wichtigsten Grundsätze der Softwareentwicklung. Ein gutes Framework sollte auf keinen Fall eine Wiederholung des Codes verursachen. Wenn es in einem Softwareentwicklungsprozess keine Wiederholung gibt, wird der Entwicklungsprozess als DRY bezeichnet.
Bei der Entwicklung soll ein redundant geschriebener Code vermieden werden. Die EntwicklerInnen sollen ihre Applikationen möglichst ohne Wiederholung der Quelltexte entwickeln. [20, p. 3]
Konvention über Konfiguration
Im Wesentlichen definiert dieser Ansatz, dass die EntwicklerInnen möglichst wenige Konfigurationen einstellen müssen, um mit der eigentlichen Arbeit beginnen zu können.
[...]
[1] Representational State Transfer bezeichnet ein Programmierparadigma für verteilte Systeme. Der Zweck von REST liegt auf der Maschine-Maschine-Kommunikation.
[2] Das ISO/OSI-7-Schichtenmodell ist ein Referenzmodell für herstellerunabhängige Kommunikationssysteme bzw. eine Design-Grundlage für Kommunikationsprotokolle und Computernetze. http://www.elektronik- kompendium.de/sites/kom/0301201.htm
[3] Design Patterns - Elements of Reusable Software (Addison-Wesley, 1995)
[4] Object-relational Mapping ist eine Technik der Entwicklung objektorientierter Software, dabei bilden Objekte die Tabellen einer relationalen Datenbank ab.
[5] Tom Butler ist ein Webentwickler und Ph.D Student aus Großbritannien. Er interessiert sich für Software Best Practices und unterrichtet als Lektor. http://www.sitepoint.com/author/tbutler
[6] Hooks sind ähnlich wie Eventshandlerfür die Behandlung eines Events während Laufzeit zuständig.
- Quote paper
- Bakk.rer.soc.oec. Mehmet Coban (Author), 2015, Analyse des Model-View-Controller Paradigmas und Implementierung eines RFID-gestützten Informationssystems für die Tourismusbranche, Munich, GRIN Verlag, https://www.grin.com/document/301694
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.