Kategorie-Archiv: Allgemein

Hammer und Sichel des Softwarearchitekten: Ende der Werkzeugdebatte!

Werkzeuge werden gerne und oft diskutiert.
Oft bestimmen die Werkzeuge die Methoden und nicht umgekehrt.
Werkzeuge versprechen erhöhte Produktivität bewirken aber zu oft das Gegenteil.
Werkzeuge sind Machtmittel, wenn über Lizenzen oder Know-how der Zugang
versperrt ist.
• Wie sehen heute Werkzeugketten für Softwarearchitekten aus?
• Wie erreichen Sie die Nachvollziehbarkeit der Ergebnisse von den Anforderungen
bis zur fertigen Software?
• Wie treffen Sie die richtige Wahl der Tools?

VHIT – die erste Werkzeugkette!

Solange Programmierer ihre eigenen Anforderungen umsetzen konnten, war VHIT- „Vom Hirn ins Terminal“ die Method der Wahl.
Es gab eine Ein-Hirn-Werkzeugkette.

Zweihirnwerkzeugkette
So bald zwei oder mehr Personen an der Softwareentwicklung beteiligt sind, ist nicht mehr sichergestellt, dass die Anforderungen so wie eigentlich gedacht umgesetzt werden. Es kommt das Dilemma der menschlichen Kommunikation zum Tragen.
„Das hab‘ ich nicht gesagt“ und „Du kannst mich einfach nicht verstehen“ sind nicht umsonst beliebte Buchtitel.
Ab der Zweihirnwerkzeugkette treten alle Probleme auf, die sich aus der Verteilung des Wissens ergeben. Der verbindliche Stand der Software ergibt sich noch immer nur aus dem erstellten Source-code.
Erst beim Wechsel des Programmierers zeigt sich, ob und wie dieser Ansatz langfristig trägt.
Auftragssoftware entsteht noch heute sehr häufig nach dem Zweihirnverfahren.

Lesen Sie mehr in der PDF

Y-Prinzip

yprinzip-neu
Auf den iSAQB Information Days 2011 stand das Y-Prinzip  im Mittelpunkt der Frage, wie Separation of Concerns möglichst einfach und effizient erreicht werden kann. Es geht dabei um die Trennung von Fachlichkeit und Technik. Das Y-Prinzip ist sehr oft, aber nicht immer anwendbar – die Kriterien für die Anwendung des Y-Prinzips müssen bekannt sein und die Softwareprojekt können dann daraufhin geprüft werden, ob ein großes Einsparpotential vorliegt.

Y

Mit diesem Wissen sollten Sie motiviert sein, Ihre eigenen Softwareprojekte darauf hin zu analysieren, wo sie bzgl. der Trennung von Fachlichkeit und Technik stehen und welches Gewicht Sie diesem Thema in Zukunft geben wollen.

Nehmen Sie Kontakt mit uns auf, um zu erfahren, wie mit zunehmender Größe und Komplexität der Vorteil des Trennungsvorgehens außerordentlich steigt. Sehen Sie, wie in konkreten Projektbeispielen die „Reverse-Y“-Analyse zeigt, wo der größte Nutzen liegt.

Reverse-Y bedeutet, das Y-Prinzip von einer bestehenden Implementierung her anzuwenden. Dabei werden wiederkehrende technische Themen wie z.B. Hilfesystem, Fehlerbehandlung, Datenhaltung und Benutzeroberfläche identifiziert und schrittweise von der Fachlichkeit entkoppelt (falls nicht idealerweise die Entkopplung schon gegeben ist und daher nur noch dokumentiert werden muss).

Je getrennter die Verfolgung der Pfade Fachlichkeit und Technik erfolgt desto mehr ist es erforderlich, die Verbindungen zwischen beiden Seiten zu klären und Schnittstellen zu vereinbaren. Dazu ist es hilfreich, wenn die fachliche Seite mit einer “pseudotechnischen Sicht” arbeitet, welche vereinfacht die technischen Annahmen und Schnittstellen darstellt und die technische Seite arbeitet mit einer “pseudofachlichen Sicht”, welche die fachlichen Annahmen und Schnittstellen darstellt. Im Detail brauchen beide Sichten gar nicht vollständig oder korrekt sein. Die pseudofachliche Sicht sollte jedoch die aus technischer Sicht  architekturrelevanten Punkte, wie z.B. das Mengengerüst, die Komplexität bzgl. Datenstrukturen und GUI und ähnliche Punkte wiedergeben. Die pseudotechnische Sicht sollte die aus fachlicher Sicht notwendigen techischen Themen wie z.B. GUI, Datenbank, Netzwerk, Security usw. so wiedergeben, dass die vorgesehenen Schnittstellen einfach und klar sind.

