SlideShare ist ein Scribd-Unternehmen logo
SOFTWARE ARCHITEKTUR
                        VS
                       PHP
                        Workshop IPC Frühjahr 2010
                           in Berlin (in Berlin!)




Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010

Foto von Bill Gates einfügen -
Hier haben wir einen Entrepreneur.
Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010

Das ist das elterliche Unternehmen - Schweden.
Sonntag, 30. Mai 2010

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



                             20%




                                                80%



Sonntag, 30. Mai 2010

... 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/
Sonntag, 30. Mai 2010

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

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/
Sonntag, 30. Mai 2010

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?
Wikimedia

Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010
2 Kanonendecks




Sonntag, 30. Mai 2010
2 Kanonendecks
                              =




Sonntag, 30. Mai 2010
2 Kanonendecks
                       =
       doppelt so viele wie die anderen




Sonntag, 30. Mai 2010
2 Kanonendecks
                       =
       doppelt so viele wie die anderen
                       =



Sonntag, 30. Mai 2010
2 Kanonendecks
                       =
       doppelt so viele wie die anderen
                       =
                  EPIC WIN!

Sonntag, 30. Mai 2010
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.
Sonntag, 30. Mai 2010

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.
?

Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

Das bin ich, willkommen zum Workshop!
PHP-
           DEVELOPER
         Aber auch ein paar andere
            Sprachen im Koffer.




Sonntag, 30. Mai 2010
Seit 3.0.4 :-)



              PHP-
           DEVELOPER
         Aber auch ein paar andere
            Sprachen im Koffer.




Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010

Das ist auch schon über 10 Jahre her.
Gründer und CTO




Sonntag, 30. Mai 2010

Das ist auch schon über 10 Jahre her.
Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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?
Sonntag, 30. Mai 2010

Bei Mayflower machen wir Software für Firmen wie EON
Sonntag, 30. Mai 2010

... das von Telefonica eingesetzt wird ...
Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010
Architektur++

Sonntag, 30. Mai 2010

Es wäre also tendenziell gut, wenn wir Architektur könnten.
Wer ist Softwarentwickler?




Sonntag, 30. Mai 2010

Wer von Euch ist Entwickler?
Wer ist Softwarearchitekt?




Sonntag, 30. Mai 2010

Wer von Euch ist Softwarearchitekt?
Wer muss trotzdem irgendwie
                         die Architektur machen? :-)




Sonntag, 30. Mai 2010

Auch wenn es keinen echten Architekten gibt, ist Architektur häufig Bestandteil des Jobs.
Wer hat den European
                        Song Contest gesehen?




Sonntag, 30. Mai 2010

Wer hat den European Song Contest gesehen?
Wer hat mit abgestimmt?




Sonntag, 30. Mai 2010

Wissen Deine Eltern das? Sind sie besorgt?
?

Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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.




Sonntag, 30. Mai 2010

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.	





Sonntag, 30. Mai 2010

This is true enough, in the sense that a horse is a mammal, but the two are not
interchangeable.
Architecture is high-level design.	





Sonntag, 30. Mai 2010

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.




Sonntag, 30. Mai 2010

Schön wärs - eine Architektur sind in der Regel aber nicht nur eine, sondern viele Strukturen.
Architecture is the overall structure of the
             system.




Sonntag, 30. Mai 2010

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.




Sonntag, 30. Mai 2010

Wer hat hier im Raum alles eine Architekturdokumentation?
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.




Sonntag, 30. Mai 2010

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.




Sonntag, 30. Mai 2010

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



Sonntag, 30. Mai 2010

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/




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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

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




Sonntag, 30. Mai 2010

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

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010
Peer 2 Peer




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

Warez, Muzak, filesharing - aber auch NNTP (also Usenet), Skype oder Spotify
C.O.A.


Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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.


Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

Das ist die einfachste Form der Applikation, ein Monolith.
Applikation




                                     Datenbank



Sonntag, 30. Mai 2010

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




                                        Backend




                                      Datenbank



Sonntag, 30. Mai 2010

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                          IPhone-App




                         Backend                       External Service




                        Datenbank



Sonntag, 30. Mai 2010

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                           IPhone-App




                         Backend                         External Service




                                                             Indizierer

                        Datenbank

                                                            SuchIndex

Sonntag, 30. Mai 2010

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             IPhone-App




                         Backend           External Service




                                              Indizierer

                        Datenbank

                                             SuchIndex

Sonntag, 30. Mai 2010

Aber was sagt uns dieses Diagramm genau?
Frontend                           IPhone-App




                         Backend                        External Service




                                                                Indizierer

                        Datenbank

                                                            SuchIndex

Sonntag, 30. Mai 2010

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




                         Backend                        External Service




                                                            Indizierer

                        Datenbank

                                                           SuchIndex

Sonntag, 30. Mai 2010

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?




Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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.
?

Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010
F
                 U
                 R
                 P                        ?
                 S

Sonntag, 30. Mai 2010

Quizfrage: Was bedeutet FURBS?
Englisches Umgangswort für Aufstossen,
eine Knuddelalienrasse aus Star Trek 1?
F
                 U
                 R
                 P                        ?
                 S

Sonntag, 30. Mai 2010

