STUDIENARBEIT CHRISTIAN EGO SOFTWAREARCHITEKTUEREN IN JAVA DOZENT: PROF. DR. MEIXNER

Transkript

1 CHRISTIAN EGO STUDIENARBEIT SOFTWAREARCHITEKTUEREN IN JAVA DOZENT: PROF. DR. MEIXNER Christian Ego Ernst-Lehner-Str. 8 Appartment 123 D Augsburg Matrikelnr.: Telefon: / c.ego@gmx.de Hochschule Augsburg University of Applied Sciences Baumgartnerstraße 16 D Augsburg Telefon: / Fax: / poststelle@hs-augsburg.de

2 INHALTSVERZEICHNIS 1. Einleitung Spezialgebiet Logging Vergleich der Frameworks und Auswahl Implementation4 2.3 Richtlinien für das Projekt5 3. Projektmanagement5 4. Entwicklungsumgebung.6 5. Teilprojekt Rechnerverwaltung Userstories ComputerPool Computer Access Domänenmodell Domain DAO AOP Service Facade Exception Weboberfläche Config Spring Config Log4J Config Hibernate Config Tests Fazit13 7. Quellen.14 SEITE 2 VON 14

3 1. EINLEITUNG Softwarearchitektur ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten, sowie die Beschreibung ihrer Beziehungen (Literatur: Balzert, S. 716). Ebenso wie beim Bau von Häusern die Architektur grundlegend zum Erfolg des Hausbaus beiträgt, so ist auch eine Architektur in der Informatik ein wichtiges und notwendiges Hilfsmittel beim erstellen größerer und komplexerer Softwaresysteme. Die Komplexität lässt sich durch folgendes Spannungsdreieck visualisieren: Im Rahmen der Vorlesung Softwarearchitekturen in Java lernten wir die grundlegenden Architekturbausteine in Java kennen. Im Verlauf der Vorlesung wurde jeder Gruppe ein Spezialgebiet sowie ein Subprojekt zugeteilt. Das Spezialgebiet wurde ausgearbeitet und im Rahmen eines Vortrages den anderen Gruppenmitgliedern präsentiert. Das Subprojekt dagegen wurde im Rahmen eines Praktikums umgesetzt. 2. SPEZIALGEBIET LOGGING Logging ist das Protokollieren von allen oder bestimmten Aktionen auf einem Computersystem. Das bedeutet, dass Informationen festgehalten werden, mit denen Nachvollzogen werden kann wer, was, wann durchgeführt hat. Durch das Protokollieren sollen Vorgänge rekonstruiert werden, um Fehlverhalten zu entdecken und beheben zu können. Bei der Softwareentwicklung kann es zum Debuggen bei Threads oder bei großen, verteilten Anwendungen eingesetzt werden. Festgehalten werden die Informationen in der Regel in einer Logdatei. SEITE 3 VON 14

4 2.1 VERGLEICH DER FRAMEWORKS UND AUSWAHL Die Zentralen Aufgaben eines Logging-Frameworks sind: 1. Bereitstellung eines einheitlichen Interfaces für alle Logmethoden. 2. Unterstützung unterschiedlicher Prioritätsstufen (Log-Level). 3. Konfigurationsmöglichkeiten: Filter für Prioritätsstufen Handler (Ausgabe bzw. Weiterverarbeitung) Ausgabeformat 4. Gruppierungsmöglichkeit nach Herkunft mit unterschiedlichen Konfigurationen Hierzu haben wir uns die folgenden Frameworks bzw. Fassades angesehen: JDK Logger der in den java.util bereitsteht. Log4J welches aus dem "E.U. SEMPER Project" entstand und unter der Apache Software License veröffentlicht wurde. SLF4J welches als Fassade in Verbindung mit Log4J am häufigsten Verwendet wird. JCL (Commons-Logging) ebenfalls eine Fassade, die unter der Apache Software License veröffentlicht wurde. Beim Vergleich der Frameworks fiel auf, dass bei allen die Einstufung in Log-Level, mit denen man Log-Meldungen bei bestimmten Bedingungen aktivieren oder deaktivieren kann, grundsätzlich gleich ist. Ebenso kann man mit allen Frameworks sowohl eine Nachricht definieren, die später ausgegeben wird, als auch Ausnahmen und Fehler behandeln. Bei Log4J und SLF4J kommt noch der Mapped Diagnostic Context (MDC) hinzu. Dabei erhält man Informationen über einzelne Threads. Diese sind z.b. IP, User, u.a. Der in SLF4J unterstützte Marker dient der Ausgabe von vorher festgelegten Bezeichnungen für Bundles und/oder Services (zz. nur in LogBack implementiert). 2.2 IMPLEMENTATION Die Implementation im Programmcode ist sehr einfach. Durch das Einbinden der entsprechenden Klassen kann ein Logger über die LoggerFactory instanziert werden. Da im Projekt mit Maven gearbeitet wird müssen die entsprechenden Abhängigkeiten in der pom.xml integriert werden. Die Konfiguration erfolgt über eine einfache xml. Diese enthält Appender, welche für die Weiterverarbeitung zuständig sind, Layouts, die für die Formatierung der Log-Statements verantwortlich sind und Filter, die für eine Eingrenzung der Statements zuständig sind. SEITE 4 VON 14

