SCHWERPUNKT Softwarearchitekturen dokumentieren Nie wieder planlos Auf einen Blick André Krämer Architekturdokumentation spart Kosten

Transkript

1 Softwarearchitekturen dokumentieren Nie wieder planlos Die Dokumentation ist die wohl am häufigsten vernachlässigte Tätigkeit bei Softwareprojekten. Sie hat den Ruf einer langwierigen und mühseligen Arbeit. Die Vorlage arc42 nimmt ihr den Schrecken. Auf einen Blick André Krämer ist selbstständiger Softwareentwickler, Trainer, Certified Professional for Software Architecture Foundation Level des ISAQB, Mitglied im Microsoft-CLIP-Programm und erhielt 2009 den Infragistics MVP Award. Er konzipiert und entwickelt Webanwendungen mit ASP.NET MVC und SharePoint. Bei der.net User Group Koblenz hält er regelmäßig Vorträge rund um das Thema.NET. Sie erreichen ihn über Inhalt Vorteile einer korrekten Dokumentation. Die Dokumentation standardisieren. Die Dokumentvorlage arc42. dnpcode A1208Arc42 T ypischer Alltag: Das Projekt läuft auf Hochtouren, der Abgabetermin naht. Alle Beteiligten stehen unter Spannung. Es wird entwickelt, gemanagt und getestet; keine Zeit für Dokumentation. Wozu auch dokumentieren? Das würde nur unnötige Kosten verursachen; und schließlich kennen doch alle Projektmitarbeiter das System und wissen, wie es funktioniert. So sieht die Situation bei vielen Softwareprojekten aus: Die Architektur der Anwendung wird nicht dokumentiert. Die Gründe sind vielfältig. So gilt die Dokumentation der Architektur als zeitaufwendig, teuer, unnötig weil sowieso alle Beteiligten wissen, wie das System funktioniert oder einfach als unpassend, weil es das agile Paradigma stört, dem sich das Team verpflichtet sieht und das ja so wenig Dokumentation wie möglich zum Leitsatz erhebt. Doch bereits bei Projekten mittlerer Größe ist es keine Seltenheit, dass während ihrer Laufzeit neue Mitarbeiter das Team verstärken. Wurde die Architektur dann nicht dokumentiert, muss sie jedem neuen Teammitglied persönlich erläutert werden, und zwar jedes Mal! Dieser Vorgang bremst das bestehende Team aus, da man sich Zeit nehmen muss, um den neuen Kollegen einzuarbeiten. Diese Aufgabe kann dem Projekt nicht produktiv zugeschlagen werden und belastet somit die Kosten. Und was ist danach? Das nächste Problem entsteht, wenn die Entwicklung der Software abgeschlossen ist und das Projekt in die Wartungsphase geht. Nicht selten obliegt die Wartung Personen, die nicht zum ursprünglichen Entwicklungsteam gehörten. Dies kann zum einen daran liegen, dass die eigentlichen Entwickler und Architekten mittlerweile an einem neuen Projekt arbeiten, oder aber daran, dass sie zwischenzeitlich den Arbeitgeber gewechselt haben. Im ersten Fall ist eine zeitaufwendige und somit teure Übergabe durch die ursprünglichen Entwickler an das Wartungsteam notwendig. Aber noch kostspieliger wird es im zweiten Fall, da sich das Wartungsteam erst unter großem Aufwand auf der Quellcodeebene in die Architektur einarbeiten muss, um diese zu verstehen. Gerade dieser Fall kann extreme Kosten nach sich ziehen, denn es ist nicht nur der Aufwand für das Ergründen der Architektur zu berücksichtigen, sondern auch die Zeit, bis das neue Team produktiv Änderungen in hochwertiger Qualität vornehmen kann. In der Praxis kommt es nämlich häufig vor, dass Entwickler Teile des Codes und der Architektur zunächst falsch interpretieren, wenn sie keine weitere Dokumentation zum Code zur Seite haben. In dieser Phase führen Änderungen am System dann in der Regel eher zu einer Verschlimmerung als zu einer Verbesserung. Architekturdokumentation spart Kosten Damit dürfte klar geworden sein, dass es erhebliche Kosten erzeugt, wenn eine Dokumentation der Softwarearchitektur fehlt. Natürlich ersetzt eine Dokumentation keine persönliche Erklärung eines Systems, sie beschleunigt diese allerdings merklich. Somit stellt sich als Nächstes die Frage, wie sich eine Dokumentation möglichst kostengünstig erstellen lässt. Um diese Frage zu beantworten, sollte man sich zunächst die Hauptkostentreiber bei der Dokumentation vor Augen halten. Der erste große Kostenblock entsteht, während sich der Architekt eine geeignete Struktur für die Dokumentation überlegt. Gerade Architekten, die das erste Mal dokumentieren, verlieren hier sehr viel Zeit. Zuweilen kann sich sogar eine gewisse Ratlosigkeit einstellen, die den Architekten blockiert. Ist diese erste Hürde genommen, entsteht der nächste große Kostenteil beim Ausfüllen der erstellten Struktur, also der eigentlichen Dokumentation. Das Hauptproblem in dieser Phase ist, dass viel Aufwand in der Dokumentation unnötiger Dinge versickert oder an Stellen, an denen es überhaupt nicht notwendig oder sinnvoll wäre, zu detailliert dokumentiert wird. Eine standardisierte Vorlage löst die beiden Probleme. Sie gibt die Gliederung bereits vor, sodass sich der Architekt hierum keine Gedanken mehr machen muss, sondern sofort mit dem Ausfüllen beginnen kann. Dem Leser hilft sie, da er im Idealfall bereits mehrere Dokumentationen im Stil der standardisierten Vorlage gelesen hat und somit sofort weiß, in welchem Kapitel er die für sich wichtigen Infor

