Definitionen und wichtige Begriffe zur Softwaretechnik

 

1.1 Einführung und grundlegende Begriffe

1.2 Der Software-Lebenszyklus

1.3 Das Personal zum Software Engineering

1.4 CASE-Tools und Entwicklungsumgebungen

1.5 Software-Messung

1.6 Software-Management

3.1 Objektorientierte Software-Entwicklung

3.2 Komponentenbezogene Technologien

3.3 Software-Reengineering

3.4 Formale Spezifikation

3.5 Verteilte Software-Entwicklung

4. Software-Entwicklung mit der UML

 

Diagramme:

-          Schichtenmodell: S. 48

-          Komponentendiagramm S. 49 ff

-          Flussdiagramm S. 53 f.

-          Struktogramm S. 55

-          Ereignisdiagramm S. 56

-          Programmflussgraph S. 81 ff., Beispiel auf S. 78

-          Callgraph S. 90

-          Anwendungsfalldiagramm (use case diagram) S. 119 ff.

-          PERT (Program Evaluation and Review Technique)-Diagramm S. 188 f.

-          CPM (Critical Path Method)-Diagramm S. 190

-          Gantt-Diagramm S. 191

-          Datenflussdiagramm S. 221

-          Funktionsbaum S. 232

-          Aktivitätsdiagramm S. 234

-          Zustandsdiagramm S. 244

-          SDL-Diagramm s. 245

-          Sequenzdiagramm S. 255

-          Kollaborationsdiagramm (auch: Objektdiagramm) S. 256

-          evtl. Storyboard-Diagramme S. 269

-          Klassendiagramm S. 277 - 282

1.1 Einführung und grundlegende Begriffe

Software Engineering: "The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that ist, the application of engineering to software."

Ein Software-Produkt (software product) ist die Gesamtheit von Softwarekomponenten (Programmen, Dokumentationen usw.), die als Ganzes entwickelt, vertrieben, angewendet und gewartet werden.

Der Software-Entwicklungsprozess (software development process) ist der gesamte Prozess der Aufgabenstellung, Planung, Realisierung und Bewertung einer Software-/Hardware-Anwendung einschließlich der verwendeten Hilfsmittel und Methoden und dem erforderlichen Personal.

Als Ressourcen (resources) fassen wir alle für die Software-Entwicklung aufgewendeten bzw. aufzuwendenden personellen, Software- und Hardware-Mittel zusammen.

Die Software-Ressourcen für den Entwicklungsprozess bilden alle programmtechnischen Hilfsmittel und Systeme, die die Entwicklung unterstützen, (teilweise) automatisieren und dokumentieren. Werkzeuge dieser Art bezeichnen wir als CASE-Tools (Computer-Aided Software-Engineering).

Die Software-Ressourcen für das Software-Produkt sind alle Programm- und Dokumentationsbestandteile, die bereits vorhanden sind und durch das Beschaffen (Akquirieren), Bereitstellen, Hinzufügen oder Anpassen in das künftige Produkt mit eingehen. Wir bezeichnen diese Ressourcen als Software-Komponenten (software components).

Ein Projekt(project) ist der konkrete Prozess zur Entwicklung eines konkreten Software-Produktes mit den dafür notwendigen Ressourcen.

Ein Anwendungsgebiet (application domain) ist ein spezieller wirtschaftlicher oder gesellschaftlicher Bereich mit den dazugehörenden technologischen und soziologischen Strukturen und Prozessen, die durch kulturelle Besonderheiten, ein vorhandenes industrielles Niveau und gesetzliche Regelungen geprägt oder bestimmt sind.

Ein Standard im Software Engineering ist eine Regelung bzw. Vorschrift zu einem Aspekt oder einer Komponente der Software-Entwicklung, die von einem speziellen Standardisierungskonsortium herausgegeben wird und Grundlage einer Prüfung der Einhaltung oder einer Zertifizierung sein kann.

Ein Maßsystem (system of measures) ist eine Menge von Software-Maßen, die sich auf alle wesentlichen Aspekte der Software-Entwicklung bezieht und die Bewertung bzw. die damit verbundene Prüfung der Einhaltung von Vorgabekriterien gewährleistet.

Die Erfahrung (experience) im Bereich der Software-Entwicklung und -Anwendung ist das durch Praxis, Fallstudien und Experimente gewonnene Wissen zur Entwicklung und Anwendung von Software-Produkten einschließlich der dabei zugrunde liegenden Prozesse und verwendeten Ressourcen.

  1. Geben Sie für ein selbstgewähltes Software-Produkt die jeweiligen Bestandteile an.
  2. Nennen Sie konkrete Beispiele für Software-Produkte zur Klasse der Fatware, Firmware und Freeware.

-          Fat: Office 98, die meisten Spiele; Firm: BIOS, auf den Geräten drauf; Free: Acrobat Reader, WinZip

  1. Welcher Ressourcenart gehören der Wartungsingenieur, das Flowchart-Tool oder der PALM-Computer an?

-          Personal, Software, Hardware

  1. Erläutern Sie die typischen Merkmale für ein Software-Projekt.

-          Kompletter Entwicklungsprozess für Software mit Personal (Manager, Programmierer, Designer), CASE-Tools (z.B. forte)

-          Ressourcen: Hardware: Betriebssystem, Netzwerk, Rechner

-          einmalig mit Termin, klar definiertes Ziel, mehrere Fachgebiete à neue Lösungen

  1. Was ist der Unterschied zwischen einem Standard und einem De-Facto-Standard? Geben Sie jeweils ein Beispiel für die Software-Entwicklung an.

-          ein Standard im Software Engineering ist eine Regelung bzw. Vorschrift zu einem Aspekt oder einer Komponente der Software-Entwicklung, die von einem speziellen Standardisierungskonsortium herausgegeben wird und Grundlage einer Prüfung der Einhaltung oder einer Zertifizierung sein kann.

-          De-facto-Standard: aufgrund hoher Dynamik in der Software-Entwicklung und des Zeit beanspruchenden Prozesses der Standardbildung: allgemein anerkannte (noch nicht standardisierte) Vorgehensweise oder Lösungsform

  1. Welche Ziele verfolgt ein Maßsystem für den Bereich der Software-Entwicklung?

-          Einhaltung der Vorgabe à in Anforderungsanalyse beschrieben, z.B. Reaktionszeit, Zuverlässigkeit, Speicherbedarf

à    Messung und Bewertung von Ressourcen (z.B. Entwicklungszeit und –Kosten)

  1. Diskutieren Sie jeweils ein Beispiel für eine allgemeine und eine konkrete Software-Entwicklungserfahrung.

-          allg.: no big bang, tiny Step

-          konkret: 1 $ Entwicklung kostet 2 $ Wartung

1.2 Der Software-Lebenszyklus

Der Software-Lebenszyklus (software life cycle) ist der Prozess der Entwicklung von Software-Produkten und kennzeichnet alle Phasen und Stadien dieser Produkte von ihrer Entwicklung, Einführung und Wartung bis zu ihrer Ablösung oder Beseitigung.

Eine Lebenszyklus-Phase (life cycle phase) innerhalb des Software-Entwicklungs-, Anwendungs-, und Wartungsprozesses ist ein zeitlich begrenzter Abschnitt mit relativ eigenständigen Ressourcen, für den eine Anfangssituation und ein bewertbarer Endzustand bestimmt werden können.

Unter der Verifikation ist die Prüfung der Korrektheit einer Entwicklungsphase zu ihrer vorangegangenen zu verstehen. Mit Validation wird die Prüfung der Korrektheit des sich in irgendeiner Entwicklungsphase befindlichen Produktes zu den Anforderungen des Auftraggebers oder Nutzers bezeichnet. Oder anders ausgedrückt: Verifikation: „richtige Entwicklung“; Validation: „Entwicklung des Richtigen“

Die Problemdefinition (problem definition) ist die zusammenfassende Beschreibung von Anforderungen (requirements) an die Entwicklung von Software-Produkten, die sich unterteilen in funktionale Anforderungen zur Beschreibung der Arbeitsweise und der grundlegenden Eigenschaften der problembezogenen Funktionalität, qualitative Anforderungen zur Darstellung der Produktqualität in seinen verschiedenen Ausprägungen, systembezogene Anforderungen für die Charakterisierung der erforderlichen Hardware und damit verbundenen bzw. notwendigen Software und prozessbezogene Anforderungen zur Beschreibung der projektspezifischen Merkmale wie Entwicklungszeit, Kontrollpunkte, personelle und finanzielle Ressourcen.

