In einem Projekt werden die einzelnen Themengebiete in sinnvolle Teilaspekte (Teilprojekte) gegliedert. Nehmen wir ein fiktives Projekt an, bei dem folgende Themengebiete erkannt und als Teilprojekte bearbeitet werden sollen:

• Infrastruktur Setup
• Operational Management Setup
• Applikationsentwicklung

Einsatz eines traditionellen Projektvorgehens

Für das Infrastruktur Setup und das Operational Management Setup kann es durchaus Sinn ergeben ein traditionelles Projektvorgehen einzusetzen. So kann es vorkommen, dass ein normales Wasserfallvorgehen für die Erarbeitung der Lieferobjekte in diesem Bereich eingesetzt wird.

• Projektphasen mit Meilensteinen im Wasserfallmodell

In unserem Beispiel erhalten wir so einen Projektverlauf mit sechs Meilensteinen (M1-M6) an denen jeweils das Ende einer Projektphase markiert ist. Die Lieferergebnisse, die pro Meilenstein erreicht werden müssen, sind sauber beschrieben und können im Gesamtprojekt entsprechend überwacht werden.

Scrum für die Applikationsentwicklung

Bei der Applikationsentwicklung sind zu Projektbeginn noch nicht alle Anforderungen von allen Beteiligten richtig und vollständig beschrieben, bekannt und verstanden. Es ist mit vielen Änderungen zu rechnen. Den kompletten Projektscope zu beschreiben würde eine sehr teure Vor-, Grob- und Detailstudie erfordern.

Und selbst nach einer solchen Studie sind wir noch nicht sicher, dass alle Anforderungen bekannt sind. Während der Projektlaufzeit ändern sich die äußeren Bedingungen, neue Anforderungen kommen hinzu und bestehende Anforderungen werden nicht mehr benötigt. Es wäre somit vernünftig, eine agile Vorgehensweise für dieses Teilprojekt einzusetzen. Das entsprechende Projektvorgehen ist in folgender Skizze erläutert.

• Projektvorgehen nur mit SCRUM

Was beim Wasserfallvorgehen als Vorstudie bezeichnet wurde, kann bei SCRUM als Vision verstanden werden. Es wird grob beschrieben, was mit dem System erreicht werden soll. Danach werden mehrere Sprints durchgeführt, die immer dem gleichen Muster folgen.

• Sprint Planungsmeeting 1 und 2 um den Umfang und die Qualität der Lieferergebnisse festzulegen
• Development mit Daily-Scrum-Meetings um jeden Tag schnell auf auftretende Schwierigkeiten reagieren zu können
• Sprint Release stellt einen neuen Applikationsrelease zur Verfügung der vom Kunden bereits verwendet werden kann. Falls, wie in unserem Beispiel, die Infrastruktur noch nicht bereit steht, kann dieser Release für die Integrationstests verwendet werden.
• Sprint Retrospektive liefert das Feedback um festlegen zu können, was in diesem Sprint gut lief und was verbessert werden soll.

Dieser Zyklus wiederholt sich bis alle vom Kunden tatsächich benötigten Elemente umgesetzt worden sind. Nach jedem Sprint kann der Kunde mit dem lauffähigen Release sehen ob er die Software erhält, die er wirklich benötigt und kann sein Feedback liefern um Änderungen am System zu erreichen.

Scrum in das Gesamtprojekt einbinden

Die hier gezeigte Vorgehensweise lässt sich sehr elegant in das Gesamtprojekt einbinden.

• Es muss dafür gesorgt werden, dass die einzelnen Sprintzyklen mit den Meilensteinen des Wasserfallvorgehens übereinstimmen.
• Weiterhin muss erreicht werden, dass die Lieferobjekte des Wasserfallmodells mit den einzelnen Releases der Sprints in Einklang gebracht werden können.

Das klingt komplizierter als es ist. In den ersten Releases einer Applikationsentwicklung wird die Architektur erstellt, die Umsetzungsrichtlinien festgelegt und die einzusetzenden Tools und Libraries definiert. Weiterhin kann in den ersten Releases schon gut erkannt werden, wie das Zielsystem aussehen wird. Diese Erkenntnisse können als Vor- und Grobstudie angesehen werden.

Nach weiteren Sprints ist sichergestellt, dass die Detaildokumentation erarbeitet wurde. Bei Scrum besteht die Devise, dass der Code die Dokumentation ist. Aus dem Code kann mit Reverse-Engineering und der Beschreibung der wichtigsten Architekturkonzepte durchaus eine sinnvolle Dokumentation erstellt werden.
Für die Planung im Projekt ergibt sich somit folgende Vorgehensweise:

