1.1 Einführung und grundlegende Begriffe
1.3 Das Personal zum Software Engineering
1.4 CASE-Tools und Entwicklungsumgebungen
3.1 Objektorientierte Software-Entwicklung
3.2 Komponentenbezogene Technologien
3.5 Verteilte Software-Entwicklung
4. Software-Entwicklung mit der UML
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.
- Fat: Office 98, die meisten Spiele; Firm: BIOS, auf den Geräten drauf; Free: Acrobat Reader, WinZip
- Personal, Software, Hardware
- 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
- 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
- Einhaltung der Vorgabe à in Anforderungsanalyse beschrieben, z.B. Reaktionszeit, Zuverlässigkeit, Speicherbedarf
à Messung und Bewertung von Ressourcen (z.B. Entwicklungszeit und –Kosten)
-
allg.:
no big bang, tiny Step
- konkret: 1 $ Entwicklung kostet 2 $ Wartung
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
- 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“
- 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
- 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
- Vereinfachung (abstraction), Aufteilung (partition), komprimierte Abbildung (projection)
- alle Beschreibungsdaten (Größen, Daten) à Metadaten (auch Abkürzungen, Begriffsbezeichnungen, -abhängigkeiten) à Modelle
-
S: Rechnen (Grundrechenoperationen)
-
P: Simulation des Wetters (zu komplex), Schachspiel
- E: Modellierung des Wirtschaftssystems eines Landes
-
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
- v.a. systembezogene (hard- und softwarebezogen)
- Commercial off the shelf: bereits vorhandenes Anwendungssystem, z.B. die Java-Programmbibliotheken
- S. 49 ff.
-
Bindung: alle Funktionalitäten in einer Komponente
(Funktionalität)
-
Kopplung: gar keine Verbindung zu anderen Komponenten
(Daten)
- Schachspiel: zuerst Strategie, dann Grafik
- S. 53 f.
- S. 55
- S. 56
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
- relativ eigenständig während der Entwicklung à geeignete Anwendungs- bzw. Standardsoftware
à Marktrecherche, Tauglichkeit, Vertragsgestaltung à Beschaffung
- Konfiguration ist eine Version oder Variante der Grundarchitektur eines Software-Produktes, welches ganz speziellen Nutzeranforderungen dient.
- verbesserte Anwendungsdokumentation (jetzt: Software-Ausrichtung), Entwicklerdokumentation (in Implementation verfeinern)
- 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
- 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
- einheitliche, gut lesbare Form, mnemonische Aspekte; v.a. bei verteilten Anwendungen: Zugriff auf Funktionen, die anders heißen
- 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
- z.B. Fehlertoleranzmechanismen: Ausnahmebehandlung, Wiederanlauf-Routinen, Implementationsdoppelung, Selbstkontrollen
- statisch: Testverfahren und -methoden, die sich auf Quellcode beziehen
- dynamisch: realisiertes Programm in abarbeitungsfähiger Form auf PC
- 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
- Ablaufverfolgung des Programms mit Symbolen à kommt man „logisch“ (Schreibtischtest) zum geforderten Ergebnis?
- Testdaten aus Spezifikation bzw. Entwurf à Normalwerte, Extremwerte, Falschwerte
- S. 81 ff.; Beispiel auf S. 78
- definition-use-paths: Überprüfung aller Definitions-Verwendungs-Pfade hinsichtlich möglicher Nebeneinflüsse, insbesondere werden dabei fehlende initiale Wertzuweisungen erkannt
- komplette Untersuchung eines bestimmten Teilaspekts, nur relevante Größen werden betrachtet; s. S. 85
- 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
- Top-down: Testen der Komponenten der Hierarchie(-Ebenen) nach
- Sandwich: von einzelnen Komponenten zu Bereichen (cluster) à immer komplexer bis ganzes Programm à Teilintegration
- man testet alle Komponenten einzeln und fügt alle zusammen, man testet lediglich das Gesamtprogramm.
- S. 90 f.
- 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
- Abnahmekonzept: Festlegungen zur Eigenentwicklung, Vorgaben für nachgenutzte Software, Protokollierungsform und involviertes Abnahmepersonal
- Integrationstest
- Inhouse: firmenintern à fertiges Produkt in der Anwendung
- Outside: in der breiten Öffentlichkeit à ähnlich Testversion
- Verbesserungen und Ergänzungen für Auftraggeber à Erweiterungen
- 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
- 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
- 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
- bei zu schlechter Leistung (performance) des Systems oder bei zu hohem Ressourcenverbrauch, z.B. Antwortzeitverhalten in interaktiven Systemen
- S. 99 f.
- User, Administrator, Betreiber (Operator à stellt z.B. Ressourcen zur Verfügung), Auftraggeber
-
sequentiell:
Wasserfallmodell, V-Modell, Cleanroon-Engineering
- nicht sequentiell (auch: zyklisch): evolutionäre Software-Entwicklung, Prototyping, inkrementelle Software-Entwicklung, Spiralmodell
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
- 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
- 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
- homogen: alle mit gleichen Charakteren, Kenntnissen
- temporär: Zusammensetzung der Teams den gerade erforderlichen Kenntnissen nach
- universell: für alle Anforderungen rel. gut geeignet
- vollständige Kommunikation, Kommunikationskette, Y-Kommunikation, sternförmige Kommunikation
- Chefprogrammierer, sein Assistent, Senior-programmierer, mehrere Junior-Programmierer, Bibliothekar, Administrator, Testteam
- chief executive officer (Abteilungsleiter), chief information officer (Leiter Informationsverarbeitung)
- S. 125
- 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.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
- Reengineering
- Analyse-, Mess- oder Bewertungstools
- 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
- 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!
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
- 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
- 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
- Dokumentationsseiten = 0,0347 * Programmzeilen0,93 à = 0,0347 * 100000,93 = 182
- Lesbarkeit = 206,85 – 0,846 * (durchschnittl. Wortsilbenanzahl) – 1,105 * (durchschnittl. Wortanzahl pro Satz)
- 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
- 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
- bewertet nur Zeiten, nicht die Schwere, ermittelt auch nur wirklich auftretende Fehler, über noch nicht entdeckte keine Aussagemöglichkeit
- Maßdefinition, empirische Bewertung, messtheoretische Analyse, Softwaremessung, Ergebnisinterpretation
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
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.
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.
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.