1 / 18

Objektorientierte Konzepte in der Softwaredokumentation

Objektorientierte Konzepte in der Softwaredokumentation. Referent: Marcus Budzyn Studiengang: Technische Informatik Oberseminar „Softwaredokumentation“ Juli 1998. Objektorientierte Konzepte in der Softwaredokumentation. Einleitung Terminologie objektorientierter Systeme

elpida
Download Presentation

Objektorientierte Konzepte in der Softwaredokumentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Objektorientierte Konzepte in der Softwaredokumentation Referent: Marcus Budzyn Studiengang: Technische Informatik Oberseminar „Softwaredokumentation“ Juli 1998

  2. Objektorientierte Konzepte in der Softwaredokumentation • Einleitung • Terminologie objektorientierter Systeme • Objektorientierte Softwaredokumentation • Dokumentationswerkzeug “DOgMA” • Kritische Anmerkungen • Literaturhinweise • Fragen

  3. Einleitung (1) Bisher: Objektorientierte Programmierung Vorteile: Hohe Wiederverwendbarkeit von Software- komponenten Aber: Extensive Wiederbenutzung von Software- komponenten erhöht den Stellenwert der Dokumentation

  4. Einleitung (2) • Lösungsvorschlag: • Anwendung des objektorientierten Konzepts auch • auf die Softwaredokumentation • “..we suggest applying object-oriented technology to the • documentation, too” • aus “Object-Oriented Documentation”, Sametinger 1994 • Vorteile: • Teile der Dokumentation werden wiederverwendet • Ansprüche verschiedener Lesergruppen der Dokumentation werden berücksichtigt (z.B. Wiederverwendung und Wartung)

  5. Terminologie objektorientierter Systeme (1) Objekte: Eine laufende OO-Software besteht aus Objekten, die Struktur und Verhalten besitzen. Bsp.: Rechteck • Struktur: Höhe, Breite • Verhalten: Zeichne, Lösche, Rotiere Rechteck Zeichne Höhe = 5 cm Breite = 7 cm Winkel = 00 Rotiere Lösche

  6. Terminologie objektorientierter Systeme (2) Klassen, Methoden: Quelltext eines OO-Softwaresystems besteht aus Klassen, welche • Struktur (Variablen) und • Verhalten (Methoden) definieren. Objekte gleicher Struktur und Verhaltens sind in einer Klassebeschrieben.

  7. Terminologie objektorientierter Systeme (3) Vererbung: Eine Klasse kann Verhalten und Struktur von einer anderen Klasse erben und zusätzlich erweitern bzw. modifizieren. Bsp.: Form Superklasse Basisklasse Kreis Rechteck Abgeleitete Klasse, Subklasse

  8. Terminologie objektorientierter Systeme (4) Klassenbibliotheken/Anwendungsrahmen: Wiederverwendung von Klassen wird Teil der OO-Softwareentwicklung Folgerung: Es entstehen Sammlungen stark wieder- verwendbarer Klassen, genannt Klassen- bibliotheken. Klassenbibliotheken, die ein Anwendungsgerüst definieren, werden Anwendungsrahmen genannt.

  9. Terminologie objektorientierter Systeme (5) Information hiding: Klassen (wie auch Module) unterstützen das Information hiding, d.h. Variablen und Methoden können im Zugriff beschränkt werden. Zugriffsbeschränkungen: • private (nicht öffentlich): kein Zugriff außerhalb der Klasse • protected (geschützt): zugreifbar in abgeleiteten Klassen • public (öffentlich): zugreifbar von Clients der Klasse

  10. Terminologie objektorientierter Systeme (6) Wiederbenutzer: Programmierer, die existierende Klassen in ihrem Programm verwenden (eine Instanz der Klasse deklarieren) oder Subklassen existierender Klassen implementieren, werden Wiederbenutzer genannt. Implementierungsdetails der verwendeten Klasse sind für den Wiederbenutzer nicht interessant andere Anforderungen an Dokumentation als “Wartungsprogrammierer”

  11. Programmierer muß nur Erweiterungen und Veränderungen im Quelltext (be)schreiben ! ! Das gleiche Prinzip soll auch für die Dokumentation angewendet werden Objektorientierte Softwaredokumentation (1) OO-Softwaresysteme sind Erweiterungen von Klassenbibliotheken oder Anwendungsrahmen

  12. Objektorientierte Softwaredokumentation (2) Übersicht externe Ansicht interne Ansicht Übersicht Beschreibung Klasseninterface Beschreibung Klassen- implementation statisch dynamisch Übersicht Beschreibung Jobinterface Beschreibung Job- implementation

  13. Dokumentation Rechteck Form Objekt Abschnitte: Kurzbe- schreibung Voraus-setzungen für die Benutzung Speichern in Dateien Wartungs- informationen Objektorientierte Softwaredokumentation (3) Softwareentwicklung Rechteck Form Objekt Methoden: Vergleiche Drucke Zeichne Bewege

  14. protected = geschützt private = nicht öffentlich public = öffentlich Objektorientierte Softwaredokumentation (4) Rechteck Form Objekt Abschnitte: Kurzbe- schreibung Voraus-setzungen für die Benutzung Speichern in Dateien Wartungs- informationen • public: Wie wird die Klasse benutzt • protected: Wie werden Subklassen gebildet • private: Implementierungsdetails

  15. Dokumentationswerkzeug “DOgMA” DOgMA3: File Edit Project Editable Classes (58) Methods for clients (131) Displayed Text: class DProject Comment: The abstract class Document File: /home/local/ET++/manTest/ Inheritance: DProject, HyperProject, ChangeAllCmd ChapterItem CommentItem ChangeAllCmd ChapterItem CommentItem CommentMark DProject Windows and Icon Each Document has a main window. The main window must be created by the method DoMakeWindows and is added to the document‘s list of windows in the instvar The layout of the main window usually Documentation for Clients (19) Document: Name Document: Description Document: Document Type Document: Windows and Icon (Die Bedienoberfläche von DOgMA)

  16. Kritische Anmerkungen • Verfügbarkeit von OOSD-Werkzeugen Akzeptanz • Wie schnell wird OOSD standardisiert Akzeptanz • Ist „Umerziehung“ der Programmierer möglich? Akzeptanz • OOSD nicht geeignet für Benutzerdokumentation(OOSD = Objektorientierte Softwaredokumentation)

  17. Literaturhinweise „Object-Oriented Documentation“ Johannes Sametinger The Journal of Computer Documentation Volume 18 Number 1 January 1994 Ergänzungen: Brad Mehlenbacher, Craig Boyle, Edmond H. Weiss (Ph. D) The Journal of Computer Documentation Volume 18 Number 2 May 1994 Mary Elizabeth Raven/Richard Thomson „Can Principles of Object-Oriented System Documentation Be Applied to User Documentation?“ The Journal of Computer Documentation Volume 18 Number 1 January 1994

  18. ... um Unklarheiten zu beseitigen Fragen Die letzte Gelegenheit...

More Related