Softwarearchitektur vs. PHP

SOFTWARE ARCHITEKTURVS

PHPWorkshop IPC Frühjahr 2010

in Berlin (in Berlin!)

Sonntag, 30. Mai 2010


Foto von Bill Gates einfügen - Hier haben wir einen Entrepreneur.


Foto von Steve Jobs einfügen - Der vor zwei Wochen in der Aktienkapitalisierung von diesem Entrepreneur überholt wurde. Entrepreneure gab es aber auch schon vorher.


Hier haben wir einen. Das ist Gustav. Er ist der klassische jugendliche Entrepreneur - ähnlich Bill Gates, der schon mit 17 das Unternehmen seiner Eltern übernahm.


Das ist das elterliche Unternehmen - Schweden.


Schweden war damals im Schwerpunkt noch nicht auf Möbel spezialisiert, sondern auf

80%

20%

Agrar Seefahrt


... den Agrarbereich und die Seewirtschaft. Da Schweden nun mal zu den meisten Seiten durch mehr oder zuviel Schnee begrenzt war dachte er sich als Wachstumsstrategie, nehmen wir doch einfach mal mehr Produktionsmittel mit dazu.

http://www.flickr.com/photos/pdxdj/


Glücklicherweise war ein Konkurrenzunternehmen im Rahmen des dreissigjährigen Krieges gerade etwas geschwächt worden, und daher wollte unser Entrepreneur deren Marktanteile übernehmen.




Ausserdem, wenn schon sonst jeder Krieg führt, warum sollte man nicht mitmachen. Aber: Krieg ist ziemlich Resourcenhungrig, konkret für die Human Resources Abteilung.

http://www.flickr.com/photos/johncatral/


Also dachte er sich: bauen wir einfach ein Produkt, dass so klasse ist, dass sich die Konkurrenz von alleine vom Markt zurückzieht.



http://www.flickr.com/photos/mcaven/Sonntag, 30. Mai 2010

War jemand schon mal in Stockholm? Skansen angeschaut? Auch im Museum mit dem Schiff gewesen? Weiss jemand, wie das Schiff heisst?

http://www.flickr.com/photos/mcaven/

http://www.flickr.com/photos/mcaven/

Wikimedia


Das war seiner Superwaffe: Ein Schiffe, dass sehr viel Dekoration hatte, drei Masten, 69 Meter lang, 12 Meter breit und 52 Meter hoch - und - das war neu - zwei Kanonendecks.

2 Kanonendecks


2 Kanonendecks =


2 Kanonendecks =

doppelt so viele wie die anderen


2 Kanonendecks =

doppelt so viele wie die anderen=


2 Kanonendecks =

doppelt so viele wie die anderen=

EPIC WIN!


http://www.flickr.com/photos/kanelstrand/Sonntag, 30. Mai 2010

Der beauftragte Schiffsbauer „Henrik Hybertsson“ war bisher eher auf kleine Schiffe spezialisiert, die nur über ein Deck verfügten.

http://www.flickr.com/photos/kanelstrand/

http://www.flickr.com/photos/kanelstrand/


Fazit: Das Schiff war zwar sehr beeindruckend, und hätte den Gegner mit Sicherheit eingeschüchtert, wenn es jemals aus dem Hafen herausgekommen wäre - das ist es aber nicht, sondern bereits nach wenigen Minuten auf der Jungfernfahrt noch im Hafen gesunken.

?


Warum erzähl ich das ganze? Weil hier jemand zwei Konkurrierende Architekturmerkmale hatte - solide Bauart mit einem Deck vs. eindrucksvolle Erscheinung. Da sich das Management - sprich vorhin genannter Entrepreneur - aber für eindrucksvolle Erscheinung entschieden hat, musste es kommen wie es gekommen ist.

JOHANN-PETER HARTMANN


Das bin ich, willkommen zum Workshop!

PHP-DEVELOPER

Aber auch ein paar andere Sprachen im Koffer.


PHP-DEVELOPER

Aber auch ein paar andere Sprachen im Koffer.

