Konzeption und Entwicklung eines Kundeninformationsystems

Leopold-Franzens-University Innsbruck
Institut für Informatik
Forschungsgruppe Quality Engineering
BACHELORARARBEIT
Konzeption und Entwicklung eines
Kundeninformationsystems
Werner Kapferer, Samuel Carraro
Betreuer: Philipp Kalb
Innsbruck, 3. Juni 2015
Inhaltsverzeichnis
1 Eidesstattliche Erklärung
3
2 Abstract
4
3 Einleitung
5
4 Firmenprofil
7
5 Anforderungen
8
6 Literatur
14
7 Technische Einführung
7.1 Frameworks . . . . .
7.2 Datenbank . . . . .
7.3 NHibernate . . . . .
7.4 Webservice WCF . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
21
21
23
8 Konzepte
8.1 Architektur . . . . . . . . . . .
8.2 Authentifizierung . . . . . . . .
8.3 Abarbeitung Benutzereingaben
8.4 Webservice . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
28
29
31
9 Technische Details
9.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Controller und View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 WCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32
33
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10 Evaluierung
46
10.1 Evaluierung durch Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.2 Evaluierung durch Abnahmeprotokoll . . . . . . . . . . . . . . . . . . . . 53
11 Projektablauf
11.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Zeitmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
59
60
62
12 Zusammenfassung
66
2
1
Eidesstattliche Erklärung
Wir erklären hiermit an Eides statt durch unsere eigenhändigen Unterschriften, dass
wir die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen
Quellen und Hilfsmittel verwendet haben. Alle Stellen, die wörtlich oder inhaltlich den
angegebenen Quellen entnommen wurden, sind als solche kenntlich gemacht.
Die Arbeit wurde bisher weder in gleicher noch in ähnlicher Form einer andern
Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht.
Samuel Carraro
Datum
Werner Kapferer
Datum
3
2
Abstract
Die Firma din Sicherheitstechniken benötigte eine Webapplikation, die ihren Kunden
Informationen zugänglich macht. Die Applikation sollte in Technologien von Microsoft
umgesetzt werden. Zusätzlich wurde ein WCF Server verlangt, um die firmeninternen
Daten in die Webapplikation spielen zu können.
In dieser Arbeit werden nach einer kurzen Firmenvorstellung die Anforderungen an die
Applikation geschildert. Zuerst werden die verwendeten Techniken und Methodiken,
die in diesem Projekt zum Einsatz gekommen sind erläutert. Neben diesen wird auch
auf die abschließende Evaluierung eingegangen. Schlussendlich wird noch aufgezeigt,
wie das Projekt intern erfolgreich organisiert wurde.
4
3
Einleitung
Webapplikationen liegen derzeit im Trend. Diese Tatsache lässt sich durch verschiedene
Vorteile auch leicht nachvollziehen. Applikationen werden zentral installiert und sind
somit einfach für alle User updatebar. Die Wartung von verschiedenen Versionen und
Varianten entfällt und alle Benutzer arbeiten garantiert mit der gleichen Version. Auch
der Zugriff auf solche Dienste erweist sich als einfach und von überall durchführbar vom Heimbüro bis zum Smartphone, jeder kann mit einem Webbrowser auf die
Anwendung zugreifen.
Daher versuchen auch alle großen Anwendungsentwickler, ihre Produkte in diese Form
zu bringen und zugänglich zu machen. Ein bekanntes und erfolgreiches Beispiel hierfür
ist Microsoft mit seinem Office-Onlineprodukt Office Online“ [15], welches die
”
wichtigsten Funktionen von Word, Excel, etc. ins Web auslagert.
Nun möchte auch die Firma din-Sicherheitstechnik GmbH diesen Schritt machen und
ihren Kunden eine Webplattform zur Verfügung stellen, über welche die Benutzer
Informationen zu Produkten und Projekten abfragen können. Das Unternehmen pflegt
seine firmeninterne Daten wie Kunden, Projekte und dazugehörige Artikel,
Datenblätter oder Normen in einem selbst-entwickeltem Enterprise-Resource-Planning
System (ERP System). Es soll daher neben des eigentlich Webportals auch ein
Webservice programmiert werden, welches das Einspielen der Daten vom ERP-System
in das Webinformationsportal ermöglicht.
Nun musste ein solches Webinformationssystem konzipiert, geplant und ausgearbeitet
werden, welches den Kunden die Möglichkeit bietet, aktuelle Informationen zu ihren
persönlichen Daten, Projekten und bestellten Artikel einsehen zu können.
Das Webportal sollte mehrere Loginstufen unterstützen. Die erste Stufe betrifft alle
Kunden des Unternehmens und bietet die Möglichkeit, allgemeine Informationen und
Dokumente, wie Datenblätter, Normen und Informationen zum Unternehmen abrufen
zu können. Für die zweite Stufe benötigt man allerdings bereits ein aktives Projekt.
Diese Stufe ist die inhaltsreichste, da sie Informationen zum Projekt, sowie zu allen
dazugehörigen Artikeln bietet. Hier werden dem Kunden zum Beispiel komfortabel die
Liefertermine und Lieferadressen der einzelnen Positionen angezeigt. Die dritte Stufe
ist für Administratoren reserviert. Sie können somit allgemeine Einstellungen für die
Applikation oder projektspezifische Konfigurationen über das Frontend vornehmen.
Da das Unternehmen firmenintern mit Microsoftprodukten arbeitet, sollte auch die
entstehende Webanwendung auf solchen basieren. Daher wurde als Basis C# im
Microsoft MVC4 Umfeld verwendet. Darauf basierend arbeiteten wir uns in das
Ext.NET Framework mit seinen View-Komponenten ein, welches bis dahin für uns
ebenfalls unbekannt war. Für die HTML-Bereiche wurde Razor und als Datenbank
eine Microsoft SQL Datenbank verwendet, welche über NHibernate angesprochen
wird.
Im der folgenden Arbeit wird unter Firmenprofil (Abschnitt 4) kurz auf das
Unternehmen eingegangen, mit welchem diese Arbeit ausgearbeitet wurde. Unter
Anforderungen (Abschnitt 5) werden die Technologien, welche zu verwenden waren
5
genauer vorgestellt. Außerdem werden hier anhand von Usecase- und
UML-Diagrammen die Grobanforderungen des Auftraggebers erläutert.
Im Kapitel Literatur (Abschnitt 6) werden ähnliche, schon vorhandene Lösungen
erklärt und analysiert.
Unter Technische Einführung (Abschnitt 7), Konzepte (Abschnitt 8) und
Technische Details (Abschnitt 9) werden die Vorgehensweise und Realisierung, sowie
genutzte Tools und Frameworks aufgezeigt. Hier wird im Detail erläutert, wie unsere
Algorithmen zur Authentifizierung und ähnlichen Vorgängen funktionieren und der
technische Hintergrund dazu detailliert erklärt.
Im kürzeren Kapitel Evaluierung (Abschnitt 10) befindet sich die nachträgliche
Beurteilung anhand der aufgestellten Use-Cases. Hierzu wird die Oberfläche der
Webapplikation, und wie die Anforderungen darin durchführbar sind, beschrieben.
Auch der Aufbau und Nutzen des selbst-erstellten Abnahmeprotokolls wird hier
gezeigt.
Der letzte Abschnitt Projektablauf (Abschnitt 11) befasst sich im Gegensatz zu den
vorhergehenden technischen Kapiteln mit dem organisatorischen Teil des Projektes.
Hier werden kurz die verwendeten Tools und ihr Einsatzgebiet erwähnt. Abschließend
wird noch auf die angwandte Projektdurchführungsmethodik des Extreme
Programming und ihre Umsetzung im Rahmen dieses Projektes eingegangen.
6
4
Firmenprofil
Abbildung 1: Logo von din
Die Firma din-Dietmar Nocker Sicherheitstechnik GmbH hat seit 30 Jahren Erfahrung
im Bereich Notlicht. 1998 wurde die din-Sicherheitstechnik GmbH mit 7 Mitarbeiter
als Handelsunternehmen für Notbeleuchtung durch Herrn Dietmar Nocker gegründet.
Bereits drei Jahre später wurde die din-Facilitymanagement GmbH (Forschung,
Entwicklung und Produktion) gegründet. Im selben Jahr begann die eigene Produktion
im Bereich Notlicht. 2002 war die din-Sicherheitstechnik GmbH Vorreiter mit der
weltweit ersten Anwendung der weißen Hochleistungs-LED und dem weltweit einzigen
vollüberwachten, frei programmier- und schaltbares Notlichtsystem. Fünf Jahre später
wurde die din-Anlagentechnik GmbH für Speziallösungen im Bereich
Verkehrsinfrastruktur gegründet. 2011 fand die Eröffnung des neuerbauten
Headquarters in Linz statt. Im selben Jahr hat der Vertrieb im Bereich Notlicht in den
Ländern Schweiz & Slowenien begonnen.2014 wurde die neue Zweigstelle in Innsbruck
mit mittlerweile 120 Mitarbeitern eröffnet. Und seit diesem Jahr gibt es nun auch die
din-Italia S.r.l. Die Firma ist stets getreu dem Motto Ihre Sicherheit ist unser
”
persönliches Anliegen“ bemüht für alle Anforderungen eine Lösung anzubieten und als
Fachberater im Bereich Notbeleuchtung zur Seite zu stehen.
7
5
Anforderungen
Von der Firma din haben wir den Auftrag bekommen ein Kundeninformationsportal zu
programmieren. Die Daten für das Portal werden vom bereits vorhandenen
ERP-System zur Verfügung gestellt. Zusammen mit einem Mitarbeiter der Firma din
haben wir die Anforderungen an die Software definiert.
Technologien:
Da das Unternehmen ausschließlich mit Microsoftprodukten arbeitet, wurde auch ein
System mit Microsoft-typischer Bedienung und Aussehen gewünscht. Daher war die
Verwendung von solchen Technologien eine Vorgabe. Anforderungen hierbei waren:
1. Entwicklung in .Net 4.5
2. Webapplikation: mit Verwendung von ASP.Net MVC4, sowie Ext.Net MVC
3. 3-Schichten-Architektur
4. Microsofot SQL Server
5. Ansprechende Benutzeroberfläche
Grobanforderungen:
Seitens des Unternehmens wurden folgende Grobanforderungen gestellt:
1. Minimaler Administrationsaufwand:
Die Daten sollten automatisch über push aus dem ERP-System in das neue,
unabhängige Webportal geladen werden.
2. 2-Stufen-Login-Modell:
Nach dem Einstieg in die 1. Stufe sollen allgemeine Informationen, wie Normen
oder Fakten, ersichtlich sein. Der Zugriff zu dieser Stufe wird über ein globales
Passwort gewährt, welches der Administrator ändern kann.
Besitzt man eine Kundennummer und eine Projektnummer, kann man sich mit
diesen Daten in die 2. Stufe des Systems einloggen. Hier werden die
projektbezogenen Dokumente mit Artikeln, Menge, Lieferdatum oder Lieferstatus
einsehbar. Weiters hat man natürlich Zugriff auf Produktdatenblätter oder
Bedienungsanleitungen. Der Zugang zu dieser Stufe soll allerdings zeitlich
begrenzt (auf 6 oder 12 Monate) sein und durch Administratoren verlänger- oder
sperrbar sein.
Spezifikation des Usecase:
Um die Grobanforderungen besser darzustellen wurde ein Usecase-Diagramm erstellt
(Abbildung 2, 3).
8
Abbildung 2: Usecasediagramm für Kunden und Datenquelle
9
Abbildung 3: Usecasediagramm für Administrator, Verwaltungssystem und Datenquelle
10
Das Usecase-Diagramm besteht aus 4 Akteuren: dem Benutzer, der Datenquelle, dem
Administrator und dem Verwaltungssystem.
Benutzer: Der Benutzer kann sich in 2 verschiedene Stufen einloggen. In der
ersten Stufe bekommt dieser eine Ansicht über aktuelle öffentliche Normen und
Datenblätter der Firma din und eine Menüleiste um sich durch die Software durch
navigieren zu können. Über diese Menüleiste kann der Benutzer in der ersten
Stufe nach Dokumenten suchen und sich in die zweite Stufe einloggen. Für das
Einloggen in die zweite Stufe wird eine Kundennummer und eine Projektnummer
benötigt. In der zweiten Stufe werden weitere Aktionen in der Menüliste
freigeschaltet. Zusätzlich zu der Dokumentenansicht wird eine Ansicht zu den
Daten des Kunden und des Projektes angezeigt. Weiters kann der Benutzer auf
die Daten seiner bestellten Produkte bezüglich des Projektes zugreifen.
Administrator: Der Administrator muss sich wie der Benutzer mit einem
spezifischen Passwort einloggen. Dieser hat die Möglichkeit den Zugang zu
Projekten zu sperren beziehungsweise ihn um eine bestimmte Zeit zu verlängern.
Außerdem kann der Administrator öffentliche Dokumente in die Datenquelle
hochladen beziehungsweise diese verstecken.
Datenquelle: Die Datenquelle ist ein ERP-System, welches bereits von der
Firma din erstellt wurde. Dieses beinhaltet alle Daten bezüglich der Kunden und
Projekte.
Verwaltungssystem: Über das Verwaltungssystem ist eine Schnittstelle
zwischen dem ERP-System und der Datenbank. Um den Administrationsaufwand
möglichst minimal zu halten soll als Schnittstelle zwischen dem ERP-System und
der Software ein Webservice erstellt werden. Mithilfe dessen lassen sich
Dokumente und Daten aus dem ERP-System in die Datenbank einspielen. Dazu
bietet der Webservice vier verschiedene Methoden an. Die Erste ermöglicht es
Daten eines Kunden und seiner Adresse in die Datenbank zu pushen. Die Zweite
speichert Daten eines Projektes und der dazugehörigen Adresse in der Datenbank
ab. Mittels der dritten Methode wird ein ERPDokument mittels einer schon
vorhandenen Kunden und Projektnummer erstellt und in die Datenbank
gespeichert. Die letzte Methode ermöglicht es ein Produkt für ein bestimmtes
ERPDokument zu pushen.
11
Spezifikation der Daten:
Da das Kundeninformationsportal die Daten aus dem ERP-System bekommt wurden
die Datenmodelle im vorhinein bereits festgelegt. Um diese besser veranschaulichen zu
können wurde ein UML-Diagramm der Daten erstellt:
Project
+ProjectID: int
+ProjectNumber: int
+LogicalObjectID: guid
+Denotation: string
+AddressID: int
+Description: string
+StartDate: datetime
+ExpireDate: datetime
ERPDocument
+ERPDocumentID: int
+CustomerNumber: int
+ProjectNumber: int
+ShippinAddressID: int
+BillingAddressID: int
+DinOfficialID: int
+ERPDocumentNumber: long
+CreationDate: datetime
+Denotation: string
+ERPDocumentType: string
Address
+AddressID: int
+FristName: string
+SecondName: string
+Street: string
+PostalCode: string
+City: string
+State: string
+PhoneNumber: string
+MailAddress: MailAdress
Position
+PositionID: int
+PositionNumber: string
+SubPositionNumber: string
+Unity: string
+ArticleDenotation1: string
+ArticleDenotation2: string
+Amount: int
+ArticleDescription: string
+ArticleNumber
+PositionInfo1: string
+PositionInfo2: string
+DeliveryDate: datetime
Customer
+CustomerID: int
+CustomerNumber: string
+LogicalObjectID: guid
+Denotation: string
+AddressID: int
Abbildung 4: UML-Daten
Kunden:
Kunden werden mit einer eindeutigen Nummer und Attributen, wie Name und
Adresse, im System gespeichert.
12
Projekte:
Projekte sind separat von den Kunden mit einer eindeutigen Nummer
gespeichert. Hierzu besitzen sie weitere Attribute, wie Startdatum, Lieferadresse,
Produktpositionen und andere.
Adressen:
Adressen werden von Kunden, Projekten und anderen Daten verwendet. Eine
Adresse besteht aus Namen, Straße, Ort, Land, Telefonnummer und
E-Mail-Adresse. Zugeordnet werden sie über eine eindeutige ID.
Positionen:
Eine Position beschreibt einen Eintrag in der Produktliste eines Projektes. Zu der
Position gehören Positionsnummern, Artikelnummer, Beschreibungen, Menge,
Einheit, ein Lieferdatum und weitere Informationen.
ERP Dokumente:
ERP Dokumente bilden im System den Container für eine
Kunden-Projekt-Beziehung. Dieses Dokument beinhaltet auch die Liste der
Positionen für das Projekt, sowie Liefer- und Rechnungsadressen.
13
6
Literatur
Im folgenden Kapitel werden verschiedene Konzepte zur Lösung unser Anforderungen
vorgestellt, miteinander verglichen und erklärt wieso wir uns für bestimmte Konzepte
entschieden haben.
Authentifizierung
Für die Authentifizierung gibt es verschiedene Konzepte um diese umzusetzen. Dabei
schauen wir uns genauer die Claim-based authentication [22], Form-based
authentication und Role-based authentication [6].
Claim-based Die Claim-based authentication ist ein
Authentifizierungsmechanismus, welches über ein externes System den Benutzer
nach seinen ’Claims’ befragt. Das Claim hierbei ist ein Stück Information,
welches eine Identität beschreibt(Bsp: E-mailadresse, Name, etc). Mehrere
Claims werden zusammen mit einer Signatur in einem Authenifikationstoken
gebündelt. Diese Tokens werden dem Benutzer ausgestellt nachdem dieser sich
auf dem Identity Provider angemeldet hat. Der Identity Provider überprüft die
Logindaten des Benutzers. Mit diesen Daten sammelt er die nötigen Claims
zusammen und formt ein Token welches zurück an den Benutzer gesendet wird.
Mit diesem Token bekommt der Benutzer Zugriff auf die Software.
Form-based Form-based authentication ist der üblichste Weg der
Authentifizierung für Webseiten. Dem Benutzer wird hierbei ein einfaches
Login-Fenster angezeigt in dem er seine Logindaten eingeben kann. Nachdem
dieser seine Daten abgesendet hat überprüft die Software seine Daten und schickt
dem Benutzer ein Cookie zurück. Das Cookie hierbei beinhaltet Informationen
zum Benutzer und einen Zeitstempel. Die Informationen werden benötigt um
gewisse Zugriffe für den Benutzer freischalten zu können. Der Zeitstempel
beinhaltet eine bestimmte Zeit nachdem der Cookie abläuft. Mit dem Cookie
kann sich der Benutzer über alle Seiten der Software bewegen ohne sich erneut
einloggen zu müssen.
Role-based Role-based authenication funktioniert ähnlich wie die Form-based
authentication. Jedoch werden die Benutzer hierbei nach dem Login in
verschiedene Rollen unterschieden. Hierbei wird beim Login ein Role Server
benötigt, welcher die verschiedenen Rollen verwaltet. Für den Login gibt es zwei
verschiedene Verfahren, den User-Pull und den Server-Pull. Bei dem User-Pull
wird dem Role Server bereits vom Client mitgeteilt welche Rolle dieser
einnehmen will. Bei dem Server-Pull werden die gesendeten Daten vom Client
überprüft und dieser wird dann einer Rolle zugewiesen.
Für unsere Software haben wir uns für die Form-based authenication entschieden. Da
wir unsere Software so kompakt wie möglich programmieren wollten haben wir uns
14
nicht für das Claim-based Konzept entschieden, da dieses einen weiteren Identity
Provider benötigt, welcher sämtliche Kunden-claims beinhaltet. Das Role-based
Konzept konnte aufgrund unseres Zwei-Stufen Logins nicht umgesetzt werden. Da für
die erste Stufe ein einmaliges Passwort für jeden Kunden benötigt wird können wir
diese nicht erkennen und in verschiedene Rollen aufteilen.
Webservice
Für unseren Webservice kamen zwei Framework in Frage. Die Web-API [11] oder WCF.
Web-API [8] Die ASP.NET Web API ist ein Framework, welches eine Plattform
zur Erstellung von REST-services bildet. Rest ist eine Ressourcen-getriebene
Architektur, welches Endpoints basierend auf den Objekten freilegt. RESTful
Services nutzen HTTP-Methoden(GET, POST, PUT, DELETE) um Daten
auszutauschen. Weiters unterstützt Web API das MVC-Muster und kann
Antworten des Services mittels JSON und XML formatieren. WEB API kann
verwendet werden wenn ein Service erstellt werden soll der alle HTTP
Funktionalitäten unterstützt und eine große Bandbreite an Benutzern vorhanden
ist.
WCF [7] WCF ist auch ein Framework von ASP.NET. Im Gegensatz zur Web
API wird jedoch eine Service-orientiertes Programm(SOAP) erstellt und ist ein
Aktions-getriebenes Modell. Dieser Service kann Daten asynchron zwischen
mehreren Endpoints schicken. Weiters können die verschickten Nachrichten als
einzelnen Zeichen oder ganzen Wörter als XML versendet werden. Für die
Kommunikation zwischen den Endpoints verwendet WCF das A-B-C Prinzip.
WCF kann verwendet werden um einen Service zu erstellen der spezielle
Szenarien unterstützt wie zum Beispiel eine Einweg-Kommunikation unterstützen
soll oder um TCP oder UDP unterstützen zu können.
Für unsere Software haben wir uns für das WCF Framework entschieden, da wir keine
große Bandbreite an Benutzern unterstützen müssen. Bei uns muss nur das
ERP-System Informationen in unsere Datenbank einspeisen. Außerdem brauchten wir
Aufgrund von Voraussetzungen der Firma din einen Service der das SOAP-Protokoll
unterstützt.
15
7
Technische Einführung
In diesem Kapitel wird auf die verwendeten Technologien unserer Software eingegangen.
Wie schon im Kapitel Anforderungen erwähnt soll das Projekt komplett mit
Technologien des Softwareherstellers Microsoft produziert werden. Für diesen Zweck
wurde die Software in der Entwicklungsumgebung Visual Studio 2013 [16] verwendet.
Programmiersprachen
Für unsere Software haben wir C# und HTML beziehungsweise Razor-Syntax für C#
verwendet. Die aktuelle Versionsnummer ist 5.0, welche auch in unserem Projekt
verwendet wurde. Um die Präsentationsschicht zu programmieren, haben wir auf Razor
und HTML zurückgegriffen. Razor ist ein Syntax für C#, um dynamische Webseiten
programmieren zu können, welche 2010 als Teil des ASP.NET MVC 3 Framework
veröffentlicht wurde. Zur Unterstützung von Razor haben wir HTML verwendet, um
Beispielsweise Tabellen genauer darzustellen. Zum Erstellen unserer Datenbank
beziehungsweise für Zugriffe auf unsere Datenbank haben wir Transact-SQL, welches
eine Erweiterung SQLs von Microsoft ist, verwendet.
7.1
Frameworks
Das Kundeninformationsportal baut auf dem .NET-Framework(siehe Abbildung 5) auf.
Dieses ist eine Sammlung von vielen Frameworks.
Abbildung 5: .NET-Framework Architektur [21]
16
Das Konzept(siehe Abbildung 6) der .NET-Plattform ist die Umsetzung des
Common-Language-Infrastructure-Standards (CLI). Dies ermöglicht es Programme mit
unterschiedlichen Programmiersprachen erstellen zu können. Weiters bietet es
Funktionen für Ausnahmenbehandlungen, Garbage Collection, Sicherheit und
Interoperabilität an. Microsoft implementiert CLI mithilfe von der Common Language
Runtime (CLR), welche als Laufzeitumgebung von .NET fungiert. Alle
.NET-Programme werden unter der Aufsicht von CLR ausgeführt, damit bestimmte
Eigenschaften und Verhalstensmuster in den Bereichen Speicherverwaltung, Sicherheit
und Ausnahmebehandlung zu garantieren. Weiters stellt CLR den JIT-Compiler für
den standardisierten Zwischencode, Common Intermediate Language (CIL), dar.
C# plugin code
VB.NET
plug-in
code
Compiler
Compiler
Common Intermediate
Language (CIL)
Common Laguage
Runtime
11001010100010101000
00101011101110101000
Abbildung 6: .NET-Plattform Konzept [1]
17
ASP.NET
Das ASP.NET-Framework baut auf dem .NET-Framework auf und wird verwendet
zum Erstellen von dynamischer Webseiten. Das Framework baut auf einer
HTTP-Laufzeitumgebung auf, welche HTTP-Anfragen bearbeiten kann. ASP.NET
Webseiten werden als Code auf dem Server ausgeführt und arbeiten nach einem
bestimmten Verarbeitungszyklus:
1. Der Benutzer fordert eine Seite, mittels HTTP-GET an. Falls die Seite zum
ersten Mal aufgerufen wird führt diese eine Vorverarbeitung aus.
2. Für den Benutzer erscheint seine angeforderte Seite, im Hintergrund wird diese
dynamisch im Browser gerendert.
3. Der Benutzer kann nun Buttons betätigen oder Informationen eingeben.
4. Die Seite wird, mitels HTTP-POST an den Webserver gesendet. Dies wird in
ASP.NET als Postback bezeichnet und bei diesem wird die Seite an sich selbst
zurückgesendet.
5. Auf dem Server wird die Seite dadurch erneut ausgeführt und die Informationen,
des Benutzers stehen der Seite nun zur Verfügung.
6. Die Seite führt nun die Verarbeitung aus und wird wieder im Browser dargestellt.
Für die Realisierung einer Webseite bietet ASP.NET vier verschiedene Konzepte, Web
Forms, MVC, WebAPI und SignalR an. WebAPI ist hierbei eine weitere Variante von
ASP.NET MVc und ermöglicht es mit REST zu arbeiten. Durch die Verwendung von
Formen wie JSON, XML und OData beziehungsweise von JavaScript ermöglicht es dies
dynamische Rich-Client-Webseiten zu erstellen. SignalR überträgt Daten mithilfe von
von HTML5 WebSockets zwischen Client und Server. SignalR wird darum oft für
Echtzeitanwendungen wie zum Beispiel Chats verwendet. Die zwei großen Teile des
ASP.NET bilden die WebForms und das MVC.
WebForms WebForms bietet an komplette Webseiten entwickeln zu können,
ohne eine Zeile Code schreiben zu müssen. Der Entwickler kann so mit
Drag-and-Drop schon fertiggestellte Steuerelemente auf der Webseite platzieren.
Die fertigen Elemente beinhalten bereits sämtliche Funktionalitäten inklusive Der
Kompatibilität zu verschiedenen Browsern. Jedoch gibt es zu einfachen
Entwicklung mittels WebForms auch Nachteile. Das Event gesteuerte Verhalten
der Seiten haben einen sehr komplexen Lebenszyklus (Page-Life-Cycle). Damit
die Events mit den gesteuerten Controlls funktionieren, gibt es im Hintergrund
einen ViewState. Dieser ViewState speichert sämtliche Zustände und Daten der
18
Steuerelemente einer Seite. Dies ergibt einen enormen Speicherumfang. Da diese
Werte bei dem HTTP-Response zurück zum Client geschickt werden müssen, hat
die Dateigröße Auswirkungen auf die Ladezeiten der Webseite.
MVC ASP.NET MVC bietet an Webseiten möglichst flexibel und schnell
Zugreifbar zu entwickeln. Wie schon der Name MVC besagt baut dieses Konzept
auf dem MVC-Muster auf. Durch die Trennung von Steuerelementen und der
View lassen sich diese flexibler entwickeln und sind so geeigneter für ein größeres
Entwicklungsteam. Im Gegensatz zu den WebForms wird für die Kommunikation
zwischen dem Server und dem Client HTTP-Methoden wie GET und POST
verwendet(siehe Abbildung 7). Durch diese Kommunikation wird der ViewState
überflüssig und der Entwickler kann sich selber um alle Zustände der Seite
kümmern.
Routing
REQUEST
Auth
Controller
CLIENT
Model
View
RESPONSE
Abbildung 7: ASP.NET MVC Request-Response [9]
19
– Request: Der Benutzer ruft eine Webseite auf.
– Routing: Der Request wird vom Server and den entsprechenden Controller
weitergeleitet und führt das gewünschte Event aus.
– Auth: Überprüft ob der Benutzer über die benötigten Rechte besitzt.
– Controller: Der Controller führt das Event aus indem die gewünschte
Methode ausgeführt wird. Aus Daten der angebundenen Datenbank und der
Anfrage erstellt der Controller ein Model.
– Model: Das erstellte Model wird vom Controller and die View
weitergereicht.
– View: In der View werden anschließend die Daten aus dem erstellten Model
dargestellt.
– Response: Der Response ist die Anzeige der neuen View für den Client.
Dieser wird vom Server zum Benutzer geschickt.
Da wir die Vorteile bei dem ASP.NET MVC 4 höher eingestuft haben als bei den
WebForms haben wir uns für dieses Konzept des ASP.NET Frameworks entschieden.
Ext.NET
Unsere Präsentationsschicht wurde mit dem Ext.NET Framework entwickelt. Das
Ext.NET Framework [12] bietet bereits vorgefertigte Elemente an, welche man für die
View verwenden kann. Die einzelnen Elemente können einfach über verschiedene
Sprachen aufgerufen und implementiert werden.
Razor-Engine
Für die Implementierung der Ext.NET-Elemente wurde die Razor-Engine verwendet.
Razor wurde für die HTML-Programmierung optimiert und hat darum einige Vorteile:
Kompakt Durch die Programmierung mit HTML muss in Razor der Code nicht
unterbrochen werden, um HTML-Blöcke einzufügen. Der Parser erkennt diese
sofort und kann diese verarbeiten. Dies ermöglicht es möglichst kurzen und
sauberen Code für die View zu programmieren.
Funktioniert mit jedem Texteditor Razor benötigt keine weiteren
Programme und lässt sich einfach in einem Texteditor bearbeiten.
Testbarkeit Razor bietet ohne einen Controller oder Web-Server erstellen zu
müssen Unit-Tests an.
20
7.2
Datenbank
Für die Speicherung der Daten haben wir eine Datenbank in Microsoft SQL-Server
2012 erstellt. Diese Datenbank stellt eine Relationales Datenbankmodell dar. Für
Testzwecke und aus Mangel eines Servers haben wir unsere Datenbank lokal über den
localhost gehostet.
7.3
NHibernate
Für die Verbindung zwischen der Datenbank und unserer Software haben wir
NHibernate verwendet. NHibernate ist eine Persistence-Engine in Form eines
Frameworks um Datenmodelle in relationale Datenbanken zu speichern beziehungsweise
Datenmodelle aus den Datensätzen der Datenbank zu erzeugen (siehe Abbildung 8).
Application
Persistent objects
NHibernate
XML
mappings
App.config
Data Base
Abbildung 8: Architektur des NHibernate [17]
Mittels eines OR-Mappers werden die Datenmodelle (persistent objects) und
XML-Mappingdatein auf die Datenbank gemappt. Um unsere Datenmodelle auf die
Datenbank zu mappen müssen wir zu jedem Datenmodell eine .xml-Datei erstellen.
21
Zusätzlich zu den xml.-Dateien muss eine hibernate.xml-Datei, welche die
Konfigurationsdatei unserer Session ist,erzeugt werden.
<?xml version=” 1 . 0 ” e n c o d i n g=” u t f −8” ?>
<h i b e r n a t e −c o n f i g u r a t i o n xmlns=” u r n : n h i b e r n a t e −c o n f i g u r a t i o n
−2.2 ”>
<s e s s i o n −f a c t o r y>

