Home

TRACES - Universität Klagenfurt

Contents

1. Quality of schedule Degree of Minimal _ gt parlieipation Minimal effort conflicts Matching 1 gt n x 7 i LA effort Schedule Collection effort meeting Collect _ timetables S Choose By schedule Byallmeans By email Have updated Collect timetables them Abb 6 Korrelation aller Ziele 9 Manually Automatically F r die Modellierung von Zielen wurden ebenfalls Frameworks in zahlreichen wissenschaftlichen Arbei ten vorgestellt Im Zuge meiner Recherchen sind das i Framework und die KAOS Methode fters aufgetreten 5 Entwicklungen in der K nstlichen Intel ligenz Wie schon erw hnt hat die Wissensrepr sentation ihren Ursprung in der K nstlichen Intelligenz Im speziellen liegt die Bedeutung im Einsatz einer Ontologie In den folgenden Abschnitten m chte ich erkl ren was Onto logie bedeutet und welche Entwicklungen es in diesem Bereich gegeben hat 5 1 Was ist eine Ontologie Der Begriff Ontologie wurde bisher bereits fters erw hnt aber was wird unter einer Ontologie verstan den An sich kommt der Begriff aus der Philosophie und bedeutet soviel wie die Lehre des Seienden und be schreibt somit die Beschaffenheit der Welt In der Informatik wurde der Begriff eingef hrt um einen Wissensbereich knowledge domain mit Hilfe einer standardisierenden Terminologie sowie von Be ziehungen und Ableitungsregeln zwischen den dort definierten Begriffen zu be
2. NET Das von Microsoft erstellte Komponenten modell NET soll das in die Jahre gekommene COM DCOM Modell abl sen Eine NET Anwen dung wird hnlich wie bei EJB und dem CCM in einem Container ausgef hrt welcher auch hier f r bergeord nete Dienste zust ndig ist Der Container arbeitet in der Regel mit mehrere unterschiedlichen NET Enterprise Servern zusammen Beispiele f r NET Enterprise Ser ver k nnen sein Exchange Server Application Center SQL Server BizTalk oder auch ein Host Integration Server um Zugriff auf IBM Mainframe Applikationen sicherzustellen Innerhalb des Containers befindet sich ebenso die Gesch ftsschicht bestehend aus sogenann ten Managed Components Sie kapseln die Gesch fts und Datenlogik wobei Datenbankzugriffe mittels Acti ve Data Objects ADO NET realisiert werden NET bietet dar ber hinaus einen einfachen Weg an mittels Webservices ber WSDL SOAP UDDI und BizTalk mit Gesch ftspartnern zu kommunizieren ASP NET erm glicht externen Ger ten Web Browser PDA etc ber Benutzerschnittstellen in Form von HTML mit der Enterprise Applikation in Verbindung zu treten Micro softs Komponentenmodell ist weitgehend sprachunab h ngig jedoch f r den Einsatz unter hauseigenen Be triebssystemen optimiert 24 Noch bietet keines dieser Modelle echte Interopera bilit t an Interoperabilit t bedeutet die F higkeit ver schiedenste Softwareanwendungen geschrieben in un terschiedlichen P
3. 2 Aspektorientierte Programmierung Parnas 8 beschreibt die unterschiedlichen M glichkeiten der Dekomposition Die Entscheidung in welche Komponenten ein Softwaresystem aufgeteilt wird hat drastische Auswirkungen auf die Komplexit t Wartbarkeit und Erweiterbarkeit des Systems Aspektorientierte Programmierung AOP ist ein Ansatz der auf der Objektorientierten Programmierung OOP aufbaut und deren Vorteile beibeh lt 2 1 Aspekte Bei der Objektorientierten Programmierung wer den einzelne funktionale Einheiten eines Systems iden tifiziert die dann zu einem Gesamtsystem zusammen gef gt werden Bestimmte Funktionalit ten eines Sys tems lassen sich jedoch nicht eindeutig einer funktiona len Komponente zuordnen So sind zum Beispiel Effi zenz bei Speicherzugriffen bzw Fehlerbehandlung sys temweite Interessen Oft muss bei Paaren von Concerns entschie den werden nach welchem der Concerns das System zu modularisieren ist Der andere Concern der nicht Grundlage des System entwurfs war verteilt sich dann ber das ge samte System und bildet einen Crosscutting Concern 9 Diese Eigenschaften eines Systems sie werden auch querschneidende Interessen Cross Cutting Con cerns genannt weil sie quer durch funktionale Kom ponenten schneiden werden von Aspekten behandelt Schon in fr hen Stadien des Designs sollte eine klare Abgrenzung zwischen Komponenten und Aspekten ge schehen hnlich der Trennung v
4. 20 The Linux kernel archives Retrieved on 12 05 2007 from http www kernel org 21 Linux using goto in kernel source 2003 Retrieved on 18 05 2007 from http kerneltrap org node 553 2131 22 Goto im Kernel 2005 Retrieved on 18 05 2007 from http www lk ete tu bs de lists archiv lug bs 2005 04 msg00063 html 23 GCC the GNU compiler collection Retrieved on 12 05 2007 from http gcc gnu org 24 L Clark 1984 A linguistic contribution to goto less programming Communications of the ACM Vol 27 No 4 pp 349 359 25 W A Wulf 1972 A case against the GOTO Proceedings ofthe ACM Vol 2 pp 791 797 26 Common Surnames in Japan Retrieved on 06 06 2007 from http www rootsweb com jpnwgw Names html Model Driven Software Development and Beyond Eine geschichtliche Betrachtung des Artikels Executable Object Modeling with Statecharts von David Harel und Eran Gery Seminararbeit f r 622 002 SB Seminar aus Angewandte Informatik SS 2007 Alpen Adria Universit t Klagenfurt Michael Steindorfer 0560854 ABSTRACT Bereits in den neunziger Jahren pr sentierten David Harel und Eran Gery mit dem Artikel Executable Object Mo deling with Statecharts einen Modellierungsansatz f r re aktive Systeme aufbauend auf Klassen und Zustandsdia grammen welche in Verbindung die vollst ndige Synthese des Programmcodes erlaubten Mit Rhapsody einem Soft wareprodukt der Firma i
5. Eine weitere Verfeinerung ist die Abgrenzung von Dom nenarten und Beziehungen zwischen Dom nen Vertikale Dom nen betreffen bestimmte Branchen z B Flugkontrollsysteme Telekommunikation etc Horizontale Dom nen betreffen Teilsysteme die sich ber mehrere vertikale Dom nen erstrecken Beispiele sind Datenbanksysteme oder Komponenten f r das Finanzwesen 5 Bei der Dom nenanalyse ist die Ausarbeitung der Gemeinsamkeiten und Unterschiede zwischen den Systemen eine notwendige Vorgangsweise und findet gr ere Bedeutung bei den Produktlinien Kapitel 4 Voraussetzung ist eine gewisse Stabilit t der Dom ne sodass das Modell ber l ngere Zeit g ltig und korrekt bleibt 7 8 F r die Korrektheit des Models kommen Verifikations Validierungs und Testmethoden zum Einsatz Der Vorgang der Validierung versucht das f r die Interessensvertreter richtige Dom nenmodell zu bestimmen bei dem alle notwendigen Entit ten deren Beziehungen und Zusammenh nge vorkommen Die Verifikation sorgt f r ein in sich korrektes und vollst ndiges Dom nenmodell 9 Beim Design der Architektur hat sich der Einsatz von Patterns bew hrt die die funktionalen und nicht funktionalen Anforderungen abbilden Besonderes Augenmerk muss dabei auf Adaptierbarkeit Erweiterbarkeit und Konfigurierbarkeit gelegt werden sodass bei einer Entwicklung einer konkreten Applikation die wieder verwendbaren Artefakte bestm glich eingesetzt werden k nne
6. was discussed Especially its interaction with the file system is very interesting Its capabilities are further enhanced with the possibility to connect programs through the use of pipes This is seen as one of the greatest inventions introduced in UNIX The toolbox of programs provided with UNIX together with the command language makes it suitable for a great component based development system at a very high abstraction level Even though UNIX was developed a long time ago it is still in use today and so are its relicts in form of paradigms and ideas It is important to understand where some of them came from and it is interesting enough to know that they are not that new References 1 Bach M J The Design of the Unix Operating System Prentice Hall Engelwood Cliffs N J 1986 45 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Kernighan B W and Mashey J R The Unix Programming Environment IEEE Computer 1981 pp 12 24 Ritchie D M and Thompson K The Unix Time sharing System Comm ACM 17 No 7 July 1974 pp 365 375 Ritchie D M The Evolution of the Unix Time sharing System AT amp T Bell Laboratories Technical Journal Volume 63 No 6 Part 2 October 1984 pp 1577 1593 Ritchie D M The UNIX Time sharing System A Retrospective Bell System Technical Journal Volume 57 No 6 Part 2 July August 1978 Freitag R J and Organick E I
7. 11 P Kruchten The Rational Unified Process An Introduction Addison Wesley 1999 12 I Jacobson G Booch J Rumbaugh The Unified Software Development Process Addison Wesley 1999 13 Rational Software The Rational Unified Process Best Practices for Software Development Teams Rational Software Corporation 1998 14 R Pressman Software Engineering A Practitioner s Approach 6th Edt Mcgraw Hill Higher Education New York 2005 15 C Bunse A von Knethen Vorgehensmodelle kompakt SpektrumVerlag Heidelberg 2002 16 R Martin Agile Software Development Priciples Patterns and Practices Pearson Education New Jersey 2003 17 K Beck Extreme Programming Das Manifest Addison Wesley M nchen 2003 18 C Dogs T Klimmer Agile Software Entwicklung kompakt mitp Verlag Bonn 2005 19 A Cockburn L Williams The costs and benefits of pair programming pages 223 243 Addison Wesley Longman Publishing Co Inc Boston MA USA 2001 20 A Lux Angewandte Prozessmodelle Javamagazin Vol 12 2002 pp 73 76 21 B Boehm Project termination doesn t equal project failure IEEE Computer September 2000 Softwareprozesse sind auch Software Aspekte einer Entwicklung Manfred J rgen Primus 0060243 mprimus edu uni klu ac at Abstract 1987 hat Leon Osterweil bei der ICSE den Artikel Software Processes are
8. 4 S Goss S Aron J L Deneubourg and J M Pasteels Self organized shortcuts in the Argentine ant Naturwissen schaften vol 76 1989 pp 579 581 5 G Castellano A M Fanelli C Mencar Generation of interpretable fuzzy granules by a double clustering technique Archives of Control Science Special Issue on Granular Computing University of Bari 2002 6 E Tron M Margliot Mathematical Modeling of Obser ved Natural Behavior A Fuzzy Logic Approach Fuzzy Sets and Systems vol 146 University Tel Aviv 2002 7 J M Rossiter T H Cao T P Martin J F Baldwin Ob ject Oriented modelling with words Fuzzy Systems The 10th IEEE International Conference on University of Bristol 2001 8 H Kiendl Fuzzy Control methodenorientiert Olden bourg Miinchen Wien 1997 ISBN 3 486 23554 0 9 L A Zadeh Knowledge Representation in Fuzzy Logic Transactions on Knowledge and Data Engeneering IEEE 1989 10 L A Zadeh Commonsense Knowledge Representation Based on Fuzzy Logic Computer vol 16 IEEE University of California October 1983 pp 61 65 11 G Castellano A M Fanelli C Mencar Discovering Human Understandable fuzzy diagnostic rules from medical Data Proc of the third European Symposium on Intelligent Technologies EUNITE 2003 University of Bari 2003 12 T Ozen J M Garibaldi Effect of Type 2 Fuzzy Mem bership Function Shape in Modelling Variation in Human Decision Makin Automat
9. Klassiker gibt es in nahezu jedem Teilgebiet der Informatik Um eine gewisse Vorstruktu rierung zu bieten sind die auf der Liste der TRACES Artikel genannten Beitr ge in die Gruppen e p_ Programming and Programming Languages e s_ Software Specification e tl Software Technology e hl Software Development Process hat etwas mit h umans zu tun e d_ Data Bases and Information Systems e k_ Knowledge Representation e o_ Operating Systems gegliedert Entsprechend Ihrem Interesse w hlen Sie sich aus einer dieser Gruppe in Thema manchmal ist dieses durch zwei zusammengeh rige Artikel gekennzeichnet durch gleiche Nummer mit Suffix a oder b definiert Sie k nnen sich beliebig viel Arbeiten ansehen bevor Sie eine w hlen Die getroffene Wahl teilen Sie den anderen Seminarteilnehmerinnen und Teilnehmern durch Posten einer entspre chenden Nachricht x lt Autor en gt lt Titel gt mit Durch Absenden dieser Nachricht haben Sie diesen Artikel f r sich reserviert und sich im Gegenzug verpflichtet zu diesem Artikel eine Ausarbeitung zu verfassen berlegen Sie sich also im Vorfeld welchen Artikel Sie w hlen wollen und pr fen Sie vor der eigenen Reservierung im Forum ob dieser Artikel noch frei ist Z gern Sie aber auch 7 nicht zu lange mit Ihrer Entscheidung Sie k nnen ab sofort w hlen Am 12 M rz 07 wird diese M glichkeit um 12 00 Mittag geschlossen sodass ab diesem Zeitpunkt die Themen vielf
10. SA SD dargestellt werden Eine klar defi nierte semantische Basis erm glicht die Generierung von vollst ndig lauff higen Code aus dem Modell 6 Die von David Harel und Eran Gery eingesetzten grafischen Notationen und ihre Aufgaben werden im Folgenden kurz vorgestellt e Klassendiagramme spezifizieren die Struktur des Sys tems in dem das System mittels Klassen ihren Be ziehungen untereinander und Rollen modelliert ist Sie werden verwendet um die Struktur die Statik des Systems zu modellieren e Zustandsdiagramme beschreiben das Systemverhalten zur Laufzeit Es wird die Dynamik das reaktive Ver halten festgelegt Ein Zustandsdiagramm verbunden einem Klassendiagramm spezifiziert alle Verhaltensa spekte von einem Objekt einer Klasse e Sequenzdiagramme auch unter dem Begriff Message Sequence Charts MSCs bekannt wurden als op tionaler Bestandteil gesehen und waren nicht Teil des Systems Die Autoren sahen damals MSCs als Mecha nismus zur Reflexion da diese gut geeignet sind um 3 Als dieser Artikel verfasst wurde war die Unified Modeling Language UML nicht sehr verbreitet aber schon damals hielten die Entwickler ihre Notationen konsistent mit denen von UML 26 Szenarien und Zusammenh nge zwischen Objekten zu beschreiben Die Semantik und Notation der Diagramme muss exakt spe zifiziert sein und darf keine Interpretationsm glichkeiten of fen lassen So kann eine effiziente und a
11. System out println data toString 0 data Im Vergleich zum vorherigen Code in AspectJ hier nun die Umsetzung in Weave NET Der Code beginnt wieder mit der Deklaration der Terminal Komponente public class Terminal extends TerminalConsole public void WriteLine String s Write s n Der nachste Codeabschnitt zeigt die Aspektdekla ration in XML im Unterschied zu AspectJ steht bei Weave NET kein Aspektverhalten in der Aspektdekla ration lt ax aspect gt lt name gt IOChecker lt name gt lt assembly gt Aspect_IOChecking lt assembly gt lt type gt Aspect IOChecking IOChecking lt type gt lt body gt lt item gt lt advice gt lt before gt lt formal_ param gt lt var_type gt object lt var_type gt lt var_name gt data lt var_name gt lt formal_param gt lt pointcut gt lt primitive gt lt pointcutId gt lt name gt Write lt name gt lt pointcutId gt lt primitive gt lt pointcut gt lt behaviour gt lt name gt LogWrite lt name gt lt behaviour gt lt before gt lt advice gt lt item gt lt item gt lt named_pointcut gt lt modifier gt lt public gt lt modifier gt lt name gt Write lt name gt lt local_var_ref gt lt var_type gt object lt var_type gt lt var_name gt data lt var_ name gt lt local_var_ref gt lt pointcut gt lt and gt lt pointcut gt lt primitive gt lt execution gt lt method_signature gt lt method_signature gt lt executio
12. 0 25 Yertl wenig offen R5 075 ANDO 75 0 75 Yen l viel offen 114 Als n chstes werden nach diesen Informationen die jeweiligen Bereiche in der Zugeh rigkeitsfunktion der linguistischen Variable Ventil ausgef llt wie in Abbildung 7 abgebildet zu wenig offen viel offen offen Ventil ZANE 10 20 30 40 50 60 70 80 90 100 46 Abbildung 7 Links Maximum Methode Beispielsweise wird der linguistische Wert zu bis zu Grad 0 25 aufgrund Regel R1 ausgef llt Dies wiederholt man mit allen Termen Um einen scharfen Wert zu erhalten wenden wir die Links Maximum Methode an und erhalten 46 als Befehlwert f r die Ventilstellung Gew hnlicherweise ist das Verhalten des Reglers nach der ersten Darstellung noch nicht ganz optimal Es sind kleine Verbesserungsma nahmen notwendig wie beispielsweise die erneute Spezifikation der Lage oder der Zugeh rigkeitsfunktion der Fuzzy Mengen eine neue feinere Partition des Wertebereichs oder eine neue Formulierung der Regeln Bei schlechter Wahl der Mess und Befehlwerte kann es jedoch auch sinnvoll sein einen g nzlichen Neuanfang zu starten 3 Geschichtlicher Hintergrund Auswirkungen der Kernidee 3 1 Fr her Anfang von Fuzzy Logik Als vor ber 2300 Jahren Aristoteles und seine Anh nger ihre Hypothesen ber Logik entwickelten kamen sie auf das so genannte Gesetz des ausgeschlossenen Dritten Dieses Gesetz besagt dass jede A
13. Komponentenbasierte Softwareentwicklung Bonifaz Kaufmann MatrNr 0361496 bkaufman edu uni klu ac at Abstract Immer wieder wird vom gro en Potential der kom ponentenbasierten Softwareentwicklung gesprochen Qualit tssteigerung und Kostenreduktion bilden die Triebfeder dieser Sehnsucht Doch um das Leistungs verm gen von Softwarekomponenten aussch pfen zu k nnen sind wohl berlegte Aktivit ten Vorausset zung Softwaresysteme zu konstruieren welche aus wiederverwendbaren vertrauensw rdigen Software komponenten bestehen erfordert hohe Startaufwen dungen Dieser Artikel zeigt auf wie die Wissenschaft ihren Teil dazu beitr gt vertrauensw rdige Kompo nenten m glich zu machen indem Dokumentation Qualit t und Zertifizierung zum Gegenstand der Kom ponentenforschung gemacht wurden Ebenso wird ein Einblick in die Notwendigkeit von Komponentenmodel len gegeben und ein eigens auf die Komposition von Softwarekomponenten zugeschnittener Softwareprozess vorgestellt 1 Einleitung Dass Softwaretechnologie kapitalintensiv ist scheint seit dem Artikel 31 von Peter Wegner aus dem Jahre 1984 kein Geheimnis mehr zu sein Wiederverwendba re Ressourcen sind das Kapital der Softwareentwickler und damit Investitionsg ter der Softwareproduktion Moderne Entwicklung st tzt sich auf eine Vielzahl unterschiedlichster Investitionsg ter Wegner bringt den Begriff der Kapitalintensit t ins Spiel a pro duction process i
14. schwert sein In solchen F llen sind vertragliche Schnittstellen und die M glichkeit beim Komponen tenhersteller bez glich technischer Details r ckfragen zu k nnen 22 das beste Gegenmittel Auslieferung und Wartung Die Auslieferung eines komponentenbasierten Systems unterscheidet sich nicht von der Auslieferung anderer Systeme Entscheidende Unterschiede gibt es im Wartungsprozess Idealerweise sind einfach alte durch neue Komponenten zu ersetzen Oder bei Funktionserweiterung zus tzliche Bauteile ins System zu integrieren Der Prozess daf r ist wie zuvor schon Suchen Finden Adaptieren Testen und Integ rieren Es soll nicht unerw hnt bleiben dass das Finden der richtigen Komponenten nach wie vor eine gro e He rausforderung darstellt Um dem gerecht zu werden sind ein reichhaltiger Komponentenmarkt 6 als auch unterst tzende Tools erforderlich 13 Das Lebenszyk lusmodell muss noch reifen und vertrauensw rdige zer 61 tifizierte Komponenten sind rar In der Literatur finden sich gescheiterte 17 wie auch erfolgreiche komponen tenbasiert entwickelte Projekte Sparling gibt uns in 26 Hinweise dazu welche Aspekte zur erfolgreichen Entwicklung komponentenbasierter Systeme beitragen 5 Zusammenfassung CBSE hat als Subdisziplin des Software Engi neerings in den letzten Jahren an Aufmerksamkeit ge wonnen Dennoch ist die Definition f r den Software komponentenbegriff zu vielschichtig und m sste pr zi si
15. terst tzung wohl kaum nachtr glich eingebaut werden Doch mit der Zeit wurde versucht mehr und mehr strukturierte Programme zu entwickeln Nachfolger bzw Erweiterungen erm glichten jedoch eine leichtere Umsetzung des Konzepts IFTRAN zum Beispiel wur de als Vorstufe zu FORTRAN eingesetzt um die Ver wendung m chtigerer Kontrollstrukturen zu erm gli chen 02 Neu entstandene Sprachen wie zum Beispiel PASCAL waren bereits so konzipiert dass die Pro grammierung von gut strukturiertem Code unterst tzt wurde PASCAL unterst tzte jedoch immer noch den goto Befehl an sich Dies erm glicht dem ambitionier ten Programmierer Strukturen die nicht direkt in der Sprache abgebildet sind selbst nachzuahmen Beispiele daf r w ren der Ausstieg aus der Ausf hrung einer Schleife oder die Nachbildung eines Konzepts f r ein Exception Handling Dies kann zwar f r die ganze ALGOL Familie gesagt werden aber auch PASCAL hat sich hier nach dem bestehenden Trend gerichtet Neben den verwendeten Programmiersprachen ha ben aber auch zus tzliche Werkzeuge welche f r diese Sprachen entwickelt wurden einiges zum Thema bei getragen Tools die heutzutage zur Entwicklung von Software eingesetzt werden wie etwa die Eclipse Plat form unterst tzen die Ausarbeitung gut strukturierter Programme immens Diverse Hilfsmittel helfen dabei den Code strukturiert aufzubauen und zu halten Ein Beispiel daf r ist die Automatische Quellcodeeinr
16. Anwendung mehrerer Zyklen erlaubt die inkrementelle Produktentwicklung wodurch mehrere Versionen der Software produziert werden k nnen 6 Risikoorientiert Durch die fr hzeitige Adressierung der Risiken versucht man die kritischen Aspekte des Projekts zu einem Zeitpunkt zu erfassen an dem noch gen gend Zeit f r den restlichen Projektverlauf brig ist Ziel ist es problematische Systemteile schnell zu realisieren um die Risiken zu minimieren Vor und Nachteile Aufgrund seines b rokratischen Charakters ist der RUP als ein schwergewichtiger Entwicklungsprozess bekannt Schwergewichtig in dem Sinn dass der Prozess eine strikte Einhaltung der Phasen und Kernworkflows fordert wodurch ein hoher Grad an Verwaltungs und Dokumentationsaufwand entsteht Genau genommen stellt der RUP aber ein umfassendes Framework f r einen Entwicklungs prozess dar der an die jeweiligen Bed rfnisse angepasst werden muss Laut Carsten Dogs und Timo Klimmer wird dem Prozessmodell dadurch eine geh rige Portion des Schwergewichtes genommen 18 Ein enormer Vorteil dieses Modells liegt im berblick und in der Koordinationsm glichkeit f r die Projektleitung Bei kleinen Entwicklerteams ist der RUP eher nicht zu empfehlen weil die geforderte Rollenverteilung nicht gestaltet werden kann An die Entwicklungs organisation bestehen f r den Einsatz vom RUP mehrere Vorraussetzungen Dies sind nach Ludewig und Lichter in 6 Ausgezeichnete Konfiguration
17. Entweder sind die Funktionen des Programms leicht zu implementieren oder aber gar nicht 4 APPL A Prototyp einer Softwareprozess Programmiersprache Trotz der wohl auch begr ndeten Gegenmeinungen gab es Bem hungen und Forschungen um die Idee Osterweils umsetzen zu k nnen APPL A ist eine Programmiersprache um Softwareentwicklungs programme beschreiben und schreiben zu k nnen und basiert auf der Programmiersprache ADA APPL A wurde als logische Folge der Arbeit von Leon Osterweil aus dem Jahre 1987 auf Grund der Forderung nach einer Programmiersprache zum Schreiben von Programmen als Unterst tzung im Softwareentwicklungsprozess entwickelt wobei Leon Osterweil federf hrend beteiligt war Das Ziel der Entwickler von APPL A war einen Prototyp f r eine Programmiersprache zum Schreiben von Programmen f r Softwareentwicklungsprozesse zu schaffen Als Ziele setzten sie sich Sutton 95 e Ausf hrbarkeit um den Prozess automatisiert ablaufen lassen zu k nnen e M glichkeit zur Kontrolle und zur Definition von Datentypen damit Prozessaktivit ten und produkte dargestellt werden k nnen zum Programmieren von prozessunabh ngigen Details e Abstraktion Kapselung und Modularit t e Darstellung von Abh ngigkeiten um Abh ngigkeiten zwischen den einzelnen Prozessschritten und Akteuren aufzuzeigen e Datenspeicherung und austausch e Programmierbarkeit von Anwendungen zur Kontrolle und Datenabstraktion insbes
18. Keywords domain analysis domain engineering reuse product line engineering domain specific modeling 1 Einf hrung Die Entwicklung von Software Systemen wird durch stetig steigende Anforderungen in unterschiedlichen Branchen komplexer und kostenintensiver Viele Probleme erscheinen bei verschiedenen Systemen in hnlicher Form Mit Hilfe von Wiederverwendung von Software Artefakten versucht man die Probleme schneller und einfacher zu l sen um effizienter Systeme zu entwickeln Schon 1968 hatte McIlroy 2 die Idee Systeme mittels industriell vorgefertigten Software Komponenten zu implementieren Das Wachsen der Komponentenbibliothek f hrte jedoch zu Schwierigkeiten passende Komponenten zu finden Ein zus tzliches Problem war die hohe Anzahl an 103 hnlichen Komponenten die f r spezifische Anforderungen angepasst und wieder der Bibliothek zug nglich gemacht wurden 3 Arango der Verfasser des Basisartikels 1 glaubt wie auch Neighbor 4 dass der Schl ssel f r eine erfolgreiche Wiederverwendung in der Wieder verwendung von Analyse und Design liegt nicht alleine in Code Um effektive Wiederverwendung von Analyse und Design zu erm glichen muss dies in eingeschr nkten Klassen von Systemen in Dom nen passieren Gliederung In Kapitel 2 wird der Basisartikel genauer betrachtet und die Ideen von Domain Analysis und Engineering von 1989 pr sentiert Kapitel 3 beleuchtet die Weiterentwicklung und Verf
19. Meyer B On To Components IEEE Computer 32 1 Jan 1999 pp 139 143 20 Meyer B The Grand Challenge of Trusted Compo nents The IEEE Proc of 25th International Conference on Software Engineering ICSE USA 2003 pp 660 667 21 Mili H Mili F Mili A Reusing Software Issues and Research Directions JEEE Trans Softw Eng 21 6 Jun 1995 pp 528 562 22 Morisio M et al Investigating and Improving a COTS Based Software Development Process ICSE 2000 Limme rick Ireland 23 Sametinger J Software Engineering with Reusable Components Springer Verlag Berlin 1997 24 Sarakatsanis A Dinner for ONE Java Magazin Soft ware amp Support Verlag Frankfurt 11 2001 pp 60 65 25 Schneider J G Han J Components the Past the Present and the Future Proc of 9th Int Workshop on Com ponent Oriented Programming Oslo Jun 2004 pp 08 26 Sparling M Lessons Learned Through Six Years of Component Based Development Communications of the ACM 43 10 Oct 2000 pp 47 53 27 Stark T Java EE 5 Pearson Studium Miinchen 2007 28 Szyperski C Component Software Beyond Object Oriented Programming Addison Wesley Essex 1998 29 Taulavuori A Niemel E Kallio P Component do cumentation a key issue in software product lines Inf Softw Technol 46 8 2004 pp 535 546 30 Wang N Schmidt C D ORyan C in Councill W T Heineman G T Component Ba
20. Principles Methodologies and Practices Intellect 1995 13 H Yao and L Etzkorn Towards a semantic based approach for software reusable component classification and retrieval In Proceedings of the 42nd annual Southeast regional conference SESSION Software engineering Nr 1 pages 110 115 2004 Software Entwicklungsprozesse Markus Schneider 0460242 m2schnei edu uni klu ac at Abstract Kostenminimierung Qualit tssoftware und maxi maler Nutzen sind die Hauptziele der Softwareentwick lung Um diese Ziele zu erreichen bedarf es methodi scher Vorgehensweisen im Entwicklungsprozess Die Schl sselkomponente daf r sind Prozessmodelle Mit dem Wasserfallmodell begann die ra strukturierter Entwicklungsprozesse Bis heute haben sich zahlreiche Vorgehensmodelle entwickelt und etabliert Der auf dem Wasserfallmodell basierende Ansatz findet sich in den meisten Prozessmodellen wieder Ausgehend von Boehms Artikel Software Enginee ring beschreibt das vorliegende Paper die bekanntesten Entwicklungsans tze und gibt einen Einblick in klassische Prozessmodelle N her wird im Artikel auf den schwergewichtigen Rational Unified Process und die agile Methodik eXtreme Programming eingegangen 1 Einleitung Mitte der sechziger Jahre steigerte sich die Leistung von Hardware enorm Software die im Stande war die Ressourcen auszunutzen wurde ben tigt Fehlendes Wissen ber Methoden mangelndes Fachpersonal und fehlerhafter
21. St rrle Wirsing LMU M nchen 2004 15 Wolfgang Hesse Ontologie n Informatik Spektrum Springer Berlin Heidelberg pp 477 480 2002 16 Dean Allemang Ontologies Reuse and Domain Ana lysis http www domainmodeling com Papers domainmod eling_ontologies pdf zugegriffen am 10 Juli 2007 17 Neil Iscoe Gerald B Williams Guillermo Arango Domain Modeling for Software Engineering Proceedings of the 13 international conference on Software Engineering IEEE Computer Society Press Los Alamitos pp 340 343 1991 Domain Engineering and Reuse Ronny Haindl 9560276 rhaindl edu uni klu ac at Abstract Domain Analysis als Teil des Domain Engineering ist seit Einf hrung der Ideen von Neighbor um 1980 ein aussichtsreiche Methode f r die Wiederverwendung von Software Artefakten Ziel ist die Steigerung der Produktivit t und Qualit t bei der Entwicklung von Software Systemen Dieser Artikel besch ftigt sich als Basis mit einem Artikel aus dem Jahre 1989 ber einen systematischen Ansatz f r Domain Analysis und Wiederverwendung von Software und untersucht die heutige Relevanz der damaligen Ideen und Konzepte Dabei werden zwei Schwerpunkte gesetzt Die Weiterentwicklung von Domain Engineering mit dem Fokus auf konkrete Produkte Product Line Engineering und zum Zweiten dom nenspezifische Modellierung als Weiter entwicklung von komponentenorientierter Wieder verwendung
22. Weiters bestehen die zwei Klassen beschreibungen aus einer Reihe von gruppierten Ei genschaftskategorien von denen jede einzelne einer Aktivit t Entit t oder Behauptung entspricht Die Eigenschaftskategorie parts umfasst beispielsweise in der Aktivit tsklasse wiederum drei Aktivit ten Eine Aktivit tsklasse enth lt zus tzlich noch Pre und Postconditions die nach bzw vor dem Ausl sen der Aktivit t zutreffen m ssen Das eigentlich Neue im Vergleich zu anderen hnli chen Frameworks und Anforderungsmodellierungs sprachen war die Hinzunahme der Behauptungen in das Modell siehe Abb 3 Auch auf sie werden die Abstraktionsmechanismen angewandt Dadurch k n nen informale Zus tze aus anderen Modellen formal in das Modell eingebracht werden Verwendet werden sie als Pre und Postconditions in Aktivit ten bzw als Invarianten in Entit tsklassen AssertionClass IsTreatedilith with arguments p Patient t Treatment parts cl Availableltre gt t at lt gt p location c2 Recommendedl end IsTreatedWith Abb 3 Behauptung in RML 5 Zusammenfassend gesagt ist RML eine formale An forderungsmodellierungssprache die Techniken aus den Bereichen K nstliche Intelligenz Knowledge Engineering und Datenbanken Datenmodellierung konzeptuelle Modelle Aggregation Generalisation n tzt um einerseits eine Wissensbasis zu erstellen und andererseits als objekt orientiertes Informationsmodell im Zuge der Softwareentwi
23. and Visual FoxPro Further down I am going to analyze two widely used open source programs in terms of their utilization of goto s The last chapter will describe a few software engineering aspects and suggestions of how goto statements and similar unconditional branching constructs might be used productively 2 What goto s were In former times goto s were a common tool for programming code and were an important part of the solution of many algorithmic problems But with the onset of increasingly powerful computers new and more powerful algorithms were devised With more power came more complexity 14 leading to more advanced programming languages and to more complex source code as well Foreseeing several problems with the program structure if goto s are used wrongly Dijkstra 1 made a comment leading to a grim discussion about the usability of goto s in common 2 1 Dijkstra s perspective Dijkstra pointed out the negative effects of goto statements that can easily disrupt the structure of a program and therefore opted for the abolishment of goto s from higher level programming languages It has to be said that this argument was issued in a time where it was most common to use goto s in many programing languages e g COBOL ALGOL C To begin with Dijkstra outlined two facts Firstly the programmer is only capable of defining a program that is then executed dynamically The dynamic process has to conform with the pr
24. auch als Motivationshilfen an jenen Stellen dienen an denen man in anderen Lehrveranstaltungen kurz auf die Wurzeln aktueller Entwicklungen eingeht Da das Bakkalaureatsseminar keine spezifische fachliche Umschreibung hat bot es die Chance obige Fragestellung experimentell zu behandeln Dazu wur den noch in den Semesterferien die in Tabelle 1 ange f hrten Arbeiten in die eLearning Plattform MOODLE gestellt damit sich Studierende rechtzeitig eine Arbeit und damit ein Themengebiet w hlen das ihren Inter essen entspricht Um entsprechende Freiheitsgrade zu sichern wurden in diese Sammlung etwa doppelt so viel Arbeiten aufgenommen als Teilnehmer in der Lehrveranstaltung erwartet wurden Die Auswahl selbst hat einen Bias in Richtung Pro grammierung und Software Engineering Dies ent spricht dem Fachgebiet des Seminarleiters Doch da das Bakkalaureatsseminar als Seminar aus Angewand te Informatik ausgeschrieben ist wurden auch Arbei ten aus den Bereichen Datenbanken Knowledge Engi neering und Betriebssysteme aufgenommen Neben fachlichen Argumenten spielte auch Verf gbarkeit und Lesbarkeit eine Rolle Daraus ergab sich dass ein weiterer Bias in Richtung auf Arbeiten die auf acm oder IEEE Servern elektronisch verf gbar sind und f r die via Universit tsbibliothek Lehrenden wie Studier enden der Zugang frei m glich ist bevorzugt wurden Bedauerlicherweise schieden nach diesen Kriterien einige Arbeiten aus die ich sonst seh
25. idea to split up monolithic programs into smaller generally usable parts and reuse them in the development of other software By reusing these software components not only the productivity can be enhanced but also the quality 15 It is interesting to note that Doug McIlroy who worked at the AT amp T Bell Labs at the time Multics the UNIX predecessor and UNIX itself were developed was one of the great advocates of component based 42 development and based a lot of the problems of the current slow and unreliable software development on the fact that not enough or no component based development was used 14 At the same time McIlroy was somehow the inventor of the UNIX pipe functionality as will be explained in chapter 3 2 1 Is the development with UNIX based tools and the use of pipes as it is described by Kernighan and Mashey 2 component based development or is it just a predecessor to this idea are questions discussed in this chapter 3 1 1 Defining a software component Defining what a software component is is quite difficult There are many different perceptions on the subject depending on the field of work and education one is coming from Szyperski offers a definition that captures the subject quite well and gets a lot of citations too A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only A software component can be deployed independently and is su
26. interpretiert also das Ergebnis und f gt somit eine be stimmte Unsch rfe hinzu mit der Konsequenz dass man dadurch ein besseres Verst ndnis der Berechnung aufgrund der realit tsnahen Sichtweise der L sung schafft 119 Das Gleiche gilt bei dem Einsatz von W rtern bei Computing with Words Computing with Words ver bindet nat rlichsprachliche W rter und Fuzzy Variablen Genau diese Verbindung macht Computing with Words zu einer eigenen Methode welche unter genau den beiden oben genannten Gesichtspunkten eingesetzt wird e Die zur Verf gung stehende Information bein haltet keine pr zise und konkrete Darstellung also kann sie nicht direkt als Wert angesehen werden e Es ist eine Unsch rfe bei der Berechnung er laubt welche jedoch die Vorteile von besserer N he zur Realit t Nachvollziehbarkeit Ro bustheit und geringerer Kosten mit sich bringt Oft kann nicht mit wirklichen Zahlen gerechnet werden Es gibt einfach keinen Messwert f r eine Ein gabe die ein System mit normaler Logik verarbeiten kann So kann man bei einer Waschmaschine nicht den Verschmutzungsgrad in Prozent angeben Dieser wird jedoch ben tigt um eine optimale Waschmittelmenge in den Waschmittelkorb zu geben Daher greift das System auf eine unscharfe Menge zur ck wie wir sp ter noch sehen werden Um dem Leser das Ganze n her zu bringen wird schlie lich ein Tool vorgestellt welches zur Simulation von Fuzzy Logik eingesetzt wird Dies
27. sen sollte Er selbst hat jedoch nie genau eingeschr nkt was der Begriff genau bedeutet oder gar eine klare Definition abgegeben Dijkstra meint strukturierte Programmierung sei als Konzept zu sehen das den Programmierer dabei unterst tzt mit jeglicher Komplexit t bei der Entwicklung von Pro grammen umzugehen 09 D Bates hat dieses Konzept treffend in Worte ge fasst What was originally meant by the term structured programming was the philosophy of structuring pro grams in such a way as to make them more intellectu ally manageable and more amenable to a convincing proof of correctness 12 1 2 Motivation Um diese Entwicklung nachvollziehen zu k nnen muss man zuerst verstehen mit welchen Problemen damalige Entwickler zu k mpfen hatten N Wirth hat 1974 einen der wichtigsten Punkte treffend zusammen gefasst A systematic orderly and transparent approach is mandatory in any sizable project nowadays not only to make it work properly but also to keep the program ming cost within reasonable bounds 01 Die Kosten fiir Software waren zu jener Zeit um ei niges geringer als diejenigen f r die dazugeh rige Hardware Deshalb versuchte man auch die kostspieli ge Rechenzeit optimal auszunutzen Jedes Programm und jeder Algorithmus wurden bis ins kleinste Detail beleuchtet und optimiert Dadurch entwickelten sich mit der Zeit clevere Tricks welche f r andere oft kaum durchschaubare Code Konstrukte z
28. sodass wir als 126 Resultat f r die Bremskraft mittel 0 25 und 0 5 erhal ten Aufgrund des Max Operators muss hier 0 5 ge w hlt werden Die Endwerte f r die Bremswirkung lauten somit schwach 0 25 mittel 0 5 und stark 0 5 Mit diesem Ergebnis kann jedoch noch kein Bremssystem arbeiten Aufgrund dessen muss dies wieder in einen realen Wert umgewandelt werden Dies wird bei uns mittels CoA durchgef hrt Wenn man den Schwerpunkt des Diagramms auswertet so kommt man ungef hr auf 5 5 m s siehe Anhang Abb 12 Eine Simulationssoftware mit dem Namen Suco SOFT fuzzyTECH kann von der Adresse www moeller net de bezogen werden Abb 13 14 und 15 5 Fazit amp Ausblick In diesem Paper wurde zuerst auf die grundlegenden Dinge von Fuzzy Logik eingegangen Diese mussten da Computing with Words ein Einsatzgebiet von Fuz zy Logik ist n her erl utert werden Hierbei wurde auch erkl rt warum seit Beginn von Fuzzy Logik de ren Wichtigkeit immer weiter steigt Anschlie end konnte auf Grunds tzliches bei Computing with Words n her eingegangen werden Sp ter wurden einige An wendungen n her gebracht Dies begann mit dem di rekten Einsatz von Computing with Words f r das bes sere Verst ndnis von Ameisen Weiters konnte eine neue Sichtweise auf objektorientiertes Modellieren gezeigt werden Durch den Einsatz von Fuzzy Logik in diesem Bereich kommt es zu neuen M glichkeiten welche es mit Java in dieser Form nicht gi
29. sowie die moderne Entwicklung mit Wiederverwendung Kapitel 2 beschreibt diese Ans tze und gibt einen Auszug klassischer Prozessmodelle Kapitel 3 und 4 erl utern den schwergewichtigen Rational Unified Process und die leichtgewichtige Methodik eXtreme Programming als Vertreter moderner Prozessmodelle 2 Allgemeine Prozessmodelle Bei einem Prozess handelt es sich um einen Rahmen der Aktivit ten Methoden und Verfahren f r die Herstellung und berpr fung von Softwareproduk ten beschreibt 2 Prozessaktivit ten k nnen sich laut TEEE Standard 610 12 1990 berlappen und sie k nnen mehrmals wiederholt werden Angelehnt an die Beschreibung des Wasserfallmodels gibt es vier grundlegende Prozessaktivit ten die sich in den g ngigen Prozessmodellen wieder finden Dies sind Spezifikation Design Implementierung und Test Prozessmodelle sorgen f r Transparenz und Steuerbarkeit im Entwicklungsprozess Sie legen Standards und Richtlinien fest definieren Verantwort lichkeiten und Kompetenzen legen die Reihenfolge von Arbeitsschritten fest und koordinieren Prozessak tivit ten und Ergebnisse Pankaj Jalote definiert ein Prozessmodell wie folgt A development process model specifies some activities that according to the model should be performed and the order in which they should be performed 4 2 1 Entwicklungsans tze Phasenorientierte Entwicklung Lineare Prozesse Die phasenorientierte Herangehensweise teilt di
30. ten orientierte Klassifikations Schema das von Prieto Diaz und Freeman in 11 hergeleitet wurde n her beleuchtet Nun werden Ans tze und moderne Technologien die auf der Arbeit von Prieto Diaz und Freeman aufbauen diskutiert und zu dieser in Relation gesetzt 5 1 Objekt orientierte Klassifizierung In der heutigen Zeit der Softwareentwicklung ist ein objekt orientierter Software Entwicklungsprozess nicht mehr weg zudenken Aus diesem Grund befassen sich Karlsson et al in 4 ausf hrlich mit dem Thema des objekt orientierten Software Reuse In diesem Kapitel werden nun die Unterschiede der Wieder verwendung und der Klassifizierung im Vergleich zur Arbeit von Prieto Diaz und Freeman in 11 diskutiert Wird bei der L sung von Prieto Diaz und Freeman von tra ditioneller Programmierung d h von Prozeduren Funk tionen und Bl cken von Source Code ausgegangen steht bei der Weiterentwicklung von Karlsson et al in 4 die Beschrei bung eines Objekts die Klasse im Mittelpunkt 4 Daher wird bei der objekt orientierten Wiederverwendung von Software Komponenten ein konkreter Vorteil genutzt die Vererbung Eine Subklasse erbt die Funktionalit t ihrer Reuse Superklasse Dabei entstehen folgende M glichkeiten der Wiederverwendung 4 e Reuse einer bestehenden Klasse ohne neue Funktio nalit t in einer Subklasse zu implementieren Dies ist nat rlich die komfortabelste jedoch auch unwahrschein lichste Varia
31. 16th international conference on Software engineering IEEE Computer Society Press pp 135 147 1994 6 Colette Rolland Naveen Prakash From Conceptual Modeling to Requirements Engineering Annals of Software Engineering CREWS Report Series 1999 7 Axel van Lamswerde Requirements Engineering in the Year 00 A Research Perspective ICSE 2000 ACM pp 5 19 2000 8 Eric S K Yu Towards Modeling and Reasoning Sup port for Early Phase Requirements Engineering Proceedings of the Third IEEE International Symposium IEEE pp 226 235 1997 9 John Mylopoulus Lawrence Chung Stephen Liao Hauiquing Wang Eric Yu Exploring Alternatives during Requirements Engineering IEEE Software IEEE pp 92 96 2001 10 John Mylopoulus Lawrence Chung Eric Yu From Object Oriented to Goal Oriented Requirements Analysis Communications of the ACM ACM Press pp 31 37 1999 102 11 J Paul Gibson Formal Requirements Models Simula tion Validation Verification Technical Report NUIM CS 2001 TR 02 2001 12 Eric Yu Why Goal Oriented Requirements Engineer ing Proc 3 Int Workshop on Requirements Engineering Foundations of Software Quality REFSQ 97 pp 171 183 1997 13 Alex van Lamsweerde Goal Oriented Requirements Engineering A Guided Tour 14 Martin Wirsing Anforderungsmodellierung Zielorien tierte Methoden Methoden des Software Engineering Koch
32. 1997 D Lafferty and V Cahill Language independent aspect oriented programming In OOPSLA 03 Proceedings of the 18th annual ACM SIGPLAN conference on Object oriented programing systems languages and applicati ons pages 1 12 New York NY USA 2003 ACM Press G C Murphy R J Walker E L A Baniassad M P Robillard A Lai and M A Kersten Does aspect oriented programming work Commun ACM 44 10 75 77 2001 D L Parnas On the criteria to be used in decompo sing systems into modules Commun ACM 15 12 1053 1058 1972 M V sgen and D Sokenou Aspektorientierte Program miertechniken im Unit Testen Informatik Forschung und Entwicklung 20 1 57 71 2005 3 4 5 6 7 8 9 The UNIX Programming Environment Where it Started and Where it Went Ofner Michael 9969295 crashproof gmx at Abstract In their 1981 paper The Unix Programming Environment 2 Kernighan and Mashey describe the peculiarities of the operating system UNIX and its influence as a programming environment at their current time Based on this paper I am going to survey how the aspects they describe as being especially well done or good for productivity still hold up in today s world Furthermore I am going to investigate if and how the paradigms that were introduced e g components pipes and filter evolved over time and how they compare to today s ideas 1 Introduction Computer s
33. 3 wird der gesamte Vorgang nochmals f r ein einfaches Simulationssystem aufgezeigt 3 1 Datengewinnung Granulation Nun gilt es das Problem zu l sen dass eine gro e Datenflut mit konkreten Werten in Fuzzy Sets automa tisch mittels Algorithmus umgewandelt wird Diese Anforderungen stammen dabei aus der Natur welche eine hohe Anzahl an Werten zur Verarbeitung liefert Es m ssen passende Mengen gebildet werden um das System wahrheitsgetreu abbilden zu k nnen Daher ist es eine wichtige Aufgabe einen effizienten Algorith mus zu finden welcher aus einer gro en Datenmenge die wesentlichen Informationen extrahiert welche dann wiederum das IDS f r unser Fuzzy System darstellen 5 Dabei muss auch darauf geachtet werden dass die semantik Gap zwischen der Information in der Daten bank und jener die der Benutzer versteht geschlossen wird Wenn es keinen Unterschied bez glich der Auf fassung der Fuzzy Bedingungen gibt so sind jene Re geln mit denen das System arbeitet semantisch ident zu denen was der Mensch implizit denkt Diese Granulation erfolgt im Wesentlichen in zwei Schritten 1 Zuerst wird der n Dimensionale Raum in n Dimensionale Cluster geteilt Anschlie end wird jeder Raum auf alle Achsen projiziert um einen Zust ndigkeitsbereich zur jeweiligen Va riable zu erhalten 123 2 Die so entstandenen Bereiche k nnen nochmals geclustert werden um eine eindimensionale gra nulare Menge zu erhalten Zulet
34. Anwendungs f lle nahezu vollst ndig zu erfassen eine fundierte Systemarchtiketur zu entwerfen sowie ein Verst ndnis f r den Problembereich zu entwickeln Die Ergebnisar tefakte in dieser Phase sind ein ausf hrbarer Architekturprototyp und eine Architekturbeschreibung ein zu ca 80 fertiges Anwendungsfallmodell die Ausformulierung der nichtfunktionalen Anford erungen sowie eine aktualisierte Version des Projektplans und der Risikenliste Am Ende dieser Phase ist der Lifecycle Architecture Meilenstein erreicht und bereit evaluiert zu werden vgl 13 Entwurf und Implementierung sind der Fokus der Konstruktionsphase Am Ende dieser Phase sollte ein fertiges Beta Release erstellt sein welches f hig f r die Weitergabe an den Kunden ist Weitere Artefakte sind ein Benutzerhandbuch die Systemdokumentation und eventuelle Schulungsunterlagen Mit Beendigung der Konstruktionsphase ist der Initial Operational Capability Meilenstein erreicht vgl 13 Die letzte Phase des Entwicklungszyklus ist die Auslieferungsphase In ihr wird eine Installationsrouti ne erstellt und das fertige System an den Kunden bergeben Dort wird es in seiner Zielumgebung installiert und vom Kunden auf Akzeptanz getestet Sollten im Akzeptanztest kleine M ngel festgestellt werden wird das Produkt nachgebessert Falls es gefordert wird werden die Benutzer beim Kunden auf das System eingeschult und die vollst ndigen Dokumente bergeben Mit dem Erre
35. Anwendungsprojekt erstellt 2 Im Sommersemester 2007 fanden zwei parallel ge haltene Bakkalaureatsseminare statt Die hier wieder gegebenen Arbeiten hatten das Ziel klassische Auf s tze aufzuarbeiten und den Bezug der inzwischen als historisch einzustufenden Ideen zu aktuellen Themen der Informatik speziell des Software Engineering her zustellen D 14 der 15 Arbeiten sind Bakkalaureatsarbeiten Eine Are goto s don t do s ist die normale Seminararbeit eines MA Studenten Eine Studierende musste aus externen Gr nden knapp vor Ende der Veranstaltung abbrechen und hat keine verbesserte Fassung abgegeben Diese Arbeit fehlt mithin im Sammelband Wie diese Verbindung zwischen einer klassischen Referenz und aktuellen Themen der Informatik her gestellt wird lag v llig in den H nden der Studie renden Leser k nnen sich berzeugen dass diese sehr unterschiedliche Wege w hlten Allerdings m chte ich bei aller Varianz der Qualit t der nachfolgenden Ar beiten doch festhalten dass die meisten Studierenden sich der Aufgabe durchaus sehr gut entledigt haben und sich redlich M he gaben wirklich gute Arbeiten abzugeben Dass Einzelne auch einen flacheren Weg als ausreichend steil betrachteten und andere die Stu fen des Verfahrens vorerst als nicht hinreichend ernst zu nehmende H rden aufgefasst haben m gen liegt in der Natur von Lehrveranstaltungen Die zugeh rigen Arbeiten zeigen noch deutliches Verbesserungs
36. At Current software Engineering Studies ausge Thema Titel arbeitet Programming and Programming Languages Flow Diagrams Turing Machines and Languages 1 C B hm G Jacopini with Only Two Fromation Rules Comm ACM Vol 9 5 May 1966 pp 366 377 ij E 2a E Dijkstra Go To Statement Considered Harmful Letter to the Editor Comm ACM Vol 11 3 March 1968 pp 147 148 i in R T Yeh ed Current Trends in Programming Methdolology Oox d On the Composition of Well Structured Programs acm Computing Surveys Vol 6 4 Dec 1974 pp 247 259 Program Development by Stepwise Refinement Comm ACM April 1971 Vol 14 4 pp 221 227 M Shaw W A Wulf Abstraction and Verification in Alphard Defining psa Ritowon o ana Spacing toto ara Gereaore S comm aom varen w Aug rrr p 860 86 O B Liskov A Snyder pao R anson Sonaten avsvacton vecharismsmnoru eomm aom vo zoe aug tren sees d Oo S p6a_ D L Parnas On the Criteria to Be Used in Decompsing Systems into Modules Comm ACM Vol 15 12 Dec 1972 pp 1053 1058 p6b D L Parnas A Technique for Software Module Specification with Examples Comm ACM Vol 15 5 May 1972 pp 330 336 EEE OEO Can Programming Be Liberated from the von Neumann Style p7 J Backus A Functional Style and Ist Algebra of Programs Comm ACM Vol 21 8 pp 613 641 Specification C A R Hoare Communicating Sequential Processes Comm ACM Vol 21 8 August 1978 pp 666 677 aS Ss i
37. Call Join Point an dem die Methode incrXY auf dem Objekt pt1 aufgerufen wird 8 Ein Method Call Join Point an dem die Methode getX auf dem Objekt pt1 aufgerufen wird 11 Ein Field Get Join Point an dem das Feld _x des Punktes pt1 gelesen wird Die Kontrolle kehrt ber die Join Points 11 10 9 und 8 zur ck 12 Ein Method Call Join Point an dem die Metho de setX auf p1 aufgerufen wird und so wei ter bis die Kontrolle schlie lich ber 3 2 and 1 zur ckkehrt 4 Originaltext in Englischer Spra che 2 3 Pointcut Designators Pointcuts sind eine Zusammenfassung mehrerer Join Points Pointcut Designators sind Bezeichner die ser Join Points sie identifizieren Join Points AspectJ enth lt bereits vordefinierte Pointcut Designatiors instanceof istein primitiver Pointcut Designa tor instanceof FigureElement identifiziert beispielsweise alle Join Points an denen das aktuell be handelte Objekt vom Typ FigureElement bzw eine Unterklasse von FigureElement ist Pointcut De signators k nnen mit den logischen Operatoren and or not amp amp kombiniert werden instanceof FigureElement amp amp calls void FigureElement incrXY int int Dieser Codeabschnitt identifiziert al le Join Points an denen die Methode FiqureElement incrXY int int auf gerufen wird und der Aufrufer selbst nicht vom Typ Figureelement ist Weiters k nnen benutzerdefinierte Pointcut Desi gnators ers
38. Code in das System e System teste den Code 87 e Wenn der Code zufriedenstellend ist abstrahiere das Design vom Code und schreibe es in die Form einer Designspezifikation e Wiederhole bis alle Anforderungen erf llt sind oder solange es der Zeitplan zul sst e Schreibe die Dokumentation von den erf llten Anforderungen e Installiere das System beim Kunden e F hre Fehlerbehebungen durch die durch den Kunden aufgezeigt werden w hrend die Entwickler an der n chsten Version arbeiten Aus seiner Verzweiflung heraus f hrte Fagan erstmalig Methoden aus der Hardwareerzeugung ein in der die Entwicklung von neuer Hardware st ndig im Analyse Design und Verlaufsprozess von neuem berpr ft werden musste Dies senkte die Fehlerrate und teure Korrekturen in der Endfertigung Seine Ergebnisse ver ffentlichte er 1976 in seinem Paper 1 welches auch das Ausgansmaterial f r diese Arbeit darstellt F r die Entwicklung der Fagan Inspection und deren weltweiten Einsatz wurde Fagan von IBM mit der h chsten Auszeichnung dem Individual Corporate Achievement Award geehrt Nach zwanzig Jahren T tigkeit bei IBM gr ndete er 1989 die Firma Michael Fagan Associates und ist seither Berater in Qualit tssicherheit und seines patentierten Fagan Defect Free Process 7 2 Fagan Inspektionen Boehm stellte die ungef hre Aufteilung der Fehlerverteilung innerhalb des Life Cycle dar 13 Abbildung 1 zeigt dass b
39. ContextMenu 9 CrystalReportViewer 5 DataGrid a DateTimePicker F DomainUpDown Abbildung 6 Durch Drag amp Drop eingesetzter DateTimePicker ohne zus tzliche Programmierung Samstag 07 Juli 2007 Jui 20077 gt i Mi Do Fr Sa So 1 23456 93 10 11 12 13 14 15 16 17 18 19 20 21 22 25 26 27 28 29 gt Heute 07 07 2007 Dadurch wird ein wesentliches Problem n mlich das Auffinden beziehungsweise die Verwendung der richtigen Komponente f r die richtige Sprache gel st 4 Zusammenfassung Die Entwicklung von Fagan war ein Meilenstein in der Softwareentwicklung Durch die Einf hrung von Inspektionen konnte einerseits die Qualit t der Software erh ht andererseits auch die Kosten f r Produktentwicklung und wartung verringert werden Moderne Werkzeuge wie sie unter Punkt 3 beschrieben werden erleichtern die Bearbeitung und Analyse von Code und senken die Fehlerrate betr chtlich Sie vermindern zwar die Anzahl der Initialfehler K nnen aber nicht alle entdecken die ein ge btes Inspektionsteam zu finden vermag Daher sind diese Werkzeuge auf keinen Fall ein Ersatz f r Code Inspektionen Sie sollten dennoch als vorbeugendes Instrument eingesetzt werden 5 Referenzen 1 M E Fagan Design and code inspections to reduce errors in program development IBM Systems J Vol 15 No 3 1976 pp 182 211 2 Tom Gilb und Dorothy Graham Software Inspection Addison Wesley 1993 3 David A Wh
40. Die Meinung von M Lehman will ich im dritten Kapitel aufzeigen Nachdem sich mir die Frage aufdr ngte ob es nun eine von Osterweil geforderte Softwareprozess Programmiersprache gibt die heute in Verwendung ist oder eine andere Verwirklichung seiner Idee machte ich mich auf die Suche nach Prototypen oder heutef r die Softwareprozess Programmierung verwendeten Programmiersprache Mit APPL A fand ich eine auf Ada basierende Programmiersprache f r den Softwareentwicklungs prozess Kontrastierend dazu m chte ich im Kapitel f nf Little JIL vorstellen eine grafische Programmier sprache bei der man sich vorstellen k nnte dass sie in Verwendung ist wobei man aber keinen Hinweis daf r findet Sie ist aber immer noch in Entwicklung Wohl in Verwendung ist der Rational Unified Process Die Kernideen und den Prozess selbst m chte ich im sechsten Kapitel darstellen 2 Software Processes are Software too zweiter R ckblick Im 1987 erschienenen Paper erkl rt Leon Osterweil den Begriff Prozess und Prozessbeschreibung Er verwendet hierzu ein Beispiel aus der realen Welt das Kochen nach einem Kochrezept Osterweil 87 Wenn man nach einem Rezept kocht ist das Kochen der Prozess und das Kochrezept die Prozessbeschreibung Wobei zu beachten ist dass das Rezept eine starre Beschreibung ist aber die Ausf hrung wer selber kocht wei dies sehr dynamisch sein kann Auch in der Software ist der Prozess die dynam
41. Funktionalit t anbietet 4 e Query erweitern dass hnliche jedoch nicht identische Komponenten in den Suchergebnissen aufscheinen e Finden einer bestimmten Software Komponente ob wohl diese evtl falsch klassifiziert wurde durch sog Semantic Matching Ein weiterer objekt orientierter Klassifizierungsansatz wird in 6 diskutiert Dabei werden die Funktionalit ts Facetten von Prieto Diaz und Freeman aus 11 nicht ver ndert ihnen jedoch teilweise eine andere Bedeutung zugesprochen 5 2 Feature orientierte Klassifizierung Die L sungen von Prieto Diaz und Freeman in 11 und Karlsson et al in 4 die f r die Beschreibung von Software Komponenten auf Facetten aufbauen haben einen Nachteil die Anzahl der Facetten ist von der Implementierung des Library Systems abh ngig z B sechs Facetten bei dem An satz von Prieto Diaz und Freeman in 11 und vier Facetten bei der Arbeit von Karlsson et al in 4 Dadurch wird auch das Beschreiben von Komponenten die mehrere Funktionen anbieten schwierig 1 Aus diesem Grund geht B rstler in 1 einem feature orientie rten Ansatz nach der die Probleme der facetten orientierten Klassifizierung beseitigen soll Im Zuge dieses Ansatzes reali siert B rstler ein feature orientiertes Klassifikations Schema mit dem Namen FOCS Bei der feature orientierten Klassifizierung wird eine Software Komponente durch eine Menge von Eigenschaften Featu res beschrieben 1 com
42. L subtrahiert von R gr er 0 ergibt geht sie nach Rechts ansonsten nach Links L und R sind dabei die Pheromonkonzentrationen auf den beiden Wegen Als 3 Schritt werden die Zugeh rigkeitsfunktionen zu den granularen Mengen wie sie in Punkt 2 erstellt wurden gebildet Da es nur eine Variable gibt k nnen wir auch nur ein Diagramm erstellen welches in Ab bildung 6 dargestellt wird H Right Left 0 D Abb 6 Membership Funktion fiir Ameisenwahl Dieses Diagramm ist auch stark davon abh ngig wie man das Expertenwissen der Ameise modellieren will Knapp bei 0 wei die Ameise dass es auch der andere Weg sein kann welcher schneller zum Futter f hrt Sie wendet aber trotzdem den Weg mit der gr Beren Pheromonkonzentration an Als letzten Punkt muss man noch ein Auswertever fahren w hlen Da man nun alles modelliert hat um eine Fuzzy L sung zu erhalten muss das Ergebnis wieder in eine konkrete Antwort umgeleitet werden Dies kann mittels unterschiedlicher Verfahren gesche hen Die Verfahren werden genauer in Kapitel 4 er kl rt Die meisten Bereiche der Natur werden mit einer verbalen Beschreibung des Sachverhaltes abgebildet Die Wissenschaft kann stark davon profitieren wenn sie diese in mathematische Modelle umwandeln kann Dazu kann und wird auch Fuzzy Logik verwendet Dieser Trend ist vor allem deswegen n tzlich um nat rliche Mechanismen welche sich schon in der rea len Welt bew hrt haben nachzua
43. Laufzeit werden bei den Zustandsdiagrammen Events und konventionelle Methodenaufrufe erlaubt Mit Events l sst sich ein System auf einer hohen Abstrak tionsebene gut modellieren daf r ist die bersetzung in Programmcode schwieriger Methodenaufrufe hinge gen erlauben eine sehr einfache Umsetzung sind aber nicht so m chtig Vererbung und Verhaltens bereinstimmung 7 Ver erbung ist ein wichtiges und m chtiges Konstrukt im objekt orientierten Paradigma welches in Verbindung mit Zustands diagrammen einige Fragen aufwirft Generell wird bei der Vererbung nur eine bereinstimmung der Schnittstellen ge fordert die noch nichts ber das Verhalten aussagen Eine Klasse B welche eine Subklasse von A ist kann ihr Verhalten komplett ndern ohne gegen Vererbungsregeln zu versto en Wenn aber wie im Ansatz von David Harel und Eran Gery ein Zustandsdiagramm zu der Klasse A zugeordnet ist wie kann garantiert werden dass dieses auch zu B passt Sie werden hier nur der Vollst ndigkeit wegen aufgef hrt da ihnen bei weiterf hrenden Forschungsarbeiten von David Harel noch viel Bedeutung zugemessen wird Mit diesen Problemen welche gro e Forschungsgebiete ff nen sahen sich die Autoren damals konfrontiert David Ha rel und Orna Kupferman widmeten sich Jahre sp ter in 10 dieser Thematik in welcher sie klare Definitionen auff hr ten was genau unter Verhaltens bereinstimmung im Bezug auf Vererbung zu verstehen und wi
44. Logix stellten sie parallel dazu ein Werkzeug vor welches dieses Vorgehensmodell verwirk lichte Es wurde in diesem Zusammenhang bereits der Ge danke vom Model Driven Software Development MDSD umgesetzt bevor dieser ffentlich formuliert wurde Diese Arbeit setzt die Konzepte aus dem Artikel von Ha rel und Gery in Bezug zur Gegenwart und hebt die daraus resultierenden Entwicklungen hervor Es wird prim r auf die Idee des Model Driven Software Development MDSD und weiterf hrende Forschungsarbeiten der Autoren einge gangen die dieses Konzept erweitern 1 EINLEITUNG UND MOTIVATION Welche Bedeutung hat der Artikel Executable Object Mo deling with Statecharts 7 von David Harel und Eran Gery heute zehn Jahre nach seiner Publikation in der Scienti fic Community Zu welchen Technologien die f r uns heute selbstverst ndlich sind haben die Erkenntnisse der Autoren gef hrt bzw beigetragen Warum ist dieser Artikel noch heute von Bedeutung Diese Arbeit verfolgt das Ziel die Konzepte von David Harel und Eran Gery anfangs offen zu legen und deren weitere Ent wicklung in den letzten zehn Jahren zu betrachten Dabei wird kein Anspruch auf Vollst ndigkeit erhoben Vielmehr werden einzelne Konzepte der Autoren herausgegriffen und ihre Entwicklung im Laufe der Zeit weiter verfolgt In Kapitel 3 werden die Grundideen des Model Driven Soft ware Development MDSD im Bezug auf die Konzepte von Davi
45. M written in 1964 he proposes an interesting idea when he lists some of his concerns on a new operating system To put my strongest concerns into a nutshell 1 We should have some ways of connecting programs like garden hose screw in another segment when it becomes necessary to message data in another way This is the way of IO also 10 This new operating system mentioned was the predecessor of UNIX named Multics for which development started around the time this note was written Even though I O redirection chapter 2 2 2 was possible in Multics the possibility of connecting two concurrently running programs without the need of a temporary file was not But UNIX was not the first to integrate pipes either The Dartmouth Time Sharing System as described in 1971 11 allowed to do pretty much the same things possible with UNIX pipes 43 However it was not as easy to use and was not exploited to such an extend 4 In UNIX pipes did not appear until 1972 Actually at first it was not even planned to integrate such a facility Through the insistence of McIlroy however it was finally added At the same time the tools which were already developed and running were changed to meet the new design principles see chapter 2 3 From there on the common use of the UNIX pipelining facility has incredibly grown 4 3 2 2 Pipes and filters design pattern As the size and complexity of software systems increases the desi
46. Mat rix darstellt und der F hrungsstil Look Forward Management beschrieben Andererseits wird die technisch sowie organisato risch unterst tzende Komponente herausgehoben in dem Matsumoto auch eine Infrastruktur zur Durchf h rung der notwendigen Arbeiten des Prozesses und eine Software Workbench SWB zur informationstechni schen Unterst tzung der einzelnen Phasen beschreibt Insbesondere wird auf das Konzept Reusability ein gegangen dessen Bedeutung mit Zahlen unterstrichen wird W hrend 52 der Angestellten bei der halbj hr lichen Mitarbeiterbefragung das Reuse Konzept als entscheidenden Faktor f r ihre Produktivit t nennen werden auch die protokollierten Reuse Raten von Tei len dokumentiert die zwischen 33 Reuse von Do kumenten in Designphase und 48 Reuse von Pro grammkomponenten liegen Es ist in diesem Bereich bereits die klare Unterscheidung zwischen Software die f r Reuse entwickelt wird und Software die durch Reuse entwickelt wird getroffen die P A V Hall kurz darauf in 2 n her ausf hrt Als Rahmen f r das gesamte Reuse Konzept wird eine Organisationsstruktur angef hrt in der ein Teil der Arbeitsressourcen ausschlie lich mit der Entwicklung und Verwaltung von Reuse Komponenten besch ftigt ist Die origin re Programmentwicklung w hlt als Kunde dieses hausinternen Dienstleisters Komponenten aus der vorhandenen Komponentendatenbank zur wei teren Verwendung im Programmierprozess der
47. Potential des auf die Verwen dung von Komponenten optimierten Prozessmodells besprochen Das letzte Kapitel fasst die wichtigsten Aussagen noch einmal kurz zusammen 2 Die Softwarekomponente ber Softwarekomponenten wurde schon viel ge schrieben und dementsprechend viele Sichtweisen gibt es auf dieses Thema Bereits eine Definition f llt schwer angesichts der Tatsache dass dieser Begriff erst im Kontext der Verwendung seine wahre Bedeu tung zeigt 23 7 Um ein gutes Gef hl daf r zu be kommen was eine Softwarekomponente darstellt hilft es sich die f nf von Meyer 19 vorgestellten Abstrak tionsebenen anzusehen e functional abstraction Stellt eine einzelne wohl definierte Funktion zur Verf gung beispielsweise eine mathematische Operation e casual grouping Eine Gruppierung hnlicher funktionaler Elemente oder Datendeklarationen wie sie in C Dateien h ufig vorkommen e data abstraction Klassen in objektorientierten Programmiersprachen entsprechend dieser Ab straktionsstufe der Datenabstraktion e cluster abstraction Frameworks bestehend aus aufeinander abgestimmten zur Komposition be stimmter Klassen e system abstraction Eine weitgehend selbstst ndig lauff hige Komponente die in sich abgeschlossen ist und klare Schnittstellendefinitionen besitzt Beispielhaft w ren hier die COTS commerical off the shelf Komponenten zu nennen Obgleich der Komponentenbegriff f r jede Abstrakti onsart volle Berecht
48. Software too ver ffentlicht 10 Jahre sp ter wurde dieser Artikel zum einflussreichsten Artikel der 9 International Conference on Software Engineering ICSE gek rt Dieser Artikel greift die Aussage L Osterweils aus dem Jahre 1987 auf und untersucht die zwei im Abstand von zehn Jahren im Rahmen der ICSE ver ffentlichten Publikationen genauso wie die kontrovers dazu verfassten Ansichten M Lehmans Wurde der Ansatz Osterweils weiterverfolgt Diesbez glich sind einige Entwicklungen erw hnenswert Er selbst hat mit APPL A und Little JIL zwei Entwicklungen mitgetragen die seinen Ansatz untermauern sollten Hierbei handelt es sich um zwei Softwareprozessprogrammiersprachen die sehr unterschiedlich sind Die eine ist an die Programmiersprache Ada angelehnt die andere Little JIL ist eine grafische Sprache Hier will ich die grundlegenden Ideen aufzeigen und damit die Unterschiede hervorheben Die dritte Programmiersprache f r Software Prozesse auf die ich n her eingehen will ist der heute sehr aktuelle und gebr uchliche Rational Unified Process RUP Philippe Kruchten hat in Bezug auf den Rational Unified Process gesagt Kruchten 03 dass mittels RUP der Softwareentwicklungsprozess als Software behandelt werden kann Ein interessanter Aspekt hierbei ist dass RUP selber sowohl Softwareprozess als auch Software ist 1 Einleitung Die Aussage das Softwareprozesse auch Software seien sollen hat mich zuerst sehr be
49. The Multics input output system Proc Thid Symposium on Operating System Principles October 18 20 1971 pp 25 41 according to Ritchie D M The Evolution of the Unix Time sharing System AT amp T Bell Laboratories Technical Journal Volume 63 No 6 Part 2 October 1984 pp 1577 1593 Kernighan B W and Pike R The UNIX Programming Environment Prentice Hall London 1984 Schaffer E and Wolf M The UNIX Shell as a Fourth Generation Language Technical Report Revolutionary Software Inc Santa Cruz CA http www rdb com lib 4gl pdf last visited 15 05 2007 Spinellis D Tool writing A Forgotten Art IEEE Software Volume 22 No 4 pp 9 11 McIlroy M D Internal Bell Labs memo provided by Ritchie D M http cm bell labs com cm cs who dmr mdmpipe html last visited 15 05 2007 Systems Programmers Manual for the Dartmouth Time Sharing System for the GE 635 Computer Dartmouth College Hanover New Hampshire 1971 according to Ritchie D M The Evolution of the Unix Time sharing System AT amp T Bell Laboratories Technical Journal Volume 63 No 6 Part 2 October 1984 pp 1577 1593 Garlan D and Shaw M An Introduction to Software Architecture in Ambriola V and Tortora G editors Advances in Software Engineering and Knowledge Engineering Volume 1 World Scientific Publishing Company New Jersey 1993 Mittermeier R T Lecture notes for Software Entwurf Test und Entwicklungsprozess Kapitel
50. Thesaurus und dem Distanz Modell zus tz lich zu einem Mechanismus zum Evaluieren und Ordnen von Komponenten Suchergebnissen in Form eines Library Systems von Prieto Diaz und Freeman in 11 realisiert und umgesetzt Die so entstandene Software Collection bietet damit die im Reuse Modell definierte Funktionalit t Um das Faceted Classification Scheme wie beschrieben umzusetzen teilt sich das Library System in zwei Teile 11 e Query System e Evaluierungs Mechanismus Wie bereits bei der Komponenten Beschreibung in Kapitel 4 1 ersichtlich wurde besteht die Beschreibung einer Software Komponente im facetten orientierten Klassifikations Schema aus einem Sechs Tupel Das Query System baut nun auf die ser Beschreibung auf und setzt sich aus folgenden Kompo nenten zusammen 11 e Query Generierung Bei der Query Generierung werden die Facetten mit Werten befiillt Spielt der Wert einer Facette keine Rol le ist es m glich diese Facette mit einer Wildcard in Form eines Sternes zu beschreiben Liefert eine Query kein zufriedenstellendes Suchergebnis z B kein Ergeb nis oder zu viele gefundene Komponenten kann diese modifiziert werden Query Modifizierung Soll eine Query allgemeiner werden d h mehr Such ergebnisse liefern k nnen einzelne Facetten mit Hilfe von Wildcards beschrieben werden Wird jedoch das Gegenteil ben tigt d h eine Query lieferte zu viele Suchergebnisse und soll nun spezieller werden m
51. Verfahren k nnen die einzelnen Erset zungen auch f r Modularisierung herangezogen werden jeder Schritt erm glicht es den eingesetzten Block durch einen Funktionsaufruf oder gar ein ganzes Modul zu ersetzen Diese Module k nnen f r eine sp tere Wiederverwendung in eigenen Bibliotheken abgelegt werden um dieselbe Funktionalit t an mehreren Stellen einzusetzen Des Weiteren k nnen die einzelnen Mo dule durch neuere bzw effizientere Varianten ausge tauscht werden ohne negative Nebeneffekte zu erzeu gen Trotz der Strukturiertheit Top Down Entwicklung und Modularisierung bedeutet das nicht dass ein resul tierendes Produkt qualitativ hochwertig einzustufen ist Ein Programm kann nur dann als gut angesehen wer den wenn es nicht voll von Fehlern ist Im Nachhinein das Programm durchzutesten und zu versuchen alle Fehler auszumerzen ist jedoch nicht immer zielf hrend Dazu meint Dijkstra 4 program testing can be a very effective way to show the presence of bugs but it is hopelessly inade quate for showing their absence 06 Aus dieser Uberlegung heraus wird auch der Vor schlag aufgeworfen dass man Software von Anfang an fehlerfrei entwickeln solle dies braucht zwar einen aufw ndigeren Prozess jedoch w rde dies insgesamt einiges an Test und Debugging ersparen Strukturierte Programmierung beschreibt genau einen derartigen Prozess Hier ist es m glich ein Programm und dessen funktionellen Nachweis quasi parall
52. Wenn bei diesen Verfeinerungen davon ausge gangen werden kann dass das urspr ngliche abstrakte re Konstrukt konzeptuell korrekt war und wenn keine zus tzlichen Fehler eingeschleust wurden so ist das Ergebnis ebenfalls korrekt Wichtig dabei ist dass man bei der Umsetzung in jedem Schritt daf r sorgt dass das entstandene Programm genau das tut was es soll nicht weniger aber auch nicht mehr Jeder Schritt hat im eigentlichen Sinn eine Beschreibung des Programms zur Folge mit fortschreitenden Iterationen wird diese Beschreibung eben immer genauer 11 09 2 2 3 Kontrollstrukturen Bei dem Prozess der Verfeinerung d rfen lediglich drei verschiedene Buil ding Blocks eingesetzt werden die von der verwen deten Programmiersprache abh ngig jedoch in ver schiedenen Varianten existieren k nnen Die Sequenz Konkatenation ist eine Menge von Anweisungen die in einer bestimmten Reihenfolge hintereinander ausgef hrt wird Die Wiederholung Schleife beschreibt das Ver fahren dass ein bestimmter Block also auch zum Beispiel eine Sequenz unter bestimmten Bedin gungen wiederholt wird Die berpr fung dieser Bedingungen kann zu Beginn while do Schleife oder am Ende repeat until Schleife der Wiederholung stehen Befindet sich die ber pr fung am Ende so wird der umschlossene Block zumindest ein mal durchlaufen Auch eine zuvor definierte Anzahl an Wiederholungen bietet eine Variante f r e
53. a Denotes a simple instruction Termination Terminates the instruction program Positive test a for each a 2 If instruction a is instruction evaluated with true the subsequent instruction after a is executed If instruction a is evaluated with false the subsequent instruction after a is Negative test a for each a 2 instruction executed Forward jump k whereby k E N A jump over k instruction operations Concatenation For modeling an instruction sequence A label with an assigned natural number Jumps to the label denoted by k Table 1 A short description of a PGLE Label instruction kwherekEN Goto instruction k where k EN 3 2 2 Concerning goto like constructs The constructs break continue and case are now going to be examined The proofs are based on a simple transfer of a pseudo code like programming language into PGLE notion There is one thing to mention beforehand it is simpler to transform do while loops into PGLE because the loop condition needs not to be altered For simplicity only do while loops are used in the following examples Table 2 shows the translation of a do while loop with an if break statement included In case the if statement is validated with true the loop is going to be terminated The translation shows that the code can be described with two simple goto s the break statement is one of them It has to be said that break is m
54. a specified level of perfomance with a given target reuser Wiederverwender als Lernsystem Der Fokus ist auf den Wiederverwender gerichtet der in einem Lernsystem eingebettet ist Die Aufgabenstellung von Domain Analysis in diesem Lernsystem ist wie folgt 1 Finde eine Methode die 104 1 Informationen in einer Dom ne identifiziert die in passender Form f r den Wiederverwender einen bestimmten Grad an Effizienz f r die Systemerstellung erm glicht 2 diese relevanten Informationen erfasst 3 diese Information verbessert um die Effizienz zu erh hen Das Lernsystem besteht aus der grundlegenden Aufgabenstellung des Wiederverwenders ein System zu erstellen Er hat eine Spezifikation die mit einer bestimmten Technologie implementiert werden soll Dabei bedient er sich der Wiederverwendungs infrastruktur in der geeignete Informationen des Modells der Dom ne in Form der passenden Technologie vorhanden sind Die gesammelte Erfahrung eines Wiederverwenders w hrend der Entwicklung flie t zur ck in die Infrastruktur um die Effizienz zu erh hen Neben dem Ziel der Effizienz sind auch andere Zieldefinitionen m glich Z B Implementierungen zu erzeugen die Speicher und CPU effizient nutzen oder Implementierungen die sicher sind 1 Mit mathematischen Konstrukten und Variablenbelegungen des Lernsystems k nnen mit diesem Framework unter bestimmten Vorraussetzungen unterschiedliche Domain Analysis Methoden mi
55. code see section 2 3 Another result was the replacement of goto branches with other similar named and similar working constructs like come froms 24 or leave lt label gt with lt expression gt 25 22 In the long term several other explicit branching constructs with a narrower scope like break continue case and return were developed and proved to be good natured to the programing structure Yet another impact of the goto discussion was the development of imperative programming languages without any goto s or goto like branching constructs Modula 2 Oberon Java Python 5 6 7 8 It has to be mentioned that there are also languages supporting unconditional branching C C C Visual FoxPro 9 10 11 12 The question arises whether so called goto less programming languages are really lacking means for unconditional branches The answer is a clear and simple no as I am going to describe in the next sub chapter 3 2 1 A programming algebra with labels and goto s It is quite easy to show that certain kinds of loop termination constructs case constructs and even return constructs are nothing more than limited unconditional branches To achieve this I would like to use a few components of a simple program algebra with labels and goto s PGLE 15 To start with a few PGLE building blocks are described in table 1 Building block Representation Explanation Basic instruction Every
56. der 90er Jahre wurden mit dem Artikel Exe cutable Object Modeling with Statecharts 7 erste Konzep te pr sentiert die heute unter dem Begriff Model Driven Software Development zu finden sind Zustandsdiagram me wurden in diesem Artikel aufgegriffen um das dyna mische Verhalten w hrend der Laufzeit zu modellieren Die Bestandteile des Entwicklungskonzeptes sind in Abbildung 2 grafisch veranschaulicht Die grundlegende Idee ist sich von der Programmierung zu l sen und weiter zu abstrahieren um der steigenden Komplexit t von Softwaresystemen Herr zu werden Auf einer Metaebene wird zur Modellierung eine Kombination aus Zustands und Klassendiagrammen ver wendet welche Informationen zum Laufzeitverhalten bein haltet die sonst nur im Programmcode zu finden sind Die ses Konzept welches die Verbindung von Verhaltenskompo nenten und der Struktur beschreibt wird als ausf hrbares Modell bezeichnet 2Das Buch Model Driven Architecture Applying MDA to Enterprise Computing 2 von David S Frankel behandelt den Standard der Object Management Group OMG und ist nicht als allgemeines MDSD Buch zu betrachten Code generation System model XUML or SA SD Figure 1 System Modellierung mit Codegene rierung Das Modell vom System beinhaltet Struktur und Verhaltensinformationen welche mit tels visuellen Formalismen wie executable UML xUML oder structured analysis structured de sign
57. der Methoden aus den Bereichen der Datenban ken Abstraktionsmechanismen und der K nstlichen Intelligenz Knowledge Representation Ontologien In meinem Artikel wollte ich die nachhaltige Relevanz solcher expliziten Wissensdarstellungen im RE ver deutlichen Dazu erkl rte ich zu Beginn Begriffe rund um die Informationsmodellierung und hob die Rolle der K nstlichen Intelligenz heraus In Abschnitt 4 ver suchte ich aufzuzeigen dass die Ber cksichtigung von Zielen in der Anforderungsanalysephase eine Anforde rungsspezifikation weiter komplettieren kann Weiters wurden Entwicklungen im Bereich der K nstlichen Intelligenz speziell im Gebieten der Ontologien dar gestellt 6 1 Warum formale Wissensrepr sentation heute noch Bedeutung hat Heutzutage hat die standardisierte semi formale Mo dellierungssprache UML einen festen Platz in der An forderungsmodellierung Mit ihren zahlreichen Model len l sst sich beinahe jede Problemstellung im Prozess der Softwareentwicklung abbilden Formale Methoden zur Wissensdarstellung sind hingegen nicht leicht an zuwenden und auch kaum verbreitet Mit steigender Komplexit t und Gr e des zu entwickelnden Systems bzw in Bereichen die h chste Pr zision verlangen z B Krankenhausbetriebe k nnen formale Sprachen zur Wissensrepr sentation und der Einsatz von Onto logien sehr unterst tzend und unter Umst nden zwin gend notwendig sein Sie liefern eine exakte unmiss verst nd
58. der zweiten Phase sieht man zus tzlich noch den Fokus bei Design und bei der Implementierung eines evtl Prototyps In der Konstruktionsphase wird der Fokus auf die Fertigstellung der Applikation gelegt wobei aber im ersten Teil auch das Design noch eine gr ere Rolle spielt In der letzten Phase geht der Schwerpunkt dann auf die bergabe ber wobei hier die Konfiguration beim Kunden berwiegt Ein Prozess beschreibt wer was wann wie tut Im RUP gibt es f nf prim re Elemente Rollen sind das wer Aktivit ten sind das wie Artefakte sind das was Workflows sind das wann Disziplin der Container in der sich die vorherigen Punkte befinden Ein Designer Rolle f hrt eine Use Case Analyse durch und erstellt dann ein Use Case Design Aktivit ten und erh lt dann eine Realisierung eines Use Cases Artefakt Die Reihenfolge wie der Designer das macht und welche Optionen er hat k nnen in einem Workflow dargestellt werden Im Mittelpunkt des RUP steht eine Rolle Eine Rolle beschreibt das Verhalten und die Verantwortlichkeiten eines Einzelnen oder einer Gruppe Das Verhalten ist in Aktivit ten die die Rolle ausf hren kann festgelegt Die Verantwortung wird gegen ber eines oder mehrerer Artefakte ausgedr ckt welche von der Rolle erzeugt modifiziert oder kontrolliert werden k nnen Rollen sind auch nicht dauerhaft an eine Person gebunden sondern k nnen bei Bedarf und bei Qualifikation vergeben werden Man kann z B
59. die fabrik hnliche Softwarefertigung stellt indem von ihm geforderte Workloads pro Einheit oder Person defi nierbar sind der Gesamtaufwand entsprechend ver folgbar ist und auch der gegenw rtige Fortschritt sehr transparent abgebildet werden kann 5 3 Reuse Die Realisierung des Reuse Konzeptes ist ein ber raschend vernachl ssigter Bereich moderner Entwick lungstools Weder die Komponentenverwaltung in ei nem eigenen Repository noch der Prozess einer sepa raten Komponentenerstellung und Verwendung mit berwachung kann auch nur ansatzweise in einem der Tools erkannt werden Der Trend geht eher in die Rich tung von Prozess Reuse Es werden ber Templates allgemeine wiederverwendbare und parametrisierbare Aufgabenl sungen geschaffen die dem Entwickler nicht als fertige getestete und verifizierte Komponente zur Verf gung stehen sondern ihm nur einen Standard Rahmen nach Best Practice Konzept liefern Der Ent wickler parametrisiert diesen und f llt ihn teilweise mit Code wodurch eine im Anschluss von Grund auf zu testende Komponente entsteht Verglichen mit der gut durchdachten Vorarbeit die hier in Matsumotos Text und anderen Arbeiten bereits geleistet wurde ist diese Entwicklung entt uschend 6 Lessons taught Die Sicht auf Matsumotos Artikel umkehrend soll noch kurz beleuchtet werden was aus heutiger Sicht im Prozess der Software Factory zu erg nzen w re Basierend auf den beschriebenen aktuellen Tools k
60. ein An satz f r semantik basierte Klassifizierung definiert welcher aus drei Abschnitten besteht und durch Abbildung 3 zum Ausdruck gebracht wird In Abschnitt 1 wird ein intelligentes auf nat rlicher Sprache aufbauendes User Interface definiert Durch dieses Interface ist ein Benutzer in der Lage Queries durch nat rliche Spra che auszudr cken welche durch einen konzeptionellen Gra phen CG repr sentiert und ber Semantic Web zum Aus druck gebracht wird Weiters wird die nat rliche Sprache in RDF bzw WSDL umgewandelt Um dies zu erm glichen wird auf DAML OIL zur ckgegriffen 13 Im zweiten Abschnitt des Ansatzes wird ein Analyse Tool definiert welches bestehende Software Komponenten durch eine semantik basierte Beschreibung charakterisiert Eben so wie in Abschnitt 1 wird hier ein konzeptioneller Graph eingesetzt um die Beschreibung zu repr sentieren und ber Semantic Web zum Ausdruck zu bringen Weiters wird die nat rliche Sprache in RDF bzw WSDL umgewandelt Um dies zu erm glichen wird auf DAML OIL zur ckgegriffen 13 In Abschnitt 3 wird ein Tool beschrieben welches die in Ab schnitt 1 und 2 definierten konzeptionellen Graphen zuein ander in Relation setzt und die semantischen Repr sentat ionen RDF bzw WSDL miteinander vergleicht Dadurch wird die Query die der Benutzer ber das User Interface erzeugt und abgesetzt hat ausgef hrt 13 Der Ansatz von Yao und Etzkorn in 13 beinhaltet wei ter
61. ere Canin ENT T J eesatwe anh ee pages EEE Era BER zu ha P Wegner Capital intensive Software Technology IEEE Software Vol 1 3 July 1984 pp 745 x x hs L Osterwe Software Processes are Software Too Proc ICSE 9 Monterey 1887 pp 2 10 x x Ih _ F P Brooks 7 __ TheMythical Man Month_ Datamation Dec TTA o o To Ih __ LA Belady MM Lehman A Model of Large Program Development IBM Systems Journal No 3 1976 pp 225252 J V R Basili R W Selby A General Empirical Solution to the Macro Software Sizing ho it pumam __ _endesimeingrictiom nn ieee rans on sotare erg suyi oO Software function source lines of code and hro Aui abc J Gainey sr _laevoopment organ sofware scence vain IEEE Trans on Sotware Erg Vol SE 9 Nov 198 pp 638 848 B Curtis S B Sheppard Measuring the Psychological Complexity of Software pn Piano Matern ase mite cued ard cco netcs ee Tane on Sotware Eng Val SES 9 Marn tren a8 104 Data Bases and Information Systems E F Codd A Relational Model of Data for Large Shared Data Banks Comm ACM Vol 13 6 June 1970 pp 337 387 OoOo o O Extending the Database Relational Model d2 E F Codd to Capture More Meaning ACM TODS Vol 4 4 Tec 1979 pp 397 434 P P S Chen The Entity Relationship Model Toward a Unified View of Data ACM TODS Vol 1 1 March 1976 pp 9 36 OOo e d4 u M Smith D C P Smith Database abstractions agg
62. f r das System mit Hilfe der linguistischen Terme aufgestellt Es gibt verschiedene Methoden diese Regeln zu erhalten Beispielsweise wird oft ein Experte des jeweiligen Bereichs zu Rate gezogen welcher dann seine Handlungen in linguistischen Regeln formuliert Die Aufgabe des Entwicklers ist es diese Regeln in Implikationen mit linguistischen Termen zu transformieren Au erdem ist f r die Art der Auswertung der Regeln eine Methode festzulegen Wir verwenden die einfache und durchaus erfolgreiche Min Max Inferenz Methode Diese werde ich beim Auswerten n her beschreiben Beispiel Aufstellen der Regelbasis R1 WENN Temperatur kalt DANN Ventil zu R2 WENN Temperatur hei DANN Ventil offen R3 WENN Temperatur angenehm UND Personen wenig DANN Ventil zu R4 WENN Temperatur angenehm UND Personen mittel DANN Ventil wenig offen R5 WENN Temperatur angenehm UND Personen viele DANN Ventil viel offen Auswahl der Defuzzifizierungsstrategie Als letzte Aufgabe des Entwicklers in der Modellierungsphase ist eine geeignete Defuzzifizierungsstrategie zu w hlen Eine sehr beliebte Strategie ist die so genannte Schwerpunktmethode 7 Diese ermittelt den scharfen Wert als Fl chenschwerpunkt Diese Methode ist sehr zuverl ssig jedoch ist die Schwerpunktberechnung speziell wenn die Zugeh rigkeitsfunktion aus Kurven besteht recht m hsam und erfordert dementsprechend auch viel Speicherplatz und Zeit Ein Grund warum man e
63. f r einen bestimmten Zeitraum Designer sein und danach Reviewer mit mehreren anderen und sich dann wieder in einer anderen Rolle wiederfinden Aktivit ten werden durch Rollen ausgef hrt und m ssen ein sinnvolles Ergebnis f r das Projekt liefern Die Aktivit t eine Iteration zu Planen geh rt zur Rolle des Projekt Managers das Finden von Use Cases und Akteuren geh rt zur Rolle des System Analysten und der Performance Tester ist verantwortlich f r das Ausf hren eines Performance Tests 85 Aktivit ten werden wiederum in drei Schritte unterteilt das Denken das Durchf hren und das berpr fen der Aktivit t Aktivit ten k nnen In und Output Artefakte haben Artefakte sind Produkte Informationen die erzeugt modifiziert oder von Aktivit ten gebraucht werden Artefakte k nnen Modelle Dokumente Source Code oder ausf hrbare Programme teile wie z B Werkzeuge sein Diszipline sind die in Abbildung 2 gezeigten Container wie z B Business Modelling oder Requirements Was sind nun die Vorteile eines iterativen Prozesses gegen ber z B Beispiel des traditionellen Ansatzes eines Wasserfallmodels Das Risiko einen Fehler mitzuschleppen wird vermindert Man erkennt Fehler oft erst bei der bergabe des Produktes an den Kunden Durch den iterativen Prozess k nnen diese Fehler fr her erkannt werden Je fr her ein Fehler erkannt wird desto geringer sind die Kosten diesen zu korrigieren Wenn ein Projekt abgebro
64. finden w rde IBM zeigt dies vor indem seine Rational Delivery Platform entsprechend auf dem RUP Prozessmodell aufbaut und das entsprechende Wiederdurchlaufen der Phasen Iterationen unterst tzt 7 Zusammenfassung Der n her untersuchte Bereich der Tool Unterst tzung im durchg ngigen Softwareprozess der von Matsumoto ber das Konzept Software Work bench realisiert wurde zeigt in gro en Bereichen eine nur leicht ver nderte bertragung der damaligen Kon zepte sowohl strukturell als auch inhaltlich in die heu tigen Werkzeuge In den untersuchten L sungen nicht bernommen wurde ent uschenderweise das hervorra gende Reuse Konzept w hrend andererseits die reali sierten Neuerungen im Bereich der Software Verteilung durchaus auch Anregungen zur Verbesse rung im Fuchu System liefern Insgesamt verbleibt der Eindruck dass die vorgestellten Werkzeuge den pro vokanten Software Factory Gedanken vielleicht sogar etwas zu weit in maschinelle automatisierte und struk turierte Erstellung spinnen Der pers nliche Aspekt ist nicht detaillierter zu finden Er muss vom heutigen Management auf einer zweiten organisatorischen Schiene abgebildet werden Matsumotos Ideen sind f r die damalige Zeit sehr drastisch aufgrund der detaillierten und straffen Struk turierung und richtungsweisend Die durch Workben ches unterst tzte Prozessstruktur mit klar definierten Zielen von Qualit t und Effizienz berzeugt als ganz heitl
65. gebunden Diese bei den Bedingungen sollten in einer Komponentenspezifi kation keinesfalls fehlen Diese Form der Anforderun gen bezeichnet Szyperski als Kontext Abh ngigkeiten 28 Blackbox und Whitebox Abstraktion Blackbox und Whitebox Abstraktion beschreibt m gliche Sicht barkeit der Implementierungsdetails von Komponenten Wird eine Komponente als Blackbox betitelt so sind lediglich Vor und Nachbedingungen des Software bausteins bekannt Bei der Whitebox Sichtbarkeit steht in der Regel der Quellcode zur Verf gung und dem Entwickler ist es m glich jeden internen Arbeitsschritt nachzuvollziehen oder ihn sogar abzu ndern Wird die M glichkeit der nderung unterbunden die Quellcode Sichtbarkeit aber bleibt erhalten so spricht man von Glassbox Sichtbarkeit Buchi und Weck bieten in 8 eine detaillierte Betrachtung ber die Schwierigkeiten der verschiedenen Sichtbarkeitsstufen Die Autoren ha ben L cken bei der Spezifikation von Sichtbarkeiten erkannt Im Speziellen sind Call backs in Blackbox Spezifikationen nicht vorgesehen Sie schlagen deshalb eine Greybox Spezifikationssprache als nat rliche Er weiterung der Implementierungssprache vor Demnach ist Greybox Sichtbarkeit eine erg nzende Spezifikati on zur Blackbox Sichtbarkeit mit der Erweiterung ei nige f r die Ausf hrung wichtige Implementierungsde tails sichtbar zu machen Die unterschiedlichen Sicht barkeiten sind f r das Testen von Komponenten ein ents
66. gepr gt Die j ngeren Arbeiten von David Harel gehen einen Schritt weiter in Richtung Formalisierung der Anforderungen und Objektmodell Diagramm gearbeitet 31 der M glichkeit aus diesen das Softwareprodukt zu generie ren Mit der Arbeit From Play In Scenarios to Code An Achie vable Dream 6 macht David Harel wie auch im Titel schon verankert klar dass es sich hierbei um eine Traum vorstellung handelt deren vollst ndige Realisierung noch l nger auf sich warten lassen wird Trotzdem gibt es auch heute schon einige Entwicklungs umgebungen die Model Driven Software Development un terst tzen und damit einen kleinen Markt bedienen Der Trend nimmt zu und durch die Bem hungen der Object Management Group OMG mit der Standardisierung von Model Driven Architecture MDA wird dieser meiner Ein sch tzung nach anhalten 6 REFERENCES 1 Werner Damm and David Harel LSCs Breathing life into message sequence charts Formal Methods in System Design 19 1 45 80 July 2001 2 David S Frankel Model Driven Architecture Applying MDA to Enterprise Computing John Wiley and Sons 2003 3 D Harel and R Marelly Specifying and executing behavioral requirements The play in play out approach Technical Report MSC01 15 The Weizmann Institute of Science 2001 4 David Harel Statecharts A visual formalism for complex systems Sci Comput Program 8 3 231 274 1987 5 David Harel Biti
67. haben ge sagt Das Auto f hrt schnell und meinen dabei Die Geschwindigkeit ist schnell Wir meinen also die Form X is Y Im Allgemeinen spricht man aber von einer X isr Y Verbindung da diese von unterschiedlichen Bedingungen abh ngen kann F r r kann anschlie end eine der folgenden Funktionen eingesetzt werden Zeichen Bedeutung equal disjunctive konjunctive probabilistic probabilistic value usuality c ix a jajo Abb 4 Verbindungsformen bei Theoremen Im Folgenden werden einige Verbindungen aus Ab bildung 4 anhand von Beispielen genauer erl utert John spricht Englisch Franz sisch und Deutsch Proficiency John ise 1 Englisch 0 7 Franz sisch 0 6 Deutsch Hierbei deuten die Zahlen darauf hin wie gut John die jeweilige Sprache beherrscht Eine andere m gliche Form der Bedingungen lautet X isp R Dies bezeichnet eine Verbindung mit einer Normalverteilung mit Mittelwert und Varianz Man schreibt daher auch X isp Nm O Hierbei werden der Mittelwert sowie die Abwei chung der Normalverteilung beachtet Gleiches gilt somit f r den Ausdruck X isp R 0 2 a 0 5 b 0 3 c 122 Dies bedeutet nun dass X eine Zufallsvariable dar stellt welche die Werte a b und c mit den dazugeh ri gen Wahrscheinlichkeitswerten annimmt Wenn man sagt x isu r dann bedeutet dies x is usu ally R und meint damit Prob X is R is usually Wie man a
68. in 19 This paper resulted of a software to remove goto statements from source code with several thousand lines written in COBOL It is based on finite automata and regular expressions The algorithm starts with writing down the program as flowchart The flowchart representation can be transferred easily into a finite state automaton by replacing the edges of the flowchart with states and the symbols of the flowchart with transition conditions The next step is to transform the automaton into regular expressions This is done by writing down every path from the program start to the program termination as a regular expression All paths are concatenated to the regular expression representation of the program A few reductions on the regular expression lead to a minimal representation of the code which can then be transformed into the final program using loops instead of goto statements 2 3 3 Final comments on goto eliminations Goto eliminations are somehow complex program transformations But they are nevertheless an integral part of reverse engineering efforts in connection with legacy programs The above mentioned algorithms are based on theoretical work which is several decades old but is still present in research and practical work A current example of an implementation is the Reasoning Systems Refine tool 19 written in LISP and designed for removing goto s of COBOL source code Another example is a patch set for the McCAT C com
69. je ne die das nicht tun Studien zeigten dass der Bedarf f r Aspektorientierung oft erst bei der Weiterentwick lung von Softwaresystemen auftritt Neue Anforderun gen k nnen sich als Cross Cutting Concerns herausstel len In diesem Fall ist es g nstig Tools zur Verf gung zu haben die eine Erweiterung des bestehenden Quellco des um Aspekte erm glicht 7 So eignet AspectJ zum Beispiel um bestehende Java Programme um Aspekte zu erweitern weil alle g ltigen Java Programme auch g ltige AspectJ Programme sind Dadurch dass AOP zunehmend in der Lehre ver mittelt wird ist das Aspektorientierte Paradigma dabei die Objektorientierung als State of the Art abzul sen Literatur 1 AspectJ PARC Home Page http www parc com research projects aspectj default html 2 Introduction to AspectJ http www eclipse org aspectj doc released progguide starting aspectj html E W Dijkstra The structure of the THE multiprogramming system Commun ACM 11 5 341 346 1968 G Kiczales E Hilsdale J Hugunin M Kersten J Palm and W G Griswold An overview of AspectJ Lecture Notes in Computer Science 2072 327 355 2001 G Kiczales J Lamping A Menhdhekar C Maeda C Lopes J M Loingtier and J Irwin Aspect oriented programming In M Aksit and S Matsuoka editors Proceedings European Conference on Object Oriented Programming volume 1241 pages 220 242 Springer Verlag Berlin Heidelberg and New York
70. n Lrrormert Ra cca t Seen an OO mn eye Nemes Iterations Abb 2 Struktur des RUP Quelle 13 T tigkeiten Jeder Projektmitarbeiter schl pft in eine oder mehrere Rollen wodurch sich seine Verantwort lichkeiten im Projekt konzentrieren Die verschiedenen T tigkeiten Activities stellen wohldefinierte Arbeitseinheiten dar und werden von Mitarbeitern in deren Rollen durchgef hrt T tigkeiten haben das Ziel Artefakte zu erstellen Als Artefakt versteht man ein konkretes Ergebnis dass von einem oder mehreren Mitarbeitern produziert wird So ein Ergebnis ist beispielsweise die Realisierung eines Anwendungs falls Workflows Workflows definieren die Abfolge von verschiedenen T tigkeiten Ein Workflow kann somit als Partition von Rollen und T tigkeiten aufgefasst werden Im RUP existieren sechs Kernworkflows und drei unterst tzende Workflows Die Kernworkflows sind Business Modelling Requirements Analysis amp 10 UML Unified Modeling Language 74 Design Implementation Test und Deployment Bis auf den Deployment Workflow erstrecken sich alle Kernworkflows ber die gesamten vier Projektphasen Als unterst tzende Workflows nennt Kruchten Configuration and Change Management Project Management und Environment 11 Iterationen Eine Iteration fasst verschiedene Workflows zusammen und durchl uft die Prozessakti vit ten von der Anforderungsspezifikation bis zur Evaluierung Jede Iteration resul
71. nicht m glich ist Bei Fuzzy Systemen erh lt man durch das durchdachte Verwenden von nicht perfekten Informationen eine Reduktion der Komplexit t des Systems bereits w hrend der Modellierungsphase wobei es selbsterkl rlich ist dass zu grob formulierte Beschreibungen die wirkliche Welt wiederum falsch abbilden 1 2 1 Theorie der Fuzzy Mengen In der klassischen Mengenlehre ist ein Element in einer Menge entweder enthalten oder nicht M chte man nun etwa eine Menge mit Elementen f llen die alle eine angenehme Raumtemperatur ausweisen so ist es notwendig eine sprunghafte Grenze zwischen den Elementen die zur Menge geh ren und jenen die nicht dazu geh ren zu ziehen Sei etwa die Menge M definiert durch xl 20 lt x lt 24 wie Abbildung 1 veranschaulicht _ Zugeh rig keitsgrad oO C 24 20 Abbildung 1 Klassische Menge W hrend 20 Grad Celsius noch eine angenehme Raumtemperatur ist geh rt 19 9 Grad nicht mehr dieser Menge an und stellt somit eine unangenehme Raumtemperatur dar Der Mensch empfindet jedoch keine solchen abrupten Grenzen sondern eher flie ende Abgrenzungen welche man mit Fuzzy Mengen definieren kann wie man in Abbildung 2 erkennen kann IN o C 19 25 Abbildung 2 Fuzzy Menge Zugeh rig keitsgrad oO Im Gegensatz zu der klassischen Mengenlehre geh rt ein Element einer Fuzzy Menge dieser mit einem bestimmten Zugeh rigkeitsgrad blicherweise im Interva
72. nisse zu ermitteln Der Vorteil dieser Methode liegt in der schrittweisen Erstellung der Spezifikation Der Ansatz hat aber auch zwei gravierende Nachteile Zum einen ist der Prozess nicht sichtbar wodurch die Kontrollf higkeit f r die Gesch ftsf hrung nicht gegeben ist Zum anderen f hrt die Methode zu unstrukturierten Systemen vgl 5 pp 98 99 Entwicklung mit REUSE Heutige Systeme werden verst rkt durch wieder verwendete Komponenten erzeugt Nach Boehm steigt die Anzahl an LOCS in den Systemen gleichzeitig sinken aber die Kosten f r eine LOC 9 Es zeigt sich der Trend Software mit bestehenden oder angekauften COTS Komponenten zu erzeugen In den letzten Jahren hat sich f r diesen Prozess das CBSE entwickelt CBSE ist ein neuer Entwicklungsansatz der die Einbindung von Softwarekomponenten ber cksichtigt Das CBSE Prozessmodell unterscheidet sich von herk mmlichen Prozessmodellen wie beispielsweise dem Wasserfall modell in den Stufen zwischen Anforderungsspezifi kation und Systemvalidierung 5 Diese Zwischenstu fen sind nach 5 Analyse der Komponenten Anpassung der Anforderungen Systementwurf mit Wiederverwendung Entwicklung und Integration von COTS und eigenen Komponenten 2 2 Auszug klassischer Prozessmodelle Wasserfallmodell In der klassischen Ausf hrung ist das Wasserfallmodell ein rein phasenorientiertes Vorgehensmodell Durch die R ckw rtsverkettung der einzelnen Phasen bekommt es aber ei
73. nur ungenauen Beschreibungen der aktuellen Lage ausgehen Ungenau beschreibt hierbei ein Zustand bei welchem die Werte in einem Bereich liegen und nicht konkret angegeben werden k nnen siehe granulare Menge Um trotz die ser nat rlichsprachlichen Beschreibung des Systems zu mathematischen Modellen zu gelangen bedient man sich eben der verschwommenen Logik Fuzzy Logik Daher lautet nun die erste Aufgabenstellung bei der Anwendung der zuvor dargestellten Methode Compu ting with Words Die nat rlichsprachige Beschreibung muss in ein mathematisches Modell bergeleitet wer den In AI wird dazu oft ein Artificial Expert System ge baut Dieses System liegt jedoch dem menschlichen Denken zugrunde Die gleichen Funktionen die ein Experte vollziehen w rde wenn er das Problem h tte werden in einen Algorithmus implementiert Der Knowledge Engineer hat dabei die Aufgabe das Sys tem mit Hilfe eines Experten auf der If_Then Logik zu erstellen Dabei werden Regeln erstellt welche dann im Weiteren auf einem Computer implemetiert werden k nnen Fuzzy Logik stellt somit eine Methode dar um effizient verbale Sachverhalte zu verarbeiten Diese Schritte sollen nun im n chsten Kapitel durch direkten Einsatz erl utert werden Im Kapitel 3 1 wird zun chst der Erhalt der Membership Funktionen n her erkl rt Wenn man dies durchgef hrt hat so muss man f r das System Regeln erstellen was in Kapitel 3 2 durchgenommen wird In Kapitel 3
74. oder in gr erer Reich weite ergibt Man kann nun zwar aufgrund der Relati vierung der Abst nde im 1 Schritt keine konkreten Werte mehr ber die Entfernung von Martin und Peter liefern jedoch stellt dies eher das menschliche Denken dar als die Rechnung mit konkreten Werten 121 Wichtig bei Fuzzy Logik ist die Begrenzung der Variablenwerte durch die Bedingungen z B 0 lkm in der N he 2 5km in der Umgebung gt 5km weit weg In diesem Schritt wird also das Universum an Werten in kleinen Mengen unterteilt und nat rlich sprachlichen W rtern zugeteilt Dies hat zur Folge dass Fuzzy Logik durch die Einf hrung von Fuzzy Bedingungen in den Fuzzy Sets mehr zum menschli chen Denken r ckt als die Bool sche Logik welches ein Rechnen mit W rtern erm glicht Aufgrund dieser Granulation gibt es 2 wichtige Notwendigkeiten welche f r die Anwendung von Computing with Words gegeben sein m ssen e Die Anwendung muss einen bestimmten Grad von Unsch rfe zulassen e Die Anwendung hat als Ziel aufgrund dieser verschwommenen Logik die Lenkbarkeit Ro bustheit und die N he zur Realit t zu verbes sern Das System muss also zuerst mit bestimmten Vari ablen welche f r das Modell von Relevanz sind be schrieben werden Als n chster Schritt wird in einem bestimmten Wertebereich eine Granulation vorgenom men Jedem Bereich g wird dann ein Wort zugewiesen die Fuzzy Bedingungen Die Vorkenntnis des Sys tems sind
75. oder be schrieben wird Sie ist aber in modernen kurzen Ent wicklungszyklen nicht mehr wegzudenken Der separate Deployment Teil beinhaltet Administrationswerkzeuge f r den Datenbank sowie Webbereich ebenso wie die weit verbreitet eingesetzte Software Deployment L sung Tivoli 5 Lessons Learned W hrend im vorhergehenden Kapitel auf die offen sichtlichen Parallelen zwischen der Fuchu SWB und den beiden aktuellen Kandidaten eingegangen wurde folgen nun die detaillierten Vorteile die sich aus den Konzepten von Matsumoto ergeben 5 1 Prozess Beginnend bei dem straff strukturierten Prozess der Software Factory kann bereits bei dem Vergleich der abgebildeten Struktur Grafiken mit den eingangs beschriebenen einzelnen Phasen des Fuchu Prozesses eine Abbildbarkeit festgestellt werden Die Schritte Planning Requirements Analyse und Design Extended Design sowie Program Design k nnen in der Microsoft L sung bis auf den dokumentenorientierten Requirements Ansatz eindeutig abgebildet und somit die Design Baseline erreicht werden IBMs weitergehender Ansatz ist um die Requirements Analyse reicher und realisiert so den Schritt bis zur Design Baseline vollst ndig Die Product Baseline kann von beiden Tools in heutigem Rahmen ebenfalls erreicht werden Schwierig ist die Beurteilung ob der strikte als Konzept sehr interessante Customer Site Test toolunterst tzt ablaufen kann Matsumoto sieht in seiner SWB dies nicht explizit
76. ohne sich sowohl ber diesen Zeitraum entstandene Unterschie de wie auch Gemeinsamkeiten bewusst zu machen Die Softwarebranche hat als zugrundeliegende Basis Hardware die sich nach dem ber 50 Jahre alten aber immer noch g ltigen Moore schen Gesetz alle 2 Jahre in ihrer Komplexit t verdoppelt 4 Aus dieser Aus gangsposition muss als erstes Vergleichskriterium auch bei der darauf aufsetzenden Software Komplexit t als erster Ma stab herangezogen werden Programmier sprachen sind in gleichem Ma e komplexer geworden wie die darauf entwickelten Programme Das durch schnittliche Fuchu Programm bestand aus 4 Millionen EASL Equivalent Assembler Sourcelines was aufge rechnet auf die damals verwendete Haupt Programmiersprache Fortran ca 1 Million SLOC An nahme f r Fuchu 1 LOC Fortran 4 EASL und eine maximale Programmgr e von knapp 5 Millionen SLOC ergibt Gr ere heutige Programme k nnen als Beispiel mit 50 Windows 200 Debian GNU SLOC im Betriebssystembereich angenommen werden 5 Wir gehen hier zwar nicht mit Moores Gesetz kon form die Steigerung ist jedoch nicht zu bersehen Die Handhabung dieser gewachsenen Komplexit t nach den damals erhobenen Vorstellungen liegt aber unter Ber cksichtigung einer ebenfalls anzunehmenden Ver besserung der technischen Unterst tzung noch im Be reich des Durchf hrbaren Auch die Besch ftigungszahlen der Firmen k nnen als Ver nderungs Ma stab zum Vergleich
77. output though the output of the first program must have a structure recognizable by the second program It is important to note that the 41 programs involved do not have to know or care if they are currently used in a pipe Like described in chapter 2 2 2 programs can be written in a standard way of reading from a standard input and writing to a standard output all other functionality is provided through the file system or by the shell But pipes are more than only an abbreviation for program connection by I O redirection Programs in a pipe run concurrently so that PROGRAM could consume content and produce output while PROGRAM is still itself reading from its input see Listing 4 Since communication between the two programs is handled through a buffer and PROGRAM2 is emptying this buffer whilst PROGRAMI is still writing to it an infinite number of bytes can be sent between them In chapter 3 2 I am going to further investigate this concept of pipes which is believed to be one of the major milestones if not the major milestone achieved by UNIX 2 2 4 Command language The previous chapters showed some of the major features the shell has to offer The most important among them is the possibility to connect programs through a pipe see chapter 2 2 3 There is much more functionality in the shell however Actually it incorporates a command language that offers most of the functionality of fully fledged programming languages li
78. somit die Theoreme von welchen man in der Realit t ausgeht IDS Initial Data Set Diese Theore me stellen mehrere Sachverhalte dar Jedes Theorem kann in der Form X is R vorkom men Dabei ist X die Variable und R die dazugeh rige Relation Diese Eigenschaften stehen in der sog ED Explanatory Database Dabei gibt es noch keine Zu sammengeh rigkeit der einzelnen Werte es gibt also noch keine Relation Erst in der EDI ED instantiated sind die Verbindungen vorhanden Man kann also sa gen dass die ED mehrere m gliche Welten beschreibt hingegen bei einer EDI schon die genaue Welt be schrieben wird Wenn man nun also sagt Peter ist jung so besteht dieses Theorem aus mehreren Relationen welche in der EDI zu finden sind ED Bev l ker ung Peter Alter Jung Alter u Hierbei wird zuerst aus der Datenbank das Alter von Peter ermittelt Anschlie end kann mithilfe der Mem bership Funktion von jung errechnet werden wie stark Peters Alter der Funktion jung zugeh rt Diese Zugeh rigkeit wird durch u ausgedr ckt X Alter Peter pe Bev lk Name Peter X wird das Alter von Peter zugewiesen Alter Peter wandelt dabei das konkrete Alter von Peter in eine Fuzzy Bedingungen also jung um Es exisiteren jedoch auch Theoreme die von ande ren abh ngen Diese haben die Form Wenn x ist R dann y ist S Die vorher besprochenen Theoreme haben aller dings alle eine bestimmte Verbindung Wir
79. spe cification bezeichnet Anschlie end werden f r dieses In terface Input Werte ausgew hlt mit denen die Software Komponente ausgef hrt werden soll Ebenfalls werden vom Benutzer Output Werte definiert die bei Ausf hrung der Komponente erreicht werden m ssen 10 Der wichtigste Schritt ist die Suche in der Software Bibliothek alle durchsuchten Komponenten die die target interface specification erf llen kommen als m gliche wiederverwend baren Komponenten in Frage Dabei m ssen jedoch auch die Parametertypen und modi bereinstimmen 10 Anschlie end werden die ausgew hlten Komponenten auto matisch mit den Input Werten die der Benutzer definiert hat ausgef hrt und die entstandenen Output Werte mit den Benutzer Output Werten verglichen Jede Komponente die mit den Benutzerspezifikationen auf diese Weise berein stimmt wird dem Benutzer zur ckgeliefert 10 5 5 Kritische Anmerkung Kritisch anzumerken bzw zu hinterfragen sei ob die in der Arbeit diskutierten Ans tze und Technologien 1 4 10 13 das Klassifizierungs Problem geeignet l sen Dabei bleiben viele Fragen bez glich der Implementierung viele Ans tze definieren ausschlie lich die Beschreibung der Probleml sung jedoch keine konkrete Realisierung und den konkreten Ver wendungen dieser Klassifizierungs Schemata offen Weiters sei kritisch zu bemerken dass in den diskutieren L sungen 1 4 10 13 zumeist nur die Klassifizie
80. ssen Wildcards durch konkrete Werte ersetzt werden Query Erweiterung Um eine Query Erweiterung zu gew hrleisten st tzen sich Prieto Diaz und Freeman in 11 auf das Distanz Modell Liefert eine Query kein zufriedenstellendes Komponenten Suchergebnis wird der azyklische ge richtete Graph herangezogen um den hnlichsten Be griff der aktuellen Facetten Beschreibung zu ermitteln Wurde eine Query erfolgreich ausgef hrt gehen Prieto Diaz und Freeman in 11 wie bereits erw hnt davon aus dass das Library System sehr gro ist st ndig anw chst und sehr viele hnliche Komponenten beinhaltet Aus diesem Grund ist die Wahrscheinlichkeit eines exakten Suchtreffers gering Um aus der erhaltenen Liste von Suchergebnissen die pas sendste Komponente auszuw hlen wird ein Evaluierungs Mechanismus ben tigt Dieser baut auf den folgenden At tributen die eine Software Komponente im Library System zus tzlich beschreiben auf 11 e Gr e e Simplizit t e Dokumentation e Programmiersprache in der die Komponente imple mentiert wurde Die Software Komponente die diese vier Attribute am bes ten erf llt sollte f r den Reuse ausgew hlt werden 5 AUFBAUENDE ANS TZE UND MODER NE TECHNOLOGIEN Im bisherigen Teil des Artikels wurde die Klassifizierung von Software Komponenten um diese wiederzuverwenden durch die Erkl rung von Software Reuse und dessen Pro blembeschreibung motiviert Anschlie end wurde das facet
81. step the program is written without goto s and with structure in 17 mind even if this would be inefficient Afterwards the well documented and well understood code should be automatically transformed into a more efficient variation using goto s if appropriate The resulting code might not be too readable but that won t matter because the original source will be used to refine or explain the program This shall be the starting point of my analysis of how the use of goto statements developed over time and it has to be said that this discussion very controversial A long time has passed since the arguments about goto statements were laid to rest but it definitely had an impact on the use of goto statements and the design of programming languages One effect was the omitting of goto s in several programming languages e g Modula 2 Oberon Java Python and others As a note on the side Java 1 5 does not provide the functionality of a goto command but the keyword goto is reserved The above mentioned languages are all known to be part of the imperative programming language paradigm Another paradigm of programming languages known as functional or logical languages do lack goto s overall Yet another effect of the goto discussion was the development of several unconditional branching constructs with limited scopes like break continue and return In contrast there are still a few programming languages that provide goto s e g C C C
82. t teure Middleware und speziell abgestimmte gut implementierte Prozesse machen die Konstruktion und den effektiven Einsatz dieser Tech nologie erst m glich Referenzen 1 Alvaro A Santana de Almeida E Romero de Lemos Meira S Software Component Certification A Sur vey euromicro 2005 pp 106 113 2 Andreou A S Tziakouris M A quality framework for developing and evaluating original software components Inf Softw Technol 49 2 Feb 2007 pp 122 141 3 Bachmann F et al Volume II Technical Concepts of Component Based Software Engineering Technical Report Software Engineering Institute SEI May 2000 pp 65 4 Bertoa M F Vallecillo A Quality attributes for cots components in Proceedings of the 6th ECOOP Workshop on Quantitative Approaches in Object Oriented Software Engi neering QAOOSE 2002 5 Boegh J Certifying Software Component Attributes IEEE Software 23 3 May 2006 pp 74 81 6 Brereton P et al Software Components Enabling a Mass Market In Proceedings of the 10th international Workshop on Software Technology and Engineering Prac tice IEEE Computer Society Washington DC 2002 7 Broy M et al What characterizes a software compo nent Software Concepts and Tools 19 1 1998 pp 49 56 8 Buchi M Weck W The Greybox Approach When Blackbox Specifications Hide Too Much Technical Report UMI Order Number TUCS TR 297 Turku Centre for Com puter Sc
83. the data is stored programs only see an unformatted sequence of bytes e dynamic growth of files file size is only limited by the available storage space e the treatment of directories as special files directories can be read like any other file e the treatment of peripheral devices such as terminals as files 1 All of these characteristics have a great effect on the ease of development with the file system but the last one is the most interesting This idea allows access to peripheral devices with the same programming interface which is also used for regular files Actually the semantics for reading and writing from to a device are the same as for a regular file So in the implementation of most programs no distinction between these two cases has to be made This leads to a very uniform view on the underlying system which greatly alleviates the development of programs and supports some new concepts as is shown further down 2 2 The command interpreter The second factor that according to Kernighan and Mashey 2 led to the widespread use of UNIX is its very powerful command interpreter the shell It does not only allow easy execution of programs but it also 40 introduced some interesting concepts which are discussed in this chapter The shell itself is a user program and enjoys no special system privileges 5 This allows easy adaptation of the shell itself to meet particular requirements that may be imposed by a c
84. tion abh ngen je n her man der Maschinensprache kommt desto eher findet man gotos Auf der niedrigs ten Ebene werden auch die Basisblocks durch bedingte und unbedingte Spr nge im Maschinencode dargestellt Man sollte sie jedoch in h heren Programmiersprachen nicht direkt verwenden 04 An dieser Entwicklung kann man erkennen dass sich die grunds tzliche Aufgabe die ein Programmierer 12 bei seiner Arbeit zu bew ltigen hat mit der Zeit grund legend ver ndert hat Fr her wurden teure Gro rechner mit Programmen gef ttert welche m glichst ideal auf alle Gegebenheiten abgestimmt waren Die Maschine wurde bis ins letzte ausgereizt Bei jeder Variablen wurde um Bits gefeilscht und versucht sie m glichst h ufig im Programm irgendwo zu verwenden Mittler weile versucht man eher eine Programmiersprache dazu zu nutzen um komplexe Systeme zu generieren Deshalb unterscheidet man heute auch zwischen co ding der reinen systemnahen Produktion von Pro grammcode und programming dem systematischen Erarbeiten von Algorithmen Dass dieser Unterschied auch f r das Erlernen von strukturierter Programmie rung eine zentrale Rolle spielt wird in einem sp teren Kapitel im Detail beleuchtet 01 3 Vorteile und Nachteile von strukturierter Programmierung Im Folgenden m chte ich aufzeigen was strukturier te Programmierung bringen kann wenn diese Technik vern nftig eingesetzt wird Dazu werden die einzelnen V
85. und Abstrakionsmechanismen um gro e Modelle strukturieren zu k nnen Informale Notationen sind nat rlichsprachiger Text oder einfache Graphen beides mit minimaler Syntax keiner Ontologie und keiner n heren Semantik Trotz dem sind sie ein wichtiger Part der Anforderungsanaly se weil sie aus der Interaktion mit dem Kunden her vorgehen und somit die eigentliche Wissensansamm lung darstellen 11 2 2 Geschichte der Informationsmodelle ber die Jahre hinweg wurden die Informationsmodel le in 3 verschiedene Kategorien klassifiziert Diese reflektieren eine historische Entwicklung weg von maschinenorientierten Repr sentationen hinzu zu den menschorientierten Modellen die ausdrucksst rker sind und mit komplexen Anwendungsmodellierungs aufgaben besser zurecht kommen Die drei Kategorien sind Physische Informationsmodelle diese Mo delle benutzen konventionelle Datenstruktu ren und andere Programmierkonstrukte um eine Anwendung zu modellieren Der gro e Nachteil dieser Modelle war der Konflikt zwi schen Recheneffizienz einerseits und der Qua lit t der Modellierung andererseits Logische Informationsmodelle verwendet abstrakte mathematische Formelstrukturen um Implementationsdetails vom Benutzer zu ver bergen Konzeptuelle Informationsmodelle bietet ausdrucksst rkere M glichkeiten um An wendungen zu modellieren und Informationen zu strukturieren Als Beispiele seien semanti sche Ausdr cke wie Entity
86. vor der Customer Site Test ist aber integraler Bestandteil seines Prozesses Vergleichbar hiermit ist eine tats chliche Simulationsumgebung die IBM ausgereift f r eine Vielzahl von unterschiedlichen Bereichen zur Verf gung stellt Microsoft zumindest in den Kernbereichen Web Anwendungen und Windows Anwendungen auf niedrigem Level parametrisierbar anbietet Die IBM L sung ist dabei durchaus als Fortschritt anzusehen Die Auslieferung hat im Rahmen der integrierten Suite nur IBM umgesetzt Microsoft verwendet zwar einheitliche Standards MSI Pakete Microsoft SMS Server hat diese jedoch nicht als vollst ndig durchg ngiges Konzept in seinem Toolkit integriert Die Operational Baseline wird von beiden vorge stellten Produkten nicht erreicht Weder das Zusam menspiel im Echtbetrieb noch der eigentliche Vor Ort Test werden von den Tools unterst tzt Die M glich keit zur Unterst tzung w re im stark dokumentenge triebenen Ansatz von Matsumoto zu sehen der aber generell in den heutigen Tools eher zur ckgestellt be handelt wird IBM spezifiziert Dokumentenverwaltung und Erstellung lediglich im Requirements Bereich in Microsoft fehlt die zugeh rige Verwaltung vollst ndig Es wird davon ausgegangen dass im Filesystem ent 52 sprechende Hierarchien zur strukturierten Ablage exis tieren geschaffen werden oder die Aufgabe an Doku menten Management Systeme bertragen wird Eine entwicklungsorientierte dokumentenba
87. vorherzusagen sind Die Artefakte werden nachtr glich aus den Produkten erstellt Hohe Kosten k nnen dann entstehen wenn die Architektur angepasst werden muss Der extrahierende Ansatz wird eingesetzt wenn schon Alt Systeme bestehen Aus diesen Systemen werden die Artefakte extrahiert und f r neue Systemvarianten zu Verf gung gestellt Eingesetzt wird diese Vorgehensweise bei Unternehmen die von einer herk mmlichen Entwicklungsstrategie auf Produktlinien umstellen Bei der organisatorischen Strategie der Artefaktentwicklung werden der zentrale und verteilte Ansatz unterschieden 12 Beim zentralen Ansatz gibt es eine organisatorische Einheit die die Artefaktentwicklung betreibt Der Vorteil ist dass die Artefaktbasis einfacher koordiniert werden kann Der Nachteil besteht in dem h heren Kommunikationsaufwand mit den Experten der Produktentwicklung Beim verteilten Ansatz bernehmen die einzelnen Projekte der Produktentwicklung auch die Artefaktentwicklung Was der Vorteil der Koordination bei dem zentralen Ansatz ist zeigt sich hier als Nachteil und umgekehrt SEI hat noch weitere Aktivit ten in Form von Practice Areas definiert die die 3 grundlegenden Aktivit ten unterst tzen bzw genauer definieren Es sind 29 Areas die in 3 Kategorien Software Engineering technisches Management und organisatorisches Management unterteilt sind 15 Beispiele f r Areas in der Kategorie Software Engineering sind Anfor
88. werden bevor das eigentliche Modul entwickelt wird Die TDD Technik hat den Vorteil dass sich der Entwickler im Vorhinein Gedanken ber die Funktionalit t des Moduls macht und durch den Unit Test sofortiges Feedback bekommt Dadurch werden Fehler fr hzeitig entdeckt und eliminiert Laut Boehm ist dies essentiell um Kosten zu sparen Beim Wasserfallmodell finden die Tests erst nach der Implementierung statt 1 Dadurch werden 40 50 der Entwicklungskosten f r die Nachbearbeitung des Codes geschluckt 1 Werkzeuge wie beispielsweise JUnit unterst tzen die Testaktivit ten Neben den Unit Tests finden in XP noch die Akzeptanztests statt bei welchen das Endprodukt vom Kunden auf Funktionalit t gepr ft wird Rollen in XP Im Prozessmodell wird eine Reihe von Rollen definiert um die Verantwortlichkeit der Mitarbeiter im Projekt zu konzentrieren Damit wird verhindert dass Entscheidungen von nicht qualifizier ten Personen getroffen werden Wie bereits einleitend hervorgeht tragen der Programmierer und der Kunde die wichtigsten Rollen in einem XP Projekt Neben diesen beiden gibt es noch den XP Trainer den Projektleiter den Technologieberater den Tester und den Tracker F r Details zu den einzelnen Personenrol len sei auf 17 18 verwiesen Einschr nkungen von XP eXtreme Programming kann nicht bei jedem Projekt eingesetzt werden Es setzt voraus dass es sich beim Entwicklerteam um u erst erfahrene Personen handel
89. werden k nnen bzw mittels Code Generatoren in Applikationen transformiert werden Vergleichbar mit jetzigen GL Sprachen die mit Hilfe eines Compilers in Maschinencode bersetzt werden Der Abstraktionslevel wird dadurch erh ht und man arbeitet n her an der Problemdefinition Ein immenser Vorteil w re dass auch Dom nen Experten ohne Programmierkenntnisse Systeme erstellen k nnten da sie nur mit den Objekten und Aktionen ihrer Dom ne arbeiten Modelle wurden schon fr her als Dokumentation und Visualisierung f r ein leichteres Verst ndnis eingesetzt Beispiele f r visuelle Modelle sind UML oder SASD Von diesen Modellen aus kann auch eingeschr nkt Code erzeugt werden Diese Modelle basieren aber auf Konzepten von Programmiersprachen und kennen die spezifischen Konzepte einer Produktfamilie nicht bzw nur in Form von Namenskonventionen oder Stereotypen 18 Auch Codegenerierung und very high languages sind kein neues Konzept aber durch hohe Anfangskosten und wenig unterst tzende Tools haben sich diese Konzepte um 1990 noch nicht durchgesetzt 19 Erst ab dem Jahr 2000 wurden konkrete Bestrebungen und Toolunterst tzungen sichtbar Domain Specific Languages DSL Dom nen spezifische Sprachen und Metamodelle Einem Modell liegt eine dom nenspezifische Sprache DSML oder nur DSL zugrunde Sie bieten Notationen und Konstrukte in einer eingeschr nkten Dom ne Sie bieten st rkere Ausdruckskraft und 108 e
90. 3 1 Abstraktionsmechanismen Abstraktionsmechanismen sind beschreibende Einrich tungen die es erlauben bestimmte Informationen zu inkludieren w hrend wiederum andere in diesem Level weniger wichtige Informationen Design und Implementierungsdetails vernachl ssigt werden k n nen In RML kommen die Mechanismen Aggregation Ge neralisation und Klassifikation zum Einsatz Die Ag gregation erlaubt es Entit ten als Zusammensetzung von Komponenten zu sehen Die Klassifikation erlaubt gemeinsame Charakteristiken von Entit ten innerhalb einer Klasse Individuelle Unterschiede werden da bei ignoriert Durch die Generalisation wird die Ein f hrung von Subklassen erm glicht die die Eigen schaften der Oberklasse erben 3 2 Die Features von RML In RML werden die Objekte der echten Welt mittels der drei Einheiten dargestellt den Entit ten Aktivit ten und Behauptungen Das Prinzip des RML besteht jetzt darin die oben genannten Abstraktionstechniken uniform auf alle drei Einheiten anzuwenden 5 Das bedeutet dass es Klassen f r Entit ten Aktivit ten und Behauptungen gibt Jede dieser Klassen kann aus ande ren Klassen einer anderen Einheit zusammengesetzt sein Organisiert sind die Klassen einer Einheit durch die Anwendung der Generalisation bzw Spezialisie rung 1 Klassen und Metaklasseneigenschaften werden durch so genannte definitorische Eigenschaften beschrieben die spezifizieren welche Art Infor
91. 3 3 Agile Softwareentwicklung Agile Softwareentwicklung hat sich in den letzten Jahren mehr und mehr durchgesetzt Der Aufwand ist meist gering und unb rokratisch Wenige einfache Regeln erleichtern den Einstieg Ein Beispiel hierf r ist Extreme Programming auf das ich nicht im Ganzen eingehen m chte sondern nur auf den Teil des Pair Programmings Pair Programming bedeutet dass zwei Personen an einem Bildschirm arbeiten Durch dieses Vier Augen Prinzip wird der Code gleichzeitig geschrieben und gepr ft Fehler k nnen sofort besprochen und ausgebessert werden Die vermeintlich h here Softwarequalit t aus dieser Methode wird in A multiple case study on the impact of pair programming on product quality diskutiert 11 Darin werden vier Softwareprojekte gegen bergestellt die jeweils alleine und mit Zweier Teams entwickelt wurden Dabei ist deutlich zu sehen dass Paarprogrammierung bei der Produktivit t der Einhaltung der Codestandards der kommentierten Bereiche Anzahl und Qualit t und Softwarequalit t stets vor der Einzelprogrammierung liegt Zum Teil liegt die Anzahl der Fehler bei Soloprogrammierern beim sechsfachen Wert Im Gegensatz dazu werden einfache Programmteile alleine schneller und effektiver bew ltigt Komplexe Teile werden von Paarprogrammierern bis zu doppelt so schnell abgehandelt Die Studie kommt zu dem Schluss dass gerade in der Anfangszeit eines Projekts die Paarprogrammierung von Vorteil ist Zu zwe
92. 5 Architectural Patterns Wintersemester 2004 2005 Klagenfurt 2004 Mcllroy M D Mass Produced Software Components NATO Software Engineering Conference Report Garmisch October 1968 pp 79 85 Mili H Mili F and Mili A Reusing Software Issues in Research Directions IEEE Trans Software Engineering Volume 6 No 6 June 1995 pp 528 562 16 Meyer B On to Components IEEE Computer Volume 32 No 1 January 1999 pp 139 143 17 Szyperski C Component Software Beyond Object Oriented Programming 2 edition Addison Wesley Professional Boston 2002 46 Software Factory An Overall Approach to Software Production Michael Prodnik 0360541 mprodnik edu uni klu ac at Abstract Der Artikel A Software Factory An Overall Ap proach to Software Production steht als ein Klassiker der IT Literatur au er Zweifel Die daraus entstande nen Ideen und darin angef hrten bereits seit 1987 g ltigen Grunds tze sind auch heute 20 Jahre sp ter noch genauso aktuell Unter den zahlreichen beschrie benen Aspekten der Fuchu Factory k nnen besonders die von Matsumoto herausgehobenen Faktoren der Effektivit tssteigerung durch ein strukturiertes Reuse Konzept und entsprechende Toolunterst tzung gut in die Neuzeit verfolgt werden Die Unterschiede der derzeit vorhandenen Gege benheiten zu den damaligen Vorraussetzungen schaf fen durch einen Vergleich von aktuellen Tools und Reuse Konzepten mit den von Ma
93. 85 11 Weiner L H 1978 The roots of structured program ming In Papers of the SIGCSE CSA Technical Symposium on Computer Science Education Detroit Michigan Febru ary 23 24 1978 ACM Press New York NY 243 254 Sekund rliteratur 12 Bates D 1976 Structured Programming Infotech State of the Art Report Infotech International Limited Maiden head England 13 Mills H D Top Down Programming in Large Sys tems In Debugging Techniques in Large Systems B Rustin Ed Prentice Hall 1971 in 11 14 Mills H D Mathematical Foundations for Structured Programming In JBM Report FSC 72 6013 1972 in 11 Internetquellen http en wikipedia org wiki Structured_programming zuletzt besucht 18 Mai 2007 7 Acknowledgment Abschlie end m chte ich allen Reviewern danken die durch ihre Hinweise sehr zur Qualit t dieser Arbeit beigetragen haben Are goto s don t do s Ingomar Preiml 0260592 ipreiml edu uni klu ac at Abstract The discussion about the use of goto s in programming languages is quite old It had its peak with Dijkstra s well known arguments against goto statements 1 At a later point Knuth 2 discussed this issue with different points of view in order to ease the discussion A question that is going to be answered is how the goto discussion had an influence on the use of goto s and on other programming constructs over time Additionally a few contemporary ways of how goto sta
94. AN with IFTRAN In Proceedings of the Fifth SIGCSE Technical Symposium on Computer Science Education D T Bonnette Ed SIGCSE 75 ACM Press New York NY 196 199 03 B hm C and Jacopini G 1979 Flow diagrams Turing machines and languages with only two formation rules In Classics in Software Engineering E N Yourdon Ed ACM Classic Books Series Yourdon Press Upper Saddle River NJ 11 25 04 Creak A 2003 Everything is Fortran in its own way SIGPLAN Not 38 4 Apr 2003 7 12 05 Dijkstra E 1979 Go to statement considered harmful In Classics in Software Engineering E N Yourdon Ed ACM Classic Books Series Yourdon Press Upper Saddle River NJ 27 33 06 Dijkstra E 1979 The humble programmer In Classics in Software Engineering E N Yourdon Ed ACM Classic Books Series Yourdon Press Upper Saddle River NJ 111 125 07 McCracken D 1979 Revolution in programming an overview In Classics in Software Engineering E N Your 16 don Ed ACM Classic Books Series Yourdon Press Upper Saddle River NJ 173 177 08 Schrage J F 1980 Educator s view of structured con cepts In Proceedings of the ACM 1980 Annual Conference ACM 80 ACM Press New York NY 327 341 09 Tomayko J E 1990 Anecdotes IEEE Ann Hist Com put 12 4 Oct 1990 269 276 10 Watts T 2004 The SFC editor a graphical tool for algorithm development J Comput Small Coll 20 2 Dec 2004 73
95. Anforde rungsanalyse und Dokumentation der den Teamfaktor durch Kommunikationsfunktionen st tzt Verglichen mit der entsprechenden Komponente SWB III finden sich klar die Funktionen wieder Der Fokus in der De signphase liegt einerseits bedingt durch die Orientie rung moderner Softwareentwicklung an Gesch ftspro zessen und gro en Workflowsystemen SAP Oracle sehr stark auf Richtung Business Process Modelling andererseits ist der Applikations Designbereich auf grund der Programmiersprachenvielfalt des anzuspre chenden Publikums enorm gewachsen In der Praxis und zum Vergleichszweck kann aber im Applikations Design nur das entsprechende f r die Sprache zu ver wendende Tool angef hrt werden Der SWB III Funk tion Performance Evaluation k nnen im Produkt von IBM ebenfalls M glichkeiten zu Performance Einsch tzungen insbesondere bei unterschiedlichen Systembelastungen gegen ber gestellt werden Das CASAD Computer aided specification analysis and documentation system als alle Sichten vereini gendes Programm zur Dokumentenerstellung findet sich jedoch in solcher Form heute nicht wieder Es kann hier am ehesten noch mit dem UML Modellierungstool verglichen werden Die Sichtweise ist hier jedoch nicht so generalisiert m glich wie im CASAD Ansatz 51 Architekt Entwickler Tester Applikations Analyse Load Designer dyn Code Tests System Analyse handische Des
96. CORBA 3 0 Spezifikation Erweiterungen f r die Un terst tzung von Komponenten anstrengte Das dabei entstandene CCM CORBA Component Model er m glicht es Anwendungsentwicklern Komponenten auf Basis gew hnlicher CORBA Dienste zu implemen tieren konfigurieren verwalten und einzusetzen CCM bietet vier verschiedene Mechanismen Ports an um Interaktion zwischen Komponenten zu erleichtern 30 e Facets Geben an welche Schnittstellen von der Komponente zur Verf gung gestellt werden So mit ist es m glich unterschiedliche Sichten auf die Komponente zu erhalten e Receptacles Damit werden Referenzen zu ande ren Komponenten bezeichnet Die Receptacles stellen die Verbindung zwischen den Komponen ten sicher e Event sources sinks Diese Ports erm glichen eventbasierte asynchrone Kommunikation e Attributes Dieser Mechanismus wird zur Konfi guration der Komponente genutzt CCM erm glich dadurch plattform und program miersprachenunabh ngige Kommunikation basierend auf der darunter liegenden CORBA Architektur Das Modelldesign von CCM lehnt sich stark an das von Sun entwickelte Komponentenmodell EJB Enterprise Ja vaBeans an wodurch unter anderem Interoperabilit t zu EJB erlangt wird EJB Anders als CORBA ist das auf Java Technologie basierende Komponentenmodell von Sun zwar plattformunabh ngig aber nicht sprachenunab h ngig Das Konzept dieses Komponentenmodells ba siert auf einer offenen Spezifikation des Java
97. Code f hrten zu kostenineffizienten Produktionen von Software Um deren Entwicklung zu verbessern sponserte das NATO SCIENCE COMITTE 1968 in Garmisch eine Konferenz Sie war die Geburtsstunde des Terminus _ Software Engineering und behandelte Standardisierungen f r Design und Produktion 3 Bis heute besteht die Schwierigkeit zuverl ssige Softwaresysteme termingerecht und kosteneffizient zu erzeugen Laut CHAOS Report 1994 2002 2004 der Standish Group werden im Mittel nach wie vor 74 der Projekte nicht erfolgreich abgeschlossen Davon berschreiten 52 den Zeit und Budgetrahmen 22 werden fr hzeitig abgebrochen und lediglich 26 der Projekte schlie en zufrieden stellend ab 7 8 Boehm 71 bekr ftigt aber dass der Grund f r einen Projektab bruch nicht ausschlie lich am schlechten Projektmana gement liegt 21 Vielmehr f hren Gr nde wie schlechte oder unvollst ndige Anforderungen mangelnde Planung oder Wirtschaftlichkeitsfaktoren zu einem Projektabbruch Die n chterne Statistik verdeutlicht wie notwendig es ist Softwareentwick lung diszipliniert und mit klaren Vorgehensweisen zu betreiben m Erfolgreich m Kosten Zeit berschreitung D Abbruch 2 8 z amp 0 20 40 60 80 100 Abb 1 CHAOS Report 1994 2002 2004 Datenquelle 7 8 Software Engineering kann als geschichtete Technologie aufgefasst werden und gliedert sich i
98. Ein Qualit tsmodell definie ren sie wie folgt A Quality model is the set of characteristics and sub characteristics as well as the relationships between them that provide the basis for specify ing quality requirements and for evaluating quality 4 Die Benennung der Charakteristika bernehmen sie aus dem ISO 9126 Modell weisen diesen aber eine neue Bedeutung zu Die Unterkriterien teilen sie in zwei Ka tegorien ein Zum einen Laufzeit Kriterien welche w hrend der Ausf hrung der Komponente beobachtet werden k nnen und zum anderen die Lebenszyklus Kriterien sie k nnen w hrend des Lebenszykluspro zesses beurteilt werden Jedem dieser Unterkriterien werden nun messbare Attribute zugeteilt Entscheidend ist dass Attribute gemessen werden k nnen denn nur so k nnen Vergleiche zwischen Komponenten sicher gestellt werden Ein allgemein g ltiges Qualit tsmodell am Markt zu etablieren sehen die Autoren als schwie rig an Es kann nicht davon ausgegangen werden dass Anbieter von COTS Komponenten aus Gr nden des Images Marketings oder anderen kommerziellen Ver anlassungen auch negative Qualit tskriterien angeben werden 4 Daher wird ein Vergleich immer mit Schwierigkeiten behaftet bleiben Einen hnlichen An satz stellt 2 vor Ebenso auf ISO 9126 aufbauend entwickelten diese Wissenschaftler ein Qualit tsfra mework nicht speziell f r COTS Komponenten son dern f r kleinere wie die Autoren es nennen origi
99. Enterpri se Edition Servers des EJB Containers und verschie dener Komponenten in diesem Modell als Beans be zeichnet sowie dem Zusammenspiel dieser Einheiten Der Container l uft serverseitig als Laufzeitumgebung f r Beans Er berwacht und steuert den Lebenszyklus von Beans versorgt diese mit diversen Umgebungsin formationen und bietet Dienste wie Transaktionskont rolle Sicherheitsfunktionalit t Namens und Verzeich nisdienst sowie einen Nachrichtendienst an Beans k nnen diese Dienste in Anspruch nehmen Je nach Aufgabengebiet unterscheidet man bei Enterprise Be ans zwischen drei Typen 27 e Session Beans Kapseln die Gesch ftslogik und stellen Dienste hierfiir bereit e Entity Beans Diese Beans repr sentieren Daten s tze einer Datenbank werden aber durch die Einf hrung der Persistenz API in Java EE 5 zu nehmend an Bedeutung verlieren e Message Driven Beans Sie stellen eine asynch rone Kommunikation zwischen den Beans bereit Der am h ufigsten genannte Kritikpunkt dieses Mo dells ist die hohe Komplexit t Mit der k rzlich er schienenen EJB Spezifikation 3 0 m chte Sun dieser Kritik begegnen Wichtigste Neuerung ist ein Meta sprachkonzept Annotations welches die Aufgaben der Entwickler vereinfachen soll Ziel ist es die Anzahl der zu implementierenden Klassen und Schnittstellen 59 zu verringern Ebenso sind Vereinfachungen im Um gang mit den einzelnen Beans Typen Teil der neuen Spezifikation 15
100. Entwicklungswerkzeugen von verschiedenen Herstellern und die Portabilt t wel che ein Plattformunabh ngigkeit mit sich bringt 3 3 Der Ansatz Modellierung ist kein neuer Ansatz und wird vor allem in den schwergewichtigen Entwicklungsprozessen verwendet um die innere Struktur zu dokumentieren Konsistenzproblemen welche zwansgsl ufig eintreten wird in den Prozessmodel len mit Reviews etcetera entgegen gewirkt 11 Beim Roundtrip bzw Reverseengineering welches bereits in etliche Lifecycle Entwicklungsumgebungen Einzug gefun den hat entstehen diese Konsistenzprobleme nicht Hierbei handelt es sich aber lediglich um Visualisierung des Source codes mittels UML z B Daraus ergibt sich der Umstand 8Die OMG ist ein weltweit offenens Konsortium welches aus mehr als 800 Mitgliedern besteht Bekannst ist sie z B f r UML Unified Modeling Language CORBA Common Object Request Broker Language und IDL MOF Meta Object Facility und XMI dass beide Sichten sich auf dem selben Abstraktionsniveau befinden im starken Gegensatz zu MDSD 11 Auf dem Niveau von Programmiersprachen sind Architek turmerkmale und Konstruktionsparadigmen oft nur noch schwer als solche zu erkennen da das Abstraktionsniveau ein viel niedrigeres ist Die Struktur liegt dadurch teilweise in verschleierter Form vor und ist nur mit Hilfe der Doku mentation nachvollziehbar 11 In der modellgetriebenen Softwareentwicklung wird durch abstrakt
101. Es stehen viele Methoden zur Verf gung um die Werte wieder zur ck zu rechnen denn das Bremssys tem kann nicht mit dem Wert 0 8 stark bremsen COA bedeutet Center of Array Dazu bindet man die Ergebnisse wieder in die Graphik ein Der Mittel punkt der sich ergebenden Fl che bildet den gesuchten Bremswert MoM Mean of Maximum verwendet hingegen den vereinfachten Algorithmus Hierbei wird lediglich die Mitte des Maximums verwendet siehe Abbildung 12 Neben diesen Methoden gibt es noch CoM Center of Maximum und andere Weitergehende Informatio nen sind in 13 zu finden 4 5 Ergebnis Bremsvorgang Es soll nun f r die folgende Situation die Brems kraft ermittelt werden Die Geschwindigkeit betr gt 45km h und der Abstand 30m Fuzzyfiziert ergibt f r 45km h einen Wert von klein 0 5 mittel 0 5 und gro 0 Dieselbe Prozedur muss f r den Abstand durchgef hrt werden klein 0 5 mittel 0 25 und hoch 0 laut Abb 8 und 9 Bildet man aufgrund des Expertenwissen die Bremswirkung ergeben sich mehrere Ergebnisse f r mittel Abb 11 Die Regel lautet nach Max Min Inferenz Die Ter me selbst m ssen mit dem Min Operator behandelt werden Die Ergebnisse in derselben Gruppe m ssen untereinander mit dem Max Operator verkn pft wer den Also berpr fen wir zuerst klein x klein Dies er gibt die Bremswirkung stark 0 5 MIN 0 5 ergibt 0 5 Also haben wir zuerst stark 0 5 Diesen Vorgang wie derholen wir f r alle Kombinationen
102. Faktoren ab Sie sollte jedoch nie l nger als zwei Stunden andauern da die Konzentration nach dieser Zeitspanne stark sinkt Es gibt einige Abbruchkriterien oder F lle in denen keine Inspektion stattfinden sollte e Es werden zu viele Fehler gefunden Typischerweise gibt es in Unternehmen Richtlinien die die Anzahl der gefundenen Fehler in einer Inspektion festlegen Die Grenze sollte hoch aber nicht unerreichbar sein Das Inspektionsteam ist schlie lich nicht f r Debugging zust ndig 89 e Nicht alle Mitglieder sind erschienen Jedes Teammitglied hat seine stark spezialisierte Funktion Durch ein Fehlen k nnen mitunter Fehler bersehen beziehungsweise Teile eines Dokuments nicht richtig wiedergegeben werden Es ist besser ein Meeting ganz ausfallen zu lassen bevor es nur zu Teilen stattfindet e Mangelnde Vorbereitung 75 der gefundenen Fehler in einer Inspektion werden durch individuelle Vorbereitungen bereits gefunden 8 Der Moderator sollte daher am Anfang jeder Sitzung die Vorbereitungszeiten der anderen Mitglieder erfragen Er sollte dann abw gen ob die Sitzung nicht wegen mangelnder Vorbereitung verschoben werden sollte e Nicht alle Fehler der letzten Sitzung wurden verbessert Es hat keinen Sinn wertvolle Ressourcen in ein Meeting zu stecken dessen Inhalte noch nicht vollst ndig verbessert wurden Inspektionen sind teuer Die Verbesserung einer nicht fertigen Sache hat keinen Sinn Ein wichtiger Faktor be
103. Logik dem Computer unscharfe Informationen zu verwerten Besonders amerikanische aber auch viele europ ische Wissenschaftler und Forscher ignorierten anfangs diese neue Theorie Auf der einen Seite lag dies daran dass der Name irref hrend gew hlt war was zur Folge hatte dass viele Wissenschaftler dachten Fuzzy Logik w rde die Pr zision aus der Wissenschaft nehmen Auf der anderen Seite war diese Theorie auch sehr provokant Viele Wissenschaftler dachten Fuzzy Logik w rde unter anderem besagen dass die konventionelle bivalente Logik auf der praktisch ein Gro teil der Wissenschaft aufbaut falsch ist Der Universit tskollege und auch guter Freund William Kahan von Lotfi Zadeh hielt absolut nichts von der Fuzzy Logik Theorie was er 1975 ein Jahr nach der Implementierung der ersten Anwendung sehr provokant aussprach Fuzzy theory is wrong wrong and pernicious I can not think of any problem that could not be solved better by ordinary logic Jedoch wurde Fuzzy Logik von den Wissenschaftlern aus Asien allen voran Japan und China akzeptiert was definitiv zu einem Teil auf die damalige Vormachtstellung der Japaner im Bereich der Halbleitertechnologie und Mikrorechner zur ckzuf hren ist Ein weiteres Argument ist jedoch auch die asiatische Betrachtungsweise die im Gegenteil zur westlichen Tradition in der Unsch rfe nichts Verwerfliches sieht 1 9 3 2 Weitere Entwicklung von Fuzzy Logik In der Anfangsze
104. Methode in einer vern nftigen Zeitspanne auf ein optimales Ergebnis kommt Eine sehr gute Einf hrung in evolution re Algorithmen in Verbindung mit Fuzzy Logik kann man in 6 finden Den Sammelbegriff von Fuzzy Logik evolution re Algorithmen und k nstliche neuronale Netze sind unter Soft Computing bekannt Weiters sind dies Konzepte die h ufig im Bereich der k nstlichen Intelligenz angewendet werden So ist es mit Neuro Fuzzy Systemen m glich dass mobile Roboter lernen k nnen wo sich welche Hindernisse befinden um Kollisionen aus den Weg zu gehen Zudem k nnen sich dadurch mobile Roboter auch in sich ndernden Umgebungen zurecht finden 4 Ausblick Einen Anstieg des Gebrauchs von Fuzzy Logik in jenen Anwendungsgebieten in denen sich diese Theorie bereits in den Anf ngen etabliert hat ist anzunehmen Dies wird besonders in der Regelungstechnik und bei Expertensystemen der Fall sein 14 Die Qualit t der Applikationen die auf dem Fuzzy Logik Konzept basieren wird zudem immer besser Ein Anwendungsgebiet von Fuzzy Logik welches zwar nicht neu aber in Zukunft noch viel mehr an Bedeutung gewinnen wird ist die k nstliche Intelligenz Neben Expertensystemen gibt es hier bereits Anwendungen zur Mustererkennung und in der 117 Robotik Des Weiteren wird auch besonders der Bereich des Sprachverstehens engl natural language processing von Fuzzy Logik gepr gt Da in der k nstlichen Intelligenz das menschliche Denke
105. Modell wurde anschlie end ein Klassifikations Schema das Faceted Classificati on Scheme definiert Weiters realisierten Prieto Diaz und Freeman in 11 ein konkretes Library System welches auf dem facetten orientierten Klassifizierungs Schema aufbaut Von der Arbeit von Prieto Diaz und Freeman motiviert ent standen im Laufe der Zeit weitere Schemata zur Klassifi zierung von Software Komponenten die auf dem Faceted Classification Scheme aufbauen Dieser Artikel diskutiert nun genauer das facetten orientierte Klassifizierungs Schema von Prieto Diaz und Freeman aus 11 und setzt dieses zu aufbauenden Ans tzen und moder nen Technologien in Relation Die Arbeit ist wie folgt auf gebaut In Kapitel 2 wird beschrieben warum und wie Software Reu se durchgef hrt werden soll In Kapitel 3 wird aufgezeigt dass die Wiederverwendung von Software Komponenten nicht nur Vorteile sondern auch bestimmte Nachteile mit sich bringt Aufgrund der Problem beschreibung wird das Reuse Modell motiviert und er rtert und gleichzeitig auf das vierte Kapitel bergeleitet In Kapitel 4 wird das Faceted Classification Scheme dis kutiert Dabei wird n her auf die Herleitung der Facetten die f r die Beschreibung der Software Komponenten in die sem Schema verantwortlich sind auf einen Thesaurus und ein Distanz Modell eingegangen Dar ber hinaus wird das Library System von Prieto Diaz und Freeman in 11 das auf dem facetten
106. Nachteile 3 2 1 Voraussetzungen Damit strukturierte Pro grammierung den gew nschten Erfolg zeigen kann m ssen jedoch bestimmte Punkte eingehalten werden Das wichtigste ist wohl dass jede Abstraktionsebene so gehalten ist dass das beschriebene Programm genau das tut was es soll nicht mehr und nicht weniger Darauf ist bei der ersten Ebene von der das Verfahren startet besonders zu achten Ist die anf ngliche Be schreibung ungenau oder gar unzutreffend wird das erarbeitete Ergebnis nicht die gew nschten Resultate erzielen 3 2 2 Entwicklungszeit Die schrittweise Verfeine rung mag vor allem wenn jede Ebene ausreichend dokumentiert wird aufw ndiger erscheinen als den Code direkt niederzuschreiben Dies ist vor allem dann der Fall wenn man sich f r eine sch ne aber nicht strukturierte L sung eine Alternative einfallen lassen muss Wirth beschreibt so in 01 ein passendes Bei spiel Selecting Distinct Numbers bei dem die erste nat rliche Formulierung des gefragten Algorithmus eine nahezu selbstverst ndliche goto Anweisung ent h lt Daraufhin wird jedoch eine intuitiv ebenso ver st ndliche L sung desselben Problems erarbeitet Dieses Manko wird jedoch durch die oben angef hr ten Vorz ge wieder wettgemacht 4 Die Entwicklung 4 1 Das Software Paradoxon Software ist ein Produkt Es wird designed von Pro grammierern produziert und anschlie end gewartet Doch im Vergleich zu anderen P
107. Relevant At Current Software Engineering Studies Aufruf zur Teilnahme und Seminarordnung Das Bakkalaureatsseminar wird im Sommersemester 2007 in form eines e Learning unterst t zten gemeinsames Workshops gef hrt Kooperation mit dem Schreibcenter wird angestrebt Die diesbez glichen M glichkeiten h ngen jedoch von der Teilnehmerzahl ab und k nnen derzeit noch nicht fixiert werden Lehrziel ist dass Studierende durch selbst ndige Bearbeitung eines aktuellen Themas aus An gewandter Informatik neben fachlichen Kenntnissen auch methodische Kenntnisse im Verfas sen wissenschaftlicher Arbeiten weitere Seminararbeiten oder Diplomarbeit aber auch sonstige fachlich technische Berichte erwerben aber auch durch positive Kritik solcher Arbeiten F hrungs und Teamf higkeit zum Gesamtgelingen beizutragen Methodisch wird dieses Seminar in Form eines durch die Seminarteilnehmer getragenen Workshops durchgef hrt in dem berpr ft werden soll welche Bedeutung Klassiker der Informatikliteratur aus heutiger Sicht haben W hrend der Entwicklungsphase wird die Kommunikation weitestgehend ber MOODLE durchgef hrt Das Workshop selbst ist zweigeteilt Zu Semestermitte sollen in einem Kurzvortrag die Kon zepte des gew hlten Basisartikels kurz vorgestellt werden und ein Ausblick auf die eigenen berlegungen dazu geboten werden Im Hauptvortrag im Juni sind diese eigenen berle gungen sodann ausf hrlich darzulegen Seminarthemen
108. Suchfunk tion in einem Compiler und in einem Datenbanksystem Die Suche im Compiler operiert evtl auf einer Symbol Tabelle wobei im Datenbanksystem ein B Baum als Datenstruktur herangezogen werden k nnte 11 Aus diesem Grund wurden neben der Funktion function die eine Komponente ausf hrt noch zwei weitere Facetten definiert um Funktionalit t zu beschreiben Objekt ob ject und Medium medium Die Facetten werden in Form des Tupels lt function object medium gt dargestellt und haben folgende Bedeutung 5 11 e Function Name der Funktion welche die Komponente ausf hrt z B search add 65 e Object Objekt das von der Komponente manipuliert und zur Ausf hrung der Funktionalit t ben tigt wird z B ar guments root e Medium Medium das verwendet wird um die Funktionalit t auszuf hren Stellt eine gr ere Datenstruktur dar wel che das manipulierende Objekt beinhaltet z B B tree array Umgebung Diese Beschreibung charakterisiert den Kontext f r den die Software Komponente entwickelt wurde 5 F r eine Kom ponente existieren zwei Umgebungen 11 e Interne Umgebung Internal Environment Die interne Umgebung bezieht sich auf das Umfeld in dem die Software Komponente ausgef hrt wird ndert sich diese Umgebung hat dies keine relevante Auswir kung auf die Funktionalit t der betroffenen Kompo nente da diese blicherweise unv
109. TRACES Themes still Relevant At Current Software Engineering Studies Ergebnisse des Bakkalaureatsseminars aus Angewandte Informatik Sommersemester 2007 Leitung Roland Mittermeir Institut f r Informatik Systeme Alpen Adria Univerisit t Klagenfurt Klagenfurt Juli 2007 Institut f r Informatik Systeme Alpen Adria Universit t Klagenfurt Juli 2007 INHALTSVERZEICHNIS Vorbemerkungen Roland MA Cre it ae iis cases ie RR RR IR DIR ER EE tS Der Ursprung Strukturierter Programmierung Martin Glawischnie ausschaut Are goto s don t do s Ingomar Brei 28er Abeer E E E E T a e aeia Model Driven Software Development and Beyond Michael Steindorfer nun ar glen tee a ce Sale Aspektorientierte Programmierung Ein Uberblick Rudolf Granitzer sense nie The UNIX Programming Environment Where it Started and Where it Went Michael Omer aan a RR ea Software Factory An Overall Approach to Software Production Michael Prodnik 4 2 2 2er sn nes ag Komponentenbasierte Softwareentwicklung Bon az ROU ANI soriire ae Near Faceted Classification Christoph Kofler wrat e aa has Software Entwicklungsprozesse Markus Schneider al seele Softwareprozesse sind auch Software Aspekte einer Entwicklung Manfred J rgen Primus a ee ee Inspections Reviewed Eritz GENSET dics Paid en ee RN NEST ber Wissensrepr sentation zu Anforderungsmodellen Marin Andritseh oeira ne EE EEEE E aN VEERE EEEE ETE EEE EENET Ea Domain Engi
110. Weg herauszufinden Dies geschieht ber die Kennzeich nung der Pfade Je fter dabei ein Weg begangen wur de desto passender scheint dieser Weg zu sein Nun kann man die Behauptung aufstellen dass wenn die Ameisen den schlechteren Weg gehen diesen ja auch markiert haben und daher beide Wege gleicherma en verwenden Es ist jedoch der schlechtere Weg jener bei dem die Ameisen l nger ben tigen um zur Futter 124 stelle zu gelangen Dieser wird dann nat rlich h ufiger frequentiert was zu einer gr eren Kennzeichnung durch Pheromone f hrt Weiters verschwindet diese Kennzeichnung auch mit der Zeit sodass der schlechte Weg alsbald eine niedrigere Priorit t aufwei t Dies passiert so lange bis fast jede Ameise den k rzeren Weg benutzt Diese Methode der Natur wurde n her in 4 erl utert Nun existieren wie bereits besprochen viele m gli che Gr nde warum man ein nat rliches Ph nomen in ein mathematisches Modell abbilden will Simulation Parameterbeeinflussung Vorhersagen usw Daher m ssen als erster Schritt die Variablen deklariert wer den Da der gew hlte Weg TDS von der Pheromon dichte abh ngt muss als einzige Variable hierbei die Pheromonkonzentration auf den einzelnen Wegen er stellt werden Als n chstes muss das Verhalten also die Regeln der Ameisen n her betrachtet werden Wir gehen im Weiteren von lediglich zwei Wegen aus Die Ameise w hlt jenen Weg welcher mehr Pheromone aufwei t Wenn
111. Wortes w wieder Als Beispiel soll folgender Sachverhalt erw hnt werden Das Auto f hrt schnell Hier stellt schnell das Wort dar welches eine granulare Menge be schreibt Das Wort schnell beinhaltet somit auch gleichzeitig die Bedeutung der Menge Man k nnte auch sagen Das Auto f hrt M1 Dabei w sste man nicht was M1 bedeutet Erst durch einen R ckschluss aufgrund der beschriebenen Menge welche MI dar stellt kann gefolgert werden dass dies schnell bedeu tet Schnell wird dabei auch noch als fuzzy constraint bezeichnet da dies f r weitere Berechnungen als eine Bedingung angesehen werden kann Ein weiteres Beispiel Wir haben 2 Theoreme fuzzy propositions p pl Martin wohnt in der N he von Klaus p2 Klaus wohnt in der N he von Peter W ren diese beiden Ausgangssituationen Grundlage f r eine Berechnung der Entfernung zwischen Carol und Pat so m sste man wie folgt vorgehen Es gibt hier eine gra nulare Einteilung der Entfernung zweier Personen Un ter Anderem gibt es eine granulare Menge in der N he von Diese Menge k nnte die Nachbarn in einer Entfernung von 1km beschreiben Man kann nun aber nicht direkt daraus schlie en dass aus den beiden S tzen von oben auch Folgendes resultiert Martin wohnt in der N he von Peter Dies h ngt von den gesetzten Bedingungen ab Es ist Festle gungssache ob die Berechnung in der N he x in der N he wieder in der N he
112. aim for every block is to only have a single top level decision which can easily be transformed into a while statement In case this is not possible additional boolean variables have to be inserted to keep track of the program flow The disadvantage of this algorithm is that it provides an input output equivalence only altering the structure of the original program significantly Another way of getting rid of goto s is described in 15 In this thesis the program code is represented in a special program algebra PGA for an easier reasoning about the correctness of certain concepts Furthermore there are two techniques mentioned to remove goto s with the use of additional variables and without The more interesting algorithm is definitely the removal without requiring additional variables thus resulting in a transformation that is almost structural equivalent To achieve this several steps are necessary Firstly so called head to head crossings need to be removed A head to head crossing are overlapping goto statements that have to be removed by reordering the code Another step of the algorithm is the replacement of goto s with loops with multiple exits In this step the whole program is put into a loop and whenever the program exits the loop is terminated There are a few more steps included in this algorithm but they are mainly refinement steps that need not to be explained here The last algorithm I would like to explain can be found
113. ain decorative headers and trailing information e Tools can accept input generated by other tools e The tools are capable of performing standalone execution without user intervention 9 Following these design principles which are easy to adopt provides an interface textual between the different programs Using this interface and the UNIX pipe mechanism new programs can be created that perform almost any function imaginable In essence these tools are components that can be put together to achieve a higher goal Since text output of every tool can not be standardized in a way that it fits as input for any other program some tools were developed that transform text in various ways Using these tools the output of the first program can be adapted to fit the input requirements of the second one 3 Programming Paradigms As mentioned earlier UNIX was a precursor to many programming paradigms that are common today UNIX thereby did not really introduce all new ideas but made concepts which where known before so easy to use that they experienced widespread use This chapter provides a closer look at some of these concepts models them like we know them today and gives some insights into their historic development as far as this is possible 3 1 Component based development The development of software is a cost and resource intensive undertaking Many approaches have been tried to overcome this problem One of which is the
114. alt f r das Seminar fest steht Terminplan Siehe TRACES Basisinformation Beurteilungsschema Beurteilt wird die auf Individualleistung und Mitarbeit beruhende Gesamtleistung bestehend aus Qualit t deskommentierten Inhaltsverzeichnis 20 Leistungen im Reviewprozess Begutachtung d kommentierten Inhaltsverzeichnis und Begutachtung d Endfassung 20 25 Endfassung Erstversion und Endfassung 40 Kurzvortrag und Vortrag 20 25 Der Ursprung Strukturierter Programmierung Martin Glawischnig 0160357 m2glawis edu uni klu ac at Abstract Strukturierte Programmierung ein Konzept das dem prozeduralen Paradigma der Programmierung entstammt begleitet uns seit den 1960er Jahren Der Grundgedanke besteht darin f r einzelne Teile des Programms lediglich die grundlegenden Strukturen Sequenz Wiederholung und Entscheidung in hierar chischer Art und Weise zu verwenden Dieser Artikel soll nun einige Fragen rund um die sen Bereich beantworten Wie ist das Konzept der strukturierten Programmierung eigentlich entstanden Wird es heute immer noch angewendet Welche Rele vanz hat es im Vergleich zu damals 1 Einleitung Zu Beginn dieser Arbeit steht eine grunds tzliche Erkl rung was unter strukturierter Programmierung eigentlich verstanden werden kann Im zweiten Kapitel wird erarbeitet welche Vor und Nachteile eine An wendung dieses Konzepts mit sich bringt Der letzte Teil besch ftigt sic
115. an die Forderung Osterweils dann ist wenn man den Softwareprozess als Programm sieht die Probleml sung das Prozess Programm selbst Wenn man nun ein Prozess Programm als Hilfestellung beim Softwareentwicklungsprozess h tte w re ein gro er Vorteil die Daten in konstanter Form gespeichert zu haben Die Daten w ren dann wie es im Jahr 1987 war nicht an eine oder eine Handvoll Personen gebunden sondern auf Grund des Softwareprozess Programms w ren s mtliche anfallenden Daten f r alle Beteiligten verf gbar H tte man eine Programmiersprache f r den Softwareprozess h tte man einen weiteren Vorteil Durch diese Sprache lie en sich die Daten einheitlich speichern sie k nnten in vielen Varianten sichtbar gemacht werden Dadurch h tte man unter anderem auch die M glichkeit f r Kunden lesbare und verst ndliche Abstraktionen verf gbar zu haben Die Beteiligten am Softwareprozess verf gten ber ein Werkzeug mit dem sie auf verschiedenen Abstraktionsebenen ber das zu erstellende Produkt diskutieren und reden k nnten Durch das Definieren einer Prozessprogrammier sprache k nnte man die eingegebenen Daten automatisch analysieren aufbereiten und interpretieren lassen Es w re ein gro er Schritt in der Weiterentwicklung des Softwareprozesses wenn man es wirklich schaffen w rde sie durch eine Softwareprozess Programmiersprache zu materialisieren Zehn Jahre sp ter wurde sein Aufsatz aus dem Jahre 1987 zum einflussre
116. an those of former times Still there are a number of programs utilizing goto s in a well structured and fashionable manner with a deeper focus on structure than on optimization 3 1 The appearance of goto s in today s programs I am going to analyze two quite big open source programs written in the programming language C The programs I had in mind are the GNU Linux kernel version 2 6 21 and the GNU C compiler collection version 4 2 0 This analysis is not meant to be a performance measurement The main goal of this observation is to outline patterns how goto s might be used in today s programs without the fear of destroying a good structure 3 1 1 The GNU Linux kernel The first program I am going to look at is the kernel of the Linux operating system 20 written in C and known for its high complexity There have been a few discussions whether goto s are a feasible way of doing things 21 especially in the kernel of an operating system One perspective is that goto s are considered harmful by default which might be a reason of the constant misuse in former times The other opinion is that goto s if used cautiously are a good means of structuring the code in a nice and readable way Most of the kernel programmers have agreed on that and the use of goto s is desired if they are applied in a reasonable way 22 But let s have a look at a few samples of code from the latest kernel release The examined kernel was downloaded fro
117. andard order This is usually accomplished by applying a local transformation to the input streams and computing incrementally Output therefore begins before input is consumed Hence components are termed filters The connectors of this style serve as conduits for the streams transmitting outputs of one filter to inputs of another Hence the connectors are termed pipes Among the important invariants of the style filters must be independent entities In particular they should not share state with other filters Another important invariant is that filters do not know the identity of their upstream and downstream filters Their specification might restrict what appears on the input pipes or make guarantees about what appears on the output pipes but they may not identify the components at the ends of those pipes 12 See Figure 1 for an example configuration Bar Filter Filter Filter Filter Filter Filter Figure 1 General pipes and filters If we compare this description of the pipes and filters architecture written by Garlan and Shaw 12 with the pipelining facility that UNIX provides we see a lot of similarities In the UNIX world components or filters can be compared to the UNIX tools Pipes in UNIX offer the same functionality like the ones described in the architectural pattern At the same time our tools do not know who is their predecessor in the chain or who is coming next it goes even fur
118. ann insbesondere im Deployment Sektor der bei gro Ben Installationen einen beachtlichen Teil des Aufwan des ausmachen kann eine umfassende Unterst tzung gesehen werden die Matsumoto in seinen berlegun gen nicht erkennbar ausf hrt Der Ansatz von Testing vor Ort geht zwar bereits in diese Richtung Software aber wirklich automationsgest tzt zu verteilen wird nicht ber cksichtigt obwohl er zum industrieorientier ten Prozess mit anschlie ender Logistik passen w rde Dies ist zwar noch f r eine gesamtheitliche Sicht einzu 53 fordern mag aber teils das Fehlen auch in der Art der in Fuchu produzierten Software liegen da bei der Ver teilung von Software eher von fertigen standardisier ten auf viele Rechner zu verteilenden Paketen ausge gangen wird was bei relativ hardware naher Prozess und Kontrollsoftware eher ein untypisches Kriterium darstellt Aus aktuelleren Modellen erkennbar und verbesser bar w re der in Matsumotos Prozessmodell vermisste Ansatz von m glichen Riickspriingen Iterationen in einzelnen Phasen Der Prozess der sich in seinen Grundz gen sehr dem Wasserfallmodell ann hert ist straff und geradlinig organisiert und eingerichtet An hand von modernen Anforderungen und Erkenntnissen die sich auch in den entsprechenden Prozessmodellen wieder finden k nnte hier entsprechender Verbesse rungsbedarf f r die Software Factory abgeleitet wer den der insbesondere im Faktor Qualit t seinen Nie derschlag
119. ant 12 and if additional functionality is needed this can be simply done by adding other filters There are however also some problems which arise with this kind of architecture First of all use of this architecture often leads to a batch organization in processing Second the coordination between different streams as it is in the general pipes and filter architecture can be very complicated Further great care has to be put in breaking up functionality into components These should be quite low in complexity but at the same time too fine a level of granularity imposes problems too 13 With the way UNIX implements its pipes another problem arises All programs in the pipe run concurrently each in a separate process which can easily lead to some major performance attrition 4 Other paradigms The two paradigms mentioned above are not everything exciting introduced by UNIX Many other ideas could be derived from this operating system Some of them are mentioned in this chapter although they are not discussed as elaborate as component based development and the pipes and filters architecture Kernighan and Mashey 2 made some interesting observations when looking at the programming methodology that is supported by the shell e Programming can often be avoided to a great extent since the use of readily available tools and the combination of these parts can often fulfill the stated requirements This idea combines somehow with the id
120. ases that have been described as software engineering aspects Finally goto s are still present in today s programming languages in one form or another and they clearly influenced the knowledge we have today 6 References 1 E W Dijkstra 1968 Goto s considered harmful Communications of the ACM Vol 11 No 3 pp 147 148 2 D E Knuth 1974 Structured programming with goto statements ACM Computing Surveys CSUR Vol 6 No 4 pp 261 301 3 W Gellerich Kosiol M and Ploederer E 1996 Where does GOTO go to Proceedings of the 1996 Ada Europe International Conference on Reliable Software Technologies pp 385 395 4 A M Erosa 1994 A goto elimination method and its implementation for the McCAT C compiler Master thesis McGill University Retrieved on 10 05 2007 from http citeseer ist psu edu erosa95 gotoelimination h tml 5 Java reference manual Retrieved on 11 05 2007 from http java sun com reference index html 6 Python reference manual Retrieved on 11 05 2007 from http docs python org ref ref html 7 Oberon reference Retrieved on 11 05 2007 from http www oberon ethz ch compiler 8 Modula 2 reference Retrieved on 11 05 2007 from http www modula2 org reference index php 9 E Huss 1997 The C library reference guide Retrieved on 11 05 2007 from http www acm uiuc edu webmonkeys book c_guide 10 C specification Retrieved on 11 05 2007 from http w
121. auf hin dass Fragen wie nun Systeme zertifiziert werden sollen welche selbst aus zertifizierten Komponenten bestehen noch offen sind Dieses Kapitel sollte die dauerhafte Relevanz von Softwarekomponenten deutlich machen und zeigen dass Softwarekomponenten auf dem besten Weg sind qualitativ hochwertige Bausteine f r Softwareentwick ler zu werden Viele der aufgezeigten Eigenschaften von Softwarekomponenten waren in Peter Wegners Ar tikel 31 noch nicht diskutiert Korrekte einheitliche Dokumentation Qualit tsmodelle und Zertifizierung von Softwarekomponenten helfen dem von Meyer ge pr gten Begriff der vertrauensw rdigen Komponenten 20 gerecht zu werden Dar ber hinaus m ssen ver trauensw rdige Softwarekomponenten auch miteinan 58 der kooperieren k nnen Sie ben tigen zus tzliche ka pitalintensive Technologie um miteinander effektiv in Verbindung treten zu k nnen 3 Komponententechnologie Die Komponententechnologie stellt die Infrastruktur zur Kommunikation verschiedener einem System zu geh riger Komponenten sicher Dazu ist es jedoch nicht alleine damit getan Interaktionsprotokolle zu de finieren und Anfragen entsprechend zu transformieren Um eine m glichst hohe Transparenz und Vielseitig keit zu gew hrleisten bieten Komponentenmodelle zu s tzliche Dienste wie Namens Transaktions Ereig nisbenachrichtigungsdienste oder auch die Sicherheit betreffende Dienste an H ufig wird in diesem Zusam me
122. bekanntesten IDEs sind Eclipse f r fast alle g ngigen Sprachen und IntelliJ IDEA speziell f r Java 9 10 IDEs erh hen die Arbeitskraft eines Programmierers um ein vielfaches Alle gr eren IDEs unterst tzen den Autor beim Schreiben Modifizieren der Fehlersuche und vieles mehr Sie unterst tzen Code Completion Refactoring automatisches umbenennen von Variablen Methoden Klassen und deren Verwendungen automatische Generierung von Methoden Code Beautifier korrektes Einriicken von Bl cken Verzweigungen und Methoden und zeigen dem Benutzer live eventuelle Fehler In weiterer Folge m chte ich kurz JetBrains IntelliJ IDEA vorstellen da diese IDE eine gro e Palette von eingebauten Code Analyse Tools und Verifikationsm glichkeiten bietet In IDEA findet man unter dem Men punkt Analyze den Punkt Inspect Code Hier kann ein erfahrener Benutzer ber sechshundert verschiedene Einstellungen treffen anhand deren der Code analysiert werden soll IDEA berpr ft auf Wunsch einzelne Dateien oder das gesamte Projekt Einige sinnvolle Beispiele sind unter anderem e Dead Code unausgef hrte Codeteile oder Methoden nicht verwendete Variablen Interfaces die keine implementierten Klassen besitzen e Redundante Importe Deklarationen oder Casts e Doppelte Zuweisungen ohne ein Auslesen e Doppelte Deklaration von globalen und lokalen Variablen e Variablen die nur lokal verwendet werden aber gl
123. bject to composition by third parties 17 From this definition four criteria can be extracted that a software component should fulfil e Multiple use A software component should be usable in different software projects UNIX tools in this sense are used over and over again They have multiple usages in the same shell procedure as well as in different programs e Context independence A component should fulfil a certain task and should be able to perform this same task in many different contexts This criterion is fulfilled as well as the first one since UNIX tools have hundreds of possible usages and are not bound to any context e Composition by third parties A software component should not necessarily be developed in house It should be possible to develop systems that are building up from parts of many different vendors UNIX tools fulfil this need in any possible view First of all they are actually developed from many different people that contributed to the total project This alone would probably fulfil the stated criterion but UNIX tools are even more By offering the possibility to develop them in any language that can be compiled under UNIX they offer third parties the opportunity to use the programming language that fits their needs best As long as they stick to the interface regulations which basically means ASCII output the command language can glue them together to a greater whole e Independent deployment and ve
124. bstraktionen zu finden und diese einer formalen Modellierung zug nglich zu machen Dadurch entsteht ein hohes Automationspotenzial f r die Fertigung von Software und dies wiederum l sst sich in den allermeisten F llen in eine deutliche Produktivit tssteige rung umsetzen Model Driven Software Development muss nicht als radi kaler Paradigmenwechsel in der Softwareindustrie gesehen werden sondern eher eine Konsolidierung einer Vielzahl von Trends und Technologien welche die Softwareentwicklung in der letzten Zeit vorantrieben Etablierte Konzepte wie zum Beispiel Objektorientierung Component based Deve lopment und Patterns werden durch MDSD nicht obsolet 2 Dieser Ansatz wird ausf hrlich in Kapitel 3 dargestellt Tn 2 wird in der Einleitung im Vorwort und im Chapter 1 diese Positionierung sehr gut dargestellt Das Vorwort wurde von Michael Guttmann verfasst Obwohl man in erster Linie an grafische Modelle denkt sei erw hnt dass diese nicht unbedingt grafisch sein m ssen 27 3 1 Abgrenzung zu Model Driven Architecture MDA Der Begriff Model Driven Architecture MDA ist in der Fachpresse sehr gel ufig wird aber sehr unterschiedlich ver wendet Nach Thomas Stahl und Markus V lter stellt MDA eine Standardisierungsinitiative der Object Management Group OMG zu Model Driven Software Development dar welche mit ihren Standards vorrangig die Ziele der In teroperabilit t Herstellerunabh ngigke
125. bt Java weist im Gegensatz zu Frill Objekte fix einer Klas se zu Abschlie end wurde die Konstruktion eines Computing with Words Systems anhand der medizini schen Diagnose dargestellt Wie wir gemerkt haben ben tigt diese jedoch viele Schritte Um nun trotzdem den gesamten Verlauf sowie die dargestellten Definiti onen zu verstehen bedienten wir uns eines anschauli chen Beispieles Computing with Words l sst also neben For schungszwecken sowie den direkten praktischen Ein satz auch noch Platz f r neue Sichtweisen weshalb es seit der Einf hrung von L A Zadeh stets an Anwen dern der Methode zunimmt Neueste Forschungen ge hen sogar den noch weiteren Weg indem sie das Un scharfe weiter unscharf machen wollen Man will die Unsch rfe des menschlichen Handelns noch besser einbinden Dies funktioniert einerseits mit Einf hrung von Unsch rfen bei den Regeln und andererseits durch eine neue Art von Fuzzy Reglern 12 Man kann also gespannt sein was dieses Thema an neuen Methoden aufwerfen wird 6 References 1 L A Zadeh Fuzzy Logic Computing with Words Life Fellow IEEE Transactions on Fuzzy Systems Universi ty of California 2 Mai 1996 2 L A Zadeh Fuzzy Sets Information and Controls National Science Foundation University of California 1965 3 V Rozin M Margliot The Fuzzy Ant JEEE Computa tional Intelligence Magazin School of Electrical Engeneering Systems Tel Aviv 2004
126. ce 17 which does not include that much freedom as the input output equivalence Two algorithms are flow graph equivalent if their program flow is equivalent leaving room for reordering and additional commands The strongest form of equivalence is the structural equivalence defined by Ramshaw 18 Two programs are considered structural equivalent if they are flow graph equivalent and one program can be transformed into the other simply by replacing a few components of the source code and without altering the codes ordering There are a few preconditions to be met in order to be able to achieve certain kinds of equivalences e g no head to head crossings Those preconditions can be achieved using other code transformations 15 2 3 2 Elimination algorithms There exist several algorithms for replacing goto s with other programming constructs mainly conditions and loops I am not going to describe the goto elimination algorithms themselves but I will outline the key informations necessary to make the algorithms understandable Please have a look at the quoted papers for additional information and examples The algorithms proposed in 16 utilizes flowcharts to describe the program structure a very common way of designing programs back in the days The algorithm works on the assumption that every goto statement can be replaced by a suitable while loop In more detail the flowchart is broken up into blocks with only one exit The
127. che Konstrukte Des Weiteren k nnen die eindeutigen Zugangspunk te auch zur Unterst tzung der Stabilit t herangezogen werden Durch die Top Down Entwicklung haben Va riablen automatisch nur denjenigen Scope den sie brauchen und keinen gr eren die Verwendung ein und derselben Variablen an verschiedenen unabh ngi gen Codest cken wird unterbunden Dieses Ergebnis erh lt man dadurch dass Variablen erst dann einge f hrt werden d rfen wenn sie auch wirklich ben tigt werden Globale Hilfsvariablen schon zu Beginn zu definieren mit dem Hintergedanken sie dann irgend wann zu verwenden w re eben nicht strukturiert Dies ist vor Allem auch dann hilfreich wenn Speicherplatz in dauerhaft laufenden Programmen freigegeben wer den muss um die Stabilit t des Systems zu gew hrleis ten 01 3 1 4 Leichtere Beweisf hrung Dadurch dass der gesamte Entwicklungsprozess vorgegeben ist kann 13 wenn man sich von Anfang bis zum Ende rigoros daran gehalten hat die Funktionalit t des entstandenen Pro gramms leicht bewiesen werden Dies unterst tzt letzt endlich die Zuverl ssigkeit des Systems Der Gro teil der Beweisf hrung wird sogar quasi als Nebenprodukt des eigentlichen Prozesses mitgeliefert Wesentlich daf r ist jedoch dass die urspr ngliche abstrakte Be schreibung die den Ausgangspunkt darstellt genau das beschreibt was als Ergebnis erwartet wird Dasselbe gilt auch f r die nachfolgend getrof
128. cheidendes Kriterium Auf diese Problematik wird im Kapitel ber komponentenbasierte Softwareent wicklung kurz eingegangen Dokumentation Soll eine Softwarekomponente wie derverwendet werden ist eine gute Dokumentation des Bausteins eine unumg ngliche Notwendigkeit Gerade wenn ein Systemintegrator eine Applikation aus Kom ponenten verschiedener Quellen zusammensetzt kann die Dokumentation sp rbar zum Gelingen beitragen Eine Dokumentation sollte die Selektion und die Vali dierung der Interoperabilit t von Komponenten unter st tzen sowie Auskunft ber Qualit tsattribute und Wartbarkeit der Komponenten geben 29 Noch exis tiert kein Standardmodell zur Dokumentation von wie derverwendbaren Komponenten Die meisten Lieferan ten haben ihre eigenen Dokumentationsrichtlinien wo durch die bersichtlichkeit f r Eink ufer von Kompo nenten erschwert wird Die Autoren von 29 haben ein Muster vorgestellt nach dem Komponenten dokumentiert werden sollten Ihr Dokumentationsmuster ber cksichtigt im Besonde ren die Produktlinienentwicklung basierend auf third party Komponenten Produkte einer Produktlinie ha ben in der Regel dieselbe Architektur als Grundlage und bestehen aus unterschiedlich zusammengesetzten Komponenten verschiedener Hersteller Wie man in Abb 1 erkennen kann ist eine nicht unbeachtliche Menge an Informationen f r Testzwecke vorgesehen 57 Basic Information Acceptance information General inf
129. chen werden muss ist der Verlust ebenfalls geringer wenn so fr h als m glich abgebrochen werden kann Das Wasserfallmodel zielt auf eine End Ubergabe ab bei RUP hat man normalerweise mehrere Produkt bergaben nderungen k nnen fr her abgefangen werden Die h ufigsten nderungen betreffen Anforderungen Dies f hrte bei anderen sequentiellen Modellen oft zu gro en Problemen Nachdem der Auftraggeber beim iterativen Prozess schon eine fr he Version des Produktes in H nden h lt sind hier die Probleme geringer und die Chance auf ein bestm gliches Produkt ist weitaus gr er Reuse ist leichter m glich Bei RUP besteht die M glichkeit auf Grund von Architekturzentriertheit und der Benutzung von Komponenten leichter Reuse zu betreiben Dadurch dass das Produkt durch die Iterationen unz hlige Male getestet worden ist das die Anforderungen immer wieder nachgebessert und verfeinert wurden verbessert sich auch die Qualit t Im Rational Unified Process gibt es 30 Rollen die in f nf Hauptkategorien eingeordnet sind Analysten Entwickler Manger Tester Produktion und Support Rollen spezifizieren wie gesagt nicht Personen sondern F higkeiten und Kompetenzbereiche Jede dieser Kategorien wird noch einmal unterteilt in spezifischen Rollen Aus jeder Hauptkategorie soll nun ein Vertreter beschrieben werden e Anforderungsanalyst Er spezifiziert eine oder mehrere Funktionalit ten des Systems unter Zuhilfenahme von Use Ca
130. chitektur Z B eine Programm Bibliothek oder ein Datenbank Schema 3 Infrastruktur Implementation die Architektur wird in der Zieltechnologie der Wiederverwender implementiert Z B Implementierung von Programmen in Ada oder Lisp indiziert mit einem Klassifizierungsschema Arango betrachtet haupts chlich die Dom nenanalyse und Infrastruktur Spezifikation gibt aber daf r keine konkrete Methode vor wie Dom nenanalyse durchgef hrt werden sollte Die Ansicht ist auf einer Metaebene in der unterschiedliche Aufgabenstellungen f r Wiederverwendung m glich und daher auch unterschiedliche Methoden notwendig sind Vielmehr gibt Arango Prinzipien eingebettet in einem Framework vor die bei jeder Analyset tigkeit vorkommen 1 Neighbor definierte eine allgemein akzeptierte Formulierung von Domain Analysis 4 domain analysis is an attempt to identify the objects operations and relationships between what domain experts perceive to be important about the domain Arango glaubt dass ein praktischer Ansatz von Domain Analysis im Gegensatz zum puren k nstlerischen Ansatz notwendig ist da es keine pr zise Definition von wichtig und Dom ne gibt Es gibt auch keine klaren Ziele und keine konkrete Formulierung wann Dom nenanalyse fertig gestellt ist F r den praktischen Ansatz formuliert Arango folgende Fragestellung 1 How is a model of a domain incrementally constructed evolved to achieve
131. chste before Advice zuerst 3 Berechnungen des Join Points werden ausgef hrt 4 after running oder after throwing Advices werden ausgef hrt weniger spezifische zuerst 5 after Advices werden ausgef hrt weniger spezifi sche zuerst 6 Der R ckgabewert von Schritt 3 sofern es einen gibt wird an das innerste around Advice in Schritt 1 bergeben Dieses innerste around Advice wird weiter ausgef hrt 36 SQ Ist die Ausf hrung des innersten around Advices beendet wird wird die Ausf hrung beim umge benden around Advice fortgesetzt 0e Ist das u erste around advice fertig wird der Join Point verlassen 4 Die folgende Advice Deklaration definiert ein after Advice auf dem Pointcut moves und wird ausgef hrt wenn ein move Methodenaufrufbeendet wurde Das hei t wurde eine Figur bewegt wird das Flag auf true gesetzt after moves flag true 2 5 Aspekte in AspectJ Aspekte k nnen Deklarationen von Pointcuts Ad vices und sonstiger in Klassen erlaubten Konstrukten enthalten Die folgende Aspektdeklaration implementiert eine nderungsverfolgung die ermittelt ob eine der Figuren bewegt wurde aspect MoveTracking static boolean flag false static boolean testAndClear boolean result flag flag false return result pointcut moves receptions void FigureElement inerXY int int receptions void Line setPl Point receptions void Line setP2 Poi
132. cience and the fields of research associated with it are often considered as quite new and fresh There is not much literature available on the history of computing and it sometimes seems like we do not want the burden of noting and categorizing historic material To better understand where we stand today however we also have to look back and see where we came from Looking at some of the design choices of earlier days and the problems they had to address back then can open up a whole new view on the paradigms we know today It is interesting to see if some paradigm was developed without even thinking a lot about it or if it was developed over time as the solution to a long lasting problem In this paper a line is drawn from the development of UNIX and the functions it offers to some concepts that we commonly know today While showing these coherences some additional historic information is given to paint a fuller picture and help to better understand the development which has taken place The first chapter of this paper is about the milestones introduced in UNIX and the most interesting parts of the operating system It describes what UNIX had to offer when it was developed and can be understood as a little historical view from the functionality still available today On purpose newer 39 developments in UNIX are not mentioned there is other literature where this information could be gathered and as described earlier this paper tries t
133. cklung zu dienen RML unterst tzt drei verschiedene Arten von Objekten Aktivit ten Entit ten und Behauptungen die mitein ander durch bin re semantische Beziehungen verbun den in Klassen gruppiert und durch Generalisie rung Spezialisierung organisiert sind Solche Modellie rungssprachen eignen sich gut f r die stufenweise Spezialisierung 5 Was RML ein wenig einschr nkt ist die fixe Betrachtung der Welt im Sinne einer fix eingebauten Notation Diese erlaubt es nicht bei Be darf neue Notationen einzuf hren die Sprache anderen Gegebenheiten anzupassen und sozusagen Ma zu schneidern 5 4 Entwicklung im Requirements Enginee ring Folgende Abschnitte behandeln das Umdenken vom objektorientierten Ansatz hin zum zielorientierten Ansatz im Bereich des RE 4 1 Von objekt orientierten zu ziel orientierten Methoden Wie schon erw hnt hatte der Einsatz objektorientierter Methoden in der Programmierung Anfang der 80er Jahre begonnen Dies hatte zwangsl ufig auch gro en Einfluss auf das RE und f hrte zum Einsatz objektori entierter Modellierungsmethoden Noch in dieser Zeit war die grundlegende berlegung was das zuk nftige System zu leisten h tte Methoden im RE waren da durch von Programmierkonzepten inspiriert Durch die Zunahme an Dynamik im gesch ftlichen und organisa torischen Umfeld f r das die Systeme heutzutage haupts chlich L sungen bieten sollten ging man dar an die Beziehung zwischen dem Syste
134. ckung die vor allem f r eine gute Lesbarkeit sorgt So werden alle Zeilen entsprechend ihrer Zugeh rigkeit zu bergeordneten Blocks einger ckt und zu lange Zeilen an geeigneten Stellen umgebrochen 13 4 3 Wie hat sich goto gehalten Moderne Sprachen wie zum Beispiel JAVA bieten bereits ausreichend viele Befehle um alle M glichkei ten f r einen Kontrollfluss abzubilden Neben der M g lichkeit aus Schleifen auszusteigen gilt wohl das Ex ception Handling als Paradebeispiel Es gibt jedoch auch Kritiker die meinen dass diese Konstrukte nichts anderes sind als eine andere Bezeichnung f r goto In JAVA wurde sogar goto als Schl sselwort ohne Funktion reserviert Nachdem auf der Ebene des Maschinencodes Sprungbefehle prinzipiell wesentlicher Bestandteil f r zwei der grundlegenden Bausteine n mlich Wiederho lung und Entscheidung darstellen kann man derartige Konstrukte dann auch in nahezu jeder Programmier sprache finden Lediglich die Vielfalt und die Benen nung unterscheiden sich zum Teil gravierend Dijkstra offerierte deshalb einen Vorschlag zur Klassifizierung von Konstrukten die seiner Meinung nach erlaubt sein sollten Er beschreibt einen vom Pro grammierer unver nderlichen Zeiger auf den sich dy namisch ver ndernden Programmfortschritt So gibt es zu jedem Zeitpunkt eine Menge von Koordinaten die eindeutig die Aufrufkette bis zur aktuellen Codezeile nachvollziehen l sst Laut Dijkstra sollen nur s
135. d Harel und Eran Gery beschrieben Dabei wird teil weise auf technische Aspekte eingegangen mehr aber auf die Ideen an sich MDSD ist ein sehr komplexes Gebiet und kann daher in dieser Arbeit nur ansatzweise bearbei tet werden Es werden prim r Konzepte behandelt die in direkter Relation zum Artikel Executable Object Mode ling with Statecharts 7 stehen Eine gute Einf hrung in dieses Thema geben die B cher Modellgetriebene Softwa Heute ist dies Firma unter dem Namen Telelogic bekannt 25 reentwicklung Techniken Engineering Management von Thomas Stahl und Markus V lter 11 und Model Driven Architecture Applying MDA to Enterprise Computing von David S Frankel 2 Aufbauend auf den Darstellungen des Model Driven Soft ware Development wird ein Ausblick auf die weiterf hrende wissenschaftliche Bearbeitung diese Gebietes von David Ha rel gegeben welche zum Teil weit ber MDSD hinaus geht Weiters bearbeitete Harel in seinen sp teren Arbeiten auch offene Fragestellungen die im Jahr 1997 noch nicht beant wortet waren 2 EXECUTABLE OBJECT MODELING WITH STATECHARTS Mit dem im Jahr 1987 publizierten Artikel Statecharts A visual formalism for complex systems 4 behandelte Da vid Harel erstmals Zustandsdiagramme Statecharts in der Form wie sie auch heute noch existieren Entworfen wurden sie mit dem Ziel die Modellierung von komplexen reaktiven Systemen zu erleichtern In der Mitte
136. d be fine The mentioned modularity and abstraction can nowadays be found per default in object oriented languages that are more focused on the issue of program structure After all Knuth did choose a more pragmatic way to analyze the goto issues than Dijkstra and his findings were aimed to rather smoothen the discussion by providing both points and contra points for and against the use of goto s His proposal for transforming well structured code into efficient code using goto s can be seen as the counterpart to the goto elimination having its roots in the same epoch and arose out of the same discussion 2 3 Goto elimination Although the process of goto elimination is very old it is still needed for re engineering legacy software 15 19 The removal of goto s is a precondition for porting legacy code to a new programing language that does not have control structures directly equal to goto s e g Java 2 3 1 Program equivalence Due to the fact that a code transformation alters a program code but should not alter its functionality there needs to be a definition of equivalence to ensure that the altered program behaves like the original In fact there are a few kinds of equivalences defined The input output equivalence 19 16 is the weakest form because it allows the program structure to be altered significantly The only restriction is that the output of both programs must be the same Another type is flow graph equivalen
137. d der gesamten Phase R cksicht nehmen muss Implementierung und Komponententest Wie in Abb 2 ersichtlich folgt dem Design die Phase der Auswahl Anpassung und berpr fung der vorselek tierten Komponenten Funktionen und Spezifikationen der ausgew hlten Komponenten m ssen isoliert verifi ziert und getestet werden Danach werden Komponen ten assembliert und die dabei entstandenen Baugruppen erneut auf korrekte Funktion getestet Oftmals m ssen Komponenten noch mit Adaptern ausgestattet werden um mit der darunter liegenden Architektur kompatibel zu sein Die Implementierungsphase besteht nur noch teilweise aus Programmieren Code zu schreiben be schr nkt sich im Idealfall auf die Erzeugung von glue code Code zur Verbindung von Teilen beim Assemb lieren System Integration Diese Phase wird bedeutend von der gew hlten Komponententechnologie bestimmt da nun die Komponenten in das Komponentenmodell integriert und auf Architekturvertr glichkeit gepr ft werden m ssen Da die Komponententechnologie die Architektur weitgehend standardisiert k nnen an die ser Stelle die Vorteile von Architekturmustern ausge sch pft werden System Test Die Systemtestmethoden unterschei den sich nur wenig vom Standardvorgehen Die Beson derheiten liegen in der Blackbox Sichtbarkeit von Komponenten begr ndet Die Fehlerzuordnung zu ei ner Blackbox Komponente kann bei Auftreten eines Fehlers ob der fehlenden Implementierungsdetails er
138. d es sind viele Softwareentwicklungswerkzeuge in RUP integriert Bei der Entwicklung von Software haben sich einige Grunds tze herauskristallisiert die von namhaften Softwareentwicklern und Softwarefirmen propagiert werden Kruchten 03 e Iterative Entwicklung von Software Da sich Durch den iterativen Ansatz k nnen nderungen in den Anforderungen bei jeder Iteration neu einflie en und verursachen weniger Probleme Es muss nicht am Beginn der Entwicklung einer Software alles entschieden werden sondern es passiert kontinuierlich Dadurch ist auch Reuse leichter Fehler k nnen eher und leichter behoben werden als in einer einzigen Testphase fast am Ende der Entwicklung e Verwaltung der Anforderungen Dies umfasst das Finden Organisieren Besprechen und Verwalten der Anforderungen Wird dies effektiv unterst tzt erh lt man reduzierte Kosten verbesserte Qualit t und bessere Kommunikation unter den Beteiligten e Benutzung von auf Komponenten basierenden Architekturen Auch hier spielt wieder der iterative Ansatz hinein Dadurch kann man w hrend des gesamten Entwicklungsprozesses entscheiden welche Komponenten man selber entwickelt oder ob eine vorhandene wiederverwendet wird Beim Unified Prozess werden die einzelnen Komponenten erst alleine getestet und dann noch einmal nach dem Einf gen ins Ganze e Grafische Modellierung von Software Im RUP wird zur grafischen Darstellung UML sehr gerne verwendet Modelle helfen uns d
139. daraus synthetisierten Sour cecode und die Verbindungen zwischen diesen Systemteilen Dieser Kern bildet auch die Grundlage f r Entwicklungen im Bezug auf MDSD Wie in der Grafik ersichtlich ist w rde das Konzept um die Dimension der Anforderungen erwei tert Interessant in diesem Zusammenhang ist dass niemals der Begriff Model Driven Software Development genannt wird obwohl es sich um Grundlagenentwicklungen auf diesem Be reich handelt 4 1 Formalisierte Anforderungen W hrend des ganzen Software Lebenzyklus ist es wichtig si cher zu stellen dass das System macht was wir von ihm fordern Daher gilt stets eine Verbindung zwischen dem Sys tem und den Anforderungen zu haben Die Anforderungen k nnen dabei entweder formal strikt und genau spezifiziert 29 informal in nat rlicher Sprache geschrieben oder als Pseu docode vorliegen Da sich die Forschung von David Harel mit Automatisierung auf diesem Gebiet besch ftigt werden hier nur formale Anforderungen betrachtet 6 Von Message Sequence Charts MSCs zu Live Se quence Charts LSCs Message Sequence Charts MSCs sind eine weit verbreitete und bekannte visuelle Darstel lungsform fiir die Beschreibung von Szenarien welche die In teraktion von Prozessen bzw Objekten darstellen Im Um feld der objektorientieten Entwicklung werden MSCs sehr oft fiir die Spezifikation von Anforderungen verwendet Die ses Konzept hat sich auch in UML niedergeschlagen und ist d
140. dargestellte Ergebnis resultiert 120 Abb 2 Max Operator Wir gehen in Abbildung 2 davon aus dass folgende Berechnung durchgef hrt wurde fe Maxl fi fr O Man kann dies Vergleichen mit dem Bool schen Oder Operator welcher auch die Vereinigung zweier Mengen behandelt fo fav Sa Der Durchschnitt wird auch als Min Operator be zeichnet da er den Minimalwert zur ckliefert wie sp ter noch in einem Beispiel n her gebracht wird f x f x f x Abb 3 Min Operator In Abbildung 3 wurden die beiden Mengen mit dem Min Operator zusammengefasst Auch hier kann daher das Ergebnis mit Hilfe der Formel beschrieben werden fe Min fix fg Dies ist mit dem logischen Und Operator gleichzu setzen welcher auch den Durchschnitt zweier Mengen repr sentiert fe fa fs Neben diesen Definitionen und Begriffen gibt es noch weitere in 2 welche aber in diesem Paper nicht weiter erl utert werden m ssen 2 2 Computing with Words Computing with Words baut auf Fuzzy Logik also auch auf den im vorherigen Kapitel erkl rten Methoden auf Daher werden bei Computing with Words Mengen vereinigt und Namen zugeteilt Nennen wir diese Men ge g und das diese Menge beschreibende Wort w Die se Darstellung wurde bereits in der Fuzzy Logik unter den Fuzzy Sets eingef hrt Dabei kann das Wort ato mar sein z B jung oder einen Verbund darstellen z B nicht jung Diese Menge g spiegelt die Bedeu tung des
141. dem THE System liefen Pro gramme zur Kompilerung Ausf hrung und Ausgabe von Algol 60 Programmen Schicht 5 Auf der obersten Stufe in dieser Schichtarchitektur steht der Benutzer Durch diese hierarchische Architektur ergeben sich einige g nstige Eigenschaften die Dijskstra im Anhang zu 3 anf hrt Ein Prozess einer Schicht kann nur Dienste von Prozessen die eine Schicht darunter liegen in Anspruch nehmen Dadurch kann ein Prozess der eine Aufgabe erledigt nur endlich viele Aufgaben erzeugen die die Prozesse in unteren Schichten abarbeiten weil Zyklen ausgeschlossen sind Die hierarchische Prozessarchi tektur verhindert au erdem zyklisches Warten Das hei t es kann nicht passieren dass ein Prozess P auf Prozess Q wartet der auf Prozess R wartet der auf Prozess P wartet Wiederverwendung ist ein wichtiges Problem in der Softwareentwicklung In komplexen hierarchischen Systemen ist die Wiederverwendbarkeit der Komponen ten ausschlaggebend f r die Wartbarkeit Die Erweite rung moderner Softwaresysteme um neue Features z B zur Performanzsteigerung die mehrere Komponen ten ver ndern f hren meist zu einer Vernachl ssigung des Schichtarchitekturkonzepts nderungen am Soft 33 waresystem betreffen oft viele Komponenten und die Schnittstellen zwischen den Komponenten werden um gangen Das f hrt dazu dass der Quellcode schwer verst ndlich wird und die Wiederverwendbarkeit der Komponenten nicht mehr gegeben ist
142. den 4 Reviewer zuge wiesen Drei davon stammten aus dem Kreis der Semi naristen einer war standardm ig der Lehrveranstal tungsleiter Hiezu mag Skepsis auftreten Man k nnte meinen dass sich einerseits Studierende so wenig kritisieren werden wie eine Kr he einer anderen und au erdem l ge zu diesem Zeitpunkt ja noch kaum Begutachtbares vor Beide Bedenken d rfen als falsch verworfen wer den Auch aus den in der Regel eine Seite umfassenden Ersteinreichungen ist nicht nur f r ge bte Reviewer sondern auch f r Studenten die bereit sind sich dieser M he zu unterziehen ersichtlich ob hinter dem knap pen Text bereits Substanz steht oder ob nur rasch etwas einigerma en plausibel erscheinendes abgege ben wurde Freilich variierten diese Einreichungen in Qualit t und Umfang stark Doch ein zu viel ist an dieser Stelle ebenso unpassend wie ein zu d nn Der Begutachtungsprozess wurde mit dem open source Produkt MyReview 3 durchgef hrt F r diese Begut achtung stand ein Zeitraum von 14 Tagen zur Verf gung Dass bereits dieser erste Schritt ein Filter war mag daraus ersehen werden dass von insgesamt 27 Themeneinreichungen nur mehr 25 Studierende eine Kurzfassung abgaben und am Reviewprozess teilnahmen In der n chsten Phase nach den Osterferien waren Kurzvortr ge in der Dauer von 8 Minuten vorgesehen In diesen Vortr gen sollten die Studierenden einerseits den Ausgangsartikel ihrer Arbeit in knappe
143. derungsanalyse Architektur Definition und Evaluierung Komponenten entwicklung COTS Einbindung Testing Im technischen Management die technische Planung Risikomanagement Konfigurationsmanagement Prozessdefinition Tool Unterst tzung Im organisatorischen Management die Marktanalyse Finanzierung Planung Organisationsstruktur Risikomanagement Training 15 Wie diese Aktivit ten der Areas angewendet werden wird in Patterns beschrieben Patterns sind L sungsans tze f r wiederkehrende Probleme wie sie schon in der technischen Applikationsentwicklung eingesetzt werden Sie helfen bei der Einf hrung und Umsetzung von Product Line Engineering in einem Unternehmen 15 Es gibt einige Unternehmen die Product Line Engineering erfolgreich eingesetzt haben Darunter befinden sich Firmen wie Alcatel Hewlett Packard Philips Boeing und Robert Bosch GmBh 15 5 Dom nenspezifische DSM Modellierung Der am h ufigsten eingesetzte Artefakttyp f r die technische Umsetzung bei Produktlinien sind objekt orientierte Software Komponenten implementiert in einer objektorientierten General Purpose GL Programmiersprache Diese Komponenten werden wieder in GL Sprachen zu einem System zusammengef gt Ein weniger verbreiteter schwieriger Ansatz aber viel versprechend im Grad der Wiederverwendung sind modellorientierte Ans tze MDE Model Driven Engineering die in direkten ausfiihrbaren Code kompiliert
144. des Prob lembereichs zu organisieren worauf vorher noch nicht gesto en wurde 16 In anderen Worten es muss m glich sein den Inhalt einer Ontologie zu erweitern und zwar so dass der Inhalt kosteneffektiv gefunden und verwendet werden kann Aus heutiger Sicht gibt es noch eine Reihe von unge l sten Problemen im Zusammenhang mit Ontologien 15 e Wie lassen sich gut verwertbare Metadaten f r sehr gro e Ressourcenbest nde erzeugen und konsistent weiterentwickeln e K nnen Ressourcen eindeutig klassifiziert werden e Wie lassen sich Metadaten in Ontologien ein ordnen e Macht es Sinn nach einer gemeinsamen Uni versalontologie zu suchen 101 Forschungen untersuchen unter anderem M glichkei ten eine Notation f r eine gemeinsame Ontologie zu entwickeln die disziplin bergreifend in der Informatik Anwendung finden kann 15 Aktuelle Bedeutung erlangten Ontologien im Zusam menhang mit der Entstehung des Semantic Web 6 Zusammenfassung In meinem Ausgangsartikel nahm sich Sol J Green span der Probleme des RE an Diese Probleme bestan den haupts chlich in schlecht formulierten inkonsis tenten Anforderungen welche zu unproportional kos tenintensiven Korrekturen oder im worst case zu einem Projektabbruch f hren k nnen In Abschnitt 3 verdeut lichte ich Greenspans Versuch solche Fehler in der Anforderungsanalysephase mittels einer expliziten Wissensdarstellung zu verhindern Er bediente sich dabei
145. die nicht von au erhalb kommen Dies impli ziert die F higkeit ein Softwaresystem zu erzeugen welches aus mehreren von unabh ngigen Quellen be zogenen Komponenten besteht Selbst die Assemblie rung des Systems durch einen externen Systemintegra tor ist damit denkbar 3 Interfaces Die Sicherstellung derart flexibler Verwen dung von Komponenten bedingt vertraglich spezifizier te und dokumentierte Schnittstellen Ein Interface Schnittstelle definiert wie eine Komponente angesp rochen werden kann und wie sie mit anderen Kompo nenten verbunden wird Dar ber hinaus legt ein Inter face auch fest welche Operationen von der Komponen te angeboten werden Zu jeder Operation sollten Vor und Nachbedingungen vereinbart werden Die meisten g ngigen Programmiersprachen verf gen ber die M glichkeit Schnittstellen explizit zu deklarieren da durch wird das Verbergen von Implementierungsdetails unterst tzt Was aber fehlt sind standardisierte Interak tionsprotokolle Diesem Umstand wird durch die soge nannten Komponentenmodelle Rechnung getragen welche in einem eigenen Kapitel behandelt werden Kontext Abh ngigkeit Viele Komponenten ben ti gen zur Bereitstellung ihrer Funktionalit t zuerst ein mal Input m ssen also beim Aktivieren mit geeigneten Informationen versorgt werden oder ben tigen ihrer seits Dienste anderer Komponenten Ebenso sind Komponenten implementierungstechnisch meistens an bestimmte Komponentenmodelle
146. dvices Die Aspekte k nnen hier jedoch keine sprachspezifischen Elemente enthal ten wie es bei AspectJ der Fall ist Aspekt Deklaratio nen in AspectJ k nnen ja Java Konstrukte enthalten Das erm glicht Aspekt Verhalten einer Sprache auch auf eine andere Sprache anzuwenden Aspekte werden in Weave NET mithilfe einer XML Beschreibungssprache definiert Aspekte wer den in einer separaten XML Datei gehalten Der Wea ve NET Weaver ist als INET Komponente implemen tiert Er akzeptiert eine Komponentensammlung und eine XML Datei die die Definitionen der Aspekte enth lt als Input Der Weaver f gt die Aspekte auf der Ebene der CLI Intermediate Language IL ein und ge neriert eine neue Komponentensammlung Im folgenden m chte ich anhand des Beispiels aus 6 das den Aspekt des Loggings beschreibt in die sem Fall ein Terminal das die Eingaben und Ausga ben mitlogt die Unterschiede zwischen AspectJ und Weave NET hinsichtlich der Aspekt Deklaration zei gen Zun chst der Code f r die Komponentendeklara 37 tion wie er in AspectJ geschrieben w rde public class Terminal extends TerminalConsole public void WriteLine String s Write s n Nun die Aspektdeklaration zum Logging Aspekt in AspectJ export System aspect IOChecker pointcut Write object data execution x TerminalWritex amp amp args data before object data Write data LogWrite data public void LogWrite object
147. e Application Software Projects Some Experimental Results IFIP 8th World Computer Congress 1980 14 Russell Glen W Experience with Inspection in Ultralarge Scale Developments IEEE Software Vol 8 No 1 Jan 1991 pp 25 31 15 Weller Edward F Lessons from Three Years of Inspection Data IEEE Software Vol 10 No 5 Sept 1993 pp 38 45 16 Monvorath Phongpaibul und Barry W Boehm An Empirical Comparison Between Pair Development and Software Inspection in Thailand ACM Press Proceedings of the 2006 ACM IEEE international symposium on empirical software engineering 2006 17 C R U 1 S E Component Reuse In Software Engineering C E S A R e Books 2007 http cruise cesar org br Letzter Zugriff 14 07 2007 18 Standard ECMA 335 Common Language Infrastructure Ath Ed Juni 2006 ECMA International 2006 http www ecma international org 19 Humphrey W S A Discipline for Software Engineering Addison Wesley 1995 ber Wissensrepr sentation zu Anforderungsmodellen Martin Andritsch 0060102 m2andrit edu uni klu ac at Abstract Ausgehend von einem Artikel aus dem Jahre 1982 von Sol J Greenspan 1 in dem er die Wichtigkeit der ausreichenden Wissensansammlung bzw in weiterer Folge deren Strukturierung und Repr sentation im Bereich des Requirements Engineerings betonte m ch te ich mit meiner Arbeit versuchen die fortw hrende Bedeutung des Wissensmanagements bis hin zu heuti gen Sof
148. e Projektaktivit ten in gleichnamige Phasen ein In jeder Phase werden Ergebnisse in Form von Dokumenten 72 produziert die als Input in der Folgephase ben tigt werden Am Ende jeder Phase werden Teilziele die so genannten Meilensteine erreicht an welchen der Projektverlauf messbar ist Eine Phase kann somit als Zeitspanne zwischen zwei Meilensteinen aufgefasst werden Grunds tzlich gilt dass sich beim phasenori entierten Entwicklungsansatz die einzelnen Teilphasen nicht berlappen und jede Phase abgeschlossen sein muss bevor die n chste startet Bekannte Vorgehens modelle mit phasenorientiertem Ansatz sind das klassische Wasserfallmodell das Phasenmodell und das V Modell Iterative Entwicklung Beim iterativen Ansatz werden die Prozessaktivit ten in Iterationsrunden mehrmals ausgef hrt Einsatz findet diese Herange hensweise h ufig bei Systemen in welchen die Anforderungen von Beginn an nicht vollkommen klar sind oder aber bei gro en Systemen die nicht in einem Zug entwickelt werden k nnen Jede Iteration kann als Teilprojekt aufgefasst werden wobei nach Iterationen ein Gesamtsystem entsteht Mit dem Spiralmodell als bekannten Vertreter dieser Gruppie rung setzt der iterative Entwicklungsansatz auf die fr hestm gliche Reduzierung der Projektrisiken Iterative Softwareentwicklung bietet einen L sungsan satz um ad quat auf nderungen in den Kundenanfor derungen reagieren zu k nnen Sie findet h ufig b
149. e Definition der Sprache Um nachtr gliche nderungen ohne gro en Aufwand durchf hren zu k nnen muss die Sprache Flexibilit t unterst tzen Flexibel sollte die Sprache auch dann sein wenn es mehrere M glichkeiten zum L sen eines Problems gibt Mit Little JIL wird der Prozess als Hierarchie von Steps gesehen Das Programm ist quasi ein Baum mit Bl ttern wobei jedes Blatt einen Agenten darstellt Ein Agent kann entweder ein Mensch sein der Reisende in Abbildung 1 oder auch der Requirements Engineer bei der Bedarfsanalyse sein oder eine Maschine wie der Reservierungsautomat in Abbildung 1 oder ein im Softwareentwicklungsprozess verwendetes Werkzeug Ein Agent bew ltigt einen kleinen Arbeitsabschnitt im Softwareentwicklungsprozess und gibt entweder einen gefunden Fehler oder den erfolgreichen Abschluss seines Arbeitsschrittes zur ck agent Traveler PlanTrip Vv TripDates agent TravelAgent __ ea S PlaneReservation InBudget Z gt NoUnited gt NoUSAir NoMoreChoices NoPlane V UnitedReservation J J USAir Reservation A DaysInnReservation u 5 A E al NotInBudget HotelReservation In Little JIL wurden auch Ausnahmen ber cksichtigt Es k nnen Ressourcen fehlen oder Parameter nicht stimmen und dazu k nnen geeignete Exceptions entworfen werden die von Handlern behandelt werden und dem Eltern Step bergeben werden Um eine Kommunikation zwischen den einzel
150. e im Ansatz von B rstler in 1 ein Mechanis mus eingef hrt der beispielsweise f r die Suche nach kind collection tree binary auch die Komponenten finden w rde die mit kind collection tree n ary klassifiziert wurden Jedoch wird daf r ein Faktor ber cksichtigt der aussagt dass dies kein exakter Treffer ist Diese Abh ngigkeiten un ter den einzelnen Spezialisierungen werden ebenso im Klass ifizierungs Schema durch spezielle Relationen definiert 1 5 3 Semantik basierte Klassifizierung Der semantik basierte Klassifizierungs Ansatz der von Yao und Etzkorn in 13 verfolgt wird bezieht sich auf das World Wide Web als Software Bibliothek die wiederverwendbare Software Komponenten beinhaltet 13 Dieser Ansatz baut auf Semantic Web 3 DAML OIL sp ter durch OWL abgel st RDF WSDL und UD DI auf RDF besteht aus einem object attribute value Modell wobei object eine Ressource attribute eine Ei genschaft und value einen freien Text darstellen Durch dieses Tripel kann Information ohne Verlust an Sinnhaftig keit zwischen mehreren Applikationen ausgetauscht werden Die Ontologie Sprache DAML OIL wurde ebenso speziell f r das Semantic Web realisiert und erweitert RDF WSDL ist eine auf XML aufbauende Sprache die Web Services be schreibt UDDI ist ein Verzeichnis bei dem Web Services registriert werden um diese wiederzufinden 13 Ausgehend von diesen Technologien wurde in 13
151. e komplex eine solche Pr fung sei 2 2 Rhapsody Heutige Positionierung des Ent wicklungswerkzeuges Die im Artikel 7 von David Harel und Eran Gery vorge stellte Entwicklungsumgebung mit dem Namen Rhapsody definiert sich heute als eines der f hrenden Werkzeuge f r Model Driven Software Develpment MDSD Die zu diesem Zeitpunkt aktuelle Version 7 1 nterst tzt Code und Modell zentrierte Workflows wobei mit Hand er stellter Code von Rhapsody automatisch in Modelle umge setzt werden kann Diese lassen sich im weiteren Verlauf zur Programmanalyse und als Dokumentation verwenden Beim Modell getriebenen Ansatz kann der Entwickler auf einer h heren Abstraktionsebene mit grafischen Modellen arbei ten und sich den Programmcode automatisiert generieren lassen 3 MODEL DRIVEN SOFTWARE DEVELOP MENT MDSD Im Gegensatz zur Modell basierten Entwicklung bei der Modelle haupts chlich das System dokumentieren r cken diese beim Model Driven Software Development ins Zen trum Dieser Ansatz kann als eine nat rliche Fortsetzung der Programmierung wie wir sie kennen gesehen werden und abstrahiert diese Konzepte weiter Der Programmcode stellt eine andere Sicht auf das Modell dar und soll so weit wie m glich automatisiert aus den Modellen synthetisiert werden 2 11 Thomas Stahl und Markus V lter beschreiben die Zielset zung in 11 mit folgenden Worten Das Ziel von MDSD ist es daher dom nenspezifische A
152. e simplicity with which they could be used and the seaming less integration into the operating system was innovative however In 1981 Brian W Kernighan and John R Mashey published their paper about UNIX as a programming environment 2 At this time UNIX was still quite new In their paper the two authors described what was revolutionary about the new system and how this had an impact on programming habits This paper investigates if these revolutionary ideas are still of interest in today s world and where development has led them to To get a perspective on these ideas the three factors which according to Kernighan and Mashey 2 enabled this development are discussed up front 1 The file system which is unique in its uniform perspective of the underlying system 2 A command interpreter with a very capable command language 3 The very rich set of tools 2 1 The UNIX file system The UNIX file system is the cornerstone on which the success of the operating system builds It has a hierarchical structure and can be represented as a tree with a single root node where every internal node is a directory and all leaves are either directories or files Most of the modern file systems are laid out in this way What made and makes it special in its way are the design choices taken in its development Due to these the file system can be characterized by e consistent treatment of file data the kernel hides the internal format in which
153. e this even simpler a file that is marked as executable and contains text is automatically interpreted by the shell if it is executed without needing the indirection over I O redirection By doing so a shell procedure gets indistinguishable from a regular program SH lt CMDFILE Listing 2 Input Redirection with the shell Another interesting feature offered by VO redirection is program connection By directing a file which was the output of a program to be the input of another program the second program gets dependent on the first one PROGRAM1 gt TEMPFILE PROGRAM2 lt TEMPFILE Listing 3 Program connection by I O redirection Listing 3 shows how the output of PROGRAM is redirected to a temporary file In the next step this temporary file serves as input for PROGRAM thus connecting the two programs through the temporary file 2 2 3 Pipes The preceding chapter showed how two programs can be interconnected to achieve some greater functionality It seems silly to have to use temporary files to capture the output of one program and direct it into the input of another The UNIX pipe facility performs exactly this serial connection without any need for a temporary file 2 PROGRAM1 PROGRAM2 Listing 4 Program connection by a pipe Through this piping technology any programs that hold the convention of reading STDIN and writing to STDOUT can be connected by a pipe To yield a meaningful overall
154. e und zugleich formale Modelle ein deutlich effekti verer Ansatz pr sentiert Mit abstrakten Modellen welche sich durch Kompaktheit und Reduktion auf das Wesentliche beschr nken wird das n tige Abstraktionsniveau erreicht Durch die exakte formale Spezifikation erhalten die Modelle eine gleichwertige semantische Aussagekraft wie der Pro grammcode Dies ist so zu verstehen dass aus den Dia grammen ein Gro teil der Implementierung generiert wer den kann 11 Modelle werden somit zum Bestandteil des Systems selbst und nicht nur wie in der modellbasierten Entwicklung als Dokumentation angesehen Diesem Umstand wird auch mit der Abgrenzung im Namen Rechnung getragen in dem ex plizit auf Modell getrieben Bezug genommen wird Durch dieses Potenzial wird die Softwareentwicklung erheblich be schleunigt und qualitativ erheblich verbessert 11 3 4 Konzepte Eine andere Definition von MDSD die 12 zugrunde liegt lautet Modellgetriebene Softwareentwicklung Model Dri ven Software Development MDSD ist ein Oberbegriff f r Techniken die aus formalen Modellen automatisiert lauff hi ge Software erzeugen Techniken und Konzepte die in diesem Zitat angesprochen sind bilden die Basis f r die modellgetriebene Entwicklung bilden und werden in diesem Kapitel genauer betrachtet Die folgenden Konzepte werden falls nicht anders zitiert aus den entsprechenden Kapiteln von 12 zusammengefasst 3 4 1 Metamodel
155. e verwendeten goto Statements indirekt proportional zu dessen Qualit t zu sehen ist Das be deutet dass je mehr goto Befehle ein Programm oder Codest ck enth lt desto eher m ssen Lesbarkeit Wartbarkeit Beweisbarkeit oder gar die Funktionalit t darunter leiden 01 09 Durch das Aufkommen von strukturierter Program mierung hat sich sehr schnell die Meinung verbreitet es sei nichts anderes als goto frei zu programmieren Hier hat Mills pr gnant reagiert Structured programs should be characterized not simply by the absence of goto s but by the presence of structure 14 Die Eliminierung von goto Anweisungen aus beste hendem Code ist heute fast automatisch durch eine alternative Darstellung mittels Sequenz Wiederholung und Entscheidung m glich Es gibt heutzutage auch schon Softwarepakete welche alte teure Programme in eine neue Sprache bersetzen um sie auf neuer Hard ware wieder lauff hig zu machen Bei einer einfachen Umsetzung ist jedoch nicht zu erwarten dass das Er gebnis leichter zu lesen oder effizienter in der Abarbei tung ist Wirth belegt dies in 01 anhand einiger aus sagekr ftiger Beispiele Dies soll jedoch nicht bedeuten dass strukturierte Programmierung ganz ohne Sprunganweisungen aus kommen soll im Gegenteil diese Anweisungen geben einem Rechner die einzige M glichkeit komplexe Kontrollstrukturen abzuarbeiten Die Existenz solcher Befehle soll hier ausschlie lich vom Level der Abstrak
156. ea of component based development chapter 3 1 where we also want to reduce programming as far as possible e Shell programming can be used to build a prototype for complex solutions before it is implemented in a fully fledged programming language Since shell programming is more cost effective than normal development such a prototype can be easily thrown away if it does not fit the needs e A lot of programs need to be continually modified and live through a kind of evolution until the program settles at a solid state This is especially true if requirements are continually changing or are not even clear in the first place A prototype in form of a shell procedure can help greatly in pushing the effort and resources spent compared to the achieved output ratio in a positive direction Since the shell procedures follow a quite natural language 8 and are built up out of components changes can be incorporated with relatively low cost and in quite few time e When a program has reached its stable state the available shell procedure can be checked for performance gaps and these parts can then be implemented in fully fledged programming languages 5 Conclusion The first part of the paper showed how a very well designed file system that offers some quite unique concepts can greatly enhance the flexibility of programs without needing any actual changes to the implementation itself After this the UNIX command interpreter the shell
157. ed Scheduling Fuzzy Systems Proc 2004 IEEE International Conference on University of Nottingham 2004 13 M Gerke M Grof Seminar Fuzzy Logik Fachgebiet Elektrotechnik FernUniversit t Hagen 2001 127 ANHANG klein mittel gross u vu wu wu w vu O00000000 O NWARUTONOO o 20 40 60 80 100 120 Abstand m Abb 8 Fuzzyfizierung der Variable Abstand klein mittel hoch uoo u uoo u uo u v v oo0o0000000 O ANDVDPRUNNDO o 30 60 90 120 150 180 Geschwindigkeit m s Abb 9 Fuzzyfizierung der Variable Geschwindigkeit 128 schwach mittel stark u u uo u w u u ooo0oo0o0000o0 O ANVBPRUIONAGO 15 3 45 6 75 9 Verz gerung m s Abb 10 Fuzzyfizierung der Variable Bremskraft Regelbasis eae ae ee a ee ica ed rar a ae ed A Be eee ar ed es Ei alin il bica Ci vee ee a a in bli lien el iced inl lu al nna hel mio Se aian a kana anl amaaa mAn e inl sil Abb 11 Regelbasis f r das Bremssystem laut Experten 129 schwach mittel stark eo w O00000000 O NWARUOANDOO 1 5 4 5 556 7 5 CoA Abb 12 Defuzzyfizierung der Bremskraft Bilder der Simulationssoftware miata Abstand Geschwindig Abstand Geschwindig Bremsen Bremsen Abb 13 Modellierung des Bremssystems in SuccoSoft Tabellen Regel Editor Matrix WENN DANN Abstand Geschwindigkeit DoS Bremsen
158. edge also Wissen ber den Prob lem Anwendungsbereich anzueignen und zu verste hen Dies umfasst unter anderem die Organisation und das System in dem die fertige Software eingesetzt werden soll Es w re zum Beispiel bei der Entwicklung eines Informationssystems f r ein Krankenhaus wich tig sich mit einer Reihe von Inhalten die ein Kranken haus betreffen vertraut zu machen Wie z B medizini sches Wissen Krankenhausabl ufe Therapiem glich keiten usw 1 In weiterer Folge muss dieses Wissen strukturiert organisiert und in dieser Phase von Details abstrahiert werden um auch allen Stakeholdern verst ndlich zu sein Schlie lich soll auch ein anderes gro es Problem des Requirements Engineerings RE gel st werden das der mangelnden Kommunikation mit den Benut zern 2 Modeling the World Die Konstruktion einer abstrakten interpretierbaren Beschreibung ist also eine fundamentale Aktivit t im Requirements Engineering geworden 4 und l sst sich auch mit den Begriffen Informationsmodellierung oder konzeptuellen Modellen formulieren Unter dem Beg riff Informationsmodellierung versteht man die Kon struktion von computerbasierten symbolischen Struk turen die einen bestimmten Bereich der Welt den Problembereich abbilden 3 Diese Strukturen k n nen auch als Wissensbasis genutzt werden die ber eine lange Zeitperiode hinweg weiterentwickelt wird und als Wissens Repository immer wieder verw
159. eeler Bill Brykczynski und Reginald N Meeson Jr Software Inspection An Industry Best Practice IEEE Computer Society 1996 4 M E Fagan Advances in Software Inspections IEEE Transactions of Software Engineering Juli 1986 5 Boehm Barry W Software Engineering Economics Prentice Hall Englewood Cliffs 1981 6 National Aeronautics and Space Administration Software Formal Inspection Standard Approved 1993 7 Michael Fagan Associates http www mfagan com letzter Zugriff 22 Mai 2007 8 Karl Wiegers Seven Deadly Sins of Software Reviews Process Impact http www processimpact com articles revu_sins html letzter Zugriff 21 Mai 2007 9 Eclipse Project http www eclipse org 10 Jetbrains S R O http www jetbrains com 94 11 Hanna Hulkko und Pekka Abrahamsson A multiple case study on the impact of pair programming on product quality ACM Press 2005 International Conference on Software Engineering Proceedings of the 27th international conference on Software engineering Agile Sessions Pages 495 504 12 Charline McDowell Linda Werner Heather Bullock und Julian Fernald The Effects of Pair Programming on Performance in an Introductory Programming Course ACM Press 2002 Technical Symposium on Computer Science Education Proceedings of the 33rd SIGCSE technical symposium on Computer science education CS Session Pages 38 42 13 Bohm Barry W Developing Small Scal
160. ei modernen Prozessmodellen Einsatz Inkrementelle Entwicklung Im Gegensatz zum iterativen Ansatz der in jedem Iterationsschritt das Produkt verfeinert bis ein Gesamtsystem entsteht werden bei der inkrementellen Entwicklung in Zyklen neue Systemteile Inkremente erstellt und in einem Kernsystem integriert Voraussetzung ist dass es sich beim Gesamtsystem um ein offenes System handelt welches in Ausbaustufen realisiert wird vgl 6 pp 164 Die inkrementelle Entwicklung hat den enormen Vorteil dass bereits fertige Systemteile an den Kunden geliefert werden k nnen Der Kunde ist somit fr hzeitig in der Lage Tests durchzuf hren und ein Feedback zu erstellen Aufgrund der Tatsache dass Systemteile mit hoher Priorit t als erstes entwickelt und ausgeliefert werden reduzieren sich mit diesem Ansatz auch die Projektrisiken vgl 5 pp 102 Evolution re Entwicklung Diese Vorgehensweise erweist sich als hilfreich wenn die Spezifikation nicht ausreichend genug ausgearbeitet werden konnte oder der Auftraggeber keine klare Vorstellung vom Endprodukt hat Die Prozessaktivit ten finden in diesem Ansatz parallel statt und tauschen gegenseitig Informationen aus Grunds tzlich werden zwei Richtungen in der evolution ren Entwicklung unterschieden Erstens die explorative Entwicklung mit dem Ziel in Kooperation mit dem Kunden die exakten Systemanforderungen herauszufinden Zweitens anhand eines Wegwerf Prototypen die Kundenbed rf
161. ei UDDI registriert und somit ffentlich zur Verf gung stellt 13 Vergleicht man nun diesen Ansatz mit der Arbeit von Prieto Diaz und Freeman in 11 wird ersichtlich dass vom facetten orientierten Klassifizierungs Schema abgewichen wird Auch der konzeptionelle Graph bekommt bei diesem Ansatz eine andere Bedeutung zugesprochen Auch Penix et al definieren in 9 einen Ansatz der seman tische Eigenschaften verwendet um Software Komponenten zu klassifizieren und wiederzufinden 5 4 Behavior Sampling Podgurski und Pierce kritisieren in ihren Ansatz in 10 dass bestehende Wiederauffindungsmethoden und Bibliotheken wie zum Beispiel das Library System von Prieto Diaz und Freeman aus 11 Source Code als puren Text interpretie ren und auf dessen Ausf hrbarkeit als Unterst tzung f r Software Reuse vergessen 10 Wie allgemein bekannt ist transformiert Software Input zu Output Dieser einfachen Eigenschaft macht sich der An satz von Podgurski und Pierce in 10 zu nutze ein Benut zer in der Literatur als Searcher bezeichnet der auf der Suche nach einer bestimmten Software Komponente ist spe zifiziert ein Interface f r diese Komponente Dieses Interface muss folgende Eigenschaften definieren 10 e Anzahl der Parameter e Datentypen der Parameter e Modi der Parameter Input bzw Output Das Interface das von einem Benutzer spezifiziert wird wird von Podgurski und Pierce in 10 als target interface
162. einerung des Domain Engineering in Verbindung mit dem konventionellen Software Engineering Einen Einblick in Domain Engineering mit dem Fokus auf Produktfamilien eines Unternehmens zeigt Kapitel 4 Dom nenspezifische Modellierung in Kapitel 5 soll M glichkeiten der Wiederverwendung auf h herer Abstraktionsebene als komponentenorientierte Entwicklung zeigen 2 1989 Domain Analysis Engineering Wiederverwendung Es besteht eine gro e L cke zwischen dem informalen impliziten Wissen einer Dom ne und der notwendigen expliziten formalen Form von wieder verwendbaren Informationen Es gibt aber keinen systematischen Ansatz diese wieder verwendbaren Informationen zu erstellen Der Domain Engineering Prozess soll mit wohl definierten Aktivit ten und Zwischenprodukten diese Informationen erzeugen Arango verwendet den Begriff Wiederverwendungs infrastruktur reuse infrastructure in der die notwendigen Informationen fiir den Wiederverwender zu Verf gung gestellt werden Der DE Prozess beinhaltet 3 grundlegende Interessen 1 1 Domain Analysis die Identifizierung Erfassung und Evolution von wieder verwendbarer Information in einer Dom ne Diese Informationen werden in einem Modell der Dom ne zusammengefasst Das Modell dient als Input f r die n chste Aktivit t 2 Infrastruktur Spezifikation die Selektion und Organisation der Informationen passend f r die Umgebung der Wiederverwender Als Ergebnis entsteht eine Ar
163. eiten Weiters waren dies das Design der Visualisierung Aufzeichnung und Messung von Prozessdaten die Einbindung von nderungen im Prozess und die Wichtigkeit der Anforderungsanalyse und anderer T tigkeiten des Softwarelifecycles 5 Little JIL Juliette sprache und Interpreter Prozessdefinitions Little JIL ist eine Programmiersprache mit einer grafischen Syntax die unter Mitwirkung von Leon Osterweil entwickelt wurde Trotzdem Little JIL grafisch ist hat sie eine sehr strikte pr zise Semantik fast vergleichbar mit der einer textuellen Programmiersprache Sutton 97 Bei der Entwicklung von Little JIL wurde besonders auf vier Punkte geachtet Einfachheit Ausdrucksst rke Pr zision und Flexibilit t Nachdem Little JIL auf einer grafischen Syntax basiert und dadurch leicht zu benutzen und zu verstehen ist ist sie f r die Entwickler genauso wie auch f r Laien wie z B Kunden einfach zu interpretieren und zu handhaben Obwohl die Sprache sehr einfach ist ist sie dennoch ausdrucksstark Auf Grund der verschiedenen Abl ufe in einem Softwareprozess aber auch der Koordination dieser muss die Prozessbeschreibungssprache f hig sein diese Abl ufe klar darzustellen Die Prozessbeschreibungssprache dient im Endeffekt dazu einen Code zu produzieren der auch ausf hrbar ist Weiters soll das Ergebnis auch analysierbar sein um z B Fehler aufdecken zu k nnen oder um eine Verl sslichkeit zu garantieren Dazu dient die pr zis
164. el von Kiczales et al 4 beschrieben FigureElement bn incrXY int int getX int getX int getY int getY int setX int setX int setY int setY int MoveTracking incrXY int int incrXY int int Abbildung 2 Modell eines Figure Editors 4 Abbildung 2 zeigt das Modell eines Figure Edi tors Die Box MoveTracking zeigt einen Aspekt der zu Methoden in der Line und der Point Klasse querschnei det Figure stellt eine Factory dar die Line Objekte erzeugt die wiederum jeweils aus zwei Punkten beste hen Point ptl new Point 0 0 Point pt2 new Point 4 4 Line Inl new Line ptl pt2 Inl inc XY 3 6 Am Beginn der Ausf hrung werden zuerst zwei Punkte intialisiert Danach wird mit diesen zwei Punk ten eine Linie initialisiert Bei der Ausf hrung der Me thode incrXY wird eine Berechnung durchgef hrt Die Join Points die diese Berechnung durchl uft sind in Abbildung 3 zu sehen Abbildung 3 Durchlaufene Join Points im Figu re Editor 4 35 l Ein Method Call Join Point der zur Methode incrXY geh rt wird im Objekt In1 aufgerufen 2 Ein Method Call Reception Join Point an dem ini den Aufruf von incrXyY erh lt 3 Ein Method Execution Join Point an dem eine bestimmte incrXY Methode die in der Klasse Line definiert ist beginnt mit der Ausf hrung 4 Ein Field Get Join Point an dem das Feld __p1 von 1n1 gelesen wird 5 Ein Method
165. el zu entwickeln Dies eliminiert jedoch nicht die Notwendigkeit des Testens eines fertigen Produkts Ein weiteres der am meisten sichtbaren Ergebnisse von strukturierter Programmierung ist dass das Ergeb nis also der entwickelte Code v llig frei von goto Statements ist die nicht zur standardm igen Abarbei tung der vorgeschriebenen Kontrollstrukturen ben tigt werden 2 3 Was hat das goto Statement damit zu tun Man muss sich vor Augen halten zu welcher Zeit und in welcher Umgebung von Programmiersprachen das Konzept der strukturierten Programmierung gerade aufgekommen ist Der f hrende und gebr uchlichste Vertreter war wohl immer noch Assembler jedoch r ckten 3GL Sprachen wie Cobol und Fortran immer mehr in den Mittelpunkt Zu der Zeit lud jedoch noch kaum eine bestimmte Sprache zu einer strukturierten Vorgangsweise ein Im Gegenteil entsprechende sprachliche Konstrukte wurden zum Teil erst im Nach hinein oder in Folgeversionen in die einzelnen Spra chen integriert Die Verwendung von goto Statements also direkten Spr ngen von einer Codezeile im Programm zu einer anderen stand an der Tagesordnung Zus tzliche Schleifendurchg nge oder berfl ssige Vergleichsope rationen wurden m glichst eingespart In den meisten F llen f hrte dies zwar zu effizientem Code die Les barkeit und auch die Wartbarkeit lie en jedoch zum Teil zu w nschen brig Man hatte jedoch bereits erkannt dass die Anzahl der im Quellcod
166. ellt werden 7 Weiter Motivationsgr nde sind die verbesserte Qualit t die Reduktion von Wartungszeiten einfachere Weiterentwicklungen bessere Handhabung 106 von Komplexit t und der Kostensch tzung 7 Verbesserung Der Begriff Product Line Engineering wurde von dem Software Engineering Institut SEI gepr gt und verfeinerte das Konzept von Domain Engineering im Kontext eines Unternehmens A software product line is a set of software intensive systems that share a common managed feature set satisfying a particular market segment s specific needs or mission and that are developed from a common set of core assets in a prescribed way 15 Die drei grundlegenden h chst iterativen Aktivit ten sind Core asset development Product development und Management wie in Abb 33 ersichtlich Product Line Development y Core Asset Development Product Development Rae Management Domain Engineering ae Application Engineering Abb 3 Grundlegende Produktlinien Aktivit ten 17 Core Asset Development Entwicklung der Artefakte Die wieder verwendbaren Artefakte bilden die Basis fiir die Entwicklung von Produkten Core Assets sind Architekturen wiederverwendbare Software Komponenten Dom nenmodelle Anforderungen Dokumentation Spezifikationen Performanzmodelle Zeitpl ne Budget Testpl ne Testf lle Prozessbeschreibungen etc Die Architektur ist der Schl s
167. en det werden kann z B um die allf llige Wartung des Produktes zu erleichtern 3 ber die Jahre wurden hunderte solcher Notationen und Anforderungsmodel lierungssprachen entwickelt die diese Aufgabe erf l len sollen von denen allerdings eine Vielzahl nur in einem einzigen Projekt angewandt wurde 10 Ich m chte an dieser Stelle auch den Unterschied zwi schen einer Modellierungssprache wie sie oben er w hnt wurde und einer Spezifikationssprachen fest stellen Spezifikationssprachen haben eine hoch entwi ckelte mathematische Formulierung als Grundlage z B Z und dienen als direkte Vorstufe der Implementie rung w hrend Anforderungsmodellierungssprachen ein erstes abstraktes formales Modell des Problembe reichs liefern und sich somit weit vor der Spezifikation anzusiedeln 5 Zusammenfassend l sst sich sagen dass die Idee des World Modeling die ist Entit ten Aktivit ten und andere Ph nomene als Objekte in einem Modell zu erfassen 96 Abb 1 Aufteilung der Welten 6 Weiters kann nach 6 der Anwendungsbereich Uni verse of Discourse in zwei Welten geteilt werden der Usage World und der Subject World Die Usage World beschreibt die Aufgaben Prozedu ren und Interaktionen mitunter der Stakeholder direk ten und indirekten Benutzern Die Subject World beinhaltet Wissen ber den real world Bereich also existierende Objekte des Anwen dungsbe
168. en ber Wieder arbeitete ein Team mit Inspektionen Das zweite mit Paarprogrammierung Die Entwicklungskosten beider Projekte waren zirka identisch Jedoch war die Qualit t des zweiten Projekts weitaus besser Es wurden um 40 weniger Fehler gemacht als beim Inspektionsteam 3 4 Reuse Die Vision Software nicht mehr von Grund auf neu zu entwickeln sondern wie Bausteine aus bereits existierenden Komponenten zusammenzusetzen existiert bereits seit beinahe vierzig Jahren Damals geriet die Softwareindustrie in eine scheinbar ausweglose Situation kosteneffektive Software zu produzieren war aufgrund von konstanten Expertenmangel kaum m glich Mcllroy stellte 1968 auf einer Konferenz seinen Artikel Mass Produced Software Components vor 20 Darin beschreibt er wie man _ Basisbibliotheken wie I O Methoden mathematische Funktionen und dergleichen wiederverwenden k nnte Trotz einer breiten Akzeptanz konnte sich Softwarereuse bis heute als etablierter Standard nicht durchsetzen Erst in den letzten Jahren entstand rund um die Wiederverwendung von Softwarekomponenten ein gr er werdender Wirtschaftszweig Softwarewiederverwendung hat eine Reihe von Vor und Nachteilen vergleiche 17 S 18 21 Komponenten die f r die Wiederverwendung entwickelt werden haben einen vermeintlich h heren Qualit tsstandard gegen ber solchen die einmalig verwendet werden Sie werden intensiver fehlerbereinigt und getestet Durch den Einsatz wird d
169. en getragen haben Damals ging es ausschlie lich nur um Konsistenzpr fungen der Syntax bei den Modellen durchf hrten 13Sollte das System keine grafische Oberfl che beinhalten oder es sich um internes Verhalten welches modelliert wird handelt dann wird bei Play In Szenarien mit dem aufgrund der grafisch erfassten Anforderungen die formalen Live Sequence Charts LSCs automatisch generiert 3 9 Diese Arbeitsweise kommt im Entwicklungsprozess beteilig ten Personen entgegen die a nicht mit formalen Anforde rungsbeschreibungssprachen wie LSCs vertraut sind oder b sich diese nicht erarbeiten wollen oder einen anderen Zu gang zu dem Projekt haben Zu Letzteren geh ren unter anderen Fachleute und Dom nenexperten Anwendungsent wickler Anforderungserfasser und eventuell auch potenzielle Benutzer 3 Die Bestrebungen von Play In Szenarien zielen ab auf die Erfassung von so vielen Anforderungen wie m glich durch direktes Manipulieren der grafischen Benutzeroberfl che oh ne direkt mit LSCs in Kontakt kommen zu m ssen Play Out 9 Nachdem die Spezifikation mit Hilfe von Play In Szenarien erfasst wurde ist es w nschenswert die se nochmals mit den Forderungen der Kunden abzugleichen und zu verifizieren damit ein gemeinsames Verst ndnis vor herrscht Play Out erweitert den Ansatz um eine Kompo nente zum Testen und Validieren von Anforderungen Bei Play Out Szenarien bedient ein Benutzer die grafische Oberfl che des zu
170. enschliche Beurteilung und Vorauskalkulation im Projektmanagementbereich werden aber vollst ndig vernachl ssigt S mtliche er hobene und einsehbare Daten basieren auf aus den Ein zelkomponenten automatisch generierten Zahlen Als Beispiel liefern Testkomponenten die erfolgreich durchgef hrten Tests User und Entwicklungs Tools die fertiggestellten Komponenten User Der Faktor einer pers nlichen Evaluierung die ein Mitarbeiter selbst durchf hren oder von einem anderen Kollegen erhalten k nnte fehlt vollst ndig Damit wird einem Kernkon zept von Matsumotos Prozess den laufenden Inspekti onen ebenfalls nicht entsprochen Ein allf lliges Per sonenspektrum w re daher strukturell abbildbar in seiner Aussagekraft aber fragw rdig da die Daten voll st ndig automatisiert ermittelt werden w rden Auch der Vorberechnungsfaktor ist nicht ber cksichtigt Es k nnen zwar entsprechende Tasks mit Zeiten vordefi niert werden Verschiebungen von Zeitpl nen werden entsprechend aktualisiert das Errechnen von zuk nfti gen Entwicklungen auf bestehenden Daten ist jedoch nicht vorgesehen was die Managementt tigkeit unn tig in Richtung Kontrolle beschr nkt und den Faktor Pla nung erschwert Die Daten f r die Planung sind jedoch entsprechend vorhanden aus Matsumotos Definition eines Workitems fehlt lediglich die erwartete Reuse Rate als Attribut Der Kontrollbereich selbst erf llt damit alle Vorraussetzungen die Matsumoto an
171. entlich ineffektiver als umgekehrt Das Testen wird produktiver wenn weniger Fehler vorhanden sind Unterst tzung bekommt Russell von Edward Weller von Bull Information Systems 15 Weller best tigt durch eigene Erfahrungen Russells Aussage indem er einige Nachteile von Testen vor Inspektionen aufz hlt e Testen senkt die Motivation beim Inspektionsteam Getestete Komponenten funktionieren und lassen den Eindruck entstehen dass sie korrekt sind e Codeinspektionen k nnen Fehler aus einer vorangegangenen Phase aufdecken die normales Modultesten nicht entdecken kann 91 Wird vor der Inspektion getestet muss gegebenenfalls der gesamte Aufwand des Testens wiederholt werden e Mitunter k nnen die Ergebnisse aus Inspektionen vor dem Modultest so gut sein dass diese Testphase bersprungen werden kann und stattdessen gleich ein Integrationstest durchgef hrt werden kann Dies w rde Zeit und andere Ressourcen einsparen 3 Moderne Tools Fagan f hrt in seiner Publikation aus dass die Vorbeugung von Fehlern weitaus effizienter sei 4 So konnten Firmen die nur einen Prozent des Gesamtbudgets in die Verhinderung von Fehler investierten zum Beispiel in Schulungen die Kosten von der Fehlerbeseitigung um das sechs bis achtfache reduzieren 2 Moderne Werkzeuge k nnen Entwicklern bei der Fehlervermeidung helfen In den letzten Jahren hat sich vieles rund um den Softwaremarkt getan Code kann w hrend der Eingabe berpr ft
172. entwickelnden Systems gleich als ob mit finalen Implementierung oder mit einem ausf hrbaren Mo dell gearbeitet wird Beim Bedienen protokolliert die Play Engine die Aktionen des Benutzers und reagiert selbstst ndig mit Aktionen und Events so wie sie bei den Play In Szena rien erfasst wurden Ist ein Szenario abgearbeitet wird dies vom System sichtbar gemacht Der gro e Vorteil liegt darin dass die Interaktion mit Hilfe von Szenarien schon auf Basis der Anforderungen ausgef hrt werden kann ohne zu diesem Zeitpunkt ausf hrbare Mo delle synthetisieren zu m ssen oder einen Prototyp f r den Kunden zu bauen Das direkte Arbeiten mit der grafischen Oberfl che erleich tert einem breiteren Personenkreis sich am Prozess beim berpr fen der Anforderungen zu beteiligen Durch die Vi sualisierung und Interaktion ist es nicht unbedingt notwen dig sich mit den formalen oder textuellen Spezifikationen auseinanderzusetzen David Harel Hillel Kugler und Rami Marelly sind der Mei nung dass man durch den Play Out Ansatz gut getestete und verifizierte Spezifikationen bekommt welche eine gerin gere Fehlerrate in den folgenden Phasen aufweist 5 KONKLUSION Ausgehend von den Erkenntnissen von David Harel und Eran Gery in 7 wurde in dieser Arbeit der Bogen zum Model Driven Software Development MDSD gespannt Die fr hen Konzepte und Ideen der Autoren finden sich heute darin wieder und haben den Ansatz des MDSD mitunter stark
173. er 2005 als Verwaltungszentrale im Hintergrund zur Verf gung hat Dabei werden die auf das System zugreifenden Personen grunds tzlich in drei Kategorien eingeteilt Software Architekten Entwickler und Tester F r jede dieser Rollen wird eine eigene Umgebung zur Verf gung gestellt welche die entsprechenden Client Tools enth lt Auf zentraler Server Ebene Team Foundation Server finden sich die Komponenten der Bereiche Build und Changemanagement Work Item Tracking Reporting und Projektmanagement als den Prozess steuernde und untAnsthirektde K nmeonant ereich System Design auf oberster Ebene Application und Database Design auf unterer Ebene und am Design des Deployment Prozesses jeweils spezialisiert t tig sein Software Entwickler erhalten durch Code Analyzer sta tisch dynamisch sowie einen Code Profiler Unterst t zung Die Testing Tools enthalten Komponenten zum Load Testing Manual Testing Unit und Code Cove rage Testing sowie eine Unterst tzung im Test Case MaM trdndeater Aufbau mit der Fuchu SWB verglichen so fallen auf den ersten Blick die gro en hnlichkeiten in der Rollenverteilung auf Die Bereiche lassen sich im Einzelnen wie folgt in den Fuchu SWB Bausteinen wiederfinden SWB I entspricht dem Toolset Develo pers SWB II hat als Pendant das Toolset Testers das im Team System besonders stark ausgepr gt ist SWB II findet sich in den Teilbereichen System Ap plication und Databasedes
174. er ndert bleibt e Externe Umgebung External Environment Die externe Umgebung stellt das Umfeld dar in dem die Komponente angewandt wird Andert sich diese Umgebung muss das Design bzw die Spezifikation der Software Komponente an die neue Umgebung ange passt werden Dies impliziert dass sich auch die Funk tionalitat andert Aus diesem Grund beziehen sich Prieto Diaz und Freeman in 11 auf die externe Umgebung da diese mehr Einfluss auf die Wiederverwendbarkeit einer Software Komponente hat Wird nun diese externe Umgebung analysiert entstehen fol gende Facetten die Umgebung beschreiben System Typ system type Functional Area functional area und Setting setting Die Facetten werden in Form des Tupels lt system type functional area setting gt dargestellt und ha ben geordnet nach absteigender Reusability Relevanz fol gende Bedeutung 5 11 e System Type Sub Systemtyp f r den die Komponente entwickelt wurde applikationsunabh ngig z B interpreter DB management e Functional Area Applikationsabh ngige Aktivit ten die von der Soft ware Komponente durchgef hrt werden z B batch job control CAD e Setting Bereich in der die Software Komponente ausgef hrt wird z B auto repair catalog sales Durch das Sechs Tupel lt function object medium system type functional area setting gt wird also im facetten orien tierten Klassifikati
175. er 1983 pp 61 65 5 L A Zadeh Knowledge Representation in Fuzzy Logic IEEE Trans on Knowledge and Data Engineering Vol 1 1 Marz 1989 pp 89 100 6 A Grauel Fuzzy Logik Einf hrung in die Grundlagen mit Anwendungen BI Wissenschaftsverlag Mannheim 1995 7 H H Bothe Fuzzy Logic Einf hrung in Theorie und Anwendungen Springer Verlag Berlin 1993 8 L A Zadeh Fuzzy Sets Information and Control Vol 8 3 Juni 1965 pp 338 353 9 K Tanaka An Introduction to Fuzzy Logic for Practical Applications Rassel Inc Japan 1991 10 L A Zadeh Outline of a New Approach to the Analy sis of Complex Systems and Decision Processes EEE Trans on Systems Man and Cybernetics Vol SMC 3 Januar 1973 pp 28 44 11 D Dubois H Prade Fuzzy Sets and Systems Theory and Applications Acadamic Press New York 1980 12 E H Mamdani S Assilian An Experiment in Linguis tic Synthesis with a Fuzzy Logic Controller International Journal of Man Machine Studies Vol7 1 Januar 1975 pp 1 15 13 C Von Altrock Fuzzy Logic and Neuro Fuzzy Ap plications Explained Prentice Hall New York 1995 14 H J Zimmermann Fuzzy Set Theory And its Appli cations Kluwer Acadamic Publishers Boston Dordrechi London 2001 Computing with Words verstehen Stefan Labitzke 0560486 slabitzk edu uni klu ac at Abstract Das Ausgangs
176. erachtet werden kann Durch eindeutige Schnittstellendefinitionen in WSDL und Implementation des SOAP Protokolls als Transportstandard wird der Wiederverwendbarkeit in unterschiedlichen Technologien als Key Kriterium Rechnung getragen Zentrale Probleme die sich aber aus Betrachtungssicht der Fuchu Factory ergeben und durchaus kritisch hinterfragt werden m ssen sind die Faktoren Kontrolle und Qualit t W hrend die klare Trennung zwischen wiederverwenbarer Komponente und verwendendem Programm gegeben ist fehlt im Gesamtbild sowohl das Steering Board als auch eine entsprechende zertifizierende Instanz welche die Komponenten als verwendbar getestet einstuft Im Rahmen einer Organisationsdomain ist dies zwar ber interne Richtlinien denk und auch durchf hrbar die Standardsammlung WebServices l sst aber technische Rahmenbedingungen hierf r vermissen In WSDL oder UDDI sind die Metainformationen ber Komponente und Hersteller enthalten Zertifizierung und Authentifi zierung sind aber ber diese Standards nicht m glich Hier bleibt es dem Verwendenden selbst berlassen damit umzugehen Das Konzept von Reuse als gesteu erter Prozess kann als unzureichend erf llt angesehen werden 4 Tools zur Veranschaulichung Um den bereits beschriebenen gestiegenen Anfor derungen der heutigen Zeit Rechnung zu tragen bedarf es entsprechend starker Tool Unterst tzung Matsumo to beschreibt 1987 die f r den Entwicklungs Prozess eing
177. eranschaulicht werden Weitere Informationen ber die Wissensrepr sentation von unscharfen Aussagen kann man in 4 und 5 erhalten Linguistische Variable Temperatur ERDE Prim rterm hei Linguistische Werte Antony kalt Modifikatoren Sehr wenig nicht kaum Viele wenige einige Quantoren alle M glichkeiten vielleicht eher unm glich Wahrscheinlichkeiten Meist manchmal oft 113 Die Festlegung der linguistischen Variablen und ihren Werten findet man bei einfachen Problemen praktisch intuitiv Bei komplexen Prozessen ergeben sich diese jedoch nicht so leicht W hlt der Entwickler die linguistischen Variablen nicht realit tsgetreu wird es wahrscheinlich n tig sein die Datenbasis wiederholt zu konzipieren Das ist etwa der Fall wenn sich sp ter herausstellt dass mit Hilfe der Messwerte keine vern nftige Regelung m glich ist Ebenso verh lt es sich mit den Wertebereichen der linguistischen Variablen Oft zeigt die Natur Grenzen auf wie beispielsweise kann ein Winkel nur Werte zwischen 0 und 360 Grad annehmen Allerdings gibt es auch Gr en die keine klaren Wertgrenzen besitzen und der Entwickler des Systems selbst zu entscheiden hat wo es vern nftig ist diese zu setzen Nach der Bestimmung des Wertebereichs muss dieser nun in die linguistischen Werte partitioniert werden Au erdem muss die Form der Zugeh rigkeitsfunktion f r die linguistischen Werte festgelegt werden Die F
178. ereits ber 50 der Fehler eines Systems noch vor der Programmierphase auftreten Je fr her nicht entdeckte Fehler auftreten desto teurer wird die Fehlerbehebung in den n chsten Phasen Fehler k nnen sich auch unterschiedlich stark fortpflanzen Dies bedeutet sie k nnen entweder keinen einen oder mehrere Fehler in beliebig vielen Folgedokumenten verursachen In seinem Buch Software Engineering Economics 5 analysierte Boehm mehrere Projekte und deren Kosten f r die Beseitigung von Fehlern in den unterschiedlichen Phasen der Projektzyklen Abbildung 2 m Anforderungsphase E Design E Implementierung E Dokumentation Abbildung 1 Durchschnittliche Fehler in den Lebenszyklen Durch fr hzeitige Fehlererkennung und behebung k nnen nicht nur Ressourcen eingespart werden zudem erh ht sich auch die Qualit t des fertigen Produkts 40 1000x 30 70x 15 40x 3 6x u 1 gt 8 SBS Requirements Design Coding Development Acceptance Test Test Operation Abbildung 2 Kostenfortpflanzung eines nicht gefunden Fehlers bis zum Betrieb 5 Eine M glichkeit der Fehlererkennung ist die Inspektion Fagan beschreibt eine Inspektion als eine formale effiziente und konomische Methode um Fehler im Design und Code zu finden 1 Eine formale Inspektion wird mit einem extra damit beauftragen Team zu bestimmten Zeitpunkten durchgef hrt Das zu pr fende Dokument wird dabei mittels einer Kontrolllistte Punkt f r Punkt d
179. ering and Knowledge Engineering pages 204 211 1995 2 B Coulange Software Reuse Springer 1998 3 I Herman Semantic web http www w3 org 2001 sw letzter Zugriff 17 05 2007 4 E A Karlsson S Sorumgard and E Tryggeseth Classification of object oriented components for reuse In Proceedings of the Conference on Technology of Object Oriented Languages and Systems TOOLS 7 pages 21 31 1992 5 Ch W Krueger Software reuse ACM Computing Surveys 24 2 131 183 1992 6 H C Liao and F J Wang Software reuse based on a large object oriented library ACM Sigsoft Software Engineering Notes 18 1 74 80 1993 7 Y Matsumoto A software factory An overall approach to software production In Freeman P Tutorial Software Resuability IEEE CS POress pages 155 178 1987 8 A Mili R Mili and R T Mittermeir A survey of software reuse libraries Annals of Software Engineering 5 0 349 414 1998 9 J Penix P Baraona and P Alexander Classification and retrieval of reusable components using semantic features In The 10th Knowledge Based Software Engineering Conference pages 131 138 1995 10 A Podgurski and L Pierce Retrieving reusable software by sampling behavior ACM Transactions on Software Engineering and Methodology 2 3 286 303 1993 11 R Prieto Diaz and P Freeman Classifying software for reusability IEEE Software 4 1 6 16 1987 12 R Rada Software Reuse
180. ersten Wert geht hervor dass der Pro grammierer im Zentrum der Entwicklung steht da 76 nach Ansicht der Agile Alliance das Entwicklerteam der Erfolgsfaktor fiir gelungene Projekte ist Wichtig ist aber die Kommunikation zwischen den Entwicklern untereinander Es hat keinen Sinn zehn sehr gute Programmierer im Team zu haben die nicht teamf hig sind Umfangreiche Dokumentation erfordert einen hohen Zeitaufwand und es ist schwierig diese w hrend der Entwicklungsphase aktuell zu halten Der zweite Wert dr ckt aus dass keine Dokumente erzeugt werden sollen f r die es keinen unmittelbaren Nutzen gibt Dem dritten Wert kann entnommen werden dass es besser ist in st ndiger Kooperation mit dem Kunden die Anforderungen des Systems auszuarbeiten als anf nglich eine Spezifikation zu schreiben und diese als endg ltige Basis und Vertrag f r die Erstellung des Systems heranzuziehen Solch ein Ansatz f hrt meistens zu Produkten niedriger Qualit t Viele Softwareprojekte scheitern aufgrund von nderungen in den Systemanforderungen Um diesem Problem zu entgehen gibt es den vierten Wert Dieser beschreibt die Flexibilit t agiler Vorgehensweisen vgl 16 4 1 eXtreme Programming XP eXtreme Programming ist der wohl bekannteste und am meisten eingesetzte Vertreter agiler Entwicklungs methoden Dogs und Klimmer gliedern die agilen Methodiken in die vier Kategorien prozessorientierte mitarbeiterzentrierte werkzeug zentrierte und
181. ert werden Die gezielte Forschung nach qualit tssi chernden Methoden best tigt dass Qualit t mit ein ent scheidender Faktor f r die Akzeptanz von Software komponenten ist Erst vertrauensw rdige Komponenten hoher Qualit t werden in der Lage sein die H rde des not invented here Syndroms zu nehmen Die andis kutierten Methoden der Dokumentation Qualit tsmo delle und Zertifizierung werden ihren Teil dazu beitra gen Die meisten Komponenten sind ohne Infrastruktur nicht lauff hig Komponentenmodelle wie COR BA CCM EJB und NET stellen f r den Betrieb wich tige Dienste bereit und halten die Komponenten f rm lich zusammen Die Komponententechnologie k mpft jedoch nach wie vor mit der Problematik der Interope rabilit t wobei der Adapter als eine L sung f r diese Schwachstelle angesprochen wurde Die Entwicklung komponentenbasierter Softwaresysteme erfordert ein speziell angepasstes Lebenszyklusmodell Suchen Ausw hlen und Adaptieren von verf gbaren Kompo nenten kommen als neue Aktivit ten im Prozessmodell hinzu Das vorgestellte Lebenszyklusmodell lie die Unterschiede der CBD zu herk mmlichen Prozessakti vit ten sichtbar werden Peter Wegner hat bereits 1984 demonstriert wie ka pitalintensiv Softwaretechnologie ist Anhand der in diesem Artikel vorgestellten heute verf gbaren Soft warekomponenten Technologie wird deutlich dass die Kapitalintensit t noch weiter zugenommen hat Kom ponenten hoher Qualit
182. ertain use case The standard shell as it is delivered with UNIX is so powerful however that it would not need a lot of changes for most tasks As mentioned above the shell allows the execution of a program by stating its name and the parameters that should be passed to it If the parameters are files pattern matching characters are supported e g which stands for any sequence of zero or more characters These characters are expanded to all files they apply to by the shell itself Thus the called program is not affected with the expansion It only has to offer means to handle a list of files even if the elementary action performed applies to only one file at a time 5 2 2 1 Standard I O Usually a program has to either actively open an existing file or create one to obtain a file descriptor and use it For most programs however user input as well as output to the user is so common that the shell opens two standard file descriptors at every execution of a program STDIN STDOUT These two descriptors are passed to any program executed by the shell Since all I O devices are represented as files it is easy to accomplish this by pointing the standard input STDIN to the file representing the typewriter and the standard output STDOUT to the file representing the screen It is apparent how the uniform structure of the operating system supports this approach But the idea goes even further as will be shown in the next c
183. esetzte SWB als ein System aus 6 Hauptkompo nenten e SWB I zur Unterst tzung des eigentlichen Programmierens Kompiliernes von Pro grammen e SWB II als Test Komponente e SWB III als Design Komponente e SWB IV zur Unterst tzung der On Site Maintainance von Software bei Kunden e SWB P zur Projektmanagement Unterstiitzung e SWB Q als eigenes Quality Assurance Tool Zus tzlich werden noch kleinere Komponenten zur Software Konfiguration sowie die bereits im vorherge henden Kapitel beschriebene Komponente zum Sup port von Reuse Entwicklung beschrieben Die techni sche Basis ist somit klar auf die Unternehmensstruktur abgestimmt und erm glicht eine eindeutige Durchf h rung des definierten Prozesses Ein Vergleich mit aktu 50 ellen Programmen beleuchtet n her inwieweit einer seits die damaligen Programmkomponenten weiterhin existieren und andererseits ob basierend auf diesen neuen Technologien eine F hrung der Software Facto ry wie von Matsumoto beschrieben im heutigen Um feld m glich w re Zum Vergleich werden zwei g ngi ge Entwicklungsumgebungen in ihrer jeweils aktuellen Version herangezogen Visual Studio Team System Microsoft und Rational Software Delivery Platform IBM 4 1 Visual Studio Team System als Tool Microsoft verfolgt mit Visual Studio Team System 13 das Ziel seine vielf ltigen Entwicklungs technologien unter einer zentralen Plattform zu vereinigen die einen Datenbankserver SQL Serv
184. esses so gut als m glich beseitigt werden 11 12 p 46 Diese w ren 11 64 e Klassifizierung Classifying Eine wohldefinierte Klassifizierung einer Komponente und die dadurch entstehende Ordnung und Organisati on in Software Collections sind essenzielle Bestandteile der Wiederverwendung von Software e Wiederauffindung Retrieval Dieses Problem steht mit dem Klassifizierungs Problem in Verbindung Werden Software Komponenten nicht geeignet klassifiziert und beschrieben stellt auch die Wiederauffindung dieser ein herausforderndes Problem dar Werden Software Bibliotheken also nicht geeignet organi siert steigt dadurch die Wahrscheinlichkeit dass ein Ent wickler die passende Komponente nicht finden kann und sie somit selbst entwickelt Nat rlich wird bei Software Reuse nicht nur der Software Collection in der Komponenten organisiert sind eine zen trale Problem Rolle zugesprochen Auch die Entwickler die Benutzer dieser Bibliotheken bilden ein Teil Problem Die se m ssen folgenden Prozess durchlaufen um eine beste hende Software Komponente in neuen Systemen einzuset zen 1 die richtige Komponente finden 2 diese ver stehen und 3 die Komponente falls notwendig so ad aptieren dass sie die Funktionalit t in der neuen Umge bung bietet Diese Aussage impliziert nun dass Attribute wie Gr e Komplexit t und Dokumentation die ausschlie lich von Entwicklern abh ngen ein Problem der Software W
185. euronale Netze bestehen aus vielen kleinen Neuronen wobei Informationen durch die Verbindungen zwischen den Neuronen erfolgen hnlich den Vorg ngen die sich im menschlichen Gehirn abspielen Ein gro er Vorteil von neuronalen Netzen ist die hohe Lernf higkeit Durch die Kombination dieser zwei Theorien werden ihre beiden Schwachstellen ausgemerzt Die Neuronalen Netze k nnen einerseits durch Fuzzy Logik eine Wissensrepresentation erzeugen die die Sachverhalte des Systems wirklichkeitstreuer beschreibt Andererseits wird das gr te Manko der Fuzzy Logik ausgemerzt Seine Unf higkeit aus Fehlern zu lernen 6 Ein weiterer Ansatz der sich mit Fuzzy Logik gut kombinieren l sst sind die so genannten evolution ren Algorithmen Diese nehmen sich die Prinzipien nat rlicher Evolution und der Genetik zum Vorbild Nach 6 kann man die Evolution als einen Lernprozess der sich auf einfache Prinzipien st tzt verstehen Die wichtigsten dieser Strategien sind Crossover Rekombination Mutation Inversion Da durch diese Algorithmen die bestm glichste L sung f r ein Problem gefunden wird kann man bei Fuzzy Systemen evolution re Algorithmen als Optimierungshilfe f r die Wissensbasis verwenden So kann etwa die Partitionierung von den linguistischen Variablen von einem evolution ren Algorithmus erledigt werden Au erdem k nnen die Regeln dadurch optimiert werden Ein Manko ist dass es nicht sicher ist dass man mit dieser
186. fenen Designent scheidungen 05 3 1 5 Modularisierung Das Top Down Verfahren l sst ein Softwareprodukt auch sehr leicht modularisiert entstehen Das bedeutet dass ein in einem Schritt der Verfeinerung entstandener Block leicht in eine eigene Subroutine beziehungsweise ganze Bibliotheken ausge lagert werden kann Die Eigenschaft der eindeutigen Ein und Ausstiegspunkte erleichtert dies vor allem auch bei der Wahl der notwendigen Parameter Dies unterst tzt Lesbarkeit Wartbarkeit und nat rlich auch die Wiederverwendung der einzelnen Module ber fl ssige Parameter werden ebenso vermieden wie Mo dule die mehr Funktionalit t enthalten als sie eigent lich sollten und so f r eine sp tere Verwendung eher unbrauchbar werden 3 1 6 Compiler Ein interessanter Punkt ist auch die Tatsache dass einige der Nachteile die im Folgen den beschrieben werden zumindest teilweise durch einen vern nftigen Einsatz von Compilern wieder wett gemacht werden k nnen Tricks die dazu verwendet wurden zum Beispiel mittels komplexer goto Kon strukte eine enorme Steigerung der Effizienz zu errei chen k nnen durch einen Compiler oder auch durch einen Precompiler automatisch eingebaut werden U bersetzter zumindest diejenigen einiger der moderne ren Programmiersprachen verwenden bereits automa tische Codeoptimierer Der Vorteil davon ist dass die Entwicklung und der endg ltige Code dennoch struktu riert und lesbar bleiben 3 2
187. further development Knuth confessed that he was biased because wrote a lot of code examples in his books include goto s Nevertheless he tried to analyze a number of problems deciding whether they can be written without goto s efficiently or not Among others loops error exits hash coding and text scanning without goto s seemed to be possible without any loss of performance Other constructs proofed to be more readable and efficient with goto s e g recursion elimination multi way branching removal of boolean variables tuning considerations To start with loops seemed to be somehow reasonable It is easy to understand that critical program loops should be written as efficiently as possible Without using goto s it is necessary to design loops in a way that as much operations as possible are moved outside of the loop e g boundary checks Error exits e g if x gt max goto overflow might be handled by a smart compiler If not validity checks should be moved outside of the loops if possible Hash codes should be extremely effective because they can be issued very often and are therefore highly bound to a low execution time It has been proven that it is better to design a hash function in a well structured way and tune it with local goto s to obtain maximum performance than to write it from scratch with goto s A few other problems are also performance critical and should not be done without goto s like text searching Recursio
188. g von Eigenschaften ben tigt Eine Komponente kann da her durch genau eine Spezialisierung eines Features klassifiziert werden In dem Klassifikations Schema aus Abbildung 2 wird beispielsweise eine collection in stack queue list etc spezialisiert Sind f r ein Feature mehrere Auspr gungen relevant wird dies im Schema von B rstler durch einen Stern symbolisiert Dies bedeutet im konkreten Schema aus Abbildung 2 dass die Eigenschaften Author und Operations mehrere Wer te annehmen k nnen 1 Dies stellt eine deutliche Verbesse rung der Ans tze aus 11 und 4 dar Folgendes Beispiel soll die Thematik der feature orientierten Klassifizierung verdeutlichen 1 name ExtendedExample author ck kind collection stack space constant operation type constructor name push time constant operation type destructor name pop time constant loc 100 error density 0 01 Auch die Suche in der Software Library wird mit der Un terst tzung von Eigenschaften durchgef hrt ein Benutzer beschreibt die Query die abgesetzt werden soll in Form von Eigenschaften einer Software Komponente Dabei ist zus tzlich zu erw hnen dass sofern nach einer Generalisie rung gesucht wird ebenso die Spezialisierungen ber cksicht igt werden z B die Suche nach kind collection tree w rde auch kind collection tree binary ber cksichtigen 1 Weiters wurd
189. gn problem goes beyond the algorithms and data structures of the computation designing and specifying the overall system structure emerges as a new kind of problem 12 To solve this problem there has to be a way to adhere models of successful solutions to get back to them and build other systems on the same architectural idea To do so the notion of architectural patterns was born An architectural pattern is a very great abstraction of different best practice and working solutions To make use of this there also has to be a description of the context in which the pattern is used as well as the forces that the pattern tries to resolve One very common architectural style is the pipes and filters style This paper already showed how UNIX supports the pipelining of commands It is clear that the UNIX pipelining idea and the ideas presented in the pipes and filters architectural style have a lot in common One could even say that the great success of UNIX pipes builds the cornerstone for the development of other systems following this idea Ultimately this led to the creation of an architectural style that summarizes all of these systems ideas The basic idea is that the system is built out of components that are connected in a certain way Each component has a set of inputs and a set of outputs A component reads streams of data on its inputs and produces streams of data on its outputs delivering a complete instance of the result in a st
190. h eine Membership Funktion zu den einzelnen granula ren Mengen zugewiesen werden F r n here Einzelhei ten siehe Anhang Abbildung 8 9 und 10 Hat man nun die Mengen gebildet so m ssen mit die sen Sets Regeln aufgestellt werden welche man von Experten in diesem Bereich einholen muss Abb 11 4 3 Inferenz Es tritt jedoch h ufig der Fall ein dass mehrere Re geln zur Verwendung kommen sodass man einen Me chanismus ben tigt welcher die Membership Werte u f r die Bremskraft berechnet Zur L sung des Prob lems kann man auf mehrere Methoden zur ckgreifen Meistens wird jedoch die Max Min Inferenz verwen det Hierbei behandelt man die Werte f r die Therme untereinander mit dem Min Operator anschlie end das Ergebnis f r die gleiche Gruppe mit dem Max Operator Weiters soll auch noch die Max Prod Inferenz er kl rt werden Hierbei werden erneut zuerst die Terme mit dem Min Operator verkn pft anschlie end jedoch wird der Ausgangswert mit dem minimalen Erf llt heitsgrad multipliziert F r n here Erkl rung siehe 8 Als n chsten Schritt k nnen also konkrete Werte mit Hilfe der Membership Funktionen zu den granularen Mengen zugewiesen werden Aufgrund der Regeln wird dann ein Fuzzy Ergebnis f r die Bremskraft abge lesen Jedoch muss auch dieser unscharfe Wert wieder umgerechnet werden Dabei gibt es mehrere Auswert methoden welche im n chsten Unterkapitel erkl rt werden 4 4 Defuzzifizierung
191. h ftigt sich mit Entwicklungen in der 95 K nstlichen Intelligenz speziell im Bereich der Onto logien Im letzten Teil erfolgt eine Zusammenfassung ber die behandelten Themen 1 1 Problembereich Requirements Enginee ring Vor 25 Jahren als Sol J Greenspan den Artikel 1 meinen Ausgangsartikel verfasste waren die Proble me die im Zuge der Anforderungsanalyse bei der Entwicklung eines Softwaresystems entstehen k nnen bereits erkannt Ausf hrliche Studien ergaben dass ber 70 aller Projekte schon damals ihre Ziele ver fehlten oder berhaupt abgebrochen wurden aufgrund verschiedenster Fehler in der Findung und Definition von Anforderungen Bis heute besteht das Problem der inkonsistenten mangelhaften unvollst ndigen oder mehrdeutigen Anforderungsdefinitionen Je sp ter im Produktentwicklungsprozess solche fehlerhaften An forderungsdefinitionen entlarvt werden desto h here Kosten verursachen sie Weiters k nnen sie auch zu einer relevanten Verz gerung der Produktfertigstellung verursachen bzw im schlimmsten Fall sogar zum Pro jektabbruch Das Bewusstsein entstand dass man die ser fr hen Phase der Softwareentwicklung mehr Auf merksamkeit schenken musste und dass es beim Defi nieren von Anforderungen um mehr geht als um das Auffinden und Spezifizieren der funktionalen Anforde rungen Man erkannte dass es von gro er Bedeutung sei sich ausreichend wie es Sol J Greenspan nannte real world knowl
192. h hohen Teilnehmerzahl eigentlich zu kurz In ver mindertem Ma e galt das auch bei einigen Hauptvor tr gen Somit bleibt mir nur mich bei den Teilnehmerinnen und Teilnehmern f r deren Engagement und f r die Bereitschaft Arbeiten und Referate von Kollegen kon struktiv zu kritisieren zu bedanken und Ihnen bei der Lekt re der folgenden Beitr ge einige spannende Einblicke zu w nschen 10 References 1 Bundesgesetz ber die Organisation der Universit ten und ihre Studien Universit tsgesetz 2002 BGBl I Nr 120 2002 Fassung BGBl I Nr 74 2006 51 Abs 2 lit 7 sowie 124 Abs 10 2 0 V Studienplan f r das Bakkalaureatsstudium und Magisterstudium Informatik an der Universit t Klagenfurt Mitteilungsblatt Univ Klagenfurt 26 Juni 2003 3 MyReview http myreview lri fr last accessed July 2007 4 R Mittermeir The Challenge of Teaching Foundational Ideas in a Modern Informatics Curriculum Proc MEDICHI 2007 Methodic and Didactic Challenges of the History of Informatics OCG 2007 pp 143 150 Danksagung Besonderer Dank gilt den Kolleginnen des Schreib Centers Unter Leitung von Prof Ursula Doleschal und Mag Carmen Mertlitsch haben studentische Mitarbei terInnen dieser Serviceeinrichtung der Universit t jenen Seminaristen die dieses Service in Anspruch nahmen Hinweise zur stilistischen und sprachlichen Verbesserung ihrer Arbeit gegeben Tabelle 1 TRACES Themes still Relevant
193. h mit der Entwicklung von struktu rierter Programmierung bis heute Dabei werden auch einige f r dieses Thema relevante Programmierspra chen ber cksichtigt 1 1 Was ist eigentlich strukturierte Program mierung Im Allgemeinen kann gesagt werden dass es sich bei strukturierter Programmierung um ein Konzept der Softwareentwicklung handelt Der Begriff selbst der E W Dijkstra zugeschrieben werden kann ist heutzutage weit verbreitet Doch woher stammt er und was bedeu tet er eigentlich 11 Als Urv ter des Konzepts an sich sind die Mathema tiker C B hm und G Jacopini zu sehen welche 1966 das Schreiben von Programmen auf das Verwenden von drei grundlegenden Kontrollstrukturen reduzieren konnten Die Strukturen selbst und ihre Bedeutung werden in einem sp teren Kapitel n her erl utert B hm und Jacopini hatten ihre auf Flussdiagrammen basierende Arbeit bereits selbst ausreichend belegt die grunds tzliche Methodik wurde jedoch 1972 von H Mills nochmals aufgegriffen und bewiesen Es kann auch gezeigt werden dass jedes bestehende Programm in eine derartige Darstellung berf hrt werden kann Das Ergebnis mag nicht dieselbe Effizienz oder eine hnlich gute Lesbarkeit besitzen unterscheidet sich aber nicht von der Funktionalit t an sich 03 14 Dijkstra schlug 1968 unter der Bezeichnung struc tured Programming ein Konzept zur Entwicklung von Programmen vor welches diverse zu der Zeit aufkom mende Probleme l
194. h the above mentioned structural parts we are able to uniquely determine a program state using a set of program and loop counters thus providing a good way to analyze several program conditions e g when does a variable hold a certain value Given the fact that we introduce the goto statement we are able to disrupt the flow of control which in the absence of goto s is much more regulated and well 18 formed With goto s it can be hard to find an unique set of coordinates to describe the actual progress of the program Of course it is possible to use the program counter to obtain an unique program state but this state is much more meaningless in terms of understanding the program Dijkstra is not altogether against the use of goto s when they do not harm the program s structure but he was convinced that it is easier to abuse goto s than to use them in a sensitive way 2 2 Knuth s perspective Knuth 2 had a different point of view in his article about structured programming with goto s He proposed two contrary ideas First he introduced several techniques to write iterations and error exits without the need of goto s Second he suggested to write well structured but maybe inefficient programs without goto s and transfer these into more efficient ones by replacing certain programming constructs with goto s and labels The resulting code is certainly less readable but the original program is well documented and serves as a basis for
195. h wird entschieden ob mit einem Prototypingansatz einem simulationsorientieren Vorgehen oder anderen Arten von Vorgehensweisen fortgefahren wird Der dritte Quadrant ist f r die Entwicklung und Tests der Teilprodukte verantwort lich Im vierten und letzten Quadranten wird jeweils die n chste Phase geplant Initial startet der Prozess mit einer Machbarkeits studie in Runde 0 Hier wird entschieden ob das Projekt in Angriff genommen wird oder nicht In Runde 1 werden ein Projektplan und ein Konzept f r den Projektablauf erstellt Weiters werden eine Kostenanalyse erzeugt und die Projektziele detaillierter spezifiziert Runde 2 ist f r die Erfassung der Anforderungen auf h chster Ebene In den nachfolgen den Runden wird das Produkt gefertigt wobei die Aktivit ten Design Implementierung und verschiedene Arten von Tests durchgef hrt werden vgl 10 3 Der Rational Unified Process RUP In den 80er Jahren erfuhren objektorientierte Sprachen breite Popularit t F r die Entwicklung von OO Softwaresystemen schmiedeten Grady Booch James Rumbaugh und Ivar Jacobson in den 90er Jahren den Unified Process 1999 12 Booch Rumbaugh und Jacobsen alias die Tres Amigos entwickelten zuvor die OO Techniken OOA OOD OMT und OOSE welche zusammen mit dem Anwendungsfall modell die Basis f r den Unified Process darstellen Der Prozess an sich ist keine konkrete Auspr gung sondern stellt ein Metamodell f r Software Prozes
196. hapter 2 2 2 I O redirection As described in the previous chapter programs handle user input and output through two standard file descriptors which are provided by the shell Because the UNIX file system offers such extent of abstraction STDIN and STOUT are handled like any other file This led to the idea that input could come from and output could go to any other file The idea itself like much else in UNIX was inspired by an idea from Multics Multics has a rather general IO redirection mechanism embodying named IO streams that can be dynamically redirected 4 In Multics one has to enter a clumsy sequence of commands to acquire such behavior which states a problem for the common day to day use In UNIX a simple gt character is enough to redirect the output of a program to any file whereas lt redirects a file to the input of a program Listing 1 PROGRAM lt IN gt OUT Listing 1 VO Redirection 2 This technique opens a set of new functionalities One worth looking at is the idea to origin the input of the shell itself from a file Since the shell is nothing else but a regular user program which itself reads its input from STDIN this input can be redirected as well By doing so one can pass a file to the shell which contains a sequence of commands These are then interpreted by the shell Listing 2 Basically this is the way to write a shell procedure store it in a file and then execute it To mak
197. he gcc source code Additionally the amount of goto s is not increasing but is rather stable 0 28 0 25 0 23 0 20 0 18 0 15 0 13 0 10 0 08 0 05 0 03 0 00 T na T T 1 1 2 2 95 3 0 346 4 0 0 4 1 0 4 1 2 4 2 0 03 99 07 99 06 01 03 06 04 05 02 06 02 07 05 07 GCC version and release date MM YY Goto s LOC Diagram 2 Usage of goto s in the GCC compiler To conclude this subpart it has to be said that although goto s are not really present in higher programming languages like Java but they still have a field of application at least in programming with C Additionally it is important to know how to use the program construct goto in a sophisticated way to not destroy or obfuscate the program structure Another interesting fact is that goto like branching constructs have survived in almost every programming language except functional and logical languages but they have different names and are limited to a certain kind of jumps Those constructs are going to be explained in the next chapter 3 2 The goto discussion and modern programming languages Returning from the depths of using goto s as programming constructs other effects causing the initial goto discussion a few decades ago will be looked at One result was the development of several algorithms to automatically remove goto s from source
198. he jedoch ein fast un berschaubar gro es Gebiet des Software Engineerings auf weshalb dieser Artikel auf die Untersuchung der Entwicklungen in Be zug auf Softwarekomponenten fokussiert Die Softwarekomponenten Technologie hat in den letzten Jahrzehnten und vor allem seit den fr hen 90er Jahren st ndig an Bedeutung zugelegt Im Besonderen weil klar wurde dass die objektorientierte Technologie den Erwartungen an hoher Wiederverwendbarkeit nicht ausreichend nachkommen kann 25 Diese Erwartun gen sollen nun wiederverwendbare Softwarekomponen ten und damit zusammengesetzte Softwaresysteme er f llen Welche Anstrengungen hierzu erforderlich sind sol len die folgenden Ausf hrungen verdeutlichen Kapitel 2 beschreibt unterschiedliche Abstraktionsebenen von Softwarekomponenten und f hrt gleichzeitig eine Ab grenzung dieses eher vielschichtigen Begriffes der Komponente durch Dar ber hinaus werden einige interessante Weiterentwicklungen in diesem For schungsgebiet diskutiert um vertrauensw rdige Kom ponenten zu erm glichen Kapitel 3 besch ftigt sich mit Komponentenmodellen welche Interaktionsstan dards und Infrastruktur f r wiederverwendbare Bau steine definieren Drei der bekanntesten Modelle wer den in diesem Kapitel berblicksweise angesprochen Kapitel 4 stellt das Paradigma der komponentenbasier ten Softwareentwicklung vor Es werden die Unter schiede zum Wasserfallmodell herausgearbeitet und Stolpersteine wie auch
199. hin die Definition einer intelligenten Internetsuchmaschi ne die automatisch Software Komponenten aus dem Inter net herunterl dt und dem Analyse Tool das in Abschnitt 2 des semantik basierten Ansatzes in 13 definiert wurde zur 3DAML plus OIL DAML ONT Darpa Agent Mar kup Language Ontology plus OIL Ontology Inference Layer 4OWL Web Ontology Language 5RDF Resource Description Framework WSDL Web Service Description Language UDDI Universal Description Discovery and Integrati on 69 a Intelligent Intemet N ae search rn D User query in Code n Code 2 Code 1 natural language a v J Ce aa Language og N understanding gt CG of a user query en c N Semantic CG of each component KL matcher A Ge E CG to Semantic ER Service Description NL Service Description SS Converter 7 T Semantic representation of gs en P 5 Web Service a query Semantic oe matcher 4 Y Metrics CG to Semantic Converter Semantic representation of a component Reuse Repository N UDDI registry A Abbildung 3 Datenflussdiagramm des semantik basierten Klassifizierungs Ansatzes Quelle 13 Verf gung stellt um die Komponenten zu klassifizieren Wie in Abbildung 3 ferner zu sehen ist definiert der Ansatz eine weitere Komponente welche die Suchergebnisse einer Que ry b
200. hin zum ausf hrbaren Code 6 den formalisierten Anforderungen generiert werden Der Weg zur ck st tzt sich auf mathematische Verfahren um das Mo dell gegen die Anforderungen zu verifizieren Von den Anforderungen zum Modell Von den Anfor derungen zum Modell bewegen wir uns durch Synthese fort Hier wird im Gegensatz zu gel ufigen Methoden das Mo dell direkt aus den formalen Anforderungen generiert wenn diese berhaupt implementierbar sind In Softwareentwick lungsprozessen bei denen diese Automatisierung nicht um gesetzt wird ist es gel ufig dass Entwickler von informalen Methoden geleitet die Anforderungen manuell in ein Modell umsetzen 6 Die Generierung des System Modells aus den Requirements ist ein weitaus schwierigeres Unterfangen als die Codesyn these aus dem Modell Die Codesynthes kann auch als high level compilation angesehen werden wogegen sich bei der Transformation von den Anforderungen zum System Modell auch die Frage nach z B der Einteilung in Struktur Objekte und Komponenten stellt 6 In einem Artikel 8 von D Harel und H Kugler beschrei ben sie Ans tze und Verfahren wie aus Anforderungen wel che mittels LSCs spezifiziert sind Systeme auf Basis von Statecharts generiert werden k nnen Vom Modell zu den Anforderungen Ausgehend vom System Model liegt unser Interesse daran eine wirkliche Ve rifikation durchzuf hren um das Model gegen die Require ments zu pr fen Diese Verif
201. hing FSS we r 2 from its original wn notion of place s notion of notion of q replacement l RL exchange enumeration P count move NSR 3 2 Pa along a scale 10 2 1 5 1 REN measure add substitute delete Abbildung 1 Distanz Modell Quelle 11 Wie in Abbildung 1 zu sehen ist werden die Begriffe die eine Facette beschreiben in Form von Bl ttern in einem azyklischen gerichteten Graph gespeichert Knoten des Gra phen stellen dabei Verbindungen zwischen hnlichen Begrif fen dar Die Bewertung der Kanten ist benutzerspezifisch je gr er die Relation eines Begriffes zu einem Knoten ist um so niedriger wird diese Kante bewertet 11 Das Beispiel in Abbildung 1 zeigt das Distanz Modell der function Facette Dabei wird ersichtlich dass zum Beispiel measure n her bei add 1 5 6 als bei move 1 15 16 liegt 11 Dieses Modell wird bei der Wiederauffindung von Software Komponenten ben tigt falls die Software Collection auf grund bestimmter Suchbegriffe keine Ergebnisse liefert wird das Distanz Modell herangezogen um die gleiche Suche mit 66 den hnlichsten Begriffen dieser Facette zu wiederholen 11 Neben den erkl rten Vorteilen die das Modell mit sich bringt existiert jedoch auch ein Nachteil das Aufbauen des azykli schen gerichteten Graphen ist zeitintensiv 11 4 4 Library System Das soeben beschriebene Klassifikations Schema wurde zu sammen mit dem
202. hmen Diese Wissen schaft wird Biomimicry genannt Dazu wird die reale Welt durch die nat rliche Sprache beschrieben Mit der Fuzzy Logik kann diese in ein mathematisches Modell bergeleitet werden welches dann einfach auf Maschi nen angewendet werden kann 3 4 Objektorientiertes Modellieren mit W r tern Dieses Kapitel zeigt einen Anwendungsfall auf welcher zwei Methoden verkn pft Einerseits die ob jektorientierten Paradigmen und andererseits die Prin zipien von Fuzzy Logik 7 Der Nachteil von objektorientiertem Modellieren ist dass ein Objekt genau einer Klasse zugeh rt Dies kann durch Fuzzy Logik umgangen werden da man hier nicht nur sagen kann ob oder ob ein Element nicht einer Klasse zugeh rt sondern auch in welchem Aus ma Ein Nachteil von Fuzzy Logik ist dadurch gege ben dass man stets nur Aussagen ber bestimmte Ei genschaften t tigen kann z B Das Auto f hrt schnell und nicht ber vollst ndige Klassifikationen Als ein Tool f r objektorientiertes Modellieren kann Frill herangezogen werden Dies erm glicht es an vielen Stellen mit W rtern zu rechnen Zuerst sei die Unsch rfe bei den Eigenschaften von Objekten er w hnt Es ist hier erlaubt den konkreten Objekten un scharfe Attributwerte zuzuweisen Weiters erlaubt die ses Schema eine Fuzzy Vererbung So kann ein Ob jekt durch Vererbung mehreren Klassen angeh ren Jedoch wird hierbei nicht alles vererbt sondern nur spezielle Att
203. i der Codeinspektion ist die Anzahl der zu berpr fenden Zeilen pro Stunde Glen Russell von Bell Northern Research BNR hat mehrere Inspektionen mit demselben Code bei unterschiedlichen Lesegeschwindigkeiten von 150 LOCs lines of code bis 750 LOCs pro Stunde durchgef hrt 14 Bei der langsamsten Inspektionslesung wurden in etwa 37 Fehler pro tausend Zeilen Code gefunden Laut Sch tzungen von Russell sind das zirka 80 der Fehler Hingegen konnte in der schnellsten Inspektion 750 LOCs pro Stunde nur mehr acht Fehler oder rund 17 der Fehler auf tausend Zeilen Code entdeckt werden 25 20 15 u u g Pe 5 o 150 250 350 450 550 650 750 Inspektionsrate in Codezeilen pro Stunde Fehler Tausend Codezeilen mSchwereFehler m Leichte Fehler Abbildung 3 Anzahl der gefunden Fehler bei unterschiedlichen Inspektionsraten von Codezeilen Vergleiche 14 Wurde ein Dokument inspiziert und enth lt noch Fehler erfolgt die Fehlerbeseitigung Rework und ein abermaliges Review Follow Up Ein Problem von vielen Teilnehmern ist es dass bei einer wiederholten Inspektion die berarbeitete Version von fehlerbehaftetem Code automatisch als fehlerfrei angesehen wird Wird etwas verbessert ist es fehlerfrei Als Faustregel gilt dass jeder sechste Fehler nicht richtig korrigiert wurde oder im Verlauf der Verbesserung ein neuer Fehler eingeschleust wurde 4 Aus Erfahrungen geht hervor dass die Effektivitat bei
204. ibliotheken Frameworks Middleware und hnlichem auf Diese Bestand teile k nnen 3rd Party Produkte wie NET oder J2EE sein oder eigens speziell f r einen Generator abgestimmte Pro dukte Die definierte Grundlage auf welcher der generierte Code aufbaut wird Plattform genannt Gibt es eine gro e Differenz zwischen den Konzepten der MDSD Dom ne und der Plattform so wird in der Regel die Tranformation komplexer Daher versucht man mit den Do main Specific Languages DSLs sich an die Plattformen an zun hern bzw umgekehrt die Plattformen an die DSLs an zupassen Solche Plattformen werden dom nenspezifische Plattformen genannt 4 BEYOND MDSD In dem Artikel Biting the Silver Bullet Toward a Brighter Future for System Development 5 aus dem Jahr 1992 be schreibt David Harel eine optimistische Aussicht auf zuk nf tige Enwicklungsmethoden f r komplexe Systeme Einige Forschungsarbeiten der folgenden Jahren beschritten diesen Weg und unterstrichen seine eigene Einsch tzung Diese Erkenntnisse f hrten zu einem Entwicklungsansatz f r komplexe reaktive Systeme welcher bei einer benutzerfreund lichen Anforderungs Erfassungsmethodik beginnt Aus den Anforderungen l sst sich die Verhaltensbeschreibung und in letzter Insanz die fertige Implementation herleiten 6 In Abbildung 2 wird dieses Gesamtkonzept illustriert Der Artikel Executable Object Modeling with Statecharts be handelt das System Modell den
205. ibt ein Framework in dem 3 Elemente notwendig sind 1 ein Modellierungstool spezifische Sprache unterst tzt 2 ein Code Generator 3 dom nenspezifisches Framework das die dom nen Abb 5 Framework f r dom nenspezifisches Modellieren zeigt die 3 Elemente auf 2 Ebenen Auf der Spezifizierungsebene und auf der Verwendungsebene Language Code Framework Metamodel Generation Code Cenemtcene Domain Models ze ns genen Framework Abb 5 Framework f r dom nenspezifisches Modellieren 23 Die obere Ebene der Spezifizierungsprozess wird einmal durchgef hrt bzw bei nderungen angepasst Dom nenexperten und Programmierer entwerfen das Metamodell und die dom nenspezifische Sprache sowie den Code Generator Das Metamodell ist die Implementation der dom nenspezifischen Sprache und enth lt die Konzepte und Regeln der Dom ne Der Framework Code beinhaltet technologiespezifischen Basiscode z B in Form von Komponenten 23 Der untere Prozess zeigt die Verwendung der dom nenspezifischen Sprache mit dem Code Generator Dieser Prozess wird pro Produkt durchgef hrt Dabei geht der Code Generator durch das Modell und transformiert die konzeptuelle Struktur in Code basierend auf dem Framework Code Dadurch dass der Code erzeugt wurde ergeben sich auch keine Implementierungsfehler 23 Standards und Tools F r die Umsetzung von Metamodeling m ssen geeignete Tools und Standards entwickelt und definiert werden um die Kom
206. ich Er kann sich ein Funktionieren aber nur vorstellen wenn ein umfangreiches Modell der Dom ne oder des Systems das Bestandteil des Problems ist bekannt ist und verstanden wird Weiters m ssten Strategien und Algorithmen von vorn herein bekannt sein Ebenso wie ben tigte Ressourcen Andernfalls ist der Ansatz von Osterweil f r ihn nutzlos Weiters kritisiert er ein Beispiel das Osterweil in seiner Publikation ver ffentlicht hat Lehman schreibt Lehman 87 81 Expressions like code wrong change_code or create_design in the body of a Process Program do nothing to clarify the process Also ist die T tigkeit entweder trivial oder der Versuch die Illusion eines Fortschrittes zu erwecken Als Beispiel in dem ein Prozessprogramm funktionieren k nnte nannte er Dom nen in denen das ben tigte Wissen f r die Softwareentwicklung komplett vorhanden ist So eine Dom ne w re ein mathematisches Problem weil f r diese Applikationen alles in mathematischen Termen ausgedr ckt werden k nnte Fr her wurden diese Programme ad hoc programmiert Lehman findet den Ansatz von Osterweil also nur sinnvoll in gewissen abgegrenzten Bereichen Auch D Notkin Notkin 88 sagt dass kein interessantes Softwareprojekt a priori definiert werden kann weil das Projekt von Kreativit t genauso wie von der Analyse von fr heren Schritten im Prozess beeinflusst ist Also w re es nicht m glich ein Prozessprogramm zu konstruieren
207. ich gemacht wurde ist auch ein zus tzlicher Aufwand f r Doku mentation und Zertifikation erforderlich F r die Ent wicklung von Komponenten bieten sich die evolution ren Prozessmodelle meistens besser an da fr hzeitiger als bei sequentiellen Modellen erste lauff hige Resulta te entstehen Wie sp ter noch erl utert wird kann es durchaus vorkommen dass bei CBD Komponenten im eigenen Unternehmen erzeugt werden m ssen Dabei ist es f r die CBD hilfreich w hrend des Systemdesigns und der Integrationsphase auf Prototypen zur ck grei fen zu k nnen Ebenso kann es aufgrund der Time to 60 Market Anforderung auch f r Lieferanten von Vorteil sein evolution r vorzugehen Komponentenbasierter Systementwicklungsprozess Ein komplettes System aus bereits vorhandenen Kom ponenten zu konstruieren verspricht weniger Aufwand in der Implementierungsphase Zus tzlicher Aufwand kommt aber f r komponentenspezifische Aktivit ten wie Suchen Finden Ausw hlen Evaluieren und Testen hinzu 22 Dennoch bleiben die grunds tzlichen Ba sisaktivit ten der Softwareentwicklung erhalten An forderungsanalyse und Spezifikation Systemdesign Implementierung Test Auslieferung und Wartung stel len die Aktivit ten des klassischen Wasserfallmodells dar In Abb 2 ist zu sehen dass die meisten traditionel len Aktivit ten auch bei CBD weiterhin wenn auch in modifizierter Form vorhanden sind Lediglich die Im plementierungsphase schein
208. ichen des Product Release Meilenstein wird das Projekt abgeschlossen vgl 13 Zyklen Unter einem Zyklus versteht man den gesamten Durchlauf der vier Phasen Wird eine neue Version der Software gefordert so entsteht diese in einem neuerlichen Zyklus 3 2 Charakteristiken Der RUP wird von Kruchten dem damaligen Leiter f r die Entwicklung des Prozessmodells als iterativ anwendungsfallgesteuert architekturzentriert und risikoorientiert charakterisiert 11 Im RUP finden sich zahlreiche Entwicklungsans tze aus Kapitel 3 wieder Der Wasserfallansatz Phasenmodell iterative inkrementelle und evolution re Entwicklung sind Teil des RUP Anwendungsfallgesteuert Die Grundlage f r viele T tigkeiten bilden die Anwendungsf lle Anhand dieser werden die funktionalen Anforderungen erhoben Sie beschreiben die Funktionalit t des Systems aus Benutzersicht werden f r den Entwurf von Testf llen herangezogen und beinhalten die Basisinformationen f r den Architekturentwurf 75 Architekturzentriert Im Prozess wird Architektur fr hzeitig entwickelt und laufend verbessert Die Architektur kann als Skelett des Systems aufgefasst werden und bildet das Fundament des Produkts F r die Betrachtung der Systemarchitektur aus unterschied lichen Blickwinkeln stellt der RUP f nf Sichten zur Verf gung Die logische Sicht abstrahiert das Entwurfsmodell Sie identifiziert Pakete Subsysteme und Klassen wobei keine technischen Detai
209. iches Konzept durch die Mittel Wiederverwend barkeit und Vorausplanung Insbesondere die Ausarbei tung des Reuse Bereiches der organisatorisch getragen wird kann heute noch berzeugen Das detaillierte Herunterbrechen von Analysen bis auf ein pers nliches Spektrum des Einzelnen berzeugt als Idee zur Quali t tsverbeserung ebenfalls Eine einfache Umsetzung als rein verbessenders Element ohne berwachungsambi tionen durchzusetzen oder Paranoia zu wecken ist in der aktuellen Arbeitswelt jedoch nur in einer gefestig ten Firmenstruktur vorstellbar 8 Referenzen 1 Matsumoto Y A Software Factory An Overall Approach to Software Production Freeman P Tutorial Software Reusability IEEE CS Press 1987 pp 155 178 2 Hall P Workshop Overview and Conclusions Dusink L Hall P A V Eds Software Reuse Utrecht 1989 Springer Verlag und British Computer Society 1991 3 Matsumoto Y and A Yonezawa Object Oriented Concurrent Programming and Industrial Software Production ed E Erhig etal Proceedings Formal Methods and Software Development Springer Verlag Berlin 1985 pp 395 409 4 Moore G E Cramming more components on integrated circuits Electronics 38 8 1965 pp 114 117 5 Wheeler D A More than a Gigabuck Estimating GNU Linux s Size Version 1 0 7 2002 http www dwheeler com sloc redhat7 1 v1 redhat7 1sloc html Stand 02 Mai 2007 6 Microsoft Corpora
210. ichsten Paper der 9 Internationale Conference on Software Engineering gew hlt In diesem Paper unterstrich Osterweil einige Aussagen die er zehn Jahre vorher ver ffentlicht hat Vor allem unterstreicht er die Forderung nach der Erstellung einer Programmiersprache zum Programmieren des Softwareentwicklungsprozesses Hier erw hnt er die Sprache JIL die in einem weiteren Kapitel noch behandelt wird In dieser Abhandlung Osterweil 97 hebt er z B hervor dass man dazu bergegangen ist verschiedene Werkzeuge die man als Modelle von Software benutzt auch im Softwareentwicklungsprozess zu nutzen Beispiele sind Petri Netze Datenflussdiagramme Endliche Automaten u a Hier muss man aber die Grenzen der einzelnen Modelle beachten Jedes Modell legt sein Hauptaugenmerk auf bestimmte Bereiche Zur Veranschaulichung von Parallelit t werden oft grafische Notationen benutzt aber die Ursachen der Parallelit t k nnen mit der zumeist unzureichenden Semantik dieser Modelle nicht oder nur schwer veranschaulicht werden Dieses Beispiel ist besonders im Softwareentwicklungsprozess beachtenswert da hier sehr viele Dinge parallel ablaufen 3 Warum ein Softwareentwicklungs prozess nur bedingt als Software behandelt werden kann Bei beiden Verdffentlichungen von Software Processes are Software too tat M M Lehman seinen Standpunkt zu dem von Osterweil beschriebenen Softwareentwicklungsansatz kund Er findet den Ansatz gut und n tzl
211. ickelt und wird bei Benutzung von RUP auch massiv eingesetzt ist aber keine Programmiersprache sondern eine M glichkeit verschiedene Sichten im Zuge des Softwareentwicklungsprozesses grafisch darzustellen Trotzdem k nnte RUP seine Forderung nach einem umfassenden Werkzeug erf llen das die Softwareentwickler unterst tzt und den Software entwicklungsprozess als Software behandeln l sst Mit RUP hat man ein Framework an Werkzeugen in der Hand also Software mit der man Daten bearbeiten speichern visualisieren transformieren usw kann Vergleicht man RUP mit APPL A sieht man die f r APPL A definierten Ziele fast vollst ndig durch RUP realisiert obwohl RUP im Grunde keine Programmiersprache ist sondern eine Software Obwohl Philippe Kruchten auf den Titel von Leon Osterweils Artikel Software Processes are Software 86 Too Bezug nimmt und sagt RUP sei eine Realisierung der Idee von Osterweil wurde die Wurzel der Entwicklung von RUP schon in den achtziger Jahren von Rational Systems gelegt Leon Osterweil hat eine rege Diskussion entfacht die mit der Prozess Programmierungssprache Little JIL eine interessante grafische Realisierung unter seiner Leitung ergeben hat Die Praktikablere so schein mir ist jedoch der Rational Unified Process 8 Referenzen Osterweil 87 L Osterweil Software Processes are Software Too ACM 1987 pp 2 13 Dikstra 68 Edsger W Dijkstra Go To Statemen
212. ie Produktivit t erh ht da weniger Code geschrieben werden muss und redundante Arbeiten und Entwicklungsphasen entfallen k nnen Der Zeitraum bis zur Marktreife wird reduziert und die Wartung von robusten Komponenten f llt geringer aus Dem gegen ber stehen Probleme wie das Auffinden einer geeigneten Komponente und allf llige Anpassungen an die eigenen Bed rfnisse Sie sind in der Regel nur mit erh htem Aufwand m glich Modifikationen an wiederverwendbaren Komponenten k nnen ungewollte Auswirkungen auf andere Bereiche haben Weiters m ssen Ressourcen f r die Suche Integration und Test von Modulen bereitgestellt werden Im Problemfall ist man bei externen Anbietern von wiederverwendbarer Software auf eine schnelle Fehlerbehebung angewiesen und kann nicht selbst t tig werden Eine Form der Wiederverwendung ist die komponentenbasierte Entwicklung wie sie beispielsweise in den Visual Programmiersprachen von Microsoft Verwendung finden Durch Drag amp Drop kann der Entwickler vorgefertigte Komponenten wie Buttons Men Eintr ge Datei Browser Kalender Auswahllisten und viele mehr in seine Applikation bernehmen Durch die Common Language Infrastructure CLI einem Standard von Microsoft ist es sogar m glich Komponenten die in verschiedenen Sprachen programmiert wurden miteinander zu kombinieren 18 Komponenten Windows Forms hk Zeiger ab Button VW CheckBox EE CheckedListBox 5 ColorDialog Ea ComboBox FE
213. iederverwendung darstellen 11 Aus diesem Grund haben Prieto Diaz und Freeman in 11 ein Reuse Modell hergeleitet das neben den oben beschrie benen Problemen auf die Annahmen dass Collections sehr gro sind st ndig anwachsen und viele hnliche Software Komponenten beinhalten aufbaut 11 Weiters wird angenommen dass aufgrund der vielen hn lichen Komponenten bei der Suche nach diesen keine ein deutige Komponente retourniert werden kann und damit die Adaptierung von Komponenten keine Ausnahme dar stellt 11 Der folgende Algorithmus beschreibt das Reuse Modell tref fend 11 begin search library if identical match then terminate else collect similar components for each component compute degree of match end rank and select best modify component fi end Listing 1 Reuse Modell Algorithmus Quelle 11 Wie aus dem Algorithmus aus Listing 1 zu entnehmen ist wird zuerst die Software Library nach der gew nschten Kom ponente durchsucht Wird eine exakte Software Komponente gefunden terminiert der Algorithmus Ist dies nicht der Fall werden hnliche Komponenten aufgelistet und mit Hilfe ei nes Evaluierungs Mechanismus der ebenso Bestandteil des Modells ist bewertet Anschlie end wird die beste Kompo nente also diese die am wenigsten Adaptierungsaufwand erfordert ausgew hlt 11 4 FACETED CLASSIFICATION Das Reuse Modell stellt einen L sungsansatz Modell dar der von Prieto Diaz und Freema
214. ience 1999 9 Chiang C C The use of adapters to support interopera bility of components for reusability Information Software Technology 3 2003 pp 149 156 10 Correira J M Biscotti F Market Share AIM and Por tal Software Worldwide 2005 Gartner market research re port Gartner June 2006 11 Crnkovic I et al Component Based Development Pro cess and Component Lifecycle icsea 2006 p 44 12 Crnkovic I Chaudron M Larsson S Component Based Development Process and Component Lifecycle 27th International Conference Information Technology Interfaces ITI IEEE Cavtat Croatia 2005 13 Crnkovic I Component based Software Engineering New Challenges in Software Development Software Focus December 2001 John Wiley amp Sons 14 Councill W T Heineman G T Component Based Software Engineering Addison Wesley 2001 p xxii 15 DeMichiel L Keith M JSR 220 Enterprise Java Beans Version 3 0 EJB 3 0 Simplified API SUN Microsys tems Dez 2005 16 Emmerich W Aoyama M Sventek J The impact of research on middleware technology SIGSOFT Software Eng Notes 32 1 Jan 2007 pp 21 46 62 17 Garlan D Allen R Ockerbloom J Architectural Mismatch Why Reuse Is So Hard IEEE Softw 12 6 Nov 1995 pp 17 26 18 McIlroy M D Mass Produced Software Components NATO Software Engineering Conference Report Garmisch Germany October 1968 pp 79 85 19
215. ier gekennzeichnet durch einen einfachen Bogen m ssen allesamt erf llt wer den um das bergeordnete Ziel zu erf llen berge ordnete Ziele deren darunter liegende Ziele durch eine ODER zueinander in Beziehung stehen doppelter Bogen verlangen nur nach der Erf llung eines dieser sub goals Softgoals hingegen die nicht funktionale Anforde rungen darstellen k nnen nicht eindeutig erf llt oder nicht erf llt werden Beispielsweise kann die Anforde rung Das System muss in einem hohen Ma e benut zerfreundlich sein keinen eindeutigen Kriterien zur Erf llung oder Nichterf llung unterzogen werden Die Erf llung solcher Softgoals h ngt davon ab ob es mehr Indizien f r die Erf llung gibt als dagegen siehe Abb 5 9 Usability Error gee i SI User Me _tailorability Information Ease of ame y Pa sharing User ina Allow change Priijraiiridllty of ee _ ad Modularity Ne N i gt P lt a Use A Allow change User defined Allow change of language writing tool of state Abb 5 Zielverfeinerung von Softgoals 9 j Allow gt of colors components 100 Schlie lich werden die erarbeiteten und evaluierten zu erreichenden Ziele mit den weichen Zielen zusammen gesetzt und so in eine Wechselbeziehung gebracht Dadurch erkennt man wie funktionale Anforderungen nichtfunktionale beeinflussen und umgekehrt Abbil dung 5 veranschaulicht dieses
216. ifestierung als die elementaren Design Patterns zum Reuse wieder findet 10 Patterns und Practices ist als weitere Auspr gung dieser Art immer st rker zu einem Buzzword der Industrie geworden In Patterns und Practices spiegelt sich auch der bereits damals exi 49 stente Ansatz wieder nicht nur Komponenten und de ren Strukturen Patterns sondern auch Prozesse ein zelne Schritte und Dokumente Practices wiederzu verwenden Ein interessantes Beispiel aus diesem Bereich in der Moderne ist das bewusst oder unbewusst durch Micro soft auf eben seiner Patterns and Practices Homepa ge aufgezeigte Verst ndnis des Begriffes Software Factories in einem anderen Kontext genannt Soft ware Factories in diesem Zusammenhang bezeichnet ein vorab zusammengestelltes weitestgehend automati siertes Verfahren zur Erstellung von Software in einer jeweils konkreten Problemdomain 11 Dem Entwick ler werden dabei Grundaufgaben und Grund berlegun gen anhand der in diesem Fall nicht allgemeinen aber vom Hersteller vorgeschlagenen idealen Parameter abgenommen vorerstellt und vorkonfiguriert In die sem Zusammenhang funktioniert die Verwendung des Begriffes Software Factory als gesamtheitlicher Beg riff wie er von Matsumoto verstanden wird nicht Es ist aber eine durchaus interessante Detailentwicklung des Reuse Bereiches die mit der Meinung von A End res der als IBM Mitarbeiter Schl sse einer eu
217. ign wieder SWB IV scheint mit seinen Maintainance Aufgaben nur teilweise in dem Produkt auf es wird zumindest die Teilaufgabe Deployment als Designer Aufgabe unterst tzt Weitere Maintainance wird im Rahmen des Product Cycle nicht vorgesehen SWB P wird als Serverkomponente Pro ject Management realisiert SWB Q kann als Teil der umfangreichen Test Suite interpretiert werden Unter st tzung f r den Bereich Reuse ist aus der Struktur des Systems nicht ersichtlich und auch bei n herer Betrach tung weder als integratives noch als administratives Konzept integriert 4 2 Rational Software Delivery Platform als Tool IBM f hrt als formgebenden Prozess f r seine Soft ware Delivery Platform 14 RUP Rapid Unified Processing an und unterstellt auf dieser Basis eine iterative Entwicklung Als an dem Prozess teilnehmen de Rollen werden Analytiker Architekten Entwickler Tester Deployer und als Querschnittsrollen Projekt Manager und Software Configuration genannt Im Ver gleich mit Matsumotos Ans tzen ist hier bereits auf oberste Ebene eine tiefere Gliederung zu erkennen In Fuchu werden die Rollen Designer keine Differenzie rung zwischen Analytikern und Architekten Program mierer Tester und Wartungspersonal aufgezeigt Der Delivery Faktor wird vom Tester mitgetragen Im Analyse Bereich bietet die IBM Plattform toolun terst tzte Modellierung und Visualisierung von Prozes sen aber auch einen eigenen Bereich zur
218. igner stat Code Tests Datenbank Code Profiler Test Case Designer Management Deployment A Designer Unit Tests Code Coverage Projektmanagement Reporting Tracking Build Management Visual Studio Team 115 Analytiker Architekt Entwickler Tester Deployer m Applikations Code Test Modellierung modeli erstellung Design Deployment 5 Daten Trans 5 Simulation modell formation Erstellung Konfiguration Business Code Profiler Mr urch i Processes Mietin f hrung Tuning Generierung Fehlermgmt Projektmanagement Prozess und Statusverfolgung Requirement und Assetmanagment Quality Management Abbildung 2 Grober Aufbau der Software Delivery Platform 16 IBM sammelt seine Testing Tools SWB ID unter dem Titel Software Quality und bietet automatisiertes manuelles performanceorientiertes und funktionales Testen als Varianten an Die Bezeichnung Quality Control findet sich in Fuchu wieder jedoch nicht als integrativer Bestandteil der Test Suite sondern ab gespalten im eigenen Quality Control Support Dieser ist als bergreifende Funktion nachgelagert hnlich dem Projektmanagement angesiedelt Als Querschnittsfunktion ebenfalls im Toolkit in tegriert findet sich die Unterst tzung f r Software Configuration Management eine Funktionalit t die von Matsumoto nicht gesondert abstrahiert
219. igung hat so konzentriert sich die wissenschaftliche Diskussion bez glich Reuse von Softwarekomponenten verst rkt auf die beiden letztge nannten Auch dieser Artikel untersucht vorwiegend Komponenten mit hohem Abstraktionsgrad welche im Vergleich zu geringerer Abstraktion den h chsten Ge winn bei Wiederverwendung versprechen Die Erzeu gung als auch Verwendung solcher Komponenten ist wie wir sehen werden von vielen kapitalintensiven Ak tivit ten und Eigenschaften abh ngig Die Time to Market Forderung erwartet z gige Entwicklungen bei gleichzeitig hoher Qualit t mit der 56 Eigenschaft schnell auf Ver nderungen reagieren zu k nnen Um diesen hohen Anforderungen gerecht zu werden lebt schon lange der Traum von leicht zusam men zu setzenden plug n play Softwarekomponen ten Die gern zitierte Definition von Szyperski unters treicht die Richtung dieser Idee A software component is a unit of composition with contractually specified interfaces and ex plicit context dependencies only A software com ponent can be deployed independently and is sub Ject to composition by third parties 28 Unabh ngigkeit Der Zusatz third parties am Ende der Definition von Szyperski stellt sicher dass die Nutzbarkeit einer Komponente nicht von Werkzeugen oder Wissen welche sich nur im Besitz des erzeugen den Lieferanten befinden eingeschr nkt werden soll Diese Voraussetzung gilt nat rlich auch f r Kompo nenten
220. ikation st tzt sich auf mathe Die Begriffe Verifikation und Validation sind abzugren den von der Bedeutung die sie bei CASE Tools in den 30 matische Verfahren um zu bewei en dass das Modell die Anforderungen erf llt 6 Die Verifikation versichert dass die spezifizierten Antiszena rien niemals eintreten und das explizit geforderte Verhalten eintritt Im Bezug auf real time Systeme sei erw hnt dass auch hier zeitliche Einschr nkungen Eingang finden k nnen Solche Eigenschaften k nnen durch reines Ausf hren des Modells nicht sichergestellt werden 6 4 3 Play In Play Out Szenarien Mit Play In Szenarien werden Anforderungen auf der grafi schen Oberfl che des zu entwickelnden Systems bzw einer abstrakten Version davon erfasst Dieser Ansatz erm glicht das Erfassen von Verhaltensanforderungen abstrahiert von formalen Sprachen auf eine intuitive und benutzerfreundli che Art und Weise 9 Am Anfang der Entwicklung wird die grafische Oberfl che des Systems erzeugt ohne ihr zu diesem Zeitpunkt Verhal ten zuzuordnen Aus der Sicht des Benutzers werden die Anforderungen spielend durch die Bedienung der Ober fl che drag and drop und dem Senden von Nachrichten sequenzen erfasst In einem zweiten Schritt werden die Per spektive des Systems eingenommen die Reaktionen auf die Benutzerinteraktion festgehalten und etwaige Bedingungen oder Einschr nkungen formuliert Im Hintergrund werden 80er Jahr
221. im Hinterkopf behalten muss Wenn man von einer fehlerfreien Ausgangsposition zum Beispiel ei ner anf nglich fehlerfreien Spezifikation der Anforde rungen ausgeht wird zumindest konzeptuell ein fehler freies Ergebnis erzeugt Dies gilt jedoch nur dann wenn in den weiteren Schritten keine Fehler einge bracht werden Auch bei nachtr glichen nderungen k nnen m gli che Fehler durch unerw nschte Seiteneffekte vermie den oder wenigstens fr hzeitig erkannt werden Weniger Fehler steigern die Qualit t des Produkts und das bedeutet auch weniger Zeit f r Debugging aufwenden zu m ssen Und das wiederum senkt den Gesamtaufwand und die Kosten 3 1 3 Handhabbarkeit Beim Vorgang der Abs traktion eines komplexen Problems sorgt ein struktu riertes Vorgehen daf r dass der menschliche Intellekt nicht mit zu komplexen Konstrukten berfordert wird Building Blocks f r strukturierte Programmierung haben alle genau einen Einstiegspunkt und einen Aus trittspunkt An diesen k nnen die einzelnen Blocks miteinander verbunden werden Diese Punkte lassen sich jedoch auch als Zust nde in einem Zustandsdia gramm beschreiben an denen Variablen Werte aus bestimmten Wertebereichen enthalten sollen oder sogar m ssen Derartige Assertions sind f r den Nachweis der Funktionalit t eines Codest cks sowohl hilfreich als auch notwendig Fortgeschrittene Programmierspra chen unterst tzen dieses Konzept sogar als integrierte sprachli
222. in reine Programmierpositionen aber eher selten bis nicht vorhanden Bereits Diplomanden werden zumeist mit Projektleiter T tigkeiten betraut die Spezialisie rung beginnt bedingt durch die breite Technologieba sis bereits mit dem Einstieg Hier ist fraglich ob es trotz einer Ausbildung die st rker auf Angewandte Informatik abzielt als damals insbesondere aus quali tativer Sicht nicht sinnvoll w re einen Schritt zur ck zu machen Die Rahmenbedingungen sind also gewachsen aber durchaus noch im Bereich des Vergleichbaren geblie ben Dies sei als Basis f r den Einstieg in die tats chli chen Parallelen und Entwicklungen zwischen dem da maligen Artikel und der Gegenwart genommen 3 Reuse als aktuelles elementares Konzept Anhand der letzten Betrachtungen den Vergleich rechtfertigend sollen nun die Erkenntnisse der Fuchu Factory in ihrer Relevanz f r die heutigen Technolo gien betrachtet werden Als elementarster Faktor f r Effizienzsteigerung wurde von Matsumoto das Konzept Reuse erkannt das hier in aktuellem Kontext beleuch tet wird 3 1 Patterns and Practices Die technischen M glichkeiten sind enorm gewach sen Moderne Entwicklungssprachen wie Java oder C zwingen als objektorientierte Sprachen den Benutzer sich zumindest in Grundz gen Gedanken ber Wieder verwendung zu machen Dies erfolgt haupts chlich ber den von der Architektur bernommenen Pattern Ansatz der sich in seiner bekanntesten Man
223. ine Schleife for Schleife Beim dritten Baustein der Entscheidung wird die Ausf hrung eines Blocks von einer bestimmten Bedingung abh ngig gemacht if then oder if then else Alle dieser drei Kontrollstrukturen haben wesentli che Eigenschaften gemeinsam Sie haben genau einen Eintrittspunkt sowie genau einen Austrittspunkt was das Beweisen der Funktionalit t erheblich erleichtert 2 2 4 Modularit t Ein wichtiger Aspekt von struk turierter Programmierung ist eine vern nftige Granula rit t der einzelnen Programmteile Logisch zusammen geh rige Bl cke sollten in eigenen Funktionen oder Modulen abgelegt werden was bei entsprechendem Design eine sp tere Wiederverwendbarkeit Reuse erheblich erleichtert Hier ist jedoch Vorsicht geboten Zu lange Passagen so genannter Spaghetticode werden schnell un berschaubar ebenso kann man bei zu vielen zu kurzen Funktionen schnell den berblick verlieren Auch auf konzeptueller Ebene ist darauf zu achten dass die Module untereinander eine vern nftige Bezie hung zueinander erhalten Die 1968 von Constantine eingef hrten Begriffe coupling and cohesion Kopp lung und Koh sion sollten dabei ebenso im Vorder grund stehen wie das Prinzip des Information Hi ding Diese wesentlichen Konzepte hier n her zu er l utern w rde jedoch den Rahmen dieser Arbeit spren gen 09 Laut Mills geh rt zu diesem Thema jedoch auch die gute Lesbarkei
224. infachere Handhabung als GL Sprachen 20 Die Verwendung von dom nenspezifischen Sprachen ist aber keineswegs neu BNF SQL HTML etc sind Beispiele f r dom nenspezifische Sprachen Die Erstellung von DSLs ist aber sehr aufw ndig 21 22 Im Zusammenhang mit MDE ist eine DSL eine Menge von zusammenh ngenden Modellen Das Modell des Systems verwendet Konstrukte die in einem Metamodell definiert sind Die Konstrukte im Metamodell sind wiederum in einem Metametamodell spezifiziert Das Metametamodell ist das letzte Glied in diesem Metamodeling stack 20 Es gibt genau 1 Meta und Metametamodell aber unterschiedliche Modelle die dem Metamodell entsprechen Abb 4 zeigt die Zusammenh nge context MetaMetaMaodel inv self conformsTo self A NetaMetaModel conforms to itself MetaMetaModel Abb 4 Metamodeling Stack 20 Als Beispiel sei hier XML erw hnt Ein XML Dokument beinhaltet Elemente die in einem XML Schema definiert sind das dem Metamodell entspricht Die Notation der Schemadefiniton ist wiederum in einem XML Metaschema definiert das dem Metametamodell entspricht 20 Da das Metamodell die Konzepte einer Dom ne spezifiziert beschreibt 20 aufgrund der Definition von Gruber T R das Metamodell als Ontologie Metamodeling Framework F r die erfolgreiche Anwendung von DSM mit automatischer Codegenerierung m ssen geeignete Werkzeuge in einer Entwicklungsumgebung vorhanden sein 23 beschre
225. innvolle Darstellung erzielt werden kann Wenn dadurch in einigen F llen recht d nne Br cken entstanden und in anderen vielleicht der Eindruck einer gewissen Schief lage eingemahnt werden k nnte w re solche Kritik zwar objektiv berechtigt sie w rde aber gegen die selbst auferlegten Regeln des Seminars versto en Ebenso k nnte man kritisch anmerken dass zu den historischen Arbeiten eigentlich auch der historische Hintergrund auf dem diese Arbeiten urspr nglich ge schrieben wurden aufgearbeitet werden sollte Dies fehlt in den schriftlichen Arbeiten weitgehend und wurde in den Vortr gen bzw wenn dann eher in den Diskussionen nur sporadisch angesprochen Aller dings geht diese Kritik ebenfalls von einer anderen Zielsetzung der Lehrveranstaltung aus Sie ist daher nicht gegen die Arbeiten sondern allenfalls gegen die Zielrichtung des Seminars zu wenden 4 Erfahrungen Aus meiner Sicht hat das Konzept des Seminars inhaltlich wie organisatorisch gut gegriffen Dass sich das Teilnehmerfeld von 27 Studierenden die sich an einem Thema versuchten relativ bald auf 22 redu zierte war zu erwarten Ich ging vielmehr aufgrund des mit dieser Organisationsform verbundenen Auf wands aller Beteiligten bereits vor Beginn der Kurz s Wenn Zeilen in der ersten Spalte abgesehen vom 3 Buch staben eine identische Kennung aufweisen bestand das zugeh rige Basisthema aus jeweils zwei Artikeln vortr ge davon aus dass letztlich nich
226. insbesonde re in den human orientierten Bereichen von Matsumo tos Artikel herangezogen werden Fuchu besch ftigte 2 300 Mitarbeiter Heutige Vertreter der Softwarebran che sind Microsoft mit berdimensionalen rund 76 000 Mitarbeitern 6 Sun mit 34 500 7 und SAP als deut scher Konzern mit knapp unter 40 000 Mitarbeitern 8 Dies darf jedoch nicht als exponentieller Ma stab gedeutet werden da es sich bei besagten Branchenrie sen eher um die Ausnahme als die Regel handelt Die Beispiele unterstreichen aber dass Softwareh user dieser Gr e existieren und derartig komplexe Unter nehmen auch in Anbetracht der fortschreitenden Globa lisierung nicht vernachl ssigt werden d rfen Ein ver gleichbarerer Wert eines durchaus gro en Unterneh mens w re Google mit rund 3000 Mitarbeitern 9 ein Ma stab in welchem das Fuchu Modell noch einwand frei funktioniert W hrend die Rahmenbedingungen technischer und humaner Ressourcen f r die Entwicklung noch gegeben scheinen wird sich das von Matsumoto propagierte der damaligen Zeit angepasste Schulungs und Karrie remodell in modernen Unternehmen nicht halten Die durchschnittlichen f nf bis neun Jahre Grundausbil dung die Fuchu anstrebt k nnen aus Kostengr nden nicht realisiert werden Einen promovierten Doktor noch f nf Jahre Programmierpraxis sammeln zu lassen erscheint aus didaktischer und integrativer Sicht sinn voll in der Praxis ist das Einsteigen von Akademikern
227. ion units betreffen zust ndig Die dritte Erweiterung sind Predicate units Diese erlauben die Definition von Bedingungen bei Beziehungen Dabei kann es sich um bestimmte Merkmale wie um referentielle Integrit t oder um Eindeutigkeit handeln Die vierte Erweiterung behandelt das Management der Transaktionen Die in APPL A verwendeten Transaktionsbefehle sind die serial atomic suspend enforce und allow Anweisungen Diese Anweisungen geben an wie mit den Daten bei Transaktionen verfahren werden soll bzw kann Wenn man sich Beispiele in Sutton 95 ansieht denkt man wieder an die Aussage Lehmans dass manche Codeabschnitte wiederum nur triviale T tigkeiten beschreiben APPL A wurde entwickelt um Versuche mit einer Prozessbeschreibungssprache beim Entwickeln von Prozessprogrammen machen zu k nnen Mit den Konstrukten von APPL A konnten sie einige unterschiedliche Softwareprozesse 82 programmieren einschlie lich der Aufgaben im Softwareentwicklungsprozess und im Management bereich Wenn man sich die unter Ziele definierten Punkte ansieht merkt man wie weit gestreut der Aufgabenbereich im Softwareentwicklungsprozess ist Durch das Experimentieren mit APPL A konnten einige wichtige Aspekte der Programmierung eines Prozessprogrammes verdeutlicht werden Vor allem waren dies Prozess Produkt und Projektmanagement mittel und langfristige Aktivit ten das Einbinden von Dokumentationen und automatisierten T tigk
228. ische Entit t einer Prozessbeschreibung Diese Prozessbeschreibung ist f r Menschen zwar leicht lesbar kann aber mitunter zu Problemen f hren Dijkstra Dijkstra 68 hat dies 1968 anhand der GOTO Anweisung beschrieben Die Erstellung von Software wird ebenso wie das Herstellen und Entwickeln von Autos M beln oder hnlichem als ein reales Produkt gesehen Es gibt hier zwar Parallelen aber Software bleibt trotzdem ein nicht greifbares nicht materielles unsichtbares Produkt Osterweil schreibt auch dass es keine konkrete Prozessbeschreibung zum Realisieren von Softwareprozessen gibt Aus was besteht nun eigentlich Software Wenn es sich um ein gro es Projekt handelt klarerweise aus tausenden Zeilen von Code Aber man produziert auch Unmengen an Begleitmaterial die gesamten Dokumentationen die Informationen bez glich der Anforderungen und des Design die Spezifikationen und Testf lle und die Benutzer und Wartungshandb cher um nur die wichtigsten zu nennen Osterweil findet es erstaunlich dass wir obwohl es keine pr zise Softwareentwicklungsprozess Beschreibung gibt trotzdem gute Produkte entwickeln Welche Software k nnten wir erst entwickeln wenn wir die bis dahin eingesetzten Prozesse zur Softwareentwicklung klar definieren k nnten Wenn wir eine genaue Beschreibung dieses Softwareprozesses h tten Wenn wir uns den 80 Computer als Hilfswerkzeug in gr erem Ma zu Nutze machen k nnten Eine L sung die Os
229. it bei Entwicklungs werkzeugen und Portablilit t Plattformunabh ngigkeit ver folgt Durch diesen Fokus werden bei MDA im Gegensatz du MDSD auch viele Einschr nkungen getroffen um diese Ziele zu erreichen MDSD kann deshalb als eine Auspr gung oder Interpretation von Model Driven Software Development ge sehen werden 11 3 2 Herausforderungen und Ziele Bevor auf den Ansatz und einige technische Grundlagen ein gegangen wird werden die von MDSD verfolgten Ziele und die Herausforderungen im Bezug auf heute etablierte Pa radigmen betrachtet die anschaulich am Beginn von 11 dargestellt werden e Durch Automatisation wird eine Steigerung der Ent wicklungsgeschwindigkeit angepeilt Aus formalen Mo dellen wird durch Transformationsschritte in letzter Instanz lauff higer Code erzeugt Durch den Einsatz von Automatisation und formal definierten Modellen wird implizit eine Steigerung der Software Qualit t er reicht da sich die Softwarearchitekuren ad quat in der Implementierung wieder finden e MDSD hilft auch beim Versuch eine bessere Handhab barkeit von Komplexit t durch Abstraktion zu errei chen Modellierung wird in den Rang der Program mierung auf eine h here abstrakte Ebene geho ben Um dies zu erreichen werden problemorientierte Modellierungssprachen ben tigt e Zwei weitere sehr wichtige Ziele die von der Object Management Group OMG verfolgt werden sind die Interoperabilit t zwischen
230. it ist der Lernfaktor und die Motivation wesentlich h her und die Einarbeitungszeit wesentlich geringer als alleine Die von McDowell Werner Bullock und Fernald vorgestellte Untersuchung 12 die die Noten von rund sechshundert Studenten in Programmiereinstiegskursen untersuchte zeigte ebenfalls die bessere Qualit t und Programmierleistungen bei Paaren Allerdings konnten die Einzelprogrammierer bei der Abschlusspr fung die knapp besseren Noten vorweisen Andererseits war die Motivation bei Paaren den Kurs bis zum Ende zu besuchen wesentlich h her rund 92 der Paare und nur 75 der Einzelprogrammier gingen zur Endklausur Phongpaibul und Boehm stellten eine empirische Studie aus Thailand vor 16 Sie untersuchte die Unterschiede zwischen dem Einsatz von Paar Entwicklung und dem Einsatz von Inspektionen anhand von zwei Projekten Da die Projekte eher kleineren Ausma es waren 600 Mannstunden beziehungsweise 1400 Mannstunden sollte man die Ergebnisse nicht berbewerten oder sie auf gr ere Projekte umlegen Sie geben aber einen kleinen Einblick in die M glichkeiten von Paarprogrammierung Beim ersten Experiment wurde von mehreren Studententeams sieben Teams haben Paarweise entwickelt sechs individuell mit Inspektionen in etwa die gleiche Qualit t erzielt bei rund einem Viertel weniger Entwicklungskosten Das zweite Experiment stellte zwei vergleichbare Softwareentwicklungen eines gro en thail ndischen Unternehmens geg
231. it von Fuzzy Logik behandelten die erschienenen Publikationen in der Mehrheit die theoretische Untersuchung von Erfolg versprechenden Verfahren Ein Res mee der bis 1978 ver ffentlichten Artikel zum Thema kann man in 11 finden Von Anfang der 70er Jahre bis in die fr hen 80er Jahre wurdem die ersten Anwendungen berwiegend im Bereich der Regelungstechnik implementiert Ich werde nun eine Auswahl von ihnen vorstellen 2 Mamdanis kleine Dampfmaschine L A Zadeh publizierte erste Arbeiten im Hinblick auf das Konzept zur Regelung mit Hilfe von Fuzzy Logik in den fr hern 70ern Die erste Implementation im Laborma stab erstellten E H Mamdani ein Professor an der Universit t von London und sein Student Seto Assilian im Jahr 1974 12 Es handelte sich um einen Fuzzy Regler der bei einer Dampfmaschine f r die Steuerung der Ventilstellung zur Dampfzufuhr und ebenso f r die W rmezufuhr zur Dampferzeugung verantwortlich war Linkman Ebenfalls wie die erste Anwendung kam auch die erste gr ere industrielle Realisierung eines Fuzzy Reglers aus Europa Die aus D nemark stammende Applikation mit dem Namen Linkman dessen Aufgabe es war die Zementbrennprozesse zu steuern wurde 1982 implementiert Subway Nach acht Jahren strenger Untersuchungen und zahlreichen Tests wurde 1986 in Sendai eine U Bahn in Betrieb genommen die vollst ndig mit Fuzzy Reglern ausgestattet ist und vollautomatisch f hrt Durch diese Anwendung
232. ke variables control flow subroutines and even interrupt handling 2 By using the very capable command language and the functionality of pipes together with the rich toolkit chapter 2 3 UNIX provides very complex programs can be written with low cost and quite good reliability 8 Although the shell resembles a typical procedural language it has rather different qualities Most important in certain ways it is a very high level language and as such is far easier to learn use and understand than lower level languages 2 This assumption is mainly based on the fact that a lot of the required functionalities are available in the toolkit and the programmer only needs to make the connection between them 2 3 The Toolkit Together with UNIX comes a rich set of tools that covers a lot of the functionality needed in everyday computing tasks A lot of these tools are written in C but any other programming language that can be compiled to a UNIX program could be used The fact that they are user programs and not systems programs allows for easy replacement Thereby performance enhancements or special adaptations can be easily managed Unix tools are built following a set of simple design principles e Each tool is responsible for doing a single job well e Functionality should be placed where it will do the most good e Tools generate textual output that other tools can use for example the program output won t cont
233. klein klein 1 00 stark mittel klein 1 00 mittel gros klein 1 00 schwach klein mittel 1 00 mittel mittel mittel 1 00 schwach gros mittel 1 00 schwach klein hoch 1 00 schwach mittel hoch 1 00 schwach hoch 1 00 schwach Abb 14 Regelbasis in SuccoSoft Ergebnis Bremskraft 72 eu 7 w Abstand 108 4 ae 175 144 462 ia Geschwindigkeit Abb 15 Funktion des Bremssystems 131
234. konnte die Fuzzy Theorie demonstrieren dass man sie auch in Situationen einsetzen kann in denen Sicherheit von enormer Bedeutung ist Durch den erfolgreichen Betrieb der U Bahn wurde die Fuzzy Logik in Japan sehr beliebt und man erkannte ihre M glichkeiten Folglich wurden zahlreiche Institutionen und Organisationen gegr ndet die sich mit Fuzzy Logik besch ftigen Etwa 1987 das IFSA International Fuzzy Systems Association oder 1989 das japanische LIFE Laboratory for International Fuzzy Engineering Research Institut das vom japanischen Ministerium f r Handel und Industrie und von 48 Unternehmen gef rdert wird In den sp ten 80er Jahren erscheinen viele Arbeiten in Japan die zwar zu einem Gro teil keine neuen Konzepte in der Fuzzy Logik Theorie aufwerfen sollten aber ber neue Anwendungen in der Regelungstechnik handelten Durch die vielen Produkte vor allem Haushaltsger te die die Fuzzy Logik Verfahren implementierten wurde in Japan ein regelrechter Fuzzy Boom ausgel st der seine Spitze 1990 erreichen sollte In diesem Jahr wurde fuzzy zum Wort des Jahres in Japan gew hlt Des Weiteren entwickelten japanischen Wissenschaftler Hardware L sungen um die Leistung von Fuzzy Systemen zu 116 erh hen Durch den immensen Erfolg in Japan wurde die Wirtschaft auch in Europa und in Nordamerika hellh rig 1 9 3 3 90er Jahre bis heute Bis in den Anfang der 90er Jahre war das haupts chliche Anwendungsgebiet von Fuz
235. lauf einer Iteration Eine Iteration ist also in vier Phasen unterteilt und nach jeder Phase wird ein Meilenstein gesetzt Dieser wird f r die Entscheidung genutzt ob die Iteration so fortgesetzt werden kann ob das Projekt abgebrochen werden sollte oder ob etwas ge ndert werden muss Hier nun eine Auflistung der vier Phasen mit den zugeh rigen Milestones e Inception Anfang Hier werden das Ziel und die Grenzen definiert Begrenzt wird diese Phase durch den Lifecycle Objective Milestone e Elaboration Ausarbeitung Hier werden die ben tigten Ressourcen ermittelt die n tigen Aktivit ten geplant die Funktionen festgelegt und die Architektur entworfen Abschlie end ist der Lifecycle Architecture Milestone e Construction Konstruktion Hier werden die Komponenten fertiggestellt Der Meilenstein ist der Initial Operational Capability Milestone e Transition bergabe Hier bekommt der Auftraggeber restriktive der Softwarebenutzer das Produkt Inkludiert sind das Installieren die Schulung der Support und die Wartung des Produktes Der Meilenstein Product Release schlie t die Phase und die Iteration ab Die erste Iteration wird auch als Initial Development Cycle bezeichnet die n chsten Iterationen sind Evolution Cycles In den unterschiedlichen Phasen werden unterschiedliche Schwerpunkte gesetzt In der Abbildung sieht man den Schwerpunkt in der ersten Phase der Inception besonders in der Anforderungsanalyse In
236. le an Computerprogramme beziehungsweise insbesondere an Internetanwendungen zu richten Die Programme sollen dann die Befehle des Benutzers verstehen und befolgen Insgesamt sind Zadeh und weitere Wissenschaftler die im Gebiet der Fuzzy Logik forschen der Meinung dass in naher Zukunft das Operieren mit Fuzzy Logik ein gro er Bestandteil unseres Alltagsleben wird Wobei der Benutzer bei der Anwendung wahrscheinlich nicht erf hrt welche Theorien und Technologien daf r erforderlich sind 5 Schlussfolgerung Trotz herber Kritik in den Anfangsjahren Rudolf Kalman William Kahan wurde vor allem an Universit ten theoretisch geforscht Ebenso wurden die ersten Prototypen mit Fuzzy Logik von Universit tsprofessoren implementiert Erst als es der Industrie als lukrativ erschien hat diese auch in Forschungen investiert Darin kann man den Wert der Forschung an Universit ten erkennen Erst die Erfolge in der Industrie haben auch Wissenschaftler in Amerika und Europa von den Vorteilen der Fuzzy Logik berzeugt Allerdings bemangelt Zadeh das Fehlen von gr eren Zuwendungen f r Forschung der Regierungen in Europa So erhalten die Universit ten in Nordamerika viel h here finanzielle F rderungen als es in den meisten europ ischen L ndern der Fall ist Generell haben Fuzzy Systeme eine schnellere und feinere R ckmeldungen als konventionelle Systeme Weitere Charakteristiken sind Energiesparsamkeit Reduzierung der Instandhal
237. lge werden von ihm Details zu den einzelnen Passagen erl utert die Logik verwendete Pfade und Abh ngigkeiten Er ist die Hauptperson bei der Designinspektion die vor der Codierungsphase stattfindet Der Programmierer ist verantwortlich f r den berpr ften Code Der Programmierer muss nicht begr nden warum er bestimmte Methoden oder L sungen zu Problemen gew hlt hat Im Gegenteil bei der Codeinspektion geht es lediglich um das Auffinden von Fehlern in einem Dokument Jede Zeile des Codes und jeder m gliche Zweig muss dabei erkl rt werden Der Tester sollte ein Experte auf seinem Gebiet sein Er ist f r das Schreiben oder die Ausf hrung von Testszenarien verantwortlich beziehungsweise f r das generelle Testen des Designs oder des durchzugehenden Codes Eine weitere Rolle ist die des Protokollf hrers Er hat zur Aufgabe die gefunden Fehler schriftlich festzuhalten Er muss keinerlei technische Erfahrungen mitbringen sie w ren aber von Vorteil In kleinen Teams bernimmt der Moderator diese Rolle 2 2 Fehlerkategorisierung Don t call them bugs call them quality improvement opportunities Graham Babel 1990 Das Ziel jeder Inspektion sollte ganz dem Auffinden von Fehlern verschrieben sein Diskussionen w hrend eines Meetings sollten nur soweit gef hrt werden wie sie dem Auffinden von Fehlern dienen Diese defects werden vom Protokollf hrer notiert und klassifiziert Es gibt eine Unterscheid
238. liche Wissensbasis auf der weitere Modellie rungen erfolgen k nnen Optimal w re der Einsatz von beiden Methoden So k nnte eine semi formale Model lierung der Kommunikation mit den Stakeholdern dienen und auch f r die Analytiker und Entwickler f rderlich sein w hrend eine formale den Modellen zugrunde liegende Wissensbasis eine exakt festgelegte Grundlage w re die bis zur Produktfertigstellung sich ndernden Anforderungen angepasst werden kann Dar ber hinaus w rde eine solche Wissensbasis auch entscheidend zum Grad der Wartbarkeit des Systems beitragen 7 Referenzen 1 Sol J Greenspan John Mylopoulus Alex Borgida Cap turing More World Knowledge in the Requirements Specifi cation Proceedings of the 6th international conference on Software engineering IEEE Computer Society Press 1982 2 John Mylopoulus Alex Borgida and Eric Yu Represent ing Software Engineering Knowledge Automated Software Engineering Springer Netherlands pp 291 317 1997 3 John Mylopoulus Information Modeling in the Time of the Revolution Information Systems 23 Elsevier Science Ltd pp 127 155 1998 4 Bashar Nuseibeh Steve Easterbrook Requirements Engineering A Roadmap Proceedings of the Conference on the Future of Software Engineering ACM Press pp 35 46 2000 5 Sol J Greenspan John Mylopoulus Alex Borgida On Formal Requirements Modeling Languages RML Revisted Proceedings of the
239. lierung Wie schon eingangs erw hnt spielen Modelle ein zentrale Rolle in der modellgetriebenen Entwicklung Diese bestehen aus Daten welche einer Struktur zugrunde liegen und eine Bedeutung in diesem Kontext haben Um eine automati sierte Verarbeitung wie Codegenerierung Modelltransfor mation etc gew hrleisten zu k nnen m ssen Struktur und Bedeutung exakt und eindeutig definiert vorliegen Ein Metamodell entspricht der Definition von Struktur und Bedeutung f r eine bestimmte Art von Modellen Auf ei ner abstrakten Ebene werden Modellkonstrukte Beziehun gen unter den Elementen und G ltigkeitsregeln spezifiziert Zur Visualisierung kann man die Beziehung von Metamodell zu Modell mit der von Klasse zu Instanz vergleichen In die sem Fall ist das Modell eine Instanz des Metamodells Die Beschreibung eines Metamodells k nnte im Prinzip auch Siehe Kapitel 3 4 1 und 3 4 2 28 textuell vorliegen aber auch hier macht eine formale Dar stellung durch ein Metametamodell Sinn Diese Schachte lung w re theoretisch auch noch weiter denkbar in der Pra xis geht man aber nicht ber die Metametaebene hinaus In diesem Fall beschreibt die Metametaebene sich selbst Im Standard der Object Management Group OMG taucht z B die Meta Object Facility MOF als Metametamodel auf welche sich auch selbst beschreibt Die Unified Modeling Language UML ist eine Instanz der MOF und konkrete UML Modelle sind Auspr gungen de
240. ll von null bis eins an So hat beispielsweise eine Temperatur von 19 9 Grad Celsius noch einen Zugeh rigkeitsgrad von 0 9 Eine Zugeh rigkeitsfunktion ben tigt man um die Abstufungen einer Zugeh rigkeit beschreiben zu k nnen In der vorhergehenden Abbildung haben war als die Zugeh rigkeitsfunktion eine Trapezfunktion definiert Ebenso wie in der klassischen Mengenlehre gibt es auch bei Fuzzy Mengen viele Operationen die man auf Elemente anwenden kann Genauso wie die boolsche Algebra die Verkn pfungen der klassischen Mengenlehre zur bivalenten Logik herstellt so ist dies auch bei der erweiterten Fuzzy Mengen Theorie der Fall Auch hier gibt es bereinstimmungen beispielsweise zwischen dem Durchschnitt und dem logischen UND der Vereinigung und dem logischen ODER und weiters auch zwischen dem Zugeh rigkeitsgrad eines Elementes in einer Fuzzy Menge und dem Wahrheitswertes einer Aussage in Fuzzy Logik Gleichfalls gibt es in der Fuzzy Logik auch Implikationen also logische Wenn dann Beziehungen wodurch man Regeln definieren kann 112 2 2 Fundamentale Verfahren Um die prim ren Verfahren die f r die Entwicklung eines Systems mit Fuzzy Logik erforderlich sind besser veranschaulich zu k nnen m chte ich ein simples Beispiel f r ein leichteres Verst ndnis zu Hilfe nehmen Hierbei orientiere ich mich im Besonderen an 2 und 1 Beispiel Ich will einen Regler f r eine Klimaanlage erstellen Von den Senso
241. ls mit einflie en Diese Sicht beleuchtet ausschlie lich fachliche Bestandteile und ist f r den Endanwender und das Management geeignet Implementierungs Prozess und Verteilungssicht decken das technische Architekturmodell ab Die Implementierungssicht ist f r den Programmierer In ihr werden die Softwaremo dule organisiert Der Verantwortungsbereich f r nebenl ufige und parallele Aspekte des Systems liegt bei der Prozesssicht Sie ist f r Systemintegratoren geeignet und deckt weiters noch Performanz und Skalierbarkeit ab Systemingenieure befassen sich mit der Verteilungssicht In ihr betrachtet man die physische Verteilung der Systemkomponenten auf verschiedene Rechnerknoten und befasst sich mit Installation und Auslieferung Die Anwendugsfallsicht umfasst die Use Cases Diese Sicht ist die zentralste aller Sichten da die Use Cases das Fundament f r s mtliche Aktivit ten sind Die Anwendungsfallsicht berlappt sich mit allen anderen vier Sichten weil diese die Informationen aus der Anwendungsfallsicht ben tigen Iterativ Inkrementell Der iterative und inkrementel le Aspekt vom RUP geht bereits aus Punkt 3 1 hervor Aufbauend auf dem Spiralmodell 10 von Boehm l uft die technische Umsetzung in Iterationen ab wodurch Arbeitsergebnisse schrittweise weiterentwickelt werden Wasserfallartig werden die Prozessaktivit ten pro Iteration abgearbeitet Am Ende jeder Iteration wird die n chste Iterationsrunde vorausgeplant Die
242. lso nun erkennen kann leitet man die Wahrscheinlichkeit eines Theorems mit den dazugeh renden Bedingungen von dieser Verkniipfung ab Die meisten Theoreme sind disjunktiver Art Es gibt nun noch eine Menge Regeln fiir die Ableitung von Infor mationen aus anderen Diese werden fiir die Arbeit nicht weiter ben tigt k nnen aber in 1 begutachtet werden 3 Anwendungen und weitergehende Er kl rungen Es wurde nun eine Motivation geliefert und die Grundbegriffe erkl rt Zum besseren Verst ndnis und f r eine tiefer gehende Auseinandersetzung werden jetzt einige Anwendungsgebiete von Fuzzy Logik er l utert Es gibt viele Anwendungsgebiete bei welchen man mit direkten mathematischen Modellen rechnen kann Dies ist zumeist dann der Fall wenn der Mensch selbst bereits diese Normierungen eingef hrt hat und auch Sensoren Geschwindigkeitsmessger t Thermometer usw sowie Aktoren Motoren Relais usw besitzt welche direkt mit Zahlen arbeiten k nnen Ein Beispiel bei dem man mit konkreten Zahlen rechnet w re die Wettervorhersage In diesem Feld entstehen gen gend konkrete Werte So wird mit Fakten wie Windge schwindigkeit in km h Hoch und Tiefdruckgebiete in mbar Luftfeuchtigkeit in Prozent die Vorhersage f r die weiteren Tage getroffen In vielen anderen Bereichen gibt es keine derartig genauen Messdaten welche man einem System zuf h ren kann Anwendungsbereiche sind Psychologie Wirtschaft Hier muss man meist von
243. m 20 There seemed to be a few situations where goto s are used in a considerable amount First they are most often used for performing cleanups The example I would like to present is a form of a cleanup stack This programming technique is used for example for initializing hardware drivers where several conditions might fail and a previous state has to be restored before returning to the calling procedure again see illustration 1 Exception handling is another use for goto s because the programming language C does not provide a built in support for handling errors As described in illustration 2 there might be several points in the program where errors can occur The only thing that needs to be done is to branch to the exception handler that is usually located at the end of the procedure after the default exit int error EINVAL Monitor the error conditions and go to the cleanup routines if necessary if strlen class dev gt class_ id goto outl error kobject_add amp class dev gt kobj if error goto out2 error make deprecated class device links class dev if error goto out3 If there was no error go to directly to return goto outl Undo several settings in a cleanup stack out3 class device remove groups class dev out2 if parent_class dev class device put parent_class dev class put parent_ class outl class device put class dev return error Illustration 1 Example
244. m Prozess der Inspektion auf Codebasis durchschnittlich bei rund 60 liegt Werden bei einem Dokument also drei ig Fehler gefunden sind zirka zwanzig Fehler unentdeckt geblieben Aus diesen drei ig Fehlern gehen f nf neue hervor die die Produktivit t einer Codeinspektion auf knapp 50 senkt Erst wenn die entdeckte Fehlerrate unter ein gewisses Niveau f llt Beispiel zwei leichte Fehler pro Seite kann das Dokument weitergegeben werden und die n chste Phase kann beginnen Ein gewisses Restrisiko an Fehlern ist immer vorhanden Ein einzelner Inspektionsdurchgang wird nie alle Fehler entdecken In der Theorie k nnte man Inspektionen so lange wiederholen bis man keine Fehler mehr findet Dies schlie t jedoch nicht aus dass keine Fehler mehr im Dokument vorhanden sind In der Praxis rechnet man mit einem gewissen Prozentsatz an Fehlern deren Beseitigung den hohen Aufwand der Inspektionen im besten Fall unterschreitet Die NASA setzt f r kritische Systeme die wiederholte Durchsicht eines Dokuments von mehreren Inspektionsteams mit keinen gefundenen Fehlern voraus Trotzdem kommt es aufgrund von Fehlern in der Software immer wieder zu Zwischenf llen 2 4 Weitere Reviewtechniken Walkthroughs sind Reviews informeller Art Es m ssen nicht alle Teilnehmer vorbereitet sein Es gibt keine Checklisten und die Anberaumung einer Sitzung kann kurzfristig erfolgen Sie werden unter anderem dazu verwendet aktuelle Design oder Programmf
245. m und dessen 99 Umgebung zu berdenken Modellierungstechniken sollten nun imstande sein auch das Warum in Betracht zu ziehen um so die semantische Kluft zwischen dem System und dessen Umgebung so weit wie m glich zu schlie en 12 4 2 Vorteile durch Zielorientiertheit Es gibt mehrere Gr nde warum eine Ber cksichtigung von Zielen im Prozess des RE hilfreich sein kann Zum einen wird das Streben nach Vollst ndigkeit der An forderungsspezifikation in der Hinsicht unterst tzt dass eine solche Spezifikation nur dann vollst ndig sein kann wenn alle Ziele durch die spezifizierten Eigenschaften des Systems erf llt werden k nnen Auch irrelevante Anforderungen n mlich solche die nichts zur Erf llung zumindest eines Zieles beitragen k nnen so erkannt werden Weiters deckt eine Verfei nerung der Ziele m gliche Konflikte die durch ver schieden Betrachtungen entstehen k nnen auf Nicht unwesentlich erleichtert die Definition von Zie len die Kommunikation mit dem Auftraggeber So k nnen beispielsweise durch die Zielverfeinerung die in einer Baumstruktur dargestellt ist strategische Ziele mit technischen Anforderungen nachvollziehbar in Beziehung gebracht und so dem Kunden leichter ver st ndlich gemacht werden So k nnen im Zuge dieser Zielverfeinerung m gliche Alternativen ausgeforscht werden die Analytiker in der Folge gemeinsam mit dem Kunden ausarbeiten 4 3 Vergleich mit objektorientiertem Ansatz Im Ve
246. mation deren Instan zen zugeordnet werden kann Dadurch stellen sich auch die Beziehungen zwischen den drei Typen Enti t ten Aktivit ten und Behauptungen heraus 98 Activity Class AdmitPatient with participants pt Person wrd Ward d Doctor parts document GetInfo amp CheckBloodPressure of lt gt pt checkIn AssignBed toWhom lt gt pt onWard lt gt wrd record Admission who lt gt newPatient where lt gt wrd when lt gt today preconditions isThereRoom wrd admitted lt wrd capacity patientAlready not pt is in Patient canAdmit HasAuthority who lt gt d where lt gt wrd postconditions incrementCount makePatient end Activity wrd admitted lt pt is in Patient wrd admitted 1 EntityClass Patient with necessary unique parts record MedicalRecord associations location NursingHome room Room physician Doctor producers register AdmitPatient pt lt gt this modifiers assessment AssessPatient patient lt gt this consumers release DischargePatient patient lt gt this initially startClean end Patient Abb 2 Aktivit t und Entit t in RML 5 record paymentDue 0 Das Beispiel der Klassenbeschreibungen einer Aktivi t t und einer Entit t in Abb 2 soll die erw hnten Tech niken verdeutlichen Es ist ersichtlich dass die Art des beschriebenen Objekts durch das erste Schl sselwort definiert wird So beschreibt einen ActivityClass eine Aktivit t usw
247. mponente werden evtl existierende Fehler in dieser beseitigt Dadurch steigt parallel die Qualit t und Zuverl ssigkeit des zu entwickelnden Gesamtsys tems e Erweiterbarkeit Ein System das aus wiederverwendeten Komponen ten besteht ist leichter zu erweitern Au erdem ent steht dabei ein st ndiger Lernprozess f r den Entwick ler durch Techniken und Ansichten die der urspr ng liche Autor verwendet hat Software Reuse ist nur bei entsprechender Organisation des Reuse Prozesses wie in 7 beschrieben sinnvoll 2 2 Reuse Prozess Der Software Reuse Prozess ist ein Lebenszyklus der auf einer Bibliothek aufbaut und aus folgenden Phasen besteht 12 p 46 1 Einordnen Classifying von Software Komponenten die zur Wiederverwendung bereitgestellt werden 2 Sp teres Wiederauffinden Retrieval dieser Kompo nenten von anderen Entwicklern 3 Entwicklung neuer Software aufgrund der gefundenen Software Komponenten Dieser Prozess soll f r alle Beteiligten so einfach als m glich gehalten werden da andernfalls auf den Reuse von existie renden Komponenten verzichtet und die ben tigte Funktio nalit t selbst entwickelt wird 12 p 46 3 PROBLEMBESCHREIBUNG Dass Software Reuse nicht nur Vorteile sondern auch Kri tikpunkte mit sich bringt wird durch den Reuse Prozess er sichtlich Alle Vorz ge die in Kapitel 2 1 beschrieben wur den treten also nur in Kraft wenn die Hauptprobleme des Reuse Proz
248. n um die Soft ware unter einem gewissen Grad von Abstrak tion zu spezifizieren besserer Semantik f r bestehende Anforde rungen und Designsprachen Software Wissensbasis welche nutzvolles Wissen ber ein spezielles Softwaresystem ber den gesamten Lebenszyklus beinhaltet verst ndlich organisiert ist und Abfrageme chanismen bereitstellt 2 3 Anforderungsmodellierung mit RML In diesem Abschnitt werde ich die formale Anforde rungsmodellierungssprache RML Requirements Mo deling Language vorstellen Sie wurde 1984 von Sol J Greenspan auf der Basis eines fr heren von Greenspan entworfenen Frameworks entwickelt und war als for male Grundlage der SADT Structured Analysis and Design Technique Diagramme gedacht Somit schlie t sie eine gleichzeitige Anwendung einer infor malen Notation nicht aus RML greift dabei auf Ideen aus der Wissensrepr senta tion und den Semantischen Datenmodellen zur ck Das Resultat ist eine objektorientierte formale Anforde rungssprache in der Entit ten und Aktivit t in einer Generalisationshierarchie organisiert sind und die einigen anderen objekt orientierten Techniken voran gegangen war 3 Dar ber hinaus soll eine Sprache wie RML als explizi tes Modell des Anwendungsbereiches einschlie lich des organisatorischen Umfelds gesehen werden in dem das ben tigte Wissen strukturiert und organisiert wird und das so den Entwicklern als Verst ndnisgrundlage dienen kann
249. n 5 10 Als Ergebnis der Implementierung der Architektur k nnen Komponenten Programmgeneratoren 105 Frameworks oder dom nenspezifische Sprachen entstehen die bei der Applikationsentwicklung als Werkzeuge genutzt werden Bei der Applikationsentwicklung werden w hrend der Analysephase die Kundenanforderungen aus dem Dom nenmodell herangezogen Neue Anforderungen die nicht im Dom nenmodell abgebildet sind werden gesondert betrachtet und evaluiert und flie en auch wieder in das Dom nenmodell ein Die System Architektur basiert auf der Architektur des Domain Engineering Prozesses und wird angepasst Mit Hilfe der erzeugten Artefakte bei der Domain Implementierung wird das System erstellt 5 Bekannte Domain Analyse Methoden sind FODA Feature Oriented Domain Analysis entwickelt von Software Engineering Institute SED http www sei cmu edu ODM Organization Domain Modeling entwickelt von Mark Simos of Synquiry Ltd DARE Domain Analysis and Reuse Environment Einer der ersten Methoden die auch Arango beeinflussten war Draco entwickelt von J Neighbors 11 4 Software Produktlinien SPL Line Engineering Product Viele Unternehmen entwickeln Systeme innerhalb einer Dom ne und bringen unterschiedliche Produktvarianten auf den Markt 12 13 Man spricht auch von Produktfamilien bei denen die Sichtweise auf die Gemeinsamkeiten der Produkte gelegt ist w hrend der Begriff Prod
250. n anhand der Fuchu Software Factory in der die Soft wareentwicklung in f r damalige Verh ltnisse h chst industrialisierten definierten Abl ufen durchgef hrt wird Es wird ein strukturierter Entwicklungsprozess mit klaren Verantwortlichkeiten beschrieben Aus dem Prozess sind bereits klar die unterschiedlichen Phasen Planung Design Implementierung Test Produktivsetzung des Systems erkennbar Benannte Base Lines bilden Review Zeitpunkte in welchen nicht nur die Qualit t der Pro duktentwicklung bis zu dem entsprechenden Zeitpunkt gepr ft wird sondern diese auch mit dem pers nlichen Profil Spektrum des jeweiligen Mitarbeiters korrel liert wird Somit wird nicht nur der Fortschritt am Pro dukt sondern auch mit jedem Prozessschritt der per s nliche Fortschritt des Mitarbeiters dokumentiert Basierend auf diesen unterschiedlichen Reviews werden die Fehler erhobene Prozentraten interne Tests Vor Ort Tests entsprechend in Design Fehler 35 45 Programmierfehler 20 10 Datenfehler 30 20 und Hardware Interface Fehler 15 25 unter teilt Die Strukturierung in unterschiedliche Phasen und eine klare Aufgabenverteilung innerhalb des Erstel lungs Prozesses werden in zwei Bereichen fortgef hrt Einerseits werden die personenbezogenen Faktoren herausgearbeitet indem die strukturierten Karrierem g lichkeiten der Factory skizziert werden Es wird die Beurteilung der einzelnen Personen anhand einer
251. n Entwicklung wird Soft warearchitektur ganz allgemein eingesetzt um das zu erzeugende System zu strukturieren Es ergeben sich die gleichen Fragestellungen und Probleme wie bei z B der Modell basierten Entwicklung Bei der modellge triebenen Entwicklung kommt als weiterer Aspekt hin zu dass von der Softwarearchitektur auf eine Zielarchi tektur abgebildet wird welche auch die Plattformar chitektur umfasst siehe unten e Die Softwarearchitektur hat auch bei der Transfor mation einen hohen Stellenwert Durch diesen Schritt Tn 12 wird erw hnt dass bei sehr vielen Projekten UML als grafische Modellierungssprache als Standard verwendet wird und ber andere Sprachen nicht nachgedacht wird bzw diese nicht in Erw gung gezogen werden Die selbe Aussage wird auch f r Programmiersprachen Plattformen und Fra meworks getroffen wird die Softwarearchitektur des generierten Produk tes auch Zielarchitektur genannt festgelegt An dieser Stelle m ssen auch ggf ben tigte Integrationspunkte festgelegt werden die manuell mit Fachlogik auspro grammiert werden Die Zielarchitektur ist zentral in die modellgetriebene Ent wicklung eingebettet den Ziel ist es diese automatisiert zu generieren Nur wenn die Konzepte der Zielarchitektur ausf hrlich definiert sind und sich systematisch durch Trans formationsvorschriften beschreiben lassen ist eine automa tische Generierung m glich Der generierte Code baut meist auf Programmb
252. n Methoden an welche die Funktionalit t der Software Komponente bzw des Objektes charakterisieren Die Operations Facette soll nun eine Liste von Operationen die von einer Komponente angeboten werden beinhalten z B push pop Falls es sich bei der Software Komponente um eine einzige Klasse handelt sollen It Karlsson et al in 4 nur die ffentlichen public Methoden aufge listet werden e OperatesOn Die OperatesOn Facette beinhaltet die Objekte die von der Software Komponente bzw von der Klasse verwaltet werden u a In und Output Argumente e Dependencies Die letzte Facette ersetzt die drei Umgebungs Facetten aus der Arbeit von Prieto Diaz und Freeman in 11 Die Dependencies Facette beinhaltet alle Abh ngig keiten welche die Verwendung der Software Kompo nente einschr nken k nnte Karlsson et al machen in 4 jedoch keine konkreten Vorschl ge welche genauen Werte diese Facette annehmen sollte M gliche Bei spiele w ren Design Methodologie Programmierspra che und Hardware hnlich wie bei der Arbeit von Prieto Diaz und Freeman in 11 existiert auch im REBOOT System von Karlsson et al in 4 ein Modell das dem Distanz Modell nachempfun den ist und auf die semantische Distanz zwischen verschie denen Facetten Beschreibungen abzielt Dieses wird f r den REBOOT REuse Based on Object Oriented Techni ques Search and Retrieval Mechanismus verwendet der folgen de besondere
253. n R T Yeh ed Current Trends in Programming Methdolology s2 B H Liskov S N Zilles Specification Techniques for Data Abstractions Vol 1 1977 pp 1 32 x x D Harel E Gery Executable Object modeling with Statecharts IEEE Computer July 1979 pp 31 42 D Harel E Gery Executable object modeling with statecharts Proc 18th ICSE March 1996 pp 246 ff Software Technology Program slicing Proc 5th ICSE 1981 San Diego pp 439 449 Kaas Programmers use slices when debugging Comm ACM Vol 25 7 pp 446 452 zn Proc Internat Conference on Reliable Software Los Angeles 1975 t2 F DeRemer H H Kron Programming in the Large vs Programming in the Small pp 114 121 x W P Stevens G J Myers t3 L L Constantine Structured Design IBM Systems Journal May 1974 pp 115 139 x D T Ross K E Schoman Jr Structured Analysis for Requirements Definition IEEE Trans on Software Eng Vol SE 3 Jan 1977 pp 6 15 Sas ae Design and Code Inspections to Reduce Errors t5 M E Fagan in Program Development IBM Systems Journal Vol 15 3 1976 pp 182 211 x x B W Kernighan J R Mashey The Unix Programming Environment IEEE Computer April 1981 pp 12 22 Software Development Process B W Boehm Software Engineering IEEE Trans on Computers Vol C 25 12 Dec 1976 pp 1226 1241 A Software Factory Matsumoto An Overall Approach to Software Production in P Freeman Tutorial Software Reusability IEEE 1987 pp 155 178 i BL
254. n Worten vorstellen und anderseits zeigen welche Sto richtung sie in ihrer eigenen Arbeit verfolgen wollen An jeden dieser Vortr ge schloss sich eine kurze Diskussion Drei Studierende meldeten sich noch vor den Kurz vortr gen ab sodass insgesamt 22 Vortr ge an drei Seminartagen gehalten wurden N chster Schritt war die Abgabe des Vollbeitrags Die Abgabetermine waren entsprechend den Kurzvor tragsterminen gestaffelt Mitte bis Ende Mai Die Abgabe erfolgte wiederum in MyReview und wurde wieder von 4 Personen begutachtet Diese sollten mit den Gutachtern der Ersteinreichung ident sein Durch die inzwischen eingetretenen Ausf lle und durch wie tere Ausf lle bei der Endabgabe mussten jedoch eini ge Neuzuordnungen getroffen werden Letztlich wur den nur mehr 17 Arbeiten eingereicht Eine dieser Ar beiten wurde im Begutachtungsprozess ausgeschieden Eine andere Arbeit kam trotz sehr positiver Begut achtung aus pers nlichen Gr nden der Studierenden nicht zum letzten verpflichtenden Schritt dem Vortrag Somit fanden im Zeitraum 6 bis 26 Juni insgesamt 15 Vortr ge zu je 30 Minuten mit anschlie end etwa 15 Minuten Diskussion statt Die Studierenden hatten nach dem Vortrag noch bis 15 Juli bewusst ein Ter min in den Ferien Zeit ihren Vollbeitrag im Lichte der Ergebnisse des Begutachtungsverfahrens sowie auf der Grundlage der Diskussion nach ihrem Vortrag zu berarbeiten Die in den folgenden Kapiteln in der Reihenfolge de
255. n als Vorbild fungiert ist es leicht erkl rlich dass Fuzzy Logik schnell Einzug in diesen Bereich gefunden hat Fuzzy Logik hat bereits einen gro en Einfluss auf viele Bereiche der k nstlichen Intelligenz Da wir am Beginn des Zeitalters der Intelligenz von Maschinen stehen werden noch viele Anwendungen in diesem Forschungsgebiet folgen Das Sprachverstehen etwa ist bisher eine relativ schwerer Forschungsbereich gewesen Die Forschung versucht auf der einen Seite das Verstehen einer nat rliche Sprache zu erm glichen und deren Bedeutung in eine formalere Sprache abzubilden und andererseits versucht sie automatisch eine nat rliche Sprache auf Grund von formalen Informationen zu generieren Damit dies berhaupt m glich ist ist es notwendig dass ein Computerprogramm den Sinn von Texten versteht Dies und auch die Wissensrepr sentation sind die Hauptprobleme in diesem Bereich welche durch Fuzzy Logik gel st werden Ein recht neues Forschungsgebiet ist das Internet Der Trend geht in Richtung intelligente Suchmaschinen Das semantische Netz ben tigt eine Wissensrepr sentation und auch Schlussfolgerungen welche mit verbalen W rtern also ungenauen unscharfen Werten umzugehen wei Momentan arbeiten bereits Spamfilter mit einem Steuerungssystem basierend auf der Fuzzy Logik Theorie Zadeh behauptet dass es bereits in relativ naher Zukunft m glich sein wird mit Hilfe von Fuzzy Logik in einer nat rlichen Sprache Befeh
256. n die vier Schichten Werkzeuge Methoden Prozesse und eine Schicht f r den Qualit tsfokus 14 Das Fundament f r Software Engineering bildet die Prozessebene Die impliziten Softwareprozesse sind nach Pressman der Leim der die Technologieebenen zusammenh lt 14 Prozessmodelle erm glichen eine vern nftige und zeitgerechte Entwicklung von Softwareprodukten vgl 14 pp 22 Sie sind Schl sselkomponenten f r die methodische Entwick lung von Softwareprodukten und leisten einen enormen Beitrag zur Verbesserung des Entwicklungsprozesses sowie der Produktqualit t Die Begriffe Prozessmodell und Vorgehensmodell werden im Paper synonym verwendet Winston Royce ver ffentlichte 1970 das Wasser fallmodell Dieses gilt als erstes konkretes Vorgehens modell und erlangte durch Barry Boehms Artikel Software Engineering 1976 1 breite Bekanntheit Boehms Paper 1 ist der Leitartikel f r die vorliegende Arbeit da das Wasserfallmodell die Basis f r die meisten Prozessmodelle bildet 10 Im weiteren Verlauf zeigt dieses Paper einen Einblick in die Entwicklung von Prozessmodellen Es werden Entwicklungsans tze beschrieben und Vorgehensmo delle diskutiert die seit der Etablierung des Wasser fallmodells entstanden sind Bei den bekanntesten Prozessmodellen findet sich eine Unterscheidung in deren Ans tzen Dies sind unter anderem der evolution re und inkrementelle Ansatz die iterative und phasenorientierte Entwicklung
257. n elimination is another main feature of performance tuning The overhead of handling a caller stack for all the called procedures can be significantly high Indeed it is not arguable that recursions can provide very small and nice solutions for a number of problems but the negative side effect of being slower in most cases cannot be neglected Another application for goto s is the removal of boolean variables using code duplication and unconditional jumps The code depending on a boolean decision is copied and altered in that way that the first copy handles the true case and the second part handles the false case After all the real issue is to write programs that are well structured and can be proven formal or informal i e it is enough to really understand whether a program is correct or not For this a good structure is supportive To conclude his essay Knuth stated that it is not a good idea to write programs with goto s and then eliminate them The goal should be to write understandable programs not only in a small but in a bigger scale A good way to achieve this is by using abstraction in different levels of the program to provide a means of understanding the whole program conveniently This conclusion does not exclude the use of goto s by default As long as the goto statements do not destroy the possibility to easily grasp the big picture Moreover if goto s provide an even better and more understandable code everything shoul
258. n gt lt primitive gt lt pointcut gt lt pointcut gt lt primitive gt lt args gt lt parameter gt lt parameter gt lt args gt lt primitive gt lt pointcut gt lt and gt lt pointcut gt lt named pointcut gt lt item gt lt body gt lt ax aspect gt Abbildung 4 Aspektdeklaration in Weave NET Das Aspekt Verhalten wird in C implementiert using System namespace Aspect_IOChecking public class IOChecking public void LogWrite object data Console WriteLine data toString 3 Zusamenfassung und Ausblick Wenn in einem System Crosscutting Concerns identifiziert werden k nnen macht es Sinn Aspekt orientierte Programmierung als Paradigma der Soft wareentwicklung einzusetzen Crosscutting Concerns verursachen Redundaten Quellcode d h gleicher bzw hnlicher Quellcode ist ber die gesamte Applikation verstreut Das macht den Quellcode schwer verst ndlich und schwer ver nderbar Durch Aspektorientierte Pro grammierung k nnen Kosten bei der Wartung oder Er weiterung des System gespart werden Eine klare Ab 38 grenzung von Aspekten von den Komponenten eines Systems erh ht die Verst ndlichkeit des Gesamtsys tems Werden Aspekte richtig identifiziert dann kann die Aspektorientierte Programmierung stark zur Ver besserung von Wiederverwendbarkeit beitragen Ex perimente zeigten dass Entwickler die AOP verwen den Fehler in der Applikation schneller finden als
259. n in 11 in eine konkre te L sung das Faceted Classification Scheme bergeleitet wurde und die Umsetzung aller Annahmen und Anforderun gen die im Modell entstanden sind beinhaltet Im folgenden Kapitel wird nun auf die Herleitung dieses Schemas und eine konkrete Realisierung n her eingegangen 4 1 Komponenten Beschreibung Bei der facetten orientierten Klassifikation wird die Beschrei bung einer Software Komponente in elementare Klassen zer legt und diese anschlie end mit Facetten beschrieben Diese Beschreibung soll kurz und b ndig ausfallen Die Klassifi zierung wird anschlie end durch die Gruppierung der Fa cetten gew hrleistet Diese Art von Klassifizierung ist leicht erweiterbar flexibel und f r sehr gro e st ndig anwachsen de Software Collections ausgezeichnet geeignet 8 11 Prieto Diaz und Freeman bauen in 11 auf den Ansatz auf dass Software Komponenten mit den folgenden beiden Be schreibungen charakterisiert werden k nnen 11 e Funktionalit t Functionality e Umgebung Environment Durch Analysieren dieser Beschreibungen wurden konkrete Facetten hergeleitet die fiir die Beschreibung von Software Komponenten im facetten orientierten Schema dienen Funktionalitat Existieren beispielsweise zwei Software Komponenten wel che die gleiche Funktionalit t realisieren bedeutet dies nicht zwingend dass die beiden Komponenten gleich sind Man denke zum Beispiel an die Implementierung einer
260. nach au en verkauften Software aus Um diese Struktur ab einer bestimmten Unternehmensgr e konsequent tra gen zu k nnen koordiniert ein Reuse Steering Board als bergeordnete Instanz das Zusammenspiel der zwei Entwicklungsbereiche Dieses Reuse Konzept wird aufgrund seiner Bedeutung in weiterer Folge auch bei der Untersuchung der gegenw rtigen Situation detail lierter behandelt Diese bereits stark an moderne Organisationshie rarchien erinnernde Struktur wird auf technischer Ebe ne von einer Datenbank verwaltet in welcher die Reu sekomponenten von einem einfachen Keyword Retrieval System unterst tzt gesucht werden k nnen Zus tzlich wird ein objektorientieres System beschrie ben das auf OKBL object oriented knowledge based language basiert OKBL ist eine objektorientierte Sprache die von Matsumoto und Yonezawa spezifi ziert wurde 3 ber die der User durch Interaktion mit den Suchobjekten seine Suchkriterien verfeinern kann und somit zu einem besseren Ergebnis kommt Die Entwicklung welche diese damals etwas mehr als state of the art Sicht der Dinge bis heute genommen 48 hat wird nun detaillierter untersucht um anschlie end zu sehen wie sich die beschriebenen Konzepte insbe sondere Reuse und die Software Workbench als In strument zur technischen Unterst tzung entwickelt ha ben 2 Evolution in die Gegenwart Der Vergleich eines 1987 erschienen Werkes mit aktuellen Gegebenheiten kann nicht erfolgen
261. nal Softwarekomponenten Auch Bertrand Meyer stellt in 20 ein Komponentenqualit tsmodell vor Meyer nennt es das ABCDE der vertrauensw rdigen Kompo nenten Das ABCDE steht f r die f nf Qualit tskrite rien wobei sich die Buchstaben aus den jeweiligen An fangsbuchstaben der f nf Kriterien ergeben Acceptan ce Behavior Constraints Design und Extension Zertifizierung Die oben andiskutierten Qualit tsmo delle sind die Grundlage zur Sicherung von Qualit ts kriterien Evaluiert man nun solche Qualit tszusiche rungen spricht man von Zertifizierung Die For schungsgemeinde hat sich seit 1993 mit diesem Thema auseinander gesetzt Dominierten anfangs noch mathe matische und testbasierte Modelle 32 als Evaluie rungstechniken so nderte sich der Fokus um die Jahr tausendwende hin zu Techniken und Modellen welche sich aus der Vorhersage von Qualit tsanforderungen ergeben 1 Alvaro et al untersuchten in Software Component Certification A Survey die Forschungs bem hungen seit 1993 und haben dabei zwei Str mun gen entdecken k nnen Die eine Richtung behandelt Zertifizierung vorwiegend von der formalen Seite also wie die Korrektheit von Eigenschaften bewiesen oder vorhergesagt werden kann Die andere Str mung geht mehr in Richtung Evaluierung von Qualit tsmodellen und deren Zertifizierung Die Forschung im Bereich der Zertifizierung von Softwarekomponenten ist nach wie vor aktuell Boegh 5 weist jedoch dar
262. nce zu sehen wie sich andere einer vergleichbaren Aufgabe stellten W nschenswert w re hierbei nat rlich dass jedes Gut achter Panel und jedes Paket aus zu begutachtenden Arbeiten ein breites qualitatives Spektrum abdeckt Dies l sst sich vorab nicht realisieren Bei der 3 1 Zu sammenstellung ist die Chance auf eine gewisse Vari anz innerhalb der Qualit t der zu begutachtenden Arbeiten wie auch innerhalb der Qualit t der erhalten en Arbeiten aber doch relativ hoch Bleibt als letztes Element die Qualit t der Lehrver anstaltung als solcher Diese lebt nat rlich von der Motivation der Teilnehmerinnen und Teilnehmer Wenn allerdings bei den einzelnen Vortr gen mindes tens 4 Personen im Raum sind die sich mit der vorge tragenen Arbeit schon auseinander gesetzt haben wird die Diskussion wohl besser sein als wenn Vortragende und Zuh rer ihre physische Pr senz nur unter das Motto stellen nur ja nichts zu fragen oder zu sagen gt Ob Feedback von Peers oder von der Seminarleitung kam war den Empf ngern nicht ersichtlich In manchen F llen mag man aus dem Inhalt Vermutungen gesch pft haben In der Regel lagen war dies allerdings nicht m glich und ich bin auf Grund des Inhalts mancher studentischer Gutachten berzeugt dass einige derartiger Vermutungen falsch waren weil man im Gegenzug ja auch gefragt werden k nnte Hier war die Diskussionszeit jedoch vor allem bei den Kurzvortr gen aufgrund der in dieser Phase noc
263. nden k nnen Die Ausgangsarbeiten waren in der e Lear ning Plattform MOODLE abgelegt und konnten daher von allen Seminaristinnen und Seminaristen angelesen werden Innerhalb der ersten zwei Wochen des Semesters konnte man im MOODLE Diskussionsforum eine Nachricht posten welchen Basisartikel in einigen F l len handelte es sich um Paare zusammengeh riger Ar tikel und damit welches Thema man gew hlt hat Diese Postings waren allen Seminarteilnehmern er sichtlich Weiters markierte der Seminarleiter perio disch jene Arbeiten die bereits gew hlt und damit vergeben waren Nach weiteren drei Wochen also etwas ber ein Monat nach Veranstaltungsbeginn war ein kommen tiertes Inhaltsverzeichnis abzugeben Dieses sollte ne ben Titel und kurz erl uterter Gliederung ein Abstract enthalten aus dem hervorging wie man den Basis artikel in der Informatik Gegenwart positionieren m chte Die meisten und besseren dieser Ersteinrei chungen gaben wohl der Tradition meiner bisherigen Anforderungen an Extended Abstracts folgend auch einige weitere Quellen an die sie in die Ausarbeitung ihrer Arbeit einbeziehen wollten Doch dies war nicht explizit gefordert es sollte allerdings f r k nftige Auflagen dieses Modells wie in der Ausgangsform dieser Veranstaltung praktiziert gefordert werden Mit dieser Ersteinreichung begann ein wesentlicher neuer Abschnitt der Lehrveranstaltung Ein erster Peer Review Jeder Einreichung wur
264. neering and Reuse Ronny Hand een Eine Einf hrung in Fuzzy Logik und seine geschichtliche Entwicklung Nina Margarita Winkler sun nen re ee Computing with Words verstehen Stefan Labitzke a ea EA A E EAE E R 17 25 32 39 47 Vorbemerkungen Roland Mittermeir Institut f r Informatik Systeme roland isys uni klu ac at Abstract Dieser Sammelband umfasst die Endausarbeitun gen des von mir im Sommersemester 2007 geleiteten Seminars aus Angewandter Informatik Es stand unter dem Motto TRACES Themes still Relevant At Current Software Engineering Studies Die im inhaltlichen Teil des Sammelbandes enthal tenen Arbeiten sind Bakkalaureatsarbeiten die von Studierenden im 6 Semester ihres Informatikstudiums anzufertigen sind Diese Vorbemerkungen sollen den die Organisationsform dieses Bakkalaureatsseminars und die Motivation f r das Rahmenthema erl utern 1 Hintergrund Das UG 02 sieht vor dass Bakkalaureatsarbeiten im Rahmen von Lehrveranstaltungen abgefasst wer den 1 Im Bakkalaureatsstudium Informatik sind demgem je eine Bakkalaureatsarbeit im Seminar aus Angewandte Informatik und eine im Softwareprakti kum anzufertigen Dabei hat dem Lehrveranstaltungs typ entsprechend die erste Arbeit theoretisch konzep tioneller Natur zu sein Sie wird in der Regel als Ein zelarbeit verfasst Die Praktikumsarbeit ist demgegen ber praktisch anwengungsbezogen und wird in der Regel in Kleingruppen als
265. nen Steps zu erm glichen k nnen Parameter bergeben Parallel TncludeSaturdayStayover Continue t Throw al Restart Complete CarAndHotelReservation A CarReservation V f p A N Av sReservat on u lt HertzReservation V HyattReservation A NotTightBudget Abbildung 1 Steps und Agenten in einem Reservierungsprozess Quelle Cass 00 Um die Funktionsweise von Little JIL m glichst einfach erkl ren zu k nnen dient Abbildung 1 Cass 00 Ein Step repr sentiert die bergabe eines Arbeitsschrittes mit allen zugeh rigen Attributen an einen Agenten Dem Agenten werden dabei auch Informationen und Ressourcen bermittelt z B die vom vorigen Agenten erstellten Dokumente Es m ssen aber auch alle T tigkeiten von dem der Arbeitsschritt des Agenten abh ngt zuvor erf llt worden sein F r die Flusskontrolle wird definiert ob dieser Step sequentiell parallel als Versuch oder alternativ ausgef hrt wird Nicht Bl tter k nnen in einen oder mehrere Unterschritte weitergef hrt werden wobei der Ausf hrungsbeginn vom Sequenzzeichen abh ngt Im obigen Beispiel ist das Ausf hren der Steps HotelReservation und CarReservation unabh ngig voneinander w hrend die Nachfolgeschritte von PlaneReservation auf Grund des Zeichens try in der Reihenfolge von links nach rechts ausgef hrt werden Es wurde ein Mechanismus Requisites eingef hrt der da
266. nen iterativen Charakter Seine gr ten Probleme liegen in der strikten Abgrenzung der einzelnen Phasen In nahezu allen Softwareprojekten kommt es zu unvorhersehba ren nderungen wodurch es zur Notwendigkeit kommt fr here Phasen abermals zu durchlaufen Das Modell geht jedoch von vollst ndigen Anforderungen aus und l sst lediglich kleine Iterationen zwischen benachbarten Phasen zu wodurch es beispielsweise keinen Weg vom Betrieb zur ck in die Entwicklungs phase gibt 4 6 Weiters fordert die dokumentenge triebene Vorgehensweise formale Dokumente am Ende jeder Phase Diese werden aber nicht bei allen Projekten ben tigt wodurch nur unn tiger Overhead entsteht 4 LOCS Lines of Code COTS Commercial off the Shelf CBSE Component Based Software Engineering 73 Spiralmodell Beim Spiralmodell handelt es sich um ein generisches Modell Es wurde 1988 von Barry Boehm beschrieben und entstand laut ihm tiber Jahre hinweg aufgrund diverser Verfeinerungen am Wasserfallmodell 10 Spiralf rmig durchlaufen die Prozessaktivit ten in mehreren Zyklen vier konkreter Quadranten Jeder Zyklus beginnt im ersten Quadranten wo Ziele Alternativen und Randbedin gungen ermittelt werden Das Spiralmodell ist ein risikogetriebenes Vorgehensmodell um Projektrisiken fr hzeitig erkennen zu k nnen und dem gr ten Risiko aus dem Weg zu gehen Risikoanalyse und Evaluie rung von Alternativen finden im zweiten Quadranten statt Danac
267. ng the silver bullet toward a brighter future for system development IEEE Computer 25 1 8 20 1992 6 David Harel From play in scenarios to code An achievable dream Lecture Notes in Computer Science 1783 22 2000 7 David Harel and Eran Gery Executable object modeling with statecharts Computer 30 7 31 42 1997 8 David Harel and Hillel Kugler Synthesizing state based object systems from LSC specifications Lecture Notes in Computer Science 2088 1 2001 9 David Harel Hillel Kugler and Rami Marelly The play in play out approach and tool Specifying and executing behavioral requirements 10 David Harel and Orna Kupferman On object systems and behavioral inheritance IEEE Trans Softw Eng 28 9 889 903 2002 11 Thomas Stahl and Markus V lter Modellgetriebene Softwareentwicklung Techniken Engineering Management dpunkt verlag 1 edition 2005 12 Thomas Stahl Markus V lter Sven Efftinge and Arno Haase Modellgetriebene Softwareentwicklung Techniken Engineering Management dpunkt verlag 2 edition 2007 Aspektorientierte Programmierung ein berblick Rudolf Granitzer 0160067 rudi edu uni klu ac at Abstract E W Dijkstra ver ffentlichte 1968 einen Artikel 3 worin er die Struktur des THE Multiprogramming Sys tems beschrieb Zum ersten Mal wurde dabei ein Be triebssystem mit einer Schichtarchitektur umgesetzt Dies erlaubte eine Trennung einzelner Betrieb
268. nhang auch von Middleware gesprochen da sie der Klebstoff zwischen den jeweiligen Komponenten ist Einer Marktanalyse von Gartner zufolge hatten An wendungsintegration und Middleware im Jahre 2005 ein Marktvolumen von 8 5 Mrd US Dollars 10 Em merich Aoyama und Sventek 16 m chten auf die weitreichenden Forschungsarbeiten hinweisen die zu dieser Gewichtigkeit gef hrt haben Dar ber hinaus geben sie auch einen detaillierten Einblick in die unter schiedlichen Technologien und deren Weiterentwick lung Komponentenmodelle sind f r sich genommen ein sehr komplexes Thema und tragen nicht unwesentlich zur Kapitalintensit t der Softwarekomponenten Technologie bei weshalb an dieser Stelle ein einf h render berblick ber drei der wichtigsten Komponen tenmodelle geboten wird CORBA CCM Die OMG Object Management Group gegr ndet 1989 hat sich zum Ziel gesetzt Interoperabilit t zwischen Objekten zu standardisieren CORBA Common Object Request Broker Architectu re ging aus dieser Vereinigung bestehend aus mehre ren hundert Mitgliedsfirmen hervor CORBA erm g licht auf verteilten Objekten Operationen auszuf hren ohne dass der Aufrufende wissen muss wo sich das Ob jekt befindet noch in welcher Programmiersprache es implementiert ist Nicht einmal das Betriebssystem und die spezifischen Kommunikationsprotokolle m ssen bekannt sein Wie bereits erw hnt beschr nkt sich CORBA auf Objekte weshalb die OMG seit der
269. nt receptions void Point setX int receptions void Point setY int after moves flag true 2 6 Aspect Weaving in AspectJ In AspectJ wird die Strategie gew hlt einen Com piler die Arbeit des Zusammenf gens des Aspekt und des Komponenten Codes erledigen zu lassen Der Com piler ndert nur jene Stellen des Programms an denen Advices Anwendung finden Advices werden als Stan dardmethoden in den Code eingef gt An jenen Stel len im Programm auf die Advices angewendet wer den werden statische Punkte eingef gt die den dyna mischen Join Points entsprechen In diese statischen Punkte wird Code zur Ausf hrung der Kontroll Advi ces eingef gt around advices 2 7 Sprachunabh ngige AOP Die Vorgehensweise Aspektorientierte Program mierung an eine bestimmte Programmiersprache zu binden nennen Lafferty und Cahill 6 Tyrannei Das Ziel von AOP sei es doch sich von den vorgegebenen Modularisierungskonzepten einer Programmiersprache zu l sen Die Aspektsprache an eine Programmierspra che zu binden widerstrebt diesem Ziel Lafferty und Cahill stellen in ihrem Artikel das Programmiermodell von Weave NET vor Weave NET unterst tzt Aspektorientierte Programmierung f r die Common Language Infrastructure CLI Implemen tierung Microsoft NET Dies erm glicht AOP f r al le Sprachen die von dieser CLI unterst tzt werden hnlich zu AspectJ unterst tzt auch Weave NET Join Points Pointcuts und A
270. nte e Reuse der bestehenden Funktionalit t durch eine Su perklasse und Hinzuf gen bzw berschreiben von Me thoden in einer Subklasse um die neue Funktionalit t zu gew hrleisten 67 e Reuse durch Modifikation der Funktionalit t einer Kom ponente Dabei wird die Idee der bestehenden Software Komponente bernommen und auf die neue Umge bung angepasst Dies ist die wahrscheinlich aufw nd igste Variante da Source Code f r die neue Umgebung wiederum neu implementiert werden muss Da wie bereits erw hnt bei diesem objekt orientierten An satz die Klasse im Mittelpunkt steht m ssen auch die Facet ten von Prieto Diaz und Freeman aus 11 modifiziert wer den 4 Karlsson et al definieren in dem Reuse System REBOOT das in 4 eingef hrt wurde und auf die Klassifizierung von objekt orientieren Software Komponenten setzt vier Facet ten wobei sich davon drei auf die Funktionalit ts Facetten und lediglich eine auf die Umgebungs Facetten aus dem An satz von Prieto Diaz und Freeman in 11 beziehen Die vier Facetten sind 4 e Abstraction Diese Facette wurde definiert da objekt orientierte Komponenten f r gew hnlich eine Abstraktion eines Objektes der realen Welt darstellen Die Objekte wer den mit einem speziellen Vokabular Name wie z B Stack Queue etc beschrieben welches auch f r die Klassifizierung der Software Komponente herangezo gen wird e Operations Objekt orientierte Komponenten biete
271. nten basierten Software Engineerings CBSE berzeugt we believe that CBSE represents the best practic es in software engineering produced during the last thirty years 14 CBSE befasst sich nach diesen Au toren haupts chlich mit drei Funktionen 1 Entwick lung von Software aus vorproduzierten Bauteilen 2 die F higkeit diese Komponenten in anderen Anwen dungen wiederzuverwenden und 3 mit der Wartung und Anpassung solcher Teile Ivica Crnkovic besch f tigt sich eingehend mit dem ersten der genannten Punk te und forscht nach spezifischen Prozessen f r Kompo nentenbasierte Softwareentwicklung 11 Er unter scheidet zwischen Entwicklung von Komponenten und Systementwicklung mit Komponenten Beide Varianten erfordern unterschiedliche Prozess und Lebenszyk lusmodelle welche aber durchaus auch nebeneinander ausgef hrt werden k nnten Werden Komponenten von third parties produziert ist dies auch die Regel Komponenten Entwicklungsprozess Die Entwick lung von Komponenten kann weitgehend mit den klas sischen Vorhergehensweisen stattfinden Besonderer Fokus ist jedoch auf die Komponenteneigenschaft der Wiederverwendbarkeit und damit auf Generalit t und Flexibilit t zu legen Daraus ergibt sich ein erh hter Aufwand f r Spezifikation und Test Die Komponente muss in Isolation wie auch mit verschiedenen Konfigu rationen und an unterschiedlichen Umgebungen getes tet werden 12 Wie in Kapitel 2 deutl
272. nter der Standardisierung von Prozessen sind einheitliche und kontrollierbare Abl ufe Was muss im Falle einer Krise getan werden Wer muss informiert werden Welche Dokumente m ssen dabei erzeugt werden Welche Workflows m ssen angesto en werden Es gibt zwei Arten von Audits interne und externe Interne Audits werden benutzt um Probleme im internen Prozessablauf zu finden und zu optimieren Externe Audits werden in der Regel von einem unabh ngigen Personenkreis meist von akkreditierten Unternehmen durchgef hrt F r eine ISO Zertifizierung m ssen beide Arten des Audits in regelm igen Abst nden durchgef hrt werden 2 5 Inspektion in Aktion Zehn Jahre nach der Ver ffentlichung seines ersten Artikels hat Fagan die nachfolgende Grafik Abbildung 4 vorgestellt 4 Sie beschreibt die Projektdauer einer durchschnittlichen Softwareentwicklung mit und ohne Inspektionen Das Ergebnis zeigt dass bei Projekten mit Inspektionen Verk rzungen der Projektlaufzeit und Einsparungen bei Mitarbeiterressourcen m glich sind Den Mehraufwand f r Inspektionen die zirka 15 des Gesamtbudgets ausmachen mit eingerechnet Inspektionen senken nicht nur die Kosten Sie erh hen auch die Qualit t der Software Im Vergleich zu hnlichen Projekten konnten bei IBM und AETNA Versicherungen 93 respektive 82 aller Fehler durch professionelle Inspektionen im Life Cycle erkannt und fr hzeitig eliminiert werden Zudem kamen noch Einsparungen von ge
273. o focus on a historical perspective Since UNIX was very unique at the time it was developed it also introduced quite a lot of new programming paradigms and ideas Some of these ideas like component based development or the pipes and filters architecture are discussed in chapter 3 Additionally to mentioning them and comparing how they deduce from the functionalities described in chapter 2 their use in today s world is shortly examined Finally chapter 4 summarizes the most important facts to show how the development of UNIX has influenced the way we produce and think of software today 2 Milestones of UNIX Development for UNIX began in 1969 at the AT amp T Bell Laboratories It was designed as designated successor for the Multics operating system which was also invented at Bell Labs but proved to be a failure due to various reasons UNIX was supposed to eliminate the immanent problems while some new and interesting features should be added as well Development was slow at the beginning since the decision makers at Bell Labs did not want to risk another loss of money like it had happened in the development of the Multics system In 1974 the first paper describing UNIX appeared 3 From this time on UNIX got widely accepted at AT amp T Bell Laboratories and development for it caught on leading to some quite revolutionary concepts being integrated It is important to note that the ideas for these concepts where not entirely new Th
274. o head to head crossings producing interwoven program blocks without a clear structure Second the label a goto is going to jump to has to be located in the same sub program i e in the same procedure or function do not use long jumps to exit procedures The third and last rule demands that every jump has to be forward directed that means the corresponding goto s have to appear before the labels that they jump to This definitely excludes loop constructs with goto s as well as the continue command for controlling loops The three simple rules provide a way to use goto statements in a good way They ensure a program to be split up in building blocks that can be understood and handled easily thus providing a good program structure 5 Conclusion The discussion about use and abuse of the goto command is very old and had a lot of impacts on how programs are written nowadays A very big research area was coupled to the goto elimination which still is interesting for reverse engineering of legacy applications Nevertheless goto s are present in a number of today s programs like the GNU Linux kernel and are accepted as a programming construct Another impact of the afore mentioned discussion was the development of languages without explicit goto statements but with a few other unconditional branching constructs break continue case To use goto statements in a sensitive way it is necessary to limit unconditional branching to a few c
275. obaler definiert wurden e _Unn tige arithmetische Funktionen Addition Subtraktion oder Division mit Null e _Unperformanter Code manuelles Kopieren von Arrays oder wenn Strings in Schleifen zusammengebaut werden e Namenskonventionen Gro schreibung bei Konstanten String Variablen die integer hei en Zus tzlich zur live Pr fung Tool Tips stellt die Inspektion des Codes im Beispiel von Abbildung 5 fest dass die Variable i von der Funktion calc immer 10 betr gt die Methoden calc und run auch private sein k nnen und die Methode run nie aufgerufen wird 92 public static void main String args calc 10 public static int calclint i if i 10 return calc 10 else return 0 System out println I am not reachable public int runi Method run recurses infinitely and can only end by throwing an exception return run Abbildung 5 Gepriifter IDEA Code Das abgebildete Programmbeispiel enth lt aber einen schweren Fehler die Methode calc 10 in main wird sich immer wieder selbst aufrufen bis zum Programmabsturz IDEA konnte diesen Zyklus nicht entdecken Ein weiterer Punkt in IDEA ist Safe delete M chte der Programmierer Methoden oder Klassen l schen so pr ft die IDE alle im Projekt enthaltenen Klassen auf Abh ngigkeiten Wird die zu l schende Methode oder Klasse anderswo verwendet so wird eine dementsprechende Liste ausgegeben
276. oder Activity angef hrt Dar ber hinaus bieten solche Mo delle Abstraktionsmechanismen um Informa tionen auch organisieren zu k nnen 3 Bis heute werden konzeptuelle Modelle verwen det um Anforderungen zu modellieren Nur die Ans tze haben sich auch hier im Laufe der Zeit ver ndert Mitte der 80er mit dem Aufkommen objektorientierter Programmiersprachen begann man auch objektorientierte Modellierungstechni ken anzuwenden die Eigenschaften aus eben der objektorientierten Programmierung aus semanti 97 schen Datenmodellen und aus Anforderungsspra chen mit sich brachten 2 3 Die Rolle der K nstlichen Intelligenz Wissensrepr sentation hat ihren Ursprung im Bereich der K nstlichen Intelligenz wo ein zentrales Thema darin besteht gen gend Wissen anzusammeln um u a menschliches Verhalten simulieren zu k nnen Daher dient dieser Bereich als Quelle von Ideen und Techni ken um Wissen zu repr sentieren und somit die Ent wicklungen in anderen Bereichen der Informatik zu verbessern Solche Techniken k nnen neue Ans tze liefern um z B Wissen anzusammeln formal festzu halten organisieren und abzurufen 2 Nat rlich k nnen diese Methoden nicht einfach ber nommen werden sondern m ssen f r jeden Bereich adaptiert werden Im Speziellen liegt der Einfluss der K nstlichen Intel ligenz in den Bereichen neuer Konzepte Ontologien um das Wis sen zu repr sentieren neuer Notationen Sprache
277. of a cleanup stack with goto s Another usage for goto s is the termination of multiple nested loops where a single break command is not sufficient The main idea is to exit both loops without adding more complexity to the termination rules of the loops Check several conditions and in case of an exception call the exception handler if class ATA DEV ATA if ata id is ata id amp amp ata id is cfa id goto err _out else if ata id is ata id goto err_out Default exit no error occured p class class return 0 Exception handler err_out if ata_msg warn ap ata_dev_printk dev KERN WARNING failed to IDENTIFY s err_mask 0x x n reason err_mask return rc Illustration 2 Example of an exception handler There are a few other usages of goto s in the Linux kernel like rather nasty backward jumps that are discouraged as we will see later Overall it can be said that the emphasis of the usage of goto s is rather concentrated on issues of the program s structure than it is on performance This conclusion is assisted by the fact that the amount of goto s in the Linux kernel 21 Goto s LOC increased steadily with the increasing of the size have a look at diagram 1 3 1 2 The GNU C compiler collection The second free available and very big software project I am going to look at is the GNU C compiler collection gcc The compiler is available at 24 and I examined
278. ogrammierung und die Arbeits weise eines aspektorientierten Frameworks verst ndlich zu machen In Tabelle 1 sind die dynamischen Join Points auf gelistet die AspectJ zur Verf gung stellt Tabelle 1 Dynamische Join Points in AspectJ 4 kind of join point points in the program execution at which method call a method or a constructor of a class is called Call join points are in the calling object or in no object if the call is from a static method constructor call method call reception an object receives a method or constructor call Reception join points are before method or construct or dispatch i e they happen inside the called object at a point in the control flow after control has been transferred to the called object but before any particular method constructor has been called constructor call re ception method execution an individual method or constructor execution constructor is invoked field get a field of an object class or interface is read field set a field of an object or class is set exception handler exe an exception handler is cution invoked static initializers for a class if any are run class initialization object initialization when the dynamic initial izers for a class if any are run during object creation Im Folgenden wird die Aspektorientierte Program mierung anhand des Beispiels im Artik
279. ograms requirements Secondly humans are more accustomed to understanding static contexts rather then dynamic process situations Therefore it is beneficial to correlate the program structure the code and the dynamical process the program being executed as much as possible This correlation can be expressed in using coordinates to describe the current state of the running program This aids in the determination of the value of a variable at any given program state Thus making it clearer how the running program will behave when looking at the source code There are several programming building blocks that have to be considered when setting up a system of coordinates to describe a running program First there is the simple sequence of commands Here it is enough to have a program counter to get hold on to the actual program state Another building block are decision taking constructs e g if case which also just require a program counter to be described In contrary it is more complex to describe a program state when procedures are included Say there needs to be a counter for the position in the caller procedure and an additional counter for capturing the position inside the called procedure This may result in an array of counters dependent on the procedure calling stack The very moment we introduce repetition constructs e g for while we have to introduce additional counters to keep track of the count of repetitions Wit
280. olche Befehle erlaubt sein die eine derartige Zuordnung zu lassen wie auch immer sie benannt sind 05 4 4 Ausbildung J F Schrage hat schon 1980 in 08 beschrieben dass Studenten mit Grundlagen in strukturierter Pro grammierung bei Wartungsarbeiten wesentlich besser arbeiten als welche ohne diesen Hintergrund Dies best tigt wie wichtig es ist beginnenden Pro grammierern die Bedeutung dieser Thematik n her zu bringen ihnen zu vermitteln welche Vorz ge gut strukturierte Programme mit sich bringen Beginnen muss dies damit die Auszubildenden programming und nicht coding zu lehren 01 Hier ist jedoch wesentlich vor allem Neulingen die Bedeutung strukturierter und die Probleme nicht struk turierter Programmierung aufzuzeigen um ein grundle gendes Verst ndnis daf r aufzubauen Des Weiteren ist es auch sinnvoll goto Statements bzw dessen Ab wandlungen nicht einfach zu verbieten sondern bei zubringen wie und wann man welche Konstrukte sinn voll einsetzen kann und darf 08 4 5 Beispiel SFC Editor Im Folgenden m chte ich ein Beispiel f r ein Werk zeug darstellen welches die Relevanz der Thematik bis in die heutige Zeit belegt Der aus dem Jahr 2004 stam mende Artikel 10 von T Watts beschreibt einen grafischen Editor welcher aus den zu Beginn beschrie benen Building Blocks komplexe Flussdiagramme erzeugen l sst Die so dargestellten Programme sind nach dem hier dargestell
281. on funktionalen Kom ponenten sollten auch Aspekte voneinander getrennt werden Sp ter in der Implementierungsphase werden dann Aspekte und funktionale Komponenten wieder zu sammengef gt um ein Softwaresystem zu bilden Au erdem helfen Aspekte dabei den Quellcode Umfang klein zu halten wodurch die Wartbarkeit von Software erh ht wird Gregor Kiczales et al 5 stellten das Paradig ma der Aspektorientierten Programmierung vor An hand kurzer Ausschnitte eines LISP Programmes wur de gezeigt wie sehr die Umsetzung von Cross Cutting Concerns in den Quellcode verwoben ist Komponen ten behandeln Cross Cutting Concerns oft unterschied lich Wodurch Aufbl hung des Quellcodes verursacht wird Das Beispiel das in 5 angef hrt wird stammt aus einer Komponente einer realen Anwendung zur Schrifterkennung Die Komponente besteht aus einfa chen Funktionen zur pixelweisen Manipulation von Bil dern Die Implementierung von performanzsteigernden Eigenschaften verursachte bei diesem System einen im mensen Anstieg der Komplexit t Ihe clean implementation of the real system is only 768 lines of code but the tangled implementation which does the fusi on optimization as well as memoization sic of intermediate results compile time memory allocation and specialized intermediate data structures is 35213 lines 5 Die Implementierung einer Anwendung mit Aspektorientierter Programmierung erfordert eine Komponenten
282. onders zum Erstellen von Alternativen e Nebenlaufige und r ckwirkende Kontrolle e Prozesszugeh rige Daten M glichkeit Daten die im Laufe des Prozesses erstellt oder erhalten werden unterst tzt in den Prozess einflie en zu lassen e Management f r flexible Transaktionen um Daten und Ressourcen zwischen den einzelnen Benutzern zu verteilen ohne Inkonsistenzen zu verursachen Dazu mussten der Sprache Ada vier wichtige Erweiterungen hinzugef gt werden Die erste betrifft Relation Units die wie eine mathematische Notation die Darstellung der Beziehung zwischen den einzelnen Einheiten im Softwareentwicklungsprozess darstellen Man ben tigte hier auch eine allgemein g ltige aber flexible Datenstruktur um die anfallenden Produkte und Daten darstellen und speichern zu k nnen Nachdem auf Daten nicht nur von einer Stelle aus zugegriffen werden soll muss sichergestellt werden dass die Daten persistent bleiben Als n chstes wurden Trigger units eingef hrt Trigger units sind Kontrolleinheiten die auf Ereignisse die die Relation units betreffen reagieren und bei gleichzeitigem Zugriff auf Eintr ge auch diese Nebenl ufigkeit kontrollieren Trigger units sorgen ebenfalls daf r dass Nachrichten von einer Einheit zur anderen transportiert werden wenn sich bei relevanten Daten etwas ndert Weiters sind sie f r Berechnungen f r das F hren der Protokolle generell f r s mtliche Aktionen die die Relat
283. ons Schema eine Software Komponente passend klassifiziert 4 2 Thesaurus Die Beschreibung von Software Komponenten im Faceted Classification Scheme ist nicht problemfrei da bei der Be schreibung einer Komponente mehrere Synonyme f r die sel bige entstehen k nnen Man denke zum Beispiel an die Be schreibung der Funktionalit t einer Software Komponente dabei k nnte diese in Form von lt move words file gt oder lt transfer names file gt beschrieben werden Dabei entste hen mehrere Beschreibungen f r die selbe Komponente 11 Um diese Probleme zu beseitigen ist eine Vokabular Kont rolle der Thesaurus entstanden Dieser gruppiert alle Syn onyme einer Facette unter einem eindeutigen aussagekr ft igen Begriff Dabei wird der Begriff der die Facette f r die betroffene Software Komponente am besten beschreibt ver wendet z B add increment total sum 6 11 Der Thesaurus kann auch die Anzahl der Suchergebnisse be einflussen einerseits k nnen viele verschiedene Begriffe zu wenigen Gruppen zusammengefasst werden mehr Ergeb nisse andererseits ist es auch m glich diese Gruppen zu spezialisieren weniger Ergebnisse 11 4 3 Distanz Modell Auch das Distanz Modell stellt ein wichtiges Feature im facetten orientierten Klassifikations Schema dar Dabei han delt es sich um die semantische Distanz zwischen zwei Be griffen einer Facette oo 10 100 400 wo s ee l a moving somet
284. ore constrained than goto because it can only jump to the end ofa loop and nowhere else Pseudo code PGLE 0 statement1 conditionl 1 condition2 0 1 Ie r Table 2 A break construct in PGLE do statement if condition break while condition2 exit The continue command is almost identical to a break command with the only difference that the program flow branches to the start of the actual loop table 3 Pseudo code PGLE do 0 statement statement1 if condition1 continue conditionl 0 statement2 statement2 While condition2 condition2 0 exit I Table 3 A continue command in PGLE A different command is the case construct which can be translated into a multi level branching structure and can then be reduced to a goto based form table 4 Pseudo code PGLE select var case a var a statement1 break statement1 0 case b var b statement2 break statement2 0 lend select 0 exit be Table 4 A select case structure in PGLE It is also not too difficult to derive a PGLE representation of a try and catch block This might be done with a label followed by the catch block and a condition for every line in the try block to check whether an exception has occurred or not It is evident that there exists a simple transformation of loop constructs to constructs goto with goto s and labels The above
285. orientierten Klassifizierungs Schema auf baut beleuchtet In Kapitel 5 werden anschlie end Ans tze und moderne Tech nologien beschrieben die auf der Arbeit von Prieto Diaz und Freeman aufbauen Dabei werden verschiedene Klassifi zierungs Schemata beschrieben und zu dem facetten orien tierten Ansatz in Relation gesetzt Ebenso wird Behavi or Sampling eine weitere Wiederauffindungs Methode f r Software Komponenten diskutiert 2 SOFTWARE REUSE Software Reuse ist die Wiederverwendung von bereits exis tierenden Software Komponenten bzw Konzepten in neuen Situationen Anwendungsproblemen und Systemen 11 Warum und wie diese Wiederverwendung durchgef hrt wer den soll wird im Folgenden erkl rt und diskutiert 2 1 Warum Software Reuse In vielen Disziplinen ist die Wiederverwendung von Wissen und bestehenden Komponenten eine Selbstverst ndlichkeit man denke zum Beispiel an die Produktion eines Autos In der Informatik ist dies jedoch anders mit jedem Software Projekt werden bestehende Ideen und Realisierungen neu umgesetzt 2 p 1 Jedoch bringt Software Reuse viele Vor teile mit sich 2 p 1 e Produktivit t Eine Software Komponente soll dann wiederverwendet werden wenn der Aufwand im Vergleich zu einer Neu entwicklung geringer wird Ist dies der Fall steigt da mit gleichzeitig die Produktivit t und Effizienz e Qualit t und Zuverl ssigkeit Durch die mehrmalige Wiederverwendung einer Soft ware Ko
286. orm der Funktion liegt ebenso in der Verantwortung des Entwicklers Meist werden jedoch simple Zugeh rigkeitsfunktionen gew hlt wie beispielsweise die Dreiecks oder Trapezfunktion oder auch die Gau sche Glockenkurve Weitere Informationen ber Zugeh rigkeitsfunktionen und das Aufstellen der Datenbasis kann man in 1 2 6 und 7 finden Beispiel Erstellen der Datenbasis Als Eingangswerte erhalte ich die Gr en Temperatur und Personenanzahl und weiters ist der Ausgangswert die Stellung des Ventils zur K hlung Mit diesem Wissen kann ich die linguistischen Variablen inklusive deren Werten wie folgt w hlen Temperatur kalt angenehm hei Personen wenig mittel viele Ventil zu wenig offen viel offen offen Deren Zugeh rigkeitsfunktionen bestimme ich wie in den n chsten Abbildungen dargestellt hei kalt angenehm Temperatur 18 19 20 21 22 23 24 25 26 27 Abbildung 4 Zugeh rigkeitsfunktion linguistischen Variable Temperatur der 1 wenig mittel viele 2 3 v oa 0 2 4 6 8 10 12 14 16 18 20 Abbildung 5 Zugeh rigkeitsfunktion der linguistischen Variable Personen zu wenig offen viel offen offen 10 20 30 40 50 60 70 80 90 100 Abbildung 6 Zugeh rigkeitsfunktion linguistischen Variable Ventil der Aufstellen der Wissensbasis Regelbasis Nach der Bestimmung der linguistischen Variablen deren Werte und deren Zugeh rigkeitsfunktionen werden nun die Regeln
287. ormation Test criteria Interfaces Test methods Configuration and composition Test cases Constraints Test environment Functionality Test summary Quality attributes Test support Support information Installation guide Customer support Tailoring support Detailed Information Technical details Restrictions Implementation Delivery Abb 1 Komponenten Dokumentationsmuster vgl 29 Komponenten werden bevor sie in ein System integ riert werden ausf hrlich getestet Dieser Aufwand kann durch eine strukturierte Dokumentation minimiert werden vor allem wenn der Lieferant der Komponente testspezifische Informationen beistellt F r eine genaue Beschreibung einzelner Punkte des Dokumentations musters sei auf 29 verwiesen Qualit tsmerkmale Eine gut abgestimmte Dokumen tation ist eine qualit tsf rdernde Eigenschaft f r Kom ponenten Qualit t ist eine wesentliche Triebfeder f r den Erfolg von Softwarekomponenten Da die Qualit t eines Systems von der Qualit t des schw chsten Glie des abh ngig ist wird ein hoher Qualit tsstandard f r Komponenten gefordert Mehrere Forschungsgruppen haben sich deshalb Gedanken dar ber gemacht wie Qualit tskriterien aussehen k nnten und wie diese be wertet werden m ssten Bertoa und Vallecillo 4 ha ben auf Basis des generellen Software Qualit tsmodells ISO 9126 ein Qualit tsmodell speziell f r COTS Komponenten entworfen
288. ort unter dem Begriff Sequenzdiagramme zu finden Se quenzdiagramme in UML besitzen allerdings eine schw che re Ausdruckskraft als MSCs Obwohl MSCs heute weit verbreitet sind wurden einige fun damentale Punkte in ihrer Spezifikation nicht behandelt Als Beschreibungssprache f r Anforderungen sind alle bekann ten Versionen von MSCs zu schwach in ihrer Aussagekraft Diese Sprache gen gt nicht um Aussagen ber das Lauf zeitverhalten zu treffen und zwischen zwingend notwendi gen und optionalen Ereignissen zu unterscheiden Ein weite res K O Kriterium ist dass es nicht m glich ist ungewollte Szenarien zu beschreiben Gerade f r reaktive Systeme spe ziell solche die in sicherheitskritischen Bereichen eingesetzt werden sind solche Anforderungen essentiell In dem Paper LSCs Breathing Life into Message Sequence Charts wurden diese Probleme behandelt und eine Erwei terung mit dem Namen Live Sequence Charts LSCs vor geschlagen Wie der Name schon sagt geht es bei LSCs um liveness Dies dr ckt aus dass erw nschtes Verhalten wie z B das Terminieren des Programmes eintreten muss Der Modellierer kann zwischen m glichem und erforder lichem Verhalten unterscheiden global auf der Ebene des ganzen Diagramms oder lokal wenn Events oder Bedin gungen spezifiziert werden bzw in zeitlichen Abschnitten des Diagramms Die als lebendig bzw hei live or hot be zeichneten Elemente erm glichen es An
289. orteile und auch die Nachteile die aus einer Anwen dung erwachsen k nnen gegen bergestellt Es ist je doch rasch zu bemerken dass hier die Vorteile wohl berhand nehmen 3 1 Vorteile 3 1 1 Top Down Entwicklung Durch diese Art der Softwareentwicklung k nnen diverse Vorz ge er reicht werden Zum Ersten bietet sich die M glichkeit die Wartbarkeit des Endproduktes zu erh hen Einer seits sind alle eingearbeiteten Designentscheidungen automatisch dokumentiert und andererseits k nnen Nebeneffekte bei nderungen bereits im Vorfeld er kannt oder grunds tzlich vermieden werden Zum Zweiten wird wie bereits weiter oben n her erl utert der entstandene Code automatisch modularisiert was neben einer besseren Lesbarkeit und Wartbarkeit auch die erh hte M glichkeit zur Wiederverwendung mit sich bringt Beide Punkte bieten einem Team von Entwicklern vor allem eines n mlich eine erhebliche Zeitersparnis Sei es durch die bereits modularisierten Bibliotheken oder durch die parallel erarbeitete Beweisf hrung f r die Funktion oder auch durch den wesentlich verrin gerten Aufwand der Fehlerbehebung 3 1 2 Weniger Fehler Durch die angewendete Me thode der iterativen Verfeinerung werden von vornher ein weniger Fehler produziert und in das System einge schleust Dies ist dadurch erkl rbar dass man sich bei den einzelnen Schritten auf eine beschr nkte Aufgabe konzentrieren kann und nicht das Konzept des ganzen Systems
290. ortschritte Mitarbeitern oder Managern zu pr sentieren Ebenso k nnen Walkthroughs als Mitarbeitertraining benutzt werden Obwohl auch hier Fehler gefunden werden k nnen ist dies nicht der prim re Fokus Walkthrough Sitzungen k nnen durchaus zwanzig oder mehr Personen umfassen Diskussionen sind hier im Gegensatz zur Vorgehensweise bei Inspektionen erw nscht Die Rolle des Pr sentators kann gleichzeitig der Autor des Dokuments sein der bestimmt welche Teile 90 seiner Arbeit er zeigen m chte Weitere Rollen sind nicht definiert Walkthroughs k nnen in unregelm igen Abst nden stattfinden Durch ihren informellen Charakter k nnen sie leichter organisiert beziehungsweise abgehalten werden Inspektionen neigen hingegen dazu seltener durchgef hrt zu werden Die Administration f r ein Inspektionsmeeting ist aufwendig und muss auf die einzelnen Mitglieder abgestimmt werden Eine weitere Form des Reviews ist das Audit Bei einem Audit stehen die Einhaltung der verwendeten Prozesse und deren G te im Vordergrund Nicht die Implementierung an sich Organisationen die solche standardisierten Prozesse verwenden k nnen sich dementsprechend zertifizieren lassen F r den Einsatz von Qualit tsmanagement gibt es unter anderen die ISO 9001 Zertifizierung Diese gibt allerdings keine Auskunft ber die Qualit t eines Produkts sondern nur dass bestimmte Abl ufe w hrend der Qualit tssicherung eingehalten werden Der Sinn hi
291. oub S Addy E Mili H Toward an Engineering Discipline of Software Reuse IEEE Software vol 16 no 5 pp 22 31 Sept Oct 1999 14 Parnas D L On the Design and Development of Program Families IEEE Transactions on Software Engineering Vol SE 2 No 1 pp 1 9 Marz 1976 15 Northrop L M SEI s Software Product Line Tenets IEEE Software IEEE Software vol 19 no 4 pp 32 40 Jul Aug 2002 16 Diaz Herrera J L Domain Engineering World Scientific 2000 17 http www sei cmu edu productlines framework html Letzter Zugriff 12 07 2007 18 Tolvanen J Pi Modellierungssprachen fiir ObjectSpektrum August September 2001 Dom nenspezifische Produktfamilien 110 19 Kr ger C W Software Reuse ACM Computing Surveys 24 2 pp 131 183 June 1992 20 Kurtev I Bezivin J Jouault F Valduriez P Model based DSL Frameworks In Companion To the 21st ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications Portland Oregon USA October 22 26 2006 OOPSLA 06 ACM Press New York NY 21 Mernik M Heering J Sloane A M When and how to develop domain specific languages CWI Centrum voor Wiskunde en Informatica Report SEN E0309 December 2003 22 Deursen A Klint P Visser J Domain specific languages an annotated bibliography ACM SIGPLAN Notices Volume 35 Issue 6 June 2000 23 Tolvanen J P Sprinkle J Gray J The 6th OOPSLA Work
292. paper Fuzzy Logic Computing with Words von L A Zadeh behandelt die Zusammen h nge zwischen Computing with Words und der Fuzzy Logik Dabei wird auf die wesentlichen Vorteile von Computing with Words eingegangen Der vorliegende Artikel befasst sich einleitend mit den Wurzeln von Fuzzy Logik Das zu bearbeitende Paper ist 1996 also in der Aufschwungszeit von Fuzzy Logik entstanden Daher stellt es eine Schnittstelle zwischen der Theorie von Fuzzy Logik und dem Ein satz dieser Methode dar Nachdem also der Basisartikel in den Grundz gen n her gebracht wurde werden die Einsatzgebiete in den unterschiedlichen Bereichen die Pr missen sowie wichtige Werkzeuge zur Anwendung von Fuzzy Logik erl utert 1 Einleitung Fuzzy Logik wird oft f lschlicherweise als eine un scharfe bzw verschwommene Theorie verstanden Vielmehr erlaubt sie es der strikten Bool schen Logik Zwischenwerte einzuf gen Damit kann das menschli che Denken besser abgebildet werden Die Fuzzy Logik bildet den Grundstein f r Computing with Words Es werden hierbei die Grundmechanismen be reitgestellt welche f r Computing with Words ben tigt werden Normalerweise versteht man unter Computation die Verwendung und Manipulation von Zahlen und Sym bolen Im Gegensatz dazu verwenden Menschen bei Berechnungen und Schlussfolgerungen W rter welche logischerweise aufgrund von unterschiedlichen Ausle gungen dazu neigen unpr zise also fuzzy zu sein Man
293. piler which enables the removal of goto s via a simple command switch 4 As we can see the discussion whether goto s are a good way of doing things or maybe dangerous for a program s structure have had an impact on the way things are done a long time ago but are still a matter of present research Therefore I would like to outline a few more impacts of goto s in the next chapter of my paper 3 Goto s in present times In today s education system goto s are affected with a sense of dirtiness More particularly the whole goto discussion lead to the establishment of a taboo 13 A decade after the Dijkstra s letter 1 the use of goto s was evermore unwanted and the designer of programing languages backed away of including 20 unconditional jumps and labels in their new languages Nevertheless the act of goto avoidance was the corner stone of the development of today s more sophisticated programming structures A negative effect of the abolishment of goto s is that the technology of writing code with explicit flow of control is deemed to die This leads also to the problem that low level programming assembler hex coding is no longer understood nor taught anymore As a result it is harder for today s programmer to write efficient programs because the low level knowledge of the program flow near the hardware gets lost In contrary this argument is moderated by the fact that modern compilers became better in optimizing code th
294. plexit t der Entwicklung zu unterst tzen Folgend eine kurze Auflistung einiger Standards und Tools Die Object Management Group OMG ein Konsortium aus verschiedenen Organisationen verantwortlich f r mehrere standardisierte Spezifikationen wie CORBA und UML hat im Bereich MDD die Model Driven Architecture spezifiziert 24 Microsoft Factory Ansatz versucht eine Plattform zu entwickeln in dem eigene DSLs mit Hilfe von Templates definiert werden k nnen 25 Eclipse eine offene Entwicklungsplattform verfolgt das Modeling Projekt das auf bestehende Eclipse Frameworks wie Eclipse Modeling Framework EMF und Graphical Modeling Framework GMF aufbaut 26 109 MetaEdit von dem Unternehmen Metacase ist ein ausgereiftes Produkt f r DSM Unternehmen wie Nokia und EADS haben das Produkt schon erfolgreich eingesetzt 27 6 Zusammenfassung Ausgehend vom Artikel von Arango von 1989 waren die Konzepte von Domain Engineering im Zusammenhang mit Wiederverwendung in der Softwareentwicklung noch sehr jung wurden aber zur Basis f r die weiterf hrende Verfeinerung Weiterentwicklungen gab es in Richtung Software Produktlinien wo Domain Engineering im Umfeld eines Unternehmens betrieben wird und unternehmensweite Strategien entwickelt wurden Code ist dabei f r die Wiederverwendung nur ein m glicher Artefakte Bei dom nenspezifischer Modellierung wird das Wissen in Form von Modellen wieder verwendet aus denen dann fe
295. ponent view import STRING import complexity import STRING import INT import REAL as name as space as author asloc as error density kind operation is _ view import STRING graphics collection Import complexity type im as time as name is Br is queue tree constructor iterator modifier stack list Tr selector test destructor is binary a b Tre n ary active passive Abbildung 2 Feature orientiertes Klassifizierungs Schema Quelle 1 Wie in Abbildung 2 ersichtlich ist werden die Eigenschaften in Form eines feature orientierten Klassifikations Schemas organisiert und durch st ndige Weiterzerlegung klassifiziert Durch diese Weiterzerlegung entsteht ein Baum bei dem ein Feature durch einen Pfad beschrieben werden kann 1 FOCS Feature Oriented Classification System 68 In dem Schema von B rstler in 1 werden zwei Relationen f r die Weiterzerlegung der Eigenschaften in diesem Baum unterst tzt 1 e View Refinement Diese Art von Refinement zerlegt ein Feature in klar erkennbare und unterscheidbare Aspekte In dem Sche ma aus Abbildung 2 kann eine Komponente durch die folgenden Eigenschaften klassifiziert werden Name na me Art der Komponente kind Platz Anforderungen space Autoren author Operationen operations Gr e in Lines of Code loc und Fehlerdichte error density e Is Refinement Diese Weiterzerlegung wird fiir die Spezialisierun
296. poten tial Doch selbst in sehr guten Arbeiten werden noch einige Fl chtigkeitsfehler st rend wirken Zwischen der Rolle eines Editors dieser Sammlung und der eines Pr fers schwankend entschloss ich mich schlie lich f r letztere und bernahm die Endfassun gen der abgegebenen Arbeiten ohne jeglichen edi toriellen Eingriff Schlie lich sind es Pr fungsarbeiten und als solche halt noch mit Schw chen unterschied lichen Ausma es behaftet In den folgenden Abschnitten dieses Vorwortes wird die Organisationsform des Bakkalaureatsseminars beschrieben und der Hintergrund des Rahmenthemas TRACES Themes still Relevant At Current Software Engineering Studies erl utert Das Vorwort schlie t mit einigen didaktischen Reflexionen 2 Organisationsform des Seminars Das Seminar wurde einem inzwischen bereits zur Tradition gewordenen Stil des Seminarleiters entspre chend als Variation eines Konferenzseminars abgehal ten In der Grundform dieser Seminarform w hlen die Studierenden innerhalb eines Rahmenthemas selbst n dig ein Thema samt zugeh riger Literatur Hier war durch die Vorgabe von Literatur die f r weitere Ent wicklungen richtungweisend war zwar eine Menge von klaren Startpunkten definiert aber mit ber 40 Arbeiten f r etwa 20 erwartete Interessenten umfasste die Ausgangsmenge doch ein deutliches berangebot Daher sollten wenigstens fr h Entschlossene ein den pers nlichen Interessen nahe liegendes Thema fi
297. r den moderne Ans tze wie Behavior Sampling und objekt orientierte feature orientierte und semantik basierte Klas sifizierung behandelt die das Thema weiterf hren 1 EINLEITUNG UND MOTIVATION Reuse is the use of previously acquired concepts and ob jects in a new situation 11 Diese Definition von Software Reuse wurde von Prieto Diaz und Freeman in 11 aufgestellt und zeigt die M chtigkeit der Wiederverwendung bestehen der Software Komponenten diese k nnen zur L sung neuer Teil Probleme eingesetzt werden ohne die ben tigte Funk tionalit t erneut zu implementieren Software Reuse bringt viele Vorteile wie Produktivit ts und Qualit tssteigerung und leichtere Erweiterbarkeit von Systemen mit sich Je doch kommen diese Vorteile lediglich bei spezieller Organi sation der Software Bibliothek welche die bereits existieren den Software Komponenten beinhaltet zu tragen Diese Organisation ist ein herausforderndes Problem das in den letzten Jahrzehnten in zahlreichen Artikeln und Publi kationen diskutiert wurde Das Hauptproblem stellt dabei die Klassifizierung also das wohldefinierte Einordnen exis tierender Software Komponenten in die Software Collection dar Aufgrund dieses Klassifizierungs Problems wird die Wie derauffindung von Komponenten erschwert Prieto Diaz und Freeman haben in 11 ein Reuse Modell entwickelt welches die oben beschriebenen Probleme erfasst 63 und zu l sen versucht Aus diesem
298. r Vortr ge wiedergegebenen Arbeiten sind die Ergebnisse dieser berarbeitung Alle f nf zehn Vortragenden haben einige mussten wohl von der M glichkeit einer berarbeitung Gebrauch ge macht Als wesentliches Zusatz Feature dieses Seminars ist noch die Kooperation mit dem SchreibCenter der Universit t Klagenfurt zu nennen Die Seminarteil nehmer hatten die M glichkeit Teile ihrer Arbeit von Mitarbeiterinnen des SchreibCenters auf sprachliche Verbesserungsm glichkeiten pr fen zu lassen Einige haben diese M glichkeit schon vor Abgabe der Erst fassung dieser Arbeit in Anspruch genommen Andere 3 http www uni klu ac at uniklu org oe jsp orgkey 706 bekamen die Konsultierung des SprachCenters im Rahmen des Begutachtungsprozesses empfohlen 3 Motivation des Inhalts F r Lehrende stellt sich das didaktische Problem der Generation der jetzt etwa Zwanzigj hrigen jene Konzepte der Informatik n her zu bringen die aus einer Laptop und Java Perspektive als im doppelten Sinn des Wortes berkommen erscheinen m ssen auch wenn diese Arbeiten auf der Basis einer breiteren Per spektive als grundlegend einzustufen sind Es stellte sich daher f r mich die Frage ob und wie weit Studierende in der Lage sind aus eigener Ein sch tzung aktueller Entwicklungen des eigenen Fachs den Stellenwert derartiger Arbeiten zu erkennen und eine Br cke zur Gegenwart zu bauen Im g nstigsten Fall sollten diese Br cken so sie tragen
299. r gerne aufge nommen h tte Die gew hlten Arbeiten sind in Tab 1 gelb Basis artikel die gew hlt aber nicht ausgearbeitet wurden oder gr n Artikel f r die eine Vollversion ausgear 3 Eine umfassendere Darstellung der Motivation des Rah menthemas findet sich in 4 beitet wurde unterlegt In Kenntnis des Curriculums darf ich festhalten dass hierbei nicht nur Arbeiten gew hlt wurden die in einzelnen Lehrveranstaltungen zweifellos schon Erw hnung fanden sondern Thema oder Neugierde auch zu einigen Arbeiten greifen lie die subjektives Neuland sein sollten Ebenso ist davon auszugehen dass man die Namen vieler in Tabelle 1 genannter Autoren schon einmal geh rt hat Aber sicherlich nicht alle Dennoch wurden auch von den subjektiv unbekannten Autoren Arbeiten gew hlt Blickt man in die Ausarbeitungen der Studierenden zeigt sich dass diese wenig berraschend vieles auf Themen lenken denen innerhalb des Bakkalau reatsstudiums angemessener Raum gewidmet wurde Es zeigt sich jedoch auch dass sich einige der M he unterzogen in neue Gebiete einzudringen Im Sinn des Experiments nahm die Seminarleitung m glichst wenig Einfluss darauf wie Studierende den Wert der Ausgangsarbeit einsch tzten und wohin sie die Br cke in die Gegenwart bauten In einigen weni gen F llen wurde aber im Rahmen der Begutachtung st rkere Fokussierung eingemahnt damit letztlich eine innerhalb des vorgegebenen Seitenumfangs s
300. regation and generalization ACM TODS Vol 2 2 June 1977 pp 105 133 ee J Mylopoulos P A Bernstein A Language Facility H K T Wong for Designing Database Intensive Applications ACM TODS Vol 5 2 June 1980 a 185 207 S J Greenspan J Mylopoulos Capturing More World Knowledge A Borgida in the Requirements Specification Proc a eee 1982 pp 225 234 id7 Arango Domain Analysis From Art Form to Engineering Discipline Proc 5th IWSSD 1989 pp 125 135 earr Knowledge Representation What IS A Is and Isn t An Analysis of Taxonomic Links al R J Brachmann in Semantic Networks IEEE Computer Vol 16 10 Oct 1983 pp 30 36 x L A Zadeh Commonsense knowledge representation based on fuzzy logic IEEE Computer Vol 16 10 Oct 1983 pp 61 65 IEEE Trans on Knowledge and Data Engineering Vol 1 1 March 1989 a2b L A Zadeh Knowledge Representation in Fuzzy Logic pp 89 100 x x L A Zadeh Fuzzy Logic Computing with Words IEEE Trans on Fuzzy Systems Vol 4 2 May 1996 pp 103 111 Operating Systems E W Dijkstra The struchture of THE multiprogramming system Comm ACM Vol 11 5 May 1968 pp 341 346 D M Ritchie K Thompson The Unix Time Sharing System Comm ACM July 1974 pp 365 375 Pox Seminar aus Angewandte Informatik Vorbesprechung und Anmeldung R Mittermeir Dienstag 6 M rz 8 15 9 45 Wintersemester 2006 07 SR 2 42 Bakkalaureatsseminar aus Angewandte Informatik TRACES Themes still
301. reichs welche in einem konzeptuellen Schema dargestellt werden 6 Schlie lich gibt es eine dritte Welt die System World die die Systemspezifikation darstellt und den Anforderungen die aus den beiden anderen Welten entstehen gerecht werden muss 6 2 1 Informal semi formal oder formal Eine weitere Kernfrage des RE ist welcher Grad der Formalisierung beim Einsatz von Anforderungs bzw Wissensmodellen angewandt werden soll Tatsache ist dass Modelle als Kommunikationsmedium zwischen Kunden und Entwicklern dienen und somit allen Sta keholdern verst ndlich sein m ssen was f r eine in formale Notation spricht Andererseits haben formale Sprachen f r die Entwickler den Vorteil dass sie die strukturelle Grundlage f r die darauf folgenden Phasen des Designs und der Implementierung bieten k nnen Zus tzlich k nnen sie mittels so genannter Analyse programme leichter auf Korrektheit und Konsistenz gepr ft werden Was sind jetzt eigentlich formale Mo dellierungssprachen Eine Notation ist formal wenn sie eine formale Menge an Regel beinhaltet die ihre Syntax und Semantik definiert Genauer betrachtet beinhalten formale Notationen eine Ontologie eine Menge von Vermutun gen ber die Natur der Anwendung die mo delliert werden soll eine Terminologie Terme um ber die An wendung sprechen zu k nnen z B Entit ten Beziehungen usw eine Sprache um Aussagen in der Notation formulieren zu k nnen
302. ren Plannungsspiel In XP werden die Anforderungen mit Story Cards ermittelt Diese werden vom Kunden verfasst und priorisiert Sie beinhalten Szenarien f r die Systemfunktionalit t Daraufhin gestalten Kunde und Entwicklerteam einen Releaseplan Die Ziele f r jedes Release werden mit dem Kunden bzw Kundenvertreter vor Ort diskutiert Dadurch wird versucht das Risiko einer Fehlentwicklung zu kompensieren 20 Pair Programming Beim Pair Programming implementieren zwei Entwickler eine Problemstellung wobei einer der beiden den Code schreibt und der andere parallel den Code berpr ft und einen Schritt voraus denkt Die Paare mischen sich in zyklischer Reihenfolge durch und arbeiten immer an unterschied lichen Komponenten Dadurch wird verhindert dass 77 Projektwissen durch den Ausfall eines Mitarbeiters verloren geht 20 Oft wird die Wirtschaftlichkeit von Pair Programming kritisiert Nach einer Studie von Cockburn und Williams verschlingt diese Praktik lediglich 15 mehr Kosten 19 Als Ausgleich daf r f rdert es die Qualit t von Design Code und Entwicklerf higkeiten und reduziert Fehler und Risiken Laut Cockburn und Williams wird die Fehlerrate um 15 gesenkt 19 Nach Boehm kostet es um ein Zehnfaches weniger einen Fehler in der Implementierungsphase auszubessern als wenn er erst im Betrieb entdeckt wird 1 Testen eXtreme Programming adaptiert den TDD Ansatz wobei zuerst die Unit Tests geschrieben
303. ren werden zwei scharfe Messgr en geliefert die Temperatur im Raum und die Anzahl der Personen im Raum Durch diese Informationen soll der Ausgangswert berechnet werden Dieser Befehlswert soll den Prozentwert angeben wie weit man das Ventil welches f r die K hlung verantwortlich ist ffnen soll Im Prinzip besteht ein Fuzzy Regler aus drei Teilen B Fuzzifizierung Inferenz B Defuzzifizierung Abbildung 3 zeigt eine vereinfachte Sichtweise eines Fuzzy Reglers Als N chstes werde ich die Bestandteile und deren Zusammenwirken genauer erl utern und anschlie end eine detaillierte Beschreibung der Entwicklung eines Fuzzy Systems und deren Funktionsweise geben Wissensbasis A Pd xN Fuzzifizierung Inferenz N Linguistische Messwerte Linguistische Befehlwerte Scharfe Befehlwerte N Abbildung 3 Architektur eines Fuzzy Reglers Ein scharfer Wert bezeichnet einen pr zisen Wert also gew hnlich eine Zahl w hrend ein unscharfer beziehungsweise ein linguistischer Wert einen ungenauen Wert beschreibt z B eher hei Defuzzifizierung Bestandteile eines Fuzzy Reglers und deren Verbindungen Bei den Messwerten des Reglers die von den Sensoren geliefert werden handelt es sich um scharfe Zahlenwerte Diese m ssen nun in die linguistischen Werte des Systems abgebildet werden Dieser Schritt ist notwendig da die Regeln auf unscharfen Werten operieren Die Transformation der scharfen Mess
304. rgleich zum objektorientierten Ansatz erweitert der zielorientierte Ansatz urspr ngliche Ontologien um Notationen wie Ziele Abh ngigkeiten Rolle Akteur und Position Aufgrund solcher zus tzlichen Notatio nen l sst sich die Frage nach der Intention einer Anfor derung modellieren 5 Dar ber hinaus wird die tradi tionelle Anforderungsanalyse durch die Evaluierung und Ber cksichtigung von Alternativen gest rkt 9 4 4 Arten von Zielen Man unterscheidet verschiedene Arten von Zielen zu erreichende Ziele achievement goals zu bewahrende Eigenschaften maintenance goals und e weiche Ziele soft goals die in der Regel nicht funktionale Anforderungen betreffen Die Erf llung der zu erreichenden Ziele bzw der zu bewahrenden Eigenschaften kann durch formales Schlie en verifiziert werden wohingegen die Erf l lung der soft goals nicht eindeutig festgestellt wer den kann nur durch qualitatives Schlie en 14 Zu erreichende Ziele werden mittels einer UND ODER Verfeinerung zueinander in Beziehung gesetzt was Abbildung 4 illustriert Schedule meeting Generate schedule Collect other Collect timetables constraints Interactively Share timetables LA ca Manually Automatically From PR collects all From ae initiator only means Abb 4 Zielverfeinerung mittels UND ODER 9 Untergeordnete Ziele die durch ein UND miteinan der in Beziehung stehen h
305. ribute und Methoden Ein weiterer Punkt ist das Zuweisen von Attributen und Methoden welche anschlie end f r die Zuordnung eines Objektes zu ei ner Klasse herangezogen werden 4 Vollst ndiges Beispiel Bremssystem Um nun den gesamten erl uterten Stoff der vorheri gen Kapitel in einem durchg ngigen Praxisbeispiel zu erl utern soll ein Bremssystem f r ein Auto erstellt werden Weiters stellt dies ein Beispiel dar bei wel 125 chem Computing with Words wohl heutzutage am meisten eingesetzt wird n mlich bei Fuzzy Reglern 4 1 Ausgangssituation Ein Auto f hrt hinter einem anderen St ndig wer den die Geschwindigkeit des vorderen Autos sowie der Abstand zum vorderen Auto gemessen vgl Abbildung 7 Nun soll ein Bremssystem erstellt werden welches eben aufgrund dieser beiden Variablen einen konkre ten Bremswert ermittelt Weiters soll wegen der einfa cheren Bauwei e ein Fuzzy Regler zum Einsatz kom men q Bremskraft Geschwindigkeit Abb 7 Ausgangssituation 4 2 Erstellung des Systems Wie in Kapitel 3 beschrieben wurde m ssen zuerst Terme definiert werden welche die drei Variablen in granulare Mengen spalten Diese k nnen der Einfach heit halber in drei Mengen eingeteilt werden Abstand klein Geschw klein Bremsen schwach mittel mittel mittel gro hoch stark Als n chstes wird eine Fuzzyfizierung vorgenom men Das bedeutet dass die konkreten Werte durc
306. rodukten sind hier Qualit t und Preis nicht mehr direkt proportional zu einander Software die nicht von Anfang an einer ver n nftigen Architektur und einem durchdachten Ent wicklungsprozess unterliegen sowie Systeme bei de nen sich laufend Fehler einschleichen haben eine viel h here Entwicklungszeit und einen erh hten War tungsaufwand um etwaige Bugs zu beseitigen Dies alles treibt die Kosten immens in die H he Wie im bisherigen Verlauf dieser Arbeit gezeigt wurde kann die Entwicklung gut strukturierter Pro gramme dem entgegenwirken Die schrittweise Verfei nerung erlaubt Entscheidungen erst dann zu treffen wenn sie wirklich notwendig sind Dies k nnen Design Entscheidungen sein oder auch Formen der Darstel lung f r die verwendeten Datentypen Was dies f r die verwendete Programmiersprache bzw das eingesetzte Paradigma zum Beispiel prozedural oder objektorien tiert bedeutet wird in einem sp teren Abschnitt ge nauer beleuchtet 4 2 Programmiersprachen Das Aufkommen und die Entwicklung strukturierter Programmierung hatten einen immensen Einfluss auf die g ngigen Programmiersprachen Ein Grund daf r war wohl auch die Tatsache dass es zur Erstellung strukturierter Programme irrelevant ist welche Pro 14 grammiersprache verwendet wird manche Sprachen unterst tzen dies eben mehr manche weniger 11 Bei bereits bestehenden Sprachen wie zum Beispiel FORTRAN oder ALGOL konnte eine zwingende Un
307. rogrammiersprachen eingesetzt auf beliebigen Plattformen und Betriebssystemen auf Grundlage unterschiedlichster Netzwerktechnologien miteinander interagieren und kommunizieren lassen zu k nnen 9 EJB ist auf die Programmiersprache Java fixiert NET auf die Plattform von Microsoft und Komponenten die unter CCM laufen sollen m ssen auch erst an dieses Modell angepasst werden Chiang greift in 9 diese Schwachstelle auf und bietet als L sung den Einsatz von Adaptertechnologie an Adapter k nnen die Wiederverwendbarkeit von Softwarekom ponenten f rdern da sie nicht mehr nur auf ein Kom ponentenmodell beschr nkt sind Dennoch erfordert diese Technik weiteren Overhead und wirkt dem Ziel nach weniger Komplexit t und damit auch mehr Quali t t entgegen Systeme aus wiederverwendbaren Softwarekompo nenten zu bauen erfordert ein speziell auf diese Anfor derung zugeschnittenes Prozessmodell Morisio et al 22 sehen es als Fehler an komponentenbasierte Ent wicklung ohne Anpassung des traditionellen Prozesses zu betreiben 4 Komponentenbasierte Softwareentwick lung CBD Seit einigen Jahren hat die komponentenbasierte Entwicklung auch in der Industrie an Bedeutung ge wonnen Die Idee ganze Systeme aus selbst erstellten oder zugekauften Fertigbauteilen zu entwickeln ver spricht hohe Wiederverwendbarkeit bei steigender Qualit t und gleichzeitiger Kostenersparnis Heineman und Councill sind von der Relevanz des kompone
308. rop i schen Software Factory den B blingen Building Blocks publiziert konform geht wenn er die besten formalen Ans tze als solche beschreibt die schlussend lich automatisiert und in Software gegossen werden k nnen 12 3 2 Serviceorientierter Reuse Wesentlich elementarer ist das Reuse Konzept durch Serviceorientierung aus technischer Sicht insbe sondere WebServices wiederbelebt worden indem das urspr nglich in Fuchu dargestellte Modell mit dem Internet auf eine breitere Basis gestellt wird Es wird erstmals Reuse auf einer weltweit einheitlichen techno logischen Basis mit XML als Kommunikationssprache und HTTP als Kommunikationsmittel ber alle Be triebsgrenzen hinweg propagiert Verglichen mit der von Matsumoto beschriebenen Struktur der Wieder verwendbarkeit bleiben die Faktoren Auffinden von Komponenten zentrale Datenbank und speziali sierte Entwicklung von Komponenten erhalten Die Komponentenauffindung erfolgt ber UDDI Universal Description Discovery and Integration durch Key word Beschlagwortung Der Discovery Prozess erfolgt in stark strukturierter Datenbank Form Die verwende ten Termini Telefonbuch Pages in den UDDI Strukturen weisen dabei deutlich auf eine listenorien tierte Struktur hin Der von Matsumoto angestrebte objektorientierte Ansatz zur Informationsfindung bleibt gr tenteils auf der Strecke obwohl er gerade in einem derartig gro en Scope als sinnvoll
309. rozess eingegrenzt in einem Unternehmenskontext Diese Eingrenzung mit der erweiterten Sicht ber Code als Wiederverwendung hinaus erm glicht eine h herwertige Wiederverwendung Product Development Produktentwicklung Der Output der Artefaktentwicklung sowie konkrete Anforderungen dienen als Input f r die Entwicklung der konkreten Produkte die nach dem Produktionsplan entwickelt werden Erfahrungen w hrend der Entwicklung flie en wieder zur ck in die Artefaktentwicklung Die Produktentwicklung kann sehr stark variieren abh ngig von den Artefakten dem Produktionsplan und der Organisation 15 Diese Aktivit t entwicklungsprozess entspricht dem Applikations Management F r die erfolgreiche Umsetzung von Product Line Engineering m ssen die Artefakte und Produkt entwicklung geplant koordiniert und berwacht werden Daf r sind geeignete organisatorische Strukturen notwendig Es gibt 3 Vorgehensweisen in welcher Form der Entwicklungsprozess gestartet wird 12 proaktiv reaktiv und extrahierend Bei dem proaktiven Ansatz werden zuerst die Artefakte implementiert und darauf aufbauend die Produktentwicklung eingeleitet Dieser Ansatz ist bei 107 stabilen Dom nen geeignet hat aber hohe Anfangskosten Beim reaktiven Ansatz werden die Artefakte nach Bedarf entwickelt und die Produkte nach herk mmlichen Verfahren erstellt Anwendung findet dieser Ansatz bei Produkten bei denen die Produktvariationen schwer
310. rrascht Es erschien mir vorerst fast paradox und erinnerte mich an 79 die Frage was zuerst existierte die Henne oder das Ei Wenn man Osterweils ersten Artikel Software Processes are Software too aus dem Jahr 1987 liest merkt man dass die Begriffe aus dem Titel erst einmal genau definiert werden m ssen um die von ihm vorgestellte Grundidee zu verstehen Deshalb sollen im zweiten Kapitel die wichtigsten Aussagen aus dem Aufsatz aus dem Jahr 1987 wiedergegeben werden Es war sicher ein neuer Ansatz in der jungen wissenschaftlichen Disziplin den Softwareprozess auch als Software zu sehen und d rfte Grund f r einige Diskussionen gegeben haben Was der Grund war warum dieser Artikel zum einflussreichsten der 9 ICSE gew hlt wurde habe ich nicht herausgefunden Nachdem Leon Osterweil im Aufsatz Software Processes are Software too Revisited einige Aussagen aus dem Leitartikel untermauert und einige Aspekte hinzugef gt hat flie t auch dieser in meinen Artikel mit ein Wie schon erw hnt hat es um die Aussagen Osterweils einige Diskussionen gegeben Ein Kritiker war M M Lehman Er geht mit Osterweil nicht konform und gibt einige stichhaltige Gr nde an warum die Idee von Leon Osterweil nicht oder nur bedingt funktionieren kann Lehmans Artikel waren unter anderem auch ein Grund daf r warum auch ich bezweifelte dass eine Umsetzung der Forderungen und Ideen von Osterweils Arbeiten praktikabel realisiert worden ist
311. rsioning It should be possible to update and change existing components one at a time Thus making it easier to manage and maintain such systems Until now it should be clear that the UNIX toolset is doing just that Since all tools are user programs they can be changed easily and by anybody Tools can even be replaced for individual users Deployment is quite easy too since the program only has to be copied to the right path in the file system Given the definition of a software component and comparing it to the functionality the UNIX command language provides together with the extensive toolset chapter 2 I have the courage to name shell programming a component driven development approach I am not alone with this assumption as some publications see the UNIX shell as a fourth generation programming language 8 with a component driven approach 3 2 Pipes and Filters One of the most widely admired contributions of Unix to the culture of operating systems and command languages is the pipe as used in a pipeline of commands said UNIX co developer Dennis M Ritchie in a paper when he looks back on the development process and describes some of the decisions made 4 This idea of pipes evolved over time and many other systems were built following these principles finally leading to an architectural pattern 12 3 2 1 History and UNIX pipes In an internal Bell Labs memo by Doug McIlroy scanned and put on the net by Ritchie D
312. rt wird dieses n Dimensionale Fuzzy Set granularisiert sodass nun Mengen vorhanden sind welche alle ein in Hinsicht auf diese Variable homogenes Verhalten aufwei en Wie stark die Auspr gungen dieses Verhaltens sind dr ckt die Membership Funktion aus Es ist nun also der n chste Schritt geeignete Regeln f r die Erken nung der Krankheit zu bilden Die Regeln hierbei ha ben alle die Form Wenn Symptom u A Symptom u Then Diagnose d u Um diese Regeln ableiten zu k nnen ben tigt man das Expertenwissen Somit wurden die Regeln gebildet und das System erfolgreich erstellt 3 3 Die Natur besser verstehen Es gibt eine starke Tendenz in Fuzzy Modellierung dass man zuerst die Natur beobachtet diese nat rlich sprachlich beschreibt weiters mit Fuzzy Logik in ein mathematisches System umwandelt und anschlie end dieses Modell bei Maschinen einsetzt Zum besseren Verst ndnis soll ein Ameisenmodell beschrieben wer den welches zwar keinen typischen Anwendungsfall von Computing with Words darstellt aber trotzdem die Arbeitsweise verdeutlicht Es handelt sich dabei um eine Gruppenprobleml sung Cooperative Problem Solving bei welcher die Ameisen in Kolonien eine hohe Intelligenz zu Tage bringen 3 6 Ameisen und auch andere Tiere m ssen oftmals bei ihrer Futtersucher einen weiten Weg zur cklegen Da her bedienen sie sich eines Mechanismus welcher ih nen erlaubt in k rzester Zeit den f r sie besten
313. rtige Systeme generiert werden Der Trend der Wiederverwendung in der Softwareentwicklung geht hin zu flexiblen anpassungsf higen Plattformen die verschiedene Werkzeuge f r unterschiedliche Anwendungszwecke zu Verf gung stellen Die gemeinsamen Entwicklungen und Standardisierungen unterschiedlicher Unternehmen und Organisationen im Bereich DSM und Wiederverwendung zeigen gro es Interesse und Potenzial die Softwareentwicklung weiter zu verbessern 7 Referenzen 1 Arango G 1989 Domain analysis from art form to engineering discipline In Proceedings of the Sth international Workshop on Software Specification and Design Pittsburgh Pennsylvania United States IWSSD 89 ACM Press New York NY 152 159 2 McIlroy M D 1968 Mass produced software components In Software Engineering Report on a conference by the NATO Science Committee Garmisch Germany Oct Naur P and Randell B Eds NATO Scientific Affairs Division Brussels Belgium pp 138 150 3 Long J IBM Software reuse antipatterns Source ACM SIGSOFT Software Engineering Notes Volume 26 Issue 4 pp 68 76 July 2001 4 Neighbors J M Software Construction Using Components Doctoral Thesis Department of Information and Computer Science University of California Irvine 1980 5 Czarnecki K Generative Programming Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment Based Component Model
314. rung von Source Code der jedoch nur eines von vielen Artefakten im Software Entwicklungsprozess darstellt ber cksichtigt wird In einem modernen objekt orientierten Prozess existiert jedoch eine Vielzahl von anderen Artefakten man denke zum Beispiel an Dokumente und Ideen die im Laufe der Requirements und Design Phase entstehen 6 KONKLUSION Ausgehend von der Arbeit von Prieto Diaz und Freeman wurde in diesem Artikel die Klassifizierung von Software Komponenten die damit verbundenen Probleme und An s tze zur L sung dieses komplexen Themas diskutiert Prieto Diaz und Freeman realisierten in 11 das facetten orientierte Klassifizierungs Schema welches Grundlage f r zahlreiche darauf aufbauende Ans tze und Technologien dar stellt und sich heute in diesen wiederspiegelt Im Zuge dieser Arbeit wurden einige dieser aufbauenden Ans tze untersucht und zur Arbeit von Prieto Diaz und Freeman in Relation gesetzt Dabei wurde speziell auf das 70 Klassifizierungs und Wiederauffindungs Problem eingegan gen Abschlie end bleibt zu sagen dass die untersuchten Proble me des Software Reuse auch in Zukunft diskutiert werden sollten um diese so gut als m glich zu l sen und die Wie derverwendung bestehender Komponenten in eine noch zen tralere Position der Softwareentwicklung zu r cken 7 LITERATUR 1 J Boerstler Feature oriented classification for software reuse In 7th International Conference on Software Engine
315. s die sich im Sekund rspeicher befinden Der Segment Controller l dt ben tigte Segmente vom Se kund rspeicher in den Hauptspeicher und schreibt nicht mehr ben tigte Segmente in den Sekund rspeicher zur ck jedoch nicht zwingend an dieselbe Stelle an der sie sich urspr nglich befanden Dar berliegende Pro zesse sprechen nun nur mehr Segmente an Sie m ssen sich nicht darum k mmern ob ein ben tigtes Segment sich bereits im Hauptspeicher befindet oder erst vom Sekund rspeicher geladen werden muss Schicht 2 In dieser Schicht befindet sich der Message Interpreter Dieser k mmert sich um die Zuweisung einer Konsolentastatur ber welche Nach richten zwischen dem Benutzer und irgendeinem dar berliegenden Prozess ausgetauscht werden k nnen Der Benutzer muss in der Er ffnungsnachricht ange ben an welchen Prozess seine Konversation gerich tet ist Beginnt ein Prozess eine Konversation identi fiziert er sich in der Er ffnungsnachricht Der Name des Message Interpreter r hrt daher dass er bei ei ner vom Benutzer er ffneten Konversation zuerst die Er ffungsnachricht interpretiert um den Prozess zu identifizieren an den die Konversation gerichtet ist Schicht 3 Hier geschieht das Puffern von Einga bestr men bzw das Entpuffern von Ausgabestr men In dieser Schicht findet die Abstraktion der eigentlichen Peripherieger te statt Schicht 4 In dieser Schicht befinden sich die Be nutzerprogramme Auf
316. s Ph D Thesis Department of Computer Science and Automation Technical University of Ilmenau October 1998 6 Kean L Domain Engineering and Domain Analysis http www sei cmu edu str descriptions deda html letzte Modifikation 1998 letzter Zugriff 05 07 2007 7 Pohl K B ckle G van der Linden F Software Product Line Engineering Springer Verlag Berlin Heidelberg 2005 8 Coplien J Hoffman D Weiss D Commonality and Variability in Software Engineering IEEE Software vol 15 no 6 pp 37 45 Nov Dec 1998 9 Allen N A Shaffer C A Watson L T 2005 Building modeling tools that support verification validation and testing for the domain expert In Proceedings of the 37th Conference on Winter Simulation Orlando Florida December 04 07 2005 Winter Simulation Conference Winter Simulation Conference 419 426 10 Fowler M Rice D Foemmel M Hieatt E Mee R Stafford R Patterns of Enterprise Application Architecture Addison Wesley Pearson Education Inc Boston USA November 2002 11 Neighbors J M Bayfront Technologies Inc Draco A Method for Engineering Reusable Software Systems In Software Reusability Vol 1 Concepts and Models T J Biggerstaff and A J Perlis Eds ACM Press New York NY 295 319 May 1987 12 Sugumaran V Park S Kang K C Software Product Line Engineering Special Issue Communications of the ACM December 2006 Vol 49 No 12 13 Mili A Yac
317. s und nderungsm glichkeiten Gute Projektmanage ment Fertigkeiten und Kenntnisse objektorientierter Konzepte Die St rken des Prozessmodells liegen in der guten Darstellung und dem hohen Detaillierungs grad des Prozesses Es eignet sich aber eher f r gro e Softwareprojekte Folgende Problemebereiche ergeben sich mit dem RUP Schwierige Anpassung in einer Organisation instabile Prozessdefinition aufgrund st ndiger Weiter entwicklung der Prozesskonzepte und die Vort u schung dass die Sofwareentwicklung algorithmisch durchgef hrt werden kann vgl 6 pp 198 199 4 Agile Softwareentwicklung Agile Methodiken sind als leichtgewichtige Ent wicklungsprozesse bekannt da hier auf alles verzichtet wird was keine Relevanz f r das Projekt hat Die agile Bewegung entwickelte sich in den sp ten 90er Jahren aufgrund der Tatsache dass schwergewichtige Prozesse einen hohen b ro kratischen Aufwand nach sich zogen wenn sich nderungen ergaben 9 Bei der agilen Entwicklung steht kein strikter Prozess im Mittelpunkt sondern der Mitarbeiter Im Manifest der Agile Alliance werden vier Werte genannt welche bei einer agilen Vorgehensweise st ndig beachtet werden m ssen Dies sind e Menschen und Zusammenarbeit vor Prozes sen und Werkzeugen e Funktionierende Software vor umfangreicher Dokumentation e Zusammenarbeit mit dem Kunden vor ver traglicher Verhandlung e Reaktion auf Ver nderung vor Einhaltung eines Plans Aus dem
318. s UML Metamodells 3 4 2 Dom nenspezifische Sprachen Model Driven Software Development spielt sich immer im Kontext von Dom nen ab Diese beschreiben einen einge schr nkt ausgew hlten Bereich auf den sie Bezug nehmen z B Versicherungswesen oder Telekommunikationindustrie Dom nen k nnen in technische und fachliche eingeteilt wer den falls dies relevant und gew nscht ist Mit dem im vorigen Kapitel gezeigten Konzept der Meta modellierung l sst sich abstrakt die Strukur von Dom nen beschreiben Solche Modellierungssprachen werden allgemein als Domain Specific Languages DSLs bezeichnet Ein Ziel von DSLs ist es dem Benutzer der Sprache so gut wie m glich zu helfen in einer Dom ne zu denken und zu arbeiten Erst durch die Orientierung am Problemraum der jeweili gen Dom ne k nnen spezielle DSLs mit kompakter Syntax erzeugt werden Dom nenspezifische Sprachen k nnen bei Bedarf auch selbst erzeugt und auf eine spezifische Probleme zugeschnitten wer den In diesem Fall sollte als erstes die Dom ne analysiert werden Dabei werden geeignete Abstraktionen und Kon zepte gesucht um diese zu beschreiben und ein Metamodell zu bilden Nachfolgend kann die exakte Syntax spezifiziert werden 3 4 3 Zielarchitekturen und Dom nenspezifische Platt formen Softwarearchitektur spielt eine wichtige Rolle im Entwick lungsprozess und wird hier in einem relevanten MDSD Kon text dargestellt e Auch bei der modellgetriebene
319. s capital intensive if it requires ex pensive tools or if it involves large startup expendi tures Die von Wegner beispielhaft aufgezeigten Softwareaktivit ten 31 lehren uns dass der Erstellung gro er qualitativ hochwertiger Softwaresysteme kapi talintensive Softwaretechnologie zu Grunde liegt Die ser Trend hat sich wegen der zunehmend divergieren den Kostenkurven zwischen Hardware und Software 55 aber auch wegen steigender Softwarequalit tsanforde rungen bis heute fortgef hrt Durch Wiederverwendung k nnen sowohl die Qua lit t der Software als auch die Produktivit t von Soft wareentwicklung bedeutend erh ht werden 21 Soft warekomponenten werden in Wegners Artikel als wich tige wiederverwendbare Ressource hervorgehoben Auch Mcllroy 18 hat bereits 1968 in dieser Techno logie gro es Zukunftspotential gesehen My thesis is that the software industry is weakly founded and that one aspect of this weakness is the absence of a soft ware components subindustry Inzwischen ist die Softwarekomponenten Forschung zu einer Teildisziplin des Software Engineerings avanciert Ohne Zweifel lassen sich hnlich weitreichende Fortschritte auch in den weiteren von Wegner betrachteten Aktivit ten wie Softwareprozesse Knowledge Engineering oder Prog rammiersprachen finden Wegner hat in jeder dieser Aktivit ten eine hohe Kapitalintensit t feststellen k n nen Aus heutiger Sicht spannen die angesprochenen Teilbereic
320. s definieren von Bedingungen erlaubt wann ein Step beginnen darf und wann er beendet ist Eine Bedingung kann die Beendigung eines anderen Schrittes sein oder z B eine Gewichtsbeschr nkung f r Gep ck beim Einchecken in einen Flug 83 werden wie man im Beispiel zwischen Step PlanTrip und PlaneReservation sieht Hier werden TripDates und Budget an PlaneReservation bergeben und PlanTrip erh lt als Paramter TripDates und die Airline zur ck Genauso k nnen Ressourcen in einen Step einflie en Ressourcen k nnen wiederum Agenten menschliche oder mechanische sein Werkzeuge oder andere ben tigte Ressourcen Little JIL wurde bzw wird an der Universit t Massachusetts entwickelt Bei meinen Recherchen fand ich keinen Hinweis auf Erfahrungsberichte in realen Softwareprojekten mit Little JIL 6 Rational Unified Process Im letzten Kapitel m chte ich nun auf den Rational Unified Process eingehen RUP wurde bei Rational Software entwickelt wobei der Ansatz dazu schon in den achtziger Jahren entwickelt wurde Die erste Version von RUP wurde 1998 herausgegeben Der f r die Entwicklung Hauptverantwortliche war Philippe Kruchten In seinem Buch sagt Kruchten selbst dass der Rational Unified Process wie Software entworfen entwickelt vertrieben und gewartet wird Es werden regelm ig Updates herausgegeben die Vermarktung erfolgt mittels Internet es kann an die Anforderungen der Benutzer angepasst werden un
321. sch tzten 85 an Programmierstunden da schwere Fehler nicht erst in der Testphase sondern durch Inspektionen fr her entdeckt wurden Zu dem gleichen Schluss kommt Russell 14 Bei Bell Northern Research wird im Durchschnitt ein Fehler pro aufgewendeter Mannstunde durch Inspektionen gefunden Wohingegen 34 Mannstunden gebraucht werden um einen Fehler der vom Kunden gemeldet wurde auszubessern Pro gefunden Fehler ergibt sich theoretisch eine durchschnittliche Einsparung von fast 33 Mannstunden DEVELOPMENT PEOPLE RESOURCE AND SCHEDULE WITHOUT INSPECTIONS w j gt ol o E i als 2 w w 2 w w i pel amp Z 5 oja 9 gis g a 1 b t Z i i 0 DESIGN CODING TESTING en ii SCHEDULE Abbildung 4 Reduktion von Ressourcen in Softwareprojekten mit und ohne Inspektionen Des Weiteren stellt Russell zwei vergleichbare Projekte gegen ber das erste wurde noch vor der Einf hrung das zweite nach der Einf hrung von Inspektionen bei BNR umgesetzt Beim ersten Projekt konnte durch den Systemtest eine Quote von rund 0 3 Fehlern pro Mannstunde entdeckt werden Im Designtest lag die Quote lediglich bei der H lfte Beim zweiten Projekt konnten durch Inspektionen immerhin rund 0 6 Fehler entdeckt werden Russell kommt zu dem Schluss dass unter optimalen Umst nden Inspektionen bis zu zwanzigmal effektiver sind als das Testen Das Testen vor Inspektionen ist also wes
322. schreiben In dieser Hinsicht gewinnen Ontologien in allen mit Wissen befassten Bereichen der Informatik immer mehr an Bedeutung ebenso in der Softwareentwicklung SE wo sie als Hilfsmittel und Wissensfundus dienen 15 In der SE leitete die Einf hrung der Objektorientiertheit den Gebrauch von Ontologien ein Man nannte diese Dis ziplin der Wissensbeschaffung und analyse eines gewissen Bereiches der Welt domain modeling 5 2 Domain Model Wie im ersten Abschnitt bereits erl utert wurde ist es bei der Entwicklung von Softwaresystemen u erst wichtig dass die Analytiker und Designer den Anwen dungs und Problembereich verstehen vor allem jenen von gro en und komplexen Systemen Das so genannte domain knowledge ist meist e informal statt formal implizit statt explizit und nur unvollst ndig oder in problemspezifischer Sprache modelliert 17 Ein domain model kann nun als ein explizites dekla ratives in formaler Sprache gehaltenes Modell ber einen solchen Anwendungsbereich verstanden werden 5 3 Ontology Engineering Mit der steigenden Bedeutung von Ontologien betrieb man auch mehr Forschung ber diese Materie und so entstand das Ontology Engineering OE OE um fasst die Produktion von Ontologien welche abstrakte Modelle eines Bereichs sind Tats chlich ist der Nut zen durch den Einsatz einer Ontologie nur so gro wie dessen F higkeit Material Gegenst nde
323. se dar Durch die Fusion der Rational Software Corporation und Jacobsons Objectory AB 1995 5 OO Objekt orientiert OOA Objekt orientierte Analyse 7 OOD Objekt orientiertes Design OMT Object modeling Technique OOSE Objekt orientiertes Software Engineering entstand 1998 der Rational Unified Process Der RUP ist im Grunde genommen ein Produkt vom Hause Rational das st ndig weiterentwickelt wird Er ist ein werkzeugzentrierter Prozess und eng mit der UML verbunden Der RUP ist eine konkrete Implementie rung des abstrakten Unified Process und ein Paradebeispiel eines modernen Vorgehensmodells 6 3 1 Strukturen Das Wesen des RUP liegt in den f nf Prozessbau steinen T tigkeiten Workflows Iterationen Phasen und Zyklen Der RUP besteht aus einer dynamischen und statischen Perspektive Die dynamische Perspektive schlie t den zeitlichen Verlauf anhand von Zyklen Phasen Iterationen und Meilensteinen ein Aktivit ten Artefakte Ergebnisse Workflows und Mitarbeiter bilden den statischen Teil des Models Die statische Struktur legt fest wer was wie und wann zu tun hat Organization along time Phases f Core Process Workflows TansnjEssee Commuter Te Burress Modeling _ Reqarements tcc i i Analysis amp Design ee Ne Organization Se nn en es i Cepek L 4 en Core Supporting Workflows I i i Configurenon amp Change Mgmt t Project Management
324. sed Software Engineering Addison Wesley 2001 pp 557 571 31 Wegner P Capital Intensive Software Technology IEEE Software 1 3 Jul 1984 pp 7 45 32 Wohlin C Runeson P Certification of Software Components JEEE Trans Softw Eng 20 6 Jun 1994 pp 494 499 Faceted Classification Christoph Kofler 0560345 christoph kofler edu uni klu ac at ABSTRACT In der heutigen Zeit der komponentenbasierten Software entwicklung wird das bereits sehr wichtige Thema Softwa re Reuse vermehrt in eine zentrale Position gestellt Jedoch gibt es ein gro es Problem das den Reuse Prozess erschwert die Klassifizierung und Auffindung von bereits vorhandenen Komponenten Der vorliegende Artikel befasst sich nun mit der Klassifi zierung solcher Software Komponenten um sie einzuordnen und Software Entwicklern die M glichkeit zu bieten diese zu finden und bei Bedarf zu adaptieren Ferner baut der Auf satz auf den Grundprinzipien der Software Klassifizierung auf Dabei werden alte grundlegende berlegungen zu neu en aufbauenden Ideen und L sungen in Relation gesetzt Speziell wird ein Schema behandelt welches davon ausgeht dass Software Collections sehr gro sind st ndig anwachsen und viele hnliche Software Komponenten beinhalten In nerhalb dieses Faceted Classification Scheme werden die Klassifizierung ihr Umfeld und ein Library System welches auf diesem Schema aufbaut diskutiert Dar ber hinaus we
325. sel f r die Artefaktesammlung 17 Als Input f r die Entwicklung von Artefakten dienen Produktbedingungen in Form von Gemeinsamkeiten und Unterschiede organisatorische Rahmenbedingungen f r die Produktion und eine Produktionsstrategie Als Output neben den Artefakten entsteht eine Produktlinienabgrenzung die die m glichen Produkte beschreibt sowie ein Produktionsplan wie Produkte mit Hilfe von den Artefakten erstellt werden k nnen 15 Die Ausarbeitung von Gemeinsamkeiten und Unterschiede wird h ufig mit Featurediagrammen dokumentiert wie sie in der Feature Oriented Domain Analysis FODA Methode angewendet wird Dabei wird eine Hierarchie von Features aufgebaut Es werden 3 Arten von Features unterschieden Zwingende Features die jedes System haben muss alternative Features bei denen nur ein Feature ausgew hlt werden kann und optionale Features 5 Artefakte k nnen horizontale oder vertikale Wiederverwendung forcieren Horizontale Artefakte sind generischer Art nicht auf eine Dom ne eingeschr nkt und k nnen daher produktlinien bergreifend eingesetzt werden Vertikale Artefakte sind mehr produktspezifisch 16 Eine wichtige organisatorische Entscheidung betrifft in welcher Form die Artefakte zur Verf gung gestellt werden Werden sie von Grund auf neu implementiert von Altsystemen extrahiert oder mit Commercial Off The Shelf COTS Komponenten zugekauft Diese Aktivit t entspricht dem Domain Engineering P
326. ses e Software Architekt Er trifft die Entscheidung in welche technische Richtung das System geht indem er auf Grund der Anforderungen der Stakeholder eine Architektur f r das System baut e Project Manager Stellt Ressourcen bereit verteilt diese setzt Priorit ten koordiniert Treffen zwischen Kunden und Teammitgliedern e Test Designer Erstellt plant implementiert und evaluiert Testf lle e Technical Writer Schreibt das Handbuch Support Material Hilfetexte Texte zu den Releases usw Au erdem gibt es noch zus tzliche Rollen wie z B den Reviewer den Review Coordinator Any Role Any Role ist eine generische Rolle der T tigkeiten zugewiesen werden k nnen die noch von keiner anderen Rolle ausgef llt wird aber ben tigt wird usw Dass RUP von verschiedenen Firmen genutzt wird beschreibt Kruchten in Kruchten 03 7 Konklusion Der teilweise philosophische Artikel von Leon Osterweil verf hrt geradezu zum Suchen und Nachschlagen von Definitionen Was ist Software Was ist ein Softwareprozess Kann man wirklich sagen dass ein Softwareprozess Software ist Wenn man die Ideen aus dem Leitartikel Software Processes are Software Too hernimmt und mit Kapitel 6 Rational Unified Process vergleicht findet man einige Ideen von Osterweil wieder Jedoch musste f r RUP keine Softwareentwicklungsprozess Programmiersprache entwickelt werden Die Unified Modelling Language UML wurde zwar parallel zu RUP entw
327. shop on Domain Specific Modeling ACM OOPSLA 06 October 22 26 2006 24 http www omg org mda Letzter Zugriff 12 07 2007 25 http msdn2 microsoft com en us practices bb190387 aspx Letzter Zugriff 12 07 2007 26 http www eclipse org modeling Letzter Zugriff 12 07 2007 27 http www metacase com Letzter Zugriff 12 07 2007 Eine Einf hrung in Fuzzy Logik und seine geschichtliche Entwicklung Sommersemester 2007 Nina Margarita Winkler 0360706 n2winkle edu uni klu ac at Abstract Bis ins 20 Jahrhundert war die von Aristoteles begr ndete zweiwertige Logik die Basis von s mtlichen Ans tzen in Bezug auf Wissensrepr sentation Die Problematik der bivalenten Logik ist jedoch das Unverm gen mit unsicheren und ungenauen Aussagen zufrieden stellend umzugehen Fuzzy Logik die eine Erweiterung des klassischen Logiksystems ist kann diese Schwierigkeit l sen Im Gegensatz zur klassischen Logik l sst die Fuzzy Logik nicht nur zwei Werte wie wahr oder falsch zu sondern ebenso Zwischenwerte wodurch es ihr m glich ist die Unsicherheit und Ungenauigkeit von Daten effektiv handzuhaben Die Seminararbeit soll zun chst die grundlegenden Konzepte und Verfahren von Fuzzy Logik n her bringen und einen tieferen Einblick in die Konsequenzen dieser Kernidee verschaffen 1 Vorwort Die bivalente Logik ist ein m chtiges Instrument auf dem viele Anwendungen aufbauen aber mit ihrer Hilfe kann man die Wel
328. shown transformations serve the purpose to increase the awareness that a lot of widely used programming languages are nothing more than goto s limited to a certain scope The limited scope is well known and 23 can be handled easily to achieve a good program structure Unconditional program transfers other than goto statements are very limited in present programming languages because program language designers decided so to overcome the above mentioned problems with program structure Nevertheless goto s are present in a number of languages and there are a few software engineering aspects that should be considered here Additionally constrained goto s break continue case are subject to these software engineering aspects as well 4 Software Engineering aspects It is very important to understand that goto statements can be a means of creating several important features like exception handling in low level programming languages like C It is also obvious that a misuse of unconditional branching will lead to programs with rather bad structure Therefore a few pragmatic rules 3 will be introduced for determining how goto statements can be used in a good way Moreover those rules can be applied to modern unconditional branching constructs as well because of their clear relationship to goto statements First no goto should ever jump into a loop or into a conditional statement A jump into a loop or a condition will lead t
329. sierte Repor tingfunktionalit t die in die Suites integriert werden k nnte w re im durchg ngigen Softwareprozess eine Bereicherung die sich aus Matsumotos Ans tzen mit heutigen Mitteln Web durchaus realisieren lassen w rde ber Identifikation aus den Codebereichen k nnen Testdokumente codebereichsspezifisch gene riert und ber Netzwerke in das entsprechende Ent wicklungssystem als Feedback und zu Wartungszwe cken r ck bertragen werden Hier eine Infrastruktur zur Verf gung zu stellen w rde m glichen Iterationen des Prozesses entsprechend gerechter werden 5 2 Management Die von Matsumoto als operative Management Methode Look Forward Management beschriebene Projektplanung l sst sich mit Hilfe der Tools nur teil weise realisieren Im Microsoft Produkt l sst sich Pro jektmanagement anhand aller aufgezeichneten Daten die aus unterschiedlichen Komponenten zentral am Server aggregiert werden auf entsprechende Auswer tungen gest tzt durchf hren Durch Drilldown Techniken mit welchen von zusammenfassenden Be richten in Einzelschritten auf Detaildatens tze in die Tiefe navigiert werden kann erh lt der Manager ba sierend auf SQL Server Reporting Services entspre chenden Einblick auf die von Matsumoto herausgear beitete menschliche Ebene Zwar nicht out of the box aber konfigurierbar lie e sich auch ein entspre chendes pers nliches Spektrum einer Person erstellen Die zwei Faktoren m
330. sprache zur Implementierung der Kom ponenten eine Aspektsprache zur Implementierung der Aspekte und einen Aspect Weaver zur Kombination der beiden Sprachen Join Points sind jene Stellen im Programm der Komponentensprache an denen die Aspekte eingebracht werden 2 2 AspectJ AspectJ 1 ist eine aspektorientierte Erweiterung zu Java und wurde im Xerox Palo Alto Research Center entwickelt we have chosen to design AspectJ as a compatible extension to Java so that it will facilitate adoption by current Java program mers By compatible we mean four things e Upward compatibility all legal Java programs must be legal AspectJ pro grams e Platform compatibility all legal AspectJ programs must run on standard Java virtual machines e Tool compatibility it must be possi ble to extend existing tools to support AspectJ in a natural way this includes IDEs documentation tools and design tools e Programmer compatibility Program ming with AspectJ must feel like a natu ral extension of programming with Ja va 4 Java wurde als Basis fiir eine Aspektsprache gew hlt weil sie eine General purpose Language ist und daher dom nenunabh ngig ist Es kann auf dem Modularisierungsprinzip mit Klassen von Java aufge baut werden um Aspekte die quer zu dieser Modulari sierung liegen zu definieren AspectJ ist sehr gut doku mentiert dadurch bietet es sich an um das Konzept der Aspektorientierten Pr
331. sprachen wurde die bis heute zunehmende Relevanz der Thematik dar gestellt Meiner Meinung nach ist es jedoch wichtig dass neben dem hier beschriebenen programming in wei terer Zukunft das coding ebenso eine zentrale Rolle spielen wird Neben der Aufgabe auch weiterhin Com piler und andere maschinennahe Systeme zu schreiben wird es heute mehr noch als fr her immer mehr von den Ressourcen her eingeschr nkte Ger te geben die einer ad quaten Programmierung bed rfen K hl schr nke die selbst online nachbestellen k nnen und intelligente Kleidungsst cke sind hier wohl erst der Anfang Derartige Ger te und Tools werden jedoch optimierte Programme ben tigen um die eingeschr nk te Hardware optimal zu nutzen Hierbei k nnen dann wohl auch die alten Tricks dabei helfen die ge w nschte Effizienz zu erreichen obwohl hier sicher eine berf hrung eines zuerst strukturiert entwickelten Programms eine angebrachte Strategie ist Nichtsdestotrotz kann ich mich nur der Meinung von D McCracken aus 07 anschlie en dass struktu rierte Programmierung neben der Einf hrung von clo sed subroutines eine der gr ten Erfindungen der Softwaretechnologie ist und bleibt 6 Referenzen Basisartikel 01 Wirth N 1974 On the Composition of Well Structured Programs ACM Comput Surv 6 4 Dec 1974 247 259 weitere Referenzen 02 Bezanson W R 1975 Teaching structured program ming in FORTR
332. ssysstem komponenten voneinander Dadurch war es m glich das System Schicht f r Schicht zu testen und die Korrekt heit der Implementierung des Systems zu zeigen In mo dernen Betriebssystemen k nnen sich bestimmte Inter essen wie zum Beispiel h here Performanz bei Spei cherzugriffen oder Logging ber einzelne Komponen ten hinweg erstrecken Es besteht die Gefahr dass die Prinzipien der Schichtarchitektur durch eine Aufhebung der Komponententrennung verletzt werden Aspektori entierte Programmierung ist eine M glichkeit solche komponenten bergreifenden Interessen zu identifizieren und in die Komponententrennung miteinzubeziehen 1 Einleitung Edsger W Dijkstra beschreibt in 3 ausf hrlich den Schichtaufbau des THE Multiprogramming Sys tems Jede Schicht repr sentiert eine Menge von sequentiellen Prozessen die dar berliegenden Pro zessen eine bestimmte Funktionalit t anbieten Dabei entsteht ein hierarchisches System Ziel ist es von der Hardware immer weiter zu abstrahieren und das System besser verst ndlich zu machen Die einzelnen Schichten von THE k nnen als virtuelle Maschinen betrachtet werden Dabei erm glichen wohldefinierte Schnittstellen zwischen den Komponenten eine use Beziehung zwischen den Schichten Ein Prozess einer Schicht verwendet die Dienste die die darunterliegende Schicht anbietet Auf unterster Ebene geschieht die Prozesssynchronisierung Dar ber werden Schicht f r Schicht Speicherverwalt
333. st wird in XP st ndig getestet Den Grundpfeiler bei XP bilden vier Werte e Kommunikation Forderung intensiver Kommunikation im Team e Einfachheit S mtliche Systemteile m ssen so einfach wie m glich entworfen werden e Feedback Unterst tzt durch die XP Prakti ken sollen Mitarbeiter rasches Feedback f r ihre erzielten Ergebnisse erhalten e Mut Die Entwickler m ssen den Mut aufbringen neue Alternativen heranzuziehen Sie m ssen in der Lage sein bestehenden Co de wegzuwerfen und Teile neu zu entwickeln Abgeleitet aus den vier Werten nennt Kent Beck die f nf Grundprinzipien Unmittelbares Feedback Einfachheit anstreben Inkrementelle Ver nderun gen Ver nderungen wollen und Qualit tsarbeit 17 Neben diesen f nf existieren noch zehn weitere Sekund rprinzipien die st ndig Beachtung finden m ssen wenn XP angewandt wird F r die praktische Umsetzung eins Projekts gibt es urspr nglich zw lf Techniken In aufz hlender Reihenfolge sind dies das Plannungsspiel kurze Releasezyklen Metapher einfaches Design Testen Refactoring Programmieren in Paaren gemeinsame Verantwortlichkeit fortlaufen de Integration 40 Stunden Woche Kunde vor Ort und Programmierstandards Damit der Rahmen des Papers nicht gesprengt wird verweise ich f r Details zu den XP Praktiken auf Kent Beck 17 Lediglich die Techniken Plannungsspiel Pair Programming und Testen m chte ich kurz diskutie
334. st Auf umfangreiche Dokumentation und Organisation wird in XP weitgehend verzichtet 6 Quellenverzeichnis 1 B Boehm Software Engineering IEEE Transactions on Computers C 25 12 pages 1226 1241 December 1976 2 H Balzert Lehrbuch der Softwaretechnik Spektrum Verlag Heidelberg Berlin 1998 3 P Naur B Randell Software Engineering Report of a conference sponsored by the NATO Science Committee Garmisch Germany 7 11 Oct 1968 Brussels Scientific Affairs Division NATO 1969 231 pp 4 P Jalote An integrated approach to software engineering 2 Edt Springer Verlag New York Inc 1997 5 I Sommerville Software Engineering gh Edt Pearson Education Miinchen 2007 6 J Ludewig H Lichter Software Engineering dpunkt verlag Heidelberg 2007 78 7 The Standish Group International Incorporated Ihe Chaos Report 1994 Boston Massachusetts www standishgroup com sample_research chaos_1994 l php Letzter Zugriff 15 05 2007 8 S Ueberhorst Wer zu sp t testet verschleudert Geld www tecchannel de 2006 http www tecchannel de entwicklung 448205 A Letzter Zugriff 15 05 2007 9 B Boehm A View of 20 and 21 Century Software Engineering 28 ICSE may 20 28 2006 Shanghai China 10 B Boehm A Spiral Model of Software Development and Enhancement IEEE Computer Vol 21 Ausg 5 Mai 1988 pp 61 72
335. t Abstract Design und Code Inspektionen im Allgemeinen Reviews genannt haben eine lange Tradition Bereits in den 70er Jahren entwickelt wurden Reviews durchgef hrt um Fehler im Design oder der Implementierung fr hzeitig zu erkennen und zu beseitigen St ndige Reviews im Softwareentwicklungsprozess erh hten die Qualit t der Software und senkten gleichzeitig Kosten f r sp tere Fehlerbeseitigungen und Wartung Dieser Artikel legt den Fokus auf Code Inspektionen wie sie seit fast drei ig Jahren in nahezu unver nderter Form existieren und gibt einen berblick ber aktuelle Werkzeuge und Verfahren die Reviews erheblich erleichtern 1 Michael Fagan Als Vater von Code Inspektionen gilt heute der fr here IBM Mitarbeiter Michael Fagan Fagan ein gelernter Physiker beschreibt im Vorwort von Software Inspection An Industry Best Practice seine Frustration w hrend eines Software Projekts bei IBM 3 Bereits zwei Projektleiter scheiterten daran bis 1972 Fagan vom Hardwaresektor in die Softwaresparte wechselte Er beschreibt die damaligen Zust nde als schiere Katastrophe Die Softwareentwicklung wurde nach dem traditionellen Life Cycle Modell propagiert entwickelt wurden Produkte aber meist nach dem folgenden Schema e Spezifiziere einige Anforderungen e Schreibe ein wenig Code um ein Subset von den Anforderungen zu erf llen e Modul teste den Code welcher dem Subset gerecht wird e Integriere den
336. t Considered Harmful CACM 11 March 1968 pp 147 148 Osterweil 97 L Osterweil Software Processes are Software Too Revistied an Invited Talk on the Most Influential paper of ICSE 9 ACM 1997 pp 539 548 Notkin 88 D Notkin The Relationship Between Software Development Environments and the Software Process ACM 1988 pp 107 109 Lehman 87 M M Lehman Process Models Process Programs Programming Support ACM 1987 pp 14 16 Sutton 95 S M Sutton Jr D Heimbigner L J Osterweil APPL A A Language for Software Process Programming ACM Transactions on Software Engineering and Methodology Vol 4 Nr 3 July 1995 Pages 221 286 Cass 00 A G Cass B S Lerner E K McCall L J Osterweil S M Sutton A Wise Little JIL Juliette A Process Definition Language and Interpreter ACM Limerick Ireland 2000 pp 754 757 Sutton 97 S M Sutton Jr L J Osterweil The Design of a Next Generaton Process Language pp 142 158 Kruchten 03 Ph Kruchten The Rational Unified Process An Introduction third Edition Addison Wesley Amsterdam December 2003 IBM 01 Ph Kruchten What is the Rational Unified Process http www ibm com developerworks rationalNibrary content RationalEdge jan01 WhatIstheRationalUnifiedProcessJanO 1 pdf 2001 last seen 21 Mai 2007 Inspections Reviewed Sommersemester 2007 Fritz Genser 9560011 fgenser edu uni klu ac a
337. t mehr als zwanzig Personen brig bleiben w rden Alles andere h tte auch zu Problemen in der Abwicklung der Haupt vortr ge gef hrt Dass letztlich nur 17 Vollbeitr ge ausgearbeitet wurden von denen 15 hier abgedruckt sind ist allerdings doch bedauerlich Methodisch hat das enge Zeitraster mit vielen Inter ventionspunkten den Vorteil dass im Unterschied zu klassischen Seminarformen Studierende gehalten sind sich relativ kontinuierlich ber ein Semester hinweg mit der Thematik ihrer Seminararbeit zu besch ftigen Optimistische Last Minute Aktionen die sonst zu oft aber stets ohne Erfolg versucht werden sind bei einem Konferenzseminar weitestgehend ausgeschlossen Frei lich ist dieser Vorteil nur relativ Drei Ersteinrei chungen von Vollbeitr gen waren noch so skizzenhaft dass sie einen strengen Review Prozess kaum berlebt h tten Um welche es sich dabei handelt ist wohl auch den berarbeiteten Endversionen noch anzusehen Als weiteres wesentliches Element dieser Seminar form sehe ich unabh ngig vom gew hlten Seminar thema den Prozess der Peer Reviews Dieser erlaubt den Studierenden Feedback von mehr Personen als blo der Seminarleitung zu bekommen Gerade das Feedback von Peers das in vielen F llen qualitativ sehr hochstehend war wirkt stark Weiters bietet der Peer Review Studierenden die M glichkeit sich im Verfassen konstruktiver Kritik zu ben Aber er bietet den Gutachtern nat rlich auch die Cha
338. t nur vereinfacht darstellen Die bestehende Welt ist meist viel zu umfassend um sie mit bin ren Aussagen entsprechend darstellen zu k nnen So sind die meisten W rter und Aussagen die wir im allt glichen Leben verwenden nicht formell definierbar Wenn man also komplexe Sachverhalte modellieren will ist Fuzzy Logik das Mittel der Wahl Im 2 Kapitel werde ich n her in die Theorie und Praxis der Fuzzy Logik eingehen und versuchen grundlegende Verfahren anhand eines Beispiels zu erl utern Im anschlie enden Kapitel gehe ich auf die Entstehung und Entwicklung der Fuzzy Logik und auf ihre Anwendungen n her ein Im 4 Kapitel werde ich einen Ausblick auf die Zukunft in diesem Forschungsgebiet geben und mit einer Schlussfolgerung meine Arbeit abschlie en 111 2 Einf hrung in Fuzzy Logik In den Wissenschaften arbeitet man zur Darstellung von Systemen gew hnlich mit mathematischen Modellen Eine Problematik der Beschreibung von komplexen Systemen liegt darin dass oft Vereinfachungen des Systems von N ten sind um ein geeignetes Modell zu entwerfen Durch den Fortschritt in der Technik ist es uns m glich vielschichtige Systeme zu verwenden aber mit dem Umfang des Systems werden auch die konzeptionellen Anforderungen volumin ser die n tig sind um zumindest eine gewisse berschaubarkeit des Systems zu gew hrleisten Zudem gibt es auch Systeme bei denen der Entwurf eines mathematischen Modells in einem angemessenen Zeitraum
339. t sich aufgel st zu haben Wie oben bereits beschrieben tritt an diese Stelle eine neue Aktivit t Requirements Design Implementation Test Release gt Maintenance waterfall model component based model Operation amp Maintenance System Test System Integration amp Component Deployment Requirements System Design component deployment inspect Component pool Abb 2 komponentenbasierter Entwicklungsprozess vgl 12 Die Ausarbeitungen von Crnkovic 11 12 beleuchten die wichtigsten Unterschiede der einzelnen Phasen Anforderungsanalyse und Spezifikation In dieser Phase ist es wichtig zu analysieren ob die Anforderun gen mit verf gbaren Komponenten realisierbar sind Lassen sich keine entsprechenden Komponenten fin den muss die ben tigte Komponente im eigenen Haus zur Entwicklung angesto en werden oder die Anforde rung auf zur Verf gung stehende Komponenten ange passt werden Systemdesign Da Komponenten meist im Kontext von Komponentemodellen entwickelt werden ist Inter operabilit t zwischen Komponenten unterschiedlicher Technologie nur schwer zu erreichen Dies f hrt zu ei ner Einengung von Architektur und Systemdesignent scheidungen Diese Phase wird bedeutend von den Charakteristika der verf gbaren Komponenten und dem gew hlten Komponentenmodell beeinflusst auf welche der Systemarchitekt w hren
340. t und das Team nicht mehr als 15 Leute umfasst Dadurch dass Kommuni kation einen entscheidenden Wert in der Prozessphilo sophie darstellt d rfen die Entwickler nicht rtlich getrennt arbeiten XP muss in die Unternehmenssitua tion passen damit den Mitarbeitern der n tige Freiraum zur Verf gung steht Weiters ist XP nicht f r TDD Test Driven Development Projekte zu empfehlen bei welchen detaillierte Dokumentation oder ein festgelegter Systementwurf gefordert ist 5 Zusammenfassung Die Anwendung von Prozessmodellen in der IT Branche ist nicht mehr wegzudenken Prozessmodelle sind der Wegweiser zum erfolgreichen Projektab schluss Schwierig gestaltet sich allerdings die Einbindung eines Prozessmodells in ein Unternehmen Es muss die jeweilige Leistung des Vorgehensmodell betrachtet und abgewogen und f r das Projekt und die Unternehmenssituation angepasst werden Die zwei Prozessmodelle RUP und XP verfolgen das gleiche Ziel die Erstellung objektorientierter Software RUP und XP setzen auf einem iterativen Entwicklungsan satz auf In beiden Modellen findet sich der Wasser fallansatz wieder Der RUP als schwergewichtiger Prozess gleicht die Komplexit t der Softwareentwick lung durch Strukturierung des Entwicklungsprozess und Arbeitsvorbereitung aus Er ist organisationslastig und dokumentenzentriert eXtreme Programming hingegen ist ein leichtgewichtiger Prozess da hier der Fokus auf die Implementierung gerichtet i
341. t von Programmcode Diese kann unter anderem durch eine gute und vor allem einheitliche Einr ckung der einzelnen Programmzeilen erreicht werden Einzelne zusammengeh rige Bl cke sollen so auf derselben textuellen Ebene stehen also gleich viele Leerzeichen weit einger ckt sein Dies sollte sich durch die zu verwendende Top Down Entwicklung fast schon von alleine ergeben oder zumindest erheblich erleich tert werden F r funktionale Blocks wird auch die tex tuelle L nge einer Seite vorgeschlagen da hier alle strukturellen Abh ngigkeiten auf einen Blick erkannt werden k nnen 14 2 2 Auswirkungen strukturierter Program mierung Durch die Anwendung dieses Konzepts hat man mit einigen Folgen zu rechnen deren Vorz ge und Nachteile im n chsten Abschnitt genauer erl utert wer den Die Top Down Entwicklung erfordert bzw erm g licht dass zu jedem Zeitpunkt das zu entwickelnde Programm korrekt ist Eine verst ndliche nat rliche Darstellung kann und sollte so lange wie m glich bei behalten werden Die einzelnen Schritte der Verfeinerung erfordern jeweils mehr oder weniger explizite Designentschei 11 dungen Diese sind jedoch sp ter leicht nachzuvollzie hen da alle Zwischenstationen leicht dokumentierbar werden Jeder einzelne Schritt sollte im Idealfall eine korrekte Darstellung des Programms darstellen was bestimmte berpr fungen und auch Beweise zu fast jedem Zeitpunkt der Entwicklung zul sst Durch das
342. teinander verglichen werden Zus tzlich hat Arango auf Basis des Frameworks eine generische Strategie f r die Entwicklung von Domain Analysis Methoden definiert 1 In den folgenden Kapiteln werden im berblick die Weiterentwicklungen von Wiederverwendung in Dom nen betrachtet 3 Evolution von Domain Engineering Mit der intensiven Auseinandersetzung der Systementwicklung mit dem Fokus auf Dom nen Anfang 1990 stieg das Verst ndnis der Beziehung zwischen Domain Engineering und System Engineering Die drei von Arango beschriebenen grundlegenden Aktivit ten bleiben erhalten und werden in Beziehung zu System Application Engineering gesetzt Fehler Verweisquelle konnte nicht gefunden werden zeigt die Verbindung zwischen Domain Engineering und Application Engineering Dieses 2 Life Cycle Konzept zeigt den Unterschied zu der konventionellen System entwicklung Dort wird ein einziges System bei Domain Engineering werden mehrere Systeme innerhalb einer Klasse betrachtet 5 6 Domain Management Software Architecture Developmert Domain Model Domain Anaysis Application Pefomaence Specification Anaysis Based on Model Domain Domain Software Architecture Sofware System Design Based on Domain Applicaton Sonware Application Sofware Architecture Application Sofware Developmert Architecture Application Engineering Abb 1 Software Entwicklung basierend auf Domain Engineering 6
343. tellt werden pointcut moves receptions void FigureElement incrXY int int receptions void Line setP1 Point receptions void Line setP2 Point receptions void Point setX int receptions void Point setY int Hier wurde ein benutzerdefinierter Pointcut Desi gnator deklariert der alle Join Points identifiziert die durchlaufen werden wenn Methoden die Figuren be wegen k nnen aufgerufen werden 2 4 Advice Advice ist ein Konstrukt in AspectJ das ahnlich zu einer Methode ist und angibt welcher Code an den ein zelnen Join Points eines Pointcuts ausgef hrt werden soll AspectJ unterst tzt before after und around Ad vices Zus tzlich gibt es in AspectJ noch Spezialf lle des after Advice after returning und after throwing un terscheiden zwischen dem normalen Zur ckkehren aus einem Join Point und dem Werfen einer Ausnahme das einfache after Advice unterscheidet nicht zwischen diesen M glichkeiten und ist vergleichbar mit finally in Java Ein around Advice wird ausgef hrt wenn ein Join Point erreicht wurde und kann die Ausf hrung dieses Join Points verhindern 2 Die Ausf hrungsreihenfolge von Advices ist wie folgt 1 around Advices Das spezifischste around Ad vice zuerst Wird innerhalb eines around advi ce proceed aufgerufen so wird mit dem n chstspezifischsten around Advice fortgesetzt oder wenn nicht vorhanden zu Schritt 2 weiterge gangen 2 before Advices Das spezifis
344. tements are used and should be used to develop well structured programs will be looked at In this context it will become evident that the use of goto statements can have a positive effect on the program structure when used in limited ways 1 Introduction First of all I would like to start with the definition of the term goto statement A goto statement is a branching construct to transfer the control flow of a program to a specific label in an unconditional manner It depends on the programming language how such a label may look like e g a name followed by a colon or simply a line number Goto is a rather old programming construct and is a basic building block in assembler languages For being international I would like to mention that goto is a common Japanese surname as well 26 Back in the days goto s have been widely programming construct As the problems that had to be solved became more complicated the resulting programs became more complex too Dijkstra 1 mentioned that goto s will have a devastating effect on the structure of a program if used inappropriately Because of this statement a lot of rumor arose about using goto statements and many algorithms with the purpose to replace goto s with other constructs e g while case were devised 15 16 17 18 19 In 1974 Knuth and many others decided to analyze the use of goto statements again and came up with the idea to design programs in two steps In the first
345. ten Konzept vollst ndig struk turiert da der Editor keine wie auch immer gearteten Ausnahmen zul sst es k nnen lediglich bestehende Blocks erweitert werden Neben dem grafischen Teil wird automatisch auch eine textuelle Darstellung generiert die je nach Einstel lung entweder aus Pseudo Code oder sogar aus kompi lierbarem C Code besteht 10 15 In Abbildung 1 ist ein Bildschirmfoto des Editors zu sehen welches die grunds tzliche Funktionalit t an zeigt Auf der linken Seite findet sich ein Diagramm welches ausschlie lich an den einzelnen Kombinati onspunkten durch dargestellt kleine graue Kreise er weitert werden kann Dadurch wird immer ein struktu riertes Programm erzeugt Auf der rechten Seite findet sich dann die Pseudo Code Darstellung des Algorith mus oie sfc Sfc1 ioj xj File Edit View Window Help la x OSHS 4 BOQ 2 Program Name Author statement 1 while condition 1 statement 2 statement 3 Abbildung 1 Bildschirmfoto des SFC Editors 5 Resumee Zu Beginn dieser Arbeit stand eine Einf hrung was unter strukturierter Programmierung tiberhaupt zu ver stehen ist und welche Grundlagen ihre Basis bilden Von einer genaueren Beschreibung was strukturierte Programme ausmacht spannt sich der Bogen iiber den Einfluss des goto Statements bis hin zu den Vor und Nachteilen dieser Vorgehensweise An der aufgezeigten Weiterentwicklung und dem Zusammenhang mit den Programmier
346. terweil aufgreift ist die Verwendung zeitgem er Programmiertechniken und Formalismen zum Beschreiben des Softwareentwicklungsprozesses Man k nnte jetzt einwerfen dass es schon L sungsans tze gibt wie das Wasserfallmodel das Spiralmodell oder das V Modell Das sind aber nicht L sungen wie sich Osterweil das vorstellt Er schreibt sogar dass beim Versuch das Wasserfallmodel als Basis f r eine Nutzung als Prozessprogramm zu verwenden zu trivialem und unvollst ndigem Code f hrt Nach seiner Vorstellung sollten wir den Softwareprozess mehr programmieren so als ob wir ein Programm schreiben Denn beide also das Softwareprozess Programm und ein herk mmliches Programm sind Prozessbeschreibungen dienen dazu viele aber auch komplexe Informationen zu transformieren modifizieren oder zu erzeugen Mit Hilfe des Softwareprozess Programmes sollte man grob gesprochen alle Daten sammeln diese durch Bearbeitung der Werte und Daten in Software Objekte umwandeln und durch das Verbinden dieser Objekte wiederum ein fertiges Softwareprodukt herausbekommen Bei einer Applikation k nnen die Daten klein und berschaubar aber auch gro und komplex sein Bei einem Softwareprozessprogramm werden die einzugebenden Daten vorwiegend komplexer Natur sein Aber in beiden F llen geht es laut Osterweil um das gleiche Ziel Bei Applikationen ist die L sung des Problems also die Beschreibung des Prozesses der ausf hrbare Code Betrachtet m
347. the newest compiler with the version 4 2 0 First of all I would like to mention that the use of goto s in the GNU C compiler is similar to the patterns already described in the GNU Linux section 0 60 0 55 0 50 0 45 0 40 0 35 0 30 0 25 0 20 0 15 0 10 0 05 0 01 1 0 0 2 0 0 2 3 99 2 4 34 2 5 75 2 6 10 2 6 21 09 91 03 94 06 96 03 00 01 06 07 03 12 04 04 07 Kernel release and release date MM YY 0 00 Diagram 1 Goto s in the GNU Linux kernel There are also cleanup processes exceptions as well as inner loop exits present in the source code But there are also other usages for goto s like loop constructs The only example I would like to give here is a part of the gcc scanner which utilizes goto s as a recovery mechanism illustration3 initial label to return back to in case a new line is read retry Gel nr c skip spaces fp c if c n source lineno lineno goto retry read an integer token and exit if ISDIGIT c ce INT_TOKEN goto done exit label done return Illustration 3 A part of the gcc scanner This code construct is very likely to be generated by a compiler compiler and is then filled with meaningful code The examination of the amount of goto s used in the gcc see diagram 2 showed that there are more than twice as much goto s in the GNU Linux kernel than there are in t
348. ther as tools can not even tell if they are in a chain or not There is one major difference though comparing the UNIX pipeline to the general pipes and filters architecture In UNIX we have a linear sequence of filters with just one input and one output per tool as shown in Figure 2 In this sense we have a special case which is mentioned in the architecture description as pipelines or pipelined pipes and filters gt Filter gt Filter gt Filter e Figure 2 Pipeline The advantages gained from using UNIX pipes or developing a system based on the pipes and filters architecture are thus pretty much the same 44 e First of all it makes it easier for a programmer to understand the I O behavior by recognizing the overall output as a combination of the individual filters applied This makes it easier to develop and test such a system Testing is further enhanced by the ability to look at the preliminary output after any filter and check if it follows the specification until then e Another advantage is the fact that this architecture greatly supports reuse of the different filters components used This is especially immanent when using UNIX where the same tools are used over and over again to perform in totally different overall activities e Since every filter is independent of any other a system following the pipes and filters architecture can be easily maintained and enhanced Any component can be replaced by an improved vari
349. tiert in einem internen Release der Software und treibt die Entwicklung schrittweise voran Phasen Das Modell gliedert sich in die vier Phasen Beginn engl Inception Ausarbeitung engl Elaboration Konstruktion engl Construction Auslieferung engl Transition Den Jede Phase kann wiederum aus mehreren Iterationen bestehen und liefert verschiedene Ergebnisartefakte Am Ende jeder Phase wird die n chste Phase geplant und ein bestimmter Meilenstein muss erreicht sein Nach Kruchten 11 haben die vier Phasen unterschied liche Kapazit ten in Bezug auf Aufwands und Zeitanteil Phase Zeit Aufwand Beginn 10 5 Ausarbeitung 30 20 Konstruktion 50 65 Auslieferung 10 10 Tab 1 Relatives Gewicht der Phasen Ziel der Beginnphase ist es eine Machbarkeitsstudie zu entwickeln und sich ber Projektumfang und Randbedingungen Gedanken zu machen Es werden die kritischen Anwendungsf lle erfasst und Projektri siken fr hzeitig identifiziert F r die wirtschaftliche Betrachtung werden Kosten und Zeitabsch tzungen angestellt Als Ergebnisartefakte liefert die Beginnpha se eine Produktvision ein Glossar eine Risikenliste ein berblicksmodell der Anwendungsf lle einen groben Projektplan und einen Business Case Nach Abschluss dieser Phase ist der Lifecycle Objective Meilenstein erreicht welcher auf spezielle Kriterien hin evaluiert wird vgl 13 In der Ausarbeitungsphase gilt es die
350. tion Fast Facts about Microsoft 2007 http www microsoft com presspass insidefacts_ms mspx Stand 02 Mai 2007 54 7 Sun Microsystems Company Profile 2007 http www sun com aboutsun company index jsp Stand 02 Mai 2007 8 SAP The World s Largest Business Software Company 2007 http www sap com company index epx Stand 02 Mai 2007 9 Google Unternehmensprofil 2007 http www google at intl de corporate Stand 02 Mai 2007 10 Erich Gamma Richard Helm Ralph Johnson John Vlissides Design Patterns Elements of Reusable Object Oriented Software Addison Wesley Professional Computing Series Addison Wesley Reading Mass 1994 11 Microsoft Cooperation Patterns and Practices Developer Center http msdn2 microsoft com de de practices default aspx Stand 06 Mai 2007 12 E Andres Lessons learned in an industrial software lab IEEE Software 09 93 1993 pp 58 61 13 Microsoft Corporation Team http msdn2 microsoft com de de teamsystem Stand Mai 2007 System 10 14 IBM Rational Delivery Platform http www 128 ibm com developerworks platform Stand 10 Mai 2007 15 vereinfachte Darstellung von http www ibm com deve loperworks platform Fig 2 Stand 10 Mai 2007 16 vereinfachte Darstellung von http www microsoft com germany msdn vstudio products teamsystem team defau It mspx Stand 10 Mai 2007
351. tiszenarien zu be schreiben Die Anderen welche auch kalt cold genannt werden unterst tzen Iterationen und Verzweigungen 1 Im Vergleich zu MSCs bieten LSCs eine viel ausdrucksst rke re Art visuell Anforderungen im Bezug auf das Verhalten darzustellen Folgende Aussage von David Harel untermau ert den Stellenwert von LSCs im Kontext zur modellgetrie benen Entwicklung Because their expressive power is far greater essentially that of XUML itself LSCs also make it possible to start looking more seriously at the dichotomy of reactive behaviour the relationship between the interobject requirements view and the intraobject system model 6 4 2 Verifikation und Synthese Zwischen den formalisierten Anforderungen und dem System Modell existiert eine automatisierbare Verbindung Auf der einen Seite kann durch einen Transformationsschritt das aus Klassen und Zustandsdiagrammen bestehende Modell aus Bs gibt einen Standard fiir MSCs welcher auf Empfehlung der ITU herausgegeben wurde ITU TS Recommendation Z 120 Message Sequence Chart MSC ITU TS Geneva 1996 Play out scenarios and verificatio Play in scenarios Requirements LSCs or temporal logic gt Methodologies and synthesis Code generation System model Model code association XUML or SA SD Figure 2 Der Traum der Softwareentwicklung nach David Harel Von einer komfortablen Anforderungser fassung
352. tsumoto geschaffenen Strukturen eine offensichtliche Verbindung zur Ge genwart Diese Zusammenh nge werden in der nach folgenden Arbeit durch Untersuchung von aktuellen Tools Techniken und Standards auf Abh ngigkeiten Zusammenh nge und Verbesserungen gegen ber den damals geforderten Abl ufen dargestellt 1 Einleitung Matsumoto stellt in seinem Artikel A Software Factory An Overall Approach to Software Production 1 als Mitarbeiter der Toshiba Corporation in Tokyo Japan bereits im Jahr 1987 einen schl ssigen und ber greifenden Ansatz zur Softwareproduktion in gro em Rahmen vor Er sieht dabei der japanischen Kultur entsprechend Qualit t und Produktivit t als die ziel vorgebenden Faktoren f r seine Vorstellung des Soft wareentwicklungsprozesses Von den vielf ltigen Kon zepten die gro teils den Sprung in die aktuelle Infor matik in unterschiedlichen Formen erreicht haben werden einf hrend die zentralen Ans tze kurz vorge stellt Anschlie end wird um das bestehende Bild ab zurunden anhand von Zahlen eine Vergleichbarkeit der damaligen Verh ltnisse mit heutigen Gegebenheiten 47 gepr ft Daraufhin werden die Konzepte Reuse und eine technische Workbench als Basis f r den Entwick lungsprozess herangezogen um die Entwicklung und Verwendung der damaligen berlegungen in der Ge genwart zu beleuchten 1 1 Das Gesamtbild einer Software Factory Yoshihiro Matsumoto beschreibt seine Erfahrunge
353. tungskosten und die Ausdehnung der Maschinenzeit Die Beschreibung der Regeln in Fuzzy Systemen in den meisten F llen simpler beziehungsweise sind oft auch weniger Regeln notwendig Dadurch gelingt die Ausf hrung dieser Systeme schneller als bei konventionellen Systemen Des Weiteren erreichen Fuzzy Systeme meist eine hohe Robustheit und eine ganzheitliche Kostenreduzierung In Gesamtheit f hren alle diese Eigenschaften zu einer besseren Leistung des Systems 2 Trotz der Vorziige von Fuzzy Logik ist die klassische Logik ein m chtiges Werkzeug und eignet sich vor allem zur L sung von simplen Problemen w hrend Fuzzy Logik komplexe Probleme gut l sen kann oder auch Anwendungen unterst tzt die unsichere Informationen verarbeiten In diesem Sinne stehen Fuzzy Logik und klassische Logik nicht im Konkurrenzkampf zueinander Gleichfalls wie die Relativit tstheorie von Einstein das Gravitationsgesetz von Newton erweitert ist die Fuzzy Logik als eine Erweiterung des bivalenten Systems zu sehen 6 Referenzen 1 R Kruse J Gebhardt F Klawonn Fuzzy Systeme B G Teubner Stuttgart 1993 118 2 T Munakata Y Tani Fuzzy Systems An Overview Communications of the ACM Vol 37 3 M rz 1994 pp 68 76 3 L A Zadeh Fuzzy Logic JEEE Computer Society Vol 21 4 April 1988 pp 83 93 4 L A Zadeh Commonsense Knowledge Representation Based on Fuzzy Logic IEEE Computer Vol 16 10 Okto b
354. twa bei Systemen in denen es auf Echtzeit ankommt eher andere Methoden vorzieht Eine andere Strategie w re die Maximum Methode 6 Diese gewinnt den scharfen Wert aus dem Maximum der Zugeh rigkeitsfunktion Dies f hrt zu Problemen wenn es mehrere Maxima gibt was oft der Fall ist Wir entscheiden uns aus Einfachheitsgr nden f r die Links Maximum Methode die das linkste Maximum als scharfen Wert w hlt Beispiel Berechnung des Befehlwerts Nun soll der scharfe Befehlwert abh ngig von den zwei Eingangswerten berechnet werden Es wird eine Temperatur von 20 Grad Celsius und weiters eine Anzahl von zehn Personen gemessen Nun werden die Aktivierungsgrade dieser Messwerte bestimmt Variable Wert Grad Term T 20 Celsi 0 75 angenehm emperatur elsius 0 25 kalt 0 25 mittel Personen 10 075 viele Die Regeln werden nun mit Hilfe der Min Max Inferenz Methode aufgel st Beachte Min Max Inferenz Methode bei UND wird der kleinere Wert genommen und der gr ere Wert bei ODER L sen wir etwa die Regel R4 auf Die Temperatur ist mit Grad 0 75 angenehm und mit Grad 0 25 mittel Da in der Regel eine UND Verkn pfung ist nimmt man den kleineren Wert als Grad f r diese Regel Diesen Vorgang der Aufl sung der Regeln nennt man auch approximatives Schlie en Regel Wenn Teil Grad Dann Teil R1 0 25 0 25 Ventil zu R2 0 0 Ventil offen R3 0 75 AND 0 0 Ventil zu R4 0 75 AND025
355. twareentwicklungen aufzuzeigen Es wird kurz generell auf den Problembereich Re quirements Engineering eingegangen um die Motiva tion der Anwendung einer Informationsmodellierung zu verdeutlichen Dann wird auf die Aspekte des world modeling eingegangen gefolgt von einer kur zen Vorstellung einer von Greenspan entworfenen Sprache zur Wissensrepr sentation dem RML Weiters m chte ich heutige Ans tze bez glich Wissensrepr sentation und modellierung im Bereich Software En gineering erl utern Im Speziellen geht der Artikel ein auf die Wandlung vom objektorientierten Ansatz aus dem auch RML entstand hin zum zielorientierten Auch der Einfluss der K nstlichen Intelligenz durch den Einsatz von Ontologien wird behandelt 1 Einleitung In der Einleitung in meine Arbeit m chte ich kurz generell Bezug auf den Problembereich des Require ments Engineering RE im Rahmen der Softwareent wicklung nehmen um die Motivation von Anforde rungsmodellen und Wissensrepr sentation aufzuzei gen Im zweiten Abschnitt wird das Prinzip der Infor mationsmodellierung erl utert bzw der Einfluss des Bereichs der K nstlichen Intelligenz deutlich gemacht In Abschnitt 3 wird eine von Sol J Greenspan entwi ckelte Anforderungsmodellierungssprache als darstel lendes Beispiel pr sentiert Abschnitt 4 wird den ber gang vom objektorientierten Ansatz aus den 80er Jah ren hin zum zielorientierten Ansatz beschreiben Ab schnitt 5 besc
356. uktlinien aus der Sicht der Marketing Strategie kommt und die Unterschiede der Produkte als Features betrachtet werden 5 Interessant in diesem Zusammenhang ist dass schon Parnas um 1976 von Programmfamilien gesprochen hat 14 Doch erst Mitte der 90er wurden konkrete Konzepte entwickelt und eingesetzt Der Einsatz von Domain Engineering um diese Produktvarianten zu realisieren hat Auswirkungen auf die Organisation und Gesch ftsprozesse des Unternehmens nicht nur auf die technischen Aspekte 12 15 16 Die Motivation fiir den Einsatz von Produktlinien liegt zum Ersten in der Reduktion von Entwicklungskosten Zu Beginn der Umsetzung gibt es zwar h here Anfangskosten aber je mehr Produktvarianten entwickelt werden desto geringer werden die Gesamtkosten im Vergleich zu herk mmlichen Entwicklungsstrategien bei denen fertige Systeme an neue Kunden angepasst werden 7 Abb 2 Wirtschaftlichkeit von SPL verdeutlicht dies Accumulated 3 7 J Single Systems Costs gt System Family Break Even OH Le Pont S enan x 2 Lower Costs Up Front Sy gt per System Investment Number of Different Systems approx 3 Systems Software Engineering Abb 2 Wirtschaftlichkeit von SPL 7 Ein weiterer Grund ist die Reduktion der Zeit f r eine Markteinf hrung einer Produktvariante Durch die gemeinsame Basis der Produktlinie k nnen schneller neue Produktvarianten erst
357. ung Eingabe Ausgabe Synchronisierung sowie Interprozesskommunikation realisiert Diese Abstraktion von der Funktionalit t 32 der einzelnen Komponenten erm glicht ein besseres Verst ndnis des Gesamtsystems ohne verstehen zu m ssen wie die Komponenten im Detail arbeiten Im Folgenden werden kurz die Schichten beschrieben aus denen sich das THE System zusammensetzt beginnend bei der untersten Schicht The operator Input output management Layer5 Layer 4 Layer 3 Layer 2 Operator process communication Memory and drum management Processor allocation and multiprogramming Layer 1 Layer 0 Abbildung 1 Die Schichten des THE Multipro gramming Systems Schicht 0 Die unterste Schicht ist fiir die Prozes sorzuweisung zust ndig Hier werden Prozessorzeiten an Prozesse zugeteilt Es wird sichergestellt dass kein Prozess einen Prozessor f r sich alleine beansprucht Priorit tsregeln stellen sicher dass bestimmte Prozes se wie Eingabe und Ausgabeprozesse bevorzugt wer den Auf dieser Ebene geschieht die erste Abstraktion Prozesse die ber dieser Schicht liegen m ssen sich nicht mehr um die tats chliche Anzahl der Prozessoren k mmern Schicht 1 Diese Schicht nennt Dijkstra Seg ment Controller Hier geschieht die Speicheverwal tung Der Inhalt einer Speicherseite wird Segment ge nannt Es gibt eine Unterteilung zwischen Core Seg ments die sich im Hauptspeicher befinden und Drum Segment
358. ung zwischen einfachen und schweren Fehlern Einfache Fehler haben keine gr beren konomischen Auswirkungen auf das Projekt und sind normalerweise lokal begrenzt Schwere Fehler haben eine dramatischere Auswirkung auf das Projekt sollten diese nicht erkannt und entfernt werden Sie k nnen unter Umst nden das gesamte Projekt gef hrden Diese Art von Defekt zieht hohe Kosten f r die Beseitigung in vorausgegangen Dokumenten nach sich Typische Vertreter von schweren Fehlern sind falsch implementierte Benutzeranforderungen Die NASA erweiterte in Ihrem Software Formal Inspection Standard die Kategorisierung eines Fehlers um einen Typ Data Requirements compliance Interface Logic Standards compliance Performance und Readability 6 Sie trifft damit gleichzeitig Aussagen ber die Qualit t des Codes sowie Hilfestellung beim Entfernen des Mangels Dies ist vor allem wichtig wenn ein gro er Personenkreis an dem Projekt Mit dieser Typisierung widerspricht die NASA Gilb und Graham die eine breitere Klassifikation f r unn tig halten Schlie lich w re eine Diskussion so Gilb und Graham eine reine Zeitverschwendung da der Fehler sowieso verbessert werden muss Dennoch beharren viele Firmen auf eine zus tzliche Einteilung da verschiedene Fehlergruppen nach dem Review von verschiedenen Spezialisten erledigt werden k nnen 2 3 Dauer und Follow Up von Inspektionen Die Dauer eines Inspektionsmeetings h ngt von vielen
359. unvollst ndige Methodiken 18 eXtreme Program ming wird den prozessorientierten Methodiken zugeordnet da es sich stark auf einen iterativen Prozess konzentriert und somit in diesem Paper einen passenden Vertreter agiler Methodiken darstellt Im Gegensatz zu herk mmlichen iterativen Prozessen wie beispielsweise dem Spiralmodell erlaubt XP extrem kurze Iterationsschritte Pro Iterationsrunde werden Anforderungen ermittelt der Entwurf wird laufend verbessert Systemteile werden implementiert und getestet Bei XP werden jedoch die prozessspezifischen Techniken in jeder Aktivit t angewandt Beispielswei se werden die Anforderungen im so genannten Planungsspiel ermittelt Nach dem Motto der agilen Werte stellt XP die Entwickler und den Kunden in den Mittelpunkt Im Zentrum von XP wird das Program mieren als Schl sselt tigkeit dargestellt wodurch die Methodik eine Reihe konkreter Praktiken f r die Implementierung bietet Kent Beck definiert eXtreme Programming als eine leichte effiziente risikoarme flexible kalkulierbare exakte und vergniigliche Art und Weise der Softwareentwicklung 17 In Zusammenarbeit mit Ward Cunningham und Ron Jeffries entwickelte Kent Beck 1996 die neue Vorgehensweise XP Ausl ser f r die Entwicklung war ein Projekt beim Chrysler Konzern welches am Rande des Abbruchs stand Das Wort eXtreme in XP bedeutet dass alle Prozessaktivit ten in extremer Weise stattfinden Wenn beispielsweise Testen gut i
360. ur Folge hatten Durch die rasante vor allem aber auch preisliche Ent wicklung der physischen Bauteile gerieten die Pro grammierer bald in ein Dilemma Die Rechner der neu en Generation waren viel leistungsf higer aber auch um einiges komplizierter zu programmieren Die resul tierenden Programme wuchsen zu regelrechten Soft warepaketen heran weil gleichzeitig immer mehr Funktionalit t bereitgestellt werden konnte und sollte Programmierung drehte sich nicht mehr darum kleine St cke von Software m glichst effizient nieder zuschreiben Sie drehte sich darum immer komplexere Systeme in immer k rzerer Zeit zu produzieren Die Herausforderung und Schwierigkeit bestand nun eher darin die Komplexit t der entstehenden Systeme zu verarbeiten und die Vielzahl an unterschiedlichen T tigkeiten zu verwalten Deshalb wurde es nun notwendig Software so zu produzieren dass sie von Anfang an m glichst fehler frei ist Dies ist nachweislich um einiges kosteneffizien ter als im Nachhinein Unmengen von Bugs auszumer zen Die so entstandene Krise in der Softwareindustrie schrie f rmlich nach einem Verfahren mittels dem m glichst effizient viel korrekter Code produziert wer den k nnte 06 N Wirth bezeichnet Effizienz sogar als wertlos wenn man sich auf die Programme und den enthaltenen Code nicht verlassen k nne F r ihn stehen reliabili ty von Software und die F higkeit gro e und kom plexe Programme organisieren
361. urch Abstraktion ein Problem und seine L sung besser zu verstehen und einzugrenzen e Management der Struktur und Anderungen Die w hrend der Softwareentwicklung erstellten Produkte m ssen verwaltet werden Diese Produkte werden immer wieder ver ndert Diese nderungen m ssen verwaltet und dokumentiert werden Und man muss wissen von wem sie gerade ben tigt oder durchgef hrt werden Weitere Schl sselfunktionen des RUP e Use Case getriebene Entwicklung In der Objekt orientierten Softwareentwicklung sind Use Cases weniger gebr uchlich jedoch sind von 84 sie eine wichtige Br cke zwischen Anforderung und Test oder Design Im RUP sind Use Cases die Basis f r den Rest des Entwicklungsprozesses e Prozess Konfiguration RUP ist ein Prozess Framework man sollte bevor man ein Projekt beginnt RUP so anpassen das man in k rzest m glicher Zeit eine h chst m gliche Qualit t bekommt Wie l uft nun der RUP ab Phases Disciplines Business Modeling Requirements Analysis amp Design Implementation Test Deployment Configuration amp Change Mgmt Project Management Environment Iterations Abbildung 2 Prozessstruktur Quelle IBM 01 Der Ablauf einer Iteration wird in Abbildung 2 gezeigt Der horizontale Ablauf repr sentiert die Zeit und zeigt die einzelnen Abschnitte einer Iteration Vertikal sieht man die einzelnen T tigkeitsbereiche mit der Wichtigkeit zum jeweiligen Zeitpunkt im Ab
362. urchgegangen Informelle Inspektionen laufen wesentlich flexibler ab da es keine fixen Zeitpl ne oder Aufgabenlisten gibt siehe auch Kapitel 2 4 Formale Inspektionen sind normalerweise effizienter bei der Fehlersuche informelle k nnen fters stattfinden 88 2 1 Team Ein Inspektionsteam besteht blicherweise aus vier Personen dem Moderator Designer Programmierer und einem Tester Jedes Teammitglied hat das Finden von Fehlern w hrend des Vorbereitungsprozesses und der stattfindenden Meetings zur Aufgabe Der Moderator ist die Hauptperson bei einer erfolgreichen Inspektion Er sollte m glichst ein erfahrener Programmierer sein muss aber zwangsl ufig nicht ein Experte im zu berpr fenden Dokument sein Es k nnen durchaus positive Synergien entstehen wenn der Moderator nicht an dem Projekt beteiligt ist Gilb und Graham gehen noch weiter und definieren die urspr ngliche Rolle des Moderators von Fagan neu er wird zum Inspektionsleiter 2 Er muss nicht nur ein Treffen moderieren sondern es planen und organisieren Er ist gleichzeitig Betreuer Lehrer und Administrator Ein Manager Freund und Unterst tzer der restlichen Inspekteure Die urspr nglichen Aufgaben wie zum Beispiel die Weitergabe von Inspektionsresultaten innerhalb eines Tages geh ren selbstverst ndlich auch dazu Der Designer ist zust ndig f r das Programmdesign Er erkl rt im Allgemeinen welcher Bereich gerade berpr ft wird In weiterer Fo
363. ussage entweder falsch oder wahr sein muss Dieses bivalente Logiksystem setzte sich wohl auch aufgrund seiner Klarheit durch obwohl es ebenso damals bereits Ans tze f r mehrwertige Logik gab Etwa sprach Platon der Lehrer von Aristoteles von einer dritten Region zwischen wahr und falsch Im 19 Jahrhundert entwickelte George Boole die nach ihm benannte Algebra und Mengenlehre wodurch es endlich m glich wurde jenes Logiksystem auch mathematisch zu behandeln Bereits Anfang des 20 Jahrhunderts schlug Jan Lukasiewicz jedoch ein trivalentes Logiksystem mit den Werten wahr m glich und falsch vor welches jedoch kein gro es Interesse erfahren durfte 1965 ver ffentlichte Lotfi Zadeh die erste Arbeit 8 in Bezug auf Fuzzy Logik Es ist dabei unbedingt zu erw hnen dass er sich innerhalb eines kurzen Zeitraums von der pr zisen Regeltechnik zur Fuzzy Logik zuwandte die Unklarheit zul sst 9 Er bezeichnete den Ursprung seiner Idee sp ter 10 als 115 das Prinzip der Unvereinbarkeit engl principle of incompatibility As the complexity of a system increases it becomes more difficult and eventually impossible t0 make a precise statement about its behavior eventually arriv ing at a point of complexity where the fuzzy logic method born in humans is the only way to get at the problem Dieses Prinzip besagt dass hohe Pr zision nicht kompatibel ist mit hoher Komplexit t hnlich dem menschlichen Denken erm glicht Fuzzy
364. utomatisierte Synthe se in Programmiersprache der dritten Generation wie z B C oder Java angewandt werden Nennenswert und durch aus mit Potenzial verbunden ist die Tatsache dass nicht nur Sourcecode sondern auch eine Hardwarebeschreibungs sprache das Ergebnis einer solchen Transformation sein kann 6 7 2 1 Modellierung der Verhaltenssemantik mit Zustandsdiagrammen Um das Verhalten einer Anwendung ber die gesamte Lauf zeit hinweg abzubilden wurden in 7 zwei wichtige Punkte identifiziert die Initialisierung am Beginn und die Dynamik w hrend der Laufzeit Diese Aufgaben werden folgend dar gestellt e Bei der Initialisierung werden aus der Komponenten und Klassenstruktur die von Beginn an existierenden Instanzen angelegt und in Verbindung gesetzt Bei Be ziehungen mit festen Kardinalit ten bzw bei Kennt nis der Ober und Untergrenzen werden die Informa tionen zur Instanzierung aus dem Klassendiagram ge wonnen Bei nicht festen numerischen Kardinalit ten muss diese Information auf eine andere Art abgebildet werden Die Autoren entschieden sich f r Initialisie rungsskripten welche einmalig am Beginn der Laufzeit ausgef hrt werden und die Instanzierung der n tigen Objekte nach manuellem Editieren ansto en e Zustandsdiagramme beschreiben wie Objekte mitein ander kommunizieren und interagieren Des Weiteren wird mit ihnen auch das objektinterne Verhalten dar gestellt Zur Modellierung der Dynamik w hrend der
365. werden Compiler optimieren Code und Entwicklungsumgebungen helfen dem Programmierer bei seiner Arbeit 3 1 PSP Der Pers nliche Softwareprozess PSP wurde 1995 von Humphrey eingef hrt 19 Dabei handelt es sich um eine Ansammlung von Methoden und Techniken zur Verbesserung der individuellen Projektplanung und kontinuierlichen Verbesserung der eignen Arbeiten Ziel ist es die pers nliche Effektivit t zu erh hen genauere Aufwandssch tzungen f r Projektteile geben zu k nnen und seine Arbeit besser zu planen Dabei ist jeder aufgefordert seine eignen Aufzeichnungen in allen Bereichen seiner Arbeit zu f hren Aus diesen lassen sich St rken und Schw chen ablesen die man im individuellen Prozess f rdert beziehungsweise zu vermeiden lernt Ein Beispiel hierf r ist die Selbstinspektion der Softwareentwickler ist angehalten seine Arbeit st ndig zu inspizieren und begangene Fehler festzuhalten Aus diesen Aufzeichnungen k nnen bestehende Makel abgelesen und gegebenenfalls durch Schulungen in Zukunft vermieden werden Ein Nachteil vom PSP ist der enorme administrative Aufwand jedes Einzelnen Studien haben jedoch gezeigt dass der Einsatz von PSP langfristig die Nachteile berwiegt 3 2 Entwicklungsumgebungen Entwicklungsumgebungen oder IDE Integrated Development Environment sind grafisch unterst tzte Anwendungen in denen der Benutzer seinen Code programmiert IDEs gibt es inzwischen f r viele Programmiersprachen Die
366. werte in linguistische Messwerte geschieht anhand von Informationen aus der Wissensbasis genauer Datenbasis die w hrend der Modellierungsphase erstellt wurden Diesen Vorgang nennt man Fuzzifizierung Als N chstes werden mit Hilfe der nun linguistischen Messwerte die Regeln entsprechend aufgel st Die Regeln sind ebenso Teil der Wissensbasis genauer Regelbasis und werden ebenso w hrend der Modellierungsphase konzipiert Anschlie end m ssen die unscharfen Befehlswerte wieder in scharfe Zahlen transformiert werden da die Einstellgr en f r den Regler scharf sein m ssen Diesen Vorgang nennt man Defuzzifizierung Aufstellen der Wissensbasis Datenbasis Damit scharfe Zahlen in linguistische Werte abgebildet werden k nnen muss man die linguistischen Variablen und deren linguistischen Werte bestimmen Das Konzept einer linguistischen Variablen kommt aus unserer Alltagssprache Dadurch werden Worte bezeichnet deren Wertebereich durch unscharfe Mengen so genannte linguistische Werte abgedeckt werden 3 Dieser Vorgang wird als Fuzzy Zerlegung oder Fuzzy Partition bezeichnet Au erdem ist es m glich die Auswahl zu erweitern und zwar um Modifikatoren Quantoren Wahrscheinlichkeiten und M glichkeiten Dies ist f r Systeme geeignet deren verbale Beschreibung in vielerlei Hinsicht sehr unscharf ist so dass dieses Wissen nur so korrekt formuliert werden kann Dies soll am Beispiel der linguistischen Variable Temperatur v
367. wird durchge f hrt damit das zuvor in diesem Artikel vorgestellte Thema auch durch direktes Anwenden n her gebracht wird Zun chst jedoch einige Grundbegriffe sowie Defini tionen auf welche der Artikel im Weiteren aufbaut 1 2 Grundbegriffe und Definitionen 2 1 Fuzzy Logik Die nachfolgenden Definitionen bilden die Basis f r Computing with Words Sie wurden im Wesentlich in 2 erkl rt Ein Fuzzy Set wird durch eine Membership Funktion definiert Dabei wird in mehrere Klassen un terschieden welche jede durch eine Funktion f x be schrieben wird 9 10 Diese Funktion liefert f r ei nen konkreten Wert im Intervall 0 1 die Zugeh rig keit dieses Wertes zur jeweiligen Klasse Ein kurzes Beispiel wird dies erl utern H Klein Mittel Gro 0 6 Gr e 185cm Abb 1 Membership Funktionen In Abbildung 1 werden 3 Membership Funktionen mit den 3 Klassen Klein Mittel und Gro auf die Fuz zy Variable Gr e dargestellt Zieht man nun einen Wert von 185cm f r die Gr e heran so erh lt man aus dem Diagramm die Fuzzy Werte 0 f r Klein 1 f r Mit tel und 0 6 f r Grof Als n chsten Schritt gehen wir nun n her auf die Operationen und die vorher erkl rten Membership Funktionen ein da diese in Kapitel 4 noch ben tigt werden Der Vereinigung zweier Funktionen wird der Max Operator zugesprochen Der Max Operator ben tigt 2 oder mehrere Funktionen damit anschlie end das in Abbildung 2
368. ww ecma international org publications files ECMA ST Ecma 334 pdf 11 C reference Retrieved on 11 05 2007 from http www cppreference com keywords goto html 12 Visual FoxPro reference Retrieved on 11 05 2007 from 24 http msdn microsoft com library default asp url ibrary en us dv_foxhelp9 html 6dcddc3f 9944 4ad8 be2f 003610af616a asp 13 L Marshall and J Webber 2000 Gotos Considered Harmful and Other Programmers Taboos In A F Blackwell amp E Bilotta Eds Proc PPIG 12 pp 171 180 14 E W Dijkstra 1972 The humble programmer Communications of the ACM Vol 15 No 10 pp 859 866 15 T D Vu 2007 Semantics and applications of process and program algebra Master Thesis University of Amsterdam Supervisor Prof J W Zwemmer pp 135 188 16 E Ashcroft and Z Manna 1972 The translation of go to to while programs Information Processing Vol 71 North Holland Amsterdam pp 250 255 17 W W Peterson T Kasami and N Tokura 1973 On the capabilities of while repeat and exit statements Communications ofthe ACM Vol 16 No 8 pp 503 512 18 L Ramshaw 1988 Eliminating go to s while preserving program structure Journal of the ACM Vol 35 No 4 pp 893 920 19 P Morris R A Gray and R E Filman 1997 Goto removal based on regular expressions Journal of Software Maintenance Research and Practice Vol 9 No 1 pp 47 66
369. zt werden diese Punkte noch einer Members hip Funktion zugeordnet Der vollst ndige Vorgang kann aus Abbildung 5 entnommen werden Kalt Warm Abb 5 Vorgang der Datengewinnung 3 2 Ableitung von Fuzzy Regeln anhand des Beispiels medizinischer Diagnose Wie im vorherigen Kapitel gezeigt wurde kann man aus einer Menge von Punkten zuerst in zwei Schritten granulare Mengen bilden und anschlie end diesen Mengen Membership Funktionen zuweisen Um nun aber mit W rtern rechnen zu k nnen ben tigt es drei Schritte 1 Die Umwandlung konkreter Werte in granula ren Mengen sowie die Zuweisung zu Be zeichnungen 2 Verarbeitung dieser W rter 3 R ckwandlung des Ergebnisses auf konkrete Werte Schritt 1 wurde bereits erkl rt Dieser bildet den Ausgang f r den 2 Schritt Die Abfolge wird in diesem Kapitel anhand der Medizin n her erl utert Der letzte Punkt wird bei Bremssteuerung Kapitel 4 n her dar gestellt Ein wichtiger Anwendungsfall von Computing with Words ist die medizinische Diagnose 11 Hierbei handelt es sich einerseits um einen stark zahlenlastigen Input Temperatur Herzfrequenz Blutwerte jedoch wird f r die Diagnose selbst mit W rtern gerechnet Dies liegt einfach im Denken des Menschen Der Arzt denkt sich Der Patient hat hohe Temperatur die Blut werte sind in Ordnung der Blutdruck ist gering usw Daher muss der Patient an einer bestimmten Erkran kung leiden Wie im 1 Schritt erkl
370. zu k nnen im Zentrum von strukturierter Programmierung 01 2 Strukturiertes Programmieren 2 1 Grundlagen Es gibt viele unterschiedliche Sichtweisen von strukturierter Pogrammeriung aber auch einige Grund prinzipien die von mehreren Vertretern dieses Kon zepts gemeinsam vorgeschlagen werden und auf wel che im Folgenden genauer eingegangen wird 2 2 1 Zielsetzung Das grunds tzliche Ziel von strukturierter Programmierung ist das Erarbeiten von korrektem Programmcode mittels einiger mehr oder weniger einfacher Regeln Es handelt sich nicht um eine definierte Vorgangsweise und es gibt auch kein 10 Rezept nach dem man vorzugehen hat Bei struktu rierter Programmierung handelt es sich um ein Kon zept das wenn man sich daran h lt bestimmte das Erlangen bestimmter Vorz ge und die Vermeidung bestimmter Nachteile verspricht Diese werden im n chsten Kapitel n her erl utert 01 06 14 2 2 2 Vorgangsweise Als grundlegende Vor gangsweise wird die Top Down Entwicklung von Pro grammcode herangezogen Das bedeutet dass man von einer pr gnanten aber korrekten Beschreibung der Funktionalit t ausgehend diese abstrakte Beschreibung iterativ erweitert Die Erweiterungen beschreiben eine Eigenschaft einen Teil der Funktion oder eine Design entscheidung auf der aktuellen Stufe Der Vorgang wird immer genauer so lange wiederholt bis die Bl cke zum Schluss durch echte Codezeilen ersetzt werden k nnen
371. zy Logik die Regelung zum einen in industriellen Systemen und zum anderen in Konsumg tern Doch das sollte sich ndern Man entdeckte Fuzzy Logik ebenso f r die Automatisierungstechnik f r die Unterhaltungselektronik und f r die Steuerungselektronik So eroberte diese Theorie viele unterschiedliche Bereiche deren Anwendungen mit Hilfe von Fuzzy Logik eine bessere Qualit t und Leistung aufwiesen Durch die immer h here Komplexit t von Fuzzy Logik Systemen wurde es immer wichtiger Richtlinien zur Entwicklung von Systemen zu erstellen Dabei will ich die Entwicklungsmethodik engl development methodology vorstellen Sie umfasst f nf Phasen Design 1 Spezifizierung der linguistischen Variablen 2 Definition der Struktur der Schlussfolgerungen 3 Formalierung der Fuzzy Regeln Debugging 4 Off line Analyse Testen Verifikation 5 On line Optimierung Weitere Informationen und Erkl rungen zu diesem Thema findet man in 13 Seit Beginn der 90er Jahre wurde intensiver nach M glichkeiten geforscht die das Konzept von Fuzzy Logik mit anderen Theorien verbinden Zwei der meines Erachtens interessantesten Konzepte werde ich hier kurz erl utern und sie ber deren jetzigen Stellenwert informieren Bei einem Hybriden System welches sich besonders gut hat etablieren k nnen handelt es sich um Neuro Fuzzy Systeme Darunter versteht man eine Symbiose von den beiden Konzepten neuronale Netze und Fuzzy Logik K nstliche n

Download Pdf Manuals

Related Search

Related Contents

SA-2U Dual Link 444 safe-area generator user manual  Médicament RHINADVIL  Blueair 503 Use and Care Manual    Les entretiens de développement professionnel  Betriebsanleitung / Operating instructions Lichtleitkabel  H.P.A. - Meta System  Sistema Portátil de Sonido y Reproductor MP3 con  V7 HDMI Cable (m/m) black High Speed gold plated connector 5m  

Copyright © All rights reserved. Failed to retrieve file