Seit 3.0.4 :-)



Das ist auch schon über 10 Jahre her.

Gründer und CTO


Das ist auch schon über 10 Jahre her.


Ausserdem bin ich der CEO von SektionEins. Ich nehm das mal als Anlass, einfach zu Duzen - ist das in Ordnung? oder ist hier eher „DU sagst immer noch SIE zu mir...“ angesagt?

Gründer und CEO


Ausserdem bin ich der CEO von SektionEins. Ich nehm das mal als Anlass, einfach zu Duzen - ist das in Ordnung? oder ist hier eher „DU sagst immer noch SIE zu mir...“ angesagt?


Bei Mayflower machen wir Software für Firmen wie EON


... das von Telefonica eingesetzt wird ...

Architektur++


Es wäre also tendenziell gut, wenn wir Architektur könnten.

Wer ist Softwarentwickler?


Wer von Euch ist Entwickler?

Wer ist Softwarearchitekt?


Wer von Euch ist Softwarearchitekt?

Wer muss trotzdem irgendwiedie Architektur machen? :-)


Auch wenn es keinen echten Architekten gibt, ist Architektur häufig Bestandteil des Jobs.

Wer hat den European Song Contest gesehen?


Wer hat den European Song Contest gesehen?

Wer hat mit abgestimmt?


Wissen Deine Eltern das? Sind sie besorgt?

?


Ok, aber eigentlich wollen wir hier Softwarearchitektur machen. Was ist Eure Definition von Softwarearchitektur?

Was erwartet Ihr vom Vortrag?


Ich erzählte tatsächlich was über: Was ist Architektur, wie bewertet man die, wie sorgt man dafür, das man beim architekturaudit nicht auseinandergenommen wird?

ARCHITEKTUR


Motivation: Ein Mayflower-Talk: Fix your architecture, bei dem alle gesagt haben: der ist ja gar nicht über architektur.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.


Schauen wir mal, was die Profis sagen.*vorlesen* - Wie man sieht, komplizierte Satzstruktur, also haben wir es offensichtlich mit einem ungeschickten Autor oder einer komplexen Materie zu tun.

Architecture is high-level design.


This is true enough, in the sense that a horse is a mammal, but the two are not interchangeable.

Architecture is the overall structure of the system.


Schön wärs - eine Architektur sind in der Regel aber nicht nur eine, sondern viele Strukturen.

Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution over time.


Wer hat hier im Raum alles eine Architekturdokumentation?

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.


Also bleiben wir mal bei dieser Definition. Sie ist aus „Software Architecture in Praxis Second Edition“, von Len Bass, Paul Clements oder Rick Kazman. Bei den Jungs habe ich ziemlich viel gekupfert.Wichtig ist: Architektur definiert die Elemente eines Systems, nicht Ihre Implementierung.

ARCHITEKTUR!=

DESIGN


Was im inneren der Elemente ist, ist Design. MVC ist im Regelfall nicht nach aussen sichtbar - und dementsprechend ein Design, keine Architektur.

http://www.flickr.com/photos/ryanhayes/


Schauen wir uns doch einfach ein paar Beispiele für Architekturstile, englisch Architecture Patterns, an. Patterns sind keine globalen Architekturen, sondern Architekturmuster, von denen meist mehrere in der gesamten Architektur vorkommen.

client - server


Durch Browser und Webserver nutzt praktisch jede Webanwendung unter anderem eine Client-Server Struktur. Bei Mashups oder embedded Applications wie Facebook wird diese Struktur durchbrochen.

Frontend and Backend


Bei Frontend/ Backend handelt es sich um eine Trennung zwischen dem, was interagiert, und der Businesslogik. Durch SOA/REST-Architekturen erlebt diese Trennung gerade wieder einen Hype. Achtung: Frontend / Backend ist nicht mit Designs wie MVC zu verwechseln - weiss jemand warum?

Three-tier model


Klassischerweise presentation layer, business logic,database - und damit auch eine Grundstruktur von Webanwendungen mit Datenbankpersistenz. Key-Value-Datenbanken etc führen hier zu 4-Tier-Architekturen.

