Leopold-Franzens-University Innsbruck Institut f¨ ur Informatik Forschungsgruppe Quality Engineering

BACHELORARARBEIT

Konzeption und Entwicklung eines Kundeninformationsystems

Werner Kapferer, Samuel Carraro

Betreuer: Philipp Kalb

Innsbruck, 3. Juni 2015

Inhaltsverzeichnis 1 Eidesstattliche Erkl¨ arung

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 Erkl¨ arung

Wir erkl¨aren hiermit an Eides statt durch unsere eigenh¨andigen Unterschriften, dass wir die vorliegende Arbeit selbst¨ andig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet haben. Alle Stellen, die w¨ortlich oder inhaltlich den angegebenen Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit wurde bisher weder in gleicher noch in ¨ahnlicher Form einer andern Pr¨ ufungsbeh¨ orde vorgelegt und auch noch nicht ver¨offentlicht.

Samuel Carraro

Datum

Werner Kapferer

Datum

3

2

Abstract

Die Firma din Sicherheitstechniken ben¨otigte eine Webapplikation, die ihren Kunden Informationen zug¨ anglich macht. Die Applikation sollte in Technologien von Microsoft umgesetzt werden. Zus¨ atzlich wurde ein WCF Server verlangt, um die firmeninternen Daten in die Webapplikation spielen zu k¨onnen. 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 erl¨autert. 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 l¨asst sich durch verschiedene Vorteile auch leicht nachvollziehen. Applikationen werden zentral installiert und sind somit einfach f¨ ur alle User updatebar. Die Wartung von verschiedenen Versionen und Varianten entf¨ allt und alle Benutzer arbeiten garantiert mit der gleichen Version. Auch der Zugriff auf solche Dienste erweist sich als einfach und von u uhrbar ¨berall durchf¨ vom Heimb¨ uro 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 zug¨ anglich zu machen. Ein bekanntes und erfolgreiches Beispiel hierf¨ ur ist Microsoft mit seinem Office-Onlineprodukt Office Online“ [15], welches die ” wichtigsten Funktionen von Word, Excel, etc. ins Web auslagert. Nun m¨ochte auch die Firma din-Sicherheitstechnik GmbH diesen Schritt machen und ihren Kunden eine Webplattform zur Verf¨ ugung stellen, u ¨ber welche die Benutzer Informationen zu Produkten und Projekten abfragen k¨onnen. Das Unternehmen pflegt seine firmeninterne Daten wie Kunden, Projekte und dazugeh¨orige Artikel, Datenbl¨atter 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 erm¨ oglicht. Nun musste ein solches Webinformationssystem konzipiert, geplant und ausgearbeitet werden, welches den Kunden die M¨ oglichkeit bietet, aktuelle Informationen zu ihren pers¨onlichen Daten, Projekten und bestellten Artikel einsehen zu k¨onnen. Das Webportal sollte mehrere Loginstufen unterst¨ utzen. Die erste Stufe betrifft alle Kunden des Unternehmens und bietet die M¨oglichkeit, allgemeine Informationen und Dokumente, wie Datenbl¨ atter, Normen und Informationen zum Unternehmen abrufen zu k¨onnen. F¨ ur die zweite Stufe ben¨ otigt man allerdings bereits ein aktives Projekt. Diese Stufe ist die inhaltsreichste, da sie Informationen zum Projekt, sowie zu allen dazugeh¨origen Artikeln bietet. Hier werden dem Kunden zum Beispiel komfortabel die Liefertermine und Lieferadressen der einzelnen Positionen angezeigt. Die dritte Stufe ist f¨ ur Administratoren reserviert. Sie k¨onnen somit allgemeine Einstellungen f¨ ur 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 f¨ ur uns ebenfalls unbekannt war. F¨ ur 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 erl¨autert. Im Kapitel Literatur (Abschnitt 6) werden ¨ahnliche, schon vorhandene L¨osungen erkl¨ art 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 erl¨autert, wie unsere Algorithmen zur Authentifizierung und ¨ahnlichen Vorg¨angen funktionieren und der technische Hintergrund dazu detailliert erkl¨art. Im k¨ urzeren Kapitel Evaluierung (Abschnitt 10) befindet sich die nachtr¨agliche Beurteilung anhand der aufgestellten Use-Cases. Hierzu wird die Oberfl¨ache der Webapplikation, und wie die Anforderungen darin durchf¨ uhrbar 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 erw¨ahnt. Abschließend wird noch auf die angwandte Projektdurchf¨ uhrungsmethodik 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 f¨ ur Notbeleuchtung durch Herrn Dietmar Nocker gegr¨ undet. Bereits drei Jahre sp¨ ater wurde die din-Facilitymanagement GmbH (Forschung, Entwicklung und Produktion) gegr¨ undet. 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 voll¨ uberwachten, frei programmier- und schaltbares Notlichtsystem. F¨ unf Jahre sp¨ater wurde die din-Anlagentechnik GmbH f¨ ur Speziall¨osungen im Bereich Verkehrsinfrastruktur gegr¨ undet. 2011 fand die Er¨offnung des neuerbauten Headquarters in Linz statt. Im selben Jahr hat der Vertrieb im Bereich Notlicht in den L¨andern Schweiz & Slowenien begonnen.2014 wurde die neue Zweigstelle in Innsbruck mit mittlerweile 120 Mitarbeitern er¨ offnet. 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 ” pers¨onliches Anliegen“ bem¨ uht f¨ ur alle Anforderungen eine L¨osung 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 f¨ ur das Portal werden vom bereits vorhandenen ERP-System zur Verf¨ ugung 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 gew¨ unscht. 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 Benutzeroberfl¨ache 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, unabh¨ angige 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 gew¨ ahrt, welches der Administrator ¨andern 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 nat¨ urlich Zugriff auf Produktdatenbl¨atter oder Bedienungsanleitungen. Der Zugang zu dieser Stufe soll allerdings zeitlich begrenzt (auf 6 oder 12 Monate) sein und durch Administratoren verl¨anger- oder sperrbar sein. Spezifikation des Usecase: Um die Grobanforderungen besser darzustellen wurde ein Usecase-Diagramm erstellt (Abbildung 2, 3). 8

Abbildung 2: Usecasediagramm f¨ ur Kunden und Datenquelle

9

Abbildung 3: Usecasediagramm f¨ ur 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 ¨offentliche Normen und Datenbl¨ atter der Firma din und eine Men¨ uleiste um sich durch die Software durch ¨ navigieren zu k¨ onnen. Uber diese Men¨ uleiste kann der Benutzer in der ersten Stufe nach Dokumenten suchen und sich in die zweite Stufe einloggen. F¨ ur das Einloggen in die zweite Stufe wird eine Kundennummer und eine Projektnummer ben¨otigt. In der zweiten Stufe werden weitere Aktionen in der Men¨ uliste freigeschaltet. Zus¨ atzlich 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 bez¨ uglich des Projektes zugreifen. ˆ Administrator: Der Administrator muss sich wie der Benutzer mit einem spezifischen Passwort einloggen. Dieser hat die M¨oglichkeit den Zugang zu Projekten zu sperren beziehungsweise ihn um eine bestimmte Zeit zu verl¨angern. Außerdem kann der Administrator ¨offentliche 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 bez¨ uglich der Kunden und Projekte.