• Gesamtprozess der Projektvorgehensweise

Die Sprints werden auf die einzelnen Projektphasen aufgeteilt.
Nach der Vorstudie steht schon ein erster Prototyp zur Verfügung, mit dessen Hilfe die Grobstudie zusammen mit dem Kunden erarbeitet werden kann. Jederzeit kann auf Änderungen und Schwierigkeiten Einfluss genommen werden.

Falls ein Standard-Sprintzyklus sich nicht mit den Meilensteinen vereinbaren lässt, kann man entweder längere Sprints durchführen, oder die Sprints verkürzen (Siehe die „S“ Sprints). Unsere Sprints lassen sich vom Schwerpunkt her den einzelnen Projektphasen zuordnen.

• So kann dafür Sorge getragen werden, dass nach der Vorstudie eine Vision und ein erster architektonischer Prototyp steht.
• Nach der Grobstudie sind erste Businessprozesse umgesetzt und können während der Detailstudie verfeinert werden.
• Bei der Implementation kann die Integration der Applikation in die Infrastrukturkomponenten und operationellen Prozesse angegangen werden.
• Bei den abschließenden Tests sind die Applikationskomponenten bereits getestet und es geht vor allem um die Integration in die Systemumgebung.
• Die Transition kann dazu verwendet werden, abschließende Änderungen einzupflegen oder die Übergabe an den Betrieb zu managen.

Die Schwerpunkte der einzelnen Sprints sind in der folgenden Grafik angedeutet.

• Scrumprozess in den Farben des Wasserfallvorgehens

Durch die Übernahme der Farben aus dem Wasserfallvorgehen werden die Schwerpunkte des Gesamtprojekts auf das Teilprojekt übertragen. Die Entwickler können sich in den Projektphasen wiederfinden.

Fazit

Mit dieser Vorgehensweise ändert sich für die beiden Welten (Scrum und Wasserfall) sehr wenig. Die einzelnen Projektbereiche können miteinander kommunizieren und wir erhalten uns die einfache Rapportierbarkeit des Wasserfallmodells und die Agilität von Scrum.

Ähnliche Beiträge

Mach dir zuerst über die Security Gedanken

Als ich so meine Architekturtapete pinselte, dachte ich logischerweise auch über die Zugriffsrechte der Anwender nach.
Es gibt, wie immer, verschiedene Vorgehensweisen und Möglichkeiten wie man seine Sicherheitsregeln in das System einbaut.
Hier sind ein paar Gedanken dazu.

Authorisierung in den Modellen

Man kann z.B. die Zugriffsrechte fest in den Modellen einschreiben.
Das bedeutet, das jeweilige Modell kontrolliert, ob der Anwender überhaupt diese Aktion durchführen darf.
Dazu können hart kodierte Regeln verwendet werden. Das bedeutet der Redakteur darf nur seine eigenen Artikel verändern, also prüfen wir ob der aktuell angemeldete Redakteur im Artikel eingetragen ist.

Vorteile

• Wir können die Regeln einmal festlegen und eintragen
• Die Sicherheit wird auf Modellebene gesteuert
  Ein versehentliches falsches Einfügen und Verändern sollte verhindert werden können.

Nachteile

• Die Regeln stehen hart kodiert im Modell drin
  Änderungen an den Sicherheitsregeln müssen in den Modellen vorgenommen werden. Das nachträgliche Anpassen für einen Kunden ist nicht möglich. Wenn aber ein Kunde will, dass der Systemadministrator auch Artikel bearbeiten kann, dann geht das nicht. Wenn das jedoch ein Kundenwunsch ist, finde ich es nicht richtig unser System schon von Anfang an so einzuschränken.
• Wenn ein zentrales Security System verwendet werden soll, dann können die Zugriffsregeln nicht von dort aus gesteuert werden. Das System ist in sich geschlossen und nicht erweiterbar.
• Duplizierung von Code und Verantwortlichkeiten auf verschiedenen Layern
  Falls die Regeln auch Auswirkungen auf die Views haben, wie Beispielsweise die Anzeige von Löschbuttons nur wenn du auch die notwendigen Rechte hast, dann muss man diese Regeln auch noch in der View implementieren.
