HMD 290 35

Jan Schümmer, Klaus Reichenberger

Semantische Netze in agilen Projekten

Komplexe Softwareprojekte sind immer mit ei-nem Lern- und Erkenntnisprozess verbunden. Beidiesem Prozess spielen das fachliche Modell undder agile Umgang mit diesem Modell eine ent-scheidende Rolle. Semantische Netze können bei-des optimal unterstützen. Dieser Beitrag be-schreibt, wie semantische Netze als Plattform füragile Projekte einsetzbar sind. Das semantischeNetz dient dabei als ausführbares Datenmodell,das von Softwareexperten und Anwendern ge-meinsam erarbeitet werden kann.

Inhaltsübersicht1 Der Weg zur Anforderung

1.1 Kommunikation von Anforderungen 1.2 Projektbeispiel

2 Semantische Netze im Projektalltag2.1 Form der objektorientierten

Modellierung2.2 Kommunikationsmedium2.3 Abbildung von Business-Logik2.4 Plattform zur interaktiven Gestaltung

von Anwendungen2.5 Änderbarkeit über den gesamten

Softwarelebenszyklus3 Gleichgewicht zwischen Struktur und

Flexibilität4 Literatur

1 Der Weg zur AnforderungAgile Methoden für Softwareprojekte habensich vor allem in Umgebungen bewährt, in de-nen die Anforderungen durch den Kunden nichtschon zu Beginn des Projekts vollständig spezi-fiziert werden können. Meistens liegt die Ursa-che für die Unsicherheiten der Planung darin,dass der Kunde zwar Experte in seiner Fachdo-mäne ist, sich aber schwer damit tut, dieses im-

plizite Wissen seiner Mitarbeiter für Außenste-hende verständlich und vollständig darzustel-len. Aus dem Spezifikationsproblem wird damitein Kommunikations- und Lernproblem.

Fachexperten der Anwendungsdomäne ge-ben ihr Wissen an Softwareexperten weiter, da-mit diese es in Software abbilden, und jederBeteiligte lernt in seinem Fachgebiet dazu[Armour 2004]. In der Kommunikation verwendenbeide Expertengruppen ihr eigenes Vokabularund ihre eigenen Denkmuster. Dieses Aufeinan-dertreffen ist im agilen Prozess wichtig und ge-wollt und entspricht der ersten Aussage desagilen Manifests: »Wir schätzen Individuen undInteraktionen mehr als Prozesse und Werkzeu-ge« [Beck et al. 2001].

1.1 Kommunikation von Anforderungen Wenn die Nutzer ihre Wünsche an Funktionender Software beschreiben, geschieht das meistvor einem Hintergrund komplexer fachlicherZusammenhänge. User Stories, exemplarischbeschrieben in [Cohn 2004], sind gut geeignet,um eine Vorstellung für die gewünschten Funk-tionen zu transportieren. Weniger gut eignensie sich für die Darstellung der dahinter liegen-den komplexen Zusammenhänge, die mit Aus-sagen der Form »Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>« nicht intuitiv greifbarsind. Für dieses Wissen sind andere Beschrei-bungsformen besser geeignet – zum Beispielals Objektmodell, als Regel oder als Paar aus Ur-sache und Wirkung. Anwender sind überfordertdarin, komplexe Modellzusammenhänge alsStories zu formulieren, denn Modellzusammen-hänge sind keine Geschichten.

Für die Kommunikation komplexer Modell-zusammenhänge werden häufig Visualisierun-gen genutzt – z.B. in Form von UML-Klassendia-

Semantische Netze

36 HMD 290

grammen [OMG 2010]. Während allerdingsUser Stories nach der Implementierung ihrenZweck erfüllt haben und nicht weiter gepflegtwerden müssen, haben Modellierungsdoku-mente eine längere Lebensdauer und werdenim weiteren Projektverlauf zu Dokumentations-zwecken vorgehalten.

Im agilen Projekt geschieht es nun häufig,dass diese Dokumente nur so lange gepflegtwerden, bis die Projektergebnisse selbst an-schaulich genug sind, um an ihnen weiter zudiskutieren. Ab diesem Zeitpunkt wird die Aktu-alisierung dieser Kommunikationshilfsmittelgerne vernachlässigt, sodass im weiteren Pro-jektverlauf das Resultat immer stärker vomBauplan abweicht.

