Diplomarbeit, 2007
136 Seiten, Note: 1,3
1 Einleitung
2 Theorie
2.1 Vorstellung des Unternehmens
2.2 Aufgabenstellung
2.3 Die agile Vorgehensweise
2.3.1 Die agile Programmierung
2.3.2 Eine Übersicht agiler Methoden
2.4 Basiswissen zur Konzeption
2.4.1 Ausgangsebene der UML
2.4.2 Die ER-Datenbankmodellierung
3 Umsetzung
3.1 Entwicklungswerkzeuge und Techniken
3.1.1 Die Serverumgebung XAMPP
3.1.2 Das phpMyAdmin – ein webbasiertes Datenbanksadministrationstool
3.1.3 MySQL Tools
3.1.4 PEAR
3.2 Realisierung des Projekts – oder einige äußerst hilfreiche Programmierfunktionen
3.2.1 Die MySQLi-Erweiterung, Funktionen für die Kommunikation mit der Datenbank
3.2.2 Authentication – ein PEAR-Paket
3.2.3 Date and Time – ein weiteres PEAR-Paket
3.2.4 Der phpDocumentor
4 Resümee und Ausblick
5 Anlagen:
6 Quellenverzeichnisse
6.1 Literatur
6.2 Internet-Quellenverzeichnis
Abbildungsverzeichnis:
Abbildung 2-1: Die duale Prozessarchitektur
Abbildung 2-2: Attribute im ER-Diagramm
Abbildung 2-3: Primärschlüssel im Chen- und im Crow’s Diagramm
Abbildung 2-4: Datenredundanz in einer Tabelle
Abbildung 3-1: Die Architektur von XAMPP
Abbildung 3-2: Die wichtigsten Parameter zur Konfiguration von phpMyAdmin
Abbildung 3-3: Die wichtigsten phpMyAdmin-Operationen im Überblick
Abbildung 3-4: Das MySQL Migration Toolkit
Abbildung 3-5: Der MySQL Query Browser
Abbildung 3-6: Die Klassen der MySQLi-Erweiterung
Abbildung 3-7: Die verfügbaren Typen für gebundene Parameter
Abbildung 3-8: Storage-Driver für Auth
Abbildung 3-9: Methoden zum Festlegen von Callback-Funktionen
Abbildung 3-10: Konstanten zur Formatierung mit getDate()
Abbildung 3-11: Die wichtigsten Platzhalter für die Methode format()
Abbildung 3-12: Methoden zum Auslesen von Datumsteilen
Abbildung 3-13: Methoden der Klasse Date_TimeZone
Abbildung 3-14: Die wichtigsten Tags von phpDocumentor
Abbildung 3-15: Von phpDocumentator erzeugte Klasse mit Codekommentaren
Die hier vorliegende Arbeit beschreibt die Entwicklung eines webbasierten Seminarabwicklungssystems.
Dieses System ermöglicht die passwortgeschützte Ansicht, Speicherung und Aktuali-sierung von Seminarabwicklungsdaten über das Intranet und Internet. Es besteht aus einem Stammdaten-, Seminarbestätigungs-, Controlling- und Administrationsmodul. Zusätzlich kann man den Benutzern des Programms in der Benutzerverwaltung verschiedene Rechtebeschränkungen zur Arbeit im System einräumen.
Wesentliche Datensätze in den großen Datenbeständen des Systems können mit entsprechenden spezifischen Suchfunktionen aufgefunden werden.
Alle Daten des Systems lassen in eine Word-, Excel-, PDF-, XML- oder Druckdatei konvertieren.
Abgespeicherte Seminarteilnehmer und deren Firmen können direkt aus dem System heraus per Email kontaktiert werden.
Alle benötigten Standardformulare für das Seminarbestätigungs- und Controllingmodul können als PDF- oder ausdruckbare Datei erzeugt werden. Außerdem gibt es für die Rechnungsdaten Archivierungs- und Reportingfunktionen.
Im Administrationsbereich befindet sich unter anderem die Möglichkeit zum Backup und zur Replikation.
Als Plattform für die Umsetzung der Webanwendung wird ein so genanntes LAMP –
System verwendet. LAMP steht für Linux, Apache, MySQL und PHP, eine Kombination aus Betriebssystem, Webserver, Datenbanksystem und Skriptsprache.
Das nächste Kapitel ist sozusagen der theoretische Abschnitt der Diplomarbeit. Es stellt die Firma vor und gibt in kurzen Worten die Aufgabenstellung wider. Außerdem erläutert es die Vorgehensweise bei der Aufgabenbearbeitung und beschreibt einige konzeptionelle Grundlagen.
Kapitel 3 elaboriert schließlich die Umsetzung des Projekts. Zuerst werden nützliche Werkzeuge und Techniken geschildert. Danach werden einige bei der Programmierung sehr hilfreiche Funktionen anhand von Quellcodeauszügen erklärt.
Das letzte Kapitel gibt einen lapidaren Ausblick auf Techniken mit Zukunft.
Das Unternehmen iKR GmbH sitzt in Mannheim-Käfertal. Es konzeptioniert und realisiert Trainingsmaßnahmen im IT-Bereich, entwickelt maßgeschneiderte Qualifizierungskonzepte und führt Schulungen durch.
Die GmbH verfügt über 4 Schulungsräume. Die Seminare werden aber auch in den Räumlichkeiten der Unternehmen durchgeführt oder im eigenen mobilen Schulungsraum vorort. Modernste Seminartechnik, ein schönes stilvolles Ambiente, eine angenehme Lernatmosphäre und individuelle Betreuung zeichnen das Unternehmen aus.
Die Trainer und Consultants stehen nicht nur für profundes Fachwissen, sondern sind auch sensibilisiert, individuelle Bedürfnisse unterschiedlichster Zielgruppen zu erfüllen. Consulting- und Projekterfahrung garantieren, dass Kenntnisse aus Theorie und Praxis vermittelt werden und dass das Projekt zum Erfolg führt.
Flexibilität ist eine weitere Stärke. Egal, ob es sich um den Schulungsort, einen Termin, einen besonderen Trainerwunsch, individuell zusammengestellte Trainingsunterlagen oder um die Gesamtorganisation der Trainingsmaßnahmen handelt, es wird eine Lösung gefunden, die den Wünschen gerecht wird.
Die langjährige Zusammenarbeit mit Unternehmen wie ABB, Alstom Power Generation, Bombardier, ReckittBenckiser, Roche Diagnostics oder T-Mobile International spricht für die Erfahrung von iKR.
IKR unterstützt und gibt Ratschläge bei der Planung und Organisation des gesamten Schulungsbedarfs, konfektioniert das projektbezogene beziehungsweise individuelle Firmen-Seminar, den Workshop oder führt ein Coaching am Arbeitsplatz durch, auch in englischer Sprache.
In regelmäßigen Abständen werden die Kunden von ikR seine zur kostenfreien POWER HOUR eingeladen. Hier werden die Kunden über Trends und Tendenzen, neue Seminarbereiche und aktuelle Themen sowie über iKR-Softwaretools informiert.
Einmal im Jahr findet für maximal 50 Teilnehmer - ein Tagesseminar zu einem aktuellen Thema aus den Bereichen Software oder Projektmanagement statt. Die Teilnahmegebühr wird an eine soziale oder karitative Einrichtung überwiesen. Welche das dann sein wird, können die Kunden vorschlagen.
Mit OnDemand erstellt und veröffentlicht iKR projektbezogene Lerneinheiten in drei alternativen Lernmodi: Demo-, Übungs- und Praxismodus. So leistet man Unterstützung bei der Durchführung von Delta-Trainings oder bei der Einführung von neuen Programmen. Ebenso erstellt man maßgeschneiderte Dokumentationen, Handbücher und Trainingsleitfäden.
IKR schließt Lernplattformen an bereits bestehende oder an interne Plattformen an.
Es werden alle Phasen des Projektmanagements unterstützt. Von der Beratung in der Projektstartphase über das Coaching in der Projektdurchführung bis hin zum externen Projekt-Controlling durch Bereitstellung optimierter Softwaretools wird geholfen, genau die Faktoren zu analysieren und zielorientiert umzusetzen, die den Erfolg der Kundenprojekte gewährleistet.
Ebenso stellt iKR die richtigen Projektassistenten, Projektmitarbeiter und Projektleiter zur Verfügung, um die Systemlandschaft eines Unternehmens an die neusten technischen Anforderungen anzupassen. iKR unterstützt in folgenden Bereichen:
- Umsetzung von CRM-Systemen und DataWareHouse,
- Prozessanalyse und Prozessoptimierung,
- Personal Outsourcing,
- First- und Second Level Support,
- Benutzerservice und Hotline,
- Software-Validierung, Erarbeiten einer Entscheidungsgrundlage,
- Inter-/Intranet-Lösungen und Realisierung,
- Erstellung und Optimierung eines effizienten Sicherheitskonzeptes,
- Mail- und Groupware-Lösungen.
Außerdem werden die firmeneigenen Schulungsräume für Besprechungen, Theorie- oder EDV-Trainings vermietet, inklusive individueller Betreuung der Teilnehmer.
Es soll ein webbasiertes System entwickelt werden, dass die Mitarbeiter in allen Prozessen der Seminarverwaltung unterstützt. Im Modul Stammdaten sollen die Daten von Seminarteilnehmern, Trainern, Firmen, Rechnungs- und Warenempfängern erfasst werden. Alle gespeicherten Personen müssen aus dem System heraus per Email erreichbar sein.
Des Weiteren sind noch Seminarorte und Lehrgänge zu erfassen. Die große Schwierigkeit besteht darin, dass die einzelnen Stammdaten nur in komplexen Abhängigkeiten zueinander erfasst werden dürfen.
Das Modul Seminarbestätigung soll die in den Stammdaten angekündigten Lehrgänge abschließend bestätigen. Dann muss es die Tischkarten und Einladungen für die einzelnen Teilnehmer generieren und den Trainer über das stattfindende Seminar und entsprechender Teilnehmerliste informieren.
Im Modul Controlling sollen dann die Rechnungen für die Teilnehmer erstellt werden. Nachdem dann die Zahlungen eingegangen sind, müssen die Rechnungen archiviert werden. Die Daten im Archiv sollen dann dank wesentlicher Reportingfunktionen auszuwerten sein. Zur detaillierten Nachbearbeitung müssen die Daten noch ins Excel-Format konvertierbar sein.
Es gibt in der Software-Entwicklung viele verschieden Vorgehensmodelle, die letztendlich nicht unmittelbar in die Nuancen des Entwicklungsalltags übertragbar sind. Dagegen versucht die Agilität vorzugehen. Sie erlaubt Flexibilität und bindet nicht strikt an ein bestimmtes Verfahren.[1]
Die Anwendung agiler Abläufe übt Effekte auf Systemanalyse, Architektur und Design, Programmierung und Dokumentation aus. Im Folgenden sind die Auswirkungen auf die Programmierung näher beschrieben und anschließend wird noch konkret auf zwei agile Methodiken eingegangen. Eine intensivere Betrachtung agiler Vorgehensweisen würde den Rahmen dieser Arbeit jedoch sprengen.
Die Programmierung zählt mit zu den gestalterischsten Aktivitäten der Software-Entwicklung. Hier werden einige Maxime der Agilität aufgezählt, die auch bei der Implementierung anwendbar sind:[2]
- Zeitiges Feedback: Oft testen. Durch die gegenwärtig erhältlichen Testframeworks, allen voran die XUnit-Familie, ist es möglich das Testen sehr wirkungsvoll in die Programmierarbeiten einzubinden. Der Ansatz der testgetriebenen Entwicklung, anfänglich ein bedeutendes Merkmal des eXtreme Programming, verbessert das baldige Feedback bei der Programmierung.
- Hochgradige Ausgangsorientierung: Entwickler sollen an erster Stelle lauffähige Anwendungen anfertigen. Gewiss, dazu eignen sich auch Dokumentation und Testfälle, aber ohne einwandfreien, performanten und anpassungsfähigen Quellcode ist die gesamte Ergänzung der Software-Entwicklung relativ nutzlos!
- Umgestaltungen sind alltäglich nötig und keine Einmaligkeiten. Darum soll beim Programmieren dieser Vorsatz im Hinterkopf behalten werden. Wenn dabei fundamentale Entwurfsprinzipien beachtet werden, bleibt viel Flexibilität erhalten.
Mut ist gefragt. Vielleicht fragt man sich, was Mut mit Programmieren zu tun hat. Dann und wann benötigt man Mut, um adäquate Pfade zu begehen und sich von ausgetretenen Wegen abzuwenden. Möglicherweise ist ein simples und schnelles Ergebnis angemessen, wo doch bisher komplett konfigurierbare Luxuslösungen entwickelt worden sind. Es bedarf an viel Mut, um eine Fülle an Quellcode einfach zu löschen und zu erneuern, anstelle unzähliger Zeit in Flickwerk zu investieren. Diese Arbeit geht aber nicht auf Ratschläge für generell übliche Programmiersprachen ein, sondern es handelt es sich nur um allgemeine Hinweise.
Agile Programmierung ist einfallsreich und synchron dazu enorm diszipliniert. Agile Programmierung hat nichts, wirklich gar nichts mit chaotischem Code von Hackern zu tun. Das Musterbeispiel dafür gibt eXtreme Programming ab - ein genauso agiles wie diszipliniertes Vorgehen bei der Software-Entwicklung. Man soll seinen Projekten sattelfeste Programmierrichtlinien geben - es finden sich exzellente Modelle und Exempel zu unzähligen Sprachen im Internet. Am Besten es werden diverse Publikationen mit spezifischen Programmiermustern, -tipps und Best Practices an einflussreichen Orten im Projekt aufgestellt. Die Merkmale und Normen von Codekritiken sollten allen Programmierern bekannt sein. Das bedarf anfangs einer bestimmten Abstimmungsanstrengung, meidet langfristig aber eine Menge Irrtümer.
Keine Informationen reproduzieren. Unterlasse Redundanz. Es müssen keine Kommentare erklärt werden, die aus dem Quellcode ersichtlich sind. Wiederholte Informationen aus abwechselnden Stellen im Code lassen sich subsumieren, dies ist ständig durchführbar. Das Musterexempel hierfür sind Konstanten (Strings oder auch Integerzahlen), die im Quellcode bloß in Sonderfällen etwas zu suchen haben.
Extreme Abhängigkeiten unter Software-Bestandteilen führen zu unnachgiebigen, unelastischen und schwer wartbaren Systemen. Demgegenüber braucht man eine bestimmte Menge von Abhängigkeiten, ansonsten können keine Beziehungen unter den einzelnen Bestandteilen erzeugt werden.
Entwickler werden andauernd nach Zahlen befragt: Wie lange dauert es noch? Wie viele Datensätze verarbeitet das Modul stündlich? Reicht eine 2 Mbit Anbindung aus? Die generelle Antwort auf diese Fragestellungen sollte lauten: „Ich melde mich bei Ihnen.". Es bedarf an Zeit, kluge Schätzungen oder Messungen in die Praxis umzusetzen.
Das geschulte Schätzen hütet im Zweifelsfall vor Verwunderungen. Beim Programmieren kann auch geschätzt werden: Wie anspruchsvoll wird es, dieses Codeteil nachher zu ändern? Wie viele Clients sind imstande das Modul simultan zu gebrauchen, ohne dass es zu Performanceeinbußen kommt? Schätzungen kann man mittels richtigen Messungen durchleuchten - diese Gepflogenheit kommt einem auf jeden Fall zugute!
Billige keine miserable Qualität. Quelltexte und Entwürfe sollten umgehend berichtigt werden, wenn man auf erdenkliche Probleme stößt. Pflege im Entwurf und im Code ist der Ausgangspunkt für Flexibilität - und die benötigt man sicherlich. Es müssen Techniken und Werkzeuge verwendet werden, die einem in Bezug auf Qualität dienen. Testframeworks für Unit-Tests sind hierfür von erster Güte, wie etwa die XUnit-Familie. Ferner nützt einem das Konzept von „Design-by-Contract": Hierbei werden die Programme um Befehle ergänzt, die Rechte und Pflichten kontrollieren, exakter: Vor- und Nachbedingungen von Funktionen und Methoden.
Als weitere Unterstützung dienen die Software-Metriken. Diese sind stets zu benutzen. Damit kann man in den Projekten alle für diese Konstellation bedeutungsvollen Größen messen. Im Falle dass Leistungsfähigkeit etwa eine essenzielle Bedeutung hat, sollte im täglichen Anpassungsvorgang ein erdenklich wirklichkeitsnaher Lasttest integriert werden. Man kann die meisten strukturellen Metriken automatisch auswerten lassen, wie Schwierigkeit, Abhängigkeiten, Nichtbeachten von Style-Guide-Vorgaben, abwesende Kommentare und allerhand mehr. Metriken sollten ständig rezipiert und stets beachtet werden. Metriken sind als Indikatoren für Schwachpunkte oder Gefahren zu sehen, und nicht um auf diese Weise Programmierer zu beurteilen.
Die Syntax von Programmiersprachen ist gewöhnlich einfach erlernbar. Unerfreulicherweise kommt kaum ein reelles Projekt mit den basierten Sprachmitteln aus, sondern beansprucht eine Menge an Bibliotheken, Frameworks, Zusätzen oder anderweitigen Werkzeugen. Hier wartet häufig beträchtlich mehr Komplexität als in den Sprachen selbst. Es reicht gegenwärtig nicht mehr aus, die Basiskonstrukte von Java oder C# zu erlernen, sondern die Bibliotheken bringen in Projekten den meisten Nutzen.
Es bietet sich an allzeit an über den Radius der eigenen Ansprüche und Lösungen hinauszublicken. Es kann sich mit Kollegen über deren Probleme ausgetauscht werden, an Konferenzen partizipiert werden und Workshops zu neuen Technologien aufgesucht werden. Eine andere Sprache anzutesten ist eine Möglichkeit, eine Andere viel über Entwurfsmuster und Programmier-Idiome zu lesen. Erweitertes Fachwissen sorgt für neue Ideen in der Arbeit.
Eine exzellente Gelegenheit dazu bieten die vielen Open-Source-Projekte, bei denen Entwurf und Code frei einsehbar im Internet auf Wissensbegierige lauern. Aus jenen Entwürfen lässt sich lernen, man kann mit den Verfassern über Nutzen und Mängel von Entwurfsansätzen fachsimpeln. Eine wunderbare Anlaufstelle im Internet ist das Sourceforge-Portal, unter „www.sourceforge.net” auffindbar.
Seit der Jahrtausendwende sind unendlich viele Entwicklungsansätze entstanden, die die agilen Maximen überwiegend oder dürftiger ins Zentrum stellen. Viele der Erschaffer dieser Handhabungen waren es auch, die sich im Februar 2002 in Utah trafen, um das agile Manifest zu verfassen. Im Folgenden werden die bedeutungsvollsten Vertreter dieser neuen Methoden aufgezählt. Crystal und ASD sind eher Entwicklungsphilosophien, die die Grundsätze der Agilität erweiternd mittels etlicher zweckdienlicher Ansichten erörtern. Die Methoden Scrum und ARTE sind zwei Exempel für ganz greifbare Fragestellungen: für das Projektmanagement und für die technischen Systeme. Den Ausklang der Methodenbeispiele geben die radikaleren Vertreter: der Rational Unified Process (RUP), der häufig als zu voluminös und zu umfangreich eingeordnet wird, und eXtreme Programming, die Methode mit dem vermutlich geringsten Umfang, die dank ihrer unnachgiebigen Konzentration auf das Enderzeugnis, den Quellcode bisweilen als zu puristisch angeschaut wird. Andere Methoden wie Lean Development, DSSD oder das Feature-based Programming sind auch interessant. Eine hervorragende Übersicht findet man unter „www.b-agile.de“. Hier werden alleinig RUP und eXtreme Programming behandelt. Diese beiden Methoden waren der Entwicklung des Seminarabwicklungssystems am förderlichsten.[3]
Historisch gesehen ruhen die Anfänge des RUP bei der Entwicklung der UML (Unified Modeling Language). Das anfängliche Begehren der UML war die Entwicklung einer Notation einschließlich eines Prozesses. Diese Ambition wurde dagegen auf den puren Notationsanteil herabgesetzt. Dadurch fehlte allerdings das Grundelement, welches die Applikation der UML im Zusammenhang von IT-Projekten elaboriert. Diese Kluft wurde nachher dank des Software-Entwicklungsprozesses Objectory von Ivar Jacobson geschlossen, dessen fortentwickelte Form derzeit unter dem Namen RUP geschätzt ist.[4]
Als erste Auskunftsquelle zu dieser Herangehensweise in der Entwicklung gilt insbesondere das Werk von Philippe Kruchten „Der Rational Unified Process“, in dem eine Einführung in die verschiedenen Bausteine des RUP (Version 2000) erteilt wird. Als gründlichere und auf den neuesten Stand gebrachte Informationsquelle steht der RUP auf den Webseiten des Herstellerunternehmens IBM zur Verfügung. Dieses Fabrikat enthält einige tausend HTML-Seiten und wird in ständigen Zyklen von etwa sechs Monaten fortentwickelt und gibt bereits ab der Version 2002 auch Ansichten wider zum Thema „Agile Vorgehensweise“.
Der Fortschritt des RUP berührt - wie etliche andere Entwicklungsherangehensweisen - die drei Knotenpunkte: Rollen, Aktivitäten und Ergebnisse (Artefakte) oder anders formuliert „ Wer stellt wessen Resultat her". Die Tätigkeiten und Resultate fasst der RUP in Aktivitätssegmente zusammen (zum Beispiel Anforderungen, Analyse und Entwurf und Implementierung). RUP führt diese Tätigkeitsbereiche als Disziplinen an . Außer den Kerndisziplinen gibt es auch besagte Hilfsdisziplinen wie Konfigurationsmanagement und Projektmanagement.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-1: Die duale Prozessarchitektur[5]
Der RUP verschafft dem Benutzer hervorstechende Beihilfe in den Wirkungskreisen Anforderungen und Analyse und Entwurf. Im Unterschied dazu entdeckt man freilich ebenfalls Entwicklungsansätze, die die Aufmerksamkeit mehr auf die Ausführung richten. Das besagt nicht, dass die anderen Aktivitätssegmente nicht beachtet werden. Im äußersten Fall werden dagegen die Aktivitätssegmente Anforderungen, Analyse und Entwurf als begleitende Tätigkeiten zu der Erreichung des Projektziels in einer eher intuitiven Gestalt realisiert. Der am Nachgefragtesten Protektionist dieses Entwicklungsansatzes ist definitiv eXtreme Programming . Entwicklungsansätze wie etwa Crystal Family behalten vielmehr einen harmonischen Ansatz im Auge.
Ein Merkmal des RUP ist die duale Prozessarchitektur (Managementsicht wider Entwicklungssicht). Die vertrautere Entwicklungssicht dokumentiert in einer Art Aufzählung, gleichwohl ohne standhafte Bezugnahme zur Zeitachse, die einzelnen zu absolvierenden Aktivitäten, die in schlüssigen Disziplinen wie etwa „Anforderungen" oder „Analyse und Design" aggregiert wurden. Die Managementsicht hingegen etikettiert die entwurfstechnischen Gesichtspunkte und enthält infolgedessen Ansichten zu Phasen, Iterationen und Meilensteinen.
Beginnend mit der Klassifikation in diese zwei Ausmaße wird eine anpassungsfähige Umsetzung des RUP im tatsächlichen Projekt ermöglicht. Bedeutend hierbei ist, dass die Managementsicht bezüglich der Meilensteine eine inhaltlich qualitative Querverbindung zu den Resultaten der Entwicklungssicht hat und keine quantitative . Das bedeutet, der Projektverlauf wird nicht an den Erzeugnissen von Dokumenten und Modellen abgemessen, sondern an deren Tauglichkeit, eine tragfähige Grundlage für anstehende Resolutionen hervorzurufen.
Dementsprechend hat das Endziel der ersten Phase vom Fassungsvermögen her identisch, mit dem die Projektziele (Systemgrenzen, ökonomische Effizienz, unter anderem) zwischen allen partizipierenden Stakeholdern zu erzielen. Im Finale dieser Phase wird beschlossen, ob es eigentlich zu einer Absicht kommt. Der Endzweck der zweiten Phase indessen ist die Bestimmung einer tragfähigen Architektur als Grundstein für die tatsächliche Konstruktion des Systems unter Rücksichtnahme der Systemgrenzen, der Kernfunktionalitäten, der Güteeigenschaften wie auch der Gefahren. Zur Vollbringung dieser Ziele ist es jeweilig erforderlich, gewisse Resultate aus der Entwicklersicht in einer gewissen Güte bereitzustellen. Zum Aufbau einer tragfähigen Architektur kann etwa eine prototypische Ausführung unbedingter Betrachtungsweisen uneingeschränkt erforderlich sein. Es ist eine offensichtliche Abwendung von Planungsansätzen zu betrachten bei denen probiert wird, den Projektverlauf und das Risiko mittels der aufeinander folgenden Erzielung von Resultaten (Anforderungsdokument - Analysedokument –Designdokument unter anderem) zu messen beziehungsweise zu kontrollieren.
Die Einfälle zu eXtreme Programming (XP) entspringen der Feder von Ward Cunningham und Kent Beck, Branchengurus für objektorientierte Systementwicklung. XP besteht aus einer Anzahl unkomplizierter, jedoch eng verknüpfter Verfahren. Ziele dieser Verfahren sind hohe Produktqualität, baldiges Feedback, nützlicher Wissensübertragung im Team wie auch Flexibilität und Modifizierbarkeit der angefertigten Systeme. Auch wenn der Name „eXtreme Programming" den Nebengeschmack von Gesetzlosigkeit und rücksichtslosem Hackertum erweckt - in Wahrheit gehört XP zu den beachtenswertesten gewissenhaften und disziplinierten Entwicklungsvorgehensweisen, die strikte Vorgaben über einzelne schematische Aktivitäten und Entwicklungstätigkeiten fabrizieren. Verschiedene Kritiker werfen, gewöhnlich aus Unwissenheit oder fehlender XP-Erfahrung, dem eXtreme Programming ein Defizit an Formalismus vor, der in funktionierender, aber undokumentierter Software endet.[6]
XP als Methode ist geeignet für kleinere bis mittlere Teams, erfahrungsgemäß bis zu 15 Individuen. Für erheblich größere Entwicklungsprojekte sind bis jetzt kaum praktische Erfahrungen mit XP bekannt. In einigen Projekten wurden dagegen in größeren Teams einzelne Praktiken von XP mit positivem Effekt integriert, nämlich das Planungsspiel mit iterativen Methoden, die fortdauernde Integration und die testgetriebene Entwicklung.
XP ist ein iterativer Vorgang. Es unterteilt die Entwicklung in Iterationen von zirka 2 Wochen Dauer - in Ausnahmen zudem auch länger. Bestenfalls probiert man es in Projekten mit Iterationsdauern von 2-3 Wochen und lässt das Team darüber urteilen, wie lange Iterationen am zweckmäßigsten sind. Die wesentlichen Praktiken von XP:
- Planungsspiel: Es wird im ganzen Projekthergang beständig geplant. In jeder Iteration schätzen die Entwickler die Unkosten und Gefahren der zu entwickelnden Funktionen. Die Auftraggeber selektieren auf Grundlage dieser Schätzungen sowie des geschäftlichen Wertes die jeweiligen Funktionen, die in der bevorstehenden Iteration entwickelt werden sollen.
- Akzeptanztests: Die Auftraggeber stellen mit dem ursprünglichen Feature dar, wie automatische Akzeptanztests daherkommen sollen. Deswegen haben Akzeptanztests für die Entwicklung einen unmittelbaren und reproduzierbaren Gradmesser für die Leistung.
- Einfaches Design: Das Programmiererteam gestaltet das Design des Systems so simpel wie denkbar. Es sollte für die Charaktere der gegenwärtigen Iteration zweckdienlich sein und nicht für alle die Sachen, die vermutlich in der Zukunft noch bevorstehen. Das Design und der Quellcode bestehen absolut jeden Test und sind möglichst schlank durchzuführen.
- Programmierung-in-Paaren: Jede erstrebte Software wird von zwei Entwicklern gemeinsam programmiert, die beisammen an einer einzigen Tastatur sitzen. Diese Praktik hat die Intention der fortlaufenden Überprüfung.
- Testgetriebene Entwicklung: Die Entwickler entwerfen zuvor Testfälle und anschließend den Code. Sie schaffen in kurzen Zyklen, ihre Tests dienen ihnen beim Refactoring der Programme.
- Refactoring: Entwickler bemühen sich fortlaufend den Code zu optimieren, ihn sauber und fehlerfrei zu halten.
- Kontinuierliche Integration: Das ganze System wird zumindest einmal am Tag integriert. Es ist nur erlaubt Code zu übernehmen, sofern alle Testfälle weiterhin gelöst werden.
- Ergebnisse-gehören-allen: Jedes Entwicklerpaar darf jedes Resultat, egal ob Code und Dokumente, allzeit modifizieren, optimieren oder ergänzen. Anfänglich hatten Cunningham und Beck diese Praktik im Übrigen Collective Code Ownership bezeichnet - es bezog sich damals lediglich auf Quellcode.
- Programmierstandard: Alle Programme gehorchen einem identischen Programmierstil und es gibt Konventionen, die das ganze Team annimmt.
- Metapher: Das Programmiererteamteam verfolgt eine kollektive Vision, wie das System funktionieren soll.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-2: Ablauf der testgetriebenen Entwicklung[7]
In diesem Teil werden die benötigten Grundlagen für die konzeptionelle Herangehensweise an das Webdatenbankprojekt gelegt. Einige in die Praxis umgesetzte Diagramme lassen sich in der Anlage finden.
Grady Booch und Jim Rumbaugh haben sich im Oktober 1994 bei der Rational Software Corporation zusammengeschlossen, um ihre aussichtsreichen Methoden zu einem zusammengehörenden Industriestandard weiterzuentwickeln. Es entstand zuerst der Vorläufer der Unified Modeling Language (UML), der unter dem Namen Unified Method 0.8 veröffentlicht wurde. Seit Herbst 1995 arbeitete auch Ivar Jacobson an der Entwicklung der UML mit. Im Oktober 1996 erschien die Version 0.91 der UML. Im September 1997 wurde die Version 1.1 der UML vorgestellt, in die außerdem die Einfälle verschiedener UML-Partner aufgenommen wurden.[8]
Die UML 1.1 wurde von der Object Management Group (OMG) im November 1997 als Standard beschlossen. Die Weiterentwicklung der UML wurde ganz an die OMG übergeben. Im Juli 1998 wurde von der OMG die UML 1.2 intern freigestellt. Alle Modifikationen waren redaktionell und hatten keine Effekte auf den technischen Kern. Im Juni 1999 publizierte die OMG die UML 1.3. Belangreiche Fortschritte waren die Auflösung von Inkonsistenzen zwischen diversen Dokumenten. Überdies entstanden präzisere Definitionen und Erklärungen. Dazu wurden inhaltlich unerhebliche Veränderungen vorgenommen. Im Mai 2002 tauchte die UML 1.4 auf, die kleinere Besserungen und einzelne Ausweitungen einschloss. Ebenso die UML 1.5, die im März 2003 publiziert wurde, bezog kleinere Berichtigungen mit ein.
Eine umfassende Überarbeitung ging der UML 2.0 voran, die entgegengesetzt der Version 1.x essenzielle Zunahmen und Umgestaltungen aufweist. Das berührt etwa die Aktivitäts- und Sequenzdiagramme. Ansonsten wurde das Metamodell, das heißt das UML-Modell zur Spezifikation der UML, komplett überarbeitet. Die ersten Dokumente wurden von der OMG im August 2003 herausgegeben. Im Oktober 2004 wurde eine berichtigte Ausführung dieses Dokuments fertig gestellt und im 1. Quartal 2005 bekannt gemacht. Augenblicklich gilt die UML 2.0 als offizielle UML-Version der OMG. In den nächsten Unterkapiteln werden einige Diagramme der UML vorgestellt. Dies sind die wesentlichen Diagrammarten die für die Konzeption des Seminarabwicklungssystems von Bedeutung waren.
Ein Use-Case (use case) stellt die Funktionalität der Applikation dar, die ein Akteur bewerkstelligen muss, um ein ersehntes Resultat zu bekommen oder um ein Ziel zu erreichen. Use-Cases sollen helfen, mit dem künftigen Anwender über die Funktionalität der Applikation zu reden, ohne sich sofort auf Details einzulassen.[9]
Ein Akteur (actor) ist eine Rolle, die ein Anwender der Applikation spielt. Akteure sind Menschen oder auch andere automatisierte Systeme. Sie sind stets außerhalb des Systems positioniert.
Das Use-Case-Diagramm (use case diagram) gibt auf beträchtlichem Abstraktionsniveau einen förderlichen Überblick über das Softwaresystem und seine Schnittstellen zur Umgebung. Die Akteure werden mehrfach als Strichmännchen mit dem Stereotypen „actor“ oder als besonderes Bilderschriftzeichen, beispielsweise mit einem Computersymbol spezifiziert. Use-Cases werden größtenteils als Ovale abgebildet. Der Name kann in das Oval oder darunter notiert werden. Daneben können Use-Cases wahlweise durch ein Quadrat mit Oval als Bilderschriftzeichen gezeichnet werden. Ein gerader Strich zwischen Akteur und Use-Case kündigt an, dass eine Kommunikation besteht. Sie wird in der UML als Assoziation abgebildet. Das beobachtete System (subject) wird im Use-Case-Diagramm mittels eines großen Quadrates dargestellt, das alle Use-Cases impliziert.
Mithilfe der extend-Beziehung (extend relationship) wird ein Use-Case A durch einen Use-Case B ausgeweitet. Der Use-Case A stellt die Basisfunktionalität dar, der Use-Case B spezifiziert Erweiterungen. Der Use-Case A kann einzeln oder gemeinsam mit den Erweiterungen ausgeübt werden. Erweiterungspunkte (extension points) geben an, an welchen Stellen der Basis-Use-Case A ausgedehnt wird. Dadurch, dass eine Erweiterung eingearbeitet wird, muss eine Bedingung erfüllt sein. Diese Bedingung vermag bei Bedarf als Notizzettel beziehungsweise Randbemerkung zu spezifiziert und an die extend-Beziehung angehängt zu werden.
Die include-Beziehung (include relationship) gestattet es, dass die kollektive Funktionalität der Use-Cases A und B durch einen Use-Case C dargestellt wird. Der Use-Case C ist nicht optional, sondern wird immer für die einwandfreie Durchführung von A und B gebraucht. Die include-Beziehung spart die wiederholte Angabe desselben Auftretens. Im Unterschied zur extend-Beziehung ist die Durchführung des Use-Case C von keiner Bedingung abhängig.
Überdies ist es denkbar, eine Generalisierung zwischen je zwei Use-Cases oder zwei Akteuren zu modellieren. Sozusagen wie bei Klassen erbt das spezialisierte Element jede Eigenschaft des allgemeineren Elements.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-3: Ein Use-Case Diagramm und seine Bestandteile[10]
Eine Aktivität (activity) steht für die Ausführung von Funktionalität beziehungsweise von Verhalten. Sie wird mittels diverser Knoten modelliert, die durch gerichtete Kanten zusammengeschlossen sind. Es lassen sich Aktionsknoten, Kontrollknoten und Objektknoten unterscheiden. Aktivitäten weisen nicht nur ein Kontrollfluss-, sondern auch ein Datenmodell auf. Das Kontrollflussmodell spezifiziert den Ablauf der Funktionen und das Datenmodell die Daten, die zwischen den Funktionen getauscht werden. Die Aktivität ist ein erstmaliger Entwurf in der UML 2. Sie wird in einem Aktivitätsdiagramm (activity diagram) modelliert.[11]
Die kleinste anwendbare Funktionseinheit in einer Aktivität wird als Aktion (action) ausgedrückt. Sie wird als ein Quadrat mit abgerundeten Ecken abgebildet. In das Quadrat wird entweder der Name oder eine kurze Angabe zur Aktion geschrieben. Steht eine Aktion für einen Aktivitätsaufruf, dann wird rechts unten am Quadrat ein kleines gabelähnliches Zeichen eingebracht.
Abgesehen von den Aktionsknoten kann eine Aktivität Kontrollknoten (control nodes) aufweisen: Entscheidung und Integration für die Modellierung von Wahlmöglichkeiten, Splitting und Synchronisation für die Spezifikation gleichgerichteter Abläufe sowie Start- und Endknoten. Ferner bietet die UML 2 einen Endknoten an, um das Ende eines Kontrollflusses zu spezifizieren.
Mithilfe von Objektknoten (object nodes) vermögen Daten von einer Aktion zur nächsten gegeben werden. Sie werden durch Quadrate abgebildet und verwirklichen das Datenmodell einer Aktivität. In das Quadrat werden der Name von dem Objektknoten, beispielsweise der Klassennamen und wahlweise der Zustand, in welchem sich das Objekt befindet, eingefügt. Ein spezieller Typus von Objektknoten ist der Parameterknoten (Eingans- und Ausgangsparameter), der auf den Grenzlinien einer Aktivität angebracht wird. Eine zusätzliche Besonderheit ist der Datenspeicher, der ruhende Daten modelliert. Objektknoten sind dazu fähig optional in einem Streaming Modus angelegt zu werden. Das besagt, dass die Daten fortdauernd generiert beziehungsweise verbraucht werden.
Objektknoten können auch zu einer Rechteck-Notation als „Pins“ modelliert werden. Das sind kleine Rechtecke, die geradewegs seitlich einer Aktion angebracht werden. Sie liefern der Aktion Eingabewerte und erfassen Ausgabewerte von ihr. Angrenzend an die Pins wird der Name des Objektknotens hinzugefügt.
Aktionen, die auf das Erfolgen eines Ereignisses lauern, werden als Ereignisempfänger (accept event actions) angegeben. Sie werden durch ein konkaves Fünfeck abgebildet. Eine Sonderform sind Aktionen, die auf ein Zeitereignis warten (accept time event actions, wait time action) . Eine derartige Aktion wird durch eine Sanduhr als Symbol dargestellt. Analog zum Warten auf ein Ereignis ist eine Aktion, die ein Erkennungszeichen an ein Zielobjekt sendet, das da eine Weiterverarbeitung bewirken kann. Der Signalsender, das heißt die Aktion zum Abschicken des Signals (signal send action), wird durch ein konvexes Fünfeck abgebildet. Signalsender und Ereignisempfänger können daneben zusammengesetzt erscheinen. Beispielsweise kann eine Aktion ein Signal versenden, dass ein Zahlungseingang erfolgen muss. Der zu prüfende Zahlungseingang wird als externes Ereignis aufgefasst, das vom Ereignisempfänger umgesetzt wird.
Aktivitätsbereiche (activity partitions) aggregieren Aktionen, die gewisse Verbundenheiten aufweisen, zum Beispiel die organisatorische Einheit, den Standort oder den Verantwortungsbereich. Sie werden auch als Verantwortlichkeitsbereiche oder Partitionen charakterisiert. Die Namen von Partitionen werden in runden Klammern in die Aktionen eingefügt. Es kann auch die so genannte „Schwimmbahn-Notation“ genutzt werden, bei der die Aktivitätsabschnitte durch nebeneinander liegende Linien gekapselt werden. Aktivitätsabschnitte können ineinander geschachtelt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-4: Eine Aktivität und ihre Bestandteile[12]
Ein Sequenzdiagramm (sequence diagram) stellt die Wechselbeziehung zwischen etlichen Kommunikationspartnern dar. Sämtliche Kommunikationspartner werden durch ein Quadrat (Kopf) mit einer Linie verkörpert, die gestrichelt sein kann und die Nutzungsdauer des Kommunikationspartners darstellt. Anstatt Kommunikationspartner sagt man auch Lebenslinie (lifeline). In das Quadrat wird der Name des Kommunikationspartners registriert. In Abweichung zur UML 1.x wird dieser Name nicht gekennzeichnet. Die gestrichelte Gerade einer Lebenslinie verkörpert eine Zeitachse, die von oben nach unten fortschreitet. Das Sequenzdiagramm ist von einem quadratischen Gültigkeitsbereich eingeschlossen, der links oben das Abkürzungszeichen sd (sequence diagram), den Namen der Wechselbeziehung und ausführbare Parameter aufweist. Die UML 2 gestattet es, mithilfe von zusammengesetzten Fragmenten Kontrollstrukturen akkurater zu kennzeichnen, als dies in der UML 1.x machbar war. Die Darstellung weist die kombinierten Fragmente für die if-then-else-Anweisung beziehungsweise die Alternative (Operator alt) und die for-Schleife (Operator loop) auf.[13]
Die Wechselbeziehung unter zwei Kommunikationspartnern kann durch eine synchrone oder eine asynchrone Mitteilung resultieren. Bei der synchronen Nachricht lauert der Sender, bis der Empfänger die verlangte Umsetzung fertig gestellt hat. Der Empfänger überbringt danach dem Sender eine Antwortnachricht, die über das Ende der verlangten Verarbeitung benachrichtigt und ansonsten Antwortdaten mit einbeziehen kann. Synchrone Nachrichten sind häufig Operationsaufrufe, können jedoch auch Signale sein.
Bei der asynchronen Nachricht wartet der Sender keinesfalls auf die Bewerkstelligung der Verarbeitung mittels des Empfängers, stattdessen knüpft er parallel dazu seine individuelle Umsetzung an. Asynchrone Nachrichten werden allzeit durch Signale verwirklicht.
Synchrone Nachrichten werden durch einen Pfeil mit ausgefüllter Pfeilspitze, Asynchrone durch einen Pfeil mit geöffneter Pfeilspitze angezeigt. Die Rückantwort einer synchronen Nachricht ist ein gestrichelter Pfeil. Das Intervall, in der ein Kommunikationspartner die ersuchte Verarbeitung ausführt, kann durch einen - grauen oder durchsichtigen - Balken auf der gestrichelten Linie modelliert werden (Aktionssequenz).
Eine besondere Form ruft die Nachricht zum Generieren eines neuen Kommunikationspartners hervor, die durch einen gestrichelten Pfeil visualisiert wird, der auf das Quadrat des neu generierten Kommunikationspartners hinweist. Das Pendant dazu ist das Löschen eines Kommunikationspartners (Beenden der Lebenslinie), das durch ein ansehnliches X geformt wird.
Für Mitteilungen im Sequenzdiagramm können fakultativ deren Parameter ausführlich angegeben werden. Die Werte der gegenwärtigen Kenngrößen werden in der entsprechenden Reihenfolge wie bei der Spezifikation angeführt, wohingegen belanglose Parameter durch einen Bindestrich ausgetauscht werden können. Alternativ können außerdem die Parameternamen angeführt werden. Hierbei werden nur die bedeutungsvollen Kenngrößen dargestellt, wobei deren Abfolge keine Bedeutung zukommt. Bei einer Antwortnachricht werden die Kenngrößen reproduziert. Überdies sind die Bekanntgabe eines Ergebnisparameters und dessen Zuteilung an ein Attribut durchführbar.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-5: Ein Sequenzdiagramm und seine Dimensionen[14]
Bei der Entwicklung einer Datenbankapplikation werden zu Beginn die Daten modelliert. Die Datenmodellierung gilt als Grundlage zur weiteren Verarbeitung, weil alles von ihr abgeleitet wird. Wurden bei der Formgestaltung Fehler gemacht, vermehren sie sich durch die gesamte Prozesskette und können zu einem späteren Zeitpunkt nicht mehr rückgängig gemacht werden. Deswegen ist es unumgänglich, dass die Datenbankmodellierung sehr sorgfältig bewerkstelligt wird.[15]
Das Design der Datenbank hat die Bedeutungen, Objekte und Verläufe der wirklichen Welt in Formungen der Datenbank umzuändern. Eine große Herausforderung bei diesem Vorgang ist, dass Modellierer der Datenbank, Applikationsentwickler und Endbenutzer die zu administrierenden Daten jedes Mal unter anderen Aspekten ausmachen. Damit die Datenbankanwendung zu einem positiven Ergebnis führt und der Gestaltungsablauf nicht an den Anliegen der Anwender vorübergeht, ist es bedeutend, dass Datenbankdesigner, Entwickler und Benutzer in diesem Zeitabschnitt des Vorhabens denkbar eng zusammenwirken. Diese Kooperation wird durch den verschiedenartigen Einsatz von Fachbegriffen belastet, was zu Irrtümern und Fehlschlüssen führen kann.
[...]
[1] Vgl. Hruschka 2004, S.13
[2] Vgl. Hruschka 2004, S.29-33
[3] Vgl. Hruschka 2004, S.53
[4] Vgl. Hruschka 2004, S.80-83
[5] Hruschka 2004, S.81
[6] Vgl. Hruschka 2004, S.87-89
[7] Dogs 2005, S.91
[8] Vgl. Balzert 2005, S.1-2
[9] Vgl. Balzert 2005, S.24-26
[10] Hahn 2004, S.177
[11] Vgl. Balzert 2005, S.27-29
[12] Hahn 2004, S.201
[13] Vgl. Balzert 2005, S.29-32
[14] Hahn 2004, S.328
[15] Vgl. Geisler 2005, S.133
Der GRIN Verlag hat sich seit 1998 auf die Veröffentlichung akademischer eBooks und Bücher spezialisiert. Der GRIN Verlag steht damit als erstes Unternehmen für User Generated Quality Content. Die Verlagsseiten GRIN.com, Hausarbeiten.de und Diplomarbeiten24 bieten für Hochschullehrer, Absolventen und Studenten die ideale Plattform, wissenschaftliche Texte wie Hausarbeiten, Referate, Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Dissertationen und wissenschaftliche Aufsätze einem breiten Publikum zu präsentieren.
Kostenfreie Veröffentlichung: Hausarbeit, Bachelorarbeit, Diplomarbeit, Dissertation, Masterarbeit, Interpretation oder Referat jetzt veröffentlichen!
Kommentare