¨ ˆ Verwaltungssystem: Uber das Verwaltungssystem ist eine Schnittstelle zwischen dem ERP-System und der Datenbank. Um den Administrationsaufwand m¨oglichst 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 erm¨oglicht es Daten eines Kunden und seiner Adresse in die Datenbank zu pushen. Die Zweite speichert Daten eines Projektes und der dazugeh¨origen 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 erm¨oglicht es ein Produkt f¨ ur 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 k¨onnen 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 geh¨ oren Positionsnummern, Artikelnummer, Beschreibungen, Menge, Einheit, ein Lieferdatum und weitere Informationen. ˆ ERP Dokumente: ERP Dokumente bilden im System den Container f¨ ur eine Kunden-Projekt-Beziehung. Dieses Dokument beinhaltet auch die Liste der Positionen f¨ ur das Projekt, sowie Liefer- und Rechnungsadressen.

13

6

Literatur

Im folgenden Kapitel werden verschiedene Konzepte zur L¨osung unser Anforderungen vorgestellt, miteinander verglichen und erkl¨art wieso wir uns f¨ ur bestimmte Konzepte entschieden haben. Authentifizierung F¨ ur 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 St¨ uck Information, welches eine Identit¨ at beschreibt(Bsp: E-mailadresse, Name, etc). Mehrere Claims werden zusammen mit einer Signatur in einem Authenifikationstoken geb¨ undelt. Diese Tokens werden dem Benutzer ausgestellt nachdem dieser sich auf dem Identity Provider angemeldet hat. Der Identity Provider u uft die ¨berpr¨ Logindaten des Benutzers. Mit diesen Daten sammelt er die n¨otigen Claims zusammen und formt ein Token welches zur¨ uck 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 f¨ ur Webseiten. Dem Benutzer wird hierbei ein einfaches Login-Fenster angezeigt in dem er seine Logindaten eingeben kann. Nachdem dieser seine Daten abgesendet hat u uft die Software seine Daten und schickt ¨berpr¨ dem Benutzer ein Cookie zur¨ uck. Das Cookie hierbei beinhaltet Informationen zum Benutzer und einen Zeitstempel. Die Informationen werden ben¨otigt um gewisse Zugriffe f¨ ur den Benutzer freischalten zu k¨onnen. Der Zeitstempel beinhaltet eine bestimmte Zeit nachdem der Cookie abl¨auft. Mit dem Cookie kann sich der Benutzer u ¨ber alle Seiten der Software bewegen ohne sich erneut einloggen zu m¨ ussen. ˆ Role-based Role-based authenication funktioniert ¨ ahnlich wie die Form-based authentication. Jedoch werden die Benutzer hierbei nach dem Login in verschiedene Rollen unterschieden. Hierbei wird beim Login ein Role Server ben¨ otigt, welcher die verschiedenen Rollen verwaltet. F¨ ur 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 uft und dieser wird dann einer Rolle zugewiesen. ¨berpr¨

F¨ ur unsere Software haben wir uns f¨ ur die Form-based authenication entschieden. Da wir unsere Software so kompakt wie m¨oglich programmieren wollten haben wir uns 14

nicht f¨ ur das Claim-based Konzept entschieden, da dieses einen weiteren Identity Provider ben¨ otigt, welcher s¨ amtliche Kunden-claims beinhaltet. Das Role-based Konzept konnte aufgrund unseres Zwei-Stufen Logins nicht umgesetzt werden. Da f¨ ur die erste Stufe ein einmaliges Passwort f¨ ur jeden Kunden ben¨otigt wird k¨onnen wir diese nicht erkennen und in verschiedene Rollen aufteilen. Webservice F¨ ur 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 unterst¨ utzt 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 Funktionalit¨ aten unterst¨ utzt 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 k¨onnen die verschickten Nachrichten als einzelnen Zeichen oder ganzen W¨orter als XML versendet werden. F¨ ur die Kommunikation zwischen den Endpoints verwendet WCF das A-B-C Prinzip. WCF kann verwendet werden um einen Service zu erstellen der spezielle Szenarien unterst¨ utzt wie zum Beispiel eine Einweg-Kommunikation unterst¨ utzen soll oder um TCP oder UDP unterst¨ utzen zu k¨onnen.

F¨ ur unsere Software haben wir uns f¨ ur das WCF Framework entschieden, da wir keine große Bandbreite an Benutzern unterst¨ utzen m¨ ussen. 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 unterst¨ utzt.

15

7

Technische Einfu ¨ hrung

In diesem Kapitel wird auf die verwendeten Technologien unserer Software eingegangen. Wie schon im Kapitel Anforderungen erw¨ahnt soll das Projekt komplett mit Technologien des Softwareherstellers Microsoft produziert werden. F¨ ur diesen Zweck wurde die Software in der Entwicklungsumgebung Visual Studio 2013 [16] verwendet. Programmiersprachen F¨ ur unsere Software haben wir C# und HTML beziehungsweise Razor-Syntax f¨ ur C# verwendet. Die aktuelle Versionsnummer ist 5.0, welche auch in unserem Projekt verwendet wurde. Um die Pr¨ asentationsschicht zu programmieren, haben wir auf Razor und HTML zur¨ uckgegriffen. Razor ist ein Syntax f¨ ur C#, um dynamische Webseiten programmieren zu k¨ onnen, welche 2010 als Teil des ASP.NET MVC 3 Framework ver¨offentlicht wurde. Zur Unterst¨ utzung von Razor haben wir HTML verwendet, um Beispielsweise Tabellen genauer darzustellen. Zum Erstellen unserer Datenbank beziehungsweise f¨ ur 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 erm¨oglicht es Programme mit unterschiedlichen Programmiersprachen erstellen zu k¨onnen. Weiters bietet es Funktionen f¨ ur Ausnahmenbehandlungen, Garbage Collection, Sicherheit und Interoperabilit¨ at 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 ausgef¨ uhrt, damit bestimmte Eigenschaften und Verhalstensmuster in den Bereichen Speicherverwaltung, Sicherheit und Ausnahmebehandlung zu garantieren. Weiters stellt CLR den JIT-Compiler f¨ ur 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 ausgef¨ uhrt und arbeiten nach einem bestimmten Verarbeitungszyklus: 1. Der Benutzer fordert eine Seite, mittels HTTP-GET an. Falls die Seite zum ersten Mal aufgerufen wird f¨ uhrt diese eine Vorverarbeitung aus. 2. F¨ ur den Benutzer erscheint seine angeforderte Seite, im Hintergrund wird diese dynamisch im Browser gerendert. 3. Der Benutzer kann nun Buttons bet¨atigen 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 zur¨ uckgesendet. 5. Auf dem Server wird die Seite dadurch erneut ausgef¨ uhrt und die Informationen, des Benutzers stehen der Seite nun zur Verf¨ ugung. 6. Die Seite f¨ uhrt nun die Verarbeitung aus und wird wieder im Browser dargestellt. F¨ ur 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 erm¨ oglicht es mit REST zu arbeiten. Durch die Verwendung von Formen wie JSON, XML und OData beziehungsweise von JavaScript erm¨oglicht es dies dynamische Rich-Client-Webseiten zu erstellen. SignalR u ¨bertr¨agt Daten mithilfe von von HTML5 WebSockets zwischen Client und Server. SignalR wird darum oft f¨ ur 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 k¨ onnen, ohne eine Zeile Code schreiben zu m¨ ussen. Der Entwickler kann so mit Drag-and-Drop schon fertiggestellte Steuerelemente auf der Webseite platzieren. Die fertigen Elemente beinhalten bereits s¨amtliche Funktionalit¨aten inklusive Der Kompatibilit¨ at 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 s¨amtliche Zust¨ande und Daten der