Ein weiteres Problem der Kommunikations-hilfsmittel ist der Spagat zwischen Verbindlich-keit und Anschaulichkeit: Für eine Implementie-rung ist es wichtig, ein Modell bis ins Detail for-mal zu fassen. Für Fachanwender hingegen sindstark formalisierte Darstellungen nur schwerverständlich. Ein Extrem stellt der Ansatz derModel Driven Architecture dar: Hier steht dasModell mit einem sehr hohen formalen An-spruch im Mittelpunkt – zur Verbesserung desSoftwareentwicklungsprozesses, aber auf Kos-ten eines hohen Einarbeitungsaufwands für dieFachanwender. Ganz im Gegenteil dazu gilt esaber in vielen Projekten, die knappen Fachan-wender-Ressourcen optimal zu nutzen undÜbersetzungsverluste in der Kommunikation zuminimieren.

Der Konflikt zwischen einer verbindlichenund einer anschaulichen Darstellung findet sichauch in der Verwendung von Beispielen: Wäh-rend die Diskussion von Beispielen den Fachan-wendern leicht fällt, drängen die Softwareex-perten auf eine Verallgemeinerung der Zusam-menhänge. In diesem Beitrag wird gezeigt, wiedie Lücke zwischen Anschaulichkeit und Ver-bindlichkeit, Spezifikation und Umsetzung mit-hilfe semantischer Netze geschlossen werdenkann. Darüber hinaus wird erläutert, wie die Ei-genschaften semantischer Netze auch im wei-

teren Lebenszyklus dem agilen Ansatz entge-genkommen.

Dazu wird im nächsten Abschnitt zunächstein Beispielprojekt vorgestellt, in dem Modell-zusammenhänge direkt in einem semantischenNetz abgebildet wurden.

1.2 ProjektbeispielDer Infrastrukturbereich eines Bahnunterneh-mens will eine Softwareunterstützung für diePlanung von Baustellen schaffen. Das ist keineinfaches Vorhaben: Die Planungsarbeit ist sehrkomplex und sie hat eine große Bandbreite –von kleinen Reparaturen bis zu monatelangenBauprojekten. Dazu kommt: Zu Beginn des Pro-jekts gibt es in den unterschiedlichen Organisa-tionsteilen unterschiedliche Planungsabläufeund eine unterschiedliche Planungstiefe.

Für die Softwareentwickler sind die fachli-chen Zusammenhänge des Eisenbahnwesensund der Baustellenplanung unbekannt und un-verständlich. Es gibt eine Vielzahl an vorhande-nen Softwaresystemen, z.B. zur Verwaltung derGleisinfrastruktur, zur Bestellabwicklung fürMaterial, Maschinen und Personal bis hin zurRegelung des Betriebsablaufs. Diese Systemerücken erst nach und nach ins Sichtfeld des Pro-jektteams. Es ist nicht klar, ob und welche in-haltlichen Berührungspunkte sie zur Baustel-lenplanung haben (sollen) und anhand welcherKriterien über eine eventuelle Anbindung ent-schieden werden kann. Den Fachanwendernfehlt im Gegenzug Wissen über die technischenMöglichkeiten und Restriktionen, denen dasneu zu erstellende Softwaresystem unterwor-fen ist.

Für den Auftraggeber ist es keine Selbstver-ständlichkeit, ein solches Projekt agil durchzu-führen. Im realen Beispielprojekt bestand aller-dings starker Druck, innerhalb eines halbenJahrs eine erste Version des Baustellenpla-nungssystems in Betrieb zu nehmen. DiesesZiel wäre mit einem herkömmlichen Projektvor-gehen und auf einer traditionellen Implemen-tierungsplattform wahrscheinlich nicht zu er-

Semantische Netze

HMD 290 37

reichen gewesen. Agile Methoden und seman-tische Technologie haben wesentlich dazubeigetragen, dieses Projekt zu einem Erfolg zuführen.

2 Semantische Netze im ProjektalltagDer folgende Abschnitt enthält eine kurze Ein-führung in das Thema »Semantische Netze«. ImVerlauf des Beitrags werden dann die verschie-denen, teilweise aufeinander aufbauendenFunktionen beleuchtet, die semantische Netzein der Projektarbeit und später im fertigen Soft-waresystem erfüllen.