Die Anforderungsanalyse (requirement analysis) ist die Phase der Kontrolle von Anforderungen an ein zu entwickelndes Software-System hinsichtlich Korrektheit, Vollständigkeit, Sachgerechtigkeit, Konsistenz und Machbarkeit und deren zweckmäßige, i.a. computer-gestützte Speicherung für die ständige Nutzung, Aktualisierung und Überprüfung im Verlauf der Software-Entwicklung.

Die Spezifikation ist die Formulierung aller funktionaler und einiger qualitativer Anforderungen in einem Modell, welches die computerbezogenen und organisatorischen Systemkomponenten beschreibt. à funktionale Anforderungen (WAS)

Der Software-Entwurf (software design) ist die Umsetzung der in der Spezifikation erstellten Modelle in eine die hard- und softwarebezogenen Anforderungen berücksichtigende Form von Diagrammen, Schemata und Pseudocodes, die gleichzeitig die hierbei gültigen qualitativen Anforderungen mit einschließen und unmittelbar als Implementationsvorgabe verwendet werden kann. à systembezogene Anforderungen (WIE)

Die Implementation ist die Umsetzung der Entwurfsergebnisse in ein programmiertes, auf spezieller Hardware oder Hardware-Klassen abarbeitbares System und vollzieht sich in den Phasen der Kodierung, des Testes, der Integration und der Installation. à qualitative Anforderungen (WIE GUT)

Die Erprobung eines Software-Systems (software acceptance testing) ist der Nachweis seiner Validität auf der Grundlage von Akzeptanzkriterien in einem ausgewählten Anwendungsfeld.

Die Software-Wartung (software maintenance) umfasst alle Aktivitäten der Erweiterung (extension), der Anpassung (adaptation), der Korrektur (correction), der Verbesserung (perfection) und der Vorbeugung (prevention) an einem Software-Produkt, um dessen fortgesetzte Anwendung über einen längeren Zeitraum zu gewährleisten.

Die Software-Anwendung (software use) ist die Nutzung eines Software-Produktes in den Phasen der Einführung (delivering), der kontinuierlichen Nutzung (operation), der zeitweise notwendigen Änderung (changing) und schließlich der Ablösung (replacement).

Die Umstellung (conversion) eines Software-Systems ist eine Anpassung auf der Grundlage gesetzlicher oder technologischer Änderungen, die eine Menge von Systemen oder Produkten betrifft.

Das Modellieren beim Software Engineering ist die strukturelle, operationelle und informelle Umsetzung von Anforderungen in einer dem zu entwickelnden System angemessenen und für den Entwickler und Auftraggeber interpretierbaren Form - dem Modell.

Ein Wörterbuch (data dictionary) – auch Enzyklopädie genannt – ist die im Allgemeinen computer-gestützte Sammlung aller Beschreibungsdaten der zu einer Software-Entwicklung gehörenden Größen bzw. Daten. Sind die Werte der Größen in diesem Wörterbuch mit enthalten, so handelt es sich um ein Repository. à überwacht Konsistenz

Die Komplexität im Software Engineering ist die durch Umfang und/oder Struktur hervorgerufene Schwierigkeit, eine Komponente aus dem Prozess, dem Produkt oder den Ressourcen zu bearbeiten (operational oder computational complexity) oder zu verstehen (psychological complexity).

Die Architektur bei der Software-Entwicklung ist die software- und ggf. hardwarebezogene Struktur eines zu entwickelnden Systems, welches die Komponenten dieser Struktur, deren extern sichtbare Schnittstelle und die Beziehungen zwischen den Komponenten umfasst.

Ein Paradigma (paradigm) bei der Software-Entwicklung ist die durch formale oder informale Methoden auf der Modellierungsseite und durch eine Programmiersprachform auf der Realisierungsseite geprägte Art der Systemdarstellung und -implementation.

Die Akquisition im Rahmen der Software-Entwicklung beinhaltet die Marktrecherche, Tauglichkeitsprüfung, Vertragsgestaltung und schließlich Beschaffung von Software für die Verwendung in einem zu entwickelnden Software-System.

Eine Konfiguration ist eine Version oder Variante der Grundarchitektur eines Software-Produktes, welches ganz speziellen Nutzeranforderungen dient.

Die Programmierungstechnik ist die Art und Weise, Quellcode zusammenzustellen, diesen zu übersetzen, zu verbinden und zu interpretieren.

Programmierkonventionen sind Richtlinien bzw. Vorgaben für die Form, die Struktur und den Inhalt des zu erarbeitenden Quelltextes zur Gewährleistung spezieller qualitativer Aspekte.

Die Software-Integration ist die daten-, steuer- und prozessbezogene Zusammenstellung der akquirierten und selbst erstellten Software-Komponenten auf der Grundlage der Einbettung, der Aufteilung und der Komposition.

Die Migration ist die Überführung eines Software-Systems auf eine neue operationale Umgebung. Das kann von der Änderung der System-Software (insbesondere des Betriebssystems) bis hin zum Wechsel der Plattform reichen.

10.  Welche Lebenszyklusphasen unterscheidet man bei der Software-Entwicklung?

-          Problemdefinition (Lastenheft-, Pflichtenhefterstellung) à Aufgabenstellung (Warum)

-          Anforderungsanalyse (Ist-Analyse/ Soll-Konzeption, Vorprojektierung) à Realisierbarkeit

-          Spezifikation (Grob-Konzeption, Fachliche Konzeption) à Modellierung (Was)

-          Entwurf (Fein-Konzeption, DV-technische Konzeption)à Systemausrichtung (Wie)

-          Implementation (Kodierung/Test, DV-technische Realisierung) à Realisierung

-          Erprobung (Feldtest) à Feldtest (Wie gut)

-          Entwicklung à P A S E I E

-          Anwendung (Einführung = Wirkbetrieb, Operation)

-          Software-Wartung

  1. Welche Korrektheit wird bei der Verifikation und welche bei der Validation zum Ausdruck gebracht?

-          Verifikation: Prüfung der Korrektheit einer Entwicklungsphase zu ihrer vorangegangenen à „richtige Entwicklung“

-          Validation: Prüfung der Korrektheit des sich in irgendeiner Entwicklungsphase befindlichen Produktes zu den Anforderungen des Auftraggebers oder Nutzers à „Entwicklung des Richtigen“

  1. Geben Sie zu den im Abschnitt 1.2.2 genannten Systembeispielen (a) bis (e) weitere Beispiele qualitativer und systembezogener Anforderungen an.
  2. Beschreiben Sie Hilfsmittel zur Unterstützung der Problemdefinition, die einen wesentlichen Erfahrungshintergrund in dieser Phase bilden.

-          Sofortmaßnahmen: Brainstorming (Zusammensitzen für Umsetzung, Machbarkeit etc.)

-          Kontrollphasen (z.B. zw. 2 Brainstormings): Expertise: Entwicklungshilfe (von mehreren); Gutachten: meist 1 Person, rechtl. verbindlich

  1. Geben Sie Beispiele für inkonsistente, implizite, messbare und unverträgliche Anforderungen an.

-          inkonsistent: leichte Bedienbarkeit bei hoher Komplexität (eigentlich: mehrdeutig)

-          messbar: Entwicklungskosten, -dauer

-          unverträglich: kleines Programm, große Funktionalität, in einem Monat fertig

-          implizit: soll auf gängigen PCs laufen

  1. Erläutern Sie die Analogiemethode der Anforderungsanalyse an einem konkreten Beispiel.
  2. Welche strukturellen Modellierungstechniken werden bei der Spezifikation angewendet?

-          Vereinfachung (abstraction), Aufteilung (partition), komprimierte Abbildung (projection)

  1. Welchen Inhalt hat ein Data Dictionary in der Spezifikationsphase?

-          alle Beschreibungsdaten (Größen, Daten) à Metadaten (auch Abkürzungen, Begriffsbezeichnungen, -abhängigkeiten) à Modelle

  1. Geben Sie Beispiele für S-, P- und E-Systeme an.

-          S: Rechnen (Grundrechenoperationen)

