Posts tagged ‘Refactoring’

Rezension zu: Refactorings in großen Softwareprojekten

Ralph Johnson hat die englische Übersetzung des Refactoring-Buches von Martin und mir gelesen und findet es gut. Da fühle ich mich jetzt ja schon ein wenig geadelt…

December 7, 2008 at 8:19 pm Leave a comment

Technical Debt und das geistige Taskboard

Entwickler wollen ihren eigenen Ansprüchen genauso gerecht werden wie den Ansprüchen anderer. Daher tun sich viele Scrum-Teams am Anfang schwer, sich einzugestehen, dass sie sich für den Sprint zuviel vorgenommen haben (Over Commitment). Für Product Owner ist es anfänglich ebenso schwer. Schließlich hat man auch als Product Owner seine Ziele und möglicherweise sogar bestimmte Features zu einem festen Zeitpunkt versprochen.
Beides zusammen kann ausreichend Druck erzeugen, dass die Entwickler in den Zug einsteigen, der direkt in die Hölle fährt: Sie opfern Qualität, um den geplanten Sprintinhalt zum Sprintende zu schaffen. Sie gehen eine technische Schuld ein (Technical Debt), die ihnen später sehr schmerzhaft auf die eigenen Füße fällt – in Form einer steilen Aufwandskurve.
Dabei ist das erste Problem aus meiner Sicht gar nicht, dass man die technische Schuld eingegangen ist. Das erste Problem ist, dass das implizit passiert. Die Entwickler machen sich beim Programmieren geistige Tasks in der Art “Hier müsste man noch mal das Refactoring XYZ durchführen.”, “Hier müssten noch die Tests nachgeschrieben werden.” etc.
Diese Tasks gehören nicht in den “Hinterkopf”. Diese Aufräum-Tasks gehören explizit und für alle sichtbar ins Sprint-Backlog (und damit auf das Taskboard). Damit hat man nicht nur die Merker, was man noch erledigen muss. Es wird auch sofort klar, dass man das Sprint-Commitment trotzdem NICHT erreicht hat. Man hat nur die übrig gebliebenen Tasks getauscht. Es sind keine fachlichen Features mehr offen, sondern technische Aufräumarbeiten.
Dieser Fakt ist erstmal zu akzeptieren und in der Sprint-Retrospektive zu beleuchten. Warum konnten wir unser Commitment nicht halten und wie machen wir es nächstes Mal besser? Und dann sollte man sich auch gleich noch die Frage stellen: Warum haben wir Qualität geopfert anstatt Funktionalität zu reduzieren und ist das Opfern der Qualität wirklich der bessere Weg?

August 12, 2008 at 8:37 pm 2 comments

Software-Architektur mit Dependency-Injection

Überblick

Dieser Artikel beschreibt meine Erfahrungen mit Dependency-Injection (DI) in mehrjährigen Großprojekten. Dabei geht es vor allem um die Best-Practices für Entwurf und Architektur.

Wir haben vor allem handprogrammierte DI, Pico-Container und Java-Server-Faces als DI-Container eingesetzt. Der Artikel bezieht sich primär auf Pico-Container. Die „Erkenntnisse“ lassen sich aber auf andere DI-Container übertragen.

In einem Großprojekt haben wir ein System mit vielen Singletons schrittweise auf Pico-Container umgestellt. Wir haben einige größere Refactorings in dem Projekt durchgeführt und bei vielen war der Nutzen letztlich zweifelhaft. Der Umbau auf Pico-Container gehört aber definitiv zu den Umbauten, die sich deutlich gelohnt haben.

Zielsetzungen

Mit DI kann man eine Reihe von Zielen erreichen:

  • Entwurf entkoppeln
  • Abhängigkeiten explizieren
  • Testbarkeit verbessern
  • Singletons und static-Attribute eliminieren

Entwurf entkoppeln

DI führt nicht automatisch zu einer Entkopplung der Systemkomponenten. Man kann sich auch mit DI eigenartige und unwartbare Abhängigkeitsgeflechte zusammenbauen. Ohne DI hingegen ist es in der Praxis fast unmöglich, entkoppelte Systeme zu bauen. In diesem Sinne ist DI eine notwendige, aber keine hinreichende Bedingung für Entkopplung. Wenn man zusätzlich zu DI noch Interfaces und testgetriebene Entwicklung einsetzt, bekommt man aber ohne größere Anstrengungen ein gut entkoppeltes System.