Event Driven Architecture


Hat jemand eine Ahnung, wo Eventgetriebene Architekturen vor allem vorkommen? Korrekt - in der GUI. Langsam schwappt dieses Architekturmuster aber auch in das Web - weil es sehr gut skaliert und hohe Responsivität erlaubt.

Redundante Hardware


Eine einfach zu verstehende Architektur - meist mit automatischem Failover durch Betriebssystem (Heartbeat), Netzwerk (Load Balancer) oder Applikation

Publish-Subscribe


Ich schicke eine Information irgendwo hin, und sie kann 0-n Empfänger haben. Viele Message-Queues implementieren diese Architektur.


Ein konkretes Beispiel dafür ist node.js. Wer von den anwesenden hat schon damit zu tun gehabt? Ein sehr Klasse spielzeug, wenn man dinge in Javascript machen möchte.

Implicit invocation


Die Technik hinter dem Observer-Designpattern: man registriert sich für ein Ereignis, und wird aufgerufen, wenn dieses eintritt.


Das ganze wird auch Hollywood-Principle genannt- don‘t call us, we call you.

Monolithic application


Der Klassiker ist die monolithische Applikation. Damit fängt jeder einmal an, und es gab eine dunkle Zeit, in der alle Applikationen so aussahen. Hier kümmert sich die Applikation um Nutzerinterface, Speichern von Daten und hat keine externen Abhängigkeiten - kennt jemand ein Beispiel? Korrekt - Microsoft Office ;-)

Microsoft Word


Peer 2 Peer


Warez, Muzak, filesharing - aber auch NNTP (also Usenet), Skype oder Spotify

C.O.A.


Hier handelt es sich um Architekturen wie CORBA, Microsofts DCOM, OLE, XPCOM in Firefox oder Java EE - einzelne Komponenten arbeiten für sich losgelöst und können von anderen eingebunden werden.

Pipes and Filters


Eine Sonderform von Component Based Architectures sind Pipes und Filters - hier können komponenten durch Ein/Ausgabe-Streams miteinander verbunden werden und das Ergebnis der Vorgänger weiterverarbeiten können - wie etwa im Unix-System.

S.O.A.


Eine Spezialisierung von COA ist SOA - service oriented architecture, auch REST. Ursprünglich um eine bessere Architektur von sehr grossen systemen zu erlauben, heute wird es auch gerne gemacht, um Teile von Webapplikationen auch für andere Applikationen nutzbar zu machen - etwa durch eine Webbasierte Schnittstelle.

Shared nothing


Einer der Gründe, warum PHP so populär ist - wenn ich nichts gemeinsam benutze, kann ich einfach linear über Blech skalieren. Viel Infrastruktur hinter Google basiert auf dieser Idee.

Space based


Space based ist btw. sehr cool. da wirft man POJOs gegen einen Stapel worker und guckt nach, was rauskommt.

Messaging/Queues


Asynchronous Workqueues: Synchronous work asynchronous. If you have time, why do it now? ActiveMQ, RabbitMQ, Gearman for the cool internet startup.Wie sieht das ganze in der Praxis aus?

Framework


Die Wahl des Frameworks ist eine Architekturentscheidung, die viele andere Architektur- und Designentscheidungen vorweg nimmt.

Applikation


Das ist die einfachste Form der Applikation, ein Monolith.

Applikation

Datenbank


Eine klassische Two-Tier-Architektur, nimmt man den Browser mit dazu Tree-Tier.

Frontend

Datenbank

Backend


Weil es gerade modern ist, trennen wir Frontend und Backend -und lassen die über eine definierte Schnittstelle miteinander reden - gute Gründe sind zB, wenn auch andere Dienste auf unser Backend zugreifen sollen.

Frontend

Datenbank

Backend External Service

IPhone-App