5 2.3 RICHTLINIEN FÜR DAS PROJEKT Da wir im Projekt in verschiedenen Gruppen arbeiteten, einigten wir uns auf folgende Richtlinien: Geloggt wird generell in das Verzeichnis <Teilprojekt>/logs Dieses Logverzeichnis ist in svn auf ignore zu setzen. Logs werden nicht eingecheckt! Logausgaben auf Konsole sollten in der Regel (ausser Exceptions) nur zu Debugzwecken während der Entwicklung eingesetzt werden. Mit den Logs sollen alle Exceptions, Zugriffe auf DAO sowie Anfragen und Rückgaben der Schnittstellen nachvollzogen werden. Um die Logs einheitlich darzustellen sollte, falls nicht zwingend anders erforderlich, das Pattern Layout verwendet werden. 3. PROJEKTMANAGEMENT Als Projektmanagementtool nutzten wir Projektweit Trac mit einem integrierten Wiki. Trac ist ein freies, webbasiertes Projektmanagement-Werkzeug zur Softwareentwicklung. Es enthält eine webbasierte Oberfläche zum Betrachten von Subversion-Repositories, ein Wiki zum kollaborativen Erstellen und Pflegen von Dokumentationen und ein Ticketsystem. Die Dokumentation zum Spezialgebiet, sowie das Domänenmodell zum eigenen Subprojekt wurde im Wiki niedergeschrieben. Unter Timeline wurde man über alle Aktionen, einschließlich von checkin-operationen informiert. Die Roadmap zeigte den aktuellen Stand des Projekts anhand des Status der Meilensteine. Unter Browse-Source hatte man Einblick in das Subversion-Repository und konnte auch Änderungen durch diffs nachvollziehen. View Tickets zeigte alle aktiven und inaktiven Tickets im System strukturiert nach Milestones, eigenen und Status der Tickets. Trac wurde weiterhin auch zu Feedbackzwecken des Tutors genutzt und war eine Austausch Plattform mit interessanten Blogeinträgen zu den behandelten Themen oder Auftretenden schwierigkeiten. So wurde beispielsweise eine Diskussion zum Thema Architektur durch den Dozenten aufgelöst und die Unklarheiten dadurch beseitigt werden. Trac war somit ein wichtiges und gutes Hilfsmittel bei diesem Projekt. SEITE 5 VON 14