18

Steuerelemente einer Seite. Dies ergibt einen enormen Speicherumfang. Da diese Werte bei dem HTTP-Response zur¨ uck zum Client geschickt werden m¨ ussen, hat die Dateigr¨ oße Auswirkungen auf die Ladezeiten der Webseite. ˆ MVC ASP.NET MVC bietet an Webseiten m¨ oglichst 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 f¨ ur ein gr¨oßeres Entwicklungsteam. Im Gegensatz zu den WebForms wird f¨ ur 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 ussig und der Entwickler kann sich selber um alle Zust¨ande der Seite ¨berfl¨ k¨ ummern.

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 f¨ uhrt das gew¨ unschte Event aus. ¨ – Auth: Uberpr¨ uft ob der Benutzer u ¨ber die ben¨otigten Rechte besitzt. – Controller: Der Controller f¨ uhrt das Event aus indem die gew¨ unschte Methode ausgef¨ uhrt 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 f¨ ur den Client. Dieser wird vom Server zum Benutzer geschickt. Da wir die Vorteile bei dem ASP.NET MVC 4 h¨oher eingestuft haben als bei den WebForms haben wir uns f¨ ur dieses Konzept des ASP.NET Frameworks entschieden. Ext.NET Unsere Pr¨ asentationsschicht wurde mit dem Ext.NET Framework entwickelt. Das Ext.NET Framework [12] bietet bereits vorgefertigte Elemente an, welche man f¨ ur die View verwenden kann. Die einzelnen Elemente k¨onnen einfach u ¨ber verschiedene Sprachen aufgerufen und implementiert werden. Razor-Engine F¨ ur die Implementierung der Ext.NET-Elemente wurde die Razor-Engine verwendet. Razor wurde f¨ ur 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-Bl¨ocke einzuf¨ ugen. Der Parser erkennt diese sofort und kann diese verarbeiten. Dies erm¨oglicht es m¨oglichst kurzen und sauberen Code f¨ ur die View zu programmieren. ˆ Funktioniert mit jedem Texteditor Razor ben¨ otigt keine weiteren Programme und l¨ asst sich einfach in einem Texteditor bearbeiten. ˆ Testbarkeit Razor bietet ohne einen Controller oder Web-Server erstellen zu m¨ ussen Unit-Tests an.

20

7.2

Datenbank

F¨ ur die Speicherung der Daten haben wir eine Datenbank in Microsoft SQL-Server 2012 erstellt. Diese Datenbank stellt eine Relationales Datenbankmodell dar. F¨ ur Testzwecke und aus Mangel eines Servers haben wir unsere Datenbank lokal u ¨ber den localhost gehostet.

7.3

NHibernate

F¨ ur 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 Datens¨ atzen 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 m¨ ussen wir zu jedem Datenmodell eine .xml-Datei erstellen. 21

Zus¨atzlich zu den xml.-Dateien muss eine hibernate.xml-Datei, welche die Konfigurationsdatei unserer Session ist,erzeugt werden. 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 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. Standardm¨ aßig bei NHibernate: NHibernate.Connection.DriverConnectionProvider. ˆ Der ConnectionDriver gibt an welcher Treiber verwendet werden soll. In unserem Fall der Treiber f¨ ur 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. Zus¨atzlich 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 f¨ ur die Datenbank verwendet wird.

Damit eine Datenbankverbindung ge¨offnet werden kann wird eine Klasse erstellt in ¨ unserem Fall NHibernateSession, welche eine Methode zum Offnen der Sitzung zur Verf¨ ugung 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 sp¨ ater f¨ ur die Steuerungsschicht ben¨otigt, damit diese ¨ auf die Datenbank zugreifen kann. Nach dem Offnen der Verbindung k¨onnen mittels SQL Befehle auf der Datenbank ausgef¨ uhrt werden. Die Befehle werden auf der Datenbank ausgef¨ uhrt und verarbeitet. Anschließend wird das Ergebnis gemappt und an die Steuerungsschicht zur¨ uckgeschickt.

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 f¨ ur 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 erkl¨ art: ˆ Dienstausrichtung Durch die Verwendung von WS-Standards ist es m¨ oglich, mit WCF dienstorientierte Anwendungen zu erstellen. Der Vorteil in der dienstorientierten Architektur ist, dass die Anwendungen untereinander lose verkn¨ upft sind und nicht hartcodiert programmiert werden m¨ ussen. So kann ein beliebiger Client auf einen beliebigen Dienst verbunden werden, solange die wesentlichen Voraussetzungen gegeben sind. ˆ Interoperabilit¨ at Aktuelle Standards f¨ ur Webdienstinteroperabilit¨at sind in WCF gegeben. ˆ Mehrere Nachrichtenmuster Nachrichten k¨ onnen 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 unterst¨ utzt weiters die Standards von Formaten wie zum Beispiel WSDL, XML. Diese Metadaten k¨onnen verwendet werden, um automatisch Clients f¨ ur die Verbindung zu WCF-Service zu generieren und konfigurieren. Metadaten k¨ onnen mittel HTTP oder HTTPS ver¨offentlicht werden. ˆ Datenvertr¨ age WCF enth¨ alt ein umfassendes System, welches die Arbeit mit Daten vereinfacht. Der einfachste Weg zur Verwaltung ist die Erstellung von Klassen, welche eine Datenenti¨ at darstellen. Nachdem diese Klassen erstellt wurden, werden vom Dienst automatisch Metadaten bez¨ uglich der Klassen erstellt. ˆ Sicherheit WCF bietet an Nachrichten zu kodieren oder Benutzer, bevor Sie Berechtigung zum Empfangen und Senden bekommen, sich einloggen zu m¨ ussen. Sicherheit kann zum Beispiel mithilfe von SSL verwirklicht werden.

23

ˆ Mehrere Transporte und Codierungen Nachrichten k¨ onnen in WCF auf eine oder mehrere Protokolle und Kodierungen gesendet werden. Standardm¨aß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 wunschgem¨aß l¨auft.

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) f¨ ur das Konzept der Endpunkte:

Abbildung 9: ABC-Prinzip von WCF [18] ˆ A - Address Die Adresse ist eine eindeutiger Identifier f¨ ur 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 ben¨otigt. Es wird das Transportprotokoll und die Art der Codierung angegeben. ˆ C - Contract Der Vertrag definiert die Funktionalit¨ at des Services. Falls notwendig, muss f¨ ur benutzerdefinierte Datentypen ein DataContract erstellt werden.

F¨ ur das Versenden von Daten ist die WCF-Architektur in 2 Grundschichten unterteilt. Der Service Layer definiert die Mechanismen und Attribute um die Nachrichten- und Datenvertr¨ age definieren zu k¨ onnen. Die Nachrichtenschicht ist f¨ ur die Herstellung und ¨ Ubertragung einer WCF-Nachricht zust¨andig. 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 Protokollkan¨alen zusammengesetzt. Auf der Benutzerseite ist es die Aufgabe der Proxykomponente und auf der Serviceseite der Dispatcherkomponente die zwei Schichten unterscheiden zu k¨onnen 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 m¨ oglichst 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 erm¨oglicht gleichzeitig an den Schichten zu arbeiten ohne auf gr¨ oßere Komplikationen zu treffen. F¨ ur 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). Zus¨atzlich zu den bereits vorhandenen Datenmodellen haben wir zwei weitere Datenmodelle File und FileType hinzugef¨ ugt. Diese werden genauer im n¨achsten Kapitel 9.1 erkl¨art. 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 f¨ ur 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 dazugeh¨origen XML-Mappingklasse aus der Datenbank ausgelesen werden. Zus¨atzlich zu den Controllerklassen des Models befindet sich der LoginController. Der LoginController u uft ebenfalls mittels einer NHibernateverbindung das ¨berpr¨ eingebene Passwort beziehungsweise f¨ ur die zweite Stufe die Kundennummer und ¨ Projektnummer. Uber 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 ur jede Einlogstufe gibt es einen eigenen ¨ber Cookies. F¨ 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 Benutzeroberfl¨ ache 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 Men¨ u, u ¨ber welches der Benutzer navigieren kann. Durch Buttonklicks im Men¨ u kann der Benutzer verschiedenste Windows ¨offnen. Falls sich der Benutzer in die zweite Stufe einloggt wird zus¨atzlich zur Homeview AccountMgmt ¨ und Products freigeschaltet. Uber diese zus¨atzlichen Views kann sich der Benutzer seine Daten bez¨ uglich seines Projektes und seiner Produkte holen. Außerdem werden wie schon im Controller erw¨ahnt u ¨ber den Auth-Controller zus¨atzliche Men¨ upunkte 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 fr¨ uher erw¨ahnt soll die erste Stufe mit einem einmaligen Passwort erreichbar sein. Die zweite Stufe soll u ¨ber die Eingabe einer g¨ ultigen Kundennummer und einer g¨ ultigen Projektnummer erreichbar sein. Zus¨atzlich zum 2-Stufen-Login soll sich ein Administrator einloggen k¨onnen. 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 uft. Je nachdem, welches Cookie an den Server geschickt wird werden Elemente ¨berpr¨ entsprechend der eingeloggten Stufe an der View f¨ ur den Benutzer dargestellt. Cookies [13] Cookies sind kleine Textdateien f¨ ur benutzerspezifische Informationen. Sie enthalten meist Daten u ber besuchte Webseiten. Weiters ist es m¨oglich mittels Cookies den ¨ Zugriff zu verschl¨ usselten Seiten zu merken. Dies funktioniert u ¨ber einen vorgegebenen Zeitraum und am selben Rechner, da die Cookies lokal abgespeichert werden. F¨ ur unsere Software haben wir HTTP-Cookies verwendet, welche mittels des HTTP-Protokolls kommunizieren (siehe Abbildung 12). Unser Client schickt einen HTTP-Request f¨ ur die angeforderte Webseite an den Server. Der Server antwortet mit einem HTTP-Response, welcher die angeforderte Webseite und ein Cookie f¨ ur die aktuelle Session beinhaltet. Solange der Client u ugt schickt er bei ¨ber einen Cookie verf¨ 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

F¨ ur unsere Software haben wir 3 HTTP-Cookies erstellt: ˆ Cookie fu ur die erste Stufe ist wie folgt aufgebaut: ¨ r 1. Stufe: Der Cookie f¨

Name: CIP

Wert: 1.Stufe(verschl¨ usselt)

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 verschl¨ usselter Wert f¨ ur die erste Stufe. Die Zeit bis zum Ablauf des Cookies betr¨ agt 30 Minuten und wird bei jedem Refresh der Seite wieder bei 30 Minuten gestartet. ˆ Cookie fu ur die Administration-Stufe ist wie ¨ r Administrator: Der Cookie f¨ folgt aufgebaut:

Name: CIP

Wert: AdminStufe(verschl¨ usselt)

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 verschl¨ usselter Wert f¨ ur die Administrationsstufe. Die Zeit bis zum Ablauf des Cookies funktioniert gleich wie beim Cookie f¨ ur die 1. Stufe. ˆ Cookie fu ur die 2. Stufe ist wie folgt aufgebaut: ¨ r Administrator: Der Cookie f¨

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 f¨ ur die 1. Stufe.

8.3

Abarbeitung Benutzereingaben

In unserer Software hat der Benutzer mehrere M¨oglichkeiten Informationen mittels einer Eingabe abzufragen. Wie schon im Kapitel Architektur 8.1 erw¨ahnt haben wir f¨ ur die Verbindung von unserer Software zur Datenbank NHibernate verwendet um diese Informationen zu bekommen. Dazu wurde in unserer Software die n¨otigen Mappingklassen und eine Sessionklasse, welche die Session ¨offnet an angelegt. Im folgenden Abschnitt der Abbildung wird ein Prozessablauf einer Benutzeranfrage dargestellt (siehe Abbildung 13). 1. Der Benutzer bet¨ atigt eine Eingabe in der View, entweder u ¨ber einen Button oder durch Einf¨ ugen 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 ge¨ offnet werden, falls diese noch nicht existiert. 4. Anschließend wird mittels SQLQueries auf die Datenbank zugegriffen. 5. Der Controller empf¨ angt das Resultat der SQL-Anfragen als Liste von Objecten. 6. Die empfangenen Daten werden auf die Datentypen des gew¨ unschte Datenmodells gecastet. 7. Diese Daten werden zum Schluss an die View geschickt und dort dem Benutzer pr¨ asentiert. 30

8.4

Webservice

Damit Daten aus dem ERP-System in die Datenbank eingespeist werden k¨onnen 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 k¨onnen 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 ¨ offnet 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 erkl¨art wie wir die Konzepte und Technologien in unserer Software implementiert haben. Wie schon in dem Kapitel Konzepte 8 erkl¨art haben wir unser System nach dem MVC-Muster aufgebaut. Die einzelnen Umsetzungen der Elemente des MVC-Musters unseres Programmes werden nun in Unterkapiteln erkl¨art.