Wie zum Beispiel, zeitgemäß, eine Iphone App. (Frage: Wer ist Android? Wer ist Iphone?) Aber nicht nur ich kann für andere Applikationen Services anbieten, ich kann auch fremde Services einbinden. Das können Payment-Gateways sein, eine Maps-Variante als auch andere interne services.

Frontend

Datenbank


IPhone-App

Indizierer

SuchIndex


Und weil mit der IPhone-App automatisch der massive Erfolg da ist, muss die Suche in einen Solr ausgelagert werden. Weil ich PDF und Word-Files automatisch wandle, wird das ganze asynchron über einen Indizierer gemacht, der den Solr-Topf füllt, der dann synchron abgefragt wird.

Frontend

Datenbank


IPhone-App

Indizierer

SuchIndex

?Sonntag, 30. Mai 2010

Aber was sagt uns dieses Diagramm genau?

Frontend

Datenbank


IPhone-App

Indizierer

SuchIndex


Hardware? Prozesse? Request-Basiert oder Asynchron? Verteilt?Welche Funktion haben die Elemente genau in der Architektur?

Frontend

Datenbank


IPhone-App

Indizierer

SuchIndex


Was sind die Verbindungen? Direkte Kommunikation? Kontrolliert ein Element das andere? Rufen sie sich gegenseitig auf, synchronisieren sie sich? Um eine Architektur zu beschreiben benötigt man also eine ganze Reihe von Diagrammen und Beschreibungen. Ausser, man baut nur Monolithen.

Was macht eine gute Architektur aus?


Frage an die Zuhörer: Was macht eine gute Architektur aus?Welche Kriterien muss eine Architektur erfüllen?

Funktionalität


Zunächst einmal müssen die vom Kunden angeforderten Requirements erfüllt werden - das ist klar. Wenn der Zweck der Anwendung nicht erfüllt wird, gibt es keine Anwendung. Aber Architektur geht darüber hinaus.

?


Hat jemand eine Idee, was weiterhin noch von der Architektur geliefert werden soll? Gibt es bestimmte Anforderungen, die eine Architektur neben der offensichtlichen Funktionalität erfüllen soll?

Qualitätskriterien


FURPS

?


Quizfrage: Was bedeutet FURBS? Englisches Umgangswort für Aufstossen, eine Knuddelalienrasse aus Star Trek 1?

FunctionalityUsabilityReliabilityPerformanceSecurity


Funktionalität - das, was der Kunde eigentlich wollte (typischerweise am Tag der Abgabe)Usability - Wenn der Kunde das gewollt hätte hätte er keinen Programmierer fragen sollenReliability - die Verlässlichkeit der Applikation, Fehlerfreiheit und VerfügbarkeitPerformance - Antwortzeit, Durchsatz, Bandbreite und vieles andereSecurity- Sicherheit in Netzwerk, Daten, Angriffsarten


Aber es geht natürlich noch komplizierter ...

ISO 9126


ISO 9126Wer ein fotografisches

Gedächtnis hat ist klar im Vorteil.


Funktionalität


Analog zu Furbs spielt Funktionalität den erste und wichtigsten PunktInwieweit besitzt die Software die geforderten Funktionen? - Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen.

AngemessenheitFunktionalität:


Eine Randfunktionalität sollte nicht 80% der Programmierung verursachen.

RichtigkeitFunktionalität:


Der Durchschnittsentwickler: Ich glaube gesehen zu haben, dass es bei mir einmal bei einer bestimmten Konstellation ein richtiges Ergebnis geliefert hätte.

InteroperabilitätFunktionalität:


Das verschweigen wir Developer gerne, dass wir das auch könnten, wenn wir wollten - statt dessen verkaufen wir lieber eine enterprisig klingende Middle-Ware-Architektur.

SicherheitFunktionalität:


Das können wir PHPler inzwischen ganz gut. Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern.

OrdnungsmässigkeitFunktionalität:


Hej, es ist eine ISO-Norm. Also wird bei Funktionalität Konformität zu Standards gefordert. Das können aber auch interne, eigene Standards sein. Im Regelfall reicht es, auf dem Papier zu dokumentieren, dass man sie einhält, und in der echten Architektur einfach das zu machen, wozu man Bock hat.