Quizfrage: Was bedeutet FURBS?
Englisches Umgangswort für Aufstossen,
eine Knuddelalienrasse aus Star Trek 1?
F
                 U
                 R
                 P                        ?
                 S

Sonntag, 30. Mai 2010

Quizfrage: Was bedeutet FURBS?
Englisches Umgangswort für Aufstossen,
eine Knuddelalienrasse aus Star Trek 1?
Functionality
                 Usability
                 Reliability
                 Performance
                 Security

Sonntag, 30. Mai 2010

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 sollen
Reliability - die Verlässlichkeit der Applikation, Fehlerfreiheit und Verfügbarkeit
Performance - Antwortzeit, Durchsatz, Bandbreite und vieles andere
Security- Sicherheit in Netzwerk, Daten, Angriffsarten
Sonntag, 30. Mai 2010

Aber es geht natürlich noch komplizierter ...
ISO 9126

Sonntag, 30. Mai 2010
ISO 9126
                            Wer ein fotografisches
                        Gedächtnis hat ist klar im Vorteil.




Sonntag, 30. Mai 2010
Funktionalität


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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.
Funktionalität:
                             Sicherheit


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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.
Zuverlässigkeit:
                                    Reife


Sonntag, 30. Mai 2010

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.
Zuverlässigkeit:
                          Fehlertoleranz


Sonntag, 30. Mai 2010

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.
Zuverlässigkeit:
                             Robustheit


Sonntag, 30. Mai 2010

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.
Zuverlässigkeit:
                Wiederherstellbarkeit


Sonntag, 30. Mai 2010

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?
Zuverlässigkeit:
                            Konformität


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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.
Benutzbarkeit:
                        Verständlichkeit


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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?
Benutzbarkeit:
                          Bedienbarkeit


Sonntag, 30. Mai 2010

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?
Benutzbarkeit:
                           Attraktivität


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

Und, die ISO-Duftmarke wieder.
Effizienz


Sonntag, 30. Mai 2010

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?
Effizienz:
                        Zeitverhalten


Sonntag, 30. Mai 2010

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“
Effizienz:
                    Verbrauchsverhalten


Sonntag, 30. Mai 2010

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 ...
Effizienz:
                    Verbrauchsverhalten


Sonntag, 30. Mai 2010

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 ...
Effizienz:
                         Konformität


Sonntag, 30. Mai 2010

Tjahaha, und die ISO-Jungs wieder ...
Änderbarkeit


Sonntag, 30. Mai 2010

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.
Änderbarkeit:
                        Analysierbarkeit


Sonntag, 30. Mai 2010

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.
Änderbarkeit:
                        Modifizierbarkeit


Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010

Spaghetti-Code zu fixen ist keine Freude.
Änderbarkeit:
                               Stabilität


Sonntag, 30. Mai 2010

„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!“
Änderbarkeit:
                            Testbarkeit


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010

Wie gut lässt sich meine Software wegwerfen?
Übertragbarkeit:
                            Konformität


Sonntag, 30. Mai 2010

Und die ISO-Jungs wieder, war ja klar.
O - Kay ...


Sonntag, 30. Mai 2010

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

Sonntag, 30. Mai 2010

Wer von den hier Anwesenden berücksichtigt jedesmal alle Aspekte?
Zu einer anderen Zeit,
      an einem anderen Ort ...



Sonntag, 30. Mai 2010
Zu einer anderen Zeit,
      an einem anderen Ort ...
                        Heute, in der Realität




Sonntag, 30. Mai 2010
Default-Toolset des
                         Unternehmens


Sonntag, 30. Mai 2010
Alte Bekannte 1:
     Dinge, die sich in der Vergangenheit
              bewährt haben ...


Sonntag, 30. Mai 2010
Alte Bekannte II:
     ... und Dinge, die sich in der
Vergangenheit nicht bewährt haben.


Sonntag, 30. Mai 2010
Technik mit
                        Coolness-Faktor


Sonntag, 30. Mai 2010

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



Sonntag, 30. Mai 2010

Map-Reduce anyone?
NoSQL?
Message-Queues?
"Nobody ever got fired
                   for choosing Java"


Sonntag, 30. Mai 2010
ARCHITEKTURNEUROSEN

    • Innere            Plattform

    • Wheel              Factory

    • Gas          Factory

    • Golden              Hammer

    • ... und           vieles mehr ...


Sonntag, 30. Mai 2010

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öst
Golden Hammer: Ein bevorzugter Lösungsweg wird als universell beste Lösung angesehen.
Sonntag, 30. Mai 2010

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


Sonntag, 30. Mai 2010
Architecture
                          Tradeoff
                          Analysis
                          Method


Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010

Das ganze kommt vom Software Engineering Institute, und ist eigentlich für die Bewertung
von Architekturen im Vergleich gedacht.
Es gibt kein Silver Bullet?


Sonntag, 30. Mai 2010
ATAM


             Ermöglicht die Ermittlung präziser Qualitätskriterien




Sonntag, 30. Mai 2010
ATAM


                        Erzeugt eine frühe Architekturdokumentation.




Sonntag, 30. Mai 2010
ATAM


                        Erzeugt eine dokumentierte Basis für
                             Architekturentscheidungen