2 Details auf die entsprechenden Anforderungsdokumente. Ziel ist, dem Leser einen groben Überblick zu vermitteln, was die Software eigentlich tut. Weiter werden in diesem Kapitel die drei bis fünf wichtigsten Qualitätsziele des Projekts festgehalten. Beispiele für solche Ziele wären: Laufzeitverhalten Sicherheit Nutzerfreundlicher Umgang (usability) Verfügbarkeit (availability) [Abb. 1] Die Darstellung des fachlichen Kontextes in Form eines UML-Paketdiagramms. Qualitätsziele haben maßgeblichen Einfluss auf die Entwicklung einer Softwarearchitektur. Daher weisen die Autoren der arc42-vorlage innerhalb des verborgenen Textes des Dokuments auch noch einmal eindringlich auf die Erhebung und Dokumentation dieser Ziele hin. Als letzten Punkt listet das Kapitel noch alle von der Architektur betroffenen Personen auf, also die Stakeholder des Projekts, und beschreibt ihren Einfluss auf die Architektur. Das wären zum Beispiel der Auftraggeber, die Nutzer der Software, die Entwickler und so weiter. mationen findet. Im besten Fall sind der Vorlage auch bereits einige Beispiele beigelegt, aus denen der dokumentierende Architekt schließen kann, mit welchem Detaillierungsgrad die verschiedenen Kapitel auszufüllen sind. Eine Vorlage zur Dokumentation von Softwarearchitekturen ist das frei verfügbare arc42-template von Peter Hruschka und Gernot Starke, für das auch einige Beispiele bereitstehen, siehe [1] und [2]. Die Vorlage selbst ist in Deutsch und Englisch in verschiedenen Formaten verfügbar, unter anderem für Word, als PDF oder für Sparx Enterprise Architect. Sie steht unter einer Creative-Commons-Lizenz und kann somit kostenlos in eigenen, auch kommerziellen, Projekten genutzt werden. In der aktuellen Version 5.0 ist die Vorlage in die folgenden Kapitel eingeteilt: Einführung und Ziele Randbedingungen Kontextabgrenzung Lösungsstrategie Bausteinsicht Laufzeitsicht Verteilungssicht Typische Muster, Strukturen und Abläufe Technische Konzepte Entwurfsentscheidungen Qualitätsszenarien Risiken Glossar Die Vorlage enthält zu jedem Kapitel übrigens auch detaillierte Informationen, die allerdings als verborgener Text formatiert sind. Um sie in der Word-Variante anzuzeigen, müssen Sie lediglich über das Tastenkürzel [Strg]+[*] oder über das Absatzmarkensymbol in der Multifunktionsleiste alle ausgeblendeten Formatierungssymbole einblenden. Als weitere Referenz zur Vorlage bietet sich [3] an. Das Template selbst versteht sich übrigens als Baukasten. Das bedeutet, dass nicht alle Kapitel unbedingt auszufüllen sind, sondern lediglich solche, die im jeweiligen Umfeld sinnvoll sind. Und die Kapitel, die ausgefüllt werden, sollten Sie außerdem so schlank wie möglich halten. Je umfangreicher eine Architekturdokumentation ist, desto geringer ist die Wahrscheinlichkeit, dass sie tatsächlich gelesen wird. Einführung und Ziele Das Kapitel Einführung und Ziele ist die Einleitung des Dokuments. Es besteht aus einer kurzen Zusammenfassung der gestellten Aufgabe und verweist für die Randbedingungen Kapitel 2, Randbedingungen, beschäftigt sich mit den äußeren Einflüssen auf die Softwarearchitektur. Dies können technische Randbedingungen sein wie zum Beispiel, dass die Software auf einer bestimmten Hardware, einem Server etwa oder einem Mobiltelefon, laufen muss. Weiter werden auch organisatorische Randbedingungen dokumentiert wie der Zeitplan, das Vorgehensmodell, rechtliche Faktoren et cetera. Zuletzt werden noch die bestehenden Konventionen dokumentiert; dazu gehören zum Beispiel Programmierrichtlinien. Kontextabgrenzung Das Kapitel Kontextabgrenzung dient als Einstieg in die Systemarchitektur. Es stellt das System im Zusammenspiel mit all seinen Nachbarsystemen und Akteuren dar, erklärt also alle relevanten Schnittstellen. Diese Kontextsicht ist somit vergleichbar mit der aus dem Hausbau bekannten Einzeichnung des Objekts in den Lageplan, die der Architekt nutzt, um mit dem Bauherrn über das Objekt zu diskutieren. Auch bei der berühmten Softwarearchitektur, die sich auf einem Bierdeckel erklären lässt oder erklären lassen sollte, handelt es sich in den meisten Fällen um eine Kontextsicht