Zuverlässigkeit


Bei Zuverlässigkeit haben wir Entwickler einen doofen Fehler gemacht. Damals, auf DOS, war es ok, wenn eine Software nach dem Start einfach mal eine Weile lief, wenn sie zwischendurch mal Gabberish redet oder einfach abstürzt, dann hat der Nutzer neu gestartet und in Zukunft um die Ursache herum gearbeitet. Heute ist es leider weniger Komfortabel, der Nutzer erwartet allen Ernstes, dass die Software einfach funktioniert.

ReifeZuverlässigkeit:


Wenige Fehler und wenige Bugs. Das können wir alle ziemlich gut, meist hört es nur an dem Tag auf, an dem der Kunde beginnt, die Software tatsächlich zu benutzen.

FehlertoleranzZuverlässigkeit:


Kann sich noch jemand an den Commodore Amiga erinnern? Sein Bluescreen hiess „Guru Meditation“ und versprach, dass der Rechner wieder zu potte kommen würde. Kam er aber nicht. Für diejenigen unter Euch, die Fehler machen: wenn einer passiert, sollte der Nutzer nicht mit einem weissen Screen „Please contact your local system administrator“ konfrontiert werden - ausser, euer Administrator hat es einfach verdient, so wie unserer.

RobustheitZuverlässigkeit:


Fähigkeit, ein stabiles System bei Eingaben zu gewährleisten, die gar nicht vorgesehen sind. Die Software hält DAUs stand. Tipp für Leute ohne gut skalierbaren Idioten im Unternehmen: einfach mal im familiären Kreis schauen, da gibt es eigentlich immer irgendwen, der hartnäckig komische Dinge von Software verlangt und einen anruft, wenn es nicht klappt.

WiederherstellbarkeitZuverlässigkeit:


Wenn eine Fehler auftrat, kann man den irgendwie wieder gut machen? Oder muss man bei den Robotern, die die Simulation steuern in der wir leben nachfragen, ob sie die Matrix noch mal auf dem Snapshot von 9:35 restarten können?

KonformitätZuverlässigkeit:


Und hier auch wieder die Duftmarke der ISO-Norm: Werden Standards, auch gerne die eigenen, erfüllt?

Benutzbarkeit


Entgegen anderslautenden Gerüchten unter Developern reicht hier nicht der theoretische Nachweis, dass mit einer hochgetunten Intuition ohnehin alles offensichtlich ist, schliesslich verstehe ich als Developer ja auch alles. Die Benutzbarkeit ist der Aufwand, den ich _nicht_ zum Einlernen und Verstehen brauche.

VerständlichkeitBenutzbarkeit:


Ist Konzept und Anwendung auch für sterbliche verständlich? Oder sind die tieferen Logiken nur dem Developer mit Schwerpunkt auf Prolog zugänglich?

ErlernbarkeitBenutzbarkeit:


Aufwand für den Benutzer, die Anwendung zu erlernen (z. B. Bedienung, Ein-, Ausgabe).Tipp für Entwickler: Einfach mal wichtige Funktionen hinter einem verwirrend benannten Button verstecken. Das freut die Vertriebsabteilung, da wird gleich die Schulung hinterherverkauft. Kennt jemand Unternehmen, die immer gleich Schulungen mitverkaufen?

BedienbarkeitBenutzbarkeit:


Aufwand für den Benutzer, die Anwendung zu bedienen. Wieviele Clicks sind zu machen, wieviele Screens sind zu verstehen um einen einfachen Workflow durchzuführen?

AttraktivitätBenutzbarkeit:


Daaaa kann Apple mitreden. Ist die Oberfläche sexy? Will ich mit der Applikation gesehen werden? Nehme ich sie heimlich mit unter die Bettdecke?

KonformitätBenutzbarkeit:


Und, die ISO-Duftmarke wieder.

Effizienz