-          P: Simulation des Wetters (zu komplex), Schachspiel

-          E: Modellierung des Wirtschaftssystems eines Landes

  1. Welche Vor- und Nachteile haben formale und informale Spezifikationsmethoden?

-          informal(verbaler Text, Skizzen, Diagramme): leicht verständlich, gute Grundlage für Validation, gut für sehr große Problemstellungen, nicht alle Anforderungen müssen zur Spezifikation vorliegen; aber: Konsistenzprobleme, beschreibt diese meist nur „punktuell“

-          formal(mathematisch, begründete Formalismen): Konsistenzbeachtung, gut für Verifikation, beschreibt die Problemstellungen i.a. vollständig und exakt; aber: schwer verständlich, nur geeignet für kleine bzw. gut definierbare Problemstellungen, alle Anforderungen müssen zur Spezifikation vorliegen

  1. Nennen Sie Beispiele für nicht implementierbare Systembestandteile.
  2. Welche Anforderungen werden vor allem beim Entwurf umgesetzt?

-          v.a. systembezogene (hard- und softwarebezogen)

  1. Was sind COTS?

-          Commercial off the shelf: bereits vorhandenes Anwendungssystem, z.B. die Java-Programmbibliotheken

  1. Beschreiben Sie in einem Komponentendiagramm die Architektur einer Programmierumgebung.

-          S. 49 ff.

  1. Wie ist die stärkste Bindung und schwächste Kopplung von Komponenten definiert?

-          Bindung: alle Funktionalitäten in einer Komponente (Funktionalität)

-          Kopplung: gar keine Verbindung zu anderen Komponenten (Daten)

  1. Geben Sie ein sinnvolles Beispiel für einen Hardest-First-Entwurf an.

-          Schachspiel: zuerst Strategie, dann Grafik

  1. Beschreiben Sie in einem Flussdiagramm die Erfassung und Verarbeitung der Quelltexterzeugung in einer Programmierumgebung.

-          S. 53 f.

  1. Geben Sie zur Algorithmenbeschreibung "Zähle alle Anweisungen in einem Quelltext, die eine Bedingung bzw. bedingte Verzweigung enthalten" ein Struktogramm an.

-          S. 55

  1. Beschreiben Sie die Berechnung des gewichteten Durchschnittes einer Wertemenge im Pseudocode.
  2. Zeichnen Sie für die Nichtdurchführbarkeit einer mündlichen Prüfung ein Ereignisdiagramm.

-          S. 56

  1. Begründen Sie die im Abschnitt 1.2.5 angegebene Klassifikation der Programmiersprachen bezüglich ihrer Entwicklungs- und realisierbaren Systemeffizienz.
  2. Nennen Sie Darstellungsmittel und Programmiersprachen für ein imperatives Paradigma.

32.  Geben Sie Standardsoftwarebeispiele an und beschreiben Sie deren Anwendungsform.

-          Datenbanksysteme: Informix, DB2, Oracle, Access

-          Textverarbeitungssystem: MS WORD, LaTeX, HTML-Editor

-          E-Commerce: Jango, Net-Genesis, Intershop

  1. Welche Aufgaben werden bei der Software-Akquisition realisiert?

-          relativ eigenständig während der Entwicklung à geeignete Anwendungs- bzw. Standardsoftware

à    Marktrecherche, Tauglichkeit, Vertragsgestaltung à Beschaffung

  1. Was versteht man unter einer Software-Konfiguration?

-          Konfiguration ist eine Version oder Variante der Grundarchitektur eines Software-Produktes, welches ganz speziellen Nutzeranforderungen dient.

  1. Welche Dokumentationsformen werden beim Entwurf vollständig oder teilweise erarbeitet?

-          verbesserte Anwendungsdokumentation (jetzt: Software-Ausrichtung), Entwicklerdokumentation (in Implementation verfeinern)

  1. Nennen Sie grundlegende Formen der Kodierung und beschreiben Sie deren Vor- und Nachteile.

-          Editieren: manuell in Editor oder Entwicklungsumgebung

-          Generieren: aus Entwurf (muss algorithmisierbar sein)

-          Anpassen: Verwendung bereits vorhandener Quellcodes, Modifikation in Editoren

-          Übernehmen: unveränderte Code-Wiederverwendung, z.B. aus Bibliotheken, aber: Verständnisproblem

  1. Erläutern Sie zwei der im Abschnitt 1.2.6 angegebenen Programmierungstechniken.

-          Unterprogrammtechnik: Abgrenzung einer speziellen Funktionalität in Form eines Programmkörpers und einer Schnittstelle für seine Anwendung; gekennzeichnet durch Bezeichnung und Parametermenge

-          Makrotechnik: ähnlich Unterprogrammtechnik; Ergebnis der Interpretation ist nicht der Wert eines Algorithmus, sondern Quelltext einer bestimmten Programmiersprache

-          Modultechnik: Unterprogramme werden, zusammengefasst als Module, separat übersetzt, getestet und in Gesamtprogramm eingebunden

-          Abstrakte Datentypen: Abstraktion von konkreten Datentypen; ermöglicht mit der Einbindung zugehöriger Verarbeitungsoperationen die Definition von Klassen

-          Emulation: Editierung und Testung von Software eines bestimmten Computers auf einem anderen

  1. Welchen Sinn haben Namenskonventionen bei der Software-Entwicklung?

-          einheitliche, gut lesbare Form, mnemonische Aspekte; v.a. bei verteilten Anwendungen: Zugriff auf Funktionen, die anders heißen

  1. Erläutern Sie den Unterschied zwischen Irrtum, Fehler und Fehlverhalten an einem Beispiel.

-          ein Irrtum (fault) bei der Software-Entwicklung entsteht durch ein Missverständnis oder einer falschen Umsetzung Anforderungen

-          ein Fehler (error) ist schließlich das Resultat einer falschen Entwicklung im Software-System

-          ein Fehlverhalten (failure) tritt schließlich bei der Anwendung eines Software-Produktes aufgrund eines Fehlers im Produkt auf

  1. Geben Sie offensive Fehlermeidungstechniken an und beschreiben Sie deren Grundformen.

-          z.B. Fehlertoleranzmechanismen: Ausnahmebehandlung, Wiederanlauf-Routinen, Implementationsdoppelung, Selbstkontrollen

  1. Was ist der Unterschied zwischen statischen und dynamischen Testmethoden?

-          statisch: Testverfahren und -methoden, die sich auf Quellcode beziehen

-          dynamisch: realisiertes Programm in abarbeitungsfähiger Form auf PC

  1. Geben Sie eine Checkliste zum Review von Programmstrukturanweisungen (while, repeat usw.) an.

-          Checkliste: Prüfung des Quellcodes eines Programms nach vorgegebenem Muster, z.B.: Einhaltung einfacher syntaktischer Regeln, paarweise Verwendung der Klammerung à Ergebnis entscheidet über den notwendigen weiteren Testaufwand

-          Review: Verallgemeinerung des Checklistenverfahrens

ž          Planung:  Moderator prüft Inspektionsteam gegen Vorbedingungen (Vertraulichkeit, Vorkenntnisse), verteilt 2 Wochen vorher   Inspektionsmaterial, legt Termin fest

ž          Einführung: vorbereitende Sitzung dient der Schulung der Inspektoren für ihre Arbeit

ž          Vorbereitung: Teilnehmer erarbeiten sich anhand der verteilten Unterlagen ihr Verständnis des zu inspizierenden Programmcodes

ž          Inspektion: Analyse des Programms durch die Inspektoren gegen den Autor, Moderator leitet Sitzung und protokolliert

ž          Korrektur: Beseitigung der gefundenen Fehler in einer festegelegten Zeitspanne durch den Autor

ž          Nacharbeit: Prüfung, ob alle Fehler behoben, ob mögliche Nachwirkungen protokolliert; Entscheidung, ob weitere Inspektionssitzung

  1. Was ist das Grundprinzip der symbolischen Programmtestung.

-          Ablaufverfolgung des Programms mit Symbolen à kommt man „logisch“ (Schreibtischtest) zum geforderten Ergebnis?

  1. Führen Sie zu dem im Abschnitt 1.2.6 angegebenen Pseudocodebeispiel die Programmverifikation durch.
  2. Welche Klassifikation der Testdaten wird beim Black-Box-Test zugrunde gelegt?