Sonntag, 30. Mai 2010
ATAM


                        Erkennt Risiken früh im Software LifeCycle




Sonntag, 30. Mai 2010
ATAM


 Erzeugt bessere Kommunikation zwischen den Stakeholdern




Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010
TECHNISCHE
                        EINSCHRÄNKUNGEN

                          „Muss auf Windows laufen“

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

                          „Alles auf unserem eigenen Framework!“

Sonntag, 30. Mai 2010
?

Sonntag, 30. Mai 2010

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

Sonntag, 30. Mai 2010

Die Werte kommen aus unserer Studie, einfach bei uns im Blog runterladen.
Sonntag, 30. Mai 2010

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

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üssen
etc ...
QUALITÄTSKRITERIEN


                           Was war FURPS noch mal?




Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010

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




Sonntag, 30. Mai 2010
SZENARIEN


    • stellen           wichtige Usecases dar

    • stellen           erwartete Änderungen dar

    • stellen           nicht erwartete Ereignisse da




Sonntag, 30. Mai 2010

Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie
vorher
Nicht 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.

Sonntag, 30. Mai 2010

Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie
vorher
Nicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.
Sonntag, 30. Mai 2010

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

                        (Zend, Cake, Symfony)-
                          Framework-basiert
                                                       REST-Architektur

                          ORM

                                                      Generiertes JavaScript
                Magento erweitern
                                         JavaScript Toolkit
                         NoSQL

Sonntag, 30. Mai 2010

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.
Sonntag, 30. Mai 2010

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?



Sonntag, 30. Mai 2010
Sonntag, 30. Mai 2010

Zusammen mit den Stakeholdern werden die Konsequenzen der Architekturwahl besprochen
und eine Architekturentscheidung getroffen.
Das ganze noch mal im Schnelldurchlauf




Sonntag, 30. Mai 2010
• Business Treiber         definieren

    • Utility Tree        auf Basis von Qualitätskriterien
        definieren

    • Szenarien          erzeugen und Priorisieren

    • Architekture         gegen Utility Tree Analysieren

    • Ergebnis          präsentieren & Entscheiden


Sonntag, 30. Mai 2010
Gruppenarbeit!




                        Vorstellen der Ergebnisse: 17:30
Sonntag, 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:30
Sonntag, 30. Mai 2010
Noch Fragen?




Sonntag, 30. Mai 2010
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



Sonntag, 30. Mai 2010

Weitere ähnliche Inhalte

Andere mochten auch

Herramientas 2
Herramientas 2Herramientas 2
Herramientas 2
Sebastian Montañez
 
Powerpointeduca lulucomba
Powerpointeduca lulucombaPowerpointeduca lulucomba
Powerpointeduca lulucomba
udotealuna
 
Otooinviernomodaclub2014 original me
Otooinviernomodaclub2014 original meOtooinviernomodaclub2014 original me
Otooinviernomodaclub2014 original me
GRIS LARA
 
Ambar cervantes b.s.c
Ambar cervantes b.s.cAmbar cervantes b.s.c
Ambar cervantes b.s.c
ambar22
 
historia de las computadoras
historia de las computadorashistoria de las computadoras
historia de las computadoras
Natalia Lopez Muñoz
 
Símbolos patrios del perú
Símbolos patrios del perúSímbolos patrios del perú
Símbolos patrios del perú
melissagamarra
 
Como diseñar una diapositiva en Power Point 2010
Como diseñar una diapositiva en Power Point 2010Como diseñar una diapositiva en Power Point 2010
Como diseñar una diapositiva en Power Point 2010
jcardenasperdomo
 
Teoría de los sistemas de información
Teoría de los sistemas de informaciónTeoría de los sistemas de información
Teoría de los sistemas de información
yanailert
 
ESTAMPADO CASERO
ESTAMPADO CASEROESTAMPADO CASERO
Fundamentos windows 7 practica
Fundamentos windows 7 practicaFundamentos windows 7 practica
Fundamentos windows 7 practica
ocarranzag
 
La enseñanza de las ciencias mediante proyectos de
La enseñanza de las ciencias mediante proyectos deLa enseñanza de las ciencias mediante proyectos de
La enseñanza de las ciencias mediante proyectos de
Hugo Alvarez Luis
 
Telesecundaria
TelesecundariaTelesecundaria
Cultura Empresarial
Cultura EmpresarialCultura Empresarial
Cultura Empresarial
MarjhoryLP
 
psicologia organizacional
psicologia organizacional psicologia organizacional
psicologia organizacional
20335130
 
Contenido
ContenidoContenido
Contenido
Maria Solano
 
Los valores
Los valoresLos valores
Los valores
erika2201
 
Presentacion curso
Presentacion cursoPresentacion curso
Presentacion curso
soniagalan40
 
Silabo informaticaambiental 1
Silabo informaticaambiental 1Silabo informaticaambiental 1
Silabo informaticaambiental 1
Rebk Vasconez
 

Andere mochten auch (18)

Herramientas 2
Herramientas 2Herramientas 2
Herramientas 2
 
Powerpointeduca lulucomba
Powerpointeduca lulucombaPowerpointeduca lulucomba
Powerpointeduca lulucomba
 