Nicht nur die Frage, wie schnell die Seite antwortet - sondern vor allem, was leistet die software für die eingesetzten Betriebsmittel? Braucht es einen Strato-Account oder eine Sun Enterprise mit Oracle-Lizenzen für 32 CPUs?

ZeitverhaltenEffizienz:


Wieviele Requests pro Sekunde? Und, „Responsivität ist das neue Schwarz“, wie schnell kommt die Antwort? „Wir können 40 Requests pro Sekunde, sie dauern nur jeweils 10 Minuten“

VerbrauchsverhaltenEffizienz:


Wieviel CPU / Festplatte wird für eine bestimmte Leistung gebraucht? Wenn ich nen Hardwarehersteller wäre, der sowas verkauft, würde ich versuchen eine Plattform zu bauen, die möglichst viel davon braucht .... am besten mit einer eigenen Programmiersprache ... andere Hardwarehersteller wie IBM würden das bestimmt stützen ... Moment mal ...

KonformitätEffizienz:


Tjahaha, und die ISO-Jungs wieder ...

Änderbarkeit


Da beginnen unsere Kunden zu grinsen - Änderbarkeit ist die Fähigkeit, neue Features abzubilden und Fehler zu korrigieren. Deshalb wollen unsere Kunden so PHP-Jungs wie uns - weil angeblich können wir das super.

AnalysierbarkeitÄnderbarkeit:


Das ist ein spannender Punkt. So Systeme wie Symfony oder Ruby on Rails erlauben es, deutlich schneller als mit zB dem Zend Framework zu arbeiten. Auf der anderen Seite passiert viel impliziert über lustige Hooks usw, und man weiss gar nicht immer, was man gerade alles anfässt - zum Nachteil der Analysierbarkeit. Auf der anderen Seite schadet Dokumentation und ein Gehirn auch nicht zwangsläufig.

ModifizierbarkeitÄnderbarkeit:


Das ist mal die konkrete Änderung. Wie lange brauch ich dafür. Habe ich eine saubere Trennung der Concerns, oder muss ich in 7 Layern jeweils etwas ändern, um ein geändertes Requirement abzubilden. Das ganze wird boykottiert von schlechten Boundaries und natürlich von hoher Cohesion.


Spaghetti-Code zu fixen ist keine Freude.

StabilitätÄnderbarkeit:


„Hey Boss, kein Problem, hab ich in 5 Minuten Live“ „Ja, die Produktionsseite läuft gerade nicht, aber das hab ich gleich.“ „Uh, da war noch eine andere Sache, ich muss nur kurz die Library umschreiben.“ „Chef, ich rufe aus dem Flugzeug nach Brasilien aus an, und wollte nur sagen, es tut mir leid!“

TestbarkeitÄnderbarkeit:


Der Durchschnittsprogrammierer denkt: Verdammt, testen auch noch? Wer arbeitet hier test-driven? Wir haben die erfahrung gemacht, dass bei hohen änderungsfrequenzen von grossen requirements testdriven keine freude ist. Aber halt weniger scheisse als die alternative.

Übertragbarkeit


Für Commodity-software trivial: läuft das überall. Aber auch Inhouse von bedeutung - Änderungen von Plattformen, datenbanken, der Serverstruktur etc.

AnpassbarkeitÜbertragbarkeit:


Kann ich die Software schnell anpassen. Anders formuliert: habe ich zB eine Datenbankabstraktion?

InstallierbarkeitÜbertragbarkeit:


Wer benutzt hier Capistrano oder irgendein automatisches Deployment? Wer installiert per Hand? Wie lange dauert das?

KoexistenzÜbertragbarkeit:


Verlange ich spezialitäten von meiner umgebung, die dem rest der welt weh tun? register_globals, anyone?

AustauschbarkeitÜbertragbarkeit:


Wie gut lässt sich meine Software wegwerfen?

KonformitätÜbertragbarkeit:


Und die ISO-Jungs wieder, war ja klar.

O - Kay ...


Müssen wir wirklich alles beachten, wenn wir eine Architektur auswählen?

?