9.1

Model

Das Datenmodell wurde bereits schon genauer im Kapitel Anforderungen 5 definiert. Wie schon erw¨ ahnt beinhaltet das Model die Strukturen der Daten unserer Software. Zus¨atzlich zu den bereits vorhandenen Datenmodellen haben wir zwei weitere Models (siehe Abbildung 15) programmiert um die Normen und Datenbl¨atter abspeichern zu k¨onnen.

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 f¨ ur den Speicherort des Dokumentes abgespeichert. Die Flag Hidden erm¨ oglicht es Dokumente, welche nicht mehr relevant sind, zu

32

verstecken. Das File-Modell verf¨ ugt 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 ben¨otigt um die Ausgabe exakt an das Modell anpassen zu k¨onnen. ˆ 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 ben¨otigt wiederum f¨ ur die Pr¨ asentationsschicht ben¨otigt.

9.2

Controller und View

Die Steuerungsschicht beziehungsweise der Controller ist zust¨andig f¨ ur den Datentransfer zwischen der Datenmodellschicht und der Pr¨asentationsschicht. Der Controller bekommt von der Pr¨ asentationsschicht 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 Pr¨asentationsschicht. Steuerung der Authentifizierung Wie schon im Konzept beschrieben verf¨ ugt unser Webportal u ¨ber ein 2-Stufen-Modell. Die erste Stufe soll mit einem einmaligen Passwort erreichbar sein. Die zweite Stufe soll u ultigen Kundennummer und einer g¨ ultigen Projektnummer ¨ber die Eingabe einer g¨ erreichbar sein. Zus¨ atzlich zum 2-Stufen-Login soll sich ein Administrator einloggen k¨onnen. Damit unsere Software weiß, wann beziehungsweise wer sich eingeloggt hat, verwenden wir Cookies. Der Aufbau der Cookies wurde bereits fr¨ uher erkl¨art (siehe Kapitel 8). Die Verwaltung dieser Cookies u ¨bernehmen bei uns die Controllerklassen CustomAuthorization und CookieStore. Der CookieStore verf¨ ugt 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 ben¨otigt damit die Methode weiß in welcher Stufe der Benutzer sich gerade befindet. Die weiteren zwei Methoden liefern entweder den momentanen Cookie zur¨ uck oder l¨oschen den Cookie. Um einen Cookie zu l¨ oschen wird der Zeitstempel zum Ablauf des Cookies auf die jetzige Zeit minus einer Sekunde gesetzt. Dieser l¨ auft damit automatisch ab und wird gel¨oscht. 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 ben¨ otigt um die Daten der Cookies mittels MD5Hash zu verschl¨ usseln. ˆ 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 f¨ ur die verschiedenen Stufen des Portals. ˆ CheckPermission u uft die Berechtigungen der Benutzer. Dazu wird das ¨berpr¨ momentane Cookie ausgelesen und ermittelt in welcher Stufe sich der Benutzer befindet. Je nachdem ob der Benutzer u ugt antwortet ¨ber die n¨otigen Rechte verf¨ diese Methode postiv oder negativ(bool). ˆ ShowMenu steuert das Men¨ u in der Pr¨asentationsschicht (siehe Steuerung der Pr¨ asentationsschicht). Dazu werden die einzelnen Men¨ uelemente je nach Stufe freigeschaltet oder ausgeschaltet. ˆ Restlichen Methoden: Die restlichen Methoden werden in den oben genannten Methoden ben¨ otigt um bestimmte Sachen, wie zum Beispiel die Kundennummer aus dem Cookie lesen zu k¨onnen.

34

Pr¨ asentationsschicht und ihre Steuerung In diesem Kapitel wird die Pr¨ asentationsschicht und ihre Steuerung unserer Software erkl¨art. Die Pr¨ asentationsschicht ist zur grafischen Ausgabe f¨ ur den Benutzer zust¨andig. Unsere Pr¨ asentationsschicht wurde mit der Razor-Engine entwickelt. F¨ ur 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 Pr¨ asentationsschicht eng mit der Steuerungsschicht zusammenarbeitet, werden im folgenden Teil die einzelnen Ansichten und Fenster der Pr¨asentationsschicht erkl¨ art, 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 f¨ ur das Passwort ist. Das zweite Element ist der Button mit dem der Benutzer den Einlogprozess triggert. Nachdem der Button gedr¨ uckt wurde bekommt der CIPController die Meldung, dass der Einlog-Button aufgerufen wurde. Dieser ruft dann den dazugeh¨ orige Controller LoginController auf und startet diesen. Im LoginController wird das Passwort mittels der in dem Kapitel Steuerung der Authentifizierung beschriebenen Methode SetPermission() gepr¨ uft ob das g¨ ultige 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 f¨ ur 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 f¨ ur die verschiedenen Dokumente erstellt. Als Layout wurde ’Fit’ verwendet, da die Liste der Dokumente dynamisch ver¨andert 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 eingef¨ ugt. Durch ein Plugin f¨ ur das ColumnModel-Element lassen sich Dokumente auf/einklappen um Informationen und den Downloadlink anzuzeigen. Der Downloadlink wurde mittels HTML eingef¨ ugt und ¨ bei Klick auf diesen wird das Dokument auf den lokalen Rechner geladen. Uber dem GridPanel am oberen Rand der Seite wurde der Container Toolbar verwendet, welche eine Men¨ uleiste darstellt. In der Men¨ uleiste 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 Men¨ upunkte: Der erste ¨ offnet einen Container Window, in dem nach Dokumenten gesucht werden kann. In diesem Fenster wird ein FormPanel verwendet, um die Filter der Suche anzeigen zu k¨ onnen. Der erste Filter ist der Dateiname und ist als Textfield-Element dargestellt. Hier kann der Benutzer nach dem vollst¨andigen 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 l¨oscht 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 f¨ ur 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 k¨ onnen, m¨ ussen die Daten auf ihren Typ gecastet werden. Anschließend werden die gefundenen Dokumente gleich wie beim Button ’Start’ ausgegeben. Der zweite Men¨ upunkt 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 ¨ offnet 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 uft. Bei Erfolg wird die Startseite der ¨berpr¨ zweiten Stufe angezeigt und das n¨otige 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 Uber 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 gel¨oscht.

38

2. Stufe Die Startseite der zweiten Stufe (siehe Abbildung 21) bildet wie bei der ersten Stufe den Ausgangspunkt. Zus¨ atzlich 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 dazugeh¨origen Projekts an.

Abbildung 21: Screenshot - Zweite Stufe 39

F¨ ur 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 k¨onnen. ˆ 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 zust¨ andigen Betreuers an. Bei diesem FormPanel wurden die Attribute ’Collapsed’ und ’Collapsible’ auf true gesetzt. Dies erm¨ oglicht es, dass bei Aufrufen der Startseite das ¨ Betreuer-Panel automatisch zugeklappt ist. Uber einen Mausklick auf den Panel-Head l¨ asst sich dieses ein/ausklappen. Der Betreuer wird aus mithilfe der Kundennummer und des CustomerControllers geladen.

Die Men¨ ubar der ersten Stufe wird um zwei Buttons erweitert. Die Software fr¨agt dazu 40

bei jedem erneuten laden einer Seite das aktuelle Cookie ab. Je nachdem welches Cookie gesetzt wurde, werden die einzelnen Buttons der Men¨ uliste versteckt beziehungsweise angezeigt. Die zwei Buttons der zweiten Stufe sind ’Mein Konto’ und ’Produkte’: ˆ Button: Mein Konto Der Button Mein Konto l¨ adt die Profilseite. ˆ Button: Produkte Der Button Produkte funktioniert ¨ ahnlich wie der Button Normen. Auch hier hat der Button zwei Men¨ upunkte:

Abbildung 23: Screenshot - Produkte Der erste Men¨ upunkt ¨ offnet die Ansicht der Produkte (siehe Abbildung 23) f¨ ur 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 Eintr¨ agen 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 Men¨ upunkt bietet eine Suche nach Produkten an. Wie schon bei der Dokumentensuche wird ein Container Window ge¨offnet. Dieser ist komplett 41

Home

Products Windows

Menu

CIPController

Position

Abbildung 24: UMLKlassendiagram f¨ ur Produkte

gleich wie der der Dokumentensuche aufgebaut. Einzig die Combobox ist nicht vorhanden. Mit dem ersten Textfield l¨asst sich nach der Produktnummer filtern und mit dem zweiten nach dem Produktnamen. Die zwei Datefields sind wieder zust¨ andig um einen Zeitraum zu definieren. Das Ergebnis wird dann in der gleichen Ansicht wie beim ersten Men¨ upunkt ausgegeben.

Administrator Stufe Die Startseite der Administrator Stufe (siehe Abbildung 25) bildet wie bei der ersten Stufe wieder den Ausgangspunkt. Die Men¨ uleiste 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 ¨ offnet ein Container Window. F¨ ur das Fenster wird ein FormPanel mit dem dazugeh¨origen 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 n¨otigen Informationen des hochzuladenden ¨ Dokuments angegeben. Uber 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 ge¨ offnet. 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 erm¨ oglicht es, ein neues Auslaufdatum des Projektes anzugeben. Dazu wird standardm¨aß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 ¨ andern Der Button Passwort a¨ndern o¨ffnet abermals ein ¨ Fenster. Uber zwei Textfields und ein Button wird das Passwort ge¨andert. Es muss zwei mal das neue Passwort eingegeben werden. Nach dem der Button den Controller CIPController triggert wird das Passwort in diesem mit Md5Hash verschl¨ usselt und in der Datenbank abgespeichert.

9.3

WCF

Der WCF-Service soll Daten aus dem ERP-System in die Datenbank einf¨ ugen. Der Dienst soll Methoden zum Einf¨ ugen von Daten der Kunden, Projekte, ERPDokumente und Produkte anbieten. Wir haben uns mit der Firma din geeinigt nur den Service zu schreiben, die Webanwendung f¨ ur den Service wird anschließend von der Firma din entwickelt. Das ABC-Prinzip wie schon in der Einf¨ uhrung 7 erkl¨art wurde wie folgt verwirklicht: ˆ Adresse Die Adresse unseres Webservice ist die SQL-Datenbank des Kundeninformationsportals. Die Verbindung l¨auft wie schon bei dem Kundeninformationsportal u ¨ber NHibernate. Die Session wird wieder, mittels der selben hibernate.xml Konfigurationsdatei initialisiert. Jedoch werden f¨ ur den Webservice diesmal keine .xml-Datein der Modelle ben¨otigt. 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 f¨ ur den Service werden die Vertr¨age f¨ ur den Service erstellt. Dazu wurden vier OperationContracts angelegt. Diese vier Vertr¨age sind die Methoden, welche der Webservice anbietet um die Daten der Kunden, Projekte, ERPDokumente und Produkte zu verschicken(InsertCustomer, InsertERPDocument, InsertPosition, InsertProject). F¨ ur 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 eingef¨ ugt. 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 eingef¨ ugt. ˆ InsertProject Die Methode InsertProject() funktioniert gleich wie die Methode zum Einf¨ ugen des Kunden. ˆ InsertERPDocument Die Methode InsertERPDocument f¨ ugt 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 eingef¨ ugt werden. ˆ InsertPosition Diese Methode bekommt die Daten eines Produktes und die ERPDokumentnummer und den ERPDokumenttyp. Zuerst wird das Produkt in die zugeh¨ orige Relation ’Positions’ eingef¨ ugt. 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 ben¨otigt um einen neuen Eintrag in die Relation ’PostionList’, welche die Verbindung des ERPDokuments mit den Produkten herstellt, einzuf¨ ugen.

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 durchgef¨ uhrt. Der zweite Teil beschreibt das selbst-entworfene Abnahmeprotokoll.

10.1

Evaluierung durch Use-Cases

Im Folgenden wird jeder Use-Case erl¨autert und anschließend die Umsetzung in unserer Software Schritt f¨ ur Schritt aufgezeigt.

Einloggen in die erste Stufe Das Einloggen in die erste Stufe erfolgt u ¨ber ein globales Passwort, welches f¨ ur alle Kunden dasselbe ist. In dieser Stufe erh¨alt 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 dazugeh¨orige Dokumente einsehen. Um zum Login f¨ ur 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 ¨offnet sich ein ” Dialog zur Eingabe der Daten (Abbildung 29).

Abbildung 28: Button zum ¨offnen des Login Dialogs f¨ ur den zweiten Schritt 46

Abbildung 29: Dialog zum Einloggen in die zweite Stufe mit der benutzerspezifischen Kundennummer und Projektnummer Bei falscher Kundennummer, sowie ung¨ ultiger 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 erm¨ oglicht, sobald man sich in die erste Stufe eingeloggt hat. Die Informationen werden in einer Tabelle angezeigt. Erweitert man eine Zeile, erh¨alt 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 erh¨ alt 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 verf¨ ugbar, sobald man sich in der zweiten Stufe der Oberfl¨ache 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

¨ Uber das Produktmen¨ u (Abbildung 33) gelangt man zu einer Tabelle mit den projektbezogenen Positionen (Abbildung 34). 49

Abbildung 33: Button zum Erreichen des Produktmen¨ us 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 Administratoroberfl¨ ache der Webseite. ¨ Passwort ¨ andern Unter diesem Use-Case wird das Andern des Benutzerpasswortes verstanden. Dieses ist das Passwort, welches man zum Einloggen in die erste Stufe ¨ ¨ ben¨ otigt. Zum Offnen des Passwort-Andern-Dialogs wird im Men¨ u die Option Passwort ¨ andern“ (Abbildung 35) gew¨ahlt. ”

¨ ¨ Abbildung 35: Button zum Offnen des Dialogs zum Andern des Passwortes 50