Abhängigkeiten explizieren

DI macht die Abhängigkeiten von Objekten an ihrer Schnittstelle deutlich. Dadurch ist erstmal natürlich nur ein wenig Dokumentation gewonnen. In unseren Projekten hat dieses kleine bisschen Mehr an Dokumentation aber erheblichen Einfluss darauf gehabt, wie gut man Entwürfe verstehen konnte.

Testbarkeit verbessern

Durch die Entkopplung ließen sich die einzelnen Komponenten besser testen. Hier fällt insbesondere die Harmonie von DI mit Mock-Testen[1] positiv auf. Zusammen mit testgetriebener Entwicklung entsteht ein schlagkräftiges Trio.

Nicht zuletzt laufen so entkoppelte Tests viel schneller ab als klassisch erstellte Unit-Tests (in einigen Fällen konnten wir Testlaufzeiten von mehreren Minuten auf unter 10 Sekunden reduzieren).

Singletons und static-Attribute eliminieren

Setzt man DI konsequent ein, braucht man weder Singletons noch irgendeine andere Form statischer Attribute. Dadurch werden Zustandsabhängigkeiten im System reduziert, so dass sich Systemteile besser unabhängig voneinander wieder verwenden und testen lassen.

In unseren Projekten sind durch die Umstellung von Singletons auf DI eine ganze Reihe eigenartiger Phänomene beim Ausführen und beim Testen verschwunden.

Pico-Container im Code

Pico-Container ist ein sehr leichtgewichtiger DI-Container, der programmatisch konfiguriert wird. Daher können programmatisch DI-Container erzeugt und an andere Objekte übergeben werden. Da ist eine Fußangel versteckt: Man sollte Pico-Container minimal-invasiv benutzen. Das bedeutet, dass möglichst wenig Code Kenntnis davon haben soll, dass Pico-Container (oder ein anderer DI-Container) eingesetzt wird. Folglich sollten die Pico-Container nur im Startup erzeugt werden. Weitere Klassen dürfen nicht vom Pico-Container abhängen. In der Schichtung des Systems liegt der Pico-Container also ganz oben.

Pico-Container in Tests

In Unittests hat Pico-Container nichts verloren. Sind die getesteten Klassen so kompliziert miteinander verflochten, dass man sie manuell nicht zusammenstecken kann, ist Refactoring angesagt – und zwar schleunigst.

Welche Klassen registriert man beim DI-Container?

In unseren Projekten haben sich drei Typen von Klassen etabliert, die wir typischerweise beim DI-Container registrieren.

  • Fabriken
  • Services
  • Objekte, die nur einmal existieren dürfen (ehemalige Singletons)

Wofür baut man Fabriken?

Wenn ein Objekt andere Objekte erzeugen will, kann man diese Objekte nicht über DI hineinreichen – man weiß ja noch nicht, wie viele Objekte erzeugt werden. In solchen Fällen reicht man stattdessen Fabriken per DI in das Objekt.

Fabriken werden häufig mit static-Methoden implementiert. Wenn man die Fabriken beim DI-Container registriert, wäre das jedoch einigermaßen witzlos. Also gilt: Fabriken sollten keine static-Methoden enthalten – static-Attribute sowieso nicht.

In vielen Projekten habe ich beobachtet, dass viel zu selten Fabriken benutzt werden! Fabriken (ohne static-Methoden) helfen bei DI und erleichtern das Testen mit Mocks ungemein[2]. Im Zweifel würde ich lieber eine Fabrik zuviel spendieren.

Abschluss

Unsere Erfahrungen mit Pico-Container haben wir in erster Linie in Rich-Clients gesammelt. Wir haben Pico-Container serverseitig nicht verwendet. Es sollte jedoch möglich sein, weil der Pico-Container sehr leichtgewichtig ist. Der Overhead für die Erzeugung bei jedem Request oder EJB-Aufruf sollte in den meisten Anwendungen zu verkraften sein. Wenn der Overhead zu groß wird, kann man den Pico-Container mind. bei Webanwendungen auch in der Session speichern.