• Seperation of Concern verletzt
  Das gefällt mir als Architekt natürlich gar nicht. Wieso soll sich eine View oder ein Modell um die Berechtigungen des Users im Detail kümmern? Das macht die Komponenten dick und fett und das kann kein guter Ansatz sein.

Oha! Das war noch nichts.
Gut, ich behaupte mal die meisten Systeme sind genau so, oder so ähnlich aufgebaut. Aber wenn es falsch ist, dann ist es auch falsch wenn es meistens so gemacht wird.
Also gut, ein weiterer Versuch:

Security Rules nur in den Controllern

Der Controller ist ja dafür da, die Abläufe im System zu steuern.
Da wäre es doch nur rechtens, wenn er sich auch um die Security kümmert.
Wenn unser lieber User jetzt eine Aktion ausführen will, die er nicht ausführen darf, dann hindert ihn der Controller daran.

Vorteile

• Die Zugriffsdefinition wird an einer Stelle gehalten
  Juchu! Klingt doch schon eher nach Seperation of Concerns gelle?. Wenn wir was ändern wollen, dann ändern wir den jeweiligen Controller. View und Modell kümmern sich um die Ansicht und die Speicherung.
• Flexibilität der Rechtevergabe deutlich erhöht
  Da wir nun eine zentrale Komponente haben, in der wir die Rechtevergabe steuern, sollte es deutlich leichter sein diese zu verändern.

Nachteile

• Auf Modellebene wird keine Zugriffssteuerung implementiert.
  Das ist ein ziemlich dicker Nachteil. Das Modell muß permanent und immer sich um die Richtigkeit der Daten kümmern. Wenn wir dem Modell jetzt diese Verantwortung entziehen, dann muss der Controller immer sauber programmiert sein. Damit entsteht eine Sicherheitslücke. Denn wer weiß? Vielleicht umgeht ein versierter Hacker unseren Controller?
• Zentrale Rechteverwaltung nicht möglich
  Da wir wieder unsere Rechteverwaltung im System behalten, können wir eine Verwaltung nicht in einer externen Komponente auslagern. Unser System bleibt dick und wenn wir es irgendwo integrieren wollen, bleibt dem Administrator nichts anderes übrig als verschiedene Administartionstools zu verwenden.

Hm… Schon mal nicht schlecht, bis auf die Nachteile.
Mir gefällt diese Implementation jedoch schon viel besser als die Erste Variante.
Vielleicht gibts da noch was anderes?

Rechteverwaltung in eigene Komponenten auslagern und über Interface ansteuern

Das klingt schön kompliziert und gefällt deshalb dem Architekt
Quatsch, das ist gar nicht kompliziert, hilft uns jedoch die Komplexität zu senken und später ein anderes Rechtesystem mitzuverwenden.
Wir erstellen, z.B. mit einem Singleton oder Factory Pattern, ein eigenständiges Sicherheitsregelwerk. Dieses Regelwerk wird für die Standalone Lösung des Newssystems verwendet.
Die Authorisierung wird über ein Interface angesprochen.
Dieses Interface bietet mindestens eine Funktion.
Und die nennen wir z.B. isActionAllowed(actionID, component).
Wir übergeben dieser Methode die Aktion die zur Zeit aufgerufen wurde und die Komponente auf die diese Aktion angewendet wird.
Die Methode liefert true zurück, wenn der Anwender diese Aktion durchführen darf. Und, rate mal, false falls er es nicht darf.
Unglaublich digital!
Jetzt können wir in jedem Modell und in jedem Controller oder View nach belieben Regeln festlegen und im zentralen Authorisierungssystem implementieren.

Vorteile

• Zentrale Verwaltung aller Rechte möglich
  Vorbei sind die Probleme, dass wir Rechte nicht zentral verwalten können. Je nach Strategie können wir eine Whitelist oder eine Blacklist implementieren. Will heißen, dass wir z.B. nur true zurückliefern, wenn die Komponente und Aktion bekannt und erlaubt ist. Oder wir liefern true zurück wenn wir keinen Plan haben was da aufgerufen wurde. Dann überprüfen wir nur, was wir auch schon kennen.
• Auf Modellebene kann Rechteverwaltung realisiert werden.
  Wenn wir mindestens alle Modelle in der Rechteverwaltung aufnehmen, ist eine Rechtesteuerung auf Modellebne möglich.
• Größte Flexibilität bei der Rechtevergabe
  Klar, wir können hier die wildesten Rechtesteuerungen erfinden. Aber Vorsicht! Es ist nicht cool man wenn man damit jedem Anwender alle Rechte gibt.
