HowToCode "ReadYou": Was soll das System denn leisten? – Gedanken an die Anforderungen
In dem letzten “ReadYou” Post ging es allgemein um den Gesamtplan – als erstes möchte ich nochmal komplett ohne Code arbeiten und auch keine großen Gedanken zur Architektur machen.
Hier geht es um die Anforderungen die ich an das System habe. Neben den bereits gestellten Qualitätsanspruchen (Source Control, Tests, Dokumentation) sollten auch gewisse Grundfunktionen enthalten sein.
Wichtiger Hinweis: Ich werde die Anforderungen bewusst “simpel” fassen – im professionellen Umfeld sollte an dieser Stelle besonders viel mit dem Kunden geredet werden um herauszufinden, was er eigentlich will!
Was genau muss die Software/Plattform leisten?
Bilder sagen manchmal mehr als tausend Worte (und vor allem empfinde ich es dann meist viel logischer, wie das hinterher aussehen muss):
Aufmerksamen Lesern des Blogs sollte dieses Bild aus dem UI Prototyping mit Powerpoint bekannt vorkommen.
Ich liste jetzt mal alle Funktionen auf:
- User-Bereich:
- Login/Logout/Register/Password-Recovery
- Admin hat Management-Oberfläche
- User kann Profildaten speichern
- User sollte sich auch mit Open ID, Windows Live ID etc. anmelden können
- User kann andere User suchen etc.
- User kann Bücher anlegen (später evtl. auch Blogs)
- “Meine Seite” ähnlich wie StudiVZ Home
- Community – “Gruppen” etc.
- Bücher-Bereich:
- Anlegen / Löschen / Managen
- Bewerten
- Taggen
- Kategorisierung der Bücher
- Amazon-Anbindung
- Rezessionen verfassen (oder man nimmt die Amazon-Rezessionen über die API
) - Allgemeines:
- Aktive User ähnlich wie in den ASP/MSDN Foren
- Neuste Bücher wie bei YouTube “Videos right watched now…”
Um es kurz zu sagen: Typische Communityseite – wobei ich die Anforderungen hier nicht so eng fasse.
Eine interessante Sachen die ich gerne einbauen würde:
- Providermodell für Authentifizierung & Userdaten
Das ASP.NET Membership-System gefällt mir nicht wirklich – es ist nett, hat aber seine Tücken und ist bei manchen Sachen (Profiles z.B.) nicht wirklich schön.
Zudem möchte ich die Authentifzierung von den eigentlichen Nutzerdatenzugriff trennen, weil ich bislang häufig bei Projekten folgendes Szenario hab:
- Oracle-DBs mit wilden Benutzerdaten
- AD / LDAP als Authentifizierung, allerdings stammen die wirklichen Userdaten dann aus einer anderen DB
- Profildaten etc. werden extra gespeichert
Insbesondere durch die Anforderung, die ich mir selbst gestellt habe, als Authentifizerung auch OpenID, Windows Live etc. zu unterstützen, wären die Userdaten und die Userauthentifizierung sowieso getrennt.
“AuthenticationRepository” & “UserRepository”:
Ich bin sehr angetan von Rob Conerys Architektur mit den Pipes & Filters Modell und dem IQueryable Interface.
Als momentane Idee steht daher solch eine “Grobe”-Architektur:
Diese “Architekturgedanken” sind hier für die Erklärung der Anforderung zu verstehen. Code etc. wird es erst später geben
Data:
Hier versteh ich die verschiedenen Datenquellen – z.B. eine Oracle-DB, eine SQL-DB, Windows Live oder OpenID (wenn es um die Authentifizierung geht).
Repository;
Hier ist die Datenzugriffsschicht – als wäre hier angenommen LINQ to SQL/ADO.NET EF/NHibernate/SubSonic oder die Windows Live API etc. einzubauen.
Service:
Der Service sollte so lose wie möglich an das “Backend” gekoppelt sein – ich denke dies hier ist ein nettes Einsatzgebiet von Dependency Injection. Dieser Serivce wird im Frontent aufgerufen und gibt das an die entsprechenden Repositories weiter.
Mein Wunschtraum:
Der Idealzustand dieser Plattform wäre, wenn ich an einer Codestelle oder über Konfiguration mein “Datenquellen” angeben kann, z.B.:
Variante A)
Nimm als Authentifizierungsquelle und Userquelle den SQL Server.
Variante B)
Nimm als Authentifizierungsquelle das Active-Directory und als Userquelle die Oracle DB
Am Ende muss man “nur” einen entsprechenden Provider bereitstellen und ich will Service nichts großes ändern müssen – ob das so klappt, wage ich jetzt mal zu bezweifeln, da die Anmeldedaten auch unterschiedlich sind – aber das wird eine interessante Sache für die nächsten Blogposts
Alles klar?
Kunde: “Falls Sie noch Fragen haben, melden Sie sich einfach. Ich denke, dass ist eine machbare kleine Anwendung – das dauert bestimmt nicht lange.”
Programmierer:
Feedback:
Auch wenn ich einen möglichst “professionellen” Ansatz verfolgen möchte, will ich hier möglichst bald euch Code präsentieren. Die Rubrik heisst ja auch “HowToCode” und nicht “HowToRequirementsManagement”, daher sei mir hoffentlich die spärlichen Anforderungen verziehen
Aber wenn ihr noch Vorschläge habt (was unbedingt mit rein müsste, und was man mit bedenken sollte), dann immer her damit.
Ausblick:
Die Idee mit der Authentifizierung/Userdata-Sache werde ich sicherlich erstmal prototyisch das nächste mal in Angriff nehmen und genauer auf die anderen Architekturpunkte eingehen.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Rainer Schuster
5. June 2008
Hallo Robert,
das hört sich doch sehr interessant an und nach Hand und Fuss. Ich plane nach meinem Urlaub in zwei Woche eine Artikelserie zu starten, bzw. fortzusetzen rund ums Thema Dokumentation. Was hälst du davon wenn ich deine Applikation als Beispiel her nehme und zeige wie dokumentiert wird?
Gruß,
Rainer
Robert Mühsig
6. June 2008
Das ist doch eine klasse Idee – würde mich freuen wenn man da was zusammen machen könnte
Bis dahin wünsch ich dir einen schönen Urlaub
James
6. June 2008
kling ja schon mal sehr nett und mein liebelings-projekt-bild ist auch gleich dabei! Ich glaube es gibt kein bild das einen projektablauf besser beschreibt wie das oben gezeigte!!!
hast du für die plattform auch an eine api vorgesehen oder möchtest du keine zu verfügung stellen?
Freu mich schon auf die ersten code stückchen! leckerlecker!!!
sg
Robert Mühsig
6. June 2008
Da ich eigentlich ein Freund von APIs bin und nicht nur die Daten bunkern will, wäre das durchaus denkbar.
Als Schlagwort fällt mir da WCF + REST ein – wäre sicherlich eine nette Sache die ich dann im nächsten Durchgang mir näher durchdenken werden
Martin
6. June 2008
Bereich Bücher:
- ISBN Codes als eingaben akzeptieren (die evtl. aus einen Barcode Scanner kommen) -> restlichen Daten über AMazon API ziehen
- Verleih Funktion ala “Ich habe Buch Foobar an User Heinz verliehen”, damit man den Überbliock über seine Bücher behält
Christian Pappert
6. June 2008
Das wird ja eine Mischung aus http://www.librarything.de/ und http://www.last.fm/.
Robert Mühsig
6. June 2008
So kann man es sagen, ja.
Um es nochmal klar zu sagen: Dass es solche Onlinedienste gibt, ist mir bekannt – aber das hält ja einen richtigen Programmierer nicht davon ab, selber sowas zu schreiben