Das Y-Prinzip ist im Jahr 2001 bei BITPlan entstanden und basiert auf der Objects 9000® Idee von Martin Rösch. Dieses Prinzip ist in einer Reihe von Projekten angewendet worden, die plattformübergreifende Lösungen erfordern.

Bei der Entwicklung von Softwarearchitekturen geht es darum, eine geeignete Zerlegung der zu entwickelnden Software zu finden. Die Trennung von Fachlichkeit und Technik ist ein wichtiges Zerlegungsprinzip. Das Kosten- und Nutzenpotential darf nicht außer acht gelassen werden, denn es macht keinen Sinn mit missionarischem Eifer als Prinzipienreiter aufzutreten, wenn eine spezielle Projektsituation nun doch nicht den höchstmöglichen Kosten- Nutzeneffekt bietet. Bei langfristig zu pflegenden Softwaresystemen ist es wichtig die gesamte Laufzeit in die Betracht zu ziehen. In Situationen in denen Produktfamilien entwickelt werden gilt grundsätzlicher, dass ein aspektorientierte Ansatz der sich von der Trennung von Fachlichkeit und Technik leiten lässt sinnvoll ist. Plattformübergreifende Entwicklung lässt sich deutlich leichter realisieren, wenn die technischen Aspekte gekapselt sind. Konsequenterweise sollte schon die Anforderungsaufnahme die technischen Aspekte möglichst getrennt berücksichtigen. Die konzeptionelle Durchgängigkeit von der Anforderungsaufnahme bis zur Implementierung unter Beibehaltung von Trennung von Fachlichkeit und Technik zu erreichen ist in der Praxis nicht einfach. Kompromisse sind kaum vermeidbar. Wichtig dabei ist möglichst den Vorteil der Systematisierung nicht zu verlieren. Denn Systematisierung ist die Voraussetzung von Automatisierung.  Die nötigen Einigungsprozesse für die Systematisierung gehören an den Anfang. Dann erst kann auf dieser Basis automatisiert werden.

Das Y-Prinzip ermöglicht es das Tempo der Änderungen auf der fachlichen und technischen Seite unabhängig voneinander zu bestimmen. Die Originalvortragsfolien aus 2011 finden Sie hier:

TrennungvonFachlichkeitUndTechnik2011-11-27.pdf

 

Vom Sinn und Unsinn der Zertifizierung von Software-Architekten

Objektspektrum Artikel

Im Online-Themenspecial Architekturen 2010 aus OBJEKTspektrum 11/2010 ist der Artikel „Vom Sinn und Unsinn einer Zertifizierung für Softwarearchitekten“ erschienen. Autoren sind Phillip Ghadir, Mahbouba Gharbi und Wolfgang Fahl, Geschäftsführer der BITPLan GmbH.Watch movie online The Transporter Refueled (2015)

Y Cathedral Bazaar and Bridge are competing software engineering metaphors

University of Auckland Computer Science Department Seminar

Wolfgang Fahl

When: Friday 28 November 2008, 12 00 PM
Where: CS Seminar Room279, Building 303

Organisation: BITPlan GmbH
Website: http://www.bitplan.de

Abstract:

During Wolfgang Fahl’s carer as a Software Engineering he was guided by metaphors and guidelines. 1989 at Dräger the guideline was „The software is broken anyways – how can we make sure it doesn’t harm anybody“. Martin Rösch later introduced him to the idea of comparing Software Engineering to the maturing industries of bridge- and tower building and later car manufacturing. In his own software architecture lectures Wolfgang has been looking into the comparison between civil engineering architecture and software architecture. His own favourite metaphors are the bridge, the Y-principle and the comparison to building cathedrals. Ewan Tempero now pointed out that at least the cathedral metaphor has been challenged by the „Bazaar“ idea and the opensource movement for a while. After Wolfgang read the book „The Cathedral & The Bazaar“ by Eric S. Raymond he is now inspired to talk about all these guidelines and metaphors and he hopes for a nice discussion by the SERG members after this.