-          Testdaten aus Spezifikation bzw. Entwurf à Normalwerte, Extremwerte, Falschwerte

  1. Geben Sie zu dem in Aufgabe 27 genannten Algorithmenbeispiel die notwendigen Testfälle an.
  2. Zeichnen Sie zu dem Algorithmenbeispiel in Aufgabe 27 den Programmflussgraphen und diskutieren Sie die Abdeckungsmaße zum White-Box-Test.

-          S. 81 ff.; Beispiel auf S. 78

  1. Erläutern Sie zu diesem Programmbeispiel auch die sogenannten du-paths und beschreiben Sie die dabei möglichen Fehlerquellen.

-          definition-use-paths: Überprüfung aller Definitions-Verwendungs-Pfade hinsichtlich möglicher Nebeneinflüsse, insbesondere werden dabei fehlende initiale Wertzuweisungen erkannt

  1. Welchen Testansatz verfolgt man mit dem Program Slicing?

-          komplette Untersuchung eines bestimmten Teilaspekts, nur relevante Größen werden betrachtet; s. S.  85

  1. Welche Rolle spielen Testdatengeneratoren, Vergleichsprogramme und Debugger beim Testen?

-          Testdatengeneratoren: computergestützte Erzeugung der Testdaten anhand der Spezifikation (Black-Box-Test) und/oder aus dem Quellcode (White-Box-Test)

-          Vergleichsprogramme: Testergebnisse vergleichen à gleiche Funktionalität, unterschiedlich entwickelt/implementiert

-          Debugger: Ablaufverfolgung, auch Step-by-Step, auch Testfortsetzung nach Fehler an beliebiger Stelle des Programms

  1. Erläutern Sie die bei der Software-Integration zur Anwendung kommenden Top-Down- und Sandwich-Testmethoden.

-          Top-down: Testen der Komponenten der Hierarchie(-Ebenen) nach

-          Sandwich: von einzelnen Komponenten zu Bereichen (cluster) à immer komplexer bis ganzes Programm à Teilintegration

  1. Was ist ein Big-bang-Test?

-          man testet alle Komponenten einzeln und fügt alle zusammen, man testet lediglich das Gesamtprogramm.

  1. Geben Sie ein Beispiel für einen Call-Graphen an.

-          S. 90 f.

  1. Welche wesentlichen Bestandteile hat die Entwicklerdokumentation nach der Implementation?

-          Programmdokumentation, die die Implementation begründet, die Lösung darstellt und die Struktur erläutert

-          Testdokumentation, die zum einen Testergebnisse selbst dokumentiert und zum anderen eine Testdatenmenge für den Regressionstest bereitstellt

-          Änderungsdokumentation, die Hinweise für Ansatzpunkte einer Programmänderung und die dafür zu verwendenden Hilfsmittel beinhaltet

-          Spezifikations- bzw. Entwurfsdokumente und deren Lösungsvarianten

-          Beschreibung der Hilfsmittel, wie Analyse-Tools, Code-Bibliotheken oder Generatoren

-          Checklisten und Review-Dokumente

-          Leistungsanalysen und -bewertungsangaben zu den einzelnen Systemkomponenten

  1. Welche konzeptionellen Bestandteile hat das für die Erprobung erforderliche Abnahmekonzept?

-          Abnahmekonzept: Festlegungen zur Eigenentwicklung, Vorgaben für nachgenutzte Software, Protokollierungsform und involviertes Abnahmepersonal

  1. Nennen Sie Inhalt und Formen des Betatests.

-          Integrationstest

-          Inhouse: firmenintern à fertiges Produkt in der Anwendung

-          Outside: in der breiten Öffentlichkeit à ähnlich Testversion

  1. Geben Sie Beispiele als Ursachen für eine Erweiterung, Anpassung, Korrektur, Verbesserung oder Vorbeugung bei der Wartung eines Software-Systems an.
  2. Welche Wartungsart ist aus der praktischen Erfahrung heraus die häufigste?

-          Verbesserungen und Ergänzungen für Auftraggeber à Erweiterungen

  1. Erläutern Sie die Teilkriterien für die Wartbarkeit eines Software-Produktes an einem Beispiel.

-          Analysierbarkeit: gute Dokumentiertheit, überschaubare Strukturierung der Produktarchitektur

-          Änderbarkeit: Aufwand à rentiert sich Änderung gg. neuer Implementation?

-          Stabilität: Risiko, dass bei Änderungen am Produkt Neben- oder Folgewirkungen, wie Fehler in anderen Produktteilen oder Inkompatibilitäten, auftreten

-          Testbarkeit: vertretbarer Aufwand für Test

  1. Was versteht man unter der Migration eines Software-Systems?

-          Migration ist die Überführung eines Software-Systems auf eine neue operationale Umgebung. Das kann von der Änderung der System-Software (insbesondere des Betriebssystems) bis hin zum Wechsel der Plattform reichen à evtl. neuer Entwurf

  1. Welchen Sinn verfolgt eine Kategorisierung auftretender Fehler bei der Software-Anwendung für die Wartung?

-          damit Wartungsabteilung weiß, wie akut ein Fehler ist à erst bei nächstem Release, sofort, oder viel später beheben

-          Kategorie E: Notfälle, sofort zu beheben, da sonst Anwendung nicht mehr möglich, z.B. Steuerungsausfall einer Taktstrasse

-          Kategorie 1: bedeutende Auswirkungen, brauchen zwar längere Installationszeit, aber nicht erst in neuer Programmversion, z.B. Recherchefehler in digitalen Bibliotheken

-          Kategorie 2: erst in neuer Programmversion, z.B. Ausfall einer Teilfunktion in einem Textverarbeitungssystem

-          Kategorie 3: vom Benutzer erkannte Fehler, hat Zeit

  1. Wann sind Verbesserungen an einem Software-Produkt unumgänglich?

-          bei zu schlechter Leistung (performance) des Systems oder bei zu hohem Ressourcenverbrauch, z.B. Antwortzeitverhalten in interaktiven Systemen

  1. Zeichnen Sie für die Priorisierung der Fehlerkorrektur einen Entscheidungsbaum.

-          S. 99 f.

  1. Welches Personal ist im allgemeinen bei der Software-Anwendung erforderlich?

-          User, Administrator, Betreiber (Operator à stellt z.B. Ressourcen zur Verfügung), Auftraggeber

  1. Erläutern Sie jeweils zwei sequentielle und nichtsequentielle Lebenszyklusmodelle.

-          sequentiell: Wasserfallmodell, V-Modell, Cleanroon-Engineering

-          nicht sequentiell (auch: zyklisch): evolutionäre Software-Entwicklung, Prototyping, inkrementelle Software-Entwicklung, Spiralmodell

1.3 Das Personal zum Software Engineering

Ein Software-Entwickler (software developer) ist eine mit speziellen Kenntnissen der Entwicklungsmethodik, bestimmter Paradigmen sowie ausgewählter Anwendungsbereiche versehene Person, die auf der Grundlage vorgegebener Problembeschreibungen oder Entwicklungsdokumente eine oder mehrere Phasen der Software-Entwicklung und –Wartung durchführen kann.

66.  Geben Sie Berufsbezeichnungen für Software-Entwickler, die in den verschiedenen Entwicklungsphasen zum Einsatz kommen, an.

-          Anforderungsanalyse: Systemanalytiker

-          Spezifikation: Systemanalytiker, Systementwickler

-          Entwurf: Systementwickler, Software-Akquisiteur

-          Implementation: Programmierer

-          Erprobung: Software-Tester

-          Wartung: Wartungs-Ingenieur

  1. Welche Qualifikationsformen besitzt ein Software-Entwickler für eine konkrete Entwicklungsfirma?

-          Einstiegsqualifikation: spezielle Ausgangssituation der Kenntnisse eines Entwicklers, außerhalb des betrachteten Entwicklungsbereiches zuvor erworben

-          Entwicklungsqualifikation: Kenntnisse und Fähigkeiten, während der Tätigkeit in dem betrachteten Entwicklungsbereich erworben

  1. Was ist die grundlegende Idee des Personal Software Process?

-          Verbesserung der Effizienz und Wirksamkeit des einzelnen Entwicklers

-          Erlernen der Software-Messung, Anwenden für ausgewählte Aspekte, Fehlervermeidung, Erlernen der Bewertung der eigenen Leistung/Leistungsverbesserung, kontinuierlicher Prozess der Messung und Auswertung

  1. Was versteht man jeweils unter einem homogenen, temporären und universellen Entwicklungs-Team.

-          homogen: alle mit gleichen Charakteren, Kenntnissen

-          temporär: Zusammensetzung der Teams den gerade erforderlichen Kenntnissen nach

-          universell: für alle Anforderungen rel. gut geeignet

  1. Beschreiben Sie zwei Arten von Kommunikationsstrukturen an einem Beispiel.

-          vollständige Kommunikation, Kommunikationskette, Y-Kommunikation, sternförmige Kommunikation

  1. Welche Struktur hat das Chefprogrammierer-Team?

-          Chefprogrammierer, sein Assistent, Senior-programmierer, mehrere Junior-Programmierer, Bibliothekar, Administrator, Testteam

  1. Was ist ein CEO und was ist ein CIO?

-          chief executive officer (Abteilungsleiter), chief information officer (Leiter Informationsverarbeitung)

  1. Wie sieht ein Entwickler den Nutzer bzw. Auftraggeber?

-          S. 125

  1. Welche Grundelemente bestimmen eine Community?

-          Verbände, z.B. Gesellschaft für Informatik (GI)

-          Forschungseinrichtungen, z.B. Software Engineering Institute (SEI) in Pittsburgh

-          Fachliteratur(v.a. Zeitschriften), z.B.: Softwaretechnik-Trends

-          Konferenzen, z.B. ICSE

  1. Nennen Sie zu jedem Grundelement Beispiele für die Community des Software-Ingenieurs.

1.4 CASE-Tools und Entwicklungsumgebungen

Unter Software-Werkzeugen (software tools) verstehen wir die rechnergestützten Hilfsmittel zur Unterstützung der Entwicklung und Wartung eines Software-Produktes.

Eine Tool-Integration ist die Zusammenfassung von Komponenten für eine spezielle oder ganzheitliche Aufgabe im Rahmen des Software Engineering in den Formen der Komposition (z.B. durch eine einheitliche Präsentation), der Aggregation (als daten- oder steuerungsbezogene Form) oder der Assoziation (z.B. als Plattformverbindung).

Eine Software-Entwicklungsumgebung (software development environment) ist ein methodengestützter und toolbasierter Entwicklungsplatz, der die entsprechenden Möglichkeiten der Software-Messung, der Anwendung der gültigen Standards und Erfahrungen der jeweiligen Entwicklungs-Community unterstützt.

76.  Erklären Sie die Aufgaben von Upper-CASE-Tools und geben Sie Beispiele an.

-          CASE-Tools für die frühen Phasen: Problemdefinition bis Entwurf

-          Problemdef.: Textverarbeitungssystem

-          Anforderungsanalyse: Suchmaschinen, digitale Bibliotheken

-          Spezifikation: Rational Rose

-          Entwurf: SelectTool

  1. Geben Sie Beispiele für die Grenzen einer Automation durch CASE-Tools an.
  2. Welche Funktionen werden durch CARE- und CAME-Tools realisiert?

-          Reengineering

-          Analyse-, Mess- oder Bewertungstools

  1. Nennen Sie zu jeder Entwicklungsphase ein geeignetes CASE-Tool und erläutern Sie dessen Anwendungsvorteile und ggf. -probleme.

-          Problemdefinition: Textverarbeitungssystem (z.B. Word) oder HTML-Editor (z.B. Netscape-Editor)

-          Anforderungsanalyse: für Begriffskontrolle: Datenbanksysteme; für Recherche: Suchmaschinen, Dig. Bibliotheken; Programmiersysteme für Prototypen: Delphi, JavaBeans...

-          Spezifikation: Modellierungstools wie z.B. Rational Rose

-          Entwurf: für Architekturdarstellung, z.B. mit SELECT-Tool

-          Implementation: Programmierumgebungen, z.B. Forte for Java oder Jbuilder

-          Wartung: Analyse-Tools wie Cosmos, Statistik-Tools, Performance-Tools

  1. Wählen Sie eine Programmierumgebung aus und geben Sie dazu die Architektur in einem Komponentendiagramm an.
  2. Welche Tool-Integrationsformen gibt es und welche durch CASE-Tools inhaltlich zu lösenden Aufgaben erfordern diese Integrationen?

-          Entwicklungs-Tools: Upper-CASE-Tools à erste Programmgenerierung (Skelette)

-          Programmier-Tools: Programmierumgebungen mit zusätzlichen Visualisierungsmöglichkeiten der Programm- oder Systemstruktur à endgültige Machbarkeit des Software-Systems gewährleistet, aber: keine Validitätsprüfung!

  1. Wählen Sie eine Programmierumgebung aus und erarbeiten Sie die dafür notwendigen Bestandteile für eine Entwicklungsumgebung.

1.5 Software-Messung

Die Software-Messung (software measurement) ist der Prozess der Quantifizierung von Attributen der Objekte bzw. Komponenten des Software Engineering mit der Ausrichtung auf spezielle Messziele (measurement goals) und ggf. der Einbeziehung von Messwerkzeugen (measurement tools).

Eine Software-Metrik ist gemäß der Maßtheorie eine Abstandsfunktion (distance), die Attributen von Software-Komponenten Zahlen (-bereiche) zuordnet.

Ein Software-Maß (software measure) ist gemäß der Messtheorie eine mit einer Maßeinheit versehene Skala, die in dieser Form ein Software-Attribut bewertet bzw. messbar macht.

Das Maßsystem (system of measures) beim Software Engineering ist eine Menge von vorhandenen Software-Maßen, -Kennzahlen  und –Metriken, die sich auf alle wesentlichen Aspekte der Software-Entwicklung und –Wartung beziehen und in ihrer Anwendung aufgrund von Beobachtungen, Analysen und kontrollierten Experimenten durch die Definition und den Einsatz neuer Maße oder Metriken kontinuierlich erweitert, angepasst und verbessert wird.

Ein Software-Messtool (metrics tool) sei ein Software-Werkzeug, welches Komponenten eines Software-Produktes oder der Software-Entwicklung in ihrer Quellform oder transformierten Form (z.B. als Modell) einliest und nach vorgegebenen Verarbeitungsvorschriften numerisch oder symbolisch auswertet.

Tools für die Software-Messung sind sowohl Messtools als auch Software-Werkzeuge, die der Ausprägung der jeweiligen Messstrategie, der Aufbereitung der Messobjekte oder der statistischen Auswertung bzw. Darstellung der Messergebnisse dienen.

83.  Welche drei Bestandteile bestimmen die Software-Messung?

-          Quantifizierung von Attributen

-          Messziele

-          Messwerkzeuge

  1. Begründen Sie das Gesetz der wachsenden Entropie an einem selbst gewählten Beispiel.
  2. Machen Sie sich mit den möglichen Diagrammformen zur Messwertdarstellung vertraut und erläutern Sie den Unterschied zwischen einem Balkendiagramm und einem Histogramm.
  3. Erklären Sie den Aufwandsunterschied zwischen der Hard- und Software-Herstellung bzw. Entwicklung.
  4. Was sagt die sogenannte Badewannenkurve aus?

-          Abtragung Komponentenanzahl gegen Aufwand: bei zu vielen Komponenten sinkt zwar der Aufwand zur Bildung/Entwicklung der Komponenten, aber es steigt der Integrationsaufwand, so dass der Gesamtaufwand ab einer bestimmten Stelle auch wieder ansteigt à gesunde Mitte zwischen Komponentenbildung und Integration

  1. Geben Sie Faustregeln zur Programmier-Produktivität und Programm-Fehlerrate an.

-          jeder Dollar für die Software-Entwicklung kostet zwei Dollar bei der Wartung

-          ein Entwickler schafft bei der Erstellung von Software-Produkten ca. 250 LOC pro Monat

-          entwickelte Programme haben noch ca. 3 Fehler pro 1000 Programmzeilen

-          Behebung eines Software-Fehlers während der Implementation ist einhundert mal teurer als in der Entwurfsphase

  1. Berechnen Sie den Anteil an Dokumentationsseiten für ein Software-System mit 10000 Programmzeilen.