Wer von den hier Anwesenden berücksichtigt jedesmal alle Aspekte?

Zu einer anderen Zeit, an einem anderen Ort ...


Zu einer anderen Zeit, an einem anderen Ort ...

Heute, in der Realität


Default-Toolset des Unternehmens


Alte Bekannte 1:Dinge, die sich in der Vergangenheit

bewährt haben ...


Alte Bekannte II:... und Dinge, die sich in der

Vergangenheit nicht bewährt haben.


Technik mit Coolness-Faktor


Das „echte“ Architekturvorgehen: Ich habe eine coole Lösung, die ich spannend finde, die jemand verblogt hat.

Ich habe eine Lösung, und suche nach einem Passenden Problem


Map-Reduce anyone? NoSQL? Message-Queues?

"Nobody ever got fired for choosing Java"


• Innere Plattform

•Wheel Factory

• Gas Factory

• Golden Hammer

• ... und vieles mehr ...

ARCHITEKTURNEUROSEN


Innere Plattform: Das System ist so universell Konfigurierbar, dass es letztlich nur eine schwache Kopie der Plattform ist, auf der es gebaut ist. Beispiel: Ein Beispiel sind „flexible“ Datenmodelle, die auf konkrete (anwendungsbezogene) Datenbanktabellen verzichten und stattdessen mittels allgemeiner Tabellen eine eigene Verwaltungsschicht für die Datenstruktur implementieren.Wheel Factory: Es wird jeweils etwas eigenes erfunden, anstelle etablierte Tools zu nutzen.Gas Factory: ein einfaches Problem wird Enterprise gelöstGolden Hammer: Ein bevorzugter Lösungsweg wird als universell beste Lösung angesehen.


Alle diese Dinge _können_ klappen, müssen aber nicht.- nicht durch andere Nachvollziehbar - nicht optimal für das Problem- die Entscheidungsfindung und Motivation wurde nicht dokumentiert Daher: Machen und Beten? Klingt nicht wirklich optimal ...

ATAM


ArchitectureTradeoffAnalysisMethod


Die Tradeoff Analyse geht davon aus, dass es keine perfekte Architektur für alles gibt. sondern nur Architekturen, die für jede Aufgabe ein paar Vorteile und ein paar Nachteile mitbringen.


Das ganze kommt vom Software Engineering Institute, und ist eigentlich für die Bewertung von Architekturen im Vergleich gedacht.

Es gibt kein Silver Bullet?


ATAM

Ermöglicht die Ermittlung präziser Qualitätskriterien


ATAM

Erzeugt eine frühe Architekturdokumentation.


ATAM

Erzeugt eine dokumentierte Basis für Architekturentscheidungen


ATAM

Erkennt Risiken früh im Software LifeCycle


ATAM

Erzeugt bessere Kommunikation zwischen den Stakeholdern



Wie sieht ATAM genau aus? „Was issene Dampfmaschin? Da stellen wir uns mal ganz dumm ...

Business Drivers


Welche Ziele verfolgen wir mit dem Projekt? Was sind unsere Prioriäten dort?

FUNKTIONALITÄT


TECHNISCHE EINSCHRÄNKUNGEN

„Muss auf Windows laufen“

„Datenbank ist Oracle.“„Unsere Entwickler können nur PHP!“

„Alles auf unserem eigenen Framework!“


?


Welche technischen Einschränkungen gibt es bei Euch?

BUSINESS GOALS

1.OpenSource, Standards and of-the-shelf

2.Systemkomplexität reduzieren, Komponentenwiederverwendung

3.Einfache Reparatur / Maintenance

4.Kostengünstige Änderungen / neue Features

5.Flexibilität und Konfigurierbarkeit


Die Werte kommen aus unserer Studie, einfach bei uns im Blog runterladen.


Stakeholder gibts viele, der erste ist aber klar: Das sind natürlich erst mal die Jungs, die unsere Rechnung bezahlen. Aber nicht nur die.


