Das Projekt hat zum Ziel, eine Online-Applikation „APPNAME“ zu erstellen (das PRODUKT), die einen Gärtner bei der Bewirtschaftung seines Gartens unterstützt: (APPNAME muss noch gefunden werden)
Dazu stellt APPNAME Informationen über relevante Dinge und relevante Zusammenhänge bereit.
APPNAME hilft dem Gärtner, die richtige Kombination von Pflanzen in der richtigen Pflanzfolge zu planen und zu überwachen.
APPNAME soll eine Mischkultur und naturnahen Anbau fördern.
APPNAME soll als Online-Lösung zur Verfügung stehen.
Aufbau von APPNAME:
Dieser Abschnitt zeigt auf, aus welchen Komponenten APPNAME besteht, mit dem Ziel einzelne Aufgabenpakete mit entsprechenden Anforderungen an die Qualifikation festzulegen.
Exkurs zu „System-Architektur“
Für die Verwaltung von Informationen bestehen folgende grundsätzlich unterschiedliche technische Lösungen. Ausgehend davon, dass jemand im Besitz von Informationen ist und diese für sich oder dritte festhalten will, unterscheide ich folgende Stufen:
Stufe 1: der Zettelkasten
Die Informationen werden systematisch gesammelt und auf Zetteln, evtl. mit Formularcharakter festgehalten. Die Zettel werden systematisch abgelegt. Im Vordergrund dieser Stufe stehen der INHALT, aber es gibt wenig Ansätze für eine STRUKTUR – im Sinne von Regeln wie die Zettel beschriftet, abgelegt oder durchsucht werden sollen.
Stufe 2: der elektronische Zettelkasten
Anstelle von Zetteln werden die Informationen auf einem Computer abgelegt, allerdings nach einer festen Ordnung. Nun kommt Struktur zu den Daten (=Inhalte der Zettel). Dies kann im einfachsten Fall geschehen, indem die Zettel als einzelne Dok-Files (evtl. mit Formular) in Directories auf dem Computer abgelegt werden (man verwendet also das Bibliotheks-System zur Verwaltung der einzelnen Daten-Einheiten („Zettel“).
Ähnlich (nicht grundsätzlich verschieden) ist die Lösung eine Datenbank zur Verwaltung der „Zettel“ zu benutzen, indem jeder Zettel (also jede Informationseinheit) als eine Tabelle definiert wird. Die Zettel enthalten meist einen Schlüssel, einzelne beschreibende Attribute (z.B. den Namen, den lateinischen Namen…) und sogenannte Beziehungs-Attribute (also in einer Tabelle steht der Name einer anderen Tabelle, z.B. um die Beziehung der Nachbarschaft auszudrücken. Dies bietet neue Möglichkeiten, den Datenbestand zu durchsuchen. Die Umsetzung dieser Lösung ist eine klassische Anwendung von Excel oder Access in der Praxis.
Diese Lösung bietet eine systematische Datensammlung und erlaubt, die Daten mit wenig Aufwand in eine nächste Lösung zu übernehmen.
Stufe 3: Abstraktion mit 3-Level-Architektur
Wir gehen klassisch von einer Architektur mit 3 Ebenen aus.
(1) Die Daten-Ebene
(2) Die Applikations-Ebene
(3) Das Benutzer-Interface
Diese Architektur kann implementiert werden als
Single User Applikation
Multi-User Applikation mit gemeinsamer Datenbasis
AUFGABE: Entscheidung für schrittweise von Single zu Multi-User?
Projekt-Aufbau
Das Projekt und seine Aktivitäten orientieren sich am 3-Ebenen-Modell. An den 3 Ebenen kann parallel gearbeitet werden mit jeweiliger Abstimmung der Inhalte.
Die Daten-Ebene
Zur Daten-Ebene – die Datenstruktur
Die Datenstruktur bildet ab, mit welchen „Dingen“ die Anwendung sich befassen soll: Beispiele
Gärtner: eher Hobby-Gärtner oder so – keine Großgärtnerei.
Pflanzen: die Eigenschaften von Pflanzen und ihre Zugehörigkeit zu Pflanzen-Familien - nicht beliebige Pflanzen, sondern eher Gemüse, Obst, Beeren im weitesten Sinn.
Garten bestehend aus Beeten. NAME verwaltet einen Anbauplan über die Zeit.
Anbauplan: Wann in welchem Beet welche Pflanzen gesät, bearbeitet, geerntet werden.
Nachbartauglich: welche Pflanzen können gut / schlecht / gar nicht zusammen wachsen.
Pflanzenfolge: welche Pflanzen können gut / schlecht / gar nicht vor/nach einer bestimmten anderen Pflanze in einem Beet angebaut werden.
Böden: Arten von Böden, Bodenbeschaffenheit und welche Pflanzen mögen/mögen nicht bestimmte Böden.
Dünger: welche Art von Dünger gibt es, welche Böden sind für welchen Dünger, welche Pflanzen verlangen welchen Dünger.
Beispiel Datenmodell
Die Datenstruktur legt fest, welche Datentypen in eigenen Tabellen erfasst werden, welche Eigenschaften für jeden Datentyp erfasst werden und welche Beziehungen zwischen den Datentypen bestehen:
Beispiel: „Pflanzen“ ist ein Datentyp – „Brokkoli, Kartoffel, Spinat“ sind einzelne Ausprägungen (Instanzen) des Datentyps „Pflanzen“. Es wird also eine Tabelle für alle Ausprägungen eines Typs angelegt. In einem Garten gibt es Beete. Ein Datentyp „Bepflanzung“ könnte beschreiben, welche Pflanzen zu einem bestimmten Zeitpunkt in einem bestimmten Beet gepflanzt werden/sind.
AUFGABE: Welche Datentypen gibt es?
Beispiel: Name, Name-Latein, Bild, Nährwert sind Attribute (Eigenschaften) eines Datentyps.
AUFGABE: Für jeden Datentyp muss festgelegt werden, welche Attribute zu erfassen sind und was diese bedeuten.
Beispiel: Zwischen zwei Pflanzen besteht eine Beziehung „Nachbarschaftstauglich“. Diese ist keine Eigenschaft der beiden Pflanzen, sondern eben die Bezeichnung für eine Verbindung / Beziehung zwischen den beiden Pflanzen. Wir unterscheiden zwischen funktionalen Beziehungen und strukturellen Beziehung (z.B. Pflanzen gehören zu einer Pflanzen-Familie).
AUFGBABE: Die relevanten Beziehungen sind zu definieren.
Ob etwas, das man ausdrücken will als Typ, Attribut oder Beziehung definiert wird, hängt von der Verwendung ab und ist oft nicht einfach zu entscheiden. Es kann also durchaus sein, dass dies im Laufe eines Projektes geändert wird: Nehmen wir das Beispiel „Bepflanzung“ – also welche Pflanze zu einem bestimmten Zeitpunkt in einem bestimmten Beet gepflanzt ist – hat Eigenschaften (z.B. wie viele Pflanzen gepflanzt sind, wann gepflanzt wurde, welcher Teil von welchem Beet in Anspruch genommen ist). „Bepflanzung“ hat also Eigenschaften und Beziehungen zu „Pflanze“, „Beet“…
Zur Daten-Ebene – die Daten-Implementierung
Die Implementierung legt fest, wie die Typen / Attribute und Beziehungen in Tabellen abgebildet werden. Besonders wichtig ist die Abbildung der Beziehungen, weil diese für die Struktur verantwortlich sind.
AUFGABE: Datenbank-Implementierung des Datenmodells. Vorschlag welches DBMS (MySql, MariaDB, SQLServer) einzusetzen sind. (Es wird sicher nicht mehr Access sein).
Dictionary:
AUFGABE: Ein Verzeichnis (Dictionary) mit allen Begriffen und deren Beschreibung aufbauen und pflegen.
Zur Daten-Ebene – der Datenzugriff
Wir gehen davon aus, dass eine relationale DB oder eine NOSql DB eingesetzt wird.
AUFGABE: Design des Interface von der Applikation zum Datenserver
Zur Daten-Ebene – Inhalte
Bis hierher wurde nur über die Struktur gesprochen. Jetzt geht es um die konkreten Inhalte.
AUFGABE: Es ist zu erarbeiten wie die Nutzdaten (Instanzdaten) in die Datenbank kommen sollen. Das beinhaltet den Initial Load, das Update, u.U. die Datenübernahme, die Datensicherung.
Die APPLIKATIONS-Ebene
Die Applikations-Ebene stellt technisch das Bindeglied zwischen Benutzer-Oberfläche und Daten-Ebene her.
Funktional: Welche Prozesse sollen mit welchen Eingaben / Ausgaben unterstützt werden? Genaue Beschreibung der Eingabe und der Ausgabe als Vorgabe für das Datendesign (Abstimmung mit Datenmodell: Die Funktion liefert welche Attribute / Beziehungen gebraucht werden, die Datenebene standardisiert die Bezeichnungen und achtet auf die Einhaltung der Sprach-Regelung).
Technisch: Hier sind Funktionen zu programmieren
Objekt-Dienste:
AUFGABE: Wie sollen die Daten der einzelnen Typen erfasst, geändert, gelöscht, gesucht und angezeigt werden?
Auswertung:
AUFGABE: Welche regelmässigen Auswertungen sind zu erstellen?
Beispiel Jahres / Monats-Zusammenstellungen von Arbeiten (Säen, Pflanzen, Bearbeiten, Ernten), die anfallen.
Planungs-Unterstützung
Beispiel: In einem Beet sind Broccoli und Zucchetti gepflanzt. Was soll als nächstes gepflanzt werden?
Benutzer-Oberfläche:
Wird inhaltlich getrieben von den Anforderungen der Anwendungs-Schicht.
Technische Implementierung:
Native GUI
Browser-basiertes GUI
AUFGABE: Vorbereiten der technischen Lösung
Unterstützung beim Entwurf von applikatorischen Funktionen.
Projekt-Auftrag
Das Projekt hat zum Ziel, eine Online-Applikation „APPNAME“ zu erstellen (das PRODUKT), die einen Gärtner bei der Bewirtschaftung seines Gartens unterstützt: (APPNAME muss noch gefunden werden)
Dazu stellt APPNAME Informationen über relevante Dinge und relevante Zusammenhänge bereit.
APPNAME hilft dem Gärtner, die richtige Kombination von Pflanzen in der richtigen Pflanzfolge zu planen und zu überwachen.
APPNAME soll eine Mischkultur und naturnahen Anbau fördern.
APPNAME soll als Online-Lösung zur Verfügung stehen.
Aufbau von APPNAME:
Dieser Abschnitt zeigt auf, aus welchen Komponenten APPNAME besteht, mit dem Ziel einzelne Aufgabenpakete mit entsprechenden Anforderungen an die Qualifikation festzulegen.
Exkurs zu „System-Architektur“
Für die Verwaltung von Informationen bestehen folgende grundsätzlich unterschiedliche technische Lösungen. Ausgehend davon, dass jemand im Besitz von Informationen ist und diese für sich oder dritte festhalten will, unterscheide ich folgende Stufen:
Stufe 1: der Zettelkasten
Die Informationen werden systematisch gesammelt und auf Zetteln, evtl. mit Formularcharakter festgehalten. Die Zettel werden systematisch abgelegt. Im Vordergrund dieser Stufe stehen der INHALT, aber es gibt wenig Ansätze für eine STRUKTUR – im Sinne von Regeln wie die Zettel beschriftet, abgelegt oder durchsucht werden sollen.
Stufe 2: der elektronische Zettelkasten
Anstelle von Zetteln werden die Informationen auf einem Computer abgelegt, allerdings nach einer festen Ordnung. Nun kommt Struktur zu den Daten (=Inhalte der Zettel). Dies kann im einfachsten Fall geschehen, indem die Zettel als einzelne Dok-Files (evtl. mit Formular) in Directories auf dem Computer abgelegt werden (man verwendet also das Bibliotheks-System zur Verwaltung der einzelnen Daten-Einheiten („Zettel“).
Ähnlich (nicht grundsätzlich verschieden) ist die Lösung eine Datenbank zur Verwaltung der „Zettel“ zu benutzen, indem jeder Zettel (also jede Informationseinheit) als eine Tabelle definiert wird. Die Zettel enthalten meist einen Schlüssel, einzelne beschreibende Attribute (z.B. den Namen, den lateinischen Namen…) und sogenannte Beziehungs-Attribute (also in einer Tabelle steht der Name einer anderen Tabelle, z.B. um die Beziehung der Nachbarschaft auszudrücken. Dies bietet neue Möglichkeiten, den Datenbestand zu durchsuchen. Die Umsetzung dieser Lösung ist eine klassische Anwendung von Excel oder Access in der Praxis.
Diese Lösung bietet eine systematische Datensammlung und erlaubt, die Daten mit wenig Aufwand in eine nächste Lösung zu übernehmen.
Stufe 3: Abstraktion mit 3-Level-Architektur
Wir gehen klassisch von einer Architektur mit 3 Ebenen aus. (1) Die Daten-Ebene (2) Die Applikations-Ebene (3) Das Benutzer-Interface Diese Architektur kann implementiert werden als
Projekt-Aufbau
Das Projekt und seine Aktivitäten orientieren sich am 3-Ebenen-Modell. An den 3 Ebenen kann parallel gearbeitet werden mit jeweiliger Abstimmung der Inhalte.
Die Daten-Ebene
Zur Daten-Ebene – die Datenstruktur
Die Datenstruktur bildet ab, mit welchen „Dingen“ die Anwendung sich befassen soll: Beispiele
Zur Daten-Ebene – die Daten-Implementierung
Die Implementierung legt fest, wie die Typen / Attribute und Beziehungen in Tabellen abgebildet werden. Besonders wichtig ist die Abbildung der Beziehungen, weil diese für die Struktur verantwortlich sind.
AUFGABE: Datenbank-Implementierung des Datenmodells. Vorschlag welches DBMS (MySql, MariaDB, SQLServer) einzusetzen sind. (Es wird sicher nicht mehr Access sein).
Dictionary:
AUFGABE: Ein Verzeichnis (Dictionary) mit allen Begriffen und deren Beschreibung aufbauen und pflegen.
Zur Daten-Ebene – der Datenzugriff
Wir gehen davon aus, dass eine relationale DB oder eine NOSql DB eingesetzt wird. AUFGABE: Design des Interface von der Applikation zum Datenserver
Zur Daten-Ebene – Inhalte
Bis hierher wurde nur über die Struktur gesprochen. Jetzt geht es um die konkreten Inhalte. AUFGABE: Es ist zu erarbeiten wie die Nutzdaten (Instanzdaten) in die Datenbank kommen sollen. Das beinhaltet den Initial Load, das Update, u.U. die Datenübernahme, die Datensicherung.
Die APPLIKATIONS-Ebene
Die Applikations-Ebene stellt technisch das Bindeglied zwischen Benutzer-Oberfläche und Daten-Ebene her.
Funktional: Welche Prozesse sollen mit welchen Eingaben / Ausgaben unterstützt werden? Genaue Beschreibung der Eingabe und der Ausgabe als Vorgabe für das Datendesign (Abstimmung mit Datenmodell: Die Funktion liefert welche Attribute / Beziehungen gebraucht werden, die Datenebene standardisiert die Bezeichnungen und achtet auf die Einhaltung der Sprach-Regelung).
Technisch: Hier sind Funktionen zu programmieren
Objekt-Dienste:
AUFGABE: Wie sollen die Daten der einzelnen Typen erfasst, geändert, gelöscht, gesucht und angezeigt werden?
Auswertung:
AUFGABE: Welche regelmässigen Auswertungen sind zu erstellen? Beispiel Jahres / Monats-Zusammenstellungen von Arbeiten (Säen, Pflanzen, Bearbeiten, Ernten), die anfallen.
Planungs-Unterstützung
Beispiel: In einem Beet sind Broccoli und Zucchetti gepflanzt. Was soll als nächstes gepflanzt werden?
Benutzer-Oberfläche:
Wird inhaltlich getrieben von den Anforderungen der Anwendungs-Schicht. Technische Implementierung: