Systemdokumentation. ChangePlorer

Transkript

1 Systemdokumentation ChangePlorer Ersteller Manuel Tächl Ort, Datum Billigheim, Sonntag, 22. Januar 2017

2 Inhalt 1 Plattform und Technologien Architektur Plattformarchitektur Systemarchitektur Datenhaltung Datenstruktur Datenquelle Schnittstellen API-Aufruf API-Attribute Query Product ProductVersion Changelog Author Deployment Parameter Fremdkomponenten und Frameworks Backend Frontend Januar 2017 Seite 2 von 12

3 1 Plattform und Technologien Die Applikation ist mithilfe des MVC-Frameworks entwickelt, welches auf der Microsoft Technologie ASP.NET basiert. Dieses ermöglicht unter anderem die Generierung dynamischer Webanwendungen unter Berücksichtigung des MVC-Patterns. ASP.NET bietet die Möglichkeit, HTML und C# zu kombinieren, um Front- und Backend-Komponenten zu entwickeln. Die View-Komponente äußert sich in HTML Seiten, welche die Inhalte visualisieren und die Informationen des Models darstellen. Die Dynamik des Frontends wird mittel JavaScript realisiert, um beispielsweise Features wie die Timeline anzuzeigen. Die dynamische Datenversorgung erfolgt durch AJAX. Die Steuerung der Daten übernimmt die Controller-Komponenten, welche das Backend der Applikation darstellen. Diese kümmern sich neben der Abarbeitung der Requests sowie des Session- Handlings auch um den Abruf und die Aufbereitung der Daten sowie der Rückgabe des entsprechenden Views mitsamt der Daten. Diese werden in Form von Models an den View übergeben, welcher im HTML mittels Variablen Zugriff auf die A ttribute besitzt und diese dynamisch einbettet. Als essentieller Baustein für die Datenbereitstellung wird ASP.NET Web API verwendet, um die Informationen mittels REST-Web-Dienst auszutauschen. Als Entwicklungsumgebung wird Visual Studio 2015 Enterprise verwendet, über welches neben der Programmierung auch das Deployment gesteuert wird. Die komplette Applikation wird auf einem IIS-Webserver gehostet und ist über jeden beliebigen Browser als Responsive-Web-App aufrufbar. 22. Januar 2017 Seite 3 von 12

4 2 Architektur Plattformarchitektur Systemarchitektur 22. Januar 2017 Seite 4 von 12

5 3 Datenhaltung 3.1 Datenstruktur Die Datenhaltung erfolgt durch objektorientierte Klassen in der Applikation, welche im folgenden Klassendiagramm visualisiert sind: 22. Januar 2017 Seite 5 von 12