3 Softwarearchitekturen dokumentieren Tabelle 1 Mapping zwischen fachlichem und technischem Kontext. Fachliche Schnittstelle Kundendaten Verkäufe Mails Stammdatenpflege Systemnutzung Technischer Kanal SOAP via http SOAP via http XML-RPC via PerspectiveMCAPI http http [Abb. 2] Der Verteilungskontext eines Webshops. Zur Darstellung der Kontextsicht werden zwei Diagramme zu Hilfe genommen, jeweils für den fachlichen Kontext und den technischen oder Verteilungskontext. Im fachlichen Kontext stellt ein UML-Paketdiagramm das System und alle Nachbarsysteme als Blackbox dar. An dieser Stelle soll die Dokumentation also bewusst auf Details verzichten. Dies erleichtert die Diskussion der Architektur mit Stakeholdern, die nur über wenig technisches Verständnis verfügen, wie zum Beispiel die Kunden. Abbildung 1 zeigt exemplarisch die Kontextsicht eines Webshops, der mit drei externen Systemen kommuniziert und durch zwei Akteure bedient wird. Das Diagramm zum technischen oder Verteilungskontext stellt dar, über welche Kanäle das System mit seinen Nachbarsystemen kommuniziert und welche Art Daten ausgetauscht werden. Dies erfolgt in Form eines UML-Deployment-Diagramms; Abbildung 2 zeigt, wie dies für das Beispiel eines Webshops aussehen könnte. Sind beide Diagramme erstellt, werden sie durch eine Mapping-Tabelle zur Deckung gebracht. Für die Diagramme aus Abbildung 1 und Abbildung 2 sähe das Ergebnis wie in Tabelle 1 aus. Lösungsstrategie Das vierte Kapitel einer Architekturdokumentation nach arc42 beschreibt die Lösungsstrategie. Hier geben Fließtexte einen kurzen Überblick über die grundlegenden Architekturentscheidungen und Lösungsansätze. Unter anderem führt dieses Kapitel die eingesetzten Architekturmuster wie zum Beispiel Pipes und Filter oder Model- View-Controller auf und begründet kurz die Entscheidung für den Einsatz dieser Muster. Generell sollte dieses Kapitel recht schlank ausfallen, da die Details in den späteren Abschnitten folgen. Bausteinsicht Nachdem die Kontextabgrenzung in Kapitel 3 den großen Gedanken der Lösung zeigt, der sich hervorragend zur Diskussion mit technisch unbedarften Stakeholdern wie etwa Projektleitern oder Kunden eignet, wird es im fünften Kapitel in der Bausteinsicht detailliert. Es beschreibt in Form von Black- und Whiteboxes die statische Struktur des Systems. Verglichen mit dem Hausbau würde es sich bei der Bausteinsicht um den Grundrissplan des Hauses handeln. Ausgehend von einem Top-down- Entwurf werden verschiedene Detaillierungsgrade für die Bausteinsicht erzeugt. Die Vorlage schlägt drei Ebenen vor, die in Abbildung 3 zu sehen sind. Jede Ebene hat ein Unterkapitel, und jedes dieser Unterkapitel hat wiederum pro Whitebox ein weiteres Unterkapitel. Wie Abbildung 3 zeigt, wird in der ersten Ebene das Gesamtsystem als Whitebox beschrieben und die einzelnen Bausteine als Blackboxes. In der zweiten Ebene werden nun die Blackboxes der ersten Ebene als Whiteboxes dargestellt. Die einzelnen Bausteine der zweiten Ebene werden dagegen zu den Blackboxes. Und so geht es weiter zur dritten Ebene, in der weiter detailliert wird: Die Blackboxes der Ebene zwei werden hier als Whiteboxes beschrieben; außerdem werden die Bausteine der Ebene zwei als Blackboxes dargestellt. Die Beschreibung einer Whitebox verläuft nach folgendem Schema: Name der Whitebox Übersichtsdiagramm als UML-Paketdiagramm wie in Abbildung 3 Liste der lokalen Blackbox-Bausteine Liste der Beziehungen zwischen lokalen Blackboxes sowie von den Beziehungen zu äußeren Bausteinen Beschreibung der Entwurfsentscheidungen, die zum Design der Whitebox geführt haben Auflistung der verworfenen Entwurfsalternativen (optional) Verweise auf zusätzliche Informationen (optional) Offene Punkte (optional) Die Auflistung der Blackbox-Bausteine einer Whitebox geschieht wiederum mit diesen Informationen:

4 Einsteigen & besser fliegen als centron- Reseller Werden Sie centron-reseller! Bis zu 20% Provision für Hostings, Domains, Server: zuverlässig, professionell und in zertifizierter Qualität. centron Qualität: [Abb. 3] Das Schema der drei Ebenen der Bausteinsicht. Die Abbildung ist der arc42-vorlage entnommen. Name der Blackbox Zweck der Blackbox für die Gesamtlösung Liste der Schnittstellen Liste der Abhängigkeiten (optional) Verweis auf Quellcode-Artefakte Liste der Anforderungen, die der Baustein erfüllt Variabilität Sonstige Metadaten, beispielsweise Autor, Versionsinformation et cetera Offene Punkte (optional) Laufzeitsicht Die Bausteinsicht stellt die Struktur des Systems statisch dar, beschreibt also, aus welchen Bausteinen das System besteht und welche Verbindungen zwischen den Bausteinen existieren. Sie zeigt jedoch nicht, wie die Instanzen dieser Bausteine zur Laufzeit miteinander kommunizieren. Dazu dient Kapitel 6, Laufzeitsicht, welches die Kommunikation zwischen den Bausteinen mithilfe von UML-Sequenz-, Aktivitäts- oder Kommunikationsdiagrammen dokumentiert. Dabei sollte sich der Autor der Dokumentation auf die wichtigsten Abläufe innerhalb des Systems konzentrieren; eine vollständige Darstellung sämtlicher Abläufe ist nicht gewünscht. Stattdessen schlagen die Autoren der arc42-vorlage die folgenden Punkte vor: die wichtigsten drei bis fünf Anwendungsfälle, den Systemstart (Bootstrapping), das Verhalten an den wichtigsten externen Schnittstellen und das Verhalten in den wichtigsten Fehlerfällen. Premium Support Unsere Mitarbeiter beantworten Ihre Fragen fachkundig, freundlich und schnell. Premium-Support mit kostenloser Hotline Mehr Informationen auf