NHibernate . Connection . D r i v e r C o n n e c t i o n P r o v i d e r


NHibernate . D r i v e r . S q l C l i e n t D r i v e r


Data S o u r c e =(LocalDb ) \ v11 . 0 ; I n i t i a l C a t a l o g=CIP ;
I n t e g r a t e d S e c u r i t y=t r u e ;


NHibernate . D i a l e c t . M s S q l 2 0 1 2 D i a l e c t

</ s e s s i o n −f a c t o r y>
</ h i b e r n a t e −c o n f i g u r a t i o n>
Diese Datei beinhaltet die Konfiguration der Datenbankverbindung. Wie schon in den
Datenmodell-XML-Dateien muss am Anfang die Versionsnummer des
Mappingverfahrens angegeben werden. Weiters muss ein ConnectionProvider, ein
ConnectionDriver, ein ConnectionString und ein Dialect angegeben werden:
Der ConnectionProvider ist der Anbieter der Verbindung. Standardmäßig bei
NHibernate: NHibernate.Connection.DriverConnectionProvider.
Der ConnectionDriver gibt an welcher Treiber verwendet werden soll. In
unserem Fall der Treiber für SQL-Datenbanken (SqlClientDriver).
Der ConnectionString ist der Verbindungspfad zur Datenbank. Da wir unsere
Datenbank auf Localhost (siehe Kapitel DB) laufen lassen ist der Parameter
Data Source auf LocalDB gesetzt. Zusätzlich muss noch der Datenbankname
angegeben werden und falls vorhanden die Logindaten zur Authentifizierung.
Der Parameter Dialect ist bei uns auf MSql2012Dialect gesetzt und gibt an
welche Datenbanksprache für die Datenbank verwendet wird.
Damit eine Datenbankverbindung geöffnet werden kann wird eine Klasse erstellt in
unserem Fall NHibernateSession, welche eine Methode zum Öffnen der Sitzung zur
Verfügung stellt. In unserer Methode OpenSession() wird ein Mappingpfad angelegt,
welcher die hibernate.xml und die Datenmodell-XML-Dateien zusammenfasst und
22
beinhaltet. Diese Methode wird später für die Steuerungsschicht benötigt, damit diese
auf die Datenbank zugreifen kann. Nach dem Öffnen der Verbindung können mittels
SQL Befehle auf der Datenbank ausgeführt werden. Die Befehle werden auf der
Datenbank ausgeführt und verarbeitet. Anschließend wird das Ergebnis gemappt und
an die Steuerungsschicht zurückgeschickt.
7.4
Webservice WCF
Damit die Firma din Daten aus ihrem ERP-System in unsere Datenbank pushen kann
wurde ein Webservice, mithilfe von WCF entwickelt [7]. Windows Communication
Foundation wurde von Microsoft für verteilte Anwendungen entwickelt. Sie ist eine
dienst-orientierte Kommunikationsplattform und ist ein Bestandteil des .NET
Frameworks. WCF bietet eine Reihe von Funktionen an. Die wichitgesten werden nun
im folgenden Teil erklärt:
Dienstausrichtung Durch die Verwendung von WS-Standards ist es möglich,
mit WCF dienstorientierte Anwendungen zu erstellen. Der Vorteil in der
dienstorientierten Architektur ist, dass die Anwendungen untereinander lose
verknüpft sind und nicht hartcodiert programmiert werden müssen. So kann ein
beliebiger Client auf einen beliebigen Dienst verbunden werden, solange die
wesentlichen Voraussetzungen gegeben sind.
Interoperabilität Aktuelle Standards für Webdienstinteroperabilität sind in
WCF gegeben.
Mehrere Nachrichtenmuster Nachrichten können in verschiedenen Mustern
ausgetauscht werden. Das Standard-Muster ist das Request-Answer-Muster, bei
dem ein Endpunkt Daten von einem zweiten Endpunkt abfragt. Ein etwas
komplexeres Muster ist das Duplex-Nachrichtenaustauschmuster, bei dem zwei
Endpunkte eine Verbindung zueinander aufbauen und dann gegenseitig Daten
senden.
Dienstmetadaten WCF unterstützt weiters die Standards von Formaten wie
zum Beispiel WSDL, XML. Diese Metadaten können verwendet werden, um
automatisch Clients für die Verbindung zu WCF-Service zu generieren und
konfigurieren. Metadaten können mittel HTTP oder HTTPS veröffentlicht
werden.
Datenverträge WCF enthält ein umfassendes System, welches die Arbeit mit
Daten vereinfacht. Der einfachste Weg zur Verwaltung ist die Erstellung von
Klassen, welche eine Datenentiät darstellen. Nachdem diese Klassen erstellt
wurden, werden vom Dienst automatisch Metadaten bezüglich der Klassen
erstellt.
Sicherheit WCF bietet an Nachrichten zu kodieren oder Benutzer, bevor Sie
Berechtigung zum Empfangen und Senden bekommen, sich einloggen zu müssen.
Sicherheit kann zum Beispiel mithilfe von SSL verwirklicht werden.
23
Mehrere Transporte und Codierungen Nachrichten können in WCF auf
eine oder mehrere Protokolle und Kodierungen gesendet werden. Standardmäßig
werden Nachrichten unter Verwendung des Hypertext Transfer Protocol (HTTP)
versendet.
Erweiterbarkeit Die WCF-Architektur kann über mehre Punkte erweitert
werden, damit der Dienst wunschgemäß läuft.
WCF kann Daten mittels asynchronen Nachrichten von einem Service Endpunkt zu
einem anderen schicken. Ein Service Endpunkt kann ein Service von IIS oder ein
Service einer Anwendung sein. WCF hat eine eigenes Prinzip (siehe Abbildung 10) für
das Konzept der Endpunkte:
Abbildung 9: ABC-Prinzip von WCF [18]
A - Address Die Adresse ist eine eindeutiger Identifier für einen WCF-Service.
Dieser teilt dem Client mit wo der Service ist und wohin die Nachricht geschickt
werden soll.
B - Binding Die Bindung beschreibt die Art der Kommunikation welche der
Client zur Kommunikation mit dem Endpunkt benötigt. Es wird das
Transportprotokoll und die Art der Codierung angegeben.
C - Contract Der Vertrag definiert die Funktionalität des Services. Falls
notwendig, muss für benutzerdefinierte Datentypen ein DataContract erstellt
werden.
Für das Versenden von Daten ist die WCF-Architektur in 2 Grundschichten unterteilt.
Der Service Layer definiert die Mechanismen und Attribute um die Nachrichten- und
Datenverträge definieren zu können. Die Nachrichtenschicht ist für die Herstellung und
Übertragung einer WCF-Nachricht zuständig. Dies geschieht mithilfe eines
Channelstacks. Dieser Stack ist eine Pipeline von Komponenten mit verschiedenen
Aufgaben. Jeder Channelstack ist genau aus einem Transportchannel, einem
24
Nachrichtencodierer und null oder mehrere Protokollkanälen zusammengesetzt. Auf der
Benutzerseite ist es die Aufgabe der Proxykomponente und auf der Serviceseite der
Dispatcherkomponente die zwei Schichten unterscheiden zu können und die
empfangenen Daten zu verarbeiten.
Service Layer
Client
Service
Objects/Entities
Objects/Entities
Proxy
Dispatcher
WCF Message
Messaging Layer
WCF Message
Protocol
Protocol
Encoder
Encoder
Transport
Raw Message
Abbildung 10: Messaging Runtime [18]
25
Transport
8
Konzepte
In diesem Kapitel werden die Konzepte unserer entwickelten Software beschrieben. Wie
schon in dem Kapitel Anforderungen (siehe Abbildung 5) beschrieben soll das System
ein 2 Stufen-Modell mit möglichst wenig Administrationsaufwand realisieren.
8.1
Architektur
VIEW
SecondStep
Home (All Steps)
Home
AccountMgmt
1
Windows
Products
Login
1
Menu
CONTROLLER
CIPController
ViewController
Auth-Controller
LoginC.
PositionC.
ERPDocumentC.
CustomerC.
FileCon
AddressC.
CustomAuth
ProjectC.
CookieStore
MODEL
Modelclasses
NHibernate
ERPDocument
FileType
1
NHibConf
1
0..*
Position
1
Customer
1
1 1
1
Address
11
Project
1
File
XML-Mappings
Abbildung 11: Klassendiagramm MVC
Unsere Software baut auf dem MVC-Muster des ASP.NET MVC auf. Die Trennung
dieser drei Schichten hat es uns ermöglicht gleichzeitig an den Schichten zu arbeiten
ohne auf größere Komplikationen zu treffen. Für die visuelle Abtrennung der Schichten
im Projektfolder haben wir diese in Ordner unterteilt. (siehe Abbildung 11)
26
Model In dem Ordner Model haben wir unsere Datenmodellklassen angelegt
(siehe Kapitel Anforderungen 5). Zusätzlich zu den bereits vorhandenen
Datenmodellen haben wir zwei weitere Datenmodelle File und FileType
hinzugefügt. Diese werden genauer im nächsten Kapitel 9.1 erklärt. Weiters ist
die NHibernatekonfiguration und die XML-Mappingklassen des Systems hier
abgespeichert.
Controller Die Controllerschicht ist in unserem System in zwei Teile geteilt
worden. Diese zwei Teile des Controllers werden vom Hauptcontroller
CIPController gesteuert. Dieser übernimmt die Verwaltung und Verteilung der
Aufgaben, welche von der View gestellt werden. Weiters bildet diese Klasse eine
Verbindung zwischen den zwei großen Aufgabenbereiche. Der Ordner
ViewController beinhaltet alle Controller der Modellklassen und bildet so mit
eine Verbindung zwischen den Daten und der View. In diesen Klassen werden
Daten aus dem Model für die View auf bearbeitet. Um dies zu verwirklichen
haben auch alle Controllerklassen innerhalb des ViewController Zugriff auf die
NHibernate-Verbindung im Ordner Model. So kann eine NHibernate-Session
gestartet werden und Daten über das Model und der dazugehörigen
XML-Mappingklasse aus der Datenbank ausgelesen werden. Zusätzlich zu den
Controllerklassen des Models befindet sich der LoginController. Der
LoginController überprüft ebenfalls mittels einer NHibernateverbindung das
eingebene Passwort beziehungsweise für die zweite Stufe die Kundennummer und
Projektnummer. Über den CIPController bekommen die Klassen im Ordner
Auth-Controller mittegeteilt, dass sich ein Benutzer in eine bestimmte Stufe
eingeloggt hat. Die zwei Klassen im Auth-Controller steuern den aktuellen
Loginstatus des Benutzers und passen je nach Einlogstufe das Menu in der View
an. Dies geschieht über Cookies. Für jede Einlogstufe gibt es einen eigenen
Cookie. Je nach Cookie wird dem CIPController vom Auth-Controller mitgeteilt
in welcher Stufe sich der Benutzer momentan befindet.
View In diesem Ordner haben wir unsere Elemente der grafischen
Benutzeroberfläche abgespeichert. Wenn die Seite aufgerufen wird ohne, dass ein
Benutzer sich bereits eingeloggt hat wird dieser zum Login weitergeleitet.
Nachdem Login befindet sich der Benutzer in der Homeview. Die Homeview
besitzt ein Menü, über welches der Benutzer navigieren kann. Durch Buttonklicks
im Menü kann der Benutzer verschiedenste Windows öffnen. Falls sich der
Benutzer in die zweite Stufe einloggt wird zusätzlich zur Homeview AccountMgmt
und Products freigeschaltet. Über diese zusätzlichen Views kann sich der
Benutzer seine Daten bezüglich seines Projektes und seiner Produkte holen.
Außerdem werden wie schon im Controller erwähnt über den Auth-Controller
zusätzliche Menüpunkte freigeschaltet.
27
8.2
Authentifizierung
Da wir in unserem System mehrstufige Authentifizierung realisieren mussten, konnten
wir nicht das von ASP.NET vorhergesehene Forms Authentication verwenden. Jedoch
haben wir uns an diesem Konzept orientiert und uns entschieden das 2-Stufen-Modell
mittels Cookies zu entwickeln. Wie schon früher erwähnt soll die erste Stufe mit einem
einmaligen Passwort erreichbar sein. Die zweite Stufe soll über die Eingabe einer
gültigen Kundennummer und einer gültigen Projektnummer erreichbar sein. Zusätzlich
zum 2-Stufen-Login soll sich ein Administrator einloggen können. Damit unsere
Software weiß, wann beziehungsweise wer sich eingeloggt hat, verwenden wir Cookies.
In unserem System wird jedes mal bei Laden der Webseite das Cookie des Benutzers
überprüft. Je nachdem, welches Cookie an den Server geschickt wird werden Elemente
entsprechend der eingeloggten Stufe an der View für den Benutzer dargestellt.
Cookies [13]
Cookies sind kleine Textdateien für benutzerspezifische Informationen. Sie enthalten
meist Daten über besuchte Webseiten. Weiters ist es möglich mittels Cookies den
Zugriff zu verschlüsselten Seiten zu merken. Dies funktioniert über einen vorgegebenen
Zeitraum und am selben Rechner, da die Cookies lokal abgespeichert werden. Für
unsere Software haben wir HTTP-Cookies verwendet, welche mittels des
HTTP-Protokolls kommunizieren (siehe Abbildung 12). Unser Client schickt einen
HTTP-Request für die angeforderte Webseite an den Server. Der Server antwortet mit
einem HTTP-Response, welcher die angeforderte Webseite und ein Cookie für die
aktuelle Session beinhaltet. Solange der Client über einen Cookie verfügt schickt er bei
weiteren Anfragen an den Server sein Cookie mit. Der Server muss dann nur noch mit
der angeforderte Webseite antworten.
HTTP Request
HTTP Response + Set-Cookie
Web Client
HTTP Request + Cookie
Web Server
HTTP Response
Abbildung 12: Ablauf einer Anfrage mittels eines HTTP-Cookies [20]
28
Für unsere Software haben wir 3 HTTP-Cookies erstellt:
Cookie für 1. Stufe: Der Cookie für die erste Stufe ist wie folgt aufgebaut:
Name: CIP
Wert: 1.Stufe(verschlüsselt)
Zeitspanne: 30 Minuten
Dieser Cookie wird nach dem Login in die 1. Stufe gesetzt und kann über den
Name ’CIP’ angesprochen werden. Im Wert des Cookies steht ein mittels
MD5Hash verschlüsselter Wert für die erste Stufe. Die Zeit bis zum Ablauf des
Cookies beträgt 30 Minuten und wird bei jedem Refresh der Seite wieder bei 30
Minuten gestartet.
Cookie für Administrator: Der Cookie für die Administration-Stufe ist wie
folgt aufgebaut:
Name: CIP
Wert: AdminStufe(verschlüsselt)
Zeitspanne: 30 Minuten
Dieser Cookie wird nach dem Login in die Administration-Stufe gesetzt und kann
über den Name ’CIP’ angesprochen werden. Im Wert des Cookies steht ein
mittels MD5Hash verschlüsselter Wert für die Administrationsstufe. Die Zeit bis
zum Ablauf des Cookies funktioniert gleich wie beim Cookie für die 1. Stufe.
Cookie für Administrator: Der Cookie für die 2. Stufe ist wie folgt aufgebaut:
Name: CIP
Wert: C:KundennummerP:Projektnummer
Zeitspanne: 30 Minuten
Dieser Cookie wird nach dem Login in die 2. Stufe gesetzt und kann über den
Name ’CIP’ angesprochen werden. Im Wert des Cookies steht
’C:KundennummerP:Projektnummer’. Die Kundennummer und die
Projektnummer sind die verwendeten Logindaten des Benutzers um in die 2.
Stufe zu kommen. Die Zeit bis zum Ablauf des Cookies funktioniert gleich wie
beim Cookie für die 1. Stufe.
8.3
Abarbeitung Benutzereingaben
In unserer Software hat der Benutzer mehrere Möglichkeiten Informationen mittels
einer Eingabe abzufragen. Wie schon im Kapitel Architektur 8.1 erwähnt haben wir für
die Verbindung von unserer Software zur Datenbank NHibernate verwendet um diese
Informationen zu bekommen. Dazu wurde in unserer Software die nötigen
Mappingklassen und eine Sessionklasse, welche die Session öffnet an angelegt. Im
folgenden Abschnitt der Abbildung wird ein Prozessablauf einer Benutzeranfrage
dargestellt (siehe Abbildung 13).
1. Der Benutzer betätigt eine Eingabe in der View, entweder über einen Button
oder durch Einfügen von Text.
29
Benutzereingabe
Eingabe an Dienst schicken
Session
offen?
NEIN
Session öffnen
JA
SQLQuery ausführen
Antwort zurückschicken (HTTP)
Daten auf Datenmodell casten
Daten ausgeben
Abbildung 13: Ablauf Benutzeranfrage
2. Die Eingabe wird anschließend an die dementsprechende Methode des Controllers
weitergeleitet.
3. Bevor der Controller auf die Daten der Datenbank zugreifen kann muss ene
NHibernate-Session geöffnet werden, falls diese noch nicht existiert.
4. Anschließend wird mittels SQLQueries auf die Datenbank zugegriffen.
5. Der Controller empfängt das Resultat der SQL-Anfragen als Liste von Objecten.
6. Die empfangenen Daten werden auf die Datentypen des gewünschte
Datenmodells gecastet.
7. Diese Daten werden zum Schluss an die View geschickt und dort dem Benutzer
präsentiert.
30
8.4
Webservice
Damit Daten aus dem ERP-System in die Datenbank eingespeist werden können
wurde ein Webservice entwickelt. Wie schon bei unserer Software arbeitet der
Webservice mit dem NHibernate Framework um eine Verbindung zur Datenbank
aufzubauen. Der Webservice selbst wurde mittels WCF entwickelt.
Eingabe der Daten
Eingabe an Dienst schicken (HTTP)
Session
offen?
NEIN
Session öffnen
JA
SQLQuery ausführen
Antwort zurückschicken (HTTP)
Abbildung 14: Ablauf WCF
Um die kompletten Daten aus dem ERPSystem in die Datenbank übertragen zu
können haben wir vier verschiedene Methoden erstellt. Diese Methoden erlauben es
Daten eines Kunden, eines Projektes, eines ERPDokuments oder eines Produktes
abzuspeichern. Dazu werden die Daten eines Modells an mittels HTTP an den Dienst
geschickt. Dieser öffnet gleich wie bei der Benutzeranfrage eine NHibernate-Session und
pusht mittels SQL-Befehlen die empfangen Daten in die Datenbank. Je nachdem ob die
Daten ohne Fehler in die Datenbank eingespeist wurden schickt der Webservice einen
HTTP-Response mit Erfolg oder Misserfolg an den Benutzer.
31
9
Technische Details
In diesem Kapitel wird genau erklärt wie wir die Konzepte und Technologien in unserer
Software implementiert haben. Wie schon in dem Kapitel Konzepte 8 erklärt haben wir
unser System nach dem MVC-Muster aufgebaut. Die einzelnen Umsetzungen der
Elemente des MVC-Musters unseres Programmes werden nun in Unterkapiteln erklärt.
9.1
Model
Das Datenmodell wurde bereits schon genauer im Kapitel Anforderungen 5 definiert.
Wie schon erwähnt beinhaltet das Model die Strukturen der Daten unserer Software.
Zusätzlich zu den bereits vorhandenen Datenmodellen haben wir zwei weitere Models
(siehe Abbildung 15) programmiert um die Normen und Datenblätter abspeichern zu
können.
File
+FileID: int
+FileTypeID: int
+Name: string
+Path: string
+Denotation: string
+CreationDate: DateTime
+Hidden: bool
FileType
+FileTypeID: int
+Name: string
Abbildung 15: File - Datenmodell
File:Dieses Modell stellt ein Dokument wie zum Beispiel eine Norm dar. Mithilfe
des FileTypeID wird eine Beziehung zum FileType-Modell hergestellt und durch
verbinden beider Modelle kann der Filetyp ausgelesen werden. Im Attribut Path
wird der relative Pfad für den Speicherort des Dokumentes abgespeichert. Die
Flag Hidden ermöglicht es Dokumente, welche nicht mehr relevant sind, zu
32
verstecken. Das File-Modell verfügt weiters über eine innere Klasse, welche das
Attribut FileTypeID mit FileTypeName[string] ersetzt und eine
GetFullModel()-Methode anbietet. Diese Methode wird von der View benötigt
um die Ausgabe exakt an das Modell anpassen zu können.
FileType: Dieses Modell liefert dem File-Modell den Namen des
Dokumententyps nachdem dieses mithilfe der FileTypeID gejoined wurde.
Weiters bietet die Klasse zwei Methoden an: GetInt(string text) und
GetString(string number). Beide Methoden sind public static.GetInt(string text)
liefert die FileTypeID mithilfe des Dokumentennamen. GetString(string number)
liefert mithilfe des Dokumentennamen die FileTypeID. Diese Methoden benötigt
wiederum für die Präsentationsschicht benötigt.
9.2
Controller und View
Die Steuerungsschicht beziehungsweise der Controller ist zuständig für den
Datentransfer zwischen der Datenmodellschicht und der Präsentationsschicht. Der
Controller bekommt von der Präsentationsschicht eine Benutzereingabe und leitet diese
weiter an das Datenmodell. Dieses schickt die angeforderten Rohdaten an den
Controller. Anschließend werden diese Daten, dann an die Anforderungen der
Benutzereingabe angepasst und berechnet. Nach diesem Arbeitsschritt werden die
Enddaten in der View ausgegeben. Die Steuerungsschicht unserer Software ist in zwei
Teile aufgeteilt: die Steuerung der Authentifizierung und die Steuerung der
Präsentationsschicht.
Steuerung der Authentifizierung
Wie schon im Konzept beschrieben verfügt unser Webportal über ein 2-Stufen-Modell.
Die erste Stufe soll mit einem einmaligen Passwort erreichbar sein. Die zweite Stufe soll
über die Eingabe einer gültigen Kundennummer und einer gültigen Projektnummer
erreichbar sein. Zusätzlich zum 2-Stufen-Login soll sich ein Administrator einloggen
können. Damit unsere Software weiß, wann beziehungsweise wer sich eingeloggt hat,
verwenden wir Cookies. Der Aufbau der Cookies wurde bereits früher erklärt (siehe
Kapitel 8). Die Verwaltung dieser Cookies übernehmen bei uns die Controllerklassen
CustomAuthorization und CookieStore. Der CookieStore verfügt über drei Methoden.
SetCookie legt einen neuen Cookie an, dabei bekommt diese Methode die Daten über
den momentanen Status des Benutzers. Dieser Status wird benötigt damit die Methode
weiß in welcher Stufe der Benutzer sich gerade befindet. Die weiteren zwei Methoden
liefern entweder den momentanen Cookie zurück oder löschen den Cookie. Um einen
Cookie zu löschen wird der Zeitstempel zum Ablauf des Cookies auf die jetzige Zeit
minus einer Sekunde gesetzt. Dieser läuft damit automatisch ab und wird gelöscht.
33
Die Klasse CustomAuthorization(siehe Abbildung 16) ist die eigentliche Verwaltung
der Authenifizierung.
CustomAuthorization
+CalculateMD5Hash()
+ChangeUserPassword()
+CheckPermission()
+CustomerNumberFromCookie()
-PasswordFromDB()
+ProjectNumberFromCookie()
+RemoveCookie()
+SetPermission()
+SetPermissionStep1()
+ShowMenu()
+StepByCookie()
Abbildung 16: Klasse - CustomAuthorization
CalculateMD5Hash wird benötigt um die Daten der Cookies mittels
MD5Hash zu verschlüsseln.
ChangeUserPassword greift mittels einer NHibernateSession auf die
Datenbank zu. Mit SQL-Befehlen wird das alte Passwort mit dem Neuen an der
Datenbank ersetzt.
SetPermission und SetPermissionStep1 setzen die Rechte der Benuzter für die
verschiedenen Stufen des Portals.
CheckPermission überprüft die Berechtigungen der Benutzer. Dazu wird das
momentane Cookie ausgelesen und ermittelt in welcher Stufe sich der Benutzer
befindet. Je nachdem ob der Benutzer über die nötigen Rechte verfügt antwortet
diese Methode postiv oder negativ(bool).
ShowMenu steuert das Menü in der Präsentationsschicht (siehe Steuerung der
Präsentationsschicht). Dazu werden die einzelnen Menüelemente je nach Stufe
freigeschaltet oder ausgeschaltet.
Restlichen Methoden: Die restlichen Methoden werden in den oben genannten
Methoden benötigt um bestimmte Sachen, wie zum Beispiel die Kundennummer
aus dem Cookie lesen zu können.
34
Präsentationsschicht und ihre Steuerung
In diesem Kapitel wird die Präsentationsschicht und ihre Steuerung unserer Software
erklärt. Die Präsentationsschicht ist zur grafischen Ausgabe für den Benutzer
zuständig. Unsere Präsentationsschicht wurde mit der Razor-Engine entwickelt. Für
unsere Software haben wir einige vordefinierte Container, Layouts und Elemente [14]
aus dem Razor-Framework zur Darstellung der View verwendet.
Da in unserer Software die Präsentationsschicht eng mit der Steuerungsschicht
zusammenarbeitet, werden im folgenden Teil die einzelnen Ansichten und Fenster der
Präsentationsschicht erklärt, wie diese aufgebaut sind und wie diese gesteuert werden.
Loginfenster
Das Loginfenster (siehe Abbildung 17) ist der Startpunkt unserer Software und ist über
die URL ’url/CIP/’ erreichbar. Der Benutzer wird automatisch auf diese Seite
weitergeleitet, falls Dieser sich noch nicht eingeloggt hat oder die Sitzung ausgelaufen
ist.
Abbildung 17: Screenshot - Loginfenster
Als Container wird ein Viewport verwendet. Das Layout ist eine VBox und beinhaltet
zwei Elemente. Das erste ist ein Textfield welches das Eingabetextfenster für das
Passwort ist. Das zweite Element ist der Button mit dem der Benutzer den
Einlogprozess triggert. Nachdem der Button gedrückt wurde bekommt der
CIPController die Meldung, dass der Einlog-Button aufgerufen wurde. Dieser ruft
dann den dazugehörige Controller LoginController auf und startet diesen. Im
LoginController wird das Passwort mittels der in dem Kapitel Steuerung der
Authentifizierung beschriebenen Methode SetPermission() geprüft ob das gültige
Passwort eingegeben wurde. Bei Erfolg wird ein Cookie gesetzt und die Startseite
entweder der ersten Stufe oder des Administrators angezeigt.
35
Login
CIPController
LoginController
Auth-Controller
Abbildung 18: UMLKlassendiagram - Loginfenster
1. Stufe
Die Startseite (siehe Abbildung 19) ist der Ausgangspunkt für die erste Stufe und wird
über die URL ’url/Home/ erreicht. Diese Seite zeigt die aktuellen Dokumente der
Firma din an.
Abbildung 19: Screenshot - Erste Stufe
Da diese Ansicht die Daten des Datenmodells File anzeigt, wurde als Container ein
GridPanel verwendet, welches eine Tabelle für die verschiedenen Dokumente erstellt.
Als Layout wurde ’Fit’ verwendet, da die Liste der Dokumente dynamisch verändert
werden kann. Das Layout beinhaltet ein ColumnModel-Element. Mithilfe des Namens
36
der Dokumente werden die Daten aus dem Datenmodell File über den Controller
FileController ausgelesen und in das GridPanel eingefügt. Durch ein Plugin für das
ColumnModel-Element lassen sich Dokumente auf/einklappen um Informationen und
den Downloadlink anzuzeigen. Der Downloadlink wurde mittels HTML eingefügt und
bei Klick auf diesen wird das Dokument auf den lokalen Rechner geladen. Über dem
GridPanel am oberen Rand der Seite wurde der Container Toolbar verwendet, welche
eine Menüleiste darstellt. In der Menüleiste sind vier Buttons aufgelistet:
Home
Login
Windows
Menu
CIPController
FileController
Auth-Controller
LoginController
Abbildung 20: UMLKlassendiagram - Erste Stufe
Button: Start Der Button Start ruft die Startseite der ersten Stufe auf.
Button: Normen Der Button Normen hat zwei Menüpunkte:
Der erste öffnet einen Container Window, in dem nach Dokumenten gesucht
werden kann. In diesem Fenster wird ein FormPanel verwendet, um die Filter der
Suche anzeigen zu können. Der erste Filter ist der Dateiname und ist als
Textfield-Element dargestellt. Hier kann der Benutzer nach dem vollständigen
Dateinamen oder nur einem Teil des Dateinamens suchen. Der zweite Filter ist
eine ComboBox welche die verschiedenen Dokumenttypen aus dem Datenmodell
FileType anzeigt. Der dritte und vierte Filter sind Datefields, mithilfe derer ein
Zeitraum des Erstelldatums eingestellt werden kann. Am unteren Ende des
Fensters befinden sich zwei Buttons. Der Erste löscht alle Eingaben in den
Filtern. Der Zweite triggert die Suche und den Controller CIPController. Dieser
leitet die Aufgabe weiter an den Controller FileController. In dem wird ein
SQL-Befehl für die Suche erstellt. Je nachdem welche Filter verwendet wurden
37
wird dieser angepasst. Das Resultat des SQL-Befehls beinhaltet die Daten der
Suche in einer Liste von Objekten. Bevor jedoch die Daten ausgegeben werden
können, müssen die Daten auf ihren Typ gecastet werden. Anschließend werden
die gefundenen Dokumente gleich wie beim Button ’Start’ ausgegeben.
Der zweite Menüpunkt filtert die neuesten zehn Dokumente heraus und zeigt
diese an. Die Dokumente sind das Resultat eines SQL-Befehls im FileController.
Button: Zweite Stufe Der Button Zweite Stufe öffnet einen Container
Window, in dem sich der Benutzer in die zweite Stufe einloggen kann. Das
Fenster hat als Container ein FormPanel und beinhaltet zwei Textfields und ein
Button. Das erste Textfield fragt die Kundennummer ab, das Zweite die
Projektnummer. Der Button ’Login’ speichert die Daten der Eingabe in die
Textfields in eigene Parameter um diese dem Controller einfacher zu übermitteln.
Mithilfe des CustomerController und des ProjectController werden die
Eingabedaten im LoginController überprüft. Bei Erfolg wird die Startseite der
zweiten Stufe angezeigt und das nötige Cookie im Controller Auth-Controller
gesetzt. Bei Misserfolg wird dem Benutzer über ein Notify-Window angezeigt,
dass dieser entweder eine Falsche Kunden/Projektnummer eingegeben hat oder
die Projektnummer abgelaufen ist.
Button: Logout Über den Button Logout kann sich der Benutzer komplett aus
dem System ausloggen. Nach dem der Benutzer sich ausgeloggt hat wird dieser
wieder auf das Loginfenster verbunden. Mithilfe der CustomAuthorization-Klasse
werden alle aktuellen Cookies gelöscht.
38
2. Stufe
Die Startseite der zweiten Stufe (siehe Abbildung 21) bildet wie bei der ersten Stufe
den Ausgangspunkt. Zusätzlich hat die zweite Stufe eine weitere Seite. Diese Seite ist
das Profil des Benutzers und kann über die URL ’url/AccountMgmt’ erreicht werden.
Diese Seite zeigt die Daten des Kunden und des dazugehörigen Projekts an.
Abbildung 21: Screenshot - Zweite Stufe
39
Für die Anzeige wird ein Panel als Container verwendet. In diesem Container sind drei
weitere Container verschachtelt welche verschiedene Informationen anzeigen.
Home
AccountMgmt
Windows
Menu
CIPController
CustomerController
ProjectController
Abbildung 22: UMLKLassendiagram - Zweite Stufe
Kunde Das erste FormPanel besteht aus mehreren Textfields, welche mittels des
VBox-Layouts sortiert sind. Um die Daten auszulesen wird über den
Auth-Controller die Kundennummer aus dem Cookie ausgelesen. Diese
Kundennummer wird über den CIPController zum CustomerController
geschickt. Dieser bekommt mittels einer NHibernate-Verbindung und
SQL-Anfrage an die Datenbank die Daten des eingeloggten Kunden. Wie schon
bei der Suche nach Dokumenten muss das Ergebnis erst im CustomerController
gecastet werden, um in der View ausgegeben werden zu können.
Projekt Das zweite FormPanel liefert die Daten des Projekts. Wie schon beim
ersten FormPanel werden die Daten in einem VBox-Layout in mehreren Textfields
dargestellt. Mithilfe der Projektnummer des Cookies aus dem AuthController
kann auf die Daten zugegriffen werden. Die Daten aus der Datenbank werden im
ProjectController verarbeitet und anschließend in weiteren Textfields ausgegeben.
Betreuer Das dritte FormPanel zeigt die Daten des zuständigen Betreuers an.
Bei diesem FormPanel wurden die Attribute ’Collapsed’ und ’Collapsible’ auf
true gesetzt. Dies ermöglicht es, dass bei Aufrufen der Startseite das
Betreuer-Panel automatisch zugeklappt ist. Über einen Mausklick auf den
Panel-Head lässt sich dieses ein/ausklappen. Der Betreuer wird aus mithilfe der
Kundennummer und des CustomerControllers geladen.
Die Menübar der ersten Stufe wird um zwei Buttons erweitert. Die Software frägt dazu
40
bei jedem erneuten laden einer Seite das aktuelle Cookie ab. Je nachdem welches
Cookie gesetzt wurde, werden die einzelnen Buttons der Menüliste versteckt
beziehungsweise angezeigt. Die zwei Buttons der zweiten Stufe sind ’Mein Konto’ und
’Produkte’:
Button: Mein Konto Der Button Mein Konto lädt die Profilseite.
Button: Produkte Der Button Produkte funktioniert ähnlich wie der Button
Normen. Auch hier hat der Button zwei Menüpunkte:
Abbildung 23: Screenshot - Produkte
Der erste Menüpunkt öffnet die Ansicht der Produkte (siehe Abbildung 23) für
das aktuelle Projekt.
Gleich wie bei der Ansicht der Dokumente wird hier ein GridPanel als Container
mit dem Layout ’Fit’ verwendet. Die Daten aus dem Datenmodell Positions
werden mittels des Elements ColumnModel angezeigt. Dieses sortiert in die zwei
Spalten Produktnummer und Produktname. Um die Daten zu bekommen wird
wieder im AuthController der aktuelle Cookie ausgelesen. Dies liefert die
Projektnummer und die Benutzernummer. Diese Nummern werden über den
CIPController an den ERPDocumentController gesendet. Im
ERPDocumentController wird mittels SQL-Befehl in der Relation ERPDocument
nach Einträgen mit den zwei Nummern gesucht. Die ERPDocumentNummer
wird an den PositionController gesendet. Mittels der ERPDocumentNummer
wird in die PostionList mit der Relation Position gejoined. Die zutreffenden
Positions werden dann mithilfe des PositionControllers und des Datenmodelsl
Positions gewrapped und anschließend an das ColumnModel geschickt.
Der zweite Menüpunkt bietet eine Suche nach Produkten an. Wie schon bei der
Dokumentensuche wird ein Container Window geöffnet. Dieser ist komplett
41
Home
Products
Windows
Menu
CIPController
Position
Abbildung 24: UMLKlassendiagram für Produkte
gleich wie der der Dokumentensuche aufgebaut. Einzig die Combobox ist nicht
vorhanden. Mit dem ersten Textfield lässt sich nach der Produktnummer filtern
und mit dem zweiten nach dem Produktnamen. Die zwei Datefields sind wieder
zuständig um einen Zeitraum zu definieren. Das Ergebnis wird dann in der
gleichen Ansicht wie beim ersten Menüpunkt ausgegeben.
Administrator Stufe
Die Startseite der Administrator Stufe (siehe Abbildung 25) bildet wie bei der ersten
Stufe wieder den Ausgangspunkt. Die Menüleiste beinhaltet drei neue Button,
deaktiviert aber die zwei Buttons der zweiten Stufe.
Abbildung 25: Screenshot - Adminstufe
42
Home
Windows
Menu
CIPController
FileCon
ProjectCon
Abbildung 26: UMLKlassendiagram - Adminstufe
Button: Hochladen Der Button Hochladen öffnet ein Container Window. Für
das Fenster wird ein FormPanel mit dem dazugehörigen Standardlayout
verwendet. Es besteht aus einem Textfield, einer ComboBox, einer TextArea,
einem Datefield, einer Checkbox , einem FileUploadField und einem Button. In
den Fields und Boxen werden die nötigen Informationen des hochzuladenden
Dokuments angegeben. Über den Button ’Hochladen’ wird das Dokument in der
Software abgespeichert. Dazu wird der Pfad des Speicherortes in der Datenbank
gespeichert. Das Dokument selbst wird in einem Ordner der Software
abgespeichert.
Button: Projekt Verwalten Wie auch beim vorherigen Button wird wieder ein
Fenster geöffnet. Im FormPanel des Fensters sind vier Elemente enthalten. Das
erste Element ist ein Textfield zur Eingabe der zu bearbeitenden Projektnummer.
Das Zweite ist eine CheckBox ob das Projekt gesperrt werden soll. Datefield ist
das dritte Element und ermöglicht es, ein neues Auslaufdatum des Projektes
anzugeben. Dazu wird standardmäßig ein Datum, welches 6 Monate in der
Zukunft liegt vorgeschlagen. Mit dem Button ’Speichern’ wird der Controller
CIPController aufgerufen dieser leitet die Aufgabe weiter an den
ProjectController. Der ProjectController übermittelt der Datenbank, mittels
SQL-Anfragen die eingegeben Daten.
43
Button: Passwort ändern Der Button Passwort ändern öffnet abermals ein
Fenster. Über zwei Textfields und ein Button wird das Passwort geändert. Es
muss zwei mal das neue Passwort eingegeben werden. Nach dem der Button den
Controller CIPController triggert wird das Passwort in diesem mit Md5Hash
verschlüsselt und in der Datenbank abgespeichert.
9.3
WCF
Der WCF-Service soll Daten aus dem ERP-System in die Datenbank einfügen. Der
Dienst soll Methoden zum Einfügen von Daten der Kunden, Projekte, ERPDokumente
und Produkte anbieten. Wir haben uns mit der Firma din geeinigt nur den Service zu
schreiben, die Webanwendung für den Service wird anschließend von der Firma din
entwickelt. Das ABC-Prinzip wie schon in der Einführung 7 erklärt wurde wie folgt
verwirklicht:
Adresse Die Adresse unseres Webservice ist die SQL-Datenbank des
Kundeninformationsportals. Die Verbindung läuft wie schon bei dem
Kundeninformationsportal über NHibernate. Die Session wird wieder, mittels der
selben hibernate.xml Konfigurationsdatei initialisiert. Jedoch werden für den
Webservice diesmal keine .xml-Datein der Modelle benötigt. Der Service kann bei
Bedarf eine Session starten und mittels SQL-Befehle die Daten in die Datenbank
einspeisen.
Binding Die Bindung an den WCF-Service ist mittels HTTP verwirklicht. Dazu
wurde in der App.config ein basicHTTPBinding erstellt.
Contract
In unserem Interface für den Service werden die Verträge für den Service erstellt.
Dazu wurden vier OperationContracts angelegt. Diese vier Verträge sind die
Methoden, welche der Webservice anbietet um die Daten der Kunden, Projekte,
ERPDokumente und Produkte zu verschicken(InsertCustomer,
InsertERPDocument, InsertPosition, InsertProject). Für die Daten wurden vier
DataContracts erstellt. In den DataContracst werden mittels dem Tag
’DataMember’ die einzelnen Typen der Daten definiert, damit diese mit den
Typen aus der Datenbank übereinstimmen.
44
In unserer Hauptklasse ’CIPService’ werden die Methoden des Interfaces aus
implementiert. Dazu werden die OperationContracts und DataContracts des Interfaces
verwendet.
InsertCustomer Nachdem der Benutzer des Webservices die Daten des Kunden
eingegeben hat werden diese der Methode InsertCustomer() übergeben. Da die
Daten des Customers auf 2 Relationen (Address, Customer) aufgeteilt sind wird
zuerst die Adresse mit einem Insert-into-Befehl in die Datenbank eingefügt.
Anschließend wird über das selektieren der neuesten ID der Address-Relation, die
AddressID geholt. Mit dieser AddressID und den restlichen Daten des Kunden
wird dieser in die Datenbank eingefügt.
InsertProject Die Methode InsertProject() funktioniert gleich wie die Methode
zum Einfügen des Kunden.
InsertERPDocument Die Methode InsertERPDocument fügt die Daten eines
ERPDokumentes ein. Da, die ShippingAddressID und die BillingAddressID der
ERPDocument-Relation dem Benutzer nicht bekannt sind, muss mittels Der
Kundennummer beziehungsweise Projektnummer die AddressID der Relation
Customer beziehungsweise der Relation Project geholt werden. Nachdem diese
zwei IDs geholt wurden kann das neue ERPDocument in die Datenbank eingefügt
werden.
InsertPosition Diese Methode bekommt die Daten eines Produktes und die
ERPDokumentnummer und den ERPDokumenttyp. Zuerst wird das Produkt in
die zugehörige Relation ’Positions’ eingefügt. Anschließend wird die neueste
PositionID ausgelesen. Mithilfe der ERPDokumentnummer und des Typs wird
die ID des ERPDokuments selektiert. Diese zwei IDs werden anschließend
benötigt um einen neuen Eintrag in die Relation ’PostionList’, welche die
Verbindung des ERPDokuments mit den Produkten herstellt, einzufügen.
45
10
Evaluierung
Im ersten Teil dieses Kapitels wird die Evaluierung der entwickelten Software anhand
der textuellen Use-Case-Ableitung aus der Grafik in Kapitel 8 durchgeführt. Der zweite
Teil beschreibt das selbst-entworfene Abnahmeprotokoll.
10.1
Evaluierung durch Use-Cases
Im Folgenden wird jeder Use-Case erläutert und anschließend die Umsetzung in
unserer Software Schritt für Schritt aufgezeigt.
Einloggen in die erste Stufe Das Einloggen in die erste Stufe erfolgt über ein
globales Passwort, welches für alle Kunden dasselbe ist. In dieser Stufe erhält man
allgemeine Informationen zu Normen und Produkten.
Abbildung 27: Dialog zum Einloggen in die erste Stufe mit dem globalen Passwort
Einloggen in die zweite Stufe Besitzt man eine Kundennummer und eine aktive
Projektnummer, kann man sich in die zweite Stufe einloggen und darin Informationen
zu den angegebenen Benutzerdaten abrufen. Weiterhin lassen sich in der zweiten Stufe
die bestellten Artikel und dazugehörige Dokumente einsehen. Um zum Login für die
zweite Stufe zu kommen, muss man sich bereits in der ersten Stufe befinden und auf
den Zweite Stufe“-Button (siehe Abbildung 28) klicken. Anschließend öffnet sich ein
”
Dialog zur Eingabe der Daten (Abbildung 29).
Abbildung 28: Button zum öffnen des Login Dialogs für den zweiten Schritt
46
Abbildung 29: Dialog zum Einloggen in die zweite Stufe mit der benutzerspezifischen
Kundennummer und Projektnummer
Bei falscher Kundennummer, sowie ungültiger oder abgelaufener Projektnummer
erscheint ein Pop-Up mit der betreffenden Meldung:
Abbildung 30: Fehler Dialoge bei Login in die zweite Stufe
Ansicht von allgemeinen Informationen Die Ansicht von allgemeinen
Informationen wird ermöglicht, sobald man sich in die erste Stufe eingeloggt hat. Die
Informationen werden in einer Tabelle angezeigt. Erweitert man eine Zeile, erhält man
folgende Details zum Dokument:
Typ: die Information kann zur Zeit eine Norm oder ein Datenblatt sein
Beschreibung: eine Beschreibung des Dokumentes
47
Datum: das Erstellungsdatum des Dokumentes
Außerdem erhält man beim Erweitern einen Link zum Download der Datei.
Abbildung 31: Tabelle zur Ansicht der allgemeinen Informationen
Ansicht aller Informationen zum Projekt Die Ansicht von projektbezogenen
Informationen ist verfügbar, sobald man sich in der zweiten Stufe der Oberfläche
einloggt.
Hierbei werden als Erstes die Projekt- und Kundendetails, wie zum Beispiel
Lieferadresse oder Projektdatum angezeigt (Abbildung 32).
Ansicht von Projekt- und Kundendetails, wie zum Beispiel Lieferadresse oder
Projektdatum (Abbildung 32) und einer
Ansicht der bestellten Position zu diesem Projekt (Abbildung 34).
48
Abbildung 32: Informationen zum aktuellen Projekt
Über das Produktmenü (Abbildung 33) gelangt man zu einer Tabelle mit den
projektbezogenen Positionen (Abbildung 34).
49
Abbildung 33: Button zum Erreichen des Produktmenüs
Hierzu gibt es folgende Informationen:
Produktnummer und -name
Bezeichnung
Beschreibung
Menge
Lieferdatum
Abbildung 34: Tabelle zur Ansicht der einzelnen Position des Projektes
Einloggen als Administrator Das Einloggen als Administrator funktioniert auf
der selben Ebene wie das Einloggen in die erste Stufe. Wird im Passwortfeld der
Abbildung 27 das Administratorpasswort eingegeben, gelangt man zur
Administratoroberfläche der Webseite.
Passwort ändern Unter diesem Use-Case wird das Ändern des Benutzerpasswortes
verstanden. Dieses ist das Passwort, welches man zum Einloggen in die erste Stufe
benötigt. Zum Öffnen des Passwort-Ändern-Dialogs wird im Menü die Option
Passwort ändern“ (Abbildung 35) gewählt.
”
Abbildung 35: Button zum Öffnen des Dialogs zum Ändern des Passwortes
50
Dokumente verstecken Beim Hochladen eines Dokuments hat der Administrator
die Möglichkeit, ein Dokument als versteckt“ zu markieren. Dadurch ist das
”
Dokument und die zugehörigen Informationen zwar vorhanden, werden dem Kunden
aber nicht angezeigt.
Diese Markierung ist auf Abbildung 36 ersichtlich.
Abbildung 36: Dialog zum Hochladen von Dokumenten mit markierter Option zum Verstecken
Zugang sperren Die Option zum Sperren des Zugangs ist im Dialog zum Ändern
eines Projektes (Abbildung 38) gegeben. Hierzu wird einfach die Option Projekt
”
sperren“ gewählt und das Projekt gespeichert. Von diesem Moment an, kann sich der
Kunde mit diesem Projekt nicht mehr in die zweite Stufe einloggen.
Zugang verlängern Jedes Projekt hat ein Datum, bis zu welchem der Benutzer
Zugang dazu hat. Verzögert sich ein Projekt und dauert daher länger als ursprünglich
angenommen, kann der Administrator das Enddatum neu setzen. Diese Option ist mit
dem Menüpunkt Projekt verwalten“ (Abbildung 37) erreichbar.
”
51
Abbildung 37: Button zum Öffnen des Dialogs zum Ändern des Projektes
Im sich öffnenden Dialog kann ein Datum ausgewählt und das Projekt anschließend
gespeichert werden (Abbildung 38).
Abbildung 38: Dialog zum Ändern des Projektes
Einspielen von Dokumenten Ein Administrator hat die Möglichkeit, Dokumente
in das System einzuspielen. Hierzu muss er folgende Daten bereitstellen:
Dateiname: der Name, wie er später in der Dateiliste (Abbildung 31) angezeigt
wird
Dateityp: hier wird ausgewählt, ob es sich um eine Norm oder ein Datenblatt
handelt
Beschreibung: eine Beschreibung des hochzuladenden Dokuments
Erstellungsdatum: das Erstellungsdatum der Datei
Verstecken: die Option, das Dokument vor den Kunden verstecken zu können
Datei: die Datei, welche hochgeladen werden soll
Der Dialog für den Datei-Upload (Abbildung 36) ist über den Hochladen“-Button
”
(Abbildung 39) zu öffnen.
Abbildung 39: Button zum Öffnen des Dialogs zum Hochladen einer Datei
52
Einspielen von Daten Das Einspielen von Daten ist als einziger Anwendungsfall
nicht über die Weboberfläche möglich. Dieser Usecase wird über den WCF-Service
realisiert, der im Abschnitt 9.3 erläutert wird.
10.2
Evaluierung durch Abnahmeprotokoll
Für die Abnahme der technischen Arbeit durch den Auftraggeber, wurde ein minimales
Abnahmeprotokoll entworfen. Unter Anwesenheit eines Entwicklers wird das
Abnahmeprotokoll ausgefüllt. Das Dokument setzt sich aus folgenden inhaltlichen
Punkten zusammen:
1. Dokumentinformation: Unter Dokumentinformation finden sich allgemeine
Informationen:
Projekt-Titel: der Titel des abzunehmenden Projektes
Version: die Version des Abnahmeprotokolles; Eine Historie zu den
Versionen findet sich unter Punkt 2.
Datum: das Datum der letzten Änderung des Dokuments
Status: der aktuelle Status der Abnahme, wobei die Status in Bearbeitung,
vorgelegt oder akzeptiert möglich sind
2. Historie: Die Historie beschreibt die Entwicklung des Abnahmeverlaufes. Ändert
sich der Status des Dokuments, erhält die Historie einen neuen Eintrag.
Angemerkt werden hier folgende Daten:
Version
Datum
Autor
Von Status
Zu Status
Bemerkung
3. Funktionalität: In diesem Abschnitt befindet sich die Tabelle, in welcher die
nötigen Funktionalitäten laut Usecases aufgelistet sind. Zu jeder Funktionalität
bestehen folgende Informationen:
Funktion
Status der Funktion: nicht vorhanden, mangelhaft oder akzeptiert
Die betreffende Funktionalität wird vom Auftraggeber entsprechend bewertet
und bei bestehendem Mangel, dieser dem anwesenden Entwickler mitgeteilt.
4. Abnahme: In diesem letzten Teil des Dokuments unterzeichnen die anwesenden
Parteien die Version dieses Protokolls.
53
Im Anschluss befindet sich die letzte Version des Abnahmeprotokolls für das
Kundeninformationsportal.
Hier ist ersichtlich, dass der Auftraggeber vollkommen zufrieden mit dem finalen
Produkt ist.
54
1. Dokumenteninformation
Projekt-Titel
Kundeninformationsportal (CIP)
Version
2
Datum
09.04.2015
Status
Akzeptiert
Mögliche Status:
in Bearbeitung:
vorgelegt:
akzeptiert:
Das Produkt wird gerade bearbeitet.
Das Produkt ist aus Sicht des Erstellers fertig und wird dem
Auftraggeber zur Abnahme vorgelegt. Ist das Produkt mangelhaft,
wechselt der Status wieder zu “in Bearbeitung”.
Das Produkt wurde vom Auftraggeber überprüft und akzeptiert.
Abnahmeprotokoll
zum Kundeninformationsportal (CIP)
Seite 1 von 4
2. Historie
Version
1
1
2
2
Datum
Autor
Von Status
Zu Status
Bemerkung
30.03.2015
Werner
Kapferer,
Samuel
Carraro
In Bearbeitung vorgelegt
Erste Abgabe
30.03.2015
Werner
Kapferer,
Samuel
Carraro
vorgelegt
Mängel laut
Protokoll
09.04.2015
Werner
Kapferer,
Samuel
Carraro
In Bearbeitung vorgelegt
Zweite Abgabe
09.04.2015
Werner
Kapferer,
Samuel
Carraro
vorgelegt
Zweite Abgabe
akzeptiert
Abnahmeprotokoll
zum Kundeninformationsportal (CIP)
In Bearbeitung
Akzeptiert
Seite 2 von 4
11
Projektablauf
Da das Projekt von zwei Personen ausgearbeitet wurde, waren bestimmte Technologien
und Methoden nötig, um eine Koordination umsetzen zu können.
Im Folgenden werden die verwendeten Tools und ihr Einsatzzweck im
Projektmanagement vorgestellt.
11.1
Tools
GitLab GitLab [2] ist ein Produkt der gleichnamigen Firma GitLab B.V., welche
ihren Hauptsitz in den Niederlanden hat.
Die Software baut auf dem Sourcecodemanagement-Tool git [4] auf und ermöglicht
eine Installation auf einen eigenen Server. Durch den Webzugriff von GitLab ist eine
einfache, übersichtliche und funktionsreiche Verwendung mehrerer Repositories
möglich.
Von den vielen Funktionalitäten der Serversoftware wurden folgende für die Umsetzung
des Projektes verwendet:
Webzugriff auf Dateien: Der direkte Zugriff auf Dateien bietet eine gute
Möglichkeit, Dokumente, wie Bilder, Präsentationsfolien oder auch Sourcecode
schnell betrachten zu können, ohne das gesamte Respository klonen zu müssen.
Wiki: Das softwareinterne Wiki wurde verwendet, um allgemeine Informationen
zu speichern und zugänglich zu machen. Hier wurden Weblinks und
Projektinformationen gespeichert.
Issues: GitLab verfügt über ein eigenes Bugtrackingsystem. Dieses ist natürlich
im Vergleich zu BugZilla oder ähnlicher Software sehr einfach und nicht mit
annähernd viel Funktionalität ausgestattet, es reicht allerdings aus, um kleinere
Bugs vermerken und bestimmten Usern zuteilen zu können.
GitStats GitStats [5] ist ein einfaches Tool zum Erstellen von Statistiken von Git
Repositories. Mit einem Aufruf von gitstats [Repository Pfad] [Export Pfad]
werden die Daten aus dem Repository Pfad ausgelesen und die Statistik in
HTML-Format in den Export Pfad exportiert.
Kimai Kimai [19] ist ein OpenSource Zeittracking-Tool, welches auf einen eigenen
Server installiert wird. Die Software bietet die Möglichkeit, für verschiedene Projekte,
Benutzer, Kunden und Aktivitäten die in Anspruch genommene Zeit zu tracken.
Zusätzlich zur Zeitaufnahme könnten auch Kosten (mit Stundensätzen) berechnet und
automatisch Rechnungen erstellt werden. Eine weitere, sehr nützliche Funktionalität ist
das Exportieren der Daten. Somit kann zum Beispiel die gesamte Zeittabelle für ein
bestimmtes Projekt als .xls exportiert werden.
In dieser Bachelorarbeit wurde mit diesem Tool die Arbeitszeit für folgende
Aktivitäten getrackt:
59
Preparation: In dieser Kategorie wurden alle Vorbereitungen aufgezeichnet, wie
zum Beispiel das Einarbeiten in ein Framework, Durchgehen von Tutorials oder
ähnliches.
Documentation: Hier wurden die Zeiten für die Erstellung von Dokumenten
(Präsentationen, Diagramme, etc.) gesammelt. Nicht mehr aufgezeichnet wurden
die Zeiten für die Erarbeitung des schriftlichen Teils dieser Bachelorarbeit oder
das Auswerten der Statistiken.
Development: Diese Kategorie war die meistgenützte - in ihr wurden Zeiten
getrackt, in denen am Code gearbeitet wurde.
Eine Auswertung der mit Kimai erfassten Daten folgt im Abschnitt 11.2.
11.2
Zeitmanagement
In diesem Abschnitt wird erläutert, wie die Resource Zeit in diesem Projekt verwendet
wurde. Wie bereits in Tools (Kapitel 11.1) beschrieben, wurde hierzu die Software
Kimai verwendet. Die Daten wurden am Ende der technischen Ausarbeitung der
Arbeit exportiert und analysiert. In diesen Daten wurde allerdings die Zeit zur
Ausarbeitung des schriftlichen Teiles der Bachelorarbeit nicht mehr berücksichtigt.
Am Projekt wurde von Mai 2014 bis inklusive März 2015 gearbeitet. Gesamt wurden
232,43 Stunden investiert. Diese Gesamtdauer teilt sich wie folgt auf die einzelnen
Aktivitäten development, documentation und
Nun werden die einzelnen Monate der Projektdauer betrachtet. Analysiert wurde
hierbei, in welchem Monat
wie viele Tage,
wie viele Stunden und
wie viele Stunden pro Person gearbeitet wurde.
Durchschnittlich wurde jedes Monat 7 Tage und 21,13 Stunden an der Bachelorarbeit
gearbeitet.
Im aktivsten Monat Oktober waren es 19 Tage und 56,95 Stunden.
Aus der Statistik von GitStats [5] ergeben sich auch die meistgenützten Tageszeiten
aus den Commits.
60
Abbildung 40: Diagramm: Tage, Stunden und Stunden pro Person
61
Abbildung 41: Diagramm: Commits pro Uhrzeit
So ergibt sich aus der Abbildung 41, dass die meisten Commits ins Repository um ca.
16:00 Uhr gemacht wurden.
Allgemein wurde im Zeitraum von 14:00 Uhr bis 17:00 Uhr 31 von 60 - also über die
Hälfte - der Commits abgesetzt.
11.3
Projektmanagement
In diesem Abschnitt werden die angewandten Projektmanagementmethoden vorgestellt
und erläutert, wie sie in diesem Projekt zum Einsatz gekommen sind.
Arbeitsteilung Da die Bachelorarbeit zu zweit ausgearbeitet wurde, mussten
natürlich die verschiedenen Bereiche der Arbeit so weit wie möglich, getrennt werden.
Unsererseits herrschten bereits Vorlieben zu den verschiedenen Bereichen, daher fiel die
Aufgabenteilung wie folgt aus:
Werner Kapferer
– Projektmanagement: die Planung und Umsetzung der Extreme
Programming Methoden, mitsamt seinen Iterationen
– Tools: Bereitstellung und Wartung der verwendeten Tools (GitLab, Kimai)
– Kommunikation: die Kommunikation mit dem Kunden und
Terminvereinbarungen
– Analyse und Statistik: Erstellung und Auswertung diverser Statistiken
und deren Analyse
– Ext.Net: Einarbeitung und Kennenlernen des Frameworks als Vorbereitung
zum Pair-Programming
Samuel Carraro
– Datenbank: der Entwurf, die Erstellung und Wartung des
Datenbankschemas
– Datenbank-Kommunikation: die Schnittstelle zwischen der Datenbank
und der Applikation (NHibernate, SQLOver, etc.)
– WCF-Service: die Erstellung und das Testen des WCF-Services, der als
Schnittstelle zum firmeninternen ERP-System dient
Gemeinsam
– Applikation: die Hauptapplikation (MVC4)
Daraus ergibt sich eine Aufteilung des schriftlichen Teiles wie folgt:
Werner Kapferer
– Abstract 2
62
– Einleitung 3
– Firmenprofil 4
– Evaluierung 10
– Projektablauf 11
– Zusammenfassung 12
Samuel Carraro
– Anforderungen 5
– Literatur 6
– Technische Einführung 7
– Konzept 8
– Technische Details 9
Extreme Programming Im Projekt wurde grundsätzlich Extreme Programming
als Vorgehensweise der Softwareentwicklung gewählt. Die Gründe dafür sind die
Eigenschaften des Verfahrens: Einfachheit, Kommunikation, Feedback und Mut“ [10].
”
Da für Extreme Programming vor allem die Einfachheit der Organisation an erster
Stelle steht, sind auch die bestehenden Rollen minimal:
Kunde: Der Kunde - oder das Kundenteam - bestand in unserem kleinen
Projekt aus einer einzelnen Person: Der Projektbetreuer seitens der Firma. Der
Kunde gibt Anforderungen, Kriterien und Geschäftswerte des Projektes vor.
Entwickler: Die Entwickler werden im Extreme Programming als Einheit
gesehen und nach außen hin nicht nach Spezialgebieten oder Ähnlichem
unterteilt. Die Entwickler erfüllen die Anforderungen des Kunden.
Manager: Ein Manager oder ein Managementteam ist bei größeren Projekten
von Vorteil, da es Ressourcen und Ziele besser verwalten kann. Ein
Managementsystem an sich ist von Extreme Programming nicht definiert. Bei
diesem Projekt wurde aufgrund seiner Größe auf einen Manager verzichtet.
Beim Extreme Programming wird in Zyklen von typischerweise 2 Wochen gearbeitet.
Am Anfang jedes Durchlaufs wird bei einem Treffen zwischen Kunde und Entwickler
das Ziel und die Anforderungen des nächsten Zyklus festgelegt. In diesem Projekt
wurden diese Zyklen etwas großzügiger ausgelegt, da die Anforderungen und Usecases
von Anfang an klar definiert wurden. Üblicherweise betrugen die Zykluszeiten 2 bis 3
Monate.
Die Abbildung 42 zeigt die Schritte einer solchen Iteration.
63
Planning/Feedback Loops
Release Plan
Months
Iteration Plan
Weeks
Acceptance Test
Days
Stand Up Meeting
One day
Pair Negotiation
Hours
Unit Test
Minutes
Pair Programming
Seconds
Code
Abbildung 42: Iterationen des Extreme Programmings [3]
Pair Programming: Während der Pair-Programming-Phase wird der Code für
das Iterationsziel geschrieben. Da das Entwicklerteam als Einheit arbeitet, wird
zum Großteil gemeinsam an einem Computer entwickelt. Diese Methodik bietet
eine Überprüfung des Codes durch eine zweite Person zur Zeit der
Programmierung und verhindert somit einige Fehler. Bei diesem Projekt wurde
ungefähr ein Drittel der Zeit in Pair Programming entwickelt. Wir Entwickler
trafen uns regelmäßig für die Zusammenarbeit um Pair-Programming zu
verwirklichen. Typischerweise dauerte so ein Entwicklungstag 6 bis 7 Stunden.
Unit Test: Das Testen der kleinsten Einheiten zeigt Fehler auf, bevor sie sich im
größeren Rahmen der Software auswirken können und sorgt für einen
konsistenten Zustand des Programmes. Diese Tests werden ausgeführt, sobald
Code geschrieben wurde, der auf Funktionalität getestet werden kann. Auch in
unserem Projekt wurden regelmäßig Unit Tests durchgeführt. Nachdem die Ziele
für den Entwicklungstag beim Stand Up Meeting vereinbart wurden, wurde die
Umsetzung regelmäßig und vor jedem Commit mit Unit Tests getestet.
Pair Negotiation: Unter Pair Negotiation versteht man kürzere Absprachen
64
unter den Entwicklern. Sie fördern die Kommunikation und stellen sicher, dass
die Anforderungen des Kunden nicht verfehlt werden. Auch diese Methode wurde
in diesem Projekt aktiv umgesetzt. Durch Pair Programming war die Pair
Negotiation einfach und unkompliziert umsetzbar.
Hierbei übernahm der Entwickler, welcher gerade nicht an der Tastatur saß den
Part, die Ziele des Tages und Anforderungen des Kunden zu überprüfen.
Stand Up Meeting: Diese Besprechung wird täglich vor Beginn der
Entwicklung abgehalten. Bei diesem kurzen Meeting wird besprochen, was am
Vortag geleistet wurde und was die Ziele für den aktuellen Tag sind. Sollten am
Vortag Probleme bei der Ausarbeitung von Code aufgetreten sein, wird
besprochen, wie diese behoben werden können.
An Entwicklunstagen wurde immer mit diesem Meeting begonnen. Hierbei
wurden die kleinen Tagesziele definiert, welche implementiert werden sollten.
Acceptance Test: Der Akzeptanztest stellt das Ende einer Iteration dar. Der
Test wird vom Kunden durchgeführt und dient zur Evaluierung, ob der
neu-entwickelte Softwareteil den Anforderungen des Kunden genügt. An diesem
Punkt können sich neue Prioritäten ergeben oder Verbesserungsvorschläge seitens
der Entwickler eingebracht werden.
Die Akzeptanztests sind die einzige Methode der XP-Iteration, welche nicht
regelmäßig durchgeführt wurde. Es gab in diesem Projekt einen großen
Akzeptanztest am Ende, welcher gleichzeitig der Evaluierung diente. Zusätzlich
wurden zirka 2 - 3 kleine Akzeptanztests bei Meetings mit dem Kunden
durchgeführt. Hier wurde auf einem Entwicklungsnotebook kurz vorgezeigt, wie
die vorgegebenen Aufgaben erfüllt wurden und mögliche Abweichungen
besprochen. Die Dokumentation zum finalen Abnahmetest wird im Kapitel 10.2
beschrieben.
Diese Iterationen werden fortgesetzt, bis die Software ins Release-Stadium gelangt.
Wurde die Softwareversion veröffentlicht, beginnt ein neuer, sogenannter Release
”
Plan“ und mit ihm auch neue Iterationen.
65
12
Zusammenfassung
In über 230 Stunden wurde ein Webinformationsportal mit zugehöriger
Webservice-Schnittstelle entwickelt, welches den Anforderungen der Firma din-Dietmar
Nocker Sicherheitstechnik GmbH entspricht. Diese Anforderungen umfassten
Technologievorgaben, Anwendungsfälle und die Verwendung und Wartung von
vorhandenen Datenstrukturen. Die Technologievorgaben wurden wie gefordert erfüllt
und somit kommt in unserem Projekt ein Microsoft SQL-Server für die Speicherung,
sowie ein WCF-Service zum Einspielen der Daten zum Einsatz. Das Datenmodell an
sich wurde verständlich und strukturiert in ein Datenbankschema übergeleitet und ist
somit komfortabel wartbar. Weiters wurde die gewünschten Technologie Microsoft
MVC unter der zusätzlichen Verwendung vom Ext.NET Framework für die Umsetzung
genutzt.
Einen interessanten Anforderungspunkt des Projektes stellte die mehrstufige
Authentifizierung mit jeweils anderen Logindaten dar. Hierbei nutzten wir eigene
Algorithmen zur Umsetzung und Überprüfung der jeweiligen Logins. Die Speicherung
von Authentifizierungen wurde mithilfe von Cookies umgesetzt. Somit wurde auch für
diesen Usecase eine elegante Lösung gefunden und realisiert.
Auch der geforderte WCF-Service als Schnittstelle zum ERP-System, aus welchem
schlussendlich die Daten kommen werden, bietet übersichtlich die wichtigsten
Methoden zur Datenmigration an. Folgende Interfaces stehen ausimplementiert zur
Verfügung: InsertCustomer, InsertProject, InsertERPDocument und InsertPosition.
Evaluiert wurde unser Projekt schlussendlich auf zwei Weisen:
1. durch Usecases: Hierbei wurden alle gestellten Usecases und die Umsetzung mit
unserem Produkt betrachtet. Die Anwendungsfälle wurden vollständig und
strukturiert in die Webapplikation eingearbeitet.
2. durch ein Abnahmeprotokoll: Am Ende der Entwicklung wurde ein
Abnahmeprotokoll erstellt, welches gemeinsam mit dem Auftraggeber bearbeitet
wurde. Hierbei wurden die Anforderungen schriftlich aufgelistet und gemeinsam
von den Entwicklern und dem Auftraggeber bewertet. In der letzten Version des
Protokolls gab es keine mangelhaften oder nicht vorhandene Funktionen mehr.
Die verwendeten Technologien von Microsoft waren für uns größtenteils unbekannt und
somit bedurfte es hier einige Einarbeitungszeit und das Befassen mit deren
Dokumentationen. Da wir allerdings die Tools, welche für die Umsetzung des Projektes
genutzt wurden, bereits kannten, war hier wenig Aufwand zum Kennenlernen dieser
nötig. Die Arbeit wurde ziemlich genau auf die zwei Bearbeiter aufgeteilt und großteils
gemeinsam mit Pair Programming am Code gearbeitet.
Im Endeffekt verlief der Ablauf des Projektes sehr gut und wir, die Entwickler, sowohl
als auch der Auftraggeber sind mit dem Ergebnis sehr zufrieden.
Eine besondere Freude für uns ist es, dass diese entwickelte Webapplikation auch in der
Praxis eingesetzt werden wird.
66
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Logo von din . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usecasediagramm für Kunden und Datenquelle . . . . . . . . . . . . . . .
Usecasediagramm für Administrator, Verwaltungssystem und Datenquelle
UML-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.NET-Framework Architektur [21] . . . . . . . . . . . . . . . . . . . . . .
.NET-Plattform Konzept [1] . . . . . . . . . . . . . . . . . . . . . . . . . .
ASP.NET MVC Request-Response [9] . . . . . . . . . . . . . . . . . . . .
Architektur des NHibernate [17] . . . . . . . . . . . . . . . . . . . . . . .
ABC-Prinzip von WCF [18] . . . . . . . . . . . . . . . . . . . . . . . . . .
Messaging Runtime [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Klassendiagramm MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ablauf einer Anfrage mittels eines HTTP-Cookies [20] . . . . . . . . . . .
Ablauf Benutzeranfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ablauf WCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File - Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Klasse - CustomAuthorization . . . . . . . . . . . . . . . . . . . . . . . . .
Screenshot - Loginfenster . . . . . . . . . . . . . . . . . . . . . . . . . . .
UMLKlassendiagram - Loginfenster . . . . . . . . . . . . . . . . . . . . . .
Screenshot - Erste Stufe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UMLKlassendiagram - Erste Stufe . . . . . . . . . . . . . . . . . . . . . .
Screenshot - Zweite Stufe . . . . . . . . . . . . . . . . . . . . . . . . . . .
UMLKLassendiagram - Zweite Stufe . . . . . . . . . . . . . . . . . . . . .
Screenshot - Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UMLKlassendiagram für Produkte . . . . . . . . . . . . . . . . . . . . . .
Screenshot - Adminstufe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UMLKlassendiagram - Adminstufe . . . . . . . . . . . . . . . . . . . . . .
Dialog zum Einloggen in die erste Stufe mit dem globalen Passwort . . . .
Button zum öffnen des Login Dialogs für den zweiten Schritt . . . . . . .
Dialog zum Einloggen in die zweite Stufe mit der benutzerspezifischen
Kundennummer und Projektnummer . . . . . . . . . . . . . . . . . . . . .
Fehler Dialoge bei Login in die zweite Stufe . . . . . . . . . . . . . . . . .
Tabelle zur Ansicht der allgemeinen Informationen . . . . . . . . . . . . .
Informationen zum aktuellen Projekt . . . . . . . . . . . . . . . . . . . . .
Button zum Erreichen des Produktmenüs . . . . . . . . . . . . . . . . . .
Tabelle zur Ansicht der einzelnen Position des Projektes . . . . . . . . . .
Button zum Öffnen des Dialogs zum Ändern des Passwortes . . . . . . . .
Dialog zum Hochladen von Dokumenten mit markierter Option zum Verstecken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Button zum Öffnen des Dialogs zum Ändern des Projektes . . . . . . . . .
Dialog zum Ändern des Projektes . . . . . . . . . . . . . . . . . . . . . . .
Button zum Öffnen des Dialogs zum Hochladen einer Datei . . . . . . . .
67
7
9
10
12
16
17
19
21
24
25
26
28
30
31
32
34
35
36
36
37
39
40
41
42
42
43
46
46
47
47
48
49
50
50
50
51
52
52
52
40
41
42
Diagramm: Tage, Stunden und Stunden pro Person . . . . . . . . . . . . . 61
Diagramm: Commits pro Uhrzeit . . . . . . . . . . . . . . . . . . . . . . . 61
Iterationen des Extreme Programmings [3] . . . . . . . . . . . . . . . . . . 64
68
Literatur
[1] Autodesk. My first plug-in training.
http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=17325174.
[Online; accessed 20. Mai 2015].
[2] GitLab B.V. Gitlab. http://www.gitlab.com/, 2015. [Online; accessed 25. März
2015].
[3] Wikimedia Commons. Planungs- und feedbackschleifen von extreme
programming. http://commons.wikimedia.org/wiki/File:
Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg, 2013.
[Online; accessed 25. März 2015].
[4] Git. Git. http://www.git-scm.com/, 2015. [Online; accessed 25. März 2015].
[5] GitStats. Gitstats - git history statistics generator.
http://gitstats.sourceforge.net/, 2015. [Online; accessed 25. März 2015].
[6] Gail-Joon Ahn Joon S. Park, Ravi Sandhu. Role-based access control on the web.
https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/p37-park.pdf.
[Online; accessed 16. Mai 2015].
[7] Stephanie Hölzl Jürgen Kotz. WCF - Windows Communication Foundation.
ADDISON-WESLEY, 2008.
[8] Vinodh Kumar. Beginning Windows 8 Data Development, chapter ASP.NET Web
API. Apress, 2013.
[9] Saascha Kupper. Asp.net mvc einführung.
http://blog.saschakupper.de/asp-net-mvc-einfuehrung/, 2014. [Online;
accessed 11. April 2015].
[10] Lowell Lindstrom and Ron Jeffries. Extreme programming and agile software
development methodologies. Information systems management, 21(3):41–52, 2004.
[11] Microsoft. Asp.net web api documentation.
https://msdn.microsoft.com/en-us/library/hh833994%28v=vs.108%29.aspx.
[Online; accessed 20. Mai 2015].
[12] Microsoft. Mvc ext.net. http://mvc.ext.net/. [Online; accessed 20. Mai 2015].
[13] Microsoft. Cookies dokumentation.
https://msdn.microsoft.com/de-de/library/ms178194%28v=vs.140%29.aspx,
2015. [Online; accessed 6. April 2015].
[14] Microsoft. Mvc ext.net gui dokumentation. http://mvc.ext.net/, 2015. [Online;
accessed 11. April 2015].
69
[15] Microsoft. Office live. https://office.live.com/, 2015. [Online; accessed 18.
Mai 2015].
[16] Microsoft. Visual studio. https://www.visualstudio.com/, 2015. [Online;
accessed 6. April 2015].
[17] NHibernate. Documentation.
http://nhibernate.info/doc/nh/en/#manipulatingdata-update-lock, 2015.
[Online; accessed 6. April 2015].
[18] Paolo Salvatori. The abc of wcf. http://blogs.msdn.com/b/paolos/archive/
2009/11/17/customizing-and-extending-the-biztalk-wcf-adapters.aspx,
2015. [Online; accessed 18. Mai 2015].
[19] Kevin Papst et al.. Severin Leonhardt, Torsten Höltge. Kimai - open source
time-tracking. http://www.kimai.org/, 2015. [Online; accessed 25. März 2015].
[20] Chris Shiflett. The truth about sessions.
http://shiflett.org/articles/the-truth-about-sessions, 2015. [Online;
accessed 10. April 2015].
[21] Wikipedia. .net. http://de.wikipedia.org/wiki/.NET. [Online; accessed 20.
Mai 2015].
[22] Coimbatore Chandersekaran William R. Simpson. Claims-based authenticationfor
a web-based enterprise. INSTITUTE FOR DEFENSE ANALYSES, 2013. [Online;
accessed 16. Mai 2015].
70