Otooinviernomodaclub2014 original me
Otooinviernomodaclub2014 original meOtooinviernomodaclub2014 original me
Otooinviernomodaclub2014 original me
 
Ambar cervantes b.s.c
Ambar cervantes b.s.cAmbar cervantes b.s.c
Ambar cervantes b.s.c
 
historia de las computadoras
historia de las computadorashistoria de las computadoras
historia de las computadoras
 
Símbolos patrios del perú
Símbolos patrios del perúSímbolos patrios del perú
Símbolos patrios del perú
 
Como diseñar una diapositiva en Power Point 2010
Como diseñar una diapositiva en Power Point 2010Como diseñar una diapositiva en Power Point 2010
Como diseñar una diapositiva en Power Point 2010
 
Teoría de los sistemas de información
Teoría de los sistemas de informaciónTeoría de los sistemas de información
Teoría de los sistemas de información
 
ESTAMPADO CASERO
ESTAMPADO CASEROESTAMPADO CASERO
ESTAMPADO CASERO
 
Fundamentos windows 7 practica
Fundamentos windows 7 practicaFundamentos windows 7 practica
Fundamentos windows 7 practica
 
La enseñanza de las ciencias mediante proyectos de
La enseñanza de las ciencias mediante proyectos deLa enseñanza de las ciencias mediante proyectos de
La enseñanza de las ciencias mediante proyectos de
 
Telesecundaria
TelesecundariaTelesecundaria
Telesecundaria
 
Cultura Empresarial
Cultura EmpresarialCultura Empresarial
Cultura Empresarial
 
psicologia organizacional
psicologia organizacional psicologia organizacional
psicologia organizacional
 
Contenido
ContenidoContenido
Contenido
 
Los valores
Los valoresLos valores
Los valores
 
Presentacion curso
Presentacion cursoPresentacion curso
Presentacion curso
 
Silabo informaticaambiental 1
Silabo informaticaambiental 1Silabo informaticaambiental 1
Silabo informaticaambiental 1
 

Mehr von Mayflower GmbH

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mayflower GmbH
 
Why and what is go
Why and what is goWhy and what is go
Why and what is go
Mayflower GmbH
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
Mayflower GmbH
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
Mayflower GmbH
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Mayflower GmbH
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
Mayflower GmbH
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native Client
Mayflower GmbH
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debugging
Mayflower GmbH
 
Usability im web
Usability im webUsability im web
Usability im web
Mayflower GmbH
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
Mayflower GmbH
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
Mayflower GmbH
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
Mayflower GmbH
 
Responsive Webdesign
Responsive WebdesignResponsive Webdesign
Responsive Webdesign
Mayflower GmbH
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Mayflower GmbH
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming Mythbusters
Mayflower GmbH
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im Glück
Mayflower GmbH
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 Sprints
Mayflower GmbH
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalieren
Mayflower GmbH
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce Breakfast
Mayflower GmbH
 

Mehr von Mayflower GmbH (20)

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
 
Why and what is go
Why and what is goWhy and what is go
Why and what is go
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native Client
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debugging
 
Usability im web
Usability im webUsability im web
Usability im web
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
 
Responsive Webdesign
Responsive WebdesignResponsive Webdesign
Responsive Webdesign
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming Mythbusters
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im Glück
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 Sprints
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalieren
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce Breakfast
 