6 4. ENTWICKLUNGSUMGEBUNG Die verwendete Entwicklungsumgebung war Eclipse. Empfohlen wurde die Spring Tool Suite eine Spezialversion von Eclipse. Zum kollaborativen Arbeiten musste dem Standard Eclipse, zusätzlich zu SVN, noch das Maven Plugin installiert werden. Apache Maven ist ein auf Java basierendes Build-Management-Tool. Es versucht den Grundgedanken Konvention vor Konfiguration für den gesamten Zyklus der Softwareerstellung abzubilden. Es sollen dabei das Kompilieren, Testen und Deployment durch Konfigurationseinstellungen automatisiert werden und der Lebenszyklus eines Softwareprojekts durch Maven auch nach Release weiter gepflegt werden. Das Maven Plugin zeigte sich jedoch an vielen Stellen leider nicht immer trivial. So hatten wir teilweise massive Probleme beim Einbinden anderer Projekte, da Artefakte nicht richtig gefunden werden konnten. Dennoch wurde es auch in unserem Teilprojekt verwendet und die notwendigen Abhängigkeiten in der pom.xml definiert. 5. TEILPROJEKT RECHNERVERWALTUNG Unsere Aufgabenstellung umfasste es einen Prototypen einer Verwaltungssoftware für Rechner in den Laboren der Hochschule zu erstellen. Wir entschieden uns dazu auch Zugriffe auf diese Rechner mitverwalten zu können. So ergaben sich aus dem Projekttitel folgende Anforderungen: Es sollen Rechner in den verschiedenen Laboren verwaltet werden. Die Rechner sind gruppiert je nach Labor. Administratoren sollen Userzugriffe steuern. Die Anforderungen zeigten dabei schnell, dass wir auch Zugriff auf die Userdaten der Gruppe des Teilprojekts Personen, Fakultäten, Studiengänge benötigten. Ebenso benötigte die Gruppe des Subprojekts Raumverwaltung von uns eine Schnittstelle. 5.1 USERSTORIES COMPUTERPOOL Je Labor wird ein ComputerPool angelegt, identifiziert durch die labid. Jeder ComputerPool enthält eine Liste mit allen im Raum vorhanden Computern. Jedem ComputerPool wird ein Admin zugeordnet. SEITE 6 VON 14

7 5.1.2 COMPUTER Jeder Computer wird identifiziert durch seine ip. Zusätzlich wird jedem Computer die labid zugeordnet. Jeder Computer enthält eine Liste mit Zugriffsberechtigungen (Access) ACCESS Jedem Access wird ein User ein Computer sowie ein AccessLevel zugeordnet. Die Identifizierung erfolgt durch user und computer Administratoren können Zugriffsrechte bearbeiten. 5.2 DOMÄNENMODELL Aus den Userstories lies sich dann unser Domänenmodell entwickeln. Dabei haben wir, auch wenn dies nicht unbedingt Teil eines klassischen Domänenmodells ist, zusätzlich die Zugriffe auf Objekte anderer Gruppen visualisiert. SEITE 7 VON 14

8 5.3 DOMAIN Beim Domain-Driven Design ist die Domänenschicht die Verknüpfung zwischen Anwendungslogik und Datenschicht. Es basiert auf folgenden zwei Annahmen: Der Schwerpunkt des Softwaredesigns liegt auf der Fachlichkeit und der Fachlogik. Der Entwurf komplexer fachlicher Zusammenhänge sollte auf einem Fachmodell basieren. Es ist dabei an kein konkretes Modell gebunden, orientiert sich aber an der agilen Softwareentwicklung. In unserem konkreten Fall haben wir im Paket Domain die Entity-Objekte untergebracht. Die Entity-Objekte stellen durch Persistenz speicherbare Objekte dar. Für den Aspekt der Persistenz verwenden wir Hibernate, welches die Entities in einer beliebigen Datenschicht speichert. In der Implementation werden dabei durch Annotationen die Informationen, die zur Persistenz benötigt werden, direkt an die Elemente gebunden. Dabei ist eine ID je Entity-Objekt oder eine generierte ID zwingend erforderlich, da Hibernate dies als Primärschlüssel interpretiert. Die wichtigsten Annotationen marktiert die Klasse als erlaubt es uns den Namen der Tabelle zu length= 35, nullable=false, unique = true) ermöglicht das Setzten von Eigenschaften der definiert den Primärschlüssel (PK) der Tabelle. Hibernate kann automatisch PK erzeugen. Jedoch muss dafür die angeggeben werden. Falls verwendet wird, muss der Entwickler den PK selbst definieren. SEITE 8 VON 14