6 Die Funktionen der einzelnen Klassen sind in der anschließenden Tabelle aufgeführt: Klasse Funktion Basisklassen Changelog Repräsentiert die zentrale Klasse in der Applikation und enthält die wesentlichen Attribute, die einen Change-Eintrag beschreiben. ProductVersion Repräsentiert die Kombination eines (Software)Produkts in Kombination mit einem Versionsstand. Jeder Changelog ist einer ProductVersion zugeordnet Product Author Repräsentiert ein (Software)Produkt, welches Changes produziert Repräsentiert den Autor eines Changelog-Eintrags Hilfsklassen ChangeType Query TreeNode HTMLHelper Enumeration aller Typen von Changes Kapselt Abfrageparameter, um Changelogs über die API abzufragen Repräsentiert einen Knoten in der Versionshierarchie und verknüpft die Child-Nodes Stellt wiederverwendbare HTML-Konstrukte bereit. ViewModels HomeViewModel TimelineViewModel ConfigurationsViewModel Enthält die Daten für den Haupt-View Enthält die Daten für den Timeline-View Enthält die Daten für den Configuration-View 3.2 Datenquelle Da im Projekt keine Datenquelle in Form eines Ticketsystems, etc. verfügbar war, we r- den in der Applikation zufällige Changelogs erstellt (Mock-Daten). Hierbei werden zufällige Platzhalter für die Attribute generiert. Jedoch wurde darauf geachtet, schlüssige Werte zu erzeugen (Datum innerhalb der Abfrageparameter, sinnvolle Produktversionierung anhand des Datums, technische Titel, etc. 22. Januar 2017 Seite 6 von 12

7 4 Schnittstellen Da im Produktivbetrieb sinnvollerweise keine Zufallsdaten erzeugt werden sollen, muss eine Datenquelle angebunden werden, um Produkt- und Changelog-Daten zu extrahieren. Dies kann einerseits über die Anpassung der integrierten API erfolgen oder durch die Anbindung einer API eines Ticket-Systems. Bei der Anpassung der internen API kann beispielsweise anstatt des Bestehenden Mock-Services zur Generierung der Testdaten eine Datenbankverbindung implementiert werden, welche die Daten aus e i- ner SQL-Datenbank je nach Abfrageparameter extrahiert. Sowohl bei der Anbindung einer Datenbank, als auch bei der Verknüpfung einer fremden API ist darauf zu achten, die von der Applikation benötigten Attribute bereitzustellen. 4.1 API-Aufruf URL Funktion HTTP- Methode Input- Parameter Ergebnis <Server>/api/products Abruf aller verfügbaren Produkte GET - IEnumerable<Product> <Server>/api/changelogs/query Abruf aller Changelogs gemäß der Abfrageparameter POST Query IEnumerable<Changelog> <Server>/api/changelogs/details <Server>/api/changelogs/details/<id> Abruf der Detaildaten für einen Changelog Abruf der Detaildaten für einen Changelog* POST* Changelog* Changelog GET* int* Changelog * Aufgrund der Mockdaten muss der komplette Changelog bei der Anforderung der D etails übermittelt werden, da diese im Backend nicht gespeichert werden. Bei der Erse tzung der Schnittstelle auf Basis einer persistenten Datenquelle genügt die Übermittlung der ID mittels GET. 4.2 API-Attribute Query Attribut Datentyp Beschreibung From DateTime Untere Datumgrenze der Changelogs To DateTime Obere Datumgrenze der Changelogs ChosenProducts IEnumerable<Product> Gewünschte Produkte Product Attribut Datentyp Beschreibung ID Int Eindeutige ID Name String Name/Beschreibung des Produkts 22. Januar 2017 Seite 7 von 12

8 4.2.3 ProductVersion Attribut Datentyp Beschreibung Product Product Produkt des Changelogs Version String Versionsstand Changelog Attribut Datentyp Beschreibung ID Int Eindeutige ID Title String Titel des Changelogs Description* String Beschreibung des Changelogs ProductVersion ProductVersion Produkt und Version des Changelogs Type ChangeType (Enum) Typ des Changes Date DateTime Datum des Changelogs Author* Author Autor des Logs Assets* IDictionary<string,byte[]> Key: Dateiname Value: Byte-Array der Datei Anhänge des Changelogs * Werden erst bei der Anforderung der Details benötigt Author Attribut Datentyp Beschreibung FirstName String Vorname des Autors SurName String Nachname des Autors String -Adresse des Autors 22. Januar 2017 Seite 8 von 12

9 5 Deployment Zu Testzwecken kann die Applikation localhost über die IDE Visual Studio getestet werden, in dem die Applikation ausgeführt wird (F5). Für einen produktiven Rollout muss die Applikation auf einen Webserver migriert werden. Dies kann direkt aus Visual Studio heraus erfolgen. Durch einen Rechtsklick auf das Projekt und einen Klick auf den Eintrag Veröffentlichen stehen mehrere Methoden zur Verfügung. Neben dem direkten Deployment auf einen Azure-Webspace können die Applikationsdaten mittels Web- Deploy auf einen Server geschoben werden: Notwendig hierfür ist die Aktivierung des IIS-Dienstes inklusive der für ASP.NET benötigten Module. Hierfür reicht bereits ein normaler Windows-Rechner. Diese Einstellungen können in der Systemsteuerung unter Programme und Features Windows Features aktivieren oder deaktivieren vorgenommen werden: 22. Januar 2017 Seite 9 von 12

10 Alternativ dazu können die für die Veröffentlichung relevanten Dateien üb er das Deployment-Tool in Visual Studio auf einen FTP-Server oder ins Dateisystem exportiert werden. Entsprechende Hilfestellungen und Tutorials sind schnell im Netz gefunden. 22. Januar 2017 Seite 10 von 12

11 6 Parameter Die Parameter befinden sich in der Datei Web.config im Bereich appsettings. Durch die folgenden Parameter kann die Applikation an benutzerdefinierte Anforderungen angepasst werden (Customizing): Variable APIEndpoint Funktion Hier wird die API-Root-URL eingetragen, sofern der Webservice auf einem anderen Server wie die Applikation läuft. Die URL kann in der Applikation unter Konfigurationen verändert werden. Sofern die Variable leer bleibt, wird diese durch den aktuellen Server der Applikation überschrieben. 22. Januar 2017 Seite 11 von 12

12 7 Fremdkomponenten und Frameworks 7.1 Backend Im Backend wurde das vom Visual Studio bereitgestellte ASP.NET MVC 5 sowie das WebAPI 2 Framework verwendet. Darüber hinaus wird zur Generierung der Testdaten MockData und zur Generierung von Test-PDFs PdfSharp eingesetzt. Zum erleichterten Umgang mit der Serialisierung und Deserialisierung der JSON Daten im Kontext der API wird auf Newtonsoft.JSON zurückgegriffen. Ale zusätzlichen Pakete wurden mittels des in Visual Studio integrierten NuGet-Paketmanager eingebunden. MockData PdfSharp Newtonsoft.JSON URL Framework/Komponente d=15&itemid= Frontend Framework/Komponente Bootstrap JQuery Bootstrap-Theme Datepicker Timeline vis.js Treeview URL Im Frontend wird zur grundsätzlichen Anzeige JQuery und Bootstrap verwendet, deren JavaScript- und CSS-Dateien im Projekt eingebunden werden. Hierdurch werden o p- tisch ansprechende Layouts. Schaltflächen und Animationen durch Anwendung eines Responsive and mobile first -Ansatzes gewährleistet. Das Bootstrap-Framework wird darüber hinaus um das Theme Flatly von der Webseite Bootswatch ergänzt. Zur Visualisierung eines Kalenders bei der Datumsauswahl wird der boostrap-datepicker verwendet, welcher auf GitHub verfügbar ist und über eine JavaScript- und CSS-Datei verfügt. Für die Visualisierung der Timeline wird vis.js verwendet, was Funktionalit ä- ten zur Anzeige browserbasierter Visualisierungen bereitstellt und mi ttels JavaScript und AJAX die Daten repräsentiert. Die Darstellung der Versionshistorie mittels eines Treeviews wurde in Anlehnung an eine Referenz-Implementierung auf jsfidle.net umgesetzt Januar 2017 Seite 12 von 12