Softwarearchitektur vs. PHP

  • 1. SOFTWARE ARCHITEKTUR VS PHP Workshop IPC Frühjahr 2010 in Berlin (in Berlin!) Sonntag, 30. Mai 2010
  • 2. Sonntag, 30. Mai 2010 Foto von Bill Gates einfügen - Hier haben wir einen Entrepreneur.
  • 3. Sonntag, 30. Mai 2010 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.
  • 4. Sonntag, 30. Mai 2010 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.
  • 5. Sonntag, 30. Mai 2010 Das ist das elterliche Unternehmen - Schweden.
  • 6. Sonntag, 30. Mai 2010 Schweden war damals im Schwerpunkt noch nicht auf Möbel spezialisiert, sondern auf
  • 7. Agrar Seefahrt 20% 80% Sonntag, 30. Mai 2010 ... 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.
  • 8. http://www.flickr.com/photos/pdxdj/ Sonntag, 30. Mai 2010 Glücklicherweise war ein Konkurrenzunternehmen im Rahmen des dreissigjährigen Krieges gerade etwas geschwächt worden, und daher wollte unser Entrepreneur deren Marktanteile übernehmen.
  • 9. Sonntag, 30. Mai 2010 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.
  • 10. http://www.flickr.com/photos/johncatral/ Sonntag, 30. Mai 2010 Also dachte er sich: bauen wir einfach ein Produkt, dass so klasse ist, dass sich die Konkurrenz von alleine vom Markt zurückzieht.
  • 11. 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?
  • 12. Wikimedia Sonntag, 30. Mai 2010 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.
  • 15. 2 Kanonendecks = Sonntag, 30. Mai 2010
  • 16. 2 Kanonendecks = doppelt so viele wie die anderen Sonntag, 30. Mai 2010
  • 17. 2 Kanonendecks = doppelt so viele wie die anderen = Sonntag, 30. Mai 2010
  • 18. 2 Kanonendecks = doppelt so viele wie die anderen = EPIC WIN! Sonntag, 30. Mai 2010
  • 19. 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.
  • 20. Sonntag, 30. Mai 2010 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.
  • 21. ? Sonntag, 30. Mai 2010 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.
  • 22. JOHANN-PETER HARTMANN Sonntag, 30. Mai 2010 Das bin ich, willkommen zum Workshop!
  • 23. PHP- DEVELOPER Aber auch ein paar andere Sprachen im Koffer. Sonntag, 30. Mai 2010
  • 24. Seit 3.0.4 :-) PHP- DEVELOPER Aber auch ein paar andere Sprachen im Koffer. Sonntag, 30. Mai 2010
  • 25. Sonntag, 30. Mai 2010 Das ist auch schon über 10 Jahre her.
  • 26. Gründer und CTO Sonntag, 30. Mai 2010 Das ist auch schon über 10 Jahre her.
  • 27. Sonntag, 30. Mai 2010 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?
  • 28. Gründer und CEO Sonntag, 30. Mai 2010 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?
  • 29. Sonntag, 30. Mai 2010 Bei Mayflower machen wir Software für Firmen wie EON
  • 30. Sonntag, 30. Mai 2010 ... das von Telefonica eingesetzt wird ...
  • 34. Architektur++ Sonntag, 30. Mai 2010 Es wäre also tendenziell gut, wenn wir Architektur könnten.
  • 35. Wer ist Softwarentwickler? Sonntag, 30. Mai 2010 Wer von Euch ist Entwickler?
  • 36. Wer ist Softwarearchitekt? Sonntag, 30. Mai 2010 Wer von Euch ist Softwarearchitekt?
  • 37. Wer muss trotzdem irgendwie die Architektur machen? :-) Sonntag, 30. Mai 2010 Auch wenn es keinen echten Architekten gibt, ist Architektur häufig Bestandteil des Jobs.
  • 38. Wer hat den European Song Contest gesehen? Sonntag, 30. Mai 2010 Wer hat den European Song Contest gesehen?
  • 39. Wer hat mit abgestimmt? Sonntag, 30. Mai 2010 Wissen Deine Eltern das? Sind sie besorgt?
  • 40. ? Sonntag, 30. Mai 2010 Ok, aber eigentlich wollen wir hier Softwarearchitektur machen. Was ist Eure Definition von Softwarearchitektur?
  • 41. Was erwartet Ihr vom Vortrag? Sonntag, 30. Mai 2010 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?
  • 42. ARCHITEKTUR Sonntag, 30. Mai 2010 Motivation: Ein Mayflower-Talk: Fix your architecture, bei dem alle gesagt haben: der ist ja gar nicht über architektur.
  • 43. 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. Sonntag, 30. Mai 2010 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.
  • 44. Architecture is high-level design. Sonntag, 30. Mai 2010 This is true enough, in the sense that a horse is a mammal, but the two are not interchangeable.
  • 45. Architecture is high-level design. Sonntag, 30. Mai 2010 This is true enough, in the sense that a horse is a mammal, but the two are not interchangeable.
  • 46. Architecture is the overall structure of the system. Sonntag, 30. Mai 2010 Schön wärs - eine Architektur sind in der Regel aber nicht nur eine, sondern viele Strukturen.
  • 47. Architecture is the overall structure of the system. Sonntag, 30. Mai 2010 Schön wärs - eine Architektur sind in der Regel aber nicht nur eine, sondern viele Strukturen.
  • 48. 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. Sonntag, 30. Mai 2010 Wer hat hier im Raum alles eine Architekturdokumentation?
  • 49. 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. Sonntag, 30. Mai 2010 Wer hat hier im Raum alles eine Architekturdokumentation?
  • 50. 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. Sonntag, 30. Mai 2010 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.
  • 51. ARCHITEKTUR != DESIGN Sonntag, 30. Mai 2010 Was im inneren der Elemente ist, ist Design. MVC ist im Regelfall nicht nach aussen sichtbar - und dementsprechend ein Design, keine Architektur.
  • 52. http://www.flickr.com/photos/ryanhayes/ Sonntag, 30. Mai 2010 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.
  • 53. client - server Sonntag, 30. Mai 2010 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.
  • 54. Frontend and Backend Sonntag, 30. Mai 2010 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?
  • 55. Three-tier model Sonntag, 30. Mai 2010 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.
  • 56. Event Driven Architecture Sonntag, 30. Mai 2010 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.
  • 57. Redundante Hardware Sonntag, 30. Mai 2010 Eine einfach zu verstehende Architektur - meist mit automatischem Failover durch Betriebssystem (Heartbeat), Netzwerk (Load Balancer) oder Applikation
  • 58. Publish-Subscribe Sonntag, 30. Mai 2010 Ich schicke eine Information irgendwo hin, und sie kann 0-n Empfänger haben. Viele Message-Queues implementieren diese Architektur.
  • 59. Sonntag, 30. Mai 2010 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.
  • 60. Implicit invocation Sonntag, 30. Mai 2010 Die Technik hinter dem Observer-Designpattern: man registriert sich für ein Ereignis, und wird aufgerufen, wenn dieses eintritt.
  • 61. Sonntag, 30. Mai 2010 Das ganze wird auch Hollywood-Principle genannt- don‘t call us, we call you.
  • 62. Monolithic application Sonntag, 30. Mai 2010 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 ;-)
  • 64. Peer 2 Peer Sonntag, 30. Mai 2010 Warez, Muzak, filesharing - aber auch NNTP (also Usenet), Skype oder Spotify
  • 65. Peer 2 Peer Sonntag, 30. Mai 2010 Warez, Muzak, filesharing - aber auch NNTP (also Usenet), Skype oder Spotify
  • 66. C.O.A. Sonntag, 30. Mai 2010 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.
  • 67. Pipes and Filters Sonntag, 30. Mai 2010 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.
  • 68. S.O.A. Sonntag, 30. Mai 2010 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.
  • 69. Shared nothing Sonntag, 30. Mai 2010 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.
  • 70. Space based Sonntag, 30. Mai 2010 Space based ist btw. sehr cool. da wirft man POJOs gegen einen Stapel worker und guckt nach, was rauskommt.
  • 71. Messaging/Queues Sonntag, 30. Mai 2010 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?
  • 72. Framework Sonntag, 30. Mai 2010 Die Wahl des Frameworks ist eine Architekturentscheidung, die viele andere Architektur- und Designentscheidungen vorweg nimmt.
  • 73. Applikation Sonntag, 30. Mai 2010 Das ist die einfachste Form der Applikation, ein Monolith.
  • 74. Applikation Datenbank Sonntag, 30. Mai 2010 Eine klassische Two-Tier-Architektur, nimmt man den Browser mit dazu Tree-Tier.
  • 75. Frontend Backend Datenbank Sonntag, 30. Mai 2010 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.
  • 76. Frontend IPhone-App Backend External Service Datenbank Sonntag, 30. Mai 2010 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.
  • 77. Frontend IPhone-App Backend External Service Indizierer Datenbank SuchIndex Sonntag, 30. Mai 2010 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.
  • 78. ? Frontend IPhone-App Backend External Service Indizierer Datenbank SuchIndex Sonntag, 30. Mai 2010 Aber was sagt uns dieses Diagramm genau?
  • 79. Frontend IPhone-App Backend External Service Indizierer Datenbank SuchIndex Sonntag, 30. Mai 2010 Hardware? Prozesse? Request-Basiert oder Asynchron? Verteilt? Welche Funktion haben die Elemente genau in der Architektur?
  • 80. Frontend IPhone-App Backend External Service Indizierer Datenbank SuchIndex Sonntag, 30. Mai 2010 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.
  • 81. Was macht eine gute Architektur aus? Sonntag, 30. Mai 2010 Frage an die Zuhörer: Was macht eine gute Architektur aus? Welche Kriterien muss eine Architektur erfüllen?
  • 82. Funktionalität Sonntag, 30. Mai 2010 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.
  • 83. ? Sonntag, 30. Mai 2010 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?
  • 85. F U R P ? S Sonntag, 30. Mai 2010 Quizfrage: Was bedeutet FURBS? Englisches Umgangswort für Aufstossen, eine Knuddelalienrasse aus Star Trek 1?
  • 86. F U R P ? S Sonntag, 30. Mai 2010 Quizfrage: Was bedeutet FURBS? Englisches Umgangswort für Aufstossen, eine Knuddelalienrasse aus Star Trek 1?
  • 87. F U R P ? S Sonntag, 30. Mai 2010 Quizfrage: Was bedeutet FURBS? Englisches Umgangswort für Aufstossen, eine Knuddelalienrasse aus Star Trek 1?
  • 88. Functionality Usability Reliability Performance Security Sonntag, 30. Mai 2010 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 sollen Reliability - die Verlässlichkeit der Applikation, Fehlerfreiheit und Verfügbarkeit Performance - Antwortzeit, Durchsatz, Bandbreite und vieles andere Security- Sicherheit in Netzwerk, Daten, Angriffsarten
  • 89. Sonntag, 30. Mai 2010 Aber es geht natürlich noch komplizierter ...
  • 91. ISO 9126 Wer ein fotografisches Gedächtnis hat ist klar im Vorteil. Sonntag, 30. Mai 2010
  • 92. Funktionalität Sonntag, 30. Mai 2010 Analog zu Furbs spielt Funktionalität den erste und wichtigsten Punkt Inwieweit besitzt die Software die geforderten Funktionen? - Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen.
  • 93. Funktionalität: Angemessenheit Sonntag, 30. Mai 2010 Eine Randfunktionalität sollte nicht 80% der Programmierung verursachen.
  • 94. Funktionalität: Richtigkeit Sonntag, 30. Mai 2010 Der Durchschnittsentwickler: Ich glaube gesehen zu haben, dass es bei mir einmal bei einer bestimmten Konstellation ein richtiges Ergebnis geliefert hätte.
  • 95. Funktionalität: Interoperabilität Sonntag, 30. Mai 2010 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.
  • 96. Funktionalität: Sicherheit Sonntag, 30. Mai 2010 Das können wir PHPler inzwischen ganz gut. Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern.
  • 97. Funktionalität: Ordnungsmässigkeit Sonntag, 30. Mai 2010 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.
  • 98. Zuverlässigkeit Sonntag, 30. Mai 2010 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.
  • 99. Zuverlässigkeit: Reife Sonntag, 30. Mai 2010 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.
  • 100. Zuverlässigkeit: Fehlertoleranz Sonntag, 30. Mai 2010 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.
  • 101. Zuverlässigkeit: Robustheit Sonntag, 30. Mai 2010 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.
  • 102. Zuverlässigkeit: Wiederherstellbarkeit Sonntag, 30. Mai 2010 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?
  • 103. Zuverlässigkeit: Konformität Sonntag, 30. Mai 2010 Und hier auch wieder die Duftmarke der ISO-Norm: Werden Standards, auch gerne die eigenen, erfüllt?
  • 104. Benutzbarkeit Sonntag, 30. Mai 2010 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.
  • 105. Benutzbarkeit: Verständlichkeit Sonntag, 30. Mai 2010 Ist Konzept und Anwendung auch für sterbliche verständlich? Oder sind die tieferen Logiken nur dem Developer mit Schwerpunkt auf Prolog zugänglich?
  • 106. Benutzbarkeit: Erlernbarkeit Sonntag, 30. Mai 2010 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?
  • 107. Benutzbarkeit: Bedienbarkeit Sonntag, 30. Mai 2010 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?
  • 108. Benutzbarkeit: Attraktivität Sonntag, 30. Mai 2010 Daaaa kann Apple mitreden. Ist die Oberfläche sexy? Will ich mit der Applikation gesehen werden? Nehme ich sie heimlich mit unter die Bettdecke?
  • 109. Benutzbarkeit: Konformität Sonntag, 30. Mai 2010 Und, die ISO-Duftmarke wieder.
  • 110. Effizienz Sonntag, 30. Mai 2010 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?
  • 111. Effizienz: Zeitverhalten Sonntag, 30. Mai 2010 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“
  • 112. Effizienz: Verbrauchsverhalten Sonntag, 30. Mai 2010 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 ...
  • 113. Effizienz: Verbrauchsverhalten Sonntag, 30. Mai 2010 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 ...
  • 114. Effizienz: Konformität Sonntag, 30. Mai 2010 Tjahaha, und die ISO-Jungs wieder ...
  • 115. Änderbarkeit Sonntag, 30. Mai 2010 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.
  • 116. Änderbarkeit: Analysierbarkeit Sonntag, 30. Mai 2010 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.
  • 117. Änderbarkeit: Modifizierbarkeit Sonntag, 30. Mai 2010 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.
  • 118. Sonntag, 30. Mai 2010 Spaghetti-Code zu fixen ist keine Freude.
  • 119. Änderbarkeit: Stabilität Sonntag, 30. Mai 2010 „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!“
  • 120. Änderbarkeit: Testbarkeit Sonntag, 30. Mai 2010 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.
  • 121. Übertragbarkeit Sonntag, 30. Mai 2010 Für Commodity-software trivial: läuft das überall. Aber auch Inhouse von bedeutung - Änderungen von Plattformen, datenbanken, der Serverstruktur etc.
  • 122. Übertragbarkeit: Anpassbarkeit Sonntag, 30. Mai 2010 Kann ich die Software schnell anpassen. Anders formuliert: habe ich zB eine Datenbankabstraktion?
  • 123. Übertragbarkeit: Installierbarkeit Sonntag, 30. Mai 2010 Wer benutzt hier Capistrano oder irgendein automatisches Deployment? Wer installiert per Hand? Wie lange dauert das?
  • 124. Übertragbarkeit: Koexistenz Sonntag, 30. Mai 2010 Verlange ich spezialitäten von meiner umgebung, die dem rest der welt weh tun? register_globals, anyone?
  • 125. Übertragbarkeit: Austauschbarkeit Sonntag, 30. Mai 2010 Wie gut lässt sich meine Software wegwerfen?
  • 126. Übertragbarkeit: Konformität Sonntag, 30. Mai 2010 Und die ISO-Jungs wieder, war ja klar.
  • 127. O - Kay ... Sonntag, 30. Mai 2010 Müssen wir wirklich alles beachten, wenn wir eine Architektur auswählen?
  • 128. ? Sonntag, 30. Mai 2010 Wer von den hier Anwesenden berücksichtigt jedesmal alle Aspekte?
  • 129. Zu einer anderen Zeit, an einem anderen Ort ... Sonntag, 30. Mai 2010
  • 130. Zu einer anderen Zeit, an einem anderen Ort ... Heute, in der Realität Sonntag, 30. Mai 2010
  • 131. Default-Toolset des Unternehmens Sonntag, 30. Mai 2010
  • 132. Alte Bekannte 1: Dinge, die sich in der Vergangenheit bewährt haben ... Sonntag, 30. Mai 2010
  • 133. Alte Bekannte II: ... und Dinge, die sich in der Vergangenheit nicht bewährt haben. Sonntag, 30. Mai 2010
  • 134. Technik mit Coolness-Faktor Sonntag, 30. Mai 2010 Das „echte“ Architekturvorgehen: Ich habe eine coole Lösung, die ich spannend finde, die jemand verblogt hat.
  • 135. Ich habe eine Lösung, und suche nach einem Passenden Problem Sonntag, 30. Mai 2010 Map-Reduce anyone? NoSQL? Message-Queues?
  • 136. "Nobody ever got fired for choosing Java" Sonntag, 30. Mai 2010
  • 137. ARCHITEKTURNEUROSEN • Innere Plattform • Wheel Factory • Gas Factory • Golden Hammer • ... und vieles mehr ... Sonntag, 30. Mai 2010 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öst Golden Hammer: Ein bevorzugter Lösungsweg wird als universell beste Lösung angesehen.
  • 138. Sonntag, 30. Mai 2010 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 ...
  • 140. Architecture Tradeoff Analysis Method Sonntag, 30. Mai 2010 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.
  • 141. Sonntag, 30. Mai 2010 Das ganze kommt vom Software Engineering Institute, und ist eigentlich für die Bewertung von Architekturen im Vergleich gedacht.
  • 142. Es gibt kein Silver Bullet? Sonntag, 30. Mai 2010
  • 143. ATAM Ermöglicht die Ermittlung präziser Qualitätskriterien Sonntag, 30. Mai 2010
  • 144. ATAM Erzeugt eine frühe Architekturdokumentation. Sonntag, 30. Mai 2010
  • 145. ATAM Erzeugt eine dokumentierte Basis für Architekturentscheidungen Sonntag, 30. Mai 2010
  • 146. ATAM Erkennt Risiken früh im Software LifeCycle Sonntag, 30. Mai 2010
  • 147. ATAM Erzeugt bessere Kommunikation zwischen den Stakeholdern Sonntag, 30. Mai 2010
  • 148. Sonntag, 30. Mai 2010 Wie sieht ATAM genau aus? „Was issene Dampfmaschin? Da stellen wir uns mal ganz dumm ...
  • 149. Business Drivers Sonntag, 30. Mai 2010 Welche Ziele verfolgen wir mit dem Projekt? Was sind unsere Prioriäten dort?
  • 151. TECHNISCHE EINSCHRÄNKUNGEN „Muss auf Windows laufen“ „Datenbank ist Oracle.“ „Unsere Entwickler können nur PHP!“ „Alles auf unserem eigenen Framework!“ Sonntag, 30. Mai 2010
  • 152. ? Sonntag, 30. Mai 2010 Welche technischen Einschränkungen gibt es bei Euch?
  • 153. 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 Sonntag, 30. Mai 2010 Die Werte kommen aus unserer Studie, einfach bei uns im Blog runterladen.
  • 154. Sonntag, 30. Mai 2010 Stakeholder gibts viele, der erste ist aber klar: Das sind natürlich erst mal die Jungs, die unsere Rechnung bezahlen. Aber nicht nur die.
  • 155. Sonntag, 30. Mai 2010 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üssen etc ...
  • 156. QUALITÄTSKRITERIEN Was war FURPS noch mal? Sonntag, 30. Mai 2010
  • 157. Sonntag, 30. Mai 2010 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.
  • 158. Sonntag, 30. Mai 2010 Für jedes Blatt des Utility Trees wird eine Szenario entworfen.
  • 159. SZENARIEN • Repräsentieren die Interessen der Stakeholder • um die Wirkung der Qualitätskriterien zu ermitteln Sonntag, 30. Mai 2010
  • 160. SZENARIEN • stellen wichtige Usecases dar • stellen erwartete Änderungen dar • stellen nicht erwartete Ereignisse da Sonntag, 30. Mai 2010 Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie vorher Nicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.
  • 161. 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. Sonntag, 30. Mai 2010 Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie vorher Nicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.
  • 162. Sonntag, 30. Mai 2010 Diese Szenarien werden mit der Priorität bewertet - H(igh), M(edium), L(ow)
  • 163. Gearman-Message-Queue (Zend, Cake, Symfony)- Framework-basiert REST-Architektur ORM Generiertes JavaScript Magento erweitern JavaScript Toolkit NoSQL Sonntag, 30. Mai 2010 Danach werden mögliche Architekturansätze gesammelt. Die können jeglicher Art sein, und sich natürlich in Teilaspekten des Systems jeweils ergänzen.
  • 164. 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.
  • 165. Sonntag, 30. Mai 2010 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.
  • 166. 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? Sonntag, 30. Mai 2010
  • 167. Sonntag, 30. Mai 2010 Zusammen mit den Stakeholdern werden die Konsequenzen der Architekturwahl besprochen und eine Architekturentscheidung getroffen.
  • 168. Das ganze noch mal im Schnelldurchlauf Sonntag, 30. Mai 2010
  • 169. • Business Treiber definieren • Utility Tree auf Basis von Qualitätskriterien definieren • Szenarien erzeugen und Priorisieren • Architekture gegen Utility Tree Analysieren • Ergebnis präsentieren & Entscheiden Sonntag, 30. Mai 2010
  • 170. Gruppenarbeit! Vorstellen der Ergebnisse: 17:30 Sonntag, 30. Mai 2010
  • 171. • 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:30 Sonntag, 30. Mai 2010
  • 173. 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 Sonntag, 30. Mai 2010