9 5.4 DAO Data Access Objects bieten den Zugriff auf die Daten in einer Datenquelle. Sie stellen eine Schnittstelle für den Zugriff auf Daten und Strukturen von Datenquellen dar. Ziel der DAOs ist es die Datenquellen so zu kapseln, dass diese jederzeit ohne Änderungen am Programmcode ausgetauscht werden können. Dabei ist es egal ob diese Datenquelle eine Datenbank oder ein Dateisystem ist. Der Entity Manager kann dabei verschiedene Datenzugriffssprachen wie SQL o. ä. verwenden. public Access getuseraccess(long user, Computer computer) { String s = "SELECT a FROM Access a WHERE a.user=:user AND a.ip=:ip"; Query q = getentitymanager().createquery(s); q.setparameter("user", user); q.setparameter("ip", computer.getip()); return (Access) q.getsingleresult(); Wie man an diesem Beispiel einer Funktion aus einem unserer DAOs sieht, wird unter Verwendung eines Entity Managers ein SQL-Befehl an die Datenbank abgesetzt und die Rückgabe verarbeitet. 5.5 AOP Aspektorientierte Programmierung (AOP) ist eine Methode der Programmierung, die verschiedene logische Aspekte eines Programms vom Rest der Logik trennen soll. Aspekte werden dabei getrennt entwickelt und später dann zusammengefügt bzw. verwoben. Der Aspekt wird dann beim Aufruf aber noch vor dem Ausführen einer Methode betreten. Der Join Point ist praktisch als eine Art Umleitung zu verstehen. Join Points sind implizit vor jeder Methode gegeben. Ein Pattern (Muster) im Pointcut sorgt dann für die Filterung derjenigen Join Points die für einen Aspekt interessant sind. Die Programmierung mit Aspekten erlaubt es das Verhalten von Klassen grundlegend zu verändern. Durch Aspekte lassen sich Eigenschaften und Methoden zu Klassen hinzugefügt werden. Die Verwendung von Wildcards bietet hier viele Möglichkeiten mit Aspekten auch mehrere Klassen zu beeinflussen. SEITE 9 VON 14

10 In unserem Subprojekt haben wir dieses Konzept exemplarisch an unserem Logger eingesetzt. package hsv.rechnerverwaltung.aop; import org.aspectj.lang.proceedingjoinpoint; import org.aspectj.lang.signature; import org.slf4j.logger; import org.slf4j.loggerfactory; public class LoggerAop { private Logger logger; public LoggerAop() { logger = LoggerFactory.getLogger(this.getClass().getName()); public Object log(proceedingjoinpoint pjp) throws Throwable { String pjpname = pjp.getsignature().getdeclaringtype().getname(); logger.debug(pjpname); Object result = null; try { result = pjp.proceed(); catch (Throwable e) { logger.error(pjpname, e); return result; Der Pointcut wird dabei in einer Spring-Bean definiert. <?xml version="1.0" encoding="utf-8"?> <beans > <bean id="loggeraop" class="hsv.rechnerverwaltung.aop.loggeraop"></bean> <aop:config> <aop:aspect id="loggeraspect" ref="loggeraop"> <aop:pointcut id="loggeraoppointcut" expression="execution(public * hsv..*(..))" /> <aop:around pointcut-ref="loggeraoppointcut" method="log" /> </aop:aspect> </aop:config> </beans> Das Pattern expression execution(public * hsv..*(..)) in unserem Beispiel trifft dabei auf alle Funktionen in den Klassen des Paketes hsv zu. SEITE 10 VON 14

11 5.6 SERVICE Serviceorientierte Architektur, ist ein Architekturmuster, um Dienste vom Programmcode abzutrennen, zu strukturieren und zu nutzen. Durch die Verwendung dieser Architektur lassen sich Services entwickeln welche in einem Gesamtkontext, die vorhandenen Komponenten in Services zu kapseln und dann zu koordinieren. Daraus ergeben sich durch die Zusammensetzung von Services niedrigerer Abstraktionsstufe, höhere Services die dem Kunden zur Verfügung gestellt werden können. In unserem Fall haben Sie die Zugriffe auf die DAOs verwaltet und deren Operationen ausgeführt. public class ComputerService implements IComputerService { private IComputerDao public void setaccess(string ip, Access access) { Computer c = this.dao.getcomputer(ip); c.setaccess(access.getuser(), access); this.dao.persist(c); In diesem Ausschnitt wird deutlich, dass das DAO abgekapselt ist und der Service die Funktionen des DAOs verwendet und ausführt. 5.7 FACADE Die Facade fasst die Services in einem Gesamtkontext zusammen und kapselt diese ebenfalls nach außen ab, der Benutzer hat damit nur die Sicht auf die Facade. Konzeptuell ist eine Facade als Interface mit wenig implementierter Logik zu interpretieren. Mithilfe der Facade lassen sich auch Schnittstellen implementieren und bereit stellen. public class ComputerManagementFacade implements IComputerManagementFacade { IComputerPoolService poolservice; IComputerService computerservice; IAccessService public int getcomputercount(string labid) { return public void removecomputer(string ip) { Computer c = this.computerservice.getcomputer(ip); this.poolservice.removecomputer(c); this.computerservice.removecomputer(c); SEITE 11 VON 14

12 getcomputercount(string labid) ist dabei die Schnittstelle, die von einer der anderen Gruppen gefordert wurde. Alle anderen Funktionen stellen die Hauptfunktionalitäten unseres Teilprojektes dar, welche dann von der Weboberfläche angesprochen werden sollen. 5.8 EXCEPTION Pro forma wurde auch eine recht allgemein gehaltene Exception definiert, die bei Fehlern geworfen werden kann. 5.9 WEBOBERFLÄCHE Aus Zeitgründen und Aufgrund von Problemen mit der Persistenz wurde keine Weboberfläche implementiert. Geplant war für unser Teilprojekt Apache Wicket einzusetzen, da es eine sehr flexible und einfache Lösung darstellt CONFIG Die Konfigurationdateien für die verschiedenen Komponenten liegen unter src/main/resources SPRING CONFIG Die Spring Config teilt sich in verschiedene XML, die für die einzelnen Beans zuständig sind. Die AOP Beans wurden bereits erläutert. Die DAO Beans definieren die DAO Objekte und den zugehörigen Entity Manager. Die Facade Beans definieren die Facades. Die JPA Beans enthalten sämtliche notwendigen Eigenschaften für die Verwendung der Datenzugriffe. Im Application-Context wird der Kontext der Anwendung zusammengefasst. Außerdem können weitere Merkmale wie SQL-Konfiguration oder Konfiguration des EntityManager ausgelagert werden LOG4J CONFIG Die Log4J Konfigurationsdatei enthält wie im Spezialgebiet erläutert alle Konfigurationseigenschaften des Loggingframeworks HIBERNATE CONFIG Die Hibernate Config enthält alle notwendigen Eigenschaften für die Persistenz und Zugriffe auf Datenquellen. SEITE 12 VON 14

13 5.11 TESTS Jede gute Applikation muss getestet werden. In der frühen Entwicklung wurde dazu auf gemockte Methoden zurückgegriffen. Dazu wurde das Mockito Framework public void setup() throws Exception { this.mockeddao = Mockito.mock(IComputerDao.class); this.computerstmp = new ArrayList<Computer>(); this.computerstest = new ArrayList<Computer>(); this.computertest = new Computer(" ", "M101"); Mockito.when(this.mockedDao.getComputer(" ")).thenReturn(this.computerTest); Mockito.when(this.mockedDao.getComputers("M101")).thenReturn(this.computersTest); Mockito.when(this.mockedDao.getComputers()).thenReturn(this.computersTest); Mockito arbeitet Bedingungsorientiert. In der Setup Methode werden neben den gemockten Objekten, die für die Vergleiche verwendet werden, auch die Wenn-Dann-Bedingungen für Mockito festgelegt. In den Tests wird bei jedem Aufruf der als when übergebenen Parametermethode wird das gemockte Objekt das als Parameter in thenreturn übergeben wurde zurückgeliefert. 6. FAZIT Die Veranstaltung Softwarearchitekturen in Java gab einen sehr interessanten Einblick in dieses Themenfeld. Für einen tiefen Einblick ist dieses Themengebiet jedoch sehr Umfangreich für ein Semester und müsste auf 2 Semester ausgedehnt werden. Was leider missfallen hat, waren die doch etwas lückenhaften Ausarbeitungen der Spezialgebiete im Wiki. Oft wollte man schnell etwas im Spezialgebiet nachschlagen und musste mangels Material sich die Kenntnisse noch einmal selbst erarbeiten. Hier wäre eine konsequentere Verwendung des Wikis im Hinblick auf die Teamarbeit wünschenswert. SEITE 13 VON 14

14 7. QUELLEN SEITE 14 VON 14