2.1 Form der objektorientierten Modellierung

Semantische Netze sind zunächst ein Werk-zeug, um objektorientierte Modelle zu formu-lieren. In dieser Eigenschaft stellen sie folgendeModellelemente bereit:

! Topics: Ein Topic ist die abstrakteste Modell-einheit. Topics können Eigenschaften habenund Beziehungen zu anderen Topics einge-hen.

! Individuen: Individuen sind Topics, die Dingeder realen Welt repräsentieren, vergleichbarmit Instanzen in herkömmlicher objektorien-tierter Begrifflichkeit.

! Begriffe: Gleichartige Individuen werden zueinem Begriff zusammengefasst. Ein Begriffist ein Topic, das das Schema seiner Individuenvorgibt. Begriffe entsprechen Klassen, sindaber anders als z.B. in Java selbst wieder voll-wertige Topics.

! Vererbung: Begriffe werden zu Multihierar-chien angeordnet. Das Schema wird von ei-nem Begriff auf seine Unterbegriffe weiter-gegeben.

! Relationen sind spezielle Individuen, die zweiTopics miteinander verbinden.

! Attribute sind spezielle Individuen, die ato-mare Aussagen über ein einzelnes Topic tref-fen.

Im Detail und der Terminologie unterscheidensich die verschiedenen Plattformen für seman-tische Netze; alle stellen aber diese oder ähnli-che Modellierungskonstrukte bereit.

Abbildung 1 zeigt einen Ausschnitt aus demsemantischen Netz des Projekts. Die Darstel-lung enthält gleichzeitig Beispieldaten (Indivi-duen) und einen Teil des Schemas, in diesemFall der Begriffshierarchie im Bereich »Arbeits-mittel«. Individuen werden als freigestellteKnoten abgebildet, Begriffe sind grau hinter-legt. Das Relationsschema wird mit gestrichel-ten Linien dargestellt, Relationsinstanzen mitdurchgezogenen Linien. Die gestrichelte Linieoben im Bild zeigt die Relation »wird eingesetztbei«, die allgemein zwischen Arbeitsmittelnund Baustellenaktivitäten definiert ist. Weiterunten in der Hierarchie wird durch diese Relationausgedrückt, dass der »Bendini KranwagenBT-BW« im Arbeitsschritt »Fahrdraht ziehen BS-SI« zum Einsatz kommt.

2.2 KommunikationsmediumWie kann ein semantisches Netz die Kommuni-kation von komplexen Modellzusammenhän-gen unterstützen? Zunächst einmal kann dasim semantischen Netz repräsentierte Modellgrafisch dargestellt werden – das rückt es in dieNähe von Hilfsmitteln wie UML.

Der entscheidende Unterschied stellt sichdann ein, wenn die Software auf Basis eines se-mantischen Netzes implementiert wird, d.h.,das semantische Netz tritt an Stelle der her-kömmlichen Datenbank. Alle grafischen undanderen Darstellungen zur Kommunikation mitden Fachexperten werden dann aus dem se-mantischen Netz generiert. Das ist auch derUnterschied zu einer Reihe älterer [Mylopouloset al. 1986] und neuerer Ansätze [Kožusznik &Štolfa 2011], semantische Netze als Hilfsmittelim Softwareprozess einzusetzen: Diese Ansätzeleiden unter den gleichen Problemen, solangedas semantische Modell als zusätzliches Arte-fakt lediglich den Softwareprozess abbildet und

Semantische Netze

38 HMD 290

nicht selbst Teil der zu entwickelnden Anwen-dung wird.

Die Vorteile, Kommunikationsmittel undtechnische Basis nicht auseinanderlaufen zulassen, sind im Einzelnen folgende:

! Es müssen keine gesonderten Artefakte er-stellt und gepflegt werden, Darstellungendes Modells werden aus der Implementie-rung heraus erzeugt und reflektieren immerden aktuellen Stand.

! Semantische Netze sind eine Wissensreprä-sentation, die auf größtmögliche Anschaulich-keit ausgelegt ist [Reichenberger 2010]. Mit ei-nem geeigneten Werkzeug ist zudem dieeinfache Darstellung von Teilausschnitten undverschiedenen Abstraktionsebenen möglich.

Im Gegensatz z.B. zu einem abstrakten UML-Diagramm können in ein semantisches Netz inVerbindung mit geeigneter Software direkt Bei-