Daneben gibt es noch die Leute, die unsere Software benutzen müssen, - Leute, die die Software später weiterentwickeln müssen,- Leute, die die Software in Produktion warten müssen - Leute, die die Software testen müssenetc ...

QUALITÄTSKRITERIEN

Was war FURPS noch mal?



Auf Basis der Qualitätskriterien wird der Utility Tree gebaut, mit den Qualitätskriterien, die - ganz konkret - für die Stakeholder eine grosse, wichtige Rolle spielen. Alle anderen, nicht relevanten Qualitätskriterien werden ausgeblendet.


Für jedes Blatt des Utility Trees wird eine Szenario entworfen.

SZENARIEN

• Repräsentieren die Interessen der Stakeholder

• um die Wirkung der Qualitätskriterien zu ermitteln


SZENARIEN

• stellen wichtige Usecases dar

• stellen erwartete Änderungen dar

• stellen nicht erwartete Ereignisse da


Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie vorherNicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.

GUTE SZENARIEN

•Use Case: Die Startseite benötigt im Tagespeak nicht mehr als 1500 ms zur Darstellung

• erwartete Änderungen: Bei Verdopplung der Nutzer kann durch Verdopplung der Applikationsserver die gleiche Responsivität erzielt werden

•Nicht erwartete Änderungen: Nach einem Datenbankserver-Plattencrash ist innerhalb von 30 Minuten wieder für alle Nutzer normaler Betrieb möglich.


Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie vorherNicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.


Diese Szenarien werden mit der Priorität bewertet - H(igh), M(edium), L(ow)

(Zend, Cake, Symfony)-Framework-basiert

Magento erweitern

REST-Architektur

Gearman-Message-Queue

ORM

JavaScript Toolkit

Generiertes JavaScript

NoSQL


Danach werden mögliche Architekturansätze gesammelt. Die können jeglicher Art sein, und sich natürlich in Teilaspekten des Systems jeweils ergänzen.

Does it Blend?Sonntag, 30. Mai 2010

Die Architekturen, die Anfangs vom Team ermittelt wurden, werden jetzt jeweils gegen den Utility Tree geworfen, und geschaut, ob es zusammen aufgeht.


Fehlertoleranz und Performance konkurrieren zB häufig. Oder eine Architektur erlaubt gar kein schnelles Ändern des Layouts. Oder die Queue wird - wie bei gearman - im Speicher gehalten, und bei einem Hardwarefehler gehen zwangsläufig Daten verloren.

ANALYSE

•Welche Architekturen erfüllen die wichtigsten Qualitätsattribute?

•Welche Risiken entstehen, weil bestimmte Attribute in einer Architektur nicht erfüllt werden können?

•Welche Tradeoffs existieren?



Zusammen mit den Stakeholdern werden die Konsequenzen der Architekturwahl besprochen und eine Architekturentscheidung getroffen.

Das ganze noch mal im Schnelldurchlauf


•Business Treiber definieren

•Utility Tree auf Basis von Qualitätskriterien definieren

•Szenarien erzeugen und Priorisieren

•Architekture gegen Utility Tree Analysieren

•Ergebnis präsentieren & Entscheiden


Gruppenarbeit!

Vorstellen der Ergebnisse: 17:30Sonntag, 30. Mai 2010

• Funktionalität: Angemessenheit, Richtigkeit, Interoperabilität, Sicherheit

• Zuverlässigkeit: Reife, Fehlertoleranz, Robustheit, Wiederherstellbarkeit

•Benutzbarkeit: Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität

• Effizienz: Zeitverhalten, Verbrauchsmaterialien

•Änderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, Testbarkeit

•Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit

Vorstellen der Ergebnisse: 17:30Sonntag, 30. Mai 2010

Noch Fragen?


http://www.amazon.de/Software-Architecture-Practice-SEI-Engineering/dp/0321154959/

http://de.wikipedia.org/wiki/ISO/IEC_9126

http://c2.com/cgi-bin/wiki?AntiPatternsCatalog






Softwarearchitektur vs. PHP

Technology

Transcript of Softwarearchitektur vs. PHP