-          Dokumentationsseiten = 0,0347 * Programmzeilen0,93 à = 0,0347 * 100000,93 = 182

  1. Bewerten Sie die Lesbarkeit nach dem Flesh-Index für eine Seite dieses Buches und für einen Abschnitt in der Tageszeitung und erläutern Sie die möglichen Unterschiede.

-          Lesbarkeit = 206,85 – 0,846 * (durchschnittl. Wortsilbenanzahl) – 1,105 * (durchschnittl. Wortanzahl pro Satz)

  1. Erweitern Sie die Liste möglicher LOC-Metriken um eigene Beispiele bzw. Definitionen.
  2. Erläutern Sie die einzelnen Skalentypen und geben Sie Beispiele aus dem täglichen Leben dazu an.

-          nominalskaliert: Identifikation von Software-Tools oder die Kennzeichnung einer Eigenschaft, z.B. bei ISO-9000-Zertifizierung: ja/nein

-          ordinalskaliert: Bewertung von CASE-Tools hinsichtlich Stabilität, Flexibilität à platzierend, ordnend, Rangfolge gebend

-          intervallskaliert: Temperatur

-          ratioskaliert (verhältnisskaliert): z.B.: Längenmaße, Preise, Leistungsverhalten, Anwendungszeiträume

  1. Nennen Sie die wesentlichen Unterschiede zwischen Justieren und Kalibrieren.

-          Justieren: „Einstellen“ eines Softwaremaßes hinsichtlich seiner empirischen Bewertung aufgrund einer speziellen Anwendungsbezogenheit                      à Thermometer genau einstellen

-          Kalibrieren: das Verändern des numerischen Relativs zum vorgegeben empirischen Relativ à Messbereich festlegen

  1. Mit welcher empirischen Bedeutung kann die LOC-Metrik als Maß verwendet werden?
  2. Welche Problematik ergibt sich bei der Anwendung der MT-Maße für Programme insbesondere hinsichtlich der Schlussfolgerungen für die Korrektheit?

-          bewertet nur Zeiten, nicht die Schwere, ermittelt auch nur wirklich auftretende Fehler, über noch nicht entdeckte keine Aussagemöglichkeit

  1. Erläutern Sie kurz die Schritte zur Maßdefinition nach dem IEEE-Standard an einem selbst gewählten Beispiel.

-          Maßdefinition, empirische Bewertung, messtheoretische Analyse, Softwaremessung, Ergebnisinterpretation

  1. Welche Rolle spielen statistische Analyseverfahren bei der Software-Messung?
  2. Geben Sie Beispiele aus der Software-Entwicklung für eine Varianz- und Diskriminanzanalyse an und beschreiben Sie die damit gezeigten bzw. bewiesenen statistischen Aussagen.
  3. In welchen Fällen ist eine (indirekte) Kausalanalyse beim Software Engineering sinnvoll?

100.    Nennen Sie Beispiele zur Unterstützung der Software-Wartung durch Clusteranalysen.

101.    Beschreibung Sie die Planung und Durchführung einer Evaluierung zur Bewertung der Kundenzufriedenheit.

-          Evaluierungen: basieren auf Klassifikationstechniken, z.B. einem Fragebogen, der Bewertung in Tabellenform vornimmt à ermöglicht Klassifikation des Bewertungsmerkmals à liefern Vergleichsmöglichkeit bzw. ordinale Bewertung; Wichtung der Zwischenergebnisse zur Bewertung der unterschiedlichsten, komplexeren Bewertungsmerkmale à Verteilungsübersichten, prozentuale Anteildarstellungen, Häufigkeitsanalysen etc.

102.    Was versteht man beim Software Engineering unter Assessment. Geben Sie ein Beispiel dafür an.

-          Assessment: gehört zu den Evaluierungen, beziehen sich aber auf einen speziellen Zeitpunkt und schließen andere Skalierungsformen, z.B. verhältnisskalierte Bewertung bzw. Messung mit ein

-          z.B. bei Anforderungsanalyse als Ist-Zustandsanalyse à Bewertung einer konkreten Situation von Software-Produkten, -Prozessen und -Ressourcen

103.    Welche Bedeutung haben kontrollierte Experimente bei der Software-Entwicklung?

-          kontrollierte Experimente: dienen der Bestätigung oder Widerlegung von Hypothese, die wiederum Ausgangspunkt für die Aufstellung von Metriken oder dem empirischen Nachweis der Gültigkeit von Software-Maßen sein können

-          Kontrolle des Experiments bezieht sich auf die genaue Planung der Experimentvoraussetzungen, -ziele und -durchführung

104.    Beschreiben Sie ein kontrolliertes Experiment zur Bestimmung des besten Programmierers in einem Entwicklungsteam.

105.    Nennen Sie Merkmale eines kontrollierten Experiments zum Verstehen eines neuen Paradigmas.

106.    Gegeben seinen die Aufwandsverhältnisse für die Software-Entwicklung als Problemdefinition 5%, Anforderungsanalyse und Spezifikation 25%, Entwurf 30% und Implementation 40%. Für ein aktuelles Entwicklungsbeispiel ist der Aufwand für die Problemdefinition mit 2 Personenmonaten bekannt. Leiten Sie den Aufwand für die anderen Entwicklungsphasen nach dem Analogieschlussverfahren ab.

ž          5% = 2PM à Anforderungsanalyse: 10PM, Spez.: 10PM, Entwurf: 12PM, Impl.: 16PM à 40 PM Gesamtaufwand

107.    Geben Sie zu einem vorgegebenen Programm den Programmflussgraphen an und diskutieren Sie die daraus ableitbaren Metriken und deren empirische Bedeutung.

108.    Analysieren Sie das direkte Maß der Aufrufgeschwindigkeit einer Web-Seite im Internet.

109.    Welche Tool-Komponenten kommen bei der Software-Messung zum Einsatz?

110.    Beschreiben Sie die Mess- bzw. Bewertungstechniken für eine ausgewählte Prozessbewertung.

111.    Welche Visualisierungsformen sind bei der Programm-Modellierung und der damit verbundenen Bewertung sinnvoll?

112.    Erläutern Sie die Bewertungstechnik eines Kiviat-Diagramms an einem Beispiel.

113.    Wann sind Erläuterungen zu den Werten bei der modellbasierten Software-Messung sinnvoll?

114.    Beschreiben Sie den Sinn und die Vorgehensweise beim tool-gestützten Justieren in CAME-Tools.

115.    Welchen Inhalt und welche Zielstellung haben Tutorials zur Software-Messung?

-          allg. Informationen zur Software-Messung und Metriken, umfangreiche Literaturübersicht, Bewertungsform für Software-Maße mit den unterschiedlichsten Skalierungseigenschaften

1.6 Software-Management

Das Software-Management ist die Planung, Überwachung und Steuerung des Prozesses und der dabei einzusetzenden Ressourcen zur Entwicklung, Wartung und Anwendung von Software-Systemen.

Die Iteration im Verlauf der Software-Entwicklung ist die Umsetzung einer Anforderungsänderung, die den erneuten Durchlauf einer Entwicklungsphase zur Folge hat.

Das Projektmanagement beinhaltet die planenden, kontrollierenden und steuernden Aktivitäten für die termingerechte Bereitstellung der Ressourcen und der kostengerechten Realisierung eines Software-Produktes.

Das Qualitätsmanagement ist die Sicherung von Qualitätsmerkmalen für das Software-Produkt auf der Grundlage der Prozess- und Ressourcenqualität durch organisatorische Methoden und Maßnahmen unter Anwendung spezieller Techniken und Technologien.

116.    Geben Sie weitere Beispiele für die Vielfalt bzw. Dimensionierung von Produkt-, Prozess- und Ressourcenkomponenten beim Software Engineering an.

117.    Diskutieren Sie Ursachen für den Projekterfolg und -misserfolg.

118.    Berechnen Sie für das angegebene PERT-Beispiel zur Software-Entwicklung die kürzeste und die längste Projektdauer.

119.    Zeichnen Sie ein PERT-Diagramm für die Software-Wartung.

-          S. 188 f.

120.    Beschreiben Sie mit Hilfe eines CPM-Diagrammes die Prüfungsvorbereitung und -durchführung.

-          S. 190

121.    Geben Sie für die kontinuierliche Software-Entwicklung im Web ein Gantt-Diagramm an.

-          S. 191