Inzwischen kommen viele Server-Infrastrukturen aber bereits mit eigenen DI-Containern (Spring, JSF, EJB 3), so dass man serverseitig i.d.R. wahrscheinlich nicht in die Verlegenheit kommt, Pico-Container einzusetzen.

Referenzen


[1] z.B. mit Easy Mock

[2] Beim Testen gilt: Jedes Testproblem kann durch eine weitere Indirektion gelöst werden.

March 18, 2008 at 8:16 am 4 comments

Buchkritik zu "Refactoring in Large Software Projects"

Schon vor einiger Zeit ist die englische Übersetzung des Buches Refactorings in großen Softwareprojekten von Martin Lippert und mir erschienen: Refactoring in Large Software Projects.
Dazu gibt es jetzt auch Kritiken: hier und hier.

May 4, 2007 at 8:29 am Leave a comment

Buchkritik zu "Refactoring in Large Software Projects"

Schon vor einiger Zeit ist die englische Übersetzung des Buches Refactorings in großen Softwareprojekten von Martin Lippert und mir erschienen: Refactoring in Large Software Projects.
Dazu gibt es jetzt auch Kritiken: hier und hier.

May 4, 2007 at 8:29 am Leave a comment

Veröffentlichungen

Siehe auch meine frühere Publikationsliste sowie meine Vorträge.

  • Stefan Roock: “eXtreme Programming“, in dotnetpro 02/2008 , Seite 28-33, Februar 2008
  • Stefan Roock, Henning Wolf, “Feature Driven Development (FDD)”, 4-teilige Artikelserie im Java-Magazin, 2007-2008
  • Stefan Roock, Henning Wolf: “Berufsethos, Qualität, Rollenverständnis”, in Java-Magazin, Juli 2006
  • Johannes Link, Stefan Roock: “Je abstrakter, desto besser, oder?”, in Java-Magazin, S. 65-69, Juni 2006
  • Eberhard Wolff, Henning Wolf, Stefan Roock: “Ist die Java-Plattform zu komplex geworden?”, in Java-Magazin, Mai 2006
  • Achin Bangert, Dierk König, Eberhard Wolff, Henning Wolf, Johannes Link, Martin Lippert, Stefan Roock: “Technology First”, in Java-Magazin, April 2006
  • Martin Lippert, Stefan Roock, Henning Wolf: “Ist die Technologie das geringere Problem?”, in Java-Magazin, Oktober 2005
  • Martin Lippert, Stefan Roock: “Large Refactorings”. Englische Übersetzung von “Refactorings in großen Softwareprojekten”, Wiley, 2006
  • Robert Beeger, Arno Haase, Stefan Roock, Sebastian Sanitz: “Hibernate”, dpunkt-Verlag, 2006.
  • Henning Wolf, Stefan Roock, Martin Lippert: „eXtreme Programming – Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis“, 2. überarbeitete und erweiterte Auflage, dpunkt-Verlag, 2005
  • Stefan Roock, Martin Lippert: “Refactorings in großen Softwareprojekten”, dpunkt-Verlag, 2004
  • Roock, S., Wolf, H.:, Agile Project Controlling, XP 2004, Juni 2004, Garmisch-Patenkirchen, 2004
  • Becker-Pechau, P., Roock, S., Sauer, J.:, Open Source für die Softwareentwicklung, In: HMD Praxis der Wirtschaftsinformatik, 238, August 2004, dpunkt.verlag, Heidelberg, S. 19-25, 2004
  • Roock, S., Lippert, M.:, Refactorings in großen Softwareprojekten, (Hrsg.): dpunkt.verlag, Heidelberg, 2004
  • Lippert, M., Becker-Pechau, P., Breitling, H., Koch, J., Kornstädt, A., Roock, S., Schmolitzky, A., Wolf, H., Züllighoven, H.:, Developing Complex Projects Using XP with Extensions, In: IEEE Computer Magazine, June 2003, Vol. 36, No. 6, 2003
  • Roock, S.:, RE bei agilen Methoden, 2003
  • Martin Lippert, Stefan Roock, Henning Wolf, “eXtreme Programming in Action”. Englische Übersetzung des XP-Buchs „eXtreme Programming in Action“, Wiley, 2003.
  • „Software entwickeln mit eXtreme Programming – Erfahrungen aus der Praxis“, Martin Lippert, Stefan Roock, Henning Wolf, 2002 erschienen im dpunkt-Verlag
  • Mitarbeit am Buch „Object-Oriented Software Construction“, Heinz Züllighoven
  • Mitarbeit am Buch „Das objektorientierte Konstruktionshandbuch“, Heinz Züllighoven
  • Lippert, M., Roock, S., Wolf, H., Züllighoven, H.:, XP in Complex Project Settings: Some Extensions, In: Extreme Programming Perspectives, Addison-Wesley XP Series, 2002
  • Lippert, M., Roock, S., Tunkel, R., Wolf, H.:, Stabilizing the XP Process Using Specialized Tools, In: Extreme Programming Perspectives, Addison-Wesley XP Series, 2002
  • Lippert, M., Roock, S., Wolf, H.:, Extreme Programming in Action – Practical Experiences from Real-World Projects, In: Wiley & Sons, UK, 2002
  • Roock, Stefan, Frameworks and Testing, In: Proceedings of Extreme Programming Conference 2002, Villasimius, Cagliari, Italy, 2002
  • Roock, Stefan; Havenstein, Andreas, Refactoring Tags for automatic refactoring of framework, In: Proceedings of Extreme Programming Conference 2002, Villasimius, Cagliari, Italy, 2002
  • Lippert, M., Roock, S., Wolf, H., Züllighoven, H.:, XP en proyectos complejos: algunas extensiones., In: Novatica, ATI, Spain, Nr. 156, March – April, 2002
  • Lippert, M., Roock, S., Wolf, H., Züllighoven, H.:, XP in Complex Project Settings: Some Extensions, In: Informatik/Informatique. Schweizerischer Verband der Informatikorganisationen. Nr. 2, April, 2002
  • Lippert, M., Roock, S., Wolf, H.:, Software entwickeln mit eXtreme programming: Erfahrungen aus der Praxis, In: dpunkt Verlag, Heidelberg, 2002
  • Lippert, Martin; Roock, Stefan; Tunkel, Robert; Wolf, Henning, Stabilizing the XP Process Using Specialized Tools, Proceedings of Extreme Programming Conference 2001, Villasimius, Cagliari, Italy, 2001
  • Lippert, Martin; Roock, Stefan; Wolf, Henning; Züllighoven, Heinz, XP in Complex Project Settings: Some Extensions, Proceedings of Extreme Programming Conference 2001, Villasimius, Cagliari, Italy, 2001
  • Gryczan, G.; Kornstädt, A.; Roock, S.; Wolf, H.; Züllighoven, H., Das JWAM-Framework und Komponenten. Eine konzeptionelle Bestandsaufnahme, in: Tagungsband des 3. Workshops zu komponentenorientierter betrieblicher Anwendungsentwicklung (Frankfurt: April 2001), S. 15-21, 2001
  • Lippert, Martin; Roock, Stefan; Züllighoven, Heinz, From Documents to Applications via Frameworks: The Tools and Materials Approach, in OOPSLA 2000 Companion, Minneapolis, ACM press, 2000
  • Roock, S., eXtreme Frameworking – How to aim applications at evolving frameworks, Proceedings of the XP2000 conference. Cagliari, Sardinia, Italy, 2000
  • Lippert, Martin; Roock, Stefan; Wolf, Henning; Züllighoven, Heinz, JWAM and XP – Using XP for framework development, Proceedings of the XP2000 conference. Cagliari, Sardinia, Italy, 2000
  • Gryczan, G., Roock, S., Wolf, H., Züllighoven, H., Frameworkbasierte Anwendungsentwicklung (6. und letzter Teil): Frameworkentwicklung und -einsatz organisieren, OBJEKTspektrum 2/2000, März/April 2000, S. 88-93, 2000
  • Gryczan, G., Havenstein, A., Roock, S., Wetzel, I., Züllighoven, H., Frameworkbasierte Anwendungsentwicklung (Teil 5): Unterstützung von Kooperation mit persistenten fachlichen Behältern, In: OBJEKTspektrum 1/ 2000, Januar/Februar , 2000
  • Gryczan, G.; Roock, S.; Wolf, H.; Züllighoven, H., Management kundenorientierter Softwareentwicklungsprojekte mit Objektorientierung, In: Informatik Software Project Management, Zeitschrift der schweizerischen Informatikorganisation, Nr. 5, Oktober 1999, S. 22-29, 1999
  • Gryczan, G., Roock, S., Wolf, H., Züllighoven, H., Frameworks von der Stange reichen nicht aus – Auswahl eines Rahmenwerks für die Software-Entwicklung, In: Computerwoche Nr. 5, 17.9.99, S. 6-8., 1999
  • Bleek, W.-G., Görtz, T., Lilienthal, C., Lippert, M., Roock, S., Strunk, W., Weiss, U., Wolf, H., Interaktionsformen zur flexiblen Anbindung von Fenstersystemen., Universität Hamburg. Fachbereich Informatik. Fachbereichsmitteilung FBI-HH-M-285/99. April., 1999
  • Bleek, W.-G., Lippert, M., Roock, S., Züllighoven, H., Strunk, W., Frameworkbasierte Anwendungsentwicklung (Teil 3): Die Anbindung von Benutzungsoberflächen und Entwick- lungsumgebungen an Frameworks, OBJEKTspektrum 3/99, Mai/Juni, S. 90-95, 1999
  • Bleek, W.-G., Lilienthal, C., Lippert, M., Roock, S., Strunk, W., Wolf, H., Züllighoven, H., Frameworkbasierte Anwendungsentwicklung (Teil 2): Die Konstruktion interaktiver Anwendungen, OBJEKTspektrum 2/99, März/April, S. 78-83, 1999
  • Bleek, W.-G., Gryczan, G., Lilienthal, C., Lippert, M., Roock, S., Wolf, H., Züllighoven, H., Von anwendungsorientierter Softwareentwicklung zu anwendungsorientierten Lehrveranstaltungen – der Werkzeug & Material-Ansatz in der Lehre, Software Engineering im Unterricht der Hochschulen (SEUH) 99, Berichte 52, B. Dreher/Ch. Schulz/D. Weber-Wulff (Hrsg.), Workshop des German Chapter of the ACM und der Gesellschaft für Information (GI) am 25. und 26. Februar 1999 in Wiesbaden, pp. 9-20, 1999
  • Gryczan, G., Lilienthal, C., Lippert, M., Roock, S., Wolf, H., Züllighoven, H., Framework-basierte Anwendungsentwicklung (Teil 1), OBJEKTspektrum Nr. 1, Jan./Feb., S. 90-98, 1999
  • Roock, S., Wolf, H., Züllighoven, H., Frameworking, In: Niels Jakob Buch, Jan Damsgaard, Lars Bo Eriksen, Jakob H. Iversen, Peter Axel Nielsen (Eds.): IRIS 21 “Information Systems Research in Collaboration with Industry“, Proceedings of the 21st Information Systems Research Seminar in Scandinavia, 8-11 August 1998 at Saeby Soebad, Denmark, pp. 743-758, 1998
  • Fricke, N., Lilienthal, C., Lippert, M., Roock, S., Wolf, H., Operating and Window Systems will never strike back or Independence day for Java developers, In: R. Nigel Horspool (Ed.): Systems Implementation 2000, Chapman & Hall, London, New York 1998, Proceedings of SI2000 (IFIP Working Group 2.4), Berlin 23-26 February 1998, pp. 86-99., 1998
  • Roock, S., Wetzel, I., Wolf, H., Züllighoven, H., Location as an Analysis and Design Metaphor in Work Settings with Complex Cooperations, In: Kristin Braa & Eric Monteiro (eds.): Proceedings of IRIS 20 “Social Informatics”, Oslo, June 1997. S. 431-448, 1997

