Entwicklung einer Software auf Empinia-Basis für die
              Abfallverwaltung eines Batterieherstellers


          ...
2                                         Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth




spiels...
Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers           3




Anwendung ...
4                                   Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth




macht lose K...
Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers        5




Eine verbreit...
6                                   Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth




main Navigat...
Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers        7




             ...
8                                      Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth




3        ...
Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers       9


                ...
10                            Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth




daten synchronisie...
Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers   11




Jahr P., Schieman...
Nächste SlideShare
Wird geladen in …5
×

Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers

3.564 Aufrufe

Veröffentlicht am

Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth: Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers. In: EnviroInfo2009, ISBN 978-3-8322-8828-0

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.564
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers

  1. 1. Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth HTW Berlin, Fachbereich 2, Betriebliche Umweltinformatik Wilhelminenhofstraße 75A, 12459 Berlin stefan.simroth@student.htw-berlin.de andreas.taube@student.htw-berlin.de matthias.maeusbacher@htw-berlin.de volker.wohlgemuth@htw-berlin.de Zusammenfassung Die neue Gesetzeslage erfordert von Unternehmen, die gefährlichen Abfall produzieren, die elektronische Register- führung, sowie den elektronischen Nachweis an die Behörden. Um dies zu ermöglichen, als auch die Arbeit des Ab- fallbeauftragten zu erleichtern und die verursachungsgerechte Zuordnung von Abfällen zu erreichen, wird eine Ab- fallverwaltungssoftware entwickelt. Die Verwendung des Anwendungsrahmenwerkes Empinia fördert die Entwick- lung und ermöglicht ein Fokussieren auf die Problemstellung der Anwendungsdomäne und das Domänenmodell. Gleichzeitig wird mit dieser Entwicklung eine Referenzanwendung für Empinia geschaffen, die dessen Verwendung als fachspezifische Entwicklungsplattform exemplarisch darstellt. Darüber hinaus sollen gemeinsame Daten zwi- schen dem in Umberto erstellten Stoffstrommodell und der Abfallverwaltungssoftware automatisiert synchronisiert werden. 1 Einführung Die Entsorgung von Abfällen in der Bundesrepublik Deutschland wurde durch das Gesetz zur Vereinfa- chung der abfallrechtlichen Überwachung und die Nachweisverordnung ab dem 1. Februar 2007 grund- sätzlich neu geregelt. 1 In der zweiten Phase dieser Verordnung, welche ab dem 1. April 2010 in Kraft tritt, wird das elektronische Abfallnachweisverfahren (eANV) verbindlich vorgeschrieben. Ab diesem Datum müssen Abfallerzeuger, Abfallbeförderer und Abfallentsorger ihre Kommunikation untereinander, die Entsorgung gefährlicher Abfälle (vorher „überwachungsbedürftige Abfälle“) betreffend, elektronisch ab- wickeln. Die zu jedem Abfall gehörenden Nachweisscheine (Entsorgungsnachweis, Begleitscheine) müs- sen dann mit einer elektronischen Signatur versehen werden und über eine zentrale Koordinierungsstelle (ZKS-Abfall) an die zuständige Behörde übermittelt werden. 2 Aufgrund dieser Tatsache stehen immer mehr kleine und mittlere Unternehmen (KMU) vor der Heraus- forderung, diese gesetzlichen Regelungen einzuhalten. In der Regel müssen die betrieblichen Prozesse angepasst, personelle Zuständigkeiten festgelegt und alle nachweispflichtigen Informationen, wie bei- 1 Vgl. Gesetz zur Vereinfachung der abfallrechtlichen Überwachung und NachwV (2006) 2 Vgl. Knäpple (2007)
  2. 2. 2 Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth spielsweise die Art und Menge eines Abfalls digital erfasst werden. Erst mit der digitalen Erfassung ist die Grundvoraussetzung geschaffen eine nachweispflichtige Transaktion an die ZKS durchzuführen. 3 Um diesen Anforderungen gerecht zu werden, wurde das hier beschriebene Kooperationsprojekt zwischen der BAE Batterien GmbH und der Hochschule für Technik und Wirtschaft Berlin (HTW) initiiert. Ziel und Bestreben dieses Projektes ist es, die BAE Batterien GmbH bei ihrer gesetzlichen Nachweis- pflicht mittels einer softwaretechnischen Lösung zu unterstützen. 1.1 Ausgangssituation Bei der BAE Batterien GmbH fallen sowohl gefährliche Abfälle (Bleirückstände, Schwermetalle, etc.) als auch ungefährliche Abfälle (Verpackung, Metalle, etc.) an. Zuständig für deren Verwaltung ist der Abfall- beauftragte. Er ist dafür verantwortlich, alle Abfälle zu erfassen, zu entsorgen und deren Verbleib nach- zuweisen. Abfälle werden nach ihrer Abfallart unterschieden und je nach Art in einem eigens vorgesehenen Behälter aufbewahrt. Wenn die Abfallbehälter voll sind, hat der Abfallbeauftragte die Aufgabe diese Behälter ab- zuholen, zu erfassen und in einem Lager zu sammeln. Für die Erfassung der Abfälle ist es notwendig, den Abfall vorher zu wiegen, wobei die Art des Abfalls, die angefallene Menge und die Anfallstelle dokumen- tiert werden müssen. Sind genügend Abfälle im Lager vorhanden oder der erlaubte Lagerhöchstbestand erreicht, muss der Ab- fallbeauftragte die Entsorgung veranlassen. Dazu müssen die Abfälle zu einem Entsorgungs-unternehmen transportiert werden. Dies kann durch ein Beförderungsunternehmen erfolgen oder, wie in der Praxis häu- fig der Fall, durch das Entsorgungsunternehmen selbst. Es ist möglich, dass bei der Beförderung des Ab- falls mehrere Beförderungsunternehmen involviert sind, sodass durchaus eine Beförderungskette entstehen kann. Wichtig ist, dass der Abfallbeauftragte den Begleit- beziehungsweise Übernahmeschein zu unter- zeichnen und dessen Durchschlag entgegenzunehmen hat. Der Begleitschein liegt dem Abfall auf dem gesamten Entsorgungsweg bei und besteht aus sechs farblich unterschiedlichen Durchschriften, welche als Beleg für eine ordnungsgemäße Entsorgung gelten. Die Datenerfassung erfolgt derzeit noch handschriftlich und durch manuelle Übertragung in Microsoft Excel. Die Abfallbilanz, die einmal jährlich als Nachweis an die Behörde übermittelt werden muss, wird ebenso manuell mittels Microsoft Excel erstellt. Eine Problematik stellt sich derzeit bei der Prozesszuordnung der Abfälle dar. Dadurch, dass in einem Be- hälter durchaus der Abfall von mehreren Produktionsschritten gesammelt sein kann, lässt sich im nachhi- nein eine verursachungsgerechte Zuordnung nicht mehr reproduzieren. Der entsprechende Abfallanteil jedes Prozessschrittes (Herkunft) wird nicht vermerkt. Außerdem ist anzumerken, dass in einem weiteren BAE-Projekt 4 derzeitig ein Stoffstrommodell mit Hilfe der Software Umberto modelliert wird. Das Stoffstrommodell soll dann in Zukunft mit den erfassten Ab- falldaten versorgt werden. 1.2 Ziele Das Hauptziel des hier beschriebenen Projektes ist die Entwicklung einer fachspezifischen Anwendung, mit deren Hilfe eine systematische Erfassung und Archivierung der Abfalldaten ermöglicht wird. Des wei- teren soll das gesetzlich vorgeschriebene elektronische Abfallnachweisverfahren (eANV) mit Hilfe dieser 3 Vgl. Klein (2007) 4 Vgl. Erdelt, Hoffmann, Witte (2009)
  3. 3. Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers 3 Anwendung umgesetzt werden. Die Vision ist eine automatisierte Übertragung der nachweispflichtigen Abfalldaten an die ZKS-Abfall zu ermöglichen. Zusätzlich zur Erfassung der Abfälle soll die Anwendung eine verursachungsgerechte Zuordnung der Ab- fallherkünfte bereitstellen. Es soll somit möglich sein, eine prozentuale oder absolute Aufteilung einer Ab- fallerfassung vorzunehmen. Darüber hinaus soll die Anwendung es ermöglichen, einen erfassten Abfall als entsorgt zu markieren. Dies ist der Fall, wenn beispielsweise ein oder mehrere Behälter von einem Beför- derungsunternehmen abgeholt wurden. Hierbei ist zwischen Lagerbestand, Bestand entsorgter Abfälle und dem Gesamtbestand zu unterschieden. Ein weiteres Ziel ist die Anbindung an das Stoffstrommodell, um Abfallmengen und Abfallarten automati- siert an das Umberto-Stoffstrommodell zu übertragen, als auch Daten zur Abfallherkunft (Prozesse) in die Abfallverwaltungssoftware zu übernehmen. Des weiteren soll die Erstellung der jährlichen Abfallbilanz und Abfallstatistiken ermöglicht werden. 2 Konzept und Implementierung Die Konzeption und Implementierung der Abfallverwaltungssoftware ist auf Basis des Anwendungsrah- menwerkes Empinia umgesetzt. Dies war zum Einen eine Vorgabe für die Durchführung des Projektes. Zum Anderen bringt die technische Umsetzung mit Empinia für die Entwickler und Kunden einige Vortei- le mit sich. Zu diesen gehört unter anderem die gute Erweiterbarkeit, vereinfachte Wartung und übersich- tliche und strukturierte Anwendungsarchitektur. Letzteres ist oft ein bestimmender Faktor, wenn es um den Erfolg eines Softwareprojektes geht, da meistens die Anforderungen an die Software zu Beginn der Entwicklung nicht in aller Fülle und nötigen Ausführlichkeit feststehen, sondern erst im Laufe der Ent- wicklung konkretisiert werden. 5 Die Systemarchitektur von Empinia wird im folgenden Abschnitt näher erläutert und auf wichtige Grundkonzepte eingegangen. Empinia wurde im Rahmen des vom BMBF 6 geförderten Projektes Emporer 7 von der HTW Berlin und deren Kooperationspartnern entwickelt. Die entwickelte Anwendung zur Abfallverwaltung stellt diesbe- züglich eine Referenzanwendung für Empinia dar. Bei der Entwicklung der Abfallverwaltungssoftware ist außerdem der Frage nachgegangen worden, wie eine solche fachspezifische Anwendung mit Empinia technisch umgesetzt werden kann. Eine Antwort hierzu wird im Folgenden anhand eines Lösungsweges gegeben. 2.1 Empinia Empinia ist ein Anwendungsrahmenwerk (engl. application framework), geschrieben in C# unter Ver- wendung des Microsoft .NET Framework. Grundlegend für derartige Rahmenwerke ist, dass sie die Archi- tektur der Anwendung maßgeblich bestimmen. 8 „Es definiert die Struktur im Großen, seine Unterteilung in Klassen und Objekte, die jeweiligen zentralen Zuständigkeiten, die Zusammenarbeit der Klassen und Objekte sowie den Kontrollfluss. [...] Das Framework enthält die Entwurfsentscheidungen, die in seinem Anwendungsbereich allgemein anzufinden sind. Frameworks betonen damit die Entwurfswiederverwen- dung gegenüber der Codewiederverwendung [...].” 9 „Da zudem die Entwürfe der Anwendungen so sehr vom Framework abhängen, sind sie gegenüber Änderungen der Frameworkschnittstellen besonders emp- findlich. Während ein Framework sich entwickelt, müssen die Anwendungen sich mitentwickeln. Dies 5 Vgl. Beck 2005 6 Abk. f. Bundesministerium für Bildung und Forschung 7 http://www.emporer.net (Letzter Abruf 22.09.2009) 8 Vgl. Gamma et al. 2004, S. 37 9 Ebd., S. 37
  4. 4. 4 Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth macht lose Kopplung umso wichtiger, da andernfalls selbst eine kleine Änderung des Frameworks größere Auswirkungen zur Folge hat.“ 10 Bei einer Klassenbibliothek wendet ein Entwickler die zur Verfügung gestellten Klassen und Methoden an, indem er die notwendigen Objekte erzeugt und entweder direkt oder über deren Schnittstellen benutzt. Im Gegensatz dazu stehen Frameworks, wie Empinia, die sich dadurch charakterisieren, dass die von ei- nem Entwickler definierten Methoden um das Framework zuzuschneiden, eher vom Framework selbst aufgerufen werden, als vom Code des Entwicklers. Damit spielt das Framework oft die Rolle des Haupt- programms bei der Koordination und Ablaufsteuerung der Aktivitäten der Anwendung. Diese Umkehrung der Steuerung (engl. Inversion of Control, „IoC“) gibt Frameworks die Fähigkeit, als erweiterbare Skelette zu fungieren. Die Methoden, die von einem Entwickler definiert werden, maßschneidern die generischen Algorithmen des Frameworks für die spezielle Anwendung. 11 Diese Anpassung, das „Maßschneidern“, sowie die Bekanntmachung von Client-Funktionalität, erfolgt dabei mittels Konfiguration, im Falle von Empinia durch Deklaration in einer XML-Datei und .NET Metadaten, den Attributen. Das Rahmenwerk liest diese Konfiguration beim Start aus und stellt diese Erweiterungen anderen Komponenten über eine zentrale Erweiterungsregistrierung zur Disposition. Die „hot spots“ für Erweiterungen sind dabei definier- te Erweiterungspunkte, ebenso in XML oder mit Attributen, welche aus reiner Konfiguration oder einer implementierenden Klasse bestehen können, oder beidem. Das hier verwendete Entwurfsmuster ist die „Strategie“. 12 Somit kann durch die Verwendung von Empinia eine sehr lose Kopplung erreicht werden. Zugleich ist es aber auch möglich, die Konsistenz der darauf aufbauenden Anwendung zu garantieren, indem festgelegt wird, welche wichtigen Komponenten vorhanden sein müssen und welche optionalen oder austauschbaren Komponenten nicht. Dies geschieht in den anwendungsspezifischen Komponenten, der Abfallverwaltung-Anwendung, in der obersten Schicht, der Anwendungsschicht, die Abbildung 1 zeigt. Abbildung 1: Empinia Systemarchitektur (nach Jahr et al. 2009 und nach Schnackenbeck et al. 2007) 10 Ebd., S. 38 11 Vgl. Johnson and Foote 1988 (sinngemäß übersetzt) 12 Vgl. Gamma et al. 2004
  5. 5. Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers 5 Eine verbreitete Technik, um komplizierte Anwendungen auseinanderzubrechen, ist die der Schichten. Eine Schicht in einem System liegt dabei auf einer anderen Schicht. In diesem Schema benutzt die höchste Schicht alle Dienste der darunterliegenden Schichten, wohingegen die unteren Schichten die darüberlie- genden nicht kennen. Eine Schicht kann als ein kohärentes Ganzes verstanden werden, welches nicht viel von anderen Schichten wissen muss. Abhängigkeiten sind innerhalb einer Schicht minimiert. 13 Schichten bestehen wiederum aus ein oder mehreren Komponenten. Die Komponenten innerhalb einer Schicht soll- ten auch untereinander so wenig wie möglich gekoppelt sein. Durch die Abhängigkeiten der Komponenten untereinander ergibt sich abermals eine Art Schichtung, die gut geplant sein muss. Die Abhängigkeiten (engl. dependencies) müssen bei .NET explizit deklariert werden. Kann eine Abhängigkeit nicht aufgelöst werden, so kann eine Assembly nicht verwendet werden, auch wenn diese die andere Assembly nur in be- stimmten Fällen braucht. Die .NET Common Language Runtime (CLR) bricht die Ausführung des Prog- ramms dann ab. Ebenso unmöglich ist es, sogenannte Ringabhängigkeiten zu definieren, das heißt dass zwei Assemblies sich gegenseitig referenzieren und dadurch bedingen. Die erweiterbare und lose gekop- pelte Architektur von Empinia ermöglicht es Entwicklern, das Problem der Abhängigkeiten besser unter Kontrolle zu bekommen und aufzulösen. Besonders zur Funktionalität und Granularität von Plugins und Komponenten existieren bereits Richtlinien und Empfehlungen. 14 Um nun Empinia für die eigene Anwendungsentwicklung zu benutzen, ist es zunächst nötig, eine ausführ- bare Datei zu erstellen, um die Laufzeitumgebung von Empinia, die in Abbildung 1 dargestellte Runtime, zu starten. Dies schließt auch die grafische Oberfläche mit ein, wenn gewünscht. So kann mittels einer Produkt-Konfiguration Empinia mit seinem Zeichen versehen werden. Außerdem läßt sich darüber auch der Funktionsumfang bestimmen, das heißt das Framework maßschneidern. Überdies bringt Empinia auch die nötigen NAnt Erstellungsskripte mit sich, sodass eine sehr flexible Erstellung der Anwendung mit den benötigten Plugins ermöglicht wird. Die Erstellungsskripte eignen sich auch sehr gut zur Integration in sogenannte Continious Integration Systeme. Sind diese wenigen grundsätzlichen Schritte zur Anwendungsentwicklung mit Empinia erledigt, kann sehr schnell bereits auf das Domänenmodell fokussiert werden. 2.2 Domänenmodell Ein Domänenmodell, also das fachspezifische Modell eines Anwendungsgebiets, besteht im Kern aus En- titäten mit ihren Eigenschaften und den Beziehungen der Entitäten untereinander. Für die Erstellung eines Domänenmodells mit Empinia kann teilweise auf Code-Generierung gesetzt werden. Dafür wird für jede Entität eine sogenannte Domain Entity Defintion benötigt. Dies ist im Grunde eine XML-Datei, welche die abstrakte Beschreibung der Entität mit ihren Eigenschaften und Beziehungen enthält. Mittels des in Empi- nia enthaltenen Domain Code Generator wird dann C#-Quellcode erstellt. Dabei werden partielle Klassen generiert, die es dem Entwickler ermöglichen, weiteren Code den Entitäten hinzuzufügen, ohne diesen zu verlieren, wenn der Code neu generiert wird. Ebenso können bereits in der XML-Definition der Entitäten die Validierungsregeln für zulässige Werte der Eigenschaften untergebracht werden, wenn eine Bibliothek wie beispielsweise der NHibernate Validator genutzt wird. Der Speicherort der Entitäten wird in der Empinia.DomainModel-Erweiterung ebenso abstrahiert, wie die durch diese Arbeit neu hinzugekommene Abstraktion des Datenzugriffs. Für den Datenzugriff wird das domänengetriebene Entwurfsmuster Repository 15 verwendet. Die visuelle Darstellung des Domänenmo- dells in einer baumartigen Struktur übernimmt eine ebenso neu hinzugekommene Komponente, der Do- 13 Vgl. Fowler 2002, S. 17 14 Vgl. Denz und Schnackenbeck 2008, Whitepaper 15 Vgl. Evans (2004)
  6. 6. 6 Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth main Navigator. Dieser erlaubt auch den schnellen Zugriff auf die sogenannten CRUD-Operationen 16 . Für eine möglichst generische Verwendung von CRUD-Operationen wurden die beiden genannten abstrahie- renden Komponenten, der Speicherort und der Datenzugriff, in dieser Arbeit verknüpft. 2.3 Persistenz Damit das erstellte Domänenmodell auch mitsamt den Entitäten in einer Datenbank abgespeichert werden kann, ist ein Persistenz-Plugin nötig. Ein solches wurde zusammen mit den oben beschriebenen gundle- genden Komponenten für Domänenmodelle bereits in einer früheren Arbeit erstellt. 17 In dieser Arbeit wurde das Persistenz-Plugin lediglich benutzt. Die bei der Persistenz zum Einsatz kommende Technologie ist vor allem das Object Relation Mapping (ORM). Dabei wird das ORM-Framework NHibernate eingesetzt. Für dieses ist es nötig, die eigenen Enti- täten in einer XML-Datei zu deklarieren, wobei die zu speichernden Eigenschaften und Beziehungen die wichtigste Konfiguration darstellt. Darüber hinaus können noch feinere Einstellungen vorgenommen wer- den. Ebenso kann mit NHibernate über die Deklaration der Entitäten mit ihren Eigenschaften und Beziehungen auch das Datenbankschema erstellt werden. Als Datenbanksysteme können derzeit Firebird und SQLite genutzt werden. 2.4 Implementierung der grafischen Oberfläche Das Framework Empinia erleichtert die Entwicklung von komplexen grafischen Oberflächen. So werden gängige Konzepte unterstützt, wie die der Ansichten (engl. Views) und der Perspektiven (Anordnung der Ansichten und Menüs). Die schon vorhandene grafische Oberfläche von Empinia kann angepasst werden, um die anwendungs- und fachspezifischen Ansichten darzustellen. Diese müssen in zumindest einer Pers- pektive angeordnet werden, welche beim Start geladen wird. Für die Abfallverwaltungssoftware ist eine solche Perspektive konfiguriert, die eine Startseite zeigt. Von dieser Startseite kann zu einer tabellarischen Übersicht navigiert werden, der Dialog zur Abfalldatenerfassung angezeigt werden oder die Berichterstel- lung initiiert werden. Das Kernstück der Abfallverwaltungssoftware ist der in Abbildung 2 gezeigte Dia- log. Da auch Empinia schon Funktionalität in Bezug auf Behandlung von Dialogen mitbringt, kann bei der Entwicklung auf den eigentlichen Inhalt und das Aussehen des Dialoges fokussiert werden. Im Falle der Abfalldatenerfassung, spielt die Abfallherkunft oder auch Quelle beziehungsweise der Ent- stehungsort für die verursachungsgerechte Zuordnung eine entscheidende Rolle. Eine Zuordnung kann, bezogen auf das Nettogewicht des Abfalls, entweder absolut oder prozentual erfolgen, wie aus Abbildung 2 ersichtlich wird. Ein deutliches Gewicht wurde auf die Benutzungsfreundlichkeit (engl. Usability) des Dialoges gelegt. So sind die Grundsätze der Dialoggestaltung 18 beachtet worden. Dazu gehört unter ande- rem die Aufgabenangemessenheit, deren erste Empfehlung besagt, dass „der Dialog [...] dem Benutzer nur solche Informationen anzeigen [sollte], die im Zusammenhang mit der Erledigung der Arbeitsaufgabe ste- hen.“ 19 Außerdem wichtig ist die Fehlertoleranz, sodass es mit minimalem Aufwand möglich ist, in dem Dialog zur Abfalldatenerfassung eine Korrektur vorzunehmen. 20 Des weiteren ist der Dialog so gestaltet, dass dieser keine ungültigen Eingaben zulässt. 16 Create, Read, Update, Delete – in Anlehnung an die SQL-Kommandos – Insert, Select, Update, Delete 17 Vgl. Denz, Busse und Page (2008) 18 Vgl. EN ISO 9241-10 19 Ebd., S. 5 20 Vgl. ebd., S. 10
  7. 7. Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers 7 Abbildung 2: Dialog "Neuen Abfall erfassen" (eigener Entwurf) Aus den erfassten Abfalldaten sollen schließlich automatisiert verschiedene Berichte erstellt werden, die für externe Anspruchsgruppen als auch für interne Zwecke verwendet werden können. Der folgende Ab- schnitt beschreibt die Umsetzung der Berichterstellung. 2.5 Berichterstellung Die Berichterstellungskomponente dient zur Auswertung der erfassten Abfalldatenbasis. Mit ihrer Hilfe können einzelne Berichte (engl. Reports) erstellt, angezeigt sowie gedruckt und in das Microsoft Excel- und PDF-Format exportiert werden. Ein Beispiel dafür ist die jährlich benötigte Abfallbilanz oder eine monatliche Abfallstatistik, sowie beliebige weitere Auswertungen von Daten die in Form von Tabellen oder Diagrammen visualisiert werden. Technisch gesehen basiert diese Komponente auf den Microsoft .NET Report Viewer Windows Forms Controls. Zur Verwendung muss der Report Viewer mit einer Client-Berichtsdefinitionsdatei (RDLC) und einer Datenquelle (DataTable) konfiguriert werden. Die RDLC-Datei entspricht einer lokalen Berichtvor- lage, die das Aussehen beziehungsweise die Aggregation der anzuzeigenden Daten definiert. Die Daten- quelle wird üblicherweise über eine Datenbankabfrage gefüllt und enthält somit die einzelnen Entitäten, die in dem Bericht angezeigt werden sollen. In Empinia erfolgt die Konfiguration einzelner Berichte über einen Erweiterungspunkt. Die Konfiguration beinhaltet vor allem die Verknüpfung der RDLC-Datei mit der gewünschten Komponente zur Anzeige, in diesem Fall dem Microsoft Report Viewer. Zur Nutzung steht in Empinia ein Dienst bereit, der Report Service, welcher die Konfiguration mit der Datenquelle zusammenbringt und den Bericht in einer neuen Ansicht darstellt.
  8. 8. 8 Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth 3 Integration mit Umberto Die Synchronisation mit dem in einem weiteren, gleichzeitigen BAE-Projekt 21 erstellten Stoffstrommodell und damit eine softwaretechnische Integration mit der Software Umberto 5 ist Teil der prototypischen Entwicklung. Im Folgenden wird der konzeptionelle Entwurf dargestellt. Ziel der Integration soll der automatisierte Austausch von Daten sein, um unzumutbare und fehleranfällige Arbeit zu vermeiden. Zu den austauschbaren Daten gehören zum Einen die Abfalldaten aus der Abfall- verwaltungssoftware für das Stoffstrommodell. Diese fehlen derzeit im Modell, sollen aber aufgenommen und auch aktuell gehalten werden. Außer der Menge an Abfall können dem Modell auch die Abfallarten in Form von Materialien bereitgestellt werden, sodass diese in den Flüssen verwendet werden können. Zum Anderen benötigt die Abfallverwaltungssoftware mögliche Herkunftsorte für Abfall, welche die Prozesse darstellen. Diese sind in den Transitionen modelliert und können für die verursachungsgerechte Zuord- nung in der Abfallverwaltungssoftware verwendet werden. Die Daten, die in dem ursprünglichen Umberto-Stoffstrommodell enthalten sind, sind Realdaten und die darauf basierenden Koeffizienten müssen und dürfen nicht geändert werden. Somit muss an dieser Stelle nicht eingegriffen werden. Dennoch muss der Abfall integriert werden. Das folgende, einfache Beispiel soll das Grundproblem illustrieren. Beispiel: S1 → T1 → S2 → S3 S1 = Rohstoff (100%) S2 = Abfall (20%) Abbildung 3: Beispiel (eigener Entwurf) S3 = Produkt (80%) Auf das obige Beispiel bezogen bedeutet dies: Aus den Materialbuchungen im SAP-System, den Realda- ten, geht hervor, dass für die Produktion von einem Stück Produkt S3 ein Stück Rohstoff S1 gebraucht wird. Der entscheidende Punkt hierbei ist, dass in Stück gerechnet wird und nicht in Kilogramm, wie sonst üblich in Umberto. Tatsächlich würden aus 1 kg Rohstoff 0,8 kg Produkte entstehen. Diese Tatsache wird jedoch ignoriert, da sie in diesem Fall irrelevant ist. In der Transition steht für diese beiden ein Koeffizient mit dem Wert 1. Die Menge des nun hinzukommenden Abfalls ist in der Regel davon abhängig, wie viel produziert bzw. verbraucht wurde. In diesem Fall 20% des erzeugten Produkts (es wird immer noch von 1-1 ausgegangen). Um den Koeffizienten für den Abfall zu bestimmen, muss lediglich die Menge des Abfalls in Relation zu den erzeugten Produkten gesetzt werden. Bei Fertigprodukten ist die Menge bekannt, da diese in einem Materialfluss steht. Bei Zwischenprodukten ist die Menge noch nicht bekannt. Also muss zunächst das Modell einmal ohne Abfälle durchgerechnet werden, um alle Mengen zu erhalten. Daraus erhält man die Menge der erzeugten Produkte (beziehungsweise aller Materialflüsse) und die Menge des angefallenen Abfalls und kann den Koeffizienten für den Abfall bestimmen. Es muss auch noch nicht einmal der Mate- rialfluss gesetzt werden, da dieser von Umberto berechnet wird. Durch das Hinzufügen von zusätzlicher Masse, in Form von Abfall, stimmt die Massenbilanz nicht mehr, da mehr Output erzeugt wird, als Input hineingeht. Das wird aber ebenfalls ignoriert. Zum Einen werden die Fertigprodukte nur in Stück bewertet, zum Anderen stehen nicht für alle Materialien Gewichte zur Verfügung. Da am Ende auf Stück Produkte skaliert wird, spielt eine Massenunausgewogenheit keine Rol- le. Ein Flussdiagramm zu dem Vorgehen zeigt die Abbildung 4. 21 Vgl. Erdelt, Hoffmann, Witte (2009)
  9. 9. Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers 9 Original -Modell kopieren Kopie-Modell berechnen Transition Tx , Verbindung Vx , Solange Abfall für Kopie -Modell Referenzfluss R und Ja Nein Periode vorhanden berechnen Koeffizient K R identifizieren Koeffizient Kx berechnen : Kx = (Abfallmenge / R) * KR Kopie -Modell : Abfall-Material und Koeffizient Kx in Transition Tx eintragen , als Ziel die an die identifizierte Verbindung Vx angeschlossene Stelle einstellen Abbildung 4: Flussdiagramm (eigener Entwurf) Auf den in Abbildung 4 dargestellten Untersuchungszeitraum, die Periode, muss insbesondere hingewie- sen werden. Stimmt nämlich die Umberto-Periode nicht mit dem Erfassungszeitraum des Abfalls überein, muss dies in der Berechnung des Koeffizienten berücksichtigt werden. Die technische Umsetzung für die Kommunikation wird über die Microsoft COM-Schnittstellen realisiert, die Umberto bereits mitbringt. Für die Nutzung dieser Schnittstellen hat die ifu Hamburg GmbH freundli- cherweise eine C#-Wrapper-Bibliothek mit einem entsprechenden Dienst für die Integration in Empinia bereitgestellt. 4 Zusammenfassung und Ausblick Zusammenfassend lässt sich sagen, dass mit Hilfe dieser Anwendung die grundsätzlich Voraussetzung dafür geschaffen wurde, um das Abfallaufkommen bei der BAE Batterien GmbH zu verwalten. Obwohl es sich hierbei um eine prototypische Umsetzung handelt, in der noch nicht alle Anforderungen vollständig umgesetzt wurden, wird zum jetzigen Zeitpunkt eine systematische Erfassung unterstützt. Basierend auf dieser Datenbasis kann mit Hilfe der Berichterstellungskomponente das Abfallaufkommen ausgewertet und in Form einer jährlichen Abfallbilanz an den Gesetzgeber derzeitig noch analog übermittelt werden. Anhand des Konzeptes für die Abfallherkunft wurde die Grundlage geschaffen, eine verursachungsgerech- te Zuordnung des Abfalls vorzunehmen. Mittel- bis langfristig gesehen kann somit das Abfallaufkommen einzelner Anfallstellen ausgewertet, analysiert und gegebenfalls optimiert werden. Dadurch wird das Ab- fallaufkommen reduziert und eine Verringerung der Kosten durch erhöhte Materialeffizienz angestrebt. Die Integration mit Umberto – welche derzeitig noch nicht implementiert ist – soll in Zukunft die realen Abfalldaten mit in die Stoffstromanalyse integrieren. Einerseits soll somit eine Validierung der Modell- rechnung anhand der Ist-Daten erfolgen. Darüber hinaus sollen die Materialien im Modell mit den Abfall-
  10. 10. 10 Stefan Simroth, Andreas Taube, Matthias Mäusbacher, Volker Wohlgemuth daten synchronisiert, danach jedes Material anhand seiner Herkunft einer oder mehreren Transitionen zu- geordnet und schließlich die entsprechenden Koeffizienten berechnet werden. Durch die Automatisierung dieser Arbeit wird die Fehleranfälligkeit genommen und das Modell kann dennoch ohne großen Arbeits- aufwand aktuell gehalten werden. Empinia bietet eine gute Voraussetzung, um die Anwendung in Zukunft individuell den Anforderungen anzupassen, denn mit Hilfe des Plugin-Mechanismus kann auf relativ einfachem Wege die Funktionalität der Abfallverwaltungssoftware erweitert werden. So muss zum Beispiel noch das elektronische Abfall- nachweisverfahren (eANV) umgesetzt werden, damit eine automatisierte Übertragung an die ZKS erfol- gen kann. Die gesetzlichen Vorlagen bezüglich der Nachweispflicht wären dann vollständig erfüllt. Ein weiterer Punkt ist der noch nicht vollständig abgedeckte Arbeitsablauf des Abfallbeauftragten in der Software. So kann beispielsweise ein erfasster Abfall derzeitig nicht als entsorgt markiert werden. Folg- lich ist eine Unterscheidung zwischen dem Lagerbestand und dem Bestand der entsorgten Abfälle noch nicht möglich. Allerdings erscheint dies als gut lösbar durch das elektronische Nachweisverfahren, da hier eindeutig ersichtlicht wird, wann der Abfall bei einem Entsorger angekommen ist und somit als entsorgt gelten kann. Des weiteren birgt der Einsatz mobiler Datenerfassung und Abgleich mit der Abfallverwaltungssoftware und der Datenbasis ein großes Potenzial zur weiteren Arbeitserleichterung und größeren Effektivität des Abfallbeauftragten. Danksagung Das Forschungsprojekt wird vom Bundesministerium für Bildung und Forschung (BMBF) gefördert. Die Verfasser danken für die Unterstützung. Literatur Balzert, H. (1999): Lehrbuch der Objektmodellierung. Spektrum, Akad. Verl., Heidelberg, Berlin. Beck, K. (2005): Extreme Programming Explained, Second Edition. Addison-Wesley, Boston. Busse T., Denz N., Page B. (2008): A Plugin-Based Framework for Domain Models and Persistence in Environmental Management Information Systems. In: EnviroInfo 2008 Conference Proceedings, Shaker, Aachen, S. 593-602. Cwalina, K., Abrams, B. (2007): Richtlinien für das Framework-Design: Konventionen, Ausdrücke und Muster für wiederverwendbare .NET-Bibliotheken, Addison-Wesley. Denz N., Schnackenbeck T. (2008): Functionality and Granularity of Plugins and Components, Whitepa- per Erdelt J., Hoffmann B., Witte S. (2009): Durchführung einer ökonomischen und ökologischen IST- Analyse bei einem Batteriehersteller. In: 2. BUIS-Tage Konferenzband. Evans E. (2004): Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Longman, Amsterdam; 1. Auflage. Fowler, M. (2002): Patterns of Enterprise Application Architecture, Addison-Wesley. Gamma, E., Helm, R., Johnson, R., Vlissides, J. (2004): Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley. Gesetz zur Vereinfachung der abfallrechtlichen Überwachung – vom 15. Juli 2006. BGBl I, Seite 1619 Griffel, F. (1998): Componentware - Konzepte und Techniken eines Softwareparadigmas. d-punkt, Hei- delberg.
  11. 11. Entwicklung einer Software auf Empinia-Basis für die Abfallverwaltung eines Batterieherstellers 11 Jahr P., Schiemann L., Panic D., Mäusbacher M., Schnackenbeck T., Wohlgemuth V. (2009): Entwick- lung von Produktionssystem-Komponenten zur Stoffstromsimulation auf Basis des Open-Source- Frameworks Empinia. In: Simulation in den Umwelt und Geowissenschaften Johnson, R., Foote B. (1988): Designing Reusable Classes. In: Journal of Object-Oriented Programming, June/July 1988, Volume 1, Number 2, S. 22-35 Klein U. (2007): Reform der abfallrechtlichen Überwachung. Müll und Abfall 39 (5), S. 240 – 244 Knäpple H. J. (2007): Die neue Nachweisverordnung. Müll und Abfall 39(1), S. 25 – 28 NachwV – Verordnung über die Nachweisführung bei der Entsorgung von Abfällen – vom 20.10.2006. BGBl I, Seite 2298 Richter, J. (2006): Microsoft .NET Framework-Programmierung in C#: Expertenwissen zur CLR und dem .NET Framework 2.0, 2. Auflage, Microsoft Press. Schnackenbeck, T., Panic, D., Wohlgemuth, V. (2007): Eine offene Anwendungsarchitektur als Funda- ment eines Methodenbaukastens für betriebliche Umweltinformationssysteme. In: Simulation in den Umwelt- und Geowissenschaften, Shaker, Aachen, S. 49-59. Wohlgemuth, V. (2005): Komponentenbasierte Unterstützung von Methoden der Modellbildung und Si- mulation im Einsatzkontext des betrieblichen Umweltschutzes, Shaker, Aachen.

×