1996 „entdeckte“ ich eine Softwarearchitektur, die ich Intention Architecture nannte. Damals war es nur eine andere Möglichkeit, Software zu entwickeln, die es überschaubar machte, komplexe Software zu schreiben. Meine Inspiration, Absichtsarchitektur zu entwickeln, war jedoch an die sehr grundlegende Verhaltensnatur des Menschen und an die Natur des menschlichen Geistes gebunden.
Sie sehen, jeder von uns wird motiviert, verschiedene Dinge im täglichen Leben, in unserem sozialen und beruflichen Leben zu tun. Unsere Motive generieren unsere Anforderungen z.B. Mein Motiv kann sein, der beste Frischelieferant zu sein. Dieses einfache Motiv kann für mich mehrere Anforderungen generieren, z. um es den Landwirten zu erleichtern, Artikel zu mir zu bringen, den Bestand zu verwalten, die Präsentation zu verwalten usw. Während diese Anforderungen im wirklichen Leben erfüllt werden, sind wir uns nicht bewusst, wie das Ergebnis einer Anforderung das Ergebnis einer anderen beeinflusst. Aber nichtsdestotrotz ist es immer so
Im Softwarebereich sind die Anforderungen natürlich verworren und eines beeinflusst das andere z.B. Die Art und Weise, wie die Liste der Bauernnamen in der Unternehmensverwaltung angezeigt wird, beeinflusst, wie ich den Lieferanten eines bestimmten Lebensmittels usw. finde. Benutzerfreundlichkeit usw. Jede dieser Ausgaben wird sich um einige unterschiedliche Ressourcen/Datenelemente wie „Liste der Bauernnamen“, „Liste der Lebensmittel für jeden Bauern“ drehen. Speichergröße’ usw.
Die Absichtsarchitektur würde es ermöglichen, sich Architekturmodellbauer mit jedem der Probleme in Bezug auf die ursprüngliche Anforderung zu befassen, z. Die Anforderung, „die Namensliste der Landwirte anzuzeigen“, ist langsam, was es ermöglichen würde, die eigentliche Anweisung zu lokalisieren, die die Anforderung generiert, beispielsweise die Speicherzuweisung. Ohne Absichtsarchitektur werden solche Erkenntnisse Teil des Debuggens des Programmcodes sein – was Absichtsarchitektur ermöglicht, ist jede Anforderung in eine einzelne Sequenz kleiner Codeabschnitte in Bezug auf Anwendungsfälle für die Software zu zerlegen. Auf diese Weise können zwei unterschiedliche Anforderungen zwei unterschiedliche Reihen von Chunks haben – wobei einige Chunks gemeinsam sein können. Auch der Entwickler kann zum Zeitpunkt der Entwicklung tatsächlich auf die Anforderung als Bezugspunkt verweisen. Die Möglichkeit, innerhalb des Codes auf die Anforderung zu verweisen, geht auch mit Ereignissen wie dem Klicken auf die Schaltfläche einher – sodass sogar die Benutzeraktionen an die Anforderung gebunden sind. Ich verstehe sehr gut, warum dieses einfache Konzept in der Softwareindustrie nicht weithin akzeptiert wurde.
Ein wichtiger Antrieb in Richtung Absichtsarchitektur ist der Begriff, der in der Software nicht neu ist und als “Separation of Concern” bezeichnet wird, zusammen mit der Wiederverwendung von Anwendungsfalldialogen. Intention Architecture hat jedoch eine Reihe von Konzepten und Werten preisgegeben, die im weiteren Kontext der Realität gültig sind. Ich liste diese Merkmale der Absichtsarchitektur unten auf und Sie können beurteilen, ob die Konstrukte Ihnen einen neuen Blick auf die Realität eröffnen.