January 1, 1990 at 9:52 pm Leave a comment

Vorträge

siehe auch meine Artikel und Bücher

  • Bernd Schiffer, Stefan Roock: Agile Entwicklung mit Grails, XP-User-Group-Hamburg und Java-User-Group-Hamburg, Dezember 2007
  • Stefan Roock: Einfachheit in Softwareprojekten, XP-Days Germany 2007, Karlsruhe, November 2007
  • Stefan Roock (Organisation): Agile Lightning Talks, XP-Days Germany 2007, Karlsruhe, November 2007
  • Stefan Roock, Bernd Schiffer, Henning Wolf: Agile Lego Hour, W-JAX 2007, München, November 2007
  • Stefan Roock, Henning Wolf: Festpreisvertrag und agil nützt nicht viel?, Agility Day auf der W-JAX 2007, München, November 2007, Folien
  • Stefan Roock (Organisation): Agile Lightning Talks, Agility Day auf W-JAX 2007, München, November 2007
  • Stefan Roock: Anforderungen, Usability und Agilität, Universität Konstanz, 2007, Folien
  • Stefan Roock, Henning Wolf: Scrum und Lean-Management in IT-Projekten, Arbeitskreis Projektmanagement, Nordakademie, 2007
  • Jürgen Ahting, Stefan Roock: Warum sind die Kunden in Softwareprojekten so schwierig?, JAX 2007, Wiesbaden, 26.04.2007
  • Robert Beeger, Matthias Lübken, Stefan Roock, Sebastian Sanitz: XP-Live-Demo, JAX 2007, Wiesbaden, April 2007
  • Stefan Roock, Henning Wolf: IT-Kaizen: Kontinuierliche Verbesserung in der Softwareentwicklung, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  • Bernd Schiffer, Stefan Roock: Beispiel Grails – Brauchen wir neue Technologien für agile Entwicklung?, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  • Arno Haase, Stefan Roock, Sebastian Sanitz: Hibernate 3 (ganztägiger Power-Workshop). JAX 2006, Wiesbaden, 08.05.2006
  • Stefan Roock, Henning Wolf: Aufwandsschätzung in agilen Projekten. Lehmanns Buchhandlung, Hamburg, Januar 2006.
  • Robert Beeger, Arno Haase, Stefan Roock: Hibernate 3. (ganztägiger Power-Workshop). W-JAX 2005, München, November 2005.
  • Bernd Schiffer, Stefan Roock: eXtreme Programming (Tutorial). ix-Konferenz, Köln, November 2005.
  • Jürgen Ahting, Stefan Roock: Der Kunde in agilen Projekten. ix-Konferenz, Köln, November 2005
  • Stefan Roock: Aufwandsschätzung in großen agilen Projekten. ix-Konferenz, Köln, November 2005.
  • Stefan Roock: Refactorings in großen Softwareprojekten, XP-Days 2004, Karlsruhe
  • Martin Lippert, Stefan Roock: Refactorings in großen Softwareprojekten, Java Forum Stuttgart 2004, 01.07.2004, Stuttgart.
  • Stefan Roock, Martin Lippert, Frank Westphal: Testing in the Extreme Programming World. (Full-Day Tutorial). ICS Test, Köln, http://www.icstest.com, 01.04.2003
  • Stefan Roock, Martin Lippert: Large Refactorings (Workshop). OT 2003, Cambridge, UK, http://www.ot2003.org, 2003
  • Stefan Roock: Requirements Engineering bei agilen Methoden. GI-Workshop “Requirements Engineering”, Ulm, http://www-lufgi3.informatik.rwth-aachen.de/GI/GI-FG2.1.6.html. 28.09.2002
  • Holger Breitling, Axel Schmolitzky, Stefan Roock: Extreme
    Programming (Half-Day Tutorial). Software Management Tagung, Hamburg, 06.11.2002
  • Holger Breitling, Petra Becker-Pechau, Stefan Roock: Agile Requirements Engineering (Full-Day Tutorial). RE 2002, Essen. 10.09.2002
  • Martin Lippert, Stefan Roock: Using and Adapting Extreme Programming (Full-Day Tutorial). ECOOP 2002, Malaga, Spanien, 11.06.2002
  • Martin Lippert, Stefan Roock: Extreme Programming in komplexen Projektsituatuionen (Full-Day Tutorial). OOP 2002, München. Januar 2002.
  • Stefan Roock: eXtreme Programming integrativ? GI-Workshop “Vorgehensmodelle”. 2001
  • Martin Lippert, Stefan Roock: Extreme Programming in Complex Project Settings (Half-Day Tutorial). ECOOP 2001, Budapest, Ungarn, Juni 2001
  • Stefan Roock: Anforderungsermittlung mit eXtreme Programming. GI-Workshop
    “Requirements Engineering”, 2001.
  • Stefan Roock, Henning Wolf: Framework-Entwicklung (Full-Day Tutorial). OOP
    2001, München, Januar 2001.
  • Stefan Roock: Object Oriented Design (3-Day Workshop). University
    of Roenneby, Schweden, März 2000.

January 1, 1990 at 9:10 pm Leave a comment

Newer Posts