spiele eingegeben werden. Anhand von Beispie-len unterliegt das Modell einem ständigen Testgegen die Fachanwender-Wirklichkeit. Die Da-ten lassen keine unklaren oder widersprüchli-chen Modellvorstellungen zu und zwingen alleBeteiligten zur frühen Klärung.

Wie wichtig dieser Realitätstest sein kann,wird an einem Beispiel sichtbar, das im Zuge desAusprobierens im Bahnprojekt entstanden ist(vgl. Abb. 2).

Anhand des Beispiels erkennt ein Fachex-perte auf Anhieb einen Fehler: Es kann nichtsein, dass in einer Schicht verschiedene Bauzü-ge eingesetzt werden, weil diese sich auf demGleis gegenseitig behindern würden. In der ab-strakten Darstellung eines Datenmodells ist einsolcher Fehler für Fachanwender nur schwer er-kennbar: Dort ist lediglich eine 1:1-Zuordnungvon Bauzügen zu Arbeitsgängen notiert, die aufden ersten Blick richtig aussieht.

Abb. 1: Beispiel eines semantischen Netzes

Semantische Netze

HMD 290 39

Ein solcher Einsatz eines semantischen Netzesstellt auch Anforderungen an die Modellierungs-umgebung. Im Idealfall erlaubt die Umgebunges, in einer Diskussion Varianten online durchzu-spielen und das Modell zu ändern. In unseremBaustellenplanungsprojekt ist es eher die Regelals die Ausnahme, dass verschiedene Nutzer un-terschiedliche Vorstellungen vertreten: Zum Bei-spiel stellte sich in einem Workshop heraus, dassdie ursprüngliche Annahme »Personen werdenArbeitsschritten zugewiesen« nicht haltbar ist,weil die konkreten Personen in frühen Phasender Baustellenplanung noch nicht bekannt sind.In der Diskussion wurden gemeinsam alternativeModelle entworfen und ausprobiert: »Müssenwir im frühen Planungsstadium überhaupt einePerson dem Arbeitsschritt zuordnen?« »Reichtvielleicht eine Relation zu einer Maschine, die wirspäter um die Person ergänzen, die die Maschinebedient?« Im Endeffekt wurden statt konkreterPersonen Platzhalter eingefügt und so die inhalt-liche Planung von der Ressourcenplanung ge-trennt. Dabei war es ein entscheidender Vorteil,im Verlauf der Diskussion das tatsächlicheModell ändern zu können und so Konsequenzendeutlich zu machen.

Das semantische Netz kann Kommunikationüber die Vokabulargrenzen hinweg unterstüt-zen, indem es ein Modell der Anwendungs-domäne aufbaut, das für alle Beteiligten ver-ständlich ist und anhand dem sie Varianten dis-kutieren und Lösungsansätze durchspielenkönnen. Zum Durchspielen gehört aber nochmehr: In semantischen Netzen können weiteTeile der Business-Logik durch Modellierungentwickelt werden und müssen daher nichtmehr ausprogrammiert werden.

2.3 Abbildung von Business-LogikEine große Stärke semantischer Netze sind dieMittel, die sie für Schlussfolgerungen und Kon-sistenzregeln mitbringen. Dadurch wird es sehreinfach, Business-Logik unter Einbeziehung derFachanwender zu formulieren.

Zum Beispiel ist eine Maschine, die in einemArbeitsschritt eingesetzt wird, auch der Bau-stelle zugehörig – auch wenn keine direkte Rela-tion zwischen der Maschine und der Baustellebesteht und es eine Vielzahl unterschiedlicherRelationsarten gibt, die eine »Zugehörigkeit«begründen (zu sehen im linken Screenshot inAbb. 3).

Abb. 2: Fachliche Fehler in der Modellierung werden in Beispielen unmittelbar sichtbar

Semantische Netze

40 HMD 290

Im rechten Screenshot in Abbildung 3 ist beispiel-haft die Bedingung für eine Konsistenzregel darge-stellt: Eine Person, die einen Bendini-Kranwagenführt, muss die SUVA-Kranausbildung erfolgreichabgeschlossen haben, weil diese Ausbildung füralle Schienenfahrzeuge vom Typ »Kranwagen« vor-geschrieben ist, nicht aber für die Bedienung einerLokomotive. Da Peter Müller die Ausbildung nichtbesitzt, warnt das System den Baustellenplaner,wenn er ihn als Kranwagenführer einsetzen will.