5 Softwarearchitekturen dokumentieren [Abb. 4] Sequenzdiagramm des Anwendungsfalls Bezahlen mit PayPal. Wie eine solche grafische Beschreibung aussehen kann, zeigt Abbildung 4. Sie stellt den Anwendungsfall Bezahlen mit Pay- Pal eines Online-Shops dar. Zu jedem Diagramm der Laufzeitsicht gehört zudem noch eine kurze Texterläuterung. Verteilungssicht Nachdem die Bausteinsicht gezeigt hat, was läuft, und die Laufzeitsicht das Wie darstellt, beantwortet Kapitel 7 der Vorlage, Verteilungssicht, die Frage nach dem Wo. Es zeigt die Hardwarekomponenten wie physische Rechner, Netzwerktopologien und so weiter und beschreibt die geografische Verteilung des Systems. Die Darstellung erfolgt mit UML-Verteilungsdiagrammen, die zum Beispiel für jede Umgebung Entwicklung, Test, Produktion et cetera angelegt werden. Typische Muster, Strukturen und Abläufe Bei der Entwicklung der meisten Softwaresysteme gibt es wiederkehrende Aufgaben, die im Idealfall immer gleich gelöst werden. Für das bisher zur Hilfe genommene Beispiel eines Online-Shops unter ASP.NET MVC wäre die Nutzung der Persistenzschicht durch den Controller eine solche wiederkehrende Aufgabe. Da diese Aufgabe (hoffentlich) immer gleich gelöst wird, sollte sie auch nur ein einziges Mal innerhalb der Architekturdokumentation beschrieben werden. Das achte Kapitel Typische Muster, Strukturen und Abläufe sieht dazu zwei Unterkapitel vor. Das erste zeigt die typischen Muster und Strukturen und hat somit eine statische Sicht auf das System; das zweite widmet sich den typischen Abläufen und stellt die Kommunikation zwischen den zuvor statisch beschriebenen Strukturen nun dynamisch dar. Technische Konzepte Das neunte Kapitel einer arc42-dokumentation beschäftigt sich mit den technischen Konzepten einer Architektur. Damit sind Querschnittsaufgaben gemeint, für die es keinen Baustein gibt. Die Vorlage schlägt dazu bereits eine umfangreiche Liste von Querschnittsaufgaben vor, die dokumentiert werden könnten: Datenspeicherung Benutzeroberfläche Ergonomie Ablaufsteuerung Transaktionsbehandlung Sessionbehandlung Sicherheit Kommunikation und Integration mit anderen IT-Systemen Verteilung Plausibilisierung und Validierung Behandlung von Ausnahmen bei Fehlern Verwaltung des Systems Logging, Protokollierung und Tracing Geschäftsregeln Konfigurierbarkeit Parallelisierung und Threading Internationalisierung Migration Testbarkeit Skalierung, Clustering Hochverfügbarkeit Zu jedem der genannten Punkte liefert die Vorlage einen kurzen Hinweis, wie dieser auszufüllen ist. In der Praxis erweisen sie sich als recht hilfreich, da sie teilweise dazu anregen, über Dinge nachzudenken, die man vielleicht bisher bei der Entwicklung der Architektur nicht ausreichend berücksichtigt hat. Die gerade aufgeführte Liste ist zwar bereits recht umfassend, lässt sich aber bei Bedarf natürlich noch erweitern. Umgekehrt können Sie einige der Punkte je nach dem vorliegenden konkreten Fall selbstverständlich auch entfernen. Falls Sie zum Beispiel ein System komplett neu entwickeln, ohne Daten aus einem Altsystem zu übernehmen, ist es kaum sinnvoll, den Punkt Migration zu beschreiben. Somit könnten Sie diesen ersatzlos aus der Liste der technischen Konzepte streichen