• Einfaches Testen
  Da die Security in einem eigenen System zusammengefasst ist, können wir für jede Aktion von CRUD und jeder Komponente einen true und false Testfall generieren. Wir können dann sehr sicher sein, dass z.B. die Modelle nur speichern wenn sie auch wirklich speichern dürfen.

Nachteile

Was? So eine coole Lösung und Nachteile?
Leider ja…

• Modelle haben keine direkte Kontrolle über Authorisierung
  Dieser Nachteil ist der gleiche wie wenn wir die Rechtevergabe dem Controller übergeben. Der Entwickler und Administrator unserer Rechtesystems muss wissen was er tut. Das Modell unterstützt ihn hierbei nicht.
• Externe Rechtevergabe kann Sicherheitslücken verursachen
  Klar, wenn wir unsere Security “outsourcen” dann verlieren wir innerhalb des Systems die Kontrolle darüber. Aber mal ehrlich: Wir bauen hier ein Newssystem, im schlimmsten Fall wird mal eine schlechte Nachricht geschrieben oder gelöscht…

Wozu hat sich jetzt der (graue) Star Architekt entschlossen?

Ratet mal!
Ich bin ein faules Tier und möchte die Flexibilität so hoch wie möglich halten.
Also werde ich in die Architektur die dritte Variante einbauen.
Wie bitte? Faul und dann so ein System?
Genau deshalb. Wenn wir nur eine Komponente verwalten müssen, mit der wir die Authorisierung durchführen, sparen wir uns über die Zeit eine menge Arbeit.
Wenn die einzelnen Methoden einfacher aufgebaut sind, können wir sie schneller uns sicherer testen.
Dann kann ich ruhig schlafen und habe das gute Gefühl keine vollständige Standalone Lösung entwickelt zu haben.

Hätten wir diese Lösung auch noch später einbauen können?

Ja, das hätten wir gekonnt. Doch wir wären permanent über den User und seine Berechtigungen gestolpert. Im schlimmsten Fall hätten wir die einzelnen Berechtigungen schon irgendwie in den Controller, oder noch schlimmer, nur in die Views eingebaut.
In den Views wäre besonders schlimm, da das erste was ein böser Bube umgehen kann die View ist. Ein Roboter braucht keine View…

Ähnliche Beiträge

Wenn also die Views kein Problem darstellen, wieso dann nicht einfach den Adminbereich entsprechend anpassen und gut ist?

Das ist eine berechtigte Frage.
Wie immer gibt es pro- und cons dafür.
Wenn ich an meine letzten Kunden denke, dann möchten die so schnell wie möglich so wenig wie möglich eingeben.
Das bedeutet, dass sie keine großen Administrationsoberflächen diesen Menschen unterjubeln kann.
Wenn die plötzlich sich in der Mächtigkeit von WordPress wiederfinden sollen, dann sagen sie zu mir: “Vielen Dank Roland! Kannst du bitte dort zur Türe hinausgehen und diese von außen schließen? Wir wollen mit dir nichts mehr zu tun haben!”
Und das mag ich nicht. Vor allem wenn es draußen regnet und kalt ist…
Geschmäcker sind verschieden. Und wenn diese Menschen eine einfache Oberfläche haben wollen, dann sollen sie diese bekommen.
Wenn sie z.B. zuerst den Text und dann den Titel schreiben wollen, also mein geliebtes Beispiel dass ich immer wieder bringe, dann sollen sie auch das tun können.
Ich möchte die Software so generisch halten, dass ich in der Lage bin die verschiedenen Welten miteinander zu verbinden.
Falls ich dann doch noch auf die Idee komme dieses Newssystem als Plugin zu realisieren ist dass auch ok.
Aber im Moment möchte ich noch ein wenig herumphillosophieren und mir alle Möglichkeiten anschauen.

Ähnliche Beiträge

HTML

In einer Datei findet sich HTML Tags. Diese beinhalten die Dokumentenstruktur die auf den Webclient dargestellt werden soll.

CSS

Das Cascating Stylesheet wird nicht in einer eigenen Datei ausgelagert sondern per inline Definition in das HTML Dokument mit eingebunden.

JavaScript

Die Funktionen werden nicht in eine Datei ausgelagert sondern gerade auch noch reingefummelt. Damit hat man schon ziemlich viel verschiedenes Sprachgewirr beisammen. Aber damit sind nur die auf dem Webclient zu interpretierenden Sprachelemente hinterlegt. Jetzt kommen noch die Serverbasierten Sprachelemente hinzu.