Je nach verwendetem System bestehennoch viele weitere Möglichkeiten zur Formulie-rung von Business-Logik, so beispielsweise inForm von Konsistenzregeln und Schlussfolge-rungen, aber auch durch folgende Mittel:

! Trigger, die als Reaktion auf Topic-Änderun-gen Aktionen auslösen: Wenn auf einer Bau-stelle Schotter benötigt wird, muss für dieseneine Bestellung in der SAP-Materialverwal-tung ausgelöst werden.

! Skripte, in denen z.B. der Ablauf einer Trigger-Aktion festgelegt wird.

! Berechtigungen: Eine Baustellenplanung darfnur durch den zuständigen Planer und dessendirekte Kollegen bearbeitet werden.

! Vorkonfigurierte Suchen: »Finde alle Baustellenim Umkreis von 50 km um die aktuell bearbei-

tete Baustelle, bei denen ähnliche Tätigkeitenwie in der aktuellen Baustelle eingeplant wur-den« (um dadurch dem Planer Hinweise für dieKoordination z.B. von Maschineneinsätzen, be-nötigten Gleissperrungen etc. zu geben).

Diese (und weitere weniger prominente) Basis-mechanismen sind auf der Grundstruktur dessemantischen Netzes definiert und funktionie-ren auf jedem Modell. Man kann daher dasfachliche Modell ändern, ohne dadurch dieFunktion der semantischen Basismechanismenzu gefährden. So kann viel Business-Logik insModell verlagert werden.

2.4 Plattform zur interaktiven Gestaltung von Anwendungen

Wie wird das semantische Netz zu einer funk-tionsfähigen Anwendung weiterentwickelt? Dieverfügbaren Plattformen bringen Funktionali-tät dafür mit: Für die späteren Endanwenderdes Systems gibt es eine konfigurierbare Web-oberfläche, die im Ausgangszustand ebenfallsZugriff auf den gesamten Datenbestand er-laubt (vgl. Abb. 4). In der Konfiguration derWeboberfläche können unter anderem die fol-genden Aspekte angepasst werden:

BendiniKranwagenBT-BW

FahrdrahtziehenBS-SI

Fahrdrahtregulieren …

Fahrdrahtprüfen …

Schicht 2OL BS-SI

SchichtOL BS-SI

ErneuerungOL BS-SI

BendiniKranwagenBT-BW Traktion

Kranwagen

LokomotiveAM 824

Müller, Peter

Schienenfahrzeug

SUVAKranausbildung

LokomotiveAM 234

Abb. 3: Schlussfolgerungen und Konsistenzregeln im semantischen Netz

Semantische Netze

HMD 290 41

! Auswahl und Reihenfolge der darzustellen-den Eigenschaften eines Topics

! Verhalten der Pflegemasken ! Navigationsstrukturen und anzuzeigende

Kontextinformationen! Buttons für fachspezifisches Verhalten wie

z.B. »Freigabeprozess für eine Baustellenpla-nung anstoßen«

2.5 Änderbarkeit über den gesamten Softwarelebenszyklus

Dieses Vorgehen hat weitreichende Auswirkun-gen auf die Arbeit im Projekt: Die Softwareex-perten können schnell auf Änderungswünschereagieren. Dabei rückt das Schreiben von Pro-grammcode für sie in den Hintergrund, dennder größte Teil der Implementierung erfolgt inForm von Modell- und Konfigurationsanpas-

sungen. Die Kunden haben die ständige Chance(und Verpflichtung) zur Mitwirkung und zumFeedback und können die Entwicklung direktanhand des laufenden Systems mitverfolgen.

Ein weiterer Grund ist der Wunsch, überden gesamten Lebenszyklus der Software soviel Flexibilität zu bewahren wie möglich. Jedetechnische Umsetzung schafft – auch wenn sieagil entstanden ist – Abhängigkeiten undSachzwänge in Form von Datenbankschemata,von auf dem Schema implementierten Funkti-onen und von zugesicherten Schnittstellen zuFremdsystemen. Diese Zwänge führen imschlimmsten Fall dazu, dass das agile Verspre-chen, Software jederzeit anpassen und erwei-tern zu können, schon in frühen Phasen desSoftwarelebenszyklus nicht mehr eingehaltenwird.

