{"id":779,"date":"2009-11-09T13:52:13","date_gmt":"2009-11-09T11:52:13","guid":{"rendered":"http:\/\/www.foerderverein-technische-fakultaet.at\/?p=779"},"modified":"2009-11-09T13:52:13","modified_gmt":"2009-11-09T11:52:13","slug":"specification-comprehension-konzeptverwaltung-am-beispiel-zustandsbasierter-spezifikationen","status":"publish","type":"post","link":"https:\/\/www.ftf.or.at\/?p=779","title":{"rendered":"Specification Comprehension &#8211; Konzeptverwaltung am Beispiel zustandsbasierter  Spezifikationen"},"content":{"rendered":"<p><a href=\"http:\/\/www.foerderverein-technische-fakultaet.at\/wp-content\/uploads\/2009\/11\/Pohl_Daniela.JPG\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-780\" title=\"Pohl_Daniela\" src=\"http:\/\/www.foerderverein-technische-fakultaet.at\/wp-content\/uploads\/2009\/11\/Pohl_Daniela.JPG\" alt=\"Pohl_Daniela\" width=\"143\" height=\"200\" \/><\/a>\u2026 ist der Titel einer der <strong>besten Diplom- bzw. Magisterarbeiten aller Studien der Technischen Fakult\u00e4t an der Universit\u00e4t Klagenfurt<\/strong> und wurde vom <strong>F\u00f6rderverein Technische Fakult\u00e4t<\/strong> mit <strong>EUR 750,\u2013<\/strong> ausgezeichnet. Die Autorin und Preistr\u00e4gerin, Frau DI Daniela Pohl, ist nun Mitarbeiterin am <a href=\"http:\/\/www.uni-klu.ac.at\/tewi\/inf\/isys\/index.html\">Institut f\u00fcr Informatiksysteme<\/a>, Forschungsgruppe &#8222;<a href=\"http:\/\/www.uni-klu.ac.at\/tewi\/inf\/isys\/sesc\/index.html\">Software Engineering und Soft Computing<\/a>&#8222;, und arbeitet dort als Universit\u00e4tsassistentin unter anderem an ihrer Dissertation. Der Preis wurde im Rahmen der <a href=\"..\/2009\/10\/eroffnung-des-akademischen-jahres-20092010\/\">Er\u00f6ffnung des akademischen Jahres 2010\/2011<\/a> \u00fcbergeben und wir m\u00f6chten ihre <strong>Diplom- bzw. Magisterarbei <\/strong>kurz vorstellen.<\/p>\n<p><strong>Kurzfassung<\/strong>:<\/p>\n<p>Man\u00a0 stelle\u00a0 sich\u00a0 vor,\u00a0 man\u00a0 st\u00fcnde\u00a0 vor\u00a0 einem\u00a0 gro\u00dfen,\u00a0 sch\u00f6nen\u00a0 Haus\u00a0 mit\u00a0 einem\u00a0 einzigen\u00a0 Haken,\u00a0 einem\u00a0 Schild\u00a0 an der\u00a0T\u00fcre:\u00a0\u201eBetreten\u00a0des\u00a0Hauses\u00a0auf\u00a0eigene\u00a0Gefahr!\u201c.\u00a0W\u00fcrden\u00a0Sie\u00a0freiwillig\u00a0eintreten?<\/p>\n<p>Eigentlich stehen wir vor dem gleichen Problem wenn man an die Software\u2010Entwicklung denkt. Wer garantiert, dass Software auch dies h\u00e4lt, was sie verspricht oder zu versprechen scheint? Wenn man ehrlich ist: nicht immer kann es versprochen werden. Um sicherzustellen und zu u\u0308berpru\u0308fen ob eine Software die Anforderungen h\u00e4lt, muss man in erster Linie eine M\u00f6glichkeit finden, sie zu bewerten. Dafu\u0308r muss eine Software aber leichter und besser verstanden werden. Das Verstehen ist sowohl w\u00e4hrend als auch bei Aktivit\u00e4ten nach der eigentlichen Entwicklung, wie der Wartung, notwendig. Dies erm\u00f6glicht es erst zu entscheiden, ob die Vorstellungen und Versprechungen der Software erfu\u0308llt wurden. [MBPR01, S 95] Dieser Gedanke bildet die Basis meiner Arbeit: die Unterstu\u0308tzung des Verstehens der Eigenschaften von Software. Dafu\u0308r mu\u0308ssen Konzepte der Software identifiziert, sowie deren Zusammenh\u00e4nge verstanden werden. Um diesen Prozess zu unterstu\u0308tzen wurde ein Framework implementiert. Es wurde dabei so konzipiert, dass es mit beliebigen Dokumenten umgehen kann. Exemplarisch werden im Rahmen der Arbeit formale Z\u2010Spezifikationen herangezogen.<\/p>\n<p>Die Welt ist voller Konzepte und Abh\u00e4ngigkeiten. Somit beinhalten auch Dokumente der Softwareentwicklung, von Analysedokumenten u\u0308ber Design, bis hin zur Implementierung, Konzepte und Abh\u00e4ngigkeiten. Durch \u00c4nderungen im Projekt finden auch \u00c4nderungen der Konzepte im Dokument statt. Sie werden hinzugefu\u0308gt, verworfen oder ausgebaut. Das Verst\u00e4ndnis dieser Dokumente ist immer notwendig, daher gilt es den Verst\u00e4ndnisprozess bestm\u00f6glich zu unterstu\u0308tzen. Dokumente besitzen eine bestimmte Struktur. Diese Struktur besteht aus unterschiedlichen Teilen, bei einem normalen Schriftstu\u0308ck zum Beispiel aus Kapiteln, Abs\u00e4tzen und S\u00e4tzen. Fu\u0308r das Gesamtverst\u00e4ndnis mu\u0308ssen Teile innerhalb von Dokumenten h\u00e4ufig miteinander in Verbindung gebracht werden. Auch Verweise auf andere Dokumente k\u00f6nnen notwendig sein. Die im Dokument enthaltenen Teile beschreiben bestimmte, notwendige Konzepte und deren Zusammenh\u00e4nge. Meist werden im Text beschriebene Konzepte und Zusammenh\u00e4nge falsch interpretiert, weil sie vielleicht im Widerspruch mit unseren Vorstellungen stehen, oder sie werden auch einfach u\u0308bersehen. Konzepte bilden ein wichtiges, wenn nicht sogar ein m\u00e4chtiges, Hilfsmittel im Verst\u00e4ndnis von Dokumenten jeglicher Art.<\/p>\n<p>Ein Softwareprojekt, unabh\u00e4ngig vom dahinterliegenden Prozessmodell, besteht aus verschiedenen Phasen und Abschnitten, welche innerhalb der Laufzeit auch mehrmals durchlaufen werden k\u00f6nnen. W\u00e4hrend jeder dieser Phasen werden Dokumente erstellt, in denen das Wissen und die Erkenntnisse u\u0308ber die entstehende Software festgehalten werden. Ideen werden dabei ausgebaut, verworfen oder neu aufgenommen. Dokumente weisen daher komplexe, umfangreiche Inhalte auf. Diese Dokumente werden erstellt, um den Entstehungsprozess zu unterstu\u0308tzen und zu erleichtern, um Informationen u\u0308ber Projektgrenzen hinweg zu kommunizieren und fu\u0308r die sp\u00e4teren Phasen festzuhalten. Dafu\u0308r mu\u0308ssen Dokumente, von jedem der sie verwendet, verstanden werden. W\u00e4hrend es einem einfach erscheint, Dokumente, welche man selbst geschrieben hat, zu verstehen, sind Dokumente aus anderen Quellen nicht immer sofort klar und verst\u00e4ndlich.<\/p>\n<p>Der Ursprung des Konzeptes stammt aus der Philosophie. Konzepte beschreiben Generalisierungen oder Abstraktionen, abgeleitet von spezifischen Merkmalen der Instanzen. Immanuel Kant, als einer der bedeutendsten Philosophen, beschreibt Begriffe fu\u0308r das Verstehen von Konzepten als eine notwendige Vorraussetzung fu\u0308r die Erkenntnis im Denkprozess [HaSc88]. Der Begriff bildet eine Abstraktion des Gesehenen aufgrund von unterschiedlichen Merkmalen ab. Dadurch wird es einem beispielsweise erm\u00f6glicht zwischen einer normalen Funkfernbedienung und einem Mobiltelefon zu unterscheiden. Genau diese Begriffe geben den Konzepten einen Namen und lassen uns mentale Modelle unserer Welt aufbauen und verstehen. Oft wird davon gesprochen, dass man sich ein mentales Modell aufbauen muss, um Dokumente verstehen zu k\u00f6nnen. Durch das mentale Modell kann die urspru\u0308ngliche Idee hinter dem Dokument aufgegriffen werden. Dies ist sowohl in Bereichen der Software\u2010Wartung und Evolution, als auch in der normalen fortschreitenden Entwicklung notwendig, vor allem wenn Informationen aufgrund der Menge vergessen werden oder neue Projektmitglieder hinzukommen. Konzepte helfen dieses Modell aufzubauen. Die Identifizierung von Konzepten, auch Concept\u2010Location genannt, erfolgt mittels unterschiedliche Verfahren [ChRa00, ACC+02 oder WHGT99]. Dabei k\u00f6nnen zum Beispiel jene Stellen im Code identifiziert werden, in denen aufgrund der Wartungsaktivit\u00e4ten \u00c4nderungen durchgefu\u0308hrt werden mu\u0308ssen, oder auch Funktionalit\u00e4ten erg\u00e4nzt werden mu\u0308ssen.<\/p>\n<p>Auch bei der komponentenbasierte Software\u2010Entwicklung ist das Aufbauen eines mentalen Modells wichtig [MBPR01]. Durch das Verstehen von Software\u2010Komponenten, kann festgestellt werden ob die gewu\u0308nschte Funktionalit\u00e4t durch die Komponente gesichert ist. Reuse (Wiederverwendung) und Comprehension (Verst\u00e4ndnis) stehen daher in engem Zusammenhang. Dabei stehen unterschiedliche Arten von Informationsquellen, wie beispielsweise Source\u2010Code und in idealen Situationen auch Spezifikationen, zur Verfu\u0308gung. Mitglieder eines Softwareteams mu\u0308ssen daher bei dem Aufbau des mentalen Modells und bei der Identifizierung von Konzepte und der Verwaltung bereits identifizierter Konzepte unterstu\u0308tzt werden.<\/p>\n<p>Spezifikationen sind, wenn vorhanden, eine wu\u0308nschenswerte und wertvolle Informationsquelle. Sie beschreiben die Funktionalit\u00e4t bzw. die Eigenschaften eines Softwareproduktes in einer semantisch kompakten Arten und Weise [Boll04, S. 17]. Aufgrund dessen sind Spezifikationen oft nicht leicht verst\u00e4ndlich, vor allem und in erschwerter Weise, wenn der Ursprung des Dokumentes nicht von eigener Hand kommt oder auch l\u00e4ngere Zeit zuru\u0308ckliegt. Weiters bieten Spezifikationen einem die M\u00f6glichkeit, kompakt die Eigenschaften eines Systems zu beschreiben. Schon aufgrund der kompakten Schreibweise ist es hier wichtig Teile in Spezifikationen zu finden, die mit anderen Teilen in Verbindung stehen, um so Konzepte und ein Verst\u00e4ndnis fu\u0308r diese Konzepte zu erm\u00f6glichen. Auch ein partielles Verst\u00e4ndnis eines Spezifikationsdokuments kann notwendig sein, um beispielsweise Fehler auszubessern, \u00c4nderungen in Spezifikationen nach zu ziehen oder einen Einblick in die Eigenschaften der Software(\u2010Komponente) zu bekommen.<\/p>\n<p>Aus diesem Grund beschreibt die eingereichte Arbeit, ein Konzeptverwaltungssystem, welches die Identifizierung und persistente Verwaltung von Konzepten in Spezifikationsdokumenten erm\u00f6glicht. Dadurch wird die Bildung eines mentalen Modells fu\u0308r ein bestimmtes Dokument erleichtert. Im Rahmen der Arbeit wird die Rekonstruktion von Konzepten als eine mehrdimensionale Repr\u00e4sentation angesehen, in der Konzepte aufgrund ihres Charakters in unterschiedlichen Konzeptebenen kategorisiert werden. Die beschriebene mehrdimensionale Abbildung erm\u00f6glicht es, Konzepte von Dokumenten zu manifestieren und mit anderen Konzepten unterschiedlicher Ebenen in Beziehung zu setzen. Aufbauend auf diese Abbildung wurde ein Datenbankschema entwickelt, welches die gewonnen Informationen persistent speichert und im Rahmen des Entwicklungsprozesses ablegt. Die Abh\u00e4ngigkeiten zwischen Konzepten k\u00f6nnen u\u0308ber einfache Datenbankabfragen ermittelt werden.<\/p>\n<p>Der Ansatz wurde generisch gehalten, um in weiterer Folge auch andere Dokumenttypen verwalten zu k\u00f6nnen. Zudem k\u00f6nnen zuku\u0308nftig dadurch Konzepte verschiedener Dokumente des Entwicklungsprozesses miteinander in Verbindung gesetzt werden, um weiters die Ru\u0308ckfu\u0308hrbarkeit (Traceability) oder die Entwicklung von Konzepten festzuhalten. Zur Veranschaulichung des Ansatzes wurden fu\u0308r die Extraktion Spezifikationsdokumente herangezogen. Hierfu\u0308r wurde ein bestehendes System, das ViZ (Visualization of Z Specifications) Projekt des Instituts fu\u0308r Informatiksystem der Alpen\u2010Adria Universit\u00e4t Klagenfurt [Boll07], erweitert. Das System unterstu\u0308tzt die Suche von Konzepten in Z\u2010Spezifikationen. Jedoch werden dabei komplexe, rechenintensive Algorithmen zur Ermittlung der Informationen herangezogen und die Ergebnisse nicht persistent abgelegt.<\/p>\n<p>Das grunds\u00e4tzliche Ziel dieser Arbeit ist es zu zeigen, wie durch Konzeptverwaltung der Prozess der Software\u2010Entwicklung unterstu\u0308tzt werden kann. Ein Anforderungsdokument, eine Spezifikation oder ein Programm bauen auf verschiedenen Konzepten. Diese Konzepte bilden sich durch die Analysephase innerhalb der Anforderungserhebung. Es soll gekl\u00e4rt werden, inwiefern Konzepte den Entwicklungsprozess unterstu\u0308tzten k\u00f6nnen. Der Verhalt wird exemplarisch am Beispiel zustandsbasierter Z\u2010Spezifikationen gezeigt werden. Um dies jedoch erfolgreich zu diskutieren, mu\u0308ssen aber zus\u00e4tzliche Teilbereiche n\u00e4her durchleuchtet werden.<\/p>\n<p>Es wurde gezeigt, wie Konzepte manifestiert, verwaltet und miteinander in Verbindung gebracht werden k\u00f6nnen. Dabei wurde als erstes der Begriff \u201eKonzept\u201c n\u00e4her untersucht. Viele Bereiche der Softwareentwicklung sprechen von Konzepten, ohne jedoch den Begriff im Detail zu definieren. Aus diesem Grund wurde der Konzeptbegriff im Bezug auf Z\u2010Spezifikationen klar abgegrenzt. Weiters wurde festgehalten, wie Konzepte miteinander in Verbindung stehen und wie diese Verbindungen lokalisiert werden k\u00f6nnen.<\/p>\n<p>Um eine Unterstu\u0308tzung im Software\u2010Prozess zu erm\u00f6glichen, beschreibt die Arbeit zudem welche Funktionalit\u00e4ten zur Unterstu\u0308tzung des Comprehension und Reengineering\u2010Prozesses fu\u0308r Spezifikationsdokumente von N\u00f6ten sind. Da die alleinige Speicherung von Konzepten nicht ausreichend ist, wurde in der Arbeit untersucht, wie Beziehungen zwischen Konzepten effizient abgebildet werden k\u00f6nnen. Weiters wurden verschiedene anderer Funktionalit\u00e4ten fu\u0308r die Handhabung der verwalteten Konzepte im Bereich von Comprehension und Reengineering ben\u00f6tigt. Eine detaillierte Erarbeitung und Aufschlu\u0308sselung der Funktionalit\u00e4ten war daher erforderlich.<\/p>\n<p>Vollst\u00e4ndige und vor allem aktuelle Spezifikationen sind im Bereich von Software\u2010Wartung und Evolution besonders hilfreich. Durch die Untersuchung von unterschiedlichen Vor\u2010 und Nachteilen, wird die Relevanz der Konzeptverwaltung im Bezug auf Software\u2010Wartung und Evolution ergru\u0308ndet. Da Konzepte auch hier eine entscheidende Rolle spielen, mu\u0308ssen m\u00f6gliche Anforderungen ebenfalls fu\u0308r diese Bereiche erfasst werden. Durch die Beru\u0308cksichtigung des Softwareentwicklungsprozess mit den wichtigsten Subdisziplinen werden die zu erfu\u0308llenden Anforderungen erhoben. Diese mu\u0308ssen durch eine geeignete Concept\u2010Location\u2010Repr\u00e4sentation (vgl. mehrdimensionale Repr\u00e4sentation) abgedeckt werden. Deshalb wird sowohl die gew\u00e4hlte Repr\u00e4sentationsform als auch die im Rahmen der Arbeit durchgefu\u0308hrte Implementierung in Hinblick auf ihre Eignung durch aus der Literatur bekannten Beispielen fu\u0308r Z\u2010Spezifikationen evaluiert.<\/p>\n<p><strong>Literatur<\/strong><\/p>\n<p>[MBPR01] Roland T. Mittermeir, Andreas Bollin, Heinz Pozewaunig, and Dominik Rauner\u2010Reithmayer. Goal\u2010driven combination of software comprehension approaches for component based development. SIGSOFT Software Engineering Notes 26, Seiten 95\u2010\u2010102, New York, NY, USA, 2001. ACM.<\/p>\n<p>[HaSc88] Robert Hartman und Wolfgang Schwarz. Immanuel Kant Logic. Dover Publications, Inc., Mineola, New York, 1988.<\/p>\n<p>[ChRa00] Kunrong Chen und V\u00e1clav Rajlich. Case Study of Feature Location Using De\u2010 pendence Graph. In IWPC &#8217;00: Proceedings of the 8th International Workshop on &#8230;. Program Comprehension, Seite 241, Washington, DC, USA, 2000. IEEE Computer Society.<\/p>\n<p>[ACC + 02] Giuliano Antoniol, Gerardo Canfora, Gerardo Casazza, Andrea De Lucia, und Ettore Merlo. Recovering Traceability Links between Code and Documentation. IEEE Trans. Softw. Eng., 28(10):970\u2010\u2010983, 2002.<\/p>\n<p>[WHGT99] W. Eric Wong, Joseph R. Horgan, Swapna S. Gokhale, und Kishor S. Trivedi. Locating Program Features using Execution Slices. In ASSET &#8217;99: Proceedings of the 1999 IEEE Symposium on Application \u2010 Specific Systems and Software Engineering and Technology, Seite 194, Washington, DC, USA, 1999. IEEE Computer Society.<\/p>\n<p>[Boll04] Andreas Bollin. Specification Comprehension Reducing the Complexity of Specifications. Dissertation, Institute for Informatics\u2010Systems, University of Klagenfurt, 2004.<\/p>\n<p>[Boll07] Andreas Bollin. The ViZ Framework \u2010 Support for Formal Z Specification Comprehension. Technical report, AAU KLU, Klagenfurt, \u00d6sterreich, Juni 2007.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u2026 ist der Titel einer der besten Diplom- bzw. Magisterarbeiten aller Studien der Technischen Fakult\u00e4t an der Universit\u00e4t Klagenfurt und wurde vom F\u00f6rderverein Technische Fakult\u00e4t mit EUR 750,\u2013 ausgezeichnet. Die Autorin und Preistr\u00e4gerin, Frau DI Daniela Pohl, ist nun Mitarbeiterin &hellip; <a href=\"https:\/\/www.ftf.or.at\/?p=779\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"sfsi_plus_gutenberg_text_before_share":"","sfsi_plus_gutenberg_show_text_before_share":"","sfsi_plus_gutenberg_icon_type":"","sfsi_plus_gutenberg_icon_alignemt":"","sfsi_plus_gutenburg_max_per_row":"","footnotes":""},"categories":[12],"tags":[25,24,26],"class_list":["post-779","post","type-post","status-publish","format-standard","hentry","category-news","tag-konzeptverwaltung","tag-specification-comprehension","tag-zustandsbasierte-spezifikationen"],"_links":{"self":[{"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=\/wp\/v2\/posts\/779","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=779"}],"version-history":[{"count":5,"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=\/wp\/v2\/posts\/779\/revisions"}],"predecessor-version":[{"id":785,"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=\/wp\/v2\/posts\/779\/revisions\/785"}],"wp:attachment":[{"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=779"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ftf.or.at\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}