<\/p>\n
Erfahren Sie, was Software-Architektur ist und wie Sie es für Ihre Zwecke einsetzen können.<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
Wer hin und wieder eine Access-Anwendung für den Eigengebrauch aus dem Handgelenk schüttelt, ohne sich vorher Gedanken um ihre Aufbau zu machen, erleidet dadurch sicher keinen Schiffbruch. Wenn Sie aber größere Projekte angehen und dies vielleicht auch noch im Kundenauftrag, erleichtert eine vernünftige Planung Ihnen und dem Kunden das Leben.<\/b><\/p>\n
Helmut Balzert definiert Software-Architektur in seinem „Lehrbuch der Software-Technik“ (ISBN 3-8274-0301-4) folgendermaßen:<\/p>\n
„Eine Software-Architektur ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Komponenten.“<\/p>\n
Diese Definition ist nicht die einzige. Allerdings gibt es nicht „die“ Definition der Software-Architektur. Sie bietet allerdings einen guten Einstieg: Software-Architektur beschreibt die Komponenten der Software und ihre Anordnung, wozu auch die Beschreibung der Beziehung der einzelnen Komponenten gehört. Daraus ergibt sich zwangsläufig die Frage, was man unter einer Komponente versteht – und ab hier ist Software-Architektur Auslegungssache … Der Hintergrund ist, dass man mit der Beantwortung der Frage nach dem Aussehen einer Komponente festlegt, wie hoch der Detaillierungsgrad bei der Beschreibung der Architektur einer Software ist. Geläufig sind wohl grobe Beschreibungen wie „Client-Server-Architektur“ oder „Three-Tier-Architektur“ – etwas feiner darf es dann aber doch sein.<\/p>\n
Bevor Sie im nächsten Kapitel ein Beispiel für die Entwicklung einer Architektur für eine Software kennen lernen, sollen Sie etwas mehr über den Sinn einer solchen Architektur erfahren.<\/p>\n
Die Erstellung einer Architektur einer Software ist immer mit dem Verfassen einer schriftlichen oder grafischen Dokumentation verknüpft. Das bedeutet, dass die Zusammenhänge entweder in Form von UML- oder UML-ähnlichen Diagrammen, als Text oder als Kombination von beiden festgehalten werden. Daraus ergeben sich folgende Vorteile:<\/p>\n
Um von den Vorteilen profitieren zu können, muss die Dokumentation der Architektur nach der Erstellung gepflegt und eventuellen änderungen angepasst werden.<\/p>\n
Außerdem sollte die für die Dokumentation gewählte „Sprache“ möglichst standardisiert sein – UML ist derzeit die beste Wahl für diesen Zweck.<\/p>\n
Access-Anwendungen entstehen meist durch die Arbeit von Ein-Mann-Entwicklerteams. Dennoch ist als Vorteil der Vorab-Festlegung der Software-Architektur anzuführen, dass durch die feste Definition einzelner Komponenten eines Systems und ihrer Schnittstellen eine wesentlich höhere Flexibilität bei der Entwicklung der Software entsteht.<\/p>\n
Vermutlich haben Sie auch schon einmal das Problem gehabt, dass Sie bei der Entwicklung an einer Stelle hängen bleiben und ohne die Lösung des aktuellen Problems auch nicht an einer anderen Stelle weitermachen können.<\/p>\n
Das ist ein Indiz dafür, dass die Software ein wenig modularer aufgebaut werden sollte.<\/p>\n
Es ist klar, dass bei einer Access-Anwendung mit wenigen Formularen, die sämtliche Geschäftslogik enthalten und auch noch direkt an die zugrunde liegenden Tabellen – also die Datenschicht – gebunden sind, ein einziges Problem zum Stillstand des Entwicklungsprozesses führen kann – vor allem, wenn die Formulare auch noch stark voneinander abhängig sind.<\/p>\n
Diese „Formular-Monolithen“ lassen sich allerdings leicht entwirren – das muss noch nicht einmal in einem so radikalen Schritt wie der Verwendung einer mehrschichtigen Architektur erfolgen. Wenn man aber wiederverwendbare Funktionalität in eigene Module (vielleicht sogar in ein Klassenmodul mit zusammenhängenden Methoden und Eigenschaften) auslagert und dafür sorgt, dass zwischen Formularen, die einander aufrufen, möglichst wenig Abhängigkeiten bestehen, erreicht man schon eine ganze Menge mehr Flexibilität.<\/p>\n
Dies bezieht sich auch auf „überladene“ Formulare – Sie müssen ja nicht das komplette Datenmodell in einem Formular abbilden. Wenn Sie etwa Kunden und Projekte verwalten möchten, müssen nicht die kompletten Kundendaten im Projekte-Formular enthalten sein – hier tut es durchaus ein Kunden-Detailformular, das sich vom Projekt-Formular aus per Mausklick öffnen lässt. Nebenher erhalten Sie direkt ein separates Kunden-Formular zur Verwaltung der Kunden.<\/p>\n
Wenn Sie den Funktionsumfang beziehungsweise bei Formularen die anzuzeigenden Daten auf ein Mindestmaß reduzieren, können Sie nur gewinnen – viele kleine und überschaubare Komponenten sind allemal besser zu handhaben als große Komponenten, die viele Aufgaben gleichzeitig erledigen. Auf diese Weise können Sie sich beim Auftreten eines Problems locker einer anderen Komponente zuwenden, die sich leichter abarbeiten lässt – und das oben erwähnte, hartnäckige Problem am nächsten Tag in neuer Frische angehen.<\/p>\n
Wenn Sie im Team tätig sind, ist der Aufbau einer Architektur mit mehreren Komponenten und sauberen Schnittstellen quasi Voraussetzung für effektives Arbeiten – auf diese Weise können sich mehrere Mitarbeiter gleichzeitig auf verschiedene Stellen der Software konzentrieren und anschließend die Ergebnisse ihrer Arbeit zusammenfügen.<\/p>\n
Durch die Unterteilung der Software in Komponenten wandelt man größere Elemente in kleine, leicht verdauliche Häppchen um. Die Wahrscheinlichkeit, dass Sie ein solches Häppchen an irgendeiner Stelle wieder verwenden können, ist natürlich wesentlich höher als für größere Brocken. Unter Umständen setzen Sie gar mehrere zusammenhängende Komponenten in weiteren Anwendungen ein – so lässt sich hier und da sicher einiges an Entwicklungszeit gewinnen.<\/p>\n
Noch wichtiger sind die Auswirkungen auf das aktuelle Projekt: Es gibt immer Funktionen, die in mehreren Modulen verwendet werden. Wenn Sie dies frühzeitig erkennen, können Sie ganze Funktionsblöcke in eigene Komponenten auslagern und parametrisieren und brauchen diese nur einmal zu erstellen.<\/p>\n
Je länger die Fertigstellung eines Projekts zurückliegt, desto größer ist der Zeitaufwand zum Finden und Beheben von Fehlern oder für die Erweiterung der Funktionalität der Software.<\/p>\n
Eine ausreichende Kommentierung des Quellcodes mag noch ein wenig Zeit herausschlagen, aber eine Aufteilung der Funktionalität in sinnvolle Blöcke und eine Dokumentation der Architektur gewährleistet eine wesentlich schnellere Identifizierung der fehlerhaften Stelle und deren Beseitigung.<\/p>\n
Auch an eine für die meisten Entwickler unbeliebtere Aufgabe, nämlich das Beheben von Fehlern oder das Weiterentwickeln von Software, die man nicht selbst „verbrochen“ hat, kann man etwas lockerer herangehen, wenn die Software in sinnvolle Komponenten mit wohl definierten Schnittstellen unterteilt ist. Je kleiner die Häppchen, desto geringer werden die Auswirkungen des individuellen Stils eines Entwicklers.<\/p>\n
Viele Softwareprojekte scheitern daran, dass die Zeit- und Kostenplanung nicht stimmt. Durch die Aufteilung der Software in kleinere Elemente bereits bei der Planung lässt sich leichter ermitteln, wie viel Zeit und damit Geld die Entwicklung einer Anwendung beanspruchen wird. Wenn Sie ein Projekt A abgewickelt haben, werden Sie nur schwer davon ableiten können, wie lange Sie für Projekt B benötigen werden. Wenn Sie aber den Aufwand für die in Projekt A verwendeten Komponenten kennen, lässt sich bei vorhandener Architektur von Projekt B schon eine wesentlich bessere Schätzung des Aufwands vornehmen.<\/p>\n
Mit den ganzen Vorteilen der Software-Architektur im Kopf werden Sie nun vermutlich wissen wollen, wie eine solche Architektur in der Praxis aussieht.<\/p>\n
Die Entstehung der Architektur und das fertige Aussehen werden im Folgenden am Beispiel einer Anwendung beschrieben, die Sie ebenfalls in dieser Ausgabe von Access im Unternehmen als Musterlösung finden. Mit der Programmierung und weiteren Details dieser Lösung beschäftigt sich der Beitrag namens Projektzeitmanager.<\/p>\n
Der Projektzeitmanager dient dem Aufzeichnen von Zeiten, die Mitarbeiter mit Projekten verbringen, und ihrer Auswertung. Im Vordergrund steht jedoch die Möglichkeit für die Mitarbeiter, dem System möglichst einfach mitzuteilen, womit sie gerade beschäftigt sind.<\/p>\n
Dabei lassen sich natürlich nicht alle Zeiten Projekten zuordnen, da zwischendurch noch allgemeine Tätigkeiten wie Besprechungen, Wartungsarbeiten am eigenen Rechner, Pausen und sonstige Nicht-Projektzeiten anfallen.<\/p>\n
<\/p>\n
Zur Erfassung der Zeiten soll der Mitarbeiter dem System jeweils beim Tätigkeitswechsel mitteilen, welche Tätigkeiten er in Zusammenhang mit dem vorherigen Projekt ausgeführt hat und angeben, welchem Projekt er sich im Anschluss an diese Tätigkeit zuwendet.<\/p>\n
Der tiefere Sinn dieser Anwendung ist natürlich die Auswertung der einzelnen Zeiten, die die Mitarbeiter insgesamt für die unterschiedlichen Projekte benötigt haben. Die Werkzeuge zur Auswertung sollen nur Mitarbeiter mit den entsprechenden Berechtigungen benutzen können.<\/p>\n
Wenn ein Selbstständiger die Anwendung benutzt, können Frontend und Backend auf dem lokalen Rechner liegen, sobald aber mehrere Mitarbeiter Daten eingeben sollen, ist ein gemeinsames Backend zum Speichern der Daten mit je einem Frontend pro Mitarbeiter gefragt.<\/p>\n
Zusätzlich benötigen Sie noch ein weiteres Frontend mit den Funktionen zur Auswertung der Projektzeiten.<\/p>\n
Die Backend-Seite des Projektzeitmanagers enthält die Tabellen mit den Projekten, den Mitarbeitern, den Projektzeiten und weiteren Informationen (für weitere Informationen siehe Beitrag Projektzeitmanager an anderer Stelle in dieser Ausgabe).<\/p>\n
Das zweite Frontend der Anwendung dient dem Verwalten der Projekte, Mitarbeiter und Projektzeiten. Es soll im weiteren Verlauf allerdings nicht weiter beschrieben werden.<\/p>\n
Das Mitarbeiterfrontend soll möglichst schlank sein und einfache Tätigkeiten für verschiedene Projekte und die entsprechenden Zeiten und Beschreibungen erlauben. Eine genaue Darstellung der Zusammenhänge folgt weiter unten in Kapitel 6.<\/p>\n
Damit sind die Informationen für den ersten Grobentwurf bereits zusammengestellt. Bild 1 zeigt, wie die Anwendung derzeit aufgebaut ist. Die Daten liegen in dem Backend, auf das alle Benutzer mit dem entsprechenden Frontend zugreifen können – die Mitarbeiter mit dem Mitarbeiter-Frontend und der Administrator mit dem Administrationsfrontend.<\/p>\n
![](\"..\/fileadmin\/_temp_\/{7DD77ADF-9961-4A03-82A7-4094AEAF3533}\/pic001.png\")
<\/p>\n
<\/b><\/p>\n
Bild 1: Grobarchitektur der Anwendung<\/span><\/b><\/p>\n Die Einzelplatzvariante für den Selbstständigen, der seine Projekte komplett selbst verwaltet, könnte alle Komponenten in einer Datenbank enthalten – hier sieht die grobe Architektur noch wesentlich einfacher aus.<\/p>\n Nachdem der grobe Aufbau geklärt ist, sollten Sie sich Gedanken um die zu verwendenden Programmiersprachen beziehungsweise Anwendungen machen: Welches Datenbankbackend kommt zum Einsatz und welche Software oder Programmiersprache wird bei der Erstellung des\/der Frontends eingesetzt<\/p>\n In allen Fällen kommen sowohl finanzielle als auch technische Aspekte zum Tragen. Im vorliegenden Beispiel gibt es wohl keine großartigen Anforderungen an die Performance – die Mitarbeiter werden wohl kaum öfter als alle halbe Stunde das Projekt wechseln. Eine Access-Datenbank sollte als Backend also durchaus ausreichend sein. Wenn natürlich ein SQL Server vorhanden ist, kann man die Datenbank auch dort mit unterbringen. Die Anschaffung lohnt sich für diese Anwendung allerdings nicht.<\/p>\n Bei den Frontends muss man differenzieren: Das Frontend für den Administrator (oder auch zwei oder drei) wird vermutlich wesentlich aufwändiger sein als das Benutzerfrontend. Vermutlich werden immer neue Abfragen und Berichte damit erstellt werden, sodass Access eine gute Lösung zu sein scheint – Abfragen und Berichte lassen sich auch von Nicht-Entwicklern im gewissen Rahmen leicht erstellen.<\/p>\n Beim Benutzerfrontend kommt es wiederum auf die Anzahl der Benutzer und die vorhandene Software an. Ist Access ohnehin auf jedem Rechner installiert, kann es leicht verwendet werden, falls nicht, kommt eine Access-Runtime in Frage.<\/p>\n Ist beides nicht vorhanden, könnte man dieses Frontend gegebenenfalls auch mit einer .NET-Programmiersprache erstellen – der Vorteil wäre, dass auf den Zielrechnern lediglich das .NET-Framework installiert sein muss, was kostenlos ist.<\/p>\n Eine andere Alternative ist ein Webfrontend – dieses könnte je nach verwendetem Server in ASP oder ASP.NET oder auch in PHP oder Java programmiert werden.<\/p>\n Da die Beispielanwendung für den Benutzer immer leicht erreichbar sein sollte, sind alle browserbasierten Lösungen eher ungünstig – einen Browser schließt man schnell und dann gilt: Aus den Augen, aus dem Sinn.<\/p>\n Optimal wäre eine Variante, die immer per Mausklick verfügbar ist – etwa eine Anwendung, die man schnell im Systray verschwinden lassen kann, wenn man sie gerade nicht benötigt. Von dort lässt diese sich leicht wieder aufrufen. Auf diese Weise bleibt die Anwendung aktiv und kann beispielsweise alle halbe Stunde das Symbol im Systray aufblinken lassen, um den Benutzer auf sich aufmerksam zu machen.<\/p>\n Ein wichtiger Bestandteil der Architektur ist das Datenmodell. Ist dieses nicht vernünftig aufgebaut, droht langfristiges Ungemach: Abfragen, Formulare, Berichte und auch die Routinen in VBA-Modulen greifen auf die Daten zu und müssen bei änderungen im Datenmodell gegebenenfalls auch angepasst werden.<\/p>\n Das Datenmodell sollte daher unbedingt vor der Erstellung einer Anwendung notiert und auch mit dem Auftraggeber analysiert werden – in vielen Fällen resultieren falsche Datenmodelle aus Missverständnissen bei der Aufnahme der Anforderungen.<\/p>\n Wenn die grobe Struktur und das Datenmodell einer Anwendung stehen, beginnt man üblicherweise mit der Erstellung der Benutzeroberfläche. Diese besteht im Wesentlichen aus den Formularen – zwar gibt es auch noch Berichte für die Ausgabe von Daten und Menüs, um die verschiedenen Funktionen aufzurufen, den Großteil der Zeit dürfte der Benutzer allerdings mit den Formularen verbringen.<\/p>\n Viele Datenbanken werden so entwickelt, dass Entwickler und Auftraggeber abstimmen, welche Daten in der Datenbank verwaltet werden sollen und wie die Benutzeroberfläche dafür gestaltet sein muss. Die Datenbank wird dann entwickelt und in Betrieb genommen und landet kurze Zeit später im Papierkorb.<\/p>\n Der Grund ist, dass die späteren Benutzer der Anwendung nicht in die Planung eingebunden wurden. Was das mit der Architektur der Anwendung zu tun hat Ganz einfach: Sie sollte neben den Entscheidungen über den Entwurf der Datenbank auch Informationen über die Gründe für die jeweilige Gestaltung enthalten – und hier kommen die zukünftigen Benutzer ins Spiel.<\/p>\n Meist ist es so, dass der Wunsch nach der Entwicklung einer Anwendung nicht aus heiterem Himmel kommt – ganz im Gegenteil: <\/p>\n Meist gibt es schon eine Anwendung, die entweder veraltet ist, ein Produkt eines ehemaligen Mitarbeiters, der nicht mehr greifbar ist, oder auch eine provisorische Verarbeitung von Daten, die so nicht mehr funktioniert.<\/p>\n Das bedeutet, dass bereits Erfahrungen im Umgang mit den zu verwaltenden Daten vorliegen, und die sollte man zugunsten einer hohen Akzeptanz der Anwendung stark in die Planung einbeziehen. Die bestehenden Erfahrungen auf der einen und die technischen Kenntnisse des Architekten oder Entwicklers sollten zusammengefasst ein sinnvolles Ergebnis bringen, das sowohl die Anwenderwünsche als auch den aktuellen Stand der Technik berücksichtigt.<\/p>\n Für die Architektur bedeutet dies, dass man auf die Erfahrungen der Mitarbeiter zurückgreift und die bisherigen Abläufe erfasst, analysiert, optimiert und die resultierenden Vorgänge in entsprechender Form aufzeichnet – etwa unter Verwendung der UML. Die UML bietet einige für solche Anforderungen geeignete Diagrammtypen. In Anwendungsfalldiagrammen (auch Use Case-Diagrammen) fasst man die Anwendungsfälle und die beteiligten Mitarbeiter zusammen und erhält so einen groben überblick über die anstehenden Aufgaben.<\/p>\n Was in einzelnen Anwendungsfällen geschieht, legt man mit einem weiteren Diagrammtyp fest: einem Aktivitätsdiagramm. Dieser Diagrammtyp dient der Beschreibung von Geschäftsprozessen und Workflows. Damit können Sie sehr genau festlegen, welche Wege ein Mitarbeiter gehen muss, um unter Zuhilfenahme der geplanten Anwendung ein bestimmtes Ziel zu erreichen.<\/p>\n Für die zeitlichen Abläufe hingegen verwenden Sie Sequenzdiagramme.<\/p>\n Wenn Sie die Anforderungen der Mitarbeiter aufgenommen haben, müssen Sie diese in einen konkreten Plan umsetzen.<\/p>\n Welche Daten müssen überhaupt bearbeitet werden Wie teile ich diese auf Formulare auf, um den aus bestehenden Workflows und Verbesserungswünschen resultierenden Anforderungen gerecht zu werden Wann wird welches Formular geöffnet und wie arbeiten die Formulare zusammen<\/p>\n Die Antworten auf diese Fragen ergeben sich meist aus dem Datenmodell und den Anforderungen der Mitarbeiter an die Anwendung. Letztere liefern dabei allerdings wesentlich mehr Informationen für die Umsetzung. Angenommen die Mitarbeiter haben die Tätigkeiten inklusive Beschreibung und Zeiten in einer Excel-Tabelle gepflegt. Der übliche Vorgang dürfte dabei folgendermaßen ausgesehen haben: Wenn ein Mitarbeiter eine Tätigkeit für ein Projekt beginnt, trägt er eine neue Zeile in ein Excel-Sheet ein, die Informationen über das zu bearbeitende Projekt, den Mitarbeiternamen sowie die Startzeit mit Datum und Uhrzeit enthält. Das ist allerdings auch nur der Fall, wenn er beim Start der neuen Tätigkeit daran denkt, diesen Eintrag vorzunehmen.<\/p>\n Wenn er die Tätigkeit beendet hat, trägt er genauere Informationen über die Tätigkeit ein – etwa die Art der Tätigkeit und eine stichwortartige Beschreibung oder andere wichtige Informationen und natürlich die Uhrzeit. Möglicherweise wurden auch gar nicht die Start- und die Endzeit eingetragen, sondern nur das Datum und eine ungefähre Angabe der benötigte Zeit – etwa „22.8.2005 0,5h“. In dem Fall hat der Mitarbeiter zu Beginn der Tätigkeit gar keinen Eintrag vorgenommen, sondern einfach am Ende des Tages in die Excel-Tabelle geschrieben, was ihm an Tätigkeiten noch so eingefallen ist.<\/p>\n Leicht zu erkennen, dass hier eine Menge Optimierungspotenzial steckt: Das reicht von der schnelleren Eingabe über genauere Daten bis hin zur einfacheren Auswertung der erfassten Daten, denn die liegen bei direkter Anbindung an eine Datenbankanwendung nun einmal direkt in einer Tabelle vor und nicht in je einem Excel-Sheet pro Mitarbeiter.<\/p>\n Die Eingabe von Projektzeiten soll möglichst einfach erfolgen. Um dies zu realisieren, werden folgende Punkte berücksichtigt:<\/p>\n Für eine konsistente Auswertung sollte der Mitarbeiter sich jederzeit mit irgendeinem Projekt beschäftigen – außer natürlich, er macht Pause oder hat Feierabend. Während normalerweise eine Tätigkeit beendet wird, wenn eine andere Tätigkeit für ein weiteres Projekt aufgenommen wird, ist also noch eine Alternative für das Beenden von Tätigkeiten ohne direkt darauf folgende Tätigkeiten vorzusehen.<\/p>\n Dies erfolgt am besten in Form einer Schaltfläche, die eine Beschriftung wie „Keine aktuelle Tätigkeit“ enthält und die Tätigkeit abschließt, ohne eine neue Tätigkeit aufzurufen.<\/p>\n Der für den Mitarbeiter sichtbare Teil der Benutzeroberfläche könnte beispielsweise wie in Bild 2 aussehen.<\/p>\n <\/b><\/p>\n Bild 2: Mögliches Aussehen des Benutzerfrontends des Projektzeitmanagers<\/span><\/b><\/p>\n Nicht jeder Mitarbeiter arbeitet an allen vorhandenen Projekten mit. Dementsprechend sollen die Mitarbeiter in ihrem Frontend auch nur die Projekte angezeigt bekommen, an denen sie beteiligt sind. Diese Grobkonfiguration des Frontends der Mitarbeiter wird ebenfalls im Administrationsfrontend vorgenommen.<\/p>\n Da aber jede Tätigkeit eines Mitarbeiters erfasst werden soll, wird jeder Mitarbeiter eine beträchtliche Anzahl Projekte bearbeiten – auch wenn nur wenige davon Projekte im eigentlichen Sinne sind. Deshalb soll jeder Mitarbeiter die Möglichkeit bekommen, selbst die Projekte auszuwählen, die im Projektzeitmanager angezeigt werden, und ihre Reihenfolge festzulegen. Die dazu benötigte Funktionalität soll nicht im Formular aus Bild 2, sondern in einem neuen Formular untergebracht werden (siehe Bild 3).<\/p>\n <\/b><\/p>\n Bild 3: Verwalten der Anzeige der Projekte und ihre Reihenfolge<\/span><\/b><\/p>\n Neben dieser Schaltfläche darf auch eine Möglichkeit zum Verbergen dieses Formulars nicht fehlen – dazu dient die Schaltfläche Ausblenden, die dafür sorgt, dass nur noch das Symbol im Systray übrig bleibt.<\/p>\n Fehlt noch das Wichtigste: Die Möglichkeit zum Eintragen der Details einer Tätigkeit. Dies erfolgt typischerweise nach dem Beenden der Tätigkeit – was entweder durch den Beginn einer neuen Tätigkeit oder durch den Beginn einer tatenlosen Phase markiert wird.<\/p>\n Für beides soll lediglich ein Klick und minimaler Aufwand zum Eintragen der benötigten Informationen notwendig sein. Dazu soll beim Klick auf ein neues Projekt oder auf die Schaltfläche mit dem Text „Keine aktuelle Tätigkeit“ (siehe Bild 2) ein Formular zur Eingabe der Daten angezeigt werden. Dieses könnte wie in Bild 4 aussehen: Es enthält automatisch ermittelte Informationen wie das aktuelle Projekt, den Namen des Mitarbeiters sowie die Startzeit und die Endzeit. Einzutragen ist lediglich die Tätigkeitsbeschreibung. Selbst die Art der Tätigkeit kann leicht per Kombinationsfeld ausgewählt werden.<\/p>\n Mit einem Klick auf die OK-Schaltfläche werden die Informationen anschließend gespeichert.<\/p>\n <\/b><\/p>\n Bild 4: Eintragen einer neuen Tätigkeit<\/span><\/b><\/p>\n Je nachdem, ob der Benutzer durch die Auswahl eines anderen Projekts eine neue Tätigkeit eingeläutet hat, muss natürlich noch die Startzeit dieser Tätigkeit festgehalten werden, was ebenfalls ohne Zutun des Mitarbeiters geschehen soll.<\/p>\n Nachdem die Komponenten der Benutzeroberfläche festgelegt sind, fehlt noch die dahinter stehende Technik. Auch hier gibt es mindestens zwei Abstufungen für den Detailgrad der Beschreibung. Die erste, gröbere Stufe legt fest, wie und auf welche Komponenten die Funktionalität aufgeteilt wird. Die Möglichkeiten sind relativ umfangreich. Ein Beispiel ist die Entscheidung, ob Validierungen auf Tabellenebene, in Formularen beziehungsweise den entsprechenden Ereignisprozeduren oder gar in einer separat zu schaffenden Businesslogik-Schicht durchzuführen sind. Außerdem können Sie festlegen, ob und wie Funktionalität in Form von Routinen in separaten Standard- oder Klassenmodulen ausgegliedert werden kann, um die Wiederverwendbarkeit zu erhöhen.<\/p>\n Die feinere Abstufung bei der Technik liegt in der Beschreibung der Routinen selbst – ob man dies allerdings vorher im Detail etwa in Form von Diagrammen festhalten muss, ist eine andere Frage.<\/p>\n Software-Architektur sollte auch für Access-Entwickler kein Fremdwort sein. Jedes im Vorhinein durchdachte Detail einer Anwendung macht möglicherweise hinterher weniger ärger.<\/p>\n Die Beschreibung der Architektur kann jedoch in Abhängigkeit von der Größe des Projekts eine Menge Aufwand bedeuten. Das lässt sich daran ablesen, dass selbst eine oberflächliche Architekturbeschreibung des hier als Beispiel verwendeten Projektzeitmanagers schon einige Seiten umfasst – und das ohne jegliche Erfassung von Abläufen in Form der verschiedenen UML-Diagramme.<\/p>\n UML ist sicher ein Thema, das auch Access-Entwickler zumindest vorausschauend einmal unter die Lupe nehmen sollten – spätestens wenn .NET auch vor Access keinen Halt mehr macht, sind Objektorientierung und in diesem Zusammenhang von der UML zur Verfügung gestellte Diagrammtypen ein Thema.<\/p>\n","protected":false},"excerpt":{"rendered":" Wer hin und wieder eine Access-Anwendung für den Eigengebrauch aus dem Handgelenk schüttelt, ohne sich vorher Gedanken um ihre Aufbau zu machen, erleidet dadurch sicher keinen Schiffbruch. Wenn Sie aber größere Projekte angehen und dies vielleicht auch noch im Kundenauftrag, erleichtert eine vernünftige Planung Ihnen und dem Kunden das Leben.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662005,66052005,44000040],"tags":[],"class_list":["post-55000296","post","type-post","status-publish","format-standard","hentry","category-662005","category-66052005","category-Allgemein"],"yoast_head":"\nüberblick per Diagramm<\/h3>\n
Kombiniere, kombiniere<\/h3>\n
Eingabe von Projektzeiten<\/h3>\n
Projekt oder nicht Projekt<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{7DD77ADF-9961-4A03-82A7-4094AEAF3533}\/pic002.png\")
<\/p>\nAnzeige der Projekte<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{7DD77ADF-9961-4A03-82A7-4094AEAF3533}\/pic003.png\")
<\/p>\nTätigkeiten eintragen<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{7DD77ADF-9961-4A03-82A7-4094AEAF3533}\/pic004.png\")
<\/p>\n