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.
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:
Zuletzt aktualisiert am Freitag, den 23. November 2012 um 11:00 Uhr
UML Tool Migration
Geschrieben von: Wolfgang Fahl
Samstag, den 22. Mai 2010 um 06:22 Uhr
Sie möchten Ihr UML Tool wechseln?
Mit den Konvertierungsmöglichkeiten der beteiligten UML Werkzeuge kommen Sie nicht aus?
Modellelemente werden nicht richtig konvertiert?
Die Grafiken nicht richtig dargestellt?
Sie möchten die Gelegenheit nutzen und mehr tun als nur zu konvertieren?
Beteiligte UML Werkzeuge
Für die unten genannten UML-Werkzeuge haben wir Migrations-Schnittstellen über das Standard XMI hinaus. Für die fett gedruckten Werkzeuge gibt es bereits Referenzprojekte.
Sparx Systems - Enterprise Architect
Rational - Rational Rose
No Magic - Magic Draw
Gentleware - Poseidon
Objectdomain Systems - Object Domain
Argo UML
MID Innovator
Microtool Objectif
... nennen Sie uns Ihr Werkzeug ...
Mehr als nur Migration
Nutzen Sie die Gelegenheit und
verbessern Sie die Qualität Ihrer Modelle
vereinfachen Sie Ihre Modelle
machen Sie Ihre Modelle verständlicher
verbesseren Sie Ihre Softwarearchitektur
ermöglichen Sie den Einsatz von Modell getriebenen Ansätzen oder Domain Specific Languages