Nach einem befruchtenden Gespräch mit Herrn Prof. Klingspor am heutigen Nachmittag bin ich nun in einer zentralen Frage weitergkommen, die im wesentlichen die Hauptbremse für weitere Überlegungen zum Zentralen Modul meiner Software darstellte.
Die Frage: wie gestalte ich meine Benutzerverwaltung? Genauer: Wie ist die Abhängigkeit zwischen den betreffenden Klassen?
Das Problem: Das Gesamtsystem unterscheidet zwischen den folgenden Benutzer-Arten: Systembenutzer (der UNIX-Systemaccount), Hosting-Benutzer (ein Systembenutzer mit der Möglichkeit, Seiten zu hosten und weitere e-Mailadressen anzulegen; verwendet von der Webanwendugn und dem System), E-Mail-Account (sowohl für Systembenutzer als auch virtuell; verwendet von der Mailsoftware), Systemadministrator (vermutlich auch ein Systemaccount, aber mit zusätzlichen Administrationsrechten innerhalb von Consolvix), Reseller (Ein Hostungbenutzer mit der Möglichkeit, weitere Webbenutzer zu administrieren).
Die Lösung: Erst hatte ich gedacht, das als Klassendiagramm vielleicht so abzubilden:
Die Vererbung würde dann durch Single Table Inheritance geregelt. Für jede Art der Authentifizierung und Authorisierung würde dann auf die Methoden/Eigenschaften des "User"-Elternobjektes zurückgegriffen werden. Durch Setzen des entsprechenden "type"-Feld in der Datenbanktabelle könnte man dan auch sehr einfach einen Hostingbenutzer zum Reseller machen usw. Nachteil ist allerdings, dass diese eine Benutzertabelle eine große Zahl an NULL-Werten aufweisen würde und Äpfel und Birnen gewissermaßen alle in einen Topf mit "Obst" geworfen würden.
Nach einiger Überlegung, wie die E-Mailaccounts verwaltet werden sollten, kam ich zu der Entscheidung, dass die sauberste Lösung durch möglichst wenig Vererbung und mehr Aggregation/Komposition erreicht wird:
So gibt es nun eine abstrakte "Benutzer"-Elternklasse. Diese ist letztendlich nur für den E-Mailversand interessant, denn sowohl virtuelle E-Mailbenutzer (alle mit der UID/GID 5000) als auch Systembenutzer besitzen ein E-Mailkonto. Auf Datenbankebene wird diese "Klasse" als View implementiert, welche die benötigten Attribute aus der Systemenutzer- und E-Mailkonten-Tabelle zusammenführt. Auf SW-Ebene kann man sagen, dass Sowohl die virtuellen als auch die Systembenutzer eher ein E-Mail-Konto "implementieren" als "sind", insofern macht es Sinn, den EmailUser als Interface oder abstrakte Klasse zu betrachten.
Die Systembenutzertabelle wird sowohl vom PAM-System als auch von Consolvix zur Authentifizierung verwendet.
Da die Zusatzangaben, wie z.B. alles was mit Hosting und Administrationsrechten zu tun hat, nicht wirklich logisch zur Klasse "Benutzer" gehören, werden diese nun aus anderen Tabellen aggregiert. Dass dieses Design wesentlich flexibler ist als eine strikte Klassenhierachie, dürfte dem geschulten Auge sofort klar sein ;-). Ich werde den Sachverhalt in der Diplomarbeit wohl noch weiter ausführen.