Dokumente verstecken Beim Hochladen eines Dokuments hat der Administrator die M¨oglichkeit, ein Dokument als versteckt“ zu markieren. Dadurch ist das ” Dokument und die zugeh¨ origen 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 Andern eines Projektes (Abbildung 38) gegeben. Hierzu wird einfach die Option Projekt ” sperren“ gew¨ ahlt und das Projekt gespeichert. Von diesem Moment an, kann sich der Kunde mit diesem Projekt nicht mehr in die zweite Stufe einloggen.

Zugang verl¨ angern Jedes Projekt hat ein Datum, bis zu welchem der Benutzer Zugang dazu hat. Verz¨ ogert sich ein Projekt und dauert daher l¨anger als urspr¨ unglich angenommen, kann der Administrator das Enddatum neu setzen. Diese Option ist mit dem Men¨ upunkt Projekt verwalten“ (Abbildung 37) erreichbar. ” 51

¨ ¨ Abbildung 37: Button zum Offnen des Dialogs zum Andern des Projektes Im sich ¨ offnenden Dialog kann ein Datum ausgew¨ahlt und das Projekt anschließend gespeichert werden (Abbildung 38).

¨ Abbildung 38: Dialog zum Andern des Projektes

Einspielen von Dokumenten Ein Administrator hat die M¨oglichkeit, Dokumente in das System einzuspielen. Hierzu muss er folgende Daten bereitstellen: ˆ Dateiname: der Name, wie er sp¨ ater in der Dateiliste (Abbildung 31) angezeigt wird ˆ Dateityp: hier wird ausgew¨ ahlt, 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 k¨ onnen ˆ Datei: die Datei, welche hochgeladen werden soll

Der Dialog f¨ ur den Datei-Upload (Abbildung 36) ist u ¨ber den Hochladen“-Button ” (Abbildung 39) zu ¨ offnen.

¨ Abbildung 39: Button zum Offnen des Dialogs zum Hochladen einer Datei 52

Einspielen von Daten Das Einspielen von Daten ist als einziger Anwendungsfall nicht u ache m¨ oglich. Dieser Usecase wird u ¨ber die Weboberfl¨ ¨ber den WCF-Service realisiert, der im Abschnitt 9.3 erl¨ autert wird.

10.2

Evaluierung durch Abnahmeprotokoll

F¨ ur die Abnahme der technischen Arbeit durch den Auftraggeber, wurde ein minimales Abnahmeprotokoll entworfen. Unter Anwesenheit eines Entwicklers wird das Abnahmeprotokoll ausgef¨ ullt. 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 Anderung des Dokuments ˆ Status: der aktuelle Status der Abnahme, wobei die Status in Bearbeitung, vorgelegt oder akzeptiert m¨oglich sind

¨ 2. Historie: Die Historie beschreibt die Entwicklung des Abnahmeverlaufes. Andert sich der Status des Dokuments, erh¨alt die Historie einen neuen Eintrag. Angemerkt werden hier folgende Daten: ˆ Version ˆ Datum ˆ Autor ˆ Von Status ˆ Zu Status ˆ Bemerkung

3. Funktionalit¨ at: In diesem Abschnitt befindet sich die Tabelle, in welcher die n¨otigen Funktionalit¨ aten laut Usecases aufgelistet sind. Zu jeder Funktionalit¨at bestehen folgende Informationen: ˆ Funktion ˆ Status der Funktion: nicht vorhanden, mangelhaft oder akzeptiert

Die betreffende Funktionalit¨ at 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 f¨ ur 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 n¨ otig, um eine Koordination umsetzen zu k¨onnen. 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 erm¨oglicht eine Installation auf einen eigenen Server. Durch den Webzugriff von GitLab ist eine einfache, u ¨bersichtliche und funktionsreiche Verwendung mehrerer Repositories m¨oglich. Von den vielen Funktionalit¨ aten der Serversoftware wurden folgende f¨ ur die Umsetzung des Projektes verwendet: ˆ Webzugriff auf Dateien: Der direkte Zugriff auf Dateien bietet eine gute M¨oglichkeit, Dokumente, wie Bilder, Pr¨asentationsfolien oder auch Sourcecode schnell betrachten zu k¨ onnen, ohne das gesamte Respository klonen zu m¨ ussen. ˆ Wiki: Das softwareinterne Wiki wurde verwendet, um allgemeine Informationen zu speichern und zug¨ anglich zu machen. Hier wurden Weblinks und Projektinformationen gespeichert. ˆ Issues: GitLab verf¨ ugt u urlich ¨ber ein eigenes Bugtrackingsystem. Dieses ist nat¨ im Vergleich zu BugZilla oder ¨ ahnlicher Software sehr einfach und nicht mit ann¨ahernd viel Funktionalit¨ at ausgestattet, es reicht allerdings aus, um kleinere Bugs vermerken und bestimmten Usern zuteilen zu k¨onnen.

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 M¨oglichkeit, f¨ ur verschiedene Projekte, Benutzer, Kunden und Aktivit¨ aten die in Anspruch genommene Zeit zu tracken. Zus¨atzlich zur Zeitaufnahme k¨ onnten auch Kosten (mit Stundens¨atzen) berechnet und automatisch Rechnungen erstellt werden. Eine weitere, sehr n¨ utzliche Funktionalit¨at ist das Exportieren der Daten. Somit kann zum Beispiel die gesamte Zeittabelle f¨ ur ein bestimmtes Projekt als .xls exportiert werden. In dieser Bachelorarbeit wurde mit diesem Tool die Arbeitszeit f¨ ur folgende Aktivit¨aten getrackt: 59

ˆ Preparation: In dieser Kategorie wurden alle Vorbereitungen aufgezeichnet, wie zum Beispiel das Einarbeiten in ein Framework, Durchgehen von Tutorials oder ahnliches. ¨ ˆ Documentation: Hier wurden die Zeiten f¨ ur die Erstellung von Dokumenten (Pr¨ asentationen, Diagramme, etc.) gesammelt. Nicht mehr aufgezeichnet wurden die Zeiten f¨ ur die Erarbeitung des schriftlichen Teils dieser Bachelorarbeit oder das Auswerten der Statistiken. ˆ Development: Diese Kategorie war die meistgen¨ utzte - 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 erl¨ autert, 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 ber¨ ucksichtigt. Am Projekt wurde von Mai 2014 bis inklusive M¨arz 2015 gearbeitet. Gesamt wurden 232,43 Stunden investiert. Diese Gesamtdauer teilt sich wie folgt auf die einzelnen Aktivit¨ aten 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 meistgen¨ utzten 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 H¨alfte - der Commits abgesetzt.

11.3

Projektmanagement

