Y-Prinzip
BlogEntry
| BlogEntry | |
|---|---|
 edit
| |
| date | 2011-10-14 |
| title | Y-Prinzip |
| author | Wolfgang Fahl |
| File:Trennungvon FachlichkeitUndTechnik2011-11-27.pdf | |
Freitext
Diese Seite in anderen Sprachen: en
Y-Prinzip
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.
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.
Vollständiger Beitrag: Y-Prinzip