122.    Erläutern Sie Formen und Ursachen für Risiken bei der Software-Entwicklung.

123.    Führen Sie eine Aufwandsschätzung nach dem COCOMO für eine teilintegriertes Produkt mit ca. 20 KDSI und den Merkmalen einer hohen Zuverlässigkeit, einer geringen Erfahrung des Entwicklungsteams und einen Zugang mit hoher Sicherheitsanforderung durch.

-          Rely 1,15; S= 1,07; ET=1,132

-          KDSI=20 à PE = 1,15 * 1,07 * 1,132 * 3,0 * 201,12 = 120PM

-          TDEV = 2,5 * PE0,35 = 27 M

124.    Bestimmen Sie die Function-Points für die vereinfachte Architektur eines Web-Browsers. Diskutieren Sie dabei die Klassifizierung nach einfachen, mittleren und komplexen Funktionsmerkmalen.

-          S. 198 f.; PM = 0,015216 FP1,29

125.    Führen Sie für den Teilbereich "Inspection und Testing" eine ISO 9000-Bewertung durch und nennen Sie die beteiligten personellen Ressourcen und den Prozeßbezug.

126.    Benutzen Sie die im SMLab zur Verfügung stehende CMM-Bewertungsmöglichkeit und leiten Sie die für die CMM-Stufe 4 wesentlichen Merkmale ab.

127.    Geben Sie für die GQM-Beispiele B und C die jeweiligen Sichten, Zwecke und den möglichen Kontext an.

128.    Formulieren einen GQM-Ansatz für die Bewertung einer Entwicklungsum-gebung bei der Software-Erstellung.

129.    Nennen Sie die wesentlichen Möglichkeiten einer Round-trip-Kontrolle durch das MS-Project-Tool.

130.    Geben Sie ein Beispiel für eine Vorgangsfolge eines Projektes an, die EA-, AA- und EE-Typen beinhaltet.

 

3.1 Objektorientierte Software-Entwicklung

Ein Objekt ist eine konkrete Form einer Abstraktion aus dem Problembereich als eine Einheit (entity) mit wohldefiniertem Geltungsbereich (boundary) und einer eindeutigen Identifikation, die ein spezielles Verhalten und Zustände beschreibt.

Eine Klasse beschreibt eine Menge von Objekten, die die gleichen Attributsmerkmale, die gleichen Dienste und eine gleichartige Semantik haben.

Eine Klassenbibliothek ist die technologische Zusammenfassung (im Allgemeinen als Menge von Dateien unter einem speziellen Verzeichnis) einer Menge von Klassendefinitionen zu einem speziellen Problembereich.

Ein Framework ist eine Menge erweiterbarer, kooperierender Objekte (Klassen), für die eine spezielle Anwendungsform definiert und implementiert ist.

167. Erläutern Sie drei Beispiele bzw. Gründe für die Notwendigkeit der Einführung der OOSE.

-          Rationalisierung der Programmierung: neben Daten konnten auch Operationen eingekapselt werden à Flexibilität

-          Erfahrungen zum Softwareprodukt: problembezogene Objekte „stabiler“ in der Änderungshäufigkeit

-          Erfahrungen zum Software-Prozess: von der Daten- zur Programmmodellierung musste per Hand übertragen werden à ERM

-          Lösung anstehender Probleme: effizientere Nachnutzung vorhandener Systemlösungen bzw. von Code-teilen überhaupt, erforderliche Flexibilität komplexer Systeme für deren Wartung und Anwendung

-          Bezug zum Weltmodell: OOSE kommt unserer Vorstellungswelt erheblich näher

168. Formulieren Sie ein Komponentendiagramm mit ausgewählten Objekten zur Desktop-Verarbeitung und nennen Sie Beispiele für Rollen und Szenarien zu den jeweiligen Objekten.

-          S. 49

-          Rolle ist das Verhalten eines Objektes in einem speziellen Kontext

-          ein Szenarium ist eine Sequenz von Aktionen zur Darstellung eines speziellen OO-Systemverhaltens, diese Aktionsfolge ist i.a. eine Folge von (parametrisierten) Nachrichten

169. Erweitern Sie das in Aufgabe 168 formulierte Objektdiagramm zu einem Klassendiagramm mit Beispielen zur Vererbung, Assoziation und Aggregation.

-          S. 277 - 282

170. Formulieren Sie auf der Grundlage der in Abbildung 173 dargestellten Vererbungshierarchie ein Klassendiagramm, welches die entsprechenden Attributs- und Methodenangaben beinhaltet.

171. Erweitern Sie in derselben Weise das in Abbildung 178 angegebene Klassendiagramm für die Problemausrichtung als Informationssystem.

172. Beschreiben Sie die grundlegenden Merkmale dreier OOSE-Methoden der ersten Generation.

-          HOOD (hierarchical object-oriented design): Problemdefinition, Erarbeitung einer (hierarchischen Lösungsstrategie), Umsetzung als Entwurf, Implementation à Problemsicht soll gewahrt bleiben (nicht nur Sicht auf Objekte), schließt auch Definition und Verarbeitung von constraints mit ein à eignet sich gut für Echtzeitsysteme

-          OMT (object modeling technique): erweitert notationell die Strukturierte Analyse um Objekt- und Dynamisches Modell à Einstieg durch Datenflussdiagramm, Relationsformen des ERM

-          OOSE (object-oriented software engineering): Einstieg über Use-Case-Diagramm; Verhaltenbeschreibung mittels Interaktions- oder Sequenzdiagrammen à v.a. für Kommunikationssysteme

173. Leiten Sie die aus dem angegebenen Zählerbeispiel potentielle Objekte her, wenn die Problemausrichtung eine Zählstatistik darstellt.

174. Definieren Sie aus dem in Abbildung 173 angedeuteten Systembeispiel ein Analysemuster.

-          S. 290 ff.

175. Erläutern Sie die Wiederverwendungsarten beim OOD durch selbst gewählte Beispiele.

-          externe: die Verwendung extern implementierter Klassen bzw. einzelner Methoden dieser Klassen

-          interne: die Verwendung von gleichartigem Code innerhalb einer Klasse bzw. innerhalb der für die jeweilige Anwendung selbst implementierten Klassen

-          modifizierte: die durch Änderungen der Attribute oder Methoden übernommene Klassen

-          parametrisierte: die spezielle Nutzung von Klassen, die als sogenannte Templates bzw. Makros bereits verallgemeinert definiert wurden

-          geerbte: die durch den Vererbungsmechanismus der Klassenhierarchien initiierte Wiederverwendung

176. Geben Sie Anwendungsbeispiele für die Entwurfsmuster Adapter und Beobachter an.

-          Adapter: Schnittstelle zwischen zwei oder mehr speziellen Klassen

-          Observer: kann auf Ereignisse anderer Objekte reagieren

177. Was unterscheidet ein Framework von einem Entwurfsmuster?

-          Ein Framework ist eine Menge erweiterbarer, kooperierender Objekte (Klassen), für die eine spezielle Anwendungsform definiert und implementiert ist.

-          Entwurfsmuster(Dokumentationsvorgabe): Mustername, Beschreibung des Problem- bzw. Geltungsbereiches für die Anwendung des Entwurfsmusters, Angabe der Architektur bzw. Struktur in Form eines Klassendiagramms, Bewertung der möglichen qualitativen Auswirkungen auf das Gesamtsystem

178. Beschreiben Sie jede klassenbezogene Modifikationsform beim OOP an selbst gewählten Beispielen.

            Die Implementation beim OOSE ist unter Umständen einfach nur eine Erweiterung des vorhandenen OO-Systems. Derartige Modifikationsformen sind:

-          einfache Übernahme der vorhandenen Implementation der Klasse und ihrer Methoden

-          Modifikation vorhandener Methoden als Erweiterung der Funktionalität der Klasse

-          Ergänzung von Methoden zu einer gegebenen Klasse

-          Veränderung der Attribute hinsichtlich Wertebereich, Gültigkeitsmerkmalen und Einheiten

-          Hinzufügen von Klassen als weiteres Blatt innerhalb der Vererbungshierarchie

-          „Anhängen“ von Klassen an eine Klassenbibliothek (z.B. als weitere Basisklasse bzw. direkt unter einer Wurzelklasse)