6 [Abb. 5] Der Qualitätsbaum setzt Qualitätsziele, Eigenschaften und Szenarien zueinander in Beziehung. Entwurfsentscheidungen In der Softwareentwicklung gibt es bei der Realisierung der Anforderungen häufig mehr als einen Weg zum Ziel. Die Aufgabe des Architekten sowie der Entwickler ist es, sich für einen dieser Wege zu entscheiden. Haben diese Entscheidungen größere Auswirkungen, werden sie im Kapitel Entwurfsentscheidungen festgehalten. Starke und Hruschka empfehlen, Entscheidungen der folgenden Kategorien zu dokumentieren [3]: Entscheidungen... mit lang anhaltender Wirkung (Grundlagenentscheidungen), mit Überraschungseffekt für künftige Entwickler oder Architekten, bei denen von Standardlösungen abgewichen wurde, die unter hohen Risiken oder Zeitdruck getroffen wurden, die beträchtliche Auswirkungen auf Qualitätsmerkmale haben. Für jede Entscheidung sollte es ein eigenes Unterkapitel mit den folgenden Punkten geben: Zugrunde liegende Frage Rahmenbedingungen Annahmen Betrachtete Alternativen Entscheidung Die Punkte selbst werden mit Fließtext gefüllt. Qualitätsszenarien Die Einführung einer Dokumentation nach arc42 hält, wie bereits angemerkt, die Qualitätsziele des Projekts fest. Sie haben einen maßgeblichen Einfluss auf die Architektur. Das elfte Kapitel greift dies auf und erarbeitet geeignete Szenarien, die das Erreichen der Qualitätsziele messbar machen. Dazu wird zunächst ein Qualitätsbaum angelegt. Abbildung 5 zeigt, wie in solch einem Baum ausgehend von den Qualitätszielen die Eigenschaften herausgearbeitet werden, die in konkrete Szenarien münden. Die gefundenen Qualitätsszenarien werden anschließend detaillierter beschrieben. Dies ermöglicht es, den Erfolg der Architektur mit Bezug auf die Ziele zu bewerten. Risiken Jede Softwarearchitektur ist mit Risiken behaftet, und diese gilt es zu erkennen und präventiv anzugehen. Zu diesem Zweck verfügt die arc42-vorlage über ein eigenes Kapitel für Risiken. In Form beispielsweise einer Tabelle ist in diesem Kapitel für jedes Risiko eine kurze Beschreibung niedergelegt, dazu die Eintrittswahrscheinlichkeit, die Schadenshöhe sowie Maßnahmen zur Risikovermeidung oder -minimierung. Selbstverständlich beschränkt sich diese Liste ausschließlich auf Risiken, die im Zusammenhang mit der Architektur stehen. Alle anderen Risiken gehören in die Risikoinventarliste des Projektleiters. Glossar In erfolgreichen Projekten sprechen alle Projektbeteiligten dieselbe Sprache. Im Idealfall ist dies die Sprache des Kunden, was bedeutet, dass auch die Entwickler dessen Fachbegriffe nutzen sollten. Da diese Begriffe den Entwicklern aber nicht zwangsläufig bekannt sind, sollten sie in einem Glossar festgehalten werden, mit dem eine arc42-dokumentation im dreizehnten Kapitel schließt. Dies geschieht am besten in Form einer Tabelle mit den Spalten Begriff und Definition. Da es sich bei der Architekturdokumentation aber um ein technisches Dokument handelt, sollten auch wichtige technische Begriffe, die nicht jedermann geläufig sind, ins Glossar aufgenommen werden. Das stellt sicher, dass alle Beteiligten auch stets dasselbe meinen, wenn sie dieselben Begriffe verwenden. Fazit Die frei verfügbare Vorlage arc42 nimmt der Architekturdokumentation ihren Schrecken, indem sie eine einheitliche und gut durchdachte Themenstruktur liefert. Sehr positiv fällt auf, dass die Autoren der Vorlage großen Wert auf Praxistauglichkeit gelegt haben. So merken sie an mehreren Stellen an, dass die Dokumentation möglichst schlank gehalten werden sollte. Außerdem geben sie nützliche Hinweise, welche Teile detailliert beschrieben werden sollten und welche eher kurz gehalten werden können. Trotz aller Hilfestellung erledigt sich die Dokumentation natürlich auch mit dieser Vorlage nicht von selbst. Der Aufwand reduziert sich jedoch merklich was wieder um die Kosten reduziert. Bei alldem sollten Sie aber auch im Hinterkopf behalten, dass Architekturdokumentation kein einmaliger Vorgang ist. Es handelt sich vielmehr um einen kontinuierlichen Prozess, für den regelmäßig Zeit eingeplant werden sollte, zum Beispiel alle zwei Wochen vier Stunden. [jp] [1] Das arc42-template, [2] Effektive Software-Architekturen, Downloads, [3] Gernot Starke, Peter Hruschka, Software- Architektur kompakt, ISBN