In diesem Abschnitt werden die angewandten Projektmanagementmethoden vorgestellt und erl¨ autert, wie sie in diesem Projekt zum Einsatz gekommen sind. Arbeitsteilung Da die Bachelorarbeit zu zweit ausgearbeitet wurde, mussten nat¨ urlich die verschiedenen Bereiche der Arbeit so weit wie m¨oglich, 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 Einf¨ uhrung 7 – Konzept 8 – Technische Details 9 Extreme Programming Im Projekt wurde grunds¨atzlich Extreme Programming als Vorgehensweise der Softwareentwicklung gew¨ahlt. Die Gr¨ unde daf¨ ur sind die Eigenschaften des Verfahrens: Einfachheit, Kommunikation, Feedback und Mut“ [10]. ” Da f¨ ur 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 Gesch¨aftswerte des Projektes vor. ˆ Entwickler: Die Entwickler werden im Extreme Programming als Einheit ¨ gesehen und nach außen hin nicht nach Spezialgebieten oder Ahnlichem unterteilt. Die Entwickler erf¨ ullen die Anforderungen des Kunden. ˆ Manager: Ein Manager oder ein Managementteam ist bei gr¨ oß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 Gr¨oß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 n¨achsten Zyklus festgelegt. In diesem Projekt wurden diese Zyklen etwas großz¨ ugiger ausgelegt, da die Anforderungen und Usecases ¨ von Anfang an klar definiert wurden. Ublicherweise 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: W¨ ahrend der Pair-Programming-Phase wird der Code f¨ ur das Iterationsziel geschrieben. Da das Entwicklerteam als Einheit arbeitet, wird zum Großteil gemeinsam an einem Computer entwickelt. Diese Methodik bietet ¨ eine Uberpr¨ ufung des Codes durch eine zweite Person zur Zeit der Programmierung und verhindert somit einige Fehler. Bei diesem Projekt wurde ungef¨ ahr ein Drittel der Zeit in Pair Programming entwickelt. Wir Entwickler trafen uns regelm¨ aßig f¨ ur 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 gr¨ oßeren Rahmen der Software auswirken k¨onnen und sorgt f¨ ur einen konsistenten Zustand des Programmes. Diese Tests werden ausgef¨ uhrt, sobald Code geschrieben wurde, der auf Funktionalit¨at getestet werden kann. Auch in unserem Projekt wurden regelm¨aßig Unit Tests durchgef¨ uhrt. Nachdem die Ziele f¨ ur den Entwicklungstag beim Stand Up Meeting vereinbart wurden, wurde die Umsetzung regelm¨ aßig und vor jedem Commit mit Unit Tests getestet. ˆ Pair Negotiation: Unter Pair Negotiation versteht man k¨ urzere Absprachen

64

unter den Entwicklern. Sie f¨ ordern 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 ufen. ¨berpr¨ ˆ Stand Up Meeting: Diese Besprechung wird t¨ aglich vor Beginn der Entwicklung abgehalten. Bei diesem kurzen Meeting wird besprochen, was am Vortag geleistet wurde und was die Ziele f¨ ur den aktuellen Tag sind. Sollten am Vortag Probleme bei der Ausarbeitung von Code aufgetreten sein, wird besprochen, wie diese behoben werden k¨onnen. 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 durchgef¨ uhrt und dient zur Evaluierung, ob der neu-entwickelte Softwareteil den Anforderungen des Kunden gen¨ ugt. An diesem Punkt k¨ onnen sich neue Priorit¨ aten ergeben oder Verbesserungsvorschl¨age seitens der Entwickler eingebracht werden. Die Akzeptanztests sind die einzige Methode der XP-Iteration, welche nicht regelm¨ aßig durchgef¨ uhrt wurde. Es gab in diesem Projekt einen großen Akzeptanztest am Ende, welcher gleichzeitig der Evaluierung diente. Zus¨atzlich wurden zirka 2 - 3 kleine Akzeptanztests bei Meetings mit dem Kunden durchgef¨ uhrt. Hier wurde auf einem Entwicklungsnotebook kurz vorgezeigt, wie die vorgegebenen Aufgaben erf¨ ullt wurden und m¨ogliche 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 ver¨ offentlicht, beginnt ein neuer, sogenannter Release ” Plan“ und mit ihm auch neue Iterationen.

65

12

Zusammenfassung

In u ¨ber 230 Stunden wurde ein Webinformationsportal mit zugeh¨origer Webservice-Schnittstelle entwickelt, welches den Anforderungen der Firma din-Dietmar Nocker Sicherheitstechnik GmbH entspricht. Diese Anforderungen umfassten Technologievorgaben, Anwendungsf¨alle und die Verwendung und Wartung von vorhandenen Datenstrukturen. Die Technologievorgaben wurden wie gefordert erf¨ ullt und somit kommt in unserem Projekt ein Microsoft SQL-Server f¨ ur die Speicherung, sowie ein WCF-Service zum Einspielen der Daten zum Einsatz. Das Datenmodell an sich wurde verst¨ andlich und strukturiert in ein Datenbankschema u ¨bergeleitet und ist somit komfortabel wartbar. Weiters wurde die gew¨ unschten Technologie Microsoft MVC unter der zus¨ atzlichen Verwendung vom Ext.NET Framework f¨ ur 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 Uberpr¨ ufung der jeweiligen Logins. Die Speicherung von Authentifizierungen wurde mithilfe von Cookies umgesetzt. Somit wurde auch f¨ ur diesen Usecase eine elegante L¨ osung 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 Verf¨ ugung: 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 Anwendungsf¨alle wurden vollst¨andig 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 f¨ ur uns gr¨oßtenteils unbekannt und somit bedurfte es hier einige Einarbeitungszeit und das Befassen mit deren Dokumentationen. Da wir allerdings die Tools, welche f¨ ur die Umsetzung des Projektes genutzt wurden, bereits kannten, war hier wenig Aufwand zum Kennenlernen dieser n¨otig. 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 f¨ ur 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 f¨ ur Kunden und Datenquelle . . . . . . . . . . . . . . . Usecasediagramm f¨ ur 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 f¨ ur Produkte . . . . . . . . . . . . . . . . . . . . . . Screenshot - Adminstufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . UMLKlassendiagram - Adminstufe . . . . . . . . . . . . . . . . . . . . . . Dialog zum Einloggen in die erste Stufe mit dem globalen Passwort . . . . Button zum ¨ offnen des Login Dialogs f¨ ur 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 Produktmen¨ us . . . . . . . . . . . . . . . . . . Tabelle zur Ansicht der einzelnen Position des Projektes . . . . . . . . . . ¨ ¨ Button zum Offnen des Dialogs zum Andern des Passwortes . . . . . . . . Dialog zum Hochladen von Dokumenten mit markierter Option zum Verstecken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ ¨ Button zum Offnen des Dialogs zum Andern des Projektes . . . . . . . . . ¨ Dialog zum Andern des Projektes . . . . . . . . . . . . . . . . . . . . . . . ¨ Button zum Offnen 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. M¨arz 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. M¨ arz 2015]. [4] Git. Git. http://www.git-scm.com/, 2015. [Online; accessed 25. M¨arz 2015]. [5] GitStats. Gitstats - git history statistics generator. http://gitstats.sourceforge.net/, 2015. [Online; accessed 25. M¨arz 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 H¨ olzl J¨ urgen 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 einf¨ uhrung. 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 H¨oltge. Kimai - open source time-tracking. http://www.kimai.org/, 2015. [Online; accessed 25. M¨arz 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