Geschäftsmodelle erkennen
8. April 2009 Roland
- Erstellen eines Newssystems
- Akteure im Newssystem
- Newssystem Anwendungsfälle für den Systemadministrator
- Newssystem Anwendungsfälle für den Editor
- Newssystem Anwendungsfälle Zusammenfassung
- Newssystem Anwendungsfälle Webuser
- Anwendungsfall Add Category
- Anwendungsfall Add Editor to Category
- Anwendungsfall Change Editor
- Nebenläufigkeiten beim Editieren von Newseinträgen
- Anwendungsfall Create Editor
- Anwendungsfall Delete Category
- Anwendungsfall Delete Editor
- Anwendungsfall Edit Category
- Anwendungsfall Remove Editor From Category
- Anwendungsfall Show Editors
- Anwendungsfall Show Categories
- Anwendungsfall Add Image to Newsentry
- Anwendungsfall Create Newsentry
- Anwendungsfall Delete Image
- Anwendungsfall Delete Newsentry
- Anwendungsfall Edit Image Data
- Anwendungsfall Edit Newsentry
- Anwendungsfall Navigate in Newslist
- Anwendungsfall Remove Image from Newsentry
- Anwendungsfall Search Image
- Anwendungsfall Search News
- Anwendungsfall Set Presentation Times
- Anwendungsfall Upload Image
- Anwendungsfall Navigate Archive News Shortentries
- Anwendungsfall Navigate Shortentries
- Anwendungsfall Show Archive Newsentry
- Anwendungsfall Show Newsentry
- Anwendungsfall Show Shortentries
- Aufbereiten der bisherigen Anwendungsfälle
- Technische Anwendungsfälle
- Nebenläufigkeiten beim Lesen von Newseinträgen
- Lasst uns mal über Performancemessung reden
- Erste Gedanken zum Backup und Restore für unser Newssystem
- Zwischenschicht zur Performancemessung einbauen
- Performancemessungen ein- und ausschalten
- Performance Messung auf dem Server durchführen
- Newssytem Daten Modellieren
- Anwender Aktionen loggen
- Geschäftsmodelle erkennen
- ImageModel Beschreibung
- Installierbarkeit des Newssystems
- Housekeeping im Newssystem
- Anwendungsfall SearchNotUsedImages
- UserModel Beschreibung
- Meldungsverwaltung und Severity Bestimmung im Newssystem
- UserModelFactory
- Einsatz eines Frameworks für die Erstellung des Newssystems
- Ist das Newssystem einfach nur eine View auf eine Blogsoftware?
- Factory- und Adapter Pattern für die Erweiterung von WordPress
- Wieso will ich das Newssystem nicht als WordPress Plugin erstellen?
- Newssystem gesundschrumpfen
- Wer sind unsere Kunden für das Newssystem?
- Requirements für Newssystem erfassen
- Rahmenbedingungen für das Newssystem
- Entscheidung wie das Newssystem jetzt umgesetzt werden soll
- Welche Tools können wir zur Anforderungsverwaltung einsetzen?
- Verwalten der Anforderungen
- Namensänderungen im Newssystem Modell
- Ein Tool für die Anforderungen
- Komponenten die im ersten Sprint umgesetzt werden sollen
- Auf der Suche nach einem Tool um Anforderungen zu erfassen
- Security fummelt man am Besten gleich in die Architektur hinein
- Security Komponenten Klassendiagramm
- wie schrumpft man das System Gesund?
Wir müssen die Daten für die Newseinträge, den Editor und die Kategorien schlussendlich irgendwie auf dem Server speichern. Damit wir die Datensätze mehr- oder weniger sinnvoll zusammenführen können, müssen wir die bisherigen Beschreibungen analysieren und entsprechend als Strukturen beschreiben.
Diese Strukturierung führt dazu, dass wir die notwendigen Daten in Geschäftsmodelle (Businessmodels) zusammenführen.
Für die Verwaltung der Geschäftsdaten werden wir entsprechende Methoden beschreiben und somit die Daten vor unsinnigen Zugriff schützen.
Und schubs, wir haben ein wohldefiniertes Geschäftsmodell mit allen Abhängigkeiten zu den umliegenen Geschäftsmodellen.
Easy oder?
Wenn du die Anwendungsfälle durchgehst, wirst du feststellen dass bestimmte Komponenten irgendwie zusammengehören.
Bei meinen Businessmodellen schreibe ich in den Namen des jeweiligen Modells und füge als Postfix “Model” hinzu. Dann weiss ich immer, dass es sich bei dieser Klasse um ein Modell handelt.
Ich habe mal einen Versuch gestartet und folgende Datengruppen gefunden:

- CategoryModel
- Beinhaltet alle Daten die zur Beschreibung einer Kategorie und der dazugehörigen Editoren gehört.
- EditorModel
- Speichert alle Elemente, die einen Editor umfassend beschreibt.
- MasterEditorModel
- Hat alle Eigenschaften eines Editor, darf darüber hinaus jedoch noch tollere Sachen mit dem System machen. Die Beschreibung der tolleren Sachen legen wir im MasterEditor ab. Das MasterEditorModel leiten wir vom EditorModel ab.
- SysAdminModel
- Der Systemadministrator hat wiederum andere Eigenschaften als der Editor. Es bietet sich daher an, ihm ein eigenes Modell zu gönnen.
- WebUserModel
- Der Webuser hat zwar keine speziellen Daten, die wir abspeichern müssen, jedoch ergibt es Sinn seine Eigenschaften in einer Modellklasse zu kapseln. Wenn wir für dieses Modell keine Daten abspeichern müssen, macht das im Prinzip ja nichts aus. Hauptsache wir können auf ein wohldefiniertes Modell zugreifen.
- UserModel
- Wir haben einen Editor, einen MasterEditor und einen SysAdmin im System. Von jedem dieser Akteure wollen wir den Vor- und Nachnamen, ein Passwort und einen Loginnamen. Die e-Mailadresse wäre auch noch schick, sonst wird die Kommunikation mit dem Anwender etwas schwierig
Aus diesem Grund habe ich die Eigenschaften, die bei jedem UserModell identisch sind, in eine eigene Klasse verbannt. Dann müssen wir das nur einmal programmieren. - NewsListModel
- Wir werden (hoffentlich) ganz viele News im System haben. Wenn wir beim Suchen immer durch alle Newseinträge einzeln durchscrollen müssen, werden wir vermutlich Performanceprobleme bekommen. Bei diesem Modell stelle ich mir eine Liste vor, in der die jeweiligen NewsModelle verlinkt werden.
- NewsModel
- Hier werden die einzelnen Newseinträge abgelegt und verwaltet. Jede News erhält ein solches Modell.
- ImageModel
- Verwaltet die einzelnen Datensätze eines Bildes. Ein Bild ist ein relativ komplexes Gebilde bei dem der Link zum Bild, der alternative Text und ein Titel abgespeichert werden sollen. Da ist ein Modell sicherlich sinnvoll.
- ImageListModel
- Einzelne Bilder werden in verschiedenen Newseinträgen vorkommen. Irgendwie habe ich das Gefühl, dass es sinnvoll wäre wenn wir uns die Information, wo ein Bild verwendet wird, irgendwie zugreifbar verwalten. Bei Löschen eines Bildes können wir so darauf hinweisen, dass dieses Bild eigentlich noch benötigt wird. Weiterhin können wir Bilder darstellen, die in keinem Newseintrag verwendet werden. (Hups! ein neuer Anwendungsfall
)
Der Beitrag wurde
am Mittwoch, den 8. April 2009 um 13:14 Uhr veröffentlicht
und wurde unter Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=744
Dir gefiel der Artikel? Dann abonniere doch den RSS Feed![]()
Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.