Abb. 4: Weboberfläche der Baustellenplanungssoftware

Semantische Netze

42 HMD 290

Moderne Implementierungsplattformen ha-ben das Problem erkannt und reagieren daraufz.B. mit Werkzeugen zum Datenbank-Refacto-ring. Ein semantisches Netz und die Abdeckungvon Anforderungen durch Modellierung helfenschon in der Anlage der Software, die Abhän-gigkeiten zu kontrollieren: Benötigt z.B. eineKonsistenzregel eine direkte Verbindung zwi-schen Maschinen und Arbeitsgängen, diese di-rekte Verbindung wird aber im Rahmen einerModelldiskussion aus dem Schema entfernt, somacht das System auf den Konflikt aufmerk-sam.

3 Gleichgewicht zwischen Struktur und Flexibilität

Flexibilität wird benötigt, um auf sich ent-wickelnde Anforderungen zu reagieren. Strukturin Form einer »guten« Systemarchitektur giltallgemein als Qualitätsmerkmal für ein robus-tes, wartbares und leistungsfähiges Software-system. Steht Flexibilität im Widerspruch zuStruktur? Im vorliegenden Beitrag kann auf die-se Frage keine erschöpfende Antwort gegebenwerden, im folgenden Abschnitt wird allerdingsdargelegt, wie Agilität und Flexibilität im Sinneeiner guten Systemarchitektur genutzt werdenkönnen.

Denn vergleichbar den aus Programmcodebekannten »Code-Smells« [Cunningham 1992]gibt es auch in Datenmodellen typische Män-gel, von denen einige auf mangelnde Flexibili-tät der Umsetzungsplattform zurückzuführensind:

! Die vorhandenen Strukturen werden zweck-entfremdet, weil der Aufwand und die Risikeneiner Anpassung gescheut werden. Wennzum Beispiel der Objekttyp »Adresse« keinFeld für »Hinterhaus« vorsieht, die Informationfür den Anwender aber aus irgendeinemGrund wichtig ist, kommen Anwender schnellin die Versuchung, ein anderes selten genutz-tes Feld (zum Beispiel »c/o«) für diese Infor-mation zu verwenden. Das mag zwar im Ein-

zelfall zielführend sein, führt aber in der Sum-me spätestens dann zu Problemen, wenn z.B.aus dem »c/o«-Feld irgendwann einmal eineBeziehung »ist erreichbar bei« zwischen zweiEntitäten abgeleitet werden soll.

! Aus Rücksicht auf das bereits vorhandeneModell werden Kompromisse anstelle vonProblemlösungen implementiert. Je größerund umfangreicher das bereits vorhandeneModell ist, desto größer ist auch die Scheu da-vor, grundlegende Änderungen daran vorzu-nehmen – selbst wenn diese Änderungen alsfachlich korrekt und »eigentlich notwendig«erkannt wurden. Mögliche Ursachen für die-ses Verhalten gibt es viele: die entstehendenKosten, die alte Weisheit »Never change arunning system!«, die Auswirkungen auf vor-handene Daten und Dokumentation odereinfach nur das ungute Gefühl, »alles nocheinmal von vorne bauen« zu müssen. Anstelledes Umbaus tritt dann ein Anbau an das be-stehende Schema.

! Die Anforderungen an das Softwaresystemhaben sich immer weiter von der eigentli-chen Zielsetzung entfernt, und die eigentlichinteressanten Business-Objekte landen inÜberlaufbereichen. Solche Überlaufbereichefinden sich häufig in Datenmodellen von Alt-systemen. Zunächst vergleichbar mit einerRubrik »Sonstiges« für die Speicherung vonRandobjekten, Zusatzinformationen oderEinzelfällen gedacht, bieten diese Überlauf-bereiche fatalerweise die Flexibilität, die demrestlichen Datenmodell fehlt, um auf neueAnforderungen reagieren zu können. Die Ver-suchung ist dann groß, diese Anforderungenunter immer intensiverer Nutzung dieses un-terstrukturierten Bereichs umzusetzen.

Jedes einzelne dieser Symptome mag für sich ge-nommen harmlos sein, aber über die Zeit und imZusammenwirken können sie dazu führen, dassein Datenmodell seine wichtige Funktion als Kom-munikationsmedium und Wissensrepräsentationnicht mehr erfüllen kann. Semantische Netze, ins-besondere wenn große Teile der Anwendung dort