PHP

Viele bauen ihre PHP Dokumente und fummeln da gleich alles was es auf dem Client zu tun gibt mit rein. Das Dokument ist wirklich weltklasse zu lesen! Das ist so ähnlich, wie wenn du in einem Dokument Englisch, Deutsch, Spanisch und Russisch miteinander kreuzt. Aber damit nicht genug. Es geht noch besser…

SQL

Ja, auch noch komplexe Datenbankabfragen müssen unbedingt mit in das Dokument rein. Und dann haben wir viel beieinander und fühlen uns irgendwie wie beim Turmbau zu Babel…

Warum ist dass nicht gut?

Wenn man mal anschaut wo welche Programmiersprachen ausgeführt und interpretiert werden, ist es sinnvoll auch die Dateien entsprechend anzuordnen. Wieso soll sich ein Server mit JavaScript rumschlagen? Warum soll die Darstellung auf dem Server interpretiert werden?
Eben, dass soll nicht auf dem Webserver passieren.
Eine gute Architektur sorgt dafür, dass alle verschiedenen Sprachelemente und Komponenten dort installiert und ausgeführt werden wo sie wirklich gebraucht werden. Weiterhin kann man sehr gut die einzelnen Sprachen in verschiedene Dateien auslagern und somit eine gut zu testende Applikation erstellen.
Denk immer dran. Deine Applikation wird einen Fehler haben und du musst diesen Fehler in einem halben Jahr finden. Dann bist du froh, wenn du deine Programmteile sinnvoll geordnet hast.

Was bedeutet jetzt Seperations of Concern?

Wir werden die Webapplikationen immer so gestalten, dass die Aktivitäten an den Orten ausgeführt werden, wo sie wirklich notwendig sind.
Folgende Aktivitäten werden normalerweise benötigt:

Präsentation

Auf dem Webbrowser muss von unserer Webapplikation die Ein- und Ausgabeelemente dargestellt werden. Ein Anwender möchte ein Textfeld vorfinden um seinen Namen einzutragen. Also wird HTML und CSS auf dem Webbrowser dargestellt und hierfür auch bereit gestellt.

Präsentations Controller

Der Präsentations Controller einer Webapplikation steuert die Programmabläufe bei der Eingabe. Er kümmert sich um einfache Typüberprüfungen, also ob ein String auch wirklich Text beinhaltet und ob eine Zahl als Zahl und nicht als String eingegeben wurde. Weiterhin können einfache Algorithmen, wie Beispielsweise die Suche nach einer Auswahl von Städten, in diesem Controller abgehandelt werden. Dieser Controller sorgt dafür, dass die Webapplikation für den Anwender schnell und einfach zu bedienen ist. Somit wird der Code sehr nah beim Anwender benötigt und wir liefern diesen Code an den Webclient aus. Der Webclient interpretiert diesen Code.

Business Logic Controller

Hierbei handelt es sich um die Abläufe die benötigt werden um die Daten aus dem Web zu speichern und zu verändern. Bei einer Autovermietung wird die Businesslogik benötigt um die einzelnen Autos an die Kunden übergeben zu können. Diese Logik ist dort wo die Daten sind, also auf dem Webserver.

Modelle

Die Daten werden in Datenbanken oder in anderen Datenstrukturen auf dem Server abgespeichert. Modelle verwalten einzelne Datensätze und helfen die Daten konsistent halten. Die Logik für die Modelle wird auf dem Webserver, die Daten selbst jedoch meistens im Datenbankserver gehalten.

Persistence Model

Auf dem Datenbankserver werden die Modelle persistent gespeichert. Um diese Speicherung beschreiben zu können, werden die Persistenzmodelle von den logischen Modellen getrennt. So können Modelle für Datenbanken oder für Fileserver erstellt werden.

SQL und SQL Prepared Statemenents

Die SQL Sprachelemente werden normalerweise auf dem Webserver installiert. Es gibt jedoch auch optimierte SQL Statements die direkt auf dem SQL Server installiert werden. Diese werden vorübersetzt und können schneller ausgeführt werden.

In der folgenden Grafik habe ich die auf der linken Seite die Sprachen und auf der rechten Seite Architekturelemente abgebildet. Dieses Deployment Diagramm soll zeigen auf welcher Komponente die jeweiligen Elemente ausgeführt werden.

Ähnliche Beiträge

Ähnliche Beiträge