-          Hinzufügen neuer Klassenbibliotheken für neue Themenstellungen, wie z.B. zur Sicherhit oder einem neuen Anwendungsgebiet

-          Auswählen bestimmter Klassen bzw. Klassenbibliotheken für eine spezifische Anwendungssystemklasse

179. Welche software-technischen Erfahrungen beeinflussten die Entwicklung bzw. die Ausprägung von Java.

180. Wählen Sie eine Java-Klasse aus der Klassenbibliothek java.lang aus und erläutern Sie die Testproblematik für das OOSE.

-          Schnittstellen auch für Kommunikation der Objekte untereinander testen

-          bei abstrakten Klassen: konkrete Klassen bilden

-          Kopplung

-          Test-Stubs à Messages simulieren

-          Testrahmen à bei mehreren Szenarien (viele Objekte) sehr komplex

-          Interpretation: Bottum-Up-Test

181. Was sind die Kernpunkte für die Einführung neuer Paradigmen für die Software-Entwicklung und -Wartung?

182. Wählen Sie zwei Java-Klassen aus den Java-Bibliotheken aus und diskutieren Sie deren Qualitätsbewertung durch die Anwendung von OO-Metriken bzw.  dem MJava-Meß-Tool.

3.2 Komponentenbezogene Technologien

Software reuse is the systematic practice of developing software from a stock of building blocks, so that similarities in requirements and/or architecture between applications can be exploited to achieve substantial benefits in productivity, quality and business performance.“

Software assets are composed of a collection of related software work products that may be reused from one application to another.”

Die Visuelle Programmierung ist eine icon- bzw. symbolbasierte Form der Programmkonstruktion und -änderung.

183. Erläutern Sie Komponentenbeispiele für ein selbst gewähltes Entwicklungs- und Implementations-Paradigma.

184. Beschreiben Sie die Integrationsformen von Komponenten anhand einer CASE-Tool-Bildung.

-          systemtechnische Integration: Gewährleistung der Verbindungsmöglichkeit von Komponenten hinsichtlich ihrer Kommunikationsfähigkeit, z.B. Aggregation durch eine daten- oder steuerungsbezogene Interaktionsform

-          modelltechnische Integration: auf Modellebene, Abbildung verschiedener oder eine Einordnung in ein übergreifendes Modell, z.B. Komposition der Komponenten durch eine einheitliche Präsentationsform oder Assoziation der Komponenten durch verschiedene Vermittlungstechniken, wie Middleware oder Wrapper-Techniken

-          prozesstechnische Integration: übergreifende Arbeitsvorgänge bzw. Prozesse möglich, z.B. Kooperation von Komponentenprozessen zur Lösung gemeinsamer Aufgaben

185. Geben Sie für die der CBSE zur Anwendung kommenden Meßansätze Metrikenbeispiele an und erläutern Sie die empirische Bewertung?

186. Welche Risiken besitzt die COTS-Anwendung?

-          Source-Code nicht bekannt à welche Testfälle? , v.a. bei Erweiterung

-          Bewertung nur indirekt möglich à CURE (COTS usage risks evaluation)

187. Beschreiben Sie Beispiele der Software-Wiederverwendung an selbst gewählten Beispielen. Gehen Sie dabei insbesondere auf die Outside-Wiederverwendung ein.

-          S. 322

188. Beschreiben Sie zu jeder Entwicklungs- und Wartungsphase ausgewählte Asset-Beispiele für eine Software-Wiederverwendung.

189. Diskutieren Sie die Metriken Reuse Leverage und Reuse Percent an ausgewählten Wiederverwendungsformen.

190. Geben Sie ein Architekturbeispiel für eine JavaBeans-bezogene Software-Entwicklung eines CASE-Tools an.

3.3 Software-Reengineering

Unter Software-Reengineering werden die Aktivitäten, Maßnahmen und Methoden verstanden, die der Erhöhung des Verständnisses, der Wartbarkeit und der Wiederverwendbarkeit dienen bzw. diese erst ermöglichen.

191. Erläutern Sie die Ursachen des Reengineering und geben Sie Beispiele aus dem Bereich der Programmierung an.

-          S. 330

192. Welche Anforderungen muss eine CASE-Tool-basierte Entwicklungsmethodik erfüllen, um die Entwicklungsdokumente aktuell zu halten?

193. Geben Sie für die in Abbildung 210 angedeuteten Reengineering-Ansatzpunkte jeweils ein Beispiel an.

-          Dissassemblierung: Aus Assembler wieder auf Quellcode kommen

194. Beschreiben Sie die Reengineering-Phasen für die Beispiele der Umstellung der Programmiersprache oder des Paradigmas in einem Software-System.

195. Erläutern Sie Ursachen für die weitere Aktualität des Y2K-Problems.

3.4 Formale Spezifikation

196. Spezifizieren Sie ein System zur Analyse von Quelltexten hinsichtlich der Einhaltung von selbst vorgegebener Programmierkonventionen.

197. Stellen Sie eine Z-Spezifikation für eine robuste Additionsfunktion zum Geburtstagebuch auf.

198. Beweisen Sie die formale Implementation der Spezifikation FindGeburtstag.

199. Geben Sie eine programmierte Form für die Funktion InitGeburtstagebuch an.

200. Geben Sie Beispiele an, die den Korrektheitsbeweis einer formalen Implementation in der programmierten Form unterlaufen könnte.

3.5 Verteilte Software-Entwicklung

Ein verteiltes Software-System (distributed software system) ist ein auf mehreren autonomen Rechnern agierendes Software-System mit den Möglichkeiten der verteilten Verarbeitung und Anwendungen und der Einbeziehung räumlich voneinander getrennter personeller Ressourcen.

Ein Software-Agent ist ein Software-System, welches innerhalb einer definierten Umgebung, dessen Bestandteil er auch ist, in einer bestimmten Zeit, mit einer ihm immanenten Verhaltensweise und einer vorgegebenen Zielstellung wirkt bzw. agiert.

Die verteilte Software-Entwicklung ist die arbeitsteilige Realisierung von Entwicklungsarbeiten zu einem Software-System auf der Basis eines verteilten Entwicklungssystems.

Groupware are computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment.” à Computer-Supported Cooperative Groupware (CSCW)

201. Erläutern Sie die sechs Merkmale eines verteilten Systems am Beispiel eines neu zu entwickelnden Web-Browsers.

202. Formulieren Sie den Auftragsverlust bei einem Client-Server-System für mehrere zeitversetzte Aufträge in einem Sequenzdiagramm.

203. Geben Sie mögliche Ursachen für die Nichteinhaltung des WYSIWIS-Prinzips an.

204. Diskutieren Sie am Beispiel eines MBone-Whiteboards die Möglichkeiten der Verletzung des ACID-Prinzips.

        ACID – Prinzip:

-          Atomarität (atomicity) als Forderung einer vollständigen Ausführung einer Transaktion ohne jede Seiten- oder Nebeneffekte

-          Konsistenz (consistency) im Sinne der Konsistenzerhaltung der bearbeiteten Daten- oder Informationsmenge

-          Isolation hinsichtlich der Nichtverfügbarkeit bzw. Nichtsichtbarkeit der durch eine Transaktion erzeugten Zwischenergebnisse beliebiger Art

-          Dauerhaftigkeit (durability) als Forderung, dass nach Beendigung einer Transaktion auch alle Änderungen erhalten bleiben

205. Beschreiben Sie eine mögliche Architektur für eine auf Telearbeit beruhende arbeitsteilige Software-Wartung durch ein Komponentendiagramm.

206. Geben Sie Aufgabeninhalte für Software-Agenten zur Unterstützung des Global Software Engineering an.

 

4. Software-Entwicklung mit der UML

Zu UML gehören:

-          Sequenzdiagramm

-          Use-Case-Diagramm

-          Klassendiagramm

-          Zustandsdiagramm

-          Kollaborationsdiagramm

-          Komponenten- und Verteilungsdiagramm

-          Aktivitätsdiagramm

A constraint is a restriction on one or more values of (part of) an object-oriented model or system.

Die aspektorientierte Programmierung (AOP) ist die modulare Ausrichtung einer objektorientierten Programmstruktur auf bestimmte Bedingungen oder Aspekte durch eine spezielle funktionale Dekomposition (crosscuts) und der damit möglichen aspektbezogenen Testung und Wartung.