Y-Prinzip
Anna Lambertz, Wolfgang Fahl
Diese Seite in anderen Sprachen: en
| BlogEntry | |
|---|---|
 edit
| |
| date | 2011-10-14 |
| title | Y-Prinzip |
| author | Wolfgang Fahl |
| File:Trennungvon FachlichkeitUndTechnik2011-11-27.pdf | |
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
Beispiel
Y-Prinzip basierte Generierung für Semantic MediaWiki:
Y-Prinzip[edit]
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
Beispiel[edit]
Y-Prinzip basierte Generierung für Semantic MediaWiki:
Technik und Fachaspekte lassen sich trennen: Separate Entwürfe führen zum Ziel - Computerzeitung 46 / 14. November 2005[edit]
Häufig kommt es Anwendern nicht darauf an, mit welchen technischen Mitteln ihre Anforderungen umgesetzt werden. Dies macht sich das Y-Prinzip der Softwaremodellierung zunutze.
Ob PHP oder Java eingesetzt wird, ist dem späteren Nutzer der Anwendung häufig egal. Auf der anderen Seite wandelt sich die technische Seite der Software mit einem anderen Tempo als die inhaltliche Seite. So verwaltet die Universitätsbibliothek der Rheinisch-Westfälischen Technischen Hochschule Aachen bereits seit 33 Jahren Bücher mit dem Computer. Das zugrunde liegende System von Soft- und Hardware hat sich aber seitdem viermal komplett geändert.
Das Y-Prinzip geht daher von zwei getrennten Strängen für die Modellerstellung aus. Die fachlichen Anforderungen fließen in ein fachliches Modell ein. Aus den technischen Anforderungen wächst ein technisches Modell. Beide Modelle werden mit Abbildungsvorschriften gemäß der Model Driven Architecture (MDA) gemischt, und daraus wird fertiger Code erzeugt.
Technische Anforderungen beziehen sich auf Programmiersprache, Betriebssystem, Zielcomputer, Datenhaltung, grafische Oberflächen, Netzwerk, Sicherheit, Lastverteilung und ähnliche Aspekte, die sich ohne Änderung des fachlichen Inhalts der Lösung ändern können. Meistens interessieren sich die Auftraggeber für die technische Seite nur wenig - es ist ihnen aber wichtig, dass die Software mit der vorhandenen Technik zusammenspielt.
Anwendersprache bleibt erhalten
Fachliche Anforderungen beziehen sich auf das, was die Software inhaltlich leisten soll. Diese Anforderungen lassen sich in der Regel frei von technischen Betrachtungen erfassen. Das ist den Betroffenen auch meist lieber, da dann ihre eigene Sprache Verwendung findet.
In Kombination mit dem objektorientierten Ansatz und der UML führt die Anwendung des Y-Prinzips zu sehr verständlichen Softwareentwürfen. Beim Übergang von den Anforderungen zum Modell können die einmal verwendeten Begriffe und Bezeichnungen unverändert weiter verwendet werden. Diese finden sich sogar noch nach der Erzeugung der Software im Code wieder. Ein Begriff wie „Mehrwertsteuersatz" bleibt also von der Anforderung bis in den Quelltext erhalten. Das war nicht immer selbstverständlich.
Technik und Fachaspekte lassen sich trennen: Separate Entwürfe führen zum Ziel - Computerzeitung 46 / 14. November 2005[edit]
Häufig kommt es Anwendern nicht darauf an, mit welchen technischen Mitteln ihre Anforderungen umgesetzt werden. Dies macht sich das Y-Prinzip der Softwaremodellierung zunutze.
Ob PHP oder Java eingesetzt wird, ist dem späteren Nutzer der Anwendung häufig egal. Auf der anderen Seite wandelt sich die technische Seite der Software mit einem anderen Tempo als die inhaltliche Seite. So verwaltet die Universitätsbibliothek der Rheinisch-Westfälischen Technischen Hochschule Aachen bereits seit 33 Jahren Bücher mit dem Computer. Das zugrunde liegende System von Soft- und Hardware hat sich aber seitdem viermal komplett geändert.
Das Y-Prinzip geht daher von zwei getrennten Strängen für die Modellerstellung aus. Die fachlichen Anforderungen fließen in ein fachliches Modell ein. Aus den technischen Anforderungen wächst ein technisches Modell. Beide Modelle werden mit Abbildungsvorschriften gemäß der Model Driven Architecture (MDA) gemischt, und daraus wird fertiger Code erzeugt.
Technische Anforderungen beziehen sich auf Programmiersprache, Betriebssystem, Zielcomputer, Datenhaltung, grafische Oberflächen, Netzwerk, Sicherheit, Lastverteilung und ähnliche Aspekte, die sich ohne Änderung des fachlichen Inhalts der Lösung ändern können. Meistens interessieren sich die Auftraggeber für die technische Seite nur wenig - es ist ihnen aber wichtig, dass die Software mit der vorhandenen Technik zusammenspielt.
Anwendersprache bleibt erhalten
Fachliche Anforderungen beziehen sich auf das, was die Software inhaltlich leisten soll. Diese Anforderungen lassen sich in der Regel frei von technischen Betrachtungen erfassen. Das ist den Betroffenen auch meist lieber, da dann ihre eigene Sprache Verwendung findet.
In Kombination mit dem objektorientierten Ansatz und der UML führt die Anwendung des Y-Prinzips zu sehr verständlichen Softwareentwürfen. Beim Übergang von den Anforderungen zum Modell können die einmal verwendeten Begriffe und Bezeichnungen unverändert weiter verwendet werden. Diese finden sich sogar noch nach der Erzeugung der Software im Code wieder. Ein Begriff wie „Mehrwertsteuersatz" bleibt also von der Anforderung bis in den Quelltext erhalten. Das war nicht immer selbstverständlich.