Semantische Netze

HMD 290 43

modelliert sind, senken durch ihre Flexibilität dieHemmschwelle für eine kontinuierliche Weiter-entwicklung des Datenmodells. Damit helfen sieüber den gesamten Softwarelebenszyklus dabei,derartige Code-Smells zu vermeiden.

Ein Datenmodell gewinnt an Qualität, wenn:

! … bei der Modellierung die Anwenderwirk-lichkeit und nicht die Umsetzung von Software-Features im Vordergrund steht. Modellemüssen »natürlich« sein, damit Fachanwen-der sie jederzeit verstehen können.

! … die Modellierung von einem minimalenKern ausgeht und erst im Zuge des Lernpro-zesses punktuell die Elemente hinzufügt, diezur Repräsentation der aktuell neu gewonne-nen Erkenntnis benötigt wird. Daraus er-wächst die Chance, ein schlankes verstehba-res Projektergebnis zu erzielen.

! … erkannte Defizite gezielt und fortlaufenddurch Ergänzungen und Umstrukturierungen(Refactorings) ausgeglichen werden.

! … es in seiner Komplexität der Anwenderwirk-lichkeit angemessen ist. Ein Modell muss sokomplex wie nötig sein, um die Anwender-wirklichkeit abzubilden. Es darf nicht komple-xer sein als sein Gegenstand.

Agilität kann nur im Ausgleich zwischen Struk-tur und Flexibilität stattfinden, denn einem100 % flexiblen System kann man keine Rich-tung geben, während ein 100 % strukturiertesSystem keinen Spielraum für Anpassungenlässt. Semantische Netze helfen dabei, ein aus-gewogenes Verhältnis zwischen Struktur undFlexibilität zu erreichen.

4 Literatur[Armour 2004] Armour, P. G.: The laws of software

process: a new model for the production andmanagement of software. Auerbach Publications,2004.

[Beck et al. 2001] Beck, K.; Beedle, M.; van Bennekum, A.;Cockburn, A.; Cunningham, W.; Fowler, M.;Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.;Kern, J.; Marick, B.; Martin, R. C.; Mellor, S.;Schwaber, K.; Sutherland, J.; Thomas, D.: Mani-fest für Agile Softwareentwicklung, http://agilemanifesto.org/iso/de/; Zugriff am 10.10.2012.

[Cohn 2004] Cohn, M.: User Stories Applied: ForAgile Software Development. Addison-WesleyProfessional, Boston, MA, 2004.

[Cunningham 1992] Cunningham, W.: The WyCashportfolio management system. Addendum tothe proceedings on Object-oriented program-ming systems, languages, and applications (Ad-dendum). Vancouver, British Columbia, Canada,October 18-22, 1992, pp. 29-30.

[Kožusznik & Štolfa 2011] Kožusznik, J.; Štolfa, S.:Knowledge Based Approach to Software Deve-lopment Process Modeling. Digital InformationProcessing and Communications (Proceedingsof ICDIPC 2011 Part II). Springer-Verlag, Berlin,Heidelberg, 2011, pp. 16-28.

[Mylopoulos et al. 1986] Mylopoulos, J.; Borgida, A.;Greenspan, S.; Meghini, C.; Nixon, B.: Knowledgerepresentation in the software developmentprocess: A case study. Lecture Notes in Controland Information Sciences, Vol. 80, Springer-Ver-lag, Berlin, Heidelberg, 1986, pp. 23-44.

[OMG 2010] Object Management Group: OMGUnified Modeling Language (OMG UML), Infra-structure, Version 2.3, 2010.

[Reichenberger 2010] Reichenberger, K.: Kompendiumsemantische Netze: Konzepte, Technologie, Mo-dellierung. Springer-Verlag, Heidelberg, 2010.

Dipl.-Inf. Jan SchümmerKlaus Reichenbergerintelligent views gmbhJulius-Reiber-Str. 1764293 Darmstadt{j.schuemmer, k.reichenberger}@i-views.dewww.i-views.de

Schümmer, J.; Reichenberger, K.: Semantische Netze in agilen Projekten. HMD – Praxis der Wirtschaftsinformatik 50 (2013), 290, S. 35-43.